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

-Macro _SUOWTMO was reading the CICSTRAN dataset and not

MONITASK; SET _LCICTRN was changed to SET _LMONTSK.

Thanks to Erling Andersen, SMT Data A/S, DENMARK.
Change 22.298 MXG 22.11 only. A missing @; caused SMF type 6 records

VMAC6 with the "PrintWay" File Transfer Section to fail with

Nov 22, 2004 INPUT STATEMENT EXCEEDED error

Thanks to Randy Shumate, LEXIS-NEXIS, USA.

Change 22.297 Short 'IF' NDM/CDI record caused INPUT STATEMENT EXCEEDED

VMACNDM error; instead of the expected 64 byte NDMRUID, there

Nov 17, 2004 were only 45 bytes at the end of the record. INPUT of

NDMRUID is now conditional if it exists.

Thanks to Bernie Mazur, Bank of Montreal, CANADA.
Change 22.296 Processing CMRDETL data on ASCII platform failed because

VMACMVCI the INFILE statement and VMXGRFV attributes contained the

Nov 17, 2004 BLKSIZE= parameter, which is not supported on ASCII:

Perhaps ASCII SAS should be smart enough to disregard,

instead of fail, but since ASCII files are nothing but

a single string of bytes, BLKSIZE has no meaning there.

Thanks to Steven Olmstead, Thompson, USA.
Change 22.295 Variable ACCIPAD, IP Address, is now output in WSFEVTPR

VMACWSF as well as WSCEVTSC.

Nov 16, 2004

Thanks to Stephane Attouz, Infosud, FRANCE

Change 22.294 -Support for APAR PQ73385 which adds data to IFCID 217 and

VMAC102 to IFCID 225.

VMACDB2 -Support for APAR PQ87848 which adds data to IFCID 173 to

Nov 12, 2004 monitor Dynamic SQL Statements that exceed RLF ASUTIME

Limit (and issued SQLCODE905).

-Support for APAR PQ91101 which adds more data to IFCID

225, and which added QISESTMT to DB2ACCT dataset.
Change 22.293 In PDB.ASUM70PR and PDB.ASUMCEC, all LP0xxxxx variables

VMXG70PR for LPARNAME='PHYSICAL' are always missing values; at one

Nov 9, 2004 time, Amdahl used zero for a real LPAR, so MXG test for

LPARNAME didn't populate LP0xxxx variables unless it was

a real Amdahl LPARNUM=0). But since Amdahl is now long

gone, it makes sense to populate the PHYSICAL LPAR data

in the LP0xxxx variables for consistency and so that the

newer PDB.ASUM70LP dataset can contain the data for the

LPARNAME='PHYSICAL'. In PDB.ASUM70PR and PDB.ASUMCEC,

the existing LPPUPDTM and PCTPOV variables are unchanged,

and the calculations that included LPPUPDTM and LP0UPDTM

are revised to not double account the PHYSICAL time.

Thanks to Anthony Lobley, EDS, ENGLAND.
Change 22.292 Debugging PUT statement is no commented out.

VMACSFS The Xerox SFS architecture is being replaced by an export

Nov 8, 2004 file produced by the Xerox Docutech 6135 network printer.

Thanks to Robert McElhaney, Texas Workforce Commission, USA.

Change 22.291 -Concatentating TNG files from multiple systems caused

VMACTNG incorrect results when the sets of fields were different;

Nov 8, 2004 values from the first system could be propagated into the

subsequent system's output, because the initialization DO

loop limit had the instance macro (&NT018I for example)

but the upper value should be %EVAL(&NT018I*&MAXROWS).

In addition, the init of the NTxxxINM variables had to be

relocated into their own DO loop.

-New NT Platform Names of NTW400I, WNS502I, and XPP501I

are all supported.

-Also, NT Platform Names are now defined in a new _NTPLAT

macro, so that new TNG names can be added in only one

place, or can be added in your IMACKEEP member.

Thanks to Peter Krijger, ANZ National Bank Limited, NEW ZEALAND.

Change 22.290 Enhancement for MQM processing creates new IHDRMQM exit

IHDRMQMH that can be used to select MQ records using variables

VMAC115 MQMSSSID SUBTYPE SYSTEM STARTIME

VMAC116 SM115REL (blank if ID=116)

VMXGINIT SM116REL (blank if ID=115)

Nov 5, 2004 Either member IHDRMQMH can be edited with your selection

logic, or %LET MQCMQMH= %QUOTE(your code;); can be used.

The existing TYPENQM member will process both SMF 115 and

SMF 116 records in one pass.

Thanks to Helmut Roese, COM Software, USA.

Change 22.289 The PDB.RMFINTRV dataset could have duplicate obs for the

VMXGRMFI first hour, if your RMFINTRV logic summarized your detail

Nov 5, 2004 RMF data (e.g., written at 15 minutes, but you tailored

IMACRMFI or your RMFINTRV memer to create HOURLY data),

but only if some SMF records for that interval were in

yesterday's SMF and the rest of that interval's records

were in today's SMF data. The MXG logic to calculate the

MSU4HRAV was at fault, incorrectly combining the data in

SPINRMFI with today's data.

Thanks to Normand Poitras, IBM Global Services, CANADA.

Change 22.288 Comments in CICINTRV show how to create PDB.CICINTRV from

CICINTRV SMF data; CICINTRV is automatically included by TYPS110

VMAC110 and by BUILDPDB/BUILDPD3.

Nov 5, 2004 Default in VMAC110 now creates WORK.CICSACCT instead of

PDB.CICSACCT, so that a //PDB DD is not required if you

run %INCLUDE SOURCLIB(TYPE110). CICSACCT has had zero

observations for years, but historically was written to

the //PDB library.

Thanks to Neil Ervin, Charles Schwab, Inc, USA.
Change 22.287 Enhanced %VMXGPRAL utility. New option to run PROC FREQ

VMXGPRAL can be used to find out who's writing DB2 SMF 102 Trace

Nov 4, 2004 Records with this example:

%LET MACDB2H %QUOTE(KEEP QWHSSSID QWHSLUNM QWHSLOCN;);

%READDB2(IFCIDS=ALL);

%VMXGPRAL(DDNAME=WORK,NOBS=MAX,NOFREQ=FREQ,

NOPRNT=NOPRNT,NOMEANS=NOMEANS);RUN

- Note: the KEEP statement should almost never be used,

but it turns out that by using MACDB2H to insert

that statement inside the READDB2 processing,

only those variables listed will be output, so

the Trace Datasets won't take much disk space.

I first kept QWHCCV and QWHCCN, but the SMF 102 trace

records do not contain the Correlation Header.

Thanks to Hoang Ho, Experian, USA.
Change 22.286 -Two variables were not converted to EBCDIC when MXG was

VMAC80A executed on ASCII platforms:

Nov 4, 2004 RACF07DT ENTITYNM

Nov 5, 2004 -Support for RACFTYPE=29 DTP adds variable RACF29AD to the

Nov 8, 2004 TYPE8020 and TYPE8021 datasets.

Nov 9, 2004 -RACFTYPE=42 DTP segment variable CLASNAME was not kept.

Nov 10, 2004 In almost all datasets with variable CLASNAME, it comes

Dec 10, 2004 from DTP=17 segments. But datasets TYPE8024 and TYPE8X24

Dec 7, 2006 can have CLASNAME from DTP=21 and/or DTP=42 segments:

- TYPE8024 dataset can have both 21 and 42 segments, and

can have more than one DTP=42 segment, so that dataset

contains variables CLASNAME,CLASNAM1-CLASNAM4 from any

DTP=42 segments, and variable CLASNA21 from DTP=21s.

- TYPE8X24 dataset contains only DTP=21 segments, so the

variable name kept is CLASNA21, so as to matches the

name in the related TYPE8024 dataset.

This text was revised 2006, no code was changed.

-Multiple RACFTYPE=24 DTP segments, up to fifteen, are now

supported in RALTER (TYPE8020) and RDEFINE (TYPE8021) in

variables RESBYTE1-RESBYTEF and RESNAME1-RESNAMEF, like

the handling of multiple RACFTYPE=44 DTP segments in the

ADDUSER (TYPE8010) and ALTUSER (TYPE8013) datasets. The

choice of 15 is arbitrary, and could be increased if it

is needed, or a secondary dataset could be created in the

future if there are many more repeated segments in one

SMF 80 record.

-Multiple RACFTYPE=25 DTP segments in RALTER/DELMEM are

also supported, as above.

-Note that some cases of multiple segments currently will

be created as separate observations in additional data

sets, rather than separate variables. Specifically:

Dataset Command Multiple Segments

TYPE8X13 ALTUSER 40s

TYPE8Y13 ALTUSER 41s

TYPE8X24 SETROPTS 21s

-Dataset Label for TYPE8X13 and TYPE8Y13 were corrected to

ALTUSER (incorrectly had SETROPTS).

-Variable RACF07DT is now correctly input and it length is

set at $80 to hold installation data.

-Variable RESBYTE uninitialized was corrected.

Thanks to Erling Andersen, SMT Data A/S, DENMARK.

Thanks to Larry Krause, Rite-Aid, USA.

Change 22.285 Label values for two variables were incorrect/incomplete

VMAC7072 and are revised to this description:

Nov 3, 2004 PCTDLCDE='CPU DELAY*PERCENT*NOT INCLUDING*WLM CAP'

PCTDLPDE='PCT WHEN*RESOURCE GROUP*MAXIMUM*ENFORCED'

And PCTDLPDE is not a delay; only PCTDLCDE will show

if there actually was a delay.

Thanks to Don Deese, (CPExpert), Computer Management Sciences, USA.
Change 22.284 Allocation Recovery subtype 7 (TYPETARC) support was not

FORMATS correct for variables after TARCDSN, now revised to match

VMACTMNT the DSECT. But the SMF records are not always correct;

Nov 2, 2004 many have 0 for DEVNR and following fields, all have ACTN

value 0, and ASID is only two bytes. Those errors in the

SMF record will be corrected in the next ASMTAPEE.

Thanks to Doug Medland, IBM Global Services, CANADA.
Change 22.283 Cosmetic. Error BIT MASK ... TOO LONG caused examination

VMAC1415 of all bit tests and three members were found to have

VMAC63678 bit literals that were not 8 or 16 symbols; fortunately,

VMACF127 none of those tests are currently executed, but the code

Nov 2, 2004 was revised nonetheless:

-TYPE1415 - bad test was inside ISAM code, not used now!

-TYPE6367 - VSAM catalog records no longer exist.

-TYPEF127 - FACOM operating system, probably defunct.

Change 22.282 Variable DATETIME was missing, because MXG code to create

ASUMHSM it from REQUEST was located before REQUEST was created;

Nov 2, 2004 this caused WHERE clause errors in a tailored IMACSHFT

Nov 5, 2004 member that used WHERE clauses and did not expect missing

values in DATETIME (nor should it have, since the error

was in MXG, not in the tailored IMACSHFT!).

-SUMBY FSRTYPE SHIFT logic in the internal invocations of

ANALCNCR had to be revised to remove SHIFT from SUMBY, as

it conflicted with SYNCINTV=YES default in ANALCNCR, and

the recalculation of SHIFT was relocated. This change

also corrected deeper errors, and the number of output

observations in PDB.ASUMHSM is now correct.

Thanks to Karl Lasecki, Chemical Abstracts, USA.

Thanks to Bruce Zink, Honda of America Manufacturing, USA.

Change 22.281 RACF SMF80DTP 44 segment with only SEGNAME and no text

VMAC80A caused *** RACF EV(44) ERROR. INVALID RACFDLNN=0 and

Nov 1, 2004 NOTE: INVALID THIRD ARGUMENT TO FUNCTION SUBSTR... and a

hex dump of each record. Code revised to protect zeroes.

Thanks to Ike Hunley, Blue Cross Blue Shield of Florida, USA.
Change 22.280 NRCPUS calculated in PDB.RMFINTRV using SMF70ONT could

VMXGRMFI have fractional values (0.999) instead of an integer when

Oct 29, 2004 IRD was not involved; the calculation was revised to add

0.005 and FLOOR/1000 to produce the expected integer.

Note that with IRD, fractional NRCPUS is very legitimate.

Thanks to Thomas Heitlinger, FIDUCIA IT AG, GERMANY.

Change 22.279 Member TYPEVTOC is no longer executed in the test stream;

TESTOTHR it caused 0C4s under SAS V9 because of CCHHR= operang,

Oct 28, 2004 but it has been archaic ever since DCOLLECT/TYPEDCOL was

released. Because it is no longer in the test stream,

the three datasets it created VTOCLIST,VTOCMAP,VTOCINFO

will no longer be documented in DOCVER.

Thanks to Randy Shumate, LEXIS-NEXIS, USA.
Change 22.278 In (archaic) VMAC90, variable SMF9029N was changed from

VMAC90 character to numeric in Change 21.320, but if you combine

Oct 28, 2004 TYPE90 built before and after that change, you got the

ERROR: VARIABLE SMF9029N HAS BEEN DEFINED AS BOTH CHAR...

This change replaces SMF9029N with SMF9029X to avoid that

error, but use of VMAC90A is the preferred solution.

Thanks to Andreas von Imhof, Rabobank, THE NETHERLANDS.
====== Changes thru 22.277 were in MXG 22.11 dated Oct 26, 2004=========
Change 22.277 New argument MACFILEX allows you to insert SAS code after

UTILBLDP the SMF header has been read (like MACFILE), for user

Oct 26, 2004 tailoring of what records to read or not to read.
Change 22.276 A utility to analyze the size of SAS data libraries, with

ANALSIZE the number of datasets, number of variables, data bytes,

VMXGSIZE compressed bytes, and average compression percentages.

Oct 26, 2004

Thanks to Chuck Hopf, MBNA, USA.
Change 22.275 The array LCUZ in data step C4 was changed to LCU1-LCU256

ANALPATH and the final report will show up to 256 LCUs if present.

Oct 26, 2004

Thanks to Harald Seifert, HUK Coburg, GERMANY.

Change 22.274 Variables TOTSHARE and TOTSHARC are now kept in both the

VMXG70PR PDB.ASUM70PR and PDB.ASUMCEC so the original and current

Oct 26, 2004 total Weights are available; for summary intervals that

Oct 27, 2004 had more than one RMF record, the weights from the first

record are kept.

Thanks to Chuck Hopf, MBNA, USA.

Change 22.273 The variable PCTCPUBY in QAPMSYST is now set to a missing

VMACQACS value, because there is no "total" CPU busy in QAPMSYST;

Oct 26, 2004 it is still kept so your report programs won't fail with

VARIABLE NOT FOUND errors, but set missing because it was

calculated from SHCPUTM, which is only the SystemTask CPU

time. New PCTCPTBY='PERCENT WHEN*SYSTASK*CPU BUSY' is

now calculated from SHCPUTM.

Thanks to Chris Selley, Zurich, ENGLAND.

Change 22.272 Support for zAAP IFA engines now requires MXG 22.11 due

VMAC30 to this change and change 22.265.

VMAC7072 =TYPE72GO Corrections:

Oct 25, 2004 -New zAAP CPU time CPUIFETM was incorrectly adjusted with

R723NFFI from R723IFCT, but IFCT is the time when zAAP-

eligible work executed on a CP, and that work executes at

the CPU speed, so the NFFI adjustment in MXG was wrong.

-Label CPUIAFTM='IFA*EQUIVALENT*CPU TIME' more accurately

describes the contents of that MXG variable.

-Variables R723IFCT (now, always equal to CPUIFETM), and

R723IFAT (unadjusted, equal to CPUIFATM ONLY if R723NFFI

is 256, and hence probably more confusing that useful),

are both now kept in TYPE72GO dataset.

-Calculation of IFAUNITS, IFEUNITS was corrected, and the

code to subtract IFAUNITS from CPUUNITS was relocated.

=TYPE30 Corrections:

-All TYPE30 IFA/IFE CPU times were wrong: I could blame

IBM, because there are two undocumented bytes after the

SMF30TF2 field that caused misalignment (but my +2 after

the SMF30TF2 was also wrong, it is now +1 for the second

byte of TF2, but now there's a new +2 needed to skip over

those undocumented two bytes). However, my guess that the

new times were like the immediately preceding SMF30CEP

field (input PIB4.6, multiply by 1024) was also wrong;

the new CPU times are PIB4.2 without the multiply).

And the offsets in the SMF manual are wrong starting at

SMF30TF2. (In my defense, Change 22.221 did note that the

changes had NOT been tested with data!).

Thanks to Don Deese, (CPExpert), Computer Management Sciences, USA.

Thanks to Adam Warkow, Citigroup Technology Infrastructure, USA.

Change 22.271 The Macro _LOGSMF, used to read log files (like NDM/CDI)

VMACSMF that have "SMF Records" without the SMF Header, did work

Oct 23, 2004 when last tested, but DATA STEP STOPPED DUE TO LOOPING

error occurred using the TYPENDML example! Inserting

INPUT @; after the ELSE DO; appears to now be required

by SAS, and eliminated that error.

Thanks to Albert Jacobs, KBC, BELGIUM
Change 22.270 22.08-22.10 only. INPUT STATEMENT EXCEEDED RECORD LENGTH

VMACDB2H error with DB2 V8.1 SMF 100/101 records. INPUT of new

Oct 23, 2004 variable QWHSLOCO was PIB4, but the field is only PIB2.

Thanks to Roman Jost, ERGO Integration, NORWAY.

Change 22.269 MXG 22.07-22.10. Six variables in TYPE71 dataset:

VMAC71 LPAPGMN LPAPGMX LPAPGAV LPAFXMN LPAFXMX LPAFXAV

Oct 23, 2004 had missing values, because an extraneous "V" was added

to each variable name in its INPUT statement, when I had

added the IBM SMF field name in comments on each line.

Thanks to Matthew Chappell, Queensland Transport, AUSTRALIA.

Change 22.268 Support for VTS R7.3 adds many statistics to TYPE94 and a

FORMATS few to TYPE94P; some 2-byte fields were expanded to four

VMAC94 bytes, but existing, reserved bytes were used for the

Oct 23, 2004 expansion, so the changes are compatible. You can tell

Oct 27, 2004 that R7.3 has been installed because S94LVVCF=730.

Oct 27: MXG 22.11 input these fields as $HEX2 per IBM doc

but IBM reports show them as decimal values, so

they were changed to PIB2 numeric variables:

S94LVVCM='VTS*CODE*MODIFICATION*VALUE'

S94LVVCF='VTS*CODE*FIX*VALUE'

S94LVLMV='LIBRARY*CODE*VERSION*VALUE'

S94LVLMR='LIBRARY*CODE*RELEASE*VALUE'

Change 22.267 The debugging PUT statement at line 745 should have been

VMACMVCI removed; it could flood sysout with millions of lines of

Oct 22, 2004 text: COL=390 T6ECPRID=F5 AFTER F4X

Thanks to Udo Froehline, Signal Iduna, GERMANY.

Change 22.266 Support for CMF Version 55.04 user SMF record (INCOMPAT).

VMACCMF INPUT STATEMENT EXCEEDED for CMF Version 5504 because the

Oct 22, 2004 BMC user SMF record removed four fields from subtype 1;

CMFREC01 was changed by BPM8956/BPM9152. MXG now INPUTS

those fields only for the old length of CMF01CSL=232.

Thanks to Peter Giles, Centrelink, AUSTRALIA.

Change 22.265 Support for APAR OA09118 adds the Service Definition

VMAC30 Coefficients (CPUCOEFF,SRBCOEFF,IOCOEFF,MSOCOEFF) into

Oct 22, 2004 the SMF type 30 records; these fields are needed now for

Oct 25, 2004 zAAP calculations, but have always been wanted in SMF 30.

-If the SDCs are in the SMF 30 record, variable IFAUNITS

will be non-missing, and variable CPUUNITS will contain

ONLY the CP TCB Service Units (i.e., IFAUNITS will be

subtracted from CPUUNITS if this APAR is installed).

-And if SDC values are present, the MXG-created variables

SRVTCBTM and SRVSRBTM will use the CPUCOEFF/SRBCOEFF from

the SMF record, rather than the &CPUCOEFF/&SRBCOEFF macro

default values of one, and CPUTOTTM will use the correct

SRVTCBTM/SRVSRBTM values. See text of Change 22.022.

-This change replaced Change 22.256.

====== Changes thru 22.264 were in MXG 22.10 dated Oct 13, 2004=========
Change 22.264 Variable QTGSUSLM in DB2STATS was not deaccumulated, so

VMACDB2 it have very large and meaningless values. DIF() logic

Oct 13, 2004 was added.

Thanks to John Shuck, Suntrust, USA.

Change 22.263 Revision of the original ANALDSET (DataSet Analysis) that

ANAL42DS uses the TYPE42DS interval records instead of TYPE1415

Oct 13, 2004 and TYPE64 close records. However, only SMS managed DISK

datasets are captured in TYPE42DS (but then ANALDSET only

reports on CLOSED datasets, so both may be necessary!).

Thanks to Chuck Hopf, MBNA, USA.

Change 22.262 Hardcoded DDNAME of PDB for PDB.DTSLOGPR and PDB.DTSCPU

VMACNTSM were replaced by their symbolic &PNTDTLP and &PNTDTCP.

Oct 13, 2004

Thanks to Matthew Chappell, Queensland Transport, AUSTRALIA.

Change 22.261 The token for dataset TYPE4237 was missing from the _N42

VMAC42 and _S42 macro definitions, so that dataset was not NULLd

Oct 13, 2004 if _N42 was used, or wasn't sorted if _S42 was used.

Thanks to Ambat Ravi Nair, ATOSORIGIN, SINGAPORE.

Change 22.260 -MXG Change 22.221 for z/OS 1.6 IFAs has now been tested

VMAC7072 with real IFAs and found wanting, causing negative values

Oct 12, 2004 in PCTCPUBY and incorrect CPUWAITTM (but only for systems

that actually have an IFA; there are NO errors using MXG

22.08+ with z/OS 1.6 if you do NOT have any zAAPs).

The code has been updated for all three configurations of

Shared/Dedicated and Wait Completion Yes/No, but only the

Shared, Wait Complete=NO data has been validated.

-New variable MXGCIN in TYPE70PR is an attempt to identify

IFAs (which have SMF70CIN='ICF') from ICFs, with values:

'PHY' - Physical

'CP ' - CP Engine

'VM ' - VM Engine

'IFA' - IFA Engine

'ICF' - ICF (Coupling Facilit) or IFL (Linux) Engine

' ' - SPARE Engine

but this is a heuristic algorithm based on my test data,

but could use validation with your system's data.

-New variables IFACROSS and IFAHONOR are now kept in the

TYPE72GO dataset, where they are created, instead of the

TYPE70 dataset, where I originally kept them.

However: it really makes no sense for IBM to have put

the global parameters in the service-class TYPE72GO

records, but since that's where IBM put them, I have

to do the same.

-I originally spelled IBM field R723IFCU as R723IFEU in

TYPE72GO dataset, trying to use "IFE" for IFA-Eligible

and "IFA" for IFA-Actual, but the variable name is now

changed back R723IFCU to be consistent with the IBM name.

-The test data was from an early system, and these notes

may not be relevant to current IFAs, but are documented

in case these data are observed:

- During Startup Interval, the IFAWAITM is slightly

larger (tenths of a second) than the Interval Duration

which causes PCTIFABY to be slightly negative. While

I could detect and set PCTIFABY to zero, I will wait

to see if this is actually necessary with your data.

- The PHYSICAL LPAR data has LCPUADDR values that are

totally unexpected: 0,2,5,7,8,10,12,14,16,18,21,23,24,

26,28,30,32,34,37,39,40,42,44,46,48,50,53,55,56,60,62

for the 32 engines! While this has no impact, it does

look strange; IBM says its working as designed.

- Update from Martin Packer, Oct 17, 2005:

It turns out there is an explanation: when LCPUADDR

is displayed as a hex value, the first nybble is the

book number minus one, the second is the CPU number.

So the values above are for book 1 thru book 4, with

hex CPU numbers of 00,02,05,07,08,0A,0C,0E

-See Change 22.272, which corrected further errors and is

required for zAAP IFA processors.

Thanks to Don Deese, (CPExpert), Computer Management Sciences, USA.
Change 22.259 Variable NDMCPUTM had missing value in NDMPT dataset; a

VMACNDM circumvention now detects that "CPUTIME=" text is present

Oct 12, 2004 and inputs NDMCPUTM.

Thanks to Andreas von Imhof, RaboBank, THE NETHERLANDS.

Change 22.258 All TRND.... members were enhanced with macro variables

TRND.... &TRENDINP, &TRENDNEW, and &TRENDOLD (all of which are set

Oct 12, 2004 to "TREND" by default) so that you can override the MXG