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

is expected to be compatible.

Change 12.283 MXG 12.07 Only. TCP/IP records cause INVALID DATA FOR

VMACTCP VARIABLE NEW because the word NEW was accidentally left

Feb 8, 1995 in columns 1-3 of line 020100. Remove "NEW". (NEW was

left as a marker that I needed to add the new variable,

FTPSTRCT to the LABEL and KEEP= lists, so not only did I

fail to remove the NEW, I also failed to add FTPSTRCT

until this change. The syntax check passed because NEW

was just another variable to be INPUT; only when real

data records were read did the error surface.)

Thanks to Richard Clary, Entergy Services, USA.

Change 12.282 Support for Velocity Software's XAMAP Version 2.2 added

VMACXAM many new variables for VM/ESA 2.2, and a few variables

Feb 8, 1995 were renamed. This code has not been tested with actual

data. The new fields were added at the end of the record

so their new version appears to be compatibly made.
Change 12.281 ANALRACF's problem with PROC TRANSPOSE error will not be

ANALRACF corrected, because the enhancements in Change 12.280

Feb 7, 1995 eliminate the need for ANALRACF. The real error was in

my original design of TYPE80, which creates one

observation for each segment in each type 80 record, and

ANALRACF was one user's solution to rebuild each logical

event from the pieces; TYPE80A creates an observation for

each event, solving the need (I believe) for ANALRACF.

Change 12.280 RACF TYPE80A has always decoded RACF events, but this

EXTY8009 enhancement adds new datasets that decode RACF Commands

EXTY8010 that have been requested by Security Administrators (so

EXTY8011 they can generate RACFRW reports from MXG datasets!).

EXTY8013 Seven new datasets are added by this change:

EXTY8014 Dataset Command

EXTY8019 TYPE8009 - ADDGROUP command

EXTY8023 TYPE8010 - ADDUSER command

IMAC80A TYPE8011 - ALTDSD command

VMAC80A TYPE8013 - ALTUSER command

Feb 7, 1995 TYPE8014 - CONNECT command

TYPE8019 - PERMIT command

TYPE8023 - REMOVE command

TYPE80CM - RACF commands not decoded above.

Most of the fields in these command records are decoded,

but some are not; there are 2- and 4-byte bit maps (eg.,

for Keywords specified on the command, where one bit

is used per keyword), and rather than creating 32 or 64

more variables, I chose to store the field as a character

variable with $HEX format to save DASD space. Of course,

this means you must learn which bit does what, and thus

you must become familiar with IBM Table 3, "Data Type 6

Command-Related Data" in the RACF Macros and Interfaces

manual, SC28-1345, in SMF Records chapter, until I have

time to document these bit-maps in member ADOC80A.

TYPE80A should replace TYPE80/ANALRACF, because TYPE80A

creates an observation for each event, whereas TYPE80

creates an observation for each segment in each event,

and ANALRACF was created to reconstruct the events from

the segments! This code has been tested with RACF 1.9.2

data.

Thanks to Richard Banks, Texas Comptroller of Public Accounts, USA.

Change 12.279 DB2STATS can be used to audit if DB2 SMF records were

DIFFDB2 lost. DB2 counts log records written and not-written in

VMACDB2 two ways: by destination (GTF, SMF, etc. in MXG variables

Feb 19, 1995 QW1Bxxxx-QW9Bxxxx) and by writer (accounting, audit, etc,

in MXG variables QWS1xxxx-QWS8xxxx). With a simple:

PROC PRINT DATA=PDB.DB2STATS;

VARIABLES QW1B: QW2B: QW3B: QW4B: QW5B: QW6B:

QW7B: QW8B: QW9B: ;

you can scan the QWnBNM (Destination Name) for SMF, and

then examine QWnBSRNW for that "n" to determine if any

SMF records were lost. If there were records lost, you

can then use a simple:

PROC PRINT DATA=PDB.DB2STATS;

VARIABLES QWS1: QWS2: QWS3: QWS4: QWS5: QWS6:

QWS7: QWS8: ;

to examine which IFCIDs (QWSnIID) had lost records, and

see whether accounting, audit, stat or trace records were

not written. See MVS Technical Notes in Newsletter 27

for a discussion of why DB2 might lose SMF records.

Impress your auditors with your knowledge of the exposure

and that it is detectable!

-Variable QWACFLGS is now INPUT $CHAR2. (it was $CHAR1.)

and this also corrects the value of QWACPKGN.

Thanks to Chuck Hopf, MBNA, USA.

Change 12.278 ERROR.TYPE110.SUBTYPE 2, STID=57, SKIP=84 message and hex

VMAC110 dump on the log with CICS/ESA 3.3.0 results because there

Feb 7, 1995 are undocumented bytes observed at the end of record.

This diagnostic message has no effect on the type 110

processing, so your datasets were built correctly (it's

there so I can detect if IBM adds new, useful data, but

in this instance, they simply added nulls!), but the dump

on the log and the message can be eliminated:

Inside the DO group IF STID=57 THEN DO;

replace IF SMFPSRVR EQ 33.0 THEN SKIP=SKIP-336;

with IF SMFPSRVR EQ 33.0 THEN DO;

SKIP=SKIP-336;

IF SKIP GT 0 THEN DO;

INPUT +SKIP @;

SKIP=0;

END;

END;

Thanks to Bruce Widlund, Merrill Consultants, USA.

Change 12.277 Support for ACC/SRS, Allocation Control Center/Space

EXTYACC Recovery System (from Mitchem Technologies) user SMF

IMACACC record. SRS is like STOPX37; an SRS record is written

TYPEACC whenever SRS protected an x37 ABEND by adding secondary

VMACACC space. ACC controls dataset allocation and lets you

Feb 6, 1995 change anything on a DD card. The record is written when

either SRS recovers, or when ACC sends a message.
===Changes thru 12.276 were included in MXG 12.07 dated Feb 6, 1995===
Change 12.276 Continued enhancement to IBM-like RMF reports. The MXG

ANALRMFR device reports can be selected by:

Feb 5, 1995 SG =, Storage Class selection

DN =, Device Number selection

LCU=, Logical Control Unit selection

and Coupling Facility report can be selected by:

RSYSPLX=. Sysplex report selection.

Format MGRMFA3 was removed for variable LCU in the I/O

queueing report (it caused hex instead of decimal values)

and this edition supports more than two IOPIQIDs (using

PROC TRANSPOSE and ARRAY processing).
Change 12.275 The old analysis of tape drives, using PDB.STEPS was

ANALTAPE revised to use the new ANALCNCR macro to speed up the

Feb 5, 1995 analysis, but using the ASMTAPES MXG Tape Allocation

Monitor records and datasets PDB.TYPETALO and member

ASUMTALO is strongly recommended as more accurate.
Change 12.274 New analysis of initiator concurrent use (i.e., how many

ANALINIT jobs are concurrently in initiation), using ANALCNCR (see

Feb 5, 1995 Change 12.272). Unfortunately, there is no way to know

Feb 19, 1995 which initiator is actually used, but at least we can

determine how many jobs are waiting or running in any JES

job class. There are also some limitations to initiator

analysis. Jobs submitted into HOLD cannot be included in

measurement of jobs waiting, because we do not know when

the job was released from hold, so these jobs are deleted

(TYPERUN=HOLD) from the analysis. (Note that jobs that

are read-in and then later placed in HOLD cannot be

detected and are thus inadvertently included as queued.

You might be able to establish a criteria for queue time

that would let you identify these probably-held jobs -

like queue time greater than one hour for 15 minute job

class - and then delete these exceptions from analysis.)

For Duplicate Jobname hold, the job is not counted in the

input queue until the previously-initiated, same-named

job has ended. Finally, the analysis only applies if the

job observation in PDB.JOBS actually completed execution;

i.e., only if INBITS contains a J in the third position.

The analysis first separates held jobs from jobs to use,

and then invokes %ANALCNCR twice to count the number of

jobs in execute/queued/held/samename, and then these 4

datasets are merged for the report. Buckets are created

for distribution values of job counts, and you can change

the number and values of the buckets. The default values

are 5, 10, 15, 20, 25, 30 , 35, and > 35 jobs. ANALINIT

is designed for MXG's PDB.JOBS, but it shows how "open"

MXG routines are to point out that one MICS and MXG user

used ANALINIT with MICS's BATJOBxx dataset, simply

by replacing these MXG variable names with their MICS

counterparts:

MXG Variable MICS Variable

READTIME RDRTS

JINITIME STARTTS

JTRMTIME ENDTS

TYPRUN='HOLD' JOBHOLD GT 0

TYPETASK not applicable

INBITS not applicable

RDRTM JOBRDRTM

Thanks to ???,???, USA, who raised the question at CMG.

Change 12.273 Complete revision of the summarization of Tape Allocation

ASUMTALO using the ASMTAPES Tape Mount and Allocation monitor now

TRNDTALO uses ANALCNCR (See Change 12.272). Early test sites that

Feb 5, 1995 have previously used ASUMTALO/TRNDTALO will need to go

Feb 20, 1995 back and reprocess TYPETALO with ASUMTALO, because the

earlier version of ASUMTALO/TRNDTALO kept averages, but

this version keeps totals (like other ASUM... members).

In ASUMTALO, SAS Compression is turned off, just in case

you had turned it on. Because few variables are kept,

compression saved no DASD space, but caused a significant

increase in CPU time, 230 to 590 seconds with a million

observations as input. Because allocations are not

written until termination, TRNDTALO re-drives the week's

detail in TYPETALO back through ASUMTALO to eliminate the

overlap and increase the accuracy of allocation trends.

See ADOCTALO (when complete, hopefully in MXG 12.12 but

still in progress at press time) for more discussion.
This note was added after MXG Newsletter 27:

TRNDTALO was enhanced to 'fix' the problem of tape

drive allocations that are in effect when the SMF data

is dumped. Since this would be a daily occurrence,

detail data from the WEEK.TYPETALO is resummarized in

TRNDTALO, but since ANALCNCR runs quickly, the impact

is minimal. The duration of a shift is defined as the

actual shift duration as defined in your IMACSHFT

(whether or not we found data during all intervals).

To avoid the remaining overlapping allocations causing

data perturbations, if an interval has already been

summarized (it was in last weeks TREND database) the

duration, max, and buckets for incoming records from

the WEEK.TYPETALO will be set to 0. Thus, the

averages will be correct but (for those small number

of overlapping allocations) the MAX and buckets will

be slightly less than accurate.
Change 12.272 A powerful new MXG tool for the analysis of concurrency

ANALCNCR (how many tape drives, or initiators, or programs ... are

Feb 5, 1995 concurrently being used. Previously, I used brute force

to count concurrency; an observation with a start and end

time was exploded into many observations, with the time

incremented from start to end by a delta-value, and then

observations were summed by time to count concurrency.

Thus a one-hour step record would explode into 600 obs if

the delta-value was 6 seconds. While that algorithm was

accurate, its execution required lots of DASD and time.

When someone at CMG asked about initiator usage, Chuck

used VMXGSUM and the brute force approach in an example,

but I realized that a general purpose routine was really

needed, and then remembered the algorithm in my 1973

simulator (and also recalled that an MXG user had made a

similar suggestion long ago). I gave the algorithm to

Chuck, and the result is this fine new tool: %ANALCNCR.
This concurrency algorithm, instead of exploding obs and

summing by timestamp, creates only two observations per

event, one at the start, with a positive value of the

variable to be counted, and a second at the end, with a

negative value. Then, sorting and scanning by time,

adding or subtracting counts as events occurred in time,

the number of concurrent "things" is easily counted with

no explosion in the number of observations. Furthermore,

there is no delta-interval; the clock resolution of the

timestamp automatically counts any "thing" that exists

for more than one clock interval. The performance of

ANALCNCR over the old algorithm is phenomenal; ASUMTALO

with 860,000 records took only 20 minutes elapsed and 6

minutes of CPU time; the old logic took that time for

only 8000 records! Not only is ANALCNCR a stand-alone

analysis module, it is already used in MXG members

ASUMTALO,ASUMINIT, and ANALTAPE, with more to come!
The logic creates the "detail" data set with the count

value and the duration at that count value (and the

"detail" can have fewer observations than the number of

original events!), and ANALCNCR will (optionally, but

usually) summarize the "detail" data set into intervals

(eg. hourly), as well as creating percentage-of-time

distribution values. There are even canned printed and

plotted reports in Chuck's fine piece of work.

Thanks to Chuck Hopf, Merrill Consultants, USA.
Change 12.271 Further enhancements after stress tests of XMXGSUM (which

XMXGSUM will eventually replace VMXGSUM). The compiler fakers

VMXGSUM (IF X=. THEN X=.) which eliminated the UNINITIALIZED VAR

Feb 5, 1995 messages were removed, as they were causing dropped

variables to be re-created in the output data set.

If you used DATETIME=xxx and also used xxx in a MINTIME=,

MAXTIME=, or SUM= argument, xxx was inadvertently dropped

(error was introduced by Change 12.084 when the DROP of

DATETIME was added). A new argument, DSNLABEL= was added

to supply a label for the output dataset created. Lots

of effort went into the parsing logic that supports the

use of multiple input datasets that have data set options

(like IN=, KEEP=, END=), since we now force a KEEP=

option on the input datasets to improve performance and

minimize work DASD space. KEEPALL= and DSNLABEL= were

also added to VMXGSUM for consistency.

Thanks to Diane Eppestine, Southwestern Bell, USA.

Thanks to Roger Zimmerman, Kemper Financial Services, USA.

Change 12.270 DB2PM-like Locking Reports were revised, now using IFCID

ANALDB2R 172 for Deadlock/Timeouts, and syntax errors in PMLOK02

Feb 5, 1995 (missing END) were corrected, and PMLOK03 was revised.

See also Change 12.250.

Change 12.269 Preliminary support for Boole & Babbage's CMF VSAM MMR

EXCMFVAS Historical Records creates 24 new datasets, but only the

EXCMFVCA two most important datasets are complete (CMFVASRE and

EXCMFVCP CMFXDRE). Others will be supported as-requested. These

EXCMFVCX datasets are created directly from the VSAM file:

EXCMFVDI CMFVAS - Address Space

EXCMFVDM CMFVCA - Cache

EXCMFVDX CMFVCP - CPU

EXCMFVEN CMFVCX - Channel Path

EXCMFVES CMFVDI - Dataspace Info

EXCMFVIS CMFVDM - SRM Domains

EXCMFVLP CMFVDX - Device

EXCMFVLX CMFVEN - Enqueue

EXCMFVPD CMFVES - ESTORE Criteria

EXCMFVRW CMFVIS - Interval Summary

EXCMFVSC CMFVLP - LPAR/Domain

EXCMFVSD CMFVLX - LCU

EXCMFVSM CMFVPD - Page Data Sets

EXCMFVSP CMFVRW - Resolve Warnings

EXCMFVSS CMFVSC - SYSID CPU

EXCMFVSU CMFVSD - Swap Data Sets

EXCMFVSY CMFVSM - SMS Storage Group

EXCMFVWK CMFVSP - SYSID Paging

EXCMFVWT CMFVSS - SYSID Swapping

EXCMFVWU CMFVSU - SYSID Summary

IMACCMFV CMFVSY - Global SYSID

TYPECMFV CMFVWK - Workload

VMACCMFV CMFVWT - Wait/Use Summary

Feb 18, 1995 CMFVWU - Wait/Use

Feb 23, 1995 See comments in member VMACCMFV for testing status.

There's lots and lots of data here.
Change 12.268 Support for BGS's BEST/1 I/O Monitor SMF record adds four

EXBGSCPU new datasets:

EXBGSDEV B1MONCPU - I/O Interrupts by CPU

EXBGSMON B1MONDEV - I/O Interrupts by Device

EXBGSPGN B1MONMON - Resources consumption of the B1MON itself

IMACBGSI B1MONPGN - I/O Interrupts by Perf Grp by Device

TYPEBGSI Their monitor is a powerful tool for I/O analysis.

VMACBGSI This code has only been bench checked with a hex dump.

Feb 4, 1995
Change 12.267 Support for Xerox Print Service Manager user SMF record

EXTYXPSM adds new dataset TYPEXPSM which tracks print and CPU

FORMATS resources, with lots of good quality data for managing

IMACXPSM and measuring print activity with XPSM. New records

TYPEXPSM with fixes for all reported problems is in hand, but it

VMACXPSM won't be tested before the Newsletter deadline, so check

Feb 4, 1995 this text in member CHANGES of MXG 12.12 for an update.

Thanks to Tom Bell, Rivendel Consulting, USA.

Change 12.266 If you use TYPEMON8 to process Landmark records that were

TYPEMON8 converted back to Version 8 format from CICS/ESA 1.3 data

Feb 4, 1995 TYPEMON8 fails with invalid records. Their conversion PGM

adds unexpected records at the beginning of the file with

value of 'HH' in TMMDREC. Expanding the test to read:

IF TMMDREC='DD' OR TMMDREC='HH' THEN DELETE;

appears to have resolved the problem. (Of course, the

real solution is to read the native 1.3 records with new

support in MXG's new TYPETMON member; see Change 12.151.)

Thanks to Bill Padillia, Farmers Group, USA.

Change 12.265 IMF variables ABENDSYS/ABENDUSR in CIMSPROG dataset were

VMACCIMS incorrectly documented and wrongly input. Instead of the

Feb 4, 1995 expected two-byte hex fields for each, the codes are in

a four byte field with value xxsssuuu, so the variables

are now input @90 for ABENDSYS and @91 for ABENDUSR, and

these two lines were inserted after the @; after INPUT:

ABENDSYS=FLOOR(ABENDSYS/16);

ABENDUSR=MOD(ABENDUSR,4096);

Thanks to Mel Lallement, Cessna Aircraft, USA.
Change 12.264 Support for RMDS Version 2.1 (completely incompatible!).

IMACRMDS Not only were the key values changed from alphabetic to

VMACRMDS numeric, but also the detail directory data from the

Feb 3, 1995 Archive activity no longer exists, so there are 46 fewer

variables in Version 2.1 than in Version 1.3/1.4. I have

removed those 46 variables from the KEEP= list for the

dataset TYPERMDS, but those variables are now in member

IMACRMDS, in a comment block inside macro _KTYRMDS, so

if you are still on the old release and want them kept,

you simply remove the comments and all 46 additional

(and now archaic!) variables will be kept. Seven new

variables were also added by RMDS 2.1. Fortunately, I

can recognize Version 2.1 records internally, so it is

not necessary to update macro _RMDSVER in IMACRMDS to

tell me you have installed Version 2.1 (although _RMDSVER

still is used for Version 1.2 versus Version 1.3/1.4).

The new version has set a world record for the largest

number of bytes to hold a date-time field; the previous

12-byte format (YYMODDHHMMSS) was expanded to 26 bytes:

YYYY.MO.DD.HH.MM.SS.uuuuuu (with microsecond resolution)!

Change 12.263 Support for TPX 4.0 SMF record adds 9 new TPX datasets:

EXTPXASS TPXASSIS - User starts/ends session assist session.

EXTPXCOI TPXCONFI - User inits/terms conference session.

EXTPXCOJ TPXCONFJ - User joins/leaves conference session.

EXTPXGRA TPXGRANT - User grants temporary view authority.

EXTPXPLY TPXPLYBK - User starts/ends playback session.

EXTPXREC TPXRECRD - User starts/ends record session.

EXTPXTRI TPXTRNGI - User init/terms training session.

EXTPXTRJ TPXTRNGJ - User joins/leaves training session.

EXTPXVIE TPXVIEW - User starts/ends session view session.

IMACTPX These new subtypes were added compatibly, but the TPX

VMACTPX version number change will cause an MXG error message

Feb 1, 1995 "Unrecognized TPX Version=4.0". Until you get the new

version with full support, you can circumvent that error

by inserting a line reading

ELSE IF TPXVER=:'4.0' THEN TPXVER=' 4.0';

after the similar ELSE IF TPXVER=:'3.5'.... statement.

Thanks to Warren Hayward, TJX Companies, USA.

Change 12.262 Zero observations in dataset CACHE90 with RAMAC devices

VMACACHE behind both 3990-3 and 3990-6 cache controllers because

Feb 1, 1995 CLEN (IBM field RF8CLEN) has zero value. Insert the

statement IF CLEN=0 THEN CLEN=108; after the statement

INPUT @OFFDATA+15 CLEN &PIB.2. @;

as a circumvention while we still pursue the IBM error.

Thanks to Miguel Sanchez, Florida Power and Light, USA.

Thanks to Harry Price, Florida Power and Light, USA.

Change 12.261 Support for APAR OW05435/OW07895 adds new variable

VMAC79 R793CUT to dataset TYPE793, but no format for the data

Jan 29, 1995 was given - I have guessed it's really CPU time, but am

pursuing with IBM.

Change 12.260 Reserved Change Number.

Jan 29, 1995

Change 12.259 Replacement support for TYPEZRB RMF Monitor III VSAM data

ASMRMFV for MVS/ESA 4.3 is tested for DSIG3, SSHG3, ASIG3, GEIG3

IMACRMFV & DVTG3 tables and work is planned for the UWDG3, CSRG3,

TYPERMFV & PGPER tables - both the ASMRMFV assembly program and

VMACRMFV the VMACRMFV SAS programs must be changed to support the

Jan 29, 1995 additional segments, but their DSECTS are missing

Feb 20, 1995 -RMF VSAM data is now compressed, so you must assemble the

program ASMRMFV (in member ASMRMFV) for the 2-step job:

-ASMRMFV reads the VSAM file from DDNAME of RMFVSAM,

invokes IBM's Data Set Decompression Interface Service

module (ERB3RDC) to decompress the data, and then writes

each section as a logical record to the output RMFBSAM

DDNAME, which is a temporary file on DASD.

-TYPERMFV reads the INFILE of RMFBSAM to create the MXG

datasets (all starting with ZRB....., and the dataset

names and variable names are the same as those created

by the original TYPEZRB code). In the example JCL below,

the output MXG datasets will be written to the DDNAME of

ZRBPDB because of the USER=OPTION on the EXEC statement.
-First, assemble the ASMRMFV program into YOUR.LOADLIB.

-Second, use this JCL:

//ASMSTEP EXEC PGM=ASMRMFV

//STEPLIB DD DSN=YOUR.LOADLIB,DISP=SHR

//RMFVSAM DD DSN=YOUR.VSAM.RMFIII.DATA,DISP=SHR

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

// DSN=&&BSAMRMF,DISP=(,PASS)

//MXGSTEP EXEC MXGSAS,OPTIONS='USER=PDBZRB'

//RMFBSAM DD DSN=&&BSAMRMF,DISP=(OLD,DELETE)

//PDBZRB DD DSN=YOUR.OUTPUT.PDB.LIBRARY,DISP=(,CATLG)

%INCLUDE SOURCLIB(TYPERMFV);
All storage variables that contained FRAME counts were