STL Time Machine Report #6 -- Thursday 1998-02-05 We are approximately midway through our second of three test cycles. We just completed another rollover on Tuesday, and Wednesday was a bye. Thursday and Friday we do our Leap Year tests -- February 28, 29, and March 1, 2000. We finally got the all-important test of our in-core table LRU (Least Recently Used) algorithm. For CICS programmers, just remember that an EIBDATE of 1999-12-31 (X'0099365C') is followed by X'0100001C'. Yup, that's right. CICS EIBDATE uses the same kind of Century Indicator as that the IBM MVS "TIME" Macro. (Cory gets another chance to rant at IBM weirdness). We didn't complete this test in cycle 1 because we ran out of time before rollover. We sweat bullets last time as the seconds ticked away, and this time the network test script beat the clock. Because we're doing some realtime testing of rollover, the system clock is on a 12-hour offset, so midnight occurs at noon local time. A few test set-ups are less than ideal, but still adequate. Cycle 3 testing uses input from Cycle 2 output, so all our application-specific test setups are frozen now. We found a new problem during review of test results. And it's not a Year 2000 problem, it's a current defect. The programs have been in production over a year and no one's noticed. The system went through a very thorough regression test and it wasn't found. It's data dependent, and causes improper summary totals to be displayed on a screen but no abends. We verified it in our regression test facility with current dates. It just proves that you can never test too much. I recently learned that we run 80+ CICS regions, and to my surprise there is still a handful of production CICS 2.1.2 regions owned by tech services that obviously need to be upgraded. I don't know what there remediation plans are, but they have their deadlines too. What have we learned? Problems can be solved. Start planning sooner rather than later. MVS/ESA 5.2.2 is compliant. CICS 4.1 works with either COBOL II runtime libraries or LE/MVS runtime libraries and is compliant. The COBOL II compiler has no rollover problems. Our third party database will work with CICS 4.1 and COBOL II runtimes, although the unremediated applications still have their own problems (the corrected versions are scheduled for testing sometime between February and June). The internal applications we have tested so far seem to have no problems through 2001-01-01 (the day after 00366). Testing in an LPAR (logical partition) instead of buying an additional mainframe doesn't seem to be causing us any problems. The Time Machine LPAR is completely isolated from the production LPAR. That makes it hard to move files into the time machine, and no files will be allowed back, except for tapes. I haven't seen the two new printers yet, but we seem to have solved a mainframe bottleneck that was slowing delivery to the existing printer. We're getting the print we need anyway. The use of an LPAR and LAN-type printers allowed us to save some money on hardware we can easily recycle into production later. With practice, the review of test results is going much quicker. I fully expect the next test group's applications to experience some gotchas during their setup. If they're lucky, they will have learned from us and have fewer problems than we did. You should plan ahead, but allow extra time to resolve unexpected problems. You can't expect everything to work right the first time. Random Notes. I haven't heard anything lately on other St. Louis companies doing Time Machine testing. There's at least two out there, maybe more. My 11-year-old niece is building web pages. She writes, "I think you should give up the COBOL and Y2K stuff and learn HTML and/or JavaScript." Well, we have to make room for the new generation. Are there any code-crankers out there who can talk about Time Machine testing in the telecom industry or electric utilities? I would really like to know what progress is being made in those areas. Finally, I have to respond to Pam Hystad's post on the casting for the Y2K disaster movie. I'm very flattered that Harrison Ford was chosen, and it got a chuckle at the office, but I'm afraid I wouldn't have the screen presence of Han Solo, Indiana Jones, or Jack Ryan. My girlfriend says I should be played by David Suchet (Hercule Poirot in the BBC Mystery Series). I don't think I look like him either, but his hair color matches mine better. -- Arnold Trembley http://home.att.net/~arnold.trembley/ "Y2K? Because Centuries Happen!"