CICS TS for z/OS V5.4
IBM CICS Transaction Server for z/OS (CICS TS) V5.4 release introduces various technical and operational capabilities. Included in these updates are improvements that provide performance benefits over previous CICS releases. Included in the CICS V5.4 performance report are the following subject areas:
•Key performance benchmarks that are presented as a comparison with the CICS TS V5.3 release.
•An outline of improvements made regarding the threadsafe characteristics of the CICS TS run time.
•Details of the changes that are made to performance-critical CICS initialization parameters, and the effect of these updates.
•A description of all the updated statistics and monitoring fields.
•A description of the performance class monitoring field contents for various types of WebSphere Liberty requests.
•High-level views of new functionality that was introduced in the CICS TS V5.4 release, including performance benchmark results where appropriate.
This chapter includes the following topics:
8.1 Introduction
When compiling the results for this chapter, the workloads were executed on an IBM z13 model NE1 (machine type 2964). A maximum of 32 dedicated CPs were available on the measured LPAR, with a maximum of six dedicated CPs available to the LPAR used to simulate users. These LPARs are configured as part of a parallel sysplex. An internal coupling facility was co-located on the same central processor complex (CPC) as the measurement and driving LPARs, connected using internal coupling peer (ICP) links. An IBM System Storage DS8870 (machine type 2424) was used to provide external storage.
This chapter presents the results of several performance benchmarks when executed in a CICS TS for z/OS V5.4 environment. Unless otherwise stated in the results, the CICS V5.4 environment was the code available at GA time. Several of the performance benchmarks are presented in the context of a comparison against CICS TS V5.3. The CICS TS V5.3 environment contained all PTFs issued before 24th February 2017. All LPARs used z/OS V2.2.
For a definition of performance terms used in this chapter, see Chapter 1, “Performance terminology” on page 3. A description of the test methodology used can be found in Chapter 2, “Test methodology” on page 11. For a full description of the workloads used, see Chapter 3, “Workload descriptions” on page 21.
Where reference is made to an LSPR processor equivalent, the indicated machine type and model can be found in the large systems performance reference (LSPR) document. For more information about obtaining and using LSPR data, see 1.3, “Large Systems Performance Reference” on page 6.
8.2 Release-to-release comparisons
This section describes some of the results from a selection of regression workloads that are used to benchmark development releases of CICS TS. For more information about the use of regression workloads, see Chapter 3, “Workload descriptions” on page 21.
8.2.1 Data Systems Workload static routing
The static routing variant of the Data Systems Workload (DSW) is described in 3.2.1, “DSW static routing” on page 22. This section presents the performance figures that were obtained by running this workload. Table 8-1 lists the results of the DSW static routing workload that used the CICS TS V5.3 release.
Table 8-1 CICS TS V5.3 results for DSW static routing workload
|
ETR
|
CICS CPU
|
CPU per transaction (ms)
|
|
1244.31
|
77.52%
|
0.623
|
|
1428.17
|
88.74%
|
0.621
|
|
1587.05
|
98.00%
|
0.617
|
|
1789.21
|
110.18%
|
0.616
|
|
2043.24
|
129.54%
|
0.634
|
Table 8-2 lists the same figures for the CICS TS V5.4 release.
Table 8-2 CICS TS V5.4 results for DSW static routing workload
|
ETR
|
CICS CPU
|
CPU per transaction (ms)
|
|
1240.69
|
76.90%
|
0.620
|
|
1425.05
|
87.84%
|
0.616
|
|
1582.76
|
96.98%
|
0.613
|
|
1784.61
|
108.81%
|
0.610
|
|
2038.77
|
128.18%
|
0.629
|
The average CPU per transaction value for CICS TS V5.3 is calculated to be 0.622 ms. The same value for CICS TS V5.4 is calculated to be 0.617 ms. The performance of this workload is within 1% and, therefore, considered to be equivalent for the two releases.
Figure 8-1 Plot of CICS TS V5.3 and V5.4 performance figures for DSW static routing workload
The measured CPU cost for each transaction rate is similar for CICS TS V5.3 and V5.4, which is demonstrated by the two plot lines being almost identical.
8.2.2 Data Systems Workload dynamic routing
The dynamic routing variant of the Data Systems Workload (DSW) is described in 3.2.2, “DSW dynamic routing” on page 23. This section presents the performance figures that were obtained by running this workload.
Table 8-3 lists the performance results of the DSW dynamic routing workload that used the CICS TS V5.3 release.
Table 8-3 CICS TS V5.3 results for DSW dynamic routing workload
|
ETR
|
CICS CPU
|
CPU per transaction (ms)
|
|
6139.73
|
253.15%
|
0.412
|
|
8974.81
|
365.76%
|
0.408
|
|
12099.66
|
483.50%
|
0.400
|
|
16444.72
|
661.87%
|
0.402
|
|
21386.62
|
871.39%
|
0.407
|
Table 8-4 lists the results of the DSW dynamic routing workload that used the CICS TS V5.4 release.
Table 8-4 CICS TS V5.4 results for DSW dynamic routing workload
|
ETR
|
CICS CPU
|
CPU per transaction (ms)
|
|
6140.75
|
252.93%
|
0.412
|
|
8968.03
|
366.44%
|
0.409
|
|
12119.32
|
491.94%
|
0.406
|
|
16433.46
|
667.78%
|
0.406
|
|
21282.97
|
871.85%
|
0.410
|
The average CPU per transaction value for CICS TS V5.3 is calculated to be 0.406 ms. The same value for CICS TS V5.4 is calculated to be 0.408 ms. The difference between the two values is less than 1% and within experimental error; therefore, the performance of this workload is considered to be equivalent for the two releases.
Figure 8-2 Plot of CICS TS V5.3 and V5.4 performance figures for DSW dynamic routing workload
The measured CPU cost for each transaction rate is similar for CICS TS V5.3 and V5.4, which is demonstrated graphically by the two plot lines being almost identical. A final observation is that the total CPU consumed by the CICS regions scales linearly in accordance with the transaction rate.
8.2.3 The Data Systems Workload HTTP interface
The HTTP interface variant of the Data Systems Workload (DSW) uses the same application logic and topology as the DSW static routing workload as described in 3.2.1, “DSW static routing” on page 22. The HTTP interface variant uses HTTP flows to drive the workload in a manner similar to the 3270 terminals used in the static routing workload. This section presents the performance figures that were obtained by running this HTTP workload.
Table 8-5 lists the results of the DSW HTTP interface workload that used the CICS TS V5.3 release.
Table 8-5 CICS TS V5.3 results for DSW HTTP interface workload
|
ETR
|
CICS CPU
|
CPU per transaction (ms)
|
|
1181.82
|
143.19%
|
1.212
|
|
1358.17
|
163.20%
|
1.202
|
|
1508.77
|
180.73%
|
1.198
|
|
1694.42
|
203.45%
|
1.201
|
|
1933.20
|
241.80%
|
1.251
|
Table 8-6 lists the same figures for the CICS TS V5.4 release.
Table 8-6 CICS TS V5.4 results for DSW HTTP interface workload
|
ETR
|
CICS CPU
|
CPU per transaction (ms)
|
|
1180.34
|
141.33%
|
1.197
|
|
1356.36
|
161.88%
|
1.193
|
|
1506.96
|
179.39%
|
1.190
|
|
1692.79
|
199.82%
|
1.180
|
|
1931.97
|
236.78%
|
1.226
|
The average CPU per transaction value for CICS TS V5.3 is calculated to be 1.213 ms. The same value for CICS TS V5.4 is calculated to be 1.197 ms. The difference in performance is within measurable limits and, therefore, is considered to be equivalent for the two releases.
Figure 8-3 Plot of CICS TS V5.3 and V5.4 performance figures for DSW HTTP interface workload
The measured CPU cost for each transaction rate is similar for CICS TS V5.3 and V5.4, which is demonstrated by the two plot lines being almost identical.
8.2.4 The Relational Transactional Workload threadsafe
The Relational Transactional Workload (RTW) is described in 3.3, “Relational Transactional Workload” on page 25. This section presents the performance figures that were obtained by running this workload.
Table 8-7 lists the performance results for the RTW threadsafe workload that used the CICS TS V5.3 release.
Table 8-7 CICS TS V5.3 results for the RTW threadsafe workload
|
ETR
|
CICS CPU
|
CPU per transaction (ms)
|
|
333.44
|
44.11%
|
1.323
|
|
499.59
|
66.11%
|
1.323
|
|
713.15
|
94.10%
|
1.319
|
|
996.18
|
131.52%
|
1.320
|
|
1241.70
|
163.99%
|
1.321
|
Table 8-8 lists the performance results for the RTW threadsafe workload that used the CICS TS V5.4 release.
Table 8-8 CICS TS V5.4 results for the RTW threadsafe workload
|
ETR
|
CICS CPU
|
CPU per transaction (ms)
|
|
333.47
|
44.47%
|
1.334
|
|
499.70
|
66.52%
|
1.331
|
|
713.23
|
94.15%
|
1.320
|
|
996.34
|
131.97%
|
1.325
|
|
1241.71
|
165.19%
|
1.330
|
The average CPU per transaction figure for CICS TS V5.3 is calculated to be 1.321 ms. The CICS TS V5.4 figure is calculated to be 1.328 ms. The difference between these two figures is 0.5%, which is within our measurement accuracy of ±1%; therefore, the performance of the two releases is considered to be equivalent.
These figures are shown in Figure 8-4 on page 156.
Figure 8-4 Plot of CICS TS V5.3 and V5.4 performance figures for RTW threadsafe workload
As shown in Figure 8-4, the lines are straight, which indicates linear scaling as transaction throughput increases. The lines also are overlaid, which indicates equivalent performance when the releases are compared.
8.2.5 The Java servlet that uses JDBC and VSAM
The Java servlet application is hosted in a CICS JVM server that uses the embedded WebSphere Liberty server. The workload is driven through HTTP requests by using IBM Workload Simulator for z/OS, as described in 2.4, “Driving the workload” on page 16. The servlet application accesses VSAM data by using the JCICS API and accesses DB2 by using the JDBC API. For more information about the workload, see 3.4, “WebSphere Liberty servlet with JDBC and JCICS access” on page 26.
The hardware used for the benchmarks is described in 8.1, “Introduction” on page 150. The measurement LPAR was configured with three GCPs and one zIIP, which resulted in an LSPR equivalent processor of 2964-704.
The CICS TS V5.3 and V5.4 releases were compared by using the software levels as described in 8.1, “Introduction” on page 150. Both configurations used a single CICS region and the following additional software levels and configuration options:
•DB2 V12
•Java 8 SR3 (64-bit)
•Single JVMSERVER resource with THREADLIMIT=256
Both JVM servers used the following JVM options:
•-Xgcpolicy:gencon
•-Xcompressedrefs
•-XXnosuballoc32bitmem
•-Xmx200M
•-Xms200M
•-Xmnx60M
•-Xmns60M
•-Xmox140M
•-Xmos140M
As described in 2.3.1, “Repeatability for Java workloads” on page 14, this workload requires a warm-up period of 20 minutes. After this warm-up phase completed, the request injection rate was increased every 10 minutes. CPU usage data was collected using IBM z/OS Resource Measurement Facility (RMF). An average CPU per request value was calculated using the last 5 minutes of each 10-minute interval.
Table 8-9 lists the performance results of the Java servlet workload that used the CICS TS V5.3 release, with the following columns:
•ETR
The average External Throughput Rate (ETR) during the measurement interval. For more details, see 1.3.1, “External throughput rate” on page 7.
•CICS CPU not zIIP-eligible
The fraction of a single CPU consumed by the whole address space during the measurement interval that was not eligible for execution on a zIIP engine. Extracted from the CP field in an RMF “Workload Activity” report for a report class.
•CICS CPU zIIP-eligible
The fraction of a single CPU consumed by the whole address space that was eligible for execution on a zIIP engine. Calculated as the sum of the IIP and IIPCP fields in an RMF “Workload Activity” report for a report class.
•CICS CPU total
The fraction of a single CPU consumed by the whole address space during the measurement interval. Calculated as the sum of the CP and IIP fields in an RMF “Workload Activity” report for a report class. This value is equal to the sum of the CICS CPU not zIIP-eligible and CICS CPU zIIP-eligible columns.
Table 8-9 CICS TS V5.3 results for WebSphere Liberty JDBC and VSAM workload
|
ETR
|
CICS CPU
not zIIP-eligible |
CICS CPU
zIIP-eligible |
CICS CPU
total |
|
837.32
|
27.45%
|
52.26%
|
79.71%
|
|
1637.60
|
53.71%
|
83.67%
|
137.38%
|
|
2289.29
|
80.11%
|
93.30%
|
173.41%
|
Table 8-10 lists the performance results of the Java servlet workload that used the CICS TS V5.4 release in the same format as Table 8-9.
Table 8-10 CICS TS V5.4 results for WebSphere Liberty JDBC and VSAM workload
|
ETR
|
CICS CPU
not zIIP-eligible |
CICS CPU
zIIP-eligible |
CICS CPU
total |
|
837.28
|
25.13%
|
49.53%
|
74.65%
|
|
1646.47
|
53.57%
|
85.10%
|
138.67%
|
|
2288.08
|
79.89%
|
95.61%
|
175.49%
|
The CICS CPU total values from Table 8-9 on page 157 and Table 8-10 on page 157 are plotted in Figure 8-5.
Figure 8-5 Total CPU comparison for CICS TS V5.3 and CICS TS V5.4 JDBC and VSAM workload
The offload eligibility figures are presented as a chart in Figure 8-6.
Figure 8-6 Comparing offload-eligible CPU utilization for servlet workload with CICS TS V5.3 and V5.4
The average CPU per transaction value for the JDBC and VSAM workload using the CICS TS V5.3 release is calculated to be 0.849 ms. The same value for the CICS TS V5.4 configuration is calculated to be 0.834 ms.
Table 8-9 on page 157 and Table 8-10 on page 157 present CICS CPU zIIP-eligible and CICS CPU total data, both as utilization fractions of a single CPU. From these figures, an overall zIIP eligibility figure for the workload is calculated, which is defined as the fraction of the total CPU consumed that was eligible to execute on a zIIP engine.
This value expressed mathematically is as follows:
The CICS TS V5.3 workload had an average zIIP eligibility value of 60.1%, and the CICS TS V5.4 configuration average value was 60.7%.
The average CPU per transaction and the zIIP eligibility calculations show that the CICS TS V5.4 release demonstrates similar performance to the CICS TS V5.3 release for this workload. This calculation is true for both the total CPU consumed and the fraction, which is eligible for offload to a zIIP engine.
|
Note: A performance improvement for WebSphere Liberty workloads was delivered by APAR PI54263 in CICS TS V5.3. A summary of this improvement is described in 7.15, “WebSphere Liberty zIIP eligibility” on page 143.
This performance improvement included in CICS TS V5.4. APAR PI54263 is also included in the CICS TS V5.3 configuration that was used as baseline measurements for this section. Therefore, no performance improvements are observed in this section because both releases include the zIIP eligibility improvements introduced by APAR PI54263.
|
8.2.6 The Java OSGi workload
The Java OSGi workload is composed of several applications, as described in 3.5, “Java OSGi workload” on page 27.
The hardware used for the benchmarks is described in 8.1, “Introduction” on page 150. The measurement LPAR was configured with three GCPs and one zIIP, which resulted in an LSPR equivalent processor of 2964-704.
The CICS TS V5.3 and V5.4 releases were compared by using the software levels as described in 8.1, “Introduction” on page 150. Both configurations used a single CICS region and the following additional software levels and configuration options:
•DB2 V12
•Java 8 SR4 (64-bit)
•Single JVMSERVER resource with THREADLIMIT=25
Both JVM servers used the following JVM options:
•-Xgcpolicy:gencon
•-Xcompressedrefs
•-XXnosuballoc32bitmem
•-Xmx100M
•-Xms100M
•-Xmnx70M
•-Xmns70M
•-Xmox30M
•-Xmos30M
As described in 2.3.1, “Repeatability for Java workloads” on page 14, this workload requires a warm-up period of 20 minutes. After this warm-up phase completed, the request injection rate was increased every 5 minutes. CPU usage data was collected using IBM z/OS Resource Measurement Facility (RMF). An average CPU per request value was calculated using the last minute of each 5-minute interval.
Table 8-11 lists the performance results of the Java OSGi workload that used the CICS TS V5.3 release.
Table 8-11 CICS TS V5.3 performance results for OSGi workload
|
ETR
|
CICS CPU
not zIIP-eligible |
CICS CPU
zIIP-eligible |
CICS CPU
total |
|
233.98
|
22.27%
|
74.51%
|
96.78%
|
|
467.93
|
43.26%
|
148.27%
|
191.53%
|
|
780.13
|
78.72%
|
249.64%
|
328.36%
|
The performance results for the CICS TS V5.4 release are shown in Table 8-12.
Table 8-12 CICS TS V5.4 performance results for OSGi workload
|
ETR
|
CICS CPU
not zIIP-eligible |
CICS CPU
zIIP-eligible |
CICS CPU
total |
|
233.98
|
22.68%
|
72.18%
|
94.86%
|
|
467.97
|
44.32%
|
144.65%
|
188.97%
|
|
779.38
|
81.19%
|
242.10%
|
323.29%
|
Figure 8-7 Comparing overall CPU utilization for Java OSGi workload with CICS TS V5.3 and V5.4
The offload eligibility figures are presented as a chart in Figure 8-8.
Figure 8-8 Comparing offload-eligible CPU utilization for OSGi workload with CICS TS V5.3 and V5.4
The average CPU per transaction value for this workload using the CICS TS V5.3 release is calculated to be 4.146 ms. The same value for the CICS TS V5.4 release is calculated to be 4.080 ms.
Using the methodology to calculate the zIIP eligibility of the workload described in 8.2.5, “The Java servlet that uses JDBC and VSAM” on page 156, the CICS TS V5.3 release had an average zIIP eligibility of 76.8%. The CICS TS V5.4 release had an average zIIP eligibility of 75.8%.
As observed with the Java servlet workload, the performance of Java OSGi applications is similar in CICS TS V5.4 when compared to CICS TS V5.3, both in terms of total CPU consumed and the fraction that is eligible for offload to a zIIP engine.
8.3 Improvements in threadsafety
All new CICS application programming interface (API) commands in CICS V5.4 are threadsafe. Also, an improvement for Java workloads running in an OSGi JVM server when accessing IBM MQ is implement.
8.3.1 Threadsafe API commands
The following new CICS API commands are threadsafe:
•FETCH ANY
•FETCH CHILD
•FREE CHILD
•RUN TRANSID
•TRANSFORM DATATOJSON
•TRANSFORM JSONTODATA
For more information about CICS API commands, see the “CICS command summary” topic in IBM Knowledge Center at this website:
8.3.2 Use of T8 TCB for MQ calls from Java
Java applications running in an OSGi JVM server no longer requires a task control block (TCB) to change mode operation when accessing IBM MQ, using either the MQ classes for Java or the MQ classes for JMS. In a CICS JVM server, Java applications run on T8 TCBs. In CICS TS V5.3, MQ calls from a Java environment required a switch to an L8 TCB. In CICS TS V5.4, this switch is removed.
The change in TCB switch behavior affects the results you see in CICS monitoring and statistics. TCB use for Java MQ applications is changed so that MQ CPU time is now accumulated against a T8 TCB. End-of-task sync point processing is still accumulated on an L8 TCB.
In releases prior to CICS TS V5.4, Java applications running in a WebSphere Liberty JVM server do not use the CICS MQCONN resource and, therefore, do not require TCB change mode operation, using either the MQ classes for Java or the MQ classes for JMS.
8.4 Changes to system initialization parameters
Several performance-related CICS system initialization table (SIT) parameters are changed in the CICS TS V5.4 release. This section outlines changes to the SIT parameters that have the most impact on CICS performance. All comparisons to previous limits or default values refer to CICS TS V5.3.
For a detailed view of changes to SIT parameters in the CICS TS V5.4 release, see the “Changes to SIT parameters” section of the “Changes to externals in this release” topic in IBM Knowledge Center at this website:
8.4.1 The EDSA limit (EDSALIM) parameter
The minimum value for the EDSALIM parameter is increased from 48 MB to 64 MB. The value that is specified for the EDSALIM parameter can be a maximum of 2047 MB, specified in multiples of 1 MB.
For more information, see the “EDSALIM” topic in IBM Knowledge Center at this website:
8.4.2 Default runaway task time (ICVR)
The minimum value for the ICVR value is reduced from 500 ms to 250 ms. The default value is reduced from 5000 ms to 2000 ms. The value that is specified for the ICVR parameter can be a maximum of 2,700,000 ms in multiples of 250 ms.
For more information, see the “ICVR” topic in IBM Knowledge Center at this website:
8.4.3 Maximum open TCBs (MAXOPENTCBS)
The minimum value for the MAXOPENTCBS parameter is increased from 1 to 32.
If the MAXOPENTCBS parameter is not specified, CICS sets the parameter automatically, based on the current value of the MXT system initialization parameter. The value of the MAXOPENTCBS parameter is calculated by using the same algorithm implemented in CICS TS V5.1, as shown in the following example:
MAXOPENTCBS = (2 x MXT) + 32
For more information about the MAXOPENTCBS parameter, see the “MAXOPENTCBS” topic in IBM Knowledge Center at this website:
8.4.4 Maximum SSL TCBs (MAXSSLTCBS)
The default value for the MAXSSLTCBS parameter is increased from 8 to 32.
For more information about the MAXSSLTCBS parameter, see the “MAXSSLTCBS” topic in IBM Knowledge Center at this website:
8.4.5 RACF synchronization (RACFSYNC)
The RACFSYNC system initialization parameter specifies whether CICS listens for type 71 Event Notification Facility (ENF) events.
RACF sends a type 71 ENF signal to listeners when a CONNECT, REMOVE, or REVOKE command changes a user’s resource authorization. If RACFSYNC=YES is specified in a CICS TS V5.4 environment, when CICS receives a type 71 ENF event for a user ID, all cached user tokens for the user ID are invalidated, irrespective of the setting of the USRDELAY parameter.
Subsequent requests from that user ID force a full RACF RACROUTE VERIFY request, which results in a refresh of the user’s authorization level. User tokens for tasks that are currently running are not affected. In addition to the RACF RACROUTE VERIFY processing, a type 71 ENF signal will also make DB2 threads for the associated user ID issue a full sign on when they are next reused.
|
Note: In the configuration where type 71 signals are issued for large numbers of users simultaneously, combined with large numbers of connections to DB2, the temporary performance overhead can be significant while the full sign on processing across all affected DB2 threads is completed.
To reduce the impact of type 71 ENF processing, make updates to large numbers of RACF users during off-peak periods.
|
For more information about the RACFSYNC parameter, see the “RACFSYNC” topic in IBM Knowledge Center at this website:
8.4.6 Sign on for a preset user ID (SNPRESET)
The new SNPRESET parameter is provided to allow the sharing of access control environment element (ACEE) control blocks. This process can save 31-bit storage and CPU. The SNPRESET parameter takes one of the following values:
•UNIQUE
When signing on a preset user ID terminal, the ACEE is built with entry port information. Every preset terminal has a unique ACEE that is associated with the user ID and terminal. This is the default.
•SHARED
When signing on a preset user ID terminal, the ACEE is built without entry port information. All preset terminals with the same user ID use the same ACEE.
If you audit data that is based on the terminal of a preset user ID, use SNPRESET=UNIQUE.
If you do not need information that is based on the terminal of a preset user ID, you can save storage by selecting SNPRESET=SHARED.
|
Note: In the event of a security violation with SNPRESET=SHARED, the netname of the terminal will not show in the DFHXS1111 message.
|
For more information about the SNPRESET parameter, see the “SNPRESET” topic in IBM Knowledge Center at this website:
8.4.7 z/OS Workload Manager Health API (WLMHEALTH)
CICS TS V5.4 introduces the new SIT parameter WLMHEALTH. For more details about the use of the z/OS Workload Manager Health API in CICS, see 8.8, “z/OS WLM Health API” on page 173.
For more information about the WLMHEALTH parameter, see the “WLMHEALTH” topic in IBM Knowledge Center at this website:
8.5 Changes to resource definition attribute default values
Several performance-related CICS resource definition attributes are changed in the CICS TS V5.4 release. This section outlines changes to the default attribute values that have the most impact on CICS performance. All comparisons to previous limits or default values refer to CICS TS V5.3.
For a detailed view of changes to SIT parameters in the CICS TS V5.4 release, see the “Changes to resource definitions” section of the “Changes to externals in this release” topic in IBM Knowledge Center at this website:
8.5.1 The PROGRAM resource
The default value for the DATALOCATION attribute changed from BELOW to ANY. Commands that use the SET option can return a data address to an application program; this operand specifies the location of the data. For example, in the EXEC CICS RECEIVE SET(ptr-ref) command, ptr-ref is in 24-bit virtual storage if DATALOCATION(BELOW) is specified but might be in 31-bit virtual storage if DATALOCATION(ANY) is specified. DATALOCATION does not affect the operation of the GETMAIN command.
For more information about the DATALOCATION attribute, see the “PROGRAM attributes” topic in IBM Knowledge Center at this website:
8.5.2 The TRANSACTION resource
The minimum value that can be specified for the RUNAWAY attribute is reduced from 500 ms to 250 ms. The value that is specified for the RUNAWAY attribute can be a maximum of 2,700,000 ms in multiples of 250 ms.
The default value for the TASKDATALOC attribute has changed from BELOW to ANY. A value of ANY indicates storage acquired by CICS for the duration of the transaction can be located in 31-bit virtual storage. These areas, which relate to specific CICS tasks, include the EXEC interface block (EIB) and the transaction work area (TWA).
The default value for the SPURGE attribute has changed from NO to YES. A value of YES indicates a transaction is initially system purgeable.
The default value for the TPURGE attribute has changed from NO to YES. A value of YES indicates, for non-z/OS Communications Server terminals only, that the transaction can be purged because of a terminal error.
For more information about the RUNAWAY, TASKDATALOC, SPURGE, and TPURGE attributes, see the “TRANSACTION attributes” topic in IBM Knowledge Center at this website:
8.6 Enhanced instrumentation
The CICS TS V5.4 release enhances the information reported by the CICS monitoring and statistics components. This section describes the extra and changed fields that are now available in the CICS monitoring and statistics SMF records.
For more information about changes in monitoring fields across a range of CICS releases, see the “Changes to CICS monitoring” topic in IBM Knowledge Center at this website:
For more information about changes in statistics fields across a range of CICS releases, see the “Changes to CICS statistics” topic in IBM Knowledge Center at this website:
8.6.1 The DFHCICS performance group
The following fields were added to the DFHCICS performance group to provide support for policy system rules:
•Policy system rules evaluation count (field MPSRECT)
The number of times that policy system rules have been evaluated for the task.
•Policy system rules trigger count (field MPSRACT)
The number of times that policy system rules that have evaluated to true and have triggered either a message or an event.
For more information about policy system rules, see the topic “Policy system rules” in IBM Knowledge Center at this website:
Several fields have been added to provide enhanced transaction tracking information when using the asynchronous services (AS) domain:
•PTSTART
•PTTRANNO
•PTTRAN
•PTCOUNT
For more information about monitoring enhancements for the AS domain, see 8.9, “Asynchronous API” on page 173.
|
Note: The previous transaction information is also available for any tasks that do not create a new point of origin.
|
For more information about counters that are available in the DFHCICS performance group, see the topic “Performance data in group DFHCICS” in IBM Knowledge Center at this website:
8.6.2 The DFHPROG performance group
The ABCODEO and ABCODEC monitoring fields can now contain the following abend codes:
•ASPF
•ASPN
•ASPO
•ASPP
•ASPQ
•ASPR
•ASP1
•ASP2
•ASP3
•ASP7
•ASP8
|
Note: Due to the circumstances under which transactions are called, a transaction dump might not be taken when these abends occur.
|
For more information about data fields that are available in the DFHPROG performance group, see the “Performance data in group DFHPROG” topic in IBM Knowledge Center at this website:
8.6.3 The DFHTASK performance group
The following field was added to the DFHTASK performance group to aid system identification:
•Logical partition name (field LPARNAME)
The name, in EBCDIC, of the logical partition (LPAR) on the processor where the CICS region is running.
The following fields are added to the DFHTASK performance group to support the asynchronous services (AS) domain:
•ASTOTCT
•ASRUNCT
•ASFTCHCT
•ASFREECT
•ASFTCHWT
•ASRNATWT
For more information about monitoring enhancements for the AS domain, see 8.9, “Asynchronous API” on page 173.
For more information about data fields that are available in the DFHTASK performance group, see the “Performance data in group DFHTASK” topic in IBM Knowledge Center at this website:
8.6.4 Transaction resource class data
The following fields are added to the transaction resource class data to support the AS domain:
•MNR_PTD_ATTACH_TIME
•MNR_PTD_TRANNUM
•MNR_PTD_TRANID
•MNR_PTD_COUNT
For more information about monitoring enhancements for the AS domain, see 8.9, “Asynchronous API”.
For more information about fields that are available in the transaction resource class data, see the “Transaction resource class data: Listing of data fields” topic in IBM Knowledge Center at this website:
8.6.5 Identity class data
The following fields are added to the identity class data to support the AS domain:
•MNI_PTD_ATTACH_TIME
•MNI_PTD_TRANNUM
•MNI_PTD_TRANID
•MNI_PTD_COUNT
For more information about monitoring enhancements for the AS domain, see 8.9, “Asynchronous API” on page 173.
For more information about fields that are available in the identity class data, see the “Identity class data: Listing of data fields” topic in IBM Knowledge Center at this website:
8.6.6 Asynchronous services global statistics
A new statistics report is added to support the AS domain. This report contains the following fields:
•ASG_RUN_COUNT
•ASG_FETCH_COUNT
•ASG_FREE_COUNT
•ASG_RUN_DELAY_COUNT
•ASG_PARENTS_DELAYED_CUR
•ASG_PARENTS_DELAYED_PEAK
•ASG_CHILDREN_CUR
•ASG_CHILDREN_PEAK
For more information about statistics enhancements for the AS domain, see 8.9, “Asynchronous API”.
8.6.7 IBM MQ monitor statistics
New statistics are provided in the CICS TS V5.4 for the MQMONITOR resource. The following fields are available in the new IBM MQ monitor resource statistics report:
•Monitor name (field MQR_NAME)
The name of an installed MQMONITOR definition in the CICS region.
•Monitor start date and time (field MQR_START_TIME_LOCAL)
The local date and time when the most recent instance of the MQ monitor was started.
•Monitor stop date and time (field MQR_STOP_TIME_LOCAL)
The local date and time when the most recent instance of the MQ monitor was stopped.
•Queue name (field MQR_QNAME)
The name of the MQ queue monitored by the MQ monitor.
•Monitor status (field MQR_MONSTATUS)
The status of the MQ monitor, which can be one of the following states:
– STARTED
– STARTING
– STOPPED
– STOPPING
•Monitor user ID (field MQR_MONUSERID)
The user ID used by the transaction monitoring the MQ queue.
•Task number (field MQR_TASKNUM)
Task number of the transaction monitoring the MQ queue.
•Transaction ID (field MQR_TRANID)
The ID of the CICS transaction used by the MQ monitor.
•User ID (field MQR_USERID)
The user ID to be used by the monitor transaction when issuing the start request for the application transaction if a suitable user ID is not available.
•Number of OPEN requests (field MQR_TOPEN)
The number of MQOPEN calls issued.
•Number of CLOSE requests (field MQR_TCLOSE)
The number of MQCLOSE calls issued.
•Number of GET requests (field MQR_TGET)
The number of MQGET calls issued.
•Number of GET with wait requests (field MQR_TGETWAIT)
The number of MQGET calls issued with the MQGMO_WAIT option.
•Number of PUT requests (field MQR_TPUT)
The number of MQPUT calls issued.
•Number of PUT1 requests (field MQR_TPUT1)
The number of MQPUT1 calls issued.
•Number of INQ requests (field MQR_TINQ)
The number of MQINQ calls issued.
•Number of INQL requests (field MQR_TINQL)
The number of MQINQL calls issued.
•Number of SET requests (field MQR_TSET)
The number of MQSET calls issued.
•Number of committed units of work (field MQR_TCOMMUOW)
The number of UOWs that were in doubt at adapter startup that are now resolved by committing.
•Number of backed-out units of work (field MQR_TBACKUOW)
The number of UOWs that were in doubt at adapter startup that are now resolved by backing out.
•Number of other requests (field MQR_TOTHER)
The number of other calls.
•Monitor GMT start date and time (field MQR_START_TIME_GMT)
The Greenwich mean time (GMT) when the most recent instance of the MQ monitor was started.
•Monitor GMT stop date and time (field MQR_STOP_TIME_GMT)
The Greenwich mean time (GMT) when the most recent instance of the MQ monitor was stopped.
For more information about IBM MQ Monitor statistics, see the “IBM MQ Monitor statistics” topic in IBM Knowledge Center at this website:
8.6.8 TCP/IP global statistics
The following fields were added to the TCP/IP global statistics report:
•Current non-persistent inbound sockets (field SOG_CURR_NPERS_INB_SOCKETS)
The current number of non-persistent inbound sockets.
•Peak non-persistent inbound sockets (field SOG_PEAK_NPERS_INB_SOCKETS)
The peak number of non-persistent inbound sockets.
•Peak persistent inbound sockets (field SOG_PEAK_PERS_INB_SOCKETS)
The peak number persistent inbound sockets.
•Total non-persistent inbound sockets created (field SOG_NPERS_INB_SOCKETS_CREATED)
Total number of non-persistent inbound sockets created.
•Peak outbound sockets (field SOG_PEAK_BOTH_OUTB_SOCKETS)
Peak number of outbound sockets.
•Total outbound sockets reused (field SOG_TIMES_OUTB_REUSED)
Total number of times outbound sockets reused.
•Total persistent outbound sockets created (field SOG_PERS_OUTBOUND_CREATED)
Total number of persistent outbound sockets created.
Example 8-1 shows a sample DFHSTUP report that contains the new fields.
Example 8-1 Extract of sample TCP/IP global statistics report produced by CICS TS V5.4 DFHSTUP
Current number of inbound sockets . . . . . . . . . . . . . . . . : 109
Current number of non-persistent inbound sockets. . . . . . . . . : 0
Peak number of inbound sockets. . . . . . . . . . . . . . . . . . : 109
Peak number of non-persistent inbound sockets . . . . . . . . . . : 0
Peak number of persistent inbound sockets . . . . . . . . . . . . : 109
Total number of inbound sockets created . . . . . . . . . . . . . : 0
Total number of non-persistent inbound sockets created. . . . . . : 0
Current number of non-persistent outbound sockets . . . . . . . . : 500
Current number of persistent outbound sockets . . . . . . . . . . : 0
Peak number of outbound sockets . . . . . . . . . . . . . . . . . : 500
Peak number of non-persistent outbound sockets. . . . . . . . . . : 500
Peak number of persistent outbound sockets. . . . . . . . . . . . : 0
Total number of times outbound sockets reused . . . . . . . . . . : 301381
Total number of outbound sockets created. . . . . . . . . . . . . : 0
Total number of persistent outbound sockets created . . . . . . . : 0
Total number of outbound sockets closed . . . . . . . . . . . . . : 0
Total number of inbound and outbound sockets created. . . . . . . : 0
For more information about TCP/IP global statistics, see the “TCP/IP: Global statistics” topic in IBM Knowledge Center at this website:
8.6.9 TCP/IP services resource statistics
The following fields were added to the statistics for each installed TCP/IP service:
•Current Maximum Backlog (field SOR_CURR_MAX_BACKLOG)
The maximum number of connection requests that the TCP/IP service currently allows in its backlog queue, summed over all appropriate stacks if the TCP/IP service is listening on multiple stacks.
•TCPIPSERVICE Backlog Setting (field SOR_BACKLOG)
The initial backlog setting for the TCP/IP service. The setting controls the maximum number of connection requests that are allowed to queue in the backlog queue for the TCP/IP service before it starts to reject incoming connections. This is per stack if the TCP/IP service is listening on multiple stacks.
•Total connections (field SOR_TOTAL_CONNS)
The total number of connections made for the TCP/IP service.
•Requests processed (field SOR_REQUESTS)
The number of requests processed by the TCP/IP service.
•Made non-persistent at MAXPERSIST (field SOR_NONP_AT_MAXPERSIST)
The number of times a new persistent connection was made non-persistent because MAXPERSIST was reached.
•Disconnected after maximum uses (field SOR_DISC_AT_MAX_USES)
The number of times a persistent HTTP connection was disconnected because its number of uses had exceeded the limit.
•Made non-persistent at task limit (field SOR_NONP_AT_TASK_LIMIT)
The number of times a new persistent HTTP connection was made non-persistent because the number of tasks in the region has exceeded the limit.
•Disconnected at task limit (field SOR_DISC_AT_TASK_LIMIT)
The number of times an existing persistent HTTP connection was closed because the number of tasks in the region has exceeded the limit.
•Current backlog (field SOR_CURR_BACKLOG)
The current number of connection requests waiting in the backlog queue, summed over all appropriate stacks if the TCP/IP service is listening on multiple stacks.
•Connections dropped (field SOR_CONNS_DROPPED)
The total number of connections that were dropped because the backlog queue was full.
•Time connection last dropped (field SOR_CONN_LAST_DROPPED)
The time that a connection was last rejected because the backlog queue of the TCP/IP service was full.
For more information about TCP/IP resource statistics, see the “TCP/IP services: Resource statistics” topic in IBM Knowledge Center at this website:
8.6.10 z/OS Communications Server global statistics
CICS TS V5.4 introduces the BMS 3270 Intrusion Detection Service that allows CICS to detect if a 3270 emulator has invalidly modified a protected field generated by a BMS map. For more details about the functionality, see the “BMS 3270 Intrusion Detection Service” topic in IBM Knowledge Center at this website:
The following fields were added to the z/OS Communications Server collected statistics to report the status of BMS 3270 validation:
•BMS 3270 validation status (field A03BMVL)
Indicates whether the BMS 3270 validation User Replaceable Module (URM) is ON or OFF.
•Number of BMS 3270 validation failures abended (field A03BMAB)
Number of times the BMS 3270 validation URM has detected invalid 3270 data, issued a DFHTF0200 message to log the event, and terminated the transaction with an ABMX abend code.
•Number of BMS 3270 validation failures ignored (field A03BMIG)
Number of times the BMS 3270 validation URM has detected invalid 3270 data but ignored the detection in response.
•Number of BMS 3270 Validation Failures Logged (field A03BMLG)
Number of times the BMS 3270 validation URM has detected invalid 3270 data and issued a DFHTF0200 message to log the event.
For more information about z/OS Communication Server global statistics, see the “z/OS Communications Server: Global statistics” topic in IBM Knowledge Center at this website:
8.7 CICS tasks for WebSphere Liberty applications
For a WebSphere Liberty application to use the JCICS API and other CICS resources, such as a JDBC data source with type 2 connectivity, requests must run under a CICS task. The point at which this task is created is optimized, is dependent upon the type of request, as follows:
•HTTP requests
A CICS task is created before the WebSphere Liberty application is invoked
•Non-HTTP requests, such as message-driven beans (MDBs), inbound Java Connector Architecture (JCA) requests, or remote Enterprise Java Beans (EJBs)
A CICS task is created on first use of a CICS resource
As described in 2.6.1, “Collecting Java performance data” on page 19, CPU time spent on a TCB before the CICS task is created will not be captured in the CICS monitoring data. When analyzing CICS performance class monitoring data for non-HTTP tasks, it is important to be aware that all monitoring data (including CPU and response time) start only at the point in the application that first accessed a CICS resource.
For more information about the processing of CICS tasks for WebSphere Liberty workloads, see the “CICS tasks for Liberty applications” section of the “Java applications in a Liberty JVM server” topic in IBM Knowledge Center at this website:
8.8 z/OS WLM Health API
CICS TS V5.4 uses the z/OS Workload Manager (WLM) health API (IWM4HLTH) as a means of controlling the flow of work into a CICS region. This service is used to inform z/OS WLM about the state of health of a server, in this context a CICS region. The health indicator is a number that shows, in percentage terms, how well the server is performing. It can be an integer value between 0 and 100. A value of 100 means the server is fully capable to do work without any health problems, whereas a value of 0 means it is not able to do any work.
As described in 8.4.7, “z/OS Workload Manager Health API (WLMHEALTH)” on page 164, CICS TS V5.4 introduces the new SIT parameter WLMHEALTH. This SIT parameter controls how a CICS region reports health to z/OS WLM both during and just after the startup period.
For more information about how CICS TS V5.4 uses the z/OS WLM Health API to control the flow of work into a CICS region, see the following article in the CICS Developer Center:
|
Note: The improvements to CICSPlex SM workload routing introduced in CICS TS V5.5 was also made available in CICS TS V5.4 with APAR PI90147. See 9.7.1, “CICSPlex SM workload routing” on page 211 for more details.
|
8.9 Asynchronous API
The CICS TS V5.4 release introduces a set of CICS commands which can be used to develop applications that start one or more child tasks. These child tasks execute asynchronously to the parent task and the new commands provide the ability for the parent task to fetch responses from the child tasks. The following API commands now support this programming model:
•EXEC CICS RUN TRANSID
Initiates a local child transaction that runs asynchronously with the parent transaction.
•EXEC CICS FETCH CHILD
Used by a parent task to inquire on the status of a specific child task.
•EXEC CICS FETCH ANY
Used by a parent task to inquire on the status of any completed child task which has not yet been fetched.
•EXEC CICS FREE CHILD
Used by a parent task which no longer requires the response of a child task, freeing resources associated with that child when it completes.
All of the new API commands are threadsafe. For more information about using the new API commands, see the “Developing for asynchronous requests” topic in IBM Knowledge Center at this website:
For an in-depth look at the Asynchronous API, refer to IBM CICS Asynchronous API: Concurrent Processing Made Simple, SG24-8411.
8.9.1 Enhanced transaction tracking information
The transaction tracking information in the CICS monitoring facility records is enhanced to provide greater insight into the relationship between parent and child tasks. Existing origin and previous hop data is extended with the concept of previous transaction data.
When work first enters the CICSplex, for example in a web service request or an MQ message, details of its point of origin is placed into task context information called “origin data,” part of its task association data, for the first task that is created to process it. This data, the origin data, flows with the work as it moves around the CICSplex.
As work moves from one CICS region to another, either through a distributed program link (DPL) or through a function ship (FS) request, the previous hop data in the target region is updated to reference the CICS task in the previous CICS region.
Using the EXEC CICS RUN TRANSID command and some EXEC CICS START commands, child tasks are created which have the parent task in the previous transaction data. Previous transaction data is created for a task when a new point of origin is not created. A task that is a new point of origin will not contain previous transaction data.
Figure 8-9 demonstrates the relationship between origin data, previous hop data, and previous transaction data.
Figure 8-9 Relationship between origin data, previous hop data, and previous transaction data
Several fields have been added to the CICS monitoring fields to record the previous transaction information, and these are discussed in more depth in 8.9.3, “CICS monitoring enhancements” on page 176.
For more information about the previous transaction information, see the “Previous transaction data characteristics” topic in IBM Knowledge Center at this website:
8.9.2 Workload management
The asynchronous API can result in a large number of concurrent tasks within a CICS system. CICS will automatically begin workload management should a region reach the maximum tasks (MXT) limit, and you can regulate performance yourself using transaction classes.
By specifying a TRANCLASS for parent transactions, you can control the maximum number of parent tasks that will run in a system at any given time, and by extension the number of child tasks that will be created by those parents. Use the MAXACTIVE attribute of a TRANCLASS to ensure that the combined number of parent and child transactions is less than the MXT value for your system.
If using a TRANCLASS for child transactions, the MAXACTIVE value for your child tasks should be higher than the MAXACTIVE value for parent tasks, assuming that a given parent task will create multiple children.
|
Note: If using a TRANCLASS for child transactions, don’t use the same TRANCLASS for child transactions and parent transactions. Otherwise, you can end up with a system full of parent tasks and no space for child tasks to attach.
|
The workload initiated by EXEC CICS RUN TRANSID commands is managed automatically by CICS when a region is under stress. If there are too many child tasks in the system, the parent tasks which are issuing EXEC CICS RUN TRANSID commands is suspended and resumed as necessary, limiting the number of new child tasks being created.
For more information about how CICS regulates workflow with asynchronous API commands, see the “Managing performance with the asynchronous API” topic in IBM Knowledge Center at this website:
8.9.3 CICS monitoring enhancements
The CICS monitoring facility (CMF) data is enhanced to support the new commands that are provided by the asynchronous API.
The DFHCICS performance group
To provide the enhanced transaction tracking information described in 8.9.1, “Enhanced transaction tracking information” on page 174, the following fields are added to the DFHCICS performance group:
•Previous transaction start time (field PTSTART)
The start time of the immediately previous or parent task in the same CICS system with which the task is associated.
•Previous transaction number (field PTTRANNO)
The task number of the immediately previous or parent task in the same CICS system with which the task is associated.
•Previous transaction (field PTTRAN)
The transaction ID of the immediately previous or parent task in the same CICS system with which the task is associated.
•Previous transaction count (field PTCOUNT)
The number of times there has been a request from one task to initiate another task in the same CICS system with which this task is associated, such as by an EXEC CICS RUN TRANSID or EXEC CICS START command. This is effectively the task depth in the local region when using the EXEC CICS RUN TRANSID command, or the EXEC CICS START command when a new point of origin is not created.
The OTRANFLG field has a new transaction origin type for asynchronous transactions.
The DFHTASK performance group
The following fields are added to DFHTASK performance group to provide task-level information when using the asynchronous API commands.
•Total asynchronous API commands count (field ASTOTCT)
The total number of EXEC CICS asynchronous API commands that were issued by the user task.
•EXEC CICS RUN TRANSID command count (field ASRUNCT)
The number of EXEC CICS RUN TRANSID commands that were issued by the user task.
•EXEC CICS FETCH command count (field ASFTCHCT)
The number of EXEC CICS FETCH CHILD and EXEC CICS FETCH ANY commands that were issued by the user task.
•EXEC CICS FREE CHILD command count (field ASFREECT)
The number of EXEC CICS FREE CHILD commands that were issued by the user task.
•Asynchronous API fetch wait time (field ASFTCHWT)
The elapsed time for which the user task waited as the result of an EXEC CICS FETCH CHILD or EXEC CICS FETCH ANY command.
•Asynchronous API delay time (field ASRNATWT)
The elapsed time that the user task was delayed as a result of asynchronous child task limits managed by the asynchronous services domain.
The TRANFLAG field has a new transaction origin type for asynchronous API transactions.
Transaction resource class data
To provide the enhanced transaction tracking information described in 8.9.1, “Enhanced transaction tracking information” on page 174, the following fields are added to the transaction resource class data:
•Previous task attach time (field MNR_PTD_ATTACH_TIME)
The start time of the immediately previous or parent task in the same CICS system with which this task is associated.
•Task number of previous task (field MNR_PTD_TRANNUM)
The task number of the immediately previous or parent task in the same CICS system with which this task is associated.
•Transaction ID of previous task (field MNR_PTD_TRANID)
The transaction ID of the immediately previous or parent task in the same CICS system with which this task is associated.
•Previous transaction depth count (field MNR_PTD_COUNT)
The number of times there has been a request from one task to initiate another task in the same CICS system with which this task is associated, such as by an EXEC CICS RUN TRANSID or EXEC CICS START command when a new point of origin is not created.
Identity class data
To provide the enhanced transaction tracking information described in 8.9.1, “Enhanced transaction tracking information” on page 174, the following fields are added to the identity class data:
•Previous task attach time (field MNI_PTD_ATTACH_TIME)
The start time of the immediately previous or parent task in the same CICS system with which this task is associated.
•Task number of previous task (field MNI_PTD_TRANNUM)
The task number of the immediately previous or parent task in the same CICS system with which this task is associated.
•Transaction ID of previous task (field MNI_PTD_TRANID)
The transaction ID of the immediately previous or parent task in the same CICS system with which this task is associated.
•Previous transaction depth count (field MNI_PTD_COUNT)
The number of times there has been a request from one task to initiate another task in the same CICS system with which this task is associated, such as by an EXEC CICS RUN TRANSID or EXEC CICS START command when a new point of origin is not created.
8.9.4 CICS statistics enhancements
A new statistics report is added to provide information about how work is processed by the AS domain and the effect the AS workload management has on parent and child tasks.
The following fields are available in the new asynchronous services global statistics report:
•RUN command count (field ASG_RUN_COUNT)
The total number of EXEC CICS RUN TRANSID API commands issued.
•FETCH command count (field ASG_FETCH_COUNT)
The total number of EXEC CICS FETCH CHILD and EXEC CICS FETCH ANY API commands issued.
•FREE command count (field ASG_FREE_COUNT)
The total number of EXEC CICS FREE CHILD API commands issued.
•Times EXEC CICS RUN command being delayed (field ASG_RUN_DELAY_COUNT)
The total number of times that EXEC CICS RUN TRANSID API commands delayed by flow control.
•Current parents being delayed (field ASG_PARENTS_DELAYED_CUR)
The current number of tasks that are delayed by flow control when issuing an EXEC CICS RUN TRANSID API command.
•Peak parents being delayed (field ASG_PARENTS_DELAYED_PEAK)
The peak number of tasks that were delayed by flow control when issuing an EXEC CICS RUN TRANSID API command.
•Current number of child tasks (field ASG_CHILDREN_CUR)
The current number of active tasks that were started by EXEC CICS RUN TRANSID API commands.
•Peak number of child tasks (field ASG_CHILDREN_PEAK)
The peak number of active tasks that were started by EXEC CICS RUN TRANSID API commands.
Example 8-2 shows an extract of a sample DFHSTUP report for a workload that uses the asynchronous API.
Example 8-2 Asynchronous services global statistics report produced by CICS TS V5.4 DFHSTUP
RUN commands : 40587368
FETCH commands : 40587290
FREE commands : 0
Current active children : 1
Peak active children : 120
Times RUN commands being delayed : 823
Current parents being delayed : 0
Peak parents being delayed : 5
For more information about asynchronous services domain statistics, see the “Asynchronous services domain: Global statistics” topic in IBM Knowledge Center at this website:
8.9.5 Asynchronous service domain performance comparison
To understand the overhead of the new API commands, a simple workload was created. This workload compared the new EXEC CICS RUN TRANSID command with another common method of executing child tasks in CICS: EXEC CICS START.
Two transactions were created, each of which have an initial program that performs the following sequence of CICS commands:
1. EXEC CICS RECEIVE
Receives control data from the terminal.
2. EXEC CICS PUT CONTAINER
Configures a container to be passed to the child task, indicating the length of time for which the child task will suspend.
3. EXEC CICS PUT CONTAINER
Configures a container in the channel to pass dummy data to the child task.
4. EXEC CICS START (transaction ASGS) or EXEC CICS RUN TRANSID (transaction ASGX)
Creates a new child task using the selected CICS command. This step is repeated multiple times, based on input received from the terminal.
5. EXEC CICS SEND
Sends a completion message to the terminal.
6. EXEC CICS RETURN
Returns control to CICS.
Steps 2 to 4 are repeated multiple times to create the required number of child tasks. Both programs create the same child transaction, ACHL, passing 4 KB of data as input. Neither transaction performs any other business logic, nor is any logic used to return information from the child tasks to the parent task. The suspend time configured in step 2 is used to simulate CICS waiting for an external service, without introducing unnecessary dependencies on non-CICS resources.
The transactions were initiated from a terminal using the methodology described in 2.4, “Driving the workload” on page 16. The transactions were executed approximately 270 times with CICS performance class monitoring enabled, and averages of the resulting data points recorded. Table 8-13 shows the CICS performance class monitoring data collected for each of the transactions in the workload.
Table 8-13 CICS monitoring data for the asynchronous API command comparison
|
Transaction
|
Average response time (ms)
|
Average user CPU time
(ms) |
Average QR CPU time
(ms) |
Average QR dispatch time
(ms) |
Average TCB change mode operations
|
|
ASGS
|
0.631
|
0.184
|
0.125
|
0.137
|
30
|
|
ASGX
|
0.284
|
0.140
|
0.030
|
0.038
|
10
|
|
ACHL
|
0.163
|
0.036
|
0.036
|
0.037
|
0
|
As shown in the table, the average CPU time for the ASGS transaction was 0.184 ms, compared to 0.140 ms for the ASGX transaction. Both the ASGS and ASGX transactions create ten ACHL transactions, with the remainder of the application logic identical. We can therefore conclude that the EXEC CICS START command costs approximately 0.004 ms of CPU more per request than the EXEC CICS RUN TRANSID command.
The “Average TCB change mode operations” column shows an average of 30 change mode operations for the ASGS transaction (EXEC CICS START), with the ASGX transaction (EXEC CICS RUN TRANSID) requiring only 10 change mode operations.
The programs used in the ASGS and ASGX transactions are both defined with the CONCURRENCY attribute of REQUIRED. As described in 4.3.2, “Programs specifying JVM(NO) and API(CICSAPI)” on page 34, specifying the value of REQUIRED will cause the program to always run on an Open TCB.
The ASGX transaction has a baseline of 10 TCB switch operations, which are accumulated as follows:
•Initial program invocation
1 TCB change mode (QR L8)
•EXEC CICS RECEIVE (a non-threadsafe command)
2 TCB change modes (L8 QR L8)
•EXEC CICS PUT CONTAINER (a threadsafe command)
0 TCB change modes
•EXEC CICS RUN TRANSID (a threadsafe command)
0 TCB change modes
•EXEC CICS SEND (a non-threadsafe command)
2 TCB change modes (L8 QR L8)
•End of task sync point and task-related user exit (TRUE) processing
4 TCB change modes
•Transaction termination
1 TCB change mode (L8 QR)
The ASGS transaction follows a similar pattern as the ASGX baseline, but the EXEC CICS START command is not threadsafe. Therefore, invoking the program switches from an L8 TCB to the QR TCB and back for each of the 10 EXEC CICS START commands that are executed. The ASGS transaction has 20 TCB change mode operations more than the ASGX baseline. Table 8-13 on page 180 also shows the extra QR TCB dispatch and CPU time when using the EXEC CICS START command.
Table 8-13 on page 180 also shows a response time improvement when using EXEC CICS RUN TRANSID and this is due primarily to the removal of time spent waiting for dispatch on the QR TCB.
8.9.6 Asynchronous API performance summary
The results in 8.9.5, “Asynchronous service domain performance comparison” on page 179 show that initiating child tasks using the EXEC CICS RUN TRANSID command is approximately the same CPU cost as using an EXEC CICS START command. The results show a slight overhead for EXEC CICS START due to TCB change mode processing, but if the user application were not defined with the CONCURRENCY attribute of REQUIRED, then this overhead would disappear.
Using the asynchronous API can provide modern applications with a method of initiating child tasks and retrieving their results using an API provided by CICS. Alternative implementations of managing communication between parent and child tasks include:
•Using event control blocks (ECBs) or the EXEC CICS ENQ and EXEC CICS DEQ commands to synchronize access to common storage. This can be error-prone and places the responsibility of task management with application code, rather than the system. It is particularly difficult to gracefully handle timeout processing in all cases. Child tasks and common storage can easily become orphaned in the event of application abends.
•Polling of CICS services (such as temporary storage). Polling a resource to check for a response can have two undesired consequences:
– It can waste CPU when the polling time is short and the average response time is long
– It can cause unnecessary delays in response when the polling time is long and the average response time is short
•Using CICS services (such as intrapartition transient data trigger queues) to notify of child task completion. This has a lower overhead than the polling approach and maintains application responsiveness, but still requires some application management of tasks. Handling timeouts can also be problematic.
•Using external resource manager (such as IBM MQ). A common application pattern is for a parent task to start a child task and then use an MQ GET command to wait for notification of completion. Calling an external resource manager in another address space adds additional overhead in terms of CPU time. Use of external products also adds to application complexity, increasing management and monitoring overhead.
All of these implementation alternatives require either an explicit or an implicit EXEC CICS START command to initiate the child task. The performance results discussed previously demonstrate that the EXEC CICS RUN TRANSID is no more expensive to execute than a simple EXEC CICS START command yet provides access to the full range of advantages of the CICS asynchronous API:
•A fully-supported API, removing the need for complex infrastructure code in the application.
•Automated workflow management which allows transactions to complete, even during periods when CICS is under stress.
•Communication between parent and child tasks is via the channels and containers API, which uses 64-bit virtual storage for data. This reduces pressure on virtual storage in the UDSA and EUDSA dynamic storage areas.
•Advanced task-level and system-level information provided alongside the existing CICS statistical and performance monitoring data.
The CICS asynchronous API provides a simple, supported method of coordinating parent and child tasks, and remains no more expensive than alternative, application-specific implementations.
8.10 EXCI support for channels and containers
The CICS TS V5.4 release introduces the ability to pass data in channels and containers when invoking CICS applications using the external CICS interface (EXCI). The use of channels and containers provides two main benefits:
•Multiple, named data areas can be passed in a single call
•Each container can hold significantly a larger data area than possible with a COMMAREA
|
Note: Only the client (EXCI) application needs to use CICS TS V5.4 libraries to take advantage of this function. Any release of CICS that supports channels and containers can receive data from a client application using the channels and containers interface.
|
For more information about EXCI, see the “Introduction to the external CICS interface” topic in IBM Knowledge Center at this website:
A common use-case for EXCI applications is to send data into a CICS program, but the data to be transmitted is larger than the COMMAREA limit of 32 KB. For these cases, the application chunks the data into areas less than 32 KB in size. Multiple requests are used to send the data into CICS, and logic in the CICS program reassembles the data into a contiguous block.
The channels and containers support for EXCI allows applications to send large areas of data into CICS, removing the complexity of this chunking logic and the overhead of multiple calls to the server. This section presents a comparison between two applications, one that uses the chunking method with COMMAREAs, and another that uses channels and containers.
The client EXCI application was implemented using the C language, and the CICS applications were implemented using COBOL.
8.10.1 Application design (COMMAREA)
The COMMAREA test case used the following logic in the client application:
1. Allocate storage and initialize data to be sent to the server. Note that the storage is initialized to random values to remove any potential optimizations achieved with large data areas consisting solely of zeros.
2. Open the EXCI pipe to the server using the Initialize_User, Allocate_Pipe, and Open_Pipe commands.
3. Start the timers for recording elapsed time in the client application.
4. Send the data to the server in chunks:
a. Initialize the current offset pointer to zero.
b. Send a maximum of 32,763 bytes of data using the DPL_Request command.
c. Advance the current offset pointer.
d. Repeat from step b until no data remains.
5. Stop the timers for recording elapsed time in the client application.
6. Shut down the EXCI pipe using calls to the Close_Pipe and Deallocate_Pipe commands.
The COMMAREA test case used long-running mirrors in the server to allow the receiving transaction to utilize task-related storage for reassembly of the chunked data. The following logic was used in the server application:
1. For the first chunk of data received:
a. Issue EXEC CICS GETMAIN to obtain storage for the total data length required, supplied as the first four bytes of the COMMAREA.
b. Save the obtained storage address and the current offset pointer in the transaction work area (TWA).
c. Copy received chunk of data to the obtained storage.
d. Advance current offset pointer.
2. For subsequent chunks of data received:
a. Copy received chunk of data to the obtained storage.
b. Advance the current offset pointer.
3. For the final chunk of data received:
a. Copy received chunk of data to the obtained storage.
b. Application would normally perform business logic at this point.
c. Issue EXEC CICS FREEMAIN to release allocated storage.
In both the client and server application code, to minimize overheads no data was copied unnecessarily. As described in 2.2, “Workload design” on page 12, the application was designed to include as little business logic as possible, to more clearly determine the costs of the CICS infrastructure.
8.10.2 Application design (channels)
The channels test case used the following logic in the client application:
1. Allocate storage and initialize data to be sent to the server. Note that the storage is initialized to random values to remove any potential optimizations achieved with large data areas consisting solely of zeros.
2. Open the EXCI pipe to the server using the Initialize_User, Allocate_Pipe, and Open_Pipe commands.
3. Start the timers for recording elapsed time in the client application.
4. Issue EXEC CICS PUT CONTAINER to store the data in a container.
5. Invoke the CICS program using the DPL_Request command, passing the channel name specified in the previous step.
6. Issue EXEC CICS DELETE CONTAINER to free storage in the client application.
7. Stop the timers for recording elapsed time in the client application.
8. Shut down the EXCI pipe using calls to the Close_Pipe and Deallocate_Pipe commands.
The channels test case also used long-running mirrors in the server to simplify application configuration, although this was not a functional requirement. The following logic was used in the server application:
1. Issue EXEC CICS GET CONTAINER(...) SET(...) to obtain a reference to the received data.
2. Application would normally perform business logic at this point.
The server application logic is considerably simplified when using channels and containers. As described in the COMMAREA test case, no data was copied unnecessarily to minimize overheads. As described in 2.2, “Workload design” on page 12, the application was designed to include as little business logic as possible, to more clearly determine the costs of the CICS infrastructure.
8.10.3 Payload comparisons
The performance benchmark compared response time and CPU consumption for several sizes of payload. Table 8-14 lists the payload sizes used, along with the number of COMMAREAs required to transmit the payload in its entirety.
Table 8-14 List of payload sizes compared
|
Payload size label
|
Bytes transmitted
|
COMMAREAs required
|
|
32
|
32
|
1
|
|
1,024
|
1,024
|
1
|
|
32,760
|
32,760
|
1
|
|
32 KB
|
32,768
|
2
|
|
512 KB
|
524,288
|
17
|
|
1 MB
|
1,048,576
|
33
|
|
2 MB
|
2,097,152
|
65
|
8.10.4 CPU time comparison
Client application CPU was measured using the z/OS TIMEUSED service. CPU consumed by the server application was measured using CICS performance class monitoring data. Total CPU measurements include CPU consumed by both the client application and the receiving CICS task.
Table 8-15 lists the total CPU time consumed by the client and server application for both the COMMAREA and channel scenarios.
Table 8-15 CPU time comparison for various payloads
|
Payload
|
COMMAREA
total CPU time (ms) |
Channel
total CPU time (ms) |
|
32
|
0.016
|
0.057
|
|
1,024
|
0.016
|
0.057
|
|
32,760
|
0.035
|
0.079
|
|
32 KB
|
0.053
|
0.080
|
|
512 KB
|
0.589
|
0.351
|
|
1 MB
|
1.171
|
0.655
|
|
2 MB
|
2.323
|
1.251
|
The results in Table 8-15 can be plotted on a chart to demonstrate the behavior of the two scenarios as the payload size increases. Figure 8-10 plots the results for payloads of size 32 bytes to 32 KB.
Figure 8-10 Plot of total CPU time comparing COMMAREA and channel scenarios for small payloads
Note the increase in CPU time when increasing the payload from 32,760 bytes to 32,768 bytes in the COMMAREA scenario. This sudden increase is the overhead of requiring a second send request, because the data no longer fits within a single COMMAREA.
Figure 8-11 plots the results for payloads of size 32 KB to 2 MB.
Figure 8-11 Plot of total CPU time comparing COMMAREA and channel scenarios for large payloads
Both scenarios scale linearly as the payload size increases, but the channel implementation is more efficient from a relatively low payload size.
8.10.5 Response time comparison
Overall application response time was measured in the client using the z/Architecture STCK instruction. Table 8-16 lists the application response times for both the COMMAREA and channel scenarios.
Table 8-16 Response time comparison for various payloads
|
Payload
|
COMMAREA
response time (ms) |
Channel
response time (ms) |
|
32
|
0.024
|
0.072
|
|
1,024
|
0.024
|
0.072
|
|
32,760
|
0.084
|
0.141
|
|
32 KB
|
0.108
|
0.144
|
|
512 KB
|
1.365
|
1.113
|
|
1 MB
|
2.711
|
2.154
|
|
2 MB
|
5.390
|
4.230
|
The results in Table 8-16 can be plotted on a chart to demonstrate the behavior of the two scenarios as the payload size increases. Figure 8-12 on page 187 plots the response times for payloads of size 32 bytes to 32 KB.
Figure 8-12 Plot of response time comparing COMMAREA and channel scenarios for small payloads
As observed for CPU time in Figure 8-10 on page 185, there is relatively large increase in response time when the payload requires a second send request.
Figure 8-13 plots the response times for payloads of size 32 KB to 2 MB.
Figure 8-13 Plot of response time comparing COMMAREA and channel scenarios for large payloads
As observed for the CPU time comparisons, both scenarios scale linearly as the payload size increases, but again the channel implementation produces lower response times from a relatively low payload size.
8.10.6 EXCI support for channels and containers performance summary
For smaller payloads, the channels and containers implementation can be shown to have a minor overhead when compared to the COMMAREA implementation in terms of both CPU consumption and response time. As the payload size increases, this CPU and response time overhead is reduced dramatically when the payload requires more than one send operation.
Using linear regression analysis shows that channels and containers are the most efficient approach for payloads larger than 64 KB (that is, those that require three or more DPL_Request operations).
As payload sizes increase, CPU and response time increase linearly for both scenarios.
The overhead of channels and containers for this test case was at most 40 µs of CPU time and 50 µs in response time, even for the smallest of payloads. This is a small value in the context of a real-world application with business logic. The advantages of the channels and containers implementation over a COMMAREA approach are:
•Reduced client and server code complexity when sending more than 32 KB of data.
•Increased flexibility, due to the ability to send multiple data areas in one call.
•Potential for future expansion without redesigning the application.
The code maintenance advantages listed here are significant, and these offset the small CPU benefits of a COMMAREA solution. Therefore, any new EXCI applications invoking CICS should use the channels and containers interface.
8.11 CICS support for IBM Health Checker for z/OS
IBM Health Checker for z/OS (Health Checker) is a z/OS component that helps simplify and automate the identification of potential configuration problems before they impact availability or cause outages. CICS TS supports Health Checker rules that define preferred practices for CICS system configuration.
Each CICS region providing support for Health Checker executes the system transaction CHCK as a long-running task. This task wakes up every 30 minutes to check and report on compliance to preferred practices. To ensure this task does not consume unnecessary CPU, two idle CICS regions were compared.
One CICS region had the Health Checker reporting enabled and the other had the Health Checker reporting disabled. Both CICS regions had security enabled (SIT parameter SEC=YES), and 25 transient data queues were installed. To ensure the most accurate reporting of CPU consumption, the CHCK transaction was specially modified to wake up every 5 seconds.
Using the overnight automation environment as described in 2.3, “Repeatable measurements” on page 13, performance of the two CICS regions were measured while idle for a 5-minute measurement period. CPU consumption data was extracted from the CICS statistics report and is presented in Table 8-17 on page 189. All data is presented in CPU seconds.
Table 8-17 Summary of CICS statistics for Health Checker CPU measurement
|
|
CHCK disabled
|
CHCK enabled
|
Difference
|
|
Address space TCB time
|
0.003888
|
0.035986
|
0.032098
|
|
Address space SRB time
|
0.000349
|
0.000538
|
0.000189
|
|
Total CPU time
|
0.004237
|
0.036524
|
0.032287
|
The CICS statistics interval was 305 seconds; therefore, we can conclude the CHCK task woke up around 60 times during that time period. Also, we can calculate that the CHCK task cost approximately 540 µs of CPU per iteration.
When using the CICS support for Health Checker configuration with the standard checking frequency of 30 minutes, this functionality consumes approximately 1 ms of CPU per hour for a completely idle CICS region. In contrast, the results presented in Table 8-17 for the CICS region with Health Checker support disabled show a CPU consumption of approximately 50 ms per hour for other CICS background processing. Thus, we can conclude that CICS support for the IBM Health Checker for z/OS adds no significant overhead to a CICS region.
|
Note: CICS support for the IBM Health Checker for z/OS is also available for releases prior to CICS TS V5.4. See APAR PI76963 for CICS TS V4.2 and APAR PI76965 for CICS TS V5 releases.
|
For more information about the CICS support for the Health Checker, see the topic “Checking CICS configuration with IBM Health Checker for z/OS” in IBM Knowledge Center:
8.12 Web services performance
This section examines the performance of the CICS TS V5.4 web services support, using several variants of the web services workload detailed in 3.6, “Web services” on page 28. All sections present the data in a similar tabular format:
•Request rate
The number of SOAP requests per second
•CICS CPU %
The amount of CPU consumed by the CICS provider region, expressed as a percentage of a single CP
•TCP/IP CPU %
The amount of CPU consumed by the TCP/IP address space, expressed as a percentage of a single CP
•CPU per request
A calculation of the total CPU consumed per request, which includes the CICS provider region and the TCP/IP address space, expressed as milliseconds
•Response time
Where applicable, the response time is obtained from RMF monitoring data, expressed in milliseconds
8.12.1 Persistent and non-persistent connections
This section looks at the performance of the web services workload when running with non-persistent and persistent connections. Neither scenario used SSL.
The data in Table 8-18 shows the performance characteristics of CICS web services support when using persistent connections.
Table 8-18 Web services workload with persistent connections and no SSL
|
Request rate
|
CICS CPU %
|
TCP/IP CPU %
|
CPU per request (ms)
|
|
417
|
12.58%
|
0.48%
|
0.313
|
|
500
|
15.14%
|
0.58%
|
0.314
|
|
555
|
16.99%
|
0.69%
|
0.319
|
|
714
|
22.10%
|
0.79%
|
0.321
|
|
999
|
31.20%
|
0.98%
|
0.322
|
Table 8-19 shows the performance characteristics of the same workload when using non-persistent connections.
Table 8-19 Web services workload with non-persistent connections and no SSL
|
Request rate
|
CICS CPU %
|
TCP/IP CPU %
|
CPU per request (ms)
|
|
417
|
14.66%
|
0.85%
|
0.372
|
|
500
|
17.62%
|
1.03%
|
0.373
|
|
556
|
19.63%
|
1.16%
|
0.374
|
|
714
|
25.29%
|
1.45%
|
0.375
|
|
1000
|
36.19%
|
1.94%
|
0.381
|
For both configurations and at all measured transaction rates, the response times were less than 1 ms therefore the response time columns have been omitted.
These results are summarized by the chart in Figure 8-14.
Figure 8-14 Comparison of persistent and non-persistent connections without SSL
On average the CICS provider region and TCP/IP address space consumed 0.318 ms of CPU per request with persistent sessions, and 0.375 ms of CPU per request with non-persistent sessions. This overhead is the result of the small extra processing required by the CICS provider region and network layer when creating and destroying an HTTP session.
8.12.2 Overhead of using SSL with persistent connections
As described in 3.6.1, “Web services variations” on page 29 the workload can use SSL to encrypt request and response data. To determine the overhead of this encryption, CICS SSL support was enabled to use the TLS_RSA_WITH_AES_256_CBC_SHA cipher suite and persistent sessions.
The results of this configuration are presented in Table 8-20 and can be compared with the performance data presented in Table 8-18 on page 190.
Table 8-20 Web services workload using SSL with persistent connections
|
Request rate
|
CICS CPU %
|
TCP/IP CPU %
|
CPU per request (ms)
|
|
417
|
13.85%
|
0.38%
|
0.341
|
|
500
|
16.51%
|
0.44%
|
0.339
|
|
555
|
18.05%
|
0.46%
|
0.334
|
|
714
|
23.45%
|
0.57%
|
0.336
|
|
1000
|
33.95%
|
0.75%
|
0.347
|
In both configurations and at all transaction rates, the response time was 1 ms or less and therefore the response time column has been omitted for clarity. These measurements are summarized by the chart in Figure 8-15 on page 192.
Figure 8-15 Comparison of non-SSL and SSL connections using persistent sessions
As documented in 8.12.1, “Persistent and non-persistent connections” on page 190 the average CPU per request figure for non-SSL communications was 0.318 ms. When using CICS SSL support, this figure rises by 0.057 ms per request to 0.375 ms.
8.12.3 SSL handshake overhead
Section 8.12.2, “Overhead of using SSL with persistent connections” on page 191 documents the overhead of using encryption when no SSL handshakes are required. This section looks in more detail at the handshake options available.
A full SSL handshake occurs when SSL partners negotiate an SSL session without the benefit of any previously-agreed information. A partial SSL handshake occurs when SSL partners establish an SSL connection using a token cached from a previously-negotiated connection. This partial handshake allows SSL partners to avoid the overhead of a full SSL session negotiation while retaining the integrity of SSL.
The first scenario obtained performance data in a steady-state situation where no SSL handshakes were taking place by enabling persistent sessions. This data was presented in section 8.12.2, “Overhead of using SSL with persistent connections” on page 191 and is available in Table 8-20 on page 191.
The second scenario measured performance when SSL partial handshakes were being used and the performance data is presented in Table 8-21.
Table 8-21 Web services workload using SSL with partial handshakes
|
Request rate
|
CICS CPU %
|
TCP/IP CPU %
|
CPU per request (ms)
|
Response time (ms)
|
|
417
|
20.13%
|
1.12%
|
0.510
|
2
|
|
500
|
23.87%
|
1.33%
|
0.504
|
2
|
|
556
|
26.35%
|
1.43%
|
0.500
|
2
|
|
715
|
34.20%
|
1.75%
|
0.503
|
2
|
|
1000
|
48.36%
|
2.47%
|
0.508
|
3
|
The third scenario measured performance of SSL full handshakes, and the data is presented in Table 8-22.
Table 8-22 Web services workload using SSL with full handshake
|
Request rate
|
CICS CPU %
|
TCP/IP CPU %
|
CPU per request (ms)
|
Response time (ms)
|
|
416
|
25.73%
|
1.62%
|
0.657
|
8
|
|
500
|
29.76%
|
1.92%
|
0.634
|
6
|
|
555
|
32.99%
|
2.11%
|
0.632
|
6
|
|
713
|
43.64%
|
2.57%
|
0.648
|
7
|
|
986
|
64.75%
|
3.12%
|
0.688
|
11
|
The results of these three scenarios are summarized in Figure 8-16.
Figure 8-16 Comparison of web services performance using SSL with various handshake options
The average CPU per request for persistent sessions, partial handshakes, and full handshakes is 0.339 ms, 0.505 ms, and 0.652 ms respectively. This data shows that the CPU overhead of a partial handshake is therefore around 0.165 ms of CPU, which includes the cost of establishing a new connection and the renegotiation of a previously-established session. The CPU overhead of a full handshake is approximately 0.150 ms in addition to the cost of a partial handshake.
The CPU overhead for SSL full and partial handshakes is dependant on several factors, including:
•The key exchange algorithm
•The size of the and complexity of the public keys
•Use of client authentication
8.12.4 CICS SSL and AT-TLS
Table 8-23 presents the performance results of the web services workload using AT-TLS with persistent sessions. By comparing the data in Table 8-20 on page 191 with the data in Table 8-23 we can determine the relative difference in performance between using the CICS SSL support and the AT-TLS support provided by IBM Communications Server for z/OS.
Table 8-23 Web services workload using AT-TLS with persistent sessions
|
Request rate
|
CICS CPU %
|
TCP/IP CPU %
|
CPU per request (ms)
|
Response time (ms)
|
|
417
|
12.59%
|
0.39%
|
0.311
|
1
|
|
500
|
15.15%
|
0.46%
|
0.312
|
1
|
|
556
|
16.63%
|
0.50%
|
0.308
|
1
|
|
714
|
21.62%
|
0.64%
|
0.312
|
1
|
|
1000
|
30.12%
|
0.89%
|
0.310
|
1
|
When using the SSL support provided by CICS the average CPU per transaction was 0.339 ms. When using the AT-TLS support the same value was 0.311 ms. This difference in CPU per request can be attributed to two key factors:
•The removal of the requirement for the CWXN transaction. When using CICS SSL support the CXWN transaction is required, but using AT-TLS this is no longer required. See 7.7, “Web support and web service optimization” on page 122 for more details.
•A reduction in the number of TCB switches in the user transaction. CICS SSL support requires several task switches to and from S8 TCBs, but AT-TLS does not have this requirement.
The chart in Figure 8-17 on page 195 presents the data from the two scenarios for comparison.
Figure 8-17 Web services workload comparing CICS SSL and AT-TLS with persistent sessions
..................Content has been hidden....................
You can't read the all page of ebook, please click here login for view all page.