Non-compliant programs with missing source codegreenspun.com : LUSENET : TimeBomb 2000 (Y2000) : One Thread
In performing inventory/assessment work for a large bank, I found many programs which had no source code. The load module was executing in production, but the source code (in Cobol, or Assembler, etc) had been lost. In such cases, the program cannot be corrected, since it really no longer exists! However, it is still running and part of the bank's operations. How are companies dealing with this situation? I don't believe you cover it in the book, although I am only 2/3 through it.
To be safe, I would think a company would want to replace such a program (replace its functionality with a new program). The bank had not made such a decision, and was basically just pretending the situation didn't exist. tick tick tick...
-- Robert Nolin (email@example.com), April 14, 1998
A company is going to have a very difficult time "replacing the program's functionality with a new program" since it would certainly appear that the bank no longer really knows what that functionality is.
There are various ways in which an organization maintains its "institutional memory". One way is through well-documented computer programs. Another way used to be through its middle management, who were the people that really knew how the company worked and what to do when things went wrong.
Chances are, that not only is the programmer long gone who turned the company's policies into computer code, but so are the middle managers who told the programmer how the business worked, then got down-sized because the company "longer needed them". So the company that has programs without source code will have a very difficult problem to solve.
When people make a generalized estimate that Y2K corrections will run about $1.00 to $1.50 per line of code, they better add a substantial buffer to cover the programs without source code. These could really b
-- Dan Hunt (firstname.lastname@example.org), April 14, 1998.
No, we didn't cover this in our "TimeBomb" book, because it's a technical issue. The average consumer doesn't care (and is unlikely to know) WHY an organization's Y2K project has failed; all he cares about is that the organization is unable to provide the products or services that he depends on.
At least a few of the Wall Street organizations have discovered that they've lost 25% of their source code, and one utility has lost 40% of its source code -- so this is a non-trivial problem! A varation on this problem is the discovery that you have six slightly-different versions of the source code, none of which exactly match the binary version running in production ... and you can't tell which (old) version of the vendor's compiler was used to produce that binary code.
A rational option for dealing with this situation prior to 1998 would be to scrap the system and replace it with a vendor-supplied package. But as someone else on this thread has already observed, and inevitable consequence of the lost-source-code situation is that nobody is quite sure what the detailed business-requirements are ... so it usually takes 2-3 years, if it's a large system, to figure out exactly how the vendor-supplied package will meet (or not meet) the organization's business requirements, how it might be customized to become more acceptable, how it can be integrated with the organization's legacy databases, etc. By now, in the spring of 1998, that's no longer a viable option in many cases.
That leaves the Y2K tools that operate on binary code. That's what Bob Bemer's technology is all about; and that's one of the many tools that IBM has been working on. I think IBM one of their binary-code tools last week...
-- Ed Yourdon (email@example.com), April 16, 1998.