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

SUMBY= list, but using the real variable name is better!

-VMXGSUM arguments TEMP01=,TEMP02=, and TEMP03= will still

be used to send intermediate WORK files to those DDnames

(for performance or space considerations), when they are

coded on the VMXGSUM invocation, but now you can redirect

the intermediate files externally, by %LETting the new

MXGTMP1, MXGTMP2, or MXGTMP3 global macro variables

to the desired DDname, before the include of the program

that invokes VMXGSUM. For example,

%LET MXGTMP1 = TEMPDD1 ;

%LET MXGTMP2 = TEMPDD2 ;

%INCLUDE SOURCLIB(ASUMDB2A);
Change 16.145 Support for APAR OW31281 adds HSM statistics for RECALL

FORMATS RECOVER, and additional fields to the DSR and FSR SMF

VMACHSM records. New DSR variables DSRNRCL DSRNRCV in dataset

Jul 7, 1998 HSMDSRST measure the number of times when RECALL/RECOVER

was satisfied by a tape that was already mounted. New

FSR variables FSRDEVCL FSRDEVTY FSRDSMNT FSROFF83

FSRRECRE FSRSCNAM in dataset HSMFSRBO provide device

class and device type, the number of tape mounts that

were avoided thru recall/recover, flags, number of tries

to recall, and the Storage Class Name.

The APAR also provided new values 19 and 20 for the

FSRTYPE field that were added to format MGHSMFU, but

values 15-18 have been skipped or are undocumented!

Thanks to Dave Cogar, U.S. Department of Transportation, USA.

Change 16.144 Significant enhancement uses Change 16.134 architecture

BLDNTPDB to build daily/weekly/monthly/week-to-date/month-to-date

Jul 7, 1998 PDBs for NTSMF data, with some simple reports implemented

and more to come. This member is documented in ADOCNTSM.

Change 16.143 One GRAPH of Tape Mounts had seconds instead of hours on

GRAFTMNT the x-axis, and GRAFTMNT did not accept SASGRAPH=YES if

Jul 7, 1998 specified (but using the default SASGRAPH=, did work).

Thanks to Billy Westland, Litton Enterprise Solutions, Inc.

Change 16.142 This utility, used only in JCLTEST6 to get 10 SMF records

VMXGGETM of each type and subtype, is now expanded to expect 512

Jul 7, 1998 subtypes, as DB2 type 102 records exceeded 255 subtypes.

Thanks to Chuck Hopf, MBNA, USA.

Change 16.141 The DURATM calculation in ASUMCACH was revised. Because

ASUMCACH the TYPE74 data can contain data from many systems, the

Jul 7, 1998 DURATM could have been inflated by the number of systems

that shared that volume with activity. Since you must

chose a single source system for the TYPE74CA dataset,

(in EXTY74CA), its DURATM is now used in ASUMCACH.

Thanks to Chuck Hopf, MBNA, USA.
Change 16.140 The weekly interleave of ASUMDB2B in WEEKBLDT failed with

WEEKBLDT wrong sort order. The correct sort variables are:

Jul 6, 1998 SYSTEM QWHSSSID QWHCPLAN QWHCAID QWHSLOCN

QWHCCV QLACLOCN QWHCCN QBACPID QWACBSC

SHIFT

Thanks to Scott Snyder, First Bank, USA.

Change 16.139 Invalid CMF User "240" SMF record has 20 Cache Statistics

VMACCMF segments (CMF27CCN=20) but only 19 Cache Device segments

VMACCMF (CMF27DIN=19); the device address in the 1st CCN segment

Jul 6, 1998 does not have a corresponding DIN segment. This is a CMF

record error that caused INPUT STATEMENT EXCEEDED error,

but MXG now compares device addresses in the two segments

instead of assuming they matched as documented, and MXG

circumvents their error. Boole fixes BMP6301 (4.3.0) and

BPM6303 (5.2.2) exist to correct the record, now that I

have circumvented their error!

Thanks to Ken Williams, Sun Life of Canada, ENGLAND.
Change 16.138 Landmark CICS Version 2 native records protection added.

VMACTMO2 A message is now printed if you try to read compressed

Jul 1, 1998 records without having installed the EXITMON6 decompress

exit.

Thanks to Glenn Delvecchio, Stelco Inc, CANADA.
Change 16.137 NOTE: INVALID ARGUMENT TO FUNCTION SQRT apparently occurs

ASUMCICS due to very small differences (9th digit) in calculating

TRND72 the Standard Deviation as SQRT(A-B) when N=1. A=B to 14

Jun 29, 1998 14 places with PROC PRINT, but A-B is different in 9th

place! Since the real STD is zero in these cases, the

logic now tests A-B for positive before SQRT() and sets

STD=0 if A-B is not GT zero.

Thanks to Jon Whitcomb, Great Lakes Higher Education Council, USA.

Change 16.136 DFSMS 1.4.0 added (compatibly) new variables WFSCPUTM and

VMACHSM WFSRACCT in HSMWWFSR dataset, so you can measure CPU time

Jun 26, 1998 used by HSM for ABARS ABACKUP/RECOVERY processing. If

you can figure out how to populate that WFSRACCT account

field, it might be useful too!

Thanks to Michael E. Friske, Fidelity Investments, USA.

Change 16.135 VTS variables SMF94VBA and SMF94VLA were mis-documented

VMAC94 by IBM. They are not the "Midnight" values of data bytes

Jun 26, 1998 and virtual volumes, but are the "End of Interval" values

so their label was corrected.

Thanks to Joseph G. Ogurchak, Westfield Companies, USA.
Change 16.134 -The new &MACKEEP and IMACKEEP MXG architecture is here!
BUILDPDB "MACKEEP" Architecture of MXG-built SAS "Datasets"

DIFFXXXX

DOCMXG Everything about the creation of an MXG dataset is now

fully externalized, and all dataset tailoring can now be

IMACXXXX EDITed into a single member, IMACKEEP (instead of using

TYPEXXXX each product's IMAC), or dataset tailoring can be done

TYPSXXXX "instream" using %LET MACKEEP= syntax, with no EDIT!

VMACXXXX

VMACXXXX All MXG datasets can be referenced using the new syntax

VMXGDEL &Pdddddd.DATASET and you can use %LET Pdddddd= MYDD;

VMXGINIT to change the destination to which a dataset is written

VMXGINV or the library from which it is to be read from.

VMXGLBIN

VMXGSUM Member DOCMXG contains the following description, and

Jul 4, 1998 additional discussion of the new architecture, and will

Sep 3, 1998 be the primary documentation of MXG syntax and design.

"MACKEEP" Architecture of MXG-built SAS "Datasets"
Fifth Draft Sep 3, 1998
"Product Suffix"

The xxxx suffix of the TYPExxxx/VMACxxxx/IMACxxxx/

ASUMxxxx/GRAFxxxx/ANALxxxx members for a "product":

Product xxxx Datasets

SMF Type 0 0 TYPE0

SMF Type 30 30 TYPE30_1,TYPE30_4,..

SMF Type 74 74 TYPE74,TYPE74CA,TYPE74CF,..

SMF 110 SMF 110 CICSTRAN,CICINTRV,CICFCR,..

NTSMF NTSM PROCESS,NTINTRV,PROCESOR,..

An MXG "Product" is defined by its VMACxxxx member,

which defines all of the macros for product xxxx, and

defines all datasets MXG builds from that product.

You run %INCLUDE SOURCLIB(TYPExxxx); syntax to read a

product's records and create all MXG SAS datasets in

the //WORK file. You run %INCLUDE SOURCLIB(TYPSxxxx);

to read the records and create SORTED output, normally

into the //PDB file. TYPSxxxx instead of TYPExxxx is

now the recommended program to use for a product.

IMACxxxx product members are now used only to override

the macros that you want to change. Definitions of

the Product Macros (_IDxxxx, _Nxxxx, and _Sxxxx) and

Dataset Macros (_Ldddddd, _W, _K, _E, _B, _Sdddddd)

were moved from the IMACxxxx into the VMACxxxx member.

Product IMACxxxx members are now only comments listing

the product's xxxx and its dddddd and DATASET names.
Even better and also new, all tailoring changes can

now be EDITed into only one place, member IMACKEEP,

instead of having to EDIT a separate IMACxxxx member

for each product. (Your old IMACxxxx's will still be

honored, but IMACKEEP is called after the IMACxxxx, so

existing IMACxxxx changes can still be overridden.

And still even better and also new, especially if you

don't like having to EDIT and SAVE a member to tailor,

you can now do it "on the fly", in your SYSIN stream,

by %LETting the new "&MACKEEP" macro to change any of

the dataset macros, including the Exit Member code to

select which observations are written!

And best of all, if you only want to change the DDNAME

to which a sorted DATASET is written, there is a new

&Pdddddd macro for each DATASET that you can %LET in

your SYSIN with this syntax:

%LET PTY74CA=TAPE74CA ;

%INCLUDE SOURCLIB(BUILDPDB);

to create your normal PDB, except that the TYPE74CA

dataset would be written to TAPE74CA.TYPE74CA instead

of being written to the default of PDB.TYPE74CA.
"DATASET"

SAS "Table Name" or SAS DATASET NAME, 8-characters,

are defined in the dataset's _L macro. Examples are

TYPE0, TYPE30_1, TYPE74CA, CICSTRAN, PROCESS, NTINTRV.

"Dataset Macros"

_L, _W, _K, _E, _B, _S, one set for each DATASET, are

defined in the VMACxxxx member for the product:

_L - "&P OUTPUT/SORT Destination LIBREF" macro

_W - "Work Library Dataset Name" macro

_K - "Keep/DROP Dataset Tailoring" macro

_E - "Dataset Exit" macro

_B - "BY List of Variables" macro

_S - "Dataset PROC Sort" macro

They can be overridden in &MACKEEP/IMACKEEP/IMACxxxx.

"Dataset Suffix"

The six character "dddddd" dataset suffix is a unique

string for each dataset. It is used in the old-style

_Ldddddd/_Wdddddd/_Kdddddd/_Edddddd/_Bdddddd/_Sdddddd

"dataset macros", is the suffix of the EXdddddd exit

member name, and is the suffix of the new &Pdddddd.

The dddddd values are encoded. For datasets starting

with TYPE (TYPE0, TYPE70PR, TYPE74CA) the dddddd is

TYaaaa (TY0, TY70PR, TY74CA). Other datasets encode

dddddd= yyzzzz/yyyzzz/yyyyzzz value with y= product

and z= dataset. CICS 110's have dddddd=CICTRN/CICINT

for CICSTRAN/CICINTRV datasets where yyy=CIC.

Similarly, NTSMF encodes dddddd as NTzzzz, so NTBROW

and NTPROR are dddddd for BROWSER and PROCESOR.

The dddddd value of each MXG dataset is defined in the

VMACxxxx members, but the IMACxxxx for the product is

the documentation of the dddddd and DATASET values.
"&PDB/&P macros"

The seven-character Pdddddd macro variable name, one

for each DATASET, defines the DDNAME/LIBREF to which

that sorted DATASET will be written. First, MXG

writes each DATASET to the //WORK file, using the

old-style substitution macro _Wdddddd:

MACRO _Wdddddd DATASET %

MXG then SORTs from the _Wdddddd to the _Ldddddd macro

that contains the new-style &Pdddddd macro variable:

MACRO _Ldddddd &Pdddddd..DATASET %

The default Pdddddd value, usually "PDB", is set by

VMXGINIT at MXG initialization, so now you can use a

%LET statement in you program to change the output

destination DDname for a dataset:

//SYSIN DD *

%LET PTY74CA = MYDD74CA ;

%INCLUDE SOURCLIB(TYPE74);

and you no longer have to EDIT into an IMAC member.

Most sites should never need to change much else!

(Note that while references use &Pdddddd syntax, the

ampersand is not used in the %LET statement.)
"Product Macros"

_IDxxxx, _Nxxxx, _Sxxxx, _VARxxxx, _CDExxxx members

are defined in the VMACxxxx member for the product:

_IDxxxx - "Record ID macro for user SMF records"

_Nxxxx - "_NULL_ all datasets in this product"

_Sxxxx - "SORT all datasets in this product"

_VARxxxx - "Variables/Datasets structure macro"

_CDExxxx - "Code to Decode structure macro"

The _VARxxxx and _CDExxxx macros should NEVER be

changed, as they are the heart and soul of MXG code;

all tailoring macros exist precisely so that you can

change MXG without changing the _VAR or _CDE macros!

The _IDxxxx macro sets the record number for user SMF

records, and must be changed in IMACxxxx/IMACKEEP or

with MACKEEP= logic to read product xxxx records.
The new _Sxxxx and _Nxxxx macros make tailoring easy.

The _S Sorts all datasets, the _N Nulls all datasets:

MACRO _S74 MACRO _N74

_STY74 MACRO _WTY74 _NULL_ %%

_STY74CA MACRO _WTY74CA _NULL_ %%

... ...

% %

If you %INCLUDE SOURCLIB(TYPS74) or run BUILDPDB, all

eleven TYPE74zz datasets are created and sorted. Now,

if you only want the TYPE74 dataset, and you want to

write it to the "TY74TAPE" DD name (perhaps, a tape?):

//SYSIN DD *

%LET PTY74=TY74TAPE;

%LET MACKEEP=

_N74

MACRO _WTY74 TYPE74 %

MACRO _S74 _STY74 %

;

%INCLUDE SOURCLIB(TYPS74);

and only dataset TY74TAPE.TYPE74 would be created, in

the WORK file, then sorted into the "PDB" default, and

then WORK.TYPE74 is automatically deleted.
The %LET PTY74 sets the Pdddddd macro variable value

with the output LIBREF/DDNAME of the desired dataset.

In the %LET MACKEEP=, the _N74 invocation changes the

default _Wdddddd dataset names to _NULL_, and then the

MACRO _WTY74 override "un-_NULL_'s" that dataset so

TYPE74 will be created, and the MACRO _S74 definition

contains only the _Sdddddd sort macro for the TYPE74

dataset that you want created! It's that simple.

"Old-Style Macro"

All MXG Old-Style macros start with an underscore.

The definition MACRO _oldstyl whatever %

will have "whatever" substituted when SAS sees the

string "_oldstyl" at compile time. "Whatever" can

contain characters and symbols to be used as parts of

SAS statements, or can be entire blocks of SAS code.

If "whatever" contains a percent-sign it must be a

double-percent in the MACRO definition. As SAS uses

the last MACRO definition encountered, any old-style

macro can be redefined with &MACKEEP, or in IMACKEEP.
"Macro Variable"

SAS Macro Variables are also used to substitute stored

text, but with different syntax. They start with &

when they are referenced, but that ampersand is not

used when defined with %LET or CALL SYMPUT statements:

%LET PDByyyy = value ;

or inside a DATA step, you can use SYMPUT:

CALL SYMPUT('Pdddddd','value');

For MXG's &Pdddddd macros, "value" is a LIBREF/DDNAME

for the output DATASET, which can always be %LET.

But for &MACKEEP macro, "value" can be anything from

the (most likely) redefinition of an old-style macro:

%LET MACKEEP = MACRO _IDHSMDS = 240 % ;

to the (less likely) lines of SAS statements to create

new variables, select observations to be output, etc.,

(as when you tailor a "Dataset Exit" _Edddddd macro).

If the text does not contain a semicolon, the simple

syntax of %LET MACKEEP = value ; is used,

even when there are % or %% in the value text.
But if MACKEEP= value contains any semicolons, then

syntax of %LET MACKEEP= %QUOTE( value ) ;

must be used:

And, if the value contains single-percent signs,

they must be doubled inside the %QUOTE function.

And, in a new quirk of the SAS macro language,

if the text contains double-percent-signs (as in

%%INCLUDE in the _Edddddd Dataset Exit macros),

those double-precents must be triple-percents!!
CICSTRAN Example.

You want to read type 110 CICS records but only create

CICSTRAN observations for a specific APPLID, and you

want to write them (unsorted) to the CICSTRAN DDNAME.

The product IMACxxxx member documents which dddddd to

use for which dataset, but in the expected IMAC110

member, it admits that the IMACxxxx for SMF type 110

is the inconsistently-named IMACCICS member, and there

you find out that the dddddd value for the CICSTRAN

dataset is "CICTRN". Then you can use:

// EXEC MXGSAS

//SMF DD DSN=smf.data,DISP=SHR

//CICSTRAN DD DSN=output,DISP=(,CATLG)

//SYSIN DD *

%LET MACKEEP=

%QUOTE(

_N110

MACRO _WCICTRN CICSTRAN.CICSTRAN %

MACRO _ECICTRN

IF APPLID='CICP' AND TRANNAME='XYZ1' THEN DO;

%%%INCLUDE SOURCLIB(EXCICTRN)

END;

%

)

;

%INCLUDE SOURCLIB(TYPE110);
The _N110 invocation nulls out all type 110 datasets,

so we then re-instate MACRO _WCICTRN so that it's data

is created, and by prefixing the dataset name CICSTRAN

with "CICSTRAN.", that dataset will be written to the

//CICSTRAN DD instead of //WORK, so its "full" name is

CICSTRAN.CICSTRAN.

The %QUOTE ( ) syntax is used to add a DO group around

the %%%INCLUDE, and any number of SAS statements could

be used inside the _ECICTRN macro in this better way:

Note that percent-signs were increased by one due

to the QUOTE ( ). Also, don't use "DELETE" logic

in your "Dataset Exit" logic, because records can

contain multiple transaction segments, and the

DELETE would prevent MXG from looking at the rest

of the transactions in the record. Instead, always

cause an OUTPUT of observations you want and skip

past the ones you don't want to output.
The preceding example was revised April, 1999.
The following text describes additional changes that were

made in this redesign, and that is followed by discussion

of possible compatibility issues with past tailoring.
-VMXGINV will "Inventory" a DDNAME with PROC CONTENTS and

will extract the "dddddd" dataset suffix from the LABEL

of every dataset in that library, so we can know which

datasets exist, with their "dddddd" values, so we can

auto-drive additional processing.

-VMXGLBIN will initialize a SAS data library to match the

contents of an existing library, but all datasets in the

new library will have zero observations. This is used in

the first-time logic in WEEKLY/MONTHLY processing.

-VMXGDEL will delete a _W dataset by its dddddd token if

the library pointed to by the _Wdddddd value is NOT the

same as the _Ldddddd (output) library and dataset. This

is used after the PROC SORT to delete its input, but not

when you sort the output back into the input dataset!

-BUILDPDB/BUILDPD3 phases are externalized with new macros

_DIFFDB2, _INTRMF, _INTCICS, and _BLD005 that can be set

to blank to bypass processing. The JOBS/STEPS/PRINT

logic was externalized to BUILD005/BUIL3005, and all of

the _PDB macros are defined in BUILD005/BUILD3005 rather

than in the BUILDPDB/BUILDPD3/BUILD001 members.

-MULTIDD logic in old BUIL3005 was corrected (BUILDPD3 had

been correct all along, and now BUILDPD3 calls BUIL3005).

-New formats $MGDDDDD and $MGDDDSN map dddddd to dataset

and dataset to dddddd values.

-New macro variables MXGTMP1 thru MXGTMP5 are GLOBALed,

defined in VMXGINIT, and default to WORK. Their names

&MXGTMP1, &MXGTMP2, etc., are the "Standard" macro names

for temporary work space that you can set globally. You

used to have to code TEMP01= on the %VMXGSUM invocation,

and VMXGSUM still honors TEMP01 if coded, but now you can

use %LET MXGTMP1 = MYTEMPDD ; and VMXGSUM will use that

destination instead of the //WORK default.

-LIMITATION: If you use %LET MACKEEP= logic to redefine

old-style macros, you can't use %LET MACKEEP= again in

the same SAS execution, unless you reset the old-style

macro to itself before the second %LET MACKEEP= logic:

%LET MACKEEP= MACRO _WTY0 FIRSTDSN % ;

%INCLUDE SOURCLIB(TYPE0);RUN;

MACRO _WTY0 _WTY0 %

%LET MACKEEP= MACRO _WTY0 SECNDDSN % :

%INCLUDE SOURCLIB(TYPE0);RUN;

If you did not have that MACRO _WTY0 _WTY0 % reset, the

second %LET would have used "FIRSTDSN" for the _WTY0 and

you would have %LET MACKEEP= MACRO FIRSTDSN SECNDDSN %;

and the second MACKEEP would not have changed _WTY0!
COMPATIBILITY NOTES:
-If you used a %INC SOURCLIB(TYPExxxx); program and you

also used the IMACxxxx to change the _Ldddddd macro, the

old version wrote to your modified _L destination, while

the new version writes to the _W (work) destination.

Circumvention/workaround/the way to do it now include:

a. Use: %LET MACKEEP= MACRO _Wdddddd _Ldddddd % ;

to use your _L definition from your IMAC for the _W

destination of the unsorted dataset.

b. Change your IMACxxxx to override _W instead of _L.

c. Use new TYPSxxxx instead of TYPExxxx, to write to _W

first and then SORT to your _L destination. Since the

_S SORTS eliminate duplicate records, it is now MXG's

recommendation to use TYPSxxxx instead of TYPExxxx.

d. See notes in member INSTALL, with examples of errors.

Status in MXG 16.04:

-Except for five products, (CRAY,FRYE,RSxx,SNIF,VMXP), all

VMACxxxx members and TYPExxxx members have been revised.

-Some _Sdddddd "sort" macros still have a DATA step rather

then the PROC SORT because I don't know the unique set of

variables that will eliminate duplicates for that data.

-IMACs now contain only comments that define the dddddd

and DATASET names.

-No Beta site has had any real problems with this change!
Change 16.133 -The summarization of NETWSEGM into NTINTRV was wrong if

NTINTRV there was more than one network segment instance. Now

VMACNTSM the rate variables are summed and the maximum percent of

Jun 24, 1998 any segment is added to NTINTRV dataset as NETSxxxx.

-The number of Physical Disks is counted and added into

NTINTRV as variable NRPDISK.

-The instance field NETWSEGM was missing in the _BNTNETS

definition in VMACNTSM.

Change 16.132 Revised utility that reconstructs VB or VBS data on MVS

UDEBLOCK that was uploaded from a PC file. This utility creates

Jun 24, 1998 one record per block, so if you intend to re-read the

output file multiple times, it would be worthwhile to

reblock the output file by copying with IEBGENER or SAS.

The earlier version did not always work correctly.

Change 16.131 On UNIX, VMXGSUM fails because of UNIX forward slashes.

VMXGSUM The failure produces these messages:

Jun 22, 1998 ERROR: A character operand was found in the %EVAL....

ERROR: The macro VMXGSUM will stop executing.

The failing statement is part of MXG housekeeping:

%IF &SASSWORK NE WORK %THEN ....

where &SASSWORK is a macro variable filled in by SAS

from SASHELP.VOPTION table that under MVS contains the

value of the WORK= option, which is a DDNAME or libref.

If your WORK= option is 'WORK' we do housekeeping and

delete work files, but if your WORK= is anything else,

then we don't delete anything in your library.

This statement fails under UNIX, because under UNIX, the

&SASSWORK value does not contain a libref, but instead

has a full UNIX directory pathname, with forward slashes

that here are interpreted by the SAS %Macro Compiler as

divide-by signs, which is invalid in this context, so

VMXGSUM fails to compile under UNIX!

It might be argued that the error is in the SAS macro

compiler, but the real error was in not knowing that what