STL Time Machine Report #7 - 1998-02-13 We've completed the second of three cycles of Year 2000 testing on our first group of applications, as of last Tuesday night. One application area requested a retest of rollover from 02/28/2000 to 02/29/2000. Tech Services is cleaning up the system for the IPL backwards in time, and we begin our final cycle on Monday. The reviews of test results have gone well, with very few problems. One minor batch file purge had some odd behavior because its dates are MM/DD only (no year at all) and had test data outside its typical range (-5 days). The purge does not abend and all contingencies are covered. But the reviewers asked some pointed questions about why November data was not purged in February. I personally retested the code and found a very strange windowing routine that only works if the MM/DD date is within approximately two months (plus or minus) of the current MM/DD date. But it handles rollover to 01/01/2000 correctly, and all our other test dates. I'd like to make this one perfect, but it's not bad enough to get a priority. Each testing "group" takes about 6-8 weeks to run, and Time Machine testing for internal compliance will continue through approximately September. There are four "group" slots allocated, with the final group open for retesting, if required. At this point that looks like it may only be needed for testing new releases. You need to be careful that any new development does not introduce new Year 2000 problems. Printer News The day after I posted the last Time Machine report the two new HP 5SI's were installed and running. I am impressed that this problem was solved so quickly. Printing test results is no longer a problem. It looks like we will be archiving test results on a mix of tape and hardcopy until 01/01/2005. More Database News We getting ready to test the beta release of our 3rd party database that's compatible with Language Environment/MVS. Unfortunately, the data security folks seem to have forgotten how to set up CICS 4.1 regions. We've been running CICS 4.1 for months in the Time Machine LPAR, but now that we're building CICS 4.1 in the production LPAR Development Test Facility we're fighting all the same CA-ACF2 security problems we had bringing up CICS 4.1 in the Time Machine. Scheduling the database upgrade into production still looks like a big headache for the database group and every application that uses it. It might take six to nine months. Nap Time I've been to a couple of meetings since the last STL-TMR. One was the quarterly off-site departmental meeting: 1997 Accomplishments and 1998 Goals. It was an afternoon meeting at a nearby hotel, so we got snacks rather the full-size meal Cory would expect. As they listed all the projects on the powerpoint slides it seemed that every application had Year 2000 work going on. The Unix folks said they only had to change 34 lines of C code. They must build 'em better than the mainframe geeks do. I attended another meeting on Mainframe assembler utility subprograms. The date routines have already been handled. The remaining assembler routines don't have date risk, but they need to be re-assembled to work with the new releases of system software we're installing, especially SMS (System Managed Storage). Now they need to upgrade perhaps 150 utility subroutines, and schedule the testing and implementation. They're trying to figure out how to test these utilities. The applications developers are not rushing to volunteer, and no one wants to delay Year 2000 applications testing. Most of these routines are I/O oriented, create a tape and assign the dataset name at run time, dynamically allocate QSAM files from a COBOL program and re-use the DDNAME, upload/download files to our servers, fetch control cards with some editing, BDAM I/O for COBOL programs, POINT access for ESDS VSAM files, a custom despooler for report tapes, all kinds of screwy little tasks. Some of these programs are obsolete, but no one is quite sure exactly which ones yet. Now is a good time to clean house. Miscellaneous notes I haven't been socializing enough lately, so no news from other St. Louis area Year 2000 projects (guerilla or otherwise). It looks like I'm nearing the end of my active Year 2000 participation (after nearly two years), since the application I work with most is almost done with Time Machine testing. I may provide some Y2K support for another big application in my department that starts Time Machine testing in March with Group 2. My project leader just dumped about a dozen old OS/VS COBOL programs on me to convert to COBOL II and merge in with our next release. They must be delivered to the test group by May 1st, and I'm itching to crank some code again. Management has finally decreed that all OS/VS COBOL programs must be migrated to COBOL II or higher as soon as conveniently possible. I've been waiting several years for this. The tricky part now will be to keep the systems software current, and prevent any new date problems from creeping into the applications. -- Arnold Trembley http://home.att.net/~arnold.trembley/ "Y2K? Because Centuries Happen!"