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

models H30, H50, H55, H70, and H75.

Thanks to Andrew Woods, FT Ineractive Data, ENGLAND.

Thanks to Alan Sherkow, I/S Management Strategies, USA.

Thanks to Cheryl Watson Walker, Watson & Walker, USA.
Change 20.126 Variable UNITADDR was changed to DEVNR in this report

ANALCACH example, so all four digits of the address are displayed.

Jul 16, 2002

Thanks to Jon G. Whitcomb, Great Lakes Educational Loan Service, USA.

Change 20.125 The SMF type 90 subtype 32 record was not supported in

EXTY9032 the TYPE90A member (which should be used instead of the

FORMATS old TYPE90 member) and the MG090CM format was updated for

VMAC90A subtypes 27-32.

VMXGINIT

Jul 16, 2002

Thanks to Bruce Hewson, Citicorp, SINGAPORE.
Change 20.124 The automatic creation of SORTEDBY= added to VMXGSUM by

ASUM42DS Change 20.094 caused this special case to fail, because

Jul 15, 2002 one of the variables in the SORTEDBY= list was renamed in

the final data step. The code was revised to relocate

the rename to avoid the error.

Thanks to Gary Keers, Indianapolis Light & Power, USA.

Change 20.123 Unused Change Number.
Change 20.122 Variable QWACAWDR, Wait Time for Drain Lock, was wrong.

VMACDB2 The statement QWACAWDR=QWAXAWDR; was deleted, because it

Jul 14, 2002 overrode the QWACAWDR=QWAXAWDR/4096; statement a few

lines earlier that set the correct value.

Thanks to Scott Mcdonall, Southern California Edison, USA.
Change 20.121 The Read/Write variables S94CLRD0-7 and S94CLWD0-7 were

VMAC94 formatted with MGBYTES to display bytes transferred, but

Jul 14, 2002 not converted internally from frames to bytes; they are

now multiplied by 4096 to correctly contain and display.

Thanks to Thomas Heitlinger, FIDUCIA IT AG Karlsruhe, GERMANY.
Change 20.120 Cosmetic. Labels for NSPL/NSPP/NSPS frames now contain

VMACNSPY Logical Link, Physical Link, and Physical Unit to clarify

Jul 14, 2002 their contents.

Thanks to Bruce Rosenthal, Inovant, USA.

Change 20.119 Variable S94MTVCA, Maximum Age of any Volume in VCA, was

VMAC94 not converted to seconds nor format TIME8, and thus was

Jul 14, 2002 unlike SMF94VCA, Average Age of volumes in the VCA. Now

both "age" variables are displayed in units of duration.

Thanks to Frank Zemaniak, Vanguard, USA.

Thanks to Ep van der Es, Dow Chemicals, BELGIUM.

Change 20.118 Two additional optional Candle CICS segments, CANPROD2

IMACICD2 and CANPROD3 are now supported when UTILEXCL detects they

IMACICD3 have been added to your type 110 SMF records. Each is a

UTILEXCL four byte field that now creates variables CANPROD2 and

VMAC110 CANPROD3 with those data.

Jul 14, 2002

Thanks to Junaina Haji Abdul Jalil, Qantas Airways Limited, AUSTRALIA
Change 20.117 SAS V6-only: %macro compiler appears to have mis-parsed

VMXGRMFI and lost an end-of-comment */ that ended in column 72,

Jul 14, 2002 immediately prior to an imbedded old-style definition of

MACRO _KRMFINT, with a user-tailored VMXGRMFI execution.

Removing the */ and rerunning under V8 generated the same

error message. This is not the first time that parsing

MXG code with both old-style MACRO definitions and %macro

statements has gone astray when text was in column 1 or

72, but since this error does not occur with SAS V8, I

chose to EDIT end comments so column 72 and 1 are blank

in VMXGRMFI, just for future problem avoidance, and so

the program will still work with Version 6.

Thanks to Albert Nosier, Qantas Airways Limited, AUSTRALIA.
Change 20.116 Support for Type 74 subtype 7 FICON data, new datasets:

EXTY747P TYPE747P - FCD Global, Switch, and Port data

EXTY747C TYPE747C - FCT Connector data

VMAC74 TYPE74P matches RMF reports, but only ports of type CHPID

VMXGINIT (R747PTFL='20'X) appear to have real data. Other ports

Jun 25, 2002 have R747PTFL='00'X and R747PCU='0000'X, but have large

Jul 14, 2002 (and unreasonably large) counts for frames and bytes.

I chose to output any port that had non-zero frame count,

since those ports are the only ports printed by RMF.

This support will likely be enhanced/revised when more

test data has been analyzed and IBM has been contacted.

Jul 14: Labels for PCTPNCHA/DLYCHATM variables changed to

"Director" verus Channel to agree with Change 17.269

APAR OW49638 relates to an RMF problem with FCD option.

Oct 5: Without this change, 74-7 caused DOMAIN ERROR

message; R747PFPT was only input as 4 bytes.

Thanks to Scott Wiig, U.S. Bank, USA.

Thanks to Stephen Hoar, Lloyds TSB, ENGLAND.

Thanks to Lawrence Jermyn, Fidelity Systems, USA.
Change 20.115 Cosmetic, has been this way for a long time; the dataset

VMXGSUM label was a single double-quote (rather than blank) for

Jun 24, 2002 datasets when DSNLABEL was not used to label the dataset.

Thanks to Freddie Arie, TXU, USA.

Change 20.114 STCVSM28 dataset (new in MXG 20.03) variable STC28CLN had

VMACSTC STC28VID as its value, and STC28VID was not kept. Change

Jun 23, 2002 the second STC28CLN of each pair to STC28VID.

Variables STC27RES an STC27STP are formatted $MGSTCSL.

and $MGSTCSD. after extraneous lines were removed.

Thanks to Freddie Arie, TXU, USA.

Change 20.113 VVDS fields were not correctly decoded if the component

VMACVVDS name was exactly 44 bytes; the MXG $VARYING44. INPUT must

Jun 21, 2002 be increased to $VARYING45. (four places) because the one

byte length field has a value of 45 when the name is 44,

and that put MXG's INPUT out of alignment.

Thanks to Mike Field, Royal Bank of Scotland Group, ENGLAND.

Change 20.112 197 source files in my master directory had a '1A'x EOF

DOC character as their last byte; these stray characters are

Jun 20, 2002 created on Windows by SPF/PRO or SPFPC EDITORs, when the

FILE TERMINATOR='Y' is specified instead of ='N'. That

option is set for each profile (file suffix) on the 2nd

page of the PROFILE options. That character only causes

a problem if you upload the ASCII file to MVS, which will

create a new source line with an unprintable '3f'x hex

character that causes a syntax error, or an ASM error.
The MXG tape and CD-ROM have never contained an '1A'x,

nor do the ftp ebcnnnn/ascnnnn files (it did exist in the

ftp dirnnnn.zip file). All '1A'x were removed. This

change was included in the MXG 20.03 release.

Thanks to MP Welch, SPRINT, USA.
=======Changes thru 20.111 were in MXG 20.03 dated Jun 19, 2002=========
Change 20.111 Oracle OSDI records can only be recognized by SUBSYSID;

VMACORAC MXG's default IF SUBSYSID='OSDI' THEN DO; in VMACORAC

Jun 18, 2002 caused lots of missing values if your subsystem name(s)

were something else. This change created new _IDORACO

macro definition to externalize the test. To select your

Oracle subsytems, you would code the expression you want

to be true as the value of the _IDORACO macro:

MACRO _IDORACO

SUBSYSTEM IN ('ABCD','EFGH', :'OSD')

%

and that MACRO definition can be put in your IMACKEEP

tailoring member, or can be defined in the //SYSIN with

//SYSIN DD *

%LET MACKEEP= MACRO _IDORACO .... % ;

Note the colon before 'OSD' selects starting-with-OSD.

Thanks to Dick Triplett, Lockheed Martin, USA.
Change 20.110 New WEEKCEC annd WEEK70PR members based on TRNDCEC/70PR

WEEKCEC will build the WEEK.ASUMCEC/WEEK.ASUM70PR correctly from

WEEK70PR partial weeks data.

Jun 18, 2002

Thanks to Diane Eppestine, SBC Services, USA.
Change 20.109 ENCG3 record with no segments (ENCG3TEO=0 or ENCG3DEO=0,

VMACRMFV or both 0), caused INPUT STATEMENT EXCEEDED error. MXG

Jun 17, 2002 tests TEO/DEO, deletes record if either are zero, and

prints a message for each deleted zero segment record.

Thanks to Jerry Urbaniak, Acxiom CDC, USA.
Change 20.108 Documentation note. Variable UOWTIME can have a value in

VMAC110 the future or the past, but not likely a valid "present"

May 23, 2002 value. UOWTIME is decoded from the first six bytes of

Jun 17, 2002 UOWID field, historically displayed as a datetime value.

Jul 25, 2002 But its only use is as a token, to match multiple CICS

MRO transactions together, or to match CICS and DB2ACCT;

so the datetime value is never used nor important.

Now, IBM often puts a valid TODSTAMP value in those six

bytes of UOWID, but I cannot change the MXG UOWTIME code,

safely, simultaneously, in all of the datasets that have

the UOWTIME variable for matching, so we are thus stuck

with a seemingly invalid value in variable UOWTIME.

But, if you see that UOWIDCHR does contain a TODSTAMP

value, (like 'B74AA17CB093'x for 07MAR2002:14:03:56.26),

you can create the actual arrival time in a new variable

UOWTOD, using the UOWIDCHR and GMTOFFxx variables:

UOWTOD=INPUT(UOWIDCHR!!'0000'X,TODSTAMP8.);

FORMAT UOWTOD DATETIME21.2;

LENGTH UOWTOD 8;

UOWTOD=UOWTOD+GMTOFFTM;

in your analysis programs. Adding the GMT Offset is

required because the UOW time is on GMT; note that MXG

has different names for the GMT offset variable.

P.S. That 'B74AA..'x UOWID value was decoded by MXG

in UOWTIME as '13OCT2001:01:56:38.49'.
Change 20.107 Syntax ARRAY CTR{54} was not accepted by SAS 6.09 at TS

TYPEIMSA TS450; CTR {54} with a blank inserted before and after

Jun 17, 2002 the "Squiggly" parentheses was required for old 6.09.

Thanks to Romain Capron, MATMUT, FRANCE.

Change 20.106 Support for G06 TANDPROC LRECL=442 record (INCOMPATIBLE)

VMACTAND eliminated the DIVIDE BY ZERO error. This record had

Jun 15, 2002 DURATM of zero in the record; MXG re-calculates duration

as DURATM=ENDTIME-STARTIME if the DURATM field is zero.

Variables starting with DEVICENM were misaligned; GNPUT,

because TMFFILL3 in the G05 record is where DEVICNM is

found in this G06 record. Six new variables are INPUT as

F1-F6 from the end of the record; they will be renamed

and labeled when I get G06 TANDPROC documentation.

Thanks to Alex Torben Nielsen, TeleDanmark EDB, DENMARK.

Change 20.105 Enhanced with new graph of "Weighted LPAR Capacity" used,

GRAFWRKX and a new print report (PROC TABULATE) can be printed if

Jun 15, 2002 you don't have SAS/GRAPH. The tabular report will be

created if you specify TABULATE=YES. If you do have

SAS/GRAPH, specifying TABULATE=YES will create both the

graphs and the report.

The "Weighted LPAR capacity" can be important because it

is based on the defined weight of the LPAR and the number

of processors, whereas the "MVS Capacity" (PCTCPUBY

in RMFINTRV) is based solely on the number of processors

defined to an LPAR. The Weighted utilization can exceed

100%, which means simply that the LPAR is exceeding the

share of the CEC that is defined by its specified weight.
As an example, assume an LPAR with 2 CPs and a weight

of 15, on a 10 engine CEC with total weight of 100.

Then this LPAR has a weighted capacity of 1.5 CPs, and a

maximum usable capacity of 2 CPs. When the CEC is

constrained, the PCTCPUBY reported by RMFINTRV from the

MVS perspective will never exceed 1.5/2.0 or 75% busy,

but the LPAR is running at 100% of its weight-defined

capacity. However, if the CEC is not constrained, the

LPAR can use some or all of the extra 0.5 CP. RMFINTRV

could show PCTCPUBY=90%, using 1.8/2.0 but that means the

LPAR used 120 "percent of the weighted capacity", which

may be an indication that this LPAR needs more power.

Whether you are creating graphs or tabular reports, you

can create HTML and GIF datasets on an OS/390 platform to

be displayed only on OS/390, or you can create HTML/GIF

output with TRANTAB=ASCII that can only be displayed on

ASCII systems. The VMXGWRKX argument HTMLDEST=ASCII

sets ASCII as default; to create EBCDIC-displayable PDSE

members, add HTMLDEST=, i.e., a null value, to your

%VMXGWRKX(HTMLDEST=, ...); invocation.

The HTML output must be written to a PDSE on OS/390 with

RECFM=VB,LRECL=8000,BLKSIZE=8004; that PDSE dataset must

be allocated using a FILENAME statement rather than with

a DDNAME in your JCL. When %VMXGWRKX is executed the

HTML text and images are written to the PDSE library to

members named FRAMWRKX, GRAFWRKX, CONTWRKX, and GCHARTnn,

if graphs were also generated. For ASCII viewing, those

those members should be downloaded (as binary files) to

file on your ASCII system using names of:

framwrkx.html grafwrkx.html contwrkx.html gchartnn.gif

(NOTE: CASE is important. Your browser may not find them

all if the case does not match its expections.)

One either EBCDIC or ASCII systems, point your browser at

member FRAMWRKX or the FRAMWRKX.HTML file to access the

contents and the reports and graphs you created.

Obscure Note: If HTMLDEST=ASCII and TABULATE=YES, a

FORMCHAR='xxxxxxxxxxxxxxxxxxxxxxxxxx' is generated on

the PROC TABULATE, and it makes the printed report on

the SASLIST output pretty much meaningless; however,

without that FORMCHAR= operand, HTML written to the

PDSE is pretty much useless.

Thanks to Chuck Hopf, MBNA, USA.

Change 20.104 The MXG ANALRMFR "RMF HTTP Server Report" didn't print

ANALRMFR web server name (MXG variable HOSTNAME), didn't print

VMAC103 separate reports for multiple servers on same system,

Jun 14, 2002 and had incorrect/transposed values. VMAC103 was revised

to increase variable HOSTNAME from $8 to $32; I thought

it was MVS System "host" name and limited to $8 bytes.

Thanks to Cheryl Watson Walker, Watson & Walker, USA.
Change 20.103 Whether or not to comment out the BO DROPMAP NONRECOV?

ASMIMSL6 instruction for OTMA records may be something you have

Jun 13, 2002 try both ways and see which gives correct results. One

site, with IMS 6.1, found it necessary to reinstate the

comment to disable the BO DROPMAP NONRECOV? statement.
Change 20.102 Logic for CICSJOUR dataset (unidentified CICS Journal

VMAC110 segment in SMF 110 Subtype 0 record) was not correct for

Jun 12, 2002 CICS/ESA 4.1 and CICS/TS 5.1, causing the USERDATA field

to be blank. ELSE IFs were missing, and 4.1 did not set

the LENUDAT field from JCRLL.

Thanks to Len Rugen, University of Missouri, USA.

Change 20.101 Support for JES2/JES3 "Z2 Mode" (INCOMPATIBLE) to allow

ANAL30DD 200,000 jobs and 9,999,999 job numbers. MVS Technical

ANALEPMV Note 11 in MXG Newsletter FORTY-ONE provides reference to

IMACCADI the IBM Flash that lists the many exposures when your

VGETJESN enable the Z2 Mode, which changes JCTJOBID to "Jnnnnnnn"

VMAC26J2 for JOBS, etc. This change created member VGETJESN to

VMAC26J3 decodes both formats of JCTJOBID into TYPETASK & JESNR.

VMAC30 Note: CONTROL-D has only a 5-byte position for JESNR;

VMAC32 That product will require changes in their SMF

VMAC42 record to support the Z2 mode, and this note will

VMAC6 be updated when/if that product supports Z2.

VMAC91 Some additional symptoms: TYPETASK='J00', 'T00', 'S00'.

VMACBETA

VMACDALO

VMACIPAC

VMACNNAV

VMACSFTA

VMACTMNT

VMACXPSM

Jun 13, 2002

Thanks to Michael Richard, CompuWare, USA.
Change 20.100 Support for Citrix was not included in Change 19.148; the

VMACNTSM Citrix process record has an extra counter (NRDATA=22)

Jun 11, 2002 that is now supported by this change.

Thanks to Robert Gauthier, Albertsons, USA.

Change 20.099 New variable MSU4HRMX was missing in PDB.TRNDRMFI dataset

TRNDRMFI because it was calculated in the INCODE= argument, but

Jun 11, 2002 its source variable, MSU4HRAV was not in any of the other

arguments to VMXGSUM. While using KEEPIN=MSU4HRAV would

have corrected this one variable, KEEPALL=YES is better,

as it has lower overhead and protects future variables.

Thanks to Fred Kaelber, Southwestern Bell, USA.

Thanks to Diane Eppestine, Southwestern Bell, USA.

Change 20.098 This is "Maintenance Level, ML-23" of MXGTMNT, the Tape

ASMTAPES Mount and Tape Allocation Monitor program, which adds the

Jun 10, 2002 EXCLUDE logic so you can suppress monitoring of your VTS

devices by DEVNR, so you can avoid filling your Logrec

file with 0E0 Software ABEND records.

When a very fast VTS scratch mount occurs, MXGTMNT can

receive (and recover from) the 0E0 ABEND (because the

job had already terminated before its next sample),

but our friends at IBM still write a Logrec record for

each 0E0 recovery, and MXGTMNT has filled Logrec with

over 25,000 records in one day, causing a B37 in EREP!

After four months research with IBM'd trying to use an

STOKEN to prevent the logrec record, IBM now says that

only an FRR (Functional Recovery Routine) can suppress

the Logrec record, and an FRR is not trivial to add.

This change is an interim solution, pending the FRR code.

To exclude DEVNRs from MXGTMNT, you will need to add the

optional //EXCLUDE DD statement (FB,LRECL=80) to the JCL

for the MXGTMNT Started Task that points to the file that

contains your exclude control statements. The new logic

skips over UCBs that are both Tape Devices AND that are

specified in the EXCLUDE statements. Single DEVNRs

and/or ranges of DEVNRs are supported in this syntax:
Device Numbers can be specified like this, separated from

each other by blanks:

XXX /* ONE 3-DIGIT DEVICE NUMBER */

XXXX /* ONE 4-DIGIT DEVICE NUMBER */

XXX-XXX /* A RANGE OF 3-DIGIT DEVICE NUMBERS */

XXXX-XXXX /* A RANGE OF 4-DIGIT DEVICE NUMBERS */

Any combination of the above can be used, separated by

blanks in columns 1 thru 80 on the statements read from

the //EXCLUDE DD. Characters in device numbers must be

Hex Digits, 0-9 and/or A-F.

These Device number Specifications are NOT valid:
XX-XX

X-XX

XX-X

X-X

XXX-XX

XX-XXX

X

XX
Comments may NOT appear on the same statement as a device

number to exclude.
Each device number or device number range must be

followed by at least one blank.

In addition to adding the FRR to ASMTAPES/MXGTMNT monitor

program to ultimately monitor VTS devices without 0E0s, I

hope to enhance the ASUMTAPE program (that creates the

PDB.ASUMTAPE dataset from the MXGTMNT records and IBM's

SMF 21 dismount record) first by adding the STK VTC SMF

data, and second with the IBM SMF 94 data to provide

additional timestamps and values from those records into

an enhanced PDB.ASUMTAPE dataset. The ASUMTAPE changes

will hopefully be completed by the end of Summer.
17Jun02: ASMTAPES is now being enhanced, and an FRR is

not going to be required, so the ML-24 that will monitor

VTS devices (catching those mounts longer that 2 seconds,

but without writing 0E0 messages to logrec) should be

available very soon.
Change 20.097 Another instance of DOMAIN ERROR was caused by IBM's mis-

VMAC91 documentation of fields SMF91SDI and SMF91SDO as long

Jun 10, 2002 floating point values, but the data values in the subtype

3 were '0000000000000002'x and '000000B600000070'x, which

are clearly not floating point values. The second value

is 728GB is highly suspect, as all of the other counters

are zero in this particular record. A problem will be

opened with IBM and this note will be updated when they

respond, but the two inputs for SDI and SDO are now PIB

instead of RB, which will eliminate the DOMAIN ERROR.

See NEWSLETTER FORTY-ONE, SAS TECHNICAL NOTE 7.

Thanks to Dan Doan, Verizon, USA.

Change 20.096 TYPE73 observations for SMF73ACR='CFS' (Coupling Facility

VMAC73 Channels) had PCHANBY missing, but RMF Reports showed non

Jun 7, 2002 zero values for "Total" Channel Utilization (but had dash

for the "Partition" percent). The records had SMF73CMG=1

and thus I calculated PCHANBY and PNCHANBY only if the

SMF73PTI (measurement interval) was non-zero. But in the

'CFS' records, SMF73PTI, PBY, PTI, PUT, and TUT are all

zero. In looking in detail, it turns out that for the

'CFS' channel, the old SMF73BSY and SMF73STP fields are

what IBM is using to calculate PCHANBY, and the PNCHANBY

file is not calculatable for the CFS channels. MXG now

uses the PTI-based fields if present, but will use the

original BSY/STP calculation when PTI is zero.

Thanks to John Gebert, Office Depot, USA.

Change 20.095 MXG did not correctly input the GMT Offset value, causing

VMACTMDB GMTOFFTM and all timestamps were incorrect, if your GMT

Jun 6, 2002 offset was non-zero. The timestamps printed as astricks.

Thanks to Paul van den Brink, Fortis Bank, THE NETHERLANDS.

Change 20.094 A combination of circumstances caused NOT SORTED error in

MONTHBLS dataset TYPE30OM, but MXG Change 19.172, that increased

MONTHBLD the stored length of many numeric variables from 4 to 5

MONTHBL3 bytes, was the underlying culprit:

WEEKBLD - TYPE30OM is unique; it's BY list has integer numeric

WEEKBL3 variables OMVSOSI, Session ID and OMVSOPI, Process ID.

WEEKBLDT Most variables in BY lists are character variables.

WEEKBL3T - The problem occurs only when both OMVS/USS and OS/390

Jun 4, 2002 have stayed up a long time, allowing ID number value in

VMXGSUM OMVSOSI/OMVSOPI to exceed 16,217,666. Only integers of

Jun 18, 2002 that value can be truncated when stored in 4 bytes.

VMXG2DTE In this case OMVSOSI and OMVSOPI were equal and large!

Jun 13, 2002 - The problem occurs only when the WEEK1 DD, which is the

ASUM78CF first libref in the SET statement, points to an old PDB

Jun 14, 2002 that was built by MXG earlier than 19.10. That old PDB

had the original, sort, 4-byte length, and the first

dataset in the SET statement is used by SAS to define

the stored length of the output MONTH.TYPE30OM dataset.

It is better that the WEEK1 DD points to the most

recently build PDB, created by the new MXG version,

so that all new changes (like the longer length) are

seen first to set the definitions.

And it is best to install a new MXG Version on

the first day of your week; if you build WEEKLYs

on Monday morning, then install the new version

Monday afternoon when all is done, so that all of

next week's PDBs are built with the same version.

With the MXG change and those circumstances, the old PDB

4-byte definition was used, causing the new 5-byte values

to be truncated to smaller numeric values, which SAS saw