Thanks to the following for taking the time to respond:
alan_at_nabeth.cxo.dec.com_nospam
steve_at_eiscat.ag.rl.ac.uk_nospam
NMH1_at_axprl1.rl.ac.uk_nospam
sher_at_altek.com.my_nospam
alastair_at_ilo.dec.com_nospam
Phil.Richardson_at_nts.hl.siemens.de_nospam
sfrankl_at_nswc.navy.mil_nospam
huehlsm_at_indy.navy.mil_nospam
rjackson_at_portal.gmu.edu_nospam
PAUKIT_at_HBSI.COM_nospam
treahy_at_allianceelec.com_nospam
tpb_at_zk3.dec.com_nospam
rlm_at_syseca-us.com_nospam
Most people said that the first version of DUNIX which will be certified
to be Y2K compliant is version 4.0D, coming out in November. Some
pointed out the specific problems I'll be seeing with the date command
(found that out myself), SCCS and RCS, and maybe others, which use only
the last 2 digits of the year. If my system is left alone, its clock
will flip over to 2000 by itself at the end of 1999, but i will have no
way to directly reset the year if the clock should be lost. A couple
folks suggested that I upgrade from OSF/1 1.3B to something more modern,
as DEC no longer supports that version. It is most definitely NOT Y2K
compliant. I'm using CAM to talk to some custom hardware we built, and
I'm still fighting a CAM problem that crashes the later versions of the
OS (2.0 and above), and I'm not certain that the 3rd party supplier of a
TC board I'm using has a driver for DUNIX 4.X.
Many listed the DEC site:
http://www.software.digital.com/year2000
for full information on what DEC is doing about Y2K compliance, as well
as other issues related to time functions on DUNIX.
Also, the internal time structure (time_t) still uses a signed 32 bit
integer to count seconds, so if it's kept this way for the next 41
years, wierd things will happen in 2038. Of course, I think that's one
of the things that DEC (and the rest of the industry) will address as it
fixes other time related problems.
thanks again for all the responses.
eyc
Received on Fri Oct 17 1997 - 15:10:37 NZDT