September 1998
Newsletter

IOFTech    Maintenance   Release8G       Newsletters    Doc    FAQ    Contact    Home

Year 2000 Testing Tips

Topics

Introduction

IOF Release 7D is year 2000 compliant. There are no known problems with processing dates and date-related information after the turn of the century. Both IOF development and many IOF customers are stress testing the product with the clock set to various dates before and after January 1, 2000.

The October, 1997 Newsletter and the IOF Support for the Year 2000 web page are two additional sources for information about IOF support for the year 2000.

This newsletter gives several additional hints and suggestions that may make your Y2K testing with IOF easier.

Authorization Passwords

IOF requires authorization passwords that are CPU and date sensitive. Most normal production authorization passwords will not permit Y2K testing because the expiration date is earlier than January 2000. We provide two authorization passwords for Y2K testing:

IOF is not authorized to run by the CPU dependent test password when the clock is set prior to June 1, 1999. Therefore when this password is applied in lieu of your production password, that copy of IOF will not run when you IPL with the current date. If you need to occasionally run your Y2K system with the current date set, you can apply both passwords concurrently.

Assume that your normal production patch is: 

   REP 00  1234,88EC,FEDC,9999   CPU 9021 2477
   REP 08  3333,4444,5678,AABC   CPU 9021 2499
   REP 10  7878,3344,ABCD,FDDC   CPU 9021 2507
Assume your CPU dependent Y2K test patch is: 
   REP 00  2000,FFED,A99B,CDEF   Y2K patch
The Y2K test patch MUST reside at location 00. Your production patch can be adjusted upwards, however if it is kept contiguous with the Y2K patch. The two patches shown above could be combined: 

   REP 00  2000,FFED,A99B,CDEF   Y2K patch   
   REP 08  1234,88EC,FEDC,9999   CPU 9021 2477
   REP 10  3333,4444,5678,AABC   CPU 9021 2499
   REP 18  7878,3344,ABCD,FDDC   CPU 9021 2507
This allows the same copy of IOF to run on any of your production machines with the date set to the current date, and on your Y2K lpar with the date set between June 1, 1999 and July 31, 2001.

Setting the Clock

When you set the clock during IPL in response to the IEA886A or IEA888A message, you have the option of setting either the local date/time or the GMT date/time. For example, suppose the system issues: 
         IEA888A GMT   DATE=1998.288,CLOCK=13.01.15
     *00 IEA888A LOCAL DATE=1998.288,CLOCK=08.01.15  REPLY U, OR GMT/LOCAL TIME
This message displays both the local and GMT time and allows you to reset either time. When you reset the time for Y2K testing, you should normally set the GMT time. By default, local time is the GMT time adjusted by the local offset as specified in the CLOCKxx member of 'SYS1.PARMLIB'. The MVS TIME SVC returns the local time value, but the S390 STCK instruction returns the GMT value.

JES2 uses the TIME SVC for most timestamps but does use STCK to timestamp a few internal control blocks. IOF displays JES2 generated timestamps in the Job List Menu, Output Group Display, Job Summary Panel, and other displays. If you do not set GMT, some IOF displays will be inconsistent.

Future Jobs on the Production Spool

If your Y2K lpar is connected to your production system via NJE, jobs that run on the Y2K system will appear to have run in the future when they are returned to the production system. The same effect is seen if Y2K jobs are offloaded with the JES2 offloaders and reloaded on the production system. IPLing the Y2K system with the current date produces the same effect.

Both JES2 and IOF tolerate future jobs on the spool with no problem. The IOF AGE calculation yields a negative result for future jobs. Negative age values are converted to blank for display to eliminate confusion and eliminate problems with Rexx execs and clists that process the age value.

Four Digit Year in SYSLOG and OPERLOG

The HCFORMAT parm on the HARDCOPY statement in the CONSOLxx member of 'SYS1.PARMLIB' specifies the format of the date field in SYSLOG. IOF also uses this parm to control the format of the date field display in OPERLOG. The default format displays a 2-digit year. HCFORMAT(CENTURY) specifies that the year should be displayed as 4 digits.

Some sites are already running with HCFORMAT(CENTURY) specified. Sites that decide to convert to 4 digit year will likely do so long before the year 2000.

The 7D version of SLAMRUN, SLAMDEF, SLAMINST, SLAMPROC, SLAMMEMO, SLAMOPER, SLAMARCH, and SLAMWTR automatically detect and adapt to the format of the year in use. Note, however, that if you have defined local index conditions in SLAMINST and plan to convert to use 4-digit year, you should update your definitions. The new YEARSIZE variable is set in all SLAM clists to a value of 2 or 4 to indicate the number of digits being used in SYSLOG or OPERLOG.

If you are running SLAMMEMO to make memo copies of old SYSLOGs you must be careful when you switch from 2-digit year to 4-digit year. SLAMMEMO can not properly index a mixture of 2 and 4 digit year log dates. Be sure to run SLAMWTR or an equivalent writer to remove all old SYSLOG data that use a 2-digit year from the spool before you run SLAMMEMO to capture SYSLOG data that uses 4-digits for the year.

IOF Server Utilities

The May 1998 Newsletter describes three IOF Server Utility Rexx execs that may be useful for Y2K testing. These utilities require the IOF APPC server to be installed, and require a VTAM connection between the production and Y2K systems. The utilities can be browsed and downloaded by clicking below.

Triangle Systems, Inc. PO Box 12752, Research Triangle Park, NC 27709
Email IOFTech@Triangle-Systems.Com