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

Change 29.023 Using GTF input, IFCID 3 (DB2ACCT) observations were not

VMACDB2 output, and a (spurious) INVALID PROD section message was

Feb 5, 2011 printed. The OFFSMF value has to be changed when GTF is

input, but the logic for ID=101 SUBTYPE=0 was incorrect.

Thanks to Tony Curry, BMC, USA.
====== Changes thru 29.022 were in MXG 29.01 dated Feb 4, 2011=========
Change 29.022 After Change 28.146 (MXG 28.04+), Buffer Hit Ratio on the

VMXGDBSS %ANALDB2R(PDB=SMF,...) statistics reports were 100 times

Feb 4, 2011 too large. In MXG-built datasets BPHITRAT is a fraction

(e.g., .952), but in DB2PM reports IBM prints 95.2. But

Change 28.146 incorrectly multiplied by 100 when creating

the PDB.ASUMDBSS dataset, and then ANALDB2R multiplied.

This change restores the correct fractional value in the

ASUMDBSS dataset and lets ANALDB2R still do the multiply.

Thanks to Ron Wells, American General, USA.

Thanks to Rick Brooks, American General, USA.

Change 29.021 Variables SMF89DTO and SMF89HOF were accidentally removed

VMAC89 from dataset TYPE892, and should not have been. Since

Feb 4, 2011 they are needed by Al's LCS Product, MXG 29.01 refreshed.

Mar 12, 2011 Mar 12: Variables SMF89SIF,SMF89LPV,SMF89LCR are kept.

====== Changes thru 29.020 were in MXG 29.01 dated Feb 3, 2011=========
Change 29.020 The definition of MACRO _NEDA, to null all datasets, was

VMACEDA missing the MACRO preceding the _WEDAxxx token.

Feb 3, 2011

Thanks to Scott Barry, SBBWorks Inc, USA.

Change 29.019 Sample ACF2 reports looked for PDB.ACF2ARR when the real

ANALACF2 dataset created by TYPSACF2 is named PDB.ACF2AR.

Feb 3, 2011

Thanks to Vitullo Carmen, State of Delaware, USA.

Change 29.018 Calculation of MEMP for z196 now subtracts the two

ASUM113 counters EXTND152 and EXTND155, per John Burg's SHARE

VMAC113 paper, which I had overlooked since last August.

Feb 3, 2011 BUT: FEB 18: The revised calculation was ONLY in the

Feb 18, 2011 VMAC113 in 29.01; I forgot the calculation is repeated

for the z196 code in ASUM113 until today when it was

discovered, because, without the correction, the RNI

values for z196 were larger than for the same workload

on the z10 when they should be about the same.

Thanks to Meral Temel, Garanti Teknoloji, TURKEY.

Thanks to Adnam Can, Garanti Teknoloji, TURKEY.
Change 29.017 -SERIOUS: MONTHBLD/MONTHBL3/MONTHASC in 28.28 will skip

MONTHBLD reading the last day's PDB library (the JAN 2011 MONTH

MONTHBL3 will be MISSING the MON PDB's observations).

MONTHASC This new statement added by Change 28.324

ADOCMNTH CALL SYMPUT('WEEKDATR',(PUT(LASTDAY,WEEKDATE3.)));

BLDSMPDB MUST be corrected to:

Feb 3, 2011 CALL SYMPUT('WEEKDATR',(PUT(TODAY,WEEKDATE3.)));

That is the permanent correction.

-BUT, to RERUN JAN 2011 NOW, since it is already Feb 2,

you must ALSO replace the existing statement

TODAY=TODAY(); with

TODAY='01FEB2011'D.

just for the JAN REBUILD (and then restore that statement

before you run the next month's build).

MONTHBLx normally must execute on the 1st day of the

next month; but comments in MONTHBLx point to ADOCMNTH,

for instructions on how to rerun on a different day of

the month; as long as you rebuild during this week,

there is no change needed to the JCL for the JOB.

If you don't see this until NEXT week, then you need

to read the instructions for the required JCL change

when you need to rebuild a MONTHly in a later week

than the normal week with the 1st day of the month.

-BLDSMPDB: LIBNAME WEEK1 NOT FOUND when runmnth=yes. Can

be circumvented by adding LIBNAME WEEK1 statement with

this syntax to rebuild JAN 2001:

libname week1 'c:\mxg\week1\';

%bldsmpdb(runday=no,runweek=no,runmnth=force);

An undocumented requirement of VSETMNTH needs WEEK1,

which is now LIBNAME'd to the same directory as WEEK.

-I personally apologize for my failure to validate these

changes made by MXG Change 28.324.

-Cosmetic, but possibly confusing. The %PUT statement

that prints the date selections printed "LT", but the

actual and correct test is for "LE".

Thanks to Robb Hermes, Sentry Insurance, USA.

Thanks to Wanda Prather, FRTIB, USA.
Change 29.016 When the _SMF macro was redesigned to store DB2 IFCID in

VMACSMF SUBTYPE, and READDB2 was revised to generate tests using

Feb 2, 2011 the SUBTYPE instead of IFCID, the _DB2GTF macro was not

updated, so %READDB2(INFILE=GTF,IFCIDS=xxx) failed to

output any observations. Macro _DB2GTF is now revised.

Thanks to Tony Curry, BMC, USA.

Change 29.015 Support for Version 7, which (COMPATIBLY) added three

VMAC115 sets of eight variables providing compression statistics,

Feb 1, 2011 one set for each of the three algorithms, although only

the first algorithm's variables are currently populated.

Thanks to Martyn Jones, Euroclear, BELGIUM.
Change 29.014 A new "exit", macro variable &EOFVMXA, for MWINPUT file,

VMACVMXA it inserted at the EOF of reading that MONWRITE data so

VMXGINIT users can take action if the input file is empty or has

Jan 29, 2011 invalid (no Control Record) contents. MONWRITE data is

ftp'd to the MXG platform, but an ftp failure causes an

empty file, which MXG processes without error, but that

has not observations created; that is reported in MXG's

"SUCCESSFULLY READ" message as having zero records.

This exit allows you to insert your own code to detect

there was a failure and you create your own log message

and then ABORTing the MXG job to externalize the error.

For example, the exit could be used with this syntax:

%LET EOFVMXA=

%QUOTE(

IF NRDRRECS LE 0 OR NRCRTOTL LE 0 OR

NRBYTOTL LE 0 THEN DO;

PUT ' ';

PUT '#####################################';

PUT 'ERROR: Z/VM MONWRITE FILE IS INVALID.';

PUT '#####################################';

PUT '>>>> CONTACT z/VM Support ON-CALL <<<< ';

PUT '#######################################';

PUT '# DETAILS:';

PUT '#######################################';

PUT //" MXG &MXGVERS FOUND THESE COUNTS:"

//+5 'THERE WERE ' NRDRRECS ' MONITOR RECORDS '

//+5 'FROM ' NRCRTOTL ' CONTROL RECORDS WHICH '

//+5 'CONTAINED ' NRBYTOTL COMMA15. ' BYTES, ( '

NRBYTOTL MGBYTES. 'B)';

PUT '#######################################';

PUT '#######################################';

ABORT ABEND 16;

END;

ELSE

);

%INCLUDE SOURCLIB(TYPEVMXA);

-Note that after your DO/END group, the "ELSE" is required

because the exit is inserted ahead of an existing PUT.

-Also note that the first line of the sample PUT statement

has double quotes around the text; this is required so

that the &MXGVERS macro variable's value is printed. With

single quotes only the text MXGVERS would be printed.

Thanks to Frank Bright, MEDCO, USA.

Thanks to Frank Bright, MEDCO, USA.

Change 29.013 -Variable CPCGRPLM in ZRBCPU is only four bytes but MXG

VMACRMFV input as 8 bytes; the commented +4 is moved ahead of the

Jan 30, 2011 input and the informat changed to PIB4.

-Variable LCPUPOLR was incorrectly input from two bits in

the first byte of LCPUCHIN; it is the last bit of first

byte and first byte of second byte (which is now input

and kept as LCPUCHI2).

Thanks to Matthew Chappell, Dept. of Transport Main Roads, AUSTRALIA

Change 29.012 Support for Endeavor Version 14 (INCOMPATIBLE because MXG

VMACENDV did not test the segment length and 20 bytes were added),

Jan 31, 2011 causing many missing variables in ENDVERAC dataset. The

fields added are now decoded and seven variables created.

Thanks to Rob D'Andrea, CIS, ENGLAND.
Change 29.011 Cosmetic. Variables with DATETIME value were stored as

VMACIMS length 5 instead of length 8, which can truncate times

ASUMSYTA up to 4 seconds.

VMACBE91 DATASET MEMBER VARIABLE

VMACCYFU ASUMTAPE ASUMSYTA REALMSMF

VMAC28 BETA91C VMACBE91 BE91CSST

VMACPMTR PERFMETR VMACPMTR STARTIME

VMACPW PWPDPD VMACPW ENDTIME

VMACSHDW PWPDPDI VMACPW ENDTIME

VMACTMVS SHADOW05 VMACSHDW SM05LGTM

VMAC90A TMVSCO VMACTMVS IPLTIME

VMACVMXA TYPE9033 VMAC90A SMF9033T

VMACXAM TYPE9034 VMAC90A SMF9034T

Jan 28, 2011 VXSYTSPT VMACVMXA SRXATOD

XAMSYVSW VMACXAM VQSCTTOD
Change 29.010 Variables NDMPRCNM, NDMPRCNO, and NDMSTEP were not kept

VMACNDM in all datasets where they exist in the "NDMPRC" header

Jan 25, 2011 or in the "Record" data segment; the table in comments at

the top of VMACNDM has been updated with a new column to

identify the datasets that have those variables, and all

datasets that are decoded now contain these variables.

Thanks to Michael Oujesky, Bank of America, USA.
Change 29.009 VMXGUOW fails if //CICSTRAN or //DB2ACCT is on tape, with

VMXGUOW MXG 28.06 thru MXG 28.28, but the error is circumvented

Jan 24, 2011 if you add LIBNAME statements to tell MXG it's on tape:

Jan 31, 2011 //SYSIN DD *

LIBNAME CICSTRAN V9SEQ;

LIBNAME DB2ACCT V9SEQ;

%LET PCICTRN=CICSTRAN;

%LET PDB2ACC=DB2ACCT;

%LET MACKEEP= MACRO _NOOBS % MACRO _YESOBS %

%INCLUDE SOURCLIB(ASUMUOW,ASUMCICX);

-Prior to Change 28.204, VMXGUOW only tested existence of

the _Ldddddd dataset token, but in 28.204, a test for the

existence of that LIBNAME was added (so we could tell you

what you did wrong when you didn't have one). But under

z/OS, if the LIBNAME had not been referenced in this SAS

session, it is not in DICTIONARY, and MXG fell thru to

use WORK for the LIBNAME, but as WORK.CICSTRAN did not

exist (your data was in CICSTRAN.CICSTRAN on tape), MXG

failed with NOT FOUND BY VARIABLES and MXGWARNS.

-In this revision, the EXTFILES table is scanned and if

the &PCICTRN "ddname" is found, _LCICTRN is set to

CICSTRAN. Likewise, _LDB2ACC and _LMONTSK are set to the

normal defaults if not found.

-In all cases, if the LIBNAME pointed to does not exist,

VMXGUOW will still fail.

Thanks to Hugo L. Michel, Prince Georges County, MD, USA.

Change 29.008 -WEEKBLD/MONTHBLD: to eliminate NOTSORTED errors, MXGNOBY

VMXGINIT is now specified in VMXGINIT so there will be no testing

BLDSMPDB of the sort order of the input, and no NOTSORTED error.

Feb 3, 2011 -BLDSMPDB: SORTEDBY=NO is now specified as the default.

(Also, LIBNAME=WEEK1 was in error and changed to WEEK.)

-Previously, you had to define MXGNOBY with this statement

%LET MXGNOBY= MACRO _BY % MACRO _SORTBY % ;

in your //SYSIN DD, to disable the sort testing and the

interleave of input observation in sort order. That will

still work fine, but no longer needed with this change.

Although I can't see a reason why you would want to go

back to the NOTSORTED exposure, you can redefine macro

MXGNOBY as null with this syntax to reinstate sorting:

%LET MXGNOBY= ;

-The exposure occurs when MXG has to change the sort order

of a dataset when it is built, and that dataset with new

sort order is combined in WEEKBLD/MONTHBLD with datasets

that were created with the previous sort order.

-The only reason MXG ever changes the sort order is when

the initial order was insufficient to remove duplicates

with the NODUP option of PROC SORT. Errors can occur if

your old WEEKBLD has the old sort order (TYPE72DL in MXG

28.28), or if MXG failed to update the new order in its

WEEKBLD/MONTHBLD member (DB2STATS in MXG 28.28)

-MXG does not require the WEEKLY and MONTHLY datasets to

be sorted; no report programs should ever expect ordered

data as there is no way to guarantee someone else didn't

sort the dataset after it was first created.

-Building sorted output is only a possible performance

benefit: if subsequent programs happen to use the same

order in their PROC SORT, SAS is smart enough to bypass

the unneeded sort, and that was the original purpose for

creating WEEKBLD/MONTHBLD in sort order. And, because

the "daily" datasets were already sorted, the WEEKBLD and

MONTHBLD programs preserved that sort order with a BY

statement, without re-sorting.

-However, it turns out that disabling the sort order test

and building the output as the concatenation of the input

datasets instead of interleaving observations to preserve

the sort order is a REAL performance benefit: benchmarks

show a reduction of about 12% of the CPU time with the

MXGNOBY enabled.

Change 29.007 Documentation if CICSTRAN variables are EXCLUDEd/DROPPED.

ASUMUOW This isn't new behavior, and has been in place long time.

ASUMCICX For ASUMUOW to execute, these BY-VARIABLES are REQUIRED:

Jan 21, 2011 TRANNAME STRTTIME ENDTIME NETSNAME

UOWID UOWIDCHR UOWTIME

There is no circumvention; ASUMUOW fails without them.

These KEPT variables from CICSTRAN aren't required for

execution, but MXGWARN messages will be printed if

these variables do not exist in your CICSTRAN:

APPLID USER LUNAME SYSTEM TERMINAL USERCHAR

This list is defined in MACRO _KUOWIDC, which you can

redefine to keep only your variables to eliminate the

MXGWARN messages.

For ASUMCICX to execute, these BY-VARIABLES are REQUIRED:

APPLID OPERATOR USER TERMINAL STRTTIME TRANNAME

SYSTEM SHIFT

If any do not exist, ASUMCICX fails.

This list is defined in MACRO _BSUCICS and some can be

removed, but you could end up with useless output if,

for example, you didn't keep STRTTIME.

If some of these variables are not kept, you can redefine

_KUOWIDC and _BSUCICS to list only those that exist.

For example, these variables are removed from CICSTRAN:

USER OPERATOR TERMINAL USERCHAR

Then you would add the MACRO _KUOWIDC and _BSUCICS into

the %LET MACKEEP= in your current JOB:

//UOWCICX EXEC MXGSAS92

//CICSTRAN DD DSN=YOUR.CICSTRAN,DISP=SHR

//DB2ACCT DD DSN=YOUR.DB2ACCT,DISP=SHR

//PDB DD DSN=NEW.ASUMUOW,DISP=(,CATLG),...

//SYSIN DD *

%LET PCICTRN=CICSTRAN;

%LET PDB2ACC=DB2ACCT;

%LET MACKEEP=

MACRO _KUOWIDC APPLID LUNAME SYSTEM %

MACRO _BSUCICS APPLID STRTTIME TRANNAME SHIFT %

MACRO _NOOBS % MACRO _YESOBS %

;

%INCLUDE SOURCLIB(ASUMUOW);

%INCLUDE SOURCLIB(ASUMCICX);

Thanks to Hugo L. Michel, Prince Georges County, MD, USA.

Change 29.006 Variables DVRTBV01-DVRTBV32, Returned Borrowed Volumes,

VMACBVIR were incorrectly formatted $MGBVIPT but $MGBVIPO is the

Jan 21, 2011 correct format to decode when printed.

Thanks to Doug Boettcher, Atco I-Tek, CANADA.

Change 29.005 Documentation of INTERVAL= change in default RMFINTRV.

RMFINTRV INTERVAL=DETAIL in MXG 27.27 became INTERVAL=QTRHOUR in

Jan 19, 2011 MXG 28.01, Change 28.046, in MXG default RMFINTRV member,

but that was not documented, carelessly, but also because

I didn't think anyone used MXG's default RMFINTRV member.

I expected each site to have their own tailored RMFINTRV

with both INTERVAL= and WORKnn= (maps Service Classes to

WORKLOADs) definitions, and thus my default would only be

used by new sites, and only before they read the INSTALL

instructions to tailor those RMFINTRV definitions, so I

could change the interval with impunity. Well, almost!

I replaced DETAIL with QTRHOUR because DETAIL creates an

observation for every RMF start, including those short

interval at each IPL that have VERY high CPU Busy and are

outliers on normal interval graphs and reports, whereas

INTERVAL=QTRHOUR creates equal intervals and smooth data.

But, with DETAIL, you get an observation with the exact

STARTIME of each interval, and if SYNC59 is in use, those

startimes were of 59:00 14:00 29:00 44:00. But SYNC59=YES

is the default for Real Intervals, so changing from the

INTERVAL=DETAIL to INTERVAL=QTRHOUR, for SYNC59 sites,

changed their STARTIMEs to 00: 15: 30: & 45: when they

"dropped-in" MXG 28.28 after MXG 27.27. Tailoring their

RMFINTRV with INTERVAL=DETAIL restored original values.

Change 29.004 ISO format dates with 19990000 for "never expire" are now

VMACEDGR detected and the DATE variable is set missing.

Jan 20, 2011

Thanks to Harald Seifert, Huk-Coburg, GERMANY.

Change 29.003 If you have ancient JCL with //SASAUTOS DD DSN=&&NULLPDS,

VMXGGETM MXG 28.28 UTILGETM ran much longer (10x) because it did

Jan 19, 2011 not read the (new in 28.28) %DATATYP macro function from

the SAS-provided AUTOCALL PDS. The ERROR message didn't

stop the read of the large SMF file, but the message

wasn't the expected APPARENT MACRO %DATATYPE NOT FOUND.

Because of the way %DATATYP was used, the error was:

ERROR: Character operand was found in the %EVAL function

... where %DATATYP(&NRECORD) NE NUMERIC ....

The JCL &&NULLPDS token was removed many MXG versions ago

for unrelated problems and lack of need, but I was not

aware that the &NULLPDS stopped the AUTOCALL search, but

only recent MXG versions actually use macros (%TRIM) from

that library. But the %DATATYP was added ONLY to detect

that you had mistyped an alphabetic text for NRECORD=,

and only in your own %VMXGGETM invocation (UTILGETM has

NRECORD=50), so we shot ourselves in the foot adding it.

And ONLY to prevent a less-than-clear warning message.

DATATYP is no longer used; the logic is in a data step.
Change 29.002 -APAR OA31615 was NOT supported by MXG 28.28 as claimed.

VMAC89 That APAR will cause many INVALID SMF89CTZ log messages,

Jan 20, 2011 but the job does NOT ABEND (unless the log fills!).

Jan 21, 2011 -MXG detection of records with Invalid Intersect Segments

Feb 3, 2011 had no limit on the number of Invalid Record messages,

but also falsely detected some valid records as invalid.

The MXG test was corrected so only true Invalid segments

are detected, and only the first 3 are printed on log.

-But, feedback from IBM has clarified the new intersect

data in new TYPE89I dataset, and MXG was wrong to carry

the PRODxxxx variables from the Usage Data Section; those

variables were removed from the KEEP= list, and from the

Sort Order in MACRO _BTY89I, which now uses the CPO-CPI

and IPO-IPI variables to order and remove duplicates, and

is sequenced SMF89UST SMF89IST within those variables.

-Unrelated to the APAR, these variables in subtype 2 have

never been populated and are no longer kept in TYPE892:

MACHTIME SMF89UET SMF89UST

Thanks to Jim Poletti, Edward D. Jones, USA.

Thanks to Jeana M. Bechtel, Edward D. Jones, USA.

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

Thanks to Scott Barry, SBBWorks Inc, USA.

Thanks to Harald Seifert, Huk-Coburg, GERMANY.
Change 29.001 Support for SMF 111 IPIC now creates obs in TY111CXI.

VMAC111 No observations were created because MXG incorrectly had

Jan 19, 2011 them to be in CTGRECID=2 when they are CTGRECID=7, so the

Jan 24, 2011 code for IPIC was relocated to that correct subtype, and

obs are now created.

-Warning added when a new subtype is detected.

-Change 28.329 for SMF 111 was NOT included in 28.28 as

originally claimed.

Thanks to Jim Poletti, Edward D. Jones, USA.

Thanks to Jeana M. Bechtel, Edward D. Jones, USA.

Thanks to Gordon E. Griffith, Edward D. Jones, USA.
LASTCHANGE: Version 29.

=========================member=CHANGE28================================

/* COPYRIGHT (C) 1984-2011 MERRILL CONSULTANTS DALLAS TEXAS USA */
Annual MXG Version 28.28 is dated Jan 18, 2011, thru Change 28.331.

MXG Newsletter FIFTY-SEVEN is dated Jan 18, 2011.

Prelim MXG Version 28.28 was dated Jan 12, 2011, thru Change 28.326.

Interim MXG Version 28.09 was dated Jan 11, 2011, thru Change 28.325.

MXG Version 28.08 was dated Dec 13, 2010, thru Change 28.297.

MXG Version 28.07 was dated Nov 5, 2010, thru Change 28.265.

MXG Version 28.06 was dated Oct 7, 2010, thru Change 28.239.

MXG Version 28.05 was dated Aug 18, 2010, thru Change 28.187.

MXG Newsletter FIFTY-SIX was dated Aug 18, 2010.

First MXG Version 28.05 was dated Aug 17, 2010, thru Change 28.186.

MXG Version 28.04 was dated Jul 5, 2010, thru Change 28.152.

MXG Version 28.03 was dated May 25, 2010, thru Change 28.114.

MXG Version 28.02 was dated Apr 14, 2010, thru Change 28.081.

MXG Version 28.01 was dated Mar 9, 2010, thru Change 28.047.

MXG Version 27.27 was dated Jan 20, 2010, thru Change 27.361.

MXG Version 27.27 was the 2010 "Annual Version".

MXG Newsletter FIFTY-FIVE was dated Jan 20, 2010.
Instructions for ftp download can be requested by using this form:

http://www.mxg.com/Software_Download_Request

Your download instructions will be sent via return email.
Contents of member CHANGES:
I. Current MXG Software Version 28.28 is available upon request.

II. SAS Version requirement information.

III. WPS Version requirement information.

IV. MXG Version Required for Hardware, Operating System Release, etc.

V. Incompatibilities and Installation of MXG 28.28.

VI. Online Documentation of MXG Software.

VII. Changes Log
Member NEWSLTRS contains Technical Notes, especially APARs of interest

and is updated with new notes frequently. All Newsletters are online

at http://www.mxg.com in the "Newsletters" frame.
Member CHANGES contains the changes made in the current MXG version.

Member CHANGESS contains all changes that have ever been made to MXG.

All MXG changes are also online at http://www.mxg.com, in "Changes".
=======================================================================

I. MXG Version 28.28 dated Jan 18, 2011, thru Change 28.331.

Major enhancements added in MXG 28.28, dated Jan 18, 2011
TYPEDB2 28.326 Invalid DB2 V10 Distributed Header protected in MXG.

There will be an IBM APAR, but this change is needed

to avoid the ABEND with earlier MXG versions, so, now

MXG 28.28 IS NOW REQUIRED FOR DB2 V10.1

to ensure your daily jobs doesn't ABEND.

APAR PM32425 has been opened, no PTF as of Feb 21.

WEEKBLD 28.324 Weekly exposure to DATASET TYPE72DL NOT SORTED.

MONTHBLD 28.324 Monthly exposure to DATASET TYPE72DL NOT SORTED.

BLDSMPDB 28.324 BLDSMPDB exposure to DATASET TYPE72DL NOT SORTED.

-If you have tailored those members and TYPE72DL is

built, you need to EDIT those members per the text

in that Change to avoid the possible ABEND of your

weekly or monthly build jobs.
EXITCICS 28.298 EXITCICS decompresses SMF 100,101,102,110 and 112.