Support: North Ridge Reports

Look out for September 16, 2042

Originally published: Winter 1998

We know, we know! Everyone is abuzz with the importance of the end of this century (the end of 1999). The inevitable, upcoming change to the Year 2000 has gotten the entire data processing world concerned about how many of their systems will fail to operate properly.

Most NRS clients have active "projects" to track, monitor, and test their entire system for compliance with the change of the century. NRS Year 2000 status' and approach has been documented for some time and we will continue to respond to your inquiries about The Network Center's and The Network Director's abilities to handle the Year 2000.

We certainly do not want to minimize the importance of these projects. BUT, for system level type products (operating systems, VTAM, NRS products, etc.), there is a far more significant time based problem ahead. We refer to it as the Year 2042 problem.

This is because most software subsystems (including NRS products) use the System 390 64 bit internal clock to compute calendar dates and precise times. The Time Of Day (TOD) clock is a binary counter with bit positions numbered 0 to 63, corresponding to the bit positions of a 64-bit unsigned binary integer.

The TOD clock is incremented by adding a one in bit position 51 every microsecond (source for most of this is IBM's ESA/390 Principles of Operation - SA22-7201).

The following table lists a few of the key 64 bit combinations and how they relate to calendar dates:

Somewhere around midnight on September 16, 2042 the TOD clock will . . . . . do something. Will your software systems be ready to handle that? What will happen to those systems relying upon the TOD clock constantly increasing and having a binary value "larger" than a preceding "date stamp"? After September 2042, the TOD clock won't be larger than it used to be!!!!

Again, we don't want to underestimate the importance of the Year 2000, but the NRS products have basically been prepared to deal with the technical aspects of the Year 2000 since their initial creation. Dealing with the Year 2042 is still not taken care of within either The Network Center (1.7.5) or The Network Director (4.2.3).

Is this a BIG problem?

NO! There are all sorts of potential corrections to this particular issue (EPOCH specifications, Coordinated Universal Time - UTC, etc.). NRS believes that some fundamental changes will be made (by IBM) to the recommended processing of the TOD clock in the System 390 hardware many years before the actual year of 2042. Seems to us that this is likely to be dealt with early in the next century after the activity associated with the Year 2000 has died down. Then, all the software vendors (including NRS) using the TOD clock for date and time related functions will have to correct their routines to manage beyond the Year 2042 properly. We expect this to occur years ahead of the actual year 2042, which means that it is unlikely the Year 2042 will be much of an issue.

BUT, the Year2042 and the TOD clock technical issues are much more significant to NRS' products than the Year 2000. Perhaps you can tell that we'd recommend you avoid setting your system's clock to a value after September 16, 2042 for the next couple of years (a need for this doesn't arise too often!!). No action on your part is required to deal with the Year2042, we'll fix the software well before it is necessary.

That is, if VTAM and the NRS products as we now know them are still around in the year 2042?