I/O activity

Input/output operations are generally the most significant factor in any performance equation. A reduction of I/O, either real or physical, often generates the most significant payback in any tuning exercise.

Many techniques are available to both eliminate I/O and to achieve optimum performance for physical I/O. Some of those techniques are discussed in this book. If you have a very high workload, consider any performance enhancing options, either hardware or software, available to you. However, we recommend you do not use software that alters the physical organization of a data set, because this can have detrimental effects on your IBM Tivoli Workload Scheduler for z/OS data and availability.

The number of real I/Os can be reduced by removing any unnecessary processing and modifying VSAM cluster definitions.

Performance of physical I/Os can be optimized by utilization of DASD hardware facilities.

The duration of a physical I/O is very dependent on the performance of the I/O subsystem, which is influenced greatly by careful placement of data to reduce channel, path, and control unit contention.

Removal of unnecessary processing

This section describes IBM Tivoli Workload Scheduler for z/OS functions that can cause unnecessarily high processing, with little or no benefit, when not used in the intended manner.

• Alerts, specifically ALERT(LATEOPER) when the deadlines and estimated durations of the operations are not accurate. This can cause a massive number of I/Os against the current plan and affects most other IBM Tivoli Workload Scheduler for z/OS functions because the current plan lock is held exclusively for the duration of the scan for late operations. The workstation analyzer (WSA) subtask performs this scan every two minutes. When a large percentage of the plan is late, many operation records must be retrieved.
• Poorly defined security environment. AUTHDEF definitions for subresources which have no rules cause FRACHECKs to be sent across the SAF interface only to be essentially ignored by the security system. Be sure to define only subresource names on the AUTHDEF statement for which resource rules actually exist.
• Too frequent current plan or JCL repository backups. CP backups are probably too frequent if there is more than 1 every 20 minutes during the peak processing period. Most installations do not require more than one JCL repository backup per day. If an optimum value cannot be found for the BACKUP or MAXJSFILE keywords to achieve the backup frequency required, consider defining NO as the value and scheduling the backups using the BACKUP command, EQQEVPGM, EQQUSIN, or the EQQUSINB subroutine.
• Unnecessary scanning of all JCL submitted. If you use the input tailoring facilities provided by IBM Tivoli Workload Scheduler for z/OS, be sure to use VARSUB(SCAN) rather than VARSUB(YES) on the OPCOPTS initialization statement if performance is important and less than 70% of submitted operations have input tailored by IBM Tivoli Workload Scheduler for z/OS at submit time.
• Do not use the job-completion checker (JCC) function to reset acceptable nonzero return codes. The NOERROR initialization statement is a much more efficient and much safer alternative. Additionally, z/OS provides functions to fail a job with a JCL error at step termination if a not cataloged x condition is detected, thereby removing the requirement to use JCC to detect such conditions.
• Audit functions. AUDIT with AMOUNT(DATA) causes a large increase in I/O, and a significant amount of DASD space, on the job-tracking logs. If the actual changed record is not required, then consider auditing with AMOUNT(KEY). Multiple audit statements are supported, thereby allowing you to define some files with AMOUNT(DATA) and others with AMOUNT(KEY).
• Consider GETMAINing and FREEMAINing storage for user exits in EQQUX000, the subsystem start-stop exit, rather than getting and freeing on each call.
• Delay retrieval of job logs until a dialog user has requested to browse a job log for non z/OS® trackers.

Tuning the controller and the tracker contains further recommendations more specific to either the tracker or the controller, many of which also result in the removal of unnecessary processing.

VSAM cluster definitions

The IBM Tivoli Workload Scheduler for z/OS databases and plans are stored in VSAM KSDS clusters. Default cluster definitions provided with IBM Tivoli Workload Scheduler for z/OS do not consider the I/O performance to the clusters. While changes to the cluster definitions can provide significant performance improvements, such changes cost either in additional storage usage by the controller address space or by increased DASD space.

Consider these performance recommendations:

• Use the IMBED and REPLICATE options if the clusters are not behind CACHE.

  IMBED specifies that the sequence-set record for each control area is written as many times as it fits on the first track adjacent to the control area. If the allocation is less than a cylinder, one track is added to the primary and secondary allocation quantities.

  REPLICATE specifies that each index record is to be written on a track as many times as it fits. With REPLICATE, rotational delay is reduced and performance is improved. But the cluster's index usually requires more direct access device space.

• |Define some free space on clusters that have |significant insert activity, particularly the JCL repository (EQQJS1DS |and EQQJS2DS), which requires at least FREESPACE(20, 20). Consider a free space allocation for the current plan |(EQQCP1DS, EQQCP2DS, EQQCXDS, EQQNCPDS, and EQQSCPDS), extended data |(EQQXD1DS, EQQXD2DS, and EQQNXDDS), application descriptions (EQQADDS), |resource descriptions (EQQRDDS), and operator instructions (EQQOIDS). |

  FREESPACE(CI-percent, |CA-percent) specifies the percentage of each control interval |and control area that is to be set aside as free space when the cluster |is initially loaded, during a mass insert, and after any split of |control intervals (CI-percent) and control areas (CA-percent). Empty |space in the control interval and control area is available for data |records that are updated and inserted after the cluster is initially |loaded. CI-percent translates into a number of bytes that is equal |to or slightly less than the percentage value of CI-percent. CA-percent |translates into a number of control intervals that is equal to or |less than the percentage value of CA-percent.

  |

  CI-percent |and CA-percent must be equal to or less than 100. When you specify FREESPACE(100 |100), one data record is placed in each control interval used |for data and one control interval in each control area is used for |data (that is, one data record is stored in each control area when |the data set is loaded). When no FREESPACE value is coded, |the default specifies that no free space be reserved when the data |set is loaded.

  |

  When you define the cluster using the RECORDS |parameter, the amount of free space specified is not taken into consideration |in the calculations to determine primary allocation.

• Allocate more buffers on clusters that do not have LSR buffering.

  BUFFERSPACE specifies the minimum space to be provided for buffers. The buffer space size you specify helps VSAM determine the data component's and index component's control interval size. If BUFFERSPACE is not coded VSAM attempts to get enough space to contain two data component control intervals and one index component control interval. Try to have one buffer for each index CA, plus one extra.

• If you do not require SPANNED support, do not allocate the cluster with the spanned attribute. By default, EQQADDS, EQQLTDS, and EQQLDDS are spanned clusters.

  SPANNED specifies that if the maximum length of a data record (as specified with RECORDSIZE) is larger than a control interval, the record is contained on more than one control interval. This allows VSAM to select a control interval size that is optimum for the direct access device.

  When a data record that is larger than a control interval is put into a cluster that allows spanned records, the first part of the record completely fills a control interval. Subsequent control intervals are filled until the record is written into the cluster. Unused space in the record's last control interval is not available to contain other data records.

  Spanning a cluster causes the number of physical I/Os to be dramatically increased. If you must define a cluster with the spanned attribute and performance is important, consider using CACHE and DASD-FAST-WRITE for these clusters.

• Specify at least AMP=('BUFND=5,BUFNI=5') in the IBM Tivoli Workload Scheduler for z/OS JCL procedure for the controller on the EQQCPxDS and EQQJSxDS ddnames. CP and JS copies are NSR, they run faster with additional buffers.

Data set placement

Place your key IBM Tivoli Workload Scheduler for z/OS data sets on volumes that minimize contention for the volumes on their controllers.

Carefully consider the placement of these performance critical data sets:

• Current® plan data sets (EQQCP1DS, EQQCP2DS, and EQQCXDS)
• Current plan side-information (EQQSIDS)
• Event data sets (EQQEVDS)
• Submit/release data sets (EQQSUDS)
• JCL repository (EQQJS1DS and EQQJS2DS)
• Job-tracking logs (EQQJTnn and EQQJTARC)
• JCL variable tables when job input tailoring is used (EQQADDS).

Hardware performance options

Use CACHE and DASD-FAST-WRITE if you can for the files recommended below. While these facilities do not reduce the number of EXCPs, they can sharply reduce the time it takes to complete them. CACHE and DASD-FAST-WRITE can be important ways to reduce enqueue contention for two reasons. First, DASD-FAST-WRITE can reduce the write times. VSAM buffering, of course, only reduces the read times, and that can make write-time reductions even more important. Second, both CACHE and DASD-FAST-WRITE are effective on spanned records.

CACHE

Appropriate for all files except the job-tracking logs. The best candidates are:

• The long-term plan (EQQLTDS)
• Operator instructions (EQQOIDS)
• Application descriptions and JCL variable tables (EQQADDS)
• The JCL libraries (EQQJBLIB)
• Event data sets (EQQEVDS), but only when an event reader task has been started using the ERDRTASK keyword on the OPCOPTS initialization statement.

DASD-FAST-WRITE

Suitable for all files. The best candidates are:

• The job-tracking logs (EQQJTnn)
• Submit/release data sets (EQQSUDS)
• The JCL repository (EQQJS1DS and EQQJS2DS)
• Event data sets (EQQEVDS)
• Current plan data sets (EQQCP1DS and EQQCP2DS).

If you submit a very high number of computer operations every day (greater than 50 000) and you have solid-state devices, consider placing the JCL repository (EQQJS1DS and EQQJS2DS) and any submit/release data sets (EQQSUDS) on such devices.