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

TYPETIMS Use the INFILE name of MONITIMS for the Landmark records.

VMACTIMS If your data records are compressed, Assemble and install

VMXGINIT member EXITMON6, an "Infile Exit" for SAS V6/V8, that can

Mar 28, 2001 read the compressed records. See comments in EXITMON6.

Apr 1, 2001

All above datasets have been created, and unexpected and

unwanted accumulated counters were found, so that you

must use member TYPSTIMS to first write to //WORK and

then SORT/Deaccumulate into the //PDB library.

Detection of accumulated fields requires non-zero values,

and some of the fields in the test data were zero, so you

need to use PROC MEANS MIN ; to examine each dataset for

negative minimum (improper deaccum) or large minimum

(variable that probably should be deaccumulated).

TIMSCU: CUMSGOQ and CUPWAIT are occasionally negative

and some timestamps are always missing.

Thanks to Warren Waid, J. C. Penny Company Inc, USA.

Change 19.049 Using JCLTEST8, warnings about CODEPASS option was

JCLTEST8 printed, because the instream proc still referenced the

Mar 27, 2001 (CONFIG) member instead of (CONFIGV8) for SAS V8.

Thanks to Art Hunter, Penn Mutual, USA.

Change 19.048 Variable STC11CSP should have been input as &PIB2.2 so

VMACSTC that its value is 20 for a 20 MegaByte/Sec Channel Speed.

Mar 27, 2001

Thanks to Chuck Hopf, MBNA, USA.

Change 19.047 Support for optional CICS TCP/IP timings and counts from

IMACICDA the EZA01 segment adds ten variables to the CICSTRAN

IMACICEZ dataset, but ONLY if you remove the comment block in the

IMAC110 IMACICEZ member. You need to also run UTILCICS to see

Mar 26, 2001 where the EZA01 segment was added, and may have to change

the expected order of segments in member IMACICDA.

Thanks to Andreas von Imhof, Rabobank, THE NETHERLANDS.
Change 19.046 Support for IMS Version 7.1 IMS Log Records is almost

VMACIMS compatible; only the '40'x log record was incompatibly

Mar 26, 2001 changed (and it is needed only if he message queue was

built), based on documentation review of the log DSECTS.

Some additional fields are now decoded, but no new

variables were added to the existing log record datasets.

Thanks to Engelbert Smets, Provinzial Versicherungen, GERMANY.
Change 19.045 Variable VERSNRMF was kept in most, but not all, RMF/CMF

VMAC7072 datasets, but is now kept in TYPE70PR/7204/72SC/78PA and

VMAC78 TYPE78SP datasets.

Mar 26, 2001

Thanks to Ian Davies, Independent Consultant, CANADA.
Change 19.044 NETSPY type 'R' records caused INPUT STATEMENT EXCEEDED

VMACNSPY because MXG expected 89 bytes, but NETSPY 5.3 creates a

Mar 26, 2001 type R record of only 77 bytes, so the three fields that

were added (NSPYBPQU NSPYBPST NSPYRNLP) are now input if

NSPYENTL=89.

Thanks to Reuben de Leeuwe, IZB, GERMANY.

Change 19.043 Reading VSAM SMF caused INPUT STATEMENT EXCEEDED RECORD

VMAC42 for type 42 subtype 5 record. This particular subtype has

Mar 26, 2001 internal offset variables, and the MXG logic looped on

Mar 27, 2001 those offset variables (instead of looping on the count

field, as these internal segments have no count field),

but the MXG logic to convert from IBM offset value to the

SAS byte location: OFFzzzz=OFFzzzz-3+OFFSMF; was

being executed even when OFFzzzz=0, causing OFFzzzz=1

when a VSAM subtype 5 was read (OFFSMF=4 for VSAM SMF).

Now, IF OFFzzzz GT 0 THEN OFFzzzz=OFFzzzz-3+OFFSMF;

logic protects for the input zero value with VSAM input.

(BSAM SMF has OFFSMF=0, so it produced OFFxxxx=-3 if the

input value was zero, but since the subsequent MXG logic

tests IF OFFxxxx GT 0 THEN DO; so the segment was not

input when not present with BSAM dumped SMF input).

Thanks to Ken Williams, IBM Global Services, ENGLAND.

Thanks to Mark Williams, Marks and Spencer, ENGLAND.
Change 19.042 Variables XMGMXT, XMGPAT, and XMGPQT should have been in

VMXGCICI a MAX= argument instead of the SUM= argument in the first

Mar 26, 2001 %VMXGSUM invocation. Their values were incorrect in the

PDB.CICINTRV dataset.

Thanks to Brian Hawthorne, MONY Life Insurance Company, USA.
Change 19.041 Support for APAR II12xxx clarifies documentation of the

VMAC50 VTAM type 50 record.

Mar 23, 2001
Change 19.040 If a file spanned more than five volumes, the VOLSERs in

VMACCTLG CTLGDSN dataset were overlaid with the subsequent VOLSER;

Mar 23, 2001 (i.e., VOLSER1='BARRY6' instead of 'BARRY1' if 6 vols).

Thanks to Gordy Rogers, Principal Financial Group, USA.

Change 19.039 Error: INVALID ARGUMENT TO SQRT FUNCTION is corrected;

ANALUOW small negative values due to rounding caused the error.

Mar 22, 2001

Thanks to Ed Long, FMR, USA.

Change 19.038 Change 18.286 corrected 1.024 to 1024 for SMF30JQT/RQT/

VMAC30 HQT/SQT, but ENCLACTM should also have been corrected to

Mar 22, 2001 use 1024 instead of 1.024 as the multiplier.

Thanks to Alan Freed, ADP, USA.

Change 19.037 Format MG060ID for type 60 records was updated from the

FORMATS SMF manual; several UNKNOWNs are now known.

Mar 19, 2001

Thanks to Chuck Hopf, MBNA, USA.

Change 19.036 Variable ABENDS in PDB.JOBS counts each OMVS/USS pseudo

BUILD005 step record as an abend. Change 10.325 set variable

BUIL3005 ABEND='OMVSEX' to identify each pseudo step record

Mar 17, 2001 (created when an OMVS/USS address space is "dubbed"), but

Change 16.183, which added variable ABENDS to PDB.JOBS,

should have skipped over these steps. The test in

BUILD005 to count abends was revised to now read:

IF ABEND NE: ' ' AND ABEND NE:'OMVSEX'

AND ABEND NE: 'FLUSH' THEN DO;

This error also could cause ABEND to be blank when it

should not have been, if the job had both pseudo steps

and other real steps that did have abends or returns.

Thanks to Rex Pommier, Western Surety Company, USA.
Change 19.035 New values for format MGSTCLB for variable STC07LBL are

FORMATS added:

Mar 16, 2001 /* $MGSTCLB FORMAT FOR VMACSTC */

VALUE $MGSTCLB

'1'='1:VERIFY LABEL VOLSER (IGNORE MEDIA)'

'2'='2:VERIFY UNLABELED CARTRIDGE (IGNORE MEDIA)'

'3'='3:BYPASS VOLSER AND MEDIA LABEL CHECK'

'4'='4:RECOVERY CARTRIGE NUMBER SPECIFIED'

'5'='5:VERIFY MEDIA TYPE, BYPASS VOLSER CHECK'

'6'='6:VERIFY MEDIA TYPE AND VOLSER'

'7'='7:VERIFY MEDIA TYPE AND UNREADABLE VOLSER'

;

Thanks to Martin Jensen, Jyskebank, DENMARK.

Change 19.034 Support for TNG for SOL260S records added. The SOL260S

VMACTNG records seem to be the same as SOL240S, so both formats

Mar 16, 2001 will create the same SOnnn Solaris TNG MXG datasets.

Thanks to Paul Hargreaves, SEMA, ENGLAND.

Change 19.033 Documentation/example only. No code change was made.

CONFIGV8 If you want to change the global MXG Default "PDB" DDNAME

VMXGINIT to something else, for example "MXG" because that's what

Mar 14, 2001 someone before you did, you should NOT make the change by

EDITing the VMXGINIT member, because that member changes

with every MXG version to GLOBAL all MXG macro variables,

and you would have to re-tailor every time you install a

new MXG version. Instead, you can change the DEFAULT=PDB

to DEFAULT=MXG by EDITing a USERID.SOURCLIB(CONFIGV8),

and changing the statement that invokes %VMXGINIT:

INITSTMT='%INCLUDE SOURCLIB(VMXGINIT);%VMXGINIT;RUN;'

to set the DEFAULT=MXG:

INITSTMT='%INCLUDE SOURCLIB(VMXGINIT);%VMXGINIT(DEFAULT=MXG);RUN;'
The CONFIGV8 member is one that sites may choose to EDIT,

since some of those options are site choices, but it does

not typically change between MXG versions, and it is the

intended location for any changes to the %VMXGINIT parms.

Further note: there should never be members starting with

VMAC nor VMXG in your USERID.SOURCLIBs, except as interim

corrections until you install the next MXG version. Old

VMAC/VMXG members in your tailoring libraries can cause

ABENDs, and require re-tailoring with each new Version.

They should always be removed when the new version is

installed, and all MXG tailoring can be put in the MXG

exit members or in your //SYSIN input stream, so you

never have to change your changes.
And while I'm in tutorial mode, if you have tailored any

VMXG members into your USERID.SOURCLIB, you probably did

it because you wanted to change the default arguments,

and you found how to make it work. But that is not the

correct way to %MACROs should be used. Instead of EDIT

of the VMXGxxxx member that defines the %MACRO %VMXGxxxx,

you simply EDIT the invocation of the %VMXGxxxx macro,

and change the parameter value there. For a specific

example, member RMFINTRV is where the statement that

invokes the execution of %VMXGRMFI macro is located, to

create PDB.RMFINTRV dataset. To change workloads, etc.,

you would EDIT the existing %VMXGRMFI

%VMXGRMFI statement in your RMFINTRV

member in USERID.SOURCLIB(RMFINTRV), adding the new parm:

%VMXGRMFI(PDB=PDB,...,PARM=WHATEVER);

In this manner, never editing the VMXG/VMAC members, the

install of a new MXG version means that you never have to

retrofit your MXG tailoring.

Thanks to Jerry J. Lentz, State of Arizona, USA.
Change 19.032 INPUT STATEMENT EXCEEDED RECORD for Shadow Direct subtype

VMACSHDW 06 record; the record says there was 417 bytes of SQL

Mar 14, 2001 text, but there were only 256 bytes of data, so the logic

to parse the SQL text into 100 byte chunks was revised to

use LENLEFT=MIN((LENGTH-COL+1,SM06SQLN) to control the

length of text bytes read.

Thanks to Chris Morgan, IBM Integrated Technology Services, ENGLAND.
Change 19.031 The CHAIN logic in processing IMF IMS transactions was

VMACCIMS revised by this user-contributed enhancement. When IMS

Mar 14, 2001 transactions are chained, the IMF record for the second

and subsequent transactions contain the arrival time of

the original transaction, which produced incorrect input

queue time measures. The CHAIN algorithm sorted thru the

chain and reset the arrival time of the second to the end

time of the preceding. But the original algorithm was

redesigned by Wolfgang:

- When transactions were started before the prior

transaction had finished, the RESPNSTM was cumulative;

that is corrected, and noted in new variables NEGTIME

and NEGCNT (kept only so you can see the impact of the

enhancement to see how wrong prior values were!).

- Data Steps 2 and 3 were removed, coding was moved into

the last step, reducing the execution and CPU time, I/O

and work space required.

Thanks to Wolfgang Vierling, AGIS GmbH, GERMANY.

Change 19.030 If your OS/390 was back level and did not have OW37565

VMAC7072 (flags ICF CPUs) MXG logic added in Change 19.015 caused

Mar 13, 2001 LPARCPUS=0 in TYPE70PR and missing data in ASUM70PR. The

Nov 15, 2001 logic now confirms the APAR is installed by checking the

NRCIXGT0 field before using SMF70CIX to id an ICF CPU.
Note added Nov 15, 2001: LPARCPUS=0 was a symptom here

because it was always zero AND caused missing data in the

ASUM70PR dataset, in that specific environment. After

this change, it is still normal to have observations in

TYPE70PR with LPARCPUS=0: those with LPARNAME='PHYSICAL',

or with SMF70CIN='ICF', or with LCPUADDR=. (for inactive

LPARs) will have LPARCPUS=0, and that's okay.

Thanks to Joe Montana, Acxiom, USA.

Change 19.029 Support for Tandem G06/G07/G08 TANCPU & TANDISK records.

VMACTAND -New fields were added to the end of the TANCPU record,

Mar 13, 2001 and variable DISKIOSF is now input as DISKIOS because it

is just the 8-byte DISKIOS field. The calculation of

rates was moved to the end of the TANCPU logic.

Code is in place for G06, G07, and G08 changes, but only

G06 with LRECL=770 has been validated.

-New fields were added to end of TANDISK record.

Code is in place for G06, G07, and G08 changes, but only

G06 with LRECL=746 has been validated.

Thanks to Patricia A. Wingfield, Bank of America, USA.
Change 19.028 Variables DSGPERCT and DS1PERCT-DS6PERCT in PDB.CICDS are

VMAC110 are not interval TCB Busy percent, as labeled, but are

Mar 12, 2001 the instantaneous value at the end of interval, which can

be quite different from the actual TCB Percent Busy:

Hour 03 06 09 12 15 18

DSGPERCT: 88 74 88 77 69 19

AVGPERCT: 22 70 58 65 64 40

IBM doesn't create DSxPERCT fields for the newer TCBs.

The PDB.CICINTRV dataset has all 11 TCBs DSnPERCT values

and all are recalculated (DSGPERCT=100*DSGACT/DURATM) so

they do match their label in the PDB.CICINTRV dataset.
The only change was to add "AT END" to the labels for the

7 TCB variables DSGPERCT-DS6PERCT in the PDB.CICDS data

Thanks to Normand Poitras, IBM Global Services, CANADA.
Change 19.027 Duplicate DB2ACCT records created by IBM Parallel Trans

EXDB2ACC are now deleted, but without this change, you will have

VMACDB2 duplicate DB2 accounting, negative DB2TCBTM, missing

VMXGUOW ELAPSTM, and these strange values in your DB2ACCT data:

Mar 12, 2001 QWACESC 01JAN1900:02:00:00 QWACEJST less than a second

Jun 5, 2001 QWACBSC 05JUN2001:19:20:21 QWACBJST minutes

The double accounting was introduced by IBM in DB2 APARS

PQ22260,PQ22451,PQ10864,PW06968,PQ45496 but it sure was

not obvious from the text of those APARs. The end result

is that, now, when DB2 parallelism is used, instead of

writing many individual child records, IBM "rolls up"

(sums) all child records into a single record, but that

record now is a duplicate of the previously existing

parent record. IBM finally documented how to identify

and delete these duplicate DB2ACCT records: New MXG

bit flag variable QWACPARR is now created

IF QWACFLGS='.........1......'B THEN QWACPARR='Y';

ELSE QWACPARR=' ';

to identify these "rolled up" records, and the statement:

IF DB2PARTY='P' AND QWACPARR='Y' THEN DELETE;

was added in the EXDB2ACC exit member so that MXG will

delete this duplicate data.

Note: That IF/DELETE statement was a circumvention and it

was removed from all exits by Change 22.121.

Additionally, VMXGUOW was similarly updated so ASUMUOW

will also delete the dupes, and it could be re-run

against existing DB2ACCT/CICSTRAN data to re-build

PDB.ASUMUOW without duplicates. Normally, I am reluctant

to delete any SMF data, but this duplication is so

obscure and could be so impacting, that I chose to delete

them in MXG to prevent their accidental introduction into

DB2ACCT (and ASUMUOW), which are used for DB2 billing. I

am not aware of any other data in these records which

justifies keeping them, but since the logic was added in

the Exit, you could easily change it to create these

rolled-up data records, if needed.

This note's documentation was enhanced Jun 5, but no code

was changed.

Thanks to Being Hwang, DOA, State of Wisconsin, USA.

Thanks to Gunther Vogt, Audi AG, GERMANY.

Change 19.026 ASUMV14 summarizes STK VTS dismount records to get total

ASUMV14 bytes compressed and uncompressed and the compression

ASUMV11 ratio. ASUMV11 summarizes STCVSM11 to the QTR hour too

Mar 10, 2001 get the back end channel busy for STK VSM.

Note that the STCVSM11 dataset must be selected from only

one system; each system connected to the VSM writes what

are effectively duplicate records, at slightly different

intervals.

Thanks to Chuck Hopf, MBNA, USA.
Change 19.025 CICS CPU time captured in CICSTRAN/CICDS/TYPE30/TYPE72 is

ADOC110 now docummented in member ADOC110. This change adds the

VMAC110 variables QRCPUTTM, MSCPUTTM and KY8CPUTM, which already

VMXGCICI exist in the CICSTRAN dataset, to the CICDS Dispatcher

Mar 10, 2001 Statistics dataset and to the CICINTRV summary dataset.
Change 19.024 Cosmetic. Status variables DVLCSMSS DVLCSMS2-DVLCSMS8

VMACDCOL are now formatted with existing MGDCOVS format, as were

Mar 8, 2001 variables DVLSMSS DVLSMSS2-DVLSMSS8.

Thanks to Jim Horne, Lowe's Companies, USA.

Change 19.023 Change 19.015 removed NRCPUS from TYPE70PR dataset; this

ANALRMFR change revises the RMF reporting to match that change.

Mar 6, 2001
Change 19.022 The First SQL Page Number QW0006PN, a 3-byte character to

ANALDB2R display up to 999, was replaced by QW0006PG, a numeric,

Mar 6, 2001 so now the '1ST PAGE' value for large values will print.

Thanks to Andrew Schmid, EDS Canberra, AUSTRALIA.

Change 19.021 If the rarely used TEMP01 and TEMP02 options of VMXGSUM

VMXGSUM are used, and TEMP02 is tape format, there will be a SAS

Mar 6, 2001 error attempting to open two datases on a tape.

Thanks to Khoan Dang, MBNA, USA.

Change 19.020 Using %VMXGRMFI(PDB=SMF) caused ERROR: FILE WORK.MERGERMF

VMXGRMFI NOT FOUND. The default, PDB=PDB, worked fine. The test

Mar 6, 2001 %ELSE %IF &PDB=PDB %THEN %DO; was changed to now read:

%IF &PDB=PDB OR &PDB=SMF %THEN %DO;

Thanks to Wayne A. Schumack, Blue Cross of Minnesota, USA.
Change 19.019 INPUT EXCEEDED RECORD LENGTH SMF 102 subtype 140 because

VMAC102 new fields INCOMPATIBLY inserted by DB2 5.1 were not read

Mar 5, 2001 in for this Audit Trace record subtype.

Thanks to Brad Dorn, Kohl's, USA.

Change 19.018 Protection for zero-divide in new z/OS variable SMF70CPA,

VMAC7072 (no actual error in the MXG output, only a hex dump print

Mar 5, 2001 on the SAS log) because OS/390 2.10 unexpectedly writes

SMF type 70 records with LENCPUC=40, (2.10 doc says 28).

If LENCPUC GE 40, MXG Inputs SMF70CPA/SMF70WLA/SMF70LAC

(new MSU capacity stuff) and then divided without testing

the denominator before the divide, and the new fields are

all zero in the R2.10 extended segment. And MXG expected

SMF70WLA to be missing if the record did not contain that

new MSU capacity measure, using IF SMF70WLA=. THEN DO...

logic in VMXGRMFI to detect its presence, so this change

also forces SMF70WLA=. if it is found to contain zeroes.

Thanks to Alan Freed, Automatic Data Processing, USA.
Change 19.017 Support for APAR OW46268 for TYPE74 USS Kernel data was

VMAC74 already in place; incorrect format and documentation was

Mar 5, 2001 recognized during MXG validation of those fields.
Change 19.016 Cosmetic. The A2THID=UPCASE(AUTHID) should have been

ANALDB2R AUTHID (only impact would be if you typed selection names

Mar 1, 2001 in lower case, and none would have been selected). Three

repeated IF AUTHID=:' ' THEN AUTHID=' ' "compiler

fakers" were redundant and were deleted.

Thanks to Tom Parker, CSC Hogan Systems, USA.

Change 19.015 If you have 2064 (z900) CPU with ICF-s installed, and

ASUM70PR do not have the PTF for APAR OW48190 installed, the count

VMAC7072 of ICF-s will be incorrect, causing incorrect CPU busy.

VMXGRMFI Without that APAR (no PTF until April), the IBM type 70

Mar 1, 2001 70 field SMF70CIX does NOT properly flag ICF CPUs, so the

Mar 6, 2001 PARTNCPU and LPARCPUS variables that count real CPs will

be wrong in TYPE70, TYPE70PR, ASUM70PR, and RMFINTRV, and

MSU4HRAV will also be incorrect. This change completely

revises how ICFs are counted, moving that logic from the

ASUM70PR back into VMAC7072 so all four datasets above

will be correct, and this change corrects the count with

logic that works whether or not you have installed the

PTF for OW48190.
Caveat: You must use VMAC7072, VMXGRMFI, and ASUM70PR

from this change; make sure you do not have any of those

three members in your "USERID.SOURCLIB" (or if you do,

you must re-tailor your changes into these new members).

First, the code loops thru the type 70 PR/SM segments to

count the number of non-zero values of SMF70CIX. If the

count is always zero, then APAR OW37565 (which populates

SMF70CIX with 1 for "CP" and 2 for "ICF") is not on this

system, so ICF's can't be counted. A non-zero value in

NRCIXGT0 proves the SMF70CIX field is valid, and IFCs can

be counted, and then I can recognize an invalid value of

zero in SMF70CIX is really an ICF, as that is the IBM

error that will be fixed by OW48190s PTF: SMF70CIX had a

zero instead of a 2 for an ICF. This allows MXG to count

and remove ICFs from the PARTNCPU count of CPs in a box.
However, the variable PARTNCPU in TYPE70 and TYPE70PR did

include ICFs; it was only in PDB.ASUM70PR/PDB.RMFINTRV

that both PARTNCPU and LPARCPUS were corrected for ICFs.

This change now corrects all four datasets, so the logic

in ASUM70PR (which both creates PDB.ASUM70PR and updates

PDB.RMFINTRV) was revised to no longer subtract ICFs.

Note also that VMXGRMFI at Change 19.012 is also neeeded

to support the 2064 processors, independent of this fix,

for variable MSU4HRAV valid on 2064s, so it is listed

here as well to alert you to use all three new memgers.

-Variable NRCPUS was removed from TYPE70PR, because it did

not belong there; LPARCPUS is the correct variable that

counts CPs in this LPAR, while NRCPUS is a TYPE70-only

variable that counted the CPUs in the SYSTEM that wrote

this type 70 record, and NRCPUS in TYPE70PR could be

misleading and/or confusing.

-Mar 6 additions. The summarization interval in ASUM70PR

and RMFINTRV is set in member IMACRMFI's macro _DURSET

definition; by default, each original interval is output.

If you change the interval of your PDB.RMFINTRV data:

a. You can tailor your own RMFINTRV member, using

VMXGRMFI(INTERVAL=HOUR);

but then you have to change the _DURSET definition in

your IMACRMFI member to set variable STARTIME hourly:

STARTIME=DHMS(DATE,HOUR,0,0);

because member ASUM70PR not only created PDB.ASUM70PR

using _DURSET, but also then reads and rewrites the

PDB.RMFINTRV dataset (adding Platform Busy, Percent of

Hardware, etc., variables), so, instead,

b. Leave the default INTERVAL=DURSET, in the RMFINTRV

member (if you still need one), and just tailor the

STARTIME value in member IMACRMFI.

c. Watch for a possible re-design to make it consistent.

Thanks to Pat Curren, SuperValu Inc, USA.

Change 19.014 The original text of this change (about CPUTM in CICSTRAN

VMAC110 possibly being the sum of many variables) was wrong; the

Feb 23, 2001 MXG equation for billable CPU time in CICSTRAN:

Mar 12, 2001 CPUTM=SUM(TASCPUTM,CPURLSTM).

has always been correct and should not be changed.