X-Message-Number: 10131 From: Keith Lynch <> Date: Mon, 27 Jul 1998 23:08:01 -0400 (EDT) Subject: Y2K -- a report from the trenches (Sorry that this is a bit off topic.) On the whole I agree with Robert Ettinger and others that the Y2K hysteria is overblown. There's not going to be any depression, major power failures, or martial law. But programs DO need to be fixed, and it IS a lot of work. I know because I'm doing it. I'm now working as Director of Applications at Point Systems in Burke, Virginia, and I've been going through over a million lines of MUMPS code in our major hospital application, looking for Y2K bugs. (Yes, I've found several (minor ones) so far.) This searching can be partially but not fully automated. Here's an analogy: When I wanted to replace every mention of a certain prominent cryobiologist's last name in the complete Cryonet archives which I host here (http://www.clark.net/pub/kfl/les/cryonet/) with F*hy (at his request, to protect him from web-searches done by cryonics-hostile cryobiologists), this was easy to automate. But when I set out to index which Cryonet messages were responses to which other Cryonet messages, I found this impossible to automate. It should be obvious to every human reader of Cryonet which recent message this message of mine is in reply to. But if you can think of a practical way to automate this, please tell me, because I sure can't. Computers are good at dealing with syntax, but not with semantics. I could easily write a program to tell you how many of each of the 26 letters are in this message. Or even how many sentences. But it would have no way of telling what any of the sentences mean. Or even what they refer to. I can search our code for suspect character strings such as "19_", "1900", "2000", and ",3,4)", but the vast majority of these are false alarms, and most true Y2K errors aren't found in this way. So how can we find the bugs? Perhaps we could simply set the date on our test system two years ahead, after loading it with a copy of a hospital database, and test it that way? We'd get lots of error messages that way, all right. Messages about patients who have been in the hospital for years for minor problems. About patients who hadn't paid their bills for years. About people in pediatric programs who are too old for those programs. About supplies that had long since expired. About billing periods not having been closed out. About passwords having expired. And lots of others, all having little to do with Y2K. And lots of true Y2K errors wouldn't appear, since no patients would have been admitted, transferred, billed, discharged, treated, etc, for months, so most of the system wouldn't be exercised at all. Or we could start fresh, and just start entering data as if we were a new hospital. That would work, if there were ten times as many of us, if we were all trained in data entry, if we had nothing better to do for a few months, and if we were able to reproduce all the quirky things that real data entry people at real hospitals might do or fail to do. Or we could get a hospital's staff to do the data entry for us. Either we would bring them to Burke, or set up leased lines. Of course we'd have to pay them. A lot. Or we could load our test system with a hospital's database, and then move up all the dates within it. That's what we plan to do. However, this is much harder than it sounds. Our database contains several tens of thousands of distinct fields, and I have to figure out which fields are intended to represent dates. First (or in parallel with it), I have to figure out when two fields are of the same kind and when they aren't, which is even harder. (In many cases, changing the value of one field in a record changes the intended interpretation of all the other fields in that record.) It doesn't help that many of the fields are left blank most of the time. In moving up the date, we have to be careful to get the month-ends to line up with each other properly. And the fiscal year-ends. We'll probably be taking a copy of a database that ends in 12/97, tossing out everything from before 3/96 (to avoid leap-year confusion), then incrementing the date on everything by two years, then spending a month or two thoroughly testing it. I expect we'll find Y2K errors, errors due to the 12/97 version of our software being slightly different than the current version, errors due to problems in incrementing the dates (some fields will probably be misidentified as dates when they aren't, or as not dates when they are), and errors due to pre-3/96 data being cut off in a slightly erroneous manner with a few dangling references left. Dealing with a million line poorly documented legacy system that was written by dozens of programmers over twenty years and that maintains a heterogeneous multi-gigabyte database is very different than debugging a thousand line program that you wrote at home over a weekend or two. Also, there always seems to be a higher priority than Y2K work. Some site needs a new report, Wednesday. Another site discovered that one subprogram gets into an infinite loop if a negative medical record number is entered, and this needs to be fixed. A third site's database got corrupted and needs to be fixed. And a dozen other things, all urgent. 2000 still SOUNDS like it's in the impossibly distant future, like in Edward Bellamy's novel. In fact it's closer than the beginning of February 1997. And FISCAL year 2000 -- for some of our hospitals -- is closer than last Christmas. There's also the issue of training. What should users be told to do when they enter a date? Currently the rule is that a year can be entered as two digits if it's in the current century, otherwise four digits must be used (e.g. if a patient was born in 1899, or a doctor's hospital priviliges expire in 2001). So what should happen if in January 2000, someone enters 12/31/99 as a patient's birthday? Maybe four digits should always be required? That's a lot more typing in the long run. I doubt the Y2K bugs will have any effect on cryonics. As for hospitals, I would still rather be hospitalized in January 2000 than in July of any year. (July is when the new doctors start their residency.) Rate This Message: http://www.cryonet.org/cgi-bin/rate.cgi?msg=10131