Y2K remediation introduces errorsgreenspun.com : LUSENET : TimeBomb 2000 (Y2000) : One Thread
ATTEMPTS to fix the Y2K computer problem often make the problem worse, according to the managing director of software firm Cincom New Zealand.
The Wellington-based subsidiary of the United States-based company is offering to check up to 100,000 lines of Cobol code for Y2K errors free of charge.
Cincom New Zealand managing director Mike Ross says experience overseas has shown the check is likely to find large numbers of critical errors - especially in code that organisations have tried to fix.
He says several hundred mainframe and minicomputer users around the world have taken up Cincom's global offer, and none has provided code which is Y2K compliant.
"We have been saying, `send us the code you have already signed off as Y2K ready - the code you are most confident about'. The best contained six critical errors, and the worst 200."
Mr Ross says Cincom tends to find more Y2K errors in code that has supposedly been through the process of Y2K remediation than in code that has been left alone.
"That's because there are thousands of programmers with varying skill levels around, not necessarily Y2K expert fixers, who have been going in there and `having a go' at fixing problems."
Cincom is using Beyond 1999/Validate, a program developed by Californian company CCD Online Systems, to check code using pattern matching and propagation algorithms.
CCD Online says it has found errors in "virtually every case of previously renovated code, regardless of whether the client has used a manual approach, a software tool, or both."
Beyond 1999/Validate customers include the United States Social Security Administration and the United States Customs Service. Customs selected the product in November to check 22 million lines of Cobol.
Under the promotion offered by Cincom New Zealand, users can e-mail up 100,000 lines of Cobol code - with source code and copy books - to Cincom. It will check it using Beyond 1999/Validate, without any obligation for the user to purchase the product.
-- Michael Goodfellow (email@example.com), March 24, 1999
Did they say, specifically, that they have found these error rates in the SSA's remediated code?
-- Rich Miller (firstname.lastname@example.org), March 25, 1999.
Boy, this is a shock (grin)! Any comments my fellow programmers out there? This ain't as easy as it seems. Programs with thousands of lines of code, much of it spaghetti code, that has been worked on by who knows how many programmers over the decades. Documentation? Yea, maybe for the original project if you're lucky.
There have been few Y2K failures to date. There have been many failures at attempting to fix Y2K. <:)=
-- Sysman (email@example.com), March 25, 1999.
Hi Michael, Sysman,
It's obvious to me that remediated and tested code will have errors. All of the numbers from DP/IT show that! As I recall, the overall figures for maintenance-induced errors is 15%. That is, make one change in a program and you stand a 15% chance of introducing an error which isn't caught until the program is in production -- either the fix was wrong or it caused an error in some other program function.
As the number of changes per program increase, the number of errors increase. Testing will catch most of the induced errors, but not all of them.
This is why I'm on the side of Infomagic when he uses a 1% error rate (instead of the 15%) with the errors cascading between systems and interconnected companies.
(Infomagic sees a real disaster -- a 10 -- because of the cascading failures)
-- Dean -- from (almost) Duh Moines (firstname.lastname@example.org), March 25, 1999.
These types of results are no surprise to me either (I have also done big systems programming.) I have not done COBOL though. Anyone know if it is susceptible to the kinds of storage-overwrite errors you frequently get with c/c++ ? My favorite Y2K bug in that language is
struct tm t; char zBuffer; sprintf(zBuffer, "%02d/%02d/%02d", t.tm_month, t.tm_day, t.tm_year)
No problem in 99, because tm_year is 99. Next year, it's 100. So the date formats as 01/01/100, and you just overwrote your buffer.... Hope it didn't step on anything important!
And by the way, this kind of bug strikes me as very hard to catch with an automated tool. It would certainly flag this as a date-related statement due to the struct tm use, but a cursory reading of it might not catch the problem. The programmer might be thinking that tm_year is 0 in 2000, and read right over it.
Anyway, can this happen in COBOL?
-- Michael Goodfellow (email@example.com), March 25, 1999.
Here is the question I've been wondering if COBOL and other mini/mainframe programmers can answer:
What happens if you took every bit of software in production, took it offline, made no code change at all, re-compile it, and move it back onto its old -- or a new, supposed-to-be-compliant -- platform?
Some old compilers are lost, some incompatible with new platforms.
How much of y2k's problem is just that everyone is getting in and monkeying with code they'd rather leave alone until replacement, and everyone's doing it at once?
How much of the lack of extra programmer hiring and keeping remediation in-house is the decision to go over the waterfall in the old rowboat they know rather than jump into the water? FOF looks better to them than messing everything up digging down deep into spaghetti code ahead of time.
-- jor-el (firstname.lastname@example.org), March 28, 1999.
OK, yeah, errors will be introduced. No avoiding this. But it's hard to believe that "Cincom tends to find more Y2K errors in code that has supposedly been through the process of Y2K remediation than in code that has been left alone." You would expect that if *every* y2k error were improperly fixed, the number of y2k errors would remain exactly the same as before the fixing.
If Beyond 1999/Validate is such a foolproof tool, why aren't more organizations using it?
Most such tools flag code as being suspicious. Is Cincom counting all such flags as errors?
This story sounds like ad copy for a service and a product.
-- Flint (email@example.com), March 28, 1999.