via eMail:

"It is hard to get first-hand info on the testing protocols and results but here is our first-hand account.
Although what was tested was insignificant, one wonders how the results will ultimately be reported, and what it might mean is happening on the more important stuff.

Husband is a pilot for an Air Rescue Reserve Squadron for the Air Force Reserve. The overall command unit AFRC is touring all the units to "test" units for how they will communicate if the LAN OR the phone lines are out (but not both simultaneously).

Everyone involved knew that this was only checking in the block but were required to do so anyway by way of demonstrating contingency planning.

Most Reserve squadrons are tenant units ie located on a guard base which is responsible for the real contingency planning ie how to keep water, electric, fuel, outside communications etc flowing. Will try and get local status on that to you shortly.

Anyway- When the LAN was down the contingency was to send a fax, if the phone was down, a runner was sent (either to a cubicle in the same building or to another building ala Dilbert) -- the runner beat the fax by 5 minutes anyway.

Course one wonders how many dedicated runners there will be even to operate at a minimum level as this "test" was for 1, 5-page message only (DUH)

Here is the interesting part though- The AFRC folks in the briefing before the "test" said this would only be a simulation because "turning the clock forward caused a lot of problems."

Say what -- excuse me but isn't that the definition of the y2k problem? They even used the LA sewage test as an example. Husband was so disgusted he didn't pump them for more info on details as to "problems with rolling the clock forward."

Doubtless this will work its way up the military food chain as a sucessful contingency planning test so Horn will raise their grade.

Ashton & Leska- maybe you could post this to the bulletin board.

This little non- event coupled with doubtless thousands around the country is the only anecdotal info we have to plan and prepare so I thought I'd share it.

EC "
-----------------------------------------------------------------
xxxxxxxxx xxxxxxxxx xxxxxxxxx xxxxxxx

-- A&L for EC (allaha@earthlink.net), June 20, 1999

Answers

Here it is, EC, sobering and informative. Thanks for sharing.

We've read many examples of sloppy/shoddy/quickie/slippy testing. Our hope is that all workers take remediation seriously and testing and contingency planning with imperative attention to detail and follow-through.

To slipshod around such crucial necessities while times are good is criminally short-sighted.

xxxxxxxxxx xxxxxxxxxx xxxxxxxx

-- Ashton & Leska in Cascadia (allaha@earthlink.net), June 20, 1999.

Thank you verrry much! I trust the messengers!!

-- Will continue (farming@home.com), June 21, 1999.

I think sometimes we miss the point:

"touring all the units to "test" units for how they will communicate if the LAN OR the phone lines are out (but not both simultaneously). Everyone involved knew that this was only checking in the block but were required to do so anyway by way of demonstrating contingency planning. "

That's what I would do. Your goal is to see where the problems are. Once you realize that ALL your communications systems have problems you then decide which ones to fix. You DONT fix them all. You fix ONE first, so you have something you KNOW will work. THEN you go back and fix the rest if time and budget allow.

It's just like a math test: it's better to have 50% of the problems fixed than 100% of the problems 50% fixed. The former may only get you a "D" but the latter is an automatic "F".

The question isn't the initial testing methodology but what was done after. The temtation is to do the latter (100% is %50 fixed) just to claim "we are 100% done with remediation" even though nothing works yet.

-- otay (spanky@lilrsacles.com), June 21, 1999.

Thanks for sharing that one Leska 'n Ashton.

Bet this kind of thing is happening across the globe right now.

Diane

-- Diane J. Squire (sacredspaces@yahoo.com), June 21, 1999.

Yep, will do ;^) BTW, the title for this thread was supplied by EC. Those on the end of the stick feel it the keenest.

-- Ashton & Leska in Cascadia (allaha@earthlink.net), June 21, 1999.

HEY GUYS:

This seems to be a test of the contingency plan, not a test of the remediated system. If this is the case, they would not at all need to set the clock forward. Contingency plan testing tests the contingency plan, not the system.

-- newlurker (bcobur@yahoo.com), June 21, 1999.

Newlurker "This seems to be a test of the contingency plan, not a test of the remediated system. If this is the case, they would not at all need to set the clock forward. Contingency plan testing tests the contingency plan, not the system."

I beg to differ with you. When the contingency plan is put into effect it, indeed, BECOMES the system.

I oughta know as I have developed dozens of contingency plans for many major corporation's IT departments as well as their business departments.

Yours in COBOL... Dino!

-- (COBOL_Dinosaur@yahoo.com), June 22, 1999.