Yahoo news March 31 1999 <:)=

Major companies and government agencies that think they're ready for the Year 2000 could be in for a surprise. Most have overlooked - or chosen to ignore - missing computer ``source code,'' and, unless they recover it, they may be headed for a Y2K meltdown, according to Barry A. Clapp, president of The Source Recovery Company, LLC.

Source code is the code written by programmers to create software applications. Once the application is in operation, years may pass before it is needed again. But code that is missing must be recovered or replaced to fully address the Year 2000 problem.

The Source Recovery Company, LLC of Roswell, Ga. and Framingham, Mass. is believed to have the only known technology for recovering missing source code in the IBM mainframe environment. SRC has recovered a million lines of code for more than 120 Fortune 1000 companies and a major government agency - the U.S. Social Security Administration.

``Companies that think they have fully addressed the Year 2000 should be worrying about the millions of lines of code that are still missing,'' according to Clapp. ``We worry about the organizations we haven't heard from. The Social Security Administration has the most advanced IT organization in the federal government. If it needed source code recovered, why wouldn't other government agencies need our help? And if 120 Fortune 1000 companies have used our service, what about the 880 Fortune 1000 companies that haven't?''

Based on SRC's work to date, Clapp said he knows that tens of millions of lines of source code are missing, but the amount may be much higher. The Gartner Group estimates that the typical organization is missing 3% to 5% of its source code. COBOL code written for IBM mainframes alone accounts for an estimated 180 billion lines of code, so an estimated 5.4 billion to 9 billion lines of COBOL alone may be missing. Based on Gartner Group's estimates, some organizations may be missing a million lines or more, yet even a few missing lines can create a serious Y2K malfunction, according to Clapp.

Some companies have dealt with missing source code by scraping entire software applications. In addition, if small amounts were missing, they may have rewritten the code. Given the time and cost required for rewriting, Clapp said, it is doubtful that many companies have taken that approach. Instead, he said, most companies apparently are either unaware of the problem or are ignoring it.

``In some cases, if the organization has not been meticulous about its inventory and testing processes, computer code may be missing and the Y2K project team may not even know it,'' Clapp said. ``In other cases, the organization may have chosen to ignore the problem, or may not have gotten around to addressing it yet. We know from our experience that this is the case for many companies.''

``Even after code is recovered, it has to be remediated and tested,'' he said. ``Given the scope of work involved, a company missing a significant amount of source code will be hard pressed to meet the Year 2000 deadline.''

-- Sysman (y2kboard@yahoo.com), March 31, 1999

Answers

You missed a key part of that item:

"Company Press Release"

Spin works both ways, doesn't it?

-- Doomslayer (1@2.3), March 31, 1999.

That's why the link is there Doomslayer. Take it anyway you want. I can tell you from personal experience, I've seen it many times over the past 31 years. These guys do COBOL. What about missing ASSEMBLY, FORTRAN, RPG, PL/1, etc. etc? <:)=

-- Sysman (y2kboard@yahoo.com), March 31, 1999.

Doomslayer commented:

"You missed a key part of that item: "Company Press Release" Spin works both ways, doesn't it?"

We'll now Doomslayer, here you go spinning your BS again. The company may well be trying to drum up some business but that doesn't mean what they are saying is not true. Your inference would lead folks to possibly believe otherwise.

Ray

-- Ray (ray@totacc.com), March 31, 1999.

CLOSE ITALICS

-- me (me@you.too), March 31, 1999.

And taking on such a project at this late date would only be setting them up for failure and legal risk...

R.

-- Roland (nottelling@nowhere.com), March 31, 1999.

And, of course, everyone working on remediation that runs into a module with no source code will flag it as fixed. Yeah, right. I don't mind the post here, but I am really, really, really, really, TIRED of the assumption - "computer nerds have no sense".

And the 'zillions and zillions of lines of missing source code' - if they bother to check, it will be on some of the old dusty archive tapes. THAT is what you get when you put your faith in a stupid automatic tape archive program. Which is exactly why I don't trust that type of program.

-- Paul Davis (davisp1953@yahoo.com), March 31, 1999.

OK, Ray, let's take what you said and try it this way.

Koskinen may well be trying to stop a panic but that doesn't mean what he is saying is not true. Your inference would lead folks to possibly believe otherwise.

Now, how does that sound?

-- Doomslayer (1@2.3), March 31, 1999.

Old dusty archive tapes? If you're lucky enough to find it, you'll probably have so many "data checks" it will be useless. Much of the OLD stuff was on old dusty card decks, most likely warped and matted together by now. Not many data centers today even have a card reader today. The ink on those old cards fades in a few years. Want to try to re-key a program by reading the holes? <:)=

-- Sysman (y2kboard@yahoo.com), March 31, 1999.

Doomslayer commented:

"OK, Ray, let's take what you said and try it this way. Koskinen may well be trying to stop a panic but that doesn't mean what he is saying is not true. Your inference would lead folks to possibly believe otherwise. Now, how does that sound? "

Doomslayer, that sounds like poopycock, hogwash and good old BS. My previous statement stands. Your twisted little mind won't change that.

Ray

-- Ray (ray@totacc.com), March 31, 1999.

The key line: "The Gartner Group estimates that the typical organization is missing 3% to 5% of its source code." As I recall, that is also in line with numbers projected by Capers Jones and Software Productivity Research. And yes, that's serious trouble.

Speaking of Jones, I think it's curious that he doesn't get cited by the feds, Gartner, etc., much these days. Jones was in the news about two months ago, when he debunked the Gartner claim that 90% of residual errors will be fixed within only three days (!). But otherwise, Jones seems to be largely ignored now (of course, Yourdon draws on his data in some recent essays)--a curious situation for the fellow acknowledged to be the world's top expert on software metrics. Maybe folks don't like what those software metrics reveal. But Jones's book "The Year 2000 Software Problem" is still must reading for those who really want to know what we are facing. It's an excellent antidote to the b.s. that frequently comes from both sides on this forum.

-- Don Florence (dflorence@zianet.com), March 31, 1999.

Sysman,

Come on, you and the rest of the crew in the trenches know that missing assembler sort exits and assembler subroutines are figments of imagination. Management will assure you that we're not running phantom code written 20 or more years ago, no way. Faded print on the card decks - what card deck? You found them, hey no problem, just run them through the punch in the reproduce mode...

For fun ask one of your young Y2K cobol jockies to set up a new odd sized form. Or perhaps the new breed of operations staff would be so kind as to punch a few decks of blank cards for future use...

jh

jh

-- john hebert (jt_hebert@hotmail.com), March 31, 1999.

Hi John. I'm funnin' about old card decks. No fun though about missing source. I've seen it happen too many times. Often it isn't really missing, it was just catalogued with a wrong name, usually overwriting another program. Many times a new program is started from an old one, and people forget to change the PROGRAM-ID, so even scanning the entire library doesn't help. Just as good as missing when you have a library of several thousand programs. The problem with missing stuff is that you don't know it's missing until you try to find it! <:)=

-- Sysman (y2kboard@yahoo.com), March 31, 1999.

Missing source code is real, I know, we've experienced some, not a lot but some. A fair bit is Assembler with some COBOL. Mostly you can figure out from context whether there are likely to be date dependancies, for example, we're missing the source code for an assembler routine that releases unused space in in a dataset, last assembled in 1972, not likely to be a date in there. I've had another case where examination of the literals in a load module with missing source program indicated that it was a one-off fix added to a job stream in 1992 to fix a particular problem, it's just sat there ever since running on a quarterly basis and doing nothing.

There are real cases though which are not so easy, so far we haven't had any that we couldn't reverse engineer from the input files, parms and jobstream contexts, but I think we've been lucky. From my experience though we would have far less than 1% missing, maybe 10 modules found so far out of an inventory of around 10,000 programs.

What is worse is the Source Code which doesn't match the Load Module, this happens mostly when an emergency fix is done for whatever reason, and the load module gets into production, after all that's the important bit from an 'up and running' point of view but the amended source never does. Probably compiled from some programmer's personal library which gets deleted when he/she quits.

You don't even know you've got a problem until you remediate the out-of-date code put it back into production and find the bug comes back. Then it's fix again.

This points to the importance of getting your remediated code back into production as soon as possible, a fix here and there is no big deal, lot's simultaneously are!

Nemo

-- Nemo (nemo@nowhereatall.com), March 31, 1999.

The second step in a Y2K compliance project is to compile a thorough software inventory. Any organization that is serious about fixing Y2K would have matched all its object programs with their sources long ago. The fact that so many large organizations still have missing source code and have not fixed this problem through source recover or rewriting proves that they are negligent.

-- Incredulous (ytt000@aol.com), March 31, 1999.

Nemo and Incredulous - You have both hit on the same point. Looking at a library listing, and matching source and run-time isn't always accurate. Source programs end up in the strangest places. We have many PC's with 3270 mainframe adapters, and many times, a programmer will download the source to his PC and work on it with a PC editor. Then he fires up a compile, complete with JCL and the source program, does a test, looks good, and signs off, forgeting to re-catalog the source program! Ain't technology wonderful! <:)=

-- Sysman (y2kboard@yahoo.com), March 31, 1999.

Remmeber that, when working in COBOL and using some of the less current DBMS's, (IMS etc.), you can change the DBD's and everything that looks at a specific segment in the Data Dictionary, but you have to OPEN EVERY PROGRAM THAT LOOKS AT A SPECIFIC SEGMENT, because, just redoing the data dictionary does not change the coded logic inside the program, particularly when the programmer uses REDEFINE's to get to the data he/she wants. If teh stuff they want is to the right of the date, you're cool. If it's to the left, you're toast. Particularly is you have a 4GL or PCweenie 6week COBOL Boot Camp graduate doing the code reading.

Chuck

-- Chuck, a night driver (reinzoo@en.com), March 31, 1999.

Chuck

When you say

... particularly when the programmer uses REDEFINE's to get to the data he/she wants. If teh stuff they want is to the right of the date, you're cool. If it's to the left, you're toast....

I assume you're referring to variations in data layout caused by expanding dates to accommodate the century? If so, haven't you got your left's and right's reversed? Data to the left of the expanded field will still be in the same place, data to the right is shoved out of alignment if its being picked up by a REDEFINES or reference modification (eg: MOVE SEG(44:6) TO SOME-VAR)

I'm only nit-picking here 'coz I'm afraid I may have missed your point, I respect what you have to say and don't want to get it wrong!

Regarding Incredulous's comments: Sure, the inventory process SHOULD pick up most of these things, but have you ever tried to do one? Sometimes the code does not even exist in an Object module library or Source code Library, only as a CSECT in a load module, unless you do a CSECT analysis of every load module you don't even know the thing exists until you try to re-link and get an unresolved external reference.

I suspect most inventories have not been well done, a count of source modules & lines of code then a frenzied attempt to find which are still actually running, (we found 20% obsolete, but when we deleted them found out it was only 18%!). Then you start fixing what's left!

Nemo

-- Nemo (Nemo@nowhereatall.com), April 01, 1999.

Sysman, Understand you re: card decks (when was the last time you saw a card punch or card reader of any sort? I know I haven't seen any for at least 10 years.)

In the spirit of the day, my allusion to blank card decks may have been legit. The a lead operartor/scheduler I knew year ago had a job that he'd insert into the production jobs. The console job info was to the effect - Punch blank card for future use and the operator had to put a box of blank cards in the reader - it was kind of an initiation routine for new operators. Funny as heck when they were asked why they were punching blank cards and it dawned on them they had been had. And again in the spirit of the day: The big old IBM disk drives were a lot more massive than today's drives. And head movement could even shake the cabinets a little. With a well written assembler program you could get the run the head back and forth and actually get cabinet 'rocking'. Imagine the expression on a new operator's face when one of the disk cabinets starts walking across the floor...

jh

-- john hebert (jt_hebert@hotmail.com), April 01, 1999.

Good evening John. My first mainframe disk drive was the IBM 2311. It was a box about 2x2 feet by 3 feet high. It used a removable disk about 18" in diameter, 5 platters I think. Total storage, 7.25 Meg. Yes Meg, not Gig. We had 4 for a grand total of 29 Meg! I remember their shaking when the head got going. We had to put them back in a nice even line about every other day. Today, you can put 29 Meg on a pinky fingernail sized piece of disk. The CPU was a 360/30, about the size of 3 refigerators back-to-back. Total main memory, 64K. Yup, ain't technology wonderful! <:)=

-- Sysman (y2kboard@yahoo.com), April 02, 1999.