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

BY VARIABLES NOT SORTED ON DATASET WORK.REPORT; example

in Change 28.004 that revised that report DOES NOT FAIL,

but removing the CONNTYPE=4 selection exposes the missing

BY statement that was added by this change.

-Audit report corrections, all prior versions:

-The BIND code was inside the loop for DML (should not

have been).

-PMAUD02/PMAUD03 reports did not agree with doc; they

were only produced when you used the AUDIT= subparm,

but now, as documented, ALL possible Audit classes

will be reported with the default AUDIT=, value.

-SQL Text printed for 141 and 145x Audit records.

-Divide by ZERO when GETS=0 is now protected.

-Cosmetic: SUDIT now correctly spelled AUDIT.

MXGWARN that PDB.ASUMDB2x NOT FOUND have been removed.

ANALDB2R first looks for the ASUMDB2x dataset for a

report request, as that saves I/O and CPU time, but

warning that it wasn't found was confusing, especially

when you knew nothing about that internal design.

-Jun 17: MACDB2H was not honored until this date.

Thanks to Jim Kovarik, AEGON USA, USA.

Thanks to Stephen Root, Harry and David, USA.
Change 28.082 MXG Formats $MGDDDDD and $MGDDDSN map the "dddddd" token

FORMATS to each "dataset" and vice versa, but the UDDDDDD program

UDDDDDD missed some of the "dddddd" values, in particular, CICTRN

Apr 18, 2010 and DB2ACC, and not all datasets were identified, as that

old logic read selected source members for the _Wdddddd,

which doesn't exist for all datasets. Now, UDDDDDD reads

DOCVER to capture ALL dataset names, and labels for all

datasets now contain "DDDDDD:" in their dataset label.

UDDDDDD is also added to QASAS so those formats will be

updated with each new version; DOCVER is already heavily

validated in post-QA reports. These members were updated

to revise/add unique DDDDDD: to their dataset labels:

ANALVM ASUM94 ASUMCIMS ASUMDB2P ASUMDB2S ASUMMWUX

ASUMSTC ASUMTALO BUIL3001 BUILD001 BUILDPD3 BUILDPDB

DIFFROSC MNTHDB2S TRNDDB2A TRNDDB2B TRNDDB2G TRNDDB2P

TRNDDB2S TRNDDB2X TRNDSTC TYPEPDL TYPEVLFC TYPEZARA

VMAC0 VMAC110 VMAC21 VMAC30 VMAC84 VMACCIMS

VMACCRAy VMACMWUX VMACNMON VMACVMON VMACVMXA VMXGCICI

VMXGDBSS VMXGHSM VMXGRMFI

Thanks to Francine Gheyle, Dexia Bank, BELGIUM.

====== Changes thru 28.081 were in MXG 28.02 dated Apr 14, 2010========
Change 28.081B PRO/SMF dataset PRORECOV was misaligned after the INPUT

VMXGINIT of variable GWMSGED.

Apr 14, 2010
Change 28.081A PRO/SMF dataset PRORECOV was misaligned after the INPUT

VMACPROS of variable GWMSGED.

Apr 14, 2010

Thanks to Perry Lim, Union Bank, USA.

Change 28.081 OPTIONS VARLENCHK=NOWARN is reinstated in VMXGINIT if the

VMXGINIT SAS Version is 9.2 TS2M0 or later to eliminate the new

Apr 12, 2010 WARNING: MULTIPLE LENGTHS WERE SPECIFIED FOR THE VARIABLE

that is discussed MANY times in several NEWSLTRS. While

MXG 26.03 eliminated the warning in internal code,

user code is now protected, and future changes in lengths

of IBM fields (e.g., CLIPADDR increased from 16 to 40 to

support IPV6) will not produce that WARNING, nor a Return

Condition Code of 4. (One cause of the warning is the

use of PROC MEANS to create an output dataset without the

option /INHERIT at the end of its OUTPUT statement.)

Thanks to John Kim, ATCO I-tek, CANADA.

Change 28.080 z/OS 1.11 adds new variable to TYPE70 dataset

VMAC7072 SMF70GAU='CAPACITY GROUP AVAILABLE MSU

Apr 12, 2010 which is documented as

-Long-term average of CPU service in millions of

service units which would be allowed by the limit of

the capacity group but is not used by its members.

-If the value is negative, the group is capped.

So, this variable is input with &IB.4. since in this rare

case, a negative value is not only possible, it is now

very useful as an indication that the Capacity Group is

Capped.

Thanks to Scott Barry, SBBWorks, USA.

Change 28.079A This change WAS included in MXG 28.02, but this text was

VMXGINIT not: the test for NOWORKINIT was removed in MXG 28.02.

Apr 14, 2010 Change 28.023 added that test and a USER ABEND 990 if

OPTION NOWORKINIT was enabled, but my cure was worse

than the disease. There IS a serious exposure in MXG

if NOWORKINIT is enabled, but I know now it is ONLY in

a second MXG step, and only after a first-step error,

and the real exposure is only MY time in diagnosing!.

Some SAS sites have now ABENDed (unnecessarily) because

that option is enabled in their SAS tailoring, and WPS

set NOWORKINIT as default (when WORK was temporary and

did not need to be INIT, and their INIT process was

inefficient, but their INIT is improved and WORKINIT is

to be the default in their next GA), and now that I

know that NOWORKINIT, of itself, does not create a

problem for MXG code, my test and USER ABEND 990 were

removed in MXG 28.02.
Change 28.079 MXG 27.11-28.01, ONLY with the MXGTMNT Tape Monitor data:

VMACTMNT SAS has had a limit on the length of an observation of

Apr 12, 2010 32760 bytes, which prevents the Host Sort from being used

if exceeded, with this SAS Warning printed on the log:

The total length of all variables must be less than or

equal to 32760 bytes. The host sort cannot be used.

The internal SAS sort will be used; this may impact

performance. Adjacent to TYPESYSL dataset references.

(An increase in CPU time of about 37% was observed.)
Change 27.336 increased the length of variable SYSLTEXT,

the SYSLOG Message Text, from 1024 to 32384, but that was

needed/intended ONLY for the TYPESYSL dataset (which can

OPTIONALLY capture any SYSLOG message); that length is

for the largest possible multi-line SYSLOG message. BUT:

variable SYSLTEXT was also accidentally increased in the

TYPESYMT dataset, used ONLY for Tape-Mount-Event-Related

SYSLOG messages, needing a SYSLTEXT length of only $256.

Even worse, new variable SYSLENCR, to identify Encrypted

Tapes, was created as SYSLENCR=SUBSTR(SYSLTEXT,x,16), but

because I failed to put the new variable in a LENGTH $16

statement, it got the 32384 byte length of SYSLTEXT. So

with SYSLTEXT and SYSLENCR, TYPESYMT had an observation

length of 65183, causing the preceding WARNING message.

This change restores the length of SYSLTEXT to $256, and

the TYPESYSL dataset's variable is now named SYSLLONG.

Note that the SPINSYSL dataset created with 27.11-28.01

by the %INCLUDE SOURCLIB(ASUMTAPE); that should always be

used to create the PDB.ASUMTAPE Tape Mount Event dataset

also exceeded 32760, with observation length 65198, but

it is not sorted, and its observation length is corrected

when this change is implemented.

Thanks to Siegfried Trantes, Gothaer-Systems, GERMANY.

Thanks to Richard Sabine, Gothaer-Systems, GERMANY.

Thanks to Willi Weinberger, Gothaer-Systems, GERMANY.
Change 28.078 VMXGGETM reports SMF record counts and bytes by SUBTYPE

VMXGGETM and ID, but DB2 100 and 101 records subtypes were changed

VMACSMF to their IFCID; now their actual SMF SUBTYPE is printed.

Apr 11, 2010 (For the DB2 102 record, which does NOT have a SUBTYPE in

the SMF Header, the IFCID is still used for SUBTYPE.)

-The setting of SUBTYPE logic was removed to VMACSMF.

Thanks to Tom White, Dell, USA.
Change 28.077 Support for JES 3 JMF TYPE84 records; previously only the

VMAC84 header was supported for subtype 5; this update supports

Apr 10, 2010 all ten subtypes.
Change 28.076 Variable CECSER is now added to PDB.RMFINTRV, but this

VMXGRMFI change was NOT moved into MXG 28.02.

Apr 18, 2010
Change 28.075 IBM's John Burg presentation at 2010 Seattle SHARE in

VMAC113 session 2113 provided insight into the new TYPE113 HIS

Apr 9, 2010 monitor data, and these new variables are created:

CPI='CYCLES*PER*INSTRUCTION'

PRBSTATE='PERCENT*PROBLEM*STATE'

L1MP='LEVEL*1*MISS*PERCENT'

L15P='PERCENT*SOURCED*FROM*L1.5*CACHE'

L2LP='PERCENT*SOURCED*FROM*L2*SAME BOOK'

L2RP='PERCENT*SOURCED*FROM*L2*DIFFEERNT*BOOK'

MEMP='PERCENT*SOURCED*FROM*MEMORY'

LPARCPU='APPL*PERCENT*CAPTURED AND*UNCAPTURED'

-John's presentation is also available at Techdocs:

http://www.ibm.com/support/techdocs/atsmastr.nsf/WebIndex/TC000041

-Using %INCLUDE SOURCLIB(TYPE113); _RPT113 ; RUN;

will replicate his example report.

-Variable SM1132CP, CPU Speed, was INPUT but not carried

into the TYPE113 dataset.

-A subsequent update will look for PDB.TYPE70 dataset, and

will use it to identify the type of each CPU in TYPE113.

Thanks to John Burg, IBM, USA.

Thanks to Graham Harris, Royal Bank of Scotland, SCOTLAND.
Change 28.074 Support for CA-Dispatch Audit User SMF record creates:

EXCADISP dddddd dataset description

IMACCADS CADISP CADISPCH CA Dispatch User SMF Record.

TYPECADS Note this is NOT the modified type 6 that can be created

TYPSCADS with the IMACCADI optional member enabled.

VMACCADS

VMXGINIT

Apr 14, 2010

Thanks to Glenn Bowman, Wakefern, USA.
Change 28.073 In new DB2 V9.1 data records, QWHSISEQ in SMF 100 Subtype

VMACDB2 0 and 1 records no longer matches QWHSISEQ in Subtype 4

Apr 8, 2010 records, causing all of the QW0225xx variables to have a

missing value in PDB.DB2STATS when DB2STAT4 is merged.

The use of QWHSISEQ was previously "safe", but must have

been a fortunate accident, since IBM documentation for

ISEQ implies it is a sequence number for the IFCID, and

not, as I had assumed, the interval's sequence number.

This change creates TEMPISEQ dataset with QWHSISEQ taken

from the DB2STAT0/DB2STAT1/DB2STATB merge, renames the

ENDTIME to QWHSSTCK, so that TEMPISEQ is then interleaved

with DB2STAT4 to store that "interval" QWHSISEQ, which

is then used in the original merge using _BDB2STS.

(Since the problem has only occurred with DB2STAT4 and

not with the T102S225 that was created in DB2 V8., that

logic was not revised).

Thanks to Fabio Massimo Ottaviani, DTS Italia, ITALY.
Change 28.072 Dataset TYPE42X4 (Above the Bar LRU Statistics) variables

VMAC42 SMFA2JQG-SMFA2JQN (Buffer Size Goal and Buffer Sizes) are

Apr 8, 2010 now correctly INPUT as &PIB.8., instead of &PIB.4. This

caused variables SMFJQO01-SMFJQO16, SMFA2JSA-SMFA2JSP to

also be mis-aligned and wrong, and the IF test for 864 is

corrected to test for GE 896 due to the misalignment.

-In addition, new variables SMF42JP6 and SMFA2JP6 (Write

Requests) are INPUT and kept in datasets TYPE42X2 (Below)

and TYPE42X4 (Above) as they too had been overlooked.

-Note that MXG variable names SMFA2xxx correspond to IBM

field names of SMF2Axxx.

Thanks to Ambat Ravi Nair, CitiGroup, SINGAPORE.

Change 28.071 PDB.STEPS could contain duplicate observations, and the

BUILD005 resources in those duplicates were summed into PDB.JOBS,

BUIL3005 if two steps had the same TERMTIME (because the first was

ANAL30DD a FLUSHED step). Change 18.344 corrected this error in

Apr 7, 2010 TYPS30, by adding INITTIME to the _BTY30U4 BY list, but

that change was also needed in BUILD001/BUILD001, which

have their own BY list in the NODUP step.
All other programs that SORT the TYPE30_4 data were now

examined; ANAL30DD's BY list was updated, but it was the

only one that sorts all variables; these other programs

currently do NOT protect for duplicate SMF records

ANAL30 ANALDDCN ANALDSET ANALJOBE ANALMULT ANALVTS

TAPEVENT UTILRMFI

because they do not keep all of the variables that are

required for duplicate removal, and adding that logic

would be very expensive: unneeded variables and an extra

PROC SORT would be required and the report program would

have to be restructured. Since the TYPS30 program WILL

remove ANY duplicates, the solution would be to use it to

create the TYPE30xx datasets first, and then those report

programs will not need revisions.

Thanks to Michael Oujesky, Bank of America, USA.

Thanks to Betty Wong, Bank of America, USA.

Change 28.070 SAS Version 9.2 TS2M2 may have changed DSNAMEs/MEMBERs in

MXGSAS92 their //CONFIG DD. As always, you MUST look at the SAS

Apr 2, 2010 JCL procedure example that was created by your SAS

Installer to know what DSNAME/MEMBERs were created; those

DDs must be the first in the //CONFIG DD, then the MXG

CONFIG member must be the last "real" DD, followed by the

// DD DSN=&CONFIG as the final DD in the //CONFIG concat.

These two variants are listed in the MXGSAS92 example.

//CONFIG DD DISP=SHR,DSN=&SASHLQ..V92DYJJJ.CNTL(BATCH)

// DD DISP=SHR,DSN=&MXGHLQ..MXG.SOURCLIB(CONFIGV9)

// DD DISP=SHR,DSN=&CONFIG

//CONFIG DD DISP=SHR,DSN=&SASHLQ.M92M2.CONFIG(BATCH)

// DD DISP=SHR,DSN=&SASHLQ.M92M2.CONFIG(COMMON)

// DD DISP=SHR,DSN=&SASHLQ.M92M2.CONFIG(&XX.&YY.)

// DD DISP=SHR,DSN=&SASHLQ.M92M2.CONFIG(SITE)

// DD DISP=SHR,DSN=&MXGHLQ..MXG.SOURCLIB(CONFIGV9)

// DD DISP=SHR,DSN=&CONFIG

Thanks to Ernie Amador, UC Davis Health System, USA.

Change 28.069 Two instances of -60 were changed to -56 for the SMF 112,

EXIT112 but the exit to decompress SMF 112s does not work and can

Apr 1, 2010 not be used. IBM does not provide a utility program that

May 17, 2010 will decompress the SMF 112s (DFH$MOLS only reads 110s),

so I have no way to correct and validate the MXG Exit.

DO NOT USE EXIT112.

Change 28.068 Change 27.111 added support for multiple CA-1/TMS catalog

TYPETMS5 inputs, but inadvertently changed the length of VOLSER to

Apr 1, 2010 $20, whereas it should have been $6. There was no error

in the contents of variable VOLSER, but if you tried to

combine new and old datasets, you receive a SAS WARNING

of the dissimilar lengths. This change restores VOLSER

to the original $6 length.

Thanks to DJ Chen, Florida Department of Corrections, USA.

Change 28.067 The final example invocation of %VMXGRMFI(....) failed

RMFINTRV because there was a comma prior to the close-paren. All

Apr 1, 2010 %MACRO invocations have commas separating arguments,

but there can not be a comma after the last argument.

Thanks to Carolyn E. Saul, West Virginia Office of Technology, USA.
Change 28.066 Support for IMS Version 11 (INCOMPATIBLE), support for

ASMIMSL6 55x/56x Statistics Log Records, validation of 45x log

TYPEIMS7 records, and TYPSIMS7 removes duplicate log records.

TYPSIMS7 -Insertion of 16-byte LINTUTKN field in 08x log record

VMACIMS in IMS 11 makes this change required to eliminate error

VMACIMSA that YYYY has invalid value, in VMACIMS and VMACIMSA.

VMXGINIT -ASMIMSL6 is updated to pass the 55x and 56x log records.

Apr 4, 2010 -45x Statistics records have been validated with data,

except for IMS4513 which had zero observations.

-55x and 56x records are now supported and validated; the

"56" names contain "55x" and "56x" records:

DDDDDD DATASET CREATED FROM SUB-SUBTYPE

IMS560 IMS5600 00x-08x,10x,12x-14x,37x-38x

IMS569 IMS5609 09x

IMS56B IMS5611 11x,16x

IMS56F IMS5615 15x

IMS56G IMS56FA FAx

-The 45x and 55/56x datasets are left in //WORK so you can

decide to copy them, or not.

-TYPSIMS7 now uses PROC SORT NODUP to remove duplicates,

and outputs ALL datasets to the //IMSTRAN DD name.

This required creation of variable IMSRECCH $CHAR8. to

contain the IMS Logical Sequence Number as character to

use in NODUP sorts. IMSRECNO was input with PIB8., but

it failed in NODUP sorts, because values were truncated

if the first byte was non-zero. IBM stores a value of

'F1'x in the 1st byte for the 1st merged file, a 'F2'x

for the 2nd merged file, etc., but when a numeric field

is INPUT with PIB8, if the field contains a non-zero

first byte, the result is truncated because SAS needs

one byte for exponent, leaving only 7 bytes for

mantissa, which caused duplicate values for IMSRECNO,

which caused the NODUP to fail to recognize true

duplicates. Now, the 8-byte Character variable

IMSRECCH is used in all BY-lists to successfully remove

duplicates and the numeric IMSRECNO is now input from

only the last seven bytes, with PIB7.

-35x record has undocumented bits in QLNQFLGS/ENQFLAG.

IMS 11 DSECT only document '10'x,'02'x,' 01'x bits,

but data contains '80'x,'40'x,'08'x,and '04'x bits on.

QLNQFLGS values '0C'x,'4C'x,'8C'x,'8E'x, and '9C'x bits.

-01x record now conditionally inputs Extended Segment,

eliminating missing value messages.

Thanks to Lars-Olof Thellenberg, Handelsbanken, SWEDEN.

Thanks to Lars Fleischer, SMT Data A/S, DENMARK.
Change 28.065 Support for BMC CICS CMRDETL C660 for CICS/TS 4.1 adds

VMACMVCI these new variables COMPATIBLY:

Mar 30, 2010 T6E66XCT T6EATMSN T6EBFDGC T6EBFTC T6EECEVC T6EECFOC

T6EECSGE T6EEICTC T6EIPA T6EJSTWC T6EJSTWT T6EMLCTC

T6EMLCTT T6EMLTDL T6EMLXTC T6EMQASC T6EMQAST T6EOIPA

T6EPIPLN T6ET8PTC T6ET8PTT T6ETIATC T6ETITC T6ETTDLC

T6ETTDLT T6EURIMN T6EWPBNM T6EWSATC T6EWSCBC T6EWSCGC

T6EWSEPC T6EWSFCC T6EWSFTC T6EWSOPN T6EWSQBL T6EWSRBL

T6EWSSFC T6EWSVCN TESTC660 UDAT2
Change 28.064 A semicolon was missing at the end of the statement

JCLIMSL6 %LET MACKEEP= MACRO _IMSVERS 10 % ;

Mar 26, 2010 causing the job to stop after MXG initialization.

Thanks to Urs Kugler, Zurich Insurance Company, SWITZERLAND

Thanks to Brian Sanger, Zurich Insurance Company, SWITZERLAND
Change 28.063 ASUM70LP and ASUMCELP had IFLACTTM,PCTIFLBY missing if

VMXG70PR the IFL was Dedicated, LCPUDED='Y' because ORIGWAIT was

Mar 25, 2010 subtracted from LCPUPDTM even when ORIGWAIT was missing.

Now, MAX(ORIGWAIT,0) is subtracted.

Thanks to Chuck Hopf, Independent Consultant, USA.
Change 28.062 NetSPY percentage calculations use TOTRSPNO or NETSRPNO

VMACNSPY in the denominator, based on the '.1.....'B XDOMAIN value

Mar 25, 2010 for Host-Only or Not, respectively. New TARGRESP variable

is now set by that XDOMAIN value to make it clearer which

denominator was used for the TnRSPPC calculations.

Thanks to Charles Savikas, DFS State of Florida, USA.

Change 28.061 MXG changes the TMS variable BLKCNT to a missing value,

VMACTMS5 when it detects an invalid BLKCNT value. Previously, the

Mar 25, 2010 BLKCNT value was output as 4,294,967,xxx decimal, because

the value in the TMS record was 'FFFFFFFC'x, which MXG

INPUT with PIB4. INFORMAT, because Block Count must be a

positive value, and I feel leaving that large value means

it can't be easily overlooked as an error. For a field

that can be positive or negative, then the first bit is

a sign bit, and the above, when INPUT with IB instead PIB

is a decimal -4, still a clearly wrong negative value.

The TMS Report prints a +4 for BLKCNT for that value!

And, from TMS Support, they confirm that:

- There is no logic in TMS-Reporting, but if the

high-orderbit is on, they interpret the negative

value as a positive number in their print routine.

- The record seems to be wrong, they had some few

similar cases in the past

In fairness to TMS, I don't think these large BLKCNT

values are their fault; I think they just pick up that

counter and output it. Occasionally, fields with values

'FFFF...'X have shown up in SMF I/O fields like EXCP

BLOCK, SIO, etc. whose counters are in the address space.

They result from the subtraction of a counter with a

larger value from a counter with a smaller value, and

thus ultimately are the result of a programming error

deep in whatever system-level code used the wrong

internal counters. Some of these errors have been

tracked down, and fixed, but it can take significant

effort, multiple vendors, and even SLIP traps.
And many of these "bad" values can be traced back to an

ABEND in the address space that overwrote one or both of

the subtraction input counters!

-So I've changed the input for BLKCNT so the value is set

to a missing value instead of that large value when the

first byte is an 'FF'x. This way, you can use

PROC MEANS N NMISS DATA=TMS.DSNBRECD;

to count the number of DSNs with invalid BLKCNT values.

Thanks to Thomas Heitlinger, FIDUCIA IT AG, GERMANY.

Thanks to Sieghart Seith, FIDUCIA IT AG, GERMANY.

Change 28.060 Change 27.289 added CPUZIPTM for SYNCSORT that was added

VMACSYNC in an existing reserved area, but SYNCSORT 1.2 did not

Mar 24, 2010 have that expected reserved area, causing MXG to ERROR:

INPUT EXCEEDED RECORD LENGTH. CPUZIPTM is now INPUT

conditionally when the reserved area exists. Note that

the current SYNCSORT version is 1.3; they renumbered.

Thanks to David Bixler, FISERV, USA.
Change 28.059 -RMF III variable ASIASSTA (ADDITIONAL*SRB*TIME) is now

VMACRMFV correctly divided by 1000 in its INFORMAT.

Mar 24, 2010

Thanks to Stephen Hoar, Lloyds TSB, ENGLAND.

Change 28.058 AS400 Version 5.4.0 creates invalid records that do not

VMACQACS contain the "Century" value and a 2-byte POOL Number that

Mar 24, 2010 caused MXG to be misaligned, and all values were wrong!

The missing Century value is now forced for 5.4.0 records

so that dates and values are correct in QAPMPOLB dataset.

Thanks to Karen Florup, Bank of America, USA.

Change 28.057 MXG 28.01, SAS V8.2 ONLY: ERROR: MACRO KEYWORD ABORT IS

VMXGINIT NOT YET IMPLEMENTED. Change 28.023 added %ABORT statement

Mar 22, 2010 for obscure NOWORKINIT detection, but we no longer QA MXG

under SAS V8.2 so the omission was missed. This change

replaced %ABORT with a DATA STEP for sites still stuck in

that ancient and archaic version of SAS.

See Change 28.079A, which removed NOWORKINIT detection.

Note: This MACRO KEYWORD error also caused FORMATS to

error with ' 22 ' under the OTHER= argument, but the

VMXGINIT correction eliminated that spurious error.

Note: As a reminder, MXG does not fully support V8;

there are other errors that require SAS V9, but this

is not one of them.

Thanks to Teuvo Virsu, Tieto, FINLAND.

Change 28.056 Format MG099TC for variable S99TCOD had spelling errors:

FORMATS Action Code 3560: Change REV to REC.

Mar 22, 2010 Action Code 8975: Change NO to NA.

Thanks to Dick Arnold, Commerce Bank, USA.

Change 28.055 Using PDB=GTF to read DB2 GTF data did not always work.

ANALDB2R Multiple includes of VMACDB2 and VMAC102 could occur,

READDB2 the logic of which records were to be read was not always