Quick fix for main frames running COBOL?

greenspun.com : LUSENET : Electric Utilities and Y2K : One Thread

Those COBOL programmers who are also knowledgeable about main frame operating systems, please give us your opinion about the claim (see below) that making small strategic changes in a main frame's operating system will allow many applications to run trouble-free after 12/31/99. Most other applications will require only minor changes.

Year 2000 Problem - Scam of the Century

Corporate technology buyers are being taken to the cleaners over the Year 2000 problem.

Im an engineer who runs a small software company. In the last 20 years Ive written lots of the kind of software that is going to break on January 1, 2000. I have many former customers - in some cases 15 years have passed - who will be out of luck when the millennium rolls in. So I have worried over this problem a good deal, as you might imagine. Yes, it's a problem. But there are solutions. And one solution is to get the same guys selling Y2K consulting services, notably the computer manufacturers like IBM, to place a small strategically placed "fix" into their operating systems. This fix would solve at least half of the problem.

A hefty percentage of the code that is going to break on Jan 1, 2000 is IBM mainframe COBOL software. Yet IBM could change its ES/390 and AS/400 operating system software to let users designate a program as being "year 2000 deficient"; when running these programs, the operating system could then automatically correct many - if not the vast majority of - date sorting and size errors by handling dates after Jan 1, 2000 as if there were additional decades in the twentieth century (e.g. the 70s, the 80s, the 90s, the A0s, the B0s, etc.). If you want the technical details, click here.

How much code would be fixed? From my experience, the percentage would be quite high. In my kind of applications, the fix could be a complete remedy! Overall, I have to believe at least half of the errors would disappear. Yeah, the screens and printouts might have some funny looking or missing characters, though with a little more work the computer manufacturers could probably fix even that; or, some simple conventions could be used, or some minor rewrites could be made to key screen/print programs. Industry would wind up saving hundreds of billions, and the companies who simply cant afford to rewrite all their software would avert a needless upheaval.

My fix is a handful of relatively simple changes to the operating system. Based on 20 years of programming IBM mainframes, I say it can be done. And I propose the fix will work in one form or another on most platforms that run COBOL.

So, the Year 2000 Problem need not be as bad as the computer manufacturers make it out to be. Especially if these same guys would spend a little less time crying about how bad it is and a little more time fixing their products to handle it.

-- Anonymous, June 05, 1998

Answers

The problem with this proposed approach is that the hexadecimal digits A through F are not valid decimal digits. COBOL will not recognize a "number" containing these digits as being numeric. Also, the hardware on an IBM 390 mainframe would give a S0C7 abend if it encountered a nibble containing one of these invalid digits except when it is used as the sign of a packed decimal number.

I worked on an assembler project at the IRS three years ago when this approach was discussed, and it was recognized that encoding two-digit dates in this fashion would involve massive rewriting of the assembler code to avoid hardwire abends.

-- Anonymous, June 06, 1998


Moderation questions? read the FAQ