The decision on region status pool name should be made before any CICS regions in the workload are started. You may change the pool name while a workload is in flight, but it’s not recommended because:
- The change won’t be effective until all regions in the workload are restarted.
- The pool name switch while the workload runs will cause the optimization function to be de-activated for all CICS regions connected to the region status server.
If the pool name is changed in error while the workload runs, then reversing the name to its original value will allow optimization to be re-activated. CICS regions required to run in optimized mode must be enabled for optimization. Setting a number of regions to be optimized is most easily achieved using the CICSplex SM Web User Interface (WUI) CICS System Definition (CSYSDEF) tabular view and summarizing the list to a single row. Then use the update button to change WLM optimization enablement to enabled. That will enable optimization for all regions. Because you won’t want optimization set for your WUI server regions (and possibly others), you should then run through the updated system definition list and re-disable optimization for your WUI server regions on an individual basis.
If some dynamic routing regions are already running, you may activate optimization to in-flight CICS regions using the “MASs known to CICSplex” tabular view in a similar manner to the “CICS system definitions” view. Users don’t need additional configuration actions to optimize their workloads. If you don’t run a region status server, workloads are forced to remain in a non-optimized state.
Coupling Facility Impact
The coupling facility is impacted in two ways. CICS region status data is broadcast to it by target regions, and that data is subsequently read back in the routing regions when a route decision is made. If CICS were to rebroadcast status data at every change instance, and read it back on every occasion a route decision is made, then the coupling facility impact could be unsustainable. So, caching mechanisms were built in to reduce the number of I/Os to the coupling facility.
Two tuning parameters are provided at the CICSplex and CICS system definition levels to adjust coupling facility exploitation. One controls how often the coupling facility is updated with task throughput data; the other controls how long region status data should be cached by a routing region before requesting a refresh:
- Region status server update frequency: UPDATERS
- Region status server read interval: READRS.
A detailed description of these attributes is available in the field help for the CICSplex definition and CICS System definition WUI views.
In addition to tuning the general read and update impact to the coupling facility, two other specialized parameters allow further fine-tuning of the workload for heavy and light workload throughput:
- Region status server top tier: TOPRSUPD
- Region status server bottom tier: BOTRSUPD.
If you think you need to deviate from the default settings for these attributes, monitor the performance of your coupling facility and that of WLM throughput capabilities for at least several days after modification.
A region status record is 40 bytes. There’s one record for each region in your CICSplex, which is stored in the physical data table named from that CICSplex. This data table will be generated within the named CFDT pool from the CICSplex definition resource table. CICS writes region status data to a file named DFHRSTAT. The definition of DFHRSTAT is automatically generated, and will locate a physical data table named from the parent CICSplex. Therefore, if PLEX1 comprised 100 regions, then the required space in the coupling facility would be 4,000 bytes for a table named PLEX1.