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

and the new 133s when they show up in your SMF file:

%LET MACKEEP=

MACRO _NSPYID 132 %

MACRO _IDNDM 133 %

;

%LET MACFILE=

%QUOTE(

IF ID=132 AND LENGTH GE 50 THEN DO;

INPUT @39+OFFSMF MARKER $EBCDIC4. @;

IF MARKER NE 'R5.3' THEN ID=133;

END;

);
%INCLUDE SOURCLIB(BUILDPDB);

(or if you only wanted one or the other, you would

%INCLUDE the TYPSNDM or TYPSNSPY record instead of the

example's BUILDPDB member).
P.S. Yes, the SMF Record ID macro for NETSPY is spelled

backwards. It should be _IDNSPY, like almost every other

_IDxxxx macro names, but it is one of the inconsistent

names. The exact name of the ID macro for each SMF data

record is in the IMACxxxx member for that product, in the

IMACNSPY and IMACNDM members for this example.

Thanks to Aldo Raimondo, Global Value Services, Italy.
Change 20.043 Support for z800 2066 CPUs running OS/390 R2.8, R2.10.

FORMATS These records without the type 70 SMF70WLA field do not

VMXGRMFI have their MSU capacity in their SMF 70 record, causing

Mar 29, 2002 MXG messages "CPU NOT IN TABLE CPUTYPE=2066", causing the

MSU-related variables to be missing in RMFINTRV dataset.

Some non-IBM machines are in the table, but we don't yet

have #CPs nor their SU_SEC value, but if you get one, the

SU_SEC is in the TYPE72/TYPE72GO dataset for the update.

Thanks to Alan Sherkow, I/S Management Strategies, USA.

Thanks to Winnie Pang, Hawaiian Medical Service Association, USA.

Change 20.042 Extraneous last byte '1A'x hex value in ASCII IMACPTF

IMACPTF was translated to '3F'x and could cause SAS 180 syntax

Mar 29, 2002 error. Deleted that byte.

Thanks to John R. MacDonald, Public Works and General Svcs, CANADA.

Change 20.041 Change 19.248 removed ID statement from member ASUMNTIN,

TRNDNTIN but should also have removed the ID statement from the

Mar 28, 2002 TRNDNTIN member.

Thanks to Terry Heim, ECOLAB, USA.

Change 20.040 -UTILEXCL incorrectly generated IF SEGLEFT GE CMODLENG in

IMACICOC the IMACEXCL it created; "CMODLENG" should have been the

IMACPTF expected segment length value, not the variable name.

UTILEXCL -If you enabled IMACICOC, and did NOT have _QOC0109 turned

Mar 25, 2002 on in IMACPTF, the IMACEXCL INPUT statement was out of

Mar 30, 2002 alignment and CICSTRAN was not valid. Since all Omegamon

records now have that old APAR enabled, I have removed it

from the IMACICOC member that was the only place it was

used, and changed the default value in IMACPTF from 0 to

1, just for compatibility.

Thanks to Raff Rushton, Kaiser Permanente, USA.
Change 20.039 The default ASUMDB2A member will fail if variables are

ASUMDB2A DROPed from the input DB2ACCT dataset, but with minor

VMXGSUM tailoring, ASUMDB2A will tolerate dropped variables.

Mar 24, 2002 ASUMDB2A invokes the %VMXGSUM macro, and in ASUMDB2A,

MXG specifies KEEPALL=YES for performance reasons. But

if you remove variables from the input dataset, you need

create a tailored ASUMDB2A member, with these changes to

the %VMXGSUM invocation in that member:

- Change the KEEPALL=YES to KEEPALL=NO in your ASUMDB2A.

- Run the ASUMDB2A against your modified data, and look

for any uninitialized variable messages on the log,

where the view WORK.MXGSUM1.VIEW was used:

NOTE: Variable QTXAPREC is uninitialized.

NOTE: Variable QTXAILMT is uninitialized.

NOTE: Variable QTXANRUN is uninitialized.

NOTE: Variable QWACRINV is uninitialized.

NOTE: Variable THREADTY is uninitialized.

NOTE: Variable DB2PARTY is uninitialized.

NOTE: View WORK.MXGSUM1.VIEW used:

- Those variables are used in the INCODE logic, but are

not in any SUM, MIN, etc. request, so they were not

kept by KEEPALL=NO, so you must add an argument to the

%VMXGSUM invocation to cause them to be kept for the

input phase, with this syntax:

KEEPIN= QTXAPREC QTXAILMT QTXANRUN QWACRINV

THREADTY DB2PARTY,

You cannot (safely) drop the variables in the KEEPIN=

argument, nor can you drop the variables in the SUMBY=

argument, as they are all required for the logic of the

summarization.

Thanks to Diane Eppestine, Southwestern Bell, USA.
Change 20.038 ASUMUOWT builds the PDB.ASUMUOW dataset, using MONITASK

ASUMUOWT from Landmark's TMON/CICS, instead of the CICSTRAN data

VMXGUOW from IBM SMF 110s. Unlike ASUMUOW, the default in the

Mar 23, 2002 ASUMUOWT program creates observations; you only need to

%INCLUDE SOURLCIB(ASUMUOWT); with the correct DDnames:

//DB2ACCT and //MONITASK, and with //ASUMUOW for output,

as shown in the example in the ASUMUOWT member.

The MONITASK values are stored in CICSTRAN variables, but

I could not find 43 CICSTRAN variables in the MONITASK

dataset, so I have just sent the list of those missed

fields to Landmark, and will update this note is any of

them are identified. (All are set missing and listed in

the _SUOWTMO macro in VMXGUOW.)

Thanks to Jacky Kwoka, ATOS Origin, FRANCE.

Change 20.037 The calculation of VELOCPU in TYPE72GO was incorrectly

VMAC7072 calculated when I/O Priority Management is enabled.

Mar 23, 2002 VELOCPU is the velocity calculated if only CPU is enabled

but with IOPM, VELOCPU included I/O effects. Now, the

VELOCPU is recalculated to measure the CPU-only velocity.

Of coure, variable VELOCITY has always been the correct

velocity value - variables VELOCPU and VELOCIOD are only

"what if" calculations of possible velocity values.

Thanks to Pat A. Perreca, Bear Stearns, USA.
Change 20.036 CICS/TS Statistics dataset CICXQ3 (Shared ts queue server

VMAC110 storage, STID=123) fields have been mis-documented in all

Mar 23, 2002 releases, TS 1.3 thru TS 2.2. The Data Areas lists them

May 14, 2002 as RQG(Gets) ,RQF(Fails) ,RQS(Frees) ,RQC(Compress), but

SMF data shows RQG and RQF are equal, and RQS and RQC are

both zero, so I assume that RQF contains Frees instead of

Failures, and so RQS must contain Storage Failures, and

not Frees. The S3ANYRQF/RQS and S3LOWRQF/RQS variable's

labels were corrected to match the observed data values.

May 14: IBM confirms my assumption, and Don found and IBM

confirmed the same problem exists in the Coupling

Facility Data Tables S9ANYxxx and S9LOWxxx) and the Named

Counter Sequence Number Server Statistics (S5ANYxxx and

S5LOWxxx); those variable's LABELs were also corrected.

Thanks to Don Deese, (CPExpert), Computer Management Sciences, USA.
Change 20.035 New %macro that will get the DSNAME of an allocated SAS

VGETDSN Data Library, and if that DSNAME is an MVS Generation

Mar 22, 2002 Data Group (GDG), %VGETDSN will allocate the next new

member (next "Go0ooVoo") dynamically, specifying its UNIT

SPACE, DISP, and ENGINE in the %VGETDSN arguments. And

You can specify JOB= to cause the dynamic creation of the

next GDG to only occur if that Job name invoked %VMXGDSN.

Thanks to Chuck Hopf, MBNA, USA.

Change 20.034 Cosmetic - variable labels. The Dispatcher Variables

VMAC110 DSGSYSW,DSnSYSW, documented as 'Operating System Waits',

Mar 22, 2002 were re-described by IBM as 'Exits from Partition' when

IBM moved the Dispatcher Statistics to STID=60 and added

twelfth and thirteenth TCBs to CICS, and some of those

variables labels were changed. Since the CICS/TS 2.2

Performance Guide still refers to the DSnSYSW fields as

Operating System Waits, the newer labels were removed and

all labels are as before.

Thanks to Gerhard Hellriegel, ???, GERMANY.

Change 20.033 Support for RMF III (RMF VSAM) for Enclave Table ENCG3.

VMACRMFV Only ENCG3 support was actually added by 20.033; the rest

Mar 22, 2002 of the original change was implemented in Change 20.069.

Thanks to Betty Wong, Bank of America, USA.

Change 20.032 Domino R5.04+ DOMBTIME/DOMETIME variables could be wrong,

VMAC108 because the GMT offset field was input as &IB.4. when it

Mar 18, 2002 should have been input as $CHAR4. The actual bad values

depended on your actual GMT offset, but were in the year

2020 if your offset was zero.

Thanks to Bob Furlong, JPM Chase UK, ENGLAND.

Change 20.031 Example Trend member had PDB.DB2STATS syntax, instead of

ANALDB2R WEEK.DB2STATS syntax, but is now correctly using WEEK. as

TRNDDB2S input. Additional typos were corrected

Mar 18, 2002 In TRNDDB2S: QJSTWT should have been QJSTWTB.

Mar 30, 2002 In ANALDB2R: QXSETCR should have been QXSETCRL.

Thanks to Scottt Snyder, First Data, USA.

Thanks to Diane Eppestine, Southwestern Bell, USA.
Change 20.030 Divide by Zero messages (but no error) when TOTBECPP, the

VMACICE total back end capacity, production partition, was zero.

Mar 14, 2002 The calculation of NCL is now protected for zero divide.

Thanks to David Ehresman, University of Louisville, USA.

Change 20.029 A typo changed all lower case "F" values to a blank in

VMAC120 WebSphere DBCS character values (SM120JA8='De ault').

Mar 14, 2002 The many TRANSLATE() statements had '86'x, but should be

SM120xxx=TRANSLATE(SM120xxx,' ','80'X);

which is needed because of the $VARYING and DBCS data.

Thanks to Bill Feeney, Hennepin County, USA.

Change 20.028 -Support for Windows 2000 TNG. PLATFORM name tests for NT

VMACTNG data look for both NTS400I and (new) NTS500I for Win 2K.

Mar 12, 2002 The same NTnnn datasets are created from either version.

Mar 18, 2002 -Both old and new TNG NT records caused ABENDS, because

Mar 25, 2002 SAS does not properly input numbers-with-leading-blanks

Apr 3, 2002 when you mix LIST and non-LIST input modes, and you have

INFILE xxx DLM='' specified. The MXG statement:

INPUT VALUE FLAG $1. @; INFORMAT VALUE 20.;

stored zero in VALUE when its input column was blank.

And BZ20. can not be used - SAS documents that you must

change DLM='' to "something" for the BZ20 informat to

treat blanks as zeros, but MXG logic requires that the

INFILE TNG DLM='' be specified so that it can parse all

of the other data fields in the records.

So the INPUT VALUE FLAG $1. @; logic was revised and is

first input as a variable length string, and then blanks

are detected and skipped before the numeric INPUT.

-Variable DOMAIN kept length increased from $20 to $30 to

keep longer domain names.

-46 character Instance Name of Network Interface value of

'Compaq Ethernet_Fast Ethernet Adapter_Module#1' exceeded

MXG's default of 40, requiring revision to the INSTANCE

handling logic to handle 64 character instance name.

(This last part was only in the Apr 3 dated member).

Thanks to Erling Andersen, SMT Data A/S, DENMARK.
Change 20.027 NDM PNODE and SNODE Account fields are now input and kept

VMACNDM in the NDMCT and NDMRT datasets.

Mar 8, 2002

Thanks to Betra Reeves, (i)Structure, Inc.

Thanks to John Rivera, (i)Structure, Inc.
Change 20.026 The Availability Report example would terminate with no

ANALAVAI output & no diagnostics if no applications were defined

Mar 8, 2002 or failed if the DATASET options was used to change

the name of the output dataset.

Change 20.025 Worked, but only with a KEEPER or DROPER argument used;

VMXG2DTE without both, either invalid syntax error or no SET

Mar 6, 2002 statement was generated.
Change 20.024 -If UNKNOWN FIELD messages were printed on the log when

UTILEXCL UTILEXCL was executed, the created IMACEXCL had extra

VMXGUOW END; statement for each unknown field.

Mar 6, 2002 -MXG expected both ABCODE fields 113 and 114 so it input 8

Mar 7, 2002 bytes into ABCODE; now UTILEXCL is enhanced to create the

Mar 8, 2002 8-byte ABCODE variable as before, from either or both of

the abend code fields, when one or both are found.

-The "ASUMUOW-CRITICAL-ALERT" tests in both UTILEXCL and

added in VMXGUOW did not test for variable "UOWID", so it

was always reported as not being in your CICSTRAN data.

-Variables UOWTIME and UOWIDCHR were not kept when UOWID

was found, causing spurious "ASUMUOW-CRITICAL-ALERT" that

listed those two variables, but not UOWID, as missing.

Thanks to Hailin Wu, Cover-ALL, CANADA.

Thanks to Chris Voris, QRS Corporation, USA.

Thanks to MP Welch, SPRINT, USA.

Change 20.023 ANALDB2R failed if your report request SORT list had only

ANALDB2R one variable. Line 2978 was changed

Mar 6, 2002 from /@1 &SORT2 $CHAR16.

to /@1 ' ' to correct the error.

Thanks to Brad Brewer, Humana Inc, USA.
Change 20.022 The PDBOUT parameter did not work in ANAL94, but now it

ANAL94 does.

Mar 5, 2002
Change 20.021 TYPEIMSA (19.19 only) fails with 180 syntax error; the

TYPEIMSA two statements %%VMXGTIME(... should have only one

Mar 5, 2002 percent sign %VMXGTIME(... in both statements.

Thanks to Yves Terweduwe, CIPAL, BELGIUM.

Change 20.020 Change 19.230 sent the four DCOLLECT datasets to the PDB

DAILYDSN DDname instead of the DATASETS because the 4 lines with

Mar 4, 2002 MACRO _PDCOxxx should have been spelled MACRO _LDCOxxx.

Mar 22, 2002 And the correct SAS dataset name should be:

MACRO _WDCOVOL DCOLVOLS %

MXG 19.19 incorrectly had DCOLDVOL instead of DCOLVOLS.

Thanks to John Muir, Illinois State University, USA.

Thanks to Diane Eppestine, Southwestern Bell, USA.

Change 20.019 SAS Version 8.2 under Windows Professional Service Pack 2

SASV8.CFG fails if there is a directory named "user" under either

VMXGINIT the SAS root, or (in this specific case), under \WINDOWS

Mar 4, 2002 under \SYSTEM32. This error was first reported for unix

Mar 18, 2002 systems under SN-001262 but was reportedly fixed in V8.

That note gave this unix fix: add -user work in your

SASV8.CFG member, which also fixed the error on Windows.

This error surfaces as a DATA SET NOT FOUND when MXG

tries to delete a WORK.xxxxxxxx dataset, but the SAS log

shows the data was written instead to USER.xxxxxxxx

instead. Under MVS, we found the existence of //USER in

the JCL also caused an error, so VMXGINIT was revised to

detect a user option value problem, to change it to work,

to report what we found on the SAS log, and to keep on

truckin' without an error. SAS Usage Note ZZ-yyyy will

document these discoveries.

Thanks to Mark Darvodelsky, Royal SunAlliance Australia, AUSTRALIA.
Change 20.018 HMF Subtypes 29, 30, and 31 variable HMFHDNOD is actually

VMACHMF an IP Address in those subtypes, so new HMFIPADR variable

Mar 1, 2002 is created to decode and display the n.n.n.n ipaddress.

Thanks to Perry Lim, Union Bank of California, USA.

Change 20.017 Using OPTIONS OBS=0 can be useful, but can cause errors.

VMXGSUM You can use OBS=0 to syntax-test your programs, and it is

VMXGRMFI the correct way to create a 'zero-obs' SAS dataset or an

Feb 28, 2002 'zero-obs' SAS data library with multiple SAS datasets,

so you can test subsequent references to datasets and to

variables, and OBS=0 and PROC COPY is the recommended way

to initialize a SAS data library with all datasets, etc.

But: when OPTIONS OBS=0 is used with summary programs

that use %macros, especially %VMXGSUM, it can cause error

messages, because macro variables are not created if the

SYMPUT/SYMGET statements are after SET statements that

don't get executed, so code has to be relocated just to

support OBS=0. We continue to plug holes when we find

them; this change relocated %VMXGOPTR calls to support

OPTION OBS=0 in VMXGSUM and VMXGRMFI, but there is an

alternative for testing: use a DUMMY file as input, so

that all datasets have zero observations, but with the

OPTION OBS=0 being set. On MVS you can do this with JCL

with //SMF DD DUMMY for the input file, or on all SAS

platforms you can use FILENAME SMF DUMMY; to read nil.

And if your need is to actually test, but you don't want

to use much CPU nor disk space, use OPTIONS OBS=5000; to

to restrict the input volume; it is only the exact OBS=0

value that is our nemesis.

Change 20.016 Sample PROC PRINTs of WebSphere SMF 120 data had several

ANAL120 prints bypassed during testing (by adding MACRO __ before

Feb 28, 2002 and a % after the block of code to be bypassed, which is

fine ONLY if there are no percent signs in the code being

bypassed!), but that MACRO and Percent Sign should have

been removed so all PROC PRINTs would execute.

Thanks to Jim Kovarik, AEGON, USA.
Change 20.015 This old report program has ENTITY as an array name, and

ANALRACF under SAS V8.2, a bogus message is printed on the log:

Feb 28, 2002 ERROR: THE PRODUCT WITH WHICH THE FUNCTION/SUBROUTINE

IS ASSOCIATED IS EITHER NOT LICENSED FOR YOUR SYSTEM OR

THE PRODUCT LICENSE HAS EXPIRED. PLEASE CONTACT YOUR

SAS INSTALLATION REPRESENTATIVE.

but there was no real error, and data step was correctly

executed. Once discovered (and with same day service!),

SAS Technical Support Usage Note SN-007039 documents that

the names: ENTITY, GENDER, STDNAME, should not be used as

array names in V8, but those names will be changed in V9,

to protect the innocent. I changed ENTITY to ENTITI to

eliminate the exposure.

Thanks to Clive Talbot, EDS, UK.

Change 20.014 Support for new subype 6 and 7, Mobius RDS InfoPac View

EXIPAC06 Direct Product's user SMF record create new datasets:

EXIPAC07 DDDDDD Dataset Description

IMACIPAC IPAC06 IPAC06 PAGES/HIERARCHY CODE

VMACIPAC IPAC07 IPAC07 ARCHIVE PLACEMENT/LONGEVITY

VMXGINIT

Feb 27, 2002

Thanks to Mary Beth Delphia, Texas Comptroller of Public Accounts, TX

Change 20.013 Enhancements for building "PDB's" from various SMF data

UTILBLDP is enhanced so that datasets can be "ZERO-OBS'ed". This

Feb 27, 2002 is needed if you want to build PDB.ASUM70PR & PDB.ASUMCEC

from SMF, which needs only PDB.TYPE70 and PDB.TYPE72GO

datasets, but the logic in member ASUM70PR also updates

the PDB.RMFINTRV dataset, so it must be created, but with

zero obs for all of the unwanted RMF datasets. Two new

examples in the comments are show here so you can see

that UTILBLDP is a powerful tool if you want to create

particular MXG datasets without running BUILDPDB:

Example 2.

Create PDB.ASUM70PR and PDB.ASUMCEC from SMF 70 and 72s:

%UTILBLDP(OUTFILE=INSTREAM,

USERADD=7072 71 73 74 75 78,

ZEROOBS=71 72 73 74 75 78,

BUILDPDB=NO,

INCLAFTR=RMFINTRV ASUM70PR

);

RUN;

%INCLUDE INSTREAM;

RUN;
Note that by using OUTFILE=INSTREAM, and then by using

%INCLUDE INSTREAM; this example will actually execute

the code that it just built.

Example 3.

Create only PDB.JOBS, PDB.STEPS, and PDB.PRINT from the

SMF 6, SMF 26 (JES2 in this example), and SMF 30 records.

Since PDB.JOBS is the sum of the steps data, you must

create PDB.STEPS to be able to create PDB.JOBS.
%UTILBLDP(OUTFILE=INSTREAM,

USERADD=6 26J2 30,

SORTOUT=NO,

BUILDPDB=NO,

INCLAFTR=BUILD005

);

%INCLUDE INSTREAM;

RUN;
Change 20.012 This report that mimics IBM's IXGRPT1 was wrong in column

ANAL88 headed "NTRY FULL", because variable SMF88ALS was printed

Feb 27, 2002 instead of SMF88EFS; All SMF88ALS were changed to EFS,

Mar 1, 2002 and some report field widths were increased from 5 to 6.

The SORT order now uses SMF88LTD to match IBM's report.

Thanks to Wesley Andrews, Alltel, USA.

Change 20.011 DO NOT USE ML-21 OF THE MXG TAPE MOUNT MONITOR. That

ASMTAPES level of the monitor was included only in the fix1919.zip

Feb 27, 2002 file, but as found to create still more 0E0 ABENDS. The

ASMTAPES member in MXG 20.01 is still at ML-20. A new

Maintenance Level is in development.
Change 20.010 Support for Top Secret V5.2 required only the change of

VMAC80 OR RACFVRSN=051X THEN DO; to

VMAC80A OR RACFVRSN=051X OR RACFVRSN=052X THEN DO;

Feb 25, 2002 While both members were updated, the TYPE80A member

is really the only member to use for SMF 80 RACF records.

Thanks to Chris Taylor, GMAC Insurance, USA.

Change 20.009 Execution of MXG under ASCII only. Some source members

TYPEMOND still had hardcoded informats of IB, PIB, PK, and RB

TYPETMON instead of "&IB.", of "&PIB.", &PK.", and "&RB." macro

TYPEVM variable names, needed for transparent execution of MXG

VMAC33 across platforms. The members that had IB or PIB would

VMAC71 have had incorrect values for those variables if MXG was

VMAC94 was executed under ASCII SAS, and they are listed below.

VMACAXC The other members revised had only PK and RB hardcoded,

VMACFTEK which works fine, but which are now changed so they are

VMACMONI consistent across MXG source, if ever needed.

VMACQTRT Members with PIB or IB:

VMACSTRS Member VARIABLE Notes

VMACTMDB VMAC71 GMTOFF71 - would impact STARTIME

VMACXAM VMACFTEK REASON

Feb 25, 2002 VMACSTRS Many

VMACXAM Several

Thanks to Freddie Arie, TXU, USA.
Change 20.008 Fixes for UTILEXCL and ASUMUOW for CICS after MXG 19.19:

UTILEXCL -ASUMUOW still did not increment SPINCNT, even with Change

VMXGUOW 19.230, but now it does. This had no impact if you left

Feb 21, 2002 the default SPINCNT for ASUMUOW at zero, or if you had

Mar 5, 2002 relatively few "inflight" transactions.

-UTILEXCL caused ASUMUOW to fail, with VARIABLES NOT FOUND

because the utility failed to create 9 CICSTRAN variables

(computed from other variables) that were required by the

syntax of the ASUMUOW program:

UOWTIME UOWIDCHR

CPUTM ELAPSTM IRESPTM TRMCHRCN

WTOTIOTM WTTOIOTM WTUNIOTM

You could circumvent the syntax error in ASUMUOW program

by adding those variables to the list in MACRO _VCICTRN

in the IMACEXCL member you created with UTILEXCL, but

your PDB.ASUMUOW dataset could still be invalid:

Satisfying the syntax above does not satisfy the logic in

ASUMUOW that requires these MXG variables be populated in

CICSTRAN so that matchup by Unit of Work is possible:
Variables required in CICSTRAN to build ASUMUOW

MXG variable IBM CMODHEAD IBM CMODIDNT

TRANNAME TRAN DEC 001

STRTTIME START DEC 005

ENDTIME STOP DEC 006

NETSNAME NETNAME DEC 097

UOWID UOWID DEC 098

UOWIDCHR UOWID DEC 098

UOWTIME UOWID DEC 098

So UTILEXCL is now enhanced and will tell you if you have

excluded fields that are required to run ASUMUOW, and

will list which of the above fields are not in your CICS