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

12 TYPE9212 MMAP

13 TYPE9213 MUNMAP
Change 17.200 Support for IBM's TPF Operating System.

EXTPFxx Forty datasets are created from the fifty or so records.

FORMATS Some datasets are written at monitor initialization to

IMACTPF map things, but the interval records are deaccumulated

TPFINTRV and written as individual PDB datasets, and then TPFINTRV

TYPETPF is invoked to summarize into PDB.TPFINTRV. This support

VMACTPF has been tested with data from one system, and TPFINTRV

VMXGINIT intervals the SA/NX/SX/SU/SP/MD/MG/FV/FS/SC records.

VMXGTPFI This is preliminary support, but TPFINTRV and its input

Aug 2, 1999 datasets have been tested extensively; there are still a

number of questions and some variable names may change.

For over two years I have requested the DSECTS for the

TPF records; it took a vote of the TPF Users Group to

"convince" IBM it would be worthwhile to allow MXG to

support this high-speed transaction processing system.

Formerly know at the Airline Control Program, it can

drive 30,000 I/Os per second on an 8-engines CPC!

The initial development of the VMACTPF code took 40 hours

across four days to write about 4,000 lines of SAS code.

Another 40 hours were required to add the roughly 400

lines to deaccumulate and validate the PDB.TPFINTRV data.

Thanks to Jack Opgenorth, Sabre, USA.

Thanks to Linda Tallent, Sabre, USA.
Change 17.199 Support for APAR OW39128 adds DSNAME to SMF type 80-2

VMAC80A Resource Access event, so that you can tell what library

Aug 2, 1999 an audited controlled program was loaded from! So if

you need to know which program library is being used by

which users for which programs, you can use RACF to

control access and write a record for each successful

or failed attempt to run that program and finally know

which STEPLIB dataset was actually used by that job!

Variable RPDSNAME is added to dataset TYPE8002. The APAR

also populates variable VOLSER in the DTP=15 section for

this case, but that variable is already in TYPE8002.
Change 17.198 Variables that contain '00'x, when printed across VTAM or

VMAC110 downloaded as a text file from MVS to your PC, can cause

Aug 2, 1999 the download to stop. Other unprintable characters in

a PROC PRINT output can make your PC see an end-of-file

long before the real end of the file. When these values

are seen for a character variable, it is either formatted

with a HEX/$HEX format, or if the variable is normally a

printed variable that maybe has nulls at the end, then

the TRANSLATE function is used to convert nulls to blank

values. Variable SMFSTRTK was formatted $HEX16. and the

variables A13LVW, A17FLOC, A17DTTYP, A17DT, and DS5TCBNM

have any nulls translated to blanks.

Change 17.197 Starting from ANALDSET, this new ANALJOBE, "Job Events"

ANALJOBE adds to the 14, 15, 64, and 30s, the information from the

Aug 2, 1999 the VSAM type 62 OPEN time, the statistics from the type

Aug 12, 1999 42 subtype 6 TYPE42DS close, and the type 30 interval

records are used to capture PROGRAM name for Started

Tasks and long running steps whose step termination type

30 has not yet been seen. Additionally, if new datasets

were cataloged, the 61/65/66 SMF records in TYPE6156

identify that activity. The result will be a tool to

examine every timestamp in the life of a job, for delay

analysis, etc. This phase is complete, but HSM is soon

to be added.

And ANALJOBE is a single step, cleaner implementation:

When ANALDSET was first written in 1976, tape had to

be used because of data volume, and frequent system

crashes were circumvented by using multiple steps, so

a recovery might not have to re-read the SMF data

again!. Reliability, cheaper DASD, and better code

makes that unnecessary: two days SMF data opens used

than 1000 Cylinders (a/k/a 750 MB) of //WORK space.

The output dataset of this algorithm, ANALJOBE, may be,

in a future program, merged into the ASUMTAPE dataset to

identify the first-open-time and last-close-time of each

tape dataset, to identify where FREE=CLOSE can be used to

save tape drives.

Thanks to Chuck Hopf, MBNA, USA.

Change 17.196A If the CPMF segment exists in the record, but SMF73CMG,

VMAC73 the CPMF Measurement Group is 0, MXG did not skip over

Aug 2, 1999 the CPMF segment, and stopped reading Channels at CHPID

'55'x (one third of 'FF'x, because the old segment was

24 bytes long, the new is 72). Also, variables CHANIND

CHANINDX CHANINDY SMF73CPD SMF73FG5 are now hex format.

Thanks to Dr. H. Pat Artis, Performance Associates, USA.
Change 17.196 Dataset CONTROLD variable ACCOUNT2 is renamed CTLDACCT,

VMACCTLD so that its label does not override the real ACCOUNTn

Aug 2, 1999 field if CTLD records are processed with BUILDPDB. The

label as changed from second to first, as CTLDACCT has

(in ten fixed bytes) the first account field.

Thanks to Mike Penlington, Westpac Truse, NEW ZEALAND.

Change 17.195 Support for STK's VTCS 2.2.0 INCOMPATIBLE change to VSM

VMACSTC SMF subtype 13-26 records. Version 1 timestamps used the

Aug 2, 1999 unix epoch of 1/1/1970, which MXG handled, but now their

developers decided to waste my time and your time by

changing what was working just fine, back to what it

should have been in the first place, a TODSTAMP8 format.

And it doesn't appear that they put a version indicator

in their record, so I have to test each subtype to see

which version you have installed. And because at least

one field (VTV time) was not changed to TODSTAMP, I have

to test each of those timestamps in case they change the

format again! The test uses the first four bytes of the

timestamp, an algorithm that won't fail until Sep, 2042,

when the TOD clock wraps. Hopefully, STK will have added

a version indicator in their record before then.

Thanks to Sue Yarker, Midland Bank a/k/a HSBC, ENGLAND.

Change 17.194 The MXG 16.04+ revisions to HP Measureware did not define

VMACMWUX macros _HPUXCPU and _HPUXDLM in member VMACMWUX, and the

Aug 2, 1999 examples in IMACMWUX were commented out. The correction

was to define the macros in VMACMWUX, so that they are

defined by default in the VMAC, so they can be tailored

in the IMACMWUX, IMACKEEP or with %LET MACKEEP=. logic.

Thanks to Glenn Delvecchio, Stelco Inc, CANADA.
Change 17.193 -Using INTERVAL=NONE caused a warning message that the

VMXGSUM VARIABLE DATETIME IS UNINITIALIZED with no other impact.

Aug 2, 1999 The warning message is eliminated by this change.

-Using a dashed-list of variables in the NORM= argument

could cause errors messages about &EVAL function or

extra variables to be created, but only if there was

more than one dash per line and/or blanks around the

dash. Now the parser handles dashed-lists and blanks.

Change 17.192 The BY list for TYPE42DS needed DEVNR added to the end of

VMAC42 the list to fully protect for duplicate records.

Jul 30, 1999

Thanks to Chuck Hopf, MNBA, USA.

Change 17.191 Comments. The Subtype 5 Interval record is automatically

ASMTAPEE synchronized with SMF ENF Event 37, so there is no longer

Jul 28, 1999 a need to issue the console command to synchronize.

Thanks to Dr. Alexander Raeder, Karstadt AG, GERMANY.

Change 17.190 The SPIN.SPINMOUN and SPIN.SPINALOC datasets were not

ASUMTAPE copied into the PBD library (for backup and recovery),

Jul 28, 1999 but now they are.

Thanks to Freddie Arie, Lone Star Gas, USA.

Change 17.189 Member DIFFDB2 is automatically invoked by TYPEDB2, and

DIFFDB2 it separately listed the _Sdddddd macro for each dataset

VMACDB2 to be sorted/deaccumulated, which works fine, until you

Jul 27, 1999 try to create only dataset DB2ACCT. You can null all DB2

datasets with the _NDB2 macro, and can reinstate DB2ACCT

with the MACRO _WDB2ACC redefinition, but then DIFFDB2

fails ("NO DATASET OPEN TO LOOK UP VARIABLES") when it

tries to sort the non-existent datasets. You can fix the

design flaw by nulling out each of the individual sort

sort macros that are listed in DIFFDB2:

%LET MACKEEP= _NDB2

MACRO _WDB2ACC DB2ACCT.DB2ACCT %

MACRO _SDB2ACP %

MACRO _SDB2ACB %

MACRO _SDB2ACG %

MACRO _SDB2PAT %

MACRO _SDB2ST2 %

MACRO _SDB2STB %

MACRO _SDB2STR %

MACRO _SDB2STS %

MACRO _SDB2PST %

;

%INCLUDE SOURCLIB(TYPEDB2);

to build only the DB2ACCT.DB2ACCT dataset. However, to

correct the design flaw, the definition of MACRO _SDB2

in VMACDB2 was changed so that it does not sort the

DB2ACCT dataset (just like _S110 doesn't sort CICSTRAN)

and DIFFDB2 now invokes _SDB2 instead of all of the

individual _SDB2ddd macros, so now (17.05+) you can use:

%LET MACKEEP= _NDB2

MACRO _WDB2ACC DB2ACCT.DB2ACCT %

MACRO _SDB2 %

;

%INCLUDE SOURCLIB(TYPEDB2);

to create only DB2ACCT.DB2ACCT. And this protects you

for future datasets, and they will be listed in both the

_NDB2 and _SDB2 macro definitions.

Thanks to Alastair Gray, Phillip Morris International, SWITZERLAND.

Change 17.188 This user contribution was posted on MXG-L; it reads the

USTKVOL output of the StorageTek Volume Report utility to find

Jul 26, 1999 the date when each volume was mounted in the ATL, and the

the date when each volume was mounted in the ATL, and the

example invokes MXG member TYPETMS5 and appends the ATL

data with the TMS information on each volume.

Thanks to Clark Jennings, Reynolds Metals Company, USA.
Change 17.187 The MXG Test JCL stream step TESTOTHR fails in VMXGTAPE

JCLTEST6 because SAS option USER=PDB had been added to their JCL.

Jul 26, 1999 Don't do that to this JCL example that didn't expect it!

A comment has been added to the member.

Thanks to Dr. Alexander Raeder, Karstadt AG, GERMANY.
Change 17.186 IBM RMF Report replicator example used TYPE74OM dataset

ANALRMFR to now produce their OMVS KERNEL ACTIVITY REPORT.

Jul 22, 1999
Change 17.185 IBM's sample IXGRPT1 for SMF type 88 Logger records is

ANAL88 now replicated in this example report program that uses

Jul 21, 1999 both TYPE88 and TYPE8811 datasets.
Change 17.184 Revision to correct ZEROOBS= argument, which did not work

UTILBLDP in the prior version. Further updated August 3.

Jul 21, 1999

Thanks to Mike Utting, Hitachi Data Systems, AUSTRALIA.

Change 17.183 Continued IMS Log enhancements for Fast Path transactions

TYPEIMS is revised and made available for testing.

VMACIMS

Jul 21, 1999

Change 17.182 Numerous errors in OMVS/USS dataset TYPE74OM. MXG failed

VMAC74 to divide seven variables by NRSAMPLE, so they had large

Jul 21, 1999 values: OMVSSYSC OMVSCPU OMVSOPRP OMVSOUS OMVSOPRU

OMVSCURP OMVSCURU

And NRSAMPLE was not kept in TYPE74OM, but now is there.

Then IBM documented twelve fields as binary, but they in

fact contain s_float (RB4.) data, also causing largeness:

OMVSCMSG OMVSCSEM OMVSCSHM OMVSCSPG OMVSCMAP OMVSCPAG

OMVSOMSG OMVSOSEM OMVSOSHM OMVSOSPG OMVSOMAP OMVSOPAG

-A few labels had TOT or TOTAL for Average variables.

-Note that the IBM OMVS Kernel Activity Report prints

CPU time in units Hundredths of a Second, so a MAX CPU

of 8 on their report is actually .08 CPU seconds, which

is what MXG variable OMVSCTMX contains.

-RMF fields for Shared Memory, Memory Map Storage, and

Shared Storage are in bytes in the raw data, so MXG now

formats those variables with MGBYTES to show the true

MegaBytes, etc, but IBM still prints K or M after the

value for a factor of 1000 instead of 1024. For Shared

Storage actual value 32,768,000, IBM prints 32.8M, but

MXG prints that true size in megabytes as 31M.

Thanks to Ed Woodward, ADP/BSG, USA.

Change 17.181 Cosmetic. DCOLLECT variables DCDCUDSZ and DCDUDSIZ were

VMACDCOL correct, but their labels were reversed. DCDCUDSZ is the

Jul 21, 1999 Data Size AFTER compression, DCDUDZIZ the size BEFORE.

Thanks to Alan Winston, MBNA, USA.

Change 17.180 Support for APAR OW31701, "ESS Parallel Access Volumes"

VMAC74 adds new variables to TYPE74 and TYPE799 datasets:

VMAC79 PAVBASE ='PAV*DEVICE?'

Jul 20, 1999 NRALEXCH='NUMBER OF*ALIAS*EXPOSURES*HAS CHANGED'

Sep 12, 2000 SMF74PCT='SUCCESSFUL*PAV*SAMPLE*COUNTS'

SMF74TMS='TIME SKIPPED*IF NR*ALIAS EXP*WAS CHANGED'

NREXPOSR='NUMBER OF*UCBS FOR*PAV VOLUME'

Text of this change revised after change 18.096 added the

variable PAVBASE instead of old variable BASE.
Change 17.179 Using the 17.04 ANALRMFR against a 14.14-built PDB failed

ANALRMFR with VARIABLE SMF72QDT NOT FOUND; five variables added to

Jul 20, 1999 TYPE72GO (SMF72QDT/IQT/ADT/IOT/CVT) by later versions of

MXG were not protected for non-existence in ANALRMFR, but

now they are and it can be used against back-level PDBs.

Thanks to Normand Poitras, Banque Nationale du Canada, CANADA.

Change 17.178 New summarization member creates PDB.ASUM78CF dataset by

ASUM78CF summarizing dataset PDB.TYPE78CF for analysis of I/O

Jul 20, 1999 Configuration activity.

Thanks to John Meli, Queensland Rail, AUSTRALIA.

Thanks to Paul Dirkis, Queensland Rail, AUSTRALIA.
Change 17.177 Support for Control D release 5.1.4 has been confirmed,

VMACCTLD as there were no changes in the record format.

Jul 20, 1999

Thanks to Trevor Ede, EDS, NEW ZEALAND.

Change 17.176 OMVS (Open Edition/MVS), now USS (Unix System Services)

BUILD005 tasks create no purge records, so BUILDPB held their data

BUIL3005 in the SPIN library for SPINCNT days (in member IMACSPIN)

VMAC30 before they were OUTPUT into the PDB.STEPS and PDB.JOBS.

Jul 20, 1999 These OMVS tasks have SUBSYS='OMVS' but TYPETASK='STC '.

To output the OMVS tasks without purge records, BUILD005

and BUIL3005 were revised to detect and to not spin OMVS

tasks. To be consistent with its purpose, MXG variable

TYPETASK='OMVS' will now contain 'OMVS' for OMVS tasks.

You can fix the SPIN problem by using member IMACSPCK

by inserting: IF SUBSYS='OMVS' THEN OKFLAG=1;

until you install the version with this change.

Note that these JOBS/STEPS observations for OMVS tasks

are the TSO resources; the count of OMVS functions are in

the TYPE30OM dataset, which was not affected.

Thanks to Larry Ludwig, Northern Illinois University, USA.

======Changes thru 17.175 were in MXG 17.04 dated Jul 16, 1999======
Change 17.175 The preliminary IMS Log Enhancements in Change 17.172

ADOCIMS required one more tweak. The SubQ 6 time from the type

TYPEIMSA 7 record was being applied to the following transaction

VMACIMSA instead of the preceding transactio for pseudo/WFI or

Jul 16, 1999 Quick Reschedules, causing timestamps used to calculate

service times to be bad in occasional transactions.

Also, the member ADOCIMSX now exists in the MXG 17.04

dated Jul 16 that is now being shipped.

Change 17.174 IBM has confirmed Don's discovery that the R723CCHS

VMAC7072 (MXG variable PCTDLCHS) was trashed (like 600,000%!),

Jul 16, 1999 and will eventually fix their in counting those delays.

This correction recalculates by subtracting all of the

other wait fields so that PCTDLCHS will be valid with

or without the IBM correction.

Thanks to Don Deese, (CPExpert), Computer Management Sciences, USA.
Change 17.173 -Reading AS/400 data on ASCII platforms caused variable

VMACQAPM AS400SYN to be trash, because it wasn't converted from

VMXGINIT ASCII to EBCDIC when it was input as variable GDESS, but

Jul 15, 1999 inserting these two lines after the input of GDESS:

Jul 20, 1999 GDESS=INPUT(GDESS,$EBCDIC8.);

GDESS=TRANSLATE(GDESS,' ','80'X);

will create readable values for GDESS and AS400SYN.
-Also, WARNING: APPARENT SYMBOLIC REFERENCE LOLEVEL NOT

RESOLVED note is eliminated by the addition of LOLEVEL

in VMXGINIT as a GLOBAL macro variable with null value.

Macro variable LOLEVEL was used under MVS to pass the

lowest level of the DSNAME of the input file into an

MXG variable (AS400SYS in this case), because there

used to be no "System" name in the AS400 records.

Now, the MXG variable AS400SYN contains the system

name, so AS400SYS can be left blank.

-The include of member IMACKEEP was missing from TYPEQAPM

member, so tailoring in IMACKEEP was not recognized for

the AS/400 processing. It has now been added.

Thanks to Don Goulden, SAS Institute, USA.
======Changes thru 17.172 were in MXG 17.04 dated Jul 14, 1999======
Change 17.172 Significant enhancements to IMS log processing are now

ASMIMSLG available for testing. These added members will replace

ASMIMSL5 their counterparts in the next version of MXG, so I

ASMIMSL6 chose to use temporary names with an X in the penultimate

JCLIMSXG position to keep the new members apart. For the ASM and

JCLIMSX5 JCL members, change the X to an L, and for the TYPE and

JCLIMSX6 VMAC members, change the X to an S, as you copy them into

TYPEIMSA your USERID.SOURCLIB for testing.

TYPEIMSB Member ADOCIMSA contains the discussion of the changes in

VMACIMSA these revisions.

Jul 14, 1999

Thanks to Carl Meredith, SAS Institute ITSV, USA.

Thanks to Ken Whitehead, Bank of New York, USA.
Change 17.171 PRINTWAY records contain JCTJOBID='PSnnnnnn', so the MXG

DOC logic to create TYPETASK='PS' and JESNR=nnnnnn in all of

Jul 13, 1999 these MXG members that create TYPETASK from JCTJOBID:

VMAC6,VMAC26J2,VMAC26J3,VMAC30,VMAC32,VMAC42,VMAC91,

VMACBETA,VMACDALO,VMACIPAC,VMACNNAV,VMACTMNT,VMACXPM

and BUILD005 was revised to test for the 'PS' value.

Thanks to Bob Falla, The Mutual Group, CANADA.
Change 17.170 DB2ACCT variables added by versions 5.1 and 6.1 are now

ASUMDB2A added to the summarization by member ASUMDB2a in creating

Jul 13, 1999 dataset PDB.ASUMDB2A. Comments in member ASUMDB2A list

the 75 variables added to the SUM and one to the MAX.

Thanks to Glenn Bowman, Wakefern, USA.
Change 17.169 Landmark TMON V2 response time TARSPTM will contain the

VMACTMO2 sum of all conversations if SEGMENT CONVERSTATION is NOT

Jul 13, 1999 set to Y in Landmark Record Collection Options, and the

total count of conversations is counted in TARSPCT. So

if TARSPCT is greater than one, TARSPTM is recalculated

as the average response time of those conversations:

IF TARSPCT GT 1 THEN TARSPTM=TARSPTM/TARSPCT;

Thanks to Dan Ternosky, IBM, USA.

Change 17.168 This utility will analyze a SAS data library for date or

ANALDATE datetime formatted variables, and will print a summary of

Jul 12, 1999 minimum and maximum dates found in your data, as well as

dates outside the expected range (user definable, default

earlier than 1/1/1999 or later than 1/1/2001). This may

be useful in your final Y2K testing of SAS libraries.

Thanks to Freddie Arie, LONE STAR GAS, USA.
Change 17.167 Corrections to Boole's MainView for CICS VSAM file. The

VMACMVCI division of T6EP24HW by 62500 was incorrect and was thus

Jul 12, 1999 removed. The input of T6EUSTGO was moved back two bytes,

by creating M6=-6; and using +M6 instead of +M4, and by

inserting +2 after the input to re-align with the rest of

the data fields.

Thanks to Mrs. Peridon, Ministere du Budget, FRANCE.

Thanks to Mr. Deledalle, SAS Institute, FRANCE.

Change 17.166 An IBM-provided PSF ZAP (change APSPPSMF to set SMF6IMPS

VMAC6 with Logical Page Count in DIAPAGE instead of Side Count

Jul 12, 1999 from DIAIMPS) overlays the record with zero for SMF6LN2,

that cause INPUT STATEMENT EXCEEDED error condition.

While IBM investigates, this circumvention resets a zero

SMF6LN2 to 36 so that the rest of the record is output.

If these invalid records are found, MXG will now print a

note for the first three instances.

Thanks to Rick Knapp, AON, USA.
Change 17.165 Preliminary NTSMF support for Win 2000 Beta 3 and support

VMACNTSM for new data and record formats for four existing objects

Jul 11, 1999 as well as protection for the new 0.8 and 0.9 records.

The Beta changes are incomplete, as the discover records

had fields with missing names that are input with place

holders, but the important existing fields should be ok.

Win 2000 Beta 3 Changes:

Object Status

Memory: Reordered, 3 Name Missing field

Process: 6 Name Missing fields

PhysDisk: 5 new fields inserted somewhere

LoglDisk: No Instance name, 3 new

Other Object Changes:

Object Status

IIS Global: Complete Revision, all new vars

Web Service: Twenty-Seven new variables

Indexing Service: Instance variable removed

Indexing Service Filter: Instance variable removed

Thanks to Jim Quigley, Con Edison, USA.
Change 17.164 The _SVMxxxx sort macros had PROC COPY syntax instead of

TYPEVM the DATA _LVMxxxx; SET _WVMxxxx; logic that is needed

Jul 11, 1999 until the _BVMxxxx BY macros are populated.

Thanks to Anthony P. Lobley, EDS, ENGLAND.

Change 17.163 ASUM70PR discards SMF70CIN='ICF' observations so they are

ASUM70PR not counted in NRCPUS, LPARCPUS, or PARTNCPU variables in

Jul 11, 1999 PDB.ASUM70PR (as long as you have APAR OW37565 on your

system - see Change 17.162). If you have more than one

ICF CPU, the circumvention in member XSUM70PR from Change

16.381 is not valid, and this revision does not depend on

a table of SYSTEM/LCPUADDR. It first counts the number

of ICF engines, and then subtracts that count from the

above variables in the real CPU records while deleting

the ICF CPU records. It also creates new variable

NRICFCPU with the count of the number of ICF engines

found in the CPC (and whose detail can still be found in

the TYPE70PR 'ICF' observations), but whose data are not

included in PDB.ASUM70PR (nor in TRND70PR either).

If you use this new ASUM70PR to summarize old TYPE70PR

data, you will get 'SMF70CIN UNINITIALIZED' messages, but

that has no impact unless you actually have ICF, in which

case you will need to recreate TYPE70PR with the new

TYPE7072 with Change 17.162 installed.
Change 17.162 Support for APAR OW37565 creates SMF70CIN='CP ' or 'ICF'

VMAC7072 in TYPE70PR dataset to identify if the CPU is a General

Jul 11, 1999 Purpose CPU (SMF70CIN='CP '), or an Internal Coupling

Facility CPU (SMF70CIN='ICF'). While most sites use the

PDB.ASUM70PR dataset, revised by Change 17.163, for PRSM