From rec.arts.sf.reviews Sun Jun 20 12:19:17 1999 Path: news.ifm.liu.se!news.lth.se!feed2.news.luth.se!luth.se!sunqbc.risq.qc.ca!news-peer.gip.net!news.gsl.net!gip.net!panix!bloom-beacon.mit.edu!senator-bedfellow.mit.edu!usenet From: "Rob Slade, doting grandpa of Ryan and Trevor" Newsgroups: rec.arts.sf.reviews Subject: REVIEW: "Deadline Y2K", Mark Joseph Followup-To: rec.arts.sf.written Date: 15 Jun 1999 17:51:43 -0400 Organization: Vancouver Institute for Research into User Lines: 95 Sender: wex@tinbergen.media.mit.edu Approved: wex@media.mit.edu Message-ID: Reply-To: rslade@sprint.ca NNTP-Posting-Host: tinbergen.media.mit.edu X-Newsreader: Gnus v5.3/Emacs 19.34 Xref: news.ifm.liu.se rec.arts.sf.reviews:2378 Deadline Y2K by Mark Joseph Review Copyright 1999 Robert M. Slade First of all, I have to say that after the halfway (or maybe two thirds) point, I really got into this book. The action is tense, interesting, and well thought out. The geeks save the day, even outclevering the semi-evil capitalist. That said, I'll go back to the opening I originally intended to use for this review: The Bad News is that Joseph figures we're all gonna die, or a reasonable facsimile thereof. The Good News is that Joseph gets so much else wrong that, based on the fact that he predicts disaster, we'll probably have a fairly easy time of it. The author has a deep, profound, and abiding lack of understanding of Y2K. The one concept he does seem to understand is that the most serious Y2K problems arise from the interconnected nature of modern systems, and the fact that small problems, added, multiply themselves. This is good, and is used to good effect at times in the story. The list of negative accomplishments is rather longer. Lets start with stereotypes. We have magic bullet Y2K fixing software. We have the traditional, mythical salami scam. We have the hygienically challenged genius hacker who starts out as a completely irresponsible flake, and suddenly transforms into a dedicated, managerial, recruiting, social worker. We have the multi-millionaire tycoon having his bagel every morning and shooting the breeze with the boys from the old 'hood. This is the same guy who alienates his wife and kid by never having time for them. Then there are specific technical errors. The credit card companies hit the Y2K wall in 1997 because of expiration dates, and therefore have generally dealt with the issue. There will not be a sudden collapse of the credit card system in the hours just before midnight, December 31, 1999. In fact, a large number of failures in the book happen in the last few hours of 1999, rather than months or years before, or slightly after. The failures of old GPS (Global Positioning System) terminals that will happen in August of 1999 have a very vague and conceptual relation to Y2K in that the problem results from a "number of weeks" field that is limited to ten bits. It has nothing to do with a sudden change of format. I have no idea why you need to calculate dates in order to tell the difference between O positive and O negative blood. Then there are the more general mistakes. One platform definitely does not fit all: it is highly unlikely that a single IBM mainframe could accommodate all the control programs from a power utility, civic infrastructures, telecommunications companies, and transit authorities. Nobody snuck a VAX or a UNIX box into the mix anywhere? Besides, I understand that the New York subway still has drivers. But you could check with Bombardier... It is also unlikely that a single mainframe could handle the processing load required to run all of them concurrently. We will ignore, for the moment, the likelihood of a small band of geeks being able to fulfill all the checking that large corporations were unable to do *and* get it to run right the first time they do a smoke test. There is no reason that someone supplying utility software would have any need to access full bank data records. Yes, there is a T-4, and, yes, it is bigger than a T-1 or T-3. But almost nobody uses that designation: it just isn't that useful in discussing the bandwidth bundles that are provided. Furthermore, I don't care what von Neumann said; a data file, even a very large data file, is *not* the same as code. Yes, if someone was careless, a very large data file could possibly overrun its bounds and crash a system, but there would be no difference between a store completely restocking and a store starting up for the first time, now would there be? Joseph's dialogue is readable, although not particularly great. His characterizations could use some work. At one point (page 166) someone goes from being "amused and thrilled" to being ready to "die of anxiety" in the space of one sentence, with nothing happening in the interim. Entertaining, yes, but only after you get through the annoying bits at the beginning. %A Mark Joseph %C 175 Fifth Ave., New York, NY 10010 %D 1999 %G 0-312-20202-4 %I St. Martin's Press %O U$24.95/C$34.99 212-674-5151 fax 800-288-2131 www.stmartins.com %P 294 p. %T "Deadline Y2K" ====================== (quote inserted randomly by Pegasus Mailer) rslade@vcn.bc.ca rslade@sprint.ca slade@victoria.tc.ca p1@canada.com It is bad to suppress laughter; it goes back down and spreads to your hips. http://victoria.tc.ca/techrev or http://sun.soci.niu.edu/~rslade