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

EXICE8DD causing INVALID DATA FOR DSSRTIME error. DDSRTYPE is

EXICE8DS a four-byte binary and not a one-byte character.

EXICE8NP -New subtype 8 is an extended subtype 6 record that now

FORMATS creates four new MXG datasets, replacing two:

IMACICE ICEBR8CL - Cluster Definition

VMACICE ICEBR8DS - Dataset Name Segment

VMXGINIT ICEBR8SN - Snapped Extents List Segment

Apr 15, 1999 ICEBR8DD - DDSR Extents List Segment

Thanks to Judy Arroyo, Summit Bank, USA.
Change 17.047 Some 24 variables with MGBYTES format also had labels

VMACDCOL with "(MGBYTES)", which misled some to think the field

VMACTSOM contained "mega-bytes". MXG variables formatted with

VMACNETP the MGBYTES format contain bytes, but are converted when

Apr 13, 1999 printed to display their value in K/M/G/T-suffix for

Kilo/Mega/Giga/Tera-byte (i.e., 1024*) units. Because of

this confusion, the "(MGBYTES)" in the LABEL of all

variables was removed. The LABEL of a variable describes

the contents of that variable; the FORMAT of a variable

describes its display format, and implicitly its internal

units (MGBYTES in bytes, TIME/DATETIME in seconds, etc.).

I just read that the International Standards body has

defined new prefixes of KIBI/MEBI/GIBI/TEBI to

explicitly describe "binary thousands", or units of

1024-per-"thousand", so the MGBYTES format formally

supports those units with its "K/M/G/T/P" suffixes!

Change 17.046 ML-19 of ASMTAPES supresses the TMNT005E messages that

ASMTAPES should not have been printed. Originally a message for

Apr 12, 1999 an unexpected event, these messages occur with very fast

mounts. We detected that an ASID has a tape allocation,

but when we (slightly later) scan to that UCB, it no

longer is owned by the ASID number we got at the start

of the sample. Fast scratch VTS mounts now cause this

message to print in flurries, but the message has no

impact on the SMF records created by ASMTAPES, which are

just fine even when there are TMNT0005E log messages.

This correction returns to the caller with an RC-8, which

will cause the main logic to simply continue processing

with the next tape drive. At the next sample interval

we'll detect the ASID change and cut the allocation for

the job that used to have the drive allocated.

Thanks to David Gayle, Alltel, USA.

Change 17.045 Changing the Interval of PDB.ASUM70PR with _DURSET macro

ASUM70PR no longer worked, because of internal changes to VMXGSUM

Apr 12, 1999 to the &DATETIME parameter. To synchronize ASUM70PR with

RMFINTRV, IMACRMFI's _DURSET macro was used in a MYTIME=

argument, instead of using the VMXGSUM interval settings.

Additionally a SHIFT variable was needed to be created,

complicating the old logic. This redesign removed the

MYTIME= and INTERVAL=, and instead substitues the _DURSET

and IMACSHFT statements directly in the INCODE= argument.

This is both simpler and forces synchronization with the

PDB.RMFINTRV that is demanded in the later merge.

Thanks to Mike Hill, Abbey Life Assurance Company Limited, ENGLAND.

Change 17.044 Another typo in the _CDE102 macro causes error if TYPE102

VMAC102 is used to create all 300+ possible IFICIDs. The line

Apr 9, 1999 _C102206 _C102107 _C102108 ... should have been

_C102106 _C102107 _C102108 .... See Change 17.020.

Thanks to Hans Coolen, Zwolsche Algemeene, THE NETHERLANDS.
Change 17.043 Variable FSRDLM was not converted to yyyyddd julian date.

VMACHSM Eleven lines after CC=FLOOR(FSRDLM/100000) statement, the

Apr 9, 1999 IF YYYYDDD GT . THEN FSRBDATE=YYYYDDD; should have been

IF YYYYDDD GT . THEN FSRDLM=YYYYDDD; (Date Last Moved).

Thanks to Solomon Baker, Prudential, USA.
Change 17.042 Type 42 subtype 16 was out of alignment; after the input

VMAC42 of SMF42GAI and SMF42GBI, lines with +3 were inserted

Apr 9, 1999 to skip over the remaining three bytes of those four byte

fields. Type 42 subtype 19 timestamps SMF42JNE/SMF42JNF

are now input as &PIB.8.3 instead of 8.6. Many times that

were documented as microsec in OS/390 R2.6 SMF manual are

now documented as milliseconds in OS/390 R2.7 manual, and

most were caught in MXG 16.16, but these two were missed.

Thanks to Ben Cheung, Bank of Montreal, CANADA.
Change 17.041 The original PDB.ASUMTAPE dataset had SYSTEM='ALL ' for

ASUMTAPE all observations, but that is now corrected and the obs

Apr 9, 1999 will contain the SYSTEM of the Allocate (or Mount, if

there was no Matching Allocate, or Dismount if neither

an Allocate or a Mount was found. MXG sets SYSTEM='ALL'

internally so that grouping is done by DEVNR, but now the

true system is reset into variable SYSTEM.

See Change 17.010 for more complete details on why you

must use the new PDB.ASUMTAPE in place of PDB.TYPETMNT.

Thanks to David Ziems, NationsBank, USA.

Change 17.040 STC SMF record subtype 14 apparently does not always

VMACSTC contain step name and dataset name, STC14SNM/DSN (and

Apr 9, 1999 the label for STC14DSN was typoed too!). Now the MXG

logic tests for those fields existence before input.

Thanks to Jorn Ernebjerg, Kommunedata A/S, DENMARK
Change 17.039 Cosmetic. Typos in example for DATASET=DB2STATB were

DOCMXG corrected. The actual _SDB2STB code in member VMACDB2

Apr 6, 1999 was correct and can be viewed as an example.

Thanks to Engelbert Smets, Provinzial Versicher. Dusseldorf, GERMANY

Change 17.038 Cosmetic. Typos in the list of DDDDDD and DATASET names.

IMACACF2 ACFJEL/ACF2JEL should be ACFJRL/ACF2JRL and ACFAR/ACF2VR

Apr 6, 1999 should be ACFVR/ACF2VR. Only comments were changed.

Thanks to Mike Penlington, WestPac Trust, NEW ZEALAND.

Change 17.037 Support for TANDEM F40, G04, and G05 Operating System

VMACTAND changes to CPU, DISK, and PROCESS (INCOMPATIBLE, because

Apr 6, 1999 you must specify the exact LRECL when you upload TANDEM

records, and the LRECL is different for these records for

these operating systems. A number of new variables,

including Bytes In/Out have been added in this change.

Although these changes have been coded, no test data for

any of these operating systems has been available yet.

Thanks to Kim S. Johnson, NationsBank, USA.
Change 17.036 TPX Start Up record, subtype 1, was not properly decoded.

VMACTPX Now TPX subpool entry count is corrected, and the total

Apr 6, 1999 pool size (instead of entry size) is calculated for each

Apr 8, 1999 of the twelve pools, above and below the 16M line.

Thanks to Tom Parker, CSC Logic, USA.
Change 17.035 DENSITY IS MISSING message will now produce a hex dump of

VMACTMS5 the bad record for the first two errors, for diagnosis of

Apr 6, 1999 the raw record, but the message is no longer printed if

STPNAME='PRE-TMS', which are the only records that that

have had their density field zero.

Thanks to Joe Bruns, Cargill, USA.

Change 17.034 UNEXPECTED TCP/IP DATA VALUE message with TSTTCPCM=STOU

VMACTCP is fixed by adding 'STOU', to the list of commands for

Apr 6, 1999 FTPCLIENT/FTPSERVER events. Also, the message will now

also print a hex dump of the full record for the first

three instances on the SAS log.

Thanks to Pat Hearne, Experian, USA.

Change 17.033 New ratio variables are created in TYPE74CA dataset to

VMAC74 match RMF cache reports and eliminate an extra pass of

Apr 5, 1999 the data in your reports. Variables PCTREAD, TOTDEVHR

and WRITEHR (Percent Read, Device Hit Ratio and Write Hit

Ratio) were added.

Thanks to Bruce Widlund, Merrill Consultants, USA.

Taught my 3-day Class in Dallas, March 31 - April 2, 1999.
Flew to Steve Cullen's retirement at State Farm Mutual Automobile

Insurance Co, Bloomington, Il, on April 2, 1999, in a Lear 25.

Change 17.032 For extended format datasets, HIGHRBA contains not the

VMAC64 highest byte address, but the highest CI number, and

Mar 29, 1999 so MXG stored HIGHRBA into HIGHCIEX, and tried to set the

HIGHRBA to missing (but misspelled it as HICHRBA). But

now, the spelling was corrected and the block of code

for extended format datasets was moved to after the INPUT

of CISIZE, and for extended format datasets, now the

HIGHRBA=HIGHCIEX*CISIZE calculates the highest relative

byte address of these datasets too.

Thanks to Alan Winston, MBNA, USA.

Change 17.031 Documentation. Boole's CMF product can create type 74

VMAC74 subtype 5 Cache records by specifying CMFREC=74 on the

Mar 29, 1999 CACHE control Statement. See CMF Monitor Batch User

Guide and Reference, Version 5 Release 2.3 pp 134-135.

Thanks to Bernd Klawa, Stadt Bielefeld, GERMANY.
Change 17.030 The calculation of RATCNT was revised, based on an email

VMACDMON from a CA technician. They now report that their code

Mar 29, 1999 calculates RATCNT=(RTCNT-RRSCNT)+SSAMPRT; but the old MXG

equation was RATCNT=(RTCNT-RRSCNT)*SSAMPRT+RRSCNT;.

Thanks to Ian Jones, Standard Life Assurance Company, ENGLAND.
Change 17.029 One site encountered syntax errors because two lines had

WEEKBLDT extended into column 72 (which is not wrong, and we can't

Mar 29, 1999 figure out why the one site had a failure), but the blank

before the percent sign was removed in the BYLIST macros

for TYPE72GO and TYPE7204, so that the line had a blank

in column 72, and the syntax error went away. The site

is at SAS 6.09 TS460!

Thanks to Bob LeMaster, Compass Bank, USA.

Change 17.028 TLMS expiration dates of 9990000 caused INVALID ARGUMENT

VMACTLMS TO FUNCTION DATEJUL, and variables BAVEXPDT or BADEXPDT

Mar 28, 1999 had missing values. These fields are now protected just

like TMS: two new variables, ORVEXPDT and ORDEXPDT will

contain the original EXPDT values, and for these non-date

dates (see Change 16.382 for the set of non-date values),

variables BAVEXPDT/BADEXPDT will contain '31DEC2099'D so

than any calculations will return a large value for these

non-date expiration values.

Two statements were changed for each variable in each

TLMS-version-block. The changes for BADEXPDT are:

IF 0 LT BADEXPDT LT 9999999 THEN .... was changed to

IF 0 LT BADEXPDT LT 9900000 THEN .... and

ELSE IF BADEXPDT=9999999 THEN .... was changed to

ELSE IF BADEXPDT GE 9900000 THEN ....

Thanks to Jim VanArsdale, IBM Global Services, USA.

Change 17.027 Support for APAR OW35586 "FICON" channels adds fields to

VMAC73 type 73 record from RMF Monitor I, and the type 79-12 RMF

Mar 28, 1999 Monitor II (optional) record. The TYPE73 and TYPE79C

Jul 11, 1999 datasets have new fields (variables prefixed SMF73 in the

TYPE73 dataset are prefixed R79C in dataset TYPE79C).

Depending on the CPMF Channel Measurement Group for the

Channel, SMF73CMG, one of these two sets of measurements

will be populated in dataset TYPE73:

For SMF73CMG=1, the Group 1 measurements are:

SMF73FG5='CPMF*VALIDATION*FLAGS'

SMF73TUT='TOTAL*CHANNEL*PATH*BUSY*TIME'

SMF73PUT='LPAR*CHANNEL*PATH*BUSY*TIME'

or for SMF73CMG=2, the Group 2 measurements are:

SMF73MBC ='MAXIMUM*BUS*CYCLES*PER SEC'

SMF73MCU ='MAXIMUM*CHANNEL*WORK UNITS*PER SEC'

SMF73MWU ='MAXIMUM*WRITE*DATA UNITS*PER SEC'

SMF73MRU ='MAXIMUM*READ*DATA UNITS*PER SEC'

SMF73US ='DATA*UNIT*SIZE'

SMF73TBC ='TOTAL*BUS*CYCLES*COUNT'

SMF73TUC ='TOTAL*CHANNEL*WORK UNITS*COUNT'

SMF73PUC ='LPAR*CHANNEL*WORK UNITS*COUNT'

SMF73TWU ='TOTAL*WRITE*DATA UNITS*COUNT'

SMF73PWU ='LPAR*WRITE*DATA UNITS*COUNT'

SMF73TRU ='TOTAL*READ*DATA UNITS*COUNT'

SMF73PRU ='LPAR*READ*DATA UNITS*COUNT'

-And these were added to TYPE79C by Change 17.023.

-They provide Channel Path Activity data transfer rates

and bus utilization for FICON bridges (FCV), with new

IBM descriptions:
Bus Utilization: Percentage of bus cycles when

bus has been found busy for

this channel in relation to the

theoretical limit.

Read (MB/SEC) PART: Data transfer rates from the

or control unit for this individual

LPAR partition.

Write(MB/SEC) TOTAL: Data transfer rates from the

control unit for the entire

CPC/CEC.
Change 17.026 APAR OW15406 added YYYY value for IODF Creation Date/Time

VMAC73 IODFTIME. Fortunately, this date is not likely to be

VMAC74 used for anything other than display, if at all! The MXG

Mar 28, 1999 logic to protect the 2-digit YY field in systems without

that APAR was added, and now the MXG code for IODFTIME is

the same for type 73 and type 74 records.
Change 17.025 Adding new variables to the PDB.JOBS/STEPS/PRINT datasets

BUILD005 with the new %LET ADD30U4= NEWVAR1 ... ; syntax is easy,

BUIL3005 but I hadn't thought about an easy way to drop variables

Mar 25, 1999 from those PDB datasets. Of course, you could always do

as before, by copying the appropriate _PDBnnnn macro from

BUILD005/BUIL3005 into your IMACPDB or IMACKEEP member

and blanking out the unwanted variables. But I realized

that by locating all _PDBnnnn macro references to the end

of the KEEP= list (some were, some weren't!), you can now

use the new ADDnnnn macro variable either to add new or

to drop old variables from those three PDB datasets:
%LET ADD30U4= NEWVAR1 NEWVAR2 DROP= UNWANT1 UNWANT2 ;

%INCLUDE SOURCLIB(BUILDPDB);

Since the &ADDnnnn token is at the end of each _PDBnnnn

definition, adding variables worked no matter where the

_PDBnnnn macro occurred after the KEEP=, but the _PDBnnnn

reference must be at the end of the KEEP= list to safely

use the above syntax to both drop and add variables.

In truth, you could have used the ADDnnnn macro to

add and drop, even without my relocating, but you

would have had to protect any variables that followed

the _PDBnnnn reference in the BUILxxxx member by the

use of this syntax for following variables:

%LET ADDnnnn= V1 V2 DROP= X1 X2 KEEP= ;

because SAS accepts this syntax:

DATASET (KEEP=list DROP=list KEEP=list )

Thanks to Larry Melamed, SHL Systemhouse, CANADA.

Change 17.024 I can't seem to ever get VMACIMSA right. Line 1374 has a

VMACIMSA missing semicolon. Actually, the semicolon was in column

Mar 25, 1999 73, which MXG truncates under MVS because S=72 is set in

CONFIG, but my testing under ASCII accepted the longer

record. Shift the line left and put the semicolon in 72.

Thanks to Pete Young, University of Toronto, CANADA.

Change 17.023 -CPU time for Pre-emptible SRBS running in this ASID, and

TYPE79 the CPU time for Pre-emptible SRBs running on behalf of

TYPS79 this ASID, and the Total CPU time consumed in this ASID

VMAC79 are now variables R791ASST/R791PHTM/R791TCPC in TYPE791

Mar 25, 1999 dataset, and R792ASST/R792PHTM/R792TCPC in TYPE792. The

Mar 28, 1999 fields were added by OS/390 Version 2 Release 5.

-In validating the TYPE791 dataset, I note that it has

mostly-accumulated fields, so the _STY791 Sort macro now

includes additional data steps to deaccumulate the data,

and the deaccumulation is automatic if you use member

TYPS79. Or you can use TYPE79 and then invoke _STY791,

so that dataset TYPE791 contains valid interval values.

-Support for FIBERCON/FICON new measures were added. See

text of Change 17.027 for details of new measurements, as

the same variables were added to TYPE73 as to TYPE79C.

-In TYPE79 and TYPS79, the line with _CDE79S was deleted

because it did not belong there; fortunately it had no

external impact, except to confuse my debugging!

Thanks to Tim Crocker, National Council on Compensation Insurance,USA
Change 17.022 IMS 6.1 only, MXG 16.16 still was wrong. Six lines with

VMACIMSA "DHMS(DATEYYYY," must be "DHMS(DATEJUL(YYYYDDD),"

Mar 24, 1999 so that timestamp values are not missing. While IMS 6.1

records had been validated with MXG 16.09, VMACIMSA was

later "cleaned up" to create unique julian date fields to

examine for debug that were not kept, and that revision

introduced this error in MXG 16.16.

Thanks to Chris Weston, SAS Institute Cary, USA.

Change 17.021 HSM and TMS Julian Date variables are internally Y2K ok,

VMACHSM but their default print format was still "6.", causing a

VMACTMS5 julian date of 2000001 to print as 2E6. The default

Mar 19, 1999 print format is now changed from "6." to "7." in both

members, but the MXG 16.16-built datasets are still

completely valid internally, and you can add a statement

FORMAT DSRDATE 7.; in your reports to print the seven

digit julian dates.

Thanks to John McCray, Huntington Services Company, USA.
Change 17.020 Typo in the _CDE102 macro causes error if TYPE102 is used

VMAC102 to create all 300+ possible IFICIDs. The text _C012297

Mar 19, 1999 should have been _C102297.

Thanks to Jules Troxler, Swiss National Bank, SWITZERLAND.

Change 17.019 The definition of HSM macro _DIFFHSM was relocated from

DIFFHSM the DIFFHSM member to the VMACHSM member so that you can

VMACHSM redefine the _DIFFHSM macro if you only want one HSM

DOCMXG dataset. For example, after this change, to create only

Mar 19, 1999 the HSMDSRST dataset, you could use:

%LET MACKEEP=

_NHSM

MACRO _WHSMDSR HSMDSRST %

MACRO _DIFFHSM _SHSMDSR %

;

Bob also found a type in DOCMXG examples; the second use

of _N110 example needed a second percent sign to end the

MACRO _ECICTRN definition as it is inside the %QUOTE.

Thanks to Bob Barton, DaimlerChrysler, GERMANY.
Change 17.018 NPM 2.4 only. Datasets NPMINSES and NPMEVSAL have trash

VMAC28 in LSCDxxxx variables. IBM added fields for IP address

Mar 16, 1999 and IP Port Number, but I misread the DSECT and thought

they were inserted; in fact they overlaid existing fields

causing the INPUT statement to be miis-aligned with data.

There are two places that needed correction.

The original code in the first location was:

SLNKNAME $EBCDIC8.

@;

IF COFTYPE='SCD' AND LSCDREVL GE 3 THEN INPUT

LSCDIPNM $EBCDIC15.

@;

INPUT SLUSUBPU $EBCDIC8.

and the correct code in that location now is:

SLNKNAME $EBCDIC8.

@;

M16=-16;

IF COFTYPE='SCD' AND LSCDREVL GE 3 THEN INPUT

+M16 LSCDIPNM $EBCDIC15.

+1

@;

INPUT SLUSUBPU $EBCDIC8.

to back up 16 bytes and input LSCDIPNM correctly.
The original code in the second location was:

VRNUM &PIB.2.

@;

IF LSCDREVL GE 3 THEN INPUT

LSCDIPPN $EBCDIC5.

@;

INPUT

TRANPRTY &PIB.2.

and the correct code in that location now is:

VRNUM &PIB.2.

@;

M5=-5;

IF LSCDREVL GE 3 THEN INPUT

+M5 LSCDIPPN $EBCDIC5.

@;

INPUT

TRANPRTY &PIB.2.

to back up 5 bytes and input LSCDIPPN.

Thanks to Steve Donahue, Blue Cross Blue Shield of Texas, USA.
Change 17.017 Cosmetic. The BY list for the TYPETMNT dataset in the

ASUMTMNT ASUMTMNT and TRNDTMNT members had "DATETIME", but that

Mar 15, 1999 can now be changed to the real variable name of TMNTTIME

Apr 5, 1999 (changes to VMXGSUM several versions ago made that change

possible), and the sort order in TRNDTMNT was changed

changed from ... SHIFT DEVICE ... to ...DEVICE SHIFT ...

to be consistent with the prior sorts. In addition, the

ID=TMNTTIME, statement has to be deleted for this change.

Thanks to John Sheridan, Aer Lingus, IRELAND.
Change 17.016 RMM EDGR dataset EDGRDEXT has zero observations because

VMACEDGR _EEDGRV /*INC SOURCLIB(EXEDGRD); _WEDGRD OUTPUTS EDGRDEXT*/

Mar 15, 1999 should have been:

_EEDGRD /*INC SOURCLIB(EXEDGRD); _WEDGRD OUTPUTS EDGRDEXT*/

Thanks to John Paul, Capital Blue Cross, USA.
Change 17.015 The input dataset was WEEK.PRINTER but member ASUMPRTR

TRNDPRTR now creates WEEK.ASUMPRTR, so the input was changed to

Mar 11, 1999 WEEK.ASUMPRTR. The output remains TREND.PRINTER.

Thanks to John McCray, Huntington Service Company, USA.

Change 17.014 Documentation and revision. The original 16.16 example

UTILBLDP did not properly handle SMF records that had fixed ID,

Mar 24, 1999 such as IBM type 39 records, and there was a missing

end comment sign.

Change 17.013 Dataset TYPE21/PDB.TAPES variable OPEN is always blank

VMAC21 now (MXG 16.04+), but it used to always be "INPUT". In

Mar 9, 1999 fact, the DCBOFLGS field that is tested to set OPEN is

not valid, since it always contains nulls in our data.

(IBM documentation says that if no bit is on in that

field, it was not available to the SMF record). Since

the type 21 record now contains BYTEREAD and BYTEWRIT,

which are clearer indicators of activity, I will leave

the code as it is, with OPEN=blank. If IBM every fixes

the record to retain the DCBOFLGS, then the MXG code

will populate OPEN. In addition, if the new ASUMTAPE

is enhanced to merge in TYPE1415 records, the actual

OPEN value will be available with that analysis.

Thanks to Khoan Dang, MBNA, USA.

Change 17.012 RACF type 80 record with optional RACFTYPE=7 user segment

VMAC80A had INPUT STATEMENT EXCEEDED RECORD LENGTH error. Delete

Mar 8, 1999 the statement INPUT +RACFDLN @; that is immediately after

the statement WHEN (7) DO;

Thanks to Joseph J. Faska, Depository Trust, USA.
Change 17.011 MXG 16.09-MXG 16.16. TYPEIMSA processing is wrong, with

VMACIMSA missing values for STRTTIME. There is one instance of

Mar 8, 1999 DATEJUL(YYYDDD) that has only three YYYs, and that must

be changed to four YYYYs: DATEJUL(YYYYDDD).

Thanks to Werner Bundschuh, SAS Institute, EUROPE.

Thanks to Dr. Harald Lindenmuller, Bayerische Beamtenversich, GERMANY

Change 17.010 MXGTMNT can miss some mounts or can create false ones!!

ASMFTAPE

ASUMTAPE The MXG Tape Mount and Tape Allocation Monitor program

ASUMTMNT MXGTMNT (in member ASMTAPES), has two newly discovered

Mar 11, 1999 serious errors in dataset PDB.TYPETMNT:

Apr 5, 1999

- extra tape mount event records may be created during

allocation recovery with a NOHOLD reply, and

- some very fast VTS scratch mounts are missed.
Fortunately, those errors can be corrected with the new

ASUMTAPE program, which will read these PDB datasets:

PDB.TYPETMNT - Sampled Tape Mount Events

PDB.TYPETALO - Non-sampled Tape Allocation Events

PDB.TAPES - Rename of TYPE21, IBM Dismount Tape

to create the new PDB.ASUMTAPE dataset, that not only

discards any extra mounts, but recognizes missed-mounts