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

subsystems) is enabled, by z/OS 1.5, but I missed that

relocation. SMF73CSS is now conditionally INPUT from the

new location when that bit is enabled.

Thanks to Joel Giacobbe, Federal Reserve Bank, USA.
Change 23.104 The ASUMTALO/ASUMTMNT summarization of tape drives and

ANALCNCR tape mounts is enhanced so that you can summarize by

ASUMTALO "groups" that you define, and ANALCNCR can now be used

ASUMTMNT to determine which jobs were active at the time of the

May 3, 2005 maximum tape drive allocation.

May 11, 2005 -For ASUMTALO, the default assumed all tape devices were

May 16, 2005 shared across all systems in the PDB.TYPETALO input data,

May 18, 2005 and were thus summarized by DEVICE.

-For ASUMTMNT, the default summarized all tape mounts BY

SYSTEM as the high level variable.

a. This change provides these local tailoring options:
-For ASUMTALO, you can define a "group" variable and then

create it based on SYSTEM, and that "group" variable

will then be used as the high-level summary variable in

the BY statements. For example, you can create a group

variable named LOCATION and populate that variable with

this example using the new old-style macros "instream":

//SYSIN DD *

%LET MACKEEP=

%QUOTE(

MACRO _GRPALNM LOCATION %

MACRO _GRPALCD

IF SYSTEM IN ('SYS1','SYS2') THEN LOCATION='DALLAS';

ELSE IF SYSTEM IN ('XYZ1','XYZ2') THEN LOCATION='NYC';

%

);

%INCLUDE SOURCLIB(ASUMTALO);

-The ASUMTALO data will then show tape device utilization

for each DEVICE type within each LOCATION.
-For ASUMTMNT, you can also define a "group" variable and

create it based on SYSTEM, and that "group" variable

will then be used as the high-level summary variable in

the BY statements. The two macro names are different, in

case you want to sum TMNT different than TALO, but the

structure is similar in this example:

//SYSIN DD *

%LET MACKEEP=

%QUOTE(

MACRO _GRPMNNM LOCATION %

MACRO _GRPMNCD

IF SYSTEM IN ('SYS1','SYS2') THEN LOCATION='DALLAS';

ELSE IF SYSTEM IN ('XYZ1','XYZ2') THEN LOCATION='NYC';

%

);

%INCLUDE SOURCLIB(ASUMTMNT);

-The ASUMTMNT data will then report tape mount statistics

for each SYSTEM within each LOCATION. If you want your

mount statistics to be summarized by each LOCATION (and

nor for each SYSTEM at each LOCATION, you would just add

SYSTEM=' ';

as the last statement in your _GRPMNNG definition.
-For your daily "BUILDPDB" job, which normally includes

both ASUMTALO and ASUMTMNT, you can put all four of those

macro definitions (_GRPALNM,_GRPALCD,_GRPMNNM,_GRPMNCD)

in a single %LET MACKEEP= for that job (or they could be

defined in the IMACKEEP member and then would apply to

any execution of their respective ASUM members).

b. Revision to find contributors to maximum value:
-ANALCNCR was enhanced so that you can print each of the

input events that caused the "maximum concurrent value".

When you specify %LET MXGDEBUG=ANALCNCR; prior to the

execution of ANALCNCR, then dataset WORK.MXGDEBUG will

be created with the first phase observations, and you can

then use this program to find the time of the peak value,

and then print the specific input events that created the

maximum. For example, ASUMTALO calculates maximum tape

drives allocated, so you would use:

%LET MXGDEBUG= ANALCNCR;

%INCLUDE SOURLCIB(ASUMTALO);

PROC SORT DATA=MXGDEBUG;

BY DESCENDING CONCURNT;

DATA _NULL_;

SET MXGDEBUG;

IF DEVICE=:'9840HSM';

PEAKTIME=PUT(TIMESTMP,DATETIME21.2);

CALL SYMPUT('PEAKTIME',PEAKTIME);

STOP;

RUN;

PROC PRINT DATA=PDB.TYPETALO;

WHERE DEVICE=: '9480HSM' AND

ALOCSTRT LE "&PEAKTIME"DT LE ALOCEND;

RUN;

to print which observations from the PDB.TYPETALO data

caused that maximum tape drive allocations.

For ANALCNCR with other input data, the test for the

"DEVICE" variable would need to be changed to use the

appropriate variable, the SET PDB.TYPETALO would need

to be changed to the input dataset, and the correct

start and end variables would need to be used in the

selection around "&PEAKTIME"DT test.

c. Additional chagnes:
-ANALCNCR was revised to re-locate the INCODE= operand;

this was required so that the "group" support, above,

could be implemented.
-A new TRACE= option for internal debugging was created

in ANALCNCR, unlikely to be needed outside development!

-An unrelated enhancement was also made to ASUMTMNT; the

definition of the mount time values for each of the mount

"buckets" was externalized, so they can also be changed

by redefining those macros with %LET MACKEEP=, as above.

Thanks to Andre D. Walker, Bank of America, USA.
Change 23.103 Documentation. Selecting ANALDB2R for an interval period

ANALDB2R (13:00 to 14:00), MXG's criteria selects any transaction

May 3, 2005 that started in that interval, or ended in that interval,

or started before and ended after that interval, so the

MXG report can easily show an "INTERVAL DURATION" that is

greater than the one hour you requested, but it includes

all transactions that spent any time in the requested

interval. IBM's DB2PM reports appear to only include the

transactions that started and ended within the requested

interval, so MXG can report more activity than DB2PM.

Thanks to Peter Farrell, Commerce Bank of Kansas City, USA.
Change 23.102 Cosmetic, but confusing! The label for PAGEINS/PAGEOUTS

VMAC30 is corrected to the TOTAL PAGE IN/OUT FROM AUX STORE, as

May 3, 2005 they count both blocked and unblocked pages moved.

Thanks to Melanie Hitchings, BT, ENGLAND.

Change 23.101 Support for APAR OA10901, new SMF30ZNF variable with the

VMAC30 zAAP CPU Normalization factor is added to the datasets

May 2, 2005 TYPE30_V/PDB.SMFINTRV, TYPE30_4 and TYPE30_5.
Change 23.100 ASG/Landmark TMON for CICS/TS V2.3 supports CICS/TS 3.1

VMACTMO2 with toleration PTFs for their product, but there are no

May 1, 2005 changes to their data dictionary, i.e., there were no

changes made in their records to add any new 3.1 fields.

Thanks to Roland Schiradin, Alte-Leipziger, GERMANY.
Change 23.099 Support for IMS Version 9.1 was already in MXG 22.22:

VMACIMS -IMS Monitors: BMC IMF, Candle ITRF, Landmark TIMS.

May 1, 2005 -MXG's "Supported" TYPEIMS7 to create IMS0708 dataset

-MXG's ASMIMSL6/JCLIMSL6 to create IMSTRAN dataset.

-There were no significant changes by IBM to any of the

IMS log records in IMS Version 9.1, compared with 8.1.

-The three IMS Monitors that are fully supported by MXG

(and are STRONGLY recommended - See Newsletter 25!!),

BMC's IMF, ASG/Landmark's TIMS, and IBM/Candle's ITRF

products all create their own data records:

-IMF writes two records to the IMS log file, 'F9'x, 'FA'x

but there were no changes made by IMF Version 4.1.00 for

IMS Version 9.1 to the IMF records. However, MXG 22.08

is required for IMF records for all IMS versions, due to

corrections in sequencing of CIMSTRAN in Change 22.199.

Also, Change 22.241 in MXG 22.10 added ASUMCIMS example

for summarization of CIMSTRAN/CIMSDBDS IMF datasets.

-TIMS writes data to its own file; the last update to

TYPETIMS code was in MXG Version 20.09.

-ITRF writes additional records to the IMS log, but then

an ITRF program combines their records with IBM records

to create their file that MXG TYPEITRF then processes;

the last TYPEITRF code change was in MXG Version 17.09.
-MXG's only "Officially Supported" IBM-IMS-log-record read

program is TYPEIMS7, which combines log records 07 and 08

to create the IMS0708 dataset (capturing only resources,

with no response time). Those records were not changed

by IBM in IMS V9.1, but MXG Change 22.199 (in MXG 22.08)

was a major revision to the TYPEIMS7 logic for all IMSs.

- You must update the _IMSVERS macro in IMACIMS to tell

MXG the IMS version you are processing, and you cannot

concatenate IMS logs from different versions, as IBM

does not put a version number in their log records!

-MXG's "pseudo-supported" IBM-IMS-log-record read programs

in the JCLIMSL6 jobstream required no changes to support

IMS Version 9.1, but you must re-assemble ASMIMSL6 with

the IBM IMS Macro Library for IMS Version 9.1 to create

the load module for V9.1 records, and you must run

separate JCLIMSLx jobs with different load libraries and

process each IMS version's data separately; you cannot

concatenate the IMS logs from two versions and read with

JCLIMSLx. MXG 20.03 contained the last changes to these

members, and thus there was no need to create L7, L8, or

L9 suffixed ASMIMSLx/JCLIMSLx members.

-For processing JCLIMSLx/ASMIMSLx on ASCII platforms, MXG

Version 22.06 is required due to Change 22.128.
-IBM did insert fields in the IMS log 31x record in V9.1,

and VMACIMS is updated by this change (in MXG 23.04) for

that insert, but the insert was after any "important" IMS

data, and could only be observed if you were looking at

the IMS31I or IMS31O datasets that are written to //WORK,

but are neither kept nor used by MXG programs.

Thanks to Roland Brugger, Credit Suisse, SWITZERLAND.
Change 23.098 DB2 Version 8 restructured Package Data, and added many

VMACDB2 new variables to DB2ACCTP dataset:

Apr 30, 2005 QTXACHG QTXACHUS QTXACLMT QTXACLNO QTXACLUN QTXADEA

QTXADRNO QTXADRUN QTXAFLG1 QTXAILMT QTXAIRLM QTXALES

QTXALEX QTXALOCK QTXANPL QTXANRUN QTXAPREC QTXAQRY

QTXARLID QTXASLAT QTXASLMT QTXASLOC QTXASOTH QTXATIM

QTXAUNLK

QBACGET QBACSWS QBACRIO QBACSEQ QBACIMW QBACLPF

QBACDPF QBACNGT QBACSIO

QPCALLCT QPCLOSET QPDELETT QPDESCCT QPFETCHT QPINSRTT

QPLOCKCT QPOPENCT QPPREPCT QPSELECT QPUPDTET

Originally, the first ten packages executed by a plan

were written as ten segments in the SMF 101 subtype 0

IFCID=0003 records, and if more than 10 packages were

executed, additional SMF 101 subtype 1 IFCID=239 records

were created. MXG creates an observation in the DB2ACCTP

dataset from each package segment, independent of whether

it was in the 0003 or the 239 IFCID record. But with

DB2 V8.1, package segments are no longer written in IFCID

0003 records; instead only the IFCID 0239 records will

contain package data, and there are three new DSECTS

added that are always present, one of each for each

package segment.

(QXPK, QBAC, and QTXA, and in that order; the DB2 MACRO

Library had inconsistent documentation that will be

corrected with a doc APAR)

MXG will transparently use either 0003 and 0239 or just

0239 segments to create the DB2ACCTP observations, and

those added new variables will exist, but will only be

populated (i.e., non-missing) from DB2 V81 records.

Thanks to Steven Olmstead, Thomson BETA Systems, USA.

Thanks to Ray Willoughby, Thomson BETA Systems, USA.

Thanks to John B. Tobler, IBM Silicon Valley Lab, USA.
Change 23.097 Variables CTCKPNTS MAXLOCKS TOTLOCKS were added to the

VMACCIMS KEEP list of both CIMSTRAN and CIMSPROG, but those three

Apr 29, 2005 variables are only INPUT from the CIMSTRAN records, so

they are now removed from CIMSPROG KEEP list.

Thanks to Christa Neven, KBC Bankverzekeringsholding, BELGIUM
Change 23.096 Change 22.203 protected decoding of JCTJOBID if it was

VGETJESN blank or hex zero, to prevent unnecessary log messages,

Apr 29, 2005 but that caused TYPETASK to be blank in TYPE30_6 data,

because the "Early Address Spaces" records that are

written as type 30 subtype 6 interval records now have

have blanks for JCTJOBID.

(Historically, these records had JOB name in JCTJOBID,

then JCTJOBID was hex zeros, but now JCTJOBID contains

blanks in current z/OS type 30 subtype 6 records).

But they have SUBSYS='STC', so the logic was revised to

sets TYPETASK='STC' (and JESNR=.) if JCTJOBID is blank or

hex zero, and SUBSYS='STC'.

(And if blank-TYPETASK-value-messages are printed now,

more code will be added to test and figure it out!)

Thanks to Michael Creech, Fidelity Information Services, Inc, USA.
Change 23.095 Variable PCTCFULL='PCT OF*CACHE*USED' was added to the

VMAC41 TYPE41VF dataset. Variable SMF41FND is clarified in the

Apr 29, 2005 ADOC41 as the number of objects found in cache in this

interval, which is NOT the total number of objects in the

cache (that number does not exist in SMF 41 records).

Thanks to Ulrich Krueger, National Semiconductor Corp., USA.

Change 23.094 The PROC DATASETS for HSMSTAT needed MT=ALL because that

ASUMHSM dataset is a VIEW, and the default MemType=DATA caused a

Apr 29, 2005 warning note.

Thanks to Chris Weston, SAS Institute ITRM Development, USA.

Change 23.093 SMF 74 subtype 8 INPUT STATEMENT EXCEEDED RECORD LENGTH

VMAC74 because I didn't have any test data to catch my typos!

Apr 28, 2005 The INPUT of R748RCNT was missing a period, variables

R748AASP/AAWD/AACP are now PIB1/2/4 instead of RB8, and

variables R748XRCP thru R748XTDY are PIB4. and not RB4.

Thanks to Miguel Francisco Monferrer Carvajal, EDS, SPAIN.

Change 23.092 MXG 23.03 only, and only for ITSV/ITRM. Two hardcoded

VMXG70PR references to "PDB." caused errors with ITSV/ITRM. The

Apr 28, 2005 macro variable "&PTY70PR.." replaced them to correct.

Thanks to Chris Weston, SAS Institute ITRM Development, USA.

Change 23.091 SMF 6 record INPUT STATEMENT EXCEEDED RECORD LENGTH with

VMAC6 a VPS record with the Printway File Transfer segment. The

Apr 28, 2005 Changes 22.309, 22.321 are revised, based on the z/OS 1.6

SMF Manual, which documents both the basic and extended

mode for records created by SUBSYS='TCP', but the values

in SMF6INDC in SUBSYS='VPS' records are 5 and 3 instead

of the 1 or 7 expected, so MXG logic is revised again to

provide special handling for VPS SMF 6 records that have

a file transfer segment. But in one SMF 6 record written

for SUBSYS='PSF', it's file transfer segment does not

agree with either the basic or extended mode TCP segments

or with the PSF segment documentation, so heuristic logic

is added to (hopefully) protect PSF records as well.

Thanks to Udo Frohling, Kommunales Rechenzentrum Niederrhein, GERMANY

Spent week in NYC at The Plaza during its last week as a real hotel, but

our real purpose was to attend the Jammy Awards ceremony at Madison

Square Garden, where our "godson", Keller Williams won one of only nine

Jammy's: Best Live Album, "Stage". See http://www.kellerwilliams.net.

====== Changes thru 23.090 were in MXG 23.03 dated Apr 22, 2005=========
Change 23.090 Executing MXG under ASCII platforms has some differences:

INSTALL -If you use the ftp access method to read your MVS data

IMACFILE directly, you won't have a copy of the SMF data on your

Apr 22, 2005 ASCII system; although most sites back up their SMF data

on MVS, it is possible to backup your SMF data on your

ASCII platform, as you are reading SMF with ftp access.

Writing a 13GB backup file added 20 minutes run time.

See the article "Can you run MXG on a PC' in NEWSLTRS.

Or, if you want to create an SMF file on your ASCII

system that contains selected SMF data, the below example

shows how you can use the "IMACFILE" exit to create an

SMF VBS file on your ASCII system.

-The _NULL_ data step creates macro variable, &DATETXT,

with the date and time as a text string, which is then

used to create the name of the "backup" SMF VBS file.

-The "instream" tailoring statement %LET MACFILE= adds

the code inside the %QUOTE() function (required because

there semi-colons in the code that would otherwise have

terminated the %LET statement) to the exit that is taken

after the SMF header has been read.

If you want to select SMF records, you would add an

IF ... THEN DO; statement after the %QUOTE( and would

add an END; statement before the ) that ends %QUOTE.

The SMF header variables ID SMFTIME SYSTEM and SUBTYPE

are available for selection, although some records with

subtypes don't put their subtype in the SMF header.

-Example to read SMF via FTP and create a local SMFBKUP

file of the input SMF records:

The example shows how to concatenate multiple SMF files:

//SYSIN DD *

DATA _NULL_;

DATE=TODAY();

TIME=TIME();

DATETXT='D'!!PUT(DATE,YYMMDD10.)!!'-'!!'T'!!

PUT(HOUR(TIME),Z2.)!!'-'!!

PUT(MINUTE(TIME),Z2.);

CALL SYMPUT('DATETXT',DATETXT);

RUN;

FILENAME SMF FTP ("'SYS1.SMF'" "'SYS2.SMF'" ... )

USER='XXXXXX' HOST='YYYYYYY'

S370VS RCMD='SITE RDW' LRECL=32760

PASS='XXXXXXXX';

FILENAME SMFBKUP "C:\MXG\SMFDATA\&DATETXT" ;

%LET MACFILE=

%QUOTE(

RDW=LENGTH+4;

BDW=RDW+4;

FILE SMFBKUP RECFM=N LRECL=32760;

PUT BDW &PIB.2. '0000'X RDW &PIB.2. '0000'X

_INFILE_ @;

);

RUN;

%INCLUDE SOURCLIB(BUILDPDB);

RUN;

The backup file name c:\mxg\smfdata\D2005-04-19-T04-20

contains the date and time of creation of the file. The

backup file is slightly larger than the input file

(325,498,825 versus 325,484,807, or +14,018 bytes)

because each VBS record creates a separate block. And,

the FILE with RECFM=N option does print the output file

name on the SAS log, there is not message that any data

was written. SAS Technical Support says that is because

RECFM=N doesn't write records that none are counted, but

a suggestion to provide byte count has been made, so that

you will know if the file was actually written to.

-Comments with this example were added to IMACFILE and to

member INSTALL, but no there was no change to MXG code.

-Example to read SMF via FTP and select a subset of SMF

records to be created on the ASCII platform;

The example shows how to concatenate multiple SMF files:

//SYSIN DD *

DATA _NULL_;

DATE=TODAY();

TIME=TIME();

DATETXT='D'!!PUT(DATE,YYMMDD10.)!!'-'!!'T'!!

PUT(HOUR(TIME),Z2.)!!'-'!!

PUT(MINUTE(TIME),Z2.);

CALL SYMPUT('DATETXT',DATETXT);

RUN;

FILENAME SMF FTP ("'SYS1.SMF'" "'SYS2.SMF'" ... )

USER='XXXXXX' HOST='YYYYYYY'

S370VS RCMD='SITE RDW' LRECL=32760

PASS='XXXXXXXX';

FILENAME SMFBKUP "C:\MXG\SMFDATA\&DATETXT" ;

%LET MACFILE=

%QUOTE(

IF ID IN (70,72);

RDW=LENGTH+4;

BDW=RDW+4;

FILE SMFBKUP RECFM=N LRECL=32760;

PUT BDW &PIB.2. '0000'X RDW &PIB.2. '0000'X

_INFILE_ @;

);

RUN;

%INCLUDE SOURCLIB(VMACSMF);

DATA _NULL_;

_SMF;

RUN;

Thanks to Michael Gebbia, Eddie Bauer, USA.

Thanks to Glenn Bowman, Wakefern, USA.

Change 23.089 Variable DCVDVNUM, the Device Number, is retained from

VMACDCOL the DCOLVOLS record and kept in the DCOLDSET dataset;

Apr 21, 2005 this is possible because the DCOLLECT output is ordered

with the DCOLVOLS record before the DCOLDSETs on that

volume.

Thanks to Frank Lund, EDB IT Drift, NORWAY.

Change 23.088 -Variables EV40FLG1 EV40FLG2 and CATGNAME from RACFTYPE=40

EXTY8066 were incorrectly kept in TYPE8007 dataset and were not

IMAC80A kept in TYPE8008 dataset, now they are correct.

VMAC80A -Variables FROMRESN (13), VOLUME FVOLUME (14) and CLAS26NM

VMXGINIT (from RACFTYPE/DTP=26) are kept in TYPE8019.

Apr 23, 2005 -FROMVOLS in RACFTYPE=6 for RACFEVNT=8 is an 8-byte field,

Apr 27, 2005 but MXG only input 6 bytes, shifting SECLEVEL/SECLABEL.

May 12, 2005 Now, FROMVOLS is input as $EBCDIC8 and the "undocumented"

May 17, 2005 +2 bytes are removed from that INPUT statement.

May 29, 2005 -Variables KW09IG06 ande KW09SP06, UNIVERSAL, added to

May 30, 2005 dataset TYPE8009

-Variables SECLEVEL,SECLABEL,KW11SP28-29,KW11IG28-29

added to TYPE8011.

-Variables CLASSP02,04,05,06 added to TYPE8010,TYPE8013.

-Variable KW19CL07 added to TYPE8019.

-Variables KW19FC00-KW19FC07 replace 00-04, which were

incorrectly decoded.

-Variables KW24S102-S109 added, decoded from KW24RSV1.

-Variables KW25VI00-VI01 added, decoded from KW24OVIO.

-Variables KW59ST00-ST06 added, decoded from KW24STAT.

-Dataset TYPE8066 created for RACDCERT command; however,

only the standard RACF variables are output in this

iteration - time ran out for 23.02 QA, but this record

will be fully decoded in the next iteration.

-Variable LOGSTR change length to 200 from 64, but not

until May 12!

-Additional variables, thru KW24S132, KW24I117, KW24KERB

are decoded, May 17.

-ACEEUSER variable now kept in TYPE8024.

-Second (290) should have been (291).

-KW24SP46/KW24SP47/KW24IG46/KW24IG47 are corrected.

-KW11xx13 and later were incorrectly aligned with th4eir

bits and labels, and KW11xx28 and KW11xx29 should not

have been created for ALTDSD event.

-KW10ER00-KW10ER31 are now decoded and kept in both the

TYPE8010 and TYPE8013 datasets; all three of the sets

of bit maps KW10ERnn, KW10IGnn, and KW10SPnn are the same

for ADDUSER (10) and ALTUSER (13), except that some bits

that can be enabled for ADDUSER won't be for ALTUSER.

Thanks to Bill Arrowsmith, Euroclear, BELGIUM.

Thanks to Andrew Davis, Euroclear, BELGIUM.

Thanks to Aimee Steel, Euroclear, BELGIUM.

Change 23.087 -If USERADD= contained two references (SYNC/208 SYNC/214)

UTILBLDP with different SMF IDs, UTILBLDP generated incorrect code

VMXGINIT but now it will use only the first reference.

BUILDPDB -EXPDBOUT=%INCLUDE SOURCLIB(ASUMPRTR); used in Example 7,

BUILDPD3 failed. Unfortunately, because of macro timing issues,

BUILD001 the only way UTILBLDP can create a %INCLUDE statement

BUIL3001 for EXPDBOUT= required a new macro variable, &BLDPOUT,

Apr 21, 2005 to be defined in VMXGINIT and inserted in the BUILxxxx

members where _EPDBOUT is invoked.

Thanks to Robert Chavez, OfficeDepot, USA.

Change 23.086 DB2STATS variable QDSTNQR2 should not have been DIF()'d.

VMACDB2 Variable QDSTQDBT should have been, and now is DIF()'d

Apr 21, 2005 as it contains accumulated values.

Thanks to Fred Nijdam, Rabobank, THE NETHERLANDS.

Change 23.085 Dataset ICEBRGCH old variables ENDTIME,STARTIME were not

VMACICE adjusted in VMXGTIME macros, old variable CHANSPED is now

Apr 19, 2005 converted to bytes and FORMATed MGBYTRT as it is channel