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

that only used zAAPs, so the resultant CPUUNITS=0 after

recalculation is correct and not an approximation!

But, if the delta is greater than one CPU second, a

revised warning is printed with the before and after

service unit and cpu time values.

Thanks to Janet Harris, Navistar, USA.

Thanks to Roger Rush, Navistar, USA.
Change 26.076 This JCL example had an extra space on the // EXEC

JCLMQMCI statement and the symbolic WORKNUM instead of WORKVOL.

Apr 23, 2008

Thanks to Gary Green, Dow Jones, USA.

====== Changes thru 26.075 were in MXG 26.02 dated Apr 22, 2008=========
Change 26.075 -MXG logic incorrectly handled back-to-back TYPE21 from

ASUMTAPE different systems in the interleave with TYPETMNT; this

Apr 22, 2008 ultimately caused variable SYSTEM in PDB.ASUMTAPE to have

the wrong system's name for these mount events.

Thanks to Paul Naddeo, FiServ, USA.
Change 26.074 MXG 25.07-MXG 26.01 only. Fewer obs created in TYPE78CU,

VMAC78 even with Change 26.023, which only partially solved the

Apr 22, 2008 MXG error. The test for 58 should have been 56.

Thanks to Shantha Hallett, Capgemini, WALES.

Change 26.073 The SORTEDBY= attribute of DB2 datasets that are created

VMACDB2 by a DATA step (instead of a PROC SORT, which sets the

Apr 20, 2008 SORTEDBY list of BY variables automatically) is added to

DATA steps for DB2STATS, DB2GBPST, and DB2STATB, and for

DB2STAT0 and DB2STAT1, but they are already in DB2STATS.

SAS will bypass a subsequent PROC SORT of a dataset when

its SORTEDBY list matched the requested sort's BY list.
Change 26.072 Example ANALTCP reports adds API (Socket) data report,

ANALTCP corrects the date selection code (it didn't work when

Apr 20, 2008 both BEGTIME and ENDTIME were requested), and the SYSTEM

May 6, 2008 selection is revised for a list of SYSTEMs and to allow

a prefix. Option 'ALL' was added for the DATA selection.

Additional enhancements made on May 6.

Thanks to Steve Clark, DHL IT Services Americas, USA.
Change 26.071 Support for z/OS 10.0 (INCOMPATIBLE due to MXG coding):

VMAC1415 -New triplet in TYPE72GO - INCOMPATIBLE due to MXG test of

VMAC18 NRTRIPLT=7 (protected previous short-record IBM error)

VMAC19 causes zero observations in TYPE72GO without this change.

VMAC30 The new Resource Delay segment is not yet coded, awaiting

VMAC42 test data records; R723RDNX, R723RDNN index/number added.

VMAC7072 -TYPE72GO new CPU times (subset in existing CPUTCBTM):

VMAC71 CPUCRPTM='CPU TIME*AT CHRONIC*CONTENTION' (R723CPDP)

VMAC74 CPUPRMTM='CPU TIME*AT PROMOTED*DISPATCH*PRTY'(R723TPDP)

VMAC78 R723CPDP in TYPE72GO.

VMXGINIT -TYPE74. New variable:

Apr 18, 2008 SMF74CAP - AVAILABLE*VOLUME*CAPACITY*IN CYLINDERS.

Jul 21, 2008 -TYPE1415. New variables:

Aug 22, 2008 SMF14EAV='EAV BAM*DETECTED*EXCP OR*XDAP?'

DEB2XUPF='BSAM*PGFIX*OPTION*SPECIFIED?'

EADSCBOK='DCBEADSCBOK*FLAG*OK*ON?'

-TYPE1718. New variable:

SMF18CON='CONTINUATION*RECORD*INDICATOR*MULT-VOL'

-TYPE19. New variables (actually added in z/OS 1.9):

SMF19CYM='VOLUME*HAS*CYL-MANAGED*SPACE?'

SMF19TRK='TOTAL*TRACKS ON*VOLUME'

SMF19TRM=*TOTAL*TRACKS IN*TRACK-MANAGED*SPACE'

SMF19VLI='VOLUME*SIZE*INFORMATION'

-TYPE30. New variable added (by z/OS 1.9):

SMF30SNF='ZIIP NORMALIZATION FACTOR'

-TYPE42D2. New variable added:

SMF42GBQ='LOCK*STRUCTURE*NAME'

-TYPE4222. New subtype 22 creates new TYPE4222 datset

for DFSMS Audit Record:

JOB ='JOB NAME'

RACFUSER='RACF*USER*ID'

READTIME='READTIME'

S42CNABL='CONTROL*RECORD*ENABLE*FLAG'

S42CSYNC='CATSYNCH*DATETIME*STAMP'

S42GMTOF='LOCAL TIME/DATE OFFSE'

S42JNEXT='NEXT*JOURNAL*RECORD*NUMBER'

S42JRECN='JOURNAL*RECORD*NUMBER'

S42MACTY='ACTIVITY*TYPE'

S42MCUPD='VSI*WHEN*MCUPDACT*SET ON'

S42MFG1 ='SMF42MFG1*FLAG*ONE'

S42MJRN ='JOURNAL*RECORD*AVAIL?'

S42MLIS ='LAST*IN*SET?'

S42VRLTK='VSREL*LAST*CHANGE*TOKEN'

S42VRSCN='CURRENT*VRS*CHANGE*COUNTER'

S42VRSUN='LAST*HSKP*VRS*CHANGE*COUNTER'

S42VSICN='VSI*CONTROL*COUNT'

S42VTSFL='VIRTUAL*TAPE*SERVER*FLAG'

-TYPE4223. New subtype 23 creates new TYPE4223 datset

for DFSMS Security Record:

DSNAME ='DATA*SET*NAME'

DSSNO ='DATASET*SEQUENCE*NUMBER'

JOB ='JOB NAME'

LOCLINFO='LOCAL*INFO'

RACFGRUP='RACF*GROUP'

RACFUSER='RACF*USER*ID'

READTIME='READ*TIME'

S42DEVT ='DEVICE*TYPE'

S42GMTOF='LOCAL*TIME*OFFSET'

S42NACTY='ACTIVITY*TYPE'

S42NSTP ='SECURITY*TYPE'

S42NVER ='RECORD*VERSION*IDENTIFIER'

VOLSEQ ='VOLUME*SEQUENCE*NUMBER'

VOLSER ='VOLUME*SERIAL*NUMBER'

Note: Change 26.187 supports APAR OA25205 which adds

subtype 24 and 25 and adds data to subtypes 20 and 21.

-TYPE71. New variables added:

SMF71CFA='AVG*64BIT*COMMON MEM*OBJS*FIXED RSTORE'

SMF71CFM='MIN*64BIT*COMMON MEM*OBJS*FIXED RSTORE'

SMF71CFX='MAX*64BIT*COMMON MEM*OBJS*FIXED RSTORE'

SMF71COA='AVG*64BIT*COMMON MEM*OBJS*ALLOCATED'

SMF71COM='MIN*64BIT*COMMON MEM*OBJS*ALLOCATED'

SMF71COX='MAX*64BIT*COMMON MEM*OBJS*ALLOCATED'

SMF71CRA='AVG*64BIT*COMMON MEM*OBJS*BACKED RSTORE'

SMF71CRM='MIN*64BIT*COMMON MEM*OBJS*BACKED RSTORE'

SMF71CRX='MAX*64BIT*COMMON MEM*OBJS*BACKED RSTORE'

SMF71CSA='AVG*64BIT*COMMON MEM*AUXSTOR*SLOTS'

SMF71CSM='MIN*64BIT*COMMON MEM*AUXSTOR*SLOTS'

SMF71CSX='MAX*64BIT*COMMON MEM*AUXSTOR*SLOTS'

SMF71SOA='AVG*SHARED*MEM OBJ*ALLOCATED'

SMF71SOM='MIN*SHARED*MEM OBJ*ALLOCATED'

SMF71SOX='MAX*SHARED*MEM OBJ*ALLOCATED'

SMF71SRA='AVG*HI VERT*SHARED*FRAMES BACKED*RSTORE'

SMF71SRM='MIN*HI VERT*SHARED*FRAMES BACKED*RSTORE'

SMF71SRX='MAX*HI VERT*SHARED*FRAMES BACKED*RSTORE'

-TYPE78PA (Private Area for jobs) new variables added:

COBYHWM ='HWM*BYTES 64BIT COMMON 2GB'

COBYMAX ='MAX BYTES*64BIT COMMON*ABOVE 2GB'

COBYMIN ='MIN BYTES*64BIT COMMON*ABOVE 2GB'

COBYNTME='TIME STAMP*OF MIN*64BIT COMMON'

COBYTOTL='TOTAL*SAMPLES*64BIT COMMON 2GB'

COBYXTME='TIME STAMP*OF MAX*64BIT COMMON'

COMOHWM ='HWM*BYTES 64BIT*COMMON'

COMOMAX ='MAX BYTES*64BIT*COMMON'

COMOMIN ='MIN BYTES*64BIT*COMMON'

COMONTME='TIME STAMP*OF MIN*64BIT COMMON'

COMOTOTL='TOTAL*SAMPLES*64BIT*COMMON'

COMOXTME='TIME STAMP*OF MAX*64BIT COMMON'

LGMOHWM ='HWM*BYTES LARGE*MEMOBJ'

LGMOMAX ='MAX BYTES*LARGE*MEMOBJ'

LGMOMIN ='MIN BYTES*LARGE*MEMOBJ'

LGMONTME='TIME STAMP*OF MIN*LARGE*MEMOBJ'

LGMOTOTL='TOTAL*SAMPLES*LARGE*MEMOBJ'

LGMOXTME='TIME STAMP*OF MAX*LARGE*MEMOBJ'

R782MEML='ADDRESS*SPACE*MEMLIMIT*MB'

Change 26.070 Support for SMF 102 IFCID 217 Storage Pool Stats changes.

VMAC102 -Dataset T102S217 new variables (GM existed, relabeled):

Apr 16, 2008 QW0217GA='TOTAL*GETMAINED*STORAGE*ABOVE*THE BAR'

QW0217GM='TOTAL*GETMAINED*STORAGE*BELOW*THE BAR'

QW0217HF='FLAG*BITS*IN THE*HEADER'

QW021764='THE*ABOVE THE*BAR DATA*IS INCOMPLETE'

-The original IFICD=217 record was in error, with triplet

3's data in triplet 2, which MXG protected by hardcoded

tests for the segment length to figure out where is that

data? IBM has increased the 02 segment with +24 blank

bytes, but that caused zero observations in T102U217.

The new 152 Length is now supported, even though no new

data was decoded!

Thanks to Matt Clarke, Charles Schwab & Co., Inc, USA.

Change 26.069 Change 25.109 stored the new (0-65535) UIC values in the

VMAC71 old a (0-2054) variables HIUICAV/HIUICMN/HIUICMX, but

Apr 16, 2008 only HIUICAV=SMF71UAC matched the RMF Paging Report

HIGH UIC (AVG). HIUICMN (MIN) was UAM instead of ULC,

HIUICMX (MAX) was UAX when it should have been UHC.

Thanks to Ray Dunn, CIGNA, USA.

Change 26.068 This MXG utility to "PRINT/CONTENTS/MEANS" all datasets

VMXGPRAL in a SAS Data Library failed with NOCONT=PRINT because

Apr 16, 2008 while PROC CONTENTS NOPRINT is valid, its counterpart

syntax PROC CONTENTS PRINT is NOT valid, and MXG had used

macro variable &NOCONT to set CONTENT's PRINT/NOPRINT.

Thanks to David Schumann, Blue Cross Blue Shield of Minnesota, USA.

Change 26.067 MXG assumed NTHOSTTN in ID=119 ST=21 to be 8-bytes, but

VMAC119 this field at the end of the record is shortened to the

Apr 14, 2008 host name length, and I now see that LEN11903=6, so it is

now used in INPUT NTHOSTTN $VARYING8. LEN11903 @; code.

ERROR: INPUT STATEMENT EXCEEDED RECORD LENGTH occurred.

Thanks to Richard J. Schwartz, State Street Corporation, USA.

Thanks to Kathleen M. Hall, State Street Corporation, USA.
Change 26.066 This MXG SAS utility gets z/OS PDS directory block counts

UTILLPDS one dataset at a time. Added by Change 25.136 with typos

Apr 14, 2008 in comments, its documentation and code matches examples.

The one created dataset is now named UTILLPDS.

Thanks to Jeffrey A. Harder, Indiana Farm Bureau Insurance, USA.
Change 26.065 Support for SAS Version 9.2: Revised August 20.

ANALCNCR The WARNING code issues originally discussed below are

VMXGSUM corrected by SAS Hot Fix F9BA07. See Change 26.189 and

ANALDOS MXG Newsletter FIFTY-TWO, SAS Technical Note 7.

ASUMDOS

ASUMHSM Except for RETURN/CONDITION CODE 4 for SAS V9.2 WARNINGs,

EXTYTPMX (which ONLY impacts z/OS job processing, and ONLY if JCL

TYPEZARA or a scheduling package checks step condition codes):

UTILXRF1

VMACVMXA MXG Software runs without error with SAS Version 9.2.

VMXGUOW and

VMXGINIT MXG Software Version 26.03 eliminates the new WARNING.

Apr 20, 2008 (or Hot Fix F9BA07).

Apr 22, 2008

Aug 20, 2008 SAS V9.2 created a new WARNING message and sets CC=4 for

changes in variable LENGTHs, but the WARNINGs in MXG code

were NOT in error, the length changes were intended, the

output dataset was valid, so these warnings harmless:

"WARNING: Multiple lengths specified for variable XXXXXX"
EXCEPT FOR: a non-zero condition code/return code can

make your z/OS job stream that test condition codes to

ABEND.
MXG has enabled the new-in-SAS-V9.2 VARLENCHK option to

completely eliminate the existence of this WARNING.

(Removed by Change 26.189, Aug 20, 2008).
These warnings (all for numeric variables) primarily

occurred inside VMXGSUM in two different cases:

a. Inside VMXGSUM where PROC MEANS is used to create an

output (summary) dataset. The original MEANS created

8-byte variables with no option to change them, so MXG

shortened numeric variable's stored lengths in a DATA

step after the PROC MEANS (to save disk space).

Now, SAS V9.2 detects that (intentional) decrease in

variable length, and prints the above WARNING.

But ONLY if the LENGTH statement precedes the SET!

If the LENGTH statement is AFTER the SET statement,

the warning is NOT printed, but either before or

after, the numeric variable's LENGTH is changed!

These LENGTH statements were located before the

SET statement, because that is the only location

where the length of a character variable can be

changed; character variable's length are set by

the first assignment or attribute statement.

Since the before-the-SET-location also worked for

numeric variable, all LENGTH change statements

were located there.

But all numeric variables are 8-bytes in memory

and the LENGTH (from the last LENGTH statement)

is only used when the observation is written, and

so relocating the numeric LENGTH changes to be

after the SET statement eliminates the WARNING

and still changes the variable's LENGTH.
b. A JOIN of multiple datasets (SET MON.JOBS TUE.JOBS...)

where a variable has different lengths in different

datasets.

But only if the variable length in the first dataset

is shorter than other lengths. There is NO WARNING

if the largest length is in that first dataset!

This also occurred inside VMXGSUM, when multiple input

datasets are combined in a SET/MERGE/UPDATE/etc., like

TRENDing, where TREND has shortened LENGTHs but the

"NEWTREND" internally had fixed, pre-KEEPLEN LENGTHs.

MXG 26.03 added the KEEPLEN option to PROC MEANS to

eliminate these inside-VMXGSUM-cases.

HOWEVER: EVEN WITH MXG 26.03 AND SAS V9.2 THE WARNING CAN

OCCUR NOW:

a. If you have tailoring members in "USERID.SOURCLIB"

from old MXG versions, that need the same code

revisions to eliminate.
b. In user-written SAS programs, this could actually be a

valid warning that a variable was truncated.

OR AT ANY TIME IN THE FUTURE THE WARNING CAN STILL OCCUR:
c. When an MXG Version that changed variable LENGTHs is

installed, subsequent WEEKLY or MONTHLY jobs create

the WARNING because some PDB's have the old length and

some have the new length, when those multiple datasets

are joined. Previous to V9.2, length were changed

with no WARNING nor CC. Between MXG 24.24 and 25.25

1206 variable's lengths were changed.

Note: installing a new MXG version on the first day of

the week is always safest, i.e., make Tuesday morning

BUILPDB with the new MXG Version, so MON-SUN datasets

are all the same; this will eliminate WEEKLY exposure,

but next MONTHLY is still exposed.

THEREFORE: The only way to prevent job failure due to

the WARNING is that SAS Institute may provide a new

option for SAS V9.2 on z/OS to turn off the setting of

the condition code for this WARNING. When this happens,

MXG will enable that new OPTION by default so that the

length of variables can be changed by MXG without this

failure.
-Discovery of how SAS sets stored LENGTH of a variable.
A DATA step uses the last LENGTH statement to set length

of numeric variables, if there are multiple statements.

An existing numeric's variable's length can be changed in

with a LENGTH statement; that statement can be put BEFORE

or AFTER the SET statement, and can request the length be

be SMALLER or LARGER in size. A 7-byte numeric variable

was increased/decreased before/after with these results:
LENGTH NEW RESULT OUTPUT WARNING

STATEMENT WANTED OUTPUT REQUESTED MESSAGE

LOCATION LENGTH LENGTH LENGTH PRINTED
NUMERIC VARIABLES:
BEFORE SET SMALLER 6 YES,TRUNCATED YES-1

AFTER SET SMALLER 6 YES,TRUNCATED NO

BEFORE SET LARGER 8 YES NO

AFTER SET LARGER 8 YES NO

CHARACTER VARIABLES:
BEFORE SET SMALLER 6 YES,TRUNCATED YES-1

AFTER SET SMALLER 7 NOT CHANGED YES-2

BEFORE SET LARGER 8 YES,INCREASED NO

AFTER SET LARGER 7 NOT CHANGES YES-2

The output lengths are identical between V9.2 and V9.1.3,

so this is not new behavior. But further tests with both

NUMERIC and CHARACTER variables discovered that:
NUMERIC: BEFORE SET SMALLER caused WARNING message and

the length was truncated (as requested).

NUMERIC: AFTER SET SMALLER does NOT print WARNING, but

the variable was truncated (as requested).

NUMERIC: BEFORE or AFTER SET LARGER worked, no WARNING.

CHAR: BEFORE SET SMALLER caused WARNING message but

the length was truncated (as requested).
CHAR: AFTER SET SMALLER does NOT change the LENGTH,

and it prints a different WARNING:

"LENGTH OF CHAR VAR C HAS ALREADY BEEN SET."

i.e., it does not work, yet it still WARNs you.

Interestingly, this WARNING, if length is to be

shortened, does NOT set a condition code, with

either V9.2 or with SAS 9.1.3.
CHAR: AFTER SET LARGER also does NOT change LENGTH,

and it prints that second WARNING,

"LENGTH OF CHAR VAR C HAS ALREADY BEEN SET.",

also not working and yet WARNING you.

Very interesting, this WARNING, if length is to

be increased, DOES set a condition code, with

both SAS 9.1.3 or SAS 9.2.
CHAR: BEFORE SET LARGER worked, no WARNING.
For NUMERICs, the requested LENGTH is always created, so

moving the LENGTH statement to be AFTER the SET statement

will eliminate the V9.2 WARNINGs and create same output.
For CHARs, only BEFORE changes LENGTHs, but BEFORE SMALL

prints the new-in-V9.2 WARNING that sets Condition Code:

There is NO way to shorten a CHARACTER VARIABLE's LENGTH

with V9.2 on z/OS without that warning and setting CC=4.

Neither AFTER SMALL nor AFTER LARGE change LENGTH, and

both print the WARNING: CHAR VAR ALREADY SET, which may

or may not set condition code, but it's a moot point,

since they don't change the variable lengths.

Details of the log messages and condition codes with

test with SAS V9.1.3 and SAS V9.2 on z/OS and Windows:

NUM CHR

1 CC DATA BEFORE76SMALLER; NEW LEN: YES,YES

PC 9.1 NO WARNING

PC 9.2 MULTIPLE LENGTHS SPECIFIED FOR VAR N,C

ZOS 9.1 00 NO WARNING

ZOS 9.2 04 MULTIPLE LENGTHS SPECIFIED FOR VAR N,C

2 DATA AFTER76SMALLER; NEW LEN: YES,NO

PC 9.1 LENGTH OF CHAR VAR C ALREADY BEEN SET.

PC 9.2 LENGTH OF CHAR VAR C ALREADY BEEN SET.

ZOS 9.1 00 LENGTH OF CHAR VAR C ALREADY BEEN SET.

ZOS 9.2 00 LENGTH OF CHAR VAR C ALREADY BEEN SET.

3 DATA BEFORE78LARGER; NEW LEN: YES,YES

PC 9.1 NO WARNING

PC 9.2 NO WARNING

ZOS 9.1 00 NO WARNING

ZOS 9.2 00 NO WARNING

4 DATA AFTER78LARGER; NEW LEN: YES,NO

PC 9.1 LENGTH OF CHAR VAR C ALREADY BEEN SET.

PC 9.2 LENGTH OF CHAR VAR C ALREADY BEEN SET.

ZOS 9.1 04 LENGTH OF CHAR VAR C ALREADY BEEN SET.

ZOS 9.2 04 LENGTH OF CHAR VAR C ALREADY BEEN SET.

VMXGSUM is extensively used in MXG summarization programs

(ASUMxxxx,TRNDxxxx,RMFINTRV,CICINTRV) and in many ANALxxx

report examples. If you have local reports that invoke

VMXGSUM/ANALCNCR, that have LENGTH statements in INCODE=

or OUTCODE= parms, you could generate the WARNINGS. So

TEST your REPORTS!!
This change also eliminated the LNSUMOUT macro variable

in Change 25.248 that was thought needed to eliminate the

warnings. It only worked in simple cases and ended up

with the output variable lengths different than input.

Changes made to MXG members to eliminate this WARNING:
-VMXGSUM was revised internally, adding the KEEPLEN option

in PROC MEANS, to propagate the input length to output.

That option was added back in SAS Version 7, but only now

is it needed to eliminate the WARNINGs inside VMXGSUM in

the MXGSUM1/MXGSUM2/MXGSUM3 temporary datasets.
-VMXGSUM LENGTH statements for NUMERIC variables was moved

after SET statement to eliminate those WARNING messages.

-Other MXG programs listed had PROC MEANS/PROC SUMMARY and

warning messages that are similarly eliminated now.

-ANALCNCR. LENGTH &DEFAULT added to CONCURR2 step.
Specific MXG summary programs that required modifications:
-VMXGUOW Variable TRANNAME was incorrectly set to $8 in

several LENGTH statements, but CICS TRANNAME is

only four bytes long. The output PDB.ASUMUOW

dataset did have TRANNAME $4, but the $8 caused

WARNING messages.

-ASUMDOS LENGTH DEFAULT=&MXGLEN; needed in INCODE= for

variable DATE.

-TYPEZARA Invoked PROC MEANS, rather than VMXGSUM, so the

INHERIT option and &KEEPLEN were added.

Fixed so QA would run; dunno if product exists!

-VMACVMXA PROC MEANS were updated with /INHERIT &KEEPLEN,

and LENGTH statements moved to after SETs.

-UTILXRF1 SAS V9.2 PROC CONTENTS changed the length of

variables LABEL and MEMLABEL to $256, and

MEMNAME/DATASET from $8 to $32, causing this

MXG QA utility to generate WARNINGs due to hard

coded LENGTH statements. The PROC CONTENTS

output variable's length change also causes the

DOCVER step of QA job to print the WARNING,

when creating DOCVERnn by comparing OLD and NEW

version's QA data libraries that have intended

length changes. This is unavoidable, but not

an error, and only occurs in my QA job.

-ANALDOS Last updated 18 years ago. PROC MEANS and PROC

SUMMARY (same code as MEANS) needed INHERIT and

KEEPLEN options added.

-ASUMHSM Variable REQUEST needed LENGTH 8 when created

in a DATA step; it is a datetimestamp.

-EXTYTPMX The 99 optional TPMX User Character variables

are each INPUT with a $VARYING50 statement, but

all are then listed in a default DROP statement

(that you would tailor in this exit member if

you wanted one or more to be kept). But there

was a LENGTH TPMUC1-TPMUC99 $1.; statement, to

minimize disk space if all variables were kept

that generated the WARNING message. That LENGTH

statement is now inside comments.
The following note was superceded by Change 26.189:
-VMXGINIT Enables OPTION VARLENCHK=NOWARN; for SAS V9.2.

This requires a Hot Fix for Phase I Foundation

but the new option will be in Phase II V9.2
The OPTION VARLENCHK was added to Phase I by Hot Fix.

If that OPTION VARLENCHK does not yet exist, on your

SAS V9.2 platform, this note will be printed

NOTE: ARGUMENT 1 TO FUNCTION GETOPTION INVALID,

on the SAS log, but it has no impact, except to tell

you to install that Hot Fix to eliminate that note,

but more importantly to suppress the warning.

Thanks to MP Welch, SPRINT, USA.

Change 26.064 Implementation of Rich Olcott's "The Actuals Map" and the

ANALACTM "WLM Service Goal Summary", as described in his paper,

Apr 12, 2008 "Dimensions of Service - Exploring WLM's Solution Space".

The Actuals Map uses SAS/GRAPH to display a daily graph

of interval service units consumed by each Service Class,

color modulated by quality of service delivered (based on

PERFINDX value: Green LT 0.6, Blue 0.6-1.4, Red GT 1.4).

with the graph arranged top to bottom by the Importance

of that Service Class. The PowerPoint paper is available

at http://regions.cmg.org/regions/mcmg/

Rich%20Olcott%20-%20Dimensions%20of%20Service%20

-%20MCMG%20.ppt

The MXG implementation provides additional features and

creates html output for these reports, and will create a

report for each system, or report each sysplex, etc.

Reese is cited simply because he asked for the report!

Thanks to Rich Olcott, (now) IBM Global Services, USA.

Thanks to Chuck Hopf, Bank of America, USA.

Thanks to Reese Bailey, Progress Energy, USA.
Change 26.063 Only DB2ACCT observations with QWACATYP=4, CICS Attach,

VMXGUOW will be considered for merge with CICSTRAN, and only if

Apr 12, 2008 the UOWTIME is non-missing in the DB2ACCT dataset. Some

DB2ACCT observations that exceeded SPINCNT, because they

had a missing UOWTIME value, were inadvertently output.

Now, they are not output, but are counted and a note is

printed on the log with the number of these DB2ACCT obs