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

as an out-of-sequence error in the sort-order validation

that is invoked when there is a BY statement in a DATA

step. The simple correction is to point WEEK1 at the new

PDB, so that the new attributes are seen first and used.

Or you could add a LENGTH OMVSOSI OMVSOPI 5; statement

between the DATA statement and the SET statement.

One other alternative is to remove the BY statement,

since no reports in MXG demand that the TYPE30OM dataset

is in sort order.

When you have DATA ONE; SET TWO THREE FOUR; BY A B C;

the BY statement causes the output dataset to be built

in the A B C sort order of the input datasets, without

invoking a PROC SORT. When there is no BY statement,

dataset ONE will be the concatenation of TWO, THREE,

and FOUR, and won't be sorted. The big advantage of

having the dataset sorted is so you don't have to SORT

in report program that exploit the same sort order.

And if you should invoke PROC SORT to sort an already

sorted dataset, PROC SORT recognizes sorted data and

will bypass an unnecessary sort, saving lots of time

with big datasets.
That was the end of the original text, and there had been

no MXG code changed, until after I added this note:

When you create a dataset with PROC SORT, SAS stores

the BY list in the directory of that dataset, but when

you create an output dataset with a DATA step, you

need to use the SORTEDBY= dataset option to tell SAS

that the dataset is created in that SORT order, so

that subsequent PROC SORTs can be bypassed by SAS.

I then looked at my code; while SORTEDBY= is used in the

BUILDPDB code for datasets created by DATA steps instead

of by PROC SORT, I discovered I had never implemented the

SORTEDBY= dataset option in the weekly and monthly code.

The actual code change made by this MXG Change was to add

SORTEDBY= to each DATA step in the listed MONTHxxx and

WEEKxxxx members, so that SAS can now recognize and

bypass unnecessary sorts of the weekly and monthly PDBs.

-VMXGSUM was revised to set the SORTEDBY= parameter when

it creates its output dataset, whether it uses a DATA

step, or a PROC MEANS to create the dataset. This change

exposed an unanticipated option in ASUM78CF's invocation

of VMXGSUM, which had the dataset options (LABEL=...) in

its OUTPUT= argument, which previously worked but was not

supported (instead, the DSNLABEL= argument is provided in

VMXGSUM for the output dataset label option). While the

ASUM78CF member was revised to use DSNLABEL, VMXGSUM was

revised to detect the existence of a start paren in the

OUTDATA= and will now suppress the addition of SORTEDBY=

so your existing ASUM78CF won't fail. A later revision

will actually parse to the end-paren and insert the

SORTEDBY= list inside your dataset options!

-VMXGSUM revised to protect DATETIME in a SUMBY= list by

moving the DATETIME= list into the SORTEDBY= list.

This will be further enhanced in the next version to move

the SORTEDBY string inside the parens, if possible, but

this eliminated the abend caused by ASUM78CF syntax.

Obscure Note: In this revision it was noticed that

VMXGSUM could ABEND with INVALID DATASET OPTIONS:

- 1. you use dataset options in the OUTDATA=, and

- 2. the final data setp is flagged as unneeded

- 3. PROC MEANS is used to conditionally drop vars:

This happens only if all these are true:

no NORMx, ERASEOUT NE NO, no OUTCODE statement,

no FREQ, no INTERVAL, no NEWSHIFT, SAS V8+.

Has not occurred, it is likely no one is using dataset

options in the OUTDATA= argument, but now documented.

Thanks to MaryBeth Delphia, Texas Comptroller of Public Accounts, USA

Change 20.093 Variables VVROPIND, SMF60FNC, VVRAMAT3 and VVRTPEXT were

VMAC60 not kept in dataset TYPE60. Those variables and VVRSMSFG

Jun 3, 2002 are now input as $CHAR1 instead of $EBCDIC1 (which has no

impact when MXG is executed on MVS, but is required for

hex-containing variables if MXG is executed on ASCII);

all five variables are now formatted $HEX2.

Thanks to Michael E. Friske, Fidelity Systems, USA.
Change 20.092 Major enhancement for TNG support for new Platforms, new

EXTAI006 Objects, and new Variables, plus logic revisions to cover

EXTAI007 new idiosyncrasies in the TNG performance cube data:

EXTAI008 -Platform tests for PLATFORM=:'SOL' and PLATFORM=:'AIX'

EXTAI009 should eliminate dependency on specific platform name.

EXTAI010 -Instance counts were increased where new instances found.

EXTAI011 -Algorithm for text length in the CAPCM Header was found

EXTAI012 to be inconsistent with text length in other records,

EXTNT021 which caused the DOMAIN name to be incorrect; whereas the

EXTNT022 base-26 syntax is used in data records (i.e., '10'=36),

EXTNT023 the Header algorithm has '10'= 10!

EXTNT024 Note: Always look to see if any observations were output

EXTNT025 in the UNKNOWN dataset, and send the performance

EXTNT026 cube to [e-mail] if there are any. If the

EXTNT027 last metric for an object is UNKNOWN, there will be

EXTNT028 zero observations output for that object.

EXTNT029 The complete list of TNG Objects now supported:

EXTNT030 PLATFORM OBJECT MAXIMUM MAXIMUM MXG

EXTNT031 NAME INSTANCE VARIABLES DATASET

EXTNT032

EXTNT033 AIX BUFFER 1 8 AI001

FORMATS AIX CPU 1 5 AI002

IMACTNG AIX PAGING 1 4 AI003

TYPETNG AIX QUEUES 1 4 AI004

VMACTNG AIX SWAPPING 1 1 AI005

VMXGINIT AIX IPC 1 2 AI006

May 27, 2002 AIX SYSTEM-CALLS 1 7 AI007

Jun 3, 2002 AIX FILE-ACCESS 1 3 AI008

AIX FILESYSTEM 1 2 AI009

AIX NETWORK 1 4 AI010

AIX TABLES 1 4 AI011

AIX TERMINAL 1 6 AI012

CIS2500 CISCO 7 130 C2001

CIS2500 MIB-2 34 89 C2002

CIS7500 CISCO 24 166 C7001

CIS7500 MIB-2 34 89 C7002

NT BROWSER 1 20 NT001

NT CACHE 1 27 NT002

NT ICMP 1 27 NT003

NT IP 1 17 NT004

NT LOGICALDISK 5 21 NT005

NT MEMORY 1 27 NT006

NT NBT CONNECTION 8 3 NT007

NT NETBEUI 2 39 NT008

NT NETBEUI RESOURCE 13 3 NT009

NT NETWORK INTERFACE 3 17 NT010

NT OBJECTS 1 6 NT011

NT PAGING FILE 2 2 NT012

NT PHYSICALDISK 3 19 NT013

NT PROCESSOR 2 10 NT014

NT REDIRECTOR 1 37 NT015

NT SERVER 1 26 NT016

NT SERVER WORK QUEUES 3 17 NT017

NT SYSTEM 1 25 NT018

NT TCP 1 9 NT019

NT UDP 1 5 NT020

NT NWLINK IPX 1 38 NT021

NT NWLINK NETBIOS 1 38 NT022

NT NWLINK SPX 1 38 NT023

NT SQLSERVER:ACCESS MET 1 19 NT024

NT SQLSERVER:BUFFER MAN 1 16 NT025

NT SQLSERVER:CACHE MANA 6 4 NT026

NT SQLSERVER:DATABASES 7 21 NT027

NT SQLSERVER:GENERAL ST 1 3 NT028

NT SQLSERVER:LATCHES 1 3 NT029

NT SQLSERVER:LOCKS 6 6 NT030

NT SQLSERVER:MEMORY MAN 1 14 NT031

NT SQLSERVER:SQL STATIS 1 7 NT032

NT SQLSERVER:USER SETTA 10 1 NT033

SOL BUFFER 1 8 SO001

SOL CPU 1 5 SO002

SOL DISK 3 6 SO003

SOL FILE-ACCESS 1 3 SO004

SOL FILESYSTEM 2 3 SO005

SOL IPC 1 2 SO006

SOL KERNEL MEMORY ALLOC 1 8 SO007

SOL MEMORY 1 2 SO008

SOL NETWORK 5 5 SO009

SOL PAGING 1 11 SO010

SOL QUEUES 1 4 SO011

SOL SWAPPING 1 5 SO012

SOL SYSTEM-CALLS 1 7 SO013

SOL TABLES 1 7 SO014

SOL TERMINAL 1 6 SO015

Thanks to Erling Andersen, SMT Data A/S, DENMARK.
Change 20.091 Support for IBM AIX PTX (Performance ToolBox) adds over

VMACAIX 100 new fields, and additional variable name sequences:

May 24, 2002 LABEL STARTS WITH BECOMES VARIABLES NAMED

CPU/ AIXCPU01-AIXCPU21

DISK/ AIXDIS01-AIXDIS56

FS/ AIXFS01 -AIXFS03

IP/NETIF AIXIP01- AIXIP49

LAN/ AIXLAN01-AIXLAN16

MEM/ AIXMEM01-AIXMEM15

NFS/ AIXNFS01-AIXNFS02

PAGSP/ AIXPAG01-AIXPAG05

PROC/ AIXPRO01-AIXPRO02

RPC/ AIXRPC01-AIXRPC04

SYS/ (SYSCALL,SYSIO) AIXSYS01-AIXSYS07

TCP/ AIXTCP01-AIXTCP06

UDP/ AIXUDP01-AIXUDP02

Thanks to Glenn Bowman, Wakefern, USA
Change 20.090 Unknown ESS keys were printed on the SAS log correctly,

IMAC6ESS but MXG did not skip over second and subsequent parms if

May 23, 2002 a key had GEPARMNR GT 1 parameter per key value. The

protection logic now skips correctly and prints the keys

found, but only in the first SMF type 6 record found.

The second part of this change will be the actual decode

GEPARMKY=0021x,2022x,002E segments, as soon as I can find

the new IBM documentation, which ain't easy for ESS data.

Thanks to Roman Jost, ERGO Integration, NORWAY.
Change 20.089 Variable MSU72 is created for each observation in TYPE72

VMAC7072 and TYPE72GO, using the total CPUTM captured:

May 23, 2002 MSU72=CPUTM*SU_SEC/1000000;

Thanks to Jim Horne's posting to MXG-L, Lowe's Companies, USA.

Change 20.088 Support for new Subtypes 27, 28, and 29 for STK HSC/VSM

EXSTCV27 user SMF record create these three new datasets:

EXSTCV28

EXSTCV29 dddddd Dataset Description

FORMATS STCV27 STCVSM27 VTV Scratch Status

IMACSTC STCV28 STCVSM28 VTV Replication

VMACSTC STCV29 STCVSM29 VTV and MVS Unlink Event

VMXGINIT

May 20, 2002

Thanks to Harold Radalin, Reader's Digest, USA.

Change 20.087 Internal macro definition of MACRO _VTYTPMX was added

VMACTPMX as described in the Change 18.338 that had not yet been

May 20, 2002 applied to this member.

Thanks to Lawrence Jermyn, Fidelity, USA.

Change 20.086 New variable EXECAPPL, hopefully the "execution" APPLID

VMXGUOW of the CICS Unit-of-Work observation in PDB.ASUMUOW, will

May 15, 2002 contain the APPLID name of the first region found with a

May 20, 2002 TRANNAME starting with CSxx (expected CSMI for the mirror

transaction). This should be the first AOR that handles

the Unit of Work, after the TOR. If you need more logic

to store an "APPLID" in variable EXECAPPL for a UOW that

uses many APPLIDs, new temp PATH1-PATH10 and TRAN1-TRAN10

variables are created with first ten APPLIDs (PATHs) and

corresponding first ten TRANNAMEs, so you could use them

in your "Case" logic to tailor VMXGUOW. The examples of

Case 1 and 2 were revised and tested, Case 3 example was

deleted.

Thanks to Ron Root, Texas Comptroller of Public Accounts, USA

Change 20.085 Type 119 subtype 3 records caused INVALID DATA message

VMAC119 and were not correctly decoded, because no test records

May 15, 2002 were available. Dataset TYP11903 is now validated.

Thanks to Keith Jefferson, Citicorp, USA.

Change 20.084 Continued picking away at flaws; if you EXCLUDEd WTTCIOTM

UTILEXCL (Terminal Control Wait), UTILEXCL did not create the code

May 15, 2002 statement "IRESPTM=ELAPSTM-WTTCIOTM;" in the IMACEXCL.

May 22, 2002 Now "IRESTPM=ELAPSTM;" is coded if WTTCIOTM is EXCLUDEd,

and since WTTCIOTM is normally zero except in the TOR

records, you should see little difference in IRESPTM.

22May02: Typo 'PSB SCHL' was changed to 'PSB SCHD',

to fix error message with IMS DL/I optional segment.

Thanks to Pat Curren, SuperValu Inc, USA.

Thanks to Richard S. Ralston, Whirlpool Corp. USA.

Change 20.083 Type 79 subtype 12 PIB fields were input as RB, causing

VMAC79 invalid values (and a DOMAIN ERROR on MVS), and new CMG

May 14, 2002 data was not DIF()'d, nor reset. Logic was revised.

Thanks to Dan Doan, Verizon, USA.

=======Changes thru 20.082 were in MXG 20.02 dated May 6, 2002=========
Change 20.082 Support for z/OS 1.3 (COMPATIBLE, except for SMF 42).

VMAC30 IBM changes to SMF records in z/OS 1.3 were compatibly

VMAC42 made (no data inserted), but MXG logic for SMF type 42

May 6, 2002 did ot correctly handle the IBM changes.

May 7, 2002 -New data added in SMF type 30 records:

New CPUCEPTM added to TYPE30_V,TYPE30_4,TYPE30_5,TYPE30_6

dataset; records the CPU time for an address space while

it was Enqueue Promoted, i.e., getting ERV Service Units

at high priority because it owned an enqueued resource,

and had been swapped out.

-New data added in SMF type 42 records:

New variables in dataset TYPE42D1 from subtype 16:

SMF42GAP='DATA CLASS NAME'.

SMF42GAJ='GT 4K CF*CACHE*ACTIVE*STATUS'

Values: blank or GT4ACTIVE, GT4KNOTACT, ALL,

UPDATESONLY, or NONE.

SMF42GRA='RE-DOS'

SMF42GRB='RECURSIVE*RE-DOS'

SMF42GRC='BMF*WRITES'

SMF42GRD='SCM*READ*REQUESTS'

SMF42GRE='SCM*READ REQUEST*CASTOUT*CONTENTIONS'

SMF42GRG='RE-DO*PERCENTAGE'

SMF42GRH='RECURSIVE*RE-DO*PERCENTAGE'

SMF42GRI='SCM*CASTOUT*LOCK*PERCENTAGE'

SMF42GZ8='SMS*DIRECT*WEIGHT'

SMF42GZ9='SMS*SEQUENTIAL*WEIGHT'

SMF42GBN='WLM*SERVICE*CLASS*NAME'

SMF42GBO='WLM*REPORT*CLASS*NAME'

SMF42GBP='SMS*DATA*CLASS*NAME'

-New variables in dataset TYPE42D2 from subtype 16:

SMF42GRL='RE-DOS'

SMF42GRM='RECURSIVE*RE-DOS'

SMF42GRN='BMF*WRITES'

SMF42GRO='SCM*READ*REQUESTS'

SMF42GRP='SCM*READ REQUEST*CASTOUT*CONTENTIONS'

SMF42GRR='RE-DO*PERCENTAGE'

SMF42GRS='RECURSIVE*RE-DO*PERCENTAGE'

SMF42GRT='SCM*CASTOUT*LOCK*PERCENTAGE'

-New variables in dataset TYPE42X1 from subtype 19:

SMF42JN7='WRITE*REQUEST*SYSPLEX*TOTAL'

SMF42JTA='AVG SCM*READ REQUEST*CASTOUT'

SMF42JTB='TOT SCM*READ REQUEST*CASTOUT'

SMF42JTC='AVG SCM*READ REQUEST'

SMF42JTD='TOT SCM*READ REQUEST'

SMF42JTE='CURR PCT*SCM*READ REQUEST*CASTOUT'

SMF42JTF='LOW PCT*SCM*READ REQUEST*CASTOUT'

SMF42JTG='HIGH PCT*SCM*READ REQUEST*CASTOUT'

SMF42JTH='AVG PCT*SCM*READ REQUEST*CASTOUT'

SMF42JTI='AVG*RE-DOS'

SMF42JTJ='TOTAL*RE-DOS'

SMF42JTK='AVG*RECURSIVE*RE-DOS'

SMF42JTL='TOTAL*RECURSIVE*RE-DOS'

SMF42JTM='CURR PCT*RE-DOS'

SMF42JTN='LOW PCT*RE-DOS'

SMF42JTO='HIGH PCT*RE-DOS'

SMF42JTP='AVG PCT*RE-DOS'

SMF42JTQ='CURR PCT*RECURSIVE*RE-DOS'

SMF42JTR='LOW PCT*RECURSIVE*RE-DOS'

SMF42JTS='HIGH PCT*RECURSIVE*RE-DOS'

SMF42JTT='AVG PCT*RECURSIVE*RE-DOS'

SMF42JUA='AVG*INTERVALS*PROCESSED*ACCELERATED'

SMF42JUB='TOT*INTERVALS*PROCESSED*ACCELERATED'

-New variables in dataset TYPE42X2 from subtype 19:

SMF42JP2='INTERVALS*PROCESSED*ACCELERATED'

SMF42JSA='SCM*READ REQUEST*CASTOUT'

SMF42JSB='SCM*READ REQUEST'

SMF42JSC='CURR PCT*SCM*READ REQUEST*CASTOUT'

SMF42JSD='LOW PCT*SCM*READ REQUEST*CASTOUT'

SMF42JSE='HIGH PCT*SCM*READ REQUEST*CASTOUT'

SMF42JSF='AVG PCT*SCM*READ REQUEST*CASTOUT'

SMF42JSG='RE-DOS'

SMF42JSH='CURR PCT*RE-DOS'

SMF42JSI='LOW PCT*RE-DOS'

SMF42JSJ='HIGH PCT*RE-DOS'

SMF42JSK='AVG PCT*RE-DOS'

SMF42JSL='RECURSIVE*RE-DOS'

SMF42JSM='CURR PCT*RECURSIVE*RE-DOS'

SMF42JSN='LOW PCT*RECURSIVE*RE-DOS'

SMF42JSO='HIGH PCT*RECURSIVE*RE-DOS'

SMF42JSP='AVG PCT*RECURSIVE*RE-DOS'

-New SMF 42 subtype 20 is written when STOW INITIALIZE IS

used to delete all members of a PDSE. The new TYPE4220

dataset contains variables:

SMF42KJB='JOB NAME*STC OR*TSO USERID*WHO STOW-D'

SMF42KST='STEP*NAME'

SMF42KPR='PROC*NAME'

SMF42KDS='DATA SET NAME'

SMF42KVS='VOLSER'

-New SMF 42 subtype 21 is written when a member of a PDS

or a PDSE is deleted, with new dataset TYPE4221 vars:

SMF42LJB='JOB NAME*STC OR*TSO USERID*WHO STOW-D'

SMF42LST='STEP*NAME'

SMF42LPR='PROC*NAME'

SMF42LDS='DATA SET NAME'

SMF42LVS='VOLSER'

SMF42LNL='LENGTH*OF MEMBER*NAME'

SMF42LFL='ALIASES*EXCLUDED*DUE TO*RECORD LENGTH'

SMF42LMN='MEMBER*NAME*THAT WAS*DELETED'

-New SMF 42 subtype 21 is also written with the Alias

Names that were deleted because its primary member

name was deleted. New variable description says it all:

SMF42LAN='ALIAS NAME*DELETED IN*SYMPATHY'

-Status:

This change has not been validated with 1.3 data.

IBM additions to RMF 79 Channel data, and additions to

SMF 99 (License Manager) won't be written until I have

test data records.
Change 20.081 z/VM MONWRITE Control Records with DATABYTE=0 caused the

VMACVMXA "WHOOPS ..." error and MXG stopped reading records. IBMs

May 4, 2002 MONWRITE now creates an "E" Event Control Record with

May 14, 2002 DATABYTE=0 that is followed by a data record that MXG did

not expect, since the control record said there were zero

bytes following! Pairs of bad records were found 4 times

in 900 intervals; each bad pair was immediately followed

by a valid pair of an Event Control Record (DATABYTE=20)

and an Event data record with one 20 byte (1.11) segment.

Knowing what IBM writes, this change detects and deletes

both records, and prints a one-line message when any of

these bad DATABYTE=0 records are found and deleted. If

IBM ever corrects these records, it will be noted here.

May 14: IF DEBUG=. THEN DEBUG=-99; changed to DEBUG=.;

Thanks to Pat Curren, SuperValu Inc, USA.

Thanks to Jean Nelson, SuperValu, USA.

Change 20.080 The SMF94VLS (Library Sequence Number) is no longer a

ANAL94 number, but now contains characters ('B1031'), causing

VMAC94 SMF94VLS to have a missing value; and ANAL94 produced

May 2, 2002 no reports if you had selected a Library number. Since

Aug 11, 2002 SMF94VLS is defined as a numeric variable, changing it

to a character variable could cause execution errors in

your perfectly running reports, so new variable SMF94VLC

with LABEL='LIBRARY*SEQUENCE*NUMBER*CHARACTER' is created

in dataset TYPE94, and the ANAL94 program was changed so

you can use the value in your SMF94VLC to select reports

for a specific Library.

Thanks to Oliver H. Richter, American Management Systems, USA.

Change 20.079 Cosmetic. When there is a mismatch between 70s and 72s

VMXGRMFI in building RMFINTRV, the MXG note was enhanced to print

May 2, 2002 the IN71 IN73 IN74 IN75 and IN78 status variables in

addition to the IN70 and IN72, for diagnostic help.

Thanks to Chuck Hopf, MBNA, USA.
Change 20.078 AS400 Version 4.5.0 (but not 5.1.0) had INVALID DATA FOR

VMACQACS variable SYSJDUM in the QAPMSYST dataset because fields

May 2, 2002 SYSDBC and SYSSWC were inserted by the earlier '4.5.0'

May 5, 2002 version. Change the IF ASLEVEL GE '5.1.0' THEN INPUT...

before SYSDBC/SYSSWC to QIF ASLEVEL GE '4.5.0' THEN ....

And PCTCPSBY was wrong; the SYSDBC was changed to SYSSWC

in its equation. And Change 20.004 needs to be applied

to the other two CPU-time-variables JBEDBC and JBTDBC in

both QAPMJOBL and QAPMJOBM datasets; non-zero data values

now show they too are &PD.8.6 rather than documented 8.3.

Thanks to Andre Baltimore, Unigroup Inc. USA.
Change 20.077 If you enabled TIMEBILD/VMXGTIME to change timestamps,

VMAC78 TYPE78 data had incorrect STARTIME; it was converted

May 2, 2002 twice. Remove the STARTIME in the second %VMXGTIME

invocation.

Thanks to Chuck Hopf, MBNA, USA.
Change 20.076 The JCL Procedure examples MXGSAS and MXGSASV8 contained

MXGSAS DISP=(MOD,PASS) for //NULLPDS, as does SAS defaults, but

MXGSASV8 the CA Job Scheduler CA-11 product regards any step with

May 2, 2002 DISP=PASS to be non-restartable (because it cannot tell

JCLTEST6 if that dataset will be referred to in a later step). The

JCLTEST8 DISP=(SHR,PASS) were changed to DISP=SHR, and the NULLPDS

Sep 7, 2002 DD was changed from MOD,PASS to now MOD,DELETE in May.

Updated Sep 7: MOD,DELETE failed in second execution in

SMS site, 213-04. Change back to MOD,PASS avoided that

SMS-induced error, but that site did not have CA-11.

Changing MOD,PASS to NEW,DELETE resolves both the CA-11

and SMS errors, and there is no real need for MOD anymore

(it's a hold-over from pre-SMS days to protect if a real

dataset already existed that would have failed with NEW

but now that all datasets must be cataloged, MOD is not

needed here).

Bottom line:

DISP=(NEW,DELETE) for NULLPDS works for SMS and CA-11

and DISP=SHR instead of DISP=(SHR,PASS) works for CA-11.

Thanks to J.C. Houck, Bank of America, USA.

Thanks to Jesse Gonzales, The Gap, USA.

Thanks to Art Cuneo, Health Care Services Corporation, USA.

Change 20.075 Variable NRTIMES was created with PROC MEANS NOPRINT with

ANALPROG OUTPUT OUT=SUMS N=NRTIMES; VARIABLES CPUTCBTM; but the

May 1, 2002 LABEL for NRTIMES in the output dataset is the label of

the CPUTCBTM variable, which I thought was a SAS error.

However, documentation of V8 INHERIT option does state:

By default the statistics in the output data set

automatically inherit the analysis variable's format

and label. However, statistics computed for N, NMISS,

SUMWGT, USS, CSS, VAR, CV, T, PROBT, SKEWNESS, and

KURTOSIS do not inherit the analysis variable's format

because this format may be invalid.

so INHERIT is working as designed, even though I still

think the LABELs for those listed stats also should not

be inherited. In any event, ANALPROG was re-written to

use %VMXGSUM and to correctly label NRTIMES.

Thanks to Mark McCallum, EDS, USA.

Change 20.074 Support for multiple CICS Versions with Exclude added.

UTILEXCL The IMACEXCL created by UTILEXCL failed with syntax error

Apr 30, 2002 if APPLID had multiple dictionary records from different

releases of CICS. This change supports multiple releases

for the same APPLID, by creating a code block for each

APPLID and CICS version:

ELSE IF APPLID='CICSTNW1' AND SMFPSRVR=53 THEN DO; ...

ELSE IF APPLID='CICSTNW1' AND SMFPSRVR=62 THEN DO; ...

And IMACEXCL will print an ERROR message on the SAS log

(as it reads your SMF data), if it finds a new version

for a CICS APPLID that is already in your list of regions

with excluded fields. Thus to support two CICS Versions,

you only have to run the _BLDDICT with the new version's

dictionary records to create a new PDB.CICSDICT, combine

that with your old PDB.CICSDICT from the old version, and

run _BLDEXCL to create an IMACEXCL that is aware of both

CICS version's excluded variables.

Thanks to Raff Rushton, Kaiser Permanente, USA.

Change 20.073 Under ASCII only, a latent 180 syntax error was triggered

VMXGRMFI and corrected in the macro logic that failed to expand a

Apr 29, 2002 macro variable J due to a missing ampersand.

Thanks to John G. Talafous, Timken, USA.

Change 20.072 Support for TMON/CICS TCE 2.1 (INCOMPATIBLE). Landmark

EXMONPA (now Allen Services) completely restructured all records,

EXMONPI and even changed the version from numeric to character!

EXMONTF HWM/maximum values were removed from some datasets, some