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

pre-9907 logic; the old format that stopped at (Z) did

not have values for (11), etc, so an old (12) was seen

as length 12, but the revised format now has (12)=38,

so even though nobody probably still is using the old

TNG format, I fixed it so my QA run with old and new

data still works.

-STARTIME was correct for the first group of records, but

it grew well into the future because it was not reset to

ORIGTIME at the start of each object's counter's input.

-STARTIME was still wrong in the first day's MXG 19.03,

but was corrected in VMACTNG internally dated Jul 27.

Thanks to Greg Jackson, National Life of Vermont, USA.
Change 19.145 Support for the Volume sections of type 42 subtype 11 XRC

EXTY42XV (Extended Remote Copy Session statistics) now create new

IMAC42 dataset TYPE42XV to track the read/write/update activity

VMAC42 at the VOLSER level. In addition, all duplicates were

VMXGINIT not being removed in TYPE42S2, but adding SMF42FBG (Cache

Jul 20, 2001 Structure Name) to MACRO _BTY42S2 removed all duplicates.

However, multiple observations from the same subtype 6

SMF record exist in TYPE42DS that were also not removed

by the NODUP sort. These multiples have different I/O

counts, but otherwise are identical, except that their

location in the record (S42JDDSO) is different, so it was

added to MACRO _BTY42DS to remove the duplicates if dupe

SMF records are read, but the two otherwise observations

from the same record will now have different S42JDDSO

values. If you discover why there are these multiples,

let me know and I'll update this text.

OBSERVATION COUNT CHANGE: TYPE42DS fewer obs.

Thanks to Mike Delaney, Pershing, USA.

Change 19.144 RMF Partition data report was updated to report on the

ANALRMFR communication devices. To get full comm reports using the

Jul 20, 2001 DEVICEC=40 parameter for commmunications, add 41 to get

the CTC adapters included.

Thanks to Joseph Rannazzisi, Salomon Smith Barney, USA.

Thanks to Jiann-Shiun Huang, CIGNA, USA.

Change 19.143 Candle did NOT correct the unsupported '20'x (instead of

VMACNAF the expected '01'x) value for the century "bit" in their

Jul 21, 2001 internal time stamps; they ONLY corrected the date part

in the SMF header field. The circumventions of Changes

18.025 and 15.211 were replaced with directly forcing the

century bit into their fields and then using an INPUT

function to convert the modified character field. This

circumvention may fail at the end of this century.

Thanks to Joseph J. Faska, Depository Trust, USA.
Change 19.142 MXG 19.02 only. The SPIN logic did not keep SPINCNT, so

VMXGUOW the SPINUOW dataset continued to grow, as there are many

Jul 20, 2001 CICS transactions whose end we don't see until the region

is terminated, and the SPIN logic depends on SPINCNT to

recognize and output those type of events into ASUMUOW.

This error was not caught in our testing because of an

incorrect IMACUOW member in our tailoring library. Sorry!

This change won't be seen until the second day's run.

Thanks to Alan Lankin, Towers Perrin, USA.
Change 19.141 The new type 74 subtype 7 FICON Director record has a new

VMAC74 option in ERBRMFxx of FCD/NOFCD that causes creation of

Jul 18, 2001 that subtype.
Change 19.140 The SASGRAPH argument was not UPCASE'd, causing test to

ANALCNCR fail if you typed your SASGRAPH=yes in lower case.

Jul 18, 2001

Thanks to Ian Davies, Independent Consultant, CANADA.

=Attended the superb SAS 25th Anniversary Party in Raleigh, NC, with

=7,200 SAS employees and families, with two bands popular in 1976:

= The Village People and KC and the Sunshine Band!
Change 19.139 An SMF 116 with invalid QWHS segment length of 108 bytes

VMAC116 (110 is expected) caused INPUT EXCEEDED STOPOVER error.

Jul 13, 2001 The QWHS segment it self was trashed, with invalid data

values for CAID, CCV, CCN, and XTYP, and the 22-byte

accounting segment was only 20 bytes. This change only

detects the short segment and prints an error message on

the SAS log. This note will be updated if an APAR is

found/developed to correct the IBM error in the record.

Thanks to Mat Elbersen, RABOBANK, THE NETHERLANDS.

Thanks to Ian Davies, Independent Consultant, CANADA.

Change 19.138 Local variables ENTEJECT caused a warning because it did

GRAFTAPE not exist, and was not referenced in sample reports, so

Jul 13, 2001 it was removed from the member.

Thanks to Ian Davies, Independent Consultant, CANADA.

Change 19.137 IMF Program record's variable FLGUESQL was incorrectly

VMACCIMS input @79 when that field is located @80. It and a few

Jul 13, 2001 other flag variables were also formatted $HEX2.

Thanks to Sergio Fastella, ALITALIA, ITALY.

Change 19.136 -TPF datetimestamp variables are written in GMT zone, but

VMACTPF MXG now converts them all to your local time of day, by

VMXGTPFI using the DB/DE records, which are written first in each

Jul 11, 2001 file, containing the GMT datetime and a local time and

Jul 12, 2001 local date (but its '01JUL' with no year, so conversion

from GMT to local has special logic to deal with JAN01

and DEC31 data to set the local year correctly!

-Variable SHIFT is now created in all datasets that have

STARTIME, that is, all interval datasets. Your IMACSHFT

definitions are used with STARTIME to set the shift of

each observation.
Change 19.135 MXG 19.01 and 19.02, IMS Log processing. Change 19.061

ASMIMSL5 was incorrect, causing invalid time stamp values. The

ASMIMSL6 asterisk in column one that was added by that change:

Jul 11, 2001 * BO DROPMAP NONRECOV Change 19.061

is removed by this change so the statement now reads:

BO DROPMAP NONRECOV Change 19.135

Thanks to Rita Bertolo, Canadian Pacific Railway, CANADA.
Change 19.134 Documentation only. When I/O delay is NOT included in

VMAC7072 velocity in your WLM, MXG's calculated VELOCIOD variable

Jul 9, 2001 estimates what the velocity would be if I/O delays, in

R723CIOD/PCTDLIOD, and WLM-managed batch initiator delay,

in R723CTDQ/PCTDLTDQ, were both included. Both impacts

are in the one VELOCIOD variable, because I didn't think

more velocity estimate variables were needed for the now

several possible combinations, and because you could

always use the EXTY72GO exit to recalculate your own

estimate if really needed.

My VELOCIOD won't match either of RMF report's values in

I/O PRTY or INIT MGMT; IBM calculations assume only the

one impact, and also say that if R723VELI is not on, that

both I/O useage and I/O delay are not included!

When I/O delay and/or Init delay are enabled in your WLM,

i.e., when R723VELI='Y', there is no discrepancy, because

VELOCITY and VELOCIOD are equal and correct.

Thanks to Steve Dyck, CDS, USA.

Change 19.133 Some JCL Examples for Assembly and LinkEdit of programs

DOC written in IBM ASM still had PGM=IEV90 and PGM=IEWL for

Jul 3, 2001 the Assembler and Link Editor, but Carl, an ASM Guru at

SAS, pointed out that the more likely names in use in

this millennium would be PGM=ASMA90 and PGM=HEWL.

Thanks to Carl Meredith, SAS Institute, USA.

Change 19.132 Support for both VM/ESA V2.4 and z/VM V3.1. The V2.4

VMACVMXA changes were added first, then the 3.1 LIST1403 was used

Jun 30, 2001 to update those changes, which are listed separately in

this change text.

Some of the new numeric variables may be accumulated and

will need to be DIF'd, so you should verify their values

before using!
These new variables were added in the Jun 30 change:
Dataset New Variables

SYTSYP: PLSDGUCT PLSXITCT

SYTPRP: PFXSPINT PFXSPINC

SYTRSG: TCMMIDSZ TCMMAIN TCMMNMIN TCMMNMAX TCMMNDL TCMSTLMN

SYSSCMAV

SYTSCG: SRMTOTST SRMWSSDL SRMWSSD1 SRMWSSD2 SRMWSSD3 SRMLLCNT

SRMCONLL SRMATOD SRMATOD2 SRMWTCPU CALSLKCT CALSLKTM

SYTUWT: CALLLIST

SYTXSG: TCMXIDSZ TCMXSMIN TCMSTLXS TCMAVGAG HCPSTPXB

MTRSYS: CALADMF VRFSG SYSTEM SYSCKVOL SYSWMVOL

MTRPRP: PFXTYPE CALUDED

MTRDEV: CALTHROT RDCRCUC RDCOBRCO RDEVSER THRDLYS THRIORTE

MTRUSR: VMDBYVAL VMDMXSHR

MTRSCH: SRMXPCTG

STOSHR: ASCCTXBK

USEACT: IUCTOTCN IUCMXCN VMDMXSHA VMDLIMTH VMDTHRCT

USEINT: HFLLIST HFPGACT VMDSLCNT

PRCPRP: CALUDED PFXTYPE HFUSERM

IODDEV: THRDLYS SCMCQTIM

IODCAD: CALSSS2

Thanks to Pat Curren, SuperValu Inc, USA.
Change 19.131 Validation of SOL260S TNG data found several minor errors

VMACTNG that have been corrected and MXG's values now matches the

Jun 29, 2001 Excel spreadsheet created by TNG.

Thanks to Bill Shanks, SEMA, ENGLAND.

Thanks to Paul Hargreaves, SEMA, ENGLAND,
Change 19.130 IBM has redefined type 103 variable TIMEWRIT as the time

VMAC103 since the last SMF write, now called SMFRecordingInterval

Jun 29, 2001 in IBM documentation, so it's label was clarified.

Thanks to Dave Cogar, Computer Associates, USA.

Change 19.129 Using UTILBLDP with BUILDPDB=NO option printed warning:

UTILBLDP APPARENT SYMBOLIC REFERENCD IDFLAG NOT RESOLVED

Jun 29, 2001 because IDFLAG was not initialized in that loop. Insert

%LET IDFLAG=NO;

after the existing %LET DE2FLAG=NO; in that loop.

Thanks to Ian Davies, Independent Consultant, CANADA.

Change 19.128 Running MXG under unix hit another lower case problem:

VMXGINIT ERROR: File does not exist /mxg/sourclib/AAAAAAAA.SAS

Jun 28, 2001 Under unix SAS, %INCLUDE SOURCLIB(MEMBER) looks for file

INSTALL "member.sas", while INFILE SOURCLIB(MEMBER) looks for

Feb 4, 2003 "member.dat", both in lower case only, so all MXG source

files must be lower cased on unix. It turns out that

when the MEMBER name has no extension, unix SAS looks

only for lower case file name, but if ANY extension name

is used (MEMBER.EXT), SAS instead looks for a file name

in the case of the source code, and the MXG statement

that was added that caused the error is in upper case:

INFILE SOURCLIB(AAAAAAAA.SAS)

One earlier fix (actually, one still discussed in INSTALL

member's instructions until Feb, 2003!) was to uppercase

the source file to AAAAAAAA.SAS, because that is the only

file in MXG that is read with an INFILE syntax. Or, you

could have lowercased the VMXGINIT member, or I might be

able to modify the MXG install process for unix to UPCASE

that one file.

But instead, the %LOWCASE macro function was inserted in

the INFILE statement for ASCII (i.e. unix/linux/WINDOWS):

INFILE SOURCLIB(%LOWCASE(AAAAAAAA.SAS))

which will cause unix to look for aaaaaaaa.sas, and you

don't have to change anything to run MXG under unix.

This also works under Windows because file names there

are not case sensitive.

Note: Don't try this under EBCDIC systems; using MVS

syntax of INFILE SOURCLIB(%LOWCASE(AAAAAAAA));

fails with a JFCB error, because MVS still can't

handle lower case DDnames.

Feb 4, 2004: The INSTALL member was revised, telling

you to leave the aaaaaaaa.sas filename in lower case.

Thanks to Chris Weston, SAS ITSV Development, USA.

Thanks to Mark Rothschild, Caremark, USA.

Change 19.127 An obscure exposure in VMXGSUM is corrected; if you had

VMXGSUM both INTERVAL= and NORMn= arguments, some variables could

Jun 28, 2001 be missing in the output dataset. None of the MXG uses

of VMXGSUM had both, but the ASUMCACH enhancement added

the INTERVAL= to an existing NORM1= argument, uncovering

the error. Correction was to relocate a code segment.

Thanks to Chuck Hopf, MBNA, USA.
Change 19.126 DFHSM 1.4 via PTF and standard in DFHSM 1.5 and later,

VMXGHSM two new variables for stacked volumes (field sequence

Jun 28, 2001 number DGNFLSEQ, file block ID DGNFBID) were added to the

DGN dataset. A reserved area was used for the two new

fields, so the IBM change is COMPATIBLE.

Thanks to Wanda Prather, Johns Hopkins Applied Physics Lab, USA

Change 19.125 Support for TPF releases PUT08, PUT10, and PUT12, which

VMACTPF inserted data fields incompatibly in several records.

VMXGTPFI The major changes were internal, to add the many new

Jun 27, 2001 variables for the 9th thru 16th Instruction Streams into

Jun 29, 2001 TPFSX dataset, and two new variables in dataset TPFDX.

Jul 10, 2001 Variable SXTWCSPR was dropped from TPFSX dataset and the

VMXGTPFI was revised to not reference that variable.

Internal mapping formats for TPFDR & TPFDH now use CPUID

so that TPF data from multiple systems can be processed

by concatenation of the input files. New variable SYSTEM

is created in dataset TPFINTRV; you must update the table

in your member IMACTPF to map which CPUIDs are in which

system to populate variable SYSTEM. There still is one

observation per CPUID per interval in TPFINTRV dataset,

but if you update that table, variable SYSTEM will exist

so that you can use it in subsequent summarization.

Jul 10: Added ZDATE to TPFINTRV.

Obs with FFCCHHR='00'X are now OUTPUT in TPFFF;

they are Virtual File Access and should not have

been deleted.

Several misspellings of 9-G variables corrected.

Thanks to Robert Wilcox, Sabre, USA.

Thanks to Jim Gilbert, Sabre, USA.
Change 19.124 -Adding the processing of SOLVE SMF to BUILDPDB caused

VMACLDMS WARNING: VARIABLE YYYY HAS ALREADY BEEN DEFINED AS NUM...

VMACMDF Change temporary variable YYYY to YYYYCH in two places to

VMACSOLV eliminate the conflict and the warning message.

Jun 28, 2001 -Changed CONDCODE to CONDCODH in VMACLDMS, to avoid a

conflict, and because it is the Highest CondCode value.

-Changed temp variable DOMFLAGn to DOMDFLGn in VMACMDF.

-This change was precipiated by the VMACSOLV error, but

the MXG QA stream should have caught this conflict of

variable types, because ANALCOMP is now run to compile

simultaneously all SMF-reading MXG programs to find any

such conflicts. Why were all three not caught then? In

fact, this error was caught by the April 5 QA run, but it

took this error to remind me to use that enhancement to

make these corrections!

Thanks to John Temme, Department of Defence, AUSTRALIA.

Change 19.123 Enhancement to ASUMCACH, for DASD Cache and DASD I/O.

ASUMCACH Variables that identify the control unit are added using

Jun 28, 2001 a PROC FORMAT as a table lookup. Summarization is now

forced to QTRHOUR level (so that if there are multiple

systems where the TYPE74 and TYPE74CA dataset times are

not exactly aligned, we will now always put the data

together. And additional variables are created to allow

better downstream reporting capabilities. The SORT order

of the output is now SYSPLEX STARTIME DEVNR VOLSER, so

you can examine the data by SYSPLEX.

Thanks to Chuck Hopf, MBNA, USA.
Change 19.122 Documentation of an example use of the EXPDBSPN exit.

EXPDBSPN The site had used IEFACTRT exit to put account info for

Jun 26, 2001 STCs in type 30_4 and 30_5 SMF records in PGMRNAME, but

BUILDPDB keeps PGMRNAME only from TYPE26 and TYPE30_1,

and their exit was after the type 30-1 was created.

Adding variable PGMRNAME to the Keep list for 30_5 did

now work, because the MXG MERGE statement has TYPE30_5

first, and then TYPE30_1 (as required by BUILD005 logic),

causing the blank value in TYPE30_1 for these STCs to

overwrite the non-blank PGMRNAME in TYPE30_5. For this

site's specific SMF modifications, the solution was to

use the EXPDBSPN exit, which is taken just before the

"Big Merge" (see member DOCPDB for more details than you

probably want to read), and in their exit code, add the

PGMRNAME from their TYPE30_5 dataset into the TYPE30_1

dataset, and then the "Big Merge" logic works just fine.

This example is the code they inserted into EXPDBSPN:

DATA TEMP30_5 (KEEP=READTIME JOB JESNR PGMRNAME);

SET TYPE30_5;

DATA TYPE30_1;

MERGE TYPE30_1 (IN=IN1) TEMP30_5 (IN=IN5);

BY READTIME JOB JESNR;

IF IN1 THEN OUTPUT;

and they also had to insert:

%LET ADD30U5=PGMRNAME;

before their %INCLUDE SOURCLIB(BUILDPDB); statement, to

add the variable PGMRNAME to be kept in TYPE30_5 inside

the BUILDPDB logic.

Thanks to Duncan Walker, Experian Limited, ENGLAND.
Change 19.121 The macros did not UPCASE the DDNAME, so it returned an

VGETENG incorrect value if you used lower case DDNAME in the MXG

VGETOBS macro invocation.

VMXGENG

Jun 26, 2001
Change 19.120 IBM APAR OW49536 documents new bit which is now variable

VMAC7072 LCPUVARY='Y' in dataset TYPE70PR if this LPAR was varied

Jun 26, 2001 online during this interval.
Change 19.119 New VMXGSUM option OUTVIEW=YES (default is OUTVIEW=NO)

VMXGSUM will cause VMXGSUM's output dataset to be a VIEW instead

Jun 25, 2001 of a dataset. We will use this internally so MXG will

be faster & cheaper when we can pass the output from one

VMXGSUM execution into another data step (or VMXGSUM!).

Note that if you use OUTVIEW=NO, the View will have the

same name as the OUTDATA= that you specified, but, since

it is a VIEW, that dataset will NOT exist when VMXGSUM

finishes, and if you do not reference the VIEW after it

is created, it will not physically exist as a dataset.

Thanks to Chuck Hopf, MBNA, USA.
Change 19.118 Test for &SASVER EQ 6 was changed to &SASVER GE 6, but

ANALDB2R luckily, running under Version 8 produced the correct

Jun 25, 2001 reports. The test will bypass a data step when under SAS

V6+ (by using the INHERIT option), but executing the data

step under V8 still worked correctly.

Thanks to Chuck Hopf, MBNA, USA.

Change 19.117 IMS Log processing with TYPEIMS7 (resources, no response)

TYPEIMS7 warning messages *** LCODE 35X NOT OUTPUT for ENQFLG=0C

VMACIMS and FLAG2=40x or 60x are now output to IMS35O dataset.

Jun 23, 2001 The warnings had no impact on the IMS0708 dataset that is

create by the TYPEIMS7 program, since only 07 and 08 log

records are used in IMS0708.

In addition, the MXG logic to set NMSGPROC=1 for 08-only

matches caused the total NMSGPROC in IMS0708 to be more

that the true NMSGPROC in the 07 reocrds, so NMSGPROC=0

is now set for the 08-only matches in TYPEIMS7.

And IMSQBLDN is now a positive number; it was initialized

to -34, but that RETAIN statement was corrected.

Thanks to Rita Bertolo, Canadian Pacific Railway, CANADA.
Change 19.116 New %MACROS allow you to read many PDB libraries for one

VGETDDS MXG dataset (SET WEEK1.JOBS WEEK2.JOBS WEEK3.JOBS), and

VMXGSET only those DDnames that are found will be used! You can

VMXGINIT control, by the DDNAMES (or LIBNAMES) in your JCL, which

Jun 22, 2001 PDB libraries will be read, but you do have to change the

SET statement in your SAS program! Two %MACROS are used:

-%VGETDDS - "Get" ddnames:

%VGETDDS(DDNAMES=WEEK: PDB: ALLWEEK);

You tell VGETDDS the DDnamePrefixes and specific DDnames

that you want to use. That example will find all DDnames

starting with WEEKn, PDBn, and the DDnames MON TUE WED

THU FRI SAT SUN that are SAS data libraries, and only

those DDnames will then be read by the second macro.
-%VMXGSET - Use in place of your SET statement:

DATA COMBINE.JOBS;

%VMXGSET(DATASET=JOBS,DEFER=YES);

RUN;

You tell VMXGSET what MXG dataset (aka table) you want to

read, and if any of your datasets are on tape media, you

can specify DEFER=YES (SAS V8+ only) and the OPEN=DEFER

option will be on the SET statement that we construct,

causing each individual dataset in the SET statement to

be opened, read, and closed, left to right, so you use

UNIT=AFF in your JCL, and need only one tape drive to

read all of your datasets!

The only caution with DEFER=YES is that it cannot be

used if there is a BY statement with %VMXGSET, because

a BY statement opens all datasets in a SET statement.
So to read five PDB libraries, PDB1-PDB5, you would have
// EXEC MXGSASV9

//PDB1 DD DSN=YOUR.PDB(0),DISP=SHR

//PDB2 DD DSN=YOUR.PDB(-1),DISP=SHR

//PDB3 DD DSN=YOUR.PDB(-2),DISP=SHR

//PDB4 DD DSN=YOUR.PDB(-3),DISP=SHR

//PDB5 DD DSN=YOUR.PDB(-4),DISP=SHR

//COMBINE DD DSN=YOUR.OUTPUT.PDB,DISP=(,CATLG)....

//SYSIN DD *

%VGETDDS(DDNAMES=PDB:);

DATA COMBINE.JOBS;

%VMXGSET(DATASET=JOBS);

... rest of your subsetting logic ...

More details.

You would execute %VGETDDS(DDNAMES=....); once to build

the DDnames, and then execute a DATA step that executes

%VMXGSET(DATASET=....) for each data set to be read.

(While not likely, you can also execute %VGETDDS multiple

times).
Special values exist for %VGETDDS's DDNAMES= argument:

CCCCCCCC - 1-8 char, specific DDname (all characters)

CCCCCCnn - 1-7 char, final 1-2 numeric - scan CCCCCC1,

CCCCCC2 .. until an CCCCCCn+1 is not found

use CCCCCC1 to CCCCCCn DDnames

ALLWEEK - SUN MON TUE WED THU FRI SAT DDnames
Note: If there is more than one tape dataset, and you

use OPEN=DEFER and UNIT=AFF so that only one tape

drive is needed, there will be two mounts of each

tape dataset's first volume: one to recognize it

is a PDB, and, because UNIT=AFF will dismount the

first to recognize the second, there will be the

re-mount of the first dataset when the read

begins. Of course if your tapes are in a VTS,

there is no actual second physical mount, but you

will see both of the mounts on the SYSLOG.

Currently, an arbitrary limit of 99 DDs can be used in

the ultimate SET statement that results.

Even though references are mostly to MVS DDnames, the

new macros work also work on ASCII SAS platforms.

-VMXGINIT was updated to GLOBAL the VGETDDS name.
-HOWEVER: PRIOR TO 2005, there was a serious problem

in that some LIBNAMEs could have been missed by VGETDSN,

but only if the Data Library were controlled by HSM, and

only if you were missing an IBM Patch. That should not

now be a problem, but you can read the full details in

the text of (old) MXG Change 23.244. (Updated 2009).

Thanks to Chuck Hopf, MBNA, USA.

Thanks to Rick Langston, SAS Institute, USA.

Thanks to Jim Horne, Lowe's Companies, USA
Change 19.115 You can disregard these confusing SAS NOTES:

None NOTE: DATA STEP VIEW SAVED ON FILE WORK.MXGSUM1.

Jun 21, 2001 THE ORIGINAL SOURCE STATEMENTS CANNOT BE RETRIEVED FROM

A STORED DATA STEP VIEW NOR WILL A STORED DATA STEP VIEW