By Gary Flood, editor of Software Futures, a sister publication
Yesterday we outlined some of the possibly over-hyped disaster- movie aspects of the Millenium Bug, the oncoming meltdown of computer systems unable to cope with (or worse, foist many hard to spot run-time errors because of) the Century Date Change from the 20th to 21st centuries. Now, hear about what some of the early pioneers who’ve fixed their systems had to say at the Year 2000 conference in Orlando, Florida, last October. As Jennifer Schmidt, managing partner for Chicago-based systems renovation consulting firm SPR, puts it, you’ll find that the actual physical changing of lines of code will be the smallest element of your cost, ironically. Based on her experience of a number of Year 2000 projects, a good rule of thumb would be 40% planning, 50% testing, and only 10% rewrites, she estimates. (By the way, that inventory check isn’t meant to just cover your in-house developed code – what about all your packaged software applications. Yes, that means you, Mr Smug Client/Server. How sure are you that all your glittering new distributed applications are century-compliant?) The inventory management angle was in any case a factor in the experience of Mike Smith, director of the Great American Insurance Company, of Cincinnati,who coordinated the company’s recent Year 2000 fix. We have a bit of everything, he admits cheerfully, detailing a mixed legacy and PC environment where systems using CICS, Cobol, Assembler, VSAM and PC upload to mainframe screens are all happy equals. And buried in this richness? At least 75 combinations of letters and characters that dealt with dates, in the case of the PICTURE, REDEFINES and VALUE literals of his Cobol applications. We’re sure Mike isn’t the only one who might have to say after looking at some of his working code, I didn’t know you could go on for that many pages before a full stop. Assembler proved an easier language to date decode, he adds, but warns that macros in the language need careful handling.
Not mere code parsing
In terms of fixing as a percentage of time spent, he agrees with Schmidt.We found that impacted code was only about 5% – but impacted logic was 80%. In other words, tracing the Year 2000 impact on all systems as a Gestalt was more important than mere physical code parsing. Two other valuable insights into getting the Year 2000 fix right: source and project management. As we said about that inventory (have we told you it’s important yet?!?), using JCL is actually a surprisingly good way of doing easier impact analysis – but if you have missing source, problem. He suggests using your JCL resource as a good roadmap. As for project management: It’s too dangerous to think you can do all this in one go. The only reason I’m able to speak to you today about it is we did it in phases. One thing that you must take away from Mike’s project is that in the end, with the right tools and approach, it became a manageable problem. A lot of the hard coded procedural logic proved acceptable so long as the right top level interface is changed, for example. In over 95% of cases of needed code change, a simple expansion to include a century date field was all that was necessary. And he was able to use a cheap and plentiful programmer resource- A task force of college kids did most of the mechanical work, he grins.
Statistics
But don’t take that one user story as a safety blanket: There are three certainties in life – death, taxes, and the Year 2000, says Hall. And it doesn’t matter about the statistics – in the end, it’s all about your situation. Dan Spragle, seconded from Andersen Consulting to the Yellow Corp, a mid-Western trucking firm, does have some statistics, though. Inventorying was easily the most time consuming aspect of our fix, he notes, since 9,000 programs were involved. In the end it took 17 people 3 years of effort to complete the work, or 50 person years (350 in dog years, as he says…). That averaged out at about $75 an hour per programm
er, a not inconsiderable sum. The team had also used the Adpac source editing tool to facilitate that process. Bank of America’s Year 2000 team had a neat way to persuade senior management that this apparently empty way to spend good IT investment (remember, you only have time to fix the Year 2000 bug – you would be reckless to think you can do that long-postponed systems re-engineering at the same time). One of its VPs, Howard Adams, declares, We sold it to management purely and simply as a business opportunity – we will use this work to gain market share and win customers in the face of our competitors’ non- compliance. Howard contracted James Martin & Co, the Atlanta- based consulting firm, to use its TSRM (The Systems Redevelopment Methodology). He found a massive 75 million lines of code needed scrubbing, including 50 different dialects of Cobol alone. No tool can cope with all that code on its own; a methodology for process and project management is vital, he believes.
Business Drivers
Abbott Labs, a Chicago-based pharmaceutical and health care company, used a combination of product and consulting from Quintic Systems, Inc (also of Chicago). Again, this was a situation involving not just mainframe but DEC and AS/400 and, yes, over 30,000 PCs. The reason the organization took on trying to pick over this gigantic IT inventory was simple – a system fell over in 1990 and another produced incorrect results. Since a lot of its system output has to go to the Federal Food & Drug Administration since the 50,000 strong outfit develops and sells new drugs, this was kind of an important business driver. To trap the problem before it got more out of hand, the company instigated a programming standard in May of 1990 to ensure that a four digit year was always used. It then divided up the problem into four areas of concern; its mainframe legacy, PC and unsupported code, the software it purchased and the software it produced or sold. The next step was to decide that as far as possible a four digit year code could be simulated as often as practical, rather than physically trapping and changing occurrences. This is similar to the Great American Insurance approach, and also puts all those perhaps simplistic Year 2000 Cost = Lines Of Code x Change Per Line doomsday equations. If that was the case the Abbott Labs inventory would have been potentially cripplingly expensive – 8,700 external sorts, 8,800 separate programs and 445 production systems needed attention.
Natural Deaths
And as we said before, the decision to carefully carve out the systems that will die a natural death soon anyway can reduce the workload even further – 320 of the production systems were thus eliminated as Year 2000 fix candidates. Using this project management tip, the user was able to go back and cut the projected Year 2000 cost by 50%. But note that based on this particular case, the systems inventory work isn’t a once-only – quarterly updates may be advisable (old systems have a habit, as we all know, of never quite dying on their own). Sandy Carroll, the Year 2000 project manager for Business and Student Information Services at the University of Minnesota, in the twin cities of St.Paul-Minneapolis, faced a similar apparently vast problem with 5 million lines of code (5,000 programs). Thankfully, she too was able to revise her original costs down by bringing in the help of Phoenix, Arizona based Viasoft’s Impact 2000 product, cutting the impact analysis phase alone down from 8.5 months to 6 weeks. Of the 5,000 programs, again, it turned out that not all needed changing – only 3,500 were actually in need of attention. Don’t think Software Futures is saying that this Year 2000 is a trivial problem simply because in practical terms it’s the feeling from some of these plucky century-date change pioneers that in practice the actual amount of effort involved is simply a lot – not crushing. All that means is that don’t be so daunted by the thing that you throw up your hands and don’t start at all. But obviously the soon
er the better. You might object that without support from the corner office, you might as well hunker down and wait for the food riots. If you hear the slightest note of objection, you might want to point to the example of Lou Gerstner. The financial engineer now turning IBM around has thrown his considerable presence into supporting Big Blue’s own efforts to clean house for Year 2000. If you download the very useful IBM’s 180 page document on its approach to the crisis (at http://www.software.ibm.com) you’ll only get more confirmation that Gerstner knows it’s vital IBM gets this right. The word from IBM spokespeople on the Year 2000 project is that Gerstner expects a full update every two months on the ongoing rollout of compliant products, and a 17-strong customer council has been established to help him get it right. In terms of IBM products and system software that need fixing, apparently VSE and MVS are on the minor casualty list, while VM needs quite a bit of work (not surprising, being that much older). While AS/400 software is kosher, AIX is pretty much okay with a hint of caution – make sure routines that work with the counter all use four digits for years, not two.
PC BIOS fix
On the PC BIOS side (and you’ve probably made the private joke to yourself about resetting the systems clock to 2000 and looking at the, er, funny things the computer does), IBM claims a hardware BIOS fix will be in place this year. (However, don’t be surprised if you have to get up a bit early from the big party to reset some system clocks once again, just in case.) All in all, IBM faithfully promises to be clean on the products side by the end of 1996, and on applications by the end of next year. IBM will also warn you about the Millennial Bug in a responsible way, (quoting, once again, Gartner), The time is now, the problem is real, the solution is ugly. Outsourcing might not work! Well, one solution a lot of customers might immediately be tempted to go for is outsourcing the whole wretched mess once and for all. Simple, no? Hang on to your card from that nice guy at EDS or Andersen for a while longer. In a good article on the crisis in the July, 1995 issue of CFO, technology editor John Xenakis pointed out that the fixed-price contract nature of a lot of typical outsourcing deals doesn’t fit well with the open-ended nature of a 2000 fix. This problem is so big that we will consider these bugs to be out of the scope of our normal maintenance contract, says Benny Popek, managing partner for applications management for Coopers & Lybrand LLP in Burlington, Massachusetts. For those clients who insist that we should take responsibility, we’ll exercise the cancellation clause and terminate the outsourcing contract. One firm we’ve already namechecked as active in both Year 2000 fixes and outsourcing, Cap Gemini America, now specifically mentions the issue in its contracts. More than mentions; its inclusion raises the cost of a typical five year contract by between 5 and 20 per cent a year! Just to rub it in, Computer Sciences Corp has been quoted as saying it doubts [any outsourcing vendor] will ever assume the cost of fixing this problem. There are any number of strategies like thinking you can ignore the problem until the weekend before the century change, or through outsourcing, or hiring a bunch of cheap and cheerful programmers in India or Russia to do it for you. The Web page devoted to the issue (http://www.2000.com) even has an amusing David Letterman style Top Ten reasons for ducking the issue; our favorites are, Nostradamus never mentioned this, I believe in the sanctity of all life – including computer bugs; and What date problem? Bill Gates will solve it. The Year 2000 problem is upon us. It’s not a joke, but it’s not like a comet crashing into the Earth – ie, you can do something about it. And it won’t cost billions for you – just time and effort, now. An analogy we’ll steal from the management consultants is the story about the frog in hot water. Put the little green fellow in a pan of boiling H20 a
nd he’ll naturally spring right out. But put him in a pan of cold water and slowly heat it up, and the poor thing will stay happily there not noticing the temperature rise until it is far, far too late. Feel that water bubble?
Gary Flood e-mail: gary@apt.usa.globalnews.com
