|HOME||PUBLIC LIBRARY||ANOTHER PERSPECTIVE||INFOPERSPECTIVES||CONTACT|
On May 3, Funny Cide came from out of nowhere to win the Kentucky Derby, paying $27.60 to win. Two weeks later, Funny Cide ran in the Preakness. A ticket on the winner was worth only $5.80. It was beginning to look like the horse was a sure thing to win the Belmont Stakes, the third jewel in the Triple Crown. About the time Funny Cide was winning the Preakness on May 17, Chuck was watching his bet on a sure thing, the upgrade of an iSeries Model 720 to a Model 820.
Funny Cide went off at even money. Until about 6:40 p.m. on June 7, everything was going right. The three-year-old gelding had risen from obscurity to fame, winning the Kentucky Derby and Preakness. Even the miserable weather would do little to dampen the spirit of this great horse, at least according to the betting public. The railbirds figured Funny Cide was a shoo-in, despite the fact that Belmont looked more like a lake than a racetrack, and bid the odds to money.
But things did not turn out as expected. Funny Cide came in third, behind Empire Maker and Ten Most Wanted. And the horse's fans will have to wait for the next race to see if the gelding can do what it has done before.
By the time of the Belmont Stakes, Chuck's iSeries was up and running. But between the Preakness and the Belmont, things went badly. Chuck was beginning to think he had been secretly convicted under Murphy's Law.
We know this because, on June 2, Chuck told his story to the comp.sys.ibm.as400.misc newsgroup. You can find this group at Google Groups and other newsgroup retrieval systems. To find Chuck's story, look for the topic "a catastrophic failure exposes IBM weaknesses."
The posting started a thread of comments and suggestions that ran to a couple dozen messages. But the sum of all that follows is small compared with the weight of the initial posting. Chuck was not very happy, and if you were in Chuck's shoes you would not be, either; although they are more comfortable than the ones worn by Funny Cide, which are nailed on.
Chuck's complaint is probably best understood in context. Chuck's company has used IBM midrange servers for 30 years. None of the machines suffered a catastrophic failure during those three decades. So reliable IBM made Chuck look good, and, in return, loyal Chuck made IBM look good.
When the Model 820 went down, Chuck found out a few things about IBM. He found that the warranty on a model upgrade, such as the 720-to-820 upgrade he bought, covers only the upgrade, literally. When IBM service technicians bring up the machine successfully, they are done, and so is the guaranty. He also discovered that IBM could be unlucky, and possibly inept, when a machine malfunctions the way his did. It took IBM about four days to get Chuck's computer running.
If a Model 820 running OS/400 is supposed to have crumple zones that absorb the damage when things go wrong, they didn't work as intended. After a number of efforts to restore the system without tearing it down to bare metal, all the experts gave up. As a result, Chuck got a whole new perspective on backup.
Another thing Chuck may have to do differently involves disaster-recovery. He decided, apparently on more than one occasion, that his system would be restored very soon, so he did not declare an emergency and begin the difficult, costly, and time-consuming procedure of bringing up a replica system.
But the main adjustment Chuck is making is one of attitude. He now expects less from IBM. It's hard for an observer of the newsgroup to say, from the posted account, whether Chuck was unrealistic before the incident and therefore a prime candidate for disappointment, or whether he was reasonable (if misinformed about IBM's policies). Whatever his attitude now, Chuck didn't go into the situation with the skepticism evinced by Captain Edward Murphy at Edwards Air Force Base in 1949. Murphy kept the rocket sled used by Dr. John Paul Stapp in safe working order, and he deeply mistrusted the technicians who worked on the apparatus.
It would be nice to also see IBM's side of the story, which could differ significantly from Chuck's, even if both parties agreed on the facts. In particular, it would be helpful to see the call logs (if any) to the service people at every point, from the telephone clerk to the service technicians sent to Chuck's site. The most significant benefits to iSeries customers of a complete picture, and of access to other complete incident reports, would be value assessment and disaster planning.
A library of service-call data might show, statistically at least, that it is more economical for users to pay for service on an incident basis, despite IBM's high charges for time-and-materials repairs, and notwithstanding any impact on the trade-in value of a machine various service strategies might have.
It's doubtful that most customers would go for a time-and-materials plan even if it could be proved that IBM service contracts were overpriced. The person managing the iSeries would weigh the costs and benefits not only to his company but also to his career, and would most likely opt for an IBM support contract every time. But good data might lead to a rise in third-party insurance plans that take advantage of any favorable averages and split the savings with their insured customers.
Similarly, good data on iSeries failures and recoveries might foster a new market in disaster services, one that is more accurately attuned to the financial facts and operational impact experienced by customers when the rare system failure occurs.
IBM probably wouldn't suffer if the facts were more readily available. Even if situations like Chuck's were not as rare as we think they are, IBM might still have a better track record than other vendors and the iSeries might have a better track record than other IBM product lines, particularly the Intel-based xSeries machines, which most directly threaten the future of the iSeries because, on the surface, they seem to be so much less costly.
Even with the facts, it would still be up to the customer to make choices, and there would always be an element of chance. But that's what makes horse racing, and it is also what makes computers go and not go.
— Hesh Wiener June 2003