STL Time Machine Report #15 - Fri 01 May 1998 (1998-05-01) Time Machine testing continues. We're on our third and final iteration for group 2. Each group has three iterations of testing, which takes about 8-10 weeks, then there's a couple of weeks of downtime while the next group sets up. Group three begins about June 1st, and will include Unix testing for the first time. I did get a call from another group that was having an odd problem with a date in a VSAM file key. I don't know if they've diagnosed it yet, but I suspect an application problem. They suspected a problem with an assembler date routine, but I was able to verify that the Y2K-compliant version is installed in the Time Machine, and no one else has a problem with it. I'll have to get back to those guys. I've just had a brainstorm that it might be another variation of the problem where you subtract 01 from 00 expecting to get 99. Wrongo! The Tape Expiration problem In the last Time Machine report I mentioned a problem with our tape management system. Test tapes were cataloged with a YYDDD expiration date of 05001 and expired immediately because RMM assumes all 2-digit years fall in the range 1900-1999, but an explicit YYYYDDD date of 2005001 works perfectly. Last Monday I also got to attend a meeting on retention of test results while my project leader was out of the office. Apparently a LOT of test tapes were scratched by the "05001" problem, which really shook up some people. Virtually all of them were recataloged before they could be overwritten, so no real damage was done. This meeting was interesting, but not very productive. Some groups have decided to save test results on tape. An operations guy said that the tapes would be unreadable after seven years of offsite storage unless they're cleaned and read at least once a year. Spinning the tape is required to retension it, and to prevent print through. Other groups (like mine) have elected to save test results on hardcopy. There was a lot of discussion about what needs to be retained until 2005 to prove "due diligence". Some groups are saving all their input data in order to rerun tests. Other attendees said they would not retain input test data after the end of the year 2000, and had no requirement to be able to rerun tests. So people had different ideas about how much should be retained until 2005, and what media should be used. I told my project leader about the confusion, and he said he was glad he was on jury duty instead. The Triage Problem I want to thank Steve Dover for highlighting this problem. If you're in triage, you'll run into this. Somebody has to decide what gets fixed first. Chances are you won't be able to fix everything at once. Then you'll have to find the right workarounds. Our case resulted in testing applications out of sequence. This could lead to some retesting to verify that multiple applications will work together. I understand why this decision was made in our specific situation, but it does have consequences. If you're not careful, your Y2K mission critical systems might still fail because a lower priority application wasn't fixed, or wasn't tested with the critical app. COBOL and LE/MVS IBM says you really should be running Language Environment for MVS (or OS/390) in order to retain vendor support for your COBOL applications. We wanted to migrate to LE/MVS in 1998, but we won't be able to do that because our third party Database cannot be upgraded to an LE/MVS compliant version this year. We've got the beta version, we've tested it in the Time Machine, but the upgrade just cannot be installed this year. Each database application has be modified and retested first. This is another kind of sequencing problem. It can be very difficult to coordinate all your system software upgrades so that your base operating systems software is fully year 2000 compliant. Starting late is very risky. CICS 4.1 IBM says only CICS 4.1 and Transaction Server for OS/390 are Y2K compliant. Last Saturday, we attempted a performance stress test with CICS 4.1 and COBOL II runtime libraries. Performance was lousy. The problem is not with IBM CICS, but rather with the third party security access package. It had excessively high CPU utilization which killed us. Our technical Services department is researching this, and they've already identified eleven performance related vendor patches to apply. If you follow bit.listserv.cics-l, you'll see that there are a lot of ACF2 users that have problems integrating ACF2 6.1 with CICS 4.1. I'm pretty sure this problem is solvable, but it means we'll be having more Saturday testing sessions. High-Level Assembler We've had a continuing controversy over the IBM High-level Assembler, with some team members suggesting that every assembler program in the shop must be re-assembled with the new assembler in order to be Y2K compliant. Somebody decided that won't happen. While this decision will probably not please everybody, I think it's the best decision that could be reached. We've already tested many of our old assembler programs in the Time Machine. A mass conversion, even with no source code changes, would require a lot of additional testing. We don't want to add more testing at this stage of the project. Miscellaneous Stuff Media awareness - Last Tuesday (I think) the Wall Street Journal had several pages in their B section devoted to Y2K. It included an article by Peter de Jager and a huge number of ads by companies offering remediation services. I should have saved it. I think I saw an article in Infoworld (or PC Week?) that said Windows 95 and NT 4.0 were not compliant. No screaming headlines, but somehow I thought this should have gotten more attention. Previous Time Machine Reports are available 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!"