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

RUN UNDER A DIFFERENT RELEASE OF THE SAS SYSTEM OR UNDER

A DIFFERENT OPERATING SYSTEM.

PLEASE BE SURE TO SAVE THE SOURCE STATEMENTS FOR THIS

DATA STEP VIEW.

These notes are because MXG now uses VIEWs where possible

to eliminate I/Os, but the "source" is already in your

MXG Source library, so there is nothing to save or do.

Thanks to Freddie Arie, Texas Utilities, USA.

Change 19.114 RMF type 74 subtype 5 (Cache Subsystem) "broken" records

VMAC74 cause the same "INPUT STATEMENT EXCEEDED" error that was

Jun 21, 2001 seen with subtype 4. See the extensive discussion in the

text of Change 17.398. IBM RMF Development has agreed to

create only 'self-contained' records (and they may well

have done so, as this particular RMF record was written

by SP5.1), but this change replaced the statement:

IF SMF745XN GT 0 THEN DO;

with this replacement statement:

IF NDVCNT LE SMF745XN THEN DO;

so that MXG will only look for Extension sections when

they exist in the first "broken" record.

In this instance, the first record had 254 Device Data

Sections, but only 11 Device Data Extension Sections

(i.e., for the first 11 devices). A second SMF record

contains the remaining 243 Extension Sections, but there

is no Device Section with which to match them, so they

are never input. This change prevents MXG from INPUTing

a non-existent extension section, but that will cause

all of these variables to have missing values in TYPE74CA

when a broken record is processed:

R745XDVN /*DEVICE*NUMBER*- SAME AS DEVN */

RSV /*R745XRSV*LOWER*IO*MILLISEC*/

DCTC /*XCTC*DEV CACHE TRKS CONFIGED*/

DCTR /*XCTR*DEV CACHE TRKS REMOVED */

DVRD /*XVRD*DEV READS*BY CU*/

DVRH /*XVRH*DEV READ HITS*BY CU*/

DVWR /*XVWR*DEV WRITES*BY CU*/

DVWH /*XVWH*DEV WRITE HITS*BY CU*/

TSRR /*XSRR*TRKS*STAGED*FOR RAID RE*/

SFRD /*XFRD*TRKS*READ*FROM SIDEFILE*/

CWCC /*XWCC*CONCUR*COPY*CONTAM*WRIT*/

PPRC /*XPRC*PPRC*WRITE*COUNT*/

The MXG change now also protects the LN/RN/1N/VN INPUTs

in case those segments are in a second record.

Thanks to MXG/ITSV Technician, Promise Co. LTD, JAPAN.

Change 19.113 Several examples were revised; some caused errors and the

NEWUSER others were updated to be clearer.

Jun 20, 2001

Thanks to Lary Nova, COMSI, USA.

Change 19.112 PDB.CICINTRV dataset can contain negative minimum values

VMXGCICI or missing values, when there are no INT (Interval) CICS

Jun 20, 2001 statistics records, i.e., when there are only 'EOD' data.

First, if there are no 'INT' records, and you request the

default INTERVAL=HALF-HOUR for PDB.CICINTRV, you will get

unexpected results - I can't create intervals where there

are not, so you must request INTERVAL=EOD in CICINTRV.

But even if you specified INTERVAL=EOD, there was still

an error in the logic in VMXGCICI, because in each of the

processing code for these datasets ('suffixes'):

DL1 DL3 DBU PGG IRC DMR FEP FEC FET JCR LDR LS1 LS3

SDR SMD SMT TC1 TDR XMC USG XMG XMR

a statement IF FIRST.APPLID THEN DELETE; existed that

could cause those datasets to be not included in the

PDB.CICINTRV (so their variables would be missing).

This change removed that code from VMXGCICI.

Additional internal documentation note:

These yyy's did not have the DELETE statement:

TC TSR DMG VT AUT LDG DTB TCR DQR DQG TSQ

DS ST FCR M TDG SDG SMS AUS CO1 CO3 CON,

These yyy's are not currently used in VMXGCICI:

CSF6/7/8/9, D2G,D2R,LGR,LSG,NCS4,NCS4,NQG,

SOR,XQS1/2/3.

Thanks to Sally Weber, Washington Mutual, USA.

Change 19.111 Support for DFSMS/RMM data in MXG is confusing, because

VMACEDGR IBM has similar data in different formats that can be

VMACEDGS written to SMF or dumped with IBM's EDGHSKP utility in

Jun 20, 2001 two different formats. This is documentation only.

1. MXG's "EDGSxxxx" processing:
RMM can create two SMF records with different SMF IDs,

so MXG has two separate macros to define the SMF record

numbers your installation told rmm to use:

_IDEDGSU for the "Security" record, one subtype,

populates dataset EDGSSECU if found,

_IDEDGSA for the "Audit" record, many "subtypes":

EDGATYPE='C' populates EDGSAREC, only from

SMF records, but the "Audit" record also has

all of the rmm control records subtypes with

EDGATYPE=D/K/O/P/E/F/U/R/S that populate the

EDGSVREC,DREC,KREC,OREC,PREC,RREC,SREC,OVOL

EDGSPVOL datasets.

MXG's members TYPEEDGS and TYPSEDGS will read the infile

"SMF" and create all of the EDGSxxxx datasets.

But the IBM utility EDGSKIP can create a Control Backup

flat file from the rmm Control file (EDGSKIP with BACKUP

option), and that flat file is in almost-SMF-format that

contains the same Audit subtypes, so the same EDGSxxxx

datasets can be crated from either SMF records or the

Control Backup file. Because of slightly different input

format, two different members are needed in MXG, but they

both create all of the EDGS datasets, which will be

populated with observations when those subtypes are read
TYPEEDGS - Reads Infile "SMF" to create "EDGS" datasets

TYPEEDGB - Reads Infile "LOGSMF" from Backup option to

create "EDGS" datasets.

2. MXG's "EDGRxxxx" processing:

But you can also run EDGHSKP to Extract instead of Backup

(EDGSKKIP with RPTEXT), and that creates a flat file that

is physically different in record layout, but it contains

almost all of the same record subtypes. Unfortunately, I

did not recognize the similarities, so MXG dataset names

are EDGRxxxx, and different variable names are used:

TYPEEDGR - Reads Infile "EDGHSKP" from Extract option to

create "EDGR" datasets.

This table should identify which MXG datasets are similar

from these multiple possibilities:

Type "EDGS" process "EDGR" process

- EDGSSECU SMF - Security does not exist

C EDGSAREC SMF - Activity does not exist

D EDGSDREC Data Set EDGRDEXT

K EDGSKREC Vital EDGRKEXT

O EDGSOREC Owner EDGROEXT

O EDGSOVOL ", per volume does not exist

P EDGSPREC Sftw Product EDGRPEXT

P EDGSPVOL ", per volume does not exist

E/F/U EDGSRREC LIB Shelf Location EDGRREXT

R/S EDGSSREC Storage Loc Shelf EDGRSEXT

V EDGSVREC Volume EDGRVEXT

Thanks to Dale Haug, Philip Morris, USA.
Change 19.110 New CICSTRAN variables BARSPACT and BATIAECT were wrongly

VMAC110 spelled BARACTCT and BADFTECT, but are now corrected to

Jun 19, 2001 agree with the IBM field names.

Thanks to Gary L. Keers, Indiana Power & Light, USA.

Change 19.109 ACCOUNTn variables in TYPE33 APPC SMF records are blank

VMAC33 if the TP profiles specify TAILOR_ACCOUNT(YES) and the

Jun 19, 2001 RACF WORKATR account code is not populated. Specifying

TAILOR_ACCOUNT(NO) corrected that problem, but caused MXG

to set READTIME to a missing value because these lines:

JOB=RACFUSER;

READTIME=REQDTIME;

were executed when MXG found both a TP usage section and

an accounting section in the type 33 SMF record, i.e.,

only when TAILOR_ACCOUNT(NO) is specified. When YES is

specified, there is no accounting section in the SMF

record. Those lines were inserted only to suppress a SAS

"UNINITIALIZED VARIABLE" note, back when there was no JOB

name nor READTIME in the type 33 record, so that the MXG

IMACACCT member could be used to decode the ACCOUNTs, but

as both JOB and READTIME are now input in the VMAC33

member, that protection is unneeded, and its unintended

consequence, this error, is eliminated by deleting them.

Thanks to Walter Medenbach, IBM Global Services, AUSTRALIA.
Change 19.108 MXG output only one observation per SMF 108 subtype 2/6

VMAC108 record, because multiple sections were not expected, but

Jun 13, 2001 as they are now known to exist, many observations that

Jul 9, 2001 were not output are now created:

Subtype 2: 513 records, 10487 observations (now)

Subtype 6: 527 records, 71592 observations (now)

Additionally, variables DOMRVN and DOMPVN are now kept in

each subtype dataset (to identify version changes).

Jul 9: SM180UDO re-spelled as SM108UDO.

OBSERVATION COUNT CHANGE: TYPE1082 more obs.

OBSERVATION COUNT CHANGE: TYPE1086 more obs.

Thanks to Wolfgang Vierling, Allianz, GERMANY.

Change 19.107 New exit member EXTPFINT for the TPFINTRV dataset is now

EXTPFINT added, so that new variables can be created in TPFINTRV.

VMXGTPFI See comments in the exit member.

Jun 12, 2001

Thanks to Jim Gilbert, Sabre, USA.
Change 19.106 Archaic VMACIMS member had incorrect IMSRECNO because the

VMACIMS statement LOCRECNO=LEN-3; was missing for three IMS 5.1

Jun 11, 2001 code segments for the 35x log record (which is not used

by the TYPEIMS7 program, which is now the only user of

the VMACIMS member, and it doesn't use the 35x records).

Thanks to Siegfried Trantes, IDG Informationsvararbeitung, GERMANY.

Change 19.105 -SU_SEC variable is now kept in 8 bytes, because the new

UTILRMFI larger values can loose some low decimal digits in 4.

VMAC7072 For example, a Z-series 5-way has SU_SEC=10540.1845, but

VMXGRMFI that was truncated in 4 bytes to only SU_SEC=10540.1818,

Jun 11, 2001 so the magnitude of the truncation is small, only .0027.

Jun 21, 2001 -The original implementation of VMXGRMFI/UTILRMFI for WLM

required blanks between the parameters of the WORKnn=

operands of VMXGRMFI, causing confusion and errors. Both

members were revised to now tolerate blanks, but they are

no longer required. The / character still is required as

a delimiter to positionally identify the operand.

-Use of both KEEPxxx and DROPxxx VMXGRMFI arguments is not

supported; now you will get a USER ABEND 1913 if you try.

Thanks to Larry Nova, TransAmerica Commercial Finance, USA.

Change 19.104 -TYPE72GO variables VELOCITY/VELOCIOD/VELOCCPU were

VMAC7072 propagated into subsequent periods in the same SMF record

VMXGRMFI if there was no activity in those subsequent periods.

Jun 11, 2001 Now, all are set to missing if they cannot be calculated.

-Temporary dataset WORK.RMF72DS (built in VMXGRMFI) is now

deleted, as it should have been, for housecleaning.

-Comment references to NORM70=YES were removed, as that

normalization is now automatically performed for all the

variables in R70NRM list. NORM70 was never needed.

Thanks to Shantha Peetham-Baran, Cap Gemini Ernst & Young, ENGLAND.

Change 19.103A The default DDname of "PDB" in BUILDPDB can be changed by

VMXGINIT re-invocation of the %VMXGINIT macro in your //SYSIN.

Jun 11, 2001 If you want to write directly to the "MON","TUE",etc.,

'day-of-week' dataset and not have a "PDB" ddname, you

can use a DATA step to create the name of "Day-of-Week"

in a macro variable &DAY, and then use that macro as the

default value instead of "PDB":

DATA _NULL_;

DAY=UPCASE(PUT((TODAY()-1),WEEKDATE3.)); /*variable*/

CALL SYMPUT('DAY',DAY); /*macro variable*/

RUN; /*force evaluate*/

%VMXGINIT(DEFAULT=&DAY); /*invoke*/

%INCLUDE SOURCLIB(BUILDPDB.....);

The change made in member VMXGINIT was cosmetic; a flag

for first-time is now used to change the text of the note

printed on the SAS log to "RE-INITIALIZED" (and the new

DEFAULT value is printed) when VMXGINIT is re-executed.

Thanks to Derek Twist, CSC, AUSTRALIA.

Change 19.103 Support for StorageTek VSM NCS 4.0 ("HSC") enhancements

FORMATS for subtypes 13, 14, 18, and 19 add new variables, but

VMACSTC the record changes are INCOMPATIBLE (STCnnTIM is now 4

Jun 11, 2001 bytes, vice 8, in different format), so this MXG change

is required for that version's SMF records. New things:

Dataset Variables Description FORMAT

STCVSM13 STC13RCI RECALL INDICATOR $MGSTCRC.

'01X:MOUNTED WITHOUT A RECALL'

'02X:MOUNTED AFTER A RECALL'

STC13MGT MANAGEMENT CLASS

STCVSM14 STC14MGT MANAGEMENT CLASS

STCVSM18 STC18MT MIGRATE REQUEST TYPE $MGSTCMT.

'01X:AUTO'

'02X:DRAIN'

'03X:DEMAND'

'04X:RECLAIM'

'05X:CONSOLIDATE'

'06X:EXPORT'

STC18MGT MANAGEMENT CLASS

STC18SCL STORAGE CLASS

STCVSM19 STC19RT RECALL REQUEST TYPE $MGSTCRT.

'01X:AUTO'

'02X:DRAIN'

'03X:DEMAND'

'04X:RECLAIM'

'05X:CONSOLIDATE'

'06X:EXPORT'

STC19MGT MANAGEMENT CLASS

STC19SCL STORAGE CLASS

Thanks to Martin Jensen, JyskeBank, DENMARK.

Change 19.102 Variable CPCMODEL ('ZX7' or 'Z77' for example) is added

ASUM70PR to PDB.ASUM70PR and PDB.ASUMCEC datasets to identify what

Jun 10, 2001 is the exact model of the platform. This is important if

a Z-series machine is an 'upgrade' from a G6, as the CPU

Serial Number does not change, even though the physical

hardware does.

Thanks to Chuck Hopf, MBNA, USA.
Change 19.101 Variable PGMRNAME was removed from the KEEP= list for the

BUILD005 TYPE30_4 dataset in the BUILDPDB logic. If a job had no

BUIL3005 Purge record, the always-blank-PGMRNAME-in-TYPE30_4 would

Jun 10, 2001 blank out the PGMRNAME from the TYPE30_1 dataset.

See Change 19.194.

Thanks to Duncan Walker, Experian, ENGLAND.

Change 19.099 Syntax for Goal Mode no longer requires the -99 place

VMXGRMFI holder.

Jun 9, 2001

Thanks to Larry Nova, COMSI, USA.

======Changes thru 19.099 were in MXG 19.02 dated Jun 1, 2001======
Change 19.098 First MXG 19.02 only. Two lines were left from testing:

VMXGRMFI Lines 2398 and 2417: IF SYSTEM='SYSA' THEN

Jun 1, 2001 must be deleted. This error caused PDB.RMFINTRV to have

many missing variables, including NRCPUS and PARTNCPU.

======Changes thru 19.097 were in MXG 19.02 dated May 27, 2001======
Change 19.097 Labels for two variables were confusing and are revised:

VMAC94 SMF94VBR='BYTES*READ*THRU HOST*CHANNEL*FROM VOL'

May 25, 2001 SMF94VBW='BYTES*WRITTEN*THRU HOST*CHANNEL*TO VOL'

Thanks to Simon Everitt, NPI Financial Services, ENGLAND.

Change 19.096 Variables SMF94IN4 and SMF94EX4 were not multiplied by a

VMAC94 1024*1024, but now are (as were IN3 and EX3) to convert a

May 24, 2001 raw megabyte value back into bytes, so the MGBYTES format

will correctly display these bytes-completed variables.

Thanks to David Bixler, Fiserv, USA.
Change 19.095 EMC's InfoMover SMF records INFSTART and INFTIME are now

VMACINMV INPUT as &PIB.4.2; their bad values reported back in MXG

May 24, 2001 Change 17.396 are now corrected to the normal SMF time

format, replacing the MXG circumvention that had &RB4.

and a divide by 150.

Thanks to Bob Bradley, United Airlines, USA.

Change 19.094 Documentation. Variable DB2SRBTM is missing in DB2ACCT,

VMACDB2 beginning with DB2 Version 6.1, and as documented by IBM

May 23, 2001 and as noted in member ADOCDB2. This note added so that

searching changess for DB2SRBTM will expose itself.

But as a result, if you have any reporting code that uses

DB2CPU=DB2TCBTM+DB2SRBTM;

because the SAS assignment statement A=B+C will have A

missing if B or C are missing. Instead, you must replace

the assignment statement with a SUM() statement:

DB2CPU=SUM(DB2TCBTM,DB2SRBTM);

or, you could remove +DB2SRBTM from your equation.
Change 19.093 Support for Release 5.06 (INCOMPATIBLE, in TYPE1082 data

VMAC108 set, because DOMUNAME was expanded from 32 to 36 bytes).

May 23, 2001 And new field DOMPRPID, Process ID, is added to TYPE108

datasets.

Thanks to Wolfgang Vierling, Allianz, GERMANY.
Change 19.092 The PDB.ASUMUOW dataset is enhanced to now keep variable

VMXGUOW USERCHAR (the real transaction name of some transactions

May 23, 2001 can be stored in the USERCHAR field). The first non-blank

May 25, 2001 (character) or non-missing (numeric) value is output. All

CICS "ID" variables are now listed in new MACRO _KUOWIDC

so you can override and add additional "ID" variables.

The current list of "ID" variables from CICSTRAN is:

APPLID USER LUNAME SYSTEM TERMINAL USERCHAR

To add another variable, say CLIPADDR, you would code:

%LET MACKEEP=

%QUOTE(

MACRO _KUOWIDC

APPLID USER LUNAME SYSTEM TERMINAL USERCHAR

CLIPADDR %

);

New macros _KUOWIDD and _KUOWIDDM for DB2 and MQ are now

defined as null, but can be used in future tailoring.
Option LISTALL=YES on the VMXGUOW invocation can be used

to identify which HOLDxxxx, FRSTxxxx, or LASTxxxx

variable is being used to retain/sum the values for which

real variables in the data step that builds ASUMUOW.

If you really want to create observations in PDB.ASUMUOW

you can use this instream logic before your include:

%LET MACKEEP=

%QUOTE(

MACRO _NOOBS % MACRO _YESOBS %

);

%INCLUDE SOURCLIB(ASUMUOW);

Thanks to Alan Lankin, Towers Perrin, USA.
Change 19.091 An incorrect statement in format $MGFDROP was not caught

FORMATS by SAS, and caused no error, but should have. The text

May 23, 2001 '00'X'='00'X:OTHER (FDRABRM)' was corrected to now read

'00'X='00'X:OTHER (FDRABRM)'

Thanks to Joseph J. Faska, Depository Trust, USA.
Change 19.090 Documentation. Comments had the wrong IBM field name for

VMAC74 two variables. Corrected field name in comments are:

May 21, 2001 @45+OFFSMF LENDDSS &PIB.2. /*SMF74DDL*/

@47+OFFSMF NRDDSS &PIB.2. /*SMF74DDN*/

Thanks to Michael Spencer, BMC Software, USA.
Change 19.089 SAS V8.2 "WARNING: OPTION BLKSIZE(2311) SET INTERNALLY

CONFIGV8 IS NOT SUPPORTED IN THIS VERSION" has no impact; SAS data

May 21, 2001 libraries are still created with half-track blocksize and

SAS Institute will eventually eliminate the spurious

message; a SAS Usage Note will be created later. The SAS

defect was precipitated by a BLKSIZE(DASD)=HALF statement

in MXG's CONFIGV8 member, and to circumvent the SAS error

and eliminate the warning, I have replaced the statement

BLKSIZE(DASD)=HALF

with

BLKSIZE(3390)=27648

BLKSIZE(3380)=23040

so as to still set the desired half track block size for

new SAS data libraries on DASD.

You could make the WARNING go away by removing that

BLKSIZE(DASD)=HALF statement from CONFIGV8, but without

those device-specific half-track values being set in your

CONFIGV8 member, you will instead get the SAS System

default value of 6144 that is set their SAS.CNTL(CONFIG)

member in your //CONFIG DD concatenation.

SAS Institute still sets their default block size for

new MVS SAS data libraries to 6144, because, for some

SAS datasets that have INDEXes, the half-track block

size may be sub-optimal, but specifically for MXG, and

in general for any data-intensive SAS application that

writes large volumes of SAS data that are sequentially

accessed and do NOT use SAS Indexes, a small 6144 byte

block size will waste massive amounts of CPU time, I/O

I/O time, cause unneeded EXCPs, SIOs, and waste real

memory! And your DASD datasets at 6144 byte blocksize

will also waste DASD space! You want your MXG-built

SAS datasets to be built with half-track blocksize on

DASD!

Thanks to John R. Myers, Vanguard, USA.

Thanks to Tricia Henry, John Fairfax Holdings, AUSTRALIA.

and now others, but they reported it first!

Change 19.088 Variable INITTIME in both TYPETMNT and TYPETALO were off

VMACTMNT by one full day starting March 1, 2001, because the MXG

May 15, 2001 logic using YEARSEC did not protect for this year's leap

day, and because ASMTAPES does not get the century bit on

when it copies these IBM fields. The logic using YEARSEC

was revised to force the century bit for INITTIME.

Thanks to Joan Nielsen, i-structure, USA

Thanks to Mike Shapland, i-structure, USA.

Change 19.087 This contributed example sums up all of the CPU time for

ANALUSS a job using Unix System Services (USS) under MVS's OMVS

May 15, 2001 (OpenEdition), as described by its author:
Jobs that call Unix System Services (USS) can have their

Unix work spawned to independant address spaces that are

started tasks. OMVS creates the jobnames for these

address spaces by appending a 1-digit numeric suffix to

the jobname of the original job. (Job ABCD will spawn

STC OMVS address spaces named ABCD1, ABCD2, etc). Eight

character jobnames will spawn A/S's named the same as the

job (e.g., ABCD5678 will spawn ABCD5678). There will

likely be more than one OMVS ASID per job, so the CPU for

the USS work of a job will be in multiple type 30 records

with different job names, numbers, and initiate times.

This program matches up those job records and sums up the

CPU time for the job. (The starting and ending time of

the USS tasks will be within the start/end time of the

originating job.)
The program makes these assumptions:

1. An 8-digit USS jobname could be spawned by either a

7 or 8 digit job. The code assumes the 8-digit USS

job is spawned by an 8-digit job unless it's found

to come from a 7-digit job.

2. We assume the job started yesterday. This code

could be removed or changed.

Thanks to Alan Lankin, Towers Perrin, USA.

Change 19.086 JCL example still referenced &&SOURCLIB, but that temp

ANALDSET dataset is no longer created nor used in the revised JCL

May 15, 2001 to analyze dataset activity from 14/15/64 and SMF 30s.

Thanks to Freddie Arie, TXU, USA.

Change 19.085 TLMS date variables BAPURCH BACLNDT BACERTDT with invalid

VMACTLMS julian day-value of zero (Packed field '0100000C'x in the

May 15, 2001 record) caused INVALID ARGUMENT FOR DATEJUL FUNCTION.

Jul 6, 2001 This change tests the day value of those three fields and

sets the date missing if the day value is zero.

Also, the value of BACTIME was not correctly converted to

a time value but now is and is formatted as TIME8.

Jul 6: Variable BALUNIT was changed to BAIUNIT to match

the TLMS dsect name.

Thanks to Dietmar Lakemann, Rechenzentrum Verden GmbH, GERMANY.

Thanks to Ian Davies, Independent Consultant, CANADA.
Change 19.084 MXG output observations in TYPE73 for channels that were

VMAC73 offline (but with all zeros, the extra observations had

May 15, 2001 no real impact), but they are no longer output. The old

MXG logic had bit tests to protect for MVS/ESA 4.3 that

can now be removed, and the test to output TYPE73 now is:

IF ONLINE='Y' AND VALIDPTH='Y' THEN DO;