Removal of unnecessary processing

This section describes HCL Workload Automation for Z 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 HCL Workload Automation for Z 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 HCL Workload Automation for Z, 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 HCL Workload Automation for Z 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, the tracker, and the TCP/IP server contains further recommendations more specific to either the tracker or the controller, many of which also result in the removal of unnecessary processing.