y2k compliant version of openvms
stm...@my-deja.com
Can anyone tell me what the first y2k compliant
version of openvms is - we have a legacy vax
4000/300 system that will be replaced soon but not
before year 2000. We are currently running v6.0
but have v6.1 - v7.1. Without maintenance support
I want to give the best chance for layered
products to work also.
Steve Munro
Prog/Analyst
WV geol survey
Morgantown, wv
Sent via Deja.com http://www.deja.com/
Before you buy.
Richard B. Gilbert
patch is applied. VMS V7.2 is compliant without patches. VMS V7.1 may
need a patch; I'm not sure and I'm too lazy to try to figure it out at the
moment.
For minimum disruption, I would suggest VMS V6.2; it's a good
release with a long track record. There are known problems but there are
also patches for them.
If you want a supported release, I would suggest V7.1-1. V7.2 hit
the streets fairly recently and doesn't have much of a track record yet.
Message text written by INTERNET:stm...@my-deja.com
Arne Vajhøj
> Can anyone tell me what the first y2k compliant
> version of openvms is - we have a legacy vax
> 4000/300 system that will be replaced soon but not
> before year 2000. We are currently running v6.0
> but have v6.1 - v7.1. Without maintenance support
> I want to give the best chance for layered
> products to work also.
VMS 7.2 is Y2K compliant out of the box.
There are Y2K patch kits for VMS 5.5-2, 6.2 and 7.1.
So if you want your VMS to be official Y2K compliant,
then upgrade to 6.2 and install the Y2K patch (should
be relative simple).
Note the word "official". Actually VMS of any version
has very few Y2K problems and only in obscure and
very seldom used corners. So the risk for actual
getting Y2K problems with any VMS version is
not that big.
Arne
JF Mezei
> Note the word "official". Actually VMS of any version
> has very few Y2K problems and only in obscure and
> very seldom used corners.
Or it simply means that Digital/Compaq did not bother doing certification
testing on older versions hence they were not declared Y2K compliant. It does
not mean that the system will crash.
Mr Loether, during is presentation in Montreal a couple months ago, stated
that VMS was Y2K compliant from the beginning in the 80s because of the way it
stores dates (those quadwords containing nanoseconds since the Smithsonian time).
I think that Y2K problems in 5.5-2 are related to the monitor utility.
More importantly, was the May 1998 (?) critical date when those quadwords
started to exceed 24 bits and it was found that some system routines had
assumed that dates were 24 bits long when doing some manipulations and patches
were made available. That was VMS's "Y2K" problem.
Arne Vajhøj
> Arne Vajhřj wrote:
> > Note the word "official". Actually VMS of any version
> > has very few Y2K problems and only in obscure and
> > very seldom used corners.
>
> Or it simply means that Digital/Compaq did not bother doing certification
> testing on older versions hence they were not declared Y2K compliant. It does
> not mean that the system will crash.
They have tested 5.5-2, 6.2 and 7.1 and made patches for them.
The patch cover letter describe the bug fixed.
Those bugs looks as if they have been present in earlier versions
as well.
> I think that Y2K problems in 5.5-2 are related to the monitor utility.
No. I think it is mostly related to ODS-1 support !
(and the number of VMS sites with disks in ODS-1 format today is
probably relative small !)
Arne
Hoff Hoffman
In article <384775FE...@videotron.ca>, JF Mezei <jfmezei...@videotron.ca> writes:
In regard to the initial question, please see the Y2K section in the
OpenVMS FAQ. This Y2K question has been discussed a number of times,
and many of the answers have been collected the answers together to
make it easier for all folks involved in the discussion.... Thanks!
:Arne Vajh=F8j wrote:
:> Note the word "official". Actually VMS of any version
:> has very few Y2K problems and only in obscure and
:> very seldom used corners. =
:
:
:Or it simply means that Digital/Compaq did not bother doing certification
:testing on older versions hence they were not declared Y2K compliant.
"Bother" would not be my choice of words here -- the effort in doing
the full Y2K readiness evaluation was non-trivial. In fact, the Y2K
readiness review was a very large project involving a large number of
engineers, and for quite some time... Those releases that we offer
support for -- either current or prior version -- were evaluated...
:It does not mean that the system will crash.
It also does not mean that the system will NOT crash.
The recommendations are to test for readiness, and the recommended Y2K
tests are referenced in the OpenVMS FAQ...
:Mr Loether, during is presentation in Montreal a couple months ago, stated
:that VMS was Y2K compliant from the beginning in the 80s because of the
:way it stores dates (those quadwords containing nanoseconds since the
:Smithsonian time).
The underpinnings have been ready since the inception of the operating
system, back prior to 1978. The OpenVMS quadword base date is in units
of centiseconds (100 nanosecond units) since midnight on 17-Nov-1858.
(The Smithsonian Astrophysical Calendar base date...) This quadword
format will overflow sometime in the 32nd millenium or so, IIRC...
:I think that Y2K problems in 5.5-2 are related to the monitor utility.
I'd suggest reading through the V5.5-2 Y2K ECO kit notes...
:More importantly, was the May 1998 (?) critical date when those quadwords
:started to exceed 24 bits and it was found that some system routines had
:assumed that dates were 24 bits long when doing some manipulations and
:patches were made available. That was VMS's "Y2K" problem.
I suspect this was a reference to is the 10,000 delta-time limit, when
certain layered products performing date calculations reached a fully
documented hard limit in the delta-time date storage format, and broke.
This date conversion involved the conversion of text-format dates using
documented calls (eg LIB$CVT_TO_INTERNAL_TIME and LIB$FROM_INTERNAL_TIME),
and 10,000 days since 1-Jan-1970. The limit was reached on 17-May-1997.
For details on this and on the specific changes made, please see the
VAXLIBR050_070 and ALPLIBR050_070 (or later) ECO kit documentation.
The media is currently quite obsessed with Y2K, I think because they can
think they understand it and can use it to sell stuff. 1/2 :-) There
have been similar date roll-overs in various systems over the years, and
more in the future... For example, back in August 1975, 22-Aug-1999,
17-May-1997, Year 2003, 19-Jan-2038 03:14:07 GMT, Year 2057, Year 2076,
Year 10000, and at various and sundry other dates. (Answers below.)
And with the various sliding window and related fixes for Y2K, we'll now
be seeing these date bugs arising at seemingly random intervals in random
applications into the forseeable future...
--
The answers: TOPS roll-over, GPS, 10K Delta-time, RT-11 on-disk date
format (OpenVMS EXCHANGE utility), C signed time_t overflow, OpenVMS
transition year, C unsigned time_t overflow, and the DCL lexicals and
text-format date-related system service conversions... (I plan to
supplement my retirement income with Year 2038 fixes and consulting. :-)
--------------------------- pure personal opinion ---------------------------
Hoff (Stephen) Hoffman OpenVMS Engineering hoffman#xdelta.zko.dec.com
Tim Shoppa
For example, back in August 1975, 22-Aug-1999,
> 17-May-1997, Year 2003, 19-Jan-2038 03:14:07 GMT, Year 2057, Year 2076,
> Year 10000, and at various and sundry other dates. (Answers below.)
> The answers: TOPS roll-over, GPS, 10K Delta-time, RT-11 on-disk date
> format (OpenVMS EXCHANGE utility), C signed time_t overflow, OpenVMS
> transition year, C unsigned time_t overflow, and the DCL lexicals and
> text-format date-related system service conversions... (I plan to
> supplement my retirement income with Year 2038 fixes and consulting. :-)
*I* for one was very happy to see that the RT-11 date word extension
(which takes it through 31-Dec-2099), originally documented in the
RT-11 5.5 manuals (late 80's), finally made its way into VMS
EXCHANGE as of V7.2.
There is another date format of note to EXCHANGE users: DOS-11
EXCHANGE tapes and disk volumes use a datestamp of the form
; WORD 1: BIT 15=0 IF LINKED, 1 IF CONTIG
; BITS 11-0 ARE THE DATE AS 1000*(YR-1970)+DAY
Since bit 15 isn't available for the datestamp if a file is moved
to/from a disk volume, this will run out
after the end of 2002. I haven't yet examined the latest VMS
EXCHANGE to see what it does after that.
--
Tim Shoppa Email: sho...@trailing-edge.com
Trailing Edge Technology WWW: http://www.trailing-edge.com/
7328 Bradley Blvd Voice: 301-767-5917
Bethesda, MD, USA 20817 Fax: 301-767-5927
Uwe Zessin
JF Mezei <jfmezei...@videotron.ca> wrote:
> Mr Loether, during is presentation in Montreal a couple months ago,
> stated that VMS was Y2K compliant from the beginning in the 80s
> because of the way it stores dates (those quadwords containing
> nanoseconds since the Smithsonian time).
The counter has a resoultion of 100 nanoseconds, not 1 nanosecond.
> I think that Y2K problems in 5.5-2 are related to the monitor utility.
>
> More importantly, was the May 1998 (?) critical date when those
> quadwords started to exceed 24 bits and it was found that some system
> routines had assumed that dates were 24 bits long when doing some
> manipulations and patches were made available. That was VMS's "Y2K"
> problem.
JF,
you should not make guesses when it comes to OpenVMS' binary format ;-)
$ python
Python 1.5.2 (V006a, Mon Nov 15 14:23:53 1999) [DECC] on OpenVMS
Copyright 1991-1995 Stichting Mathematisch Centrum, Amsterdam
portions Copyright 1996-1999 Uwe Zessin
>>>
>>> import vms_sys
>>>
>>> print vms_sys.asctim (0x1000000L) # 24 bits
17-NOV-1858 00:00:01.67
>>>
>>> print vms_sys.asctim (0x100000000L) # 32 bits
17-NOV-1858 00:07:09.49
>>>
A little 'bit' off, right?
---
What you were thinking about, I beleive, is the 10k day problem that
started on 19-MAY-1997 (how time goes by...)
That date is exactly 10000 days after the common UNIX time origin
of 1-JAN-1970. Several LIB$ routines did raise a (documented) error
code when the delta time was equal or greater than 10000 days.
>>> x1 = vms_sys.bintim ('01-JAN-1970 00:00:00.00')
>>> x2 = vms_sys.bintim ('9999 23:59:59.99')
>>> x3 = vms_sys.bintim ('0 00:00:00.01')
>>> print x1, x2, x3
35067168000000000L -8639999999900000L -100000L
>>> print vms_sys.asctim (x1 - x2 - x3)
19-MAY-1997 00:00:00.00
>>>
But even this has very little to do with 24 bits:
>>> print hex (vms_sys.bintim ('9999 23:59:59.99'))
-0x1EB208C2DA7960L
>>>
---
I still have the cover letter from FEB-1997 on my desk, because
I need to install V6.2(-x) systems from time to time.
--
Uwe Zessin
Jan Vorbrueggen
> 17-May-1997, Year 2003, 19-Jan-2038 03:14:07 GMT, Year 2057, Year 2076,
Errr. 2038-1970=68;2038+68=2106, not 2076. Tsk, tsk...
I'm gratefull that it is highly unlikely I'll be around to be forced to
resolve the 2106 issue (I'd turn 145 that year), because I think it'll
be a really BIG one (much larger than that simple Y2K stuff, methinks).
As Hoff says, 2038 will be a good way to supplement our retirement income.
Jan
mike menard
mostly patches driver for 11 type files and c run time lib
mike menard
systems and data admin
stanley aviation
"Arne Vajhøj" <Arne.V...@gtech.com> wrote in message
news:38476E88...@gtech.com...
> stm...@my-deja.com wrote:
> > Can anyone tell me what the first y2k compliant
> > version of openvms is - we have a legacy vax
> > 4000/300 system that will be replaced soon but not
> > before year 2000. We are currently running v6.0
> > but have v6.1 - v7.1. Without maintenance support
> > I want to give the best chance for layered
> > products to work also.
>
> VMS 7.2 is Y2K compliant out of the box.
>
> There are Y2K patch kits for VMS 5.5-2, 6.2 and 7.1.
>
> So if you want your VMS to be official Y2K compliant,
> then upgrade to 6.2 and install the Y2K patch (should
> be relative simple).
>
> Note the word "official". Actually VMS of any version
> has very few Y2K problems and only in obscure and