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

Thanks to Matt Martin, USPS, USA

Thanks to Craig Collins, State of Wisconsin, USA.

Change 21.030 Protection added for subtype 8 record with NRSEGS=295

VMACICE (295*128 = 37760, which cannot fit in 32760 LRECL) while

Mar 7, 2003 reporting site contacts STK for a fix.
Change 21.029 MXG Newsletter FORTY cited APAR PQ56039, which supposedly

VMAC116 corrected invalid values for many of the MQMQUEUE fields,

Mar 7, 2003 in particular the WQMAXLAT and WQTOTLAT fields. However,

data records with very large values (168 hours plus) at

one site, and "large values" at another site are still

under investigation, which uncovered these unrelated

changes: The label for WQTOTUSE was corrected to be

WQTOTUSE='TOTAL*API CALLS*USING THIS*QUEUE', and the test

for the three PMS fields tests is LENWQ GE 588 instead of

the old test for 592.

Change 21.028 Early V8-V9 comparisons were flawed because CONFIGV8 did

CONFIGV9 not collect statistics, but CONFIGV9 enabled these:

Mar 7, 2003 DLEXCPCOUNT FULLSTATS FULLSTIMER STIMER MEMRPT

This change disables those statistics options in CONFIGV9

so that you should NOT see any increase in CPU time when

you install SAS V9 and use the same options as SAS V8.

Change 21.027 Mostly documentation. When you are using a SAS View to

JCLUOWV pass data from a data step to PROC SORT, SAS cannot give

Mar 6, 2003 the SORT the estimated record count (because SAS does not

know the observation count of a view), and thus the SORT

cannot be optimized in its choice of SORTKWs and memory.

In these cases, for SYNCSORT, you can use the $ORTPARM DD

to pass the size estimates to the sort program:

//$ORTPARM DD *

VSCORE=756K,VSCORET=512M,FILSZ=E40000000

which tells SYNCSORT to use 756K below the line (fixed)

and 512M total (fixed) storage, and the estimated record

count to be sorted is 40,000,000 records.

Previously, SORTSIZE=40000000 was used, but SYNCSORT

now ignores SORTSIZE= and instead uses the syntax of

FILSZ=Ennnnnnnn. The E is required; without it, SORT

fails if the record count is not exactly nnnnnnnn.

Similar parameters can be passed to DFSORT; if you

tell me that syntax, I'll update this note.

But note that the //$ORTPARM parameters apply to EVERY

sort in the job-step, so use with care, especially

because the memory will be fixed.

The change replaced SORTSIZE= with FILSZ=E.

Thanks to Chuck Hopf, MBNA, USA.

Thanks to Steve Dunn, Mainframe Performance Products Pty., AUSTRALIA

Change 21.026 Support for Control-T Release 6.0.0 (INCOMPATIBLE). New

VMACCTLT data fields were inserted, and the LRECL was increased to

Mar 6, 2003 600 bytes in their new version. Instead of feet, you get

Mar 27, 2003 bytes compressed/uncompressed for volume and datasets.

-Mar 26: Support for Control-T Release 6.1.0 (INCOMPAT,

because the LRECL was increased to 660 bytes, and MXG had

only protected for 600 bytes. Three fields were added to

their volume record by 6.1.

Thanks to Craig Collins, State of Wisconsin, USA.

Thanks to Stefano Baldi, Phoenix Spa, ITALY.

Change 21.025 Documentation only. The removal of Cross Memory Calls in

ASMTAPES ML-27 MXGTMNT causes these variables to be missing in the

Mar 6, 2003 TYPETMNT and ASUMTAPE datasets:

DDNAME INITTIME JOBCLASS PGMRNAME PROCSTEP PROGRAM

RACFGRUP RACFTERM RACFUSER RDRTM READTIME STEPNAME

and these variables to be missing in TYPETALO/ASUMTALO:

ALOCSTRT DDNAME STEPNR

(ALOCSTRT is commented in the ASM code and it appears

it has never been populated in the SMF record).

Stay tuned for a new algorithm that will merge TYPETALO,

TYPETMNT, TYPE1415, and TYPE30TD to not only populate the

missing fields, but enhance tape mount analysis with new

data as well. Maybe by the end of third quarter.
Note that the removal of Cross Memory calls was to solve

problems caused by VTS mounts; if your site does NOT

(yet!) have any VTS devices (or VTS-simulating-software)

so that all of your tape mounts are real mounts that take

real time, then you can still have the above variables

populated by MXGTMNT program, by re-assembling ASMTAPES

with the XMEM=YES parameter enables.
Change 21.024 -Support for TNG "Enterprise Cubes", which contain data

EXTNT007 from multiple servers, required structural revision of

EXTNT034 the code, which had expected a CAPMPCM Header record

EXTNT035 betweeen each system. This redesign has been tested

FORMATS with TNGVERS 6 data from multiple systems.

IMACTNG -New NT object NETWORK SEGMENT creates new NT034 dataset.

VMACTNG -New variables were added to existing SYSTEM object in

VMXGINIT dataset NT018.

Mar 7, 2003 -Support for NT PROCESS Object creates new NT035 dataset

Mar 19, 2003 and a major design change, because each process instance

Mar 27, 2003 does not record all process metris: out of 327 process

Apr 1, 2003 name records, only 175 had PROCESSOR TIME metric records,

but 324 had ID Process, and 326 had Page File records.

MXG presumed TNG recorded all metrics for each instance,

but now a new context-based array (NT035INM) maps each

process name to its metrics's location (INSTLOC), instead

of assuming a sequential INSTNR for each process metric.

-The arrays to support process data can require large

virtual storage if there are very many process names.

With NT035I=2000, NT007I=999, and MAXROWS=325, TYPETNG

required about 180MB of virtual storage! The MXG defaults

of NT035I=500, NT007I=100, MAXROWS=288 needs REGION=64M.

-TYPETNG will ABEND with USER 1111 if it finds more unique

process names than your chosen NT035I=value permits.

-EXTNT035 now only outputs observations that have non-zero

value of % PROCESSOR TIME; most processes are idle and do

not record any time. There were 2,448,576 observations

created when all process records were output, but only

31,320 observations had and CPU. That logic was located

in EXTNT035 in case you ever think you want to output all

observations.

-The process records for the Idle and _Total process names

both have % PROCESSOR TIME of 100, so they should be

removed in your analysis of process utilizations.

-EXTNT007 now only outputs observations that have non-zero

value of Total Bytes, i.e., that had activity.

Thanks to Peter Krijger, National Bank of New Zealand, NEW ZEALAND.
Change 21.023 -Messages SHORT XAMSYS SEG FOUND, DELETED.... were caused

VMACXAM by incorrect subtraction in line 2275, which should be

Mar 5, 2003 SKIP=SKIP-20; instead of SKIP=SKIP-24; The error occurs

Mar 12, 2003 only in records with MTRSYS length of 164 or greater.

Mar 16, 2003 -Support for SYTCPC (Channel Activity) creates new dataset

Apr 22, 2003 XAMSYCPC with Channel Busy array HFCHB0-HFCHB255 (where

the CHPID is the array suffix, and the array is populated

with NBUSY entries), and Channel Simultaneous Bussy Array

HFCHSI0-HFCHSI50 (populated with NBUSYSIM).

-Support for TCP data files creates many new datasets from

Linux, NT, Sun systems, as well as from VM Monitor:

UCD - From UCD-SNMP or NET-SNMP

HST - From ANY SNMP DAEMON supporting HOST MIB

TCP - From either VM MONITOR RECORD FOR VM, or SNMP

FAL - From VM MONITOR RECORDS, exclusive to VM

OTHERS - SUBNET, TCPCON, TCPAPP come from either FAL

or a "NETSTAT" interface.

The datasets have been validated, but this is preliminary

support, and variable names may change slightly as the

data is better understood.

-Additional XAMDEV variables, including RDEVSER, VOLSER,

are now decoded. Apr 22, 2003.

Thanks to Rebecca Cates, Merrill Lynch, USA.

Thanks to Tom White, SPRINT, USA.

Change 21.022 All daily PDB datasets that are created in the JCLPDB8

WEEKBLD example JCL are now copied into the WEEKLY PDB in the

WEEKBLDT example WEEKBLD/WEEKBLDT members. Most datasets were

WEEKBL3 copied into the weekly PDB, but many new datasets were

WEEKBL3T created by BUILDPDB/BUILDPD3 that were not also copied

Mar 5, 2003 into the weekly that now are.

Yes, this change could cause a perfectly good weekly MXG

job to ABEND with an out of space condition, but that, I

decided, was less painful than discovering later that the

data you thought was in the weekly wasn't!

Thanks to Ronald Lundy, AHOLD, USA.
Change 21.021 The Active Server Pages object's INPUT statement has been

VMACNTSM incorrect, at least since NTSMF 2.2.2. ASMEMALO no longer

Mar 5, 2003 exists, and a DUMMYFLD was inserted after ASTMCAHT in the

logic for NRDATA=34 for the ACTVSRVR dataset.

Thanks to Chris Morgan, UFI, ENGLAND.
Change 21.020 Relocated the VMXGOPTR call that resets OBS= value to

VMXGSUM earlier; if KEEPALL=NO and the first data step bypassed,

Mar 4, 2003 and you had changed OBS= to a small value, the original

location was too late. Seen only in unrelated test runs,

has been that way for a long time and never reported, but

is now corrected.

Change 21.019 Oracle variable ASID was not input and ELAPSTM was not

VMACORAC created for Release 8. Several variables no longer are

Mar 1, 2003 created in the Oracle SMF record with that release, and

Mar 13, 2003 will always have missing values:

CPUCICTM CPUSRBTM CPUTCBTM CPUTIMER DDLCOMIT DDLROLLS

ENDSRB ENDTCB ORACMSB PCCOUNT STRTSRB STRTTCB

-Cosmetic. Text in labels had misspelled OSDI as ODSI and

OSID are now all OSDI.

Thanks to Forrest Nielson, State of Utah, USA.

Thanks to Marvin Wapnitsky, TIAA-CREF, USA.

Change 21.018 Support for Domino Server Release 6.0.0 added five new

IMAC108 HTTP-related variables to the Subtype 1 record that are

VMAC108 now output in dataset TYPE1081:

Mar 1, 2003 DOMCACOM='DOMINO*CACHE*COMMAND*COUNT'

DOMCADES='DOMINO*CACHE*DESIGN*COUNT'

DOMCAREQ='DOMINO*CACHE*REQUESTS*TOTAL'

DOMCASES='DOMINO*CACHE*SESSION*COUNT'

DOMCAUSR='DOMINO*CACHE*USER*COUNT'

Their existence was found in APAR PQ70810, which added

the fields to IBM's TIVOLI product; that is what alerted

me that there was a new Domino version to support.
Change 21.017 For devices with IORATE=0, variable DEVIOQTM was carried

VMAC74 from the preceding device that had non-zero IORATE. The

Feb 28, 2003 missing DEVIOQTM=.; statement was inserted where it

should have been, after the AVGIOQMS=.; statement.

Thanks to Barry McQueen, Department of Defence, AUSTRALIA.
Change 21.016 Several "Wdddddd" macro variables were incorrectly %LET

VMXGINIT to &DEFAULT instead of &MXGWORK: all for VMACLDMS and for

Feb 27, 2003 VMACMIM were wrong, as were two for VMACTAND. This only

surfaced as an actual error if you used the USER= option.

Thanks to Ken Kelso, National Australia Group, SCOTLAND.
Change 21.015 Using %ANALDB2R(PDB=SMF); to get the default set of DB2

ANALDB2R reports failed with 76-322 and other strange errors, due

READDB2 to changes made to READDB2 by Change 20.233. The READDB2

Feb 27, 2003 calling logic in ANALDB2R was corrected. However, using

%ANALDB2R(PDB=SMF,IFCIDS=ACCOUNT);

will circumvent the error.

-READDB2 now detects that it was invoked without arguments

and gracefully reports that error.

-IFCIDS=ALL is now recognized.

Thanks to D. J. Chen, State of Florida, USA.

Change 21.014 More than one type 6 ESS '0031'x USERDATA segment was not

IMAC6ESS expected, causing INPUT STATEMENT EXCEEDED if comments in

VMAC6 IMAC6ESS were opened. Multiple USERDATA now supported.

Feb 23, 2003

Thanks to Ricke Godehard, Itellium, GERMANY
Change 21.013 -INVALID DATA messages reading QAPMDISK file because of

VMACQACS ELSE INPUT INPUT in lines 3984 and 3985. Remove one.

Feb 22, 2003 -Variable DSASPN 'ASP RESOURCE NAME' was not kept and was

Mar 5, 2003 not labeled, but now it is.

Thanks to Paul E. Bennett, JPMorganChase, ENGLAND.
Change 21.012 The MNTH72GO example still had PERFGRP and PERFRPGN where

MNTH72GO it should have had SRVCLASS and RPRTCLAS

Feb 22, 2003

Thanks to Mike Kynch, International Paper, USA.

Taught the first tuition-free three-day class in Dallas to 64 students.
Change 21.011 The format MGSASPR had PARETO misspelled, and had several

FORMATS procedure names that were longer than 8 characters that

Feb 18, 2003 are now truncated to 8 bytes so they will match the name

in the TYPESASU dataset (from the SAS user SMF record).

And SETINIT (BASE) was added to the list of procs.

Thanks to Tom White, SPRINT, USA.

Change 21.010 SMF 42 offsets for subtype 20 and 21 are incorrect in the

VMAC42 z/OS SMF manual, but (without test records), I believed

Feb 17, 2003 the manual. Offsets for SMF42KN1 thru SMF42KN3 and for

SMF42LN1 thru SMF42LN6 should have started at decimal 36,

but the manual showed them starting at dec 52 and dec 60.

MXG printed error messages, but the job did not fail, but

it did not output those subtypes, either!

But the subtype 21 records that are only 176 bytes long

have invalid offset SMF42LN4 (177) and number of SMF42LN6

(1) for the Alias Names Deleted in Sympathy segments,

causing MXG to print an error message. It's not clear if

there were Alias names that were not written, or whether

the offset/number should have indicated there were no

Alias names in the record. This will be purusued with IBM

but this Change does correctly populate TYPE4221 dataset.

Thanks to Karl Lasecki, Chemical Abstracts Service, USA.

Change 21.009 Symbolic parameter WORKVOL= is added to the MXGSASV8 JCL

MXGSASV8 procedure, defaulting to 5 volumes, and the WORK= parm

Feb 12, 2003 is (200,200) in CYL. SAS only allocates what it needs,

but this will reduce the probability of B37 ABENDS for

new users.
Change 21.008 Documentation. TYPE70PR PR/SM data for IFL Linux LPARs

VMAC7072 are not identified as such: they have SMF70CIN='ICF', so

Feb 12, 2003 you can't tell an IFL from an ICF partition, so you must

use a table lookup of LPARNAME to select the Linux LPARs

from PDB.TYPE70PR. And only LCPUPDTM is non-zero; the

LCPUEDTM is always zero.

Thanks to Tony P. Steward, Royal Mail, ENGLAND.
Change 21.007 PCHANBY is missing for SMF73ACR='CBP/CBS/CFP/CFS/ICP'

VMAC73 Channels. Originally corrected by Change 20.096, that

Feb 12, 2003 was overridden in Change 20.172, which reset it missing.

Feb 17, 2003 The initialization to prevent carry forward was moved to

above the PCHANBY calculations.

Thanks to John Gebert, Office Depot, USA.

Change 21.006 Negative values in DB2STATB variables occurred when a DB2

VMACDB2 subsystem was stopped and started, and the first record

Feb 11, 2003 after the start had QWHSISEQ=4, but MXG expected first

record to have QWHSISEQ=1. MXG's test to recognize start

was revised to also test SEQCHECK GT 0 or ISEQ=1. This

may be an IBM error, but the MXG circumvention should be

sufficient.

Thanks to Tony P. Steward, Royal Mail, ENGLAND.

Change 21.005 Cosmetic. The INVALID DEVICE messages now include the

VMACEXC2 PROGRAM name, making it easier to identify if they are

Feb 11, 2003 coming from the same program.

Thanks to Paolo Uguccioni, UNICREDIT, ITALY.

Change 21.004 ML-28 corrects an 0C4 in ML-27 that occurred only with

ASMTAPES the //EXCLUDE DD, and only if the tape drive with the

Feb 11, 2003 highest DEVNR was excluded. Trivial to fix once seen,

Feb 17, 2003 hard to include in all combinations of our testing.

Thanks to Anthony A. Ziegler, UMB, USA.
Change 21.003 Variable R791FMCT should have been multiplied by 4096 to

VMAC79 convert from frame count to bytes, which will be printed

Feb 11, 2003 as nnnnKB/MB/GB; the variable is FORMATed MGBYTES.

Thanks to Tom Draeger, Aurora Health Care, USA.

Change 21.002 Major enhancements to MXG processing of RMF III VSAM data

ASMRMFV includes revisions to the ASMRMFV assembly program, the

CLRMFV new CLRMFV CLIST member that will read all of your RMF

DOCLRMFV III VSAM files on all your system in one job (since you

Feb 13, 2003 cannot concatenate VSAM, and member DOCLRMFV to document

Feb 18, 2003 the CLRMFV CLIST, and provides JCL examples of how to

use CLRMFV and ASMRMFV (which will create the RMFBSAM

file that is then read with MXG's TYPERMFV to create all

of the MXG RMF III datasets). Enhancements in ASMRMFV:

-Minimum and maximum LRECL output is now reported for each

RMF III Table/Header.

-Total Displays restructured to combine selection, input,

output records written/skipped and output LRECL min/max.

-CC=4 set when input records are skipped due to exceeding

32756 LRECL or decompression errors; previous CC was 0.

-Messages show FROM=/TO= keyword selection Time Stamps in

Date/Time Format for each RMF III data set processed.

-Messages show FIRST/LAST Sample Set Time Stamps

-Messages assigned RMFVNNN with I=INFO,W=WARN,E=ERROR, and

S=SEVERE ERROR suffixes.

-Major performance improvement with Selection: entire RMF

VSAM dataset is skipped if Data Set Header FIRST/LAST

shows all sample sets are outside FROM=/TO= keywork.

-Minor performance improvement: entire Sample Set bypassed

if FIRST/LAST header is outside FROM/TO keyword range.

-Table access validated by comparing eyecatcher.

-If a specific table exceeds maximum LRECL, next table is

processed; previously, remainder of this sample set was

abandoned.

-Internal ASM improvements; counters that used fullword

Register to Storage arithmetic instructions replaced with

Load Address or Branch on Count Register instructions.

-Improved documentation in the program prologue.

-Tables that are not processed by TYPERMFV (because no one

has needed them)are skipped by ASMRMFV and documented.

-Performance: processing 7 LPARs with 44 RMF III datsets

(a total of 308) in a single job reduced Elapsed Time,

CPU Time, and EXCP count by 70%

-CLRMFV is run in batch and repetitively calls ASMRMFV

for each RMF Monitor III dataset it finds, making ASMRMFV

truly useful for bulk processing; without this CLIST a

separate job step must be used for ASMRMFV, since VSAM

does not support concatenation.

The code, CLIST, and documentation were all written by

and contributed to MXG by Jerry.

-Feb 18: Use PGM=IKJEFT01 instead of PGM=IKJEFT1B, doc'd

in member DOCLRMFV. ASMRMFV now recognizes FROM= and/or

TO= keywords for filtering.

Thanks to Jerry Urbaniak, Acxiom CDC, USA.
Change 21.001 Archaic report example member ANALCICS caused V8 to 0C4

ANALCICS ABEND in module VXBSM doing the autocall for %VMXGFOR,

Feb 8, 2003 now removed by MXG Change 20.327, but the cause was the

old OPTIONS SASAUTOS=(SOURCLIB SASAUTOS) statement in the

ANALCICS member, which as been unneeded for years, and

now removed, as MXG sets SASAUTOS at MXG Initialization.

But SAS had documented this problem before: "It is not

advisable to change SASAUTOS during a SAS session. If

you change the SASAUTOS= specification in an ongoing SAS

session, the SAS System will store the new specification

only until you invoke an uncompiled autocall macro, and

then SAS will close all opened libraries, and open all

the newly specified libraries that it can open."
LASTCHANGE: Version 21.

=========================member=CHANGE20================================

/* COPYRIGHT (C) 1984-2003 MERRILL CONSULTANTS DALLAS TEXAS USA */
MXG Version 20.20 is dated Feb 7, 2003, thru Change 20.341.

MXG Version 20.12 was dated Feb 3, 2003, thru Change 20.335.

MXG Version 20.11 was dated Jan 30, 2003, thru Change 20.330.

MXG Version 20.10 was dated Jan 3, 2003, thru Change 20.307.

MXG Version 20.09 was dated Dec 20, 2002, thru Change 20.299.

MXG Version 20.08 was dated Dec 4, 2002, thru Change 20.280.

MXG Version 20.07 was dated Nov 4, 2002, thru Change 20.244.

MXG Version 20.06 was dated Oct 7, 2002, thru Change 20.215.

MXG Version 20.05 was dated Sep 6, 2002, thru Change 20.186.

First MXG Version 20.05 was dated Sep 1, 2002, thru Change 20.177.

MXG Newsletter FORTY-ONE was dated Sep 1, 2002.

MXG Version 20.04 was dated Aug 12, 2002, thru Change 20.157.

MXG Version 20.03 was dated Jun 19, 2002, thru Change 20.111.

MXG Version 20.02 was dated May 8, 2002, thru Change 20.082.

Final MXG Version 20.01 was dated Apr 11, 2002, thru Change 20.061.

Second MXG Version 20.01 was dated Apr 9, 2002, thru Change 20.058.

First MXG Version 20.01 was dated Apr 1, 2002, thru Change 20.046.

Annual MXG Version 19.19 was dated Feb 14, 2002, thru Change 19.300.

MXG Newsletter FORTY was dated Feb 14, 2002.
Contents of member CHANGES:
Member NEWSLTRS (and the Newsletters frame at http://www.mxg.com) now

contain the current MXG Technical Notes that used to be put in member

CHANGES between Newsletters. New Technical Notes are now added (and

now dated!) in NEWSLTRS/Newsletters with each new MXG Version.

I. MXG Software Version 20.20 is now available upon request.

II. Incompatibilities and Installation of MXG 20.20.

III. Online Documentation of MXG Software.

IV. Changes Log

=======================================================================
I. MXG Software Version 20.20 is now available.
Major enhancements added in MXG 20.20
ASMTAPES 20.320 ML-27 now robust, low CPU, sees VTS, no XMEM, etc.

ML-27 eliminates the cross memory call and 0E0s,

changes interval to 0.5 seconds, which captures

all VTS allocations and most VTS mounts

TYPETMO2 20.335 Support for ASG/TMON CICS V2.2 INCOMPATIBLE.

TYPEXAM 20.315 Support for Velocity Software's ESAMON VM Monitor 3.2

and support for TCP and Linux data almost made it.

TYPE28 20.316 Support for Tivoli Netview NPM 2.7 SMF 28 records.

TYPE102 20.336 Support for IFCID=247 in T102S2347 dataset.

TYPEEDGR 20.331 Support for DFSMSrmm Extended Extract 'X' records.

TYPEESPH 20.318 Support for Cybermation's ESP Product JOBHIST file.

TYPESYNC 20.309 Support for SYNCSORT for z/OS 1.1 SMF record.

IMAC6ESS 20.332 Support for more ESS variables (on OUTPUT statement)

TYPERMFV 20.334 Numerous enhancements/corrections to RMF III support.

BUILDPDB 20.330 New CSTORE30,ESTORE30 variables in STEPS,SMFINTRV.

TYPE30 20.330 New CSTORE30,ESTORE30 variables in TYPE30_4,_5,_V.

TYPE30 20.310 TYPE30TD now has subtypes 2, 3, and 4 output.

ANAL116 20.313 Example graphs of MQ Series SMF 116 data.

VGETJESN 20.326 Type 30s with JCTJOBID='INTnnnnn' protected.