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

include DIV connect time, but a DDNAME for DIV

could record connect time if it were accessed

with a VSAM utility.

IOTMNODD: Will now include the DIV I/O connect time (i.e.

NOT captured at the DD level is in NODD vars.)

7.Support for PR/SM hardware and RMF PTFs in VMAC7072 with

new member EXTY70PR.

a. New data set TYPE70PR created, one obs for each LCPU

(Logical processor) in each LPAR (Logical partition).

This PR/SM data set reports on all defined partitions

and is the only source of total hardware CPU active.

b. PR/SM changes how TYPE70 captures CPU wait and busy.

Read the Partition Data Report field descriptions in

the RMF User's Guide. The variables CPUWAITM/PCTCPUBY

(and the individual CPU 0-8 values) are recalculated

by this change from the PR/SM data sections for the

LPAR this MVS is executing in. TYPE70 data under the

PR/SM hardware now only reports this MVS's usage, and

no longer reports total (real) hardware CPU active.

Summing TYPE70PR variable LCPUPDTM by STARTIME will

provide total (real) hardware CPU activity during the

interval by ALL partitions.

c. TYPE72 variable ACTFRMTM is the resident page-seconds

sum of Central Store (CS) and Expanded Store (ES). The

ratio of ACTFRMTM/RESIDTM is the average total number

of pages (frames) in CS+ES for this performance group

period. TYPE72 variable PGPAGEIN is the number of page

ins in this performance group period.

8.Additional Paging data in TYPE71 supported. New variables

EXTREADS, SQARE.., SQAEX.., LPAEX.., CSAEX.., LSQARE..,

LSQAEX.. and REGSEX.. added.

9.Additonal SMS data in TYPE74 supported. New variables are

DASDRCFG & STORGRUP, and AVDSOPEN in RMF 3.5.0+ contains

count of allocations, rather than data sets open.

Change 06.067 This member lists all %INCLUDES for each MXG member. It

DOCINCLD is now automatically created from each new MXG version by

Jun 2, 1988 a smart SAS program.
Change 06.066 The MXG FMXGUCBL SAS function which dynamically allocates

FMXGUCB7 all online DASD for VTOC processing was for MVS/XA only.

Jun 2, 1988 This new member provides the same function under MVS/370.

Thanks to ???, ???, AUSTRALIA.

Change 06.065 STOPX37 Product Release 3.2 is now supported. Record was

VMACX37 completely reordered but essentially the same variables

Jun 2, 1988 exist.
-------Changes through 6.064 completed the Pre-release MXG 6.2-------
Change 06.064 STOPX37 product changed SMF record format. Temp fix to

VMACX37 avoid STOPOVER ABEND was added, but does not support the

May 2, 1988 new format in their Release 3.2, which will be in the

next pre-release of MXG.

Thanks to Chuck Hopf, Dean Witter Reynolds, USA.
Change 06.063 Final beta tests of 6.2-minus uncovered these errors:

TYPEIMS -MSGSZOUT spelled once in error as MSGSZOU.

EXIMSOUT -TRANCLAS spelled in error as TRANCLS.

JCLUXREF -Unnecessary PROC COPY removed from TESTUSER step and 2nd

Apr 27, 1988 DCLOG DD DUMMY was supposed to be EPILOG DD DUMMY (slow

response after SPF replicate subcommand caused error).

Thanks to Pete Shepard, Ashland Oil, USA.
Change 06.062 Support for VM/XA SP 1 accounting card data (described in

TYPEVM SC23-0353, pages 126-128). Only the VMSESSN, VMDEVICE and

Apr 27, 1988 VMUSRDAT datasets are created by VM/XA. Data set VMDEVICE

variables DEVICECL, DEVICETY, MODEL, & FEATURE are now

reserved fields! Two new variables for vector CPU time,

VECVITM and VECVIRTM, are created for VM/XA and VM/SP

account cards. The card format is essentially the same as

VM/SP so this member now supports VM/SP or VM/XA records.

Change 06.061 Variables LPAPGMN,MX,AV, CSAPGMN,MX,AV, and PRVPGMN,MX,AV

VMAC71 in TYPE71 are correct, but their label was "PAGEABLE" and

Apr 27, 1988 is now "TOTAL". Page 410 of the MXG Supplement is correct

(except for the mispelling of private as privage!) which

corrects page 706 in the MXG Guide! Change 4.34 made the

values correct, but overlooked the change in labels.

Thanks to Roger Crabb, British Telecom Red Lion Square, ENGLAND.
Change 06.060 -Variable NPMLOST should have been PIB4. vice $CHAR8.

VMAC28 -For all date fields INPUT with PD4 format were protected

Apr 27, 1988 from a null (hex zeros) value causing INVALID DATA by the

addition of ?? between variable and PD4. (which causes

the value to be set missing without the hex dump and the

error message). Nulls were found for OGNSDATE & OGNEDATE.

-LDRTIME is reported always zero, IBM suggested UY18442 is

the fix, but that is in doubt and unconfirmed.

Thanks to Barry Pieper, FBS Informations Services, USA.

Thanks to Craig Feistner, CITICORP South Dakota, USA.

Change 06.059 Variable DOWNTM in TYPE0 data set was sometimes set to

VMACSMF missing when it could have been calculated, because the

Apr 27, 1988 PREVSYS and PREVTIME temporary variables in this member

were not RETAINed. They are now.

Thanks to Mike Heffler, Department of Defense, Ft Meade, MD, USA.
Change 06.058 Beta test of VM/XA SP 1 Monitor Records completed. See

DOCVER the sparce documentation in comments in VMACVMXA and

EXdddrrr examine the structure of the _TESTVM macro to see the

FORMATS slight changes in overall MXG structure necessary to

IMACVMXA accomodate the need to de-accumulate. Instead of the

UTILGEVX _VAR.... and _CDE.... MXG macro names, the _Vdddrrr and

UTILVB _Cdddrrr MXG VM/XA macros descrive the VXdddrrr data set

VMACVMXA created from Monitor Domain ddd and Record rrr records.

Apr 27, 1988 Seventy-five MXG SAS data sets are created with 1393

variables. Member DOCVER documents these MXG data sets.

In the author's opinion, this is the best MXG code ever written!

But that's not surprising with the good documentation and SAS,

and especially since the choice of IBM field names were

sufficiently "human-engineered" and self-consistent that I chose

to use them as the MXG variable name. This will completely avoid

the past difficulty of multiple names for the same field (such as

the CP, MON, and VM MAP triplets for identical fields). The

design left 5 positions for a reasonably un-cryptic name, and

wise person(s) picked good, usable and understandable names.
IBM Kingston: Thanks, you really did this one right!

========Changes thru 6.057 were printed in NEWSLETTER TWELVE==========

========Changes thru 6.057 were printed in NEWSLETTER TWELVE===========
Change 06.057 New exit IMAC434D was added to support modeling from

IMAC434D type 4, 34, and 40 records. Since BUILDPDB only uses

VMACEXCP type 30 records, this should not be important to many,

but it was added upon request for consistency with the

IMAC30DD similar-purpose exit for type 30 SMF records.

Apr 7, 1988

Thanks to Andrea Glaser, Performance Systems, Inc, USA.
Change 06.056 Complete internal rewrite of db2pm-like reports as new

ANALDB2R style macro, which supports reporting for multiple db2

systems, with a brand new report, is described in the

comments in this revised member. more still to come.

Apr 6, 1988
Change 06.055 $AVRS (SYSOUT Accumulation and Viewing System), Confident

IMACSAVR Software, Inc, creates a user SMF record which is now

TYPESAVR supported. You specify the SMF TYPE in IMACSAVR.

VMACSAVR

Apr 4, 1988

Thanks to Vern F. Berkquist, Bradford Exchange, USA.

Change 06.054 Landmark's CICS code was not updated for decoding of new

TYPEMONI UOWTIME format, causing an "INVALID DATA FOR INPUT FUNCT"

Apr 2, 1988 message (simply setting UOWTIME missing and continued).

Change 6.016 should have been made to Landmark as well.

Thanks to Bill Border, Apollo Computer, USA.
Change 06.053 -IMS Log processing with MXG now really matches DFSILTA0

EXIMSOUT counting of transactions! This supplements the comments

IMACIMS in Change 6.22. Lots of additional research by Pete shows

TYPEIMS that the "minor glitches" turned out to be "page scrolls"

VMACIMS (PA1 key, or retrieval of multiple screens) which MXG put

your IMSJCL in the MSGONLY data set. Pete has added new algorithms in

Apr 1, 1988 EXIMSOUT which recognizes and moves them from MSGONLY to

the IMSTRANS data set. With this change, MXG now matches

exactly to 99.5% of IBM's DFSILTA0 program (which ,may be

the culprit, since it doesn't start counting transactions

until an IMS checkpoint record is found, while MXG begins

with the first record on the IMS log.)

-You must add a new DDNAME to the JCL which uses TYPEIMS

(this has been done to step TESTOTHR in JCLTEST):

//INSTREAM DD UNIT=SYSDA,SPACE=(CYL,(1,1))

which is used in the new EXIMSOUT exit for the "instream"

creation of the $TEMPIMS. tempory SAS FORMAT.

-All references to the unnecessary and redundant _IMSWORK

macro were removed to avoid confusion. Since IMS log data

is processed in a separate step from other data records,

there is no need for a work DD name other than WORK.

Thanks to Pete Shepard, Ashland Oil, USA.

for lots of arduous work.
Change 06.052 -TYPE78.. data sets variables INSTALL, ONLINE, VARIED,

VMAC78 OFFLINE, INVLID, PCTPTHBY, NOSTCPS, NOUCBFND, NOHDWMES

Apr 1, 1988 were not set blank by an ELSE clause if the bit test was

false, which could cause the 'Y' value to be propagated

(incorrectly) into the next segment in the record.

(Change 5.27 fixed this for VMAC74 but overlooked VMAC78.

-Labels for NRIOPENQ and NRIOPREQ were reversed.

Thanks to Stephen Geard, Commonwealth Bank of Australia, AUSTRALIA.

Change 06.051 When the SORT list for BUILDPDB data sets was expanded to

WEEKBLD handle the NODUP option in MXG 4.4, weekly and monthly

MONTHBLD members BY lists were not updated. While only one user

Apr 1, 1988 noticed this oversight, now the BYLISTs agree with the

PDB order as documented in the MXG supplement pp263ff.

Thanks to Marge Hagen, GTE Marina del Rey, USA.

Change 06.050 Comments were re-written to better describe the default

TYPEROSC ROSCOE data sets created by this member. No code changed.

Mar 31, 1988

Thanks to Craig Feistner, CITICORP South Dakota, USA.

Change 06.049 SYNCSORT SMF record had minor exposure in calculating the

VMACSYNC date part of SORTEND datetime stamp for sort which began

Mar 31, 1988 on one day and ended on the next day. Lines 260-261 were

reversed; the IF test precedes the calculation.

Thanks to Chuck Hopf, Dean Witter Reynolds, USA.
Change 06.048 RACF type 80 format TYPE80ER was not correct (and caused

VMAC80 an overlooked note on the SAS log). It is now.

Mar 31, 1988 Add one new line after 1261:

@; IF LENAOF GE 76 THEN INPUT

b.Change three occurrences of NPN to NPM.

Thanks to Mark Bercov, Canadian Occidental Petroleum, CANADA.

Change 06.047 This change consolidates all current reported errors in

ANALNPM support for the new type 28 SMF record. The comments at

VMAC28 the beginning of VMAC28 are now enhanced and provide a

Mar 17, 1988 cross reference of the type 38 variables with their new

Mar 31, 1988 type 28 replacements: TYPE38EX in NPMEVNCP & NPMEVNET,

TYPE38IN in NPMINLU & NPMINPU, and TYPE38NC in NPMINNCP.

a.These five new data sets are not exact replacements for

the three TYPE38.. data sets, and for consistency all of

the old NPA prefixes were changed to NPM (NPA was the old

IBM FDP, which died a graceful death). Your TYPE38..

reports will need to be changed; use the aforementioned

cross reference of new/old variables and data sets in the

comments at the beginning of VMAC28.

b.NPM 1.3 type 28 record creates two lengthed NAD segments

and the shorter length caused an INPUT STATEMENT EXCEEDED

RECORD LENGTH error. Add one new line after 1261:

@; IF LENAOF GE 76 THEN INPUT

c.Changed three mis-spellings from NPN to NPM.

d.Exchanged 20 and 30 in line pairs 24,25 and 1424,1427.

(This will exchange observations in NPMINSES & NPMINRTM.)

e.Repeated line 731 as 731.1 with 0F5X setting NND.

f.Added new line 779.2 with +2 (missed reserve field).

g.Added new line 1201.1 to set AOFTYPE='NAC' with OR

(NPMSUBTY EQ 18X AND NPMTYPE EQ 81X).

Added new line 1202.1 to set AOFTYPE='NAD' with OR

(NPMSUBTY EQ 18X and NPMTYPE NE 81X).

h.Renumbered VMAC28 and ANALNPM to "level set" for future.

i.You can see that many users helped in the validation

of the 6.1 pre-release of SMF 28 support. There still

may be record combinations which have not been tested,

and there are not really any reports yet, especially from

the new data sets, but (to paraphrase SAS' Robert Cross

at 1988 SUGI, about the major SAS re-design, MVA for

Multi Vendor Architecture which was only a concept last

SUGI): "Now it works!" Thanks for all who helped:

Thanks to Ray Dickensheets, Yellow Freight System, USA.

Thanks to Rodney L. Reisch, General Electric Silicon Products, USA.

Thanks to Barry Pieper, FBS Information Services, USA.

Thanks to Matt Cody, Jostens, USA.

Thanks to Chuck Hopf, Dean Witter Reynolds, USA.

Thanks to Diane Eppestine, Southwestern Bell, USA.

Thanks to Rodney L. Reisch, General Electric Silicon Products, USA.

Thanks to Mike Pichowicz, U.S. Trust, USA.

Thanks to Billy Westland, Candle Corporation, USA.

Thanks to Robert Bunn, IBM NPM Level 2, USA.
Change 06.046 This MXG system for measuring your DASD farm (data set

FMXGUCBL sizes from VTOCs) now supports the 3375 DASD device.

VMXGVTOC

Mar 17, 1988

Thanks to Chuck Rexroad, Perpetual Savings Bank, USA.
Change 06.045 -Cosmetic clean-up in JCLTEST member in step TESTUSER adds

JCLTEST the EPILOG DDNAME. In TESTUSER member, %INCLUDE TYPESYNC

TESTUSER was added to create and test SYNCSORT data set. We use

VMXGUSE JCLTEST to create MXG's cross-reference that is input to

Mar 17, 1988 both the auto documentation (DOCVER, DOCVERnn) and the

conflict analysis (variable names, types, formats, etc).

XREF and DOCVER are the final runs before a pre-release

of MXG Software is ready for shipment.

-A new style macro %VMXGUSE was contributed by Dan Kaberon

that builds an MXG execution for a specific subset of SMF

records. This is provided as an example only. The MXG

development of a code generator to trivialize that task

is ongoing, but not with the %MACRO facility. Consider:
BUILD XAONLY 30.4 30.5 26 ADD=MYVAR DROP=OLD1 OLD2
for you to create the TYPE30_4, TYPE30_5, TYPE26 datasets

with the MXG default variables (but only from MVS/XA) and

with trivial tailoring of kept variables through ADD= and

DROP= syntax. This is a list processing problem, where

the input lists are a tested, changing part of MXG code.

A data step seems to be the only right way to implement

this design, but don't look for it before 1989! Another

MXG user has shown me his proprietary solution which is

based on a data dictionary, implemented with macros. It

is also under consideration. Then also, SAS Institute

announced at SUGI 88 that the SAS/AF CPE Reporting System

(currently free upon request) will be automatically on

SAS 5.18. That is likely to be the test bed for any such

MXG offering.

Thanks to Dan Kaberon, Hewitt Associates, USA.
Change 06.044 The optional DL/I counters and clocks which can be added

IMACICDL to your CICSTRAN data set from type 110 SMF records may

Mar 8, 1988 not be labeled. The LABEL statement is inside the 1.6

comment block, but not in the 1.7 comment block. If you

enabled both 1.6 and 1.7 DLI counting, your labels are

fine, but if you enabled only 1.7 DLI counts, you should

copy the LABEL statement from in the 1.6 code in IMACICDL

into the same place in the 1.7 code.

Thanks to Jim Gilbert, Texas Utilities, USA.
Change 06.043 This ASM program and associated REXX EXEC is for VM/SP

ASMVMCOPY and VM/SP HPO sites who do not have a CMS SAS license,

REXXCOPY who want to copy the VM/Monitor spool data records to a

Mar 8, 1988 CMS file (typically to then be processed by MXG under the

MVS SAS System). The EXEC should be self explanatory, and

the ASM source program needs only compiled and linkedited

to be useful. (If you have the CMS SAS System, the Infile

Exit named MONITOR allows the copy of Monitor Spool Class

data directly, without ASMVMCOPY program.) This program

is functionally equivalent to the VM MAP MONDISK/MONTAPE

routines.
Change 06.042 Support for RMDS Release 3.0. One MXG Format, new values

FORMATS for existing formats, and a new Macro in IMACRMDS is now

IMACRMDS required to tell MXG whether its RMDS release 2 or 3, as

VMACRMDS there is no version indicator in the data records.

Mar 8, 1988 self-recognition.

Thanks to Randy Graves, City of Albuquerque, USA.

Change 06.041 Reserved Change number.

Mar 8, 1988

Change 06.040 Support for the SMF record created by Goal System's

ANALPDSM PDSMAN/SP product. This code was written in Germany and

EXTYPDSM donated to MXG. It was slightly restructured, and thus

IMACPDSM any errors are my fault, not theirs.

TYPEPDSM This implementation (which started with functioning code)

VMACPDSM produced a "typical" MXG support set for an SMF record:

Mar 7, 1988 Five new source members, 250 SAS source lines, one SAS

data set with 21 variables and one new MXG format.

Thanks to Engelbert Smets, Provinzia Versicherungsanstalten, GERMANY.

Change 06.039 Member ANALDB2R produces DB2PM-like summary reports. They

ANALDB2 have been further validated by detail comparison and now

ANALDB2R they should be reliable. This validation uncovered an MXG

Mar 7, 1988 error in member ANALDB2R which affected variable QXFETCH

in DB2STAT1 data set, because Change 5.144 (which changed

QXQUERY to QXFETCH) was not applied to ANALDB2R.
The ANALDB2R report has been re-written as four new-style

%macros and support reports by DB2 system. Comments in

that member describe the selection criteria. Another DB2

report has been added also. Expect more DB2 reports in

the next prerelease (which hopefully will support the SMF

type 102 DB2 record as well)!

Five SQL values in the Accounting summary were close, but

were nevertheless wrong. Most of the other differences

between DB2PM and MXG reports came from these factors:

a. IBM uses a slightly different value for interval in the

denominator of all rates (still under investigation,

but it looks like IBM modulos minimum to adjacent 10

minute TOD, modulos maximum SMF time up to its 10 min

TOD and then takes difference as interval).

b. A difference of one in the last digit almost always is

noted. IBM truncates, MXG rounds.

c. IBM averages include zero values but MXG used to use a

SAS missing value. MXG now sets zero to agree with IBM.

d. Errors (in my opinion, still under investigation) in

their DB2PM Statistics Summary report code:

1. Buffer Pool "Current Active Buffers" is actually the

maximum number of buffers, and the Max/Min numbers do

exist, even though not printed by DB2PM.

2. Service Controller "Datasets Open - Current" is larger

than "Datasets Open - Maximum" and not equal to either

current or maximum in SMF record. SMF=MXG looks right

now. This was reported in Change 5.89d.

3. Still as reported in Change 5.89a, EDM Pool "FREE PG

IN FREE CHANGE" and adjacent AVERAGE values are wrong

because QISEFREE is (incorrectly) the value from the

preceding record.

4. Change 5.89e (Agents Services and Storage Manager)

fields (QVASX... and QSST...) have not been confirmed

as corrected.

5. System Events "Abends EOT" shows zero even though the

next page, Subsystem Service Component "Subsystem

Allied Memory EOT" value is 203.

e. Additional changes in the Accounting Summary report:

-Group total line printed only when there was a group!

This will reduce the size of the MXG report by half as

many pages as it was.

-RATE/HR and %DYNSQL report fields are now calculated.

-The average values in this report now agree with IBM's.

Five fields (ABNRM TERM thru OTHER MANIP) disagreed. The

1st was wrong, the others were different because IBM's

averages included 0 values, while MXG used missing value

There was no error in the MXG DB2ACCT data set, only in

this ANALDB2R report program.

This change required 16 dedicated hours.
Thanks to Louis Eliscu, Continental Insurance Company, USA.

Thanks to Ralph A. Pepe, Connecticut Bank & Trust Company, USA.

Change 06.038 Continued validation of MXG VM/Monitor data sets shows a

ANALVMOS numeric difference on some average values. These design

VMACVMON considerations caused the variations:

Mar 05, 1988 -MXG set values to missing, while IBM sets everything to 0

(which changes the Number of observations in the Mean).

-MXG defined ACTIVE if the USER used any CPU time during

the interval while IBM tested only the virtual CPU time.

There are lots of user records (for PROFS users maybe?)

with CPUSVITM zero but with CPUSTOTM non zero that MXG

formerly counted ACTIVE. CPUSTOTM non-zero with CPUSVITM

non-zero means CP CPU time with no VTIME. This may be a

result of PROFS machines, actually inactive during the

interval, whose "display clocks" must nevertheless be

updated (or something like that) causing measured CP CPU

time during the interval. In any event, MXG now counts

ACTIVE just like IBM.

-MXG deleted all records in the first two intervals. This

was done in initial testing when large CPU time values

were found in the first few records, and because the 1st

record will eventually be deleted (can't calculate delta

'til you get the second record). However, the real cause

of those "bad" CPU times turned out to have been fixed

by Change 5.133 (negative decremented counter reset)!

-In summary, MXG now keeps the second interval, uses zeros

and IBM's ACTIVE calculation to more closely match VMMAP

reports. The detail data was never really wrong.

a.ANALVMOS needed PROC SORTS and some new calculations for

the Paging and Swapping Volume data sets to be right in

the summary reports and data sets.

b.VMACVMON revisions include:

-Logic which used to output observations after the second

interval (INTRVCNT GT 2) was changed to (INTRVCNT GT 0)

so that all records initially create an observation.

-Final MERGE to build VMONPERF data set now does delete

the first interval (after delta calculation). This was a