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

Change 24.023 The default value of macro variable &TAPENGN, used for

VMXGINIT the engine for the TAPETEMP DD in Weekly/Monthly examples

Apr 1, 2006 that output to tape, is now changed to V9SEQ if executing

Jun 24, 2006 MXG under SAS V9, or to V8SEQ if executing under SAS V8.

This should have been done back in Change 23.061, which

changed CONFIGV9 to set the MXG default SEQENGINE=V9SEQ,

(it previously had been V6 due to SAS errors in V9SEQ),

but changing TAPENGN default was overlooked. The V6SEQ

engine does not support character variables longer than

200 bytes, and there are now many long variables in MXG.

Jun 24: The April change caused UNKNOWN ENGINE V9SEQ when

the Weekly or Monthly job was run for the first

time under SAS V8. New logic now tests the

&SASVERS to set V8SEQ or V9SEQ as appropriate.

Thanks to Robbie A. McCoy, Salt River Project, USA.
Change 24.022 The BY list in the default MONTHBLD example for ASUMDB2B

WEEKBLD now ends with ... QBACPID QWACBSC SHIFT to match the BY

MONTHBLD list used to build PDB.ASUMDB2B.

Mar 31, 2006 Jul 3: Unfortunately, the March change incorrectly had

Jul 3, 2006 MONTHBLD with QWACPID instead of QBACPID, and

WEEKBLD had QWACPID QBACBSC, and the preceding

change test also had incorrect spellings.

Now, all BYs agree with line 2 of this change.

Thanks to Michael Creech, Fidelity National Information Svcs, USA.

Thanks to Bruce Widlund, Merrill Consultants, USA.

Change 24.021 A invalid RACF SMF 80 record with NRSEGS=252 but that had

VMAC80A only 235 actual segments caused INPUT STATEMENT EXCEEDED.

Mar 31, 2006 The last segment was complete, and the RDW matched the

size of the actual SMF record, so this was not a record

that had been truncated in SMF post-processing. MXG now

prints an error message and hex dump on the log for each

instance of this type of invalid SMF record, so you can

send to IBM RACF Support if you choose to resolve their

invalid record. Jun 13, 2006: See Change 24.097.

Thanks to Randy Shumate, LexisNexis, USA.

Change 24.020 ASUMTAPE is still in development, pending STK reply to

ASUMTAPE our problem with their exit, but I accidentally made it

Mar 7, 2006 fail if run under ITRM; I replaced the previous use of

%VMXGWORL macro (to find the location, WORK or PDB, of

the input datasets) with hardcoded &MXGPDB..TAPES and

similar references. Now, the use of %VMXGWORL is

reinstated.

Thanks to Dan Squillace, SAS Institute ITRM, USA.

Thanks to Chris Weston, SAS Institute ITRM, USA.
Change 24.019 MXG set OPTIONS DKROCOND=NOWARN in BUILD001/BUILD005/3005

BUILD001 to prevent WARNING: VARIABLES NOT REFERENCED messages,

BUILD005 as those members execute code with many optional variable

BUIL3005 names in its KEEP= lists, but in BUILD005/3005 the option

Mar 7, 2006 was reset back to DKROCOND=WARN, and if your code had the

condition, the warning message caused condition code 4.

So the hardcoded reset changed the MXG DKROCOND=NOWARN

that is set by CONFIGVn/AUTOEXEC at initialization.

Now, %VMXGOPTR is used to store the original value of the

DKROCOND option, and the hardcode reset is change to now

restore the original value of the option.

And so you won't see any of these messages, unless you

change the OPTION after MXG initialization, in your

code or in mine.

Thanks to H.E. Tempelmans Plat, Corus, THE NETHERLANDS.
Change 24.018 INPUT STATEMENT EXCEEDED in RACF Extended Relocate 301

VMAC80A SMF30TP2 because new TOKSUBSY='PROXY' records were not

Mar 6, 2006 supported.

Thanks to Fred Schmidt, Northern Territory Government, AUSTRALIA.

Change 24.017 Two four-byte fields were inserted in the SYTCUP segment,

VMACXAM causing INVALID DATA FOR SYTNLPMG messages, and trashed

Mar 5, 2006 data in some SYTxxxxx variables. New variables SYTPCTBY

and SYTPCTOV for each LCUCPUID are now created and kept

in the XAMSYT dataset.

-IODQDS segment no longer flagged as UNKNOWN.

Thanks to Tony Curry, BMC, USA.
Change 24.016 Datetimestamp variables WTNIDTIM, WTUOWTIM and QWHSSTCK

VMAC116 were not called by %VMXGTIME, which is used to shift date

Mar 2, 2006 time variable's values to a common time zone, if you have

LPARs or SYSTEMs on different time zones.

Note that while UOWTIME contains a datetime value, it is

never shifted, because it is used as a token to match to

other records; this part of Change 19.286 is added in the

comments in VMXGTIME as a self-reminder:

Two very important "token" variables that are necessary

to match records together, READTIME and UOWTIME, are

NOT converted by VMXGTIME.

Thanks to Chuck Hopf, Bank of America, USA.

Change 24.015 Documentation only. Identifying CRYPTO users and usage.

VMAC30 -TYPE30 variable ICSFSCNT/SMF30CSC may or may not identify

VMAC7072 crypto users. It is the number of crypto instructions

Mar 1, 2006 executed on behalf of the caller (within that caller's

address space). However, new machine instructions are

available on T-Rex processors with the CPACF feature that

provide clear key DES/TDES functions as well as hashing

functions, and applications can call these functions

directly, bypassing ICSF, and those application calls

would NOT be included in this count.

-TYPE70Y2 Crypto dataset variables added by OA10556 in

MXG 23.05 to record these CPACF function statistics:

R702NH2B='SHA-256*DATA*BYTES*HASH'

R702NH2C='SHA-256*CALLS*TO*HASH'

R702NH2I='SHA-256*PCMF INSTR*USED TO*HASH'

-This information was extracted from a lengthy and very

informative IBM note ASKQQA Item BDC000034378, in reply

to the question "Is there a way to measure encryption

overhead in TLS/SSL for TN3270":

There is no separate SMF field that tells you how much

CPU time is consumed to do this encryption. However,

since it is the TCP/IP address space that is doing the

instructions for encryption, the CPU time consumed

would be included in the regular SMF fields for that

Address Space, i.e., both TYPE30 for the ASID and

TYPE72GO for its Service Class and Reporting Class.

The CPU time consumed by the PCIXX engine (the

handshake part) will be reported in the R7023T0 in

dataset TYPE7002 (RMF 70 subtype 2 crypto).

-That note suggests that for other crypto applications,

their CPU time will also be recorded in the address space

and service class records for the address space that does

the encryption. The TYPE1415 record now contains the

elapsed time for tape encryption, but no separate CPU

time exists in any address space records.
Change 24.014 Support for new QWSnPSRB DB2 Address Space preemptable

VMACDB2 and non-preemptable SRB CPU time in PDB.DB2STATS dataset.

Mar 1, 2006 Variables QWSnSRBT have always contained the SRB time for

DB2 Address spaces and for the IRLM Address space, and

included both preemptable and non-preemptable SRB time.

New variables QWSnPSRB will now contain only the SRB CPU

time consumed by preemptable SRBs in the address space

specified by QWHAASID.

Note: CHANGE was made in Change 24.028.
Change 24.013 Support for new memory object data in DFSORT records:

VMAC16 ICEMON - MEMORY OBJECTS ALLOCATED

Mar 1, 2006 ICEMOUSE - MEGABYTES USED FOR MEMORY OBJECTS

ICEMOSIZ - MOSIZE VALUE IN EFFECT

MEMOBJUS - MEMORY OBJECT USED?

These data were added in z/OS DFSORT V1R5

Thanks to Rob D'Andrea, Royal Bank of Scotland, UNITED KINGDOM.
====== Changes thru 24.012 were in MXG 24.01 dated Mar 1, 2006=========
Change 24.012 INPUT STATEMENT EXCEEDED in RACF Extended Relocate 301

VMAC80A SMF30TP2 because MXG only expected 8 bytes for TOKDANAM.

Feb 27, 2006 Field expanded to 80. Values of NOCPUTIMAX, NOASSIZMAX,

NOFILEPROCMAX NOPROCUSERMAX NOTHREADSMAX NOMMAPAREAMAX

are observed as values for TOKDANAM, with no values after

the TOKDANAM field.

Thanks to Fred Schmidt, Northern Territory Government, AUSTRALIA.

Thanks to Andrew Krink, Northern Territory Government, AUSTRALIA.

Thanks to Scott Thomson, Northern Territory Government, AUSTRALIA.
Change 24.011 Negative and missing values were created in PDB.TYPE30_6

VMAC30 after Change 23.296 revised the deaccumulation logic to

Feb 27, 2006 support wrapping of ACTIVETM/RESIDTM. Additionally, the

coversion of GMT timestamps to local using GMTOFF30 fails

when ONLY subtype 6 records are read; subtype 6 records

don't contain the SYNCTIME value needed calculate the GMT

offset, so MXG gets the RETAINed GMTOFF30 from the prior

SMF 30 record of different subtype.

-The errors could also cause fewer observations to be

created in PDB.TYPE30_6.

-However, variable GMTOFF30 will still be missing value in

PDB.TYPE30_6 if no prior 30s were found, and that will be

the only clue that the INTBTIME/INTETIME/SYNCTIME values

that MXG created (for symmetry with PDB.SMFINTRV) are not

on local time, but are still on GMT.

Thanks to Diane Eppestine, AT&T Services, Inc, USA.

Change 24.010 Variable LPARNSW (percent when capped) in RMF/NTRV and

VMAC7072 TYPE70 datasets could be zero when capping was active,

Feb 26, 2006 due to an error in the SPLIT70 redesign. The statement

LPARNSW=SMF70NSW should only have been executed when the

LPARNUM=PARTISHN, but it was mislocated and executed for

the last LPARNUM. And, of course, my test data did have

PARTISHN equal to the last LPARNUM, so the error was not

caught sooner.

-Array subscript out of range with exactly 60 LPARS. The

S70LPCP array was defined with 60 elements, but 61 are

needed to account for the PHYSICAL LPAR. I had assumed

than only 59 real LPARs plus the PHYSICAL was the limit.

Thanks to Diane Eppestine, AT&T Services, Inc, USA.

Thanks to Brian Crow, British Telecom, ENGLAND.

Change 24.009 Variable AVGWKSET in TYPE30 datasets was too large if you

VMAC30 have IFAs, because I didn't know that PAGESECS, which is

Feb 27, 2006 the source of AVGWKSET, is based on service, and IFA time

and TCB time are included in service. IBM separates the

IFA and TCB time in RMF for performance management, and

in SMF for charge back, but doesn't separate them in the

Service Units, nor for TIME= on JCL, or in the CPUTIMER

or TIMEUSED services. zIIPs will be handled the same

way. This would be important if AVGWKSET and PAGESECS

had any real use in memory utilization measurmement, but

they don't, as PAGESECS only counts the memory frames

owned by the task when it is executing TCB or IFA. All

of the pages owned by the task while in wait state

(wait for CPU dispatch, page fault, I/O, cross memory)

are NOT counted in PAGESECS. In addition, AVGWKSET by

itself is a poor metric, because it only measures the

average number of pages that might be swapped out; it

does NOT measure memory utilization because it does NOT

indicate how LONG those pages were held. Why does the

AVGWKSET exist? Primarily for modeling programs, which

can take that as a metric, and inside the model, multiply

by the modeled duration, so the model program can measure

memory utilization (like old K-Core HOURS) and compare

with the memory capacity (GIGABYTES times 24 Hours).

And finally, tasks don't "OWN" real memory; z/OS decides

how much memory to dole out to tasks based on service

objectives, so whatever memory utilization might be

measured is not because the task 'wanted' that memory,

but because z/OS decided to give it that memory.

-Variable CSTORE30 should never have been created as such.

It does not measure CSTORE pages, but only measures the

IARVSERV Shared Pages used by this task, and thus it is

almost always zero, except for tasks that share pages.

Shared segments allow two address spaces to have

addressability to the same data, like a private CSA,

and was added for posix compliance. The shared areas

must be overtly set up by applications and I'm not

aware of any current exploiters.

To avoid confusion, and hopefully to draw your attention

to this change, CSTORE30 is now set to a missing value.

Thanks to Gennady Katsnelson, AT&T Services, Inc, USA.

Thanks to Diane Eppestine, AT&T Services, Inc, USA.

Thanks to Jack Hudnall, AT&T Services, Inc, USA.
Change 24.008 Corrections for TPF Continuous Monitor date; the "QUICK

UTILTPFC FIX" that reset 3827 to 3826 was removed, since it fixed

VMACTPFC nothing and created errors. Debugging PUT statements in

Feb 23, 2006 UTILTPFC and VMACTPFC members were commented out.

-BY variables were corrected from SYSTEM SMFTIME (MVS!!)

to the TPFC variables TPFCSS TPFCSSU TPFCTIME.

Thanks to Chris Weston, SAS Institute ITRM, USA.
Change 24.007 Support for the "Memory Monitor" that writes an SMF

ASMUSR1 record that tracks the memory object sizes by JOB.

EXUSR1ME This is in intial testing.

FORMATS You must run FORMATS and then update IMACKEEP with the

IMACUSR1 MACRO _IDUSR1 nnn %

TYPEUSR1 definition to set the SMF record number.

TYPSUSR1

VMACUSR1

VMXGINIT

Feb 22, 2006

Thanks to Dean Montevago, Visiting Nurse Service of New York, USA.
Change 24.006 APPARENT MACRO MAC102S error with ANALDB2R or READDB2 is

READDB2 corrected with this revision, although we have NOT been

Feb 22, 2006 able to replicate the error, we know the code was wrong.

Thanks to Jim Nickolas, LEXIS-NEXIS, USA.

Change 24.005 Support for APAR OA14340 (follow on the OA11675) which

VMAC30 now creates an 8-byte field (SMF30TEX) to replace 4-byte

Feb 22, 2006 SMF30TEP when TEP overflows. Variable EXCPERR=Y is set

if bit SMF30TEF is on by OA11675, but with OA14340, MXG

stores SMF30TEX in EXCPTOTL instead of SMF30TEP, and the

EXCPERR is blanked, since EXCPTOTL is now valid.

Similar change made to SMF32 fields also.
Change 24.004 ASUMTMNT failed if _GRPMNNM and _GRPMNCD were used to

ASUMTMNT define "Locations" for tape devices; Change 23.253 had

Feb 23, 2006 changed to those macro names, but ASUMTMNT still had the

initial _Gxxxxxx names that were later changed.

Thanks to Paul Bennett, JPMorganChase, ENGLAND.
Change 24.003 Toleration support for z/VM 5.2 (INCOMPATIBLE). The 10.1

VMACVMXA Application Server 10.2 record was changed from 24 to 28

Feb 23, 2006 bytes, but there is no field with the number of entries,

nor the length of the entries, so a MOD(CALDATLN,24) and

MOD(CALDATLN,28) to create LEN0D of 24 or 28 is inserted

to figure out which length is present.

Without this correction, BROKEN CONTROL RECORD messages

are printed on the log.

There are many new data fields added to the MONWRITE data

in z/VM 5.2, and these data are not yet supported in this

change. The known records and new data lengths are here

so I can whittle them down over time:

REC SKIP REC SKIP REC SKIP REC SKIP REC SKIP

1.6 12 0.22 64 3.1 220 3.14 20 6.21 8

1.14 2 0.3 96 3.19 68 3.18 40 4.9 20

4.9 20 0.21 64 3.2 80 4.3 20

0.4 12 3.3 12 3.20 108 5.9 92

Thanks to Pat Curren, SuperValu, USA.

Change 24.002 The ML-38 default DEBUG=YES should be changed to DEBUG=NO

ASMTAPEE (unless you are specifically working with MXG support).

Feb 20, 2006 The DEBUG=YES option was intended only for investigation

Apr 7, 2006 of STK HSC exit code, and should not have been enabled,

as DEBUG=YES causes a dump for any ABEND the monitor

encounters, even ones that we know can happen.

One specific known ABEND occurs when we are in cross

memory and running TIOT entries, and the chain has

been modified while we're in it: with DEBUG=NO, that

ABEND is ignored and suppressed and our code recovers

and then continues, minus only the information we now

can't find in the modified TIOT.

However, there is NO loss of data; the SMF records were

written and the monitor continued to monitor; it is only

to suppress the unneeded dumps.

While this change was dated in Feb, and should have been

made in the ASMTAPEE member in MXG 24.01, the actual

debug option was not disabled until April 7, 2006, which

is now the LAST CHANGED date in ASMTAPEE. Only if your

ASMTAPEE is dated earlier, would you need to change the

line 3248 in that ASMTAPEE at ML-38, from what was there:

DODEBUG EQU B'00001000' DO DEBUGGING STUFF

to now read:

DODEBUG EQU B'00000000' DO DEBUGGING STUFF

and then reassemble ASMTAPEE to disable DEBUG=YES.

Thanks to Dr. Alexander Raeder, ATOSORIGIN, GERMANY.

Thanks to Beau Chavis, Bank of America, GERMANY.
Change 24.001 The DB2 Audit Trace IFCIDs 140, 141, 142, and 145 caused

VMAC102 INPUT STATEMENT EXCEEDED error if the SQL Text length was

Feb 20, 2006 more than 4000 bytes. MXG used length field QW014nLL in

its INPUT QW014nTX $VARYING. QW014nLL, but the ERROR made

me RTFM ("F=Fine"), amd I found that IBM did document the

truncation, providing adjacent QW014nLE field with the

length of the truncated SQL text in the record, so it is

now used for the SQL text INPUTs.

And IBM doesn't always store exactly the first 4000;

one record had QW0145LL=13120, but QW0145LE=3980.

Thanks to Bjorn Helgestad, VPS ASA, NORWAY.

Thanks to Steinar Amot, VPS ASA, NORWAY.

LASTCHANGE: Version 24.

=========================member=CHANGE23================================

/* COPYRIGHT (C) 1984-2006 MERRILL CONSULTANTS DALLAS TEXAS USA */
Annual MXG Version 23.23 is dated Feb 20, 2006, thru Change 23.358

PreRel MXG Version 23.23 was dated Feb 15, 2006, thru Change 23.351

Final MXG Version 23.11 was dated Feb 2, 2006, thru Change 23.340

Third MXG Version 23.11 was dated Feb 2, 2006, thru Change 23.338

Second MXG Version 23.11 was dated Jan 31, 2006, thru Change 23.336

First MXG Version 23.11 was dated Jan 30, 2006, thru Change 23.336

MXG Version 23.10 was dated Jan 23, 2006, thru Change 23.328

MXG Version 23.09 was dated Dec 7, 2005, thru Change 23.309

Third MXG Version 23.09 was dated Dec 6, 2005, thru Change 23.309

Second MXG Version 23.09 was dated Dec 1, 2005, thru Change 23.303

First MXG Version 23.09 was dated Nov 30, 2005, thru Change 23.300

MXG Version 23.08 was dated Oct 27, 2005, thru Change 23.273

First MXG Version 23.08 was dated Oct 25, 2005, thru Change 23.271

Final MXG Version 23.07 was dated Aug 10, 2005, thru Change 23.209

First MXG Version 23.07 was dated Aug 9, 2005, thru Change 23.207

MXG Version 23.06 was dated Jun 29, 2005, thru Change 23.176

MXG Version 23.05 was dated Jun 7, 2005, thru Change 23.154

First MXG Version 23.05 was dated Jun 5, 2005, thru Change 23.148

MXG Version 23.04 was dated May 4, 2005, thru Change 23.107

MXG Version 23.03 was dated Apr 22, 2005, thru Change 23.090

MXG Version 23.02 was dated Apr 4, 2005, thru Change 23.061

MXG Version 23.01 was dated Mar 15, 2005, thru Change 23.050

MXG Version 22.22 was dated Feb 1, 2005, thru Change 22.378

MXG Newsletter FORTY-SIX was dated Feb 1, 2005.

Contents of member CHANGES:
Member NEWSLTRS (and the Newsletters frame at http://www.mxg.com) now

contain the current MXG Technical Notes that used to be put in member

CHANGES between Newsletters. New Technical Notes are now added (and

now dated!) in NEWSLTRS/Newsletters with each new MXG Version.

I. 2006 Annual MXG Software Version 23.23 automatically was sent.

II. Incompatibilities and Installation of MXG 23.23.

III. Online Documentation of MXG Software.

IV. Changes Log

=======================================================================

I. 2006 Annual MXG Software Version 23.23 dated February 20, 2006.

The Annual Version was available for ftp download on Feb 20, but

a CD-ROM containing MXG 23.23 will also be sent to all sites; the

copying/packaging began on the 20th, with mailing on Feb 25th, so

all sites should receive the package in early March.

Major enhancements added in MXG 23.23 - 2006 Annual MXG Version
TYPE70 23.348 Final "70's Record Rewrite", PARTNCPU corrected.

TYPE115 23.347 Support for MQ for z/OS Version 6.0 (COMPAT)

TYPE110 23.342 Support for CANDLE UMBRELLA optional CICSTRAN data.

READDB2 23.345 New WANTONLY= enhancement for %READDB2 utility.

MONTHxxx 23.351 &MXGSYSN macro variable for compatibility.

WEEKxxx 23.351 &MXGSYSN macro variable for compatibility.

MACKEEP 23.346 DB2 Tailoring Example to add DB2 102 to PDB.
Major enhancements added in MXG 23.11
1. Corrections for "Split 70/Over 60 LPAR" RMF 70 Re-Write.

TYPE70 23.330 Corrections to Split 70/Over 60 LPAR Change 23.321.

2. Yet another major revision to RMF 70 processing:

TYPE70 23.336 Support for RMF with repeated SYSTEMs in a SYSPLEX.

3. ITRM sites that build RMFINTRV do NOT have to change anything;

the previous "INCOMPATIBILITY" that required _STY70 to be put

in your EXPDBOUT member is NOT needed when RMFINTRV is created,

and everyone SHOULD create the XRMFINT/RMFINTRV dataset.

"Routine" enhancements/changes:

TYPENDM 23.331 Support for NDM/Connect Direct subtype TF, TL, TW.

TYPE30 23.329 Support for SMF30CEPI field, new CPUCIPTM variable.

TYPE7072 23.335 Variables SMF70OIL and SMF70SYN now KEPT in TYPE70.

TYPE30_V 23.334 IMACINTV default now OUTPUTs TYPE30_V/PDB.SMFINTRV.

TYPEVMXA 23.332 Variables HFLLIST,HFPGACT were accumulated.

Major enhancements added in MXG 23.10
1. Support for over 60 LPARs. Support for Split RMF 70 records.
Required extensive rewrite of the "heart and soul" logic in the

VMAC7072 and VMXG70PR members, potentially impacting datasets

TYPE70 TYPE70PR RMFINTRV ASUM70PR ASUM70LP ASUMCEC and ASUMCELP

from TYPE7072, TYPS7072, BUILDPDB/BUILDPD3, or RMFINTRV programs.

New DATA records that now exist that required this change:
INCOMPATIBLE: If you have more than 32 LPARs defined, versions

earlier than MXG 23.10 will fail with ARRAY errors.

See Change 23.322/23.321 text.

INCOMPATIBLE: IBM now splits RMF 70 records when you have lots of

LPARs and lots of spare engines; MXG 22.22+ detects

and reports split records were found in messages on

the SAS log, but created incomplete/wrong data in

TYPE70/TYPE70PR/ASUM70PR/ASUMCEC from split 70 SMF.

See Change 23.322/23.321 text.
New stuff YOU may have to do when you install MXG 23.10 or later:
INCOMPATIBLE: ITSV/ITRM sites that run BUILDPDB but do NOT create

the XRMFINT (RMFINTRV) dataset, MUST insert this

_STY70

text (an invocation of that old-style macro) in the