* copyright (C) 1984-2019 merrill consultants dallas texas usa

Also, variable SMF73BSY was added to the KEEP list, in

case it is needed for later re-calculation.

I was writing this update for ADOC73 to better document

that there are two, different, kinds of observations in

TYPE73, when I found the need for this change.
TYPE73 Contains Different types of Observations, based on

the value of SMF73CMG, the CPMF Group:

SMF73CMG = . or 0 ==> old record, without extension

PCHANBY calculated from SMF73BSY/NRSTCPS

PNCHANBY calculated from SMF73PBY/SMF73PTI
SMF73CMG = 1 ==> CPMF=COMPAT

When present, variables SMF73TUT/SMF73PUT, the new

durations when Total Channel Path, LPAR Channel Path

was busy are INPUT (i.e., will be non-missing).

PCHANBY re-calculated from SMF73TUT/SMF73PTI

PNCHANBY re-calculated from SMF73PUT/SMF73PTI

"Normal" TYPE73 record for ESCON channels, CTC's, etc.

FICON channels are reported upon, but only to the same

level of detail as other channel types.
SMF73CMG = 2 ==> CPMF=EXTENDED

This "new" extended subtype is currently written for

OSD and FICON channels (SMF73CPD=11x:OSA DIRECT

EXPRESS, SMF73CPD=1Cx:FICON BRIDGE). It adds

read/write/total byte counts for total/lpar from which

MXG creates four read/write rates in bytes/second:

SMF73TRU=SMF73TRU*SMF73US/SMF73PTI;

SMF73PRU=SMF73PRU*SMF73US/SMF73PTI;

SMF73TWU=SMF73TWU*SMF73US/SMF73PTI;

SMF73PWU=SMF73PWU*SMF73US/SMF73PTI;

and re-calculates PCHANBY and PNCHANBY:

PCHANBY=100*SMF73TUC/(SMF73MCU*SMF73PTI);

PNCHANBY=100*SMF73PUC/(SMF73MCU*SMF73PTI);

and calculates the new "Bus Busy Percent" in PBUSBY

(which is non-missing only in these SMF73CMG=2 obs).

PBUSBY=100*SMF73TBC/(SMF73MBC*SMF73PTI);

Whether type 73 (and type 79-12) records contain CMG 1 or

2 data is determined by the CPMF parameter of IEAOPTxx

member of PARMLIB. CPMF=COMPAT produces MG1 format data

records and CPMF=EXTENDED produces the MG2 format record.

Note that all TYPE73 observations have variables PCHANBY

and PNCHANBY calculated for Total/LPAR percent channel

busy measurements, so if you need seconds of busy time

you can calculate as BUSYTM= PCHANBY*DURATM/100;

OBSERVATION COUNT CHANGE: TYPE73 fewer obs.

Thanks to David M. Kellerman, ADP, USA.

Change 19.083 MXG's creation of SMF70WLA and MSU4HRAV/MSUINTRV values

VMXGRMFI in PDB.RMFINTRV is wrong if you now have the new z/OS

May 14, 2001 records that have SMF70WLA populated by IBM. I thought

May 16, 2001 SMF70WLA would contain the "this-system" MSU capacity in

May 26, 2001 the type 70 record, so in records without that field, I

created SMF70WLA in PDB.RMFINTRV, and for a 1-way system

I set SMF70WLA=36 (the correct MSU capacity available to

that LPAR with one engine), but now I find that IBM puts

SMF70WLA=253 in their record, which is the "all-engine"

or total "image" MSU capacity of the CPC, the hardware

MSU capacity of the box. Spinning was also corrected.

*** NOTE: IBM NOW STORES THE LPAR CAPACITY VALUE, 36,

AND NOT THE CPC MSU VALUE, 253. THIS WAS

APPARENTLY AN EARLY TEST SITE?

SEE CHANGE 20.168.

Since MXG generally never changes the value of IBM fields

in IBM records (although sometimes "Sums" are converted

into "Averages", and labelled accordingly):

- corrects the MXG value of SMF70WLA in PDB.RMFINTRV

to contain the IBM value and the label now reads

SMF70WLA='DEFINED*CAPACITY*IN MSU*AVAILABLE*TO CPC'

- and creates new variable ZOS70WLA in PDB.RMFINTRV

ZOS70WLA='DEFINED*CAPACITY*IN MSU*AVAILABLE*TO MVS'

to contain the value that you really want, the MSU

capacity of this MVS System, so you can compare this

MVS System's MSU usage (MSU4HRAV/MSUINTRV) with its

MSU capacity (ZOS70WLA). Both SMF70WLA and ZOS70WLA

variables are kept in the PDB.RMFINTRV dataset

So now: NOTE: after Change 20.168:

SMF70WLA is the Defined Capacity of the LPAR

ZOS70WLA is the same as SMF70WLA

MSU4HRAV is MXG's 4-hour average hourly MSU

MSUINTRV is the MSU count for this RMF interval.

SMF70LAC is IBM's 4-hour average hourly MSU

Thanks to Pat Curren, SuperValu Inc, USA.
Change 19.082 Support for HMF Subtypes 29, 30, and 31 create threee new

DIFFHMF MXG datasets:

EXTYHMFT Subtype "dddddd" DATASET Description

EXTYHMFU 29 TYHMFT TYPEHMFT CNT2 COMPRESSION ENTRY

EXTYHMFV 30 TYHMFU TYPEHMFU CNT2 IFENTRY

IMACHMFU 31 TYHMFV TYPEHMFV CNT2 SYSGROUP/CNTSYS

VMACHMF Datasets TYPEHMFT and TYPEHMFU have accumulated counters

VMXGINIT so their sort macros _STYHMFT and _STYHMFU were added to

May 14, 2001 the DIFFHMF member.

Thanks to Perry Lim, Union Bank of California, USA.

Thanks to Theo Peelen, Rabobank, THE NETHERLANDS.
Change 19.081 Support for DB2 SMF 102 IFCID 096 was mis-aligned. Field

VMAC102 QW0096WF should have been &PIB.4. instead of 2, and a two

May 10, 2001 byte reserved field was not input after QW0096RC.

Thanks to John Mourtgos, Albertsons, USA.

Change 19.080 NPM processing with TYPS28 invoked only _S028IN7 macro to

TYPS28 sort the NPMINPMT dataset; instead, it should invoke the

May 10, 2001 _S28 macro so that all NPM datasets are sorted to the PDB

DD name.

Thanks to Sue Kemper, Universal City Studios, USA.
Change 19.079 JCL with comments to run ASUMUOW using batch pipes or

JCLUOWP pipes plex. SAS Institute has enhanced their product at

May 9, 2001 our request so that it interfaces with IBM's BatchPipes

product; this example shows how to use SAS and pipes to

significantly reduce run time and physical I/Os. The SAS

support for BatchPipes will be available in SAS Version 9

but if there is enough demand to Technical Support at SAS

for support, a "hot fix" for SAS 8.2 could be possible.

There are 3 jobs and they must all run concurrently.

-READDB2 reads the DB2 SMF data, and, using a view,

passes DB2ACCT to a SORT which outputs into the PIPE for

DB2ACCT and uses a pipe fitting to harden the DB2ACCT

dataset.

-READCICS reads the CICSTRAN data and again, using a

view, passes the data the SORT which then outputs into

the PIPE for CICSTRAN and hardens the CICSTRAN dataset.

-ASUMUOW uses the PIPEs from READDB2 and READCICS to read

the DB2ACCT and CICSTRAN datasets and create ASUMUOW.

Note the SPININ and SPIN DD usage in ASUMUOW allows the

SPIN dataset to be a GDG for ease of recovery.

The hardening via a pipe fitting is certainly optional

but does not materially affect the run, time. In theory,

when the sort of CICSTRAN ends, so does ASUMUOW.

Thanks to Chuck Hopf, MBNA, USA.

Change 19.078 Truncated type 14 record caused INPUT STATEMENT EXCEEDED

VMAC1415 error because MXG did not validate the real length with

May 9, 2001 the length fields in the record. This rare bad record is

now detected and deleted with an MXG message but the rest

of the SMF file will now be read.

Thanks to Howard Unich

Change 19.077 IBM made changes to the SMF 120 record (Websphere CB) and

VMAC120 now with actual records, the MXG design was revised, as

May 9, 2001 only five datasets are now created:

May 11, 2001 TYP120CC - Container and Class information, from either

Subtype 2 (Container Activity) or Subtype 4

(Container Interval). Variable SM120STY can

be used to identify which event created the

observation; the interval records will also

have DURATM,SM120SST,SM120SET non-missing.

TYP120CM - Class and Method information, from either

Subtype 2 (Container Activity) or Subtype 4

(Container Interval). Variable SM120STY can

be used to identify which event created the

observation; the interval records will also

have DURATM,SM120SST,SM120SET non-missing.

TYP120SA - Server Activity from subtype 1

TYP120SC - Communications Session from subtype 1

TYP120SI - Server Interval from subtype 3

Thanks to Martyn Jones, ABN AMRO, THE NETHERLANDS.
Change 19.076 The STRTTIME/ENDTIME values in CICSTRAN segments could be

VMAC110 later than the SMFTIME of the physical record; the MXG

May 8, 2001 conversion from STCK(GMT) to LOCAL did not include the

Leap Seconds. The revised equation is now:

STRTTIME=STRTTIME+MCTMNTAD-MCTMNLSO;

Thanks to Ralph Alcorn, Safeway, USA.

Change 19.075 TSO/MON variables were input but not kept in TSOMCALL.

VMACTSOM These variables are now labeled and kept:

May 7, 2001 TSMPEMCT TSMPEMTM TSMPRTYP TSMPSDCT TSMPSEQN TSMPSWCT

TSMPTRAN TSMPURR

Variable TSMPURR=00x observations do not have counts in

the LONG, TRIV, or NONTRIV transaction counts; those

counts exist only if the '01'x bit is on in TSMPURR.

Thanks to Gerry Girard, Canadian Utilities, USA.

Change 19.074 KEEPALL=YES is now specified in the VMXGSUM invocation in

ASUMCICS these ASUMxxxx members that are all included in JCLPDBx

ASUMDB2A examples. Using KEEPALL=YES bypasses the execution of

ASUMDB2B many DATA steps by VMXGSUM, saving CPU time in these ASUM

ASUMJOBS members. (The prior KEEPALL=NO default caused steps to

ASUMTMNT be executed to build a KEEP= list that was used only for

May 7, 2001 the INPUT dataset to prevent variable not found errors in

subsequent PROC MEANS executions.)

-In ASUMJOBS, IF JSTRTIME=. was changed to IF INITTIME=.

to eliminate jobs that did not initiate more robustly.

Change 19.073 Support for DCOLLECT APAR OW48529 which documents the

FORMATS value of 3 for DSCAVAIL as "Continuous Preferred" so the

Apr 18, 2001 MGDCODV format was updated to decode that value.

Thanks to Jim Petersen, HomeSide Lending, USA.

Change 19.072 USERADD=HSM, resulting in _IDHSM, but in VMACHSM the IF

UTILBLDP statement is looking for _IDHSMDS.

May 2, 2001 Also, COMPLETE has five macro names, now generated.

Thanks to Wayne Bell, National General Insurance Co., USA.

Change 19.071 To allow for the override of _IDTMNT with IMACTMNT

ASMFTAPE Line 53 ( MACRO _IDTMNT 238 % ) must move before the

Apr 26, 2001 %INCLUDE(VMACSMF,VMAC21,VMACTMNT);

Thanks to Normand Poitras, IBM Global Services, USA.

Change 19.070 The _BTY78SP BY list for TYPE78SP was not complete enough

VMAC78 to remove duplicate records, so it was revised to be:

WEEKBLD MACRO_BTY78SP SYSPLEX SYSTEM STARTIME READTIME JOB

MONTHBLx SUBPOOL %

APR 26, 2001 with the addition of SUBPOOL. Since TYPE78SP is optional

job-level subpool monitoring, this exposure is minimal,

but since TYPE78SP is a part of the BUILDPDB process, the

BY lists for it in the WEEKBLDx and MONTBLx also had to

be updated.

Thanks to Iven Willy, Fortis Bank, ENGLAND

Change 19.069 The BY-list MACRO _BFDRDSF had DSNAME instead of FDRDSN

VMACFDR as the name of the variable, causing DSNAME NOT FOUND.

TESSUSR1 Added TYPSFDR to test stream for _S, _B macros.

Apr 26, 2001

Thanks to David Ehresman, University of Louisville.
Change 19.068 Format $MG073CD for type 73 records was updated to

FORMATS include 23X Internal Coupling Peer.

Apr 12, 2001

Thanks to Jerry Urbaniak, Acxiom CDC, USA.

Change 19.067 Preliminary support for BMC Mainview Batch Optimizer, BMO

TYPEMBO that will replace HiperCache product. BMO records quite

Apr 6, 2001 different; code works but at Alpha test site now.

Thanks to Jim Petersen, HomeSide Lending, USA.

Change 19.066 GOPTIONS statement was mis-located; it should be located

GRAFRMFI after the %SYSPROD(GRAPH) statement. Only impact was if

Apr 6, 2001 you did not have SAS/GRAPH on your system.

Thanks to Art Hunter, Penn Mutual Life Insurance Company, USA.

Change 19.065 NTSMF Object NETWORK INTERFACE is now NETWORKINTERFACE

VMACNTSM and PAGING FILE is now PAGINGFILE, both without the old

Apr 6, 2001 blank, requiring the test for object name to

now look for either spelling.

Thanks to Bob Gauthier, Albertsons, Inc, USA.
Change 19.064 Cosmetic, to avoid confusion. In this example JCL for a

JCLTREND TRENDing, the DISP=OLD on //CICSTRAN and //WEEK is not

Apr 6, 2001 needed, as both are input-only in that job, and so they

were changed to DISP=SHR.

Thanks to Art Hunter, Penn Mutual Life Insurance Company, USA.
Change 19.063 SAS Version 8.2 Spurious NOTE "might be uninitialized".

VMXGWORL Fortunately, there is no impact, other than the printing

Apr 6, 2001 of several new NOTES on the SAS log, and SAS Technical

Apr 9, 2001 Support now acknowledges the note should not have been

Jun 11, 2001 printed and SAS be revised to recognize that NOBS will be

initialized by the NOBS=NOBS parameter.

The MXG change was to initialize the NOBS variable before

the CALL to prevent the compiler notes.

Read on, only if details interest you.
Some of the new NOTES include these:

546: LINE AND COLUMN CANNOT BE DETERMINED

NOTE: NOSPOOL IS ON. RERUNNING WITH OPTION SPOOL MAY

ALLOW RECOVERY OF THE LINE AND COLUMN WHERE THE ERROR

HAS OCCURRED.

NOTE: 546-185: THE VARIABLE NOBS MAY BE UNINITIALIZED.

Enabling the SPOOL option did print the source statement,

which was inside the VMXGWORL macro, which MXG uses to

figure out if observations are in "WorL", i.e., in the

"_W" OR the "_L" dataset macro. That code:

DATA;

CALL SYMPUT('MXGOBS',NOBS);

____

546

STOP;

SET CONTENTS NOBS=NOBS;

is code originally recommended by SAS as a safe way to

set macro variable &MXGOBS non-zero if there are obs in

dataset "CONTENTS", to set it zero if there are 0 obs,

or to not-fail if there is no "CONTENTS" dataset.

The NOBS variable in our SYMPUT is uninitialized when the

CALL SYMPUT is seen, but SET CONTENTS NOBS=NOBS populates

variable NOBS, so MXG's logic works just fine.

If we moved the CALL to be after the SET, NOBS would

have been populated, but that logic won't work here:

If the CALL is after the SET, the CALL statement

won't be executed when there are zero observations

in CONTENTS or when CONTENTS dataset doesn't exist.

SAS added this new "may be" note to correct a problem

where it an uninitialized variable was not identified,

but that fix unintentionally fired spuriously here, and

SAS will correct the compiler to recognize the NOBS=NOBS

will populate the CALL statement, even when the CALL is

seen before the SET statement.

To eliminate the printing to these notes SAS V8.2, MXG

simply added a compiler faker statement:

IF NOBS=. THEN NOBS=.;

before each of the two CALL SYMPUTs in member VMXGWORL

to satisfy the compiler's need for NOBS to appear in an

assignment statement; this will work now and when SAS has

fixed the spurious NOTE.

11Jun01: The extraneous %PUT statement was deleted:

%PUT BARRY DEBUG &MXGLYES= &MXGWORL= &MXGOBS=;
Change 19.062 MXG 19.01 only. Change 19.059 introduced an error when

VMACSOLV temporary variable MONTH was changed to numeric. Now, it

Apr 5, 2001 is reverted back to character but renamed MONTHSL.
Change 19.061 IMS 01 records with the recovery bit on were deleted,

ASMIMSL5 causing differences in observation counts in IMSSUMSO,

ASMIMSL6 IMSMERGE, and NODTOKEN. The Branch statement (at line

Apr 5, 2001 1444 in ASMIMSL6, line 1415 in ASMIMSL5), following the

TM MSGFLAGS,MSGFNRQU statement, was commented out to

prevent the incorrect deletion of valid 01 records.

NOTE: JUL 11: This change was in error and was undone by

Change 19.135.

======Changes thru 19.060 were in MXG 19.01 dated Apr 4, 2001======
Change 19.060 Variable BLKSIZE in the optional TYPE30_D => PDB.DDSTATS

VMACEXC1 dataset is wrong in OS/390 R2.10 and z/OS; I input the

Apr 4, 2001 new 8-byte SMF30XBS as floating point with RB8, causing

values of -1E64 or +1E18, as the input should have been

binary &PIB.8. However, IBM uses the first bit as a flag

that the block size was changed, and then I re-discovered

that SAS cannot store all digits of a field input as PIB8

when the first bit is turned on:

X = '8000000000006D10'X; /*hex literal */

Y = INPUT (X,&PIB.8.); /*input as binary*/

Z = MOD(Y,8000000000000000X); /*get the 6d10 */

returns z= 28762 under PC SAS,

z= 27904 under OS/390 SAS,

but z= 27920 is the correct value for '6D10'x.

so the actual INPUT was revised to use &PIB.7.

Fortunately, BLKSIZE/MULTSIZE variables are rarely used.

Thanks to Rob Gibson, CentreLink, AUSTRALIA.
Change 19.059 Compiling of all MXG members that process SMF records has

VMACF127 uncovered a few conflicts where variables are defined as

VMACLDMS numeric in one record and character in another record.

VMACMOUN Renaming the variable in the more-seldom-used product

VMACDECS eliminate the possible exposure.

VMACRMDS VMACF127 - Not-kept DEVNUM renamed.

VMACROSC VMACLDMS - JESNR is now a numeric variable.

VMACSOLV VMACMOUN - Variable UCBTYPE is now a numeric variable.

VMACAIMR VMACDECS - Variable DSORG now DSORGDEC.

VMACLMS VMACRMDS - Not-kept RECSEQNO renamed.

VMAC102 VMACROSC - Not-kept DELETE renamed.

VMACHBUF VMACSOLV - Not-kept YYYY now numeric.

VMAC90 VMACAIMR - Not-kept YY1-SS1 and YY2-SS2 now YY-SS.

VMAC90A VMACORAC - Not-kept Reserved variables renamed.

Apr 4, 2001 VMACLMS - Not-kept DSTYPE renamed to DSTEMPTY.

VMAC102 - Not-kept VALUE renamed VALUE4BY.

VMACHBUF - RECTYPE renamed RECTYPEC.

VMAC90 - Not-kept DOMFLAG renamed.

VMAC90A - DOMFLG renamed DOMFLG90.
Change 19.058 If you changed the PDB2ACC default from PDB to DB2ACCT,

JCLTEST6 the JCL TEST programs failed, because MXG had failed to

JCLTEST8 provide a //DB2ACCT DD statement in some steps.

Apr 4, 2001

Thanks to Jesse Gonzales, Gap Inc, USA.
======Changes thru 19.057 were in MXG 19.01 dated Apr 3, 2001======
Change 19.057 The NTCONFIG dataset only recorded model/speed/etc for

VMACNTSM the first four CPUs; now CPUNUM,CPUSPED,FAMILY,MANUFAC

Mar 31, 2001 variables exist for 32 processors.

Thanks to Bob Gauthier, Albersons, Inc, USA.

Change 19.056 Protection for invalid ALOCTIME in type 30 records, while

VMAC30 IBM investigates the cause. Step records with ALOCTIME

Mar 31, 2001 that is a fraction of a second earlier than the INITTIME

are not possible (steps initiate first, then allocate,

and then load), but are written by OS/390 R2.10. The

MXG logic must compare those times to determine the step

ALOCDATE and LOADDATE (because ALOC/LOAD have only times

with no dates in type 30s), and it concluded "INIT Today,

ALOC Tomorrow" when the ALOC Time was earlier than INIT.

The IBM error of the earlier ALOC time causes MXG to add

one day to the ALOCTIME variable, which then caused the

DSENQTM to be 23:59 hh:mm, ALOCTM to be -23:59, and the

EXECTM could also be very large, positive or negative.

Knowing that it will take IBM time to diagnose and fix

their eror, I have revised the MXG logic to be smarter.

Now, if the INITDATE and TERMDATE are the same, then the

ALOCDATE and LOADDATE are known so the "date bump" logic

is bypassed (all seen observations fell into this case).

So only when the TERMDATE is a day or more later than the

INITDATE will the INITTIME, ALOCTIME (and LOADTIME) be

tested, and their dates are now bumped only if the delta

is more than 5 seconds, so small errors in the time value

in the SMF record won't cause the algorithm to misfire.

Note Sep 25, 2001: IBM APAR OW50134 acknowledges their

error, but that APAR resolution is "FIN", Fixed in Next.

Thanks to Andrew Hebden, Barclays, ENGLAND.

Change 19.055 -Change 18.233 documented new SYNC59 parameter, but it was

VMXGDUR actually added until this change. SYNC59 argument values

VMXGSUM can be:

Mar 30, 2001 N - do nothing.

Y - add 1 Minute to time

nnn - add nnn minutes to time

and a null value is the same as N.

-Additionally, a typo for TEMP02 option that caused error

FILE DDD.MXGSUM1.VIEW IS SEQUENTIAL when TEMP02 was used

was corrected.

Thanks to Karen Florup, Fidelity Investments, USA.
Change 19.054 MXG 18.10-18.18. MXG creates duplicate observations in

VMAC115 MQ-Series dataset MQMMSGDM, because there were duplicate

Mar 29, 2001 _ETY1152 macro executions. Delete the first invocation

of _ETY1152 macro (line 598), leaving one at line 639.

OBSERVATION COUNT CHANGE: MQMMSGDM fewer obs.

Thanks to Jun dela Rosa, U.S. Customs Service, USA.

Change 19.053 TCP SMF118 ERROR.4. HFS FILE TWO NAME ERROR message may

VMACTCP be created-in-error, if the second HFS filename is first

Mar 29, 2001 in the SMF record. MXG protection logic (for invalid

offset values) tested IF COL LE ... (which assumed that

COL would increase as the record was read. But now that

records with the physical positions reversed are found,

changing those tests to IF 205 LE ... will protect for

invalid offsets, and let MXG find the name segments in

whatever order IBM writes them in their SMF record.

The only impact of this error was that one or both HFS

filenames would be blank.

Apr 9, 2003: IBM APAR PQ73030 will correct the offsets,

which should only be non-zero for a RENAME event.

Thanks to Bruce Widlund, Merrill Consultants, USA.

Change 19.052 INVALID DATA for MOUNSMND/MOUNEMND occurs if those dates

VMACMOUN are nulls; one pair of PD4 INPUT was protected with "??",

Mar 29, 2001 but now all PD4 INPUTs are protected.

Thanks to Normand Poitras, IBM Global Services, CANADA.

Change 19.051 Support for APAR OW46622 identifies Address Spaces that

VMAC79 have Temporal Affinity (see also OW45238). No code was

Mar 28, 2001 changed, since R791FLG and R792FLG variables already are

input and kept, and bit 7 ('.......1'B) is the flag.

Change 19.050 Support for Landmark's The Monitor for IMS V1.1 records.

EXTIMCH Use TYPSTIMS to create and deaccumulate these datasets:

EXTIMCJ TIMSCH History Statistics

EXTIMCJD TIMSCJ Transaction Statistics

EXTIMCK TIMSCJD Transaction Statistics - Detail

EXTIMCKD TIMSCK Database Statistics

EXTIMCL TIMSCKD Database Statistics - Detail

EXTIMCL1 TIMSCL Buffer Statistics

EXTIMCL2 TIMSCL1 Buffer Statistics - First Pools

EXTIMCL3 TIMSCL2 Buffer Statistics - Second Pools

EXTIMCM TIMSCL3 Buffer Statistics - Third Pools

EXTIMCN TIMSCM Input Messages

EXTIMCO TIMSCN Interval Statistics

EXTIMCP TIMSCO Output Messages

EXTIMCT TIMSCP PSB Completion

EXTIMCU TIMSCT Thread Termination

EXTIMCUD TIMSCU PST Statistics

EXTIMCX TIMSCUD PST Statistics - Detail

IMACTIMS TIMSCX Exception Alerts