The Millennium Bug: A programmer’s story

Much of the talk in the World’s media about the Millennium Bug is written by journalists, with little knowledge about the real reasons why earlier programmers ignored what is now conceived of as a problem

If you want more accurate information, find a programmer (preferably an older programmer who worked on mainframes years ago) and ask that person.

The following article is from just such an old-timer who worked on IBM OS/360/370, MVS, MVS/XA, MVS/ESA and OS/390 operating systems from IBM 1620’s to new IBM CMOS mainframes.

Once upon a time when computers meant mainframes and only a few thousand people in the world worked with them, the Y2K bug was born. Probably the most significant date was in 1964 when the IBM System 360 was released. At the time computers and storage were expensive. Large mainframe installations were in the range $10-20 million each and computations cost about $0.035 per 100,000. Computers and computing were expensive. Computing charges were billed back to the originating department. There was no such thing as a CIO or that computers should be taken for granted or that their costs should not be charged. Hence a program had to be inexpensive to run or the originating department would scream at the programmers for costing them money.

The original OS/360 TIME macro instruction (the assembler language macro that gets the time value from the computer system clock) returned, in register 1, the date in packed decimal format: 00YYDDDF where YY was the year as 2 digits, DDD was the Julian day number (1-365) and F is the sign byte ‘1111’ . So any date routine by any computer program or computer language would only return a 2 digit year. If you wanted 4 digit years, they would have to have been coded in the computer program. The mainframe sure wasn’t going to give it to you!

NOTE: The time macro since about 1980 or so with MVS, MVS/XA, MVS/ESA, and OS/390 now returns data in the form 0CYYDDDF where C is a digit representing the century. In the years 1900 through 1999, the macro will return a value of C=0. In the years 2000 through 2099, the macro will return a value of C=1. YY is the last two digits of the year. DDD is the Julian day of the year (1-365) and F is a 4-bit sign character ‘1111’ that allows the data to be unpacked and printed.

The shortcutting of storing dates came about by most COBOL programmers saving dates in the MMDDYY or DDMMYY instead of DDMMYYYY or MMDDYYY. We were all saving 2 bytes per record. If you had a 10,000 employee database and one file for each employee, you saved 20,000 bytes. Computing was expensive. Small tightly-coded programs that ran quickly were the rule. You had to cram as much code as possible into a program but it had to be compact and quick running. You could not afford to run large programs — it was too expensive.

Mainframes had no more than 2Mb real memory. Virtual memory was unknown. Large programs were limited to 1500K in size lest you bog down and hog up CPU cycles. Programs larger than 1500K had to be run in off-peak hours, not during the business hours. We all learned good programming techniques such as overlays so that we could squeeze a 2200K program in less than 1500K.

The first mainframe I worked on, an IBM 1620 only had 64K memory!! The problem with PCs is everyone is now blinded to the reality of how tightly-coded programs are in the mainframe world. Large mainframes today still only run about 2Mb real memory and up to 64Mb virtual memory. However, most have multiple CPUs — 6 to 8 and verrrrrry efficient operating systems to support multi-user and multi-programming environments. Tight code and quickly running programs is still the rule in the mainframe world. 10,000 users and 350+ plus programs running simultaneously doesn’t even cause the mainframe to slowdown.

The main Y2K problem in the business world is locating all the COBOL source code, going through it to see if there is a date calculation, and then revising the code for a four-character year. Programs that only print dates or don’t use them in calculations will be the last programs checked and updated for Y2K compliance. You then have to run the programs and databases on a second or test sytem to simulate dates greater than 2000 and perform many performance tests. We are talking about tremendous amounts of code throughout the world and tremendous resources being used. You can’t shutdown your day-to-day operations until one whole database and all the associated programs that go with it are throughly tested. You then have a production turnover at some off-peak hour, 2-4AM usually, and roll out the new system.

Companies with many systems and programs have millions of lines of code and thousands of programs to go through. This is not a simple task. Where I worked we had gone through about 85% of our code by July 1998. Full-scale testing will be done for the whole year of 1999 running duplicate systems. It was cheaper for us to buy another small mainframe computer ($4 million) and additional DASD (Direct Access Storage Devices — hard disks to you PC users) to duplicate and run parallel systems than try to disrupt day-to-day operations involving a customer database of 1.3 million.

Our biggest problem involved old 360-assembler language programs that were coded and linked to our COBOL code. Many of the original sources have been lost and some of the routines were coded in the 60s and 70s. Also, most newer programmers don’t even know 360-assembler so some of us “old” dogs got the reward of re-writing the code. You take a dump of the code and go back and try to re-create the 360-assembler language. This then will be re-written in new assembler language. Talk about difficult. I’m glad I retired.

As you can guess, all of the above is an expense that can never be recovered in day to day operations. How many major corporations in the US and rest of the world are done is anybodys guess. So legacy code in the mainframe world is a culprit that may not be conquered in time. Depending upon the industry, these problems could be construed as major (wall street stock market, commodities, life insurance and annuity calculations, flight and room reservations, etc.) or minor (pay check errors, bad billing, ordering problems, etc.) Anything related to date calculations can cause problems. Most of these would be in programs that subtract one date from another to give a time frame, like your age — subtract birth year from current year to find age. How many days is it between date1 and date2 (short terms loans, investment calcs, etc.)?

PC clock timers and operating systems probably won’t be affected as much as the above due to the fact that most BIOS (Basic Input Output System) chips have been changed in newer PC since the 90s to carry a four-character year. Only old 286, 386, and early 486s with old BIOS chips and running old DOS versions would be affected. However, it’s possible that many of your favorite old PC programs won’t work correctly. If you check Microsoft’s Y2K site you can check the status of their programs. Note that many of the old programs will not be fixed for Y2K. See http://www.microsoft.com/technet/year2k/

IBM DOS 7.0 (with Y2K fix pak) and the new IBM DOS 2000 should meet the needs of any old DOS users that needs a Y2K fix for old PCs. M$ is not providing one! See http://www.software.ibm.com/os/dos/

The real problem comes from embedded micro code in microprocessor controlled devices. For a simple example, How does my VCR know when it’s daylight savings time? It appears to do it properly but how is the microprocessor coded? Does it do a date calc? If so, will it be valid in 2000? What about controllers in medical equipment? or the electic utlility industry? or your car? or your TV? or any other microprocessor controlled device? We could be in for a big surprise in Y2K or then again maybe nothing will happen. This is the area that gives the informed individual the most fear — devices failing for which no fix is available, except to buy a new one.

Best advice in December 1999, is to make sure you car is full of gas, you have plenty of groceries stored away, all bills have been paid, and you have plenty of cash on hand. Things could get tricky for a month or so in January and February 2000 (This is a leap year).