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

EXTMTCIO TMTCIL TMTCIL TMON TCP/IP IL TELNET EVENT

EXTMTCOD TMTCIM TMTCIM TMON TCP/IP IM CSM INTERVAL

EXTMTCIP TMTCMO TMTCIMO TMON TCP/IP IM CSM OWNER

EXTMTCPA TMTCIO TMTCIO TMON TCP/IP IO CISCO

EXTMTCPR TMTCOD TMTCIOD TMON TCP/IP IO CISCO DEVICE

EXTMTCPT TMTCIP TMTCIP TMON TCP/IP IP IP GROUP

EXTMTCIR TMTCPA TMTCIPA TMON TCP/IP IPA IP ADDRESS

EXTMTCIS TMTCPR TMTCIPR TMON TCP/IP IPR IP ROUTING

EXTMTCIU TMTCPT TMTCIPT TMON TCP/IP IPT IP TRANSLATE

EXTMTCIZ TMTCIR TMTCIR TMON TCP/IP IR TRACE ROUTE

IHDRTMTC TMTCIS TMTCIS TMON TCP/IP IS SYSTEM GROUP

IMACTMTC TMTCIU TMTCIU TMON TCP/IP IU UDP GROUP

TYPETMTC TMTCIZ TMTCIZ TMON TCP/IP IZ FTP EVENT

TYPSTMTC Invalid packed dates in IASDAT, IZSDAT, and ILSDAT have

VMACTMTC '101271F0'x instead of '0101271F', causing missing values

VMXGINIT values, and IZFTPTY is sometimes shifted right, but there

Nov 16, 2001 is lots of new data here, especially from SNMP v1/v2 MIB.

Thanks to Julie Haines, Direct Line, ENGLAND.

Thanks to Pete Gain, SAS Software PTY, ENGLAND.

Change 19.224 Support for CICS/TS 2.2 Statistics Record was enhanced

EXCICDSP with new datasets CICDSPOO, CICS Dispatcher TCB Pools to

IMACCICS record the number of TCBs attached, allocated, etc., for

VMAC110 the Open, JVM and HP TCB pools. Now understanding that

VMXGCICI CICS TCB number is no longer valid to identify what is in

VMXGINIT which TCB, the text of Change 19.204 and ADOC110 were

Nov 13, 2001 revised to show that the TCB "Name", rather than number

Nov 19, 2001 determines what is stored in the dsNxxxxx set of CICS TCB

variables: trust the variable's Label, not its number!

-The VMXGCICI member was updated to bring in the twelfth

and thirteenth TCBS

-New (and undocumented) "D2" TCB is now recognized.

The STID=114 EJR and STID=66 STG segments have new fields

added to their existing datasets.

Change 19.223 Invoking _N108 to null out all TYPE108x datasets failed

VMAC108 because the MACRO _N108 statements were wrong - each was

Nov 12, 2001 of the subsequent lines were missing the word "MACRO".

Thanks to Martin Lee, Safeway Stores PLC, ENGLAND.

Change 19.222 -%ANALDB2R WARNING: ARGUMENT 2 TO MACRO FUNCTION and then

ANALDB2R ERROR: FILE WORK.DB2ACCTP.DATA DOES NOT EXIST, if there

Nov 14, 2001 are no observations in DB2ACCTP, but observations were in

Nov 22, 2001 both DB2ACCT and ASUMDB2A, causing USEACCT to be blank,

Nov 26, 2001 causing SKIPPAK to be wrong, which caused the incorrect

open. The logic to set USEACCT and SKIPPAK and the code

that uses then was corrected and made consistent for both

PMACCT01 and PMACCT03 reports.

-%ANALDB2R failed when PMACC01 and PMACC03 were requested,

with ERROR: FILE WORK.ASUMDB2A.DATA DOES NOT EXIST,

because the OPTIONS NODSNFERR NOVNFERR statement was not

executed the second time (after the PMACC01 report was

created, it reset those options to DSNFERR and VNFERR).

Adding the OPTIONS statement inside %MACRO PMACC01 fixed

that error, but uncovered an extra END; statement in the

PMACC03 report, that had to be conditionally generated.

-With PDB=SMF and both PMACC01 and PMACC03 requested, no

package detail was printed, but UNINITIALIZED VARIABLE

log messages were, because the VMXGSUM output of PMACC01

was written to OUTDATA=DB2ACCTP, but that overwrote the

original DB2ACCTP data, and then that summary was used as

the input to PMACC03. Using a different dataset name in

the OUTDATA= statement (and in subsequent references) was

required for both DB2ACCTP and DB2ACCTB, and now they are

OUTDATA=OUTACCTP and OUTDATA=OUTACCTB.

-A conditional execution of a PUT statement was inserted

in the Package Detail.

-Statements were indented to make the logic more obvious.

-Nov 26: Eliminated UNINITIALIZED DATETIME varialbe notes,

two CPUTIME headings became one ELAPSED and one CPUTIME,

and when there's more than a page of package detail, the

headings on package section now propagate to the first

heading lines on the second and following pages.

Thanks to Simone Niemczura, Harleysville Insurance Companies, USA.

Thanks to Andrew Taylor, AXA Shared Servicess Limited, ENGLAND.
Change 19.221 Enhanced support for NPM subtype 18/19x (Exception and

EX028EX1 Resolution events) are now output in eight new datasets

EX028EX2 based on NPMTYPE (LSCDRTYP) value, with detail sets of

EX028EX3 variables from each Volume/AOFTYPE segment. This will

EX028EX4 cause zero observations in datasets NPMEVNET & NPMERNET,

EX028EX5 which are replaced by the new datasets:

EX028EX6 NPMTYPE Exit Dataset Event Description

EX028EX7 24x EX1 NPMEXXPU X.25 (NPSI/XI/3746) PU

EX028EX8 26x EX2 NPMEXXVC X.25 (NPSI/3746) VC

VMAC28 27x,47x EX3 NPMEXNEO Generic NEO link/PU

VMXGINIT 28x,4Cx EX4 NPMEXCSL ODLC LAN

Nov 12, 2001 2Ax,2Bx EX5 NPMEXFRP Frame Relay

49x,4Ax " "

44x,45x EX6 NPMEXTRI NTRI logical/physical link

46x EX7 NPMEXXLK X.25 (NPSI/XI/3746) link

4Bxc EX8 NPMEXETH Ethernet LAN physical link

These Event/Resolution records were not reported as being

a problem, but in validating NPM 2.6 records, INVALID

DATA FOR MDY FUNCTION with NPMTYPE=28x exposed the need

to create a separate dataset for each of these events.

-Variable BASTIME now existsin NPMSUBTY 51x & 62x records,

so the test for NPMSUBTY added by Change 7.237 (!) is now

removed; only BASNCPDT and BASNCPTM GT 0 are now tested.

-Labels for CONTENT*FLAG variables were made consistent

and all are now formatted $HEX2.

-All Byte-Measurement variables are now formatted MGBYTES

so that their values will be printted with K/M/G suffix.

-Four variables previously in Kilo-Bytes are now converted

to contain bytes, and formatted with MGBYTES:

LLBVP1BB LLBVP1NB LLBVP2BB LLBVP2NB

-FORMAT statements were sorted and reorganized.

Thanks to William Sherriff, IBM Global Services, USA.

Change 19.220 SMF type 42 subtype 6 INVALID DATA FOR READTIME message

VMAC42 and hex dump were caused by blanks for both JOB name and

Nov 9, 2001 for READTIME, in a record from (old) DFSMS/MVS 3.1 for a

started task that may have been cancelled/forced. This

change supresses the message and hex dump by inserting

double-question-mark-modifier, but with or without this

change, READTIME is missing in the TYPE42DS dataset for

a record with blanks instead of a time and date.

The blanks could also have been caused by user SMF exits.

Thanks to Jesse Gonzales, The Gap, USA.

Change 19.219 Documentation only. Comments added to identify which of

VMXGUOW the "_K" macros are to be used for what. There is a pair

Nov 9, 2001 of "_Kxxxxxx" macros that can be tailored to control what

additional variables are kept from CICSTRAN, DB2ACCT, and

MQACCT. One is for numeric variables that are summed and

kept in PDB.ASUMUOW from each input dataset:

_KUOWCIC CICSTRAN

_KUOWDB2 DB2ACCT

_KUOWMQC MQACCT

and one is for character variables that are added to the

ID statement and are kept in PDB.ASUMUOW:

_KUOWIDC CICSTRAN

_KUOWIDD DB2ACCT

_KUOWIDM MQACCT

Thanks to Kenneth Johnsonk, Vanguard, USA.
======Changes thru 19.218 were in MXG 19.07 dated Nov 3, 2001======
Change 19.218 Revision to RMF III ASMRMFV program, additional revisions

ADOCRMFV to VMACRMFV will follow. Extensive documentation of the

ASMRMFV changes in ADOCRMFV.

Nov 3, 2001

Thanks to Jerry Urbaniak, Acxiom CDC, USA.
Change 19.217 CPUTYPE='2064'x with Spare CPUs still made PDB.ASUM70PR

VMAC7072 have bad values for LPnDUR and LPnPERCENTAGES. The real

Nov 3, 2001 source of the problem was that the TYPE70PR dataset had

an observation for each spare CPU, with non-zero DURATM,

and the LPARDUR included the DURATION of all the spares.

I considered deleting the spares in the ASUM70PR logic,

but believe many MXG users do their own sums of TYPE70PR,

so it makes more sense to only output observations in the

TYPE70PR dataset for 2064 CPUS for LPARNAME=PHYSICAL (as

it has SMF70ONT=0), or if SMF70CIN NE 'CP' (so ICFs and

anything else will be output) or if SMF70ONT NE 0 (so the

2064s with the APAR will have non-zero ONT for non-spares

and 2064s without the ONT APAR will have missing ONT and

will also be output.

If you have LPnDED='Y' or LPnWAIT='Y' (Dedicated CPUs or

Wait-Complete), then the only PDB.ASUM70PR observations

that have non-missing values for those LPARs will be the

ASUM70PR observation written on the Dedicated LPAR, i.e.,

those with SYSTEM=LPnNAME. For Dedicated/Wait Complete

CPUs, the PDB.ASUMCEC dataset was invented to solve this

problem; read the extensive discussion in the text of the

Change 17.203 that added the creation of PDB.ASUMCEC into

the ASUM70PR logic, and see member ACHAP10 for general

PR/SM CPU measurement discussion.

OBSERVATION COUNT CHANGE: TYPE70PR fewer obs.

Thanks to Bruce Widlund, Merrill Consultants, USA.

Thanks to Joseph Rannazzisi, Salomon Smith Barney, USA.

Thanks to Jim Gilbert, EDS-Sabre, USA.

Change 19.216 MXG ASCII Execution only: R723MSCF in TYPE72GO is wrong,

VMAC7072 but not when MXG runs under MVS. It was INPUT with the

VMAC71 $EBCDIC format, but it is a character-variable-containing

VMAC73 hex-values, formatted with $HEX, and all such variables

VMAC74 MUST be INPUT with $CHAR informat to preserve the bits

VMAC75 and for MXG to be portable across platforms.

VMAC76 Under MVS, $EBCDIC and $CHAR are identical, but on ASCII

VMAC77 platforms, the INPUT must be with $CHAR to preserve the

VMAC78 original bits; if you input with $EBCDIC under ASCII, as

VMAC79 designed, SAS converts '40'x to '20'x for blanks, etc.,

VMAC102 for each byte in the field. Under ASCII, $CHAR stores

TYPEDOS the unmodified hex value in the character variable (and

VMAC102 so does $VARYING).

VMAC110 Don's discovery precipitated an audit of old MXG source

VMAC116 for other cases of incorrect informat: all variables

VMAC22 listed below are now correctly INPUT with $CHAR and

VMAC42 formatted with $HEX; none are important flags, some are

VMAC6 not even kept, many are reserved fields, but a few are

VMAC6156 used to create other (apparently-not-very-important) flag

variables, and since no one else had caught this failure

in MXG transparency across platforms, I feel very lucky!

VMAC80A I should have done this long ago.

VMAC84

VMAC90A VMAC7072: R723MSCF TEMPIOML SMF70PRF SMF70PRF

VMACACF2 SMF72RV5 SMF70V

VMACACHE VMAC71: TEMPIOML SMF71PRF

VMACAPAF VMAC73: TEMPIOML SMF73PRF

VMACAPAF VMAC74: R747PNUM R747PADR R747CNUM R747CADR

VMACBETA VMAC75: TEMPIOML SMF75PRF SMF75RV3 SMF75RVA

VMACCTLG VMAC76: TEMPIOML SMF76PRF

VMACDB2 VMAC77: TEMPIOML SMF77PRF

VMACEREP VMAC78: TEMPIOML SMF78PRF

VMACFTP VMAC79: TEMPIOML SMF79PRF SMF79RV2 R79FRCVT R79RV1

VMACIDMJ R79RSV R79USER R796FLG R797FLG R797RES

VMACIDMS R798FL1 R799RVO R799CNF R799RV0 R799CNF

VMACIMS R79BFL2 R79BRESV

VMACIMSA TYPEDOS: SUFFIX

VMACMVCI VMAC102: QW0011PS QW0015C2 QW0021KD QW0021KP QW0021K1

VMACOPC QW0021K2 QW0087AD QWP1SMRC QWP3WLST QWP4DATE

VMACSNAP QWP4DATE QW0170FC QW0177CT

VMACSPMS VMAC110: TRANPRI TCLASS TRANPRI TRANPRI TRANPRI

VMACSYNC TRANPRI TRANPRI TRANPRI TCLASS

VMACTMV2 VMAC116: WTIDUOWI WQCORREL

VMACTMVS VMAC22: CPUTYPE

ZMACxxxx VMAC42: SMF42DEV

Nov 1, 2001 VMAC6: SMF6OTOK

VMAC6156: RELFLAG

VMAC7072: R723MSCF

VMAC79: R79FRCVT

VMAC80A: CLASOPT1

VMAC84: SMF84FL1

VMAC90A: SMF9031U

VMACACF2: ACVMFMF

VMACACHE: DEVMAP1 DEVMAP2 CSDEV DVID

VMACAPAF: CPUMAP

VMACAPAF: IOPMAP

VMACBETA: BETAALVL

VMACCTLG: RELFLAG

VMACDB2: QBGBGR1 QBGBGR2

VMACERE: SYRELLVL

VMACFTP: DVGDRETC DVGDREAC

VMACIDMJ: DBKOWNER DBKOWNER

VMACIDMS: DBKOWNER DBKOWNER

VMACIMS: SYNCDMAP

VMACIMSA: SYNCDMAP

VMACMVCI: T6EUDATA

VMACOPC: EXRPURGE

VMACSNAP: SNAPSVCI SNAPDTE SNAPSTA1 SNAPSTA2 SNAPREAS

SNAPDIAO

VMACSPMS: SPMSEXTB SPMSEXTE

VMACSYNC: SYNSOIO SYNSOIO

VMACTMV2: JDCLASS

VMACTMVS: ICLCUNUM ICSUBCHN IOELCUNO IOEDDVNO IVDEVADR

IVDEVNR JDCLASS

Fortunately, except for R723MSCF in TYPE72GO cited above,

none of these variables have been reported in error by

users.

Note: most of these CHAR variables were assigned MXG's

$NOTRAN informat: that was to be used by SAS as a flag to

"Not Translate" that variable between platforms, but that

scheme will not be implemented, so whether hex-containing

character variables have informat $NOTRAN or not has no

impact. Sep 2009: Find MXGNOTRA in CHANGESS for solution.
I also eliminated many ZMACxxxx members that were old and

no longer needed as penultimate backup for major changes.

Thanks to Don Deese, (CPExpert), Computer Management Sciences, USA.
Change 19.215 MXG 19.05 only. PDB.ASUM70PR and PDB.ASUMCEC variable

VMXG70PR SHIFT was usually wrong. The _DURSET logic changes made

Nov 2, 2001 by Change 19.201 were incorrect and were revised with the

insertion of DATETIME=STARTIME; before the first include

statement for IMACSHFT, and that code block was copied to

the second include statement for IMACSHFT.

Thanks to Bruce Widlund, Merrill Consultants, USA.
======Changes thru 19.214 were in MXG 19.06 dated Oct 30, 2001======
Change 19.214 Support for NTSMF SMS Objects create five datasets:

EXNTSMDI dddddd dataset description

EXNTSMEX NTSMDI SMSDISDM SMS DISCOVERY DATA MANAGER

EXNTSMIM NTSMEX SMSEXTHR SMS EXECUTIVE THREAD STATES

EXNTSMSE NTSMIM SMSINMEM SMS IN-MEMORY QUEUES

EXNTSMST NTSMSE SMSSENDR SMS STANDARD SENDER

IMACNTSM NTSMST SMSTATUS SMS STATUS MESSAGES

VMACNTSM

VMXGINIT

Oct 31, 2001

Thanks to Jim Quigley, ConEd, USA.
Change 19.213 "Support" for DB2 V7 QLES section was added to DB2STATS

VMACDB2 dataset (from 100 subtype 1) record, even though none of

Oct 31, 2001 the QLES fields are described in the DSNDQLES DSECT; they

are all flagged with (S) - Serviceability. Additionally,

the 8-byte QLETIMEx "time" fields, are actually two four

byte fields, which I have assumed to be like CICS "time"

values, with a 4-byte time value and a 4-byte count when

the time value was updated. While all of the other four

byte counters are accumulated, five of the "time" fields

are not accumulated: QLETIMEW,QLECNTM,QLETIMEI,QLECNTDY,

and QLECNTW. (The pair of time and count variables are

named QLETIMEx and QLECNTx, labelled "QLETIMEx*TIME" and

"QLEXTIMEx*COUNT". The QLExxxxx variables are discussed

in IBM documentation concerning the use of DSNTIP7 and

Section 2 of the DB2 Installation Guide, specifically to

measure and set the MAXIMUM LE TOKENS (LEMAX) on that DB2

panel to ensure that there are enough, and not too many,

LE tokens. Whether I've guessed correctly on the order

of time-count, and whether my assumed time units of secs

are valid, will hopefully confirmed or corrected, when

either IBM provides additional documentation, or when you

users can prove or disprove the numbers! Why only five

counters are not accumulated, especially since they are

really in pairs, suggests possible alignment errors, but

even then, I would expect four or six, not five.

Thanks to Harry Price, Florida Light and Power, USA.

Thanks to Ed Gambon, Florida Light and Power, USA.
Change 19.212 MXG 19.05 ONLY, CPUTYPE not 2064, LPARCPUS count is wrong

VMAC7072 in TYPE70PR and in ASUM70PR, because the test added by

Oct 30, 2001 Change 19.189 to support APAR OW49536 only was valid if

the CPUTYPE='2064'x. The revised change now counts CPUS:

IF SMF70CIN NE 'ICF' AND ( (SMF70ONT NE 0) OR

(SMF70ONT EQ 0 AND CPUTYPE NE '2064'X) )

THEN LPARCPUS=LPARCPUS+1;

and thus is CPU-Type dependent until IBM externalizes the

DDBOnlin flag into the RMF type 70 record as a safer test

field in the future.

Thanks to Peter Krijger, National Bank of New Zealand, NEW ZEALAND.

Thanks to Alan Sherkow, I/S Management Strategies, USA.

Change 19.211 Support for Tivoli/Netview NPM 2.6 COMPATIBLY added one

EX028INN new subtype, 17x, for new NPMINNRC dataset containing

VMAC28 Router CISCO CIP Interval Volume Data (i.e., records are

VMXGINIT written only for the routers that have installed CISCO

Oct 30, 2001 CIP card).

Oct 31, 2001

Change 19.210 NOT SORTED TYPE72GO error in WEEKBLDT caused by Change

WEEKBLDT 17.353 that added variable RPRTCLAS to the BY list in

WEEKBL3T TYPE72GO/WEEKBLD/MONTHBLD but missed WEEKBLDT/WEEBL3T.

Oct 30, 2001 This worked fine for two years, but a SET CLOCK event at

two sites exposed the MXG inconsistency that caused the

error. Correcting the BY list eliminated the error.

Thanks to Art Hunter, Penn Mutual, USA.

Thanks to Richard Lopez, Johnson and Johnson, USA.

Change 19.209 RMF III job monitor total storage is created in new

VMACRMFV variable ASIDTOT=SUM(ASIFMCT,ASIFMCTI,ASIESF,ASIESFI);

Oct 28, 2001 in ZRBASI dataset.

Thanks to Mark Wittie, FMR, USA.

Change 19.208 First 19.05 only. SYSTEM object has missing counters if

VMACNTSM NRDATA=24; first IF test was revised.

Oct 24, 2001

Thanks to Jim Quigley, ConED, USA.

======Changes thru 19.207 were in MXG 19.05 dated Oct 24, 2001======
Change 19.207 Some sample MQ Series Exception reports based on SMF 115

ANAL115 records (TYPS115).

Oct 24, 2001

Thanks to Bruce Widlund, Merrill Consultants, USA.

Thanks to Yakov Nudel, Beta Systems, USA.

Thanks to Jan Hess, America West, USA.

Change 19.206 Unexpected blank 80-byte record at start of compressed

VMACTMO2 Landmark file caused INPUT STATEMENT EXCEEDED error. This

Oct 24, 2001 change detects short records, lists them on the SAS log,

and deletes them. These records are probably being added

as part of the site's tape initialization process, rather

than being created by Landmark.

Thanks to Tim Sisk, CSC Corp, USA
Change 19.205 Using ASUMCICS with Landmark TYPSTMO2 member failed, due

ASUMCICS to the incorrect include of member IMACMONI instead of

Oct 23, 2001 VMACTMO2 (so _LMONTSK was not defined).

Thanks to Robin Murray, Maritime Life, CANADA

Change 19.204 Support for CICS/TS 2.2 Statistics changes to CICDS data.

VMAC110 IBM has changed the 9th and 11th TCB buckets contents and

Oct 23, 2001 added a twelfth bucket:

Nov 12, 2001 MXG Prefix TCB Number TCB Name 2.1 TCB 2.2 TCB

DSG 1 QR 1 1

DS2 2 RO 2 2

DS3 3 CO 3 3

DS4 4 SZ 4 4

DS5 5 RP 5 5

DS6 6 FO 6 6

DS7 7 SL 7 7

DS8 8 SO 8 8

DS9 9 J8 9 H8 12

DSA 10 L8 10 11

DSB 11 S8 11 9

DSC 12 D2 -- D2 10

MXG variable DSnTCBNM, where n is the TCB number, will

contain the actual name of the TCB so you can verify

which set of TCB values applies to which TCB; because of

the IBM change, the LABEL values for DS9,DSA,DSB, and DSC

variables may be incorrect, but DSnTCBNM will be valid.

There are additional DSG Pool segments that are not yet

decoded, as I need actual data to validate their location

in the SMF record to write that code.

Change 19.203 Support for z/OS Version 1.1 and 1.2 APAR and MXG error.

VMAC78 APAR OW49806, for z900 with z/OS 1.2, adds new IOP

Oct 23, 2001 (I/O Processor) utilization measurements have been added

TYPE78IO dataset:

R783IIPB='TIMES WHEN*IOP*WAS BUSY'

R783IIPI='TIMES WHEN*IOP*WAS IDLE'

R783IIFS='IO FUNCTIONS*INITIALLY*STARTED'

R783IPII='PROCESSED*I/O*INTERRUPTS'

R783ICPB='RETRIES*DUE TO*CHANNEL*PATH*BUSY'

R783IDPB='RETRIES*DUE TO*DIRECTOR*PORT*BUSY'

R783ICUB='RETRIES*DUE TO*CONTROL*UNIT*BUSY'

R783IDVB='RETRIES*DUE TO*DEVICE*BUSY'

But in installing this support, I found the new variables

for DCM managed channels, added by Change 18.134 for 1.1

(R783MCMN/MX/DF/PTM/DBPM/CUBM added to dataset TYPE78IO),

should have instead been added to dataset TYPE78CU, so

this change is required for z/OS 1.1 and 1.2 on all

platforms, not just z900s.

14May02: Documented in comments in VMAC78, but not here,

z/OS 1.2 R783GSAM/NRCMPTSM and R783PB/PCTPTHBY are now

reserved, causing PCTPTHBY to be missing in TYPE78CF.

16Jun02: This also causes PCTALLBY to be missing in

TYPE78CU, beginning with Z/OS 1.2.
Change 19.202 Support for Serena's Ultimizer user SMF record.

EXULTM01 Four datasets are created:

EXULTM02 ULTM01 ULTMIZ01 VSAM BLOCKSIZE OPTimIZATION

EXULTM03 ULTM02 ULTMIZ02 QSAM BUFFER OPTIMIZATION

EXULTMNN ULTM03 ULTMIZ03 QSAM BLOCKSIZE OPTIMIZATION

FORMATS ULTMNN ULTMIZNN BLDVRP OVERRIDE OR BYPASSES

TYPEULTM This vendor puts the RDRDATE where the SYSTEM should be

TYPSULTM in the SMF header. The subtypes 4 thru 10 are all output

VMACULTM in the ULTMIZnn dataset, which appears to also have

VMXGINIT duplicate records created for some subtypes.

Oct 20, 2001
Change 19.201 Several enhancements to PDB.RMFINTRV and PDB.ASUM70PR:

ASUM70PR -Variables PARTISHN TOTSHARE LPARSHAR and CECSER added to

VMXG70PR PDB.RMFINTRV by your include of ASUM70PR after BUILDPDB

VMXGRMFI that updates PDB.RMFINTRV after PDB.ASUM70PR is built.

Oct 22, 2001 -The SYNC59 logic in VMXGRMFI was revised; it could be

off by one minute in creating PDB.RMFINTRV.

-The 70ID list was cleaned up and now is in one place.

-If you used the (recently added) INTERVAL= and SYNC59=

arguments in your RMFINTRV member to control %VMXGRMFI's

summary interval, variables PLATBUSY and PLATCPUS could

be missing, because the ASUM70PR program that adds them

into PDB.RMFINTRV uses the _DURSET macro in IMACRMFI to

set the ASUM70PR interval, causing the mis-match. This

exposure is fixed by new member VMXG70PR, a new %MACRO

definition, that is now invoked by member ASUM70PR, with

the same arguments as VMXGRMFI, so that if you do tailor

RMFINTRV with INTERVAL= and/or SYNC9=, you now can (and

now MUST!) use the same arguments and values in both your

RMFINTRV and ASUM70PR members, so that the intervals in

RMFINTRV, ASUM70PR, and ASUMCEC are identical.

-The default value in both RMFINTRV and ASUM70PR are set

to INTERVAL=DURSET and SYNC59=NO, so that the default

interval in PDB.RMFINTRV and PDB.ASUM70PR is set by the

member IMACRMFI (in it's _DURSET macro definition).