Optimized Workload Benefits
If the topology of a CICSplex is such that regions in a workload can be managed by the same CMAS, then the perceived benefit won’t be so great. If most of the dynamic routing traffic flows through the DTRPGM exit, the benefit won’t be particularly high. If target regions in a workload execute a high proportion of non-dynamic throughput, the benefit of implementing an optimized workload is stronger.
Benefits of running workloads in optimized state should become clear fairly quickly for a workload comprised of routers and targets managed by different CMASs where the bulk of the dynamic traffic flows through the DSRTPGM exit—especially for transactional input that’s generated by dynamic CICS STARTs. No workload batching should occur. An effect of this will be that the overall workload should run through faster because fewer (if any) routed transactions would be waiting in the queue of a CICS region already at its MAXTASK limit.
When your CICSplex extends beyond the scope of your Sysplex, there’s little benefit to optimized workload routing. Typically, this would occur when routers and targets are physically remote from each other. In those situations, the isolated coupling facilities can’t be linked or shared, which effectively nullifies the optimized routing functions.
Determining Workload Optimization State
The easiest way to check the state of workload optimization is to use the active workloads view in the CICSPlex SM WUI. The list view contains a row for each workload active in the CICSplex. A new column added to this view indicates the workload optimization status. Expected values are:
- ACTIVE: All targets and routers are executing in optimized workload state.
- PARTIAL: At least one target and one router are executing in optimized workload mode.
- INACTIVE: The workload isn’t running in optimized state, because either no routing regions in the workload are running in optimized state, no target regions in the workload are running in optimized state, or the workload was designated as being non-optimized.
The easiest way to check the optimization state for a CICS region is to use the routing region or target region views located in the active workloads menu. The optimization status for the region is shown in the list views for both region types. Expected values are:
- ACTIVE: The region is executing in optimized workload state.
- INACTIVE: The region can execute in optimized state, but it’s currently non-optimized. Reasons for this are detailed in the help data for the routing and target region views in the WUI.
- N_A: The region isn’t optimized workload-capable—probably because the region is running a CICS TS version prior to V4.1.
If you have regions that require no optimization capabilities, then set the region status server update frequency value for those regions to 0 to prevent the CICS transaction manager from broadcasting irrelevant region status data to the coupling facility. This would typically include all WUI server regions and any regions assigned a purely routing role.
CICS will record the status of a CICS region to the DFHRSTAT CFDT file. The definition for this file is automatically generated when the CICS region status function is initialized. The CICS file definition will be related to a physical CFDT that’s named after the CICSplex name the region belongs to. When defining this file, RS domain will also generate a poolname gathered from the CICSplex Definition (CPLEXDEF) the starting region belongs to. The default poolname is also DFHRSTAT. In any given z/OS image, there must be one region status server per poolname running in that image.
For example, If a z/OS image executes CICS regions associated with PLEX1, PLEX2 and PLEX3, which all specify the default poolname, then only a single region status server must be running in that image for the CFDT pool named DFHRSTAT.