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

Change 26.224 NMON variables that did not have a decimal point in the

VMACNMON data were incorrectly input by MXG's 6.1 format, so they

Oct 2, 2008 were small by a factor of 10, and fields with more than

6 digits were truncated; both errors were due to the use

of INPUT(field,6.1) syntax, which divides by 10 when the

field does not contain a decimal point, and only reads in

the first six digits. Each variable in each MXG dataset

has now been validated against the NMON xls file after

this (embarrassing!) correction, and all are created with

INPUT(field,16.0) syntax.

Thanks to Steven Olmstead, Northwestern Mutual, USA.
Change 26.223 Support for NSM VMWARE ESX 2.5.5 formerly a/k/a TNG has

EXTVW020 ten new datasets for these new objects:

EXTVW021

EXTVW022 dddddd dataset description

EXTVW023

EXTVW024 VW020 VW020 VMWARE ENGINE CPU

EXTVW025 VW021 VW021 VMWARE ENGINE DISK

EXTVW026 VW022 VW022 VMWARE ENGINE MEMORY

EXTVW027 VW023 VW023 VMWARE ENGINE NETWOR

EXTVW028 VW024 VW024 VMWARE ENGINE SYSTEM

EXTVW029 VW025 VW025 VMWARE VM CPU

FORMATS VW026 VW026 VMWARE VM DISK

IMACTNG VW027 VW027 VMWARE VM MEMORY

VMACTNG VW028 VW028 VMWARE VM NETWORK

VMXGINIT VW029 VW029 VMWARE VM SYSTEM

Oct 3, 2008

Thanks to Michael Kynch, International Paper, USA.
Change 26.222 Extremely large values in CPUIFATM, CPUIFETM, IFAUNITS in

VMAC7072 TYPE72GO observations in an interval in which an operator

Sep 30, 2008 varies a CP engine on or offline were caused by invalid

values in R723IFAT and R723IFCT. IBM determined that the

CONFIG command invokes IRAEVCFG to recalculate RMCTADJC,

and when IWMRCOLL is invoked, IRAWRARC converts these

service units into microseconds using RMCTADJC (SU_SEC).

In the specific case, RMCADJC was x'194' prior to vary

and was x'166' after, which caused IFAT and IFCT to be

lower in the second IWMRCOLL, creating a "negative" value

i.e., first bit on, which MXG sees as a large positive.

IBM said it is not possible to fix because the microsecs

are correct based on the current RMCTADJC value; however

IBM support noted that the service unit values in fields

R723CIFA and R723CIFC were correct because they are not

adjusted by RMCTADJC, so IBM's permanent solution is for

MXG to recalculate CPUIFATM and CPUIFETM from service

units and to no longer use R723IFAT and R723IFCT values.

The defective fields, R723IFAT and R723IFCT were the

original IFA times, from which MXG IFAUNITS/IFEUNITS

were originally created. The recommended fields now

used, R723CIFA and R723CIFC were added by the APAR

that also added the zIIP service unit values that MXG

has always used to create the zip CPU times, so it is

consistent now to use all those service unit fields for

both zAAP and zIIP CPU times and service units.

This change implements that IBM solution.

Jul 29, 2010: Variables R723IFAT and R723IFCT are set to

a missing value to avoid confusion. The

APAR mentioned was OA13499, Change 24.046!

Thanks to Dianne Gamarra, IBM Level 2 Support, USA.

Thanks to Frank De Bree, DEXIA, BELGIUM.

Thanks to Christine De Clercq, DEXIA, BELGIUM.

Thanks to Eugent Van Ossalaer, DEXIA, BELGIUM.

Change 26.221 Support for IBM DS8000 2107 SAN Disk Controller stats in

EXSVCCP SVCPerfStats xml files, creates five statistics datasets:

EXSVCMD MACRO INFILE DDDDDD DATASET

EXSVCNO

EXSVCPO _TSVCMD SVCMDISK SVCMD SVCMDISK

EXSVCVD

IMACSVC _TSVCNOD SVCNODE SVCCP SVCCPBSY

TYPESVC SVCNO SVCNODE

TYPSSVC SVCPO SVCPORT

VMACSVC

VMXGINIT _TSVCVD SVCVDISK SVCVD SVCVDISK

Sep 28, 2008

Oct 20, 2008 The support for this data source requires an extra file,

named TEMPSVC, which is written to and read from, to

prevent thousands of lines to be written on the SAS log.

For ASCII execution,

FILENAME TEMPSVC 'C:\tempsvc' LRECL=52;

For z/OS execution,

//TEMPSVC DD UNIT=SYSDA,SPACE=(CYL,(100,100)),

// RECFM=VB,LRECL=512,BLKSIZE=0

Both SVC 4.1 and SVC 4.2 data has been tested.
The order of the SVCMDISK, SVCNODE, or SVCVDISK DD is

not important; use DD DUMMY if you don't want to read

an XML file. Example JCL to process SVC data:
// EXEC MXGSASV9

//PDB DD DSN=YOUR.SVC.OUTPUT.PDB,DISP=(NEW .....

//TEMPSVC DD UNIT=SYSDA,SPACE=(CYL,(100,100)),

// RECFM=VB,LRECL=512,BLKSIZE=0

//SVCMDISK DD DSN=YOUR.MDISK.FILE01.DATA,DISP=SHR

// DD DSN=YOUR.MDISK.FILE02.DATA,DISP=SHR

// DD DSN=YOUR.MDISK.FILENN.DATA,DISP=SHR

//SVCNODE DD DSN=YOUR.MDISK.FILE01.DATA,DISP=SHR

// DD DSN=YOUR.MDISK.FILE02.DATA,DISP=SHR

// DD DSN=YOUR.MDISK.FILENN.DATA,DISP=SHR

//SVCVDISK DD DSN=YOUR.MDISK.FILE01.DATA,DISP=SHR

// DD DSN=YOUR.MDISK.FILE02.DATA,DISP=SHR

// DD DSN=YOUR.MDISK.FILENN.DATA,DISP=SHR

//SYSIN DD *

%INCLUDE SOURCLIB(TYPSSVC);
This was my first venture into reading XML files; these

are directly created by the disk controller monitor, and

no predecessor "flat file" exists. Unfortunately, these

XML documents are not "well-formed" which could have been

directly read with the SAS XML engine; a well-formed XML

document has a matching end-tag for each start-tag, but

these documents often have only the start-tag. SAS does

provide a separate facility for these "non-generic" XML

documents, but it involves writing a tag-specific XML map

document that tells SAS how to read the XML document, but

that would require a significant redesign of MXG to have

a matching pair of "documents", a program and an XML map,

for each of the XML files to be read, with new naming .

conventions, etc. Instead, I wrote this support in SAS

data steps, using SAS NAMED INPUT (well suited to the XML

data format of tag1="value1" tag2=="value2"). Also, as

the monitor data is accumulated, additional DATA steps

would be required after the initial input.

One real negative of having to read XML documents instead

of a simple binary file is the massive increase in data

volume. For example, the VDISK file contained 1,143,405

physical records, but there were only 70,160 observations

created from that XML file.

Part of that volume is due to the monitor's design: it

creates a separate document for each interval, but all of

the documents must be read and sorted so the values can

be deaccumulated. There were 400 mdisk documents daily,

which were concatenated and read in a single data step,

but that generated 160,000 lines of the SAS log, because

each of those 400 input events not only print the file

name being read, but repeats the full "file list" of all

400 files! As a result, that first data step is wrapped

in an OPTIONS NONOTES to suppress that unwanted printing.
Users HAVE experienced problems attempting to ftp the xml

files to z/OS, because the files are "unix-format" files

that are created on Windows, and they are terminated ONLY

with LF (0Ax) and not the normal-for-windows-files CRLF

(0D0Ax).
One user was able to ftp the xml files to z/OS using:

ascii

quote site recfm=fb lrecl=2000 blksize=2000

put stats.xml 'uuuuuuuu.stats.xml' lf

where the z/OS ftp server was IBM FTP CS V1R8.
However, another user's ftp failed with IBM FTP CS V1R7.

(The ftp executed, but created a single record with the

'0A'x treated as data, and that record was truncated at

the LRECL length. That user found this IBM documentation

note in the IP User's Guide and Commands manual:

"The z/OS FTP server supports only the CRLF value for

incoming data."

After using a hex editor to change '0A'x to '0D0A'x they

were able to ftp the IBM xml file to the IBM ftp server.
This Windows command will change the '0A'x to '0D0A'x:

TYPE unix_file | FIND "" /V > dos_file

so the file can be ftp'd to an IBM ftp server on z/OS.
And for completeness, if the LF-only file is on a unix

system, you can use this Unix command to convert to CRLF:

unix2dos old.xml new.xml

prior to the ftp-ing.

Thanks to Stephen Hoar, Lloyds TSB, ENGLAND.

Thanks to Steve Foskett, Lloyds TSB, ENGLAND.

Thanks to MP Welch, SPRINT, USA.
Change 26.220 Example report for Service Class percent CPU busy revised

ANALSRVC to show how to change the interval of the report, and the

Sep 27, 2008 default now produces hourly percent busy, and EXCSP are

added to the totals for each interval.

Thanks to Lisa Lawver, Land's End, USA.
Change 26.219 Change 26.101 was not implemented; the semicolon at the

VMXGFOR end of %VMXGFOR was still present. However, only very

Sep 26, 2008 old user code in tailoring library are exposed, since

all %VMXGFOR calls were removed in all MXG code in 2003

by Change 20.327. Note that Change 23.127 also claimed

of have removed this semicolon, but it didn't!

Thanks to Pius Nwaobasi, IBM Global Services, USA.
Change 26.218 RMF III variables ASIRNM, Reporting Class Name and ASIRDE

VMACRMFV Reporting Class Description were blank due to a misplaced

Sep 24, 2008 IF statement.

Thanks to Betty Wong, Bank of America, USA.

Change 26.217 Revised QA JOB stream example, and cosmetic cleanups.

ANALCNCR The old multi-step JCL used for MXG QA tests were needed

BATDOIT back in SAS V6 because it couldn't handle a single step,

JCLQASAS but for some time the PC QA stream has run only a single

JCLQAWPS SAS datastep. First one-step z/OS runs failed with JCL

PRODSRCE issues, because the QA "PDB" data library is used with

PRODTEST multiple LIBREFs (PDB,MON,TUE..,WEEK1..,MONTH...) but on

QASAS z/OS you couldn't use the same temporary DSN. Finally,

TESTANAL Chuck figured out what JCL referbacks were needed, so the

TRNDCICX PROC COPYs (a holdover from when the multi-step required

UTILVREF them) could be eliminated, and they were really a killer;

VMXGCICI PC run time of the QA dropped from over an hour to only

Oct 21, 2008 10 minutes; z/OS run time dropped from xx to yy.

Nov 15, 2008 QASAS now documents the MXG QA job stream in comments.

BATDOIT is the batch file I use to run QASAS.

PRODTEST is the IEBUPDTE-format directory used in QA job.

PRODSRCE creates PRODTEST from c:\QA\prodtest directory.

-Many members still had SASAUTOS=SOURCLIB in OPTIONS or in

JCL examples, but MXG's CONFIGV9 or AUTOEXEC now set all

options, including SASAUTOS=(SASAUTOS SOURCLIB) so these

old examples were actually wrong. Their existence in the

ANALxxxx member actually caused errors when they reset

SASAUTOS to only SOURCLIB, preventing %TRIM and other SAS

%MACROs that are provided in their SASAUTOS to be found.

-JCL with // EXEC SAS and // EXEC SAS,OPTIONS= ... were

replaced, where appropriate, with // EXEC MXGSASV9.

Many of these old examples also had //SOURCLIB or even

//SASLIB (archaic since SAS V5); all of those DDs were

deleted from examples as they are contained in MXGSASV9

JCL procedure example.

These members were cosmetically revised:

achap21 achap31 achap32 adoctrnd aixpds analbnc1

analbnch analcm29 analnpmr analnspy analpdsm analrrtm

analturn analvary analvm analvmdy analvmos asummips

docgraf doctrend exitmon6 grafhsm grafregr graftalo

graftmnt graftrnd grafwork grafworx jclpdb multivol

newsltrs rexxtes6 rexxwlm sas5fix1 senddata trndtmnt

typedms typeslri typsims1 utildocv utilspac utilvone

vmacndm vmxguse vmxgvtoc vmxgvtof xcompall xibmfdp

xjclcomp xmacsar xnpmsess xsyslog zrbbuild zrbjcl

zrbrpt1 zrbrpt2 analsupr

-VMXGCICI caused WARNING on COLLTIME when VMXGSUME used;

COLLTIME should be only in SUMBY and DATATIME= so it was

removed from ID statement.

-ANALCNCR caused WARNING on TIMESTMP when VMXGSUME used;

old logic similar to VMXGCICI was revised.

-COMPALL was tested, creating 1871 datasets in a single

DATA step compiling all MXG datasets created from SMF:

Compiler Platform Run Time Memory Required
SAS 9.1.3 Win/XP 75 seconds 1100 MB

WPS 2.2 Win/XP 120 seconds same box

SAS 9.1.3 z/OS 93 seconds 1145 MB

WPS 2.2 z/OS 32 minutes 1024 MB

Thanks to Chuck Hopf, Bank of America, USA.

Thanks to MP Welch, SPRINT, USA.

Thanks to Rich Anderson, SAS Technical Support, USA.
Change 26.216 -The ZIPUSED MSU was incorrect; obviously, CPUZIPTM should

ASUMMIPS have been used instead of CPUIFATM.

Sep 23, 2008 -If the same name was used for both a Service Class and a

Sep 28, 2008 Reporting Class, the PDB.RMFMSUSE dataset had incorrect

values in RPRTCLAS, CPUTM, and the MSU and MIPS used.

-Change 26.131 added ZIP/ZAP metrics, but only to _RMFMIPS

causing UNINITIALIZED VARIABLE messages when _SMFMIPS was

executed. Now, both _RMFMIPS and _SMFMIPS report on all

three engine types.

Thanks to Don Goulden, SAS Institute, USA.

Thanks to Robert Kuhne, Excelon Corp, USA.
Change 26.215 NDM-CDI subtype 'UC' was not output, because it was not

VMACNDM in the initial test for known subtypes, but it was in the

Sep 23, 2008 test and is now output in the NDMAE dataset.

Thanks to Jerry Urbaniak, Acxiom, USA.

Change 26.214 Protection for invalid extended segment did not cover

VMAC1415 all cases; protection and error message revised, could

Sep 17, 2008 still cause INPUT STATEMENT EXCEEDED RECORD error.

Thanks to Mayer Rosenthal, Infocrossing, USA.

Change 26.213 Support for new data in NTDS and ASP.NET Applications

VMACNTSM objects in NTSM adds these new variables:

Sep 16, 2008 -Dataset ASPNETAP new variables:

Sep 17, 2008 ASPARWTB ASPACMLU ASPACMLB ASPACPLU

ASPACPLB ASPACTTR ASPACATR ASPAOCTR

-Dataset NTDS new variables:

NTDSLNCS NTDSLCCS NTDSLNSC NTDSDPRO NTDSTGNC NTDSTGHS

NTDSLVUR NTDSTURP NTDSDWFN NTDSDSFN NTDSDRFN NTDSSAEL

NTDSSREL

Also, the XDS and LDAP Binds variables no longer exist.

-Dataset MEMORY had all variables missing when NRDATA=40,

due to my careless testing.

Thanks to Lisa E. Van Allen, Boeing, USA.

Thanks to James A. Young, Boeing, USA.

Change 26.212 Change 25.308 for SAS V9.2 corrected three instances of

VMXGSUME %ELSE %THEN %DO statements to %ELSE %DO, but two members

UTILBLDP were overlooked, VMXGSUME and UTILBLDP.

Sep 16, 2008 The symptoms of the V9.2-only error is this message

Sep 18, 2008 ERROR: THERE IS NO MATCHING %IF STATEMENT FOR THE %THEN.

A DUMMY MACRO WILL BE COMPILED.

Thanks to Kim Westcott, OFT, State of New York, USA.

Thanks to Stan Dylnicki, Royal Bank of Canada, CANADA.

Change 26.211 Cosmetic. Labels for G3DTIN01-07, G4DTIN01-07 were blank

VMACBVIR (they were caught in QA reports, but I overlooked them!).

Sep 16, 2008 Some duplicate labels were also removed.

Thanks to Markus Bansemir, HUK-Coburg, GERMANY.

Change 26.210 Support for Landmark The Monitor for DB2 V 4.1 raw data.

VMACTMDB -Dataset TMDBD7P adds new variables:

Sep 18, 2008 D7QAASC D7QAAWLG D7QAAWTI D7QAAWTJ D7QAAWTL D7QABPID

D7QADBID D7QAOBID D7QAOCUR D7QAOTSN D7QAOTTY D7QASDB2

D7QASDYN D7QASFL1 D7QASFL2 D7QASTAB D7QASTET D7QATRET

D7QAUDEA

-Dataset TMDBDB adds new variables:

DBACTRTE DBACTREE DBACSVPT DBACRLSV DBACRBSV DBACAWTK

DBACAWTM DBACAWTN DBACAWTO DBACAWTQ DBACARNK DBACARNM

DBACARNN DBACARNO DBACARNQ DB1ZIIP DB2ZIIP DBTZIIP

DBEZIIP DBFIL71 DBFIL72 DBFIL73 DBFIL74 DBAXAWFC

DBAXFCCT DBAXIXLE DBAXIXLT DBSETCPR DBDCLGTT DBDEGDTT

DBCRESEQ DBALTSEQ DBDROSEQ DBPRRESI DBALTVW DB0112IW

DB0112SC DB0112CC DB0112OF DB0112LN DB0112OH DBASHSQL

DBASLSQL SQLIDLEN SQLIDNAM

-Dataset TMDBDA2 adds new variables:

DAMSPSRB DAMSZSRB DADSPSRB DADSZSRB DAISPSRB DAISZSRB

DXSPSRB DAXSZSRB DASSPSRB DASSZSRB DAXSETCP DAXDCLGT

DAXDEGDT DAXCRESQ DAXALTSQ DAXDROSQ DAXPRESI DAXALTVW

DASEDFAL DASEDPGE DASEDFRE DASEDYNP DASECFAL DASECPGE

DASECFRE DAISTCOL DADNDBA DADPOOL DAGSFLMG DABSTLPL

DABPFIX DABVDQB DABSLA DABPGST DABGLGG DABGLHS

DABGL2H DABGLP1 DABGLP2 DABGLP3 DABGLU1 DABGLS1

DABGLS2 DABGLS3 DABGLN1 DABGLN2 DABGLN3 DA3STHWB

DA3STHWF DA3STHWC DA9STCX4 DAJSLSUS DAJSLOGW DAJSCIWR

DAJSSERW DAJSTHRW DAJSBPAG

Thanks to Martin Legendre, Regie des rentes du Quebec, CANADA.
====== Changes thru 26.209 were in MXG 26.08 dated Sep 12, 2008=========
Change 26.209 Enhancement for reading DB2 SMF records adds new parms:

READDB2 SMFOUT= DDNAME to which SMF records that met selection

Sep 12, 2008 criteria will be written
Change 26.208 Variables SMF30MLS and MEMLIMIT are now kept in BUILDPDBs

BUILD005 PDB.STEPS dataset. Previously, they were kept only in

BUIL3005 PDB.SMFINTRV and PDB.TYPE30U6.

Sep 11, 2008

Thanks to Paul Naddeo, FISERV, USA.
Change 26.207 Support for Thruput Manager Subtype 7, and new fields:

EXTPM701 -Dataset TPMXSLM new variables

EXTPM702 TPMSLXGN='EXECUTION*START*TIME'

EXTPM703 TPMSLXGF='EXECUTION*END*TIME'

EXTPM704 While the DSECT used LXTN,LXTF, those datetime fields do

EXTPM705 already exist, and these new fields, while DSECT'd as

EXTPM706 TODSTAMP, in fact, contain only TIME12.2 time-of-day.

IMACTPMX -Support for subtype 7 creates six new datasets:

VMACTPMX dddddd Dataset Description:

VMXGINIT TPM701 TPM0701 SERVER ENVIRONMENT

Sep 12, 2008 TPM702 TPM0702 GENERAL SERVICES QUEUE

TPM703 TPM0703 1ST DISCRETIONARY QUEUE

TPM704 TPM0704 SERVICES GROUP QUEUE

TPM705 TPM0705 JESPLEX MEMBER STATUS

TPM706 TPM0706 INTERVAL DATA

Thanks to Scott Barry, SBBWorks, Inc, USA.

Change 26.206 CICS/TS 3.2 BMC optional CMRDATA increased to 256 bytes

IMACICMR as CPU time fields were increased from 4 to 8 bytes, but

Sep 5, 2008 MXG's IMACICMR had not been updated for 3.2, causing

ERROR: INVALID STRTTIME when IMACICMR was tailored and

read 3.2 data. Turns out IMACICMR never decoded times

correctly, even with earlier CICS releases, but now both

old and new records are correctly decoded. There are 16

undocumented bytes at the end of the CMRDATA segment that

will be decoded if they are ever populated by BMC.

Thanks to Barry T. Mueller, RiteAid, USA.

Change 26.205 Change 26.115 erroneously added SYSNAME to the BY list

WEEKBLDT for TYPE892 dataset, causing WEEKBLDT to fail with

Sep 4, 2008 ERROR: VARIABLE SYSNAME NOT FOUND.

Thanks to Mark W. Brown, CapGemini, ENGLAND.

Change 26.204 New fields and new subtypes for Shadow USER SMF records:

EXSHDW05 -New variables in SHADOW01 dataset:

EXSHDW18 SM01ADCT=*ADABAS*COMMAND*COUNT'

IMACSHDW SM01CLRC=*CLIENT*READ*DATA*COUNT'

VMACSHDW SM01CLWT=*CLIENT*WAIT*TIME'

VMXGINIT SM01HONA=*HOST*NAME*CLMI'

Sep 3, 2008 SM01LNID=*CLIENT*LAN*NETWORK*USERID'

SM01SRCP=*SRB*CPU*TIME'

-New variables in SHADOW02 dataset:

SM02CLRC='CLIENT*READ*DATA*COUNT'

SM02CLWT='CLIENT*WAIT*TIME'

SM02ENZC='ENCLAVE*ZIIP*TIME*ON CP'

SM02ENZI='ENCLAVE*ZIP*CPU*TIME'

SM02ENZQ='ENCLAVE*ZIP*QUALIFIED*CPU TIME'

SM02MXUS='MAX*INTERVAL*CONCURRENT*USERS'

SM02RPCU='CURRENT*NUMBER*EXECUTING*RPCS'

SM02RPHW='RPC*HIGH*WATER*MARK'

SM02SLCP='SSL*CPU*TIME'

SM02SRCP='SRB*CPU*TIME'

-New SHADOW05 dataset for SHADOW NON SOAP REQUEST:

SM0501CR='WWW RULE*CRITERION*MATCH*STRING'

SM0501EU='RUNTIME*MVS*USERID*IN EFFECT'

SM0501RL='WWW RULE*EVENT*PROCEDURE*MEMBER NAME'

SM0501RS='WWW*RULE EVENT*PROCEDURE*SET NAME'

SM05ABCD='TRANSACTION*ABEND*CODE'

SM05ABRS='TRANSACTION*REASON*CODE'

SM05ADLT='TRANSACTION*CONNECT*TIME*LOCAL'

SM05AUTH='CLIENT*AUTHORIZATION*STATUS'

SM05CLIP='CLIENT*IP*ADDRESS'

SM05CLIP='CLIENT*IP*ADDRESS'

SM05CLUS='CLIENT*USER*ID'

SM05CNID='CONNECTION ID'

SM05DBCP='DB2*CPU*TIME'

SM05ELTM='TRANSACTION*ELAPSED*TIME'

SM05ENCP='ENCLAVE*CPU*TIME'

SM05INUR='ORIGINAL*INBOUND*URL*VALUE'

SM05IPAC='IPADDRESS*OF*CLIENT*HEX'

SM05IPAD='IP*ADDRESS'

SM05LGTM='TRANSCTION*CONNECT*TIME*GMT'

SM05LSCR='WWW RULE*CRITERION*MATCH*STRING'

SM05LSEU='RUNTIME*MVS*USERID*IN EFFECT'

SM05LSRL='WWW RULE*EVENT*PROCEDURE*MEMBER NAME'

SM05LSRS='WWW*RULE EVENT*PROCEDURE*SET NAME'

SM05MTCT='COUNT OF*URL*MATCHES*PROCESSED'

SM05NTCP='NETWORK*CPU*TIME'

SM05OHCP='OTHER*CPU*TIME'

SM05PDSS='PRODUCT*SUBSYSTEM*NAME'

SM05RDTO='TOTAL*BYTES*SENT*INBOUND'

SM05RESC='COUNT OF*URL*RE-SCANS'

SM05RPCP='USER*PROGRAM*CPU*TIME'

SM05RXCP='SHADOW/REXX*CPU*TIME'

SM05SLCP='SSL*PROCESSING*CPU*TIME'

SM05SMID='HOST*SYSTEM*SMFID'

SM05SRCP='SRB*CPU*TIME'

SM05TRRC='OVERALL*RETURN*CODE'

SM05TRRS='REASON*CODE'

SM05TRST='HTML*STATUS*CODE'

SM05USR1='USER*DATA*AREA*1'

SM05USR2='USER*DATA*AREA*2'

SM05WRTO='TOTAL*BYTES*WRITTEN'

-New SHADOW05 dataset for SHADOW Z/SERVICES:

SM18ABCD='TRANSACTION*ABEND*CODE'

SM18ABRS='TRANSACTION*REASON*CODE'

SM18ADLT='TRANSACTION*CONNECT*TIME*LOCAL'

SM18AUTH='CLIENT*AUTHORIZATION*STATUS'

SM18CLIP='CLIENT*IP*ADDRESS'

SM18CLUS='CLIENT*USER*ID'

SM18CNID='CONNECTION ID'

SM18DBCP='DB2*CPU*TIME'

SM18ELTM='TRANSACTION*ELAPSED*TIME'

SM18ENCP='ENCLAVE*CPU*TIME'

SM18ENZC='ENCLAVE*ZIIP*TIME*ON CP'

SM18ENZI='ENCLAVE*ZIIP*CPU TIME'

SM18ENZQ='ENCLAVE*ZIIP*QUALIFIED*CPU TIME'

SM18INUR='ORIGINAL*INBOUND*URL*VALUE'

SM18IPAC='IPADDRESS*OF*CLIENT*HEX'

SM18IPAD='IP*ADDRESS'

SM18LGTM='TRANSCTION*CONNECT*TIME*GMT'

SM18MTCT='COUNT OF*URL*MATCHES*PROCESSED'

SM18NASP='WEB*SERVICE*NAME*SPACE'

SM18NTCP='NETWORK*CPU*TIME'

SM18OHCP='OTHER*CPU*TIME'

SM18PDSS='PRODUCT*SUBSYSTEM*NAME'

SM18PORT='CLIENT*AUTHORIZATION*STATUS'

SM18RCCT='TRANSACTION*COUNT*FOR*SUMMARY*RECORD'

SM18RCTY='CLIENT*AUTHORIZATION*STATUS'

SM18RDTO='TOTAL*BYTES*SENT*INBOUND'

SM18RPCP='USER*PROGRAM*CPU*TIME'

SM18RXCP='SHADOW/REXX*CPU*TIME'

SM18SLCP='SSL*PROCESSING*CPU*TIME'

SM18SMID='HOST*SYSTEM*SMFID'

SM18SRBT='SRB*CPU*TIME'

SM18SRCP='SRB*CPU*TIME'

SM18TRFX='SOAP*FAULT*TEXT'

SM18TRRC='OVERALL*RETURN*CODE'

SM18TRRS='REASON*CODE'

SM18TRSE='SOAP*FAULT*LENGTH'

SM18TRST='HTML*STATUS*CODE'

SM18TYPE='CLIENT*AUTHORIZATION*STATUS'

SM18VDIR='VIRTUAL*DIRECTORY'

SM18WRTO='TOTAL*BYTES*WRITTEN'

SM18WSNA='WEB*SERVICE'

SM18WSOP='OPERATION*NAME'

SM18WSTG='TARGET*SYSTEM*NAME'

Thanks to Scott Chapman, American Electric Power,USA.
Change 26.203 Support for z/VM 5.4 (COMPATIBLE back to MXG 25.05) adds

EXMTRMCC new 5.4 variables and two new datasets, but there are