Cobol Program "fix" - quick and accurate ?!!? : LUSENET : TimeBomb 2000 (Y2000) : One Thread

Ed: Am not technically oriented so only based on what I have read - there are no silver bullets - fully understood. Today, Computer Associates announced new "fix" for Cobol Programs and described it as "quick & accurate". Is this just hyping up it's stock? Does this type of fix address one language only? If the managements of so many large companies and mid-sized companies are still in denial or ignorant of 'bug" - how would Computer Associates reach them if no one else can? Steve.

-- Steve Alley (, January 06, 1998


Hi Steve, I'm no techo guy, just an ordinary ICU nurse and trader. Have read lots on y2k. I read that CapGemini is offering an automateed Cobol tool that garuntees (money back in 90 days) remediation of Cobol code in four weeks "after specifications are accurated provided". I'm not sure what that means. My understanding of the automated repair programs is that they scan code and repair instances where y2k probs are encountered. However, I also understand that the actual repair of code is about 30% of the remediation process. Questions for Ed or some other very knowledgable person: 1. Do these tools increase the likelihood that repairs for Cobol only companies will be done in time. 2. Is Capers Jones estimate of total percentage of Cobol code accurate? 3. Should the advent of these tools be cause for increasing optimism? 4. What is the approximate probability that the tools actually find and repair all y2k problems (I have also read that regardless of tools, an actual programmer still needs to review the repair line by line)?

-- P. Larson (, January 09, 1998.

Steve, I haven't seen the details of the CA tool, but I'm intrigued by the level of interest that it has generated; after all, there have been many similar announcements from several other reputable vendors over the past few years. But in any case, to answer your question and those of Mr. Larson:

1. Certainly, there is a chance that CA's product will improve the situation; but recent surveys in the Y2K field indicate that over 70% of the companies working on the problem have already chosen their tools. Not to have done so implies that you're so late getting started on Y2K that there's not much chance of finishing anyway.

2. As people like Capers Jones have indicated, COBOL is only one of many, many languages involved (and, yes, Mr. Larson, his figures are generally considered fairly accurate). In any case, the CA tool does not address the far more difficult Y2K work that takes place in assembly language on mainframes, nor does it address such other mainframe languages as PL/I, FORTRAN, etc. It has nothing to do with PCs (except the very few cases of COBOL running on PC's), and it has nothing to do with embedded systems.

3. Mr. Larson asked whether the advent of these tools be cause for increasing optimism? In my opinion, the answer is "no," because the problem has never been a shortage of tools. Again, there are lots of good vendors and lots of good products -- including the ones that CA began introducing back in 1996. The new CA product is presumably a good one, but there's no way that it could be a silver bullet that will automatically fix everythign in every language on every platform.

4. Mr. Larson also asked, "What is the approximate probability that the tools actually find and repair all y2k problems?" The answer, of course, is "it depends" -- and you'll find that most of the vendors have lots of caveats and qualifiers in the fine print of their product description, which ultimately means that they don't promise 100%. Typically, the tools will find 90-95% of the date occurrences, and can change all of those appropriately. But the other 5-10% have to be found and fixed by humans -- and EVERYTHING has to be tested (though there are lots of good testing tools to help automate that process, too.)

-- Ed Yourdon (, January 10, 1998.

P Larson -

>>the actual repair of code is about 30% of the remediation process<<

I believe that 30% figure is high. Plus, there are very few companies that are pure COBOL.

Figures for where project effort goes are from Fred Brooks' classic "The Mythical Man Month": - 33% planning - 17% coding <-- code conversion - 25% unit test - 25% system test These are real numbers from his experience with the construction of IBM's MVS operating system in the 1960s.

Bottom line... automagical code converters definately help, but it's the smallest, easiest step.

Makes for fine press releases, but really not where the action SHOULD be.

- David

-- David Eddy (, January 13, 1998.

Moderation questions? read the FAQ