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

EXMONTFF variables will have missing values. New fields were added

EXMONTJ to many existing datasets, and new records are supported.

EXMONTK Since every record and subtype was touched, MXG support

EXMONTKM for TCE was enhanced with all the MXG bells and whistles:

EXMONTKP duration variables are formatted TIME13.3, storage and

EXMONTN byte-containing variables are formatted MGBYTES, etc., to

EXMONTO both "print-pretty", and to document what data is stored

EXMONTOS in which of these hundreds of new variables.

IMACTMO2 The new PA/PI records capture IBM CICS Monitor Facility

VMACTMO2 data at the transaction and interval level, and the new

VMXGINIT TK Dispatcher Record provides CPU time for each CICS TCB.

Status: TA,TD,TI,TP,TR,TS, TX, and T2 records were all

Apr 28, 2002 changed, some new variables, some dropped.

May 1, 2002 TF was so changed that new MONITF/MONITFF datasets are

May 5, 2002 created for TF records with Release 2.1.

New PI,PA records create MONIPI/MONIPA with massive

numbers of new variables.

New TJ for Java, TN for Enqueues, and TO records for

Sockets create MONITJ, MONITN, MONITO and MONITOS, for

a total of 11 new datasets and hundreds of variables.

PTF TCE3400-21 changes were added May 5.

This complete rewrite took three full days to write and

validate (thanks to a full suite of test records from

Landmark, and nearly accurate documentation); over 3000

lines of code were added by this change.

Thanks to Martin Jensen, JyskeBank, DENMARK.

Change 20.071 The JCL example (Testing MXG under SAS Version 8) still

JCLTEST8 MXGSAS instead of MXGSASV8 as its JCL procedure name.

Apr 28, 2002 Also, the example suggests REGION=80M for installations

that restrict the use of REGION=0M.

Thanks to Donald J. Likens, AON, USA.
Change 20.070 New IBM Product, NPM/IP user SMF record, is supported.

EXNPIP01 Two datasets are created from the two subtypes:

EXNPIP02 DDDDDD Dataset Description

IMACAAAA NPIP01 NPMIP01 Performance Record - each observation

IMACNPIP measures the round trip response time

TYPENPIP for one of four packet sizes to a

TYPSNPIP specific IP address.

VMACNPIP NPIP02 NPMIP02 Workload Record - accumulated bytes

VMXGINIT from an application to an ip address.

Apr 28, 2002 Records must be deaccumulated (use

TYPSNPIP or _SNPIP in your EXPDBOUT)

to create interval duration and bytes

sent/received during each interval.

To minimize the size of PDB.NPMIP02,

observations are created only for

intervals with non-zero bytes.

Many duplicate SMF records were

found, but MXG logic deletes them;

IBM will be contacted to fix or to

explain their duplicate records:

Subtype 2 records in SMF: 29762

duplicate records removed: (14407)

unique subtype 2 records: 15265

MXG obs in PDB.NPMIP02: 6963

Updated 2Jan03: APAR OW56033 reports duplicate records

were cut by the "AESTNETS" task's AEST044 program, and

provides the PTF to correct that error.

Thanks to Sue Kemper, Universal Music Group, USA.

Change 20.069 Support for APARs OW52227 and OW51848 for z/OS 1.2, adds:

VMAC7072 -New variables to TYPE72GO dataset (type 72 subtype 3):

Apr 26, 2002 New wait state sample counts (SSL Thread, Regular Thread,

Registration to Work Table, R723RWST/RWRT/RWWR), and new

"Active Application State" sample count, R723RAPP, that

indicates there is a program executing on behalf of a

work request, from the perspective of the WLM (this does

not mean that the program is active from the BCP's

perspective), so RMF reports can distinguish between

active subsystem and active application; from APAR text:

Before this APAR, state samples were reported as percent

of response time, calculated when a transaction ends,

which could cause values over 100% when samples for long

running transactions were included that did not complete

in the RMF interval. With OW52227, the problem is solved

by showing the single states as percentages of total

state samples, instead as percentages of response time.

This eliminates percentages over 100% in the BREAKDOWN

section. Thus the RESPONSE TIME BREAKDOWN is replaced

by a STATE SAMPLE BREAKDOWN, and the STATE SWITCHED TIME

is replaced by a STATE SWITCHED SAMPL(%) breakdown. Only

the TOTAL column will be kept as percentage of response

time, which is the current view; however, the field name

will be changed to RESP TIME(%).

The APAR text contains a numeric example of the change

in the values printed with and without OW52227.

The APAR also states that the RMF III SYSWKM Report has

changed the meaning of ACT (Active State); in addition

to the time spent in an active subsystem state, it also

contains the time spent in an active application state,

if that information is provided by the subsystem, for

example, WebSphere.

The APARs also now count delays for service classes with

goal types other than response time goals, and count

delays for multi-period service AND report classes.

This MXG change adds the new variables to TYPE72GO data.

A later change to ANALRMFR will detect OW52227 and will

use R723RAPP to match IBM calculations, when test data

is available for validation.

The associated OW51848 added the new function that allows

Performance Block (PB) state reporting for enclaves. Now,

report-only PBs can be associated with an enclave or an

address space in a service class with multiple periods.

(Previously, a PB could only be associated with an ASID

that was in a Service Class with a response time goal.)
-The APAR documents that the new delay and sample counts

are also added to RMF III VSAM ERBRCDG3 segment, but that

segment is not yet supported in MXG's VMACRMFV, because

no one has yet sent sample data records to be decoded.

Change 20.068 Significant user contribution enhances the MXG RMF III

ASMRMFV support. This change is the last part of Change 20.033.

VMACRMFV -ASMRMFV, the program that reads the RMF III (compressed)

Apr 26, 2002 VSAM file to create the RMFBSAM flat file that is then

read with MXG's TYPERMFV, originally had hardcoded LRECL

of 800 bytes, but IBM now writes 1500 byte records that

were truncated by the original program. This revision

sets DCB to RECFM=VBS,LRECL=32756,BLKSIZE=0, which will

support any future record length. VBS is used (instead

of VB) so that half-track DASD will be allocated and DASD

space won't be wasted by the output flat file.

-VMACRMFV was enhanced to create variables SHIFT, SYSTEM

and SYSPLEX in all datasets, added SSHTIBEG/SSHTIEND to

datasets that did not contain them, corrected four vars

(GEIESPMB/SPME/SMRB/SMRE) to be input with RB instead of

with informat PIB, creates PCTLOGBY and PCTCPUBY vars as

percents of logical and physical CPU busy, added labels,

and corrected typos and spelling errors! Whew!

Thanks to Jerry Urbaniak, Acxiom CDC, USA.
Change 20.067 z/VM datasets VXBYUSR, VXSUMUSR, VXBYCPU, VXSUMCPU, and

TYPSVMXA VXBYTIME were not copied into the PDB library when the

Apr 26, 2002 TYPSVMXA member was used to SORT all datasets into the

PDB library. These summary datasets are built from the

other datasets, so they are now copied with a PROC COPY

that was added at the end of TYPSVMXA.

Thanks to Pat Curren, SuperValu Inc, USA.
Change 20.066 New datasets TYP120JC and TYP120JI were created in the

VMAC120 //WORK file, but their _ST120JC/_ST120JI Sort macros were

Apr 26, 2002 not invoked inside _S120, so they were not sorted into

the PDB library by TYPS120 nor when _S120 was invoked.

Thanks to Pat Curren, SuperValu Inc, USA.
Change 20.065 Support for BMC MAINVIEW FOR CICS 5.4 CMRDETL file, which

VMACMVCI was completely and incompatibly changed. Release 5.5 only

Apr 24, 2002 added two fields in reserved fields; both are supported.

Apr 30, 2002

Thanks to Ermanno Bertolotti, INTESABCI, ITALY.
Change 20.064 The example to send email from an MVS SAS job should have

EMAIL spelled the option EMAILSYST as EMAILSYS, without that

Apr 15, 2002 "T".

Thanks to James A. Monahan, National Grid USA, USA.

Change 20.063 Boole/BMC CIMS/IMF CIMSTRAN dataset variables CTCKPTNTS,

VMACCIMS MAXLOCKS, and TOTLOCKS were input but not kept; now they

Apr 15, 2002 are kept in dataset CIMSTRAN.

Thanks to Siegfried Trantes, IDG mbH, GERMANY.

Change 20.062 STARTIME in TNG datasets was an hour earlier than actual.

VMACTNG I originally assumed the "hour" was the hour of end of

Apr 12, 2002 the data, and used STARTHR-1 to set the ORIGTIME to the

previous hour. But the hour really is the START hour of

the data, so the two STARTHR-1 were changed to STARTHR.

Thanks to Erling Andersen, SMT Data A/S, DENMARK.

=======Changes thru 20.061 were in MXG 20.01 dated Apr 11, 2002=========
Change 20.061 UTILEXCL recognized and reported "UNKNOWN FIELD" but did

IMACICD1 not build correct logic in IMACEXCL to skip over the data

IMACICDA so the CICSTRAN dataset was invalid, strange dates, etc.,

UTILEXCL if that "POTENTIALLY SERIOUS ERROR" message was printed

VMAC110 when you executed UTILEXCL. The particular unknown field

Apr 11, 2002 CANPROD1 perhaps is the last CICS field to be supported.

This change corrects UTILEXCL to properly skip over any

future unknown CICS segments, and supports the CANPROD1

segment, creating the 4-byte variable CANPROD1.

Candle describes CANPROD1 as "Internal, used to provide

statistics for VSAM, DL/1, IDMS, ADABAS, SUPRA, and

DATACOM. Used to provide Application Trace Statistics.

Thanks to Hailin Wu, Cover-All, CANADA.
Change 20.060 SAS V6 Only, Warning. Labels added in Change 20.05x were

VMXG70PR longer than V6 limit of 40 bytes; non-fatal.

Apr 11, 2002

Thanks to Freddie Arie, TXU, USA.

Change 20.059 With UTILEXCL created IMACEXCL, STRTTIME/ENDTIME were not

UTILEXCL converted to Local Time if your GMT offset was non-zero,

Apr 10, 2002 and variable CPUTM was not populated. Both are corrected.

Thanks to Raff Rushton, Kaiser Permanente, USA.

=======Changes thru 20.058 were in MXG 20.01 dated Apr 9, 2002=========
Change 20.058 DB2 report PMSQL02 had missing TCB time values for two

ANALDB2R trace events (62058 and 59058) due to carry-down typos.

Apr 9, 2002 The CPU=S058UCPU-S066UCPU; is now CPU=S058UCPU-S062UCPU;

and CPU=S058UCPU-S066UCPU; is now CPU=S058UCPU-S059UCPU;

for those trace events.

Thanks to Frank d'Hoine, Nationale Bank van Belgie, BELGIUM.

Change 20.057 -The daily NT PDBs are no longer all deleted when the WEEK

BLDNTPDB NT PDB is built, in keeping with the MVS BUILDPDB design,

Apr 9, 2002 so that you can read FRI's PDB on TUE without reading the

entire past-week's WEEKLY PDB.

-The RERUN parameter now works, but is subject to this

exposure that requires intelligent manual intervention:

If RERUN is used and it happens to be the day of the

week that is specified for running of the weekly or

the monthly, those programs will automatically be run.

Turn off the weekly and/or monthly options with RERUN,

and then evaluate what restores may be needed before

you can rerun to build weekly or monthly.

Thanks to Terry Heim, Ecolab, USA.
Change 20.056 Enhancements for MSU-based Capacity Measurement for IRD

VMAC7072 (z/OS Intelligent Resource Director, see Change 20.046):

VMXG70PR -Variable SMF70BDA,SMF70CSF,SMF70ESF, and SMF70MSU are now

Apr 8, 2002 corrected in dataset PDB.TYPE70PR; they were zero because

I used early doc and missed document revisions at GA.

-Variable SMF70CPA is kept into TYPE70PR from the TYPE70

segment, so the MSU can be calculated later in ASUM70PR

and ASUMCEC - see Change 20.046 equation.

-Both PDB.ASUM70PR and PDB.ASUMCEC now contain six new

variables for each LPAR:

LPnBDA ='LPAR n*AVERAGE*LOGICAL*CPUS*SMF70BDA

LPnMSU ='LPAR n*INTERVAL*MSU*COUNT

LPnMSUHR='LPAR n*INTERVAL*MSU*AS HOURLY*RATE

LPnMSU70='LPAR n*MSU*DEFINED*CAPACITY*SMF70MSU

LPnONT ='LPAR n*LPAR*ONLINE*DURATION*SMF70ONT

LPnWST ='LPAR n*LPAR*WAIT STATE*DURATION*SMF70WST

and three new variables for totals:

MSULICEN='SUM OF*LICENSED*MSU CAPACITY*OF ALL LPARS'

MSUTOTAL='TOTAL*MSU*DELIVERED*TO ALL LPARS'

MSUPERHR='HOURLY*MSU RATE*DELIVERED*TO ALL LPARS'

-SMF70BDA is usually equal to LPARCPUS, and sometimes is

slightly less, showing that IRD seems to be working,

but it does not seem to be useful to calculate any of

the LPAR utilizations.

-SMF70ONT (LPAR Online Time) and SMF70WST (LPAR Wait State

Time) are summed for each LPAR in ASUM70PR/ASUMCEC, but

are also still not understood for these 5 LPAR's data:

LPAR LPnDUR LPnUPDTM LPnBDA LPnONT LPnWST

1 2:15:00 0:19:06 9 2:15:00 0:51:50

3 2:15:00 0:12:02 9 2:15:00 1:07:33

5 0:15:00 0:00:00 1 0:15:00 0:00:00

7 2:15:00 0:08:23 8.37 2:05:36 1:32:51

14 2:15:00 0:04:12 8.40 2:06:07 1:43:43

Total+Phys: 0:46:24 ==> 34.3% busy, 9 engines, 15 min.

-I note that the only place where IBM records their 4-hour

rolling average MSU is in the TYPE70 data for each MVS in

variable SMF70LAC, but IBM does not calculate that value

in the PR/SM data for each LPAR. The MXG calculation of

the rolling average MSU4HRAV is in the PDB.RMFINTRV data.
Change 20.055 The Group Buffer Pool GBPxxxxx variables in DB2ACCTG (for

VMACDB2 each pool) and their sum in DB2ACCT have never been right

Apr 5, 2002 if more than one GBP was used; MXG repetitively input the

first segment. Adding OFFGBP=OFFGBP+LENGBP; and removing

the unused SKIP logic corrects the error.

Thanks to Warwick Robinson, National Westminister Bank, plc, ENGLAND.

Change 20.054 -The optional CICS User segment is now the last segment in

IMACICDA the default order in member IMACICDA, as was intended and

IMACICMR as is documented. If you have your own IMACICDA, it will

UTILEXCL still input the CICS segments in your chosen order. If

VMAC110 you use member UTILEXCL to create IMACEXCL, IMACICDA is

Apr 4, 2002 not used, so this has no impact there.

-The optional CICS CMRDATA segment from Mainview is now

supported in member IMACICMR, and UTILEXCL now knows of

that member for that optional data for its notes to you.

-VMAC110 was updated with the optional CMRDATA variables.

Thanks to Helgund Linck, BASF-IT-Services, GERMANY.
Change 20.053 Mitchem ACC/SRS support corrections. The offset was INPUT

VMACACC into variable SRHPHL, but references spelled it SHRPHL,

Apr 4, 2002 so ASHxxxxx variables were not INPUT. MSGLENGTH was 3

bytes short when SRHPHL was present. And so that this

member will execute correctly under ASCII SAS, INPUT()

and TRANSLATE() functions were added (because

EBCDIC-containing variable MESSAGE must be INPUT with

$VARYING informat).

Thanks to Heinz-Bernd Leifeld, Provinzial Rheinland Versich., GERMANY

Thanks to Engelbert Smets, Provinzial Rheinland Versicherung, GERMANY

Change 20.052 INSTANCE was blank if a 3-HDR records contained (*) for

VMACTNG the length of the instance field, indicating there was no

Apr 4, 2002 new instance value. MXG incorrectly blanked the value in

Apr 5, 2002 retained variable INSTANCE. Now, INSTANCE will be from

the preceding 2-HDR record, unless the 3-HDR has a real

length for the INSTANCE. Noted in NT014, but pervasive.

Thanks to Erling Andersen, SMT Data A/S, DENMARK.
Change 20.051 Documentation. When you use UTILEXCL to create IMACEXCL

UTILEXCL for CICSTRAN, old variables that no longer exist in CICS

Apr 3, 2002 are no longer kept; these variables will not exist:

Pre CICS/ESA: FCOTHCN MAXTASK SHRTSTOR OPERATOR PAGEINS

CICS 3.3 only: PC24UHWM PC31UHWM TCSTG TCLASS

Thanks to Helgund Linck, BASF-IT-Services, GERMANY.

Change 20.050 MXG incorrectly decoded the second TYPE78IO IOP segment

VMAC78 if z/OS 1.2 extended data was present, causing very large

Apr 3, 2002 values for R783ICPB/IDBP/ICUB/IDVB when &RB.8 input was

Apr 25, 2002 mis-aligned. Those values caused PROC MEANS to fail with

Mar 25, 2003 a "DOMAIN ERROR", because SAS does not validate data when

the "RB" (floating point) informat is used.

Mar 25 2003: This change may increase the number of obs

created in dataset TYPE78IO, and may increase NRIOPREQ,

the SIO count, and that variable is summed and renamed in

RMFINTRV as SIO73CNT.

Thanks to Diane Eppestine, Southwestern Bell, USA.

Thanks to Jeff Rash, American Honda, USA.

Change 20.049 TYPE89 dataset variable MULCURD was wrong when MULCURT=2

VMAC89 or MULCURT=3. For MULCURT=2 the INPUT is &PIB.8. and for

Apr 3, 2002 MULCURT=3 the INPUT is &RB.8, but MXG had them reversed.

The specific error with MULCURT=2 and incorrect informat

of &RB.8. used for a data value of '00.....01'x resulted

in a MULCURD value of -1.606E60, and that value caused a

SAS DOMAIN ERROR when PROC MEANS summed that dataset.

Thanks to Glenn Harper, Memorial Hermann Hospital System, USA.

Change 20.048 The KEEP= list spelled SMF4VLS instead of SMF94VLS, so

VMAC94 that variable was not kept in TYPE94 dataset.

Apr 2, 2002

Thanks to Bruce Widlund, Merrill Consultants, USA.

Change 20.047 DAILYDSN still wrote to the //PDB libref, after Change

DAILYDSN 20.020. Change OUTDATA=&PDBMXG..DATASETS,

Apr 2, 2002 to OUTDATA=DATASETS.DATASETS,

Thanks to Tien Truong, Citicorp Asia Pacific, SINGAPORE.

=======Changes thru 20.046 were in MXG 20.01 dated Apr 1, 2002=========
Change 20.046 CPU Busy Percentages are very different if WLM's IRD is

VMXGRMFI in control of allocating CPUs to LPARs. Previously the

Mar 31, 2002 PCTCPUBY (TYPE70) and PCTLnBY (ASUM70PR/ASUMCEC) measured

the percentage of the fixed capacity (NRCPUS*DURATM) that

you gave to an LPAR, i.e., that you gave to the system

running in that LPAR, so 100% meant the MVS system was

using all of the CPUs you gave that LPAR.
Now, WLM's Intelligent Resource Director will dynamically

change the number of engines given to an LPAR, so there

is no fixed capacity to measure an LPAR's work against:

variables NRCPUS/LPARCPUS/LPnNRPRC now contain the count

of engines that were used (even briefly) in an interval.
Fortunately, though, when IRD is in control, the PCTCPUBY

(TYPE70 and RMFINTRV), and the PCTLnBY (ASUM70PR/ASUMCEC)

calculations are valid; they have just changed in meaning

and now measure the percentage of the hardware platform

(the CPC, all PARTNCPUs) that was used by this MVS system

or this LPAR. If you had a 2-engine LPAR running at 100%

of those two engines, PCTCPUBY=100% in that MVS's system.

But if that 2-engine LPAR is now run under IRD on a z900

10-way, the PCTCPUBY will be measured as 20%, since only

the fixed capacity of the total CPC platform can be used

now to measure "percent CPU busy".
So what to do? For starters, while we all learn this

new playground, MSUINTRV, the total MSU consumed by each

LPAR during each interval, can be summed for each hour

and compared with SMF70WLA, the (hourly) Defined Capacity

that you chose for your Licensed Software MSU capacity.

You can also convert the MSUINTRV value for intervals

less than an hour to an hourly rate with the ratio:

MSUPERHR= MSUINTRV*3600/DURATM.

But what capacity percentage makes sense anyhow. On a

2064-1C9 (MSU hardware capacity of 305/hour), you could

assign an LPAR to a Defined Capacity of 50 MSU, but you

could easily consume all 302 MSU in that LPAR for an

hour (only impacting Software costs!); what percentage

should be calculated: 302/50= 600% of capacity?

You can detect that WLM's IRD is in control in the

TYPE70PR dataset, which will have LPARWLMG='Y' (SMF70WLM

bit in field SMF70PFG), but only in observations with

SMF70CIN='CP'; the LPARNAME='PHYSICAL' observations have

LPARWLMG='N',and SMF70CIN=' '.
The number of LCPUADDRs in TYPE70PR varies for the same

LPAR; some intervals had 9 LCPUADDRs of 0-8, and some

some intervals had only eight LCPUADDRS of 0-7.
Unless you change the Defined Capacity for an LPAR, the

hourly MSU Capacity of each LPAR, SMF70WLA, is constant,

in spite of the change in the actual count of LCPUs.

The CPC capacity of the 2064-1C9 is 302 MSU (9 CPUs with

SMF70CPA=9329.45), but the sum of SMF70WLA across all of

the LPARs in each CPC is only 185 MSU:

CPCSER xxx3: 65 40 60 15 5 (sum=185)

CPCSER xxx2: 65 55 50 15 (sum=185).

So this site is a perfect example of the real value of

IRD and the IBM License Manager: IBM has installed a 302

MSU box, but the customer is only paying for the 185 MSU

that they currently need for all their LPARs.

Note that even though the CPC has 11 engines, because two

are ICF engines, the CPUMODEL='2064-1C9', showing 9 CPUs.

The change was to revise the calculation of RMFINTRV's

MSUINTRV value, to use the CPUACTTM*SMF70CPA/1E6 rather

than the original that was based on LPAR percent busy.
Expect additional enhancements as we learn more, and

as we decide how to measure this changing landscape.

NOTE: Change 21.170 re-defines NRCPUS and recalculates

PCTCPUBY using the new SMF70ONT online-time measure.

Thanks to Raimo Korhonen, CompMeas Consulting Oy, FINLAND.
Change 20.045 MXG 19.04-19.19. PCTDLxxx variables in TYPE72GO divided

VMAC7072 by variable VALDSAMP can be slightly different than the

Mar 29, 2002 RMF report values; the calculation of the PCTDLxxx and

Apr 5, 2002 PCTUSxxx variables is now based on R723CTSA instead of

on VALDSAMP to match the RMF system level reports, and

both VALDSAMP and R723CTSA are kept in TYPE72GO so that

sysplex-wide velocity can be calculated.

Thanks to John A. Doan, Total System Services, USA.

Change 20.044 If two products write the same user SMF record number,

VMACSMF you can still tailor MXG to read both records, although

Mar 29, 2002 it would be wise to use unique SMF record numbers! The

exact syntax depends on finding a "marker" in one of the

records that can be used to differentiate between the two

products. In this case, both CA's NETSPY and Sterling's

NDM wrote ID=132 SMF records, and the NETSPY Version of

"R5.3" could be used as the "marker", and this example

assumes the NDM record ID will be changed to ID=133. The

example uses MACFILE and MACKEEP macro variables in the

job's input stream, and will read the existing (old) 132s