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

PASOO1C ='SOCKET CHARS SENT'

PASOOMC ='SOCKET SEND REQUESTS'

Dataset MONIPA new variables:

PIRECICT='PI*RECORD*COUNT'

PIKY9DST='KEY 9*DISPATCH*TIME'

PIKY9DSC='KEY 9*DISPATCH*COUNT'

PIKY9CPT='KEY 9*CPU*TIME'

PIKY9CPC='KEY 9*CPU*COUNT'

PIJ9CPUT='MODE*J9*CPU*TIME'

PIJ9CPUC='J9*CPU*COUNT'

PIDSMWT ='TCB*MISMATCH*TIME'

PIDSMWC ='TCB*MISMATCH*WAIT*COUNT'

PIDSCWT ='STG*CONSTRAINT*WAIT*TIME'

PIDSCWC ='STG*CONSTRAINT*WAIT*COUNT'

PIEJBACT='BEAN*ACTIVATION*REQUESTS'

PIEJBPCT='BEAN*PASSIVATION*REQUESTS'

PIEJBCCT='BEAN*CREATION*REQUESTS'

PIEJBRCT='BEAN*REMOVAL*REQUESTS'

PIEJBMCT='EJB*METHOD*CALLS'

PIEJBTCT='TOTAL*EJB*REQUESTS'

PIRODSPT='RO*DISPATCH*TIME'

PIRODSPC='RO*DISPATCH*COUNT'

PIROCPUT='RO*CPU*TIME'

PIROCPUC='RO*CPU*COUNT'

PIPTPWTT='PARTNER*WAIT*TIME'

PIPTPWTC='PARTNER*WAIT*COUNT'

PISOOMC ='SOCKET*SEND*REQUESTS'

PISOO1C ='SOCKET*CHARS*SENT'

PISOIMC ='SOCKET*RECEIVE*REQUESTS'

PISOI1C ='SOCKET*CHARS*RECEIVED'

PIJVIRST='JVM*RESET*TIME'

PIJVIRSC='JVM*RESET*COUNT'

PIJTDLYT='JVM*TCB*DELAYS*TIME'

PIJTDLYC='JVM*TCB*DELAYS'

PIHTDLYT='HOT*POOL*DELAYS*TIME'

PIHTDLYC='HOT*POOL*DELAYS'

Dataset MONITKP new variables:

TKPTOTMT='MVS*STORAGE*CONSTRAINT*WAIT*TIME'

TKPTOTMW='MVS*STORAGE*CONSTRAINT*WAITS'

Dataset MONITR new variables:

TRSTGWWT='STORAGE*REQUEST*WAIT*TIME'

TRSTGWCT='STORAGE*REQUEST*WAITS'

New Dataset MONIAMQ for MQ variables:

TAAMQCLC='MQCLOSE*CALLS'

TAAMQCLT='MQCLOSE*CALL*TIME'

TAAMQFLG='QUEUE*MQ*API*FLAG'

TAAMQGTC='MQGET*CALLS'

TAAMQGTT='MQGET*CALL*TIME'

TAAMQICT='TAAMQ*SEGMENT*COUNT'

TAAMQIQC='MQINQ*CALLS'

TAAMQIQT='MQINQ*CALL*TIME'

TAAMQMGO='ORIG*QUEUE*MANAGER*NAME'

TAAMQMGR='MQ*QUEUE*MANAGER*NAME'

TAAMQOPC='MQOPEN*CALLS '

TAAMQOPT='MQOPEN*CALL*TIME '

TAAMQP1C='MQPUT1*CALLS '

TAAMQP1T='MQPUT1*CALL*TIME '

TAAMQPTC='MQPUT*CALLS'

TAAMQPTT='MQPUT*CALL*TIME'

TAAMQQUE='MQ*QUEUE*NAME'

TAAMQQUO='ORIG*QUEUE*NAME'

TAAMQSTC='MQSET*CALLS'

TAAMQSTT='MQSET*CALL*TIME'

Change 22.190 Support for NTSMF Objects MicroStrategy Server Jobs and

EXNTMSSJ MicroStrategy Server Users create new datasets MSTRSRJB

EXNTMSSU and MSTRSRUS (MSTRSRJB is complete, but only structure

IMACNTSM code exists MSTRSRUS, with no fields, as the dictionary

VMACNTSM record for the User's object has not yet been created).

VMXGINIT Because some of the fields are presented as totals, and

Jul 29, 2004 are not deaccumulated interval values, the _SNTMSSJ sort

macro must be used to de-accumulate the datasaet, so the

first observation for each instance has missing values.

Additional heuristics to detect when these total values

went to zero (perhaps a shutdown of the process?) were

necessary.

Thanks to Bob Gauthier, Albertsons, USA.
Change 22.189 Major update added 1300 lines of text to document most of

ADOC110 the undescribed CICSTRAN variables, using IBM's CICS

Jul 29, 2004 Performance Analyzer Report Reference 1.3 manual.
Change 22.188 Variables S94VCA41-S94VCA48, S94CA481-S94CA488, and

VMAC94 S94CA351-S94CA358 are all multiplied by 60 (so their

Jul 29, 2004 internal value is seconds) and then formatted TIME8.

so they will print as hh:mm:ss units of time, since they

are all rolling average cache ages.

Thanks to Bruce Widlund, Merrill Consultants, USA.

Change 22.187 The format to map SAS Procs to their Product for the SAS

FORMATS user SMF record was updated for PROC SORTT, which is an

Jul 29, 2004 undocumented way of forcing the internal SAS Sort utility

to be used instead of a "host" sort product.

Thanks to Dave Thorn, SunGard Availability Service, USA.
Change 22.186 Omegamon/VTAM V520 IRNUM 29 caused DIVISION BY ZERO and

VMACOMVT LOOPING; the test for IRNUM IN (29,30) was incorrect for

Jul 28, 2004 IRIND NE 'L'.

Thanks to Phil Baxter, Capgemini Group, ENGLAND.

Change 22.185 Invalid SMF 80 Extended Relocate Section contained token

VMAC80A PROGRAM but there was no length of program name nor the

Jul 28, 2004 program name field following the token) caused and INPUT

STATEMENT EXCEEDED RECORD error. Circumvention tests for

expected length field, while IBM support is contacted.

Thanks to Engelbert Smets, Provinzial Rheinland Versicher., GERMANY.

Change 22.184 ASCII Execution only, SAS V9 only: EBCDIC character

DOC variables can contain hex zeros instead of blanks due to

Jul 28, 2004 a V9 SAS design change, which can cause character tests

to fail and/or cause spurious MXG error messages when an

expected character was not found. Under ASCII execution,

the $VARYINGn informat reads a variable length string,

but the value is "raw" and must be converted to EBCDIC if

that's what's really in the text. Previous to Version 9:

INPUT VARIABLE $VARYINGnn. LENTEXT @;

VARIABLE=INPUT(VARIABLE,$EBCDICnn.);

VARIABLE=TRANSLATE(VARIABLE,' ','80'X);

was sufficient: when LENTEXT was less than nn, $VARYINGnn

returned ASCII blank '20'x for the extra characters, the

INPUT function converted them to '80'x, and thus the

TRANSLATE of '80'x back to blank was necessary. Now, SAS

V9 $VARYING informat returns hex zeros, rather than ASCII

blanks for the extra characters, and the INPUT function

passes the hex zeros into it's output, so it is necessary

now to use these statements for each $VARYING variable:

INPUT VARIABLE $VARYINGnn. LENTEXT @;

VARIABLE=INPUT(VARIABLE,$EBCDICnn.);

VARIABLE=TRANSLATE(VARIABLE,' ','80'X);

VARIABLE=TRANSLATE(VARIABLE,' ','00'X);

to convert those unexpected hex zeros to character blank.

All 511 TRANSLATE statements with '80'x were replicated

and the '80'x changed to '00'x in the second instance in

these 55 MXG members:

ANALSNAP IMAC6ESS IMACACCT INSTALL SYSLOGJ3 UTILTPMX

UTILXREF VMAC102 VMAC103 VMAC119 VMAC120 VMAC24

VMAC33 VMAC37 VMAC42 VMAC4789 VMAC59 VMAC6

VMAC60 VMAC6156 VMAC80A VMACACC VMACACF2 VMACASXT

VMACCMA VMACCTLG VMACDB2 VMACEDGS VMACENDV VMACHMF

VMACHPDM VMACIMS VMACNDM VMACNETM VMACNSPY VMACOPFT

VMACPOOL VMACQACS VMACQAPM VMACRSDA VMACSARR VMACSASU

VMACSHDW VMACSOLN VMACTCP VMACTMDB VMACTPMX VMACTSOM

VMACVMON VMACVMXA VMACVVDS VMACXPSM VMXGHSM

- An alternative was to replace the INPUT and TRANSLATE

functions with INPUTC(variable,'$EBCDIC.'); but its

syntax needs additional quotes (the second argument

is not an INFORMAT, but a literal/variable containing

an informat), the length has to be removed, (it fails

if the informat has an "n" value), and in some cases

just didn't seem to work correctly (returned only one

character when there were three), all of which made

it very unattractive to EDIT/CHANGE those many times!

- The TRANSLATE statement supports multiple pairs, so

it could have been written as

VARIABLE=TRANSLATE(variable,' ','80'x,' ',00'x);

but that too was mechanically risky, and was too long

for some existing lines of code, so a second function

statement was inserted.
Change 22.183 The Working Set Size variables ACTVWSS and VMDWSSPR are

VMACXAM in 4096 byte blocks, so they are now converted to bytes

Jul 27, 2004 and FORMATed MGBYTES to "print pretty" storage units.

Aug 8, 2004 Aug 8: Semi-colon added to FORMAT statement to correct

error detected in Freddie's QA tests.

Thanks to Rodger Foreman, Acxiom, USA.

Thanks to Freddie Arie, TXU, USA.
Change 22.182 The field FCFILENM was truncated at 32 bytes; the INPUT

VMAC119 was 64 bytes, but the statement MINLEN=MIN(32,LEN11903);

Jul 26, 2004 is now corrected to MINLEN=MIN(64,LEN11903);.

Thanks to Ken Jordan, Pacific Gas & Electric, USA.

Change 22.181 Enhancements to RMF Reporting.

ANALRMFR -Online Time Percentage field added to CPU Activity Report

Jul 26, 2004 -Updates to Partition Data Report

-LPAR Cluster Report added, use REPORT=LCLUS to request.

Thanks to Jim Horne, Lowe's Companies, Inc, USA.
====== Changes thru 22.180 were in MXG 22.07 dated Jul 25, 2004=========
Change 22.180 IFA CPU variables added by APAR OA05731, Change 22.152

VMAC22 variable names are clarified and more consistent:

VMAC30 R723IFAT - IFA*CPU TIME*ON IFA

VMAC7072 R723IFCT - IFA-ELIGIBLE*CPU TIME*ON CP "C-for Coulda?"

VMAC71 Some additional revisions were made for IFA processors.

VMAC74 This change includes new fields added to RMF 74-5 by

VMAC75 APAR OA04877.

VMAC79

BUILD005

BUIL3005

Jul 24, 2004
Change 22.179 The UCICSCNT utility to examine and count CICS records in

FORMATS your SMF file was enhanced with additional reports on the

UCICSCNT Statistics STIDs found in your data, and corrected so the

Jul 23, 2004 PROC FREQs always work without error. New formats for

a description of STID and MNSEGCL are added in FORMATS.

Thanks to Tren Burner, City of San Antonio (TEXAS, of course), USA.

Change 22.178 The INSTANCE=, argument allows selection by "UOWIDCHR",

ANALDB2R the first six bytes of UOWID (which is also QWHSLUUV),

Jul 23, 2004 but the internal logic was wrong in ANALDB2R. The test

and comments for how to use INSTANCE= were revised; the

value passed must be hex characters, with no quotes and

without the "X" that is used for hex literals in data

step logic.

Thanks to Jim Mourgelas, TD Bank Financial Group, USA.

====== Changes thru 22.177 were in MXG 22.07 dated Jul 23, 2004=========
Change 22.177 Update to define MACRO _Vdddddd in selected members.

VMACIDMS -VMACIDMS: The _Sdddddd macros now invoke PROC SORT with

VMACTMS5 NODUP and the _Bdddddd macros are defined.

Jul 22, 2004 -VMACTMS5: _Vdddddd defined.

Aug 8, 2004 -Aug 8: These members were EDITed and support _V macros:

VMAC20 VMAC25 VMAC26J2 VMAC26J3 VMAC28 VMAC31

VMAC32 VMAC33 VMAC36 VMAC37 VMAC38 VMAC39

VMAC40 VMAC41 VMAC434 VMAC4345 VMAC44 VMAC4789

VMAC50 VMAC5234 VMAC535 VMAC5568 VMAC57 VMAC59

VMAC60 VMAC6156 VMAC6367 VMAC68 VMAC69 VMAC7

VMAC75 VMAC81 VMAC83 VMAC85 VMAC88 VMAC89

VMAC8911 VMAC90 VMAC90A VMAC91 VMAC92 VMAC94

VMAC97 VMAC99 VMACNSPY VMACSTC VMACSYNC VMACTCP

VMACTMNT VMACTPF VMACTSOM

Thanks to Dale Houg, Abbott Labratories, USA.

Thanks to Dr. Alexander Raeder, Itellium, GERMANY.

Change 22.176 Invalid SMF 42 subtype 5 caused INPUT STATEMENT EXCEEDED

VMAC42 error; this record contained only volume segments, with

Jul 21, 2004 422 valid segments, but the 423rd segment was overlaid.

It has valid S42VTNXT (00004FE4x) VOLSER (IMS210), DEVNR

(6BC5x) and S42VTFL1 (80x, indicating online), and 2 in

S42VTUNC, but the 2nd and 3rd offsets are overlaid:

S42VTVDO/S42VTVDL are '000000000000'x

S42VTVXO/S42VTVXL are '000000006C87'x and

S42VTVVO/S42VTVVL are '0001C4C2F2C2'x,

and the hex dump shows that last data is a VOLSER DB2B91

overlaying the third offset/length, and the rest of the

record is control unit information that doesn'b belong

there. MXG added tests to detect these invalid offsets,

and prints error messages for the first five bad records,

and prints a hex dump of the first bad record; variable

OFFVOL in the error message is the start of the defective

volume segment.

This text will be updated when an IBM fix is identified.

Thanks to Richard Haynes, Blue Cross Blue Shield of Kansas, USA.
Change 22.175 Major revision to this Utility to inventory the Contents

UTILCONT of SAS data libraries, reporting on size of each dataset

Jul 21, 2004 in MegaBytes, and the percentage of the library occupied

by each SAS dataset. The inventory can be output to the

ASUMSIZE dataset, which could be added to your PDB and

then TRENDed over time to monitor growth of your PDBs.

But only datasets are reported; DICTIONARY.TABLES doesn't

provide the size of CATALOGS (GRAPHS, SASMACR) in the

LIBNAMEs.

You can specify the list of LIBNAMEs to be inventoried

PDB=PDB WEEK MONTH (default is PDB=PDB), so to size the

datasets in yesterday's PDB in a standalone job on MVS

you would need to use this syntax:

// EXEC MXGSASV9

//PDB DD DSN=YOUR.PDB,DISP=SHR

//SYSIN DD *

%UTILCONT(PDB=PDB);

Under MVS, when you supply a list of LIBNAMEs, UTILCONT

issues a LIBNAME DDNAME SHR; statement for each LIBNAME;

the DICTIONARY.TABLES requires that each LIBNAME has

been 'referenced' (OPENed, or in a LIBNAME statement).

If any LIBNAME is sequential-format (e.g., tape), that

ENTIRE physical library must be read to find its size,

taking time and resources; you can skip reading of all

sequential format libraries using EXCLUDE=SEQUENTIAL,

or just don't put that LIBNAME in your list!

Instead, you can use PDB=_ALL_ to inventory all LIBNAMEs

that have been referenced; the _ALL_ choice enables the

EXCLUDE=SEQUENTIAL DUMMY GISMAPS LIBRARY MAPS SAS SASHELP

default list to skip sequential and 'SAS-owned' LIBNAMEs

that we think you don't want reported, but you can use

EXCLUDE=DUMMY GISMAPS LIBRARY MAPS SAS SASHELP in your

%UTILCONT invocation if you do want sequentials reported.

On MVS, the reported size closely matches the MVS dataset

allocated size, but on ASCII platforms the actual files

are slightly larger than the reported size; the directory

of variables is not included in pagesize*number-of-pages.
Change 22.174 Using the IDCAMS EXPORT Catalog function, the output file

VMACCTLG always has a few defective records, but those records do

Jul 20, 2004 not appear to actually contain any catalog segments. This

change revises the old "NOT UNDERSTOOD" MXG messages with

specific description of the two possible defects found.

IBM's "trench-holder" technican who "owns" the catalog

records refused to provide any documentation, claiming

the catalog records are "object code only", and their

contents could not be released, and his manager was also

unable to listen to reason (like, do they really think

think Microsoft is going to create a competing catalog

dataset, as kludgy as IBM's???), so I can only continue

to delete the defective records in the export file.

-The comments now contain the JCL for the IDCAMS program.

Thanks to Greg Burt, Fifth Third Bank, USA.
Change 22.173 Support for RMF 99 subtypes 3, 4, and 8 create four new

EXTY99U3 datasets:

EXTY994I dddddd dataset description

EXTY998L TY99U3 TYPE99_3 99-3 Service Class Period

EXTY998P TY994I TYPE994I 99-4 Device Cluster

IMAC99 TY998L TYPE998L 99-8 LPAR

VMAC99 TY998P TYPE998P 99-8 Priority Table

VMXGINIT -None of the "Plot" tables are created for these subtypes;

Jul 17, 2004 only tables that had test data are supported.

-I made blind guesses as to the format of two variables,

S998CPUT and S998PTMA.

Thanks to Richard S. Ralston, Humana, USA.

Change 22.172 ASCII only. Zero observations in TYPEVVDS because the

VMACVVDS INPUT of VVRTYPE was $EBCDIC1. instead of $CHAR1. Other

Jul 17, 2004 HEX-containing variables were also corrected and INPUT

with $CHAR and formatted with $HEX. On "MVS", $EBCDIC

and $CHAR are the same, but not so on ASCII platforms

This member was overlooked, because most sites use the

TYPEDCOL/DCOLLECT data to examine VVDS data, but the

TYPEVVDS has more detail information and is now correct.

Thanks to Glenn Bowman, Wakefern, USA.
Change 22.171 Enhancement for RMF III VSAM file reading program.

ASMRMFV -The very last CSR table entry was not being output.

Jul 16, 2004 -RMFV104I message for RED record type always showed Y for

SELECT, even when that table was not selected. Only the

message was incorrect; data exclusion did occur if RED

table was not selected.

Thanks to Jerome Urbaniak, Acxiom CDC Inc, USA.

Thanks to Len Romano, Hewitt Associates, USA.

Change 22.170 Support for TNG NT Windows Server 2003 Enterprise Ed 5.2,

EXTNT067 PLATFORM='WNE502I', added 35 new objects, some of which

thru are also created on PLATFORM='NTS500I. New NT datasets

EXTNT099 NT065 thru NT099 are documented in updated IMACTNG.

FORMATS -LENTEXT GT 99 tests caused errors with INSTANCE names

IMACTNG greater than 36 characters; all were revised to test for

VMACTNG GT 35 (TNG's base-35 encoding has '10'=36) to bump LOC

VMXGINIT by 2 positions; this should have been fixed earlier, but

Jul 16, 2004 -New MIB-2 Object data had over 12,000 instances for three

metrics, which makes little or no sense, and until that

data is better understood, only the first instance will

be output in new NT089 dataset.

-If you use the distributed TYPETNG/TYPSTNG members, you

must remove the %LET MAXROWS=1; statement that was added

by Change 22.160 to override the MAXROWS=288 MXG default

(288 supports 24 hours of 5-minute-interval data cubes).

-With MAXROWS=288 and the MXG default array sizes, the

TYPETNG program now needs about 300MB of virtual memory.

Thanks to Peter Krijger, National Bank of New Zealand, NEW ZEALAND.
Change 22.169 Support for Hogan System's optional CICS segment was not

IMACICHO complete; UTILEXCL recognized Hogan data was present, but

VMAC110 the IMACICHO member did not exist. It does now, and will

UTILEXCL create these four Hogan variables:

Jul 15, 2004 FPSAPPL - Application Code

FPSFUNC - Function Code

FPSCSCR - Current Screen

FPSSIPR - Previous Screen

Old code in IMACICUS had additional Hogan variables:

FPSACTN ='HOGAN*ACTION*CODE'

FPSOPTN ='HOGAN*OPTION*CODE'

FPSSCRN ='HOGAN*SCREEN*NAME'

PLDVERS ='HOGAN*PAS*VERSION'

TCTPLD ='HOGAN*ODS TCTNAME/*PAS PLDNAME'

TCBFUNC ='HOGAN*ODS TCT*TRANCODE'

and those variables will be in the _VCICTRN macro if the

Hogan data is detected by UTILEXCL, but only the fields

actually created in your IMACICHO will exist in CICSTRAN.

Thanks to Scott Wiig, USBank, USA.
Change 22.168 Support for HMF V2.7 adds subtypes 26, 27, 28 creating

EXTYHMFP St dddddd Dataset Description

EXTYHMFQ 26 TYHMFP TYPEHMFP ULTRANET SNMP TRANSPORT STATS

EXTYHMFS 27 TYHMFQ TYPEHMFQ ULTRANET SNMP TRANSPORT STATS

VMACHMF 28 TYHMFS TYPEHMFS ULTRANET SNMP DECOMPRESSION

VMXGINIT Variables in TYPEHMFT TYPEHMFU stored in the original

Jul 7, 2004 named/labeled variables; both 29 and 30 subtypes have

fewer variables, but Change 21.143 did not handle that

revision correctly.

Thanks to Perry Lim, Union Bank of California, USA.

Change 22.167 Variable STATIND in TYPE77 is a one byte numberic flag

ADOC77 byte, but it should have been formatted as HEX2. The bit

VMAC77 descriptions in ADOC77 were incomplete and incorrect, and

Jul 8, 2004 bit 6 ON was not even documented by IBM, but the bits are

now correct. A value of 03 is normal, as it indicates

that bit 6 and bit 7 are on, i.e., you have a GRS=STAR

configuration.

Thanks to Rodger Foreman, Acxiom, USA.

Change 22.166 Support for STK ExHPDM user SMF record.

EXHPDM00 DDDDDD DATASET DESCRIPTION

EXHPDM01

EXHPDM02 HPDM00 HPDMAU00 AUDIT STARTUP/SHUTDOWN

EXHPDM03 HPDM01 HPDMAU01 AUDIT CLIENT REQUEST

EXHPDM04 HPDM02 HPDMAC02 AUDIT CONNECTION ACCOUNTING

TYPEHPDM HPDM03 HPDMPE03 AUDIT STREAM TASK PERFORMANCE

TYPSHPDM HPDM04 HPDMAU04 AUDIT DATABASE TRANSACTION

VMACHPDM -Problems in data:

VMXGINIT Variable SOV2DEVN, 'Device Definition Name' has '0E'x in

Jul 19, 2004 in first byte, then 7 blanks in subtype 2, but is text

'DEVICE3' in subtype 3 records.

Thanks to Al Holtz, MEDCO, USA.
Change 22.165 BUILDPDB now detects "overlapped" SMF data was read in.

BUILD005 If you read the same SMF file in two separate PDB runs,

BUIL3005 or if you rerun BUILDPDB to re-create a PDB library and

Jul 8, 2004 did not restore the SPIN library, there will be duplicate

Aug 25, 2004 observations in the SPIN30_1 dataset; MXG now detects the

Oct 28, 2004 duplicates, and prints ERROR. DUPLICATE TYPE 30 SUBTYPE 1

messages on the SAS log. I had considered ABENDing for

this condition, but in this implementation, only error

messages are printed.

-The symptom that detected this problem was a change in

the number of observations in PDB.SMFINTRV, and messages

NOTE: MERGE STATEMENT HAS MORE THAN ONE DATASET... for

the TYPE30_V interval dataset, because the SPIN30_1 data

is used to populate the ACCOUNTn variables in PDB.SMINTRV

dataset, even though no interval records are "spun".

-For any rerun of BUILDPDB, you must restore the //SPIN

library to contain what it did before that failed run;

BUILDPDB automatically backs up your SPIN datasets into

the PDB library, so all you need do is to go back to the

last successfully build PDB library and restore the SPIN:

// EXEC MXGSASV9

//PDB DD DSN=LAST.GOOD.PDB,DISP=SHR

//SPIN DD DSN=YOUR.SPIN,DISP=OLD

//SYSIN DD *

PROC COPY IN=PDB OUT=SPIN;

SELECT SPIN: ;

and then you can rerun BUILDPDB with the SMF data that

failed; you may need to edit IMACZDAT to set the ZDATE

of the re-built PDB library, if you have skipped a day.

-Aug 25: Added restriction to only examine BAT/TSO/STC job

records with a JES Number. OMVS/USS creates multiple job

initiate records with the same READTIME/JOB/JINITIME and

a missing JESNR that erroneously caused the "duplicate"

MXG message.

-Oct 28: Corrected tests for BAT to JOB and TSO to TSU, as

those are the correct spelling of TYPETASK values. With

original spelling, only STC tasks were being examined.

And the CRITICAL ERROR. DUPLICATE TYPE 30 message now

shows where the overlapped records were found.

Thanks to Tim Gilchrist, Department of Defence, AUSTRALIA.

Thanks to Pat Curren, SuperValu Inc, USA.

Thanks to Udo Froehling, Signal-Iduna, GERMANY.

Change 22.164 The %VGETJESN invocation was moved after variable SYSTEM

VMACSFTA has been set. Initially, I saw no error in my tests, but

Jul 8, 2004 the PUT in VGETJESN for error conditions had a blank for

Aug 11, 2004 SYSTEM that was corrected by the relocation. However, I

now have test data that failed with error messages that

NOTE: INVALID NUMERIC DATA, STEPNAME='XXXX' that were

corrected by this change, so it all depends on which of

the SoftAudit files have data as to whether this change

is cosmetic, or required!

Thanks to Jim Kovarik, Aegon, USA.

Thanks to Ng Kin, Acxiom, USA.