QuickBASIC/QBASIC newsletter
Article of the Month
The Millennium Bug II
Note: The following article is meant to be a follow-up to last
issue's
article on the millennium bug and to correct some misinformation
the article provided by showing the programmer's side of the
issue.
The hardest part about fixing the Y2K bug is trying to find
all the
code it uses and references. This is compounded by the
fact that over
the years - and through all the different political leaders,
and programers -
the way that the date was stored had changed. In some
cases it is just a
byte, in others the byte is split into two (so it can read from
00 to 99), and
in other cases it is stored as a string (for some reason the
programers
liked to do that 'split' byte thing a lot, as most of the money
amounts and
such are stored in the same matter).
From what I understand: the scanner program is doing a decent
job of listing out the 'bug' references it finds (the 'scanner'
was written by
some company a few years ago to simply find the bug, but it
needed to be
modified a bit to run throught the system, but they also run
through 'by
hand' as the 'scanner' sometimes misses and also picks the wrong
stuff
out as the 'bug'). The programers are also spending a
lot of time in meetings
with other departments and government agencies, this is so that
they can be in
agreement on how to fix the problem (our State's Dept. of Revenue
computers
are in communication with those at the federal level, and they
also comunicate
with other departments). If they don't agree on how to
set-up the corrections,
they could end up crashing the system because someone didn't
fix his linked
system correctly. Some of this I didn't quite understand,
but mom, who works
on the 'bug,' disagrees. But it seems to me that with
the current date system
of mixed up bytes and strings that they are very lucky to have
the system
working now and are even luckier to be able to communicate with
the other
computers! So why spend so much time trying to agree on a solution?
Anyways, once they 'agree' and have a huge list of the 'bug'
code
sources it shouldn't take to long to implament the changes I
don't want to
imply that they aren't changing code yet - just that mom's group
within the
dept. hasn't and that the early recoded portions will have to
be redone once
they find a solution, these early recodes were done to keep
the computer
running so if they couldn't get the programs done they could
at least work
on them after 2000. So, I guess in some ways they are
fixed. Mom thinks
they will be ready with the essental programs and will have
about 4-8
months work to get the rest of they proggies fixed. As
far as what would
happen if they don't get it fixed in time: they set the date
forward on a copy
of their main program in a seperate computer...it still worked
fine but the
date was 1900, and it wouldn't allow some things to work (like
write a social
security check to some body born in say 1933 because the system
thinks
they arn't born yet) but the sytem was stable enough to keep
working. So
far so good.
My father lives in Chicago and I only see him a few times
a year,
but I think that they are closer to getting ALL the 'bugs' removed
in the
Dept. of Education than Revenue because they use fewer programs
and
such. This only applies to Illinois Dept. of Revenue
and Education (and
then only to a small portion of those departments), so what
I meen by this
is that the power company could be way behind and on 1-1-2000
the lights
could go out and so the computers wouldn't work either.
But I think that
they are working on a solution (our power company has begun
to lay
emergency lines that will be connected if the system fails).
Darren...MA SNART
Back