CICS TS for z/OS V5.2
This chapter describes many of the performance-related improvements that are found in the CICS TS for z/OS V5.2 release. The following subject areas are included in the CICS TS V5.2 performance report:
•Key performance benchmarks that are presented as a comparison against the CICS TS V5.1 release.
•An outline of improvements that were made regarding the threadsafe characteristics of the CICS run time.
•Details of the changes that were made to performance-critical CICS initialization parameters and the affect of these updates.
•Description of all the new and updated monitoring fields, including examples where necessary.
•High-level views of new functions that were introduced in the CICS TS V5.2 release, including performance benchmark results where appropriate.
This chapter includes the following topics:
6.1 Introduction
When the results for this chapter were compiled, the workloads were run on an IBM zEnterprise EC12 model HA1 (machine type 2827). A maximum of 32 dedicated central processors (CPs) were available on the measured logical partition (LPAR), with a maximum of four 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, which were connected by 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 run in a CICS TS for z/OS V5.2 environment. Unless otherwise stated in the results, the CICS V5.2 environment was the code available at the general availability (GA) date of 13 June 2014. Several of the performance benchmarks are presented in the context of a comparison against CICS TS V5.1. The CICS TS V5.1 environment contained all PTFs issued before 18 February 2014. All LPARs used z/OS V2.1.
For more information about performance terms that are used in this chapter, see Chapter 1, “Performance terminology” on page 3. A description of the test methodology that was used can be found in Chapter 2, “Test methodology” on page 11. For more information about the workloads that were 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 the use of LSPR data, see 1.3, “Large Systems Performance Reference” on page 6.
6.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.
6.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”. This section presents the performance figures that were obtained by running this workload. Table 6-1 lists the results of the DSW static routing workload that used the CICS TS V5.1 release.
Table 6-1 CICS TS V5.1 results for DSW static routing workload
|
ETR
|
CICS CPU
|
CPU per transaction (ms)
|
|
2563.06
|
57.03%
|
0.223
|
|
3011.97
|
66.75%
|
0.222
|
|
3613.27
|
79.61%
|
0.220
|
|
4515.94
|
98.11%
|
0.217
|
|
6029.03
|
128.57%
|
0.213
|
Table 6-2 lists the same figures for the CICS TS V5.2 release.
Table 6-2 CICS TS V5.2 results for DSW static routing workload
|
ETR
|
CICS CPU
|
CPU per transaction (ms)
|
|
2562.81
|
57.00%
|
0.222
|
|
3011.61
|
66.74%
|
0.222
|
|
3613.01
|
79.61%
|
0.220
|
|
4515.30
|
98.47%
|
0.218
|
|
6028.32
|
129.29%
|
0.214
|
The average CPU per transaction value for CICS TS V5.1 is calculated to be 0.219 ms. The same value for CICS TS V5.2 is also calculated to be 0.219 ms. The performance of this workload is considered to be equivalent across the two releases.
These figures are shown in Figure 6-1.
Figure 6-1 Plot of CICS TS V5.1 and V5.2 performance figures for DSW static routing workload
The measured CPU cost for each transaction rate is similar for CICS TS V5.1 and V5.2, which is demonstrated by the two plot lines being almost identical. A final observation is that the CPU cost scales linearly in accordance with the transaction rate.
6.2.2 DSW dynamic routing
The dynamic routing variant of the DSW workload is described in 3.2.2, “DSW dynamic routing”. This section presents the performance figures that were obtained by running this workload.
Table 6-3 lists the results of the DSW dynamic routing workload that used the CICS TS V5.1 release.
Table 6-3 CICS TS V5.1 results for DSW dynamic routing workload
|
ETR
|
CICS CPU
|
CPU per transaction (ms)
|
|
3006.60
|
158.00%
|
0.526
|
|
6118.61
|
308.48%
|
0.504
|
|
8830.54
|
440.00%
|
0.498
|
|
11962.02
|
599.67%
|
0.501
|
|
16238.38
|
815.93%
|
0.502
|
Table 6-4 lists the same figures for the CICS TS V5.2 release.
Table 6-4 CICS TS V5.2 results for DSW dynamic routing workload
|
ETR
|
CICS CPU
|
CPU per transaction (ms)
|
|
3005.68
|
159.81%
|
0.532
|
|
6111.82
|
311.00%
|
0.509
|
|
8827.54
|
441.50%
|
0.500
|
|
11963.57
|
596.41%
|
0.499
|
|
16252.29
|
817.04%
|
0.503
|
Figure 6-2 Plot of CICS TS V5.1 and V5.2 performance figures for DSW dynamic routing workload
As with the DSW static routing workload, the V5.1 and V5.2 lines are almost identical, which indicates near-identical CPU cost per transaction. The plot lines are also straight, which indicates linear scaling as transaction throughput increases.
6.2.3 Relational Transactional Workload non-threadsafe
The Relational Transactional Workload (RTW) is described in 3.3, “Relational Transactional Workload” on page 25. This section presents the performance figures for the non-threadsafe variant when CICS TS V5.1 is compared with CICS TS V5.2.
Table 6-5 lists the performance results for the RTW non-threadsafe workload that used the CICS TS V5.1 release.
Table 6-5 CICS TS V5.1 results for the RTW non-threadsafe workload
|
ETR
|
CICS CPU
|
CPU per transaction (ms)
|
|
250.08
|
60.71%
|
2.428
|
|
332.92
|
80.40%
|
2.415
|
|
453.24
|
113.15%
|
2.496
|
|
585.73
|
147.30%
|
2.515
|
|
709.60
|
180.50%
|
2.544
|
Table 6-6 lists the same figures for the CICS TS V5.2 release.
Table 6-6 CICS TS V5.2 results for the RTW non-threadsafe workload
|
ETR
|
CICS CPU
|
CPU per transaction (ms)
|
|
250.20
|
60.37%
|
2.413
|
|
332.92
|
79.88%
|
2.399
|
|
453.54
|
110.97%
|
2.447
|
|
586.15
|
145.72%
|
2.486
|
|
710.25
|
178.82%
|
2.518
|
For the V5.1 release, the average CPU cost per transaction is calculated to be 2.480 ms. The V5.2 release produces an average of 2.453 ms. This difference represents a reduction in CPU per transaction of approximately 1%.
Figure 6-3 Plot of CICS TS V5.1 and V5.2 performance figures for RTW non-threadsafe workload
The straight line represents linear scaling as throughput increases. The CICS TS V5.2 line shows a slight improvement when compared with CICS TS V5.1.
6.2.4 RTW threadsafe
This section presents the performance figures for the threadsafe variant of the RTW, as described in 3.3, “Relational Transactional Workload” on page 25.
Table 6-7 lists the results of the RTW threadsafe workload that used the CICS TS V5.1 release.
Table 6-7 CICS TS V5.1 results for the RTW threadsafe workload
|
ETR
|
CICS CPU
|
CPU per transaction (ms)
|
|
333.14
|
53.86%
|
1.617
|
|
498.78
|
80.12%
|
1.606
|
|
711.30
|
114.03%
|
1.603
|
|
990.59
|
157.05%
|
1.585
|
|
1227.39
|
195.89%
|
1.596
|
Table 6-8 lists the same figures for the CICS TS V5.2 release.
Table 6-8 CICS TS V5.2 results for the RTW threadsafe workload
|
ETR
|
CICS CPU
|
CPU per transaction (ms)
|
|
333.79
|
53.63%
|
1.607
|
|
499.18
|
79.72%
|
1.597
|
|
711.84
|
114.13%
|
1.603
|
|
991.11
|
157.43%
|
1.588
|
|
1228.72
|
196.47%
|
1.599
|
These performance results are shown in Figure 6-4.
Figure 6-4 Plot of CICS TS V5.1 and V5.2 performance figures for RTW threadsafe workload
The straight line indicates linear scaling as throughput increases, while the almost identical lines demonstrate equivalent performance between the two CICS releases.
6.2.5 Java servlet that uses JDBC and VSAM
The JDBC and VSAM Java servlet benchmark was run in the environment as described in 6.1, “Introduction” on page 78. The LPAR that was used for performance measurements was configured with three dedicated CPs and one dedicated IBM System z® Integrated Information Processor (zIIP). The LPAR that was used to drive workload into the measured system was configured with three dedicated CPs. Both of these LPARs represent an LSPR equivalent processor of 2827-703. All configurations used IBM DB2 for z/OS V10, with IBM Workload Simulator for z/OS V1.1.0.1 driving the workload as 200 simulated HTTP clients.
All tests used a CICS region that contained a single JVMSERVER resource with the THREADLIMIT attribute set to 100. The following garbage collection and memory management options were specified in the relevant JVM profile configuration file:
•-Xgcpolicy:gencon
•-Xcompressedrefs
•-XXnosuballoc32bitmem
•-Xmx200M
•-Xms200M
•-Xmnx60M
•-Xmns60M
•-Xmox140M
•-Xmos140M
For more information about these JVM tuning parameters, see the “Command-line options” topic in IBM Knowledge Center at the following website:
To minimize variance in the performance results that might be introduced by the just-in-time (JIT) compiler, the workload was run at a constant transaction rate for 20 minutes to provide a warm-up period. The request rate was increased every 10 minutes, with the mean CPU usage per request calculated by using the final five minutes of data from the 10-minute interval.
As described for other workloads in 2.6, “Collecting performance data” on page 18, IBM Resource Measurement Facility™ (RMF) was used to record CPU consumption at an address space level.
CICS TS V5.1 and CICS TS V5.2 used Java 7.0 SR7 (64-bit). In addition to the software environment that is described in 6.1, “Introduction” on page 78, the following software versions were used:
•CICS TS V5.1 with IBM WebSphere Application Server Liberty V8.5.0.0
•CICS TS V5.2 with IBM WebSphere Application Server Liberty V8.5.0.1
Table 6-9 lists the performance measurements when running the workload in a CICS TS V5.1 environment.
Table 6-9 CICS TS V5.1 results for the Java servlet JDBC and VSAM workload
|
ETR
|
CICS CPU
|
CPU per request (ms)
|
||
|
Not zIIP-eligible
|
zIIP-eligible
|
Total
|
||
|
200
|
20.87%
|
30.03%
|
50.90%
|
2.545
|
|
400
|
42.02%
|
60.81%
|
102.83%
|
2.571
|
|
800
|
86.61%
|
120.95%
|
207.55%
|
2.594
|
Table 6-10 lists the performance measurements when running the workload in a CICS TS V5.2 environment.
Table 6-10 CICS TS V5.2 results for the Java servlet JDBC and VSAM workload
|
ETR
|
CICS CPU
|
CPU per request (ms)
|
||
|
Not zIIP-eligible
|
zIIP-eligible
|
Total
|
||
|
200
|
20.82%
|
29.42%
|
50.24%
|
2.512
|
|
400
|
42.34%
|
60.12%
|
102.46%
|
2.562
|
|
800
|
86.46%
|
120.38%
|
206.85%
|
2.586
|
A subset of the performance measurements in Table 6-9 on page 84 and Table 6-10 on page 84 is shown Figure 6-5.
Figure 6-5 CICS TS V5.1 and CICS TS V5.2 performance results for JDBC and VSAM workload
The total CPU lines for CICS TS V5.1 and CICS TS V5.2 are almost identical and demonstrate similar performance when comparing the two CICS TS releases. The straight lines represent linear scaling as the transaction rate increases.
Also, the fraction of total workload that is eligible for offload features similar profiles between the CICS TS V5.1 and CICS TS V5.2 releases. Again, the straight line demonstrates the linear scaling nature of the environment.
For the sake of clarity, the non-zIIP-eligible performance results were omitted from Figure 6-5; however, it can be concluded that non-zIIP-eligible time must scale in a similar manner as shown in the following equation:
Total CPU time = non zIIP-eligible time + zIIP-eligible time
6.3 Improvements in threadsafe API and SPI commands
CICS V5.2 brings further improvements in threadsafe API and SPI commands. The following new CICS API commands are threadsafe:
•INVOKE APPLICATION
•VERIFY TOKEN
For more information about CICS API commands, see the “CICS command summary” topic in IBM Knowledge Center at this website:
The following CICS SPI commands were made threadsafe:
•INQUIRE MVSTCB
•DISPATCHER commands:
– INQUIRE DISPATCHER
– SET DISPATCHER
•MONITOR commands:
– INQUIRE MONITOR
– SET MONITOR
•PROGRAM commands:
– INQUIRE PROGRAM
– SET PROGRAM
– DISCARD PROGRAM
•STATISTICS commands:
– EXTRACT STATISTICS
– INQUIRE STATISTICS
– SET STATISTICS
•SYSTEM commands:
– INQUIRE SYSTEM
– SET SYSTEM
•TRANSACTION commands:
– INQUIRE TRANSACTION
– SET TRANSACTION
– DISCARD TRANSACTION
For more information about CICS SPI commands, see the “System commands” topic in IBM Knowledge Center at this website:
6.4 Changes to system initialization parameters
Several performance-related CICS system initialization parameters were changed in the CICS TS V5.2 release.
6.4.1 Maximum tasks (MXT)
The default value for the maximum tasks (MXT) system initialization parameter was changed to 250.
|
Note: The default MXT value is provided as a starting point when tuning a CICS system and does not represent an optimal configuration for all workloads. The MXT parameter must be configured according to the expected transaction throughput for the system.
|
You must ensure that enough storage is available to support the maximum number of tasks value. For more information about setting the MXT value, see the “Setting the maximum task specification (MXT)” topic in IBM Knowledge Center at this website:
CICS allocates several MVS workload manager (WLM) performance blocks (PBs) that are based on the current setting of the MXT parameter. Specifying an excessively large value for MXT can result in wasted use of local system queue area (LSQA) storage. Where many unused PBs exist, CPU cycles can be consumed unnecessarily by WLM because all blocks must be scanned to determine the status of the performance goal metrics.
6.4.2 Maximum open TCBs (MAXOPENTCBS)
The maximum open TCBs (MAXOPENTCBS) system initialization parameter was removed in CICS TS V5.1, but for tuning purposes is reinstated in the CICS TS V5.2 release. 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 MAXOPENTCBS 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:
|
Note: The minimum value for the MAXOPENTCBS parameter was increased to 32 in CICS TS V5.4.
|
6.4.3 Maximum XP TCBs (MAXXPTCBS)
The maximum XP TCBs (MAXXPTCBS) system initialization parameter was removed in CICS TS V5.1. However, it is reinstated in the CICS TS V5.2 release for tuning purposes. If the MAXXPTCBS parameter is not specified, CICS sets it automatically based on the current value of the MXT system initialization parameter. The value of MAXXPTCBS is calculated by using the same algorithm implemented in CICS TS V5.1, as shown in the following example:
MAXXPTCBS = MXT
For more information about the MAXXPTCBS parameter, see the “MAXXPTCBS” topic in IBM Knowledge Center at this website:
6.5 Enhanced instrumentation
The CICS TS V5.2 release continues the expansion of information that is reported by the CICS monitoring and statistics component. This section describes the extra fields that are now available in the CICS statistics SMF records.
6.5.1 Dispatcher global statistics
The following new fields were added to the collected dispatcher global statistics:
•Last excess TCB scan (field DSGLXSCN)
The date and time of the last CICS dispatcher excess MVS TCB scan.
•Last excess TCB scan - no TCB detached (field DSGLXSND)
The date and time of the last CICS dispatcher excess MVS TCB scan that did not detach any TCBs.
A sample DFHSTUP report that contains the new fields is shown in Example 6-1.
Example 6-1 Sample dispatcher global statistics report produced by CICS TS V5.2 DFHSTUP
Dispatcher Start Date and Time. . . . . . . : 05/16/2014 04:04:34.9633
Address Space CPU Time. . . . . . . . . . . : 00:00:29.882586
Address Space SRB Time. . . . . . . . . . . : 00:00:16.516442
Current number of dispatcher tasks. . . . . : 30
Peak number of dispatcher tasks . . . . . . : 75
Current ICV time (msec) . . . . . . . . . . : 1000
Current ICVR time (msec). . . . . . . . . . : 5000
Current ICVTSD time (msec). . . . . . . . . : 100
Current PRTYAGE time (msec) . . . . . . . . : 1000
Current MRO (QR) Batching (MROBTCH) value . : 1
Last Excess TCB Scan. . . . . . . . . . . . : 05/16/2014 05:28:10.1478
Number of Excess TCB Scans. . . . . . . . . : 1
Last Excess TCB Scan - No TCB Detached. . . : 05/16/2014 05:28:10.1478
Excess TCB Scans - No TCB Detached. . . . . : 1
Number of Excess TCBs Detached. . . . . . . : 0
Average Excess TCBs Detached per Scan . . . : 0
Number of CICS TCB MODEs. . . . . . . . . . : 18
Number of CICS TCB POOLs. . . . . . . . . . : 4
For more information about dispatcher global statistics, see the “Dispatcher domain: Global statistics” topic in IBM Knowledge Center at this website:
6.5.2 Dispatcher TCB mode statistics
The following new fields were added to the collected dispatcher TCB mode statistics:
•Dispatchable Queue – Current (field DSGTMCDQ)
The current number of dispatchable tasks that are queued for the TCB.
•Dispatchable Queue – Peak (field DSGTMPDQ)
The peak number of dispatchable tasks that were queued for the TCB.
•Dispatchable Queue – Average (field DSGTMADQ)
The average number of dispatchable tasks that were queued for the TCB.
A sample DFHSTUP report that contains the new fields is shown in Example 6-2. The new fields are presented in the final three columns for TCB modes where only one TCB exists.
Example 6-2 Sample dispatcher TCB mode statistics report produced by CICS TS V5.2 DFHSTUP
TCB TCB < TCBs Attached > <- TCBs In Use -> TCB <- Dispatchable Queue ->
Mode Open Pool Current Peak Current Peak Attaches Current Peak Average
________________________________________________________________________________________________
QR No N/A 1 1 1 1 0 1 27 1.12
RO No N/A 1 1 1 1 0 1 1 1.00
CO Unk N/A 0 0 0 0 0 0 0 0.00
SZ Unk N/A 0 0 0 0 0 0 0 0.00
RP Unk N/A 0 0 0 0 0 0 0 0.00
FO No N/A 1 1 1 1 0 0 0 0.00
SL No N/A 1 1 1 1 0 0 0 0.00
SO No N/A 1 1 1 1 0 0 0 0.00
SP No N/A 1 1 1 1 0 0 0 0.00
EP No N/A 2 2 2 2 0
TP Unk N/A 0 0 0 0 0
D2 Unk N/A 0 0 0 0 0
S8 Unk N/A 0 0 0 0 0
L8 Yes Open 1 1 0 1 0
L9 Unk N/A 0 0 0 0 0
X8 Unk N/A 0 0 0 0 0
X9 Unk N/A 0 0 0 0 0
T8 Unk N/A 0 0 0 0 0
________________________________________________________________________________________________
Totals 9 8 0
For more information about dispatcher TCB mode statistics, see the “Dispatcher domain: TCB Mode statistics” topic in IBM Knowledge Center at this website:
6.5.3 Dispatcher TCB pool statistics
The Time Max TCB Pool Limit last reached (field DSGLTCBL) field was added to the collected dispatcher TCB pool statistics. This field shows the time at which the pool reached the maximum TCB limit.
A sample fragment of DFHSTUP report that contains the new field is shown in Example 6-3.
Example 6-3 Sample dispatcher TCB pool statistics report produced by CICS TS V5.2 DFHSTUP
TCB Pool. . . . . . . . . . . . . . . . . . . . : OPEN
Current TCBs attached in this TCB Pool. . . . . : 170 ...
Peak TCBs attached in this TCB Pool . . . . . . : 170 ...
Max TCB Pool limit (MAXOPENTCBS). . . . . . . . : 170 ...
Time Max TCB Pool Limit last reached. . . . . . : 15:47:39.2782 ...
Total Requests delayed by Max TCB Pool Limit. . : 819 ...
Total Max TCB Pool Limit delay time . . . . . . : 00:01:57.2105 ...
Current Requests delayed by Max TCB Pool Limit. : 0 ...
Current Max TCB Pool Limit delay time . . . . . : 00:00:00.0000 ...
Peak Requests delayed by Max TCB Pool Limit . . : 67 ...
For more information about dispatcher TCB pool statistics, see the “Dispatcher domain: TCB Pool statistics” topic in IBM Knowledge Center at this website:
6.5.4 Monitoring domain global statistics
The following fields were added to the collected monitoring domain statistics:
•User transactions ended (field MNGUTNUM)
The number of user transactions that ended.
•System transactions ended (field MNGSTNUM)
The number of system transactions that ended.
•Time last user transaction attached (field MNGLUTAT)
The date and time of the last transaction attach processed by the monitoring domain.
•Time last user transaction ended (field MNGLUTCL)
The date and time at which the last transaction ended.
•MXT at last user transaction attach (field MNGMXUTA)
The current MXT value at the time of the last transaction attached.
•Current tasks at last attach (field MNGCAUTA)
The current number of user transactions that are attached in the region at the time of the last transaction attached.
•Average user transaction resp time (field MNGAUTRT)
The rolling average user transaction response time.
•Peak user transaction resp time (field MNGPUTRT)
The maximum user transaction response time.
•Peak user transaction resp time at (field MNGLUTRT)
The time stamp of the maximum user transaction response time.
A sample DFHSTUP report that shows the new statistics fields is shown in Example 6-4.
Example 6-4 Sample monitoring domain global statistics report produced by CICS TS V5.2 DFHSTUP
User transactions ended . . . . . . . : 905698
System transactions ended . . . . . . : 11
Time last user transaction attached . : 05/16/2014 05:28:43.5198 ...
Time last user transaction ended. . . : 05/16/2014 05:28:43.5215 ...
Average user transaction resp time. . : 00:00:00.001168
Peak user transaction resp time . . . : 00:00:00.104882
Peak user transaction resp time at. . : 05/16/2014 05:26:55.8512
... MXT at last user transaction attach . : 650
... Current tasks at last attach. . . . . : 8
For more information about monitoring domain statistics, see the topic “Monitoring domain: global statistics” in IBM Knowledge Center at this website:
The rolling average transaction response time is computed using the following equation:
6.5.5 Transaction manager global statistics
The following new fields were added to the collected transaction manager statistics:
•Time MAXTASKS last changed (field XMGLSMXT)
The date and time when MXT was last set or changed dynamically.
•Time last transaction attached (field XMGLTAT)
The date and time when the last user transaction was attached.
•Time the MAXTASKS limit last reached (field XMGLAMXT)
The date and time when the number of active user transactions last equaled MXT.
•Currently at MAXTASKS limit (field XMGATMXT)
Indicates whether the CICS region is at MXT.
A sample DFHSTUP report that contains the new fields is shown in Example 6-5.
Example 6-5 Sample transaction manager global statistics report fragment produced by CICS TS V5.2 DFHSTUP
Total number of transactions (user + system) : 19,274
Current MAXTASKS limit : 650
Time MAXTASKS last changed : 05/15/2014 12:20:16.9640
Current number of active user transactions : 1
Time last transaction attached : 05/15/2014 12:40:24.6738
Current number of MAXTASK queued user transactions : 0
Times the MAXTASKS limit reached : 7
Time the MAXTASKS limit last reached : 05/15/2014 12:34:21.7237
Currently at MAXTASKS limit : No
Peak number of MAXTASK queued user transactions : 164
Peak number of active user transactions : 650
Total number of active user transactions : 19232
Total number of MAXTASK delayed user transactions : 456
Total MAXTASK queuing time : 000-00:00:13
Total MAXTASK queuing time of currently queued user transactions : 00:00:00
For more information about transaction manager statistics, see the topic “Transaction manager: Global statistics” in IBM Knowledge Center at this website:
6.6 Kerberos
CICS TS V5.2 introduces support for Kerberos token validation. CICS TS supports Kerberos by using the external security manager (ESM). The level of support depends on the support that is provided by the ESM. If your ESM is RACF, support is based on Kerberos Version 5 and Generic Security Services (GSS).
CICS can verify a Kerberos token by configuring a service provider pipeline or by using the API command VERIFY TOKEN. An extract of a web service provider pipeline file that is configured to use Kerberos support is shown in Example 6-6.
Example 6-6 Extract of web services pipeline file configured for Kerberos support
<service_handler_list>
<wsse_handler>
<dfhwsse_configuration version="1">
<authentication trust="basic" mode="basic-kerberos"/>
</dfhwsse_configuration>
</wsse_handler>
</service_handler_list>
A sample invocation of the VERIFY TOKEN command that uses COBOL is shown in Example 6-7.
Example 6-7 Sample COBOL invocation of the VERIFY TOKEN command
EXEC CICS VERIFY TOKEN(WS-KERBEROS-TOKEN)
TOKENLEN(WS-LENGTH)
KERBEROS
BASE64
ESMREASON(WS-ESMREAS)
ESMRESP(WS-ESMRESP)
RESP(WS-RESP)
For more information about Kerberos support that is provided by CICS TS, see the topic “Kerberos support” in IBM Knowledge Center at this website:
6.6.1 Kerberos test configuration
A high-level topology diagram of the test application is shown in Figure 6-6.
Figure 6-6 Topology of Kerberos performance test application
A CICS requester region is used to create web services request messages. This requester region runs transactions that are started over LU2, where IBM Workload Simulator for z/OS (Workload Simulator) provides several simulated clients that can be configured to provide requests at a consistent, but adjustable transaction rate.
The transactions run in the requester region issue web services requests that are directed to an IBM WebSphere DataPower® Integration Appliance XI50 for zEnterprise.
The DataPower appliance requests a Kerberos token from a Kerberos key distribution center (KDC), which is hosted in z/OS. The Kerberos token is obtained by using information that is retrieved from RACF.
After a Kerberos token is obtained, it is inserted into the received web service request and the modified request is forwarded to the CICS web services provider region under test.
The CICS web services pipeline handler logic is configured to validate the Kerberos token by using the configuration that is shown in Example 6-7 on page 92. This pipeline processing involves the CICS provider region passing the received Kerberos token to RACF for validation.
After the Kerberos token is validated, control is passed to the user application in the CICS provider region with the received data supplied by using the CICS channels interface.
The user application performs a trivial processing operation and then returns the application response as binary data to the CICS web services pipeline in the DFHWS-DATA container. The web services pipeline converts the binary data response to a well-formed XML response that is returned to the DataPower appliance.
Finally, the DataPower appliance returns the web services response back to the CICS requester region.
6.6.2 Kerberos performance results
To verify the Kerberos token within the CICS provider pipeline, RACF calls the KDC to verify the token. Therefore, in addition to the CPU cycles that are consumed by the CICS provider address space, CPU cycles are consumed by the KDC address space. This publication focuses on the CICS overhead and does not account for this extra CPU overhead in the performance results.
Figure 6-7 plots the measured CPU consumption for a web service request rate, with and without a Kerberos token included in the message body.
Figure 6-7 Plot of CPU usage for web service workload with and without Kerberos token
6.6.3 Kerberos support conclusion
By using the data that is shown in Figure 6-7, you can see that processing a Kerberos token for each web service request added a burden of approximately 0.165 ms of CPU. This extra usage remained constant as the workload increased.
In this scenario, a maximum throughput of 410 web service requests per second was achieved with a Kerberos token, which is compared to over 500 requests per second without a token. This reduction in throughput was primarily due to usage involved with these processes:
•DataPower obtaining the Kerberos token
•CICS using RACF to verify the Kerberos token
6.7 JSON support
CICS TS V5.2 includes support for JSON data mapping, originally released as the CICS Transaction Server Feature Pack for Mobile Extensions V1.0. This support can be used by configuring a web service to use a JSON data stream, or by invoking the JSON transformer linkable interface y using the correct CICS container data structures. The JSON data mapping support is implemented in Java and uses a CICS JVM server that is configured with Axis2 services to provide the required runtime environment.
For more information about the use of the JSON support in a web services environment, see the topic “Getting started with JSON web services” in IBM Knowledge Center at this website:
For more information about the use of the JSON support as an API, see the topic “JSON transformer linkable interface containers” in IBM Knowledge Center at this website:
6.7.1 JSON support test configuration
The performance test application uses the pipeline interface to determine the cost per request of the JSON data mapping support.
A JSON request is accepted into the CICS provider region on a TCP/IP port by using the HTTP transport and is processed by the CICS pipeline handler mechanism. The pipeline handler transforms the received JSON payload into a binary data structure as defined by the COBOL copybook that is used when the bind files are created. The *.wsbind files are created by using the bottom-up approach of taking a language copybook and generating a JSON schema and wsbind file.
The pipeline transforms the JSON request payload into a binary data structure by using CICS supplied code that runs in a Java virtual machine (JVM). The converted binary data structure is passed to the user application as containers within a channel. When the user application is completed, the output binary data structure is converted back to a JSON response. The conversion process to a JSON data stream is again implemented as Java code that runs in a CICS JVM server. The use of this Java processing code is specified in the pipeline configuration file.
Example 6-8 shows sample input to the DFHCSDUP utility that is used to create the JVMSERVER CSD definition that is required for enabling JSON mapping services support.
Example 6-8 Sample JVMSERVER definition for JSON support
DEFINE JVMSERVER(JSONJVM)
GROUP(GJSON)
JVMPROFILE(DFHJVMAX)
THREADLIMIT(50)
The JVMSERVER name is referenced by the pipeline configuration XML file (see the sample XML configuration file in Example 6-13 on page 97). The definition references the JVM profile file named DFHJVMAX.jvmprofile. CICS determines the hierarchical file system (HFS) location of this file by using the JVMPROFILEDIR SIT parameter.
For more information about the attributes that are available on a JVMSERVER resource definition, see the topic “JVMSERVER attributes” in IBM Knowledge Center at this website:
The CICS supplied sample JVM profile file was amended to specify system-specific values for the JAVA_HOME and WORK_DIR parameters. The following parameters were also specified to fix the Java heap sizes to minimize variation in performance results:
•-Xmx400M
•-Xms400M
•-Xmnx120M
•-Xmns120M
•-Xmox280M
•-Xmos280M
A TCP/IP port was opened in CICS that was dedicated to the JSON endpoint. Example 6-9 shows sample input to the DFHCSDUP utility that was used to create the TCPIPSERVICE CSD definition that is required for opening a port in CICS.
Example 6-9 Sample TCPIPSERVICE definition for JSON support
DEFINE TCPIPSERVICE(JSONTCP1)
GROUP(GJSON)
PORTNUMBER(6000)
TRANSACTION(CWXN)
PROTOCOL(HTTP)
URM(DFHWBAAX)
IP(1.2.3.4)
BACKLOG(250)
The CWXN value for the TRANSACTION attribute specifies the transaction to run when an HTTP request is received on the TCP/IP port that matches the URIMAP pattern as specified in the construction of the *.wsbind files. Example 6-14 on page 98 shows an example of creating a *.wsbind file. The URM value of DFHWBAAX specifies the default HTTP analyzer program.
For more information about attributes that are available on a TCPIPSERVICE resource definition, see the topic “TCPIPSERVICE attributes” in IBM Knowledge Center at this website:
By default, work is accepted by the CSOL (socket listener) transaction, which starts a CWXN (web attach) transaction. The CWXN transaction then creates a CPIH (pipeline handler) transaction to process the request. For improved separation of work, you can use an alternative transaction ID rather than CPIH.
Example 6-10 shows an alternative transaction ID: JPIH. This alternative transaction ID provides the same functions as the CICS supplied CPIH transaction, but enables CPU cost from this JSON workload to be separated by filtering on transaction ID.
Example 6-10 Sample TRANSACTION definition for JSON support
DEFINE TRANSACTION(JPIH)
GROUP(GJSON)
PROGRAM(DFHPIDSH)
TRANCLASS(JSONTCLH)
SPURGE(YES)
TASKDATALOC(ANY)
DESCRIPTION(JSON HTTP inbound router)
A transaction class value of JSONTCLH is specified in Example 6-10 that is used to restrict the number of JPIH transactions that are attached at any one time within the CICS region.
Example 6-11 shows a sample definition for the JSONTCLH transaction class.
Example 6-11 Sample TRANCLASS definition for JSON support
DEFINE TRANCLASS(JSONTCLH)
GROUP(GJSON)
MAXACTIVE(100)
PURGETHRESH(NO)
A pipeline is configured in CICS by combining two definitions: The PIPELINE resource and an XML file in HFS.
Example 6-12 shows sample input to the DFHCSDUP utility that is used to create the PIPELINE CSD definition that is required to enable JSON mapping services support.
Example 6-12 Sample PIPELINE definition for JSON support
DEFINE PIPELINE(JSONPIP1)
GROUP(GJSON)
CONFIGFILE(/path/to/config/file/jsonjavaprovider.xml)
SHELF(/var/cicsts/myapplid/)
WSDIR(/wsdir_prefix/wsbind)
The CONFIGFILE attribute specifies a fully qualified HFS file name for the XML configuration file. The SHELF attribute indicates the HFS directory that contains the in-use wsbind files. The WSDIR attribute indicates the HFS directory that contains the *.wsbind files that are used to determine the mapping between JSON and the native data structures.
For more information about the attributes that are available on a PIPELINE resource definition, see the topic “PIPELINE attributes” in IBM Knowledge Center at this website:
Example 6-13 shows the pipeline XML configuration file that was used in the test application. By using the resource definition in Example 6-12, the following fully qualified XML configuration file name is available:
/path/to/config/file/jsonjavaprovider.xml
Example 6-13 Sample pipeline configuration file to use JSON data mapping support
<?xml version="1.0" encoding="EBCDIC-CP-US"?>
<provider_pipeline xmlns="http://www.ibm.com/software/htp/cics/pipeline">
<service>
<terminal_handler>
<cics_json_handler_java>
<jvmserver>JSONJVM</jvmserver>
</cics_json_handler_java>
</terminal_handler>
</service>
<apphandler_class>com.ibm.cicsts.axis2.CICSAxis2ApplicationHandler</apphandler_class>
</provider_pipeline>
The JSON handler is configured to use the CICS JVMSERVER resource named JSONJVM as defined in Example 6-8 on page 95. A sample XML configuration file for the JSON pipeline handler is supplied in the following location relative to the CICS installation root directory:
./samples/pipelines/jsonjavaprovider.xml
As described in 6.7.1, “JSON support test configuration” on page 95, the wsbind files were generated by using a bottom-up approach. A copybook was used to generate the wsbind and JSON schema files.
Example 6-14 shows a snippet of the JCL that runs the DFHLS2JS utility to generate one of the wsbind files.
Example 6-14 Extract of JCL used to generate wsbind files
//CABASIC EXEC DFHLS2JS,
// JAVADIR='java6_31/J6.0',
// USSDIR='cics690',
// PATHPREF='',
// TMPDIR='/tmp',
// TMPFILE='LS2JS'
//INPUT.SYSUT1 DD *
JSON-SCHEMA-REQUEST=/schema_path/CABASIC-req.schema
JSON-SCHEMA-RESPONSE=/schema_path/CABASIC-resp.schema
LANG=COBOL
LOGFILE=/log_path/LS2JS_CABASIC.log
MAPPING-LEVEL=3.0
PDSLIB=hlq.COPY <- PDS containing COPY members
PGMINT=COMMAREA <- Application interface
PGMNAME=CABASIC <- Program name to invoke
REQMEM=BASICQ <- COPY member for request structure
RESPMEM=BASICP <- COPY member for response structure
TRANSACTION=JPIH <- Pipeline transaction
URI=JSON/CABASIC <- PATH attribute of generated URIMAP
WSBIND=/wsbind_path/CABASIC.wsbind <- Output wsbind file
/*
For more information about the use of the DFHLS2JS utility and the input parameters, see the topic “DFHLS2JS: High-level language to JSON schema conversion for request-response services” in IBM Knowledge Center at this website:
The receiving CICS region used the channel interface to communicate with a COBOL back-end application. The application contained no business logic and generated only a trivial response. The use of a minimal back-end program enables you to understand the base cost of processing a JSON request in a CICS region.
The inbound request contains 32 bytes of application data, which corresponds to 180 bytes of JSON.
Example 6-15 shows a sample JSON request. Formatting is added for clarity; the request as received by CICS does not contain white space.
Example 6-15 Sample JSON input for mobile workload
{
"CABASICOperation" : {
"count_in" : 32,
"count_out": 1
}
}
The request JSON is produced to populate the input fields that match with the COBOL copybook that is shown in Example 6-16.
Example 6-16 Sample COBOL copybook for mobile workload request
05 COUNT-IN PIC 9(8) COMP-4.
05 COUNT-OUT PIC 9(8) COMP-4.
05 FILLER PIC X(24).
The application request can result in one of the following four possible responses:
•32 bytes of user data (103 bytes of JSON)
•1,024 bytes of user data (1,638 bytes of JSON)
•4,096 bytes of user data (6,342 bytes of JSON)
•16,384 bytes of user data (25,159 bytes of JSON)
Multiple response sizes were achieved by creating multiple endpoints. The endpoints were defined by creating four different wsbind files: One for each of the possible response sizes. The four wsbind files were created by using multiple invocations of the DFHLS2JS utility, each specifying a different copybook for the RESPMEM parameter.
Example 6-17 shows a fragment of a sample JSON response. Formatting is added for readability; to reduce data transmission burden, the response that is generated by CICS does not contain white spaces.
Example 6-17 Sample fragment of JSON response
{
"CABASICOperationResponse":{
"recv_size":32,
"send_size":1024,
"taskid":44,
"tranid":JPIH,
"user_data":[
{"user_data":"0001-ABCDEFGHIJKLMNOPQRSTUVWXYZ-"},
{"user_data":"0002-ABCDEFGHIJKLMNOPQRSTUVWXYZ-"},
…
{"user_data":"0031-ABCDEFGHIJKLMNOPQRSTUVWXYZ-"}
]
}
}
The JSON response in Example 6-17 represents a response size of 1 KB of user data. Several lines of response were omitted for clarity. The corresponding copybook is shown in Example 6-18.
Example 6-18 Sample COBOL copybook for response
05 RECV-SIZE PIC 9(8) COMP-4.
05 SEND-SIZE PIC 9(8) COMP-4.
05 TASKID PIC 9(8) COMP-4.
05 TRANID PIC X(4).
05 FILLER PIC X(16).
05 USER-DATA PIC X(32) OCCURS 31 TIMES.
The varying response size was achieved by having multiple copybooks, where the OCCURS clause for the USER-DATA field was updated to reflect the required size of response.
6.7.2 Scalability as a function of response size
To determine the scalability of the JSON pipeline handler as the payload increases, the workload was run by using a range of response sizes. As described in 6.7.1, “JSON support test configuration” on page 95, the input request message consisted of 32 bytes of user data, which corresponds to 180 bytes of JSON data.
The workload ran at a rate of approximately 290 requests per second, with the response size that varied from 32 bytes to 16 KB of user data. Overall CPU consumption figures are taken from RMF data and are listed in Table 6-11. The “GCP cost” values represent work that is not eligible for offload, and “zIIP cost” values represent workload that is eligible for offload to a specialty engine.
Table 6-11 Average CPU cost per request as response size increases
|
Response size
|
GCP cost (ms)
|
zIIP cost (ms)
|
Total (ms)
|
|
32 bytes
|
0.529
|
0.084
|
0.613
|
|
1 KB
|
0.627
|
0.245
|
0.872
|
|
4 KB
|
0.619
|
0.907
|
1.525
|
|
16 KB
|
0.643
|
3.988
|
4.630
|
The data in Table 6-11 is plotted in Figure 6-8 on page 101.
Figure 6-8 Plot of CP cost per request against response size
As the response size increases, the non-zIIP-eligible CP usage remains constant. It is also clear that as the response size increases, the zIIP-eligible CP usage increases linearly.
6.7.3 Scalability as a function of request rate
To determine the scalability of the JSON pipeline handler as throughput increases, the workload was run with a range of inbound request rates. As described in 6.7.1, “JSON support test configuration” on page 95, the input request consisted of 32 bytes of user data, which corresponds to 180 bytes of JSON data.
The workload used the 1 KB of user data response size configuration (a response of 1,638 bytes of JSON), and the request rate varied from approximately 300 - 3,300 requests per second. Overall CPU consumption figures are taken from RMF data and are listed in Table 6-12. The “% of single general CP” values represent work that is not eligible for offload, and “% of single zIIP” values represent workload that is eligible for offload to a specialty engine.
Table 6-12 CP utilization as a function of request rate
|
Requests per second
|
% of single general CP
|
% of single zIIP
|
|
334.36
|
19.69%
|
6.55%
|
|
499.66
|
29.52%
|
9.13%
|
|
999.77
|
59.48%
|
17.56%
|
|
1995.16
|
118.68%
|
34.62%
|
|
3315.31
|
196.36%
|
70.20%
|
The values in Table 6-12 are plotted Figure 6-9 on page 102.
Figure 6-9 Plot of total GCP and zIIP usage against request rate
The straight lines for GCP and zIIP usage demonstrate linear scalability of CPU usage in the workload. The ratio of non-eligible to eligible CPU consumption remains constant as the transaction rate increases.
6.7.4 JSON support conclusion
Section 6.7.2, “Scalability as a function of response size” demonstrated good scalability of the JSON support functions as payload size increases. Section 6.7.3, “Scalability as a function of request rate” demonstrated good scalability as transaction rate increased.
The experience that was gained while performance testing the JSON support infrastructure showed that performance tuning and monitoring of the JSON support functions is a similar process to managing an HTTP XML web services workload within CICS. Many of the resources that are required serve the same purpose in SOAP over HTTP and JSON over HTTP configurations, with only minor differences in resource definitions observed.
One final observation is related to the situation where it is wanted to throttle work arriving in the JVM server. When measuring CPU consumption, adding the pipeline handler transaction (JPIH) to a transaction class was slightly more efficient than the use of the THREADLIMIT attribute of the JVMSERVER resource.
6.8 Java applications and trace
During the CICS V5.2 development cycle, a review of all the trace points in the direct to CICS domain resulted in many of these trace points moving from level 1 to level 2 trace. As a consequence of these changes, the performance of a Java application is improved when running CICS with default level 1 trace enabled.
The first workload that was used to demonstrate the performance improvements is the CICS Hello World Java sample. This simple application is started at a console and echoes back a simple string to confirm that execution completed successfully.
For more information about the use of the Hello World Java sample application, see the topic “Running the Hello World examples” in IBM Knowledge Center at this website:
The second workload that was used to demonstrate these performance improvements is a Java application that issues 120 file read operations by using the JCICS interface.
Figure 6-10 plots the CPU cost per transaction of the simple Hello World Java workload in the following configurations:
•CICS TS V5.1 with trace disabled
•CICS TS V5.1 with default level 1 trace enabled
•CICS TS V5.2 with default level 1 trace enabled
Figure 6-10 Plot of CPU per transaction for the Hello world Java workload
Figure 6-10 shows a clear reduction in CPU consumption in CICS TS V5.2 when compared to the same configuration that uses CICS TS V5.1. The same three configurations were studied for the file read Java workload, with the results shown in Figure 6-11 on page 104.
Figure 6-11 Plot of CPU per transaction for the file read Java workload
As with the Hello World Java workload, there is a clear reduction in CPU consumption per transaction when CICS TS V5.2 is used. The results of both of these workloads are listed in Table 6-13.
Table 6-13 Summary of CPU cost per transaction with varying trace and release configurations
|
Workload
|
V5.1 no trace
|
V5.1 default trace
|
V5.2 default trace
|
|
Hello world
|
0.19 ms
|
0.33 ms
|
0.23 ms
|
|
File read
|
1.05 ms
|
4.27 ms
|
1.43 ms
|
Most Java workloads that run with trace enabled in CICS TS V5.1 see a reduction in CPU when upgrading to CICS TS V5.2.
In CICS TS V5.2, enabling trace for a Java application results in a CPU overhead that is approximately equal to the CPU overhead that is incurred by enabling trace for an equivalent non Java application.
6.9 Web services over HTTP improvements
Performance improvements were delivered in CICS TS V5.2 for the scenario where CICS acts as a web services provider for HTTP requests. The improvements are a reduction in real storage usage and a reduction in CPU usage. This section quantifies the performance benefits by using sample workloads.
6.9.1 Web services real storage usage
For every inbound web service request, the amount of real storage that is used was reduced significantly. This reduction in real storage is manifested as a reduction in 31-bit virtual storage usage. Increased efficiency in the code page conversion processing reduces the amount of storage that is required, which enables CICS regions to process many concurrent requests.
Figure 6-12 shows the amount of 31-bit virtual storage that is used by a 1 MB web service request into CICS.
Figure 6-12 Storage usage for a 1 MB web service request with CICS as a provider
This reduction in storage usage can enable a CICS region to process a higher request rate for a specific configuration, or it might allow a consolidation exercise that reduces the number of CICS regions that are required to satisfy a workload.
6.9.2 Web services CPU reduction
For inbound requests into CICS as an HTTP web services provider, the number of TCB change mode operations that are required to fulfil the request was reduced. This reduction in TCB change mode operations provides a small performance gain in CPU for most workloads.
Three XML web services were configured to accept requests that consisted of a single XML element of 8 bytes, 32 KB, or 256 KB. The provider application returned a single 8-byte XML element as a response.
The total cost to process the web service request was calculated by using RMF data, which includes the CSOL, CWXN, and CPIH transactions.The results are shown in Figure 6-13.
Figure 6-13 CPU cost per request for varying request sizes
For the largest message sizes, a small reduction in CPU cost per request is observed. The CPU costs for smaller message sizes remain equivalent when comparing CICS TS V5.1 with V5.2.
6.10 Java 7.0 and Java 7.1
By using the same workload and methodology that is described in 6.2.5, “Java servlet that uses JDBC and VSAM” on page 83, the performance of Java 7.0 and Java 7.1 was compared. For both scenarios, CICS TS V5.2 was used with Java 7.0 SR7 or Java 7.1 SR1.
Table 6-14 on page 107 lists the performance measurements when running the workload with Java 7.0 SR7.
|
Note: APAR PI52819 enables support for Java 8 in CICS TS V5.2.
|
Table 6-14 Java 7.0 SR7 results for the Java servlet JDBC and VSAM workload
|
ETR
|
CICS CPU
|
CPU per request (ms)
|
||
|
Not zIIP-eligible
|
zIIP-eligible
|
Total
|
||
|
200
|
20.82%
|
29.42%
|
50.24%
|
2.512
|
|
400
|
42.34%
|
60.12%
|
102.46%
|
2.562
|
|
800
|
86.46%
|
120.38%
|
206.85%
|
2.586
|
Table 6-15 lists the performance measurements when running the workload with Java SR1.
Table 6-15 Java 7.1 SR1 results for the Java servlet JDBC and VSAM workload
|
ETR
|
CICS CPU
|
CPU per request (ms)
|
||
|
Not zIIP-eligible
|
zIIP-eligible
|
Total
|
||
|
200
|
21.44%
|
29.70%
|
51.15%
|
2.558
|
|
400
|
43.55%
|
61.13%
|
104.68%
|
2.617
|
|
800
|
88.95%
|
124.12%
|
213.07%
|
2.663
|
Figure 6-14 Plot of Java 7.0 and Java 7.1 performance results for JDBC and VSAM workload
For this workload, Java 7.0 delivers slightly better performance than Java 7.1, which provides a decrease of approximately 2% in terms of CPU usage per transaction.
It can be observed that Java 7.1 provides the same linear scaling characteristics as demonstrated by the Java 7.0 run time.
..................Content has been hidden....................
You can't read the all page of ebook, please click here login for view all page.