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

May 22, 2004

Thanks to Chuck Hopf, MBNA, USA.

Change 22.106 Variables EDSDSMEM, EDSESMEM, EDTDSMEM, EDTESMEM were not

VMACENDV correctly input.

May 22, 2004

Thanks to Lindsay Oxenham, IBM Global Services, AUSTRALIA.

Change 22.105 MXG 22.04 ONLY. If there were no optional CICS segments,

UTILEXCL the IMACEXCL created by UTILEXCL failed with ERROR 22-322

May 22, 2004 on this statement: STRTTIME=STRTTIME+MCTMNTAD-MCTMNLSO;

The error was due to a mislocated comment symbol after

the LASTCHEK: label around a debugging PUT statement.

-ZDATE protected if _RPTEXCL run against PDB.CICSDICT that

had been created by an old UTILEXCL prior to ZDATE keep.

Thanks to George Waselus, Arizona State Department of Admin, USA.

Thanks to Noel D'Sousa, CSC, AUSTRALIA.

Thanks to Helmut Roese, Com-Software, GERMANY.

Change 22.104 Support for Candle Omegamon II for DB2 IFCID Trace data

TYPE102C that is written to a sequential file. Use the file name

VMAC102 //CANDB2 to point to their file, and %INC the TYPE102C

VMACSMF program to create obs for all IFCIDs in the file.

May 20, 2004

Thanks to Joseph Pugh, Fujitsu, ENGLAND.

Change 22.103 Cosmetic. Example had lines 648 and 652 the same; the

DOCPDB second MACRO _LDBJOBS &PDBJOBS..JOBS % statement in

May 20, 2004 line 652 was deleted.

Thanks to Christa Neven, KBC BankVerzekeringsHolding, BELGIUM.

Change 22.102 SAS under unix does not fileref SASAUTOS (SN=000444), and

AUTOEXEC this caused NO LOGICAL ASSIGN FOR SASAUTOS followed by

AUTOEXEU WARNING: Apparent invocation macro LOWCASE not resolved.

May 20, 2004 ERROR 23-2: Invalid option name ) messages, plus the MXG

Version number and date are missing from this message:

MXG DATED HAS BEEN SUCCESSFULLY INITIALIZED.

The real cause of this error is that the %LOWCASE macro

function is not implemented in base SAS, but instead is

provide as a %MACRO in the "SASAUTOS" library; if that

function (and %LEFT) were in base SAS, there

would be no need to concatenate the "SASAUTOS" fileref

with the MXG SOURCLIB. For both z/OS and Windows and

Linux, SAS does "fileref" the SASAUTOS (with a -SET in

the SASVn.CFG file, so this syntax in the MXG-provided

AUTOEXEC.SAS works just fine.

OPTIONS MAUTOSOURCE SASAUTOS=(SOURCLIB,SASAUTOS);

However, under unix, you must provide the "pointer" to

the SASAUTOS directory; you could use a FILENAME to do

that, but it is simpler to use the new AUTOEXEU member

for your autoexec.sas under unix, as it contains

OPTIONS SASAUTOS=(SOURCLIB !SASROOT/SASAUTOS);

which should be the correct location of unix sasautos.

For Windows, of course, the location is different, and

OPTIONS SASAUTOS=(SOURCLIB !SASROOT\CORE\SASMACROS);

is the correct syntax.

If any of the above fail in the future, all you need do

is to search your disk for the file "lowcase.sas", which

will be found in some directory under the sas root, and

use that directory name in your AUTOEXEC/AUTOEXEU file.

Thanks to Steven Hudson, Avnet Inc, USA.

Change 22.101 Support for VIO/PLUS subtypes 1 and 2 create new datasets

EXTYVIOL subtyp dddddd dataset description

EXTYVION 1 TYVION TYPEVION VIO PLUS NON-VSAM STATISTICS

IMACVIOP 2 TYVIOL TYPEVIOL VIO PLUS LOAD STATISTICS

VMACVIOP and eliminates INPUT STATEMENT EXCEEDED RECORD LENGTH

VMXGINIT error. Both new subtypes have been validated with data.

May 5, 2004

Thanks to Billy Westland, Kaiser Permanente, USA.

Thanks to Raff Rushton, Kaiser Permanente, USA.
Change 22.100 Invalid SMF 80 created by EKC's ETF/R FIRECALL product

VMAC80A caused INPUT STATEMENT EXCEEDED RECORD LENGTH ERROR. The

May 4, 2004 second segment length was 197, but only 7 bytes remained

in the record. This vendor's "ETFR" modified SMF 80 was

supported by Change 21.215, after a similar error in that

record was circumvented by Change 21.201. This new EKC

record contains "EKCS" rather than "ETFR", and eventually

I'll support that unique record, also, but for now, this

additional test will prevent your daily job from ABENDing

no matter what EKC comes up with next.

May 22: EKC Inc fix for this error is their PTF LK12029.

Thanks to John Grasing, Metropolitan Life, USA.

====== Changes thru 22.099 were in MXG 22.04 dated May 2, 2004=========
Change 22.099 Documentation only. If a "dddddd" macro variable WTNT063

VMXGINIT %GLOBALed but was not %LET a value, then SAS syntax

May 2, 2004 errors 22, 202, and 455 and their messages were created:

+ &WTNT063..NT063

22

202

455

ERROR 22-322: Syntax error, expecting one of the following:

a name, a quoted string, RC, _DATA_, _LAST_,;, _NULL_.

ERROR 202-322: The option or parameter is not recognized

and will be ignored.

ERROR 455-185: Data set was not specified on the DATA

statement.
Change 22.098 Variables LCPUSHAR,LPnSHARE in ASUM70PR/ASUM70LP/ASUMCEC

VMXG70PR are the Initial Weight of the LPAR (SMF70BPS). Now, new

May 2, 2004 variables LCPUSHAC,LPnSHARC in those datasets contain the

Current Weight of the LPAR (SMF70ACS).

Thanks to Karl Lasecki, Chemical Abstracts Service, USA.
Change 22.097 Assembly error for ASMRMFV if an old OS/390 MACLIB was

ASMRMFV used: "ASMA017W Undefined keyword parameter - GETDS/LOC"

May 2, 2004 because the old GETDSAB macro did not support LOC=ANY.

Reassemble with a current z/OS MACLIB, or you can remove

",LOC=ANY" from the GETDSAB macro call in ASMRMFV source,

if you're still stuck with an old system and MACLIB.

No change was made in MXG code; documentation only.

Thanks to Dr. Alexander Raeder, Itellium, GERMANY.

Change 22.096 Global macro variables &MACINTV and &MAC30DD are defined

IMAC30DD in VMXGINIT and located in IMACINTV and IMAC30DD so that

IMACINTV TYPE30_V(PDB.SMFINTRV) and TYPE30_D(PDB.DDSTATS) datasets

VMXGINIT can be optionally created using %LET MACINTV= syntax as

May 2, 2004 an alternative to EDITing the IMAC members.

Thanks to Dr. Alexander Raeder, Itellium, GERMANY.

Change 22.095 Support for OS/400 5.2 QAPMMIOP with three new fields

VMACQACS that were added compatibly at the end of the record;

May 2, 2004 the length for QAPMMIOP is now 290 instead of 272.

Thanks to Clayton Buck, UniGroup, USA.

Change 22.094 CICS/TS 2.3 records with no excluded fields had wrong

VMAC110 values for all variables after CBSRVRNM in the CICSTRAN

May 1, 2004 dataset. If, instead, you had excluded fields from SMF,

Aug 13, 2004 like all my test CICS/TS 2.3 data, and used the UTILEXCL

program to create your IMACEXCL tailoring member, that

code did input CBSRVRNM correctly as $EBCDIC4., but the

code for un-excluded records input CBSRVRNM as $EBCDIC8,

throwing every thing else in the record off by 4 bytes.

Note: Not to defend my error, but I do STRONGLY recommend

that even if you do not have any EXCLUDEd fields in

CICS data, you should still use UTILEXCL to create

a tailored IMACEXCL for your installation; it will

minimize the size of CICSTRAN by keeping only the

CICS variables in your current release(s), and some

some optional CICS fields are only decoded if you

use UTILEXCL to create an IMACEXCL to create your

CICSTRAN data.

Aug 13: More Important Note: Variable TASCPUTM is one of

the VERY MANY CICSTRAN variables that are wrong if you

read CICS/TS 2.3 records without this change. As listed

in CHANGES since last May, MXG 22.04 or later is the

REQUIRED version to support CICS/TS 2.3 records fully.

Thanks to Helmut Roese, COM Software, GERMANY.
Change 22.093 Cosmetic. Blank lines between FIRST/LAST record messages

VMACSMF were removed, _N_= value is consistently located, and new

May 1, 2004 Start of Read SMF and End of Read Time of Day messages.
Change 22.092 For SMF 116 Subtype 1 and 2, the CICS and IMS id fields,

VMAC116 variables QWHCTNO,QWHCTRN,QWHCTASK for CICS and

May 1, 2004 variables QWHCPST, QWHCPSB for IMS

were not in the same location as the subtype 0 record.

New input statements correct those variables in the

MQMACCTQ and MQMQUEUE datasets.

Thanks to Helmut Roese, COM Software, GERMANY.
Change 22.091 Variable PCTALLBY in dataset TYPE78CU should have always

VMAC78 been a missing value, with z/OS 1.2+, per the June, 2002,

May 1, 2004 note added to the text of Change 19.203, but it has been

alway 100% instead of missing. The test was revised so

that it now is as documented, always missing value.

Thanks to Phil Baxter, Cap Gemini Ernst & Young, ENGLAND.

Thanks to Simon Bolland, Cap Gemini Ernst & Young, ENGLAND.
Change 22.090 MXG 22.02-22.03 only. Change 22.045 corrected QWHSSTCK in

VMACDB2 DB2STATx datasets (so statistics intervals would MERGE),

VMACDB2H but that change caused QWHSSTCK in the DB2ACCTx datasets

May 1, 2004 to be zero (printed as year 1960).

-MXG Logic in VMACDB2H was revised to RETAIN the STCK of

the first ID=100 record in variable STATSTCK, and use

QWHSSTCK=STATSTCK for statistics data, but directly use

QWHSSTCK=THISSTCK for ID=101 DB2ACCTx datasets.

-The RETAIN QWHSSTCK in VMACDB2 was removed as not needed.

Thanks to Dean Ruhle, J. C. Penney, USA.

Change 22.089 Variable QWHCCV was INPUT $EBCDIC12. in MXG 20.20, but as

VMAC116 the field contains both EBCDIC text characters and binary

May 1, 2004 hex values, the INPUT was changed to $CHAR12 in MXG 21.21

so that the hex values were preserved when MXG executed

under ASCII. On EBCDIC platforms, there is no difference

between $EBCDIC and $CHAR, but $CHAR informat variables

must be formatted $HEX: a binary '00'x value, PROC PRINTd

can stop VTAM output, so QWHCCV is now $HEX24 formatted.

16Jan04: Note that my choice to format QWHCCV as $HEX24

will cause printed reports to be expanded from 12 to 24

positions.

Thanks to Dean Ruhle, J. C. Penney, USA.

Change 22.088 If VMXGRMFI is invoked a second time with PDB= non-null,

RMFINTRV to re-read the PDB.TYPE7xx datasets to create different

VMXGRMFI output "PDB.RMFINTRVs", perhaps with different workload

Apr 30, 2004 definitions, the SPINRMFI dataset was reused and became

May 19, 2004 corrupted, causing spurious observations to be created.

Note:

This does NOT happen with the example in RMFINTRV using

PDB=, TRENDIN=PDB.RMFINTRV, to resummarize the first

output to create separate hourly and daily summary

datasets PDB.RMFINTHR and PDB.RMFINTDY. When the PDB=

argument is null, the SPINRMFI dataset is not used.

The SPINRMFI is only needed to keep the prior day's

last four hours, for calculation of MXG's MSU4HRAV.

If your PDB= argument is non-null in subsequent VMXGRMFI

invocations, you must use the SPINRMIN= argument to name

your spin dataset (e.g. SPINRMIN=SPINRMXX,), so that that

summarization's SPIN will be in SPIN.SPINRMXX dataset.

The default value for SPINRMIN is SPINRMFI, and I suggest

you use SPINRMxx naming convention for your dataset.

-This change also created new argument SPINRMOU, for the

output dataset name, for consistency, but it is unlikely

to be used. SPINRMOU defaults to the value in SPINRMIN.

-Each VMXGRFI with PDB=non-null must use a different SPIN

dataset; the SPINRMIN= argument changes the dataset name,

but the default "SPIN" library is used for all of them.

There is an alternative: you can have multiple "SPIN"

libraries, instead of multiple "SPIN" datasets, using the

&SPININ/&SPINOUT macro variables created in Change 22.018

(so that you could have different input and output SPIN

libraries so you could use a GDG for your SPIN library).

So you could %LET SPININ=SPIN01, to change the DDNAME for

each %VMXGRMFI invocation.

-May 19: Example in comments in RMFINTRV was missing the

comma after SPINRMIN=SPINRMDY, now corrected.

Thanks to Karl Lasecki, Chemical Abstracts Service, USA.

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

Change 22.087 Non-PR/SM systems. Datasets PDB.TYPE70 and PDB.RMFINTRV

VMAC7072 had variables IORATE and PCTTPI too low; they contained

Apr 30, 2004 values from only the last CPU, instead of the totals.

This error was introduced in MXG 21.05 when Change 21.170

moved the three lines inside the PR/SM Control Section,

which does not exist on non-PR/SM systems. The lines are

relocated after the PR/SM Control Section (NRPRCSS) loop.

Thanks to Dean Ruhle, J. C. Penney, USA.

Change 22.086 The second IF ID=xx AND MVSXA THEN DO; statement should

VMAC74 have been ELSE IF ID=xx ...., for performance reasons,

VMAC75 and to be consistent with SMF TYPE logic in MXG, but it

VMAC76 had no other impact on execution.

VMAC77

Apr 30, 2004

Thanks to Dr. Alexander Raeder, Intellium, GERMANY
Change 22.085 Support for TNG NT platform SESSION and USER objects:

EXTNT063

EXTNT064 dddddd Dataset Description Vars Instances

FORMATS TNT063 NT063 SESSION 77 181

IMACTNG TNT064 NT064 USER 17 75

VMACTNG You must update your MXG Format Library with this FORMATS

VMXGINIT member (see FORMAT step of JCLINSTL).

Apr 29, 2004

Thanks to Peter Krijger, National Bank of New Zealand, NEW ZEALAND.
Change 22.084 Large QBSTGET in PDB.DB2STATB after Change 22.045 occurs

VMACDB2 if the DB2 Subsystem was restarted, and the buffer pool

Apr 29, 2004 was not used in every interval. MXG Logic was revised

to use QWHSACE to detect a restart had occurred.

Thanks to Steve Dyck, Canadian Depository for Securities, CANADA.
Change 22.083 Support for additional unix AIX PTX objects create new

EXAIXIP datasets:

EXAIXNFS dddddd dataset description

EXAIXRPC AIXIP AIXIP AIX IP DATA

EXAIXTCP AIXNFS AIXNFS AIX NFS DATA

EXAIXUDP AIXRPC AIXRPC AIX RPC DATA

IMACAIX AIXTCP AIXTCP AIX TCP DATA

VMACAIX AIXUDP AIXUDP AIX UDP DATA

VMXGINIT

Apr 29, 2004

Thanks to Glenn Bowman, Wakefern, USA.
Change 22.082 Variable MEMINBOX in NTCONFIG dataset was 1/100th of the

VMACNTSM actual memory in the box; the INFORMAT MEMINBOX 16.2 was

Apr 28, 2004 changed to INFORMAT MEMINBOX 16. because the value is an

integer, and does not have two implied decimal places.

Thanks to Diane Parker, AmeriSource Bergen, USA.
Change 22.081 -If the translate table used to send TNG ASCII data to MVS

VMACTNG created '9E'x/'9F'x for Left/Right Square Bracket & '4F'x

Apr 28, 2004 for Exclamation Point, those unexpected values caused MXG

Apr 29, 2004 ERROR: UNEXPECTED CAPMPCM HEADER RECORD. The Left Square

Bracket test now has '9E'x for that EBCDIC value, and has

'92'x, because the ftp of the '9E'x value back to ASCII

created that unexpected value. The full test now is:

IF TYFLG IN : ('[','5B'X,'AD'X,'BA'X,'92'X,'9E'X)

-Change 21.269 blanked variable DOMAIN, but did not note

that there is no "domain" value in TNG, and that variable

should not have been created. SYSTEM is the one to use.

-The "DATA FROM PLATFORM" message now has the SYSTEM from

each new Header record; it was blank in the first message

and had the prior record's SYSTEM value in the rest.

Thanks to Gunner Jacobsen, Nordea, NORWAY.
Change 22.080 Variable CPUTM was removed from PDB.CICS built from ASG-

ASUMCICT The Monitor's MONITASK dataset, since TASCPUTM is the TCB

Apr 28, 2004 CPU time variable. CPUTM had been removed from PDB.CICSs

built by ASUMCICS and ASUMCICX by was accidentally left

in the ASUMCICT member.

Thanks to Frank Lund, EDB IT Drift, NORWAY.

Change 22.079 Support for IBM Session Manager User SMF record creates

EXIBSMSM IBMSESMG dataset. Unfortunately, there is no field that

IMACIBSM indicates what Application was connected to, so for a

TYPEIBSM specific USERID/LTERM (variables SSTUSER/SSTTNAM), that

TYPSIBSM connected to multiple applications, records with overlap

VMACIBSM between Session Start (SSTSTRTT) and SMFTIME (Signoff).

VMXGINIT Use SMFTIME instead of the lower resolution SSTSTIME for

Apr 28, 2004 the signoff time. Query to IBM as to why there is no

field for the application to which session connected.

Thanks to Dave Crandall, Farmers Insurance, USA.

Change 22.078 Cosmetic. Variable PCTDLCCA Label was corrected to be

VMAC7072 PCTDLCCA='CPU*CAPPING*DELAY*PERCENT'

Apr 27, 2004 instead of RESOURCE*GROUP... (which is in PCTDLPDE).

Thanks to Ronald Kveton, Experian, USA.

Change 22.077 Support for "second flavor" of ACCT fields; original data

VMACTPMX had the "standard type 30 job accounting string", but new

Apr 27, 2004 data has multiple ACCT fields; new logic detects which is

present and still populates ACCOUNT1-ACCOUNT9, LENACCT1-

LENACCT9 from the individual fields.

-TSSUSR2 and TSSUSR3 fields now supported.

Thanks to Lawrence Jermyn, Fidelity Systems, USA.
Change 22.076 Cosmetic. Variable _N_ was added to PUT statements for

IMACACCT error conditions and messages were single spaced.

Apr 27, 2004
Change 22.075 ARRAY SUBSCRIPT OUT OF RANGE error occurs if you have

VMAC74 more than 255 structures in your CF; the temporary arrays

Apr 27, 2004 allocated only 255 elements, but they have been raised to

1024 elements, which I believe is the maximum number of

structures supported in a CF.

Thanks to Bob Miller, CONSECO, USA.

Change 22.074 DB2 Trace SMF 102 Subtype 125 dataset T102S125 variables

VMAC102 QW0125PC QW0125PL QW0125PN QW0125TS QW0125SN were missing

Apr 27, 2004 values because the test for QWT02R1L GE 64 should have

been GE 62. The original DSECT showed two reserved bytes

but those bytes do not exist in the current record, so

the +2 at the end of segment was also removed.

Thanks to Ron Alterman, PG&E, USA.
Change 22.073 SMF 119 Subtype 10 dataset TYP11910 had invalid values in

VMAC119 variables UCINDTGR UCOUDTGR UCINBYTE UCOUBYTE because +2

Apr 27, 2004 was needed to skip two reserved bytes before UCINDTGR.

Thanks to Thomas Heitlinger, FIDUCIA IT AG, GERMANY.

Change 22.072 For Service or Reporting Classes with R723CWMN GT 0, not

VMAC7072 all periods were output. With three periods, only the

Apr 27, 2004 first period was output; with four periods, only the 1st

Aug 5, 2004 and 2nd periods were output. This is NOT a new error;

MXG has always been this way:

Inner loop IF R723CWMN GT 0 THEN DO _I_=1 TO R723CWMN;

(for the two state/delay sections), and the outer loop

(for each period), DO _I_=1 TO NRSCS; used the same _I_

variable! Transaction Service Classes have R723CWMN=2

(begin and end entries), causing _I_=3 when R723CWMN=2,

so if NRSCS (number of periods) was 2 or 3, only the

first period's data was created. (With 4 periods in

the service class, only the first and second period

data was output, but not the 3rd nor 4rd, etc.).

The DO variable in the inner loop was changed to _II_ to

correct this error.

-The April text cited R723TYPE=3 as the only exposure, but

the error actually occurred with any service or reporting

class with R723CWMN non-zero. This text was revised in

August, but the April code change was not affected.

Thanks to Tom Koelle, CitiGroup, USA.

Thanks to Dave Crandall, Farmers Insurance, USA.

Change 22.071 Test string for "SAS Product SMF Record" change to SASU

UTILBLDP (it was SAS) to correctly include VMACSASU, etc., when

Apr 26, 2004 SAS USER records are to be processed.

Thanks to Dr. Alexander Raeder, Itellium, GERMANY.

Change 22.070 Modification to VMXGSUM to prevent a bizzare abend that

VMXGSUM should not happen but did happen in one isolated case,

VMXGSUME where a slash was used. Addition of %STR resolved.

Apr 26, 2004

CHANGE 22.069 The BLDSMPDB utility for daily/weekly/monthly/trend PDB

BLDSMPDB had used SMF= for its input argument, but Change 22.060

Apr 26, 2004 replaced hardcoded SMF DDname in VMACSMF with &SMF, which

caused BLDSMPDB code to fail; the name in BLDSMPDB was

changed to SMFIN= to eliminate the conflict and error.

Thanks to ???, ???, USA.

Change 22.068 -Support for optional RMI data for both CMODNAME='RMI' in

VMAC110 IMACICRM and CMODNAME='DFHRMI' in IMACICRD adds similar

UTILEXCL but different sets of RMIxxxxx variables.

IMACICRD -UTILEXCL was revised to support DFHRMI and RMI segments;

IMACICRM without this change, if CMODNAME='DFHRMI' was in the CICS

Apr 17, 2004 dictionary, the IMACEXCL created by UTILEXCL failed with

a SAS 180 error, underscoring variable TRANTYPE.

Thanks to Neil Ervin, Charles Schwab, USA.

Change 22.067 Ending */ comment was missing, but the only impact was

SPUNJOBS that work datasets were not be deleted.

Apr 16, 2004

Thanks to Dov Brosch, Bank Hapoalim, USA.

====== Changes thru 22.066 were in MXG 22.03 dated Apr 5, 2004=========
Change 22.066 Cosmetic. Labels for SOMSGIN1 and SOMSGOU1 were reversed.

VMAC110

Apr 5, 2004

Thanks to Allan J. Winston, MBNA, USA.

Change 22.065 The six undocumented ESS fields in SMF 57 (Change 22.057)

VMAC6 are also in SMF 6 records, and are decoded in variables

Apr 5, 2004 SMF6C1, SMF6C2, SMF6C3, SMF6N1, SMF6N2,and SMF6N3

Thanks to Rainer Hertwig, Lufthansa Systems Infratec GmbH, GERMANY.

Change 22.064 -Executing "MONTHBLD" on ASCII platforms caused errors, as

AUTOEXEC it was designed to run on "MVS", with RECFM=FB, which SAS

MONTHASC does not honor on ASCII; it presumed MVS JCL provided the

INSTALL required //DUMMY DD'; it created the MONTHPDB in "tape"

Apr 2, 2004 (sequential) format, to eliminate MVS tape mounts, etc.

This new MONTHASC member executes under ASCII and creates

a "disk" format SAS Data Library, but it also executes on

"MVS", and it may be preferred there, now that Virtual

Tape drives have eliminated most of the concerns about

tape mounts, and the "disk" format library with directory

is much faster to access a single dataset; furthermore,

the "disk" format PDB can be migrated to tape by HSM!

-AUTOEXEC member was revised to add LIBNAME DUMMY, which

is used for "dummy" datasets in MONTHASC.

-INSTALL for MXG install under ASCII was revised to note

that you need to create c:\mxg\dummy directory and the

c:\mxg\userid\instream.sas file, if you did not copy the

MXG product from CD-ROM (that directory and file are now

created on the CD-ROM).

Thanks to Joe Keey, BOC, ENGLAND.

====== Changes thru 22.063 were in MXG 22.03 dated Apr 2, 2004=========
Change 22.063 The delay percentages in TYPE72GO are calculated by using

VMAC7072 R723CTSA, execution samples, if it is non-zero as the