STL Time Machine Report #3 - 1998-01-15 Well, tomorrow is show-time. We've completed our dry run to shake out the set-up problems, the data file problems, the JCL & schedule problems and we are (hopefully) ready to rock 'n roll. Our first test date will be 07/05/1999, followed on succeeding days by 12/31/1999 with rollover, 02/28/2000 with rollover, 02/29/2000 with rollover, and 12/31/2000 with rollover. We will IPL with a 12-hour offset so that rollover occurs at noon local time. That way we only miss lunch instead of daylight. For each test we plan a targeted suite of network transactions plus daily and monthly batch schedules. We do not have any year end jobs in this application. This test sequence will be repeated three times, which should take three weeks, and then the next application group should be ready to move into the time machine. We also expect to test our application again later in the year as more vendor software is upgraded. With a lot of overtime we managed to get the JCL working and the new job scheduler working. We tested rollover 12/31/1999 to 01/01/2000 twice, and we found four problems so far. All the problems were minor and none caused catastrophic failures. I notified tech services that our CICS Good Morning screen reported the date as January 01, 1900. In less than an hour I was called back and asked to NEWCOPY program ACFAEUSA in all my CICS regions. One down. The other three problems were in a system built to be Y2K compliant before our Y2K project started. This system has dates in VSAM keys, so its dates were fully expanded. (We are windowing for most of our Y2K remediation). New data arrives with only 2-digit years and the CC was generated by prepending the CC from the current four-digit year. So for a few seconds after midnight we are still getting 1999 data and it's being windowed into 2099. Similarly, one screen has MMDDYY as a search argument, and will not window keyed searches to data outside the current century. All these problems have been fixed in the Time Machine and will be migrated to production as well. We use a product called SAR (Sysout Archive & Retrieval) to view job syslog history. While it doesn't appear to have any Y2K problems, I found that booting up the system back and forth in time makes it impossible to locate certain jobs by date. I'm sure the vendor doesn't recommend operating it the way we do. We can still locate the jobs by jobname, but it is a bit inconvenient for testing. We ought to erase the job history when we IPL backwards in time, but operations doesn't want to do that. I also noticed a comment in c.s.y2k that this newsgroup is too mainframe-centric. I'm sorry I don't have more information on non-mainframe hardware & software, but I just don't have the expertise to talk about them. I'm sure there will be enough date problems for everyone's favorite system. Perhaps someone in the know can post some useful testing information for those other platforms. For the record, a time machine is a test environment that can be IPL'ed forward or backward in time, specifically to test hardware, operating system software, network software, and applications software for date related problems. Our time machine includes several Unix boxes as well as an LPAR running MVS/ESA 5.2.2 and CICS 4.1. The COBOL applications are currently being tested with the IBM COBOL II runtime library, since our third party database does not yet work with LE/MVS. I plan to watch the leap year test carefully. We're looking at the February/March timeframe before the vendor's mainframe database fix is available. I know that other mainframe development groups are very busy fixing date problems and finally converting from OS/VS COBOL to COBOL II. My group has about five years experience with COBOL II, and converting COBOL II to COBOL for MVS & VM does not require any source code changes. There is another whole group that works with our PC applications and LAN's. Unfortunately I don't know exactly what they're doing for Y2K, but I know they've been testing. So in answer to Ron Kenyon's question of a few days ago, it seems like our Y2K effort is lots of small projects rather than one huge multi-year project. -- Arnold Trembley http://home.att.net/~arnold.trembley/ "Y2K? Because Centuries Happen!"