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

Mar 22, 2010 correct, an unneeded data step was eliminated, and the

old-style macros are cleared with %CLEARDB2 so that you

can execute ANALDB2R multiple times (which also protects

PDB=SMF and PDB=PDB).

Apr 17: See Change 28.083. CLEARDB2 REMOVED.

Thanks to Tony Curry, BMC, USA.
Change 28.054 Variables TSQIOSTM and TSQIOWTM in CICSRDQU dataset from

VMAC110 Resource Class SMF 110 SUBTYPE=1 MNSEGCL=5 records were

Mar 20, 2010 wrong, and the count portion of those two "clocks" is now

input into new variables TSQIOSCN and TSQIOWCN.

Thanks to Danny Sun, IBM Global Services, AUSTRALIA.

Thanks to Tony Delmenico, IBM Global Services, AUSTRALIA.

Change 28.053 Executing TYPEQACS on ASCII caused OPTION JFCB UNKNOWN.

VMXGDSNL The VMXGDSNL macro is revised so that

Mar 19, 2010 - It works without referencing a JFCB

- Works on ASCII to find the part of the dataset between

the . and the / or the \.

- Continues to function as before to capture the

penultimate token of a GDG DSNAME.

Thanks to Paul Naddeo, FISERV, USA.

Change 28.052 Cosmetic. Fourteen misspellings of CONTENTION corrected.

VMAC42

Mar 16, 2010

Thanks to Miguel A. Fernandez, CitiGroup, USA.

Change 28.051 DB2 APAR PK62161 adds four important SQL counters that

VMACDB2 are output in DB2ACCT, DB2ACCTP, and DB2STATS:

Mar 16, 2010 QXRWSFET='ROWS*FETCHED'

QXRWSINS='ROWS*INSERTED'

QXRWSUPD='ROWS*UPDATED'

QXRWSDEL='ROWS*DELETED'

The APAR adds the fields to both DB2 V8 and DB2 V9.

Thanks to Terry L. Berman, DST Systems, USA.

Change 28.050 Documentation. If you want to reset the value of the

VMXGINIT OPTIONS USER=xxx;, then you MUST reinvoke VMXGINIT after

Mar 16, 2010 setting your desired LIBNAME:

OPTIONS USER=MYPDB;

%VMXGINIT;

%INCLUDE SOURCLIB(TYPEDB2,ASUMDB2A);

Thanks to Lars Fleischer, SMT Data, SWEDEN.
Change 28.049 -If you APPEND PDB datasets, you may receive warnings that

FIXTRNCD the old dataset did not have TRANSCODE attribute set.

Mar 16, 2010 These warnings are only cosmetic, and will go away when

Apr 29, 2010 you reset the MTD or WTD dataset with only the new MXG.

But, those warnings can be eliminated with the attached

FIXTRNCD program which adds the TRANSCODE=NO attribute to

all $HEX-formatted CHAR variables in the OLD MDT/WTD.

-MXG 28.01/28.02. Original FIXTRNCD program did not work.

Revised and tested Apr 29, 2010.

Thanks to Jan Hess, USAirways, USA.

Thanks to Doug Medland, IBM Global Services, USA.
Change 28.048 RMFV CPUG3 record has +192 bytes in z/OS 1.11.

VMACRMFV Temporary skip realigns data.

Mar 15, 2010

Thanks to Miguel Barrios, SSA, USA.

====== Changes thru 28.047 were in MXG 28.01 dated Mar 9, 2010========
Change Numbers with an asterisk are still OPEN, their text may change,

and the listed members might not have been updated yet in this release.

Contact [e-mail] for current status of those changes.
Change 28.047 User defined CICS segment supported. Names similar to

IMACICUJ the expected names for IMACICDL caused this particular

UTILEXCL user segment to not be recognized, causing ERRORs when

Mar 9, 2010 SMF data was processed.

Thanks to Paul Baquet, Duke University, USA.
Change 28.046 Documentation. The summarization INTERVAL= request must

ASUM70PR be GREATER THAN OR EQUAL TO the RMF interval duration.

Mar 9, 2010 The default ASUM70PR has INTERVAL=QTRHOUR, but if that is

used with data that was created HOURLY, the output

ASUM70PR dataset(s) can have PCTCPUBY,PCTLnBY, etc.

percentages greater than 100, and there's nothing I can

do to correct those values with the incorrect INTERVAL=.
Change 28.045 The TIMEBILD table was arbitrarily limited to 99 entries;

TIMEBILD keeping ancient systems in the table caused an error when

Mar 8, 2010 the limit was exceeded; the limit is increased to 999.

Thanks to Betty Wong, Bank of America, USA.

Thanks to Michael Oujesky, Bank of America, USA.
Change 28.044 WPS failed with a compiler error in VGETOBS, reported as

VGETOBS UNRESOLVED MACRO %TRIM, but the error, documented in WPS

Mar 6, 2010 item 8385, was not in %TRIM, but was in the parsing of a

Mar 8, 2010 %VGETOBS value that had a plus sign (e.g. 1234e+56). WPS

maintenance 14690 corrected the compiler error, but now

we understand the code syntax that exposes the problem,

by adding %QUOTE() function around the %VGETOBS text, the

exposure is circumvented, without installing WPS 14690.

(First attempt using %STR() around %VGETOBS failed;

%STR is evaluated at compile time, %QUOTE is evaluated

at execute time, which is required here. Two other

%STR were changed to %QUOTE just for consistency.)

(Second attempt did not correctly parse a period that

was returned when the SAS Data Library was in XPORT

format.)

(Third attempt used %INDEX to solve the problem.)

Thanks to Atle Mjelde, ErgoGroup, NORWAY.
Change 28.043 zTPF has major revisions in Performance Data, with many

EXTPFCC old variables removed and new record types; while the new

EXTPFCF support is in new members TYPEZTPF/TYPSZTPF/VMACZTPF and

EXTPFCL not an updated TYPETPF, old DATASET and VARIABLE names

EXTPFCW that exist are unchanged, and TPF is still the prefix for

EXTPFCY the new dataset names.

EXTPFCZ Status

EXTPFGL TPFID DSECT DATA RECORD DATA IN DATA RECORD

EXTPFHP CC NO YES NO

EXTPFMT CF YES YES NO

EXTPFMT CL YES YES NO

EXTPFSF CW COMPLETED

EXTPFSI CY NO YES NO

EXTPFTH CZ NO YES NO

EXTPFUC GL YES YES NO

EXTPFVC HP YES YES NO

EXTPFVF MT COMPLETED

TYPEZTPF MU NO NO NO

VMACZTPF SF NO YES YES

VMXGZTPF SI COMPLETED

Mar 5, 2010 TH NO YES NO

Mar 30, 2010 UC YES YES NO

Apr 5, 2010 VC NO NO NO

VF NO YES YES

Thanks to Bob Wilcox, HP, USA.
Change 28.042 New Sentry VM 3.1.4.3 adds new objects and metrics:

EXNTAPOW dddddd Dataset Name Object

EXNTEVFS

EXNTEVFW NTAPOW APOOLWAS APP_POOL_WAS

EXNTHSRQ NTEVFS EVTRACWS EVENT TRACING FOR WINDOWS SESS

EXNTHSUG NTEVFW EVTRACWI EVENT TRACING FOR WINDOWS

EXNTIPDP NTHSRQ HTTPSRQU HTTP SERVICE REQUEST QUEUES

EXNTIPDR NTHSUG HTTPSUGR HTTP SERVICE URL GROUPS

EXNTIPGL NTIPDP IPSECDOS IPSEC DOS PROTECTION

EXNTPPAC NTIPDR IPSECDRI IPSEC DRIVER

EXNTPPIC NTIPGL IPHTTPSG IPHTTPS GLOBAL

EXNTPRIN NTPPAC PPNETACC PER PROCESSOR NETWORK ACTIVITY

EXNTSYNC NTPPIC PPNETINC PER PROCESSOR NETWORK INTERFAC

EXNTTECL NTPRIN PROCINFO PROCESSOR INFORMATION

EXNTTECL NTSYNC SYNCHRON SYNCHRONIZATION

EXNTTESE NTTECL TERECLIE TEREDO CLIENT

EXNTVWGA NTTECL TERERELY TEREDO RELAY

EXNTVWHA NTTESE TERESERV TEREDO SERVER

EXNTWFP NTVWGA VMGUESTA VMWARE.GUEST.AGGREGATE

EXNTWFPV6 NTVWHA VMHOSTAG VMWARE.HOST.AGGREGATE

EXNTWPFV4 NTWFP WFP WFP

EXNTWSMAN NTWFPV6 WFPTV6 WFPV6

IMACNTSM NTWPFV4 WFPV4 WFPV4

VMACNTSM NTWSMAN WSMANQUS WSMAN QUOTA STATISTICS

Mar 7, 2010
Change 28.041 Do NOT use ASMTAPEE ML-45/46; it caused CPU spikes in the

ASMTAPEE in the MXGTMNT address space (minutes vs fractions of a

Mar 9, 2010 second) that are now corrected by this new ML-47 release.

ML-45 was in MXG 27.10, ML-46 was in MXG 27.11/MXG 27.27.

Just in case, member ASMTAP44 contains ML-44.
Change 28.040 This original change text was wrong and replaced in 2011.

VMACTMS5 The new TMS Extended Format TMC did NOT change ANY size

Mar 5, 2010 of the TMC 340 byte records. The new Extended Format is

Dec 7, 2011 COMPLETELY COMPATIBLE WITH ALL VERSIONS OF MXG SOFTWARE.

See Change 29.274.
Change 28.039 -Dataset TYPE74CA variable R7451RID, the Rank ID, is input

VMAC74 from two bytes, but that produced values in the thousands

Mar 5, 2010 while the values in R748ARID and R748RRID in TYPE748A and

TYPE748R have values up to only 15. The observed values

in the first byte of R7451RID are between 1 and 15, and

and the second byte is 1 or 2, so (guessing), R7451RID is

now input from only the first byte and new R7451RI2 has

the value in the second byte, perhaps the Rank Group.

IBM RMF support observed the same values, but they only

get the two bytes from the interface.

-The Raid Rank segment has fields overlaid that populated

multiple variables, but variable R7451FLG is now used to

set missing values for the variables that don't exist.

This table identifies which R7451xxx variables have value

for each value of R7451FLG, which should be used to group

these three different sets of metrics in TYPE74CA.

R7451FLG

0=No Information, 1=Raid Rank Data, 2=Extent Pool Data

0 1 2

RID XID

HDD HDD XTY

RTY XFL

HSS

RRQ RRQ PRO

WRQ WRQ PWO

SR SR PBR

SW SW PBW

RRT RRT PRT

WRT WRT PWT

-Documentation. The three type 74 subtype 5 LSA Segments

(LO,RO,VO) added in OS/390 Release 2.10 in Change 18.134

were removed by IBM in z/OS 1.1, so these variables will

always be a missing value:

R745DCIR R745LFRE R745LKBF R745LKBR R745RBYF R745RBYS

R745RRID R745VBYW R745VFLG R745VNTR R745VNUM R745VSER

Thanks to Deb Soricelli, CIGNA, USA.

Change 28.038 SMF 120 SUBTYPE 9 caused INPUT STATEMENT EXCEEDED RECORD

VMAC120 because MXG thought variable SM1209ES was 128 bytes long,

Mar 3, 2010 when it should have been INPUT as 64 bytes long.

Thanks to Clayton Buck, UniGroup, USA.

Change 28.037 PDB.SMFINTRV will have EXCP/IOTM counts for FLUSHED steps

BUILD005 that have ZERO elapsed time (for example, steps bypassed

BUIL3005 execution due to JCL Condition Code Tests) if this causes

BUIL3005 the flushed step and the NEXT step to have identical time

Mar 3, 2010 in INITTIME and INTBTIME (step init, interval begin, to

.01 second resolution). Those NEXT step EXCPs/IOTMs were

incorrectly output in that FLUSHED step observation, and

the NEXT step observation had zero EXCP/IOTM counts.

The PDB.STEPS and PDB.JOBS datasets were correct, because

they don't use interval data.

And, in PDB.SMFINTRV, since those EXCPs were valid, but

just in the wrong step, both the JOB and INTERVAL totals

were always just fine.

-Adding INTETIME, the interval end time, in the BY lists

in SORTS and MERGES and KEEP= and in FIRST. and LAST. in

the MULTIDD algorithm corrects the error; it's now clear

they were always required for uniqueness.

Thanks to Rachel Holt, Fidelity Systems, USA.

Change 28.036 -TYPE1032 from SMF 103 subtype 2 did not deaccumulate

VMAC103 correctly if PORTNR was not unique; variable JOB was

Mar 2, 2010 added to the BY list for uniqueness to correct.

-"SINCE*STARTUP" removed from label of variable TIMEOUTS,

as it is now the interval value, after deaccumulation.

Thanks to Matthew Chappell, Queensland Dept of Transport, AUSTRALIA.

Change 28.035 Cosmetic, a numeric to character conversion note was

VMXG2DTE eliminated.

Feb 28, 2010
Change 28.034 The references to %TRIM() function are not required, and

VGETOBS their removal may avoid UNRESOLVED MACRO TRIM errors.

Feb 28, 2010
Change 28.033 Incorrect MXG test for SEGLEN=220 for XAMSYS records in

VMACXAM the SUBSUM segment caused alignment ERRORS on the log.

Feb 28, 2010 Correct tests are for 224 and 228.

Thanks to Frank Bereznay, IBM Global Services, USA.

Thanks to Raff Rushton, IBM Global Services, USA.
Change 28.032 -IBM/CANDLE/OMEGAMON optional CMRDATA segment (IMACICMR)

IMACICMR was increased to 256 bytes in CICS/TS 3.2 (SMFPSRVR=65),

UTILEXCL and MXG tests that CICS version in IMACICMR, but records

Feb 27, 2010 from CICS/TS 3.2 with the old 200-byte length are still

created (presumably, the OMEGAMON exit for that segment

was not reassembled with CICS/TS 3.2 macros). While the

segment length of an optional CICS segment is not in the

CICSTRAN SMF record, if the MR segment happens to be the

LAST segment, this change invokes the old short-record

INPUT when less than 256 bytes are left and it's 3.2.

If the CMRDATA segment is not the last segment, the short

segment ultimately (hopefully) causes some sort of ERROR

(in this case, INVALID TASKNR DETECTED with a VERY large

value, due to the misalignment of the short record).

-While I can't tell segment length when creating CICSTRAN,

UTILEXCL will now detect the short CMRDATA segment under

CICS/TS 3.2 and print error messages on its log.

Thanks to Atle Mjelde, ERGO Group, NORWAY.

Change 28.031 z/OS 1.11 GA added variables to SMF 30 and SMF 71, but I

VMAC30 had not re-examined the final SMF manual. Now added:

VMAC71 Dataset TYPE71:

Feb 25, 2010 SMF711RN='FIRST*REFERENCE*FAULTS'

SMF71FBN='FRAMES*BACKED*DURING*GETMAINS'

SMF71FFN='FRAMES*REQUESTED*TO BE FIXED*BELOW 2GB'

SMF71FRN='FIX*REQUESTS*BELOW*2GB'

SMF71GRN='GETMAIN*REQUESTS*ISSUED'

SMF71NRN='NON-FIRST*REFERENCE*FAULTS'

Datasets TYPE30_4,TYPE30_5,SMFINTRV,TYPE30_6:

SMF30HSH='HWM*USABLE BYTES*IN 64-BIT*SHARED'

SMF30HSO='BYTES IN*64-BIT*SHARED*STORAGE'

SMF30HVA='HWM*AUX*SLOTS*BACK*64-BIT'

SMF30HVH='HWM*USABLE BYTES*IN 64-BIT*OBTAINED'

SMF30HVO='BYTES IN*64-BIT*STORAGE*OBTAINED'

SMF30HVR='HWM*REAL*FRAMES*BACK*64-BIT'

Thanks to Don Deese, CPExpert, Computer Management Sciences, USA.
Change 28.030 Support for IMS Log 55x Statistics records, may not

VMACIMS have been tested with actual records.

Feb 24, 2010
Change 28.029 RMM datetime vars have always been wrong time zone. MXG

VMACEDGR assumed that the existence of a GMTOFF value in a Header

Feb 24, 2010 record extracted by EDGHSKP meant that the values in the

Mar 5, 2010 records were on GMT, so MXG added the GMTOFF, intending

Mar 8, 2010 to convert to local, but that incorrectly converted times

back to GMT time zone values. IBM rmm support confirms

that, since z/OS 1.8, extract records ALMOST ALWAYS have

the local time zone, even if the new Common Time UTC(YES)

option is enabled. However, if the RHTZNAME field in the

header record is non-blank, then the user specified the

TZ operand of the RPTEXT command, and times IN the record

were created on that time zone; in this case, MXG does

use the GMTOFF to convert record times to local time zone

and MXG prints a message when this is detected.

-The MXG support for all possible data formats added in

Change yy.xxx requires a Header Record to define the date

formats (Julian, American, European, etc.), but if there

was no Header record, all of the date/times were missing.

This change prints an error message if no "H" Header was

found as the first record in the file, and sets the date

format to the Julian (arbitrary, but most common), with

no guarantee that valid times will be created.

Thanks to Jorge Fong, NYC Information Technology, USA.

Thanks to Phillip Moore, UHC, USA.

Thanks to Robert Chavez, Florida Power and Light, USA.
Change 28.028 BMC IMF INPUT STATEMENT EXCEEDED RECORD LENGTH when a

VMACCIMS shorter than expected TRNEXTEN segment of only 16 bytes

Feb 24, 2010 was found; MXG expected 52 bytes. What's sad is that

I only input that segment, and didn't keep it, so it is

not even important, but now, the length remaining is

validated prior to the INPUT of that segment. BMC support

has acknowledge the error: "MVIMS should clear TRNEXTEN

and TRNEXTLN when it strips off the extension. A PTF will

be created to correct the problem.

Thanks to Lorena Ortenzi, UniCredit Global Info Services, ITALY.

Thanks to Paolo Uguccioni, UniCredit Global Info Services, ITALY.
Change 28.027 Do not use the EXIT112 ASM program to decompress CICS SMF

EXIT112 110 records: instead, use the EXITCICS ASM program to

Feb 23, 2010 create the CICSIFUE infile exit to process CICS/TS 3.2

VMAC110 compressed SMF records. As noted in the original change

text, EXIT112 was supposed to handle both 110 and 112

compressed records, and it was tested in 2007, but it now

fails with either 110 or 112 compressed records.

I thought you could use the IBM DFH$MOLS program to

decompress the 112 Omegamon records, but you can't.

-MXG VMAC110 was updated to print a message when the

internal SAS decompression code was executed because the

CICSIFUE exit was not installed.

Change 28.026 Only for consistency, SUMBY= argument changed to STARTIME

TRND71 in place of the now-archaic DATETIME symbol.

Feb 23, 2010
Change 28.025 New Crypto Type CEX3C PRCAPMCT=9 caused MXG to CPU LOOP

FORMATS on the DM=5 RC=10 PRCAPM segment, with no clue unless you

VMACVMXA enabled DEBUG=2 to see the last record before the loop.

Feb 22, 2010 -MXG now protects any unknown PRCAPMCT value with MXGERROR

messages for the first 3 records, and no CPU loop!

-PRCAPMCT values 3,5,7,9 have one structure, and 4,6,8

have a second structure (and 4 has 5 engines, while 6,8

have only one engine). All seven values are now decoded.

-Variable PRCAPMCT is now formatted with new MGVXACX

to map the value to the Crypto Type processor:

3='3:PCICC'

4='4:PCICA'

5='5:PCIXCC'

6='6:CEX2A'

7='7:CEX2C'

8='8:CEX3A'

9='9:CEX3C'

Thanks to Jim Kovarik, AEGON USA, USA.

Change 28.024 Variable BYTESIN is now MGBYTES formatted, rather than

VMACAIX MGBYTRT formatted, as it contains bytes, not a rate.

Feb 18, 2010

Thanks to Glenn Bowman, Wakefern, USA.

Change 28.023 -New MXGERROR and USER ABEND 990 if NOWORKINIT is enabled.

VMXGINIT Unlikely/obscure, but if //WORK is a Permanent DSNAME and

Feb 18, 2010 has DISP=OLD, that NOWORKINIT option skips initialization

of the (normally temporary) //WORK library, so whatever

temporary stuff (macros, catalogs, tables, datasets) was

left from the last SAS step will be used for this step.

While there may be some applications that can use this

"feature", MXG is NOT one of them. When an ITRM site

with that environment upgraded to 27.27, the SAS Compiler

initially had UNRESOLVED MACRO VARIABLE TEMP1ENG errors

in the first execution of VMXGSUM in BUILDPDB, but a job

to enable diagnostics had a typo that caused an error,

but when fixed and diagnostics were enabled, yet another

compiler error was encountered, and three subsequent runs

all failed with different errors. It was only when one

error reported CORRUPTED MACROs that we spotted the reuse

of the //WORK DD in the JCL, and only because diagnostic

option VERBOSE had been turned on that we saw the CONFIG

in use had specified the NOWORKINIT option.
That original unresolved macro error was false; there was

no error in MXG code, but was the result of a conflict

between the old, compiled, %VMXGSUM macro in //WORK that

was compiled from the old MXG, with the invocation in the

new MXG that expected the new definition. Changes were

made to VMXGSUM between the two versions.

This change causes a USER ABEND 990 and MXGERROR messages

if the NOWORKINIT is enabled at MXG Initialization.

-All VMXGxxxx members that define volatile %MACROs print a

single MXGNOTE: VMXGxxxx LAST UPDATED...., when the macro

is compiled; this will avoid a rerun just to determine if

an old macro is in use when there are errors.

-But, see Change 28.079A
Change 28.022 -ML-47 of ASMTAPEE/MXGTMNT protects for diagnostic ABEND.

ASMTAPEE If diagnostic trap IEAINITREGSTASK is enabled, it causes

Feb 13, 2010 a recoverable ABEND 0E0-28 for each XMEM Cross-Memory

call, with a loss of data fields in some MXGTMNT records,

and the unwanted overhead of triggering that trap.

Diagnostic traps like this are enabled, usually only on

test systems, but especially on new z/OS system tests,

to expose existing or potential coding errors. The fact

that this trap caused an abend doesn't necessarily mean

there is an error.

The idea behind this one is that if a program does not

properly set a register, then any use of that register

could potentially lead to a storage overlay. Storage

overlays are some of the most difficult problems to

diagnose because you don't get an abend when the storage

is overlaid: the abend only comes later when subsequent

code attempts to use that storage and comes across that

now-corrupted area. The abend could happen immediately,

or hours later.
This trap places x'FF' in all registers, including access

registers, at task initialization, with the expectation

that the task will clear all access registers before it

goes into AR cross memory mode. The 'FF'x will cause the

code that is using the register without clearing it to

immediately abend, making this storage overlay error much

easier to find. There are several IBM APARs for various

products that had identical S0E0 ABENDS.

Newer sections of MXGTMNT do clear all ARs, but the older

code, pre ML-29, only cleared the ARs that were actually

used, leaving the unused ARs with the x'FF' value.
What is the exposure for MXGTMNT? There isn't any. This

trap exposes, at most, a bad programming practice, maybe!

The trap ABEND is caused by the access registers being

set to x'FF's. Access registers are used for access via

cross memory, and the trap sets them when the task is

first created and entered.

Since MXGTMNT is the first task there is no chance that a

previous task left any unwanted data in the access

registers. But even though there is no exposure, we have

no choice but to add code to clear all ARs; otherwise

anyone who runs MXGTMNT with that diagnostic trap enabled

will encounter these abends.

See Change 28.041 text for ML-47 status.

Thanks to Ginny Nugent, SAS Institute, USA.

Thanks to Ed Webb, SAS Institute, USA

Thanks to my "asmguy", who provided the explanations and the update.

Change 28.021 The zPCR program works fine for simple configurations,

ANALZPCR but with missing data, or multiple, complex, sysplexes

Feb 13, 2010 the ANALZPCR program could fail, the MXG-created .zpcr

Feb 16, 2010 file load could fail, or a model that would load without

Feb 25, 2010 an error could have SYSTEMs in the wrong SYSPLEX.

Feb 28, 2010 -The SYSPLEX value in PDB.TYPE70PR is NOT the SYSPLEX of

Mar 4, 2010 the LPARNAME, but, rather, is the SYSPLEX on which that

Mar 5, 2010 SMF record was written, a fact overlooked in ANALZPCR,

which needs to correctly associate LPARNAME to SYSPLEX.

Depending on the alphabetical ordering of your SYSTEM and