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

Apr 1, 2004 denominator, replacing VALDSAMP. But PCTDLTDQ, pct total

delay including batch, when there was batch queueing is

incorrect, because in that case, VALDSAMP and R723CTSA

can be major-different (R723CTSA=7, VALDSAMP=202,206!),

so the calculation of PCTDLTDQ is now based on VALDSAMP

instead of R723CTSA, to get a sensible percentage!

Thanks to Phil Baxter, CGEY, ENGLAND

Thanks to Simon Bolland, CGEY, ENGLAND.

Change 22.062 When REPORT=ALL is specified, the HTTP report abends with

ANALRMFR ERROR: FILE WORK._LTY1031 DOES NOT EXIST. The HTTP report

Apr 1, 2004 logic was not included in the "ALL" logic, but now it is.

Thanks to David Klein, DOITT - City of New York, NY.

Change 22.061 Cosmetic. VARIABLE QWGTDSC1 IS UNINITIALIZED had no

UDB2GTF impact; it was in a Debugging PUT that was not executed.

Apr 1, 2004 This UDB2GTF utility is required as a pre-step to convert

GTF 256-byte "chunks" into readable VB records, which can

then be read by MXG. The output DDNAME of UDB2GTF is

GTFOUT, so to process that converted file, you would use

%READDB2(GTF=GTFOUT,IFCIDS=ALL) to create all possible

DB2 datasets and populate those found in your data.

Thanks to George French, Liberty Mutual, USA.

Thanks to John Pierce, Liberty Mutual, USA.

Change 22.060 -The ARRAYs added in TYPETPMX in MXG 21.21 cause horrific

EXTPMACT CPU time increases, from 3 Minutes to 71 Minutes for

EXTPMAFF TYPETPMX to read 4 million SMF records (4GB), of which

EXTPMAFT only 16,000 (70MB) were TPM records. (Processing the SMF

EXTPMBFR file of only those 16K TPM records took 3 CPU minutes.)

EXTPMBND The ARRAYs were used to store the variables that can have

EXTPMBVL multiple instances (like the list of VOLSERs used), and

EXTPMDEA you had to update IMACTPMX to tell MXG the maximum number

EXTPML10 of instances of each of the arrays. The problem is that

EXTPML11 real variables were defined in each array, and that was

EXTPML12 the cause of the CPU increase; for real variables, SAS

EXTPML13 initializes each array variable before each SMF record

EXTPML14 is read. Using _TEMPORARY_ instead of real variables

EXTPML15 eliminated the CPU hit, as did removing the ARRAYs and

EXTPML16 their references.

EXTPML17 -With real variables in an ARRAY, SAS initializes every

EXTPML18 one of the variables for each new SMF record, even for

EXTPML19 the non-TPM SMF records that are skipped after their ID

EXTPML20 in INPUT and tested, before any arrays were referenced.

EXTPML21 -The only solution was to completely rewrite TYPETPMX and

EXTPML22 eliminate the use of real variable ARRAYs, and instead,

EXTPML23 create 34 new TPMxxxxx datasets, one for each variable

EXTPML24 that can have multiple instances, keeping the instanced

EXTPMLL1 variable and JOB JESNR SMFTIME SYSTEM variables so you

EXTPMLL2 can select and report, or use those key variables to

EXTPMLL3 JOIN the instanced dataset with TYPETPMX if needed.

EXTPMLL4 There is a counter variable in TYPETPMX for each of the

EXTPMLL5 instanced variables to tell you if there are instances.

EXTPMLL6 -The %LETs that you were required to update in IMACTPMX,

EXTPMLL7 which told MXG the maximum number of instances are no

EXTPMLL8 longer required and were removed ("a Good Thing"), as

EXTPMLL9 were the now-unnecessary DROP statements in the EXTYTPMX

EXTPMLLM exit member for those instanced variables. And TYPETPMX

EXTPMLMT dataset now has only 480 variables, but you may have to

EXTPMVVL revise your TPMX reports as a result of this redesign.

EXTYTPMX -Before TYPETPMX was redesigned, a circumvention was seen

IMACTPMX possible: my changing the hardcoded INFILE SMF ... in the

VMACSMF MACRO _SMF definition in VMACSMF to INFILE &SMF ..., and

VMACTPMX transparently adding %LET SMF=SMF in VMXGINIT, you could

VMXGINIT then change the INFILE name "on the fly", and could use

Apr 1, 2004 the MACFILE exit to send the TPM records to a temp file,

and then use "TYPETPMX" only against the TPM records:

// EXEC MXGSASV9

//SMF DD YOUR.SMF,DISP=SHR

//SMFOUT DD UNIT=SYSDA,SPACE=(CYL,(200,200))

//SYSIN DD *

%INCLUDE SOURCLIB(VMACTPMX); /*defines _IDTPMX*/

%LET MACFILE=

%QUOTE(

IF ID=_IDTPMX THEN DO;

FILE SMFOUT DCB=SMF;

PUT _INFILE_;

FILE LOG;

END;

);

%INCLUDE SOURCLIB(BUILD001);

RUN;

%LET MACFILE= ;

%LET SMF=SMFOUT;

%LET PTYTPMX=PDB;

DATA _VARTPMX; _SMF; _CDETPMX; RUN;

%INCLUDE SOURCLIB(BUILD002,BUILD003,BUILD004,BUILD005)

Although this specific need to change the SMF infile to

use the temporary SMFOUT file is no longer needed with

the revised TYPETPMX support, it was left in place for

possible future use.

Thanks to Richard S. Ralston, Humana, USA.
Change 22.059 New CICS/TS 2.3 Pool variables were added using reserved

VMAC110 fields in STID=60 subtype 2 SMF 110 stat record, but were

Mar 30, 2004 not input (no vertical bars in CICS Data Areas!):

Mar 31, 2004 DSGMMWTS DSGMMWTM DSGCMMWS DSGPMWWS DSGCMMWT

DSGTOTMT DSGTOTMW

DS2MMWTS DS2MMWTM DS2CMMWS DS2PMWWS DS2CMMWT

DS2TOTMT DS2TOTMW

DS3MMWTS DS3MMWTM DS3CMMWS DS3PMWWS DS3CMMWT

DS3TOTMT DS3TOTMW

These new variables measure TCB Mismatch Waits/durations

and MVS Storage Waits/durations, and are output in the

CICDSPOO datas for the three pools.

Thanks to Don Deese, (CPExpert), Computer Management Sciences, USA.
Change 22.058 -Temporary variable SHFTTIME should have been DROPed in

IMACSHFT IMACSHFT when it was added by Change 21.204; now it is

VMACTMDB DROPped so it will not be kept in any MXG dataset.

Mar 29, 2004 -Variables added to ASG Monitor for DB2 in Change 21.237

were not labeled.

Thanks to Chris Weston, SAS Institute ITRM, USA.

Change 22.057 -Support for the optional ESS fields in TYPE57J2, for JES2

VMAC57 sysout transmission between NJE nodes; the ESS variables

Mar 29, 2004 are now (optionally) created if your IMAC6ESS member has

been tailored (comment block removed) to keep them.

-Six undocumented variables SMF57C1-C3 and SMF57N1-N3 are

decoded from the 28 bytes following SMF57TUL; they will

be re-labeled if their documentation can be located.

-SMF 57 is created when sysout was sent thru this JES2 NJE

node, but it counts only the number of logical TP records

(which may or may not count actual lines or images!).

-The SMF 57 record is also created by unisys's DEPCON

(output management tool), which routes print from unisys

to the z/OS print queue. While actual lines printed may

not be available, at least the destination printer is

available, but as there is no MVS "job" that created the

output, merging with BUILDPDB for unisys print accounting

is not really possible.

Thanks to Rainer Hertwig, Lufthansa Systems Infratec GmbH, GERMANY.

Change 22.056 Q3STHWIB variable should still be good; UNINIT Q3STHIWB

VMACDB2 note caused by a typo, but code is executed only if field

Mar 26, 2004 wrapped, and the next interval's Q3STHIWB value is valid.

Thanks to Lori A. Masulis, FMR, USA.

====== Changes thru 22.055 were in MXG 22.02 dated Mar 24, 2004=========
Change 22.055 TYPE42DS variable AVGIOQMS=RESP-PND+DIS+CON+CUQ is often

VMAC42 a negative 0.128 milliseconds, which is one clock tick in

Mar 24, 2004 the type 42 "clock", and AVGIOQMS is at best an estimate

of an average value. Since this is a calculated value,

rather than a value in an SMF record, I think it wise to

just set these negative values to zero, and document what

I've done here, so you don't get sidetracked by the small

negatives; the max AVGIOQMS was 902 Millisec/SIO.

Thanks to Ron Alterman, PGE, USA.
Change 22.053 Cosmetic. The MXG-created character variable CPCFNAME

VMXGRMFI was inconsistently built, sometimes with a dash 2064-2C8,

VMXG70PR sometimes without, 20642C8. It now always has the dash.

Mar 24, 2004

Thanks to Kenneth D. Jones, xwave, CANADA.
Change 22.052 PDB.STEPS can have some EXCP, IOTM, TAPEDRVS, TAPNMNTS

BUILD005 and TAPSMNTS counts from one step of a job output in the

BUIL3005 previous step of that job, if both steps have exactly the

VMAC30 same INITTIME: the first step was FLUSHED (condition code

Mar 23, 2004 bypass), so it was never initiated, nor allocated, nor

executed), AND, the next step initiated instantaneously,

without any delay, in the same 10 millisecond clock tick.

MXG's BUILDPDB logic was revised to use INITTIME STEPNR

instead of INITTIME to separate the two steps, so these

I/O counts are now output in the correct PDB.STEPS obs.

While I/O counts were in the wrong PDB.STEPS observation,

the values were correct, so the PDB.JOBS observation did

have the correct total I/O counts for the job (although

the TAPEDRVS count could have been incorrect). Also, in

PDB.STEPS the STEPNR was not equal to variable STEP (but

that is normal for restarted jobs, as STEP is a counter

of steps executed, and restarted jobs will have multiple

instances of the same STEPNR with different STEP values).

-Member VMAC30 had to be changed to add STEPNR to KEEP=

list for the TYPE30TD dataset.

Thanks to John R. Parla, CIGNA, USA.

Thanks to Ray Dunn, CIGNA, USA.

Thanks to Paul E. Cohen, CIGNA, USA.
Change 22.051 The Multi-System Remote Enclave CPU segment is 80 bytes

BUILD002 instead of the 20 bytes documented in SMF; I have guessed

VMAC30 what some of the fields contain, but the MRENxxxx names

Mar 22, 2004 will likely be changed when I understand what's what.

Mar 24, 2004 But assuming the data is eventually valid, I have added

Jan 12, 2005 _STY30MR to the BUILD002 so that PDB.TYPE30MR will now be

automatically created in the PDB library in BUILDPDB/PD3.

-Jan 12, 2005: This Change was COMPLETELY wrong; the code

was completely revised by Change 22.345, with correct

SMF30MRx variable names.

Thanks to Chuck Hopf, MBNA, USA.
Change 22.050 IRD caused wrong PCTCPUBY in TYPE70 and RMFINTRV datasets

VMAC7072 for intervals in which engines were varied offline. The

VMXGRMFI MXG support for IRD should now be complete; it was added

Mar 22, 2004 in these increments for these "CPU-measuring" datasets:

Datasets When MXG Version Change

ASUM70PR/ASUMCEC Sep 22, 2003 21.05 21.170

TYPE70PR Mar 11, 2004 22.01 22.011

TYPE70,RMFINTRV Mar 22, 2002 22.02 22.050

MXG accumulated CPUWAITM for each engine only when it was

online at the end of interval (CAIx='01'B), but when IRD

varies an engine CAIx='11'B, so CPUWAITM for that engine

was not added, causing CPUACTTM and PCTCPUBY both to be

too large. Now, CPUWAITM is accumulated if SMF70ONT is

non-zero (i.e., the engine was used, a stronger test).

-An unrelated error in the first RMF interval after an IPL

was also detected and corrected. The first records have

their interval DURATM greater than SMF70ONT, but CAI0=01

so engines were not varied off. For one IPL, the 25 sec

difference caused PCTCPUBY and CPUACTTM to be NEGATIVE!

These first interval records have short DURATM because

RMF is synchronizing with time of day:

IPL TIMESTAMP STARTIME DURATM SMF70ONT

22FEB04:02:15:05.95 02:19:12.00 0:09:47.39 0:09:24.26

22FEB04:02:22:46.45 02:26:59.00 0:02:00.63 0:01:35.19

22FEB04:01:28:39.42 01:31:52.00 0:12:07.05 0:11:39.81

I conclude that RMF starts to count DURATM before engines

are available for use, so MXG now uses SMF70ONT (if it is

non-zero) instead of DURATM to correct IBM's error.

-Variable CPUPDTTM is added to PDB.RMFINTRV. (It was the

validation of this user request that exposed the prior

MXG error!).

Thanks to Kenneth D. Jones, Xwave, CANADA.

Change 22.049 Variable TMNTUSER added to the Mount record is actually

VMACTMNT the existing LOCLINFO variable (in all JOB-related SMF

Mar 21, 2004 records), so TMNTUSER variable no longer exists.
Change 22.048 If SPF Statistics are enabled, the MXG.SOURCLIB PDS will

JCLINSTL now require 1199 directory blocks; JCL examples with 999

JCLTEST9 blocks were increased to 1199. Without SPF statictics,

COVERLTR only 399 blocks are required.

Mar 21, 2004

Thanks to Peter Giles, Centrelink, AUSTRALIA.

Change 22.047 -Datasets QAPMTCP and QAPMIFC were not automatically built

TYPEQACS by TYPEQACS/TYPSQACS, so they were not listed in DOCVER.

TYPSQACS -Variables PCTCPUBY NRCPUS were not labelled in QAPMSYSL.

VMACQACS -Variable INTSEC was not kept in QAPMTCP nor QAPMIFC.

Mar 21, 2004

Thanks to Chris Weston, SAS ITRM, USA.

Change 22.046 %VMXGTIME was invoked before SYSTEM had been input in two

VMACRMFV places; the %VMXGTIME and IMACSHFT invocations were moved

Mar 20, 2004 to below the INPUT of variable SYSTEM.

Thanks to Michael Oujesky, MBNA, USA.

Change 22.045 Dataset PDB.DB2STATB was not protected for wrap of 4-byte

VMACDB2 counters, which caused negative values in variables like

Mar 20, 2004 QBSTDPP,QBSTGET,QBSTRIO,QBSTSGT,QBSTSPP,QBSTSWS, all of

which can have very large raw values before their DIF().

All other DB2 variables that are DIF()'d were protected.

This error was introduced in Change 21.140 when DB2STATB

was restructured and I forgot to protect for wrapping.

Thanks to Ron Alterman, PGE, USA.

Change 22.044 The %%INCLUDE SOURCLIB(VGETJESN) should have been only

ANALEPMV one %INCLUDE SOURCLIB(VGETJESN) because it is inside a

Mar 18, 2004 %MACRO statement; two are needed inside MACRO statements.

Thanks to David Klein, DOITT - City of New York, NY.

Change 22.043 APPL records with or without the nine APPRM variables are

VMACMWUX supported in a heuristic test for LENGTH LE/GT 565, based

Mar 18, 2004 on 535/536 length without, 594/595 with, in test data.

Thanks to Miguel Fernandez, Information Services International, USA.

Change 22.042 DB2 Statistics SMF 100 Subtypes 0, 1, and 2 have always

VMACDB2H been written to SMF in order, but because their QWHSSTCK

Mar 18, 2004 datetime values could be fractions apart, I retained STCK

from each 0 into its 1 so DB2STAT0 and DB2STAT1 had the

same value in QWHSSTCK, so they could be MERGEd to create

DB2STATS directly. But now, one site's DB2 6.1 SMF 100

records are completely out of order, with subtype 0 with

an earlier STCK written after that interval's subtype 1

with a later STCK value, and MXG's algorithm to create a

common QWHSSTCK value created this ERROR message:

DB2 TYPE 100 SUBTYPE 1 FOUND AT START OF INPUT FILE.

The error corrupts the DB2STATS0,DB2STATS1 and DB2STATS

datasets; QWHSSTCK will have wrong values, and subtype 1s

from one interval may be merged with subtype 0 from next

interval in the DB2STATS dataset, and negative values in

DB2STATB dataset may result when this message is printed.

-The QWHSSTCK logic now recognizes the start of interval

as a delta of 10 seconds, and the first record's STCK is

now stored in QWHSSTCK for all three STAT subtypes.

-It's only a guess as to why this has not been seen before

but it may be the "tactical" interval of one minute that

exposed the error; for whatever reason, it is now clear

that each of these subtypes are created by independent

subtasks, so their physical writes are not in any order,

and my ASSUMEption of order was wrong.

Thanks to Ron Alterman, Pacific Gas and Electric, USA.

Change 22.041 If you EXCLUDEd variable OPERATOR or TERMINAL in CICS SMF

ASUMCICS and if you used ASUMCICS (which we no longer recommend)

Mar 17, 2004 to create PDB.CICS, the length of OPERATOR and TERMINAL

are now $1, but they were $4 in previous versions. This

can cause a warning if you combine PDB.CICS datasets in

your MONTHBLD that were built with two different versions

of MXG. This change restores the length to $4 for both.

See Change 21.xxx on why ASUMCICS may not be the

right program to use.

Thanks to Gary Keers, AES, USA.

Change 22.040 The ANALALL example, which selects all SMF records from a

ANALALL JOB(s), creates all MXG datasets from those SMF records,

Mar 17, 2004 and then prints all observations and all variables, can

also be used to create an SMF output VBS file with all of

the selected SMF records. Comments in the member show

how to add

FILE SMFOUT DCB=SMF;

PUT _INFILE_;

FILE LOG;

after the IF JOB=: selection in %LET MACJBCK=, and how

to add an //SMFOUT DD statement for those records.

Thanks to Alex Puno, LACO, USA.

Change 22.039 If you use the _N42 macro to null data set creation, the

VMAC42 _WTY4237 null definition was missing; it has been added.

Mar 16, 2004

Thanks to Jon Whitcomb, Great Lakes Educational Loan Services, USA.

Change 22.038 ML-31 of the Exit-Based MXG Tape Mount, Allocation, and

ASMTAPEE Allocation Recovery monitor corrects GMT timestamps that

Mar 15, 2004 should have been on the local clock, and supports an IBM

Mar 25, 2004 MSC APAR that changed bit meanings. The MXGTMNT DIAG

command provides additional diagnostics in its WTO text,

but will also write a "dump" to a file (for sites where

taking a "system dump" is political issue), if there is

an MXGDUMP DD included in the monitor program's JCL:

//MXGDUMP DD RECFM=FB,LRECL=4160,BLKSIZE=4160,

// UNIT=SYSDA,SPACE=(CYL,(100,100)),

// DISP=(,CATLG),DSN=YOUR.CHOICE

The DIAG command is issued from a console:

F jobname,DIAG

where jobname is the "job" name of the MXGTMNT monitor.

-The IBM IEF-VOLUME-MNT exit in our Exit-Based logic is

not called by StorageTek's HSC software, so you will NOT

see any mount records with HSC with MXIT=YES in ML-31.

Now that we've examined the dump and saw that STK did not

call the IBM exit, and knew who/what to ask, STK has been

very cooperative in providing documentation of HSC, so I

believe it is only a matter of time (weeks?) before our

"[e-mail]" will develop the needed enhancement to

support both HSC and IBM tape mounts with MXIT=YES.

April 1, 2004.

Change 22.037 Support for NetMaster subtype 5000x record, Performance

EXNETM50 Monitoring record.

IMACNETM

VMACNETM

VMXGINIT

Mar 24, 2004

Thanks to Andy Creet, Department of Defence, AUSTRALIA.
====== Changes thru 22.036 were in MXG 22.01 dated Mar 11, 2004=========
Change 22.036 The MG070CP format, used only if you are still on OS/390,

FORMATS or running z/OS on a non-zSeries machine, was updated for

Mar 11, 2004 the 2066-E1 and 2066-X2 processors.

Thanks to Al Sherkow, I/S Management Strategies, Ltd., USA.

Thanks to Edward Ogonosky, Blue Cross Northeast PA, USA.
Change 22.035 The z/VM MONWRITE "User" dataset, VXBYUSR, was left in

VMACVMXA the //WORK file and was not written to the //PDB, but now

VMXGINIT is; this is the dataset with interval data for each CMS

Mar 11, 2004 "user", i.e., each VM Machine, and is THE dataset to use

to track individual Linux-under-VM machine activity. Only

the default output "DDname" was changed.

Thanks to Reinhard Kelm, GAD, GERMANY.
Change 22.034 -Support for Candle optional CANADABN and CANADABT fields

IMACICD4 (for Adabas Count/Duration variables of same NAME) is

IMACICD5 added. UTILEXCL will detect and tell you to open the

UTILEXCL comments in the appropriate IMAC, if fields exist in your

VMAC110 CICS SMF 110 records, with Candle's additions.

Mar 10, 2004

Thanks to James Hein, Erie Insurance, USA.
Change 22.033 -Support for XIDTYP='A' ADAPATER record in new QAPMIOP5

EXQAPIO5 dataset.

IMACQACS -Correction for LRECL=359 QAPMIOPD record which has an

VMACQACS extra byte betwen XIDTYP and XIDTA1.

VMXGINIT

Mar 10, 2004

Thanks to Stan Dylnicki, Royal Bank of Canada, CANADA.
Change 22.032 Support for Endeavor Release 4.0 user SMF (INCOMPATIBLE,

VMACENDV because ELEMT, DSNAME, and DSMEM fields were relocated.

Mar 10, 2004 The Action Record (subtype 2) has been validated with

new data; the Block Header's record version had to be

used to identify the new format record because C1VER was

not changed (only has before/after 2.5), and SM2RECVN is

'01' in the new records. The Security Record (subtype 2)

also had incompatible changes, and has been coded, but no

subtype 1 records have been validated. The DSECT shows

a subtype 3 (ESI Exception) and a subtype 4 (MCF CHANGES)

but there is no sub-DSECT for those records; if a 3 or 4

is found, MXG will print one record on the log.

Thanks to John Paul, Highmark, USA.
Change 22.031 The ASUMJOBS logic calculated the Initiation Wait Time as

ASUMJOBS IWT=INITTIME-JRDRTIME, but JRDRTIME is only in the Purge

Mar 9, 2004 record, so a PDB.JOBS observation that did not have a

Purge record (probably because member IMACSPIN had not

been tailored to change MXG's SPINCNT=0 default) had a

missing value for JRDRTIME, causing IWT to be missing.

This caused the summarized observations in PDB.JOBSKED to

have incorrect bucket percentages because IWT missing was

counted as a zero-wait job. It also caused IWT (summed)

to be equal to IWTMAX in some obs that had NUMJOBS more

than one (but closer examination showed that these case

actually had had only one job with non-missing IWT!).

The IWT calculation was revised; if JRDRTIME is missing,

IWT=INITTIME-SUM(READTIME,RDRTM) is used, as those data

are in the JOB Termination record. And if the IWT is

still a missing value, that job will be deleted.

Thanks to Miguel F. Montferrer Carvajal, RSI EDS, ESPAGNE.
Change 22.030 Support for DF/SMS Storage Class Exit User SMF record,

EXSMSXSC written at Storage Class assignment, so you can examine

FORMATS how your ACS rules actually perform. New dataset:

IMACSMSX dddddd Dataset Description

TYPESMSX SMSXSC IGDACSSC DF/SMS STORAGE CLASS EXIT

TYPSSMSX I arbitrarily only output the first six VOLSERS of the

VMACSMSX possible 1464 volumes that a dataset can have, until

VMXGINIT someone needs all of them!. I was unaware of that limit.

Mar 9, 2004

Thanks to Tobias Cafiero, Depository Trust and Clearing Company, USA.

Change 22.029 Support for new SMF 117 record from WBIMB, WebSphere

EX117FLO Business Integration Message Broker creates four new

EX117THR datasets:

EX117NOD dddddd Dataset Description

EX117TRM 117FLO S117FLOW MESSAGE FLOW

FORMATS 117THR S117THRD THREAD

IMAC117 117NOD S117NODE NODE