If you are wondering why computers can't understand year 2000, you are not alone. Fact is computers CAN understand year 2000. Actual problem is: on most computers around the world dates are not entered as "1973" or "1999" but instead like "73" or "99". Computers were programmed this way by people purposely to understand that "73" means "1973" and "99" means "1999". Probably now you are asking the question: what would be the meaning for "00"? , "1900" or "2000"? (Unless MS-DOS, try typing "01-01-00" on MS-DOS, you won't because MS-DOS only woke up on 01-01-80).
For computers, "00" means "1900", and so after 11:59:59 PM 1999, will come 00:00:00 AM 1900, but as you probably suppose, humans would like after 1999 to come 2000.
What kind of people made so insane assumption?. No insane people, but rather people limited by computer resources decided take off two first figures on years.
When computers first began to be programmed in 1950s, a) people was on middle of century and b) computer memory was VERY expensive (yes, even magnetic disks and tapes were very expensive).
(Some keywords to computer history, Babbage, Konrad Zuse, Ada Lovelace, Alan Turing, Enigma cypher machine, Bentchley Park, Differential engine, Babbage, Munich Tech Museum, ENIAC, ILLIAC, MANIAC, MARK I, Manhatann Project, Von Neuman, Batman and Robin ..)
On 50s people used to ask many questions, What's new Elvis song?, Do communists eat children? And more important: why wasting valuable computer memory to store a lot of "19" into? After all (exception perhaps for japanese people), nobody saves money or sign contracts preventing fifty years in advance. On the other hand, most people (valuable to be stored on computer records) were born after 1900. The obvious conclusion was to assume year 00 = 1900, year 01 = 1901 ... year 73 = 1973, year 99 = 1999, saving this way two places (19) on every year, because very few dates would overflow the 1900 century. This appears to be a tiny save, but to business transaction records and punch cards of that time it was a very big saving. People born after Bill Gates first billion dollars uses to think computers were created with 32x CD-ROMS and 8 MB SVGA cards, but I swear to you that 1950 computers HAD NO screens at all, but just wires for chatting with CPU's (following came teletypes). A "big" CPU memory was 2 KB (yes TWO KILO BYTES! , Kind of tiny memory to write "teletype-savers" programs like "Flying Windows" for saving screens, this the reason there weren't teletype-saver programs on that time).
And then? What would happen after 1999?
Nothing to happen, because when 1960s nerds noticed A. C. Clarke "2001" movie, they became absolutely sure that on that distant and marvelous future (2000) it would be enough to tell computers: "please Mr. Computer, now it is year 2000, the right moment you should change the obsolete and human way of thinking about dates....", and Mr. Computer would understand our words and would perform necessary changes on all files and programs at same time resolving philosophical conjectures. Yesterday I asked to my Pentium correct all millenium bugs, but it limited to burp a "general failure". I threw aspirin and glass of water into disk bay hole, it appears to be better now.
Even visionary A. C. Clarke wouldn't imagine the following chat: Dave - "Open the door HAL" , HAL - "abort?, retry?, fail?". Even for smart A. C. Clarke was impossible to prevent PanAm crash, Bill Gates, General Failures, Windows, or even mouses and virtual reality.
Most of software produced on 60s, 70s and 80s were "COBOL" programs (COmmon Business Oriented Language), perhaps because lion's part in computer industry was for big corporations and government organizations. I can't remember some personal IBM-360 or laptop vacuum-tube ENIACs, so probably they didn't exist after all. Even today with 4-th generation languages, OOP philosophy, Visual programming and other marvelous and hungry-resources inventions, some of 60 or 70 percent of today running programs are still those old COBOL programs written into the 60-80s era. (By the way, there is Visual Cobol today, and I am NOT a COBOL-fan).
Why COBOL? Because COBOL is a language (almost unique on 60s) well structured to manage FILES same way business people does commonly with indexing cards. COBOL was the first language suited to manage files through LAY-OUTS, that's to say, to organize information through blocks of data (a feature later incorporated by C and Pascal). Previous languages (mostly BASIC and FORTRAN) had not this ability. COBOL was able to record and retrieve complete sets of well structured information from files and to manage records looking exactly like filling cards, for example:
This way, people was able to program computers exactly like cards into a cabinet, not worrying with internal details about recording and accessing those cards.
But computers DO care of those details, and when recording data, it records one block (or register) after another, for example:
JOHN.DOE....010973Addison.Av....Mary.Dusserl.031186Rose.Street....
|_____ first record____________||_______ second record __________|
If you pay attention, you'll notice the number "010973" glued to "Addison Av." into the record. This is probably some date meaning "January 09 1973", same happening with 031186 to mean "March 11 1986". Please remember this because we will turn here very soon. Remember also this: medium and big-size corporations have thousand (even dozen thousands) programs accessing and updating those "records", and these corporations have thousand of files with dates imbedded into. Each program uses a kind of "mouldering" or pattern for records when looking into a file. Turning to previous example, every program "knows" that first 12 positions of record represent "name of the person", next 6 positions "birth date" and next 14 position "address", starting again with a new person. Probably you are beginning to understand the hell we will have when "extending" years to 4 digits.
To insert two more places on every record, neighbors must shift a little to right side, and this would mean to entirely rewrite all (thousand) files, some of them having hundred million records. When thinking that most programmers and managers who created and programmed those stuffs are actually retired, problem raises to a nightmare level.
And what if people lets all things the way they are? It would be enough to teach computers that "00" now means "2000", "01" means "2001" and so, until "50" meaning "2050", teaching also that for all numbers above 50 to think on "1900" instead, so "51" is "1951", "99" is "1999" etc.
This appears to be a good idea, because like wonderful 50s people thought, it's difficult to overflow a "100 years wide-spread window" for a common computer system.
This *could* be a good idea and *could* be a good disaster, depending on kind of application you are working on. Suppose you need to list records sorted by date. To do this, people reorganize dates in a "yy/mm/dd" (year/month/day) fashion mode because year is more important than month on sorting processes, month is more important than day, day more than hour.... and so on. If you maintain records untouched, computer will think "01/01/01" becomes before "51/01/01", but didn't you tell computer than "51" is "1951" and "01" is "2001"? Ok, you could teach computers a new kind of sorting routines... or to make an intermediate process to sort dates, but if you have already 1000 sorting routines at work, you'll need more 1000 new intermediate processes until Dec. 31 1999 ... and this way nightmare spreads across your company.
You can think on some "layers of difficulty" to solve Y2K problem. First, there is the "easy" layer, then, the "nightmare" layer. These two layers exist because there are many systems NOT programmed in old COBOL (or another old AND hard language, like RPG, even assembly). These newer languages are dBase-like, some Pascal and C versions, and whatever other proprietary language coming into DBMS (Data Base Management Systems) such as Clarion, Oracle, Dataflex or Access, including here new versions of COBOL. These newer languages store dates in a format very more efficient than older COBOL did, cutting off first two digits from years (when asked) just to show years in more readable format, but inside computer, storing complete dates with all four digits for years. That's to say, newer languages stores dates in a proprietary (and efficient) format, no letting programmers to make choices for two or four digits on years. They also take care of all concerning DATE operations, such as lap-years coming, what is the day of week for given date, and when giving two dates, to calculate exact quantity of days between those two dates.
All these operations are very important for business community (Banks, Stocks, Insurance, finances..) because taxes, incomes, profits and all kind of goodies are calculated day by day at a precise rate. Just one misplaced day is a tremendous headache for those companies.
To simplify: Easy Layer is when programmers only need to change the way computer shows and asks dates to people, letting files untouched. Normally dates will appear on screens and reports like "mm/dd/yy" to save space. This is the way most computers show and ask dates, then to modify this you should program the machine to show and ask dates in the "mm/dd/yyyy" format.
If your company has some thousands programs to be changed (to show YYYY instead YY) because new millenium approaching, even so this is the easy part of task, because you should imagine that when someone modify the structure of any file, ALL programs related in some way to this file SHOULD BE modified also, even when these programs nothing have to do with the problem.
Example: suppose on file above you have ONE program that read birth dates, and ONE THOUSAND programs that DON'T read birth dates BUT name and addresses. If you modify the file to add space for two extra years places, then you should modify 1001 programs, one because the date, and thousand because teaching the new file structure to them . You need to change, compile and test 1001 programs instead only one program.
On the other way, if date is complete into file in the format "mm/dd/yyyy", then you need to change (and compile and test) only ONE program, the one concerning to dates problem.
Many intermediate solutions can be analyzed and proposed for each Data Processing Center (here entering consultants and all kind of gurus). For DPC using newer languages, solutions belong to "easy layer", that's to say, just modify programs, recompile and check them. For other DPC, solutions will come through a mix of processes.
Not all COBOLs are the same, there are several companies selling COBOL compilers (some disappeared), there are many versions of COBOL, many complaints, many releases, ANSI and ISO norms, exceptions and standards posted at regular intervals beginning from 1960. Your Data Processing Center could be imbedded somewhere in this universe, running COBOL V7.34 Release ac.8 ANSI X3.23a 1989 for JBM 361 under OS/3 or kind of hieroglyphic.
Many COBOL compilers store numbers using just the half right of bytes (because any digit from 0 to 9 can be represented in binary form using only 4 bits), then for some compilers the internal storage of numbers happens always in the form 0n 0n (hexadecimal), and those four unused bits could be used to indicate that dates belonging to 2000 or to 1900, leaving this way your files untouched in size.
If yours are "short term" systems not needing reports sorted by date, you could adopt the solution of telling computers that all dates below 50 means "2000" and dates above 50 means "1900".
A good rule for ALL systems is to create a "Y2K" environment, duplicate all programs and files in this area, set the clock to 11:50:00 PM Dec. 31 1999 and process all tasks you can imagine in this environment, looking carefully what happens after clock turns to next millenium. When all appears to be ok, then set again the clock to 11:50:00 PM and start again. Remember some Murphy's related laws for computers: "There are not good or bad programs, but just well checked or bad checked programs" or "If your program approved all testing procedures, then it was not tested well enough". The best way is to set back the clock to several days before year 2000.
And what about those tiny microprocessors running assembly programs to control airport communications and radars, airplane engines, washing machines and Tomahawk missiles?
This is an entirely new universe. No big systems with big files here, but I think will continue this novella later.
To know about Y2K survival kit click here
If you want to know what would be computers on next millenium, I invite you to read "The Song of the Swan".
