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

(PIB6.2 seconds since 1JAN1980, IB2. minutes GMT offset,

and add 63115200 seconds for the 1960-1980 delta).

The corrected variables are

SYREXTDI SYREXPTI GLSTDAY1 GLSTDAY2 RWREDATE

Thanks to Bill Blair, BMC, USA.
Change 18.204 Major rewrite of ASUMUOW to add variables, make it

ADOCUOW simpler for you to add or delete variables, add the

ASUMUOW possibility of MQ series data, and allow you to break

JCLUOWV the processing of DB2 and CICS data into separate jobs

VMXGUOW to increase parallelism and decrease run times.

Aug 26, 2000

Sep 25, 2000 In larger installations, the processing of CICS and DB2

data can be extremely time and resource consuming. In a

large shop, over 120 million CICS transactions/day are

processed and over 3 million DB2 accounting records in

3 separate runs per day. Each of these creates 5-6

3490 volumes of CICS transaction data and 1-2 of DB2

data. The total processing time often exceeds 18 hours

per day. In the event of an ABEND, recovery time is

very painful.
Consider the flow of the processing. TYPE110 reads the

SMF data and creates the CICSTRAN dataset. This must

be sorted and then read by ASUMUOW. That means that 5-6

cartridges of data are read and written by TYPE110, read

and written by SORT, and read by ASUMUOW. If we assume

6 cartridges for each, then there are 5 full passes of

the data (a total of 30 cartridges!)
Now revise the flow so that a VIEW is used to pass the

data directly from TYPE110 into the SORT. Two full

passes of the data (writing it from TYPE110 and reading

it in the SORT) are eliminated. At 10 minutes per tape

this adds up to about 2 hours of processing time in each

of the three cycles of CICS data per day!

Member JCLSUOW is a set of JCL containing three jobs.

Job TYPE110V executes TYPE110 to read only the CICS

transaction data and sort it into the correct sequence

for ASUMUOW keeping only those variables needed by

ASUMUOW. TYPEDB2V process all of the DB2 data and uses

a VIEW to pass the DB2ACCT data into the SORT for

ASUMUOW. All other DB2 data uses the normal sorts and

processing for DB2. ASUMUOWV uses the output of the

first two jobs as input to ASUMUOW.
ASUMUOW now contains some substitution style macros

for keeping lists of variables and datasets and uses a

new macro VMXGUOW to dynamically build the code to

perform the summarization so that adding and deleting

variables is much simpler (you don't have to invent new

variables names for all of the counters!)

Substitution MACROS in ASUMUOW:

_LASSPIN - SPIN.SPINUOW - OUTPUT SPIN DATASET

_PRESPIN - SPIN.SPINUOW - INPUT SPIN DATASET

_TMPSPIN - TEMPSPIN - INTERMEDIATE SPIN DATASET

_SUUOW - &PSUUOW..ASUMUOW - FINAL OUTPUT

_WSUUOW - NOT USED

_KSUUOW - NOT USED

_BSUUOW - NETSNAME UOWTIME UOWIDCHR - SORT ORDER

_SSUUOW NOT USED

_NOBS - %%VMXGOPTR(OPTNAME=OBS,NEWVALUE=0);RUN;

Controls number of observations

Must be overridden in member IMACUOW

(by completing comment statements)

to create observations in PDB.ASUMUOW.

_YESOBS - %%VMXGOPTR(OPTNAME=OBS,NEWVALUE=MAX);RUN;

Resets number of observations

Must be overridden in member IMACUOW

(by completing comment statements)

to create observations in PDB.ASUMUOW.

_TRANUOW logic to determine which transaction name

is the real transaction name

_SPINUOW - 7 How many spins

_LASCICS &TEMP01..TEMPCICS - intermediate CICSTRAN

_LASDB2A &TEMO02..TEMPDB2A - intermediate DB2ACCT

_LASMQ WORK.TEMPMQM - intermediate MQMACCT

_INMQ _NULL_ - input MQMACCT dataset

_KUOWCIC list of variables to be kept and accumulated

from CICSTRAN

_KUOWDB2 list of variables to be kept and accumulated

from DB2ACCT

_KUOWMQ list of variables to be kept and accumulated

from MQMACCT

_SUOWCIC the sort of the CICSTRAN dataset

_SUOWDB2 the sort of the DB2ACCT dataset

_SUOWMQ the sort of the MQMACCT dataset

_SUOSPN building of the intermediate SPIN dataset

VMXGUOW parameters:

INCODE= A stub of code executed

during INPUT processing

INCICS= A stub of code executed

when a CICS record is found

INDB2 = A stub of code executed

when a DB2 record is found

INMQ = A stub of code executed

when an MQ record is found

INSPIN= A stub of code executed

when a SPIN record is found

OUTCODE= A stub of code executed

during OUTPUT processing

Currently calculates

CLASS3 DB2 times and counts

and SQL counts

CICSVARS=_KUOWCIC variables kept and counted

for CICS

DB2VARS=_KUOWDB2 variables kept and counted

for DB2

MQVARS=_KUOWMQ variables kept and counted

for MQ Series

If all you do with ASUMUOW is a %INCLUDE, you will

not need to make any changes.

Thanks to Chuck Hopf, MBNA, USA.
Change 18.203 RMF Paging Activity Report: corrected values for LPA and

ANALRMFR CSA columns named NON SWAP BLOCK and NON SWAP NON BLOCK.

Aug 25, 2000
Change 18.202 Some DB2 statistics variables, new in DB2 6.1, were input

VMACDB2 but were not deaccumulated, so their values were wrong.

Aug 25, 2000 This change does not affect the DB2ACCT dataset, which

Sep 5, 2000 contains interval values (i.e., valid); it is only the

statistics records that have accumulated values that must

be deaccumulated in MXG logic.

-Group Buffer Pool variables in DB2GBPST/DB2STATS/DB2STAT1

datasets were not deaccumulated:

QBGLAX QBGLAY QBGLAZ QBGLCC QBGLCK QBGLCS

QBGLDG QBGLDN QBGLRB QBGLRD QBGLRG QBGLUN

Don found this error because he knew that QBGLUN must

be lots less than QBGLRC. I had INPUT and KEEPt them but

failed to update the _SDB2PST and _SDB2ST1 macros that do

the deaccumulation. This cause me to examine the other

variables added to the statistics records, and I found:

-QXxxxxx variables in dataset DB2STATS/DB2STAT1 dataset

were only INPUT, and were neither kept nor deaccumulated:

QXALPRO QXALUDF QXCASCDP QXCAUD QXCAUDAB QXCAUDRJ

QXCAUDTO QXCRATB QXROIIDX QXROIMAT QXROITS QXROWTRG

QXSTLOBV QXSTTRG QXTRGERR

-Sep 5: Variables QBGBGR1 and QBGBGR2 were moved from the

$HEX8. to $HEX12. format list; they are 6 bytes long but

with the shorter $HEX8. format, they appeared to be blank

when the first four characters were blank or nulls.

Thanks to Don Deese, (CPExpert), Computer Management Sciences, USA.
Change 18.201 The four variables that measure bytes are now formatted

VMACTCP with MGBYTES so the values will be more readable in the

Aug 24, 2000 units of /KB /MB /GBytes. The four variables are:

APIBYTIN APIBYTOU FTPBYTEC TELINBYT TELOUBYT

Thanks to Chuck Hopf, MBNA, USA.
Change 18.200 The Workload name printed only the first two characters.

UTILRMFI A LENGTH WORK $8; statement had to be inserted after

Aug 25, 2000 each of the INCODE= arguments.

Thanks to David Ehresman, University of Louisville, USA.

Change 18.199 The High Impact (Low UIC), Medium Impact (Medium UIC),

VMAC71 Low Impact (High UIC), and Available Impact frame count

Aug 25, 2000 fields for CStore and for EStore were added to TYPE71 by

Sep 5, 2000 OS/390 R2.4, but only now, as a result of Peter's looking

Sep 12, 2000 at real numbers after seeing a presentation by Martin

(who had them added to type 71), and with free advice

from Don Deese (who first documented their cousins in RMF

type 99), MXG now correctly decodes those twenty-four

memory measurements into these variables:

HI mn/mx/av HI mn/mx/av

CSFR ME mn/mx/av ESFR ME mn/mx/av

LO mn/mx/av LO mn/mx/av

AV mn/mx/av AV mn/mx/av

The field values are accumulated between adjacent values;

it is necessary to subtract MED from HI to get HI values,

LOW from MED to get MED, and AVAIL from LOW to get the

LOW values. Because the MED memory is quite small with

the current IBM-set UIC buckets, its average value was

often a small negative value; in those cases, the MED are

set to missing, and HI-LO is used for HI values. Fields

are in frames, but as the variables were never correct, I

converted all CSFR/ESFR variables to bytes, formatted

them with MGBYTES, and re-labeled them as IMPACT MEMORY.
Martin's paper precipitated creation of additional memory

measures, based on average values that are now created in

MXG's TYPE71 dataset:

CSFRSRAV "SRM-BUFFER" in CSTORE

ESFRSRAV "SRM-BUFFER" in ESTORE

The frames needed to support the Available

Frame Queue, calculated by subtracting the

new free size from the old free size.

CSFRWLAV "Free as Seen by WLM" in CSTORE

ESFRWLAV "Free as Seen by WLM" in ESTORE

The free memory as seen by WLM, calculated

by removing the SRM-Buffer value from the

CSFRAVAV/ESFRAVAV values.
But the "Impact" memory includes only the UIC-updated

pages. WLM updates UICs in Expanded, but not DREF nor

hiperspaces, (but hiperspace size is in TYPE71). Also,

fixed frames and nucleus frames are not UIC-updated (but

they also are in TYPE71). Since the installed CSTORE and

ESTORE memory is known, the missing piece of memory is

all of the memory owned by all of your logically swapped

ASIDs plus any storage isolated pages!

With this change and these new variables, the CSTORE and

ESTORE memory is mapped by these MXG variables:

Online memory CSTORE ESTORE

Logically Swapped CSFRLSAV ESFRLSAV

Fixed CS, Hiper ES CSFRFXAV ESFRHSAV

WLM-viewed Free Memory CSFRWLAV ESFRWLAV

SRM-Buffer Memory CSFRSRAV ESFRSRAV

Low-Impact High-UIC Memory CSFRLOAV ESFRLOAV

Med-Impact Med-UIC Memory CSFRMEAV ESFRMEAV

Hi-Impact Low-UIC Memory CSFRHIAV ESFRHIAV

Because we are adding averages to averages, the measures

are not perfect, and small negative values can still show

up for the MN and MX values, but this provides a complete

picture of how your CSTORE and ESTORE are being used.

Sep 5: The calculation of CSFRFXAV was corrected to use

FIXEDAV instead of PRVFXAV for the fixed memory.

These new CSFRxxxx measures above were compared with the

existing CSTORE72 and ESTORE72 variables in RMFINTRV and

TYPE72/TYPE72GO datasets; those type 72 measurements are

based on resident frame time, and are more accurate than

the averages of averages, in my opinion, and they also

provide memory usage by SRVCLASS/PERFGRP so you can tell

which tasks are occupying how much of your memory.

Sep 12: CSTORE and ESTORE creation was moved up in the

code so that CSFRLSAV and ESFRLSAV are not missing.

Thanks to Martin Packer, IBM, EUROPE

Thanks to Peter Webber, CIS, UK.

Thanks to Tony P. Steward, Post Office, UK.

Change 18.198 TYPE103 variable BYREADCA could have negative values and

VMAC103 contained only the bytes portion of Bytes Read From Cache

Aug 23, 2000 while variable KBREADCA contained only the bytes from the

KiloByte part of the total. Now that IBM revised their

field descriptions, I can correctly sum the KB*1024 plus

the Bytes, and that value is stored in both variables;

both contain bytes and are formatted with MGBYTES format,

and now both describe total bytes read from cache.

An eight byte binary field would have been better!

Thanks to Rex Elbert, SPRINT, USA.

Change 18.197 Support for APAR II11493 changes to SMF type 50 VTAM

FORMATS Statistics record (INCOMPAT) adds new subtype 03 and

VMAC50 restructures that record different from other subtypes.

Aug 22, 2000 The new record provides statistics for TCP connections.

Thanks to Mark Rosen, Office Depot, USA.
Change 18.196 Support for APAR PN61399 (corrects TELNET SMF LOGF record

VMACTCP 'SAVF' in error instead of 'LOGF') adds 'SAVF' to the

Aug 21, 2000 commands that MXG recognizes as TELNET SERVER record, so

even if you don't have the APAR installed, MXG protects.

Change 18.195 Cosmetic. Comments in EXPDBSTP containing the old macro

EXPDBSTP names (prior to MXG 16.04 changes) were revised to show

Aug 16, 2000 the current macro name, _LDBSTEP, in the example.

Thanks to Patrick Julien, France Telecom, FRANCE.

Change 18.194 Error: INVALID DATA FOR GDESIS because the input should

VMACQAPM have &PD.3. instead of &PD.4., but this field indicates

Aug 16, 2000 the data is from Collection Services and not QAPM.

Thanks to Joseph J. Faska, Depository Trust, USA.

Change 18.193 Support for new NTSMF object "SESSION", previously named

VMACNTSM "TERMINAL SERVICES SESSION and with seven new fields:

Aug 16, 2000 ELAPSTM PID PRTYBASE TOTPROHI TOTPROHR TOTPRORE

UNKNCTR1

and removes two:

TOTRANER TOTAL*TRANSPORT*ERRORS

OUTRANER OUTPUT*TRANSPORT*ERRORS

INTRANER INPUT*TRANSPORT*ERRORS

and one unnamed counter is thought to be HANDLES, so the

new record has a total of 80 data fields. It is still

output to the TERMSESS dataset.

Thanks to Luc Gariepy, Regie des Rentes du Quebec, CANADA.

Change 18.192 MXG 18.05-18.06 only INPUT STATEMENT EXCEEDED RECORD. The

VMAC16 +6 before ICEOTBKF should have been +2.

Aug 16, 2000

Thanks to Shabida Khan, Royal Bank, CANADA.

Change 18.191 PSBNAME, added by Change 18.083A was blank because it was

VMACCIMS inserted in the wrong KEEP= list. It should have been

Aug 16, 2000 immediately before _KIMFTRX instead of _KIMFPGM so it

is kept in CIMSTEMP instead of CIMSPROG.

Thanks to Tammy Wellstood, Clarica, USA.
Change 18.190 Year 2000 support for BMC CICS Manager data segments in

IMACICBB type 110 records was incorrect, causing year to be 2020

Aug 15, 2000 instead of 2000. Change 15.179 had never been

tested with Y2K data, and its change was incorrect for

each of its six datetime variables.

Thanks to ???, ???, EUROPE.

Change 18.189 If you had the same name for both a Service Class and a

TRND72GO Reporting Class, TRND72GO lumped them together. Adding

Aug 12, 2000 variable RPRTCLAS at the end of the SUMBY= now separates.

Thanks to Mike Schwencer, Banner Health, USA.

Change 18.188 CICS type 110 Journal (Subtype 0) with GLRHTYPE=2 caused

VMAC110 an INPUT STATEMENT EXCEEDED RECORD error. The statement

Aug 11, 2000 IF CLUPRLE GT 0 THEN INPUT +CLUPRLE @; should not have

been there, and has been deleted (those bytes are read by

the included exit member and the double read were wrong).

Thanks to Shoab Kamran, U.S. Postal Service, USA.

Change 18.187 Support for APAR OW43854 adds new fields to SMF type 62

VMAC62 VSAM OPEN and especially to the SMF type 64 VSAM CLOSE

VMAC64 record, finally adding the OPENTIME of the VSAM file, so

Aug 9, 2000 it is no longer necessary to merge 62 and 64 just to get

the OPENTM duration of a VSAM file! New ACB bits are

also decoded; these variables are added to TYPE64:

ACBMACR4='ACBMACRF*BYTE*FOUR'

OPENTIME='DATETIMESTAMP*WHEN THIS*FILE WAS*OPENED'

OPENTM ='DURATION*THIS FILE*WAS OPEN'

SMF64FG1='MISCELLANEOUS*FLAG*ONE'

SMF64RSC='SMB*INFORMATION'

SMF64SMB='SMB*ACCESS*BIAS*INFORMATION'

ACBBWO ='ELIGIBLE*FOR BACKUP*WHILE*OPEN?'

ACBCCT ='CONTROL*CHARACTER*TYPE?'

ACBJES ='OUTPUT*AND*JES*?'

ACBNLEX ='NO LSR*EXCLUSIVE*CONTROL?'

ACBRLS ='RLS*PROCESSING?'

ACBSNP ='SNP*OPTION?'

-TYPE62 was also enhanced: the OPENTIME variable was added

and all four ACBMACRx bytes were added, so all of the MXG

ACBxxxxx variables in TYPE64 now also exist in TYPE62.

-The new data fields were added compatibly, using either

previously reserved fields or added at the end.

Dec 2005 note: APARs OW45393 and OA03866 reference the

"new" OPENTIME field, but they were already supported and

no additional code changes were needed for those APARs.

Change 18.186 An extra observation in PDB.STEPS can result if a step

BUILD005 with multiple TYPE30_4 records (MULTIDD='Y') has some of

BUIL3005 the records in today's SMF file and the rest are at the

Aug 9, 2000 start of tomorrow's SMF file, i.e., when MULTIDD='Y' step

records are "spun" today and re-introduced tomorrow.

Fortunately, that extra observation has zeroes in all of

the resource variables, so there is no real impact, but

it should not have been created, and is confusing, with

STEP=0, MULTIDD=' ' instead of MULTIDD='Y', and SYSTEM is

blank. The spun MULTIDD records (SPIN30_4) are combined

with today's new MULTIDD records (TYPE30_4) into GOOD30_4

which is then sorted for its SET with GOOD30_5 to create

STEP number, but that sort of GOOD30_4, did not ensure

that the real MULTIDD=' ' step record was always first.

If any spun records with MULTIDD='Y' were physically

before the real MULTIDD=' ' step record, they created the

extra STEP=0 observation!
The original BY list of READTIME JOB JESNR SORTTIME (with

SORTTIME=INITTIME of the step) was expanded to now be by

READTIME JOB JESNR SORTTIME MULTIDD DESCENDING EXTRADD

as this forces the real step record to be first, and also

sequences the MULTIDD='Y' in the order they were written,

by that addition of DESCENDING EXTRADD to the BY list.

Variable RDRTM was removed for the TYPE30_4 keep list, as

it exists only in the TYPE30_1 and TYPE30_5 datasets.

Thanks to Mat Elbersen, Rabobank, THE NETHERLANDS.
Change 18.185 NETVIEW SMF 39 record with invalid ROUTE segment caused

VMAC39 INPUT STATEMENT EXCEEDED RECORD LENGTH. The record looks

Aug 9, 2000 like it was overlaid starting in the SCS section with the

LSESCOSA filed, thru the APPN and ROUTE segments. MXG

added test to INPUT only if there is enough data left in

the record, while investigating the cause of the record.

Thanks to Bruno Peeters, Dexia Bank, BELGIUM.
Change 18.184 Datasets TYPE7 and TYPE23 are now automatically created

BUIL3001 in your PDB library by BUILDPDB/BUILDPD3 programs. The

BUIL3606 PDB.TYPE7 dataset will have observations only if there

BUILD001 was a loss of SMF records. The PDB.TYPE23 dataset has

BUILD002 one observation per SMF interval with the activity to the

BUILD606 SMF datasets, and is useful in tracking down the cause of

BUILDPDB any TYPE7 SMF Data Lost events. Both are very small.

BUILDPD3 Note: if you tailored BUILDPDB to add either of these two

Aug 9, 2000 datasets, you must back out your tailoring in the members

EXPDBINC, EXPDBVAR, EXPDBCDE, and EXPDBOUT.

Change 18.183 The EREP Symptom Record was output to EREPSIM instead of

VMACEREP to EREPSYM; the _EERPSIM in line 2680 should have been

Aug 9, 2000 _EERPSYM.

Thanks to Peter Webber, CIS, ENGLAND.

Change 18.182 VMXGSUM enhancements - 4 major changes:

VMXGSUM -Small differences in results could be seen if INHERIT is

VMXGENG used with V8 to set the lengths of variables and bypass

VMXGINIT the second data step. VMXGSUM was modified to only use

Aug 9, 2000 the inherit option when the data step can be bypassed

Aug 26, 2000 (when no OUTCODE= or NORMx= operands are specified.)

-If TEMP01 or TEMP02 was used and they were sequential

format datasets, the MXGSUM1 and MXGSUM2 datasets were

left in place. Since this can cause subsequent uses

of VMXGSUM to run longer and a PROC DATASETS will fail

on a sequential format dataset, macro %VMXGENG now exists

to detect the ENGINE for a LIBNAME and to set the global

macro variable &MXGENG to contain the ENGINE name, so

that either a PROC DATASETS or LIBNAME DDNAME CLEAR;

LIBNAME DDNAME ENGINE; will be done to appropriately

reset the work files.

-If KEEPALL=YES is used, more WORK space may be required

because there was no KEEP= list on the MXGSUM1 dataset.

So now a KEEP= list (the UNION of all parameters sorted

with duplicates removed) is created, and this is a better

than KEEPALL=NO or KEEPIN=xxxx since it avoids all of the

resources needed to determine what variables exist.

-Significant savings can be had by avoiding the physical

I/O involved in the first data step. This is now done by

using a VIEW on MXGSUM1, but since a VIEW will not work

on a sequential format SAS dataset, the new logic detects

that a sequential engine is being used and instead uses

a data step within the INCODE instead of a VIEW.

In a test of ASUMDB2A with 1743212 OBS in input DB2ACCT

dataset the following results were attained:

CPU EXCP WORK TRACKS

Current 16.75 minutes 124805 117630

New 11.82 100178 59442
-The new %VMXGENG macro can be used to detect the engine

for a LIBNAME/DDNAME, using this syntax:

%VMXGENG(DDNAME=xxxxxxxx);

The name of the SAS engine is returned in the global

macro variable &MXGENG.

Thanks to Diane Eppestine, Southwestern Bell, USA.

Thanks to Chuck Hopf, MBNA, USA.
Change 18.181 Variable CLASS3WT was incorrect in ASUMUOW if there was

ASUMUOW any WAIT FOR IO UNDER DIFF THREAD, variable QWACARNW.

Aug 9, 2000 The count rather than duration variable was in the SUM.

Thanks to Chuck Hopf, MBNA, USA.

Change 18.180 Variable DEVTYPE now supports TRTCH values of E8x,E9x for

VMACTMS5 3590 and 3590E devices, although you must manually update

Aug 8, 2000 the TRTCH value in TMS.

Thanks to Renzo Serena, ENEL, ITALY.

Change 18.179 Variable QLACMDWT, elapsed time waiting because the max

VMACDB2 number of DBATS has been exceeded, is now input and kept

Aug 8, 2000 in DB2ACCT dataset.

Thanks to Phil Downes, ABN AMRO Bank, THE NETHERLANDS.

Change 18.178 DB2 Version 6.1 only, IFCID 106. The end of comment was

VMAC102 missing in line 11081.

Aug 4, 2000

Thanks to Harald Seifert, HUK Coburg, GERMANY.

======Changes thru 18.177 were in MXG 18.06 dated Jul 28, 2000======
Change 18.177 Report example that uses ANALCNCR and PROC TABULATE and

ANALHTML produces reports in HTML format using ODS.

Jul 28, 2000

Thanks to Chuck Hopf, MBNA, USA.

Change 18.176 Doc only. Support for APAR OW45168's minor changes to

VMAC94 SMF Type 94 were already in place in MXG.

Jul 28, 2000
Change 18.175 MXG 18.05 only. INVALID DATA FOR PHMSDATE because three

VMACIDMS debugging lines were incorrectly left. Delete the three

Jul 28, 2000 lines (1223-1226) starting IF PHMRTYPE=18 THEN ....

Thanks to Wim Desmecht, DOLMEN, BELGIUM.

Change 18.174 Documentation only. Comments in both members still had

ASMIMSL5 LRECL=132 for the IMSSUM,INQUEUE, and OUTQUEUE DD names,

ASMIMSL6 but the correct LRECLs (which are ok in the JCLIMSLx's)

Jul 28, 2000 are 136 for V5 and 144 for V6. If you used our old JCL