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

FIRST.VMDUSER OR FIRST.VMDCPUAD) THEN OUTPUT;"

until HFQUCT can be corrected by IBM.

Perhaps someday, IBM will provide the long-requested

flag in the user sample record so the time from logon

to end of interval can be captured safely.

-An unrelated change was made to better format the notes

MXG writes to the log when operator commands are found.

Additionally, the command variable CALCMD is now length

200 in all kept data sets.

Thanks to Procter & Gamble, BELGIUM.
Change 08.200 IMS Log type 35x with ENQFLAG=0Cx and FLAG2=40x is now

VMACIMS output in the IMS35P record. This is the last reported

Dec 16, 1990 record subtype that was not output in TYPEIMS processing.

Thanks to Magnus Jansson, DAFA Stockholm, SWEDEN.

Change 08.199 SAS 6.06 Circumvention discussed in Changes 8.078 and

ANALDB2R 8.059 were not propagated into all reports in ANALDB2R.

TESTANAL The default set of ANALDB2R reports were changed, but in

Dec 16, 1990 lines 028780 and 45960 the commas after AUTHCHG UTILITY

and OUTCODE=DROP DATETIME; must be removed. The fourteen

occurrences of " .T102" must be changed to " . T102", and

two " .DB2" must be changed to " . DB2". MXG testing of

%ANALDB2R by member TESTANAL was corrected to now invoke

and test all 27 of the DB2 reports.

Thanks to Susan Marshall, SAS Institute Europe, GERMANY.

Change 08.198 ACF2 variable ACLFLDVB could raise "Invalid Data" note.

VMACACF2 Line 052900 (the only occurrence of PK4.) should end with

Dec 7, 1990 "ACLFLDVB ?? PD4. @;" instead of "ACLFLDVB PK4. @;"

Thanks to Rachel Bromage, L.O.L.A., ENGLAND.

Change 08.197 Unused.
Change 08.196 Unused.
Change 08.195 Change 8.056 had not been installed in PreReleases. Lines

VMACSYNC 023800 and 024800 should now read SIRFM ?? 1. and

Dec 4, 1990 SORFM ?? 1. respectively.

Thanks to Bob Rutledge, Sherwin Williams Paint, USA.

Change 08.194 Validation of the STC Silo HSC 1.1.0 SMF Record uncovered

VMACSTC an MXG coding error that caused STOPOVER. Line 034600

Dec 3, 1990 should input STC07TNM PIB1. (instead of PIB4.).

Thanks to Leslie Dixon, Santa Fe Energy Resources, USA.

Change 08.193 VMXGVTOF is a modification of VMXGVTOC that will read the

VMXGVTOF output of ASMVTOC (the "Fast VTOC Reading program") and

Dec 3, 1990 will create the same datasets (VTOCLIST,VTOCMAP,VTOCINFO)

that were created by the slower VMXGVTOR/VMXGVTOC pair.

Note that VMXGVTOF replaced the (temorary) MPXGVTOC that

was introduced in Change 8.117.

Thanks to Jeff Fox, SKF, USA.
Change 08.192 Reserved Change Number.

Dec 2, 1990

Change 08.191 This contributed member estimates processor storage

ANALSTOR requirements based on techniques taught by IBM's

Nov 29, 1990 "MVS/ESA Subsystem Analysis: Processor Storage

Estimation" seminar taught by the South Western

Area Systems Center. The two step process suggested

first measures current usage based on RMF type 71 and

type 79 ASD records and second estimates the real and

expanded storage needed for zero paging (or very close

paging) taking under consideration future workload

growths. This analysis program accomplishes only the

first step, and provides a program to report the

current usage based on this IBM methodology.

Thanks to Miller Dixon, Continuum, USA.
Change 08.190A The original author of the support for Arbiter SMF

EXARB404 records (from Tangram product) has updated the code

EXARBC01 to support changes in Version 2.1.1 of that product.

EXARBC02 Three new data sets are created.

IMACARB

VMACARB

Nov 29, 1990

Thanks to J-P Tonnieau, GMF System Team SARAN, FRANCE.

Change 08.190 VMXGVTOC produces a single "error" message,

VMXGVTOC POINT=1 NOBS=0 POINTER=. VOLSER= DSNAME= ...

Nov 28, 1990 that has no real effect, that will disappear if you move

the SET statement (line 063700) to after the STOP

statement (line 063800).

Thanks to Magnus Jansson, DAFA Stockholm, SWEDEN.

Change 08.189 The POINT= operand of the SET statement cannot be used

ASUMCICS for a dataset on tape under SAS 6.06. We used it under

Nov 27, 1990 5.18, but it turns out that 5.18 documentation said that

it couldn't be used for tape! POINT= and NOBS= were used

to determine transparently which CICS dataset (CICSTRAN

or MONITASK or both) was to be summarized. The logic has

been redesigned to make the same determination without

the POINT= operand, so tape datasets can be used.

Thanks to Bob Grant, Gold Bond, USA.
Change 08.188 The final RETURN; statement was after the END; statement,

VMACHSM which caused no problem as long as HSM SMF record was

Nov 27, 1990 processed by itself; adding VMACHSM to BUILDPDB caused

subsequent data sets to be not output! The RETURN; is

now moved inside the END; statement.

Thanks to Chuck Hopf, Hopf Consulting, USA.

Change 08.187 Hitachi processors using MLPF (their PR/SM or MDF) can

VMAC7072 mix dedicated and shared processors in the same LPAR,

Nov 27, 1990 but MXG did not protect for that possibility and the

CPUWAITM in the TYPE70 was incorrect (but the individual

CPUWAITn variables were correct). This change expanded

the logic for Dedicated processors to re-calculate the

CPUWAIT variable across both dedicated and shared CPUs.

Thanks to Matthew Bakulich, Crowley Maritime, USA.

=========Changes thru 8.186 were printed in Newsleter EIGHTEEN==========
Change 08.186 PreReleases 8.2 thru 8.5, JES 3 BUILDPDB, line 044500

BUILDPD3 added variables JINLTIME and JSRTTIME to the LENGTH

Nov 16, 1990 statement but left out the "8" before the semicolon.

Thanks to Phil Waters, Arthur Andersen, Bristol, ENGLAND.

Change 08.185 PreRelease 8.3 thru 8.5 had an extra debugging statement

VMACDB2 "IF QWHSTYP GT 2 THEN PUT QWHSTYP= Z=;" after the @; in

Nov 16, 1990 line 165000 which should have been removed. Other than

possibly filling your log, there was no real problem.

Thanks to Ron Allison, UDSI, USA.
Change 08.184 PreRelease 8.5 could fail with a STOPOVER due to SMF

VMAC57 type 57 (only with MVS 4.1) because of typographical

Nov 15, 1990 errors in Change 8.167. Line 009700 should be

IF LEN GE 116 THEN instead of GE 16 and line 009800

should be INPUT @101+OFFSMF instead of @100.

Thanks to Bob Malitz, United Parcel Service, USA.

Change 08.183 PreRelease 8.5 needed minor tuning of Landmark TMON/CICS

TYPEMON8 Version 8 support. The division by TCINPRCN for long

Nov 15, 1990 running mirrors needed zero-divide protection.
Change 08.182 The CICS 3.1+ Statistics records are now combined into

BUILDPDB _CICNTRV.CICINTRV by new member CICINTRV which is now

BUILDPD3 automatically included in BUILDPDB/3 and TYPE110. The

CICINTRV CICINTRV data set merges the interval "INT" records from

IMACCICS statistic data sets, and the original CIC..... datasets

TYPE110 remain in the work file. CICINTRV is a major enhancement

Nov 14, 1990 for CICS 3.1 analysis, and logically is a replacement for

the non-existent CICSYSTM. Note that if no "INT" records

exist (which would happen if only "EOD" was requested),

there will be no observations in CICINTRV. These nineteen

CICS Statistics datasets are merged together to create

the CICINTRV interval statistics dataset:

CICAUTO CICDMG CICDQG CICDQT CICDS CICDTB

CICFCT CICLDG CICM CICSDG CICSMDSA CICST

CICTC CICTCT CICTDG CICTM CICTSQ CICTST

CICVT
Change 08.181 Boole & Babbage IMF product record for IMS chained

TYPECIMS transactions contain the ARRVTIME of the original

Nov 14, 1990 transaction in the subsequent records, causing the input

queue time to be too long. This contributed fix adds the

logic to sort and reprocess the IMS.TRANSACT datasetand

resets ARRVTIME to the ending time of the preceding

transaction in each chain.

Thanks to David Daner, Sun Refining and Marketing, USA.
Change 08.180 IMS Response Mode Transactions are now identifiable

VMAC110 with new variable RSPMODTR added to IMSTRAN dataset.

Nov 14, 1990

Thanks to ???, CED BORSA, ITALY.

Change 08.179 CICS Type 110 variables DSAHWMK, PROGCOMP, PROGSTOR,

VMAC110 STORHWMK, and STORHWMH all measure bytes, but their

Nov 14, 1990 units ranged from bytes, to doublewords to pages. Now,

all are converted to bytes and formatted with MGBYTES

format for consistency and clarity. (MGBYTES prints

100K, 200M, etc, scaling bytes to the appropriate range.)

Thanks to Elisabeth Jensen, Aetna Life and Casualty, USA.
Change 08.178 IMS Log processing algorithms enhanced in MXG 8.3 arenow

VMACIMS corrected for two conditions that had occasionally caused

Nov 11, 1990 INPQUETM and RESPNSTM to be appreciably wrong. The first

change affected 21 transactions, the second affected 134

transactions, out of a total of 368,000 transactions!

1.IMS Log 35x records with ENQFLAG=0Cx and FLAG2=0Cx did

not decode correctly, which caused RESPNSTM to be very

large in a very small number of transactions.

Near line 070600, after line

IF FLAG2='...1.....'B THEN LOC=LOC+2;

insert the following new line:

ELSE IF FLAG2='00001100'B THEN LOC=LOC+4;

This has been validated only for IMS 2.2, but it should

apply also for both 2.1 and 3.1. One of the big logic

problems in MXG support of the IMS log is the decoding of

the 35x records. IBM does not describe all of the bit

values for ENQFLAG, and each combination of ENQFLAG/FLAG2

must be experimentally determined to be an input, output,

message, or program-to-program enqueue event. MXG notes

on the log "LCODE 35X NOT OUTPUT ENQFLAG= FLAG2=" when

unknown values are found, and deletes the record. Values

of 0C/40, 2F/80, 2F/88 have been reported and are thought

to be output enqueue (and hence non-critical to delete).

It appears that FLAG2 must contain the '04'x bit on for

the enqueue to be for input.

2.The logic added in PreRelease 8.3 to reset ARRVTIME when

it was missing was correct and did correct problems by

sorting correctly. Out-of-time-sequence 01/03x records

were also reset by the 8.3 change, and seemed to work for

many transactions, but when the transaction's 35x record

was also out of time sequence, the change overcorrected,

and the INPQUETM and ENQTIME were wrong.

Near line 025600, change the test which read

IF ARRVTIME=. or ARRVTIME LT LASTTIME THEN ARRVTIME=....

to now read

IF ARRVTIME=. THEN ARRVTIME=LASTTIME-.001;

Thanks to J. Cary Jones, Philip Morris, USA.

Thanks to T. H. Witt, Oscar Mayer Food Corp, USA.

Thanks to Magnus Jansson, DAFA Data AB, SWEDEN.
Change 08.177 -CICS/ESA 3.1 transactions accessing DL/I databases with

IMACICDB DBCTL can contain (optionally) a 256-byte segment with

IMACICDL clocks and counters for the CICS-caused DL/I activity.

IMACICUS (DL/I counters from the IMACICDL member can also exist,

UTILCICS but contain DL/I counts only for Local DL/I). Enabling

VMAC110 the DBCTL data is described in the Customization Guide.

Nov 11, 1990 Previously, the transaction record consisted of a static

segment, the optional local DL/I segment, the optional

user counters/clocks, and then ended with the optional

user character field. Since the character field (often

used for application data, account number, etc.) was at

the end of the transaction record, MXG simply read the

rest of the record into USRSTRNG, and then truncated the

data into the kept variable USERCHAR, whose length you

specified with the LENGTH statement in member IMACCICS.

With the restructured CICS 3.1 record, however, you must

now also set the variable USRCHRLN in IMACICUS to tell

MXG how many bytes of character data is to be read into

USRSTRNG so that the DBCTL data can be read; the order in

CICS 3.1 is static, Local DLI, User clocks/counters, user

character string, and DBCTL segment, when the new EMP is

added after your existing MCT calls.

The new IMACICDB member decodes the DBCTL fields when

you remove the comment block (just like IMACICDL did for

local DL/I). The actual DBCTL segment is 256 bytes, but

only 158 bytes are currently used by IBM, and they create

these 34 new variables (only if IMACICDB is changed);

STATBFWT='WAITS FOR*DEDB*BUFFERS'

STATDATN='SCHEDULE*COMPLETED*TIMESTAMP'

STATDATS='SCHEDULE*STARTED*TIMESTAMP'

STATDBIO='DATABASE*I/O-S'

STATDECL='DEDB*CALLS'

STATDERD='DEDB*READ*OPERATIONS'

STATDLET='DATA BASE*DELETES*ISSUED'

STATEXDQ='EXCLUSIVE*DEQUEUES'

STATEXEQ='EXCLUSIVE*ENQUEUES'

STATGHN ='DATA BASE*GHN CALLS*ISSUED'

STATGHNP='DATA BASE*GHNP CALLS*ISSUED'

STATGHU ='DATA BASE*GHU CALLS*ISSUED'

STATGN ='DATA BASE*GNP CALLS*ISSUED'

STATGNP ='DATA BASE*GNP CALLS*ISSUED'

STATGU ='DATA BASE*GU CALLS*ISSUED'

STATINTC='WAIT TIME*INTENT*CONFLICT'

STATISRT='DATA BASE*INSERTS*ISSUED'

STATMSCL='RESERVED*FOR*FAST PATH'

STATNPSB='PSB*NAME'

STATOVFN='OVERFLOW*BUFFERS*USED'

STATPOOL='WAIT TIME*FOR POOL*SPACE'

STATREPL='DATA BASE*REPLACES*ISSUED'

STATSCHT='SCHEDULE*PROCESSING*DURATION'

STATTENQ='TEST*ENQUEUES'

STATTLOC='PI*LOCKING*DURATION'

STATTMIO='DATABASE*I/O*DURATION'

STATTOTC='TOTAL*DL/I*CALLS'

STATTSDQ='TEST*DEQUEUES'

STATUENQ='UPDATE*ENQUES'

STATUOWC='UNIT-OF-WORK*CONTENTIONS'

STATUPDQ='UPDATE*DEQUES'

STATWEXQ='WAITS ON*EXCLUSIVE*ENQUEUES'

STATWTEQ='WAITS ON*TEST*ENQUEUES'

STATWUEQ='WAITS ON*UPDATES AND*ENQUEUES'

-Unrelated, but discovered in this phase of testing, the

%VMXGFOR macro references inside old style macros, in the

UTILCICS dictionary-reading utility were corrected to now

contain double percent signs and titles were clarified.

Thanks to Hamid Tavakolian, Continuum, USA.

Change 08.176 IMS 3.1 DBCTL Thread Type transactions have zero for the

TYPEIMS value for NMSGPROC, causing them to be lost. There were

VMACIMS two errors in MXG logic. First, the setting of PROGTYPE

Nov 9, 1990 from PTYPE values 3, 4, and 5 (for D, Q, and R), near

line 038500 in VMACIMS should have been 4, 8, and 128.

Second, the tests in TYPEIMS for PROGTYPE='B' near line

024400 and 038700 are expanded to protect for DBCTL:

IF PROGTYPE='B' OR PROGTYPE='D' NMSGPROC EQ 0 THEN DO;

Thanks to Hamid Tavakolian, Continuum, USA.
Change 08.175 Landmark's TMON/MVS release 1.11 was supposed to become

EXTMVTR release 1.12, but it is now in managed availability as

EXTMVTRS release 1.1, with two new data records and some changes.

EXTMVWK -In LMRKREC="SY" section, insert a line with +4 after

EXTMVWKP SYSMDL $CHAR2., change SYSTSO1P PIB4.2 to PIB4.4, and

IMACTMVS delete the line with +4 after SYSPDT is read in.

TYPETMVS -Logical data records can span physical blocks, and the

VMACTMVS spanning can split fields! Thus far, only the I/O data

Nov 9, 1990 records have been found to be spanned. For example, with

Nov 28, 1990 552 I/O devices, an interval's logical record contains

41,400 bytes of data (plus headers), but is written in

three blocks of 13844 bytes each. Part of a field is at

the end of the first block, with the rest of that field

continued in the 33rd byte of the second block! There is

only one way to handle these non-standard records that

can exceed 32760 bytes, and that requires the use of an

Infile Exit to the SAS System. Fortunately, the Infile

Exit named TMON that is supplied by MXG for compressed

Landmark CICS records has been modified to support either

compressed and/or spanned record processing! The member

EXITMONI, however, only works under SAS 5.18.

In Newsletter EIGHTEEN, I thought we would also change

the 6.06 exit, and added member EXITMON6 in preparation

for its modification, but it turns out that SAS 6.06

itself will need modifications before the infile exit

can be redesigned. Thus EXITMON6 only supports the

decompression of Landmark records under SAS 6.06; the

EXITMONI member does both decompression and unspanning

but only under SAS 5.18.

Follow the instructions in the EXITMONI member, build

the TMON exit, and then edit new member IMACTMVS to tell

MXG that you have installed the Infile exit. Note that

this modified TMON exit will process either TMON/MVS or

TMON/CICS records. If you have not installed the TMON

exit and MXG finds spanned TMON/MVS records, the bad data

record will now be deleted and so noted on the log; prior

to this change, TMON/MVS spanned records cause STOPOVER.

3.Four new datasets are built, two each from the TR and WK

records. TMVSTR contains the Tape Record statistics, and

TMVSTRS contains one observation for each tape drive in

a TR record. TMVSWK contains the "static" variables in

the WK record, and TMVSWKP contains one observation for

each period of each performance group in the WK record.

4.Further validation added JIJNAME to TMVSJIST, corrected

labels for IOELDNRP,PSMAXSU,PSMINSU, and changed the

INPUT for SYSWTIME from PIB8.6 to MSEC8.

Thanks to Bob Rutledge, Sherwin Williams Paint, USA.
Change 08.174 This change should be transparent. It permits MXG to be

VMACSMF used for SMF record processing either under CMS or OS

UTILGETM versions of SAS, by using a new %MACRO to set the values

Nov 9, 1990 of RECFM and LRECL differently when MXG is exeuted under

CMS SAS than when MXG is executed under MVS SAS.

(Previously, CMS users had to EDIT these changes.)

UTILGETM was also expanded for both environments to look

for additional subtypes in creating the SMFOUT file.

Under CMS, VBS records can only be read, not written, and

they cannot have LRECL greater than 32756. Furthermore,

RECFM=VB is not supported for output; only RECFM=V

records can be created (CMS SAS accepts RECFM=VB syntax

but actually creates RECFM=V records). With this change,

execution under CMS causes the _SMF macro used for SMF

input to specify RECFM=VBS,LRECL=32756, and the UTILGETM

output spec will be RECFM=V,LRECL=32756,BLKSIZE=32760.

Additionally, since the SAS JFCB= option of the INFILE

statement does not function under CMS, variable SMFJFCB

is now protected to eliminate the uninitialized variable

message when MXG is executed under CMS SAS for SMF data.

Under MVS, VBS records can have LRECL=32760 (and actual

records with 32760 LRECL are written by SMF!). Since the

MXG specification has been LRECL=32760, this change had

no logic change to _SMF or UTILGETM when MXG is executed

under MVS SAS.
Change 08.173 Preliminary support for Amdahl's MPT (MDF Performance

EXMPTDOM Tool) SMF record. This new tool replaces the existing

EXMPTEND TYPEMDF record with enhanced information. Existing names

EXMPTGLO of TYPEMDF variables were preserved when recognized, but

EXMPTSEL until the actual DSECT is provided by Amdahl, all names

IMACMPT are subject to change and should be used with caution.

TYPEMPT The four new datasets created from the MPT SMF records

VMACMPT (whose ID is set in IMACMPT) are MPTDOMAN, MPTGLOBL,

Nov 9, 1990 MPTSELCT, and MPTENDSL. This support has not been tested

with actual data records yet.

Change 08.172 SPIN library suddenly fills after installation of JES2

BUILDPDB maintenance (either migration to MVS/ESA or PUT 8908).

BUILDPD3 This change replaces the discussion (without a change)

Nov 9, 1990 on the MXG 8.5 PreRelease as Change 8.158.

1.The logic decision in BUILDPDB ("to SPIN or not to SPIN")

controls the contents of PDB.JOBS, PDB.STEPS, PDB.PRINT,

and the SPIN data library. BUILDPDB will output to the

PDB library or SPIN library based on these criteria:

a) Job has "spun" more times than your chosen value of

_SPINCNT (defined in IMACSPIN). Each time a job is not

output, its SPINCNT is incremented. If you set the

value of _SPINCNT in IMACSPIN to 0, BUILDPDB will then

always output to the PDB and will never output to the

SPIN library.

b) The job is complete. There are two possibilities:

i.) The job failed before execution (i.e., JCL error

or canceled before initiation). The JES2 JSTRTIME

(start of execution) will be missing, and only

type 26 (and possibly type 6) records exist for

the job.

ii.) The job is really complete, and all SMF records

have been read. This requires that both a type 26

and a type 30 subtype 5 record were found, AND the

timestamp in the subtype 5 (MVS execution ended)

is between JSRTIME to JENDTIME (the JES execution

start to end times). That timestamp test is needed

to ensure that the real execution type 30 record

was found. If the SMF type 30 timestamp doesn't

match the JES type 26 timestamp, all records on

the job are "SPUN" until the correct type 30

subtype 5 is found. (Restarted jobs create

multiple type 30 subtype 5s. With multiple MVS

systems, today's SMF file could contain the type

26 and a type 30 from the first execution, but the

real (final) type 30 record could be in an

un-dumped SMF file that will not be read until

tomorrow's BUILDPDB run.)
This logic is implemented in BUILDPDB by setting OKFLAG;

if OKFLAG is set to 1, the job is created in the PDB,

if OKFLAG is not set, the records are sent to the SPIN.
SPINCNT= MAX(SPIN26,SPIN6,SPIN30_5,SPIN30_4,SPIN30_1,0);

IF IN26 AND IN30_5 AND

JSTRTIME LE JTRMTIME LE JENDTIME THEN OKFLAG=1;

ELSE IF IN26 AND (JSTRTIME=. OR JENDTIME=.) THEN OKFLAG=1;

ELSE IF SPINCNT GE _SPINCNT THEN OKFLAG=1;
2.Several sites suddenly found their SPIN libraries filled

after migration from MVS/XA to MVS/ESA, or after applying

JES2 maintenance (somewhere between PUT 8902 and 8908).

There were PTFs which altered JES2 time stamps, and one

of the PTFs went PE (PTF in Error), and perhaps the site

did not correctly install all of the PTFs, but the actual

result of the maintenance was that the site's JES2 type

26 SMF record's JENDTIME variable (SMF26XPT, JCTEQOF, the

job ended time, also in the $HASP395 job ended message)

was now earlier than the MVS type 30 subtype 5 (the job

termination JTRMTIME variable (SMF 30TME) timestamp!!!

This has NEVER been true before, and the sites with the

problem saw the change occur precisely when they put on

the IBM maintenance. Not only did IBM JES2 Level 2 say

there was no problem, they also tried to say that there

is no correlation between the JES SMF26XPT execution end

and the MVS SMF30TME job termination time (which is the

timestamp when SVC83 moves the record into the SMF buffer

in the SMF address space)! But SMF30TME occurs while the

job is still in MVS initiation and JES2 can't end the

execution until after SVC83 has completed and until after

MVS terminates its initiator. At these sites, the actual

JENDTIME to JTRMTIME delta is hundreds of milliseconds,

and it plots uniformly across the entire day. Note also

that SVC83 does not write data to disk, but only moves an

SMF record into the SMF buffer; the actual VSAM write of

the CI containing that SMF record will occur much later,

under an asyncronous SRB in the SMF address space.

But even if I'm right and IBM's wrong, it doesn't matter.

IBM can't find their problem or fix their code nearly

as fast as you and I can change the MXG logic to protect

for the error. Since the purpose of the time test is to

match the type 30 with its type 26, we will use the MVS

type 30 job initiation time, JINITIME, which has not been

touched by JES2 maintanance, instead of JTRMTIME, which

was altered, in the MXG BUILDPDB logic. Thus if the SPIN

library suddenly fills, compare JTRMTIME in SPIN30_5 with

JENDTIME in SPIN26J2, and if JENDTIME is earlier than the

JTRMTIME, you know you have this problem. To correct,

simply change JTRMTIME in the BUILDPDB "To Spin or Not To

Spin" logic shown above to instead use JINITIME. This

Change has been made in MXG PreRelease 8.7 and later.

Thanks to Georg Simon, Federal Reserve of Philadelphia, USA.
Change 08.171 PreRelease 8.5 support for Landmark CICS Version 8 had a

TYPEMON8 little error, but it caused a big dump and a STOPOVER!

Nov 5, 1990 Add +1 at the end of line 066800 (ends with TH PK1.)

to skip over the eighth byte of that datetimestamp.

Thanks to Marcia Ketchersid, Price Waterhouse, USA.
Change 08.170 The FORMATS step (only on MXG 8.5 PreRelease) was missing

JCLTEST the //SOURCLIB DD DSN=MXG.SOURCLIB,DISP=SHR

Nov 5, 1990 JCL statement.
---Changes thru 8.169 were included in MXG PreRelease 8.6 Oct 27, 1990--
Change 08.169 Support for VM/ESA Version 1 Release 1.0 ESA Feature.

EXAPLEDT The contents of the MONWRITE output data records has been

EXAPLSDT changed with new fields and new records, but the changes

EXAPLSRV were implemented by IBM in a completely compatible manner

EXIODATS and thus previous versions of MXG Software will not fail

EXSTOASS when they process the ESA Feature data records.

VMACVMXA The four new records create five new MXG datasets (and

Oct 16, 1990 thus there are five new EX...... exit members), and 15 of

Nov 5, 1990 the existing MXG datasets have new variables.

Dec 4, 1990

1.These fifteen existing MXG data sets content's have been

changed as indicated:

VXSYTXSP - New variables PLSPGMRD,PLSPGMRX,PLSPGXRD, and

PLSPGXWT (page reads/writes to/from ESTORE/AUX

due to page translations/migrations). Sample.

VXSYTASG - SALPRFAV,SALPRFIU are now reserved (were for

Preferred Paging), and new variables added for

page/spool average/total MLOAD (CALTOTM1,M2,

CALAVGM1,M2). Sample.

VXSYTCOM - New variables for counts of IUCVs good to/from

and bad to services SYSTEM,ACCOUNT,LOGREC,CRM,

IDENT,CONFIG, and SPL, twenty-one variables

PLSIS+{E,T,U}+{SY,AC,LO,CR,ID,CF,SP}.

VXMTREPR - Added new flag if Application Domain Event is

active, and CONFIG time limit variable.

VXMTRPAG - DDIPREF now reserved (was Pref. Paging Flag),

DDIPPCYL renamed RDCPCYL, and RDEVSID, Host

Subchannel ID now added.

VXMTRSPR - Added new flag if Application Domain Sample is

active, and CONFIG time limit variable.

VXMTRSCH - New SRMWSSMP for SET SRM MAXWSS value.

VXSCHDDL - New VMDLRGST if user prempted for storage.

VXSCLSRM - New SRMWSSMP for SET SRM MAXWSS value, and

VMDSCDF1 was replaced with VMCQDSPU.

VXSTORSG - New CALASCRT,CALASCFT,CALASCUT for paging

virtual segment control (reorgs, unused and

used pages).

VXSTORSP - New PLSPGDRD,PLSPGDWT for page tables paged

to/from auxiliary storage.

VXSTOASP - New EXPDEVST,EXPMLOAD,CPVLOKAT,CPVALOCD with

paging device service time, MLOAD, scans for

allocations, actual allocations, and twenty

EXPCON01-EXPCON20 tabulating how many times

that many contiguous slots were available.

VXSTOATC - DDIPREF now reserved, CALPAGCY renamed to

RDCPCYL, and RDEVSID added.

VXUSEACT - VMDCTPPS (Pref Page Slots) deleted.

VXIODCAD - New CALPSF data for 3990-3 status bytes.

2.There are five new datasets which can exist. However, two

of the new datasets (VXAPLEDT,VXAPLSDT) will have nonzero

observations is your site has an application that uses

the new interface to create Application data records.

Note that IBM uses that interface, and MXG creates the

VXAPLSRV dataset for file pool servers.

VXSTOASS - Auxiliary Shared Storage Sample Data record

describing resources from the CP-owining a

shared volume (PAGE/SPOOL READs/WRITES, queue

length, and SSCH+RSCH counts).

VXIODATS - Attach Shared Device Event Data record, which

contains exactly the same data as the existing

VXIODATD Attach (non-shared) Device dataset.
VXAPLEDT - Application Event Data record, with a variable

length string of installation/application

created event data, domain 10 record 1.

No IBM application currently uses this new

event data interface.
VXAPLSDT - Application Sample Data record with a variable

length string of installation/application

created interval data, domain 10 record 2.

IBM applications do now use this new interface

but they are recognized by MXG and create the

new VXAPLSRV dataset described below.

VXAPLSRV - IBM's use of Application Sample Data to record

"Server Monitor Records". Both SFS file pool

servers and CRR recovery servers use the

APPLDATA class call to provide 123 counters or

clocks that are listed below. MXG converts all

counters to rates per second (which are, by an

MXG convention, formatted 7.1 to so indicate

that they are rates), but the clocks are kept

in units of seconds during the sample interval

(and FORMATed TIME12.2 to so indicate). The

VMDUSER (VM User ID) must be used to identify

which server created the application data:

Server-ID Observation contains
VMSERVR CRR (Counters 103-116 are only

for CRR, and 114 will be

always non-zero if CRR).

VMSERVS SFS (System owned file pool)

VMSERVU User (User owned file pool)
The following list of variables created from

these servers using the new application data

interface clearly is a major enhancment in

the measurement and management of the shared

file system and other future file servers:
ADATASDT='APPLICATION*DATA'

CALDATLN='LENGTH OF*APPLICATION*DATA'

CALDATOF='BYTE OFFSET*TO APPLICATION*DATA'

DEDMTFLG='DEDICATED*MAINTENANCE*MODE FLAG'

FIRSTR ='FIRST RECORD*SINCE DIAGNOSE*DC ISSUED?'

MDGPROD ='APPLICATION*PRODUCT AND*RELEASE'

SRVCN001='ACTIVE*AGENTS*HIGHEST VALUE'

SRVCN002='VIRTUAL*STORAGE*HIGHEST VALUE'

SRVCN003='VIRTUAL*STORAGE*REQUESTS DENIED'

SRVCN004='CHECKPOINTS*TAKEN'

SRVCN005='CHECKPOINT*TIME'

SRVCN006='SECURITY*MANAGER*EXIT CALLS'

SRVCN007='SECURITY*MANAGER*EXIT TIME'

SRVCN008='EXTERNAL*SECURITY*MGR EXIT CALLS'

SRVCN009='EXTERNAL*SECURITY*MGR EXIT TIME'

SRVCN010='ADD*STORAGE*REQUESTS'

SRVCN011='CACHE*RELEASE*REQUESTS'

SRVCN012='CHANGE*THRESHOLD*REQUESTS'

SRVCN013='CLOSE*DIRECTORY*REQUESTS'

SRVCN014='CLOSE*FILE*REQUESTS'

SRVCN015='COMMIT*REQUESTS'

SRVCN016='CONNECT*REQUESTS'

SRVCN017='CREATE*ALIAS*REQUESTS'

SRVCN018='CREATE*DIRECTORY*REQUESTS'

SRVCN019='DELETE*DIRECTORY*REQUESTS'

SRVCN020='DELETE*FILE*REQUESTS'

SRVCN021='DELETE*STORAGE*REQUESTS'

SRVCN022='FILE*COPY*REQUESTS'

SRVCN023='GET*DIRECTORY*REQUESTS'

SRVCN024='GET*DIRECTORY*ENTRY REQUESTS'

SRVCN025='GRANT*ADMINISTRATOR*AUTHORIZATION'

SRVCN026='GRANT*AUTHORIZATION*REQUESTS'

SRVCN027='GRANT*USER*CONNECT REQUESTS'

SRVCN028='LOCK*REQUESTS'

SRVCN029='OPEN*DIRECTORY*REQUESTS'

SRVCN030='OPEN FILE*NEW REQUESTS'

SRVCN031='OPEN FILE*READ*REQUESTS'

SRVCN032='OPEN FILE*REPLACE*REQUESTS'

SRVCN033='OPEN FILE*WRITE*REQUESTS'

SRVCN034='QUERY*ADMINISTRATOR*REQUESTS'

SRVCN035='QUERY*CONNECTED USERS*REQUESTS'

SRVCN036='QUERY*ENROLLED USERS*REQUESTS'

SRVCN037='QUERY*LOCK CONFLICT*REQUESTS'

SRVCN038='QUERY*FILE POOL*REQUESTS'

SRVCN039='QUERY*USER SPACE*REQUESTS'

SRVCN040='READ*FILE*REQUESTS'

SRVCN041='RECOVERY*CLOSE CATALOG*REQUESTS'

SRVCN042='RECOVERY*GET CATALOG*REQUESTS'

SRVCN043='RECOVERY*OPEN CATALOG*REQUESTS'

SRVCN044='RECOVERY*PUT CATALOG*REQUESTS'

SRVCN045='REFRESH*DIRECTORY*REQUESTS'

SRVCN046='RELOCATE*REQUESTS'

SRVCN047='RENAME*REQUESTS'

SRVCN048='REVOKE*ADMINISTRATOR*AUTHORIZATIONS'

SRVCN049='REVOKE*AUTHORIZATION*REQUESTS'

SRVCN050='REVOKE*USER*REQUESTS'

SRVCN051='ROLLBACK*REQUESTS'

SRVCN052='UNLOCK*REQUESTS'

SRVCN053='WRITE*ACCOUNTING*REQUESTS'

SRVCN054='WRITE*FILE*REQUESTS'

SRVCN055='FILE POOL*REQUEST*SERVICE TIME'

SRVCN056='REMOTE*FILE POOL*REQUESTS'

SRVCN057='ALIAS*DEFINITIONS*EXAMINED'

SRVCN058='ALIAS*DEFINITIONS*UPDATED'

SRVCN059='BEGIN*LOGICAL*UNITS OF WORK'

SRVCN060='AGENT*HOLDING*TIME'

SRVCN061='LOGICAL*UNIT OF WORK*ROLLBACKS'

SRVCN062='SAC*CALLS'

SRVCN063='STORAGE GROUP*EXPLICIT LOCK*CONFLICTS'

SRVCN064='FILE SPACE*EXPLICIT LOCK*CONFLICTS'

SRVCN065='DIRECTORY*EXPLICIT LOCK*CONFLICTS'

SRVCN066='FILE*EXPLICIT LOCK*CONFLICTS'

SRVCN067='STORAGE GROUP*LOGICAL LOCK*CONFLICTS'

SRVCN068='FILE SPACE*LOGICAL LOCK*CONFLICTS'

SRVCN069='DIRECTORY*LOGICAL LOCK*CONFLICTS'

SRVCN070='FILE*LOGICAL LOCK*CONFLICTS'

SRVCN071='CATALOG*LOCK*CONFLICTS'

SRVCN072='LOCK*WAIT*TIME'

SRVCN073='DEADLOCKS'

SRVCN074='QSAM*REQUESTS'

SRVCN075='QSAM*TIME'

SRVCN076='FILE*BLOCKS*READ'

SRVCN077='FILE*BLOCKS*WRITTEN'

SRVCN078='CATALOG*BLOCKS*READ'

SRVCN079='CATALOG*BLOCKS*WRITTEN'

SRVCN080='CONTROL*MINIDISK*BLOCKS READ'

SRVCN081='CONTROL*MINIDISK*BLOCKS WRITTEN'

SRVCN082='LOG*BLOCKS*READ'

SRVCN083='LOG*BLOCKS*WRITTEN'

SRVCN084='BIO REQ TO*READ FILE*BLOCKS'

SRVCN085='BIO REQ TO*WRITE FILE*BLOCKS'

SRVCN086='BIO REQ TO*READ CATALOG*BLOCKS'

SRVCN087='BIO REQ TO*WRITE CATALOG*BLOCKS'

SRVCN088='BIO REQ TO*READ CONTROL*MINIDISK BLOCKS'

SRVCN089='BIO REQ TO*WRITE CONTROL*MINIDISK BLKS'

SRVCN090='TOTAL*BIO REQUEST*TIME'

SRVCN091='I/O REQ TO*READ FILE*BLOCKS'

SRVCN092='I/O REQ TO*WRITE FILE*BLOCKS'

SRVCN093='I/O REQ TO*READ CATALOG*BLOCKS'

SRVCN094='I/O REQ TO*WRITE CATALOG*BLOCKS'

SRVCN095='I/O REQ TO*READ CONTROL*MINIDISK BLOCKS'

SRVCN096='I/O REQ TO*WRITE CONTROL*MINIDISK BLKS'

SRVCN097='RELEASE*BLOCKS*REQUESTS'

SRVCN098='TEMPORARY*CLOSE*REQUESTS'

SRVCN099='SFS*SEND USER*DATA REQUESTS'

SRVCN100='PREPARE*REQUESTS'

SRVCN101='CHANGE*FILE*ATTRIBUTE'

SRVCN102='HIGHEST*MAXCONN*USER'

SRVCN103='GET*CAPABILITY*REQUESTS'

SRVCN104='GET*LOG NAME*REQUESTS'

SRVCN105='CRR GET LUWID REQUESTS'

SRVCN106='RESYNC*INITIAL*REQUESTS'

SRVCN107='RESYNC*PROTOCOL*VIOLATION REQS'

SRVCN108='RESYNC*QUERY DIRECTION*REQUESTS'

SRVCN109='CRR*WRITE LOG*REQUESTS'

SRVCN110='CRR REQUEST*SERVICE*TIME'

SRVCN111='NUMBER OF*SYNC*POINTS'

SRVCN112='SYNC*POINT*TIME'

SRVCN113='PARTICIP RESC*CRR WRITE*LOG REQS'

SRVCN114='CRR LOG*CHECKPOINTS*TAKEN'

SRVCN115='CRR LOG*I/O*REQUESTS'

SRVCN116='CRR BIO*REQUEST*TIME'

SRVCN117='RESERVED'

SRVCN118='DIRATTR*REQUESTS'

SRVCN119='QUERY*ACCESSORS*REQUESTS'

SRVCN120='RESERVED*COUNTER 120'

SRVCN121='RESERVED*COUNTER 121'

SRVCN122='DIRCONTROL*RESOURCE*LOCK CONFLICT'

SRVCN123='DEADLOCKS*THAT CAUSE*ROLLBACK'

SVMSTAT ='OPTION*SVMSTAT*IN DIRECTORY?'

VMDUSER ='USER*IDENTIFICATION'
3.The documentation of the VM/ESA Monitor records will now

be only in "softcopy", and will be unloaded at install

into a file named MONITOR LIST1403 on your base CP object

disk (194). The new documentation contains an excellent

table that details changes made to the content and format

of the monitor records, including the many APARs that are

a part of VM/XA (and were already supported in MXG).
A thanks for IBM for making documentation available so

early; it's nice to not have to play "catch-up". Of even

greater significance: you can install this version of MXG

now, and whenever you install VM/ESA, you won't need to

install yet another version of MXG!
---Changes thru 8.168 were included in MXG PreRelease 8.5 Oct 27, 1990--
Change 08.168 The SAS 6.06 circumvention was misspelled; three lines

GRAFRMFI that now read

Oct 26, 1990 IGOUT=GRARMF5S GOUT=PDB.GRARMF5S

should be

IGOUT=GRARMF5S GOUT=PDB.GRARMF5S

IGOUT=GRARMF5M GOUT=PDB.GRARMF5M

IGOUT=GRARMF5D GOUT=PDB.GRARMF5D

Thanks to Jan Simark, SAS Institute Europe, GERMANY.

Change 08.167 Support for MVS/ESA SP Version 4.1 and RMF 4.2, which

VMACSMF became avaliable October 26, 1990.

VMACSMF 1.New flag variable MVSESAV4 (flag that this is MVS Version

VMAC434 4) is set but not used in MXG logic.

VMAC535 2.TYPE434, new variables CPUWRONG and EXCPLOST are now set

VMAC6 to "Y" if TCB time has overflowed, or EXCPs lost because

VMAC24 over 1635 DD statements existed. Both conditions exist

VMAC57 ONLY in the type 4 and 34 records, and IBM's now states

VMAC71 "Only the type 30 record should be considered valid."

VMAC74 3.TYPE535, new variable CPUWRONG (see above) added.

VMAC78 4.TYPE6 (JES2 only, not PSF nor JES3 nor EXT WRTR) has

VMAC79 a new "Enhanced SYSOUT Support (ESS) section containing

VMAC90 the output descriptor (if any) for the first offloaded

XMAC7072 data set, with five new variables:

XMAC71 SMF6IND ='ESS*SEGMENT*INDICATOR'

XMAC73 SMF6JDVT='JCL*DEFINITION TABLE*NAME IN JDTV'

XMAC74 SMF6SGID='SEGMENT*IDENTIFIER'

XMAC75 SMF6TU ='TEXT UNIT*(SWBTU)*DATA AREA'

Oct 27, 1990 SMF6TUL ='TEXT UNIT*(SWBTU)*DATA AREA LENGTH'

Mar 5, 1991 This paragraph was changed after Newsletter 18.

The SMF6TU character variable contains the SWB text unit,

which contains the JES2 ITEXT (length, key, value) for

the new OUTPUT JCL statement parameters ADDRESS, BUILDING

DEPT, NAME, ROOM, and TITLE. Their key values (IEFDOKEY

in SYS1.MACLIB) are x'27',28,29,2D,26, & 2A respectively.

Once I find out what sets the maximum length of these new

parameters, the fields will be decoded from the SWB. Stay

tuned to this paragraph in this change.

5.The MSS (Mass Storage System) device is no longer and IBM

supported device, and TYPE22_4 and its MSS variables will

now always be missing.

6.TYPE24 contains the same new five Enhanced SYSOUT (ESS)

fields added to the type 6, with these different names:

SMF24IND,SMF24JDT,SMF24SGT,SMF24TU, and SMF24TUL.

These variables are kept in TYPE24.

7.TYPE57J2 contains the same new five Enhanced SYSOUT (ESS)

fields added to the type 24, with these different names:

SMF57IND,SMF57JDT,SMF57SGT,SMF57TU, and SMF57TUL.

These variables are kept in TYPE57.

8.TYPE71 contains three new swap reason codes, because MVS

now has three additional reasons to swap an ASID:

IC - Improve Central Storage usage swap, by recognizing

page thrashing.

IP - Improve System Paging Rate swap, identifies that

your PTR controls are causing swaps.

MR - Make Room to swap in a user who has been swapped

out too long. When an Exchange Swap should have

occurred, SRM starts a clock, defaults to 30 sec

for TSO, 10 min for non-TSO, and will bring that

task back in if it stays out that long.

For each swap reason, there are five new variables for

the swap rate of each possible transition (EXTAUX..,

LOGAUX.., LOGEXT.., PHYAUX.., and PHYEXT..). The sum of

all transitions for each swap reason, (i.e., the total

swap rate for that reason code) is in the new variables

SWAPIC, SWAPIP, and SWAPMR.

9.TYPE74 data set has been enhanced with new variables

CUNAME ='CONTROL*UNIT*NAME'

DEVMODEL='DEVICE*MODEL*NAME'

and three variables describing pending delay due to the

director port busy, AVGPNDIR, DLYDIRTM, and PCPNDIR.

10.New subtype 2 of the Type 74 record from the Monitor III

Cross-System Coupling Facility (XCF) reports on message

traffic between the local system (where RMF executes)

and remote systems.

Four new TYPE74xx data sets are created:

/*TYPE74CO - control data */

R742MNXT='MEMBER DATA*SECTIONS IN*NEXT RECORDS'

R742MTOT='MEMBER DATA*SECTIONS IN*ALL RECORDS'

R742PNXT='PATH DATA*SECTIONS IN*NEXT RECORDS'

R742PTOT='PATH DATA*SECTIONS IN*ALL RECORDS'

R742SNXT='SYSTEM DATA*SECTIONS IN*NEXT RECORDS'

R742STOT='SYSTEM DATA*SECTIONS IN*ALL RECORDS'

R742TSR ='SUBTYPE 2 RECORDS IN INTERVAL'

/*TYPE74ME - member data */

R742MGRP='GROUP*NAME'

R742MMEM='MEMBER*NAME'

R742MRCV='SIGNALS*RECEIVED BY*MEMBER'

R742MSNT='SIGNALS*SENT BY*MEMBER'

R742MSTF='STATUS*FLAGS'

R742MSYS='SYSTEM NAME*WHERE MEMBER*RESIDES'
/*TYPE74PA - path data */

R742PAPP='PATH WAS BUSY*WHEN SELECTED*TO TRANSFER'

R742PDEV='DEVICE*NUMBER'

R742PDIR='DIRECTION*PATH'

R742PIBR='INBOUND SIGNALS*REFUSED*MAX MSG LIMIT'

R742PMXM='MAXIMUM*MESSAGE BUFFER*SPACE'

R742PNME='SYSTEM*NAME'

R742PODV='DEVICE*NUMBER ON*OTHER END'

R742PONA='NAME OF*SYSTEM ON*OTHER END'

R742PQLN='OUTBND SIGNALS*PENDING TRANSFER*ON PATH'

R742PRET='PATH*RETRY*LIMIT'

R742PRST='NUMBER*OF*RESTARTS'

R742PSIG='OUT/IN BOUND*SIGNALS SENT/RCVD*OVER PATH'

R742PSTA='PATH*STATUS'

R742PSTF='STATUS*FLAGS'

R742PSUS='PATH NOT BUSY*WHEN SELECTED*TO TRANSFER'

R742PTCN='TRANSPORT*CLASS*NAME'
/*TYPE74SY - system data */

R742SBIG='NUMBER OF*BIG MESSAGE*CONDITIONS'

R742SBSY='NUMBER OF*NO BUFFER*CONDITIONS'

R742SDIR='DIRECTION*OF THE MESSAGE*TRAFFIC'

R742SFIT='NUMBER OF*MESSAGE FIT*CONDITIONS'

R742SMXB='MAXIMUM*MESSAGE BUFFER*SPACE'

R742SNME='SYSTEM*NAME'

R742SNOP='NUMBER OF*NO PATH*CONDITIONS'

R742SOVR='BIG MESSAGES*THAT EXCEEDED*OPT MSG LEN'

R742SPTH='SIGNALING PATHS*CURRENTLY*IN SERVICE'

R742SSML='NUMBER OF*SMALL MESSAGE*CONDITIONS'

R742SSTF='STATUS*FLAGS'

R742STCL='MESSAGE LENGTH*FOR*TRANSPORT CLASS'

R742STCN='TRANSPORT*CLASS*NAME'

11.TYPE75 data set has also been enhanced with the same new

variables CUNAME and DEVMODEL that were added to TYPE74.

12.TYPE78 now detects and deletes invalid subtype 3 records

to avoid the STOPOVER condition if you have not installed

PTF UY55476 for APAR OY36517 described in MVS notes.

13.TYPE79 subtype 1 changed R791ES to reserved and previous

reserved R791ESSL now contains what was in R791ES and is

renamed R791ESCT! Both R791ES and R791ESCT are kept.

14.TYPE79 subtype 11, new variables R79BCU and R79BDEVN for

control unit name and device name.

15.TYPE90 new subtype 18 added variables SYSISUED,SMF90SGC

and SMF90GRN for the SET GRSRNL command.

16.All five of the XMAC70xx members (needed only for SAS

Version 5 for circumvention of the "344 Compiler Limit"

error condition) now include these and all previous MXG

changes to their corresponding VMAC members. See Change

8.129 for further information on the "344" error. Due to

additional new subtypes added by MVS 4.1, there were 3

new iterative DOs added by this support which may cause

modified BUILDPDBs to need "344" circumvention. Sorry!

Note that IBM has announced additional RMF enhancements in

MVS/ESA 4.2 (RMF 4.2.1) to be available on March 29, 1991,

that will add additional data to type 72, 74, and 79s.
Change 08.166 Variable INNODE was added to _PDB26J2 macro. INNODE and

IMACPDB (previously kept) INROUTE are both required to know the

Oct 23, 1990 source of a job, using PDB.JOBS.

Thanks to Elliot Weitzman, Oryx Energy Company, USA.

Change 08.165 IMS Log processing variable PGMLODTM is now non-zero only

TYPEIMS for the first transaction, for multiple transactions per

Oct 23, 1990 program schedule (since the program is loaded only once!)

and OENQTIME is calculated differently for MULTRANS.

Thanks to Harry Olschewski, DVG Kiel, GERMANY.
Change 08.164 Page 219 references the _DBUG110 macro which no longer

MXG Guide exists. It was replaced by a new (undocumented) value of

Oct 23, 1990 SYSPARM=TYPE110-5, since specifying a SYSPARM value does

not require the source change mentioned on page 219.

Thanks to Hr. Moser, RBG Munich, GERMANY.
Change 08.163 NETSPY target response variables for session manager

VMACNSPY have no meaning, but contained non-zero values (they are

Oct 23, 1990 addresses) in the SMF record. MXG recognized thesession

manager record and set the percentages T1RSPPC-T4RSPPC to

missing, but left the counts T1RSPNO-T4RSPNO as they were

found, which confused some users. Now, the countsare

also set missing for session manager records.

Thanks to Randy Hallman, LEGENT, ENGLAND.

Change 08.162 NPM variables OPER.... are now correctly labeled to show

VMAC28 these fields represent HOST plus NETWORK durations, and

Oct 23, 1990 the NETW.... variables are now corrected to label these

fields as NETWORK only (i.e., eliminating the previously

incorrect NEWT label of Network Plus Host). The values

were correct, only the MXG label was incorrect.

Thanks to Tom Kiddy, American President Lines, USA.
Change 08.161 Support for Landmark's Monitor for CICS Version 8.0

ANALMONI Member TYPEMON8 is used instead of TYPEMONI for this

EXMONHIS new version. The support added two new datasets, the

EXMONMRO MONIMRO (MRO detail from transaction record), and the

IMACMONI MONIHIST history detail, which contains the total-to-

TYPEMON8 current-minute of the resources in the MONISYST interval

Oct 18, 1990 data set. MONISYST is now written every minute. Many new

fields describe counts and durations of both requested

and waiting states. The variable names are patterned:

WTxxyyzz

where xx=activity (see list below).

yy=IO for request active, or

WT for waiting, a subset of request active.

zz=TM for duration, or

CN for count of times activity performed.

eg:

WTFCIOTM=duration File Control IO was requested,

including processing and waiting time,

WTFCIOCN=count of File Control IO requests,

WTFCWTTM=duration that FC IO actually waited, and

this duration is included in WTFTIOTM,

WTFCWTCN=number of times File Control actually waited.

The xx activities captured in Landmark Version 8 are:

xx Requests Waits

DB ='DB2*WAITS' YES

DL ='DLI*CALL*IO' YES YES

DS ='DISPATCH*QUEUE-WAIT' YES

EN ='ENQUE*SUSPEND*WAITS' YES

FC ='FILE*CONTROL*IO' YES YES

IC ='ICP*SUSPEND*WAITS' YES

IS ='ISC (MRO)*SUSPEND*WAITS' YES

JC ='JOURNAL*CONTROL*IO' YES YES

MD ='MRO/DTP*WAITS' YES

MI ='MIRROR*SUSPEND*WAITS' YES

MR ='MRO/IRC*WAITS' YES

MS ='MRO/DTP*SUSPEND*WAITS' YES

NS ='DB2 NON-SQL*CALLS' YES

OP ='OPER*THINK TIME*FOR CONV' YES

PF ='PROGRAM*FETCH' YES YES

PM ='PREEMPT*WAITS' YES

SC ='MRO/ISC' YES YES

SQ ='DB2 SQL*CALLS' YES

ST ='STORAGE*SUSPEND*WAITS' YES

TB ='TEMPSTG*(AUX+MAIN)' YES YES

TC ='TERMINAL*SUSPEND WAITS' YES

TD ='TD (EXTRA)*IO' YES YES

TI ='TD (INTRA)*IO' YES YES

TS ='TEMPSTG (AUX)*OUTPUT' YES YES

UD ='USER*DATABASE' YES YES

1S ='FIRST*DISPATCH' YES

Wherever possible, previous MXG variable names are used

but Landmark names are in comments adjacent to MXG's

chosen variable name in MXG member TYPEMON8. Complete

description of variables is contained in Landmark's

Appendix C of "Report Writer and Extended Facilities",

and in MXG member DOCVER under each MONI.... dataset.

Change 08.160 DCOLLECT record date fields cause "NOTE: INVALID DATA"

VMACDCOL or "NOTE: ILLEGAL ARGUMENT TO FUNCTION" when the julian

Oct 10, 1990 date is a zero, nulls or 99000 or 99366. The three input

statements for DCDDATE1-DCDDATE3 need ?? before the PD4

format item, and the calculation of DCDCREDT and DCDLSTRF

must be protected for 0. The DCDEXPDT expiration date is

more complicated, because EXPDT values of 99000 and 99366

appear in DCOLLECT records, but these cannot be converted

to real date values. DCDCREDT, DCDEXPDT, DCDLSTRF should

be SAS date values, so that subtraction, formatting, etc.

can be done. However, these "flaky" EXPDT values used for

flags should not be lost. Since only EXPDT contain these

"flaky" values, MXG chooses the following technique. New

variable ORGEXPDT will contain the original (raw, in the

record) value (the raw value for Jan 1, 1991 is 1991001).

DCDEXPDT will contain the real SAS date of ORGEXPDT, or

will be missing if ORGEXPDT was zero or missing, but if

ORGEXPDT contains a "flaky" value (day=000, 99000, 99365

or 99366), MXG sets DCDEXPDT of 1JAN 2099 as a special

flag date to tell you to look at ORGEXPDT if you really

need to know the original expiration date. MXG uses a

SAS date in the year 2099 so that if you should ever use

DCDEXPDT in a calculation, you'll see the expiration

date is well into the future!

Thanks to Jim Gilbert, Texas Utilities, USA.
Change 08.159 Variable PAGRT in TYPE71 now includes PGMIEXAU, HIPAGINS,

VMAC71 and HIPAGOUT, in addition to the original DPR, SPR, & VIO

Oct 10, 1990 variables so that PAGRT counts all pages moved between

auxiliary storage (DASD) and central/expanded storage.

The three new fields are MVS/ESA only.

Thanks to Peter Durant, National Australia Bank, AUSTRALIA.

Change 08.158 This was originally a two part technical discussion with

no actual MXG change. The first half of that discussion

is now Change 8.172 and has been reworded and enhanced.

This is the rest of the original technical discussion.

One site wanted to reset their SPINCNT value to 0 at the

end of each month. (I don't recommend this technique,

and its not clear to me this is wise, but by exploiting

MXG's use of the old style substitution macro _SPINCNT,

it was possible to show them how to do what they wanted

to do, with no change to the BUILDPDB code itself):

In IMACSPIN, define _SPINCNT as follows. The value of 10

in the example assumes your original SPINCNT was 10.

MACRO _SPINCNT

. THEN DO;

IF SYSPARM()='MONTH' THEN SPINTST=0;

ELSE SPINTST=10;

IF SPINCNT GE SPINTST THEN OKFLAG=1;

END;

ELSE IF -1 = +1

%
This logic is not obvious, until you look at BUILDPDB

to see exactly how _SPINCNT is referenced, but it shows

how flexible the old style substitution macros can be!

With this new definition for _SPINCNT, and by using the

OPTIONS='SYSPARM="MONTH"' on the EXEC SAS statement

on the desired day, the SPIN library will be emptied.
---Changes thru 8.157 were included in MXG PreRelease 8.4 Oct 9, 1990---
Change 08.157 SAS 6.06 Compatibility Change. SAS User-SMF record.

IMACSASU The format of the SAS-created user SMF record (describing

VMACSASU resources for each PROC execution) was changed in 6.06.

Oct 8, 1990 Now, IMACSASU defines two macros, _IDSAS5 and _IDSAS6 to

identify the SMF record number of each version's record.

If you are currently building TYPESASU from Version 5.18

records, you will have to replace the modified IMACSASU

in your USERID.SOURCLIB with this new IMACSASU member.

Thanks to Tim Haiar, South Dakota Higher Ed. Computer Services, USA.
Change 08.156 Additional enhancements for RMF III VSAM dataset record

EXZRBUWM processing was provided by National Westminster Bank to

EXZRBUWT these members. Two new members, ZRBBATCH and ZRBPRINT

VMACZRB were added and they produce a detailed analysis of batch

ZRBBATCH job delays. Member ZRBDLYBT was rewritten to be more

ZRBBUILD efficient. Member VMACZRB has been amended to include a

ZRBCHECK division-by-zero test for SQA overflow frames.

ZRBDLYBT The function of the associated code members is explained

ZRBDVDLY in member VMACZRB. New member ZRBIPSJ is an interesting

ZRBMKIDX job which is self-explanatory and reads selected members

ZRBPRINT of SYS1.PARMLIB. Two new data set exits were added. The

Oct 8, 1990 remaining members changes were only in the comments. All

"ZRB" members now cite both NatWest's enhancements and

acknowledge the original "ZRB" author, Dick Whiting.

Thanks to Roland Rashleigh-Berry, NatWest, ENGLAND.

Thanks to Dick Whiting, Precision Castparts, USA.

Change 08.155 Variable FWRATIO (Fast Write Hit Ratio) was added to the

VMACACHE CACHE90 data set. Because four Fast Write specific fields

XMACACHE (SRCD,SRCDH,WCD,WCDH) were zero, it appeared there was no

Oct 8, 1990 Fast Write, but FWRATIO was actually non-zero. This value

now matches the same-named heading on the IBM report.

Thanks to Dale Mattison, Shared Medical Services, USA.

Change 08.154 This ROSCOE report did not %INCLUDE IMACROSC and did not

ANALRRTM threfore use the _ROSCDDN as the expected location of the

Oct 6, 1990 RRTMPSE data set used for reporting; now it does.

Thanks to Bob Yeager, Whirlpool Corporation, USA.

Change 08.153 Comments were corrected. The correct sort order for the

ASUMJOBS WEEKBLD after using ASUMJOBS is given by the SUMBY= list

Oct 6, 1990 on the invocation of %VMXGSUM, but anytime that the

temporary variable "DATETIME" is used in the SUMBY list

(as it usually is), the actual variable you must use in

any subsequent processing is not "DATETIME" (which will

always be DROPped by VMXGSUM), but instead the actual

variable set equal to DATETIME= in the macro invocation.

For ASUMJOBS the actual resultant sort order will be

JOBCLASS SHIFT INITTIME

because SUMBY=JOBCLASS SHIFT DATETIME, but also

DATETIME=INITTIME, in the VMXGSUM invocation.

Thanks to Linda Carroll, Crawford Long Hospital of Emory Univ, USA.
Change 08.152 VM/370 Monitor data set VMONCHAN now has the sample count

ANALVMDY variables MN602SAM and MN602SA2 added to the KEEP= list,

VMACVMON and they were added to the RETAIN list so that the are

Oct 6, 1990 carried into the CHAN record from the DEV record. This

avoids the need to merge DEV and CHAN to calculate CHAN

busy. The three tests for (LENGTH-COL) GE 64 should all

be GE 63 so that channels 32 and higher actually INPUTed.

ANALVMDY now uses the MN602SAM/SA2 instead of INTERVAL to

correct its CHAN busy calculations. Variable MN003CDD

should not be DIF()d, and variable DRUMUTIL needed to be

added to the big RETAIN list.

Thanks to Bob Small, Grumman Data Systems, USA.

Thanks to Frank Putnam, Ryerson Polytechnical Institute, USA.
Change 08.151 VM/XA support macro _DBYUSR did not DIF() some of the HF

VMACVMXA counters, causing some percentages to be since the start

Oct 5, 1990 of monitoring. These HF counters are now DIF()d. MACRO

_CSYTUWT should have decremented SKIP by 52 vice 72.

If the Interval or HF Sampling rate were changed, MXG

made the change when the record was found, rather that

as it should have at the end of the interval. That has

been corrected, and notes on the log alert you if either

was altered.

Thanks to Peter Strange, BP International London, ENGLAND.

Change 08.150 This JCL member is an example of the MVS job that submits

JCLCRAYC a job to execute on the Cray to extract the accounting

Oct 5, 1990 and performance data records and send them back (asis)

to the MVS system (into dataset MXG.CRAY.MODFILE) that is

then processed by MXG member TYPECRAY under MVS to build

the Cray PDB. (This specific example is for COS 1.17).

With 1000 Cray jobs per business day, and with the SPM

interval set at 10 minutes, the extract will need about

125 cyl, or about 90MB for an entire WEEKs Cray rawdata.

Thanks to Arlin B. Collins, Oryx Energy, USA.

Change 08.149 Support for Amdahl's SPMS product's SMF record for the

IMACSPMS 6100 and 6880 Cache DASD controllers. The code was tested

VMACSPMS with the help of the folks at Amdahl, and one real user,

TYPESPMS as the documentation of the SMF record is less than good.

Oct 5, 1990 Data set TYPESPMS is created from the SMF record, but

only 6100 data records have been validated. Amdahl has

said there will be enhancements in the near future to the

SMF record that will answer many user requirements.

MXG variable names for fields described in the DSECT are

the DSECT suffix prefixed with SPMS. For variables that

are calculated or decoded, the variable name suffix is

SPMS or SPM. Do you like this technique (which was my

choice after looking at the two user contributions from

which this support derived)?

Thanks to Richard R. (Dick) Sziede, PRC Inc, USA.

Thanks to Neville Windeyer, Amdahl, USA.

Thanks to Ray Williams, Amdahl, USA.

Thanks to Neil Avery, Amdahl, USA.

Thanks to Randy Graves, Amdahl, USA.
Change 08.148 NPM Release 4 (NPM 1.4) Support has been added, but not

EX028ER1 yet tested with 1.4 data. This text will change when

EX028ER2 validation has been completed with 1.4 data records.

EX028IN9 Support is in MXG PreRelease 8.4, but because IBM used

FORMATS (correctly!) the relocatable record architecture, their

VMAC28 changes ARE compatible with MXG 7.7. (MXG 7.7 will detect

Oct 5, 1990 the new 1.4 data and will note that unexpected data was

found, but MXG 7.7 will not fail with NPM 1.4 data!). The

change processes mixed 1.3 or 1.4 records, transparently!

1.Support added three New MXG datasets:

NPMERNCP,NPMERNET, for NCP or Network respectively,

are created when a prior Event Exception has been

resolved (either the value is now in range, the

resource was detached, or monitoring was stopped).

NPMINTRI, an interval record reporting resources from

the Network Token Ring Interface.

2.Support added new variables in existing MXG datasets:

NPMINPMT, variables NPMALRCT,NPMARCNT count Alerts

sent or lost.

NPMINSES, variables LSCDANUM,BADI,CNTL,EXTN,GRUP,SMID,

SPLU,SSLU, and LSCDUSER contain (optional) session

manager names (Userid, SLU, etc.) and status.

NPMINNCP, variables NCPNEWNM,NCPGENLV contain NCP load

module name and the GENLEVEL parameter.

NPMINPMT, variables NPMTDROF,DRAD,DRDE,DL18) track the

DDR entries lost, added, or deleted.

3. FORMAT member was updated with new format MG028FL and

existing formats MG028DA and MG028NT contain new

values.

4. The IBM NPM 1.4 Installation and Customization Guide,