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

insufficient number of allocated slots will degrade the contiguous slot

algorithm; the exact percentage at which you encounter increased

service time may not be 25%, and you should construct your own data for

analysis.

h. Use STEP data for job ABEND analysis.

Analysis of "Job" abends really must be done from the PDB.STEPS (from

TYPE30_4 step termination), rather than from the PDB.JOBS (from

TYPE30_5 job termination). The CONDCODE and ABEND variables (Page 578

in the MXG Book, page 266 in the MXG Supplement) describe the value and

the type of termination. ABEND values of SYSTEM or USER indicate

abends and CONDCODE identifies the abend code, such as SYSTEM 322 or

USER 999. An ABEND value of RETURN indicates that CONDCODE contains a

return code value. While both variables exist in both PDB.JOBS and

PDB.STEPS, the ABEND value in PDB.JOBS is from the job termination

record, and can show an ABEND of SYSTEM for the job with a CONDCODE of

zero if the step which ABENDed was not the last step! The PDB.STEPS

data is thus not only more accurate, but since many abends result are

due to defective programs rather than defective jobs, using the STEPS

data allows you not only to identify which JOB abended, but also to

identify the name of the PROGRAM which abended. You may even be able

to recognize (by your program naming convention) which of your

development groups wrote the frequently-abending programs!). PDB.STEPS

data also identifies which step actually abended first when there are

multiple abends (and when there are COND=EVEN and COND=ONLY steps).

CICS CMF record blocksize is set by the JCT BUFSIZE parameter, and

typically is only 6000, which should be increased to half-track on

3380s to reduce IO counts and CPU overhead in building CMF records.
NPM may produce negative square root when calculating standard

deviation, since SSQ field can wrap in NCP.

Tape mounts in TYPE30_4 and PDB.STEPS does not include mounts issued

by JES3 for MDS mounts; they are counted in the JES3 Type 25 record.

Steps which mount a tape, and then RETAIN, will show zero mounts for

the subsequent step. If you want to identify steps which actually

use tape in any step, the EXCPTAPE and IOTMTAPE are much better

indicators of actual usage.

UCC7 can cause invalid READTIME error messages. There are two options

for UCC7 to identify jobs which are under its control. By default, the

eighth byte of JMRUSEID (the 'User identification field', MXG variable

LOCLINFO) is used. The UCC7 installer can choose any other byte of the

JMRUSEID if other products use the eighth. If all eight bytes are used

by other products, UCC7 will optionally store its flag in the first

byte of the Job Reader Date field. The normal value stored is a 'EE'X,

but if NCF is also installed, the field can take on almost any value.

When the Job Reader Date field is used, UCC7 traps each SMF record as

its being written and clears out the high order byte. Unfortunately,

the trap uses a table of SMF record IDs, and records which UCC7 does

not know about (such as the type 60, 61, 65, 66, 78, 80 and all user

records such as ACF2) are passed into the SMF file with an invalid

reader date. The result is a missing value for READTIME for these UCC7

controlled job records. Pages 2 and 9 of the UCC7 Installation Guide

discuss these options, and UCCEL technical support has the fix for the

60's and 80 records, as well as advice for handling user SMF records.

If the record has the Reader Date in the "standard" location (bytes

27-30), the fix is simply to add the record ID to ICMDSECT. For records

with relocatable format (like the type 78 record which can record a

specific job's virtual storage), more complicated instructions are

available from UCCEL. Since MVS 2.2 will use the first byte of the

date field for dates in the next millennium, UCC7 designers are looking

for an alternative.

Technical Notes, VM:
There are two ways to hold SPOOL data in VM so that it exists after the

spool data is read:

SPOOL READER HOLD holds the reader, while

CHANGE READER nnn HOLD holds the file

Hold only the reader, never hold the file, if you want the data to be

read. The CMS Diagnose 14 Subtype 1C command which is used to read the

monitor data in the spool, skips over held files.
VM will not create VBS records. If you install MXG under CMS to read

SMF data, you cannot build the SMFSMALL data set described in the

installation instructions. Change the Filedef and the FILE statement in

UTILGETM to build the SMFSMALL file with RECFM=VB,LRECL=32756, and

BLKSIZE=32760 on a 3380 disk and the program will work. Yes, it will

not make efficient use of the disk space, but SMFSMALL is only a small

test file of SMF data. VM is capable of reading VBS input tapes, so

you should have no problem processing SMF under CMS.

Technical Notes, SAS:
a. Eliminating tape mounts for SAS tape data libraries.

Many users have found that the weekly and monthly PDB jobs (described

in Chapter Thirty-Five with examples in MONTHBLD and WEEKBLD) can cause

lots of tape mounts and rewinds. Some sites have resorted to the

parallel allocation of as many tape drives as there are tape volumes to

avoid mounts. This problem is not unique to MXG, but results from the

protective instincts of SAS when tape data sets are involved. As you

will see, we now have a sucessful circumvention which minimizes the

amount of temporary DASD needed by WEEKBLD and MONTHBLD, and completely

eliminates the multiple rewinds and mounts for the output library.

The Present SAS Design:

SAS data libraries on tape volumes have no directory of what SAS data

sets are where on the tape. When a SAS SET statement needs to read a

SAS data set from tape, SAS rewinds to the beginning of the tape, and

searches for the desired data set. When a SAS DATA step writes a SAS

data set to tape, the tape is first rewound to the beginning, and SAS

searches for the data set name. If no match is found, SAS puts the new

data set at the end of the tape. (If a match is found, SAS starts the

new data set where the old one was found, erasing all old data sets

after that point on the tape.)

The Source of the Problem:

The required rewind spins the tapes a lot. If the SAS data library

fits on a single volume, there is not too much of a problem. But if

the output tape library expands to a second tape volume, each rewind

(i.e., each new SAS data set) causes the second volume to be

dismounted, the first volume to be mounted and searched, and then the

second volume remounted and searched, and finally the new data set is

laid down at the end of the tape! This always occurs when SAS DATA

steps create the tape data library.
Past Circumventions:

One solution was to build all of the desired SAS data sets on disk, and

then use PROC COPY from disk to tape. The PROC COPY knows it does not

need to rewind before each data set. While this avoids the mount

problem, it requires as much temporary DASD space as the size of the

entire SAS data library, which is why it was not recommended.

The New Solution:

Each new SAS data set is first built on temporary DASD in "tape

format", and then is copied to the output tape using FILE/INFILE logic,

exploiting the SAS CLOSE=LEAVE option to hold the output tape in place.

The temporary DASD data set is then erased, so that the job needs only

as much DASD space as the size of the single largest SAS data set to be

created. The "tape format" is created if the DDNAME of the SAS data

set being created starts with TAPE...., and is necessary so that the

SAS data set can be copied with the FILE/INFILE logic. The following

partial example shows how this is done (see member MONTHBLD for

complete implementation):

// EXEC SAS,OPTIONS='TAPECLOSE=LEAVE,GEN=0,ERRORABEND'

//MONTH DD DSN=MXG.MONTHLY(+1),DISP=(NEW,CATLG),UNIT=TAPE,

// DSCB=SYS1.MODEL,LABEL=EXPDT=99000

//TAPETEMP DD DSN=&TEMP,UNIT=SYSDA,SPACE=(CYL,(10,10))
DATA TAPETEMP._DSET; create _DSET in TAPETEMP

SET WEEK1._DSET WEEK2._DSET ... ; input data sets

BY _BYLIST: sort order variables

IF date selection logic; selection criteria

RUN:
DATA _NULL_; copy _DSET to MONTH

INFILE TAPETEMP;

FILE MONTH MOD CLOSE=LEAVE;

INPUT;

PUT _INFILE_;
DATA _NULL_; write EOF to TAPETEMP to

FILE TAPETEMP; "scratch" _DSET

These three DATA steps are then repeated for each data set to be built,

by invoking the _MNTHBLD macro as shown in member MONTHBLD. Our thanks

to Susan Marshall, SAS Institute, for this circumvention. The only

additional cost is the extra copying of each output data set. This

solution only eliminates mounts for the output SAS data library. If

the input data sets are on multiple volumes, each new data set may

causes the same rewind and dismount/mount sequence. These input mounts

can only be eliminated (at present) by specifying multiple units where

necessary, eg., with UNIT=(TAPE,2) for a two-volume input tape data

library.

SAS Institute is investigating a new SAS option which might allow

you to override that "rewind and search" algorithm for both input

and output tape data libraries. Provided the order of building new

data sets is the same as their order on the input data libraries,

such an option could completely eliminate the unnecessary mounts and

unnecessary copy steps. No commitment has been made by SAS yet.

However, early experience with this circumvention is overwhelmingly

positive - fewer tape drives, fewer tape mounts, significant reduction

in elapsed time, all for a few seconds of I/O time!

b. SAS ZAPs which you should install.

ZAP 516.2525 Corrects (erratic) error condition in PROC PLOT if

data set has zero observations.

ZAP 516.4592 PROC FORMAT can cause a "STOW failure" message on the

SAS log (no error condition, no abend) if the PDS to

which the formats are being written does not have

enough directory blocks defined. Some formats will be

missing, with no notification. This ZAP tells you.
c. SAS Options which you should be aware of.
FREE=CLOSE either as a SAS option or on a DD card in a SAS job

interferes with the IBM STIMER routine, which is used

to measure SAS step CPU time. FREE=CLOSE has caused

unpredictable USER 999 ABENDs with the SAS error

message CPU TIME EXCEEDED and a large value of CPU

time shown on the SAS log. The value on the log is

wrong (see the Step Termination message to confirm)

but the STIMER poped and SAS shut the step down.

Either do not use FREE=CLOSE, or use the SAS NOSTIMER

option, which eliminates the problem, but will also

eliminate the CPU used message on the SAS log.
NOMEMFILL Should always be specified, MEMFILL is a SAS debug

developers option which should never be used, as it

causes a seven-fold increase in CPU time.

==========================Changes======================================

The following changes are already in the Production MXG 5.5 library.
Some of the changes contain the code with line numbers, because those

changes were originally distributed (via prior newsletter, telephone

or telefax to correct immediate problems. Just for your information,

lines to be inserted have a period after the line number they are to

follow; existing lines which needed no change (usually included to

locate the change) have no period in their line number.

While this newsletter hits the high spots, you must read each change

description to ensure that you understand their potential impact to

your installation.
ALWAYS read member CHANGES for last minute changes and notes. This

newsletter is mostly an editied version of CHANGES slightly before

the production library is created.
ALWAYS read each member listed under an impacting change for

additiona comments, notes, and any last minute documentation.

Members DOCVER and DOCVER05 document the entire collection of data

sets created by MXG (DOCVER), and the delta-documentation of data

sets and variables changed between MXG Version 4.4 and 5.5.

NEXTCHANGE: Version 5

=============Changes thru 5.173 as of Dec 17, 1987 ===================

==================completed MXG Version 5.5.==========================

--Changes 5.167-5.173 were added after Newsletter ELEVEN was printed--

Change 05.173 Processing of IMF (Control/IMS) records from Boole &

Dec 17, 1987 Babbage with IMS Release 2.0+ was failing. The test of

VMACCIMS IMSLEVEL NE:'13' caused old format INPUT statement to

be executed. Test is now either LT:'13' or GE:'13'.

Thanks to Dave Lawrence, NCNB of Florida, USA.

Change 05.172 CICS 1.6 dictionary entry for USER field with length

Dec 17, 1987 of zero (i.e., no USER field in your data) caused an

UTILCICS unnecessary, incorrect and superfulous MXG message.
Change 05.171 Support for CICS 1.7 PTF UL14896 (which adds a new

Dec 16, 1987 SCWTETIM field to CICSEXCE exception data set). MXG

IMACPTF creates variables SCWTETM and SCWTECN for the field,

UTILCICS which reports time in suspend because unconditional

VMAC110 storage request was not satisfied.

Thanks to Joseph J. Faska, Chemical Bank, USA.

Change 05.170 Some complexity-level-4 variables had level-3 in their

Dec 16, 1987 labels. Labels are now correct. Member ANALRTM1 (only

ANALROSC existed in pre-releases) was eliminated by rewrite of

IMACROSC ANALROSC. Read important comments in ANALROSC, as it

TYPEROSC now deletes "useless" ROSC.... and RRTM.... data sets.

VMACROSC New macro _ROSCDDN is now defined in memeber IMACROSC

to name the DD to which final ROSCOE data sets are to

be written: _ROSCDDN.ROSCOE, _ROSCDDN.RRTMPSE and the

_ROSCDDN.ROSCAWS "important" data sets. Less important

data sets ROSCOAUD, ROSCOSHU, and ROSCOVPE are left in

the work file.

Thanks to Terry Trevier, Naval Construction Battalion Center, USA.

Change 05.169 The SMF interval recording INTERVAL variable was read

Dec 15, 1987 with TODSTAMP8. (an IBM TOD datetime value) instead of

VMAC90 with MSEC8. (a TOD time value). As a result, it was

printed as -525935 hours and 25 minutes - the correct

number of hours backwards from 01JAN1960 (SAS's zero

datetime) to 01JAN1900 (IBM's zero datetime).It now

will correctly print 00:30:00 for thirty minutes

Thanks to Shawn Wikle, Citibank South Dakota, USA.

Change 05.168 The %%INCLUDE which should have been %INCLUDE now is.

Dec 15, 1987

VMXGVTOC

Thanks to Chuck Rexroad, Perpetual Savings Bank, USA.

Change 05.167 The NETSPY support (Change 5.164) was written with no

Dec 15, 1987 knowledge that Duquesne provided sample SAS code with

ANALNSPY the product. With Duquesne approval, NETSPY support

EXNSPYAP now uses almost all of their variable names, so as to

EXNSPYLU preserve any reports you might have already written.

EXNSPYLI The MXG data sets created are different than in 5.4:

EXNSPYNC NSPYAPPL, NSPYLINE, NSPYLU, and NSPYNCP are now the

VMACNSPY four data sets created. Exits EXNSPYSE and EXNSPYTE

were deleted and EXNSPYLU and EXNSPYLI now exist. Data

from NETSPY 3.0 has now been tested. The default PROC

PRINT reports from Duquesne's sample are in ANALNSPY.

Thanks to Andy Schoentrup, Public Service of Indiana, USA.

Thanks to Luis Motles, Duquesne, USA.
==========Newsletter ELEVEN printed changes through 5.166=============
=============Changes thru 5.166 as of Nov 24, 1987 ==================
Change 05.166 The monthly MXG job can cause lots of tape mounts and

Nov 24, 1987 rewinds when a SAS DATA step writes multiple data sets

MONTHBLD to tape (SAS is preventing duplicate named data sets).

this change is a circumvention which writes the new

data sets first to a temporary disk file, but by using

a DDNAME starting with TAPE...., the data set is built

in "SAS tape format", which can then be copied from

the temporary disk file to the monthly tape with an

INFILE/FILE pair, which eliminates the rewinds. The

temporary TAPETEMP file only needs to be as large as

the largest single data set to be created. See the

code and comments in this member and MXG NL ELEVEN.

Thanks to Susan Marshall, SAS Institute Europe, GERMANY.
==========The 5.4 Pre=Release included changes through 5.165=========
Change 05.165 This change will not affect many sites. It will be

Nov 22, 1987 needed ONLY if you receive the "Compiler Limit is

XMAC7072 Exceeded" error message from SAS on the SAS log.

XMAC71 This error does not occur with BUILDPDB unless you

XMAC73 have added many other SMF records with the PDB Exit

XMAC74 facility. (Only the world's largest PDB builder has

XMAC75 encountered the problem). The compiler limit problem

can not be fixed by SAS until Version 6, but we have

several circumventions available. The compiler has

a 4K table (cannot be expanded, thats the problem)

which sets an upper limit on the number of "Iterative"

DO statements (i.e., DO I=1 to something, DO WHILE,

DO UNTIL, but not DO groups like IF x THEN DO which

predominate in MXG code). There is an upper limit of

99 "Iterative" DO statements in a data step, but the

4K table is used by other SAS statements. The default

BUILDPDB has an actual upper limit of 56, but the MXG

default SMF record proccssing macros only use 24.

These new members are MVS/XA-only copies of their

corresponding VMAC.... member. By stripping out the

MVS/370 code, we reduced the number of "Iterative DOs"

these members would consume. This is only a temporary

solution. In our next version, we will begin to employ

the "new" SAS macros and will dynamically select the

MXG code which will be passed to the compiler, which

should stave off any compiler limit long before SAS

Version 6 is available on mainframes.

Thanks to David Daner, Sun Company, USA, USA.

Change 05.164 Support for the Duquesne network monitor NETSPY user

Nov 22, 1987 SMF record was added. Data for Release 2.3 and 3.0 has

EXNSPYAP been tested, but this still is our first support. s

EXNSPYNC Data sets NSPYAPPL, NSPYNCP, NSPYSESS and NSPYTERM are

EXNSPYSE created; member IMACNSPY sets the SMF record ID.

EXNSPYTE

IMACNSPY

TYPENSPY

VMACNSPY

Thanks to Chuck Hopf, Dean Witter Reynolds, USA.

Change 05.163 Pre-release code for Candle's EPILOG 100 SMF data. The

Nov 22, 1987 MXG redesign of the SAS code provided by Candle has

EXTYEPIL not been tested with data. Only one data set is now t

IMACEPIL created, but this may be changed once real data volume

TYPEEPIL and data structure is known. Call for status before

VMACEPIL you execute this code.

Change 05.162 New member IMACPDB externalizes MXG code which was in

Nov 20, 1987 BUILDPDB/3. The control of the NODUP option, and the

BUILDPDB macro definitions for the MXG variables which will be

BUILDPD3 kept in the PDB data sets was moved to this member, so

IMACPDB that you can tailor PDB function in the IMACPDB exit.

UNLESS YOU HAVE MODIFIED BUILDPDB/3, THIS CHANGE WILL

HAVE NO EFFECT ON YOUR INSTALLATION. Only minor logic

changes were made in this relocation of code. The PROC

MEANS logic which SUMs, MINs, and MAXs variables into

PDB.JOBS from STEPS is now a macro (_PDBSUMS) defined

in IMACPDB, and two macros, _PDB26J2 and PDB26J3 (for

type 26 variables), replace the previous single _PDB26

definition.This is the first step in planned changes

to BUILDPDB to externalize variable selection and to

make user tailoring even easier. IMACPDB will be the

control point for these future enhancements. This is a

good time to say to the original suggestor of NODUP

logic, the formerly "unknown Australian",

Thanks to Phil Bailey, NRMA Data Processing, AUSTRALIA.
Change 05.161 Support for optional Hogan function code data for

Nov 20, 1987 Hogan System application transactions under CICS is

IMACICUS now described and implemented in this member.

Thanks to Chester W. Sutton, Sears Consumer Financial Corp, USA.

Change 05.160 Titles were cleaned up to be more descriptive, and the

Nov 19, 1987 (seldom needed) debug option TYPE110-4 is supported.

UTILCICS

Thanks to Pete Shepard, Ashland Oil, USA.

Change 05.159 ACF2 data for type "T" records has been debugged and

Nov 19, 1987 the pre-release's "congratulations, you found the

VMACACF2 untested code" message has been eliminated. Also, the

ACTFMTOD field is PIB4.2 and FORMAT TIME12.2 and

length 4, as it turns out to be only a time, not a

datetime.

Thanks to Pete Shepard, Ashland Oil, USA.
Change 05.158 CICS 1.7 monitor facility permits your installation

Nov 19, 1987 to EXCLUDE fields in the CICS type 110 records. It is

VMAC110 not my opinion that EXCLUDE is wise (almost for sure,

the variable you exclude will be the one you need),

but this enhancement provides support for CICS 1.7

transaction records created with the EXCLUDE option.

The instructions for using this MXG enhancement are

described by comments in member VMAC110. Search for

the string CICS1.7EXCLUDE (two hits).

Thanks to Dale Mattison, Shared Medical Systems, USA.

Change 05.157 IDMS Performance Monitor (formerly RTE) data can now

Nov 19, 1987 be processed from journal file with member TYPERTEJ as

TYPERTEJ well as from SMF file with member TYPERTE.

VMACRTE

Thanks to Jim Lawrence, Central and South West Services, USA.

Change 05.156 Type 24 SMF (JES2 SPOOL Transfer) records have now

Nov 18, 1987 been validated (and code corrected). SMF24CNT is PIB4.

FORMATS vice PIB1. Format MG024BC: new values for 'A0'X and

VMAC24 'C0'x were added. Format MG024SF: new values for '44'X

and '24'X were added. The value of variable SMF24EOJ

is always zero unless this is the last SYSOUT outgroup

of this job. In that instance, SMF24BCF will contain a

'..1.....'B ('20'X or '24'X), and only then will the

variable SMF24EOJ contain true End-Of-Job condition.

Thanks to John Dundas, International Flavors & Fragrances, USA.
Change 05.155 NETVIEW changes to original type 39 NLDM record were

Nov 18, 1987 not completely corrected by Change 5.57. SCS length is

VMAC39 actually 117 vice 118, because BINDCODE is PIB1. not

PIB2. This well documented change is with

Thanks to Mark Shephard, Dun & Bradstreet EBIC, ENGLAND.