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

TYPETNG 21.095 Support for six new TNG objects, new fields.

TYPETNG 21.160 Support for TNG Version 7 (INCOMPAT, Header changed).

TYPETNG 21.269 Major enhancement/validation of new TNG objects.

TYPETPMX 21.209 New fields supported.

TYPETPMX 21.271 Major enhancement/validation of ThruPut Manager SMF

TYPETSMF 21.210 Support for IBM Tivoli Storage Manager Acct Records.

TYPEWWW 21.166 IIS Web Log with missing fields now supported

TYPEWWW 21.221 Web Log INVALID ARGUMENT with negative GMT offset.

TYPEXAM 21.023 Support for TCP/Linux/etc, plus lots of cleanup.

UNIXSAR1 21.309 Support for "sar", "acctcom", "ps" for AIX/SUN unix.

UNIXTOP 21.314 Support for "top" unix report.

UTILBLDP 21.148 Enhancement to the "Build your own PDB" utility.

UTILBLDP 21.231 USERADD=80/90 create TYPE80A or TYPE90A execution.

UTILEXCL 21.054 Variables KY8DISTM/KY8CPUTM corrected.

VMACSMF 21.127 Variable INFILENM contains input DSNAME or dir/file.

VMXGINIT 21.253 Global macro variables TRENDOLD/TRENDNEW/TRENDINP.

VMXGRMFI 21.067 Examples to invoke RMFINTRV twice, general cleanup.

VMXGRMFI 21.094 Corrections to MSU4HRAV calculation.

VMXGRMFI 21.113 Parsing of more than 99 service class names.

VMXGRMFI 21.125 Different SRVCLASS definitions can map to same WORK.

VMXGRMFI 21.234 Test for '2084'x CPUTYPE, only needed S/390 R2.10.

VMXGSUM 21.185 New INTERVAL=SECOND now supported.

VMXGSUME 21.277 Enhanced alternative, tolerates non-present variables

VMXGUOW 21.093 PDB.ASUMUOW corrected, blank SYSTEM plus others.

WEEKBLDT 21.045 WEEKBLDT fails under SAS Version 6.
Inverse chronological list of all Changes:
NEXTCHANGE: Version 21.
====== Changes thru 21.320 were in MXG 21.21 dated Feb 10, 2004=========
Change 21.320 MXG 21.21 final QA corrections/incompatibilities:

CLRMFV -SEQENGINE=V6SEQ changed to V8SEQ/V9SEQ in CONFIGV8/V9.

CONFIGV8 See MXG Tech Note 4.A in Newsletter FORTY-FOUR, 10Feb04.

CONFIGV9 -VMACDB2. Remove line 8259: PUT _N_= 'HAVE 239 ';

EXTMNSTS -UTILEXCL. Add a second percent-sign to change line 218 to

IMACTMNT %%INCLUDE SOURCLIB(IMACZDAT);

UTILEXCL -CLRMFV. Cosmetic. A "NOT" and EQUAL symbols slipped thru

VMAC90 and were changed to "NE"; NOTs don't translate well among

VMACDB2 platforms, and were removed back in Change 8.093

VMACTMNT -Only if you received MXG on CD: Change line 57 in member

VMXGINIT VMACTMNT, removing "DEVNR", changing the line to be:

Feb 10, 2004 MACRO _BTYSTS SYSTEM SHIFT INTBTIME %

-The CD-only VMACTMNT error was caused by my accidental

copying of support for the new TYPESTAT statistics data

from the subtype 6 ASMTAPEE ML-30 SMF record, after the

ftp and tape files were built. TYPESTAT was validated,

but I didn't use TYPSTMNT to test its sort macro. Member

EXTMNSTS was added and VMXGINIT updated for TYPESTAT and

the sort has been tested in this final iteration.

-Variables SMF9029N,SMF9029A,SMF9030I in archaic VMAC90

were renamed A, N, and Y, only in case someone foolishly

uses both VMAC90 and VMAC90A in same step. Use VMAC90A.

Thanks to George Canning, Abbey National Plc, ENGLAND.

Thanks to Vernon Kelley, IBM, USA.

====== Changes thru 21.319 were in MXG 21.21 dated Feb 6, 2004=========
Change 21.319 Variables PARTNCPU and CPCMSU were added to the new

VMXG70PR PDB.ASUM70LP dataset so the hardware attributes of

Feb 6, 2004 the number of engines and MSU capacity are kept.

Feb 10, 2004

Thanks to Una Cho, CIGNA, USA.
Change 21.318 The label for DB2 variable QLACRBND should be

VMACDB2 SQL STATEMENTS*BOUND FOR*REMOTE ACCESS insteadd of

Feb 5, 2004 ... REMOVE ....

Thanks to Marnel Groebner, State of Washington, USA

Change 21.317 IBM changed the contents of SMF64BMH; its new label is

VMAC64 SMF64BMH='REQUEST HITS*FROM RLS BMF*BUFFER POOL'

Feb 5, 2004 the number or requests obtained from the local shared

buffer pool, and not the old VSAM LSR pool.

Thanks to Thomas R. Coccia, Bank One, USA.

Thanks to Hari Maramraju, Bank One, USA.

Thanks to Raymond G. Seeley, IBM OS/390 Support, USA.
Change 21.316 Updates for SMF record from Serena Ultimizer fix an INPUT

VMACULTM EXCEEDED error and revised INPUT logic have been tested

Feb 4, 2004 with Version R313, but the DSECT indicates no changes

since R310.

Thanks to Scott Barry, SBBWorks, Inc, USA
Change 21.315 PDB.TYPE70PR data with STARTIME 10:13:59 and 10:14:00

VMXG70PR caused multiple observations in PDB.ASUMCEC; the logic

Feb 4, 2004 to force STARTIME across the CEC to the nearest minute

was changed to STARTIME=60*FLOOR((STARTIME+30)/60);

and now those two observations are correctly combined.

Why the STARTIME are off by a full second in a SYSPLEX

is not known at this time. See Change 23.070 redesign.

Thanks to Alan Gray, Carefirst, USA.

Change 21.314 Support for "top" unix command in this user contribution.

UNIXTOP This member contains input for IEBUPDTE to create a PDS

Feb 4, 2004 or directory of the sample program.

This code is not yet "MXG-structured".

Comments in the members tell you what to do!

Thanks to Xiaobo Zhang, ISO, USA.

Change 21.313 Error IEC143I 213-04 on STEPLIB DD with the SAS JCL PROC,

MXGSASV8 after you have executed MXGSASVx JCL Proc, tells you to

MXGSASV9 change your SAS proc to //NULLPDS DD DISP=(NEW,DELETE),

Feb 4, 2004 to matches MXG's discovery that (NEW,DELETE) is safer for

all sites than (MOD,PASS) - see text of Change 20.076.

However, if you do NOT have CA-11, and you are not the

SAS installer, you can circumvent this error by making

//NULLPDS in MXGSASxx PROC use the archaic (MOD,PASS).

This change is doc only; nothing was changed in MXG.

Thanks to Allana Jacob, IBM CANADA LTD, CANADA.

Change 21.312 Support for Beta97 creates new datasets in this user

EXTYB970 contribution.

EXTYB972

EXTYB974

EXTYB97L

IMACBE97

VMACBE97

VMXGINIT

Feb 4, 2004

Thanks to Stephen Bell, Sparkassen Informatik, GERMANY.

Change 21.311 Support for Omegamon for VTAM subtype 29/30 additions and

VMACOMVT protection for INPUT STATEMENT EXCEEDED error, and for

Feb 3, 2004 records that are too short to contain all IRECS.

Thanks to Manfred Engelhart, Candle GmbH, GERMANY.

Change 21.310 Support for z/OS 1.5 (V 1 Release 5) is already in place

DOC in MXG 21.04 and later (required for z/OS 1.4 PTFs), so

Feb 3, 2004 no new MXG changes are required. Minor additions in data

fields that were reserved were compatibly made by IBM.

Change 21.309 Enhanced support for "sar", "acctcom", and "ps" reports

UNIXSAR1 for AIX & SUN unix platforms, in this user contribution.

Feb 3, 2004 In addition to the existing UNIXSAR example, this member

contains four SAS members and two Perl scripts that you

can use to process "sar" data. You need to install the

daemons in the SUN and AIX operating systems; collect the

data in each system, ftp or nfs the data to MXG, and then

process the sar data with the SAS programs.

This member contains input for IEBUPDTE to create a PDS

or directory of the sample program.

This code is not yet "MXG-structured".

Comments in the members tell you what to do!

Thanks to Uriel Carrasquilla, NCCI. USA.
Change 21.308 Member EMAIL previously contained examples to send an

EMAIL email from SAS; this enhancement defines %MACRO EMAIL

Feb 3, 2004 that will send a PROC PRINT of any SAS dataset via a

list of email addressees.

Thanks to Chuck Hopf, MBNA, USA.
Change 21.307 Example program that reads z/OS SYSLOG file for specific

SYSLOG events; an excellent starting place for additional event

Feb 3, 2004 analysis. Please send your updates for other events.

This example tracks these SYSLOG events:

AQ/HQ Activate/Hold JES2 input job queue

SI/TI/PI Start/Modify/Purge Initiators

TJ Modify a job - class, scheduling environment

SJ Force a job to start, disregard class limits

T JOBCLASS Modify characteristics of a job class

Thanks to Chuck Hopf, MBNA, USA.

Change 21.306 This change was rewritten. There is no new "87F3x" flag

VMACVMXA (which was actually a typo, the value was "873Fx") and

Feb 3, 2004 MONWRITE was not changed. However, if you ftp MONWRITE

Mar 22, 2004 data, and translate it from EBCDIC to ASCII, instead of

using a BINARY ftp transfer, you will find the incorrect

0000873Fx value instead of 00008709x at the start of the

data file, and you'll get *ERROR* PROBABLE DATA LOSS DUE

TO MONWRITE FAILURE messages. Always ftp MONWRITE as

BINARY, (i.e., NOASCII NOCRLF if using IND$FILE, etc.)

Aug 20, 2004: If you send VMACCT data and translate it

from EBCDIC to ASCII, CPUMODEL='3F84'x results, which is

the cause of INVALID DATA error for a '2084'x CPU.

Thanks to Dwain Majak, ACS, USA.

Thanks to Sudie Wulfert-Schickedanz, Anheuser-Busch Companies, USA.

Change 21.305 UNDECLARED ARRAY REFERENCED: ICSRDQU error precedeed by

VMXGINIT an APPARENT SYMBOLIC WCICRDQ NOT RESOLVED error was due

Feb 3, 2004 to back-level VMXGINIT in tailoring that didn't define

&WCICRDQ. The text &WCICRDQ..CICSRDQU (KEEP= without

the macro var was parsed to ISCRDQU (KEEP= which

looks just like an array reference to SAS compiler.

Real purpose of this note is to suggest to always take

care of the first SAS error first, and then rerun to see

if that also took care of subsequent SAS errors during

compile of complicated programs.

Thanks to Michael Cosentino, Rohm & Haas, USA.
Change 21.304 New MXG Tape "Event" Mount/Allocate/Recovery monitor sees

ASMTAPEE all tape events, no longer samples for mounts, and gets

VMACTMNT back all of the JOB-level data lost when we gave up XMEM.

Feb 5, 2004 ASMTAPEE is a complete redesign that executes in a mount

exit in the address space of the job, so we not only see

all mount events, but no longer have to use Cross Memory

Services. The new design had one field test iteration

last year, and only one graceful failure (i.e., only an

ABEND of the monitor program, no impact to the system)

when two concurrent allocation recovery events for the

same device occurred, which is now protected.

However, please test this new design with extreme care;

this text will be updated when we have had confirmed

field tests and feed back from new users. See comments

in the ASMTAPEE member for more information.
Since ASMTAPEE will eventually replace ASMTAPES, this

is "ML-30" of the MXGTMNT program.

When MXIT=YES is used, then the mount exit monitoring is

used instead of interval sampling. MXIT=NO is default;

you must change that default to create the exit monitor.
The new MXIT=YES exit monitor (like the recently added

allocation recovery monitor logic) runs in a subtask of

MXGTMNT to keep it separate and independent. If an

unrecoverable error occurs in the MXIT=YES subtask, it

will shut itself down and switch back to using the old

interval sampling method, so that records won't be lost.

New variable TMNTFLAG='1.......'B is set in records that

are created by the new exit monitor.

The tape allocation monitoring function still uses

interval sampling.

Most of the fields that were removed when we disabled

XMEM processing are populated by the exit monitor, and

these new variables are created in TYPETMNT dataset:

ASID ='ASID'

DDNAME ='DD NAME'

DSNAME ='DSNAME NAME'

JOB

PGMRNAME='PROGRAMMER*NAME'

RACFGRUP='RACF*GROUP*NAME'

RACFTERM='RACF*TERMINAL*NAME'

RACFUSER='RACF*USER*NAME'

STEPNAME='STEP*NAME'

TMNTACTN ='MNTFLG: 80 04 02 01'

TMNTDEVC='DEVICE*NUMBER AS*CHARACTER'

TMNTEDUR ='EVENT*DURATION'

TMNTFLAG ='MNTFLG: 80 04 02 01'

TMNTRCN ='RELATIVE*CONCATENATION*NUMBER'

Thanks to "[e-mail]".

Change 21.303 Variable ZARCHMDE, "System is running in z/Architecture"

VMAC7072 is now kept in TYPE70 dataset, since it has been found to

Feb 2, 2004 be a useful discriminant when activating Z/Arch mode.

Thanks to Cheryl Watson Walker, Watson & Walker, USA.

Change 21.302 DB2 SMF 102 IFCID=22 variable QW0022OS was negative when

VMAC102 the &RB.4. field contained 'FFFFFFFF'x, an invalid float

Feb 2, 2004 value. MXG now tests and detects and sets QW0022OS to a

missing value instead of -7.237E75. There is no IBM note

describing why the SQL cost was not validly populated.

Thanks to Frank d'Hoine, National Bank of Belgium, BELGIUM.

Change 21.301 Ahh, what we have to do to keep MXG running under SAS V6!

VMXGCICI VARIABLE S2ACT S2TCT IS UNINITIALIZED because their names

Jan 30, 2004 DS2ACT and DS2TCT started in column 1 of the ORDER= stmt,

and the preceding label's ending quote was in column 72,

and the V6 parsing was imperfect. Inserting a blank has

corrected this V6.09-only error, caught in our QA.

P.S. The only impact without this change was that the

real variables DS2ACT/DS2TCT had blank labels.

Thanks to Freddie Arie, TXU, USA.
Change 21.300 The calculated EXPORTIM was incorrect for hour 0; the

VMACHPAI logic was revised to protect that hour of the day.

Jan 30, 2004

Thanks to Nick Johns, Sainsburys, ENGLAND.

Change 21.299 PARTNCPU was zero for z800s running in basic mode. MXG

VMXGRMFI tested SMF70WLA, the image size, to determine what data

Jan 30, 2004 is present, because on OS/390 R2.10 or lower, SMF70WLA

was zero or missing. But when basic mode or LPAR mode is

running with OS/390 R2.10 or z/OS, SMF70WLA is populated

with the image size in MSUs. When there are no LPARS,

PARTNCPU was zero, so using CPCNRCPU=PARTNCPU was wrong.

The test was revised to use SMF70LAC, which is zero on

basic machines, but nonzero for LPARs.

Thanks to Al Sherkow, I/S Management Strategies, Ltd., USA.

Change 21.298 Nearly cosmetic; all variables were kept in TYPE30_4 when

ANAL30 four were needed; the MACRO _KTY30U4 V1 V2 V3 V4 % was

Jan 29, 2004 replaced with MACRO _VTY30U4 KEEP= V1 V2 V3 V4 %

Thanks to Diane Eppestine, SBC, USA.

Change 21.297 Variable ZDATE added to the list of variables kept in the

UTILEXCL PDB.CICSDICT dataset, for possible use.

Jan 29, 2004
Change 21.296 Does MXG support the VM Performance Tool Kit data file?

TYPEVMXA There is a VM Perf took kit that apparently creates its

Jan 29, 2004 own output data file, but that file is not supported in

MXG, because MXG's TYPEVMXA member supports all of the

monitor data from the IBM-supplied CMS MONWRITE command,

rather than the tool kit's subset of the monitor data.

I thought there might be an actual MONWRITE execution as

part of the tool kit's process, so that you would only

have to find and read that intermediate file,

and if you find there is one, please let me know,

or if you find there is tool kit data not in MONWRITE,

then I'll consider supporting the tool kit file,

but one user found it easier just to create a virtual

machine and run MONWRITE in it to monitor all of the VMs

on that system (including each of the Linux machines!);
His virtual machine had these directory statements:

IUCV *MONITOR MSGLIMIT 255 NAMESAVE MONDCSS

and then he can issue the "start" command:

MONWRITE MONDCSS *MONITOR DISK

command which will cause the MONWRITE records to be

copied from the monitor to this virtual machine and

written on its a-disk. Then the command

MONWSTOP

is issued to close the file and then reissue the "start"

command to start the monitor back up.

As he said, "it's crude, but it works."

Thanks to Jerry Ellis, Liberty Mutual, USA.

Change 21.295 Documentation of /VIEW limitation. This simple program

doc should read SMF type 110 records, create dataset CICSTRAN

Jan 29, 2004 as a view (to skip a write and read of CICSTRAN), and at

the same time, create all of the CICS Statistics datasets

in the //WORK file, then PROC SORT each of the CICS stats

datasets to the //PDB by the _S110ST macro, and then the

_SUOWCIC macro will PROC SORT the CICSTRAN view to create

the PDB.ASUMUOW dataset. This program fails:

%INCLUDE SOURCLIB(VMAC110,VMACSMF,IMACKEEP...);

DATA

_VAR110 /VIEW=_WCICTRN;

_SMF

_CDE110

_S110ST

_SUOWCIC

because of the /VIEW operand. Remove the /VIEW= and the

program works as expected. Why? Because the existence

of a /VIEW defers the execution of that data step until

that dataset is referenced, but the _S110ST macro starts

with PROC SORT DATA=CICAUSS, so ERROR: CICAUSS NOT FOUND

results since that dataset hasn't yet been create; what's

really confusing is that the INFILE SMF messages are not

on the log, and SMF was never opened.

However, reordering the macro references:

DATA

_VAR110 /VIEW=_WCICTRN;

_SMF

_CDE110

_SUOWCIC

_S110ST

the program works just fine, because the CICSTRAN gets

referenced first, the data step runs, and _SUOWCIC runs,

and the CICS Statistics Data Sets are SORTed at the end.

Okay, since VIEW= is for performance, putting the Sort

of CICS Stats after _SUOWCIC means those stat datasets

will be occupying //WORK space until after _SUOWCIC

ends, which might itself be a bigger performance issue

than the write/read of CICSTRAN saved with the VIEW.

An alternative that writes those CICS Statistics Data

Directly to the PDB library, without the PROC SORT, so

no duplicates will be detected, but without the extra

copy, was described in Change 18.152:

//SYSIN DD *

%INCLUDE SOURCLIB(VMAC110,VMACSMF,IMACKEEP...);

%LET CICSTAT=PDB;

_CICSTAT;

... rest of your program

Change 21.294 Support for new JVM Heap data in SMF 120 subtype 1 and 3:

EXT120SH

EXT120SR Subtype dddddd dataset description

IMAC120 1 T120SH TYP120SH server region heap

VMAC120 3 T120SR TYP120SR server region intervval heap

VMXGINIT Has been tested with only one heap per server region, so

Jan 29, 2004 have not validated with multiple heaps and code is nasty.

Thanks to Stan Dylnicki, Royal Bank of Canada, CANADA.
Change 21.293 Support for DFSMS/rmm + DCOLLECT in the JCLDAYDS example.

DAILYDSR The original JCLDAYDS, for "Daily Data Set Accounting"

JCLDAYDS used DCOLLECT for DASD space accounting and TMS/CA-1 for

Jan 29, 2004 tape storage; this enhancement will use IBM's DFSMS/rmm

instead of TMS for your tape storage accounting.

Thanks to Diane Eppestine, SBC, USA.

====== Changes thru 21.292 were in MXG 21.08 dated Jan 28, 2004=========
Change 21.292 Jan 26 21.08: ERROR: VARIABLE R0723AX NOT FOUND TYPE7002,

VMAC7072 when sorted; correct name is R7023AX in the _BTY7002

Jan 28, 2004 macro definition.

Thanks to Craig Loubser, Winn-Dixie, USA.

Change 21.291 If your "PDB" Data Libraries were built by V6, reusing

TYPE102 that old V6 PDB under SAS V8/9 to create MXG datasets

Jan 27, 2004 with "long length character variables", i.e, those with

"LENGTH varname $ &SASCHRLN;" in their VMACxxxx member,

like SQL text variable QW0063ST in T102S063 dataset,

will fail. You must write those V8 SAS datasets to V8

data libraries; you cannot write them to a V6 library.

Create a new data library with SAS V8, and if you need

any of the old datasets as input, the use PROC COPY to

copy from the old V6 library to the new V8 library.

In this specific case, the error that surfaced was that

variables SEG10263 and LEN10263 were missing; they were

counts of 200-byte segments of SQL text under SAS V6.

Thanks to Frank d'Hoine, National Bank of Belgium, BELGIUM.

====== Changes thru 21.290 were in MXG 21.08 dated Jan 26, 2004=========
Change 21.290 Changes in OPTIONS for SAS V9.1.

AUTOEXEC -The options for printing statistics on the SAS log have

CONFIGV9 been enabled and made consistent; benchmarks with V9.1

JCLTEST9 show there is no longer a CPU cost associated with these

MXGSASV9 options, now the default, as their informatiopn on the

Jan 27, 2004 log has been very useful in execution problem resolution.

Jan 31, 2004 -ASCII: AUTOEXEC STIMER FULLSTIMER

-EBCDIC: CONFIGV9 STIMER FULLSTIMER DLEXCPCOUNT MEMRPT

FULLSTATS

Under Windows, SAS V9.1 FULLSTIMER increased run time

by only 14 seconds in a 5 minute execution.

-New options DTRESET added to both AUTOEXEC and CONFIGV9,

to print the current date/time on the SAS log and SAS

listings (rather than the constant step initiate time on

every page!).

-See also Newsletter FOURTY-FOUR, which contains benchmark

comparisons of SAS V9.1, along with other notes

concerning using 9.1.

-The DLEXCPCOUNT option causes these messages to be on the

joblog:

12.56.18 JOB00052 +SAS processed 122 blocks and

and performed 64 EXCPs on library MXG.MONTHRPT.VOLS

====== Changes thru 21.289 were in MXG 21.08 dated Jan 25, 2004=========
Change 21.289 Execution tests with SAS Version 9.1 caused NOTE 49-169

VMAC6156 "NOTE 49-169: The meaning of an identifier after a

IMACICBB quoted string may change in a future SAS release.

VMACX37 Inserting white space between a quoted string and the

VMACEREP succeeding identifier is recommended."

ANALDB2R V9.1 fixed the 9.0 spurious 49 problem, so 9.1 notes were

ANALRMFR used to find the 7 members and 14 lines of MXG code that

ANAL94 needed a blank to be inserted to support for this future

Jan 25, 2004 SAS version now, and make these notes go away.

Because you may have similar now-non-recommended-syntax,

these are the statements that were flagged and revised.

Member Statement Text

VMAC6156 PUT '***'JOB

IMACICBB LABEL 'ID*(='23'x)'

VMACX37 IF EQ 'X37 3'OR PRODREL

VMACEREP LABEL '...('YY'X)'

ANALDB2R PUT ...text='QW0020PC' text'

PUT ...text='QW0020AN' text'

PUT ...text='QW0023PD' text'

PUT ...text='QW0024PD' text'

PUT ...text='QW0025PD' text'

ANALRMFR PUT "*"LPARNAME"*"

PUT PERIOD='PERIOD

ANAL94 PUT 'S94TVCS'GB' 3 times

Change 21.288 -Support for Type 42 Subtype 10, Volume Selection Failure'

EXTY42VS because of insufficient space when allocating a dataset

IMAC42 creates new TYPE42VS dataset.

VMAC42 -Type 42 subtype 3 TYPE42AU SMS AUDIT with SMF42EAC='VARY'

VMXGINIT needed +22 instead of +21 after SMF42ENM, causing vars

Jan 25, 2004 SMF42EVL/ESY/EST to be incorrect by one byte.

Thanks to Chris Edwards, Defence Computing Bureau, AUSTRALIA.