YDKF Episode 178: Y2K

Posted by robohara | Posted in YDKF | Posted on 08-17-2016


Support You Don’t Know Flack on Patreon.com/RobOHara


On Episode 178 of You Don’t Know Flack I discuss Y2K — the hype and the reality, from someone who was actually there and was actively fixing computers. This episode includes some Y2K commercials, discussion of Y2K-specific magazines, and lots more, including information about the next apocalyptic event, Y2038!

Link: L.A. Times Article (4/1999)
Link: Novell Update
Link: Confirmed Y2K Issues
Link: Year 2038 Problem


You Don’t Know Flack’s Official Forum
You Don’t Know Flack’s RSS Feed
You Don’t Know Flack’s iTunes Feed
You Don’t Know Flack’s Facebook Page
You Don’t Know Flack’s Voice Mailbox: 405-486-YDKF

To check out other podcasts I record including Sprite Castle, Throwback Reviews and Multiple Sadness, check out RobOHara.com/podcasts. There you can find iTunes and RSS feeds for all my shows.

You Don’t Know Flack is a proud member of the ThrowbackNetwork.

Support You Don’t Know Flack on Patreon.com/RobOHara


Comments posted (2)

I remember Y2K well. I had just moved back to Arkansas from Wisconsin and managed to land a job as a “Y2K Satellite Coordinator” at the local NBC station. I was told that the job lasted until just after the beginning of the year, which it did. Here’s what it entailed: under normal circumstances, satellite-fed syndicated TV shows were fed once per week. Even if the show was nightly, llike Seinfeld reruns, it would feed once a week in a 2 1/2 hour “gang feed”. The control room guys had a set number of videotape decks with which to catch these, and more than one of each feed was scheduled. A normal satellite coordinator would work up a schedule, post it in master control, and check the resulting tapes (basically, skim through them, watch them for busted feeds, audio/video dropouts in the satellite signal, tape problems). If any show’s sat feed was completely missed at every opportunity, you’d have to call the program vendor and order a physical copy to be FedEx overnighted. That would be a normal satellite coordinator.

My job was more complex. Starting in late November, the program vendors started doubling, tripling, quadrupling up on feeds of their shows, as far in the future as they had completed programming. “Emergency reruns” were fed for shows that were produced on a weekly basis. The theory was – as you mentioned – “the satellites will all fall out of the sky”. Now of course they actually wouldn’t, but the concern was that they would stop working. (Aside from the spy sat bugs mentioned, which were the result of bad patch code, none of them did.) But still, I had to come up with a schedule for our already overworked, underpaid master control staff to follow to catch, say, a month’s worth of Seinfeld nightly reruns in one short sharp shot. I had to order extra blank tapes to accomodate all of this recording. I had to carefully schedule downtime for each deck so engineering could clean heads because of all of this recording. The idea was that we would have 1 or 2 months’ programming on tape, in the bag, just in case the satellites did stop working.

I’ve never watched so much Seinfeld in my life. By the end of that, I really was saying SERENITY NOW!!

And of course, none of it was necessary. But thanks for the cash, NBC.

Y2K was a primary focus of my job for about 3 or 4 years at the Semiconductor plant.

The project was composed of multiple stages:

The first stage was discovery: we hired a company to scan all of our systems looking for software that would be affected by the Y2K effect (or bug or whatever it was. I’ll just call it effect). My role was minimal: give the vendors access to our machines, point out the location of code. Since I was a programmer in years past, I was asked to list the software I knew would be impacted and and maybe comment if any of it needed to be fixed (Answer: YES).

Second stage was planning: reviewing results, prioritizing affected code, develop a testing plan, yadda yadda yadda. I was in a bunch of meetings during this period since I was to play a major role in the testing.

Third stage was code review and modifying. I was asked to review a major program I wrote when I first started at the plant and what changes should be made. My conclusion was the program (which extracted data from a database and generated a report) would only be a problem if they used the date fields AND they crossed the 1999-2000 boundary. Since most users only cared about the current week and the current month, that would not be a problem. A couple users tried the date extraction across the boundary in 2000 and they ended up with a really large report. When they complained, I told them why it happened.

Fourth stage was testing. This is where I spent most of my attention. My job was to set up a test system (since it was a VAX it was not cheap – think six figures) and use it to test the modifications to the code. When the programmers were ready I would roll the data forward to a post 2000 date and the programmers would install and test the code. When they were done, I would restore the correct date and time, restore the systems disk from backup (since the date change messed up all sorts of stuff) and then reboot the machine. This process lasted nearly two years, IIRC.

Fifth stage was implementation. Programmers installed the code into production, tested it and made sure everything was good for the new year. We did all sorts of planning for the changeover: failure procedures, cell phones with walkie-talkie capabilities, contingency procedures and so on. I once complained that perhaps we were over planning and spending way to much time on unlikely scenarios. I was told about how much planning they put into the D-Day invasion to which I replied that all those plans were worthless the moment the soldiers landed on the beaches.

Finally the date change happened and..no major problems developed. Minor things happened that didn’t affect production and they were easily fixed. No one called each other on the expensive cell phones. No frantic rush to the plant to fix code. No calls from the customers (at least related to Y2K anyway). One big non-event. Naturally, we celebrated and patted each other on the back for a job well done.

This, of course, got people wondering if the whole thing was just one big fraud to make money for IT folks. Some of those comments actually came from plant management. Naturally, our management responded and reminded them that this big non-event was due to our excellent work. The objections died down but it left a bitter taste in the mouths of those of us who spent all that time working on the project.

Based on my conversations with colleagues and friends who worked at other companies, my experience was pretty typical. Especially the part about people wondering if it was all an elaborate hoax.

Write a comment