Conference evms::y2k

    re .0
    
    It would be helpful to provide the note number that makes this claim or
    a URL.

    
    Sorry. This notes file notes 12.3 and 12.4. On the web
    http://www.digital.com:80/year2000, go down 
    "OpenVMS and the Year 2000/Millennium", read the paragraph
    "You Can Test TODAY for Year 2000/Millennium with OpenVMS"
    
    /�ke

    re .0,.2
    
    It looks like a fair question. In the absence of an answer from the
    author I would suggest that while setting the time to the future is
    allowed by most if not all operating systems, not all of them then
    continue to operate normally. In fact I thought that if one had DECnet
    (some flavour) one couldn't do this under VMS either i.e. without
    unintended side effects.

Re: .0

In general, several mainframe systems do not allow this simulation, 
beacuse of problems present in the OS or in the system firmware.

The istuation with NT and Windows is not clear, expecially PCs with
old BIOS regularly run into trouble when doing this.

UNIX systems, also, in many cases do not allow the setting of the 
system clock to the year 2000 and beyond. 
This is true for Digital UNIX as well, and the problem has been 
fixed only very recently (september 1996) as part of the Year 2000
effort.

From this point of view, the advantage of OpenVMS is that it allows 
the simulation of the transition to the year 2000 without needing
additional patches, and without having to upgrade to new versions.

re: .3

I know of some customers of ours condicting the simulation without
problems, and they had DECnet running.
Can you please describe what kind of side effects may happen?

Thanks,

	Vittorio

re .4
    
>I know of some customers of ours condicting the simulation without
>problems, and they had DECnet running.
>Can you please describe what kind of side effects may happen?
    
    OK, I admit that I couldn't find the original note in which I read
    about this. However some trawling brought to light some relevant notes.
    One needs to distinguish carefully whether the problem affects setting
    the time back or forwards or both. All problems can presumably be
    avoided by setting the time forward before system startup e.g. using
    the SYSGEN parameter TIMEPROMPTWAIT and rebooting to set the time back,
    again using the SYSGEN parameter, but that may undermine the message
    that triggered the base note of this topic.

    Before referencing the relevant notes and with the disclaimer that I am
    not familiar with the internals of any of our network protocols here is
    a general scenario in which network problems may occur.
    
    Let's say some network protocol requires the network software e.g. to
    generate a "hello" message every X seconds. If that software does that
    by adding X to the current time (having just sent a hello message) and
    waiting until the time reaches this value (possibly using operating
    system timers directly or possibly via other means) and during that
    interval of X seconds the time is set back by a large amount (typically
    one hour for daylight savings purposes but possibly a lot more during
    year 2000 testing) then the scheduled event will occur very late (by
    the amount that the time was set back) and hence network timeouts can
    occur. Other machines may see the year 2000 testing machine as
    unreachable until the time again reaches its "highwater mark" on the
    testing machine.
    
    (One can imagine similar problems with timeout waiting for a response
     from a remote machine when the time is set forward but I haven't seen
     that discussed. Possibly there are enough retries so that a single
     incident of setting the time forward does not cause a problem.)
    
    Time set back apparently was a problem with DECnet Phase IV but was fixed
    a long time ago (VMS V5.0?) and so probably won't affect many customers.
DECNET topic 226
    
    The problem seems to have crept back into DECnet Phase V and is allegedly
    fixed in V5.7. It's a problem in the LES component whatever that is.
DECNET-OSI_FOR_VMS topic 962
    
DECNET-OSI_FOR_VMS topic 2480
    is unanswered but suggests that the VOTS component also has problems in
    this area.
    
MARVIN::SYNC_DRIVERS topic 424
    indicates that V1.2 of the WAN Device Drivers has a problem with the
    time being set *forward* but there is no indication whether this has
    been fixed.
    
    And finally
DECNET topic 5827
    talks about the DAP specification bug that leads to problems in this
    area but this is already covered by note 27.7 in this conference (and
    is not directly relevant to the intent of this note).

re: .5

I think that your points are correct, but anyway, these concerns
are addressed by the testing steps that are clearly specifying
that the simulation should not occur in a production environment 
(which include systems connected to others via some network) and
that all disks must be backed up before the session and restored
afterwards.

Testing steps can be found in 12.5.

    re .6
    
    In addition to the steps you mention it is probably simpler just not to
    start any network software on the machine being used for Y2K testing
    unless you need it. Unfortunately virtually any client/server
    application will need the net to be available and then one needs to
    account for the issues raised in .5. Additionally, due to distributed
    time protocols one might need an island in the network just for Y2K
    testing.

    additional to .5
    
    The reference in .5 to note 27.7 should now be to note 38.7 as a
    result of conference reorganisation.