y2k stuff

From: Megan <mbg_at_world.std.com>
Date: Mon Jan 4 22:48:32 1999

>What boggles the mind is that this is a problem at all. It seems hard to
>believe (in retrospect) that people really did deliberately build
>software with only 2 digit years. I know it saved a few bytes, and yes,
>I remember when a byte of memory was a significant amount, but still.
>How did standard programming practice come to be so short sighted as to
>assume that software infrastructure would be thrown out and replaced on
>a regular basis?

The problem is that it isn't just one problem... it is a series of
problems, some of which have already been addressed over the years.

It isn't just that software only handled two-digit years. That is,
at best, simplistic, and at worst, just plain wrong. The fact is
that there are numerous levels to the problem. Let me enumerate
some of them...

        o Boot code - Does the hardware have a calender/clock? How
          does it store the date? How does one set the date? How
          does it report the date?

          An example of this is the 11/93

        o Adapters/controllers - Do they have an internal calendar/clock?
          How do they store the date? How is the date set? How is
          the date reported?

          An example of this is are the RF series DSSI disks... they
          seem to have a built in clock and can report dates/times and
          even when the device was last powered on.

          Also, some devices will report date information, but only
          once it is set by the host operating system - an example is
          the DELQA, which reports date/time in a MOP System ID packet.

        o The operating system - how does it store the date? How does
          it accept the date? How does it report the date?

          RT-11, for example, stored years in 5-bit fields and the base
          year was 1972... which would work to 2003, but there were
          other problems. This was upgraded to 7-bits worth of info,
          which increased the range from 1972 to 2099, but there were
          still problems with other parts of the system -- Mentec's
          V5.7 addresses this.

          What about pdp-8s? They have been through the end of their
          epoch several times over... What about tops-10? What about
          Unix, which breaks in 2038...

        o The on-disk directory structure - How is the date encoded?

        o Applications - Are they concerned with the date? Do commands
          allow date specifications? In what form? How is date info
          reported?

        o *DATA* - what about all those data files which have been
          recorded over the years? What form was date stored?

And I'm sure others can come up with more levels... these were just those
which I could come up in 5 minutes of thinking...

Keep in mind that when many institutions report they are working on
Y2k issues... it is probably only billing. What about hospitals and
the embedded controls in, for example, patient-controlled analgesia?

There are going to be more and more failures as we get closer. Last
year, there was a report that an insurance company which normally
issued 3-year policies could only do two-year. If they haven't
fixed the problem, they're probably down to one year now...

                                        Megan Gentry
                                        Former RT-11 Developer
(Not speaking for Compaq)
+--------------------------------+-------------------------------------+
| Megan Gentry, EMT/B, PP-ASEL | Internet (work): gentry!zk3.dec.com |
| Unix Support Engineering Group | (home): mbg!world.std.com |
| Compaq Computer Corporation | addresses need '_at_' in place of '!' |
| 110 Spitbrook Rd. ZK03-2/T43 | URL: http://world.std.com/~mbg/ |
| Nashua, NH 03062 | "pdp-11 programmer - some assembler |
| (603) 884 1055 | required." - mbg |
+--------------------------------+-------------------------------------+
Received on Mon Jan 04 1999 - 22:48:32 GMT

This archive was generated by hypermail 2.3.0 : Fri Oct 10 2014 - 23:32:03 BST