COPYRIGHT (C) 1984-2021 MERRILL CONSULTANTS DALLAS TEXAS USA
MXG NEWSLETTER ELEVEN
****************NEWSLETTER ELEVEN***************************************
MXG NEWSLETTER NUMBER ELEVEN DECBMBER 15, 1987
Technical Newsletter for Users of MXG : Merrill's Expanded Guide to CPE
This newletter accompanies the production shipment of MXG Version 5.5.
The MXG Newsletter is available only to supported customers of Merrill
Consultants. An "MXG Newsletter" binder, similar to the binder for the
MXG Supplement, will be sent to your site early in 1988 to hold your
site's newsletters.
We thought that 100 pages of MXG Newsletters would fit with the 500
planned pages of the Supplement in its binder. The Supplement's 630
actual pages absorbed our planned excess capacity!
I. MXG SOFTWARE VERSION 5.5 page 2
II. 1988 ANNOUNCEMENTS page 3
III.TECHNICAL NOTES
1. HOT PTFs: MVS page 4
2. HOT PTFs: VM
3. Technical Notes, MVS page 5
a. Counting allocated tape drives.
b. I/O Counts in TYPE70 and TYPE78IO.
c. SMF TYPE64 (VSAM I/O) counts.
d. CPU and I/O measurements when writing tapes.
e. More EXCPs in 30's than in 4's and 34's.
f. More CPUTCBTM in SMF than in RMF for a step.
g. MVS 2.1.7 page data set allocation size.
h. Use STEP data for job ABEND analysis.
4. Technical Notes, VM page 8
5. Technical Notes, SAS page 9
a. Eliminating tape mounts for SAS tape data libraries.
b. SAS ZAPs which you should install.
COPYRIGHT (C) 1987 BY MERRILL CONSULTANTS DALLAS TEXAS
MXG IS A REGISTERED TRADEMARK OF MERRILL CONSULTANTS
I. MXG VERSION 5
This newsletter accompanies the shipment of MXG Version 5.5, the
Production MXG Version 5, which contains the following enhancements:
1. MVS 2.2 support.
- New type 36 ICF Export/Import SMF record.
- New type 41 Data-In-Virtual SMF record.
- Changes in existing SMF/RMF records.
2. VM/SP Release 5 support.
3. SAR Accounting record support.
4. SAR Type 6 record support.
5. DASD storage measurement system (dynamically read all VTOCs).
6. IDMS 10.1 Performance Monitor record (new data sets) support.
7. ACF2 user SMF record support.
8. DB2PM validation and reports.
9. IMS log processing re-designed and supported for IMS 2.1.
10. STOPX37 user SMF record support.
11. RMF Cache Reporter validation and enhancement.
12. CICS 1.7 cleanups, enhancements, and more decoding.
13. DFSORT Release 9 support.
14. VM/Monitor summarization.
15. Vector Processor measurement.
16. TYPE64X data set for VSAM extents.
17. SYSLOG JES3 processing and JES2 SYSLOG example.
18. EDP Auditor Reports from RACF type 80 data.
19. Eight CPU engine (3090-800?) C.E.C. Support.
20. Online Business Systems WYLBUR Accounting SMF record support.
21. TSO/MON Version 5.1 support.
22. Extended Storage measurement enhanced.
23. 3480 tape drive error counting in TYPE21 added.
24. Separate counts of 3420 and 3480 tape drives in type 30 and PDB.
25. VSAM VVR Type 60 record decoded.
26. NETVIEW modifications to NLDM record supported.
27. RMDS support.
28. SYNCSORT user SMF record support.
29. CINCOM SUPRA log record support.
30. VM Account LOGOFF record support.
31. ROSCOE 5.5 SMF Account record support.
32. IMF 2.3 support for DDNAME level I/O counting.
33. NETSPY support.
34. OMEGAMON EPILOG 1000 support.
35. Externalized BUILDPDB macro definitions in IMACPDB.
36. HOGAN FPS transaction function code data support.
37. CICS 1.7 EXCLUDE option "support".
38. IDMS Performance monitor from IDMS journal file supported.
39. Landmark's SPECIAL 78 zap (adds CICS 1.7 MRO fields) support.
40. Naming conventions established for MXG's use of "New style" macros.
41. Elimination of excess tape mounts for monthly and weekly jobs.
Four MXG Version 5 pre-releases, in July, August, October and
November, were tested by more than 150 sites; their feedback was
invaluable in the quality assurance of the production release.
POTENTIAL COMPATIBILITY EXPOSURES BETWEEN MXG 4.4 AND MXG 5.5:
1. The aggregation interval of RMFINTRV data set was relocated in the
new member IMACRMFI, instead of being defined inline.
2. VM/Monitor users must read Change 5.133. The meaning of VMONDEV data
set variable CNTVIOCT was altered. A new macro, _INTRVL, defined in
IMACVMON, sets the expected record interval of your VM/Monitor. The
MXG default of one minute is now used to detect user logon events.
3. BUILDPDB/3 users who wish to tailor the PDB data sets will no longer
have to make internal changes; all PDB macros which control the PDB
data sets were externalized into member IMACPDB.
II. 1988 EXPECTATIONS
IBM announced plans for operating system changes next year which will
likely require changes to MXG software. IBM dates given below are the
availabilty date in the IBM announcement. We always hope to provide
MXG support by availability date, if we can get both documentation and
test data in time. We will likely repeat the strategy of the past two
years: a spring newsletter to announce when the pre-release of the
next MXG version is available, and a production MXG version shipped to
all customers in the fall.
a. March, 1988. Expected availability of VM/XA SP1, with a complete
new set of monitor records, new format, and zero compatibility with
current VM/SP VM/Monitor data. IBM says there will be no VM MAP for
this new VM/XA monitor, but MXG will be there.
b. May, 1988. PTF to MVS 2.2 which adds VIO activity fields to TYPE71
data (this PTF permits VIO to be directed to Extended Storatge).
c. Unknown. PTF to add JOB and READTIME which IBM left out of the new
MVS 2.2 Type 41 (Data In Virtual) SMF record.
d. December, 1988. Expected availability of VM/SP Release 6, with many
new data elements added to existing VM/SP VM/Monitor. This release
includes the new VM Shared File System, which creates new data.
e. Unknown. We expect to enhance MXG to support the PDL data written by
the FACOM OSIV/F4 MSP operating system.
f. Unknown. Other rumored impacting events may be CICS 2.1, a new DB2
release, and DOS/VSE Power record changes.
III. TECHNICAL NOTES
Note: The PTF or APAR numbers were provided by some system programmer
who has actually installed this fix, but sometimes the number will no
longer be valid; IBM supersedes and replaces PTFs, and one APAR often
has several PTFs for the same logical problem. Use this information
only to search INFO/MVS for more information and exact status.
1. HOT PTFs: MVS:
MVS 2.1.7 PTFs OZ44728 and OZ92196 appear to finally solve the long
outstanding constraint that the SMF interval (for type 30s and 32s) had
to be greater than JWT. These PTFs apparently are already in MVS 2.2,
and the documentation still recommends that the Interval duration be
greater than JWT, but experimental system programers have reported that
that recommendation is no longer a requirement. Don't take my word on
this, but I think it's probably true.
A new PTF (only for MVS 2.2 and later) finally allows you to specify
BLKSIZE of the SMF data. Requested through SHARE in the CME project in
1973, it has finally been acknowledged in APAR OY07209 and implemented
in PTF UY12002.
MVS 2.1.3 and 2.1.7 do not write type 7 records when SMF recording is
lost! Fix is PTF UY12608.
For 3090-400s, 300s, and 600s with 128MB real memory, there are lots of
performance problems if you do not install OY01085. Your CE should
have caught this one for you. MXG NL TEN misprinted this PTF number.
2.HOT PTFs: VM:
Concatenated MACLIBs on different mini-disks will fail; only the first
MACLIB in the concatenation will be searched until PTF VM24283 is
installed. As long as the MACLIBs are on the same mini-disk, there is
no problem with concatenation (as suggested for the MXG SOURCLIB and
USERID SOURCLIB libraries).
3.TECHNICAL NOTES, MVS:
a. Counting allocated tape drives.
The following is a revision of a note originally in MXG Newsletter TEN:
Counting of tape drives (TYPE30_4 or PDB.STEPS variables TAPEDRVS,
TAPE3420 and/or TAPE3480) is affected if the job step dynamically
allocates tape drives. For example, DB2MSTR dynamically allocates a
drive every time the recovery data is backed up. If each allocation
happens to get a different tape drive, the step record for DB2MSTR
would contain a different DEVNR (old UCB address) for each tape, which
MXG would count as a large number of tape drives. Only a few jobs
actually use dynamic allocation (thank goodness), but they tend to be
long running DBMS, which wreak havoc on the number of tape drives
perceived by ANALTAPE to be in use. You must use the type 40 (Dynamic
Allocation) record to find those jobs that dynamically allocate tape
drives, and exclude their step records before processing STEPS with the
MXG ANALTAPE program. Otherwise, it will appear the job step had all
those tapes for the entire time the step executed.
You can use the MXG Exit Facility to add type 40 processing, and in
the exit (EXTY40) and use:
IF DEVICE='3420' or DEVICE='3480' THEN OUTPUT TYPE40;
to only create observations for tape devices.
VMAC40 reads in a 40 and calls VMACEXC1, which decodes DEVCLASS,
DEVTYPE, and DEVNR for each UCB segment. VMACEXC1 then calls
VMACUCB to decode DEVCLASS and DEVTYPE (hex) into DEVICE (char);
the value '3420' or '3480' is set for tape devices.
Since SMF offers no option to create type 40's just for tape, you
still have to create all type 40 records, but this use of the EXTY40
exit allows you to keep only tape observations in TYPE40.
b. I/O Counts in TYPE70 and TYPE78IO.
The MXG Supplement noted that the I/O Interrupt Counts in TYPE70 were
observed to be greater than the 3090 IOP I/O Activity in TYPE78IO. It
was pointed out that IBM notes (in LY17-5500) that both TYPE78IO and
TYPE70 count SSCH (i.e. SIOs) and RESUMES, but that TYPE70
additionally counts PCIs, Device End following Channel End, and
Unsolicited Interrupts. The difference has been seen as 12-14% more in
TYPE70. Is this a useful indicator of anything?
c. SMF TYPE64 (VSAM I/O) counts.
VSAM counts (EXCPs, SPLITS, etc.) in type 64 records are wrong if the
VSAM file is concurrently opened. These counts are the "change since
open". Four jobs which concurrently opened the same VSAM file and then
read 9000 blocks, showed 9000, 18000, 27000, and 36000 EXCPs in their
type 64 records. The type 30 SMF record EXCP counts are correct. The
type 64 record has always been this way; only recently did a user
investigate the data. MXG will be enhanced to de-accumulate TYPE64
data, as ANALDSET does to de-accumulate TYPE1415 data. You could find
a CASPLIT count in a type 64, but the actual split may have been caused
by a separate job. You must sort all accesses to the same VSAM file by
open time and examine the end time for potential overlap and perform
you own de-accumulation.
d. CPU and I/O measurements when writing tapes.
In creating tape copies of MXG Version 4.4, we used SYNCSORT's free,
fast BETRGENR replacement for IEBGENER. Since BETRGENR copies one
cylinder at a time, the 833 blocks of 6160 bytes each required only 11
Start IO's, each SIO transferred 550KB of data in .44 seconds (you can
hear the voice coil humm that long), but there was then a delay of
about .6 seconds for the next SIO to commence (again, heard at the tape
drive). As a result, while the channel capacity is 1.25 MB/sec, even
with the transfer of 550KB per SIO, the effective channel capacity was
only 550KB/sec, or only 44% of IBMs stated capacity. This was in a
dedicated processor with no other work in progress.
Furthermore, this was for a single copy of the MXG library. The actual
data transfer took 11 seconds for the 11 SIOs, but the physical loading
of the tape, the swap in to reply (tapes are NL) and the rewind and the
unload time total just about one minute elapsed time. Because we were
waiting on the computer (THE definition of bad response) we allocated
more tape drives and found that with two tape apes (us), and four tape
drives, we could create 100 tapes per hour. Increasing the tape drive
count to six drives increased our production to 163 tapes per hour.
Note at this rate of 163 5.5MB tapes written per hour, the tape channel
was still only utilized at 250KB per second, or only 20% of the peak
transfer capacity. The peak-to-sustainable rate here was 5 to 1.
This should point up the fallacy of using the peak transfer rate (or
any peak rate) as a measure of capacity, without determining the actual
sustainable transfer rate. IEEE Computer magazine recently had a good
discussion with regard to the ratio between peak mega-flop rate and
achievable mega-flop rate on super computers, reporting typical ratios
also in the 5 to 20 range.
Each job executes 255 copy steps. All steps except the first recorded
.40 or .41 TCB seconds and .03 SRB seconds on a 3090-200. With 5.5MB
of data per step, this 13 MIPS (speed) processor is moving data at 13.4
MB per second. This is quite close to the one byte per one instruction
rate first noted on page 842 of the MXG book!
The first step of each job, however, required 1.06 TCB seconds and .06
SRB seconds, or 1.12 total CPU seconds apparently because the CPU time
for operator response to allocation recovery is captured in the step.
Each job enters allocation recovery because its specific UCB address is
offline at job initiation. The IEF244I - "Unable to allocate" message
set up the IEF238D - "Reply Device Name or Cancel" WTOR and the
R,99,181 reply apparently records .68 CPU seconds in the step record.
(The job which specifies VOLSER=MXG181 allocates UCB 181. NL tapes are
built so only one mount is needed, but require a reply to confirm the
VOLSER. With the UCB in VOLSER, the reply is fast and accurate.)
e. More EXCPs in 30's than in 4's and 34's.
Several sites have noticed approximately 10% more EXCPs are counted in
the type 30 subtype 4 (TYPE30_4 data set) record than the EXCPs in the
step type 4 (or type 34) for the same step. The type 30 is correct,
and the additional count in type 30 is due to the EXCP count to dynamic
allocations, which are captured in 30s but never were captured in the 4
or 34 records. As described on page 628 of the MXG book, if you used
4s or 34s, you had to use the 40s also. This is only one more reason
why the type 30 SMF record has (since 1978) always and all ways been
better than the type 4/34 records. It's even worse for the 4s and 34s
now. In MVS 2.2, IBM turns on a new flag bit in 4s and 34s to tell you
that the EXCP data on this step is incomplete in the 4/34 record and
you must use the type 30 for this step. (This happens for any step
with more than 1651 DD cards). STOP USING 4's and 34's! (MXG's
BUILDPDB has always used only type 30s.)
f. More CPUTCBTM in SMF than in RMF for a step.
Step termination data shows that the SMF CPU TCB time in the SMF type
30 can be slightly greater than the RMF CPU TCB time in RMF service
units in both the SMF type 30 and the RMF type 72 record for that step.
The step recorded 8.13 CPUTCBTM seconds in TYPE30_4, but CPUUNITS in
the step record (converted to CPU seconds) showed only 8.08 seconds.
This step executed in a unique performance group, and the TYPE72
CPUTCBTM was also 8.08 seconds for the interval in which the step
executed. This is not statistically significant, but an IBM expert
suggests this occurs because RMF gets it service unit values
(CPUUNITS,SRBUNITS) from the job data during step termination. This is
why the CPUUNITS in the type 72 data matched. However, after the
service units have been passed to RMF, the job is still in termination
and the SMF clock is still accumulating true CPU time for the step.
The extra CPU time recorded in the SMF step record may be due to SMB
processing (putting those termination messages on your SYSLOG listing)
or it could be installation code executing in SMF exits (perhaps to
print the job costs on the "banner page" in SMF exit IEFU83 or IEFU84).
At this site, there appears to be a fixed cost of .05 TCB seconds per
step termination which is not recorded in the TYPE72 CPUTCBTM, but
which is recorded in the TYPE30 CPUTCBTM. Even at 1000 steps
terminating each hour, this would be only 50 additional TCB seconds
for each 3600 seconds, or only about one percent.
g. MVS 2.1.7 page data set allocation size.
The Contiguous Slot Allocation algorithm, the very efficient way of
transferring up to 30 page frames contiguously with one SIO and with
minimal arm movement, was introduced for page data set I/O with MVS/370
SP 1.3 in the late 70's. Recently, several authors have concluded that
the algorithm will perform well only if the maximum number of slots in
use is less than 25% of the slots allocated. When the page data set is
full, the algorithm can not perform well, because it can not find
contiguous free slots. This greatly increases the search time, which
can negate the positive performance of the algorithm. For MVS/370
VSCR, IBM had recommended minimizing the number of slots allocated to
relieve MVS/370 VSCR because a small amount of CSA is used for each
slot allocated. With only 50K-60K virtual storage saved, real paging
is likely a more serious problem, and thus a larger page data set
allocation may still be advised. In early MVS/XA there also was a real
problem with large page data sets causing excessive seek times, but
that design error was fixed in MVS 2.1.2. You can use the MAXUSED and
SLOTS variables in TYPE75 to see if you might have a problem, and could
plot the percent used versus the service time (AVGRSPMS from TYPE74)
for each paging volume to confirm its real impact. It is clear that an
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).
4. 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.
5. 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 data
library, SAS rewinds to the beginning of the tape, and searches for the
desired data set name to be read.
When a SAS DATA step writes a SAS data set to a tape data library, the
tape is first rewound to the beginning of the OS tape dataset, and SAS
begins searching for the data set name to be written:
i.e., if currently on vol 4 of a multi-volume tape data library, SAS
will rewind and dismount vol 4, mount vol 1, read and dismount it,
mount vol 2, read and dismount, etc, until it gets back to where it
physically was, and then SAS writes the SAS dataset at the end of the
existing tape, if no matching SAS dataset was found in the library.
If a match is found, SAS starts writing the new data set where
the old one was found, ERASING ALL OTHER DATA SETS physically 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 multi-volume, the above problem of
mounts, dismounts and rewinds will elongate run times, whenever SAS
DATA steps are used to 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 SAS "tape format" originally was created just by using a
DDNAME that started with "TAPE....", but now LIBNAME TAPETEMP V6SEQ;
syntax is used to create the Sequential Format, which is required 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,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))
LIBNAME TAPETEMP V6SEQ;
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.