COPYRIGHT (C) 1984-2021 MERRILL CONSULTANTS DALLAS TEXAS USA
MXG NEWSLETTER THIRTY-TWO
****************NEWSLETTER THIRTY-TWO***********************************
MXG NEWSLETTER NUMBER THIRTY-TWO September 12, 1997
Technical Newsletter for Users of MXG : Merrill's Expanded Guide to CPE
TABLE OF CONTENTS Page
I. MXG Software Version 15.04 is available upon request 3
II. MXG Technical Notes 5
1. Status of ASMTAPES (Tape Mount and Allocation Monitor) 24Jun97. 5
2. Using NUM Variables with HEXn. versus CHAR variables with $HEXn. 7
3. Please subscribe to the MXG-L ListServer broadcast service. 7
III. MVS Technical Notes. 8
1. A big jump in PGPEXCP (and also in IOSERVICE & SERVICE) in TYPE72 8
2. APAR OW24867 corrects SMF type 60 record SMF60FNC & SMF60NNM 8
3. APAR OW14759 corrects loss of all RMF records if SMF is switched 8
4. APAR OW24149 reports negative page counts in variable PAGEESIN 8
5. APAR OW24002 reports no SMF type 42 subtype 2 records are written 8
6. APAR OW16728 reports negative values for variable ACTIVETM 8
7. APAR OW23020 corrects SMF type 21 records that were not written 8
8. Steps that have NOT CATALOGED 2 or 8 conditions can set a bit 8
9. APAR OW24166 corrects Netview SMF Session Monitor records 8
10. APAR OW25371 for VSAM/RLS processing enables creation of type 64 8
11. CA-DISPATCH can create type 6 SMF records with invalid READTIME. 8
12. APAR OW25624 corrects SMF type 42 subtype 6 (TYPE42DS) records 8
13. APAR OW10233 references OZ51286 dealing with TYPE30 (STEPS/JOBS) 8
14. APAR OW16975 (in OS/390 R3) will not write 80 bytes of zeroes 9
15. APAR OW26144 reports excessive number of SMF type 118 records 9
16. PSF APAR OW23493, if you have Cut Sheet Emulation devices 9
17. Mobius' InfoPac SMF records have incorrect datetimes 9
18. APAR OW25624 for DF/SMS type 42 SMF records corrects SMF42PTS 9
19. APAR OW26949 corrects RACF UNLOAD utility so that the RACF Group 9
20. Documentation of Error in SMF Type 30 Interval Due to LeapSeconds 9
21. Information APAR II10549 acknowledges that TYPE70PR/ASUM70PR 10
22. Reports of TYPE74CF observations wherein CFBUSY time exceeded 10
23. Using Reporting Classes (and RPGNs) for workloads in IMACWORK. 10
23. APAR OW26609 corrects errors in new fields in type 72 records 11
24. APAR OW27840 (Opened 24Jun97) acknowledges sporadic instances 11
25. APAR OW20926 (old) may correct error in TYPE42 variable SMF42DWB 11
26. This is a preliminary response to the question: 11
27. APAR OW27252 reports no I/O queueing data in SMF record 78 12
28. APAR OW28256 reports OS/390 can have invalid CPURCTTM (SMF72RCT) 12
29. APAR OW25609 reports SMF interval processing can stop. 12
30. APAR OW27956 reports that DFSMS/MVS RMM can create RMM SMF 12
31. The variable MVSLEVEL in type 70 OS/390 1.3 has value VE010300 12
IV. DB2 Technical Notes. 12
1. With regard to EXCP counts in type 30 records, APAR OW16847 12
2. IBM Item RTA000099957 answers DB2 Buffer Pool Hit Ratio query. 12
V. IMS Technical Notes. 13
1. The IMS Technical Note in Newsletter THIRTY-TWO that reported 13
COPYRIGHT (C) 1997 MERRILL CONSULTANTS DALLAS TEXAS USA
TABLE OF CONTENTS, continued Page
VI. SAS Technical Notes. 13
1. SAS I/O errors may require SAS maintenance. Revised 20Apr97. 13
2. SAS data libraries CAN be hardware compressed, (up to 8:1!) 14
3. An ABEND 0C4 (preceded by a SAS message about an I/O error 14
4. If you are testing SAS for year 2000 compliance with third-party 14
VII. CICS Technical Notes. 15
1. APAR PN89643 discusses large increase in CPU time when migrating 15
2. Originally posted on SAS/CPE web by Jim Hein at ERIE, migration 15
3. CICS Transactions with the same value of UOWTIME were generated 15
4. APAR PQ03431/PQ06162 correct a never-ending-loop in DFHSTTR that 15
5. CICS Transaction Server Version 1, abbreviated CICS/TS V1R1, 15
6. Reducing the cost of CICS type 110 transaction record processing. 15
VIII. Windows NT Technical Notes. 16
IX. Incompatibilities and Installation of MXG 14.14. 16
X. Changes Log 16
Alphabetical list of important changes 17
Changes 15.206 thru 15.001 19-62
I. MXG Software Version Status.
1. MXG Software Version 15.04 is now available, upon request.
MXG 15.04 Software is now over one million lines (1,008,660)!
Major enhancements added in MXG 15.04 dated 01Sep1997:
MXG now protects ALL date fields for year 2000.
Support for OS/390 Version 2 Release 4 (COMPAT).
Support for "Goal Mode SMF" type 99 subtype 6.
Support for DCOLLECT in DFSMS 1.4 (COMPATIBLE)
Support for VTAM 4.4 changes to SMF type 50.
Support for CA-1/TMS Release 5.2 (COMPATIBLE).
Support for ObjectStar 3.0 (INCOMPATIBLE in MXG).
Support for Xerox's XPSM Version 2 SMF records.
Support for HMF SMF Subtype 11 (DS3 Statistics).
Support for five new NTSMF Objects.
Support for VM ADSM Account Records in VM/ESA.
Support for TMON/DB2 record type "DE".
Support for Boole MainView for CICS stat records.
Support for Catalog Cell 'E7'(Alias) and invalid '05'x segment.
Support for RACFEVNT=22 and 59 in TYPE80A.
Support for Shared Medical CICS Journal OASMON records.
Support for Peregrine's Service Center SMF record.
Table of Holidays for SHIFT example added in IMACSHFT.
Major enhancements added in MXG 15.03 dated 30Jun1997:
Support for NTSMF Version 2.0 (INCOMPATIBLE; 15.02 was not correct).
Support for Windows NT 4.0 Service Pack 2 (INCOMPATIBLE also).
Support for IXFP SMF subtypes 6 and 7 (SNAPSHOT, SPACE UTILIZATION)
Support for TYPE1415 APAR OW25263 (for 3590s).
Support for TYPE42 APAR OW26451/OW26543/OW26497 MAXRSPTM added.
Support for TYPE42 APAR OW20921 adds TYPE42VT VTOC/VVDS counts.
Support for OMVS RACF data with RACF utility IRRDBU00.
Support for new fields in TYPEEDGR DFSMSrmm extracts.
ASMTAPES at ML-14 populates fields, protects 0C4 ABENDs better.
RMFINTRV now allows Report RPGNs/Classes to be used in IMACWORK.
Format MGBYTRT (Bytes per Second) can truncate value on the left.
BUILDPDB enhanced to rename WORK.STEPS for IT Service Vision.
Leap second support for type 30, 110, and 100-102 "GMT" conversion
Trending for TYPE72GO into TREND.TRND72GO added.
ANALCNCR Example counts Avg & Max Logged-ON TSO users from PDB.JOBs.
Major enhancements added in MXG 15.02:
Support for DB2 Version 5.1 (MXG 14.14 tolerates, COMPATIBLE!!)
Support for Filetek's Optical Disk SMF record
Support for OMVS data in RACF database (IRRDBU00 unload)
Enhancements to VMXGSUM for OBS=0 processing
Replacement for MXG 15.01's defective CICINTRV.
ASMTAPES Technical Note updated - cause of 0C4 is now known.
Major enhancements added in MXG 15.01:
Errors in MXG 14.14 that are fixed in MXG 15.01:
ASMTAPES (ML13) is available, recovers from 0C4s, see MXG Tech Notes.
WORK.CICINTRV.DATA DOES NOT EXIST.
OS/390 R3 Goal only: Type 72 INPUT STATEMENT EXCEEDED RECORD LENGTH.
FILE counts in TYPETMON were incorrect before and after 14.14.
New Support in MXG 15.01:
ANALDDCN to analyze impact of DDCONS(NO) on duplicated SMF bytes
TYPEIMSD for IMS DBCTL transactions from IMS 07/08 log records
SMFPRM00 with first draft of MXG discussion for SMF parameters
Support and exploitation of new TALO fields added by ASMTAPES ML-12.
Support for APAR OW25152 (adds PRINTWAY Queue Name to TYPE6).
Support for Altai's ZARA Tape Management Release 1.2
Support for Anacom's Anastack spooler's type 6 SMF
Support for Boole and Babbage IMF 3.2.
Support for CA-DISPATCH Version 6 with 5-digit JESNR
Support for CA-ROSCOE Version 6 SMF record verified.
Support for COMPAQ hardware NTSMF objects.
Support for Hitachi 7700 changes to TYPE74CA/CACHET90 (INCOMPAT)
Support for Landmark's Performance Works/Smart Agents for UNIX 4.0
Support for MEMO subtype 8 creates new MEMODIST dataset.
Support for NETSPY Version 5.0 is already in MXG 14.14
Support for Virtual Tape Server additions to SMF type 94
Support for World Wide Web Common Log Format records.
Support for all OS/400 Release 3.7.0 records.
UDUMPEBC utility for MVS-like LIST; hex dump under ASCII systems.
All of these enhancements are described in the Change Log, below.
Availability dates for the IBM products and MXG version required:
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.05
MVS/ESA 5.2.2 Oct 19, 1995 13.09
OS/390 1.1.0 Feb 22, 1996 14.01
OS/390 1.2.0 Sep 30 1996 14.05
OS/390 1.3.0 Compatibility Mode Mar 28 1997 14.14
OS/390 1.3.0 WLM Goal Mode Mar 28 1997 15.02
OS/390 2.4.0 Sep 28 1997 15.04
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. 13.09
CICS/ESA 5.1 aka CICS/TS V1R1 Sep 10, 1996 14.07
CICS-Transaction Server V1R1 Sep 10, 1996 14.07
CRR 1.6 Jun 24, 1994. 12.02
CRR 1.7 Apr 25, 1996. 14.02
DB2 2.3.0 Oct 28, 1991. 10.01
DB2 3.1.0 Dec 17, 1993. 13.02A
DB2 4.1.0 Tolerate Nov 7, 1995 13.07
DB2 4.1.0 Full support Sep 11, 1996 14.07
DB2 5.1.0 Tolerate Jun 30, 1997 14.14
DB2 5.1.0 Full support Jun 30, 1997 15.02
DFSMS/MVS 1.1 Mar 13, 1993. 11.11
DFSMS/MVS 1.2 Jun 24, 1994. 12.02
DFSMS/MVS 1.3 Dec 29, 1995. 13.09
DFSMS/MVS 1.4 Sep 28, 1997. 15.04
MQM 1.2, 1.3, 1.4 Apr 25, 1996. 14.02
NETVIEW 3.1 type 37 ??? ??, 1996. 14.03
NPM 2.0 Dec 17, 1993. 12.03
NPM 2.2 Aug 29, 1994. 12.05
NPM 2.3, 2.4 ??? ??, 1996. 14.03
RMDS 2.1, 2.2 Dec 12, 1995. 12.12
TCP/IP 3.1 Jun 12, 1995. 12.12
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
IMS 4.1 Aug 6, 1994 12.02
IMS 5.1 Jun 9, 1996 14.05
AS400 3.7.0 Nov 1, 1996 15.01
Availability dates for non-IBM products and MXG version required:
Availability MXG Version
Product Name Date or Change Required
Microsoft
Windows NT 4.0 and NT 3.51 14.14
Windows NT 4.0 Service Pack 2 15.03
Demand Technology
NTSMF Version 1 Beta 14.11
NTSMF Version 2 15.03
Landmark
The Monitor for DB2 Version 2 13.06
The Monitor for DB2 Version 3 15.03
The Monitor for CICS/ESA 1.2 - 12.12
The Monitor for CICS/ESA 1.3 - 15.01
The Monitor for MVS/ESA 1.3 - 12.05
The Monitor for MVS/ESA 1.5 - 12.05
Candle
Omegamon for CICS V300 User SMF 12.05
Omegamon for CICS V400 User SMF 13.06
Omegamon for IMS V110 (ITRF) 12.12
Omegamon for IMS V300 (ITRF) 14.04
Omegamon for MVS V300 13.05
Omegamon for MVS V400 13.06
Omegamon for DB2 Version 2.1/2.2 13.05
Omegamon for VTAM V160 12.04A
Omegamon for SMS V100/V110 12.03
CA
ASTEX 2.1 14.04
NETSPY 4.7 14.03
NETSPY 5.0 14.03
Boole & Babbage
IMF 3.1 (for IMS 5.1) 12.12
Memorex/Telex
LMS 3.1 12.12A
II. MXG Technical Notes
1. Status of ASMTAPES (Tape Mount and Allocation Monitor) 24Jun97.
ASMTAPES ML-14 is now available upon request, and is in MXG 15.03.
- The ML-14 level improves interception of the 0C4s ABEND (see the
discussion, below, for ML-13, and the text of Change 15.14x).
- ML-14 populates several fields in the Mount Record, but as the
SMF record's format was not changed, prior MXG versions will not
fail with ML-14 SMF records. However, MXG 15.03 TYPETMNT code is
required to properly INPUT and format the new fields and for
support of 5-digit JESNR in TYPETMNT.
ASMTAPES ML-13 was available upon request, and was in MXG 15.01.
- The ML-13 level added an ESTAE to intercept 0C4s ABEND and to
recover without a restart, so the monitor kept writing records.
- ML-13 added new optional debugging diagnostics that allowed us
to find the real cause of the 0C4's and the TMNT008I/TMNT007I
messages:
It all boils down to an address space having to be swapped in
to guarantee access to all of its virtual storage while in AR
mode. Periodically in large and very busy data centers, a job
with a tape drive allocated ends up swapped out. If the swap
is physical, ALESERV fails with a return code of '4C'x (which
was discovered through experimentation and MXG handles, but you
still get TMNT008I messages with RC of '4C'x printed). The
problem arises when the address space is logically swapped.
ALESERV merrily returns an ALET, and the program continues
execution. All virtual storage access into the target address
space is O.K., as long as it is in real memory, but if the page
instead is in expanded or auxiliary storage, the page fault is
not resolved and the S0C4 is passed on to the program. IBM now
has an APAR (OW22245) to change the ABEND code in this
situation to a S0D5 with various reason codes!
Now that we understand the cause, we will enhance ASMTAPES in
the next iteration to stop issuing the TMNT007I and TMNT008I
messages and just continue on to the next UCB. If we take a
S0C4 ABEND in any of the AR mode code, we will have our error
recovery check the swap status of the address space and if it
is swapped out, recover from the ABEND completely - no error
messages, symptom dumps, or LOGREC entries. We will also see
if we can detect the logical swapped status early and avoid the
0C4 ABEND, but will keep the error recovery in any event.
ASMTAPES at ML-12 was shipped in MXG 14.14.
- has failed with 0E0 and 0C4 ABENDS which took down the MXGTMNT
address space
- but ML-12 can be restarted, though one site had to try 4 times
times in 15 minutes before the monitor stayed up (probably
because the task that precipitated the 0C4 ABEND was still
executing).
- there was a patch for an 0C4 in the Mount monitor, (the patch
bypassed the acquisition of JESNR and READTIME) but that 0C4
was due to an ASMTAPES coding error (in handling ASIDs with
multiple TCBs that do not have a TIOT for the first TCB) that
patch is now included in ML-13.
- generates TMNT007I and TMNT008I (ALESERV UNABLE TO ADD ....)
informational messages. We now know these notes are related to
logically swapped ASIDS (see above) and will eliminate these
now-unneeded MXG diagnostics in ML-15.
- Only 6 sites have experienced any failures, and they have all
been large systems and intense exploiters of tape technology.
- Nevertheless, the ML-12 (from MXG 14.14) can still be used, and
it is inherently safer than prior levels of ASMTAPES. But it is
so easy to install a new version of ASMTAPES and/or MXG Software
you should just request MXG 15.03 and install ML-14 if you have
not yet installed ML-12!
ASMTAPES Management Summary:
ML-14 is required if you have failures with ML-12 or ML-13, but
installing ML-14 plus MXG 15.03 is recommended for all, to take
advantage of both monitor protection and report enhancements,
even though there still will be an ML-15 in the third quarter.
2. Using NUM Variables with HEXn. versus CHAR variables with $HEXn.
Tim VanderHoek observed differences in printing TYPE74CA variables:
LCU SSID1 SSID2 SSID3 SSID4 (in TYPE74CA)
0044 001B 001C 4040 4040
with that distracting "4040" hex value ('40'x is the MVS blank)
printed for the non-existent SSIDs, and contrasted to TYPE78:
CHP1 CHP2 CPH3 CHP4 CHP5 CHP6 CHP7 CHP8 (in TYPE78)
37 57 77 A7 . . . .
which clearly shows that CHP5 thru CHP8 are missing.
The difference is because MXG chose to use Numeric Variables with
HEX format for the CHPn variables, and numeric variables have a
unique "missing" value when they were not INPUT or initialized
that SAS recognizes when HEX format is used, so SAS prints those
missing values as a period (by default, but the MISSING= option
lets you change those periods to blanks for cleaner reports),
while MXG chose to use Character Variables with $HEX format for the
SSID variables, and SAS has no unique "missing" value for Character
variables. Characters are initialized to blanks, so you cannot
tell whether a character variable is blank because it was not INPUT
or blank because a '40'x was actually INPUT!
Why chose Character or Numeric for hex variables? Using Character
for hex variables requires only one byte per byte, whereas numeric
variables require more storage, requiring a minimum of 3 bytes for
a one-byte field, and requiring 5 bytes for a four-byte field, so
most MXG hex variables are stored as Character with $HEXn format.
Most of the time, the fields are always input, so the issue of
blanks printing due to non-input is usually not an issue, and since
'4040'x can be a legitimate data value, MXG cannot change.
So what can you do when you are stuck with MXG's choice and have a
specific report in which you want to changes those hex blanks to
print as blanks? Use the new $MGHEX2H, $MGHEX4H, $MGHEX8H
formats (Change 15.252) or create the format in your report:
OPTIONS CHARCODE;
PROC FORMAT;
VALUE $MGHEX4H
'4040'X=' '
OTHER=?< $HEX4. ?>;
and then use FORMAT SSID $MGHEX4H. ; with your PROC PRINT to cause
the hex '4040'x to print as blanks. 2JUL97.
3. Please subscribe to the MXG-L ListServer broadcast service, simply
by sending an email to : LISTSERV@PEACH.EASE.LSOFT.COM
with no subject and text: SUBSCRIBE MXG-L firstname lastname
and you will receive technical discussions by MXG users as well as
notification of new versions of MXG and any major changes!
III. MVS Technical Notes.
1. A big jump in PGPEXCP (and also in IOSERVICE & SERVICE) in TYPE72
occurs between MVS/ESA 4.3 and MVS/ESA 5.2, because the DB2 Media
Manager EXCP counts are now captured. 28FEB97.
2. APAR OW24867 corrects SMF type 60 record SMF60FNC & SMF60NNM blank
values for RENAME event. 8MAR97.
3. APAR OW14759 corrects loss of all RMF records if SMF is switched
from NOACTIVE to ACTIVE after an SMF interval has expired. 12MAR97.
4. APAR OW24149 reports negative page counts in variable PAGEESIN in
datasets TYPE72GO and TYPE30_4/PDB.STEPS and in variable PGPAGEIN
in dataset TYPE72GO if the address space was logically swapped
during the interval. 12MAR97.
5. APAR OW24002 reports no SMF type 42 subtype 2 records are written
when parameter SMF_TIME in the IDGSMSxx member of SYS1.PARMLIB is
set to YES. Records are written if SMF_TIME=NO and CACHETIME(nnn)
is specified! 12MAR97.
6. APAR OW16728 reports negative values for variable ACTIVETM in
TYPE72GO dataset, and possible lost type 72 subtype 3 records if
WLM Policy is changed and then activated. 12MAR97.
7. APAR OW23020 corrects SMF type 21 records that were not written
due to HSM tape recycles done in "connected sets". Because HSM
did not dequeue at the completion of a recycle for each tape volume
there was no type 21 record written. This amounted to over 2,000
missed type 21 records at one site. (Plug: the ASMTAPES MXG Tape
Mount monitor did correctly record these mounts!). 12MAR97.
8. Steps that have NOT CATALOGED 2 or 8 conditions can set a bit in
type 30 TERMIND variable, and MXG will recognize that bit if on
and will set variable ABEND='NOTCTL', but it turns out that that
bit in type 30 is enabled ONLY if you have told MVS to fail the
job on this error condition (in SYS1.PARMLIB member ALOCxx you
must specify FAILJOB(YES)), so if you want to know which jobs had
the not cataloged condition, you must first cause them to ABEND!
This is not new, but was not clearly documented in MXG previously.
9. APAR OW24166 corrects Netview SMF Session Monitor records for
multidrop lines (incomplete secondary side configuration info for
second and subsequent active clusters).
10. APAR OW25371 for VSAM/RLS processing enables creation of type 64
and type 42 subtype 15,16,17,18 and 19 records.
11. CA-DISPATCH can create type 6 SMF records with invalid READTIME.
Their fix is L012084 ("INVALID SM6JLTIM...).
12. APAR OW25624 corrects SMF type 42 subtype 6 (TYPE42DS) records so
the STARTIME (SMF42PTS) is valid. IBM failed to clear the field for
the first datasets opened, and it contained the open time from an
earlier job! 25MAR97.
13. APAR OW10233 references OZ51286 dealing with TYPE30 (STEPS/JOBS)
variables SWAPS(SMF30NSW), SWPAGINS(SMF30PSI), SWPAGOUT(SMF30PSO),
counting pages and swaps for both physical and logical swap events,
but OZ51286 was a 1981 APAR that fixed SWPAGINS and SWPAGOUT, so
the new APAR only corrects SWAPS (so that only physicals are
counted). The APAR is in OS/390 Release 3. 29MAR97.
14. APAR OW16975 (in OS/390 R3) will not write 80 bytes of zeroes in
the should-be-nonexistent APPC segments in type 30 SMF records for
steps that were flushed, but this has no impact on MXG.
Note revised: 30Sep97. The APAR has an error, which (until fixed)
does impact MXG: the APAR creates records without the 80 bytes,
but the triplets say the data is there, causing MXG to detect the
bad records, print an MXG error message, a hex dump of the record,
and all variables for each bad record, and MXG deletes the record!
MXG Change 15.227 is required to circumvent the APAR error.
15. APAR OW26144 reports excessive number of SMF type 118 records can
be created for TCP/IP attached printers by PSF/MVS, because PSF's
zero default value for CONNINTV (try for ever) will, when PSF finds
a printer is not available (in use by some other app), then PSF
loops forever trying to obtain a TCP/IP connection, creating an SMF
118 record each time! While IBM decides if they will change their
default to perhaps 15 minutes, the APAR recommends that YOU code a
non-zero value for CONNINTV (in the PSF PRINTDEV macro) for each
TCP/IP attached printer under PSFs control.
16. PSF APAR OW23493, if you have Cut Sheet Emulation devices (they
have a switch on the printer that permits 2 pages side by side with
no change in your print application!), errors (bogus values) in
fields SMF6IMPS (SHEETPRN), SMF6FEET (DOCLENFT) and SMF6BNCN
(BINUSED ) in MXG's PDB.PRINT and TYPE6 datasets are now correct.
15Apr97.
17. Mobius' InfoPac SMF records have incorrect datetimes for variables
REQSTART and REQEND after installing InfoPac maintenance (VOLSER
5767, Nov 96). Instead of a value '0163514C'x for 16:35:14, their
error (shift and truncate left!) put '6351490C'x into SMF, which
SAS read as 635:51:49 hours, and added that to the 08APR97 date to
create a datetimestamp of 11MAY97:11:14:53! The error will be
fixed soon in their "Project Name" ER740210. 21APR97.
18. APAR OW25624 for DF/SMS type 42 SMF records corrects SMF42PTS, and
explains some of the logic of how the Data Set Statistics Blocks
(DSSB) are created, and describes the internal logic used to build
the type 42 subtype 6 record.
19. APAR OW26949 corrects RACF UNLOAD utility so that the RACF Group
ID is populated for both Violations and Successful accesses; it
was previously filled in only for Violations. 14Jun1997.
20. Documentation of Error in SMF Type 30 Interval Due to Leap Seconds.
SMF type 30 subtype 2 (Interval) begin and end timestamps use the
"Absolute" clock (in GMT and includes leap seconds), but that makes
the actual local time of the interval start to be 20 seconds sooner
than requested. Fifteen-minute intervals start at 13:14:40 local
instead of the desired start time of 13:15:00.
SMF Raw Converted
Field Hex Value Date-time-stamp value to local
SMF30ISS AEC433D280740000'x 05JUN1997:18:15:00.104 13:14:40.10
SMF30IST 0048C10A0097156F'x 05JUN1997:13:14:40.10 13:14:40.10
SMF30IET AEC4372CB5A00000'x 05JUN1997:18:30:00.000 13:29:40.00
SMF30TME 004A215C0097156F'x 05JUN1997:13:29:42.04 13:29:42.04
Three clocks can be used to populate SMF record timestamps:
Absolute - In GMT and includes leap seconds
GMT - In GMT equivalent of local (no leap seconds)
Local - In Local time zone, no leap seconds.
Fields SMF30IST (interval start in local) and SMF30TME (record sent
to SMF buffer in local) show the real interval begin and end, but
because SMF Synchronization uses ISS/IET instead of IST values, the
intervals are not synchronized with time of day.
The error occurs in ANY sysplex, since leap seconds are non-zero in
the CVTLOS in any system with the sysplex timer.
I have recommended that IBM change their incorrect design and use
the true local time of day instead of the absolute time to drive
synchronization.
I now understand better that I must use the entire difference from
ISS to IST as the "GMT Offset" to convert IET to correct local
time of day. See MXG Change 15.133 for more on leap seconds.
21. Information APAR II10549 acknowledges that TYPE70PR/ASUM70PR and
RMF Reports can show Total Effective Dispatch time greater than
Total Dispatch time (LCPUEDTM GT LCPUPDTM in TYPE70PR, LPnUEDTM GT
LPnUPDTM in ASUM70PR), causing negative values for LPAR Management
Time (LPnMGTTM in ASUM70PR). IBM has seen this problem most often
when the LPAR partition is connected to a coupling facility. This
APAR indicates this problem needs to be reported to your IBM CE so
he/she can open a hardware PMH, "as this is most often the result
of a non-responding or a slow-responding coupling facility". 18JUN.
Update: 2005: EDT can be greater than PDT because of:
a. coupling facility hardware when there really is a hardware
problem, although these are quite rare, or
b. when an LPAR, instead of hardware ICF, is used, for your
coupling facility, and/or
c. when you have defined a pathalogical ICF Sharing configuration;
for example, having six coupling facility LPARs share a single
ICF.
d. Small, fractional differences between CPUEFFTM and CPUACTTM
(here, CPUACTTM is the same as CPUUPDTM) can be ignored; you
can also calculate the delta and track it for the last few
weeks to see if it was significant.
IBM has provided updated discussions of the negative performance
impacts of coupling facilities sharing ICFs, in Washington System
Center Flash W99037.
Note: 2012. This is now in the RMF Performance Management Guide:
Each partition's CPU consumption for LPAR management is
calculated as the difference between total and effective dispatch
time. It is possible that the total dispatch time is smaller
than the effective dispatch time. This situation occurs when
partitions get "overruns" in their dispatch intervals caused by
machine delays. The most typical form of this is caused by an
MVS partition trying to talk to a coupling facility but getting
significant delays or time-outs. It is sometimes symptomatic of
recovery problems on the machine. In this case, field LPAR MGMT
is filled with '****'.
22. Reports of TYPE74CF observations wherein CFBUSY time exceeded the
RMF Interval Duration (CFBUSYxx GT DURATM) were corrected with a
microcode fix to the (ailing) Coupling Facility. 18JUN97.
23. Using Reporting Classes (and RPGNs) for workloads in IMACWORK.
You can now use Report Performance Groups or Reporting Classes to
define the MXG Workloads that are created into the PDB.RMFINTRV
dataset. Previously, you could only use the Control Performance
Group or Service Class values for variables PERFGRP or SRVCLASS in
your definitions of workloads in member IMACWORK. Revisions to
RMFINTRV and IMACWORK in MXG 15.03 allow you to use any combination
of Control Performance Groups and Report Performance Groups
(Compatibility Mode), or Service Classes and Reporting Classes
(Goal Mode) to define your work in member IMACWORK.
RMFINTRV now calculates the true CPU time captured from all of the
"safe" Control PERFGRP or Service Class observations into variable
CPUTM (from which Capture Ratio is calculated), and then calculates
the sum of CPU times from your IMACWORK definitions (stored in new
variable CPU72TM). If the sum of your definitions is less that the
true CPU time (work has been skipped in your definitions), or if
the sum is greater than the true CPU time (you have overlapped
definitions), MXG will emit error messages on your SAS log!
Using Reporting Class to define workloads is primarily needed
by sites using WLM Goal Mode. The old Compatibility Mode concern:
you can't use Report Performance Groups because not only are
RPGNs double accounted with their Control PGN, but a task can
be triple, etc., accounted because a task can be in more than
one Report Performance Group, and
MXG's design used your definitions to get true CPU time
has been changed, for with WLM Goal Mode:
MXG's redesign now lets you use Reporting Classes to define
workloads, but you must ensure that if you use them, that there
is no overlap with the Service Class in which their resources
are also counted. There cannot be triple or above accounting,
as WLM will allow a task to be in at most one Reporting Class.
and even for Compatibility Mode:
MXG's redesign now lets you use Report Performance Group values
to define workloads, but you must ensure that if you use them,
that there is no overlap with the Control Performance Group in
which their resources are always accounted, and you must be
aware of the exposure to triple or above accounting, if you
allow a task to be in more than one Report Performance Group.
In WLM Goal Mode, by design, you will have a small number of
Service Classes (perhaps all of your Production CICS Regions are in
one Service Class), but you should put each individual CICS Region
(or better still, put each and every long running task) in its own
unique Reporting Class. You can have as many Reporting Classes as
you need, as there is essentially no cost to a Reporting Classes;
at most the SMF type 72 records will take a few more tracks of DASD
each interval, even with hundreds of Classes. In fact, some sites
have mapped each old Control Performance Group into a new Reporting
Class. See comments in member IMACWORK and Change 15.138.
23. APAR OW26609 corrects errors in new fields in type 72 records that
were originally reported in Change 15.038. R723CIRC,R723CIDT,
R723CIWT and R273CICT record Non-Paging DASD I/O Connect, Wait, and
Disconnect durations, and SSCH counts; without the APAR SRM could
double count, most likely for TSO work, but any workload with lots
of swap activity had bad counts. 26Jun97.
24. APAR OW27840 (Opened 24Jun97) acknowledges sporadic instances of
impossibly high values for ENQ contention times SMF77WTM, SMF77WTX,
and SMF77WTT (MXG TYPE77 variables MAXTM, MINTM, and TOTLTM).
25. APAR OW20926 (old) may correct errors in TYPE42 variable SMF42DWB
(Direct Write Blocks) for IMS databases. SMF42DWB seems valid in
most cases, but some IMS database activity create unreasonably high
values. Site will either install PTF or migrate to OS/390 and I
will update this note when I know more. 7Jul97.
See APAR OW30059 (target PTF date 26Sep97). 31Oct97.
26. This is a preliminary response to the question:
How do you account for a 20% increase in CPU usage (20% more than
last month? Can you attribute it to individual jobs?
The RMFINTRV data provides interval CPU usage and CPU usage by work
load (based on your Performance Group/Service Class mappings in
IMACWORK), so you can see changes not only in total CPU usage, but
also changes in the amount of Uncaptured CPU, and the CPU time used
by each workload. You should begin analysis with RMFINTRV:
- While PCT CPU busy can be useful in tracking changes, using the
Total CPU Hours will often put things in better perspective, and
eliminates the issue of what denominator did you use to calculate
Percentage.
- Compare the number of observations in RMFINTRV to see how many
day's data is being compared. How many working days were there
in the two months being compared. March has 25% more working
days than February.
- Compare Shift totals. If the 20% increase was only in Prime
shift, perhaps response time improved, more work was done in
Prime time, so less work was held over to Non-Prime.
- Compare individual Workloads in RMFINTRV to see if all workloads
were increased, or only some workloads. If the increase is in
online workloads (CICS, TSO, etc.), look at the transaction count
for those applications to see if they had more work to do, or it
they did more CPU time per transaction.
- Once you have isolated an increase to a particular workload in
RMFINTRV, you can use the TYPE72 or TYPE72GO observations to see
which Performance Group or Service Class caused the increase.
- Once you identify the PERFGRP or SRVCLASS causing the increase,
you use PDB.STEPS to select the jobs by PERFGRP or SRVCLASS to
see what jobs were executing in that workload. You could use
PDB.JOBS, but you get the last step's PERFGRP/SRVCLASS, and you
will get safer analysis from PDB.STEPS. Moreover, you can then
compare usage by PROGRAM to find the cause of the increase.
- You should also compare a specific job's PDB.STEPS data across
the two months. The daily BUILDPDB or daily SMF dump program
are reasonably consistent day-to-day (perhaps excluding weekend)
consumers that can be tracked to see if those jobs also saw an
increase that might suggest an overall increase in recorded CPU
time (which can happen across hardware/software/microcode change
in your data center).
27. APAR OW27252 reports no I/O queueing data in SMF record 78 subtype
three (dataset TYPE78XX), with SMF fields SMF78DCN/SMF78ASN (MXG
variables NRCDSLCU/NRASS) zero after CPMF termination/restart.
APAR OW26350 may also apply.
28. APAR OW28256 reports OS/390 can have invalid CPURCTTM (SMF72RCT),
the Region Control Task CPU time; very large values have been seen
which cause negative values for CPUOVHTM in RMFINTRV. This error
previously existed in 1992 and was fixed by APAR OY51878's PTF, but
seems to have reappeared (although the cause is different now).
The error can be circumvented by subtracting CPURCTTM from CPUTM
in member EXTY72GO and EXTY72 until IBM again provides a fix to
the APAR OW28256 (which is still open) See Changes 10.064/9.184.
29. APAR OW25609 reports SMF interval processing can stop, causing no
type 30 subtype 2 or 3 records and no type 23 nor type 89 records.
The error affects MVS 4.3 thru 5.2 and OS/390 R1 thru R3.
30. APAR OW27956 reports that DFSMS/MVS RMM can create RMM SMF records
with ID=0 (i.e., they look like IPLs) with certain combinations of
parameters specified in SECCLS command in EDGRMMxx PARMLIB member.
31. The variable MVSLEVEL in type 70 OS/390 1.3 has the value VE010300
and for OS/390 2.4 it is VE020400. The value is never used in MXG,
but may be confusing when printed. IBM changed the value (it used
to be SP5.2.2) because some third-party programs failed if it did
not increase with each release, so IBM could not use OS2.4.0!
IV. DB2 Technical Notes.
1. With regard to EXCP counts in type 30 records, APAR OW16847 notes
The VSAM Media Manager does all I/O for linear datasets. Most DB2
Tablespaces reside on Media Manager controlled Linear Data Sets.
The DBM1 Address Space calls the VSAM Media Manager to perform
these asynchronous database I/O operations. 13Apr97.
2. IBM Item RTA000099957 answers DB2 Buffer Pool Hit Ratio questions
originated with an (unknown) MXG user. IBM confirmed that his
calculation:
BPHITRAT=(QBSTGET-(QBSTSIO+QBSTDPP+QBSTLPP+QBSTSPP))/QBSTGET;
was correct, and confirmed that negative values can occur, pointing
to DB2 V3 Admin Guide (SC26-4888) Vol III page 7-81, which states:
"When the hit ratio is negative, it means that prefetch has
brought pages into the buffer pool that are not subsequently
referenced, either because the query stops before it reaches the
end of the table space, or because the prefetched pages are
stolen by DB2 for reuse before the query has the chance to
access them."
IBM also confirmed the requestor's belief that the only reason for
this to happen is when a program start 'triggers' sequential
prefetches and just fetches one or a few rows and then does a close
cursor, and that this is the only time when the number of Get Page
Requests can be less than the number of pages read from DASD!
See Change 15.146, which added BPHITRAT/BnHITRAT variables and
corrected ANALDB2R's calculation VPOOL hit ratios to use SIO vice
RIO. 26Jun97.
V. IMS Technical Notes.
1. The IMS Technical Note in Newsletter THIRTY-TWO that reported a 10%
CPU increase with Boole & Babbage's IMF that was circumventable if
some monitoring was disabled, has now been corrected with two fixes
BPI7166 and BPI7167. With the fixes installed, the CPU times now
look okay.
VI. SAS Technical Notes.
1. SAS I/O errors may require SAS maintenance. Revised 20Apr97.
For SAS 6.08, Level TS430 or later is required (or TS425+Z608A625).
(Four-digit UCB address support)
For SAS 6.09, Level TS450 requires zaps Z609D182 and Z609D339.
(Four-digit UCB support, dynamically added UCBs)
SAS 6.09, Level TS455 contains zaps Z609D182 and Z609D339.
Mini-tutorial about UCB's above the line:
By default, MVS/ESA 5.2 and OS/390 move UCBs above the 16MB line,
but your site can change that default, and some sites have had to
not-move their UCBs because of problems with software products.
If your UCBs have been moved up, using VOLSERs with 3-digit UCB
address for the SAS data library may circumvent the error, but
installing the fix is a better solution. 18Apr97
Open Problem?
Back in May, four SAS 6.09 TS450 sites reported 0318 ABENDs, but in
each case the ABEND went away with a rerun! None of the sites had
the two zaps listed above installed, and as no further 0318 ABENDs
have been reported as of 26Jun97, it is likely that the ZAPs listed
above were the solution!
However, my original notes may be useful in the event of future
SAS 0318 ABENDs:
The symptoms (fails in DATA step or PROC SORT while writing to a
SAS data library, but a rerun does not fail), and these earlier
know causes of 0318 ABENDS:
4-digit UCB addresses with back level SAS System
High Track Address of SAS data library or input on 3390-9
STOPX37 (only if STOPX37 installer did not read the manual)
HSM Migration and Recall of SAS MultiVol (see Newsletter 26)
made me suspect the error is related to the physical allocation of
the data library (did it get allocated on a 4-digit or 3-digit UCB
device, did the library go into extents, and did an extent go to a
high-numbered track, etc.). Possible circumventions include
directing the library to a specific VOLSER with 3-digit UCB, or
increasing the Primary Allocation so that no extents are needed, or
re-using an existing permanent data set for //WORK or //PDB (i.e.,
do not allocate new for each run of BUILDPDB).
The SAS error message: "LIBRARY PDB APPEARS TO HAVE BEEN TRUNCATED.
THE INTERNAL LIBRARY REFLECTS A HIGH FORMATTED RELATIVE BLOCK
NUMBER THAT IS GREATER THAN THE NUMBER OF BLOCKS IN THE LIBRARY"
also went away with a rerun with only the primary allocation
changed, from 150 to 200 cylinders; the device was a 3390-9 (fat
DASD) volume.
Now, there are several SAS USAGE notes dealing with these errors:
V6-SYS.SASIO-7929 Discusses possible problems if you backup SAS
multi-volume DASD libraries using utilities.
The only safe way appears to be to use the
PROC COPY to back up multi-volume libraries.
V6-SYS.SASIO.A345 Discusses possible recovery for "truncated" SAS
libraries.
V6-SYS.SASIO-C141 Documents "appears to have been truncated"
V6-SYS.SASIO-C142 Lists several reasons why SAS libraries can be
"truncated", and what you can do to correct.
2. SAS data libraries CAN be hardware compressed, (up to 8:1!) in
spite of my note in Newsletter THIRTY-ONE, if you make the data
library an "Extended Sequential" or "Extended Format" OS dataset,
and then tell SAS to create the data library in "Tape" format (by
specifying LIBNAME CICSTRAN TAPE;, or by starting the name of the
LIBNAME with TAPE....)!
However, this is most useful when there is only one SAS dataset to
be written to the data library, because tape-format libraries do
not have a directory, and thus to access a second SAS dataset in a
tape-format library, you must read thru (and hence decompress) the
entire first SAS dataset to find the start of the second one, just
like any SAS data set actually on tape.
Since you must use the new Extended Format data set type to use
hardware compression, there is an additional virtue; these datasets
will extend to multiple volumes when you fill the first disk, so
here is yet another way to create a SAS multi-volume disk data
library, and this one can be hardware compressed!
3. An ABEND 0C4 (preceded by a SAS message about an I/O error on
dataset ASUMDB2A) occurred when a PROC COPY of a weekly PDB library
had a SELECT statement with dataset ASUMDB2A listed twice.
Removing the second instance of ASUMDB2A in the SELECT statement
eliminated the error! While the user did not intend to copy the
dataset twice, SAS certainly should be able to handle that without
ABEND, right? Yes, right. The actual error was not in the repeat
of the name, but because the output DD statement (accidentally)
specified UNIT=(SYSDA,4), that second copy of the very-large
ASUMDB2A dataset filled the first volume, and SAS ABENDED when it
spilled over into the second volume, because you cannot use the
UNIT=(SYSDA,n) for SAS multi-volume output libraries!
Note inserted Feb 3, 2000: You CAN use UNIT=(SYSDA,n) with
SAS Version 8 and later!!!
(See MXG Newsletter 32 "SAS Technical Note 2" and
MXG Newsletter 26 "SAS Technical Note 3" and
MXG Newsletter 23 "SAS Technical Note 4"
*** OR NOW JUST SEE MEMBER MULTIVOL ***
for how to create SAS multi-volume libraries. Jun 3, 1997.
4. If you are testing SAS for year 2000 compliance with a third-party
tool that uses SVC 11 timer interception technology, you must be
running Release 6.09E, and you must request special maintenance
by having your SAS rep contact a mainframe specialist in SAS's
Technical Support group for specific details.
VII. CICS Technical Notes.
1. APAR PN89643 discusses large increase in CPU time when migrating
to CICS 4.1 due to logging errors even though LOGMESSAGE(NO) was
specified on the EXEC CICS QUERY SECURITY command. 12MAR97.
2. Originally posted on SAS/CPE web by Jim Hein at ERIE, migration from
CICS 3.3 to CICS 4.1 can result in a dramatic drop in the number of
transactions (observation count in CICSTRAN) if your CICS guru did
not read the CICS/ESA Migration Guide to note that the old CICS
parameter CONV=YES must be replaced by MNCONV=YES in CICS 4.1 to
record each conversational transaction. CICS 4.1 will disregard the
old CONV=YES option and writes one record per attach rather than the
desired one per conversation. This was observed with SAS/SESSION
(CICS transaction SASC, which is in conversation with MVS/APPC)
count dropped from 100,000 to only 2,000 CICSTRAN observations until
the MNCONV=YES was specified in CICS DFHMCT macro.
3. CICS Transactions with the same value of UOWTIME were generated by
an RPG application running in an AS/400 as a batch job. A series of
messages each created a CICS transactions, but all transactions from
the job had the same UOWTIME, so it was impossible to match the CICS
and DB2 activity. By redefining the application with multi-session
and using Free & Release (or modifying the application to use Evoke
and Commit, which apparently does a pseudo Release/Detach of each
Conversation), unique UOWTIME values for each transaction appeared.
4. APAR PQ03431/PQ06162 correct a never-ending-loop in DFHSTTR that
filled SMF with CICS Statistics (VTAM) records for IRCBATCH.
5. CICS Transaction Server Version 1, abbreviated CICS/TS V1R1, is the
official IBM name of new versions of CICS/ESA. It would have been
called CICS/ESA 5.1.0 (and SMFPSRVR=51 is in SMF data) but IBM has
renamed the CICS Product. The SMF records were INCOMPATIBLY changed
between 4.1 and CICS/TS V1R1, but MXG 14.07 or later transparently
provides support for those incompatible changes. See Change 14.209.
6. Reducing the cost of CICS type 110 transaction record processing.
These are preliminary notes, to partially answer an MXG-L query.
This section will be updated with additional suggestions.
-If you create CICSTRAN and keep only the 9 variables that are needed
by the ASUMCICS program (to create PDB.CICS dataset), or only the xx
variables needed by ASUMUOW (to create PDB.ASUMUOW), run times and
resources needed can be reduced.
-Using %INCLUDE SOURCLIB(TYPE110,ASUMCICS) to read 1613MB of SMF
data, creating 2 million CICSTRAN observations and summarizing
into 225,000 PDB.CICS observations took 14.5 CPU minutes, 1.75
hours elapsed RESIDTM and 16.5 minutes of IOTM when all 109
CICSTRAN variables were kept, but only 9.5 CPU minutes, 31
minutes of RESIDTM, and only 6 minutes of IOTM when only the 9
variables required by ASUMCICS were kept.
-Using %INCLUDE SOURCLIB(TYPE110,ASUMUOW) to read 7400MB of SMF
data, creating 13 million CICSTRAN observations and summarizing
into 4 million PDB.ASUMUOW observations took 46 CPU minutes, 4.5
hours elapsed RESIDTM and 1.5 hours of IOTM when only the xx
variables needed by ASUMUOW were created. Attempts to run with
all 109 CICSTRAN variables failed to complete due to insufficient
SORT work space and/or excessive elapsed time!
Since the summary datasets PDB.CICS or PDB.ASUMUOW contain the
summarized transaction resources AND responses, you may not really
need all of the detail in CICSTRAN every day, and might consider
using a tailored IMACCICS in your daily job to keep reduced CICSTRAN
daily, and setup a separate IMACCICS for a separate TYPE110 job that
will create all CICSTRAN variables when needed for ad hoc analysis.
Examples of _KCICTRN macro definitions for keeping the 9 ASUMCICS or
the xx ASUMUOW variables have been added (but are commented out) in
member IMACCICS by Change 15.178.
-If you were to use CICS EXCLUDE in CICS's DFMCT macro to only write
out those 9 fields in the type 110 subtype 1 record (and then tailor
MXG member IMACEXCL to process those nine fields), you could expect
further reduction in processing time and in the size of your SMF
data file. Unfortunately, once you have excluded fields, you can't
go back and get them when you need them, but for well behaved
applications in large volume shops, it might be feasible. Has
anyone measured the difference, or is anyone interested in helping
me to measure this?
-If you never use the CICS Statistics (subtype 2 record), you can
skip over them in MXG processing by adding in member IMACFILE:
IF ID=110 AND SUBTYPE=2 THEN DELETE;
VIII. Windows NT Technical Notes.
1. There are no new technical notes, but see CHANGES for many new
objects that are now supported.
IX. Incompatibilities and Installation of MXG 15.04.
1. Incompatibilities introduced in MXG 15.04 (since MXG 14.14):
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:
none
c- These products were incompatibly changed by their vendor, and they
require MXG 15.xx as indicated:
NTSMF Version 2.0 MXG 15.03 Change 15.147
Hitachi 7700 Cache R.R. records MXG 15.01 Change 15.008
DB2 Version 5.1.0 two SMF 102 IFCIDs MXG 15.02 Change 15.095
ObjectStar 3.0 MXG 15.04 Change 15.195
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.
XI. 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 than 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 between MXG 14.14 and MXG 15.04:
Dataset/
Member Change Description
Many 15.167 MXG now protects ALL date fields for year 2000.
Many 15.169 SAS inconsistencies between MVS and ASCII fixed.
Many 15.170 Support for OS/390 Version 2 Release 4 (COMPAT).
ADOCTAND 15.119 Cannot use Tandem's ftp program to upload Measure.
ANALCNCR 15.126 New example counts Avg and Max Logged on TSO Users.
ANALCNCR 15.174 ANALCNCR with large INTERVAL had large WORK space.
ANALDB2R 15.191 ANALDB2R fails, ERROR 31-185 if no PLAN in SORTBY.
ANALDBXX 15.173 Merge DB2 102s with DB2ACCT and CICSTRAN example.
ANALDDCN 15.062 Analysis of impact of DDCONS(NO)'s duplicate bytes.
ASMTAPES 15.047 ML-13 of ASMTAPES protects 0C4s, stays up, etc.
ASMTAPES 15.141 ASMTAPES ML-14 populates fields, protects 0C4s.
ASUMTALO 15.077 Exploitation of TALO Interval Records added by ML-12
ASUMUOW 15.079 IRESPTM, ENDTIME corrected.
BUILDPD3 15.020 JES3 BUILDPD3 had extra observations created.
CICINTRV 15.006 WORK.CICINTRV.DATA DOES NOT EXIST if IMACCICS changed
CICINTRV 15.092 Replacement of MXG 15.01's CICINTRV.
CLMXGSAS 15.084 Sample CLISTs for MXG and SAS execution under TSO.
CONFIG 15.194 MXG default for MEMSIZE raised from 48M to 64M
DIFFDB2 15.070 DB2STATS values are negative in startup interval.
EXPDB30V 15.142 PDB exit EXPDB30V added for PDB.SMFINTRV.
FORMATS 15.057 New RACF events decoded by MG080EV.
FORMATS 15.109 Format MGBYTRT (Byte per second) truncated on left.
FORMATS 15.152 Formats $MGHEX2H, $MGHEX4H, $MGHEX8H blanks '40'x.
FORMATS 15.175 CICS formats $MGCICDL,$MGCICDS corrected.
IMACICBB 15.179 Support for Boole MainView for CICS stat records.
IMACICSM 15.157 Support for Shared Medical CICS Journal OASMON.
IMACKEEP 15.123 Member IMACKEEP is documented as archaic.
IMACPDB 15.002 Variable TERMIND added to PDB.STEPS.
IMACPDB 15.048 Variables SMF6FDNM/SMF6PDNM (Formdef/PrintDef) kept.
IMACPDB 15.091 Variables ACTBYTES/ACTPAGES from TYPE26J2 in PDB.
IMACSHFT 15.151 Table of Holidays for SHIFT example added.
RMFINTRV 15.138 Report RPGNs/Classes can be used in IMACWORK!!!
SMFPRM00 15.053 First draft of MXG recommendations for SMF parms.
TRND72GO 15.135 Trending for TYPE72GO WLM Goal Mode Service Classes.
TYPE102 15.113 DB2 Trace IFCID=125 logic revised.
TYPE102 15.121 Negative values for DB2 fields decoded with format.
TYPE102 15.132 DB2 Trace dataset T102S106 now corrected.
TYPE110 15.133 Leap Seconds support correct "GMT" to local.
TYPE116 15.043 TYPE116 variable QWHCTNO remains numeric.
TYPE1415 15.124 Support for APAR OW25263 (for 3590s)
TYPE30 15.063 TYPE30OM for OMVS discoveries
TYPE30 15.065 EXCP/IOTM for UCB addresses over '8000'x wrong.
TYPE30 15.133 Leap Seconds support converts "GMT" to local.
TYPE42 15.106 Support for APAR OW20921 creates TYPE42VT (VTOC+).
TYPE42 15.112 Support for APAR OW26451/OW26453/OW26497 MAXRSPTM+.
TYPE50 15.185 Support for VTAM 4.4 changes to SMF type 50.
TYPE6 15.009 Support for APAR OW25152 (PRINTWAY Print Queue Name)
TYPE6 15.015 Support for Anacom's Anastack spooler type 6 SMF.
TYPE6 15.016 Support for CA-DISPATCH Version 6 w/5-digit JSENR.
TYPE6 15.039 Invalid "MVS PSF DOWNLOAD" type 6 records, APAR.
TYPE6156 15.176 Support for Invalid Catalog Cell '05'x segment.
TYPE6156 15.193 Another invalid '04' Catalog Cell STOPOVER.
TYPE7072 15.004 OS/390 R3 type 72 INPUT STATEMENT EXCEEDED RECORD.
TYPE7072 15.013 Variable SSTORE72 (Shared Pages Bytes) created.
TYPE7072 15.023 TYPE70 variable PCTMVSBY wrong in MDF shared CPUs
TYPE7072 15.026 New variable VELONOIO calculates NO I/O Velocity.
TYPE7072 15.038 TYPE72GO PERFINDX, R723CIRC and R723CICT wrong.
TYPE7072 15.182 TYPE72GO VELOCITY wrong for Discretionary/System
TYPE7072 15.183 TYPE72GO was OUTPUT when NOACTVTY was zero.
TYPE71 15.064 Variable SLOTUTIL added to TYPE71 - slot usage
TYPE74 15.008 Support for Hitachi 7700 Cache Records (INCOMPAT)
TYPE74 15.011 Variable SMF744PN added to TYPE74CF to count CPUs.
TYPE74 15.058 Cache TYPE74CA clean up and new variables added.
TYPE78 15.061 PCTDIRPT/PCTCUBSY in TYPE74CF wrong.
TYPE80A 15.107 Dataset TYPE8025 now created for RACF Event 25.
TYPE80A 15.158 Support for RACFEVNT=22 and 59, repeated segments.
TYPE92 15.003 OMVS file GMT datetimestamps now converted to local.
TYPE94 15.073 Support for Virtual Tape Server additions to SMF 94.
TYPE94 15.130 TYPE94 variable SMF94ETO restored.
TYPE99 15.165 Support for "Goal Mode SMF" type 99 subtype 6.
TYPEACF2 15.197 ACF2JR dataset variable ACLFLDVL populated.
TYPEBETA 15.181 INVALID ARGUMENT in BETA93 SMF record *RELOAD*.
TYPECACH 15.008 Support for Hitachi 7700 Cache Records (INCOMPAT)
TYPECIMS 15.033 ABENDSYS/ABENDUSR in IMF 1.3+ is corrected.
TYPECIMS 15.082 Support for Boole and Babbage IMF 3.2 (for IMS 6.1.)
TYPECMF 15.187 Variable C279SSI changed from numeric to character.
TYPECTLG 15.166 Support for Catalog Cell 'E7' (Alias).
TYPEDB2 14.095 Support for DB2 Version 5.1.0 (COMPATIBLE).
TYPEDB2 15.133 Leap Seconds support correct "GMT" to local.
TYPEDCOL 15.108 High Used RBA can be greater than Allocated Space.
TYPEDCOL 15.163 Support for DCOLLECT in DFSMS 1.4 (COMPAT).
TYPEEDGR 15.140 Support for new fields in DFSMSrmm extracts.
TYPEEDGS 15.021 Variables EDGSADTE,EDGSARSD,EDGSASID, formats value.
TYPEFTEK 15.102 Support for Filetek Optical Disk SMF record
TYPEHMF 15.192 Support for HMF SMF Subtype 11 (DS3 Statistics).
TYPEHURN 15.195 Support for ObjectStar 3.0 (INCOMPATIBLE).
TYPEICE 15.134 Support for IXFP SMF subtypes 6 and 7
TYPEIMSD 15.081 Support for IMS DBCTL transactions from IMS 07/08s.
TYPEMEMO 15.071 Support for MEMO subtype 8, creates MEMODIST dataset
TYPEMIM 15.059 Segments not output after MIMCNT=0 with MIM V 3.
TYPEMWSU 15.068 Revised support for HP's MeasureWare for SUN
TYPEMWUX 15.022 HP-MW and HP-PCS base date now JAN1970 vice JAN70.
TYPENSPY 15.067 Support for NETSPY Version 5.0 is in MXG 14.14.
TYPENSPY 15.069 ARSPHOST missing in NSPYLU dataset for NETSPY 4.4
TYPENSPY 15.168 Zero obs in NSPYTIC3 corrected.
TYPENTSM 15.012 NTSMF records from NT 3.51 now supported.
TYPENTSM 15.027 NTSMF new objects created by COMPAQ hardware.
TYPENTSM 15.147 Support for NTSMF Version 2.0 (INCOMPAT).
TYPENTSM 15.147 Support for Windows NT 4.0 Service Pack 2 (INCOMPAT)
TYPENTSM 15.190 Support for five new NTSMF Objects.
TYPEOMVT 15.150 INPUT STATEMENT EXCEEDED Omegamon VTAM 200 IRNUM=12.
TYPEOPC 15.188 OPC 3.1 datasets OPC23, OPC29, OPC31 corrected.
TYPEPW 15.010 Support for Landmark's Performance Works/Smart Agent
TYPEQAPM 15.052 Support for all OS/400 Release 3.7.0 records.
TYPEQAPM 15.105 Dataset QAPMAPPN has variables wrong.
TYPEQAPM 15.127 AS/400 variable AS400SYN missing if SYSTEM LT 8.
TYPERACF 15.103 Support for RACF utility IRRDBU00's OMVS RACF data.
TYPERDS 15.144 Zero observations in TYPERDS1-TYPERDS7 datasets.
TYPEROSC 15.017 Support for CA-ROSCOE Version 6 SMF is verified.
TYPESFTA 15.030 SOFTAUDIT collect only at JOB record was deleted.
TYPESTC 15.186 STK 4400, STCLMU variables decoded.
TYPESVCC 15.200 Support for Peregrine's Service Center SMF.
TYPETMDB 15.114 TMON/DB2 subtype "DW" now supported.
TYPETMDB 15.184 Support for TMON/DB2 record type "DE".
TYPETMNT 15.077 Support for new fields added by ML-12 of ASMTAPES.
TYPETMNT 15.110 Enhancements in preparation for ASMTAPES ML-14.
TYPETMON 15.001 File counts incorrect in TYPETMON datasets.
TYPETMON 15.054 Variables SYSTEM/SYSID truncated to only one byte.
TYPETMON 15.139 Landmark CICS fix TT00032 creates one bad record.
TYPETMS5 15.199 Support for CA-1/TMS Release 5.2 (COMPATIBLE).
TYPEVM 15.189 Support for VM ADSM Account Records in VM/ESA.
TYPEWWW 15.086 Support for World Wide Web Common Log Format records
TYPEXPSM 15.172 Support for Xerox's XPSM Version 2 SMF records.
TYPEZARA 15.074 Support for Altai's ZARA Tape Management Release 1.2
UDUMPEBC 15.085 Utility to produce MVS-like LIST; hex dump on ASCII.
UTILCONT 15.056 Now a %MACRO - displays SAS dataset sizes (in MB).
VMACUCB 15.125 VIO detection conflict with DEVNR='7FFFF'x.
VMXGCOMP 15.100 %MACRO utility to compare SAS Data Libraries
VMXGOPTR 15.099 %MACRO to reset (most) SAS Options.
VMXGSUM 15.098 Enhancement to protect OBS=0, and USER= options.
WEEKBLDT 15.115 Dataset TYPE77 causes failure, wrong BY list.
YEAR2000 15.045 DATETIMExx won't display yyyy if truncated.
Inverse chronological list of all Changes:
===Changes thru 15.206 thru Change 15.001 were included in Newsletter 32
and are available in CHANGESS member.