STL Time Machine Report #14 - Fri 24 April 1998 (1998-04-24)
 
Between the tornado on the 13th and a production problem on 
Saturday the 18th, I haven't kept a normal sleep schedule in 
nearly two weeks.  Not that I have a normal one to begin with, 
as my co-workers can attest.
 
I've been out of Y2K testing since the beginning of March.  It 
still goes on.  One of our contractors encountered an interesting 
problem with IBM's tape manager system, RMM (Removable Media 
Manager).  They cataloged a tape of Y2K test results with an 
expiration date of 05001 (typical IBM YYDDD format).  Everybody's 
been worrying about all those files with 99365 expiration dates.  
Well, under RMM a tape file with an 05001 expiration date expires 
the day you create it, because the system interprets it as 1905001.  
But if you catalog a tape with an explicit expiration date of 
2005001 you have no problems.
 
As far as I know, 99365 is treated as a signal date and means
"never expire".  I'll have to check with someone who's actually
tested it.
 
Planning Problems
 
Over a year ago when they decided which systems were mission
critical and had to get fixed first they made a little mistake.
All the mission critical systems depend on data feeds from a 
non-mission critical system with known year 2000 problems.  
Eventually they reclassified the database, but the first group 
of apps tested had to simulate or override some file feeds 
because part of the infrastructure was not ready.  They just 
installed the final Y2K fixes in the Time Machine, and there 
were a few problems.  I'm pretty confident it will be compliant 
and in production well before rollover, but we could have 
scheduled it better and had fewer problems in our time machine 
testing.
 
Apparently, the most common problem with this system is that
the screen edits will not allow you to enter '00 dates anywhere,
and therefore the data file extracts couldn't be created and
passed to the mission critical systems.

Two old applications have been scheduled to be shutdown by August, 
1998.  At least we won't have to fix those.

High-Level Assembler
 
We're still looking into the High-level assembler issue.  I trolled
comp.lang.asm370 and got a lot of useful comments on whether or
not all assembler programs should be reassembled with the "Y2K
compliant assembler".  Generally, the experts don't think it's
necessary.  There's plenty of work to do, so it would be helpful
to know what kind of work really needs to be done.
 
My guess is they won't reassemble every program in the shop.  That
would mean retesting a lot of systems that have already been through
the time machine.  So we have a high level of confidence that the
older programs will work with future dates without reassembling.
 
Miscellaneous Stuff
 
No new PHM stories this time, I hope that's good news.
 
Previous issues of the STL Time Machine Reports can be found at:
http://home.att.net/~arnold.trembley/tmr.htm
 
STANDARD DISCLAIMER:  I am NOT an official corporate spokesperson.  
My opinions should not be held against my benevolent employer.

--
Arnold Trembley     
http://home.att.net/~arnold.trembley/
"Y2K?  Because Centuries Happen!"