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

May 12, 2000 %INCLUDE SOURCLIB(VMACIMSA,IMACKEEP);

should have been added by change 18.086. Our testing was

with IMS Version 5, so we missed this error, as even with

that note, the 18.03 IMS Support processes V5 just fine.

Thanks to Pete Young, University of Toronto, CANADA.
Change 18.102 SMF 108 records from the early release 5.0 cause error

VMAC108 INVALID DO LOOP CONTROL because the DO loop on SM108PTN

May 12, 2000 did not test first that SM108PTN was non-missing.

Thanks to Coen Wessels, UNICBLE, SWITZERLAND.

Change 18.101 INVALID DATA FOR REQSTART resulted when the date field

VMACIPAC contains packed decimal value of zero for both the time

May 11, 2000 and date parts ('0000000C0000000C'x). Inserting the

"double question-mark modifier" in the INPUT statement

suppresses the note and hex dump of the SMF record. This

subtype (for KSDS VSAM) should not have been created by

IPAC, since that feature is not enabled at this site.

So MXG now protects the zero date in this useless record.

Thanks to Jim Petersen, Homeside Lending, Inc, USA.
Change 18.100 Variable FILDATEX was not protected for invalid Julian

VMACZARA date values of 1998000, but now those expiration dates

May 11, 2000 will be set to MXG's "infinite" date of '31DEC2099'D.

Thanks to Jim Horne, Lowe's Companies, USA.

Change 18.099 Dataset ASUMCEC is now automatically built in the Monthly

MONTHBLD and Weekly PDB libraries. Since it is built by %INCLUDE

WEEKBLD of ASUM70PR member, and MXG already expected the ASUM70PR

WEEKBLDT dataset to exist, adding ASUMCEC to the WEEK/MONTH PDBs

May 11, 2000 should be transparent.

Thanks to Normand Poitras, ISM, Canada.

Change 18.098 Variable FTPDATFM added to LENGTH $1 statement, as it

VMACTCP is decoded by $MGTCPFM and its length must be forced in

May 10, 2000 the LENGTH statement.

Thanks to Lindsay Oxenham, IBM Global Services, AUSTRALIA.

Change 18.097 Summarization example for DB2STATB, the DB2 Statistics

ASUMDBSB Buffer Pool data, which is not yet provided by ANALDB2R

May 2, 2000 Statistics Detail report. This is a first pass effort.

Thanks to Chad Heck, BEPC, USA.

Change 18.096 Execution under ASCII only. Some hex variables were read

VMAC74 with $EBCDIC instead of $CHAR, causing possible incorrect

Apr 30, 2000 values in internal variables TEMPIOML/SMF74PRF/DASDRCFG/

SMF74CNX/RF8FLAG/DSG2 and kept variables TYPEIOML,

EXTNDSTO,ESCAENAB,ESCACONF,MTPATBEG,MTPATEND,DEVDYNCH,

DEVDISNV,BASE,NRALEXCH,SNAV,DVID,RCOL,DIFN,DBDP, &PDAT,

but only if the raw SMF data was read with MXG under SAS

on an ASCII platform. Fortunately, most of these are new

variables, and the old ones were rarely used.

-I misread APAR OW31701 and used the wrong hex field to

set variable NRALEXCH (number of aliases changed?).

and overlooked bit 2 of SMF74CNX, now variable PAVBASE.

Change 18.095 The HFS Dataset Names for FTP Client and Server are now

VMACTCP created as variables FTPHFSD1/FTPHFSD2 in the TYPETCPF

Apr 30, 2000 and TYPETCPC datasets. While the theoretical length of

an HFS dsname could be 1024 bytes, only the first 200

bytes (the maximum length of a character variable under

SAS V6) are kept. However, if you actually have dsnames

longer than 200, this could easily be changed, and when

the entire world is on V8 with compression, variable

lengths can be 32000 with no wasted space!

Thanks to Steve Clark, California Federal Bank, USA.

Change 18.094 Building the daily MVS PDB on tape is not recommended, as

VMXGCICI there will be lots of rewinds (and possible dismounts and

VMXGRMFI remounts). If you want to put your daily PDB on tape, it

Apr 30, 2000 is far better to create it on temporary DASD and then use

Feb 27, 2003 PROC COPY IN=PDB OUT=PDBTAPE MEMTYPE=DATA; to copy all of

the PDB datasets to the tape in one write after creation.

MXG has always intended that the BUILPDB could write to

//PDB when it points to tape, so code was revised so that

you could make the below changes and put //PDB to tape:
To write all the PDB datasets directly to //PDB on tape:

//SYSIN DD *

%LET PCICTRN=WORK;

%LET PDB2ACC=WORK;

%LET PCICACC=WORK;

%INCLUDE SOURCLIB(BUILDPDB);

PROC COPY IN=WORK OUT=PDB;

SELECT DB2ACCT CICSTRAN CICSACCT;

DB2ACCT and CICSACCT are normally written to //PDB during

the SMF-processing step, but you cannot have two datasets

open simultaneously in a sequential data library, so they

will be written initially to //WORK and copied to //PDB.

The CICSTRAN dataset is normally written to //CICSTRAN as

a separate sequential data library, but in this example,

CICSTRAN will be written to //WORK and then copied to the

//PDB. Of course, if you don't want to keep CICSTRAN and

DB2ACCT you can eliminate the PROC COPY. (CICSACCT always

has zero observations, and is not likely used anymore.)

If you have large CICSTRAN and DB2ACCT datasets, you may

prefer to write them to separate tape datasets and have

the rest of the PDB datasets written to //PDB, taking

much less //WORK space and eliminating double handling:

// EXEC MXGSASV9

//CICSTRAN DD DSN=CICSTRAN,DISP=(,CATLG),UNIT=TAPE

//DB2ACCT DD DSN=DB2ACCT,DISP=(,CATLG),UNIT=TAPE

//SYSIN DD *

%LET PCICTRN=CICSTRAN;

%LET PDB2ACC=DB2ACCT;

%LET PCICACC=WORK;

%INCLUDE SOURCLIB(BUILDPDB);

And if you want to include ASUMCACH, you must use this

code; ASUMCACH normally reads PDB.TYPE74 and PDB.TYPE74CA

and outputs to PDB.ASUMCACH:

DATA TYPE74; SET PDB.TYPE74;

DATA TYPE74CA; SET PDB.TYPE74CA;

The actual MXG changes made in CHANGE 19.084 were these:

-In VMXGCICI, protection for archaic CICEOD/REQ/RRT/USSRV

datasets had input and output from the PDB ddname; now a

temporary file is created and used for the four inputs.

-In VMXGRMFI, the TYPE72 and TYPE72GO datasets were read

concurrently from the PDB ddname; a temporary copy is

made of the TYPE72 dataset (which eventually will have

zero observations always when the world is goal mode!).
Read Change 18.104 before using SAS V8 tape datasets.
The text of this change was revised in Feb 2003.

Change 18.093 Support for Roger Software Development, RSD FOLDERS 4.0.

EXRSDFBA Two datasets are created

EXRSDFOL dddddd dataset description

IMACRSDF RSDFBA RSDFOBAT RSD FOLDERS ASTRES BATCH

TYPERSDF RSDFOL RSDFOONL RSD FOLDERS ASTRES ONLINE

TYPSRSDF Most fields documented in DSECTS ACCIO and ACCIOAP are

VMACRSDF now decoded, but there still are a few unknown fields

VMXGINIT in the record, but they seem to contain zeroes.

Apr 29, 2000

May 13, 2000 Note that member TYPEWSF supports RSD's EOS/WSF product.

Thanks to Chairat Tiajanpan, KrungThai Bank, Thailand.

Change 18.092 The _ETY1032 statement, which OUTPUTs SMF 103 subtype 2,

VMAC103 was in the wrong place (too early in the INPUT logic),

Apr 27, 2000 causing many TYPE1032 variables to have missing values.

The type 103 SMF record's product has had these names:

Websphere Application Server for OS/390

HTTP Server Version 5.2

Lotus Domino GO Webserver

ICSS (Lotus Domino GO)

IICS V2 R2

See Change 18.119 for the type 108 SMF record.

Thanks to Steve Clark, California Federal Bank, USA.
Change 18.091 A set of sample reports for some basic TCP/IP analysis

ANALTCP from IBM type 118 records (MXG Member TYPETCP) for the

Apr 27, 2000 analysis of FTP and Telnet usage.

Thanks to Steve Clark, California Federal Bank, USA.

Change 18.090 Cosmetic, to avoid confusion. VMXGSUM's WARNING message

VMXGSUM that a dataset did not exist had a confusing reference to

Apr 27, 2000 KEEPALL=NO that was removed. The message now states that

it is normal for the first TRENDing run; but otherwise

the warning that an input dataset did not exist is valid.

Thanks to Normand Poitras, ISM, CANADA.

Change 18.089 The last period for any BY group when intervals are

ANALCNCR synchronized may not have been synchronized, because the

Apr 26, 2000 RUNTIME variable was not forced to be a discrete interval

time value. Adding RUNTIME=CEIL(RUNTIME/&TIMER)*&TIMER;

and DO up to LASTINTV in &TIMER chunks fixed the error.

Thanks to Anthony P. Lobley, EDS, ENGLAND.

Change 18.088 Using VMXGRMFI with TREND= specified and PDB= blank to

VMXGRMFI invoke only for TRENDing failed with messages:

Apr 26, 2000 WARNING: APPARENT SYMBOLIC V70NRM NOT RESOLVED....

Local macro definitions mis-located inside the PDB loop

were relocated, and KEEPALL=YES was added to the VMXGSUM

invocation in its TRENDing section.

Thanks to Normand Poitras, ISM, CANADA.
Change 18.087 Support for MainView for CICS 5.3.01 (INCOMPATIBLE). The

VMACMVCI CMRDATE format was changed to YYYYMMDD, and a PTF added

Apr 26, 2000 variables STRTTIME, ENDTIME, and SYSTEM to the CMRDETL

transaction dataset. Nine new file count variables were

added in the CMRFILE dataset.

Thanks to Steve Smith, BMC, USA.

======Changes thru 18.086 were in MXG 18.03 dated Apr 17, 2000======
Change 18.086 Revised TYPEIMSB member for IMS log processing completes

TYPEIMSB MXG 18.03 revisions, correcting earlier TYPEIMSB members

Apr 17, 2000 (post 17.17) that created dates of Jan 1, 2000 instead of

the correct date. MXG 18.03 dated Apr 17, 2000 has now

corrected all reported IMS 5.1 log errors, and thus the

IMS Log processing now requires that release of MXG.

Change 18.085 Revisions to Sterling's Solve Management Services V3.7

VMACSOLV support. New subcategory '50'x is undocumented, and MXG

Apr 15, 2000 code will be revised to create separate datasets for each

subcategory. The original MXG code was only for the '06'

USERCPU segment, which is now the only subcategory that

is output in TYPESOLV, pending receipt of documentation

and additional test data.

Apr 29: SOLVLAST changed from TODSTAMP8. to SMFSTAMP8.

Thanks to Silas J. White, FDIC, USA.

Thanks to Ian Davies, Workers' Compensation Board of Alberta, CANADA.

Change 18.084 Variable VERSION is now XPTRVERS, because it conflicted

VMACXPTR with pre-existing character variable VERSION, and it is

Apr 14, 2000 now labeled 'XPTR*REPORT*VERSION'. The KEEP= list for

May 12, 2000 XPTR50 and XPTR52 were missing SYSTEM/SUBSYSTEM/SMFTIME

May 15, 2000 causing _SXPTR50/_SXPTR52 to fail. I protected the Y2K

non-Ready records for 2000, expecting only new dates, but

the RPRTTIME date in XPTR52 have 98 and 99, which MXG

interpreted as 2098/2099. Apparently, the RPRTTIME date

is when the report (format?) was put out to this X/PTR

Report repository, and so now both 19xx and 20xx dates

are protected. LOC_7ATA is respelled as LOC_DATA.

May 12: SRC_FLG logic revised.

May 15: SRC_FLG '... .100'B now '.....100'B.

Thanks to Mike Shapland, PKS Information Services, Inc, USA.

Change 18.083A IMF variable PROGRAMB (@149) was originally documented

VMACCIMS "BMP Program name", when it was added to the IMF record

Apr 14, 2000 by IMF Release 1.3 years ago, because variable PROGRAM

May 22, 2000 was already input (@53), and so MXG used the logic

"IF PROGRAMB GT ' ' THEN BMP='Y';"

to identify BMPs. However, BMC Technical Support has

informed me to instead use variable PROGTYPE (@78), so

IF PROGTYPE='B' THEN BMP='Y';

is now the revised change in VMACCIMS to identify BMPs.

BMC Technical Support also told me that the field I named

PROGRAM has always actually contained the PSBNAME, and

the field I named PROGRAMB contains the actual program

name. This has not been noticed; first, MPPs must have

PSBNAME and PROGRAM name the same, second, for BMPs and

other transaction types that can have different names,

most sites use the same name, and third, IMS analysis is

usually more interested in transaction name than program.
But now that I know the truth, VMACCIMS was changed:

- variable PROGRAMB is still input @149 but re-labeled

to make no reference to "BMP".

- variable PROGRAM is now input @149 instead of @53.

- new variable PSBNAME is now input @53 and kept in the

CIMSTRAN dataset from the 'FA'x IMF records.

The entire text of this change was revised May 22, 2000,

but the change to VMACCIMS that corrected BMP='Y' was

made by the original change contained in MXG 18.03 of

April 17, 2000. Only the changes to PROGRAM/PSBNAME

were not available until MXG 18.05.

Thanks to Betty Paterson, BMC, USA.

Thanks to Dan Sills, The Mutual Group, CANADA.

Thanks to Bob Falla, The Mutual Group, CANADA.

======Changes thru 18.083 were in MXG 18.03 dated Apr 12, 2000======
Change 18.083 ICF CPUs support was still imperfect. The PCTLnBY in

ASUM70PR both PDB.ASUM70PR and PDB.ASUMCEC was wrong (too low)

Apr 11, 2000 if there was an ICF in the box, and the LPnDUR in

PDB.ASUMCEC was DURATM instead of LPnNRPRC*DURATM.

Note that for ICF removal from capacity calculations,

you need APAR OW37565 or the current OS/390 release that

stores 'ICF' into SMF70CIN. If you have systems that are

back level, you can use EXTY70PR to force SMF70CIN='ICF'

for the TYPE70PR observations for the ICF LPARNAME, but

you also must set SMF70CIN='ICF' for the PHYSICAL entry

for that LPAR by its LCPUADDR:

IF SYSTEM='CMC1' AND (LPARNAME='CFP2' OR

(LPARNAME='PHYSICAL' AND LCPUADDR=2))

THEN SMF70CIN='ICF';

Thanks to Richard S. Ralston, Whirlpool, USA.
Change 18.082 First MXG 18.03 only. Sort macro for TYPE64X had a

VMAC64 missing underscore before the _WTY64X in the PROC SORT.

Apr 11, 2000

Thanks to Bruce Widlund, Merrill Consultants, USA.

======Changes thru 18.081 were in MXG 18.03 dated Apr 11, 2000======
Change 18.081 Very minor. Protection for a 16th IFCID destination

VMACDB2 eliminates the VMACDB2 NOTE: YOUR DATA HAD NRQWSC=16.

Apr 11, 2000
Change 18.080 Revisions to correct tape drive counts for SPINing tape

ASUMTALO allocations, and additional exits have been added so that

Apr 11, 2000 selection by SYSTEM and changes to bucket definitions can

Apr 12, 2000 be made without EDITing the ASUMTALO member (by using

%LET MACKEEP= to redefine the exit macros:

_ESUTAL1 allows for the insertion of code to select

which SYSTEMs data is summarized.

_ESUTAL2 allows for overriding the buckets built by

ASUMTALO's invocation of ANALCNCR.

_ESUTAL3 allows for adding to the renames of buckets

if more than 8 bucket are present (supports

new buckets added in _ESUMTAL2)

Thanks to Anthony Lobeley, EDS, ENGLAND.
Change 18.079 These two summary members require KEEPALL=NO to override

ASUMCICS the VMXGSUM new default of KEEPALL=YES, Change 18.065.

ASUMCICX These members will read either IBM or Landmark CICS data,

Apr 10, 2000 but only one set of variables was kept; with KEEPALL=NO,

VMXGSUM constructs a KEEP= with only needed variables,

but KEEEPALL=YES passes the hardcode SUM= list, which

caused variable not found condition. I will revise the

members in a cleaner fashion in a later release, but by

restoring KEEPALL=NO for these two VMXGSUM invocations,

it constructs the correct KEEP= list, and all is well!

Change 18.078 The change in order of sort variables by Change 18.001

MONTHBLD was not propagated into WEEKBLD, WEEKBLDT or MONTHBLD,

WEEKBLD causing NOT SORTED errors TYPE30MU, TYPE30OM, and TYPE89

Apr 10, 2000 datasets. The BY lists were corrected and now match the

Apr 24, 2000 BUILDPDB sort order, but NOT SORTED errors will still

Apr 27, 2001 occur if you build weekly/monthly from daily/weeklys that

Aug 7, 2001 were created with different sort orders.
To get that failing weekly/monthly job to finish, you

only need to add the NOTSORTED option to the end of the

BY list in your WEEKBLD/WEEKBLDT/MONTHBLD:
in WEEKBLD: add NOTSORTED to the BY statement after

each SET statement BY .... NOTSORTED ;

in WEEKBLDT: add NOTSORTED to the MACRO _BYLIST ... %

& MONTHBLD after each MACRO _DSET TYPExxxx %

Explanation: The BY statement with multiple datasets

in a SET statement creates an output

dataset that is sorted, so that a SORT in

a report programs can be bypassed by SAS

to save time and resources, but nothing

else in MXG requires datasets to be in a

sort order, so adding option NOTSORTED

will create the output dataset (which is

partially sorted!) without the error.

Install a new MXG version on the first logical day of

your week (e.g.: my week is MON to SUN PDBs, or Tue-Mon

daily runs, so I move my new version into production on

Monday afternoon, before the Tuesday morning's BUILDPDB,

so that all of the new week's dailies will be created by

the same MXG version) to minimize sort change issues.

Thanks to David Ehresman, University of Louisville, USA.

Thanks to Alan Lankin, Towers Perrin, USA.

Thanks to Scott Snyder, First Data, USA.

Change 18.077 A final PROC SORT was added to put PDB.CICINTRV back in

VMXGCICI the correct order for the WEEKLY merge. The final step

Apr 9, 2000 logic can recalculate STARTIME, so the added sort was:

PROC SORT DATA=CICINTRW OUT=&OUTDATA;

BY SYSTEM APPLID SMFPSSPN STARTIME;

Thanks to Michael L. Knych, International Paper, USA.

Change 18.076 NETSPY report NSPYPRT exposed that MXG NETSPY datasets

VMACNSPY needed revisions in some of its response calculations.

Apr 9, 2000 -Julian discovered and tested with TARGETS=HOST:

NETRSPNO and NETRSPN6 appear to be the number of

instances where a 'definite response' has occurred, as a

result of either (1) FORCEDR in the NetSpy INITPRM, or

(2) the application running in DR-mode anyway. Therefore

they represent the number of times network response time

has been measured, and can correctly be used to calculate

average network response time (by division by CRSPNET and

CRSPNET6). They can only be used to calculate %responses

on target if TARGETS=USER is in force. With TARGETS=HOST

the value of NETRSPNO and NETRSPN6 should be irrelevant.

-The revision of TRANSNO +1 or -1 relates to the number of

inputs to the number of transactions terminated at the

host, which is redundant with LUNRSPSS, and was removed.

-TARGETS=HOST/USER based on NETRSPNO LT Sum(T1-T4RSPNO)

is an approximation that fails with small numbers.

Instead, using SMFTFLG1 for NSPYLU and XDOMAIN for the

NSPYAPPL is a better determination.

Thanks to Julian Smailes, Experian Limited (UK), ENGLAND.
Change 18.075 Dataset TMVSWG's _STMVWG and _NTMVWG macros were not in

VMACTMV2 the _STMV2 and _NTMV2 macro lists, and comments with the

Apr 9, 2000 TMVSWKP instead of TMVSWG were corrected.

Thanks to John Jackson, Redcats (UK), ENGLAND.

Change 18.074 CICS Statistics dataset CICTCPIP variables SOROPENG/OPENL

VMAC110 which should be open timestamp on GMT and Local are bad;

Apr 9, 2000 OPENG is zero, and OPENL is 'FFFFFFFFD1' which produces

a datetime of 17SEP2042:18:53:47.18 in every record. And

the GMT and Local clock values for OPEN/CLOSE are not the

same; they are off by about .2 seconds.

This change is only for documentation; when an IBM APAR

exists that corrects those fields, this will be updated.

Thanks to Bruce Widlund, Merrill Consultants, USA.
Change 18.073 Support for Systemware SYSOUT X/PTR, JHS, MPS, and C/QUE

EXXPTR02 product's user SMF record. There are 30 XPTRnn datasets

... created, but only these subtypes have been data tested:

EXXPTR52 04,06,09,10,11,12,18,20,50,51,52. This vendor provides

IMACXPTR sample SAS code that was used as a starting point, and

TYPEXPTR some of its variable names were used in MXG datasets, but

TYPSXPTR that program failed when executed, had fields input from

VMACXPTR wrong locations, was incomplete, and not Y2K compliant,

VMXGINIT so the DSECTS were used to create this MXG support with

Apr 9, 2000 its structure, formatting, exits, etc.

Thanks to Mike Shapland, PKS Information Services, Inc, USA.
Change 18.072 ObjectStart/Huron have new HU62KEYn/HU72KEYn variables so

VMACHURN that the multiple observations from a single type 62/72

Apr 7, 2000 (multiple Process, Accounting, Locking, etc) can be

Apr 10, 2000 combined into a logical transaction. HU47INTV/APL/SSNO,

HU49INTV/HU49APL/HU49SSNO and HUxxHPSN/PUIN/ACTN/SCN/SAN/

PERN/LKN/RPN/ for 62 and 72 subtypes are all now kept.

Variables HUnnSSNO were changed from &PIB.4. to $CHAR4.

with $HEX8 so that the type 49 and 62 records can be

merged together by HU49SSNO and HU62UNQI to show Huron

resource usage by JOB/STEP. The LABEL for HU49TCPU is

TCB+SRB (was TCB).

Thanks to Lindsay Oxenham, TELSTRA, AUSTRALIA

Thanks to John Toohey, TELSTRA, AUSTRALIA.

Thanks to Greg Meyer, Isuzu Motors, USA.

Change 18.071 MXG 17.17-MXG 18.02 only INPUT STATEMENT EXCEEDED or

VMAC7072 INVALID DATA FOR R723CIEA in Goal Mode Type 72 Subtype 3.

Apr 7, 2000 The OS/390 R2.9 added code was wrong. The INPUT of CXEA

Apr 10, 2000 and CFEA should have been &RB.8. vice &RB.4., and there

was a missing SKIP=SKIP-24; after that input statement.
See Change 18.120: R2.8 with APAR OW41317 also requires

this change, but has no error message. 24May2000.

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

Thanks to Harmuth Beckmann, Karstat AG, GERMANY

Change 18.070 DB2ACCT variable JOB has been revised based on the source

ASUMDB2A of the connection, and new variables TRAN and PLAN are

VMACDB2 also created for possible use in matching to CICSTRAN:

Apr 7, 2000 TRAN=' ';

Apr 10, 2000 PLAN=QWHCPLAN;

IF QWHCATYP IN (1,2,0BX) THEN DO;/*TSO,CALL ATTACH*/

JOB=QMDACORR; /*UTILITY JOBS*/

END;

ELSE IF QWHCATYP IN(3,5,6,9,0AX) THEN DO;/*DLI,IMS*/

JOB=QWHCCN;

END;

ELSE IF QWHCATYP =4 THEN DO;/*CICS*/

JOB=QWHCCN;

TRAN=SUBSTR(QMDACORR,5,4);

END;

ELSE IF QWHCATYP IN (7,8) THEN DO;/*DISTRIBUTED,REMOTE*/

JOB=QWHCOPID;

PLAN=SCAN(QWHCCV,1,' .');

END;

-Testing with the new VMXGSUM change (KEEPALL=YES) found

that some DB2 6.1 variables had been added to ASUMDB2A

but were not in the KEEP= list for dataset DB2ACCT. The

old default of KEEPALL=NO had masked the omission, and

ASUMDB2A's spelling of two QZZ variables as QXX.

Thanks to Paul Weissman, Perot Systems, USA.
Change 18.069 Support for CA's NETSPY 5.3 (COMPATIBLE) adds nine new