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

=Attended the 50th Anniversary meeting of SHARE, the world's first

=computer User Group, in Boston.

Change 23.216 APAR OA10346 was supported by Change 23.187, but it was

VMAC7072 revised on Aug 18, with these new enhancements:

VMXG70PR -TYPE72Y2 dataset, variables CRYIH2R and CRYIH2s created

Aug 19, 2005 for hashing rate and hashing size for SHA=256.

-Tests in VMXG70PR were revised, because SMF70CIN can now

contain "IFA", "IFL", "ICF" or "CP" to identify the type

of processor.

Thanks to Don Deese, (CPExpert), Computer Management Sciences, USA.

Change 23.215 While not "hard-coded" DDname, these two statements that

VMXGRMFI were inadvertently left in the middle of VMXGRMFI

Aug 18, 2005 %LET SPININ = SPIN;

%LET SPINOUT = SPIN;

were just as bad as hardcoded, and cause errors if you

had changed your SPIN library's DDNAME elsewhere in MXG.

Both lines were deleted.

Thanks to Ken Williams, CPT Global, ENGLAND.

Thanks to Mark Williams, Marks and Spencer, ENGLAND.
Change 23.214 Cosmetic. Label for variable A20E2HWM was corrected to

VMAC110 now read A20E2HWM='PEAK*CONTENTION*WINNERS'.

Aug 17, 2005

Thanks to Scott Wiig, U.S. Bank, USA.

Change 23.213 All SMF88xxx datetime variables were on GMT time zone.

VMAC88 Now, the GMT88OFF offset is calculated and the variables

Aug 17, 2005 are all now on the same time zone as SMFTIME.

Thanks to Don Deese, (CPExpert), Computer Management Sciences, USA.

Change 23.212 Cosmetic. Labels for RTSMAP01-RTSMAP14 were clarified to

VMAC7072 'BUCKET nn*RESPONSE TIME*GOAL*PERCENT' because they

Aug 16, 2005 contain the percentage of R723CVAL, rather than a goal

value. If you want to know the goal value of the nnth

bucket, it is RTSMAPnn*R723CVAL.

Thanks to Dave Crandall, Farmers Insurance, USA.

Change 23.211 Requesting USERADD=6 25 26J3 21 30, INCLAFTR=BUIL3001

UTILBLDP generated a MACRO _WTY26J2 _LTY26J2; statement which

Aug 16, 2005 should have been MACRO _WTY26J3 _LTY26J3 % statement.

Thanks to Hansruedi Zaugg, EDS, SWITZERLAND.

Change 23.210 MXG 23.07 only. Typo of CURRSHARE in the DROP statement

VMXG70PR should have been CURSHARE. Fortunately, there was no real

Aug 16, 2005 impact on any of the expected variables, just that the

variable CURSHARE was unnecessarily kept. The typo did

cause an error when MXG ran under V6, because the 9-byte

variable name exceeded SAS V6 limits. MXG variables are

normally also 8-bytes-max; our QA tests for name length,

but only for kept variables, and since CURRSHARE was a

typo that didn't exist in a KEEP= statement, this typo

was missed.

Note: I thought this was fixed in the final 23.07, by

Change 23.208, but I typo'd the typo, and MXG 23.07

had CURRSHAR instead of CURSHARE, so the problem was

not corrected until MXG 23.08.

Thanks to Jon Whitcomb, Great Lakes Higher Education Corporation, USA
====== Changes thru 23.209 were in MXG 23.07 dated Aug 10, 2005=========
Change 23.209 Not sure why, but the includes of VMAC7072,VMAC6,IMACKEEP

ASUMPRTR inside ASUMPRTR cause it to fail when it was INCLUDed in

Aug 10, 2005 EXPDBOUT in BUILDPDB to create the PDB.TYPE6ENH dataset.

Removing those three members from the %INCLUDE statement

in ASUMPRTR eliminated the ERROR: OLD-STYLE MACRO NAME

PDB.TYPE6 MUST CONTAIN ONLY LETTERS, DIGITS AND UNDERSC.

Those members only need to be included when SMF data is

read, and that JCL example in the comments has the needed

%INCLUDE statement, so the %INCLUDE for them in ASUMPRTR

was redundant, anyhow.

Thanks to Keith McWhorter, Georgia Technology Authority, USA.
Change 23.208 Replaced by Change 23.210.
====== Changes thru 23.207 were in MXG 23.07 dated Aug 9, 2005=========
Change 23.207 Variables IAMNOA and IAMNOP have traded places; they were

VMACIAM coded as documented, but the documentation was wrong.

Aug 9, 2005 Aug 10: it was IAMNOD and IAMNOP that traded places.

Aug 10, 2005

Thanks to Ken Wantuch, BB&T IT Systems Engineering, USA.
Change 23.206 Line 2704 contained a semicolon after SMFPSRVR, but that

ANALCISH should have been a comma. Only caused error if CFEC FEPI

Aug 9, 2005 Connection Statistics report was requested.

Thanks to Scott Wiig, U.S. Bank, USA.

Change 23.205 -Variables LPnNSW/SMF70NSW, percent when LPAR was capped,

EXCECTIM were wrong in PDB.ASUMCEC/ASUM70LP/ASUM70PR and could

VMXG70PR even be greater than 100%. Weighted average had wrongly

Aug 9, 2005 used LPARDUR instead of SMF70DSA. Logic revised.

Aug 10, 2005 -LP1LAC was always missing in PDB.ASUM70LP because of a

Nov 10, 2005 typo that had SMF71LAC instead of SMF70LAC.

-LPnLAC was often missing in PDB.ASUMCEC because logic to

select the first LPARNUM in each CECSER has been wrong.

Variable PCTMVSBY is populated only in "this system" obs

in TYPE70PR dataset, so adding DESCENDING PCTMVSBY to the

end of the sort order that creates CECCLEAN forces that

"this system" observation to be the one that is kept.

-The optional EXCECTIM member is reinstated in VMXG70PR

to change STARTIME in PDB.ASUMCEC, PDB.ASUM70PR, and in

PDB.ASUM70LP datasets to the exact nearest minute for the

summarized output's STARTIME value; observations with

slight differences caused duplicate or semi-duplicate

output. Nov 10: this paragraph revised; originally, it

said only PDB.ASUMCEC's STARTIME was changed. But, now,

you also need Change 23.289 for full short-interval fix.

-Aug 10 enhancement: VMXG70PR logic (ASUM70PR) now adds

variable LPARNSW, percent when this LPAR was capped, to

the PDB.RMFINTRV dataset, so your system-level analysis

will contain LPAR capping.

Thanks to Chuck Hopf, MBNA, USA.
Change 23.204 Documentation only. Change 23.021 correctly populated

ASUM70PR the "PHYSICAL" LPAR's data in LP0xxxxx variables, so the

Aug 9, 2005 total MSU, summed across all LPARs, from PDB.ASUMCEC,

will be slightly larger than the MSUs from versions prior

to MXG 23.01.

Oct 31, 2005: See Change 23.276.

Thanks to Huch Lapham, Royal Canadian Mounted Police, CANADA.
Change 23.203 Change 23.143 did not correctly handle the length 8 data

VMACMPLX fields, and MXG's INPUT did not match the MPLX DSECT.

Aug 9, 2005

Thanks to David Bixler, FISERV, USA.

Change 23.202 -Variables KW21GL01-KW21GL05 are no longer created nor

VMAC80A nor kept in dataset TYPE8021, as the RDEFINE command does

Aug 8, 2005 not contain the GLAUFLGS field.

Aug 30, 2005 -Variables CLASNAM1-CLASNAM4 are now created in TYPE8024

to support up to 5 class names.

-Support for SMF80DTP (43) for SETROPTS GENLIST/NOGENLIST

and enhancement for (42) for SETROPTS RACLIST/NORACLIST;

up to five class names (CLASNAME,CLASNAM2-CLASNAM5) are

now kept from either 42 or 43 RACFTYPE entry.

This assumes that the SETROPTS record contains either

a (42) or a (43) segment, but not both. My test data

had no event 24 records so I could not validate that

assumption. If wrong, then new variable names will be

needed and this text will be revised.

-Aug 30: tests for NR44SEGS should be NR42SEGS in the

WHEN (42) logic; caused job to fail.

Thanks to Adam Thorn, Euroclear, BELGIUM.

Thanks to Aimee Steel, Euroclear, BELGIUM.

Thanks to Bill Arrowsmith, Euroclear, BELGIUM.
Change 23.201 Condition Code (Return Code) 4 in ASUMTALO eliminated.

ASUMTALO The LENGTH statement in ASUMTALO specified DEVICE $8, but

Aug 8, 2005 the actual length of DEVICE is only $7; both the LENGTH

entry and the (redundant) "Compiler Faker" statement were

revised to make DEVICE only seven characters long.

The message appears when SPIN.SPINTALO exists, i.e., only

on the second or later execution of ASUMTALO, but it had

no impact, other than setting the condition code.

-After years of seeing those spurious LENGTH OF CHARACTER

VARIABLE HAS ALREADY BEEN SET messages, when there was no

change in the length (before SAS fixed the message so it

now only prints when the lengths are different), this is

the first time that message actually uncovered an error!

Note: The message text suggests that putting the LENGTH

statement ahead of the SET statement will eliminate the

message; however, that is not acceptable because if the

LENGTH statement precedes the SET statement, then this

DATA step could inadvertently truncate the kept length

of a variable, but there would be no warning message.

Instead, MXG puts the LENGTH statement after the SET

statement so that any mismatch will be detected.

Thanks to Mike Allen, Pacific Corp., USA.

Change 23.200 Support for MegaCrytion's user SMF record creates:

EXMGCRCR dddddd dataset description

IMACMGCR MGCRCR MEGACRYP MEGACRYPTION START/END

TYPEMGCR The start and stop datetimestamps MGCRSTRT/MGCREND are

TYPSMGCR on the GMT clock, and there is no GMT Offset in the

VMACMGCR record that could safely be used to infer the zone,

VMXGINIT until the vendor adds the GMTOFFSET field to the record.

Aug 4, 2005

Thanks to John Rivera, i-structure, USA.
Change 23.199 Support for TPF Continuous Data Collection, TPFCDC, which

EXTPFC80 is a new data source for TPF and creates many datasets:

EXTPFC81 dddddd dataset description typetype

EXTPFC82 TPFC80 TPFC80 SYSTEM MESSAGES 80X

EXTPFC83 TPFC81 TPFC81 SYSTEM LISTS 81X

EXTPFC84 TPFC82 TPFC82 SYSTEM BLOCKS 82X

EXTPFC85 TPFC83 TPFC83 DASD/POOLS 83X

EXTPFC86 TPFC84 TPFC84 DASD DEVICES 84X

EXTPFC87 TPFC85 TPFC85 SYSTEM VFA 85X

EXTPFC88 TPFC86 TPFC86 SUBSYSTEM VFA 86X

EXTPFC89 TPFC87 TPFC87 MPIF 87X

EXTPFC8A TPFC88 TPFC88 TAPE 88X

EXTPFC8B TPFC89 TPFC89 TCP/IP 89X

EXTPFC8C TPFC8A TPFC8A I-STREAM 8AX

EXTPFC8D TPFC8B TPFC8B SUBYSTEM MESSAGES 8BX

EXTPFC8E TPFC8C TPFC8C SUBSYSTEM USER 8CX

EXTPFC8F TPFC8D TPFC8D LODIC 8DX

EXTPFC90 TPFC8E TPFC8E MQ SUMMARY 8EX

EXTPFC91 TPFC8F TPFC8F MQ QUEUE DETAIL 8FX

EXTPFC93 TPFC90 TPFC90 MQ CHANNEL DETAIL 90X

EXTPFC94 TPFC91 TPFC91 USER DATA 91X

IMACTPFC TPFC93 TPFC93 CDC RECORD 93X

TYPETPFC TPFC94 TPFC94 STATIC SYSTEM INFO 94X

TYPSTPFC TPFCDC "records" have a '93'x segment with total length

UTILTPFC the number of segments that follow in that record, and

VMACTPFC then those segments, which can have repeated entries,

VMXGINIT and each of which contains its own-length field, follow.

Aug 3, 2005 -MXG creates an observation in each of the above datasets

Aug 19, 2005 for each instance of each segment.

-But the TPF creation splits these logical records into

multiple physical "tape" records that are most definitely

NOT standard variable length records, and that cannot be

directly read. The first 4095 bytes of data start the

first physical record, but TPF adds a 16-byte trailer

segment, creating a 4111-data-byte (4115 LRECL) variable

length first-record. The remaining bytes of the logical

record start in the first byte of the second "tape"

record, which is padded with nulls thru data byte 4095,

and to which the TPF 16-byte trailer is added at the end.

-Because of this non-standard record format, you will have

to pass the TPFCDC data file twice: first, with the MXG's

UTILTPFC program, which will read those split records and

create a legitimate VBS record for each split record, and

then second, that output file is processed by TYPETPFC to

create the preceding 20 TPFCDC datasets.

Note: UTILTPFC is heuristic based on the sample data,

and it reads a pair of records for each event.

It will need revision if your TPF data length

causes more than two split records to be needed.

-Product Problems Reported to IBM:

1. Their complicated split process is not working; one

byte of data is lost from the segment that is split!

In my test data that was always the '87'x segment,

so MXG resets that segment's length, but that only

works if the '87' is the segment across the split.

MXG will be revised when IBM corrects their error.

Oct 28 Update: IBM APAR PJ30503 corrects the one

byte loss error.

2. Two fields in the '90'x segment have blanks instead

of binary numeric values. Aug 19 update: IBM says

the two fields (TPFCBTSZ, TPFCSZLB) do not apply when

the MQ Channel Type is SERVER (TPFCCTYP='V'); MXG now

sets those two variables missing when TPFCCTYP='V'.

-Product exposure:

Several character fields have field lengths that can be

changed by the TPF installation; MXG code expects these

lengths for those fields; other lengths cause errors:

Length Field Name Length MXG Variable

CDC_SS_NAME_LEN 4 TPFCSSNA,TPFCSS

CDC_SSU_NAME_LEN 4 TPFCSSUN,TPFCSSU

MQ_Q_MGR_NAME_LENGTH 48 TPFCQMGR

MQ_Q_NAME_LENGTH 48 TPFCQNAM

MQ_Q_CHANNEL_NAME_LENGTH 20 TPFCCHAN

Thanks to Luis R. Vega-Zayas, IBM TPF, USA.

Change 23.198 Support for existing NT objects with fewer data fields

VMACNTSM (DATABASE with NRDATA=133, MSEXCHANGEIS MAILBOX with 49,

Aug 4, 2005 DATABASE==>INSTANCES with NRDATA=92, and MSEXCHANGE IS

with NRDATA=110) than MXG code expected. Those objects

records were deleted prior to this change.

Thanks to Paul Billick, Harleysville Insurance, USA.

Change 23.197 The hardcoded "SPIN" DD in PROC COPY IN=SPIN OUT=&PDBMXG

BUILD005 in BUILD005/BUIL3005 was changed to &SPINOUT so the new

BUIL3005 SPIN datasets will be backed up from the correct DD.

Aug 4, 2005 If the &SPINOUT was different than "SPIN", you could get

a VARIABLE NOT FOUND error when SPUNJOBS executed.

Thanks to Ken Williams, CPT Global, ENGLAND.

Thanks to Mark Williams, Marks and Spencer, ENGLAND.
Change 23.196 -Support for CA SAR/VIEW R11,they INCOMPATIBLY CHANGED the

FORMATS SMF records, increasing these variables to $EBDCID32:

VMACSARR SV20DIST,SV21DIST,SV30RID,SV30VID,SV31RID,SV31VID,

Aug 3, 2005 SV31DIST,SV31BNDL,SV32RID,SV33RID,SV34RID

and by increasing SV33LTM to PIB4. The test for SARR

Version got messy; SMFVPRL is now '11.0' but it used to

be '2.0 ', so instead of IF SMFVPRL GE '11.0' THEN....,

each test was more complicated:

IF INPUT(SCAN(SMFVPRL,1,'.'),5.) GE 11 THEN ....

-Format MGSARTY new value '10:DOC VIEW WEB' for Interface

Type was added.

Thanks to Mark Schrager, Metropolitan Life, USA.

Change 23.195 Line fifteen had an end comment but no start comment,

GRAFTALO which caused the %MACRO statement to never be read.

Aug 3, 2005

Thanks to Ep van der Es, Dow Chemicals, THE NETHERLANDS.

Change 23.194 -Missing value messages for DB2RDWTM when testing IMACEXCL

UTILEXCL built by UTILEXCL found DB2RDYTM had been misspelled as

Aug 2, 2005 DB2RDWTM, which does not exist. Value of DB2RDYTM was

incorrect by a factor of 16 due to that typo.

-Calculation of SEGLEFT for optional segments was only

correct for the first segment; fortunately, it appears

to have had no impact; using SEGSTRT instead of LOC in

each calculation corrects the exposure.

Thanks to Normand Poitras, IBM Global Services, CANADA.
Change 23.193 Support for TNG AIX new object CA PROCESS GROUP (PID)

EXTAI025 creates new MXG AI025 dataset. New variables are added

FORMATS to datasets AI018 (CA KERNEL GROUP), AI020 (CA NETWORK

VMACTNG GROUP), and AI016, (CA INTERFACE GROUP).

VMXGINIT

Aug 2, 2005

Thanks to Dale Gilbert, AhYum, USA.
Change 23.192 Variable NDMUID in dataset NDMRJ (Run Job) was truncated

VMACNDM to 8 bytes, instead of being input as $EBCDIC64., because

Jul 30, 2005 the test for that input did not contain 'RJ'.

Aug 10, 2005 -Aug 10: additional variables are now read in from 'RJ'.

Thanks to Tom Neurauter, Fidelity Systems, USA.
Change 23.191 Cosmetic. Invocation of VMXGSUM had "ANALCACH" instead

ASUMCACH of "ASUMCACH" for the printed message text.

Jul 30, 2005

Thanks to Chuck Hopf, MBNA, USA.

Change 23.190 Comments only. IMACICDA is not used if IMACEXCL controls

IMACICDA the input for a CICS APPLID/REGION. When IMACEXCL is

Jul 27, 2005 used, it controls the INPUTing of the optional CICS data

segments. Only when there is no IMACEXCL, or IMACEXCL

does not protect an APPLID, does IMACICDA control the

order of the optional CICS data segments MXG expects.

Thanks to Normad Poitras, IBM Global Services, CANADA.
Change 23.189 The example should have had //DAY DD instead of //PDB DD,

PDBCPYDY to copy from the "TODAY" PDB library just created by the

ACHAP35 BUILDPDB program, into the day-of-week PDB library. I use

Jul 21, 2005 //PDB in the "build", but //DAY thereafter to refer to

the "today" PDB library.

Thanks to Jeff Harder, Farm Bureau Insurance, USA.

Change 23.188 Variable R744QFLG should have been defined LENGTH $1, but

VMAC74 ended up as CHAR 34 because it's formatted $MG074QF which

Jul 20, 2005 set the kept length as the longest text in that format.

This variable was not caught by Change 23.170 because it

does NOT appear in an INPUT statement, which was expected

in our original QA analysis program, but that report has

been revised to catch any other similar syntax issues.

Thanks to Travis Hicks, IBM GS (Telstra Account), AUSTRALIA.

Change 23.187 Support for APAR OA10346 adds the LPAR's User Partition

VMAC7072 Identifier (UPID, the value you specified on your HMC

Jul 20, 2005 Customize Image Profile) to RMF 70 PR/SM section for each

LPAR, as variable SMF70UPI in TYPE70PR dataset.

As was reported in MXG Newsletter 46, APAR II13668 said

that after z990s, LPARNUM (SMF70LPN) was no longer a

static identifier, but instead is now a system generated

number of the alphabetical location of the LPAR name, and

the LPARNUM of an LPAR changes when you add/delete LPARs.

But now, IBM has accepted Edward Williams suggestion and

added the new SMF70UPI variable to TYPE70PR dataset.

MXG code

If you want to use SMF70UPI in your reporting, please

send me some SMF 70 records (see member SENDDATA) after

you have the APAR installed, so we can decide how to

add SMF70UPI to the ASUM70PR and ASUM70LP datasets, and

so I can validate those changes.

Thanks to Edward Williams, BMC, USA.

Change 23.186 Support for new CPUTYPE '2094'x for the z9 processors;

VMAC7072 this is an INCOMPATIBLE change: without this change, your

VMXGRMFI TYPE70PR dataset will contain extra observations for

Jul 20, 2005 nonexistent LCPUADDR, and incorrect data values.

Aug 29, 2005 -The exposure in VMXGRMFI for RMFINTRV is minimal; the

CPUTYPE test is used only for OS/390 or very early z/OS

that did not have SMF70WLA or SMF70LAC populated, and it

is used only to create CECSUSEC, CPCNRCPU, CPCFNAME and

CPCMSU variable's values from table lookups.

-In VMAC7072 there are several CPUTYPE tests with impact:

It is used to set SMF70ONT missing when it is zero for

some cases, which affects counting of CPU engines, and

which is used to identify spare engines so they are not

output in PDB.TYPE70PR; without this change, extra and

spurious observations are created in PDB.TYPE70PR.

It is also used to populate SMF70CPA for OS/390 and

early z/OS before SMF70CPA was added to the SMF record.

Thanks to Patricia Hansen, ADP, USA.

Change 23.185 Roscoe creation of PDB.ROSCOE didn't work when UTILBLDP

VMACROSC was used to create the sysin stream to add ROSCOE to PDB.

Jul 19, 2005 Most "DIF" members invoke the _Sdddddd macro for that

dataset with accumulated data, but ROSCOE is unique and

is now revised, so that DIFFROSC is included when _SROSC

is invoked, and all of the datasets that are processed in

DIFFROSC no longer have their _Sdddddd sort macro invoked

in the revised _SROSC macro. And, the ROSCOE datasets

that are merged into PDB.ROSCOE are no longer kept.

Thanks to Jeff Harder, Farm Bureau Insurance, USA.

Change 23.184 Optional new %LET MXGABND=nnnn; enhancement can be used

VMXGINIT to make MXG fail with a USER ABEND nnnn, instead of just

VMAC110 printing error messages on the SAS log. This option is

VMXGRMFI whether or not you want the job to USER ABEND nnnn.

Jul 19, 2005

Oct 19, 2005 -To enable the new MXGABND enhancement, you would insert:

%LET MXGABND= 333;

as your first SYSIN statement, and if any of the below

errors occur, your MXG job will USER ABEND 333.
-The default value for MXGABND is 0000, for NO ABEND. You

must use a value between 0001 and 4095 for nnnn.

Actually, you can use a larger value for nnnn, but the

ABEND code you see will be MOD(ABEND,4096) so using

nnnn=4096 resulted in USER ABEND U0000,

nnnn=8000 resulted in USER ABEND U3904, and

nnnn=9999 resulted in USER ABEND U1807.
The option is only available for these specific errors:
-SMF type 110 CICS record processing (Jul 19, 2005):

***ERROR.TYPE110.CICS/ESA 3.1.0. EXCLUDED FIELDS HAVE

BEEN DETECTED. YOU MUST RUN UTILEXCL.

RECORD WAS DELETED. CICSTRAN DATA WAS LOST.

***ERROR.VMAC110 STRTTIME HAS MISSING VALUES and

***ERROR.VMAC110.ESA.2 INVALID TASKNR OR STRTTIME IN...

Those errors means that your CICS records have

changed or that you have excluded data and you must

run the UTILEXCL program to create IMACEXCL and to

tailor the IMACICxx's that you may also need to

EDIT to properly read the data. But, as the

message was only printed in the middle of the SAS

log of the daily job, which can be kilothousands of

lines of text, they requested a new option that

would let them choose to cause the MXG job to ABEND

for these CICS errors that delete data, in addition

to the error message (which will now be the last

thing printed on the log!!).

-RMFINTRV creation (Oct 19,2005):

***ERROR.RMFINTRV.CPUTM IS MISSING.

The CPUTM variable from TYPE72GO dataset is missing

which can be caused by incorrect tailoring in your

EXTY72GO exit member.
This change will be updated if other error messages are

added to this enhancement.

Thanks to Mike Perry, Morgan Stanley, USA.

Thanks to Min-che Li, Morgan Stanley, USA.

Change 23.183 Support for APAR OA11036, which adds MACHTIME to SMF 89

VMAC89 and variables SMF89HOF and SMF89DTO values.

Jul 18, 2005

Thanks to Al Sherkow, I/S Management Strategies, Ltd., USA.

Change 23.182 Test of LENCPUC GE 24 should have been GE 64 to input the

VMAC7072 SMF70HWM and SMF70HOF fields in support for APAR OA11375.

Jul 18, 2005

Thanks to Al Sherkow, I/S Management Strategies, Ltd., USA.