Conference 7.286::digital

	What information didn't you get from these other topics in here?


4739.0    16.194.208.9::Sharke       6  Year 2000 formal statement required
4216.0    GALVIA::ROCKALL           65  Are we doing anything about the year 
					2000?
3876.0    HLDE01::VUURBOOM_R        48  Who Keels Over New Year's Eve 2000?

Try Vittorio (STAR::) Mezzano.  He has been handling many of these queries.

- Scott

    I cannot understand why they did not use 4 characters for the year to
    produce the format YYYYMMDD from the beginning.  This would surely have
    prevented this year 2000 problem.  What were they thinking of 20-30
    years ago?  Did they either not think of it, or think 30 years is a long 
    time and that their systems would have been well replaced by then? 
    
    Can anyone explain why they chose to adopt the YYMMDD approach as I've been
    hearing this 'Year 2000 problem scenario' ever since starting my IT career 
    8 years ago!

>>    I cannot understand why they did not use 4 characters for the year to
>>    produce the format YYYYMMDD from the beginning.  This would surely have
>>    prevented this year 2000 problem.  What were they thinking of 20-30
>>    years ago?  Did they either not think of it, or think 30 years is a long 
>>    time and that their systems would have been well replaced by then? 
    
>>    Can anyone explain why they chose to adopt the YYMMDD approach as I've been
>>    hearing this 'Year 2000 problem scenario' ever since starting my IT career 
>>    8 years ago!

Using 30% more memory to solve problems in 30 years time is of dubious value even 
today. Can you imagine Microsoft explaining that they require you to have 160MB of 
free disk space today to install NT4.1 rather than the mere 115MB of NT4.0 because 
someone might still be running the system in 2026. 30 years ago the sums made even 
less sense.

30 years ago RAM didn't exist in semiconductor form. Every bit had to be 
constructed from a small ferrite ring positioned in a lattice and three wires had 
to be threaded through each ring in a particular fashion - by hand. (Often the hand 
of a child in the far east.) This made memory a pretty valuable commodity. Even 20 
years ago, upgrading my university's mainframe from 1/2MB to 2MB - in order to 
support the 400 interactive users - cost a year's hardware budget.

Yes, I know that increasing the date size by 30% doesn't imply that the entire 
system size be increased by 30%, but have you ever tried that argument with an IT 
manager? Buying pencils (e.g. 30% too many) is not going to affect the expense 
position of Digital, but just try doing it.

What is less forgivable is that people are still - today - making systems that will 
break at the turn of the century. And, even more are making systems without testing 
whether or not it will manage the change.

Mike.

    <<< Note 4748.4 by ULYSSE::sbudhcp11.sbu.vbe.dec.com::Mike >>> -< not
    really surprising >-

    >>    I cannot understand why they did not use 4 characters for the
    year to >>    produce the format YYYYMMDD from the beginning.  This
    would surely have >>    prevented this year 2000 problem.  What were
    they thinking of 20-30 >>    years ago?  Did they either not think of
    it, or think 30 years is a long  >>    time and that their systems
    would have been well replaced by then? 
    
    >>    Can anyone explain why they chose to adopt the YYMMDD approach as
    I've been >>    hearing this 'Year 2000 problem scenario' ever since
    starting my IT career  >>    8 years ago!

    Using 30% more memory to solve problems in 30 years time is of dubious
    value even  today. Can you imagine Microsoft explaining that they
    require you to have 160MB of  free disk space today to install NT4.1
    rather than the mere 115MB of NT4.0 because  someone might still be
    running the system in 2026. 30 years ago the sums made even  less
    sense.

    30 years ago RAM didn't exist in semiconductor form. Every bit had to
    be  constructed from a small ferrite ring positioned in a lattice and
    three wires had  to be threaded through each ring in a particular
    fashion - by hand. (Often the hand  of a child in the far east.) This
    made memory a pretty valuable commodity. Even 20  years ago, upgrading
    my university's mainframe from 1/2MB to 2MB - in order to  support the
    400 interactive users - cost a year's hardware budget.

    Yes, I know that increasing the date size by 30% doesn't imply that the
    entire  system size be increased by 30%, but have you ever tried that
    argument with an IT  manager? Buying pencils (e.g. 30% too many) is not
    going to affect the expense  position of Digital, but just try doing
    it.

    What is less forgivable is that people are still - today - making
    systems that will  break at the turn of the century. And, even more are
    making systems without testing  whether or not it will manage the
    change.

    Mike.

    

I hate it when 
people forget to 
restrict 
themselves to 80 
characters.

Sorry.

Mike.

    Thanks for that Mike.  The thing is, just look how much money its
    probably costing them now to have it put right, which includes the
    possibility of interruptions to their systems and business.
    
    Denzil

Back in the olden days of computer programming (back when it was still
called programming, rather than engineering), the expectation used to be
that software got rewritten on a regular basis.

I don't think anyone really expected a lot of those crocks to be propped up
on new hardware for so long.

Heck -  a lot of old programs used ONE digit years!  This allowed an entire
date to fit into a 16-bit integer.

			Steve

> Heck -  a lot of old programs used ONE digit years!  This allowed an entire
> date to fit into a 16-bit integer.

  Or even a *12* bit integer!

                                   Atlant

>> Heck -  a lot of old programs used ONE digit years!  This allowed an 
entire
>> date to fit into a 16-bit integer.

>>                        Steve


Ironically, they break less because most of the problems are in a failure 
to cope with subtracting two dates and getting a negative number. This 
occurred frequently with one-digit implementations and so was well catered 
for. Of course, less things could be done, but these were known and not 
attempted and so such implementations rarely cause problems. (Besides, if 
it was going to break it would have done so in 1970, 1980 and/or 1990.)

Mike.

    .10:
    
    1975, not 1978.
    
    I have fond memories of the "DATE75" panic.

>    1975, not 1978.

12/31/77 was the OS/8 "drop dead" date before the 2 bit date extension,
which I presume is what the previous reply was referring to.

Kent:

  I didn't take the reply as arguing with my OS/8-derived date.
  Instead, I assumed they were providing an earlier date than
  my "as early as 1978" and, in mail, I've since confirmed that.

  They were referring to TOPS-10.

  BTW, OS/8 didn't extend the date, they just created a sort
  of sliding 8-year window ending at the current year (which
  was still stored on-disk as a 3-bit field). So, for example,
  on January 1, 1979, all the disk files that used to be dated
  1971 suddenly were dated 1979!

                                   Atlant

> 12/31/77 was the OS/8 "drop dead" date before the 2 bit date extension,

Hmm, my calendar doesn't have the 31 months/year extension. Should I upgrade 
now? 8-)

PJDM

re .15

There are Little endian, big endian and American 
date standard 8-)

/Jojo

    I understand RT-11 will "fall over" in 2004. Does anybody know about
    RSX or RSTS?

    See PROXY::PDP_11 1146.0 onwards for Mentec's statement.
    
    Antonio