Jaqui Lynch - MVS/XA to ESA 4.2 MIgration and Performance Changes seen


Presented at IBM Large Systems Performance Conference in Poughkeepsie, September 1992

                  
                        MVS/XA 2.4 to ESA 4.2 
                Migration and Performance Changes Seen 
                                    
                             by Jaqui Lynch
                             Boston College

Introduction

During March of 1992 Boston College migrated from MVS/XA 2.4 to ESA 4.2. The purpose of this paper is to discuss some of the problems along the way, the performance changes noticed during this migration, and changes that had to be made to the IPS and ICS. Boston College has a fairly simple environment - a 3090- 180J running MVS and CICS v2.1.2. There are two major CICS systems - an online library system and the university's online administrative systems such as registration, etc. Workloads are basically broken down into 6 categories: Batch, System overhead, the Library system (called Quest), the test CICS systems, TSO and the administrative CICS system.

Capacity planning and performance measurement are basically new areas at Boston College and, thus, a great deal of work had to be done to set up the IPS and ICS before the ESA migration started. It was difficult to perform before and after comparisons, because no history of workload data had been kept and the only tools currently available were RMF and SLR. It was also difficult because of the nature of the workload at BC - it is very cyclical and tends to change in leaps, rather than gradually, as new systems are added, and lastly, the system is never static - it is always being updated.

The network environment that BC is in is fairly complex, with both Internet and Bitnet connections to the IBM, TCPIP connections to the Library system, multiple LAN technologies, dial-in users via a 7171, two JES subsystems running under the one MVS, plus connections to the Vaxes and to various other hosts. This means that NJE is heavily used at BC, and thus the migration to the new JES2 was a major concern. The decision to distribute some functions from the mainframe onto the RS/6000 was a prime factor in the decision to go to ESA, as the requirements included NFS and APPC, and BC had also purchased Escon channels. Thus it was decided that the installation would take place in two phases - this paper discusses the installation/migration phase one, whilst phase two is currently underway. Phase two is the implementation of features such as DLF, VLF for clists, Escon, APPC/MVS and CICS/ESA.

The system installed was MVS/ESA v4.2 via IPO 91c at 9103 with some Hipers applied. Releases of both the old and new products are listed on the accompanying transparency. The product that caused the most problems was the new version of JES2, as the NJE hooks have changed considerably. It also became necessary to install CA-1 r5, which we hadn't expected.

Problems

During the installation process, several problems were encountered. Most of these were fairly minor such as forgetting to update COBOL parms, but others were more serious. These included problems adding users in Racf, NJE to Vaxes or non ESA 4.2 systems stopped working, JES2 looked like it was hanging (turned out IKJEFNL was in a loop), RMF was reporting incorrectly and some modules had been linked incorrectly. Reworking the exits, particularly those for JES2, was a major effort as many of them no longer existed or had new exit numbers. This was particularly the case with NJE.

Workload Changes and IPS/ICS

Changes in the ICS were fairly minor and consisted primarily of adding the new STCs and adding an entry for the ASCH subsystem. The IPS was another story. Once it had been decided to migrate to ESA, the IPS had been reviewed and cleaned up considerably so that the migration would be simpler. Rather than using the IPSCONVT program, it was decided to manually change the IPS, and to keep it as close as possible to the old one, which was providing excellent performance. As can be seen from the transparency, the major changes consisted of removing the WKL parameter early on, removing all Obj, Dobj and Aobj statements, and removing ISV statements. A performance group was then added for ASCH and Asrv and Dsrv parameters were coded on each of the domains. Ieaopt00 was left alone to default, and we are now monitoring the system and watching the things it affects. Ieasys00 was also not changed very much, the main change being to increase maxuser from 250 to 350. CSA, real, etc were left as they were. There was also very little change in the workload breakdown before and after ESA, which was not at all surprising to us. The workloads at 11am and 3pm, before and after, are compared in the accompanying transparency.

TSO and CICS

Both TSO response and CICS response degraded a little after ESA went in. TSO average response went from .283 to .335 and CICS went from .368 to .416. While this change went totally unnoticed by the users, we are still investigating the causes. There was no noticeable change in the average number of CICS transactions per day - this remained at about 90,000 (9-5) for Prod, and the Library system also held steady. The average TSO users logged on at the same time varied between 20 and 28 as per normal, but STCs increased from between 46-55 to 57-63.

Storage and Paging

The swap rate, transaction rate, UIC min, migration min, movement within Cstor, pages in/out per swap in all decreased, some considerably as a result of going to ESA. The demand paging rate was a little erratic - it decreased in the morning but increased for the afternoon.

CPU Utilization

It was expected that the jump from XA to ESA would increase CPU by between 10 to 15% of what was currently being used. This was not the case, however. Average CPU before ESA was 28.36% and increased to 30.41% afterwards, while 9-5 CPU went from 43.83% to 45.75%. This amounted to an increase of only about 4.9% of current load, considerably less than had been expected.

DASD Time and Channels

The DASD subsystem at BC consists of a 3880 with Ds and Es behind it, and a 3990 (32MB cache) with 3390s and 3380Ks behind it. The system was not well balanced as we were waiting to order an additional 3990 and some more 3390s so that we could get rid of the older equipment and balance across the controllers and cache. The I/O rates to the 3880 often get up to 50 I/Os per second while the 3990 averages about 190 but has been seen over 250. After ESA went live there was about a 12% increase in the amount of I/O being done to the 3990 DASD, primarily because that is where all the ESA volumes were moved to. At the same time there was a 50% decrease in the I/O going to the 3880 attached DASD. Other important indicators for the 3990 - chpid utilization, response, and IOSQ increased a little, while Pend, Disconnect and Connect all stayed about the same. For the 3880, a corresponding drop was seen in everything, except the connect time and chpid utilization which both increased.

Summary

All in all, BC was very pleased with the migration from XA to ESA. It was not as difficult or as hard on performance as had been expected. The major changes noticed were that CPU increased a little, as did TSO and CICS response time, while UIC, etc decreased. Some of the changes can be directly attributed to changes in the disk layout due to ESA going into production, and others are still being investigated. We still have some outstanding problems with respect to a number of JES2 Hipers that need to go on, and I caution anyone migrating to the new JES2 to go to 9201 at least, if you are a heavy NJE/RJE user.

Index of Jaqui's Papers

Pete's Wicked Home Page


© 1995 Jaqueline A. Lynch

Compiled and edited by Jaqui Lynch

Last revised June 5, 1995