This is in refernce to NBC program which I saw last night about the Ex-IBMer solving the problem for all Cobol Programs.. Also I remember Ed agreeing to his solution. Can some one expain what it is and will it realy work and how.

Thank You

Sam

-- Sam (Unilinx@Unilinxinc.com), January 17, 1998

Answers

Sam:

I'm not a computer expert, but here goes anyway. Regardless of programming language, computers do their calculations in binary code. Assembly language allows a programmer to write code that the computer can understand regardless of the type of higher level language that was used to do the original programming. Therefore, if an efficient algorithm (logical decision making subroutine) can be written to "capture" all date related variables and then correct the date to the year 2000 instead of 1900 or other erroneous date, then this one program can be used for a wide variety of applications. However, there may be a couple of potential problems before we go off blissfully into the sunset. (1) It remains to be seen just how reliable such an algorithm will be in practice. (As I understand it part of the "capture logic" relies on the fact that dates are never multiplied or divided, but other date-variable characteristics may have to be exploited to identify the rest of the date variables and these additional characteristics may inadvertently identify other non-date variables.(2) Messing around with a program using assembly language is dangerous. Any undetected error generated while patching the assembly language code will cause huge problems that only a handfull of programmers can solve while all the rest of the staff must sit on their collective hands and wait. Finally, you must remenber that this step, while it does constitute the "fix", represents only about 17% of the total remediation process.

-- Roger Altman (RogAltman@AOL.com), January 17, 1998.

Sam,

I think it was a CNBC program that you saw, in which they used approx 5 seconds, out of context, of the 30 minute on-camera interview they did with me yesterday morning. What they broadcast was a portion of my statement that "because the technological approach is unorthodox, it's virtually certain that a potential customer will test it thoroughly for a couple months before entrusting their mission-critical systems to it."

But the BIG piece of my statement was: who cares if it works? It's as if the first-mate came running up to the Captain of the Titanic, and said, "Captain! Captain! We found one more lifeboat!".

Consider: there are approx 130 tool vendors out there already, and approx 70% of the companies actually working on Y2K have already chosen their tools. So along comes Mr. Bemer with his innovative technology. Well, that's fine -- except that it only works on COBOL and PL/I. I bumped into some folks last week from the Defense Logistics Agency at DoD who are trying to figure out what to do with their portfolio of 40 million lines of code that has been written in 77 different programming languages! Chances are that they've already tackled the COBOL problem; now they're trying to figure out what do with their FORTRAN and JOVIAL and CMS-2 and ALGOL and PASCAL and goodness knows what else...

Anyway, to continue the Titanic metaphor, the mainframe systems are only the tip of the iceberg. What about the tens of thousands of PC's that a typical company has -- where we have to look at the hardware, the BIOS, the operating system, the application programs, and the user-generated spreadsheets and databases? What about the embedded systems, of which there are some 50 billion floating around?

I can't help admitting that I'm still a little skeptical about Bemer's technology, but I've stopped worrying about it. Either it works, or it doesn't -- and it will quickly become obvious whether it does or not, once a company tries it out. But in the final analysis, it doesn't matter. Like one more lifeboat on the Titanic, it will have the desirable benefit of saving a few more lives -- but it's not the "silver bullet" that the media is clearly hoping they can broadcast to the nation. Last year, it was the 14 year old kid in New Zealand; this year, it's the great story of "eldery scientist comes out of retirement, invents brilliant solution, saves mankind, earns gratitude of terrified citizens, receives Nobel Prize, and returns to retirement." It might make for a good movie, but it isn't gonna turn out that way in the real world. I wish Mr. Bemer well, and hope that he makes a ton of money -- but there are no silver bullets for this problem.

Ed

-- Ed Yourdon (yourdon@worldnet.att.net), January 17, 1998.

Ed (Yourdon),

Are you sure that Bemer's tool only works on COBOL and PL/1? It's my understanding that Bemer's tool works on object code, so it should be (high level) language independent. Also, in email a while ago, Bemer affirmed that his tool has broad applications and clearly suggested it wasn't limited to a few languages.

IF, and I say IF, Bemer's tool is applicable to most, or all object code, and IF it's reliable, it CAN'T be compared to having an extra lifeboat on the Titanic. Bemer's tool, hypothetically, could put a really MAJOR dent in the IT part of the y2k problem (although it would have no impact on the embedded chip issue).

Ed (Greenberg)

-- Edward H. Greenberg (edward.h.greenberg@jpl.nasa.gov), January 19, 1998.

If a "silver bullet" actually works on object code, then it is limited to the machine language it has been written for. A new solution must be developed for each machine language. It may also depend on the compiler used. Different compilers use different optimizations and deal with different situations in different characteristic ways, using different subsets of a particular machine language.

As for years not being multiplied or divided, don't forget leap year calculations - one of the potential Y2K bugs (2000 is aleap year, 1900 is not). These calculations require taking a modulus of the year...essentially a division. - David Anderson

-- David Lee Anderson (davidan@sttl.uswest.net), January 20, 1998.