CICS/MRO and CSUTRSTM accuracy concerns

[Scott Barry]

Hello Fellow MICS'ers:

With CICS/MRO environments, there are typically multiple CICS transactions executed that relate to a given business-application transaction, identified by a unique UOWID.

Hopefullly MICS CICS component sites have implemented the CICOPS parameter MSACCOUNT and also have devoted CICACTn variable(s) to capturing the TOR / initial application transaction identification data-values for say TRANCODE and PROGRAM?

These supplemental CICS environment identification data-values permit "application level" mgmt reporting to be done using the MICS summary-level time-spans, as well as the typical CICS region-level analysis / reporting.

Okay, so with CICS/MRO, the only CSUTRSTM that is meaningful (and accurate) would be the initial metric from FIRST.CICUOWID (in MICS terms), again, where MSACCOUNT is activated. All other transactions related to the TOR instance really should be zeroed-out, right?

I've opened a CA SUPPORT issue to investigate the opportunity to remedy this situation in MICS, likely with new CICCSU variable(s) set and maybe a CICOPS parameter to drive the calculation process -- if not otherwise, then at least provide admin/user awareness in the MICS DICTIONARY member.

The CICCSU impact also would include the RESPONSE DISTRIBUTION variables as well, from my perspective.

I'll update this thread in the future when I hear back from CA. I'm curious about others' interest and perspective on this message board challenge, if you're willing to give a shout (MICS message board lurkers out there, come on!).

Regards,

Scott Barry
SBBWorks, Inc.

P. S. Isn't London and Great Britain doing an incredible job with hosting the Olympics? I'd sure say so......sbb

[Scott Barry]

Now after 2 years since I posted this item / concern, I see numerous VIEWs but no one has commented whether or not they also have concern that CSUAVTTM (CICS average response time) is flawed for CICS/MRO 'application transaction' reporting -- unless action / awareness is taken to capture the TOR (now identified as originating transaction code, MICS CICCSU detail variable CSUOTRAN) and only count CSUTRSTM observation values for this TOR-initiated transaction.

 

An oversimplified example is shared in the Excel screen-capture below:

The multi-region CICS application transaction execution of "APPX" will report a response-time of 0.83 seconds, when the MICS CICCSU SAS variables CSUTRSTM and CSUTRANS are summarized in order to derive CSUAVTTM (metric in blue at the bottom: sum-of CSUTRSTM divided by sum-of CSUTRANS, for the three related transactions), otherwise a more accurate application transaction response time (as experienced by the end-user, or otherwise 'internal response') would be the TOR-only CSUTRSTM (or CSUAVTTM, same value).

 

One possible solution is to capture CSUOTRAN as well as TRANCODE with a CICACTn (CICS Account Code) variable and interrogate the CICCSU at reporting, resetting CSUTRSTM where CSUOTRAN does not equal TRANCODE.

 

At this point in time, CA has agreed to investigate further....

 

Scott Barry

SBBWorks, Inc.

[Scott Barry]

For those interested, a CA MICS CICS component enhancement idea was added today for this topic/issue/challenge.

 

CICCSU Application Transaction Response (improved CSUTRSTM/CSUTRANS-CSUETRN)

 

Scott Barry

SBBWorks, Inc.