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

then SMF70MDL contains only the CPC MODEL CAPACITY, and

SMF70HWM has the CPC PHYSICAL MODEL IDENTIFIER.

-STFBIT03='SMF70LAC*NO LONGER*INCLUDES*CPU WAIT?'

-SMF70Q00='PERCENT*WHEN*IN READY*LE N CP-S' thru variable

SMF70Q12='PERCENT*WHEN*IN READY*LE N+12 CP-S' now track

the PCTRDYWT, but based on IN-READY greater than the

number of CP engines.

-TYPE70PR dataset:

-LPARCLND='CAPACITY*LIMIT*NOT*DEFINED' is now reserved.

so the new label (new in Sep 2012, MXG 30.07) reads

LPARCLND='RESERVED*FIELD*SINCE*Z/OS 1.7' and the value

is now a blank instead of either Y or N.

-Note that if LPARWTFD='Y' (WAIT TIME FIELD DEFINED?) is

true, then LPARCPUX (SMF70BND) contains the maximum

logical processors defined as shown at the HMC, starting

with z900 processors. The Active Logical Processors

have an online time SMF70ONT greater than zero, which is

how/why MXG now counts NRCPUS.

-TYPE70Y2 Crypto dataset, new variables:

R702NH2B='SHA-256*DATA*BYTES*HASH'

R702NH2C='SHA-256*CALLS*TO*HASH'

R702NH2I='SHA-256*PCMF INSTR*USED TO*HASH'

-TYPE74CA dataset, new variable:

R745DCCU='CONFIGURED*CONTROL*UNIT*TYPE'

-TYPE791/TYPE792: (Note added Dec 12, 2005):

-MXG used variable name suffix TIFE (Eligible CPU) but

the IBM field name is TIFC, and my choice caused some

confusion, so the IBM Field name of TIFC is now used.

-R791NFFI/R792NFFI normalization factor was added and

is used to normalize R791TIFA/R792TIFA times back to

CP seconds.

-TYPE88 dataset, new variables:

SMF88EAF='IXLOGR*STAGING*ASYNC BUFFER*FULL'

SMF88ERS='RESERVED*WRONG NAME' SMF88EDO in manual,

but that field name already exists. Investigating.

-TYPE94 dataset, new variables:

S9SDEMN1='SECURE*DATA*ERASE*MOUNTS*DC 1'

S9SDEMN2='SECURE*DATA*ERASE*MOUNTS*DC 2'

S94XLCSG='VTC 0*WRITE*PROTECT*MODE'

S94XLCSH='VTC 1*WRITE*PROTECT*MODE'

S94XLCSI='VTC 2*WRITE*PROTECT*MODE'

S94XLCSJ='VTC 3*WRITE*PROTECT*MODE'

S94XLCSK='VTC 4*WRITE*PROTECT*MODE'

S94XLCSL='VTC 5*WRITE*PROTECT*MODE'

S94XLCSM='VTC 6*WRITE*PROTECT*MODE'

S94XLCSN='VTC 7*WRITE*PROTECT*MODE'

-TYPE99U7 dataset Subtype 7 new variable

SM997SCS='SUB*CHANNEL*SET='

-TYPE99UA dataset Subtype 10 - need test data to decode

-TYPE1415 dataset, new flag variable ('Y',' '):

SMF14LGE='DSNTYPE*LARGE*FORMAT?'

Note that if SMF14LGE='Y', the value in variable TTRN

will contain 'TTTR', and if EXTNDSEQ='Y' the value in

TTRN will contain 'TTTT', the total number of tracks

used across all volumes.

Oct 5, 2005: Original Reserved Change Number replaced.
Change 23.131 Support for DB2 IFCID=313 creates T102S313 dataset, with

FORMATS dataset labeled 'CHECKPOING LONG RUNNING UR-S'.

VMAC102

May 24, 2005

Thanks to Christa Neven, KBC Bankverzekeringsholding, BELGIUM
Change 23.130 To update the ITRM data dictionary for MXG datasets, all

IMACACCT of my code and datasets created by that code are examined

IMACICD6 and numerous corrections were made as a result of that

IMACICMR process. Most are spelling errors, but many cause the

RMFINTRV variable to be not-kept, or incorrectly labeled, etc.

VMAC110 VMAC110: FILADDCN changed to FCADDCN in CICSRFDI keep.

VMAC30 DSxACT/TCT/TDE/TWT for DSH/DSI/DSJ/DSK FORMATed

VMAC6 DSGTOTMT/DS2/DS3/DS4 formatted.

VMAC7072 DSGTOTWL dual use, now DSGTOTWT kept in CICDS

VMAC80A instead of DSGTOTWL, DGTOTWT labeled.

VMACDB2 VMACICE: SRCEOD changed to SRCEOE in ICEBR8SN keep.

VMACICE IMACICD6: $EBCDUC8. changed to $EBCDIC8.

VMACTPMX IMACICMR: CMDDB2CT formatted TIME12.2.

VMACVMXA IMACACCT: IDMSCPTM formatted TIME12.2. (in comments).

May 24, 2005 VMAC80A: KW24ASTE,KW24KERB kept, labeled in TYPE8024.

CLAS26NM,RES25MEx,RES25TEx labeled in 25/26.

VMACTPMX: TPMUSERC,TPMXPLEX labeled.

VMAC30: SMF30MRD,SMF30MRI formatted TIME12.2

VMAC6: SMF6FTL, leading asterisk removed in label

VMAC7072: IFAWAITM, R723IFAT, R723IFCT formatted TIME12.2

MXGCIN, NRPHYCPS, R723NFFI labeled.

Also NRPHYCPS now labeled in ASUMCEC,ASUM70PR.

VMACDB2: QISESTMT kept in DB2STATS

RMFINTRV: PCTIFABY labeled.

VMACVMXA: APLSDTST labeled.

USAPLxxx temporary variables dropped in

VXAPLCMS/SLM/SLN/SLP/SLO datasets

PCT-prefixed VXAPLSLP/SLO and TICKS labeled.

MRHDRRC labeled

BYTOA and BYFRA are MGBYTES formatted, LENGTH 8

and BFFRA was removed from LENGTH 8.

Stray text in label of PT4ID corrected.

IFINOCWR/IFOUOCWR are kept, logic corrected.

New variables in VXAPLSRV labeled, kept.

Temp variable OLDTODON is dropped from VXBYUSR.

Thanks to Chris Weston, SAS ITRM Development Cary, USA.

Change 23.129 Cosmetic. Label for IPMIGR2 should have been SECONDARY

VMACIPAC as IMIGR1 is 'PRIMARY*MIGRATION*CLASS*NAME'.

May 23, 2005

Thanks to Tom Parquette, AXA Technology Services, USA.

Change 23.128 New z/VM 5.1 1.19 record was misdocumented by IBM, which

VMACVMXA caused ERROR* PROBABLE DATA LOSS DUE TO MONWRITE FAILURE.

May 23, 2005 Correct MRHDRLEN=368 was doc'd as 365, and two bytes at

offset 42 were not listed in the length column, but MXG

was also not guilt-free, as I had guessed wrong at where

those two undocumented bytes were located. Dataset

VXMTRQDC is now corrected.

Thanks to Pat Curren, SuperValu Inc, USA.

Change 23.127 A semi-colon at the end of a %MACRO invocation caused a

VMXGFOR "180" syntax error, and now I know that it is NOT true

May 24, 2005 that every SAS statement ends with a semi-colon!

While MXG Change 20.327 removed all invocations of the

now-unneeded %VMXGFOR macro from all MXG PROC SORTs,

a site with an old PROC SORT DATA=A OUT=B %VMXGFOR; in

their report program failed with "FORCE" underlined.

%VMXGFOR was only needed because Version 5 of SAS did

not support the FORCE keyword; that macro generates

a blank for V5 and "FORCE" with V6 or later.

It turns out the culprit was the addition of the new

%VMXGVERS(23.05,VMXGFOR);

statement after the %MEND; statement in the VMXGFOR

member, added by Change 23.005. It also turns out that

it was that final semicolon after %VMXGVERS() that caused

the error, in this reply from SAS Technical Support:

"The problem is the semi-colons in the autocall source

files that follow the macro call. These semi-colons are

superfluous for the macro call, but not harmless when

contained in an autocall source file. When a macro call

is determined to be the first reference to an autocall

macro, the file containing the autocall macro definition

is processed until the end-of-file is reached and then

the macro is called. In this instance the macro

definition is read and processed. This consumes the

autocall source file up to and including the semi-colon

following the %MEND. Then the following macro call

(i.e., to %VMXGVERS) in the autocall source file is

processed. This consums the autocall source file up to

and including the right parenthesis, leaving the

semi-colon. The dangling semi-colon is then inserted

into the source stream (as model text) and then a call is

placed to the autocall macro that started the process.

This behavior is present in versions 6 thru version 9."

So, a final semi-colon has NEVER been needed after the

invocation of a %MACRO, and none of the examples in the

SAS Macro Manual (yes, we Read The Fine Manual!) show a

semi-colon after the invocation. For example, you can

use %ANALDB2R() and the report program executes!
Fortunately, it appears that only the %VMXGFOR member is

vulnerable, because it inserts text into a SAS statement.

All other VMXGxxxx members that have %VMXGVERS added are

"standalone" executions, and the extra semi-colon, even

though those members are autocalled, is superfluous.
But now I know what caused this strange error, and have

removed the trailing semicolon from the %VMXGVERS call

in the (still-archaic) VMXGFOR autocalled member.

Thanks to Matt Feeney, Defence Department, AUSTRALIA.

Change 23.126 -Dataset PDB.RMFMSUSE contains both Service and Reporting

ASUMMIPS Class obs, but variable RPRTCLAS was not kept, so you

May 18, 2005 couldn't identify which class the observation was for.

May 23, 2005 Now, RPRTCLAS is kept in PDB.RMFSUSE.

May 24, 2005 -Member IMACKEEP was not included, so you could not use

the MACKEEP= to tailor the ASUMMIPS execution. As an

example that you can now use:

//SYSIN DD *

%LET MACKEEP=

%QUOTE(

MACRO _RMFOUT RMFMSUSE %

MACRO _MIPSMSU

IF SYSTEM='TREX' THEN MIPSFACT=6.7;

ELSE MIPSFACT=5.7;

%

);

%INCLUDE SOURCLIB(ASUMMIPS);

_RMFMIPS;

_SMFMIPS

changes the output from PDB.RMFMSUSE to WORK.RMFMSUSE and

changes the MIPSFACT (MIPS per MSU) depending on SYSTEM.

-The default PROC PRINT for RMFMSUSE is now sorted by the

RPRTCLAS variable, so if you have both Reporting Class &

Service Class data, you will get separate reports. Since

they will overlap, having a single report was deceptive.

-The default PROC PRINT for SMFMSUSE did not use _SMFOUT,

causing an error if _SMFOUT was redefined.

Thanks to Dan Case, Mayo Foundation, USA.

Thanks to Chuck Hopf, MBNA, USA.

Thanks to Jim Horne, Lowe's Companies, Inc, USA.
Change 23.125 HSC V6 changed the STCLMU (subtype 4) SMF record, now STK

VMACSTC PTF L1H12EW documents the new record, but that PTF also

May 17, 2005 changes the record again, so records written with HSC V6

without the PTF will produce strange results in STCLMU.

-And, of course, no version flag is in the STK record, so

the (archaic) logic to test the Record Length is required

to determine if this is a valid pre-V6 record, a short

pre-V6 record (fixed by a prior PTF), an invalid HSC V6.0

prior to the PTF, or a valid HSC V6.0 record after PTF.

-And there are undocumented bytes in the record, as well,

between offsets 11 and 16 (decimal).

Thanks to Dean A. Ruhle, JC Penney Co., Inc, USA.

Thanks to Michael Gresham, JC Penney Co., Inc, USA.

Thanks to David M. Cole, STK, USA.

Change 23.124 -Duplicate SMF type 30 interval records caused duplicate

VMAC30 observations in PDB.SMFINTRV because the revisions in MXG

BUILD005 Change 22.320 removed the NODUP option from the SORT.

May 17, 2005 This change restores the NODUP option.

-The _BTY30UV macro in VMAC30 was revised so the first

five variables match the sort order used in BUILDPDB:

MACRO _BTY30UV READTIME JOB JESNR INITTIME INTBTIME

MULTIDD DESCENDING EXTRADD

just for consistency, even though the PDB.SMFINTRV that

can be created with TYPS30 (or with the _STY30UV macro

invocation) is NOT the same PDB.SMFINTRV dataset that is

created by BUILDPDB:

-The BUILDPDB-built PDB.SMFINTRV has consolidated all of

the "MULTIDD" observations into a single observation.

-The TYPS30/_STY30UV-built PDB.SMFINTRV still contains

all of the additional and confusing "MULTIDD" obs.

Thanks to Joan Nielsen, (i)Structure, USA.
Change 23.123 Variables CPUIFATM and CPUIFETM (total) are added to the

VMXGRMFI PDB.RMFINTRV dataset, and individual workload variables

May 17, 2005 (like BATIFA, BATIFE, etc) with IFA/IFE CPU times added.

Oct 19, 2005: See Change 23.265; 23.123 was incomplete.

Thanks to Andre Baltimore, Unigroup, Inc, USA.
Change 23.122 Datasets PDB.TYPE70LP and PDB.ASUMTAPE were not in the

WEEKBLD default WEEKBLD member, but as they are created in the

WEEKBLDD JCLPDBx daily job examples, they are now added to the

WEEKBLDT weekly example job.

May 17, 2005

Thanks to Hugh Lapham, Royal Canadian Mounted Police, CANADA.

Change 23.121 ERROR: BY VARIABLES NOT SORTED ON DATASET WORK.BOTHCEC is

VMXG70PR corrected by an insertion of a PROC SORT to ensure the

May 16, 2005 order is correct; values for SHIFT were the culprit.

Thanks to Tony Curry, BMC, USA.

Change 23.120 Support for ESS GEPARMKY=004Dx creates ESSMAIL2 variable

IMAC6ESS in TYPE6 dataset when IMAC6ESS is enabled.

VMAC6

May 13, 2005

Thanks to Engelbert Smets, Provinzial, GERMANY.
Change 23.119 Change 23.025 was not tested with TRENDIN data, and the

UTILCONT semicolon after &PDBOUT..ASUMSIZE should not have been

May 13, 2005 there, since the macro code is still part of the SET.

Thanks to Jeffrey A. Harder, Farm Bureau Insurance, USA.

Change 23.118 Processing CICS Journal Records (SUBTYPE=0) didn't output

VMAC110 the last record. The test was changed to

May 12, 2005 IF LOC+GLRHLEN-1 LE LENGTH THEN GOTO JOUR5202;

Thanks to Helmut Roese, COM Software, USA.

Change 23.117 If you built your own program, and had _CDE40 before the

VMAC40 _CDE30 macro, you got ERROR 48-59 with the below two

May 12, 2005 notes:

WARNING: VARIABLE PROGRAM HAS ALREADY BEEN DEFINED AS NUMERIC

ERROR 48-59: THE INFORMAT EBCDIC WAS NOT FOUND OR COULD NOT BE LOADED

because MXG didn't fully protect the variable PROGRAM.

-Per the text of Change 20.243, PROGRAM was added to the

ARRAY statement for character variables in VMAC40 so that

the _CDE40 could be located prior to the _CDE30.

-This is really a bummer, as PROGRAM is not even input in

SMF 40 records, but the code in VMAC40 makes a call on

VMACEXC2, which has a PUT statement in case of an error

in the decoding EXCP segments, and when the PUT was the

first instance of variable PROGRAM, SAS made it numeric

which then spawned numerous other errors when it was

referenced as a character variable.

Thanks to Michael S. Noud, IRS, USA.
Change 23.116 Very bad values for some data fields in TYPE 74 subtype 5

VMAC74 records for HDS on their Tagmastore USP, like negative

May 12, 2005 values for SCTO (R745DTC). Under investigation with HDS.

Reporting site now has a microcode fix which is believed

to correct the error; no fix number at press time.
Change 23.115 The default OPTIONS and OPTIONS2 did not agree with the

ASMTAPEE documentation in Change 23.030, and the internal comments

May 11, 2005 about default options were inconsistent. The comments

May 29, 2005 were clarified, and the default options in OPTIONS and

OPTIONS2 are set as documented, for IBM VTS Systems.

As noted, if you have STC VTS, you must remove DOMXIT to

disable the IBM Volume Mount Exit, because we still have

not been able to find an equivalent Exit in STK's HSC,

but we're still working on that enhancement.

Updated: Jul, 2005. See Change 23.162/23.177/23.230.

-Line 3139 extended into column 72, making it look like a

continuation.

Thanks to Shane Dowling, DEWR, AUSTRALIA.
Change 23.114 DCOLLECT dataset DCOLCLUS, VSAM Dataset Info, was not

DAILYDSN used in the original "Daily Dataset Billing" (JCLDAYDS),

May 11, 2005 but has been added so that it will be there if needed.

Thanks to Chairat Tiajanpan, KCS, Thailand.

Change 23.113 -Zero obs with a Solaris cube. The _UTNGCNT array sizer

ADOCTNG only worked for NT data, so the INSTREAM code was not

EXTNT128 generated due to a missing OUTPUT statement, and the new

EXTNT129 MIB-2 UNKNOWN object was processed last, causing 0 obs.

EXTNT130 New So028 dataset supports the MIB-2 object and new field

EXTSO028 added to existing So027 dataset is now supported.

FORMATS -Cubes with data from multiple days had only last day's

IMACTNG data output. Two tests that previously read

TYPETNG IF NRPAREN GT 1 AND NRSYSTMS GT 1 THEN DO;

VMACTNG appear to be the culprit, and by commenting out to be

VMXGINIT IF NRPAREN GT 1 /* AND NRSYSTMS GT 1 */ THEN DO;

May 10, 2005 data from all days was output. That heuristic was needed

May 23, 2005 early on in TNG support, but I think subsequent redesign

May 28, 2005 eliminated the need for that part of the test to invoke

outputting, BUT PLEASE VALIDATE THAT YOU GET DATA FROM

ALL OF THE SYSTEMS, AND ALL OF THE DAYS IN YOUR INPUT!!

-New NT platform names of NTP500I and WNS502I were added

to the MACRO _NTPLAT to eliminate UNKNOWN PLATFORM msgs.

-Support for new Objects for NT: RAS PORT, MICROSOFT

GATHERER, and MICROSOFT SEARCH.

-May 28: $MGTNGVN Format was completely revised, as two

Solaris metrics were identical in first forty characters:

'Interface Traffic (Lifetime) Collisions %'

'Interface Traffic (Lifetime) Collisions'

causing INSTANCES EXCEEDED error messages when tested.

That %MGTNGVN format, used to lookup the concatenation of

Platform abbreviation, Object Name, and Metric Name, had

only allowed 40 positions for metric name. To eliminate

future duplicate exposures, all TNG cubes were read to

find the maximum metric name of 58 chars, so the format

was expanded to allow 64 char metric names, but with the

2-char platform abbreviation and the 20-character object

name, the "expanded length format" now had DEFAULT=86 in

its VALUE statement. But with only 72 positions of MXG

input text, some of the value definitions had to be split

into two lines, a nasty but necessary implementation.

But then the fun began. Read Change 23.144 for solution.

Since more than 40 bytes of METRIC name are now being

looked-up in the format, data for all past test cubes

was read to find all metrics longer than 40 bytes, and

those 55's format data-values were revised so they would

be found in the new format; the longest was 58 bytes.

But if I missed one, it will show up as an observation

in the UNKNOWN dataset, so please check your SAS log to

make sure I found them all.

Thanks to Michael L. Kynch, International Paper, USA.

Thanks to Peter Krijger, ANZ National Bank Limited, NEW ZEALAND.
Change 23.112 Change 23.070 reset STARTIME for 58,59, and 01 seconds,

VSETZERO but that didn't protect delays beyond 1 second; new data

May 9, 2005 shows that 70 and 72 records with seconds 02 are created;

in fact, the SMFTIME of the 72 subtype 4 was 4.5 seconds

after the interval pop, and that subtype 4 had 00 seconds

for its STARTIME! So the test in VSETZERO is now revised

to set seconds 58 thru 05 back to seconds 00. The main

impact without this change was that the PDB.ASUMCEC had

had two observations, one with 01 seconds, one with 02

seconds as their STARTIME.

Thanks to Diane Eppestine, SBC, USA.
Change 23.111 Support for DB2 V8.1 DB2ACCTP Package Data now validated.

VMACDB2 Change 23.098 guessed wrong, but IBM didn't help; in the

VMACDB2H new IFCID=239 structure, the LENQPAC is zero! But, in

May 9, 2005 a very weak defense of their redesign, there is a very

obscure note that says it is now "legal" to have a DB2

data segment with Length=zero, and it now means: read the

first two bytes at the offset, and use that as the length

of the data segment! So with a hex dump of one of the

new records, the code is now corrected and DB2ACCTP will

be valid for DB2 V8.1 or earlier versions as well.

-There was also an extraneous PUT QWHSRELN= in VMACDB2H

added by Change 23.098, only for DB2 V8.1, but lots of

messages would have been printed, if you had DB2 V8.1,

since it put that message for EVERY SMF 100/101 record!

It was removed by this change.

-Note that this change is required for DB2 V8.1 if there

are ANY package segments in your DB2 records; prior notes

that earlier versions of MXG support DB2 V8.1 are wrong.

Thanks to Steve Olmstead, Thomson, USA.
Change 23.110 Cosmetic. Variable ESMFFAVG was listed in the KEEP list

TYPEVM but was a misspelling and was removed; variables ESMFIAVG

May 5, 2005 and ESMFOAVG are now FORMATed TIME12.2.

Thanks to Sudie Wulfert-Schickedanz, Anheuser-Busch.

Change 23.109 Support for VM:Account product, which reversed the order

TYPEVM of dates from MMDDYY to YYMMDD and writes longer records.

May 5, 2005 This iteration does not support the additional data but

that support will be added in a later change.

Thanks to Richard J. Reents, Abbott Labs, USA.
Change 23.108 -Label was missing for variable PCTCPTBY in VMACQACS

VMACQACS PCTCPTBY='PERCENT WHEN*SYSTASK*CPU BUSY' and "8" in the

VMAC110 label for SYBTAC was changed to *.

VMACDB2 -VMAC110, new Stat variables prefixed DSH/DSI/DSJ/DSK

VMXGRMFI that are time values were not FORMATed TIME12.2;

May 5, 2005 DSxTOTMT variables were not formatted TIME12.2;

May 17, 2005 DSGTOTWT replaces DSGTOTWL in CICDS variable; TOTWL is

a suffix for CICDSPOO variables and had been reused.

-VMACDB2, new 8.1 variable QISESTMT was not kept.

-RMFINTRV, variable PCTIFABY labeled, ZOS70WLA removed.

Thanks to Chris Weston, SAS Institute ITRM Development, USA.
====== Changes thru 23.107 were in MXG 23.04 dated May 4, 2005=========
Change 23.107 Several macro definitions were incomplete or mislocated.

VMACVMXA -MACRO _SAPLSRV statement was missing; its code was

May 4, 2005 inside the MACRO _SAPLEDT definition.

May 16, 2005 -Invocations of _SAPLEDT and _SAPLSDT were missing in

the _DELTALL macro definition.

-The _SSYTSCG and _SSYTSYG macros had the DELTATM located

too late, and it was not set negative when missing to

protect the subsequent divides by DELTATM.

-There is no _SAPLAPL macro, but there's a _VAPLAPL macro

now created. The VMXA design preceded the _Vdddddd

macro definition (lists variables kept in the "dddddd"

token's dataset), and the old VMACVMXA uses _Vdddrrr

macros for domain/record groupings. _VAPLAPL wraps all

of the 25 Application Server _WAPLrrr datasets, each of

which has its own _Sdddddd macro, so that's why there

is on _SAPLAPL sort macro definition.

-A number of ommissions for new variables were fixed.

Thanks to Chris Weston, SAS Institute ITRM Development, USA.

Change 23.106 -Variable TIWRDCT should not have been kept in MONIIDS nor

VMACTMO2 should its second label exist; that name was used twice

May 3, 2005 but was caught in QA and the correct TIIDSWRC/TIIDSWRT,

May 5, 2005 fields were input and labelled, but I failed to clean up

this part of the original duplicate names.

-Label for PAJTDLYT and PAJTDLYC were reversed, and some

lables had blanks instead of '*' SPLIT characters.

Thanks to Chris Weston, SAS Institute ITRM Development, USA.

Change 23.105 TYPE73 variable SMF73CSS, Channel Subsystem ID was moved

VMAC73 to the end of the Channel Path Control Section, if bit 2

May 3, 2005 of SMF73CFL (Hardware allows multiple logical channel