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

- Bits in R791FLG and R792FLG added for temporal

affinity

-TYPE79C - New CMG=3 data added

-TYPE79E - Variables CHPIDTKN and NRCMPTSM now reserved.

-TYPE90 - Support for subtypes 26,27,28,29,30,31,32.

Change 19.175 Statistics reports for multiple intervals used the number

ANALDB2R of intervals as a divisor, incorrectly, but only on one

Sep 25, 2001 summary page, and only for the Long Statistics summary

and trace, PMSTA01/PMSTA03, which are not invoked by

default. It's been this way for some time, suggesting

that a) that page of that report is not very useful, or

b) no user has looked at it that closely until now!

Thanks to Liesbeth Post, KLM, THE NETHERLANDS.

Change 19.174 Two separate sites report errors in SMF type 60 records,

VMAC60 causing INPUT STATEMENT EXCEEDED RECORD error when read.

Sep 21, 2001 Both had VVRTYPE=Z:PRIMARY, but the two SMF records are

Oct 1, 2001 wrong in different ways:

-ENTTYPID=C:CLUSTER record, VVR has impossible value for

offset-to-next-field of 1792 in a 588 byte SMF record:

VVRLOKYL=1792 (0700x located at byte 563) can't be

valid, but the expected fields VVRXSC1 that I tried to

INPUT look like they are there after VVRLOKYL in the

record. Maybe first byte of VVRLOKYL is now a flag

(note '.....11100000000'B value in this record)?

CIRCUMVENTION: This change now compares VVRLOKYL with

LENGTH to prevent INPUT, but when prevented, those

additional fields will have missing or blank values.

-ENTTYPID='A:NON-VSAM', NVR has invalid values in length

and name fields for the Storage Class, Data Class, and

the Management Class names:

VVRSTGLN Length field = 6 , but 8 EBCDIC bytes follow

before the next length:

VVRDATLN Length field = 4 , and 4 bytes do follow, but

only 3 are EBCDIC, final is

'00'x instead of '40'x, and

VVRMGTLN Length field = 6 , but four unprintable hex

bytes are followed by four

EBCDIC bytes.

so the name field variables VVRSTGCL, VVRDATCL, VVRMGTCL

are trashed, as is the VVRSBKUP datetimestamp, whose byte

location is now indeterminate with those invalid length

length fields. My old DSECT ends with VVRSBKUP, but this

record has nearly 200 bytes more data, with several new

TODSTAMP fields that should be new event variables, since

type 60s are frequently used to investigate security

issues about who has access, and who accessed, and when

did they access sensitive data on DASD volumes.

Oct 1, 2001 update to this change text:
I held this as the last change for 19.04, expecting IBM

would supply me with the VVR and NVR "DSECTS" so I could

see if something had been changed, and if so, how to

continue decoding the SMF type 60 records without error.

IBM's official reply to Merrill Consultant's request for

the DSECTS for the SMF type 60 record came from the IBM

DFSMS Vendor Activity manager:
"I've discussed this matter with the developer and since

the VVR and NVR contains proprietary information, we

cannot honour you request to acquire the DSECT for the

VVR and NVR records in the VVDS. Instead, please

contact IBM Service and be prepared to FTP the dump and

the SMF records for analysis. No promises are made as

to how we'll choose to resolve this issue."
Stay tuned for future updates to this bigger problem!
Feb 14: IBM DFSMS refuses to provide documentation of

either the Catalog or the VVDS records. One of the

above IBM errors was fixed by OW51353/OW50528 that

reports creation of defective VVR; it's a shame that

IBM would not let me have the documentation so I could

have detected the bad record and told you the APAR that

you need to correct IBM's error, but I've given up.

Thanks to Lawrence Jermyn, Fidelity, USA.

Thanks to Peter Krijer, National Bank of New Zealand, NEW ZEALAND.
Change 19.173 Invalid SMF type 42 subtype 6 (TYPE42DS) record caused

VMAC42 INPUT STATEMENT EXCEEDED error. OFFDSAM segment started

Sep 19, 2001 data byte 32697 but the record length of 32722 data bytes

left only 26 bytes for the 48-byte Access Method segment.

This change now protects for the short record, printing a

message that bad records were found and missing values

were set for the S42AMxxx variables.

Thanks to Linda Berkley, USPS, USA.

Change 19.172 Moving your EBDCIC SPIN library from an existing BUILDPDB

SPINSORT to run under ASCII versions of SAS will require a re-SORT

Sep 19, 2001 of the SPIN library after it has been XPORT/IMPORTed to

ASCII, or you will get SPINxxxx NOT SORTED errors.

This member has the PROC SORT and BY statements to resort

all of the SPIN datasets.

Thanks to Robert Battilana, Franklin Mint, USA.
Change 19.171 Misspelled variable CSRENTLE was corrected to CSRENTIN,

VMACRMFV and the dataset labels for ZRBCPU and ZRBENC were revised

Sep 14, 2001 in this almost-cosmetic change.

Thanks to ???, ???, ???

Change 19.170 -Dataset TPFFM variable FMIOTIM, unlike the SXxxxxxx wait

VMACTPF variables, should not have been divided by 4096.

Sep 14, 2001 -All accumulated counters in all TPF datasets are now

protected for wrapping (when they exceed their four byte

field max value) using this logic to correct the wrap:

IF . LT FVDATAn LT 0 THEN FVDATAn=FVDATAn+4294967296;

This change was not originally needed, because the TPF

monitor was only permitted to run for a few hours, so the

counters didn't wrap, but now that TPF SYSPROGs/Managers

are seeing how useful it to measure TPF, they permit the

monitor to run all day, and the counters now do wrap!

-In the TPFFV dataset (VFA Database Activity), variable

SLOTNR was replaced with new variable FVDATBAS that has

the Database Number, 1 if there is only one database,

sequentially more when there are more than one.

Thanks to Robert Wilcox, Sabre, USA.

Thanks to Jim Gilbert, Sabre, USA.
Change 19.169 The IBM field name DCVFRAGI should have been used as the

VMACDCOL variable name, but DCVFRAG1 is what I thought it was, but

Sep 10, 2001 now its too late to change the name without impact, so I

added a comment with the DCVFRAGI name for documentation.

Thanks to Moira Hunter, SchlumbergerSema, ENGLAND.
Change 19.168 Change 19.104 missed some SU_SEC variables that should

VMACTMV2 have been stored in 8 bytes now; variables SU_SEC in the

VMAC97 TMON/MVS data, variable THSU_SEC in TYPE97, and variables

VMAC30 RMSU_SEC and LOSU_SEC in some TYPE30xx are now changed.

Sep 10, 2001
Change 19.167 INVALID ARGUMENT TO FUNCTION INPUT caused messages and a

ASUMCACH hex dump on the log, and missing value in R7451RID that

Sep 9, 2001 are now corrected.

Thanks to Chuck Hopf, MBNA, USA.

Change 19.166 The Soft Audit product's records now contain SYSTEM in

VMACSFTA the field location that previously contained STEPNAME.

Sep 9, 2001 New variable SYSTEM and old variable STEPNAME will now

contain the value of that field.

Thanks to Jiann-Shiun Huang, CIGNA, USA.
Change 19.165 Revision; if APPEND=YES was specified and DDIN and DDOUT

VMXG2DTE are not the same, the output will reflect only the most

Sep 9, 2001 current day, and an error was generated.

Thanks to Chuck Hopf, MBNA, USA.

Change 19.164 TMS Audit variables TMAUxxxx have been always missing,

TYPETMS5 the TMVAxxxx variables should never have been created,

VMACTMS5 and labels for some TMAUxxxx/TMVAxxxx variables had

Sep 9, 2001 LAST UPDATE when they should have been LAST AUDIT.

This change revises the creation of TMAUxxxx variables,

(which should be used in place of TMVAxxxx variables)

in your report programs (although the TMVAxxxx variables

are correct and still kept in TMS.TMS so reports work).

Note: The TMVAxxxx variables in your old TMS.TMS data

did have correct values with wrong label. TMVATIME,

for example, contains the Last Audit Date, but now you

should use the TMAUTIME variable instead of TMVATIME.

Thanks to Terry Duchow, United States Postal Service, USA.
Change 19.163 Variable JOBCLASS has always been unique, because it had

ADOC30 valid EBCDIC characters (A-Z,0-9) for real TYPETASK='JOB'

VMAC30 records, but non-printable hex characters ('00'x) for SMF

Sep 9, 2001 type 30 records from non-JOBs (TYPETASK=STC/TSU/OMVS...).

Before variable TYPETASK existed, I thought that keeping

those non-printable values might be useful, so JOBCLASS

used the $CHAR informat to preserve the hex value. But,

under ASCII execution, this causes all values of JOBCLASS

to be unprintable; MXG stores a hex 'C1'x in JOBCLASS for

class 'A', but ASCII requires hex '41'x to print an 'A'!

Then, when IBM added the 8-byte class name field SMF30CL8

years ago, MXG input it in JOBCLAS8 with $CHAR8, adding

logic to use it as JOBCLASS only when it was present:

IF JOBCLAS8 GT ' ' THEN JOBCLASS=JOBCLAS8;

But under ASCII, that test was always true when JOBCLAS8

was blank (EBCDIC '40'x), because that GT ' ' test is

IF '40'x GT '20'x , so JOBCLAS8 was always used, even

when the one-byte JOBCLASS had a non-printable hex value!

The fix: SMF30CL8 is now always present, and it does not

contain unprintable characters, so it is now INPUT into

the JOBCLASS variable (not JOBCLAS8), using $EBCDIC as

the Informat, and "IF JOBCLAS8 GT ' ' test was deleted.

What do you do with existing MXG datasets under ASCII?

I thought you could just use the $EBCDIC format in your

PROC PRINT to display the job class value, but that does

not work under either V6 or V8 under Windows:

DATA; X='C1'x; PUT X $EBCDIC1.;

prints a lower case "e" instead of an "A"

However, you can convert the actual data value in the

JOBCLASS variable in your TYPE30_5 or PDB.JOBS dataset

on your ASCII system, using this data step:
DATA JOBS;

SET PDB.JOBS;

JOBCLASS=INPUT(JOBCLASS,$EBCDIC8.);
The description of JOBCLASS in ADOC30 was updated.

Thanks to Paul Gillis, Pacific Systems Management Pty Ltd, AUSTRALIA.

Thanks to Robert Battilana, Franklin Mint, USA.
Change 19.162 JES3-only. Variable NETNAME, The JES3 DJC (Dependent JOB

BUIL3005 Control) Network ID, is now propagated into PDB.JOBS when

Sep 5, 2001 BUILDPD3 is used to create your JES3-PDB.

Thanks to Graham Cornwell, Donovan Data Systems, ENGLAND.

=Cruised from Nome, Alaska, south to St. Lawrence, St. Matthew, St.

=George in the Pribilofs to Chugulak, and thence west across all of the

=Aleutian Islands to Russia's Bering Island, Kamchatka Peninsula's

=Valley of the Geysers (pronounced "geezers" in Russian), and

=Petropavlovsk on the 340-foot Clipper Odyssey, with "birders" from the

=American Birding Association. Landings each morning via Zodiacs to see

=birds at sunrise, often second island landing in afternoon, phenomenal

=weather (while the Alaskan State wine is "When is this fog going to

=lift?", we had sun on every single day!). And evening lectures on the

=geology, flora and flauna! Saw over 100 bird species, including Steller

=Sea Eagles on their nest, 10 mammals (five whale species!), and bones

=of the extinct Steller Sea Cow. Fantastic naturalist experience,

=especially for this EE!
Change 19.161 MXG 19.03 only. Change DEBUG=1; to DEBUG=.; and those

VMACTNG "AFTER HEADERS _N_=" (harmless) notes won't be printed on

Aug 16, 2001 the SAS log.
Change 19.160 Support for type 42 subtypes 7 and 8 was revised; a six

VMAC42 byte filler is now skipped, the OFFCL calculation was

Aug 16, 2001 corrected, and S42FFN and SMF42CHN are now input variable

length, and converted and translated to be printable

under MVS or ASCII platforms.

Thanks to Richard Fortenberry, Mitsubshi Motor Sales of America, USA.

Change 19.159 While TYPEMBO tested just fine, the TYPSMBO member had

TYPEMBO a type _SDEMBO should be _SMBO, and the VMACMBO member's

VMACMBO definitions of _NMBO and _SMBO were obviously incorrect.

Aug 10, 2001

Thanks to David Bixler, FISERV, USA.
Change 19.158 Support for CISCO Works Blue ISM User SMF record creates

EXCISM01 twelve new datasets, one for each subtype:

EXCISM02 Dataset Description

EXCISM03 CISM01 CISCO ISM ROUTER/SWITCH CPU/MEM'

EXCISM04 CISM02 CISCO ISM CMCC(CIP) CPU/MEM'

EXCISM05 CISM03 CISCO ISM OSA CPU/MEM'

EXCISM06 CISM04 CISCO ISM TN3270 STATISTICS'

EXCISM07 CISM05 CISCO ISM INTERFACE PERF STATS'

EXCISM21 CISM06 CISCO ISM INTERFACE STATISTICS'

EXCISM31 CISM07 CISCO ISM PATH STATISTICS'

EXCISM41 CISM21 CISCO ISM REAL SERVER STATS'

EXCISM42 CISM31 CISCO ISM VIRTUAL SERVER STATS'

EXCISM66 CISM41 CISCO ISM FORWARDING AGENT STAT'

IMACCISM CISM42 CISCO ISM WILD CARD STATISTICS'

TYPECISM CISM66 CISCO ISM ISM EVENT LOG'

TYPSCISM This support is preliminary; only subtypes 01,05,06,66

VMACCISM are decoded and tested, and these issues have just been

VMXGINIT observed from the small data sample:

Aug 6, 2001 - The SYSTEM field in the CISCO SMF record is blank.

- There is an extra undocumented file at the end of

the '01' record, that looks like a percentage?

- Additional '06' fields are documented for FDDI, etc

that won't be decoded until they appear in data.

- The documentation shows 8 fields in the '06' record

after the "OE(" marker (UN,OE,CO,IR,RS,OBF,OBS,TR),

but there are only 7 data fields in the '06' record.

Thanks to Harvey Aviles, SSA, USA.
Change 19.157 The PDB.CICS dataset can be created by either ASUMCICS,

JCLPDB8 which always counts from CICSTRAN, or by ASUMCICX, which

JCLPDB6 will use PDB.ASUMUOW if it exists (i.e, if ASUMUOW was

Aug 6, 2001 both included and member IMACUOW updated to create obs in

PDB.ASUMUOW), but what is counted is quite different:

when PDB.CICS is built from CICSTRAN, it counts all CICS

transaction names separately, since each observation in

CICSTRAN is a separate "CICS" transaction, but if ASUMUOW

is built, it has summarized all of the CICS transactions

in one "Unit-of-Work" into one observation, with only the

"Real" transaction name of that UOW, and thus the counts

in PDB.CICS using ASUMCICX are counts of units-of-work,

not CICS transactions, and only the "Real" TRANNAME will

be in the PDB.CICS dataset built from ASUMCICX.

Thanks to Art Hunter, Penn Mutual Life Insurance Company, USA.
Change 19.156 -Using %VMXGRMFI(IMACWORK=NO) in your RMFINTRV member and

EXRMFINT defining fewer than the default workloads can cause many

VMXGRMFI notes NOTE: VARIABLE OTHnACTV IS UNITIALIZED one set for

Aug 6, 2001 each workload you didn't use, and all of those UNINIT

variables listed are actually created in PDB.RMFINTRV.

The problem was caused by the default LABEL statement in

EXRMFINT, which was there to support the earlier design

in which you defined the workloads in IMACWORK and their

labels in EXRMFINT. With the revised VMXGINIT design,

the labels in EXRMFINT are not needed in my default code,

and are now commented out, as an example if you are still

using IMACWORK=YES and want to change labels.

-MXG 19.03 only. Change 19.105 causes errors if %VMXGRMFI

arguments end with slash before the comma (mis-matched

DO;-END; pair). This change makes the final slash

optional.

Thanks to Nancy R. Brizuela, University of Wyoming, USA.
Change 19.155 Dataset CTLGVSAM, created by reading an exported Catalog,

VMACCTLG had unique variables missing because macros were spelled

Aug 6, 2001 wrong. Folowing _WCTLGVS /* CTLGVSAM */, the statement

after the label should have been _VCTLGVS _KCTLGVS to

match the CTLGVS (was mistyped as _VCTLGDS _KCTLGDS).

Thanks to Barry McQueen, Department of Defense, AUSTRALIA.

Change 19.154 IHDRxxxx exit members exist for each "INFILE" that MXG

IMACFILE reads from, and are taken after the record header or

IHDR110 sub-header, has been INPUT. They exist so that you can

IHDR110S use ID, SUBTYPE, SYSTEM, APPLID, SMFTIME, etc., in these

IHDRCIMS exits to control whether or not MXG creates observations,

IHDRDCOL primarily for ad hoc runs when you want to output just a

IHDREAGL little bit of the input. For example, IHDR110S for CICS

IHDRNTSM Statistics Segments lets you select by STID value to only

IHDRTMDB output to specific a CICxxxxx statistics dataset, and not

IHDRTMO2 waste temporary disk space with unwanted statistics.

IHDRTMV2 These IHDRxxxx members are not new, but this change adds

IHDRTPF a macro variable to each, so that you can alternatively

IHDRVMXA tailor these headers "instream", using this syntax:

IHDRTMDC %LET MACxxxx= %QUOTE( your code );

IHDRIMS instead of having to EDIT/SAVE of the IHDRxxxx member.

IHDRTIMS The IHDR members and their new MACxxxx macro variables:

Aug 2, 2001

IHDRxxxx Macro

Member Name Data Source
IMACFILE MACFILE SMF Record Header, ID, SUBTYPE, etc.

IHDR110 MAC110H CICS 110 Sub-Header, APPLID, etc.

IHDR110S MAC110S CICS 110 Statistics Sub-Sub, STID.

IHDRCIMS MACCIMH IMF/CIMS Record Header

IHDRDCOL MACDCOH DCOLLECT Record Header

IHDREAGL MACEAGH Eagle Header

IHDRNTSM MACNTSH NTSMF Record Header

IHDRTMDB MACTMDH TMON/DB2 Record Header

IHDRTMO2 MACTMOH TMON/CICS Record Header

IHDRTMV2 MACTMVH TMON/MVS Record Header

IHDRTPF MACTPFH TPF Record Header

IHDRVMXA MACVMXH VM/ESA, z/VM Record Header

IHDRTMDC MACTMCH TMON/DBCTL Record Header

IHDRIMS MACIMSH IMS Log Record Header

IHDRTIMS MACTIMH TMON/IMS Record Header
The MACFILE macro has existed for some time; IMACFILE was

the original name for the SMF File Header, but now all

new INFILE exit member names start with IHDR.

Thanks to MP Welch, SPRINT, USA.

Change 19.153 -NTSMF Process object record with NRDATA=27 is supported.

VMACNTSM -Records from Win2000 Servers with older NTSMF versions

Aug 1, 2001 for Indexing Service, Indexing Service Filters, and Site

Aug 3, 2001 Server Authentication Srevice had an unexpected instance

field, which is now expected, but not kept, as there is

no instance field with the current NTSMF version.

Thanks to Jim Quigley, ConEd, USA.
Change 19.152 Variable NCL, Net Capacity Load, the back-end space used

VMACICE is now created in ICEBRGSY and ICEBRGUT dataset (but the

Jul 31, 2001 ICEBRGUT records are generated only if you run a REPORT

SPACEUTILIZATION, daily, and have turned on subtype 7 in

SVAA or IXFP in SYS1.PARMLIB(SMFPARM), so using ICEBRGSY

which is always present is recommended).

Thanks to Rob Gibson, Centrelink, AUSTRALIA.
======Changes thru 19.151 were in MXG 19.03 dated Jul 30, 2001======
Change 19.151 If you use TEMP01/TEMP02/TEMP03 in a VMXGSUM invocation,

VGETENG a non-impacting Warning 413 may result, if those DDs were

VMXGSUM on tape devices that had not been opened. Our open to

Jul 27, 2001 determine the device type of your (optional) TEMPnn DD

Jul 30, 2001 caused the warning when the tape had not been opened.

Those TEMPxx parms were primarily needed before SAS V8

provided good multi-volume support, and are less needed

now, but as sequential format datasets on disk, they can

be striped and hardware compressed, and for VMXGSUM runs

with large volumes of data, they are still very useful.

This change eliminates the 413 warning by first looking

to see if the TEMPnn libname is already open, in which

case we will use its current engine, and if the TEMPnn DD

is not open, we will force the Sequential Engine for you,

and avoid the open that caused the warning. The TEMPnn

options are not used in any MXG VMXGSUM invocations.

Jul 30: Added GLOBAL to VMXGSUM and VIEW MXGENG.

Thanks to Mike Hoey, Ameren, USA.

Change 19.150 Example of TREND summarization for the ASUMCEC dataset,

TRNDCEC similar to TRND70PR trending of ASUM70PR for LPAR/MDF,

Jul 26, 2001 but TRENDCEC is a the hardware CEC/CPC level.

Thanks to Diane Eppestine, Southwestern Bell, USA.

Change 19.149 First 19.03 only. TNG support still had incorrect values

VMACTNG for STARTIME for some PLATFORMS, now corrected on all.

Jul 26, 2001
======Changes thru 19.148 were in MXG 19.03 dated Jul 26, 2001======
Change 19.148 Support for NTSMF V 2.4.2.11 and Windows 2000 changes to

VMACNTSM the SYSTEM and PROCESS objects, including new variables

Jul 26, 2001 for I/O activity at the process level:

Jul 27, 2001 IORDOPRT='IO READ OPERATIONS/SEC'

IOWROPRT='IO WRITE OPERATIONS/SEC'

IODTOPRT='IO DATA OPERATIONS/SEC'

IOOTOPRT='IO OTHER OPERATIONS/SEC'

IORDBYRT='IO READ BYTES/SEC'

IOWRBYRT='IO WRITE BYTES/SEC'

IODABYRT='IO DATA BYTES/SEC'

IOOTBYRT='IO OTHER BYTES/SEC'

READYTHR='READY*THREADS'

Revisions to PROCESS and UNTDISC made Jul 27, 2001.

Thanks to Jim Quigley, ConEd, USA.

Change 19.147 Invalid type 42 subtype 5 record caused INPUT STATEMENT

VMAC42 EXCEEDED RECORD LENGTH and/or DIVISION BY ZERO. This

Jul 26, 2001 record was overlaid after 20,500 bytes, with a dataset

name appearing where there should be no data set name!

Segments thru VOLSER DX0004 (starting at byte 20249) were

valid, but the segment for VOLSER DX0003 (at byte 20409)

contains offsets of S42VTVDO=7 and S42VTVXO=1, when those

offsets must be greater than the current column, or zero,

and subsequent fields are clearly invalid. A heuristic

circumvention based on those observed values will detect

and delete these bad records, while the site contacts IBM

for a correction to their invalid SMF 42-5 record created

by DFSMS 2.1

Thanks to M.J.H. Elbersen, RABOBANK, NL.

Change 19.146 -TNG records with (*) in their object name, such as the NT

FORMATS object "NWLINK IPS(*)(G)" saw the (*) and set TEXT='*'

VMACTNG instead of the expected TEXT='G', causing LENTEXT to be

Jul 25, 2001 missing instead of 16, and deleting that record with an

Jul 27, 2001 MXG note. Now, the scan knows to skip (*) when looking

for the (X) length field.

-Existing Format MGALFA only decoded single base-36 values

for TNG field lengths (1)=1, (A)=10, (Z)=35, but now two

position base-36 characters, (12)=38 are supported when

that value was found for an object length. Values to

(1Z)=71 are now decoded by MGALFA:

-The related tests LENTEXT LE 36 were revised to LE 35,

and a separate test for 36 LE LENTEXT LE 40 was added

due to (10)=36 taking one more position than (Z)=35.

-The revised MGALFA format should not have been used in