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

Change 09.177 MXG PreRelease 9.4 produced zero observations in DB2data

VMACDB2H sets, with no error message. A last-minute "cosmetic"

Nov 25, 1991 change to label the new 2.3 variables corrupted the code.

(The last 32 lines, starting at line number 01860000 must

be moved to after line 005500).

Thanks to Ted Garner, First Union, USA.

Change 09.176 IMS Abend condition codes were always blank, and because

TYPEIMS Change 9.106 was incorrectly located in MXG 9.3, the

Nov 28, 1991 resources for multi-trans were incorrect.

Thanks to Pete Shepard, Ashland Oil, USA.

--Changes thru Change 9.175 were in MXG PreRelease 9.4 dtd Nov 15, 1991
Change 09.175 BUILDPDB has been significantly enhanced. DB2ACCT/STAT

BUILD518 datasets are now added to your PDB from type 100/101 SMF

BUILD606 records. SAS 5.18 users should be able to add many more

BUIL3518 SMF records to their PDB before a SAS 344 Compiler error

BUIL3606 is encountered. However, this change is INCOMPATIBLE for

BUILDPDB SAS 5.18 sites; a new DD statement is required in the JCL

VMACDB2 for the BUILDPDB/3 step (only for SAS 5.18):

VMACSMF

Nov 15, 1991 //SMFTEMP DD UNIT=SYSDA,SPACE=(CYL,(20,20))
An additional INCOMPATIBILITY exists for all BUILDPDB/3

sites that have added DB2 processing to their PDB (this

would have been done by editing members EXPDBINC,EXPDBVAR

EXPDBCDE and EXPDBOUT members as described on pp 134ff of

the MXG Supplement). If you have added DB2 processing,

it must be removed or BUILDPDB will syntax error.

This redesign was caused because the "vanilla" BUILDPDB

in MXG 9.4 could not be compiled under SAS 5.18. The

additions for MVS/ESA, CICS/ESA, etc., added iterative DO

statements, causing a SAS 5.18 "344 Compiler Error". To

circumvent this error, now, (for SAS 5.18 only), MXG

writes RMF 71 and 73-78 records to the (new) SMFTEMP file

while reading your SMF input, and then executes a second

data step to process that small SMFTEMP file. (Type 70,72

records are not split out, because type 30 processing

needs IOCCOEFF to calculate EXCPRMF!). Splitting the

data step reduced the number of iterative DO statements,

avoiding the "344 Error" for sites which have added other

SMF record processing (using the MXG Exit Facility, pages

134-140 of the MXG Supplement). The circumvention that

was previously described in Change 7.038 (in CHANGE07) is

no longer applicable (except for the possible use of the

XMAC7072 member), since MXG has split the RMF processing

out. Since RMF data is not large volume (perhaps 9MB

per day per system at 15 minute intervals), there is very

little increase in processing time.

Unfortunately, this elimination of the 344 SAS error may

only serve to uncover yet another SAS 5.18 limitation. A

160 SAS error occurs if the total length of all variables

in a SAS data step exceeds a SAS 5.18 internal limit, and

there's NO circumvention for the 160 error. If received,

you must remove some of your additional SMF records from

the EXPDB.. members, and instead use IMACFILE member to

write your SMF records the SMFTEMP DD, which can then

be processed in a subsequent step of your job. (Or, you

can use SAS 6.06/6.07 for just the BUILDPDB step and use

a LIBNAME statement to build your PDB datasets in SAS

version 5.18 format).

Note there is no change for SAS Version 6; the compiler

limit does not exist in SAS Version 6, and BUILDPDB logic

uses %MACROs to detect you are executing under Version 6,

and MXG processes all SMF data in one pass; there is no

need for the SMFTEMP DD name under SAS 6.07/6.07.
Adding DB2 processing had been desired for some time, but

because of the 5.18 problems, it could not be easily done

until now.
Change 09.174 Divide by zero error occurred for the type 79 record for

VMAC79 the interval in which the clocks were set back this Fall!

Nov 14, 1991 The record had a duration of 0 seconds after the operator

changed the clock. Now, divides by DURATM are checked to

be non-zero before the divide. Also, RMF 3.5.1 caused a

STOPOVER on type 79 subtype 3 that is now protected.

Thanks to Fred Fettinger, Rockwell Graphic Systems, USA.
Change 09.173 Support for LEGENT's MIM (Multi-Image Manager) user SMF

EXTYMIM records was added by this user contribution. A single

IMACMIM dataset, MIMTAPE, is created from this record.

TYPEMIM

VMACMIM

Nov 14, 1991

Thanks to Doug Drain, National City Bank, USA.
Change 09.172 Support for Softtool Corporations's CCC (Change and

ANALCCC Configuration Control software is added by this user

EXTYCCC contribution. Example reports are also provided, but

IMACCCC will require an installation format for processor power.

TYPECCC

VMACCCC

Nov 14, 1991

Thanks to Sue Swayne, Inland Revenue (UK), Worthing, ENGLAND.

Change 09.171 The collection of RACF reports added by change 9.064 had

ANALRACF invalid concatenation symbols (because the code went

Nov 12, 1991 from MVS to a PC and back!). The reports were also

slightly revised and enhanced.

Thanks to Duncan McKellar, Inland Revenue (UK)

Thanks to Neil Campbell, Inland Revenue (UK)

Thanks to Dave McLaughlin, Inland Revenue (UK)
Change 09.170 FTP SMF records produced no observations because test to

VMACFTP ensure there was data was incorrect. Eleven occurrences

Nov 12, 1991 OFFDATA+(NRDATA*LENDATA) LE LENGTH THEN ...

must each be changed to

OFFDATA+(NRDATA*LENDATA) LE LENGTH+1 THEN ...

Thanks to Kueller, Spardat Wien, AUSTRIA.

Change 09.169 TYPE59 variable QUEUTIME was not formatted DATETIME21.2,

VMAC59 nor was it set to stored length of 8 bytes, but now it

Nov 12, 1991 is!

Thanks to Siegfried Trantes, Gothaer Versicherungsbank VVAG, GERMANY.

Change 09.168 A CICS region ABEND caused Landmark to write a "trashed"

TYPEMON8 record that contained invalid values for the offset to

Nov 11, 1991 variable segments. Because MXG did not validate that

the offset value was actually in the record, MXG failed

(with "INPUT STATEMENT EXCEEDED RECORD LENGTH"). There

are three DO statements that need to be protected. Find

the following 3 DO statements in TYPEMON8, and insert

the four lines of protection preceding the existing DO

statement:

IF FILECOL+FATNUM*TAFATLEN GT LENGTH+1 THEN D0;

PUT 'BAD RECORD FOUND AND DELETED '; LIST;

DELETE;

END;

DO FILESEG=1 TO FATNUM;

IF UATCOL+UTNUM*TAUATLEN GT LENGTH+1 THEN DO;

PUT 'BAD RECORD FOUND AND DELETED '; LIST;

DELETE;

END;

DO USERSEG=1 TO UTNUM;
IF MROCOL+MRONUM*TAMROLEN GT LENGTH+1 THEN DO;

PUT 'BAD RECORD FOUND AND DELETED '; LIST;

DELETE;

END;

DO MROSEG=1 to MRONUM;

Thanks to Freddie Arie, Lone Star Gas, TEXAS.

Change 09.167 Support for Codework Software's SNAPAD-MVS product user

EXSNAPAD SMF record. SNAPAD lets mainframes talk to X.25 packet

IMACSNAP switching networks. Feb 20, 1992: This code has now

TYPESNAP been tested and verified, superceeding the note in this

VMACSNAP change printed in Newsletter TWENTY-ONE.

Nov 10, 1991

Thanks to Dennis Uy, Asian Development Bank, PHILIPPINES.
Change 09.166 MXG incorrectly calculated Full Duplex line utilization

VMAC28 PCTBUSY. For half duplex, the calculation was correct.

Nov 10, 1991 Since a Half Duplex line has only one set of buffer for

both send and receive, MXG summed the send and receive

bytes and divided by the send (primary) line speed:

PCTBUSY=800*(BYTSPRSC+BYTSSCPR)/(NCPTM*NPMPLS);.

(The 800 is used because line speed is in baud).

But for a Full Duplex line, there are 2 sets of buffers,

one for send and the other for receive. Thus there are

two separate utilizations that can be calculated. Since

the purpose of PCTBUSY is to identify utilization, and

since the line is out of speed when either its send or

its receive utilization is 100%, MXG now calculates the

PCTBUSY for full duplex as the Maximum of the send or

receive (primary or secondary) utilization:

PCTBUSY=MAX(800*BYTSPRSC/(NCPTM,NPMPLS),

800*BYTSSCPR/(NCPTM,NPMSLS));

MXG's previous calculation for Full Duplex turned out to

be the average of the send and receive utilizations, and

thus underreported the typical utilization in which one

direction predominates.

Thanks to Lee Lik Cheung, DBS Bank, SINGAPORE.

Change 09.165 Support for LEGENT's LANSPY component of NETSPY 4.1 that

EXNSPYLF captures LAN resources and responses in five new MXG

EXNSPYLG datasets. LANSPY creates record segments even when

EXNSPYLL there was no activity on the LAN, but MXG only outputs

EXNSPYLR observations if the activity counts are non-zero (the

EXNSPYLS decision logic is located in the Exit member EXNSPY..).

VMACNSPY This support has been tested with actual LANSPY data,

Nov 10, 1991 thanks for excellent vendor support from Legent.

Change 09.164 This change is primarily internal in that most user will

ANALDB2R not explicitly see these changes, but they are under the

READDB2 cover significant enhancements to DB2 processing. In

VMAC102 VMAC102, new macros of the form _LTRccnn now are defined

Nov 8, 1991 that are the list of the IFCIDs in each trace class.

These list macros are then used by the new READDB2 macro

(invoked by ANALDB2R when PDB=SMF is specified) so that

MXG only processes the IFCIDs that are needed, based on

the reports you have requested. You no longer have to

manipulate member IMAC102 to process trace records, and

this re-design should execute significantly faster.

Note that READDB2 can be invoked independently if you

wish to create datasets from subsets of DB2 data; it

is self documenting. The old keyword parameter names

for trace class selection (DB2TC1-DB2TC16, etc.) do not

exist (they were replaced by the new TRACECLS parameter),

and you will get "KEYWORD PARAMETER NOT DEFINED" errors

if your ANALDB2R invocation uses the old names.

Change 09.163 Trend Data Base updates. DB2ACCT, DB2STAT0, DB2STAT1

TRNDDB2A have been updated to add some new DB2 2.3 variables for

TRNDDB2S identification, if they exist (i.e., when you have DB2

TRND70 2.3 data. New member TRND70 trends RMF TYPE70 dataset.

Nov 8, 1991
Change 09.162 Cosmetic (but then looks do count!). TYPE22_A bit maps

VMAC22 of 3390-3 status should have been formatted $HEX2./$HEX4.

Nov 8, 1991 Now they are correctly formatted to describe status bits.

Thanks to Harry Price, Florida Power and Light, USA.

Change 09.161 CICS/ESA only, DBCTL EMP data only. In IMACICDB, the +98

IMACICDB after STATBFWT should have been +100 (but this would have

VMAC110 only caused a problem if you had additional user data

Nov 8, 1991 after the DBCTL EMP - if you did and decoded that user

data you will have been off by two bytes in your code).

However, IBM has added a new field in those former +100

bytes, so this change in IMACICDB replaces the old +98

with STATUSSN PIB4.

+96

and adds a label STATUSSN='USSN*NUMBER'. In VMAC110, the

new variable is added to the KEEP= list for CICSTRAN.

Thanks to Barry Pieper, First Bank Minneapolis, USA.

Change 09.160 MXG 9.3 only, VMXGVTOF processing of ASMVTOC output will

VMXGVTOF cause "Invalid data for STARTIME" because the variables

Nov 6, 1991 UNITADDR, UCBTYPE and STARTIME (added by Change 9.099)

were off by one byte. The input @151, @154, and @158

for those three variables must be @152, @155, and @159.

Thanks to Normand Poitras, Teleglobe Canada, CANADA.

Change 09.159 A potentially serious error in VTOC/VTOF processing (only

VMXGVTOC under SAS 5.18, not under SAS 6.06+) has been found. The

VMXGVTOF error appears to have been introduced in MXG 7.2 (October

Nov 6, 1991 1989!). If you have this error, dataset VTOCLIST will

describe only the space used by the first three extents!

You have the error if VTOCLIST variable NREXTNTS (extent

count in the DSCB1) is greater than variable NUMEXT (MXGs

count of extents). The logic error is the location of

the CALL SYMPUT; it is now known that under SAS 5.18 the

CALL and STOP must be located after the SET statement for

the below logic to have ever worked:

DATA _NULL_;

POINT=1;

CALL SYMPUT('MXGOBS',PUT(NOBS,7.0));

STOP;

SET DSNAMES POINT=POINT NOBS=NOBS;

RUN;

%IF &MXGOBS EQ 0 %THEN %LET I=11;

Because the CALL was mislocated, &MXGOBS was always zero,

causing MXG to prematurely terminate extent processing.

(Under SAS 6.06, it turns out, the logic worked!). But

the following logic is more straightforward and has now

replaced the above logic in VMXGVTOC and VMXGVTOF:

DATA _NULL_;

IF EOF THEN CALL SYMPUT('MXGOBS','0');

ELSE CALL SYMPUT('MXGOBS','1');

STOP;

SET DSNAMES END=EOF;

RUN;

%IF &MXGOBS EQ 0 %THEN %LET I=16;

Additionally, the %DO statement twenty lines before this

code was changed to 15 instead of 10 (which corresponds

to changing the %LET I= value from 11 to 16), because it

is theoretically possible to require up to fifteen passes

of the extent merge (I've not seen more than two needed).

The actual change in MXG is more extensive; in addition

to the above logic changes, NREXTNTS is now compared to

NUMEXT and an error message produced on the log if data

has been lost (and some of the work dataset names used

in the matching process were renamed to make diagnosis

of any future problems more tractable).

Thanks to Joseph Rannazzisi, Brooklyn Union Gas, USA.

Thanks to Al Acosta, Brooklyn Union Gas, USA.
Change 09.158 The NETVIEW VPD record type "E", end subrecord STOPOVER.

VMACVPD Variables VPDRSRV1 and VPDDCCAL must be $CHAR8. instead

Nov 5, 1991 of $CHAR12. Offset for VPDDCCAL and VPDRSRV2 must be 86

and 94 instead of 90 and 102. Additionally, informat for

VPDRECNT, VPDPUCAL, and VPDDCCAL were changed from $CHAR8

to ?? 8. so they are changed from character to numeric.

Thanks to Jim Nicholas, Mead Data Central, USA.
Change 09.157 Two DCOLLECT variables, DCDLBKDT in DCOLDSET, and UMLBKDT

VMACDCOL in DCOLMIGS, were previously $CHAR8. (because IBM did not

Nov 5, 1991 choose to document the internal contents, and test data

used for MXG validation had only zeros in those fields.)

Both variables are now changed from character to numeric;

this change may cause a problem if you combine the DCOL..

datasets from before and after the change, but the long

term benefit of having the correct field name and format

out weight the short term impact. Furthermore, BEFORE

and AFTER datasets can be combined while deleting the

previous character variable with simple logic:
DATA DCOLDSET; SET OLD.DCOLDSET (DROP=DCDLBKDT)

NEW.DCOLDSET ;

Thanks to O. V. Hanger, A. C. Nielsen Co., USA.
Change 09.156 DB2 2.3 final validation and documentation found several

VMACDB2 changes, mostly cosmetic, were needed.

Nov 5, 1991 1.DB2ACCT/DB2STAT1 variables QTXABLLM,INLM,IOLM,SALM,SELM,

and SPLM were deleted, as they were completely redundant

with decoded values of QTXAPREC. They had been used in

tests in ANALDB2R, but those tests were replaced with the

explicit tests for values of QTXAPREC. Also, variables

QTXAILMT and QTXANRUN are now set based on bit tests (the

previous tests for '80'X and '40'X were incorrect). Also

variables QTXACHUS and QTXACLMT are now format TIME12.2.

2.DB2STAT0 variable QLSTBRBF needed asterisks in its label.

Variables QWS4ASCB and QWS4ASID are now kept, variables

QWS4EJST and QWS4SRBT are formatted TIME12.2. The twenty

address space variables (prefix QWS1,QWS2,QWS3,QWS4 and

suffix ASCB,ASID,EJST,PROC,SRBT) labels now name each of

the address spaces, and MXG now stores the data for each

address space consistently in these prefixes (in spite of

IBM's inconsistent use of the 3rd and/or 4th buckets!):

QWS1 - Master, or system services address space

QWS2 - DBM1, or data base services address space

QWS3 - IRLM, or inter-region lock manager address space

QWS4 - DDF, or distributed data facility (values will

be missing if no DDF).
Change 09.155 TYPE22_7 variables CHOWNED and CHONLINE are set in lines

VMAC22 lines 079600 and 079700, but were not reset if bit test

Oct 17, 1991 was not satisfied, causing values to be propagated. Now

ELSE CHOWNED=' '; and ELSE CHONLINE=' '; were inserted

respectively.

Thanks to Bruce Read, Attorney General's Department, AUSTRALIA.

Change 09.154 NETSPY variables STARTIME and STOPTIME are reversed in

VMACNSPY lines 089100 and 089200. STOPTIME is based on DTEE/TMEE

Oct 17, 1991 and STARTIME is based on DTES/TMES.

Thanks to Lois Robinson, M & I Data Services, Inc, USA.

Change 09.153 Type 6 "INPUT STATEMENT EXCEEDED RECORD LENGTH" results

VMAC6 from LEGENT's Bundle product record which is logically a

Oct 16, 1991 normal External Writer record, but because the record now

contains the characters "BU" instead of the normal zero

in the SUBS field, the shorter EXTW record format was not

recognized by MXG. Now, SUBS=49892 ("BU" as PIB2.) sets

SUBSYS='BUND', and the two tests for 'EXTW' are extended

to treat 'BUND' as 'EXTW', thereby adding support for

the Bundle product in MXG.

Thanks to David Kyle, Dominion Bankshares, USA.

Change 09.152 Support for new Tape Device 3490E added. In MXG datasets

VMACEXC2 TYPE434, TYPE30_V, TYPE30_4, TYPE30_5, TYPE30_6, TYPE40,

VMACUCB variable EXCP3490 is created, in the TYPE30_n datasets

VMAC30 variable IOTM3490 is created, and in datasets TYPE434

VMAC40 and TYPE30_N variable TAPE3490 is created. Change 9.002

VMAC434 created a new value for the variable DEVICE, but did not

Oct 9, 1991 create these new variables. Because the 3490E format is

Aug 19, 1995 completely different than 3480s or the earlier 3490s, it

was consistent with MXG treatment of devices to create

these three new variables in the appropriate datasets.

MXG Internals Architecture Note for the record:
Addition of new device type in MXG requires knowledge of the values

of device class DEVCLASS and device type DEVTYPE returned by the IBM

macro DEVTYPE so that the new variables EXCPnnnn, IOTMnnnn, (and for

tape devices, TAPEnnnn) can be created. The changes that are then

made in MXG (not by you - these are the changes that MXG made when

an MXG Change states "Support for new DASD/Tape Device nnnn added"):

For new DASD device:

a) VMACUCB - create new value for DEVICE within device class.

b) VMACEXC2 - create new DO group within device class.

IF DEVTYPE=0hhX THEN DO;

EXCPnnnn=SUM(EXCPnnnn,EXCPCNT);

IOTMnnnn=SUM(IOTMnnnn,IOTM);

END;

c) VMAC434 - Label EXCPnnnn

d) VMAC40 - Label EXCPnnnn

e) VMAC30 - Label EXCPnnnn, IOTMnnnn

- Add IOTMnnnn to TIME12.2 format list.

f) IMAC30IO - Add EXCPnnnn, IOTMnnnn to respective macros.

For new Tape device:

a) VMACUCB - create new value for DEVICE

b) VMACEXC2 - create new DO group:

IF DEVTYPE=0hhX THEN DO;

EXCPnnnn=SUM(EXCPnnnn,EXCPCNT);

IOTMnnnn=SUM(IOTMnnnn,IOTM);

END;

- create new counter within device class tests:

IF DEVTYPE=0hhX THEN TAPEnnnn=SUM(TAPEnnnn,1);

c) VMAC434 - Label EXCPnnnn,TAPEnnnn

- Keep TAPEnnnn

d) VMAC40 - Label EXCPnnnn

e) VMAC30 - Label EXCPnnnn,IOTMnnnn,TAPEnnnn

- Keep TAPEnnnn

- Add IOTMnnnn to TIME12.2 format list.

f) IMAC30IO - Add EXCPnnnn, IOTMnnnn to respective macros.

g) IMACPDB - Add TAPEnnnn to the _PDB30_4 and _MAXSTP macros.

- Then, in the PROC MEANS logic that follows, the

X10 in the DROP= list must be changed to X11, and

X11 must be added after the X10 in the SUM= list.

In addition, member FORMATS must be scanned for all occurrences

of the previously-newest-device-of-this-class. (Eg, when adding

support for 3590 tape drive, locate all occurrences of 3490 in

all formats). Only one or two formats use the IBM DEVCLASS and

DEVTYPE values (eg., '8083' for 3590s); those you can directly

update. The rest (currently, EREP and ZARA) have their own, non-

standard table of values, and their vendor must be contacted to

determine what value they chose.

This note was revised August 19 and again September 22, 1995.
Change 09.151 Support for new DASD Device 9345 added. In MXG datasets

VMACEXC2 TYPE434, TYPE30_V, TYPE30_4, TYPE30_5, TYPE30_6, TYPE40,

VMACUCB variable EXCP9345 is created, and variable IOTM9345 is

VMAC30 created in the TYPE30_n datasets. The new device has a

VMAC40 tracksize of 46456 (after R0 is on the track), with 15

VMAC434 tracks per cylinder, and 1440 cyl per vol on Model 1 or

Oct 9, 1991 2156 cyl per vol on Model 2.
Change 09.150 Cosmetic changes. Comments describing the expected sort

ANALCICS order were clarified, and the second occurrence of

Oct 8, 1991 TASCPUTM=0; was deleted.

Thanks to John Chapman, British Gas, ENGLAND.

Change 09.149 DB2 report PMACC01 could produce zeros in two places due

ANALDB2R to MXG typing errors. The two lines now reading

Oct 8, 1991 GSWS=QBACSWS; and L2SWS=QBACSWS; should read

GSWS+QBACSWS; and L2SWS+QBACSWS; respectively.

Though not causing an error, lines 012560-012970 (IF _N_

.... END;) were deleted, as those variables were already

initialized by the RETAIN statement.

Thanks to Susan Marshall, SAS Institute Europe, GERMANY.

Thanks to ???, ORDA-B, BELGIUM.
Change 09.148 Cosmetic enhancement to MXG messages when reading SMF.

VMACSMF MXG now prints additional information on the SAS log

Oct 4, 1991 when reading SMF data. The start and end times and the

system id for each dump event are now printed (from the

type 02/03 records) preceding the "SUCCESSFULLY READ"

message, and the minimum and maximum timestamp of any

SMF record are also printed. The 02/03 pairs are very

useful to detect problems in SMF dump processing (if you

don't have matched pairs for each system, you had a real

problem, and if you have duplicate data you can see the

record numbers so you can copy the SMF file, deleting

the duplicate records based on these log messages).

Thanks to John Chapman, British Gas London, ENGLAND.
Change 09.147 Support for Omegamon for CICS/ESA Version 550 user SMF

EXOMCADA record created by ESRA, INTR, SYSINIT, and OMDV. There