COPYRIGHT (C) 1984-2007 MERRILL CONSULTANTS DALLAS TEXAS USA
CHANGE 15.15
=========================member=CHANGE15================================
/* COPYRIGHT (C) 1984-1998 MERRILL CONSULTANTS DALLAS TEXAS USA */
This is MXG Version 15.15 - dated Feb 23, 1998, thru Change 15.391.
Second MXG Version 15.09 - dated Feb 17, 1998, thru Change 15.384.
First MXG Version 15.09 was dated Feb 16, 1998, thru Change 15.382.
Newsletter THIRTY-TWO was dated Feb 23, 1997, thru Change 15.382.
MXG Version 15.08 was dated Jan 15, 1998, thru Change 15.340.
MXG Version 15.07 was dated Dec 18, 1997, thru Change 15.311.
MXG Version 15.06 was dated Nov 24, 1997, thru Change 15.287.
MXG Version 15.05 was dated Oct 02, 1997, thru Change 15.238.
Newsletter THIRTY-TWO was dated Sep 12, 1997, thru Change 15.206.
MXG Version 15.04 was dated Sep 01, 1997, thru Change 15.206.
Final+ MXG Version 15.03 was dated Jun 30, 1997, thru Change 15.151.
Final MXG Version 15.03 was dated Jun 26, 1997, thru Change 15.148.
Second MXG Version 15.03 was dated Jun 25, 1997, thru Change 15.145.
First MXG Version 15.03 was dated Jun 24, 1997, thru Change 15.144.
MXG Version 15.02 was dated May 23, 1997, thru Change 15.103.
MXG Version 15.01 was dated May 6, 1997, thru Change 15.087.
Newsletter THIRTY-ONE was dated Feb 21, 1997, thru Change 14.343.
Contents of member CHANGES:
I. MXG Software Version 15.15 is now available, upon request.
II. MXG Technical Notes
III. MVS Technical Notes.
IV. DB2 Technical Notes.
V. IMS Technical Notes.
VI. SAS Technical Notes.
VII. CICS Technical Notes.
VIII. Windows NT Technical Notes.
IX. Incompatibilities and Installation of MXG 15.15.
X. Online Documentation of MXG Software.
XI. Changes Log
I. MXG Software Version Status.
I. Annual MXG Software Version 15.15 was shipped to all sites,
along with the printed copy of MXG Newsletter THIRTY-THREE,
during the last week of February, 1998, by US Air Mail.
1. Major enhancements added in MXG 15.15 dated 23Feb1998:
MXG Tape Mount Monitor ASMTAPES ML-16 now supports four-digit UCBs.
Support for RMF Monitor III CPU, PGP, ENC records.
Support for TME 10 Netview OS/390 1.1 SMF type 37.
Major enhancements added in MXG 15.09 dated 16Feb1998:
Support for OS/390 Release 2.5 (no changes, need 15.04 or later).
Support for AIX commands IOSTAT/PSSTAT/VMSTAT output into SAS.
Support for StorageTek's VSM SMF records subtypes 9 thru 25.
Support for IDMS Journal format for IDMS V12.
Support for Boole's IMF 3.2 (for IMS 6.1) INCOMPATIBLE
Landmark TMON for CICS V2 variables renamed.
Landmark for MVS V2 INPUT STATEMENT EXCEEDED.
New &MACxxxx macro variable added to all VMACs to override IMACs.
All VMACs for SMF records now start with IF ID=....
Major enhancements added in MXG 15.08 dated 15Jan1998:
Support for Netview NPM Version 2.3 and APAR OW17876.
Support for AS/400 - OS/400 Release 4.1.0 (INCOMPATIBLE).
Support for ICSS SMF type 103 (Internet Connection Secure Server).
Support for RMF type 79 subtype 15 (IMS IRLM Long Lock) record.
Hardcoded "PDB." DDname externalized into &PDBxxxx macro variables.
ASUMUOW option to get real TRANNAME instead of CPMI/CSMI tranname.
Performance improvements in BUILDPDB (_CDE's ordered, ELSE DOs).
New _Sxxyyy "PROC SORT" macros defined for PDB datasets in IMACs.
Major enhancements added in MXG 15.07 dated 18Dec1997:
Support for DPPX/370 Performance Reporter output.
Support for MODEL204 Version 3.4 INCOMPATIBLE.
Support for SAR CA-VIEW SMF exit SARSRQUX.
Support for Omegamon for VTAM V400 (COMPATIBLE).
Support for Landmark the Monitor for MVS Version 2 (INCOMPATIBLE).
Support for SAR CA-VIEW SARSRQUX SMF record.
Support for Fujitsu's AIM V20 AIM/RDBII SMF type 98 record.
ASMTAPES ML-15 adds dump suppression, OS/390 1.3 JCT changes.
(MXG 15.06 said it contained ML-15, but actually still had ML-14).
VELOCITY variables are now multiplied by 100.
Major enhancements added in MXG 15.06 dated 24Nov1997:
Support for CICS Transaction Server 1.2, INCOMPATIBLE. IBM inserted
new fields in the middle of CICSTRAN record, so you must install
MXG 15.06 or later for CICS TS 1.2 processing. New statistic data
is also captured; see Change 15.274.
Support for Landmark's The Monitor for CICS/ESA 2.0, INCOMPATIBLE.
CICS TS V1.1 APAR UN98309 INCOMPATIBLE, Must install MXG 15.06.
Support for NTSMF Version 2.1 (INCOMPATIBLE), install MXG 15.06.
CICINTRV logic validated, must use this newest revision.
Duplicate CICS UOWTIME values due to SAS non-resolution of DATETIMEs.
Support for Subtype 11 Type 88 System Logger.
Support for Applied Expert Systems Clever TCP/IP.
Support for HP MeasureWare for Terra Data OS.
Support for DFSORT APAR PN71137 (COMPATIBLE).
Support for HP MeasureWare for Terra Data OS in TYPEMWTE.
Support for Boole & Babbage MQ Series MVMQS VSAM History Records.
OS/390 R2.4 Goal Mode IBM Doc Error INVALID DATA R723CIDT fixed.
New IHDR110 exit for CICS record selection by APPLID.
Utility to recreate VBS from data with no RDW/BDW.
Major enhancements added in MXG 15.05 dated 02Oct1997:
Support for JES3 TYPE26 APAR OW26297 adds account fields.
Support for APPC APAR OW16975 APAR-in-Error (INCOMPATIBLE).
Support for 255 Structures in a Coupling Facility (INCOMPAT).
Support for CA's IDMS 14.0 (INCOMPATIBLE).
Support for BETA93 Release 1.3 (INCOMPATIBLE) (subtype 21 only).
Support for SMF type 91 new subtype 21 (SmartBatch) data.
Support for TCP/IP 3.2 API Calls record changes.
Duplicate MULTIDD='Y' step records may not be deleted in BUILDPDB.
Catalog SMF Type 65 record INPUT STATEMENT EXCEEDED corrected.
PDB.ASUMUOW options externalized, zero obs now created by default.
DB2 Trace 102 subtype 140 INPUT STATEMENT EXCEEDED.
Iceberg / IXFP subtypes 2,3,4 not output, MXG 15.02-15.04 only.
TYPE70 variable PCTMVSBY incorrect in MXG 15.01-15.04.
Major enhancements added in MXG 15.04 dated 01Sep1997:
MXG 15.04 Software is now over one million lines (1,008,660)!
MXG now protects ALL date fields for year 2000.
Support for OS/390 Version 2 Release 4 (COMPATIBLE).
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.06
OS/390 2.5.0 Feb 24 1998 15.06
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
CICS-TS V1R1 with APAR UN98309 Sep 15, 1997 15.06
CICS-TS V1R2 Oct 27, 1997 15.06
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 27, 1997 14.14
DB2 5.1.0 Full support Jun 27, 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 ??? ??, 1996. 15.08
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 Jul 4, 1994 12.02
IMS 5.1 Jun 9, 1996 14.05
AS400 3.7.0 Nov 1, 1996 15.01
AS400 4.1.0 Dec 30, 1996 15.08
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.0 15.03
NTSMF Version 2.1 15.06
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 CICS/ESA 2.0 - 15.06
The Monitor for MVS/ESA 1.3 - 12.05
The Monitor for MVS/ESA 1.5 - 12.05
The Monitor for MVS/ESA 2.0 - 15.09
Candle
Omegamon for CICS V200 User SMF 12.05
Omegamon for CICS V300 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. Measurement of CPU Utilization in PR/SM,MDF,MLPF environments.
This note was written for ACHAP10, "Processor Utilization".
The ASUM70PR dataset is built from the TYPE70PR detail data using
%INCLUDE SOURLIB(ASUM70PR); as shown in JCLPDB6 example. There
is one observation in ASUM70PR from each MVS SYSTEM for each RMF
Interval, and that observation describes the utilization of each of
the LPARS, and their sum, which is the hardware busy of the platform.
If you have multiple MVS Systems, and if you process their SMF
data together, then duplicate data will exist in ASUM70PR, since
SYSA's type 70 record will describe all LPARs, and SYSB's type 70
will also describe all LPARs, so you must select only one set of
observations (from SYSA or from SYSB) to avoid duplication.
For each partition, the Partition Dispatch Time and the Effective
Dispatch Time (and their difference, the CPU time when this partition
was dispatched for LPAR management of this partition) are recorded.
There is also a "pseudo" partition named "PHYSICAL" that exists only
in the RMF type 70 record that records the LPAR management dispatch
time that could not be charged to a specific partition.
Schematic of ASUM70PR observation
Total Partition Dispatch (CPU) Time
CPUACTTM= LPnUPDTM summed for all real partitions + LPPUPDTM
CPUACTTM
|______________________________________________________________|
| |
| LPAR #1 | LPAR #2 | LPAR # 3 | "PHYSICAL" |
| LP1UPDTM | LP2UPDTM | LP3UPDTM | LPPUPDTM |
| Dispatched | Dispatched | Dispatched | Dispatched |
|_______________|_______________|_______________|______________|
| | | | | | | |
| | LP1UEDTM | | LP2UEDTM | | LP3UEDTM |
| | LPAR1 | | LPAR2 | | LPAR3 |
| | Effective | | Effective | | Effective |
| | | |
__ __ __ ______________
| | | | | | | |
1 2 3 "Physical"
LP1MGTTM LP2MGTTM LP3MGTTM LPPUPDTM
In-partition LPAR Management Time Unassigned LPAR time
Important variables in PDB.ASUM70PR dataset:
LPnUPDTM - Partition Dispatch Duration for LPAR n.
LPnUEDTM - Partition Effective Dispatch Duration for LPAR n.
LPnMGTTM - LPnUPDTM minus LPnUEDTM, this partition management.
LPPUPDTM - Physical partition dispatch duration.
PARTNCPU - Number of engines in this platform.
PCTCPUBY - Percent "Physically" Busy in all LPARS, equal to the
sum of all partition's (including PHYSICAL) dispatch
time divided by the Total "capacity" of all engines:
100*CPUACTTM/(PARTNCPU*DURATM). This is the percent
of the total capacity of the box that was used. If
the platform has 5 engines, and CPUACTTM was 4 hours
in a one hour interval, PCTCPUBY would be 80%.
PCTLnBY - Percent "Physically" Busy in LPAR n, equal to the LPAR
Dispatch time divided by the Total "capacity" of all
engines in the box: 100*LPnUPDTM/(PARTNCPU*DURATM).
If an LPAR was dispatched for 1 hour, and the CEC has
5 engines, then PCTLnBY for that LPAR would be 20%,
because that LPAR used 20% of the hardware platform.
PCTLnOV - Percent "Phsyically" Busy in "LPAR Overhead" in this
LPAR, 100*LPnMGTTM/(PARTNCPU*DURATM).
LPnNRPRC - Number of engines available to LPAR n.
LPnDUR - LPAR n's "Up time" or "Availability time to execute
CPU", the sum of DURATM across all LCPUs in LPAR n,
or LPnDUR=LPnNPRC*DURATM. This is the duration when
this LPAR could have been dispatched. If the LPAR was
IPLed as a 3-engine MVS machine, in one hour, it would
have 3 hours of "Up Time" (or 3 hours of "capacity").
LPCTnBY - Percent "Logically" Busy in LPAR n, equal to the LPAR
Dispatch time for the partition divided by the LPAR's
"Up Time", 100*LPnUPDTM/LPnDUR. If a 3-engine LPAR
was dispatched for 60 minutes in one hour, its LPCTnBY
would be 33%. This variable describes the percent of
LPAR capacity, in contrast to variable PCTLnBY which
describes the percent of Hardware Platform capacity.
If that same 3-engine LPAR was executing on a 5-engine
CEC, PCTLnBY would be 20%, because that LPAR used 20%
of the hardware platform, while LPCTnBY is 33% of the
CPU time available to this LPAR.
LPnCAP - 'Y' if this partition is capped.
LPnCHG - 'Y' if something changed in LPAR n.
LPnDED - 'Y' if this partition has all-dedicated-CPUs.
LPCTnOV - Percent "Logically" Busy in "LPAR Overhead"
100*LPnMGTTM/LPnDUR, describes how much of the
Dispatch Duration was for management of this LPAR.
Important variables in PDB.TYPE70PR dataset:
LPARNUM - Logical Partition Number, = PARTISHN in TYPE70 dataset
LCPUPDTM - Partition Dispatch Time
LCPUEDTM - Partition Effective Dispatch Time
The following example is real data from a 5-engine CEC (Central
Electronic Complex, the preferred name for a platform). This CEC
has three LPARs: LP1 has two engines (and is lightly used), LP2 has
five engines, and LP3 has three engines. All CPUs are shared and
Wait Completion is No. One hourly observation in ASUM70PR showed:
PARTNCPU 5 - Number of real engines in CEC
DURATM 1:00:00.05 - Duration interval
CPUACTTM 4:40:35.32 - Total CPU Dispatch, all engines
CPUOVHTM 15:35.40 - Total CPU Overhead in LPARS
LPPUPDTM 6:40.28 - Total "Physical" Overhead
PCTCPUBY 93.53% - CPUACTTM as a percent of hardware
PCTOVHD 5.20% - CPUOVHTM as a percent of hardware
PCTPOV 2.22% - LPPUPDTM as a percent of hardware
LP1 LP2 LP3
LPnNRPRC 2 5 3
LPnDUR 2:00:00.10 5:00:00.25 3:00:00.15
LPnUPDTM 4:49.67 3:33.06.54 55:58.85
LPnUEDTM 2:56.63 3:29:16.51 52:46.77
LPnMGTTM 1:53.03 3:50.02 3:12.07
LPCT1BY 4.02% 71.04% 31.10%
LPCT1OV 1.57% 1.28% 1.78%
PCTL1BY 1.61% 71.04% 18.66%
PCTL1OV .63% 1.28% 1.07%
The LP2 has the same PCTL2BY as LPCT2BY because it can use
all five engines, and its logical and physical utilization
are the same. The LP3, with only three engines available
to its MVS, shows it is using 18.66% of the five hardware
engines (PCTL3BY), while LPCT3BY shows that this actually
is 31.1% of the CPU time possible for those three logical
CPUs available to LP3.
The dispatch time measurements in ASUM70PR are always accurate in
describing the total platform busy and each LPARs use of the total,
because when an LPAR is dispatched, its processors are not available
to any other LPAR, and thus ASUM70PR does report platform capacity.
Furthermore, if all CPUs are shared and Wait Completion is No, the
ASUM70PR dispatch duration is the actual CPU busy time, so not only
is the total platform capacity known, but also the utilization of
individual LPARs is measured in ASUM70PR.
The problem arises when CPUs are Dedicated to an LPAR, or when Wait
Complete = Yes is used, because the dispatch time in those cases is
NOT equal to the CPU executing time. While a dispatch time of one
hour does mean that one hour of total platform capacity was used by
an LPAR, (i.e., not available to other LPARs), the actual CPU time
used by that LPAR may be a lot less than one hour. What we need is
the Wait time measured inside each MVS system, which is in the MVS
TYPE70 dataset, but each type 70 record only has a single TYPE70
segment (for the LPAR in which this MVS System executed); we do not
get a TYPE70 segment for the other LPARs. But MXG does store the
MVS Wait Time from the TYPE70 segment into variable ORIGWAIT in the
TYPE70PR observation for each LCPUADDR, which shows this data:
Wait Complete = YES example: System SYSC (LPARCPUS=2 PARTNCPU=4)
LPARNUM=PARTISHN=2
LCPU=0 LCPU=1
DURATM=15 min DURATM=15 min
|---------------------------------|-------------------------------|
8 min 7 min 15min
|--------------------|------------|-------------------------------|
Dispatched LPAR Wait Dispatched
LCPUPDTM 70PR calc LCPUPDTM 70PR
5 min 3 min 7 min 11 min 4 min
|----------|=========|------------|---------------------|=========|
ORIGWAIT BUSY LPAR Wait ORIGWAIT BUSY
70 calc calc 70 calc
This LPAR has two LCPUs, Wait Complete=Yes, but due to the other
LPAR on this platform (that was also using Wait Complete=Yes), the
LCPU=0 was dispatched for only 8 minutes of the 15 minute interval,
while LCPU=1 was dispatched for all 15 minutes. The ORIGWAIT from
TYPE70 shows that LCPU=0 was actually CPU Busy for only 3 minutes,
and LCPU=1 was actually CPU Busy for only 4 minutes.
While there are only two LCPUs for this LPAR, this LPAR is in a
platform that has four engines, so the ASUM70PR calculation is:
PCTL2BY = (8 disp + 15 disp )/ (4*15) = 23/60 = 38%
because 38% of the dispatch capacity of the four engines in the
hardware platform was consumed by this LPAR in this interval.
However, RMF in its CPU Activity Report calculates two percentages
(and MXG replicates in both TYPE70 and TYPE70PR data):
PCTCPUBY = "LPAR Busy Time" = (3 busy + 4 busy) / (2 * 15) = 23%
PCTMVSBY = "MVS Busy Time" = (10 busy+lparwait + 4 busy)/30 = 48%
The "LPAR Busy Time" shows that this LPAR was busy for 7 of the 30
minutes that the two engines in the LPAR could have been executing,
and thus is a measure of how busy the MVS system might have been.
However, the "MVS Busy Time" calculated by IBM is at best confusing
and at worst wrong, for Wait Completion = Yes LPARs, because it
calculates the MVS busy time as DURATM minus ORIGWAIT, adding the 3
minutes busy and 7 minutes of LPAR wait from LCPU=0 to the 4 minutes
busy from LCPU=1 to conclude 14 minutes of "busy time" out of the
30 minutes that the two engines could have been executing, for 48%!
But the MVS SRM never saw those possible 30 minutes of execution; it
was dispatched for only 8 + 15 = 23 minutes, so a far more accurate
measure is "SRM Busy Time", the busy time over the dispatched time:
PCTSRMBY = "SRM Busy Time" = (3 busy + 4 busy) / 23 (dispatch) = 30%
which more accurately reflects what MVS can do with Wait Comp=Yes,
and it strongly suggests that the IBM "MVS Busy Time" is wrong for
Wait Comp=Yes. Note: Jan 2006: Using WAITCOMP=YES is no longer an
issue; only the early AMDAHL implemented that option, as I recall.
(The example used the Partition Dispatch times, but to be
slightly more precise, using the Effective Dispatch times would
show what was delivered to MVS. I am still deciding if I should
create a new variable for PCTSRMBY, but want to send this
preliminary note to MXG-L, so I will update this part of this
note at a later date.)
Dedicated example: System SYSA (LPARCPUS=3 PARTNCPU=4)
LCPU=0 Dedicated, Wait=No
LCPU=1,2 Shared, Wait=No
LPARNUM=PARTISHN=5
LCPU=0
DURATM=15 min DURATM=15 min
|---------------------| |------------------------------------|
LCPU=1
14:59.20 5:48.92 8:25.73 0:45.35
|---------------------| |===============|---------|----------|
Dispatched Dispatched ORIGWAIT Non-Disp
LCPUPDTM 70PR LCPUPDTM 70PR 70 Non-Wait
BUSY calc
LCPU=2
3:11.51 11:48.49 5:49.20 8:25.41 0:45.39
|----------|==========| |===============|---------|----------|
ORIGWAIT BUSY Dispatched ORIGWAIT Non-Disp
70 calc LCPUPDTM 70PR 70 Non-Wait
BUSY calc
For all the three LCPUs in this LPAR, MXG calculates in ASUM70PR:
PCTL5BY = 100* ( 26.5 / 4*15) = 100 * 26.5 /60 = 44.37%
because the total dispatch time of the three LCPUs was 26.5 minutes
of the possible 60 minutes of dispatch time in the four engines of
the platform, and this is this LPAR's use of dispatch capacity.
But if we have the TYPE70PR observation from the system that has the
ORIGWAIT measurement from TYPE70 for that dedicated LCPU, we can see
the LPAR's total CPU busy time was only 11:48 + 5:48 + 5:49, or 22.5
minutes, since 3 minutes of that dispatch time was in MVS wait time!
The IBM RMF calculations for each LCPU and the total for all three
LCPUs in this LPAR show:
LCPU PCTCPUBY (calc) PCTMVSBY (calc) Status
0 78.72 (11:48/15) 78.72 (11:48/15) Ded,Wait=No
1 38.77 ( 5:48/15) 43.81 ( 6:33/15) Shr,Wait=No
2 38.80 ( 5:49/15) 43.84 ( 6:34/15) Shr,Wait=No
all 52.10 (23:17/45) 55.46 (24:55/45) Combined
For the Dedicated LCPU, both PCTCPUBY and PCTMVSBY are calculated
PCTCPUBY=PCTMVSBY= 100*(DURATM-ORIGWAIT)/DURATM = 78.7%
PCTMVSBY=PCTCPUBY= 100*(DURATM-ORIGWAIT)/DURATM = 78.7%
For the Shared, Non-Wait LCPUs, the "Lpar Busy Time" is
PCTCPUBY= 100*LCPUPDTM/DURATM = 38.7%
but the IBM calculation for the "MVS Busy Time" is
PCTMVSBY= 100*(DURATM-ORIGWAIT)/DURATM = 43.8%
because the PCTMVSBY value includes the 45 seconds of non-dispatched
non-wait time recorded in the MVS Busy Time calculation!
Again, while PCTCPUBY is legitimate, PCTMVSBY raised more questions
than it answers, initially. Note: Jan 2006: However, now it is
used to calculate the SHORTCPS variable, and is thus useful.
To summarize what percentages are printed where by IBM and reported
where by MXG, on RMF CPU Activity Report, the "LPAR Busy Time Perc"
is variable PCTCPUBY, and the "MVS Busy Time Perc" is variable
PCTMVSBY in dataset TYPE70 (and now in TYPE70PR as well). On RMF's
Partition Data Report, IBM's "Logical Processors Total" is variable
LPCTnBY, and IBM's "Physical Processors Total" is PCTLnBY in dataset
ASUM70PR for each LPAR, and the "Physical Processors Total" is the
variable PCTCPBUY in ASUM70PR.
Note: I intend to revise this note as I learn more, especially for
millennium and/or MDF, in the near future. The purpose of this
much of the note was to document what is calculated by MXG and by
IBM when you try to compare RMF reports to MXG datasets, and to
point out basic problems if you have Dedicated or Wait Comp = YES.
Not only is there a problem in ASUM70PR in that we do not know the
true CPU busy time, we also have assumed the "capacity" was the
DURATM of the interval, but that is not always the case, especially
when LPAR weighting is taken into account. No single percentage
value can be used, as it depends on your perspective. ASUM70PR
reports usage percentages of the "dispatch" capacity, while TYPE70
still must be used to understand what is happening inside each MVS.
2. FAT32 file system reduces space needed for MXG from 139MB to 68MB.
On Windows 95 and Windows NT with FAT File Systems, the MXG Source
Library directory DIR command shows 3549 files totaling 57.7 MB,
but the files in that directory actually required 139.1 Megabytes
of disk space! The 2GB disk drive with 32K cluster size wastes
space if the file is less than 32KBytes, and as only 272 of MXG's
source files are over 32K in size, the other 3277 small files waste
lots of disk space with large cluster size under FAT file systems.
Well that is a dead problem with the newer FAT32 file system that
virtually eliminates the space waste problem. That same source
library required only 68.23 MegaBytes on a 9GB FAT32 disk drive!
III. MVS Technical Notes.
1. APAR OW25609 corrects a stoppage of SMF type 30 interval records
(subtypes 2 & 3) and type 23 records, after a serialization problem.
The APAR applies to MVS/4.3 thru OS/390 2.4.
2. APAR OW28289 changes counts in type 30 variables TAPNMNTS/TAPSMNTS
(SMF30PTM/SMF30TPR). In DF/SMS 1.2 and earlier, tape mount counts
were the number of physical mounts (actually, a count of volumes
that were verified by OPEN/CLOSE/EOV via a loadpoint read of the
VOL1 tape label). That was changed by an SPE to DF/SMS 1.2.0 (which
was included in DF/SMS 1.3.0 and 1.4.0); IBM decided instead to
count logical volumes (i.e., increment the mount count when OPEN
processing is entered with the tape drive in a ready state and with
the mounted volume at loadpoint). A document change was prepared
but never distributed, and now IBM is backing out the SPE's effect,
and with this APAR, the counts revert to physical mount counts. The
APAR's text is confusing, because it lists PTFs for DF/SMS releases
1B0, 1C0, and 1D0, which turn out to be DFSMS 1.2, 1.3, and 1.4,
respectively. If you depend on the count of tape mounts in type 30
records, you will want to apply this PTF.
3. APAR OW28613 corrects errors in the JES2 Type 26 Purge record in the
SMF26OAG Accounting Section offset. I earlier thought MXG would not
fail, but without that APAR, MXG offset validation was insufficient,
an INPUT STATEMENT EXCEEDED occurs. Now, Change 15.330 circumvents
the wrong value for SMF26OAG, but the ACCOUNTn fields in TYPE26J2
will be blank until you install to APAR to correct IBM's error.
Fortunately, MXG only uses the TYPE26J2 ACCOUNTn fields for jobs
that do not produce type 30s (JCL Errors or Cancel before start).
4. APAR OW28256 reports invalid CPU times measured (once again!) in RMF
type 72 field SMF72RCT (MXG Variable CPURCTTM, which is summed into
variable CPUTM); PTF was available November 14 1997. This causes
the total CPU time captured in type 72 records to exceed the total
CPU busy time, causing the Uncaptured CPU time (misnamed as CPUOVHTM
and labeled as "Overhead") to be negative in RMFINTRV. This same
field was in error in 1992, fixed then by APAR OY51878. MXG now
detects the negative value and prints this error message on the log:
"ERROR. NEGATIVE CPU-UNCAPTURED-TIME (TYPE70-TYPE72)".
See text of Change 15.238 for more details.
5. APAR OW26619 for OS/390 V2.4, in Goal Mode corrects WLM errors found
by IBM during final function test, and corrects SMF values.
6. APAR OW26421 for OS/390 V1.3 is needed only for ASMTAPES. In OS/390
IBM created two 4-byte fields for Y2K support to replace the 3-byte
fields JCTSSD and JCTJMRJD (step and job start/init dates), but I
missed that change, so ASMTAPES still used the 3-byte fields. But
IBM also zeroed the 3-byte fields, which caused INVALID DATA when
TYPETMNT was executed, and variable INITTIME has missing value.
This APAR restores the dates in the 3-byte fields, so INITTIME will
not be missing. The ML-15 of the MXG ASMTAPES avoids the exposure
by using the 4-byte fields if they are present.
7. SYNCSORT 3.6 can ABEND 0C9 during a PROC SORT; SYNCSORT fix SY49930
is the correction.
8. APAR OW30153 corrects type 30 Measured Usage (MULC) segments. There
are multiple occurrences of the same product name and qualifier for
PRODNAME=CICS PRODQUAL=DFHKETCB in the interval records that should
have had only a single segment. There are still other errors that
are not addressed in creating the subtype 4 and subtype 5 records
from the interval records. One CICS job had 39 DHFKETCB segments in
its interval records (subtype 2 and 3), but had 37 segments in its
step termination record (subtype 4) and then had only 36 segments in
its job termination record (subtype 5). Further, the job had 12
DFHSIP segments in the interval records but had 16 segments in both
step and job terminate. Finally, the job had 2 DFHDUP segments in
the job term but none in either the interval or step term records.
A new problem has been opened with IBM on this error.
Note that old APAR OW16176, which consolidates MULC sections for
each product, should be installed. Increasing SMF buffers with
APAR OW12836 is also recommended to minimize the problems with SMF
buffers, and especially specification of DDCONS=NO in SMFPRMxx in
SYS1.PARMLIB is strongly recommended to eliminate the SMF address
algorithm to consolidate DD segments.
Note added Dec 30, 1997:
APAR PN80497 corrects a problem after applying UN84065 with Measured
Usage (MULC) that can create millions of type 30 subtype 3 records
with the same product name in the MULC segment. The problem
occurred with an IMS BMP that used MQ Series. The excess records
could cause IEE979W SMF DATA LOST - NO BUFFER SPACE AVAILABLE.
9. APAR OW30059 (PTF available 12Dec97) reports type 42 values for
Direct Write and Direct Read SMF42DWB/SMF42DRB and this APAR is
likely the fix that was originally described in note 26 in MVS
Technical Notes in MXG Newsletter THIRTY-TWO for APAR OW20926.
When the channel program did single CI reads and writes, residual
data was left in the counter that was not used.
10. APAR PQ09396 (Target 26Dec97) for MQSERIES SMF type 116 reports
inconsistencies between 115 and 116 record's statistics.
11. APAR PQ09083 is for subtype '51'x of the FTP SMF record (VMACFTP).
The text mentions SMF Record Type 51, but there is no type 51 SMF
record (yet). The APAR corrects missing values in variables
DVGSETME/DVGSEDTE in dataset FTP51X.
12. Job Accounting for Started Tasks became available with MVS/ESA 5.1,
because you can now have a JOB card in the JCL for your STC's, and
can put ACCOUNT parameters in that JOB card that show up in MXG's
ACCOUNTn variables in PDB.JOBS/PDB.PRINT/PDB.STEPS datasets. The
JCL Reference Manual Sections 7.2, 7.3, and 16.7 discuss how.
13. What happens to measurements if I have a Y2K Test System in an LPAR?
You can use the ASUM70PR dataset and select the observations from
your production LPAR (SYSTM='PROD') to measure the Y2K Partition's
resources, since the STARTIME of the records with SYSTEM='PROD'
will be your local time of day.
All of the records written on SYSTEM='Y2K' will have the year 2000
dates (although the READTIME value could be earlier if jobs were
read into the hold queue before IPLing with year 2000). Since the
Y2K system will be re-IPLed repetitively with the same start value
(probably 31DEC99:23:45:00), RMF interval data will appear to have
duplicate data and the jobs/steps from all IPLs will be jumbled
together, because MXG sorts RMF data by STARTIME and job data by
READTIME.
You can extract SYSTEM='Y2K' data for a specific "test run" by
finding the record number (_N_) of each SMF IPL record, using:
%INCLUDE SOURCLIB(VMACSMF);
DATA _NULL_;
_SMF;
IF ID=0 THEN PUT 'IPL RECORD FOUND ' _N_= SMFTIME=;
and then use the record number of the specific IPL to select only
the SMF records desired. If you wanted the third run, and the third
IPL record had _N_=8,000 and the next IPL record had _N_=10,000, you
would use this logic:
%INCLUDE SOURCLIB(VMACSMF);
DATA _NULL_;
_SMF;
FILE SMFOUT DCB=SMF;
IF 8000 LE _N_ LE 9999 THEN PUT _INFILE_;
IF _N_ EQ 10000 THEN STOP;
to write to //SMFOUT DD only those records for that test run.
There is an alternative. You can use the IPL PROMPT feature to
require the operator to reply with the (local) time and the reason
(describe the test run) for each IPL, and there will be a SUBTYPE=8
observation in dataset TYPE90 with variables DTIME and IPLREASN with
the operator's reply, so the TYPE90 dataset can be used to identify
the records in each test run (variable SMFRECNR, equal to _N_, was
added to the TYPE90 dataset by Change 15.267).
You must have specified PROMPT(IPLR) or PROMPT(ALL) in member
SMFPRMxx in SYS1.PARMLIB dataset to prompt the operator for the
reply at each IPL.
14. Almost-Duplicate TYPE74 records, differing only by one second in the
STARTIME, can be written by Boole & Babbage's CMF Product, if both
IPM and CPM modes are enabled. This has happened recently as sites
installed OS/390. In MXG's TYPE7xxx datasets, variable PRODUCT will
be 'CMF-IPM' in one almost-duplicate record, and 'CMF-CPM' in the
other observation. Boole does NOT recommend both modes!
15. Channel Type variable CHANTYPE in dataset TYPE73 still exists, but
variable SMF73CPD provides a better description as it describes both
ESCON and Parallel Channel types. SMF73CPD was new in MVS/ESA 5.1.
16. APAR OW27855 corrects PSF/MVS-written type 6 SMF records so that
they now contain the node number of the current node in field
SMF6ROUN, which MXG decodes into variable NODE and RMOTID in TYPE6
dataset.
17. APAR OW20844 enables JES2 job numbers greater than 32000, but has
no impact on MXG, since MXG has supported 5-digit JES Numbers thru
99999 from the JCTJOBID for several years.
IV. DB2 Technical Notes.
1. There are no DB2 Technical Notes in this newsletter.
V. IMS Technical Notes.
1. Support for Boole's IMF 3.2 (for IMS 6.1) was added in MXG 15.09.
Candle has not informed me of any changes in their ITRF product.
2. Discussion of IMS Log support in MXG Software.
I strongly recommend you use an IMS monitor (Boole or Candle)
that creates a transaction record, rather than attempt to use
IBM's IMS log for transaction response and resource measurement.
See MXG newsletter TWENTY-FIVE, IMS Technical Notes, for the MXG
position statement of the technical reasons why you cannot measure
the response time and resources (CPU, DL/I calls) for transactions
with only IBM's standard IMS log records.
However, you CAN use the TYPEIMS7 MXG program to get accurate counts
of transactions and resources by transaction, because it uses IMS 07
and IMS 08 log records, written for each deschedule of an IMS
program, which contains the count of IMS transactions that were run
during that program schedule (can be 1, usually is at least 5
transactions per schedule, and be millions for WFIs), the
transaction name, and the total CPU time and DL/I calls for all
of those IMS transactions. But you cannot get accurate resources
per transaction from the IMS 07/08 records. At best, you can get
the "average" of each group of transaction processed if you are
willing to divide the CPU time by the number of transactions run,
and you'll get fractional numbers of DL/I calls per transaction!
MXG Member TYPEIMFL will read the IMS log and will select and create
all possible datasets from any combination of Boole's IMF log
records (LCODE=FAx) IBM IMS log records (01,03,07,08,31x,36x,40x,
plus fastpath 59x subtypes 01,03,36x,37x,38x) and SAP IMS log
records (LCODE=AEx). Members TYPEIMFL and TYPEIMS7 both use macros
that are defined in VMACIMS to decode those IMS log records, and
which are fully supported by MXG.
Unfortunately, I have received no test data nor the needed assembly
of ILOGREC for IMS 6.0 or IMS 6.1, so MXG log record support for
the IBM IMS log records may or may not fail with IMS 6; that no one
has reported a problem only suggests that perhaps IBM made no change
in their records, but once I have test data and documentation, I
will know for sure if there were changes.
It is not the reading of the IMF, IBM, and SAP IMS log records that
is the problem, but rather it is the construction of the
many-records-per-transaction-without-a-merge-key into a single
transaction record with per-transaction resources and response that
is in principle impossible with IMS log records.
Nevertheless if you still must try to get IMS response time with
only IBM's IMS log records, because your management still won't buy
you an IMS monitor tool, then, at your own risk, you can probably
get good results with the MXG assembly program ASMIMSL5 (IMS 5) or
ASMIMSLG (IMS 4) and their JCLIMSLG example. The ASM program acts
like an IMS MPR and reads the log to figure out which records go
with which transaction, and writes a copy of the IMS log records
with an appendage to identify the transaction, and then the MXG SAS
programs invoked in JCLIMSLG read the extended IMS log records to
crate dataset IMSTRAN with observations on a per-transaction basis.
These transaction records will always contain only average CPU and
DL/I calls, but the response time for each transaction is usually
quite accurate, although a few transactions may not be perfectly
matched and can have very large response times (and sometimes the
output queue time is accurately very large!). It is not guaranteed
that ASMIMSL6 will exist, but it is my hope to continue to provide
this crutch for IMS sites unwilling to purchase an IMS monitor.
VI. SAS Technical Notes.
1. There are no MXG problems using the Version 6.09 of the SAS System.
In fact, there have been no MXG problems with Version 6.08 at TS430
or later maintenance levels! Perhaps that is because MXG Software
is now a standard part of the SAS Quality Assurance test stream?
VII. CICS Technical Notes.
1. How can you use USER instead of TERMINAL to bill CICS transactions.
IBM note RTA000013242 Library item Q451666 answers the question,
"How can you use USER instead of TERMINAL to bill CICS transactions
in an ISC or MRO CICS environment (i.e., when using transaction
routing?", by pointing out that when you specify USERSEC=IDENTIFY
or ATTACHSEC(IDENTIFY) on the SYSTEM entry or CONNECTION definition,
the USER field is then propagated into the records created in the
AOR and other regions observations in CICSTRAN.CICSTRAN.
If you are billing CICS and DB2 by transactions, you really should
look at the ASUMUOW member that summarizes CICSTRAN and DB2ACCT and
their CPU times into one record per Unit of Work, reducing the
number of "things" you have to count. ASUMUOW keeps both TERMINAL
and USER as well as both CICS and DB2 CPU times plus CICS response
buckets in its output dataset PDB.ASUMUOW. If you were using
ASUMCICS to create PDB.CICS summary data, you will find ASUMUOW
preserves the CICS resource and response fields from PDB.CICS and
adds in the DB2 information. ASUMUOW replaces the earlier ANALDB2C
report program that merged DB2ACCT and CICSTRAN records.
VIII. Windows NT Technical Notes.
1. Use /B "Binary" switch on the COPY command to eliminate '3F'x.
Two sites had STOPOVER ABENDS on MVS reading NTSMF data that had
been COPYed under Windows NT Server before uploading to MVS. The
hex dump showed a one-byte physical record containing a '3F'x.
Another site's TYPENTSM job failed with a 180 abend; the VMACNTSM
member had been COPYed, and an extra line containing '3F'x had been
appended to the source file. It is apparently a documented fact
that the COPY command can add an ASCII End-of-File Character at
the end of a copy whenever multiple input files are copied into an
output file. That ASCII End-of-File Character then becomes the
separate physical record on MVS after uploading and translation
from ASCII to EBCDIC with ftp. Using the /B "Binary" switch on
the COPY command was found to eliminate the extra character.
To read the uploaded file with the short record without ABENDing,
you can change MXG's STOPOVER option to MISSOVER by using:
MACRO STOPOVER MISSOVER %
as your first SAS statement, before the %INCLUDEs in your SYSIN.
IX. Incompatibilities and Installation of MXG 15.15.
1. Incompatibilities introduced in MXG 15.15 (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):
IMACPTF, if you install PTF UN98309 for CICS Transaction Server 1.1
b- Other incompatibility changes:
Users of SAS ITSV V1 and V2.0 and SAS/CPE must install the two line
circumvention described in the text of Change 15.320 to use MXG
Version 15.08 or later. SAS ITSV Version 2.1 is compatible and
the circumvention is not required.
c- These products were incompatibly changed by their vendor, and they
require MXG Version 15.xx as indicated:
Boole's IMF 3.2 (for IMS 6.1) MXG 15.09 Change 15.372
CICS TS V1.2 MXG 15.06 Change 15.274
CICS TS V1.1 APAR UN98309 MXG 15.06 Change 15.258
Landmark TMON CICS 2.0 MXG 15.06 Change 15.281
Landmark TMON MVS 2.0 MXG 15.09 Change 15.346
NTSMF Version 2.1 MXG 15.06 Change 15.249
255 Structures in a Coupling Facility MXG 15.06 Change 15.226
BETA93 Release 1.3 MXG 15.06 Change 15.237
IDMS 14.0 MXG 15.05 Change 15.218
Coupling Facility more than 64 Structs MXG 15.05 Change 15.226
APPC APAR OW16975 APAR-in-Error MXG 15.05 Change 15.227
ObjectStar 3.0 MXG 15.04 Change 15.195
NTSMF Version 2.0 MXG 15.05 Change 15.220
DB2 Version 5.1.0 two SMF 102 IFCIDs MXG 15.02 Change 15.095
Hitachi 7700 Cache R.R. records MXG 15.01 Change 15.008
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.
X. Online Documentation of MXG Software.
MXG Documentation is now described in member DOCUMENT.
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 is normally
created after the newsletter is sent to the printer! Member CHANGES
on the www.MXG.com homepage are the most timely, as they are updated
(sometimes) between MXG versions.
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 after MXG 14.14 now in MXG 15.15:
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.320 Hardcoded PDB. DDname externalized with &PDBxx macro.
Many 15.354 All VMACs for SMF records start with IF ID=....
Many 15.356 New &MACxxxx macro variable added to all VMACs.
Many 15.170 Support for OS/390 Version 2 Release 4 (COMPAT).
None 15.373 Support for OS/390 Version 2 Release 5 (no changes).
ADOC1415 15.304 Using 14/15 records to determine dataset size.
ADOCTAND 15.119 Cannot use Tandem's ftp program to upload Measure.
AIXPDS 15.337 Support for AIX commands IOSTAT/PSSTAT/VMSTAT.
ANALAVAL 15.262 Availability analysis example with PROC CALENDAR.
ANALBATW 15.378 'Batch Window' graphical reports from PDB.JOBS/STEPS.
ANALCISH 15.365 CICS reports CICNQG, CICSLGS, CICLGR are added.
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.
ANALDB2R 15.223 Some datetimes shifted right two positions, overlay.
ANALDB2R 15.279 APPARENT MACRO &SORTUOW NOT RESOLVED error.
ANALDBTR 15.259 Pairing DB2 IFCID 59 & 63 wrong if multiple 63s.
ANALDBXX 15.173 Merge DB2 102s with DB2ACCT and CICSTRAN example.
ANALDDCN 15.062 Analysis of impact of DDCONS(NO)'s duplicate bytes.
ANALMULT 15.367 Corrected values of EXCPNODD/IOTMNODD for MULTIDD=Y.
ASMIMSLG 15.229 Archaic pre-DFP 3.0 systems retrofit.
ASMRMFV 15.384 Support for RMF Monitor III CPU, PGP, ENC records.
ASMTAPES 15.047 ML-13 of ASMTAPES protects 0C4s, stays up, etc.
ASMTAPES 15.141 ASMTAPES ML-14 populates fields, protects 0C4s.
ASMTAPES 15.285 ML-15 adds dump suppression, OS/390 1.3 JCT changes.
ASMTAPES 15.381 ASMTAPES ML-16 supports four-digit UCBs.
ASMTAPES 15.291 MXG 15.06 did not contain ML-15; MXG 15.07 does.
ASMVVDS 15.302 Out of Storage eliminated, UCBs above 16MB
ASUMTALO 15.077 Exploitation of TALO Interval Records added by ML-12
ASUMTALO 15.301 Starting/Ending Interval counts include SPUN.
ASUMUOW 15.079 IRESPTM, ENDTIME corrected.
ASUMUOW 15.221 Specific reference to TEMP01 caused error, removed.
ASUMUOW 15.307 MROTRAN count included "spun" observation counts.
ASUMUOW 15.315 ASUMUOW option to get real TRANNAME versus CPMI/CSMI.
BUILDPD3 15.020 JES3 BUILDPD3 had extra observations created.
BUILDPD3 15.235 Duplicate step records might not be deleted.
BUILDPDB 15.235 Duplicate step records might not be deleted.
BUILDPDB 15.329 _CDExxxx macros reordered, now inside ELSE DOs.
CICINTRV 15.251 CICINTRV logic corrected, must use this version.
CLMXGSAS 15.084 Sample CLISTs for MXG and SAS execution under TSO.
CONFIG 15.194 MXG default for MEMSIZE raised from 48M to 64M
CONFIG 15.293 YEARCUTOFF=1960 is now MXG default, protects non-Y2K.
DIFFDB2 15.070 DB2STATS values are negative in startup interval.
DIFFDB2 15.278 Variables B1HITRAT-B4HITRAT were wrong.
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.
IHDR110 15.268 CICS Type 110 Header Exit for record selection.
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.
IMACUOW 15.221 SORT output destination, other options externalized.
IMACs 15.328 New _Sxxyyy "PROC SORT" macro defined in IMACs.
INSTALL 15.277 VM/CMS cannot use a MACLIB member for CONFIG option.
NTINTRV 15.255 Multi-processors properly summarized in NTINTRV.
RMFINTRV 15.138 Report RPGNs/Classes can be used in IMACWORK!!!
RMFINTRV 15.238 "ERROR. NEGATIVE CPU OVERHEAD TIME (TYPE70-TYPE72)".
RMFINTRV 15.250 Test CPUTM NE CPU72TM too strong due to truncation.
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.
TYPE102 15.216 DB2 Trace 102 subtype 140 INPUT STATEMENT EXCEEDED.
TYPE102 15.245 DB2 Type 102 Subtype 140 INPUT STATEMENT EXCEEDED.
TYPE102 15.245 Invalid Type 102 subtype 140 protection added.
TYPE103 15.313 Support for ICSS SMF type 103 (Lotus Domino).
TYPE110 15.133 Leap Seconds support correct "GMT" to local.
TYPE110 15.258 APAR UN98309 CICS TS V1.1 INCOMPATIBLE
TYPE110 15.269 UOWTIME duplicate values, UOWIDCHR added to resolve.
TYPE110 15.274 Support for CICS Transaction Server 1.2 INCOMPATIBLE.
TYPE116 15.043 TYPE116 variable QWHCTNO remains numeric.
TYPE116 15.241 MQ Series type 116 blank CICS TASKNR, questions.
TYPE116 15.241 Type 116 INVALID DATA FOR QWHCTASK message
TYPE1415 15.124 Support for APAR OW25263 (for 3590s)
TYPE1415 15.239 New variable LASTVOFL flags if this is Last Volume.
TYPE16 15.243 Support for DFSORT APAR PN71137 (COMPATIBLE).
TYPE16 15.243 Support for DFSORT APAR PN71337 added flag fields.
TYPE26J3 15.228 APAR OW26297 adds job account fields to JES3 type 26.
TYPE26J3 15.273 JES3 ACCOUNT fields in type 26 were not read.
TYPE28 15.336 Support for NPM 2.3 and APAR OW17876.
TYPE28 15.362 NPM type 28 subtype 82 error corrected.
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.
TYPE30 15.227 APAR OW16975 INCOMPATIBLY in error, APPC type 30.
TYPE37 15.385 Support for TME 10 Netview OS/390 1.1 SMF type 37.
TYPE42 15.106 Support for APAR OW20921 creates TYPE42VT (VTOC+).
TYPE42 15.112 Support for APAR OW26451/OW26453/OW26497 MAXRSPTM+.
TYPE42 15.358 TYPE42AU dataset was incorrectly built.
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.
TYPE6156 15.222 INPUT STATEMENT EXCEEDED, Change 15.166 was wrong.
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.
TYPE7072 15.214 TYPE70 PCTMVSBY incorrect MXG 15.01-15.04.
TYPE7072 15.270 OS/390 R2.4 Goal MODE INVALID DATA FOR R723CIDT/CDQT
TYPE70PR 15.299 TYPE70PR had no obs for deactivated partition.
TYPE71 15.064 Variable SLOTUTIL added to TYPE71 - slot usage
TYPE72GO 15.297 VELOCITY variables are now multiplied by 100.
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.
TYPE74 15.226 Support for SMF type 74 CF more than 64 structures.
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.
TYPE80A 15.309 RACF RVARY INPUT STATEMENT EXCEEDED 1.0.9.2 release.
TYPE88 15.257 Support for subtype 11 type 88 System Logger.
TYPE90 15.267 Variable SMFRECNR is now kept.
TYPE91 15.213 Support for SMF type 91 subtype 21 SMARTBATCH data.
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.
TYPE99 15.357 Support for APAR OW29790.
TYPEACF2 15.197 ACF2JR dataset variable ACLFLDVL populated.
TYPEAIMR 15.311 Support for Fujitsu's AIM V20 AIM/RDBII SMF type 98.
TYPEBBMQ 15.263 Support for Boole & Babbage MQ Series VSAM file.
TYPEBETA 15.181 INVALID ARGUMENT in BETA93 SMF record *RELOAD*.
TYPEBETA 15.237 Support for BETA93 Release 3.1 (INCOMPATIBLE).
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.)
TYPECIMS 15.372 Support for Boole's IMF 3.2 (for IMS 6.1) INCOMPAT
TYPECMF 15.187 Variable C279SSI changed from numeric to character.
TYPECMF 15.376 CMF Subtype 15 now creates CMF16MAP & CMF16LPA.
TYPECMF 15.377 CMF Cache dataset CMF27CSC now contains CMF27C93.
TYPECMFV 15.380 Boole & Babbage CMF VSAM History File supported.
TYPECTCP 15.248 Support for Applied Expert Systems Clever TCP/IP.
TYPECTLG 15.166 Support for Catalog Cell 'E7' (Alias).
TYPECTLT 15.276 IOA/Control-T 5.0 variable DSEXPDT changed.
TYPECTLT 15.306 CONTROL-T vars DSUSECT/DSEXCP wrong, undoc bytes.
TYPEDB2 14.095 Support for DB2 Version 5.1.0 (COMPATIBLE).
TYPEDB2 15.133 Leap Seconds support correct "GMT" to local.
TYPEDB2 15.269 UOWTIME duplicate values, UOWIDCHR added to resolve.
TYPEDCOL 15.108 High Used RBA can be greater than Allocated Space.
TYPEDCOL 15.163 Support for DCOLLECT in DFSMS 1.4 (COMPAT).
TYPEDCOL 15.324A VOLSER added to DCOLLECT DCOLCLUS dataset.
TYPEDPPX 15.305 Support for DPPX/370 Performance Reporter output.
TYPEEDGR 15.140 Support for new fields in DFSMSrmm extracts.
TYPEEDGS 15.021 Variables EDGSADTE,EDGSARSD,EDGSASID, formats value.
TYPEEREP 15.246 EREP records past logical EOF were read from DASD.
TYPEFTEK 15.102 Support for Filetek Optical Disk SMF record
TYPEHMF 15.192 Support for HMF SMF Subtype 11 (DS3 Statistics).
TYPEHPTE 15.247 Support for HP MeasureWare for Terra Data OS.
TYPEHURN 15.195 Support for ObjectStar 3.0 (INCOMPATIBLE).
TYPEICE 15.134 Support for IXFP SMF subtypes 6 and 7
TYPEICE 15.215 IXFP subtypes 2,3,4 not output, MXG 15.02-15.04 only.
TYPEIDMJ 15.363 Support for IDMS Journal format for IDMS V12.
TYPEIDMS 15.218 Support for CA's IDMS 14.0 (INCOMPATIBLE).
TYPEIDMS 15.264 IDMS 10.02 observations not output.
TYPEIMFL 15.375 Read IMF + SAP + IBM IMF log records at one time.
TYPEIMSD 15.081 Support for IMS DBCTL transactions from IMS 07/08s.
TYPEM204 15.303 Support for MODEL204 Version 4.1 INCOMPATIBLE.
TYPEMEMO 15.071 Support for MEMO subtype 8, creates MEMODIST dataset
TYPEMIM 15.059 Segments not output after MIMCNT=0 with MIM V 3.
TYPEMON2 15.281 Support for Landmark's The Monitor for CICS/ESA 2.0.
TYPEMWSU 15.068 Revised support for HP's MeasureWare for SUN
TYPEMWTE 15.247 Support for HP MeasureWare for Terra Data OS.
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.
TYPENTSM 15.220 Support for NTSMF Version 2.1 (COMPAT), new objects.
TYPENTSM 15.249 Support for NTSMF Version 2.1 (INCOMPATIBLE).
TYPENTSM 15.265 NTSMF Version 2.0.H caused INPUT STATEMENT EXCEEDED.
TYPEOMVT 15.150 INPUT STATEMENT EXCEEDED Omegamon VTAM 200 IRNUM=12.
TYPEOMVT 15.296 Support for Omegamon for VTAM V400 (COMPATIBLE).
TYPEOPC 15.188 OPC 3.1 datasets OPC23, OPC29, OPC31 corrected.
TYPEOPC 15.256 OPC type 29 INPUT STATEMENT EXCEEDED error.
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.
TYPEQAPM 15.316 Support for OS/400 Release 4.1.0 (INCOMPATIBLE).
TYPERACF 15.103 Support for RACF utility IRRDBU00's OMVS RACF data.
TYPERDS 15.144 Zero observations in TYPERDS1-TYPERDS7 datasets.
TYPERMFV 15.321 Some RMF III VSAM variables were corrected.
TYPERMFV 15.355 CSA and SQA values were wrong; should be &RB.4.
TYPEROSC 15.017 Support for CA-ROSCOE Version 6 SMF is verified.
TYPESARX 15.300 Support for SAR CA-VIEW SMF exit SARSRQUX.
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.
TYPETCP 15.234 Support for TCP/IP 3.2 API Calls record changes.
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.
TYPETMO2 15.353 Landmark TMON for CICS V2 variables renamed.
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.
TYPETMON 15.266 MXG 15.04-MXG 15.05 only. CREATIME, other dates wrong
TYPETMON 15.294 SYSID was length five instead of length four.
TYPETMS5 15.199 Support for CA-1/TMS Release 5.2 (COMPATIBLE).
TYPETMV2 15.346 Landmark for MVS V2 INPUT STATEMENT EXCEEDED.
TYPEVLFC 15.230 Support for VLF Catalog activity from SYSLOG.
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
TYPEZARA 15.323 Packed Decimals protected, DATELU corrected.
UDSKCONT 15.388 Utility to report PC Disk File sizes.
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).
UTILUOW 15.335 CICS MRO - which CICSTRAN record has real TRANNAME.
UVBSNRDW 15.242 Utility to re-create SMF VBS with no RDW/BDWs.
UVBSNRDW 15.242 Utility to recreate VBS from data with no RDW/BDW.
VMAC80A 15.289 RACF DTP EV44xxxx variables added for RACFEVNT=13.
VMACIMSA 15.275 SAP IMS timestamp SAPTIMTR is Start of Transaction.
VMACSTC 15.364 Support for StorageTek's VSM SMF records.
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.
YEAR2000 15.167 MXG now protects ALL date fields for year 2000.
YEAR2000 15.293 MXG cannot protect all non-Y2K-compliant dates.
Inverse chronological list of all Changes:
NEXTCHANGE: Version 15
======Changes thru 15.391 were in MXG 15.15 dated Feb 23, 1998======
Change 15.391 Zero observations in MIMTAPE dataset, because somewhere
VMACMIM along the way, the variable MIMCNT, which used to be the
Feb 20, 1998 sample count, is now zero in the MIM SMF record. MXG had
heuristically only invoked the EXTYMIM exit if the record
had "samples" but now no observations were created. The
two DO groups around the %INCLUDE SOURCLIB(EXTYMIM); that
tested MIMCNT GT 0 were eliminated, so all MIM segments
will be output.
Thanks to Joseph Montana, Acxiom, USA.
Change 15.390 Three variables in these two members still had DATE7 as
ANALDB2P their format, but are now changed to DATE9 so that all
ASUMIDMS four digits of year will be displayed.
Feb 20, 1998
Thanks to Pete Gain, SAS UK, ENGLAND.
Change 15.389 Reading type 42 records directly from the SMF VSAM file
VMAC42 caused INPUT STATEMENT EXCEEDED because some of the new
Feb 20, 1998 subtypes did not have "+OFFSMF" added when their offsets
were calculated. The code worked fine with dumped SMF
Thanks to Ken Williams, Sun Life of Canada, ENGLAND.
Change 15.388 New utility program that reports PC Disk File sizes and
UDSKCONT disk space required by directory and high-level directory
Feb 20, 1998 names. To use, from the root directory, you issue:
DIR *.* /S >> C:\DISKFARM
which creates the listing of all files in "DISKFARM",
and then, under SAS, you issue:
%UDSKCONT
and the reports will show the total disk space required
(assuming 32K worst-case cluster size for FAT) and the
file bytes in each directory, and then a summary report
shows filesize and space required by highlevel dir name.
Change 15.387 Support for TME 10 Netview for OS/390 1.1 SMF type 39
VMAC39 will not fail with the new records, but there are two
Feb 18, 1998 segments (accounting and availability data section and
APPN route data section) that are added to the existing
subtypes, and there are two new subtypes:
007 - Init Failure Record
008 - Storage and Event Counter Record
If you have these records, see member SENDDATA and email
me a few hour's worth so I can validate the enhancement.
Change 15.386 Support for TME 10 Netview for OS/390 1.1 SMF type 38
VMAC38 is NOT included in MXG; the type 38 record was completely
Feb 18, 1998 restructured and I need test data records to enhance it.
There are now three subtypes that now exist in type 38:
001 - Command Authorization Table
002 - Task Resource Utilization Table
003 - Span Authorization Table
First glance shows lots of interesting fields. If you
have type 38's from Version 1.1, see member SENDDATA and
email me a few hours worth, and I can enhance MXG with
these three new datasets.
Change 15.385 Support for TME 10 Netview for OS/390 1.1 SMF type 37
VMAC37 record IS already included in MXG, as there were no
Feb 18, 1998 changes to the type 37 record, although the table numbers
were changed in documentation: "TME 10 Netview for OS/390
Application Progrmmer's Guide Version 1 Release 1, pub
number SC31-8223-00 (but don't look for that order number
on the publication itself; only on the Readers Comment
Form could I find the pub number!). IBM saves ink???
That publication documents SMF 37, 38, and 39 records.
======Changes thru 15.384 were in MXG 15.09 dated Feb 17, 1998======
Change 15.384 Support for RMF Monitor III VSAM file adds support for
ASMRMFV new record types of CPU, PGP, and ENC, but I have not had
ASMRMFVX test data (ASMRMFV, when assembled, converts the RMF III
Feb 17, 1998 compressed files into flat records for TYPERMFV to read),
so output records from ASMRMFV with CPU, PGP, or ENC
enabled needs to be verified with TYPERMFV. In addition,
the support for the CSR records cannot be finished until
we can get a hex dump of the ASMRMFV program when it
tries to read a CSR record. We have created a special
version of ASMRMFV, named ASMRMFVX, that will Abend S0C3
when it tries to read a CSR record; if you have those
enabled and can generate the S0C3 Abend Dump, please send
it (tape or printed) to Merrill Consultants so we can
decode that RMF III record as well.
Change 15.383 MXG 15.09 only. Comma missing at end of INCODE= caused
TRNDRMFI error. This was caught in my QA test, but I failed to
Feb 17, 1998 copy the change from the QA library back into the master!
====Changes thru 15.382 were printed in MXG Newsletter THIRTY-THREE====
Change 15.382 NPM variables STARTIME, ENDTIME, and DURATM had missing
VMAC28 value in dataset NPMINRTM from SMF type 28 subtype '30'x.
Feb 16, 1998 Valid STARTIME and ENDTIME were INPUT in the STT section
processing, but the SAA section also INPUT STARTIME and
ENDTIME, and when there were no timestamps in the SAA
section, their missing value overrode the valid STT
values. To correct, the calculation of STARTIME and
ENDTIME in the AOFTYPE='SAA' section is performed by
IF STARTIME=. THEN DO; and IF ENDTIME=. THEN DO;
logic so that valid STARTIME/ENDTIME will be preserved.
Thanks to ???, Spar Handels AG, GERMANY.
Change 15.381 ASMTAPES Maintenance Level ML-16 now writes records for
ASMTAPES devices with four-digit UCBs. (We thought we had added
ZSMTAPES that support long ago, but testing uncovered our error.)
Feb 17, 1998 In addition, ML-16 corrects the "TEST" SYSPARM which did
not work as advertized. Note that "TEST" (which writes
to a flat file instead of SMF), does not support the WLM
(Workload Manager Fields) that ARE supported in non-TEST.
Thanks to Mark Schmitt, First Card, USA.
Change 15.380 Major enhancement to support for Boole & Babbage CMF
EXCMFVAL VSAM History File. MXG Previously decoded a dozen or
EXCMFVCD so subtypes, but this massive user contribution added
EXCMFVCF fourteen completely new datasets and their exits, and
EXCMFVCS creates variables in ten existing datasets that were only
EXCMFVDC a skeleton dataset before this change.
EXCMFVDV
EXCMFVGL The bulk of this change was written by
EXCMFVHD Pino Todesco, Boole and Babbage, Australia.
EXCMFVMP
EXCMFVMS This text will be updated with correct name, etc.
EXCMFVMV
EXCMFVRV As test data is received from interested sites for the
EXCMFVSO subtypes not yet decoded, MXG will be enhanced to also
EXCMFVST support those subtypes.
VMACCMFV
Feb 15, 1998 This is also called "Mainview" by Boole.
Thanks to Pino Todesco,Boole & Babbage, AUSTRALIA.
Change 15.379 Two new reports for "Batch Window" analysis, one based on
ANALBATW PDB.STEPS as input, and the second based on PDB.JOBS were
Feb 15, 1998 written by Grant and contributed by Ken.
Thanks to Grant Mackay, Standard Life, SCOTLAND
Thanks to Ken Williams, Southern Electric, UK.
Change 15.378 Some simple reports of Data Set activity based on the SMF
ANAL42 type 42 record's dataset TYPE42DS were contributed by
Feb 15, 1998 Ken from a previous lifetime.
Thanks to Ken Williams, Standard Life, SCOTLAND.
Change 15.377 Boole's CMF Cache Stats were split into two CMF datasets
VMACCMF CMF27CSC and CMF27C93, but there were no merge variables
Feb 15, 1998 with which to combine them, so the internal logic was
redesigned, so now the CMF27CSC dataset contains both
sets of variables. The CMF27C93 dataset is still built as
before (so your old reports won't fail), but you should
now use CMF27CSC for Cache reporting (and you can then
use your EXCMFC93 exit member to turn of creation of obs
in the now-archaic CMF27C93 dataset. Use CMF27CSC!
Thanks to Neil Ervin, Banc One Services Corporation, USA.
Change 15.376 Boole CMF subtype 16 record now creates two new datasets
EXCMF15M CMF16MAP (Virtual Storage Map) & CMF16LPA (LPA Modules)
EXDMF15L thanks to this significant user contribution.
VMACCMF
Thanks to Paul Hill, Midland Bank, UK.
Change 15.375 IMS Log records from Boole's IMF and from SAP and IBM's
TYPECIMS IMS log records can now be processed in one pass of the
TYPEIMFL IMS log. Member VMACIMS had internal variable MSGDRRN
VMACCIMS (a numeric variable) replaced by CMSGDRRN (a character)
VMACIMS to avoid conflict between CIMS and IMS member, and some
Feb 13, 1998 lines were relocated in both VMACCIMS and VMACIMS, and
macro _IMS in member VMACIMS now creates the variables in
the header that VMACCIMS expected, and new macro _CHAIN
is defined in member VMACCIMS, replacing the inline code
that handled Chained Transactions in member TYPECIMS, so
the end result is that new member TYPEIMFL contains:
%INCLUDE SOURCLIB(VMACCIMS,VMACIMS);
DATA _VARCIMS _VARIMS ;
_IMS ; _CDECIMS _CDEIMS ; _CHAIN ;
so TYPEIMFL creates all 25 datasets from IMF, IMS, and
SAP's IMS log records in one pass of the IMSLOG tape:
CIMSTRAN CIMSDBDS CIMSDB2 CIMSPROG
IMS01 IMS01M IMS03 IMS03P IMS07 IMS08
IMS31I IMS31O IMS35I IMS35M IMS35O IMS35P
IMS36 IMS36M IMS5901 IMS5903 IMS5936 IMS5937
IMS5938A
SAPIMSBA SAPIMSON SAPIMSSP
And if you don't want to create all 25 datasets, you can
use MXG's new &MACxxxx macro variable (Change 15.356) to
redefine the _Lxxxxx dataset macros to _NULL_ for the
unwanted data sets, and they won't be created:
%LET MACIMS=
MACRO _LIMS01 _NULL_ % MACRO _LIMS01M _NULL_ %
MACRO _LIMS03 _NULL_ % MACRO _LIMS03P _NULL_ %
MACRO _LIMS07 _NULL_ % MACRO _LIMS08 _NULL_ %
MACRO _LIMS31I _NULL_ % MACRO _LIMS31O _NULL_ %
MACRO _LIMS35I _NULL_ % MACRO _LIMS35M _NULL_ %
MACRO _LIMS35O _NULL_ % MACRO _LIMS35P _NULL_ %
MACRO _LIMS36 _NULL_ % MACRO _LIMS36M _NULL_ %
MACRO _LIMS591 _NULL_ % MACRO _LIMS593 _NULL_ %
MACRO _LIMS596 _NULL_ % MACRO _LIMS597 _NULL_ %
MACRO _LIMS598 _NULL_ %
;
%INCLUDE SOURCLIB(TYPEIMFL);
would only create the 4 IMF and the 3 SAP datasets.
Thanks to Reinhard Kelm, GRZ, GERMANY.
Thanks to Friedhelm Danne, GRZ, GERMANY.
Change 15.374 There was no KEEPs example that worked with ASUMUOW, but
IMACCICS comments implied there was. Now the three examples show
Feb 12, 1998 the KEEPs for CICSTRAN that are required for ASUMCICS,
ASUMCICX, and ASUMUOW. The actual KEEPs examples use
the DROP= statement in the _K macro to control keeping.
Thanks to Tom Weiland, Phoenix Home Life Mutual Insurance Co, USA.
Change 15.373 Support for OS/390 Version 2 Release 5 is contained in
none MXG 15.04 or later, as there were no changes to the SMF
Feb 12, 1998 records between OS/390 2.4 and OS/390 25., and MXG Change
15.270 added support for Version 2 Release 4 in 15.04.
Change 15.372 Support for Boole's IMF 3.2 (for IMS 6.1) INCOMPATIBLE
VMACCIMS because 400 bytes were inserted at the end of the fixed
Feb 12, 1998 portion of the record, causing DBD counts to be wrong
without this change. The 400 bytes added only four new
fields: GMT Adjustment, UTCA, Checkpoints/Syncpoints
CTCKPNTS, Maximum Locks Held MAXLOCKS and Total Locks
Held, TOTLOCKS.
Thanks to Reinhard Kelm, GRZ, GERMANY.
Thanks to Friedhelm Danne, GRZ, GERMANY.
Change 15.371 The new BLDNTPDB macro provides simple daily/weekly/
BLDNTPDB monthly dataset building and reporting from NTSMF data
Feb 12, 1998 records. This macro does everything for you, or you
can override its options. It even supports reruns!
Especially for new users who are not familiar with the
PDB architecture, this runs-only-on-ASCII-SAS example
should make life simple. More documentation on how to
use this facility will be forthcoming, and this is still
in development.
Thanks to Marti Henley, Matridigm, USA.
Thanks to Chuck Hopf, MBNA, USA.
Change 15.370 Concurrency analysis routine ANALCNCR has new MYTIME=
ANALCNCR argument for sites that want to specify a non-standard
Feb 12, 1998 time period for summarization. (Note: the MYTIME=
specification is not used to "sync" the intervals, and
SYNCINTV=YES is ignored if INTERVAL=MYTIME is used.
Thanks to Tom Parker, CSC FSG Banking Division, USA.
Change 15.369 Trending for the ASUMUOW using the PDB.ASUMUOW dataset
TRNDUOW daily as input, rather than building ASUMUOW weekly, is
Feb 12, 1998 recommended for sites that need to analyze CICS MRO with
or without DB2 by UOWID, i.e., by Unit of Work ID, due
to potential large volumes of data, CPU time, work space
and I/O operations if the trending were done from the
weekly PDB.
Thanks to Chuck Hopf, MBNA, USA.
Change 15.368 New argument DURATM=INTERVAL will cause variable DURATM
ASUMCICS to be created in VMXGSUM's output dataset, and DURATM
ASUMDB2A will contain the duration specified on INTERVAL (for the
ASUMDB2B "real" durations of QTRHOUR, HALFHOUR,HOUR, and DATE), to
ASUMHSM be consistent with MXG design intentions of having DURATM
ASUMJOBS in all interval datasets. The eight ASUMxxxx members
ASUMPRTR listed are the first to exploit this new DURATM=INTERVAL
ASUMTMNT argument for VMXGSUM. In addition, both VMXGSUM and
VMXGDUR VMXGDUR now contain new argument MXGWEEK= that allows
VMXGSUM you to change your "first day of the week" in Trending
Feb 12, 1998 datasets from MXG's default of MONday.
Thanks to Chris Weston, SAS ITSV Cary, USA.
Change 15.367 The EXCPNODD and EXCPTODD counts in step and job records
ANALMULT with MULTIDD='Y' (i.e., there were so many DD segments
Feb 12, 1998 that MVS created multiple type 30 records for a step)
are incorrect, because they are created for each step
record and are not summed across all of the multiple
records. Since these MULTIDD='Y' jobs are almost always
data center work (like SAR/RMDS/etc spoolers) the error
has not had any real effect, but this user has provided
a series of macros that will start with the raw SMF data
and correctly calculate EXCPNODD and EXCPTODD for these
MULTIDD='Y' tasks. Because it must sort lots of records,
and takes appreciable CPU and IO resources, I have no
plans to add the logic to BUILDPDB, but it is here if
you need it!
Thanks to Dr. Alexander Raeder, Karstadt, GERMANY.
Change 15.366 Member ANALUOW as announced in Change 15.205, but it did
ANALUOW not get copied into the MXG library until MXG 15.09, and
Feb 12, 1998 it was cleaned up and enhanced now as well.
Thanks to Chuck Hopf, MBNA, USA.
Change 15.365 CICS DFHSTUP "Shutdown" reports CICNQG, CICLGS, and
ANALCISH CICLGR have been added to member ANALCISH.
Feb 20, 1998
Thanks to Bruce Widlund, Merrill Consultants, USA.
Change 15.364 Support for StorageTek VSM SMF records adds 17 new data
EXSTCV09- sets for HSC subtypes 09 thru 26. The datasets are
EXSTCV25 named STCVSM09 thru STCVSM26 and they provide significant
VMACSTC measurements, including bytes read/written, duration of
Feb 12, 1998 mount, dismount, recall, migrate, etc., etc., etc!
Feb 20, 1998 The code has been syntax checked and subtypes 13, 14, 15
and 21 records have been processed.
Change 15.363 IDMS Journal Format Performance Records were apparently
TYPEIDMJ changed in IDMS Version 12, and the old Journal support
VMACIDMJ failed. This revision heuristically skips over the non
Feb 11, 1998 performance segments and has been tested with real data.
Unfortunately, the quick solution was to create VMACIDMJ
that knows about the idiosyncrasies of the Journal data,
but this means dual maintenance in VMACIDMS/VMACIDMJ with
each new version of IDMS!
Thanks to Alfred Mueller, ABN-AMRO Services Co., USA.
Change 15.362 NPM type 28 subtype 82 caused INPUT STATEMENT EXCEEDED
VMAC28 because 36 bytes were input when there were only 24. The
Feb 10, 1998 statement ELSE IF LENAOF GE 172 AND NPMSUBTYP NE 83X
THEN INPUT +36 @;
must be changed to ELSE .... THEN INPUT +24 @;
Thanks to Mel Hitchings, British Telecom, WALES.
Change 15.361 Creation of the WKnnPCPU, WKnnPPRV, and WKnnPUSR percent
NTINTRV values in the NTINTRV dataset was revised to convert the
Feb 10, 1998 percentages to durations, sum the durations, and recalc
the percentage values. If the DURATM of all PROCESS
intervals is the same, the new and old calculations are
identical, but the old calculations were wrong if there
were dissimilar values of DURATM in the PROCESS dataset.
Thanks to Wayne Holzback, Reynolds Metal Company, USA.
Change 15.360 Variable OTHRPUSR was not in the RETAIN list in member
NTINTRV NTINTRV, causing that variable to be missing from the
Feb 10, 1998 NTINTRV dataset.
Thanks to Marti Henley, Matridigm Corporation, USA.
Change 15.359 DCOLLECT variables DDCXSYS and DDCXREG were reversed in
VMACDCOL the input statement; DDCXSYS should have been first and
Feb 10, 1998 then DDCXREG second, as it was in DCOLLECT 1.2. In 1.3
the documentation reversed the order, but tests with
data confirm the real order is XSYS and then XREG.
Thanks to Mike Blocker, Fidelity Investments, USA.
Change 15.358 The TYPE42AU (Audit ACTIVATE, ENF, or VARY SMS events)
VMAC42 was not input correctly, but the record is also wrong!
Feb 10, 1998 MXG errors: insert +16 between INPUT and SMF42ETY.
change +72 to +88 before SMF42ESD.
IBM error: there are only 31 total bytes between SMF42ETY
and SMF42EVL, instead of the 32 documented.
I changed the +22 after SMF42ENM to +21 while
we sort out IBM's error.
Thanks to Michael E. Friske, Fidelity Investments, USA.
Change 15.357 Support for APAR OW29790 adds variables PGOALPCT and
VMAC99 SERVER01-SERVER05 and SERVPN01-SERVPN05 to the TYPE99_6
Feb 10, 1998 dataset to track service classes served.
Change 15.356 This enhancement adds a &MACxxxx macro variable in each
many VMACxxxx member so that you can dynamically override the
VMXGINIT IMACxxxx member without having to EDIT and save an IMAC!
Feb 8, 1998 In each VMACxxxx member, a new line with "&MACxxxx;" was
added immediately after the %INCLUDE SOURCLIB(IMACxxxx).
For example, in member VMACHSM, the statements are:
%INCLUDE SOURCLIB(IMACHSM);
&MACHSM;
Each of the &MACxxxx macro variables are initialized to
a null string, and GLOBALed, in member VMXGINIT.
So in your program, you can set the value of the &MACxxxx
macro variable equal to the old-style macro definition
syntax ("MACRO macro-name macro-text %" to thus change
the definition of the _L,_K dataset tailoring macros:
MACRO _Lxxxxxx - tailor Libref and Dataset Name
MACRO _Kxxxxxx - tailor KEEP/DROP list of vars
or to change the new _S PROC SORT macro added in 15.328:
MACRO _Sxxxxxx - PROC SORT and BY statements
or in a future version, change the planned _E Exit macro:
MACRO _Exxxxxx - will allow you to override the
%INC SOURCLIB(EXxxxxxx) exit.
and thus have complete dynamically tailoring for each
individual dataset. For example, for SMF 30, you could:
%LET MAC30=
MACRO _LTY30U1 _NULL_ %
MACRO _LTY30U4 MYDD.TYPE30_4 %
MACRO _LTY30U5 _NULL_ %
MACRO _LTY30UV _NULL_ %
MACRO _LTY30UD _NULL_ %
MACRO _LTY30U6 _NULL_ %
MACRO _LTY30MU _NULL_ %
MACRO _LTY30OM _NULL_ %
;
%INCLUDE SOURCLIB(TYPE30);
to create only the dataset TYPE30_4 from the subtype
4 record, and it would be written to the //MYDD library.
For a User-SMF record, where you must set the SMF record
ID in the MACRO _IDxxxx in the IMACxxxx for the product,
you can now redefine the _ID macro with the &MACxxxx.
For example, to process the HSM User SMF record and put
all HSM datasets in the //WORK library, you could use:
%LET MACHSM=
MACRO _IDHSMDS 240 %
;
%INCLUDE SOURCLIB(TYPEHSM);
For those not familiar with the syntax of the %LET, you
use %LET MACxxx= before the old-style macro statements
and then you end the %LET statement with a semi-colon.
If the text contains semi-colons, you can instead use
%LET MACxxx= %QUOTE( whatever-with-semicolons) ;
For those not familiar with the syntax of the old-style
MACRO statement, it is simply
MACRO macro-name macro-text
and then a single percent-sign ends the definition.
If the macro text has a percent-sign, then double it:
MACRO _EXXXXXX %%INCLUDE SOURCLIB(EXYYYY); %
This new &MACxxxx architecture is a significant piece of
the complete redesign to allow external control of all
MXG datasets. Because the &MACxxxx enhancement is safe
and can be used to override existing IMAC definitions, it
is added in MXG 15.09. The remaining pieces of this big
change will be implemented after MXG 15.15 has shipped!
Change 15.355 Variables ASICSAA, ASISQAA, ASIECSAA and ASIESQAA were
VMACRMFV horifically large, because they should have been read in
Feb 5, 1998 with &RB.4. informat instead of &PIB.4.
Thanks to Peggy Dunne, Depository Trust Company, USA.
Change 15.354 All VMACs that process SMF records were made consistent,
VMACs by locating the "IF ID = ..." statement immediately after
BUILD606 the MACRO _CDExxxx statement. All new VMACs have been
BUIL3606 written that way, but some old VMACs had LABEL statements
Feb 5, 1998 between the macro definition and the IF test. Now that
the _CDExxxx macros for SMF records all start with the IF
test for record IDs, the efficiency improvements of MXG
Change 15.329 are revised again. Instead of the logic
ELSE IF ID=xx THEN DO;
_CDExxxx
END;
now, the logic
ELSE _CDExxxx
can be used, eliminating the extra test imposed by the
external IF statement.
The VMACs whose IF statement was relocated are:
VMAC25 VMAC7072 VMAC71 VMAC73 VMAC74 VMAC75 VMAC76
VMAC77 VMAC78 VMACCTCP VMACEDGS VMACF127 VMACFTEK
VMACHSM VMACODS VMACSYNC VMACTSOM
Thanks to Chuck Hopf, MBNA, USA.
Change 15.353 Support for Landmark's TMON for CICS Version 2 (MXG1506)
VMACTMO2 conflicted with ITSV because some variables were changed
Feb 5, 1998 incorrectly by MXG, and some variables were not created.
Variable MONIMANT is now created, variable TATASKNN is
re-spelled TATASKNR, variable CICSLV is renamed to be
CICSLEV (Landmark changed it from PIB1 to $CHAR4 so I
had no choice), and variable FACTYP is changed back to
PIB1 and formatted as it was in prior versions.
Thanks to Rod Gaas, Eagle Star, UK.
Change 15.352 MXG 15.08. The label for variable S1ELEMLO was typed as
VMAC110 S1ELEMLO='LOWEST*FREE*ELEMENTS*='/ but SAS did not die
Feb 4, 1998 or produce an error message! The extraneous characters
are now removed. Also, macro _CICSTCMN was added to the
KEEP= list for dataset CICSSMED so the common variables
(in particular, SYSTEM and SMFTIME) will now be kept.
Thanks to Chris Weston, SAS ITSV, USA>
Change 15.351 Cosmetic. Variable LCSLOV1 label should have been
VMAC28 'OVERFLOW*FLAG*BYTE'.
Feb 4, 1998
Thanks to Ley Teng, QANTAS, AUSTRALIA.
Change 15.350 The explicit dataset names TYPE72 and TYPE6 were replaced
ASUMPRTR with _LTY72 and _LTY6 macro names instead, so that if you
Jan 31, 1998 re-direct either dataset from the default of "WORK", MXG
will find it where you put it.
Thanks to Chris Weston, SAS ITSV, USA.
Change 15.349 The example "reptprod" file to control fields extracted
ADOCMWAI from HP's MeasureWare for AIX is now provided in the
Jan 28, 1998 ADOCMWAI member.
Thanks to Lorenzo Wright, NCCI, USA.
Thanks to Thierry Van Moer, Comparex, BELGIUM.
Change 15.348 Member VMACTRNS was a copy of VMACTRSN that had been
VMACTRNS saved under the incorrect VMACTRNS name, so the member
Jan 27, 1998 VMACTRNS has been deleted.
Thanks to Dr. Alexander Raeder, Karstadt AG, GERMANY.
Change 15.347 The VMXGFOR references in the commented out example that
RMFINTRV can be used to read SMF directly must all be %VMXGFOR.
Jan 27, 1998 Only if you remove the comment block to read SMF direct
would you see this error.
Thanks to Jim Chappell, Pacific Power and Light, USA.
Change 15.346 Support for Landmark for MVS Version 2 segments that were
VMACTMV2 not available for testing in MXG 15.08. New segments
Jan 26, 1998 that have now been data-validated are: JD, LM, and TR.
These record subtypes caused INPUT STATEMENT EXCEEDED.
Thanks to Jonathan McVey, Lowe's Company, USA.
Thanks to Mark Derreks, Hershey's, USA.
Change 15.345 MXG 15.08 only. The new MACRO _SCICEXC should have had
IMACCICS &PDB..CICSEXCE instead of &PDB.CICSEXEC. Fortunately,
Jan 20, 1998 the new macro is not (yet!) used in MXG code, so there
was no execution error.
Thanks to Freddie Arie, Lone Star Gas, USA.
Change 15.344 Variable NTVERSP was truncated to 12 positions, so it
VMACNTSM had only "Service Pack" instead of "Service Pack 3".
Jan 20, 1998 Move the NTVERSP in the line with $12 to the next line,
with $32, so it will be 32-bytes long.
Thanks to Marty Henley, Matridigm, USA.
Change 15.343 MXG 15.08 only, JES2 only. Change 15.329 reordered the
BUILD606 _CDE macros for performance, but putting _CDE30 ahead of
Jan 20, 1998 _CDE26J2 caused variable JOBCLASS to be 8 bytes instead
of 1 byte. (JES2 has a one byte JOBCLASS, JES3 has three
bytes kept, but the variable is input at $EBCDIC8 in the
type 30 logic.) By placing the _CDE26J2 processing prior
to the _CDE30 processing for the JES2 BUILDPDB, the
JOBCLASS variable will be 1 byte in JES2 and 8 in JES3.
Thanks to Tom Parker, CSC Hogan Systems, USA.
Change 15.342 MXG 15.08 only. Change 15.330 was not correct, causing
VMAC26J2 type 26 ACCOUNTn fields to be not input. The test
Jan 20, 1998 (SMF26OAG+SMF26LAG-1 LE LENGTH) should have been
(SMF26OAG+SMF26LAG-4 LE LENGTH).
Thanks to Tom Parker, CSC Hogan Systems, USA.
Change 15.341 Support for 'DD'x NPM record did not input the VCD data.
VMAC28 Change the test that sets COFTYPE='VCD' to read:
Jan 19, 1998 ELSE IF 0D0X LE NPMSUBTY LE 0DBX OR
NPMSUBTY EQ 0DDX THEN COFTYPE='VCD';
Thanks to Mel Hitchings, British Telecom, WALES.
======Changes thru 15.340 were in MXG 15.08 dated Jan 15, 1998======
Change 15.340 Cosmetic. Extra variables were kept in NPMINFRP because
VMAC28 the KEEP= list contained _VA28ACD, but that should have
Jan 15, 1998 been _VA28NCD, which is the shorter configuration record
that is in NPMINFRP. Variable names that were misspelled
are corrected: LFRPOBOL is LFRPOBQL, LXLKTSLP/LXLKRSLP is
LXLKTLSP/LXLKRLSP and LXPUTSLP/LXPURSLP is ....TLSP/RLSP.
Thanks to Ley Teng, QANTAS, AUSTRALIA.
Change 15.339 The first MXG 15.08 tapes dated Jan 14, 1998 contained an
UTILUOW error: the member UTILUOW was added at the last minute,
Jan 15, 1998 and I failed to change its "./" IEBUPDTE control cards
to "XY", so when IEBUPDTE read the tape to create your
source library, those "./" cards in UTILUOW overwrote
all of the (previously unloaded successfully!) EXCICxxx
members. Replacement tapes with Jan 15, 1998 date (and
with XY vice ./) were shipped to the 23 sites getting the
bad tape, but you could copy the tape and delete lines
864,653 thru 865,135 inclusive, and then use that copy as
input to IEBUPDTE.
Thanks to Freddie Arie, Texas Utilities, USA.
======Changes thru 15.338 were in MXG 15.08 dated Jan 14, 1998======
Change 15.338 Further cleanup and enhancements to eliminate unneeded
ANALCISH datasets (the INT, EOD, USS, RRT, and REQ datasets are
Jan 14, 1998 not used by any ANALCISH report, so they are no longer
created when PDB=SMF is specified, for example). You
can select from more than one PDB library for input with
the PDB=TUE WED THU, syntax, and handling of the many
WORK.TRANSxx merges was revised.
Thanks to Bruce Widlund, Merrill Consultants, USA.
Change 15.337 Support for AIX commands IOSTAT, PSSTAT and VMSTAT
AIXPDS has been revised and enhanced from the original unix
Jan 14, 1998 examples in member VMACRSxx. Those members and new
ones, including JCL examples for FTPing the unix data
to MVS, are provided in this find enhancement authored
and contributed by Joe. See the comments to expand the
member into a separate MXG.RX6000.SOURCLIB library.
Using the unix commands to measure unix performance is
marginal at best, but if you do not have a monitor
product for unix, you can get useful information by
running the PSSTAT, IOSTAT and/or VMSTAT commands and
using this code to turn them into MXG datasets.
Thanks to Joseph Faska, Depository Trust Company, USA.
Change 15.336 Support for NPM APAR OW17876 and NPM Version 2.3 added
EX028VTT variables to the CSL, FRP, GBL, TRI, VCD, VEN, VGB, and
IMAC28 VVR segments, and new dataset NPMVSVTT is created from
VMAC28 from new subtype 'DD'x record. Many new variables
Jan 14, 1998 provide HPR counts (frames/bytes sent/rcv/discarded).
These changes were COMPATIBLY made by IBM, so earlier
versions of MXG will not fail with NPM 2.3 records, but
this change is required to capture the new fields.
Thanks to Melanie Hitchings, British Telecommunications, WALES.
Change 15.335 Utility to examine CICSTRAN observations from MRO CICS
UTILUOW to determine which transaction record contains the real
Jan 13, 1998 transaction name for each unit-of-work. With the output
of UTILUOW, you can edit IMACUOW to tell MXG which name
to keep, so that dataset ASUMUOW will have the "correct"
TRANNAME name for the UOW. Read the member's comments.
Thanks to Chuck Hopf, MBNA, USA.
Change 15.334 Cosmetic. Temporary dataset KEEPERS was not deleted when
VMXGSUM there were no observations in the input dataset, but now
Jan 13, 1998 it is always deleted.
Thanks to Chuck Hopf, MBNA, USA.
Change 15.333 Support for type 79 subtype 15 (IMS Long Lock) record has
EXTY79F only been visually tested, as no IMS site has sent any
IMAC79 test data. For each Long Lock, you get the IRLM lock
VMAC79 structure name and Lock Name, as well as identity of the
Jan 11, 1998 IMS subsystem and even CICS task name (if CICS).
Change 15.332 All ADOC members have been updated to list all variables
ADOCx as of MXG 15.07; this is the output of an extensive piece
Jan 9, 1998 of work by Freddie that merge new variables and datasets
into the existing ADOC members, while preserving the text
descriptions, tutorials, discussions, and the sample PROC
PRINT and MEANS output. This iteration makes all of the
ADOCs conform to the format described in ADOCxxxx, so
that this process can be fully automated and will soon be
an automated part of the MXG QA jobstream.
Thanks to Freddie Arie, Lone Star Gas, USA.
Change 15.331 OMEGAMON FOR VTAM 400, Change 15.296 was not complete,
VMACOMVT amd caused MXG to loop on an INPUT statement. All byte
Jan 9, 1998 related variables are now formatted with MGBYTES. MXG
now creates new interval rate, or "Per Sec", variables
for each pair of ACCUM/PREVIOUS counters. These new
variables, suffixed with R, should be most useful.
The ACCUM/PREVIOUS counters could be dropped if space
becomes an issue. However, the OMVTMPCS pair ON08BCT
and ON08BCTP for one interval produced a negative value
for the "Per Sec" value, ON08PCTR, because the ACCUM of
104,425 was less than the PREVIOUS of 108840! This will
be investigated with Candle.
Thanks to Joseph E. Darvish, Farmers Insurance Group, USA.
Thanks to Robert S. Miller, Farmers Insurance Group, USA.
Change 15.330 APAR OW28613 corrects an error in SMF26OAG; without the
VMAC26J2 APAR, MXG had INPUT STATEMENT EXCEEDED error condition.
Jan 8, 1998 To circumvent the error until you get the APAR installed
change the test of SMF26OAG to read as follows:
IF SMF26OAG GT 0 AND SMF26LAG GT 0 AND SMF26NAG GT 0
AND (SMF26OAG+SMF26LAG-1 LE LENGTH) THEN DO;
(The bad record I saw has LENGTH=417 but SMF26OAG=439!)
Only variables ACCOUNTn in dataset TYPE26J2 (which are
new additions) are affected by the error, and the will be
blank until you install the APAR. Furthermore, MXG uses
the type 30 ACCOUNTn fields in BUILDPDB normally, and
will use the new type 26 fields only for job's with JCL
errors that did not execute.
Thanks to Diane Eppestine, Southwestern Bell, USA.
Change 15.329 The BUILDPDB logic for the SMF processing phase is now
BUILDPDB more efficient, as the _CDExxxx macros are reordered to
BUILDPD3 process the most frequent records first (the order is
BUILD606 110, 30, 74, 100-101 and then the rest), and the _CDExxxx
BUIL3606 macros are now inside ELSE IF ID= xxx then DO; blocks.
BUILD001 This will result in significant reductions in CPU time!
EXTYID Also, the ID dataset that was hardcoded in BUILPDx code
IMACID has been externalized so it can be tailored to contain
TYPEID additional variables (in IMACID's _KTYID macro) or can
VMACID contain zero observations (by commenting out the OUTPUT
Jan 7, 1998 statement in member EXTYID). See Change 15.354, which
redesigned this change for more efficiency.
Change 15.328 New macros _Sxxyyyy are defined in IMACs that will let
IMACs you sort individual datasets exactly as that dataset is
Jan 7, 1998 sorted into the PDB library in BUILDPDB/BUILDPD3. The
_Sxxyyyy name matches the _L, _K macro names and the
EXxxyyyy exit member naming conventions. The sort macro
is needed by sites that have so much SMF data that they
have to split their SMF data into parallel SMF files. An
example of their use would be for a site that split their
type 74 RMF records to a separate SMF file. To create
the TYPE74 and TYPE74CA datasets into separate SAS data
libraries they could now use:
//SMF DD DSN=SMF.TYPE74.ONLY,DISP=SHR
//TYPE74 DD DSN=YOUR.TYPE74.PDB,DISP=NEW
//TYPE74CA DD DSN=YOUR.TYPE74CA.PDB,DISP=NEW
%INCLUDE SOURCLIB(TYPE74);
%LET PDB74=TYPE74;
_STY74
%LET PDB74CA=TYPE74CA;
_STY74CA
The _STY74 macro definition (in member IMAC74) is:
MACRO _STY74
PROC SORT NODUP DATA=_LTY74
OUT=&PDB74..TYPE74 ;
BY SYSTEM STARTIME DEVNR SMFTIME;
%
so it uses the _LTY74 name to get the location of the
unsorted TYPE74 dataset, and sorts it into the new
&PDB74 macro for the DDname that was just added by
Change 15.320.
(The %VMXGFOR macro, needed so that PROC SORT's FORCE
option is used so that you can SORT when OBS= is not
OBS=MAX, has double percent signs because it is inside
an old-style MACRO definition).
A later MXG Technical note will discuss other examples.
Only those IMACs for products that are in the default
BUILDPDB/BUILDPD3 now have _Sxxxyyy macros, but over time
I hope to provide an _S macro with the MXG "recommended"
sort order for every MXG dataset. At the present time,
none of the _S macros are used in the BUILxxxx members.
Thanks to Billy Westland, Litton Computer Services, USA.
Change 15.327 APAR OW28921 adds a volume segment to type 42 subtype 11
VMAC42 XRC (eXtended Remote Copy) SMF records, but the volume
Jan 7, 1998 data is present only if the volume being copied is in a
duplex state. I need sample data records before I can
proceed to add support for that APAR, so if you can send
sample data for a duplexed volume copied with XRC, do it!
Change 15.326 Cosmetic. Labels were added for variables DCSNAME and
NTINTRV PRODTYPE and NRCPUS, andNRCPUS is now kept in dataset
VMACNTSM NTCONFIG. In NTINTRV, variables DCPQUED and DCPRATE are
Jan 7, 1998 now correctly spelled as DPCQUED and DPCRATE.
Change 15.325 The number of RACF DTP (44) segments kept is increased
VMAC80A from 6 to 12 for RACFEVNT 10 and 13, and the MXG message
Jan 7, 1998 was relocated so the total count in the record is now
printed. See Change 15.289.
Thanks to Tom Parker, Hogan Systems, USA.
Change 15.324A DCOLLECT cluster records do not contain a VOLSER, but the
VMACDCOL Variable DCDVOLSR is now RETAINed from the preceding
Jan 7, 1998 dataset record (DCURCTYP='D', for DCOLDSET dataset) so
that dataset DCOLCLUS now contains DCDVOLSR.
Thanks to John W. Etter, StorageTek, USA.
Change 15.323 All packed decimal inputs are now protected with ?? input
VMACZARA modifier so that hex zeros won't create a SAS log note.
Jan 5, 1998 The file record contains System ID at location 295, so
new variable FILESYST is now created. Both statements
IF FILEDATL=0 THEN DATECR=.; were typos and now read:
IF FILEDATL=0 THEN DATELU=.;
Thanks to Harry Olschewski, DeTeCSM/SES, GERMANY.
Change 15.322 MXG 15.07 only. Remove SMTNTASK from the KEEP statement
ANALCISH 91 lines after DATA &MXGDS1. Change SMTRANI to SMSTRNI
Jan 3, 1998 in all 57 occurrences.
Change 15.321 Some variables in RMF III VSAM processing were wrong.
VMACRMFV -In dataset ZRBASI, variables ASITOTSV, ASISVINR, ASIGSPPI
Jan 3, 1998 and ASIGASPD were wrong because ASICUSE, ASITOTD, and
ASISRVO should have been input as &PIB.4. instead of as
&PIB.2. New variables ASIOREPL, ASIOTOTU, and ASIIOU
(new with OS/390 R1.1) are now created in ZRBASI.
-In dataset ZRBGEI, variables GEIWLMTK and GEISPLXI should
be input $EBCDIC8. instead of $CHAR8. (but under MVS the
results are the same; only if you run MXG under ASCII SAS
would you have noticed the error). Variable PCTCPUBY is
now always missing, as its source field GEICPUOL is now
reserved in OS/390.
Thanks to Joseph Faska, Depository Trust, USA.
Thanks to Peggy Dunne, Depository Trust Company, USA.
Change 15.320 All hardcoded references to "PDB" as a DDNAME are now
many replaced with a macro variable, &PDBxxxx, so that each
VMXGINIT datasets can be re-directed to a different DD if needed.
Jan 2, 1998 For example, if you want to write the TYPE74 dataset to
Jan 12, 1998 a separate DDname of MY74, you would use:
%LET PDB74=MY74; %INCLUDE SOURCLIB(BUILDPDB);
to create dataset MY74.TYPE74 in the MY74 Libref.
A separate &PDBxxxx macro exists for each dataset in the
PDB architecture. The macro &PDB and "PDB." were changed
to &PDBMXG macro name. All of the &PDBxxxx macros have a
default value of "PDB". VMXGINIT defines these macros:
%MACRO VMXGINIT(DEFAULT=PDB);
%LET PDBMXG =&DEFAULT;
%LET PDB0 =&DEFAULT; /*TYPE0 >> PDB.IPLS */
%LET PDB0203=&DEFAULT; /*TYPE0203 */
%LET PDB6 =&DEFAULT; /*TYPE6 */
%LET PDB21 =&DEFAULT; /*TYPE21 >> PDB.TAPES */
%LET PDB25 =&DEFAULT; /*TYPE25 (JES3 ONLY) */
%LET PDB30UD=&DEFAULT; /*TYPE30_D >> PDB.DDSTATS*/
%LET PDB30UV=&DEFAULT; /*TYPE30_V >> PDB.SMFINTRV*/
%LET PDB30U1=&DEFAULT; /*TYPE30_1 */
%LET PDB30U4=&DEFAULT; /*TYPE30_4 */
%LET PDB30U5=&DEFAULT; /*TYPE30_5 */
%LET PDB30U6=&DEFAULT; /*TYPE30_6 */
%LET PDB30OM=&DEFAULT; /*TYPE30OM */
%LET PDB30MU=&DEFAULT; /*TYPE30MU */
%LET PDB70 =&DEFAULT; /*TYPE70 */
%LET PDB70PR=&DEFAULT; /*TYPE70PR */
%LET PDB71 =&DEFAULT; /*TYPE71 */
%LET PDB72 =&DEFAULT; /*TYPE72 */
%LET PDB72GO=&DEFAULT; /*TYPE72GO */
%LET PDB72DL=&DEFAULT; /*TYPE72DL */
%LET PDB72MN=&DEFAULT; /*TYPE72MN */
%LET PDB72SC=&DEFAULT; /*TYPE72SC */
%LET PDB7204=&DEFAULT; /*TYPE7204 */
%LET PDB73 =&DEFAULT; /*TYPE73 */
%LET PDB73L =&DEFAULT; /*TYPE73L */
%LET PDB73P =&DEFAULT; /*TYPE73P */
%LET PDB74 =&DEFAULT; /*TYPE74 */
%LET PDB74CA=&DEFAULT; /*TYPE74CA */
%LET PDB74CF=&DEFAULT; /*TYPE74CF */
%LET PDB74ST=&DEFAULT; /*TYPE74ST */
%LET PDB74TD=&DEFAULT; /*TYPE74TD */
%LET PDB75 =&DEFAULT; /*TYPE75 */
%LET PDB77 =&DEFAULT; /*TYPE77 */
%LET PDB78 =&DEFAULT; /*TYPE78 */
%LET PDB78CF=&DEFAULT; /*TYPE78CF */
%LET PDB78CU=&DEFAULT; /*TYPE78CU */
%LET PDB78IO=&DEFAULT; /*TYPE78IO */
%LET PDB78PA=&DEFAULT; /*TYPE78PA */
%LET PDB78SP=&DEFAULT; /*TYPE78SP */
%LET PDB78VS=&DEFAULT; /*TYPE78VS */
%LET PDBTMNT=&DEFAULT; /*TYPETMNT */
%LET PDBTSWP=&DEFAULT; /*TYPETSWP */
%LET PDBTALO=&DEFAULT; /*TYPETALO */
%LET PDBNJEP=&DEFAULT; /*PDB.NJEPURGE*/
%LET PDBJOBS=&DEFAULT; /*PDB.JOBS */
%LET PDBSTEP=&DEFAULT; /*PDB.STEPS*/
%LET PDBPRIN=&DEFAULT; /*PDB.PRINT*/
%LET PDBRMFI=&DEFAULT; /*PDB.RMFINTRV*/
The &DEFAULT macro argument in VMXGINIT exists so that
SAS ITSV product can send all datasets to the //WORK
file and then later copy them to their //DIRECT libref.
This eliminated the needs discussed in Change 15.272.
It is unlikely anyone else will need to use that option.
Since the default value for all of these macros is "PDB",
the change should be completely transparent to MXG users.
However, users of SAS ITSV Version 2.0 and SAS/CPE must
install this circumvention with MXG 15.08 or later:
The following two lines of code must be inserted
immediately before any %CMPROCES invocation:
%INCLUDE SOURCLIB(VMXGINIT);
%VMXGINIT(DEFAULT=WORK);
Version 2.1 of ITSV does not need this circumvention.
Change 15.319 Cosmetic. Data set Labels were added to VMAC members to
BUIL3005 label datasets TYPE0203, TYPE7, TYPE21, TYPE75, and
BUILD005 TYPE7204, and Labels for datasets PDB.JOBS, PDB.STEPS,
BUILDPD3 PDB.PRINT, PDB.SMFINTRV and (JES2-only) PDB.NJEPURGE were
BUILDPDB added in the BUILxxxx members. The labels in BUILxxxx
DIFFDB2 members now contain BUILDPDB/BUILDPD3/BUILD005/BUIL3005
RMFINTRV so you can tell exactly which member created your PDB
VMAC0203 library! Data set Label for RMFINTRV was added, and in
VMAC21 DIFFDB2 labels were added for the de-accumulated
VMAC7 statistics datasets (and they too indicate DEACCUM versus
VMAC7072 the RAW tag now used in VMACDB2 for those same datasets).
VMAC75 Data set labels are passed from input to output by PROC
VMACDB2 SORTs, so only DATA steps were labeled.
Dec 31, 1997
Thanks to Lindsay Oxenham, IBM Global Services, AUSTRALIA.
Change 15.318 Cosmetic. Comments were updated to list all of the MXG
IMACACCT members that contain account fields and thus include
Dec 31, 1997 member IMACACCT:
VMAC20 VMAC26J2 VMAC26J3 VMAC30 VMAC33 VMAC434
VMAC535 VMACBETA VMACDB2 VMACNAF VMACORAC VMACSFTA
VMACTSOM VMACXPSM XTYPEMVT XTYPEVS1
Thanks to Charlie Bloemker, Lockheed-Martin, USA.
Change 15.317 ML-15 of ASMTAPES does not run under MVS/ESA 4.2 or any
ASMTAPES earlier release of MVS; in fact, the monitor program
Dec 31, 1997 will loop under that archaic release. If you are still
stuck with a back level MVS, use the back level ASMTAPES
or ASMTMNT until you upgrade your MVS.
Thanks to Scott Snyder, First Data Merchant Services, USA.
Change 15.316 Support for OS/400 Release 4.1.0 (INCOMPATIBLE in three
VMACQAPM datasets - QAPMETH, QAPMIDLC, and QAPMLAPD, because field
Dec 30, 1997 lengths were changed and/or reserved fields were deleted)
but the other "important" datasets were not changed.
This support is based on examination of DSECTS, but has
not been absolutely verified with AS400 4.1 data yet.
Thanks to Len Marchant, Coca Cola, USA.
Change 15.315 Major enhancement in architecture of ASUMUOW program that
ASUMUOW merges/sums CICSTRAN and DB2ACCT into one observation for
IMACUOW each unit of work. Member IMACUOW now defines new macro
Dec 30, 1997 _TRANUOW that allows you to determine which CICS trans
record is used to supply TRANNAME in the PDB.ASUMUOW data
set that is created by ASUMUOW. For some environments,
the TRANNAME wanted is the first transaction to end, but
with CICS under OS/2, the first transaction name is CPMI
and that mirror name is not the desired transaction name.
Comments in IMACUOW and ASUMUOW discuss the three choices
that now exist, and other tailoring options.
Note that while ASUMUOW is automatically included in the
JCLPDB6 example, so that dataset PDB.ASUMUOW will be
created by default, the dataset PDB.ASUMUOW will contain
zero observations until you tailor member IMACUOW; that
way, there is no sort of CICSTRAN and DB2ACCT until you
tell MXG you want to create observations in PDB.ASUMUOW.
Thanks to Richard Ralston, Whirlpool Corporation, USA.
Change 15.314 Cosmetic corrections (duplicate variable name in KEEP,
many FORMAT, INFORMAT, or incorrect comment statement naming
Dec 30, 1997 dataset OUTPUT, etc., were corrected in members:
EXAIMRA EXAIMRD EXAIMRP EXAIMRR EXAIMRT EXAMIRS
EXHPTEAP EXHPTECO EXHPTEDS EXHPTEGL EXHPTELA EXHPTEPR
VMAC102 VMAC110 VMAC7072 VMAC99 VMACAIMR VMACCMFV
VMACCTCP VMACDCOL VMACEREP VMACHBUF VMACHURN VMACNSPY
VMACOMVT VMACSARX VMACTCP VMACTMO2 VMACTUX VMACVMXP
VMACXPSM
Thanks to Fredie Arie, Lone Star Gas, USA
Change 15.313 Support for ICSS SMF type 103 (Internet Connection Secure
DIFF103 Server, V2R2, but soon it will be renamed to Domino GO
EXTY1031 Webserver V2R4, with no change in the record format).
EXTY1032 Two new datasets are created for this webserver:
IMAC103 Subtype Dataset Name Description
TYPE103 1 TYPE1031 ICSS Configuration
VMAC103 2 TYPE1032 ICSS Performance
VMACSMF Many Configuration Values are decoded by formats.
Dec 20, 1997 Member VMACSMF had to be updated, because the SMF 103
Jan 14, 1998 record does not correctly set the second bit in the
Feb 20, 1998 first byte ("record has subtype field" bit). The
TYPE1032 Performance record contains request counts like
bytes received/sent, but there is no interval duration in
the IBM record. As a result, member DIFF103 was required
(it is automatically invoked by TYPE103) to create the
interval duration variable DURATM. Although the record
default interval is 15 minutes when the logging queue is
full, if the server activity is minimal the logging
queue fills more slowly and the DURATM will be much
longer than the expected 15 minutes
Note that if you add 103 processing to BUILDPDB, you will
need to %INCLUDE the DIFF103 member in your EXPDBOUT
member to create DURATM in dataset TYPE1032.
The TYPE1032 Performance Data is actually an SNMP MIB
with an SMF header; I suspect we will see many future
SMF records based on Simple Network Measurement Protocol
Measurement Information Blocks!
New information Feb 20, 1998: IBM is fixing the problem
in the SMF 103 records and the fix should be in Lotus
Domino Go Webserver 5.0 (LDGW) with GA in May, 1998. As
I don't have the DSECT changes yet, you will need to get
the then-current version of MXG to process the revised
records (which should eliminate the need for DIFF103).
Thanks to Peter Skov, Jyske Bank, DENMARK.
Change 15.312 MXG 15.07 only. In VMXGINIT, a semi-colon is missing
CHANGES after '15.07' in the %LET MXGVERS=15.07 statement, which
VMXGINIT causes an ERROR message and variable MXGVERSN in TYPE70
Dec 19, 1997 to be missing. Also, the date in CHANGES was 17Dec97,
but the real date (in VMXGINIT) was 18Dec97.
======Changes thru 15.311 were in MXG 15.07 dated Dec 17, 1997======
Change 15.311 Support for Fujitsu's AIM Version V20 SMF records adds
VMACAIM2 several fields to the existing AIM and AIM/NDB records,
VMACAIM6 and new datasets from AIM/RDBII's type 98 SMF record
VMACAIM7 with member TYPEAIMR. Datasets are now labeled and
VMACAIMR alphabetized, and INPUT statements were collimated, but
TYPEAIMR the real logic changes were discovered and contributed
IMACAIMR by the cited codesharks!
EXAIMRT Logic changes (i.e., incompatibilities between V12 and
EXAIMRS V20) were made in VMACAIM2 and VMACAIM6 and the new
EXAIMRP VMACAIMR. The other VMACs were changed only by adding
EXAIMRD existing variables to the KEEP= list or deleting dead
EXAIMRB variables from the KEEP= list.
EXAIMRR
EXAIMRA
Thanks to Ian Heaney, Toyota Australia, AUSTRALIA.
Thanks to D. Ackland, Toyota Australia, AUSTRALIA.
Change 15.310 In ANALCISH reports, "Wait on String - Peak" value was
ANALCISH not the maximum, because it was in the SUM= argument.
Dec 16, 1997 Move variable name A17DSHSW from the SUM= to MAX=.
Thanks to Dale Slaughter, Allied Group Insurance, USA.
Change 15.309 RACF record from 1.0.9.2 caused INPUT STATEMENT EXCEEDED
VMAC80A record, because 3 bytes were documented in Table 4 for
Dec 16, 1997 Event Code 25 (19x), RVARY, but this record contained
only two bytes, so the third byte is now conditionally
input. Change the INPUT to read:
KW25OVIO $CHAR1. /*FLAGS FOR*OTHER*VIOLATIONS*/
@;
IF RACFDLN GE 3 THEN INPUT /* UNDOC RACFDLN=1 FOUND */
KW25ADSP $CHAR1. /*OTHER*KEYWORDS*SPECIFIED*/
Thanks to Len Rugen, University of Missouri-Columbia, USA.
Change 15.308 I changed the CICSEXCE exception dataset when CICS/ESA
IMACCICS was introduced, but I can't find where I really discussed
Dec 16, 1997 the changes to variables. Non-ESA CICS (2.1 & earlier)
had specific variables for each exception, and those only
the variables specific to an exception were non-missing
in a particular observation. But these specific vars
are always missing with CICS/ESA or CICS/TS:
ISAMFILE MSREQWT MSWAITCN MSWAITTM PGMCMPTM
PGMCMPCN SCWTECN SCWTETM TSREQWT TSWAITTM
TSWAITCN VSAMBUFF VSAMFILE VSWAITTM VSWAITCN
because CICS/ESA has one set of variables and their
values describe the exception event and durations:
EXWAITTM - Duration of the exception wait.
EXCMNRTY - Exception Resource Type:
STORAGE FILE TEMPSTOR
EXCMNRID - Exception Resource Identification:
UDSA GLLCLAS FDED
EXCMNTYP - Exception Type (format MG110EX.):
'X01:WAIT (EXCMNWT)'
'X02:BUFFER WAIT (EXCMNBWT)'
'X03:STRING WAIT (EXCMNSWT)'
Exception Exception
Resource Resource
Exception Type Type Identication
EXCMNTYP EXCMNRTY EXCMNRID
'X01:WAIT (EXCMNWT)' STORAGE UDSA
'X02:BUFFER WAIT (EXCMNBWT)' FILE B0INDEX
'X03:STRING WAIT (EXCMNSWT)' TEMPSTOR FDED
This allows for new exception events to be created by IBM
with no need to create new variables for each exception.
Thanks to Dale Slaughter, AMCO Insurance, USA.
Change 15.307 ASUMUOW could produce missing value for MROTRAN count, as
ASUMUOW "spun" observations were not properly reintroduced in the
Dec 16, 1997 next run. Logic involving several lines was revised.
Thanks to Larry Nova, First Card, USA.
Change 15.306 CONTROL-T variables DSUSECT and DSEXCP in CTLTDSN dataset
VMACCTLT were wrong; there are three undocumented bytes before the
Dec 14, 1997 DSUSECT field. Add +3 after INPUT before DSUSECT:
INPUT +3 DSUSECT &PIB.4. ....
Thanks to Joseph G. Ogurchak, Westfield Companies, USA.
Change 15.305 Support for DPPX/370 (Release 4) Performance Reporter
TYPEDPPX creates eleven datasets in this user contribution, by
Dec 14, 1997 reading and decoding the report output as MXG input.
DPPX/370 (Distributed PRocessing Programming Executive)
runs on ES/9000 series and was written by IBM, originally
for 8100, then 9370, and then 9221. Release 4 is the
last release and goes out of service in 1998/1999.
Thanks to Mark Robbins, W.H. Smith LTD, ENGLAND.
Change 15.304 Using 14/15 records to determine the size of datasets
ADOC1415 is not straightforward. Descriptions in ADOC1415 have
Dec 14, 1997 been revised based on Richard's discoveries:
I've recently completed a study where I used TYPE1415
data to analyze our tape use and develop a model for
sizing a VTS subsystem we are considering. In the course
of this, I found myself looking at BLKSIZE, BLKCOUNT,
TRKSALOC, and TRKREL to develop a size in megabytes for
these files. Multi-volume files, both tape and disk,
presented a challenge to correctly accumulate the
multiple type 15 records generated into a single record
representing the creation of the entire file.
RECIND1, bit 1 x'40' 'Record written by EOV'
This bit is ON for records written for a change-in-volume (written
by "End-of-Volume", LASTVOFL=' ' if ON), and this bit is OFF for
records written by close (LASTVOFL='Y' if OFF). When ON (EOV),
this is normally a volume switch within a multi-vol dataset.
Rick thinks this may also occur for file 1 through n-1 for a
sequence of n datasets concatenated on a single DDname, but has
not seen that in his data, and he has not prove whether or not
this bit would be on for the first of two files concatenated
together, which happened to reside on the same volume.
If you can confirm/deny his thesis, I will update this note.
TRKSALOC
This is the number of tracks allocated *on the current volume* to
this dataset. This must be accumulated across multiple TYPE15s
when RECIND1, bit 1 is on.
TRKREL
This is the number of tracks released at close. In the case of
RECIND1, bit 1, this will be zero for all but the last record.
Note however, that this last record does *not* have the EOV bit on.
BLKSIZE
No surprise here. Same for all related records.
BLKCNT
Again, these represent the block count written on the current
volume only. Must be accumulated to get accurate file size.
Performing the accumulation.
Because of the fact that the last record for a given step/DD does
*not* have the EOV bit on, this flag is really not useful to group
records to accumulate. I finally arrived at the following PROC
SUMMARY to accomplish the task:
PROC SORT DATA=TYPE1415;
BY JOB OPENTIME DSNAME SMFTIME;
/*ELIMINATE DUPLICATE RECORDS (MULTI-VOL INTERMEDIATE EOV)*/
PROC SUMMARY DATA=TYPE1415 NWAY;
BY JOB OPENTIME DSNAME;
VAR SMFTIME BLKCNT TRKSALOC TRKREL;
ID AVGBLK ID DEVICE BLKSIZE ;
OUTPUT OUT=SUM1415
MAX(SMFTIME)= SUM(BLKCNT TRKSALOC TRKREL)=;
DATA SUM1415; SET SUM1415;
IF AVGBLK NE 0 THEN MBUSED = AVGBLK * BLKCNT;
ELSE MBUSED = BLKSIZE * BLKCNT;
FORMAT MBUSED MGBYTES.;
(AVGBLK is usually zero, so BLKSIZE is usually used.)
Thanks to Richard T. Green, Comerica Incorporated, USA.
Change 15.303 Revised text, 14May2003: MXG's default _M204VER value in
VMACM204 member VMACM204 (4.1, since 1997) is also valid for 5.xt
Dec 14, 1997 Release, as there were no changes to their SMF records.
May 14, 2003 Original Change text, slightly revised.
Support for MODEL204 Version 4.1 or later added two bytes
at the end of the header. Version-based logic was added
to skip over the bytes, and MXG updated VMACM204 so that
the default is now 4.1. Also, a number of variables
added by Version 3.2 were added to the KEEP= list for the
M24SINCE dataset. The new version is INCOMPATIBLE due to
the insertions in the record.
Thanks to Lindsay Oxenham, IBM Global Services, AUSTRALIA.
Thanks to Carole J. Storby, Lockheed Martin, USA.
Change 15.302 With very large DASD farms, ASMVVDS could run out of
ASMVVDS storage, because it FREEMAINed less than it GOTMAINed.!
Dec 14, 1997 Not only was that corrected,, but also optional supports
UCBs above the 16M line, and now executes in AMODE 31.
Additional cleanup of this old programs for sites that
need detail VVDS info (or don't have DCOLLECT).
Thanks to Skip Abadie, MBNA, USA.
Change 15.301 The counts in the starting/ending intervals were usually
ASUMTALO wrong, because spun records ("inflight allocations") were
Dec 14, 1997 kept after output and were counted by the summary logic!
This caused MAXDRVS to be greater than installed devices.
Fortunately, the effect was only for the beginning and
ending interval of the analysis, so the effect should
have been minimal on your analysis.
-After IF ALOCEND GT &LOWTIME THEN OUTPUT SPIN.SPINTALO;
insert ELSE DO; and then after fourteen lines, insert
END; before the PROC SORT DATA=TALOSUM1....;
This corrects the basic error in logic.
-Additionally, LASTTIME was used as a temporary variable,
but was not dropped, and then used in adjusting for clock
synchronization. Now it's DROPped:
After RETAIN HOLDEND LASTTIME 0;
insert DROP LASTTIME;
-In addition, the PROC PRINT DATA=TALOSUM1, WHERE, and VAR
statements left for debugging were deleted.
Thanks to Anthony P. Lobley, EDS, ENGLAND.
Change 15.300 Support for SAR CA-VIEW Selection Request Exit SARSRQUX
EXTYSARX SMF record creates new dataset SARSRQUX.
IMACSARX
TYPESARX
VMACSARX
Dec 14, 1997
Thanks to Tim Haiar, Citicorp, USA.
Change 15.299 TYPE70PR PR/SM dataset did not contain an observation for
VMAC7072 partitions that were deactivated (LPARCPUS=0), and some
Dec 13, 1997 sites have needed an observation for that LPARNAME for
configuration reports. Replace DO J=1 TO LPARCPUS; with
IF LPARCPUS=0 THEN DO; %%INCLUDE SOURCLIB(EXTY70PR);END;
ELSE DO J=1 TO LPARCPUS;
If you do NOT want observations for deactived partitions,
you could delete the obs with LPARCPUS=0 in EXTY70PR!
Thanks to Hartmut Beckmann, Karstadt AG, GERMANY
Thanks to Dr. Alexander Raeder, Karstadt AG, GERMANY.
Change 15.298 ERROR: VARIABLE TERMINAL NOT FOUND in these sample CICS
ANALCICS reports occurs when _LCICTRN sends CICSTRAN to //WORK
Dec 13, 1997 instead of to the //CICSTRAN DD, because the report code
used OUT=CICSTRAN for the first PROC SORT with a KEEP=
statement, so a later reference to _LCICTRN got the OUT=
dataset instead of the original CICSTRAN data. Change
CICSTRAN to SORTTRAN (four places) to correct this error.
I also added KEEP= logic to each input of _LCICTRN to
reduce input data read, but the reports will be re-done
using ANALCNCR to much more expeditiously count the CICS
concurrent users.
Thanks to Doug Jungels, Fingerhut Corporation, USA.
Thanks to James Lieser, Fingerhut Corporation, USA.
Change 15.297 Variables VELOCITY, VELOCCPU, and VELOCIOD were 0 to 1 in
ANALRMFR TYPE72 and TYPE72GO datasets, but were multiplied by 100
TRND72GO in ANALRMFR reports where they matched IBM report values.
VMAC7072 But I now realize they should be 0 to 100 in both the IBM
Dec 13, 1997 report and the MXG datasets, so their values are changed.
-In VMAC7072, four lines VELOCITY=... are VELOCITY=100*...
and ELSE VELOCIOD= is now ELSE VELOCIOD=100*
and PERFINDX=R723CVAL/VELOCITY; has its 100* removed.
-In ANALRMFR, the VELOCITY=100*VELOCITY; was removed.
-In TRND72GO, 100* was added to VELOCITY= and the 100*
was removed in the denominator of PERFINDX= calculation.
Thanks to Ken Williams, Southern Electric, ENGLAND.
Change 15.296 Support for Omegamon for VTAM V400 (COMPATIBLE, but new
EXOMVX2L subtypes and exceptions will print "invalid" messages on
EXOMVX2M the SAS log). Three new subtypes create datasets:
EXOMVX2V Subtype Dataset Description
IMACOMVT 15 OMVTX2MC X.25 MCH Link
VMACOMVT 16 OMVTX2VC X.25 VC
Dec 4, 1997 17 OMVTX2LU X.25 LU
There are also nineteen new exceptions, 0939-0957 that
are now decoded.
Thanks to Joseph E. Darvish, Farmers Insurance Group, USA.
Change 15.295 The ACCOUNTn variables in DB2ACCT did not decode skipped
VMACDB2 fields correctly. DB2 replaces the comma delimiters in
Dec 3, 1997 the job card with 'FF'x, and (TOMP,9999,XXX,,,ACCT6) had
variable ACCOUNTn = 'FFFF'xACCT6. Each of the nine
DO groups in VMACDB2 that read:
IF LOC LE 1 THEN DO;LENACCTn=ACCTLEFT;ACCTLEFT=0;END;
were replaced with
IF LOC EQ 1 THEN DO;LENACCTn=0;ACCTLEFT=ACCTLEFT-1;END;
ELSE IF LOC LT 1 THEN DO; LENACCTn=ACCTLEFT;ACCTLEFT=0;
END;
to properly parse the 'FF'x delimiter.
Thanks to Tom Parker, CSC Financial Services Group, USA.
Change 15.294 Change 15.054 intended to have four blanks after SYSTEM
TYPETMON and SYSID, but ended up with five, so SYSID became length
Dec 3, 1997 five instead of four.
Thanks to Jim Wertenberger, Medical Mutual of Ohio, USA.
Change 15.293 SAS Option YEARCUTOFF=1960 is MXG's default specification
CONFIG in member CONFIG, as this makes MXG more robust in its
YEAR2000 attempt to protect non-Y2K-compliant dates. In MXG 15.05
YEAR2000 I added code to protect records written in 2000 that do
Dec 3, 1997 not have the "century value" in julian dates, or still
have only 2 year digits in YYMMDD-type date fields.
I thought I could protect non-Y2K-compliant fields after
the input of the date, by detecting that the year was
pre-1960, and then I could add the number of days between
1900 and 2000 to move the non-Y2K date into the second
millennium.
I now know it is impossible to correct all cases after
the field has been INPUT, because some date values will
be missing after INPUT, because some dates that are valid
in 2000 were invalid in 1900:
non-Y2K value Informat Y2K date
000229 YYMMDD6. 29FEB2000
'000000000000366F'x SMFSTAMP8. 31DEC2000
The YYMMDD6 is in error because there was no leap year
day in 1900, and the SMFSTAMP8 is in error because there
were only 365 days in the year 1900.
The YYMMDD6 error can be eliminated by changing the SAS
default YEARCUTOFF=1900 to YEARCUTOFF=1960, because then
SAS will accept 000229 as Feb 29, 2000; this will also
eliminate the need for the MXG protection logic.
I had been reluctant to base MXG's support of the year
2000 on any SAS option, believing I could provide safer
protection that would function independent of the SAS
YEARCUTOFF option's value. However, it now appears
that the best choice is to make YEARCUTOFF=1960 the
value set in MXG's CONFIG member, and that was done.
The SMFSTAMP8 error cannot be eliminated because the
YEARCUTOFF option does not apply to those julian date
informats, and making it apply is likely to cause more
exposure to error than it is worth. However, SAS
Institute will consider enhancing the SMFSTAMP, RMFSTAMP,
etc., formats to provide this functionality internally,
and it may be available (in a future TS-level maintenance
release).
Fortunately, the logic added by Change 15.167 (that will
be removed) has no impact on present dates and thus
causes no errors until after 1999.
These notes are just for the record:
Change 15.167 used 36524 as the constant number of
days between 1900 and 2000 for YEARSECS, but it turns
out that the number of days to add is not a constant:
For dates in 2000:
01JAN1900 + 36524 = 01JAN2000
01MAR1900 + 36524 = 29FEB2000
That '29FEB2000' might look wrong, but the 60th
julian date of 1900 was 01MAR1900, and the 60th
julian date of 2000 is 29FEB2000, so it is ok!
For dates in 2001
01JAN1901 + 36524 = 31DEC2000
which is definitely wrong; a value of 36525 should
have been used for years after 2000!
Thanks to Nico Lenaerts, SAS Institute, BELGIUM.
Thanks to Michel Laublin, GIB, BELGIUM.
Change 15.292 The example extract command for HP MeasureWare from HPUX
ADOCMWUX statements GBL_BYDISK_ID_LIST and GBL_BYLAN_ID_LIST that
Dec 1, 1997 caused "unknown metrics" error; the statements should
not have been in the example and were deleted.
Thanks to Thierry Van Moer, Procter & Gamble, BELGIUM.
Change 15.291 MXG 15.06 did not contain ML-15 of ASMTAPES. While the
ASMTAPES comments in the member said it was ML-15, in fact it was
Dec 1, 1997 still ML-14 with only comments changed, and when Started
it said it was ML 14! The wrong member was copied into
15.06 and then its comments were edited. This change
really is the ML-15 that was promised, and when it is
Started it actually says that it is ML-15!
Thanks to Glenn Harper, Memorial HealthCare System, USA.
Thanks to Mark Smith, First Card, USA.
Change 15.290 Documentation only. Minor corrections to variables in
ADOCNTSM datasets RASPORT (CONNTOTL did not belong in list),
Dec 1, 1997 NETWINTR (INTRNAME was not listed), IMAGE (IMAGFILE and
IMAGNAME are CHAR 32), and IP (DEVNAM did not belong).
Thanks to Bob Gauthier, American Stores Company, USA.
Change 15.289 MXG keeps only one RACF DTP (44) segment's variables
VMAC80A until multiple segments are actually found in RACF data,
Dec 1, 1997 and then the (usually unimportant) EV44xxxx variables
are added to the KEEP= list for that event. This change
adds six sets of EV44xxxx variables for RACFEVNT=13 (six
were previously kept for RACFEVNT=10), and clarifies the
text of the message printed when new segments are found.
All of this, just to save a little disk space!
Thanks to Gerald Lawrence, ABN AMRO Bank NV, THE NETHERLANDS.
Change 15.288 MXG 15.06 only. Label for variables LOSMCNTR & LOIOCOMP
VMAC16 were too long, causing warning on SAS log but no error.
Nov 26, 1997
Thanks to Freddie Arie, Lone Star Gas, USA.
======Changes thru 15.287 were in MXG 15.06 dated Nov 24, 1997======
Change 15.287 Local and Remote IP addresses are now decoded into their
VMACCTCP dec.dec.dec.dec format in Clever TCP/IP's SMF record, and
Nov 24, 1997 are changed from numeric to character variables.
Change 15.286 Dataset TYPE30_6 is interval data for address spaces that
VMAC30 do not go thru full function startup (examples of JOBs
Nov 24, 1997 that create observations in TYPE30_6 are RASP,ALLOCAS,
IEFSCHAS,CONSOLE,SMXC,GRS,SYSBMAS,TRACE,PCAUTH,OMVSSTFS),
but the interval start times (SMF30ISS,SMF30IST) from
which GMT offset is calculated are missing, so SYNCTIME
in TYPE30_6 was always on the GMT clock. This change
uses a heuristic comparison of SMFTIME and SYNCTIME
to correct the hour-part of SYNCTIME if there is a
difference (inserted before the %INCLUDE of EXTY30U6):
SYNCTIME=SYNCTIME+3600*FLOOR((SMFTIME-SYNCTIME+1800)/3600);
but having the real GMT offset in the record
would have been better!
Thanks to Hartmut Beckmann, Karstadt AG, GERMANY
Thanks to Dr. Alexander Raeder, Karstadt AG, GERMANY.
Change 15.285 ML-15 of ASMTAPES MXG Tape Mount and Tape Allocation
ASMTAPES Monitor has two enhancements:
Nov 20, 1997 -Dump suppression. When MXGTMNT intercepts internal
ABENDS (usually do to a logically address space changing
states, often 0C4 or 0E0 ABENDS), now the SVC dump will
be suppressed, unless you enable the 'DEBUG=YES' option,
which will cause an SVC dump to be taken. However, a
logrec record will be created for all ABENDs, so it will
be possible to get some information if required.
-Step start date (INITTIME) year 2000 support relocated
the date from the ASID's JCT to the JCT Extension in
OS/390 Release 1.3 and above. If you are at OS/390 R1.3
or higher, you will need to change the default of 'ES5'
to 'ES6' when you assemble ASMTAPES to pick up the step
start date from the JCT Extension.
Change 15.284 INPUT STATEMENT EXCEEDED with an EREP record, CLASRC=40,
VMACEREP but flag bits indicate that the record was truncated, so
Nov 20, 1997 those bits are now tested before the INPUT statement so
the STOPOVER abend is eliminated.
Change 15.283 Additional CICS DFHSTUP "Shutdown" reports have been
ANALCISH added/revised in this iteration:
Nov 20, 1997 -CICSMDSA, CICSMS, and CICSMT "Storage Manager Statistics
were updated.
-CICDS uses CICS release SMFPSRVR for decision logic.
-CICAUSS adds new CICS 4.1 fields to detail/summarys.
-CICFCR "Files" report is complete.
Thanks to Steve Colio, CIGNA, USA.
Change 15.282 Variables BYTEREAD and BYTEWRIT in TYPE21 (which is
VMAC21 renamed to PDB.TAPES) are now formatted MGBYTES.
Nov 19, 1997
Thanks to Chuck Hopf, MBNA, USA.
Change 15.281 Support for Landmark's The Monitor for CICS/ESA 2.0, a
ANALMONI completely INCOMPATIBLE reformatting of their records.
EXMONARQ You must now use program TYPETMO2 instead of TYPETMON to
EXMONAWT process the new records, but the MONITASK dataset that
EXMONDSP MXG creates should be compatible as only a few old
EXMONDBD variables were removed by LANDMARK, although there are
EXMONMRO many new ones.
EXMONUSR Landmark notes that the TD,TF,TM,TP,TS,TT,T2 and TX data
EXMONUTG is based on CICS statistics, while the TR record is part
EXMONTAS based on CICS stats and part based on data collected by
EXMONTDQ TMON; the TR record contains much of the non-volatile
EXMONTFI data previously written in the TI record. The MONISYST
EXMONSYS dataset may also be compatible, but some variables may
EXMONCMX have moved to the TR-record datasets, and some variables
EXMONIDS may be spelled differently if I did not recognize them!
EXMONIRQ
EXMONIWT The meaning of the TI interval data has been changed.
EXMONTMC Previously, data was posted to the interval as it was
EXMONTP collected, leading to a highly accurate picture of the
EXMONTPD activity during that interval, but increasing the
EXMONTPG collection overhead. Instead, in Version 2.0, the TI
EXMONTR data is collected by rolling up the TA (Transaction End)
EXMONDSA event records into the interval in which they ended, so
EXMONEXP the accuracy of each interval is lost! Landmark claims
EXMONXMC "over time this results in the same statistics, but the
EXMONTS distribution across intervals may be different. In a busy
EXMONTSQ CICS region the difference will be very small. In a
EXMONTTR small test region discrepancies may be more noticeable".
EXMONTX I seriously question the utility of interval data that
EXMONTXN does not represent the interval. It is not the
EXMONT2 busyness of the region but the long-running
EXMONT2E transactions that end from time-to-time that corrupt
IMACTMO2 their interval data, so all of the datasets created
TYPETMO2 from the TI record may be inaccurate.
VMACTMO2
Nov 19, 1997 Thirty MXG datasets are created from the new records:
Record Description
TA - Transaction Performance Record
TD - Transient Data Interval Record
TF - File Interval
TI - Transaction Activity Interval Record
TM - MRO/ISC Interval Record
TP - Program Interval Record
TR - Region Interval Record
TS - Temporary Storage Interval Record
TT - Terminal Interval Record
TX - Transaction Interval Record
T2 - DB2 Interval for CICS Record
Record Segment MXG Dataset
TA ARQ MONIARQ
AWT MONIAWT
DSP MONIDSP
DBD MONIDBDS
MRO MONIMRO
USR MONIUSR
UTG MONIUTG
TAS MONITASK
TD TDQ MONITDQ
TF TFI MONITFI
TI SYS MONISYST
CMX MONICMX
IDS MONIIDS
IRQ MONIIRQ
IWT MONIIWT
TM TMC MONITMC
TP TP MONITP
TPD MONITPD
TPG MONITPG
TR TR MONITR
DSA MONIDSA
EXP MONIEXP
XMC MONIXMC
TS TS MONITS
TSQ MONITSQ
TT TTR MONITTR
TX TX MONITX
TXN MONITXN
T2 T2 MONIT2
T2E MONIT2E
-ANALMONI's example reports using MONISYST were disabled
because many old variables no longer exist, and the old
examples weren't all that good, anyhow!
Change 15.280 Landmark's The Monitor for MVS Version 2.0 INCOMPATIBLE.
VMACTMV2 Essentially all records have been tested and do not fail.
IMACTMV2 Not all datasets have all variables decoded; as users
TYPETMV2 request them, they will be built. You must use member
Nov 19, 1997 TYPETMV2 instead of TYPETMVS for Version 2 records.
Thanks to Chris Taylor, VF, USA.
Change 15.279 MXG 15.04-MXG 15.05. DB2 report PMTRN01 caused APPARENT
ANALDB2R MACRO &SORTUOW UNRESOLVED, because Change 15.173 added a
Nov 18, 1997 new option to %ANALDBTR (UOWSORT=, that creates &SORTUOW
as a local macro variable), but old-style macro _TRANSIT
that is also defined in member ANALDBTR is also invoked
in ANALDB2R, but the &SORTUOW was local to %ANALDBTR and
did not exist when _TRANSIT was invoked. &SORTUOW is not
actually used by _TRANSIT, so the correction is to insert
%LET SORTUOW=; immediately before the _TRANSIT line.
Thanks to Tom Elbert, John Alden, USA.
Change 15.278 Calculation of B1HITRAT,B2HITRAT,B3HITRAT, and B4HITRAT
DIFFDB2 had mis-located parenthesis; there was no syntax error,
Nov 18, 1997 but the value was wrong. (Variable BPHITRAT was fine.)
The four calculations for the BnHITRAT variables need to
look like this
B1HITRAT=(QB1TGET-(QB1TSIO+QB1TDPP+QB1TLPP+QB1TSPP))/QB1TGET;
with all of the parens in the numerator.
Thanks To Yao-Chun Rickert, First National Bank of Chicago, USA.
Change 15.277 Under VM/CMS SAS, it is not possible to specify a MACLIB
INSTALL member in the CONFIG option, so the INSTALL instructions
Nov 18, 1997 for MXG under CMS were revised; now you can create the
CONFIGVM SAS A file from the copy file, and then use
SAS (NODMS CONFIG=CONFIGVM syntax.
Thanks to Sue Kent, CHEVRON, USA.
Change 15.276 IOA/Control-T 5.0 input of variable DSEXPDT was changed.
VMACCTLT If DSEXPTYP is 'C' or 'L', DSEXPDT is INPUT as PIB.4, as
Nov 18, 1997 if 'C' it is a numeric with the number of active cycles,
or if 'L' it is a numeric with the number of days since
last access; if 'D' or 'J' it is INPUT as PD4. as then
it is a date value.
Thanks to Joseph G. Ogurchak, Westfield Companies, USA.
Change 15.275 SAP IMS timestamp SAPTIMTR must be used as the Start of
VMACIMSA Transaction, and the true End time is SAPTIMTR+SAPELTI.
Nov 17, 1997 Subtracting the SAPELTI from the Log Time produced bad
results; there appears to be a delay between the true
End time and the Log Time that is being examined.
The LABEL for SAPTIMTR now indicates "START TIME..."
Thanks to Cary Jones, Philip Morris, USA.
Change 15.274 Support for CICS TS 1.2 a/k/a CICS Transaction Server 1.2
EXCICD2G is INCOMPATIBLE because IBM inserted new fields into the
EXCICD2R middle of the Type 110 Subtype 1 Monitor (Transaction)
EXCICXQ1 record, instead of adding them at the end of the record!
EXCICXQ3 You must install this Change to process TS 1.2 records.
EXCICXQ3 In addition, new variables were added to CICSLGS Stats
FORMATS dataset, and five new (and important) interval statistics
IMACEXCL data sets are created with CICS TS 1.2, described below:
VMAC110 Dataset STID Description
Nov 15, 1997 CICD2G 102 DB2 Global Statistics
CICD2R 103 DB2 Resource Statistics
CICXQ1 121 Shared TS Queue Server Coupling Facility
CICXQ2 122 Shared TS Queue Server Buffer Statistics
CICXQ3 123 Shared TS Queue Server Storage Stats.
-New variables added to CICSTRAN dataset:
BRDGTRAN='BRIDGE*TRANSACTION*ID'
CPUTM ='TOTAL*CPU TIME*CAPTURED'
ICTOTCN ='IC START*CANCEL*DELAY*RETRIEVE*REQUESTS'
PCLURMCN='LINK URM*REQUESTS'
WTDWIOCN='DISPATCHABLE*WAIT*GIVE UP*DELAY*COUNT'
WTDWIOTM='DISPATCHABLE*WAIT*GIVE UP*DELAY*DURATION'
WTICIOCN='INTERVAL*CONTROL*DELAY*COUNT'
WTICIOTM='INTERVAL*CONTROL*DELAY*DURATION'
WTLMIOCN='LOCK*MANAGER*DELAY*COUNT '
WTLMIOTM='LOCK*MANAGER*DELAY*DURATION'
WTOTIOTM='TOTAL*OTHER*WAIT*TIME*DURATION'
WTSHIOCN='SHARED*TEMP STORE*DELAY*COUNT'
WTSHIOTM='SHARED*TEMP STORE*DELAY*DURATION'
WTTOIOTM='TOTAL*I/O*WAIT TIME*DURATION'
WTUNIOTM='UNCAPTURED*WAIT*TIME*DURATION'
WTWCIOCN='WAIT*CICS/EVENT*WAIT*DELAY*COUNT'
WTWCIOTM='WAIT*CICS/EVENT*WAIT*DELAY*DURATION'
WTWEIOCN='WAIT*EXTERNAL*WAIT*DELAY*COUNT'
WTWEIOTM='WAIT*EXTERNAL*WAIT*DELAY*DURATION'
-The CPUTM is TASCPUTM + RLSCPUTM, the sum of TCB and SRB
CPU time used by the transaction.
-Three very useful new Wait variables WTTOIOTM, WTOTIOTM
and WTUNIOTM are created in CICSTRAN based on IBM's
equations in the CICS Performance Guide an help explain
why a CICS transaction is waiting:
WTTOIOTM = Total I/O Wait Time, is the sum of:
WTTCIOTM+ Terminal Control I/O Wait
WTTSIOTM+ Temporary Storage I/O Wait
WTSHIOTM+ Shared Temporary Storage I/O Wait
WTTDIOTM+ Transient Data I/O Wait
WTJCIOTM+ Journal Control I/O Wait
WTFCIOTM+ File Control I/O Wait
WTRLIOTM+ RLS File I/O Wait
WTIRIOTM+ Interregion (MRO) I/O Wait
LU61IOTM+ LU 6.1 TC I/O Wait
LU62IOTM+ LU 6.2 TC I/O Wait
SZWAIOTM FEPI Suspend I/O Wait
WTOTIOTM = Total Other Wait Time, is the sum of:
DSPDIOTM+ First Dispatch Delay (MXT+TRANCLASS)
ENQDIOTM+ ENQ Delay
WTICIOTM+ Interval Control Delay
WTLMIOTM+ Lock Manager Delay
WTWEIOTM+ Wait External Wait
WTWCIOTM+ Wait CICS/Event Wait
WTDWIOTM+ Dispatchable or Give Up Wait
RMISIOTM RMI Suspend
WTUNIOTM = Uncaptured Wait Time, is calculated as:
WTUNIOTM=SUSPNDTM-(WTTOIOTM+WTOTIOTM);
-New variables added to CICLGS Statistics dataset:
LGSAUTOD='DATA*AUTO*DELETE*FLAG?'
LGSDONLY='DASD*ONLY*FLAG'
LGSMAXBL='MAXIMUM*BLOCK*LENGTH'
LGSRETPD='DATA*RETENTION*PERIOD'
LGSSTRUC='CF*STRUCTURE*NAME'
LGSSYSLG='SYSTEM*LOG*FLAG'
-New dataset CICD2G DB2 Global Statistics contains:
D2GABORT='ABORTS'
D2GACCOU='ACCOUNTREC*SETTING'
D2GATHID='STATIC*AUTHID'
D2GATHTY='AUTHTYPE'
D2GCALLS='CALLS*USING POOL'
D2GCOMIT='COMMITS'
D2GCONGM='CONNECT*TIME*GMT'
D2GCONLO='CONNECT*TIME*LOCAL'
D2GDB2ID='DB2*SYSID'
D2GDB2RL='DB2*RELEASE'
D2GDBCON='NAME*OF THE*DB2CONN'
D2GDISGM='DISCONNECT*TIME*GMT'
D2GDISLO='DISCONNECT*TIME*LOCAL'
D2GDSNAT='DSNC*STATIC*AUTHTYPE'
D2GDSNAU='DSNC*STATIC*AUTHID'
D2GDSNCC='DSNC*COMMAND*CALLS'
D2GDSNCU='DSNC*CURRENT*NUMBER OF*THREADS'
D2GDSNLM='DSNC*LIMIT*NUMBER OF*THREADS'
D2GDSNOV='DSNC*OVERFLOWS*TO POOL'
D2GDSNPK='DSNC*PEAK*NUMBER OF*THREADS'
D2GDSNSI='DSNC*SIGNONS'
D2GDSNTT='DSNC*THREAD*TERMINATES'
D2GPLEXI='PLANEXIT*NAME'
D2GPLNAM='STATIC*PLAN NAME'
D2GRDQCU='NUMBER OF*TASKS ON*READYQ'
D2GRDQPK='PEAK NUMBER*OF TASKS*ON READYQ'
D2GSIGNO='SIGNONS'
D2GSPCMM='SINGLE*PHASE*COMMITS'
D2GTCBCU='CURRENT*NUMBER*OF TCBS'
D2GTCBFR='CURRENT*NUMBER OF*FREE*TCBS'
D2GTCBHW='HIGH*WATER*MARK*OF TCBS'
D2GTCBLM='LIMIT*NUMBER*OF TCBS'
D2GTHRCU='CURRENT*NUMBER OF*THREADS'
D2GTHRLM='LIMIT*NUMBER OF*THREADS'
D2GTHRPK='PEAK*NUMBER OF*THREADS'
D2GTHRPR='THREAD*PRIORITY'
D2GTHRRE='THREAD*REUSES'
D2GTHRTE='THREAD*TERMINATES'
D2GTHRWA='THREAD*WAITS'
D2GTHWSE='THREADWAIT*SETTING'
D2GTRQCU='NUMBER OF*TASKS ON*TCB*READYQ'
D2GTRQPK='PEAK NUMBER*OF TASKS*ON TCB*READYQ'
D2GTSKCU='CURRENT*NUMBER OF*TASKS'
D2GTSKPK='PEAK*NUMBER OF*TASKS'
D2GTSKTO='TOTAL*NUMBER OF*TASKS'
-New dataset CICD2R DB2 Resource Statistics contains:
D2RABORT='ABORTS'
D2RACCOU='ACCOUNTREC*SETTING'
D2RATHID='STATIC*AUTHID'
D2RATHTY='AUTHTYPE'
D2RCALLS='CALLS*USING*DB2ENTRY'
D2RCOMIT='COMMITS'
D2RDBENT='NAME*OF THE*DB2ENTRY'
D2RPLEXI='PLANEXIT*NAME'
D2RPLNAM='STATIC*PLAN NAME'
D2RRDQCU='NUMBER OF*TASKS ON*READYQ'
D2RRDQPK='PEAK NUMBER*OF TASKS*ON READYQ'
D2RSIGNO='SIGNONS'
D2RSPCMM='SINGLE*PHASE*COMMITS'
D2RTHPCU='CURRENT*NUMBER OF*PROTECTED*THREADS'
D2RTHPLM='LIMIT*NUMBER OF*PROTECTED*THREADS'
D2RTHPPK='PEAK*NUMBER OF*PROTECTED*THREADS'
D2RTHRCU='CURRENT*NUMBER OF*THREADS'
D2RTHRLM='LIMIT*NUMBER OF*THREADS'
D2RTHRPK='PEAK*NUMBER OF*THREADS'
D2RTHRPR='THREAD*PRIORITY'
D2RTHRRE='THREAD*REUSES'
D2RTHRTE='THREAD*TERMINATES'
D2RTHRWA='THREAD*WAITS*OR OVERFLOWS'
D2RTHWSE='THREADWAIT*SETTING'
D2RTSKCU='CURRENT*NUMBER OF*TASKS'
D2RTSKPK='PEAK*NUMBER OF*TASKS'
D2RTSKTO='TOTAL*NUMBER OF*TASKS'
-New dataset CICXQ1 CICS Shared Temporary Storage Queue
Server Coupling Facility Statistics (i.e., how much of
the CF does each structure use) contains:
S1ASYCT ='ASYNCHRONOUS*REQUESTS'
S1CNNAME='NAME FOR*CONNECTION*TO STRUCTURE'
S1CRLCT ='CREATE*LIST*FOR A BIG*QUEUE'
S1DLLCT ='DELETE*LIST*1 PER*OVERALL*DELETE'
S1DLQCT ='DELETE*QUEUE*INDEX*ENTRY'
S1ELEMCT='CURRENT*ELEMENTS*IN USE'
S1ELEMHI='HIGHEST*ELEMENTS*IN USE'
S1ELEMLN='DATA*ELEMENT*SIZE'
S1ELEMLO='LOWEST*FREE*ELEMENTS*='/
S1ELEMMX='MAX ELEMENTS*RETURNED BY*IXLCONN'
S1ELEMPE='MAXIMUM*ELEMENTS*PER ENTRY'
S1ELEMPW='DATA*ELEMENT*SIZE*POWER OF 2'
S1ELEMRT='ELEMENT*SIZE OF*ENTRY*ELEMENT*RATIO'
S1ENTRCT='CURRENT*ENTRIES*IN USE'
S1ENTRHI='HIGHEST*ENTRIES*IN USE'
S1ENTRLO='LOWEST*FREE*ENTRIES'
S1ENTRMX='MAX ENTRIES*RETURNED BY*IXLCONN'
S1ENTRRT='ENTRY*SIZE OF*ENTRY*ELEMENT*RATION'
S1FREECT='ENTRIES*ON*FREE LIST'
S1FREEHI='HIGHEST*ENTRIES*IN*QUEUE INDEX'
S1HDRS ='MAXIMUM*NUMBER OF*LIST*HEADERS'
S1HDRSCT='HEADERS*USED FOR*CONTROL*LISTS'
S1HDRSQD='HEADERS*AVAILABLE*FOR QUEUE*DATA'
S1INDXCT='ENTRIES*IN*QUEUE INDEX'
S1INDXHI='HIGHEST*ENTRIES*ON*USED LIST'
S1INLCT ='INQUIRE*ON*LIST*ENTRY'
S1INQCT ='READ*QUEUE*INDEX*STATUS*ONLY'
S1NAME ='FULL NAME*OF LIST*STRUCTURE'
S1RDLCT ='READ*LIST*ENTRY'
S1RDQCT ='READ*QUEUE*INDEX*ENTRY'
S1RRLCT ='REREAD*LIST*DATA*FOR FULL*LENGTH'
S1RRQCT ='REREAD*INDEX*DATE*FOR FULL*LENGTH'
S1RSP1CT='RESPONSES*NORMAL*EVERYTHING*OK'
S1RSP2CT='RESPONSES*BUFFER*LENGTH*TOO SHORT'
S1RSP3CT='RESPONSES*NO*MATCHING*ENTRY'
S1RSP4CT='RESPONSES*ENTRY*VERSION*NO MATCH'
S1RSP5CT='RESPONSES*LIST*AUTHORITY*MISMATCH'
S1RSP6CT='RESPONSES*MAX LIST KEY*REACHED'
S1RSP7CT='RESPONSES*STRUCTURE*OUT OF SPACE'
S1RSP8CT='RESPONSES*OTHER*IXLLIST*RTRN CODE'
S1RWLCT ='REWRITE*LIST*ENTRY'
S1SIZE ='STRUCTURE*SIZE'
S1SIZEMX='MAXIMUM*STRUCTURE*SIZE'
S1USEDCT='ENTRIES*ON*USED LIST'
S1USEDHI='HIGHEST*ENTRIES*ON*USED LIST'
S1WRACT ='WRITE*QUEUE*INDEX*ADUUNCT*AREA ONLY'
S1WRLCT ='WRITE*LIST*ENTRY'
S1WRQCT ='WRITE*QUEUE*INDEX*ENTRY'
-New dataset CICXQ2 CICS Shared Temporary Storage Queue
Server Buffer Statistics measures the queue index buffer
pool and contains:
S2BFACTS='ACTIVE*BUFFERS*OWNED*BY TASKS'
S2BFEMPS='EMPTY*BUFFERS*ON*FREE CHAIN'
S2BFENTH='BUFFERS*USED*SO FAR'
S2BFFNOS='FREE ERRORS*BUFFER*NOT OWNED'
S2BFFRES='FREES*PUT BACK*BUFFER*AS EMPTY'
S2BFGETS='GET*REQUESTS'
S2BFGFRS='GETS*WHICH USED*A FREE*BUFFER'
S2BFGLRS='GETS*WHICH*USED*THE LRU*BUFFER'
S2BFGNBS='GETS*WHICH*RETURNED*NO*BUFFER'
S2BFGNWS='GETS*WHICH*USED*A NEW*BUFFER'
S2BFHITS='GET*WHICH FOUND*A VALID*BUFFER'
S2BFKEPS='KEEPS*PUT BACK*BUFFER*AS MODIFIED'
S2BFLRUS='VALID*BUFFERS*ON*LUR CHAIN'
S2BFLWTS='GET*WAITS*ON*BUFFER*LOCK'
S2BFPNFS='PURGES*WITH NO*MATCHING*BUFFER*FOUND'
S2BFPNOS='PURGE ERRORS*BUFFER*NOT OWNED'
S2BFPURS='PURGES*MARK*BUFFER*INVALID'
S2BFPUTS='PUTS*PUT BACK*BUFFER*AS VALID'
S2BFPWTS='WAITS*ON*BUFFER POOL*LOCK'
S2BFQTY ='TOTAL*BUFFERS*DEFINED'
-New dataset CICXQ3 CICS Shared Temporary Storage Queue
Storage Statistics measure usage of AXMPGANY & AXMPGLOW
storage pool areas, with:
S3ANYFR ='FREE PAGES*IN THE*STORAGE*ANY POOL'
S3ANYLO ='LOWEST*FREE PAGES*ANY POOL*SINCE RESET'
S3ANYMX ='TOTAL PAGES*IN THE*STORAGE*ANY POOL'
S3ANYNAM='POOL*NAME*AXMPGANY'
S3ANYPTR='ADDRESS OF*STORAGE*ANY POOL*AREA'
S3ANYRQC='ANY*COMPRESS*DEFRAGMENTATION*ATTEMPTS'
S3ANYRQF='ANY GETS*FAILING*TO OBTAIN*STORAGE'
S3ANYRQG='ANY POOL*STORAGE*GET*REQUESTS'
S3ANYRQS='ANY POOL*STORAGE*FREE*REQUESTS'
S3ANYSIZ='SIZE OF*STORAGE*ANY POOL*AREA'
S3ANYUS ='USED PAGES*IN THE*STORAGE*ANY POOL'
S3LOWFR ='FREE PAGES*IN THE*STORAGE*LOW POOL'
S3LOWLO ='LOWEST*FREE PAGES*LOW POOL*SINCE RESET'
S3LOWMX ='TOTAL PAGES*IN THE*STORAGE*LOW POOL'
S3LOWNAM='POOL*NAME*AXMPGLOW'
S3LOWPTR='ADDRESS OF*STORAGE*LOW POOL*AREA'
S3LOWRQC='LOW*COMPRESS*DEFRAGMENTATION*ATTEMPTS'
S3LOWRQF='LOW GETS*FAILING*TO OBTAIN*STORAGE'
S3LOWRQG='LOW POOL*STORAGE*GET*REQUESTS'
S3LOWRQS='LOW POOL*STORAGE*FREE*REQUESTS'
S3LOWSIZ='SIZE OF*STORAGE*LOW POOL*AREA'
S3LOWUS ='USED PAGES*IN THE*STORAGE*LOW POOL'
-Formats MGCICDA, MGCICDT, and MGCICDP are created.
-Eight STIDs are no longer created in CICS TS 1.2, so
these datasets(STID) will have zero observations:
CICAUSS(22), CICDLIG(72), CICDLIR(70), CICDLIR(73)
CICDQR (43), CICDTB (33), CICIRCB(75), CICJCR (49).
The table of Dataset/STID/DSECT/etc. has been updated in
member ADOC110.
Change 15.273 MXG 15.05 only. Change 15.228 did not input the ACCOUNT
VMAC26J3 fields because IF SMF26IND='.......1........' THEN DO;
Nov 14, 1997 should have been IF SMF26IND='.......1........'B THEN DO;
the "B" at the end of the bit test was missing, so SAS
did a character comparison, which was never satisfied.
Additionally, JES3 sites must install APAR UW41108, or
you will get INPUT STATEMENT EXCEEDED RECORD LENGTH on
ID=26 record; without that APAR, the bit in SMF26IND was
turned on, but the data segment was not present! This
was for JES3 running with OS/390 Release 1.3.
Thanks to John Allender, National Computer Systems, USA.
Change 15.272 This Change was not implemented. A future change will
XUILD005 change hardcoded PIB. references to a global macro, and
XUIL3005 that will eliminate the need to keep WORK.STEPS.
Nov 14, 1997 The original text of the change was:
Nov 21, 1997 For ITSV, dataset WORK.STEPS is no longer deleted from
the //WORK library in these two "Phase-Five" members that
are used by ITSV and some smart users in place of the
"All Phases" members BUILDPDB/BUILDPD3. The ITSV product
needs the STEPS dataset to be kept in addition to the
"PDB.STEPS" dataset, and ITSV actually has been modifying
the MXG source code during execution to remove the PROC
DATASETS that deleted STEPS! By now leaving the STEPS
dataset in the work library, ITSV will no longer need to
modify the MXG source code. "STEPS" is first renamed to
"REALSTEP" where it was previously deleted (because the
SPUNJOBS member creates a dataset named STEPS so that the
macro _PDBSUMS can summarize PDB.JOBS and PDB.SPUNJOBS),
and after SPUNJOBS has been run, "REALSTEP" is then
renamed back to "STEPS".
I did not include this logic in the BUILDPDB/BUILDPD3
members that do all five phases in one step, because ITSV
does not use those members, and leaving the STEPS dataset
instead of deleting it requires somewhat more DASD space
in the work library. Sites that have created their own
PDB job using the "phase" members may want to add a
delete of the WORK.STEPS dataset after their include of
members BUILD005 or BUIL3005 if more members are included
subsequently in the same SAS step execution.
Thanks to Chris Weston, SAS Institute Cary, USA.
Change 15.271 Further consistency enhancements. All interval datasets
VMAC23 should have SYSTEM DURATM STARTIME (especially for ITSV)
VMAC24 and these didn't:
VMAC94 TYPE23 - STARTIME variable created and kept.
Nov 14, 1997 TYPE24 - SYSTEM variable kept.
TYPE94 - DURATM variable created and kept.
Thanks to Chris Weston, SAS Institute Cary, USA.
Change 15.270 OS/390 R2.4, Goal Mode Only. INVALID DATA FOR R723CIDT
VMAC7072 or R723CDQT error. The SMF Manual showed R723CTSA as
Nov 14, 1997 four-byte binary, but the DSECT shows it is eight-byte
floating point! Change PCTEXTSA &PIB.4. to &RB.8. and
three lines earlier change LENSCS GE 432 to GE 436 and
fourteen lines later change SKIP-48 to SKIP-52.
Thanks to Diane Eppestine, Southwestern Bell, USA.
Change 15.269 The eight-byte variable UOWTIME (created by INPUTing the
ADOCDB2 first six bytes of UOWID with PIB6.6 and then dividing by
ANALDB2C sixteen to convert time units into seconds) can have the
ANALDBTR same value for two unique values of the six-byte UOWID!
ASUMUOW Since UOWTIME is used to combine CICS MRO observations
IMACEXCL for the same unit-of-work, and is used to combine the
VMAC102 CICSTRAN and DB2ACCT data by unit-of-work, only members
VMAC110 that used UOWTIME (ANALDB2C,ANALDBTR, and ASUMUOW) were
VMACDB2 directly affected; the duplicate values lumped different
VMACDB2H units-of-work's transactions into one observation.
Nov 13, 1997
I had believed that any 6-byte field could be input,
converted, and stored with full resolution in a SAS
8-byte variable, but in an eight-byte floating point
non-integer, SAS can only store 15 digits on MVS and
only 14 digits on ASCII. In UOWTIME, it happens that
16 digits were required to resolve adjacent unitary
changes in the 6-byte UOWID value; one unit change in
UOWTIME is one third of a microsecond, so 8 digits are
needed for the seconds of DATETIME since 1960, and 7
fractional digits were not enough as shown in the table:
The table shows duplicate DIVIDED BY 16 values for the
different UOWID input values, and shows that adjacent
UOWID values could not be resolved:
UOWID 6-bytes INPUT PIB6.6 DIVIDED BY 16
(15 digits) (15 digits)
DDDDDDDDE100 243974979.816704 15246561.2385440
DDDDDDDDE101 243974979.816705 15246561.2385440
DDDDDDDDE102 243974979.816706 15246561.2385441
DDDDDDDDE103 243974979.816707 15246561.2385441
DDDDDDDDE104 243974979.816708 15246561.2385442
DDDDDDDDE105 243974979.816709 15246561.2385443
DDDDDDDDE106 243974979.816710 15246561.2385443
DDDDDDDDE107 243974979.816711 15246561.2385444
DDDDDDDDE108 243974979.816712 15246561.2385445
DDDDDDDDE109 243974979.816713 15246561.2385445
DDDDDDDDE10A 243974979.816714 15246561.2385446
This error wasn't seen earlier in "real" CICS systems
because UOWTIME was the real time of day when a real
transaction started, and real microseconds occurred
between successive events, so UOWTIME values resolved to
unique values for different units-of-work. But clients
like CICS/OS2 and AS/400 now send transactions into CICS,
and these originators store not a timestamp in UOWID,
but rather a counter value that is incremented for each
transaction, and as one counter unit is one third of a
microsecond, MXG's choice of storing the six-byte UOWID
token as an eight-byte datetimestamp is now proven to be
incorrect to resolve adjacent counter values.
The solution is to create a new 6-byte character variable
UOWIDCHR in both CICSTRAN and DB2ACCT datasets containing
the first six bytes of UOWID, and then to insert UOWIDCHR
after UOWTIME in each BY statement so BY NETSNAME UOWTIME
becomes BY NETSNAME UOWTIME UOWIDCHR to guarantee unique
instances are correctly merged. The logic in ASUMUOW was
revised to protect the SPIN library against a variable
UOWIDCHR NOT FOUND error.
Thanks to Carol Arnold, Brown Brothers Harriman & Co., USA.
Thanks to John Krall, Brown Brothers Harriman & Co., USA.
Change 15.268 The new IHDR110 "Type 110 Header Exit" member can be
IHDR110 used to select CICS records by APPLID or other fields,
VMAC110 since the exit is taken after the header of the CICS
Nov 13, 1997 record has been input. It can save lots of time if you
have lots of Test CICS Regions whose SMF data you want
recorded (for problem determination) but whose records
you do not want in your daily CICS PDBs, because you can
use IHDR110 to delete all records from your test regions.
See the IHDR110 member for the list of fields that exist
in the Subtype 0/1/2, for Journal/Transaction/Statistics.
Thanks to Chuck Hopf, MBNA, USA.
Change 15.267 Variable SMFRECNR was added to KEEP= list for TYPE90
VMAC90 dataset. See Technical note on Y2K Test System's SMF
Nov 13, 1997 data in MXG Technical Newsletter THIRTY-THREE.
Thanks to Carol Arnold, Brown Brothers Harriman & Co., USA.
Change 15.266 MXG 15.04-MXG 15.05. Current dates in CREATIME, STRTTIME
TYPETMON ENDTIME, UOWTIME, TIESDATE, and TIREDATE were wrong. The
Nov 6, 1997 three lines IF O LE YY LE 1959 THEN YY=YY+2000; should
have been IF 0 LE YY LE 59 THEN YY=YY+2000;
This error caused 1997 TMON dates to be in the year 2097.
Thanks to Colin J. Fester, Engen Petroleum, SOUTH AFRICA.
Change 15.265 NTSMF version 2.0.H caused INPUT STATEMENT EXCEEDED for
VMACNTSM the 0,0 (Discovery) record. The quick circumvention is
Nov 3, 1997 to replace STOPOVER with MISSOVER by using
MACRO STOPOVER MISSOVER % as the first statement, before
the %INCLUDE statement. The fix is contained in 15.06.
Thanks to Howard Glassetter, Weyerhaeuser, USA
Change 15.264 IDMS 10.02 observations were not OUTPUT in the IDMSTAS
VMACIDMS dataset; the statement IF '1201' LE SMFHVER LT '1400' ...
Nov 3, 1997 that is immediately before %INCLUDE SOURCLIB(EXIDMTAS);
must be changed to IF '1002' LE SMFHVER LT '1400' ... if
you still have records from archaic IDMS 10.02 release.
It is possible there will be no obs in IDMSBUF and INT,
with 10.02 as well.
Thanks to Jill Billings, First Data, USA.
Change 15.263 Support for Boole & Babbage MQ Series 1.1.4 MVMQS 1.2.0
EXBBMQBP VSAM file of statistics records adds 3 new MXG datasets:
EXBBMQPS RTIN MXG DATASET VARS DESCRIPTION
EXBBMQQM 'E1'x BBMQQMGR 125 Queue Manager Record
IMACBBMQ 'E2'x BBMQBUFF 96 MQ Buffer Pool Record
TYPEBBMQ 'E3'x BBMQPAGE 16 MQ Page Set Record
VMACBBMQ This Boole product is also called MainView for MQSeries,
Nov 2, 1997 and the MXG support reads their online historical files.
Change 15.262 Availability Analysis example using PROC CALENDAR and the
ANALAVAL PDB.SMFINTRV dataset (must be enabled in IMACINTV) is
Nov 1, 1997 provided in this nice user contribution.
Thanks to Rob Wunderlich, USS/POSCO Industries, USA.
Change 15.261 Cosmetic. APAR OW15518 is the IBM APAR that added the
YEAR2000 year 2000 support to all SMF-owned SMF records; the
Nov 1, 1997 member YEAR2000 incorrectly typo'ed OW16518.
Thanks to Don Friesen, B.C. Systems, CANADA.
Change 15.260 Cosmetic. Change @28 QWACRINV MGDB2RC16. to MGDB2RC15.
ANALDB2R and there will be a space between the reason and the
Nov 1, 1997 count of SELECTs and so it doesn't look overlaid.
Thanks to Bob Gauthier, American Stores Company, USA.
Change 15.259 Pairing DB2 type 102 59 and 63 records was wrong when
ANALDBTR there were multiple 63s due to lots of SQL text. The
Oct 31, 1997 correction is to only increment PAIRNR in the BEGIN63
logic IF QWHSSTCK NE OLDTME63 THEN PAIRNR+1; and add
OLDTME63 to the RETAIN and DROP statements, and to set
OLDTME63=QWHSSTCK; just before the OUTPUT statement.
This affected the S064058 file because PAIRNR was being
incremented by more than the one count MXG expected in
the IF HOLD63 AND HOLD64 logic block. This correction
was diagnosed and the fix coded by its discoverer.
Thanks to Ken Michalik, Kraft Foods, USA.
Change 15.258 Support for CICS APAR UN98309 (INCOMPATIBLE) which
IMACPTF adds new field RLSCPUT (MXG variables CPURLSTM and
VMAC110 CPURLSCN) to dataset CICSTRAN. You must update member
UTILCICS IMACPTF to enable macro _UN98309 if you install this
Oct 31, 1997 PTF, because there is no way to tell from the SMF
record that the PTF is installed. If you use any
of the "User" fields, or have any optional segments
(e.g., those created by Candle or Boole & Babbage)
those data will be wrong with this PTF until you both
install the MXG 15.06 or later version and update the
IMACPTF member. Sorry, but this is what happens when
IBM adds data to the type 110 transaction record without
changing version numbers (and there is no maintenance
level flag for them to update, either!).
MXG utility UTILCICS was updated and it will now detect
that APAR UN98309 has been installed on any of your CICS
regions; see its comments for instructions and output.
Thanks to Martin Peck, CA-IT/Capacity Management, GERMANY.
Change 15.257 Support for type 88 subtype 11 (System Logger Alter
EXTY8811 Structure) data creates new dataset TYPE8811.
IMAC88 Also, variable SMF88EDO is now input and created in
VMAC88 the TYPE88 dataset.
Oct 31, 1997
Thanks to Pat Quinnette, Principal Mutual Life Insurance, USA.
Change 15.256 OPC segmented type 29 records caused INPUT STATEMENT
VMACOPC EXCEEDED error; MXG only inputs the EQE control block
Oct 31, 1997 fields, which does not exist in the segmented records,
so now MXG verifies both the length and EQE eyecatcher
before decoding type 29 records.
Thanks to Randy Shumate, LEXIS-NEXIS, USA.
Change 15.255 Windows NT on a multiprocessor (two or more engines) was
NTINTRV not summarized correctly; each engine created a separate
Oct 30, 1997 observation in the NTINTRV dataset. This revision will
correct that MXG design error by summing INTPROR before
the merge and creating NRCPUS variable to count engines.
Most of the fields from the PROCESOR record exist in the
SYSTEM record, but the percentage values are slightly
different between the records. Variable ACPBYPAS in the
SYSTEM record appears to be half of the sum from the
PROCESOR records with two engines, so the (believed!)
more correct value from PROCESOR is used, rather than the
values from the SYSTEM record, by moving INTPROR to the
end of the MERGE statement (so its values will override
variables of the same name).
Change 15.254 Of no real impact, because adding zeros has none, but MXG
VMAC30 created additional observations in TYPE30_V/30_4/30_5 if
Oct 29, 1997 there were type 30 records containing only MULC or OMVS
segments. These observations had MULTIDD='Y', a flag
that this step record contained only EXCP segments, and
had zeroes for all resource variables, because resources
in the MULC (Measured Usage) and OMVS (Open Edition/MVS)
segments are output in TYPE30MU or TYPE30OM datasets.
Prior to MXG 15.05, when there was more than one multiple
record from a step, they were identical and MXG's NODUP
in PROC SORT deleted all but one. But Change 15.235 in
MXG 15.05 added variable EXTRMULC to be kept, and as its
value was not the same in each multiple record, MXG did
not delete any dupes, and comparison of MXG 15.03 and MXG
15.05 showed different messages on the SAS Log about
duplicates. While they were still zero and had no
impact, they should not have been output in the first
place. So MXG has now added a test
IF MULTIDD='Y' AND NUMDD=0 THEN DELETE;
so that only multiple records due to EXCP segments will
be output into the TYPE30_V/TYPE30_4/TYPE30_5 datasets.
In TYPE30MU dataset, INITTIME will be the job or step
initiate time for subtype 4 and 5 records, but it is now
set equal to INTBTIME in the subtype 2 and 3 interval
records so that duration of the interval can be known.
There can be multiple records created due to too many
ARMS (Automatic Restart) segments, but I have no data
with ARMS segments to investigate what I should do with
those records. Variable EXTRARMS will be nonzero if you
have ARMS segments causing multiple records, and it is
kept in TYPE30_V/_4/_5 datasets. In fact, only the data
in the first ARMS segment is actually input by MXG.
Thanks to Tom Elbert, John Alden Systems Company, USA.
Change 15.253 Text of Change 12.255 now points to revision in Change
CHANGESS 15.061, whose text was also revised to TYPE78CF rather
Oct 29, 1997 than TYPE74CF!
Thanks to Jack Fausti, EDS, USA.
Change 15.252 The example for pre-CICS 4.1 GMT protection should have
ADOC110 spelled STRTTIME instead of STTRTIME.
Oct 29, 1997
Thanks to Rey Marquez, General Accident, USA.
Change 15.251 The CICINTRV logic was still wrong after Changes 15.219
CICINTRV and 15.092. The first interval was dropped when it was
Oct 14, 1997 valid, the COLLTIME value was reset to the start time of
Oct 29, 1997 the interval, variable STARTIME was not propagated into
the PDB.CICINTRV dataset, and the HALFHOUR default value
for MACRO _CICINTV produced strange results in DSGCNT if
15 minute interval data was input. To correct the logic,
DURATM and STARTIME were added to the KEEP= list in the
one-per-interval datasets (i.e., the ones that are not
VMXGSUMed), the DROP of SMFSTRQT was removed (to help in
debugging), and the major logic changes were in both the
big MERGE step (to not drop first interval, and to create
STARTIME) and in the final VMXGSUM (which now uses the
STARTIME rather than COLLTIME to cluster records. This
has been tested with broken data (i.e., an interval with
only FCR (file close) records, which will happen when SMF
is dumped before the end of the interval) as well as with
USS/REQ/EOD records interleaved with INT records, and now
the data looks correct.
Note that an observation in PDB.CICINTRV with missing for
DURATM is a "broken data" interval in which only event
data was found, and STARTIME will equal COLLTIME since
there is no interval duration in the event records.
It was invalid values for DSGCNT (Current Nr of Tasks)
in Dan's reports that led to this revision, so I also
moved DSGCNT from the MEAN= list to the MAX= list as it
is more useful as the maximum number of current users
when multiple intervals are summarized than the average.
Sites with SAS IT Service Vision (ITSV) should install
MXG 15.06 or later if they want to use PDB.CICINTRV
table. With MXG 14.07 thru MXG 15.05, SAS ITSV will
generate a warning message because variable DATETIME
was not found in PDB.CICINTRV. You could delete the
statement DROP DATETIME in member CICINTRV in those
earlier versions and ITSV will populate its tables,
but only the MXG 15.06 version of member CICINTRV
creates a legitimate PDB.CICINTRV dataset.
This change did remove the DROP DATETIME; statement
that was added in MXG 14.07. Eventually, the variable
DATETIME will be deleted, because STARTIME is the name
that should be used, but both are now kept to protect
ITSV until it is updated to use STARTIME.
Early versions of VMXGSUM created variable DATETIME, but
that was not my intention; instead, the original named
variable (i.e., the one used in the DATETIME= argument)
is intended to be used for the summarized datetime value.
Thanks to Dan Gilbert, Bergen Brunswig, USA.
Thanks to Ken Whitehead, Bank of New York, USA.
Change 15.250 The test IF CPUTM NE CPU72TM in RMFINTRV that validates
RMFINTRV that the sum of your work definitions (CPU72TM) is equal
Oct 13, 1997 to the sum of real work (CPUTM, all non-report perfgrps
or service classes) was too strong. Truncation effects
caused fractional differences (1E-9) when totals really
were equal. In the worst case, with 1000 numbers summed
at .01 second resolution, if all lost the max of .001,
a maximum difference of 1 second could exist, so the test
was revised to report error only:
IF ABS(CPUTM-CPU72TM) GT 1 THEN DO;
This test only comes in to play if you have enabled
IMACWORK to use both control/report performance groups
or service/reporting classes to define workloads.
Thanks to David Ehresman, University of Louisville, USA.
Change 15.249 Support for NTSMF Version 2.1 Final Changes (INCOMPAT).
VMACNTSM In the final Beta Tests of NTSMF Version 2.1, we have
Oct 13, 1997 decided to make a structural change in the timestamps of
NTSMF records that can affect the NTINTRV dataset, so
now, MXG 15.06 (or at least Change 15.249) is required
for NTSMF Version 2.1. Prior versions are not affected.
Prior to 2.1, all NTSMF records for a interval had the
same SMFTIME timestamps and DURATM durations, because
only one call to the Registry for all objects was made.
A single call sometimes generated 300K bytes of data,
which the Registry did not handle well, but in using just
one call to the registry we got back every counter in
every object, and we had wanted to allow the collection
of only some counters in some objects.
So NTSMF 2.1 now will issue multiple calls (one per
object) so you can tailor which counters are collected.
But the multiple calls create records with slightly
different SMFTIME timestamps, varying by the milliseconds
it takes NTSMF to get from the first to the last object,
and since NTINTRV uses STARTIME=SMFTIME-DURATM to collect
all of the records for an interval, STARTIME would not be
constant for each interval, which would cause multiple
obs in dataset NTINTRV for each real interval.
That is the incompatibility which is eliminated by this
change. NTSMF 2.1 writes a configuration record with
OID=0, OBJECT=0 (which contains fields that used to be in
each record's header that were moved to this record as
part of 2.1's "reduced header" redesign to reduce data
volume, as well as configuration information). This 0,0
record is now written at the start of each call sequence,
its DURATM is the duration since the last call sequence,
and MXG now uses the 0,0 record's SMFTIME-DURATM as
the retained STARTIME value for all records until the
next 0,0 record is read. So STARTIME will be constant
for each interval, NTINTRV will be correct, and each
individual record's timestamps, SMFTIME, can be examined
to see how long it takes NTSMF to write a set of data!
- This change also creates variable PRODTYPE (Server/WS)
and DSCNAME (NTSMF data set collection that was used)
from the 0,0 configuration record.
Change 15.248 Support for Applied Expert System's Clever TCP/IP SMF
ADOCCTCP record creates two new datasets:
EXCTCPPR CTCPPERF - Clever TCP/IP Performance Statistics
EXCTCPWL CTCPWORK - Clever TC/IP Workload Statistics
IMACCTCP
TYPECTCP
VMACCTCP
Thanks to Chuck Hopf, MBNA, USA.
Change 15.247 Support for HP MeasureWare for Terra Data Operating
ADOCMWTE System creates six new datasets:
EXHPTEAP HPTEAPPL - HP-MWA TERRADATA APPLICATION RESOURCES
EXHPTECO HPTECONF HP-MWA TERRADATA CONFIGURATION
EXHPTEDS HPTEDSK HP-MWA TERRADATA DISK ACTIVITY FROM DISK
EXHPTEGL HPTEGLOB HP-MWA TERRADATA GLOBAL ACTIVITY
EXHPTELA HPTELANS HP-MWA TERRADATA LANS
EXHPTEPR HPTEPROC HP-MWA TERRADATA PROCESS RESOURCES
IMACHPTE The Report Macro for Terra Data extract is contained in
TYPEHPTE member ADOCMWTE.
VMACHPTE
Oct 13, 1997
Thanks to Alfred Holz, Medco Data Corporation, USA.
Change 15.246 When you used TYPEEREP to read the DASD (i.e. online)
ADOCEREP SYS1.LOGREC file, MXG read the entire file, all the way
IMACEREP to End-of-File, but the DASD file contains old records
VMACEREP that should not have been read. The first record of the
Oct 12, 1997 DASD file is a header record that contains the pointer
LASTTR to the last record written. IBM utilities CLEAR
SYS1.LOGREC by updating LASTTR and leave all the records
where they were. Now, MXG detects that there is a header
record and uses its LASTTR value to STOP the input from
SYS1.LOGREC after that logical end of file record. (If
you should ever want to read the entire DASD LOGREC file,
new macro _READALL in IMACEREP will let you change the
MXG default) Note that this was only a problem if you
read the DASD SYS1.LOGREC file; the dumped file contains
only the valid records, and there is no header record in
the dumped file, so MXG reads dumped data to end-of-file.
An old IBM reference, RTA000138425 dated 11/13/1996 has
more discussion, including pointing out that SYS1.LOGREC
and EREP may not necessarily point to the same file!
This MXG change only applies if you use TYPEEREP to read
the online, DASD, SYS1.LOGREC, as only it contains the
header record. If you were reading the dumped EREP data
records, on tape or DASD, there are no dead records nor
any header, and reading to end-of-file is what you want!
Thanks to Christophe Faure, ATOS Group, FRANCE.
Change 15.245 DB2 Type 102 Subtype (IFCID 140) INPUT STATEMENT EXCEEDED
VMAC102 error due to trashed record. The data thru QW0140UR is
Oct 11, 1997 valid for the Object-Type=Plan record, but the XL8 field
QW0140HO contains '40ffff4040404040'x, and QW0140LL has
'4000'x, (indicating 16,384 bytes of SQL text follows),
but QWT02R1L is only 82 bytes (and there are 9 bytes in
the segment following QW0140LL). It looks to me that the
QW0140HO field was filled with 9 bytes rather than 8, and
it overlaid the first byte of QW0140LL. MXG previously
added protection for this IFCID=140 record when there was
no SQL text in Change 15.216; this Change makes the line
IF QW0140LL GT 2 THEN
look like this:
IF QW0140LL GT 2 AND COL+QW0140LL-3 LE LENGTH THEN
The site will pursue the bad record with IBM.
Thanks to Mike Oujesky, MBNA, USA.
Change 15.244 New variable CPU72TM was formatted TIME12.2 before it was
RMFINTRV output, but was not formatted in the step in which it was
Oct 11, 1997 created and in which it was PUT in an error message, so
it is now FORMATed when created.
Thanks to David Ehresman, University of Louisville, USA.
Change 15.243 DFSORT APAR PN71337 added flag fields (Compatibly) which
VMAC16 are new variables in MXG TYPE16 dataset:
Oct 9, 1997 LOSMCNTR='LOCALE PROCESSING*SORT MERGE*CONTROL FIELD?'
LOIOCOMP='LOCALE PROCESSING*INCL OMIT*COMPARE FIELD?'
EQUALUSE='EQUALS*WAS USED*FOR SORT*OR MERGE?'
Change 15.242 Utility program to re-create SMF VBS data records from a
UVBSNRDW downloaded SMF file that had BDW and RDW stripped. If
Oct 9, 1997 you don't download correctly (see member SENDDATA), you
can end up with an SMF file of only records; the BDW/RDW
are removed when you download from a RECFM=VBS instead of
using the RECFM=U copy. This has happened enough times
that I wrote this utility to reconstruct the original SMF
record, adding the missing BDW (Block Descriptor Word)
and RDW (Record Descriptor Word). As written, the logic
only works for SMF records that have only one instance of
SYSTEM per record (DB2 and CICS qualify); it would need
to be extended for records like JES type 26 that has the
SYSTEM repeated in several places, but it worked so I was
able to reconstruct the problem in the site's SMF data,
and to discover their error had been previously fixed!
Change 15.241 MQ Series type 116 SMF record with blank for CICS Task Nr
VMAC116 caused INVALID DATA FOR QWHCTASK message. The input of
Oct 7, 1997 QWHCTASK was protected by adding the double questionmark:
QWHCTASK ?? &PD.4. to suppress the error message and the
hex dump of the record. QWHCTASK was input only if CICS
attach (QWHCATYP=1 in MQ Series), but MXG did not expect
records with blank values.
MQ Series SMF type 116 record questions answered by IBM:
1. I have SMF type 116 record subtype 0 with QWHCATYP=1
(CICS), but the Thread Cross Reference Data is all
blanks (i.e., the CICS "thread number" QWHCCTNO,
"transaction name" QWHCTRN, and the CICS "task number"
are hex 40's). The CPU time field is hex zeroes, as
are all of the GET/PUT counts.
MQSSeries System Management Guide for Version 1.1.4
SC33-0806-04 page 343 discusses that there may be up
to 9 records containing zero CPU time. Do the blank
values in the CICS fields only occur in these records
with zero CPU time, and is a record with zero CPU time
always going to have blanks for the CICS fields, or is
the zero CPU and the blank CICS fields unrelated
conditions. Aren't blanks an error?
IBM ANSWER: Regarding records with zero cpu time on
CICS adapter related records, the null
records relate to the main CICS TCB and
8 MQ-related CICS TCBs. Depending on the
activity in the queue manager, these null
records will be written.
2. There is a third, undocumented self-defining section
in type 116 records that contains non-zero values,
including two TODSTAMP fields. The Offset of the
triplet is 36 decimal, and the note in Table 25 states
"other self-defining sections refer to data for IBM
use only". However, the data values may be of
significant value to our customers but I need
confirmation of their meaning, as well as the other
fields in the undocumented section:
- The two TOD stamp fields at the beginning of the
section look to be a start time and an endtime, and
as there is no other start time in the record, it
should be kept to measure event duration.
- The end timestamp has more resolution than the .01
seconds to which the SMF record timestamp is
truncated. Additionally, there is yet another
undocumented TODSTAMP field in the record, in the
Message Manager Accounting record QWHS section, as
the first eight bytes of the reserved field at
decimal offset 16, and this is also an ending
timestamp, but it is 26 microseconds later than the
ending timestamp in the undocumented section, so it
is clearly the timestamp of a third event.
Start Time in Undefined Section 05OCT97:04:15:42.970238
SMF Record time stamp 05OCT97:12:50:25.43
End Time in Undefined Section 05OCT97:12:50:25.438630
Reserved Time in QWHS Section 05OCT97:12:50:25.438656
By understanding what events are being timestamped,
the delta-time between them can often be used to
characterize short term problems and long term trends,
so I request information as to their meaning. In
addition, there are a number of fields in the
undocumented section that are non-zero; since they
exist in the site's SMF record, knowing what they
count so that they can be decoded would help our
mutual customers to better measure their MQ Series
systems.
The sample 116 record in SC33-0806-04 on pp 344-346 has
similar data, with SMF time of 29MAR94:16:43:15.17, its
start at 16:43:13.500017, and its two end times are at
16:43:15.174748 and 16:43:15.175460, for a delta of 712
microsec! What is happening during that delta duration?
I am aware that while the SMF time stamp is on the local
clock, all three undocumented TOD stamps are on the GMT
clock. The delta between SMF time and the end time will
let me discover the GMT offset to convert to local for
comparison with other SMF data records from CICS IMS,
etc.
IBM ANSWER: The additional data is not strictly just
for IBM use; it's just that the additional
data is not used for any purpose by MQ.
Part of this core code for MQ is based on
DB2, and while MQ cannot guarantee any of
the information in the additional section,
the layouts for DB2 Accounting Data may
indicate the contents of this section.
BARRY's STATUS: If you want to look deeply into MQ Series
with type 116 records, send me some data
records and I will decode the extra data
segment to see if it really is useful.
Thanks to Ken Whitehead, The Bank of New York, USA.
Change 15.240 Variables that had duplicate entries in LABEL statements
several were removed from members VMAC42, VMAC7072, VMAC79,
Oct 4, 1997 VMAC80A, VMAC99, VMACICE, VMACMWUX, and VMACXPSM. These
caused no error, but should not have been repeated.
Thanks to Freddie Arie, Lone Star Gas, USA.
Change 15.239 New variable LASTVOFL "IS THIS*THE*LAST*VOLUME?" is added
VMAC1415 to dataset TYPE1415 to flag whether an individual 14/15
Oct 4, 1997 record is the last volume, by decoding '40'x in RECIND1.
See Change 15.304.
======Changes thru 15.238 were in MXG 15.05 dated Oct 2, 1997======
Change 15.238 "ERROR. NEGATIVE CPU-UNCAPTURED-TIME (TYPE70-TYPE72)" is
RMFINTRV printed by RMFINTRV when MXG detects bad CPU time values
Oct 2, 1997 in type 72 records. Back in 1992, IBM APAR OY51878 found
bad values in CPURCTTM (SMF72RCT), and now APAR OW28256
reports bad values again! When CPURCTTM is corrupted,
CPUOVHTM (actually the "Uncaptured CPU Time" rather than
overhead) becomes negative because the total CPU in type
72 records exceeds CPU Active time for the box! This is
because MXG includes CPURCTTM in CPUTM in building the
TYPE72/TYPE72GO datasets, and in RMFINTRV calculations.
You can correct this error in advance by inserting in the
EXTY72/EXTY72GO exit members:
CPUTM=CPUTM-CPURCTTM;
so that TYPE72/TYPE72GO and RMFINTRV will not include the
CPURCTTM (Region Control Task, mostly TSO Quiesce/Resore)
in the total CPU time captured, and then remove this
workaround when you install the PTF for the APAR OW28256.
Note: for Boole's CMF, APAR BPM6782 is reportedly also a
requirement. 29May98.
Thanks to Thomas Heitlinger, FIDUCIA, GERMANY.
Change 15.237 Support for BETA93 Release 3.1.3 (INCOMPATIBLE) inserted
VMACBETA fields in the header, and changed the length of many of
Oct 2, 1997 the fields. Unfortunately, I only received subtype 21
records, so only that subtype is supported in MXG 15.05.
In fact, all other subtype will produce a hex dump of the
first record of each unsupported subtype and prints an
MXG message to please send that dump to me so I can add
support for those subtypes. (If the BETA93 vendor had
documented their alignment bytes in their DSECT, I could
have delivered the code for all subtypes, but the subtype
21 record proved their documentation is inadequate. I
presume that since only the subtype 21 records were sent,
that that is the most important record for BETA92, and I
hope this change will get you through the nite!).
Thanks to Manfred Thomas, BHF-Bank, GERMANY.
Change 15.236 DFHSTUP-like CICS Shutdown Reports have been enhanced to
ANALCISH match new IBM reports, but not all reports were finished
Oct 2, 1997 in time for MXG 15.05 (notably, CICFCR). See notes in
the member for additional status.
Thanks to Steve Colio, CIGNA, USA.
Change 15.235 Duplicate step records might not be deleted by SAS NODUP
BUILDPDB option, but only for steps with more than one physical 30
BUILDPD3 record for a step (eg., steps with many DD segments, aka
BUILD005 MULTIDD='Y' steps). The sort order for TYPE30_4 did not
BUIL3005 include MULTIDD EXTRADD variables, and if the multiple 30
VMAC30 records had exactly the same TERMTIME, the sort did not
Oct 2, 1997 place them adjacent, and the NODUP only deletes duplicate
records that are adjacent. The correction is to change
the BY list for PROC SORT NODUP DATE=TYPE30_4 ... ;
to BY READTIME JOB JESNR TERMTIME MULTIDD EXTRADD;
Of course, if you never have duplicate SMF data
(which can ONLY happen when a failure in SMF dump
AND an incorrect human recovery occurs) you will
not have cause for concern!
The impact was that two observations were created in
PDB.STEPS, and the job's CPU time was doubled.
-Variables EXTRARMS, EXTRMULC, and EXTROMVS are now kept
in the TYPE30_V and TYPE30_4 records, as they may be
needed for additional protection.
-Member ADOC30 has been updated with a discussion of the
existence of multiple step records that was written in
reply to a request from IBM to review SMF documentation
on how to know whether a physical step record was the
first, last, or in-between record for a step terminate.
Thanks to Steve Donahue, Blue Cross and Blue Shield of Texas, USA.
Change 15.234 Support for TCP/IP 3.2 API Calls SMF record increased the
VMACTCP length of the API Call record (on which MXG depends to
Oct 01, 1997 sort out API from FTP from TELNET), relocated APIJOBNM,
and added new variables APIJOBID (JCTJOBID) and APISTART
(JES Start Time) for HPNS applications (where the HPNS
enabled interfaces are
- C sockets API (including C sockets for CICS)
- Sockets Extended APIs:
- Macro Interface
- Call Instruction Interface, including Call Instr
for CICS and IMS).
Thanks to Harmut Richter, BASF Computer Services GmbH, GERMANY.
Change 15.233 The discussion of documentation of MXG Software, the
DOCUMENT MXG books, etc., is now contained in member DOCUMENT.
Sep 30, 1997 There are several "tables of contents" of ACHAPxxx and
ADOCxxx members (this consolidates and enhances the old
"Online Documentation" section of member CHANGES).
Change 15.232 Enhancements to process EASMON/EASMAP data from VM/ESA
EXXAMSYT were contributed to add new XAMSYT and XAMSYU datasets,
EXXAMSYU and to correct "IF SKIP GE 20... SKIP=SKIP-20;" before
IMACXAM the INPUT TCMXIDSZ to ..GE 16 ...SKIP-16" so that the
VMACXAM fields are actually input. Datasets XAMSYT and XAMSYU
Sep 30, 1997 report LPAR dispatch and management time from VM/ESA.
Thanks to Anthony P. Lobley, EDS, ENGLAND.
Change 15.231 Deaccumulation of the NPMINPMT dataset in member DIFF28
DIFF28 (added by Change 15.206) now creates variable DURATM
Sep 30, 1997 instead of DELTATM, and creates variable STARTIME to
be consistent with other interval datasets.
Thanks to Chris Weston, SAS Institute Cary, USA.
Change 15.230 VLF Activity for CATALOGs can be generated in SYSLOG
TYPEVLFC with the F CATALOG,REPORT,VLF command that creates the
Sep 30, 1997 messages IEC359I. This program will read //SYSLOG and
create dataset PDBVLFC.VLFCATLG from those reports and
also trends the new and old reports in PDBVLFC.TRNDVLFC.
Note that the report values are cumulative: the command
must have been issued at least twice to produce data.
Thanks to Chuck Hopf, MBNA, USA.
Change 15.229 These IMS Log Processing Assembly programs were revised
ASMIMSLG in MXG 14.07, but the revisions did not support archaic
ASMIMSL5 pre-DFP 3.0 systems, and there was at least one MXG site
Sep 30, 1997 at that level that encountered an 0C4, so the programs
were revised to support the earlier QSAM level.
Thanks to Skip Abadie, MBNA, USA.
Change 15.228 IBM APAR OW26297 for JES3 add a new triplet section and
VMAC26J3 Job Account fields at the end of the purge record (though
Sep 30, 1997 the original APAR text made it look like it was inserted
in the middle of the record, it was in fact added at the
end). There was already a 42-byte accounting field in
the JES3 purge record, but IBM added the new section to
support all Job accounting fields. MXG previously used
the 42-byte field to decode only variable ACCOUNT1, but
with the new section, MXG will decode ACCOUNT1-ACCOUNTn
(where the number of fields kept is set in your IMACACCT
tailoring member). All of this is relatively unimportant
since MXG needs the Purge record account fields only for
jobs that did not initiate (i.e., JCL errors or cancel
before execution); account fields are normally taken from
the type 30 records.
Change 15.227 IBM APAR OW16975, reported in MXG Newsletter THIRTY-TWO,
VMAC30 is in error, and when installed causes APPC-using flushed
Sep 30, 1997 steps to fill your log with hex dumps, and causes MXG to
Dec 13, 1997 delete those step records. The APPC section was removed
by the APAR, but the triplet values were not zeroed.
This circumvention will print only one instance message
on the log, will skip the non-existent APPC section, but
will then output the type 30 record, and when the APAR
error is fixed, the circumvention will be passive.
Dec 13 update: APAR OW30802 is the new fixing APAR that
will make this circumvention passive.
Thanks to Bill Shanks, BR Business Systems, ENGLAND.
Change 15.226 Support for APAR XXnnnnn, which increases the number of
ANALRMFR structures in a Coupling Facility from 64 to 255. The
VMAC74 SUBSCRIPT OUT OF RANGE error will occur if you install
Sep 29, 1997 the PTF without this change. This change also eliminates
four sets of variables QSTR01-QSTR64, QSIZ01-QSIZ64,
QFLG01-QFLG64, and QVER01-QVER64 from dataset TYPE74CF.
That information was already stored in TYPE74ST dataset,
which has one observation per structure, and those fields
should not have been kept in TYPE74CF anyhow!
Reports in ANALRMFR have not been updated for more than
64 structures, and Total Size of Structures Allocated
value will be missing until the CF Reports are revised.
This change also corrected INPUT STATEMENT EXCEEDED error
with type 74 subtype 4 records with NRTRIPLT=8.
There is still an open problem with IBM for this APAR, as
pointer R744CDSI is sometimes wrong, pointing beyond the
end of the data record; MXG now conditionally inputs the
R744CDSI extension fields, pending a fix from IBM.
Thanks to Dennis Pugh, BMC Software, USA.
Change 15.225 This report for Cached DASD Controllers now will use the
ANALCACH PDB.TYPE74CA and/or PDB.CACHE90 dataset, and will not
Sep 26, 1997 fail if either dataset does not exist. (TYPE74CA has
replaced the old CACHE90 dataset created from CRR.)
Thanks to David Ehresman, University of Louisville, USA.
Change 15.224 Variable TAPEBYTE was not in the KEEPIN= LIST, causing
DAILYDSN variable SPACE5 (Non-HSM Tape) to be missing and causing
Sep 26, 1997 UNINITIALIZED VARIABLE TAPEBYTE message on the log. The
DAILYDSN program is used in JCLDAYDS example to measure
the size of all of your datasets (DASD/TAPE/HSM) using
DCOLLECT, CA-1, and HSM records.
Thanks to Robert Miles Standish, Dean Witter Trust Company, USA.
Change 15.223 Some reports may have timestamps shifted right two bytes,
ANALDB2R causing Authid to be overlaid. I changed DATETIME16. to
Sep 26, 1997 DATETIME18. expecting to show all four digits of year,
but did not check to see there was space on the line for
the two extra positions. (Worse, DATETIME18 does not
print the four digit year, it justs shifts right and then
prints two digits of year!). Therefore, change all of
the occurrences of DATETIME18. to DATETIME16. (Note the
datetimes printed at the top of the page use DATETIME21.2
so you will see the four digit year on each page!)
Thanks to Brian Hawthorne, Mutual of New York, USA.
Change 15.222 MXG 15.04 only. Catalog Cell 'E7' in TYPE6156 record had
VMAC6156 INPUT STATEMENT EXCEEDED error, because Change 15.166 was
Sep 25, 1997 not correct. In the block ELSE IF CLTYPE='E7'X THEN DO;
delete these two lines after the INPUT statement:
ALICELN &PIB.2. /*LENGTH OF ALIAS INCLUDING ITSELF*/
ALITYPE $EBCDIC1.
and then change ALIRESV $EBCDIC1. to ALIRESV $EBCDIC2.
Thanks to Lawrence Jermyn, Fidelity Systems Company, USA.
Change 15.221 The new ASUMUOW in MXG 15.04 fails with LIBNAME TEMP01
ASUMUOW not found. Test code that should have been removed had
IMACUOW the specific reference. You can change TEMP01.CICSTRAN
Sep 24, 1997 to CICSTRAN in both places to circumvent. However, this
revision changes the MXG defaults so that
PDB.ASUMUOW will always have zero observations, until
you enable it in member IMACUOW.
I create dataset PDB.ASUMUOW by default in JCLPDB6, but
the default sets OPTIONS OBS=0 at the beginning and then
resets OBS back to the original value (using VMXGOPTR) at
the end of member ASUMUOW, so no data will be sorted or
merged until you turn it on. I really think that large
CICS and DB2 shops will find PDB.ASUMUOW better than its
predecessor PDB.CICS, but it can use lots of CPU & DASD,
so I think it safer to make you enable it. In addition,
IMACUOW now externalizes the output of the PROC SORTs so
you can send them to tape and save DASD space as well.
The options are documented in comments in both members.
Thanks to Mike O'Brien, McKesson General Medical, USA.
Change 15.220 -Support for NTSMF Version 2.1, COMPATIBLE with 15.03 or
EXNTCNRS later (MXG 15.03 was required for NTSMF Version 2.0).
IMACNTSM -Support for new Object 'Content Replication Service' adds
VMACNTSM creation of new dataset CONTRPSV.
Sep 26, 1997 -Existing dataset CONTNFI (Content Index Filter) has been
validated with data, with new CNFINAME instance.
-Existing CONTINDX (Content Index) has been validated with
data, with new CNINNAME instance.
-Existing IMAGE (Image) has been validated with data, with
two instance variables IMAGNAME and IMAGFILE.
-Existing MSEXCHMS (MSExchangeMSIM) object is validated,
and will have observations (if you change the misspelling
in IF UPCASE(OBJECT)='MXEXCHANGEMSIM' from MXEX.... to
MSEX...., even earlier versions of MXG will have obs!).
-Many new variables in CMPQxxxx datasets (from COMPAQ)
were not in the INFORMAT statement, which would cause
their values to be off by a factor or 100.
-The _BNTxxxx macros were not defined for all datasets,
and not all datasets were in the _SRTPRNL and _SRTPRNV
print macros.
-Member ADOCNTSM's list of datasets and Instance Variables
has been updated to include recently added objects.
-Variables CPUNUM1, FAMILY1, and MANUFAC1 and CPUSPED1 are
now decoded from the "0.0 configuration record" (new in
NTSMF 2.1).
-The location of the calculation of SMFTIME was relocated
so it does not generate "MISSING VALUES" message with 2.1
data; the value was re-calculated later and was never
actually missing.
Thanks to Jim Quigley, Con Edison, USA.
Thanks to Carmen Vitullo, Boeing, USA.
Change 15.219 -In CICINTRV, variables DSGAMXTL, DSGICVSD, DSGICVT, and
CICINTRV DSGTL are static values and should not have been DIF()
VMAC110 (as was DSGTL), and should not have been in SUM= nor
Sep 22, 1997 MEAN= statements, and are now in the ID= statement.
In spite of their mis-location, most of the time they
yielded correct values, so the error was overlooked.
(Note DSGTL only existed in CICS 3.3 and earlier)
-In VMAC110, the new A04 variables in the INPUT statement
begining with A04RDINT were all incorrectly labeled, and
the two time durations, A04RDINT and A04RDIDL had wrong
values with no TIME12.2 format.
-The SKIP=SKIP-220 for archaic CICS 3.1.0 if there were no
index segments and its INPUT +220 were changed to 218, to
suppress an "UNEXPECTED DATA" message that, while
harmless, could be eliminated.
Thanks to Dan Gilbert, Bergen Brunswig, USA.
Change 15.218 Support for CA's IDMS 14.0 (INCOMPATIBLE) splits existing
EXIDMDGB subtypes 1 and 16, adds new subtype 16 for new dataset
IMACIDMS IDMSDBG, and adds variables to IDMSBUF, IDMSINT, IDMSRUS,
VMACIDMS IDMSTAS, and IMDSTAW.
Sep 22, 1997
Thanks to Terry Heim, ECOLAB, USA.
Thanks to Martin Wieland, Neckermann B.V., THE NETHERLANDS.
Change 15.217 The default SMF ID in all IMAC members is intended to be
IMACDALO the impossible value of 512 (so that JCLTEST6 does not
IMACENDV try to read the wrong record type), but these three IMAC
IMACSVCC members had values left over from testing; all are now
Sep 20, 1997 set to the 512 default value.
Thanks to Chuck Hopf, MBNA, USA.
Change 15.216 DB2 Trace SMF type 102 Subtype 140 INPUT STATEMENT
VMAC102 EXCEEDED if there was no SQL text in the Audit record.
Sep 19, 1997 between NRSQLSEG=CEIL(( .... and DO SEGSQLT=1...
insert IF QW0140LL GE 2 THEN
so that the loop is only executed when there's text.
Thanks to Chuck Hopf, MBNA, USA.
Change 15.215 IXFP records, MXG 15.02-MXG 15.04 only. A line was
VMACICE dropped by change 15.134, causing zero observations
Sep 16, 1997 for subtypes 2, 3, and 4 (datasets ICEBRGCH,DV,DR).
In the DO group for subtypes 1 thru 4, between the
INPUT of ICEVERS and COLLID, insert a line with +2
to skip over the two reserved bytes that were dropped
when ICEVERS's input was added by Change 15.133.
Thanks to Angela Mulcahey, Summit Bank, USA.
Change 15.214 MXG 15.01-MXG 15.04. Variable PCTMVSBY in TYPE70 is
ACHAP10 wrong. The new algorithm used by MXG in Change 15.023
VMAC7072 should only have been used for Wait Completion = Yes,
Sep 16, 1997 and although I think it is a better way to look at the
Sep 20, 1997 MVS busy time for WC=Yes, I decided to revert back to
match IBM's number while I do more research on the whole
subject of PR/SM, MDF, and MLPF instrumentation.
-Member ACHAP10, the MXG Chapter on Processor Utilization
has been revised to describe how PR/SM, MDF, and MLPF
can be measured, and includes description of how IBM
calculates PCTCPUBY and PCTMVSBY and PCTLnBY on their RMF
CPU Activity and Partition Data Reports. Numeric values
for Dedicated, Shared Wait=Yes, and Shared Wait=No LCPUs
are now provided. This article will be in the next MXG
Technical Newsletter and was posted to MXG-L Listserv.
-The test IF CPUWAIT GT 0 THEN DO; ... END; was removed
because CPUEFFTM and PCTMVSBY/PCTCPUBY were missing if an
LPAR was 100% busy in all LCPUS (the case noted was a
single LPAR); the test was unneeded because the block of
code is already inside the LPAR processing section.
-Calculation of PCTCPUBY and PCTMVSBY in TYPE70PR dataset
is made only in the TYPE70PR observation for the LPAR in
which that MVS System executed, because only that LPAR's
TYPE70PR observations knows what ORIGWAIT, the MVS Wait
time, was recorded for that LPAR's LCPUs. They will be
missing in TYPE70PR observations for other LPARs in that
type 70 record.
-Added variable NEWWAIT to TYPE70PR. NEWWAIT contains
the "wait" time that was actually added to CPUWAIT for
the calculation of CPUACTTM=CPUUPTM-CPUWAITM and for
the calculation of PCTCPUBY in TYPE70 dataset. This new
field may be useful to some sites with Dedicated or
Wait Completion=Yes to match some RMF calculations.
Thanks to Carl Downing, Blue Cross Blue Shield of Minnesota, USA.
Thanks to Jan Tits, Amdahl, BELGIUM.
Change 15.213 Support for type 91 SMF record new subtype 21, written by
EXTY9121 SMARTBATCH at data set close for each VSAM or non-VSAM
IMAC91 data set processed by the Data Accelerator component.
VMAC91 New MXG dataset TYPE9121 contains a wealth of statistics
Sep 12, 1997 and activity information for this new component.
Took real vacation to celebrate Judy and her twin's 50th birthday!
Change 15.212 Values for R744SSIZ (Structure Size) are now in 4096 byte
VMAC74 units, rather than the 4000 byte unit discussed in Change
Sep 3, 1997 14.328, probably beginning with OS/390 Release 1.2, so
the three lines multiplied by 4000 are now by 4096.
Note that R744SSIZ rather than R744QSIZ is used by RMF in
its reports as the allocated structure size.
Thanks to Tim VanderHoek, Fidelity Systems Company, USA.
Change 15.211 Candle's CL-Supersession PTF QLG1073 (Y2K support) sets
VMACNAF a value of yyyydddF (instead of 0cyydddF) for SMFSTAMP8
Sep 4, 1997 fields, causing 1997 dates to be in year 3897! While
Sep 26, 1997 Candle's choice is not illegal, SAS's SMFSTAMP8 informat
expected IBM's documented century-bit format, so it used
that first byte as the number of centuries after 1900.
While SAS has agreed to change their SMFSTAMP8 format to
support both yyyydddF and 0cyydddF formats, that fix
won't be available on all platforms until next year,
and as Candle's PTF creates the problem today, all 15
internal timestamps in VMACNAF are now protected by:
CENT=FLOOR(YEAR(DATEPART(datetime))/100);
IF CENT GE 38 THEN
datetime=datetime-59958230400+(CENT-38)*86400;
(The SMFTIME field in byte 3 of Candle's record was
not changed by their PTF, so it needed no protection!)
Update 26Sep97: Candle now says that if you put all of
these PTFs on: QLS1303,1304,1305,1306,1307,1308,1310 and
QLV1465, that their dates will conform to IBM's use of
the century bit.
Thanks to Joseph Faska, Depository Trust Company, USA.
Change 15.210 Replaced by Change 15.218.
Change 15.209 MXG 15.04 only. TRNDTALO fails if TREND.TRNDTALO does
TRNDTALO not exist in your TREND library. Add the statement
Sep 2, 1997 OPTIONS NODSNFERR NOVNFERR; at the beginning of the
member to correct. Note that if you were previously
creating the TRNDTALO member, the new code did not
fail, so only first-time users of TRNDTALO got hit.
Note also that TRNDTALO requires that ASUMTALO be in
your WEEK library, so you will need to update your
WEEKBLD to propagate ASUMTALO before you can use the
trending in TRNDTALO.
Change 15.208 Cosmetic: comments /* _Lxxyyyy OUTPUTS TYPExxxx */
EXVMADSM are after each %INCLUDE SOURCLIB(EXxxyyyy); statement
VMACNTSM name the default MXG dataset for each _Lxxyyyy macro, to
VMAC80A make the MXG source code documentation, but seven new
VMAC99 datasets had wrong names or no comment. I block copy and
VMACSVCC revise when I can, but sometimes I overlook the comments.
Aug 31, 1997 But Freddie's sophisticated analysis of my source code
uncovered seven inconsistencies in MXG 15.04, and I plan
to add his QA to my QA before I build the next version!
Thanks to Freddie Arie, Lone Star Gas, USA.
Change 15.207 CA-1/TMS 5.2 Change 15.199 had one incorrect new variable
VMACTMS5 DEFEXPOO. The second occurrence in the KEEP, LABEL, and
Aug 30, 1997 assignment should have been NRESTAPE.
Thanks to Freddie Arie, Lone Star Gas, USA.
===Changes thru 15.206 were included in MXG 15.04 dated Sep 01, 1997===
===Changes thru 15.206 were published in MXG NEWSLETTER THIRTY-TWO=====
Change 15.206 NPM dataset NPMINPMT contained accumulated fields that
DIFF28 were deaccumulated inside VMAC28, but when SMF data was
TYPE28 sorted before MXG processing, wrong results occurred!
VMAC28 In addition, not all variables were deaccumulated that
Aug 28, 1997 should have been. This change adds new member DIFF28
that externally and correctly deaccumulates NPMINPMT.
DIFF28 is included by member TYPE28, but if you have
added type 28 processing to your BUILDPDB, then you must
add the statement %INCLUDE SOURCLIB(DIFF28);
in member EXPDBOUT to properly deaccumulate NPMINPMT.
Thanks to Steve Donahue, Blue Cross and Blue Shield of Texas, USA.
Change 15.205 Alternative CICS Summarization, especially for MRO.
ANALUOW -Member ASUMUOW combines all of the pieces of CICS MRO
ASUMCICX transaction (i.e., TOR, AOR, and FOR records for the
ASUMUOW same Unit-of-Work are combined, and the correct TRANNAME
IMACCICS is picked up), and (if the transaction called DB2) also
TRNDCICX merges in all of the DB2ACCT records to create dataset
Aug 28, 1997 PDB.ASUMUOW that gives a complete picture of each CICS
unit-of-work. This revision to ASUMUOW adds CICS wait
durations/counts to PDB.ASUMUOW so you can determine the
cause of poor CICS reponse time.
-Member ANALUOW is a parameter driven report to examine
why CICS transactions were delayed, using PDB.ASUMUOW.
-Member ASUMCICX is an alternative summary member, like
ASUMCICS to create dataset PDB.CICS, but member ASUMCICX
will use dataset PDB.ASUMUOW as its input, and also keeps
the wait durations/counts.
-Member TRNDCICX is an alternative trending member, like
TRNDCICS, but it keeps the wait durations/counts.
If you have CICS MRO and/or CICS talking to DB2, you
should change the %INCLUDE SOURCLIB(ASUMCICS) in your
BUILDPDB job to %INCLUDE SOURCLIB(ASUMUOW,ASUMCICX) so as
to build both PDB.ASUMUOW and the enhanced PDB.CICS.
The JCLPDB6 example has been updated to build both.
The example macro _KCICTRN in member IMACCICS that keeps
only the variables needed by ASUMCICS has been revised
to keep the original ASUMCICS set or the new ASUMCICX
set of variables, to reduce the size of CICSTRAN.
Thanks to Chuck Hopf, MBNA, USA.
Change 15.204 Tape Capacity Planning graphs based on TREND database
GRAFTAPE and MXG ASMTAPES tape allocation and trending records,
Aug 27, 1997 and also the HSC and LSM data from an STK silo.
If you saw Chuck's paper at CMG94, this is the code that
generated those graphs.
Thanks to Chuck Hopf, MBNA, USA.
Change 15.203 Trending of NTSMF's NTINTRV dataset creates summarized
TRNDNTIN TREND.TRNDNTIM for long term trending of NTSMF systems
Aug 27, 1997 with minimal storage required.
Thanks to Chuck Hopf, MBNA, USA.
Change 15.202 Enhanced measurement of Tape Allocation uses the Interval
TRNDTALO Allocation record created by ASMTAPES at ML-13, MXG 15.02
Aug 27, 1997 or later, so you must have installed ML-13 before you can
use this enhancement. The interval record eliminates any
undercounting of devices still allocated and improves the
accuracy of tape allocation counting.
TRNDTALO assumes you have created WEEK.ASUMTALO in your
WEEKBLD/WEEKBLDT member from your daily PDB.ASUMTALO data
sets; you will need to add the data step in your weekly.
Thanks to Chuck Hopf, MBNA, USA.
Change 15.201 Related members in a way.
ASUMCACH ASUMCACH creates the union of the TYPE74_1 and TYPE74_5
ANALEMC data (device level and cache reporter). This is useful
EMCRANK in figuring out problems in the IO subsystem but it will
EMCMAP also be part of the "I/O Stimulator" that will generate
Aug 27, 1997 control cards for Stress Test based on your RMF data.
ANALEMC takes the ASUMCACH data and carries it a step
closer to the hardware by using a series of formats to
map the logical to the physical in an EMC world. It will
also do this for Spectris and HDS 7700 boxes but no
formats are required. It creates datasets RANK, RAIDVOL,
EMCMAP, and VOLUMES. Each is a slightly different level
of summarization except for EMCMAP which is used to apply
labels to graphs with the annotate facility of SAS/GRAPH.
EMCRANK and EMCMAP use the output of ANALEMC to build
graphs of the performance of EMC boxes. This is a grid
8*12 where each box represents on physical SCSI disk
on the inside of the box. Each box contains the VOLSER,
RANK, and DEVNR of the logical MVS volumes and EMCRANK
applies colors to represent IO rates. EMCMAP leaves all
of the boxes empty of everything except text to make the
text a little easier to read. Find the line that says if
text=:'EM' then color='ORANGE'; This is used to alter the
color of the text. In this code, volumes that contain no
data start with EM in the VOLSER. Making those volumes
ORANGE makes them stand out and is a quick visual
indicator of available capacity.
Thanks to Chuck Hopf, MBNA, USA.
Change 15.200 Support for Peregrine's Service Center SMF record creates
EXTYSVCC new dataset TYPESVCC with one set of variables and two
IMACSVCC subtypes, which can be identified by variable SVCCTYPE:
TYPESVCC SVCCTYPE Description
VMACSVCC 1 Service Center Statistics
Aug 27, 1997 2 Service Center User Termination
Thanks to Chuck Hopf, MBNA, USA.
Change 15.199 Support for CA-1 aka TMS Release 5.2 (COMPATIBLE) adds
TYPETMS5 new flag variables to both DSNB and Volume records:
VMACTMS5 Dataset TMSREC:
Aug 25, 1997 Variable Description
ADDLFILS='ADDITIONAL*FILES*EXIST IN*VOLSET?'
COPYCAT ='CREATED*BY*COPYCAT?'
DEFEXPOO='DEFAULT*EXPDT*USED AT OPEN*OUTPUT?'
DEFEXPOO='NON*RESIDENT*TAPE?'
DEGAUSSD='TAPE*HAS BEEN*DEGAUSSED?'
EMVREL ='RELEASED*BY EXTERNAL VAULT*MANAGER?'
ERASEREQ='DATASET*ERASE*REQUIRED?'
FILEISCA='FILE*ON OS*CATALOG?'
SMSEXPIR='EXPIRED*BY SMS*MAX RETENTION?'
VAULTREQ='VAULT*SPECIFIC*REQUEST?'
VOLACTV ='ACTUAL*VOLSER*IN USE?'
Dataset DSNBREC:
Variable Description
DSNBABND='CLOSED* BY ABEND*PROCESS?'
DSNBDFXU='DEFAULT*EXPDT*USED?'
DSNBECAT='EXPIRED* BY CATLG*INTERFACE?'
DSNBISCA='FILE IS*ON OS*CATALOG?'
DSNBLBL ='B1*SECURITY*LABEL?'
DSNBTMSI='EXPIRED* BY TMS*INTERFACE?'
DSNBWSCA='FILE WAS*ON OS*CATALOG?'
The Release 5.2 data records show that TMS julian
dates in year 2000 are supported. The 311th day
in year 2000 will have julian data of 100311.
Thanks to Xiaobo Zhang, Insurance Services Office, Inc., USA.
Change 15.198 CICS reports were updated to add new data step for CICLDR
ANALCISH processing to calculate the "average fetch time" where
Aug 25, 1997 previously the "total fetch time" was printed.
Thanks to ???, ???, USA.
Change 15.197 ACF2 dataset ACF2JR did not populate variable ACLFLDVL
VMACACF2 if ACLARCFL=02x, because that field type had not been
Aug 24, 1997 previously seen. The data value is a hex string rather
than the EBCDIC characters normally stored in ACLFLDVL,
but rather than creating yet another variable for the
hex representation, I chose to use ACFLLDVL, but to
convert it to the printable-hex value using:
SUBSTR(ACLFLDVL,1,2*ACLFLDLG)=PUT(ACLFLDVL,$HEX100.);
so the three-byte data value of '010203'x in the ACF2
record will cause ACLFLDVL to contain six bytes 010203
as printable characters.
Thanks to Peter J. Lines, NatWest Bank, ENGLAND.
Change 15.196 New utility old-style MACRO _SMFGOOD defined in VMACSMF
VMACSMF was needed to read an SMF tape with truncated records at
Aug 24, 1997 the end of each block followed by a trashed record at the
start of the next block. As an example of its use:
MACRO STOPOVER MISSOVER %
%INCLUDE SOURCLIB(VMACSMF,VMAC80A);
DATA _VAR80A; _SMFGOOD ; _SMF ; _CDE80A ; RUN;
deletes the trashed records and prevents invalid-smftime
error messages and hex record dumps from being printed,
while the MISSOVER prevents input-statement-exceeded
errors from causing stopover on the truncated records.
At the same time, variable SMFRECNR is now created in the
_SMF macro, so it can be added to a _Kxxxyyy macro if you
need to know which SMF record created an observation.
Very few users will need to use these enhancements!
Change 15.195 Support for ObjectStar 3.0 SMF record. While the record
VMACHURN changes themselves were compatibly made, you must change
Aug 23, 1997 VMACHURN to read them. Change IF SMFHVR EQ 02X THEN DO;
Aug 26, 1997 to read IF SMFHVR LT 02X THEN DO; and MXG will tolerate
(i.e., process the records correctly) Version 3.0, but to
exploit (i.e., pick up the new fields) you will need this
change.
New dataset HURN06 Lock Manager Statistics is created for
both subtype 22 (Interval) and subtype 6 (Termination)
as both records are identical in structure.
New fields were added to existing datasets:
Control Region Start Time variables HU50CRTM, HU51CRTM
HU52CRTM HU60CRTM HU61CRTM HU62CRTM and HU72CRTM are
added to HURN501 HURN511 HURN521 HURN601 HURN611
HURN621 and HURN721 datasets.
Control Region Session Identifier variables HU60UNQI
HU61UNQI HU62UNQI HU72UNQI are added to HURN602
HURN612 HURN622 and HURN722 datasets.
Thanks to Trevor Ede, Bank of New Zealand Ltd, NEW ZEALAND
Thanks to Glen Bowman, Wakefern Food Corporation, USA.
Change 15.194 The MXG default for MEMSIZE was raised to 64M (from 48M)
CONFIG because if you add lots of additional record processing
Aug 22, 1997 (DMON,ENDV,FOCU,HSM,IDMS,28,NSPY,NTCP,PROS,80A,SASU,
STC,SYNC, and X37, for example!), you will need slightly
more than 48M of virtual addressability. Since there is
no cost to large virtual storage limit for programs that
do not need it, changing the MXG Maximum Default may save
someone diagnostic time to resolve OUT OF MEMORY errors.
The symptoms were that the IEF374I message on SYSLOG had:
VIRT = 1572K SYS = 308K EXT = 47316K SYS=10768K
the EXT value suggested a 48M limit was set somewhere!
Why 64M? Why not 80M? No good reason.
Thanks to Susan Walters, Michelin Tires, USA.
Change 15.193 Another invalid '04' Catalog Cell requires protection.
VMAC6156 Add the IF SKIP GE 2 THEN DO; and END; statements
VMACCTLG around the two statements to end up with:
Aug 22, 1997 IF SKIP GE 2 THEN DO;
INPUT VOLHKYLN &PIB.2. @;
SKIP=SKIP-2;
END;
The '04' cell had nulls for VOLSER, and only had a low
key range; the high key range was non-existent.
Thanks to Dave Millard, Southern California Edison, USA.
Change 15.192 Support for HMF SMF record Subtype 11 (DS3 Statistics)
DIFFHMF adds new dataset TYPEHMFB, with 44 counter and endpoint
EXTYHMFB values for each link (HMFBUSNO) during each polled
IMACHMF interval. Since the HMF counters are accumulated, the
VMACHMF dataset TYPEHMFB must be de-accumulated by logic added
Aug 21, 1997 to DIFFHMF. Sep 2 update: all non-endpoint counters
Sep 2, 1997 are protected for wrapping.
Thanks to Anne Robbins, Bank of New York, USA.
Change 15.191 ANALDB2R fails with ERROR 31-185 if the SORTBY list did
ANALDB2R not contain PLAN. The error was because variable PACKID
Aug 19, 1997 was not initialized as character; as long as PLAN was in
the SORTBY list, PACKID's definition was picked up by the
assignment IF ... THEN PACKID=PLAN; but that statement
was not generated when SORTBY did not list PLAN.
To correct: Find %MACRO PMACC02; and then find
RETAIN PAGENUM; (about 957 lines later) and then insert
LENGTH PACKID $18; after that RETAIN statement.
Thanks to John Shuck, SunTrust Companies, USA.
Change 15.190 Support for 5 new NTSMF Objects, validation of untested
ADOCNTSM objects and some new counters, and utility for Discovery
EXNTCNME Records.
EXNTFULC -Five new NTSMF Objects create six new datasets:
EXNTPEP5 Dataset Object Name
ENNTSNAA CONECTME Connect-ME
EXNTSNAC FULCRUM Fulcrum Server
EXNTWBSS SNAADAPT SNA ADAPTER SNAD1c1
IMACNTSM SNACONN SNA Connections
VMACNTSM WEBPRSRV WEB Proxy Server Service
Aug 19, 1997 PENTP5 PENTIUM (see next note)
Aug 25, 1997 -Two forms of the PENTIUM object exist. For PENTIUM PRO P6
processors, the record contains the expected 68 fields to
output in the PENTIUM dataset, but for PENTIUM P5, there
there are only 58 fields, with completely different field
names, so the new PENTP5 dataset is now created from
PENTIUM objects with only 58 fields. Instead of sensible
variable names, variables PENTP501-PENTP548 are created
(its a lot quicker, and I expect little need for these
counters); there are only 48 variables because ten of the
fields are place-holders.
Mark has discovered that for either Pentium object, only
two pairs of Pentium counters can be enabled at a time,
and the counter values are accumulated so that you will
need to subtract adjacent observations to calculate the
delta using SAS's DIF() function until MXG provides a
de-accumulation member, but this support is probably all
that is needed for this hardware-level data.
-Five untested NTSMF records have been validated; three
have instance names (cannot tell without test data, as
the Discovery records do not identify instances):
Dataset Object Name Instance
MSEXCHIP MSEXCHANGE INTERNET PROTOCOLS PROTNAME
MSEXCHIS MSEXCHANGEIS 3 new vars
MSEXCHMC MSEACHANGEMTA CONNECTIONS CONNNAME
MSEXCHPU MSEXCHANGEIS PUBLIC 35 new vars
NETWSEGM NETWORK SEGMENT SEGMNAME
-The new utility macro, _UNTDISC, that can be used to
print the Discovery records, is defined in VMACNTSM,
and comments before the MACRO definition show how to
use the utility to find new counters and new objects.
-In Microsoft's NT Resource Kit, there is a utility
\PerfTool\CntrTool\Cntrlist.exe that will provide detail
explain text for all counters; unfortunately it does not
always work in decoding new objects and has been known to
abend, and Microsoft does not support their ResKit, but
now you know it is there.
Thanks to Jim Quigley, Consolidated Edison, USA.
Change 15.189 Support for new ADSM VM Account Records from VM/ESA.
IMACVM New dataset VMADSM matches the TYPE42AD dataset created
TYPEVM from type 42 subtype 14 SMF records on OS/390 and MVS.
VMAC42 While MVS puts the data in one SMF record, VM Accounting,
Aug 15, 1997 forever limited to an 80 byte physical card image record,
has broken new ground by defining subtype and sequence
numbers so that more than 80 bytes can be recorded for an
account event. The subtype 1 and subtype 2 of the 'C0'
must be found in sequence in the VM Accounting input, or
MXG will Delete with Error Message. Since Multiple User
products can create 'C0' VM Accounting Records, the User
ID Name of the ADSM Server must be hardcoded in TYPEVM;
MXG expects the name to start with DSMSERV or records
will not be recognized by MXG as ADSM-created. The new
variable CLSESTYP is now created also in TYPE42AD; that
location was a reserved field in original ADSM SMF doc.
VM also creates a subtype 3 ADSM record, but I need test
data to decode and validate that record.
I took this opportunity to update the VM Accounting
Support in MXG; the _KVMxxxx macros defined in IMACACCT
are now actually referenced in the TYPEVM Data Statement
and labels for the data sets were clarified:
VMID Dataset Description
01/C1 VMSESSN Virtual Machine Resource Usage
02/C2 none Dedicated Devices
03/C3 none Temporary Disk Space
04 VMLOGON Invalid LOGON Password
05 VMDISK LINK to Not-Owned Protected Disk
06 VMLINK Invalid LINK Password
07 VMVCNA SNA/CCS Logoff/Disconnect
08 VMLOGOFF User Logoff/Disconnect/Shutdown/Force
09 none ACNT ALL - ISFC Accounting
ISFC Initialization ISFI Accounting
ISFC Conversation Accounting
ISFS - Conversation Start
ISFA - Conversation Active
ISFE - Conversation End
ISFC Link Statistics ISFL
ISFC Termination Accounting ISFT
0B VMDEVICE Virtual Disk in Storage
C0 VMADSM USER=:DSMSERV ADSM Accounting
VMRSCS USER=:RSCS RSCS Accounting
VMSQLxxx USER=:SQLDBA SQL Accounting
VMSQLINI SQL INIT
VMSQLSYS SQL SYSTEM
VMSQLTRM SQL TERM
VMSQLUSR SQL LOCAL USER
VMSQLRMT SQL REMOTE USER
VMUSRDAT USER=other USER Data
The datasets listed as "none" will be created when test
data is provided. The VM/ESA Account records still do
not contain four-digit years (except in new ADSM record)
but MXG's Change 15.167 does protect VM Account Records
for the year 2000.
Thanks to Ned Hammond, American Management Systems, USA.
Change 15.188 OPC 3.1 dataset OPC31 had bad values in some variables
VMACOPC because 19 reserved bytes after ETCNAME were not skipped.
Aug 15, 1997 -Insert +19 between ETCNAME and ETCDESC to correct.
-Dataset OPC23 only had obs for TRLEVT23='C' (Completed)
or 'E' (Error). Now, events 'S' (Start) and 'X' (Reset)
are also output, but date variable TRLDUR23 is nonmissing
only for the 'C' and 'E' events.
-Invalid OPC29 records have been observed, but are thought
to be an IBM problem, which is under investigation.
Thanks to Randy Shumate, LEXIS-NEXIS, USA.
Change 15.187 CMF. Variable C279SSI in dataset CMF27C93 was INPUT as
VMACCMF &PIB.2., while variable C279CSSI in dataset CMF27CSC was
Aug 7, 1997 INPUT as $CHAR2., but both variables are Subsystem ID,
Aug 28, 1997 and should be the same so they can be MERGED. Therefore
add variable C279SSI to the $HEX4. format list, and
change C279SSI &PIB.2. to C279SSI $CHAR2.
-Aug 28: New variable C279DDIC is created by adding the
Base address to the Device ID and converting to character
so that new variable C279DDIC matches CMF27UA1 in the
CMF27CSC dataset, because merging datasets CMF27CSC and
CSC27C93 must be done BY both SSI and DDI.
C279DDIC=SUBSTR(PUT(INPUT(CMF27CCU,S370FPIB2.)+
INPUT(C279DDI,S370FPIB1.),HEX8.),5,4);
Thanks to Neil Ervin, Banc One Services Corporation, USA.
Change 15.186 STK 4400 SMF records. STCLMU dataset character variables
VMACSTC LSBECON1 and LSBECON2 were $CHAR6 fields, but are now
Aug 6, 1997 replaced with four variables:
LSBELSM1='PASSTHRU*PORT 1*CONNECTED TO*LSM'
LSBEPAN1='PASSTHRU*PORT 1*CONNECTED TO*PANEL;
LSBELSM2='PASSTHRU*PORT 2*CONNECTED TO*LSM'
LSBEPAN2='PASSTHRU*PORT 2*CONNECTED TO*PANEL'
Thanks to Bob Gauthier, American Stores Company, USA.
Thanks to Bruce Sloss, PNC Financial Corporation, USA.
Change 15.185 ACF/VTAM. Type 50 produced zero observations because the
VMAC50 records are now greater than 78 bytes (although I still
Aug 6, 1997 can find no documentation of the IBM change). The test
LENGTH EQ 78+OFFSMF must be LENGTH GE 78+OFFSMF. Also,
variable NCPSLOWS may be defective, as it has values of
zero or 7FFFFFFx (which I am also pursuing with IBM).
Note added Sep 30: It is not possible to distinguish
between an XCF MPC Group Record and a non-XCF MPC Group
record using ATTCHTYP or VERSNO, but for an XCF MPC
Group record, both DEV and BSIZE will be zero, while for
a non-XCF MPC Group record, at least one will be nonzero.
Thanks to Bill Feeney, Hennepin County, USA.
Change 15.184 TMON/DB2. Change 15.114 did not properly handle the "DE"
VMACTMDB record, which only has part of the standard header. Also
Aug 6, 1997 the dates input with MMDDYY informat were changed to use
&NUM.2 so that VMACTMDB will correctly execute under
ASCII systems as well as under MVS.
Thanks to Luc Gariepy, Regie des rentes du Quebec, CANADA
Change 15.183 Dataset TYPE72GO could have observations OUTPUT that had
VMAC7072 no resource consumption for that period, because the MXG
Aug 4, 1997 variable NOACTVTY was not reset to 0 for the second and
subsequent periods within a Service Class. The new test
for _I_ GE 2 was added to zero NOACTVTY (which is then
used in EXTY72GO to control execution of the OUTPUT):
DO _I_=1 TO NRSCS;
IF _I_ GE 2 THEN NOACTVTY=0;
INPUT @COLSCS
Thanks to Ove Dall-Hansen, CODAN Insurance, DENMARK.
Change 15.182 Variable VELOCITY in TYPE72GO was wrong for service class
VMAC7072 periods with Discretionary or System goals; the value was
Aug 4, 1997 carried forward from prior periods. Since neither System
nor Discretionary goals have velocity, the variable is
now set missing with:
ELSE IF R723CRGF='S' OR R723CRGF='D' THEN DO;
PERFINDX=.;
END;
Thanks to Brenda Rabinowitz,
Change 15.181 INVALID ARGUMENT TO FUNCTION INPUT in BETA93 SMF record
VMACBETA is caused by a value of '*RELOAD*' in the JCTJOBID field
Aug 4, 1997 from which MXG extracts the job's JES Number JESNR, for
the BETA93 RELOAD step. Adding two question marks:
JESNR=INPUT(SUBSTR(JCTJOBID,4,5), ?? 5.);
to the INPUT function supresses the NOTE and the hex dump
of the input record. With or without the question-mark
modifiers, JESNR will be a missing value.
Thanks to Winfried Waldeyer, BHF-Bank Frankfurt, GERMANY.
Change 15.180 SAS Compiler Error under Windows 95 and Windows NT when
VMACVMON old-style macro has text in column 1 is circumvented in
VMACVMXA MXG by ensuring a blank is in column one in the MXG code
VMACXAM members that worked under MVS but failed under Windows.
ANALDBTR This error was seen long ago, when initially testing MXG
Aug 3, 1997 on ASCII platforms; it showed up now as I began testing
of all of MXG under Windows. The symptom was a SAS error
message "Variable ACTIVEDSVMAXUS longer than 8 bytes",
(even though ACTIVE and DVSMAXUS were on separate source
lines), but the variable names are in an old-style macro
and the variable name started in column one! Inserting a
blank in column eliminates the compiler's confusion in
these members previously untested on ASCII platforms.
Change 15.179 -Boole & Babbage MainView for CICS (was CICS Manager) will
IMACICBB support the year 2000 in MV for CICS Release 5.2. Their
YEAR2000 date yymmdd0F will be changed INCOMPATIBLY to yyyymmdd,
Aug 1, 1997 so you will need MXG 15.04 or later before you install
that release (late 1997?), if you have enabled IMACICBB
to process their statistics segments in type 110 SMF
records. MXG tests the 0F byte to determine the format.
-Boole & Babbage MainView for IMS (was IMF) will support
the year 2000 in Release 3.2, using yyyydddF format in
place of 00yydddF, but MXG already supported that format
so there was no MXG change to TYPECIMS code.
-Boole informed me that CONTROL-D is a New Dimension Co
product (although it is marketed by Boole in Europe), so
I have updated that product, as well as Boole's products
in member YEAR2000.
Thanks to whoever told Boole marketing about YEAR2000 on www.MXG.com!
Change 15.178 Example macro definitions for _KCICTRN that will keep
IMACCICS only CICSTRAN variables that are needed for ASUMCICS or
Aug 1, 1997 ASUMUOW have been added to member IMACCICS (although they
are commented out). See CICS Technical Note in MXG
Newsletter THIRTY-TWO or comments in IMACCICS itself.
Thanks to Mark Cohen, ???, ITALY.
Change 15.177 -Typos: after DDD=MOD(MVLCDATE ... change IF 0 LE DDD to
VMACEDGS IF 0 LT DDD. Remove the second occurrence of MVEXPDT in
Aug 1, 1997 the FORMAT statement.
-Logic change. DFSMS/rmm variables MVEXPDT and MKDELDAT
can have value 1999366 as a "never expire" date, but that
is an invalid SAS date. MXG's DCOLLECT algorithm is now
used for these values, and the date is set to the future
date in year 2099 (and the original value is available in
character variable MVEXPDTO for MVEXPDT, although there
is no corresponding character variable for MKDELDAT):
IF DDD GT 366 OR (YY=99 AND DDD GE 365) THEN DO;
MVEXPDT='31DEC2099'D;
END;
Thanks to Peter Young, University of Toronto, CANADA.
Change 15.176 Invalid Catalog Cell '05'x caused INPUT STATEMENT EXCEED
VMACCTLG error. The cell began at byte 279, with Length of Cell
VMAC6156 '2E'x (46) bytes, and at byte 284 the count of four-byte
Aul 1, 1997 segments following is '5C'x (92), so MXG attempted to
read 92*4=368 bytes of GAT segments, but there were only
40 bytes left in the record. To circumvent this IBM
error, MXG had to add code to validate that the number of
segments is consistent with the cell length:
Change DO _I_=1 TO GATCNT;
to IF GATCNG*4 LE SKIP THEN DO _I_=1 TO GATCNT;
and after the END; statement for that DO group, insert:
ELSE DO;
INPUT +SKIP @;
SKIP=0;
NB615605+1;
IF NB615605=1 THEN DO;
PUT // ' *** INVALID CATALOG CELL 05 SKIPPED.'/
_N_= SMFTYPE= SYSTEM= JOB= LENTHIS= GATCNT= COL= ;
LIST;
END;
END;
Thanks to Shana Bereznay, Southern California Edison, USA
Change 15.175 CICS formats $MGCICDL and $MGCICDS that decode variables
FORMATS LDGDSAIN, SMDDSAIN, SMSDSAIN, and SMTDSAIN printed trash
Jul 29, 1997 because the syntax 01X= was used (a numeric hex value)
instead of the '01'X syntax that is needed for character
values. SAS could not raise an error condition, because
(due to legacy considerations) both quoted and unquoted
strings are valid syntax. Adding quotes corrects.
Thanks to Larry Gray, Lowe's Companies, Inc., USA.
Change 15.174 Using ANALCNCR with an INTERVAL greater than 24 hours
ANALCNCR produced valid results, but cause a very large number of
Jul 29, 1997 unnecessary observations to be created in the work file,
because SYNCINTV=YES was set by default. Now, the large
interval value will be recognized and SYNCINTV=NO will be
forced (and a note to that effect printed on the log).
Thanks to Clark Jennings, Reynolds Metals Company, USA.
Change 15.173 A question on MXG-L concerning how to merge DB2 Trace
ANALDBTR records with DB2ACCT and CICSTRAN data has resulted in
ANALDBXX an new example program in member ANALDBXX. The example
Jul 29, 1997 uses ANALDBTR, but an new options, UOWSORT, had to be
created in ANALDBTR. UOWSORT=YES causes variables
NETSNAME and UOWTIME to be kept in all dataset pairs
created by ANALDBTR, and also causes those variables to
be added to the BY list in each sort. This example will
likely become a new option in ANALDB2R in the future,
but this working example is provided for use now.
Thanks to Michael Frey, COMLAB GmbH, GERMANY.
Thanks to Chuck Hopf, MBNA, USA.
Change 15.172 Support for Xerox's XPSM Version 2 (Xerox Print Services
VMACXPSM Manager) Host Accounting Record (INCOMPATIBLE). The new
ZMACXPSM record is a complete restructure of the original record,
Jul 29, 1997 but contains much new and useful information if you are
using XPSM. Among the major additions are:
- The record now contains all fields in IBM's type 6
record for PSF, and MXG uses the same variable names
that you know from TYPE6 processing
- Unlike IBM's type 6, the XPSM V2 record contains the
Account Fields from the Job card, plus a "Department
Account", so it is not necessary to merge TYPEXPSM
with type 30 data to charge back XPSM printing, and
you can account for jobs printed after the job purge
record has been created (e.g., output sent to remote
print servers).
- Repeated segments contains multiple names of Forms,
Overlays, Fonts, Images, Templates, and Colors.
MXG keeps first eight values (three for colors).
- Printer setup names JDL and JDE used.
- Remote Server section provides timestamps of begin and
end of transmission and begin/end of printing.
- MVS Host CPU time (TCB,SRB,RCT,IPT,HPT) are captured.
- MVS I/O SSCH counts and spool size for each DASD and
Printer device used are available, although MXG has
only implemented capture of the totals (a dataset for
each DD will be implemented when requested).
- CPU of cost of data stream transformation (eg, LCDS to
PCL) is captured.
- Outage and change of state information is provided.
Thanks to Dan Kaberon, Hewitt Associates, USA.
Change 15.171 HSM dataset DGN's variable DGNDCL was blank because the
JCLHSM INPUT DGNDCI should have been INPUT DGNDCL. Several
VMXGHSM non-existent variables were removed from the KEEP= list
Jul 28, 1997 for datasets MCP and DGN. The now-nonexistent option
DQUOTE was removed from JCLHSM. The %VMXGHALL macro
used in the MXG QA job, was updated so that all of the
HSM datasets are created; this accounts for new datasets
BCR, BVR, DCL, DCR, DGN, MCB, MCC, MCM, MCP, MCPDGN, and
MCT now being listed in member DOCVER.
Thanks to Peter Young, University of Toronto, CANADA.
Change 15.170 Support for OS/390 Version 2 Release 4.
VMAC1415 -TYPE1415: Variables PROGRAM and STEPNAME were added:
VMAC26J2 (MXG's ANALDSET, which is still needed to correctly de-
VMAC30 accumulate EXCP counts from 14/15's has always picked up
EXTY4237 PROGRAM and STEPNAME, but having them directly in these
IMAC42 records is long overdue!).
VMAC71 -TYPE26J2: New workload management section added:
VMAC7072 JOBMODE0='JOB RAN*IN*MODE=WLM?'
VMAC42 JOBMODE1='JOB RAN*BECAUSE*OF $S J?'
VMAC74 SMF26WCL='SERVICE*CLASS AT*EXECUTION'
Jul 23, 1997 SMF26WIN='JOB*INDICATORS'
SMF26WJC='JOB*CLASS'
SMF26WOC='ORIGINAL*SERVICE*CLASS'
SMF26WSE='SCHEDULING*ENVIRONMENT'
-TYPE30: datasets TYPE30_V, TYPE30_4, TYPE30_5 and
TYPE30_6 have important new data:
-New DASD-only Connect/Disconnect/Pending time plus
SSCH counts for ASID plus Dependent Enclaves and for
Independent Enclaves (added by OS/390 R1.3).
SMF30AIC='DASD CONNECT*ASID PLUS*DEPENDENT'
SMF30AID='DASD DISCONNECT*ASID PLUS*DEPENDENT'
SMF30AIS='DASD SSCH*ASID PLUS*DEPENDENT'
SMF30AIW='DASD PEND+CU*ASID PLUS*DEPENDENT'
SMF30EIC='DASD CONNECT*INDEPENDENT*ENCLAVES'
SMF30EID='DASD DISCONNECT*INDEPENDENT*ENCLAVES'
SMF30EIS='DASD SSCH*INDEPENDENT*ENCLAVES'
SMF30EIW='DASD PEND+CU*INDEPENDENT*ENCLAVES'
-CPU for Dependent Enclaves is recorded:
CPUDETTM='DEPENDENT*ENCLAVE*CPU TIME'
-Residency time in Page-Seconds in ESTORE was added,
but CSTORE residency is not (yet?) provided:
RESESFTM='ESTORE*RESIDENCY*PAGESECS'
-New Scheduling Environment (when WLM owns Initiators
and adds/drains INITs to meet Service Objectives!)
add several important durations and flags:
SMF30HQT='JOB*HOLD*TIME'
SMF30JQT='JOB*PREPARATION*TIME'
SMF30PFF='JOB INIT*WAS FORCED*BY OPERATOR?'
SMF30PFL='SCHEDULING*ENVIRONMENT*NAME'
SMF30PFR='SRVCLASS*WAS MODIFIED*DURING*EXECUTION?'
SMF30PRJ='SRVCLASS*WAS MODIFIED*PRIOR TO*INIT?'
SMF30RQT='INELIGIBLE*FOR*EXECUTION*TIME'
SMF30RTR='JOB*HAS*BEEN*RESTARTED?'
SMF30SQT='ELIGIBLE*FOR*EXECUTION*TIME'
-TYPE42: new subtype 9 creates new dataset TYPE4237
for every B37/D37/E37 (out of space) ABEND. The record
is useful for tracking these abends, but I have asked
for the record to be (optionally) written when datasets
are extended (so you could track those jobs/datasets that
are going to abend before they do!). Variables are:
DISP ='DISPOSITION'
DSNAME ='DATA SET NAME'
DSORG ='DSORG'
JOB ='JOB NAME*OR*TSO USER'
LOCLINFO='LOCAL*INSTALLATION*FIELD'
READTIME='READ-IN*OR LOGON*EVENT'
S42ABEND='S42FLAGS*B37 OR*D37 OR*E37?'
S42ADRLH='S42ADRLH*AVERAGE*BLOCK*LENGTH'
S42ASSAT='S42ASSAT*SECONDARY*ALLOCATION*AMOUNT'
S42ASYID='S42ASYID*SYSTEM*ID'
S42DCNME='S42DCNME*DATA*CLASS*NAME'
S42MCNME='S42MCNME*MANAGEMENT*CLASS*NAME'
S42NEXT ='S42NEXT*NUMBER OF*EXTENDS*THIS VOL'
S42SCNME='S42SCNME*STORAGE*CLASS*NAME'
S42TNTRK='S42TNTRK*TOTAL*TRACKS*THIS VOLUME'
S42UCBTP='S42UCBTP*UCB*TYPE'
STEPNR ='STEP*NUMBER'
VOLSER ='VOLUME*SERIAL*NUMBER'
-TYPE71: new counts of frames in CSTORE/ESTORE includes
available, and low/medium/high impact frames in memory:
CSFRAVMN='SMF71CAM*MIN*CSTORE*FRAMES*AVAILABLE'
CSFRAVMX='SMF71CAX*MAX*CSTORE*FRAMES*AVAILABLE'
CSFRAVAV='SMF71CAA*AVE*CSTORE*FRAMES*AVAILABLE'
CSFRLOMN='SMF71CLM*MIN*CSTORE*LOW IMPACT*FRAMES'
CSFRLOMX='SMF71CLX*MAX*CSTORE*LOW IMPACT*FRAMES'
CSFRLOAV='SMF71CLA*AVE*CSTORE*LOW IMPACT*FRAMES'
CSFRMEMN='SMF71CMM*MIN*CSTORE*MED IMPACT*FRAMES'
CSFRMEMX='SMF71CMX*MAX*CSTORE*MED IMPACT*FRAMES'
CSFRMEAV='SMF71CMA*AVE*CSTORE*MED IMPACT*FRAMES'
CSFRHIMN='SMF71CHM*MIN*CSTORE*HIGH IMPACT*FRAMES'
CSFRHIMX='SMF71CHX*MAX*CSTORE*HIGH IMPACT*FRAMES'
CSFRHIAV='SMF71CHA*AVE*CSTORE*HIGH IMPACT*FRAMES'
ESFRAVMN='SMF71EAM*MIN*ESTORE*FRAMES*AVAILABLE'
ESFRAVMX='SMF71EAX*MAX*ESTORE*FRAMES*AVAILABLE'
ESFRAVAV='SMF71EAA*AVE*ESTORE*FRAMES*AVAILABLE'
ESFRLOMN='SMF71ELM*MIN*ESTORE*LOW IMPACT*FRAMES'
ESFRLOMX='SMF71ELX*MAX*ESTORE*LOW IMPACT*FRAMES'
ESFRLOAV='SMF71ELA*AVE*ESTORE*LOW IMPACT*FRAMES'
ESFRMEAV='SMF71EMM*MIN*ESTORE*MED IMPACT*FRAMES'
ESFRMEMN='SMF71EMX*MAX*ESTORE*MED IMPACT*FRAMES'
ESFRMEMX='SMF71EMA*AVE*ESTORE*MED IMPACT*FRAMES'
ESFRHIMN='SMF71EHM*MIN*ESTORE*HIGH IMPACT*FRAMES'
ESFRHIMX='SMF71EHX*MAX*ESTORE*HIGH IMPACT*FRAMES'
ESFRHIAV='SMF71EHA*AVG*ESTORE*HIGH IMPACT*FRAMES'
Note of Sep 16, 1997: IBM will not publish the UIC
values that define High, Medium, or Low Impact,
because "the UIC ranges depend on whether the system
is in goal or compatibility mode and several OPT
settings. These are values that may change in the
future. The idea of reporting these buckets was
just to get a high level view of how much stress
there is on the system's storage."
-TYPE72: support for WLM Managed Initiators added new
total sample count that includes batch queue delays,
so the calculation of VALDSAMP now also includes any
batch queue delays; batch queue delay is measured as are
three components, and the DASD IOS Queue Time is also
measured in dataset TYPE72GO:
PCTDLTDQ='TOTAL*(INCLUDES BATCH)*DELAY*SAMPLES'
PCTEXTSA='TOTAL*EXECUTION*SAMPLES'
R723CDQT='TOTAL*BATCH*QUEUE*DELAY*TIME'
R723CADT='INELIGIBLE*AFFINITY*DELAY TIME'
R723CIQT='INELIGIBLE*OTHER RESOURCE*DELAY TIME'
R723CCVT='JCL*CONVERSION*DELAY TIME'
R723CIOT='DASD*IOS*QUEUE TIME'
And dataset TYPE72DL has one new variable:
R723RWNL='STATE WITH*WAIT FOR*NEW LATCH'
-TYPE74: Coupling Facility dataset TYPE74CF now has the
model, version and level information:
R744FMOD='COUPLING*FACILITY*MODEL'
R744FVER='COUPLING*FACILITY*VERSION'
R744VLVL='COUPLING*FACILITY*LEVEL'
An additional change to BUILDPDB to add the new hold
delays (from which TYPRUN=HOLD time can be calculated)
will be available in the next version of MXG.
Revised, Nov 11, 1998: Enhancements to System Logger SMF
type 88 and OAM SMF type 85 records were supported in
MXG 16.06, Changes 16.265 and 16.255.
Change 15.169 Inconsistencies between MVS and ASCII versions of SAS
VMACOPC prevented some MXG members from being executable on the
VMXGINIT ASCII platform. While these members are not likely to
VMXGVTOC be used on the ASCII platforms, by making their code
Jul 22, 1997 transparently execute on all SAS platforms, I can run
the MXG QA stream anywhere, so changes were made:
-ASCII SAS does not accept RECFM=VBS, and MVS SAS does
not accept RECFM=S370VBS, so macro variable VMXGVBS
is now defined in member VMXGINIT to allow member
VMACOPC to execute. All other usage of VBS was already
protected by other means.
-ASCII SAS does not accept INFILE options CCHHR VTOC so
a local %MACRO VMXGCHR is created in VMXGVTOC (even
though that is a very archaic member).
Change 15.168 No observations in NETSPY dataset NSPYTIC3 because the
VMACNSPY logic inside NSPYREC='N' code to identify subtype used
Jul 22, 1997 either NSPNRECI or NSPNSUBT values, but the value '01'x
for NSPNSUBT exists in both Ethernet and TIC3 records, so
TIC3 observations were erroneously OUTPUT in NSPYETHR.
Now, all tests use ONLY variable NSPNRECI, but changing
ELSE IF NSPNRECI='06'X OR NSPNSUBT='01'X THEN ..
ELSE IF NSPNRECI='06'X THEN ...
will correct the immediate problem.
Also, the last alert in each record was not output in the
NSPYALRT dataset, and the second and later were corrupted
because the statement:
OFFNSPY=OFFNSPY-10;
that was just before the INCLUDE SOURCLIB(EXNSPYAL);
should not have been there and must be deleted.
Thanks to Mrs. Silvia Hug, RWG GmbH, GERMANY.
Thanks to Mr. Karl-Heinz Placht, RWG GmbH, GERMANY.
Change 15.167 MXG now protects all two-digit YY dates for year 2000.
IMACICBB Since IBM and other vendors have not expanded all of the
TYPEDMS two-digit YY dates, and since it is likely that some MXG
TYPEMON8 sites will still be back level on some of those products
TYPEMONI that are not year-2000 compliant, and since I could cover
TYPEPDL for the negligent products, I have extended Change 15.050
TYPETMON and have added logic to "Window" all dates that are not
TYPEVM year-2000 compliant. Years 00-59 will be set to 20xx
VMAC28 while years 60-99 will be set to 19xx.
VMACCTLD In some members, this protection was added using:
VMACIPAC IF YEAR(DATEPART(datetime)) LE 1959 THEN
VMACNSM datetime=datetime+YEARSECS;
VMACNSPY where RETAIN YEARSECS 3155673600; is used to store the
VMACODS number of seconds between 1Jan1900 and 1Jan2000.
VMACOPC In other cases, the protection was added using:
VMACQTRT IF YEAR(date) LE 1959 THEN date=date+YEARDAYS;
VMACRMDS where RETAIN YEARDAYS 14610 is used to store the number
VMACROSC of days between 1Jan1900 and 1Jan2000.
VMACSAR
VMACTMDB Member YEAR2000 has been updated to show which dates
VMACVMXP are truly year 2000 compliant (and the APAR which made
VMACXAM them so) and to show which dates are not compliant but
YEAR2000 are now protected by MXG Logic to support the year 2000.
Jul 20, 1997
Change 15.166 Support for Catalog Cell 'E7'x ("X" - Alias Cell) is now
EXCTLGE7 added to VMACCTLG so as to create new dataset CTLGE7 obs
IMACCTLG for each alias cell. In addition, the E7 cell will now
VMACCTLG be decoded in the optional logic in VMAC6156 (which only
VMAC6156 prints catalog cells on the SAS log).
Jul 18, 1997
Thanks to Michael Ayers, Wyeth Labratories, USA.
Thanks to Brian Cooper, Wyeth Labratories, USA.
Change 15.165 Support for new subtype 6 type 99 record creates new data
EXTY99U6 set TYPE99_6, called the "Goal Mode SMF" record by BGS.
VMAC99 The new subtype contains no new data (everything in it is
Jul 18, 1997 already in other subtypes of the type 99), but the new
record compacts the needed data in one subtype so that
you can afford to write that subtype 6 record and can
supress all other subtypes to reduce data volume.
Change 15.164 Variable MSGXRST is missing value because the ARRAY and
TYPEIMSA the DROP statement must be changed to read:
Jul 17, 1997 ARRAY CTR{54} CTR01-CTR54 ;
DROP CTR01-CTR54 I ;
i.e., change the 53's to 54's in those two lines.
Thanks to Kenneth D. Jones, SHL Systemhouse, NOVA SCOTIA.
Change 15.163 Support for DFSMS 1.4 adds (COMPATIBLY!) new fields:
VMACDCOL -Type 'A' - Dataset DCOLCLUS new variables:
Jul 17, 1997 DCACISZ ='NUMBER OF*BYTES IN*A CI'
DCACACIC='NUMBER OF*CI-S IN*A CA'
-Type 'V' - Dataset DCOLVOLS new variable:
DCVDPTYP='PHYSICAL*DEVICE*TYPE'
-Type 'M' - Dataset DCOLMIGS new variable:
DCVDPTYP='PHYSICAL*DEVICE*TYPE'
-Type 'B' - Dataset DCOLBKUP new variable:
UBFRVOL ='1ST SOURCE*VOL*OF BACKUP DATA'
-Type 'DC' - Dataset DCOLDC
Fifteen new DDCxxxxx construct variables.
-Type 'SG' - Dataset DCOLSG
Sixty-four status flags decoded & DSG32NAM corrected.
-Type 'VL' - Dataset DCOLVL
Ninety-six status flags decoded & DVL32NAM corrected.
-Type 'BC' - Dataset DCOLBC
Ninety-six status flags decoded & DBC32NAM corrected.
-Type 'DR' - Dataset DCOLDR
Sixty-four status flags decoded.
-Type 'LB' - Dataset DCOLLB
Sixty-four status flags decoded.
Change 15.162 Minor. Variable CPUSERF wasn not kept, and variable
RMFINTRV CPUHPTTM was not FORMATed nor LENGTHed.
Jul 16, 1997
Thanks to Bruce Widlund, Merrill Consultants, USA.
Change 15.161 Optional Omegamon/CICS DB2 variables OMBDESCN/OMBDESTM &
IMACICOB OMBEXECN/OMBEXETM were not labeled, nor were they kept in
VMAC110 CICSTRAN dataset.
Jul 15, 1997
Thanks to Harald Seifert, HUK-Coburg, GERMANY.
Change 15.160 ASUMUOW/IMACUOW are enhanced to allow large sites to send
IMACUOW the temporary sorted output of CICSTRAN/DB2ACCT to a
ASUMUOW DDname other than //WORK. Comments explain how.
Jul 15, 1997
Thanks to Chuck Hopf, MBNA, USA.
Change 15.159 IBM APAR OW13754 documents type 14/15 CRDATE and EXPDT
YEAR2000 support for year 2000 by allowing those one-byte binary
Jul 15, 1997 fields to have values 100 thru 255 to correspond to year
2000 thru 2155 (giving our descendants the opportunity
to make big bucks fixing the "Year 2155" problem). MXG
had assumed this solution, so no MXG code fix is needed.
Note that these julian dates will now print at 99363,
99364, 99365, 100001, 100002, etc.
Change 15.158 RACF type 80 RACFEVNT=22 and 59 are now supported, with
EXTY8022 new datasets TYPE8022 and TYPE8059. Segments for DTP for
EXTY8059 RACFTYPE=22, 24, 39, 40, 41, and 44 are now decoded. New
EXTY8X13 formats $MG080AF and $MG080UA are created by FORMATS.
EXTY8Y13 FORMAT MG808IA was updated so INTENT/ALLOW value 5 is now
EXTY8X24 decoded, TYPE8010 and TYPE8013 has SECLEVEL added.
FORMATS Dataset label for TYPE8018 is now PASSWORD COMMAND.
IMAC80A Several KW24xxxx variables were also corrected.
VMAC80A
Jul 14, 1997 For some RACF events, repeats of segments 21, 33, 34, 39,
Aug 24, 1997 40, 41, 42, and 44 are possible, but MXG kept only the
last instance. To repeat variables in the base TYPE80nn
or to create new TYPE8xnn dataset(s) depends on how many
repeats occur for a specific RACFEVNT; support for repeat
is added on a case-by-case basis when I receive test data
with multiple segments. Thus far, these instances of
repeated segments are supported as described:
-The many repeats of segment 21 in RACFEVNT=24 (SETROPTS)
are supported by observations in new TYPE8X24 data set,
keeping JOB READTIME SMFTIME SYSTEM as keys back to the
parent TYPE8024 dataset. The SETROPTS command creates
hundreds of repeated segments of questionable utility,
so creating an "Extra" dataset will save space.
-The second repeat of segment 33 in dataset TYPE8004 is
added as new variable RESNAME2 in that dataset. This
is a newname/oldname event, so only a second instance
needs to be supported.
-The six repeats of segment 44 in dataset TYPE8010 are
added as variables EV44FLG1-EV44FLG6, SEGNAME1-SEGNAME6,
and EV44TXT1-EV44TXT6, if more than 6 are found in the
RACFEVNT=10 record, a message will be put on the log.
For the other RACFEVNT's (11,12,13,20,21,22) only one
segment 44 has been observed, so only one is kept, but
a message will be put on the log if more are found.
-The many repeats of segments 40 and 41 in TYPE8013 create
new dataset TYPE8X13 for segment 40's (maximum of 20 has
been observed) and new dataset TYPE8Y13 for segment 41's
(maximum of 4 has been observed).
Thanks to Peter J. Lines, NatWest Bank, ENGLAND.
Thanks to Len Rugen, University of Missouri-Columbia, USA.
Thanks to Joseph Faska, Depository Trust Company, USA.
Change 15.157 Support for Shared Medical Services CICS application's
IMACCICS OASMON (SMS Online Architecture System) journal segments
IMACICSM creates new dataset CICSSMED. Observations are created
VMAC110 when records are found, with no user action required.
EXCICSME CICSSMED contains the OAS stack or program name and the
Jul 11, 1997 response time in type 110 subtype 0 SMF records without
having to enable CICSTRAN monitoring in your MCT.
Thanks to Kristyann Manske, University of Wisconsin-Milwaukee, USA.
Thanks to Kevin Hurst, Shared Medical Systems, USA.
Change 15.156 Variable DEVNR is now added to dataset TYPE74CA and is
VMAC74 equal to DEVN. The DEVN spelling was kept from the old
Jul 11, 1997 CACHE90 predecessor dataset so your old reports would
run from TYPE74CA, but DEVNR is the more common name in
all other MXG datasets, and is the variable name to use.
Thanks to MH, Allied Irish Bank, IRELAND.
Change 15.155 Cosmetic. Duplicate label statements were deleted in the
many members VMAC102, VMAC110, VMACAPAF, VMACCTLG, VMACHPSU,
Jul 10, 1997 VMACHPUX, VMACMWSU, VMACMWUX, VMACODS, VMACQAPM,
VMACTPX, and VMACXAM.
Thanks to Freddie Arie, Lone Star Gas, USA.
Change 15.154 Archaic members VMXGVTOC and VMXGVTOF did not create the
VMXGVTOC ZDATE variable in datasets INFO and VTOCINFO, but now the
VMXGVTOF variables are created. Both members were effectively
Jul 10, 1997 replaced by DCOLLECT: see TYPEDCOL/JCLDAYDS, although
the archaic members are still useful, especially if you
need to know the physical location of extents, since the
DCOLLECT records only contain total sizes of datasets.
Thanks to Mark Zelden, CIBER Network Services, Inc., USA.
Change 15.153 Cosmetic. The LABELs for LPAR variables are now grouped
ASUM70PR by LPAR number, so all variables for LPAR 0 are together
Jul 9, 1997 for ease in viewing; the global CPU and Percentages are
also grouped together, as the 1st variables in ASUM70PR.
Thanks to Jean Quinkert, Inland Steel, USA.
Change 15.152 Formats $MGHEX2H, $MGHEX4H, and $MGHEX8H are added to
FORMATS MXG to print hex character variables's blank values as
Jun 29, 1997 blanks instead of '40's. See MXG Tech Note, NL 32.
===Changes thru 15.151 were included in MXG 15.03 dated Jun 30, 1997===
Change 15.151 Installation tailoring code that defines your SHIFT value
IMACSHFT has added an example of a table of holiday's dates that
Jun 29, 1997 can be used to change Prime/Non-Prime Shift observations
to Weekend Shift, if that is what your manager says to
do because the numbers are skewed. (Personally, I prefer
to leave the shift asis, and observe the week-to-week
difference between weeks with holidays and weeks without,
but MXG is all about freedom and doing it your way!)
The example is commented out, so this change did not
really change anything except comments in IMACSHFT.
Thanks to Mark Zelden, CIBER Network Services, Inc., USA.
Change 15.150 INPUT STATEMENT EXCEEDED with Omegamon VTAM 200 IRNUM=12
VMACOMVT record; variables ON12OQ, ON12SP, and ON12SS must be
Jun 28, 1997 INPUT as &PIB.4. instead of &PIB.8., and variable ON12DX
must be INPUT as $EBCDIC4. instead of &PIB.8. This is
the first instance of anyone processing this subtype.
Thanks to Richard Anderson, SAS Institute Cary, USA.
Change 15.149 MXG 15.03 corrections uncovered in final final tests:
TESTWWW -Step TESTOTHR of JCLTEST6 fails because of the extra
DIFFDB2 close-parenthesis in the DATA statement in member TESTWWW
TRND72GO (twice I caught this and thought I had fixed it!).
NEWSLTRS -"UNINITIALIZED VARIABLE BHHITRAT" in building DB2STATB;
EXNTCMBU BPHITRAT was spelled BHHITRAT in one LABEL statement in
IMACEXCL member DIFFDB2, causing variable BPHITRAT to be created
Jun 28, 1997 without a label. See Change 15.xxx.
-TRND72GO statement LENGTH SERVICE 8 MSOUNITS; caused a
very strange %MACRO compiler error; but the correct
statement should be LENGTH SERVICE MSOUNITS 8;
-Four Thousand lines were deleted from member NEWSLTRS;
The text of changes in the Change Log in Newsletters
TWENTY-SEVEN and TWENTY-EIGHT should have been removed
from member NEWSLTRS, as that text is kept in member
CHANGESS, and a redundant copy is not needed!
-Comment in EXNTCMBU changed to CMPQCMBU vice CMPQBUSU.
-Comments in IMACEXCL were clarified extensively.
Thanks to Freddie Arie, Lone Star Gas, USA.
===Changes thru 15.148 were included in MXG 15.03 dated Jun 26, 1997===
Change 15.148 Omegamon BSC data had incorrect GMTOFFTM calculated; The
IMACICOC variable OMGMTCHR was truncated to only one byte because
Jun 26, 1997 it was in the INFORMAT ... $NOTRAN. statement; it should
be removed from that INFORMAT statement.
Thanks to Dale Wiles, Perdue Farms, USA.
Change 15.147 NTSMF Version 2.0.d requires MXG 15.03 dated Jun 26, or
VMACNTSM at least MXG 15.02 plus this change. MXG coding errors
Jun 26, 1997 will cause error messages "UNEXPECTED INSTANCE FIELDS" or
INVALID DATA FOR MO IN LINE .... and/or STOPOVER ABEND.
-The LENGTH statement VERSION $4. must be changed
to VERSION $5.
-The two tests for Reduced or Extended Header must be
changed to read:
IF VERSION GE : '2.1' THEN INPUT /*REDUCED HEADER*/
and
IF '2' LE : VERSION LT : '2.1' THEN INPUT /*EXTENDED*/
instead of the tests for '2.0.d' and LE '2.0.c'.
Thanks to Chuck Hopf, MBNA, USA.
Change 15.146 IBM Item RTA000099957 (see DB2 Technical Note 2 in NL 32)
DIFFDB2 states that the calculation of Buffer Pool Hit Ratio
ANALDB2R is (QBSTGET-(QBSTSIO+QBSTDPP+QBSTLPP+QBSTSPP))/QBSTGET;
Jun 26, 1997 whereas MXG used QBSTRIO instead of QBSTSIO in ANALDB2R.
I have added variable BPHITRAT to the DB2STATB dataset,
and variables B1HITRAT-B4HITRAT to the summary DB2STATS
dataset. I expect to alter ANALDB2R but want to verify
first (and its an extensive change). See the discussion
of why you can get negative values for Hit Ratio in DB2
Technical Note in Newsletter THIRTY-TWO.
===Changes thru 15.145 were included in MXG 15.03 dated Jun 25, 1997===
Change 15.145 Minor cosmetic changes were made to TRND72GO (Labels, and
TRND72GO DROPs), and 3 documentation-only members: ACHAP99, DOCVER
Jun 25, 1997 and DOCVER15 were updated with 15.03 dataset contents,
and counts in AAAAAAAA & COPYRITE now are for the real
MXG 15.03 dated Jun 25, 1997. Only ten tapes to trusted
sites carried the Jun 24, 1997 date.
===Changes thru 15.144 were included in MXG 15.03 dated Jun 24, 1997===
Change 15.144 TYPERDS records created 0 observations; these corrections
VMACRDS were required: INPUT of H15FTP is &PIB.2. vice &PIB.4.,
Jun 24, 1997 the INPUT of H15HSQ is &PIB.4. vice &PIB.2., and the
test IF H15FOS+H15FL GT ... must be changed to
IF H15FOS+H15FL-1 GT ....
Thanks to Shana Bereznay, Southern California Edison, USA.
Change 15.143 This change was NOT made. After planning the change and
BUILDPDB writing the change text, I realized I could not make the
BUILDPD3 change as described without a negative impact on existing
BUILD005 MXG BUILDPDB/BUILDPD3 users: BUILDPDB deletes the STEPS
BUIL3005 dataset from WORK as soon as PDB.STEPS is created (so its
Jun 24, 1997 workspace can be reused), but keeping WORK.STEPS would
require more WORK space - an existing daily job could
ABEND, needing more //WORK space, if I made the change.
I will revise the change and revise its description when
I can figure out how to meet IT Service Vision's request
without impact on existing MXG BUILDPDB jobs.
For IT Service Vision. After MXG's BUILDPDB logic has
created the PDB.STEPS dataset, SAS's IT Service Vision
uses the WORK.STEPS dataset left in the WORK file. But
then MXG logic to create PDB.SPUNJOBS replaces the real
WORK.STEPS with only the spun steps, because I reuse the
_PDBSUM macro that is defined in IMACPDB. I considered
changing that macro in IMACPDB to use a symbolic for its
output dataset, but that implementation would have caused
incompatibility for any user that had tailored IMACPDB!
Instead, by adding PROC DATASETS to rename WORK datasets:
PROC DATASETS NOLIST; CHANGE STEPS=REALSTEP;
%INCLUDE SOURCLIB(SPUNJOBS);
PROC DATASETS NOLIST; CHANGE STEPS=SPUNSTEPS;
PROC DATASETS NOLIST; CHANGE REALSTEP=STEPS;
both WORK.STEPS and WORK.SPUNSTEP will now exist after
BUILDPDB runs. By making this change in MXG, IT Service
Vision installers will have one less option to tailor.
Again, this change was NOT made. These are notes only,
that will likely be revised in the future.
Change 15.142 New exit EXPDB30V is added to the BUILDPDB/BUILDPD3 logic
EXPDB30V to allow tailoring of the PDB.SMFINTRV after TYPE30_V has
BUILDPDB been merged with the Accounting Information. While the
BUILDPD3 IMACINTV exit can be used to tailor TYPE30_V (which
BUILD005 becomes PDB.SMFINTRV), the accounting fields do not exist
BUIL3005 when IMACINTV is invoked, so the new exit allows for
Jun 23, 1997 more flexible tailoring.
Thanks to Diane Eppestine, Southwestern Bell, USA.
Change 15.141 ASMTAPES ML-14 populates fields in the Tape Mount record
ASMTAPES (COMPATIBLY) and provides some enhancements to the AR
Jun 23, 1997 mode code to prevent the S0C4 abends with swapped out
address spaces. It does not completely conceal the S0C4
abends (that is still planned) but this should improve
the situation significantly.
Change 15.110 describes the corresponding changes to the
VMACTMNT member to process the newly populated fields,
but as the record format was not changed by the monitor,
earlier versions of MXG can read the ML-14-created SMF
records compatible. You will want to use VMACTMNT from
MXG 15.03 or later to exploit and decode the new fields:
The ALOCSTRT is of value when working with tape mounts
for DFHSM where some DDNAMEs (eg., RESIN1, RESIN2,...)
are re-used many times (dynamically allocated) within
one (long-running) step. The DDNAME is of value when
working with tape mounts for DFHSM were some devices
are allocated multiple times with different DDNAMEs
within a step.
Mark also provided corrections for truncation of JESNR to
four digits in the mount record processing; he found that
the ASMTAPES logic did not replace ALCSTIME with ALISTIME
for INTERVAL records cut after a day boundary has been
crossed; he provided his ASM and SAS code to to add the
above fields; and he found a nit in one series of tests!
Mark is a fine example of an MXG CodeShark!
Thanks to Mark Keimig, VF Information Technology Services Inc., USA.
Change 15.140 Support for new fields in the DFSMSrmm TYPEEDGR extracts
FORMATS that were COMPATIBLY added at some time in the past.
VMACEDGR Dataset EDGRDEXT has new variables:
Jun 23, 1997 RDABEND RDCAT RDCRTJBN RDDCNAME RDDDNAME RDDSSIZE
Jun 26, 1997 RDLABNO RDMDMVID RDRETDAT RDSCNAME RDSGNAME RDSTEPNM
RDVRSJBN RDVRSNAM RDVRSR RDVRSTYP
and new format $MGEDGRT is added to member FORMATS.
Dataset EDGRSEXT has new variable RSBMEDN.
Dataset EDGRVEXT has new variables:
RVABEND RVACTERA RVACTINI RVACTNOT RVACTREP RVACTRET
RVACTSCR RVBMEDN RVDSNREC RVHOMTYP RVLUDEV RVMVMODE
RVNEXTYP RVNLOC RVOBMEDN
27Jun97: Variables RVNVOL RVNPVOL and RVMDMVID were
labelled and added to KEEP for EDGRVEXT dataset.
Thanks to Sam Bass, McLane Co., USA.
Change 15.139 When Landmark maintenance TT00032 was applied after the
TYPETMON March cum tape was installed (to fix a Landmark 0C4 in
TYPEMON8 their dump program), the dump program creates a garbage
Jun 23, 1997 first record, causing MXG to USER ABEND 1099. The bad
record can be deleted by changing the test for dictionary
record deletion to include this garbage record:
IF TMMDREC='DD' OR (TMMDPROD='00'X AND TMMDREC='0081'X)
THEN DELETE;
Thanks to Marcia Ketchersid, Price Waterhouse LLP, USA.
Change 15.138 Report Performance Groups or Reporting Classes now CAN be
IMACWORK used in member IMACWORK to define workloads in dataset
RMFINTRV PDB.RMFINTRV. This redesign separately sums the Control
Jun 22, 1997 Performance Groups (Compat Mode) or the Service Classes
(Goal Mode) into the existing variable CPUTM, and then
sums all of the CPU times from your workload definitions
into new variable CPU72TM. If CPU72TM does not exactly
match CPUTM, then either you have double accounting
(CPU72TM GT CPUTM), or you have failed to map all of your
workloads in your IMACWORK logic (CPUTM GT CPU72TM); MXG
will print an error message on the SAS log if the times
do not match. The new design relocated the DELETE logic
from member RMFINTRV into the revised IMACWORK (since you
will have to change that delete logic if you want to use
RPGNs or Reporting Classes in your workload definitions),
but you do not have to change your IMACWORK member until
you want to use the new facility. The new RMFINTRV will
detect that you are still using an "old" IMACWORK member,
and will continue to delete Report Performance Groups and
Reporting Classes until it detects you are using the new
IMACWORK member. Thus this change is compatibly made!
The optional code to directly read SMF records that is
commented out in RMFINTRV was updated to match BUILDPDB.
Change 15.137 Pre-15.03-QA job found missing labels for variables in
VMACSTRS these members.
TRNDDB2S
VMACTMDB
VMACLMS
TYPEIMS
ASUMDB2A
ASUMDB2B
Change 15.136 This member for reading Web Proxy logs in Common Log
TYPEWWW Format was revised to conform to MXG style (LABELs,
Jun 22, 1997 FORMATS, LENGTH, and name changes of temporary fields,
and some statements were consolidated. Variable RDRTS
was renamed WWWRDRTS to avoid name conflict.
Change 15.135 Trending for Workload Manager Goal Mode Service Class
TRND72GO dataset TYPE72GO into TREND.TRND72GO now exists, in
Jun 20, 1997 this preliminary version. A revision that will map your
Jun 25, 1997 old TRND72 Performance Group data into the new TRND72GO
is planned so you can track before/after Goal Mode.
Jun 25 note: Cosmetic revisions (LABELs, DROPs) added
after first (Jun 24) MXG 15.03 was created.
Thanks to Mike Billy, Banc One, USA.
Change 15.134 Support for IXFP (Iceberg/IBM RVA) new subtype 6 and 7
EXICEDDS creates three new datasets:
EXICESNP Subtype Dataset Description
EXICEUTL 6 ICEBRGSN SNAPSHOT - EXTENTS SNAPPED
IMACICE 6 ICEBRGDD SNAPSHOT - DDSR EXTENTS
VMACICE 7 ICEBRGUT Space Utilization
Jun 19, 1997 Note that APAR OW25126 corrects errors in subtype 7 in
Mar 30, 1998 sites when Snapshot microcode is installed on an RVA
(RAMAC Virtual Array) subsystem. Put its PTF on!
===>>> Text updated March 30, 1998. This change created an
INCOMPATIBILITY in dataset ICEBRGDE. Before this change,
variable ICEVERS was a numeric and stored in 4 bytes, but
this change (in MXG 15.04) changed ICEVERS to character
of length one in dataset ICEBRGDE, and then created new
new variable ICEVERSN as a numeric stored in 4 bytes in
datasets ICEBRGSN and ICEBRGDD. In retrospect, exactly
why I did it this way is unclear, but I suggest for now,
simply drop the variable ICEVERS from ICEBRGDE, since it
really is not needed to be kept (it's a record version,
but I think there's only been one and it's always a 1?).
Edit member IMACICE and replace the MACRO _KICEDEL %
null definition with
MACRO _KICEDEL DROP=ICEVERS %
to drop the variable from dataset ICEBRGDE to avoid the
conflict. I think ITSV and SAS/CPE can tolerate the
absence of ICEVERS better than its conflicting presence.
This is a preliminary answer, and will be updated if it
does not resolve the conflict.
Thanks to Dan Almagro, Automobile Club of Southern California, USA.
Thanks to Ken Williams, Sun Life of Canada, ENGLAND.
Change 15.133 In sysplex, timestamps converted from "GMT" to "LOCAL"
VMAC30 were off by the number of "leap seconds", currently 20.
VMAC110 These "GMT" time values are actually "Absolute" values
VMACDB2 that include leap seconds; MXG erroneously "floored" the
Jun 18, 1997 delta value to get only the GMT offset hours to convert
"GMT" to "Local". Now, MXG keeps the full delta between
"Absolute" and "Local" to properly convert to local; if
the GMT offset value itself is not exact, it shows the
number of leap seconds in your system (CVTLOS).
Records GMT Offset Comment
30's SMF30IST-INTBTIME Calculated, leap seconds
42 st 6 S42JDGMO Provided, leap seconds
72 GMTOFFTM Provided, leap seconds
100-102 SMFTIME-THISSTCK Calculated, leap seconds
110 MCTMNTAD Provided, leap seconds
Unless you were comparing events with your wrist watch,
you might not have noticed this 20 second error in the
timestamps, but see the discussion in MVS Technical Notes
in Newsletter THIRTY-TWO for synchronization impact.
In addition, this change now converts SYNCTIME to local
time in type 30; it was already converted from Absolute
to local in RMF datasets, so now it is consistent!
Change 15.132 MXG 15.01 or MXG 15.02 cosmetic errors. TESTOTHR brings
VMXGHSM TYPEWWW in, but the FILENAME statement causes dataset not
TYPEWWW found under MVS, so it was commented out. Uninitialized
Jun 18, 1997 variable MCTFLG3 message was corrected by spelling it as
MCTFLGS in the LABEL statement.
Thanks to James McCullough, Economical Mutual Insurance Co., USA.
Change 15.132 DB2 Trace dataset T102S106 was not correct for new fields
VMAC102 added to QWP4 section in DB2 3.1, 4.1, and 5.1. The new
Jun 17, 1997 fields include MXG-constructed QWSU_SEC Service Unit per
CPU-Second value of the machine on which this DB2 Subsys
is executing!
Thanks to Jon Fritz, Levi Strauss & Co., USA.
Change 15.130 Variable SMF94ETO existed in MXG 14.14 but did not exist
VMAC94 with MXG 15.01 or 15.02, while variable SMF94EPM had the
Jun 17, 1997 TOTAL*EJECTS but was labeled POST*EJECTS. The real IBM
documentation now shows that only SMF94ETO should exist
and is the TOTAL*EJECTS, so MXG variables are no longer
created.
Thanks to Robert Miles Standish, Dean Witter Trust Company, USA.
Change 15.129 Label for DB2 QBSTDMC and QBnTDMC variables is now
VMACDB2 QBSTDMC='DATA MANAGER*THRESHOLD*REACHED'.
Jun 17, 1997
Thanks to Joseph Fordham, UPS, USA.
Change 15.128 Dataset TYPE116 MQ Series variable QWHCTNO is now labeled
VMAC116 QWHCTNO='CICS*THREAD*IDENTIFICATION*ADDRESS' instead of
Jun 17, 1997 Thread Number, as IBM now explains it is a control block
address of the thread, so '004dF3D4'x is a valid value.
The address can be reused, so it is not a unique value.
Thanks to Helmut Roese, COM Gmbh, GERMANY.
Change 15.127 AS/400 variable AS400SYN is missing if length of SYSTEM
VMACQAPM is less than 8 characters. The original logic is now:
Jun 16, 1997 ELSE IF GKEY=' S' THEN DO;
LENSYS=MIN(LENGTH-6,8);
INPUT @7 GDESS $VARYING8. LENSYS @;
AS400SYN=GDESS;
CALL SYMPUT('AS400SY',AS400SYN);
END;
Thanks to Len Marchant, Coca Cola Enterprises, USA.
Change 15.126 Counting the Average and Maximum Logged On TSO Users each
ANALCNCR 15 minutes (using PDB.JOBS TSO Session records) is done
Jun 15, 1997 in a new example in the comments in member %ANALCNCR.
Thanks to Dan Gilbert, Bergen Brunswig, USA.
Change 15.125 The detection of VIO was based solely on DEVNR='7FFF'x
VMACUCB but as this could now be a legitimate device address with
Jun 15, 1997 4-digit UCBs, the test for VIO in VMACUCB was changed to
require DEVCLASS='00'x also. For type 30 DD segments,
the DEVCLASS for VIO is zero, but in type 14/15 records,
the DEVCLASS is whatever device was installation defined
for VIO space calculations. Fortunately, there is a bit
set in type 14/15 records for VIO, which MXG uses to set
DEVICE='VIO' even though DEVCLASS is non-zero.
Change 15.124 Support for APAR OW25263 adds variables JFCTDSI1 (bits
VMAC1415 for 128 track mode, "1/2 inch/320 meter particle media",
Jun 15, 1997 and JFCTDSI2 (bits for Compaction=YES) for 3590's.
Change 15.123 Comments were revised to describe IMACKEEP as archaic;
IMACKEEP its function was replaced by the MXG Exit Facility that
Jun 15, 1997 is described in Change 10.175.
Thanks to Thierry Van Moer, Comparex Information Systems, BELGIUM.
Change 15.122 Label for variable R744SCN should have been spelled
VMAC74 CONTENTIONS.
Jun 15, 1997
Thanks to Bob Gauthier, American Stores Company, USA.
Change 15.121 DB2 Trace IFCID=125. Variables QW0125NR and QW0125RI are
FORMATS now INPUT as "&IB.4." instead of "&PIB.4." and formats
VMAC102 MGD125N and MGD125R decode their negative values:
Jun 15, 1997 VALUE MGD125N
-2 = '-2:NO STG OR MAX EXCEEDED'
;
VALUE MGD125R
-1 = '-1:RETRIEVE NOT ATTEMPTED'
-2 = '-2:NO STG AVAILABLE'
-3 = '-3:NUM RIDS EXCEEDED MAX LIMIT'
;
Thanks to Dr. Alexander Raeder, Karstadt AG, GERMANY.
Thanks to Hartmut Beckmann, Karstat AG, GERMANY.
Change 15.120 Change 14.300 (which only affected old RMDS 1.3 and 1.4)
VMACRMDS was not made as documented, causing variables RMDSARN and
Jun 12, 1997 RMDSARI to be missing; the change is now made!
Thanks to Steve Colio, CIGNA Corp, USA.
Change 15.119 You cannot use Tandem's ftp program to upload Measure's
ADOCTAND "Structured" data files because Tandem's ftp sends the
UTANDSTR entire file including header, data records, and trailer.
Jun 17, 1997 Products like BCOM and Connect Direct do understand
Tandem's structured files and will send only the data
records, so they don't have this problem!
If you are stuck with Tandem's ftp, you will have to
convert the Structured file into an Unstructured file
and then you can use their ftp to upload that data.
Member ADOCTAND has been updated with a Tandem-supplied
example that will create an unstructured file from the
structured MEASCOM data files using Tandem utilities.
In addition, although I hope you never need it, member
UTANDSTR will create Unstructured Measure files from
Structured ones that have already been shipped to MVS.
You will have to supply the LRECL of each file in the
program, and will have to EDIT the dataset names, and
you must use RECFM=FB and LRECL=4096 when you upload
their structured file with their ftp.
If Tandem ever changes their ftp program to recognize
their own records, the double processing can go away.
Thanks to Tim Crocker, AT&T UCS, USA.
Thanks to Jack Driscoll, Tandem, USA.
Change 15.118 TYPE94 record without APAR OW27369 caused INVALID AUDIT
VMAC94 SECTION error; the test IF SMF94SDL GE 76 THEN INPUT must
Jun 6, 1997 be changed to IF SMF94SDL GE 84 THEN INPUT.
Thanks to Will Evans, Consolidated Freightways, USA.
Change 15.117 Changes in NPM that were overlooked long ago:
VMAC28 -LCSLxxxx variables added to CSL segment for HPR bytes and
Jun 4, 1997 frames transmitted, received, and discarded, and LCSLCON5
thru LCSLCON7 flag bytes are now kept.
Change 15.116 TLMS 5.3 (archaic, 5.4 has been out for some time) dates
VMACTLMS were not converted completely; the conversion code from
Jun 4, 1997 the 5.4 code was moved to the 5.3 section of VMACTLMS
Thanks to Jim Van Arsdale, IBM Global Services, USA
Change 15.115 MONTHBLD failed for dataset TYPE77, because WEEKBLDT did
WEEKBLDT not have the correct BY list (but WEEKBLD was correct!).
Jun 4, 1997 WEEKBLDT now matches BUILDPDB/WEEKBLD/MONTHBLD.
Thanks to Mike Rouncville, Rose's Stores, Inc., USA
Change 15.114 TMON/DB2. Previously un-tested subtypes "DE" and "DW" had
VMACTMDB coding errors that surfaced when real data was read.
Jun 4, 1997 -The "DW" record INPUT was realigned, DWWLRTME was changed
Jun 24, 1997 from TIME8 to HH &NUM.2 and DWWLRDAT's JULIAN input was
revised so the code will work under EBCDIC or ASCII SAS,
and the variable text is now correctly input.
-The "DE" record has the common header; the test
IF LMRKREC='DA' OR LMRKREC='DB' THEN INPUT
was expanded to also test OR LMRKREC='DE'.
Thanks to Tricia Dudley, SAS Institute Cary, USA.
Thanks to Luc Gariepy, Regie des rentes du Quebec, CANADA
Change 15.113 DB2 Trace SMF type 102 subtype 125.
VMAC102 -The +2 after QW0125MR must be +1. This error affected
Jun 5, 1997 only variable QW0125NR.
-The DO OFFSET=QWT02R2O in the IFCID 125 section was
replaced with DO _I_=1 to QWT02R2N logic from IFCID 172.
Thanks to Dr. Alexander Raeder, Karstadt AG, GERMANY.
Thanks to Hartmut Beckmann, Karstat AG, GERMANY.
Change 15.112 Support for APAR OW26451/OW26453/OW26497 added fields for
VMAC42 MAXRSPTM and MAXSRVTM (Max Response/Service Time) to data
Jun 3, 1997 set TYPE42DS. Other minor changes were made.
Change 15.111 Support for TANDEM D42/D43/D44/G02 releases.
VMACTAND Documentation indicates compatibility, in that new data
Jun 3, 1997 fields are added at the end of the record, but you will
Jun 20, 1997 still find it INCOMPATIBLE, because you will have to
change the LRECL of each MVS dataset into which the data
records are sent when you install the versions with new
data. Initially, it appears there is no problem with
D42, but I need to review the later three systems and
will update this note when I know more.
Thanks to Tim Crocker, AT&T Universal Card Services, USA.
Change 15.110 Enhancements so MXG Tape Mount records that will be in
VMACTMNT ML-14 of ASMTAPES (see later Change) are coded now:
Jun 2, 1997 -New variables are added to TYPETMNT:
DEVFLGS, UCBSTAT, UCBFL1, UCBSTAB, DDNAME, STEPNR,
ALOCSTRT, and TMNTMAIN.
-Existing unpopulated variables will be populated by the
changes in ASMTAPES at ML-14:
READTIME, INITTIME
-Variable JESNR now supports 5-digit JES numbers.
-The interval start value did not replace ALCSTIME with
the interval-start time for interval records created
if a job spans a day boundary; in error, the allocation
timestamp of the original allocation was stored.
Thanks to Mark Kemig, VF Services, Inc., USA.
Change 15.109 Format MGBYTRT (bytes-per-second) truncates on the left
FORMATS (1099KB/Sec prints as 99KB/Sec) because the DEFAULT=8 in
May 30, 1997 the PICTURE MGBYTRT statement must be DEFAULT=10.
After making that change, you need only to re-build your
format library by %INCLUDE SOURCLIB(FORMATS); (with the
//LIBRARY DD allocated with DISP=OLD under MVS).
Thanks to Leigh Ann Payne, Wachovia Operational Services Corp, USA.
Change 15.108 DCOLLECT variable DCASRCI (dataset DCOLCLUS) is relabeled
VMACDCOL to 'USE HARBC/HURBC*INSTEAD OF*HARBA/HURBA?' to flag that
May 29, 1997 variables DCAHARBC and DCAHURBC, according to IBM, should
be used for VSAM space (high RBA) allocated and used in
place of DCAHARBA/DCAHURBA variables. Also, variables
DCAHARBC and DCAHURBC are now formatted MGBYTES.
In merging DCOLDSET and DCOLCLUS for VSAM datasets (to
get HLQ classifications by storage group with accurate
allocated/used statistics), John noted that sometimes,
the High Used RBA was greater than the Allocated Space
(i.e., DCAHURBC GT DCDALLSP). Chuck tracked this to obs
for the Index component for VSAM datasets which used
IMBED or REPLICATE; it appears that the index bytes that
are imbed/replicated in the Data Component are being
counted in the RBA for the Index Component, causing it to
appear to have more "used" than "allocated".
Thanks to John Astle, National Australia Bank, AUSTRALIA.
Thanks to Chuck Hopf, MBNA, USA.
Change 15.107 New TYPE8025 dataset is now created for RACF Event 25,
EXTY8025 RACF RVARY Command. Variable RACFTYPE was removed from
IMAC80A the KEEP= list, as it contained the TYPE value of only
VMAC80A the last segment in a type 80 record. (Variable TYPSTRNG
May 29, 1997 lists all segment types found in each record).
Thanks to Joseph Faska, Depository Trust Company, USA.
Change 15.106 Support for APAR OW20921 which created TYPE42VT dataset
EXTY42VT with response time statistics like TYPE42SR, but for the
IMAC42 VTOC, VTOC Index, and VVDS for each volume. This APAR
VMAC42 also added stripe count and flag variables to TYPE42DS.
May 28, 1997 In the new TYPE42VT, there are occasional observations
with AVGIOQMS less than zero (-.127 maximum), indicating
that the data is not exact.
Thanks to Tim Vanderhoek, Fidelity Systems Company, USA.
Change 15.105 Variables in dataset QAPMAPPN read in after ANDBE8 were
VMACQAPM wrong; the offset 1464 was incorrectly repeated in two
May 27, 1997 lines. Subsequent offsets have now been corrected.
Variable ATCSDR is INPUT @558 vice @588 now.
Thanks to Freddie Arie, Lone Star Gas, USA.
Change 15.104 Duplicate variable names were corrected.
VMACPW -VMACPW: TOIOOPCT should have been TOIOPCRT, first
VMAC102 SWINOPCT is now SWINCTCT and first SWOUOPCT is SWOUCTCT.
VMACSTRS -VMAC102: second QW0221AN was removed
May 26, 1997 -VMACSTRS: second TOTSERV was removed
Thanks to Freddie Arie, Lone Star Gas, USA.
===Changes thru 15.103 were included in MXG 15.02 dated May 23, 1997===
Change 15.103 Support for RACF data for OMVS RACF using IBM's IRRDBU00
EXRAC120 unload utility creates two new datasets, thanks to this
EXRAC270 user-contributed enhancement. New datasets are:
IMACRACF Dataset Description
VMACRACF RACF0120 Group OMVS Data
May 22, 1997 RACF0270 User OMVS Data
Thanks to Ben Cowan, University of Nevada System, USA.
Change 15.102 Support for Filetek's Optical Disk SMF record creates
EXFTEKIC three new datasets:
EXFTEKID Dataset Description
EXFTEKGL FILTEKIC IC Command Link Task Record
IMACFTEK FILTEKID ID Data Transfer Task Record
TYPEFTEK FILTEKGL GL Global Statistics Record
VMACFTEK This is preliminary; the Global record is not complete.
Thanks to Joseph Faska, Depository Trust Company, USA.
Change 15.100 A new macro that compares two SAS Data Libraries and
VMXGCOMP lists datasets in one and not in the other, and then
May 22, 1997 generates PROC COMPARE on all datasets that are common
to both Data Libraries. The observations compared are
limitable via an option.
Thanks to Chuck Hopf, MBNA, USA.
Change 15.099 A new macro that resets the setting of most SAS Options
VMXGOPTR (those whose name is 8 bytes or less and which can be
May 22, 1997 changed after SAS Initialization). The current setting
is kept so that MXG can change it and then reset it to
the original value (Change 15.098 uses it in VMXGSUM to
reset the OBS= option). Documentation is in the member.
Thanks to Chuck Hopf, MBNA, USA.
Change 15.098 Enhancement to VMXGSUM that uses the new VMXGOPTR macro
VMXGSUM to examine SAS Options to detect that OBS=n (as opposed
May 22, 1997 to the default OBS=MAX) was specified. OBS=0 causes the
PROC CONTENTS (used to determine which variables to keep)
to have no observations, so the list of kept variables is
wrong. (Even OBS=n will cause trouble, if n is less than
the number of variables to be kept). With this new
enhancement, VMXGSUM detects the OBS=value, sets OBS=MAX
for the Keep-Variable-Create phase, and then resets OBS
to its original value. This greatly improves MXG QA runs,
which use OBS=0, by eliminating unnecessary messages!
Additionally, VMXGSUM now allows use of USER= and the
TEMP01/TEMP02/TEMP03 options.
Thanks to Chuck Hopf, MBNA, USA.
Change 15.097 RACF "SKIPPED SEGMENT RACFEVNT=xx:desc RACFTYPE=nn ...."
VMAC80A messages are normally harmless; they indicate that your
May 22, 1997 RACF record contained a segment (RACFTYPE=SMF80DTP=nn)
that MXG did not know about in creating TYPE80A dataset.
(The event causing the type 80 record is RACFEVNT, which
might not even be an event of interest to you!).
You can look at Table 2. Relocate Section Variable Data
in Chapter 4 in "RACF Macros and Interfaces" SC23-3732
to see a) is the DTP value documented, and b) do you
care! If the segment contains data of interest, when I
get a hex dump of a record with the new segment, I will
decode the segment and add new variable(s) to the event
dataset; if the data is of no interest, I add logic:
WHEN (91) DO; /*FOUND IN 27:GENERAL AUDIT, NO DOC*/
INPUT +RACFDLN @;
END;
to member VMAC80A to bypass the segment without notice.
(the example skips the un-documented DTP=91 value found).
Thanks to Bruce Hewson, CITICORP, SINGAPORE.
Change 15.096 Inconistency analysis uncovered these flaws:
VMACNSPY -Variable APLUIDR in VMACNSPY is now format $HEX8 (the
VMACLMS length was only two bytes because $HEX4. preceded its
VMACOMCI INPUT statement).
VMACRMDS -Variable TDBSYS in VMACLMS is now initialized to a value
May 21, 1997 of 'TMS ' so the kept length is eight bytes.
Variable ISITSL in VMACLMS is LENGTH $3, and the INPUT
@53 is changed to ISITSLX, as are following five IF's.
-Variable EWAITDC in VMACOMCI was removed from $NOTRAN
informat list (because INFORMAT was seen before INPUT,
variable had kept length of only one).
-Variable RMDSFORM is set LENGTH $9 because later code
INPUTs as 9, but first occurrence was for 8.
Thanks to Chris Weston, SAS Institute Cary, USA.
Change 15.095 Support for DB2 Version 5.1.0.
FORMATS New formats $MGD022A, MGD022Q, and $MGD221M were added.
VMACDB2 Type 101 Record (DB2ACCT) Compatibly changed.
VMAC102 Eight new variables added:
May 21, 1997 QWACSUCV='THIS CPU SU_SEC*SERVICE*UNITS PER*SECOND'
QXCOORNO='PARGROUPS*EXECUTED*COORD PARM NO'
QXCRGTT ='CREATE*GLOBAL*TEMPORARY*TABLES'
QXISORR ='PARGROUPS*EXECUTED*REPEAT*READ'
QXSTREOP='REOPTIMIZATION*OCCURRENCES'
QXXCBPNX='PARGROUPS*INTENDED*RUN*DATASHARE'
QXXCSKIP='BYPASSED*DB2S*NOT ENUF BUFFERS'
QBGADG ='CF UNREGISTER*PAGE*REQUESTS'
Type 100 Subtype 0. DB2STAT0. Compatibly Changed.
One new Q9STxxxx variable, three QDSTxxxx variables,
and six QXxxxxxx variables added.
Type 100 Subtype 1. DB2STAT1. Compatibly Changed.
Twelve QBGLxx variables added.
Type 100 Subtype 1. DB2GBPST. Compatibly Changed.
Twelve QBGLxx variables added.
Type 100 Subtype 2. DB2STAT2. Compatibly Changed.
One variable, QDBPXSQT, added.
Type 100 Subtype 3. DB2GBPAT. Compatibly Changed.
One variable, QBGBGAS, added.
Type 102 Record. Only IFCIDs listed have been validated.
IFCID 022. INCOMPATIBLY changed. Record restructured
Fifteen new variables added.
IFCID 221. INCOMPATIBLY changed. INPUT STATEMENT EXCEEDED
Record restructured. Ten new variables added.
IFCID 222. Compatibly changed. Three new variables.
However, MXG created Pipe Duration in variable QW0222SM
by subtraction, but now IBM uses that name, so Pipe
Duration time is now calculated in variable QW0222PD.
IFCID 231. Compatibly changed. Five new variables.
Thanks to Ted Blank, IBM, USA.
Change 15.094 -Variable R723TYPE was kept as LENGTH $23 because it was
VMAC7072 not in the LENGTH $1 statement, so SAS took it's length
VMAC110 from the MGRMFTY format. Now it is kept as LENGTH $1.
VMAC74 -Variable LDGDSAIN was listed both as $1 and $2, but is
May 21, 1997 now only in the $1 list.
-Variable R744QSIZ is now formatted MGBYTES; the variable
R744QFLG is formatted $HEX2. and added to $NOTRAN.
-Variable MCDFLG3 (IF '1.......'B, DATASET is KB) is now
input @291 MCDFLG3 &PIB.1. in the MCD section, formatted
HEX2., labeled, and kept.
Thanks to Neville Wright, Telstra, AUSTRALIA.
Thanks to Lindsay Oxenham, Telstra, AUSTRALIA.
Change 15.093 Comments were revised to explain why the error messages:
JCLPDB6 ERROR: ALL VALUES MISSING FOR PLOT OF xxx
May 21, 1997 ERROR: THERE ARE NO VALID OBSERVATIONS FOR VARIABLE yyy
may print on the SAS log when you run the JCLPDB6 sample
job to build the PDB, and why they actually tell you the
BUILDPDB run was successful. (Briefly, they are from the
ANALxxxx members, and to have gotten that far is to have
successfully built the PDB library; they occur because of
"shotgun" reports that include old and new variables so
everybody gets some sample report output.)
Thanks to Robin Mitchell, SmithKline Beecham, USA.
Change 15.092 MXG 15.01 only. An incomplete CICINTRV member was sent
CICINTRV in MXG 15.01 (last minute changes to add READTIME were
May 20, 1997 tested but not migrated); now I realized that the change
was redundant, as CICSSTCK is logically the READTIME!
Note that the DURATM variable in PDB.CICINTRV is the sum
of the durations of the discrete intervals that were
summed into this observation, and might not be the delta
between COLLTIME values. MXG defaults to HALFHOUR, but
if you are only recording USS records, and you took the
IBM default interval, your records will be written every
three hours, so PDB.CICINTRV will have an obs with the
COLLTIME of the half hour preceding the end of that
interval, but the DURATM value will be the 3 hours
represented by the actual data in that observation.
Thanks to Ben Cowan, University of Nevada System, USA.
Change 15.091 Variables ACTBYTES and ACTPAGES from TYPE26J2 are added
IMACPDB to macro _PDB26J2 in IMACPDB so that they will be kept in
May 20, 1997 dataset PDB.JOBS. The ACTBYTES is the total number of
bytes of SYSOUT text that was created by each job, and is
useful in determining the JES2 Track Group Size.
Thanks to Clark Jennings, Reynolds Metal, USA.
Change 15.090 -Support for Microsoft Windows NT 4.0 Service Pack 2 which
EXNTACSR INCOMPATIBLY inserted a null field in the Process record,
EXNTCNFI and support for Version 5.0 of MS Exchange, which added
EXNTCNIN (need I say INCOMPATIBLY) eight real fields and 33 null
EXNTHTIN fields to MSEXCHDS and MSEXCHPR datasets. NRDATA count
EXNTMSIM was corrected for MSEXCHDB dataset.
EXNTMSIP -Support for NTSMF Version 2.0. Change 15.027/MXG 15.01
EXNTMSWB did not (in spite of saying so) handle the new records.
EXNTWBPR -Support for several new datasets (new objects):
EXNTWSPR Dataset Object
IMACNTSM ACTVSRVR Active Server Pages
VMACNTSM CONTINDX Content Index
May 20, 1997 CONTINFI Content Index Filter
HTTPINDX Http Contents Index
MSEXCHIM MS Exchange Internet Mail Service
MSEXCHIP MS Exchange Internet Protocols
MSEXCHWB MX Exchange WEB Component
WEBPROXY WEB Proxy Server Cache
WINPROXY WinSock Proxy Server
-Of the 68 objects now supported, all but 16 have been
tested with data records.
Change 15.089 MXG 15.01 only. INPUT STATEMENT EXCEEDED for type 94 SMF
VMAC94 record. SMF94VR3 should be +2 vice +1, while variables
May 17, 1997 SMF94VDC,VDX,VDN and VDA should be &PIB.1. vice &PIB.2.
This only affected the new section added for VTS.
Thanks to Pat Quinette, Principal Mutual Life Insurance Co., USA
Change 15.088 MXG 15.01's new ANALDDCN member inadvertently contained
ANALDDCN "./" IEBUPDTE control cards for several IMACxxxx members,
PROCSRCE so when you unloaded the IEBUPDTE file to create your MXG
May 8, 1997 SOURCLIB, those "./"s created those IMACs from ANALDDCN
(and by design they DROPed most variables from type 30s).
But fortunately, the real "./" cards for those IMACxxxx
members were found later on in the MXG tape, so they
successfully replaced the incorrect members, so your
SOURCLIB was correctly built!
Thank you Heavenly Father: if the member name had been
ZNALDDCN, your SOURCLIB would have been wrong!).
It used to be that IEBUPDTE set a CC=4 when a new member
replaced an existing member, but no longer; the IEBUPDTE
set CC=0. The only clue is in the print message "IEB816I
MEMBER NAME FOUND IN NM DIRECTORY. TTR IS NOW ALTERED"
(but IEB messages print to the //SYSPRINT DD, which is DD
DUMMY because it is hugh (1,005,099 print lines, 126 MB,
because IEBUPDTE prints all 980,991 lines of MXG 15.01,
plus 8 lines of IEBxxxx messages and blank lines for each
of MXG's 3,200 members, plus pages and the JES log!).
I have revised PROCSRCE to ERROR ./ cards found in its
input while creating the IEBUPDTE format file, so this
error should not be seen again.
Thanks to Freddie Arie, Lone Star Gas, USA.
===Changes thru 15.087 were included in MXG 15.01 dated May 6, 1997===
Change 15.087 QA tests for MXG 15.01 generated these corrections:
JCLQAJOB -CICINTRV. Variables SDGTSUPR/SDGTTKN were misspelled and
May 6, 1997 are now SDGSSUPR/SDGSTKN.
-VMACDALO. Variables DALODDN/CODE/JFCB are now labeled.
-DIFFDB2. Variables PREVGN,DIFDB21,PREVBPID are dropped,
and dropped only once.
-VMACIMS. Many unlabelled variables are now labeled, and
LABEL statements consolidated.
Change 15.086 Support for World Wide Web Proxy logs in Common Log
TYPEWWW Format to track an installation's access frequency and
May 4, 1997 destinations for URLs and IP addresses via the WWW is
provided in this user contribution, which is based on
Dan Squillace's CMG96 paper. Comments in TYPEWWW by
Brian document his approach to decoding the log into
new MXG dataset TYPEWWW.
Thanks to Brian Farley, Reliastar Life Insurance Co., USA.
Change 15.085 A new utility for ASCII platforms that produces a hex
UDUMPEBC dump like the LIST; statement on MVS, with characters
May 4, 1997 decoded as EBCDIC rather than ASCII (so you can read the
hex dump of your SMF record on your PC!). This utility
was written and contributed by Dan (but I actually made
it into a %MACRO with arguments!).
Thanks to Dan Kaberon, Hewitt Associates, USA.
Change 15.084 Sample CLISTs for MXG and SAS execution under TSO.
CLMXGSAS
May 4, 1997
Thanks to ???, ????, USA.
Change 15.083 Documentation. The discussion of why you get fractional
ADOC26J2 priorities in variable ONPRTY in PDB.JOBS or TYPE26J2 now
May 4, 1997 matches the code in VMAC26J2. The old documentation said
that MXG FLOORed ONPRTY to an integer, but it never did;
ONPRTY has always been a real, rather than an integer.
Thanks to Brian Sanger, Eagle Star Group Services Ltd., ENGLAND
Change 15.082 Support for Boole and Babbage IMF 3.2 (for IMS 6.1) is
VMACCIMS already in place in MXG. The changes were a) increase
May 4, 1997 in maximum DBD segments in a record (from 50 to 500, and
associated record length increase) but MXG always reads
whatever segments are in the record, and b) IMF 3.2 now
supports the year 2000 (by documenting dates as yyyyddd)
but MXG support was also already in place for that too!
No code was changed by this change.
Change 15.081 This user contribution is a revision of TYPEIMS7 (which
IMACIMSD reads IMS log records 07/08 for transactions and BMPs),
TYPEIMSD for IMS DBCTL, because TYPEIMS7 threw away DBCTL events.
May 4, 1997 The documentation of the significant logic necessary to
capture IMS DBCTL from the IMS log is provided also by
Bruce, in the comments in member TYPEIMSD.
Thanks to Bruce Galle, Talbots, Inc., USA.
Change 15.080 The revisions in Change 14.349 to support Stress Test's
VMACSTRS enhancements in Release 3.3.6 accidentally failed to
May 4, 1997 INPUT some variables from the earlier version.
Change 15.079 ASUMUOW combines CICS and DB2 transactions by UOW, or
ASUMUOW unit of work, but IRESPTM was kept from the last CICS
May 4, 1997 transaction physically encountered, rather than the
first (initiating) transaction. The ENDTIME should have
been a MAX() rather than MIN(), and QWHCATYP is now in
the DROP list as it is unneeded after first step.
Thanks to Tom Elbert, John Alden, USA.
Change 15.078 DB2 variable QWHCATYP printed a value of '41' when a
FORMATS value of 11 decimal or 0Bx was found. (I now know that
May 4, 1997 the 0Bx value is for "DB2 Utilities" and the MGDB2TY
May 9, 1997 format that decodes QWHCATYP was updated May 9, 1997,
but at the time, the value 0Bx was not in the format.)
Why did MXG print 41 when the value was actually '0B'x?
Because there was a logical error in the MGDB2TY format
for undefined values; the OTHER format was $HEX2, but it
should have been HEX2, because QWHCATYP is a numeric
variable! Using $HEX for a numeric variable in the OTHER
operand of PROC FORMAT is a SAS "feature" that prints not
the hex of the data value, but rather prints the hex of
the internal representation of the numeric value (as
stored by each platform). Since numerics are internally
stored as floating point numbers, the '41'x printed was
the hex value of the first byte of MVS's internal value
of '41B00000'x, where the '41' is the exponent and 'B0'
is the mantissa. But under Windows, a '00' was printed,
because Intel stores eleven as '00002640' with its
exponent in the last byte. In any event, using HEX2
instead of $HEX2 correctly shows the 0B value under MVS
or Windows. (This was the single instance of $HEX for a
numeric in FORMATS.)
Thanks to Roman Jost, Gjensidige, NORWAY.
Change 15.077 The MXG Tape Allocation Monitor records had new fields
ASUMTALO added in ASMTAPES in MXG 14.14 that are now INPUT into
VMACTMNT tape allocation dataset TYPETALO by member VMACTMNT:
ZSUMTALO ALEERROR='ALLOCATION*ERRORS*RECORDED'
May 3, 1997 RESGROUP='RESOURCE*GROUP*NAME'
RPTCLASS='REPORTING*CLASS*NAME'
SRVCLASS='SERVICE*CLASS*NAME'
TMNT008I='TMNT008I*MESSAGE*ISSUED?'
TMNTTYPE='TYPE*OF*MOUNT*OR ALLOCATION*EVENT'
WLMNAME ='WORKLOAD*NAME'
XMEMABND='CROSS*MEMORY*ABENDS'
In addition, ML-12 added the new subtype 5 interval-end
record (to keep track of long-running allocations) but
MXG 14.14's VMACTMNT skipped over the subtype 5 record.
With this change, VMACTMNT now OUTPUTS the subtype 5
into TYPETALO, and this requires a new ASUMTALO member
that exploits these interval observations to improve the
accuracy of counts if you have long-running allocations.
This logic is more accurate than prior ASUMTALO, but may
not be perfect until the ASMTAPES ML-14 monitor provides
time-synchronized subtype 5 records. I have copied the
MXG 14.14 ASUMTALO member into ZSUMTALO and modified it
so that subtype 5 records are deleted, so you could use
the new VMACTMNT with the (renamed) member ZSUMTALO in
case you have problems. Check the counts closely.
NOTE: YOU MUST IMPLEMENT MXG 15.01 MEMBERS TYPETMNT AND
ASUMTALO SIMULTANEOUSLY - IF YOU HAVE A TAILORED
ASUMTALO MEMBER IN YOUR USERID.SOURCLIB, YOU MUST
RETROFIT YOUR TAILORING INTO THE 15.01 ASUMTALO.
(Or use the ZSUMTALO as described above).
The ASUMTALO enhancements use SPIN-type logic as well as
determining which system's SMF had the earliest cutoff of
SMF data (earliest last datetime). Data is "spun" to
SPIN.SPINTALO if it is after the cutoff or if it is the
last observation for an allocation event and it is also
an interval record (we have to adjust the start time of
the real allocation record during the next day's ASUMTALO
so that we don't count the same drive-interval twice.
Thanks to Chuck Hopf, MBNA, USA.
Change 15.076 SAS Warning: ARGUMENT 3 TO MACRO FUNCTION %SUBSTR IS
VMXGTAPE MISSING OR OUT OF RANGE when the length of the DSN= macro
May 3, 1997 argument was three characters or less, but now will work
with any length DDNAME. (VMXGTAPE is a %MACRO to find
out if a DDNAME or SAS DATASET is on tape.)
Change 15.075 Validation of Change 15.061 uncovered opportunities.
ANALRMFR -Updates were made to logic for IOQU reports
May 3, 1997 -Incorrect paging, added array IOPI(9) IOPINSTL, added
RETAIN for IOP, ACTIVITY RATE and AVG Q LNGTH variables
during MERGE.
-MXGCHAN, changed PS=&PGS back to PS=66, because with
PS=&PGS and N=PS (to arrange the contents of an entire
printed page) does not work correctly.
-MXGSMRY moved SWAPRATE=. and PRT=. to SUMRPT dataset to
eliminate "MISSING VALUES" messages.
Change 15.074 Support for Altai's ZARA Tape Management Release 1.2.
TYPEZARA Well, almost. I have created all of the new variables
VMACZARA in datasets ZARADSN and ZARAVOL, an enhanced TYPEZARA's
May 3, 1997 back-end logic to also keep the new variables, but I do
not have the DSECT for the header yet, nor do I have any
test data yet, to the new code is in a never-execute DO
group (IF RECTYP= -99 THEN DO;) Check for an update to
this change when actual support has been tested. Note in
this rare instance, the documentation is done before the
code changes are complete!
Changes to ZARADSN dataset:
Variables added:
FILABEND FILCONT FILCRSID FILENEXT FILEXPIR FILRCFM
FILTPSTK
FILRECFM was replaced by FILRCFM, now is CHARACTER
FILFLAG1 was replaced by FILABEND FILCONT FILEXPIR
Changes to ZARAVOL dataset:
Variables added:
VOLAPERR VOLATRER VOLATWER VOLCBLVL VOLCHECK VOLCLEN
VOLCREAT VOLFILEA VOLLABEL VOLLOCK VOLSTAT1 VOLSTAT2
Variables no longer created in Version 1.2:
VOLSECUR VOLAPPID VOLGRPID VOLOBOX VOLFLG1 VOLFLG2
VOLPOOL
VOLLABL was replaced by VOLLABEL, now is CHARACTER
Thanks to ???, Nissan Motor Manufacturing (UK) Limited, ENGLAND.
Change 15.073 Support for Virtual Tape Server additions to SMF type 94
VMAC94 provide an excellent set of measures for VTS physical and
May 2, 1997 logical volume activity, including counts of mounts,
by type, lots of min/max/avg for times to mount physical/
logical volumes, time virtual drives were mounted, the
number of concurrent physical/virtual drives mounted, and
bytes read/written to host channel/from tape devices!!
Change 15.072 Variable FTPCLHST in ILKAST20 and ILKAST21 datasets from
VMACILKA Interlink has always been wrong. The "FTPCRHS3" in the
May 2, 1997 create for FTPCLHST should have been "FPTCLHS3".
Thanks to Chris Weston, SAS Institute Cary, USA.
Change 15.071 Support for MEMO subtype 8 record creates new MEMODIST
EXTYMEMD dataset; subtype 8 records are written by MEMO during a
VMACMEMO distribution by an internal process.
May 2, 1997
Thanks to Thomas Peiper, Enator, SWEDEN.
Change 15.070 The start-up observation in DB2STATS and other DB2 Stats
DIFFDB2 datasets will have lots of negative values, and there are
May 2, 1997 two observations with QWHSISEQ=1 created for each real
startup. You can delete both the good and the bad start
up record with IF QWHSISEQ=1 THEN DELETE; to clean up
your reports quickly, but the logic error fixed by this
change applied to each of the Stats datasets and involved
creating an OUTFLAG=1 before the DO group for the first
OUTPUT, then setting OUTFLAG=0 inside that DO group, and
then adding AND OUTFLAG=1 to the subsequent IF QWHSISEQ
test for the second OUTPUT.
This error was introduced by Change 14.231.
Thanks to Trevor Nightingale, SAS Institute Cary, USA.
Change 15.069 Variable ARSPHOST in dataset NSPYLU for NETSPY 4.4 was
VMACNSPY frequently missing when it should have had value.
Apr 30, 1997 Variable LUNRSPSS was to be INPUT if NSPYENTL GE 112, but
the NETSPY 4.4 record had NSPYENTL=108, so LUNRSPSS was
not INPUT and hence missing, and LUNRSPSS is used to
calculate ARSPHOST. The existing test IF NSPYENTL GE 112
must be change to IF NSPYENTL GE 108 and then between the
INPUT lines for LUNRSPSS and LUATTCHS, insert:
@;
IF NSPYENTL GE 112 THEN INPUT
to always INPUT thru LUNRSPSS. MXG was unaware of the
shorter length segment. This error was noticed moving
from MXG 13.02 to 14.14 with NetSpy 4.4; I do not think
there is a problem with 4.5 and later, as I think its
segments are always NSPYENTL=112 or greater.
Thanks to Mark Zelden, Newark Electronics,USA.
Change 15.068 Revised support for HP's MeasureWare for Sun systems has
ADOCMWSU restructured the code to match the default REPORT macro,
VMACMWSU and was validated with data. Examples of moving data via
Apr 29, 1997 ftp are provided in ADOCMWSU's comments.
Thanks to Steve Corson, Cincinatti Bell Information Service, USA.
Thanks to Gary Alexander, BMC, USA.
Change 15.067 Support for NETSPY Version 5.0 is included in MXG 14.14,
VMACNSPY (there was no real change between NETSPY 4.7 and 5.0, and
Apr 29, 1997 4.7 support was added in MXG 14.03). The DSECT shows
fields added compatibly to the type 'X' (Alert) record,
but this is not a primary subtype, so until I have test
data (and a site that needs the new data in this fairly
obscure subtype) I won't add the new fields.
Change 15.066 Variable AVGXETTM in TYPE72GO was wrong; the divisor must
VMAC7072 be TRANSEXC (transactions completing "execution phase"
Apr 29, 1997 during the interval) instead of TRANS (transactions that
completed during the interval).
Thanks to Don Deese, Computer Management Sciences, USA.
Change 15.065 EXCP and IOTM count in TYPE30/PDB.JOBS/PDB.STEPS datasets
VMACEXC2 for devices with 4-digit UCB addresses of 8000x or higher
Apr 29, 1997 were put in variables EXCPMSS/IOTMMSS (instead of the
EXCP3390 or EXCP3480 device-type buckets), and these IOs
were also not included in EXCPDASD or EXCPTAPE, although
they were counted in EXCPTODD and EXCPTOTL variables.
The old logic for the now defunct Mass Storage System,
MSS has now been commented out, but it tested the first
bit of DEVNR to identify MSS devices, causing this error.
Change 15.064 Variable SLOTUTIL is added to dataset TYPE71 to measure
VMAC71 the percentage of local page dataset slots that are in
Apr 28, 1997 use. Find the maximum value of SLOTUTIL during the month
to make sure you have enough page dataset slots defined.
SLOTUTIL should always be less than 25% (because the
ASM's contiguous slot allocation algorithm can move 30
pages in one SSCH only when there are 30 contiguous free
slots, and at utilizations above 25%, ASM begins to not
find 30 slots, so it tries to find 15, then 8... which
causes lots of extra SSCHs to your page volumes at the
very worst possible time - those few times when paging
becomes a performance problem!). I have preached this
concept, but had not provided the variable (and the value
I used in class turns out to need to be changed):
SLOTUTIL=(SLOTLOMN-SLOTUNMN)/SLOTLOMN;
compares the minimum number of defined local slots with
the minimum number of unused local slots to calculate the
maximum utilization of slots during the interval.
Thanks to Jean Quinkert, Inland Steel Company, USA.
Change 15.063 I have begun to analyze the OMVS data in TYPE30OM.
EXTY30OM The variable OMVSEXNP (OMVS Program Name, "grep", "find",
VMAC30 etc) is now 16 instead of 8 bytes.
Apr 27, 1997
TYPETASK='A ', originally for APPC/ASCH type 30 records
(other TYPETASK values are JOB/TSU/STC, taken from the
JCTJOBID), is now also used for OMVS type 30 records, so
there is no direct way to separate OMVS from APPC/ASCH
in type 30 records. However, Goal Mode records contain
WLMNAME and SRVCLASS names, which may be useful along
with TYPETASK to group type 30 records.
Dataset TYPE30OM contains an observation for every OMVS
segment, and there can be segments in interval subtypes
2 and 3, in step termination subtype 4, and in job term
subtype 5, but there is only one slot per record for the
OMVSEXNP Program Name, so the subtype 5 observations are
useless for analysis. Here's what I observed:
SUBTYPE INIT TERM STEPNAME SUBSTEP OMVSEGNR OMVSEXNP
3 59:02.16 02.29 STEP1 0 1 find
4 59:02.16 02.30 STEP1 0 1 find
3 59:02.30 02.51 *OMVSEX 1 1 grep
4 59:02.30 02.51 *OMVSEX 1 1 grep
5 59:02.16 02.52 0 1
5 59:02.16 02.52 0 2
Subtypes 3 & 4 have OMVS program name in interval and
step records. The single subtype 5 job record has two
OMVS segments, representing the two OMVS invocations (one
per each step, in this instance), but the OMVS segments
in subtype 5 cannot be associated with their program
name. As a result, I no longer output obs in TYPE30OM
from subtype 5 records (although you can change my new
default in member EXTY30OM).
Change 15.062 Analysis of impact of DDCONS(NO) versus DDCONS(YES) with
ANALDDCN regard to the number of duplicate DDs that are written to
Apr 27, 1997 SMF when the (recommended) DDCONS(NO) option is
specified. This analysis proves how little duplicates
there are and refutes arguments that lots of additional
SMF records will be created. See MVS Technical Note in
Newsletter 32.
Change 15.061 Variables PCTDIRPT and PCTCUBSY in TYPE78CF dataset were
VMAC78 incorrect. The calculation of PCTDIRPT was changed:
Apr 26, 1997 Variable R783DPB is now INPUT where PCTDIRPT was, and
May 3, 1997 now the calculation of PCTDIRPT is changed to
IF (CHPIDTKN+R783DPB+PCTCUBSY) GT 0 THEN
PCTDIRPT=100*R783DPB/(CHPIDTKN+R783DPB+PCTCUBSY);
ELSE PCTDIRPT=.;
and the calculation of PCTCUBSY was changed to:
IF SUM(CHPIDTKN,R783DPB,PCTCUBSY) GT 0 THEN
PCTCUBSY=100*PCTCUBSY/SUM(CHPIDTKN,R783DPB,PCTCUBSY);
ELSE PCTCUBSY=.;
The SUM() statement is needed for PCTCUBSY calculation to
protect for missing values (old versions of RMF do not
have all three variables), but is not needed for PCTDIRPT
because that calculation is inside loops which guarantee
the existence of the three variables.
Thanks to Thomas Neurauter, Fidelity Systems, USA.
Change 15.060 For CICSEXCE observations from CICS/ESA, variables
VMAC110 DURATM and STARTIME were always missing, but now both
Apr 26, 1997 variables are created in CICSEXCE for consistency.
Thanks to Trevor Nightingale, SAS Institute Cary, USA.
Change 15.059 If a MIM record segment contained MIMCNT=0, Version 3
VMACMIM segments after the zero were not read, because the line
Apr 26, 1997 IF MIMCNT = 0 THEN DELETE; deleted the record. For the
Version 4 record, that statement had been commented out.
This change puts IF MIMCNT GT 0 THEN DO; ... END;
around both of the OUTPUT statements for both versions,
so only records with samples are output, but so that
a zero segment doesn't stop the scan for other segments.
Thanks to David L. Dittmar, IBM Global Services, USA.
Change 15.058 Variable R745CINT is now kept, formatted TIME12.3 and
FORMATS labeled in dataset TYPE74CA; it is the Cache interval
VMAC74 and is used in all rate calculations (instead of the
Apr 25, 1997 RMF variable DURATM). The IF CSCSS1='...1....'B line
misspelled CSCSDFM0='N', should be CSCSDFM1='N'. The
variables CSDEVPI and DEVPI have been incorrectly decoded
by format MGCACPI, which was replaced by MGCACPD. New
variables CSDPIDAT/CSDPIFAI/DEVPIDAT/DEVPIFAI are now
replacements for CSDEVPI and DEVPI. Format values for
MGCACRC format (for variable RCOL) were enhanced; this
field/format describes record level caching mode.
Thanks to Bruce Widlund, Merrill Consultants, USA.
Change 15.057 New RACF events are now decoded by format MG80EV, with
FORMATS new Open Edition events, process actions, etc. It is
Apr 25, 1997 worth your while to read the list of possible events!
Thanks to Jens Schlatter, Independent Consultant, GERMANY.
Change 15.056 This utility is now a %MACRO which can be invoked with:
UTILCONT %UTILCONT(PDB=WORK);
Apr 25, 1997 to show the size (Megabytes, Observations, etc) of each
SAS dataset in the PDB= Data Library, with one line per
dataset. And it now works under Windows as well as MVS!
It still requires an //INSTREAM or FILENAME INSTREAM to
write to and read from (ok, it's crude, but it works,
especially when I have filled my WORK file and need to
see which datasets are big and which are small).
This is a structural revision of the earlier UTILCONT.
Thanks to Vickie Drake, Levi Strauss & Co.
Change 15.055 Inconsistency analysis of MXG code found several errors:
ASUM70PR -ASUM70PR. In the calculation of TOTSHARE=SUM(LP0SHARE,..
CICINTRV variable LPESHARE was repeated; the first instance of
DIFFTMDB LPESHARE should be LPDSHARE.
VMAC42 -VMACQAPM. Variable OS2CT16 should have been divided by
VMACQAPM 1000 and formatted TIME12.3, just like variable OS2CT14,
VMACTMDB and now it is. Variables ASBRCV ASBTRN LSBRCV LSBTRN
Apr 25, 1997 SDBRCV SDBREX SDBXMT SYBRCV SYBREX SYBXMT are now
formatted with MGBYTES. Variables ending with PWT in
QAPMSNA are formatted TIME12.3 now.
-VMAC42. Variables SMF42JNC and SMF42JND are now length
8 with format DATETIME21.2, and variable SMF42JNE is
format TIME12.3.
-VMACTMDB. Numerous previously unlabelled variables are
now labeled, and several DA9STCTx variables that were not
kept in TMDBDA2 dataset, now are.
-DIFFTMDB. Datasets TMDBDAB, TMDBDA2 and TMDBDAF are now
SORTed and Deaccumulated to create DURATM and ENDTIME
variables for these interval datasets.
-CICINTRV. The first statement A06TEOT=DIFTEOE should be
A06TEOE=DIFTEOE. The VMXGSUM for INDATA=SRTDLIR had
INVOKEBY comment of INTDBU instead of INTDLIR. Variable
A10IDQN appeared twice in KEEP= list for SORT of CICDQR.
Variable A17DSTSW was misspelled as A17DTSW.
Thanks to Chris Weston, SAS Cary, USA.
Change 15.054 TMON/CICS variables SYSTEM and SYSID were truncated to
TYPETMON only one byte as a result of Change 14.342. Statement:
Apr 25, 1997 IF SYSTEM=' ' AND SYSID=' ' AND TMMDREC='TA' ....
inserted by that change must be changed to read:
IF SYSTEM=' ' AND SYSID=' ' AND TMMDREC='TA' ....
(i.e., four blanks instead of one blank for SYSTEM &
SYSID). The inserted statement became the first
assignment of the two variables, so SAS used it to set
their length, in place of the later INPUT statements
that had previously defined the variable's lengths.
Thanks to Henry Schreiber, Amdahl, USA.
Change 15.053 First draft of MXG recommendations for SMF parameters
SMFPRM00 that are specified in member SMFPRM00 of SYS1.PARMLIB.
Apr 24, 1997 Extensive discussion of why options are recommended.
Will be expanded into discussion of
to synchronize or not to synchronize
to DDCONS(YES) or to DDCONS(NO)
system delays during the SMF interval pop.
Thanks to Henry Pomorski, Harris County, USA.
Thanks to Robert Rudd, Harris County, USA.
Thanks to Cheryl Watson, Watson and Walker, USA.
Change 15.052 Support for all AS/400 OS/400 Release 3.7.0 records. MXG
VMACQAPM had earlier supported only the critical records (CONF,
Apr 22, 1997 SYS,JOBS, and DISK), and had coded many new variables
Apr 25, 1997 added to the end of the records, but the incompatible
insertion of IOPRN (IOP RESOURCE NAME) was overlooked
until hit with test records. These datasets were
incompatibly changed between 3.6 and 3.7 by the insertion
of IOPRN: QAPMHDLC,ASYN,BSC,X25,ECL,STNL,ETH,STNE,DDI,
DDI,STND,FRLY,STNY,CIOP,DIOP,LIOP,MIOP,RESP,RWS,LAPD,IDLC
and QAPMIOPD. In addition, IBM incompatibly changed the
field lengths in QAPMPOOL, and fields were removed from
QAPMRESP, QAPMX25, & QAPMRWS. Existing variables named
CIDMAO/CIDMAI/DIDMAO/DIDMAI are now named CIKBY0/CIKBYI/
DIKBY0/DIKBYI, but MXG kept the original names and uses
conversion from KBytes back to bytes so MGBYTES format
will print same magnitudes before and after 3.7.0!
Thanks to Len Marchant, Coca Cola Enterprises, USA.
Thanks to Cheryl Howard, NationsBank, USA.
Change 15.051 Change 14.321 (CF Structures) added trap if number of QO
VMAC74 and SO sections were not equal (trap prints MXG DISCOVERY
Apr 21, 1997 NO STRUCTURE MATCH on log), but trap springs if there was
no QO section at all. While unexpected, I have added
protect for SMF744QN=0 while we talk with IBM to find out
why the record has Request Data sections but had no
corresponding Structure Data Section.
Thanks to Joe Schwartz, Cigna, USA.
Change 15.050 Protection for products that do not support year 2000 has
YEAR2000 been added in MXG Software. Windowing (00-59=20yy, 60-99
Apr 20, 1997 =19yy) has been added during INPUT of JULDATE fields if
the century bit is not enabled (i.e., where the record
vendor does not support the year 2000, MXG can still do
the right thing and create the correct year 2000 date.
A more extensive note and update to member YEAR2000 will
be written and this text will be revised.
As of May 5, JULDATEs have been windowed, but there are
other forms to be protected, and member YEAR2000 has not
yet been updated to identify the new category of products
that are now "MXG-protected".
Change 15.049 TIC_UTIL is now added to NPMLANOD and NPMINTRI datasets.
VMAC28 (It was calculated but not kept in NPMINTRI, and the
Apr 17, 1997 units of time-per-byte were corrected to nanoseconds in
NPMLANOD).
Thanks to Ian Hindshaw, Standard Bank of South Africa, SOUTH AFRICA.
Change 15.048 Variables SMF6FDNM (Form Def) and SMF6PDNM (Print Def)
IMACPDB are added to dataset PDB.PRINT, as they are often used to
Apr 17, 1997 determine print characteristics in analysis. They were
always captured in TYPE6 dataset, but were not in the
list of variables (in IMACPDB) to be kept into PDB.PRINT.
Thanks to Jerry Maier, First Chicago NBD, USA.
Change 15.047 ML-13 of ASMTAPES contains enhancements to provide error
ASMTAPES recovery for the mount monitor's AR code. ML-13 will not
Apr 17, 1997 correct these problems, but it will recover from them so
the monitor stays up. In addition, when the monitor is
run in "DEBUG" mode, an ABEND in ML-13 will generate an
SVC dump of both address spaces (monitor and monitored)
which will hopefully provide enough diagnostics data that
the next iteration will eliminate these errors. In
addition, there are two other fixes: ML-13 prevents S0C4
ABENDS when the TCBTIO is zero, and ML-13 corrects the
ALESERV return code in the TMNT008I message.
Thanks to Ruth Whitney, CITICORP, USA.
Thanks to Tom Parker, Hogan Systems, USA.
Thanks to Will Evans, Consolidated Freight, USA.
Change 15.046 Change 14.345 added code, but the 4DIGITUCB comment was
FMXGUCBL coded into column 72, causing an ASSEMBLY errors such as
Apr 13, 1997 BEGIN-TO-CONTINUE COLUMNS NOT BLANK. Move left one col.
Thanks to Dr. Alexander Raeder, Karstadt AG, GERMANY.
Thanks to Hartmut Beckmann, Karstadt AG, Germany
Change 15.045 Datetime variables that had DATETIME18. formats are now
many DATETIME20., so as to display all four digits of years.
YEAR2000 I also observed that truncated DATETIME formats will not
Apr 13, 1997 display four-digit year for the date, hour, minute or
second truncations - I hoped DATETIME9 could be enhanced
to show the yyyy, but as it now prints seven positions,
and increase could cause existing applications to fail
(the wider field would shift right or overlay), so SAS
Institute cannot make the change.
value printed DATETIMExx. truncation
01FEB84 7-8-9 date,daily
01FEB84:22 10-11-12 hourly
01FEB84:22:33 13-14-15 minutely
01FEB84:22:33:59 16-17-18 secondly
01FEB1984:22:33:59 19-20-21-22 secondly,yyyy
Thanks to Bruce Widlund, Merrill Consultants, USA.
Change 15.044 Format $MGCICLO did not decode values 08x,09x,0Ax values
FORMATS but now it does into 08X:SDSA, 09X:ESDSA, and 0AXRDSA.
Apr 13, 1997
Thanks to Helmut Roese, COM Gmbh, GERMANY.
Change 15.043 Change 15.037 changed TYPE116 variable QWHCTNO from
VMAC116 &PIB.4. to &NUM.4., but data values that are not EBCDIC
Apr 13, 1997 numbers (eg., 004DF3D4x), so the input is changed back
back to &PIB.4., is now formatted as HEX8., and is now
kept as LENGTH 5 (to display all four bytes numeric, an
extra byte must be kept). I could have changed to a
character variable of length 4 with $HEX8 format, but
then prior TYPE116 datasets would be incompatible with
newly build TYPE116, so I kept the variable as numeric.
I am also asking IBM if these values are expected for
the CICS Thread Number - their answer was that it really
is a token and is not necessarily a number.
Thanks to Helmut Roese, COM Gmbh, GERMANY.
Change 15.042 Tandem Disk Drive subtype 30 is now 30:4GB/4260.
FORMATS (It was decoded as 30:3GB before format MGTANDS was
Apr 13, 1997 corrected by this change). Tandem Disk Drives type
Apr 25, 1997 4245,4255,4265,4560, and 4570 are now decoded.
Thanks to Hannu Koski, SJ Data, SWEDEN.
Change 15.041 Cosmetic. The JCL example for the //CONTENTS DD did not
UTILCONT have BLKSIZE=, but now it does.
Apr 1, 1997
Thanks to Vickie Drake, Levi Strauss & Co., USA.
Change 15.040 IBM can write type 72 subtype 2 (TYPE72MN - RMF III MON)
VMAC7072 records with zero for DURATM, which caused DIVISION BY
Apr 1, 1997 ZERO error, so protection was added to protect PGINRATE:
IF DURATM GT 0 THEN PGINRATE=MONPGIN/DURATM;
These zero duration records occurred under MVS/ESA 5.2.2
and have strange values for SWAPDLUS and SWAPDLIC but
other variables have reasonable values, and the STARTIME
was 15:20:00.00, SYNCTIME 14:27:54.81, and the SMFTIME
was 15:27:59.91, so why DURATM is zero is unknown.
Thanks to Martin Peck, CA-IT/BM, AUSTRIA.
Change 15.039 IBM's "MVS PSF DOWNLOAD" product created invalid SMF type
VMAC6 6 records (SMF6LN3/SMF6LN6 are located two bytes beyond
Apr 1, 1997 where they should be). APAR OW23937 reports the error,
and PTF UW34926 corrects the error, but bad records can
be read by MXG by conditionally INPUTing the two LENx
fields as PIB4 instead of PIB2 by inserting:
IF LENGTH=274 THEN INPUT @OFTONXT SMF6LN3 &PIB.4. @;
ELSE
before the existing:
INPUT @OFTONXT SMF6LN3 ..... statement
and by inserting
IF LENGTH=274 THEN INPUT @OFTONXT SMF6LN6 &PIB.4. @;
ELSE
before the existing:
INPUT @OFTONXT SMF6LN6 ..... statement
NOTE: This Change was NOT made to MXG Software, but is
only printed here for temporary circumvention to read
records created prior to the installation of the PTF.
Thanks to Hal Merritt, Texas Commerce Bank, USA.
Change 15.038 -Dataset TYPE72GO variable R732CIRC is now R723CIRC to be
VMAC7072 consistent with other subtype 3 type 72 variables.
Apr 1, 1997 -The calculation of NRPTRANS was incorrect, which also
caused the calculation of PERFINDX for Percentile Goals
to be incorrect.
The equation that was: NRPTRANS=TRANS*TRANEXEC/100;
is now: NRPTRANS=TRANS*R723CPCT/100;
-IBM's RMF report calculation of PERFINDX for Percentile
Goal Service Classes can be wrong, producing a value that
is greater than true, especially when the number of TRANS
is small. IBM sums transactions until the sum is GT the
percentage goal, but the definition in the SRM (and now
in MXG) should stop when the sum is GE. For example,
with 10 transactions and a 70% goal value
bucket: 1 2 3 4 5 6 7 8 9 10 11 12 13
RTSMAP: .5 .6 .7 .8 .9 1.0 1.1 1.2 1.3 1.4 1.5 2 4
RTSTRN: 3 0 1 2 1 0 1 0 0 0 0 1 1
RMF counts to the 7th bucket, setting PERFINDX=1.1, but
MXG and the SRM stop at the 5th bucket, PERFINDX=.9,
because 7 out of 10 transactions did meet the goal!
The equation IF SUMPTRAN GT NRPTRANS THEN DO;
was changed to IF SUMPTRAN GE NRPTRANS THEN DO;.
-26Jun97: The following error was originally documented
here in April, 1997, but now has been corrected by APAR
OW26609. See MVS Technical Note 22 in Newsletter 32:
Variable R723CIRC appears very right in lots of cases,
but is very wrong in some Service Class data (notable,
TSO, which has multiple periods) when compared to
TYPE30 interval data. This is still under investigation
but it is most likely an IBM error in RMF
deaccululation in multiple period service classes for
this new variable. The numbers on the RMF report look
fine, because RMF only prints the avg time per I/O
(R723CICT/R723CIRC); it looks like both fields are each
wrong! For 5 periods of TSO in a 30 minute interval:
R723CIRC R723CICT R723CIWT R732CIDT ACTIVETM TRANS
23179776 15:45:17.81 2:18:18.80 6:23:29.81 0:01:28 1309
177746 0:07:53.98 0:01:07.03 0:03:24.63 0:01:22 358
342664 0:13:54.80 0:02:06.71 0:05:55.51 0:04:44 378
10639 0:00:29.34 0:00:04.83 0:00:02.56 0:00:49 10
5180 0:00:13.68 0:00:01.76 0:00:00.94 0:02:19 6
That is 16 hours of connect time in 30 minutes (or 32
I/O concurrently transferring data during the entire
interval) or is 13,000 SSCH per second? I think not!
Clearly, APAR OW26609 must be installed to correct!
Thanks to Don Deese, Computer Management Sciences, USA.
Thanks to Dale Mattison, Shared Medical Systems Corporation.
Change 15.037 The INPUT of TYPE116 variable QWHCTNO must be changed
VMAC116 from &PIB.4. to &NUM.4. (since the value is an EBCDIC
Mar 29, 1997 number) and the INPUT of variable QWHCTASK must be
changed from &PIB.4. to &PD.4. But see Change 15.043.
Thanks to Helmut Roese, COM GmbH, GERMANY.
Change 15.036 Duplicate.
Change 15.035 The INPUT of TYPE80A variable ACEEUSER was increased from
VMAC80A $VARYING20. to $VARYING30., as data of length 25 was
Mar 29, 1997 found at one site, and an MXG note prints on the SAS log
if a longer length string is found in your data. lmut
Thanks to HeRoese, COM Gmbh, GERMANY.
Change 15.034 CICS Statistics variable A08BKHSW must be INPUT &PIB.2.
VMAC110 and +2 instead of &PIB.4., as it is only a half-word that
Mar 29, 1997 is followed by two reserved bytes.
Thanks to Helmut Roese, COM Gmbh, GERMANY.
Change 15.033 Change 12.264 for IMF variables ABENDSYS and ABENDUSR was
VMACCIMS only correct for old IMF 1.2, and only for ABENDSYS. The
Mar 29, 1997 revised algorithm to decode the two intermingled fields
(stored as xxSSSUUU in four bytes) now reads:
@117+OFFIMS +1 /*SKIP OVER XX OF XXSSSUUU: */
@118+OFFIMS ABENDSYS &PIB.2. /*OVERLAY 117 118 119 120 */
@119+OFFIMS ABENDUSR &PIB.2. /* XX SS SU UU */
/* +1 ABENDSYS */
. /* +1 +1 ABENDUSR*/
The first byte is skipped, the second two bytes are input
into ABENDSYS as PIB2., the third and fourth bytes are
INPUT in ABENDUSR as PIB2. Then, after the INPUT ends,
in both the old 1.2 and later 1.3 groups, this code:
ABENDUSR=MOD(ABENDSYS,16)+ABENDUSR;
ABENDSYS=FLOOR(ABENDSYS/16);
creates ABENDSYS=0013x and ABENDUSR=0000x from 00013000x
(ABENDUSR must be done first, because it uses ABENDSYS
which then stores into itself).
Thanks to M. Nicolas, BNP, FRANCE.
Change 15.032 Variable SERVUNIT was only length 4 in PDB.STEPS and in
BUILD005 PDB.SPUNJOBS, but it should have been length 5 (since
BUIL3005 Change 14.214). The LENGTH statement following PDB.STEPS
BUILDPDB now has SERVUNIT 5 added in the BUILxxxx members,
BUILDPD3 as does the LENGTH statement following PDB.SPUNJOBS in
SPUNJOBS member SPUNJOBS.
Mar 27, 1997
Thanks to Trevor Ede, Bank of New Zealand, NEW ZEALAND.
Change 15.031 Warning message that datasets WORK.INTxxx don't exist is
BUILD004 because the datasets were deleted in both CICINTRV and
BUILDPDB the BUILD004/BUILDPDB/BUILDPD3 members. Since these are
BUILDPD3 CICS only datasets, the DELETE belongs in CICINTRV and
Mar 27, 1997 they are removed from the DELETE in the three BUILDxxx
members.
Thanks to Martin Peck, CA-IT/BM, AUSTRIA.
Change 15.030 When SOFTAUDIT is enabled to collect data only at the JOB
VMACSFTA level, the record is only 115 bytes long, so the test
Mar 27, 1997 IF LENM=131 THEN DO; must be changed to:
IF LENM=115 OR LENM=131 THEN DO;
Thanks to Rick Green, Comerica, Inc., USA.
Change 15.029 -Error in MXGCHAN macro caused RMF Channel Reports to fail
ANALRMFR with a syntax error. The statements &PDB..TYPE73 ; and
Mar 27, 1997 &&PDB&I...TYPE73 ; must have those semicolons removed.
-All of the "PROC PRINT"s and their TITLE statements
should have been deleted (they were debugging prints) to
save paper (or at least SPOOL space!).
Thanks to Mike Creech, Alltel Information Services, USA.
Change 15.028 Variable RVDSNAM1 (FIRST FILE*DATASET*NAME) is now INPUT
VMACEDGR (immediately after RVMEDATR) and kept in RMM dataset
Mar 27, 1997 TYPEEDGR; I'm not sure when this field was added by IBM.
Thanks to Ben Cowan, UCCSN System Computing Services, USA.
Change 15.027 NTSMF discovered new objects created by COMPAQ so four
EXNTCMBU new datasets are now created from these objects:
EXNTCMCN CMPQBUSU Compaq EISA/PCI Bus Utilization
EXNTCMDV CMPQCTLR Compaq 32-Bit SCSI-2 Controllers
EXNTCMNF CMPQDEVS Compaq 32-Bit SCSI-2 Devices
IMACNTSM CMPQCMNF Compaq NetFlex-3 Network Driver
VMACNTSM I note that the Controllers record appears to have a per-
Mar 26, 1997 controller record with CTRLNAME containing the name of
Apr 28, 1997 the controller (eg. \\.\Scsi0) and a second interval
record with CTRLNAME blank (which I assume is an interval
total, but have not had two controllers' data for
verification). Revised Apr 28: NTSMF Version 2.0 adds
two new fields NTVERSN (NT VERSION, 4.0) and NTVERSP (NT
SERVICE PACK, SPK1) to the header of each NTSMF record.
The variables are kept in the PROCESOR dataset and in
dataset NTINTRV (although they will be blank until you
install NTSMF Version 2.
Thanks to Richard Clary, Entergy, USA.
Change 15.026 The new VELOCITY calculation for OS/390 Release 3
VMAC7072 includes I/O delay time if it was enabled (see Change
Mar 25, 1997 14.318), but some sites may need to know the old or new
May 29, 1997 velocities before they are enabled, so two new variables
were introduced:
VELOCCPU 'CPU ONLY*EXECUTION*VELOCITY'
VELOCIOD 'I/O DELAY*EXECUTION*VELOCITY'
and are kept in both TYPE72 and TYPE72GO datasets. The
variable VELOCITY will continue to contain the actual
velocity, and variable R723VELI='Y' will flag whether or
not the value of VELOCITY contains I/O DELAY time.
Text of this change was incorrect until May 29, 1997, but
the above change was made to the code in March.
Thanks to Cheryl Watson, Watson and Walker, USA.
Change 15.025 A typo had real impact - variable BATCHMAX was renamed to
TRNDRMFI MATCHMAX. The correct spelling is BATCHMAX.
Mar 25, 1997
Thanks to Dave Schultz, First Card, USA.
Change 15.024 A typo had minor impact - a FORMAT statement was absorbed
TYPEIMSB as a comment because a comment was not terminated. The
Mar 25, 1997 INFILE IMSSUMS0 END=END; /* comment .... text *
should have ended with */
Thanks to Kristyann Manske, University of Wisconsin-Milwaukee, USA.
Change 15.023 TYPE70 variable PCTMVSBY was wrong (although it did match
VMAC7072 IBM RMF report values) for Amdahl MDF domains with some
Mar 25, 1997 shared and some dedicated CPUs. The MXG equation was
(CPUUPTM-MVSWAITM)/CPUUPTM=58:56-16:00/58:56=43/59=72.8%,
but that assumed the total dispatch time of all CPUs was
CPUUPTM=NRCPUS*DURATM or 59 minutes, when in fact the
true dispatch time was only 46 minutes, and the true CPU
busy time was 30 minutes, and not 43 minutes as shown
below:
The MDF partition had DURATM=14:44.05 with CPUs 0 and 3
given 100% target allocation but CPUs 1 and 2 were shared
with only 55% target allocation for this partition:
LCPUn CPUPDTMn CPUWAITn MVSWAITn MVSBUSYn
0 14:43.99 5:42.42 5:42.37 9:01.62
1 8:35.56 8:22.62 2:14.13 6:21.43
2 8:35.18 8:19.20 2:10.34 6:24.84
3 14:43.92 5:53.71 5:53.59 8:50.33
CPUPDTTM CPUWAITM MVSWAITM CPUACTTM
total 46:38.65 28:17.97 16:00:43 30:38.22
CPUACTTM has 30:38 minutes of actual CPU seconds for the
partition, and CPUPDTTM has 46:30 minutes of dispatch,
so the true PCTMVSBY (percent of dispatch time when this
MVS was busy) is 30/46 or 65.7% (versus IBM's 72.8%) so
the revised MXG equation is now:
PCTMVSBY=100*CPUACTTM/CPUPDTTM;
(IBM footnotes that their value is the arithmetic mean,
which if correct if each LCPU is dispatched equally as
is the case with their PR/SM, so they implied you should
be wary, but apparently IBM won't modify its RMF reports
for MDF idiosyncracies - but MXG does!).
The variable CPUUPDTM (total partition dispatch time) is
also now calculated and kept in TYPE70 dataset.
This site also enabled the old Amdahl MDF option "Wait
Complete=No Reporting" (see Change 12.289), but that
option appears to be useless when engines are shared
between domains; while the real CPU usage is known, that
option loses the domain dispatch time, so you can never
know what was the capacity available to each
domain/partition.
Thanks to Kirk Poore, Union Electric, USA.
Change 15.022 Old HP-PCS and new HP-MW code still had date litterals of
VMACHPxx JAN70 (the epoch of the Unix Clock) that are now changed
VMACMWxx to JAN1970. (With YEARCUTOFF default, SAS would have set
Mar 19, 1997 the correct date, but it is MXG's intention to support
the year 2000 intrinsicly, rather than thru YEARCUTOFF).
Thanks to Graeme Yeandle, British Telecom, ENGLAND.
Change 15.021 -Variables EDGSADTE and EDGSARSD are added to DATE9 format
FORMATS and the ELSE was removed from ELSE IF after the INPUT of
VMACEDGS EDGSAFLG in the ID=_IDEDGUS logic block (because records
Mar 19, 1997 from SMF were not INPUT due to the extraneous ELSE).
Mar 29, 1997 -Variable EDGSASID must be input as $EBCDIC4. instead of
$EBCDIC8. in the EDGSSECU dataset - not only was EDGSASID
wrong, but all following fields were too, but fortunately
the EDGSSECU data set is just now being investigated!
-Value 18:SAF CALL was added to the MGACFDA format in
member FORMATS for ACF2.
Thanks to Pete Young, University of Toronto, CANADA.
Change 15.020 JES3 BUILDPD3 created additional PDB.JOBS/PDB.STEPS obs
BUILDPD3 that contained only TAPEMNTS TAPFETCH SMFTIME, because
BUIL3005 multiple TYPE25 observations were inadvertently created.
Mar 19, 1997 In the logic following DATA ONE25;, find the statement
TAPEMNTS=MOUNT; and insert the statement OUTPUT;
immediately following (and before the END;).
Thanks to Neil Musitano, Jr., Veterans Administration, USA.
Change 15.019 Variable ULOGADAE was changed to be INPUT as &PIB.4.3
VMACCOMP in only one statement, but there were two overlooked
Mar 19, 1997 statements for ULOGADAE that are now also changed.
Thanks to Jens Schlatter, Independent Consultant, GERMANY.
Change 15.018 -The Label for dataset TYPE8011 should be ALTDSD and not
VMAC80A ADDUSER.
Mar 19, 1997 -Variable USERID was inadvertently removed from TYPE8014
dataset in MXG 14.14, so USERID was added to KEEP= list
for dataset TYPE8014, and the 1st occurrence of USEROWNR
after ELSE IF RACFEVNT=14 THEN DO; after WHEN (6) was
changed back to USERID, so both USERID and USEROWNR will
be kept in TYPE8014 dataset.
Thanks to Jens Schlatter, Independent Consultant, GERMANY.
Change 15.017 Support for CA-ROSCOE Version 6 SMF Record has been
VMACROSC verified (i.e., the V6 records do not cause MXG to fail
Mar 18, 1997 although I have not yet verified with the DSECT).
Thanks to Bob Bunt, NYSEG, USA.
Change 15.016 Support for CA-DISPATCH Version 6 and five-digit JESNR.
IMACCADI CA relocated the five-digit JESNR to a new area at the
VMAC6 end of the record, and new fields CADIARCH and CADIBUND
Mar 14, 1997 are now created (only if you enable CADI support in the
IMACCADI tailoring member).
Thanks to Kenton O'Brien, Barclays, ENGLAND.
Change 15.015 Support for Anacom's Anastack product (spools data to
VMAC6 microfiche, etc.) which writes a type 6 SMF record. The
Mar 14, 1997 record is an "External Writer" record (DEVICE='EXT WTR')
so many of the JES-only and PSF-only fields will be
missing, but the event, JOB, and number of lines are
captured. No code was changed in MXG, since external
writer records are already supported.
Thanks to Dave Crandall, Farmers Group, USA.
Change 15.014 Change 14.245 (added variables to some BY statements to
WEEKBLD better protect for duplicate SMF records in BUILDPDB) was
WEEKBLDT not fully implemented in WEEKBLD and WEEKBLDT, so the BY
Mar 12, 1997 lists are not exactly the same, but there should be no
execution error. Now, the BY lists are consistent.
Thanks to Tom Parker, Hogan Systems, USA.
Change 15.013 Variable SSTORE72 (Shared Pages Bytes) is now created in
VMAC7072 dataset TYPE72GO, for consistency with variables
Mar 12, 1997 CSTORE72 ESTORE72 TSTORE72 that were added earlier.
Thanks to Bruce Widlund, Merrill Consultants, USA.
Change 15.012 -NTSMF records from NT 3.51 for SQLSERVER, SQLSERVER-LOCKS
IMACNTSM and SQLSERVER-LOG have fewer fields than NT 4.0; now that
VMACNTSM I have raw records, MXG was enhanced to support these NT
Mar 12, 1997 3.51 records.
Thanks to Richard Clary, Entergy, USA.
Change 15.011 Variable SMF744PN was added to dataset TYPE74CF to count
VMAC74 the number of processors in this Coupling Facility. You
Mar 11, 1997 you could have derived the number from CFNUM01-CFNUM16,
by counting, but you should not have to!.
Thanks to Rick Poliak, Amdahl, USA.
Change 15.010 Support for Landmark's "Performance Works/Smart Agents
ADOCPW for UNIX" dumped output (see ADOCPW for syntax of their
EXPWACCT dump command) creates twenty new PWPxyyyy datasets:
EXPWCPUP From Product Detail records:
EXPWDEVD Dataset Name Description
EXPWDEVS PWPDACCT PROCESS ACCOUNTING
EXPWFSL PWPDFSL LOCAL FILE SYSTEM CAPACITY
EXPWFSR PWPDFSR REMOTE FILE SYSTEM RECORD
EXPWMESS PWPDPD PROCESS DETAIL
EXPWNCO PWPDPDI PROCESS DETAIL INTERVAL
EXPWNIND PWPDPDS PROCESS SUMMARY
EXPWNINS PWPDPGM PROGRAM RECORD
EXPWNSO PWPDTERM TERMINAL SUMMARY RECORD
EXPWPD PWPDUFSQ QUOTAS RECORD
EXPWPDI PWPDUFSS USER FILE SYSTEM STORAGE
EXPWPDS PWPDUSER USER SUMMARY RECORD
EXPWPGM From Product Interval records:
EXPWPI Dataset Name Description
EXPWTERM PWPICPUP PROCESSOR RECORD
EXPWUFSQ PWPIDEVD DEVICE USAGE INTERVAL
EXPWUFSS PWPIDEVS DEVICE USAGE SUMMARY
EXPWUSER PWPINCO NFS CLIENT OVERVIEW
IMACPW PWPININD NETWORK INTERFACE INTERVAL
JCLPW PWPININS NETWORK INTERFACE SUMMARY
TYPEPW PWPINSO NFS SERVER OVERVIEW
VMACPW PWPIPI SYSTEM SUMMARY RECORD
Mar 11, 1997 From Product Log records:
Dataset Name Description
PWPLMESS CONSOLE MESSAGES TEXT
Landmark's initial response to documentation was to use
the "ODBC" interface to their database, but this could
only work if you intended to run SAS on the UNIX system
you are measuring, so MXG's more general solution is to
use their ASCII dump of the data store, so you can ship
the raw ASCII data (convert to EBCDIC during transfer) to
OS/390 for processing there like your other "SMF" data.
(The MXG code will also work fine on UNIX or WINDOWS to
directly process the dumped ASCII.)
Unfortunately, their dump has no selectivity of fields,
so you must dump all fields of each record (the CPUP has
32 fields in the Data Model, but 105 fields in their data
store!). And you cannot select the interval; you get all
all six drawers: minute,hour,day,week,month,and year.
And of course, being typically-UNIX, the drawer values
are m,H,d,w,M,Y, with upper and lower case "m" in use for
two different drawers - a nice exposure to coding errors
that mandates VMACPW must be in mixed-case!!!!! In spite
of these deficiencies, the process does work so that you
can monitor your UNIX resources with Landmark's PW
replacement for The Monitor for Unix, formerly TYPETUX.
Thanks to Dan Sedorik, SmithKlein Beecham, USA.
Change 15.009 Support for APAR OW25152 that adds PRINTWAY Print Queue
VMAC6 Name SMF6PRTQ to TYPE6 dataset, compatibly made. I have
Mar 7, 1997 assumed a maximum name length of 16 to save storage. The
Jul 14, 1999 PRINTWAY internal subsystem value of SMF6SBS='0009'x is
used by MXG to set SUBSYS='TCP' for PRINTWAY records.
See Change 17.171 for PRINTWAY impact on TYPETASK.
Change 15.008 -Wrong values for CSCONF,CSAVAIL,CSOFFL,CNCONF,CNPINNED
VMACACHE and CSSTAT with Hitachi 7700, probably due to bad IBM
VMAC74 SMF documentation rather than Hitachi. In the SMF manual
Mar 7, 1997 CSSTAT='....1111'B is the 3990-6 Enhanced Mode flag, and
that is the value in IBM 3990 records, but IBM's Storage
Control manual GA32-0274 documents CSSTAT='.......1'B as
the expected value, and that is the value in Hitachi 7700
records (which are in fact in Enhanced Mode format)! To
support both IBM and Hitachi, MXG's test is changed to:
IF CSSTAT='.......1'B THEN DO;
(The storage sizes are in units of 1024 bytes in the
3990-Enh format records, or are in bytes if not.)
-In VMAC74, the label for CSSTAT is 3990-6 (vice 3880-6!).
-A second HDS 7700 problem: with 3GB of cache, 4080GB of
cache is reported! (Raw data value is 'FF040000'X). PTF
UW36274 may address, but Hitachi is investigating and
this note will be updated when more is known.
Thanks to Miller Dickson, DST Systems Inc., USA.
Change 15.007 Analysis of APAF Shared processors used NUMLP (the number
ANALAPAF of total engines) to calculate PHY_BUSY, but using number
Mar 7, 1997 of engines available to this domain, LINUMLPS, makes more
sense.
Thanks to Gary Strohminger, AT&T Transtech, USA.
Change 15.006 ERROR: WORK.CICINTRV.DATA DOES NOT EXIST if you changed
CICINTRV IMACCICS to write CICS Statistics to the //WORK DD.
Mar 7, 1997 Move the PROC DATASETS; DELETE CICINTRV; to the bottom
of member CICINTRV to correct my error.
Thanks to Fred Kaelber, Pacific Bell, USA.
Change 15.005 Cosmetic. Label for variable SMF42EAC should have been
VMAC42 ACTIVATE*ENF OR*VARY SMS (instead of VARY SMF).
Mar 7, 1997
Thanks to Solomon Baker, Prudential, USA.
Change 15.004 OS/390 V 1 Rel 3 type 72 record INPUT STATEMENT EXCEEDED
VMAC7072 RECORD LENGTH error. The statement SKIP=SKIP-24; that
Mar 1, 1997 is after the statement R723CIDT=128*R723CIDT; must be
changes to SKIP=SKIP-68;
Thanks to Perry Gibson, Candle Corporation, USA.
Change 15.003 All OMVS File Activity datetimestamps were in GMT, but
VMAC92 are now converted from GMT to local (using the same
Feb 27, 1997 algorithm introduced in Change 14.311). In TYPE9210, the
close time, SMF92CTC, is often .01 seconds later than the
SMFTIME value, which in theory should not happen, but is
valid because SMFTIME informat is truncated to .01 sec
resolution while TODSTAMP (SMF92CTC) informat has micro
second resolution that is rounded to .01 seconds by the
DATETIME21.2 format. A true time of .026 seconds will
be .02 input as SMFTIME and .026 if input as TODSTAMP,
but will print as .02 and .03 respectively with the
DATETIME21.2 format (increasing that format to 22.3
would show the .026 value).
Thanks to Perry Gibson, Candle Corporation, USA.
Change 15.002 Variable TERMIND was added to the _PDB30_4 macro so it is
IMACPDB now kept in PDB.STEPS, as enhancement for ABEND decoding,
Feb 27, 1997 in case of multiple bits.
Thanks to Dan Adams, Facilities Systems Office (FACSO), USN, USA.
Change 15.001 File counts were not properly decoded in TYPETMON, and
TYPETMON one MXG 14.14 change made it worse! The statement
Feb 22, 1997 FILECOL=TAFATOFF+6+LOC-LENMONI; must be changed to
FILECOL=TAFATOFF+1;
In addition, MXG 14.14 added a block of code
LOC=COL; INPUT SYSID .... SYSTEM $EBCDIC4 @LOC @;
but both "LOC"s must be changed to "TLOC".
Thanks to Bob Hall, USA Group, USA.
LASTCHANGE: Version 15