management: Is z/OS In Trouble in 2038?
On January 19th, 2038, any program storing a UNIX timestamp as a 32-bit signed integer will have a problem: it will think it is 1901. The reason is simple: the number of seconds since 01-Jan-1970 will no longer fit into that signed integer. UNIX users are well aware of this 'Y2K38' problem. But z/OS users are also at risk. Let's see how.
z/OS and UNIX
As z/OS is a POSIX-compliant UNIX system, the operating system itself is the first thing to think about. The good news is that z/OS UNIX has been 'Y2K38 resistant' for quite some time. z/OS features storing datetime values like those for z/OS UNIX filesystems have been able to handle dates beyond 2038 since z/OS 2.3, released in 2017. IBM announced that from z/OS 2.4 (released in 2019), all application APIs should support 2038.
z/OS Language Environment has its own unique way of working with dates and times. For example, the CEELOCT service returns the local date and time as a Lilian date (days since 14 October 1582), Lilian seconds (seconds since 14 October 1582), or a Gregorian date string (e.g. 2025021513113). So, no Y2K38 worries there.
Other z/OS components work with z/OS UNIX but are also OK. For example, the REXX function convdate converts a date to a z/OS UNIX datetime and has supported dates past 2038 for some time. Similarly, RACF was updated in z/OS 1.12 to handle digital certificates that expire after 2038.
However, it looks like there may be some work for IBM to finish. For example, as of z/OS 3.2, the Communication Server Policy Agent has problems with dates beyond 2038.
Programming Languages
The next big-ticket item are programming languages. By themselves, COBOL and PL/I are unlikely to be an issue: they don't internally store dates as UNIX datetimes. COBOL 'Gregorian' dates are an integer holding the number of days since 31-Dec-1600. COBOL date functions like CURRENT-DATE usually return strings, not integers.
Similarly, the PL/I functions DATE and DATETIME return strings, not integers. To be hit by Y2K38, COBOL and PL/I functions must get a UNIX datetime stamp from somewhere else: perhaps from another (C/C++) program, database, or file.
C and C++ are different. C/C++ datetime functions such as gettimeofday() return a UNIX datetime value. 64-bit programs are fine: the UNIX datetime stamp is returned as a 64-bit integer. 31-bit programs need a solution.
Most C compilers have changed time-related functions to return a time_t value that is larger than a signed 32-bit number. For example, Dignus System/C made this change from version 2.1 of its C compiler, and SAS from version 7.50 of their SAS/C. The flipside is that users must recompile their programs with these later compiler versions for this solution to work. Programs using integers instead of the time_t structure will need modification as well.
IBM, with its XL/C and C++ compilers, has provided a different path. They have introduced (non-standard) 64-bit versions of time functions for 31-bit C/C++ programs, such as gettimeofday64 (introduced in z/OS 1.12 in 2010). APAR PK83212 explains this better. This means that existing XL/C and C++ programs can either be recompiled as 64-bit or must be modified to use the 64-bit time functions.
Like C and C++, 64-bit Java programs are also OK, but 31-bit programs may need a quick check. IBM Java SDKs from Java 8 use the 64-bit C functions for dates: all OK. If you still use IBM Java SDK 7 or earlier, upgrading to the supported Java 8 or later is essential.
Even with later IBM Java SDKs, some care is still needed with 31-bit Java. For example, IBM documentation for the latest IBM Semeru Runtime for z/OS version 21 states that the 31-bit setChangeTime method cannot change times after 2038.
Current versions of Unix ported languages, such as PHP and Python, are 64-bit: no Y2K38 issues. However, anyone using older versions (such as anything earlier than PHP 7.0 or Perl 5) will want to upgrade.
Other Products
IBMs flagship Db2 and IMS database managers use internal formats that can store dates up to 9999. They do not have functions like UNIX_TIMESTAMP to get UNIX datetime values, so this looks good.
Other z/OS resident database managers like SQLite and Adabas don't have internal date formats, but use 'normal' formats, including integers holding UNIX datetime stamps. These will need to be reviewed to ensure that 4-byte integer formats such as the Adabas (F,4) or SQLite int(4) are not used for UNIX datetime values.
Outside the DBMS, there is nothing stopping an application from storing UNIX timestamps in database fields as a signed 32-bit integer. Similarly, products receiving external data and mapping it to internal data types could squeeze incoming UNIX datetime stamps into 32-bit signed integers. Products to check include IBM MQ, z/OS Connect, IBM Transformation Extender (ITX), and CICS web services.
The CICS ASKTIME service returns an 'absolute date' as a 64-bit integer holding the number of microseconds since 01-Jan-1900. No problems here.
Issues for z/OS Users
Y2K38 is a problem for z/OS users. Many software vendors, including IBM, have learned from the first Y2K and are making their software Y2K38 resistant today. This is smart, as users will at some point require Y2K38 certification of software products.
All z/OS sites will need to review their exposure to Y2K38, especially those with C/C++ programs or using UNIX datetime stamps in other ways.
Today, few z/OS sites are worried about Y2K38: it won't happen for almost 12 years. Some may be confident that there will be no mainframe in 2038, others will leave the problem for the future: they won't be around by then. However, those with experience of the first Y2K problem will remember how those preparing early were far better off than those leaving it to the last minute. Today is the day to start planning for Y2K38.
David Stephens
|
Home
| Press
Room | Contact
Us | Site
Map
