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

retrofit your tailoring with the new IMACMONI member.

-Also, the DO group beginning with

IF LENMONI='1... ..'B THEN DO;

was relocated to follow

IF TMMDREC='DD' ... 'HH' ... 'TD' THEN DELETE;

because one XA site found the LENMONI bit on in an 'HH'

record (causing USER ABEND 1099), even though the site

had the EXITMON6 decompression exit installed. I'm still

investigating, but relocating the DELETE to be prior to

the LENMONI test eliminated the ABEND.

Thanks to Carl Sommer, SAS Institute Cary, USA.

Thanks to Jim Swartz, Dale Electronics, USA.

Thanks to Svend Henningsen, SMT Data A/S, USA.
===Changes thru 12.314 were included in MXG 12.12 dated Mar 1, 1995===

(but were were not printed in MXG Newsletter TWENTY-SEVEN)

Change 12.314 IMACEXCL (for CICS Exclude/Include logic) is updated with

IMACEXCL new _CICXCU4 for CICS/ESA 4.1.0 records; the old _CICXCUS

Feb 24, 1995 macro for Version 3 won't work with the restructured data

records in Version 4 - you get no error, but bad values,

most notably for TASCPUTM.

Thanks to Simon Wu, Southern California Edison, USA.

Change 12.313 TCP/IP error INVALID DATA FOR TELLOGFT encountered at one

VMACTCP site; the 8-byte field added by APAR PN34837 did not have

Feb 23, 1995 a valid date-time-stamp. To eliminate the message, I put

double questionmarks between TELLOGFT and SMFSTAMP8.

Thanks to Barbara Rask, University of North Dakota, USA.
Change 12.312 INPUT STATEMENT EXCEEDED for LANSPY type D record because

VMACNSPY the path segments were not correctly skipped. Inside the

Feb 23, 1995 IF LDLANMAX GT 0 THEN DO; group, after the @;, insert

OFFNSPY=OFFNSPY+LDLANMAX*28;

to move the pointer over the path segments.

Thanks to Mr. Dechamps, R&V Versicherung, GERMANY.

Change 12.311 Early MXG 12.12 only (dated 20Feb95). IEBUPDTE step had

VAXPDS return code of 4, because the "./" in VAXPDS should have

Feb 23, 1995 been changed to "xy".

Thanks to Glenn Harper, Memorial Hospital, USA.

Change 12.310 RMF CPU reporting is now consistent with new APAR OW07986

ANALRMFR (MVS/ESA 5.1) or OW05435 (MVS/ESA 4.3). "CPU ACTIVITY"

Feb 22, 1995 REPORT column showing the CPU busy time percentage (

column header "BUSY TIME PERCENTAGE") has been replaced

by a column showing now the LPAR CPU utilization (new

column header "LPAR BUSY TIME PERC"). In case of an LPAR

system this column contains the same values as in

previous versions. In case of a basic mode system, dashes

are shown here. The previous column showing the wait time

( column header "WAIT TIME PERCENTAGE") has been replaced

by a column showing the MVS view of the CPU utilization (

column header "MVS BUSY TIME PERC"). The wait time is no

longer shown on this report.

Thanks to Bruce Widlund, Merrill Consultants, USA.

Change 12.309 Xerox Print Services Manager SMF record has been further

FORMATS enhanced and validated. The first 3 downtime segments

VMACXPSM are kept (if you find you need more, let me know), and

Feb 22, 1995 the font list and forms list are now decoded.

Change 12.308 Support for RMDS 2.1 has now been validated with read SMF

VMACRMDS data; some datetimes were missing because all of the YYYY

Feb 22, 1995 inputs should have been &PIB.4. instead of &PIB.2.; the

input of RMDSALC and RMDSPAGE for RMDSORG='1' should have

been &PIB.4. instead of &PD.4. (I guessed wrong!); and

some datetime calculations in the old 1.3,1.4 code were

moved to eliminate missing value messages on the log.

Thanks to Wolfgang Vierling, Vereinte Versicherungen, GERMANY.

Change 12.307 Some dates/times were wrong because Change 10.176 was

VMACFTP only partially implemented; PIB4. should have been PIB4.2

Feb 20, 1995 and the DATEJUL() was missing in DHMS functions.

Thanks to Waldemar Schneider, SAS Europe, GERMANY.

===Changes thru 12.306 were printed in MXG Newsletter TWENTY-SEVEN=====
Change 12.306 Support for DB2 Trace Records sent to GTF is provided by

REXXDB2 this user contribution, in REXX, which will read the GTF

VMACSMF records (which are uniquely segmented) and reconstruct a

Feb 18, 1995 valid, un-segmented SMF format type 102 record that can

be processed by conventional MXG code. (DB2 type 102

records that happen to fit in one 255-byte segment can

already be processed, but most of the interesting data is

in longer records, and I had contracted with a slick ASM

programmer to write me an Assembly routine to do exactly

what this slick REXX program does!) I have modified the

GTF macro in VMACSMF to at least now tell you that a

spanned record was deleted - Clyde was justifiably

frustrated when he first tried to use vanilla MXG code

against GTF data, and MXG did not tell him that those

spanned records could not be handled and were deleted!

Thanks to Clyde Thompson, Australian Taxation Office, AUSTRALIA

Change 12.305 -ANALDB2R provides DB2 Version 3.1 reports for PMACC02

ANALDB2R (Accounting Detail Report), PMSTA02 (Statistics Summary

ASUMDB2A Report), and PMSTA01 (Statistic Detail Report), the last

TRNDDB2A now uses the DB2STATS. PMACC02 does not yet include

TRNDDB2B detail stats on each of the new buffer pools; that will

TRNDDB2S be available in the next MXG release, as will package

TRNDDB2X report support. These new DB2 reports take many more

VMACDB2 pages per group, so be cautious and select carefully!

Feb 20, 1995 -ASUMDB2A, TRNDDB2A, and TRNDDB2B were changed to now keep

Oct 19, 1995 new DB2 3.1 variables needed for ANALDB2R reports.

-TRNDDB2S now uses PDB.DB2STATS instead of the (archaic

DB2STAT0, DB2STAT1, and DB2STAT2 datasets, (ANALDB2R also

now uses PDB.DB2STATS for statistics reports). Instead

of creating the old TRNDDB20/TRNDDB21 datasets, TRNDDB2S

now summarizes into TREND.TRNDDB2S. You can convert your

old TRNDDB20/TRNDDB21 datasets into the TRNDDB2S with a

one-time execution of the UCVRTDB2 program.

-New member TRNDDB2X trends the eXtra statistics for each

buffer pool from PDB.DB2STATB data. Revised 10/19/1995.

-VMACDB2 was changed to add variables to DB2ACCTB that are

needed by ANALDB2R (and should have been kept already!).

-The DB2STAT0, DB2STAT1, DB2STAT2, TRNDDB20, and TRNDDB21

datasets should be replaced in your reporting with either

PDB.DB2STATS or TREND.TRDNDB2S, as only these latter two

datasets will continue to be enhanced. Fortunately, the

statistics datasets are physically small, so keeping the

redundant data in your PDB is better than removing it now

(and possibly causing an avoidable ABEND)!

Thanks to Chuck Hopf, Merrill Consultants, USA.
Change 12.304 XMXGSUM, a much faster and leaner replacement for VMXGSUM

XMXGSUM has all errors fixed (the last fix UPCASED all variables)

Feb 18, 1995 and has been heavily tested. However, because VMXGSUM is

so pervasive in MXG ASUM/TRND/ANAL members, I decided to

leave VMXGSUM intact and deliver XMXGSUM as a separate

member so you would not be accidentally burned. If you

have lots of CICS/DB2 data being summarized by MXG, I

strongly urge you to test XMXGSUM in place of VMXGSUM,

because it runs much faster and uses much less CPU and

DASD when there are lots of data and variables read and

only a few kept. (You can test simply by copying XMXGSUM

into your USERID.SOURCLIB, renaming it therein to VMXGSUM

and running your test programs, because internally it is

VMXGSUM!). However, do not use OPTIONS OBS=nnn with the

new XMXGSUM without reading this detail techie note:

XMXGSUM figures out what variables are really needed

and what variables exist to create a KEEP= list. We

use a PROC CONTENTS of all of the datasets in the

INDATA= parameter to create the list of unique

variable names. If OPTIONS OBS=nnn is in effect, and

if nnn is less than the total number of variables,

unpredictable failures will occur (or no failure with

incorrect values!). created. To prevent these

problems, never set the OBS= to be less than the sum

of the number of variables in the combined INDATA=

datasets or (a better choice) set OBS back to MAX

after selecting the data you want to summarize. A

dataset with 0 obs and a non-existent dataset look the

same (because there is no SAS facility to determine if

a dataset exists). If the dataset does not exist,

then PROC MEANS abends because its expected variables

are not found. Now, an observation is forced so the

number of variables can be used to tell if you made an

mistake (i.e., you referenced a non-existent dataset

for input) or if there just happened to be no

observations (when we go ahead and create the expected

zero-obs output dataset).

Thanks to Chuck Hopf, Merrill Consultants, USA.

Thanks to Diane Eppestine, Southwestern Bell, USA.
Change 12.303 Analysis of tape mounts pending using the MXG Tape Mount

ANALMTP monitor TYPETMNT data and the new %ANALCNCR concurrency

Feb 18, 1995 analysis tool gives you average and maximum number of

tape mounts outstanding across the day, with built-in

graphs! A fine example of the power of %ANANCNCR!

Thanks to Chuck Hopf, Merrill Consultants, USA.

Change 12.302 ANALCNCR enhanced to permit multiple MAX= variables and

ANALCNCR multiple COUNT= variables. If no MAX= is used and there

Feb 18, 1995 are COUNT= variables, then the MAX variables will be

MAX1-MAXn where n is the number of COUNT= variables used.

MAX= is positional, and the variables listed will be the

MAX of the same positioned variable in the COUNT= list.

If you don't use MAX= and ask for a summary, then the

MAXCNCR variable will contain the MAX value for the

things you are counting.
Change 12.301 Support for VAX Accounting Data and even some Performance

VAXPDS reports are provided in this user contribution from the

Feb 18, 1995 Australian creators of "The Bill". Member VAXPDS is

really a 12-member PDS in IEBUPDTE format (the first few

lines give you the JCL example to create MXG.VAX.SOURCLIB

PDS from member VAXPDS. I have not tested this code, but

it is self explanatory (read comments in each member to

understand what it does) and has been used by several VAX

sites in Australia, so I anticipate no surprises!

Thanks to Brian Jennings, Pacific Management Systems, AUSTRALIA.

Change 12.300 SYNCSORT has permitted up to 32 SORTWORK DDs, but MXG did

VMACSYNC not decode statistics for 13th-32nd. I have added code

Feb 17, 1995 to INPUT the 13th-32nd sets of variables, but I did not

add the new variables to the KEEP= list in VMACSYNC, as

I really don't think anyone uses that many DDs! If you

really need the extra variables, they can be added using

the _KTYSYNC macro in IMACSYNC (see Change 10.175 for the

general instructions for using _K macros to add/drop

variables to MXG datasets). This was only an MXG change;

while there is a new release 3.6 of SYNCSORT, it made no

changes to their SMF record.
Change 12.299 Support for CICSAO user SMF record written by CICSAD,

EXTYCIAO added by APAR PN06426, provides CICS availability info,

FORMATS in new dataset TYPECIAO, reporting for each CICS region

IMACCIAO under CICSAO control when CICSAO started or shutdown a

TYPECIAO particular region, and when that CICS actually completed

VMACCIAO that function. If the region halts (becomes unusable) or

Feb 15, 1995 is unhalted, that event too is recorded.
Change 12.298 The JCL example for the MXGTMNT PROC did not contain an

ASMTAPES //SNAPOUT DD SYSOUT=C

Feb 15, 1995 causing the monitor to fail at startup. Now it does.

Thanks to Shaheen Pervaiz, Acxiom, USA.

Change 12.297 SAS errors "OBJECT FILE OUT OF SPACE" is an indication

CONFIG that you do not have enough virtual storage, either the

CONFIG07 MEMSIZE in your CONFIG member is too small or the REGION

CONFIG08 parameter on your JOB card is too small. MXG 12.12 does

Feb 15, 1995 require slightly more virtual storage (because of the

additional datasets/variables for MVS/ESA 5.1), and if

you were just below the limit prior to MXG 12.12, you may

fail just due to MXG 12.12. I have raised the default in

CONFIG to 48M to hopefully minimize this occurrence.

Thanks to Shaheen Pervaiz, Acxiom, USA.

Change 12.296 DEBUG messages were printed on the SAS log for some MIM

VMACMIM records; the PUT statement writing these messages should

Feb 15, 1995 have been deleted.

Thanks to Shaheen Pervaiz, Acxiom, USA.

Change 12.295 Support for RDS, Remote Device Support, for Network

EXTYRDS1 Systems Corp. DXE Channel Extenders user SMF record

EXTYRDS2 creates seven datasets:

EXTYRDS3 TYPERDS1 - Device Class Descriptions

EXTYRDS4 TYPERDS2 - Path Descriptions

EXTYRDS5 TYPERDS3 - Device Throughput

EXTYRDS6 TYPERDS4 - Network Throughput

EXTYRDS7 TYPERDS5 - RDEVADPT Errors

IMACRDS TYPERDS6 - HOSTADPT Errors

TYPERDS TYPERDS7 - LINK Network Errors

VMACRDS Activity counts, bytes transferred, and other statistics

Feb 15, 1995 as well as errors are provided in these datasets.

Thanks to Christopher B. Calvin, Ahold Information Services, USA

Thanks to Benny Maynard, Ahold Information Services, USA

Change 12.294 Support for SAR Cross Memory/VTAM Region Session Logoff

EXTYSARS user SMF record contains statistics on storage used above

IMACSARS and below, CPU time, Getmains, etc., in new dataset

TYPESARS SARSESSN. Note that this is a separate SMF record that

VMACSARS can be created by SAR; the other record created by the

Feb 14, 1995 SARSRQU3 exit is supported by member TYPESAR et al.

Thanks to Miguel Trujillo, Salomon, Inc, USA

Thanks to Dov Brosh, Salomon, Inc, USA.

Change 12.293 CPU Utilization for each Performance Group is provided in

ANALPGNS this new, simple analysis algorithm which merges RMFINTRV

Feb 12, 1995 with TYPE72. Two measures of PerfGrp utilization are:

PGPCTCAP = Percentage of Capacity used by PERFGRP.

PGPCTUSE = Percentage of Active Time used by PERFGRP.

The denominator for Percent of Capacity is Duration times

Number of CPUs Online, while the denominator for Percent

of Active Time is the Capacity Duration times PCTCPUBY.

Which number you use depends on whether you want to know

how much of the installed capacity was used by a PERFGRP,

or how much of what was used by everyone was used by a

PERFGRP, so both numbers are provided. This sample will

likely be expanded into a full-blown %ANALPGNS member

with bells and whistles and summarization, but the basic

algorithm is provided in these initial 48 lines.

I have described how to do this scores of times; with

hindsight, this member should have existed years ago!

Thanks to Virginia Tsai, SAS Institute, TAIWAN.

Change 12.292 Support for OS/400 Version 3.1.0 AS/400 Performance Data

EXQAPIO1 records: completely INCOMPATIBLE!! Instead of appending

EXQAPIO2 new fields at the end of the existing records, new fields

EXQAPIO3 were inserted in almost every record, and some record's

EXQAPIO4 fields were reordered even when no new fields were added!

IMACQAPM Previously, MXG logic used LENGTH to identify the OS400

TYPEQAPM Version and hence data format, but QAPMDISK record was

VMACQAPM reordered with no change in LENGTH, so MXG now uses the

Feb 12, 1995 variable ASLEVEL (input from QAPMCONF and retained, which

is why _TQAPCON must always be executed first) to detect

data format.

While almost every other record was also changed, that

change was to insert two 2-byte packed decimal fields for

Bus Number and Bus Address. But those IOPB/IOPA variables

were already created in MXG from the existing 1-byte "IP

Address" (bits 0-2 = IOPB, bits 3-7 = IOPA, easily INPUT

with SAS's BITS informat)! Apparently, it was so hard

for other OS/400 programmers to decode these simple bit

values (dare I say "objects"?), that IBM Rochester had to

convert the bits to numbers and create two new fields for

them (which, of course, were then inserted, instead of

being appended to the end for compatibility)!.

And IBM's pub SC41-3306-00, pp A-14 to A-30, for the

QAPMSYS record, has completely wrong "Buffer Position"

values starting with location 507 of this 3090-byte

record - that was real fun to sort out!

All this from winners of the Malcolm Baldridge award!

In spite of the OS/400 developers inability to provide

compatible records across version changes, there is a

wealth of new data added to the QAPMSYS and QAPMJOBS

datasets, and the new QAPMIOPD record creates four new

datasets from SNADS:

QAPMIOP1 - File Server I/O Processor Pipe Task

QAPMIOP2 - OS/2

QAPMIOP3 - HPFS386

QAPMIOP4 - Lan Server

IBM now says QAPMIOP1 is Internal Use Only, and its

counters were incorrectly documented, and that even

if they were, you can't do anything about them, and

its description will be removed. However, since my

code was already done before I knew that fact, I

decided to leave the code in place with this caveat!

MXG Install note: YOU MUST ADD //QAPMIOPD DD DUMMY to

your existing QAPM job's JCL when you install MXG 12.12,

or that existing job will fail with a JCL error. Then,

when you install V3.1, you can change the DUMMY to the

real dataset, and MXG will automatically create obs in

the new QAPMIOPn datasets.

Yes, this is an incompatibility between MXG 11.11 and

MXG 12.12, that I could have avoided by commenting out

the invocation of _TQAPIOP in member TYPEQAPM, but then

you would have had to modify the source code to create

observations in the future, so I chose this JCL change

as the lesser of the two choices.

As of Newsletter 27 press time, the new 3.1 code had not

been tested with 3.1 data; only 2.2 data was available.

Change 12.291 ERROR. INVALID OFFSETS IN USER SEGMENTS with Landmark

TYPEMON8 CICS/ESA Version 1.1 records converted back to Version 8

TYPETMON format may result because MXG's test is true when the

Feb 11, 1995 offset in the record is greater than record length even

when there is no segment - the number of segments must be

added to the test. The three lines in TYPEMON8 now read:

IF FILECOL+FATNUM*TAFATLEN GT LENGTH+1 AND FATNUM GT 0 ..

IF UATCOL+UTNUM*TAUATLEN GT LENGTH+1 AND UTNUM GT 0 ..

IF MROCOL+MRONUM*TAMROLEN GT LENGTH+1 AND MRONUM GT 0 ..

The one line in TYPETMON now reads:

IF FILECOL+FATNUM*TAFATLEN GT LENGTH+1 AND FATNUM GT 0 ..

Thanks to Bill Padilla, Farmers Group, USA.

Change 12.290 Amdahl MDF will produce negative/trashed CPU values if

VMAC7072 you use the same LPAR number for different LPARs. The

Feb 10, 1995 error, introduced in microcode ML 6, has been fixed in

Amdahl's ML 8.09, and your SE can show you how to define

your IOCDS with a unique Partition Number, but you must

correct the error, or your CPU busy data is invalid.

Thanks to Dean Brown, Pacific Bell, USA.
Change 12.289 Amdahl MDF has been providing real MVS CPU utilization of

VMAC7072 "this" MVS in TYPE70 dataset since their microcode ML 6;

Feb 10, 1995 Change 12.288 added the PCTMVSBY/MVSWAITM fields which

contain the MDF "CPU using" time for "this" Domain.

A new MDF option, called "Wait Complete=No Reporting",

(available for ML 6, included as a feature in ML 8.09)

can store the Real CPU Active Time (instead of Dispatch

Time) into the TYPE70PR LPAR data segments in type 70.

You can tell that the option is enabled and the CPU times

are real if LCPUWAIT='N' (not enabled, LCPUWAIT='Y'), as

the 'N' record looks like a non-wait-completion PR/SM.

(Without the option, MDF LPAR measures are "dispatch"

time, not "CPU using" time, so you had to use Amdahl's

APAF to get the real CPU busy time of other LPARS. This

new option lets you now use TYPE70PR/ASUM70PR for real

CPU measures, using APAF data for deeper analysis.)

Jul 9, 1997: See Change 15.023 for update on option.
Change 12.288 PR/SM APAR OW07986 puts "MVS Wait" time back in type 70

VMAC7072 records, so the new variables PCTMVSBY MVSWAITM and

Feb 10, 1995 MVSWAIT0-MVSWAITF report the MVS view of CPU busy/wait

contrasting with the existing variables PCTCPUBY (LPAR

dispatch perspective) and PCTCPUEF (LPAR effective

perspective). Looking at one sites numbers, it appears

that the sum of the "MVS Wait" plus the sum of "CPU Eff"

plus the "Physical LPAR" is very close to total duration,

which implies that PCTCPUBY-PCTMVSBY is the true LPAR or

MDF overhead. The text of the APAR includes a complete

discussion of the differences between "MVS CPU Busy" in

PCTMVSBY and "LPAR CPU Dispatch" in PCTCPUBY.

Thanks to Boris Ginis, BGS Systems, USA.
Change 12.287 ITRF note. Candle has corrected the problems that

VMACITRF were reported in Newsletter 26, and the blank field for

Feb 10, 1995 RNJOB, etc., are now populated (except in the TYPE= '13'x

thru '16'x Database records, which being cut from the IMS

Control Region, have no associated Job information).

A small sample of their log records post-APAR have been

validated, and I have no reason to believe there are any

further problems, but as the Newsletter went to press,

the APARs were too new to have had stress testing, so I

would appreciate feedback from active ITRF users.

There was no change to the VMACITRF code; this change is

solely for documentation.

Change 12.286 Zero observations in dataset CISIZE can occur, because

ANALSMF the logic detecting that data was held was unrobust. The

Feb 10, 1995 test IF INCI4K=0 THEN DELETE; must be expanded to

IF SUM(INCI4K,INCI8K,INCI16K,INCI22K,INCI26K)=0 THEN ....

Thanks to Freddie Arie, Lone Star Gas, TEXAS.
Change 12.285 Support for Type 99 Subtype 1 has been added, creating

EXTY99TT two new datasets:

EXTY99U1 TYPE99TT - Trace Table Entries

VMAC99 TYPE99_1 - System State Information

Feb 9, 1995 Don found this data so useful in his CPExpert product,

that he shared his coding for this record!

Thanks to Don Deese, (CPExpert), Computer Management Sciences, USA.
Change 12.284 Support for IMF 3.1 (for IMS 5.1) is already in MXG 12.12

VMACCIMS because Boole expects there will be no significant change

Feb 9, 1995 in the format of the IMF records in their new version.

Some old MVS fields may be zero when MVS 5.1 is in Goal

Mode, but the fields will still be there, so the MXG code