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