STL Time Machine Report #13 - Fri 10 April 1998 (1998-04-10) Our contractors are continuing the time machine testing of our application that uses our third party database. I talked with one of our QA testing gurus and he says that testing is easier with scheduled jobs to prep the test data for the environment. Run the jobs, save the output, analyze the results. Two annual file purges deleted all the data, instead of just the year-old data. The basic cause was subtracting 01 from year 00 and getting an answer of 01 instead of the expected year 99. This was easily corrected in the time machine, and the fixes are already being updated to production. A bigger problem occurred on Tuesday. A critical database was corrupted and the entire day's test run was trashed for everybody. Yesterday, one file was still wrong, which caused some tests to produce unexpected results. As far as I've heard this is a setup and data management problem rather than a Year 2000 date failure. CICS issues I've posted several times about the shock our management experienced when they discovered that CICS 3.3 won't even come up after 1999-12-31. I've even posted this in bit.listserv.cics-l. I have seen postings from other CICS mainframers that they've had no problems testing CICS 3.3 with post-2000 dates. Now I'm not saying they're wrong, but there are a couple of things that could explain the difference between our experience and theirs. A few of the respondents said they were running CICS 3.3 with MVS/ESA 4.2 or 4.3. We upgraded to MVS/ESA 5.2.2 last September, and IBM says MVS 4.x is not compliant and not supported. MVS 5.2.2 is the minimum compliant release. Also, some of these posts did not indicate whether they tested in an LPAR booted up with a forward date, or by using date override tools such as Hourglass or TicToc or SupportPak CH15. From personal experience I know that CICS 3.3 can be tested with date override tools because CICS 3.3 knows the real system date is different from the local time zone. If we had only tested that way we would had a big surprise coming. I was sharing some war stories with the CICS Guru who designed our application ten years ago. He's now combining MVS with Unix FTP in another department. He told me that he'd heard at SHARE conferences that older releases of CICS and MVS don't know that 2004 is a leap year. Bottom line, if IBM tells you that MVS 5.2.2 and CICS 4.1 are the minimum compliant releases, I believe them. High-Level Assembler Our technical services department has got religion. Now they're telling us that every last assembler program in the shop must be re-assembled with the high-level assembler, or programs won't work with SMS after rollover. What? Last I heard, the machine level instructions don't change their behavior when the calendar rolls over. Some of our assembler programs haven't been reassembled in ten years, and tested out fine in the Time Machine. Also, they're willing to reassemble the programs, but they won't test them. Needless to say, this would add a lot of work. I posted the question to comp.lang.asm370 and most of them thought it was nuts. You do have to change assembler programs if they have application date logic (we've already done that), but an MVC or BALR instruction shouldn't die in the year 2000. All this heartache seems to be caused by upgrading Compuware's Abend-Aid. Anytime a program abends the dump analysis report says "Danger Will Robinson, this program was created with a language translator that is not Year 2000 compliant". IBM says you can execute 20 year old cobol programs with LE/MVS runtime libraries, but assembler doesn't require any runtime library. Here's the only date issue in IBM mainframe assembler I can find. The assembler provides you with &SYSDATE so you can store the date of assembly in your program somewhere. It's format is MM/DD/YY. The High-Level Assembler still supports &SYSDATE, but also gives you &SYSDATC, which has a format of YYYYMMDD. What do you do with the date of assembly? I guess you can put it in macro expansion comments or an embed it in an eyecatcher, but I don't see this causing program dumps on its own. And if it did, it would be a programmer's error and not an assembler defect. I suspect they will reassemble and time machine test a few, selected modules, but not every assembler program in the shop. We've already updated our internal procedures so that all future assemblies will be in High-level Assembler. More COBOL fun A couple of weeks ago I was able to help out another department that is converting their OS/VS COBOL to COBOL II. They installed a COBOL subprogram and it caused another system to crash. It turned out they compiled with NCAL (no autocall link). They normally link their programs statically, but the other system called their program dynamically and could not find its runtime environment. This one's a little hard to diagnose for lots of COBOL'ers. They had to back out the program and recompile without the NCAL linkedit option. These kinds of problems will happen when you compress 15 years of deferred maintenance into 2 years of Y2K death marches. Y2K Awareness Fully one third of the 1998-03-27 issue of the Kiplinger Washington Letter was devoted exclusively to Y2K! Their rules on quotation are pretty strict but here goes: "The year-2000 problem is VERY serious...There will be disruptions...some utilities could have trouble...But no massive breakdowns...The problem will slow the economy...Profits will suffer...But no recession...Concentrate on what's most critical to your company's mission...Have a manual, nonelectronic backup system...Prepare to use 60% of the time testing...Cities' bond ratings at risk..." None of this will surprise you. Just remember that Kiplinger's is targeted toward non-technical businessmen. Thursday the Wall Street Journal had an article on corporate Year 2000 costs, buried on page B8, I think. Costs are higher for some companies because they are reporting all costs for new hardware and software as year 2000 related. Project Management One question that comes up a lot is: How do you manage year 2000 changes when you still have other projects going on? You know how it is, you're working on a project, everthing's taken apart, and now you need to fix a production problem in a program that's being modified for a project. How do you coordinate year 2000 remediation with current projects? We finessed this problem. Most of our applications are on a release cycle, two releases a year. One release was year 2000 compliance changes only, any other enhancements were deferred unless they could be put in the year 2000 compliant release without bogging it down. I don't know if it helps you, but it worked for us. Just don't forget to do Time Machine testing. Another PHM story I have a friend who works for a large retailer. They are doomed. His PHM says UNIX, Windows, and packages will replace the mainframe in December 1999. The PHM reports to a CFO. The CFO is out golfing with his brother-in-law who works for a major stock brokerage in the area. The broker asks the CFO how they're doing on Y2K. I don't know, says the CFO. Well, how many guys do you have working on your Y2K project? I don't know, he says. So the next time the CFO sees the PHM he asks him, do we have a Y2K project and how many people are on it? Oh, yeah, we've been working on it since 1996, everybody's working on it. Yeah, right. Does the CFO see the budgets or not? 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!"