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:
You should check the following:
The first step is to determine which workload is active in the region from which the dynamic request is routed. Issue the WLMSCOPE command.
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.
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.
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.
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.
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.
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.
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.
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 ]]