In a serviceability review for CPSM, I brought this up and it was suggested that it should be submitted as an RFE instead.
Can we introduce some easier way of gathering documentation when customers ask 'why is a transaction routing this way?' As it is now, we resort to turning on several different levels of WLM Level tracing, having them capture that in AUX trace, send it in, then we pour through it...slowly. The instructions for them are long and error prone. How about something like this:
.
If they have a question, they'd use something built in, perhaps through CAPTURE in COD0. Maybe we would have them logon to the TOR, use COD0, and through CAPTURE or some new option, they'd specify
CAPTURE WLMTRACE XXXX ####
where XXXX could either be an '*' or a transaction 'FRED' or a mask 'FRE*' and #### would be the number of new tasks that matched that pattern to trace. When they issued that, we would automatically turn CPSM WLM Level tracing on for WLM levels 18, 19, and 23 through 27, issue a TRACE ON RESET (both in the TOR and try to route one up to the CMAS) trace #### number of transactions matching the pattern, then when we hit that issue TRACE OFF STOP, reset the flags to off. That would make gathering the current data easier.
What I'd REALLY like though is something that would externalize the final balanced and sorted scope vector information to them immediately so they can look at it without sending it in to us, and answer their own question. Perhaps as we're writing it to trace for the above CAPTURE command, we could intercept it and build a result set that could be queried through the CICS Explorer, and presented something like this:
.
DATE/TIME/APPLID/WLMSPECNAME
REQUESTED BY USER: CVMGT2
CAPTURE WLM TRACE XXXX #### RESULTS:
---------------------------------------- SCOPE VECTOR DETAILS -------------------------------------------------
TASK# TRANID TIMESTAMP APPLID AFF LOAD SELECTABLE SOS MXT STALL DUMPING RTERR WEIGHT LINK-STAT EVENT-SEV OPT HLTH INTWGHT
12345 FRED MM/DD/YY HH:MM:SS AOR00006 Y/N 99999 (THESE WOULD BE YES/NO FIELDS) 0-13 99999999 0-2 0-6 OR N Y/N 0-2 99999999
AOR00002 Y/N 99999 (THESE WOULD BE YES/NO FIELDS) 0-13 99999999 0-2 0-6 OR N Y/N 0-2 99999999
AOR00009 Y/N 99999 (THESE WOULD BE YES/NO FIELDS) 0-13 99999999 0-2 0-6 OR N Y/N 0-2 99999999
AOR00001 Y/N 99999 (THESE WOULD BE YES/NO FIELDS) 0-13 99999999 0-2 0-6 OR N Y/N 0-2 99999999
AOR00016 Y/N 99999 (THESE WOULD BE YES/NO FIELDS) 0-13 99999999 0-2 0-6 OR N Y/N 0-2 99999999
AOR00011 Y/N 99999 (THESE WOULD BE YES/NO FIELDS) 0-13 99999999 0-2 0-6 OR N Y/N 0-2 99999999
12345 FRED MM/DD/YY HH:MM:SS AOR00006 Y/N 99999 (THESE WOULD BE YES/NO FIELDS) 0-13 99999999 0-2 0-6 OR N Y/N 0-2 99999999
AOR00002 Y/N 99999 (THESE WOULD BE YES/NO FIELDS) 0-13 99999999 0-2 0-6 OR N Y/N 0-2 99999999
AOR00016 Y/N 99999 (THESE WOULD BE YES/NO FIELDS) 0-13 99999999 0-2 0-6 OR N Y/N 0-2 99999999
AOR00011 Y/N 99999 (THESE WOULD BE YES/NO FIELDS) 0-13 99999999 0-2 0-6 OR N Y/N 0-2 99999999
12345 FRED MM/DD/YY HH:MM:SS AOR00006 Y/N 99999 (THESE WOULD BE YES/NO FIELDS) 0-13 99999999 0-2 0-6 OR N Y/N 0-2 99999999
AOR00002 Y/N 99999 (THESE WOULD BE YES/NO FIELDS) 0-13 99999999 0-2 0-6 OR N Y/N 0-2 99999999
AOR00009 Y/N 99999 (THESE WOULD BE YES/NO FIELDS) 0-13 99999999 0-2 0-6 OR N Y/N 0-2 99999999
AOR00001 Y/N 99999 (THESE WOULD BE YES/NO FIELDS) 0-13 99999999 0-2 0-6 OR N Y/N 0-2 99999999
AOR00011 Y/N 99999 (THESE WOULD BE YES/NO FIELDS) 0-13 99999999 0-2 0-6 OR N Y/N 0-2 99999999
...
and so on. Essentially, ALL the scope vector fields in EYURWSVE would be externalized in an easy to read format. At the beginning of the output we'd probably put a table of values for what each field can have (Y/N is obvious, but the numeric fields meaning something could have an index to refer to.)
Taking this a step farther though, and putting it where it should be, we would write this routing information to SMF records to be consumed by CICS PA, where we would supply model PA reports that would let customers research and resolve routing questions on their own, instead of opening PMRs.
This requirement has been re-assessed. It is not likely that this will be implemented in the next 12-24 months and so it is being declined at this point. The requirement will be kept in the RFE system and might be reassessed in the future. You also have an opportunity to resubmit in twelve months time if you wish it to be reconsidered then.