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

which contain the swap sizes and maximum swap sizes

in both TSOMCALL and TSOMSYST data sets. Prior to 5.2

TSO/MON recorded the number of 2K blocks, but now TSO/MON

TSO/MON records the number of 4K pages. Since all of the

swap sizes and high water marks are actually

measures of storage (bytes, frames, pages, KB, MB, etc.)

which can be printed accurately and uniformly with MXG's

MGBYTES format, all of these old variables are now

converted

into bytes and formatted with MGBYTES. Unless you test

the value of those variables or calculate other report

variables, the only impact will be that the size will be

printed 396K instead of 99 pages (5.2+) or instead of 198

2K blocks (5.1 and earlier). This fix also preserved old

variables SWAPSIZE, SWAPHIGH, NRSWAPS to protect reports,

but now swaps are split into two variables each for

In/Out.
I firmly believe presenting KB, MB, GigaBytes, and their

rates per second is far more communicative than using

units of pages, frames, slots, etc., for both the swap

size of a single user (which might be 200K, 400K, etc.),

and for the total swapping load (which might be 9000G

for a 15 minute interval, or 10 MB/sec to/from if 100

100K users are swapped once per second). By expressing

these transfers of data between memories in MB/sec or

similar consistent units, comparisons with channel speed,

memory speeds, etc. become clearer, not just in TSO but

in all subsystems in all operating systems.

Thanks to Pete Shepard, Ashland Oil, USA.

Change 07.239 Change 7.142 for PR/SM environment corrected CPUWAITM if

VMAC7072 the number of LPARS was greater than the number of real

Feb 8, 1990 processors. That fix also corrects an error in CPUWAITM

when CPUs are varied ONLINE or OFFLINE under PR/SM.

In verifying that the fix solved both problems, it was

noted that the fix was made only to PR/SM SHARED,WAIT=NO

environment (the normal, expected use of PR/SM). Although

no one has ever (nor likely will ever) specified WAIT=YES

for their PR/SM partition, the fix of 7.142 was applied

to lines 136200-141000.

Thanks to Lou DeRosa, Commercial Union, USA.

Thanks to Igor Polevoy, Commercial Union, USA.

Change 07.238 Several collected changes to various things.

ANALAUDT 1.ANALAUDT line 01500001 should be RACFQUAL=107 instead of

Feb 7, 1990 RACFEVNT=107.

2.Misspelled SMF6LN3 now correct in text of Change 7.105.

3.VMAC37 variables BRFMODEL and BRFTYPE removed from keep

list, as they did not exist.

4.VMAC102 variables QW0080CK,QW0082CK and QW0082F1 are now

formatted $HEX2. for printing.

Thanks to Susan Marshall, SAS Institute Europe, GERMANY.
Change 07.237 -NETVIEW NPM Type 28 records occasionally produce MXG note

VMAC28 "nonzero AOF segment for NPMSUBTY F1 (NPM End)". In the

Feb 7, 1990 two dumps viewed, the AOF triplet does point to a data

segment, but it contains trashy data (like an uncleared

buffer?). There is no AOF segment documented for the F1

subtype (and none expected; this is the stopping of the

NPM monitor). It sure looks like an IBM coding error in

NETVIEW/NPM, but since it's only impact is the note on

the MXG log, and because this is not important, no one

has gone thru the tedious process of several calls to the

support center Level I and Level II until they find that

no reported problem exists and IBM then issues an APAR,

(Authorized Problem Activity Report), which is IBM's

acceptance of the problem, and then they wait for the IBM

Product Change Team to produce the PTF (Program Temporary

Fix), that now must be installed (a change, with its

exposure to breaking something that was already fixed).

Hoping it eventually goes away or gets reported, you can

ignore the note for the F1 subtype.

-Variable BASTIME does not exist in subtype 51x and 61x,

causing INVALID ARGUMENT FOR INPUT FUNCTION. INFO/SYS

entry E337883 confirms these values are zero for those

subtypes. MXG now causes BASTIME to be missing for those

subtypes. Update Nov 2001: See Change 19.221.

Thanks to H. Beer, Hessische Landesbank, GERMANY.

Thanks to Siegfried Trantes, Gothaer Versicherungsbank VVAG, GERMANY.

Change 07.236 Support for Empact's STOPX37 Product Release 3.3 added

VMACX37 new variables STEPNAME,PROCSTEP,VMEXTS,VSCLUST,VSCOMP,

Feb 7, 1990 VSTYPE, and VSDTYPE and corrected the length of SELECTBK,

ACTIONBK, and ACTION37. The Empact supplied SAS code for

3.3 is incorrect for at least one field, and this support

has not yet been tested with actual 3.3 records.

Thanks to Duane Reaugh, Empact Software, USA.
Change 07.235 DB2 discoveries and enhancements support DB2 2.2.0:

ANALDB2R 1.DB2STAT0 and DB2STAT1 records have slightly different

VMACDB2 values for QWHSSTCK (time stamp). To associte the two

VMAC102 records from the same interval, MXG carries the subtype

Feb 6, 1990 0 QWHSSTCK into the subtype 1, unless the absolute time

Feb 8, 1990 delta between the 0 and 1 subtypes was greater than one

second (to detect when the previous 0 is the last from

one SMF file and the new subtype 1 is the first from this

system). I assumed one second delta would be enough, but

it is not! One site sent these data for adjacent SMF

type 100 records:

Subtype SMFTIME (SMF) QWHSSTCK (DB2)

0 33:42.55 33:42.4624

1 33:43.69 33:43.6992

a. DB2 STCK to SMF buffer delta time is 90 millisecs.

This possibly represents the elapsed time for DB2

to collect and pass the subtype 0 to SMF.

b. Delta from STCK of 0 to 1 is 1.25 seconds between

DB2 time stamps AND delta from SMFTIME is 1.14

seconds suggest a momentary glitch delayed DB2.

As a result, the THISSTCK check in VMACDB2 now tests for

a delta of 60 seconds between subtype 0 and 1 before a

mis-match is declared. (No records are lost).

2.The DB2ACCT, DB2STAT0, and DB2STAT1 data sets now contain

the 16-byte DDF variable QWHSLOCN (This Location Name) if

this DB2 is part of a Distributed Data Facility network.

3.QWHSLOCN was also added to all T102Snnn trace datasets.

In the trace record, for DDF, there is a new header with

several new DDF fields (including QWHDRQNM, the location

name of the Requestor/Server DB2), which is decoded, but

kept only in the T102S106 dataset. Location names are

$CHAR16. fields (though in the pre-release, QWHDRQNM was

incorrectly $CHAR8.).

4.Type 102 trace subtype 106 T102S106 variables QWP9....,

for DDF are now created and decoded.

5.Variable QXNSMIAP in VMACDB2 is now spellec QXMSMIAP.

6.The CPU time of the 4th address space (DDF) is created

in QWS4EJST and QWS4SRBT and is added to DB2CPUTM.

7.New member XDB2HDR is a debugging aid that decodes the

type 102 record header(s). Hopefully you won't need it!

8.DDF may create multiple segments in type 100 and 101

records (NRQTXA and/or NRQLST greater than 0), but MXG

currently only processes the first segment. Once we have

real DDF data in hand, we'll decide what to do (i.e.,do

we create multiple variables, or multiple observations?).

9.EDM pool reports from variables QB1TCBA-QB4TCBA and

QISEPAGE,CT,FREE,DBD, and SKCT were incorrect (only the

ANALDB2R report was wrong; the values were correct in

the DB2STAT0 data set), and have been fixed.

10.ANALDB2R (DB2PM-like reporting) has been updated thru DB2

Release 2.2.0. The status of all DB2 reporting is in the

comments in member ANALDB2R. Only the SQL TRACE and the

Transit Trace reports were not completed in MXG 7.7. The

reports are generally updated for DDF fields, but we have

had no test DDF data. In all trace reports from DB2PM in

DDF environment, QWHDRQNM, (DDF location) is printed in

the header, but not all MXG trace reports have this one

field (although the system parameter report and other

important reports have been updated.

Thanks to Siegfried Trantes, Gothaer Versicherungsbank VVAG, GERMANY.

Change 07.234 MXG Algorithms to process IMS log records into IMSTRAN

IMACIMS observations now are further enhanced. Variables MODNAME,

TYPEIMS NODENAME, MSGSIZIN, MSGSIZOU, ODEST, and DTOKEN should no

VMACIMS longer be occasionally missing; incorrect KEEP/DROP logic

Feb 5, 1990 in VMACIMS was changed. A new macro, _IMSVTAM, is now

defined in IMACIMS to indicate if VTAM is your IMS access

method (default _IMSVTAM is yes). For IMS 2.2 or later,

VTAMNODE will be captured. Output queue time was missing

sometimes because CLINENR was set to LINENR/TERMNR but in

VTAM environment NODENAME/VTAMNODE should have been used;

now CLINENR is set appropriately. The response times for

WFI and multiple transactions per program schedule were

sometimes missing, because only one observation was

created for type 35 events, but a type 35 could be both

the end of one transaction and the start of a second;

MXG now creates multiple observations when appropriate,

and this new logic seems to have closed that loophole.

I keep hoping each IMS iteration will be the last, yet

I know it never will be. This one, though, was a cleanup

of many small problems which have existed since Pete

re-vamped the original MXG algorithms in 1988! These

changes have been well tested on IMS 2.2 and tested on

2.1 data, but not yet on IMS/ESA 3.1 data records.

A new debugging macro _IMSDBUG that provides a decoded

trace of each IMS log record used in MXG logic is also

defined and described in VMACIMS.

Thanks to Pete Shepard, Ashland Oil, USA.

Thanks to Ervin Claxon, Ashland Oil, USA.

Change 07.233 VM/370 Monitor MXG dataset VMONPERF variables Q1LOGDRP

VMACVMON and Q1LOGDRP were documented in the MXG Supplement p 551f

Feb 5, 1990 as being renames of MN002Q1B/MN002Q2Bm but the change was

not made in VMACVMON until now.

Thanks to Bob Small, Grumman Data Systems, USA.
Change 07.232 Landmark's MONITASK record for TRANSACT='OVHD' does not

TYPEMONI contain User segments, and the second fix in Change 7.108

Feb 5, 1990 is now added permanently to prevent STOPOVER when reading

Landmark-created summary files. Note that OVHD transact

do not exist in the "raw" (normal) Landmark records.
Change 07.231 The new-style macro %GRAFRMF was both defined in this

GRAFRMFI member, and automatically invoked as the last line of

Feb 2, 1990 the member, preventing you from passing/changing any of

the macro arguments for RMF reports from RMFINTRV. Now,

the member only defines the macro, and no longer invokes

it for you.

Change 07.230 The variables kept in PDB.STEPS did not include the nine

IMACPDB variables documented on page 278 of the MXG Supplement:

Feb 2, 1990 JOBCLASS,LSQSZHI/LOW,PVTSZHI/LOW,RDRDEVT,REGREQST, and

USRSZHI/USRSZLOW that were supposed to have been added

back in Version 5! Now they have been added to the list

(in the MACRO definition for _PDB30_4 list in IMACPDB).

Thanks to Elliot Weitzman, Oryx Energy Company, USA.
Change 07.229 TYPE70PR (PR/SM only) variable PRSMSLIC (dispatch time

VMAC7072 slice duration) and flag variables DIAG204F, NRPRCHGD,

Jan 30, 1990 and SLICCHGD (X'204' failure, number of processors were

changed, or time slice was changed respectively) were not

kept, labelled, and the last two were not even created,

and PRSMSLIC should have been PIB2.3 instead of PIB3.

Fortunately, that it took until now for this to be seen

suggests they are not of critical import, but due to

detailed debugging by this user, they are now valid.

Thanks to Diane Eppestine, Southwestern Bell Telephone, USA.

===========Changes thru Change 7.228 comprised Prerelease 7.6==========
Change 07.228 NETSPY 3.2 Appendix B did not agree with actual DSECT of

VMACNSPY the T and U records, causing LUUID and LUGTRGT1-4 to be

Jan 29, 1990 missing (but no ABEND nor ERROR, because the Appendix

said to expect 116 bytes, but there were only 108, so the

conditional INPUT was never executed).Change the test

IF NSPYENTL GE 116 to GE 108 and change the subsequent

four occurrences of PIB4.6 to PIB2. (for the LUGTRGT1-4

variables), and delete the four lines where LUGTRGT1-4

are multiplied by 65536,

Thanks to Brian Cooper, Wyeth-Ayerst Labs, USA.

Change 07.227 The alpha test site for Change 7.219 found it deficient

VMACVMXA in two places. The calculation of SKIPTHIS was changed

Jan 29, 1990 to SKIPTHIS=LENGTH-COL-1; and the ELSE INPUT was changed

to just INPUT to properly skip over VM/XA spanned

records.

Thanks to S. Rolin Hymans, Comparex Belgilux, BELGIUM.

Change 07.226 VM/XA changes only in pre-releases 7.2+ caused DELTATM

VMACVMXA in VMXAINTV to be picked up inadvertently from VXSUMIOD,

Jan 29, 1990 where it was inadvertently summed. (DELTATM is the delta

between interval records of the same type, and is used

to calculate rates. In VXDEVTOT, DELTATM is appropriately

summed, because it aggregates device activity across the

day by device address. In VXSUMIOD, however, the interval

is the aggregate, and DELTATM is now taken from the first

occurrence within the interval device records. Note that

DELTATM between device records in an interval will not be

exactly the same as the DELTATM between other interval

records, because all records are not written at the same

time.) The fix: removed DELTATM from the _VSUMIOD macro

definition, added DELTATM explicitly after the references

to _VSUMIOD in building the VXDEVTOT, added ID DELTATM;

to the subsequent PROC MEANS for VXSUMIOD, and added

(DROP=DELTATM) after the VXSUMIOD reference in the MERGE

that builds VXBYTIME. MXG MACRO _TESTINT, which will

process only the interval VM/XA data records, was also

updated to properly handle the I/O interval records.

A brief benchmark of VM/XA processing costs for 30

intervals with 1000 Logged on VM machines shows total

MONWRITE output was 37,735,588 (35MB), written as

1372 4KB control records interspersed with the 3290

data blocks which varied from 4KB to 28KB but averaged

16K. That's about one Megabyte per Logged On user for

30 intervals (at 15 min intervals, thats 7.5 hours, or

one prime shift). MXG _TESTMW took 70.99 TCB 3090-200

seconds for the data step and totalled 117.20 TCB and

46,146 EXCP to create all possible data sets and sample

VM/XA reports, in 14 elapsed minutes of execution. The

_TESTINT macro (keeps only interval records and not all)

took only 9 minutes elapsed with 40.37 TCB in the data

step and 77.33 total TCB with only 31,464 EXCPs.

Thanks to Rob Owens, SAS Institute Europe, GERMANY.

Thanks to Margaret Curtis, Rutherford Appleton Laboratories, ENGLAND.

Thanks to Yam Tan, British Airways, ENGLAND.
Change 07.225 This update to DB2PM-like reports enhances more of the

ANALDB2R reports to support DB2 2.2.0 reports, although not all

Jan 28, 1990 of the new information (especially the DDF Distributed

Data Facility information) has been added to all of

the existing reporting. See the table in the comments

of the member to identify if the report tolerates or

exploits the new data fields. Member was renumbered.
Change 07.224 Typos crept into XMAC71 change 7.038 (to circumvent the

XMAC71 SAS Error 344 condition) that could cause variable type

Jan 26, 1990 conflict for variable FRAMES in TYPE71. Line 0318 XMAC71

that was IF FRAMES=. THEN FRAMES=.;

must be IF FRAMES=' ' THEN FRAMES=' ';

(to initialize FRAMES, which is non-existent if MVS/XA).

Thanks to Bruce Widlund, Texas Utilities, USA.
Change 07.223 Typos crept into ANALPATH, added in MXG 7.3. Line 105

ANALPATH should have been HEX4.; vice HEX4; and Line 222 should be

Jan 26, 1990 PDB.TYPE73 vice DB.TYPE73.

Thanks to Christophe Faure, SAS Institute, FRANCE.

Change 07.222 Preliminary support for type 79 SMF record written by RMF

EXTY791 Monitor II session to the SMF file. This support used an

EXTY792 SMF Manual from MVS/ESA 3.1.3 and an MVS/XA 2.2 DSECT in

EXTY793 ERBSMF79. If I am lucky, it should support all MVS/ESAs

EXTY794 and MVS/XAs 2.2 and later. If I should be really lucky,

EXTY795 some of the MVS/370 subtypes and MVS/XA before 2.2 may

EXTY796 also be processed without error, but caveat user.

EXTY797

EXTY798 Added in MXG 7.6, the code has yet to read a 79 record.

EXTY799

EXTY79A For subtypes 1 thru 12, exact IBM field names are used as

EXTY79B variable names, and one observation is OUTPUT for each of

EXTY79C the segments in each subtype into the twelve MXG-built

EXTY79D TYPE791-TYPE999 + TYPE79A-TYPE79C datasets.

EXTY79DF

EXTY79E For subtypes 13 and 14, because they so parallel the type

EXTY79EF 78 SMF record, their dataset names and variable names are

FORMATS taken from the existing TYPE78, TYPE78CF, and TYPE78CU

TYPE79 MXG datasets to create these four new data sets:

VMAC79

Jan 25, 1990 TYPE79D,TYPE79DF,TYPE79E,TYPE79EU
where Ds (13X) are non-3090s and Es(14X) are 3090 plus.
The implementation for this subtyped SMF record creates a

_VAR... and _CDE... MXG macro for each subtype, allowing

you to construct programs for selected subtypes, if your

really need to.

If you have turned on the right monitoring in RMF Monitor

II, you should have only subtypes of interest, and the

standard MXG program for processing an SMF record:
%INCLUDE SOURCLIB(TYPE79); RUN;
will create all 16 of the possible TYPE79.. datasets that

can be created, and for those of the 14 subtypes that

are found in your SMF file, non-zero observations will

appear in the associated MXG-built dataset.

Alternatively, as an example of this new MXG design for

SMF records with subtypes, you could create/execute the

following MXG program:
%INCLUDE SOURCLIB(EXTY79);

DATA _VAR791 _VAR792 _SMF _CDE79S _CDE791 _CDE792 ;RUN;

to create only the TYPE791 and TYPE792 MXG datasets from

the subtype 1 and subtype 2 SMF type 79 records. If you

do create your own subtype-specific program, note the new

required _CDE79S reference to process the RMF 79 header

and product section. (It's already in member TYPE79).
Future enhancements might include an "ANAL79" to merge

some subtypes together, and might include an "IMAC79" for

session selectivity, etc. Let me know what you need.

Thanks to Ervin Claxon, Ashland Oil, USA.

Thanks to Tom Skasa, General Electric Medical Systems, USA.

Thanks to Sterling Green, General Electric Capital, USA.

Thanks to Bob Rutledge, Sherwin Williams Paint, USA.
Change 07.221 Change 7.189 (only in MXG 7.3 and 7.5) was incorrect.

ASUMCICS While intended to transparently use either Landmark or

Jan 24, 1990 IBM CICS transaction data, it failed miserably if either

source was missing (but it worked great, when both were

present!). Now it self-detects what kind of CICS data

you want summarized from the detail transaction data to

the PDB.CICS (Trending, summarized) CICS data set. Sorry

for not testing all possible alternatives on this one!

Change 07.220 Line 002000 contained a truncated line, and should be

XSYSLOG deleted. (Variable EVENTIME was already calculated just

Jan 20, 1990 a few lines above).

Thanks to Freddie Arie, Lone Star Gas, TEXAS.

Change 07.219 This change is a series of enhancements to VM/XA Monitor

VMACVMXA support.

Jan 15, 1990 1.VM/XA MONWRITE can span logical records across physical

blocks, but VM does not support a "VBS" format, and the

2-byte field that could be used for "spanning" flag is

a reserved field in VM/XA! As long as the spanned record

happened to split on a field boundary, MXG'S Change 7.086

(which removed STOPOVER), and the robustness of SAS, made

spanning "supported"! Now, however, we find 1.13 records

split in the middle of the 8-byte MRHDRTOD field! (This

occurred at a site that named 240 specific devices to be

monitored, causing a 1.14 record that did not leave space

enough in that page for the 1.13 record to fit!)

This circumvention detects a spanned logical record and

and notes the encounter on the log, deleting the bad data

record, and IBM has been notified of their design error.

It may be that this is the only exposure, as in most of

the other records in which there can be multiple segments

the individual segments are actually separate logical

records and may (accidentally) be protected. How could

IBM overlook this design oversight? Because if you are

thinking about "data pages in memory" rather than the

resultant "physical block on external storage device",

and are simply moving addresses across virtual storage,

the operating system takes care of "page spanning" for

you!

2.If no Monitor START event precedes each package of VM/XA

MONWRITE data, numerous problems result. First, since

there is no 1.4 record, the GMT offset delta is unknown,

causing all timestamps to be of unknown time zone! All

of the records found before an end-of-interval have to

be deleted, because BEGINMTR and ENDTIME are unknown.

Furthermore, since MONWRITE records contain accumulated

data (instead of the actual data for the interval), the

first interval will ultimately also be thrown away, as it

is valid only to initialize values for de-accumulation.

Still further, no Monitor START event record means that

there is no MTRDEV Configuration record, which is needed

to map the static device information (such as device type

class, path, etc.) to the device activity records. All of

those variables will be blank in the IOD... datasets.

MXG now will process VM/XA data that is not precedeed by

a Monitor START record correctly, but even MXG cannot do

anything about the missing data.

How can there be no START event? This problem came about

at a site using Candle's VCOLLECT product that creates a

new MONWRITE file each day with its End-of-Day routine.

The second and subsequent files are incomplete. The only

safe solution seems to require Candle to STOP/START the

monitor as the initial records written to each new day"s

MONWRITE file.
This is not a problem with IBM's MONWRITE-created files,

since their ONLY way to dump VM/XA data requires you to

STOP and then START the monitor!
The real culprit here is the IBM design in which monitor

data records are created that are not self-described and