9/9/99 to bring a preview of armageddon? - take a look!greenspun.com : LUSENET : TimeBomb 2000 (Y2000) : One Thread |
Nines in the date field will cause havoc.Having been part of the industry for the better part of 30 years, I would like to address this fable.
============================================================================ "DIAL 999 for yet another computer bug. That's the word from the Institution of Engineers, whose experts have warned that the numerical combination 9/9/99 is lurking in some large computers, where it is potentially as lethal for data as is the combination 1/1/00. This bug does not affect desktop machines. Only ``big iron'' mainframe computers, and then probably only those using elderly Cobol systems, are likely to be affected." ============================================================================ First, the "all nines" method of EOF (End Of File) marking was done on a "record" basis. That means that all fields within the record contained the numeral "9" in them. This was *NOT* used in COBOL programs but in early Fortran-I programs. The COBOL File system automatically identifies (and always has) when the last record has been processed on a file.
Second - the date 9/9/99 is generally stored (in COBOL) in the following format: "090999" in a field defined as either numeric or alphanumeric and 6 bytes in length. The suppression of zeros is only done during the process of displaying or printing the data - this is also when the slashes or dashes are entwined in the output.
Third - the date "99999" in Julian format is/was used as an expiration date for files. This is the date that is used by the mainframe computer's file management system to release and scratch (basically delete) the file. The way Julian works (if you are not aware) is as follows: YY=year, DDD=day of the year - So this would mean that today's date (May 14, 1999) would be "99134" as it is the 134th day of the year 1999. If this version of the Julian date were to be maintained on mainframe systems (and it still is for file control), the files would "NEVER" be expired since we can never reach a day number beyond "366".
============================================================================ "``People programmed in different ways. One used a string of nines in the date field to mean the record had to be treated in a special way, or that the record was the last one in the file; it was an end-of-file indicator. The problem is rooting the strings out of where they have been embedded." ============================================================================ Many programmers consider it to be almost an "artistic license" to code programs in their own style. I am one of those. I will agree that there is the "possibility" of special codes being inserted into records to cause the default handling of data to be bypassed in favor of specialized logic. This would be quite easy to find in the source code because your search would be for a string of 9's stored either as an integer or the value of an Identifier within Working Storage (COBOL). Again, it is not a problem - even when 100's of millions of lines of code are involved - to find these strings.
============================================================================ "In general however, and even if mainframe software had been upgraded, the string of nines problem might have propagated within the system, he said." ============================================================================ This term "propagated" right along with "systemic" really bug me (no pun intended). What "mainframe software" is this individual talking about? The Operating System? - It doesn't care what the application program logic is doing - it's only function is to manage memory and the facilities (Input / Output devices). The Application program? Well if it has been "upgraded" then there isn't a problem. The Data? Well OK if you stored nines in a date field 30 years ago and have not altered that field since, the nines will still be there. See the first of my retorts to this logic.
============================================================================ "Where 9/9/99 was used as an end-of-file indicator, it could malfunction to join files together, corrupting data in anything from library cards to insurance policies to medical databases, he said." ============================================================================ It could also flip the switch that causes the printers to print out pictures of Mickey Mouse in strange EBCDIC characters! Not really, but then you must remember that the programmer had the ability to alter the way data was processed. This "join files together" could *only* be done if that was, indeed, the programmer's intention. "Corrupting data" - Not bloody likely. If the File Management system were to "delete" the data (which it won't - see my retorts above) the data is thereby *gone* NOT "corrupted".
============================================================================ "``Responsible organisations have already taken action to ensure their data is protected,'' he said" ============================================================================ Back in the olden days we called this "backing up the data".
============================================================================ ``But software is always failing on big systems; people have to understand that. A few years ago, one of our big banks had a problem that cancelled the credit limit on their ATMs and people could draw out whatever they liked. It was there for only a few hours, but it occurred,'' Peterson said. ``The 1999 blip may be bigger than normal, but it will still be just a blip among blips.'' ============================================================================ Yes there are frequent failures among mainframe software systems, but rarely do these failures result in the loss or corruption of data. The "big banks" part of this paragraph must have been one of the closest held secrets within the industry - as it is that part of the industry I have been primarily engaged in for the span of my career and "I" have not heard of it.
============================================================================ "The other problem with the number nine that computer users needed to beware of was 29 February 2000, he said." ============================================================================ Finally something the old COBOL Dinosaur can relate to. Yes this has been a problem, but is very easy to find and repair.
In summary - Many people who have written articles like this have little or no understanding of the COBOL language and/or mainframe operating systems. Mainframes are not, in any way, functionally comparable to a PC or even a "big" server system. The COBOL Language has been developed over the last 35 years or so and was one of the first "second generation" languages to have been utilized within the corporate environment. Furthermore COBOL is not a dead language. On the contrary. There have been many major advances with this language and as such has been standardized by ANSI on numerous occasions. There are new versions of Object Oriented and Visual COBOL developed and utilized within the PC and Client Server ends of the industry. The usage of COBOL lends itself to cross-platform portability more than *any* other language. Additionally legacy COBOL applications can be quite easily updated and ported to different platforms with little or no loss of the application's embedded business logic. Why then have colleges and universities gone away from COBOL? This is a trend that started about 15 years ago when COBOL was, for the most part, a Mainframe based language. The costs of maintaining a mainframe computer solely for student laboratory use made it economically unfeasible for most colleges. These schools embraced "C" and Fortran as they could be used in a PC and small Unix platform environment. Additionally there was not, at the time, a PC based version of COBOL which was ANSI Standard. This has changed dramatically since.
I offer this for your consideration in your attempt to better understand the problems we have at hand in the world of information technology.
Yours in COBOL... Dino!
-- COBOL Dinosaur (COBOL_Dinosaur@yahoo.com), May 14, 1999
Y'all must be workin' with a diffrent COBOL than my programmers were in '79, cause all of them had to tell IMS and our batch programs which record was the last in the file. They used "999999" which happens to be all nines in the DATE-REC field. Now, this ain't equal to "090999" or "9/9/99" or.....CHuck
-- chuck, a Night Driver (rienzoo@en.com), May 14, 1999.
Howdy,We've been thur the 9/9/99 problem a couple of times. Many of the programmers here, including myself, didn't think it's a big deal, except for Chuck I believe. I have great respect for Chuck, and don't doubt him at all. That's part of the problem, there are so many ways to do things in this business, and no two programmers think alike. I'll see if I can dig up a couple of threads for you on this in a while. I've been off the forum for a couple of days and have some catching-up to do now. I see my friend Mr. Poole is looking for me... Later. <:)=
-- Sysman (y2kboard@yahoo.com), May 14, 1999.