Do you remember the Y2K problem where the date rolled into 2000?
I had to fly to the US on Jan 1st 2000, so I could be on site in case there were problems with a large bank running on the mainframe. I have two memories
- the vending machines had a message like Out of Cheese Error. Redo From Start. and would not vend.
- someone had been taken to hospital with gunshot wounds, because people celebrated the new millennium by firing their guns up into the air, and what goes up, must come down, and if you are in a crowded street…
There is another year 2K type problem coming, it is when the System 390 clock wraps. It is a 8 byte field. When I was writing statistics and accounting code for MQ on z/OS, you time an event by issuing the STCK instruction before something, STCK again afterwards and calculate the difference.
To solve this problem there is the STCK extended instruction which is 16 bytes – essentially there is one byte in front of the existing STCK, and some space space at the end. So problem solved? Not quite.
There are many control blocks with a field for the 8 byte STCK value. If this is changed to a 16 byte STCKE field then the offsets of all the fields will change. This is OK with a small program, but not for the operating system, where fields are fixed “for architecture reasons” to allow people to rely on the location of these fields.
Many products depend on a STCK to create a unique identifier, and given two STCK values you can tell which was created first – even across IPLs. Changing this to use a STCKE will cause a migration and coexistance problem.
Some SMF records have a STCK to say when an event occurred, the report processing may need logic to say if the value is small – then add 2042 years to it.
I had a routine which formatted a STCK into YY/MM/DD hh:mm:ss.tttttt. This will no longer work, as the STCK(e) is now 9 bytes long.
Do you need to worry about this? Not really – IBM will fix the operating system and products, vendors will fix their products. It is down to your programs, and most people do not use the STCK values. If you do use STCK I suggest you locate all references to STCK and put the operations in macros. Then when you have to change the code – you change the macros, recompile the programs, and with a bit of magic, and a good wind you’ll have no problems – just make sure you feed the flying pigs first.
The alternative is to retire and let someone else worry about it.
ColinPaice 
You’d better retire slightly earlier than that! 32bit Epoch time wraps in January 2038 🙂
In fact if you read this page (https://en.wikipedia.org/wiki/Time_formatting_and_storage_bugs) you’ll see that there are two or three of these time bugs in each decade from now on!
LikeLike