COPYRIGHT (C) 1984-2021 MERRILL CONSULTANTS DALLAS TEXAS USA
MXG NEWSLETTER THIRTEEN
****************NEWSLETTER THIRTEEN*************************************
MXG NEWSLETTER NUMBER THIRTEEN JAN 20, 1989
Technical Newsletter for Users of MXG : Merrill's Expanded Guide to CPE
This Newsletter accompanies the production shipment of MXG Version 6.6.
I. MXG SOFTWARE VERSION 6.6
1. The thirty-seven major enhancements in MXG Version 6. page 2
2. Installation instructions. page 3
3. Compatibility considerations. page 4
4. Documentation. page 5
II. ADMINISTRATIVE ANNOUNCEMENTS
1. "CPE Reporting System" tape to be sent to you by SAS. page 6
2. MXG Software default media. page 6
3. MXG Newsletters are now "online". page 6
4. 1989 Planning. page 7
III.TECHNICAL NOTES
1. HOT PTFs: MVS page 8
2. HOT PTFs: VM page 8
3. Technical Notes, IBM page 8
4. Technical Notes, MVS page 9
5. Technical Notes, VM page 12
6. Technical Notes, SAS page 15
IV. Change log. page 16
Changes through Change 6.206 - 6.058 thru page 46
COPYRIGHT (C) 1989 BY MERRILL CONSULTANTS DALLAS TEXAS
MXG IS A REGISTERED TRADEMARK OF MERRILL CONSULTANTS
I. MXG SOFTWARE VERSION 6.6
The Production release of MXG Version 6 is MXG 6.6, January 15, 1989.
The library is at Change 6.206, and MXG 6.6 produces 552 datasets with
18048 variables from its 911 members, and creates 151 SASLIB formats.
1. The major enhancements in MXG Version 6.
a. Support for the documented MVS/ESA changes in SMF and RMF records.
SMF changes include JESNR changes in SMF 6, 26, and 30 records now
that up to 99999 JES numbers are allowed. This caused several
changes in SMF data. The change was needed by IBM because lots of
sites found the 9999 job limit was eaten up by jobs left on spool!
The old 4-byte JESNR field will be zero and the JESNR will be in the
JCTJOBID field instead, which could affect your installation's JES
mods, if they used the old 4-byte JESNR instead of JCTJOBID. The
MVS/ESA support includes RMF 3.5, RMF 4.1.0 and RMF 4.1.1 changes.
b. Support for PR/SM changes to TYPE70 CPU measures. First,there is a
new TYPE70PR data set created by MVS 2.2's partition which describes
the processor utilization of all partitions (not just this MVS
2.2). Second, the TYPE70 CPU busy now uses the PDT partition
dispatch time to correct the MVS CPUBUSY and CPUWAIT variables.
(PR/SM puts zeroes in the old CPUWAIT field and stores partition
busy time in a new data segment). Third, read IBM's disclaimers in
the RMF User's Guide on what is and is not measured. Fourth, under
PR/SM you cannot know the actual hardware CPU busy of individual CPU
engines, but do get the overall activity of all engines. (If you
have Vector Processors this could be a problem, since you will no
longer know CPUBUSY for the CPU engine to which the VP is attached.)
c. VM/XA SP1 and SP2 Monitor support and reports (35 reports so far).
See extensive discussion below under Technical Notes, VM.
d. Support for DB2 Version 1 type 102 trace data records. Many DB2
reports similar in format to DB2PM are now produced by ANALDB2R.
e. Support for NPM 1.3 new type 28 SMF record. This record replaces the
type 38 (NPA/NPM), type 39 (NLDM) and VSAM VTAM Session statistics
(MXG's XNPMSESS) data sources. Twenty eight data sets are created
from TYPE28, all now start with NPM..... and a number of variable
names were changed. Member VMAC28 cross-references these changes for
your reports. Support includes Network Gateway Accounting too!!!
f. IMS log record processing was completely re-written (in MXG 6.4) to
capture individual transaction response, even for Message Switches
WFI (Wait for Input) programs. Prior MXG logic captured only program
schedule events (07 record), like IBM's DFSILTA0 utility. Separate
responses are measured for each transaction event, and TYPEIMS now
supports the IMS 2.2 log record format changes made by IBM.
g. Support for IDMS-R 10.2.1 Performance Monitor SMF records.
h. Support for IMF Version 2.5 has been added.
i. Support for NETSPY Release 3.1.
j. Support for EPILOG 1000 (CICS) Release 4.30.
k. VM/SP Release 4 and 5 Monitor validation corrections were made and
enhanced summary reports match VM MAP numbers better.
l. Goal Systems EXPLORE/VM records are now supported.
m. VPS (a SYSOUT handler) support in TYPE6 data set.
n. EXD (a SYSOUT handler) support in TYPE6 data set.
o. CA-DISPATCH (a SYSOUT handler) support in TYPE6 data set.
p. $AVRS (a SYSOUT handler) support in TYPESAVR data set.
q. Landmark Version 7.1 support.
r. CICS 1.7 UOWTIME variable decoded for the (undocumented) third data
format for both CMF and Landmark records.
s. Building MONTHLY PDBs using only one tape drive now always works.
t. Support for RMDS Release 3.0 SMF record.
u. ASMVMCOPY (assembly source) and REXXCOPY (an exec) permits a VM/SP
site to "dump" their VM/Monitor spool records to a CMS file. Without
this program, you either used VM MAPs MONTAPE/MONDISK command or you
used the SAS MONITOR INFILE exit to "dump" the VM/SP Monitor data.
v. Support for AIM database manager records from FUJITSU's FACOM OS.
w. Support for type 1, 127, and 234 records from FACOM OSIV/F4.
x. Support for SAS user SMF record (PROC/DATA step resources).
y. Support for CA-ROSCOE Release 5.6
z. Support for 3990-3 Cache DASD RMF Reporter (user) SMF records.
aa. Support for Duquesne's DASDMON SMF record.
bb. IDMS 10.2 exits 05 and 13 ASM code for TYPE200-203 MXG datasets.
cc. Support for Duquesne's TPX Session Manager SMF record.
dd. Support for SQL/DS VM/Account records.
ee. Support for STC 4400 Tape Silo SMF record.
ff. Support for HSM data records.
gg. Support for COM-PLETE SMF records.
hh. VSAM DASD measurement with ASMVVDS program to read VVDS and
create SMF data record for DASD management and chargeback.
ii. MXG Newsletters online in member NEWSLTRS.
ii. Initial implementation of the "fabled" MXG Trend Data Base
with examples of CICS, RMF, etc. weekly/monthly/etc trending.
All reported 5.5 problems have been fixed in this release.
See the Change log and read the comments in the referenced MXG
source member for complete details of these enhancements and changes.
2. Installation instructions.
Installation instructions are in Chapter 32 of the MXG Supplement.
(which are also contained in member INSTALL of the source library.)
However, since those instructions were written, MXG has expanded!
The SASLIB MXG format library must be re-allocated with the SPACE
parameter of CYL(1,1,99), because there are now 151 formats in this
library, and the original MXG Guide showed only 10 directory blocks!
The MXG formats are then created in the SASLIB PDS by the first step
of JCLTEST, which executes a PROC FORMAT. Unfortunately, if there is
not enough directory space, PROC FORMAT only prints a cryptic message
("STOW FAILURE") on the SAS log, and does not set a return code. You
will discover the actual error only later when you get SAS error 170
FORMAT NOT FOUND, when you run an MXG job that now needs one of the
MXG formats expected in SASLIB! (Actually, only 26 directory blocks
are currently required, but why not plan for the future with 99!)
Similarly, the allocation for SOURCLIB needs to be increased to the
present recommendation of CYL,(25,5,199) with the DCB parameter set
to RECFM=FB,LRECL=80,BLKSIZE=23440, (with 130 directory blocks used).
3. Compatibility considerations.
This library is a complete replacement for the Version 5.5 (or prior)
MXG.SOURCLIB data set. It is forward and backward compatible with all
data sources (eg., it still processes MVS/370 as well as new MVS/ESA
changed records.) The sooner you install it, the less likely you are
encounter an error condition which is fixed in this Version!
These are the known exposures which you must protect when you install
this (or any) new version of MXG. (Users report it takes a half-day.)
First, there MUST be no VMAC.... members left in your USERID. library
when you install a new MXG version. Since MXG uses %INCLUDE to pickup
its macro definitions, if you have a VMAC.... member in your library
concatenated ahead of MXG, you will not pickup the new MXG macro and
instead will execute a (probably modified) macro from a prior version
of MXG. In the past, some leading edge sites found it necessary to
make "emergency" changes to a VMAC.... member and had copied it into
their USERID library. Those VMAC.... members in your USERID.SOURCLIB
library MUST be removed when the new version of MXG is installed.
YOU SHOULD NEVER EVER HAVE TO MODIFY A VMAC.... MEMBER TO TAILOR MXG
TO YOUR SITE. The IMAC.... & EX...... members are designed to allow
ALL installation tailoring to be external to the VMAC.... members.
See the MXG supplement pages 134ff or call for help, but please avoid
storing VMAC.... members in your USERID.SOURCLIB library.
Second, BUILDPDB and BUILDPD3 must not be in your USERID.SOURCLIB, for
the same reasons as the VMACs. MXG Supplement pages 137ff show how you
can add new data sets or change their contents with the EXPDB... and
IMACKEEP exits.
Third, we create an unavoidable compatibility exposure to your MXG
system whenever we change an IMAC.... member that you have already
modified into your USERID.SOURCLIB library. YOU MUST compare the
following list of changed IMAC.... members with the members of your
USERID.SOURCLIB, and if the member exists in your library, you must
retro-fit your tailoring into a copy of our new IMAC.... member. The
change number(s) describing what we changed, as well as comments in
each member itself, should aid in your tailoring.
IMACs in MXG 5.5 Read Change Number
that were changed
IMACACCT 6.131
IMACCICS 6.148
IMACEPIL 6.091, 6.013
IMACICDL 6.044
IMACIMS 6.116, 6.053
IMACMONI 6.096
IMACPDB 6.129, 6.105
IMACRMDS 6.042
IMACSHFT 6.206
IMACs new in prerelease Read Change Number
that were changed.
IMACDB2T 6.103, 6.079
IMACEXD 6.084, 6.037
IMAC102 6.201
IMAC that might need Read Change Number
to be changes by you
IMACKEEP 6.148
New IMAC which should Read Change Number
be noted for impact.
IMAC30IO 6.129
You could see more observations in TYPE74 with MXG 6.6 than with 5.5.
Observations are now output only for non-zero values of the SIOCOUNT,
PCTDVUSE, or MOUNT variables; prior versions did not test MOUNT. The
addition of MOUNT captures tape devices which had mount pending but
no other activity during an RMF interval.
VM/XA processing now requires a new FILEDEF/DDNAME of INSTREAM, a
3-track temporary file, into which MXG creates SAS code which is
then %INCLUDEd to create the look-up table of device attributes for
VXIODDEV and related data sets from VXMTRDEV. The INSTREAM DD is
referenced only during building the VXIODDEV data set(s).
4. Documentation.
It was hoped that the Chapter FORTY style documentation of each of the
new data sets and their variables would be available coincident with
MXG 6.6. However, the choice was made to ship the software now and to
send the documentation as a (very large!) Newsletter later this year.
Member DOCVER06 alphabetically lists all NEW data sets and all NEW
variables which did not exist in MXG Version 5.5. Member DOCVER is a
complete list of ALL variables in ALL data sets built by Version 6.
Both members give the complete label, which is usually adequate for
initial use of the data. Since in most cases the field names of the
data source are used as the MXG variable names, the vendor's manuals
should not be overlooked for additional descriptions. Best of all,
build the new data sets with the TYPE.... member for a day's data, and
then PROC PRINT the first 50 observations, examining what values your
installation's data creates. PROC MEANS and PROC FREQ can also be very
useful tools in understanding the range of values and the frequency of
occurrence of the new data.
Finally, use member CHANGES to find all of the member names that are
associated with a change of interest, and then examine each listed
member for comments at the beginning of the member. Most of the new
data sets are initially described in their VMAC.... member, and the
associated IMAC.... may also contain specific comments on how to set
up MXG to process a particular data. When none of this helps, call!
II. ADMINISTRATIVE ANNOUNCEMENTS
1. "CPE Reporting System" tape to be sent to you by SAS Institute.
The CPE Reporting System (originally called the CPE Starter Set) is
a SAS/AF application which has been available free upon request from
SAS Institute. It was developed (primarily by Allan Russell, SAS
Technical Manager of SAS Institute's European subsidiary) in
Heidelberg.
SAS/AF gives end users (for example, your manager) the ability
to analyze, select, plot, and to apply the power of the SAS System to
SAS data sets through a series of screens and menus which
require no knowledge of the SAS language.
The CPE Reporting System is both an example of how to use SAS/AF and
a fine set of hourly, daily, and weekly reports of interest to
managers and CPE technicians alike. It contains a tutorial on its
use, and generates a wide range of reports from the MXG data sets
built from MVS (PDB.IPLS, PDB.JOBS, PDB.STEPS, and PDB.RMFINTRV).
It is easily extended to provide SAS/AF services for the analysis
of any data.
We are providing SAS Institute with our mailing list of supported
MXG sites, and shortly after you receive MXG Version 6.6 from us in
Dallas, you will receive your free copy of the CPE Reporting System
directly from the SAS Institute (or from your local SAS office).
2. MXG Software default media.
We announced our intention to change tape media default from 3420s to
3480s in Newsletter TWELVE, and included a return postcard if your
site could not accept 3480 cartridges, since the vast majority of USA
sites do have 3480s. However, at the request of our overseas offices,
we will continue to ship 3420 mini-reels to overseas sites, and will
send 3480 cartridges overseas only to sites who so request. The MXG
default media for the USA and Canada will remain 3480s.
3. MXG Newsletters are now "online".
The new member NEWSLTRS now contains the text of this and all prior
Newsletters. Not only will this (hopefully) eliminate your requests
for multiple printed copies of our Newsletters, but also it permits
you to BROWSE and search for technical information by computer! The
change log portion of each newsletter has always been contained in the
members CHANGEnn for prior MXG version nn, and in member CHANGES for
the current MXG version.
4. 1989 Planing.
a. The 3-day CPE class taught by Dr. Merrill will be offered in the
USA in February (preceding SHARE in Los Angeles), in October at
SAS in Cary, and in December (preceding CMG in Reno). SAS Cary
makes the arrangements for these courses. The course will also
taught in Paris in July (the 200th anniversary of Bastile Day!)
and also in England in late July. An Australian class is also
being planned adjacent to CMGA in September in Melbourne.
b. Things that did not get completed in time for Version 6:
- VM/SP Release 6 Shared File System Account Record.
- IMS Fastpath log record analysis.
- Tape mount monitor for MVS/XA.
- Chapter 40-style documentation for everything new.
c. MXGMENU - a statement of direction.
MXGMENU will be the interactive facility for the installation and
tailoring of MXG, for report selection and generation, and for the
management of the MXG environment. MXGMENU will be delivered after
SAS Institute releases a full function mainframe Version 6 of the SAS
System, probably in 1990. MXGMENU will take as its starting the
previously described "CPE Reporting System". MXGMENU will execute
PROC DISPLAY and will not require the site to have SAS/AF, but may
well motivate its acquisition. MXGMENU will exclusively use Version
6 SAS/AF features and Screen Contorl Language, and will execute on
the mainframe or the microframe.
For reporting, MXGMENU will publish and use a standard set of macro
names as tokens for selection and control, such as for Dates, Times,
Shifts, Jobnames, Transaction Names, User names, etc. Unlike the
present "CPE Reporting System", which carries most of its reporting
code inside the SAS/AF catalog, all of the report code used by the
MXGMENU will be in the MXG Source library. This will allow reports
to be produced directly in batch, TSO, or CMS, or from the MXGMENU.
(Standardization of MXG report tokens will also make it easier for
users to share and contribute reports!)
For installation tailoring, MXGMENU will interactively interrogate
the installer and then create appropriate definitions in IMAC....
members in the user's tailoring USERID.SOURCLIB library to override
MXG defaults. For example, you will be able to specify "MVS/ESA"
and thereby create only MVS/ESA (or only MVS/370, etc.) relevant
variables in MXG data sets. MXGMENU will also set up the sources
and summary levels of the data to be kept in the MXG Trend Database.
MXGMENU will be a free, intrinsic component of MXG Software.
III. TECHNICAL NOTES
1. HOT PTFs: MVS
MVS:
OY13794 NPM type 28 data invalid.
OY01945 SMF Buffer errors causing IEE979W message and data loss.
OY12066 SMF Buffer errors corrected. On 8805.
OZ97236 ACTJTIME only 3-byte storage for step CPU, can wrap if task
uses lots of CPU (this is an old problem, still unfixed).
OY06621 Type 41 JOB, PTF UY22185, UY20659, may need SYSGEN.
OY09186 VIO paging into ESTORE (RMF 3.5 and later).
OY15663 TYPE 64 VSAM EXCP counts are now accurate for shared VSAM.
CICS:
PL20996 CICS Clock gets ahead of MVS clock!
2. HOT PTFs: VM
VM:
VM27244 TAPPDS fails with virtual storage error message DMSTPD105S.
VM35321 VM/XA Monitor Scheduler record needs CPU address in record.
3. Technical Notes: IBM
The IBM Internal document titled "RMF Accuracy and Capacity Assessment
Under VM/XA" is currently available to your IBM SE thru PROFS under
the VM/XA SP Forum, but is supposed to become a real publication
soon. It is the best discussion of what happens to RMF data when you
execute MVS under VM I have ever read. It was written by Robert Youngs
of the IBM UK Chiswick Center.
The MVS/ESA SMF Manual is a new publication, GC28-1819-0. The EXCP
counting is clarified somewhat in Chapter 8, but it still fails to
discuss connect time measurements. Also, Chapter 9 expands CPU timing
discussion to include Vector Facility timing and adds more reasons why
CPU-time measures may vary from run-to-run.
4. Technical Notes: MVS
a. VSAM EXCP counting.
In October 1988, APAR OY15663 became available, which corrected the
VSAM EXCP counting problem in TYPE 64 SMF records. The following is
the problem corrected by that APAR, and thus will no longer be true.
The EXCPS variable in TYPE64 contains the change in EXCPs since the
VSAM file was opened by this job, but (some, none, all) of the change
may not be caused by this job. If the same VSAM file is concurrently
opened by four jobs that issue 9000 EXCPs each, their four type 64
records contain 9000, 18000, 27000 and 36000 EXCPS respectively, even
though 9000 EXCPs are properly recorded in the type 30 step data. It
does not even appear possible to write a de-accumulation algorithm for
type 64 records that will always be correct, and the counting problem
for multiple-opened VSAM files applies to the other variables (INSERTS
DELETES, etc.) which are calculated from changes in catalog counts.
Again, the preceding problem is eliminated with APAR OY15663.
b. DB2 Account data.
DB2 Account data sometimes contains a 0 value for beginning CPU time
and 23:59 hh:mm for the EJST ending CPU time when a plan abends, which
results in a large "measured" CPU time. Two sites have noted this flaw
but it has not been repeatable enough to get IBM attention.
c. NETVIEW 2.1.
NETVIEW 2.1 created type 39 (NLDM RTM data) records will have missing
data unless LOG=YES, SAW=YES, SETSTATS=YES (even though documentation
says NO) are specified in AAUPRMLP member of NETVIEW library.
d. ACTFRMTM in TYPE72.
The new TYPE72 variable ACTFRMTM, Active Frame Time is the number of
page-seconds of pages of Central Store (CS) and Expanded Store (ES)
that were owned by resident tasks in each performance group period.
The new TYPE72 variable PGPAGEIN, Pageins for this perfgrp period, can
be directly compared with Storage Isolation parameter PWSS which
controls the sum of CS and ES frames. The number of ES pages owned by
a performance group can be estimated by comparing ACTFRMTM (CS+ES)
with PAGESECS (CS only, calculated from MSOUNITS). However at the task
level in type 30, we can only get the count of CS pages from MSOUNITS.
In summary, type 72 contains CS and ES pages, type 30 has CS only.
e. IO Counting in TYPE70.
I had previously noted that IO's counted in TYPE70 are higher than the
count of IO's in TYPE78IO, but did not know why. LY17-5550 explains
the difference (typically 12-14% higher in TYPE70) is because the 70
counts SSCH's and Resumes (like 78), but the 70 includes PCI counts,
Device End following Channel End, and Unsolicited Interrupts.
f. CICS 1.7 EXCLUDE option.
One CICS 1.7 CICS Monitor Facility (type 110 data) user reported that
he tried to EXCLUDE ALL followed by INCLUDE specific transaction data
fields, but the unexpected result was that not only were CICSTRAN data
fields excluded, but also CICSYSTM global fields were also excluded
(except for fields 1-9 which appear to be always kept!). MXG supports
the use of EXCLUDE, but requires you to EDIT VMAC110 into your USERID.
SOURCLIB. (Find "EXCLUDE" in VMAC110 and follow the instructions.) IBM
has suggested most of the CPU overhead of CMF is in the capture of CPU
timings and Paging activity, which are usually important fields. If
your aim is to save space, make sure you calculate how much you can
save before you go to all this effort. A CICS 1.7 transaction is 336
bytes (CICS 1.6.1 was 186 bytes).With 1,500,000 transactions per week
CICS 1.7 would write 504MB of data per week, which would only require
a total IO transfer time (at 3MB per sec) of 168 seconds per week!
Remember that you can put the CICSTRAN data directly to tape with MXG
and keep all CICS detail data. When you read CICSTRAN to summarize and
measure response time, remember to use (KEEP= ... ) on both the DATA
and the SET statements to minimize SAS CPU costs and bytes moved.
g. SMF dump sample program.
The IBM sample program SMFDUMP, which automatically detects the active
SMF data set, dumps, switches, etc., without operator action, can be
found (currently!) in IPO1.SAMPLIB or with CBIPO in MVS Process Aids,
(T00616.SAMPLIB). See also member IEFU29 which will automatically
submit SMFDUMP when a MAN data set fills.
h. MXG execution and storage costs.
Analysis of CPU time to process SMF data into a SAS dataset suggests
that MXG requires 100 seconds to read each 400 MB of input SMF data,
and requires an additional 100 seconds for each 40 MB of output SAS
data libraries. Times are TCB+SRB on a 3090-400. One site with two
3081's and heavy workload reported that its total DASD requirements
for MXG online data sets (eight dailies, one weekly, 5 years RMFINTRV,
all MXG source libraries, etc.) was 350 CYL (250 MB) of 3380 DASD.
Triple density 3380AKs purchase for $25,000 per 1873 MB means their
250 MB was purchased for only $3216. They keep 3-years PDB (156
weekly, 36 monthly) on 192 3480 tape cartridges ($6.50 each) for
$1248. Total MXG storage cost is a one time $4464!
i. 922 Abend.
An MVS 922 ABEND can cause TYPE30 CPU times to be irrationally high,
and the record may be missing the IO, PROC, EXCP and STOR segments.
j. Large blocksize is good.
Yet another reminder why large blocksize for sequential data sets is
good. At 32760 blocksize a 3480 tape holds 215 MB, while at 4096 the
same tape can only hold 124 MB.
k. Sorting.
How much do we sort? One site with a 3090-300 and 3090-200 supporting
TSO (200 concurrent of 600 total user ids) issued 3550 sorts that took
19 hours of CPU time. SMF recorded 47 CPU hours in type 30s, TYPE70
recorded 55 CPU hours available. SORTs were 40% of the TSO load.
l. IMS log processing.
IMS log records can be separated (database recovery or performance) by
the DFSUARCO program control card COPY statement to write selected IMS
log records (see TYPEIMS) to a user defined DD. To print the DSECTS
of IMS log records, assemble ILOGREC TYPE=DSECT,RECID=ALL
Re-constructing an IMS transaction from the many different IMS log
records is complicated because there is no unique field which ties all
records together. The MXG algorithms were re-designed (largely by
Pete Shepherd) and then compared with Boole and Babbage's IMF data
records. Resources (CPU, DL/I calls) are always correct, and response
times are extremely close. If multiple transactions are processed by
a program schedule (eg., Wait-For-Input), there is only a single 07
log record written, with total CPU and DL/I calls. MXG divides these
resources across all of the transactions processed. As a result, you
might find fractional DL/I counts recorded for a transaction! The new
algorithms have been validated with IMS 2.1 and IMS 2.2 data and seem
robust, (as long as all of the records for a transaction are on the
IMSLOG tape presented to MXG). For IMS 1.3 data, however, it has been
reported that sometimes variables MLOGONID, ODEST, MODNAME, MTYPE,
LTERM, DEST, and/or LOGONID may be blank. If IMS is really the bread
and butter of your installation, you probably should not depend on us
to always be able to recognize transactions, and should lobby IBM to
enhance the IMS log records (like CICS's Unit-Of-Work ID field), or
should consider an IMS monitor that creates individual transaction
records, like IMF.
m. NJE impact on job time stamps for Batch Service measurement.
NJE sites tracking job service times note that the READTIME variable
is the time (at the originating node) when the JOB card was first
read, but the JRDRTIME (in each type 26 purge record) is the time (at
each node) when the job completed read-in at that node. The MXG
PDB.NJEPURGE data set may be useful in tracking job times. In the
PDB.JOBS data set, since MXG keeps only the purge record from the
actual execution node, the variable JRDRTIME will be the actual time
when the job arrived at its execution node, and thus the delta between
JRDRTIME to JSTRTIME will be the initiation wait time at the execution
node. (However, that wait will also include time the job spent in
hold, if any).
n. Clarification of contents of MXG variable CPUTM.
The variable CPUTM (in type 30 data sets, as well as in PDB.STEPS &
PDB.JOBS) is the sum of all four CPU measures captured at the step
level: CPUTCBTM, CPITCBTM, CPUSRBTM, and CPISRBTM. The equation has
never changed, but Chapter 40 in the MXG Guide incorrectly documents
CPUTM as the sum of only CPUTCBTM and CPUSRBTM. The MXG Supplement
correctly described CPUTM on page 366. Note that these CPI...TM
values (CPU time in the "initiator" or "privileged state") are not
captured in the type 72 RMF record (they are in the uncaptured CPU
time, see MXG Guide page 82 Fig 10.1 and MXG Supplement page 34). The
magnitude of these CPI "initiator" times is not typically very large
(eg. 13 hours out of a total type 30 CPUTM of 683 hours, 2%), but the
CPI time is directly attributable to the step and thus is included in
the CPUTM variable which should be used for both the chargeback and
the capacity measurement of processor utilization.
o. An important date: When DATETIME clocks wrap:
A date for your grandchildren. At 23:53:48 on Sep 17, 2042, the IBM
8-byte hardware clock will fill and reset to Jan 1, 1900.
With regard to the IBM clock date, it must be corrected by year 2011,
as the retention period for a cataloged tape volume can be as long as
30 years.
And it turns out the Open Systems wrap earlier:
The year 2038 problem ("Unix Millennium bug"), is UNIX result of
storing its system time as a 32-bit signed integer with the number of
seconds after the Unix/POSIX epoch time of midnight, January 1, 1970.
This value will roll over on February 19, 2038.
5. Technical Notes: VM
a. VM/XA Monitor description.
VM/XA Monitor creates many new data records in brand new format. The
CP MONITOR Command determines which domains, records, and which data
will be created in a DCSS. The new MONWRITE CMS command extracts the
data from the DCSS and writes the data to a CMS file which is read
directly by MXG to create the 75 VX...... detail datasets and 1300+
variables. The sample classes are sorted and build dataset VMXAINTV,
the primary interval analysis data set, and VXBYUSR, the machine by
machine interval analysis data set. The IBM documentation for the
records are in the Appendix of SC23-0370-1. The IBM field names for
monitor data are of the form of dddrrr_ffffffff; ddd is the name of
the Domain and rrr is the name of the record type in that domain and
ffffffff is the field name. MXG creates data sets named VXdddrrr and
whose variables are named ffffffff, so that (finally) there will be no
transformation between IBM and MXG nomenclature! This is a major new
addition to MXG which has been validated by a number of users.
Additional IBM documentation will be found in:
LY27-8058 - Features Summary, pp 478-482
SC23-0353 - Administration, pp 137-145.
SC23-0370 - CP Programming Services, pp 145-149, pp 237-421.
SC23-0354 - CMS Command Reference, pp 371-373.
SC23-0358 - CP Command Reference, pp 271-288.
LY27-8054 - CP Diagnostic Reference.
The current documentation of this major MXG enhancement is in the
comments in member VMACVMXA, CHANGES, and DOCVMXAF.
b. VM/XA Monitor known problems.
The following information was presented at SHARE in August and at the
Confederate CMG in October. The following problems have been observed
in VM/XA Monitor data:
1. Interval end time and interval duration are inconsistent.
a. 30 second interval request generates 30.1 second data.
b. MTREND data does not accurately represent collection interval.
Writing user data extended 6 second interval to 9 seconds in
MTREND, but actual delta varied by record from 6 to 9 seconds.
c. Must use individual record-to-record DELTATM for rates of data
in that record, but then a logic interval has many slightly
different durations.
d. ENDTIME should represent end of collection of interval but
each MRHDRTOD is slightly different.
e. MXG algorithm: Set ENDTIME as timestamp of first 0.1 (SYTSYP)
record, but use DELTATM of 0.2 (SYTPRP) as common DURATM of
interval, since SYTPRP contains CPU busy data. However, rates
from other records are built using individual record
DELTATMs.
2. CPU measurement is inconsistent or incorrectly documented
a. The sum of "user" PFXUTIME and "system" PFXTMSYS from SYTPRP
(0.2) is greater than "TTIME" from USEACT (4.3) data.
PFXTMSYS is not captured at the user level:
DWR1 DWR2 IBM1 HNET1 HNET2
SYSTEM: Total CPU: 873.94 12552.51 2700.70 874.00 125.18
PFXTMSYS: 92.38 2832.56 369.43 92.00 73.62
PFXUTIME: 781.56 9719.95 2331.27 782.00 51.56
USER: VMDTTIME: 773.94 9771.93 2341.12 774.00 51.56
VMDVTIME: 433.56 7483.90 1667.81 434.00 31.93
their diff: 340.38 2288.03 673.31 340.00 20.63
%captured
by user: 88.5% 77.4% 67.4% 88.5% 41.2%
b. In SYTPRP (0.2) the sum of PFXTMSYS+PFXTOTWT+PFXUTIME should
match DELTATM between records, but is as much as 24 seconds
short in a 900 second interval! LOSTTM variable in VMXAINTV
calculates the unaccounted time.
c. A small amount of user CPU time is always lost in the USER
data. CPU time used prior to the first interval record is lost
and CPU time used between the final interval record and the
user's logoff is not recorded.
3. Response time validation is erratic.
a. Controlled single-user experiment with one transaction in each
30 second interval with two long transactions (Copy 1MB file
from 2K "Q" to 1K "A" on same volume) clocked 51.99 and 52.20
at terminal and were measured as 51.96 and 52.12 by VM,
showing very good agreement for these two non-trivial
transactions.
b. However, the response time is recorded not in when the
transaction ended, but when the next transaction start is
recognized (two intervals later in this case!)
c. Logon and IPL CMS seemed to take 7.28 seconds but VM recorded
33.91 seconds.
d. Unexpected trivial transactions were counted because SMART was
also running. Assuming SMART response was near zero the
product of number*duration matches the measured trivial
response quite well.
e. The biggest problem with response measurements in VM/XA is the
actual definition of trivial itself. The Scheduler desires
that 85% of all transactions count as trivial. To make this
happen, the SRME1ETS elapsed time slice is adjusted from .5 to
5 seconds to ensure that (if possible) 85% are classified as
trivial! As a result, the CALMPTRV and CALUPTRV "Average
Trivial" response value is meaningless unless you also look at
the value of SRME1ETS. (MP and UP counts are intended to
separate Guests (MP) from CMS (UP) responses). Thus the value
of CALMPTRV and CALUPTRV are best described as "the average
response of those 85% of transactions that completed in the
elapsed time given by SRME1ETS". In fact, the value of
SRME1ETS may itself be a better measure of interactive
response, as long as it is less than its upper bound of 5
seconds! Detail comparison:
--Monitor Reported--
Action Stopwatch Non-trivial Trivial
sec avg nr avg nr
FILELIST .86 .44 2
XEDIT .74 .71 2
SAVE .74 .49 2
SCROLL .50 .48 2
END .72 .39 2
UNKNOWN CMD .72 1.12 1 .48 2
DISCONNECT .66 .35 4
LOGON .79 0 1
IPL 5.54 1.14 1 .72 4
FINISH CMS INIT 1.74 33.91 1 .49 1
EXEC DISK ACCESS 3.37 1.13 1 .51 1
FILELIST 1.26 2.51 1 .50 1
SORT .54 1.15 1 .53 1
COPY 1031 BLK .48 2
COPY completed 51.99 .49 1
no action .55 1
ERASE FILE .50 51.96 1 .47 1
COPY same 26391 rec .46 2
COPY completed 52.20 .48 1
no action .63 1
END .88 52.12 1 .51 1
QUERY DISK .80 .50 2
4. Scheduler records cannot be used for CPU measurement of Guests
which allocate more than one CPU (i.e., MVS). CPU time is
accumulated by CPU Address, but CPUAD is not in the SCHEDULE
domain records.
5. Some USER domain USEACT records show small VTIME with no TTIME.
6. Many fields are only two bytes, which wraps at 65536. An hourly
interval would lose data on any field with a rate greater than 36
per second, with no indication that data values were lost. Use
15 minutes or less for interval.
7. One accumulated field is not monotonic: :VMDVCSCT, the Virtual
Console Requests. This might result from a user who disconnects
(count reset to zero at disconnect?)
8. It was thought that (SYSUSRS-SRMCDORM) could be used as a count
of "Active" users but it failed (and the difference is now named
NONDORM) because SYSUSRS counts virtual machines while SRMCDORM
counts VMDBLKS (one for each CPU defined by each machine.) The
variable ACTIVE is now calculated from user records (non-zero
VTIME during the interval) but itself suffers because the
interval size affects the definition, and because it counts
VMDBLKS, not machines.
9. IODDEV HFRDEVCNT is wrong. It accumulates an accumulation!
10. SEEK data is wrong. The record indicates a seek did occur, but
the serialization of data and the data in the record itself is
not always valid.
11. HFUSERC in VXPRCPRP and VMXAINTV (VMDBKS in PLDV is not valid -
it appears to be accumulation of accumulation. data is new to
everyone (especially IBM!).
12. Additional problems have been reported by IBM by MXG and other
vendors and are under investigation. Unfortunately, the list of
known problems has not been made available, and is not in IBM's
Support Center as of this writing. I can only give you my list!
6. Technical Notes: SAS
Z516.2120 Allows 3380-K's to contain SAS data sets with over 32000
tracks. (This was never possible before 3380-K's so it
is required only if you want to create a very large SAS
data set.) Note that this zap is a very big one and is
to be on the SAS 5.18 maintenance release and thus it is
recommended that you wait until then.
Z516.4669 Makes PROC CONTENTS aware of 3380-K's. See above zap.
Z518.5694 Makes PROC GPLOT not set CC 12. (See Change 6.106).
Z518.5779 Makes GROUP statement in PROC GREPLAY work correcty.
The mainframe SAS/PC Device Driver (GRLINK) under 5.18 will not work
when you are trying to create SAS/GRAPHs with a batch job. This
device driver expects the PC to be online and will not generate the
graphs when the PC is offline (as it is to a batch job). To
circumvent this problem, specify
GOPTIONS DEVICE=TCX4107 GOUTTYPE=INDEPENDENT NOCHARACTERS NOCELLS
GSFMODE=NONE HPOS=80 VPOS=43;
or use the %VMXGGOPT invocation of
%VMXGGOPT(DEVICE=PCBATCH,DISPLAY=N);
This will allow you to build a graphics catalog in a batch job and
then replay the graphs with SAS/PC AND have graphs that look right!
To execute MXG code under SAS/PC, you must first download the MXG
member FORMATS and build the formats on the PC. You must create a
directory and establish LIBREFS of SASLIB and LIBRARY pointing to
that directory. Member FORMATS will execute under SAS/PC and the
resulting 150+ formats requires only 250K. Members ANALDB2R,
ANALDMON, and ANALNPMR have been tested on a PC. ANALDB2R took over
35 elapsed minutes on an AT, compared with less than one minute on a
3090 mainframe.
The SAS ERROR: WORK.DIRMACR/SYSTEM REQUIRES MORE SPACE THAN IS
ALLOCATED TO THE LIBRARY, followed by a NOTE: DATA SET WORK.DIRMACR
WAS AT OBSERVATION 16744450 has occurred at two sites during
execution of the JCLTEST program. This error results from a design
limit in SAS. The DIRMACR dataset is where old-style macro
definitions are stored, and it (unlike real SAS datasets) has a fixed
limit in its size. Both sites had (correctly!) made use of MXG
member IMACKEEP to keep only desired variables. But because JCLTEST
repetitively re-includes IMACKEEP, and because SAS does not reuse the
space in DIRMACR (even though the same macro names are being
re-defined with each include), DIRMACR filled! Removing IMACKEEP
temporarily from USERID.SOURCLIB allowed JCLTEST to complete
successfully. THERE IS NO REAL PROBLEM HERE, since your normal MXG
jobs do not re-include IMACKEEP hundreds of times!
IV. CHANGE LOG.