[11418] in Public-Access_Computer_Systems_Forum

home help back first fref pref prev next nref lref last post

Re: Will Your Computer Crash in 2000? -Reply

daemon@ATHENA.MIT.EDU (Dan Lester)
Mon Jun 23 20:10:38 1997

Date: Mon, 23 Jun 1997 13:56:33 -0500
From: Dan Lester <DLESTER@bsu.idbsu.edu>
To: PACS-L@LISTSERV.UH.EDU
Reply-To: Public-Access Computer Systems Forum <PACS-L@LISTSERV.UH.EDU>

----------------------------Original message----------------------------
I'll agree that there is a certain amount of overhyping of y2k
issues.  After all, all the outfits dealing with it want to make
some bucks for their services.

But, the fact that almost none of my software is same as 30
months ago is irrelevant.  I'm a high end geek-user- boy who
wants the latest and spiffiest toys.

The people who are in deep doodoo are the ones with tons of
legacy applications running on VAX, VM/CMS, MVS, etc,
etc.  Think of your insurance company, various government
agencies, etc.  They may well be running the same stuff
written in 1975 or 1986, and have not had a reason to change
except for minor updates as new rules or regs are imposed
on them.  If THEY have problems, we'll all have problems.
Same with banks, etc.  Are you SURE you can get money
from your ATM in Jan 2000?

As of now, many of the swipe readers in the stores where you
use your credit or debit card won't handle cards expiring in
00, 01, etc.  Two credit card companies have personally told
me that due to that problem (for which they're fining stores
who don't get new readers by some date in the near future)
they've not yet issued cards with those dates.  I inquired
several months ago after two cards that expired in 03/97, for
example, and had always been renewed for three years at a
time, came with a 03/99 expiration instead of 03/00.  I called
because I knew the pattern and thought that they might have
thought there was something wrong with my account and
thus had given me a short renewal.  Nope.   Just the y2k
issue.  They were NOT happy about it, as it meant producing
more and mailing more cards sooner than they wanted to.
I'm sure that is a non-trivial cost to them (no, I don't feel sorry
for them....and figure it'll show up in rates or charges so we'll
all pay for it anyway).

I know that many mainframe legacy COBOL apps on this
campus will not make the change.  Most will be replaced with
an entire new u**x based system from an outside vendor, etc.
 Almost all the current stuff is home grown over the decades
and still runs on VM mainframe.  If something happens to the
contract or vendor, I'm not going to be sure of getting pay
check, W2, etc, when the change comes.  Of course if they
can't collect my taxes....it isn't really good, as I also can't get
my annual refund.  o-(

Even if you're now using Access97, say, have you made sure
that the things you wrote in Access2.0 a few years back are
compliant?  For many apps it won't be a crisis, but for some
it could be.

Finally, in the July 97 Byte Mag, p. 96, the following info is
offered in an inset box in a y2k related article.

"In research of 1,000,000 lines of code from banking,
insurance, big six CPA, securities, and health services, they
found that: 13% of COBOL modules will require changes
Of that 13% less than 4% of the lines will require change."

Your mission, Ernest, should you choose to accept it, is to
find and correct them all.....before all the tapes they're on self
destruct on 12/31/99 at 2359 local time.  As always, if you're
not successful, we'll disavow any knowledge of you or your
mission.     (shot of smoking and melting monitor)    (fade to
Ernest pursuing a mountain of evil bugs........and bad code...)

This series will be concluded in 31 months.  Watch for the
exciting finale.

dan



Dan Lester, Network Information Coordinator
Boise State University Library, Boise, Idaho, 83725 USA
voice: 208-385-1235   fax:  208-385-1394
dlester@bsu.idbsu.edu     OR    alileste@idbsu.idbsu.edu
Cyclops' Internet Toolbox:    http://cyclops.idbsu.edu
"How can one fool make another wise?"   Kansas, 1979.

home help back first fref pref prev next nref lref last post