X-Message-Number: 10132 Date: Mon, 27 Jul 1998 21:21:46 -0700 From: Peter Merel <> Subject: Y2K - replies to Perry and Bob Perry Metzger writes, >I'm really sorry to say this, but as a computer professional actually >working in the financial field, I have to say that the hysteria being >created is completely absurd I've developed telecommunications, manufacturing, SCADA, financial, military, mass market and freeware programs. What this has to do with the price of eggs I don't know. Please address the specific firmware and economic concerns raised here and let's leave pissing contests and personal invective for some other forum. [the US banking industry is on target for Y2K] Indeed it seems to be. Other US industries, however, report almost total non-compliance. Some f'rinstances published this month: http://cbs.marketwatch.com/archive/19980716/news/current/stwatch.htx?sou The SEC surveyed annual reports of 1,023 large US companies. 30% didn't even mention y2k. Of those that did, 73% reported they had not begun code remediation. http://www.esj.com/library/1998/july/julynews.htm Cap-Gemini says 1 in 7 of its surveyed organizations will be non-compliant http://www.sentrytech.com/Y2K/Y2KJul98/y2k078nf.htm Software Magazine's survey indicates 60% of large US businesses haven't begun code remediation http://www.house.gov/smbiz/leg/hearings/hearing_11/dennis.html National Federation of Small Business testifies 80% of small US businesses have done nothing for Y2K http://www.house.gov/smbiz/leg/hearings/hearing_11/taufen.html IBM testifies to the senate its estimate that 75% of US small businesses have done nothing for Y2K http://www.sentrytech.com/sm078dl.htm Triaxysys surveys of Fortune 250 10k filings suggest only 10% of the total US code base will have been fixed by 1/1/00 And none of this even addresses the 2 possibilities that give me what Perry calls "hysterics" - embedded systems failures and the likely bank run. >See: http://www.cpsr.org/program/y2k/ >(one link Peter Merel didn't give) if you don't believe me. I'd be happy about this except that CPSR were only able to refute 1/5 of those stories. In their official policy statement, CPSR note: "CPSR believes [there is a] very serious threat posed to individuals, organizations, governments, and economies by the Year 2000 computer problem, a threat that could disrupt our economic and social systems." For CPSR, these are strong words indeed. [It's easy to fix software] Sure is. Only trouble is, as described above, there's a great deal of it to fix. Well, and firmware ain't software - you can't fix it unless you replace it. Well, and then there's the panic issue. Well, amongst our troubles are such diverse elements as ... >Well, two weekends ago, most NYC financial center organizations did a >mass Y2K test. They set the clocks forward and tried simulating a day >of NYSE trading. Everything worked. EVERYTHING. Actually, it was only a half-volume test - 29 firms and 12 exchanges. The "everything" test isn't till spring '99. But I won't be surprised if this holds up too - these folks have all been working on their part of the problem for 5-10 years. It's all those firms described above that haven't even started yet, and all the embedded systems, that trouble my sleep. [software is easy to fix. NetBSD for example ...] Um, yeah, so what does that have to do with the firmware and economic problems? What does it have to do with the amount of software going unfixed? Numbers please. It's easy to walk, but numbers tell us walking around the world takes a long time. Not anecdotes or hand-waving - give us some real numbers based on real empiricism. Here's a short list of the numbers I really want to see: How much of the software problem has been addressed? How much of the software problem will be addressed in the next 17 months? How much of the firmware problem has been addressed? How much of the firmware problem will be addressed in the next 17 months? What will be the effect of a run on the banks in this country? What will be the effect of a run on the banks in other countries on this country? Not invective, nor anecdotes, nor hype - just the figures please. [Y2K consultants spread panic. Gary North spreads a lot of panic.] I'm not a Y2K consultant. I'm not working on any Y2K problems. I make no money from Y2K consulting, and I don't expect to make any money from Y2K consulting. I'm a software architect who builds nice modern standards-based y2k-free distributed OO systems. I just want some straight answers to the hard questions. As to Gary North, the man's certainly no technologist. I place no stock in any technical opinion he puts out about Y2K. But I do like his site as a clearing house of published Y2K reports - very useful. The URL I referred you to was a page of *external* links, not anything Gary North wrote. -- Bob Ettinger writes, >At least it appears hopeful that, in some cases, there may be a simple fix >[...] In some cases maybe a relatively simple fix [...] such as >reinstallation of manual controls Yes, in many cases there are simple or relatively simple fixes. There are already many products that address, or claim to address, problems like bad BIOS in PCs. There are many applications that will work just fine, or fine enough for practical purposes. Accounting packages that get some date details wrong, for example, are hardly much of a threat to small business. Historical databases that need to be thrown away aren't all that much of a worry, and so on. Many legacies are non-vital. Unfortunately, many really vital systems seem very hard to fix. As Jeffrey Soreff wrote, many of these are so real-time intensive that no manual replacement is feasible, and many more would require so many skilled manual replacements that manual replacement would not be practical. [why no software silver bullet? Why not automatically detect and fix y2k problems?] To some extent, automatic detection and fixes are being attempted. But software is heterogeneous and messy stuff, often produced in the absence of or without regard to standards. This isn't so true of newer software (I hope!), but very much so for legacy systems. When implementations don't meet any standards, the only thing that can be done is to walk through the source line by line - when there's source available, which sometimes there ain't. Much worse, many of the affected systems aren't software any more - they're firmware - read-only controls burnt into the hardware. Fixing these requires physical replacement, not software twiddling. [Insert garbage filters at the O/S level] In general this isn't feasible because the problem is with the logic in the application, not its interface to its O/S. But maybe under some circumstances this could be a useful technique. The question is, under what circumstances could it meet the real-time requirements, and under what circumstances would it be less expensive than actual code remediation? Imho, I suspect the answers to these questions make O/S intervention only useful under very limited circumstances. >(In fact, shouldn't every industrial plant program have, as the last step, a >review of possible dangers in the command output? Do they? If not, would it be >relatively simple to add that to the operating program?) Most SCADA systems of my experience have the ability to raise alarms and shut down upon system faults. But this is more the problem than the solution. It's the ripple of such shutdowns that makes this such a nasty situation. Check some of last posting's URLs for examples. >I know it's presumptuous to make suggestions to professionals who have been >wrestling with the problem for a long time, and such suggestions are unlikely >to have merit--but who knows. Even a blind hen sometimes finds a corn. Oh, no, I for one really appreciate you giving it thought. The more minds that address themselves to this problem, the better. But it might pay to do a bit more reading up on the technical issues and strategies being used to fight them so your thinking won't reinvent wheels. But there's no end of original thought about software that hasn't been thought yet. Peter Merel. Rate This Message: http://www.cryonet.org/cgi-bin/rate.cgi?msg=10132