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

clocks are invalid when this happens, and that APAR

adds a new bit to the TRANFLAG field to identify these

tasks. Since the clock values are all wrong, these

transactions are now also output in CICSBAD instead of

CICSTRAN."

There are 3 normal ways to terminate a CICS task, all

using a CEMT SET TASK command or CEKL SET TASK command:

1) Purge this is what is normally called a cancel.

The task is terminated. Task termination occurs

only when system and data integrity can be

maintained.

2)Forcepurge this is what is normally called a purge.

The task is terminated immediately. System integrity

is not guaranteed.
3)Kill has more option then a Forcepurge but seems to

have the same effect.

Both Forcepurge and Kill may crash the CICS region.

Kill may free up a stall CICS region.

Change 24.154 -ERROR: VARIABLE THREADTY NOT FOUND if both DB2ACCT and

ANALDB2R ASUMDB2A existed in the "PDB" with PMACC03/PMACC04=YES.

Aug 18, 2006 The PMACC03 and PMACC04 reports require detail data, but

the logic incorrectly used ASUMDB2A.

-In addition, references to ASUMDB2P dataset are commented

out, as that dataset does not (yet?) exist.

Thanks to Steve Olmstead, Northwestern Mutual Company, USA.
Change 24.153 Support for EMC's Centera Mainframe HSM Migrator user SMF

EXCMHMEV records. New CMHMEVNT dataset for each recall or migrate

IMACAAAA with start, end, and elapsed duration, dataset size, and

IMACCMHM attributes of the dataset.

TYPECMHM This support is preliminary, as both the contents of the

VMACCMHM new SMF record, and how MXG handles the data, may be

VMXGINIT changed when user's get their hands on the new product

Aug 18, 2006 and its SMF data.

Change 24.152 SMF 80 INPUT STATEMENT EXCEEDED RECORD LENGTH because MXG

VMAC80A did not protect $VARYINGnn lenmm for the case when lenmm

Aug 18, 2006 was greater than nn. While many RACF fields have a true

Oct 13, 2006 maximum nn (like 44 for DSNAMEs), some fields were INPUT

with $VARYING200. because no max was known or documented.

And 200 was used because SAS V6 was limited to 200 bytes

for character variables. But MXG no longer executes with

SAS V6, so all of the $VARYING200. are now $VARYING255,

and they are all protected if the text exceeds 255, with

a message and hex dump on the log printed if the length

exceeds MXG's expectation. Fields protected: RACF263,

RACF295, RACF298, TOKDANAM TOKHOME, TOKPROG, and TOKLDAP.

This was tested in Aug, but VMAC80A was not updated until

October.

Thanks to Kim Nguyen, National Australia Bank, AUSTRALIA.
Change 24.151 The _VMINPUT macro, to read z/VM MONWRITE data converted

VMACVMXA from it's native RECFM=U to RECFM=VB, did not include the

Aug 18, 2006 IMACVMXA member nor execute the &MACVMXA macro variable.

Thanks to Steven Clark, DHL, USA.

Change 24.150 Typo in the KEEP= list for dataset HURN49, and the label

VMACHURN statement had HU47BJOB and HU47BSTP, instead of correct

Aug 17, 2006 names of HU49BJOB and HU49BSTP, added by Change 20.248.

Thanks to Colin Bowen, CSC Computer Sciences, SOUTH AFRICA.

Change 24.149 -New variables in VTCS Subtype 15 are now decoded:

VMACSTC STC15CTP='*S-CART*OR*E-CART?'

Aug 17, 2006 STC15LRI='HSTRESIDENCY*RECALL OR*CREATE?'

Aug 21, 2006 -The _VSTCV13 keep list now keeps STC13MRC instead

of STC15MRC.

Rudolf Sauer, T-Systems, GERMANY.

Change 24.148 Variable DATECLN was not converted from the raw record's

VMACTMS5 cyyddd format, so the julian date of 2004241 printed as

Aug 17, 2006 104241. Now, like other TMS dates, DATECLN is converted

to yyyyddd format.

And if you need to see that as a "real date", you can

use CLNDATE=DATEJUL(DATECLN);

FORMAT CLNDATE DATE9.;

and see that 2004241 julian was 28AUG2004.

Thanks to DJ Chen, Florida Department of Corrections, USA.
Change 24.147 -Variable JBAFF in dataset TPMJBAFF was blank when it

VMACTPMX should have been populated, and populated when it should

Aug 16, 2006 not have been; the IF test missing the NOT now is coded:

IF SYSAFF NOT = : TPMXTEST THEN SYSAFF=' ';

NOTEBENE: THIS AUG CHANGE WAS WRONG, THE NOT DOES NOT

BELONG, AND THE CODE WAS CORRECTED IN CHANGE 24.199.

The two FORMATS in your IMACTPMX must match your SYSPLEX

and AFFINITY systems, for JBAFF to be correct. The MXG

logic was originally correct, and now is after Oct 5.

-Variables UMANUAL, UME, UMB now all contain "MANUAL" in

their labels.

Thanks to Kris Ferrier, State of Washington DIS, USA.

Change 24.146 The TRANSLATE(TRANSACT,' ','00'x) statement was relocated

VMACTMO2 so both TRANNAME and TRANSACT have those nonprintable

Aug 15, 2006 characters changed to blanks. TRANSACT was named from

the Landmark DSECT when TYPEMONI was written, but now,

with hindsight, I should have use TRANNAME as the name

for all Transaction Names. TRANNAME was added to the

MONITASK dataset because CICSTRAN users expected it when

they switched to TMON for CICS.

Thanks to Salis Gross Kurdin, Credit-Suisse, SWITZERLAND.
Change 24.145 Support for optional PRPRTYPE='9901' User Log Record in

VMACPRPR Oce's Prisma Print product log records creates new

VMXGINIT dataset PR9901 with variable PRPR9901 containing all of

EXPR9901 the text after ACCOUNT, and variable LEN9901 has the

IMACPRPR length of that text.

Aug 15, 2006

Thanks to Engelbert Smets, Provinzial, GERMANY.
Change 24.144 Reading NDM Log records (instead of SMF format), record

VMACNDM NDMRTYPE='RJ' caused INPUT STATEMENT EXCEEDED record

VMACSMF error; the OFFTODSN,OFFPACCT,OFFRSACCT offsets did not

Aug 16, 2006 include +OFFSMF in their calculation (for normal dumped

SMF records, OFFSMF=0, so the logic error was missed,

until the log-format records were read.

-NDM Logs with a single 13-byte '***NO DATA***' record are

now detected and deleted in the _LOGSMF macro defined in

VMACSMF, but only used by TYPENDML to read //LOGSMF DD.

-NDMCPUTM could be wrong and very large, when the VLR data

section was after the VLS data section, because MXG code

expected VLR first; now, the INPUT is reset correctly no

matter which order the segments are found.

Note: Change 24.160 corrected NDMCPUTM.

-Support for new variables that were added by 4.3 to the

NDMCT dataset:

NDMCKPI ='CHECKPOINT*INTERVAL'

NDMCPU ='CPU TIME*OF STEP*VIA*TIMEUSED'

NDMDBPAD='DBCS*PAD*CHAR'

NDMDBSI ='DBCS*SHIFT-IN*CHAR'

NDMDBSO ='DBCS*SHIFT-OUT*CHAR'

NDMDBTAB='DBCS*TABLE*NAME'

NDMRIPCH='INBOUND*OUTBOUND*IP ADDRESS'

NDMRPOR ='OUTBOUND*PORT'

In my small number of test records, the new NDMCPU

CPU time was zero, and NDMCPUTM was always missing.

Further investigation is needed. See Change 24.182.

-Perhaps support for 4.5. There is a bit flag in the DMRCT

DSECT for new fields added in 4.5, but there are no new

data fields described in that DSECT, so I believe this is

all that is required to support NDM/Connect Direct 4.5.

Thanks to Rob Hollingum, HSBC, ENGLAND.

Change 24.143 Format MGPLOT is added to FORMATS; it is used in ANALDB2R

FORMATS to generate text lines for some reports.

Aug 11, 2006
Change 24.142 -PDB.TYPE70 variables SMF70Q00-SMF70Q12 values were wrong,

VMAC7072 because they were missing the factor of 100 to convert to

Aug 11, 2006 percentages, and their labels, starting with SMF70Q04 had

the wrong +n values in the N+n part of the label. Correct

labels are belos (e.g., SMF70Q08 is the percentage of

time when the number of IN-AND-READY ASIDs was between

21 and 30 larger than the number of CPUs that were online

to this z/OS system when this sample was taken):

SMF70Q00='PERCENT*WHEN*IN READY*LE N CP-S'

SMF70Q01='PERCENT*WHEN*IN READY*LE N+1 CP-S'

SMF70Q02='PERCENT*WHEN*IN READY*LE N+2 CP-S'

SMF70Q03='PERCENT*WHEN*IN READY*LE N+3 CP-S'

SMF70Q04='PERCENT*WHEN*IN READY*LE N+4-5 CP-S'

SMF70Q05='PERCENT*WHEN*IN READY*LE N+6-10 CP-S'

SMF70Q06='PERCENT*WHEN*IN READY*LE N+11-15 CP-S'

SMF70Q07='PERCENT*WHEN*IN READY*LE N+16-20 CP-S'

SMF70Q08='PERCENT*WHEN*IN READY*LE N+21-30 CP-S'

SMF70Q09='PERCENT*WHEN*IN READY*LE N+31-40 CP-S'

SMF70Q10='PERCENT*WHEN*IN READY*LE N+41-60 CP-S'

SMF70Q11='PERCENT*WHEN*IN READY*LE N+61-80 CP-S'

SMF70Q12='PERCENT*WHEN*IN READY*GT N+80 CP-S'

-PDB.TYPE70 PCTRDYWT, the percentage of time there were

more READY asids than NRCPUS (used to estimate latent

demand), is calculated from the READY00-READY15 variables

summing READYnn's for nn's GE NRCPU, but there are only

14 READYnn buckets, so PCTRDYWT will always be missing

when NRCPUS is more than 14 in your SYSTEM.

-New variable PCTRDQWT may be used in place of PCTRDYWT,

as it's upper bucket is 80 ASIDs more than your NRCPUS,

and is quite easily calculated directly using

PCTRDQWT=100-SMF70Q00;

but PCTRDQWT is counting the IN-and-READY users, whereas

the PCTRDYWT was counting the READY ASIDs.

-PDB.TYPE70 labels for all of the READYnn variables are

corrected to "READY" instead of "IN READY", and

READY15 ='PERCENT*WHEN 15*OR MORE*READY'

is now that label.

-Observations were output in PDB.TYPE70PR for spare IFAs,

but my intention was not to output any spare segments, so

the test "OR SMF70CIN NE 'CP'" was removed, and now,

only if SMF70ONT NE 0 OR LPARNAME='PHYSICAL' will the

segment be OUTPUT in PDB.TYPE70PR.

Thanks to Jim Horne, Lowe's Companies, USA.

Thanks to Andrew Hebden, Barclay's, ENGLAND.

Change 24.141 Processing of DB2 data written to GTF was inconsistent,

UDB2GTF sometimes failed completely, or sometimes skipped data.

UDB2GTFA -The MXG utility UDB2GTFA, for MXG execution under ASCII

VMACDB2 SAS to convert the 256-byte DB2 GTF records into

Aug 10, 2006 legitimate complete DB2 SMF records from those itty-bitty

pieces, only worked for the first record. Revisions

correct that problem, and added more debugging facilities

to ease validation.

-The UDB2GTF utility for EBCDIC SAS execution was fine;

the only change was to enhance its debugging messages.

-For GTF input, VMACDB2 was resetting OFFSMF back to zero

too early for the 100-1 and 101-1 records, causing the

triplets for QBGN, QTGS, and QLES (DB2STATS) and for

QXPK, QBAC, QTXA (DB2ACCTP only) to be incorrect, which

could cause those variables to either be missing or to

be horiffically wrong, but with no error in either case.

Those triplets are now correctly input with OFFSMF=12 for

GTF, and OFFSMF is now correctly reset only after all of

the triplets have been input.

-For SMF or GTF input, VMACDB2 INPUT the QLES triplet from

the wrong (preceding) location, causing those statistics

variables to be incorrect. The QLExxxxx variables are

now also labeled.

Thanks to Thomas Heitlinger, FIDUCIA IT AG, GERMANY.

Change 24.140 Support for optional user-created CICS fields with

IMACICU1 CMODNAME='ARZGEOS',CMODHEAD='FACHG' (IMACICU1) and

IMACICU2 CMODNAME='ARZGS',CMODHEAD='GSACCT' (IMACICU2).

UTILEXCL The UTILEXCL member must be used to create IMACEXCL

VMAC110 and the comment block in each of the IMACICU1/IMACICU2

Aug 9, 2006 members must be EDITED for those variables to exist.

Aug 10, 2006 -On Aug 9, I noticed that these optional variables

MQGETWTM MQGETWCN MQREQS MQWTCBUS MQONTCBU MQREQUS

created by a user-created CMODNAME='MQSeries' segment,

could be kept in CICSTRAN, when they shouldn't have been

(they were in the "compiler faker" block, not used for

optionals). They were removed from the faker block

today, today when John saw them present and wanted to

know why they were all blank; quite timely!

Thanks to Richard Hilber, Allgemeines Rechenzentrum GmbH, AUSTRIA.

Thanks to John Ferguson, Washington Mutual, USA.

Change 24.139 If there were no observations in TYPETALO but SPINTALO

ASUMTALO had observations, a strange syntax error was generated

Aug 8, 2006 about (LOWTIME='141515...'DT) being invalid due to a

PUT statement without DATETIME21.2 format.

(The actual error occurred in ANALCNCR text, but the

call was from ASUMTALO, which needed the correction.)

Thanks to Edward M. Burns, Blue Cross Blue Shield of Nebraska, USA.
Change 24.138 Incorrect inclusion of DB2PARTY='R' Rollup observations

ANALDB2R in creating accounting summary report caused average

Aug 4, 2006 values to be wrong; the R record was counted as a PLAN

(doubling the denominator when there was one execution).

Also, the in-DB2 elapsed time could be larger than total

elapsed time: ELAPSTM is missing in the R record, so the

average elapsed was one half the base record's elapsed

duration eg: ( 4 + 0 )/2 = 2 hr. avg total elapsed.

But both had QWACASC in-DB2-elapsed time which were then

averaged eg: ( 3 + 2 )/2 = 2.5 hr avg in-DB2 elapsed!

Clearly, including the elapsed and in-DB2 time from the

Rollup record, and counting it as a plan, created invalid

average values in the summary reports; now, for Rollups,

the count of plans is not incremented, and QWACASC is set

to zero in the sum, so the average class 2 elapsed in-DB2

time reflects the base transaction(s).

Thanks to Yaohua Hu, Insurance Service Office, USA.

Thanks to Issac Lukach, Insurance Service Office, USA.

Change 24.137 MXG Variable PRODUCT in the PDB.TYPE70 dataset identifies

VMACSMF "RMF" or "CMF=." as the creator of the 70-79 SMF records.

Aug 3, 2006 To identify CMF from RMF records in case both are being

created, you could test PRODUCT=:'CMF' in each of the

EXTY7xxx exit members, but you can alternatively use this

logic to input the RMF Product Segment header and skip

the CMF records:
%LET MACFILE=

%QUOTE(

IF 70 LE ID LE 78 THEN DO;

INPUT @25+OFFSMF OFFRMFP &PIB.4. /*SMF70PRS*/

@29+OFFSMF LENRMFP &PIB.2. /*SMF70PRL*/

@31+OFFSMF NRRMFP &PIB.2. /*SMF70PRN*/

@;

OFFRMFP=OFFRMFP-3+OFFSMF;

INPUT @OFFRMFP+28 SMF70RV6 &PIB.2. @;

IF SMF70RV6='........1.......'B THEN

PRODUCT='CMF-CPM';

ELSE IF SMF70RV6='.........1......'B THEN

PRODUCT='CMF-IPM';

IF PRODUCT=:'CMF' THEN DELETE;

END;

);

Thanks to Xiaobo Zhang, CheckFree, USA.

Change 24.136 When DB2 V8 option UIFCIDS=YES is used, many text fields

VMACDB2 in DB2 SMF records that used to contain EBCDIC characters

VMACDB2H will instead contain ASCII text, which, when INPUT by MXG

Aug 4, 2006 with $EBCDICnn INFORMAT, creates unprintable text data.

IBM puts %U in the DSECTS for these ASCII fields, and

in DSNDQWHS %U is described as UniCode UTF-8, but UTF-8

is just simple ASCII text. A few fields with ASCII text

were already supported in MXG, but with UIFCIDS=YES on,

all of these variables were found to contain ASCII text:

%U Header variables QWHCAID QWHCOPID

%U Package variables QPACCOLN QPACLOCN QPACPKID

%U Location variables QLACLOCN QLSTLOCN

%U in DSNDQMDA only QMDALOCN

%U nowhere, but ASCII: QWACNID

Except for QWACNID, all above have %U in their DSECT and

have offsets to their 128-byte extended area, so they now

must be increased to LENGTH $128. QWACNID was found with

ASCII text, but it is not listed as %U in DSNDQWAC nor

DSNDWMSG, and it has no extended area documented, so it

remains unchanged at LENGTH $16.

IBM sets QWHSFLAG='80'x if the %U fields contain Unicode,

and MXG sets variable DB2UNICD='Y' (now kept in DB2ACCT

and DB2ACCTP) to conditionally INPUT these fields as

EBCDIC or ASCII, so the resultant variable will always

contain printable characters.
While these %U variables must be LENGTH $128, MXG's sets

COMPRESS=YES to compress out those blanks, and so there

should not be any increase in disk space required.
This change supports all of the %U fields in the SMF 100

(Statistics) and SMF 101 (Accounting) records, and in the

DB2 Header for all DB2 SMF records, but there are many

other %U fields in the DB2 Trace IFCIDS that are written

in SMF 102 records; these will also eventually be fixed,

initially on an I-have-this-trash-in-this-IFCID basis.

Thanks to John Hammond, Texas State Comptroller of Public Accts, USA.
Change 24.135 XAM variables from the MTRSYS segment, starting with the

VMACXAM SYSTMID (system) variable were all incorrect; the +2 that

Jul 30, 2006 skip 2 bytes before SYSTMID was INPUT do not exist, and

that statement was removed by this change. These are the

variables that were wrong:

CPUCAPAB CPUCFGCT CPUCFGCX CPUCHAR CPUCOUNT

CPUCOUNX CPUDEDCT CPURESVD CPURESVX CPUSHARD

CPUSTNBX CPUSTNBY DEDCNT IOPCNT LPARCAF

LPARNAME LPNUMBER SCPCAPAB SYSCKVOL SYSMMODL

SYSMPOM SYSMSEQC SYSMTYPE SYSTMID SYSWMVOL

VL3CAF VL3CFGCT VL3COUNT VL3CPNAM VL3DBCT

VL3MNAME VL3RESVD VL3STNBY

Thanks to Mike Salyer, Citigroup Technology Infrastucture, USA.

Thanks to Bob Bates, Citigroup Technology Infrastucture, USA.

Change 24.134 If USEREPRT=COMPAT or USECNTRL=COMPAT was specified, no

VMXGRMFI values were created in any workloads. Change 24.079 had

Jul 30, 2006 removed that option, but a test for this option was left

that caused the deletion of all TYPE72GO obs. Only with

MPRINT turned on was it revealed that the statement

IF SYSTEM NE: 'COMPAT' THEN DELETE; was in the generated

code, so the code assumed that COMPAT was a system name.

Now if COMPAT is specified, and MXGWARN message will be

printed indicating that COMPAT is no longer supported,

and processing then continues.

Thanks to Tom Kelman, Commerce Bank of Kansas City, USA.
Change 24.133 The IMACKEEP include was relocated so it is now after the

ASUMMIPS macro definitions, so they can be changed. And the MIPS

Jul 30, 2006 factor's comments are revised to now read:
THE MIPS CALCULATION DEFAULT IS A CONSTANT OF 5.8 TIMES MSU.

HOWEVER, THAT IS A SPECIFIC VALUE AT ONE POINT IN TIME FOR

ONE PROCESSOR, AND BY NO MEANS IS THAT A "RECOMMENDED" VALUE.

SINCE 'MIPS' ARE DEFINED BY YOU, AND NOT MXG, YOU CAN USE

WHATEVER VALUE YOU/YOUR-MANAGEMENT DECIDE IS THE APPROPRIATE

CONVERSION FACTOR TO GET MIPS FROM MSU.

THAT'S PRECISELY WHY THE FACTOR IS DEFINED IN THE _MIPSMSU

MACRO, SO YOU CAN CHANGE IT TO YOUR VALUE, AS SHOWN BELOW.

Thanks to Wayne Bell, UniGroup, USA.
Change 24.132 Analysis of DD segment counts was revised to use "new"

ANALDDCN MXG exit facility, instead of the old IEBUPDTE technique

Jul 30, 2006 to tailor the analysis program.

Thanks to Chuck Hopf, Bank of America, USA.

Change 24.131 INPUT STATEMENT EXCEEDED RECORD LENGTH error because the

UTILEXCL Omegamon/Candle type 110 dictionary entry is truncated if

Jul 30, 2006 the CMODHEAD field name of the last of their optional

fields is not 8 bytes. The dictionary entry is supposed

to always be fixed (MCTSSDRL=26), but in this case, the

last field name was OMEGDB2 and the last dictionary entry

was only 25 bytes. MXG now tests for the field length

and protects for the invalid dictionary record.

Thanks to Burt.Allen, Harris County ITC, USA.
Change 24.130 Support for Oracle was revised to support only current

VMACORAC versions, so I could eliminate the test for Subsystem.

Jul 22, 2006 Previously, if Subsystem ID changed but MXG's macro was

Dec 19, 2006 not updated, almost all variables were missing. These

ANALORAC pre-V9 variables have always been missing and are now

removed (not KEPT) from the ORACLE dataset:

CPUCICTM CPUSRBTM CPUTCBTM CPUTIMER DDLCOMIT DDLROLLS

ENDSRB ENDTCB ORACMSB PCCOUNT STRTSRB STRTTCB

SWTCHCNT TCBADDR

-Dec 19, 2006: ANALORAC updated to remove references to

the variables that were DROPed.

Thanks to Huug Tempelmans-Plat, CORUS Group, ENGLAND.

Change 24.129 Support for up to 10 CICS ABCODE values in PDB.ASUMUOW.

VMXGUOW The ASUMUOW program logic keeps three sets of ten arrays

Jul 19, 2006 one for transaction name, one for APPLID, one for ABCODE,

which can optionally be kept by adding a KEEP statement

in the TRANUOW macro in your tailored IMACUOW member.

The base variables are TRAN1-TRAN10, PATH1-PATH10, and

new ABEND1-ABEND10.

By default, the first blank ABENDn value is kept in the

ABCODE variable, but you can alter the logic in TRANUOW

as needed.

Thanks to Stan Adriaensen, Axa-Tech, BELGIUM.
Change 24.128 The new ZIP variables from SMF 30s were not kept in the

ASUMDB2A PDB.STEPS and PDB.JOBS variables, but are now added to

BUIL3005 both datasets. And, the DB2ACCT zip variables are now

BUILD005 summarized in ASUMDB2A.

Jul 22, 2006

Thanks to Jim Kovarik, AegonUSA, USA.

Change 24.127 Support for fourth GEPARMKY='4D'x and GEPARMKY='4A'x adds

IMAC6ESS optional variables ESSMAIL5 and ESSMACC1 respectively to

VMAC6 both TYPE6 and TYPE57 datasets. Also, the KEEP= list for

VMAC57 TYPE57 was updated to list all of the possible IMAC6ESS

Jul 19, 2006 variables, which had not been updated since 2004.

Thanks to Dr. Alexander Raeder, ATOSORIGIN, GERMANY.

Change 24.126 Variables NDMPRCNM NDMPRCNO NDMSTEP NDMUNODE are now kept

VMACNDM in the NDMFI dataset, so that NDMFI can be matched to the

Jul 16, 2006 NDMCT record to obtain the full file name.

Thanks to Mary Lou Arredondo, Federal Reserve, USA.

Change 24.125 ZIP variables were not kept in TYPE72GO dataset; IBM had

VMAC7072 used different names in early and later documentation,

Jul 13, 2006 and I was awaiting a reply as to which set was actually

going to appear in the SMF manual, and I expected their

reply would trigger my revision of names, but no reply

was received, and I forgot to go back and add the names

that I had started with. These are the new variables

that are now kept in TYPE72GO dataset for zip data:

R723NFFS CPUZIETM CPUZIPTM R723CIFA R723CIFC R723CSUC

R723CSUP R723SUCU R723SUPD R723SUPU ZIEUNITS ZIPUNITS

But the error was mine, not IBMs; my ESP contact had said

that because it was "only a documentation/naming query,

that I should not expect a fast reply".

Thanks to Scott Wigg, USBank, USA.

Change 24.124 -Warnings ZDATE and ZTIME in DROP/KEEP/RENAME not being

VMXG70PR referenced for the FINL70LP dataset because the call to

Jul 13, 2006 include IMACZDAT to create them was missing. That also

caused those variables to NOT be populated in ASUM70LP,

and also impacted variable SHIFT.