COPYRIGHT (C) 1984-2021 MERRILL CONSULTANTS DALLAS TEXAS USA
MXG NEWSLETTER NINE
****************NEWSLETTER NINE*****************************************
MXG NEWSLETTER NUMBER NINE SEPTEMBER 30, 1986
Technical Newsletter for Users of MXG : Merrill's Expanded Guide to CPE
This newletter accompanies the production shipment of MXG Version 4.4.
The MXG Newsletter is available only to supported customers of Merrill
Consultants. Beginning with this issue, the newsletter will be printed
in this reduced size to fit in the MXG Supplement binder. All supported
customers will receive one copy of the binder when it is available. At
a later time, the actual MXG Supplement itself will also be sent to each
supported site.
I. DESCRIPTION OF ENHANCEMENTS IN MXG VERSION 4.
II. TECHNICAL NOTES
1. Considerations on where to execute MXG.
2. Affect of PARMTZ on CICS Monitor timestamps.
3. Use of the following colon operand.
4. Lower bound on uncaptured MVS CPU time?
5. Affect of increased RMF sampling rate.
6. 3800 print start and end can overlap.
7. TPX and PIE multiple session managers.
8. 3090 Expanded Storage access times.
9. Various impacting APARs and PTFs.
III. INSTALLATION INSTRUCTIONS FOR MXG
(See included table of contents)
COPYRIGHT (C) 1986 BY MERRILL CONSULTANTS DALLAS TEXTA
MXG IS A REGISTERED TRADEMARK OF MERRILL CONSULTANTS
I. ENHANCEMENTS AND CHANGES TO PREVIOUSLY EXISTING PRODUCTS:
1. Full Support for SAS Version 5 graphics and syntax.
2. BUILDPDB/3 will delete duplicate SMF data with NODUP option.
3. IMACPTF member handles three CICS 1.6 PTFs.
4. RMF 3.4 & MVS 2.1.7 support (Vector Processor and 3090 Architecture)
5. CICS 1.7 support for CMF type 110 SMF or CICS journal record.
6. DOS/POWER Version 2 expansion and new record types.
7. DISOSS Version 3 Release 3 Account record.
8. DB2 Release 2 Type 100-102 records.
9. VTAM SNA Type 50 SMF record.
10. RACF 1.7 Type 80 SMF record.
11. 3480 Tape statistics Type 21 SMF record.
12. ICF Catalog entries in Type 61,65, and 66 SMF records.
NEW PRODUCTS SUPPORTED:
1. New installation instructions for execution under CMS.
2. VM Monitor PERFORM, USER, and DASTAP records.
3. IMS Log processing and analysis into transaction record.
4. Landmark The Monitor for CICS VSAM record.
5. INFILE exit to process Landmark's compressed record format.
6. Cullinet IDMS Performance Monitor (formerly BST RTE) SMF record.
7. IDMS DC Log record analysis program.
8. ASM code to enable IDMS exit to write "MXG IDMS SMF" records.
9. NJE BDT Type 59 SMF record.
10. ROSCOE Response time monitor records.
11. RMF System Availability Management records.
12. JES2 Spool Offload Type 24 SMF record.
13. NPDA type 37 SMF record.
The CHANGES section of this Newsletter provides some discussion of the
enhancements listed here, and identify the members of the MXG SOURCLIB
data set which operate on the listed data records. Additional
discussion will be found in comments in those members. Further
information on these new data sources will also be provided when the MXG
SUPPLEMENT is printed.
II. TECHNICAL NOTES
1. Considerations on where to execute MXG.
In principle, MXG code has always been executable under either CMS or OS
versions of the SAS System. Heretofore, our support/documentation only
instructed the user how to install MXG under OS SAS. In spite of that,
many sites with a system programmer who understood MVS, CMS and SAS have
had no appreciable problems installing MXG under CMS. Version 4 now
contains installation instructions for MXG under either version of SAS.
Once installed, MXG will process whatever data presented to it.
In MVS, IBM provides a utility program (the SMF dump program) to copy
VSAM SMF data to a BSAM file which can be transported to any SAS
program. SAS can also read the undumpded (VSAM) SMF file and could be
used to create the transportable file as well.
In VM, the user had to write their own specialized "VM dump" program,
(or purchases IBM's VM MAP program), to create a transportable file of
VM monitor records to be processed by SAS. Beginning with SAS version
5.12, the new INFILE exit named MONITOR (added by SAS Institute at our
request), allows SAS to similarly create a transportable file.
With MXG Version 4 and SAS 5.15, either MVS or CMS data can be processed
under either the CMS or VMS versions of SAS. The real question becomes:
is one more appropriate than the other?
Without sounding like an MVS bigot, MVS is significantly better than CMS
in managing job streams to build and maintain SAS data bases, especially
in the areas external to SAS (catalog management, tape management,
physical data set location, data center operations, interfaces for ABEND
conditions, etc.). Preliminary benchmarks also show that processing
large volumes of data under CMS is significantly more CPU-expensive than
creating SAS data bases under MVS. CMS was never designed to process
the 80 million bytes of SMF data each day from a 3081 - that is clearly
a "batch" process, and MVS batch processing will always, always, be
cheaper and more efficient than any other processing mode. However, the
SAS runs are made in the late hours when the processor normally is idle,
these added CPU costs may be of no concern. Once the SAS data libraries
have been built, however, accessing SAS data bases under CMS is as
suitable as accessing them under TSO.
The real choice of where to execute MXG becomes an installation choice,
which is likely to be influenced by personnel preference, by the ease
with which data can be transported, etc. I think most sites with both
CMS and MVS will find it cost justified to maintain a SAS license for
both operating systems, to decode the raw data in the creating host, and
then transprort SAS data (rather than raw data) to a common performance
library for both MVS and VM systems. The cost of the second SAS license
may well be balanced by the elimination of VM MAP monthly charges.
2. Affect of PARMTZ on CICS Monitor timestamps.
The internal time stamps (STRTTIME, ENDTIME) in the CICS Monitor
Facility record type 110 are directly affected by the value of PARMTZ
(in SYS1.PARMLIB member PARMTZ), which sets the delta time between GMT
and LOCAL time zones. Syntax of W,00.00.00 sets both clocks to LOCAL.
CMF uses the GMT clock, so that if PARMTZ is non-zero, the CMF
timestamps will be hours different from SMFTIME. The difference can be
even worse if console operators change clocks; the SET GMT clock also
changes the LOCAL clock, but SET LOCAL clock does not change the GMT
clock. MORAL: PARMTZ should be W,00.00.00
3. Use of the following colon operand.
In dealing with data sets with many variables (like DB2 and VMON), don't
forget the SAS syntax to easily select some variables for printing using
the colon operand. PROC PRINT DATA=DB2STAT0; VAR QB: ; will cause
only variables starting with QB to be printed.
4. Lower bound on uncaptured MVS CPU time?
One site has noted that the PCTOVHTM in RMFINTRV is about 27% when
MVS/XA is well tuned, but that higher values indicate either a lack of
tuning, or that excess capacity exists (i.e., low utilization effects
cause the higher uncaptured CPU time. After each new release of MVS
over the past 8 years, the PCTOVHTM jumps up to 33-38% in the early
weeks, and as the release settles down, the PCTOVHTM settles down to
27%, and was never less.
5. Affect of increased RMF sampling rate.
One site decreased the RMF interval so that the record write rate
increased from 1 per hour to 12 per hour and inadvertently increased the
sample rate. PCTOVHTM (uncaptured CPU) increased from 27% to 33%, and
PCTCPUBY increased from 93% to 99.9%. When the sampling rate was
decreased back to the original rate of 1 per second, overhead returned
to the 27-28% range, even though 12 times as many records were being
written.
6. 3800 print start and end can overlap.
The PRINTIME and PRENTIME variables in TYPE6 can overlap on 3800's. The
Print Endtime (PRENTIME) is not timestamped until the print file is
moved to the stacker, but the next file printed on the same 3800 printer
shows a Print Startime (PRINTIME) earlier than the end of the previous
print file. A JES Display command will often show 2-3 different jobs
active on the same 3800 printer!
7. TPX and PIE multiple session managers.
Sites with multiple session managers TPX and PIE have observed that
TPX - Requires multiple TSO IDs to multi-task. (You log on to TPX
ASID which then passes you to APPLID). Since it is an extra
ASID, a page fault in the TPX address space WAITS all users.
TPX, therefore, probably should be Storage Isolated.
PIE - Is its own TMP, attaches TSO, and can thus multi-task TSO
functions. A pass thru to CICS will cost two swaps, a
Detected Wait Out, then In.
8. 3090 Expanded Storage access times.
Some measurements of the 3090 Expanded Storage show the average access
time is 30-35 microsec, 60 microsec worst case with lots of activity,
and a 10 microsec minimum access per 4K block.
9. Various APARs and PTFs you may want to look up:
OZ78130 - DISP=MOD with IFASMFDP (SMF Dump program) sometimes does
OZ96195 not catalog 2nd or 3rd tape volume serial. You get an SVC
dump with the IFASMFDP execution, and the next MOD run
gives you an A13 abend.
OZ97886 - DFP 2.1 on 8603 counts only Demand Mounts in type 30
OZ97997 - RMF reports for virtual storage show time before start of
RMF interval. (This was one we found).
OZ83743 - 0C4 in SMF writer after 8603, records all wrong. PTFs are
UZ48891 (JBB2214), UZ48888 (JBB2110) or UZ48890 (JBB2133).
WSC Flash 8633-1 discusses DB2 CPU accounting changes in Release 2.