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

VMAC102 -T102S371 variables QW0371CL and QW0371DA were 1000000 too

Feb 18, 2014 large, as the input was &PIB.8. instead of &PIB.8.6.

Thanks to Rachel Holt, Fidelity Systems, USA.
Change 32.031 RMF TYPE748 ESS Subtype 8 datasets completely revised.

EXTY748I -The existing TYPE748 dataset had an observation for every

EXTY748L LINK, instead of just one observation per CUSERIAL. R748L

EXTY748P variables are moved to the new TYPE748L Link dataset.

IMAC74 IBM print 12 digits for CUSERIAL on RMF reports, but that

VMAC74 field is only 10 characters in the subtype 8 record, so

VMXGINIT match on CUSERIAL failed. Extra 00 characters added.

Feb 14, 2014 -The new TYPE748L Link dataset is created with one obs per

Feb 17, 2014 CUSERIAL and R748LAID Link Adapter ID.

-The TYPE748R RANK dataset and TYPE74A RANK ARRAY dataset

are now merged by CUSERIAL R748RRID (Rank Raid ID) to

create the new PDB.TYPE748I "ID" dataset with R748rXID

(Extent Pool) for the detail ESS RANK STATISTICS report.

Unfortunately, the Raid Rank Level can NOT be mapped back

to the logical VOLSER of the I/O.

-In addition, _STY748I also sums the TYPE748I dataset by

CUSERIAL R748XPID to create the Extent Pool Sums in the

new PDB.TYPE748P "EXTENT POOL" dataset.

-Dataset TYPE748X is unchanged.

Thanks to Patricia J. Jones, DST Systems, USA.

Change 32.030 -ASMRMFV execution could fail with RMFV035S >>>>SEVERE

ASMRMFV 1 RED TABLES SKIPPED DUE TO INVALID ID OR FLAG error

Feb 13, 2014 and the program could loop due to an outdated branch in

the DETAIL subroutine when one or more RMF III table

errors were found. The errors detection was valid but

the recover and notification looped.

-REQUIREMENT: In order to implement this fix the

current ASMRMFV utility program from this MXG change

must be installed. See MXG SOURCLIB member JCLASM3 for

sample JCL for the assembly and link-edit install steps.

Thanks to Andre Gustavo Moretto, IBM Global Services, BRAZIL.
Change 32.029 -VMXGPRAL print utility ERROR 72-322: Expecting a ). after

VMXGPRAL a DATA _NULL_ step highlighting this statement:

Feb 12, 2014 SYMPUT("OBS&I",PUT(NOBS,12.); that's missing the paren.

-COMPBL HAS TOO MANY ARGUMENTS if the DATASET LABEL that

is now printed with the DATASET name has a comma. The

commas are removed in VMXGPRAL to circumvent, but See

Change 32.005 - commas to be removed with DATASET LABELs

added to that planned list.

Thanks to Paul Volpi, UHC, USA.
Change 32.028 Protection for BETA93 truncated SUBTYPE=51 record that

VMACBETA caused INPUT STATEMENT EXCEEDED because LOCFIELD+BETAFLEN

Feb 10, 2014 (offset plus length) exceeded the record length. In this

specific record, there were two valid segments that were

output but the third segment was truncated so only the

first two segments were output.

Thanks to Andreas Menne, Finanz Informatik, GERMANY.
Change 32.027 MXG 32.01. INVALID DB2 10.1 HEADER RECORDS, DELETED,

VMACDB2H if the DB2 APAR PM62481, a 2012 APAR that added the

Feb 11, 2014 QWHSAACE field to the QWHSTYP=2 Header Segment, is NOT

installed, because when Change 32.002 INPUT that field,

it was not from the APAR, but last month when I saw that

it was in DSNDQWAC for DB2 V10 and had been overlooked,

and I assumed it was always present by testing for the

QWHSRELN GE 10.2, and ran the MXG DB2 QA with 15 site's

data and no errors. Today, two sites, Australian and

USA, reported the error message and sent data with

QWHSLEN=156, instead of the 164 byte expected with the

field present.

-May 2014: This MXG 30.01 ERROR MESSAGE (yes 30.01!!):

**VMACDB2.ERROR. INVALID IBM TYPE 101 RECORD DETECTED.

YOU MUST INSTALL IBM APARS PN56441 AND PN63234....

was also corrected with this updated VMACDB2H.

(Those APARs were from 1994!).

-MXG input logic was revised to use actual segment lengths

and not the version number to detect the existence, which

then required the creation of QWHCEXTRA with the count of

bytes added for the "truncated" name fields, so it could

be subtracted from QWHSLEN to get the actual length of

the base segment to know for certain if QWHSAACE exists.

With this much time and effort to diagnose and resolve,

at least the new QWHCAACE field may be worth it:

QWHCAACE is zero if the IFCID is written outside of an

accounting interval. Otherwise it will contain a value

that can be correlated to QWHSACE in the IFCID3/DB2ACCT

accounting record. For DDF/RRSAF rollup accounting

records, QWHCAACE should be correlated to QWARACE as the

record will represent multiple transactions. For

parallel tasks, QWHCAACE will point to the ACE of the

parent task.

Thanks to Andrew Petersen, CSC, AUSTRALIA.

Change 32.026 TRNDRMFI could fail if all possible 114 workloads were

VGETWKLD defined in your RMFINTRV dataset, because the limit of

VMXGRMFI 64K bytes of text for a macro variable was exceeded.

VMXGSUM Each of these potentially-large macro variables are now

Feb 7, 2014 created by writing text to FILE INSTREAM as old-style

Feb 10, 2014 macros so the macro variable only contains the old-style

Feb 18, 2014 name; see Change 31.288. Additional macro logic also

reduced size of some other macro variables, and to also

circumvent the 262-byte limit between quotes.

-VMXGSUM was also revised to minimize the size of macro

variables it creates, by calling SYSFUNC to invoke COMPBL

to remove duplicate blanks, but because the argument can

be blank, causing a TOO FEW ARGUMENTS FOR COMPBL error,

%LET ALLVARS=%SYSFUNC(COMPBL(%STR(&ALLVARS &MIN)));

was needed to avoid that (harmless) error message.

-VGETWKLD: the lists in WORKLOAD, NEWLABL, STRING are now

TRIMed before APPEND to reduce text length, and protect

for blank labels added.

====== Changes thru 32.025 were in MXG 32.01 dated Feb 6, 2014=========
Change 32.025 CPUCRPTM, CPU TCB+SRB during CHRONIC CONTENTION was wrong

VMAC30 as the second multiply by 1024 was incorrect. Fortunately

Feb 6, 2014 this is a standalone CPU metric added in Version 26 that

has obviously not been examined previously!

Thanks to Leonard Jejer, MorganStanley, USA.
Change 32.024 RMFINTRV created with a large number of workloads could

VGETWKLD cause TRNDRMFI to fail because the wrong dataset was

Feb 6, 2014 SORTED. PROC SORT DATA=WORKLOADS corrected this error.

Thanks to Wayne Bell, UNIGROUP, USA.

Change 32.023 Support for IMS LOG Record 06 creates IMS06 dataset, to

ASMIMSL6 track IMS startup/shutdown/other conditions.

EXIMS06

FORMATS

IMACIMS

VMACIMS

VMACIMSA

VMXGINIT

Feb 5, 2014

Thanks to Rosa Maria Martinez Alonso, Bustia, SPAIN.

Change 32.022 Support for CA XCOM Version 11.6 INCOMPATIBLY changed the

VMACXCOM SMF record. This updated VMACXCOM supports both 11.6 and

Feb 5, 2014 11.1, transparently.

Thanks to Claudio Zanon, Phoenix, ITALY.

Change 32.021 Change 31.285 was removed. The FILENAME INSTREAM added

VMXGINIT in VMXGINIT, to eliminate the need for //INSTREAM, fails

Feb 4, 2014 if you used it, for example, to write date macros in one

job and then use %INCLUDE INSTREAM in all your report

jobs to instantiate that code, a quite reasonable thing

to do. Unfortunately, the FILENAME INSTREAM CATALOG fails

on the %INCLUDE because it was never opened for output so

it doesn't exist, and using FILENAME INSTREAM TEMP also

fails, but without error: the TEMP is included instead of

the //INSTREAM DD that you wanted to %INCLUDE.

Thus an INSTREAM DD/FILENAME is still be required by MXG.

Another symptom of the need for the new VMXGINIT are

these log messages:

ERROR: CATALOG WORK.MXGTEMP DOES NOT EXIST.

ERROR: CANNOT OPEN %INCLUDE FILE INSTREAM.

Thanks to Arylon Brooks, Verizon Wireless, USA.

Thanks to Nick Bubica, Verizon Wireless, USA.

Thanks to Stephen K. Simon, Verizon Wireless, USA.

Change 32.020 MIPFACTR set to a null string and logic was inserted to

GRAFWRKX base the MSU to MIPS factor on the CPCFNAME variable so

Feb 1, 2014 that GRAFWRKX will automatically reflect the MIPS on the

current machine. The MSU chart reflects MSU consumed

during the period and the MIP chart reflects the MIPS

of capacity consumed during the period. MIPFACTOR can

be overridden with a value of your choice. The values

used by default are:

2097 - 6.5 2098 - 6.5 2817 - 8

2818 - 8 2827 - 8 2828 - 8

Change 32.019 -READDB2 did not always use LDB2ddd override, and &PDBOUT

ANALDB2R option logic was restructured with better documented

ANALDBTR possible values: UNIQUE, YES, PDB/XXXX, NULL/WORK.

ANALTURN Now, WANTONLY will be honored when specified for ACCTs.

READDB2 -Fixing READDB2 uncovered an error in ANALDB2R where the

Feb 4, 2013 datasets were created in PDB, but report expected data

in WORK.

-ANALDBTR. Restructured and revised and corrected, mostly

preventing spurious "THE STRING" messages that only were

printed when there were multiple ANALDBTR invocations

(e.g., when ALL POSSIBLE reports are executed).

-ANALDB2R. Similar restructure and cleanup with heavy

testing with ALL reports and with DATA for all reports.

-ANALDB2R. Reports IOS SQL LOK TRN may not be correct with

PDB=SMF,PDBOUT=WORK (or no PDBOUT=) but they are fine if

PDB=SMF,PDBOUT=PDB (or any XXX DDNAME). I may choose to

leave it this way for these extremely detailed and seldom

used reports, since the repair would be VERY tedious and

there's no cost to using PDBOUT= PDB with PDB temporary.

-ANALDB2R. Requirement for PDBOUT=PDB to be specified for

PMTRC01 Trace Report was never documented but now is no

longer required with revision of the READDB2 logic to set

the output destination for the T102Snnn based on PDBOUT.

-UNRELATED, BUT: CAUTION FOR THE USE OF DATASET VIEWS:

Discovered in QA test when ANALTURN created WORK.STATS

that was left in WORK, and then 30 steps later, ANALDB2R

failed when it tried to create WORK.STATS/VIEW: you CAN

NOT create a dataset view named X if there already is a

dataset named X. This has NOT been an actual problem at

customer sites, but MXG View names are not documented and

you could create an accidental conflict in your programs

that only shows up when you subsequently execute MXG code

that happens to use that dataset name. Fortunately the

error message text makes it clear what dataset name YOU

have to change in YOUR code.

ANALTURN now deletes WORK.STATS.

Change 32.018 Unused Change Number.
Change 32.017 A mislocated RUN; statement cause VMXGPRNT and VMXGPRAL

VMXGPRNT to fail with a 180 syntax error pointing to LABEL.

Jan 29, 2014

Thanks to David Schumann, Blue Cross Blue Shield of Minnesota, USA.

Change 32.016 DB2 Netezza variable Q8STNAME, Accelerator Server ID, was

VMACDB2 not kept in PDB.DB2STATS dataset; its offset was read in

Jan 29, 2014 but then the field was never input.

Thanks to Giuseppe Giacomodonato, EPVTECH, ITALY.

Change 32.015 Cosmetic. Variable ACTHNODE was set to blank or 'Y' but

VMACBVIR it incorrectly was formatted $HEX2. so the 'Y' printed as

Jan 29, 2014 'E8'X. Now the Y will be printed as a Y.

Thanks to Keith McWhorter, IBM Global Technology Services, USA.

Change 32.014 Variable CPUUOWTM incorrectly (now) included DB2TCBTM, as

VMXGUOW that WAS correct back when VMXGUOW was written, but that

Jan 29, 2014 changed in CICS/TS 3.2 with the OTE Environment when the

DB2TCBTM was added into the TASCPUTM in CICSTRAN, so the

equation is now CPUUOWTM=SUM(CPUTM,CPUMQMTM);

Thanks to Rick Southby, Insurance Australia Group, AUSTRALIA.

Change 32.013 Create $PLOTCHAR to map one character from SYSTEM name to

VMXGPLCH be used as the "Z-AXIS", the third position variable, in

Jan 28, 2014 PLOT statements so each point is identified to SYSTEM.
%VMXGPLCH(DATASET=PDB.YOURS,VARIABLE=SYSTEM,POSITION=4);

RUN;

PROC PLOT DATA=PDB.YOURS;

PLOT X*Y=SYSTEM;

FORMAT SYSTEM $PLOTCHAR.; <== add in your report code

RUN;
An example in comments shows how to store the formatted

value back into SYSTEM, so that your existing reports do

not need to have that FORMAT statement inserted.

Thanks to Sam Bass, McLane Co., USA.
Change 32.012 Many new spurious MXGWARN: DATASET xxx.yyy DOES NOT EXIST

VGETOBS messages (BUILDPDB for ALL of the PDB.CICxx statistics

Jan 28, 2014 datasets read to create CICINTRV, i.e. where VMXGWORL

calls VGETOBS first for PDB and then for WORK to find the

"_L" or "_W" location) are printed after Change 31.180,

because VGETOBS did not test for NOEXIMSG=YES in line 282

causing the unwanted warning to be printed. Now correct.

Thanks to Carol Arnold, Brown Brothers Harriman & Co, USA.

Change 32.011 MXG 31.31-31.06. USER ABEND 1950 CICSTRAN DOES NOT EXIST

ASUMUOWT because the ASUMUOWT (UOW TMON MONITASK vs CICSTRAN) did

Jan 28, 2014 not null the default _LCICTRN DDNAME value of CICSTRAN

before it called VMXGUOW. Previously, when VMXGUOW then

called VGETOBS to test for the existence of the CICSTRAN

libname, there was only a warning message, and as it was

never actually referenced, PDB.ASUMUOWT was created fine.

In Change 31.180, VGETOBS was changed to USER ABEND 1950

so that you cannot overlook it, when you ask MXG to use

a non-existent LIBNAME.

The correction in ASUMUOWT: add MACRO _LCICTRN _NULL_ ;

in the existing %LET MACKEEP= redefinitions, but you can

circumvent for ASUMUOWT just by adding a temp //CICSTRAN.

This was missed in my QA because all ASUMUOWT tests just

happened to also have a CICSTRAN LIBNAME allocated.

Thanks to Frank Lund, EVRY AS, NORWAY.

Change 32.010 IBM APAR OA43921/OA44049 cause MXGTMNT ABEND 0E0 RC28.

ASMTAPEE This is ML-52 level MXG Tape Mount Monitor. With those

Jan 28, 2014 APARs, on a z/OS 1.13 system, after return from MCSOPMSG,

Master Console Service, register AR15 returns non-zero,

not previously observed, nor expected, nor protected, but

because MXGTMNT is in AR mode, it fails with ABEND 0E0.

MXGTMNT Starts and Shutdown with these messages:

IEA630I OPERATOR MXGC0004 NOW ACTIVE, SYSTEM=SYSX,

LU=MXGTMNT

MXGC009E Unrecoverable error in Allocation Recovery

Monitor, function is terminated.

MXGC008E Recoverable abend limit reached, monitor

extension subtask is terminated.

IEA630I OPERATOR MXGC0004 NOW INACTIVE,SYSTEM=SYSX,

Register AR15 is now cleared in ML-52, now that we know

we need to!

Thanks to Warren Cravey, Fidelity Institutional, USA.

Thanks to Chuck Laurent, Fidelity Institutional, USA.

Change 32.009 -RMF III Enhancements, Fixes, and Notes

ASMRMFV -FROMDATE=/TODATE= and FROMTIME=/TOTIME= date and time

ADOCRMFV selection parameters now have better error detection

Feb 2,2014 and diagnostics. Error messages include more detail

about what the specific error was.

-FROMDATE=/TODATE= now support Gregorian style dates in

the format of FROMDATE= or TODATE= ddmmmyyyy where dd is

the day of the month, mmm is a 3 character month name,

and yyyy is a 4 digit year.

-Also supported are the following Gregorian style date

formats for usability and flexibility: ddmmmyyy, ddmmmyy,

ddmmmy, ddmmm, and mmm

-For yyy, yy, and y years 2000 is added to create the

year. When no year is present the current year is used.

When no day of the month is present the first day of the

month is used. mmm must always be present and cannot

further be shortened.

-Also supported are the following Gregorian style date

formats so that a leading dd day of month zero is not

required for days 1-9 of a month: dmmmyyyy, dmmmyyy,

dmmmyy, dmmmy, and dmmm.

-NOTE: Gregorian style dates are validated so that the dd

value does not exceed the number of possible days in the

month. 29FEB is only allowed for leap years.

-NOTE: Similar to Julian style dates, YYYY366 is also

only allowed for leap years.

-NOTE: ASMRMFV supports dates from 2000.001 January 1,

2000 through and including 2042.259 September 16, 2042.

Dates outside this range will be flagged as errors.

-NOTE: On 2042.260 September 17, 2042 the 8 byte TOD clock

will wrap just after 22:53:47.370495 as all bits will be

X'FF'. If RMF Monitor III still exists at that time, IBM

will need to use the Extended TOD clock or some other

mechanism for time stamps in this data.

-Generic values for FROMDATE= and TODATE= such as

YESTERDAY and TODAY may now be shortened to as few

characters as desired even down to the single characters

Y and T. Before the full length had to always be used

which was cumbersome.

-Processing routines for FROMDATE= and TODATE= are

combined into a single routine for better efficiency as

are the routines from FROMTIME= and TOTIME=.

-A second RMFV041I message is now displayed for each found

VSAM data set when using the Dynamic Method. It includes

the VSAM data set type, volume serial, average and

maximum LRECL, Control Interval size, and Creation Date.

This is intended to allow better identification that the

correct RMF Monitor III VSAM data sets have been pattern

selected by this method.

-When message RMFV002I is displayed showing the JCL PARM=

field contents, the length of the PARM field is now

displayed. There is a z/OS limit of 100 characters for

the PARM= field. If you are nearing this limit consider

using the SYSIN DD file instead of or in addition to the

PARM= field.

-When execution environment messages RMFV001I are

displayed, there is now an additional message showing the

last IPL date, time, and IPL volume serial.

-Parameter end processing was not validating that the

FROMDATE= value did not exceed the TODATE= value when

other errors had previously been detected.

-Parameter end processing was not validating that the

FROMTIME= value did not exceed the TOTIME= value when the

same day had been selected and other errors had

previously been detected.

-Documentation in the ASMRMFV source prologue and in the

ADOCRMFV member has been updated to discuss the new

Gregorian style formats for FROMDATE= and TODATE=. More

examples are added also.

-REQUIREMENT: In order to receive these improvements the

current ASMRMFV utility program from this MXG change must

be installed. See MXG SOURCLIB member JCLASM3 for sample

JCL for the assembly and link-edit install steps
Change 32.008 Cosmetic. The text in the file created by UTILBLDP that

UTILBLDP identifies the last change still had Change 30.115 after

Jan 27, 2014 Change 31.276. A new QA test compares the text with the

LAST UPDATED information in line 2 to detect mismatch.

Thanks to Clayton Buck, UNIGROUP, USA.
Change 32.007 MXG 31.31. SMF ID=111 INPUT STATEMENT EXCEEDED LENGTH,

VMAC111 because line 659 should be SKIP=SKIP-16; instead of -8.

Jan 27, 2014

Thanks to Flemming Bramsen, SEMLER, DENMARK.

Change 32.006 -PDB.TAPES/PDB.ASUMTAPE variable BYTEWRIT for 3590 tapes

VMAC21 could still be too small, after Change 31.244, when more

Jan 26, 2014 than 64GB uncompressed bytes were written, i.e., when the

count of 4K blocks written exceeds the 3-byte 'FFFFFF'x

maximum in SMF21BW. When SMF21BW overflowed, MXG used

the compressed count in SMF21DBW when the uncompressed

count in SMF21DBW should have been stored instead.

The error can only impact DEVICE='3590'. So far, only

SMF21BW has exceeded 64GB, but the error would also be in

BYTEREAD if SMF21BR had overflowed.

-Variables SMF21BWN & SMF21BRN are now kept in PDB.TAPES.

Thanks to Yves Cinq-Mars, IBM Global Services, CANADA.

Change 32.005 -Support for ID=90 Subtype=35 SETLOAD XX IEASYM Command

FORMATS record, overlooked because it is not listed in subtypes

VMAC90A on page 734, and the documentation text was located after

EXTY9035 Subtype 33 instead of after Subtype 34 (and before 36).

VMXGINIT -Discovered when updating the ANALID $MGSMFID format to

Jan 25, 2013 describe SMF record IDs 38, 85, 90, and 118 for ANALID.

-All MXG FORMAT'S VALUES ARE NOW COMMA-FREE, for ease in

exporting SAS datasets with formatted variables to EXCEL,

since commas can't exist in CSV Comma Delimited files,

and blanks read just as well where there were commas.

-While far less likely to be exported, over time, I will

also replace all commas in the LABELs of MXG variables.

Change 32.004 Cosmetic. "Destructive" added to these variable's label:

VMAC116 WQGETA ='MQGET*DESTRUCTIVE*(ANY)

Jan 23, 2014 WQGETS ='MQGET*DESTRUCTIVE*(SPECIFIC)'

Thanks to Pietro Rosella, Canadian National, CANADA

Change 32.003 OUTDATA= parameter added should you wish to preserve the

ANALCOMP output dataset created by ANALCOMP.

Jan 22, 2014
Change 32.002 -Support DB2 QWHC Header variable QWHCAACE Initiator ACE,

VMACDB2H added in DB2 V10 is now INPUT but only right four bytes

Jan 22, 2014 are input, as all other ACE fields are 4-bytes and data

shows those are the populated bytes. Kept in all DB2 data

sets that currently have QWHSACE from the QWHS header.

Logic to detect that QWHCAACE is present require revision

because records with only QWHCAACE are created, although

the DB2 QWHC DSEC documents that both QWHCAACE and the

two 2-byte offsets for EUTX/EUWN were added.

-DB2 V10 increased QWHCEUTX Users Transaction Name length

from $32 to $128 and QWHCEUWN Users Workstation length

from $18 to $128, in two relocated "Truncated" segments.

Change 32.001 -NTSMF objects TCPV4 and TCPV6 were INCORRECTLY output in

VMACNTSM dataset TCP versus the correct TCPV4 and TCPV6 datasets,

Jan 21, 2014 causing apparent duplicate observations in TCP dataset,

Jan 25, 2014 because the OBJECT=:'TCP' test should have been changed

to be OBJECT=:'TCP ' when the new TCPV4 and TCPV5 objects

were supported (or the test for those longer object names

should have preceded the shorter name.)

-WEB SERVICE CACHE object, dataset WEBSRVCA new variables:

WBSCOUMU WBSCOUCF WBSCOUCH WBSCOUCI WBSCOUFI WBSCOUTF

WBSCOUTH WBSCOUTM

-ASP.NET APPLICATIONS object, dataset ASPNETAP, new vars:

ASPARQBI ASPARQBO ASPARQEX ASPARQFA ASPARQSU ASPARQTO

Thanks to Carl Levy, Boeing, USA.

Thanks to Kenneth R. Jallen, Boeing, USA.