2014/11/25

Date and Time

Recently we had a discussion at work about unique file names. OpenVMS has facilities for that, like the lexical F$UNIQUE in DCL and tmpnam in the C Runtime Library. However, people tend to write their own functions for this. No problem of course. One of the solutions in DCL is e.g. taking a combination of the PID and date/time. I might spend a post on that later, but you might find some implementations on Google.

We talked about the OpenVMS Date/Time, and the time base used in OpenVMS: November 17, 1858. Then someone wanted to know what was so special about that date, and if  issues were to be expected on OpenVMS with date/time.

Kevin G. Barkes describes it in  DCL Dialogue Online 199111:
The short story is the Smithsonian Astrophysical Observatory adopted the Modified Julian Day (not related to the Julian calendar) in 1957 for satellite tracking purposes. January 1, 1957 was Julian day 2,435,839. The 8K, non-virtual 36-bit IBM computer used by the SAO kept the Julian day in the left 18 bits of a 36-bit word, and the hours and minutes in the right 18 bits of a word. The problem was the octal representation of Julian day 2,435,839 would have required 22 bits, wasting 14 bits of precious memory.

So, the SAO decided to settle on using 18 bits to represent what was called the Modified Julian Day. From November 17, 1858, this permitted 700 years of timekeeping. Using 17 bits allowed 300 years, plus one bit to allow for representing negative time. No star  catalog used by SAO was older than 1858, so 11/17/1858 was picked as the starting date.

There is also a pretty detailed article on OpenVMS Ask The Wizard.

The Modified Julian Day allows OpenVMS to handle dates through a little before three in the morning on July 31, 31086. That's when the 63-bit absolute time representation within VMS goes negative and all VMS time operations halt (Source: DCL Dialogue Online 199111).
That does not mean that there were/are no other issues with date/time on OpenVMS. These are the ones I know of:

There was the 10,000 day limit in LIB$CVT_TO_INTERNAL_TIME causes problems for DECthreads since it is using this routine to convert Unix times to VAX time. It will fail to work on 19-May-1997. I had problems with this one in 1997, when running the OSU HTTP Server. The VAXStation 4000 running the HTTP server would become very slow when the HTTP Server was running, since it relies on DECthreads. After installation of the patch, the problem disappeared.

Issues regarding Y2K have been dealt with in the Year 2000 response (Source: OpenVMS Y2K FAQ).

The first possible problems with date/time on OpenVMS can be expected in 2038. In 2038 problems can occur with the C time_t structure. OpenVMS dealt with this problem in 1998, in the Year 2000 response, postponing the issue to 2106 (Source: OpenVMS Year 2038). That still leaves at least 24 years to fix applications. Recompiling on the current OpenVMS release will give time to 2106 to solve this problem. So we are safe for another 92 years.

The next problem will occur December 10, 5941. Someone reported a bug on DSNlink in the F$CVTIME() DCL lexical function and the LIB$DAY_OF_WEEK RTL routine. The functions will report the wrong day of the week, due to a problem in the time calculation algorithm. The routine counts the number of 100 nanosecond intervals from midnight on 11/17/1858, which is stored in a 64-bit quadword. This number is divided by 600 million to convert it to minutes, and the result is stored in a longword value. From that date to 12/10/5941 is 7FFFFF80 (hex) minutes, only a little over two hours away from a longword integer overflow error. Fortunately, the bug has been reported to VMS Engineering (Source: DCL Dialogue Online 199111). I have no clue if this has been fixed already, but I might not be around to encounter the bug anyway.

Another minor problem is the fact that all of OpenVMS' time-related displays and routines can only display four digits in the year field, but the maximum year OpenVMS can handle is 31086. There is still time to fix this :-) before 31-DEC-9999 (Source: DCL Dialogue Online 199111). Maybe VMS Software Inc. will do so.

As you can see, if the issues are resolved in time, OpenVMS can run at least another 29072 years.

No comments:

Post a Comment