COPYRIGHT (C) 1984-2023 MERRILL CONSULTANTS DALLAS TEXAS USA
MXG CHANGES 19.19
=========================member=CHANGE19================================
/* COPYRIGHT (C) 1984-2002 MERRILL CONSULTANTS DALLAS TEXAS USA */
This is MXG Version 19.19, dated Feb 14, 2002, thru Change 19.300.
MXG Version 19.11 was dated Feb 4, 2002, thru Change 19.288.
MXG Version 19.10 was dated Jan 28, 2002, thru Change 19.282.
MXG Version 19.09 was dated Jan 21, 2002, thru Change 19.267.
MXG Version 19.08 was dated Dec 20, 2001, thru Change 19.247.
MXG Version 19.07 was dated Nov 3, 2001, thru Change 19.218.
First MXG Version 19.06 was dated Oct 31, 2001, thru Change 19.214.
MXG Version 19.05 was dated Oct 24, 2001, thru Change 19.207.
MXG Version 19.04 was dated Oct 5, 2001, thru Change 19.189.
First MXG Version 19.04 was dated Oct 1, 2001, thru Change 19.183.
MXG Version 19.03 was dated Jul 30, 2001, thru Change 19.151.
First MXG Version 19.03 was dated Jul 26, 2001, thru Change 19.148.
MXG Version 19.02 was dated Jun 1, 2001, thru Change 19.098.
First MXG Version 19.02 was dated May 27, 2001, thru Change 19.097.
MXG Version 19.01 was dated Apr 4, 2001, thru Change 19.060.
First MXG Version 19.01 was dated Apr 3, 2001, thru Change 19.057.
MXG Version 18.18 was dated Feb 12, 2001, thru Change 18.360.
MXG Newsletter THIRTY-EIGHT is dated Feb 12, 2001.
Contents of member CHANGES:
Member NEWSLTRS (and the Newsletters frame at http://www.mxg.com) now
contain the current MXG Technical Notes that used to be put in member
CHANGES between Newsletters. New Technical Notes are now added (and
now dated!) in NEWSLTRS/Newsletters with each new MXG Version.
I. MXG Software Version 19.19 is the 2002 Annual Version.
II. Incompatibilities and Installation of MXG 19.19.
III. Online Documentation of MXG Software.
IV. Changes Log
=======================================================================
I. MXG Software Version 19.19 dated Feb 14, 2001, is available.
Major enhancements added in MXG 19.19:
Support CICS/TS 2.2 CICSTRAN (INCOMPATIBLE).
Support for TYPE94 APAR OW52989, adds 8-way AX0 controlers.
Support for OS/400 Release 5.1.0 Collection Services, in TYPEQACS.
New UTILEXCL program for CICS EXCLUDEd fields automatically creates
an IMACEXCL member to read your records, without any EDITing, but
this major enhancement should be used by ALL sites that read SMF
110 records, even if you do not EXCLUDE fields. UTILEXCL creates
an IMACEXCL member with these performance enhancements:
- a single INPUT statement (more efficient than conditionals)
- eliminates unnecessary arithmetic (avoids missing values)
- KEEPs only the variables that exist in your records; all the
EXCLUDED fields are dropped, and all of the extra variables
that are in the CICSTRAN KEEP= list for new/old versions that
do not (yet) exist in your data are also not kept.
See text of Change 19.293 and examples in member UTILEXCL.
User contributed code to read the output of the unix sar command.
ASMVTOC enhanced to select/exclude VOLSER and UCBs above the line.
Versions 19.12 thru 19.18 were never created.
Major enhancements added in MXG 19.11:
INCOMPATIBILITY: MXG CHANGED LANDMARK SUPPORT FOR IMS, DB2, MVS:
Datetime values are now automatically converted from GMT fo LOCAL
Landmark CICS values are NOT changed, but now could be.
See Change 19.288.
TIMEBILD/TIMETABL/VMXGTIME supports LOCAL and GMT Time Zone deltas
and has identified all MXG datetime variables that contain GMT
(few) in the text of Change 19.286. If you have SYSTEMs on
different time zones that needs to be shifted to a common zone,
of if you have GMT values to change to Local, this massive change
will let you do all of the above. And if you do nothing, it does
nothing; the VMXGTIME() statements do nothing until TIMEBILD has
been invoked for a specific job to change datetimes.
UGMTCHEK Utility will check for datetime variables still on GMT
Major enhancements added in MXG 19.10:
MXG sets OPTIONS COMPRESS=YES as the default. Change 19.279.
MXGLEN=5 (EBCDIC) or MXGLEN=6 (ASCII) LENGTH CHANGE in MXG 19.10.
MXG changes LENGTH DEFAULT=4 to =5 on EBCDIC, to =6 on ASCII, to
eliminate any truncation of PIB4-input numeric variables, and the
stored length of MGBYTES-Format'd PIB4 variables was reduced from
8 to 5/6 to eliminate wasted space. &MXGLEN/&MXGBYLN macro vars
can be %LET if you need to restore original defaults; only known
exposure is if you use PROC APEND, but did not specify FORCE.
No size increase with compress; benchmarks/text in Change 19.272.
Initiator Number and Name variables added to PDB.JOBS and TYPE30_1
but missing until you install the IEFU84 SMF Exit Assembly code
that moves those fields into type 30 subtype 1. Change 22.136.
Major enhancements added in MXG 19.09:
Support for SMF 119 from IBM z/OS V1R2.0 Communications Server.
Support for IBM AIX Performance Toolbox, PTX V2.
You can change the time zone of all SMF datetime variables, by
SYSTEM and TimeRange, to put all of your systems on their own
time zones (EST/PST/GMT) to the common time zone of the floor
of the data center, so you can compare RMF, response, etc.,
when your SYSTEMS are on different time zones. This is in the
VMXGTIME, TIMEBILD, and TIMETABL members.
ML-20 ASMTAPES, wrong DDNAME in MXGTMNT SMF if tape on 4-digit.
Select step records, then corresponding 14 15 & 64s - see ANAL30.
Select SORTs with concat SYSIN, then matching 14 15 - see ANAL16.
Support for WebLogs: IIS, WebSphere, CLF, Cookies+.
Major enhancements added in MXG 19.08:
MXG 19.04-19.07: TYPE73 PCHANBY/PNCHANBY zero, ONLINE wrong.
Support for Crypto (for SSL) RMF 70 Subtype 2 APAR OW49808.
Support for IBM CICS/TS 2.2 Statistics Record TCBs
Support for IDMS Log Statistics Records.
Support for Landmark's TMON for TCP/IP v1.1.
Support for RSD Folders ASTRE Auditing User SMF record.
MXG Software (all versions) supports euro symbol.
New HSM variables, start/end timestamps for HSMFSRST events.
Sample MQ Series reports were enhanced.
Enhanced support for NPM subtypes 18x/19x.
ANALDB2R PMACCnn reports caused ERRORS and ABENDS.
ASUMUOW Doc updated: which _K macro to use for what data.
%GLOBAL macro variables no longer %LET to null value.
Major enhancements added in MXG 19.07:
Errors in datasets PDB.ASUM70PR, PDB.ASUMCEC, and PDB.TYPE70PR
were introduced by MXG 19.05 and not completely fixed by MXG 19.06
changes. IBM's unexpected insertion of segments for spare CPUs in
type 70 records (APAR OW49536) precipitated Change 19.189 to fix,
and that worked fine with 2064 CPUs, but failed with 9672 data.
The next fix took care of 9672s, but that fix created too large
values for LPnDUR, causing bad percentages, but now only on 2064s.
And then a user pointed out that Dedicated CPUs were not quite
correctly summed in ASUM70PR logic. Another user had mis-matched
values for LPAR busy of the same LPAR from three different systems
with MXG 18.18, because he had Dedicated/Wait Complete CPUs, and
(after hours of looking at his data, I re-found my) Change 17.203
that created PDB.ASUMCEC to solve the problem with missing values
and Dedicated/Wait Complete processors. (That the values were not
missing in his 18.18 data was itself an error also now corrected).
And Change 19.201 was needed to correct variable SHIFT in ASUM70PR
and ASUMCEC.
But, in summary, we did not handle that APAR well!
Major enhancements added in MXG 19.06:
Support for Tivoli/Netview NPM 2.6 COMPATIBLE.
Support for NTSMF SMS Objects.
"Support" for DB2 QLES section added to DB2STATS.
Major enhancements added in MXG 19.05:
Support for APAR OW49806, z/OS 1.1 and 1.2 required correction.
Support Windows 2000, SP2 for Exchange 2000, SQLSERVER, objects.
Support for Serena's Ultimizer user SMF record
Support for SMF type 82 crypto facility record.
New RMFINTRV vars PARTISHN TOTSHARE LPARSHAR CECSER
Revised to invoke VMXG70PR to match RMFINTRV interval
Major enhancements added in MXG 19.04:
Support for z/OS Version 1 Release 2, most new stuff (COMPATIBLE):
Existing important SMF and RMF records have been updated, but
some new data records, SMF 109, SMF 119 are not yet written.
See Change 19.176. (SMF 119 support was added in MXG 19.09).
Support for CICS/TS 2.2 Subtype 1 CICSTRAN (COMPATIBLE, unless you
have tailored MXG process any optional "user" segments in your
SMF 110 Subtype 1 Performance record (how to tell?: if you have
any tailored IMACICxx members in your USERID.SOURCLIB).
This support does NOT yet support the Subtype 2 Statistics 110.
See Change 19.181.
Support for IMS 6.1 Fast Path records (INCOMPAT)
Support for CISCO Works Blue ISM user SMF record st 01/05/06/66.
Support for WAS/390 4.0 EE Websphere SMF 120; won't fail, but this
support requires SAS V8.2+ for some character variables to be
valid; IBM introduced "Unicode" UCS/DBCS data in SMF 120's.
New SPINSORT member to sort SPIN if MXG moves from MVS to ASCII.
Documentation of the IHDRxxxx "INFILE" header exits.
Support for NTSMF V 2.4.2.11 & Windows 2000 changes.
Major enhancements added in MXG 19.03:
Support for TPF releases PUT08, PUT10, PUT12 (INCOMPATIBLE).
Support for z/VM 3.1 and VM/ESA 2.4 on z900 CPUs.
Revisions to ASMIMSL5 (5.1) and ASMIMSL6 (6.1 and 7.1) IMS log.
Enhanced ASUMCACH, from 74s: DASD Cache and DASD I/O.
New TYPE42XV dataset for XRC Volume segments.
Correction for TNG STARTIME, two-digit base-36, etc.
Read same MXG dataset from many DDnames/libraries with VGETDDS
Major enhancements added in MXG 19.02:
New MSU calculations were wrong with new z/OS 70 records.
PDB.ASUMUOW now contains USERCHAR from CICSTRAN.
Support for BMC Mainview Batch Optimizer, BMO SMF.
Support for DCOLLECT APAR OW48529, new value.
Support for HMF Subtypes 29, 30, and 31.
Support for IBM changes to Websphere SMF 120 record.
Support for SMF 102 IFCID 096 was corrected.
Support for objects NETWORKINTERFACE and PAGINGFILE.
ANALUSS example sums CPU time from USS/OMVS task's type 30s.
ASMIMSLn deletes IMS 01 records with recovery bit.
CICSTRAN STRTTIME/ENDTIME did not include Leap seconds.
JCL example to use BatchPipes with SAS - big savings!
KEEPALL=YES is now specified in ASUMs to save CPU.
SAS V8.2 WARNING: OPTION BLKSIZE(2311) NOT SUPPORTED.
Spurious SAS NOTE: "might be uninitialized".
TYPE73 records different for SMF73CMG=1 and SMF73CMG=2.
Major enhancements added in MXG 19.01:
z900 2064s and ICFs without OW48190 have wrong CPU count.
- causes CPU busy values to be wrong, too. Change 19.015
DB2ACCT Parallel Transactions are double accounted.
- See 19.027. IBM now "rolls up" child records into duplicate.
Duplicate observations created in MQMMSGDM dataset.
- See Change 19.054. MXG 18.18 error had two outputs.
Support for APAR OW46268 TYPE74 USS Kernel in place.
Support for APAR OW46622 for Temporal Affinity.
Support for CICS TCP/IP EZA01 optional variables.
Support for IMS Version 7.1 Log Records - no changes.
Support for Omegamon/IMS V500 - no changes.
Support for Tandem G06/G07/G08 CPU & DISK records.
Support for Landmark's The Monitor for IMS records.
Support for TLMS Release 5.5 (COMPATIBLE).
Support for CA/TNG new, post-9907 V6, format (INCOMPAT).
CICS CPU time captured is now documented in ADOC110.
Protection for invalid ALOCTIME (before INITTIME).
CHAIN logic in IMF IMS trans corrects negatives.
See member NEWSLTRS or the Newsletters frame at www.mxg.com for
current MXG Technical Notes that used to be in CHANGES.
MXG 19.19 has been tested with SAS V8.2 and SAS V6.09 on OS/390, and
with SAS V8.2 on Windows 98 and 2000 and Linux RH 7.2, but should run
without error under V8.2 on every possible SAS platform!
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 15, 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
OS/390 2.6.0 Sep 24, 1998 16.04
OS/390 2.7.0 Mar 26, 1999 16.09
OS/390 2.7.0 APAR OW41317 Mar 31, 2000 18.03
OS/390 2.8.0 Aug 24, 1999 16.09
OS/390 2.8.0 APAR OW41317 Mar 31, 2000 18.03
OS/390 2.8.0 FICON/SHARK Aug 24, 1999 17.08
OS/390 2.8.0 APAR OW41317 Mar 31, 2000 18.03
OS/390 2.9.0 Mar 31, 2000 18.03
OS/390 2.10.0 Sep 15, 2000 18.06
OS/390 PAV Oct 24, 2000 18.09
z/OS 1.1 Mar 30, 2001 18.11
z/OS 1.1 on 2064s Mar 30, 2001 19.01
z/OS 1.1 with correct MSU Mar 30, 2001 19.02
z/OS 1.2 Oct 31, 2001 19.04
z/OS 1.1,1.2 APARs to 78 Oct 31, 2001 19.05
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 CICS/TS 1.2 Oct 27, 1997 15.06
CICS-TS V1R3 CICS/TS 1.3 Mar 15, 1999 17.04
CICS-TS for Z/OS Version 2.1 Mar 15, 2001 18.11
CICS-TS for Z/OS Version 2.2 Oct 31, 2001 19.04
CICSTRAN subtype 1 support only 19.04
CICSTRAN subtype 2 completed 19.05
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
DB2 6.1.0 initial support Mar 15, 1999 16.09
DB2 6.1.0 all buffer pools Mar 15, 1999 18.01
DB2 7.1.0 Mar 30, 2001 18.11
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
DFSMS/MVS 1.4 HSM Sep 23, 1998 16.04
DFSMS/MVS 1.5 ??? ??, 1999 16.04
MQM 1.1.2, 1.1.3, 1.1.4 Apr 25, 1996 14.02
MQ Series 1.2.0 May 26, 1998 16.02
MQ Series 2.1.0 Oct 2, 1999 17.07
MQ Series 5.2 Dec 16, 2000 18.10
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
NPM 2.4 Nov 18, 1998 17.01
NPM 2.5 Feb ??, 2000 18.02
NPM 2.6 Nov ??, 2001 19.06
RMDS 2.1, 2.2 Dec 12, 1995 12.12
RMDS 2.3 Jan 31, 2002 19.11
TCP/IP 3.1 Jun 12, 1995 12.12
TCP/IP 3.4 Sep 22, 1998 16.04
DOS/VSE POWER V6.3.0 Dec 19, 1998 16.08
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
VM/ESA 2.3 Jun 1, 1998 16.08
VM/ESA 2.4 Mar 1, 2001 19.03
z/VM 3.1 Mar 1, 2001 19.03
IMS 4.1 Jul 4, 1994 12.02
IMS 5.1 Jun 9, 1996 14.05
IMS 6.1 ??? ?, 199? 16.04
AS400 3.7.0 Nov 1, 1996 15.01
AS400 4.1.0 Dec 30, 1996 15.08
AS400 4.2.0 Apr 27, 1998 16.02
AS400 4.4.0 Sep 27, 1999 17.07
AS400 4.5.0 Jul 27, 2000 18.07
Availability dates for non-IBM products and MXG version required:
MXG Version
Product Name Required
SAS Institute
MXG executes best under SAS Version 8.2, with 82BX01 HOTFIX for
MVS-OS/390-z/OS which includes Critical 81BA57 fix).
See Newsletter FORTY for expanded discussion of other versions.
Read member NEWSLTRS (search 'V8') for SAS Version 8 notes.
Microsoft
Windows NT 4.0 and NT 3.51 14.14
Windows NT 4.0 Service Pack 2 15.03
Windows NT 4.0 Service Pack 5 16.04
Windows 2000 Build 2195 17.10
Demand Technology
NTSMF Version 1 Beta 14.11
NTSMF Version 2.0 15.05
NTSMF Version 2.1 15.06
NTSMF Version 2.2 16.04
NTSMF Version 2.3 17.10
Landmark
The Monitor for DB2 Version 2 13.06
The Monitor for DB2 Version 3.0 16.02
The Monitor for DB2 Version 3.1 16.02
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 CICS V400 User SMF 16.02
Omegamon for CICS V400 type 110 segments 16.02
Omegamon for CICS V500 User SMF 18.01
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 VTAM V400 15.15
Omegamon for VTAM V500 18.08
Omegamon for SMS V100/V110 12.03
CA
ACF2 6.2 16.04
ASTEX 2.1 14.04
NETSPY 4.7 14.03
NETSPY 5.0 14.03
NETSPY 5.2 16.05
NETSPY 5.3 18.03
Boole & Babbage
IMF 3.1 (for IMS 5.1) 12.12
IMF 3.2 (for IMS 6.1 only) 15.09
IMF 3.2 (for IMS 5.1 and 6.1) 16.04
Memorex/Telex
LMS 3.1 12.12A
MXG IMS-Log Not-Officially-Supported
IMS 6.1 - ASMIMSL6/TYPEIMSA 19.03
IMS 5.1 - ASMIMSL5/TYPEIMSA 19.03
Amdahl
APAF 4.1, 4.3 16.08
II. Incompatibilities and Installation of MXG 19.19.
1. Incompatibilities introduced in MXG 19.19 (since MXG 18.18):
a- Changes in MXG architecture made between 18.18 and 19.19 that might
introduce incompatibilities.
- A small increase, perhaps 5-6MB, of virtual storage may be
required for BUILDPDB due to MXG code changes (new variables
and datasets require more REGION=, and Change 19.272) has
has been observed. If you have a fixed REGION=nnM in your
JCL, even a small increase could cause an ABEND, so you must
compare the region used in your current job (Total Memory on
on the SAS log, for that big DATA step) with your REGION,
and may need to increase your fixed REGION size. At present
REGION=128M is larger than any BUILDPDB, and thus should be
safe, if you can't use REGION=0 and must specify a value.
- COMPRESS=YES is now the MXG default for new datasets. ITSV
sites have always had COMPRESS=YES specified, but if you did
not have that option set, you could see an increase in the
CPU time of BUILDPDB jobs. On some early CMOS systems cost
of compression was significant; you can turn it off with:
OPTIONS COMPRESS=NO;
Our benchmarks on 2064s with 307MB SMF showed:
Data Step sec BUILDPDB total CPU sec
NO YES NO YES CPU increase
18.18 71 -> 110 54% 172 -> 243 41% 71 seconds
19.19 106 -> 123 16% 205 -> 255 24% 50 seconds
The cost of compression with 18.18 was substantially higher
as a percentage than is the cost of compression with 19.19,
which mostly shows how poor percentages can be for real
comparisons. The real cost of total job compression is one
minute of CPU time per day for 300 MegaBytes of SMF data.
And you not only save lots of DASD space, but also avoid the
3am phone call that BUILDPDB had a B37 ABEND!
- Changes between 18.18 and 19.19 (new data, new subtypes
of existing BUILDPDB records) may cause a small increase in
the MXG CPU time for the "Big DATA" step; perhaps 2-3% for
an untailored BUILDPDB. But even when the new VMXGTIME time
zone convert option was enabled, the monster BUILDPDB that
reads almost every IBM and user SMF records, saw only a 12%
increase in the Big Data Step. However, other MXG changes
(KEEPALL=YES in VMXGSUM invocations) actually significantly
reduced the CPU time for the rest of the BUILDPDB job, and
the net increase (again, with VMXGTIME enabled) was only 5%:
Extended BUILDPDB Timings 307MB SMF;
Big DATA step BUILDPDB Job Total
18.18 110 sec 102MB 243 sec 104MB
19.19 123 sec 105MB 255 sec 107MB
Other cross-hardware benchmarks without VMXGTIME enabled
showed 2064 CPU time increased by 3% but by 5% on 9672
- MXG changed Landmark Support code for IMS, DB2, MVS:
Datetime values are now automatically converted from
GMT to LOCAL, as there is an offset in those records.
Landmark CICS values are NOT changed, because I could
not confirm if they should be. See Change 19.288.
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.
MXG Definitions with regard to MXG Software Changes:
COMPATIBLE A change in a data record which did not alter either
the location or the format of all of the previously-
kept MXG variables is COMPATIBLE, and you can continue
to run the old version of MXG software, which will read
the new records without error, but none of any new data
fields or any new record subtypes will be created/kept
until you install the MXG Version with this change.
A change that alters any previously kept variable is
INCOMPATIBLE, and requires the new version to be used.
TOLERATE In other words, the old MXG Version TOLERATES the new
data records, if they are COMPATIBLY changed.
EXPLOIT Once you use the new MXG Version to read the changed
records, all of the new fields, subtypes, etc, that are
described in this change will be created in the MXG
datasets, so the new MXG Version EXPLOITS the new data,
and you have full support of the new data records.
INCOMPAT A change in a data record that causes the current MXG
version to fail, visibly or invisibly, with or without
error conditions or messages, and the output datasets
may contain wrong values and incomplete observations,
and/or observations may have been lost.
You MUST install the new MXG Version with this change
to process data records that have been INCOMPATIBLY
changed by their vendor.
III. Online Documentation of MXG Software.
MXG Documentation is now described in member DOCUMENT.
See also member INDEX, but it may be overwhelming.
IV. 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 always identifies the actual version and release of
MXG Software that is contained in that library.
The CHANGES selection on our homepage at http://www.MXG.com
is always the most current information on MXG Software status,
and is frequently updated.
Important changes are also posted to the MXG-L ListServer, which is
also described by a selection on the homepage. Please subscribe.
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 need be made by users).
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 18.18 now in MXG 19.11:
Dataset/
Member Change Description
none 19.234 MXG Software (all versions) supports the euro symbol.
Many 19.176 Support for z/OS Version 1 Release 2 (COMPAT)
ADOC110 19.025 CICS CPU time captured is now documented in ADOC110.
ANAL115 19.231 Sample MQ Series reports were enhanced.
ANAL16 19.257 Select SORTs with concat SYSIN, then matching 14 15.
ANAL30 19.257 Select step records, then corresponding 14 15 & 64s.
ANALDB2R 19.222 ANALDB2R PMACCnn reports caused ERRORS and ABENDS.
ANALQAPM 19.262 Sample AS/400 report from QAPM Perf Monitor data
ANALUSS 19.087 Example to sum CPU time from USS aka OMVS 30 records.
ASMIMSL5 19.135 MXG 19.01-19.02 only. Change 19.061 removed.
ASMIMSL6 19.135 MXG 19.01-19.02 only. Change 19.061 removed.
ASMIMSLn 19.061 IMS 01 records with recovery bit are deleted.
ASMTAPES 19.259 MXGTMNT DDNAME in SMF wrong if tape on 4-digit UCB.
ASUM70PR 19.015 z900 and ICFs without OW48190 have wrong CPU count.
ASUM70PR 19.201 Revised to invoke VMXG70PR to match RMFINTRV interval
ASUMCACH 19.123 Enhanced ASUMCACH, from 74s: DASD Cache and DASD I/O.
ASUMCACH 19.167 INVALID ARGUMENT TO FUNCTION INPUT corrected.
ASUMUOW 19.219 Doc only. Which _K macro to use for what.
ASUMxxxx 19.074 KEEPALL=YES is now specified in ASUMs to save CPU.
AUTOEXEC 19.279 MXG now sets OPTIONS COMPRESS=YES as default.
BLDNTPDB 19.199 Incorrect copying in the weekly phase corrected.
BUIL3005 19.162 JES3-only, variable NETNAME (DJC) now kept in JOBS.
BUILDPDB 19.036 Variable ABENDS in PDB.JOBS counted pseudo steps.
BUILDPDB 19.237 Variable LOCLINFO in PDB.STEPS was not from step.
BUILDPDB 19.269 Initiator Number and Name added to PDB.JOBS.
CONFIGV8 19.089 SAS V8.2 WARNING: OPTION BLKSIZE(2311) NOT SUPPORTED.
FORMATS 19.073 Support for DCOLLECT APAR OW48529, new value.
IEFU84 19.269 SMF Exit to add Initiator Number and Name to SMF 30.
IHDRxxxx 19.232 Documentation of the IHDRxxxx "INFILE" header exits.
IMACICEZ 19.047 Support for CICS TCP/IP EZA01 optional variables.
JCLUOWP 19.079 JCL example to use BatchPipes with SAS - big savings!
MXGBYLE 19.272 Default of MXG numeric variables changed, externalizd
MXGLEN 19.272 Default of MXG numeric variables changed, externalizd
RMFINTRV 19.011 CPCNRCPU,CPFCNAME wrong for CPUTYPE='2064' in 18.18.
RMFINTRV 19.020 %VMXGRMFI(PDB=SMF) error, MERGERMF not found.
RMFINTRV 19.156 Using fewer than the default workloads caused Notes.
RMFINTRV 19.201 New RMFINTRV vars PARTISHN TOTSHARE LPARSHAR CECSER
SPINSORT 19.172 PROC SORT of SPIN if MXG moves from MVS to ASCII.
TIMEBILD 19.260 Change time zone of all datetime variables by SYSTEM.
TIMEBILD 19.286 LOCAL and GMT Time Zone Deltas for VMXGTIME.
TIMETABL 19.260 Change time zone of all datetime variables by SYSTEM.
TIMETABL 19.286 LOCAL and GMT Time Zone Deltas for VMXGTIME.
TRNDCEC 19.150 Example of TRENDing the ASUMCEC dataset.
TYPE102 19.019 Type 102 subtype 140 INPUTE EXCEEDED error.
TYPE102 19.081 Support for SMF 102 IFCID 096 was corrected.
TYPE110 19.028 Variables DSxPERCT in CICDS are endpoint values.
TYPE110 19.076 CICSTRAN STRTTIME/ENDTIME did not include Leap secs.
TYPE110 19.181 Support for CICS/TS 2.2 Subtype 1 CICSTRAN
TYPE110 19.224 Support for IBM CICS/TS 2.2 Statistics Record TCBs
TYPE110 19.293 Support for CICS/TS 2.2 CICSTRAN (INCOMPATIBLE).
TYPE115 19.054 Duplicate observations created in MQMMSGDM dataset.
TYPE116 19.139 Invalid SMF 116 with QWHS length=108 protected.
TYPE119 19.267 Support for SMF 119 IBM z/OS V1R2 CS TCP/IP Product
TYPE120 19.077 Support for IBM changes to Websphere SMF 120 record.
TYPE120 19.180 Support for WAS/390 4.0 EE Websphere SMF 120
TYPE28 19.211 Support for Tivoli/Netview NPM 2.6 COMPATIBLE.
TYPE28 19.221 Enhanced support for NPM subtypes 18x/19x.
TYPE28 19.264 NRPxxxxx variables in NPMINNRP were all missing
TYPE30 19.056 Protection for invalid ALOCTIME (before INITTIME).
TYPE30 19.163 Variable JOBCLASS was unprintable under ASCII SAS.
TYPE30 19.169 Initiator Number and Name added to TYPE30_1 job init.
TYPE30 19.283 Actual Midnight ALOCTIME=0 caused ELAPSTM=24 hours.
TYPE30_D 19.060 Variable BLKSIZE in TYPE30_D, PDB.DDSTATS, wrong.
TYPE42 19.043 TYPE 42 subtype 5 INPUT EXCEEDED reading VSAM SMF.
TYPE42 19.145 New TYPE42XV dataset for XRC Volume segments.
TYPE42 19.147 Invalid SMF 42-5 protected.
TYPE42 19.160 Type 42 subtypes 7 and 8 were revised.
TYPE42 19.173 INPUT STATEMENT EXCEEDED, SMF 42 ST 6, invalid.
TYPE60 19.174 INPUT STATEMENT EXCEEDED, VVRTYPE='Z' SMF 60.
TYPE7072 19.018 Zero-divide by SMF70CPA corrected (no impact).
TYPE7072 19.245 Support for CRYPTO RMF 70 Subtype 2 APAR OW49808.
TYPE70PR 19.030 LPARCPUS=0 if back level OS/390 and no OW37565.
TYPE70PR 19.189 APAR OW49536 "spare" LPARCPUS/LPnNRPRC counted.
TYPE71 19.270 CSFRLSAV/ESFRLSAV can be small negative, reset to 0.
TYPE73 19.084 Offline channels in TYPE73, document CMG=1 and CMG=2.
TYPE73 19.240 MXG 19.04-19.07: PCHANBY/PNCHANBY/ONLINE were WRONG.
TYPE74 19.017 Support for APAR OW46268 TYPE74 USS Kernel in place.
TYPE74 19.186 "Broken" 74 subtype 4 incorrectly output in TYPE74CF.
TYPE74 19.239 TYPE74CF/TYPE74ST some R744S/R744F variables wrong.
TYPE78 19.070 TYPE78SP's _BTY73SP BY list didn't remove all dupes.
TYPE78 19.203 Support for APAR OW49806, z/OS 1.1 and 1.2 correction
TYPE79 19.051 Support for APAR OW46622 for Temporal Affinity.
TYPE82 19.200 Support for SMF type 82 crypto facility record.
TYPE91 19.241 Batch Pipes datasets have added variables for merge.
TYPE94 19.290 Support for APAR OW52989, adds 8-way AX0 controlers.
TYPEAIX 19.261 Support for IBM AIX Performance Toolbox, PTX V2.
TYPECIMS 19.031 CHAIN logic in IMF IMS trans corrects negatives.
TYPECISM 19.158 Support for CISCO Works Blue ISM user SMF record.
TYPEDB2 19.027 DB2ACCT Parallel Transactions are double accounted.
TYPEDB2 19.213 DB2 V7 QLES section variables added to DB2STATS.
TYPEEDGR 19.252 Variables added by OW40710 in 1999 now added in MXG.
TYPEEDGS 19.284 DFSMS/rmm "V" records had blank MVDSNx variables.
TYPEHMF 19.082 Support for HMF Subtypes 29, 30, and 31.
TYPEHSM 19.227 New vars, start/end timestamps for HSMFSRST events.
TYPEIDML 19.244 Support for IDMS Log Statistics Records.
TYPEIMS 19.046 Support for IMS Version 7.1 Log Records.
TYPEIMS 19.242 IMSGTEXT/OMSGTEXT were incorrect.
TYPEIMS7 19.117 NMSGPROC in IMS0708 no longer counts unmatched 08's.
TYPEIMSA 19.177 Support for IMS 6.1 Fast Path records (INCOMPAT)
TYPEIMSA 19.188 Times were GMT vice local: IMS SRV/RES/ TM/TS.
TYPEITRF 19.003 Support for Omegamon/IMS V500 - no changes.
TYPEMBO 19.067 Support for BMC Mainview Batch Optimizer, BMO SMF.
TYPEMPLX 19.185 Support for the Implex User SMF record.
TYPENDM 19.275 NDMCPUTM added in NDM/Connect Direct records.
TYPENSPY 19.044 NETSPY type 'R' INPUT STATEMENT EXCEEDED.
TYPENTSM 19.065 Support for objects NETWORKINTERFACE and PAGINGFILE.
TYPENTSM 19.148 Support for NTSMF V 2.4.2.11 & Windows 2000 changes.
TYPENTSM 19.153 Corrections for Process with NRDATA=27, old NTSMFs.
TYPENTSM 19.197 New Windows 2000, Exchange 2000, etc, objects.
TYPENTSM 19.214 Support for NTSMF SMS Objects.
TYPENTSM 19.276 MSEXCHANGE DS object has new variables.
TYPEQACS 19.289 Support for OS/400 Release 5.1.0 Collection Services
TYPERSDA 19.229 Support for RSD Folders ASTRE Auditing User SMF rec.
TYPESFTA 19.166 Soft Audit variable STEPNAME contained SYSTEM.
TYPESHDW 19.032 Shadow Direct INPUT STATEMENT EXCEEDED error.
TYPESTC 19.264 Zero observations in HSC dataset STCHSC from STK SMF.
TYPESYNC 19.004 Array name DD conflicts with existing DD variable.
TYPESYNC 19.228 VARIABLE UNIT1 HAS BEEN DEFINED AS BOTH CHARACTER
TYPETAND 19.029 Support for Tandem G06/G07/G08 CPU & DISK records.
TYPETCP 19.053 SMF 118 ERROR.4. HFS FILE error created in error.
TYPETIMS 19.050 Support for Landmark's The Monitor for IMS records.
TYPETIMS 19.288 Landmark for IMS datetime variable now on Local zone.
TYPETLMS 19.013 Support for TLMS Release 5.5 (COMPATIBLE).
TYPETMDB 19.288 Landmark for DB2 datetime variable now on Local zone.
TYPETMNT 19.088 INITTIME could be off by one day.
TYPETMS5 19.164 TMS Audit variables TMAUxxxx/TMVAxxxx correct now.
TYPETMTC 19.225 Support for Landmark's TMON for TCP/IP v1.1.
TYPETMV2 19.288 Landmark for MVS datetime variable now on Local zone.
TYPETMV2 19.297 Support for Landmark Monitor for MVS Version 3.
TYPETNG 19.009 Support for CA/TNG new, post-9907, format (INCOMPAT).
TYPETNG 19.146 Correction for TNG STARTIME, two-digit base-36, etc.
TYPETPF 19.125 Support for TPF releases PUT08,PUT10,PUT12 INCOMPAT.
TYPETPF 19.136 TPF datetimes now corrected from GMT to local zone.
TYPETPF 19.170 TPF enhancements for wrapped counters.
TYPETSOM 19.075 New TSMPxxxx variables now kept in TSOMCALL dataset.
TYPEULTM 19.202 Support for Serena's Ultimizer user SMF record
TYPEVMXA 19.132 Support for z/VM 3.1 and VM/ESA 2.4 on z900 CPUs.
TYPEWWW 19.249 Support for WebLogs: IIS, WebSphere, CLF, Cookies+.
UGMTCHEK 19.287 Utility to check for datetime variables still on GMT
UGMTCHEK 19.287 Utility to examine if GMT values are in your data.
UNIXSAR 19.294 User contribution reads unix sar -A -f reports.
UTILCVRT 19.271 Utility converts historic MVS PDB's $HEX on ASCII.
UTILEXCL 19.293 UTILEXCL creates IMACEXCL without EDIT for CICS.
VGETDDS 19.116 Read same MXG dataset from many DDnames/libraries.
VGETOBS 19.247 New MXGDSN macro variable exist/zero obs detection.
VGETxxx 19.002 Documentation of VGETxxx macro naming convention.
VMXGDEL 19.268 Replaced use of PROC SQL/VTABLE in internal macro.
VMXGDEL 19.295 Lower case work. did not match upper case WORK.
VMXGDUR 19.282 SYNC59=NO specification did not work.
VMXGINIT 19.230 %GLOBAL macro variables no longer %LET to null value.
VMXGINIT 19.279 MXG now sets OPTIONS COMPRESS=YES as default.
VMXGOPTR 19.268 Replaced use of PROC SQL/VTABLE in internal macro.
VMXGRMFI 19.083 New MSU calculations wrong with new z/OS 70 records.
VMXGSUM 19.151 Use of TEMP01/TEMP02/TEMP03 revised.
VMXGSUM 19.246 New HOUSKEEP= option to leave temporary datasets.
VMXGSUM 19.251 &MXGLEN added, TEMPnn logic corrected, PROC SQL fix.
VMXGTIME 19.260 Change time zone of all datetime variables by SYSTEM.
VMXGTIME 19.286 LOCAL and GMT Time Zone Deltas for VMXGTIME.
VMXGUOW 19.092 PDB.ASUMUOW now contains USERCHAR from CICSTRAN.
VMXGWORL 19.063 Spurious SAS NOTE: "might be uninitialized".
Inverse chronological list of all Changes:
NEXTCHANGE: Version 19.
=======Changes thru 19.300 were in MXG 19.19 dated Feb 14, 2002=========
Change 19.300 One site using MXGTMNT MXG Tape Mount Monitor found their
ASMTAPES LOGREC filled with MXGTMNT generated X'E0' ABEND messages
Feb 13, 2002 to the extent that they had to stop MXGTMNT. This site
is a massive user of virtual tapes, and the E0 results
when the monitor saw the job at one pop, but the job is
no longer in the system a 2-second pop later, because its
done its virtual mount and ended in milliseconds.
The original design used a previously saved ALET during
cross-memory access to an address space for which a tape
mount occurred, but, no check was made to see if the ALET
has been invalidated because the job had ended.
Instead, this redesign will
- Save the ASID and JOBNAME for the job associated with
the device when it sees a mount pending, and now save
the STOKEN for the address space. Each STOKEN value is
unique across the life of the IPL, whereas the ASID and
the ALET are not.
- When the CROSSMEM routine executes, it checks to see if
the STOKEN for the address space it is in (ASSBSTKN in
the ASSB) matches what was saved previously when the
mount was detected; if it matches, it's safe to do the
SAC instruction. If the STOKEN does not match, then
the original address space that caused the mount is
indeed gone, and we will stop CROSSMEM processing for
that address space.
-The SMF record will be written the same way a job
change is currently handled: MXGTMNT writes out the
SMF record as it is up to that point, without the
allocation information in it. The data currently
captured from the ACEE, JCT, OUCB, ACT, JMR, DSAB, and
the SCT will be missing from these records.
This enhancement to MXGTMNT will be "ML-21" and the
ASMTAPES member will have that noted at its beginning.
As of the February 14 start of tape build for MXG 19.19
this change has only been designed; if you encounter
significant counts of LOGREC 0E ABEND messages from the
MXGTMNT program, please request the "ML-21" level of
the ASMTAPES member, and it will be sent when tested.
Feb 27, 2002: ML-21 is now available, Change 20.011.
Change 19.299 MXG Messages "New NTSMF OBJECT Found" did not contain the
VMACNTSM name of the SYSTEM with the new object, making it hard to
Feb 13, 2002 know on which system to enable NTSMF's DISCOVERY option.
Sending the discover file to support@mxg.com is all that
is needed to add support for the new object into MXG.
But if that message has OBJECT=, then you
will need to contact NTSMF support, because that message
results when the MicroSoft code-writer failed to comply
with standards, so the NTSMF programmers have to develop
a fix to Cover Their Actions and get the correct name.
Thanks to Denny C. Wong, New York Life Insurance, USA.
Change 19.298 Variables for Storage Class name are now input in subtype
VMACSTC 16, 17, and 18 STK records, as is STC17MVC, the VOLSER in
Feb 13, 2002 subtype 17.
Thanks to John Ellis, Powergen Retail, ENGLAND.
Change 19.297 Support for Landmark TMON for MVS Version 3.0 (INCOMPAT).
VMACTMV2 The documentation does not agree with their actual data,
Feb 13, 2002 but by considerable sleuthing I believe I have found what
Oct 17, 2002 was changed, but you must validate this support with your
data, and report any discrepancies to support@mxg.com.
The DV record is bypassed because it has inserted data
that I can't figure out, but these 3.0 datasets have been
created and printed and look okay except as noted:
XIS, XIM, XI, WG , TR (DURATM is in error in the record)
SYS, YSSW, YSUI, PS (CHANGED) NQ, MLV, MLL, MLG, LC,
JDSW, JDDL, JDIN (suspect) EL CS,CP,CH,CF (suspect)
Oct 17, 2002: Support for TMON/MVS V3.0 and 3.1 is
now in member TYPETMVS/TYPSTMVS/VMACTMVS and not in
the TMV2 suffixes. See Change 20.201.
Thanks to John Jackson, REDCATS (UK), ENGLAND.
Thanks to Jim S. Horne, Lowe's Companies, USA.
Change 19.296 While DCOLLECT is generally used to graze your DASD farm
ASMVTOC for dataset space, etc., there are cases when ASMVTOC is
Feb 13, 2002 needed, and this revision will make it easier and better
when you need to look at all the VTOCs.
-The program now allows Volume select/exclude processing,
so you can avoid multiple scans of volumes shared between
images. To invoke select/exclude, set PARM='VOLLIST' and
add a //VOLLIST DD.
-The program revised the CVAFSEQ access to handle UCBs
that are above the line.
Thanks to Brian Crow, British Telecom, ENGLAND.
Change 19.295 An ITSV-only problem appears to have been introduced by
VMXGDEL SAS Version 8.2; apparenly the ITSV %CMSTART macro now
VMXGINIT sets the option USER='work', and VMXGDEL tried to compare
Feb 13, 2002 work.DB2STAT2 with WORK.DB2STAT2, which was not equal, so
VMXGDEL deleted the WORK.DB2STAT2 dataset it had built.
This change protects the VMXGDEL test with UPCASE, but
also VMXGINIT was enhanced to force the USER and SASWORK
options to upper case if they had been lower case, for
consistency.
Thanks to Roderic Gass, British Energy Group, ENGLAND.
Change 19.294 This user contribution processes unix sar reports files
UNIXSAR created with the command sar -A -f sardata.mmmyy
Feb 12, 2002 This preliminary code will eventually be revised into the
normal MXG member naming, macros, etc, but this code will
give you access to the sar information now.
Thanks to Carmen Vitullo, Acxiom, USA
Thanks to Uriel Carrasquilla, NCCI, USA.
Change 19.293 -Support for CICS/TS 2.2 CICSTRAN (INCOMPATIBLE, IBM again
VMAC110 inserted new fields in their SMF 110 subtype 1 records.
UTILEXCL -New UTILEXCL program for EXCLUDEd fields in CICS records
Feb 9, 2002 automatically creates the tailored IMACEXCL member from
Feb 11, 2002 your CICS dictionary SMF records, eliminating any manual
EDITing of the IMACEXCL member. In addition, using the
UTILEXCL to create an IMACEXCL member, even if you don't
exclude fields, will provide performance benefits:
- a single INPUT statement for each APPLID is created;
the default TYPE110 code has many conditional tests
that break up the INPUT statement, and that is more
CPU-expensive that a single INPUT execution.
- conversion statements (times are multiplied by 16) are
only generated for the fields that are input. The
old IMACEXCL you created skipped over Exclude fields,
but then all variables were converted, causing many
unnecessary calculations on missing values, which is
itself a performance negative in SAS V8.
- all EXCLUDEd fields are DROPped automatically, so you
do not have to tailor the KEEP or DROP macros for the
CICSTRAN dataset.
This is new and very powerful; see its comments.
And this design will be enhanced: I would like to detect
changes in your CICS dictionary and create a new IMACEXCL
that can use SMFTIME to differentiate the old from the
new records from the same APPLID, in a future revision.
Change 19.292 Overdue cleanup of TRENDing for DB2 datasets has correct
TRNDDB2A spelling of all variables and KEEPALL=YES is specified on
TRNDDB2B each VMXGSUM invocation so they work. The TRNDDB2X member
TRNDDB2S summarizes the DB2STATB, Interval Buffer Statistics, by
TRNDDB2X Buffer Pool, named TRNDDB2X because TRNDDB2B is used for
Feb 8, 2002 the DB2ACCTB (Plan Buffer Details, by Buffer Pool).
Change 19.291 The NOAMSGID field in the Version 2.3 record is now an
VMACNOAM 8-byte character variable, instead of a 2-byte numeric,
Feb 6, 2002 so it is now input into new variable NOAMSGCH.
Thanks to Mike Fry, HSBC, ENGLAND.
Change 19.290 Support for IBM SMF 94 record, APAR OW52989 that added
VMAC94 support for 8-way AX0 controllers (AX0 to AX7). MXG will
Feb 6, 2002 input the additional 4 AXO's data fields when they are
present.
Thanks to Alex MacFarlane, Bank of New York, USA.
Change 19.289 MXG Support for OS/400 Release 5.1.0 Collections Services
EXQAPJOL was added in the TYPEQACS member (introduced in 4.5 for
EXQAPJOM IBM's first Collection Services), instead of the TYPEQAPM
EXQAPJOM member, because the records were completely incompatibly
EXQAPJOL restrucured, and in three instances, split apart. While
EXQAPPOB the Member name you execute is changed from QAPM to QACS,
EXQAPPOL all datasets created still start with QAPMxxxx and all of
EXQAPPOT the former variable names are preserved. Three old files
EXQAPSYC are split: JOBS, POOL, and SYS. For example, from IBM's
EXQAPSYL Collection Services documentation:
EXQAPSYT Performance data files: QAPMJOBS and QAPMJOBL.
IMACQACS The QAPMJOBL file is provided for compatibilty with
TYPEQACS the PM and combines data from QAPMJOBMI and QAPMJOBOS
TYPSQACS files. The QAPMJOBS file is created when the PM
VMXGINIT database files are migrated with the Convert
Feb 6, 2002 Performance Data commmand (CVTPFRDTA) to the new
Feb 9, 2002 release, but Collection Services does not create the
QAPMJOBS file.
MXG will create QAPMJOBL, or QAPMJOBM, or QAPMJOBO, from
whichever those three files you create, but it appears
the new "Logical" dataset, QAPMJOBL, contains all that
was in the old QAPMJOBS dataset, so the JOBMI/JOBOS files
probably are not needed. And similarly, the POOL records
are split and create QAPMPOLB, QAPMPOLL (old QAPMPOOL),
and QAPMPOLT datasets from those three Pool files, and
the SYS records now create QAPMSYSC, QAPMSYSL (old
QAPMSYS), and QAPMSYST datasets from those files. Your
choice of macros you invoke in your copy of TYPEQACS
determines what MXG will create. This changes has been
validated with all of the above records, plus QACSCONF
and QACSDISK, but there are three new records (JSUM, TCP,
and TCPIFC) that have not been requested (i.e., test
data). The list of specific LRECLs that must be used to
upload to MVS (or to use in your FILENAME statement on
ASCII) are listed in the comments in VMACQACS.
Thanks to Paul Gillis, Pacific Management Systems, AUSTRALIA.
Thanks to Gary Katerelos, Coles Meyer, AUSTRALIA.
Thanks to Martyn Jones, ABN-AMRO, THE NETHERLANDS.
======Changes thru 19.288 were in MXG 19.11 dated Feb 4, 2002======
Change 19.288 MXG Support for Landmark's IMS, DB2, and MVS products is
VMACTIMS changed INCOMPATIBLY, possibly, because all datetimes are
VMACTMDB now converted from GMT to LOCAL, using the record's GMT
VMACTMO2 offset, which is the way is should have been done.
VMACTMV2 IF YOU USE THESE PRODUCTS, YOUR TIMES WILL CHANGE FROM
Feb 3, 2002 GMT TO LOCAL, OR IF YOU ARE ALREADY CHANGING THOSE FIELDS
IN MXG EXITS OR IN OUR REPORTS, YOUR REPORTS WILL CHANGE
FROM RIGHT TO WRONG, and you will need to remove your
tailoring code. (Of course, if your site's GMT offset is
zero, no change in before or after values will occur.)
Alternatively, you could use the new TIMEBILD/TIMETABL
in Change 19.286 to change those local times back to
GMT, using a TIMETABL just for these MXG jobs with the
negative of the GMT offset in the LOCAL delta entry,
and with SYSTEM blank. help.
Note that ONLY Landmark IMS, DB2, and MVS were changed;
the CICS support in TYPETMO2 is still unchanged, because
there IS no GMT offset in those records. In fact, you
can now use the new TIMEBILD architecture for your
TYPETMO2 jobs to convert those GMT datetimes into local.
Change 19.287 Utility UGMTCHEK selects all datetime variables in all
UGMTCHEK datasets in a SAS data library, PROC PRINTs only those
VMXGPRAL variables from the first observation, and PROC MEANS to
Feb 2, 2002 get the min and max value of each datetime variable, so
that you can see whether a datetimestamp is on the local
or GMT time zone. Change 19.286 required knowledge of
the zone of each datetime variable, rarely found in the
record's documentation; only actual data can confirm the
time zone of a datetime variable, hence this new utility.
MXG always intends to convert datetime variables to the
local timezone, if a GMT offset is present in the record,
and for the vast majority of data, times are local zone.
UGMTCHEK requires SAS V8 because it uses the AUTONAME
option (so variable names in MEANS output are appended
with their statistic: SMFTIME_MIN and SMFTIME_MAX for
these reports; it is still my intention NOT to create any
real MXG variables in MXG datasets with names longer than
8-characters, but AUTONAME was perfect for this report.
UGMTCHEK uses %VMXGPRAL to "PRint ALL datasets in a SAS
Data Library"; VMXGPRAL was revised to choose any or all
of the three procs (CONTENTS, MEANS, PRINT) to execute;
in this instance, I only wanted a PRINT of each dataset.
Change 19.286 LOCAL and GMT Time Zones Delta conversion in VMXGTIME.
IMACINIT -This enhancement to Change 19.260 supports two time zones
TIMEBILD in TIMETABL: a LOCAL delta for datetime variables on the
TIMETABL local time zone, and a GMT delta for those few variables
VMACmanymany still on GMT time zone (because there is no GMT-offset
VMXGTIME in their record). All GMT-time-zone datetime variables
VMXGINIT were put in separate %VMXGTIME source statements:
Feb 2, 2002 %VMXGTIME(.list-of-GMT-vars.,SYSTEM,GMT=YES)
Feb 5, 2002 so that VMXGTIME uses the GMT delta column in TIMETABL
Feb 8, 2002 member to convert those variables.
Feb 11, 2002 Almost all important variables are in local time zone,
but actual data is the only way to know for sure, so
all possible data records were run thru the UGMTCHEK
utility that display the actual values of each variable
that has a datetime format in all datasets in a PDB.
But since vendors can add GMT offsets, and they will be
used when found, you should use UGMTCHEK against your
own datasets to confirm and validate your datetimes.
The full list of GMT variables is at the end of this
change, and it will be revised if vendors add GMT
offsets to their records, or if your validation shows
that I've overlooked something.
If there is a difference in your datetime values, check
your "USERID.SOURCLIB" Exit members (EXdddddd) to see
if the previous MXG-person changed those values in your
installation tailoring exit member.
The specific case that created VMXGTIME was a site with
multiple LPARs, each on different time zones, and this
change is running in production to bring all of those
data to the common, local time zone of the data center.
But for records that do not contain a GMT Offset, you can
now enable TIMEBLD with a zero LOCAL Delta and your site
GMT offset for the GMT delta, and convert GMT datetimes
based on your instructions in TIMETABL.
Most MXG datetimestamp variables contain local time; the
SMFSTAMP/RMFSTAMP informats are local; most TODSTAMPs are
GMT, but are converted if there is a GMT offset. Records
that contain only the first 4-bytes of GMT offset were
originally decoded with this calculation:
INPUT OFFSET &IB.4. @; OFFSET=1.048576*OFFSET;
but the result can be off by a second, it has no obvious
reason for that constant, and must be "rounded" to give
picture-pretty values. And now, real logic can be used
to replace that engineering estimate:
INPUT GMTCHAR $CHAR4. @;
OFFSET=INPUT( (GMTCHAR!!'00000000'X),&IB.8.6)/4096;
IF . LT OFFSET LT 0 THEN OFFSET=CEIL(OFFSET);
ELSE OFFSET=FLOOR(OFFSET);
Only a few members had the old code.
Two very important "token" variables that are necessary
to match records together, READTIME and UOWTIME, are
NOT converted by VMXGTIME:
READTIME - its time zone is that of the SYSTEM that saw
the job card, but the records on this SYSTEM
do not tell where the job was input (except
for the type 26 purge record), so it is not
possible to correctly re-zone READTIME. And
even if it were, you would have the READTIME
in your PDB datasets different that READTIME
in the other (unprocessed) SMF data.
UOWTIME - similarly, it's time zone is unknown, and it
must be unchanged to allow CICS and DB2 to
be merged in ASUMUOW.
The variables below are still in GMT time zone (because
there is no GMT offset value in their data records) so
they are in VMXGTIME (GMT=YES) statements, and will be
converted only if you have a non-zero GMT-offset value
in your TIMETABL member:
VMAC110:
A06GOFTM A06GONTM A08GBKCD A08GBKDD A14GACT A14GADT
A17GCLST A17GOPNT AUSGOFTM AUSGONTM D2GCONGM D2GDISGM
DS2LSTRT DS2START DS3LSTRT DS3START DS4LSTRT DS5LSTRT
DS6LSTRT DSGLRT DSGLSTRT DSGLSTRT DSGLSTRT DSGSTART
GLRHGMT GLRUGMT SORCLOSG SOROPENG STACTIME STADTIME
STGCSTRT STGLRTVL
VMAC116:
WQCLOSTI WQOPENTI WTASINTE WTASINTS WTASSTRT
VMAC119:
CITITIME CTTITIME CTTTTIME FCSETIME FCSTTIME FSSETIME
FSSTTIME NIINTIME NTTITIME NTTTTIME STTIME TITIME
TTETIME TTSTIME UCCTIME UCOTIME
VMAC42:
STARTIME ENDTIME
S42EXSTM S42EXETM
S42CCSST S42CCEIT S42CCSET
VMACCMF:
CMF29SCK CMF29TIM SMF29ECK SMF29PCK
VMACACF2:
ACSMFTOD LIDLUPT LIDPSTOD
VMACAPAF:
APAFTOD IMLTOD LITOD UPDATE
VMACASXT:
RSIOMT RSIO RCENDT
VMACHURN:
HU01RST HU02END HU05RST HU06RST HU08RST HU09RST
HU10RST HU11RST HU12RST HU12TIM1 HU12TIM2 HU12TIM3
HU12TIM4 HU12TIM5 HU13ETIM HU13RST HU13STIM HU16SSTM
HU22RST HU24RST HU25RST HU26RST HU40DRST HU42CRTM
HU47ONDT HU47RST HU49ONDT HU49RST HU50CRTM HU51CRTM
HU51DRST HU51RST HU52DRST HU52RST HU60CRTM HU60DRST
HU60SSTM HU61CRTM HU61DRST HU61RST HU62CRTM HU62DRST
HU62RST HU62SSTM HU72CRTM HU72DRST HU72RST HU72SSTM
HU72TSTM
VMACOMSM:
OMFS2STM OMFS2ETM OMFS2JTM
VMACSTC:
STC09TIM STC13MET STC13MST STC13TIM STC14TIM STC16MET
STC16MST STC18MET STC18MST STC18TIM STC19RET STC19RST
STC19TIM STC23TIM STC26MET STC26MST VARDATI VARDATL
VMACSUNS:
ENDTIME
VMACTMV2:
ENDTIME JDINTST JDITIME JDJETIME JDJSTIME JDOSTCK
JDRDTIME JDSETIME JDSSTIME LMRKCARK STARTIME TRLAST
TRSTCK TRSTK1 TRSTK2 TRSTK3
-Performance Impact:
- Changes between 18.18 and 19.19 (new data, new subtypes
of existing BUILDPDB records) may cause an increase in
the MXG CPU time for the "big DATA" step: perhaps 3%
for an untailored BUILDPDB, and as much as 12% at one
test site with a heavily tailored and extended PDB that
contains almost all possible IBM and user SMF records.
However, the CPU time for the post-big-DATA processing
was significantly with 19.19 than with 18.18, so the
net increase in the entire BUILDPDB job was only 5%:
Extended BUILDPDB Timings 307MB SMF;
Big DATA step BUILDPDB Job Total
18.18 110 sec 102MB 243 sec 104MB
19.19 123 sec 105MB 255 sec 107MB
- Many %VMXGTIME() invocation statements were added in
source code, but MXG initialization invokes %TIMEBILD
with TIMEBILD=NO to create a dummy %VMXGTIME macro that
has minimal impact on CPU and virtual storage costs.
- Enabling %TIMEBILD in your //SYSIN will create the real
%VMXGTIME macro, with a small, measurable compile cost,
but the actual execution CPU costs depend on how many
variables in how many records are actually changed.
- BUILDPDB with only default SMF records with no DB2/CICS
(375K records, 1.1GB) showed no increase between 18.18
and 19.19. Enabling VMXGTIME, CPU increased from 9 to
10 minutes.
- BUILDPDB with only default RMF records (4.8GM) also had
no increase between 18.18 and 19.19; enabling VMXGTIME
increased 79 seconds CPU time to 98 seconds.
MXG 19.07 base - 1637 CPU secs Virtual 69411K
MXG 19.19 disabled - 1638 CPU secs + 0% Virtual 69574K
MXG 19.19 enabled - 1839 CPU secs +12% Virtual 70951K
- The delta between 19.07 and 19.19 VMXGTIME-disabled
run shows there was no cost in adding that code.
- The VMXGTIME-enabled increase of 201 seconds is the
(small, fixed) compile-time cost of each %VMXGTIME
statement, and the actual execution costs to change
377 variable's values across those 10 million SMF
records to shift all records to the local zone.
There were 210 VMACxxxx members that were EDITed for this
change, with 1054 %VMXGTIME statements added that list in
excess of 1,500 datetime variables.
-Feb 8 revision. TIMEBILD with TIMEBILD=NO is now invoked
at MXG Initialization to create a null %VMXGTIME macro,
so there is NO cost for those %VMXGTIME() statements
added in MXG source code to provide this enhancement.
-Unrelated, but done as part of this change, there is a
new IMACINIT, for user tailoring at MXG Initialization,
which is included as the last statement each time that
%VMXGINIT is initialized or re-initialized. Likely very
few sites will ever need it, but now it's there.
-If you enable TIMEBILD, you can get a count of how many
variables were changed by adding this statement:
%PUT MXG USED VMXGTIME TO CONVERT &MXGTIMEC VARIABLES.;
at the end of your sysin.
Change 19.285 Incorrect macro references caused syntax errors if you
VMXG70PR used the OUT70PR= WORK.ASUM70PR or OUTCEC=WORK.ASUMCEC
Feb 1, 2002 arguments of %VMXGRMFI to send those two datasets to WORK
(VMXG70PR was wanted to only update the PLATxxxx vars in
the PDB.RMFINTRV dataset). The correct macro references
now work as documented.
Thanks to Helgund Linck, BASF IT Services GmbH, GERMANY.
Change 19.284 DFSMS/RMM "V" records have changed at some point in the
VMACEDGS past, but unless you wanted the MVDSNx fields, you would
Jan 31, 2002 not have notices. The +58 in the INPUT for the V record
is now +122 to skip over the new blank data inserted in
the record.
See Change 21.122, which changed the +122 back to +58,
and externalized the value in MACRO _LNEDGS.
Thanks to Bruce J. Danderline, Memorial Sloan Kettering, USA.
Change 19.283 My very earliest (1972) heuristic, to identify steps that
VMAC30 did not Allocate or Load by setting ALOCTIME or LOADTIME
Jan 31, 2002 to a missing value, was based on exact zero values in the
Feb 1, 2002 raw data, but has finally been exposed by a step that did
allocate exactly at midnight (0.00), causing ALOCTIME to
be wrong, ELAPSTM to be 24 hours, and ALOCTM negative in
step and interval datasets. A heuristic is required here
because IBM only provides times, without dates, for these
events timestamps. This revision eliminates any exposure
to incorrectly setting LOADTIME, now setting it missing
only when virtual storage was not acquired; if PVTTOP=0
PVTTOP=0, the "PROGRAM FETCH" event never occurred. And
with this external criteria to guarantee LOADTIME valid,
ALOCTIME can be always valid when LOADTIME is nonmissing.
One remaining exposure cannot be corrected: a step that
did not load, so it has LOADTIME=., but had an allocation
start time exactly at midnight, will still have ALOCTIME
missing, rather than a midnight time on potentially the
wrong date, because there is no separate criteria to tell
whether that was a midnight or a no-allocate event, but
since LOADTIME is missing in this case, ALOCTIME is far
more likely to have also been missing, and not midnight.
SMF 30 records for STCs for O/MVS a/k/a USS can be valid
but appear inconsistent. Step records for JOB=BPXAS with
both ALOCTIME and LOADTIME missing, but a SELAPSTM of 45
minutes, and with PVTBOT and PVTTOP both zero but with a
small non-zero CPUTCBTM recorded have been observed; the
examples all had PGM=IEFIIC, the initator program name.
Because Change 19.056 reported that the ALOCTIME can be
slightly earlier than INITTIME, and won't be fixed by IBM
a 5-second fuzziness is included in the revision.
Thanks to Randy Shumate, LEXIS-NEXIS, USA.
Change 19.282 Explicitly specifying SYNC59=NO in $%VMXGRMFI invocations
VMXGDUR did not work, printed "uninitialized variable NO " notes,
Jan 30, 2002 and could create incorrect datetime value; even though
SYNC59=NO is the default in VMXGRMFI and works. The user
found that SYNC59=N circumvented this error, that occurs
only if you add SYNC59 to your invocation of
%VMXGRMFI(PDB=...,SYNC59=NO);
The actual error was in the VMXGDUR macro that is called
by %VMXGRMFI, and its handling of SYNC59 is now correct.
Thanks to Helgund Linck, BASF IT Services GmbH, GERMANY.
======Changes thru 19.281 were in MXG 19.10 dated Jan 29, 2002======
Change 19.281 Internal utility macro %VGETOBS is now modified to test
VGETOBS that DDNAME is not blank; instead of failing, it will pop
Jan 29, 2002 a warning message and will set the DDNAME to WORK.
Thanks to Michael Oujesky, MBNA, USA.
Change 19.280 WebLog read fails if the ASCII-to-EBCDIC conversion table
VMACWWW in the ftp/upload program that moved the web log to MVS
Jan 29, 2002 changed left/right ASCII square brackets into 'AD'x/'BD'x
instead of the expected 'BA'x/'BB'x hex values. IBM's
"Yellow Card" does show 'AD'x/'BD'x for EBCDIC square
brackets, and some editors and (we now know!) some ftp
packages also output AD/BD values, but IBM's own ISPF/PDF
editor has always created the BA/BB value that is in MXG
source code on MVS! Now, when MXG code that reads data
records with brackets as delimiters is executed on MVS,
MXG will use the TRANSLATE function to change 'AD'x/'BD'x
into 'BA'x/'BB'x so either delimiter will be recognized.
Thanks to MP Welch, SPRINT, USA.
Change 19.279 MXG now sets option COMPRESS=YES by default, to enable
AUTOEXEC compression of new SAS datasets, to significantly reduce
CONFIGV8 the disk space required for work and PDB libraries:
CONFIGV6 - primarily to eliminate unnecessary out-of-space ABENDs
CONFIGxx that wake up a human at 3 am when BUILDPDB fails,
Jan 28, 2002 - Avoid B37 ABENDS
- Job that now needs two or more work volumes will still
run without changing its JCL to UNIT=(SYSDA,3)
- Big reduction in I/O time and I/O conflicts
- Faster run time: lots on Intel, somewhat on IBM
- Automatic; no human intervention or action on your
part is required; many sites already made this choice
- For MXG under ITSV: no impact; ITSV has always used
COMPRESS=YES default option.
- Reversible; just specify OPTIONS COMPRESS=NO; as your
first statement in the //SYSIN stream.
Those benefits far outweigh the only possible negative:
a moderate increase in CPU time on old CMOS pre-G6 CPUs.
The savings in human intervention alone is worth the very
small increase in CPU time of your MXG jobs.
Benchmarks in Newsletter FORTY justify this change.
-All CONFIGs now have OPTION SOURCE, so that the SAS code
statements in your //SYSIN stream will be printed on the
SAS log (so I can figure out what program you are running
if you have a problem).
Change 19.278 Support for RMDS 2.3 added new RMDSORG=5 RMDSACT=A Report
FORMATS with several new variables in TYPERMDS, and new Sign On
VMACRMDS and Sign Off RMDSORG=4 RMDSACT=U/X events with no new
Jan 28, 2002 data fields. FORMATS was updated for RMDSORG values.
Thanks to Bruno Peeters, Dexia Bank, BELGIUM.
Change 19.277 New examples of Availability Reporting based on TYPE30_V
ANALAVAI a/k/a PDB.SMFINTRV data from type 30 interval records.
Jan 27, 2002
Thanks to Chuck Hopf, MBNA, USA,
Change 19.276 NTSMF object MSEXCHANGE DS has two added fields:
VMACNTSM MSEXCMTA='MSEXCHANGE*MTA'
Jan 27, 2002 ABANRRRT='AB*ANR*PER SEC'
Thanks to Terry Heim, ECOLAB, USA.
Change 19.275 Support for NDM Connect Direct for OS/390 CPU time that
VMACNDM was added to the end of PT, CT and RT statistics record.
Jan 27, 2002 MXG variable NDMCPUTM now exists in those datasets, and
will be non-missing if the extra field is found.
Thanks to John Rivera, (i)Structure, Inc, USA.
Change 19.274 Variables B1HITRAT/B2/B3/B4 in DB2STAT1 dataset were not
VMACDB2 changed when BPHITRAT in DB2STATB was, by Change 17.338.
Jan 26, 2002 Now all Buffer Hit Ratios use that same equation.
Thanks to Helmut Roese, COM Software GmbH, GERMANY.
Change 19.273 IMACEXCL now defines MACRO _CICXC22 for CICS/TS 2.2, if
IMACEXCL your CICS guru has excluded CICSTRAN fields from the SMF
VMAC110 type 110 subtype 1 record.
Jan 24, 2002
Change 19.272 The default stored length of numeric variables is changed
VMACmanymany from 4 bytes for most and 8 bytes for MGBYTES-formatted
Jan 24, 2002 memory variables, to 5 bytes for most, and 5 bytes for
Jan 28, 2002 memory, on EBCDIC, and to 6 bytes for both under ASCII.
Two macro variables were created so you can change either
default back; %LET MXGLEN=4; for most numerics, and with
%LET MXGBYLEN=8; the variables will be their original
stored lengths. MXGLEN=5 ON EBCDIC MXGLEN=6 ON ASCII.
MXG Newsletter FORTY, SAS Techical Note 2 documented the
truncation of up to 255 counts when a large-value 4-byte
binary input field is stored in 4 bytes (floating point).
It was SAS's original choice of using floating point
that made SAS shine in 1972; other programs used
integer values in fixed length fields, and truncated
the high-order digits with large values! Using FP
keeps track of the decimal point, avoiding errors!
All LENGTH DEFAULT=4 are now LENGTH DEFAULT=&MXGLEN,
and all variables with MGBYTES format lengths are now
set with &MXGBYLN instead of ' 8 ' bytes.
Both MXGLEN and MXGBYLN are set by VMXGINIT when MXG
initialized, but can be changed in your //SYSIN code
or in IMACKEEP with %LET MXGLEN=4; %LET MXBYLN=8; to
restore the pre-MXG 19.10 default values.
There is only one exposure when I change variable length:
If you use your own PROC APPEND, you must make certain
that it uses the FORCE operand, which has always been an
MXG reconnendation, so that datasets with dissimilar
attributes can be concatenated.
The only use of PROC APPEND in MXG is optional in the
VMXG2DTE member, which has always specified FORCE.
This change has been under discussion for some time, but
it was DB2 Statistics records, which contain accumulated
counters, that precipitated the change, which was not
needed until now (because DB2 and OS/390 used to crash
before the counters got this large: QB2TGET=301,219,072).
Two adjacent intervals with truncated large values with
a delta less than 255 resulted in a zero delta value.
I considered just identifing the MXG variables that are
accumulated and could get "big" enough now, but that is
both human-intensive and high-exposure-to-missing-one;
the real exposure should never have existed, and the
default length of 5 for a PIB4 has absolutely integrity.
Historical choice of 4 versus 5. In early 70s, sorts
with SYNCSORT failed when lengths other than 4 or 8
were used; SYNCSORT thought only FORTRAN *4 and *8 FP
could exist. Old memories of 3am ABENDS remain strong!
But MXG has had length 3, 5, and 6 for sometime, so I
now deem it completely safe to use!
Datetimestamp variables are still kept in 8 bytes stored
length, as are a few other variables that need the full
resolution possible (like SERVUNIT, which may be used
directly for billing, and there, pennies ARE important!).
With the increased lengths, PROC COMPARE between 19.10
and 19.09 showed many variables are slightly larger now
than before, but the magnitude of the difference is very
small; a 60 minute time value was 0.006 seconds larger.
But PROC COMPARE will not show exact values before and
after MXG 19.10.
The net impact of changing the default stored lengths on
the size of the //WORK space and the //PDB libraries, as
usual, depends! It depends on how many numeric variables
were increased from 4 to 5, and how many were reduced
from 8 to 5, in the datasets that interest you.
But, if you use compression, almost always a wise choice
now, there is NO increase in the disk space required.
Without compression, the storage increase depends on how
many records of what type you keep, but here are a two
examples of what we have measured with MVS defaults:
a. An 842 MB 6/26/30 SMF file created JOBS/STEP/PRINT
datasets; PDB increased from 350MB to 390MB, 11%.
b. A 456 MB all-record SMF file, 30 RMF intervals, full
PDB increased from 316MB to 356MB, 12% increase.
c. Chuck's big 1160 Cyl PDB increased by 30 Cyl, 3%.
There is also a small increase in Virtual Storage needed
for a big job like BUILDPDB. Chuck's Total Memory went
from 69MB to 71MB, but that 2MB increase did cause one
one site to fail with an out-of-memory error:
viloada: autoload failed for module SASXKRN2
because they were limited to 64M by their defaults:
In V6: set by the MEMSIZE=64M default in CONFIGV6.
In V8: Do not have MEMSIZE in CONFIG, use REGION=80M
You should compare the Total Memory used reported on the
SAS log, or in the IEF374I message on the job's SYSLOG,
with your REGION= parm to make sure you have VS left!
-z/OS 1.12 message IEF032I/33I replaced IEF374I/276I.
Thanks to M.J.H. Elbersen, Rabobank, THE NETHERLANDS.
Thanks to F. Nijdam, Rabobank, THE NETHERLANDS.
Change 19.271 This conversion utility, used to convert $HEX FORMATed
UTILCVRT character variables in PDB libraries moved from EBCDIC
Jan 23, 2002 to ASCII platforms (if you move your MXG processing from
MVS to PCs/unix, you'll copy your historical PDBs),
never did work right, but it now works as designed.
CPORT/EXPORT changes all characters variables values,
like '40'x EBCDIC to '20'x ASCII, during download,
but we need the original '40'x value so bit tests work
and so that the CPU Model is '9672'x and not '96B7'x.
The 1994 iteration used $EBCDIC, but Change 19.163 shows
that won't work. Instead, UTILCVRT now uses the $MGAS2EB
mapping ASCII-2-EBCDIC, defined in member FORMATS, and
selects variables with FORMAT=:'$HEX', no longer using
the original and 'not happening' INFORMAT=:'NOTRAN' test.
Of course, this conversion works only if the table that
SAS uses in your country matches that format; some sites
may find it necessary to edit the $MGAS2EB format into
the IMACFMTS tailoring member to match your tran table.
But any MXG datasets that you create under ASCII, reading
SMF,etc, data, are correct and do not need UTILCVRT.
Thanks to Mark Darvodelsky, Royal Sun, Australia
Change 19.270 Two variables that estimate the Average Logically Swapped
VMAC71 frames, CSFRLSAV and ESFRLSAV were found to be negative
Jan 22, 2002 CSTORE=1040MB,CSFRTOAV=920,CSFRFXAV=142==>CSFRLSAV=-4MB
which printed as -42E5. The problem is subtracting two
average values on a system with essentially no logical
swapping, the "zero" is slightly negative. I now test
the calculation, and when negative, the variable is set
to a missing value, so that a real zero value would still
be preserved as a zero value, but these negative values
will just be missing.
Thanks to Kenneth D. Jones, xwave, CANADA.
Change 19.269 The Initiator Number, INITNUMB and Name, INITNAME are now
BUILD005 added to the type 30 subtype 1 (job initiate) record when
BUIL3005 you install the Assembly code in SMF exit IEFU84 that
IEFU84 will move those values into the subtype 1 record.
VMAC30 -This change creates and keeps those two new variables in
Jan 23, 2002 dataset TYPE30_1, and updated BUILDPDB logic to add them
Jun 24, 2004 to the PDB.JOBS dataset as well. The variables will be
missing/blank if the SMF exit has not been installed.
Jun 24, 2004: The IEFU84 exit code member was added by
MXG Change 22.136; the original IEFU83 references were
wrong, as it is IEFU84, not IEFU83, that writes the SMF
30 subtype 1 SMF record. Text was changed from 83 to 84.
-The SMF exit IEFU84 source code is in member IEFU84,
along with notes, so your SYSPROG can see what it does.
The exit moves the initiator number (in binary) into
the first four bytes of PROGRAM (SMF30PGM) name field,
and the initiator name (character) into the second
four bytes of PROGRAM name. SMF30PGM is not populated
at job initiate since PROGRAM doesn't exist until
after the step initiates.
-However, it is your System Programmer's responsibility to
install and test any SMF exit, and thus your company, and
not Merrill Consultants, must take all risk in choosing
to adapt this enhancement SMF exit into your systems:
recognize that the risk with an SMF exit-in-error could
be as bad as a system outage.
I would not provide this example if I did not think it is
safe, and almost every MVS site uses an SMF exit, but you
should read up on SMF exits in the SMF manual before you
convince your friendly SysProg to install the exit.
Remind them that the exit will let you to help them track
which job us which initiator, to help in chasing ABENDS
with overlaid initiators, or in measuring which init is
used how often, etc.
This exit is provided because IBM does not currently
provide this information in their SMF type 30 record. I
have provided them with the tested exit code in the hope
that they will eventually add the fields so that you
don't have to install an SMF exit to get them.
Several MXG-L postings on the subject of initiator number
precipitated this change, but the guys who suggested and
coded the solution, respectively, get the CodeShark cite!
Thanks to Mike Shaw, MVS QuickRef/Chicago Soft, USA.
Change 19.268 Under very strange circumstances: when %LET MACKEEP= was
VMXGDEL used to redefine an old style macro that contained an
VMXGOPTR %VMXGDEL(DDDDDD=dddddd) invocation, the internal call to
VMXGSUM %VMXGOPTR by VMXGDEL generated this error message:
Jan 23, 2002 ERROR 14-12: Invalid option OBS=;; for SAS option OBS.
Jan 26, 2002 VMXGOPTR was needed by VMXGDEL solely because PROC SQL
doesn't execute if OBS=0, but PROC SQL/VTABLE had to run
in VMXGDEL (even when OBS=0 was specified) to populate
macro variables, and OBS=0 is commonly set for testing.
We had used VMXGOPTR to store the old OBS=value, set it
to OBS=MAX (so PROC SQL would execute), and then restore
the original OBS= value, all inside VMXGDEL. But when
we could not diagnose this particular macro error, Rick
Langston at SAS showed us the GETOPTION() function, which
allowed us to remove the PROC SQL/VTABLE in both VMXGDEL
and in VMXGOPTR, with a cleaner, safer approach.
The GETOPTION() function can be used in two ways:
- DATA step solution:
%GLOBAL OBSVALUE;
DATA;CALL SYMPUT("OBSVALUE",GETOPTION("OBS"));RUN;
- pure macro solution:
%MACRO GETOBS;
%GLOBAL OBSVALUE;
%LET OBSVALUE=%SYSFUNC(GETOPTIONS(OBS));
%MEND GETOBS;
%GETOBS;
We chose the pure macro solution in VMXGDEL and VMXGOPTR.
We also changed the design of VMXGOPTR so that it resets
the option value to what it was in the prior VMXGOPTR
execution; the original design kept the value of the
option only from the very first invocation of VMXGOPTR,
and did not recognize if you changed the option between
paired invocations of VMXGOPTR. See comments in VMXGOPTR.
-In QA tests of these VMXGOPTR and VMXGDEL changes, Bruce
set OPTION OBS=10, and found two places inside VMXGSUM
where we had failed to use %VMXGOPTR to protect for user
change of OBS=; VMXGSUM was corrected to now protect.
With OBS=11, this error would not have been corrected!
Thanks to Bruce Widlund, Merrill Consultants, USA.
Thanks to Rick Langston, SAS Institute, USA.
Thanks to Rosalind Howe, IBM Global Services, USA.
======Changes thru 19.267 were in MXG 19.09 dated Jan 21, 2002======
Change 19.267 Support for IBM SMF 119 (TCP/IP) record from z/OS V1R2.0
EXT11901 Communications Server, which replaces the SMF 118 record
EXT11902 from the current IBM TCP/IP product. The data content is
EXT11903 significantly enhanced beyond what is in the current 111,
EXT11905 with many new subtypes and these datasets created:
EXT11906
EXT119A7 SUBTYPE DATASET description
EXT119B7 1 TYP11901 TCP CONNECTION INITIATION
EXT11908 2 TYP11902 TCP CONNECTION TERMINATON
EXT11910 3 TYP11903 FTP CLIENT TRANSFER COMPLETION
EXT11920 5 TYP11905 TCP/IP STATISTICS
EXT11921 6 TYP11906 INTERFACE STATISTICS
EXT11922 7 TYP119A7 SERVER PORT STATISTICS - TCP
EXT11923 7 TYP119B7 SERVER PORT STATISTICS - UDP
EXT11970 8 TYP11908 TCP/IP STACK START/STOP
EXT11972 10 TYP11910 UDP SOCKET CLOSE
FORMATS 20 TYP11920 TN3270 SERVER SNA SESSION INIT
IMAC119 21 TYP11921 TN3270 SERVER SNA SESSION TERM
TYPE119 22 TYP11922 TSO TELNET CLIENT CONNECTION INIT
TYPS119 23 TYP11923 TSO TELNET CLIENT CONNECTION TERM
VMAC119 70 TYP11970 FTP SERVER TRANSFER COMPLETION
VMXGINIT 72 TYP11972 FTP SERVER LOGIN FAILURE
Jan 18, 2002
Change 19.266 Variable RVSTBIN, Bin Number, can be characters, but MXG
VMACEDGR did not know that, and character data caused a non-fatal
Jan 16, 2002 INVALID DATA FOR RVSTBIN message. New variable RVSTBINC
is now Character; RVSTBIN is still numeric, but missing
value now if RVSTBINC has non-numeric characters.
Thanks to Joe Ellis, American Century, USA.
Change 19.265 Dataset STCHSC has zero observations, because STK changed
VMACSTC the length of the record; long ago MXG had to protect for
Jan 16, 2002 records shorter than the then-written 140 bytes, but now
their subtype=7 record is only 120 bytes. Logic revised.
Thanks to Fraser Wong, CitiCorp, USA.
Change 19.264 Cisco Memory Pool variables NRPxxxxx in NPMINNRP were all
FORMATS missing; MXG tested NRPDTYP=1 for Cisco, but the records
VMAC28 contained NRPDTYP=0, so nothing was input. Now, the test
Jan 14, 2002 is for NRPRTYP=2 (Record Type, not Data Type) for the
Jan 16, 2002 Memory Pool data. IBM lists two other NRPRTYP values of
NRPRTYP=1 - CPU and Memory NRPRTYP=3 - Interface
but does not document the contents of the NRP segment for
those (as yet) unsupported values. Variables NRPRTYP and
NRPDTYP are now kept in NPMINNRP so you can see if any of
the new Record Types are in your SMF data; contact MXG
support when you find any, so we can decode them!
New format MG028PT decodes Cisco pool type variables
NRPCPTYP and LNCDCPTY:
1='1 PROCESSOR MEMORY 4='1:FAST MEMORY'
2='1:I/O MEMORY' 5='1:MULTIBUS MEMORY'
3='1:PCI MEMORY'
Jan 24: IBM APAR OW53087 documents that the DTYP=0 in the
NRP and NRT segments is now a reserved field, but that
APAR does not document the RTYP=1 and RTYP=3 data.
Feb 15: IBM will correct OW53087. The xxxRTYP field has
only one value in each record: NRPRTYP==2 NRT=1 NIT=3,
so there are no undocumented segments, and the misleading
documentation will be revised by IBM. See Change 20.003.
Thanks to Howard Swift, HSBC Bank, UK.
Thanks to John Wilmot, HSBC Bank, UK.
Change 19.263 The _SDB2ACC sort macro for DB2ACCT and _BDB2ACC BY list
VMACDB2 were defined as blank, to prevent an accidental sort of
Jan 14, 2002 that potentially large dataset, but since the _SDB2ACC
reference in _SDB2 is commented out, both macros are now
defined, in case you do need to sort and remove dupes
from your DB2ACCT dataset.
Thanks to Rosalind E. Howe, IBM Global Services - South, USA.
Change 19.262 A sample AS/400 report from TYPEQAPM Performance
ANALQAPM Monitor data.
Jan 11, 2002
Thanks to Stephen Hoar, Lloyds TSB, ENGLAND
Change 19.261 Support for IBM AIX Performance Toolbox and Performance
ADOCAIX AIDE for POWER, PTX Version 2, refs: SG24-2011-00.
EXAIXPTX This internal design is extremely robust, and is similar
IMACAIX to the new WebLog support; the list of fields in your
TYPEAIX data is read and used to input the record, so you can
TYPSAIX have different sets of fields defined for different AIX
VMACAIX servers, and the one MXG program will work on all their
VMXGINIT data, transparently.
Jan 15, 2002 This implementation supports the default set of 55 fields
Jan 17, 2002 and the heavy work is done; expansion to keep any of the
other 2000 possible fields is easy, when anyone actually
has actually created those additional fields!
Thanks to Glenn Bowman, Wakefern, USA.
Thanks to Al Sias, Wakefern, USA.
Change 19.260 New optional design will change timezones of all datetime
TIMEBILD variables read from SMF records, based on a table lookup
TIMETABL of SYSTEM/SYSPLEX/datetime-range in which you set the
VMACmanymany offset to be added to all datetime variables.
VMXGTIME This is needed when you have SYSTEMs with different time
Jan 11, 2002 zones, so you can have a common timezone for analysis of
Jan 15, 2002 shared dasd, time of day, etc.
Jan 26, 2002
The table is defined in member TIMETABL (copied into your
USERID.SOURCLIB tailoring library) with a syntax of:
SYSA 01/01/2002 00:00:00 01/31/2999 23:59:59 -21600
to change SYSA datetimes back 6 hours, for a datetime
range from now until infinity.
Even if you have defined your table in member TIMETABL,
nothing happens until you enable time change with this
statement in your //SYSIN stream:
%TIMEBILD;
Invoking %TIMEBILD enables the time changing logic, and
reads the TIMETABL member with the TIMEBILD program that
creates the (temporary) format $MGTMPTM that is the look
up table that is used by %VMXGTIME.
The default table is the TIMETABL member in your SOURCLIB
concatenation, but you can use %TIMEBLD(TIMETABL=XYZ);
to use a different time change table; see its comments.
While the table supports SYSPLEX for selection, SYSPLEX
only exists in some records, so it is really there only
for future selection. Only in the case where you know
that all records you want to change (RMF is the only one
at present) contain SYSPLEX, then and only then could you
have a value for SYSPLEX in the TIMETABL, and you could
not then use that same TIMETABL to select TYPE1415 data
that does not contain a SYSPLEX variable.
To make the actual time change itself, this statement
%VMXGTIME(var1 var2 var3,system,sysplex);
was inserted in the correct place in every VMACxxxx
member that creates datetime variables from SMF records.
All MXG members that process IBM or User SMF records have
been updated, as were most other products that contain a
SYSTEM variable. Some non-SMF products that do not have
a "SYSTEM" field were set aside until a need arises.
VMXGTIME statements were inserted 874 places in 380 MXG
members, listing 1,300 variables that can be changed in
'one felt swoop': update TIMETABL, invoke %TIMEBILD.
See VMXGTIME revisions, GMT support, and corrected CPU
and memory cost measurements in Change 19.286/MXG 19.11.
Change 19.259 The MXGTMNT Tape Mount and Tape Allocation Monitor SMF
ASMTAPES record had the wrong DDNAME if the tape UCB was a 4-digit
VMACTMNT address (the incorrect DDNAME was the last DDNAME in the
JAN 20, 2002 TIOT). The previous logic compared UCB address to get the
the correct DDNAME; this revision compares device numbers
for the UCBs, so this logic will work regardless of
whether the tape UCB address is above or below the 16MB
line, or 3 or 4-digit device address. The revision also
gets the correct DSAB allocation flags for tape mounts.
This revision is "ML-20" of the monitor program. Your
SysProg must re-assemble ASMTAPES and link edit the new
MXGTMNT program that is executed by your MXGTMNT started
task that writes the SMF records, to get the corrected
DDNAME into those SMF records, but you don't need to do
anything to your daily MXG SMF processing jobs; they will
get the correct DDNAME without any change. Only if you
want the new DSABFLAG variable (which is not currently
used by MXG) in your TYPETMNT dataset, will you need to
use the revised VMACTMNT member.
Thanks to Chuck Hopf, MBNA, USA.
Thanks to Jim Sherman, FDC, USA.
Change 19.258 Variable XCPUFLAG is now formatted with new $MGXCMCP
FORMATS format to decode the CPU type of the ftp transfer, and
VMACXCOM the list of old and new values for XCPUFLAG in ADOCXCOM
Jan 9, 2002 was updated with the new values.
Thanks to Tony P. Steward, Post Office, ENGLAND.
Change 19.257 Two examples that select related pairs of SMF records.
ANAL16
ANAL30 Program ANAL16 reads SMF to create TYPE16 (sort) obs for
Jan 8, 2002 selected sorts (in this example, those with concatenated
Jan 15, 2002 SORTIN datasets, because only the first DSNAME is in the
TYPE16 record), and uses those selected TYPE16 obs to
create a table lookup that is then used to re-read SMF
and select only the matching SMF TYPE1415 records; the
site could thus find the dsnames of all SORTIN datasets.
Program ANAL30 reads SMF to create only TYPE30_4 obs for
steps you selected (this example, programs IEBCOPY and
IEBGENER), creates the lookup table, which is then used
to select all of the non-VSAM TYPE1415 and VSAM TYPE64
datasets that were opened by that step.
These examples are easily extended to select other
pairs of data where one event defines a timerange, and
the matching events must occur within that timerange.
I've been meaning to write this example technique for
some time; this specific request precipiated the program!
Thanks to David Goldstein, EDS, AUSTRALIA.
Change 19.256 Variable UMRECRD in dataset DCOLMIGS is now formatted by
FORMATS the new $MGDCORF format to decode the Record Format when
VMACDCOL UMRECRD is printed or displayed. And variable DCERECRD
Jan 4, 2002 in dataset DCOLDSET is now kept, and formatted with the
new $MGDCORF format, also displays the Record Format (and
eliminates the need to combine the same information from
the variables DCDRECFA/B/C/F/J/S/U/V to get it!
Thanks to Wanda Prather, The John Hopkins Applied Physics Lab, USA
Change 19.255 Comments only. If you add NPM TYPE28 processing to your
DIFF28 BUILDPDB, you must either add %INCLUDE SOURCLIB(DIFF28);
Jan 2, 2002 in member EXPDBOUT (to deaccumulate the NPMINPMT data) or
if you want all NPM datasets written to your PDB library,
then you would instead add _S28 in member EXPDBOUT, as
that "product" sort macro sorts (and deaccumulates where
necessary) all datasets created by TYPE28 code.
The DIFF28 member contains only _S028IN7, the "dataset"
sort macro for NPMINPMT, which is included in _S28 macro.
DIFFxxx members exist only for products with accumulated
data fields, and MXG always invokes the DIFFxxx member in
both the TYPExxx and TYPSxxx members, to hopefully assure
that you always have legitimate (i.e., deaccumulated)
values. But now, the DIFF logic is contained in the
"dataset" sort macro, so the DIFFxxx members contain only
the specific datasets that must be deaccumulated.
Thanks to Bruce Hewson, CitiCorp, N.A., SINGAPORE.
Change 19.254 Support for the configuration record (NTCONFIG dataset)
VMACNTSM adds variables DCSDURATM (DCS Interval) and DSCVRYRT
Jan 2, 2002 (Discovery Record Types) - existing fields not decoded,
and variable SUMRYVER (Summary Version Number), to be
added to the record when this data file was created by
NTSMF's summarization program, which is also the flag
that this input file contains summarized data.
Change 19.253 Variable LABEL in TYPETMNT was wrong; the INPUT location
VMACTMNT of TMNTLAB should have been the first byte, with the
Dec 30, 2001 second byte unused.
Thanks to Mike Jacques, Branch Banking & Trust, USA.
Change 19.252 "New" DFSMS/rmm variables include Creating Program Name,
VMACEDGR Total Block Count across all volumes, and "Last Used"
Dec 30, 2001 Program/Job/Step/DD/DEVNR are now INPUT and kept in
TYPEEDGR. They were added by IBM by OW40710 in 1999.
Thanks to Joe Lodyga, Whirlpool Corporation, USA.
Change 19.251 Use of long-variable-names was not fully supported in
VMXGSUM VMXGSUM; names could be truncated to eight bytes. Since
VMXGINIT MXG does not use long variable names, this only impacted
Dec 27, 2001 use of VMXGSUM with long variable names in SAS V8.
Dec 30, 2001 To accomplish this change, TEMPnn libnames will be built
Jan 4, 2002 with ENGINE=V8SEQ under V8, and ENGINE=V6SEQ under V6,
Jan 20, 2002 and TEMPnENG is set blank if TEMPnn is not used.
Corrected logic if KEEPALL=NO was used.
-In member VMXGINIT, new global macro variable MXGLEN
defaults to 4, and it is used by VMXGSUM (instead of the
hardcoded 4) to set the length of variables on the output
side of VMXGSUM, for those rare cases where you need to
increase kept length, by using %LET MXGLEN=8; before
your %VMXGSUM invocation. NO LONGER TRUE.
PARAGRAPH WAS CHANGED BY CHANGE 19.272 in JANUARY.
-PROC SQL's scope was limited to look only at LIBNAMEs;
under very unlikely circumstances, it could read all SAS
datasets on a multi-volume tape data library; nothing
failed, but the job took longer than expected.
Thanks to Paul Gillis, Pacific Systems Management Pty, AUSTRALIA.
Change 19.250 The Logically Swapped ESTORE in variable ESFRLSAV was
VMAC71 wrong; ESFRHSAV was being added instead of subtracted.
Dec 27, 2001 ESFRLSAV=ESTORE-(ESFRTOAV+ESFRHSAV); is now used.
Thanks to Peter Webber, CIS, US.
Change 19.249 Major revision in support for Web Logs.
EXWWWCOO The original TYPEWWW was completely restructured and now
EXWWWIIS creates multiple datasets, and more are likely over time.
EXWWWLOG -Multiple web log data formats are automatically detected,
EXWWWREF and multiple "Log Event" datasets will be created where
EXWWWURQ the contents of the logs are sufficiently different. An
IMACWWW observation in the "Log Event" dataset is created for
VMACWWW each web log record that is not filtered. At present:
VMXGINIT
TYPEWWW Dataset Description of Web Log
TYPSWWW WWWLOG Netscape/I-planet,Common Log Format,Websphere
Jan 7, 2002 WWWIIS Microsoft IIS (old and new versions)
-"Multiple segment" datasets are created for content items
when there can be more than one item in a log event. The
individual segments can be mapped back to their parent
log event observation using the ZTIME/WEBSEQNR variables.
At present, these multiple segments are decoded:
Dataset Description of contents
WWWCOOKE Cookies, COOKNAME and COOKVALUE pairs
WWWREFER Referer text, may be revised.
WWWURQRY URI Query, URIQNAME, URIQVALU pairs.
-By default, MXG Sorts invoke the NODUP option to remove
all duplicates, but duplicate log events occur (refresh
same page in same second), and to allow you to override
and keep duplicates, macro variable &SASNODUP is defined
in VMXGINIT (Default is NODUP) and it is used in VMACWWW
so you can supress duplicate removal in web logs by
using %LET SASNODUP=; in your //SYSIN
-There is a lot of logic in VMACWWW that will eventually
be documented in ADOCWWW, and there will be new exits to
allow filtering of what records are kept during INPUT, as
web log data can be voluminous. Current notes:
Variable HOST is LOWERCASED, so that all of the casing
spelling variants (WWW.MXG.COM, www.mxg.com) will be
combined.
Variable VISITOR is created from cookies if either the
SITESERVER=ID= or ASPSESSIONID cookie name (COOKNAME)
is found, to track the same user thru your servers. If
neither cookie is found, a VISITOR variable is created
as TRIM(HOST)!!TRIM(CLIENTIP)!!TRIM(USERNAME). Note the
USERNAME exists only for URLs in the authenticated
realm
For web logs with self-contained documentation of their
contents (currently, the IIS "#FIELDS" record and the
Netscape "format=" record), this new architecture reads
those header records to determine what data fields are in
your data records, and in what order, to automatically
process logs with excluded, skipped, optional fields,
and with those fields in any order, transparently!
These powerful algorithms will be easy to use to support
other new data that contain self-documenting headers.
While this support is fully usable now, I anticipate the
expansion of analysis and reporting of this clickstream
data. Unfortunately, at present, there is no way to
correlate the computer resources that are associated with
these web activities. But this is ongoing research, and
additional enhancements can be expected.
Thanks to Tom Gray, SPRINT, USA.
Change 19.248 Change 19.187 was incomplete; an ID statement referenced
ASUMNTIN non existent variables and was removed.
Dec 21, 2001
Thanks to Jim Quigley, ConEd, USA.
======Changes thru 19.247 were in MXG 19.08 dated Dec 20, 2001======
Change 19.247 Some ANALDB2R reports failed if all DB2 datasets had zero
ANALDB2R observations. The original design of %VGETOBS macro did
VGETOBS did not differentiate a non-existent dataset from one
VMXGINIT with zero observations. This enhancement to %VGETOBS
Dec 19, 2001 creates new GLOBALed macro variable VGETDSN that will be
blank if the dataset does not exist in the DDNAME, or
will contain the data set name if it exists. If the
dataset is found, an MXGNOTE with name and number of
observations is printed on the log; if not, an MXGWARN is
printed that the requested dataset was not found.
The invocations of %VGETOBS in ANALDB2R were then revised
to exploit the enhancement.
Change 19.246 Sophisticated option for VMXGSUM when two output summary
ADOCSUM datasets at different summary levels are to be created.
VMXGSUM MXG's normal HouseKeeping deletes the MXGSUMx temporary
Dec 18, 2001 datasets, to make disk space available, but with the new
HOUSKEEP=NO specified in your first %VMXGSUM invocation,
no housekeeping is done, so a second %VMXGSUM can then
specify NOSORT=YES to bypass the PROC SORT, and since the
first step (when needed) will be a VIEW, there is no I/O
associated with the output side of the first data step,
which is then read directly by the PROC MEANS.
You have to be very sure of what you are doing; if the
sort order is not correct, the second %VMXGSUM invocation
will fail. Examples of using these options are given in
member ADOCSUM.
Thanks to Chuck Hopf, MBNA, USA.
Change 19.245 Support for APAR OW49808 to RMF Type 70 Subtype 2 CRYPTO
EXTY70X2 record (new in z/OS 1.2, Change 19.176) enhances the data
EXTY70Y2 measures and there are now three datasets created from
IMAC7072 the 70-2 record:
VMAC7072 DDDDDD Dataset Description
VMXGINIT TY7002 TYPE7002 RMF PCI CRYPTO COPROCESSOR PCICC
Dec 18, 2001 TY70X2 TYPE70X2 RMF PCI CRYPTO ACCELERATOR PCICA
TY70Y2 TYPE70Y2 RMF CRYPTO COPROCESSOR FACILITY CCF
These data will become important as they will be used by
the Secure Sockets Layer associated with Websphere and
similar secured systems.
These data have not yet been validated with test records.
Change 19.244 Support for IDMS Log Statistics Records decodes LGRTYPE
EXIDML01- 'F6'x and '76'x record's into eleven datasets, one for
EXIDML11 each STLTYPE (01x-11x), but only the STLTYPE=02 TASK
FORMATS records are fully decoded (in dataset IDMLOG02). Records
TYPEIDML with STLTYPE=01 (SYSTEM) have three non-zero fields, but
VMACIDML do not match their DSECT descriptions, and all other STL
VMXGINIT TYPEs in the test file have no data fields.
Thanks to Hugh O'Neill, Dow Jones, USA.
Change 19.244 This Windows Disk Space Used utility read the output of
UDSKCONT DIR commands to report disk space by direcory and file.
Dec 13, 2001 It now supports Windows NT/2000/XP, which has a different
output format for the DIR command, but you have to tell
it which format you want to read. I use this to find out
why I've run out of space on a PC disk.
Change 19.243 IBM declared field QBACSWU to be 'Reserved' in DB2 6.1,
VMACDB2 but the field appears to continue to contain QBACSWU, so
Dec 13, 2001 the QBACRSVD field is now input into QBACSWU variable,
but please validate and use it with caution.
Thanks to Charles Harbour, John Deere, USA.
Change 19.242 For users of TYPEIMS7 and VMACIMS, variables IMSGTEXT and
VMACIMS OMSGTEXT in IMS01/IMS03 datasets were blank with IMS 6.1
Dec 12, 2001 and wrong with 5.1 that are now correctly input in this
almost-archaic member. Some unnecessary/confusing tests
IF _IMSVERS were removed for readability. Several new
variables were INPUT but not kept; MSGRACUS (RACF User
ID, also "LogonID"), MSGSAFNM, MSGUSIDI, and MSGWLMSC are
now kept in the 01/03 datasets.
The recommended MXG IMS Log processing is in the members
JCLIMSLn, ASMIMSLn, and TYPEIMSA/TYPEIMSB, and they are
not impacted by this change. This site had reports that
were based on the raw IMSnn datasets created by VMACIMS,
so it was updated to preserve their reports.
Thanks to James Seitz, Oklahoma Department of Human Services, USA.
Thanks to Ken Sharpe, Oklahoma Department of Human Services, USA.
Change 19.241 MXG enhancement for Batch Pipes adds these variables
VMAC91 DDNAME JESNR JOB READTIME STEPNAME STEPNR to the
Dec 11, 2001 TYPE91nn datasets for subtypes 11,12,13, and 15, and
increases the number of system names/flags variables
SMF91XYn and SMF91XFn from eight to sixteen to support
sixteen systems in a sysplex.
Thanks to Michael Oujesky, MBNA, USA.
Change 19.240 MXG 19.04-19.07 only. Variables PCHANBY and PNCHANBY can
VMAC73 be always zero in error. Change 19.176 mis-located the
Dec 10, 2001 initialization of those variables for SMF73CMG=0 records.
Thanks to John Gebert, Office Depot, USA.
Change 19.239 Several Coupling Facility variables in TYPE74CF/TYPE74ST:
VMAC74 R744SASQ/R744SSSQ/R744SQSQ/R744SDSQ/R744FCSQ/R744FSQU
Dec 6, 2001 were all sums of squares that are now divided by 1000000.
Variables R744FTIM/R744FCTM were incorrectly divided by
4096. Our test data had all zeros, so these incorrect
conversions were not previously caught.
Thanks to Bill Cool, EDS Federal Government, USA.
Change 19.238 Variable DEVNR is now created in dataset TYPE42VL as a
VMAC42 numeric field with format HEX4; variable SMF42DEV in that
Dec 6, 2001 dataset is a 4-byte character device number in hex, but
Dec 18, 2001 DEVNR is numeric in all other datasets, and is needed to
merge TYPE42VL with other data.
Dec 18: SMF42DEV input changed to $CHAR and logic to
INPUT the DEVNR variable was revised to work.
Thanks to Don Deese, (CPExpert), Computer Management Sciences, USA
Change 19.237 Variable LOCLINFO in PDB.STEPS was incorrect. Its value
BUILD005 in a step record was being overlaid with LOCLINFO from
BUIL3005 the other job-level records, so if you put different data
Dec 4, 2001 in the STEP records, it was lost. Now, the step value
is preserved for each step.
Thanks to Diane Eppestine, Southwestern Bell, USA
Change 19.236 Values for SMF73CPD (Channel Path Description), decoded
FORMATS by MXG Format MG073CD, were updated for new '14'x,'15'x,
Nov 26, 2001 values for HSSI and Ethernet Open System Adapter Channel.
Change 19.235 Observations were created in new dataset MQMCFMGR only by
VMAC115 accident; the test IF SM1152O2 GT 0 THEN DO; should have
Nov 26, 2001 been coded as IF SM1152OC GT 0 THEN DO;
Thanks to Martin Lee, Safeway Stores PLC, ENGLAND.
Change 19.234 MXG Software (all versions) supports the euro symbol, as
none there are no MXG variables that contain financial values
Nov 23, 2001 in euros, dollars, or any other units of currency.
Of course, you can always create financial variables
in your reporting and billing programs, and there, you
can use the SAS FORMAT EUROw.d, which complies with
the European Monitary Union rules and displays an "E"
as the euro symbol, without any special characters.
But be careful with EUROw.d (and DOLLARw.d) formats;
you must not underspecify the field width w, or SAS
will truncate from the left and your euro/dollar sign
will not be printed (as shown in SAS documentation!):
With a value of x= E1254.71 euros
using format will print as
EURO6.0 E1,255
EURO5.0 1,255
EURO5.1 1255
EURO6.1 1254.7
Thanks to K. Strange Bruun, IBM Denmark A/S, DENMARK.
Change 19.233 For NT Trending, default DDNAMES could not be changed, as
BLDNTPDB the user tailoring could be overwritten by TRND defaults.
TRNDNTIN Now, user tailoring of DDnames works as expected.
TRNDNTLD
Nov 23, 2001
Thanks to Greg Jackson, National Life Insurance of Vermont, USA.
Change 19.232 The new IHDRTMO2 exit that was supposedly added by Change
IHDRTMO2 Change 19.154 was created but not included in VMACTMO2.
VMACTIMS This change adds the %INCLUDE of IHDRTMO2 in VMACTMO2; it
VMACTMO2 is called after the Transaction Header or Interval Header
VMACTMV2 has been INPUT. Comments in IHDRTMO2 were updated and
Nov 20, 2001 now include an examples of tailoring, either by EDIT of
Nov 23, 2001 the IHDRTMO2 member, or by using the %LET MACTMOH= in
your //SYSIN input.
-Similarly, the INCLUDE of IHDRTIMS and IHDRTMV2 have been
added to their appropriate VMAC member.
Thanks to Jerry Urbaniak, Acxiom CDC, USA.
Change 19.231 Sample MQ Series reports were updated. Originally, the
ANAL115 ANAL115 member contained an MXG "program" that was read
Nov 20, 2001 with a %INCLUDE, and then executed with the syntax:
%INCLUDE SOURCLIB(ANAL115);
Now, the ANAL115 member defines %MACRO ANAL115;, so your
%INCLUDE statement is now replaced with:
%ANAL115;
to execute with all defaults, or with
%ANAL115(PDB=SMF,REPORTS=ALL);
if you want to change the input to use SMF data, select
reports, etc. See the complete list of arguments in the
comments in the ANAL115 member. The member was changed
into a %MACRO so that we could provide you with arguments
to tailor the execution and provide report selection:
- The %INCLUDE(ANAL115); statement now would not fail,
but it would only read the member and compile the
%ANAL115 macro, but it would not "do" anything, since
it does not invoke the actual %MACRO name.
- You don't need the %INCLUDE(ANAL115); statement now,
because when SAS sees that %ANAL115; statement in your
//SYSIN (because MXG set options SASAUTOS=SOURCLIB and
MAUTOSOURCE in its CONFIGV8/AUTOEXEC), SAS will read,
compile, and execute the %MACRO defined in ANAL115.
There are extensive IBM notes about measuring/monitoring
MQ series in the comments of this report member.
Thanks to Bruce Widlund, Merrill Consultants, USA.
Change 19.230 -Using %LET MACKEEP= to tailor the DCOLLECT part of the
DAILYDSN DAILYDSN program (used in the JCLDAYDS example to read
VMXGINIT DCOLLECT and TMS data for "Daily Dataset Accounting")
Nov 19, 2001 did not work. The second execution of %VMXGINIT inside
DAILYDSN was re-executing the %LET MACKEEP=; statement to
set the MACKEEP macro variable back to blank. Further
examination of the %GLOBAL statement documentation showed
A macro variable created with a %GLOBAL statement has
null value until you assign it some other value. If a
global macro variable already exists and you specify
that variable in a %GLOBAL statement, the existing
value remains unchanged.
so there is no need to initialize macro variables to null
value if the variables is in a %GLOBAL statement, and the
removal of those %LET xxxxxx=.; (null value) statements
permits multiple execution of %VMXGINIT.
-However, the purpose of the user's MACKEEP= tailoring was
to make DAILYDSN only create the four DCOLLECT datasets
that are used in DAILYDSN, so that member now has an
example of a %LET MACKEEP= statement that only keeps the
four DCOLxxxx dataset that are used by DAILYDSN:
DCOLDSET DCOLVOLS DCOLMIGS DCOLBKUP
Thanks to Joseph Stoll, University of Wisconsin Hospital, USA.
Change 19.229 Support for RSD Folders ASTRE Auditing User SMF Record
EXRSDAUD creates new RSDAUDIT dataset with member TYPERSDA, and
FORMATS new formats MGRSDAU and $MGRSDFO. One set of fields,
IMACRSDA Folder Type is not documented, but will eventually be
TYPERSDA decoded with another format.
TYPSRSDA Note that the other RSD Folder SMF records are supported
VMACRSDA in TYPERSDF.
VMXGINIT The tested version is RSD/Folders V 4.1.
Nov 17, 2001
Thanks to Christa Neven, KBC Bank, BELGIUM.
Change 19.228 MXG 19.01-19.07 only, execution under ITSV, received this
VMACSYNC ERROR: VARIABLE UNIT1 HAS BEEN DEFINED AS BOTH CHARACTER
Nov 16, 2001 AND NUMERIC, because MXG 19.01 unintentionally changed
those variables from CHAR to NUM, but ITSV's dictionary
(righteously!) expected them to still be character.
This change creates variables UNIT0-UNIT99 as CHAR $4
variables, as they were in MXG 18.18, but it also creates
new numeric variables DEVNR0-DEVNR99, that should be used
instead of UNITn variables, so that your devices are in
numeric order: 181x..18Ax..A18x..B41x... If you use the
character unit address, you get A81x..B41x..18Ax..181x..
Variables DEVNR0-DEVNR99 are FORMATed HEX4, so they
print the same value as the UNITn variables.
Thanks to Bob Funk, Progressive Insurance, USA
Change 19.227 Fields added to HSM User SMF (usually 240/241) last year,
VMACHSM compatibly, in what were reserved bytes. These new MXG
Nov 15, 2001 variables now exist in HSMFSRST dataset:
FSRFLG3 ='FSRFLG3*REQUEST*FLAGS'
FSRTIMS2='TIME WHEN*PREPROCESSING*COMPLETED'
FSRTIMM1='TIME WHEN*DATA MOVEMENT*STARTED'
FSRTIMM2='TIME WHEN*DATA MOVEMENT*COMPLETED'
FSRTIME1='TIME WHEN*HOST PROCESSNG*STARTED'
FSRHOST ='HOST*IDENTIFIER'
Those new timestamps for phases of HSM may be useful.
I chose to keep only the one-byte flag variable FSRFLG3,
to save DASD space, but these tests can be used for the
bit-level-field-names, some of which may be important:
FSRFLG3='1.......'B FSRFVINI RECOVERY REQUEST
FSRFLG3='.1......'B FSRVXPL1 DS EXPIRED FROM ML1
FSRFLG3='..1.....'B FSRFXPL2 DS EXPIRED FROM ML2
FSRFLG3='...1....'B FSRFEXBV BACKUP VER BEING EXPIRED
FSRFLG3='....1...'B FSRFBKTP BACKUP VER DELTD IS TAPE
FSRFLG3='.....1..'B FSRFEXDT DELETED BY EXPDT/MGTCL
FSRFLG3='......1.'B FSRRECON MIGRATE DUE TO RECONNECT
Thanks to Judith Bruner, Wal-Mart, USA.
Change 19.226 There was a missing end-of-comment */ in this member.
ASUMTCPT
Nov 15, 2001
Thanks to Dan Riggs, Wachovia, USA.
Change 19.225 Support for Landmark's The Monitor for TCP/IP v1.1 has
EXTMTCIA been tested with actual data for all subtypes! These new
EXTMTCIC datasets are created from the dumped TMON records:
EXTMTCIE dddddd dataset description
EXTMTCIF TMTCIA TMTCIA TMON TCP/IP IA API TERM
EXTMTCIG TMTCIC TMTCIC TMON TCP/IP IC TCP GROUP
EXTMTCIL TMTCIE TMTCIE TMON TCP/IP IE EXCEPTION
EXTMTCIM TMTCIF TMTCIF TMON TCP/IP IF INTERFACE/ICMP
EXTMTCMO TMTCIG TMTCIG TMON TCP/IP IG PING RESULTS
EXTMTCIO TMTCIL TMTCIL TMON TCP/IP IL TELNET EVENT
EXTMTCOD TMTCIM TMTCIM TMON TCP/IP IM CSM INTERVAL
EXTMTCIP TMTCMO TMTCIMO TMON TCP/IP IM CSM OWNER
EXTMTCPA TMTCIO TMTCIO TMON TCP/IP IO CISCO
EXTMTCPR TMTCOD TMTCIOD TMON TCP/IP IO CISCO DEVICE
EXTMTCPT TMTCIP TMTCIP TMON TCP/IP IP IP GROUP
EXTMTCIR TMTCPA TMTCIPA TMON TCP/IP IPA IP ADDRESS
EXTMTCIS TMTCPR TMTCIPR TMON TCP/IP IPR IP ROUTING
EXTMTCIU TMTCPT TMTCIPT TMON TCP/IP IPT IP TRANSLATE
EXTMTCIZ TMTCIR TMTCIR TMON TCP/IP IR TRACE ROUTE
IHDRTMTC TMTCIS TMTCIS TMON TCP/IP IS SYSTEM GROUP
IMACTMTC TMTCIU TMTCIU TMON TCP/IP IU UDP GROUP
TYPETMTC TMTCIZ TMTCIZ TMON TCP/IP IZ FTP EVENT
TYPSTMTC Invalid packed dates in IASDAT, IZSDAT, and ILSDAT have
VMACTMTC '101271F0'x instead of '0101271F', causing missing values
VMXGINIT values, and IZFTPTY is sometimes shifted right, but there
Nov 16, 2001 is lots of new data here, especially from SNMP v1/v2 MIB.
Thanks to Julie Haines, Direct Line, ENGLAND.
Thanks to Pete Gain, SAS Software PTY, ENGLAND.
Change 19.224 Support for CICS/TS 2.2 Statistics Record was enhanced
EXCICDSP with new datasets CICDSPOO, CICS Dispatcher TCB Pools to
IMACCICS record the number of TCBs attached, allocated, etc., for
VMAC110 the Open, JVM and HP TCB pools. Now understanding that
VMXGCICI CICS TCB number is no longer valid to identify what is in
VMXGINIT which TCB, the text of Change 19.204 and ADOC110 were
Nov 13, 2001 revised to show that the TCB "Name", rather than number
Nov 19, 2001 determines what is stored in the dsNxxxxx set of CICS TCB
variables: trust the variable's Label, not its number!
-The VMXGCICI member was updated to bring in the twelfth
and thirteenth TCBS
-New (and undocumented) "D2" TCB is now recognized.
The STID=114 EJR and STID=66 STG segments have new fields
added to their existing datasets.
Change 19.223 Invoking _N108 to null out all TYPE108x datasets failed
VMAC108 because the MACRO _N108 statements were wrong - each was
Nov 12, 2001 of the subsequent lines were missing the word "MACRO".
Thanks to Martin Lee, Safeway Stores PLC, ENGLAND.
Change 19.222 -%ANALDB2R WARNING: ARGUMENT 2 TO MACRO FUNCTION and then
ANALDB2R ERROR: FILE WORK.DB2ACCTP.DATA DOES NOT EXIST, if there
Nov 14, 2001 are no observations in DB2ACCTP, but observations were in
Nov 22, 2001 both DB2ACCT and ASUMDB2A, causing USEACCT to be blank,
Nov 26, 2001 causing SKIPPAK to be wrong, which caused the incorrect
open. The logic to set USEACCT and SKIPPAK and the code
that uses then was corrected and made consistent for both
PMACCT01 and PMACCT03 reports.
-%ANALDB2R failed when PMACC01 and PMACC03 were requested,
with ERROR: FILE WORK.ASUMDB2A.DATA DOES NOT EXIST,
because the OPTIONS NODSNFERR NOVNFERR statement was not
executed the second time (after the PMACC01 report was
created, it reset those options to DSNFERR and VNFERR).
Adding the OPTIONS statement inside %MACRO PMACC01 fixed
that error, but uncovered an extra END; statement in the
PMACC03 report, that had to be conditionally generated.
-With PDB=SMF and both PMACC01 and PMACC03 requested, no
package detail was printed, but UNINITIALIZED VARIABLE
log messages were, because the VMXGSUM output of PMACC01
was written to OUTDATA=DB2ACCTP, but that overwrote the
original DB2ACCTP data, and then that summary was used as
the input to PMACC03. Using a different dataset name in
the OUTDATA= statement (and in subsequent references) was
required for both DB2ACCTP and DB2ACCTB, and now they are
OUTDATA=OUTACCTP and OUTDATA=OUTACCTB.
-A conditional execution of a PUT statement was inserted
in the Package Detail.
-Statements were indented to make the logic more obvious.
-Nov 26: Eliminated UNINITIALIZED DATETIME varialbe notes,
two CPUTIME headings became one ELAPSED and one CPUTIME,
and when there's more than a page of package detail, the
headings on package section now propagate to the first
heading lines on the second and following pages.
Thanks to Simone Niemczura, Harleysville Insurance Companies, USA.
Thanks to Andrew Taylor, AXA Shared Servicess Limited, ENGLAND.
Change 19.221 Enhanced support for NPM subtype 18/19x (Exception and
EX028EX1 Resolution events) are now output in eight new datasets
EX028EX2 based on NPMTYPE (LSCDRTYP) value, with detail sets of
EX028EX3 variables from each Volume/AOFTYPE segment. This will
EX028EX4 cause zero observations in datasets NPMEVNET & NPMERNET,
EX028EX5 which are replaced by the new datasets:
EX028EX6 NPMTYPE Exit Dataset Event Description
EX028EX7 24x EX1 NPMEXXPU X.25 (NPSI/XI/3746) PU
EX028EX8 26x EX2 NPMEXXVC X.25 (NPSI/3746) VC
VMAC28 27x,47x EX3 NPMEXNEO Generic NEO link/PU
VMXGINIT 28x,4Cx EX4 NPMEXCSL ODLC LAN
Nov 12, 2001 2Ax,2Bx EX5 NPMEXFRP Frame Relay
49x,4Ax " "
44x,45x EX6 NPMEXTRI NTRI logical/physical link
46x EX7 NPMEXXLK X.25 (NPSI/XI/3746) link
4Bxc EX8 NPMEXETH Ethernet LAN physical link
These Event/Resolution records were not reported as being
a problem, but in validating NPM 2.6 records, INVALID
DATA FOR MDY FUNCTION with NPMTYPE=28x exposed the need
to create a separate dataset for each of these events.
-Variable BASTIME now existsin NPMSUBTY 51x & 62x records,
so the test for NPMSUBTY added by Change 7.237 (!) is now
removed; only BASNCPDT and BASNCPTM GT 0 are now tested.
-Labels for CONTENT*FLAG variables were made consistent
and all are now formatted $HEX2.
-All Byte-Measurement variables are now formatted MGBYTES
so that their values will be printted with K/M/G suffix.
-Four variables previously in Kilo-Bytes are now converted
to contain bytes, and formatted with MGBYTES:
LLBVP1BB LLBVP1NB LLBVP2BB LLBVP2NB
-FORMAT statements were sorted and reorganized.
Thanks to William Sherriff, IBM Global Services, USA.
Change 19.220 SMF type 42 subtype 6 INVALID DATA FOR READTIME message
VMAC42 and hex dump were caused by blanks for both JOB name and
Nov 9, 2001 for READTIME, in a record from (old) DFSMS/MVS 3.1 for a
started task that may have been cancelled/forced. This
change supresses the message and hex dump by inserting
double-question-mark-modifier, but with or without this
change, READTIME is missing in the TYPE42DS dataset for
a record with blanks instead of a time and date.
The blanks could also have been caused by user SMF exits.
Thanks to Jesse Gonzales, The Gap, USA.
Change 19.219 Documentation only. Comments added to identify which of
VMXGUOW the "_K" macros are to be used for what. There is a pair
Nov 9, 2001 of "_Kxxxxxx" macros that can be tailored to control what
additional variables are kept from CICSTRAN, DB2ACCT, and
MQACCT. One is for numeric variables that are summed and
kept in PDB.ASUMUOW from each input dataset:
_KUOWCIC CICSTRAN
_KUOWDB2 DB2ACCT
_KUOWMQC MQACCT
and one is for character variables that are added to the
ID statement and are kept in PDB.ASUMUOW:
_KUOWIDC CICSTRAN
_KUOWIDD DB2ACCT
_KUOWIDM MQACCT
Thanks to Kenneth Johnsonk, Vanguard, USA.
======Changes thru 19.218 were in MXG 19.07 dated Nov 3, 2001======
Change 19.218 Revision to RMF III ASMRMFV program, additional revisions
ADOCRMFV to VMACRMFV will follow. Extensive documentation of the
ASMRMFV changes in ADOCRMFV.
Nov 3, 2001
Thanks to Jerry Urbaniak, Acxiom CDC, USA.
Change 19.217 CPUTYPE='2064'x with Spare CPUs still made PDB.ASUM70PR
VMAC7072 have bad values for LPnDUR and LPnPERCENTAGES. The real
Nov 3, 2001 source of the problem was that the TYPE70PR dataset had
an observation for each spare CPU, with non-zero DURATM,
and the LPARDUR included the DURATION of all the spares.
I considered deleting the spares in the ASUM70PR logic,
but believe many MXG users do their own sums of TYPE70PR,
so it makes more sense to only output observations in the
TYPE70PR dataset for 2064 CPUS for LPARNAME=PHYSICAL (as
it has SMF70ONT=0), or if SMF70CIN NE 'CP' (so ICFs and
anything else will be output) or if SMF70ONT NE 0 (so the
2064s with the APAR will have non-zero ONT for non-spares
and 2064s without the ONT APAR will have missing ONT and
will also be output.
If you have LPnDED='Y' or LPnWAIT='Y' (Dedicated CPUs or
Wait-Complete), then the only PDB.ASUM70PR observations
that have non-missing values for those LPARs will be the
ASUM70PR observation written on the Dedicated LPAR, i.e.,
those with SYSTEM=LPnNAME. For Dedicated/Wait Complete
CPUs, the PDB.ASUMCEC dataset was invented to solve this
problem; read the extensive discussion in the text of the
Change 17.203 that added the creation of PDB.ASUMCEC into
the ASUM70PR logic, and see member ACHAP10 for general
PR/SM CPU measurement discussion.
OBSERVATION COUNT CHANGE: TYPE70PR fewer obs.
Thanks to Bruce Widlund, Merrill Consultants, USA.
Thanks to Joseph Rannazzisi, Salomon Smith Barney, USA.
Thanks to Jim Gilbert, EDS-Sabre, USA.
Change 19.216 MXG ASCII Execution only: R723MSCF in TYPE72GO is wrong,
VMAC7072 but not when MXG runs under MVS. It was INPUT with the
VMAC71 $EBCDIC format, but it is a character-variable-containing
VMAC73 hex-values, formatted with $HEX, and all such variables
VMAC74 MUST be INPUT with $CHAR informat to preserve the bits
VMAC75 and for MXG to be portable across platforms.
VMAC76 Under MVS, $EBCDIC and $CHAR are identical, but on ASCII
VMAC77 platforms, the INPUT must be with $CHAR to preserve the
VMAC78 original bits; if you input with $EBCDIC under ASCII, as
VMAC79 designed, SAS converts '40'x to '20'x for blanks, etc.,
VMAC102 for each byte in the field. Under ASCII, $CHAR stores
TYPEDOS the unmodified hex value in the character variable (and
VMAC102 so does $VARYING).
VMAC110 Don's discovery precipitated an audit of old MXG source
VMAC116 for other cases of incorrect informat: all variables
VMAC22 listed below are now correctly INPUT with $CHAR and
VMAC42 formatted with $HEX; none are important flags, some are
VMAC6 not even kept, many are reserved fields, but a few are
VMAC6156 used to create other (apparently-not-very-important) flag
variables, and since no one else had caught this failure
in MXG transparency across platforms, I feel very lucky!
VMAC80A I should have done this long ago.
VMAC84
VMAC90A VMAC7072: R723MSCF TEMPIOML SMF70PRF SMF70PRF
VMACACF2 SMF72RV5 SMF70V
VMACACHE VMAC71: TEMPIOML SMF71PRF
VMACAPAF VMAC73: TEMPIOML SMF73PRF
VMACAPAF VMAC74: R747PNUM R747PADR R747CNUM R747CADR
VMACBETA VMAC75: TEMPIOML SMF75PRF SMF75RV3 SMF75RVA
VMACCTLG VMAC76: TEMPIOML SMF76PRF
VMACDB2 VMAC77: TEMPIOML SMF77PRF
VMACEREP VMAC78: TEMPIOML SMF78PRF
VMACFTP VMAC79: TEMPIOML SMF79PRF SMF79RV2 R79FRCVT R79RV1
VMACIDMJ R79RSV R79USER R796FLG R797FLG R797RES
VMACIDMS R798FL1 R799RVO R799CNF R799RV0 R799CNF
VMACIMS R79BFL2 R79BRESV
VMACIMSA TYPEDOS: SUFFIX
VMACMVCI VMAC102: QW0011PS QW0015C2 QW0021KD QW0021KP QW0021K1
VMACOPC QW0021K2 QW0087AD QWP1SMRC QWP3WLST QWP4DATE
VMACSNAP QWP4DATE QW0170FC QW0177CT
VMACSPMS VMAC110: TRANPRI TCLASS TRANPRI TRANPRI TRANPRI
VMACSYNC TRANPRI TRANPRI TRANPRI TCLASS
VMACTMV2 VMAC116: WTIDUOWI WQCORREL
VMACTMVS VMAC22: CPUTYPE
ZMACxxxx VMAC42: SMF42DEV
Nov 1, 2001 VMAC6: SMF6OTOK
VMAC6156: RELFLAG
VMAC7072: R723MSCF
VMAC79: R79FRCVT
VMAC80A: CLASOPT1
VMAC84: SMF84FL1
VMAC90A: SMF9031U
VMACACF2: ACVMFMF
VMACACHE: DEVMAP1 DEVMAP2 CSDEV DVID
VMACAPAF: CPUMAP
VMACAPAF: IOPMAP
VMACBETA: BETAALVL
VMACCTLG: RELFLAG
VMACDB2: QBGBGR1 QBGBGR2
VMACERE: SYRELLVL
VMACFTP: DVGDRETC DVGDREAC
VMACIDMJ: DBKOWNER DBKOWNER
VMACIDMS: DBKOWNER DBKOWNER
VMACIMS: SYNCDMAP
VMACIMSA: SYNCDMAP
VMACMVCI: T6EUDATA
VMACOPC: EXRPURGE
VMACSNAP: SNAPSVCI SNAPDTE SNAPSTA1 SNAPSTA2 SNAPREAS
SNAPDIAO
VMACSPMS: SPMSEXTB SPMSEXTE
VMACSYNC: SYNSOIO SYNSOIO
VMACTMV2: JDCLASS
VMACTMVS: ICLCUNUM ICSUBCHN IOELCUNO IOEDDVNO IVDEVADR
IVDEVNR JDCLASS
Fortunately, except for R723MSCF in TYPE72GO cited above,
none of these variables have been reported in error by
users.
Note: most of these CHAR variables were assigned MXG's
$NOTRAN informat: that was to be used by SAS as a flag to
"Not Translate" that variable between platforms, but that
scheme will not be implemented, so whether hex-containing
character variables have informat $NOTRAN or not has no
impact. Sep 2009: MXGNOTRA in CHANGE 27.014 implemented
the NOTRAN attribute support for SAS.
I also eliminated many ZMACxxxx members that were old and
no longer needed as penultimate backup for major changes.
Thanks to Don Deese, (CPExpert), Computer Management Sciences, USA.
Change 19.215 MXG 19.05 only. PDB.ASUM70PR and PDB.ASUMCEC variable
VMXG70PR SHIFT was usually wrong. The _DURSET logic changes made
Nov 2, 2001 by Change 19.201 were incorrect and were revised with the
insertion of DATETIME=STARTIME; before the first include
statement for IMACSHFT, and that code block was copied to
the second include statement for IMACSHFT.
Thanks to Bruce Widlund, Merrill Consultants, USA.
======Changes thru 19.214 were in MXG 19.06 dated Oct 30, 2001======
Change 19.214 Support for NTSMF SMS Objects create five datasets:
EXNTSMDI dddddd dataset description
EXNTSMEX NTSMDI SMSDISDM SMS DISCOVERY DATA MANAGER
EXNTSMIM NTSMEX SMSEXTHR SMS EXECUTIVE THREAD STATES
EXNTSMSE NTSMIM SMSINMEM SMS IN-MEMORY QUEUES
EXNTSMST NTSMSE SMSSENDR SMS STANDARD SENDER
IMACNTSM NTSMST SMSTATUS SMS STATUS MESSAGES
VMACNTSM
VMXGINIT
Oct 31, 2001
Thanks to Jim Quigley, ConEd, USA.
Change 19.213 "Support" for DB2 V7 QLES section was added to DB2STATS
VMACDB2 dataset (from 100 subtype 1) record, even though none of
Oct 31, 2001 the QLES fields are described in the DSNDQLES DSECT; they
are all flagged with (S) - Serviceability. Additionally,
the 8-byte QLETIMEx "time" fields, are actually two four
byte fields, which I have assumed to be like CICS "time"
values, with a 4-byte time value and a 4-byte count when
the time value was updated. While all of the other four
byte counters are accumulated, five of the "time" fields
are not accumulated: QLETIMEW,QLECNTM,QLETIMEI,QLECNTDY,
and QLECNTW. (The pair of time and count variables are
named QLETIMEx and QLECNTx, labelled "QLETIMEx*TIME" and
"QLEXTIMEx*COUNT". The QLExxxxx variables are discussed
in IBM documentation concerning the use of DSNTIP7 and
Section 2 of the DB2 Installation Guide, specifically to
measure and set the MAXIMUM LE TOKENS (LEMAX) on that DB2
panel to ensure that there are enough, and not too many,
LE tokens. Whether I've guessed correctly on the order
of time-count, and whether my assumed time units of secs
are valid, will hopefully confirmed or corrected, when
either IBM provides additional documentation, or when you
users can prove or disprove the numbers! Why only five
counters are not accumulated, especially since they are
really in pairs, suggests possible alignment errors, but
even then, I would expect four or six, not five.
Thanks to Harry Price, Florida Light and Power, USA.
Thanks to Ed Gambon, Florida Light and Power, USA.
Change 19.212 MXG 19.05 ONLY, CPUTYPE not 2064, LPARCPUS count is wrong
VMAC7072 in TYPE70PR and in ASUM70PR, because the test added by
Oct 30, 2001 Change 19.189 to support APAR OW49536 only was valid if
the CPUTYPE='2064'x. The revised change now counts CPUS:
IF SMF70CIN NE 'ICF' AND ( (SMF70ONT NE 0) OR
(SMF70ONT EQ 0 AND CPUTYPE NE '2064'X) )
THEN LPARCPUS=LPARCPUS+1;
and thus is CPU-Type dependent until IBM externalizes the
DDBOnlin flag into the RMF type 70 record as a safer test
field in the future.
Thanks to Peter Krijger, National Bank of New Zealand, NEW ZEALAND.
Thanks to Alan Sherkow, I/S Management Strategies, USA.
Change 19.211 Support for Tivoli/Netview NPM 2.6 COMPATIBLY added one
EX028INN new subtype, 17x, for new NPMINNRC dataset containing
VMAC28 Router CISCO CIP Interval Volume Data (i.e., records are
VMXGINIT written only for the routers that have installed CISCO
Oct 30, 2001 CIP card).
Oct 31, 2001
Change 19.210 NOT SORTED TYPE72GO error in WEEKBLDT caused by Change
WEEKBLDT 17.353 that added variable RPRTCLAS to the BY list in
WEEKBL3T TYPE72GO/WEEKBLD/MONTHBLD but missed WEEKBLDT/WEEBL3T.
Oct 30, 2001 This worked fine for two years, but a SET CLOCK event at
two sites exposed the MXG inconsistency that caused the
error. Correcting the BY list eliminated the error.
Thanks to Art Hunter, Penn Mutual, USA.
Thanks to Richard Lopez, Johnson and Johnson, USA.
Change 19.209 RMF III job monitor total storage is created in new
VMACRMFV variable ASIDTOT=SUM(ASIFMCT,ASIFMCTI,ASIESF,ASIESFI);
Oct 28, 2001 in ZRBASI dataset.
Thanks to Mark Wittie, FMR, USA.
Change 19.208 First 19.05 only. SYSTEM object has missing counters if
VMACNTSM NRDATA=24; first IF test was revised.
Oct 24, 2001
Thanks to Jim Quigley, ConED, USA.
======Changes thru 19.207 were in MXG 19.05 dated Oct 24, 2001======
Change 19.207 Some sample MQ Series Exception reports based on SMF 115
ANAL115 records (TYPS115).
Oct 24, 2001
Thanks to Bruce Widlund, Merrill Consultants, USA.
Thanks to Yakov Nudel, Beta Systems, USA.
Thanks to Jan Hess, America West, USA.
Change 19.206 Unexpected blank 80-byte record at start of compressed
VMACTMO2 Landmark file caused INPUT STATEMENT EXCEEDED error. This
Oct 24, 2001 change detects short records, lists them on the SAS log,
and deletes them. These records are probably being added
as part of the site's tape initialization process, rather
than being created by Landmark.
Thanks to Tim Sisk, CSC Corp, USA
Change 19.205 Using ASUMCICS with Landmark TYPSTMO2 member failed, due
ASUMCICS to the incorrect include of member IMACMONI instead of
Oct 23, 2001 VMACTMO2 (so _LMONTSK was not defined).
Thanks to Robin Murray, Maritime Life, CANADA
Change 19.204 Support for CICS/TS 2.2 Statistics changes to CICDS data.
VMAC110 IBM has changed the 9th and 11th TCB buckets contents and
Oct 23, 2001 added a twelfth bucket:
Nov 12, 2001 MXG Prefix TCB Number TCB Name 2.1 TCB 2.2 TCB
DSG 1 QR 1 1
DS2 2 RO 2 2
DS3 3 CO 3 3
DS4 4 SZ 4 4
DS5 5 RP 5 5
DS6 6 FO 6 6
DS7 7 SL 7 7
DS8 8 SO 8 8
DS9 9 J8 9 H8 12
DSA 10 L8 10 11
DSB 11 S8 11 9
DSC 12 D2 -- D2 10
MXG variable DSnTCBNM, where n is the TCB number, will
contain the actual name of the TCB so you can verify
which set of TCB values applies to which TCB; because of
the IBM change, the LABEL values for DS9,DSA,DSB, and DSC
variables may be incorrect, but DSnTCBNM will be valid.
There are additional DSG Pool segments that are not yet
decoded, as I need actual data to validate their location
in the SMF record to write that code.
Change 19.203 Support for z/OS Version 1.1 and 1.2 APAR and MXG error.
VMAC78 APAR OW49806, for z900 with z/OS 1.2, adds new IOP
Oct 23, 2001 (I/O Processor) utilization measurements have been added
TYPE78IO dataset:
R783IIPB='TIMES WHEN*IOP*WAS BUSY'
R783IIPI='TIMES WHEN*IOP*WAS IDLE'
R783IIFS='IO FUNCTIONS*INITIALLY*STARTED'
R783IPII='PROCESSED*I/O*INTERRUPTS'
R783ICPB='RETRIES*DUE TO*CHANNEL*PATH*BUSY'
R783IDPB='RETRIES*DUE TO*DIRECTOR*PORT*BUSY'
R783ICUB='RETRIES*DUE TO*CONTROL*UNIT*BUSY'
R783IDVB='RETRIES*DUE TO*DEVICE*BUSY'
But in installing this support, I found the new variables
for DCM managed channels, added by Change 18.134 for 1.1
(R783MCMN/MX/DF/PTM/DBPM/CUBM added to dataset TYPE78IO),
should have instead been added to dataset TYPE78CU, so
this change is required for z/OS 1.1 and 1.2 on all
platforms, not just z900s.
14May02: Documented in comments in VMAC78, but not here,
z/OS 1.2 R783GSAM/NRCMPTSM and R783PB/PCTPTHBY are now
reserved, causing PCTPTHBY to be missing in TYPE78CF.
16Jun02: This also causes PCTALLBY to be missing in
TYPE78CU, beginning with Z/OS 1.2.
Change 19.202 Support for Serena's Ultimizer user SMF record.
EXULTM01 Four datasets are created:
EXULTM02 ULTM01 ULTMIZ01 VSAM BLOCKSIZE OPTimIZATION
EXULTM03 ULTM02 ULTMIZ02 QSAM BUFFER OPTIMIZATION
EXULTMNN ULTM03 ULTMIZ03 QSAM BLOCKSIZE OPTIMIZATION
FORMATS ULTMNN ULTMIZNN BLDVRP OVERRIDE OR BYPASSES
TYPEULTM This vendor puts the RDRDATE where the SYSTEM should be
TYPSULTM in the SMF header. The subtypes 4 thru 10 are all output
VMACULTM in the ULTMIZnn dataset, which appears to also have
VMXGINIT duplicate records created for some subtypes.
Oct 20, 2001
Change 19.201 Several enhancements to PDB.RMFINTRV and PDB.ASUM70PR:
ASUM70PR -Variables PARTISHN TOTSHARE LPARSHAR and CECSER added to
VMXG70PR PDB.RMFINTRV by your include of ASUM70PR after BUILDPDB
VMXGRMFI that updates PDB.RMFINTRV after PDB.ASUM70PR is built.
Oct 22, 2001 -The SYNC59 logic in VMXGRMFI was revised; it could be
off by one minute in creating PDB.RMFINTRV.
-The 70ID list was cleaned up and now is in one place.
-If you used the (recently added) INTERVAL= and SYNC59=
arguments in your RMFINTRV member to control %VMXGRMFI's
summary interval, variables PLATBUSY and PLATCPUS could
be missing, because the ASUM70PR program that adds them
into PDB.RMFINTRV uses the _DURSET macro in IMACRMFI to
set the ASUM70PR interval, causing the mis-match. This
exposure is fixed by new member VMXG70PR, a new %MACRO
definition, that is now invoked by member ASUM70PR, with
the same arguments as VMXGRMFI, so that if you do tailor
RMFINTRV with INTERVAL= and/or SYNC9=, you now can (and
now MUST!) use the same arguments and values in both your
RMFINTRV and ASUM70PR members, so that the intervals in
RMFINTRV, ASUM70PR, and ASUMCEC are identical.
-The default value in both RMFINTRV and ASUM70PR are set
to INTERVAL=DURSET and SYNC59=NO, so that the default
interval in PDB.RMFINTRV and PDB.ASUM70PR is set by the
member IMACRMFI (in it's _DURSET macro definition).
By default, IMACRMFI member does no summarization, and
instead creates one observation in PDB.RMFINTRV and
PDB.ASUM70PR for each original RMF interval.
-If you have tailored member IMACRMFI to set the summary
interval (eg, HOUR, SHIFT, etc) you want, then it will
be used for both RMFINTRV and ASUM70PR.
-If instead you tailored member RMFINTRV to use INTERVAL=
or SYNC59= arguments, then you MUST also tailor member
ASUM70PR to use those same arguments and values.
-With the added variables, the maximum percent CPU busy
that a system can reach based on LPAR weights can be
calculated
LPARMAX=100*(LPARSHAR/TOTSHARE)*(NRCPUS/PARTNCPU);
E.g.: CEC with 11 physical engines and with 3 LPARS:
6 engines and weights of 47 in two LPARS
2 engines and weight of 6 in one LPAR
LPARMAX = 100 * (47/100) * (11/6) = 86.6 %
is the busyiest those six engine LPARs can be,
even though PLATBUSY is 100%
-Correction in ASUM70PR for Dedicated processors to change
IF LCPUDED='Y' AND LCPUWAIT='Y' THEN DO; to now read
IF LCPUDED='Y' OR LCPUWAIT='Y' THEN DO;
because the logic only worked for Dedicated and LCPUWAIT,
which could cause the non-dedicated CPU busy to be wrong.
Thanks to Chuck Hopf, MBNA, USA.
Thanks to Steve Emson, TESCO, ENGLAND.
Thanks to Richard Rich, State of California Teale Data Center, USA.
Change 19.200 Support for SMF type 82 crypto facility record
EXTY8201 creates thirteen new datasets:
EXTY8203 TY8201 TYPE8201 INITIALIZATION
EXTY8204 TY8203 TYPE8203 STATUS CHANGE
EXTY8205 TY8204 TYPE8204 CONDITION CODE 3
EXTY8206 TY8205 TYPE8205 SPECIAL SECURITY MODE
EXTY8207 TY8206 TYPE8206 MASTER KEY PART
EXTY8208 TY8207 TYPE8207 KEUK PART
EXTY8209 TY8208 TYPE8208 CKDS REFRESH
EXTY8210 TY8209 TYPE8209 CKDS UPDATE
EXTY8211 TY8210 TYPE8210 PKA KEY PART
EXTY8212 TY8211 TYPE8211 CLEAR NEW MASTER KEY PART
EXTY8213 TY8212 TYPE8212 PUBLIC KEY SECURE CABLE
VMAC82 TY8213 TYPE8213 PUBLIC KDS UPDATE
VMXGINIT
Oct 19, 2001
Change 19.199 Incorrect copying in the weekly phase was corrected by
BLDNTPDB inserting a RUN; statement between the PROC COPY and the
Oct 19, 2001 %VMXGOPTR invocation (to force macro resolution).
Thanks to Greg Jackson, National Life of Vermont, USA
Change 19.198 Invalid values for sample counts of 'FFFFFFFF'x for the
VMAC7072 PCTDLTOT (R723TOT) and PCTDLQ (R723CQ) and 'FFFFFFFA'x
Oct 19, 2001 for PCTDLTDQ (R723CTDQ) caused very small VELOCITY and
very large PERFINDX values. MXG now tests those three
fields and forces a missing value when large values are
found in the IBM record.
Updated: Oct 30, 2001: IBM APAR OW50380 fixes the error,
at least for basic mode.
Thanks to Jiann-Shiun Huang, CIGNA, USA
Thanks to Perry Metzel, Hewitt, USA.
Change 19.197 -Support for revised SYSTEM object with NRDATA=24, which
EXNTEPXY reinstated Total Interrupts/Sec counter to match all of
EXNTEXEX the SYSTEM fields that used to exist in NT 4.0.
EXNTMEAL -Support for the restructured SQL 2000 objects creates
EXNTMECA these seventeen new SQLServer datasets:
EXNTMECO NTQLAM MSQACCES NT MSSQL:ACCESS METHODS
EXNTMEIM NTQLBD MSQBKPDV NT MSSQL:BACKUP DEVICE
EXNTMEM NTQLBM MSQBUFMG NT MSSQL:BUFFER MANAGER
EXNTMEOE NTQLBP MSQBUFPA NT MSSQL:BUFFER PARTITION
EXNTMEOR NTQLCM MSQCACMG NT MSSQL:CACHE MANAGER
EXNTMEPO NTQLDA MSQDATAB NT MSSQL:DATABASES
EXNTMEPR NTQLGS MSQGENST NT MSSQL:GENERAL STATISTICS
EXNTMESA NTQLLA MSQLATCH NT MSSQL:LATCHES
EXNTMESR NTQLLO MSQLOCKS NT MSSQL:LOCKS
EXNTMETD NTQLMM MSQMEMMG NT MSSQL:MEMORY MANAGER
EXNTMETS NTQLRA MSQREPAG NT MSSQL:REPLICATION AGENTS
EXNTMEWM NTQLRD MSQREPDI NT MSSQL:REPLICATION DIST.
EXNTMIGA NTQLRL MSQREPLR NT MSSQL:REPLICATION LOGREADER
EXNTMIGP NTQLRM MSQREPME NT MSSQL:REPLICATION MERGE
EXNTMISC NTQLRS MSQREPSN NT MSSQL:ACCESS METHODS
EXNTMISE NTQLSE MSQUSRSE NT MSSQL:USER SETTABLE
EXNTMISI NTQLSS MSQSTATS NT MSSQL:SQL STATISTICS
EXNTQLAM -Support for 14 new MS Exchange objects create datasets:
EXNTQLBD NTMEAL MSEXMEAL NT MSEXCHANGEAL
EXNTQLBM NTMECA MSEXCACH NT MSEXCHANGEDSACCESS CACHES
EXNTQLBP NTMECO MSEXCONT NT MSEXCHANGEDSACCESS CONTEXTS
EXNTQLCM NTMEIM MSEXIMAP NT MSEXCHANGEIMAP4
EXNTQLDA NTMEM MEMORY NT MEMORY
EXNTQLGS NTMEOE MSEXOLEV NT MSEXCHANGE OLEDB EVENTS
EXNTQLLA NTMEOR MSEXOLRE NT MSEXCHANGE OLEDB RESOURCE
EXNTQLLO NTMEPO MSEXPOP3 NT MSEXCHANGEPOP3
EXNTQLMM NTMEPR MSEXPROC NT MSEXCHANGEALACCESS PROCESSES
EXNTQLRA NTMESA MSEXMESA NT MSEXCHANGESA - NSPI PROXY
EXNTQLRD NTMESR MSEXSRS NT MSEXCHANGESRS
EXNTQLRL NTMETD MSEXTRDR NT MSEXCHANGEIS TRANSPORT DRIVER
EXNTQLRM NTMETS MSEXTRSD NT MSEXCHANGETRANSPORT STORE DRIVER
EXNTQLRS NTMEWM MSEXWEBM NT MSEXCHANGEWEB MAIL
EXNTQLSE The duplicate removal logic was validated and BY lists
EXNTQLSS were enhanced where needed to ensure removal. There are
IMACNTSM actual duplicates in MSEXCONT that are being investiaged.
NTINTRV -In NTINTRV, the NTCONFIG dataset is no longer combined in
VMACNTSM to PDB.NTINTRV because is is not an interval dataset.
VMXGINIT -SP2 for Exchange 2000 added object MSExchangeIS Mailbox
Oct 19, 2001 that appears to have the same fields as MS..eIS Public,
so the Mailbox records are output in MSEXISPU dataset.
Object for MSExchangeIS was restructured with some new
and some removed fields. The "Database ==> Instances"
object is questionable, and missing fields in Database
object have yet to be resolved, but both objects with
"Database" in their name are now output into DATABASE.
-New Epoxy object creates new EPOXY dataset.
-New MicroSoft Gatherer object creates new MIGATHER
-New " Gatherer Projects object creates new MIGATHPR
-New Microsoft Search object creates new MISEARCH
-New " Search Catalogs object creates new MISEARSC
-New " Search Indexer Catalogs creates new MISEARSI
-New Exchange Server HTTP Extensions new EXCHHTEX
Change 19.196 Variable QBGBGCS, the current status of GBPCACHE (NO/YES)
VMACDB2 was added by DB2 Release 6, but was skipped by MXG; now
Oct 17, 2001 that variable is INPUT and kept in dataset DB2GBPAT.
Thanks to Don Deese, (CPExpert), Computer Management Sciences, USA.
Change 19.195 Cosmetic. Some of the error messages for bad segments
VMAC108 had incorrect segment name in the text, possibly causing
Oct 17, 2001 confusion, if any of those conditions ever occurred.
Thanks to Bob Furlong, Chase, USA.
Change 19.194 Change 19.101 removed PGMRNAME from the TYPE30_4 step
BUILD005 dataset in BUILDPDB processing to protect against blank
BUIL3005 values, but that change caused PGMRNAME to not be kept
Oct 17, 2001 in PDB.STEPS; by adding PGMRNAME to the PDBADD2/PDBADD3
Apr 5, 2002 macros, the PGRMNAME from the PDB.JOBS dataset will now
be copied into the PDB.STEPS dataset. However, PGMRNAME
will still be blank if no PGMRNAME was used on the JOB
card: PDB.JOBS and PDB.STEPS contains observations for
all "jobs": STCs, TSO, OMVS, USS, APPC, etc, all will
create "job" records that can have no PGMRNAME value,
so variable TYPETASK may explain blank PGMRNAME values.
Since BUILDPDB keeps PGMRNAME from only the 30.1 Job Init
and 26 Job Purge, if "Spinning" was not enabled in your
IMACSPIN, and if only step/job/print without init/purge
are found for a job, then variable INBITS won't contain
an I or a P, and PGMRNAME will be blank in JOBS/STEPS.
5Apr02: Text revised: why it can still be blank.
Thanks to Bob Greer, Nissan North America, USA.
Change 19.193 Support for IFCID=225, DB2 Storage Manager Pool Summary
VMAC102 Statistics to create dataset T102S225, with lots of stats
Oct 17, 2001 on pool sizes and concurrent activity.
Thanks to Sim Williams, Fidelity, USA.
Change 19.192 New formatted variable S42DSBUF for VSAM Buffer type:
FORMATS S42DSBUF='VSAM*BUFFER*TYPE'
VMAC42 with values 0:NSR 1:RLS 2:LSR 3:GSR
Oct 16, 2001 and new character flag variables ('Y' or blank) are added
S42DSEXC='OPEN FOR*EXCP*PROCESSING?'
S42DSFXD='NONVSAM*FIXED*LENGTH*RECORDS?'
S42DSPL ='PROGRAM*LIBRARY?'
S42DSEF ='EXTENDED*FORMAT?'
S42DSEFC='COMPRESSED*FORMAT?'
to TYPE42DS by decoding the existing S42DSFL1 variable.
These new variables were used to examine why the S42AMxxx
Access Method Statistics variables are sometimes missing
in TYPE42DS. Thus far, all observations with
S42DSEXC='Y' - EXCP Access Method
do not contain an Access Method Statistics section, but
no other pattern has been found to explain why that A.M.
segment is not present (S42DSAMO=0) for other datasets.
Thanks to Rob D'Andrea, NatWest, ENGLAND.
Change 19.191 Variable CPUTYPE was added to the KEEP= list for TYPE70PR
VMAC7072 dataset.
Oct 15, 2001
Thanks to Helmut Roese, COM Software GmbH, GERMANY.
Change 19.190 This example report to calculate per-service-class CPU
ANALSRVC busy percentages had a FORMAT PGPCTCAP PGPCTUSE 5.1; that
Oct 7, 2001 should have been FORMAT SVPCTCAP SVPCTUSE 5.1; .
Thanks to Sudie Wulfert-Schickedanz, Anheuser-Busch, USA.
======Changes thru 19.189 were in MXG 19.04 dated Oct 5, 2001======
Change 19.189 Support for APAR OW49536 (INCOMPAT if you have SPARE CPU
VMAC7072 engines on your 2064 CPU). Reserve/Spare CPUs on 2064s
Oct 5, 2001 have segments in type 70 records that were being counted
as a real CP engine (both in RMF reports and in MXG!).
This change tests SMF70ONT, the new LPAR "online time";
only if that value is non-zero will that CP be counted.
A missing value in SMF70ONT will be counted; that is a
record without the new field that can't have the problem.
A non-zero non-missing value in SMF70ONT will be counted,
because it was online during the interval.
Variable LPARCPUS in dataset TYPE70PR, and the LPnNRPRC
variables for each LPAR in dataset ASUM70PR will be wrong
and LPAR percentages based on these variables will also
be incorrect without this change.
Thanks to Al Sherkow, I/S Management Strategies Ltd, USA.
Change 19.188 TYPEIMSA corrected ENDTIME and STRTTIME for GMTOFFTM, but
TYPEIMSA variable END7TIME was not corrected, so these variables
Oct 5, 2001 IMSSRVTM IMSRESTM IMSSRVTS and IMSRESTS were off from TOD
by the value of GMTOFFTM. All are now corrected.
Thanks to Daniel Cannon, The Hartford, USA.
Change 19.187 Enhancements for MXG NTSMF support:
ASUMNTIN -NTCONFG file has been added in NTINTRV so KEEPALL=YES can
BLDNTPDB be used in ASUMNTIN.
NTINTRV -ASUMNTIN now uses KEEPALL=YES for performance reasons.
-RUNMNTH processing in BLDNTPDB corrects problem passing
Oct 5, 2001 a variable that should not have been.
Stay tuned: more enhancements, like RERUN, in progress.
Change 19.186 Support for RMF type 74 subtype 4 "Broken Records" output
VMAC74 observations from the subsequent, incomplete record when
Oct 2, 2001 that record should have been deleted, as it was precedeed
by the MXG "Broken Record" message from the previous SMF
record. This change only outputs to TYPE74CF when the
SUM(SMF744XN,SMF744GN,SMF744QN,SMF744SN,SMF744PN)
is greater than zero.
For First 19.04: This change relocate the RO section,
inserted the missing END; and corrected the comment that
has masked the missing END;
Thanks to Wally Danielson, Airborne, USA.
Change 19.185 Support for Implex USER SMF record creates five datasets
EXMPLXGA one per subtype, from Williams Data Systems:
EXMPLXIN Subtype DDDDDD Dataset
EXMPLXPE 1 MPLXIN IMPLEXIN Interface Statistics
EXMPLXPM 2 MPLXSE IMPLEXSE Service Statistics
EXMPLXPO 3 MPLXGA IMPLEXGA Gateway Statistics
EXMPLXRT 4 MPLXRT IMPLEXRT RTT Statistics
EXMPLXSE 5 MPLXPR IMPLEXPR Protocol Monitoring
FORMATS These records contains accumulated fields, so the member
IMACMPLX both TYPEMPLX and TYPSMPLX invoke the _SMPLX "sort MPLX"
TYPEMPLX macro, which sorts and deaccumulates these datasets into
TYPSMPLX the default DDname of PDB. Implex is an IP monitor with
VMACMPLX 3270 response time monitoring.
VMXGINIT
Oct 5, 2001
Thanks to Rolf Meinert, Volkswagen, GERMANY.
Change 19.184 MXG Data Sets contain labels with unique syntax DDDDDD:,
BLDNTPDB that is used via PROC CONTENTS to control copying of the
Oct 2, 2001 daily/weekly/monthly in the BLDNTPDB logic. However, the
DATA WEEK.NTxxxxx; SET MON.NTxxxxx ... SUN.NTxxxxx; does
not propagate a dataset LABEL, causing RUNMNTH=YES to
fail with ERROR: BY VARIABLE _B IS NOT ON INPUT DATASET
(because the DDDDDD value is used to create &SUFX, but if
there is no DDDDDD value in the label, &SUFX is blank).
The circumvention is to use the PDB, instead of the WEEK.
as the library to read to get the DDDDDD values. Change
%VMXGINV(LIBNAME=WEEK); to %VMXGINV(LIBNAME=PDB) after
the comment "BUILD THE MONTHLY" to circumvent.
Thanks to Liz Slack, Premera Blue Cross, USA.
======Changes thru 19.183 were in MXG 19.04 dated Oct 1, 2001======
Change 19.183 Variable R742PIOT in dataset TYPE74PA was always missing.
VMAC74 The test IF SKIP GT 4 THEN DO; prior to its INPUT should
Oct 1, 2001 have been IF SKIP GE 4 THEN DO;
Thanks to Philip Foster, CGI Inc, CANADA.
Change 19.182 A new alternative report member for GRAFWORK, enhanced to
GRAFWRKM support all workload that are now createable in RMFINTRV,
GRAFWRKX with an additional neat twist. With GRAFWORK, workloads
Oct 1, 2001 are stacked from bottom to top and the order was fixed:
Overhead, CICS, IMS, TSO, BATCH, OTHER OTH1-OTH9.
But now with GRAFWRKS, if IMACWORK=NO is used, there is
total control of the order of stacking (except that the
"overhead", or uncaptured, is always at the bottom, so
you can order the stacking to map the priorities of your
workloads. GRAFWRKM is an example using GRAFWRKX.
Thanks to Chuck Hopf, MBNA, USA.
Change 19.181 Support for CICS/TS 2.2 SMF 110 Subtype 1 CICSTRAN record
VMAC110 is almost compatible! IBM added two new variables at the
Sep 29, 2001 end of the standard transaction segment:
PTPWAITM='3270 BRIDGE*PARTNER*WAIT*ELAPSED*TIME'
PTPWAICN='3270 BRIDGE*PARTNER*WAIT*COUNT'
so that all of the standard IBM fields are still correct
with earlier versions of MXG that supported TS 2.1 data.
However, if you are processing any of the optional CICS
segments, this change is required so that the optional
variables are valid: (you ARE processing optional CICS
segments if there are IMACICxx members in your tailoring
MXG library).
This change supports only the subtype 1 record. A later
change will support the CICS TS 2.2 Statistics subtype 2
record changes (INCOMPAT: CICDS data moved to STID=60).
Change 19.180 Support for SMF 120 WAS/390 4.0 EE (Websphere Application
EXT120JI Server, Enterprise Edition) which adds new Server Type:
EXT120JC -MOFW server supports both C++ and Java BOs (in 3.02)
FORMATS -J2EE server supports EJBs only (new in 4.0)
VMAC120 The existing subtype 1 and 3 records for MOFW servers are
VMXGINIT reused for the new J2EE server, so existing MXG datasets
Sep 28, 2001 TYP102SA and TYP102SC from subtype 1 Server Activity and
Oct 17, 2001 TYP102SI from subtype 3 Server Interval are changed only
by the addition of new variable SM120ST, Server Type, to
identify MOFW or J2EE server type. Existing MOFW subtype
2 and 4 could not be reused; new subtypes 5 and 6 create
MXG dataset TYP120JC (subtype 5 J2EE Container Activity)
and dataset TYP120JI (subtype 6 J2EE Container Interval).
-These new records are the first SMF records to contain
UCS, or Unicode DBCS (Double Byte) character data in new
variables SM120JA8/SM120JB1/SM120JM1/SM120JA, with the
names of containers, ejbRoles, methods, and AMCNames of
the bean, etc. However, SAS support for UCS (Informat
$UCS2Bnnn.) became available in SAS V8, so those new
UCS variables will have valid printable names only if
SAS Version 8 or later is used to build the datasets.
Although those names can be as large as either 256 or 512
characters (512 or 1024 bytes of DBCS data in the record)
until there is a need for more text, and for simplicity
and compatibility, only the first 200 characters are
kept, creating a unique new MXG macro variable named
UCS2B4, with value:
IF &SYSVER GE 8.2 THEN %LET UCS2B4= $UCS2B4 ;
ELSE %LET UCS2B4= $EBCDIC2;
so that using "&UCS2B4.00" syntax, SAS V8.2+ will INPUT
with $UCS2B400. while earlier INPUT is with $EBCDIC200.
Code was revised and validated with J2EE data, Oct 17.
Change 19.179 RMF III LENGTH=0 cause INPUT STATEMENT EXCEEDED error,
VMACRMFV but a rerun does not fail, (but a rerun against the VSAM
Sep 28, 2001 file to create the BSAM file will have different records
because RMF III VSAM continuously runs and wraps). This
change tests and deletes LENGTH=0 records with a message
on the log to show how many records were found.
Thanks to John F. Gebert, Office Depo Inc, USA.
Change 19.178 DB2 variable QWHSLUCC is the character variable with the
VMACDB2 Commit Count, but that should have been a numberic value.
VMACDB2H Since I can't change the type from CHAR to NUM without a
Sep 27, 2001 serious compatability issue, I have created QWHSLUCN as
a numeric variable with the Commmit Count.
Thanks to Chuck Hopf, MBNA, USA.
Change 19.177 Support for IMS 6.1 Fast Path records (INCOMPAT).
VMACIMS Fast Path subcodes 01, 03, 36, 37, and 38 were all
VMACIMSA changed by IBM; fields were inserted in all records, and
Sep 27, 2001 new variables are now created and kept. Support was then
Oct 15, 2001 revised Oct 15 to correct VARIABLE STRTTIME NOT FOUND
errors introduced by the first change.
Thanks to Pete Gain, SAS, ENGLAND.
Change 19.176 Support for z/OS Version 1 Release 2 changes in SMF data:
EXTY7002 -TYPE30xx - bit 2 in field SMF30SFL (Storage/Paging) new
EXTY74DU variable IEFUSIME='IEFUSI*CHANGED*MEMLIMIT?'
FORMATS in TYPE30_4, TYPE30_V, TYPE30_5, TYPE30_6.
IMAC7072 - new vars MEMLIMIT='MEMLIMIT*VALUE'
IMAC74 and SMF30MLS='SOURCE OF MEMLIMIT' which
VMAC30 is decoded by new MG030ML format:
VMAC7072 1:MEMLIMIT SET BY SMF
VMAC71 2:MEMLIMIT SET IN JCL
VMAC73 3:MEMLIMIT BASED ON REGION=0
VMAC74 4:MEMLIMIT SET BY IEFUSI
VMAC78 but SMF30MLS and MEMLIMIT are set missing (and
VMAC79 not zero) if SMF30MLS has no bit set (i.e., if
VMAC90 MEMLIMIT is not specified).
VMXGINIT -TYPE70PR - Existing SMF70BDA is now divided by SMF70DSA
Sep 25, 2001 to calculate Average number of LCPUs Active,
as the variable was labelled, and existing
SMF70ACS is now documented as 4 bytes (z/OS
R1.1 doc had ACS 2 bytes with +2 after MAS; I
assume this is an IBM doc correction).
SMF70ACS is now divided by SMF70DSA.
-TYPE7002 - New Dataset for Cryptographic Coprocessor data
contains PCCI Cryptographic Hardware execution
times and counts for all operations and all
RSA-key-generation operations.
-TYPE71 - New Swap Reason "In-Real Swap" is added in new
variables SWAPIR/EXTAUXIR/LOGAUXIR/LOGEXTIR/
PHYAUXIR/PHYEXTIR.
-TYPE72GO - New variable R723CLSC, only in Reporting Class
observations, contains the name of the Service
Class that last contributed to this Reporting
Class; blank if this obs is for Service Class.
Note: Previously Reporting Classes did not
have Periods, (only Service Classes
had periods), but now both can have
up to 8 periods.
- New variable R723HETR='Y' if this report class
period is "Heterogeneous":
If the report class contains transactions
from a single service class, R723HETR='N'
for a "Homogeneous" reporting class.
Report classes now can combine transactions
running in different service classes, and
those "Heterogeneous" have R723HETR='Y'.
BUT: IBM says data is invalid if hetero.
- New variables R723CAMU/R723CAMD (CAM CRYPTO)
and R723APU/R723APD (AP CRYPTO) contain TCB
USING and TCB DELAY samples for Cryptographic
Asynchronous Message Processor (CAM) and for
Cryptographic Assist Processor (AP).
- New R723FQD Feature Queue Delay Samples: a TCB
was found waiting on a processor feature queue
associated with a CPU, are also included in
the delay samples in R723CCDE (MXG PCTDLCDE).
Note: Feature Queue Using Samples are in
MXG variable PCTUSCUS (R723CCUS).
-TYPE7204 - Type 72 subtype 4 delay samples have new var
R724OR18 for new "In-Real" Swap Reason delays.
-TYPE73 - New CPMF Channel Measurement Groups 3 adds new
channel traffic variables for HiperSockets, or
the IQDIO, a/k/a IQD (Internal Queued Direct
Communication) channel type, a high-speed LAN
for communications between LPARs in a CEC/CPC.
Eleven variables with byte rates per second,
for both LPAR and Totals, for both data unit
and message unit traffic, plus unsuccessful
sends and receive counts, but there is no
capacity measure for the IQD. These new
variables exist only for SMF73CMG=3:
SMF73PDS SMF73PDU SMF73PMS SMF73PUB SMF73PUM
SMF73TDS SMF73TDU SMF73TMS SMF73TUB SMF73TUM
SMF73PUS
-TYPE74CF - New variables added to TYPE74CF with bit masks
of paths available and installed and channel
path type acronym for each of 8 possible paths
in variables
R744FPAS R744FPIS R744FPCM R744FTA1-R744FTA8
-TYPE74ST - New variables for waits, wait duration, and
square of wait duration for waiting for peer
subchannel, for waiting for peer with reserve
held, and for waiting for peer completion in
these new variables:
R744SCSS R744SCST R744SCTC R744SLSV R744SPES
R744SPLN R744SPSS R744SPST R744SPTC R744SRSS
R744SRST R744SRTC
-TYPE74DU - New remote facility data section in subtype 4
Coupling Facility data for your Duplexed CFs
creates new dataset TYPE74DU.
-TYPE746x - SKIP calculation corrected for 746BL/746DL.
-TYPE747x - While decoding of the subtype 7 FICON Director
is in place in VMAC74, no datasets are created
until I have test data to understand.
-TYPE78CF - IBM removed PCTPTHBY and NRCMPTSM fields, so
they will now have missing values.
-TYPE791 - Variable R791TTOD now is non-zero and contains
"Real Time into Transaction".
- Added swap 'SR'='IN REAL' to FORMAT $MG079SR
- New R791MLIM variable ASID Memory Limit added.
- Bits in R791FLG and R792FLG added for temporal
affinity
-TYPE79C - New CMG=3 data added
-TYPE79E - Variables CHPIDTKN and NRCMPTSM now reserved.
-TYPE90 - Support for subtypes 26,27,28,29,30,31,32.
Change 19.175 Statistics reports for multiple intervals used the number
ANALDB2R of intervals as a divisor, incorrectly, but only on one
Sep 25, 2001 summary page, and only for the Long Statistics summary
and trace, PMSTA01/PMSTA03, which are not invoked by
default. It's been this way for some time, suggesting
that a) that page of that report is not very useful, or
b) no user has looked at it that closely until now!
Thanks to Liesbeth Post, KLM, THE NETHERLANDS.
Change 19.174 Two separate sites report errors in SMF type 60 records,
VMAC60 causing INPUT STATEMENT EXCEEDED RECORD error when read.
Sep 21, 2001 Both had VVRTYPE=Z:PRIMARY, but the two SMF records are
Oct 1, 2001 wrong in different ways:
-ENTTYPID=C:CLUSTER record, VVR has impossible value for
offset-to-next-field of 1792 in a 588 byte SMF record:
VVRLOKYL=1792 (0700x located at byte 563) can't be
valid, but the expected fields VVRXSC1 that I tried to
INPUT look like they are there after VVRLOKYL in the
record. Maybe first byte of VVRLOKYL is now a flag
(note '.....11100000000'B value in this record)?
CIRCUMVENTION: This change now compares VVRLOKYL with
LENGTH to prevent INPUT, but when prevented, those
additional fields will have missing or blank values.
-ENTTYPID='A:NON-VSAM', NVR has invalid values in length
and name fields for the Storage Class, Data Class, and
the Management Class names:
VVRSTGLN Length field = 6 , but 8 EBCDIC bytes follow
before the next length:
VVRDATLN Length field = 4 , and 4 bytes do follow, but
only 3 are EBCDIC, final is
'00'x instead of '40'x, and
VVRMGTLN Length field = 6 , but four unprintable hex
bytes are followed by four
EBCDIC bytes.
so the name field variables VVRSTGCL, VVRDATCL, VVRMGTCL
are trashed, as is the VVRSBKUP datetimestamp, whose byte
location is now indeterminate with those invalid length
length fields. My old DSECT ends with VVRSBKUP, but this
record has nearly 200 bytes more data, with several new
TODSTAMP fields that should be new event variables, since
type 60s are frequently used to investigate security
issues about who has access, and who accessed, and when
did they access sensitive data on DASD volumes.
Oct 1, 2001 update to this change text:
I held this as the last change for 19.04, expecting IBM
would supply me with the VVR and NVR "DSECTS" so I could
see if something had been changed, and if so, how to
continue decoding the SMF type 60 records without error.
IBM's official reply to Merrill Consultant's request for
the DSECTS for the SMF type 60 record came from the IBM
DFSMS Vendor Activity manager:
"I've discussed this matter with the developer and since
the VVR and NVR contains proprietary information, we
cannot honour you request to acquire the DSECT for the
VVR and NVR records in the VVDS. Instead, please
contact IBM Service and be prepared to FTP the dump and
the SMF records for analysis. No promises are made as
to how we'll choose to resolve this issue."
Stay tuned for future updates to this bigger problem!
Feb 14: IBM DFSMS refuses to provide documentation of
either the Catalog or the VVDS records. One of the
above IBM errors was fixed by OW51353/OW50528 that
reports creation of defective VVR; it's a shame that
IBM would not let me have the documentation so I could
have detected the bad record and told you the APAR that
you need to correct IBM's error, but I've given up.
Thanks to Lawrence Jermyn, Fidelity, USA.
Thanks to Peter Krijer, National Bank of New Zealand, NEW ZEALAND.
Change 19.173 Invalid SMF type 42 subtype 6 (TYPE42DS) record caused
VMAC42 INPUT STATEMENT EXCEEDED error. OFFDSAM segment started
Sep 19, 2001 data byte 32697 but the record length of 32722 data bytes
left only 26 bytes for the 48-byte Access Method segment.
This change now protects for the short record, printing a
message that bad records were found and missing values
were set for the S42AMxxx variables.
Thanks to Linda S. Berkley, USPS, USA.
Change 19.172 Moving your EBDCIC SPIN library from an existing BUILDPDB
SPINSORT to run under ASCII versions of SAS will require a re-SORT
Sep 19, 2001 of the SPIN library after it has been XPORT/IMPORTed to
ASCII, or you will get SPINxxxx NOT SORTED errors.
This member has the PROC SORT and BY statements to resort
all of the SPIN datasets.
Thanks to Robert Battilana, Franklin Mint, USA.
Change 19.171 Misspelled variable CSRENTLE was corrected to CSRENTIN,
VMACRMFV and the dataset labels for ZRBCPU and ZRBENC were revised
Sep 14, 2001 in this almost-cosmetic change.
Thanks to ???, ???, ???
Change 19.170 -Dataset TPFFM variable FMIOTIM, unlike the SXxxxxxx wait
VMACTPF variables, should not have been divided by 4096.
Sep 14, 2001 -All accumulated counters in all TPF datasets are now
protected for wrapping (when they exceed their four byte
field max value) using this logic to correct the wrap:
IF . LT FVDATAn LT 0 THEN FVDATAn=FVDATAn+4294967296;
This change was not originally needed, because the TPF
monitor was only permitted to run for a few hours, so the
counters didn't wrap, but now that TPF SYSPROGs/Managers
are seeing how useful it to measure TPF, they permit the
monitor to run all day, and the counters now do wrap!
-In the TPFFV dataset (VFA Database Activity), variable
SLOTNR was replaced with new variable FVDATBAS that has
the Database Number, 1 if there is only one database,
sequentially more when there are more than one.
Thanks to Robert Wilcox, Sabre, USA.
Thanks to Jim Gilbert, Sabre, USA.
Change 19.169 The IBM field name DCVFRAGI should have been used as the
VMACDCOL variable name, but DCVFRAG1 is what I thought it was, but
Sep 10, 2001 now its too late to change the name without impact, so I
added a comment with the DCVFRAGI name for documentation.
Thanks to Moira Hunter, SchlumbergerSema, ENGLAND.
Change 19.168 Change 19.104 missed some SU_SEC variables that should
VMACTMV2 have been stored in 8 bytes now; variables SU_SEC in the
VMAC97 TMON/MVS data, variable THSU_SEC in TYPE97, and variables
VMAC30 RMSU_SEC and LOSU_SEC in some TYPE30xx are now changed.
Sep 10, 2001
Change 19.167 INVALID ARGUMENT TO FUNCTION INPUT caused messages and a
ASUMCACH hex dump on the log, and missing value in R7451RID that
Sep 9, 2001 are now corrected.
Thanks to Chuck Hopf, MBNA, USA.
Change 19.166 The Soft Audit product's records now contain SYSTEM in
VMACSFTA the field location that previously contained STEPNAME.
Sep 9, 2001 New variable SYSTEM and old variable STEPNAME will now
contain the value of that field.
Thanks to Jiann-Shiun Huang, CIGNA, USA.
Change 19.165 Revision; if APPEND=YES was specified and DDIN and DDOUT
VMXG2DTE are not the same, the output will reflect only the most
Sep 9, 2001 current day, and an error was generated.
Thanks to Chuck Hopf, MBNA, USA.
Change 19.164 TMS Audit variables TMAUxxxx have been always missing,
TYPETMS5 the TMVAxxxx variables should never have been created,
VMACTMS5 and labels for some TMAUxxxx/TMVAxxxx variables had
Sep 9, 2001 LAST UPDATE when they should have been LAST AUDIT.
This change revises the creation of TMAUxxxx variables,
(which should be used in place of TMVAxxxx variables)
in your report programs (although the TMVAxxxx variables
are correct and still kept in TMS.TMS so reports work).
Note: The TMVAxxxx variables in your old TMS.TMS data
did have correct values with wrong label. TMVATIME,
for example, contains the Last Audit Date, but now you
should use the TMAUTIME variable instead of TMVATIME.
Thanks to Terry Duchow, United States Postal Service, USA.
Change 19.163 Variable JOBCLASS has always been unique, because it had
ADOC30 valid EBCDIC characters (A-Z,0-9) for real TYPETASK='JOB'
VMAC30 records, but non-printable hex characters ('00'x) for SMF
Sep 9, 2001 type 30 records from non-JOBs (TYPETASK=STC/TSU/OMVS...).
Before variable TYPETASK existed, I thought that keeping
those non-printable values might be useful, so JOBCLASS
used the $CHAR informat to preserve the hex value. But,
under ASCII execution, this causes all values of JOBCLASS
to be unprintable; MXG stores a hex 'C1'x in JOBCLASS for
class 'A', but ASCII requires hex '41'x to print an 'A'!
Then, when IBM added the 8-byte class name field SMF30CL8
years ago, MXG input it in JOBCLAS8 with $CHAR8, adding
logic to use it as JOBCLASS only when it was present:
IF JOBCLAS8 GT ' ' THEN JOBCLASS=JOBCLAS8;
But under ASCII, that test was always true when JOBCLAS8
was blank (EBCDIC '40'x), because that GT ' ' test is
IF '40'x GT '20'x , so JOBCLAS8 was always used, even
when the one-byte JOBCLASS had a non-printable hex value!
The fix: SMF30CL8 is now always present, and it does not
contain unprintable characters, so it is now INPUT into
the JOBCLASS variable (not JOBCLAS8), using $EBCDIC as
the Informat, and "IF JOBCLAS8 GT ' ' test was deleted.
What do you do with existing MXG datasets under ASCII?
I thought you could just use the $EBCDIC format in your
PROC PRINT to display the job class value, but that does
not work under either V6 or V8 under Windows:
DATA; X='C1'x; PUT X $EBCDIC1.;
prints a lower case "e" instead of an "A"
However, you can convert the actual data value in the
JOBCLASS variable in your TYPE30_5 or PDB.JOBS dataset
on your ASCII system, using this data step:
DATA JOBS;
SET PDB.JOBS;
JOBCLASS=INPUT(JOBCLASS,$EBCDIC8.);
The description of JOBCLASS in ADOC30 was updated.
Thanks to Paul Gillis, Pacific Systems Management Pty Ltd, AUSTRALIA.
Thanks to Robert Battilana, Franklin Mint, USA.
Change 19.162 JES3-only. Variable NETNAME, The JES3 DJC (Dependent JOB
BUIL3005 Control) Network ID, is now propagated into PDB.JOBS when
Sep 5, 2001 BUILDPD3 is used to create your JES3-PDB.
Thanks to Graham Cornwell, Donovan Data Systems, ENGLAND.
=Cruised from Nome, Alaska, south to St. Lawrence, St. Matthew, St.
=George in the Pribilofs to Chugulak, and thence west across all of the
=Aleutian Islands to Russia's Bering Island, Kamchatka Peninsula's
=Valley of the Geysers (pronounced "geezers" in Russian), and
=Petropavlovsk on the 340-foot Clipper Odyssey, with "birders" from the
=American Birding Association. Landings each morning via Zodiacs to see
=birds at sunrise, often second island landing in afternoon, phenomenal
=weather (while the Alaskan State wine is "When is this fog going to
=lift?", we had sun on every single day!). And evening lectures on the
=geology, flora and flauna! Saw over 100 bird species, including Steller
=Sea Eagles on their nest, 10 mammals (five whale species!), and bones
=of the extinct Steller Sea Cow. Fantastic naturalist experience,
=especially for this EE!
Change 19.161 MXG 19.03 only. Change DEBUG=1; to DEBUG=.; and those
VMACTNG "AFTER HEADERS _N_=" (harmless) notes won't be printed on
Aug 16, 2001 the SAS log.
Change 19.160 Support for type 42 subtypes 7 and 8 was revised; a six
VMAC42 byte filler is now skipped, the OFFCL calculation was
Aug 16, 2001 corrected, and S42FFN and SMF42CHN are now input variable
length, and converted and translated to be printable
under MVS or ASCII platforms.
Thanks to Richard Fortenberry, Mitsubshi Motor Sales of America, USA.
Change 19.159 While TYPEMBO tested just fine, the TYPSMBO member had
TYPEMBO a type _SDEMBO should be _SMBO, and the VMACMBO member's
VMACMBO definitions of _NMBO and _SMBO were obviously incorrect.
Aug 10, 2001
Thanks to David Bixler, FISERV, USA.
Change 19.158 Support for CISCO Works Blue ISM User SMF record creates
EXCISM01 twelve new datasets, one for each subtype:
EXCISM02 Dataset Description
EXCISM03 CISM01 CISCO ISM ROUTER/SWITCH CPU/MEM'
EXCISM04 CISM02 CISCO ISM CMCC(CIP) CPU/MEM'
EXCISM05 CISM03 CISCO ISM OSA CPU/MEM'
EXCISM06 CISM04 CISCO ISM TN3270 STATISTICS'
EXCISM07 CISM05 CISCO ISM INTERFACE PERF STATS'
EXCISM21 CISM06 CISCO ISM INTERFACE STATISTICS'
EXCISM31 CISM07 CISCO ISM PATH STATISTICS'
EXCISM41 CISM21 CISCO ISM REAL SERVER STATS'
EXCISM42 CISM31 CISCO ISM VIRTUAL SERVER STATS'
EXCISM66 CISM41 CISCO ISM FORWARDING AGENT STAT'
IMACCISM CISM42 CISCO ISM WILD CARD STATISTICS'
TYPECISM CISM66 CISCO ISM ISM EVENT LOG'
TYPSCISM This support is preliminary; only subtypes 01,05,06,66
VMACCISM are decoded and tested, and these issues have just been
VMXGINIT observed from the small data sample:
Aug 6, 2001 - The SYSTEM field in the CISCO SMF record is blank.
- There is an extra undocumented file at the end of
the '01' record, that looks like a percentage?
- Additional '06' fields are documented for FDDI, etc
that won't be decoded until they appear in data.
- The documentation shows 8 fields in the '06' record
after the "OE(" marker (UN,OE,CO,IR,RS,OBF,OBS,TR),
but there are only 7 data fields in the '06' record.
Thanks to Harvey Aviles, SSA, USA.
Change 19.157 The PDB.CICS dataset can be created by either ASUMCICS,
JCLPDB8 which always counts from CICSTRAN, or by ASUMCICX, which
JCLPDB6 will use PDB.ASUMUOW if it exists (i.e, if ASUMUOW was
Aug 6, 2001 both included and member IMACUOW updated to create obs in
PDB.ASUMUOW), but what is counted is quite different:
when PDB.CICS is built from CICSTRAN, it counts all CICS
transaction names separately, since each observation in
CICSTRAN is a separate "CICS" transaction, but if ASUMUOW
is built, it has summarized all of the CICS transactions
in one "Unit-of-Work" into one observation, with only the
"Real" transaction name of that UOW, and thus the counts
in PDB.CICS using ASUMCICX are counts of units-of-work,
not CICS transactions, and only the "Real" TRANNAME will
be in the PDB.CICS dataset built from ASUMCICX.
Thanks to Art Hunter, Penn Mutual Life Insurance Company, USA.
Change 19.156 -Using %VMXGRMFI(IMACWORK=NO) in your RMFINTRV member and
EXRMFINT defining fewer than the default workloads can cause many
VMXGRMFI notes NOTE: VARIABLE OTHnACTV IS UNITIALIZED one set for
Aug 6, 2001 each workload you didn't use, and all of those UNINIT
variables listed are actually created in PDB.RMFINTRV.
The problem was caused by the default LABEL statement in
EXRMFINT, which was there to support the earlier design
in which you defined the workloads in IMACWORK and their
labels in EXRMFINT. With the revised VMXGINIT design,
the labels in EXRMFINT are not needed in my default code,
and are now commented out, as an example if you are still
using IMACWORK=YES and want to change labels.
-MXG 19.03 only. Change 19.105 causes errors if %VMXGRMFI
arguments end with slash before the comma (mis-matched
DO;-END; pair). This change makes the final slash
optional.
Thanks to Nancy R. Brizuela, University of Wyoming, USA.
Change 19.155 Dataset CTLGVSAM, created by reading an exported Catalog,
VMACCTLG had unique variables missing because macros were spelled
Aug 6, 2001 wrong. Folowing _WCTLGVS /* CTLGVSAM */, the statement
after the label should have been _VCTLGVS _KCTLGVS to
match the CTLGVS (was mistyped as _VCTLGDS _KCTLGDS).
Thanks to Barry McQueen, Department of Defense, AUSTRALIA.
Change 19.154 IHDRxxxx exit members exist for each "INFILE" that MXG
IMACFILE reads from, and are taken after the record header or
IHDR110 sub-header, has been INPUT. They exist so that you can
IHDR110S use ID, SUBTYPE, SYSTEM, APPLID, SMFTIME, etc., in these
IHDRCIMS exits to control whether or not MXG creates observations,
IHDRDCOL primarily for ad hoc runs when you want to output just a
IHDREAGL little bit of the input. For example, IHDR110S for CICS
IHDRNTSM Statistics Segments lets you select by STID value to only
IHDRTMDB output to specific a CICxxxxx statistics dataset, and not
IHDRTMO2 waste temporary disk space with unwanted statistics.
IHDRTMV2 These IHDRxxxx members are not new, but this change adds
IHDRTPF a macro variable to each, so that you can alternatively
IHDRVMXA tailor these headers "instream", using this syntax:
IHDRTMDC %LET MACxxxx= %QUOTE( your code );
IHDRIMS instead of having to EDIT/SAVE of the IHDRxxxx member.
IHDRTIMS The IHDR members and their new MACxxxx macro variables:
Aug 2, 2001
IHDRxxxx Macro
Member Name Data Source
IMACFILE MACFILE SMF Record Header, ID, SUBTYPE, etc.
IHDR110 MAC110H CICS 110 Sub-Header, APPLID, etc.
IHDR110S MAC110S CICS 110 Statistics Sub-Sub, STID.
IHDRCIMS MACCIMH IMF/CIMS Record Header
IHDRDCOL MACDCOH DCOLLECT Record Header
IHDREAGL MACEAGH Eagle Header
IHDRNTSM MACNTSH NTSMF Record Header
IHDRTMDB MACTMDH TMON/DB2 Record Header
IHDRTMO2 MACTMOH TMON/CICS Record Header
IHDRTMV2 MACTMVH TMON/MVS Record Header
IHDRTPF MACTPFH TPF Record Header
IHDRVMXA MACVMXH VM/ESA, z/VM Record Header
IHDRTMDC MACTMCH TMON/DBCTL Record Header
IHDRIMS MACIMSH IMS Log Record Header
IHDRTIMS MACTIMH TMON/IMS Record Header
The MACFILE macro has existed for some time; IMACFILE was
the original name for the SMF File Header, but now all
new INFILE exit member names start with IHDR.
Thanks to MP Welch, SPRINT, USA.
Change 19.153 -NTSMF Process object record with NRDATA=27 is supported.
VMACNTSM -Records from Win2000 Servers with older NTSMF versions
Aug 1, 2001 for Indexing Service, Indexing Service Filters, and Site
Aug 3, 2001 Server Authentication Srevice had an unexpected instance
field, which is now expected, but not kept, as there is
no instance field with the current NTSMF version.
Thanks to Jim Quigley, ConEd, USA.
Change 19.152 Variable NCL, Net Capacity Load, the back-end space used
VMACICE is now created in ICEBRGSY and ICEBRGUT dataset (but the
Jul 31, 2001 ICEBRGUT records are generated only if you run a REPORT
SPACEUTILIZATION, daily, and have turned on subtype 7 in
SVAA or IXFP in SYS1.PARMLIB(SMFPARM), so using ICEBRGSY
which is always present is recommended).
Thanks to Rob Gibson, Centrelink, AUSTRALIA.
======Changes thru 19.151 were in MXG 19.03 dated Jul 30, 2001======
Change 19.151 If you use TEMP01/TEMP02/TEMP03 in a VMXGSUM invocation,
VGETENG a non-impacting Warning 413 may result, if those DDs were
VMXGSUM on tape devices that had not been opened. Our open to
Jul 27, 2001 determine the device type of your (optional) TEMPnn DD
Jul 30, 2001 caused the warning when the tape had not been opened.
Those TEMPxx parms were primarily needed before SAS V8
provided good multi-volume support, and are less needed
now, but as sequential format datasets on disk, they can
be striped and hardware compressed, and for VMXGSUM runs
with large volumes of data, they are still very useful.
This change eliminates the 413 warning by first looking
to see if the TEMPnn libname is already open, in which
case we will use its current engine, and if the TEMPnn DD
is not open, we will force the Sequential Engine for you,
and avoid the open that caused the warning. The TEMPnn
options are not used in any MXG VMXGSUM invocations.
Jul 30: Added GLOBAL to VMXGSUM and VIEW MXGENG.
Thanks to Mike Hoey, Ameren, USA.
Change 19.150 Example of TREND summarization for the ASUMCEC dataset,
TRNDCEC similar to TRND70PR trending of ASUM70PR for LPAR/MDF,
Jul 26, 2001 but TRENDCEC is a the hardware CEC/CPC level.
Thanks to Diane Eppestine, Southwestern Bell, USA.
Change 19.149 First 19.03 only. TNG support still had incorrect values
VMACTNG for STARTIME for some PLATFORMS, now corrected on all.
Jul 26, 2001
======Changes thru 19.148 were in MXG 19.03 dated Jul 26, 2001======
Change 19.148 Support for NTSMF V 2.4.2.11 and Windows 2000 changes to
VMACNTSM the SYSTEM and PROCESS objects, including new variables
Jul 26, 2001 for I/O activity at the process level:
Jul 27, 2001 IORDOPRT='IO READ OPERATIONS/SEC'
IOWROPRT='IO WRITE OPERATIONS/SEC'
IODTOPRT='IO DATA OPERATIONS/SEC'
IOOTOPRT='IO OTHER OPERATIONS/SEC'
IORDBYRT='IO READ BYTES/SEC'
IOWRBYRT='IO WRITE BYTES/SEC'
IODABYRT='IO DATA BYTES/SEC'
IOOTBYRT='IO OTHER BYTES/SEC'
READYTHR='READY*THREADS'
Revisions to PROCESS and UNTDISC made Jul 27, 2001.
Thanks to Jim Quigley, ConEd, USA.
Change 19.147 Invalid type 42 subtype 5 record caused INPUT STATEMENT
VMAC42 EXCEEDED RECORD LENGTH and/or DIVISION BY ZERO. This
Jul 26, 2001 record was overlaid after 20,500 bytes, with a dataset
name appearing where there should be no data set name!
Segments thru VOLSER DX0004 (starting at byte 20249) were
valid, but the segment for VOLSER DX0003 (at byte 20409)
contains offsets of S42VTVDO=7 and S42VTVXO=1, when those
offsets must be greater than the current column, or zero,
and subsequent fields are clearly invalid. A heuristic
circumvention based on those observed values will detect
and delete these bad records, while the site contacts IBM
for a correction to their invalid SMF 42-5 record created
by DFSMS 2.1
Thanks to M.J.H. Elbersen, RABOBANK, NL.
Change 19.146 -TNG records with (*) in their object name, such as the NT
FORMATS object "NWLINK IPS(*)(G)" saw the (*) and set TEXT='*'
VMACTNG instead of the expected TEXT='G', causing LENTEXT to be
Jul 25, 2001 missing instead of 16, and deleting that record with an
Jul 27, 2001 MXG note. Now, the scan knows to skip (*) when looking
for the (X) length field.
-Existing Format MGALFA only decoded single base-36 values
for TNG field lengths (1)=1, (A)=10, (Z)=35, but now two
position base-36 characters, (12)=38 are supported when
that value was found for an object length. Values to
(1Z)=71 are now decoded by MGALFA:
-The related tests LENTEXT LE 36 were revised to LE 35,
and a separate test for 36 LE LENTEXT LE 40 was added
due to (10)=36 taking one more position than (Z)=35.
-The revised MGALFA format should not have been used in
pre-9907 logic; the old format that stopped at (Z) did
not have values for (11), etc, so an old (12) was seen
as length 12, but the revised format now has (12)=38,
so even though nobody probably still is using the old
TNG format, I fixed it so my QA run with old and new
data still works.
-STARTIME was correct for the first group of records, but
it grew well into the future because it was not reset to
ORIGTIME at the start of each object's counter's input.
-STARTIME was still wrong in the first day's MXG 19.03,
but was corrected in VMACTNG internally dated Jul 27.
Thanks to Greg Jackson, National Life of Vermont, USA.
Change 19.145 Support for the Volume sections of type 42 subtype 11 XRC
EXTY42XV (Extended Remote Copy Session statistics) now create new
IMAC42 dataset TYPE42XV to track the read/write/update activity
VMAC42 at the VOLSER level. In addition, all duplicates were
VMXGINIT not being removed in TYPE42S2, but adding SMF42FBG (Cache
Jul 20, 2001 Structure Name) to MACRO _BTY42S2 removed all duplicates.
However, multiple observations from the same subtype 6
SMF record exist in TYPE42DS that were also not removed
by the NODUP sort. These multiples have different I/O
counts, but otherwise are identical, except that their
location in the record (S42JDDSO) is different, so it was
added to MACRO _BTY42DS to remove the duplicates if dupe
SMF records are read, but the two otherwise observations
from the same record will now have different S42JDDSO
values. If you discover why there are these multiples,
let me know and I'll update this text.
OBSERVATION COUNT CHANGE: TYPE42DS fewer obs.
Thanks to Mike Delaney, Pershing, USA.
Change 19.144 RMF Partition data report was updated to report on the
ANALRMFR communication devices. To get full comm reports using the
Jul 20, 2001 DEVICEC=40 parameter for commmunications, add 41 to get
the CTC adapters included.
Thanks to Joseph Rannazzisi, Salomon Smith Barney, USA.
Thanks to Jiann-Shiun Huang, CIGNA, USA.
Change 19.143 Candle did NOT correct the unsupported '20'x (instead of
VMACNAF the expected '01'x) value for the century "bit" in their
Jul 21, 2001 internal time stamps; they ONLY corrected the date part
in the SMF header field. The circumventions of Changes
18.025 and 15.211 were replaced with directly forcing the
century bit into their fields and then using an INPUT
function to convert the modified character field. This
circumvention may fail at the end of this century.
Thanks to Joe Faska, Depository Trust, USA.
Change 19.142 MXG 19.02 only. The SPIN logic did not keep SPINCNT, so
VMXGUOW the SPINUOW dataset continued to grow, as there are many
Jul 20, 2001 CICS transactions whose end we don't see until the region
is terminated, and the SPIN logic depends on SPINCNT to
recognize and output those type of events into ASUMUOW.
This error was not caught in our testing because of an
incorrect IMACUOW member in our tailoring library. Sorry!
This change won't be seen until the second day's run.
Thanks to Alan Lankin, Towers Perrin, USA.
Change 19.141 The new type 74 subtype 7 FICON Director record has a new
VMAC74 option in ERBRMFxx of FCD/NOFCD that causes creation of
Jul 18, 2001 that subtype.
Change 19.140 The SASGRAPH argument was not UPCASE'd, causing test to
ANALCNCR fail if you typed your SASGRAPH=yes in lower case.
Jul 18, 2001
Thanks to Ian Davies, Independent Consultant, CANADA.
=Attended the superb SAS 25th Anniversary Party in Raleigh, NC, with
=7,200 SAS employees and families, with two bands popular in 1976:
= The Village People and KC and the Sunshine Band!
Change 19.139 An SMF 116 with invalid QWHS segment length of 108 bytes
VMAC116 (110 is expected) caused INPUT EXCEEDED STOPOVER error.
Jul 13, 2001 The QWHS segment it self was trashed, with invalid data
values for CAID, CCV, CCN, and XTYP, and the 22-byte
accounting segment was only 20 bytes. This change only
detects the short segment and prints an error message on
the SAS log. This note will be updated if an APAR is
found/developed to correct the IBM error in the record.
Thanks to Mat Elbersen, RABOBANK, THE NETHERLANDS.
Thanks to Ian Davies, Independent Consultant, CANADA.
Change 19.138 Local variables ENTEJECT caused a warning because it did
GRAFTAPE not exist, and was not referenced in sample reports, so
Jul 13, 2001 it was removed from the member.
Thanks to Ian Davies, Independent Consultant, CANADA.
Change 19.137 IMF Program record's variable FLGUESQL was incorrectly
VMACCIMS input @79 when that field is located @80. It and a few
Jul 13, 2001 other flag variables were also formatted $HEX2.
Thanks to Sergio Fastella, ALITALIA, ITALY.
Change 19.136 -TPF datetimestamp variables are written in GMT zone, but
VMACTPF MXG now converts them all to your local time of day, by
VMXGTPFI using the DB/DE records, which are written first in each
Jul 11, 2001 file, containing the GMT datetime and a local time and
Jul 12, 2001 local date (but its '01JUL' with no year, so conversion
from GMT to local has special logic to deal with JAN01
and DEC31 data to set the local year correctly!
-Variable SHIFT is now created in all datasets that have
STARTIME, that is, all interval datasets. Your IMACSHFT
definitions are used with STARTIME to set the shift of
each observation.
Change 19.135 MXG 19.01 and 19.02, IMS Log processing. Change 19.061
ASMIMSL5 was incorrect, causing invalid time stamp values. The
ASMIMSL6 asterisk in column one that was added by that change:
Jul 11, 2001 * BO DROPMAP NONRECOV Change 19.061
is removed by this change so the statement now reads:
BO DROPMAP NONRECOV Change 19.135
Thanks to Rita Bertolo, Canadian Pacific Railway, CANADA.
Change 19.134 Documentation only. When I/O delay is NOT included in
VMAC7072 velocity in your WLM, MXG's calculated VELOCIOD variable
Jul 9, 2001 estimates what the velocity would be if I/O delays, in
R723CIOD/PCTDLIOD, and WLM-managed batch initiator delay,
in R723CTDQ/PCTDLTDQ, were both included. Both impacts
are in the one VELOCIOD variable, because I didn't think
more velocity estimate variables were needed for the now
several possible combinations, and because you could
always use the EXTY72GO exit to recalculate your own
estimate if really needed.
My VELOCIOD won't match either of RMF report's values in
I/O PRTY or INIT MGMT; IBM calculations assume only the
one impact, and also say that if R723VELI is not on, that
both I/O useage and I/O delay are not included!
When I/O delay and/or Init delay are enabled in your WLM,
i.e., when R723VELI='Y', there is no discrepancy, because
VELOCITY and VELOCIOD are equal and correct.
Thanks to Steve Dyck, CDS, USA.
Change 19.133 Some JCL Examples for Assembly and LinkEdit of programs
DOC written in IBM ASM still had PGM=IEV90 and PGM=IEWL for
Jul 3, 2001 the Assembler and Link Editor, but Carl, an ASM Guru at
SAS, pointed out that the more likely names in use in
this millennium would be PGM=ASMA90 and PGM=HEWL.
Thanks to Carl Meredith, SAS Institute, USA.
Change 19.132 Support for both VM/ESA V2.4 and z/VM V3.1. The V2.4
VMACVMXA changes were added first, then the 3.1 LIST1403 was used
Jun 30, 2001 to update those changes, which are listed separately in
this change text.
Some of the new numeric variables may be accumulated and
will need to be DIF'd, so you should verify their values
before using!
These new variables were added in the Jun 30 change:
Dataset New Variables
SYTSYP: PLSDGUCT PLSXITCT
SYTPRP: PFXSPINT PFXSPINC
SYTRSG: TCMMIDSZ TCMMAIN TCMMNMIN TCMMNMAX TCMMNDL TCMSTLMN
SYSSCMAV
SYTSCG: SRMTOTST SRMWSSDL SRMWSSD1 SRMWSSD2 SRMWSSD3 SRMLLCNT
SRMCONLL SRMATOD SRMATOD2 SRMWTCPU CALSLKCT CALSLKTM
SYTUWT: CALLLIST
SYTXSG: TCMXIDSZ TCMXSMIN TCMSTLXS TCMAVGAG HCPSTPXB
MTRSYS: CALADMF VRFSG SYSTEM SYSCKVOL SYSWMVOL
MTRPRP: PFXTYPE CALUDED
MTRDEV: CALTHROT RDCRCUC RDCOBRCO RDEVSER THRDLYS THRIORTE
MTRUSR: VMDBYVAL VMDMXSHR
MTRSCH: SRMXPCTG
STOSHR: ASCCTXBK
USEACT: IUCTOTCN IUCMXCN VMDMXSHA VMDLIMTH VMDTHRCT
USEINT: HFLLIST HFPGACT VMDSLCNT
PRCPRP: CALUDED PFXTYPE HFUSERM
IODDEV: THRDLYS SCMCQTIM
IODCAD: CALSSS2
Thanks to Pat Curren, SuperValu Inc, USA.
Change 19.131 Validation of SOL260S TNG data found several minor errors
VMACTNG that have been corrected and MXG's values now matches the
Jun 29, 2001 Excel spreadsheet created by TNG.
Thanks to Bill Shanks, SEMA, ENGLAND.
Thanks to Paul Hargreaves, SEMA, ENGLAND,
Change 19.130 IBM has redefined type 103 variable TIMEWRIT as the time
VMAC103 since the last SMF write, now called SMFRecordingInterval
Jun 29, 2001 in IBM documentation, so it's label was clarified.
Thanks to Dave Cogar, Computer Associates, USA.
Change 19.129 Using UTILBLDP with BUILDPDB=NO option printed warning:
UTILBLDP APPARENT SYMBOLIC REFERENCD IDFLAG NOT RESOLVED
Jun 29, 2001 because IDFLAG was not initialized in that loop. Insert
%LET IDFLAG=NO;
after the existing %LET DE2FLAG=NO; in that loop.
Thanks to Ian Davies, Independent Consultant, CANADA.
Change 19.128 Running MXG under unix hit another lower case problem:
VMXGINIT ERROR: File does not exist /mxg/sourclib/AAAAAAAA.SAS
Jun 28, 2001 Under unix SAS, %INCLUDE SOURCLIB(MEMBER) looks for file
INSTALL "member.sas", while INFILE SOURCLIB(MEMBER) looks for
Feb 4, 2003 "member.dat", both in lower case only, so all MXG source
files must be lower cased on unix. It turns out that
when the MEMBER name has no extension, unix SAS looks
only for lower case file name, but if ANY extension name
is used (MEMBER.EXT), SAS instead looks for a file name
in the case of the source code, and the MXG statement
that was added that caused the error is in upper case:
INFILE SOURCLIB(AAAAAAAA.SAS)
One earlier fix (actually, one still discussed in INSTALL
member's instructions until Feb, 2003!) was to uppercase
the source file to AAAAAAAA.SAS, because that is the only
file in MXG that is read with an INFILE syntax. Or, you
could have lowercased the VMXGINIT member, or I might be
able to modify the MXG install process for unix to UPCASE
that one file.
But instead, the %LOWCASE macro function was inserted in
the INFILE statement for ASCII (i.e. unix/linux/WINDOWS):
INFILE SOURCLIB(%LOWCASE(AAAAAAAA.SAS))
which will cause unix to look for aaaaaaaa.sas, and you
don't have to change anything to run MXG under unix.
This also works under Windows because file names there
are not case sensitive.
Note: Don't try this under EBCDIC systems; using MVS
syntax of INFILE SOURCLIB(%LOWCASE(AAAAAAAA));
fails with a JFCB error, because MVS still can't
handle lower case DDnames.
Feb 4, 2004: The INSTALL member was revised, telling
you to leave the aaaaaaaa.sas filename in lower case.
Thanks to Chris Weston, SAS ITSV Development, USA.
Thanks to Mark Rothschild, Caremark, USA.
Change 19.127 An obscure exposure in VMXGSUM is corrected; if you had
VMXGSUM both INTERVAL= and NORMn= arguments, some variables could
Jun 28, 2001 be missing in the output dataset. None of the MXG uses
of VMXGSUM had both, but the ASUMCACH enhancement added
the INTERVAL= to an existing NORM1= argument, uncovering
the error. Correction was to relocate a code segment.
Thanks to Chuck Hopf, MBNA, USA.
Change 19.126 DFHSM 1.4 via PTF and standard in DFHSM 1.5 and later,
VMXGHSM two new variables for stacked volumes (field sequence
Jun 28, 2001 number DGNFLSEQ, file block ID DGNFBID) were added to the
DGN dataset. A reserved area was used for the two new
fields, so the IBM change is COMPATIBLE.
Thanks to Wanda Prather, Johns Hopkins Applied Physics Lab, USA
Change 19.125 Support for TPF releases PUT08, PUT10, and PUT12, which
VMACTPF inserted data fields incompatibly in several records.
VMXGTPFI The major changes were internal, to add the many new
Jun 27, 2001 variables for the 9th thru 16th Instruction Streams into
Jun 29, 2001 TPFSX dataset, and two new variables in dataset TPFDX.
Jul 10, 2001 Variable SXTWCSPR was dropped from TPFSX dataset and the
VMXGTPFI was revised to not reference that variable.
Internal mapping formats for TPFDR & TPFDH now use CPUID
so that TPF data from multiple systems can be processed
by concatenation of the input files. New variable SYSTEM
is created in dataset TPFINTRV; you must update the table
in your member IMACTPF to map which CPUIDs are in which
system to populate variable SYSTEM. There still is one
observation per CPUID per interval in TPFINTRV dataset,
but if you update that table, variable SYSTEM will exist
so that you can use it in subsequent summarization.
Jul 10: Added ZDATE to TPFINTRV.
Obs with FFCCHHR='00'X are now OUTPUT in TPFFF;
they are Virtual File Access and should not have
been deleted.
Several misspellings of 9-G variables corrected.
Thanks to Robert Wilcox, Sabre, USA.
Thanks to Jim Gilbert, Sabre, USA.
Change 19.124 -Adding the processing of SOLVE SMF to BUILDPDB caused
VMACLDMS WARNING: VARIABLE YYYY HAS ALREADY BEEN DEFINED AS NUM...
VMACMDF Change temporary variable YYYY to YYYYCH in two places to
VMACSOLV eliminate the conflict and the warning message.
Jun 28, 2001 -Changed CONDCODE to CONDCODH in VMACLDMS, to avoid a
conflict, and because it is the Highest CondCode value.
-Changed temp variable DOMFLAGn to DOMDFLGn in VMACMDF.
-This change was precipiated by the VMACSOLV error, but
the MXG QA stream should have caught this conflict of
variable types, because ANALCOMP is now run to compile
simultaneously all SMF-reading MXG programs to find any
such conflicts. Why were all three not caught then? In
fact, this error was caught by the April 5 QA run, but it
took this error to remind me to use that enhancement to
make these corrections!
Thanks to John Temme, Department of Defence, AUSTRALIA.
Change 19.123 Enhancement to ASUMCACH, for DASD Cache and DASD I/O.
ASUMCACH Variables that identify the control unit are added using
Jun 28, 2001 a PROC FORMAT as a table lookup. Summarization is now
forced to QTRHOUR level (so that if there are multiple
systems where the TYPE74 and TYPE74CA dataset times are
not exactly aligned, we will now always put the data
together. And additional variables are created to allow
better downstream reporting capabilities. The SORT order
of the output is now SYSPLEX STARTIME DEVNR VOLSER, so
you can examine the data by SYSPLEX.
Thanks to Chuck Hopf, MBNA, USA.
Change 19.122 Documentation of an example use of the EXPDBSPN exit.
EXPDBSPN The site had used IEFACTRT exit to put account info for
Jun 26, 2001 STCs in type 30_4 and 30_5 SMF records in PGMRNAME, but
BUILDPDB keeps PGMRNAME only from TYPE26 and TYPE30_1,
and their exit was after the type 30-1 was created.
Adding variable PGMRNAME to the Keep list for 30_5 did
now work, because the MXG MERGE statement has TYPE30_5
first, and then TYPE30_1 (as required by BUILD005 logic),
causing the blank value in TYPE30_1 for these STCs to
overwrite the non-blank PGMRNAME in TYPE30_5. For this
site's specific SMF modifications, the solution was to
use the EXPDBSPN exit, which is taken just before the
"Big Merge" (see member DOCPDB for more details than you
probably want to read), and in their exit code, add the
PGMRNAME from their TYPE30_5 dataset into the TYPE30_1
dataset, and then the "Big Merge" logic works just fine.
This example is the code they inserted into EXPDBSPN:
DATA TEMP30_5 (KEEP=READTIME JOB JESNR PGMRNAME);
SET TYPE30_5;
DATA TYPE30_1;
MERGE TYPE30_1 (IN=IN1) TEMP30_5 (IN=IN5);
BY READTIME JOB JESNR;
IF IN1 THEN OUTPUT;
and they also had to insert:
%LET ADD30U5=PGMRNAME;
before their %INCLUDE SOURCLIB(BUILDPDB); statement, to
add the variable PGMRNAME to be kept in TYPE30_5 inside
the BUILDPDB logic.
Thanks to Duncan Walker, Experian Limited, ENGLAND.
Change 19.121 The macros did not UPCASE the DDNAME, so it returned an
VGETENG incorrect value if you used lower case DDNAME in the MXG
VGETOBS macro invocation.
VMXGENG
Jun 26, 2001
Change 19.120 IBM APAR OW49536 documents new bit which is now variable
VMAC7072 LCPUVARY='Y' in dataset TYPE70PR if this LPAR was varied
Jun 26, 2001 online during this interval.
Change 19.119 New VMXGSUM option OUTVIEW=YES (default is OUTVIEW=NO)
VMXGSUM will cause VMXGSUM's output dataset to be a VIEW instead
Jun 25, 2001 of a dataset. We will use this internally so MXG will
be faster & cheaper when we can pass the output from one
VMXGSUM execution into another data step (or VMXGSUM!).
Note that if you use OUTVIEW=NO, the View will have the
same name as the OUTDATA= that you specified, but, since
it is a VIEW, that dataset will NOT exist when VMXGSUM
finishes, and if you do not reference the VIEW after it
is created, it will not physically exist as a dataset.
Thanks to Chuck Hopf, MBNA, USA.
Change 19.118 Test for &SASVER EQ 6 was changed to &SASVER GE 6, but
ANALDB2R luckily, running under Version 8 produced the correct
Jun 25, 2001 reports. The test will bypass a data step when under SAS
V6+ (by using the INHERIT option), but executing the data
step under V8 still worked correctly.
Thanks to Chuck Hopf, MBNA, USA.
Change 19.117 IMS Log processing with TYPEIMS7 (resources, no response)
TYPEIMS7 warning messages *** LCODE 35X NOT OUTPUT for ENQFLG=0C
VMACIMS and FLAG2=40x or 60x are now output to IMS35O dataset.
Jun 23, 2001 The warnings had no impact on the IMS0708 dataset that is
create by the TYPEIMS7 program, since only 07 and 08 log
records are used in IMS0708.
In addition, the MXG logic to set NMSGPROC=1 for 08-only
matches caused the total NMSGPROC in IMS0708 to be more
that the true NMSGPROC in the 07 reocrds, so NMSGPROC=0
is now set for the 08-only matches in TYPEIMS7.
And IMSQBLDN is now a positive number; it was initialized
to -34, but that RETAIN statement was corrected.
Thanks to Rita Bertolo, Canadian Pacific Railway, CANADA.
Change 19.116 New %MACROS allow you to read many PDB libraries for one
VGETDDS MXG dataset (SET WEEK1.JOBS WEEK2.JOBS WEEK3.JOBS), and
VMXGSET only those DDnames that are found will be used! You can
VMXGINIT control, by the DDNAMES (or LIBNAMES) in your JCL, which
Jun 22, 2001 PDB libraries will be read, but you do have to change the
SET statement in your SAS program! Two %MACROS are used:
-%VGETDDS - "Get" ddnames:
%VGETDDS(DDNAMES=WEEK: PDB: ALLWEEK);
You tell VGETDDS the DDnamePrefixes and specific DDnames
that you want to use. That example will find all DDnames
starting with WEEKn, PDBn, and the DDnames MON TUE WED
THU FRI SAT SUN that are SAS data libraries, and only
those DDnames will then be read by the second macro.
-%VMXGSET - Use in place of your SET statement:
DATA COMBINE.JOBS;
%VMXGSET(DATASET=JOBS,DEFER=YES);
RUN;
You tell VMXGSET what MXG dataset (aka table) you want to
read, and if any of your datasets are on tape media, you
can specify DEFER=YES (SAS V8+ only) and the OPEN=DEFER
option will be on the SET statement that we construct,
causing each individual dataset in the SET statement to
be opened, read, and closed, left to right, so you use
UNIT=AFF in your JCL, and need only one tape drive to
read all of your datasets!
The only caution with DEFER=YES is that it cannot be
used if there is a BY statement with %VMXGSET, because
a BY statement opens all datasets in a SET statement.
So to read five PDB libraries, PDB1-PDB5, you would have
// EXEC MXGSASV9
//PDB1 DD DSN=YOUR.PDB(0),DISP=SHR
//PDB2 DD DSN=YOUR.PDB(-1),DISP=SHR
//PDB3 DD DSN=YOUR.PDB(-2),DISP=SHR
//PDB4 DD DSN=YOUR.PDB(-3),DISP=SHR
//PDB5 DD DSN=YOUR.PDB(-4),DISP=SHR
//COMBINE DD DSN=YOUR.OUTPUT.PDB,DISP=(,CATLG)....
//SYSIN DD *
%VGETDDS(DDNAMES=PDB:);
DATA COMBINE.JOBS;
%VMXGSET(DATASET=JOBS);
... rest of your subsetting logic ...
More details.
You would execute %VGETDDS(DDNAMES=....); once to build
the DDnames, and then execute a DATA step that executes
%VMXGSET(DATASET=....) for each data set to be read.
(While not likely, you can also execute %VGETDDS multiple
times).
Special values exist for %VGETDDS's DDNAMES= argument:
CCCCCCCC - 1-8 char, specific DDname (all characters)
CCCCCCnn - 1-7 char, final 1-2 numeric - scan CCCCCC1,
CCCCCC2 .. until an CCCCCCn+1 is not found
use CCCCCC1 to CCCCCCn DDnames
ALLWEEK - SUN MON TUE WED THU FRI SAT DDnames
Note: If there is more than one tape dataset, and you
use OPEN=DEFER and UNIT=AFF so that only one tape
drive is needed, there will be two mounts of each
tape dataset's first volume: one to recognize it
is a PDB, and, because UNIT=AFF will dismount the
first to recognize the second, there will be the
re-mount of the first dataset when the read
begins. Of course if your tapes are in a VTS,
there is no actual second physical mount, but you
will see both of the mounts on the SYSLOG.
Currently, an arbitrary limit of 99 DDs can be used in
the ultimate SET statement that results.
Even though references are mostly to MVS DDnames, the
new macros work also work on ASCII SAS platforms.
-VMXGINIT was updated to GLOBAL the VGETDDS name.
-HOWEVER: PRIOR TO 2005, there was a serious problem
in that some LIBNAMEs could have been missed by VGETDSN,
but only if the Data Library were controlled by HSM, and
only if you were missing an IBM Patch. That should not
now be a problem, but you can read the full details in
the text of (old) MXG Change 23.244. (Updated 2009).
Thanks to Chuck Hopf, MBNA, USA.
Thanks to Rick Langston, SAS Institute, USA.
Thanks to Jim S. Horne, Lowe's Companies, USA
Change 19.115 You can disregard these confusing SAS NOTES:
None NOTE: DATA STEP VIEW SAVED ON FILE WORK.MXGSUM1.
Jun 21, 2001 THE ORIGINAL SOURCE STATEMENTS CANNOT BE RETRIEVED FROM
A STORED DATA STEP VIEW NOR WILL A STORED DATA STEP VIEW
RUN UNDER A DIFFERENT RELEASE OF THE SAS SYSTEM OR UNDER
A DIFFERENT OPERATING SYSTEM.
PLEASE BE SURE TO SAVE THE SOURCE STATEMENTS FOR THIS
DATA STEP VIEW.
These notes are because MXG now uses VIEWs where possible
to eliminate I/Os, but the "source" is already in your
MXG Source library, so there is nothing to save or do.
Thanks to Freddie Arie, Texas Utilities, USA.
Change 19.114 RMF type 74 subtype 5 (Cache Subsystem) "broken" records
VMAC74 cause the same "INPUT STATEMENT EXCEEDED" error that was
Jun 21, 2001 seen with subtype 4. See the extensive discussion in the
text of Change 17.398. IBM RMF Development has agreed to
create only 'self-contained' records (and they may well
have done so, as this particular RMF record was written
by SP5.1), but this change replaced the statement:
IF SMF745XN GT 0 THEN DO;
with this replacement statement:
IF NDVCNT LE SMF745XN THEN DO;
so that MXG will only look for Extension sections when
they exist in the first "broken" record.
In this instance, the first record had 254 Device Data
Sections, but only 11 Device Data Extension Sections
(i.e., for the first 11 devices). A second SMF record
contains the remaining 243 Extension Sections, but there
is no Device Section with which to match them, so they
are never input. This change prevents MXG from INPUTing
a non-existent extension section, but that will cause
all of these variables to have missing values in TYPE74CA
when a broken record is processed:
R745XDVN /*DEVICE*NUMBER*- SAME AS DEVN */
RSV /*R745XRSV*LOWER*IO*MILLISEC*/
DCTC /*XCTC*DEV CACHE TRKS CONFIGED*/
DCTR /*XCTR*DEV CACHE TRKS REMOVED */
DVRD /*XVRD*DEV READS*BY CU*/
DVRH /*XVRH*DEV READ HITS*BY CU*/
DVWR /*XVWR*DEV WRITES*BY CU*/
DVWH /*XVWH*DEV WRITE HITS*BY CU*/
TSRR /*XSRR*TRKS*STAGED*FOR RAID RE*/
SFRD /*XFRD*TRKS*READ*FROM SIDEFILE*/
CWCC /*XWCC*CONCUR*COPY*CONTAM*WRIT*/
PPRC /*XPRC*PPRC*WRITE*COUNT*/
The MXG change now also protects the LN/RN/1N/VN INPUTs
in case those segments are in a second record.
Thanks to MXG/ITSV Technician, Promise Co. LTD, JAPAN.
Change 19.113 Several examples were revised; some caused errors and the
NEWUSER others were updated to be clearer.
Jun 20, 2001
Thanks to Lary Nova, COMSI, USA.
Change 19.112 PDB.CICINTRV dataset can contain negative minimum values
VMXGCICI or missing values, when there are no INT (Interval) CICS
Jun 20, 2001 statistics records, i.e., when there are only 'EOD' data.
First, if there are no 'INT' records, and you request the
default INTERVAL=HALF-HOUR for PDB.CICINTRV, you will get
unexpected results - I can't create intervals where there
are not, so you must request INTERVAL=EOD in CICINTRV.
But even if you specified INTERVAL=EOD, there was still
an error in the logic in VMXGCICI, because in each of the
processing code for these datasets ('suffixes'):
DL1 DL3 DBU PGG IRC DMR FEP FEC FET JCR LDR LS1 LS3
SDR SMD SMT TC1 TDR XMC USG XMG XMR
a statement IF FIRST.APPLID THEN DELETE; existed that
could cause those datasets to be not included in the
PDB.CICINTRV (so their variables would be missing).
This change removed that code from VMXGCICI.
Additional internal documentation note:
These yyy's did not have the DELETE statement:
TC TSR DMG VT AUT LDG DTB TCR DQR DQG TSQ
DS ST FCR M TDG SDG SMS AUS CO1 CO3 CON,
These yyy's are not currently used in VMXGCICI:
CSF6/7/8/9, D2G,D2R,LGR,LSG,NCS4,NCS4,NQG,
SOR,XQS1/2/3.
Thanks to Sally Weber, Washington Mutual, USA.
Change 19.111 Support for DFSMS/RMM data in MXG is confusing, because
VMACEDGR IBM has similar data in different formats that can be
VMACEDGS written to SMF or dumped with IBM's EDGHSKP utility in
Jun 20, 2001 two different formats. This is documentation only.
1. MXG's "EDGSxxxx" processing:
RMM can create two SMF records with different SMF IDs,
so MXG has two separate macros to define the SMF record
numbers your installation told rmm to use:
_IDEDGSU for the "Security" record, one subtype,
populates dataset EDGSSECU if found,
_IDEDGSA for the "Audit" record, many "subtypes":
EDGATYPE='C' populates EDGSAREC, only from
SMF records, but the "Audit" record also has
all of the rmm control records subtypes with
EDGATYPE=D/K/O/P/E/F/U/R/S that populate the
EDGSVREC,DREC,KREC,OREC,PREC,RREC,SREC,OVOL
EDGSPVOL datasets.
MXG's members TYPEEDGS and TYPSEDGS will read the infile
"SMF" and create all of the EDGSxxxx datasets.
But the IBM utility EDGSKIP can create a Control Backup
flat file from the rmm Control file (EDGSKIP with BACKUP
option), and that flat file is in almost-SMF-format that
contains the same Audit subtypes, so the same EDGSxxxx
datasets can be crated from either SMF records or the
Control Backup file. Because of slightly different input
format, two different members are needed in MXG, but they
both create all of the EDGS datasets, which will be
populated with observations when those subtypes are read
TYPEEDGS - Reads Infile "SMF" to create "EDGS" datasets
TYPEEDGB - Reads Infile "LOGSMF" from Backup option to
create "EDGS" datasets.
2. MXG's "EDGRxxxx" processing:
But you can also run EDGHSKP to Extract instead of Backup
(EDGSKKIP with RPTEXT), and that creates a flat file that
is physically different in record layout, but it contains
almost all of the same record subtypes. Unfortunately, I
did not recognize the similarities, so MXG dataset names
are EDGRxxxx, and different variable names are used:
TYPEEDGR - Reads Infile "EDGHSKP" from Extract option to
create "EDGR" datasets.
This table should identify which MXG datasets are similar
from these multiple possibilities:
Type "EDGS" process "EDGR" process
- EDGSSECU SMF - Security does not exist
C EDGSAREC SMF - Activity does not exist
D EDGSDREC Data Set EDGRDEXT
K EDGSKREC Vital EDGRKEXT
O EDGSOREC Owner EDGROEXT
O EDGSOVOL ", per volume does not exist
P EDGSPREC Sftw Product EDGRPEXT
P EDGSPVOL ", per volume does not exist
E/F/U EDGSRREC LIB Shelf Location EDGRREXT
R/S EDGSSREC Storage Loc Shelf EDGRSEXT
V EDGSVREC Volume EDGRVEXT
Thanks to Dale Haug, Philip Morris, USA.
Change 19.110 New CICSTRAN variables BARSPACT and BATIAECT were wrongly
VMAC110 spelled BARACTCT and BADFTECT, but are now corrected to
Jun 19, 2001 agree with the IBM field names.
Thanks to Gary L. Keers, Indiana Power & Light, USA.
Change 19.109 ACCOUNTn variables in TYPE33 APPC SMF records are blank
VMAC33 if the TP profiles specify TAILOR_ACCOUNT(YES) and the
Jun 19, 2001 RACF WORKATR account code is not populated. Specifying
TAILOR_ACCOUNT(NO) corrected that problem, but caused MXG
to set READTIME to a missing value because these lines:
JOB=RACFUSER;
READTIME=REQDTIME;
were executed when MXG found both a TP usage section and
an accounting section in the type 33 SMF record, i.e.,
only when TAILOR_ACCOUNT(NO) is specified. When YES is
specified, there is no accounting section in the SMF
record. Those lines were inserted only to suppress a SAS
"UNINITIALIZED VARIABLE" note, back when there was no JOB
name nor READTIME in the type 33 record, so that the MXG
IMACACCT member could be used to decode the ACCOUNTs, but
as both JOB and READTIME are now input in the VMAC33
member, that protection is unneeded, and its unintended
consequence, this error, is eliminated by deleting them.
Thanks to Walter Medenbach, IBM Global Services, AUSTRALIA.
Change 19.108 MXG output only one observation per SMF 108 subtype 2/6
VMAC108 record, because multiple sections were not expected, but
Jun 13, 2001 as they are now known to exist, many observations that
Jul 9, 2001 were not output are now created:
Subtype 2: 513 records, 10487 observations (now)
Subtype 6: 527 records, 71592 observations (now)
Additionally, variables DOMRVN and DOMPVN are now kept in
each subtype dataset (to identify version changes).
Jul 9: SM180UDO re-spelled as SM108UDO.
OBSERVATION COUNT CHANGE: TYPE1082 more obs.
OBSERVATION COUNT CHANGE: TYPE1086 more obs.
Thanks to Wolfgang Vierling, Allianz, GERMANY.
Change 19.107 New exit member EXTPFINT for the TPFINTRV dataset is now
EXTPFINT added, so that new variables can be created in TPFINTRV.
VMXGTPFI See comments in the exit member.
Jun 12, 2001
Thanks to Jim Gilbert, Sabre, USA.
Change 19.106 Archaic VMACIMS member had incorrect IMSRECNO because the
VMACIMS statement LOCRECNO=LEN-3; was missing for three IMS 5.1
Jun 11, 2001 code segments for the 35x log record (which is not used
by the TYPEIMS7 program, which is now the only user of
the VMACIMS member, and it doesn't use the 35x records).
Thanks to Siegfried Trantes, IDG Informationsvararbeitung, GERMANY.
Change 19.105 -SU_SEC variable is now kept in 8 bytes, because the new
UTILRMFI larger values can loose some low decimal digits in 4.
VMAC7072 For example, a Z-series 5-way has SU_SEC=10540.1845, but
VMXGRMFI that was truncated in 4 bytes to only SU_SEC=10540.1818,
Jun 11, 2001 so the magnitude of the truncation is small, only .0027.
Jun 21, 2001 -The original implementation of VMXGRMFI/UTILRMFI for WLM
required blanks between the parameters of the WORKnn=
operands of VMXGRMFI, causing confusion and errors. Both
members were revised to now tolerate blanks, but they are
no longer required. The / character still is required as
a delimiter to positionally identify the operand.
-Use of both KEEPxxx and DROPxxx VMXGRMFI arguments is not
supported; now you will get a USER ABEND 1913 if you try.
Thanks to Larry Nova, TransAmerica Commercial Finance, USA.
Change 19.104 -TYPE72GO variables VELOCITY/VELOCIOD/VELOCCPU were
VMAC7072 propagated into subsequent periods in the same SMF record
VMXGRMFI if there was no activity in those subsequent periods.
Jun 11, 2001 Now, all are set to missing if they cannot be calculated.
-Temporary dataset WORK.RMF72DS (built in VMXGRMFI) is now
deleted, as it should have been, for housecleaning.
-Comment references to NORM70=YES were removed, as that
normalization is now automatically performed for all the
variables in R70NRM list. NORM70 was never needed.
Thanks to Shantha Peetham-Baran, Cap Gemini Ernst & Young, ENGLAND.
Change 19.103A The default DDname of "PDB" in BUILDPDB can be changed by
VMXGINIT re-invocation of the %VMXGINIT macro in your //SYSIN.
Jun 11, 2001 If you want to write directly to the "MON","TUE",etc.,
'day-of-week' dataset and not have a "PDB" ddname, you
can use a DATA step to create the name of "Day-of-Week"
in a macro variable &DAY, and then use that macro as the
default value instead of "PDB":
DATA _NULL_;
DAY=UPCASE(PUT((TODAY()-1),WEEKDATE3.)); /*variable*/
CALL SYMPUT('DAY',DAY); /*macro variable*/
RUN; /*force evaluate*/
%VMXGINIT(DEFAULT=&DAY); /*invoke*/
%INCLUDE SOURCLIB(BUILDPDB.....);
The change made in member VMXGINIT was cosmetic; a flag
for first-time is now used to change the text of the note
printed on the SAS log to "RE-INITIALIZED" (and the new
DEFAULT value is printed) when VMXGINIT is re-executed.
Thanks to Derek Twist, CSC, AUSTRALIA.
Change 19.103 Support for StorageTek VSM NCS 4.0 ("HSC") enhancements
FORMATS for subtypes 13, 14, 18, and 19 add new variables, but
VMACSTC the record changes are INCOMPATIBLE (STCnnTIM is now 4
Jun 11, 2001 bytes, vice 8, in different format), so this MXG change
is required for that version's SMF records. New things:
Dataset Variables Description FORMAT
STCVSM13 STC13RCI RECALL INDICATOR $MGSTCRC.
'01X:MOUNTED WITHOUT A RECALL'
'02X:MOUNTED AFTER A RECALL'
STC13MGT MANAGEMENT CLASS
STCVSM14 STC14MGT MANAGEMENT CLASS
STCVSM18 STC18MT MIGRATE REQUEST TYPE $MGSTCMT.
'01X:AUTO'
'02X:DRAIN'
'03X:DEMAND'
'04X:RECLAIM'
'05X:CONSOLIDATE'
'06X:EXPORT'
STC18MGT MANAGEMENT CLASS
STC18SCL STORAGE CLASS
STCVSM19 STC19RT RECALL REQUEST TYPE $MGSTCRT.
'01X:AUTO'
'02X:DRAIN'
'03X:DEMAND'
'04X:RECLAIM'
'05X:CONSOLIDATE'
'06X:EXPORT'
STC19MGT MANAGEMENT CLASS
STC19SCL STORAGE CLASS
Thanks to Martin Jensen, JyskeBank, DENMARK.
Change 19.102 Variable CPCMODEL ('ZX7' or 'Z77' for example) is added
ASUM70PR to PDB.ASUM70PR and PDB.ASUMCEC datasets to identify what
Jun 10, 2001 is the exact model of the platform. This is important if
a Z-series machine is an 'upgrade' from a G6, as the CPU
Serial Number does not change, even though the physical
hardware does.
Thanks to Chuck Hopf, MBNA, USA.
Change 19.101 Variable PGMRNAME was removed from the KEEP= list for the
BUILD005 TYPE30_4 dataset in the BUILDPDB logic. If a job had no
BUIL3005 Purge record, the always-blank-PGMRNAME-in-TYPE30_4 would
Jun 10, 2001 blank out the PGMRNAME from the TYPE30_1 dataset.
See Change 19.194.
Thanks to Duncan Walker, Experian, ENGLAND.
Change 19.099 Syntax for Goal Mode no longer requires the -99 place
VMXGRMFI holder.
Jun 9, 2001
Thanks to Larry Nova, COMSI, USA.
======Changes thru 19.099 were in MXG 19.02 dated Jun 1, 2001======
Change 19.098 First MXG 19.02 only. Two lines were left from testing:
VMXGRMFI Lines 2398 and 2417: IF SYSTEM='SYSA' THEN
Jun 1, 2001 must be deleted. This error caused PDB.RMFINTRV to have
many missing variables, including NRCPUS and PARTNCPU.
======Changes thru 19.097 were in MXG 19.02 dated May 27, 2001======
Change 19.097 Labels for two variables were confusing and are revised:
VMAC94 SMF94VBR='BYTES*READ*THRU HOST*CHANNEL*FROM VOL'
May 25, 2001 SMF94VBW='BYTES*WRITTEN*THRU HOST*CHANNEL*TO VOL'
Thanks to Simon Everitt, NPI Financial Services, ENGLAND.
Change 19.096 Variables SMF94IN4 and SMF94EX4 were not multiplied by a
VMAC94 1024*1024, but now are (as were IN3 and EX3) to convert a
May 24, 2001 raw megabyte value back into bytes, so the MGBYTES format
will correctly display these bytes-completed variables.
Thanks to David Bixler, Fiserv, USA.
Change 19.095 EMC's InfoMover SMF records INFSTART and INFTIME are now
VMACINMV INPUT as &PIB.4.2; their bad values reported back in MXG
May 24, 2001 Change 17.396 are now corrected to the normal SMF time
format, replacing the MXG circumvention that had &RB4.
and a divide by 150.
Thanks to Bob Bradley, United Airlines, USA.
Change 19.094 Documentation. Variable DB2SRBTM is missing in DB2ACCT,
VMACDB2 beginning with DB2 Version 6.1, and as documented by IBM
May 23, 2001 and as noted in member ADOCDB2. This note added so that
searching changess for DB2SRBTM will expose itself.
But as a result, if you have any reporting code that uses
DB2CPU=DB2TCBTM+DB2SRBTM;
because the SAS assignment statement A=B+C will have A
missing if B or C are missing. Instead, you must replace
the assignment statement with a SUM() statement:
DB2CPU=SUM(DB2TCBTM,DB2SRBTM);
or, you could remove +DB2SRBTM from your equation.
Change 19.093 Support for Release 5.06 (INCOMPATIBLE, in TYPE1082 data
VMAC108 set, because DOMUNAME was expanded from 32 to 36 bytes).
May 23, 2001 And new field DOMPRPID, Process ID, is added to TYPE108
datasets.
Thanks to Wolfgang Vierling, Allianz, GERMANY.
Change 19.092 The PDB.ASUMUOW dataset is enhanced to now keep variable
VMXGUOW USERCHAR (the real transaction name of some transactions
May 23, 2001 can be stored in the USERCHAR field). The first non-blank
May 25, 2001 (character) or non-missing (numeric) value is output. All
CICS "ID" variables are now listed in new MACRO _KUOWIDC
so you can override and add additional "ID" variables.
The current list of "ID" variables from CICSTRAN is:
APPLID USER LUNAME SYSTEM TERMINAL USERCHAR
To add another variable, say CLIPADDR, you would code:
%LET MACKEEP=
%QUOTE(
MACRO _KUOWIDC
APPLID USER LUNAME SYSTEM TERMINAL USERCHAR
CLIPADDR %
);
New macros _KUOWIDD and _KUOWIDDM for DB2 and MQ are now
defined as null, but can be used in future tailoring.
Option LISTALL=YES on the VMXGUOW invocation can be used
to identify which HOLDxxxx, FRSTxxxx, or LASTxxxx
variable is being used to retain/sum the values for which
real variables in the data step that builds ASUMUOW.
If you really want to create observations in PDB.ASUMUOW
you can use this instream logic before your include:
%LET MACKEEP=
%QUOTE(
MACRO _NOOBS % MACRO _YESOBS %
);
%INCLUDE SOURCLIB(ASUMUOW);
Thanks to Alan Lankin, Towers Perrin, USA.
Change 19.091 An incorrect statement in format $MGFDROP was not caught
FORMATS by SAS, and caused no error, but should have. The text
May 23, 2001 '00'X'='00'X:OTHER (FDRABRM)' was corrected to now read
'00'X='00'X:OTHER (FDRABRM)'
Thanks to Joe Faska, Depository Trust, USA.
Change 19.090 Documentation. Comments had the wrong IBM field name for
VMAC74 two variables. Corrected field name in comments are:
May 21, 2001 @45+OFFSMF LENDDSS &PIB.2. /*SMF74DDL*/
@47+OFFSMF NRDDSS &PIB.2. /*SMF74DDN*/
Thanks to Michael Spencer, BMC Software, USA.
Change 19.089 SAS V8.2 "WARNING: OPTION BLKSIZE(2311) SET INTERNALLY
CONFIGV8 IS NOT SUPPORTED IN THIS VERSION" has no impact; SAS data
May 21, 2001 libraries are still created with half-track blocksize and
SAS Institute will eventually eliminate the spurious
message; a SAS Usage Note will be created later. The SAS
defect was precipitated by a BLKSIZE(DASD)=HALF statement
in MXG's CONFIGV8 member, and to circumvent the SAS error
and eliminate the warning, I have replaced the statement
BLKSIZE(DASD)=HALF
with
BLKSIZE(3390)=27648
BLKSIZE(3380)=23040
so as to still set the desired half track block size for
new SAS data libraries on DASD.
You could make the WARNING go away by removing that
BLKSIZE(DASD)=HALF statement from CONFIGV8, but without
those device-specific half-track values being set in your
CONFIGV8 member, you will instead get the SAS System
default value of 6144 that is set their SAS.CNTL(CONFIG)
member in your //CONFIG DD concatenation.
SAS Institute still sets their default block size for
new MVS SAS data libraries to 6144, because, for some
SAS datasets that have INDEXes, the half-track block
size may be sub-optimal, but specifically for MXG, and
in general for any data-intensive SAS application that
writes large volumes of SAS data that are sequentially
accessed and do NOT use SAS Indexes, a small 6144 byte
block size will waste massive amounts of CPU time, I/O
I/O time, cause unneeded EXCPs, SIOs, and waste real
memory! And your DASD datasets at 6144 byte blocksize
will also waste DASD space! You want your MXG-built
SAS datasets to be built with half-track blocksize on
DASD!
Thanks to John R. Myers, Vanguard, USA.
Thanks to Tricia Henry, John Fairfax Holdings, AUSTRALIA.
and now others, but they reported it first!
Change 19.088 Variable INITTIME in both TYPETMNT and TYPETALO were off
VMACTMNT by one full day starting March 1, 2001, because the MXG
May 15, 2001 logic using YEARSEC did not protect for this year's leap
day, and because ASMTAPES does not get the century bit on
when it copies these IBM fields. The logic using YEARSEC
was revised to force the century bit for INITTIME.
Thanks to Joan Nielsen, i-structure, USA
Thanks to Mike Shapland, i-structure, USA.
Change 19.087 This contributed example sums up all of the CPU time for
ANALUSS a job using Unix System Services (USS) under MVS's OMVS
May 15, 2001 (OpenEdition), as described by its author:
Jobs that call Unix System Services (USS) can have their
Unix work spawned to independant address spaces that are
started tasks. OMVS creates the jobnames for these
address spaces by appending a 1-digit numeric suffix to
the jobname of the original job. (Job ABCD will spawn
STC OMVS address spaces named ABCD1, ABCD2, etc). Eight
character jobnames will spawn A/S's named the same as the
job (e.g., ABCD5678 will spawn ABCD5678). There will
likely be more than one OMVS ASID per job, so the CPU for
the USS work of a job will be in multiple type 30 records
with different job names, numbers, and initiate times.
This program matches up those job records and sums up the
CPU time for the job. (The starting and ending time of
the USS tasks will be within the start/end time of the
originating job.)
The program makes these assumptions:
1. An 8-digit USS jobname could be spawned by either a
7 or 8 digit job. The code assumes the 8-digit USS
job is spawned by an 8-digit job unless it's found
to come from a 7-digit job.
2. We assume the job started yesterday. This code
could be removed or changed.
Thanks to Alan Lankin, Towers Perrin, USA.
Change 19.086 JCL example still referenced &&SOURCLIB, but that temp
ANALDSET dataset is no longer created nor used in the revised JCL
May 15, 2001 to analyze dataset activity from 14/15/64 and SMF 30s.
Thanks to Freddie Arie, TXU, USA.
Change 19.085 TLMS date variables BAPURCH BACLNDT BACERTDT with invalid
VMACTLMS julian day-value of zero (Packed field '0100000C'x in the
May 15, 2001 record) caused INVALID ARGUMENT FOR DATEJUL FUNCTION.
Jul 6, 2001 This change tests the day value of those three fields and
sets the date missing if the day value is zero.
Also, the value of BACTIME was not correctly converted to
a time value but now is and is formatted as TIME8.
Jul 6: Variable BALUNIT was changed to BAIUNIT to match
the TLMS dsect name.
Thanks to Dietmar Lakemann, Rechenzentrum Verden GmbH, GERMANY.
Thanks to Ian Davies, Independent Consultant, CANADA.
Change 19.084 MXG output observations in TYPE73 for channels that were
VMAC73 offline (but with all zeros, the extra observations had
May 15, 2001 no real impact), but they are no longer output. The old
MXG logic had bit tests to protect for MVS/ESA 4.3 that
can now be removed, and the test to output TYPE73 now is:
IF ONLINE='Y' AND VALIDPTH='Y' THEN DO;
Also, variable SMF73BSY was added to the KEEP list, in
case it is needed for later re-calculation.
I was writing this update for ADOC73 to better document
that there are two, different, kinds of observations in
TYPE73, when I found the need for this change.
TYPE73 Contains Different types of Observations, based on
the value of SMF73CMG, the CPMF Group:
SMF73CMG = . or 0 ==> old record, without extension
PCHANBY calculated from SMF73BSY/NRSTCPS
PNCHANBY calculated from SMF73PBY/SMF73PTI
SMF73CMG = 1 ==> CPMF=COMPAT
When present, variables SMF73TUT/SMF73PUT, the new
durations when Total Channel Path, LPAR Channel Path
was busy are INPUT (i.e., will be non-missing).
PCHANBY re-calculated from SMF73TUT/SMF73PTI
PNCHANBY re-calculated from SMF73PUT/SMF73PTI
"Normal" TYPE73 record for ESCON channels, CTC's, etc.
FICON channels are reported upon, but only to the same
level of detail as other channel types.
SMF73CMG = 2 ==> CPMF=EXTENDED
This "new" extended subtype is currently written for
OSD and FICON channels (SMF73CPD=11x:OSA DIRECT
EXPRESS, SMF73CPD=1Cx:FICON BRIDGE). It adds
read/write/total byte counts for total/lpar from which
MXG creates four read/write rates in bytes/second:
SMF73TRU=SMF73TRU*SMF73US/SMF73PTI;
SMF73PRU=SMF73PRU*SMF73US/SMF73PTI;
SMF73TWU=SMF73TWU*SMF73US/SMF73PTI;
SMF73PWU=SMF73PWU*SMF73US/SMF73PTI;
and re-calculates PCHANBY and PNCHANBY:
PCHANBY=100*SMF73TUC/(SMF73MCU*SMF73PTI);
PNCHANBY=100*SMF73PUC/(SMF73MCU*SMF73PTI);
and calculates the new "Bus Busy Percent" in PBUSBY
(which is non-missing only in these SMF73CMG=2 obs).
PBUSBY=100*SMF73TBC/(SMF73MBC*SMF73PTI);
Whether type 73 (and type 79-12) records contain CMG 1 or
2 data is determined by the CPMF parameter of IEAOPTxx
member of PARMLIB. CPMF=COMPAT produces MG1 format data
records and CPMF=EXTENDED produces the MG2 format record.
Note that all TYPE73 observations have variables PCHANBY
and PNCHANBY calculated for Total/LPAR percent channel
busy measurements, so if you need seconds of busy time
you can calculate as BUSYTM= PCHANBY*DURATM/100;
OBSERVATION COUNT CHANGE: TYPE73 fewer obs.
Thanks to David M. Kellerman, ADP, USA.
Change 19.083 MXG's creation of SMF70WLA and MSU4HRAV/MSUINTRV values
VMXGRMFI in PDB.RMFINTRV is wrong if you now have the new z/OS
May 14, 2001 records that have SMF70WLA populated by IBM. I thought
May 16, 2001 SMF70WLA would contain the "this-system" MSU capacity in
May 26, 2001 the type 70 record, so in records without that field, I
created SMF70WLA in PDB.RMFINTRV, and for a 1-way system
I set SMF70WLA=36 (the correct MSU capacity available to
that LPAR with one engine), but now I find that IBM puts
SMF70WLA=253 in their record, which is the "all-engine"
or total "image" MSU capacity of the CPC, the hardware
MSU capacity of the box. Spinning was also corrected.
*** NOTE: IBM NOW STORES THE LPAR CAPACITY VALUE, 36,
AND NOT THE CPC MSU VALUE, 253. THIS WAS
APPARENTLY AN EARLY TEST SITE?
SEE CHANGE 20.168.
Since MXG generally never changes the value of IBM fields
in IBM records (although sometimes "Sums" are converted
into "Averages", and labelled accordingly):
- corrects the MXG value of SMF70WLA in PDB.RMFINTRV
to contain the IBM value and the label now reads
SMF70WLA='DEFINED*CAPACITY*IN MSU*AVAILABLE*TO CPC'
- and creates new variable ZOS70WLA in PDB.RMFINTRV
ZOS70WLA='DEFINED*CAPACITY*IN MSU*AVAILABLE*TO MVS'
to contain the value that you really want, the MSU
capacity of this MVS System, so you can compare this
MVS System's MSU usage (MSU4HRAV/MSUINTRV) with its
MSU capacity (ZOS70WLA). Both SMF70WLA and ZOS70WLA
variables are kept in the PDB.RMFINTRV dataset
So now: NOTE: after Change 20.168:
SMF70WLA is the Defined Capacity of the LPAR
ZOS70WLA is the same as SMF70WLA
MSU4HRAV is MXG's 4-hour average hourly MSU
MSUINTRV is the MSU count for this RMF interval.
SMF70LAC is IBM's 4-hour average hourly MSU
Thanks to Pat Curren, SuperValu Inc, USA.
Change 19.082 Support for HMF Subtypes 29, 30, and 31 create threee new
DIFFHMF MXG datasets:
EXTYHMFT Subtype "dddddd" DATASET Description
EXTYHMFU 29 TYHMFT TYPEHMFT CNT2 COMPRESSION ENTRY
EXTYHMFV 30 TYHMFU TYPEHMFU CNT2 IFENTRY
IMACHMFU 31 TYHMFV TYPEHMFV CNT2 SYSGROUP/CNTSYS
VMACHMF Datasets TYPEHMFT and TYPEHMFU have accumulated counters
VMXGINIT so their sort macros _STYHMFT and _STYHMFU were added to
May 14, 2001 the DIFFHMF member.
Thanks to Perry Lim, Union Bank of California, USA.
Thanks to Theo Peelen, Rabobank, THE NETHERLANDS.
Change 19.081 Support for DB2 SMF 102 IFCID 096 was mis-aligned. Field
VMAC102 QW0096WF should have been &PIB.4. instead of 2, and a two
May 10, 2001 byte reserved field was not input after QW0096RC.
Thanks to John Mourtgos, Albertsons, USA.
Change 19.080 NPM processing with TYPS28 invoked only _S028IN7 macro to
TYPS28 sort the NPMINPMT dataset; instead, it should invoke the
May 10, 2001 _S28 macro so that all NPM datasets are sorted to the PDB
DD name.
Thanks to Sue Kemper, Universal City Studios, USA.
Change 19.079 JCL with comments to run ASUMUOW using batch pipes or
JCLUOWP pipes plex. SAS Institute has enhanced their product at
May 9, 2001 our request so that it interfaces with IBM's BatchPipes
product; this example shows how to use SAS and pipes to
significantly reduce run time and physical I/Os. The SAS
support for BatchPipes will be available in SAS Version 9
but if there is enough demand to Technical Support at SAS
for support, a "hot fix" for SAS 8.2 could be possible.
There are 3 jobs and they must all run concurrently.
-READDB2 reads the DB2 SMF data, and, using a view,
passes DB2ACCT to a SORT which outputs into the PIPE for
DB2ACCT and uses a pipe fitting to harden the DB2ACCT
dataset.
-READCICS reads the CICSTRAN data and again, using a
view, passes the data the SORT which then outputs into
the PIPE for CICSTRAN and hardens the CICSTRAN dataset.
-ASUMUOW uses the PIPEs from READDB2 and READCICS to read
the DB2ACCT and CICSTRAN datasets and create ASUMUOW.
Note the SPININ and SPIN DD usage in ASUMUOW allows the
SPIN dataset to be a GDG for ease of recovery.
The hardening via a pipe fitting is certainly optional
but does not materially affect the run, time. In theory,
when the sort of CICSTRAN ends, so does ASUMUOW.
Thanks to Chuck Hopf, MBNA, USA.
Change 19.078 Truncated type 14 record caused INPUT STATEMENT EXCEEDED
VMAC1415 error because MXG did not validate the real length with
May 9, 2001 the length fields in the record. This rare bad record is
now detected and deleted with an MXG message but the rest
of the SMF file will now be read.
Thanks to Howard Unich
Change 19.077 IBM made changes to the SMF 120 record (Websphere CB) and
VMAC120 now with actual records, the MXG design was revised, as
May 9, 2001 only five datasets are now created:
May 11, 2001 TYP120CC - Container and Class information, from either
Subtype 2 (Container Activity) or Subtype 4
(Container Interval). Variable SM120STY can
be used to identify which event created the
observation; the interval records will also
have DURATM,SM120SST,SM120SET non-missing.
TYP120CM - Class and Method information, from either
Subtype 2 (Container Activity) or Subtype 4
(Container Interval). Variable SM120STY can
be used to identify which event created the
observation; the interval records will also
have DURATM,SM120SST,SM120SET non-missing.
TYP120SA - Server Activity from subtype 1
TYP120SC - Communications Session from subtype 1
TYP120SI - Server Interval from subtype 3
Thanks to Martyn Jones, ABN AMRO, THE NETHERLANDS.
Change 19.076 The STRTTIME/ENDTIME values in CICSTRAN segments could be
VMAC110 later than the SMFTIME of the physical record; the MXG
May 8, 2001 conversion from STCK(GMT) to LOCAL did not include the
Leap Seconds. The revised equation is now:
STRTTIME=STRTTIME+MCTMNTAD-MCTMNLSO;
Thanks to Ralph Alcorn, Safeway, USA.
Change 19.075 TSO/MON variables were input but not kept in TSOMCALL.
VMACTSOM These variables are now labeled and kept:
May 7, 2001 TSMPEMCT TSMPEMTM TSMPRTYP TSMPSDCT TSMPSEQN TSMPSWCT
TSMPTRAN TSMPURR
Variable TSMPURR=00x observations do not have counts in
the LONG, TRIV, or NONTRIV transaction counts; those
counts exist only if the '01'x bit is on in TSMPURR.
Thanks to Gerry Girard, Canadian Utilities, USA.
Change 19.074 KEEPALL=YES is now specified in the VMXGSUM invocation in
ASUMCICS these ASUMxxxx members that are all included in JCLPDBx
ASUMDB2A examples. Using KEEPALL=YES bypasses the execution of
ASUMDB2B many DATA steps by VMXGSUM, saving CPU time in these ASUM
ASUMJOBS members. (The prior KEEPALL=NO default caused steps to
ASUMTMNT be executed to build a KEEP= list that was used only for
May 7, 2001 the INPUT dataset to prevent variable not found errors in
subsequent PROC MEANS executions.)
-In ASUMJOBS, IF JSTRTIME=. was changed to IF INITTIME=.
to eliminate jobs that did not initiate more robustly.
Change 19.073 Support for DCOLLECT APAR OW48529 which documents the
FORMATS value of 3 for DSCAVAIL as "Continuous Preferred" so the
Apr 18, 2001 MGDCODV format was updated to decode that value.
Thanks to Jim Petersen, HomeSide Lending, USA.
Change 19.072 USERADD=HSM, resulting in _IDHSM, but in VMACHSM the IF
UTILBLDP statement is looking for _IDHSMDS.
May 2, 2001 Also, COMPLETE has five macro names, now generated.
Thanks to Wayne Bell, National General Insurance Co., USA.
Change 19.071 To allow for the override of _IDTMNT with IMACTMNT
ASMFTAPE Line 53 ( MACRO _IDTMNT 238 % ) must move before the
Apr 26, 2001 %INCLUDE(VMACSMF,VMAC21,VMACTMNT);
Thanks to Normand Poitras, IBM Global Services, USA.
Change 19.070 The _BTY78SP BY list for TYPE78SP was not complete enough
VMAC78 to remove duplicate records, so it was revised to be:
WEEKBLD MACRO_BTY78SP SYSPLEX SYSTEM STARTIME READTIME JOB
MONTHBLx SUBPOOL %
APR 26, 2001 with the addition of SUBPOOL. Since TYPE78SP is optional
job-level subpool monitoring, this exposure is minimal,
but since TYPE78SP is a part of the BUILDPDB process, the
BY lists for it in the WEEKBLDx and MONTBLx also had to
be updated.
Thanks to Iven Willy, Fortis Bank, ENGLAND
Change 19.069 The BY-list MACRO _BFDRDSF had DSNAME instead of FDRDSN
VMACFDR as the name of the variable, causing DSNAME NOT FOUND.
TESSUSR1 Added TYPSFDR to test stream for _S, _B macros.
Apr 26, 2001
Thanks to David Ehresman, University of Louisville.
Change 19.068 Format $MG073CD for type 73 records was updated to
FORMATS include 23X Internal Coupling Peer.
Apr 12, 2001
Thanks to Jerry Urbaniak, Acxiom CDC, USA.
Change 19.067 Preliminary support for BMC Mainview Batch Optimizer, BMO
TYPEMBO that will replace HiperCache product. BMO records quite
Apr 6, 2001 different; code works but at Alpha test site now.
Thanks to Jim Petersen, HomeSide Lending, USA.
Change 19.066 GOPTIONS statement was mis-located; it should be located
GRAFRMFI after the %SYSPROD(GRAPH) statement. Only impact was if
Apr 6, 2001 you did not have SAS/GRAPH on your system.
Thanks to Art Hunter, Penn Mutual Life Insurance Company, USA.
Change 19.065 NTSMF Object NETWORK INTERFACE is now NETWORKINTERFACE
VMACNTSM and PAGING FILE is now PAGINGFILE, both without the old
Apr 6, 2001 blank, requiring the test for object name to
now look for either spelling.
Thanks to Bob Gauthier, Albertsons, Inc, USA.
Change 19.064 Cosmetic, to avoid confusion. In this example JCL for a
JCLTREND TRENDing, the DISP=OLD on //CICSTRAN and //WEEK is not
Apr 6, 2001 needed, as both are input-only in that job, and so they
were changed to DISP=SHR.
Thanks to Art Hunter, Penn Mutual Life Insurance Company, USA.
Change 19.063 SAS Version 8.2 Spurious NOTE "might be uninitialized".
VMXGWORL Fortunately, there is no impact, other than the printing
Apr 6, 2001 of several new NOTES on the SAS log, and SAS Technical
Apr 9, 2001 Support now acknowledges the note should not have been
Jun 11, 2001 printed and SAS be revised to recognize that NOBS will be
initialized by the NOBS=NOBS parameter.
The MXG change was to initialize the NOBS variable before
the CALL to prevent the compiler notes.
Read on, only if details interest you.
Some of the new NOTES include these:
546: LINE AND COLUMN CANNOT BE DETERMINED
NOTE: NOSPOOL IS ON. RERUNNING WITH OPTION SPOOL MAY
ALLOW RECOVERY OF THE LINE AND COLUMN WHERE THE ERROR
HAS OCCURRED.
NOTE: 546-185: THE VARIABLE NOBS MAY BE UNINITIALIZED.
Enabling the SPOOL option did print the source statement,
which was inside the VMXGWORL macro, which MXG uses to
figure out if observations are in "WorL", i.e., in the
"_W" OR the "_L" dataset macro. That code:
DATA;
CALL SYMPUT('MXGOBS',NOBS);
____
546
STOP;
SET CONTENTS NOBS=NOBS;
is code originally recommended by SAS as a safe way to
set macro variable &MXGOBS non-zero if there are obs in
dataset "CONTENTS", to set it zero if there are 0 obs,
or to not-fail if there is no "CONTENTS" dataset.
The NOBS variable in our SYMPUT is uninitialized when the
CALL SYMPUT is seen, but SET CONTENTS NOBS=NOBS populates
variable NOBS, so MXG's logic works just fine.
If we moved the CALL to be after the SET, NOBS would
have been populated, but that logic won't work here:
If the CALL is after the SET, the CALL statement
won't be executed when there are zero observations
in CONTENTS or when CONTENTS dataset doesn't exist.
SAS added this new "may be" note to correct a problem
where it an uninitialized variable was not identified,
but that fix unintentionally fired spuriously here, and
SAS will correct the compiler to recognize the NOBS=NOBS
will populate the CALL statement, even when the CALL is
seen before the SET statement.
To eliminate the printing to these notes SAS V8.2, MXG
simply added a compiler faker statement:
IF NOBS=. THEN NOBS=.;
before each of the two CALL SYMPUTs in member VMXGWORL
to satisfy the compiler's need for NOBS to appear in an
assignment statement; this will work now and when SAS has
fixed the spurious NOTE.
11Jun01: The extraneous %PUT statement was deleted:
%PUT BARRY DEBUG &MXGLYES= &MXGWORL= &MXGOBS=;
Change 19.062 MXG 19.01 only. Change 19.059 introduced an error when
VMACSOLV temporary variable MONTH was changed to numeric. Now, it
Apr 5, 2001 is reverted back to character but renamed MONTHSL.
Change 19.061 IMS 01 records with the recovery bit on were deleted,
ASMIMSL5 causing differences in observation counts in IMSSUMSO,
ASMIMSL6 IMSMERGE, and NODTOKEN. The Branch statement (at line
Apr 5, 2001 1444 in ASMIMSL6, line 1415 in ASMIMSL5), following the
TM MSGFLAGS,MSGFNRQU statement, was commented out to
prevent the incorrect deletion of valid 01 records.
NOTE: JUL 11: This change was in error and was undone by
Change 19.135.
======Changes thru 19.060 were in MXG 19.01 dated Apr 4, 2001======
Change 19.060 Variable BLKSIZE in the optional TYPE30_D => PDB.DDSTATS
VMACEXC1 dataset is wrong in OS/390 R2.10 and z/OS; I input the
Apr 4, 2001 new 8-byte SMF30XBS as floating point with RB8, causing
values of -1E64 or +1E18, as the input should have been
binary &PIB.8. However, IBM uses the first bit as a flag
that the block size was changed, and then I re-discovered
that SAS cannot store all digits of a field input as PIB8
when the first bit is turned on:
X = '8000000000006D10'X; /*hex literal */
Y = INPUT (X,&PIB.8.); /*input as binary*/
Z = MOD(Y,8000000000000000X); /*get the 6d10 */
returns z= 28762 under PC SAS,
z= 27904 under OS/390 SAS,
but z= 27920 is the correct value for '6D10'x.
so the actual INPUT was revised to use &PIB.7.
Fortunately, BLKSIZE/MULTSIZE variables are rarely used.
Thanks to Rob Gibson, CentreLink, AUSTRALIA.
Change 19.059 Compiling of all MXG members that process SMF records has
VMACF127 uncovered a few conflicts where variables are defined as
VMACLDMS numeric in one record and character in another record.
VMACMOUN Renaming the variable in the more-seldom-used product
VMACDECS eliminate the possible exposure.
VMACRMDS VMACF127 - Not-kept DEVNUM renamed.
VMACROSC VMACLDMS - JESNR is now a numeric variable.
VMACSOLV VMACMOUN - Variable UCBTYPE is now a numeric variable.
VMACAIMR VMACDECS - Variable DSORG now DSORGDEC.
VMACLMS VMACRMDS - Not-kept RECSEQNO renamed.
VMAC102 VMACROSC - Not-kept DELETE renamed.
VMACHBUF VMACSOLV - Not-kept YYYY now numeric.
VMAC90 VMACAIMR - Not-kept YY1-SS1 and YY2-SS2 now YY-SS.
VMAC90A VMACORAC - Not-kept Reserved variables renamed.
Apr 4, 2001 VMACLMS - Not-kept DSTYPE renamed to DSTEMPTY.
VMAC102 - Not-kept VALUE renamed VALUE4BY.
VMACHBUF - RECTYPE renamed RECTYPEC.
VMAC90 - Not-kept DOMFLAG renamed.
VMAC90A - DOMFLG renamed DOMFLG90.
Change 19.058 If you changed the PDB2ACC default from PDB to DB2ACCT,
JCLTEST6 the JCL TEST programs failed, because MXG had failed to
JCLTEST8 provide a //DB2ACCT DD statement in some steps.
Apr 4, 2001
Thanks to Jesse Gonzales, Gap Inc, USA.
======Changes thru 19.057 were in MXG 19.01 dated Apr 3, 2001======
Change 19.057 The NTCONFIG dataset only recorded model/speed/etc for
VMACNTSM the first four CPUs; now CPUNUM,CPUSPED,FAMILY,MANUFAC
Mar 31, 2001 variables exist for 32 processors.
Thanks to Bob Gauthier, Albersons, Inc, USA.
Change 19.056 Protection for invalid ALOCTIME in type 30 records, while
VMAC30 IBM investigates the cause. Step records with ALOCTIME
Mar 31, 2001 that is a fraction of a second earlier than the INITTIME
are not possible (steps initiate first, then allocate,
and then load), but are written by OS/390 R2.10. The
MXG logic must compare those times to determine the step
ALOCDATE and LOADDATE (because ALOC/LOAD have only times
with no dates in type 30s), and it concluded "INIT Today,
ALOC Tomorrow" when the ALOC Time was earlier than INIT.
The IBM error of the earlier ALOC time causes MXG to add
one day to the ALOCTIME variable, which then caused the
DSENQTM to be 23:59 hh:mm, ALOCTM to be -23:59, and the
EXECTM could also be very large, positive or negative.
Knowing that it will take IBM time to diagnose and fix
their eror, I have revised the MXG logic to be smarter.
Now, if the INITDATE and TERMDATE are the same, then the
ALOCDATE and LOADDATE are known so the "date bump" logic
is bypassed (all seen observations fell into this case).
So only when the TERMDATE is a day or more later than the
INITDATE will the INITTIME, ALOCTIME (and LOADTIME) be
tested, and their dates are now bumped only if the delta
is more than 5 seconds, so small errors in the time value
in the SMF record won't cause the algorithm to misfire.
Note Sep 25, 2001: IBM APAR OW50134 acknowledges their
error, but that APAR resolution is "FIN", Fixed in Next.
Thanks to Andrew Hebden, Barclays, ENGLAND.
Change 19.055 -Change 18.233 documented new SYNC59 parameter, but it was
VMXGDUR actually added until this change. SYNC59 argument values
VMXGSUM can be:
Mar 30, 2001 N - do nothing.
Y - add 1 Minute to time
nnn - add nnn minutes to time
and a null value is the same as N.
-Additionally, a typo for TEMP02 option that caused error
FILE DDD.MXGSUM1.VIEW IS SEQUENTIAL when TEMP02 was used
was corrected.
Thanks to Karen Florup, Fidelity Investments, USA.
Change 19.054 MXG 18.10-18.18. MXG creates duplicate observations in
VMAC115 MQ-Series dataset MQMMSGDM, because there were duplicate
Mar 29, 2001 _ETY1152 macro executions. Delete the first invocation
of _ETY1152 macro (line 598), leaving one at line 639.
OBSERVATION COUNT CHANGE: MQMMSGDM fewer obs.
Thanks to Jun dela Rosa, U.S. Customs Service, USA.
Change 19.053 TCP SMF118 ERROR.4. HFS FILE TWO NAME ERROR message may
VMACTCP be created-in-error, if the second HFS filename is first
Mar 29, 2001 in the SMF record. MXG protection logic (for invalid
offset values) tested IF COL LE ... (which assumed that
COL would increase as the record was read. But now that
records with the physical positions reversed are found,
changing those tests to IF 205 LE ... will protect for
invalid offsets, and let MXG find the name segments in
whatever order IBM writes them in their SMF record.
The only impact of this error was that one or both HFS
filenames would be blank.
Apr 9, 2003: IBM APAR PQ73030 will correct the offsets,
which should only be non-zero for a RENAME event.
Thanks to Bruce Widlund, Merrill Consultants, USA.
Change 19.052 INVALID DATA for MOUNSMND/MOUNEMND occurs if those dates
VMACMOUN are nulls; one pair of PD4 INPUT was protected with "??",
Mar 29, 2001 but now all PD4 INPUTs are protected.
Thanks to Normand Poitras, IBM Global Services, CANADA.
Change 19.051 Support for APAR OW46622 identifies Address Spaces that
VMAC79 have Temporal Affinity (see also OW45238). No code was
Mar 28, 2001 changed, since R791FLG and R792FLG variables already are
input and kept, and bit 7 ('.......1'B) is the flag.
Change 19.050 Support for Landmark's The Monitor for IMS V1.1 records.
EXTIMCH Use TYPSTIMS to create and deaccumulate these datasets:
EXTIMCJ TIMSCH History Statistics
EXTIMCJD TIMSCJ Transaction Statistics
EXTIMCK TIMSCJD Transaction Statistics - Detail
EXTIMCKD TIMSCK Database Statistics
EXTIMCL TIMSCKD Database Statistics - Detail
EXTIMCL1 TIMSCL Buffer Statistics
EXTIMCL2 TIMSCL1 Buffer Statistics - First Pools
EXTIMCL3 TIMSCL2 Buffer Statistics - Second Pools
EXTIMCM TIMSCL3 Buffer Statistics - Third Pools
EXTIMCN TIMSCM Input Messages
EXTIMCO TIMSCN Interval Statistics
EXTIMCP TIMSCO Output Messages
EXTIMCT TIMSCP PSB Completion
EXTIMCU TIMSCT Thread Termination
EXTIMCUD TIMSCU PST Statistics
EXTIMCX TIMSCUD PST Statistics - Detail
IMACTIMS TIMSCX Exception Alerts
TYPETIMS Use the INFILE name of MONITIMS for the Landmark records.
VMACTIMS If your data records are compressed, Assemble and install
VMXGINIT member EXITMON6, an "Infile Exit" for SAS V6/V8, that can
Mar 28, 2001 read the compressed records. See comments in EXITMON6.
Apr 1, 2001
All above datasets have been created, and unexpected and
unwanted accumulated counters were found, so that you
must use member TYPSTIMS to first write to //WORK and
then SORT/Deaccumulate into the //PDB library.
Detection of accumulated fields requires non-zero values,
and some of the fields in the test data were zero, so you
need to use PROC MEANS MIN ; to examine each dataset for
negative minimum (improper deaccum) or large minimum
(variable that probably should be deaccumulated).
TIMSCU: CUMSGOQ and CUPWAIT are occasionally negative
and some timestamps are always missing.
Thanks to Warren Waid, J. C. Penny Company Inc, USA.
Change 19.049 Using JCLTEST8, warnings about CODEPASS option was
JCLTEST8 printed, because the instream proc still referenced the
Mar 27, 2001 (CONFIG) member instead of (CONFIGV8) for SAS V8.
Thanks to Art Hunter, Penn Mutual, USA.
Change 19.048 Variable STC11CSP should have been input as &PIB2.2 so
VMACSTC that its value is 20 for a 20 MegaByte/Sec Channel Speed.
Mar 27, 2001
Thanks to Chuck Hopf, MBNA, USA.
Change 19.047 Support for optional CICS TCP/IP timings and counts from
IMACICDA the EZA01 segment adds ten variables to the CICSTRAN
IMACICEZ dataset, but ONLY if you remove the comment block in the
IMAC110 IMACICEZ member. You need to also run UTILCICS to see
Mar 26, 2001 where the EZA01 segment was added, and may have to change
the expected order of segments in member IMACICDA.
Thanks to Andreas von Imhof, Rabobank, THE NETHERLANDS.
Change 19.046 Support for IMS Version 7.1 IMS Log Records is almost
VMACIMS compatible; only the '40'x log record was incompatibly
Mar 26, 2001 changed (and it is needed only if he message queue was
built), based on documentation review of the log DSECTS.
Some additional fields are now decoded, but no new
variables were added to the existing log record datasets.
Thanks to Engelbert Smets, Provinzial Versicherungen, GERMANY.
Change 19.045 Variable VERSNRMF was kept in most, but not all, RMF/CMF
VMAC7072 datasets, but is now kept in TYPE70PR/7204/72SC/78PA and
VMAC78 TYPE78SP datasets.
Mar 26, 2001
Thanks to Ian Davies, Independent Consultant, CANADA.
Change 19.044 NETSPY type 'R' records caused INPUT STATEMENT EXCEEDED
VMACNSPY because MXG expected 89 bytes, but NETSPY 5.3 creates a
Mar 26, 2001 type R record of only 77 bytes, so the three fields that
were added (NSPYBPQU NSPYBPST NSPYRNLP) are now input if
NSPYENTL=89.
Thanks to Reuben de Leeuwe, IZB, GERMANY.
Change 19.043 Reading VSAM SMF caused INPUT STATEMENT EXCEEDED RECORD
VMAC42 for type 42 subtype 5 record. This particular subtype has
Mar 26, 2001 internal offset variables, and the MXG logic looped on
Mar 27, 2001 those offset variables (instead of looping on the count
field, as these internal segments have no count field),
but the MXG logic to convert from IBM offset value to the
SAS byte location: OFFzzzz=OFFzzzz-3+OFFSMF; was
being executed even when OFFzzzz=0, causing OFFzzzz=1
when a VSAM subtype 5 was read (OFFSMF=4 for VSAM SMF).
Now, IF OFFzzzz GT 0 THEN OFFzzzz=OFFzzzz-3+OFFSMF;
logic protects for the input zero value with VSAM input.
(BSAM SMF has OFFSMF=0, so it produced OFFxxxx=-3 if the
input value was zero, but since the subsequent MXG logic
tests IF OFFxxxx GT 0 THEN DO; so the segment was not
input when not present with BSAM dumped SMF input).
Thanks to Ken Williams, IBM Global Services, ENGLAND.
Thanks to Mark Williams, Marks and Spencer, ENGLAND.
Change 19.042 Variables XMGMXT, XMGPAT, and XMGPQT should have been in
VMXGCICI a MAX= argument instead of the SUM= argument in the first
Mar 26, 2001 %VMXGSUM invocation. Their values were incorrect in the
PDB.CICINTRV dataset.
Thanks to Brian Hawthorne, MONY Life Insurance Company, USA.
Change 19.041 Support for APAR II12xxx clarifies documentation of the
VMAC50 VTAM type 50 record.
Mar 23, 2001
Change 19.040 If a file spanned more than five volumes, the VOLSERs in
VMACCTLG CTLGDSN dataset were overlaid with the subsequent VOLSER;
Mar 23, 2001 (i.e., VOLSER1='BARRY6' instead of 'BARRY1' if 6 vols).
Thanks to Gordy Rogers, Principal Financial Group, USA.
Change 19.039 Error: INVALID ARGUMENT TO SQRT FUNCTION is corrected;
ANALUOW small negative values due to rounding caused the error.
Mar 22, 2001
Thanks to Ed Long, FMR, USA.
Change 19.038 Change 18.286 corrected 1.024 to 1024 for SMF30JQT/RQT/
VMAC30 HQT/SQT, but ENCLACTM should also have been corrected to
Mar 22, 2001 use 1024 instead of 1.024 as the multiplier.
Thanks to Alan Freed, ADP, USA.
Change 19.037 Format MG060ID for type 60 records was updated from the
FORMATS SMF manual; several UNKNOWNs are now known.
Mar 19, 2001
Thanks to Chuck Hopf, MBNA, USA.
Change 19.036 Variable ABENDS in PDB.JOBS counts each OMVS/USS pseudo
BUILD005 step record as an abend. Change 10.325 set variable
BUIL3005 ABEND='OMVSEX' to identify each pseudo step record
Mar 17, 2001 (created when an OMVS/USS address space is "dubbed"), but
Change 16.183, which added variable ABENDS to PDB.JOBS,
should have skipped over these steps. The test in
BUILD005 to count abends was revised to now read:
IF ABEND NE: ' ' AND ABEND NE:'OMVSEX'
AND ABEND NE: 'FLUSH' THEN DO;
This error also could cause ABEND to be blank when it
should not have been, if the job had both pseudo steps
and other real steps that did have abends or returns.
Thanks to Rex Pommier, Western Surety Company, USA.
Change 19.035 New values for format MGSTCLB for variable STC07LBL are
FORMATS added:
Mar 16, 2001 /* $MGSTCLB FORMAT FOR VMACSTC */
VALUE $MGSTCLB
'1'='1:VERIFY LABEL VOLSER (IGNORE MEDIA)'
'2'='2:VERIFY UNLABELED CARTRIDGE (IGNORE MEDIA)'
'3'='3:BYPASS VOLSER AND MEDIA LABEL CHECK'
'4'='4:RECOVERY CARTRIGE NUMBER SPECIFIED'
'5'='5:VERIFY MEDIA TYPE, BYPASS VOLSER CHECK'
'6'='6:VERIFY MEDIA TYPE AND VOLSER'
'7'='7:VERIFY MEDIA TYPE AND UNREADABLE VOLSER'
;
Thanks to Martin Jensen, Jyskebank, DENMARK.
Change 19.034 Support for TNG for SOL260S records added. The SOL260S
VMACTNG records seem to be the same as SOL240S, so both formats
Mar 16, 2001 will create the same SOnnn Solaris TNG MXG datasets.
Thanks to Paul Hargreaves, SEMA, ENGLAND.
Change 19.033 Documentation/example only. No code change was made.
CONFIGV8 If you want to change the global MXG Default "PDB" DDNAME
VMXGINIT to something else, for example "MXG" because that's what
Mar 14, 2001 someone before you did, you should NOT make the change by
EDITing the VMXGINIT member, because that member changes
with every MXG version to GLOBAL all MXG macro variables,
and you would have to re-tailor every time you install a
new MXG version. Instead, you can change the DEFAULT=PDB
to DEFAULT=MXG by EDITing a USERID.SOURCLIB(CONFIGV8),
and changing the statement that invokes %VMXGINIT:
INITSTMT='%INCLUDE SOURCLIB(VMXGINIT);%VMXGINIT;RUN;'
to set the DEFAULT=MXG:
INITSTMT='%INCLUDE SOURCLIB(VMXGINIT);%VMXGINIT(DEFAULT=MXG);RUN;'
The CONFIGV8 member is one that sites may choose to EDIT,
since some of those options are site choices, but it does
not typically change between MXG versions, and it is the
intended location for any changes to the %VMXGINIT parms.
Further note: there should never be members starting with
VMAC nor VMXG in your USERID.SOURCLIBs, except as interim
corrections until you install the next MXG version. Old
VMAC/VMXG members in your tailoring libraries can cause
ABENDs, and require re-tailoring with each new Version.
They should always be removed when the new version is
installed, and all MXG tailoring can be put in the MXG
exit members or in your //SYSIN input stream, so you
never have to change your changes.
And while I'm in tutorial mode, if you have tailored any
VMXG members into your USERID.SOURCLIB, you probably did
it because you wanted to change the default arguments,
and you found how to make it work. But that is not the
correct way to %MACROs should be used. Instead of EDIT
of the VMXGxxxx member that defines the %MACRO %VMXGxxxx,
you simply EDIT the invocation of the %VMXGxxxx macro,
and change the parameter value there. For a specific
example, member RMFINTRV is where the statement that
invokes the execution of %VMXGRMFI macro is located, to
create PDB.RMFINTRV dataset. To change workloads, etc.,
you would EDIT the existing %VMXGRMFI
%VMXGRMFI statement in your RMFINTRV
member in USERID.SOURCLIB(RMFINTRV), adding the new parm:
%VMXGRMFI(PDB=PDB,...,PARM=WHATEVER);
In this manner, never editing the VMXG/VMAC members, the
install of a new MXG version means that you never have to
retrofit your MXG tailoring.
Thanks to Jerry J. Lentz, State of Arizona, USA.
Change 19.032 INPUT STATEMENT EXCEEDED RECORD for Shadow Direct subtype
VMACSHDW 06 record; the record says there was 417 bytes of SQL
Mar 14, 2001 text, but there were only 256 bytes of data, so the logic
to parse the SQL text into 100 byte chunks was revised to
use LENLEFT=MIN((LENGTH-COL+1,SM06SQLN) to control the
length of text bytes read.
Thanks to Chris Morgan, IBM Integrated Technology Services, ENGLAND.
Change 19.031 The CHAIN logic in processing IMF IMS transactions was
VMACCIMS revised by this user-contributed enhancement. When IMS
Mar 14, 2001 transactions are chained, the IMF record for the second
and subsequent transactions contain the arrival time of
the original transaction, which produced incorrect input
queue time measures. The CHAIN algorithm sorted thru the
chain and reset the arrival time of the second to the end
time of the preceding. But the original algorithm was
redesigned by Wolfgang:
- When transactions were started before the prior
transaction had finished, the RESPNSTM was cumulative;
that is corrected, and noted in new variables NEGTIME
and NEGCNT (kept only so you can see the impact of the
enhancement to see how wrong prior values were!).
- Data Steps 2 and 3 were removed, coding was moved into
the last step, reducing the execution and CPU time, I/O
and work space required.
Thanks to Wolfgang Vierling, AGIS GmbH, GERMANY.
Change 19.030 If your OS/390 was back level and did not have OW37565
VMAC7072 (flags ICF CPUs) MXG logic added in Change 19.015 caused
Mar 13, 2001 LPARCPUS=0 in TYPE70PR and missing data in ASUM70PR. The
Nov 15, 2001 logic now confirms the APAR is installed by checking the
NRCIXGT0 field before using SMF70CIX to id an ICF CPU.
Note added Nov 15, 2001: LPARCPUS=0 was a symptom here
because it was always zero AND caused missing data in the
ASUM70PR dataset, in that specific environment. After
this change, it is still normal to have observations in
TYPE70PR with LPARCPUS=0: those with LPARNAME='PHYSICAL',
or with SMF70CIN='ICF', or with LCPUADDR=. (for inactive
LPARs) will have LPARCPUS=0, and that's okay.
Thanks to Joe Montana, Acxiom, USA.
Change 19.029 Support for Tandem G06/G07/G08 TANCPU & TANDISK records.
VMACTAND -New fields were added to the end of the TANCPU record,
Mar 13, 2001 and variable DISKIOSF is now input as DISKIOS because it
is just the 8-byte DISKIOS field. The calculation of
rates was moved to the end of the TANCPU logic.
Code is in place for G06, G07, and G08 changes, but only
G06 with LRECL=770 has been validated.
-New fields were added to end of TANDISK record.
Code is in place for G06, G07, and G08 changes, but only
G06 with LRECL=746 has been validated.
Thanks to Patricia A. Wingfield, Bank of America, USA.
Change 19.028 Variables DSGPERCT and DS1PERCT-DS6PERCT in PDB.CICDS are
VMAC110 are not interval TCB Busy percent, as labeled, but are
Mar 12, 2001 the instantaneous value at the end of interval, which can
be quite different from the actual TCB Percent Busy:
Hour 03 06 09 12 15 18
DSGPERCT: 88 74 88 77 69 19
AVGPERCT: 22 70 58 65 64 40
IBM doesn't create DSxPERCT fields for the newer TCBs.
The PDB.CICINTRV dataset has all 11 TCBs DSnPERCT values
and all are recalculated (DSGPERCT=100*DSGACT/DURATM) so
they do match their label in the PDB.CICINTRV dataset.
The only change was to add "AT END" to the labels for the
7 TCB variables DSGPERCT-DS6PERCT in the PDB.CICDS data
Thanks to Normand Poitras, IBM Global Services, CANADA.
Change 19.027 Duplicate DB2ACCT records created by IBM Parallel Trans
EXDB2ACC are now deleted, but without this change, you will have
VMACDB2 duplicate DB2 accounting, negative DB2TCBTM, missing
VMXGUOW ELAPSTM, and these strange values in your DB2ACCT data:
Mar 12, 2001 QWACESC 01JAN1900:02:00:00 QWACEJST less than a second
Jun 5, 2001 QWACBSC 05JUN2001:19:20:21 QWACBJST minutes
The double accounting was introduced by IBM in DB2 APARS
PQ22260,PQ22451,PQ10864,PW06968,PQ45496 but it sure was
not obvious from the text of those APARs. The end result
is that, now, when DB2 parallelism is used, instead of
writing many individual child records, IBM "rolls up"
(sums) all child records into a single record, but that
record now is a duplicate of the previously existing
parent record. IBM finally documented how to identify
and delete these duplicate DB2ACCT records: New MXG
bit flag variable QWACPARR is now created
IF QWACFLGS='.........1......'B THEN QWACPARR='Y';
ELSE QWACPARR=' ';
to identify these "rolled up" records, and the statement:
IF DB2PARTY='P' AND QWACPARR='Y' THEN DELETE;
was added in the EXDB2ACC exit member so that MXG will
delete this duplicate data.
Note: That IF/DELETE statement was a circumvention and it
was removed from all exits by Change 22.121.
Additionally, VMXGUOW was similarly updated so ASUMUOW
will also delete the dupes, and it could be re-run
against existing DB2ACCT/CICSTRAN data to re-build
PDB.ASUMUOW without duplicates. Normally, I am reluctant
to delete any SMF data, but this duplication is so
obscure and could be so impacting, that I chose to delete
them in MXG to prevent their accidental introduction into
DB2ACCT (and ASUMUOW), which are used for DB2 billing. I
am not aware of any other data in these records which
justifies keeping them, but since the logic was added in
the Exit, you could easily change it to create these
rolled-up data records, if needed.
This note's documentation was enhanced Jun 5, but no code
was changed.
Thanks to Being Hwang, DOA, State of Wisconsin, USA.
Thanks to Gunther Vogt, Audi AG, GERMANY.
Change 19.026 ASUMV14 summarizes STK VTS dismount records to get total
ASUMV14 bytes compressed and uncompressed and the compression
ASUMV11 ratio. ASUMV11 summarizes STCVSM11 to the QTR hour too
Mar 10, 2001 get the back end channel busy for STK VSM.
Note that the STCVSM11 dataset must be selected from only
one system; each system connected to the VSM writes what
are effectively duplicate records, at slightly different
intervals.
Thanks to Chuck Hopf, MBNA, USA.
Change 19.025 CICS CPU time captured in CICSTRAN/CICDS/TYPE30/TYPE72 is
ADOC110 now docummented in member ADOC110. This change adds the
VMAC110 variables QRCPUTTM, MSCPUTTM and KY8CPUTM, which already
VMXGCICI exist in the CICSTRAN dataset, to the CICDS Dispatcher
Mar 10, 2001 Statistics dataset and to the CICINTRV summary dataset.
Change 19.024 Cosmetic. Status variables DVLCSMSS DVLCSMS2-DVLCSMS8
VMACDCOL are now formatted with existing MGDCOVS format, as were
Mar 8, 2001 variables DVLSMSS DVLSMSS2-DVLSMSS8.
Thanks to Jim S. Horne, Lowe's Companies, USA.
Change 19.023 Change 19.015 removed NRCPUS from TYPE70PR dataset; this
ANALRMFR change revises the RMF reporting to match that change.
Mar 6, 2001
Change 19.022 The First SQL Page Number QW0006PN, a 3-byte character to
ANALDB2R display up to 999, was replaced by QW0006PG, a numeric,
Mar 6, 2001 so now the '1ST PAGE' value for large values will print.
Thanks to Andrew Schmid, EDS Canberra, AUSTRALIA.
Change 19.021 If the rarely used TEMP01 and TEMP02 options of VMXGSUM
VMXGSUM are used, and TEMP02 is tape format, there will be a SAS
Mar 6, 2001 error attempting to open two datases on a tape.
Thanks to Khoan Dang, MBNA, USA.
Change 19.020 Using %VMXGRMFI(PDB=SMF) caused ERROR: FILE WORK.MERGERMF
VMXGRMFI NOT FOUND. The default, PDB=PDB, worked fine. The test
Mar 6, 2001 %ELSE %IF &PDB=PDB %THEN %DO; was changed to now read:
%IF &PDB=PDB OR &PDB=SMF %THEN %DO;
Thanks to Wayne A. Schumack, Blue Cross of Minnesota, USA.
Change 19.019 INPUT EXCEEDED RECORD LENGTH SMF 102 subtype 140 because
VMAC102 new fields INCOMPATIBLY inserted by DB2 5.1 were not read
Mar 5, 2001 in for this Audit Trace record subtype.
Thanks to Brad Dorn, Kohl's, USA.
Change 19.018 Protection for zero-divide in new z/OS variable SMF70CPA,
VMAC7072 (no actual error in the MXG output, only a hex dump print
Mar 5, 2001 on the SAS log) because OS/390 2.10 unexpectedly writes
SMF type 70 records with LENCPUC=40, (2.10 doc says 28).
If LENCPUC GE 40, MXG Inputs SMF70CPA/SMF70WLA/SMF70LAC
(new MSU capacity stuff) and then divided without testing
the denominator before the divide, and the new fields are
all zero in the R2.10 extended segment. And MXG expected
SMF70WLA to be missing if the record did not contain that
new MSU capacity measure, using IF SMF70WLA=. THEN DO...
logic in VMXGRMFI to detect its presence, so this change
also forces SMF70WLA=. if it is found to contain zeroes.
Thanks to Alan Freed, Automatic Data Processing, USA.
Change 19.017 Support for APAR OW46268 for TYPE74 USS Kernel data was
VMAC74 already in place; incorrect format and documentation was
Mar 5, 2001 recognized during MXG validation of those fields.
Change 19.016 Cosmetic. The A2THID=UPCASE(AUTHID) should have been
ANALDB2R AUTHID (only impact would be if you typed selection names
Mar 1, 2001 in lower case, and none would have been selected). Three
repeated IF AUTHID=:' ' THEN AUTHID=' ' "compiler
fakers" were redundant and were deleted.
Thanks to Tom Parker, CSC Hogan Systems, USA.
Change 19.015 If you have 2064 (z900) CPU with ICF-s installed, and
ASUM70PR do not have the PTF for APAR OW48190 installed, the count
VMAC7072 of ICF-s will be incorrect, causing incorrect CPU busy.
VMXGRMFI Without that APAR (no PTF until April), the IBM type 70
Mar 1, 2001 70 field SMF70CIX does NOT properly flag ICF CPUs, so the
Mar 6, 2001 PARTNCPU and LPARCPUS variables that count real CPs will
be wrong in TYPE70, TYPE70PR, ASUM70PR, and RMFINTRV, and
MSU4HRAV will also be incorrect. This change completely
revises how ICFs are counted, moving that logic from the
ASUM70PR back into VMAC7072 so all four datasets above
will be correct, and this change corrects the count with
logic that works whether or not you have installed the
PTF for OW48190.
Caveat: You must use VMAC7072, VMXGRMFI, and ASUM70PR
from this change; make sure you do not have any of those
three members in your "USERID.SOURCLIB" (or if you do,
you must re-tailor your changes into these new members).
First, the code loops thru the type 70 PR/SM segments to
count the number of non-zero values of SMF70CIX. If the
count is always zero, then APAR OW37565 (which populates
SMF70CIX with 1 for "CP" and 2 for "ICF") is not on this
system, so ICF's can't be counted. A non-zero value in
NRCIXGT0 proves the SMF70CIX field is valid, and IFCs can
be counted, and then I can recognize an invalid value of
zero in SMF70CIX is really an ICF, as that is the IBM
error that will be fixed by OW48190s PTF: SMF70CIX had a
zero instead of a 2 for an ICF. This allows MXG to count
and remove ICFs from the PARTNCPU count of CPs in a box.
However, the variable PARTNCPU in TYPE70 and TYPE70PR did
include ICFs; it was only in PDB.ASUM70PR/PDB.RMFINTRV
that both PARTNCPU and LPARCPUS were corrected for ICFs.
This change now corrects all four datasets, so the logic
in ASUM70PR (which both creates PDB.ASUM70PR and updates
PDB.RMFINTRV) was revised to no longer subtract ICFs.
Note also that VMXGRMFI at Change 19.012 is also neeeded
to support the 2064 processors, independent of this fix,
for variable MSU4HRAV valid on 2064s, so it is listed
here as well to alert you to use all three new memgers.
-Variable NRCPUS was removed from TYPE70PR, because it did
not belong there; LPARCPUS is the correct variable that
counts CPs in this LPAR, while NRCPUS is a TYPE70-only
variable that counted the CPUs in the SYSTEM that wrote
this type 70 record, and NRCPUS in TYPE70PR could be
misleading and/or confusing.
-Mar 6 additions. The summarization interval in ASUM70PR
and RMFINTRV is set in member IMACRMFI's macro _DURSET
definition; by default, each original interval is output.
If you change the interval of your PDB.RMFINTRV data:
a. You can tailor your own RMFINTRV member, using
VMXGRMFI(INTERVAL=HOUR);
but then you have to change the _DURSET definition in
your IMACRMFI member to set variable STARTIME hourly:
STARTIME=DHMS(DATE,HOUR,0,0);
because member ASUM70PR not only created PDB.ASUM70PR
using _DURSET, but also then reads and rewrites the
PDB.RMFINTRV dataset (adding Platform Busy, Percent of
Hardware, etc., variables), so, instead,
b. Leave the default INTERVAL=DURSET, in the RMFINTRV
member (if you still need one), and just tailor the
STARTIME value in member IMACRMFI.
c. Watch for a possible re-design to make it consistent.
Thanks to Pat Curren, SuperValu Inc, USA.
Change 19.014 The original text of this change (about CPUTM in CICSTRAN
VMAC110 possibly being the sum of many variables) was wrong; the
Feb 23, 2001 MXG equation for billable CPU time in CICSTRAN:
Mar 12, 2001 CPUTM=SUM(TASCPUTM,CPURLSTM).
has always been correct and should not be changed.
See member ADOC110 for the new note on CPU capture in the
CICSTRAN, CICDS/CICINTRV, SMFINTRV and TYPE72/72GO data,
which provides a schematic of what's captured where.
Thanks to Trevor A. Holland, TELSTRA, AUSTRALIA.
Change 19.013 Support for TLMS Release 5.5 (COMPATIBLE). Two new
VMACTLMS variables, BACUNIT (Create Unit) and BALUNIT (Last Unit)
Feb 23, 2001 were added compatibly at the end of the record; both of
these new fields were actually added back in Release 5.4.
Thanks to Jon Whitcomb, Great Lakes Higher Education Corp, USA.
Change 19.012 Change 18.348 created QWACALOG/AWCL/AWAR/OCSE/SLSE/DSSE/
ASUMDB2A OTSE/IXLT from QWAX variables, but did so incorrectly,
VMACDB2 they were not formatted as TIME12, and ASUMDB2A was not
Feb 23, 2001 revised to include the QWACs instead of the QWAXs.
Apr 4, 2001 Line 105 in 18.18's ASUMDB2A was removed to eliminate the
"duplicate variables" message (but it had no impact).
Thanks to Chris Weston, SAS Institute ITSV, USA.
Change 19.011 MXG 18.18 only, new variables only. Incorrect SUBSTR()
VMXGRMFI argument caused CPCNRCPU to be missing, CPFCNAME could
Feb 19, 2001 have extraneous characters, CPUTYPE='2064'x was not found
Mar 1, 2001 in the MG070CP table because CPCMODE3='404040'x should be
removed. The correct block of code now reads:
END;
CPUSTUFI=CPUTYPE!!CPUVERS1!!CPCMODE3;
CPUSTUFO=PUT(CPUSTUFI,$MG070CP.);
IF CPUSTUFO NE CPUSTUFI THEN DO;
CPCMSU =INPUT(SUBSTR(CPUSTUFO,1,4),4.);
CPCFNAME=SUBSTR(CPUSTUFO,6,8);
CECSUSEC=INPUT(SUBSTR(CPUSTUFO,15,10),10.);
CPCNRCPU=INPUT(SUBSTR(CPUSTUFO,26,2),2.);
SMF70WLA=CPCMSU*NRCPUS/MAX(CPCNRCPU,PARTNCPU,NRCPUS)
END;
No change was made to the logic in member FORMATS that
creates the MG070CP format, but comments that describe
that format's format were revised to match the format.
Note: This correction only applied if the FORMAT was
used. If SMF70WLA was populated, the FORMAT is
not used. But Change 20.168 is then needed.
Thanks to Pat Curren, SuperValu Inc, USA.
Change 19.010 The FTPREPLY character variable contains '000000FA'x, but
VMACTCP is converted by this change to ' 250', its numeric value
Feb 19, 2001 in a character variable, by inserting this statement
FTPREPLY=PUT(INPUT(FTPREPLY,&PIB.4.),4.);
and by changing the input from $EBCDIC4. to $CHAR4. to
prevent conversion of the binary value.
Using $CHAR versus $EBCDIC under OS/390 doesn't matter
here, but under ASCII, leaving the $EBCDIC4. informat
would convert any binary value that happened to be a
valid EBCDIC character into its ASCII equivalent:
(eg: '0000C1FA'x becomes '000041FA'x when INPUT with
$EBCDIC4. informat under ASCII SAS.)
Now the Reply values for the Client (FTPREPLY) will be in
the same format as the Server (FTPRSRSR) reply.
Change 19.009 Support for CA/TNG post-9907 (INCOMPAT). The initial MXG
VMACTNG support was for the "old" data records, which had simple
Feb 19, 2001 data format, but CA's complete revision (with internal
version 6 or higher), with its base-36 counting and with
repeat-count counters, is now supported with this change.
Thanks to Roman Jost, Gjensidige, NORWAY.
Change 19.008 Variable SYNCNAME was added to the KEEP= for IMS597 so
VMACIMSA that variable PROGRAM will be populated in Fast Path
Feb 19, 2001 dataset.
Thanks to Bruce Widlund, Merrill Consultants, USA.
Change 19.007 MXG 18.18 only. The BY statement in _SHPSUGL was missing
VMACMWSU its ending semicolon, and the extra semicolon at the end
VMACMWUX of MACRO _BHPUXDS was removed.
Feb 19, 2001
Change 19.006 The calculation of RDHITPCT in TYPE42DS was incorrect in
VMAC42 the denominator; the revised equation is:
Feb 19, 2001 RDHITPCT=(CACHHITS-WRITHITS)/(CACHCAND-WRITCAND);
The previous denominator was just CACHCAND and the value
calculated was too low.
Thanks to Ep van der ES, Dow Chemicals, BELGIUM.
Change 19.005 NTSMF files that have been COPYed and APPENDed without
VMACNTSM the /B parameter (search NEWSLTRS) and/or concatenated on
Feb 16, 2001 MVS have been found with a record of nulls (hex zeroes)
that MXG did not expect. This change detects and deletes
those records, printing a message that these bad records
were found in your input.
Thanks to Howard Glastetter, Weyerhaeuser, USA.
Change 19.004 SAS does not permit an ARRAY name to be the same as a
VMACSYNC variable name; a new ARRAY named DD defined in VMACSYNC
Feb 16, 2001 conflicted with a variable named DD in VMACRMDS, (only
if you tailored MXG to process both RMDS and SYNCSORT SMF
records in the same MXG datastep). Changing the ARRAY
names in VMACSYNC transparently corrects the conflict.
Thanks to Chris Weston, SAS Institute ITSV, USA.
Change 19.003 IMS Version 7 requires Omegamon/IMS V500, but Candle says
TYPEITRF the upgrade from V300 to V500 is transparent as far as
Feb 14, 2001 their ITRF data records are concerned.
Thanks to Gene Quinn, Blue Cross of Rhode Island, USA
Change 19.002 Two new VGETxxx %MACROs were included in MXG 18.18 but
VGETENG they (and the new VGETxxx prefix) were not documented.
VGETOBS %MACROS that "Get" and return a value are named VGETxxx,
VMXGENG and the value "got" is returned in a macro variable that
Feb 14, 2001 is named VGETxxx. The two new implementations are:
Executing Will return
%VGETENG(DDNAME=yyyyyyyy); The Name of the SAS Engine
that created that yyyyyyyy
data library, in &VGETENG.
(Needed by MXG so we can
exploit V8 features.)
%VGETOBS(DDNAME=,DATASET=); The number of observations
in dataset DDNAME.DATASET
in &VGETOBS.
The earlier %VMXGENG macro still exists for compatibility
but it now invokes %VGETENG.
Thanks to Chuck Hopf, MBNA, USA.
Change 19.001 The _BTY30UV BY list in VMAC30 was not quite the same as
VMAC30 the order needed in BUILDPDB, and was corrected to be:
Feb 12, 2001 MACRO_BTY30UV READTIME JOB JESNR INITTIME INTETIME
DESCENDING INTBTIME MULTIDD EXTRADD %
(Note that SMFTIME is appended during the initial NODUP
sort in _STY30UV sort, but is not needed subsequently.)
Thanks to Barry McQueen, Department of Defence, Australia.
LASTCHANGE: Version 19.