In-Depth

Y2K Testing in a Parallel Sysplex

• 09/01/1998

Testing for Year 2000 (Y2K) compliance in a Parallel Sysplex configuration can require system reconfigurations and considerable time-of-day clock evaluations. It also raises some unique questions:

• What software and files can be shared (if any) between the production and test environments? The answer is, usually none.
• Is it necessary to test in a Parallel Sysplex environment at all? Running Year 2000 compliance tests in a Parallel Sysplex cluster is seldom required except for applications that are truly multi-system (that is, those applications which cannot be tested in a single-system environment).
• Can one Parallel Sysplex cluster be in production while another year 2000 Parallel Sysplex test is running on multiple processors? It depends on the processor models being used.

This article will attempt to address the issues associated with supplying the time source for the Year 2000 Parallel Sysplex testing environment. The article will focus on four areas:

• Production multi-system Parallel Sysplex environments
• Using SIMETRID
• Year 2000 Sysplex Test DATESOURCE
• Enhanced Parallel Sysplex Clock Function

If you do intend to run Year 2000 tests in a Parallel Sysplex cluster, keep the Y2K test images isolated from other systems. Do not share the coupled data sets with other system images. It is also essential to completely isolate the data used in the Year 2000 test environment.

In addition to the requirement to avoid mixing the application data on the test system with production data, Y2K testing also requires isolation of system data, such as JES2 spool and checkpoint and catalogs. This is because Data Set Control Block (DSCB) entries, VSAM Volume Data Set (VVDS) entries and catalog entries are time stamped, when datasets are referenced. A mixture of time stamps (current time and Y2K time) can cause the programming to make unexpected decisions.

Step one in Year 2000 testing is to have an understanding of Parallel Sysplex cluster requirements. An operational IBM 9037 Sysplex Timer is required for clock TOD synchronization when a Parallel Sysplex cluster consists of more than one Central Processing Complex (CPC). All CPCs in a Parallel Sysplex cluster must be connected to the same Sysplex Timer Network (9037 NET_ID).

The operating system can be customized to either use or not use the Sysplex Timer. This is determined by the ETRMODE parameter found in the CLOCKxx member of SYS1.PARMLIB. All images attached to the same Sysplex Timer Network and have specified ETRMODE YES will have their TOD clocks set, synchronized and kept synchronized to the Sysplex Timer.

By specifying ETRMODE NO, other logical partitions not participating in the Parallel Sysplex cluster may have the operator prompted at Initial Program Load (IPL) time to set the partitions logical TOD clock to a value different than the Sysplex Timer. In this way non-clustered images may perform Y2K testing.

The Sysplex Timer can also provide the time zone and daylight savings time offset if the images are using ETRMODE YES and ETRZONE YES, or they may optionally use the TIMEZONE parameter in the CLOCKxx member.

SIMETRID has existed since Parallel Sysplex clustering was first introduced in September 1990. SIMETRID is a parameter in the CLOCKxx member of the SYS1.PARMLIB data set that allows multiple simulated Sysplex Timer Networks to be created. This configuration is typically used to create a Parallel Sysplex cluster for pre-production testing purposes. An operational Sysplex Timer is not required if the cluster is created on one processor (LPAR Mode), but a Sysplex Timer may be attached and used by production images simultaneously if desired.

SIMETRID NN allows for the creation of multiple Parallel Sysplex clusters across multiple OS/390 images if they are running under LPAR on the CPC, as VM Guests on the same CPC, or in a combination of the two. All OS/390 images in the SIMETRID cluster must use the same SIMETRID value (NN number). It is recommended that the SIMETRID value is different from the real 9037 network ID used by other clusters.

Using SIMETRID NN is fine when creating a Parallel Sysplex cluster that has the same date and time as the physical TOD clock of the machine, but not when you need to create an additional cluster environment for Y2K testing. In our example, the additional test Parallel Sysplex cluster would have the same date and time (provided by PR/SM LPAR Licensed Internal Code) as the production cluster.

The Year 2000 Sysplex Test DATESOURCE function allows the definition of multiple logical partitions (LPARs) within a CPC to have a synchronized time and date other than that of the production logical partitions. This eliminates the need to dedicate an entire CPC to the year 2000 testing of a multi-system Parallel Sysplex cluster. This testing capability is available on IBM S/390 G3, G4 and G5 Servers, the Multiprise 2000 server family and the Application StarterPak.

When using the Sysplex Test Datesource function, the test Parallel Sysplex cluster will again use the SIMETRID parameter in the CLOCKxx member. The test "Group" is identified by settings made through the CPC’s Support Element or Single Object Operations via the Hardware Management Console (HMC). The operator specifies a date and time to which the test group will be synchronized and which LPARs belong to the test group. To change the test date, an IPL of the test images is required.

This feature may be used for Y2K Sysplex testing when all test images are running on the same CPC. An operational 9037 is not required, but one may be connected. Other images on the same CPC (and other CPCs in the Sysplex Timer Network) could run a production Parallel Sysplex environment with the current date simultaneously with the Y2K test cluster.

Note: 1) Only one test group is allowed at a time; 2) Datesource requires EC F10640, Driver 98 or higher;3) APAR OW28604 is recommended. It changes SIMETRID support to prevent an image from joining a Parallel Sysplex cluster when its TOD Clock value differs from the TOD Clock of other systems in the configuration. When this condition is detected, message IXC416I is issued.

The Enhanced Parallel Sysplex Clock Function was introduced in May 1998 for the S/390 G5 Server family and provides more options than the Sysplex DATESOURCE function. It enables customers to run different Parallel Sysplex configurations on the same multi-CPC platform with each cluster using a different TOD Clock value, even though they use the same Sysplex Timer network. This capability enables Year 2000 testing in a Parallel Sysplex environment that spans multiple processors, thus reducing the possible need for a dedicated hardware platform. In this scenario, one operational Sysplex Timer Network is required for both the production and test clusters.

Assuming there are multiple CPCs, each processor in each Parallel Sysplex cluster must attach to the Sysplex Timer and the CLOCKxx member must specify ETRMODE YES. SIMETRID must not be specified if the Parallel Sysplex images are participating across multiple CPCs.

The Support Element again is used to set up the environment. Instead of specifying a specific date and time for the group(s), the operator will enter a specific time "offset" for each group. The time offset specifies a value (plus or minus) from the 9037 time value being transmitted. The offset is entered as +/- days, hours, and minutes. To set up a test environment for December 31, 1999, you need to calculate how many days until then. Let’s say it’s now June 11, 1998. There are 567 days until 12/31/99. The operator would enter + 567_days, xx_hours, xx_minutes. The URL http://tycho.usno.navy.mil/cgi-bin/countdown.pl can be used to calculate the days, hours, minutes and seconds until the year 2000.

This Sysplex TOD Clock enhancement has uses other than Year 2000 testing. It obviously allows other Parallel Sysplex clusters to have different TOD dates and times, but this capability can be put to use in another way. For example, some S/390 installations have not converted their TOD clocks from local time to GMT (Greenwich Mean Time) even though this is recommended. Using GMT when migrating to a Parallel Sysplex environment can make daylight savings time changes easier to implement without a cluster-wide outage.

With this new Enhanced Parallel Sysplex Clock Function, customers can run both a multi-system Parallel Sysplex cluster using true GMT and another cluster on the same CPCs using a logical TOD set to local time. In this case the operator would enter an offset that coincides with his local time zone, for example New York (- 0_days, 05_hours, 00_minutes). Notice that there is a minus 05 hours offset entered. If the 9037 were transmitting UTC (Coordinated Universal Time), which is equivalent to GMT, then this "local time" offset resides five hours west of GMT. This could be very useful for an installation that has recently merged with another company. If the other company still used local time set in its TOD clock, both Parallel Sysplex clusters could coexist simultaneously on the same multiple CPC hardware.

Note: A Datesource group and several Enhanced Parallel Sysplex Clock Function groups may coexist on the same processor, but the same LPAR image cannot be used simultaneously across the groups. Up to 15 Enhanced Parallel Sysplex Clock Function Groups may coexist simultaneously.

Hardware Management Console (HMC). On an S/390 CPC, whenever the processor TOD is changed by a processor SET CLOCK instruction, the Support Element is informed and synchronizes itself to the processor TOD. The Support Element clock is also synchronized to the TOD value at 23:00 hours every day.

It is also likely that the HMC is optionally configured to be synchronized to the Support Element. When a SET CLOCK instruction occurs, and the Support Element clock is synchronized to the processor TOD, the HMC clock is then synchronized to the Support Element Clock. Additionally, the HMC clock is synchronized to the Support Element value at 23:15 hours every day.

The HMC time synchronization should be disabled by the ACSADMIN userid by changing the CPC Object Definition. This is recommended when the HMC is controlling more than one CPC and one of the CPCs is running a year 2000 test.

Scheduled Operations. On an S/390 CPC used for Year 2000 testing, the Support Element time can suddenly jump forward a number of years when synchronized with the processor TOD clock. This time change on the Support Element clock would result in the dispatching of any scheduled operations defined for the CPC in the period from the present time until the year 2000. Scheduled operations include tasks such as backing up the hard disk information or transmitting availability information to the CPC vendor.

To prevent a flood of scheduled operations, delete the scheduled operations for the S/390 CPC. If the Year 2000 test is going to cover an extended period of time, reenter the scheduled operations covering the Year 2000 test period.

All hardware and software vendors are addressing the Year 2000 issue in one way or another. For general information on issues, potential solutions or help, the World Wide Web (WWW) is a terrific place to start your search. For further information on Y2K testing in a Parallel Sysplex cluster, visit www.redbooks.ibm.com/SG242070/y2000.html. Other reference materials include the PR/SM Planning Guide GA22-7236, Datesource Announcement Letter (197-300), Enhanced Parallel Sysplex Clock Function Announcement Letter (198-115), The Year 2000 and 2-Digit Dates: Guide for Planning and Implementation GC28-1251 and the OS/390 Parallel Sysplex Test Report GC28-1963, which are available through your local IBM representative. Other useful Web sites are www.software.ibm.com/year2000 and www.ibm.com/IBM/year2000.

ABOUT THE AUTHOR: