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

it's size, but that turns out fortunate, as the default

sort order defined in MACRO _BDB2ACC in VMACDB2:

SYSTEM QWHSSSID QWHCPLAN QWHCAID QWHSLOCN QWHCCV

QLACLOCN QWHCCN QWACBSC QWHSSTCK,

is just fine for duplicate removal, so it's not "wrong",

but it is NOT the correct order to group all DB2ACCT obs

into their "ACE Group". Instead, the new report uses

uses this sort order (MACRO _XDB2ACC):

SYSTEM QWHSSSID QWHSLOCN QLACLOCN QWHCCV QWHCCN ACE

QWACBSC QWHSSTCK QWHCPLAN QWHCAID

that does correctly sort DB2ACCT into each "ACE Group".

This iteration defines old-style MACROs _Q, _X, _Y, _X

which are used by the MACRO _RDB2ACC that you execute:

// EXEC MXGSASV9

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

//SYSIN DD *

%INCLUDE SOURCLIB(VMACDB2);

_RDB2ACC

This report was used for diagnostic understanding of the

events in DB2 Parallel, and thus is not likely to be used

by many MXG users, but it's there if needed. Also, the

structure of selecting all of a group that has one of

something (DB2 Parallel Transaction, in this case) could

easily be extended to select by some other criteria.
Change 25.168 Using %ANALDB2R(PDB=PDB,PMSTA02=YES); caused VMXGSUM to

VMXGSUM fail with ERROR: VARIABLE STRTTIME NOT FOUND. In this

Aug 17, 2007 one place in ANALDB2R, VMXGSUM was invoked with variable

STRTTIME used in the INCODE's internal DATA/PROC steps,

and it was in the KEEPIN= list, but STRTTIME was NOT in

any of the VMXGSUM output parameters. Now, variables in

the KEEPIN= list are added to the generated KEEP list to

protect for this unique VMXGSUM invocation.

The problem was introduced in MXG 25.04 VMXGSUM changes.

Thanks to Richard Haynes, Blue Cross Blue Shield of Kansas, USA.

Change 25.167 Variable FCUSERID='LOGIN*USER ID*OR NAME' is INPUT and

VMAC119 kept in the TYP11903 dataset.

Aug 16, 2007

Thanks to Jim Kovarik, Aegon, USA.

Change 25.166 Trending example for DB2ACCTP dataset.

TRNDDB2P

Aug 16, 2007

Thanks to Chuck Hopf, Bank of America, USA.

Change 25.165 The IMF FB Program Record is updated with new variables:

VMACCIMS PGMSAD56='SADFLAG5*AND*SADFLAG6'

Aug 14, 2007 FLGSPCHR='PROGRAM*SUBTYPE'

The $MGIMFCS format decodes FLGSPCHR, which is OUTPUT

in both CIMSTRAN and CIMSPROG, but only the first

three values of J, K, or O exist in CICSPROG:

VALUE $MGIMFCS

'O'='O:ODBA'

'J'='J:JMP'

'K'='K:JBP'

'Q'='Q:PSEUDO WFI'

'W'='W:WFI(WAIT FOR INPUT)'

;

SAPEXIT ='SAP*PGM*USING*SAPEXIT?'

OTMATRAN='OTMA*TRAN?'

The offset to SRVCLASS was also corrected.

Thanks to Doug Johnson, Blue Cross Blue Shield of Kansas, USA.
Change 25.164 The _VNDMRJ macro token was missing in the _WNDMRJ part

VMACNDM of the _VARNDM macro definition, so the NDMRJ datasets

Aug 14, 2007 kept ALL MXG VARIABLES IN THE DATA STEP, 7062 variables

to be exact, when NDM code was added to BUILDPDB in ITRM

tests!

Thanks to Chris Weston, SAS Institute, USA.

Change 25.163 Support for Capacity Group analysis. z/OS 1.8 added the

VMAC7072 SMF70GNM='CAPACITY GROUP NAME'

VMXG70PR SMF70GMU='MAXIMUM LICENSE UNITS OF GROUP;

VMXGINIT variables, but Change 24.092 output them in TYPE70, when

Aug 20, 2007 they should have been output in PDB.TYPE70PR dataset, as

they are LPAR-level capacity limits.

-ASUM70PR now creates two new Group Capacity datasets

PDB.ASUM70GC - CEC Totals for each Capacity Group

PDB.ASUM70GL - LPAR Detail within each Capacity Group

Dataset ASUM70GL matches the RMF Group Capacity Report,

while dataset SUM70GC provides the total MSU usage for

each Group, and the percent of Group capacity limit used.

Both new datasets are created with fixed INTERVAL=HOUR,

to match SMF70GMU capacity units of MSU per hour.

Thanks to Jim Dammeyer, State Farm Insurance, USA.
Change 25.162 The final example in comments was missing a close-paren.

UTILBLDP

Aug 12, 2007

Thanks to Trevor Holland, ANZ, AUSTRALIA

====== Changes thru 25.161 were in MXG 25.07 dated Aug 10, 2007=========
Change 25.161 Support for new z/OS 1.9 RMF III and APAR OA17070 fields.

VMACRMFV New variables INPUT from the CFIG3 Header Section are

Aug 9, 2007 added to the ZRBCFI dataset:

CFIRANGE='REPORTING*RANGE*SECONDS'

CFIPONAM='POLICY*NAME'

CFIPOACT='POLICY*ACTIVATION*TIME'

CFIPREQS='NOT ALL*STRUCTURES*CONTAINED'

CFIPREQC='NOT ALL*CONNECTIONS*CONTAINED'

New variables INPUT from the CFIG3 Entry Section are

added to the ZRBCFI dataset:

CFIENSCN='CONNECTED*MVS*SYSTEM*COUNT'

CFIENSTI='STRUCTURE*COUNT*IN*POLICY'

CFIENSTO='STRUCTURE*COUNT*OUT*POLICY'

CFIENTCS='TOTAL*CONTROL*SPACE'

CFIENFCS='FREE*CONTROL*SPACE'

CFIENTDS='TOTAL*DUMP*SPACE'

CFIENFDS='FREE*DUMP*SPACE'

CFIENSCT='SUM WAIT*FREE FOR*SYNCH IMMED'

CFIENFOC='COUNT*OF TIMES*FOR UNSUCCESSFUL'

CFIENFOT='SUM OF*SERVICE*FOR*UNSUCCESSFUL'

CFIENPDE='DEDICATED*PROCESSORS'

CFIENPSH='SHARED*PROCESSORS'

CFIENPWG='SHARED*PROCESSOR*AVERAGE*WEIGHT'

New variables INPUT from the CFIG3 Table Entry Section

are added to the ZRBCFI dataset:

CFISTCOM='MAX*CONNECTIONS*ALLOWED'

CFISTCOT='TOTAL*CONNECTIONS*TO*STRUCTURE*

CFISTCOP='CONNECTIONS*WITH*PROBLEMS'

CFISTQTM='SERVICETM*SUM FOR*QUEUED*REQUESTS.

CFISTFLE='STATUS*FLAGS*EXTENDED'

CFISTRBP='REBUILDPERCENT*IN ACTIVE*CFRM'

CFISTPL ='CF*PREFERENCE*LIST'

CFISTXL ='STRUCTURE*EXCLUSION*LIST'

CFISTETM='STRUCURE*EXECUTION*TIME*SUM'

Change 25.160 Sample reports for Velocity Software data.

ANALXAMR

Aug 9, 2007

Thanks to Robert Obee, IMS Health(R), USA.

Change 25.159 Support for APAR OA12865 for RMF 79 Subtype 9 Device

VMAC79 Activity added variable R799PSM='SUCCESSFUL*PAV*SAMPLES'

Aug 9, 2007 and relabeled variable R799PCT='UNSUCCESSFUL*PAV*SAMPLES'

and now INPUTs R799NDA as 4 bytes instead of 2, so that

variables R799NDA,R799DPB,R799CMR,R799PCT,R799PSM now are

correct, and variable R799CNX6='HYPERPAV*BASE*DEVICE?' is

created.

-RMF II 79 subtype 9 records written at 1 minute intervals

have the accumulated values reset when RMF Monitor I pops

its interval, which caused MXG to set the DIF()'d

values missing; now, only the first observation for each

device will have missing values for the deaccumlations,

since I don't know the prior value from yesterday!

-R799NUX required special handling as it is accumulated

if the device is HyperPav, and is not otherwise.

Thanks to Mike Romeo, Schwab, USA.

Change 25.158 The %QUOTE function had to be replaced with the %BQUOTE

UTILBLDP function, because %QUOTE does not "mask" percent signs,

Aug 8, 2007 and the user-provided text can contain percent signs

that needed to be masked. When a user sets the text

%LET MACKEEP= MACRO _S110 %; and executes %UTILBLDP(...)

this %LET MACBLDP= %QUOTE(&MACKEEP); created the MACBLDP

with MACRO _S110 ) instead of MACRO _S110 % because the

%QUOTE function saw the end of the text as %) and that

pair of adjacent characters are a "special character"

that is, by design, changed to a single paren by %QUOTE.

The %BQUOTE masks these characters that aren't by %QUOTE:

unmarked percent signs

unmatched, unmarked single and double quotation marks

unmatched, unmarked opening and closing parentheses

This issue comes up most often in the %LET MACKEEP= text,

as its usage can have a wide range of character text.

I have previously suggested that when setting MACKEEP to

text that can contain a semicolon, you must use %QUOTE(),

but for old-style macro redefinitions like _S110, there

was no need for the complexity of the %QUOTE() syntax.

And it appears if there happened to be blanks in the

right places, even percent signs could be passed without

either function. Now, if you have semicolons or percents

depending on the context and state of the macro language,

%BQUOTEs may be required in your %LET statements.

Specifically this is required:

%LET MACKEEP=%BQUOTE( MACRO _S110 %) ;

Thanks to Carmen Vitullo, Acxiom IT Outsourcing, USA.

Change 25.157 Change 24.064 added &MXGNOBY operand to circumvent errors

MONTHDSK NOT SORTED, but the invocation of &MXGNOBY was not added

MONTHWEK the WEEKBLDT and MONTHDSK members, where it didn't work!

WEEKBLDT

Aug 6, 2007

Thanks to Randy Parker, Trustmark National Bank, USA.

Change 25.156 The ARRAY LWAI(33) $ LCPUWAI0-9 + were one-byte lengths,

VMAC7072 but ARRAY LDED(33) $ LCPUDED0-9 + were eight bytes long,

Aug 6, 2007 and I cannot see why they are different, but as they are

one-byte variables, their ARRAY statement now explicitly

sets their length with ARRAY xxxx (33) $1;
Change 25.155 Variables created with the SCAN() function are set by SAS

VMACCLAR to character length of $200, even though the input length

VMACNMON is only $128. While I believe SAS should set the output

Aug 6, 2007 length to $128, as WPS does, adding LENGTH statements did

circumvent this SAS problem. Other character handling

functions, like SUBSTR() do set the new variable's length

from the input variable's length.
Change 25.154 PROC MEANS does not pass variable attributes (LENGTH etc)

VMXG70PR to the output dataset unless / INHERIT is added to the

Aug 6, 2007 OUTPUT statement; MXG normally uses %VMXGSUM, which does

specify INHERIT, but the two new PROC MEANS added for the

new IFA/ZIP variables did not specify INHERIT, causing

wrong or blank LENGTH/LABEL/FORMATs for those variables.

Change 25.153 False ERROR: INVALID TYPE42 SUBTYPE 5 RECORD DELETED

VMAC42 were printed because the tests revised by Change 25.095

Aug 3, 2007 should be OFF+LEN GT LENGTH+1 vice GT LENGTH. The

record was valid, but, as the message stated, it was

deleted.

Thanks to Joachim Mayr, Amadeus, GERMANY.

Change 25.152 The analysis of input queue time for Duplicate JOB HOLD

ANALINIT used LASTEND=LAG(JINTTIME) for the start of the input

Aug 3, 2007 queue delay of the next Duplicate JOB NAME, but JINTTIME

is the Start Time of the last job, and, as documented in

Change 12.274, that LAG() function statement

(which returns the value of that variable from the

prior observation)

should have been LASTEND=LAG(JTRMTIME), so that this

job's delay is calculated from the End of Execution of

the prior job.

Thanks to Larry Riggen, OneAmerica, USA.
Change 25.151 The example JCLVMXA invokes PROC MEANS for all datasets,

VMACVMXA that would not normally be executed except for the first

Aug 3, 2007 test, but it failed be cause _MPRCAPC and _MPRCAPM were

not defined (those macro names in lines 20396,20397 were

misspelled). The MONWRITE datasets were correctly built;

Also, MXG 25.06 had a DEBUG=1; statement left from tests

that printed a lot of messages on the SAS log, but with

no impact on the SAS datasets that MXG created.

Thanks to Yaohua Hu, ISO, USA.
Change 25.150 The ASUM70PR summarization could (still!) create PCTCPUBY

VMXG70PR over 100%, if adjacent intervals being summarized had the

Aug 3, 2007 exact same value of STARTIME SMF70GIE and DURATM after

the INTERVAL= operand had reset STARTIME and SMF70GIE.

These DURATM was also incorrect (too small) in these bad

observations, but ALL OTHER VARIABLES ARE CORRECT.

It was the heuristic use of DURATM that seemed to work,

but is now recognized as the culprit, as it failed when

two adjacent DURATMs were identical. Now, by instead

using the OLDSTART, the original unmodified interval

start, and inserting it in internal sorts in place of

DURATM, and testing IF FIRST.OLDSTART vice FIRST.DURATM

there's a clean algorithm for new intervals and this old

recurring problem should be fixed for good.

-Summarization with INTERVAL=SHIFT did not work, because

MXG can not know the duration of each of your shifts, and

message VARIABLE MXGDURTM UNINITIALIZED was printed.

However, if you will add a statement in your IMACSHFT

tailoring member for each shift, that sets then variable

MXGDURTM=nnnnn;, where nnnnn is the duration in seconds

(e.g., MXGDURTM=28800; for an 8-hour shift), then you can

INTERVAL=SHIFT to summarize PDB.ASUM70PR & PDB.ASUM70LP

to your shift definitions.

-Summarization with CECINTRV=SHIFT is also now supported,

proved you tailor IMACSHFT to set MXGDURTM, as above.

The MXG note that SHIFT could not be used is removed.

Thanks to Debby Blackey, HCA HealthCare, USA.
Change 25.149 The SAS/ITRM product (formerly SAS/ITSV) executes MXG to

ADOCITRM create its SAS datasets, but the MXG dataset names are

Aug 2, 2007 changed by ITRM. This member's table maps the ITRM names

to the original MXG dataset name.

Change 25.148 A tutorial on how MXG normally creates SORTed datasets,

ADOCDB2 two exceptions, and an MXG tailoring example that writes

Aug 1, 2007 the DB2ACCTB and DB2ACCTP datasets to separate DDNAMES,

also bypassing their SORTs.

MXG normally builds datasets that are PROC SORTed, and

the sort order can be exploited in subsequent programs

to avoid unneeded sorts. MXG's SORTs specify the NODUP

SAS option, which removes any duplicate SMF records.

However, two datasets, DB2ACCT and CICSTRAN have never

been SORTed by default, as they were always known to be

very large. So their "dataset sort _Sdddddd" tokens,

_SDB2ACC and _SCICTRN, were NOT in the default list of

datasets to be sorted in VMACDB2 and VMAC110 defaults.
With hindsight, I should also have NOT included SORTs of

the DB2 per-buffer (DB2ACCTB) and per-package (DB2ACCTP)

datasets, which now can be as large or larger than, their

DB2ACCT counterpart!

But now that MXG has sorted those datasets by default,

I can not safely remove those SORTs, without high risk

of causing a user program to unnecessarily fail. But,

you can use this MXG tailoring example to write them

to separate DDnames, and bypass their dataset sorts:
// EXEC MXGSASV9

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

//DB2ACCT DD DSN=YOUR.DB2ACCT,DISP=(,CATLG),...

//DB2ACCTB DD DSN=YOUR.DB2ACCTB,DISP=(,CATLG),...

//DB2ACCTP DD DSN=YOUR.DB2ACCTP,DISP=(,CATLG),...

//PDB DD DSN=YOUR.OTHER.DB2.STUFF,DISP=(,CATLG),..

//SYSIN DD *

%LET WDB2ACC=DB2ACCT; /*DDNAME for DB2ACCT */

%LET WDB2ACB=DB2ACCTB; /*DDNAME for DB2ACCTB*/

%LET WDB2ACP=DB2ACCTP; /*DDNAME for DB2ACCTP*/

%LET MACKEEP=

MACRO _SDB2ACB % /*BYPASS DB2ACCTB SORT*/

MACRO _SDB2ACP % /*BYPASS DB2ACCTP SORT*/

;

%INCLUDE SOURCLIB(BUILDPDB);

RUN;
This same tailoring, using a %LET Wdddddd=DDNAME;

statement to name the output DDname for the "Work"

copy of a dataset, and using %LET MACKEEP= as shown to

define MACRO _Sdddddd % (i.e., to a blank value) can be

used for any other large dataset that you want written

to a separate DDNAME, unsorted, as your SMF data is read.

Change 25.147 Almost cosmetic. The IMACxxxx/MACxxxx tokens that were

VMACQACS defined for VMACQACS were the old IMACQAPM/MACQAPM tokens

VMXGINIT from when AS/400 support was in VMACQAPM, and I decided

Aug 1, 2007 to change the VMAC to QACS but still use the QAPM token

so existing AS/400 tailoring wouldn't need to be changed.

However, this is inconsistent for new users, so this

change adds the include of IMACQACS and created MACQACS,

so the expected token names are found, but the old tokens

are still invoked, so existing tailoring still works.

Thanks to Philip Downes, Fortis Bank, BELGIUM.

Change 25.146 Using PDB=SMF could cause ERROR: NO DATASETS TO LOOKUP

ANALRMFR because SPLIT70 changes were not fully implemented.

Aug 1, 2007 A circumvention was to use TYPS7072 first to create the

PDB datasets, and then use PDB=PDB in the %ANALRMFR,

but this change corrects the error.

Thanks to Mike Rounceville, Blue Cross Blue Shield of NC, USA.

Change 25.145 RMF III dataset ZRBLCP might have no observations for

VMACRMFV many LPARs, due to an MXG error in its "SKIP" logic that

Aug 1, 2007 prematurely ended the scan over all LPARs.

The statement SKIP=CPUCPLEN-32-1280; was replaced with

the statement SKIP=CPUCPLEN-LPARPROF-LPARPRLN*LPARPRNR;

Thanks to Erik Torp, IMT Nordic IBM, DENMARK.

Change 25.144 For ASCII execution, the FULLSTIMER option (MXG default)

UPCMEMSZ will print the memory used by each DATA/PROC step. One

Jul 31, 2007 way to determine how much virtual memory is available to

your MXG programs is to execute this new utility

%INCLUDE SOURCLIB(UPCMEMSZ);

which iterates the number of variables allocated in a

temporary array of 32K-length-character-variables so the

array size varies from 150MB up to 3GB. You look on the

log for the last successful step prior to the ERRORs:

FATAL: Insufficient memory to execute data step

program. Aborted during the COMPILATION phase.

NOTE: The SAS System stopped processing this step

because of insufficient memory.

In my Windows/XP system with SAS 9.1.3, that last step

allocated ARRAY TESTMEMSIZE (30000) $32000 _TEMPORARY_;

and used 938,107 kbytes, or 916 MegaBytes

Change 25.143 MXG sets each of the 135 SWAP rate variables in TYPE71 to

VMAC71 a missing value if that field was zero and the field was

VMXGINIT INPUT, but that design is inconsistent with MXG's use of

Jul 29, 2007 missing values. Normally, an MXG variable has a missing

value, a value different from a "zero", when:

- the event didn't happen, like a datetimestamp JSTRTIME

for a JCL error - the job never "started".

- a new variable is not INPUT, because that new product

is not yet installed at your site.

- an old variable that no longer exists (like PERFGRP)

is no longer INPUT because the record segment is no

longer written.

This design is not perfect; if the new variable is INPUT

because it was added to an already-existing-segment, or

if the old variable is still INPUT because it's segment

exists, they will have a zero value instead of a missing

value, but examination of missing values with PROC MEANS

is used in MXG validation and technical support.

Back when these swap rates were added to the TYPE71,

most were zero, but I wanted blanks when PROC PRINTed,

so by setting their zero values to a missing value, and

using an OPTIONS MISSING=' '; statement, SAS printed

blanks instead of a sea of zeros or periods.
Since TYPE71 always been this way, I'm reluctant to make

changes to my default, but new &MXGMISS macro variable is

now defined in VMXGINIT:

%LET MXGMISS = GT 0 ;

and it referenced in VMAC71 for each swaprate with logic

IF variable &MXGMISS THEN variable=variable*INTTIME;

ELSE variable=.'

so you can put this statement in your IMACKEEP or SYSIN

%LET MXGMISS = GE 0 ;

and any zero values will no longer be missing values.

Advanced SAS notes:

a. I first defined MACRO _GT0 GT 0 % in VMAC71 member,

so it could be redefined with the MACKEEP, but its

re-execution caused unrelated code with ' GT 0 ' to

be seen as ' GT 0 0 ', causing compiler errors.

b. I tested IF X &MXGMISS THEN ... syntax for the case

when the variable MXGMISS was not defined, which

would happen if your site (unwisely) has a tailored

VMXGINIT member. Although there are UNRESOLVED

MACRO VARIABLE messages and one NOTE: VARIABLE

MXGMISS IS UNINITIALIZED, the end result

I also discovered that the value of &MXGMISS macro

variable, when it is undefined, is the MXGMISS text,

rather than the blank value I had assumed/presumed!

Thanks to Jerry Urbaniak, Acxiom, USA.
Change 25.142 Change 18.211 identified most _xxxxID macro tokens that

IMACIPAC are "reversed" from the normal _IDxxxx syntax, but that

VMACIPAC change only updated member UTILBLDP so it would know of

Jul 29, 2007 those inconsistent _ID macro names. This change defines

new, "correct" _IDxxxx macro names for those products,

and modifies the SMF Record ID test syntax to

IF ID=_IDxxxx OR ID=_xxxxID THEN DO;
so that your old definition in your IMACKEEP tailoring

with MACRO _xxxxID nnn % does NOT need to be changed, but

more importantly, so that new users who use the expected

MACRO _IDxxxx nnn % will never find out about this MXG

inconsistency. These members were identified:

ARB, DLMN, DMON, HBUF, HURN, IPAC, M204, NSPY, PDSM,

RMDS, ROSC, RTE, SYNC, TSOM, VVDS, WYLA, WYLB, X37.

Thus far, this change has only been made to these xxxx:

IPAC

Thanks to Keith McWhorter, Georgia Technology Authority, USA.

Change 25.141 IBM APAR OA21799 corrects invalid values for SMF78HIX,

VMAC78 the offset to the new-with-HYPERPAV (SMF78HPS) segments

Jul 27, 2007 in RMF 78 Subtype 3 records. The value in SMF78HIX:

-sometimes exceeded the physical record length, causing

the MXG job to ABEND with this error message:
INPUT STATEMENT EXCEEDED RECORD LENGTH
-sometimes pointed to the wrong LCUID. MXG compares the

LCUID/R783ID2 from the old SMF78ASS segment with the

R783HLCU from the new SMF78HPS, and printed messages:
***ERROR.VMAC78 LCUID=002E DOES NOT MATCH R783HLCU=002F
HyperPAV support was shipped by IBM with APAR OA12865.
This change prevents the ABEND without the APAR installed

by validating SMF78HIX before the INPUT of the HYPERPAV

variables. Also, these new HyperPav variables:

R783HLCU R783HCU R783HNAI R783HTIO R783HAIU

R783HCAD R783HIOQ

are set missing when LCUID mismatch or beyond-record-HIX

is detected. Only 10 error messages will be printed.
-The actual records that contained invalid SMF78HIX values

happened to also be "SPLIT 78" records, i.e., multiple

records written for an interval when the data won't fit

in one 32K SMF record.

But split 78 records are not new; even before HyperPav,

records are split if there are more than 80 LCUIDs.

Fortunately, MXG has always created observations in the

TYPE78CF (Configuration, from the SMF78DCS segments, and

TYPE78CU (Control Unit, from the SMF78ASS and SMF78HPS

segments), since split records are fully self-contained

for each group of LCUIDs for those three segments that

create those two datasets.

But, UnFortunately, when 78 records are split, the 588

byte I/O Queue Global segment (pointed to SMF78QDS) is

repeated in each split record, causing duplicate,