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