STL Time Machine Report #12 - Sun 29 March 1998 (1998-03-29) Our contractors did some "dry run" testing this past week. They found a few cosmetic errors that have been fixed. I believe they were testing a leap day 2000 rollover. This is a COBOL mainframe application that uses the third party Database and has a few CICS components as well. This is the application that currently processes dates past 1999, but has always used two digit years. Under our testing strategy, only production code is moved into the Time Machine. Any required fixes are applied there to resolve testing problems, and then migrated to production through our normal maintenance or release upgrades. Two years ago I was surprised to learn we had more than about 50 internal applications. My group supports at least one not-ready application, and we can't find anyone willing to sign off on shutting it down, even though no one uses the reports. Unix Stuff Last week I forgot to relate a funny story from Eric Buckley. At his last contract they were doing time machine testing and someone tried out Unix to see what happens when the 32-bit integer rolls over in something like 2037. I don't know if I've ever seen this posted in comp.software.year-2000. Eric laughed as he told the story. All the userid's expired and the system could not be used at all. The operating system had to be re-installed. I'm not sure, but it might have been an HP box of some kind. I had an interesting conversation with a former mainframer who transferred to one of our Unix groups a couple of years ago. I asked him about their Y2K fixes and he told me some interesting things. They have trace files, used for real-time diagnostic purposes, and log files which are batched into the mainframe complex, primarily for network billing. The Log files use tm_year and store the year in a single unsigned binary byte. They had to change four common subroutines to force this year to always be in the range 00-99. This was done because the mainframe expects a two-digit year, and windows it into a four digit year. The trace files use a 16-bit integer to hold the year, and are displayed by diagnostic programs. The trace files were changed to always store a full four digit year, 0000-9999, and all the diagnostic programs were modified to expect that. S/370 Assembler Fun Just recently our mainframe tech services department decreed that all mainframe assembler programs need to be reassembled with the High-Level Assembler. When we installed MVS/ESA 5.2.2 last September, we also installed Compuware's Abend-Aid, which has the disturbing characteristic of reporting on every dump that the failing program was created with a Language translator that is not Year 2000 compliant. It will only omit this message for COBOL for MVS & VM and the High Level assembler. So this last week I had to compile a list of all the assembler programs my group supports. At least 35% of these modules are obsolete. The most critical ones have already been successfully tested in the Time Machine LPAR, and passed. That includes modules last assembled ten years ago, at least two releases before the high-level assembler. The tech services department has a completely different list of what they believe they own, and there's a little overlap here to add to the confusion. They are willing to reassemble them, but they want the applications programming areas to test them. This is causing a bit of controversy. Here's the problem: If we reassemble a program with no changes, it still has to be tested or else we can't be sure it still works. On the other hand, our T/S people say that if it wasn't assembled with the most current version of the assembler, they're not sure it's safe, no matter what our test results are. A funny story A good friend of mine works for a PHM at another company. They run VSE/ESA and VM, and his pointy-haired boss is trying to get rid of the IBM mainframe. He wants to run Unix and windows with only purchased software packages. They are a retail operation and their most critical mainframe app is an old inventory system developed internally. They had a presentation recently from a vendor who sells an inventory package that looks like it meets their needs. The PHM listened to the presentation and at the end asked what kind of system they would need to run this package. The answer was MVS. So the PHM asks, don't you have a client/server version of this? And the vendor says, yes, we will have a client/server version available in late 1999. Okay, says the PHM, we'll order the client/server system when it becomes available. Previous issues of the STL Time Machine Reports can be found 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!"