As described in 2.1, “Workloads” on page 12, a workload is a collection of application programs (started by a simulated operator) where the application accesses data from one or more data stores.

This chapter describes several general-purpose workloads that are used by IBM to report performance results in every release of CICS TS for z/OS. It also highlights some of the functional areas that are covered by the test cases.

This chapter includes the following topics:

One of the primary objectives of testing the performance of the CICS TS product is to ensure that customer workloads do not observe a degradation in performance when upgrading to a new release. The process of comparing one release of CICS TS with another by using identical workloads and identical configurations is known as regression testing.

Each chapter in Part 2, “CICS TS performance information” on page 35 provides information that relates to a specific CICS TS release. A significant component of all the release-specific chapters are the results of running regression test workloads. For more information about the details of workload results, see Chapter 5, “CICS TS for z/OS V5.1” on page 37, Chapter 6, “CICS TS for z/OS V5.2” on page 75, and Chapter 7, “CICS TS for z/OS V5.3” on page 107.

Many workloads are used during regression test. The remainder of this chapter outlines some of the workloads that are available to the CICS TS performance team in the IBM development organization.

The Data Systems Workload (DSW) is a non-threadsafe COBOL application that accesses VSAM files. Transactions use Basic Mapping Support (BMS) maps to interface with 3270 terminals. The amount of files in use varies depending on configuration, but can be in the range of 16 - 320.

A amount of transactions comprise the DSW workload, where 50% of CICS transactions issue at least one file control (FC) request. On average, six FC requests are issued per CICS task. FC requests are distributed in the following percentages:

To simulate users of the application in a controlled manner, IBM Workload Simulator for z/OS is configured to emulate many 3270 terminals. Depending on the configuration, the amount of simulated users can be in the range of 1,000 - 4,000.

Several configuration options are available for DSW. Some of these variants are described in the following sections.

Five CICS regions are configured for the workload. Two terminal-owning regions (TOR) connect to two application-owning regions (AOR). These two AORs then connect to a file-owning region (FOR). Files are accessed in the FOR by using VSAM local shared resources (LSR).

Work enters the system in a TOR and is then transaction-routed to the corresponding AOR. The business logic of the workload then accesses the VSAM data by using CICS function shipping to the FOR. Temporary storage (TS) requests are fulfilled by using local, unrecoverable, auxiliary temporary storage.

All connections use the multi-region operation and cross-memory (MRO/XM) protocol. CICSPlex System Manager is not used to provide dynamic workload routing in this scenario. Figure 3-1 shows the topology of DSW in a static routing configuration.

By using the same business logic and file structure as the static routing variant of the DSW, the application is extended to include the use of VSAM record-level sharing (RLS) and CICSPlex System Manager (CICSPlex SM) dynamic transaction routing. The use of CICSPlex SM introduces the requirement for the following two CICS regions:

The CMAS region is the component of the CICSPlex SM topology that is responsible for most of the work that is involved in managing and reporting on CICS regions and their resources. Each CICSplex must have at least one CMAS.

The WUI server is a CICS region that acts as a CICSPlex SM application, which uses the API to view and manage objects in the data repositories of CICSPlex SM address spaces.

To remove application affinities and enable dynamic workload distribution, temporary storage requests are fulfilled by using shared temporary storage, which is held in the coupling facility (CF).

As with the static routing configuration, all connections between CICS regions use the MRO/XM protocol.

Transactions enter the system through TORs by using the BMS maps interface, and are then transaction-routed to an AOR. Although the static routing variant that is described in 3.2.1, “DSW static routing” on page 20 is connected to a single AOR only, all TORs are connected to all AORs in this scenario. A CICSPlex SM workload is defined and installed to route transactions dynamically from the routing regions (the TORs) into the target regions (the AORs). File commands from the business logic use the VSAM RLS support in CICS TS to access the required data.

Typically, a dynamic routing configuration uses four TORs and 30 AORs, although not all regions are highlighted in topology diagrams. Figure 3-2 shows the topology of the DSW workload when it is configured to use dynamic routing with CICSPlex System Manager.

The topology of this workload is the same as described in 3.2.2, “DSW dynamic routing” on page 21. The only difference between these variants is that IP interconnectivity (IPIC) is used to facilitate communication between CICS regions, rather than the MRO/XM protocol.

As described in 2.2, “Workload design” on page 12, workloads are designed to minimize any unnecessary overhead or variations in runtime performance. The DSW IPIC workload uses the TCP/IP home address (127.0.0.1) to avoid testing physical networking hardware.

The Relational Transactional Workload (RTW) is a COBOL application that accesses a DB2 database. Transactions use BMS maps to interface with 3270 terminals.

Seven transaction types access 16 DB2 tables by using EXEC SQL commands. In total, slightly more than 30 million rows of data are defined in the database. On average, each CICS task issues 200 DB2 SQL calls. These SQL requests are distributed in the following percentages:

The two main variants of the RTW workload are non-threadsafe and threadsafe.

The non-threadsafe variant of RTW includes all PROGRAM resources defined with the CONCURRENCY attribute set to the value of QUASIRENT.

The threadsafe variant specifies the value of REQUIRED. For more information about the effects of this variation, see Chapter 4, “Open transaction environment” on page 27.

Typically, the RTW workload is executed as a stand-alone CICS region, but some test scenarios require a many transactions. To achieve high transaction rates, a variant of the RTW workload is available and uses TORs and AORs in a similar manner that was described for DSW in 3.2.2, “DSW dynamic routing” on page 21. Figure 3-3 shows the topology of the RTW workload in a high-volume configuration.

The workload that is presented in this section is a pure Java application, based on the CICS-supplied JDBC sample application. For more information about the sample JDBC servlet application, see the “Getting started with the servlet examples” topic in the IBM Knowledge Center, which is available at this website:

The sample application is composed of a Java servlet, which accesses an SQL database by using the Java JDBC API. The values that are retrieved from the database are then rendered as an HTML page and sent to the client as the response. For this workload, the sample application was expanded to also access a VSAM file by using the JCICS interface. The VSAM file contains a copy of the data that is held in the sample database.

The supplied sample application uses the CICSDB2DynamicSQLExample.getData(String) method to read 42 rows from the sample DB2 table EMP. This method was modified to also read 42 records from a VSAM file by using JCICS KeyedFileBrowse.next() calls and display the data as extra entries in the HTML table that is returned to the client.

The application is deployed into an IBM WebSphere Application Server Liberty environment inside a CICS JVM server. Simulated browser requests are made to the HTTP port that is specified in the server.xml configuration file. Figure 3-4 shows an overview of the application topology.

The Liberty server configuration file server.xml was automatically generated by specifying the following options in the JVM profile file for the JVM server:

The following entry was also added to the JVM profile configuration file to optimize retrieval of static resources from the web application:

By using IBM Workload Simulator for z/OS, 200 HTTP clients were simulated to provide a controlled rate of transactions in the CICS region under test. The workload measured overall central processor usage and zIIP usage of the address space.