Never paid attention to the 2K bug!
No such thing as a 2K bug. It was just a way to scare Americans and make a literal ton of money.
The alleged problem arose when it became apparent in the 70s and 80s to programmers/systems analysts writing new code that it would be prudent to use a 4 digit year variable field instead of a 2 digit year variable field, which had been the norm since the invention of computers. Saving 2 bytes per record was a big, big deal in the 50s, 60s, 70s, etc... to the hardware people because, for example, at DuPont, we processed and calculated sales and use tax on tens of millions of line item invoice records each night in production batch jobs (this was ~1985).
As Y2K got closer, people became nervous as they knew that we only stored 2 digits for the year, so what would happen when the year changed to "00" -- you cannot just subtract "00 minus 99" and expect an answer of +01. We needed "2000 minus 1999" to obtain a positive "01" as the answer.
Most of the systems like sales and use tax were very old COBOL or WORK-10 Cobol-like generated code systems and changing the LRECL (logical record length), which was fixed at about 1000 bytes, to add 2 additional bytes for the 1st two digits of the 4 digit year would be impractical and a waste of money as many of these systems needed to be re-written anyway because RAM and hard drive disk space were replacing magnetic tapes with lightening speed because their cost had decreased so much. (Often, these very old mainframe programs were limited to 64K RAM and 10-25,000 bytes of hard drive space. Anything over that - went on magnetic tape (mandatory) and was very, very slow - execution time.
I put out bids to rewrite at least 50 of DuPont's financial related systems that were identified as having 2 digit year fields; I ended up finding over 100 more programs that utilized 2 digit years at some point in the program/app, but most of these were written in non-COBOL, usually PL/I.
Re-writing all of these programs in IBMs latest version of COBOL - COBOL VS II - was a lot of fun and thrilling because only 2 or 3 systems ended up needing magnetic tapes because of the new rules on how much [RAM and hard disk] resources a single program/app could use. We just wrote them smaller so as not to trip the limits. Our production time went from 12-15 hours per night ultimately down to 5 hours. So now it was possible to start the entire job from the beginning any any time of night if the JCL Job ABENDED (abnormal termination - like a BSOD).
In the end, many areas of DuPont were still not ready for Y2K, so I took my project team, changed the subtraction year result to a signed field (+/-), subtracted the years (e.g.,
00-98= -02 -- then would change the sign to positive (
+), so now we had a
+02 subtraction years as the result. Pretty simple, huh?
We continued rewriting these 2 digit year programs, even though some bosses asked why we could not continue changing the signs), to which I replied "it is just too dangerous to continue and cheaper in the long run to rewrite the apps because of the money we're saving by using increased RAM and disk space".
I reminded them that we paid dearly for every second of CPU time consumed and sorting 10 or 15 tapes together were killing us on such costs.
I prepared estimates and finished up all of the contracts by 2005 or so.
John
LOL