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

Part 1, pages 1-106 provide much better documentation

than its predecessor. A big thanks also to IBM to make

the manual available early so support can be in place!
Change 08.147 TYPE41 variable SMF41LRG is already in bytes and the line

VMAC41 SMF41LRG=SMF41LRG*4096; must be deleted. Some labels did

Oct 1, 1990 not contain * for split characters, but now they do!

Thanks to Ken Williams, Australian and New Zealand Banking, AUSTRALIA

Change 08.146 New members. This set of members provides a capacity

ANALPRTR measurement and planning system for printers, and it

ASUMPRTR defines measures of printer throughput. It is preliminary

IMACPRTR and further additions to BUILDPDB may be made. Definition

TRNDPRTR of printers, costs, etc., are made in IMACPRTR, and then

Oct 1, 1990 member ASUMPRTR can be added to BUILDPDB to create the

dataset PDB.TYPE6ENH ("Enhanced", with throughput stats),

which is the basis for ANALPRTR, and TRNDPRTR. See the

comments in each member for documentation.

Thanks to Chuck Hopf, Hopf Consulting, USA.

Change 08.145 RACF variable RACFDESC contains undecoded values which

FORMATS were printed as a colon because the MXG format did not

Oct 1, 1990 recognize the additional bits added by RACF 1.9. The data

itself was not wrong; bit 0 is a violation and bit 3 is

a warning. Because IBM uses multiple bits in this field,

the $MG080DE. format now includes values A0 and 88 for

violation and values 30 and 18 for warning.

Thanks to Joseph Rannazzisi, Brooklyn Union Gas, USA.

Change 08.144 New members. JCL example and code used to print the MXG

JCLUPPDS source library (or any source PDS) in two column format

VMXGPPDS with an Index of members. The JCL uses standard IBM PSF

Oct 1, 1990 control statements in the SYSIN for all steps.

Thanks to Chuck Hopf, Hopf Consulting, USA.
Change 08.143 Critical error, but only in MXG 8.3. The order of INDATA

TRNDRMFI datasets was changed for consistency, but the (IN=INWEEK)

TRND72 option was not re-located, which caused the Trend dataset

Oct 1, 1990 TYPE72 and RMFINTRV to be badly corrupted.

Change INDATA to correctly read:

INDATA=WEEK.TYPE72 (IN=INWEEK) TREND.TRND72,

INDATA=WEEK.RMFINTRV (IN=INWEEK) TREND.RMFINTRV,

Thanks to Raymond Zieverink, Belk Stores Services, USA.

Change 08.142 This member was intended to produce trend charts from the

GRAFREGR VM/370 trend data set TREND.VMONINTV, but somewhere in an

Oct 1, 1990 EDIT session, VMONINTV inadvertently became RMFINTRV!

Thanks to Bob Yeager, Whirlpool Corporation, USA.

Change 08.141 -Enhancement. The existing code used default pattern and

GRAFTRND color selection when building bar charts. This is fine

Oct 1, 1990 when the graphs are viewed in color, but if reproduced in

black and white they can be very difficult to read. This

change solves this problem by alternating cross-hatching,

left diagonals, and right diagonals in varying densities.

Colors are also selected but only eight are used. If the

default PCBATCH device driver is used, there should be no

difficulty on any device with eight or more colors. You

could use a color catalog (described in the SAS/GRAPH

manual) to modify the colors in use. All MXG GRAFxxxx

routines that use the PCBATCH device driver default to

WHITE for the titles and axes and any text. If you are

using a pen plotter, you may wish to force the conversion

from WHITE to BLACK.

-Bar charts for workloads create segments in the legend

for workloads that have zero CPU time. This is not really

an error but it's annoying to have to explain nonexistent

workloads to your management. This change only outputs

those workloads with non-zero CPU time.

-If SASGRAPH=NO and SASSTAT=YES were specified, the first

plot received a "variable not found" message. The PROC

PLOT was pointed at the wrong dataset.
Change 08.140 New member that produces bar charts of workloads by hour

GRAFWORK from RMFINTRV. Will use SAS/GRAPH if available, otherwise

Oct 1, 1990 produces printer charts and tabular reports.
Change 08.139 Cosmetic change added new optional argument INVOKEBY to

VMXGSUM %VMXGSUM macro that will be printed on the SAS log to

Oct 1, 1990 identify which member invoked %VMXGSUM. As time permits,

each MXG invocation of %VMXGSUM will be changed to pass

the member name into this argument for documentation on

your log. This is mostly helpful when one is debugging!

Change 08.138 Significant validation and enhancement of MXG's supprot

EXHSMDSR for the HSM User SMF records (default is 240 and 241) is

EXHSMFSR added by this user contribution. Code has been unloaded

EXHSMFST and syntax tested, but not actually used. One of the HSM

EXHSMFUN SMF records contains accumulated counts that are reset

EXHSMVSF each midnight, and de-accumulation may be desirable but

EXHSMVSR has not yet been investigated. The other record seems to

FORMATS be directly usable.

IMACHSM

VMACHSM

Sep 19, 1990

Thanks to Wanda Prather, Johns Hopkins APL, USA.

Change 08.137 TYPE1415 Hiperbatch variables (added by Change 8.017) are

VMAC1415 non-zero (garbaged) for type 14/15 records with more than

Sep 19, 1990 one UCB, which occurs only for BPAM accessed concatenated

PDSs, which aren't even eligible for Hiperbatch! The test

IF LENGTH-COL+1 GE 20 THEN .... should be changed to

IF LENGTH-COL+1 GE 20 AND NUCB=1 THEN .... so that only

non-BPAM data sets with a single UCB are tested to see if

the hiperbatch fields exist. (MXG must use the length of

the record to determine if data exists that could be the

hiperbatch fields, because IBM does not set a flag to say

that the fields are present, and IBM also failed in the

original implementation to set the length of the segment

to include the new fields!)

Thanks to Linda Carroll, Crawford Long Hospital of Emory Univ, USA.

Change 08.136 The DFP 3.2 type 42 SMF record to audit an ACTIVATE event

VMAC42 is created in error. IBM APAR OY36035 describes the error

Sep 18, 1990 and PTF UY55307 is the correction for their error. The

subtype 3 (audit) record is mis-located and incorrectly

documented in the SMF manual, and will cause MXG to abend

with a STOPOVER, than can be circumvented only by adding

this test to member IMACFILE (which deletes all subtype 3

audit records) until the PTF exists from IBM:

IF ID=42 THEN DO;

INPUT @85+OFFSMF TESTDFP $CHAR8. @;

IF TESTDFP='ACTIVATE' THEN DELETE;

END;
or alternatively by using the MISSOVER circumvention for

STOPOVER option as described in Change 8.012.

Member VMAC42 was re-written based on the corrected SMF

record description received from IBM Level 2, and tests

for both the right and wrong format record. Fortunately,

the subtype 3 record is not very important and deleting

it won't really hurt the good data in the other subtypes!

Thanks to Dan Barbatti, Southwestern Bell, USA.
Change 08.135 PR/SM changes in status were not decoded in TYPE70PR. Now

VMAC7072 variables LCPUCHST, LCPUCHWT, LPARCHAC and LPARCHNR flag

Sep 17, 1990 that changes occurred in LCPUWAIT status, LCPUSHAR value,

Activation/Deactivation, or Number of LPARS in Partition,

respectively.

Thanks to Richard Evans, Mervyns, USA.

Change 08.134 The ACBMACR1-3 variables added in MXG Version 7 (decoded

VMAC64 after PTF UY40839, APAR OY23661 has been installed) are

Sep 15, 1990 now explicitly decoded into useful new flag variables:

ACBADR ='ACCESS*WITHOUT*INDEX?'

ACBAIX ='AIX OF THE PATH IN THE GIVEN DDNAME?'

ACBCNV ='CONTROL*INTERVAL*PROCESSING?'

ACBDFR ='DEFER*WRITES'

ACBDIR ='DIRECT*PROCESSING?'

ACBDSN ='SHARING*CONNECTION*USING DSNAME?'

ACBGSR ='GLOBAL*SHARED*RESOURCE?'

ACBICI ='IMPROVED*CI*PROCESSING?'

ACBIN ='INPUT*(GET,*READ)?'

ACBKEY ='ACCESS DATA*VIA*INDEX?'

ACBLOGON='LOGON*INCICATOR*(VTAM X03004)?'

ACBLSR ='LOCAL*SHARED*RESOURCE?'

ACBMODE ='VSAM*31 BIT*ADDRESSING?'

ACBNCFX ='CFX IF Y,*NFX IF BLANK?'

ACBOUT ='OUTPUT*(PUT,*WRITE)?'

ACBRST ='SET*DATA SET TO*EMPTY STATE?'

ACBSEQ ='SEQUENTIAL*PROCESSING?'

ACBSIS ='SEQUENTIAL*INSERT*STRATEGY?'

ACBSKP ='SKIP*SEQUENTIAL*PROCESSING?'

ACBUBF ='USER*BUFFERS?'

Thanks to Derek Cespedes, Florida Power and Light, USA.

Change 08.133 The technique for setting the number and length of the

IMACACCT Accounting variables kept in MXG from SMF records has

Sep 13, 1990 always been an exposure to user error, because the user

was required to actually alter the SAS code in member

IMACACCT, which occasionally caused a STOPOVER condition

to new users unfamiliar with SAS syntax. A much safer

and easier technique has now been implemented. Instead of

commenting out code for unwanted account variables, the

simple addition of a DROP statement naming the unwanted

variables will keep only the wanted with no code changes.

Existing sites need not change their IMACACCT member, but

may wish to do so anyhow.

The only price for this technique is that programs that

%INCLUDE member IMACACCT more than once will cause a new

warning message (but only under SAS 5.18) that reads:

WARNING 393:VARIABLE ALREADY SPECIFIED IN DROP/KEEP LIST.

The warning itself has no effect.

Thanks to Rich Hawthorne, Group Health Coop. of Puget Sound, USA.

Change 08.132 One major and several minor changes to RMF to support the

VMAC7072 ES/9000 series under MVS/ESA 3.1.3 from (GC28-1819-3).

VMAC71 1.ES/9000 Processors will cause STOPOVER abend on type 78

VMAC73 SMF records, because IBM added data to the IOP and IOQ

VMAC74 sections which MXG was not prepared to handle! The new

VMAC75 fields (see below) are now supported, and the MXG "SKIP"

VMAC76 logic now protects future segment length changes. Even if

VMAC77 you have this MXG change installed, MXG will STOPOVER if

VMAC78 IBM's PTF for APAR OY36517 is not installed, as the IBM

VMAC79 PTF which added RMF support for ES/9000 (UY90666) itself

Sep 13, 1990 is in error until PTF OY36517 is installed.

2.New flag variables ESCAENAB,ESCACONF identify if this

processor is enabled for ES Connection Architecture, or

there is an ES connection director in the configuration.

3.The MSOCOEFF field in the type 72 and type 79 records was

increased from 4 to 8 EBCDIC characters (I cannot imagine

why) and relocated to the end of the section. MXG picks

up the longer field if it exists, but since an 8 digit

number can still be stored in a 4-byte MXG variable, the

IBM increase has no effect on the MXG MSOCOEFF length.

4.PCTDIRPT, percentage of samples when I/O was delayed due

to Director Port (ESCA, or Fiber Optic Channels) busy is

added to TYPE78CF, TYPE79EF, and as variable R799DPB in

TYPE799.
The only circumvention for the STOPOVER condition until

you receive this change is to delete the type 78 subtype

3 record in member IMACFILE:

IF ID=78 AND SUBTYPE=3 THEN DELETE;
or alternatively use the MISSOVER replacement for the

STOPOVER option as described in Change 8.012.

Change 08.131A Minor enhancement to TYPE41AC and TYPE41UN data sets for

FORMATS Data-in-Virtual added format for object type (DA) and

VMAC41 object mode (Read or Update).

Sep 12, 1990

Change 08.131 The CMS example on page 24 of the MXG Supplement to copy

VM example VM/Monitor data to a CMS file named MONITOR DATA A does

Sep 12, 1990 not specify DCB attributes on the FILE MONOUT statement,

and the CMS default of FB, 80, 960 causes the output data

records to be truncated. The correct FILE statement is:

FILE MONOUT RECFM=VB LRECL=4092 BLKSIZE=4096;

There is additional discussion of possible problems with

the subsequent GLOBAL statement in Change 6.212 in member

CHANGE06.

Change 08.130 Validation and enhancement of the DCOLLECT processing was

VMACDCOL added by this change. All 7 record types are supported to

Sep 12, 1990 create DCOLDSNS, DCOLVOLS, DCOLCLUS, DCOLMIGS, DCOLBKUP,

DCOLCAPD, and DCOLCAPT data sets. The documentation for

the output of this IDCAMS utility named DCOLLECT is found

in several manuals. GG24-3540-00 "DFSMS Planning and

Reporting" provides an overview of DCOLLECT. The first 3

MXG data sets above are built from VTOC/VVDS information

and their contents are described in Appendix E of DFP 3.2

"Access Method Services for Integrated Catalog Facility",

SC26-4562-1. The final 4 MXG data sets are HSM related,

and their contents is described (poorly, DCOLLECT is not

even cited in the table of contents nor the index) in

Chapter 17 (User Application Interfaces) of SH35-0084-4,

"DFHSM 2.5.0 Installation and Customization Guide".

A future MXG newsletter will contrast the data available

from the DCOLLECT facility with the data created from the

VMXGVTOC and VMACVVDS, and will (hopefully) also compare

the HSM DCOLLECT data captured with the data available

from MXG's JCLHSM (BCDS,MCDS, etc), and the HSM SMF data

record (VMACHSM, still work in progress). The initial

review does make DCOLLECT attractive, especially since it

is a supported interface from IBM, but there appears to

be some data simply not available from DCOLLECT that may

be important (such as physical data set location).

Thanks to Jim Gilbert, Texas Utilities, USA.

Thanks to Sal Fazzino, General Electric Capital, USA.

Change 08.129 SAS 5.18 Compiler Error 344 circumvention. An iterative

XMACACHE DO was added by MXG 8.3 for DB2 Distributed Header in the

Sep 12, 1990 VMACDB2 processing. That broke the compiler limit in 5.18

at a site which had added DB2, Cache DASD, and several of

their own SMF records to BUILDPDB processing. In looking

for additional opportunities to eliminate iterative DOs,

this change creates replacement member XMACACHE from the

existing VMACACHE member. XMACACHE will ONLY process the

3990 Cache Controller records (although the 3880 datasets

will still be built with zero observations) and thereby

eliminated 4 iterative DO statements. If you have added

VMACACHE processing to BUILDPDB and get the 344 Error,

copy XMACACHE into your USERID.SOURCLIB and rename it

therein to VMACACHE. The original discussion of Error

344 Circumvention is in Change 7.038 in member CHANGE07.

Note that 344 is only a problem with SAS 5.18. There is

no limitation on iterative DOs in SAS 6.06.

Thanks to Dan Barbatti, Southwestern Bell Telephone, USA.

Change 08.128 SMS (System Managed Storage) adds a new record to the

VMAC60 VVDS for non-VSAM files on SMS-managed volumes, a pseudo

VMACVVDS VVR record called the NVR. Unlike real VVR records that

Sep 5, 1990 describe space, etc., the NVR record has no such data.

However, the NVR and the VVR records both now contain the

SMS attributes (Data, Storage, & Management Class Names).

The new MXG variables VVRDATCL,VVRSTGCL,VVRMGTCL are the

class names, new variable VVRSBKUP is the last backup

date, and flag variables VVRNATTR,VVRSMSFG were added.

The NVR record was processed without error by TYPEVVDS,

but the TYPE60 member failed with a STOPOVER condition

if it encountered the new NVR data record without this

change.

Thanks to Jim Gilbert, Texas Utilities, USA.

Thanks to Sal Fazzino, General Electric Capital, USA.
Change 08.127 Preliminary support for MVS/ESA Version 4 SMF changes.

IMACPDB 1.New variable VARIEDBY was added to TYPE8911 (but applies

VMAC8911 only for SMF type 9 or 11 vary record) to identify who

VMAC30 issued the vary command. (In Version 4, a terminal user

Sep 5, 1990 can actually signal to MVS to vary the device offline).

2.New variable MVSLEVEL was added to the type 30 datasets

(and will contain SP4.1.0 for MVS/ESA Version 4) so that

you can finally know which software operating system was

in use at the step/job accounting level. MVSLEVEL was

also added (in IMACPDB) to the variables to be kept in

PDB.STEPS and PDB.JOBS.

3.Additional changes in MVS/ESA Version 4 that did not need

MXG changes but which should be noted:

a. A new bit in the header identifies MVS as Version 4.

b. Long standing problem with the internal 3-byte counter

for step/job CPUTCBTM (which wrapped at 17 hours) is

now corrected, and a 4-byte field is used internally.

This will correct CPU times for these long-running job

records in the type 30 (used by BUILDPDB), but for any

site still clinging to the archaic 4, 34, 5,or 35 SMF

record, the CPU times are still only 3-bytes, and will

not be correct. (In fact, MVS Version 4 now sets a bit

if the 3-byte field overflows to tell you to use the

CPU times in the type 30 instead!).

c. APPC support was added, but accounting fields for APPC

are added only to the type 30s, and not 4,34,5,35s.

d. SMF Exits IEFUJP and IEFUJV must be AMODE 31.
Change 08.126 SAS 6.06 Compatibility. JCL Examples.

CONFIG The JCLTEST example creates the MXG Format Library and

JCLTEST exercises the MXG system under SAS. Member JCLTEST was

JCLTEST6 revised for SAS Version 5, and now %INCLUDES new member

JCLPDB SASOPTV5 which specifies the SAS System Options that are

JCLPDB6 now required by MXG Version 8.3 and later. SAS Version 5

SASOPTV5 format library still uses the DDname "SASLIB" and uses a

Sep 5, 1990 DSNAME of "MXG.SASLIB" in this example for Version 5.

New member JCLTEST6 provides an example of the JCL needed

for SAS Version 6.06, and references the CONFIG member to

specify the Version 6 recommended options. SAS Version 6

format library now uses the DDname "LIBRARY" and uses a

DSNAME of "MXG.FMTS606" in this example for Version 6.
Change 08.125 SAS 6.06 Compatibility. SYS prefix reserved in %MACROs.

ANALDMON Syntax of %LET SYSTEM causes "ERROR: Attempt to %GLOBAL

ANALNPMR a name (SYSTEM) which exists in a local environment."

Sep 4, 1990 This is actually a bug in SAS 6.06, but there is a good

possibility that the SYS.... prefix may be reserved in

%MACRO variables/arguments in SAS 6.07, and thus the two

occurrences in MXG in which SYSTEM= was used as a macro

variable (to select the SMF System ID for the report)

have been changed to SMFSYSTM= instead of SYSTEM.
Change 08.124 Variable SMGS_MIN in this NSPY reporting program should

ANALNSPY have been spelled SMSG_MIN in the FORMAT statement in

Sep 4, 1990 line 006000.
Change 08.123 The MXG 8.2 circumvention (Change 8.020) for invalid CPU

VMACSYNC time in SYNCSORT SMF records was mis-typed and caused

Sep 4, 1990 TYPESYNC to contain garbage. Line 042910 was added as

@M4 CPUERTST but it was supposed to be

+M4 CPUERTST $CHAR4.

to redefine CPUERTST as a character value of CPUTCBTM for

the subsequent test (M4 is set equal to minus four).
Change 08.122 Member FORMATS produced warning message because there are

FORMATS no quotes for $MG037FU format definition.

Sep 4, 1990
Change 08.121 DB2 PMAUD02 and PMAUD03 report request produced 145 and

ANALDB2R 170 SAS errors. The format for variable QW0145TS in both

Sep 1, 1990 PUT statements should be HEX16. instead of $HEX16.

Thanks to Tim Kearney, Allied Automotive, USA.

Change 08.120 The allocation for SAS 6.06 format library needed SPACE

FORMATS of CYL,(10,1) during 6.06 beta testing; unbeknownst to

LIBRARY me, the problem had been fixed in 6.06.01, and in fact,

SASLIB MXG's format library under SAS 6.06 requires only space

Sep 1, 1990 of (CYL,(1,1)). References have been corrected.

Thanks to Dan Squillace, SAS Institute Cary, USA.

--Changes thru 8.119 comprised MXG PreRelease 8.3 Dated August 26, 1990-
Change 08.119 IMS Log Input Queue times were incorrect whenever an

TYPEIMS IMS transaction had no ARRVTIME in its 01/03 record.

TYPEIMSX Why IBM can't put the DATE and TIME in every IMS log

VMACIMS record is beyond me, but they don't. Because of the

Aug 26, 1990 missing value, these records sorted early and caused

sometimes significant errors in IMSQUETM & RESPNSTM.

Comparison with IBM's DFSILTA0 output shows that IBM

uses the ENQTIME as the ARRVTIME in these cases, and

now MXG also uses ENQTIME. The implementation was to

use the timestamp of the just-previous-log-record minus

.001 for ARRVTIME when ARRVTIME was missing. That causes

the sort order to be correct, and the .001 allows MXG

to recognize that ARRVTIME was missing (IMS time stamps

are only accurate to .1 seconds), and thus MXG can use

ENQTIME for ARRVTIME in these cases.

In further examination of the test data and the output

of DFSILTA0, it became apparent that even IBM's IMS

guru's can't figure out how to put IMS transactions

together with that program, even though DFSILTA0 is

essentially simulating IMS processing and can keep

everything it needs in virtual storage. About one

third of these IMS 2.2 transactions have missing

time stamps on the DFSILTA0 report, especially when

multiple transactions are executed with a single

program schedule. Further review suggested that if

using the adjacent record's time stamp was good for

a missing ARRVTIME in an 01/03 record, it was also good

in those many cases where the 03 log contained a non-

missing, but much-earlier-than-now timestamp, and now

those cases are also detected and protected this way.

Additional logic enhancements were offered by Ashland

Oil, whose contribution in recalculation of output queue

times were implemented in this change as well.

And for those of you still using IMS 1.3, remember that

member TYPEIMS1 (See Change 7.075 in member CHANGE07)

is only for that archaic IMS version.

Thanks to Richard S. Ralston, Rochester Telephone, USA.

Thanks to Ervin Claxon, Ashland Oil, USA.

Change 08.118 IMS Log processing did not handle a cold start. This

IMACIMS contributed discovery added processing in VMACIMS to

TYPEIMS detect a cold start of IMS (a subtype of type 40 record)

VMACIMS and added IMSQBLDN to count each new queue build event.

Aug 25, 1990 In TYPEIMS, the SORT order which formerly was

IMSTAPNO DTOKEN PSTNUMBR TRANSACT IMSRECNO is now

IMSQBLDN DTOKEN PSTNUMBR TRANSACT IMSTAPNO IMSRECNO

which not only handles cold starts, but solves several

site's problems with incorrect input queue time, by

re-associating IMSTAPNO with IMSRECNO. The same SORT

logic (with different variables) was applied throughout