The MICS CICS component (also IDMS and IMS) have a keen feature which can help sites categorize transactions as short, medium, long, etc., but also to help segregate outliers as "excessive" transactions. When the cccRLRT exit assigns TRANTYPE="X" then MICS sets aside that transactions "response" and "distribution count" measurement variables into a separate group, starting with "Excessive" Transaction execution (and others related, as well).
So, any MICS administrator who was not around when MICS was implemented/configured, it may be worthwhile to have a look at those install parameters, and in particular any component-level (unit database PARMS) relative longevity routine exit in component-level cccRLRT member.
As well, any sites with end-users who go after their own MICS reporting, it's also important not to keep them in the dark, by providing simple code examples, such as this one where excessive transactions are combined in with "normal" for the purposes of getting an overall response average, not one that avoids "skewing" due to frequent-type utility or long-running outlier transactions -- those that can skew down true internal response time as reported within MICS and those transactional components you have licensed. Have a look at Chapter 7 of your MICS component guide and the "RLRT" exit reference for more details.
* use code below prior to any MICS summarization macro ;
* invocation to include excessive trans executions. ;
CSUTRANS = SUM(CSUTRANS,CSUETRN);
CSUETRN = 0;
CSUTRSTM = SUM(CSUTRSTM,CSUERSTM);
CSUERSTM = 0;
In addition to cccRLRT (relative longevity routine) for TRANTYPE="X" (excessive) assignments, this site also uses a revise cccOPS RESP statement with more realistic response-thresholds for "percent response" analysis. And just determined with the MICS CICS ANALYZER, there are no CICCSU, CICCSY excessive-grouping variables provided by CA -- at least not today. A SUPPORT CASE has been opened to identify and hopefully resolve this DEFECT condition.
As of recent, CA has categorized the missing CICS "excessive transaction" activity (this discussion-post topic) in CICxxx information area files not as an appropriate DEFECT but instead as a new enhancement.
Although consider MICS CICS users that use TRANTYPE="X" assignment in CICRLRT are not able to easily count / report / manage this activity within MICS, as can be done today most effectively with other MICS components like IDMS ANALYZER.
So, without other MICS sites chiming-in on this topic, the MICS PTF-fix / enhancement will be relegated to the "future" pile, sadly.
Here is a MICS/SAS code-pience for suggested verification technique to see if your site is vulnerable, using this MICS/SAS analysis code to detect if CSUETRN as used using PROC MEANS against the available MICS CICS CICCSUnn cycles in MONTHS:
//STEP1 EXEC MICSSHR? <- your MICS CICS unit ID //SYSIN DD DATA,DLM=ZZ OPTIONS NOCENTER SOURCE SOURCE2; /* CREATE A SAS VIEW FOR PERFORMANCE */ DATA CSUV / VIEW=CSUV; SET _CICM.CICCSU: ; /* SELECT ALL AVAILABLE CYCLES */ RUN; PROC MEANS MAX MAXDEC=0 DATA=CSUV; WHERE CSUETRN GT 0; BY SYSID CICSID; VAR CSUETRN; RUN; ZZ