COPYRIGHT (C) 1984-2007 MERRILL CONSULTANTS DALLAS TEXAS USA
CHANGE 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.
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-formatted PIB4 varibles 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 Horne, Lowes, 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
VMXGINIT work.DB2STAT2 with WORK.DB2STAT2, which was not equal, so
Feb 13, 2002 VMXGDEL deleted the WORK.DB2STAT2 dataset it had built.
Feb 13, 2002 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
VGETDUR 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 Mike 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.
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!
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 IEFSMF30 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, 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 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 Mike 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, 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 with 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 statment 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 Tay