Conference 7.286::digital

don't know, but I remember shorty after I came to work in '75 there was a memo
sent out wanting people about 6 digit badge numbers - it seemed a lot of systems
were storing them as a 5 character field!

-mark

    Anyone else remember fixing DATE75 bugs on TOPS10??
    
    /Charlotte

	The number of systems that will up and die at the start of the
21st century is astronomical. I had heard about the company from Washington
state that did "date upgrades" for a living and was not at all surprised.
Think about the poor users, in the small mom & pop shops that might not have
access to their source code!

	What will happen? I view all of 1999 as a "maintenance" year. Business
users don't care to give up valuable enhancement time to have their IS groups
fixing dates. I've raised the issue more than once as an IS person and been
overridden every time. Have faith! The job will get done in all systems that
it needs to get done in. Albeit, a JIT job, however.

Rick

ps. No matter how you slice it, 000101 is not greater than 990101, is it?

    >The number of systems that will up and die at the start of the 21st
    >century is astronomical. 
    
    Actually, these deaths will occur a year before the beginning of the
    21st century.
    					andrew

>>    Actually, these deaths will occur a year before the beginning of the
>>    21st century.

To add to the pedantry, the title of the note should refer to keeling over
either after New Year's Eve 1999 or on New Year's Day 2000.  Few systems will
have much problem going from the year 2000 to the year 2001.

re .5, more likely, few systems will have survived to make the transition from
2000 to 2001!!

The RISKS DIGEST Usenet newsgroup (comp.risks) has a lot of coverage on this,
both the doomsaying and the people preparing for it. I recall one amusing item
abut the Social Security Administration (I think...) starting the work in 1995,
and expecting to complete it within 7 years. Do the math...

    Oh, no, Steve!  You mean our very *government* might become an inept,
    inefficient, archaic pile of dog poo in five years?  I find it
    upsetting that...what?...the newspaper?...sure, I'll read...
    
    Umm, Steve?  Never mind.
    
    								Tex

    ALl this has already happened in the past, albeit on a somewhat smaller
    scale. Prior to 1970, many systems used 5-digit dates (YMMDD). They
    were smaller if stored as character and fit perfectly into a 3-byte
    packed decimal format (as opposed to YYMMDD which "wasted" half a
    byte).
    
    Did we learn anything? No way. We just upgraded to 6-digit dates and
    assumed someone would rewrite the bloody thing before 1999. Well they
    did, but by then they'd forgotten the 1970 madness, and the new system
    had YYMMDD dates, too.
    
    The only consolation is that a lot of VMS and UNIX systems will come
    through the whole thing unscathed, as both operating systems have
    extended date formats built in.
    
    \dave

    I discovered this whole discussion is pointless last night.  While
    standing in line at the grocery store, I noticed the headline on the
    Weekly World News:
    
    Judgement Day will be Dec 31, 1999.  So, no need to get concerned about
    date conversions.

      See also topics 220, 147 in MILORD::WAR_STORY for fun with end of the
    century dates, and the (in)famous response to an SPR about 2000 being a
    leap year. Press <KP7> to add it to your notebook.
    
    Ken

  I am confident that most of our software products can handle this. My con-
cern is about third-party products that we sell. If it has the Digital name on
it and it dies on 1-1-2000, we will get the blame whether or not it is "our"
product.
  I think there is going to be major chaos in the weeks following 1-1-2000 due
to the date problem. And by that time we will be so dependent on computers that
all sorts of vital systems will break down: telecommunications, banking, retail
store checkouts, etc, etc. I am assuming that 99% of the computers and software
systems that are in use then will be able to handle this, but the other 1% that
fail will be a large enough number to cause major trouble.

  This topic is also discussed at CDSRV::ASKENET_V5, note 763.
  If you don't already have this conference in your notebook
  and would like to add it, press <KP7> or <Select> or type
  "SELECT" and the conference will be added to your notebook.

                                   Atlant

    I've told my standalone workstation it's 2006, which has a similar
    calendar to 1995. So far, no problems. DECW$CALENDAR runs just fine,
    along with various other utilities like PCDISK.
    
    You'd think there would be some SI revenue in here somewhere, say
    setting up a system or cluster similar to a customer environment,
    installing the apps and databases, then rolling time forward.
    
      John

    The Sunday paper had a front page story that reminded me of this topic. 
    Gartner was again quoted, they say that $100B will be spent on this and
    that there is a potential that all available manpower may be working on
    projects to get ready for the day...
    
    Mark

    I seriously doubt the supposed extent of this "problem" (90% - get real!).
    
    Most mortgages last 30 years.  The software that handle these would
    have broke in 1970.  I recently worked on some Dept of Ed. student
    loan software.  As a good example, they still store only 2 digit years 
    and have simple logic tricks (like those mentioned in .8 or .9, etc.) 
    to handle century rollover:
    
        If   two_digit_year > 50
        then real_year = 1900 + two_digit_year
        else real_year = 2000 + two_digit_year
    
    So don't think you/your_child will be able to stop paying back the loan 
    in 4.5 years  :-)
    
    I'm in Digital SI and have been writing application software for 
    about 20 years.  I have seen/worked on about 2 dozen sizable software
    applications with about a dozen customers, and have never seen one yet
    that mishandles dates in such a way that it will break when the 
    century odometer rolls over.  
    
    There is little requirement to HAVE to store a full 4 digit year.  
    Most dates could be offset from a starting point (such as 17-Nov-1858
    in VMS 64-bit date routines).  Most events that need to be tracked 
    will NOT span 100 years.  Dates can be compressed, etc.  Any programmer 
    who can't handle this isn't worth their salary.  Pick up a copy of 
    Knuth's Numerical Algorithms, for plenty of good techniques for 
    this type of thing.  
    
    This type of press ("All software will die in 4 years", 
    "Every programmer on planet Earth will spend all of 1999 fixing this")
    is fit for grocery store tabloids and to scare the uneducated masses.
    In a word - it sells better than an article titled "Most Software will 
    easily handle the 1999-2000 date transition".  The fact that Gartner 
    is espousing this garbage is not surprising to me.  The newsletters
    will readily print anything sensational, even if it's baseless.  
    
    While I'm sure that Digital SI can leverage some consulting business 
    to a few sites that may need additional manpower to update/check/test 
    their date handling source code routines, it certainly doesn't need 
    to be marketed as a scare tactic.  But I seriously doubt the extent or 
    need for this, based on my personal experience with other companies code.  
    
    But, I'll put an entry in my electronic calendar to re-check this note 
    in January 2000 - just so I can reply "I told you so" - 
    assuming, of course, that my calendar software still works then...  ;-)

    
>    But, I'll put an entry in my electronic calendar to re-check this note 
>    in January 2000 - just so I can reply "I told you so" - 
>    assuming, of course, that my calendar software still works then...  ;-)
    
    Or come to think of it this Notes conference :-)

> Or come to think of it this Notes conference :-)

If NOTES did the smart thing and used the quadword date, it should be good until
around the year 5001.

This problem may be much easier to solve if we all standardize on Alpha and
OpenVMS and Digital Unix.

Then at least there will only be one set of operating systems to fix.

Tom

>If NOTES did the smart thing and used the quadword date, it should be good until
>around the year 5001.
    
    Who Keels Over New Year's Eve 5001 then? :-)

>    Who Keels Over New Year's Eve 5001 then? :-)

The date doesn't roll on new years eve as I recall.

> The date doesn't roll on new years eve as I recall.

It needs to *start* rolling on New Year's Eve to have built up 
sufficient momentum by midnight.

    isn't New Year's Eve 4999 the important one?
    
    ed

Paul:

> NET$TIME_VELOCITY

  Please *DON'T* adjust that parameter. It's really comfortable
  for all of us when set to about 1,000 miles/hour / 1667 km/h.
  If you turn it up much higher than that, the people near the
  equator will all get flung off the planet.

                                   Atlant

> Paul:
>
> > NET$TIME_VELOCITY
>
>   Please *DON'T* adjust that parameter. It's really comfortable
>   for all of us when set to about 1,000 miles/hour / 1667 km/h.
>   If you turn it up much higher than that, the people near the
>   equator will all get flung off the planet.

Who would want to unilaterally adjust it?

The speed of time is best set to one second per second.

(Note that this is local time.  There is no
 universal coordinated time possible; even that 
 which we parochially call UTC is a local time).

> The speed of time is best set to one second per second.

    Hmmm, and as the speed of time approaches the speed of light does
    relativity kick in to slow time down? At some point the time
    acceleration is going to be balanced by the time slowdown and where
    does that get you then? With a lot of heavy time on your hands?

    RE: .26  (non-adjustment of NET$TIME_VELOCITY parameter...)
    
    It is my understanding (albeit limited) that there have been several
    cases within the past few years where California hackers were able to
    break into systems and slightly alter the value for this parameter,
    thus causing earthquakes of various scale.  Because of the easterly
    rotation of the planet, the effects were generally localized to the
    U.S. west coast and/or out over the Pacific up to the point where the 
    International Date Line acted as a buffer and dissipated the force.  
    However, this January, a major hacking event occurred on the world wide 
    web, was able to circumvent the IDL, and created the devasting quake 
    in Kobe Japan.  I remember reading this in the Weekly World News 
    (which can be purchased in 7-11's, Krogers, A&P's and other high quality 
    reading establishments) but I think the major news media has been placed
    under a gag-order by the CIA to prevent this information from falling
    into the hands of Bosnian Serbs armed with 386's and modems.

	...?!

Chris.

    Ya know, I always *knew* there were a few of those system parameters it
    was better just not to mess with...

    Of course, we could add a new lexical function to VMS,
    F$ADJUST_REALTIME, and have it do more work in less time. Saves
    purchasing faster Alpha chips
    
    Alan

    I think it's ok if you make the /SPECIAL_OVERRIDE switch the default.
    
    Laurie.

re .30

hmm...Conspiracy theories abound.  Sounds a tad simplified to me.

>> hmm...Conspiracy theories abound.  Sounds a tad simplified to me.

Egad, these conspiracy theorists are plotting to take over the world!

						Brian

    For the purists, Digital will actually start to enjoy the effects of
    the 2000 problem 6 months earlier.
    
    As I ask the oft repeated question ..... "Is that fiscal 2000 or
    calendat 2000 ?"

I think that all of these problems can be avoided by the age old (and 99%
successful) operator's fix of `er, try turning it off and back on again,
and see what happens...'

Chris.

Of course, UNIX systems will keel over permanently about 30+ years later...

PJDM

>Of course, UNIX systems will keel over permanently about 30+ years later...

they'll be okay, with the advent of 64-bit integers for timestamps.  Unix
will be around forever, to the eternal disdain of many... :)

Chris.

    Re .39
    
    Digital UNIX already uses a 64-bit value for time.

    
    I got a call from a Digital Sales rep looking for help with this
    "year 2000" issue.
    
    She has an account that's looking for some type of certified letter
    from all their software suppliers that the year 2000 won't be a
    problem.
    
    Does anyone have any recommendations on getting such a formal
    commitment from Digital that I can relay to her?
    
    Thanks,
    
    	-John

    Lotsa luck.  Nobody seems willing to accept responsibility for this
    on a corporate basis.  It appears that our PR department didn't
    forward Tim Ellison's letter about VMS to Datamation.
    
    What platform does the customer use and what specific Digital
    products?  You can probably get a statement by asking the individual
    product groups.
    
    					Steve

    
    RE: .-1,
    
    Just heard back from the Sales rep.  Platform is OpenVMS, with ALL-IN-1, 
    Pathworks, DECnet, and Teamlinks.
    
    She thinks a letter just covering OpenVMS will suffice. 
    
    I haven't seen Tim's letter - can you provide a pointer?
    
    Thanks,
    
    	-John

VAXAXP::VMSNOTES 60.17.  You may want to contact Tim Ellison directly.

			Steve

    There is a formal Digital UNIX response in the TURRIS::DIGITAL_UNIX
    notesfile.  Note #4628.1
    
    Why can't we provide a statement that covers both OVMS and UNIX ? 
    Seems like a disconnect.

Re: .46

Because nobody at the "corporate" level is willing to lift a finger to make
it happen.

				Steve

    Thanks Steve. Will do. -J