The current MICS-distributed cccOPS members have a RESP statement that warrants review / dial-down to define more useful and accurate "response distribution limits" (to multiple sub-second intervals) than what's provided by CA. Take a look at your cccOPS members and see what's defined. And compare your unit database values to the distributed-version of cccOPS in sharedprefix.MICS.HOLD.PARMS(cccOPS).
Of course this discussion does presume there is MICS reporting interest with exploiting MICS / transaction percentile analysis using summary-level MICS database reporting files, like CICCSU, CICCSY, and others for IDMS and IMS. Don't you want to be able to inquire with CA MICS and address the question: "99 percent of all CICS application *** transactions completed with 0.5 seconds" yesterday, or on-average for the past 53 weeks or 6 months.....okay, I'll stop there.
And so here's a tip with MICS CICS Analyzer to substitute the current response limit 1 for the appropriate SAS LABEL based on what's defined in MICS...after generating this report, then it may be time to reconsider the RESP settings, discuss them with end-users and decrease the limit-values so you can get more out of MICS (BTW, the code below can easily be applied to IMS or IDMS components with some minor changes to SAS variable names):
//STEP1 EXEC MICSSHR?
//SYSIN DD DATA,DLM=ZZ
OPTIONS SOURCE SOURCE2 NOCENTER;
%LET CYCRANGE = 01;
* SORT/SUMMARIZE MICS CICCSU USING MICS SUMMARIZATION. ;
* SUMMARIZE TO ONE OBS PER CICS-REGION, PER DATE/HOUR. ;
%LET BY = SYSID CSUAPPL INTVLHR;
%* code below captures last SAS variable from BY list. ;
%LET BREAK = %SCAN(&BY,-1,%STR(&BY));
DATA CSU;
SET %MFILE(F=CSU&CYCRANGE,TS=DAYS);
* *SBB* Optional WHERE statement could go here. ;
* YOUR CICCSU FILTER CODE GOES HERE, OTHERWISE USE CICCSY. ;
* ;
IF _N_=1 THEN DO;
* DECLARE SAS MACRO VARIABLES FOR LATER USE IN LABEL STMT. ;
CALL SYMPUT('RVAL1',PUT(CICRVAL1,6.2 -L) );
CALL SYMPUT('RVAL2',PUT(CICRVAL2,6.2 -L) );
END;
* derive hour-interval for summary-reporting, convenient as one-column. ;
ATTRIB INTVLHR FORMAT=DATETIME15. LABEL='INTVL-END HOUR';
INTVLHR = INTNX('DTHOUR',ENDTS,0);
RUN;
PROC SORT DATA=CSU;
BY &BY;
RUN;
%MACRO NEGATE;
* MICS fffSUM macro invokes this code below to combine all CP-types ;
* just prior to OUTPUT. Remember to combine zIIP CP usage below, ;
* starting with CICS/TS V5. ;
ATTRIB AVGCPUTM FORMAT=10.3 LABEL='AVG CICS CPU P/TRAN (SEC)';
AVGCPUTM = SUM(CSUCPUTM,CSUNZZTM) / SUM(CSUTRANS,CSUETRN);
%MEND NEGATE;
DATA CSU;
%CSULEN(TS=MONTHS);
SET CSU;
%CSUSUM; /* NEGATE macro invoked just prior to OUTPUT */
RUN;
PROC PRINT UNIFORM NOOBS LABEL DATA=CSU;
VAR &BY CSUTRANS CSUAVTTM AVGCPUTM CSUPCTR1-CSUPCTR2 CSUTDST1-CSUTDST2;
FORMAT CSUTRANS COMMA9. CSUAVTTM 14.3 ;
* OVERRIDE SAS LABEL BELOW - ADD MICS RESP DIST LIMIT. ;
LABEL CSUPCTR1 = "PCT RESP W/IN &RVAL1 SEC";
LABEL CSUPCTR2 = "PCT RESP W/IN &RVAL2 SEC";
LABEL CSUTDST1 = "TOT RESP W/IN &RVAL1 SEC";
LABEL CSUTDST2 = "TOT RESP W/IN &RVAL2 SEC";
RUN;
ZZ
Another tip for ASG TMON/CICS (TCE) users (hey, now aren't you glad you read this far down in the post?) -- if you are at TCE 3.4 or later/higher, be sure that the TMON option is properly set to split-out your zIIP CPU consumption as separate reporting metrics, otherwise it gets lumped together with general-purpose CP consumption and cannot be segregated for transaction/application reporting interests.
Scott Barry
SBBWorks, Inc.