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

Part of the solution was to re-design the %VMXGSUM macro

so that it protects for possible missing variables in the

MIN, MAX, SUM, etc. operations done by %VMXGSUM, because

that should have been the original implementation. That

enhancement to %VMXGSUM is implemented herein in the 1st

part of this change.

Additionally, however, MXG 7.7 reports expected several

character variables that did not exist in MXG 6.6-built

PDBs. The second part of this change added statements to

supress the UNINITIALIZED VARIABLE messages if a cross-

version report (7.7 report from 6.6 data) is requested!
1.These sixteen new lines are inserted in member VMXGSUM:

After 025910 (IF DATETIME=. THEN DATETIME=.;) and before

026000 (&INCODE) insert:
%DO I = 1 %TO &NUMMAX %BY 1; 02592000

%LET VAR = %SCAN(&MAX,&I); 02593000

IF &VAR = . THEN &VAR = .; 02594000

%END; 02595000

%DO I = 1 %TO &NUMMIN %BY 1; 02596000

%LET VAR = %SCAN(&MIN,&I); 02597000

IF &VAR = . THEN &VAR = .; 02598000

%END; 02599000

%DO I = 1 %TO &NUMMEAN%BY 1; 02599100

%LET VAR = %SCAN(&MEAN,&I); 02599200

IF &VAR = . THEN &VAR = .; 02599300

%END; 02599400

%DO I = 1 %TO &NUMSUM %BY 1; 02599500

%LET VAR = %SCAN(&SUM,&I); 02599600

IF &VAR = . THEN &VAR = .; 02599700

%END; 02599800

2.If you MUST create new ANALDB2R MXG 7.7 reports from old

MXG 6.6-built PDB libraries, you must make these changes.

a.In two places in ANALDB2R, after lines 084860 and 110130

(each is: IF QWHSLOCN = ' ' THEN QWHSLOCN = ' ';),

replicate each line twice, then change the QWHSLOCN to

QLSTLOCN in the first replicate, then change the QWHSLOCN

to QLACLOCN in the second replicate.

b.Replicate line 006330 and change QWHSLOCN to QLACLOCN.

c.Change lines 015610 and 015620 (which initialize variable

QWHSDBAT and QWHSLOCN to four blanks) to now read:

IF QWHSDBAT=' ' THEN QWHSDBAT=' ';

IF QWHSLOCN=' ' THEN QWHSLOCN=' ':

d.Now, replicate this changed line 015620 thirteen times,

and change the replicated lines to now read:

IF QWHSLOCN=' ' THEN QWHSLOCN=' '; 015620

IF QLACLOCN=' ' THEN QLACLOCN=' '; 015621

IF QTXASELM=' ' THEN QTXASELM=' '; 015622

IF QTXASALM=' ' THEN QTXASALM=' '; 015623

IF QTXASPLM=' ' THEN QTXASPLM=' '; 015624

IF QTXABLLM=' ' THEN QTXABLLM=' '; 015625

IF QTXAINLM=' ' THEN QTXAINLM=' '; 015626

IF QTXAIOLM=' ' THEN QTXAIOLM=' '; 015627

IF QLACTRNS=. THEN QLACTRNS=.; 015628

IF QLACCNVQ=. THEN QLACCNVQ=.; 015629

IF QLACMSGS=. THEN QLACMSGS=.; 015630

IF QLACMSGR=. THEN QLACMSGR=.; 015631

IF QLACBYTS=. THEN QLACBYTS=.; 015632

IF QLACBYTR=. THEN QLACBYTR=.; 015633

Thanks to Dale St. Amant, Tenneco, USA.
Change 08.020 As discussed in Change 7.139 in MXG 7.7 CHANGES, SYNCSORT

VMACSYNC creates an invalid CPUTCBTM value (hex'555555'=15:32HHMM)

Mar 23, 1990 but it was not known why. SYNCSORT Early Warning Nr. 2803

now identifies the culprit; the use of FREE=CLOSE on the

SORTIN DDNAME causes SYNCSORT and MVS to both have issued

active STIMERS, which causes the corruption in their CPU

TCB time measurement. Eventually, SYNCSORT will fix the

conflict by zeroing out the field when a second STIMER is

set. MXG now recognizes '00555555'X and sets CPUTCBTM to

be missing in VMACSYNC. When the SYNCSORT fix is applied

in the future, a zero value instead of missing value will

result. This is a price you pay for FREE=CLOSE. Note that

even DFSORT specifically states to not specify FREE=CLOSE

on SORTIN DD statement

Note that this STIMER conflict ONLY affects the CPU time

that is measured by the 2nd STIMER issuer. The true CPU

TCB time in the SMF type 30 and the RMF type 72 records

are NOT affected, and remains correct.

Note also that FREE=CLOSE similarly affects SAS reported

CPU times on the SAS log, and can actually cause SAS to

ABEND with an internal apparent CPU TIME EXCEEDED error,

that also does not affect type 30/72 data, as was first

discussed on page 6 of MXG Newsletter TEN. With SAS, you

can still use FREE=CLOSE by specifying the NOSTIMER

option, which supresses CPU capture by not even issuing

the STIMER macro. (While SYNCSORT also has a NOSTIMER

option, it does not work in the same way, and will not

zero the CPU field when FREE=CLOSE is used.)

Thanks to Sam Sheinfeld, Kraft General Foods, USA.

Thanks to Nanette, SYNCSORT, USA.

Change 08.019 As documented in Newsletter SIXTEEN, MXG support for

VMACEPIL Candle's EPILOG/CICS was incomplete. It was also wrong!

XMACEPIL 1.The correct member to include (in member TYPEEPIL) is

XXACEPIL XMACEPIL in place of VMACEPIL, and DO NOT use XXACEPIL).

Mar 23, 1990 2.In member XMACEPIL, a + sign is missing in line 039300,

which should read: @121+OFFEPIL BISTIME ....

3.Variable WID should be 8 bytes (it is UOWID), but the

DEFAULT=4 causes it to be kept as only 4 bytes. It needs

to be added with explicit length 8, but eventually will

be converted and decoded into UOWID and UOWTIME.

Thanks to ???, ???.
Updated Jan 14, 1991. Member XMACEPIL was corrected and

copied into (replacing) member VMACEPIL, and then the

member XMACEPIL was deleted. All future EPILOG CL1000

support will be in member VMACEPIL, as it should have

been all along. See Change 8.212.
Change 08.018 System Managed Storage (SMS) now uses formerly reserved

VMXGVTOC bits located at offset '4E'x in the DSCB1 in your VTOCs.

Mar 22, 1990 DASD products like DMS/OS and ASM2 have used these bits,

and local modifications (to CSECTS IFG0196W and IFG0194E)

have also caused this "DSCB Contamination".IBM published

"Clean up VTOCs Before Implementing DFP V3"(as WSC Flash

9009, Hone Entry G022345) to advise you of the exposure.

If DSCB contamination is found, you must not only clean

the VTOCs of your online data sets, but you will need to

also clean all migrated datasets, since their DSCBs were

also migrated and your migration software will need to

correct the contamination when datasets are recalled.

The change in 8.2 creates these new SMS variables in the

VTOCLIST (for VMXGVTOR) or LIST (for VMXGVTOC) dataset:

DS1CRSDB='DADSM CREATE ORIGINATED BLOCKSIZE?'

DS1PDSE ='PDSE MANAGED DATASET?'

DS1REBLK='DATA SET MAY BE REBLOCKED?'

DS1SCAVB='SECONDARY IS ORIG AVG BLOCK LENGTH?'

DS1SCCP1='SECONDARY IS COMPACTED BY FACTOR OF 256?'

DS1SCCP2='SECONDARY IS COMPACTED BY FACTOR OF 65536?'

DS1SCKB ='SECONDARY IS IN KILOBYTES?'

DS1SCMB ='SECONDARY IS IN MEGABYTES?'

DS1SCUB ='SECONDARY IS IN BYTES?'

DS1SCXTV='SECONDARY SPACE EXTENSION VALUE'

DS1SMSDS='SYSTEM*MANAGED*DATASET?'

DS1SMSUC='NO BCS ENTRY EXIST FOR DATA SET?'

OFFSET4E='OFFSET 4E*INTO DSCB1*(USED BY SMS)'
2.The PROC SORT DATA = EXTENT; BY VOLSER POINTER; was

inside the %DO group was relocated outside, just before

the %DO, since no values in EXTENT were changed; this

will speed up execution slightly.

3.Adding variable OFFSET4E to VMXGVTOC is simple: replace

line 045100 (now containing only +4 ), with this:

@84 OFFSET4E $CHAR4.

and add OFFSET4E to the KEEP list for the LIST dataset.

Then, you can execute the following MXG program under TSO

to read the VTOC of your favorite VOLSER to see if it

suffers from DSCB contamination at offset '4E'x:
ALLOC F(DISK) DA('any data set on chosen volume') SHR

SAS OPTIONS('NODMS MAUTOSOURCE SASAUTOS=SOURCLIB VTOC')

%VMXGVTOC(DISK=DISK); RUN;

DATA CONTAMIN; SET LIST;

IF OFFSET4E NE '00000000'X THEN OUTPUT;
(Dataset LIST is built directly by VMXGVTOC. If you

have implemented VMXGVTOR to graze your entire DASD

farm, the SET LIST; statement would be replaced with

SET &LIB..MXGVTOC which contains all LIST datasets.)

If dataset CONTAMIN has non-zero observation count, then

you either have DSCB contamination, or SMF has already

been installed at your site!

Thanks to Tuanhung Doanvo, Philip Morris, USA.

Thanks to Jim Gilbert, Texas Utilities, USA.
Change 08.017 Hiperbatch hit/miss stats were added by IBM to type 14/15

VMAC1415 and type 64 by TNL (GN28-1284) dated Jan 3, 1990 that was

Mar 22, 1990 delivered today. (Had it been received even by Feb 20, it

would have been implemented in MXG 7.7, avoiding this

change!). The change adds five new fields to both the

TYPE1415 and TYPE64 data sets. While the fields are the

same, IBM used two different field names/acronyms:
TYPE1415 TYPE64 Description

name name

SMFIOREQ SMF64SIO Hiperbatch total searches/requests

SMFCHITS SMF64HIT Successful searches

SMFPHIOS SMF64MIS Misses; caused physical DASD I/O

SMFCIOS SMF64IOS Misses that were copied into buffers

SMFNMWTS SMF64WTS Suspends due to conflict other users
Change 08.016 TPX dataset TPXINTRV will have zero observations because

VMACTPX of mis-alignment in the subtype 2 or 4 records. After

Mar 22, 1990 line 040900 insert:

IF TPXVER GE 200 THEN INPUT TPX24LEN PIB2.

TPX24ID $CHAR2.

@;

Note: TPX24ID was printed in error as $CHAR4. in Newsletter

SEVENTEEN, but was correct in MXG PreRelease 8.2 and

later software. It should be $CHAR2. as shown above.

Thanks to Kari Strand, Televerkets EDB-tjeneste, NORWAY.

Thanks to Doug Mayward, Pharmaceutical Data Services, Inc, USA.

Change 08.015 New subtype 3 of the existing SMF type 41 record provides

EXTY41AC usage statistics of the Virtual Lookaside Facility (VLF).

EXTY41UN Interval records (15 min) are written for each class in

EXTY41VF your COFVLFnn member of PARMLIB that is currently in use.

VMAC41 MXG creates dataset TYPE41VF from this subtype, reporting

Mar 22, 1990 (for each VLF class used) the MAXVIRT size, the storage

used, counts when objects were found in, added to,

deleted from or trimmed from VLF during the interval,

the largest object attempted to be added to VLF since VLF

was started, and the VLF "pct found/hit ratio". Multiple

VLF classes (CSVLLA, IGGCAS, IKJEXEC) can exist in one

type 41 subtype 3 record; multiple observations with the

same SMFTIME will be created by MXG. This change deletes

the existing TYPE41 dataset built from subtypes 1 and 2

and in its place creates two: TYPE41AC (DIV Accesses)

and TYPE41UN (DIV Unaccesses), which now keep only the

variables specific to those DIV events.

Thanks to Dan Barbatti, Southwestern Bell, USA.

Thanks to Jim Gilbert, Texas Utilities, USA.
Change 08.014 These circumvention members (for SAS 344 compiler limit)

XMAC7072 did not keep ZDATE in all datasets and had a typographic

XMAC71 error.

Mar 22, 1990 1.In XMAC7072, add ZDATE to the KEEP list for TYPE70PR and

TYPE72MN datasets.

2.In XMAC71, remove the extraneous period before the final

semicolon in line 031800.

Thanks to Bruce Widlund, Texas Utilities, USA.

Change 08.013 DB2 data read from GTF did not have DATETIME21.2 format

VMACSMF nor LENGTH=8 for SMFTIME variable, but now _GTFDB2 macro

Mar 22, 1990 contains SMFTIME in both FORMAT and LENGTH statements.

Thanks to Susan Marshall, SAS Institute Europe, GERMANY.

Change 08.012 As noted in comments, type 79 support had not been tested

VMAC79 with real records. Now it has, and these changes will be

Mar 21, 1990 required to avoid STOPOVER or invalid data conditions.

1.These seven actions are SPF commands to be entered on the

command line while SPF EDITing member VMAC79 to make the

global changes (note that blanks ARE important):

a.EXCLUDE ALL

b.FIND ' = ' ALL (16 occurrences found)

c.CHANGE ' = ' '=' ALL

d.CHANGE ' BY ' '-1 BY ' ALL NX

e.EXCLUDE ALL

f.FIND ' LE LENGTH' ALL (21 occurrences found)

g.CHANGE ' LE LENGTH' '-1 LE LENGTH' ALL

2.Change line 013800 to read CYCLE ?? PD4.

3.Insert new line 015910 (after 105900) R79LF2 $CHAR1.

4.Change line 016200 to read R79RSV $CHAR2.

5.Change line 016900 to read R79IST ?? PDTIME4.

6.Change three occurrences in two lines of R792SLQR to read

R792LSQR.

7.These first six items bring the code up for MVS/ESA, but

for MVS/XA, other STOPOVER conditions are guaranteed, as

the code was only written for ESA. Guess what, though.

A real slick trick for MVS/XA execution (pointed out to

me by a user who got the trick from LEGENT's MICS) is to

execute with this code:

MACRO STOPOVER MISSOVER %

%INCLUDE SOURCLIB(TYPE79);

which will simply set the non-MVS/XA variables missing!

(I seldom use MISSOVER, because it does not tell you

that there were short records; I need STOPOVER so that

I GET the dump of the record, but is perfect here.)

Eventually, I may retrograde the code to support the XA

records, by breaking up the INPUT statement and inputting

conditionally the MVS/ESA variables, and thereby support

both MVS/XA and MVS/ESA type 79 data records, if that is

really necesary!

Thanks to Ron Thein, Mortgage Guaranty Insurance Corp., USA.

Thanks to Dan Barbatti, Southwestern Bell, USA.

Thanks to Randy Catlin, CENTEL.
Change 08.011 New member ZZZZZZZZ now exists as the last member of the

ZZZZZZZZ MXG library (AAAAAAAA is the first) so that it will be

Mar 15, 1990 easy to verify that all of the MXG Source Library ("from

AAAAAAAA to ZZZZZZZZ") has been successfully unloaded.

(Twenty new customers received incomplete MXG 7.7 tapes

from SAS before a customer discovered that only 1057 of

the 1100 members had been copied from our master tape!)

Thanks to Don Ehrig, Pearl Vision, USA.

Change 08.010 Support for NETSPY 3.2 was incomplete. NSPYVIRT (Virtual

VMACNSPY Route) variables APACING HOSTSUB OSTAGEP VRBLOCKD VRHELD

Mar 15, 1990 VRBHELDT VRBNSESS VROPEN VRBOPACT VRBPRTME were not input

and APPLID was replaced by SUBHOST. NSPYLINE variables

NSPDLY NSPDIALU NSPNMAXD NAPNMAXO NSPNANC NSPNCA NSPNNELS

NSPNPACE NSPNPLIM NSPNRTO NSPNSLIM were not input. These

un-input variables did not cause MXG to fail, they just

were not read in. Three other variables were actually

wrong and must be changes.

1.Line 052500 should read: BUF_UTIL=100 - FBLPCT;

so that minimum free buffers are used to calculate buffer

utilization (instead of average free buffers).

2.Line 059400 should read: COTPUTSZ PIB8.

(as PIB4., COTPUTSZ, Output Length, was always zero).

3.Move NETWADDR in line 009400 (in data set NSPYLU keep) to

line 008000 (in data set NSPYLINE keep list).

Thanks to Marty Quinlan, Virginia Power, USA."

for extensive validation.

Change 08.009 The %VMXGVTOR macro which invokes the FMXGUCBL function

FMXGUCBL was not correct. Changes made in VMXGVTOC (which is the

VMXGVTOR piece that actually reads the VTOC) were not propagated.

Mar 15, 1990 1.In member VMXGVTOR:

Jun 13, 1990 a. In lines 002200 and 002300 replace &I with &IVTOR.

b. Replace two lines 002500 and 002600 with these three:

PROC APPEND BASE=&LIB..VTOCLIST NEW=LIST FORCE;

PROC APPEND BASE=&LIB..VTOCMAP NEW=MAP FORCE;

PROC APPEND BASE=&LIB..VTOCINFO NEW=INFO FORCE;

2.The FMXGUCBL function was modified in MXG 7.7 (see page

17 of MXG Newsletter SIXTEEN), so the function would work

compatibly under either SAS 5.18 or SAS 6.06+, but it was

only tested under SAS 6.06! Under SAS 5.18, the MXG 7.7

FMXGUCBL returns a value too large by one. The following

change DOES work under either version of SAS and does let

a single assembly of this function to work witheither

SAS 5.18 or 6.06+. Change member FMXGUCBL lines 017400

thru 017500 so they now read:

MVC WORKAREA(4),=XL4'4E000000' 01740000 no change

LD FR0,WORKAREA 01741000 was SD FR0,FR0

XC WORKAREA+4(4),WORKAREA+4 01742000 new line

AD FR0,WORKAREA 01750000 no change

Thanks to Jeff Fox, SKF Inc, USA.

Thanks to David Fahey, SAS Institute Cary, USA.

Change 08.008 This is a complete revision of the text of this change

IMACVMON that was published in MXG Newsletter SEVENTEEN.

VMACVMON 1.The Q1SEC equation was wrong. The actual calculation

Jul 19, 1990 is Q1SEC=SUM(Q1TIME,E1TIME)/SUM(Q1DROPS,Q1); .

The lines affected by this change are:

a. After 035700, insert Q1SEC (to the KEEP= list)

b. After 082100, insert Q1SEC='AVERAGE*Q1SEC*DURATION'

c. After 146800, insert two lines:

DENOM=SUM(Q1DROPS,Q1);

IF DENOM GT 0 THEN Q1SEC=SUM(Q1TIME,E1TIME)/DENOM;

ELSE Q1SEC=.;

d. After 170000, insert Q1SEC (to the RETAIN list).

2.Comments in IMACVMON were added to stress the importance

of setting _INTRV macro value to equal your VM/Monitor

interval. If you leave the MXG default _INTRV value of

1 minute, but actually write records at 15 minutes, MXG

will throw away all USER and DASTAP data.

3.Variables PCTQUEDV/PCTQUECU were wrong, and instead of

containing the percentage of monitor intervals during

which there was a queue (as VM MAP calculates), these

MXG variables actually contained 100 times the average

number of entries in the queue. Now, they are correct and

should agree with VM MAP. The label for PCTQUEDV was

corrected and a label provided now for PCTQUECU.

4.The VM/370 SEEK (Class 7) reports in ANALVMDY do not work

and have not been fixed in MXG 8.7. It was re-packaged

incorrectly and causes syntax errors. Also, the logic to

match Seek address with the Mini-Disk directory may cause

ambiguous results, because it turns out that directory

entries can overlap. Pended for test data and test site.

Thanks to Bob Small, Grumman Data Systems, USA.

Thanks to George Ellard, Federal Express, USA.

Change 08.007 TSO/MON data set TSOMDSNS did not contain SYSTEM, and

TYPETSOM TSOMCMND had missing STRTTIME if there were enough users

Mar 19, 1990 logged on to create multiple System records for one

interval. (The TSOMSYST data set was protected by retain,

but the restore logic was after TSOMCMND was output.)

1.Add SYSTEM to keep list at line 005200.

2.Move three lines 084200 thru 084400 (which restore

STRTTIME,ENDTIME,and MAXUSERS from TSOMSTAR,TSOMENDT,and

TSOMAXUS) to immediately after line 072700 (before the

COMNDTYP='00'X; statement.

Thanks to Pete Shepard, Ashland Oil, USA.
Change 08.006 TYPEIMS IMS Log processing had missing values if IMS

TYPEIMS crashed repeatedly, due to duplicate DTOKEN values.

Mar 19, 1990 1.Move IMSTAPNO in lines 035400 and 035800 to make the line

read: BY IMSTAPNO DTOKEN PSTNUMBR TRANSACT IMSRECNO;

2.Insert IMSTAPNO in line 036900 to make the line read

BY IMSTAPNO DTOKEN;

3.Move IMSTAPNO in lines 094900 and 095300 to make the line

read: BY IMSTAPNO DTOKEN ARRVTIME GUTIME IMSRECNO;

4.Insert IMSTAPNO in line 108300 to make the line read

BY IMSTAPNO DTOKEN;

Thanks to Pete Shepard, Ashland Oil, USA.
Change 08.005 IDMS Performance Monitor SMF record variables PGMTYPE,

VMACIDMS TASPTYPE, and TASTTYPE were kept as 8-byte variables and

Mar 15, 1990 with $HEX2. format. They should have been 1-byte length

with the $MGIDMPP, $MGIDMTT, and $MGRTEPT formats. Also,

the IDMSDBK data set was never output.

1.Delete the semicolon at the end of the LENGTH statement

in line 072000, and insert this new line
PGMTYPE $1. TASPTYPE $1. TASTTYPE $1.;
to force their length to only one byte, and then also

2.Remove these same three variable names from line 072400

(where the $HEX2. format overrode line 072000).

3.Change line 154800 from EXIDMCDM to EXIDMDBK.

Thanks to Mike Eisenhart, York International, USA.

Thanks to Mark Robbins, Jaguar Cars, ENGLAND.

Change 08.004 Candle's OMEGAMON/VM for VM/XA has an option to reformat

VMACVMXA IBM's MONWRITE data records into a Variable Blocked (VB)

Mar 15, 1990 file. Unfortunately, their program did not create valid

VB format records. They incorrectly added an extra RDW

(Record Descriptor Word of 4 bytes) in front of the real

RDW (does this make the record a VVB format!).

Because VB records are easier to work with during testing

and because it was hoped that IBM would eventually change

MONWRITE to create legitimate VB data files, MXG's VM/XA

support defined the _OUTFILE macro, that does create true

VB data records from IBM's MONWRITE records, and MXG's

_VMINPUT macro was defined to process those (future!) VB

records. With only a minor change, MXG's _VMINPUT macro

can be modified by Candle sites to process those invalid

"VVB" format data. Candle has acknowledged their error,

and announced that a permanent solution (i.e., correct

VB record format) would be provided in their next release

of VCOLLECT in their Version 4.10, in second quarter 90.

Before 4.10, Candle sites can read the "VVB" data by the

followin new line inserted after 769000 (ends a PUT that

precedes the INPUT MRHDRDM ... ), skipping over the RDW:

INPUT +4 @;

BUT THIS CHANGE IS ONLY FOR CANDLE "VVB" PRIOR TO 4.10.

IT MUST BE BACKED OUT WHEN YOU INSTALL THEIR 4.10.

Candle's VCOLLECT Incident Number is 81696.

2.To read real VB data (either from Candle 4.10 or using

MXG's _OUTFILE), if you have installed the IBM PTFs that

are described in Change 7.219, you will need to add this

correction (unrelated to the Candle problem, but observed

while debugging the Candle-created problem):

The following line must be inserted after line 769600:

LENGTH=LENGTH+4;

(immediately before the MRHDRLEN=LENGTH; statement), to

set LENGTH to the physical instead of logical record

length, as expected by MXG's MONWRITE logic.

Thanks to Mark Flugrath, WVNET, USA.

Change 08.003 DASDMON data sets did not have SMFTIME and ZDATE in their

VMACDMON KEEP= list, causing uninitialized variable error in the

Feb 26, 1990 ANALDMON report program. Now they do.

Thanks to Danny High, Blue Cross Blue Shield Texas, USA.

Change 08.002 ACF2 ARE data segment had two bytes not read, causing a

VMACACF2 STOPOVER condition. If the ARE did not exist, a program

Feb 23, 1990 loop could occur.

Mar 22, 1990 1.Insert two new lines, after line 052000 and 054200 (both

of which are ACLFLDNM $CHAR8.). The new lines contain

+2

(thereby skipping over two bytes after ACLFLDNM).

2.Change line 051500 to now read:

IF ACLAFARE GT 0 AND ACLMFLGS NE '...1....'B THEN DO;

3.Change line 053700 to now read:

IF ACLBFARE GT 0 AND ACLMFLGS NE '..1.....'B THEN DO;

Thanks to Roman Gudz, Leaseway Transportation, USA.