Unexpected workload management routing decision

You may need to investigate questionable or misunderstood dynamic routing decisions. For example, you might expect a specific dynamic routing request to be routed to the healthiest target region in a group of target regions. However, you might find that the request is always routed to one particular target region, regardless of the health of the target region.

The approach described here is as follows:

  1. Make sure that dynamic routing is enabled for the work requests
  2. Determine which workload is active
  3. Determine whether the workload is separated by TRANSID, LUNAME or USERID
  4. Determine whether there are active affinities

Is dynamic routing enabled?

You should check the following:

Which workload is active?

The first step is to determine which workload is active in the region from which the dynamic request is routed. Issue the WLMSCOPE command.

Figure 62. Example of WLMSCOPE view showing active workloads
27FEB2005  08:40:03 ----------- INFORMATION DISPLAY ---------------------------
COMMAND  ===>                                                 SCROLL ===>
CURR WIN ===> 1        ALT WIN ===>
 W1 =WLMSCOPE==========EYUPLX01=EYUPLX01=27FEB2005==08:40:03=CPSM====9=========
CMD WLM      Scope    Scope    Scope    Scope    Update
--- Spec---- Name---- Type---- Mode---- Link---- Option--
    EYUWLS01 EYUMAS1A CICSSYS  INHERIT  EYUCSG01
    EYUWLS01 EYUMAS2A CICSSYS  INHERIT  EYUCSG01
    EYUWLS01 EYUMAS3A CICSSYS  INHERIT  EYUCSG01
    EYUWLS01 EYUCSG01 SYSGROUP
    EYUWLS02 EYUMAS1B CICSSYS  INHERIT  EYUCSG02
    EYUWLS02 EYUMAS2B CICSSYS  INHERIT  EYUCSG02
    EYUWLS02 EYUMAS3B CICSSYS  INHERIT  EYUCSG02
    EYUWLS02 EYUCSG02 SYSGROUP
    EYUWLS02 EYUCSG03 SYSGROUP
 

A routing region can be associated with only one workload specification. In the WLMSCOPE view, look in the Scope Name field for the routing region you are concerned with, and find the name of the associated workload specification. This name is the name of the workload that is activated when the requesting region starts.

One thing to remember about the WLMSCOPE view (and all other workload views) is that it reflects information that is in the data repository. It is possible that the data repository has been modified since its definitions were installed into running systems. Therefore, you must use the WLMAxxxx views to see which definitions are installed and active in running systems.

To verify that a workload is active, issue the WLMAWORK view command.

Figure 63. Example of the WLMAWORK view showing an active workload
27FEB2005  08:59:19 ----------- INFORMATION DISPLAY ---------------------------
COMMAND  ===>                                                 SCROLL ===>
CURR WIN ===> 1        ALT WIN ===>
 W1 =WLMAWORK==========EYUPLX01=EYUPLX01=27FEB2005==08:59:19=CPSM====1=========
CMD Name     Ownr Rout Targ Affinity Lifetime  Scope    Event    Status Algrthm
--- -------- ---- Cnt- Cnt- -------- --------- -------- Name---- ------ Type----
    EYUWLS02 HTC1    1    2 LUNAME   LOGON     EYUMAS2B          ACTIVE QUEUE
 
 

Now you need to ensure that the workload is actively associated with the routing region you are interested in. To display the WLMAWTOR view, hyperlink from the Rout Cnt field on the WLMAWORK view.

Figure 64. Example of the WLMAWTOR view
27FEB2005  09:03:20 ----------- INFORMATION DISPLAY ---------------------------
COMMAND  ===>                                                 SCROLL ===>
CURR WIN ===> 1        ALT WIN ===>
 W1 =WLMAWTOR==========EYUPLX01=EYUPLX01=27FEB2005==09:03:20=CPSM====1=========
CMD Workload Ownr Router   Connection
--- -------- ---- -------- Lost------
    EYUWLS02 HTC1 EYUMAS2B
 

The WLMAWTOR view shows which routing regions are actively running a given workload.

Is the workload being separated?

Now you know which workload is active on the routing region. The next step is to find out if the workload is being separated based on TRANSID, USERID, LUNAME, or some combination of these. To do that, take the request in question (the one defined as dynamic, initiated via terminal input) and see whether it is a member of any active transaction groups. Issue the WLMATRAN command.

Figure 65. Example of the WLMATRAN view
27FEB2005  09:16:49 ----------- INFORMATION DISPLAY ---------------------------
COMMAND  ===>                                                 SCROLL ===>
CURR WIN ===> 1        ALT WIN ===>
 W1 =WLMATRAN==========EYUPLX01=EYUPLX01=27FEB2005==09:16:49=CPSM====8=========
CMD Transid  PCONV Trangrp  Workload Ownr
--- -------- Mode- -------- -------- ----
    ADCD           WMTAFFA  EYUWLS02 HTC1
    DAA1           WMTAFFB  EYUWLS02 HTC1
    DAA2           WMTAFFC  EYUWLS02 HTC1
    DBA1           WMTAFFB  EYUWLS02 HTC1
    DBA2           WMTAFFC  EYUWLS02 HTC1
    DCA1           WMTAFFB  EYUWLS02 HTC1
    DCA2           WMTAFFC  EYUWLS02 HTC1
    F100           WMTMSCA  EYUWLS02 HTC1
 

If the transaction in question is listed in this view, the routing decision is possibly based on a workload definition associated with the transaction group of which the transaction is a member. Note the name of the transaction group.

Now look at the active workload definitions. Issue the WLMAWDEF command.

Figure 66. Example of the WLMAWDEF view
27FEB2005  11:42:55 ----------- INFORMATION DISPLAY ---------------------------
COMMAND  ===>                                                 SCROLL ===>
CURR WIN ===> 1        ALT WIN ===>
>W1 =WLMAWDEF==========EYUPLX01=EYUPLX01=27FEB2005==11:42:55=CPSM====4=========
CMD Name     Workload Ownr Trangrp  Luname            Userid   Target   Descrip
--- -------- -------- ---- -------- ----------------- -------- Scope--- -------
    T123DEF  EYUWLS02 HTC1          .++++T123         *        EYUMAS1B
    WMDFAFFA EYUWLS02 HTC1 WMTAFFA  .*                *        EYUMAS1B
    WMDFAFFB EYUWLS02 HTC1 WMTAFFB  .*                DEPT02*  EYUMAS2B
    WMDFAFFC EYUWLS02 HTC1 WMTAFFC  .*                *        EYUCSG02
 

This view shows you which workload definition, if any, applies to the routing request in question. You know the USERID and LUNAME from which the routing request came. You also know whether the transaction is a member of an active transaction group, and, if it is, you know the name of the transaction group. Given these three things, you can tell which workload definition, if any, controls the routing decision. The following pseudo code explains the logic:

IF dynamic transaction in question is a member of an active transaction group
 
 THEN  IF there is a workload definition associated with that transaction group
        THEN  IF the USERID and NAME match the pattern on that workload definition
               THEN  that workload definition will control the routing decision
               ELSE  the workload default controls the routing decision
        ELSE  the workload default controls the routing decision
 
 ELSE  IF there is a workload definition not associated with a transaction group
        THEN  IF the USERID and NAME match the pattern on that workload definition
               THEN  that workload definition will control the routing decision
               ELSE  the workload default controls the routing decision
        ELSE  the workload default controls the routing decision

To illustrate this logic, here are some examples using the WLMAWDEF view shown in Figure 66.

Example 1
The transaction is a member of active transaction group WMTAFFA. The USERID is DEPT01DZ. The LUNAME is NET1.IYJFT123. The routing decision is controlled by workload definition WMDFAFFA.
Example 2
The transaction is not a member of an active transaction group. The USERID is DEPT01DZ. The LUNAME is NET1.IYJFT123. The routing decision is controlled by workload definition T123DEF.
Example 3
The transaction is a member of active transaction group WMTAFFB. The USERID is DEPT01DZ. The LUNAME is NET1.IYJFT123. The routing decision is controlled by the workload default.

When you know which workload definition is controlling the routing decision, the Target Scope field on that same WLMAWDEF view shows you the target region or target region group to which the transaction is routed. If the workload default is controlling the routing decision, the Target Scope field on the WLMAWORK view shows where the transaction is routed.

Are there any active affinities?

Given that a transaction is routed to a specific target region group, an active affinity forces the transaction to go to a particular target region in that group. Affinities are associated with a transaction group. To see whether there are any active affinities for a transaction group, issue the WLMATGRP command to show all active transaction groups. Then, hyperlink from the Affinity field. If there is no active transaction group involved, the default transaction group comes into play. To see whether there is an affinity associated with the default transaction group, hyperlink from the Affinity field of the WLMAWORK view.

[[ Contents Previous Page | Next Page Index ]]