Is Y2K Back? Help for the 2039 Problem!
Bad Joke of the Month
Q: How do you get a squirrel to like you?
A: Act like you’re nuts.
Is Y2K Back? Help for the 2039 Problem!
Many of us remember working for years in the 1990s to find and fix anything that would cause a “Y2K problem.” These were the problems caused by using 2-digit years that occurred when the year changed from 99 to 00. At the time, IBM gave us a workaround such that years from 40-99 were considered 1940 to 1999, and years 00-39 were considered 2000 to 2039, giving us another 40 years to solve the problem – but now in 2024, more than half of that time has passed, and people are starting to run into the 2039 problem!
To assist with finding and solving the 2039 problem, IBM has released a new feature in RPG.
Background
The original problem was that we stored years in 2-digit fields, or whole dates in 6-digit fields. For example, for the date December 31, 1999, we may have stored it in Year/Month/Day sequence as 991231. This caused two problems: (1) when you take 99 and add 1, you get 100, whereas you really want 00. (2) Even if you fix that problem, if you compare 000101 (January 1 2000) to 991231, it is a lower number, so sorting algorithms would put the year 2000 as earlier than the year 1999.
We worked around this problem by using routines provided by IBM that temporarily converted our 2-digit years to 4-digit years to allow us to get past the change from 1999 to 2000. The temporary conversion worked like this:
If year < 40;
temporary_year = 2000 + year;
else;
temporary_year = 1900 + year;
endif;
This let us get past the crisis and ensure that our computer systems didn’t fail when the year 2000 rolled around, whew! The only problem is, 2039 is now coming up on the horizon, and therefore we need to go through the process all over again! In some cases, businesses are already running into the problem. For example, code to calculate a 15 year loan starting in January 2025 will be calculating dates in 2040, ouch!
Even if you aren’t already experiencing problems, it’s time to ensure that all of your code is fixed. The best solution, naturally, is to upgrade everything to 4-digit years before it is too late!
The DATEYY Ctl-Opt Feature
To help us address this problem, IBM has added a new feature to the RPG compiler in the form of the DATEYY CTL-OPT keyword. For example:
ctl-opt DATEYY(*WARN);
If you put this in your RPG program, the compiler will produce a severity 10 (warning) message in the compiler listing when one of the following is true:
- A date format for a date field has a 2-digit year, such as *MDY, *DMY or *JOBRUN.
- An externally defined file or data structure has a 2-digit year format
- The program uses the legacy UDATE or UYEAR special variables.
- The program uses the TIME opcode with a 12-digit date/time result.
With this message in the compile listing, your developers will notice the problem and be aware that they will need to work on getting this code upgraded to use a 4-digit year before 2039 rolls around.
If you feel that this is not severe enough (sometimes RPG programmers are in the habit of ignoring warnings) you can take it a step further by coding this instead:
ctl-opt DATEYY(*NOALLOW);
Using *NOALLOW instead of *WARN tells the compiler to produce a severity 30 error, which will stop the program from compiling. This way, the error cannot be ignored.
RPG Programs Using *JOBRUN
One nice feature that RPG offers is the ability to use the job’s date format in a program by using the special value of *JOBRUN. For example, in Europe where dates in day/month/year are preferred, a user can have their job set to use that format, whereas in the USA, the job may indicate month/day/year.
To use that feature an RPG program would do something like this:
DateForUser = %char(curDate: *jobrun);
In this case, if curDate is November 23, 2024 the DateForUser would contain 11-23-24 in the USA, or 23-11-24. We’ve had this feature for a long time, and it is very nice for shops that have users in multiple countries where different users may prefer different formats.
However, this also produces a 2-digit year, so can cause the same problems in 2039!
To address this problem, IBM has introduced the *LONGJOBRUN option.
DateForUser = %char(curDate: *longjobrun);
Using *LONGJOBRUN, a 4-digit year will be produced, so given the same example you will have 11-23-2024 in the USA or 23-11-2024 in Europe.
More Information
For more information about these new features, including the PTFs needed to enable this support in IBM i 7.4 and 7.5, please see the following link in the RPG Café:
Scott Klement
Development and Solutions Architect
Scott Klement is an IT professional with a passion for both programming and mentoring. He joined Midrange Dynamics at the beginning of October 2022. He formerly was the Director of Product Development and Support at Profound Logic and the IT Manager and Senior Programmer at Klement’s Sausage Co., Inc. Scott also serves on the Board of Directors of COMMON, where he represents the Education, Innovation, and Certification teams. He is an IBM Champion for Power Systems.