Feb 29 ’08

IMS Connect and RRS Performance and Diagnostics

by Jack Yuan in z/Journal

The integrated IMS Connect function of IMS, IBM’s premiere hierarchical database management system and transaction processor, provides TCP/IP connectivity to the Transaction Manager component of IMS. IMS Connect provides TCP/IP socket management and message conversion capabilities that let TCP/IP client applications submit transactions and commands to IMS.

The z/OS Resource Recovery Services (RRS) is a sync point manager. It uses a two-phase commit protocol to coordinate the commitment or rollback of changes to the protected resources of multiple subsystems so changes are made in all subsystems or no subsystems and data integrity is ensured (see Figure 1).

The scope of an RRS transaction is contained in a Unit of Recovery (UR). All updates to resources contained in a UR are either committed across all participating subsystems, referred to as resource managers, or are all backed out across all participating subsystems.

From an RRS perspective, an IMS subsystem is a data resource manager. That is, IMS manages the protected data resources and performs the actual commitment or rollback of changes as RRS directs. However, the IMS Connect function, which communicates with RRS independently from IMS, also can serve as a communication resource manager and can take on the role of a Server Distributed Syncpoint Resource Manager (SDSRM). When a resource manager takes the role of SDSRM, the SDSRM decides when all participating subsystems commit their changes instead of RRS.

RRS uses the z/OS system logger to store information about the active URs and the participating resource managers in logs on a coupling facility, which is periodically offloaded to disk.

IMS Connect and RRS

IMS Connect and RRS provide support for two basic transaction types: global transactions and local transactions. The first is for a global transaction that could involve multiple IMS systems. A global transaction is a unit of work in a distributed transaction processing environment that requires the participation of multiple resource managers. For IMS Connect to process global transactions using RRS, the transaction messages must be defined with a sync level of sync point (see Figure 2).

For IMS Connect to process local transactions that have a sync level of NONE or CONFIRM with RRS, the IMS OTMA synchronous shared queues function must be enabled (see Figure 3).

A third scenario in which IMS Connect can work indirectly with RRS is when a transaction submitted by IMS Connect to IMS is processed by an IMS application in an IMS dependent region, and that application invokes another resource manager, at which time RRS becomes involved again. An example of this scenario is when an IMS application invokes a protected Advanced Program-to-Program Communications (APPC) outbound allocate call.

The remainder of this article provides some tips for using RRS, IMS Connect, and IMS.

Timeout Values for J2EE Client Applications

To coordinate a global transaction, a Java 2 Enterprise Edition (J2EE)-compliant application server, such as IBM WebSphere Application Server, uses a Java transaction manager to communi- cate with the client application components and the resource managers, such as IMS, through resource adapters, such as the IMS TM resource adapter.

If a resource manager takes too long to implement the changes requested in the transaction submitted by the client application, or if the transaction involves many resource managers, the client application can appear hung. To prevent excessive wait times or hung client applications, set a timeout value for your client applications that’s acceptable to your installation. Remember, however, that if your timeout value is too short, and IMS processes a message on its queues from a client that has already timed out, the IMS application running in the dependent region could abend.

Alternatively, designing your transactions to involve fewer resource managers also can reduce wait times for client applications.

Create More IMS-Dependent Regions When Using RRS

Updates to IMS databases are performed by application programs running in IMS-dependent regions. If an IMS application program is updating a database at the request of an RRS-managed transaction, then the application program remains scheduled in the dependent region for the duration of the RRS two-phase commit process, which may or may not be delayed by other participating subsystems. While an application program remains scheduled in a dependent region, the dependent region has a WAIT-RRS status and the application program can’t process other transactions.

Defining additional IMS-dependent regions can increase the transaction throughput rate by reducing the likelihood that subsequent transactions will have to wait for an application program to be scheduled in a free dependent region.

Also, when defining the IMS transa c t i o n s RRS ma n a g e s , s p e c i f y SCHDTYP=PARALLEL and PARLIM=0 in the IMS TRANSACT macro so different transactions of the same type can be simultaneously processed in multiple dependent regions.

Process Multiple Transactions of a Global Transaction on One IMS System

A global transaction can contain multiple IMS transactions with the same IMS transaction code. Due to restrictions related to the transfer of database locks and buffers, all the IMS transactions contained in a global transaction must run in one IMS system.

Minimize the Impact on Performance of Offloading Log Data to Disk

RRS logs many activities related to the RRS events and services. The RRS data is written to a log stream. When the storage used for the log stream reaches a user-defined high threshold, a percentage of the total storage used, the z/OS system logger offloads the data to disk. The system logger offloads only enough data to bring the total storage used down to the low threshold and then stops offloading.

Correctly setting the high and low thresholds for offloading can minimize the performance impact of offloading. The threshold specifications are set in the z/OS LOGR policy stored in the z/OS LOGR couple data set. Setting the high threshold too low or the low threshold too high can result in offloading too frequently, which can slow performance. On the other hand, setting the high threshold too high could lead to the log stream storage becoming full before the system logger can offload to create more space. If a coupling facility or staging data set space for a log stream becomes completely full, the system logger rejects all write requests until the log data can be offloaded to disk.

Also, if you’re using a coupling facility log stream, determining the optimum size of the coupling facility structure helps in handling the offload processing rate and in keeping more log data available on the coupling facility.

If you’re using a disk-only log stream, the size of the staging data set is another factor affecting RRS performance. Make the size of the staging data set large enough to hold all the log data in the coupling facility.

Finally, consider not using the RRS archive log stream, which will reduce the RRS logging activities.

Diagnosing Problems Related to RRS and IMS Connect

The first step in resolving any problem is to determine where the problem actually lies. For example, if an IMS transaction managed by RRS hangs, the IMS Connect client application might time out the transaction request, but the UR might remain hung in IMS, RRS, or both. To resolve this situation, you’ll want to determine where the UR is hung. IMS Connect, IMS, and RRS together provide a variety of methods for determining where the problem lies.

With IMS Connect, you can issue the IMS Connect MVS command VIEWUOR to display the status of a specific UR or of all URs IMS Connect currently manages. In IMS itself, you can issue the command /DISPLAY UOR ALL to display the status of all URs in IMS. IMS may have any number of different types of URs other than those associated with IMS.

From the RRS ISPF panels you can view even more comprehensive RRS information for resource managers, work managers, URs, and log streams.

If necessary, take an SVC dump of the IMS control regions and dependent regions, the IMS Connect address space, the RRS address space, and the z/OS system logger address space.

You also can generate valuable diagnostic information by using the trace functions of IMS Connect recorder, the RRS component, and other associated components such as the IMS RRST table trace and IMS OTMT table trace.

Running RRS and IMS with the RRS CTRACE and the IMS OTMT and RRST traces is recommended. Also of particular use in diagnosing problems are the IMS Connect internal traces, HWSTRACE and BPETRACE, which you can view in a dump of IMS Connect in IMS Version 9. In IMS Version 10, you don’t need a dump to view the HWSTRACE and BPETRACE traces.

For IMS Connect traces, the default size of the IMS Connect trace tables can be small for diagnosing some problems, including those related to RRS. To ensure your trace tables capture as much useful information as possible, increase their sizes in the IMS BPECFG PROCLIB member. For example, the following size specifications, which define 200 4K pages, should be sufficient:

TRCLEV=(*,HIGH,BPE,PAGES=200)

TRCLEV=(*,HIGH,HWS,PAGES=200)

An additional source of diagnostic information is the IMS Online Log Data Set (OLDS), which also can provide detailed RRS diagnostic information.

If an IMS-dependent region hangs for a long time with a WAIT-RRS status, you can try issuing the IMS command “/ STOP REGION reg# ABDUMP transaction- name” to roll back the transaction and free the dependent region or you can use the RRS ISPF panels to abort the UR and get out of the wait state.

Keep Your IMS RRS-Related Maintenance Current

IMS Version 10 provides many enhancements that exploit z/OS features and provides effective RSS twophase commit processing. For example, the IMS Version 10 APAR PK37614 offers the complete outbound protected conversation support for transactions running in the IMS shared queues environment. If you use global transactions with IMS Connect transaction, or if you run IMS Connect with the IMS shared message queue support OTMA commit-then-send messages, ensure that your IMS maintenance is up-to-date with all the RRSrelated enhancements.

Conclusion

This article has suggested some methods for improving performance when IMS Connect, IMS, and RRS work together and has highlighted some of the diagnostic methods and resources available with these products. The IMS development team is committed to high-availability, performance, and data integrity, and continues to enhance IMS Connect support for two-phase commit processing with RRS. Z