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

to associated END;) TO AFTER line 012500. In the new

block you copied:

-Add OR RACFQUAL=200 after RACFQUAL=201

-Change both tests for RACFDLN GE 3 to RACFDLN GE 1

-Change SUBSTR(RACFDATA,3,1) to SUBSTR(RACFDATA,1,1)

in ten statements within this copied block.

-Delete the statement OUTPUT INSUF;

-Now, go back to lines 016300 thru 018100, delete the

entire block, and replace it with these two lines:

016400 IF RACFQUAL=201 THEN OUTPUT INSUF;

016500 IF RACFQUAL=200 THEN OUTPUT SUF;

b.Additional cosmetic changes made for next Version that

are truly optional for now:

-In ANALAUDT, after RETAIN at line 009400 new line:

FORMAT ALLOW INTENT MG080AI.;

-In FORMATS, after MG080EV definition, add new format:

VALUE MG080AI

0='0:ALTER'

1='1:CONTROL'

2='2:UPDATE'

3='3:READ'

4='4:NONE'

;

c.One additional change, but only for users of the FACOM

operating systems type 80 records. Format MG080QU has a

slightly different meaning for four values, which are

changed in member FORMATS (after VALUE MG080QU) to now

describe either IBM or FACOM type 80 records:

101:INVALID PASSWORD (FACOM: OR GROUP)

102:INVALID GROUP (FACOM:UIDCARD)

103:INVALID OIDCARD (FACOM:TERMINAL)

104:INVALID TERMINAL (FACOM:APPLICATION)

Thanks to Ingrid Ahmer of Australian National, AUSTRALIA.

(railways), who sent an excellent discussion and fix for the code

relocation logic.

Thanks to Thomas Peiper, KommunData, SWEDEN.

Change 07.046 MVS Step Accounting fields were decoded in MXG TYPE30_4

IMACACCT variables ACCOUNTn, but BUILDPDB/3 does not carry these

IMACPDB STEP accounting fields into PDB.STEP. Instead, the JOB

VMAC30 accounting variables ACCOUNTn from the TYPE30_1 (Init)

Apr 30, 1989 or TYPE30_5 (Job termination) records are used through

out BUILDPDB/3 logic, which is what almost every site

really wants. Step level accounting really does not work:

you can't tell which step caused which PDB.PRINT data;

which account do you use in PDB.JOBS if different fields

are used on different steps, etc. However, IBM does not

provide a mechanism for putting job-level account fields

in type 30_1 or type3-_5 records for Started Tasks (STC).

This change creates additional variables SACCTn in both

TYPE30_V (interval) and TYPE30_4 (step) records, and the

SACCTn variables are now added to PDB.STEPS. Please NOTE

that PDB.JOBS is unchanged; ACCOUNTn variables for STCs

will still contain blanks. Further design considerations

of BUILDPDB logic is required before step account fields

could replace blank job accounting fields in PDB.JOBS.

1.Member VMAC30

SACCT1-SACCT9 was added to KEEP of TYPE30_4 and TYPE30_V

2.Member IMACACCT

SACCT1-SACCT9 were added. IMACACCT is usually modified as

described on page 311 of the MXG Guide; changes made to

the number and length of ACCOUNTn variables must also now

be made to the SACCTn variables.

3.Member IMACPDB:

SACCT1-SACCT3 added to the MACRO _PDB30_4 list of which

TYPE30_4 variables will be carried into PDB.STEPS. (MXG

defaults to 3 ACCOUNT and now 3 SACCT variables).

Thanks to Michel Leveille, CTTL, USA.
Change 07.045 MXG Programs can be executed through JCL with either an

JCLPDB explicit DD DSN=MXG.SOURCLIB(XXXXXXXX) member name in the

JCLTREND JCL, or by a //SYSIN DD * JCL statement followed by SAS

PDBTREND %INCLUDE SOURCLIB(XXXXXXXX); statements. MXG members that

Apr 9, 1989 contain JCL were inconsistent, some used member name and

some used %INCLUDE.

1. In favor of member name:

a. There was a historical limitation when JES could not

submit a job from a job if the submitted job contained a

SYSIN DD * JCL statement. The submitted job would simply

not execute. Making the DD * statements a member of a PDS

and then using only member name DD statements solved the

problem. (This still is occasionally encountered at some

sites and/or levels of JES - anyone know why/when/what?)

b. JCL is easier to comment out than SAS. JCL needs only a

asterisk in col 3 of the DD statement. SAS usually needs:

an INSERT character to make room for the leading /*,

typing of the /* delimiter before the statement,

a long shift cursor to the end of the statement,

typing of the */ delimiter after the statement,

(and only if you did not first have to cursor right, char

delete to make room in the line buffer!)

c. Production jobs which failed could be re-submitted in one

step by editing the JCL member, commenting out the member

names that had successfully completed and submitted to

run from that point.

2. In favor of %INCLUDE.

a. The MXG Exit Facility. You need the ability to change any

MXG program in your USERID.SOURCLIB, and the use of JCL

member name prevents you from making effective use of the

Exit Facility. Items b. and c. above were encountered at

State Farm and Sun, before there was an Exit Facility!

3. The conclusion. MXG will now use only %INCLUDE statements

in JCL examples. Furthermore, all %INCLUDE statements in

JCL examples will be precedeed by five blanks to make any

editing easier (as long as I don't forget to do so).

Thanks to Susan Marshall, SAS Institute Europe, GERMANY.
Change 07.044 IDMS Performance Monitor SMF record processing did not

VMACIDMS retain TASBFLDS and TASNDBLV in the IDMSTAS data set. Add

Apr 9, 1989 TASBFLDS to the RETAIN statement (line 130300) and change

the 2nd occurrence of TASMXRBB line 131000 to TASNDBLV.

Variable TASTTYPE in IDMSTAS identifies the type of task

(DC Task, CICS ERU, Batch ERU, or TPMON ERU) and several

variables only apply to specific task types. MXG did not

initialize these variables, and because these variables

must be retained (the IDMSTAS record is segmented into

256 byte pieces because of the 256 byte IDMS Journal),

the "other" variables will have retained values from a

prior IDMSTAS observation. As long as you use TASTTYPE

you should not have a problem, but the real fix inserted

25 lines after 123300 to initialize the retained values:

SKIP=SKIP-40; 123300

TASTSKCD =' '; 123310

TASPGMNM =' '; 123320

TASLTEID =' '; 123330

TASPTEID =' '; 123340

TASUSER =' '; 123350

TASPGDBN =' '; 123360

TASPGNOD =' '; 123370

TASLDLST =' '; 123380

TASAMNAM =' '; 123390

TASFACCD =' '; 123391

TASCTI =' '; 123392

TASCPGNM =' '; 123393

TASCTETI =' '; 123394

TASCLID1 =' '; 123395

TASCLID2 =' '; 123396

TASCTEOI =' '; 123397

TASCJBNM =' '; 123398

TASBJBNM =' '; 123399

TASBPGNM =' '; 123400

TASBNFLD =.; 123401

TASBBALN =.; 123402

TASBFLDS =' '; 123403

TASTPGNM =' '; 123404

TASTLID1 =' '; 123405

TASTLID2 =' '; 123406

IF TASTTYPE='1.......'B THEN DO; /*ONLINE - DC TASK */123410

Thanks to Randy Springs, Glidden Paint, USA.

Change 07.043 VM/370 Account records contain blanks (rather than hex

TYPEVM zeros) for the VECVMTM and VECVIRTM vector CPU fields.

Apr 9, 1989 (Four bytes of blanks input as PIB4.3 is 1,077,952.576!)

Lines inserted after 036900 to conditionally input:

036910 @;

036920 INPUT @65 TSTCHAR1 $CHAR4.

036930 @69 TSTCHAR2 $CHAR4.

036940 @;

036950 IF TSTCHAR1 NE ' ' AND TSTCHAR2 NE ' '

THEN INPUT

Thanks to J. D. Hill, CyCare Systems, USA.
Change 07.042 NPM Type 28 SMF record subtype 60x,61x, and 62x were not

VMAC28 output. Expand the test at line 200300 to include those

Apr 9, 1989 three values of NPMSUBTY (and change comment in 200400

for EX028IN8 to read for NPMINNSA vice NPMINPMT).

Thanks to J. D. Hill, CyCare Systems, USA.
Change 07.041 Variables QTXAFLG1, QTXAIRLM, and QWHCOPID were not kept

VMACDB2 in DB2ACCT keep list, but will be needed in DB2PM-like

Apr 9, 1989 reports for DB2 Version 2.1. They are now kept.
Change 07.040 Support for Tape Management System (TMS) Catalog records

ANALTMS5 (tape volume sizes, last use, etc.) is now upgraded from

TYPETMS "X-rated (i.e, extra but not supported member) XMACUCC1"

VMACTMS5 to these members. There may be additional logic added

Apr 8, 1989 after further testing. See comments in TYPETMS.

Thanks to Joseph J. Faska, Depository Trust, USA.

Change 07.039 The subtype 3 (Storage) type 22 SMF record (seldom if

VMAC22 ever needed) fails with MVS/370 and old MVS/XA because

Apr 7, 1989 NRPAGES may not exist and LOWADDR may be 2 or 4 bytes.

Change lines 046100 to 046300 to read:

046100 IF LENGTH-COL EQ 1 THEN INPUT LOWADDR PIB2. @;

046200 ELSE IF LENGTH-COL GE 3 THEN INPUT LOWADDR PIB4. @;

046300 ELSE IF LENGTH-COL GE 7 THEN INPUT LOWADDR PIB4.

NRPAGES PIB4. @;

Thanks to Dana Yam, Washington University, USA.
Change 07.038 These five members are one possible circumvention for a

XMAC7072 "SAS Error 344 - Compiler Limit Exceeded" condition in

XMAC71 executing BUILDPDB/3. By copying these five members to

XMAC73 your USERID.SOURCLIB library and renaming them to their

XMAC74 corresponding VMAC.... name, the number of interative

XMAC75 "DO" statements is reduced, and BUILDPDB might be able

Apr 5, 1989 to compile successfully. (The ultimate fix will be SAS

Version 6 on the mainframe, which eliminates the limit in

their compiler.) These members reduce the number of "DO"s

by processing only MVS/XA and MVS/ESA RMF records, but

depending on which additional SMF processing members you

have added to BUILDPDB/3, even with this circumvention in

place, you might still exceed the compiler limit.

An alternate circumvention which completely avoids any

exposure, and is only slightly more complicated, is to

use the IMACFILE exit to write the newly wanted SMF data

records to a temporary SMFOUT file, which is then passed

to an additional step in your BUILDPDB/3 job, which then

creates the additional data sets and copies them into the

PDB ddname. In this way you will still only read your SMF

dataset once, and by good choices of which records are in

this temporary data set versus which records you process

in BUILDPDB/3, you can keep the temporary data set small.
The XMAC7... members on Version 6.6 were unfortunately

not built correctly, and created different exposures. If

you need to use these five XMAC7... members to attempt to

avoid the compiler limit, you will need to recreate them

their corresponding VMAC.... member, replace the MVS/370

processing lines with the indicated "Initialization IF"

statements so they end up as shown below:
XMAC7072:

Replace lines 043900 thru 085000 to be:

043900 IF (ID=70 OR ID=72) AND NOT MVSXA THEN DO;

044000 IF SUPATERN=' ' THEN SUPATERN=' ';

085000 END; /* TYPE 70, 72 RECORD FOR NON-MVSXA */

XMAC71:

Replace lines 031500 thru 046100 to be:

031500 IF ID=71 AND NOT MVSXA THEN DO;

031600 IF FRAMES =. THEN FRAMES =.;

031700 IF LPSWRCLM=. THEN LPSWRCLM=.;

031800 IF PVTMVCLC=. THEN PVTMVCLC=.;

031900 IF PVTMVDWN=. THEN PVTMVDWN=.;

032000 IF PVTMVUP0=. THEN PVTMVUP0=.;

032100 IF PVTMVUP1=. THEN PVTMVUP1=.;

046100 END; /* MVS/370 TYPE 71 RECORD */

XMAC73:

Replace lines 012700 thru 002270 to be:

012700 IF ID=73 AND NOT MVSXA THEN DO;

012800 IF AVGENQUE=. THEN AVGENQUE=.;

012900 IF CHANMAP0=. THEN CHANMAP0=.;

013000 IF CHANMAP1=. THEN CHANMAP1=.;

013100 IF C0ANYCH =. THEN C0ANYCH =.;

013200 IF C0BYWT =. THEN C0BYWT =.;

013300 IF C1ANYCH =. THEN C1ANYCH =.;

013400 IF C1BYWT =. THEN C1BYWT =.;

013500 IF DEFCUBY =. THEN DEFCUBY =.;

013600 IF DEFDEVBY=. THEN DEFDEVBY=.;

013700 IF DEFERED =. THEN DEFERED =.;

013800 IF DEFLCHBY=. THEN DEFLCHBY=.;

013900 IF DEFPHYBY=. THEN DEFPHYBY=.;

014000 IF FQCUBY =. THEN FQCUBY =.;

014100 IF FQDEVBY =. THEN FQDEVBY =.;

014200 IF FQLCHRQ =. THEN FQLCHRQ =.;

014300 IF FQPHYRQ =. THEN FQPHYRQ =.;

014400 IF LCHAN =. THEN LCHAN =.;

014500 IF LCI =. THEN LCI =.;

014600 IF PCTDEFCU=. THEN PCTDEFCU=.;

014700 IF PCTDEFDV=. THEN PCTDEFDV=.;

014800 IF PCTDEFER=. THEN PCTDEFER=.;

014900 IF PCTDEFLC=. THEN PCTDEFLC=.;

015000 IF PCTDEFPY=. THEN PCTDEFPY=.;

015100 IF QUEUE0 =. THEN QUEUE0 =.;

015200 IF QUEUE1 =. THEN QUEUE1 =.;

015300 IF QUEUE2 =. THEN QUEUE2 =.;

015400 IF QUEUE3 =. THEN QUEUE3 =.;

015500 IF QUEUE4 =. THEN QUEUE4 =.;

015600 IF SIO73CNT=. THEN SIO73CNT=.;

015700 IF AVGPHYNQ=. THEN AVGPHYNQ=.;

015800 IF CPUID =. THEN CPUID =.;

015900 IF PCHANWT =. THEN PCHANWT =.;

016000 IF IDWRONG=' ' THEN IDWRONG=' ';

022700 END; /* MVS/370 TYPE 73 RECORD */

XMAC74:

Replace lines 012800 thru 002380 to be:

012800 IF ID=74 AND NOT MVSXA THEN DO;

012900 IF CUBUSY =. THEN CUBUSY =.;

013000 IF DEFERCUB=. THEN DEFERCUB=.;

013100 IF DEFERED =. THEN DEFERED =.;

013200 IF DEFERSVD=. THEN DEFERSVD=.;

013300 IF DEVBUSY =. THEN DEVBUSY =.;

013400 IF LCHAN =. THEN LCHAN =.;

013500 IF PCTDEFCU=. THEN PCTDEFCU=.;

013600 IF PCTDEFER=. THEN PCTDEFER=.;

013700 IF PCTDEFRS=. THEN PCTDEFRS=.;

013800 IF PCTQUEDV=. THEN PCTQUEDV=.;

013900 IF PCTQUEPA=. THEN PCTQUEPA=.;

014000 IF QUEUE0= . THEN QUEUE0 =.;

014100 IF QUEUE1= . THEN QUEUE1 =.;

014200 IF QUEUE2= . THEN QUEUE2 =.;

014300 IF QUEUE3= . THEN QUEUE3 =.;

014400 IF QUEUE4= . THEN QUEUE4 =.;

014500 IF UNITADR= . THEN UNITADR =.;

023800 END; /* MVS/370 TYPE 74 RECORD */

XMAC75:

Replace lines 006500 thru 012000 to be:

006500 IF ID=75 AND NOT MVSXA THEN DO;

012000 END; /* MVS/370 TYPE 75 RECORD */

Thanks to Larry Cecil, First National Bank of Chicago, USA.

Change 07.037 Version 6.6 added variable PRENTIME to PDB.PRINT and its

BUILDPDB BY-list, but the change was incomplete and needed to be

BUILDPD3 fixed (see Change 7.006) and documented (Change 7.036).

Apr 3, 1989 Another exposure to incorrect sort order was seen and is

fixed by this change. The exposure only exists on the

very first run of the new BUILDPDB when PRENTIME does not

yet exist in SPIN library, and only if the same job had

multiple print files with exactly the same PRINTIME on

different devices with one record in SPIN and one record

in today's SMF, AND only if the device names are not in

ascending alphabetical sequence! No one has reported the

exposure, but once noted, it was fixed by this change.

References to JPURTIME in this change fix another first

time exposure induced by Change 7.008, and make JES3

purge records sort order consistent with JES2.

Changes made to both BUILDPDB and BUILDPD3:

BUILDPDB BUILDPD3

018800 019200 LENGTH DEFAULT=4 READTIME PRINTIME PRENTIME 8;

019310 019710 IF PRENTIME=. THEN PRENTIME=.;

019320 019720 IF OUTDEVCE=' ' THEN OUTDEVCE=' ';

019330 019720 IF SYSPRN =' ' THEN SYSPRN =' ';

019410 019810 SYSTEM=SYSPRN;

020110 020510 IF JPURTIME=. THEN JPURTIME=.;

n/a 023900 BY READTIME JOB JESNR JPURTIME;

022900 023300 BY READTIME JOB JESNR PRINTIME PRENTIME OUTDEVCE

SYSTEM;

Thanks to Raymond Zieverink, Belk Stores Services, USA.
Change 07.036 Implementation Considerations for WEEKBLD/MONTHBLD.

WEEKBLD Changes to MXG Software can usually be implemented at any

MONTHBLD time. A powerful feature of the SAS system is its ability

Apr 3, 1989 to add variables to existing datasets and to create new

datasets automatically. To further ease implementation,

MXG logic uses SAS options "NOVNFERR" and "NODSNFERR" to

avoid "variable not found" and "dataset not found" errors

whenever approriate. Unfortunately, the NOVNFERR option

does not work if the variable is in a BY-list. Thus when

Version 6.6 added variable PRENTIME to PDB.PRINT dataset,

we failed to document all that you might have to do to

avoid a "variable not found" or "data set is not sorted"

error in WEEKBLD or MONTHBLD. This is that documentation:
If you implement the new BUILDPDB/3 code on Monday after

you have built your weekly PDB, you will avoid any change

to WEEKBLD, since all of the new daily PDBs will contain

PRENTIME and will be correctly sorted.

If you must implement the new BUILDPDB/3 in the middle of

a week, you must modify WEEKBLD by inserting new line:

003110 PROC SORT;

(between the SET MON.PRINT ... SUN.PRINT; statement and

the BY ... statement). This will create the WEEK.PRINT

by concatenating all seven dailies in unsorted order, but

now WEEK.PRINT will contain PRENTIME (since at least one

of the seven dailies was built with MXG 6.6 code). Then,

WEEK.PRINT is sorted by the original BY list. The only

cost of this modification is the double processing of the

WEEK.PRINT dataset.
You MUST modify MONTHBLD since at least one prior weekly

PDB will have been built before the 6.6 BUILDPDB. You

must remove "PRENTIME OUTDEVCE SYSTEM" from the end of

the MACRO _BYLIST definition for the MONTH.PRINT dataset

in line 016001. As soon as all input datasets used by

WEEKBLD/MONTHBLD have been built with the new version of

MXG, you can remove the modified members from your USERID

SOURCLIB or MXG.CHANGLIB libraries and use the unmodified

MXG code.
Page 263 of the MXG Supplement documented the sort order

of the PDB.PRINT data set, and should now read:

BY READTIME JOB JESNR PRINTIME PRENTIME OUTDEVCE SYSTEM.

Thanks to Bill Salassi, BHP Petroleum, AUSTRALIA.

========Changes thru 7.035 were printed in NEWSLETTER FOURTEEN==========
Change 07.035 If you used the new member IMAC30IO to remove variable

IMAC30IO D3330DRV from the _IO30DR macro defined therein, and you

IMACPDB did NOT also change member IMACPDB to adjust the dummy

Mar 15, 1989 X1-X9 variables, your PDB.JOBS data set contains wrong

values for ALL numeric values in the _SUMSTP macro that

is defined in IMACPDB. The documentation in IMAC30IO was

grossly inadequate, because it did not tell you to read

the instructions in lines 020000-023900 in IMACPDB. This

error affects ONLY the PDB.JOBS data set. Any TYPE30 data

sets and the PDB.STEPS were built correctly, even if you

removed D3330DRV. Also, removing other variables from the

other two macros (_IO30EX and _IO30TM) in IMAC30IO would

not cause any error.

FIX: The simple fix is to simply leave variable D3330DRV in

the MACRO _IO30DR definition in IMAC30IO.
If you really are concerned about the extra four bytes

and do want to delete D3330DRV from your PDB.JOBS and

PDB.STEPS data, you can remove D3330DRV from the MACRO

_IO30DR definition in IMAC30IO, but you must then change

IMACPDB:

a) Line 024400, change DROP=X1-X9 to DROP=X1-X8

b) Line 024700, remove X9 from the SUM= list

Thanks to Trevor Holland, AUSTRALIA.

Thanks to Richard Evans, Mervyn's, USA.

Comments expanded April 9, 1989:

And even if you do delete D3330DRV as described above,

you will still find an UNINITIALIZED value note because

BUILDPDB/3 still have D3330DRV in two length statements

where it should have been changed to _MAXSTP:

BUILDPDB BUILDPD3

051600 051900 change D3330DRV to _MAXSTP

055300 056100 " " "

Thanks to Lucy Fukishima, California Health & Welfare Agency, USA.

Change 07.034 The FMXGUCBL function to dynamically allocate all DASD

FMXGUCBL devices may attempt to allocate a printer device. This is

FMXGUCBL a soft error condition. It turns out that the FMXGUCB7

Mar 15, 1989 function (provided because FMXGUCBL was thought to be an

MVS/XA-only function) actually uses an MVS/XA facility

that was retro-fitted into MVS/370. FMXGUCB7 not only is

usable under MVS/XA, it does not try to allocate printer

devices! This change replaces FMXGUCBL member with the

contents of FMXGUCB7, changes FMXGUCB7 therein to read

FMXGUCBL, and deleted member FMXGUCB7.

Thanks to Susan Marshall, SAS Institute Europe, GERMANY.

Thanks to Dan Squillace, SAS Institute Cary, USA.

Change 07.033 The VTOC processing example in member TYPEVTOC should use

TYPEVTOC %VMXGVTOC instead of the erroneous %_MXGVTOC, and comment

TYPEVTOC refering to member VMACVTOC should have been VMXGVTOC.

Mar 15, 1989 Member VMACVTOC was replaced by VMXGVTOC and now VMACVTOC

has been deleted to avoid the confusion.

Thanks to Chun-Heng Liu, Brooklyn Union Gas, USA.

Change 07.032 MVS/ESA-only variables for SQA, LPA, CSA, LSQA, and REGS

VMAC71 frames in CS (Central Storage, formerly Real Storage) and

Mar 15, 1989 in ES (Expanded Storage, formerly Extended Storage) are

missing. The test in these lines should have been:

083000 IF VERSNRMF GE 410 AND LENPGDS GE 504 THEN DO;

085600 IF VERSNRMF GE 410 AND LENPGDS GE 536 THEN DO;

Thanks to Don Friesen, B.C. Systems, CANADA.
Change 07.031 RMF Monitor III variables in Subtype 2 SMF Type 72 record

VMAC7072 (MVS 3.1.0e only) WSETACT WSETIDL WSETDIV WSETFIX WSETASM

Mar 15, 1989 need zero divide protection in lines 165794 thru 165810:

IF denominator GT 0 THEN WSETACT = numerator/denominat

ELSE WSETACT=.;

Thanks to Don Friesen, B.C. Systems, CANADA.

Change 07.030 In member ASUMCICS the label in line 009100 for variable

ASUMCICS RESPBKT6 should be 8 SEC instead of 6 SEC. Additionally,

VMXGSUM in member VMXGSUM the example in comments for "min, max,

Mar 15, 1989 and sum" actually calculated mean, max and sum (and also

misspelled statistics).

Thanks to Susan Marshall, SAS Institute Europe, GERMANY.

Change 07.029 An unexpected limitation of CMS SAS (although it is noted

new macros in a documentation footnote): new style %MACRO names are

Mar 9, 1989 limited to seven position names! Current MXG %MACROs that

are now eight-characters long: ANALDB2R ANALDMON ANALNSPY

GRAFRMFI GRAFTRND IBM3287F PCONLINE VMXGGOPT and ZETAFOIL

Thanks to J. D. Hill, CyCare Systems, USA.

Change 07.028 Value tested for RECFM=VM should have been (line 003200):

VMACRCFM 003200 ELSE IF RECFMT='0100001.'B THEN RECFM='VM ';

Mar 9, 1989

Thanks to Mr. Rathfelder, Taylorix, GERMANY.

Change 07.027 Beginning and ending times of DB2 reports were taken from

ANALDB2R SMF timestamp and not the actual interval, causing loss

Mar 9, 1989 of first interval.

Line 089300 Change VAR SMFTIME; to VAR QWHSSTCK DURATM;