Cobolgreenspun.com : LUSENET : TimeBomb 2000 (Y2000) : One Thread
Sir I hear a lot of talk about the programming languag Cobol and it being instrumental in solving the y2k problem. Changing the 2digit date field to a 4digit. What's your opinion.
-- Shaquan Blake (firstname.lastname@example.org), September 16, 1998
COBOL is both the blessing and the curse for Y2K. Unfortunately, many of the mainframe Y2K problems are actually COBOL applications (as well as numerous other arcane languages.) Not to sound like the National Rifle Association, but COBOL is a tool. The responsibility lies with the person using the tool. Many seem to think COBOL is 'dead'- that is a shame. Make a bank withdrawl- its probably a COBOL application transaction. Make a plane reservation - somewhere, down-deep, its a COBOL application transaction. Currently, I am involved with a Windows NT, SQL Server financial application for a large health organization (no names). What I am using to prepare transactions for this new system - PC COBOL. So, two things: COBOL is part of the solution - and intertwined into the problem; and, it is a 'technology' that is both 'obsolete' and will be with us for a good long time.
-- ed condron (email@example.com), September 16, 1998.
Granted, the fault lies in the program, and the entrenched databases read by and written to that programs. The operating system and process used to write the program are relevent only to those inside the problem trying to fix it/prevent it.
The presence or absence of COBOL isn't particularly relevent. (The relative few experienced users of COBOL is important in finding qualified people who can "fix" old programs.
-- Robert A. Cook, P.E. (Kennesaw, GA) (firstname.lastname@example.org), September 16, 1998.
The only reason that COBOL is instrumental is that a huge chunk of existing business applications (anyone know a percentage - they told us 90% in college 10 years ago) are written in COBOL. So to fix them, you are going to work in the language they are written in. Just like you wouldn't edit a French Novel with English corrections, you'd use French.
There is nothing inherently "good" or "bad" about COBOL. Y2K problems exist in applications written in other languages - I've seen C programs (for non-techies "C" is considered a very different language from COBOL) with 2 digit years.
-- Ray Givler (email@example.com), September 17, 1998.
COBOL is a fairly rigid language, but it is also relatively easy to learn. In my consultant days, probably 80% of the applications were in COBOL. The rest were assembler, FORTRAN, PL-1 and a handful of other special ops. COBOL often gets an undeserved bad rap. As an aside, I can tell you all (since we are all friends, right?) that I get very irritated by some of the poo-bahs of the Y2K lecture circuit who call the old COBOL programmers of the 60's/70's "stupid" or "careless" or "unthinking" for using 2 digit dates. It was a CONSCIOUS decision given the cost/performance constraints of the computers of that era. A standard punch card could only hold 80 positions of data. Computer memory and storage media were very expensive. Sorting was done by running cards individually through a separate sorting machine one column at a time. I once sorted a deck of 15,000 cards on 40 positions. That means the sorter fed cards 600,000 times. It took hours. This desktop I'm on now could sort the same data in about 5 seconds!! Computers were largely isolated from one another and everyone believed that future computer systems would totally eliminate old methodologies and standards. Wrong.... Instead, the computer hardware developement far exceeded innovative software developement. The old standards were simply swallowed whole and data standards were carried along. Y2K is actually not so much a programming problem as a data standard problem. Anyway, its not the fault of the 60's programmers. Blame the 80's IT managers who never reviewed data standards they inherited.
-- R. D..Herring (firstname.lastname@example.org), September 17, 1998.
I'll go along with what has been said here, but make it a bit stronger.
COBOL has absolutely NOTHING to do with Y2K issues per se. The majority of existing business systems are written using that language, so most of the business system Y2K problems are going to exist in COBOL programs. Therefore, they will also be fixed using that language. COBOL as a language has nothing to do with why programs written in COBOL have Y2K problems, and it darned sure doens't have anything to do with all the Y2K problems in non-COBOL programs.
-- Paul Neuhardt (email@example.com), September 17, 1998.
Yeah, I also get sick of the journalists that chalk up the Y2K problem to "poor programming practises" or some other equally insulting phrase. I'm convinced that the majority of journalists are far more interested in spewing out sensationalist crap that sells rather than well thought out material. They seem to have very little sense of history or put it any real research at all. Look closely at the articles that talk about poor programming practises. Somewhere is most of those articles is a reference to "planes falling out of the sky".
Wouldn't it be ironical though if a plane actually did fall out of the sky.
-- Craig (firstname.lastname@example.org), September 18, 1998.
As far as the "planes falling from the sky", if one does I bet it's an Airbus. They've had incidents of the flight computer "fighting" with the pilots for a few years now. It's already caused some crashes, since the computers are programmed to override the pilot and not the other way round like Boeing and McDonnel-Douglas jets are programmed. Give me an old, analog 707, 727 or DC-9 any day.
-- Vern Moore (email@example.com), September 19, 1998.
Be even more ironic if the plane didn't fall out of the sky, came in for a landing and the runway landing lights (as well as the rest of the city lights) went out.
Or it landed and there were no rental cars available, or ones that could be rented.
Or it landed but they couldn't route luggage to the terminal.
Or it landed and they couldn't run the "tram", or "subway" to move passengers.
Or it landed, but they had no "new" fuel available to take-off.
Or it landed, but there were no routing instructions (payroll, reservation, crew assignemnts, in-flight food, baggage, mail, gate assignments, etc.) to tell it where to land next and who to take there.
-- Robert A. Cook, P.E. (Kennesaw, GA) (firstname.lastname@example.org), September 20, 1998.