New Year’s Eve: Musings on Y2K
At 3pm PST on 31 December, 1999, I sat down at the computer in my home office in Yakima, Washington. I logged remotely into the network at HQ and started monitoring our systems. The most critical moment would come at 4pm local time. We were in Pacific Standard Time (PST), -0800 UTC. In other words, at 4pm in Yakima, it would be midnight in Greenwich, England, where the time zone aligns with Coordinated Universal Time. (Coordinated Universal Time is abbreviated as UTC, not CUT, because there are actually other languages in the world besides English, and… never mind. Look it up if that story interests you).
Anyway.
The GPS satellites run on UTC, and our entire multi-state operation depended on GPS timing. My first hint of system failure because of a Y2K bug would occur at midnight, UTC.
Beginning at 3:55pm I began testing the major system once a minute. At 4:05pm I sent out the notice to corporate management that all was well.
I tested hourly, then, but the next critical moment wasn’t until 9pm PST, which was when midnight occurred on the US East Coast. Our equipment was all in MST and PST, but some of our many telecom providers might have systems with local time coordination in some other US time zone. (They’d all be using GPS now, but – this was 1999, and US telecommunications had plenty of legacy systems with other clocking methods).
In the end, nothing failed. Our entire system worked.
This wasn’t because Y2K was overblown.
It was because we replaced our billing system, which wasn’t able to generate an invoice after the date flip.
It was because we did software updates on several proprietary systems that would have failed.
It was because we did firmware updates, too.
Equipment inventories.
Application inventories.
Operating system inventories.
Software version inventories.
Firmware version inventories.
The reason January 1, 2000 seemed like such an ordinary day is because of the MASSIVE amount of work and money spent to make it ordinary. There are unsung heroes around the world who put in the work to update or replace systems that would’ve failed otherwise.
If you’re one of those people, I would love to hear your story.
@fifonetworks
It pissed me off when people called it the Y2K Bug. It wasn’t a bug. It was a mgmt decision. In the early 80s I was a COBOL programmer at a big east coast bank. We were converting the systems from IBM 360 DOS to 370 MVS. Years were encoded in 2 bytes to conserve limited RAM. I suggested increasing years to 4 bytes because Y2K. Was told by mgmt not to bother, “We won’t be using these programs by then.” He was right. Bank was gone by 1998.
@Extelec@fifonetworks I was a little more fortunate in that I worked with PBX's where a failure would not be a disaster, but would have had problems with any time profiles thinking it was the wrong day.
various test were made on all equipment, most passed, some needed software updates & for the rare system that was so old it could not e patched we advised the customer to change to a year that would match
we were on standby over the NYE, NYD with a huge bonus for doing so
@fifonetworks second hand, alas, but I knew someone who was on the JMU Y2K task force, they started in 1994(!) and replaced accounting and HR software by 1998 when I lost contact. They were working with PeopleSoft at the time on the student admin system.
Add comment