Dec 15 ’11
IBM CICS System Management: New CICSPlex SM WLM Features in Version 4.2
With the need to handle increasing volumes of transactions, enterprises must implement extensive and more complex system configurations that often consist of Web front-ends, WebSphere Application Servers, WebSphere MQ, WebSphere Message Broker, CICS, DB2, IMS, and other products. The tasks of systems management and workload management then become rather challenging. The CICS Transaction Server for z/OS (CICS TS) Development team recognizes this and constantly looks for ways to enhance the use and management of CICS TS.
This article discusses the numerous CICSPlex SM Workload Management (WLM) enhancements in CICS TS Version 4.2 (released June 24, 2011) that offer more control with workload istribution.
CICSPlex SM Link Neutral Dynamic Routing Algorithms
CICS TS 4.2 introduces two link neutral WLM dynamic routing algorithms:
- Link Neutral Queue Algorithm (LNQUEUE). Target regions for transactions routed through link neutral queue mode are selected based on their current task load, health state, and the existence of any active Real-Time Analysis (RTA) events and any abend compensation probabilities defined in the WLM specification (WLMSPEC) or transaction groups (TRANGRPs) associated with the workload. This is the same as the standard queue algorithm, but the link type factor isn’t calculated in the routing weight for a target region.
- Link Neutral Goal Algorithm (LNGOAL). Target regions for transactions routed through goal mode are selected based on the response time goal (either average or percentile) for the transaction being routed, as specified by the WLM component of z/OS. If a specific target can’t be identified through the goal algorithm execution, then the new LNQUEUE is applied to the remaining set of target regions. This is the same as the standard goal algorithm, but the link type factor isn’t calculated in the routing weight for a target region.
Note that if there are any transaction affinities outstanding for the transaction being routed, the affinity target region is selected regardless of the algorithm being executed.
Link neutral algorithms are beneficial for routing dynamic transactions that, for example, may require services from MVS subsystems. With the standard routing algorithms, routers focus dynamic traffic on the systems with the fastest links, which by implication probably reside in the same Logical Partition (LPAR). This could cause such subsystems to become overloaded in the local MVS image. Remote MVS images participating in the workload would be relatively underutilized. By assigning these transactions to a TRANGRP that specifies a link neutral algorithm, dynamic traffic is routed to the local and remote LPARs on a relatively even basis, spreading the load across those subsystems.
Link neutral algorithm types are intended to isolate the connection factor from the rest of the routing weight calculation. The effect is that the most remote target regions (most likely connected with the slowest telecommunications links) are equally favorable as locally connected Multi-Region Operation (MRO) regions (or even the routing region itself if it’s part of the routing target scope). Using the LNQUEUE or LNGOAL algorithm at the WLMSPEC level can affect every dynamically routed transaction. The consequence is that WLM may not necessarily choose the best target region for your dynamically routed traffic. This might hamper overall throughput.
If a link neutral algorithm is desired for a specific transaction set, an algorithm type can be specified in a WLM TRANGRP definition.
Prior to CICS TS 4.2, CICSPlex SM WLM let you specify a single dynamic routing algorithm at the WLMSPEC level (see Figure 1). This had the effect of applying the same dynamic routing algorithm to every dynamically routed transaction in the workload. Also, if the algorithm had to be changed in the same workload, all regions participating in the workload had to be simultaneously quiesced to allow the workload to be refreshed with the new algorithm specification.
You can now specify an algorithm type at the CICSPlex SM WLM TRANGRP level (see Figure 2). By specifying an algorithm in this way, you can apply alternative algorithms to specific transaction codes in the same workload. A new SET command was implemented with this function to accommodate immediate dynamic modification of the algorithm type directly against the TRANGRP. So it’s possible to modify the algorithm type at run-time with no need to quiesce and restart any regions in the workload. There’s a one-to-one relationship between an installed workload definition (WLMDEF) and TRANGRP. The ability to discard and re-install a TRANGRP through its associated WLMDEF was retained, but using the SET command directly against the TRANGRP is a more efficient change mechanism.
At the WLMSPEC level, a default algorithm must be specified for the workload. This algorithm is applied to all dynamic transaction codes not encompassed by a TRANGRP associated with the same workload. The algorithm types you can specify at the WLMSPEC level are:
- QUEUE: queue mode
- GOAL: goal mode
Transactions that are to be evaluated by an alternative algorithm type need to be associated with a TRANGRP that identifies that algorithm type. The algorithms that can be specified at the TRANGRP level include the same algorithms that can be specified at the WLMSPEC level and an additional algorithm—INHERIT. For INHERIT, the algorithm type specified in the WLMSPEC for the workload is used.
When migrating CICSPlex SM data repositories to CICS TS 4.2, you can retain current settings by setting the algorithm type for existing TRANGRPs to INHERIT.
Figure 3 shows the relationship between CICSPlex SM WLM resources. The algorithm type can be specified as an attribute on a WLMSPEC or a TRANGRP definition.
The Web User Interface (WUI) in Figure 4 shows algorithm types specified at the WLM specification level.
Figure 4 shows that WLM specification GWS has an algorithm type of GOAL. If WLM specification GWS is selected and mapped, the WLM groups, WLM definitions, and transaction groups associated with GWS can be seen (see Figure 5).
If transaction group TRANGRP is selected in the transaction group definitions column in Figure 5, the algorithm type specified at the transaction group level is actually QUEUE (see Figure 6). This means that WLM algorithm type QUEUE will override the algorithm type GOAL, specified at the WLMSPEC level, for those transactions associated with transaction group TRANGRP.
The Order of Precedence of Link Types
CICSPlex SM WLM optimizes processor capacity by making decisions to dynamically route transactions and programs to the most appropriate target region.
When executing its dynamic routing algorithm, CICSPlex SM WLM assigns a predefined arithmetic value based on the type of link between a routing region and candidate target region. This value is used as a multiplier against the target region's task load as part of the routing weight calculation of a target region. The region with the lightest weight is normally selected as the target region.
Prior to CICS TS 4.2, IP Interconnectivity (IPIC) was slower than Logical Unit 6.2/Advanced Program-to-Program Communication (LU6.2/APPC). So IPIC was allocated a higher arithmetic value to make it less preferable compared to other link types. Because IPIC is now faster than LU6.2/APPC, it’s now allocated a lower arithmetic value than LU6.2/APPC to make it more preferable. So, on occasions of significant workload, more dynamic route requests would be routed to the target regions over IPIC than over LU6.2/APPC.
The link-type order of precedence a router now employs is:
- Local (faster than MRO/XM)
- MRO/XM (faster than MRO/XCF)
- MRO/XCF (faster than IPIC)
- IPIC (faster than LU6.2/APPC)
- APPC (faster than an indirect connection)
- Indirect connection.
This behavior is recognized only for queue mode and goal mode dynamic routing. The link neutral algorithms specifically omit the link type factor from the algorithm execution, causing all targets to be regarded as having the same link speed.
Unit of Work (UOW) Affinities With Distributed Program Link
CICS Distributed Program Link (DPL) lets CICS programs run programs in other CICS regions by shipping program control LINK requests to target regions. The benefit is that you can write an application without knowing the location of the requested programs. The CICS program resource definition specifies that the program is in a remote rather than local region (see Figure 7).
The program running on region CICA issues a program control LINK command for program PGA. From the installed program definitions, CICS discovers that program PGA is owned by region CICB. CICS changes the LINK request into a suitable transmission format and ships it to CICB. In CICB, a mirror transaction is attached. The mirror program DFHMIRS associated with the mirror transaction re-creates the original request and issues the request on CICB to link to program PGA. So CICS has performed a DPL request.
CICSPlex SM WLM optimizes processor capacity by dynamically routing transactions and programs to the region that’s the most appropriate to execute them. However, when using dynamic WLM, problems can occur during use of multiple DPL requests in a single UOW.
For example, if multiple invocations of the same dynamically routed program access a common resource in the same UOW, one DPL request could be routed to one region where a resource may be locked, while a subsequent DPL request may be routed to a different region where the state associated with the outstanding UOW isn’t available. So, it wouldn’t be possible to run the second DPL request in the same UOW (see Figure 8).
Dynamic WLM now resolves problems associated with the use of multiple DPL requests in a single UOW. A new type of CICS affinity, associated with a UOW and restricted to dynamically linked programs, was introduced. CICSPlex SM WLM has been extended to manage these UOW affinities for DPL requests. The affinity is defined with an affinity relation of LOCKED, meaning a called program retains state data that’s to be preserved after it returns to its caller, and an affinity lifetime of UOW so that programs with this type of affinity are routed to the same target region for the duration of the UOW (see Figure 9).
CICSPlex SM WLM administration views were updated with new fields and field values to configure UOW affinities. Using the TRANGRP and WLMSPEC resource tables, you can now create transaction groups and WLM specifications that incorporate this new type of affinity. The Active workloads view has been updated to display the number of active transaction group affinities. Figure 10 shows an example of the affinity relationship and the affinity lifetime specified on a WLM specification. To use the new UOW affinity with existing workloads, you must restart the workloads with CICS TS 4.2.
We’ve shown you how:
- CICSPlex SM WLM algorithms can be used to isolate the connection factor from the routing weight calculation.
- CICSPlex SM WLM dynamic routing algorithms can be specified at the WLMSPEC level and overridden at the TRANGRP levels.
- UOW affinities are taken into account with DPL.
To learn more, visit http://publib.boulder.ibm.com/infocenter/cicsts/v4r2/topic/com.ibm.cics.ts.whatsnew.doc/themes/theme4.html.
CICS systems administrators should realize the value of the new features of CICS Transaction Server for z/OS V4.2 and consider exploiting them.