opinion: Do We Need to Care About Y2K38 or Y2K42 Yet?

In the next 16 years, z/OS users will face two problems similar to the Y2K problem of 2000. On 19-Jan-2038, the Y2K38 problem will hit anyone using a signed 32-bit integer to hold a UNIX timestamp (more on this here). On 17-Dec-2042, anyone using the 64-bit STCK date format will have similar problems (Y2K42).

But that's 12-16 years away. Do we really need to care yet?

Your Code

Let's start from 2038, and work back: 2042 will be similar. By the end of 2037 at the latest (one month before Y2K38), all code will need to be verified as Y2K38 resistant. Think source code searches and lots and lots of testing. Many applications cross server boundaries, so this testing will likely span z/OS and other systems and applications.

Identifying code at risk won't be as simple as searching for z/OS UNIX datetime functions. A COBOL reading a Db2 table or a PL/I application receiving an IBM MQ message may be accessing UNIX timestamps. If we allow 3 years to fix and test all our code, we'll need to start by Jan 2035. A long way off.

There may be compliance and regulation issues that require Y2K38 confirmation before the end of 2037. We may want some more 'wiggle room' in case of problems. So, let's give ourselves another year, just in case. Now we're at Jan 2034.

Compilers

Our code will need compilers and runtimes that support 'fixes' for the Y2K38 problem. For example, suppose you have a 31-bit C program using the C getdatetime function. You could convert this to 64-bit or recompile using later compilers with Y2K38 fixes. In other words, you need to ensure your compiler and supporting software are up to date. Let's add a year for this. We're now at Jan 2033. Still lots of time.

Service Providers

Suppose your code is an API used by other systems, or even external customers. You need to change your code early enough to allow your API users to upgrade to the new API, do any code fixes, and then perform their own testing. If you have anything that modifies or generates code, you may want this upgraded first.

All vendor services and APIs used by your code must be certified as Y2K38 compliant, and possible upgraded. Ideally, this will be done before you work on your code.

Vendor Software

All vendor software and hardware must be Y2K38 compliant, preferably before you work on your code in 2031. If you are a vendor, you want your stuff to be ready by 2031.

You'd expect these upgrades to be part of your normal software maintenance lifecycle. However, if you have some very old or unsupported software lying around, you may need more time to find the vendor, and get it upgraded to where it needs to be.

Let's allow another two years for all of this. We're now at 2029.

Resources

You will need staff with skills and experience to perform code reviews and testing. The Y2K38 will probably need C/C++ programmers, but also COBOL, Assembler and PL/I programmers.

If you have staff who are about to retire, you may want them to review and test all code before they leave. If you have no staff, finding staff or a service provider will become a priority. Incoming staff and service providers will also need time to become familiar with your systems and code: more time.

Modernisation

Many mainframe sites have modernisation plans that will avoid the Y2K38 and Y2K42 problems. For example, no need to worry about Y2K38 if the mainframe will be shut down by 2034. This strategy could be risky: many modernisation projects fail, or far exceed their original timeline.

Start Today

Let's start with the obvious: Y2K38 and Y2K42 aren't a big issue today. We still have over a decade, and a lot could happen between now and then.

However, all vendors by now should be well on the path to fixing any Y2K38 and Y2K42 problems. Vendors can expect clients to request Y2K38 and Y2K42 compliance certification. IBM and others are already there, or well on the way.

Others should begin to think about these issues: their exposure and risk. For example, creating standards now is an excellent step that can be done today. Sites could insist that all Java and C/C++ programs from now on are compiled as 64-bit. All future assembler changes could include work to certify they are immune to these problems, or be modified so they are. All future database fields holding UNIX datetime integers must be 8 bytes.

Increasing awareness and adding Y2K38 and Y2K42 to long-term planning will reduce costs in managing Y2K38 and Y2K42, and reduce risk as these dates approach.

David Stephens

LongEx Quarterly is a quarterly eZine produced by Longpela Expertise. It provides Mainframe articles for management and technical experts. It is published every November, February, May and August.

The opinions in this article are solely those of the author, and do not necessarily represent the opinions of any other person or organisation. All trademarks, trade names, service marks and logos referenced in these articles belong to their respective companies.

Although Longpela Expertise may be paid by organisations reprinting our articles, all articles are independent. Longpela Expertise has not been paid money by any vendor or company to write any articles appearing in our e-zine.