STL Time Machine Report #22 - Monday 29 June 1998 (1998-06-29) As I mentioned in the last TMR, we had a serious problem in Group 3 testing last week. Log files dated after 12/31/99 were missing. This problem lasted several days, and many downstream mainframe batch applications were unable to test because they did not have valid input data. This problem is now resolved, and it did not involve any program code, although I imagine Unix programmers were frantically reviewing possible tm_year problems. I know for a fact that some serious desk-checking was being done on mainframe COBOL apps. The problem turned out to be a series of test set-up glitches. Log files were not being pulled from a Unix box (boot-up scripts had some kind of problem). And the log files were not being transferred to the mainframe at one point, also some kind of set-up problem. The final problem in the Mainframe test set-up involved SORT JCL. A SORT job is used to merge three different log files in one day into a combined file. Due to the test configuration the first log file of the day is empty and only the second log file has any data. The SORT JCL should have looked like this: //SORTIN DD DSN=TEST.LOG.FILE1,DISP=SHR // DD DSN=TEST.LOG.FILE2,DISP=SHR // DD DSN=TEST.LOG.FILE3,DISP=SHR But the test JCL actually looked something like this: //SORTIN DD DSN=TEST.LOG.FILE1,DISP=SHR //SORTIN DD DSN=TEST.LOG.FILE2,DISP=SHR // DD DSN=TEST.LOG.FILE3,DISP=SHR The duplicate SORTIN DDNAME caused the sort to stop reading at the end of the first empty file, and to bypass the concatenated datasets containing the test data. Interestingly enough, this apparently did not cause any JCL errors (that anyone noticed), and a great deal of time was wasted looking into program source code problems. There's a lesson to be learned here, but I'm not sure what it is. CICS 4.1 - The Summer of Upgrades I believe we will have all of our CICS regions (around 90 of them) upgraded to CICS 4.1 by September 1. A few regions were converted from CICS 2.1.2 to 3.3 just a couple of months ago, and will be upgraded again. Even if we upgrade from MVS/ESA 5.2.2 to OS/390 2.x next year as planned, we will be on CICS 4.1 through rollover. Database, COBOL, HLASM, and Language Environment/MVS There's no change here. We cannot upgrade to LE/MVS as the default runtime libraries until the production database applications are upgraded to the new release of the database. That probably won't be done until first quarter 1999. There's still some work being done to try to speed that up, but at least we know there are no Y2K problems with COBOL II runtime libraries. They've found one problem with an assembler routine that generates storage dumps on request. It doesn't work very well with LE/MVS and requires some source code changes. This one is not a showstopper, and doesn't seem to be too difficult to fix. Function Point Follies - Again Everyone in my department has a requirement to get 60 hours of training this year. I've used it to take CBT classes on stuff I would never get to use, like Rexx and HTML. Last week I got to take 8 hours of training on Function Point counting. I am now an expert . I know Cory is going to be groaning about this, but I think there is some value to Function Points. I still don't like to count them. I don't think they would work very well on systems software, like OS, compilers, tape managers, et cetera. If you're not already using function point methodology, it would be insanity to use it with Y2K projects. We have been trying to build baseline counts for our applications for two years, and we're not done yet. Nobody here is using function points for Y2K. At this point, it would only slow Y2K work down. There still is some fear on the part of programmers. Last year I posted something to the effect that programmers were worried about being rated by function points per hour, and affecting their raises. This is silly. A typical measurement is something like 6 function points per month per project team. Miscellaneous Stuff Last week I dropped by the chat room. Cory was there, Pam, Tony, several c.s.y2k regulars. I hadn't tried that out for several months, but I thoroughly enjoyed it. Wish I had a log of it, some of the jokes were outstanding! I passed on a copy of the CSIS Y2K conference transcript to the Y2K project director. He was VERY interested in it. "webmaster" has been posting it to c.s.y2k, so you can't miss it. After three weeks on NT 4.0, they added an additional 32 Meg of RAM to my PC. Word 97 seems to come up a little quicker now. Last Thursday the Wall Street Journal reported that Microsoft is discouraging corporations from migrating to Win98, because NT 5.0 is the strategic platform. According to the WSJ, NT 5.0 is going to require a 400mhz Pentium II, and 64 to 128 Megabytes of RAM. Does anybody know if Win98 is Y2K-compliant? How about NT 5.0? No new PHM stories this week. When there's a good one, I'll let you know. As of 1998-06-29, My countdown now reads: 125 days until 1998-11-01 (Beta Test begins) 186 days until 1999-01-01 (External Testing begins) 551 days until 2000-01-01 (Rollover) Previous Year 2000 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!"