• Current Issue
• About MeasureIT
• Article Database
• Industry Articles
• Submit an Article
• Submit a Letter to the Editor
• Contact Us
• Subscribe
• Unsubscribe

z/OS Version 1.11 and CICS Version 4.1 News and “Oldies but Goodies” for Performance Managers and Capacity Planners

November, 2009
by Ivan Gelb

About the Author

[an error occurred while processing this directive]

The new versions of z/OS and CICS contain a number of items of particular interest to performance managers and capacity planners. These items are the main focus of this article. Also included are the most important items and top recommendations which should be actively considered by z/OS mainframe shops. We plan a similar future article with focus on DB2 Version 9. Readers can "expedite" when the DB2 article is published by expressing their interest to the Measure IT editors.

New in z/OS 1.11

• Option in SYS1.PARLMIB IEASYSxx member: ZAAPZIIP=YES
  Allows System z Application Assist Processor (zAAP) eligible work to run on a System z9 and z10 Integrated Information Processor (zIIP). Enables offloading Java work from the general purpose processors (CPs) when not enough of such work is present to justify purchase of a zAAP. This option is described as "zAAP on zIIP" in the relevant literature.
  With ZAAPZIIP=YES, all the zAAP eligible usage shows up only as zIIP utilization. For effective support of performance management and capacity planning (PM&CP) activities, customers will have to devise ways of measuring how much of the zIIPs is the zAAP eligible work consuming.
• Service units' fields in the SMF records are increased in length to prevent them from wrapping. This addresses the reporting and chargeback problem caused by the time based measurement fields reporting zero on the z10 processor due to rounding of the measurements. Change is recommended from time based to the use service units based measurement fields for all the CP&PM activities.
• New RMF Monitor II OPT Settings report which displays information about the active IEAOPTxx SYS1.PARMLIB member and the settings of all OPT parameters.
• Frame and Slot Counts section of the RMF Postprocessor Paging Activity report now provides measurements about real storage requests and page faults. This is most useful for determining the pain caused by paging and sizing the real storage on a processor.
• Enhanced RMF group capacity reporting via the Partition Data Report display of the long term average capacity which is not used by members of the group but would be allowed by the defined limit.
• RMF Group Capacity Report's new CAPPING ACT% displays how much capping really limited the processor usage. This is in addition to the old CAPPING WLM% column which indicates to what extent the partition is subject to capping.
• RMF Postprocessor can now generate the following reports in XML format: CPU, CRYPTO, ESS, FCD, OMVS and Overview Report.
  
  Remember that with the free RMF Spreadsheet Reporter, downloadable from IBM, you can also request the reports in XML format for display in a web browser.

z/OS "oldies but goodies"

Review the following options, shown in alphabetic order, in the SYS1.PARMLIB IEAOPTxx member:

• INITIMP=option where option is either 0, 1, 2, 3, or E. Effective use of this option is required to insure that the performance of critical workloads is protected from lower importance and non-critical workloads. If INITIMP is not coded, all of the initiators will run at priority of 254. The options are:
  
  
  • 0 - The initiator dispatching priority is set to 254. Not a recommended option.
  • 1, 2, or 3 - Forces the initiator dispatching priority to be lower than the dispatching priority for CPU critical work with the same or a higher importance level. One of these options combined with an effective WLM (Workload Manager) service policy is the recommended selection.
  • E - The dispatching priority is calculated dynamically to ensure access to the processor. There is no guarantee that CPU critical work will always have a higher dispatching priority. Not a recommended option.
• HIPERDISPATCH=YES/NO  NO is the default. YES option can benefit some and hurt the performance other installation.
  
  When HiperDispatch helps, it improves the ITR (Internal Throughput Rate). A simple recommendation can not be made. Your system's performance will vary based on many factors such as: number of physical CPs, number of LPARs (Logical Partitions), number of logical CPs defined, and the effective memory working set size of your applications. Best/worst example is the working set size because it can produce poor results regardless of the HIPERDISPATCH setting
• IFAHONORPRIORITY=YES/NO (YES is default) The YES option allows CPs to help zAAPs if they indicate that they need help. NO prevents CPs from running zAAPs eligible work. The NO option should be considered because it may reduce the CP capacity requirements which in turn decrease total hardware and software costs.
• IIPHONORPRIORITY=YES/NO (YES is default) The YES option allows CPs to help zIIPs if they indicate that they need help. NO prevents CPs from running zIIPs eligible work. The NO option should be considered because it may reduce the CP capacity requirements which in turn decrease total hardware and software costs.
• PROJECTCPU=YES enables collection of zAAP and zIIP utilization projections before they are acquired. This is clearly the most important option for the sizing of the initial specialty processor acquisition.

Additional items to consider:

• The free IBM zPCR capacity planning tool is a "must do" for any capacity planning exercise. It is very good at predicting the ITR (Internal Throughput Rate) of various processor models and LPAR configurations as long as your workloads fit the profiles of the workloads IBM uses to determine the capacity and performance of new hardware and software releases.
• DB2 parallelism and zIIPs can yield hardware and software cost savings.
  Once the threshold of 100 milliseconds (ms) per query is reached, all child tasks become zIIP eligible. CPU time of parent and child tasks count towards the 100 ms. Parents are not eligible for running on zIIPs. CICS, IMS, TSO and batch DB2 work can all use zIIPs.
• z10 CPU Measurement Facility available on z10 GA2 generates SMF 113 subtype 2 records. IBM announcement states that future uses include: better workload characterization, ISV (Independent Software Vendor) product improvements, and application tuning. Functionality is delivered via new z/OS Hardware Instrumentation Facility (HIS... yes HIS... not HIF as we might expect).
• SMF type 23 records contain detailed workload profiling data. Help IBM help you. Provide your type 23 records for their analysis. These records do not contain any fields which may raise concerns about the privacy of your data. IBM needs this information to improve the workload mix selection for the LSPR and zPCR generated numbers.

New in CICS 4.1

• Monitor Control Table (MCT) has had the options to exclude unused CMF (CICS Measurement Facility) record segments and to compress the collected SMF type 110 records. Potential savings is in the range of 50 - 90% less data logged! Compression is the new default with CICS 4.1.
  
  While the data compression alone may achieve impressive savings, the exclusion of unused record segments via CICS region-specific MCTs is highly recommended for shops where CICS regions interact with a multitude of other products like DB2, IMS, MQ, and WebSphere.
• Throughput improved via more efficient workload management with Sysplex optimized workload routing enabled at the z/OS Coupling Facility (CF).
  
  We can monitor distribution of dynamic workloads through CICSplex via new CPSM (CICSPlex System Manager) WUI (Web Interface) views. Load value, including all tasks, and health status for a CICS region is broadcast with basic health status.
  
  CICSplex SM uses data in CF to make dynamic routing decisions. Target regions' refresh interval for their data in CF is between 1 ms and up to 2 seconds. Default is 200ms. Smaller refresh values may increase CF utilization without improvements in the "quality" of decisions.
• New support for z/OS Workload Manager (WLM) service policy specified percentile goals in addition to the prior support of average response time goals.
  CICSplex SM optimizes response times by routing to region it deems most likely to meet goals.

CICS "oldies but goodies"

• Determine if CICS regions which were cloned simply because of the QR (Quasi-reentrant) TCB saturation can now be put back together.
  
  Initial QR TCB offload arrived to us many years ago when the DB2 processing for a CICS transaction was offloaded to a separate pool of L8 TCBs. In the latest CICS versions, much of the CICS systems code became threadsafe and eligible to run on the new pool of TCBs.
  
  By collapsing your applications into the fewest possible production regions, processor savings in the range of 15 - 40% can be achieved without changing anything else. We have encountered a saving of over 50% at one site.

• WLM CICS service classes should be based on percentile response time goals for best utilization of available resources and protection of CICS SLAs (Service Level Agreements).
  
  Least effective are the velocity based goals since they guarantee nothing that we can easily and objectively measure.
  
  Average response time goals can also work fine but require more ongoing reviews and possible adjustments to maintain their effectiveness.
• CICS System Initialization Table (SIT), also know as DFHSIT, option INTERVAL(hhmmss) default is 3 hours.
  
  Modify default to match the RMF - SMF data collection interval's duration or be a multiple of it. This option has same use as DFHSIT STATINT.
  Proper setting is required for effective analysis of resource utilization statistics collected by SMF-RMF in conjunction with the CICS collected statistics.
• Modify SIT option ENDOFDAY(hhmmss) from default = 000000
  
  Modify default to eliminate chance of performance problems at every midnight when all the regions with the default value will produce their end-of-day statistics.
  Same use as DFHSIT STATEOD.
  Offsetting ENDOFDAY by just a few seconds for limited groups of regions is the recommended solution for this often found problem.
• 4 - 12% of the total CPU/CICS region can be saved if response time reporting based CMF transaction level records is replaced with RMF only reports. We recommend the selective collection of transaction level details rather than the complete elimination. Such selective collection should be employed to establish the resource utilization profile of most of the transactions.
  This activity has to be combined with effective service and report classes specified in the WLM service policy. Well defined report classes can enable early detection in the resources a transaction consumes before such changes create problems.

In closing, we hope you found this article useful. You questions, comments and wishes for future article topics are invited and appreciated. Please send your feedback directly to ivan@gelbis.com and/or to the MeasureIT staff.

References

z/OS 1.11 Information center found at: http://publib.boulder.ibm.com/infocenter/zos/v1r11/index.jsp

CICS 4.1 Information center found at: https://publib.boulder.ibm.com/infocenter/cicsts/v4r1/index.jsp

Disclaimer

All of the information in this document is tried and true. However, this fact alone cannot guarantee that you can get the same results at your place. In fact, some of this advice can be hurtful if it is misused and misunderstood. Anyone attempting to adapt these recommendations to their own environments does so completely at their own risk.