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

SYTCUP - LCXPUPID

SYTXSG - TCMFSHVM TCMRDCT TCMPIN4K

USELOF - VEBALERT VEBHDWAI VEBSVSCT VEBTPIAI

VEBTVSCT VEBVIRAI

USEACT - VEBALERT VEBHDWAI VEBSVSCT VEBTPIAI

VEBTVSCT VEBVIRAI

USEATE - VEBALERT VEBHDWAI VEBSVSCT VEBTPIAI

VEBTVSCT VEBVIRAI

SYTSYG - SCPCAPAB

-New Datasets created in z/VM 5.1:

MTRQDC - QDIO DEVICE CONFIGURATION

IODQDS - QDIO ACTIVITY

Other new records will be supported only if you

have a need and can send test data for them:

MTRCCC, IODVSM, IODVSR, IODSZI, IODQDA, IODQDD.

Thanks to Kris Ferrier, State of Washington Dept Info Services, USA.

Thanks to Alexandre Dorsimont, SCNH, FRANCE.

Change 22.368 The "TOTALS" record was still output in XAMSYT, because

EXXAMSYT the test in EXXAMSYT was spelled 'TOTAL' but the actual

Jan 26, 2005 LPAR name test needed to be 'TOTALS:'.

Thanks to Joachim Mayr, Amadeus, GERMANY.

Change 22.367 MXG 22.13-22.22 only. Change 22.320 combined MULTIDD obs

BUILD005 from TYPE30_V into one PDB.SMFINTRV obs, but if you used

BUIL3005 IMACINTV to only output some of the TYPE30_V obs, then

Jan 25, 2005 PDB.SMFINTRV had more obs than were in TYPE30_V. All DDs

for all tape devices from all interval records are output

in TYPE30TD, independent of the TYPE30_V selections. The

TYPE30TD then becomes TYPE30VT, which is merged with the

INTVS (which is a stripped down TYPE30_V) and INT30VSIO

(the sum of all I/Os for the interval records), but now,

the merge is only OUTPUT if the obs is in INTVS.

Thanks to Ron Lundy, AHOLD, USA.
====== Changes thru 22.366 were in MXG 22.22 dated Jan 22, 2005=========
Change 22.366 The MXGTMNT Tape Mount Event and Sampling Monitor ML-32

ASMTAPEE is in member ASMTAPEE, with these enhancements:

ASMTAPST -The ML-32 revisions are primarily for IBM Tape Devices,

ASMTAPSK because it defaults to use the IBM Volume Mount Exit, and

Jan 22, 2005 STK doesn't support that exit. Thus these defaults in

Jan 27, 2005 the ASMTAPEE member will ONLY work with IBM devices:

MXIT=ON, use the IBM Volume Mount Exit to capture all

Mount Events (exit-driven, not sampling for mounts),

which also gets job-level fields for the Mount Event

so Cross Memory Service calls are not needed for the

mount record.

XMEMF=ON, use Cross Memory Services to get job-level

fields for the Allocation Event, which are detected

by sampling.

ARCV=ON, enable detection of Allocation Recovery thru

exit, to write a separate subtype for each delay

because a tape device could not be allocated. This

subtype creates the (new) PDB.TMNTTARC dataset.

-However, you can use ML-32 with STK devices: you have to

set MXIT OFF, so that the old sampling monitor is used to

detect mount events, even though that means that many of

your fast VTS mounts will not be captured. You also need

to leave XMEMF ON, so that Cross Memory Services is used

to get the job-level information for both mount events

and allocate events, even though that may increase the

CPU time used by the MXGTMNT monitor (because there is no

way to know that an address space is no longer present,

except to issue the XMEM call, and then go thru the very

CPU-expensive recovery mechanism when XMEM fails to find

the job, because it had already ended).

-And if you have both IBM and STK devices, you will need

to assemble two different MXGTMNT programs and run them

in two Started Tasks, and use the EXCLUDE LIST DD to tell

the IBM instance to exclude the STK devices by DEVNR, and

to tell the STK instance to exclude the IBM devices.

You can create the same SMF record for both monitors, or

you could set different SMF IDs, and then you would use

MACRO _IDTMNT nnn OR ID= mmm % in the IMACKEEP member

to tell MXG to process both IDs as MXGTMNT records.

-STK devices are allocated by STK's HSC product, which

does not call the IBM volume mount exit; we have written

a test program for the HSC SLSUX01 exit, but have not had

an STK site run the program, which will determine if we

can use that exit for STK devices (and thus eliminate the

sampling and missed mounts). Here's what we need:

ASMTAPST is a test exit for potential STK support. The

program is a wrapper for the site's current SLSUX01 HSC

exit. There is a DD in the linkedit step, HSCLOAD, that

points to the location of the site's current SLSUX01

exit. The output of the linkedit is a combined SLSUX01

exit that the site will use, instead of their current

SLSUX01 exit code. The HSCLOAD and SYSLMOD DDs must not

point to the same library, or the site's SLSUX01 will be

replaced. Once the ASM/LKED are done, the site will

have to define the new MXG version of that exit to HSC.

The logic is as follows:

-HSC calls the MXG SLSUX01.

-MXG SLSUX01 executes the site's local SLSUX01 as-is,

taking whatever actions, were coded by the site.

-Control is returned to MXG SLSUX01 where the code

will do some data gathering and issue WTOs to the job

log, reporting what was discovered, from which we can

tell if the HSC exit can be used for STK devices.

-MXG SLSUX01 returns to HSC.

Once you've installed our exit, run some jobs that

cause both VTS and non-VTS tape mounts, and send us the

MXGTMNT job log, which will show us if all mounts do

actually go through the exit, and what environment

exists at the time the exit is taken. From that info,

we may be able to figure out how to handle the STK

devices. Unfortunately, we have to depend on you to

run these tests, as STK has been unwilling to run these

tests for us on their systems.

- Just discovered: STK no longer provides a dummy exit

SLSUX01 in HSC 6.0! Member ASMTAPSK is the variant

of ASMTAPST that doesn't call that user exit.

-ML-32 corrects ML-31, in which setting MEXIT bypassed the

XMEMF call in the Allocation Monitor (causing job-level

fields to be missing in the allocation records). Now,

XMEMF on/off is independent of the MEXIT on/of setting.

-The TMNT004I message is updated before it is issued at

MXGTMNT initialization, to show any user modifications.

-STEPNAME is now correctly populated, and PROCSTEP name

has been added to TYPETMNT record for mounts.

-Using MXIT on IBM systems is only supported on z/OS. We

have seen, on OS/390 systems, that second and subsequent

mounts for a job-step are not captured by MXIT, and also

mounts from STCs (like DFHSM and JES2) are also missed.

This is just not worth fixing for those archaic systems.

-There is one know error in ML-31/ML-32; the Mount Start

time is taken as the entry time into the Volume Mount

Exit, which now appears to be the same as the Allocation

Allocation Start time, and for most mounts that is very

close to the IEF233I Mount Message timestamp, and hence

not a problem. But one site experienced very significant

delays (30 minutes!, due to hardware errors) between the

TMNTTIME time and the IEF233I time, so "[e-mail]"

is now working on a revision, ML-33, but it won't be done

and tested in time for MXG 22.22; please email a request

to [e-mail] when you read this text, asking for

ML-33, and we'll email the revised ASMTAPEE when ready.
Change 22.365 BUILDPDB now sets Condition/Return Code of zero under V9!

BUILD005 SAS V9 tightened when Condition Codes were returned, and

VMAC26J2 the WARNING: LENGTH OF CHARACTER VARIABLE HAS BEEN SET

Jan 21, 2005 returned a CC=0 with SAS Version 8.2, but CC=4 with V9,

because JES3 JOBCLASS is $8, VMAC30 reads JES2 and JES3

30s, but VMAC26J2 for JES2 26s had JOBCLASS of $1, and

VMAC26J2 was located first in BUILDPDB to set $1 length.

This design increased JOBCLASS length in VMAC26J2 to $8,

eliminating the WARNING in the SMF-reading step where

VMAC30 and VMAC26J2 coexist, and new LENGTH JOBCLASS $1

statements were inserted in BUILD005 to keep only $1 for

JES2 JOBCLASS in the PDB and SPIN datasets, so that old

and new datasets built before and after this redesign

will still have a one byte JES2 JOBCLASS variable.

-TYPE30 used by itself always had JOBCLASS $8, so that did

not change; only if you use TYPE26J2 by itself would you

notice that JOBCLASS's length is now $8 instead of $1.

But with MXG's COMPRESS=YES default, you shouldn't see

any increase in the size 'cause those 7 blank bytes will

get compressed real good!

-The SAS change was noted in MXG Newsletter FORTY-FOUR,

but that note was revised, citing this MXG change.

-This should make migration from V8 to V9 even easier.
Change 22.364 Variables BLKPAGE, BLKSAUIN, and NRBLKPAGE in TYPE71 are

VMAC71 rates (per second, like all paging activity rates), but

Jan 21, 2005 their labels did not so indicate; now, they do.

Thanks to David Kaplan, DTC, USA.

Change 22.363 -The JES3 Workload Management Section variables (added to

BUILD005 SMF 26 in OS/390 R2.4; already in TYPE26J2 and PDB.JOBS

BUIL3005 for JES2, are now kept in JE3's TYPE26J3 and PDB.JOBS.

VMAC26J3 JOBMODE0='RAN*IN*MODE=WLM'

Jan 21, 2005 JOBMODE1='RAN*F*J=JOB,RUN'

SMF26WCL='SERVICE*CLASS AT*EXECUTION'

SMF26WIN='JOB*INDICATORS'

SMF26WJC='JOB*CLASS'

SMF26WOC='ORIGINAL*SERVICE*CLASS'

SMF26WSE='SCHEDULING*ENVIRONMENT'

-Variable SMF26WSE, the Scheduling Environment name, was

only previously kept in JES2's PDB.JOBS, but this change

adds SMF26WSE to PDB.STEPS for both JES2 and JES3, as it

is often useful examine STEPS-level data (i.e., PROGRAM)

and the Scheduling Environment name that caused that PGM

to execute on this SYSTEM.

Thanks to Julian Smailes, Experian, ENGLAND.
Change 22.362 Cosmetic. The include of VMACSMF in these products was

Several not needed, as they read different INFILES. No error,

Jan 21, 2005 but it could have been confusing. Members changed:

TYPEASXT, TYPECMFV, TYPEEAGL, TYPEIDML, TYPEMVCI,

TYPEOMDB, TYPEUNIA, TYPEUNIK, and TYPEVITA and TYPS's.

Thanks to Freddie Arie, TXU, USA.

Change 22.361 Variable SYSTEM was blank in PDB.ASUMUOW if there was no

VMXGUOW DB2ACCT observation for that unit of work. The value of

Jan 20, 2005 SYSTEM comes from the last of the two input datasets

(CICS,DB2) that contributed to the PDB.ASUMUOW obs, so

if there are DB2 obs, the SYSTEM of the last DB2ACCT

observation will be the source of the value of SYSTEM.

Thanks to Ron Root, Texas Comptroller of Public Accounts, USA.
Change 22.360 On z/890s with z/OS 1.4 but with SMF70LAC=0, values in

FORMATS the variables CECSUSEC, CPCNRCPU, CPUMSU were missing

VMXGRMFI because the $MG070CP format's table for CPUTYPE='2086'x

Jan 19, 2005 was wrong. When SMF70LAC GT 0, those variables are in

the SMF 70, but the $MG070CP table has to be used when

SMF70LAC=0. MXG ERROR: CPUTYPE WAS NOT FOUND IN TABLE,

CECSUSEC IS MISSING was printed (obscurely) on the SAS

log by RMFINTRV code; this change enhanced that message

in case it again occurs. Changes 21.299 and 20.168 noted

that SMF70LAC was zero on basic (non-LPAR) machines, or

on LPAR'd machines if APAR OW55509 was not installed and

the LPAR had no defined capacity limit. This system was

not running in 64-bit mode, which may also be required

for SMF70LAC to be non-zero.

Thanks to Diane Parker, AmerisourceBergen Corp, USA.
Change 22.359 Full support for CICS/TS 3.1 was only in UTILEXCL in

VMAC110 22.13 as the three new fields (328,341,342) during the

Jan 18, 2005 ESP were not added to VMAC110 INPUT for SMFPSRVR=64.0

until today. MXG 22.13 tested MCTSSDCN=283, but now

MCTSSDCN=286 and MCTSSDRL=1848 is tested for

non-excluded-field records. Using UTILEXCL to create

IMACEXCL has always been the recommended way to minimize

the size of your CICS 110s, and even if there are added

fields, since UTILEXCL read your CICS dictionary records,

it will generate code to skip over any unrecognized

fields (and will tell you on the log it found unknown

fields, so they can be added to the MXG UTILEXCL and

VMAC110 members.

Thanks to Roland Schiradin, Alte-Leipziger, GERMANY.

Thanks to Lambros Theodorides, Alte-Leipziger, GERMANY.
Change 22.358 CALTODON, the datetime stamp when user Logged on, was not

VMACVMXA converted from GMT to local time, but now it is.

Jan 18, 2005

Thanks to Xiaobo Zhang, ISO, USA.

Change 22.357 UTILBLDP failed with USERADD=118 because VMACTCP defines

UTILBLDP the macros for SMF 118; originally, the TCP record was a

Jan 18, 2005 User SMF record, and only later was given ID=118. Now,

UTILBLDP is coded for this inconsistency and will work if

use USERADD=118 or USERADD=TCP.

Thanks to Keith McWhorter, Georgia Technology Authority, USA.

Change 22.356 UTILCONT reports SAS Data Set sized in MegaBytes; as is

UTILCONT documented in its comments, it can cause log messages of:

Jan 18, 2005 WARNING: LIBRARY xxx WAS ALREADY ALLOCATED

ERROR: LIBRARY xxx MAY NOT BE REASSIGNED

ERROR: DISP=SHR CONFLICTS ASSIGNED

ERROR: LIBNAME XXX IS NOT ASSIGNED

but with MXG default options, these messages to NOT cause

a condition code, nor does the job fail, and the reports

are produced. However, if you have set the SAS Option to

ERRORCHECK=STRICT (default is NORMAL), then errors like

the above in LIBNAME statements do cause ERRORABEND to be

invoked, and the step fails with USER ABEND 999.

An ABEND did occur with %UTILCONT(PDB=WORK); due to the

changes made in Change 22.175, when MXG 22.12 was tested.

This change to UTILCONT detects that the LIBNAME of WORK

was requested and does not reassign it, avoiding those

messages for the WORK library, and the ABEND.

Thanks to Hugh Lapham, Royal Canadian Mounted Police, CANADA.

Change 22.355 EDGRKEXT was wrong; the first +1 did not exist. New

VMACEDGR variables RKRELIXD RKRELSI RKRETAND RKRETNCD RKRETNXD

Jan 17, 2005 are now output.

Thanks to Reinhard Nitsch, Provinzial Vershicherungen, GERMANY.

Change 22.354 Capacity used for each interval for each workload, for

ASUMMIPS each service and reporting class from PDB.TYPE72GO, and

Jan 16, 2005 for each job from PDB.SMFINTRV, with MIPSUSED, MSUUSED,

Jan 22, 2005 and PCTUSED variables, is created in two output datasets

named PDB.RMFMSUSE and PDB.SMFMSUSE by the ASUMMIPS code.

I think MSU is a much better capacity measure than MIPS,

but I used "MIPS" to name the member, so that, when your

boss asks for an MXG report on MIPS used, you will find

this program, which uses MSUUSED and MSU Capacity for the

PCTUSED, but also calculates MIPSUSED from MSUUSED.

-Note that the conversion from MSU to MIPS uses a factor

that you will likely have to change to meet your boss's

MIPS rating of your hardware. IBM giveth the MSU rating.

Comments show how to determine the factor for your boss,

and you can set different factors for different systems.

-The MIPSUSED are the MSUUSED, multiplied by the factor

you set; the default factor is 5.8 MIPS for each MSU, but

IBM now has a factor of 6.7 MIPS for each MSU for T-REX.

-See MXG Newsletter FORTY-ONE, MVS Technical Note 24, for

my documentation of MSU metrics and the MSU capacity

variables that are reported in the ASUMMIPS examples.

-PDB.RMFMSUSE is created from RMFINTRV and TYPE72GO data,

for capacity used by each Service and Reporting Class in

each interval. Be careful: PDB.RMFMSUSE has duplicate

data, because it keeps both the Reporting and Service

Class obs. You will need to select which obs are of

interest for your reporting, before you do any summary of

the data in PDB.RMFMSUSE.

-PDB.SMFMSUSE is created from RMFINTRV and SMFINTRV data,

for capacity used by each JOB in each interval. If your

SMFINTRV data is NOT globally synchronized, the results

in PDB.SMFMSUSE may be inaccurate:

If your RMF Interval is on 0 minutes, but your SMF data

is on 3 minutes, the 00:00 to 00:10 interval created in

PDB.SMFMSUSE includes CPU time from jobs's intervals

that executed from 00:03 to 00:13.

-In both datasets, the MSU capacity is calculated from the

CECSUSEC of the hardware platform, not from the SU_SEC of

the MVS System, because that's what IBM uses in its MSU

calculations. I use the NRCPUS (average number of CPUs

that IRD gave to this MVS system ) to get the capacity

of the specific interval (DURATM). To compare with IBM

hourly MSU rates, you need to multiply by the ratio of

3600 divided by DURATM of your interval data.

-The PCTUSED is the percentage of MSUUSED by the job or

service/reporting class during this interval, divided

by the interval MSU capacity (using average NRCPUS),

which MXG calculates in variable INTMSUCP.

-Be careful to not confuse MIPS/MSU counts with MSU rates.

Read the Newsletter Article (again).

-Macros define the input "RMFINTRV" dataset that is used,

which sets the output interval, and macros define the

output dataset names. The MXG default interval for

"RMFINTRV" is your RMF Interval, but you can execute the

RMFINTRV program many times to create multiple "RMFINTRV"

datasets, each with different interval (see comments in

member RMFINTRV). For example, Hourly in RMFINTHR,

Shiftly in RMFINTSH, Daily in RMFINTDY. Comments in

ASUMMIPS member show how to execute it and how to tailor

it for your needs.

Thanks to George Canning, Abbey Plc, ENGLAND.
Change 22.353 The ERROR*RMFINTRV. WORKLOAD CPU TIMES DO NOT MATCH ...

VMXGRMFI is printed when the sum (CPU72TM) of the workloads that

Jan 16, 2005 you defined, either in your tailored RMFINTRV member

(the recommended way to define which Service/Reporting

Classes you want combined into PDB.RMFINTRV workloads),

or in your tailored IMACWORK member (the old way), do not

match the sum (CPUTM) of all Service-only Classes.

The text of the message was enhanced to show both times

in both TIME12.2 and 8.2 formats and they are collimated

for easier reading.

-If you do receive that error message, you need to review

your RMFINTRV/IMACWORK definitions, and review your data,

which is the purpose of the UTILRMFI program, which will

examine both your TYPE72GO and STEPS/SMFINTRV data to

provide explicit answers, but UTILRMFI requires manual

EDITing, and could require re-reading of your SMF data.

This PROC FREQ might be sufficient to show the error:
PROC FREQ DATA=PDB.TYPE72GO

WHERE=(STARTIME='02JAN2005:08:00:00'DT));

BY SYSPLEX SYSTEM;

TABLES RPRTCLAS*SRVCLASS*STARTIME/MISSING;

WEIGHT CPUTM;

FORMAT STARTIME DATETIME13.;RUN;

My error message was the result of using an old RMFINTRV

that had USEREPRT=GOAL (use ONLY Reporting Classes), but

the test data I was looking at (for other purposes!) did

not have 100% of its Service Classes mapped to Reporting

Classes. The preceding PROC FREQ showed that the CPUTM

was exactly equal to the RPRTCLAS=' ' observations, and

that CPU72TM was exactly equal to the RPRTCLAS='Y' obs,

and that CPU72TM was less than CPUTM. The PROC FREQ is

also useful since it shows the CPU time and the names of

all Service and Reporting Classes in the interval.

Change 22.352 Test for short record expanded to test both LENMONI and

VMACTMO2 LENGTH, because an archive file contained two 80-byte

Jan 14, 2005 records that contained '4040'x for LENMONI.

Thanks to Tom Parker, CSC, USA.

Change 22.351 HSM format MGHSMFU for 13 is 13:FULL VOLUME DUMP instead

FORMATS of 13:DELETE BACKUP VERSIONS, and descriptions were made

Jan 14, 2005 clearer for migration formats.

Thanks to Michael Yuan, University of California, USA.

====== Changes thru 22.350 were in MXG 22.13 dated Jan 13, 2005=========
Change 22.350 New CICS/TS 3.1 variables WBREPRDL, WBREPWDL, PGCRECCT

UTILEXCL were found in PDB.CICSDICT and are now supported in the

VMAC110 UTILEXCL member, and WBSNDOU1 test was corrected.

Jan 13, 2005 -Duplicate variables were not removed from SORTTEST so

and additional DATA step was added to remove them all.

Without this change, 180 errors when TYPE110 was executed

with IMACEXCL built by the earlier UTILEXCL.

Thanks to Tory Lepak, Aetna, USA.

Change 22.349 Change 22.325 created SHORTCPS/PLCPRDYQ variables, but

VMAC7072 negative values were found in a few TYPE70 observations.

VMXGINIT Those obs also had PCTMVSBY and CPUMVSTM negative, values

Jan 13, 2005 of MVSWAITx greater than DURATM, and unreasonably large

Jan 29, 2005 IORATE values, at two sites, both using IRD (Intelligent

Resource Director, the WLM component that varies engines

on/offline as needed. The occasionally bad data records

occurred with both z/OS 1.4 and 1.5, and all of the RMF

70 records with bad data had SMF70CNF bit 6 on ('02'x or

'03'x in MXG variables CAIx), and no observations with

bit 6 off had bad data values, and only some CPU Data

segments in each bad record had bad data.

-None of the LPAR bits indicated a change in CPUs, but in

one z/OS 1.5 case examined closely, in the LPAR segment

for the CPUID that had CAI='02'x, SMF70ONT was only 230

milliseconds less than SMF70INT/DURATM; the next interval

shows that engine remained offline (CAI='00'x), so it

appears the bad data may only occur when IRD has varied

an engine off right at the end of an interval.

-When engines had been IRD'd on/off with good data, they

had SMF70ONT values that were a multiple of 10 minutes,

the normal WLM decision interval for varying engines.

-SMF70CNF bit 6 was documented in the SMF manual as

"CPU reconfigured during the measurement interval (data

for this CPU is incorrect)"

However, RMF Development now says that the "incorrect"

part of the doc is out of data, is no longer true, and

will be revised.

-Both sites had SLIH counts of 20-30 million in 900 second

(15 minute) interval data, which was much above the value

in normal observations from both sites.

-Many obs had SMF70WAT (CPUWAITM) much larger than DURATM

in the observations with bit 6 on (as much as 26 Hours of

Wait in a 15 minute interval) at one site, while the

second size always had SMF70WAT of zero when bit 6 was on

(which is likely also wrong, as that would be 100% busy

for that engine, which was inconsistent with the other

engines in the LPAR for that interval).