COPYRIGHT (C) 1984-2005 MERRILL CONSULTANTS DALLAS TEXAS USA
Newsletter TWENTY THREE
/* COPYRIGHT (C) 1984-2005 MERRILL CONSULTANTS, DALLAS, TEXAS */
****************NEWSLETTER=TWENTY-THREE*********************************
MXG NEWSLETTER NUMBER TWENTY-THREE March 15, 1993
Technical Newsletter for Users of MXG : Merrill's Expanded Guide to CPE
TABLE OF CONTENTS
page
I. MXG Version 10.10 Announcement, Status and Enhancements 2
II. Incompatibilities, Installation, and Space for MXG 10.10 4
III. Documentation of MXG Software 6
IV. MXG Technical Notes
1. MXG Tape Mount Monitor with MIM 7
2. MGBYTES format. 7
V. MVS Technical Notes
1. APAR OY56235 - JES2 type 26 invalid times fill SPIN library. 7
2. APAR OY57134 - IFASMFDP Blocksize correction 7
3. APAR OY57971 - TYPE 73 two CHPID '00', no CHPID 'FF'x 7
4. SMF/RMF Enhancements in MVS/ESA 4.3 and DFSMS 1.1 8
5. ISOGON's TICTOC product Zap PMR0011. 10
6. "MVS/ESA Resource Accounting - What's Captured Where" 11
VI. VM Technical Notes
1. APAR VM52395 corrects invalid VM type 01 account records. 24
VII. CICS Technical Notes
1. Correction to IBM Document ID Q504977 "Main Task" CPU time. 24
VIII. SAS Technical Notes
1. Technical note on BUILDPDB virtual storage usage. 24
2. MEMSIZE and REGION relationship. 25
3. SASOPT73 can restrict your SAS options. 25
4. Use SMS Guaranteed Space for multi-volume SAS library. 25
5. SAS 6.07 CMS requires GLOBAL statement. 26
6. SAS 6.07 ZAP Z6074721 corrects 0C4 with double ampersand. 26
7. PROC COPY zero observation dataset ABENDs. 26
8. INVALID HEADER error. 26
9. Nested parenthesis in SUM results in invalid values. 26
10. PROC GPLOT "SAS SYSTEM STOPPED" error corrected by Z6071258. 27
11. SAS 6.07 CPU loop or Wait loop if //WORK has UNIT=(SYSDA,3) 27
12. XSWISS font name changed to SWISS. 27
13. 0C4 ABEND in Data Step compiler V6-SYS-DATA-5266 27
14. SAS V6-SYS-FILE-4673 corrects CRITICAL ERROR IN VTOC 27
15. MXGSAS sample JCL Procedure provided. 27
IX. Change Log 28
Alphabetical list of important changes 28
Changes 10.323 thru 10.105 32-80
COPYRIGHT (C) 1993 BY MERRILL CONSULTANTS DALLAS TEXAS
I. MXG Software Status and Enhancements:
MXG 10.10 is the Production Version of MXG 10 (i.e., the version that
we "Produce" for all sites), dated March 15, 1993, and it was shipped
to you along with this MXG Technical Newsletter number TWENTY-THREE.
MXG 10.10 is a major revision, with many latent enhancements, and near
transparent installation. Sites with normal MXG tailoring should need
less than 2 hours to unload, tailor, and submit the test jobstreams.
Make sure you read the COMPATIBILITY warning in Installation section
of this Newsletter (repeated, always, in member CHANGES).
Check member CHANGES in MXG Version 10.10 for last minute additions!
Versions 10.7-10.9 were skipped to make the Production Version 10.10.
Versions 4.4 thru 9.9 were truly the n.n release, but I now plan to
number all future Production releases equal to the version number!
Major enhancements added in MXG 10.10, that were not in MXG 10.6:
Support for OpenEdition MVS, OMVS, RMF record enhancements.
Preliminary RS6000 AIX VMSTAT,IOSTAT,PS command processing
GMT offset, GMTOFFTM, available in MVS/ESA 4.3 RMF records.
DCOLLECT options SMSDATA creates nine new SMS construct datasets.
RMF reports can be produced from MXG TYPE70xx datasets.
Additional online MXG documentation members (ADOC and ACHAP).
Major enhancements added in MXG 10.6, that were not in MXG 10.5:
Support for Empact's Hipercache SMF record.
Support for IMF Release 2.8.
Support for Oracle 6.0.33.1.51.
Support for IBM 3495 Tape Library Dataserver's type 94 SMF record.
Support for (incompatible) Omegamon/CICS DATACOM SPE PTF QOC0109.
Support for STOPX37 Release 3.5.
Support for Empact's POOL-DASD user SMF record.
Support for Candle's IMS Transaction Reporting Facility, ITRF.
Support for Landmark for CICS's Release 9 and Release 1.0.
IBM-like RMF reports can be created with new ANALRMFR.
Additional HOGAN application fields added in CICSTRAN
HP's MPE data or HP/UX Unix data are both supported by TYPEHPCS
SLR-like IMS processing for sites with heavy fast-path in TYPESLRI
Additional CMF "type 240" subtypes supported in TYPECMF
Major enhancements added in MXG 10.5, that were not in MXG 10.4:
Support for MVS/ESA 4.3 and RMF 4.3.
Support for NPM Release 1.6.
Support for NETSPY Release 4.3 and LANSPY 1.1.
Support for IDMS Release 12 PM records confirmed.
Major enhancements added in MXG 10.4, that were not in MXG 10.3:
Support for ESCOM Multi-Image Facility (EMIF)
Support for VM/ESA 2.0
Validation of support for Velocity Software's XAMAP History files.
Major enhancements added in MXG 10.3, that were not in MXG 10.2:
Support for NPM 1.5.1 incompatible changes.
Correction of MXG-10.2-only error in ASUM70PR
Support for DFSORT Release 12 new fields.
Cleanup of all reported errors in prior prereleases.
Toleration support for VM/ESA 2.0 MONWRITE data.
Major enhancements added in MXG 10.2:
Powerful new "_L" and "_K" macro architecture allows full tailoring
of MXG datasets (variables kept/dropped, compression, blocksize,
the DDNAME to which the dataset is written, etc.).
Support for DB2 Trace IFCID 172/ 177 added, Audit/SQL reports fixed.
Support for FACOM AIM Version 12 type 116 SMF record changes.
Support for FACOM PDLF Type 127 for MSP/EX.
Support for HP Unix (HP/UX) PCS Performance Collection System data
Support for IBM TCP/IP Version 2 Release 2 SMF record.
Support for IBM TIRS type 96 SMF record coded.
Support for Network Alert APAR OY49717 in SMF Type 37.
Support for OMEGAMON II for VTAM V150 user SMF record coded.
Support for OPC changes.
Support for SAP Accounting data in CICS type 110 or journal file.
Support for SIMWARE SIM/XFER VTAM user SMF record.
Support for TMS Billing-by-dataset using enhanced DSNBRECD dataset.
Support for VSE DOS POWER Version 4.2
Support for Xerox Printer's SFS Status File System records.
Support for XCOM 6.2 Version 2.2.2G SMF record.
Alert that Legent's MIM can corrupt MXG Tape Mount counting.
"Appended" IMS Log enhancements; has now been tested with IMS 2.2.
Continued enhancement of ANALDB2R for DB2 reports.
Major enhancements added in MXG 10.1 but not listed in Newsletter 22:
OPC/A log processing major revision, additional datasets created.
Verstand's product, TTX, is now included in MXG Software.
Support for AS400 V2R1M0 added, and AS400 support was revised.
NPM 1.5.1 subtypes 144-150 (NPMEVX25 dataset) errors were corrected.
Sample IEFU83 exit to filter type 40 records for tape-only added.
Major enhancements added in MXG 10.1 that were listed in NL 22:
Required for CICS/ESA 3.3,
Required for VM/ESA 1.1.1,
Required for TYPEIMS users; major revision in IMS log processing.
Strongly recommended for DB2 sites, because it:
- has significant corrections in ANALDB2R reporting,
- has speeded up MXG DB2 processing and reduced WORK space needed,
- allows DB2ACCT direct to tape for sites with large DB2 activity,
- has new ASUMDB2A to summarize and reduce size of DB2ACCT.
- has MVS Account fields added to DB2ACCT (DB2 2.3).
Offers support for these new products or releases:
Support for AICorp's KBMS user SMF record.
Support for Amdahl's APAF replacement for MDFTRACK.
Support for Blue Line's Vital Signs for VTAM type 28.
Support for Fujitsu's FACOM MSP/EX (incompatible) SMF records.
Support for MVS/ESA 4.2 Dynamic I/O Reconfig in MXG Tape Monitor.
Support for NETSPY Release 4.2 added.
Support for NETSPY Token-Ring records added.
Support for ROSCOE Release 5.7 changes to SMF data.
Support for RSD's WSF/WSF2 Release 3.4.1.
Support for SPMS 1.2.13 incompatible changes.
Support for STOPX37 Release 3.4.
Support for Software Ag "Natural Process" SMF record.
Support for System Center's NETMASTER type 37 SMF records.
Support for The Network Director North Ridge Software
Support for UNIX iostat and vmstat commands from ULTRIX.
ASMVTOC avoids 213/314 abends reading VTOC of TPF or VM volumes.
MINTIME=,MAXTIME= parameters added to VMXGSUM.
MXG Tape Mount Monitor supports MVS/ESA dynamic reconfiguration.
TAPE3490 (3490s allocated) added to PDB.STEPS/JOBS.
Each of those enhancements are described in the Change Log, below.
The following table lists announced availability dates for the IBM
product, and the corresponding Version of MXG required to support
that IBM product.
Availability MXG Version
Product Name Date Required
MVS/370, MVS/XA (all) long ago 8.8
RMF 4.1.2 (for MVS/ESA 3.1.3) Sep 7, 1990. 8.8
RMF 4.2 (for MVS/ESA 4.1) Oct 26, 1990. 8.8
MVS/ESA 4.1 Oct 26, 1990. 8.8
MVS/ESA 4.2 Mar 29, 1991. 9.9
RMF 4.2.1 (for MVS/ESA 4.2) Mar 29, 1991. 9.9
MVS/ESA 4.2.2 Aug 1991. 9.9
RMF 4.2.2 (for MVS/ESA 4.2.2 Aug 1991. 9.9
MVS/ESA 4.3 Mar 23 1993. 10.10
RMF 4.3.0 (for MVS/ESA 4.3 Mar 23 1993. 10.10
CICS/ESA 3.1 1990 8.8
CICS/ESA 3.2 Jun 28, 1991. 9.9
CICS/ESA 3.3 Mar 28, 1992. 10.1
DB2 2.2.0 1990 8.8
DB2 2.3.0 Oct 28, 1991. 10.1
DFSMS 1.1 Mar 23, 1993 10.10
VM/ESA 1.1.0 (370 Feature) Oct 26, 1990. 8.8
VM/ESA 1.1.0 (ESA Feature) Mar 29, 1991. 8.8
VM/ESA 1.1.1 Dec 27, 1991. 10.1
VM/ESA 2.0 Dec 23, 1992. 10.4
II. Incompatibilities, Installation, and Space Requirements.
1. Incompatibilities in MXG 10.10 which will cause syntax errors:
a. If these members exist in your USERID.SOURCLIB, then you must
replace them, by re-tailoring your changes starting with the
new MXG 10.10 member:
IMACCICS IMACCIMS IMACCMF IMACDB2 IMACDCOL IMACIMS
IMACINTV IMACMONI IMACNSPY IMACOPC IMACPDSM IMACROSC
IMACSTX IMACTPX IMACZRB IMAC30DD IMAC40DD IMAC434D
These members defined the DDNAME to which MXG sent certain
datasets (eg., MACRO _CICTRAN CICSTRAN % set the DDname for
DATA _CICTRAN.CICSTRAN). The new "_L" architecture provides
the same function with different syntax (eg., now the macro
_LCICTRN defines both the DDNAME (LIBREF) and dataset name).
Change 10.175 provides specific details of what old-names have
to be changed to what new-names for these incompatibly changed
members.
b. If you had tailored BUILDPDB/3 to create TYPETMNT (the MXG
Tape Mount Monitor records), you will need to remove your
tailoring in members EXPDBINC,EXPDBVAR,EXPDBCDE,EXPDBOUT.
In MXG 10.10 TYPETMNT is automatically created by BUILDPDB/3.
Sites migrating to MXG 10.10 from MXG 9.9 or later should find no
other compatibility issues.
Sites jumping to 10.10 from an MXG version earlier than 9.9 must
read the compatibility section of the installation instructions in
MXG Newsletter TWENTY-ONE pp 37-38 (also in member NEWSLTRS).
2. Installation and re-installation procedures are described in detail
in member INSTALL, but they are summarized here:
a. Allocate a 70-cyl PDS: MXG.V1010.MXG.SOURCLIB, & use IEBUPDTE
to read the MXG tape to create the 1800+ member Source Library.
b. Allocate a 1-cyl PDS: MXG.V1010.USERID.SOURCLIB for your site
"Installation Tailoring" Source Library. Installation specific
tailoring (like telling MXG your shift hours, which performance
groups are TSO, CICS, etc.) is done by copying and modifying MXG
source members into V104.USERID.SOURCLIB.
c. Allocate a 1-cyl SAS Data Library: MXG.V1010.MXG.FORMATS and
execute SAS to create the library of Formats required by MXG.
Sample JCL for the above three steps is in member JCLINSTL.
d. If re-installing MXG, copy your existing USERID.SOURCLIB library
members into the MXG.V1010.USERID.SOURCLIB. Then examine the set
of IMACs that were changed incompatibly (see member CHANGES).
If any members in MXG.V1010.USERID.SOURCLIB are in that list,
you must reinstall your site's tailoring for that IMAC, starting
with the IMAC member from the MXG 10.10 Source Library.
d. If this is the initial install of MXG, tailor these members into
your MXG.V1010.USERID.SOURCLIB tailoring library:
IMACACCT (Account Length),
IMACSHFT (Shift Definitions),
IMACWORK (Performance Group to Workload mapping), and
IMACSPIN (for BUILDPDB).
Each IMAC member is self-documenting, and IMACAAAA is the index
of all of the IMACs. You should at least scan IMACAAAA to see
the acronyms MXG uses for the many products MXG supports.
e. EDIT and submit member JCLTEST6 (JCLTEST if still on SAS 5.18)
to verify that your tailoring did not create any errors.
f. EDIT and submit JCLPDB to create a Daily PDB for testing. Or
use the TYPE.... members to process specific data sources, use
the ANAL.... members for report examples, the GRAF.... members
for SAS/GRAPH reports.
You have now installed MXG 10.10 in its own set of libraries. When
parallel testing is complete and are ready to implement MXG 10.10
in production, rename your three current MXG Production Libraries
(MXG.MXG.SOURCLIB, MXG.USERID.SOURCLIB, and MXG.MXG.FORMATS) to
(MXG.BACK.MXG.SOURCLIB, MXG.BACK.USERID.SOURCLIB, MXG.BACK.MXG....)
and and rename the MXG.V1010.x.y libraries to their Production
names!
Again, detailed installation instructions are in member INSTALL
Always read comments in the CHANGES member for compatibility issues, as
well as for any last minute changes.
Whenever you install changes or test a new version of MXG (or even your
own reports), be extra careful to look on the SAS log for any real error
conditions. Search for all occurrences of "ERROR:" and "ERROR :" and
"UNINITIALIZED" and "NOT CATLGD", as they may indicate a serious error.
A PROC PRINT and a PROC MEANS of each new MXG-built SAS dataset can help
you to understand their contents, and should be used to examine any
unusually large, negative, or suspicious values. Print all variables in
the dataset, and read the variable's descriptions in its ADOC member.
III. Documentation of MXG Software.
Member CHANGES always contains the version number of MXG Software, and
it lists changes that were installed in that version. Members named
CHANGEnn are the CHANGES member from MXG Version "nn". Each change in
MXG software is documented by a Change number and text. The text of
each Change identifies the member(s) that were added or altered by that
change. Documentation (especially for new product's support) is often
also found in comments at the beginning of those members listed in the
change entry. The CHANGE member is designed to be read online (with SPF
BROWSE); you can search for specific product name references (CICS,
MVS/ESA, etc.), or the MXG member name.
Member NEWSLTRS contains the text of all newsletters (up through the
newsletter that accompanied that MXG release). You can search NEWSLTRS
for product name or acronym to find the technical notes, APARs, etc.
from all MXG newsletters. The Change Log pages of each Newsletter are
in member CHANGES or CHANGEnn and are not repeated in member NEWSLTRS.
Member DOCVER lists alphabetically ALL datasets and variables that can
be build by this MXG Software Version. "Delta-documentation" between
MXG versions, which lists only those datasets and variables that were
changed by version "nn" is found in DOCVERnn members for each version.
Chapter FORTY in the MXG Guide and MXG Supplement books are still the
primary documentation of MXG datasets and their variables (at least for
those data sources that existed in 1987!). This should be the first
place you look for information about MXG variables and/or datasets.
As each section of chapter FORTY is rewritten, it becomes an ADOCxxxx
member of MXG.SOURCLIB, providing online documentation for product xxxx.
ADOCs contain alphabetic descriptions of datasets and variables, the
instructions on how to enable that product, bibliography to the vendor
documentation, sample PROC PRINT and PROC MEANS of real data, and the
MXG member names that you use to process that product, etc. Sounds
great? It will be when finished - this is work in progress!
Beginning with MXG 10.3, there has been an IMACxxxx member for every
product supported by MXG. Once you know the xxxx suffix for a product,
you then know the names of all of the MXG members for that product:
IMACxxxx - Defines record IDs, and "_K,_L" macros for product xxxx.
ADOCxxxx - "Chapter FORTY" style dataset and variable documentation.
VMACxxxx - The "real" code member, often documentation in comments.
TYPExxxx - Standalone member to test or process product xxxx records.
ASUMxxxx - Summarization example (only for some products)
TRNDxxxx - Trending example (only for some products)
ANALxxxx - Reporting/analysis example (only for some products)
GRAFxxxx - SAS/GRAPH report example (only for some products)
EXyyyzzz - OUTPUT exit for each dataset. There can be more than one
dataset per product. The EX member name suffix yyyzzz is
the same as the suffix of "_L" and "_K" macros defined in
IMACxxxx for the product. See further discussion under
"Using the MXG Exit Facilities".
Member IMACAAAA is an index of all IMACs, and is the best place to
begin to find what xxxx suffix Merrill chose for which product!
You can often find additional documentation by searching members
NEWSLTRS, CHANGES, and the CHANGEnn members for the xxxx suffix.
Finally, remember that MXG is source code, so you can often find your
answer by BROWSE/EDIT of the source member, especially the VMACs that
actually create the data set, or ANALs that analyze the MXG data sets.
In most cases, the MXG Variable name is the IBM or Vendor's field or
DSECT field name. In other cases, the DSECT field name is carried as a
comment beside in the MXG INPUT statement to map field name to MXG's
variable name. MXG does expect that you will also have access to the
vendor's documentation of the data records you are processing.
The MXG Technical Newsletter is published aperiodically, one copy per
licensed site, and describes changes and enhancements to the software,
provides APARs and PTFs affecting MXG users, and provides tutorial
information of interest to MXG users.
IV. MXG Technical Notes
1. The MXG Tape Mount Monitor (in member ASMTMNT) seems to be very
low overhead - Freddie Arie reports that with 35,000 tape mounts
per month, the MXGTMNT task used only 6 CPU minutes per month!
MIM and other tape allocators that set Mount Pending can cause
mount records for non-mount events. You can delete the non-mount
events that have TAPMNTTM less than 5 seconds. See discussion in
Change 10.200.
2. The MXG-built format named MGBYTES does not stand for "megabytes",
but is a format that prints the value of variables that contain
bytes in Kilobytes, Megabytes, Gigabytes, suffixing the numeric
value with KB, MB, GB as necessary. This conversion does not
alter the true value of the variable, which always contains bytes.
If a variable TESTSTOR has format MGBYTES (in member DOCVER or in
a PROC CONTENTS listing), you could see the exact number of bytes,
without the KB, MB, etc., suffix, simply by printing the variable
using FORMAT TESTSTOR; to eliminate the assigned MGBYTES format.
Note that in many cases, a storage value with format MGBYTES may
have been stored as "frames" in the SMF record; MXG multiplied the
number of frames by 4096 to convert the value to bytes, and then
applied MGBYTES format so it prints pretty!
V. MVS Technical Notes
1. APAR OY56235 PTFs UY85272 (JES 4.1) and UY85272 (JES 4.2) correct
invalid READTIME, JSTRTIME and JENDTIME values in TYPE26J2 and
PDB.JOBS. This IBM error can cause your SPIN library to fill, so
put this fix on!
2. APAR OY57134 corrects the IFASMFDP (SMF Dump program) so that it
no longer creates BLKSIZE=32767 by default. Actual SMF records
can be no greater than 32760, and now BLKSIZE=32760 is the default
set by IFASMFDP, because some utilities had problems with a value
of 32767. (You could avoid the problem by explicitly specifying
the BLKSIZE=32760 in your JCL for the dump job, but this APAR
corrects the basic problem.)
3. APAR OY57971 acknowledges that there are two '00'X CHPID values in
TYPE73, and no 'FF'X CHPID value.
4. SMF AND RMF ENHANCEMENTS ADDED IN MVS/ESA 4.3
SMF Global Recording Interval Synchronization now permits RMF and SMF
interval records to be matched exactly. You synchronize with the new
SYNCVAL and INTVAL values in the SMFPRMxx member of your SYS1.PARMLIB.
Variable SYNCTIME is added to the TYPE23, TYPE30_V (type 30 subtype 2
and 3 intervals) and TYPE70xx thru TYPE79xx datasets. SYNCTIME is the
datetime value when the SMF Global Recording Interval ended, but it, and
INTBTIME/INTETIME in TYPE30_V are written from the GMT clock, so if you
have a non-zero value for TIMEZONE in SYS1.PARMLIB(CLOCKxx), the records
contain a GMT value in SYNCTIME, INTBTIME, and INTETIME, but SMFTIME,
STARTIME, ENDTIME, INITTIME, ALOCTIME, LOADTIME and TERMTIME are local!
Fortunately, the GMT offset in type 30 can be determinted from the old
interval begin time, and SYNCTIME in RMF can be compared to SMFTIME to
actually benefit us - with fuzzy logic that delta is now the retained
variable GMTOFFTM, the GMT offset at the end of each RMF interval!
Synchronization also changes the contents of the TYPE30_V interval data.
Formerly, INTETIME was the SMFTIME when the interval record was written,
but now, INTETIME is the time when the synchronized interval ended. If
the task is swapped out when an interval ends, the SMF record will not
be written until later, when the task is swapped back in, and the begin
time of the next interval record, INTBTIME, will be the time of the swap
swap in, and not set to the ending time of the previous interval. This
makes the INTBTIME to INTETIME duration the true duration during which
the resources reported in the interval record were consumed, even though
the elapsed interval of execution can be much longer for swapped tasks.
The original SMF30IST interval begin time is still recorded on the local
clock, but the new INTBTIME and INTETIME fields are on the GMT clock.
Fortunatly, the difference between SMF30IST and INTBTIME fields is the
GMT offset in effect, so MXG could correct INTBTIME and INTETIME back to
local, and furthermore, new variable GMTOFFTM is created and retained.
The JES2 type 26 Purge Record was enhanced with these long-wanted data:
SUBMUSER - Submitting USERID
NOTIFYND - Job end execution notify NODE
NOTIFYUS - Job end execution notify USERID
ACCOUNTn - Job card accounting fields finally!!!
NRACCTFL - Number of accounting fields.
LENACCTn - Length of nth accounting field
DUPJBDLY - Flag that job was delayed due to Duplicate Job Name Hold
OFFLPURG - Flag that this is a Spool Offload purge record.
APPC Accounting in TYPE33_1 now contains JOB READTIME and STEPNAME.
The new TYPE33_2 dataset contains resources at the conversation level,
particularly needed if you use an APPC/MVS Server address space to
process multiple conversations concurrently, since now you can collect
information for each conversation in the server address space.
New DFSMS TYPE42SR dataset provides response statistics for each Storage
Class for each interval, containing:
AVGCONMS- Average connect time per SSCH
AVGCUQMS- Average CU queue time per SSCH
AVGDISMS- Average disconnect time per SSCH
AVGPNDMS- Average pending time per SSCH
CACHCAND- Count of cache candidates
CACHHITS- Count of cache hits
IOCOUNTS- Total i/o count
RESPTIME- Average response time per SSCH
STORCLAS- Average connect time per SSCH
WRITCAND- Count of write candidates
WRITHITS- Count of write hits
New DFSMS TYPE42DS dataset provides the above response statistics, but
at the data set level, with additional details.
TYPE70s: Variable SYNCTIME was added to all RMF datasets for matchup
with SMF records, and new variable INTRVSYN flags if synchronization was
in effect.
TYPE71: CPUPAGTM, the CPU time spent in page movement in central store.
When a particular type of frame (eg. below 16MB or nonreconfigurable) is
mandated by a request but is not found in the available frames, the real
storage manager uses a process called prefsteal to attempt to find a
correct type of frame and move the contents of that frame elsewhere in
central or expanded storage. The TCB/SRB timer is stopped during this
process in consideration of the general desire that these times be as
repeatable as possible. This new variable, CPUPAGTM, is the CPU time
that was not previously captured during this process.
TYPE72MN: A significant MVS/ESA 4.3 RMF enhancement is the addition of
many new RMF III variables to the TYPE72MN dataset, written for each
performance group for each interval. New sampled measures for the
percentage of time when each performance group was USING devices or CPU,
or was DELAYed for devices, CPU, storage, ENQ, HSM, JES, MOUNT, message,
XCF will make TYPE72MN a very useful source of delay analysis.
Additional measures of CSTORE and ESTORE usage and "long" logical swaps
are included in these new variables:
AVGELPTM=AVG ELAPSED*TIME PER*ENDED TRANS
AVGQUETM=AVG JES/APPC*QUEUE TIME*PER ENDED
CPUVECTM=VECTOR*CPU USED*DURATION
LOGCSTOR=CSTORE FOR*LOGICALLY*SWAPPED USERS
LOGESTOR=ESTORE FOR*LOGICALLY*SWAPPED USERS
LONGESTO=LONG SWAPS*TO EXPANDED*STORAGE
LONGLGSW=LONG*LOGICAL*SWAPS
LONGPHYS=LONG SWAPS*TO PHYSICAL*AUXSTORE
LSWSAMPS=TOTAL*LOGICAL SWAP*SAMPLES*/
PCTDLDEV=PCT WHEN*DEVICE*DELAY
PCTDLENQ=PCT WHEN*ENQ*DELAY
PCTDLHSM=PCT WHEN*HSM*DELAY
PCTDLJES=PCT WHEN*JES*DELAY
PCTDLMNT=PCT WHEN*MOUNT*DELAY
PCTDLMSG=PCT WHEN*MESSAGE*DELAY
PCTDLPRO=PCT WHEN*PROCESSOR*DELAY
PCTDLSTO=PCT WHEN*STORAGE*DELAY
PCTDLXCF=PCT WHEN*XCF*DELAY
PCTUNKN =PCT WHEN*UNKNOWN*STATE
PCTUSDEV=PCT WHEN*DEVICE*USING
PCTUSPRO=PCT WHEN*PROCESSOR*USING
PHYESTOR=ESTORE FOR*NON-LOGICAL*SWAPPED USERS
PSWSAMPS=TOTAT*NON-LOGICAL*SWAP SAMPLES
TRANS =ENDED*TRANSACTION*COUNT
VALDSAMP=TOTAL*VALID*SAMPLES
TYPE73: In MVS/ESA 4.2, APAR OY45991 PTF UY77343 now writes a CHPID
segment for all 256 possible paths whether they exist or not, so now MXG
only OUTPUT TYPE73 observations if the CHPID is ONLINE. This logic was
externalized into member EXTY73 in case you want observations for
OFFLINE channel paths.
TYPE74TD: New "Tape Device" dataset contains the maximum number of tape
devices allocated each interval, recorded if device class TAPE is being
recorded. This dataset was also added to BUILDPDB/BUILDPD3 and
WEEKBLD/MONTHBLD logic.
TYPE74: New variable, TAPEMNTS, counts the number of tape mounts
detected during the interval for each tape device. Variables MTPATBEG
and MTPATEND are "Y" flags if MTP (mount pending) existed at begin or
end of interval. If MTP does not exist at either begin or end, MXG
calculates the average mount pending per tape mount per device in new
variable AVGMTPTM. In RMFINTRV AVGMTPTM is calculated for all
devices that had both MTP flags blank.
(Only when both flags are blank do we know for sure that the mount
pending time duration and the number of mounts are exactly matched.)
TYPE79C: New variables R79FLAG, R79CPBY and R79CCPTS added.
TYPE90: Variables MINBUFF and MAXBUFF are now reserved in IPL SMF, SET
SMF, or SETSMF Operator Command event records. No real loss here, since
the maximum number of buffers each interval is always in TYPE23 dataset.
TYPE94 The type 94 record from the 3495 Tape Library Dataserver has
hourly counts and durations (min/max/avg for counts/durations) of drives
mounted, mount requests pending, demounts, ejects, audit requests, and
the count of insert stores.
TYPE96 The type 96 record from The Integrated Reasoning Shell, TIRS
accounts for TIRS resounce usage. The SMF Manual title "Cross Memory
Service Provider Charge Back" is certainly pompous for this TIRS record!
Type 118/119: The TCP/IP SMF record sample used ID=70! APAR PN34837
now assigns IBM record numbers 118 and 119 for the TCP/IP product.
BUILDPDB Logic was changed to use the type 26 OFFLPURG field to detect
purge records created by the SPOOL Transfer/Offload program. New
variables SUBMUSER DUPJBDLY OFFLPURG ACCOUNT1-ACCOUNT3 LENACCT1-LENACCT3
and NRACCTFL were added to the list of variables kept from TYPE26J2 (in
member IMACPDB). The order of datasets in the MERGE for PDB.JOBS was
changed, moving GOOD26J2 to be first so that the TYPE26 ACCOUNTn fields
will be used in PDB.JOBS when they exist. (Leaving it where it was
could have blanked out valid ACCOUNTn data since the SAS MERGE uses the
values from the last dataset, for sites not yet on MVS/ESA 4.3!)
RMFINTRV The new CPUPAGTM from TYPE71 is kept in RMFINTRV as a separate
variable, is also added to CPUTM, the sum of all captured CPU time, and
hence the CPUPAGTM is NOT included in CPUOVHTM, the MXG variable for
uncaptured CPU time in RMF.
DCOLLECT has added a new field to the type "A" record with the amount of
space used by a VSAM entry (formerly only allocated size was given).
5. The TICTOC product from ISOGON, designed to test applications for
the year 2000+, can corrupt dates and data in SMF type 4, 5, and
30 records. TICTOC establishes a "virtual clock" by trapping SVC
11, but SMF uses SVC 11. When the virtual clock was returned to
SMF, it created invalid job initiation, JINITIME (which is used in
MXG's SPIN decision logic) and corrupts JELAPSTM, for any job that
used TICTOC for application testing. The virtual clock also
corrupted the CPUTCBTM field, but ISOGON has corrected both errors
(by only returning a "virtual clock" value if the caller is in
Problem State and in a User Protect Key), so that now the SMF
times appear to be valid. Their zap is PMR0011, and it is
included in TICTOC Release 2.0, due out later this year.
6. MVS/ESA Resource Accounting, Cost Transfer, and Billing Issues
What's Captured Where
Herbert W. Barry Merrill
President-Programmer
Merrill Consultants
Originally presented at the
SHARE Winter 1993 Meeting Session M724
Wednesday, March 3, 1993
This paper is also contained in member ACHAP31 of MXG Software,
as it is a consolidation and revision of that chapter.
Computer system accounting is implicitly tied to the effectiveness
of the DP management. While your chief executive officers want
effective cost accounting for their data processing budgets, many
DP managers drag their feet because they do not want to be held
accountable, and justify those delays by claiming that resource
accounting cannot be accomplished. Successful computer system
accounting is thus both a technical and a political issue. This
chapter is a technical tutorial on the excellent resource capture
mechanisms that do exist in MVS/ESA, and how they can be used to
distribute the cost of your major hardware components to users.
This material is Copyright (c) 1993 by Merrill Consultants, Dallas, TX.,
and will be published in MXG Technical Newsletter TWENTY-THREE, March
15, 1993. Permission is hereby granted to SHARE, Inc., and to SHARE
member installations to reproduce this material for their internal use.
All other rights are reserved.
Topic Page
CPU RESOURCE ACCOUNTING 2
USING RMF DATA TO DETERMINE THE CPU CAPTURE RATIOS 2
USING SMF DATA TO DETERMINE THE CPU CAPTURE RATIOS 4
SCHEMATIC COMPARISON OF CPU MEASURES IN RMF AND SMF 5
CPU CAPTURE AT THE SUBSYSTEM LEVEL 6
DB2 CPU USAGE CAPTURE 7
CICS CPU CAPTURE 8
MEMORY 9
CHANNELS AND CONTROL UNITS 10
DISK DRIVES 10
TAPE DRIVES 11
TAPE VOLUMES 11
TAPE MOUNTS 12
PRINTERS 12
TERMINALS, CONTROL UNITS, AND PORTS 13
CPU RESOURCE ACCOUNTING
The CPU resource is always the most expensive shareable resource in any
data processing system, and it will always be the primary resource used
for cost recovery and chargeback. Charges must be based on utilization
in order to equitably distribute the cost of the processor itself.
MVS records the total CPU time consumed in the hardware platform in
TYPE70 dataset variable CPUACTTM, it records the CPU time captured for
each address space in the TYPE30 dataset, and it records the CPU time
for each service class, so the accounting and cost recovery of CPU time
should be relatively straightforward, right? Ain't nothin' that
straightforward: read on!
A major issue in CPU accounting are the capture ratios, which quantify
how much of the total CPU time caused by a workload is captured in the
accounting records for that workload. In most instances, uncaptured CPU
time results when MVS simply does not know which task caused the burst
of CPU time.
An example is the I/O interrupt processing CPU time of the First
Level Interrupt Handler, FLIH, the module that gets control when an
I/O interrupt occurs. Although FLIH knows which device is involved,
it does not know which task owns that device at the time of the
interrupt processing, and thus its CPU time cannot be assigned to an
address space or a service class. For a long time, even the Second
Level Interrupt Handler, SLIH, did not record its CPU usage, but
MVS/ESA added instrumentation to capture SLIH time in CPUIIPTM.
Uncaptured CPU time is still CPU time that the hardware had to deliver,
and you had to buy that hardware, so you must measure the uncaptured CPU
time, and recover it by inflating the recorded CPU time by dividing by
the capture ratio. So how do we measure how much CPU time is captured?
We can use RMF or SMF data to calculate capture ratios, but they do not
necessarily provide the same answers!
USING RMF DATA TO DETERMINE THE CPU CAPTURE RATIOS
The "RMF Uncaptured CPU time" is the TYPE70 CPU active time minus the
"identifiable" CPU times recorded in RMF; this difference measures how
much CPU time was uncaptured, as measured by RMF, during an interval.
IBM has made major improvements in minimizing the uncaptured CPU time by
improving the instrumentation within MVS; early MVS/370 typically
captured only 70% of the CPU time, MVS/XA improved to 80%, and with the
addition of the new Page Movement CPU time in MVS/ESA 4.3, over 90% of
the total CPU time may be identifiable in the RMF data.
That "RMF Identifiable" CPU time is the sum of the five CPU measures in
TYPE72GO (TCB, SRB, I/O Interrupt, Hiperspace, and Region Control Task)
for all of the Service Classes, plus the CPU measure in TYPE71 for Page
Movement:
RMF CPUTM=CPUTCBTM+CPUSRBTM+CPUIIPTM+CPUHPTTM+CPURCTTM+CPUPAGTM;
Only Service Classes can be used in this calculation because any CPU
time in a Reporting Class duplicates CPU time in its Service Class.
The RMF Uncaptured CPU time (historically, but inaccurately named
CPUOVHTM in MXG's RMFINTRV dataset) is calculated as:
CPUOVHTM=CPUACTTM-CPUTM;
and it represents the total CPU time that was consumed but that was not
captured in RMF data. And we could calculate the RMF capture ratio:
RMF Capture Ratio= CPUTM/CPUACTTM; (express as percentage)
So can't we then take the TYPE72GO data for each Service Class, inflate
the measured CPUTM by dividing by the above capture ratio to recover
100% of the CPU time consumed? Of course not, that would be too easy,
and there's an additional problem. While RMF "identifies" all of the
CPUTM, only some of the service classes represent directly chargeable
work. For example, service classes for VTAM, CATALOG, RMF, etc.
represent real work that was consumed, but that work is not attributable
to a specific workload or account number: TSO users, as well as IMS and
CICS transactions cause the CPU time that VTAM used; RMF resources
(while small) are not attributable to any user, and CATALOG resources
are caused by all catalog references! The new CPUPAGTM is "identified"
CPU time, but it, along with the CPUSRBTM in Service Class SYSSTC,
record the paging subsystem's use of CPU!
We must identify those service classes that map directly to our billable
workloads (for example, the service class(s) in which Batch, TSO, CICS,
IMS, etc., execute) and from them, construct workload specific variables
with the sum of TYPE72GO CPUTM from those workload specific service
classes (for example, variables BATCPU, TSOCPU, CICSCPU, IMSCPU, etc.)
for each RMF interval. MXG's member IMACWORK is the table which maps
service classes to specific workloads, and it is used to build the
RMFINTRV dataset from which capture ratios can be calculated. The RMF
CPU time that is captured in these workload specific variables will be
Workload Specific CPUTM = BATCPU + TSOCPU + CICSCPU + IMSCPU;
and there now exists a new "Workload Specific Uncaptured" CPU time:
W.S. Uncaptured CPU = CPUACTTM - (BATCPU+TSOCPU+CICSCPU+IMSCPU);
which now includes all of the CPU time that was not recorded in one of
the workload specific service classes. We can thus now calculate the
Workload Specific Capture Ratio:
W.S. Capture Ratio = (BATCPU+TSOCPU+CICSCPU+IMSCPU) / CPUACTTM;
It is this capture ratio that we must use in our chargeback analysis, as
it takes into account not only the MVS uncaptured CPU time, but also the
CPU time consumed in service classes (like VTAM, RMF, etc.) that are not
mappable to specific workloads.
A note for the serious analyst: The capture ratio calculated above
is the average capture ratio across all workloads, which assumes that
the same amount of uncaptured CPU time is caused by each workload.
That clearly may not true; interactive workloads (especially TSO) may
capture significantly less CPU time than does batch, as was shown in
Chapter 26 of the 1984 MXG Guide, which found MVS/XA captured 80% of
Batch, 76% of IMS, 66% of CICS, but only 58% of TSO, with the average
capture ratio of 70%!
Calculation of individual capture ratios for each workload can be
done using SAS/STAT linear regression tools:
PROC GLM DATA=RMFINTRV;
MODEL CPUACTTM = BATCPU TSOCPU IMSCPU CICSCPU;
as was described in that chapter.
There is now an even easier way to get a good estimate of the
capture ratio of your workloads; the MXG dataset PDB.RMFINTRV
contains the variable CAPTURAT, which is the total system capture
ratio. By plotting the CAPTURAT versus time of day for each of
your systems:
PROC PLOT DATA=PDB.RMFINTRV;
BY SYSPLEX SYSTEM;
PLOT CAPTURAT*STARTIME;
you can examine those times of day on a particular system when the
workload is "all CICS", or "all TSO", and make a very accurate
estimate of that workload's capture ratio.
However, when the overall capture ratio was only 70%, measuring the
individual capture ratio of each workload was much more critical,
because there was so much more variation between workloads. But if
overall capture ratio is over 90%, and with the TSO capture ratio
improved by CPURCCTM, it may not be so critical to calculate each of
the workloads individual RMF capture ratio. Of much more immediate
concern is the determination of the CPU time captured by the SMF
accounting records themselves.
USING SMF DATA TO DETERMINE THE CPU CAPTURE RATIOS
Historically, we have used RMF to calculate the RMF Capture Ratio and
the Workload Specific Capture Ratio because there was no other choice;
SMF type 30 data could not be synchronized and thus it was simply not
possible to accurately compare SMF CPU time with RMF CPUACTTM. Now that
IBM has finally provided SMF interval synchronization (requested in a
SHARE CME requirement that I authored in 1978!), the same analysis
described above for RMF could now be accomplished using the SMF type 30
data. However, not only are the CPU times recorded in RMF different
than the CPU times recorded in SMF, but also the CPU times in the
TYPE30_4 step termination record are not exactly the same as the CPU
times in the TYPE30_V step interval records! Let us examine these
differences.
MVS/XA recorded only CPUTCBTM and CPUSRBTM in RMF TYPE72GO, TYPE30_4 and
in the TYPE30_V datasets. MVS/ESA 3.1.0e added three new CPU times,
(CPUIIPTM,CPUHPTTM,CPURCTTM) to the TYPE30_4 and TYPE30_V data, but
those three CPU times were not added to the RMF TYPE72 data until 4.2
The CPUPAGTM that was added by MVS/ESA 4.3 to the RMF TYPE71 data is not
recorded anywhere in SMF type 30 data; in fact, IBM describes this Page
Movement CPU time as the time when the CPU timer was suspended, and says
that the reason the CPU timer was suspended during page movement was to
make the recorded task CPU time more repeatable (albeit less accurate!).
There are two other CPU measures that exist only in the type 30 step
termination data. These fields, CPITCBTM and CPISRBTM contain the
"Initiator State" or "Privileged State" CPU time caused by the step, and
they record the CPU time at the beginning of the step and the CPU time
at the ending of the step that is not recorded elsewhere.
So what are the beginning and ending step events that are recorded in
CPITCBTM and CPISRBTM? The major events recorded at the beginning of
steps appear to be allocation related. Specifically, the CPU time to
execute the System Managed Storage allocation rules (ACS) is captured in
these times. This has been both observed and verbally confirmed by IBM
SMS Level Two Support technicians. Additionally, one site with Boole &
Babbage's IAM Product noted a step increase in these CPU times when that
product was enabled. There may also be a small amount of CPU time due
to the creation of the address space included in these CPU times.
At the end of step, the CPITCBTM and CPISRBTM times result primarily
from SMF itself! At step termination, the DD segments are scanned by
the type 30 SMF "DD Consolidation" algorithm in an attempt to minimize
the length of the type 30 record, by consolidating into a single entry
all DD segments with the same DDNAME and Device Address. In 1987, Diane
Epstein at Southwestern Bell noted that whenever their SAR job (a SYSOUT
processing subsystem) was cancelled, the CPU went to 100% busy for 30-60
minutes. Instruction traces found the "loop" was in DD Consolidation.
SAR dynamically allocates a DD for each SYSOUT file it processes; by the
end of the week that step had over 75,000 DD entries! DD consolidation
reads the first DD segment, scans the remaining 74,999 segments for a
match, reads the second and scans the remaining 74,998 for a match, etc.
etc., etc., all at DPRTY=FE! In response to Diane's discovery, Bill
Richardson, IBM SMF Development, subsequently provided a new SMF option,
DDCONS(NO), specified in SYS1.PARMLIB(SMFPRMxx), so that you can disable
this very unwise (in my opinion) algorithm, and thereby eliminate its
wasted CPITCBTM and CPISRBTM CPU time.
The time of DDCONS(YES) is measurable because SMFTIME timestamps when
each record is moved (memory-to-memory) to the SMF ASID. For step
events with more than 1635 DD segments, multiple physical type 30
records are created, each with its own time stamp. One specific case
found a subtype 2 interval event created seven type 30 records at
Time of Day of .19 .19 .19 .22 .32 .36 & .46 TOD seconds (i.e., it
took only 270 milliseconds to create these seven records, since there
is no DDCONS in the creation of the subtype 2). These seven records
contained 9182 DD segments that had been allocated during that
interval. The step then terminated at 18.89 TOD seconds, creating
two subtype 3 records both with that timestamp, containing 1929 DD
segments. DDCONS then began, and it then took until 36.50 TOD
seconds to create the first subtype 4 record, and then the last of
the eight subtype 4 records was not created until 40.93 TOD seconds.
These subtype 4s had 11,070 DD segments, while the subtype 2s and 3s
had 11,111 total DD segments. Thus this invocation of DDCONS took
22.04 elapsed seconds (and recorded CPITCBTM of 22.00 CPU seconds!)
from the end of step until the step actually ended, and this DDCONS
invocation could remove only 31 DD segments from the step record!
Examine a day's TYPE30_4 (or PDB.STEPS) data and sum the CPITCBTM and
CPISRBTM, then specify DDCONS(NO) and show management how many CPU
seconds you have been wasting due to DD consolidation!
NOTE: THE SMF DEFAULT IS DDCONS(YES). YOU MUST CHANGE YOUR
SMFPRMxx MEMBER TO SPECIFY DDCONS(NO).
SCHEMATIC COMPARISON OF CPU MEASURES IN RMF AND SMF
Solid = captured Dashed = calculatable
TYPE 70 (RMF-captured CPU measurement of real or logical CPUs):
Elapsed Interval (Duration multiplied by number of CPUs)
|_____________________________________________________________________|
| |
| |
|___________________________________________________________|---------|
| CPU | CPU
| Executing | Waiting
| |
| |
|_________|_________|_________|_________|_________|_________|
| CPU 1 CPU 2 CPU 3 CPU 4 CPU 5 CPU 6 |
| Busy Busy Busy Busy Busy Busy |
| |
| |
|___________________________________________________________|
Total Hardware CPU Busy Time (from Type 70 "non-wait")
___________________________________________________________
| |
Total Hardware CPU Busy Time (from Type 70 "non-wait")
TYPE72GO (service classes) plus TYPE 71 Paging
|_____|_____|_____|_____|_____|_____|-----------------------|
| TCB | SRB | IIP | RCT | HPT | PAG | RMF Uncaptured CPU |
| CPU CPU CPU CPU CPU | CPU | |
| |
|_____|_____|_____|_____|_____|_____| |
| RMF RMF | Captured in |New | |
| TCB SRB | RMF 4.2.1, |in | |
| CPU CPU | MVS/ESA 4.2+ |RMF | |
| | |4.3 | |
|___________|_____|_____|_____|_____| |
| | Existed, |New, | | |
| TCB+SRB |Moved from |was | | |
| |Uncaptured |RMF | | |
| | to |TCB | | |
| | Captured | | | |
|_____|_____|_____|_____|_____|_____| = RMF CPUTM, sum of 6 measures
TYPE 30 step termination:
| |
|_____|_____|_____|_____|_____|-----|_____|_____|-----------|
| SMF SMF SMF SMF SMF SMF SMF | Uncaptured
| TCB SRB IIP RCT HPT TCB SRB | SMF step
| CPU CPU CPU CPU CPU CPI CPI | CPU
|_____|_____|_____|_____|_____| |_____|_____| = CPUTM, sum of 7.
TYPE 30 interval:
| |
|_____|_____|_____|_____|_____|-----------------------------|
| SMF SMF SMF SMF SMF Uncaptured SMF interval CPU
| TCB SRB IIP RCT HPT
| CPU CPU CPU CPU CPU
|_____|_____|_____|_____|_____| = CPUTM, sum of 5.
CPU CAPTURE AT THE SUBSYSTEM LEVEL
Thus far, we have only looked at what is captured at the address space
level, and for many applications this is adequate. For example, if your
CICS regions individually service individual business units, using their
type 30 step termination records may well be adequate for cost recovery.
However, in most instances, a single CICS region services multiple users
from different cost centers, which would require CPU capture at the
transaction level to distribute cost to each department.
Many multiple user address spaces (VTAM, CATALOG and monitor address
spaces like NPM, RMF, SMF) do not provide discrete CPU time per user,
requiring the use of regression techniques described earlier for
their redistribution.
For subsystems that do provide transaction level accounting, we have yet
another capture ratio: how much of the CPU time that is captured in the
type 30 (or type 72) data is captured in that application's transaction
records. The answer varies widely, especially if DB2 access from CICS
or IMS is involved.
DB2 CPU USAGE CAPTURE
When DB2 is accessed by Batch, TSO, IMS, and CICS address spaces, almost
all of the DB2 CPU time is recorded in the address space of the caller,
because DB2 access uses MVS cross-memory services. Thus for those
callers, the DB2 CPU time is recorded in the type 30 records and in the
type 72 records for the service class of the caller. (Some benchmarks
for these caller's use of DB2 showed that over 96% to the DB2-caused CPU
time was recorded in the caller's service classes, with less than 4%
recorded in the DB2 MAST, DBM1, and IRLM service classes.) So the
good news is that the usage of DB2 CPU time is already recorded in your
accounting records, as long as you are using type 30 data for your
accounting. Using the RMF type 72 data for your capacity planning
similarly includes DB2 CPU time in those workload records.
For DB2-under-IMS transaction accounting, the DB2-caused CPU time is
included in the CPU time recorded in the IMS log 07 (program scheduled)
record. Unfortunately, there is only one bucket for CPU time in the IMS
log, and it includes not only the DB2-caused CPU time, but also all of
the transaction's CPU time in the IMS Control and IMS Message Processing
Regions. Neither Candle/IBM's ITRF product nor Landmakr's ASG TMON for
IMS product capture the portion of CPU time due to DB2 in their IMS
monitors. However, BMC's IMS Measurement Facility, IMF, (originally
Control/IMS) is implemented as a monitor sitting on top of IMS itself,
so it is able to capture and segregate CPU time into eight separate CPU
buckets, one of which is the DB2 CPU time caused by the transaction.
The key point about DB2 under IMS is that the DB2-caused CPU time is
included in the transaction-level CPU time, no matter which IMS data
source you use.
Such was not the case for DB2-under-CICS transaction accounting! Before
the "OTE" (Open Transaction Environment) existed, the below indented
paragraphs documented the DB2 CPU capture under CICS:
While the DB2 CPU time caused by CICS transactions is captured in the
type 30 records for each region, and while that DB2 CPU time is
captured in the type 72 service class and reporting class record for
each CICS region, as well as in the type 110 subtype 2 record's CICS
Statistics CICDS dataset (so it is included in MXG's CICINTRV
dataset), prior to "OTE", the DB2 CPU time caused by a CICS
transaction was NOT recorded in any transaction record from any CICS
monitor. Neither the CICSTRAN dataset from IBM's SMF 110 subtype 1
CICS Monitor facility, nor from Candle's Omegamon for CICS, nor from
the MONITASK dataset from ASG-Landmark's The Monitor for CICS, could
capture any DB2 CPU time in the CICS transaction data. Fortunately,
there was an accounting solution: DB2 itself creates a type 101 SMF
accounting record for each DB2 transaction event from any connection
in dataset DB2ACCT. The DB2ACCT observations for CICS connections
had to be selected from the DB2ACCT data (but only CICS Attaches,
since CPU time in DB2ACCT for Batch, TSO, and IMS connections has
already been captured in their type 30 and/or IMS log CPU time).
DB2ACCT variable QWHCATYP identifies the source of the connection; a
value of 4 indicates CICS attach. Thus to account CICS at the
transaction level, you must use both CICSTRAN and the QWHCATYP=4
subset of DB2ACCT in your chargeback.
Prior to DB2 2.3, if the DB2 thread was reused, only one DB2ACCT
record was created (for the thread), and it could represent many
CICS transactions, which prevented accurate CICS accounting with
DB2, but now each DB2 transaction causes a CICSTRAN observation,
even with thread re-use. Also, QWHCATYP did not exist prior to
DB2 2.3, which prevented accurate connection identification!
The DB2ACCT data can be matched with the CICSTRAN data by merging on
variables NETSNAME (the originating network name) and UOWTIME (which
is the first six bytes of the UOWID, the Unit-of-Work ID field), and
the MXG member ASUMUOW combines DB2ACCT and CICSTRAN to create the
PDB.ASUMUOW dataset that contains both the CICSTRAN CPU time (CPUTM)
and the DB2 CPU time (DB2TCBTM), and you had to add those variables
together to properly account for the CICS and DB2 CPU time at the
transaction level.
Only the first six bytes of UOWID are used for the same unit of
work because the last two bytes of UOWID count commits and/or sync
points, and may not be the same across the same transaction. Note
that there can be multiple observations in CICSTRAN with the same
values of NETSNAME and UOWTIME; in CICS Multiple Region Option,
MRO, environments, the Terminal Owning Region (TOR), the
Application Owning Region (AOR), and the File Owning Region (FOR)
create individual CICSTRAN observations for a single CICS event,
and all records from the same CICS event/uow will contain the same
values in NETSNAME and UOWTIME. In DB2ACCT dataset, MXG created
variables named NETSNAME and UOWTIME by substringing DB2 variable
QWHCTOKN (added in DB2 2.3), padding as necessary, to conform
exactly with the structure of those pre-existing CICS variables,
so that a SAS MERGE of DB2ACCT and CICSTRAN can be used in the
ASUMUOW program to match CICS and DB2 transactions.
While you must select DB2ACCT observations only for CICS in your
charge-back (to avoid double accounting), the other observations in
DB2ACCT are completely valid if you want to know how much of your
Batch, TSO, or IMS CPU time was actually consumed in DB2 access.
Most of the preceeding paragraph is still true, even with OTE, except
for this MAJOR change:
With the Open Transaction Environment, "OTE" (which automatically
exists when you have CICS/TS 2.2 or later calling DB2 V6 or later,),
the CICS transaction record's CPU time (e.g., TASCPUTM in CICSTRAN or
MONITASK datasets) DOES now include the DB2 CPU time! The bottom line
for CICS accounting with OTE is that you do NOT add the two CPU times
(CPUTM and DB2TCBTM) in the PDB.ASUMUOW dataset, because CPUTM
includes DB2TCBTM.
While the PDB.ASUMUOW dataset is no longer required to capture the DB2
CPU time, it is still strongly recommended that it be created and used
for CICS transaction accounting, since it combines the multiple CICSTRAN
observations for MRO environments into a single observation for each
"Unit of Work", so there are many fewer observations to pass into your
billing system, and PDB.ASUMUOW will have the correct TRANNAME of the
unit of work:
Using only CICSTRAN, you will not see the actual transaction name,
because the CPU time will usually be in the CICSTRAN observation from
the "AOR", and that record will have TRANNAME='CSMI' (the mirror
transaction), so you can't map CPU time to TRANNAME from CICSTRAN in
an MRO environment, independent of the OTE environment. Furthermore,
the TERMINAL/LUNAME in that AOR record won't identify the source of
the CICS user. The real TRANNAME/TERMINAL/LUNAME will only be found
in the "TOR" observation for that unit of work.
Also, PDB.ASUMUOW is useful because of the additional DB2ACCT variables
which are useful for performance and capacity measurement, independent
of its use for accounting; the MXG program ANALUOW analyzes delays in
the PDS.ASUMUOW data. And finally, in MXG 22.13, the MQ-Series data
from SMF 116 (MQMACCT and MQMACCTQ) data is merged into PDB.ASUMUOW when
you use the ASUMUOW program.
For the accounting of DB2 Distributed work (DRDA from DDCS, for example,
(a DRDA Transaction from DDCS running in an AIX workstation), it is
necessary to directly charge back using the DB2ACCT dataset. DB2ACCT
distributed work observations have QWHCATYP values of 7 or 8, and a plan
name of DISTSERV, and the only field to tie the transaction back to the
workstation which generated the DB2 activity is the AUTHID, but that may
be constant for all transactions, depending on the software running in
the workstation that created the DB2 activity.
For Distributed work, that CPU time in DB2ACCT is also recorded in the
type 30 records for the DISTSERV address space and in TYPE72GO for the
DISTSERV's service class, but there is no other address space involved.
Very high CPU time per transaction (for transactions that have few
GETPAGES) has been seen (5 CPU hours for 186 transaction! This may
simply be the cost of Distributed Architecture (translating each of
the SQL calls and Results to be sent back for different platforms
must involve more code than DB2 talking to CICS, since DRDA has to
manage itself too), or it may be just that the startup and shutdown
costs of DRDA are significantly higher than for normal threads.
The CPUSRBTM/DB2SRBTM in DB2ACCT is now always missing:
I have previously documented (member ADOCDB2, variable description)
that the SRB CPU time in DB2 Accounting records was invalid, but I
did not know how wrong it was, or why it looked ok sometimes, until
I read IBM's library item Q576462, repeated here:
Q: User is doing some DDF testing and has run some accounting reports.
SRB times (both class 1 and 2) are about 8 times the TCB times.
A: The SRB times in the accounting records, in general, account for
SRBs that run in the user address space. These SRBs are caused
by the user's processing, unrelated to anything that DB2 does,
but since the SRBs are asynchronous, they sometimes run while the
user is processing in DB2. With two notable exceptions, these SRB
times while unrelated to DB2 will almost always be insignficant.
One exception is CICS, where there are multiple subtasks accessing
DB2 from a single CICS address space. CICS (not DB2) will often
do a significant amount of processing via SRBs. If there are
several DB2 tasks running concurrently when CICS issues an SRB
(unrelated to these tasks!) then the time for that SRB will show
up not once, but once in each of the accounting records for each
of the tasks. Thus if you add up the SRB times from the DB2
accounting records for CICS attachment, it will often greatly
exceed the actual amount of SRB time used by CICS.
The other exception is when using DDF. The requestor times are
not affected, but the times at the server (or DBAT, using DB2PM
terminology) will show very very large SRB times.
When you look at the DB2 ACCOUNTING records, use only the TCB
CPU time, and never look at the SRB time. When you look at the
DB2 STATISTICS records, you should use the TCB and SRB times for
all three/four address spaces, but remember that much of the SRB
time reported for the DDF address space may also be reported in
DB2 accounting records (as TCB time).
CICS CPU CAPTURE
Even without the DB2-under-CICS issues raised above, the amount of CPU
time captured in CICS transaction records historically has been much
less than the CPU time recorded for the region in its type 30 or its
type 72 service class records. The following table, while showing
pre-ESA CICS numbers, demonstrates the observed capture of three CICS
regions executing in the same 3090 model 400 processor in a 900 second
interval:
Seconds in Percentage of CPUTCBTM
Region TYPE72GO in CICSTRAN dataset
Region CPUTCBTM TASCPUTM
A 111.72 41.1
B 127.06 37.5
C 198.76 66.0
The CICS CPUTCBTM time that is not captured in the CICSTRAN transaction
accounting TASCPUTM is the CPU time to start-up and to shut-down each
transaction. Until a transaction is attached, CICS monitoring cannot
capture CPU time, and CICS monitoring terminates before the transaction
is detached. It appears that this CPU cost to start-up and shut-down a
transaction is fixed; it is independent of what a transaction ultimately
does. Thus there should be a fixed amount of CPU time per transaction
that is not recorded, and we should be able to measure that cost per
CICS transaction and use it, along with the TASCPUTM actually recorded
for the transaction, to improve the recovery of CICS CPU time.
We can determine this "fixed-cost per CICS transaction" by selecting RMF
TYPE72GO for the service class of a CICS region to get that region's
recorded RMF CPUTM for each interval, and by summing CICSTRAN for the
same interval from the same region (APPLID) to create variables NRTRANS
(the number of transactions that ended during each interval), WTFCIOCN
(the number of times that File Control had to wait, indicating that a
physical I/O was performed for a transaction), and TASCPUTM (the CICS
recorded transaction CPU time). We can then use linear regression:
PROC GLM;
MODEL CPUTM=NRTRANS WTFCIOCN TASCPUTM;
to generate the coefficients of the equation relating these independent
variables to the total recorded CPUTM. The coefficient of NRTRANS is
that "fixed-cost per CICS transaction" (in seconds), and the coefficient
of WTFCIOCN is the CPU cost (in seconds) of each physical I/O!
The coefficients of these three terms can be evaluated as potential
billing factors to reproduce the total CPU time caused by each
transaction. What has been proposed here is that the real CPU cost to
deliver CICS CPU service results from adding together the following
three cost components:
a) a cost for the existence of each transaction (NRTRANS), recovering
the static cost of each ATTACH/DETACH,
b) a cost for I/O (WTFCIOCN), the CPU cost of doing I/O operations for
each transaction, and
c) a cost for the actual CPU seconds (TASCPUTM times it's coefficient)
for each transaction.
Prior results (not only for CICS and other on-line systems, but even for
batch job steps) suggest that the major component of CPU time recovery
may be the NRTRANS component. I regret that those studies were
proprietary to the enterprise for which they were done and thus have not
been published, but they showed that the start-up and shutdown costs of
a transaction can often be more significant numerically that the actual
CPU time recorded by the transaction accounting.
With the three coefficients, you can then take the CICSTRAN data and
apply them transaction by transaction to create a billable CPU time for
each interval, which can then be compared with the recorded TYPE72GO
CPUTM for validation. By examining the sum of the three components of
CICS CPU time, you may discover that the addition of the NRTRANS
component brings the CPU captured to very nearly 100%, and you can also
see how much CPU is recovered from NRTRANS, WTFCIOCN, and TASCPUTM.
Remember that this constructed CPU time per transaction still does not
include the uncaptured MVS CPU time discussed previously.
MEMORY
Although you might like to be able to recover the cost of real memory
(Central and Expanded Storage) by charging memory usage to each task,
that possibility disappeared with the departure of MVT and other "real"
memory systems (in which tasks really did own "K-core" units for which
we could legitimately charge). With virtual memory operating systems,
all real memory is owned by the operating system, and not by individual
address spaces. The amount of memory "doled out" to an address space is
thus not under the control of that address space, but rather depends on
the other work that is concurrently requesting services, and (sometimes)
the whims of the memory management algorithms. Since a task does not
control how much memory it does or does not get, real memory cannot
legitimately be used for chargeback. In addition, because the amount of
memory allocated varies widely from run to run, attempting to charge for
real memory space-time occupancy would have very serious problems with
repeatability.
See the paper on I/O Blocksizes in Chapter 42 of the 1984 MXG Guide.
PAGESECS variation of 30-40% were noted between execution of the same
program!
You must treat the cost of memory just like the cost of floor space and
air conditioning; they cannot be explicitly allocated to users but must
be recognized as prerequisite resources you must purchase so that you
can deliver CPU cycles to user workloads.
How do we know we need more air conditioning resources for our CPUs?
We examine the thermometer and when it gets "too high", we buy more
air conditioning. Similarly, when we need more memory, we recognize
its need by looking at the memory thermometer, the page fault rate!
When it is "too high", we must buy more memory!
CHANNELS AND CONTROL UNITS
Channels and control units are meant to allow programs in execution to
read and write blocks of data. Channels and control units are shareable
resources, and their charges should be distributed based on usage. If
channels and control units serving tape devices are separate from those
serving disk devices, it is reasonable to sum the cost of tape channels
and control units and divide by the number of tape I/Os in order to
establish a price-per-tape I/O. Similarly, sum the cost of disk
channels and disk control units and divide by the number of disk I/Os to
establish a cost-per-disk I/O. Under MVS/ESA using I/O connect time
instead of I/O counts is much wiser, as it eliminates the inequity of
charging the same for a 99 byte I/O as for a 32760 byte I/O, and is
strongly recommended. In addition, since I/O counts in RMF are the
number of I/O operations, SSCHs (formerly SIOs), but SMF I/O counts can
be either EXCPs (blocks transferred, for sequential access methods) or
SSCHs for all other access methods), additional validation problems will
result if I/O counts are used instead of I/O connect time.
The key issue is to distribute the cost of the shared channels and
control units to the users who use them in moving blocks of data. Some
channels and control units service only the data center - eg., paging
channels. Their costs must be included in the cost of memory and cannot
be not directly charged to users.
Even this resource recovery is no longer straightforward. When we use
memory as buffers (CICS LSR, DB2 Buffer Pools, etc.), the recorded I/O
operation will be counted only for the first user that caused the I/O
operation. If that block of data remains in the buffer all day long,
other users will not count an I/O and thus will not be charged! Is it
fair, then, to charge the bright user who came to work earliest for his
I/O and give a free ride to the johnny-come-latelies? Probably not!
And this is not just a problem with program buffers. Cached controllers
create exactly the same problem with both I/O counts and I/O connect
time: I/O time is much less when the data is already in the cache!
DISK DRIVES
Disk drives are used to store data, and the owner of the data should pay
the storage cost. If an entire volume is dedicated to an application,
the monthly cost of that volume can be billed to that application. For
shared disk drives, the VTOC/VVDS can be read and used to identify the
owner of each data set, who can then be charged for the number of bytes
allocated. One method is to take the total cost of the disk drive,
divide by the number of bytes on the volume, but this only recovers
costs if 100% of the volume is allocated, so the percentage of the DASD
farm's capacity that can be allocated must be determined, and used to
inflate the per byte cost of DASD storage.
DCOLLECT, an SMF IDCAMS facility will read VTOCs and VVDSs to create a
flat file processed by TYPEDCOL to record non-VSAM allocation and usage
and VSAM data space allocations (in DFSMS 1.1). Alternatively, MXG has
ASMVTOC and ASMVVDS programs to dynamically allocate all DASD devices
and read their VTOCs and VVDSs to provide considerable more detail (for
example, location of each extent for non-VSAM, and VSAM space used for
VSAM), with or without SMS.
TAPE DRIVES
Tape drives are owned for the life of each allocation by a specific job.
It is the duration of allocation that must be used to distribute the
cost of tape drives. The PDB.STEPS contains TAPEDRVS, the number of tape
drives allocated by the step, and EXECTM, the duration of step execution
after drives are allocated, so their product is used to calculate tape
drive hours per job. You can sum all jobs to get the total tape hours
allocated; divide that sum into the dollar costs of your tape drives to
determine the per-hour tape drive charge. This measure reflects actual
elapsed time of a job step and is a good measure if your installation is
reasonably well tuned, causing job elongation to be constrained.
If you have widely varying execution times, however, it may be unfair to
charge tape drives based on true elapsed time. If the installation wants
to eliminate the variability of tape drive hours due to using the actual
elapsed hours, you can instead estimate the number of hours that the job
would have used the tape drive if it was the only job in the system. You
can execute tape jobs in a controlled run and determine the relationship
between tape drive hours and the tape resource (connect time or EXCPs)
to establish an equation that estimates the billable tape drive hours
from each I/O connect second (or EXCP). These estimated billable tape
hours can be summed and divided into the cost of tape drives to create a
per unit rate for billable tape drive hours to recover tape drive costs.
However, there remains one serious problem in using step records for the
calculation of tape drive hours: dynamic allocations. The step record
contains a DD segment for each tape allocation, with the unit address of
the tape drive, but there is no flag to indicate if the tape drive was
allocated for the entire life of the step (statically), or if the tape
drive was deallocated dynamically (using FREE=CLOSE, for example), or
dynamically allocated and then dynamically deallocated for brief periods
of time (as done by both HSM and DB2MSTR). MXG's variable TAPEDRVS is
the number of unique tape drive addresses found in the step record, but
if DB2MSTR happens to allocate a tape drive 15 times during the day (as
it does to back up the log), and if each allocation happens to get a
different drive address, the step record for DB2MSTR will look like it
had 15 tape drives allocated for the entire life of the step! The only
safe solution is to identify which jobs use dynamic allocation of tape
devices, and to then exclude those jobs in charging for tape drive
hours! Only dynamic deallocation is recorded in the type 40, and it can
not be enabled just for tape drives, so enabling type 40 to count tape
dynamic allocations would also create many type 40s from TSO users. MXG
member ASMIEFU8 is SMF exit IEFU83 code that filters only type 40s for
tape deallocations that will let you enable type 40s to identify which
jobs have to be excluded from tape drive charges.
The MXG Tape Mount Monitor, ASMTMNT, is being modified to also track
tape drive allocation-to-deallocation, and it will write an SMF record
for each tape drive allocation, dynamic or static, which can then be
used directly to account for and measure tape drive allocation hours.
TAPE VOLUMES
Storage of tape volumes requires floor space and racks. The total cost
of storage can be divided by the number of tapes in the library to
establish a monthly cost for a stored volume. The tape management system
catalog can be used to determine ownership of each volume, and a daily
or weekly program can determine the number of days each volume is owned
by its creating user, who can then be charged at one-thirtieth of the
monthly rate for each day of tape storage. The job costs of the tape
management system runs can also be added to the storage costs if they
are significant.
TAPE MOUNTS
Tape mounts require people time. Scratch tape mounts require a great
deal less people time than permanent tape data sets do. Unfortunately,
SMF does not record any durations for tape mount time but provides only
the count of mounts for each step for billing. The TYPE30 step data in
PDB.STEPS can be used to identify scratch requests from specific volume
requests. A work study analysis could be used to identify the ratio of
time to fetch and mount permanent volumes versus the time to fetch and
mount scratch volumes, and, thus, the relative cost of a permanent mount
to a scratch mount can be established. The total cost of tape mounter's
salaries can then be distributed by time to mount a scratch or permanent
tape at different rates, and the job steps causing mounts can be charged
appropriately.
Since the duration and nature of each tape mount is recorded in SMF with
the MXG Tape Mount Monitor, ASMTMNT, it is used not only for chargeback,
but also for monitoring the efficiency with which tapes are mounted.
PRINTERS
The TYPE6 record data in the PDB.PRINT data set provides the data needed
to distribute the cost of printing to the end-user. The method used in
distributing these costs depends on the type(s) of printers used. What
works for one class might not work for other classes of printers.
For older line printers, charges based on the number of lines printed is
probably the most accurate and equitable method. For some of the the
early laser printers (like the IBM 3800-1) the line count can be
distorted by font changes within lines but counting lines printed is
still the best method. The PDB.PRINT variable
TOTLINES=SUM(PRINTLNE,PUNCHCRD,EXTWTRLN) must be used to count lines.
Almost all lines printed now are counted in the EXTWTRLN field, because
IBM changed OUTDEVCE (it used to contain the name of the printer or
punch, but it now contains the VTAM node name, so PRint versus PUnch can
not be detected, and EXTWTRLN is the fall-thru bucket!).
PSF printers should be billed based on the number of sheets printed,
SHEETPRN, which is the number of physical page sides that were printed.
SHEETPRN per minute is a good printer throughput measure; the printer
can never produce sheets at more than the rated speed of the printer,
and thus using SHEETPRN recovers the cost of the individual pieces of
paper, and the exclusive use of the printer. Alternatively for PSF, you
may want to consider the use of DOCLENFT (the length of the paper
printed). This number is useful because the meter that is read by the
CE each month is measuring the number of feet of paper that passes
beneath the print head and thus your printer maintanence bill is
directly related to DOCLENFT. There is one small problem with this
number that only applies to continuous form printers like the IBM
3800-3. DOCLENFT is always measured in the direction of paper flow. In
the case of a cut sheet printer, this is ALWAYS across the 8.5 inch side
of a standard size sheet of paper. Continuous forms can be obtained
with the tractor feed on either the 8.5 inch sides or the 11 inch sides
and the same document can be produced on either stock simply by rotating
the text (which may be as simple as changing the form number.) Thus a
100 page job could potentially reflect 70.8 feet one day and 91.75 on
another simply by changing the paper. If you are still using the forms
with the feed on the long side, you may want to evaluate the possible
cost savings of using the other orientation of the paper. What about
PAGECNT? Don't use it. To PSF printers, one page is one sheet of paper
whether SIMPLEX or DUPLEX. Thus a user printing a 100 page document
DUPLEX would be billed for 50 pages while a SIMPLEX user would be billed
100 pages for the same document.
What is in TOTLINES under PSF? It all depends: line-mode data counts
the number of line images spooled in TOTLINES, and PSF-mode data counts
the number of records spooled, but a record could be single line or a
multi-page graph. You can tell that PSF created the type 6 data because
variable SUBSYS6='PSF' (others are: JES2,JES3,EXTW,SAR,EXD,CADI,BUND),
but there's nothing in the type 6 to identify the print's data mode.
Print workstation printers (Xerox printers like the 4050, 4090, 4135,
and 9700s) present other challenges, because they contain their own
operating systems and disk storage (early Xerox used a PDP 11 inside),
and the PDB.PRINT information represents only what was sent by JES or
PSF to the print workstation. PRINTIME/PRENTIME are the time print was
transmitted, and not when actually printed. These printers can store
the SYSOUT, print the SYSOUT, copy it to tape or floppy, or purge the
output prior to printing all without notifying the MVS host of the
action taken! To further muddy the water, there are commands, called
DJDEs, that can be sent along with the datastream to modify the number
of copies, to set print to SIMPLEX or DUPLEX, to set how many logical
pages are on a physical page, etc. This all means that any relationship
between the TYPE6 record and what actually happened on these printers is
purely coincidental. The good news is that there is a Xerox-provided
facility, SFS, that will create a billing record of each
job printed with the print facilities actually used, including the
number of sheets of paper printed and which bins were used. The
bad news is that SFS does not automatically send these data records to
the mainframe, and that you must modify SFS (see the example in member
ADOCSFS) to add the JOB name and JESNR to the SFS record.
Although special forms are less common than earlier, they still exist
and users should be charged for the use and storage of the special forms
that they use. All of these data sources provide indications of the
forms that were used and these should be charged based on the operator
time to mount the form (like a tape mount) and the cost of storing the
blank forms (like a tape volume.)
TERMINALS, CONTROL UNITS, AND PORTS
If a terminal is shared across applications (for example, a VTAM
terminal used for CICS, TSO, and CMS), it is difficult to distribute the
cost of that terminal since not all applications provide a connect time
measure. It is even worse, if a session manager product is used, for
the same terminal may be logged on to multiple systems simultaneously.
If the terminal is exclusively or mostly used by a single application,
say CICS, then the monthly cost of the terminal and its share of the
control unit and 3705 can be distributed directly to that application by
fixed monthly charges. If TSO terminals are shared by different
departments, the duration of each TSO session and the terminal name are
both contained in the session data in PDB.JOBS, allowing numerous
opportunities for distributing the cost of terminals to individual
departments and identifying which terminals are used by which
departments. For terminals used by IMS and CICS, there are no connect
time records, and cost accounting of terminal usage must be done
externally.
VI. VM Technical Notes
1. IBM APAR VM52395 applies to VM/ESA 1.1.1 and corrects invalid
values for EXCPPGIN and EXCPPGOU in type 01 VM accounting records.
VII. CICS Technical Notes
1. IBM Document ID Q504977 discusses using the "Main Task" CPU TCB
time to determine the "single engine requirement" for a CICS
region, but the calculation of "Main Task" CPU TCB in that article
is wrong, and produces a CPU measure which is not only not the
Main Task CPU time, but in fact is greater than the total CPUTCBTM!
The article calculated "Main Task" by subtracting the "Wait Time"
OSWAITTM (MXG name, OSWTELAT IBM name) from the interval duration.
Since the calculation produced a value greater than CPUTCBTM (MXG
name, ADSPTIME IBM name), I conclude that OSWAITTM is not capturing
all of the wait time in the CICS region and have asked IBM for
comments. However, the primary message of that article is good;
it is the Main Task CPU time that must be used to determine the
single engine requirement, which is why the CICSYSTM dataset in MXG
contains variables MAINCPTM and SUBTCPTM with their sum CPUTCBTM!
VIII. SAS Technical Notes
1. This technical note summarizes my investigation of virtual storage
use in a very large BUILDPDB, so that I could better understand
MEMSIZE required, and this note is simply technical information.
See the subsequent note on MEMSIZE and REGION for recommendations.
The virtual storage required by BUILDPDB for I/O buffers is set by
SAS options BLKSIZE=, BUFSIZE, and BUFNO=. The BLKSIZE= option is
an attribute of the SAS data library, and it sets the size of the
physical block that will be moved to and from DASD. The BUFSIZE=
option is an attribute of each SAS dataset and each SAS dataset in
a data library can have a different BUFSIZE. The BUFSIZE must be
a multiple of BLKSIZE. The default BUFSIZE=0 causes SAS to compute
an "optimum" BUFSIZE based on the record length of an observation.
The BUFNO= option is the number of buffers of size BUFSIZE that are
allocated in virtual storage. Each SAS dataset needs BUFNO times
BUFSIZE virtual storage. A very large BUILDPDB (164 datasets vice
81 in the default BUILDPDB) was tested with BLKSIZE=4096, BUFNO=2,
and with BUFSIZE=24576 and required TOTAL MEMORY=34269K. That was
reduced by 7244K when BUFSIZE=4096 was used; by extrapolation, the
total buffer virtual memory required with BUFSIZE=24756 is 8451K,
or 25% of the total virtual storage of this SAS data step. An
additional experiment was run to investigate the virtual storage
impact of %INCLUDE and oldstyle macro processing (by saving the SAS
log with source code to disk); it showed that the %INCLUDE and old
style macro processing required 6336K virtual storage. These tests
are summarized in the following virtual storage map:
TOTAL VIRTUAL MEMORY allocated 34269K
data set buffers (8451K)
macros/include processing (6336K)
generated program size (2181K)
task memory (4842K)
Unidentified (compiler,spvr,etc) 12459K
As a final reminder, this 34269K run was a very large BUILDPDB.
The default BUILDPDB in MXG 10.1 requires only 14857K! These tests
were run using ENTRY=SASHOST, so that all of the virtual storage
required came out of the user's address space. If your site has
installed SAS in the LPA and you use entry=SASLPA, you will see a
2M to 4M reduction in the virtual storage used by your ASID.
While this was informative, it turns out the real value of these
tests was the confirmation of my long-held belief that the use of
oldstyle (substitution) macros and %INCLUDEs has no significant
impact on the cost of execution (save for the 6M virtual storage).
The CPU time for the full blown BUILDPDB was 106.0 seconds; the
pure code run with no macros nor %INCLUDES was 94.5 seconds!
The blocksize used, 4096, IS NOT RECOMMENDED for MXG, but was
used so BUFSIZE could be iterated. MXG still strongly recommends
all of its SAS data libraries be built with half-track blocksize
(23040 for 3380, 27648 for 3390s), which causes BUFSIZE to also
be half-track, and with BUFNO=2, SAS will move one track of data
per physical I/O operation.
2. MEMSIZE and REGION. The SAS option MEMSIZE sets the total virtual
storage above AND below the 16MB line that SAS can use. The "very
large" BUILDPDB that needed 34269K total virtual was executed with
REGION=4M and MEMSIZE=38M, and the job's SYSOUT message IEF374I
shows VIRT 2072K EXT 32768K for a total of 34840K above and below.
The EXT 32768K value shows we were limited to 32M above the line,
which is the IBM default specified in IEFUSI. If the job actually
needed 42M, the job would fail because the 32M above plus the 4M
below total only 36M. We could have specified a REGION=9M
to get a total MEMSIZE of 41M, but the size of your private area
(typically 9M max) limits how much you can get below the line!
The solution is simple. Specify a REGION=42M, while overrides the
IEFUSI default of 32M, and you can get what you need. (Note that
you cannot specify a REGION value between the private area and 16M,
but a value greater than 16M is valid. Since the default BUILDPDB
in MXG 10.1 requires only 15M, few sites should have a problem!
3. SAS options can be restricted by your site's SAS installer. The
restrictions are in BAMISC(SASOPTRS) used by job BAOPT2(BAOPT2),
which creates a load module named SASOPT73 (was SASOPTRS in 6.06),
that must be in a linklist library. So how do you know that your
installer created this module? From TSO "READY", simply type in
SASOPT73. If you get a "COMMAND NOT FOUND" message, then there
are no local restrictions in effect; if you ABEND, you have the
proof that there are local restrictions placed on SAS options!
4. Multi-volume SAS datasets can be created as described in the
"SAS Companion for the MVS Environment", pages 533-534, but that
implementation requires permanent datasets to be allocated and
cataloged, and is not well suited for temporary data libraries like
//WORK that may need multiple volumes! Sites with System Managed
Storage, SMS, have what appears to be a superior solution that does
allow SAS to use multi-volume data libraries for temporary files.
You need only to have your SMS Storage Administrator create an SMS
Storage Class with the "Guaranteed Space" attribute. Since a volume
can be in multiple storage classes, you can pur your existing DASD
temporary workspace volumes in this STOCLASS. You then need only
to specify this STOCLASS for your WORK DD, with UNIT=(SYSDA,3), and
with VOL=SER=(VOL1,VOL2,VOL3) and you are home free! This works
because the "Guaranteed Space" attribute does two things. First,
it permits you to specify a VOLSER on your DD (normally, only SMS
itself can be the VOLSER godzilla!). Second, it allocates one
primary extent on each VOLSER you specify, thereby creating a DSCB1
entry with the same DSNAME in each VTOC, which is all that is
really required for SAS to be able to use the multiple volumes.
Note that the SMS name "guaranteed space" is a slight misnomer,
since SMS can't guarantee there will be free space on the volumes,
but it does guarantee that if the space you allocated is available
at initial allocation time, it will still be there until the job
ends. (In a non-SMS environment, UNIT=(SYSDA,3) allocates only the
first volume until it needs to go to the next volume, and your job
could die hours into its run if that third volume was full when you
finally needed it.) The IBM SMS manuals advice caution in the use
of "guaranteed space"; the only rationale I know is concerned with
archived and then restored by HSM, which requires the same VOLSERs
to have space for the restore, but that does not apply if your use
is for a temporary library that goes away at end of job! Your DASD
storage administrator may not like it because it takes control away
from SMS, but I know of no other objection, and this technique has
been in use by its discoverers, John Astle and Wayne Moray-Hype of
National Australia Bank for three months with no problems. By the
way, you could write ACS routines to select the VOLSERs and would
then not have to specify them on your DD statement. Additionally,
this technique can be used with a temporary or permanent DSNAME.
5. SAS 6.07 CMS had a problem with %INCLUDES; only the first library
in a concatenation was examined. Tracking 248801 is still open,
but using GLOBAL statement (see REXXTES6 example) circumvents!
6. SAS 6.07 ZAP Z6074721 corrects 0C4 ABEND in the %MACRO compiler if
a double ampersand (&&) was encountered.
7. Usage note 2665 (to be fixed in September 93 Maintenance) discusses
an ABEND of PROC COPY when a zero-observation dataset that has the
"Sorted" flag turned on is copied to a tape-format data library.
This ABEND only hit one MXG site, but since many sites copy their
Daily and Weekly PDBs to tape with PROC COPY (in fact, that is the
MXG recommendation for archiving), why did we not see this ABEND in
MXG testing of SAS 6.07? Well it turns out there are two different
kinds of zero-observation datasets, and the ABEND affects only one.
In SAS 6.07, a dataset now has a "Sorted" flag if that dataset is
known to be sorted by SAS (a "strong SORT assertion"). But if you
PROC SORT an input zero-observation dataset to an output dataset,
the "Sorted" flag is not enabled in the new dataset. Since all of
the MXG-built zero-observation datasets are built by PROC SORT from
zero-observation input datasets, none have the "Sorted" flag on,
and thus PROC COPY of MXG PDB's to tape did not fail. How do you
build a zero-observation dataset with the "Sorted" flag on? Well,
here's one way: OPTIONS OBS=0; PROC COPY IN=MON OUT=SAT; RUN;
to initialize a PDB library with zero-observation datasets. While
the MON.datasets that had zero observations are copied into SAT as
"NotSorted", all of the MON.datasets that had non-zero observations
are copied into SAT now as "Sorted", and if you now try to use a
PROC COPY IN=SAT OUT=TAPE (for example, to backup the SAT library),
the PROC COPY ABENDed! As you can see, the exposure to this SAS
error was extremely limited - in fact, only one MXG site reported
the error, though the problem did affect other SAS customers!
Note: the MXG Circumvention without the September maintenance
is to not backup SAT until you have put data in it!
8. INVALID HEADER for a dataset in the WORK library has occurred in
three sites, ABENDing the job, but a re-run has (thus far) always
been successful. Since the error has not been repeatable, the SAS
Institute folks can't work on the problem. Tracking 256220.
9. Complex nested parenthesis inside a SUM() function can result in
invalid values. This has not occurred in any MXG use of SUM(),
but was noticed in user report code. Zaps Z6073413,2570,and 4338
are required to eliminate the exposure.
10. PROC GPLOT fails with "THE SAS SYSTEM STOPPED PROCESSING THIS STEP
BECAUSE OF ERRORS" with no other error condition. The error occurs
when the input dataset has zero observations, and is corrected by
SAS Zap Z6071258.
11. SAS 6.07 may go into a CPU loop if the //WORK DD specifies multiple
volumes with UNIT=(SYSDA,3). As described in item 4, above, you
cannot use that MVS multi-volume specification for SAS libraries.
12. Although documented by SAS on page 65 of the SAS 6.07 Changes and
Enhancements, you may have overlooked that the XSWISS font name
no longer exists, and it must be replaced with SWISS.
13. SAS 6.07 may fail with an 0C4 ABEND due to an error in the SAS
Data Step Compiler. Temporary ZAP V6-SYS-DATA-5266 corrects the
problem (it will be on the May 1993 SAS Usage Notes tape) and this
problem appears to be avoided in SAS 6.08, so this is presently a
6.07-only problem.
14. SAS 6.07 error in the CCHHR option causes VMXGVTOC to miss extents
and produce "CRITICAL ERROR IN VTOC PROCESSING" if there are more
than three extents. SAS ZAP V6-SYS-FILE-4673 is available on the
June 1992 SAS Usage Notes Tape. This error was apparently only in
the CCHHR option, and not the similar but different CCHHR= option.
This error did not affect the recommended alternative to VMXGVTOC,
the ASMVTOC/VMXGVTOF members which are faster, better, and do not
use either CCHHR or CCHHR= options. This note was in Newsletter 22.
15. MXG has always shown JCL samples using the SAS or SAS607 procedure,
adding the CONFIG= parameter, and DDs for //LIBRARY and //SOURCLIB,
but now there is an MXGSAS JCL Procedure in the MXG Source Library.
All MXG JCL examples now use // EXEC MXGSAS to minimize JCL errors
for new users, and member INSTALL expects you to put MXGSAS in your
Proclib. However, MXGSAS is also an instream PROC in JCLTEST6 and
JCLPDB6 members, so you can test before putting it in PROCLIB.
Since the new install procedure suggests 'MXG.V1010.x.y' as the
High-Level for your testing of MXG 10.10, and then renaming the
'MXG.V1010.x.y' libraries to 'MXG.x.y' Production names, MXGSAS
defines MXGHLQ= as the MXG Hi-Level Qualifier, and SASHLQ for SAS
Hi-Level Qualifier, so Testing would use
// EXEC MXGSAS,MXGHLQ='MXG.V1010'
and after you have renamed the test libraries to production, only
// EXEC MXGSAS
is required. Note that CONFIG=MXG.MXG.SOURCLIB(CONFIG07) is not
required with MXGSAS, as (CONFIG07) is already inside the PROC.
For large volumes of input records, you can specify TIME= in CPU
minutes, WORK= space in cylinders (and in rare cases, SORT= wor
space in cylinders).
IX. Change Log
--------------------------Changes Log---------------------------------
You MUST read each Change description to determine if a Change will
impact your site. All changes have been made in this MXG Library.
Member CHANGES of the MXG SOURCLIB will always be more accurate than
the printed changes in a Newsletter, because the software is created
after the newsletter is sent to the printer!
Member CHANGES always identifies the actual version and release of
MXG Software that is contained in that library.
The actual code implementation of some changes in MXG SOURCLIB may be
different that described in the change text (which might have printed
only the critical part of the correction that can be made by paper).
Scan each source member named in any impacting change for any comments
at the beginning of the member for additional documentation, since the
documentation of new datasets, variables, validation status, and notes,
are often found in comments in the source members.
Alphabetic INDEX of significant changes in MXG 10.10 (since MXG 9.9):
Member Change Description
All 10.175 Powerful new "_L" and "_K" macros tailor MXG datasets
All 10.261 Support for MVS/ESA 4.3.
ADOCAAAA 10.087 Twenty-Five ADOCs documentation members now exist.
ANALDB2R 10.001 DB2 Report truncated character values.
ANALDB2R 10.034 SORTBY= operand parsed only the first SORT variable.
ANALDB2R 10.046 LIBRARY SMF IS NOT VALID message with PMSQL04 report.
ANALDB2R 10.047 DBID/OBID hex values printed instead of name.
ANALDB2R 10.055 Date/time selection in PMSACC01/02 produced no report
ANALDB2R 10.094 ANALDB2R Accounting report uses ASUMDB2A if exists.
ANALDB2R 10.135 DB2 Audit report may not be produced.
ANALDB2R 10.158 DB2 SQL Trace report FORMAT NOT FOUND error.
ANALDB2R 10.272 Buffer Pool statistics average values wrong.
ANALDSET 10.097 VSAM data sets may have wrong PROGRAM name.
ANALMONI 10.066 TMON/CICS sample report filled WORK file.
ANALRMFR 10.301 IBM's RMF reports produced from MXG datasets.
ANALRMFR 10.301 IBM-formatted RMF reports are now produced by MXG.
ASMIMSLG 10.084 Major revision in IMS log processing algorithms.
ASMIMSLG 10.142 Revision to "Appended" IMS log processing.
ASMIMSLG 10.191 "Appended" IMS process might miss RACF segment
ASMISMLG 10.146 New "Appended" IMS log processing works with IMS 2.2.
ASMTMNT 10.012 MXG Tape Mount Monitor supports Dynamic I/O Reconfig.
ASMTMNT 10.136 (MXG 10.1 only). ABEND S55F at startup.
ASMTMNT 10.226 MXG Tape Monitor sets TMNTRTRN=3 for MIM event.
ASMTMNTO 10.177 MXG Tape Mount Monitor for sites still on MVS/XA.
ASMVTOC 10.073 Avoid 213/314 abends reading VTOC of VM/TPF volumes
ASMVTOC 10.157 (MXG 10.1 only). Assembler error MSGAREA.
ASMVTOC 10.202 Use ASMVTOCO for ASMVTOC under MVS/ESA 3.1.3.
ASMVVDS 10.156 ASMVVDS fails with User 666 Abend.
ASUM70PR 10.131 PR/SM,MDF,MLPF summarization now supports 16 LPARs.
ASUM70PR 10.218 MXG 10.2 only, corrupted Effective/Management times.
ASUM70PR 10.284 Amdahl MDF LPARNUM=0 now supported.
ASUMDB2A 10.090 DB2 Account "transactions" summarized into ASUMDB2A.
BUILDPDB 10.117 BUILDPDB under SAS 6.07 needs changes.
BUILDPDB 10.129 Execution under CMS requires changes.
BUILDPDB 10.153 Step account variable SACCT1 now added to PDB.
BUILDPDB 10.190 JES APAR OY56235 filling SPIN library circumvention.
BUILDPDB 10.298 TOTLINES added to PDB.PRINT dataset.
CMS 10.129 SAS 6.07 under CMS has problems for MXG.
CONFIG07 10.109 Option S=72, s2=72 added to MXG Config members.
EXCICJRN 10.132 New exit for CICS journal data sent to SMF.
EXTY72 10.064 CPURCTTM PTF now exists, circumvention removed.
GRAFDB2 10.151 Not all DB2 graphs were produced.
GRAFLPAR 10.052 LPAR CPU utilization reports added.
GRAFTRND 10.049 Graphic trending reports were not always correct.
GRAFxxxx 10.227 SAS 6.07 replaced XSWISS font name with SWISS.
IMACACCT 10.119 Invalid type 30 subtype 1 SMF caused INPUT STATEMENT.
IMACDB2 10.149 CORRNAME/CORRNUM set from QWHCATYP now.
IMACDOS 10.168 Support for VSE DOS POWER Version 4.2 account records
IMACFACO 10.100 Fujitsu's FACOM MSP/EX SMF records now supported.
IMACFMTS 10.173 Member made archaic by SAS 6.07 FMTSEARCH option.
IMACICSA 10.164 Support for SAP Accounting data in CICS type 110.
IMACICUS 10.297 Optional HOGAN application variables in CICSTRAN.
IMACPDB 10.053 New macro _DB2ACCT added. Compatibility exposure.
IMACPDB 10.068 TAPE3490 (3490s allocated) added to PDB.STEPS/JOBS.
IMACPDB 10.133 PDB.JOBS can have JELPSTM missing when it should not.
JCLPDB6 10.127 (MXG 10.1 only) JCLPDB6 fails, TYPETMNT not found.
JCLTEST6 10.030 INVALID DATA FOR SMFTIME, SAS zap MV313550 required.
MNTH.... 10.091 Trending with INTERVAL=MONTH members added.
MONTHBLD 10.206 All JCLPDB6 PDB & ASUM.... datasets are in MONTHBLD.
READDB2 10.045 TRACECLS= parameter does not select all IFCIDs.
RMFINTRV 10.299 Additional statistics added to RMFINTRV dataset.
TRNDDB2A 10.093 TRNDDB2A Account Trending uses ASUMDB2A if exists.
TTXPDS 10.111 Verstand's TTX product is now included in MXG.
TYPE102 10.072 DB2 SQLCODE can be negative, MXG read as positive.
TYPE102 10.170 DB2 Trace IFCID 172 and 177 now tested and supported.
TYPE102 10.174 DB2 optimizer's cost estimate was incorrect.
TYPE102 10.183 DB2 Trace statement Numbers now print as decimals.
TYPE102 10.281 DB2 T102S044 lock fields were incorrect.
TYPE110 10.017 Invalid type 110 subtype 2 could cause MXG to loop.
TYPE110 10.038 Omegamon error causes INVALID DATA FOR SMFPSRSN.
TYPE110 10.059 Type 110 STOPOVER due to bad record eliminated.
TYPE110 10.061 Support for CICS/ESA 3.3.0 monitor (CICSTRAN) data.
TYPE110 10.062 Support for CICS/ESA 3.3.0 statistics datasets.
TYPE110 10.234 Enhanced CICS error messages for EXCLUDE/INCLUDE.
TYPE110 10.278 OMEGAMON/CICS V550 DATACOM SPE is incompatible.
TYPE110 10.280 Fourth TCBs CPU time was not included in CICINTRV.
TYPE24 10.037 Spool off-load type 24 can cause STOPOVER abend.
TYPE28 10.095 Blue Line's Vital Signs for VTAM type 28 supported.
TYPE28 10.106 NPM 1.5.1 NPMEVX25 (subtypes 144-150) error fixed.
TYPE28 10.134 Line PCTBUSY in each direction measured separately.
TYPE28 10.141 (MXG 10.1 only). INVALID DATA FOR NPMPDUTH.
TYPE28 10.155 NPM variables LLBSSTIM/LLBSPTIM incorrect.
TYPE28 10.264 Support for NPM Release 1.6
TYPE30 10.031 Variables ACTDLYTM, RESDLYTM, DSPDLYTM created.
TYPE30 10.108 Some APPC variables in TYPE30 have wrong value.
TYPE33 10.232 Error in processing SMF type 33 (APPC) records.
TYPE37 10.098 System Center's NETMASTER type 37 SMF record support.
TYPE37 10.167 Support for Type 37 Network Alert APAR OY49717.
TYPE39 10.040 INPUT STATEMENT EXCEEDED for subtype 5.
TYPE40 10.065 New dataset TYPE40_D can be created for tape analysis
TYPE41 10.015 DIV type 41 SMF record timestamps misdocumented.
TYPE42 10.005 Type 42 SMF record causes STOPOVER ABEND.
TYPE6 10.003 PSF type 6 record had FORM truncated.
TYPE6 10.124 Incompatible change to type 6 SMF record by PSF.
TYPE6 10.139 PRUWTR type 6 SMF record has incorrect READTIME.
TYPE6156 10.255 VSAM Data and Index component names & SMS data added.
TYPE70 10.256 TCP/IP SMF record defaults to type 70!
TYPE70 10.260 Negative CPUACTTM/PCTCPUBY in TYPE70 with PR/SM/
TYPE7072 10.010 TYPE70PR variable NRPRCS corrected.
TYPE7072 10.042 PCTRDYWT variable now created.
TYPE7072 10.317 GMT Offset, GMTOFFTM, available in MVS/ESA 4.3.
TYPE70x 10.320 Support for OpenEdition MVS, OMVS, RMF records.
TYPE71 10.014 SWAP counts corrected.
TYPE73 10.179 ESCON converter flag variable ESCACVC not set.
TYPE73 10.247 MVS/ESA 4.2.2 EMIF Feature corrupts TYPE73 data set.
TYPE73 10.259 Only real channels create TYPE73 observations now.
TYPE74 10.137 MVS/ESA XCF Type 74 causes INPUT STATEMENT EXCEEDED.
TYPE75 10.099 MVS/ESA 4.2.0 changed format of DEVNR/UNITADR.
TYPE78 10.201 CMF Type 78 incorrect R783CPDN value causes 0 obs.
TYPE79 10.123 Type 79 subtype 1 corrections.
TYPE79 10.283 RMF 79 records appear to be un-deaccumulatable.
TYPE80 10.114 CA TOP SECRET caused INPUT STATEMENT EXCEEDED error.
TYPE80A 10.251 RACF events consolidated in new TYPE80A dataset.
TYPE84 10.224 JES3 type 84 INPUT STATEMENT EXCEEDED error.
TYPE94 10.285 Support for IBM 3495 Tape Library Dataserver SMF.
TYPEAICO 10.048 Support for AICorp's KBMS user SMF record.
TYPEAIM6 10.161 Support for FACOM's AIM Version 12 type 116 SMF.
TYPEAPAF 10.078 Support for Amdahl's APAF replacement for MDFTRACK.
TYPEAPAF 10.143 Variable Balance not kept in APAFDOMA
TYPEASTX 10.245 Support for Legent's ASTEX Trace Record
TYPECIMS 10.063 IMF flag variables wrong if multiple bits are on.
TYPECMF 10.230 Boole's CMF variable R783PT in error.
TYPECMF 10.292 Support for IMF Release 2.8.
TYPEDB2 10.024 MVS Account fields added to DB2ACCT!
TYPEDCOL 10.071 INVALID VALUE FOR FUNCTION DATEJUL message.
TYPEDCOL 10.148 DCOLBKUP variables UBALLSP,UBUSESP,UBRECSP wrong.
TYPEDCOL 10.221 DCOLLECT variable UCTOTAL was incorrectly documented.
TYPEDCOL 10.307 DCOLLECT SMSDATA writes SMF constructs records.
TYPEF127 10.162 Support for FACOM PDLF Type 127 for MSP/EX Version.
TYPEFTP 10.176 NETVIEW FTP SMF record timestamps reversed.
TYPEHIPR 10.300 Support for Empact's HiperCache SMF records.
TYPEHPCS 10.178 Support for HP Unix (HP/UX) PCS Performance Data.
TYPEHPCS 10.294 HP's MPE operating system records now supported.
TYPEHSM 10.080 FSTTRKR/W large values are actually negative values.
TYPEIDMS 10.219 IDMS variable DBKDBKEY was incorrectly documented.
TYPEIDMS 10.265 Support for IDMS Release 12 PM records confirmed.
TYPEILKA 10.121 Invalid data because incorrect offset/documentation.
TYPEIMSA 10.142 STRTTIME/ENDTIME/INPQUETM/SERVICETM/RESPNSTM wrong.
TYPEIMSA 10.205 NMSGPROC value wrong. Must use ASMIMSLG for IMS log.
TYPEIMSA 10.288 Zero service time corrected.
TYPEITRF 10.273 Support for Candle's IMS Trans Report Facility,ITRF.
TYPEM204 10.120 MODEL204 variable M24IODEV input, EXM24ACT eliminated
TYPEMON8 10.020 Landmark CICS "INVALID OFFSETS" message.
TYPEMON8 10.067 MONITASK variables STRTTIME/CREATIME now equal.
TYPEMON8 10.145 Landmark CICS variable TAMRCNT input incorrectly.
TYPEMON8 10.271 Support for Landmark's/CICS Release 9 and Release 1.
TYPENATP 10.033 Support for Software Ag "Natural Process" SMF record.
TYPENETP 10.039 NETPACTM was total response, should be average.
TYPENRS 10.075 Support for The Network Director North Ridge Software
TYPENSPY 10.015 Support for NETSPY Token-Ring records added.
TYPENSPY 10.057 Support for NETSPY Release 4.2 added.
TYPENSPY 10.144 NETSPY type 'N' records cause INPUT STATEMENT EXCEED.
TYPENSPY 10.262 Support for NETSPY Release 4.3 and LANSPY 1.1
TYPEOMCI 10.182 Omegamon V550 ESRA (user) SMF "INPUT EXCEEDED".
TYPEOMVT 10.194 Support for OMEGAMON II for VTAM V150 user SMF.
TYPEOPC 10.112 Major revision for OPC/A log processing.
TYPEOPC 10.204 Support for Changes to OPC records.
TYPEOPC 10.302 RECFM= parameter removed so RECFM=U data can be read.
TYPEORAC 10.291 Support for Oracle 6.0.33.1.51.
TYPEPOOL 10.274 Support for Empact's POOL-DASD user SMF record.
TYPEQAPM 10.110 Support for AS400 V2R1M0 and restructured members.
TYPERMDS 10.102 RMDS messages INVALID DATA FOR RMDSMXVR eliminated.
TYPEROSC 10.022 Support for ROSCOE Release 5.7 changes to SMF data.
TYPEROSC 10.101 ROSCOE ADSFUN.. variables values corrected.
TYPEROSC 10.138 ROSCOE JCK and Documentview added to ROSCOVPE.
TYPERSxx 10.319 Support for RS6000 AIX VMSTAT,IOSTAT,PS commands.
TYPESFS 10.186 Support for XEROX Printer's SFS Status File System.
TYPESIM 10.180 Support for SIMWARE SIM/XFER VTAM user SMF record.
TYPESIM 10.222 SIMWARE initial support revised.
TYPESLRI 10.290 SLR-like IMS log processing for Fast Path.
TYPESMF 10.019 Header/Trailer messages on log were not always right.
TYPESPMS 10.011 SPMS R2.1.4 invalid record circumvented.
TYPESPMS 10.069 SPMS 1.2.13 inserted four byte field, causing errors
TYPESTC 10.105 STC 4400 decode used wrong bits of STC07TYP.
TYPESTC 10.116 STC4400 HSC SMF record for Release 1.2 incompatible.
TYPESTC 10.193 STC 4400 Silo HSC variables formatted.
TYPESTC 10.229 STC 4400 variables LSBECON1/2 incorrectly documented.
TYPESYNC 10.115 SYNCSORT variable COREREQ can be negative.
TYPETCP 10.184 Support for IBM's TCP/IP Version 2 Release 2 SMF.
TYPETIRS 10.181 Support for IBM type 96 SMF record from TIRS.
TYPETMNT 10.200 Legent's MIM corrupts MXGTMNT Tape Mount count.
TYPETMS5 10.060 TMS inactive DSNBs now deleted, caused wrong VOLSER.
TYPETMS5 10.082 TMS.TMS had DSNB fields, TAPEFEET calculation changed
TYPETMS5 10.185 DSNBs could have been skipped.
TYPETMS5 10.196 TMS Billing-by-dataset enhanced in DSNBRECD dataset.
TYPETMS5 10.289 "Dead" tapes no longer create DSNBRECD observation.
TYPETMVS 10.058 TMON/MVS "INVALID DATA for WKLCPURF" message.
TYPETPX 10.007 TPX variable TPXELAP has wrong value.
TYPEVM 10.233 VMSQLxxx datasets enhanced for SQL/DS under VM.
TYPEVMXA 10.036 VM/ESA 1.1.1 additions now supported.
TYPEVMXA 10.071 VM/ESA VXSYTCUP dataset has only 49 observations.
TYPEVMXA 10.163 Candle's VCOLLECT 5.1.0 still writes invalid "VVBs".
TYPEVMXA 10.244 Support for VM/ESA Release 2.0.
TYPEWSF 10.081 Support for RSD's WSF/WSF2 Release 3.4.1.
TYPEWSF 10.150 WSF 3.3.6 caused error (no problem with 3.4.1).
TYPEX37 10.013 STOPX37 Release 3.4 is supported.
TYPEX37 10.276 Support for Empact's STOPX37 Release 3.5.
TYPEXAM 10.231 Support for Velocity Software's XAMAP History files.
TYPEXCOM 10.165 Support for XCOM 6.2 Version 2.2.2G SMF record.
VMXGHSM 10.254 HSM dates TTOCDLR and TTOCXPDT were wrong.
VMXGSUM 10.089 MINTIME=,MAXTIME= parameters added to VMXGSUM.
VMXGVTOC 10.018 CRITICAL ERROR IN VTOC if DSORG=PS-SUL data found.
VMXGVTOC 10.054 ISAM index space not recognized in VTOC.
VMXGVTOC 10.243 SAS 6.07 ZAP V6-SYS-FILE-4673 required.
VMXGVTOF 10.125 Variable DS4VTOCE input but not kept.
VMXGVTOF 10.171 VTOCs with freespace starting in track 1 missed it.
WEEKBLD 10.008 NOT SORTED when implementing MXG 9.9
WEEKBLD 10.009 TYPE70PR,DB2ACCT/STAT0/STAT1 added to weekly/monthly.
WEEKBLD 10.206 All JCLPDB6 PDB & ASUM.... datasets are in WEEKBLD.
WEEKBLD 10.225 BY list for WEEK.ASUM70PR wrong.
XMAC7072 10.023 344 Compiler circumvention causes UNINITIALIZED msg.
XUNIX 10.076 Support for ULTRIX UNIX iostat and vmstat commands.
Inverse chronological list of all Changes:
---Changes 10.323-10.105 were printed in MXG NEWSLETTER TWENTY-THREE---
and can be found in member CHANGES of MXG Version 10.10