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

MXG architecture supports "subtype-level-processing" for

this record (see comments in its VMAC.... member), it is

easy to add only specific subtypes to your BUILDPDB.

(It is MXG's intention to extend "s-l-p" architecture to

all SMF records with subtypes.)

The following example shows how you would add DB2 type 102

subtypes 63 and 106 to your BUILDPDB.
Member Would contain
EXPDBIND %INCLUDE SOURCLIB(VMAC102);

EXPDBVAR MACRO _VARUSER _V102063 _V102106 %

EXPDBCDE MACRO _CDEUSER _HDR102 _C102063 _C102106 _END102 %

EXPDBOUT PROC COPY MT=DATA INDD=WORK OUTDD=PDB;

SELECT T102S063 T102S106;

Thanks to Nancy Ayers, General Electric Lighting Business Group, USA.

Change 10.055 Date selection in DB2 reports PMSACC01/PMSACC02 produced

ANALDB2R no report because code was relocated incorrectly. In the

May 3, 1992 %MACRO PMACC01 and the %MACRO PMACC02 definitions, find

the invocation of %DB2RSELA (once in each of the above

macro definitions), and after each of these %DB2RSELA,

insert the following four lines:

IF NOT INTREND THEN DO;

MINTIME=QWACBSC;

MAXTIME=QWACESC;

END;

Thanks to Nancy Ayers, General Electric Lighting Business Group, USA.
Change 10.054 VTOC processing did not capture archaic ISAM index space,

VMXGVTOF warning "CRITICAL ERROR IN VTOF PROCESSING". The FMT2

VMXGVTOC DSCB, which describes the space occupied by ISAM indices

May 3, 1992 is now properly processed.

Thanks to Hr. Leineweber, HUELS AG, GERMANY.
Change 10.053 DB2ACCT dataset can now be written to a DDNAME of your

ANALDB2R choosing, and unnecessary SORTs which wasted WORK space

ASUMDB2A were eliminated. High volume transaction datasets should

BUILDPDB be written to tape (or a separate DASD file) and thereby

BUILDPD3 avoid B37 ABENDs and pollution of the daily PDB. MXG has

DIFFDB2 done this for CICSTRAN, and now that same philosphy has

EXDB2ACC been implemented for DB2ACCT as well. However, if you

IMACDB2 do nothing, the DB2ACCT data will still be written to your

READDB2 PDB, and the only incompatibility of this change is that

May 5, 1992 the DB2ACCT dataset is no longer sorted, which could cause

an error if you build a weekly DB2ACCT expecting it to be

sorted. (If so, simply remove the BY statement following

WEEK.DB2ACCT in your WEEKBLD/MONTHBLD member.)

Of greater impact, however, is the philosophy that now the

DB2ACCT dataset is a transaction file that may not be in

the daily PDB; what about daily/weekly reporting? Just as

CICS transactions are written to a transaction file and

are then summarized into the PDB.ASUMCICS by ASUMCICS, the

DB2ACCT dataset can now be summarized into PDB.ASUMDB2A by

new member ASUMDB2A, and the summarized PDB.ASUMDB2A can

be used for DB2 reports PMACC01 or PMACC02 in ANALDB2R.

a.IMACDB2 now defines MACRO _DB2ACCT PDB % (i.e., default is

PDB). Change that default value to DB2ACCT if you want to

write the DB2ACCT data to the DDname of DB2ACCT (and then

add a //DB2ACCT DD to your job).

b.VMACDB2 and EXDB2ACC now output to _DB2ACCT.DB2ACCT, and

IMACDB2 is included by VMACDB2.

c.DIFFDB2's unnecessary PROC SORT DATA=DB2ACCT was removed.

(This was the primary abuser of WORK space in BUILDPDB.)

d.The PROC SORT DATA=DB2ACCT OUT=PDB.DB2ACCT in BUILDPDB/3

was eliminated, since the DB2ACCT data set has already

been written to _DB2ACCT as the SMF data was processed.

And DB2ACCT was removed from the PROC DATASETS;DELETE list

e.If ANALDB2R or READDB2 is used to read SMF data, and if

PDBOUT= is specified to save the created datasets, the

DB2ACCT dataset will be sent to the DDname in IMACDB2,

while all other selected datasets are sent to PDBOUT=.

Thus if you do not change IMACDB2's default of PDB, and

you specify PDBOUT=PDB, then all datasets created by these

two members will be written to the PDB DDname. If instead

you change the IMACDB2 DDname, the DB2ACCT dataset will be

sent to the IMACDB2 destination.

Thanks to Nora Spencer, Toyota, USA.

Thanks to Bill Stoneberg, National-Oilwell, USA.

Thanks to Neil Ervin, Huntington Bank Service Company, USA.
Change 10.052 LPAR CPU utilization reports created by this rewritten

GRAFLPAR member can use PDB or TREND library PR/SM datasets

Apr 30, 1992 ASUM70PR or TRND70PR. Comments within the member show how

to select and generate desired reports.

Change 10.051 Invalid data for SMFPSRVR reading CICS/ESA dictionary

UTILCICS records, because UTILCICS was not updated at the same time

Apr 30, 1992 that VMAC110 was updated to support IBM's changed format

of SMFPSRVR. 2. The correction is to replace two lines

039200-039300 which now read:

INPUT @OFFPROD SMFPSRVR 2.

APPLID $CHAR8. /*SMFMNPRN*/

with these three lines:

INPUT @OFFPROD SMFPSRVR ?? 2. @;

IF SMFPSRVR=. THEN INPUT @OFFPROD SMFPSRVR PK2.1 @;

INPUT APPLID $CHAR8. /*SMFMNPRN*/

Thanks to Dave Gosse, Univesity of Iowa Hospitals, USA.

Change 10.050 Specifying a DDname other than PDB in IMACMONI caused the

ASUMDBDS ASUMDBDS member to fail with dataset not found error. This

TRNDDBDS change also renames the dataset created by ASUMDBDS to be

Apr 30, 1992 named ASUMDBDS and thereby be consistent with MXG ASUMs.

Finally, TRNDDBDS was added for trending ASUMDBDS output.
Change 10.049 Graphic reports were not perfect. Charts were not printed

GRAFTRND if there were fewer than 40 intervals, the interval was

Apr 28, 1992 not always calculated correctly, and forecast line could

be skewed because the last-actual-value rather than the

last-predicted-value was used. If STAT=NO was specified

or specified in the wrong case, Axes statements were lost.

Workload bar chart axes values for projections were wrong.

All these glitches have been repaired.

Thanks to Van Xydis, VM System Center, USA.

Thanks to Norbert Korsche, OMV-AG, AUSTRIA.

Change 10.048 Support for AICorp's KBMS (Knowledge Based Management

EXAICOST System) user SMF record is added by this change, which

IMACAICO creates the AICOSTAT dataset with CPU time, EXCP count and

TYPEAICO elapsed time for each "transaction".

VMACAICO

Apr 30, 1992

Thanks to Kelly Raven, CSX Technology, USA.
Change 10.047 DB2 reporting for DBID and OBID did not print the actual

ANALDB2R name of the object. MXG built formats dynamically to map

Apr 30, 1992 these objects, but failed to use the format in the report

PUT statements. Many lines were altered in this change.

This change also added processing of the T102S183 dataset

to the SQL reports.

Thanks to Carl Koch, AT&T Westminster, USA.
Change 10.046 DB2 reporting LIBRARY SMF IS NOT VALID message occurs if

ANALDB2R PMSQL04 or TRANSIT reports are requested with PDB=SMF.

Apr 29, 1992 Insert after 009060 OR &PMSQL04=YES

and replace line 186700 (currently _ALLPAIR;)

with %ANALDBTR(PDB=&PDB1,PAIRS=ALL);

Thanks to Carl Koch, AT&T Westminster. USA.

Change 10.045 Using READDB2 with TRACECLS= parameter to select desired

READDB2 IFCIDs by trace class does not select all IFCIDs in all of

Apr 29, 1992 the classes you ask for (however, the IFCID= parameter can

be used to list the desired values, and it has no error).

READDB2 itself does not fail, but creates zero observation

datasets for some trace classes, which can cause ANALDB2R

to fail if it is invoked after the READDB2 invocation.

Correct this error by moving the %INCLUDE statement in

line 026400 to immediately after 007400.

Thanks to Carl Koch, AT&T Westminster. USA.

Change 10.044 The calculation of TAPEFEET from TMS data should include

TYPETMS5 test for RECFM='VS ' in line 005200 of TYPETMS5 and in

VMACTMS5 line 037300 of VMACTMS5.

Apr 28, 1992

Thanks to Norbert Korsche, OMV-AG, AUSTRIA.
Change 10.043 Two RECFM codes, FS and VS, were not decoded by VMACRCFM.

VMACRCFM After line 002100 insert:

Apr 28, 1992 ELSE IF RECFMT='1000100.'B THEN RECFM='FS ':

and after line 003200 insert:

ELSE IF RECFMT='0199100.'B THEN RECFM='VS ':

Thanks to Norbert Korsche, OMV-AG, AUSTRIA.

Change 10.042 The percentage of time when there are more Ready tasks in

VMAC7072 memory than there are Processor Engines is a much better

XMAC7072 indicator of CPU "stress", especially in LPARs, because it

Apr 27, 1992 directly measures when tasks are waiting for CPU dispatch.

MXG now creates variable PCTRDYWT in dataset TYPE70:

IF NRCPUS=1 THEN PCTRDYWT=SUM(OF READY02-READY15);

ELSE IF NRCPUS=2 THEN PCTRDYWT=SUM(OF READY03-READY15);

ELSE IF NRCPUS=3 THEN PCTRDYWT=SUM(OF READY04-READY15);

(repeated for NRCPUS up to 8), and is labeled

PCTRDYWT='PERCENT WHEN*READY TASKS*ARE WAITING'.

The only weakness of PCTRDYWT is that it does not identify

WHICH ready tasks are waiting, and with a well-designed

SRM you would typically have your lesser important tasks

Ready and waiting for CPU dispatch while your online tasks

are getting what they need.
Change 10.041 Line 398700 should be STID=77 instead of STID-77, and MXG

VMAC110 did not create observations in CICCONMT statistic dataset.

Apr 27, 1992 Fortunately for me, the STID=77 is the "total" record for

the "interval" STID=76 which was output in CICCONMR, and

thus no data was lost. IBM no longer creates any "total"

records starting with CICS/ESA 3.3, so all of the CICS

statistics datasets which end with "T" will have zero

observations in the future. Total records were redundant

with the interval data.

Thanks to Caron Knox, Willis Corroon Group, ENGLAND.

Change 10.040 Type 39 SMF record caused INPUT STATEMENT EXCEEDED with

VMAC39 subtype=5. Change all occurrences of NE 0 to GT 0

Apr 22, 1992 (a missing value unintendedly satisfied the NE 0 test).

Thanks to Miller Dixon, Continuum, USA.

Change 10.039 The NET-PASS variable NETPACTM was the total response

VMACNETP for NETPTRNS transactions, but it should have been the

Apr 22, 1992 average response time. Insert after 010200 this line:

IF NETPTRNS GT 0 THEN NETPACTM=NETPACTM/NETPTRNS;

Thanks to Nancy Ayers, General Electric Lighting, USA.
Change 10.038 Candle Omegamon for CICS V550 erroneously stored nulls in

VMAC110 the packed decimal field SMFPSRSN, causing MXG to print a

Apr 22, 1992 hex dump of the SMF record. Candle incident 201387 fixes

their error, but MXG circumvents the unwanted hex dump

by adding ?? to the input statement so it now reads:

SMFPSRSN ?? PD4.

Change 10.037 JES2 Spool Offload type 24 SMF record can cause STOPOVER

VMAC24 ABEND because tests for OFFESS and NRESS in line 016100

Apr 21, 1992 must be GT 0 instead of NE 0. (Missing values satisfy the

NE 0 test but not the GT 0 test.)

Thanks to David Ehresman, University of Louisville, USA.
Change 10.036 VM/ESA 1.1.1 is now supported, creating 3 new datasets

FORMATS and adding new variables to existing datasets:

VMACVMXA a.Variables added to existing MXG datasets:

Apr 20, 1992 VXSYTSHS - variables CALNUMSA and RSACTSHR.

VXMTRSYS - flag variable SYSMASFI.

VXMTRPRT - PCCCSU and PFXCFO.

VXSTOSHR - ASCCSPGR,SPGW,SPXR,SXWT,ASCSMIGC,VMDCTLKP and

VMDCTNPS. IBM renamed VMDCTPST to ASCCSPST,

but MXG continues to call it by its original

name, and did not create a redundant variable.

VXBYUSR - VMDASMCT,BLKCT,MDCIA,OPCTN (from VXUSEACT).

VXIODDEV - VIUTIM/CNT for IN,LV, and OT, and RDEVMCIA.

VXIODCAD - CALDATA ($CHAR160) replaced CALPSF ($CHAR96).

b.New data sets VXSTOASI (Interval Shared Address Space

paging activity), VXSTOASC (Address Space Create Event),

and VXSTOASD (Address Space Delete Event) were added.

c.New format MGBYTRT expresses byte rate in B/SEC, KB/SEC,

MB/SEC printed units, similar to MGBYTES for byte values,

and is used for several new storage movement variables.

d.These changes have been tested with HCPCPEID=1101 release.

Change 10.035 TMS variables EDMTAP and DYNAM were incorrect. The bit

VMACTMS5 test should be the '20'X bit for EDMTAP (instead of '40'X)

Apr 20, 1992 and the '10'X bit for DYNAM (instead of '20'X).

Thanks to Ruth Whitney Parker, Citibank South Dakota, USA.

Change 10.034 If you added a SORTBY= operand for DB2 Reports the report

ANALDB2R did not break where you expected; only the first variable

Apr 16, 1992 in your SORTBY= list was used. Lines 006250 and 006260

both now start with %ELSE %IF LENGTH( .... Both must be

changed to start with only %IF LENGTH( ....

Reports requested without SORTBY= had no error.

Thanks to Georg Simon, Federal Reserve Bank of Philadelphia, USA.
Change 10.033 Support for the Software Ag "Natural Process" SMF record

EXNATPAC is added by this change. Dataset NATPACCT contains one

IMACNATP observation for every SMF record, written at user logoff

TYPENATP (including a termination of Natural Process before the

VMACNATP user can logoff), with the Natural Process 8-byte user id,

Apr 15, 1992 the CPU time and I/O count of that session.

Thanks to Joanne Turpie, Department of Labour, Wellinton, NZ

Thanks to Terry Proops, Department of Labour, Wellington, NZ

Change 10.032 Two references to DATA=SMF should have been DATA=LLAEXIT

ANALLLA in this analysis example.

Apr 15, 1992

Thanks to Hanno Bresch, SAS Institute, GERMANY.

Change 10.031 New variables ACTDLYTM/RESDLYTM/DSPDLYTM are now created

VMAC30 in TYPE30_4, TYPE30_V, PDB.STEPS and PDB.JOBS datasets.

IMACPDB These delta times are described on pages 44-45 of the MXG

Apr 15, 1992 Guide, but were not kept as unique MXG variables until a

CPE class student went home and observed confusing values,

because pages 44-45 were not completely accurate. After

further research (and clarification from Bernie Pierce of

IBM) they now clearly deserve their own variables.

ACTDLYTM='Delay duration*executing*not active'

(EXECTM-ACTIVETM)

This delta includes time the address space was

Detected Wait or Long Wait swapped out by SRM,

(which includes TSO user's think time).

RESDLYTM='Delay duration*active*not resident'

(ACTIVETM-RESIDTM)

This delta is the time SRM wanted the ASID to

be in the Multi-Programming Set, but was unable

to get the ASID resident. This includes all

swapped out time (except DW/LW, which is caught

in ACTDLYTM) plus the time to actually do the

swap in. Another name might be MPL Delay time,

because all of the swap out and non-resident

time while active is the time when the Target

MPL was not high enough to include this task.

This delta divided by SWAPS is an estimate of

the time-to-swap-in a task, but since SWAPS

counts both RESDLYTM and ACTDLYTM swap events,

and since RESDLYTM includes the time to swap in

and the time waiting to swapin and the time

swapped out, the estimate is usually poor!

DSPDLYTM='Delay duration*resident*not dispatched'

(RESIDTM-CPUTCB+SRB+HPT+RCT+IPT)

This delta is the time the task was resident

in memory but was not executing instructions.

It includes delay for CPU dispatch (when you

enter the MPL set you don't immediately get

CPU - a hot CICS transaction may still have the

processor), delay for I/O (you execute a few

CPU instructions and then issue an I/O and you

wait for IOS to get the data for you), delay

due to page faults (the next page is not

in memory and you wait for that page to be

brought in), and delay due to tape mounts.
NOTE: PRIOR TO AUG, 1994, THIS CHANGE TEXT SAID THAT TAPE MOUNT

DELAY WAS INCLUDED IN ACTDLYTM, BUT THAT WAS IN ERROR. DELAY FOR

TAPE MOUNTING HAS ALWAYS BEEN INCLUDED IN DSPDLYTM. SEE THE NEW

SCHEMATICS IN MEMBER ADOC30 AND SEE CHANGE 12.142.

Schematic step duration example (numbers from a day's TSO session):

ELAPSTM

|-----------------------------------------------------------------|

| |

INITTIME ALOCTIME LOADTIME ENDTIME

|---------|---------|---------------------------------------------|

DSENQTM ALOCTM / EXECTM |

/ |

/ |

/ |

/ |

/ |

/ EXECTM |

/ 14:29:37.42 |

|------------------------------------------------------|

| |

| ACTDLYTM ACTIVETM |

| 14:16:57.90 759.52 |

|--------------|---------------------------------------|

| |

| RESDLYTM RESIDTM |

| 04.22 755.30 |

|------------|--------------------------|

Session TGETS=1275 | |

TSO/MON TRANS=1276 |DSPDLYTM CPUTM|

| 654.13 101.17|

|--------------|-----------|
Thanks to Steve Donahue, Blue Cross and Blue Shield of Texas, USA.
Change 10.030 JCLTEST6 gets INVALID DATA FOR SMFTIME when a VSAM SMF

JCLTEST6 file is used for step SMFSMALL, because of SAS 6.07 Error

Apr 15, 1992 V6-SYS.DATA-3550, which affects only the creation of BSAM

files from VSAM input. There is no error in creation of

SAS datasets from VSAM input.

The error only occurs if the INFILE SMF START=BEGINCPY

parameter has BEGINCPY not equal to one. To create a

BSAM file of SMF records from a VSAM file, MXG has to

set BEGINCPY=5 (to start the copy in byte 5 of the

VSAM record, and thereby skip over the unwanted first

four bytes containing RDW/SDW of the VSAM record).

This is done in MACRO _SMF defined in member VMACSMF.

This error has been fixed by SAS ZAP MV313550. Only the

members JCLTEST6/JCLTEST use START=BEGINCPY logic, and

only in step SMFSMALL; either install the SAS ZAP or use

a non-VSAM file for the SMF ddname in step SMFSMALL.

Thanks to Dan Squillace, SAS Institute Cary, USA.
Change 10.029 Cosmetic. Variable QWACARNW in VMAC102 had no asterisks

VMACNSPY in its label. Added asterisks as in variable QWACARNR.

Apr 15, 1992
Change 10.028 Variable SESSMGR was misspelled once as SESSGMR, causing

VMACNSPY it to never have value "Y".

Apr 10, 1992

Thanks to Lindsay Oxenham, State Electricity Commission of Victoria.

Change 10.027 Comments only were changed. The reference to _CICEXCL in

IMACCICS comments do not apply to IMACICS; the Exclude Logic macro

Apr 10, 1992 _CICEXCL is defined/described in member IMACEXCL.

Thanks to Don Sively, E-Systems, USA.

Change 10.026 Dataset TYPE0203 was not deleted from the WORK file after

BUILDPDB PDB.TYPE0203 had been built. MXG "housecleans" the WORK

BUILDPD3 library in BUILDPDB to minimize the amount of workspace

Apr 9, 1992 required. TYPE0203 had been overlooked when added.

Thanks to Tracy Blackstone, Kaiser Foundation Health Plan, Inc, USA.
Change 10.025 SMF type 41 DIV (Data In Virtual) Access/Unaccess records

VMAC41 variables ACCSTIME and UACCTIME are timestamps and not the

Apr 9, 1992 durations implied by the SMF manual. Hex value 'A57F3640'

expanded to 8 bytes was 05APR92:08:50:33 in a record with

SMFTIME=05APR92:09:09:00 in a TYPE41AC observation after

this change. (That large delta of 19 minutes confuses me;

if you use this record, what's your data show?). Change

ACCSTIME PIB4.2 to ACCSCHAR $CHAR4.

UACCTIME PIB4.2 to UACCCHAR $CHAR4.

and insert after the appropriate @; one of the following:

ACCSTIME=INPUT((ACCSCHAR||'00000000'X),TODSTAMP8.);

UACCTIME=INPUT((UACCCHAR||'00000000'X),TODSTAMP8.);

and give both variables format DATETIME21.2 and LENGTH 8.

IBM APAR OY19780 is the Documentation Error acknowledging

these fields to contain the first 4 bytes of TODSTAMP.

Thanks to Terry Poole, SAS Institute Cary, USA.

Thanks to Richard Bear, Gulf States Toyota, USA.
Change 10.024 MVS Accounting fields (+ additional DB2 accounting data)

FORMATS were added to DB2ACCT and some trace records by IBM in a

VMACDB2 revision included in DB2 2.3 release, but documentation

VMAC102 did not arrive in time for MXG 9.9. Additionally, format

Apr 9, 1992 values for PACKADM were added to the IFCID 140/141 data.
This enhancement uses your site's tailoring in IMACACCT

to set the length of the ACCOUNTn variables that are kept.

These new accounting variables are added to DB2ACCT:
Variable Type Length Format Label
ACCOUNT1 CHAR ?? FIRST JOB*ACCOUNT*FIELD

ACCOUNT2 CHAR ?? SECOND JOB*ACCOUNT*FIELD

ACCOUNT3 CHAR ?? THIRD JOB*ACCOUNT*FIELD

QMDAASLN NUM 4 BYTES USED IN QMDAAINF

QMDAAUTH CHAR 8 DB2 AUTHID

QMDACNAM CHAR 8 DB2 CONNECTION*NAME

QMDACORR CHAR 12 DB2 CORRELATION*ID

QMDACTYP CHAR 8 DB2 CONNECTION*TYPE

QMDALOCN CHAR 16 DB2 LOCATION NAME

QMDALUNM CHAR 8 SNA*LU*NAME

QMDANETN CHAR 8 SNA*NETID

QMDAPLAN CHAR 8 DB2 PLAN

QMDAPMOD CHAR 1 PRODUCT*MODIFICATION*LEVEL

QMDAPREL CHAR 2 PRODUCT*RELEASE

QMDAPTYP CHAR 10 $MGDB2PN. PRODUCT*NAME

QMDAPVER CHAR 2 PRODUCT*VERSION

IBM's DB2 group reformatted the standard MVS account data!

Instead of sensibly copying the existing, well-known, and

already-decoded MVS accounting string (which contains a

length-field preceding each account-field), the DB2 group

decided to eliminate the length fields and instead insert

an 'FF'x byte as a delimiter between account fields! This

unnecessary inconsistency by DB2 required a new algorithm

(and of course any new algorithm is an exposure to error)

that required 120 lines of SAS code plus time to test!

Consistency would have been cheaper and lots safer!

Change 10.023 The SAS 5.18 Circumvention for the 344 Compiler Error in

XMAC7072 member XMAC7072 will cause UNINITIALIZED VARIABLE messages

Apr 8, 1992 because the final version of VMAC7072 was not edited into

XMAC7072. Copy in VMAC7072 into XMAC7072, replace all 410

lines in the DO group following 'NOT MVSXA' with this

single line : IF SUPATRN=' ' THEN SUPATRN=' ';

to create the corrected XMAC7072 member.

Thanks to Ken Thomas, Maryland Casualty Company, USA.

Change 10.022 Support for ROSCOE Release 5.7 changes to SMF Records.

EXROSPRN SMF record creates two new subtypes and MXG creates a new

EXROSSTA dataset for each: ROSCOPRN - ROSCOE Printing Services,

FORMATS subtype '80'x, and ROSCOSTA - Roscoe Statistics, subtype

VMACROSC '34'x. Both new ROSCOE datasets appear to have useful

Apr 8, 1992 new information about your ROSCOE subsystem, and its PRINT

activity. This change added about 250 lines.

Thanks to Dave Thorn, Dow Jones & Company, USA.

Change 10.021 New NPMHP, NPMMP, and NPMLP variables for Hi/Lo/Med Prty

TYPE28 bytes sent/received were not all kept, and some had "Sent"

Apr 7, 1992 in their label instead of "Received".