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

creates observations in TYPE70PR from the PR/SM segment.

(RMF users must use TYPEMDF, Change 7.087, to decode its

separate SMF record from Amdahl's MDFTRACK instead.)

Also, note there is no type 79 record created by CMF.

Thanks to Richard L. Gimarc, Boole & Babbage, USA.

Thanks to Allan Callahan, SAC Offutt AFB, USA.

Change 07.118 MXG DB2PM-like reporting has been further enhanced. All

ANALDB2R reports possible have been tested with DB2 Version 2.1

Sep 6, 1989 data (as well as prior DB2 versions). Additional reports

have been added, and all reports planned for MXG Version

7 have been named (even though some do not yet exist).

See member for revised documentation and details.

Change 07.117 DB2 Report PMACC01 values on **TOTAL** lines were totals

ANALDB2R of averages because wrong denominator was used in three

Sep 5, 1989 places. Insert three lines to correct:

line 07951000 FREQ=L2FREQ;

line 08411000 FREQ=L1FREQ;

line 08871000 FREQ=GFREQ;

Thanks to Alan W. Maloney, Telenet Communications, USA.
Change 07.116 A minor omission, &OTHER6 was left out in lines 019300 to

GRAFTRND 019600. 12="&OTHER6" inserted after 11=, and &OTHER7 to

Sep 5, 1989 &OTHER9 became 12 to 15, deleting the extra &OTHER9.

Thanks to Raymond Zieverink, Belk Stores Services, USA.

Change 07.115 ACF2 data sets ACF2NRA & ACF2NRB contain 0 observations.

VMACACF2 ACF2 SMF record subtype 'A' has JOB name of hex zero.

Sep 5, 1989 MXG includes IMACJBCK (an MXG macro which allows for JOB

name selection during creation of MXG data sets) BEFORE

checking the record subtype, which caused all ACF2 'A'

records to be deleted. Line 0345's %INCLUDE was moved to

after 0365 and executed within a do group:

IF ACSMFREC NE 'A' THEN DO;

%%INCLUDE SOURCLIB(IMACJBCK);

END;

Additionally, line 0376 (ACFAPMLN) should be PIB2. vice

PIB1., and line 0379 AFCAPARM should be spelled ACFAPARM.

Finally, ACFACID is formatted as $HEX2. (in line 0328).

Thanks to Raymond Wallace, NRMA, AUSTRALIA.

Thanks to Bill Gibson, SAS Institute, AUSTRALIA.
Change 07.114 VMAC7072 PR/SM variables were wrong (only) when SMF data

VMAC7072 was read from the VSAM SMF file. Line 132700 should read:

Sep 5, 1989 LOCPRDS=OFFPRDS+BDNSKIP*LENPRDS-3+OFFSMF;

Additionally, SMFTIME was not kept in TYPE72MN, and

ZDATE was not kept in TYPE72MN or TYPE70PR datasets.

Thanks to Barry Pieper, First Bank System Information Services, USA.

Thanks to Siegfried Trantes, Gothaer Versicherungsbank VVAG, GERMANY.
Change 07.113 RMF Monitor III VSAM data set support validation found a

VMACZRB few changes. In VMACZRB, field GEISIZ is now spelled as

ZRBJCL GEISIZE. The lengths (see inital comments in VMACZRB) of

Sep 5, 1989 ASISIZE was changed from 84 to 88, and of GEISIZE was

changed from 92 to 96 by RMF 3.5. In ZRBJCL, the correct

DDNAME is RMFIII vice ZRBIII. It has been reported that

only minor changes (tests LENGTH was tested for explicit

value instead of GE, I think) are needed for this code to

also support RMF 4.0 (MVS/ESA) RMF III, but that has not

been identified/tested yet.

Thanks to Neil Ervin, Sara Lee Direct, USA.
Change 07.112 Member ANALBNC1, for the analysis of benchmark runs, is

ANALBNC1 not really complete (in that the benchmark job stream is

Sep 5, 1989 not yet in existence) but some users have still found the

member was a good starting point for comparisons of their

own benchmark stream. This change upgrades the code so

that at least it runs without errors due to incomplete

comments, misspelled variables, etc.

Thanks to Harry Olschewski, DVG Kiel, GERMANY.

Change 07.111 This is a major revision to the MXG VTOC reading utility.

VMXGVTOC All variables are now labeled, and additional fields in

Sep 1, 1989 the VTOC (tracks allocated, tracks used, expiration date,

last use date, etc.) are now decoded in the MXGVTOC data

set. The VTOC itself is now recognized as occupying DASD

space, and free space after the last dsname on the volser

is now included in the MXGFREE data set. With this change

MXG really does capture the VTOC information for capacity

management of your DASD farm as well as for the billing

of DASD usage. The number of tracks on the volume is now

contained in the MXGVTOC data set in the DSNAME of the

VTOC data set (see comments in member).

Thanks to J. Cary Jones, Philip Morris, USA.

Thanks to Chris Luckman, SAS Institute, ENGLAND.

Thanks to Jugdish Mistry, SAS Institute, SCOTLAND.
Change 07.110 In searching for info on 3480-IDRC in INFO/MVS, I found a

VMACEXC2 reference to a new Device Type of x'81' for Device Class

VMACUCB of x'80' (Magnetic Tape), decoded as device type 9348. On

Aug 31, 1989 Sep 5, the 9348 (a 1600/6250 reel drive) was announced!

In examining UCBTYPE for decoding the 9348, a new Device

Class value of x'04' (Character Reader) was noted. Also

on Sep 5, IBM announced the 3490 tape cartridge device,

(a 3480 with IDRC built-in and a smaller footprint).

MXG member VMACUCB creates values of variable DEVICE.

MXG member VMACEXC2 accumulates EXCP/IOTM counts into the

device-specific variables (EXCP3420, EXCP3480, etc.).

a. VMACUCB now sets DEVICE variable values of 2400, 3420,

3480 or 9348. (Previouly, DEVICE was either 3420 or 3480,

and 3420 meant "all tapes not-3480").

b. VMACEXC2 IOTM/EXCP summarization for Tape Class continues

to keep only XXXX3420 and XXXX3480 variables, and 9348

counts are included in the XXXX3420 variables. XXXX3420

variables still mean "all tapes not 3480".

c. VMACUCB also now creates a value of CHARRDR for DEVICE

for device class of x'04'. (If you had actually had any

x'04' values, MXG would have produced an error message on

the SAS log, and none have ever been reported!)

d.VMACEXC2 counts EXCP/IOTM counts from device class x'04'

in the XXXXUREC variables.

Attended SHARE to present paper on the history of SMF Product's 1969

release, twenty years ago (and the 20th anniversary of the SHARE CME

Project as well). The paper is published in MXG Newsletter FIFTEEN,

in Volume One of the SHARE 73 PROCEEDINGS, and elsewhere as well.

Change 07.109 Unknown DOS Accounting records caused MXG to STOP reading

TYPEDOS the DOS file, which was inappropriate. Now, if an unknown

Aug 3, 1989 record id is encountered, a message and a hex dump of the

first ten occurrences are printed on the SAS log, but the

MXG program continues to read the rest of the POWER data.

The unkonwn record encountered was RECID='D', which looks

like an execute record, but is still under investigation;

it may be created by a vendor-product.

Thanks to P.J. Penrith, Kleinwort Benson, ENGLAND.
Change 07.108 Landmark's Monitor for CICS History Data OVHD Records are

TYPEMONI incorrect due to an error in Landmark's TMV630 program.

Aug 1, 1989 The OVHD,History record (not typically used by MXG users)

is one byte too short, and causes an "INPUT EXCEEDED" SAS

error message and STOPOVER ABEND. Landmark now has a fix

to create valid records, but until you apply their fix,

this circumvention will avoid the ABEND:

Insert after line 040600 (USER $CHAR8.) :

@; IF SUBSTR(TRANSACT,1,4) NE 'OVHD' THEN INPUT

Insert after line 040800 (@;) :

ELSE INPUT LUNAME $CHAR7. @;

Remember to remove this fix after you get the fix from

Landmark installed.

THIS CIRCUMVENTION WILL NOT BE PUT IN MXG SOURCE CODE.

IT IS ONLY FOR YOU TO TEMPORARILY INSTALL IN YOUR SYSTEM.

Thanks to Neil Ervin, Sara Lee Direct, USA.

October 19, 1989 update:

Another site tried the above circumvention before they

got the fix from Landmark, and still abended, because

in their case, the record had no FILESEGs, so that the

input DO loop is not executed, then the code in line

048600 is executed, and the STOPOVER occurs in trying

to input UTNUM PIB1.

Their additional circumvention, then, was

IF SUBSTR(TRANSACT,1,4)='OVHD' THEN UTNUM=0;

ELSE INPUT UTNUM PIB1. @;

Thanks to Anthony Miekle, Composite Buyers, AUSTRALIA.
Change 07.107 Change 7.060 (7.0 Beta ONLY) added type 37 support for

VMAC37 NETVIEW 1.2 and NETVIEW 1.3 records. Earlier versions of

Aug 1, 1989 NETVIEW (1.1) and prior NPDA (V3R2,V3R3) STOPOVERed. The

code now supports all of these records, and additionally

now decodes the local and remote modem reports into 12

new variables each.

Thanks to Bruce Widlund, Texas Utilities, USA.
Change 07.106 IDMS SMF records have been further validated and a few

VMACIDMS fields (which had existed in the old RTE records) are now

Aug 1, 1989 added in this minor enhancement.

Add TASMSSEV to keep list in line 013700.

Label TASMSSEV='TASK ABEND*SEVERITY*CODE'

PMHTSKID='TASK ID*NUMBER' after 019700.

Add TASPRTY to the $HEX2. format list in 072400.

Insert after 136100:

TASMSSEV=MOD(TASABMSG,10);

TASABMSG=INT(TASABMSG/10);

Thanks to Rodney L. Reisch, Wacovia Bank and Trust Company, USA.
Change 07.105 Type 6 PSF records had variable FORM wrong, because IBM's

VMAC6 8-byte "form" field in the Common Section of the PSF type

Jun 30, 1989 6 record does not contain the form! This fix may change

Feb 7, 1990 if IBM ever moves an 8-byte form name into the PSF record

but for now, you must change line 021300-021500 to read:

IF SMF6LN3 GE 14 AND SUBSYS NE 'PSF' THEN INPUT FORM $CHAR8. @;

ELSE IF SMF6LN3 GE 14 THEN INPUT +8 @;

Feb 7, 1990 update: SMF6LN3 was printed here in CHANGES

as SMFLN3 in error, and corrected today. VMAC6 was okay.

Thanks to Agneta Bergsten, SPP, SWEDEN.

Change 07.104 Shift calculation changes made in Version 6.6 did not

IMACSHFT affect the SHIFT variable, but the value of the DATETIME

Jun 28, 1989 variable passed back to the caller was not always right.

Since the returned value was used only infrequenly and

only in trending, this should not really cause a problem:

Insert new line 005701:

ELSE IF WEEKDAY(DATEPART(DATETIME)) EQ 2 THEN

Remove ELSE from beginning of line 005800.

Thanks to Gary Kallenber, CONTEL, USA.
Change 07.103 New style macro %VMXGSUM requires SAS System Option of

ANALDB2R MWORK=28K, else an 1453 Invalid Parameter Length error

Jun 28, 1989 occurs. While MWORK=28K was shown in MXG Trending example

in 6.6, rewrite of ANALDB2R using the new style macro did

not remind you to specify MWORK=28K for DB2 reports.
Change 07.102 MXG Tape Mount Monitor SMF record processing code had two

FORMATS formats reversed (lines 004900 and 005000) and failed to

VMACTMNT decode TMNTMTYP (Type of Mount, 0=Demand, 1=Private, and

Jun 28, 1989 2=Scratch) correctly. New format MGTMNTM. added to member

FORMATS. Replace present line TMNTRTRN PIB4. with two:

TMNTRTRN PIB2.

TMNTMTYP PIB2.

Thanks to Ray Dickensheets, Yellow Freight System, USA.

Change 07.101 VM/370 Monitor data for USER class did not exactly match

VMACVMON VMMAP. MXG did not output the first interval record, and

Jun 28, 1989 then deleted the second interval user record in the DIF()

logic. Change line 248700 (precedes EXVMOUSR's include)

to read IF INTRVCNT GT 0 THEN DO; instead of GT 1 THEN.

Thanks to Rob Owens, SAS Institute Europe, GERMANY.

Change 07.100 TMS DSN record caused STOPOVER due to bad logic. Correct

VMACTMS5 by inserting IF I=1 THEN before INPUT in line 0146.

Jun 28, 1989 Also, all packed decimal input fields were precedeed with

?? (between variable and PDn.) to protect if the field

has nulls instead of a valid PD field. The ?? tells SAS

to suppress the "invalid PD" message and to suppress the

hex dump of a record with invalid PD data!

Thanks to Brenda Rabinowitz, Prudential-Bache Securities, USA.

Change 07.099 Default record ID of 255 in IMACAION caused STOPOVER when

IMACAION an SMF ID=255 record (from a diferent product) was read.

Jun 18, 1989 Default should have been 512.

Thanks to Jim Kane, Reader's Digest, USA.

========Changes thru 7.098 were on the 7.0 Beta Tape===================
Change 07.098 Creation of CICS data sets by BUILDPDB beginning in 6.6

BUILDPDB removed the PROTECT=ZZZZZ option from the CICSACCT,

May 31, 1989 CICSEXCE, and CICSYSTM data sets. This could cause an

error when 6.6 attempts to reuse a 5.5 PDB library. (See

extensive discussion of PROTECT= in member CHANGE06). To

avoid the problem, you can simply scratch and reallocate

each PDB library before its re-use. Alternatly, you could

simply delete the three protected datasets from the PDB

library before you run MXG 6.6, by executing:

PROC DATASETS NOLIST DDNAME=PDB MT=DATA;

DELETE CICSACCT CICSEXCE CICSYSTM PROTECT=ZZZZZ;

Thanks to Greg Bowman, Walmart, USA.

Change 07.097 MXG support for type 79 SMF records is not functional.

VMAC79 This member needs lots more work before it can even be

May 31, 1989 tested. Do not try to use or understand it.
Change 07.096 HSM can create an SMF user record, whose contents is in

EXHSMDSR LY35-0080-1 pp180ff as the Daily Statistics Record. The

EXHSMFUN MXG support creates two data sets, HSMDSRST (statistics)

IMACHSM and HSMDSRFU (for each function) from the DSR record.

TYPEHSM There are two other subtypes of the DSR record that are

VMACHSM documented (FSR, p191 and VSR, p348s) but are not yet in

May 31, 1989 this preliminary code. I have only bench tested the code.

Member VMXGHSM contained the basic code for the DSR data

record, and FSR and VSR will be restructures of that code

as well. All of these segments existed (apparently) in a

single SMF record, but there is yet another SMF record

that I can not recognize. This is just a beginning.

Thanks to J. D. Hill, CyCare Systems, USA.
Change 07.095 The VMSQL... datasets created from VM/ACCOUNT cards will

TYPEVM exist only if your VM SQL machine's name (USER) begins

May 30, 1989 with SQLDBA. If your SQL machine has a different name,

see comments in the member. Additionally, data records

with apparently invalid values for SQLCPUTM (FFF91A25x)

have been reported to IBM, but no response yet. MXG uses

PIB4. format, and these values show up as large positive

values. Using IB4. instead would create negative values,

which might be easier to detect if you are looking for

bad values. But I think PIB4. is still safer, since you

can hardly overlook the bad data with large positive data

values, but with mixed positive and negative numbers, the

summing could cause the bad data to be overlooked. You

should always compare CPU measurement with the elapsed

duration of the interval (in this case, how long the VM

SQL machine was executing) to detect this type of IBM

error (which should eventually be fixed by an IBM PTF).

Should I externalize the test for SQL machine name into

a new macro name in a new member of MXG?

Thanks to Norbert Korsche, OMV-AG, AUSTRIA.

Change 07.094 EPILOG CL1000 Version 440 support was tabled until later.

XMACEPIL I did not have all of the DSECTs I need when working on

XXACEPIL XMACEPIL, and when Candle provided me with their sample

May 30, 1989 code, it did not agree with the actual records. Member

XXACEPIL is partially corrected, decoding at least the

header (due to the DSECTS sent for Change 7.090), but

development was pended awaiting DSECTS and test data from

Candle.

Thanks to David Lloyd, Talbots, USA.

Thanks to M. Peller, Braun AG, GERMANY.

Change 07.093 Type 22 SMF record for 3990-3 Cache DASD controller has

VMAC22 had its problems. The subtype 10 data was left out of ESA

May 30, 1989 by IBM, and in the fix to that problem, four new bytes

have been added to the end of the record. Unfortunately,

segment length is not in the data record, and if IBM ever

writes more than one subtype 10 per section, the TYPE22_A

data may be incorrect. This is not an important record.

The missing segment was reported in MVS/ESA with APARS

OY22641/OY11323, and PTFs OY22641/UY90164 add the new

fields and for ESA creates the missing subtype.

Change 07.092 Preliminary support for SMF record created by COMPUWARE

IMACFILA product FILEAID. The access records seem usable, but the

TYPEFILA Field Update and Comprehensive Update records appear to

VMACFILA be of questionable value, especially since pointers do

May 25, 1989 not appear to exist to connect the record to its dataset!

Thanks to Mark A. Hawkes, Monarch Systems Group, USA.

Thanks to Timothy T. Tadeo, Monarch Systems Group, USA.
Change 07.091 This contributed report uses the TYPE30_5 record to count

ANALBATQ how many batch jobs are in the input queue. This report

May 25, 1989 has not been extensively tested yet, and may change.

Thanks to Neil Ervin, Sara Lee Direct, USA.

Change 07.090 Support for Candle's Omegamon Audit (hence OMAU) SMF user

EXTYOMAU record, written for each execution by an operator of an

IMACOMAU audited OMEGAMON command. The code is syntax checked and

TYPEOMAU visually validated with a hex dump of the data. but has

VMACOMAU not been actually used to read real audit records.

May 25, 1989

Thanks to Jonathan Swann, Belk Stores Services, USA.
Change 07.089 Support for AION Development System's SMF record, which

EXTYAION creates data set AIONACCT, an accounting record created

IMACAION when AION executes under IMS.

TYPEAION

VMACAION

May 25, 1989

Thanks to David Daner, Sun Refining and Marketing, USA.
Change 07.088 Variable DOWNTIME in TYPE90 is a duration, not a datetime

VMAC90 stamp and should have been FORMATed TIME12.2 instead of

May 25, 1989 DATETIME21.2. (It really should have been spelled DOWNTM

to be consistent, but its too late to change its name.)

Move DOWNTIME from line 009100 to 009000.

Thanks to Jonathan Swann, Belk Stores Services, USA.

Change 07.087 Support for Amdahl's SE Tool MDFTRACK's SMF record. This

EXTYMDF record describes activity in other MDF Domains, using the

IMACMDF MDFWATCH data. Amdahl cautions that this is not really a

TYPEMDF supported product but instead it is an SE's tool and is

VMACMDF subject to change (and not all fields are documented).

May 25, 1989 - GBLTOD is GMT while GBLBEGTS/GBLENDTS/SMFTIME local.

- GLBENDTS/GBLBEGTS resolve only to seconds.

- GLBINTMS is the actual interval duration.

- Units of DOMMIN,TGT,MAX,NORM,ATGT and GBLELTM? All

are same (and 879.068 if PIB4.3).

- Units of DOMDUTIL, DOMSUTIL,DOMUTIL.

- Validity of DOMNTSC.

- Validity of GBLRSERN.

- Avg Time slice calculation?

By comparing your online screen displays of the numbers

with a PROC PRINT of the MXG-built data sets, you should

be able to figure out how to replicate the screen report

values exactly from the MXG variables. Let me know.

Thanks to Dennis Dwyer, Citicorp St. Louis, USA.
Change 07.086 FOR VM/XA ONLY: Remove both occurrences of STOPOVER in

VMACVMXA the two INFILE statements for VM/XA Monitor processing!

May 24, 1989 I never thought I'd recommend not using STOPOVER, but it

looks like that's the best way to deal with the newest

idiosyncrasy of VM/XA. MONWRITE creates logical records

that span physical blocks! The only case in which this

spanning has occurred so far is the MTRDDR (1.14) record,

written only at VM/XA Monitor Start-Up. A large number of

devices + userids created a 1980 byte record which began

at byte 3021 of one 4096 byte block (1076 bytes in the

first block, 904 in the second). If this had been real

IBM VBS Record Format, SAS could handle spanned records,

but the VM/XA data is a series of blocks of 4096 byte

pages written in blocks of from 4096 to 7*4096=28672

bytes, containing two different sets of control records

interleaved between sequences of blocks of data records.

This non-standard record structure would permit the DCSS

to be re-created in an analysis program. The IBM manual

suggested algorithm required keeping track of page within

block and byte within page and databytes within control

interval; that's a lot of unnecessary CPU processing if

it's really "data processing" (i.e., reading lots of

monitor data) you want. Besides, maybe someday we'll

get MONWRITE re-written to create real, valid, VB data

record format to really minimize the I/O overhead.
The MXG Algorithms treat the VM/XA Monitor data as an

imperfect VB architecture, building heuristics to skip

over defects, such as the End of Frame record, a valid

self-describing 20 byte record followed by an undescribed

number of hex zeros - if the Record Length included the

zeros following the header, the MONWRITE data records

would at least be valid Variable-Blocked data between the

control records! But spanned logical records were not in

IBM documentation, nor seen until now.

The STOPOVER option has been discussed in the book, and

in previous CHANGExx/NEWSLTRS entries. It is very useful

to protect me and you from coding and data errors. It

makes SAS stop reading input records when the MXG program

tries to read beyond the end of the current logical (to

SAS) record. HOWEVER, the simplest fix to the VM/XA

Monitor's "spanning" of data is to remove STOPOVER from

the INFILE statements. SAS will continue on to the next

block with no other change to the MXG algorithm! You will

receive a "SAS READ BEYOND THE END OF A LOGICAL RECORD"

note (which does not set any error condition) on the log.

Martyn Stevens has coded a circumvention which works at

his site, but which works only if the end of each 1.14

record occurs exactly at the end of a page. The removal

of STOPOVER is thought to be a more robust solution, and

it demonstrates the versatility of SAS. The ability to

read multiple logical records as a single data record is

a boon to social scientists with 80-byte card image data,

10 card images per subject. SAS lets you treat that as a

single, 800 byte record (which reduces the human errors

in data entry, coding, etc.). STOPOVER is still useful in

SMF and other structured data records, but I think the

tests built into MXG are strong enough to detect any real

VM/XA errors softly. The removal of STOPOVER in this case

may let the latent power of SAS shine through, but Martyn

says even MISSOVER may not always work and he is sending

a VM/XA monitor tape for further analysis.