Any routers needing to examine the status of a remote target will also require a region status server to run in the local z/OS image for the same poolname as that servicing the target regions. If you use the default poolname in the CPLEXDEF of all your CICSplex definitions, you’ll require one region status server per z/OS image.
Figure 1 shows the lifetime of an unoptimized workload of 10,000 started tasks initiated from a single routing region. The workload is dynamically routed across a target scope of 30 target regions. Ten of these regions are managed by the same CMAS as the router, but the other 20 regions are managed by two other CMASs, one on a different LPAR in the Sysplex. Each line in the chart represents the task load in a target region at 10-second intervals. The lines clustered along the bottom of the chart are all local to the router. None of them exceed 10 percent exploitation. All the other regions are remote from the router and are continuously surging 100 percent utilization and then back to idle. This is workload batching.
Consider Figure 2. This is the same workload, but with Sysplex optimization activated. No workload batching is occurring. None of the target regions are idle or at the MAXTASK limit. The workload is being spread equitably. The locality of the target regions to the router is appropriately reflected; the upper band of target regions are local to the router, and the lower band is remote from it.
WLM correctly favors the local target regions over the remote ones until the task load difference for the region locality exceeds approximately 30 percent. However, the most important difference between the optimized and unoptimized workloads is represented by the number of 10-second time intervals across the bottom of each graph. The duration of the unoptimized workload was 16 10-second periods. When the same workload runs in optimized state, the workload completes in 12 periods. In this test case, that was a 25 percent savings in workload throughput time. These figures were measured in ideal circumstances; you’ll need to run your own tests to determine your precise benefits.
During testing of other intensive distributed workloads, time savings of more than 50 percent were recorded. The higher the task load throughput, the greater the savings in throughput time. Sysplex optimization appears to be most effective at times of high throughput demand for distributed workloads. These are workloads fed to CICS through asynchronous START commands. Typically, these are from MQSeries trigger transactions or WebSphere Sysplex Distributor.
Workloads that originate from synchronous dynamic routing requests—such as those from transaction routes, function ships, etc.—won’t show such an exceptional improvement unless those target regions share transaction traffic with locally initiated tasks. In those circumstances, Sysplex optimization means the router will become aware of the non-dynamic throughput to a target region long before a heartbeat occurs; again, this lets routers make more intelligent routing decisions.
If you’re running at least CICSplex to CICS TS V4.1 and your dynamic workload throughput comprises a high percentage of asynchronous routing requests, you should consider implementing Sysplex optimization.
The key points to remember are:
- To enable workload optimization, first define and execute a region status server in each MVS image that will execute CICS regions intending to exploit it. When all regions are migrated to CICS TS V4.1, those requiring optimization must be enabled in their CICS system definitions (CSYSDEFs).
- Users may mix and execute CICS TS V4.1 and pre-V4.1 regions in workload, but full optimization benefits won’t occur until all systems are running CICS TS V4.1.
- One region status server is required per pool name per z/OS image. Don’t start any servers if you don’t want to exploit optimized workloads.
- Don’t adjust the WLM RS domain tuning parameters until you’re certain an adjustment is required. When changes are deemed necessary, make them in gradual increments.
- Look at the new active workload views to monitor status and progress of workloads in target regions.