I have to retract my contention that Errington is Hamasaki. In fact, he's not even a Doomer. In further fact, he needs to send a copy of this article to Cory, because Bro' Have-a-saki might experience epiphany.

In a 1998 article entitled The Year 2000 Farce (emphasis mine), Bro' Errington discusses a common-sense approach to addressing Y2K problems in batch-processing.

In plain English: you create a data file in which all dates have been moved back, input that file to your application, then re-run your date-changer on the output to adjust everything back up.

The article is very good. (There's an nice photo of the boy there, too. Have a look.) But in view of our previous (and sometimes rancorous) discussion in threads like OK, Poole let's get down to the nitty gritty, I have to wonder if he has realized that if HE could think of workarounds like this one, so could others?

And that perhaps tricks like these, COMBINED with remediation efforts, COMBINED with a little vigilance, etc., help explain the marked lack of Y2K problems to date?

This falls under the general heading of "workarounds." No, Peter's idea won't work in every case. There's no such thing as a "magic bullet" that will work on every single system in the world.

But that's not the point; this is: imagine that world filled with bright people -- a whole bunch of Erringtons, if you like -- each faced with a problem: I have to keep this system running after January 1. How can I do that?

In the control systems at my station, we weathered the rollover with our audio network by simply setting the date back. Neat, clean and simple (and I can't resist: Before Jan 1st, I stated too many times to count that this was a perfectly viable option for most control systems, but the Doomers would never accept it).

(I guess it was just too simple. I was dismissing 98% of their fears about electrical power, water supplies and sewage treatment with a single sentence. They couldn't believe that they could be That Wrong.)

(But I digress.)

Of course, sometimes the workarounds require ... well, a little work. My copy of MSVC++ 4.0 STILL wants to cram 1900 into some of the date fields. I simply change them manually.

But there you go. Given that Mr. Errington himself indicated that (in batch processing, at least) Y2K was essentially "a farce," I am confused; why is he so incredulous that *I* might expect to see a few handy workarounds like these in places like AFGHANISTAN, ITALY, RUSSIA AND INDONESIA ...?

Couple that with my contention that, in general, we are nowhere near as dependent on computers as the IT/IS Gurus think, and you'll have the reasons for the Non-Event.

ReasonS. There's not one single reason; it's a combination, all brought to you courtesy of some smart guy or gal ... like, say, Peter Errington ... ?

-- Stephen M. Poole, TTMHMIY2K (smpoole7@bellsouth.net), May 18, 2000

Answers

http://hv.greenspun.com/bboard/q-and-a-fetch-msg.tcl?msg_id=0039HY

-- (Also@see.this), May 18, 2000.

But in view of our previous (and sometimes rancorous) discussion in threads like OK, Poole let's get down to the nitty gritty, I have to wonder if he has realized that if HE could think of workarounds like this one, so could others?

And that perhaps tricks like these, COMBINED with remediation efforts, COMBINED with a little vigilance, etc., help explain the marked lack of Y2K problems to date?

No doubt there is some truth to what you're saying there, Stephen. A variety of factors are probably responsible for a lack of significant problems since Jan. 1.

My opinion though is that workarounds have been over-rated as an option for dealing with y2k. Fix-on-failure may have been a viable option for a small business that uses PCs, but risky for others. The way I looked at it last year was this: if it takes a large company two or three years to remediate y2k and they waited until 1998 to begin, how much difference is a few days work at the beginning of January 2000 going to make?

The interconnectedness of systems, especially in more computerized nations like the U.S., made predicting the correct outcome for y2k dicey. TEOTWAWKI wasn't likely because it looked as if we were going to have electricity, but whether it would be a non-event, a bump or something significant (shortages and/or a recession) was a hard call.

-- My (2_1/2@cents.worth), May 18, 2000.

Looking at my message there, I see I gave my opinion about fix-on- failure while mostly ignoring Stephen's point about workarounds. Workarounds may indeed have been a significant reason why problems as a result of y2k have been few.

Could be.

On the other hand, was there any way of knowing before the rollover just how effective workarounds would be? No. So then it hinges on how risk adverse one is generally. We knew at the beginning of 1999 that at least 85% of organizations in the U.S. would get all of their mission-critical systems fixed in time (Gartner), but what would that other 15% do to the economy? Fix-on-failure works sometimes, but would it work often enough in Jan. 2000?

Throw in the large number of data exchange points in a global economy ('interconnectedness') and it's no surprise that the government, many corporations and some individuals prepared for the possibility of y2k disruptions.

I agree we should have known that most of us were going to have electricity in January. But I'm not sure we should have known that y2k was not going to cause shortages or a recession

-- My (2_1/2@cents.worth), May 18, 2000.

TOO FunnnYYYY!!!!!

So Peter, knowing full well Y2k was like child's play, abandons knowledge of such, and buys the Y2k Hoopla? And he has a problem with Memetics? WHahahahahahehehehWhooohahaha.

You cannot make this up, way too funny, great find.

Yep the FIX was on Pete, literally.

-- Doc Paulie (fannybubbles@usa.net), May 18, 2000.

This old article by Peter is about...applying the windowing technique to batch processing?

-- (not@a.pro), May 18, 2000.

My,

My opinion though is that workarounds have been over-rated as an option for dealing with y2k. Fix-on-failure may have been a viable option for a small business that uses PCs, but risky for others.

Large corporations with IT staffs were in the best position to avoid that "risk" (which I think you overstate, but that's an aside).

Remember, a COMBINATION of factors resulted in the Non-Event. It was a whole bunch of bright people working on individual problems, coming up with solutions in each case where it mattered.

In one case, maybe we had to roll up our sleeves and rewrite the code wholesale; no way around it. But in another case, maybe we could time warp or use "windowing." In yet still other cases, we most assured COULD decide to "fix on failure."

(... and enjoy listening to every self-appointed Y2K "expert" with access to a keyboard or microphone wail about how "risky" that was. Hint: not for nothing did I coin the term Virtua l Remote Control Psychic[g].)

The "Compliance Percentages" game -- which was based on the linear thinking, "either we fix the code or we're hosed" -- was utterly useless to start with. A whole lot of people (up to and including the Y2K Doom types in Washington, DC) got snookered into playing that game because IT Doom types got there first and made the rules. By the time the rest of us realized what was going on, it was too late.

And don't forget the most important factor of all: we are NOT as dependent on computers as most IT/IS types think. We see the proof of that every day, with each new virus attack or other major problem. When it occurs, it'll be all over the news; the IT Gurus will be screaming that it's the End Of The Computing World.

But once the dust settles, the same headline could be used for most of these cases: Things Blew Up. We Fixed Them. Life Goes On.

-- Stephen M. Poole, CET (smpoole7@bellsouth.net), May 18, 2000.

My,

On the other hand, was there any way of knowing before the rollover just how effective workarounds would be?

Not in every case, no. But in the vast majority, yes.

Why? Because computer systems have been failing for years and we've been working around them for years. We had an excellent statistical base from which to form a reasoned judgement.

But here was the problem: IT/IS Doom types were NOT capable of making that judgement. If you were to ask them, "are your computers essential to company operations?" most would (of course!) reply, "absolutely!"

(After all, they'd get hollered at if the computers didn't work. Therefore, they MUST be essential. Right?[g])

But ask that question of typical corporate management and they'd probably say, "our efficiency would suffer, but we COULD work around them."

(And to add insult to blindness, during the Y2K debate, when I'd point this out, the IS/IT Doom types would say, "aw, corporate management is just CLUELESS. You can't believe them.")

In critical cases, any smart enterprise ALREADY has the workarounds in place. Social Security is a perfect example. Before the rollover, I didn't know whether to laugh or cry when I'd read an article by a supposed "expert" about SSA possibly "losing records" (or something like that) due to undiscovered Y2K bugs.

These "experts" obviously didn't know that the government has HARD PAPER COPY BACKUPS for everything. Each person with a SS number has a PAPER FILE filled with every transaction and decision ever made on his/her account.

(In fact, there's even a giant underground vault in the midwest were additional copies of these files are kept in safe storage.)

Why do they do this? BECAUSE THEY KNOW THAT COMPUTERS CAN FAIL, having learned this from hard experience over the past few decades.

The issue devolves to one of efficiency: if the computers fail, we might be less efficient for a while (because we're doing it by hand, USING PROCEDURES WHICH HAVE PROBABLY BEEN IN PLACE FOR YEARS), but we'll stay in operation.

-- Stephen M. Poole, CET (smpoole7@bellsouth.net), May 18, 2000.