STL Time Machine Report #29 - Sunday 13 September 1998 (1998-09-13) Dry run testing is complete using current dates. Monday they begin iteration 1 of forward date testing. The applications have been resynchronized to production libraries, because several have had non-Y2K changes installed recently, and need to be re-tested. Additional job schedules and initialization jobs have been built. Disk space has been increased by 6 logical 3390 volumes, or about 14 gigabytes. Group four, like all previous groups, consists of a "dry run" with current dates, and three iterations of the forward date test cycle. The dry run and each iteration takes about two weeks for a total of eight weeks per group test. Non-mission critical applications are tested outside the Time Machine, using date override simulators. More on the "Summer of Upgrades". The second of our three mainframes was scheduled for a speed upgrade last Saturday night/Sunday morning (just a few hours ago). I haven't heard of any problems. All our CICS regions have been upgraded to release 4.1, except for one region which will be shut down later this year. We have about 80 or 90 of them. It looks like we probably won't upgrade from MVS/ESA 5.2.2 to OS/390 Release 2.5 this year, maybe in early 1999. To my surprise it looks like we WILL upgrade the third-party database this month (rather than first quarter 1999), and we'll try to make LE/MVS the default runtime library at the same time. The problem with Language Environment/MVS is that it uses much more storage in CICS regions than COBOL II runtime libraries. We've been running our CICS regions in the Time Machine with LE/MVS rather than COBOL II runtime libraries, so we know how to do it. We've also found some problems with old OS/VS COBOL programs executed with LE/MVS rather than COBOL II runtime libraries. Especially COBOL programs compiled with the NORES option, or subprograms linked with the NCAL option. So that's why we have a push to get off OS/VS COBOL and convert to COBOL II. For non-mainframers, the difference between OS/VS COBOL and COBOL II (ANSI-74 versus ANSI-85) is roughly equivalent to the difference between K&R C and ANSI standard C. No COBOL programmers available. I've mentioned a couple of times that Venture Stores (a discount department store chain similar to Target) went out of business this year. A buddy of mine at another company tells me they sent a guy to Venture to see about hiring COBOL programmers. They let him interview project leaders and managers, but they didn't have any COBOL programmers left. They'd all gotten jobs someplace else. Too bad rates aren't going up as fast as Cory would like. Date Routines. Back in January of 1997, when I worked on the first pilot remediation project, we knew we had problems with utility date routines. One old assembler routine was simply retired. Another one was fixed by a contractor. The call interface uses two digit years, so it had to be windowed. We have two more standard date routines in COBOL and they support four digit years. Both of the older assembler date routines had leap year bugs that had to be fixed. One of them had caused a really ugly production problem in December of 1992. The other one only had problems with leap years prior to 1969 (don't ask why). It's a good idea to test your date routines very thoroughly. Generally date routines do some combination of date validation, date conversion, and date interval calculation. The most difficult date routine problem is calculating a new date from a given date and an interval of days. Conversion of an absolute day count back to a typical date representation (YYYYMMDD or YYYYDDD) is tricky. You want to test this for problems with leap years. Calculating the day of week is done by MODULO 7 arithmetic (divide by 7 and save only the remainder) against an absolute day count from a known date. For example, if we extend the Gregorian calendar back to Monday, 0001-01-01, the current absolute day count is 729,645 days. Divide it by 7 and the remainder is zero. If you prefer to rest on the seventh day, just add seven to convert a zero result. 1=Mon, 2=Tue, 3=Wed, 4=Thu, 5=Fri, 6=Sat, 7=Sun. A 400-year epoch, like 1601-01-01 through 2000-12-31 or 0001-01-01 through 0400-12-31, is exactly 146,097 days and begins on a Monday and ends on a Sunday. There's also a formula called Zeller's congruence that you can use to calculate the day of week. I'll try to post it to my webpage. Or you can search DejaNews for a posting by Leif Svaalgard on 18 Jun 1998 in comp.lang.cobol. Years ago, at another company, I learned the following routine to convert between IBM Julian dates and Gregorian Dates: 01 02 03 04 05 06 07 08 09 10 11 12 NRML 000 031 059 090 120 151 181 212 243 273 304 334 LEAP 000 031 060 091 121 152 182 213 244 274 305 335 Today is 1998-09-13. 1998 is not a leap year, so we use the normal year table. Looking up 09 we get 243 days. Add the 13, and the Julian date is 1998/256. If you need to convert 2000/193, you need to use the Leap year table. Search it backwards until you find the first month LESS THAN 193 days (07), then subtract that value (182) from 192, and you get 2000-07-11. Several months ago, someone posted a nice routine for checking if a particular year is a leap year. I can't remember who posted it, but I would like them to have the credit. I never thought of this. IF the YY portion of CCYY is '00' THEN LEAP = CC mod 4 ELSE LEAP = YY mod 4 ENDIF If LEAP is zero, then it's a leap year. This has the advantage of combining the 400-year rule, the 100-year rule, and the 4-year rule so that you only need to do one division to determine leap year, instead of three. If you're picky about machine code performance, you would rather divide just one time. As of 1998-09-13, My countdown now reads: 49 days until 1998-11-01 (Beta Test begins) 110 days until 1999-01-01 (External Testing begins) 475 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!"