Remembering Y2K ... where were you?
Summary: What were you doing ten years ago? Chances are good that if you were an IT pro back then that you were hard at work battling the dreaded Y2K bug.
What were you doing ten years ago? Chances are good that if you were an IT pro back then that you were hard at work battling the dreaded Y2K bug.
I'm not going to waste pixels and inconvenience electrons by giving you the background to the whole Y2K thing. If there are any youngsters out there who want the background on this, I suggest you read this excellent Wikipedia article.
I remember the hype. I remember the survival kits and ration packs that were on sale. I remember updating BIOSes and checking and patching countless pieces of hardware and software. Then there was the testing. Lots of testing. It was a busy time.
And then I remember the rollover, when thanks to all out efforts the power stayed on, planes didn't fall out of the sky and the McDonald's "99 Billion Served" didn't roll back to zero.
It's odd to think back to how genuinely spooked people were by the idea of their hardware suddenly stopped working. The reason, I think, was that we'd allowed technology to infiltrate so many aspects of our lives without giving it much thought. We'd walked into a tech trap and Y2K threatened to throw us back into the stone age.
Note: I'm not going to get into how technology has infiltrated out lives so much more since 2000, and how we're more vulnerable than ever to it being taken away from us. Don't have nightmares!
Ahhh, good times!
Feel free to share your Y2K thoughts and memories here.
Kick off your day with ZDNet's daily email newsletter. It's the freshest tech news and opinion, served hot. Get it.
Talkback
I did nothing
Everything continued to work Jan 1, 2000. The only bug I had to fix was a leap year algorithm error on some logfile outputs in code I inherited. It was basically the same bug as why Excel has two date bases for calculating date differences.
Total non-event for me, made a lot of folks look stupid worrying about it.
"Not Y2K Safe"
There were some legitimate issues, but very few with PCs or PC software.
Oh yeah ...
Blaming it on PC sales?
It was all combined
Y2K and PCs
If you had a problem in your organization in 1985, you couldn't just search the Internet and go out and buy a professionally designed software package. You had to spend months defining the problem and a solution and then you had to ask your programming staff to create a solution by adding code line by line to a program that may have been started years before by someone else. Usually it was a problem defined ambiguously within the organization outside of the IT staff by people who assumed that is was hard to get a computer to count all the way to a million but easy to get it to figure out human speech or the difference between pictures of a male and a female or a dog and a cat. The programmer's were valued according to their ability to define, design, and code a problem/solution set. Their supervisors were valued according to their ability to decide if the new code and all the associated costs would be more valuable than the expenditures thereon. (Costs of development and upkeep.) Also their ability to communicate to others in the organization which were appropriate jobs for the IT dept to even take on.
Same here
RE: Remembering Y2K ... where were you?
And im glad you did not downplay the great success the Y2K "bug" was, and that it was real and was one of the major IT success stories.
I was travelling up and down the east coast of Australia, from Queensland to Tasmania, upgrading VMS SCADA system on Dec ALPHA's and VAX'es performing BIOS and software upgrades and yes, lots of testing.
These were for critical services like Gas, Water, Sewage, Electricity systems, and if they were not upgraded they WOULD OF FAILED.
If not for alot of people identifying the problem and taking the necessary steps to fix them.
A great IT success story, it's also a bit funny how concerned essential services were with this problem (rightly so).
Providing full manual fallover control, backup generators, and extra staff to be employed on call.
A 12:00 I was watching fireworks at Newcastle harbour, and at 12:10 I withdrew money from my ATM just to make sure :)
(or in the hope it would spew out wads of money).
I remember that!
Heheheeh
Nonsense!
The billing systems might have failed but the services themselves and the embedded systems controlling them have no dependency on "year".
Systems that paid interest were quickly fixed, ones that charged interest were mostly fixed, pretty much everything else was hokum.
Taking credit for a great Y2K success is like using this great elephant repellent I sell. Now that Obama is in, I'm working on some new and improved donkey repellent.
Who are YOU to decide what is nonsense?
Date/Time have a way to creep into systems (data and logic) you would think don't need/use it.
I'd love to hear the details!
Bring 'em on, enquirering minds want to know.
If there were a lot of actual disasters averted I'd expect the folks involved would have been bragging about it by now.
As I said, systems paying or charging interest are not interesting, as the problems were obvious and fixing the paying systems top priority, the systems billing interest could wait and see if the customer noticed :)
Not the billing system the SCADA
They control things like DAM Stillway gates, water storage tanks, pumps, filters, airation systems, sewage treatment, gas supply, electricity (power station CONTROL).
And if you went on site with an unpatched system and rolled the date forward to 2000 it FAILED, so no electricity, no gas, no fresh water, no sewage system.
If we did nothing come 12:00 midnight, all hell would have broken loose, when sydney's water, sewage, gas, and electricity stopped, or the local dam flood gates opened !!
Or the sewage system "backed up", or as someone said the pumps run backwards flooding your house!!.
And it was main due to old legacy code, often from FORTRAN or COBAL starts, in the days when we did not have desktop supercomputers, and at a time when the programmers (1960;s,70's) NEVER expected their code to be still usefull and used in 2000.
Remember 8-bit CPU's were standard, and a full date field was not felt necessary.
Nobodies actual failt just a quirk of computing.
But a great success story, caused it to be a non-issue,, (BY DESIGN) not by dumb good luck.
(Im glad I was incharge of those systems and not you, and that we did not flood out thousands of people by opening up a dam !).
So your dam software ...
"Remember 8-bit CPU's were standard, and a full date field was not felt necessary."
I'm curious as to why spillway or most any control software cares about what year it is? I was very close to the hardware in the 8-bit days, real-time clocks were very much a luxury, and counters wrapped around a lot faster the 1000 year intervals.
I'm not being obstinate. I'd genuinely like to know which of these critical embedded controllers actually used the year in any way other than for log file outputs.
I'm sure IEEE Spectrum or American Heritage History of Science and Technology magazines would fall allover an article documenting the details of how the world was saved.
Not so much the PLC's in the SCADA
It's this level of control this is mostly affected,
Like in any factory, if the supervisor loses the plat and cannot function with the custom application, the DB or the OS erronious results will happen (and did).
Providing incorrect control instructions to the PLC's and making the works go kaka gogo. :)
So we had to basically patch the bios of the ALPHA's, upgrade the VMS OS, and the SQL Database, and re-write the custom app.
Yes, these system's are designed fail safe, but opening the flood gates of a dam, might be the fail safe mode if the PLS is getting confusing instruction from the SCADA.
other other fail safe, is the shut down, and shut down is not a good mode if you need the services.
So it's not just that the information was wrong, it was that the supervisor computers would barf, and basically the ALPHA's and VAX's would move back to EPOCH 1, lose Database, and the custom supervisor software, and OS would drop it's load.
Then things start to get bad, but certainly the supervisory control know's about day, time, year, and does specific action's based on that.
Power control, and power efficiency is a big thing in large SCADA plants, $100,000 can be saved a year with smart use of off-peak energy.
But it was basically an IT issue, with the VAX's and ALPHA's and OS and our SCADA application.
SCADA makes a great deal of use of date/time
This is not the billing system, that is a seperate system alltogether.
SCADA system have no concept of "users" or "clients" they care about demand and supply and control.
The actual PLC's will have date/time information and a part of SCADA is the "supervisory" bit with is a high end computer system, (ALPHA's or VAX's in my case) running VMS.
The ALPHA's firmware required modification (upgrading), and the custome supervisory application (and SQL database) required extensive modification and re-writing, as did the OS (VMS 7.1 I think) also required upgrading.
from memory we had about 15 dates to check, 2000, 2013, 2038 I think they were.
And prior to upgade during testing they would fail EVERY time.
So if you think not having electricity, gas, water, toilets, or having your local Sewage system overflow, or your nearby DAM open and flood you.
Then it was a non-issue, but if you happen to think those things are important, I know for sure Sydney, Newcastle, Brisbane, Hobart, and many towns in between would have well, it would not have been the end of the world, but close !
again, a huge IT success story, that fixed before it appeared.
(I like hot showers, and loo's that work).
With a name like aussie_troll ...
You are making very general claims about a wide variety of systems, same as I do about my new improved elephant and donkey repellent.
If you've actually fixed one such system we'd love to hear the details, I could put you in contact with the editors of IEEE Spectrum magazine and I'd bet they'd go for an article telling the story, which obviously is history that needs documenting (if it ever actually happened).
the fact it was a non-issue is the success
What you clearly dont understand is that SCADA systems are complex, distributed computer and database systems.
Each outstation will have banks of PLC's and it's own supervisory computer, (the VAX or ALPHA) Running VMS and our custom SCADA application based on an SQL database.
Each one of these outstation mini-computers, is connected via dedicated land line or radio link to a central SCADA mainframe also running VMS, the entire system is a high powered VMS cluster, with the outstation's responsible for their own specific plant and function's and their own sections of the database.
These machines and all the other outstations sync their part's of the entire DB to the mainframe, datasets are date/time stamped and validated, the central mainframe and it's workstations allow control of the entire system.
If any outstation went haywire and started providing SQL datasets with incorrect date information (say 1970), then the central mainframe and the SQL queries the system is based on will probably not pick up the data or reject it as 'unsafe'.
when you have a real time, highly distributed system you need to be aware of time and date information, and year, and historical information is loged, and that information is used to make real time decisions now.
If any aspect of the system fails, with computers it generally means it all fails.
So it's never going to get in the new's or be interviewed by IEEE by saying you checked you're car's breaks today, they needed fixing and as a result you did not have a crash.
Where I come from thats not news, and I would rather not be in the news for not doing my job and being the one held responsible for blacking out the city of Sydney on New Years eve !!!.
Thats the kind of publicity I can do without.
(and seems unlike you, I dont need to be a hero, just do my job).
Part of the problem...
Of course, nothing happened and life returned to normal. All of the doomsayers moved on to Global Warming, West Nile, and whatever flue is in season. Of course, now we know that the world will end in 2012, so none of it really matters anymore, does it?