COPYRIGHT (C) 1984-2021 MERRILL CONSULTANTS DALLAS TEXAS USA
MXG NEWSLETTER TWENTY-EIGHT
****************NEWSLETTER TWENTY-EIGHT*********************************
MXG NEWSLETTER NUMBER TWENTY-EIGHT August 21, 1995
Technical Newsletter for Users of MXG : Merrill's Expanded Guide to CPE
TABLE OF CONTENTS Page
I. MXG Software Version 13.05 is now available upon request. 2
II. MXG Technical Notes 4
1. Support for the Year 2000. 4
2. Tape activity shows EXCPs without any tape mounts 6
3. How can I have 10 digits printed for a variable of length 4? 7
III. MVS Technical Notes 7
1. APAR OW06770 corrects MVS/ESA 5.1 type 72 fields 8
2. Boole & Babbage CMF invalid STARTIME corrected by BMP5061/5322. 8
3. TYPE42DS does not record activity on all datasets. 8
4. MVS/ESA 5.1 Goal Mode sites need MXG 13.01 or later 8
5. My current understanding and research on LEAPSECONDS. 8
6. MVS RMF APAR OW12017 corrects many RMF problems. 9
7. MVS/ESA 5.1 APAR OW11733 corrects trashed type 72 fields. 9
8. High MVS Uncaptured CPU time caused by GTF trace. 9
9. NETVIEW FTP APAR PN71477 corrects SMF record 0 instead of 118. 9
10. APAR OW13375 corrects variable TTRN in TYPE1415. 9
11. TYPE42AU dataset has invalid MVS volume status, OW11153 fixes. 9
12. Type 6 records invalid data by NFP FSS writer, PN72812 open. 9
13. TYPE6 observations may indicate DUPLEX when you think SIMPLEX. 10
14. EXCP counts in type 30 for VSAM hardware compressed datasets. 10
15. SMF VSAM dataset CISIZE allocation changed by VSAM. 10
IV. DB2 Technical Notes 10
1. DB2ACCT CPUTCBTM/DB2TCBTM capture for Distributed work. 10
2. DB2ACCT CPUSRBTM/DB2SRBTM invalid, always. 10
V. IMS Technical Notes 11
1. IMS APAR PN45106, CPU time recorded increased by LSO=S. 11
VI. SAS Technical Notes 11
1. SAS ABENDS out of space in WORK.@Tnnnnnn.UTILITY 11
2. MXG FORMATS OTHER= syntax is incompatible with SAS 5.18 12
3. Character variables assigned $MGxxxxxx formats need LENGTH 12
4. SAS data libraries cannot be hardware compressed. 12
5. Out of Memory errors if site restrictions are in effect 12
6. HEX15. and HEX16. formats produce unexpected (but neat!) output. 13
VII. CICS Technical Notes 13
1. APAR PN71965 discusses contents of TERMINAL in AOR records 13
2. APAR PN70771 variable USER is not cleared between tasks 13
VIII. Incompatibilities and Installation of MXG 13.05. 14
1. Members and products incompatibly changed. 14
2. Installation instructions. 15
IX. Online Documentation of MXG Software. 15
X. Changes Log 17
Alphabetical list of important changes 17
Changes 13.162 thru 13.001, 12.328 thru 12.315 19-56
(Changes 12.304-12.129 were in Newsletter 27)
COPYRIGHT (C) 1995 BY MERRILL CONSULTANTS DALLAS TEXAS
I. MXG Software Version 13.05 is now available upon request (it is NOT
shipped with this newsletter - you must ask for it and it is free!).
Major enhancements added in MXG 13.05 dated August 21, 1995:
Support for the year 2000 (see MXG Technical note).
Support for OpenMVS File System I/O type 92 SMF record.
Support for MVS/ESA 5.2 System Logger Data type 88 SMF record
Support for EREP (SYS1.LOGREC) records.
Deaccumulation of HMF records.
MAINTLEV 6 of ASMTAPES enhancements for MXG Tape Mount Monitor.
Final (?) Correction to ANALDB2R Statistics and Audit Reports.
If you use either the DB2 Statistics reports or DB2 Audit Reports,
you must request MXG 13.05 for the ANALDB2R corrections to errors
introduced in MXG 12.12 (Statistics) or MXG 13.01 (Audit) that were
not fixed until now (I apologize for the careless coding and lack
of validation of report output that took seven iterations to fix).
The Audit errors were actually corrected in 13.03, but Statistics
still had four values that were not corrected until MXG 13.05.
The more-commonly-used DB2 Accounting Reports had no errors.
Major enhancements added in MXG 13.04 dated Jul 31, 1995:
Support for NetCompress SMF records.
Support for Packet/Main SMF records.
Support for Kodak AXCIS Optical Disk SMF records.
Major enhancements added in MXG 13.03 dated Jul 19, 1995:
More fixes for DB2 Statistics Reports, a fix for DB2 Audit Reports.
TYPE116 (MQM) validation and correction.
Major enhancements added in MXG 13.02B dated Jul 6, 1995:
Correction to DB2 Statistics Summary and Audit Reports
MXG Position Paper on Support for Year2000 in member YEAR2000.
Major enhancements added in MXG 13.02A dated Jun 28, 1995:
Correction to DB2 PMSSTA01/02 Statistics Summary Reports.
Final (?) revisions to XMXGSUM.
Major enhancements added in MXG 13.02 dated Jun 19, 1995:
Support for MVS/ESA 5.2 (compatible) changes 24, 30, and 42 records.
Support for OPC Release 3.0 (INCOMPATIBLE).
Support for DFSORT Release 13.0 (INCOMPATIBLE).
Support for TMS (CA-1) Release 5.1 (compatible).
Support for Antares' HURON ObjectStar SMF record.
Support for TYPE32 APARS OW10393 (causes error) and OW12856 (none).
Support for SAP Release 5.0 CICS accounting in type 110.
Support for ACS Wylbur Accounting SMF record
Support for Sterling SAMS Storage Automation SMF record.
Support for LEGENT's AUTOMATE SMF record.
DB2 Audit SQL text corrections.
Support for APAR OW08641 for NPM Version 2.2
Major enhancements added in MXG 13.01 dated May 3, 1995:
Support for NETSPY Release 4.6 (compatible), divide by zero fixes.
Support for HP PCS current version on HPUX, AIX, and SUN unix.
Support for OS/400 Version 3.1.0 (was wrong in MXG 12.12/12.12A).
Support for TCP/IP APAR PN69321-PN69322.
Support for Sterling SOLVE NCL CPU-time accounting user SMF.
Support for HMF SMF record subtypes 4 and 5.
Support for APAR OW04653 added variables to TYPE74ST dataset.
Support for IBM's IRRDBU00 RACF Database Unload.
ASMRMFV 0C4 correction and enhancements for RMF VSAM processing.
ANALCNCR enhancements and validation.
XMXGSUM enhancements and validation.
TYPE116 (MQM) validation and correction.
Major enhancements added in MXG 12.12A dated Mar 20, 1995:
Twelve MXG 12.12 members had errors that are now fixed:
ANALCNCR ANALDB2C ANALDB2R ANALPATH ANALTALO IMACICSA
TRNDTALO VMAC80A VMAC110 VMACILKA TYPEMON8 TYPETMON
Support for Memorex/Telex LMS Version 3.1 (INCOMPATIBLE).
All of these enhancements are described in the Change Log, below.
Table of availability dates for the IBM products and MXG version:
Availability MXG Version
Product Name Date Required
MVS/ESA 4.1 Oct 26, 1990. 8.8
MVS/ESA 4.2 Mar 29, 1991. 9.9
MVS/ESA 4.2.2 Aug 1991. 9.9
MVS/ESA 4.3 Mar 23 1993. 10.10
MVS/ESA 5.1.0 - compatibility Jun 24, 1994 12.02
MVS/ESA 5.1.0 - Goal Mode May 3, 1995 13.01
MVS/ESA 5.2.0 Jun 15, 1995 13.02
CICS/ESA 3.2 Jun 28, 1991. 9.9
CICS/ESA 3.3 Mar 28, 1992. 10.01
CICS/ESA 4.1 Oct 27, 1994. 12.04
CICS/ESA 4.2 when G.A. 13.??
CRR 1.6 Jun 24, 1994. 12.02
DB2 2.2.0 1990 8.8
DB2 2.3.0 Oct 28, 1991. 10.01
DB2 3.1.0 Dec 17, 1993. 13.02A
DB2 4.1.0 when G.A. 13.??
DFSMS/MVS 1.1 Mar 13, 1993. 11.11
DFSMS/MVS 1.2 Jun 24, 1994. 12.02
NPM 2.0 Dec 17, 1993. 12.03
NPM 2.2 Aug 29, 1994. 12.05
VM/ESA 1.1.1 Dec 27, 1991. 10.01
VM/ESA 2.0 Dec 23, 1992. 10.04
VM/ESA 2.1 Jun 27, 1993. 12.02
VM/ESA 2.2 Nov 22, 1994. 12.06
Table MXG support for non-IBM products:
Availability MXG Version
Product Name Date Required
Landmark
The Monitor for DB2 - See Note 1. 12.12
The Monitor for CICS/ESA 1.2 - 12.12
The Monitor for CICS/ESA 1.3 - 12.12A
The Monitor for MVS/ESA 1.3 - 12.05
Candle
Omegamon for CICS V300 User SMF 12.05
Omegamon for IMS V110 (ITRF) 12.12
Omegamon for MVS - last MXG change 1992 12.12
Omegamon for DB2 Version 2.1/2.2 13.05
Omegamon for VTAM V160 12.04A
Omegamon for SMS V100/V110 12.03
Boole & Babbage
IMF 3.1 (for IMS 5.1) 12.12
Memorex/Telex
LMS 3.1 12.12A
======================================================================
II. MXG Technical Notes.
1. Support for the Year 2000.
a. Date and date-time variables in MXG-built SAS datasets have always
internally supported the year 2000:
Date variables are stored as 4-byte floating-point number-of-days
since 01Jan1960, and will not overflow for 45,925 years. All date
variables now have a default format of DATE9, causing them to display
as 08Aug1995, showing the full four-digit year.
Datetime variables are stored as 8-byte floating point number-of-
seconds since 1Jan1960, and will not overflow for 2283 million years.
Datetime variables now have a default format of DATETIME21.2, so they
display as 05Jul1995:12:52:59.99, showing the full four-digit year.
b. However, MXG dates/datetimes will be valid in 2000 only if the
field in the data records read by MXG actually contain valid Year2000
dates. I have examined all date-containing fields read-in by MXG
Software, and these thirty-six products do not currently have enough
field width to support the year 2000:
IBM Products Which do not provide valid Year2000+ dates:
MVS CICS SMF type 110
MVS DFP SMF type 36
MVS DFP VTOC
MVS NETVIEW NPM SMF type 28
MVS RMF SMF type 73, 74, 78
MVS SMF SMF type 14, 15
MVS HSM SMF user records
MVS OPC Log records
MVS RMDS Log records
MVS NCCF Log records
MVS SYSLOG Log records
OS400 Accounting All Accounting/Performance Records
OS400 Trace Trace Data
VM VM ACCOUNT Accounting Records
VM VM/370 Monitor *Performance Record
Other Vendor Products which do not provide valid YEAR2000+ dates:
Boole & Babbage CICS/Manager
Boole & Babbage CONTROL-D
CA SAR
CA NETSPY
CA XCOM
CA VM/EXPLORE
Fujitsu PDL Reports
FUJITSU Type 127 SMF record
FUJITSU Type 234 SMF record
GOAL SYSTEMS PDSMAN/XP
LANDMARK TMON/CICS
LANDMARK TMON FOR DB2
LANDMARK TMON FOR MVS
Mobius Infopac
NOMAD NOMAD
ODS ODS/ODI Optical Disk SMF record
SAP SAP IMS log record type AEx
STERLING DMS
VELOCITY SOFTWARE ESAMON
VOLVO (EUROPE) SESAME
XEROX Shared File System Print Accounting
c. In addition, 59 products use a four-byte packed-decimal julian
date field, which can support the year 2000, but only WILL support
it when the vendor has populated the first byte. The vendor can use
either a century bit ('0cyyydddF'x, which IBM uses in SMF records),
or a four-digit year ('yyyydddF'x) can be populated. Each of those
PD4 vendor fields must be validated by the vendor that they do
support the year 2000, and documented as to their format. Vendors
using the TIME macro need only verify that fact, as the TIME macro
returns the century bit, whereas vendors using the STCK macro will
have to change their code to populate the first byte, which means
their products won't support the year 2000 until that vendor change
has been installed on your system. These products require either
validation or change for their PD4 date fields:
Vendor=IBM:
MVS APPC SMF type 33
MVS Batch Pipes SMF type 91
MVS BDT SMF type 59
MVS CICS SMF type 110
MVS DFP CATALOG SMF type 36
MVS DFSORT SMF type 16
MVS JES2 NJE SMF type 57
MVS JES2 SMF type 6
MVS JES2 SMF type 24
MVS JES2 SMF type 26
MVS JES3 SMF type 25
MVS JES3 SMF type 26
MVS JES3 SMF TYPE 84
MVS MULC SMF type 89
MVS NETVIEW NPM SMF type 28
MVS NETVIEW NPM SMF type 37
MVS RMF SMF type 70-79
MVS SMF SMf type 4,5,7,14,15,30,32,34,35,90
MVS HSM SMF USER RECORD
MVS DCOLLECT IDCAMS output
MVS RMM EDGS Extract output
MVS FTP SMF record
MVS HSM SMF RECORDS
MVS IMS LOG Log records
MVS OPC Log records
MVS HSM MCD/BCD/ Log records
MVS DFP VTOC
MVS NETVIEW NCCF
VM VM ACCOUNT Accounting
Vendor Product
AION AION
ALTAI ZARA
BGS BGS I/O MONITOR
BOOLE IMF
CA IDMS SMF RECORD
CA ROSCOE
CA SAR
CA NETSPY
CA TMS
CA XCOM
CA (GOAL SYSTEMS) PDSMAN/XP
CANDLE OMEGAMON AUDIT SMF RECORD
CANDLE OMEGAMON FOR VTAM
CANDLE ITRF
CINCOM SUPRA LOG RECORD
COMPUWARE FILEAID
LANDMARK TMON/CICS
LANDMARK TMON FOR DB2
LANDMARK TMON FOR MVS
NETWORK SYSTEMS HMF (HyperChannel or DXE)
NOMAD NOMAD
RSD WSF
SAP CICS JOURNAL
SIMWARE SIM/XFER
SOFTWARE AG'S NET-PASS
STERLING DMS SMF USER RECORD
STK ICEBERG
SYSTEM CENTER NDM (NETWORK DATA MOVER)
SYNCSORT SYNCSORT
VOLVO (EUROPE) SESAME
d. The SMFSTAMP, and RMFSTAMP input formats do support the century
bit, but not the four-digit year julian format. The DATEJUL function
supports the four-digit year, but not the century bit, and the MDY
MDY function does not accept YY=100 (i.e., cyy) as a valid year.
SAS Institute is investigating how to provide both support and
consistency for its date functions and informats, and I expect that
a combination of changes, new functions and new input formats may be
required for all possible date formats to be supported by SAS. But
because those changes will not be available until SAS version Seven,
MXG has been modified to protect all of its uses of DATEJUL and MDY
functions. The extensive details can be found in Change 13.159.
e. MXG member YEAR2000 contains the detail list of fields that must
be changed or validated by their vendors. That member will be
updated as vendors make changes and notify Merrill Consultants of
their changes to support the year 2000. Feel free to hassle your
friendly vendor when you see their product on that list.
2. Analysis of Tape Activity from PDB.JOBS and PDB.STEPS can show tape
EXCPs without any tape mounts. How can this be? Let's first look
at the tape-related variables in the PDB.STEPS dataset:
TAPNMNTS - Scratch and Private Tape Mount count, but this only
TAPSMNTS includes the mounts issued by MVS. In JES3, any
mounts managed by MDS will not be counted in the type
30 records (although they are counted in the
JES3-only TYPE25 dataset); JES3 second-volume mounts
and first-mount for non-MDS mounts (including dynamic
allocations) will be counted in the type 30 records.
EXCPTAPE - Count of EXCP (from TIOT in type 30) to TAPE devices
that were allocated to this step.
TAPEDRVS - Count of unique tape devices addresses that were
allocated by this step, both statically (i.e., in the
JCL) and dynamically.
However, there is no guarantee that this many tape
drives were concurrently allocated; if a task like
HSM dynamically allocated a tape 10 times in a run
and happened to get 10 different drives, TAPEDRVS
would be 10, but if HSM just happened to get the
same drive each time, then TAPEDRVS would be only
one. Also, we do not know how long the tapes
were allocated; for static allocation it is the
step EXECTM, but for dynamic allocation or
deallocation (eg., FREE=CLOSE) we do not know when
the tape device use began nor ended.
So now how can we have EXCPTAPE with no TAPNMNTS+TAPSMNTS?
In the STEPS data set, we could have:
- JES3 MDS mounts are not counted, but EXCP to all tapes are, or
- First step mounts, second step uses, second step record will
count EXCPTAPE but no tape mounts, or
- In all cases, if we have EXCPTAPE non-zero we must also have
TAPEDRVS non zero.
In the JOBS data set, since we sum step records to create the
job resources, we could have:
- JES3 MDS mounted all tapes for the job, or
- SPINCNT (defined in IMACSPIN) too small, and a job that was
still running when SMF was dumped. If SPINCNT=0, today's
steps will be summarized into todays PDB.JOBS, while tomorrows
steps will be in tomorrow's PDB.JOBS, and if all of the mounts
occurred in today's steps, tomorrows PDB.JOBS would have EXCP
counts without tape mounts.
- Extremely unlikely, but if IMACPDB were incorrectly modified
by the site, many variables in JOBS could be wrong, because
- We still must have TAPEDRVS non zero for EXCPTAPE non-zero.
3. How can I have 10 digits printed for a variable of length 4 bytes?
Maximum integer values that can be stored by SAS.
A four-byte binary field, INPUT as PIB4., can contain a maximum
integer value of of 4,294,967,296. All SAS numeric variables are
stored as floating point numbers, with one byte for exponent and the
remainder of the stored length as the mantissa.
For MVS, these integer values can be represented exactly with these
stored lengths:
Length Largest Integer Significant Digits
2 256 2
3 65,536 4
4 16,777,216 7
5 4,294,967,296 9
6 1,099,511,627,776 12
7 281,474,946,710,656 14
8 72,057,594,037,927,936 16
For PC/Unix, these integer values can be represented exactly with
these stored lengths:
Length Largest Integer Significant Digits
2 Not ALLOWED
3 8,192 3
4 2,097,152 6
5 536,870,912 8
6 127,438,953,472 11
7 35,184,372,088,832 13
8 9,007,199,254,740,992 15
SAS stores numerics in 8 bytes, but MXG uses LENGTH DEFAULT=4 for
almost all numerics, saving considerable DASD space, but raising
the question of accuracy. Consider this example program:
DATA; LENGTH X 8 Y 4;
X=4294967295;Y=X;OUTPUT; PUT X= Y=;
X=X+1;Y=Y+1;OUTPUT;PUT X= Y=;
X=X+1;Y=Y+2;OUTPUT;PUT X= Y=;
PROC PRINT;
The PUT statements all have Y equal to X exactly, because numeric
variables are always length 8 when created in a data step; it is not
until the observation is OUTPUT to a data set that its stored length
comes in to play, as the output of the PROC PRINT shows:
X Y
4,294,967,295 4,294,967,040
4,294,967,296 4,294,967,296
4,294,967,297 4,294,967,296
Here we can see that the 4-byte variable Y prints 10 digits, and that
while its value can be exact for certain powers of 2, the value can
be smaller by as much as 255 (out of 4 billion) due to truncation.
For most MXG variables, that is truly insignificant. However, there
are classes of MXG variables which are always longer than 4-bytes:
All Datetimestamp variables - length 8
Large value accounting (DASD bytes, Service Units)- length 8
Four byte numerics containing hex values (UCBTYPE) - length 5
Any variable with value greater than 16777216 that must be exact.
III. MVS Technical Notes after Newsletter TWENTY-SEVEN.
1. APAR OW06770 and OW09814 (PTFs UW10049 and UW14370) correct type 72
wrong values in MVS/ESA 5.1 fields SMF72ACT SMF72SER SMF72MTS
SMF72ITS SMF72CTS SMF72TAT and SMF72STS. Bad values occurred in any
interval in which a CICS region was FORCED or a batch job terminated
at end of memory. The bad values were all '7FFFFFFF'x, which in MXG
(being read as PIB4.) is 2,147,483,647!
2. Boole & Babbage CMF 5.1 creates RMF records with incorrect STARTIME
(type 72 STARTIME is 1 second earlier or later than 70 and 71) when
SYNC is specified, which causes MXG's RMFINTRV dataset to calculate
incorrect uncaptured CPU times. Boole's fix is BPM5061 & BPM5322.
MXG produced "ERROR.RMFINTRV.INCONSISTENT RMF DATA" messages.
3. TYPE42DS (dataset level I/O monitoring) does not capture activity on
all datasets. For Concatenated BPAM, there is only one type 42 SMF
record written, and it contains only the name of the first dataset
in the concatenation; there is not even any indication that there
were other datasets behind this DDNAME. (Note that type TYPE1415
has always had part of this problem - there too you only get the
name of the first dataset in the concatenation, but at least in the
14/15 records, there is a UCB segment for each dataset with the
UCB address and EXCP count to each member of the concatenation.)
Finally, note that "Concatenated BPAM" means that you have PDS data
sets concatenated without member names in the JCL. (If there are
member names in your JCL, then BSAM is used instead of BPAM, and
you will get a separate 14/15 record for each dataset.)
4. MVS/ESA 5.1 in Goal Mode sites need MXG 13.01 or later when you
begin to stress your Coupling Facility, especially with Data Sharing
applications. IBM moved structure data (TYPE74ST) incompatibly, and
added new stats on storage allocation (how much for LISTs, how much
for CACHE) that seem to be very important in sizing your allocation,
and MXG had errors (no test data for validation until MXG 13.01).
The TYPE74CF and TYPE74ST datasets are the focal point of analysis
if you suspect delays due to the Coupling Facility.
5. My current understanding and research on LEAPSECONDS:
LEAPSECONDS only exist in the sysplex timer environment, and the
current value of leap seconds was 18 seconds in 1995 (and is now
20 seconds in June, 1997).
There are two common timestamps output into SMF records:
TODSTAMP is the 8 byte time-of-day IBM "STCK" clock format.
SMFSTAMP is the 4-byte time, 4-byte date in packed decimal format.
There are three clocks which can be used:
Absolute Clock - time value includes leap seconds and is on GMT
GMT Clock - GMT value without leap seconds
Local Clock - SMF Time and Console Time stamps.
There are two macros which supply time to an assembly routine:
TIME returns a local time value that DOES NOT include leap seconds
and can return the time in many formats, including SMFSTAMP,
TODSTAMP, Timer Units, Microsec, or Binary).
STCK returns the "Absolute" TIME, a GMT value that DOES include
leap seconds, and only returns the time in TODSTAMP format,
although macros CONVTOD and STCKCONV can be used to take the
output of STCK and convert it to other formats.
But the assembly program could use either macro to get the tod and
use either format for its output, so you can't tell by the informat
whether the timestamp includes or excludes leapseconds.
JES2 APAR OY67004 corrects type 6, 24, and 26 timestamps to include
leapseconds in its conversion of STCK time from Absolute to local.
See text of APAR OW12750 for a very detailed explanation of the
SMF "Midnight Value" calculation.
MVS/ESA 4.3 Type 42 interval records for CLOSE show SMF42PTE 18
seconds later than SMFTIME, indicating incorrect direction of
conversion. This was thought to be an error, but now (JUN97) it
is recognized that the "GMT" value in SMF42PTE is actually from
the "Absolute" clock, which included 18 leap seconds!
The SAS functions TIME(), DATE(), DATETIME() and &SYSTIME use the
STCK command and do not include leapseconds when converted to the
local time you get back from SAS. SAS Institute has been requested
to enhance these functions to include leapseconds.
6. MVS RMF APAR OW12017 corrects many RMF problems, some affecting RMF
records, while some fixes apply only to the RMF report program.
7. MVS/ESA 5.1, RMF72 performance group data occasionally trashed (very
unreasonable values in several variables) is reportedly fixed by IBM
APAR OW11733 with PTF UW18509 for 5.1. There apparently is a 4.3
PTF as well.
8. High MVS Uncaptured CPU time (CAPTURAT in RMFINTRV dropped from 92%
to 77%) was the result of running GTF to trace a job, but the job
name being traced was not in the system during trace. The requested
trace was
TRACE=DSP,USRP,SYS,JOBNAMEP
TRACE=JOBNAME(XYZ12345)
It may be that GTF always causes uncaptured CPU time, but certainly
in this specific case it was quite noticeable!
9. NETVIEW FTP MVS 221 Server writes SMF record with record ID=0, even
if FTP SMFREC initialization parameter was not set by installation.
APAR PN71477 corrects the error.
10. TYPE1415 variable TTRN contains incorrect last track of data set
after a partial release. APAR OW13375 corrects this error.
11. TYPE42AU data set contains invalid new MVS volume status during vary
online/offline of SMS managed volume. APAR OW11153 corrects.
12. TYPE6 records created by NPF FSS writer may have invalid data in
variables SMF6DSNM and SMF6PRMD. APAR PN72812 is still OPEN.
13. TYPE6 observations may indicate DUPLEX when you really think the
print file was SIMPLEX. The Banner Page Header and Trailer are
associated with the first and last datasets printed, and if either
the Header or Trailer itself are marked as DUPLEX, then the entire
print dataset is marked DUPLEX, even though it was only the Header
or Trailer page that was duplexed.
14. EXCP counts in type 30 segments for VSAM hardware-compressed data
sets initially contained a count of blocks transferred, but since
non-hardware-compressed VSAM counts I/O operations (SSCHs), IBM has
changed (APAR OW11649) VSAM counts for hardware compression to now
count SSCHs to be consistent with other VSAM counts. For Extended
Format datasets, the count was the number of blocks per I/O, but now
Extended Format will show the count of SSCHs, like other VSAMs.
15. A site with SMF data sets on mixed devices (3390, 3380, 9345) chose
an SMF VSAM data set CISIZE=16K for all three device types, but SMF
failed because the actual blocksize allocated was not the same for
all SMF data sets. It turns out that VSAM allocates the physical
block size of a dataset based on a table in SC26-4910-00, and not on
what you ask for. For a CISIZE request of 16K, the 3380 and 9345 got
an 8192 PHYREC-SIZE, while the 3390 got a 16384 PHYREC-SIZE, but SMF
requires that the control interval size must match the physical
record size (the text of IEE984 message).
IV. DB2 Technical Notes.
1. DB2ACCT CPUTCBTM capture for Distributed work (DRDA from DDCS).
Most of the DB2 CPU TCB time is captured in the DB2ACCT records, and
hence also in the address space (type 30) records for the caller, as
well as in the performance group/service class (type 72) of caller.
One day's data showed 346 minutes DB2TCBTM in DB2ACCT with only 7.5
minutes CPUTCBTM in the RMF 72, or 97.8% of TCB was captured in DB2.
See note 2 for a discussion of why DB2ACCT SRB time cannot be used.
For Distributed work (a DRDA Transaction from DDCS running
in an AIX workstation, for example), its CPU time will be found in
the DB2ACCT dataset with a plan name of DISTSERV, and also in the
type 30 records and type 72 records for the DISTSERV address space,
but there is no other address space involved. Thus to account for
the use of Distributed DB2, you must use the DB2ACCT record to
redistribute the CPU cost. But it looks like the only field that
might tie back to which workstation generated the DB2 activity is
the AUTHID, but that appears constant for all transactions!
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, or
it may be that this site has a misset parameter - I am still looking
into this data and will update this note when I learn more.
2. DB2ACCT CPUSRBTM/DB2SRBTM is invalid.
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 some times, 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).
V. IMS Technical Notes.
1. IMS APAR PN45106 documents that CPU time recorded in the IMS log 07
record (MXG variable IMSCPUTM, IBM field DLRTIME) increases when
LSO=S is specified instead of LSO=Y. With LSO=Y specified, MXG
variable IMSCPUTM contains only the CPU time in the dependent
region, and does not include CPU time spend in DL/I processing.
However, if LSO=S is specified, IMSCPUTM now includes the CPU time
in DL/I processing, and IBM reported a 30% decrease when LSO=Y
replaced LSO=S. The moral is: changing the LSO parameter can
dramatically change how much CPU time is recorded in IMSTRAN dataset
(and you cannot tell from the IMS log whether LSO=S or LSO=Y was in
effect).
VI. SAS Technical Notes.
1. SAS ABENDS which point to out of space in WORK.@Tnnnnnn.UTILITY
are the result of running out of sortwork space when the SAS
Internal SORT has been invoked. With the default SORTPGM=BEST
option, the SAS Internal SORT is used for small datasets, while
the host sort is used for large datasets, but due to an error in
SAS, if the dataset size is greater than about 2GB, the size becomes
a negative number to SAS, and SAS tries to sort your 2GB dataset in
your WORK file! SAS Usage note V6-SORT-8334 discusses their error,
but no fix is currently scheduled. You can circumvent the error by
specifying OPTIONS SORTPGM=HOST for large SORTs, forcing SAS to use
your host sort package instead of its internal sort.
The SAS usage note also says to specify DYNALOC instead of
NODYNALOC. NODYNALOC causes SAS to allocate the sort work space,
while DYNALOC causes the host sort package to do the allocation,
but with that negative number and the NODYNALOC default, SAS will
allocate a very small work space, causing yet another failure!
However, the DYNALOC/NODYNALOC option has no effect if there are
//SORTWKnn DDs in the step; the initial allocation is set by the
JCL, and the host sort packages all extend as needed (based on
the real size, not the negative number). Since MXG has always
recommended real SORTWKnn DDs (and they are in the MXGSAS JCL
procedure), you do not need to change the DYNALOC/NODYNALOC
option, as long as there are real //SORTWKnn DDs in the step.
2. MXG-created FORMATS which decode hexadecimal values now use syntax
OTHER=( $HEX2. ) in the PROC FORMAT so that values that are not in
the format table will be printed in hex; without the OTHER statement
the character variable is printed as a character, which for most hex
values will be an unprintable field. For numeric formats the
syntax is OTHER=( HEX2. ) to cause hex instead of decimal values
for fall-thru values. This is not new, just newly re-discovered!
But this now makes MXG 13.01 and later incompatible with SAS Version
5.18 and SAS Version 6.06 because that OTHER= syntax did not exist
in those archaic SAS versions! However, you can delete all of the
occurrences of that OTHER= syntax from member FORMATS, and then the
member will execute without error. See Change 13.127.
3. Character variables that are assigned $MGxxxxx formats must also
appear in a LENGTH statement to set their stored length; otherwise
the width of the $MGxxxxx format will be used by SAS to set the
stored length. Not only must there be a LENGTH statement, that
statement must preceed the FORMAT statement in the input stream.
Accidentally, almost all MXG members just happened to have that
sequence, but now I know the mandatory sequence of statements in
creating MXG data sets is
LABEL LENGTH FORMAT INFORMAT INPUT
4. SAS data libraries cannot be hardware compressed; only BSAM and QSAM
access methods are supported, and SAS uses EXCP access method. If
you put SAS data libraries in a Data Class specifying hardware
data compression, you will get a 213-B8 ABEND that says that EXCP
access method cannot be used with extended sequential format data
sets (and hardware compression data uses extended sequential).
See the MVS Technical notes for other compressed data impacts.
5. Out of Memory errors can occur if your site has restrictions on
virtual storage (usually in IEFUSI, IEASYS, or IEFUJV exit). One
clear indication of virtual storage constraints are memory values
in IEF374I message in your JCL log. For a larger-than-default MXG
BUILDPDB successful execution, the IEF374I messages showed:
IEF374I ... VIRT 4488K SYS 976K EXT 32768K SYS 9352K
and the sum of the VIRT+EXT values, 4488K+32768K=37256K shows
that 36MB of virtual addressability was available for this step.
On the other hand, the site with out of memory error had only:
IEF374I ... VIRT 1684K SYS 300K EXT 7048K SYS 9180K
and the sum of 1684+7048K=8732K shows the site's virtual storage
restriction prevented SAS from getting more than 8MB.
-z/OS 1.12 message IEF032I/33I replaced IEF374I/276I.
If you get an out of memory error, make sure you have REGION=64M for
an unmodified BUILDPDB, and larger if you have additional SMF record
processing added to your PDB:
SAS V6: Requires the MEMSIZE=64M parameter in your CONFIGV6 member,
AND your REGION=64M (or REGION=0M, if it permits 64M).
SAS V8: Requires that there NOT be a MEMSIZE= parameter in CONFIGV8
BUT instead your REGION=64M on your JOB card controls V8.
Note that you can not specify REGION= values between the size
of your Private Area (typically 6-9MB) and 16MB, but
REGION=32MB or larger can be specified without JCL errors.
You can always overspecify and look at the SAS Total Memory message
in the SAS log to see how much virtual storage was required, and by
which DATA/PROC step, although it is always the "Big DATA" step in
BUILDPDB that sets the maximum virtual storage required.
If IEF374I shows the sum of the VIRT+EXT is only 16MB, 32MB or less,
then either the above installation exits are limiting REGION size,
or you have installed SAS with its optional restriction member:
SAS V6: BAMISC(SASOPTRS) used by job SASCNTL(BAOPT2) creates
load module named SASOPT73
SAS V8: BAMISC(SASOPTRS) used by job SASCNTL(BAOPTS1) creates
load module named SASOP800
From TSO "READY", if you type in SASOPT73 (V6) or SASOP800 (V8) and
hit Enter Key, you will get "COMMAND NOT FOUND" if there are no SAS
restrictions in effect, (i.e., that load module was not found in the
linklist), but if the module SASOPxxx exists, the ABEND (because it
is not an executable program) proves you have optional restrictions.
If you find no SAS restrictions but System restrictions, you might
try REGION=0M; at least one site restricted REGION=56M, but I got
what I needed with REGION=0M, with MEMSIZE then controlling size.
This note was revised Apr 27, 2000, and revised again Oct 25, 2001,
to correct that SAS V8 requires you NOT have a MEMSIZE parameter.
-z/OS 1.12 message IEF032I/33I replaced IEF374I/276I.
6. Although documented by SAS Institute, I was unaware that the HEX16.
and HEX15. format items (for NUMERIC variables only) produce quite
unexpected (but explainable) output. A value of '1111111111111111'x
prints as '5011111111111111'x, and '00000025AFC60562'x prints as
'4A25AFC605620000'x. The HEX15. and HEX16. format items don't print
the hexadecimal representation of the binary number, but instead,
the hexadecimal representation of the internal floating point (real
binary) value. At first glance this might seem serious, but it
turns out to have little impact on MXG and is actually a quite
novel use of an otherwise-useless format item.
- MXG always creates CHARACTER variables with $HEX format to store
hexadecimal representations (because there is no possible loss of
bits, and a 1 byte character variable stores in 1 byte, not 2).
- Some NUMERIC variables with HEX format do exist in MXG, but none
contained 32 bits of data. Some were stored in length eight, but
they contain 24-bit addresses which needed only HEX12., and there
is no error using HEX14-or-less for 7-byte-or-less numerics.
- Since only the left 7 bytes of an 8 byte NUMERIC can be exactly
represented in MVS SAS (at least one byte is always used for the
floating point exponent), the best SAS could ever print was
'11111111111100'x! Hence recognizing that the HEX15 and HEX16
formats could never be legitimately used for real data, SAS
developers way back in SAS 82.4 decided and documented that those
format items would print the float value instead of binary value!
Why? Because it gave SAS Technical Support the ability to see
the actual internal floating point value when a customer had a
numeric precision issue (while rare in our data, this is often a
problem for neophyte statisticians calling SAS Support!).
That first byte is the exponent, the remaining 7 the mantissa!
Why did this come up? In debugging a problem, I used HEX16 without
this knowledge, and became quite convinced there was a SAS error.
Of course, I HAD failed to R.T.F.M. (Read The Fine Manual), and
now we both know better!
VII. CICS Technical Notes.
1. APAR PN71965 points out that in CICS 4.1, the variable TERMINAL
in the AOR record in an MRO environment will contain the MRO
Session ID instead of the surrogate TERMID as was seen in previous
releases. IBM says this is "working as designed" in 4.1, but IBM
acknowledges customers desire the surrogate TERMID, and there may
be a later enhancement to meet that need.
2. APAR PN70771 (still OPEN) indicates that CICSTRAN variable USER
is not cleared between transactions in the type 110 record, and
thus a short userid will contain remnant data of a previous long
userid.
VIII. Incompatibilities and Installation of MXG 13.05.
1. Incompatibilities introduced in MXG 13.05 (since MXG 12.12):
a- IMACs that were changed (if they exist in your USERID.SOURCLIB, you
must refit your tailoring, starting with the new IMAC member):
None.
b- Other incompatibility changes:
Member FORMATS cannot be executed as-is under SAS Version 5.18,
but can be tailored if you are still running that archaic version.
See Change 13.127
User-written invocations of VMXGSUM with OUTCODE= to recalculate
the DATETIME= variable may be wrong. See Change 13.152.
c- These products were incompatibly changed by their vendor, and they
require MXG 13.xx as indicated:
Memorex/Telex LMS 3.1 (Change 12.326)
OPC Release 3.0 (Change 13.092)
DFSORT Release 13 (Change 13.092)
Hipercache 4.1.x (Change 13.120)
2. Installation and re-installation procedures are described in detail;
in member INSTALL (which also lists common Error/Warning messages a
new user might encounter), and sample JCL is in member JCLINSTL:
Summary:
a. Install member MXGSAS as JCL Procedure MXGSAS in your PROCLIB.
b. Allocate a 90-cyl PDS: MXG.V1305.MXG.SOURCLIB, and use IEBUPDTE
to read the MXG tape to create the 2500+ member Source Library.
c. Allocate a 1-cyl PDS: MXG.V1305.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 V1305.USERID.SOURCLIB.
d. Allocate a 1-cyl SAS Data Library: MXG.V1305.MXG.FORMATS and
execute SAS to create the library of Formats required by MXG.
e. If this is the initial install of MXG, tailor these members into
your MXG.V1305.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. If re-installing MXG, copy your existing USERID.SOURCLIB library
members into the MXG.V1305.USERID.SOURCLIB. Then, compare the
members in your USERID.SOURCLIB with the list of members that
were incompatibly changed (above, in this section) in this MXG.
If any of the incompatibly changed members exist in your dataset
MXG.V1305.USERID.SOURCLIB, then you must reinstall your site's
tailoring for that IMAC, starting with the IMAC member from the
MXG 13.05 Source Library.
f. EDIT and submit member JCLTEST6 to verify that your tailoring
did not create any errors.
g. EDIT and submit JCLPDB6 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 13.05 in its own set of libraries. When
parallel testing is complete and are ready to implement MXG 13.05
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 rename the MXG.V1305.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:", "ERROR :", " NOT "
"UNINITIALIZED", "TRUNCATED", "NEVER BEEN", "NOT FOUND", "CONVERT",
"APPARENT", and "NOT CATLGD", as they usually 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.
IX. Online Documentation of MXG Software.
Since 1994, the contents of the two MXG Books, (the 1984 MXG Guide, and
the 1987 MXG Supplement) are contained in the MXG Source Library, as are
all MXG Technical Newsletters and all MXG Changes, so all MXG
documentation is actually online in the software itself; even the
Installation Instructions are online, in members INSTALL/JCLINSTL!
ACHAPxxx members are the text of the 42 chapters from the two MXG books,
to which the text from newsletters and changes has been added. Some of
these chapters are still rough; while some of the chapters have actually
been completely revised, many of these ACHAPxxx are little more than a
concatenation of the two original chapters, often without the figures
or tables. The revision is work still in progress!
Members ADOCxxxx are what were in Chapter FORTY, and should be the first
place you look for information about MXG variables and/or datasets. The
ADOCxxxx members alphabetically describe each dataset and all variables
that are created by product xxxx, the instructions on how to enable that
product, bibliography of the vendor documentation, sample PROC PRINT and
PROC MEANS of real data, references to MXG reports that use these data,
and the MXG member names that you use to process that product. While
this too is work in progress, the most heavily used data sources,
especially the common SMF records, have been revised and are up to date.
There is 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, because of MXG naming conventions:
IMACxxxx - Defines record IDs, and the _Lyyyzzz and _Kyyyzzz macros
that name the dataset(s) created from product xxxx.
ADOCxxxx - "Chapter FORTY" style dataset and variable documentation of
all datasets created from product xxxx, with sample output.
VMACxxxx - The "real" source code member, often extensively commented.
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 tailoring of each MXG dataset, not used by
most MXG sites, but powerful if needed. There can be more
than one dataset created from one product. The yyyzzz
suffix of the EXyyyzzz member name is the same as the
suffix of "_L" and "_K" macros defined in the IMACxxxx for
its product. See Using the MXG Exit Facilities in ACHAP33.
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 or CHANGESS
for the xxxx suffix.
Member CHANGES identifies this Version and Release of MXG Software, and
describes all changes made in this Release, plus new technical notes.
Member CHANGESS contains each of the CHANGES members from each version
of MXG, so this member contains ALL changes ever made to MXG Software.
Since each MXG change lists the names of the members that were added or
altered, names the new product/version supported by a change, or lists
error messages corrected by a change, this member is designed to be read
online (with SPF BROWSE); you can search for specific product acronyms
(CICS, MVS/ESA, etc.), or the MXG member name or anything else. Many of
the changes are actually mini-tutorials, especially for new products.
Member NEWSLTRS contains the text of all newsletters. You can search
NEWSLTRS for product name or acronym to find all of Dr. Merrill's
published and unpublished technical papers, technical notes announcing
enhancements in new operating systems or subsystems, new datasets and
products, important APARs and PTFs, and other technical information of
importance to MXG users. (Since the Change Log that is printed in each
newsletter is in member CHANGESS, it is not repeated in NEWSLTRS.) MXG
Technical Newsletters are typically published twice a year, with one
printed copy sent to each licensed site's technical addressee.
Member DOCVER lists alphabetically ALL datasets and variables that are
built by this MXG Software Version, abbreviated to a line per variable.
Members DOCVERnn are the "delta-documentation" between MXG versions, and
list only those datasets and variables that were added/deleted/changed
by version "nn", so you can identify when a variable/dataset was added.
Finally, remember that MXG is source code, and you can often find your
answer by BROWSING the source members, especially the VMACxxxx members.
The MXG Variable name is frequently the vendor's field name, or the
vendor's field name is often in a comment adjacent to the variable's
INPUT, so you can cross reference MXG to the vendor's documentation.
The migration from print to online is clearly work in progress, but at
least the two books are now machine readable! When all 42 chapters
are completely revised and updated in the source library, I will decide
which, if any, will also be made available in printed form, but the
primary media for all future MXG documentation will be these members of
the MXG source library, which can be immediately updated in each new
version of MXG as changes occur.
X. Changes 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 tapes are
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.
Alphabetical list of important changes after MXG 12.12:
Dataset/
Member Change Description
ANALALL 13.076 Print of All SMF records from a job was enhanced.
ANALAPAF 13.014 Semicolon missing in report program.
ANALCISH 13.046 Report enhancements for CICS Shutdown reports.
ANALCISH 13.113 CICS Shutdown may cause NOTSORTED error.
ANALCNCR 13.036 Validation closed several exposures.
ANALCNCR 13.047 ANALCNCR failed when invoked by ANALTAPE or ANALMTP.
ANALDB2C 12.318 NO MATCHING IF error because colon vice semicolon.
ANALDB2R 12.328 Syntax errors with PMACC01 or PMACC02 report.
ANALDB2R 13.042 DBID/OBID mapping enhanced to include timestamp.
ANALDB2R 13.058 BY VARIABLE STRTTIME IS NOT ON INPUT DATA error.
ANALDB2R 13.079 DB2 Statistics Summary PMSTA01, Audit report fixes.
ANALDB2R 13.106 Statistics Report correction, FORMAT NOT FOUND.
ANALDB2R 13.118 Final (?) corrections to Statistics and Audit Reports
ANALDB2R 13.159 More Statistics Report errors, but at field level.
ANALPATH 12.325 Cross-System DASD Reports cols ran together.
ANALPGNS 13.003 Failed if you changed RMFINTRV duration in IMACRMFI.
ANALRMFR 13.134 Data/time selection crossing midnight failed.
ANALTALO 12.327 VARIABLE NOT FOUND error.
ANALTALO 13.006 Variable SYSTEM NOT FOUND in MXG 12.12A.
ANALTAPE 13.037 All-systems report was missing.
ASMRMFV 13.027 0C4 ABEND if no enqueue table, additional records.
ASMTAPES 13.135 MAINTLEV 4 of MXG Tape Mount and Allocation Monitor
ASMTAPES 13.162 MAINTLEV 6 of MXG Tape Mount and Allocation Monitor
FORMATS 13.061 All MXG formats for hex values use OTHER= syntax.
FORMATS 13.127 MXG FORMATS member incompatible with SAS Version 5.
GRAFLPAR 13.060 MXG 13.01 only. NAME uninitialized error.
IMACFILE 13.109 Select CICS records by APPLID/SUBTYPE example.
IMACICSA 12.324 SAP Journal data times formatted correctly.
IMACICSA 13.077 CICS SAP variable STCTIMTR may be wrong.
JCLDAYDS 12.316 DCOLLECT output LRECL=644 instead of LRECL=264.
JCLPDB6 13.018 Member ASUMDB2S does not exist error.
MONTHBLD 13.015 SORT error building monthly TYPE72, wrong BY list.
TRNDDB2S 13.031 Variables QTPUBD and QTXAIRL incorrect spellings.
TRNDTALO 12.327 Syntax error due to missing comma.
TYPEACF2 13.112 ACF2 subtype "L" logic (ACF2JR dataset) redesigned.
TYPEACHE 13.005 CRR 1.6 with 3990-6 in Basic Move, values wrong.
TYPEAUTO 13.091 Support for LEGENT's AUTOMATE SMF record.
TYPEAUTO 13.102 Corrections to initial support for AUTOMATE.
TYPEAXC 13.149 Support for Kodak AXCIS Optical Disk SMF records.
TYPECACH 13.103 Support for 4-digit UCB in Cache RMF Reporter data.
TYPEDCOL 13.105 INPUT STATEMENT EXCEEDED with SMS 1.2 DCOLLECT.
TYPEEDGS 13.124 IBM RMM SMF record INVALID DATA FOR MDUCDATE.
TYPEHIPR 13.120 Support for Boole & Babbage HiperCache V1.4.3.
TYPEHMF 13.038 Support for HMF subtypes 4 and 5.
TYPEHPAI 13.010 Support for HP-PCS data from HPUX UNIX.
TYPEHPSU 13.010 Support for HP-PCS data from SUN UNIX.
TYPEHPUX 13.010 Support for HP-PCS data from AIX UNIX.
TYPEHSM 13.131 Corrections to HSM FSR segment in SMF record.
TYPEHURN 13.085 Support for Antares' HURON ObjectStar SMF record.
TYPEICE 13.026 ICEBERG subtype 5 extents and TOIOTIME wrong.
TYPEILKA 13.130 Internet addresses were not converted to num-point.
TYPEIMSA 13.013 IMS DEDB and MSDB counts from fastpath type 59.
TYPELMS 12.326 Support for Memorex/Telex LMS Version 3.1 (INCOMPAT).
TYPEMON8 12.315 NO MATCHING DO/SELECT error, 'TD' record support.
TYPENAF 13.094 NAFLOGOF dataset variables incorrect.
TYPENAF 13.133 Candle's Supersession Release 147 PTF QLV1372
TYPENDM 13.070 Variable NDMDSDSN (Source DSN) added to NDMCT.
TYPENDM 13.146 Connect Direct (formerly NDM) minor corrections.
TYPENSPY 13.021 NETSPY Type N subtype 06/07 support incorrect.
TYPENSPY 13.022 Support for NETSPY Release 4.6 (compatible).
TYPENSPY 13.059 INPUT STATEMENT EXCEEDED for NETSPY type X record.
TYPENTCP 13.144 Support for NetCompress SMF records.
TYPEOPC 13.092 Support for OPC Release 3.0 (INCOMPATIBLE).
TYPEPKMN 13.145 Support for Packet/Main SMF records.
TYPEQAPM 13.051 Support for OS/400 Version 3.1.0 wrong in MXG 12.12.
TYPEQAPM 13.071 OS/400 Version 3.1, DSARM/DSTYPE reversed.
TYPERACF 13.030 Support for IBM's IRRDBU00 RACF Database Unload.
TYPESAMS 13.080 Support for Sterling SAMS Storage Automation SMF.
TYPESOLV 13.028 Support for Sterling SOLVE NCL CPU-time accounting.
TYPETCP 13.008 Support for TCP/IP APAR PN69321-PN69322.
TYPETMNT 13.135 PROGRAM=IEFIIC records are again deleted by TYPETMNT.
TYPETMON 12.320 Landmark Version 1.3 variables were not INPUT.
TYPETMS5 13.083 Support for TMS (CA-1) Release 5.1 (compatible).
TYPETMS5 13.123 New variables from 5.1 added to final datasets.
TYPETSOM 13.143 TSO/MON 6.1 only, TRIVTM,NTRIVTM,LONGTM too small.
TYPEVMXA 13.126 Sterling's VM/Monitor MONWRITE records cause error.
TYPEVMXA 13.137 Support for MICS VM Data Transmission Program output.
TYPEWYLA 13.075 Support for ACS Wylbur Accounting SMF record.
TYPE102 13.009 T102S145 QWn145OB values wrong.
TYPE110 12.321 CICS Statistics CICDS and CICEODRV datasets wrong.
TYPE110 13.057 CICSLSRR variables A08BKCTD/A08BKDTD incorrect.
TYPE116 13.049 Zero observations in dataset TYPE116.
TYPE1415 13.002 DSNAME='UNKNOWN...' set incorrectly for multi-vol.
TYPE1415 13.064 Multi-UCB type 1415 SMS fields wrong.
TYPE16 13.093 Support for DFSORT Release 13 (INCOMPATIBLE).
TYPE24 13.066 Fields added by MVS/ESA 5.2
TYPE28 13.072 Support for NPM Version 2.2 APAR OW08641.
TYPE30 13.065 Negative value for EXECTM due to IBM leapseconds.
TYPE30 13.066 Fields added by MVS/ESA 5.2
TYPE30 13.073 ABEND value may be wrong in TYPE30_5.
TYPE32 13.084 Support for APARs OW10393 and OW12856.
TYPE42 13.066 Fields added by MVS/ESA 5.2
TYPE6 13.056 4-Digit remote support incomplete.
TYPE74 13.004 MVS/ESAS 5.1 TYPE74ST dataset had duplicate/missing.
TYPE74 13.035 Support for APAR OW04653 added to TYPE74ST dataset.
TYPE80A 12.323 Invalid SUBSTR function, STOPOVER error corrected.
TYPE92 13.155 Support for OpenMVS File System I/O SMF type 92.
VMXGHSM 13.108 Dataset DGN corrected for multiple dump copies.
VMXGINIT 13.033 New macro variable, <#&SINGLE-WORD SPELLING ERROR.#>
, is now GLOBALed.
XMXGSUM 13.097 Final validation enhancements.
YEAR2000 13.110 MXG Position Paper on support for the Year2000.
YEAR2000 13.158 Phase one support for the Year2000.
VMXGSUM 13.152 VMXGSUM incompatibity for user-written invocations.
Inverse chronological list of all Changes:
===Changes thru 13.165 thru 13.001 and 12.328 thru 12.315 were printed
in this newsletter.
===Changes thru 12.314 were included in MXG 12.12 dated Mar 1, 1995===
(changes thru 12.304 were printed in MXG Newsletter TWENTY-SEVEN)
ALL changes (both current and for all prior versions of MXG)
are contained in member CHANGESS.