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

Part of this problem has been reported to IBM under APAR

OY27665 (1989!), which has no PTF and was "CLOSED - SUG",

meaning its only a suggestion to the developers!

Thanks to J. G. Vlietstra, Ultramar Canada, CANADA.

Change 10.212 New variables SPMSCTST and SPMSXSQN are created, and old

FORMATS variables SPMSEL1,EL2,SL1,SL2,SL3 were deleted, and format

VMACSPMS MGAMDCS and MGAMDDT were added to decode SPMSCTST,SPMSDTYP

Oct 27, 1992 respectively. This completes Change 10.069.

Thanks to Joseph G. Ogurchak, Westfield Companies, USA.
Change 10.211 DB2 Trace variable QW0145OB in dataset T102S145 has value

VMAC102 of QW0145DB; statement QW0145OB=QWX145DB should have been

Oct 26, 1992 QW0145OB=QWX145DB. Variables QW0141TX,QW0142TX,QW0145TX

are now input as $VARYING200 (were only 100) to be same as

the SQL text field in the other audit trace records.

Thanks to Jorn Fledelius, Kommunedata I/S, DENMARK

Change 10.210 Several DB2STAT0 & DB2STAT2 variables were deaccumulated

DIFFDB2 that should not have been. (Because IBM often fails to

Oct 26, 1992 identify whether fields are accumulated or not, only real

data values can prove to DIF() or not to DIF(). Most of

these fields are from Distributed DB2, and only now do we

have test data with non-zero values with which to validate

accumulation.)

DB2STAT0 variables which must be removed from DIFFDB2:

QWSBSACT QW2BSACT QW3BSACT QW4BSACT QW5BSACT

DB2STAT1 variables which must be removed from DIFFDB2:

QB1TWFM QB2TWFM QB3TWFM QB4TWFM

QDSTQDBT QISEKT QISESKPT QISTRCUR QTCURPB QTPUBDD

QTSLWDD and all QLST fields: QLSTABRR QLSTABRS

QLSTBRBF QLSTBROW QLSTBTBF QLSTBRBF

QLSTBROW QLSTBTBF QLSTBYTR QLSTBYTS QLSTCBLB QLSTCNVQ

QLSTCNVR QLSTCNVS QLSTCOMR QLSTCOMS QLSTMSGR QLSTMSGS

QLSTROWR QLSTRBND QLSTROWS QLSTSQLR QLSTSQLS QLSTTRNR

QLSTTRNS

Thanks to Warren E. Waid, JC Penny, USA.
Change 10.209 Variables A17FLOC and A17FNAM were not in the KEEP= list

VMAC110 for the CICFCR statistics dataset.

Oct 19, 1992

Thanks to Don Deese, (CPExpert), Computer Management Sciences, USA.

Change 10.209A New variable PCTRDYWT was not in the KEEP= list for the

VMAC7072 TYPE70 dataset.

Oct 19, 1992

Thanks to Tom Elbert, John Alden Life Ins, USA.

==Changes thru 10.208 are included in Oct 18, 1992 MXG PreRelease 10.2==

Change 10.208 Something is wrong with this archaic member, for it now

VMXGVTOC has "UNINITIALIZED VARIABLE" messages that I could not

Oct 18, 1992 resolve in time for building this tape, but since MXG

strongly recommends the use of ASMVTOC/VMXGVTOF instead

of this old technology, I hoped this warning is enough!

Change 10.207 All of the MACRO _Txxxyyy definitions should have started

VMAC102 with DATA _Vxxxyyy but the "DATA" was missing. The JCL

Oct 18, 1992 example showing how to use the _Txxxyyy macros will now

execute correctly!

Thanks to Merlin Beeching, Nuclear Electric, ENGLAND.
Change 10.206 WEEKBLD and MONTHBLD were updated so that all of the PDB

WEEKBLD datasets created by the JCLPDB6 example are copied into

MONTHBLD your WEEKly and/or MONTHly PDB libraries. Note that it

Oct 18, 1992 is definitely NOT my recommendation that you build all of

these datasets monthly:

I do recommend that you create all of the WEEKBLD

datasets in your WEEKly PDB, but only build MONTHly the

PDB datasets that you need for monthly reports; often

only the PDB.JOBS, PDB.STEPS, PDB.PRINT and

PDB.RMFINTRV datasets are needed to feed monthly

billing validation. This is especially true if you

have implemented the TREND database and have weaned

your management from monthly to WEEKLY trending (as

exemplified by the MXG report examples in Chapter 42 of

the 1984 MXG Guide!).

However, so you don't have to rummage around in BUILDPDB

or ASUM members to find the MXG Sort Order, they've all

been added so you can comment out the datasets you don't

want created. That's safer and easier for both of us!
The BUILDPDB-created PDB datasets that were added were

PDB.TYPE72MN, PDB.NJEPURGE, PDB.TYPETMNT, & PDB.TYPE0203,

and the ASUM.... PDB Summary datasets PDB.CICS,

PDB.ASUMDB2A, PDB.JOBSKED, PDB.ASUM70PR, and PDB.TAPEMNTS,

which are built by their corresponding ASUM.... member

ASUMCICS, ASUMDB2A, ASUMJOBS, ASUM70PR, ASUMTMNT, have

also been added. Do check your USERID.SOURCLIB for an

EXPDBWEK member you might have added to do some of this

yourself, and avoid duplication!
If you do use MONTHBLD, make sure you use the JCL example

in JCLMNTH instead of the earlier JCL still in JCLMONTH.

JCLMNTH needs only one tape drive to create your monthly

PDB from your dailies and weeklies, and runs much faster.

It does require more temporary DASD space than the old

example, but the saving in tape drives AND tape mounts

is substantial with JCLMNTH. Everyone who has tried it

has kept on using it in production.

Change 10.205 IMS log variable NMSGPROC, IMSTRAN is wrong, but only in

TYPEIMSA MULTRANS='Y' observations, where it should have been set

Oct 17, 1992 back to 1, since a total of NMSGPROC observations will be

created by the MERGE logic. Insert NMSGPROC=1; after the

MULTRANS='Y'; statement to correct the value. Users report

correct response times and faster run times with the IMS

"Appended" Log processing, and it is so much better that

MXG sites MUST use ASMIMSLG/JCLIMSLG/TYPEIMSA instead of

the old TYPEIMS member for IMS log processing.

Thanks to Lonnie T. Rimmer, Philip Morris, USA.

Change 10.204 IBM Changes to OPC records cause INVALID RECORD messages.

IMACOPC There appear to be two different versions of records from

VMACOPC OPC, but IBM did not update the Record Version Number in

Oct 17, 1992 the record, so there is a new _OPCVER macro in IMACOPC to

tell which version to expect. I don't know right now what

OPC version is which, but there are only two choices, a 0

for the old and a 1 for the new format. Try one, and if

it doesn't work, try the other. This text will be revised

when I know more, but the software has been tested with

data from both versions. The changes were the addition of

MT0JVT $16 after MT0OCC, MTDOPTS2 $1 after MTDOPTS, and

+2 after MTDDIATM (but only for MTDTYPE=9), and SPLITLEN

was changed from 71 to 36. One MXG error was found. The

test IF 8 LE MT0TYPE LE 9 should have tested MTDTYPE!

This site also discovered that the records in the EQQTROUT

file with record type of 01, 02, or 03 appear to be copies

of the Current Plan, but have not yet found description

of the format, nor an acknowledgement of the discovery!

Thanks to Brenda Rabinowitz, Prudential Securities, USA.
Change 10.203 Early 10.2 support for Candle's Omegamon II for VTAM V150

VMACOMVT failed with real data records; I gambled and lost when I

Oct 13, 1992 sent a few sites an Early 10.2 before the test data from

Candle finally arrived. The support has now been tested

and the real 10.2 (this one) does support that product.

However, as with all new product support, use with caution

and validate your own data values.
Change 10.202 A blank line in the Early 10.2 choked the ASSEMBLER that

ASMVTOC is fixed in this 10.2. However, ASMVTOC may not work with

ASMVTOCO MVS/ESA 3.1.3; Matt found it executed instantaneously and

Oct 13, 1992 wrote no records on his 3.1.3 system while it worked find

Oct 17, 1992 on his 4.2 system. Apparently the ESA 4.2 enhancement in

10.1 is the culprit, but since the MXG 9.9 version has no

problem with MVS/370 thru MVS/ESA 4.1, I have put the old

MXG 9.9 version of ASMVTOC in member ASMVTOCO for you old

timers!

Thanks to Matt Gallion, Tenneco, USA.

Change 10.201 Boole & Babbage CMF under MVS/ESA 4.2 contains incorrect

VMAC78 triplet R783CPDN in type 78 subtype 3 record, causing MXG

Oct 16, 1992 to create zero observations in the TYPE78CF dataset.

Field R783CPDN (MXG variable NRCPDS), the number of I/O

queueing data sections, is 4 but there are 8 sections in

the record! The length of SMF78DCS (MXG variable LENDCS)

does include those extra 4 sections, so while I believe

CMF should be fixed, it turns out that by a simple change

in MXG "SKIP" logic (the logic to protect for any future

data which might be added, and which had been "faked out"

by the incorrect value), MXG can support this CMF record

and simultaneously protect both CMF and RMF for this new

way of adding unused data segments to type 78 records!
(To Boole's credit, they looked at MXG logic, as they are

also an MXG customer, diagnosed the source of the zero

observations, and gave the MXG site an MXG circumvention

that is part of this change, even before they called me!)

Find the following lines in VMAC78 (note EXCLUDEed lines):
OFFCPDS PIB4.

LENCPDS PIB2.

NRCPDS PIB2.

@;

SKIP=LENDCS-(12+NRCPDS*LENCPDS);

IF SKIP GT 0 THEN INPUT +SKIP @;

DO _II_ =1 TO NRCPDS;

- - - - 39 line(s) not displayed -

END; /* END DO TO NRCPDS */

END; /* END DO TO NRDCSLCU */

and make it look like the following by move and insert:

OFFCPDS PIB4.

LENCPDS PIB2.

NRCPDS PIB2.

2nd: @;

these new lines ==> SKIP=OFFCPDS-12;

were changed ==> IF SKIP GT 0 THEN INPUT +SKIP @;

after copy DO _II_ =1 TO NRCPDS;

- - 39 line(s) not displayed - -

1st: END; /* END DO TO NRCPDS */

these old lines ==> SKIP=LENDCS-(12+NRCPDS*LENCPDS);

were copied ==> IF SKIP GT 0 THEN INPUT +SKIP @;

from above END; /* END DO TO NRDCSLCU */

Boole & Babbage now have PTFs BPM4428/BPM4428 to correct

the original error.

Thanks to Norvell Reeves, Boole & Babbage, USA.
Change 10.200 Legent's MIM product causes the MXG Tape Mount Monitor to

ADOCTMNT write a record with non-zero return code when MIM replies

TYPETMNT "WAIT" or "NOHOLD" to some allocation recovery events.

VMACTMNT

Oct 17, 1992 YOU MUST USE ONLY THE OBSERVATIONS WITH TMNTRTRN=0

TO COUNT AS TAPE MOUNTS IN A MIM ENVIRONMENT, OR AT

LEAST DISCARD MOUNTS WITH TAPMNTTM LESS THAN 5 SECONDS.
MIM manages tape drives across systems by "Plugging"

values into the UCB, and by propagating UCB status bit

values to all systems. MIM "allocates" all drives and

then doles them out to your jobs as needed. One of the

bits plugged by MIM is the Mount Pending, or MTP, bit. For

every allocation recovery scan event (each time a drive is

deallocated while jobs are in allocation recovery), MIM

intercepts messages and replies WAIT,NOHOLD for each job

that didn't get that device, and sends new UCB status bits

for that device to all sharing systems. MXGTMNT sees the

MTP bit change on these other systems, thinks a mount

event was seen and missed, and writes an SMF record,

setting a non-zero Return Code value in TMNTRTRN

(accidentally, a 1 for NOHOLD, a 2 for WAIT) for these

non-mount mount events.
Change 10.226 attempts to recognize these MIM non-mount

events (the UCBASID to zero and the UCB Allocated Bit is

On), and sets TMNTRTRN=3 for them, but that change has NOT

been validated, and one non-MIM site saw valid mounts with

TMNTRTRN=3, so you must verify. Since the minimum mount

time for a real tape mount is 5 seconds, I suggest that

you discard any TYPETMNT mount record with TAPMNTTM LT 5.

Further investigation is planned, and hopefully these MIM

pseudo-mount events can be explicitly identified.

As a result of this investigation, I have finally written

the long overdue documentation of the MXGTMNT monitor and

the datasets created from its SMF records, in the member

ADOCTMNT. Please review it for complete information.

Thanks to Ted Anderson, Kaiser Permanente, USA.

=Changes thru 10.199 were included in MXG PreRelease 10.2, Oct 12, 1992=

Change 10.199 MXG Installation instructions have been revised and are

INSTALL now contained in member INSTALL. JCL to allocate the MXG

JCLINSTL libraries (two source PDS, a SAS data library of FORMATS)

Oct 11, 1992 is contained in JCLINSTL. The references to SAS 5.18 have

been removed, and the philosophy of installation slightly

changed, as described in INSTALL and above in this member.

This is work still in progress, as the rewriting of the

MXG documentation begins in ernest!
Change 10.198 Execution under SAS 5.18 required several changes.

DIFFDB2 Although MXG Strongly recommends execution under SAS 6.07,

VMACOPC for those of you still struggling with Version 5 (you are

VMACAIM6 either still running MVS/370 or are you think you are too

VMACQAPM swamped to take a half-day to install SAS 6.07), MXG still

Oct 11, 1992 executes under SAS 5.18! Only TYPEQAPM (AS400 support)

is known to fail under 5.18 (it uses 6.07-only formats).

a.VMACOPC and VMACAIM6 were written using IN (1,2) logic,

but that syntax was not a part of 5.18, so the IN (,)

logic was replaced with OR logic.

b.DIFFDB2 initially failed under SAS 5.18 because its parser

failed on PROC SORT NODUP DATA=_LDB2ST0 %VMXGFOR; syntax!

Moving the %VMXGFOR to after the NODUP allowed 5.18 to

successfully execute. (This is really strange, because

there are numerous other PROC SORT statements with very

similar structure that did not fail!)

Change 10.197 Variable DEVCLASS has been added to TYPE74 so reports

VMAC74 for DASD (DEVCLASS=20X) or for TAPE (DEVCLASS=80X) can be

Oct 7, 1992 generated without a list of all devices in a class.
Change 10.196 TMS datasets have been enhanced to provide both capacity

TYPETMS5 measures and billing measures for tapes & tape data sets.

VMACTMS5 Dataset TMS contains one observation for each tape volume

Oct 7, 1992 with the count of files on that tape and the TAPEFEET for

that volume, and contains the DSNAME of only the first

data set on that tape volume. TMS is thus useful for the

capacity measurement of your tape library. The major part

of this change was to enhance dataset DSNBRECD so that it

now contains one observation for each tape data set with

the attributes and correct TAPEFEET for that dataset.

(Previously, DSNBRECD contained observations for only the

second and subsequent data sets on tape - the first data

set information was in TMS. Now, the data set information

from the first (and maybe only) data set in TMS has been

added to DSNBRECD so ALL of your tape data sets can be

billed directly from DSNBRECD.

Thanks to Chuck Hopf, Primerica, USA.
Change 10.195 Accounting summary report now has DDF headings suppressed

ANALDB2R if there is no Distributed data, and null values for one

Oct 7, 1992 of the SORTBY variables now prints "BLANK" vice a blank.

The owning and wanting plan were reversed in the Lock

Suspension Trace, and that report is now named the Lock

Contention Trace.

Change 10.194 Support for OMEGAMON II FOR VTAM V150 user SMF record.

EXOMVEXC Seven datasets are created from the record's subtypes:

EXOMVTBU OMVTEXCE - Exception Events

EXOMVTCT OMVTTBUF - Trend Interval Buffers

EXOMVTET OMVTTCTC - Trend Interval CTCs

EXOMVTLC OMVTTETE - Trend Interval End-to-End Response

EXOMVTNC OMVTTLCL - Trend Interval Local Controllers

EXOMVTVR OMVTTNCP - Trend Interval NCP

IMACOMVT OMVTTVRF - Trend Interval VRs

TYPEOMVT Code has been syntax checked, but no test records were

VMACOMVT provided by Candle as yet for validation.

Oct 7, 1992

Change 10.193 STC 4400 SILO HSC (subtype 7) SMF record variables have

VMACSTC been FORMATed, and some $CHAR1. variables were changed to

Oct 6, 1992 PIB1. numeric variables. New variables STC07FPS/STC07TPX

are created and contain the volume in the same format as

the MVS System (LSM ID, Panel, Row, Column display as

000:00:00:00.) Specifics:

- Variables changed from $CHAR1. to PIB1. in their INPUT

statement, and given format Z2. are these:

STC07SAC STC07SPN STC07SRO STC07SCO

STC07TAC STC07TPN STC07TRO STC07TCO

- Variables changed from $CHAR1. to PIB1. in their INPUT

statement, and given format Z3. are these:

STC07SLS STC07TLS

- Variables added to format statement as shown:

STC07FPS STC07TPS $12.

STC07TYP STC07RQS STC07FLG $HEX2.

STC07DRS STC07DRT HEX4.

- New variables created:

STC07FPS=PUT(STC07SLS,Z3.)!!':'!!PUT(STC07SPN,Z2.)!!

':'!!PUT(STC07SRO,Z2.)!!':'!!PUT(STC07SCO,Z2.);

STC07TPS=PUT(STC07TLS,Z3.)!!':'!!PUT(STC07TPN,Z2.)!!

':'!!PUT(STC07TRO,Z2.)!!':'!!PUT(STC07TCO,Z2.);

Thanks to Lou Sassani, National Australia Bank, AUSTRALIA.
Change 10.192 Variables SYSTEM SMFTIME weren't kept in dataset ROSCOSOR

VMACROSC ROSCOPUR,ROSCOHEX,ROSCOCON,ROSCOATT,ROSCOALL,ROSCOSHU,

Oct 6, 1992 ROSCOVPE, and ROSCODSR, but now they are.

Thanks to Willie Antman, Federal Deposit Insurance Corp., USA.

Change 10.191 "Appended" IMS Log processing was enhanced with new logic

ASMIMSLG to test for and locate the RACF segment in the IMS 01/03

Oct 6, 1992 record. Before this change, it was possible that the RACF

variables would have had wrong values.

Thanks to Engelbert Smets, Provinzia Versicherungsanstalten, GERMANY.

Rheinprovinz.

Thanks to Jeffrey S. Crum, Ashland Oil, USA.
Change 10.190 JES2 errors (APAR OY56235) create truncated timestamp

BUILDPDB values for TYPE26 variables JSTRTIME and JENDTIME. These

BUILDPD3 values are compared with TYPE30_5 variable JINITIME in the

IMACTIME BUILDPDB/BUILDPD3 logic to decide whether to SPIN or not.

Oct 6, 1992 Since IBM has not yet fixed their truncation problem, the

macro _TIMEDIF defined in IMACTIME previously used only in

JES3 BUILDPD3 has been added to JES2 BUILDPDB so that the

decision can be externalized without modification to the

BUILDPDB member. The default value for _TIMEDIF is zero,

but if you experience problems (i.e., your SPIN library

fills because of the JES2 error, and few jobs are put in

PDB.JOBS), you should change the default to 10 seconds,

as described in the comments in IMACTIME. The new logic

to decide to SPIN or not to SPIN using _TIMEDIF is now:

IF IN26 AND IN30_5 AND

(JSTRTIME-_TIMEDIF) LE JINITIME LE (JENDTIME+_TIMEDIF)

THEN OKJOB=1;

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

Change 10.189 Variables TOTMEMR and OTH0MEMR were accidentally left out

RMFINTRV of the FORMAT statement for the other ....MEMR variables

TRNDRMFI in RMFINTRV. In the INCODE= logic in TRNDRMFI, compiler

Oct 6, 1992 "faker" statements (IF OTH0xxxx=. THEN OTH0xxxx=.;) for

OTH6-OTH0 variables were deleted. They were added to avoid

the UNINITIALIZED VARIABLE message between MXG 6.6 and MXG

7.7 (when these new variables were added), but now only

caused confusion as to why they were there!

Thanks to Tom Elbert, John Alden Life, USA.
Change 10.188 Change 10.020 correctly circumvented LENGTH problem in

EXITMONI Landmark records, but the actual cause of the zero value

Sep 28, 1992 is corrected by changing the line reading

MVC 0(2,R1),=H'0' RECORD LENGTH IS MEANINGLESS

to read

MVC 0(2,R1),F$NXTLNG+2

Thanks to Trevor Holland, Bank of Melbourne, AUSTRALIA.
Change 10.187 Change 10.110 mislocated an INFILE & FORMAT statement in

VMACQAPM the new X.25 section, which surfaced as "SYSTEM ABEND 0C4

Sep 28, 1992 OCCURRED OUTSIDE OF THE SAS ENVIRONMENT" on the SAS log.
Change 10.186 Support for XEROX printer SFS "Status File System" data.

ADOCSMS XEROX Printers have always created data records on print

EXTYSFS workstations, but now that data is somewhat more usable,

IMACSFS because you can now capture the MVS JOB and JESNR fields.

VMACSFS This will require your XEROX person to make some changes

TYPESFS to the XEROX software driving the printer, as described

Sep 28, 1992 in member ADOCSFS.

Then, getting the SFS data records from the XEROX printer

to the mainframe may require floppy disk or non-labeled

tapes or communications packages, depending on the

configuration of a particular printer.

You typically cannot use PDB.PRINT for XEROX printer

cost recovery, because JES counts in the TYPE6 record

only what JES sent to the printer, not what was

actually printed; JES may send only one copy, but the

printer can print 100 copies, and only the SFS

Accounting record will tell you what was really

printed. Now it can tell by whom, too!

The ability to process the TYPESFS dataset and merge it

with your PDB.JOBS dataset to pick up accounting data now

makes the XEROX SFS data worth generating and transporting

over to MVS for XEROX printer workstation accounting.

Unfortunately, XEROX does not yet include the data

needed for accurate printer throughput analysis (see

ANALPRTR) and there is still no way to get the MVS

accounting fields put in the SFS data records.

Thanks to Chuck Hopf, Primerica, USA.
Change 10.185 Change 10.060 was not completely correct. If the first of

VMACTMS5 two DSNBs was inactive, the statement IF DSNBACTV='Y';

Sep 24, 1992 that was added by 10.060 caused the next DSNB to be lost!

That statement must be deleted. The statement

IF VOLSER GE 'A' THEN OUTPUT DSNBREC;

must be changed to read

IF VOLSER GE 'A' AND DSNBACTV='Y' THEN OUTPUT DSNBREC;

so only the active DSNBs are output.

Thanks to Norbert Korsche, OMV-AG, AUSTRIA.
Change 10.184 Support for IBM's TCP/IP Version 2 Release 2 SMF records.

ADOCTCP The Telnet Server writes a record for each Logon or Logoff

EXTYTCP event; a different SMF record number can be assigned for

IMACTCP each event, but only one record number for both events is

TYPETCP needed/recommended, as MXG will create one observation in

VMACTCP dataset TYPETCPT for each event record which identifies

Sep 24, 1992 which event. The FTP Server writes a record for each

APPEND/DELETE-MDELETE/LOGIN fail/RENAME/GET-MGET/PUT-MPUT

event; like the Telnet Server, a different record number

can be assigned for each event, but only one record number

for all FTP events is needed/recommended, as MXG will

create one observation in dataset TYPETCPF for each event

record which identifies which FTP event. These records

and their installation is described in TCP/IP V2 R2

Planning and Customization, SC31-6085-01.

Thanks to Fred Toro, Lever Bros. Co, USA.

Thanks to Kurt Karlsen, NIT, NORWAY.

Thanks to Oystein J. Blix, Etrinell.