COPYRIGHT (C) 1984-2025 MERRILL CONSULTANTS DALLAS TEXAS USA
MXG CHANGES 20.20
=========================member=CHANGE20================================
/* COPYRIGHT (C) 1984-2003 MERRILL CONSULTANTS DALLAS TEXAS USA */
MXG Version 20.20 is dated Feb 7, 2003, thru Change 20.341.
MXG Version 20.12 was dated Feb 3, 2003, thru Change 20.335.
MXG Version 20.11 was dated Jan 30, 2003, thru Change 20.330.
MXG Version 20.10 was dated Jan 3, 2003, thru Change 20.307.
MXG Version 20.09 was dated Dec 20, 2002, thru Change 20.299.
MXG Version 20.08 was dated Dec 4, 2002, thru Change 20.280.
MXG Version 20.07 was dated Nov 4, 2002, thru Change 20.244.
MXG Version 20.06 was dated Oct 7, 2002, thru Change 20.215.
MXG Version 20.05 was dated Sep 6, 2002, thru Change 20.186.
First MXG Version 20.05 was dated Sep 1, 2002, thru Change 20.177.
MXG Newsletter FORTY-ONE was dated Sep 1, 2002.
MXG Version 20.04 was dated Aug 12, 2002, thru Change 20.157.
MXG Version 20.03 was dated Jun 19, 2002, thru Change 20.111.
MXG Version 20.02 was dated May 8, 2002, thru Change 20.082.
Final MXG Version 20.01 was dated Apr 11, 2002, thru Change 20.061.
Second MXG Version 20.01 was dated Apr 9, 2002, thru Change 20.058.
First MXG Version 20.01 was dated Apr 1, 2002, thru Change 20.046.
Annual MXG Version 19.19 was dated Feb 14, 2002, thru Change 19.300.
MXG Newsletter FORTY was dated Feb 14, 2002.
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 20.20 is now available upon request.
II. Incompatibilities and Installation of MXG 20.20.
III. Online Documentation of MXG Software.
IV. Changes Log
=======================================================================
I. MXG Software Version 20.20 is now available.
Major enhancements added in MXG 20.20
ASMTAPES 20.320 ML-27 now robust, low CPU, sees VTS, no XMEM, etc.
ML-27 eliminates the cross memory call and 0E0s,
changes interval to 0.5 seconds, which captures
all VTS allocations and most VTS mounts
TYPETMO2 20.335 Support for ASG/TMON CICS V2.2 INCOMPATIBLE.
TYPEXAM 20.315 Support for Velocity Software's ESAMON VM Monitor 3.2
and support for TCP and Linux data almost made it.
TYPE28 20.316 Support for Tivoli Netview NPM 2.7 SMF 28 records.
TYPE102 20.336 Support for IFCID=247 in T102S2347 dataset.
TYPEEDGR 20.331 Support for DFSMSrmm Extended Extract 'X' records.
TYPEESPH 20.318 Support for Cybermation's ESP Product JOBHIST file.
TYPESYNC 20.309 Support for SYNCSORT for z/OS 1.1 SMF record.
IMAC6ESS 20.332 Support for more ESS variables (on OUTPUT statement)
TYPERMFV 20.334 Numerous enhancements/corrections to RMF III support.
BUILDPDB 20.330 New CSTORE30,ESTORE30 variables in STEPS,SMFINTRV.
TYPE30 20.330 New CSTORE30,ESTORE30 variables in TYPE30_4,_5,_V.
TYPE30 20.310 TYPE30TD now has subtypes 2, 3, and 4 output.
ANAL116 20.313 Example graphs of MQ Series SMF 116 data.
VGETJESN 20.326 Type 30s with JCTJOBID='INTnnnnn' protected.
UNIXSAR 20.314 Enhancements to process unix sar command output.
VMXGFOR 20.327 All %VMXGFOR were removed, to avoid a SAS zap.
BUILDPDB 20.319 OMVS task filled //SPIN, had TYPETASK='JOB' in error.
BUILDPDB 20.310 TYPE30TD now has subtypes 2, 3, and 4 output.
JCLUOWP 20.312 JCL example for ASUMUOW using Views/Pipes corrected.
UTILBLDP 20.329 Enhancement if BUILDPDB=NO is specified.
BLDNTPDB 20.323 Some combinations of arguments didn't work right.
TYPEOPC 20.321 IBM's OPC Log causes INVALID ARGUMENT TO FUNCTION....
TYPE79 20.325 TYPE792 was incorrectly deaccumulated.
TYPESRMH 20.317 Security Resource Manager for MVS V2.3 correction.
Many 20.324 Semi-colons added after each _Edddddd exit statement.
Versions 20.11 and 20.12 were QA tests, sent to only a few sites.
Major enhancements added in MXG 20.10
TYPE7072 20.307 Errors in TYPE72GO (MXG 20.08-20.09 only) corrected.
TYPENSPY 20.305 Support for NetSpy Version 6 subtypes G,H (COMPAT).
TYPEIDMS 20.304 Support for IDMS V1500 new subtypes 13, 14, 15.
TYPECIMS 20.306 No observations in CIMSDBDS after Change 20.138.
Major enhancements added in MXG 20.09
VMAC115 20.288 Support for MQSeries V5.3 (COMPATIBLE) new data.
VMAC116 20.288 Support for MQSeries V5.3 (COMPATIBLE) new data.
FORMATS 20.291 Support for APAR OW57121 new SMF 99 trace codes.
TYPE94 20.283 Support for undoc SMF 94 Subtype 2, heuristically.
REXXWLM 20.289 Support to read Workload Manager's WLM Defs PDS.
A very slick REXX exec and SAS step to output the WLM
definitions into a SAS dataset.
TYPEQACS 20.295 AS/400 CPU times merged in optional QACSCPU dataset.
ANAL94 20.294 VTS activity reports selection SUBREP= parm added.
TYPE110 20.293 UNKNOWN STID=115 messages should not exist.
FORMATS 20.292 Mapping of SAS Procedure Name to Product updated.
TYPENTSM 20.286 MicroSoft added instance names for SMF objects.
RMFINTRV 20.297 Workloads can use SYSTEM/SYSPLEX as criteria.
Major enhancements added in MXG 20.08
TYPEQACS 20.260 Support for AS/400 5.2 Collection Services (INCOMPAT)
UTILEXCL 20.256 Major UTILEXCL enhancement, MCTSSDCN/DRL DO grouping,
so you don't have to rerun UTILEXCL for new APPLIDs.
TYPENTSM 20.276 Support for NTSMF new objects from MS Exchange 2000
SP3, XP Professional, Citrix, DataCore, MSMQ, and
changes to PROCESSOR and MQSERIES objects.
TYPE94 20.265 SMF 94 FC4001 undoc fields caused wrong values.
TYPEMVCI 20.263 Support for BMC MVCICS 5.6, fix for 5.5 CMRDETL data.
TYPETMO2 20.253 Support for ASG-Landmark TMON/V2.1 TH01595 (COMPAT)
TYPETAND 20.250 Support for Tandem G07 new data, fix TANDPROC G06.
CONFIGV9 20.252 Support for Version 9 TS M0 Production Release.
AUTOEXEC 20.252 Support for Version 9 TS M0 Production Release.
TYPE79 20.274 Support for APAR OW56739, RMF 79 subtype 3.
TYPE7072 20.274 Support for APAR OW56739, RMF 72 subtype 3.
GRAFWRKX 20.273 Workload Graph examples include MSU used by workload.
ANALRMFR 20.277 RMF Channel Activity Report CHP= selectivity added.
TYPE71 20.259 Medium Impact Frames ESFRMExx are now input in order.
TYPE119 20.267 TSIPxxxx variables wrong in TYPS11905, other fixes.
Major enhancements added in MXG 20.07
Status of ASMTAPES:
ML-26 tests show no improvement; CPU time same as ML-25, even
when scan excluded VTS devices. Update: USE ML-27, in 20.20.
TYPE73 has PCHANBY/PNCHANBY mising with SMF73CMG=0.
Support for CICS APAR PQ63143 changes to 110-2 stats; only STID=24
(for CICAUTO) was INCOMPATIBLY changed.
Support for RMF 74-4 APAR OW55968 (R744SST 4 to 8-byte).
Support for APAR OW54010 Large Virtual Memory (>2GB).
Support for Candle Omegamon for CICS V520 User SMF.
Support for Control-D "SF2" User SMF record.
Support for Control-D "POD" User SMF record.
Circumvention for IDMS Version 1500, no new data yet.
UTILEXCL USERCHAR variable generated wrong INCLUDE post 20.148
TYPEDB2 Negative DB2SRBTM with DB2 V7 forced back to missing.
Trending for TYPE23 (SMF Buffer Usage) was wrong.
Documentation: Don't use TEMP01 with %VMXGSUM.
Example of RACF Filtering with TYPE80A and MACJBCK=.
TYPE80A Support for UID/HOME/PROGRAM OMVS/USS RACF fields.
Major enhancements added in MXG 20.06
Status of ASMTAPES:
ML-25 uses lots more CPU time (30 minutes per day versus 30 secs
with ML-19) and there is no immediate fix. Update: Use ML-27.
Support for APAR OW52396 (no change) SMF 74-7 FICON.
Support for APAR OW56162 new SMF 64 CATALOG UPDATE.
Support for SMF 94 subtype 2 and subtype 1 new stuff.
Support for z/OS 1.4 is in MXG 20.06, but MXG 20.03 or later is all
that is truly REQUIRED for z/OS 1.4. The minor 1.4 enhancements
that are now supported (i.e., decoded) by MXG 20.06 have very
little impact. See Change 20.101 for why 20.03 is the minimum,
and see Change 20.205 for the z/OS 1.4 enhancements.
However, if you're leading edge enough to be install new releases
of your operating system, then you surely should install the most
recent MXG Version (20.06, this week), because of likely changes
to at least one of your other products; the current MXG is always
more aware of other product's changes than was the prior version.
And installing a new MXG Version, now, is very easy, and with no
changes needed to your MXG tailoring, very simple.
Note that IBM has announced that the next major z/OS release is
scheduled for March, 2004 (yes, 18 months), to be followed by a
release in September, 2004, and thereafter major z/OS releases
will be annually, each Fall.
But you can still expect to see a new MXG Version available
practically every month, as we keep up with constant change in
the other 399 products whose data records are supported by MXG;
z/OS itself is but one product.
Support for SMF 120 subtype 7 and 8 WebSphere 4.0.1.
Support for BMC's Mainview for DB2 THRDHIST file.
Support for ASG-Landmark TMON/MVS V3 (INCOMPATIBLE).
Support for CICS Transaction Resource Class new data.
Support for SAMS:VANTAGE 3.2.0 OBJ=POOLS record.
Major enhancements added in MXG 20.05
ASMTAPES: ML-25 corrects CPU loop or 0C4 in ML-24. Now: Use ML-27.
Support for Oracle and Analysis Server NTSMF objects.
Revision/enhancement of MSU calculations in RMFINTRV, ASUM70PR and
ASUMCEC, plus description of important MSU variables and MXG
recommendation to use MSU instead of MIPS. Change 20.168.
Support for EMC's Catalog Solution user SMF record.
Technical Note in NEWSLETTER FORTY-ONE: CICS-DB2 ACCOUNTING change.
Major enhancements added in MXG 20.04:
ASMTAPES: ML-24. Corrects 0E0 logrec, CPU loop. Update: Use ML-27.
Support for APAR PQ61349 to SMF 103 records.
Support for APAR OW54007 to SMF 42 records..
Support for RMF 74 subtype 7 FICON Port data.
Support for type 90 subtype 32 in TYPE90A member
Support for multiple CICS user fields in UTILEXCL.
Support for IMPLEX Version 2.1 has been coded.
Landmark TMON/CICS datetimes wrong zone if GMTOFF GT 0.
Landmark TMON/DB2 datetimes wrong zone if GMTOFF GT 0.
Support for NTSMF 2.4.4, MODULE Object, Disk pct and Averages.
Support for NTSMF File System Collector. DCOLLECT for NT!
New ANALDB2K merges package DB2ACCTP data with DB2ACCT data.
Major enhancements added in MXG 20.03:
Support for JES "Z2 Mode" (INCOMPATIBLE JESNR): YOU MUST HAVE THIS
version before you enable Z2 mode in z/OS 1.2 or later!!!!
ML-23 of MXGTMNT, skips over list of UCB addresses for VTS devices.
Support for subtype 27/28 of STK HCS/VSM records.
Support for many new TNG Platforms (SOL, AIX) etc.
Support for G06/G08 TANDPROC LRECL=442 (INCOMPAT).
Support for NTSMF Citrix process record.
Support for AIX PTX (Performance ToolBox) adds objects/variables.
GRAFWRKX Enhanced "Weighted LPAR Capacity" Graph/Tabular reports.
ANALRMFR "RMF HTTP Server Report" multiple servers, etc.
Domain Error in TYPE78, TYPE79 and TYPE91 were corrected.
PCHANBY missing for TYPE73 Coupling Facility channels.
Doc: Variable UOWTIME may look wrong, but it's okay.
Variable MSU72 created in TYPE72/TYPE72GO.
EXECAPPL, the "execution" APPLID, added to PDB.ASUMUOW.
UTILEXCL Final (?) cleanup covers all reported optional data.
Major enhancements added in MXG 20.02:
Support for z/OS 1.3 (COMPATIBLE, except SMF 42 needs MXG fix).
Biggest enhancement: new TYPE4221 dataset records every delete
of a PDS or PDSE member, and who dun it.
Support for APAR OW52227 (Active Application State) for WLM.
New state counters are used, changing percent calculations.
Support for multiple CICS versions with EXCLUDEs added in UTILEXCL.
Support for unexpected z/VM record with DATABYTE=0, caused STOP.
Support for IBM Product NPM/IP monitor user SMF record.
Support for TMON/CICS TCE 2.1 (COMPLETELY INCOMPATIBLE).
Support for full LRECL and VBS output for RMF III in ASMRMFV.
SAS Inherit option created wrong label in ANAL94.
Major enhancements added in MXG 20.01:
CPU Busy Pct in TYPE70/TYPE70PR/ASUM70PR wrong with WLM IRD.
There is no correction yet; see text of Change 20.046.
Additional corrections to UTILEXCL.
Support for z800 2066 CPU factors for OS/390 R2.8-R2.10.
Support for Top Secret V5.2, INCOMPATIBLE.
Support for Mobius RDS InfoPac Subtypes 6 and 7.
Support for Oracle OSDI format (8.1.7) SMF record INCOMPATIBLE.
Support for RMF III Enclave Table ENCG3.
Support for CA TNG Windows 2000 performance cube.
New ASUMUOWT creates PDB.ASUMUOW from Landmark TMON + DB2ACCT.
Enhanced UTILBLDP, examples for only RMFINTRV, only JOBS, etc.
MXG 19.19 corrections:
- TYPEIMSA Syntax error: Two %%VMXGTIME should be %VMXGTIME.
- AS/400 JBCPU/JBTCPU wrong in QAPMJOBM, IBM doc was wrong.
- VMXGUOW did not increment SPINCNT for ASUMUOW.
- If you used the new UTILEXCL utility to create your IMACEXCL, it
causes ASUMUOW to syntax fail; some computed variables weren't.
Also, some optional segments were not correctly recognized.
And it is enhanced to report if you have deleted any variables
are required to create ASUMUOW.
- DAILYDSN writes to PDB versus DATASETS; four _P should be _L.
- JCLTEST6 SAS V6 only, temp var SYS000008 name is too long.
- VMXGSUM with OPTIONS OBS=0 could cause errors.
See member NEWSLTRS or the Newsletters frame at www.mxg.com for
current MXG Technical Notes that used to be in CHANGES.
MXG QA test are with SAS V8.2 and (archaic) SAS V6.09 on OS/390, and
SAS V8.2 on Windows 2000, but previous QA tests on Linux RH 7.2 had
confirmed MXG's unix compatibility, so MXG should execute under SAS
V8.2 or later on every possible SAS platform!
MXG has also executed without error under SAS Version 9 beta, on both
"MVS" and Windows platforms.
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 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
z/OS 1.2, IRD enhancements Apr 26, 2002 20.01
z/OS 1.2+ APAR OW52227 Apr 26, 2002 20.02
z/OS 1.3+ APAR OW52227 Apr 26, 2002 20.02
z/OS 1.2 JESNR Z2 MODE Apr 26, 2002 20.03
z/OS 1.3 JESNR Z2 MODE Apr 26, 2002 20.03
z/OS 1.4 Tolerate Sep 27, 2002 20.03
z/OS 1.4 Support Sep 27, 2002 20.06
CICS/ESA 3.2 Jun 28, 1991 9.9
CICS/ESA 3.3 Mar 28, 1992 10.01
CICS/ESA 4.1 Oct 27, 1994 13.09
CICS/ESA 5.1 aka CICS/TS V1R1 Sep 10, 1996 14.07
CICS-Transaction Server V1R1 Sep 10, 1996 14.07
CICS-TS V1R1 with APAR UN98309 Sep 15, 1997 15.06
CICS-TS V1R2 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 Jan 25, 2002 19.19
CICSTRAN subtype 1 support only *19.19
CICSTRAN subtype 2 completed *19.08
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 6.1.0 parallel DB2 Mar 15, 1999 19.19
DB2 7.1.0 parallel DB2 Mar 30, 2001 19.19
DB2 7.1.0 corrections Mar 30, 2001 20.06
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
NTSMF 2.4.4 Aug 9, 2002 20.04
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
z/VM 3.1 DATABYTE=0 May 2, 2002 20.02
z/VM 4.2 ?? May 2, 2002 20.02
IMS 4.1 Jul 4, 1994 12.02
IMS 5.1 Jun 9, 1996 14.05
IMS 6.1 ??? ?, 199? 20.01
IMS 7.1 ??? ?, 199? 20.01
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
Note: An asterisk before the version number indicates that this
entry was changed to a later version of MXG being required,
after it was found that the previous version did not support
the listed product level, usually the result of an APAR to
the product that modified the products data records.
Or a coding error in MXG could be the reason for the change!
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 82BA77 HOTFIX for
MVS-OS/390-z/OS which includes Critical fixes; see NEWSLTRS.
It has executed succesfully under SAS Version 9 Beta on both
MVS and Windows platforms.
See Newsletters 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 20.04
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 CICS/ESA 2.1 - 20.04
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
The Monitor for MVS/ESA 3.0 - 19.19
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 7.0 - ASMIMSL6/TYPEIMSA *20.01
IMS 6.1 - ASMIMSL6/TYPEIMSA *20.01
IMS 5.1 - ASMIMSL5/TYPEIMSA *19.08
Amdahl
APAF 4.1, 4.3 16.08
II. Incompatibilities and Installation of MXG 20.09.
1. Incompatibilities introduced in MXG 20.09 (since MXG 19.19):
a- Changes in MXG architecture made between 19.19 and 20.09 that might
introduce incompatibilities.
NONE.
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.
OBSERVATION COUNT CHANGE: xxxxxxxx more/fewer observations.
This new note will be the last line of new Changes that alter the
number of observations MXG creates in dataset xxxxxxxx.
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 19.19 now in MXG 20.12:
Dataset/
Member Change Description
Many 20.268 Syntax INPUT +(-4) @; replaces M4=-4; INPUT +M4 @;
Many 20.299 MXG Checked by SAS/ITSV Dictionary Build process.
Many 20.324 Semi-colons added after each _Edddddd exit statement.
ADOCxxxx 20.338 All 282 ADOCs updated with all variables, old text.
ADOCSASU 20.292 Mapping of SAS Procedure Name to Product updated.
ANAL116 20.313 Example graphs of MQ Series SMF 116 data.
ANAL94 20.080 Revised to use SMF94VLC rather than SMF94VLS.
ANAL94 20.294 VTS activity reports selection SUBREP= parm added.
ANALCICS 20.193 VARIABLE OPERATOR NOT FOUND if OPERATOR excluded.
ANALCNCR 20.224 KEEPIN= argument no longer used, won't cause failure.
ANALDB2K 20.128 New member combines DB2ACCTP with DB2ACCT data.
ANALPROG 20.075 SAS V8 INHERIT option caused wrong label for NRTIMES.
ANALRACF 20.015 Bogus SAS error; ENTITY was used as array name.
ANALREG 20.183 Example regression of two variables with DATA step.
ANALRMFR 20.104 "RMF HTTP Server Report" multiple servers, etc.
ANALRMFR 20.277 RMF Channel Activity Report CHP= selectivity added.
ASMRMFV 20.033 Support for RMF III Enclave Table ENCG3.
ASMRMFV 20.068 RMF III support enhanced and corrected.
ASMRMFV 20.135 OC4 ABEND in ASMRMFV if CSR table was empty.
ASMTAPES 20.320 ML-27 now robust, low CPU, sees VTS, no XMEM, etc.
ASUM42DS 20.124 SORTEDBY= in VMXGSUM required change to ASUM42DS.
ASUM7072 20.169 Variable LPnLAC (4-hr MSU) added to ASUM70PR/ASUMCEC.
ASUMDB2A 20.039 Tailoring example for dropped variables from DB2ACCT.
ASUMUOW 20.086 EXECAPPL, the "execution" APPLID, added to ASUMUOW.
ASUMUOWT 20.038 Create PDB.ASUMUOW from Landmark TMON/CICS + DB2ACCT.
ASUMUOWT 20.251 Change 20.221 to VMXGUOW caused ASUMUOWT to fail.
AUTOEXEC 20.252 Support for Version 9 TS M0 Production Release.
BLDNTPDB 20.323 Some combinations of arguments didn't work right.
BUILDPDB 20.310 TYPE30TD now has subtypes 2, 3, and 4 output.
BUILDPDB 20.319 OMVS task filled //SPIN, had TYPETASK='JOB' in error.
BUILDPDB 20.330 New CSTORE30,ESTORE30 variables in STEPS,SMFINTRV.
CONFIGV8 20.019 //USER or directory named "user" causes SAS errors.
CONFIGV9 20.252 Support for Version 9 TS M0 Production Release.
DAILYDSN 20.020 DCOLLECT datasets written to PDB instead of DATASETS.
EXddddd 20.266 EXdddddd members are now one executable statement.
FORMATS 20.127 IBM MSU Capacity for 7060s only in format table.
FORMATS 20.194 MSU constants updated for 2064-2xxx family.
FORMATS 20.291 Support for APAR OW57121 new SMF 99 trace codes.
FORMATS 20.292 Mapping of SAS Procedure Name to Product updated.
GRAFWRKX 20.105 Enhanced "Weighted LPAR Capacity" Graph/Tabular
GRAFWRKX 20.273 Workload Graph examples include MSU used by workload.
IMAC6ESS 20.332 Support for more ESS variables (on OUTPUT statement)
IMACESS6 20.090 Unknown ESS keys not skipped if GEPARMNR GT 1.
JCLTEST6 20.002 SAS V6, VMACTMV2, variable SYS000008 name too long.
JCLUOWP 20.312 JCL example for ASUMUOW using Views/Pipes corrected.
JCLUOWV 20.269 VARIABLE TIMESTMP NOT FOUND building ASUMUOW.
MONTHBLD 20.094 SORTEDBY= added to Monthly PDB datasets
READDB2 20.270 Enhancement for IFCIDs 202, 230, 230, not in SMF 102.
REXXWLM 20.289 Support to read Workload Manager's WLM Defs PDS.
RMFINTRV 20.168 MSU4HRAV corrected, MSU-related variables documented.
RMFINTRV 20.297 Workloads can use SYSTEM/SYSPLEX as criteria.
TRND23 20.239 Trending for TYPE23 (SMF Buffer Usage) was wrong.
TRNDRMFI 20.099 Variable MSU4HRMX was missing in TRNDRMFI.
TRNDRMFI 20.249 New TRENDOLD= parm lets you use GDGs for TREND.
TYPE102 20.228 QW0022TS/BT were wrong if your GMTOFFDB was non-zero.
TYPE102 20.336 Support for IFCID=247 in T102S2347 dataset.
TYPE103 20.104 TYPE103x HOSTNAME increased to $32
TYPE103 20.130 Support for APAR PQ61349.
TYPE108 20.032 Timestamps DOMBTIME/DOMETIME incorrect.
TYPE110 20.102 CICSJOUR was incorrect for CICS/ESA 4.1, 5.1.
TYPE110 20.108 Doc: Variable UOWTIME may look wrong, but it's okay.
TYPE110 20.200 Support for CICS Transaction Resource Class new data.
TYPE110 20.225 Support for CICS APAR PQ63143 changes to 110-2 stats.
TYPE110 20.293 UNKNOWN STID=115 messages should not exist.
TYPE119 20.085 Subtype 3 caused INVALID DATA, now corrected.
TYPE119 20.267 TSIPxxxx variables wrong in TYPS11905, other fixes.
TYPE120 20.029 Lower case "f" in DBCS variables changed to blank.
TYPE120 20.066 Datasets TYP120JC/JI were not sorted to PDB by _S120.
TYPE120 20.204 Support for SMF 120 subtype 7 and 8 WebSphere 4.0.1.
TYPE26J2 20.101 Support for JES "Z2 Mode" (INCOMPATIBLE JESNR).
TYPE26J2 20.149 TIMEBILD now uses correct SYSxxxx for time conversion
TYPE26J3 20.101 Support for JES "Z2 Mode" (INCOMPATIBLE JESNR).
TYPE28 20.316 Support for Tivoli Netview NPM 2.7 SMF 28 records.
TYPE30 20.082 Support for z/OS 1.3 (COMPATIBLE).
TYPE30 20.101 Support for JES "Z2 Mode" (INCOMPATIBLE JESNR).
TYPE30 20.197 JOB=JES2 blank READTIME caused INVALID READTIME msg.
TYPE30 20.310 TYPE30TD now has subtypes 2, 3, and 4 output.
TYPE30 20.330 New CSTORE30,ESTORE30 variables in TYPE30_4,_5,_V.
TYPE42 20.082 Support for z/OS 1.3 (MXG Change Required).
TYPE42 20.129 Support for APAR OW54007.
TYPE42 20.134 S42DSBUF was incorrect, buffer type wrong.
TYPE42 20.182 SMF42NRS, JPF,JPE,JNF,JNE documentation wrong.
TYPE6 20.101 Support for JES "Z2 Mode" (INCOMPATIBLE JESNR).
TYPE64 20.212 Support for APAR OW56162 new SMF 64 CATALOG UPDATE.
TYPE70 20.043 Support for z800 2066 CPUs at OS/390 R2.8-2.10.
TYPE70 20.046 PCTCPUBY etc wrong with WLM IRD controling CPUs.
TYPE7072 20.089 Variable MSU72 created in TYPE72/TYPE72GO.
TYPE7072 20.140A Values in SMF70CSF,ESF now correct, IBM doc wrong.
TYPE7072 20.169 Variable SMF70LAC (4-hr MSU) added to TYPE70PR
TYPE7072 20.274 Support for APAR OW56739, RMF 72 subtype 3.
TYPE7072 20.307 Errors in TYPE72GO (MXG 20.08-20.09 only) corrected.
TYPE71 20.259 Medium Impact Frames ESFRMExx are now input in order.
TYPE72GO 20.045 Variable VALDSAMP now reset to equal R723CTSA.
TYPE72GO 20.069 Support for APAR OW52227 (Active Appl State) for WLM.
TYPE73 20.096 SMF73ACR='CFS' TYPE73 obs had PCHANBY missing.
TYPE73 20.172 Variables PCHANBY/PNCHANBY/PBUSBY carried forward.
TYPE73 20.240 PCHANBY/PNCHANBY mising with SMF73CMG=0.
TYPE74 20.116 Support for type 74 subtype 7 FICON data.
TYPE74 20.205 Support for z/OS 1.4 (COMPATIBLE), minor change
TYPE74 20.213 Support for APAR OW52396 (no change) SMF 74-7 FICON.
TYPE74 20.241 Support for APAR OW55968 (R744SST 4 to 8-byte).
TYPE78 20.050 Domain Error in 78 IOP corrected.
TYPE78 20.077 Using TIMEBILD, STARTIME was converted twice.
TYPE78 20.235 Support for APAR OW54010 Large Virtual Memory (>2GB).
TYPE79 20.083 Domain Error in 79-12, new CMG data now DIF()'d.
TYPE79 20.205 Support for z/OS 1.4 (COMPATIBLE), minor change
TYPE79 20.274 Support for APAR OW56739, RMF 79 subtype 3.
TYPE79 20.325 TYPE792 was incorrectly deaccumulated.
TYPE80A 20.010 Support for Top Secret V.2.
TYPE80A 20.218 Support for UID/HOME/PROGRAM OMVS/USS RACF fields.
TYPE80A 20.226 Example of RACF Filtering with TYPE80A and MACJBCK=.
TYPE90A 20.125 Support for type 90 subtype 32 (don't use TYPE90).
TYPE90A 20.281 VERSN90 is binary in some subtypes, was EBCDIC.
TYPE91 20.097 Domain Error in SMF91SDI/SDO corrected.
TYPE94 20.080 SMF94VLS now contains characters, new SMF94VLC.
TYPE94 20.206 Support for SMF 94 subtype 2 and subtype 1 new stuff.
TYPE94 20.265 SMF 94 FC4001 undocumented fields caused wrong value.
TYPE94 20.283 SMF 94 Subtype 2 now heuristically decoded.
TYPEAIX 20.091 Enhanced AIX PTX (Performance ToolBox) adds obj/vars.
TYPECIMS 20.138 CIMSDBDS DBDORG='00'X no longer output.
TYPECIMS 20.306 No observations in CIMSDBDS after Change 20.138.
TYPECPOD 20.230 Support for Control-D "POD" User SMF record.
TYPECSF2 20.231 Support for Control-D "SF2" User SMF record.
TYPEDB2 20.173 QWAXvvvv variables shouldn't be used, but now valid.
TYPEDB2 20.195 DB2 QWACAWTK/M/N/O/Q ARNK/M/N/O/Q etc missing/wrong.
TYPEDB2 20.210 DB2 V6 variables QWACARLG & QWACAWLG were missing.
TYPEDB2 20.222 Negative DB2SRBTM with DB2 V7 forced back to missing.
TYPEDCOL 20.171 Variable DCDRECFM decodes FBA or VBA Record Formats.
TYPEEDGR 20.331 Support for DFSMSrmm Extended Extract 'X' records.
TYPEEMCS 20.165 Support for EMC's Catalog Solution user SMF record.
TYPEESPH 20.318 Support for Cybermation's ESP Product JOBHIST file.
TYPEHURN 20.248 Overlooked HU47xxxx and HU49xxxx variable input.
TYPEIDMS 20.237 Circumvention for IDMS Version 1500, no new data yet.
TYPEIDMS 20.304 Support for IDMS V1500 new subtypes 13, 14, 15.
TYPEIMSA 20.021 Syntax error. Two %%VMXGTIME( should be %VMXGTIME.
TYPEIPAC 20.014 Support for Mobius RDS InfoPac Subtypes 6 and 7.
TYPEMPLX 20.141 Support for IMPLEX Version 2.1 has been coded.
TYPEMVCI 20.263 Support for BMC MVCICS 5.6, fix for 5.5 CMRDETL data.
TYPENDM 20.211 NDM/Connect Direct writes invalid SMF record.
TYPENPIP 20.070 Support for new IBM Product NPM/IP monitor SMF.
TYPENSPY 20.305 Support for NetSpy Version 6 subtypes G,H (COMPAT).
TYPENTSM 20.100 Support for Citrix process record.
TYPENTSM 20.132 Support for NTSMF File System Collector. NT DCOLLECT!
TYPENTSM 20.144 PROCESS object POOLxxxx,HANDLES were wrong.
TYPENTSM 20.156 Support for NTSMF 2.4.4, MODULE Object, Disk percents
TYPENTSM 20.176 Support for Oracle and Analysis Server NTSMF objects.
TYPENTSM 20.276 Support for MS E2K SP3, XP Prof, new vendor objects.
TYPENTSM 20.286 MicroSoft added instance names for SMF objects.
TYPEOMCI 20.234 Support for Candle Omegamon for CICS V520 User SMF.
TYPEOMVT 20.189 Candle OMEGAMON/VTAM Release 5.2.0 IRNUM=27 corrected
TYPEOPC 20.321 IBM's OPC Log causes INVALID ARGUMENT TO FUNCTION....
TYPEORAC 20.007 Support for Oracle OSDI format (8.1.7) (INCOMPAT).
TYPEORAC 20.111 Oracle OSDI Subsystem Name text externalized.
TYPEQACS 20.004 JBCPU/JBTCPU wrong in QAPMJOBM, IBM doc is wrong.
TYPEQACS 20.078 AS400 4.5.0 INVALID data, 5.1.0 JBEDBC/JBTDCB fixed.
TYPEQACS 20.260 Support for AS/400 5.2 Collection Services (INCOMPAT)
TYPEQACS 20.295 AS/400 CPU times merged in optional QACSCPU dataset.
TYPERMFV 20.334 Numerous enhancements/corrections to RMF III support.
TYPESAMS 20.192 Support for SAMS:VANTAGE 3.2.0 OBJ=POOLS record.
TYPESASU 20.236 Variable SASPROD, SAS Product Name, now kept.
TYPESRMH 20.317 Security Resource Manager for MVS V2.3 correction.
TYPESTC 20.088 Support for St. 27/28/29 of STK HCS/VSM records.
TYPESTC 20.220 STC28TIM in STCVSM28 from STK User SMF was wrong.
TYPESTC 20.242 STK HSC Subtype 29 INPUT STATEMENT EXCEEDED error.
TYPESYNC 20.309 Support for SYNCSORT for z/OS 1.1 SMF record.
TYPETAND 20.106 Support for G06/G08 TANDPROC LRECL=442 (INCOMPAT).
TYPETAND 20.250 Support for Tandem G07 new data, fix TANDPROC G06.
TYPETMDB 20.095 TMON/DB2 Timestamps wrong if GMT Offset is nonzero.
TYPETMDB 20.139 Landmark TMON/DB2 datetimes wrong if GMTOFF GT 0.
TYPETMDB 20.161 Support of ASG-Landmark TMON/DB2 Version field 3.2.
TYPETMO2 20.072 Support for TMON/CICS TCE 2.1 (INCOMPATIBLE).
TYPETMO2 20.140 Landmark TMON/CICS datetimes wrong if GMTOFF GT 0.
TYPETMO2 20.187 MONITASK variables STORVIOL/ABNDMONI weren't created.
TYPETMO2 20.253 Support for ASG-Landmark TMON/V2.1 TH01595 (COMPAT)
TYPETMO2 20.335 Support for ASG/TMON CICS V2.2 INCOMPATIBLE.
TYPETMVS 20.201 Support for ASG-Landmark TMON/MVS V3 (INCOMPATIBLE).
TYPETNG 20.028 Support for CA TNG for Windows 2000.
TYPETNG 20.062 STARTIME in TNG datasets was an hour early.
TYPETNG 20.092 Support for many new TNG Platforms (SOL, AIX) etc.
TYPETNG 20.180 TNG Start Hour defaults to zero, externalized.
TYPETPMX 20.208 TYPETPMX variable SPACE renamed to SPACERQ.
TYPEVIOP 20.216 INPUT STATEMENT EXCEEDED with VIO PLUS SMF record.
TYPEVMXA 20.081 z/VM MONWRITE DATABYTE=0 caused MXG to stop reading.
TYPEXAM 20.315 Support for Velocity Software's ESAMON VM Monitor 3.2
TYPSMQM 20.188 Example member to read //SMF to create all MQM data.
TYPSTHST 20.202 Support for BMC's Mainview for DB2 THRDHIST file.
TYPSTHST 20.245A MACRO _THRDHST should have INFILE THRDHIST, not SMF.
UNIXSAR 20.314 Enhancements to process unix sar command output.
UTILBLDP 20.013 Enhancement, examples for only RMFINTRV, JOBS.
UTILBLDP 20.329 Enhancement if BUILDPDB=NO is specified.
UTILEXCL 20.008 UTILEXCL caused ASUMUOW to fail, missed IMS data.
UTILEXCL 20.040 Tests IF SEGLEFT GE CMODLENG now IF SEGLEN GE nn.
UTILEXCL 20.074 Excluded fields from multiple CICS versions support.
UTILEXCL 20.084 Final (?) cleanup covers all reported optional data.
UTILEXCL 20.118 Support for CANPROD2/CANPROD3 optional CICS data.
UTILEXCL 20.148 Support for multiple CMODNAME,CMODHEAD='USER' fields
UTILEXCL 20.223 USERCHAR variable generated wrong INCLUDE post 20.148
UTILEXCL 20.256 Major UTILEXCL enhancement, MCTSSDCN/DRL DO grouping.
UTILRMFI 20.162 Revised to use identical arguments as %VMXGRMFI.
VGETDSN 20.035 New utility to get DSNAME, can allocate next GDG.
VGETJESN 20.190 "Z2" Jnnnnnnn JESNR support protects SMF 6 record.
VGETJESN 20.326 Type 30s with JCTJOBID='INTnnnnn' protected.
VMAC115 20.288 Support for MQSeries V5.3 (COMPATIBLE) new data.
VMAC116 20.288 Support for MQSeries V5.3 (COMPATIBLE) new data.
VMAC7072 20.272 Zeroed MSU variables from old S/390 are now non-zero.
VMAC80A 20.257 Message VMAC80A.WARN. MORE DTP... revised, 15 kept.
VMXGFOR 20.327 All %VMXGFOR were removed, to avoid a SAS zap.
VMXGINIT 20.278 %UPCASE added by 19.295 was dropped in 20.019
VMXGINIT 20.296 Macro variables &TRNDIN,&TRNDOUT defined for TREND.
VMXGRMFI 20.017 OPTIONS OBS=0 could cause errors.
VMXGRMFI 20.079 Mismatch now reports all INn status variables.
VMXGSUM 20.017 OPTIONS OBS=0 could cause errors.
VMXGSUM 20.094 SORTEDBY= added to Output VMXGSUM dataset.
VMXGSUM 20.142 SORTEDBY= filed if dropped variable only in SUMBY=.
VMXGSUM 20.238 Documentation: Don't use TEMP01 with %VMXGSUM.
WEEK70PR 20.199 Typo SAT.TYPE70PR read twice, FRI not read.
WEEKBLD 20.094 SORTEDBY= added to WEEKLY PDB datasets
Inverse chronological list of all Changes:
NEXTCHANGE: Version 20.
====== Changes thru 20.341 were in MXG 20.20 dated Feb 5, 2003=========
Change 20.341 Support for APAR OW57396 adds two flag fields, SMF22CYS
VMAC22 and SMF22PCY to the TYPE22_A dataset (the APAR calls the
Feb 6, 2003 two fields SNSSDST3 and SSCBDVC4, to describe the reason
for the state-change interrupt during FlashCopy.
Thanks to Susan Greenlee, IBM, USA.
Change 20.340 Summarized RMFINTRV data (for example, RMFINTHR from 15
RMFINTRV minute RMFINTRV data) will have a high value for MSU4HRAV
Feb 6, 2003 in any interval that crosses an IPL. The interval will
have a DURATM considerably smaller than your requested
hour summary, so these intervals can be detected/deleted
by testing for DURATM less than your summary interval
This is an MXG coding error, only in RMFINTHR; the
ASUM70PR and ASUMCEC data is correct across an IPL
(but note that MXG keeps history, and uses those
prior hours, IBM's SMF70LAC starts new with each
IPL, so "correct" is in the eyes of the beholder).
and I will eventually take time and figure out how to
correct the logic, but not right now!
Jun 9 2003: See Change 21.094.
Thanks to Craig Collins, State of Wisconsin, USA.
Change 20.339 Support for MainView TCP/IP SMF record with many datasets
EXMVTPA and almost all of them are wrong; the only documentation
EXMVTPC available was the sample SAS code from BMC, and it was
EXMVTPD restructured into MXG source format, labeled, etc., and
EXMVTPF then the test records were examined, only to find that
EXMVTPH the data and sample code do not agree.
EXMVTPI If you are interested in this support, please contact me,
EXMVTPN send me your current SMF records, and I will pursue the
EXMVTPO actual DSECT documentation so I can rewrite the support.
EXMVTPP And since I could not validate the new support, there may
EXMVTPR be variable names in conflict with existing MXG names
EXMVTPS that may need to be changed.
EXMVTPT But at least the structure and contents of all of the 14
EXMVTPU new datasets is complete!
EXMVTPV
IMACMVTP
TYPEMVTP
TYPSMVTP
VMACMVTP
VMXGINIT
Feb 6, 2003
Change 20.338 All ADOCxxxx members were programatically updated with
ADOCs all variables created by MXG 20.10, but all existing
Feb 6, 2003 comments and descriptions (manually made) are preserved
by a slick utility program Freddie developed to read the
old and merge in the new (and by agreed syntax standards
in the ADOCs structure, so his program works!).
Thanks to Freddie Arie, TXU, USA.
Change 20.337 Using example 4 in UTILEXCL, which reads CICS records to
UTILEXCL create and write member IMACEXCL to your USERID.SOURCLIB
Feb 5, 2003 tailoring library, writing to this DD statement:
//IMACEXCL DD DSN=MXG.USERID(IMACEXCL),DISP=SHR
then the example reads that IMACEXCL member from that
dataset, using %INCLUDE SOURCLIB(IMACEXCL); from this DD:
//SOURCLIB DD DSN=MXG.USERID,DISP=SHR
// DD DSN=MXG.SOURCLIB,DISP=SHR
resulted in an UNDETERMINED SAS I/O ERROR and a SYSMSG
entry "OUT OF EXTENTS", with both SAS V8.2 and V9.0, but
only when:
the USERID.SOURCLIB was extended into another extent
by the writing of the IMACEXCL member to the PDS.
Breaking the example into two MVS steps did not fail; the
IMACEXCL member was read correctly from the extended-PDS
in the second step. While this will ultimately be fixed
by SAS (I hope!), if you use this technique of writing to
your USERID.SOURCLIB, you should make sure it has a large
primary, and compress it after each run, to avoid this
exposure.
That same error message is also documented in NEWSLTRS
for a completely un-related problem: if you have your
datasets in your //SOURCLIB concatenation that are
mixed PDS and PDSE source libraries.
Only all-PDS libraries is guaranteed to be error free!
The error will be discussed with SAS Institute, and this
note will be revised if a correction becomes available.
No code change was made; documentation only.
Thanks to MP Welch, SPRINT, USA.
Change 20.336 Support for DB2 Trace IFCID=247 (SMF 102 subtype 247) now
VMAC102 populates the trace variables in dataset T102S247.
Feb 2, 2003
Thanks to Terry L. Berman, DST Systems, USA.
====== Changes thru 20.335 were in MXG 20.12 dated Feb 2, 2003=========
Change 20.335 Support for ASG/Landmark TMON for CICS/ESA Version 2.2.
VMACTMO2 INCOMPATIBLE, causing INPUT STATEMENT EXCEEDED errors:
Feb 2, 2003 -Field inserted in 'TP' record header and sub records.
-Field inserted in 'TR' record header.
-Field inserted in 'TK' record header.
-Field inserted in 'TS' record header.
-Field inserted in 'T2' record header.
-Field inserted in 'TM' record header.
-Field inserted in 'TN' record header.
-Field inserted in 'TT' record header.
-Field inserted in 'TX' record header.
-Fields inserted and removed in 'TA' record.
-Some overlooked $CHAR fields are now formatted $HEX.
-Useful new MQSERIES counts/duration variables are created
in MONITASK dataset.
Change 20.334 -ZRBDVT kept twelve accumulated start and end values which
VMACRMFV are unneeded and are now dropped; the delta values are in
Feb 2, 2003 the six variables PENDTM DISCTM CONNTM DVBUSYTM CUBUSYTM
Feb 3, 2003 and SWPODLTM. The _SZRBDVT now actually sorts vice copy.
-ZRBGEI kept four accumulated start and end values which
are unneeded and are now dropped; the delta values are in
new variables GEIESPM and GEIESPR. OS/390 set several GEI
fields reserved, causing CPUWAITM to be zero and PCTCPUBY
to be missing. The PCTCPUBY is in dataset ZRBCPU.
-Variable ASIAUXSC is now divided by sample count, and the
_SZRBASI now actually sorts vice copy.
-ENCG3 record with RDW=804, DEO=@296 DEL=608 caused INPUT
STATEMENT EXCEEDED RECORD ERROR and is now protected, but
it was caused by using ASMRMFV program earlier than MXG
20.02, which corrected Enclave support. No-longer-needed
triplet variables are no longer kept.
-All _SZRBxxx macros now PROC SORT their dataset to PDB
(most just had a Data step) because their _BZRBxxx macro
now have BY-list variables of SYSPLEX SYSTEM SSHTIBEG and
possibly more.
Thanks to Betty Wong, Bank of America, USA.
Thanks to John Gebert, Office Depot, USA.
Change 20.333 Using READDBw with IFCIDS=ALL is strongly disrecommended,
READDB2 as it requires massive virtual storage and compile time
Jan 31, 2003 to generate the data step for all 300+ DB2 trace records,
and you could never have all those IFCIDs enabled; if you
did, you'd be running an SMF stress test, not a DB2 test!
but now, IFCIDS=ALL will compile correctly; Change 20.270
introduced syntax errors when IFCIDS=ALL was used.
Additionally, IFCIDS= 1 2 are now supported as arguments
(although they are redundant with ACCOUNT).
Thanks to John Gebert, Office Depot, USA.
Change 20.332 -IMAC6ESS: Support for optional ESS variables from OUTPUT
FORMATS statements, including the USERDATA= field, which can be
IMAC6ESS used: USERDATA=(ACCT=123456) to set accounting fields
VMAC6 for each OUTPUT statement, new variable ESSUSDAT, plus
Jan 31, 2003 less-important variables ESSTRC, ESSDATCK, ESSCHARS-4,
Feb 3, 2003 ESSUCS and ESS0013 for undocumented IEFDOKEY='0013'x.
Feb 4, 2003 Protection added if more than four ESSCHARn fields are in
the SMF record.
-VMAC6: Variable BINUSED='00'X is set for non-PSF type 6
records; all BINxxxxx fields only exist in APF-PSF data.
-FORMATS. Variable BINUSED's format MG006BN was updated
for bins 3,4 and combo's of bins, "NOT PSF" for '00'x.
Thanks to Ricke Godehard, Itellium, GERMANY.
Change 20.331 Support for DFSMSrmm Extended Extract Data Set Records,
EXEDGRX which are written as EDGRTYPE='X', along with the other
IMACEDGR records, by IBM's EDGHSKP program to a flat file that is
VMACEDGR read by MXG from the INFILE name of EDGHSKP. The new 'X'
VMXGINIT record creates new EDGRXEXT dataset with all variables
Jan 30, 2003 from the 'V' volume record (MXG dataset EDGRVEXT) and all
of the variables from the 'D' dataset record (MXG dataset
EDGRDEXT); now that I've written the code to create the
new dataset from the new X record, I realize I could have
instead created it simply by MERGEing the EDGRVEXT Volume
and EDGRDEXT Dataset MXG dataset, since the X record is
completely redundant with the V and D records. IBM added
the 'X' record with APAR OW47651, June, 2001.
Thanks to Donald P. Ludwig, United Health Care, USA.
====== Changes thru 20.330 were in MXG 20.11 dated Jan 30, 2003=========
Change 20.330 Useless MSO-based variable PAGESECS (SMF30PSC):
BUILD005 the CPU-TCB-only-based memory occupancy page-seconds,
BUIL3005 the soon to be useless variable RESESFTP (SMF30ERS):
VMAC30 active-time-based expanded memory storace occupancy,
Jan 30, 2003 and the very useful variable IARVPSEC (SMF30PSF):
active-time-based central memory storage occupancy
were all 2.4% too low; IBM now documents them as being in
'page-milliseconds - 1.024 milliseconds', but MXG had
used 1000 rather than 1024 in its internal conversion.
This change creates new CSTORE30 and ESTORE30 variables
with the average storage occupancy size in bytes, for the
TYPE30_4, TYPE30_5, TYPE30_6, and TYPE30_V datasets, and
those new variables are also propagated into the dataset
PDB.STEPS and PDB.SMFINTRV if BUILDPDB/BUILDPD3 is run.
Thanks to Scott Barry, SBBWorks, Inc, USA.
Change 20.329 -With BUILDPDB=NO, and enabling USERADD=6 26 30, and also
UTILBLDP INCLAFTR=BUILD005, macro names generated for input data
UTILRMFI for BUILD005 now knows to get it from //PDB, which is
Jan 31, 2003 where USERADD= stored them. Also, UTILBLDP defaulted to
execute ASUMxxxx members if it found you were USERADDing
their input, even when you specified BUILDPDB=NO. Now,
those ASUMs are generated only with BUILDPDB=YES, so you
would use INCLAFTR=ASUM70PR, to execute only the ASUMs
you want.
-UTILRMFI now prints a report2 even if there is no data;
the report says there was no data. Previously, only a
message to the log was written when there was none.
Thanks to Alan Sherkow, I/S Management Strategies, USA.
Change 20.328 The period in the //TAPETEMP DD was changed to a comma.
JCLWEEKT
Jan 28, 2003
Thanks to Dave Crowley, Blue Cross Blue Shield of Florida, USA.
Change 20.327 All references to %VMXGFOR and %%VMXGFOR were removed in
VMXGFOR all MXG members (except CHANGES/CHANGESS) and the VMXGFOR
Jan 28, 2003 member remains for historical interest! This %MACRO has
the value "FORCE" in SAS V6 and later, and was blank in
SAS V5. In SAS V6, SAS chose to prevent a SORT which had
the same input and output dataset names when the option
OBS=N (rather than =MAX) was in effect (so that a dumb
user didn't replace a million obs dataset with only N
obs), but then initially provided the FORCE option so you
could override that choice. Because using OBS=N is smart
for testing (so you don't have to read the whole file),
MXG added %VMXGFOR to all PROC SORTs to permit it. And
then SAS made the original behavior the default with a
6.07 zap, but MXG users didn't have to install the zap,
since %VMXGFOR permited the sorts with OBS=N anyhow.
Now, a new 0C4 error in SAS has occurred in the handling
of the autocall for %VMXGFOR in SAS V8.2, and SAS note
SN-009297 documents the problem that will be corrected,
but by removing the FORCE option from all 282 members,
the autocall is avoided, and you won't have to install
the SAS fix when its available.
Change 20.326 Type 30 records from OS/390 R2.10 with JOB='INIT' have an
VGETJESN undocumented and unexpected value of JCTJOBID='INTnnnnn';
Jan 28, 2003 JCTJOBID='STCnnnnn' is the expected value of SMF30JNM.
This unexpected prefix caused MXG to set TYPETASK='INT '.
The logic to set TYPETASK was changed to recognize these
values and set TYPETASK='STC ', and additional protection
for future undocumented values of JCTJOBID was added.
Thanks to Roger P. Martens, International Truck and Engine Corp, USA.
Change 20.325 TYPE792 was incorrectly deaccumulated, as there are many
VMAC79 repeated entries with same JOB (R792JBN); added ASID to
Jan 24, 2003 separate in the SORT and in the IF FIRST. logic. This
problem was only seen for OMVS jobs. Same change made in
TYPE791 just because it was also sorted by R791JBN.
Thanks to Stan Dylnicki, RBC, USA.
Change 20.324 Almost cosmetic; semi-colons were added after each of the
DOC _Edddddd exit invocations. In general, not required, but
Jan 24, 2003 their existence can be exploited in members that generate
code (BLDNTPDB, READDB2), and it was my intention to have
them always present, even if unneeded.
Change 20.323 Using RUNDAY=YES,RUNWEEK=YES,RUNMNTH=YES,RUNNTINT=NO
BLDNTPDB caused errors, attempting to create NTINTRV, even though
VMACNTSM RUNNTINT=NO. TRNDNTIN was initialized and fixed. The
Jan 23, 2003 KEEPERS= logic was revised.
Jan 28, 2003 -VMACNTSM did not have the normal semicolon after each of
the _Edddddd exit macro invocations, which are required
only if you re-define those exits (as is done in this
case by BLDNTPDB), and a dataset label was respelled.
Thanks to Fiona Benoist, UFI Limited, ENGLAND.
Thanks to Chris Morgan, UFI Limited, ENGLAND.
Thanks to Terry Heim, ECOLAB, USA.
Change 20.322 The PROC FREQ failed if &OUTDETAL was specified; a test
ANALCNCR for &OUTDETAL now uses DATA=&OUTDETAL when that option is
Jan 22, 2003 specified.
Thanks to Kris Ferrier, State of Washington, USA.
Change 20.321 IBM's OPC Log data causes: INVALID ARGUMENT TO FUNCTION
IHDROPC error messages followed by INVALID MTD SUBTYPE. IBM has
VMACOPC changed their data, but no OPC site has yet been able to
VMXGINIT get IBM to provide the DSECTS for the MTD sub-segment,
Jan 17, 2003 which is part of the TRLRCTYP=24 "MCP EVENT" OPC record.
Fortunately, since neither site needed the datasets built
from that OPC record, they just deleted that record and
were able to continue using OPCLOG for their purposes.
This change creates the IHDROPC "OPC LOG Header Exit"
member (and &MACOPCH macro variable) so that you can
delete the TRLRCTYP=24 records in the exit or instream.
In member IMACOPCH, use IF TRLRCTYP=24 THEN DELETE;
Or instream, after your //SYSIN, you would use:
%LET MACOPCH=%QUOTE( IF TRLRCTYP=24 THEN DELETE; );
Thanks to Andrew Phillip Davis, Abbey National, ENGLAND.
Change 20.320 ASMTAPES/MXGTMNT is healed in ML-27. Option XMEM=OFF now
ASMTAPES elimimates the increase CPU time cause by fast VTS mounts
TAPEVENT (that caused 0E0 ABENDs because the job was already gone)
Jan 20, 2003 by elminating the cross memory call. This permits the
MXGTMNT monitor to be run at 0.1 seconds with minimal CPU
ML-19 @2 sec 1.36 sec/hr ML-27 @2 sec 1.8 secs/hr
ML-27 @.5 sec 6 sec/hr ML-27 @.1 sec 28.5 sec/hr
Feb 5: Do not use //EXCLUDE DD statement; causes 0C4,
awaiting dumps to examine. No other problems
have been reported. At 0.5 seconds interval,
the monitor takes less than 1 second per hour
when there are no tape mounts on that system.
Change 20.319 VGETJESN erroneously set TYPETASK='JOB' for OMVS tasks,
BUILD005 instead of TYPETASK='OMVS', causing OMVS TYPE30_1/_4/_5s
BUIL3005 to be sent to SPIN, instead of being written to the PDB
VGETJESN (OMVS type 30s have no 6s nor 26s to match), causing the
Jan 15, 2003 SPIN library to increase in size.
VGETJESN now sets TYPETASK='OMVS' if SUBSYS='OMVS', even
though those OMVS data have JCTJOBID='JOBnnnnn'.
Fortunately, these type 30 step records for OMVS tasks
are rarely important; if you do nothing, these records
will be output into your PDB library in SPINCNT days.
To remove the OMVS records from your SPIN library and to
thus prevent further growth, you can use the IMACSPCK
tailoring member to set OKFLAG=1 for these OMVS jobs.
In the SPIN30_1 and SPIN30_4 datasets, variable SUBSYS
exists and can be tested for 'OMVS', but you will need to
examine variable RACFGRUP in your SPIN30_5 dataset, as it
is the only variable you can use for SPIN30_5 (other than
a large table of JOB names). Then you can put this code:
IF SUBSYS='OMVS' OR RACFGRUP='OMVSGRUP' THEN OKFLAG=1;
in your IMACSPCK tailoring library.
The MXG change-in-error was to support the new JCTJOBID
values in JES "Z2" mode; to further protect OMVS records
from being spun due to any future Merrill error, the two
members BUILD005 and BUIL3005 that hand the OMVS 30s was
redesigned to look for either TYPETASK='OMVS' or for the
SUBSYS='OMVS' value, for added protection.
Thanks to Roger P. Martens, Navistar International, USA.
Thanks to Roger Rush, Navistar International, USA.
Change 20.318 Support for Cybermation's ESP Product's JOBHIST file.
EXESPJHR Dataset ESPJBHIS is created from the INFILE ESPHIST.
IMACESPH
VMACESPH
TYPEESPH
TYPSESPH
VMXGINIT
Jan 14, 2003
Thanks to Jesse Gonzales, The Gap, USA.
Change 20.317 Correction for the Security Resource Manager for IBM MVS
VMACSRMH V2.3, Thales e-security, Host Security Module SMF record.
Jan 14, 2003 Datasets SRMHSMDV and SRMHSMAP did not output repeated
segments, but repeatedly output only the first segment.
Thanks to Russell Dewar, National Australia Bank, AUSTRALIA.
Change 20.316 Support for Tivoli Netview NPM 2.7 SMF 28 changes.
FORMATS -NAC. Eighteen existing variables LNACPT01-LNACPT18 are
VMAC28 now documented and each contains the 3746-900 line
Jan 14, 2003 processor type, now decoded by the new MG028LT format:
Jan 17, 2003 LNACPTnn
value Description
0050X='0050X:CBP (3745-3746/900 LINK)'
0051X='0051X:NNP (APP-Resource)'
0052X='0052X:CLP (SDLC, Frame Relay, X.25)'
0053X='0053X:ESCP (ESCON)'
0054X='0054X:TRP (Token-Ring'
The CPU "NN" value in the MXG label for each of those 18
sets of LNACPxNN variables in the MXG Label is documented
(e.g., LNACPT01='3746-900*LINE*CPU 1*TYPE') and this
table maps the NN value to these line address ranges:
CPU Line Addresses CPU Line Addresses
1 2080-2111 10 2624-2687
2 2112-2175 11 2688-2751
3 2176-2139 12 2752-2815
4 2240-2303 13 2816-2879
5 2304-2367 14 2880-2943
6 2368-2431 15 2944-3007
7 2432-2495 16 3008-2071
8 2496-2559 17 3072-3135
9 2560-2623 18 NNP Processor
-NIT. INCOMPATIBLE inserts of new variables:
NITALIMB='MESSAGE*I-FRAME*BYTES*RECEIVED'
NITALIXB='XID*BYTES*RECEIVED'
NITALOMB='MESSAGE*I-FRAME*BYTES*SENT'
NITALOXB='XID*BYTES*SENT'
NITAPPNI='APPN*DATA'
NITIFSPB='INTERFACE*TABLE*SPEED*BYTES'
NITIFUC ='INPUT*UNICASTS*PACKETS*DLVD HIGHER'
NITIFUTI='PERCENTAGE*TOTAL LINK*CAPACITY*USED'
NITINUC ='INPUT*BCST/MCST*PACKETS*DLVD HIGHER'
NITISLL ='TABLE*STACK*LOW*LAYER'
NITOFUC ='OUTPUT*UNICASTS*PACKETS*DLVD HIGHER'
NITONUC ='OUTPUT*BCST/MCST*PACKETS*DLVD HIGHER'
INCOMPATIBLE in that the NIT variables are trashed by the
inserted fields, but MXG will not fail with the new data;
however, it also will not tell you NIT data is trashed!
-SMC. Scores of new low/high criteria variables are added
(COMPATIBLY, at the end).
-ACD/RCD. The Session Type, LSCDSTYP field, formerly at
offset 006C, is now documented as reserved, but in 2.7
LSCDSTYP still contains known values of session type:
'02'X='02X:3270 RELAY'
'03'X='03X:3270 CONTROL'
'04'X='04X:3270 TRANSIT=DR'
'05'X='05X:3270 TRANSIT=DFC'
'06'X='06X:AGENT SERVER COMMUNICATIONS DATA'
'08'X='08X:APPC PROTOCOL 1'
'09'X='09X:APPC PROTOCOL 2'
'0A'X='0AX:TN3270'
'0B'X='0BX:TN3270=DR'
'0C'X='0CX:TN3270E'
'0D'X='0DX:TN3270E=DR'
(plus a new, undocumented '0007'x value was found once.)
-Jan 17: Logic for LSCDIPPN was corrected, and above 0A-0D
values were added to MG028ST format.
Thanks to Michael H. Thompson, IBM Global Services, USA.
Thanks to Vernon Kelly, IBM Global Services, USA.
Change 20.315 -Support for Velocity Software's ESAMON VM Monitor 3.2 and
EXXAMSTO 3.1 with both YY and YYYY year formats in either release.
EXXAMSTO Restructured CPU, SYS, DEV, and USR records are supported
EXXAMEP1 new fields added to some segments and existing datasets,
EXXAMEP2 and new datasets created for these repeated segments:
EXXAMEP3 SEGMENT DDDDDD DATASET
EXXAMSYC SYTEP1 XAMEP1 XMXAMEP1 EP1
EXXAMVDK SYTEP1 XAMEP1 XMXAMEP2 EP2
IMACXAM SYTEP3 XAMEP3 XMXAMEP3 EP3
VMACXAM SYTCPM XAMSYC XMXAMCPM CHANNEL PATH
VMXGINIT STOVDK XAMVDK XAMSTVDK STO VDK
Jan 12, 2003 SHRSTO XAMSTO XMXAMSTO SHARED DCSS/NCS
Feb 6, 2003 -Support for the TCP file, with IBM TCPIP Monitor records,
and HST and UCD segments for Linux, NT, and HP servers is
nearly ready; contact support@mxg.com for that update.
-The USER data segments SFSAPL and MTSAPL will be decoded
only when someone wants to use that data; I previously
have decoded it from the MONWRITE output, but want a body
to make it worth my while to reuse the old code.
-Support for the default YY date format, or the optional
(if you set XAM PARM Y2K=ON in localesa.write file) YYYY.
Thanks to Tony Curry, BMC Software, USA.
Thanks to Tom White, SPRINT, USA.
Change 20.314 Enhancements to process unix sar command output increase
UNIXSAR the size of some fields that were too short.
Jan 11, 2003
Thanks to Uriel Carrasquilla, NCCI, USA.
Change 20.313 Example graphs of MQ Series SMF116 data; CPU by Region,
ANAL116 Elapsed time by Region, Bytes Get/Put, etc.
Jan 11, 2003
Thanks to Amanda Sumner, Royal Bank of Scotland, SCOTLAND.
Change 20.312 JCL examples to create ASUMUOW using Views or using the
JCLUOWP Batch Pipes product did not create the TIMESTMP variable,
JCLUOWV which caused errors that are corrected by this change,
Jan 11, 2003 which also bypasses and additional pass of both data.
Thanks to Larry Nova, TransAmerica Distribution Finance, USA.
Change 20.311 Utility to create tailored BUILDPDB jobs has new argument
UTILBLDP EXPDBOUT= that lets you insert additional code. The need
Jan 11, 2003 was to copy the TYPE6 dataset to the PDB library, so that
use would be to use the new argument in your UTILBLDP:
EXPDBOUT= DATA PDB.TYPE6;SET WORK.TYPE6; ,
or similar code to copy the dataset in that exit.
It would be wiser to use the _STY6 macro to PROC SORT the
dataset to the PDB library, since that will remove any
duplicate type 6 SMF records, but that macro will also
delete the TYPE6 dataset from the //WORK file, which will
cause BUILDPDB to fail when it tries to build PDB.PRINT
from WORK.TYPE6. If you use this logic:
EXPDBOUT= _STY6 ;
DATA TYPE6 (SORTEDBY= _BTY6); SET PDB.TYPE6; ,
the _STY6 will sort and remove duplicates, and WORK.TYPE6
will be created, marked as sorted, so that the later PROC
SORT in BUILDPDB will be bypassed.
Thanks to Normand Poitras, IBM Global Services, CANADA.
Change 20.310 Transparent redesign of processing of TYPETMNT/TYPETALO
BUILD005 in BUILDPDB was needed for the planned TAPEVENT program,
BUIL3005 which is still in development, but needed these changes:
VMAC30 -VMAC30 adds subtypes 2/3 interval tape DDs to TYPE30TD
Jan 6, 2003 dataset, and variables SUBTYPE INTBTIME INTETIME and
Jan 17, 2003 DDNAME are now kept in TYPE30TD. Subtype 4s are needed
by BUILDPDB now, and the 2/3s will be used later.
-BUILDPDB's now selects only subtype 4's in its PROC SORT
of dataset TYPE30TD, as the existing logic expects.
Change 20.309 Support for SYNCSORT for z/OS 1.1 User SMF (COMPAT).
VMACSYNC Five new variables are added, and two two-byte block
Jan 6, 2003 size of sortin and sortout are replaced by four-byte
fields, using the existing +36 bytes at end of record.
A new one byte SYNCHDB2 flag and reserved byte are input,
replacing variable NRWRKUSE, Number of Work Units Used,
which will now be missing with the new version. And the
new SYNCLVL value is 1.1 for this version, the previous
version was 3.7, making for less than elegant logic!
Thanks to Chuck Hopf, MBNA, USA.
Change 20.308 Variable ATTRQUAL was changed from LENGTH $8 to $24, as
VMACSOLN it can be longer than the original 8 byte length.
Jan 6, 2003
Thanks to Andy Creet, Department of Defence, AUSTRALIA.
=======Changes thru 20.307 were in MXG 20.10 dated Jan 03, 2003=========
Change 20.307 Change 20.274 (OW56739) was flawed, causing INVALID DATA
VMAC7072 FOR CPUHPTTM, EXETTM .. messages, and creating invalid
Jan 2, 2003 values in some observations in TYPE72GO dataset (only for
periods 2 and higher, and only if LENSCS was GE 488). The
code after IF LENSCS GE 488 THEN DO; should have INPUT
only R723PLSC field. Change 20.274 erroneously had four
additional fields that had been copied from earlier code.
Thanks to David Klein, City of New York, USA.
Change 20.306 Change 20.138 caused almost no observations in CIMSDBDS
VMACCIMS dataset; the correct test for output should have been:
Jan 2, 2003 IF NOT (DBORG EQ '00'X AND FLGOVERF EQ '00'X ) THEN DO;
Thanks to Thomas Heitlinger, FIDUCIA IT AG, GERMANY.
Change 20.305 Support for NetSpy Version 6.0 new subtypes 'G' and 'H'
EXNSPYIN create new datasets:
EXNSPYUD DATASET DDDDDD Subtype Description
IMACNSPY NSPYUDP NSPYUD G UDP Connections
VMACNSPY NSPYINTR NSPYIN H Interface
VMXGINIT However, the "H" Interface records are invalid, with only
Jan 2, 2003 76 bytes in each segment (while 176 is documented and is
the length field in these bad records). MXG will detect
and delete the invalid records, printing a note on the
SAS log. A problem will be opened with CA Support.
Thanks to Chris Selley, Zurich Finaincial Services, ENGLAND.
Change 20.304 Support for IDMS V1500 new subtypes 13, 14, and 15 create
EXIDMXLI new datasets:
EXIDMXLK DATASET DDDDDD Description
EXIDMXMS IDMSXLI IDMXLI DSG XESLOCK WAIT
IMACIDMS IDMSXLK IDMXLK DSG XESLIST WAIT
VMACIDMS IDMSXMS IDMXMS DSG XCFMSG WAIT
VMXGINIT
Dec 30, 2002
Thanks to Gilles St-Amand, DGSIG, Province of Quebec, CANADA
Change 20.303 This utility constructs DB2 GTF trace segmented records
UDB2GTF into legitimate variable length records, but printed the
UDB2GTFA "LOST EVENT" messages on the log.
Dec 30, 2002 -Member UDB2GTF only works on EBCDIC SAS (z/OS, etc).
-The new UDB2GTFA member works on ASCII SAS, if that's
where your DB2 trace records are downloaded.
Thanks to Ron Alterman, PGE, USA.
Change 20.302 Mostly cosmetic.
ANALUAFF -ANALUAFF (Unit Affinity Candidates analysis) needed an
ANALSRVC end comment in line 6.
Dec 30, 2002 -ANALSRVC replaced "compiler fakers" with ARRAYs statement
to initialize variables.
Thanks to Bruce Widlund, Merrill Consultants, USA
Change 20.301 This archaic member was replaced by VMXGTIME, but it had
VMXGGMT typo's corrected and comments updated to steer you to use
Dec 29, 2002 the VMXGTIME to convert timestamps between time zones.
Thanks to David Klein, DOITT - City of New York, USA.
Change 20.300 SAS Version 9 has tightened syntax validation, and found
VMACLMS these MXG syntax violations that were tolerated by V8.2:
VMACNTSM -VMACNTSM variable DUMMYFLD was LENGTH $32 but was also in
Dec 23, 2002 (incorrectly) INFORMAT 16.2 - error raised on the 16.2.
-VMACLMS had two instances of ELSE ELSE corrected.
-Many NOTES: 49-169 The meaning of an identifier .... that
won't go away until there's a V9 maintenance release.
=======Changes thru 20.299 were in MXG 20.09 dated Dec 20, 2002=========
Change 20.299 -Member ANALALL, which selects and prints all SMF records
ANALALL for a job is enhanced to include all user SMF records,
Dec 20, 2002 and some new SMF records added since it was last updated,
and the printing is now done with the %VMXGPRAL utility.
-Member VMACHSM now include member IMACJBCK, which is the
member that permits selection of SMF job-related records.
Thanks to Ronald Lundy, AHOLD, USA.
Change 20.298 The macro override in the MACKEEP= for LDCOVOL had the
DAILYDSN dataset name spelled wrong; the statement should be:
Dec 18, 2002 MACRO _LDCOVOL DATASETS.DCOLVOLS %
Thanks to Diane Eppestine, Southwestern Bell, USA.
Change 20.297 This enhancement adds SYSTEM and SYSPLEX to the criteria
VMXGRMFI that can be used to define RMFINTRV's workloads.
Dec 18, 2002 If you have the same SRVCLASS name on different systems
that have different meanings in your workload terms, you
can use the new positional arguments to differentiate.
(The old IMACWORK gave you access to write code for this,
but it is limited to only 15 workloads.)
Two new sections are added to the WORKx= macro arguments
(that you would tailor in the VMXGRMFI invocation in your
RMFINTRV member in your USERID.SOURCLIB).
The syntax to defina a workload now is:
WORKx=varname/label/pgn(s)/srvclass(s)/periods/system(s)/sysplex(s)
-varname is used as the first 4 characters of the name of
your workload variables
-label is the first line of the workload variable labels
-pgn(s) is a list of one or more performance group numbers
to sum into this workload (COMPAT MODE only).
-srvclass(s) is a list of one or more service or reporting
classes to sum into this workload (GOAL MODE only).
-periods is the number of periods in the workload
-system(s) is a list of one or more systems whose srvclass
or pgn will be summed into this workload.
-sysplex(s) is a list of one or more sysplexes whose pgn
or srvclass will be summed into this workload.
Thanks to Chuck Hopf, MBNA, USA.
Change 20.296 New macro variables &TRNDIN and &TRNDOUT are defined in
VMXGINIT VMXGINIT and initialized to "TREND", so that the input
Dec 18, 2002 and output TREND libraries can be different. Originally,
I backed up the trend library and then updated in place,
but for restartability products, input and output must
be different. These macro variables can be %LET to your
different DDnames, and your Trend library can be a GDG.
Only TRND23 (Change 20.239) has been updated to use these
macros, but all of the MXG TRNDxxxx members will have
this enhancement.
Macro LSU23 was defined and set to PDB for TRND23.
Thanks to Diane Eppestine, Southwestern Bell, USA.
Change 20.295 Investigation of CPU times in AS/400 datasets is enhanced
VMACQACS by new _400CPU and _400PRN macros to summarize and merge
Dec 18, 2002 all of the variables containing CPU time from QACSJOBL,
QACSSYSL, and QACSSYST into new dataset QACSCPU that
includes these CPU-related variables from these datasets:
QACSJOBL: JBCPU JBTCPU JBEDBC
QACSSYSL: SCIFUS SCIFTE SYSSWC
JSCPUTOT (sum of JS/3/1/b/c/d/e/i/m/p/s/CPU)
SCPUSTOT (sum of SCPU01-SCPU32)
NRCPUS (count of nonzero SCPUnn)
PCTCPUBY 100*SCPUSTOT/(NRCPUS*INTSEC)
QACSSYST: SHCPU
(the data in QACSSYSC is a subset of QACSSYSL).
Examination of these CPU times shows that the total CPU
time in SCPUSTOT is very close to JSCPUTOT+SHCPU.
Note that the old calculation of PCTCPUBY in QAPMSYS used
variable SHCPU, but this revision uses the total hardware
busy time (SCPUSTOT, the sum of SCPU01-SCPU32), as it is
clear that SHCPU is nothing close to the total CPU used.
To create the QACSCPU dataset, add _400CPU after you
have built the above datasets in the work file. To then
print the comparison, add _400PRN after the _400CPU
macro invocation.
Cosmetic: MXG 20.08 debug PUTs with COL=17 GDES=XX were
removed.
Thanks to Stephen Hoar, Lloyds TSB, ENGLAND.
Thanks to John Gebert, Office Depot, USA.
Change 20.294 VTS activity reports enhanced and updated. A new
ANAL94 selection parameter, SUBREP= to select desired report:
Dec 17, 2002 ALL, PHY, VIR, TAP.
Dec 30, 2002 Dec 30: cosmetic: "compiler fakers" replaced with RETAIN.
Thanks to Wally Danielson, Airborne, USA.
Change 20.293 CICS Stats "UNKNOWN STID=nnn" messages are printed by MXG
VMAC110 to alert us both that IBM has added a new statistics STID
Dec 17, 2002 segment to the SMF 110 subtype 2 record, one that is not
yet supported by MXG, so that I can begin the process of
finding the documentation from IBM and updating MXG for
that new STID. But when the "UNKNOWN STID=115" message
was printed, it took several iterations of customer's
system programmers time to report the problem and send a
record dump, and hours here trying to find documentation
that doesn't exist, and then reinvolvement of the site's
CICS staff to open a PMR with IBM, and then IBM CICS
support technicians time to finally document that:
The STID=115 for Enterprise Java Beans (DFHEJBDS) was
produced by early levels of CICS/TS 2.1 code but then
withdrawn, with the external mappings and documentation
removed, so these records should not be produced by the
currently supported IBM CICS code. (If you are still
getting these records on CICS TS 2.2, you need to raise
a PMR with your CICS support centre.)
This record type may be reinstated in a future release.
This change in VMAC110 bypasses the UNKNOWN STID= message
for STID=115, and documents the STID number!
02Jan03: APAR PQ69408 was opened 24DEC02.
Thanks to Chris Selley, Zurich Financial Services, ENGLAND.
Thanks to Tony Hurlston, Zurich Financial Services, ENGLAND.
Change 20.292 SAS Technical Support provided updated mapping of SAS SMF
ADOCSASU User record's Procedure Names to the SAS Product Name, so
FORMATS the $MGSASPR format was updated with new procedure names,
Dec 16, 2002 and the table in member ADOCSASU was revised.
Thanks to Tom White, SPRINT, USA.
Change 20.291 Support for APAR OW57121 which documents many new SMF 99
FORMATS Trace Code values; format MG099TC was updated.
Dec 16, 2002
Change 20.290 The Management Class Name variable DMCNAME is padded with
VMACDCOL hex zeros, which are now converted to blanks.
Dec 11, 2002
Thanks to Dave Gibney, Washington State University, USA.
Change 20.289 Support for the Workload Manager's WLM Definitions PDS.
REXXWLM The REXX exec contributed by this user will read the WLM
Dec 11, 2002 PDS to extract the names of tables, keys, and variable
names, and the exec then generates the SAS code to read
the PDS to create a SAS dataset for each WLM table.
Thanks to Sam Bass, McLane Company, USA.
Change 20.288 Support for MQSeries V5.3 (COMPATIBLE) new data:
VMAC115 -SMF 115 Subtype 2 MQMMSGDM Data Set new vars:
VMAC116 QISTDLMM='DELETE*MARKED*MESSAGE*REQUESTS'
Dec 9, 2002 QISTENUM='ENUMERATE*SELECT*REQUESTS'
QISTGETB='GETS THAT*GOT MESSAGE*FROM BP'
QISTGETD='GETS THAT*GOT MESSAGE*OFF DISK'
QISTLOMM='LOCK*MARKED*MESSAGE*REQUESTS'
QISTMBLR='RELEASE*BROWSE*LOCK*REQUESTS'
QISTMCNT='MESSAGE*COUNT*REQUESTS'
QISTRABP='READ*AHEADS*FROM*BUFFER*POOL'
QISTRAIO='READ*AHEADS*DOING*I/O'
QLSTGETL='GET*LOCK*REQUESTS'
QLSTHLDL='TIMES*REQUESTED*LOCK*HELD'
QLSTRELL='RELEASE*LOCK*REQUESTS'
And all of the QSST fields that exist in DB2ACCT:
QSSTABND QSSTCONF QSSTCONT QSSTCONV QSSTCRIT QSSTEXPF
QSSTEXPV QSSTFPLF QSSTFPLV QSSTFREF QSSTFREM QSSTFREV
QSSTGETM QSSTGPLF QSSTGPLV QSSTRCNZ
-SMF 116 MQMACCTQ Data Set new vars:
QWHSRN =' RELEASE*INDICATOR'
QWHSACE ='ACE*ADDRESS'
QWHSSTCK='STORE*CLOCK*VALUE OF*HEADER'
QWHSISEQ='SEQUENCE*NUMBER*FOR*IFCID'
QWHSWSEQ='SEQUENCE*NUMBER*FOR*DESTINATION'
QWHSMTN ='ACTIVE*TRACE*NUMBER*MASK'
WQGETPMS='PERSISTENT*GOT BY*MQGET'
WQPUTPMS='PERSISTENT*GOT BY*MQPUT'
WQPUT1PM='PERSISTENT*GOT BY*MQPUT1'
Change 20.287 PROC DELETE DATA=_Wdddddd; syntax for four z/VM datasets
VMACVMXA were overlooked and are now %VMXGDEL(DDDDDD=dddddd); as
Dec 9, 2002 they should have been. The %VMXGDEL is used only for
datasets that are directly sorted from _W to _Ldddddd,
and prevents deletion when _W is equal to _L dataset.
Thanks to Chris Weston, SAS Institute ITRM, USA
Change 20.286 -Three SMS objects were revised to contain Instance Names;
EXNTSQBP variables SMEXNAME in SMSEXTHR, SMIMNAME in SMSINMEM and
VMACNTSM SMSENAME in dataset SMSSENDR are now supported.
Dec 8, 2002 -Dataset SQLBUFMG has new fields and fields deleted.
-New SQLSERVER:Buffer Partition Object supported.
-INPUT STATEMENT EXCEEDED INPUT with MSExchangeIS object
if it had NRDATA=49; MXG logic corrected.
-Antigen Scan object with only NRDATA=12 supported.
Thanks to Jim Quigley, ConEd, USA.
Change 20.285 Using the _NTIMS macro to tailor Landmark IMS processing
VMACTIMS failed; each line of that MACRO definition was missing
Dec 8, 2002 the work MACRO at the start of each line.
Thanks to Michael Gresham, JCPenny, USA.
Change 20.284 Cosmetic cleanup of first MXG 20.08 only:
VMAC119 VMAC119: PUT at line 1794 was deleted.
VMAC110 VMAC110: PUT at line xxxx was deleted.
VMACNTSM VMACNTSM: Labels for DAPASTRT, DBPAFLRT missing quote.
Dec 8, 2002
Change 20.283 SMF 94 Subtype 2 SMF94SOF/SLN/SON triplet is nonstandard,
VMAC94 so it cannot be used to determine how many pool segments
Dec 5, 2002 need to be output to TYPE942P. SMF94SON should be the
Jan 2, 2002 number of repeated segments, but is always 1. SMF94SLN
should be the length of a segment, but it is 1792, the
total length of all 16 possible pools, even when fewer
pools are used. MXG initially used SON, outputting only
the first pool, but the test site knew they had defined
two pools. Their SMF records had an (undocumented) field
S94PPP='...0....'B in the first 2 segments, and had
S94PPP='...1....'B in the other 14 segments, so that test
was added to VMAC94, to only output if that bit was zero,
while awaiting this answer from IBM:
"We consider all pools to be defined, they just may not
be in current use. Other than assuming that a pool
with no logical volumes in it is 'not defined', there
is no way to make that determination. The bits of
SMF94PPP are now described, but they will not help in
determining which pools are defined."
So the heuristic test was removed, and MXG now always
outputs all 16 pool segments to TYPE942P dataset.
These new variables are created from that S94PPP field:
S94PPPRA='RETURNS*ALLOWED?'
Bit 0:
"Y" if borrowed volumes are to be returned to
the common scratch pool when scratched; blank
if borrowed volumes remain in the pool that
borrowed them when scratched.
S94PPPFM='FIRST*MEDIA*TYPE*TO BORROW'
Bits 2-4 converted to a decimal value.
First media type to borrow, if additional
physical scratch volumes are needed by the
pool.
S94PPPSM='SECOND*MEDIA*TYPE*TO BORROW'
Bits 5-7 converted to a decimal value.
Second media type to borrow, if additional
physical scratch volumes are needed by the
pool, and none of the first media type are
available.
Both are decoded by MG094PP format:
0 - No Borrowing
1 - Borrowing of Media ID 0 is allowed
2 - Borrowing of Media ID 1 is allowed
3 - Borrowing of Both Media is allowed
Change 20.282 The debugging PUT _N_= STARTCOL= .... statement at line
VMACCTLG 580 was removed.
Dec 5, 2002
Thanks to Len Rugen, University of Missouri, USA.
Change 20.281 SMF 90s from OS/390 V2.9 and z/OS 1.3 have VERSN90 as a
VMAC90A binary field in subtype 30 records, although the z/OS 1.4
VMAC90 SMF manual still shows an EBCDIC number. INVALID DATA
Dec 5, 2002 messages were printed, but no impact, as VERSN90 is not
Dec 11, 2002 used. Revised code inputs VERSN90 ?? &NUM.2. and then
tests for missing to re-INPUT as &PIB.2. Subtype 6 have
VERSN90='0002'x, subtype 6s have 'F0F1'x, or EBCDIC 1.
Note: USE TYPE90A, the old TYPE90 was replaced by TYPE90A
and this fix was extended to TYPE90 just for protection.
I have opened a documentation issue with IBM.
Thanks to Peter Webber, Co-operative Insurance Society Limited, UK.
=======Changes thru 20.280 were in MXG 20.08 dated Dec 4, 2002=========
Change 20.280 MXG-constructed variable PLAN in DB2ACCT was incorrect in
VMACDB2 Distributed/Remote records (QWHCATYP=7,8); the statement
Dec 4, 2002 in the DO group for those attachments was changed from
PLAN=SCAN(QWHCCV,1,' .'); to PLAN=SCAN(QWHCPLAN,1,' .');.
Thanks to Warren E. Waid, JCPenney, USA.
Change 20.279 The Local IP address TCBINDIP in TYP119A7 dataset was not
VMAC119 correctly stored; the statement to compress TCBINDIP must
Dec 4, 2002 be: TCBINDIP=COMPRESS(TCBINDIP);
but MXG code had .... TCBINDIC .. causing the error.
Thanks to Thomas Heitlinger, FIDUCIA IT AG, GERMANY.
Change 20.278 The %UPCASE(&SASSWORK) and %UPCASE(&USERWORK) added by
VMXGINIT Change 19.295 were lost, probably by Change 20.019. When
Dec 3, 2002 ITSV set USER=work (lowercase), their absence caused the
VMXGDEL to delete dataset work.ANYTHING because it was
different from dataset WORK.ANYTHING. %UPCASEs restored.
Thanks to Chris Weston, SAS Institute ITRM, USA.
Change 20.277 RMF Channel Activity Report enhanced with two selection
ANALRMFR parmaters, CHP= to select desired CHPID values, and
Dec 3, 2002 CACR= to selected SMF73ACR channel types.
Thanks to Don Isenstadt, Parker Hannifin Corporation, USA.
Change 20.276 Support for numerous NTSMF new objects and new data:
VMACNTSM -Support for MS Exchange 2000 SP3 changes:
VMXGINIT -DATABASE: Variables renamed:
EXNTxxxx TOCAPCHT==>CACHTOHT
Dec 3, 2002 TOCAHIRT==>CACHTORT
TOCAMIRT==>CACHTOMI
Variables removed:
TOOPENRT LGTHWAIT FIOPPEND FIOPRATE LGWRITRT LGRESTRT
CACHSTAL
Variables added:
DBPAFLRT DAPAEVRT DAPASTRT DBCASIZE
-DATABASE ==> INSTANCES: Variables renamed:
TOCAPCHT==>CACHTOHT
TOCAHIRT==>CACHTORT
TOCAMIRT==>CACHTOMI
Variables removed:
CACHFALT CACHSIZE FIBYWRRT FIBYRDRT TOOPENRT FIOPPEND
FIOPRATE LGWRITRT LGRESTRT CACHSTAL
-MSEXCHANGEDSACCESS CACHES: New variables:
CAEXPIRX CAINSRRX TOTENTRX DNENTRX SEAENTRX NDNENTR
NGUENTRX TOTENTMX DNENTMX SEAENTMX NDNENTMX NDUENTM
CAEXPITX CAINSRTX
-MSEXCHANGEIMAP4: New variables:
INVALICR CONNFAIL CONNREJE
-MSEXCHANGEPOP3: New variable:
INVALICR
-MSEXCHANGEIS: New variables:
RPCAVLAT RPCSLOPK
-Support for XP Professional:
-PROCESSOR: New Variables
PCTIDLTM PCTC1TM PCTC2TM PCTC3TM TRNSC1RT TRNSC2RT
TRNSC3RT
-Two new XP Professional Objects supported:
dddddd Dataset Object
NTPSFL PSCHFLOW PSCHED FLOW
NTWMIO WMIOBJCT WMI OBJECTS
-Support for MQSERIES QUEUES: New Instance variable
MSMQINST added.
-Support for new objects: Antigen Scan, Citrix, MSMQ,
and Data Core:
dddddd Dataset Object
NTANGN ANTIGENS ANTIGEN SCAN
NTCIIN CITRIXIN CITRIX IMA NETWORKING
NTCIMF CITRIXMF CITRIX METAFRAME XP
NTDCCA DACOCACH DATACORE CACHE
NTDCDC DACODOMC DATACORE DOMAIN CONTROLLER
NTDCFC DACOFIBC DATACORE FIBRE CHANNEL
NTDCMI DACOMIRR DATACORE MIRRORING
NTDCND DACOSCHD DATACORE SCHEDULING
NTDCNP DACONMVP DATACORE NMV POOLS
NTDCSC DACONMVD DATACORE NMV DISKS
NTMQMQ MSMQUEUE MSMQ QUEUE
NTMQMS MSMQSRVC MSMQ SERVICE
Change 20.275 HSM new variables added to dataset HSMDSRDS:
VMACHSM DSRDRECN='DATA SETS*RECONNECTED'
Dec 2, 2002 DSRBRECN='TRACKS*RECONNECTED*TO TAPE'
DSREXRED='EXTENT*REDUCTIONS'
DSRABACK='ABACKUPS*REQUESTED'
DSRABAKF='ABACKS*FAILED'
DSRABXTR='EXTRA*MOUNTS*RECALL*TAKEAWAY'
HSM now has the ability to "Reconnect" the MCDS record
when migrating a dataset that had been recalled; the
update-bit is tested, and if the dataset was not changed,
HSM "Reconnect"s that MCDS record to the migrated copy
on tape, updates the catalog to MIGRATE, and avoids any
movement of data to tape, counting the tracks that were
not moved to tape!
-There are 13 function types, not 12, so the DO loop was
increased to read all 13 array elements.
Thanks to Frank Cortell, Credit Suisse First Boston, USA.
Change 20.274 Support for RMF APAR OW56739. For RMF 79 subtype 3, adds
VMAC79 4-byte fields at the end of the segment (i.e. COMPATIBLY)
VMAC7072 to replace the existing and now-overflowing 2-byte frame
Dec 2, 2002 count variables. For RMF 72 subtype 3, TYPE72GO dataset,
adds new variable R723PLSC, with the period-level service
class name, which is now used in RMF reports to flag as
'HETEROGENEOUS' if R723PLSC is not identical to R723CLSC
for a certain period across the sysplex.
See Change 20.306 - correction.
Change 20.273 Workload Graph examples now include plots of MSU used by
GRAFWRKX each workload.
Nov 27, 2002
Thanks to Chuck Hopf, MBNA, USA.
Change 20.272 MSU variables that were zero in ASUM70PR/ASUMCEC from old
VMAC7072 S390 data with SMF70CPA=0 are now populated by using the
Nov 26, 2002 CPUTYPE/CPUMODEL variables and the $MG070CP table lookup
to get and store the CECSUSEC value back into SMF70CPA in
the TYPE70PR dataset; the non-zero SMF70CPA is then used
to calculate the MSU values in ASUM70PR/ASUMCEC.
Thanks to Chuck Hopf, MBNA, USA.
Thanks to Alan Sherkow, I/S Management Strategies, USA.
Change 20.271 -VMAC108: DOMPVN now labeled.
several -VMAC42: S42JDDSO now labeled.
Nov 26, 2002 -VMAC60: VVROPIND SMF60FNC VVRAMAT3 VVRTPEXT now labeled.
-VMACTPF: TPFRECNR, GMTOFF, SYSTEM are now labeled, and
temporary variable MZHDVAL is no longer kept.
-VMAC73: SMF73BSY now labeled.
Thanks to Chris Weston, SAS ITRM, USA.
Change 20.270 Enhancement for DB2 Trace IFCIDs 202, 230, and 239; those
READDB2 IFCID values are not SMF 102 subtypes, but are SMF 100
Nov 26, 2002 subtype 2 and 3, and SMF 101 subtype 1. READDB2 will now
create DB2STAT2 (202), DB2GBPAT (230) or DB2ACCTP (239)
datasets when those IFCIDs were requested in your READDB2
invocation.
Thanks to ???, ???, USA.
Change 20.269 Change 20.221 for ASUMUOW created variable TIMESTMP and
JCLUOWP changed the sort order of _SUOWCIC, but the JCL examples
JCLUOWV to use Views (JCLUOWV) or to use Pipes (JCUUOWP) were not
Nov 26, 2002 updated with the revised _SUOWCIC definition, causing the
VARIABLE TIMESTMP NOT FOUND error.
Thanks to Larry Nova, TransAmerica, USA.
Change 20.268 Cosmetic. Syntax of M4=-4; INPUT +M4 ... was replaced
DOC by INPUT +(-4) ... and the Assignment or RETAIN statement
Nov 25, 2002 for variables M1, M2, M4 ... were deleted. There is no
need to create/retain the negative valued variable to
move backwards in an INPUT statement.
Change 20.267 -Type 119 subtype 5 TYP11905 variable TSIPMAXS was not
VMAC119 input, causing the following 8 TSIPxxxx variables to be
Nov 23, 2002 wrong, and the label for TSIPCURS was changed to CURRENT.
-Type 119 subtype 2 TYP11902 variable TTSTATUS was 0 or
16777216 when it should have been 0 or 1; documented as
length 4, it's actually only length 1. Variable TTTOS is
only PIB1, TTXRT is PIB2, and TTINSEG and TTOUSEG are
both PIB8 instead of PIB4; IBM's originaly documentation
was corrected by the z/OS 1.3 online manual.
Thanks to Mark Cohen, DTS, ITALY.
Change 20.266 Most EXdddddd "Data Set Exit" members have one executable
EXDB2ACC statement, OUTPUT _Wdddddd or IF ... THEN OUTPUT ....
EXTY39 which permits instream tailoring syntax that will execute
EXNSPYAP the existing EXdddddd member's statement:
EXIMRACF %LET MACKEEP=
EXDB2ACP %QUOTE(
EXDB2ACB MACRO _EDB2ACC
EXCICJRN IF (your-new-selection-logic-is-true)
EXARBnnn THEN %%%INCLUDE SOURCLIB(EXDB2ACC); %%
Nov 20, 2002 );
However, that logic failed with EXDB2ACC, one of the few
exit members that has more than one executable statement:
IF something THEN DELETE; OUTPUT _WDB2ACC;
DB2 Parallel duplicate must be deleted by MXG, but IBM
techies using MXG inside DB2 Development needed to see
those records, so the normal DELETE was externalized.
Note: That DELETE was removed by Change 22.121.
a. The DELETE statement should not normally be used in
dataset exits, as it deletes the entire record; if
the record has repeated segments, a DELETE will stop
MXG from seeing the rest of that record's segments.
But by adding a DO; END; pair in the exit member code:
DO;
IF DB2PARTY='P' AND QWACPARR='Y' THEN DELETE;
OUTPUT _WDB2ACC; /* DB2ACCT, DEFINED IN IMACDB2 */
END;
there is only one executable statement, so the preceding
logic IF ... THEN %INCLUDE SOURCLIB(EX...) works.
All exit members were examined, and those with more than
one executable statement were wrapped in a DO; END; pair.
HOWEVER: The actual MXG recommended syntax for tailoring
in exit members when overriding the _Edddddd macro, as
shown in examples in member DOCMXG, show that I expected
that YOU would put the DO; ... END; pair in your logic:
%LET MACKEEP= %QUOTE(
MACRO _EDB2ACC
IF selection-critera THEN DO;
%%%INCLUDE SOURCLIB(EXDB2ACC);
END;
%%
);
and I still think that syntax is clearer and safer.
But this is still an worthy enhancement, because, now, no
matter which syntax you use to override _Edddddd macros,
either will work, transparently!
Thanks to Rob D'Andrea, Royal Bank of Scotland, ENGLAND.
Change 20.265 Undocumented fields added by FC4001 cause new SMF 94 data
VMAC94 (added by Change 20.206, using the text of the IBM PTF!)
Nov 19, 2002 to be wrong. IBM Redbook SG24-2229-05 now lists the 128
Nov 25, 2002 byte field we found at offset 400, but an 8-byte field
Nov 26, 2002 between S94OPM_AVG_VDM at offset 534 and S94OPM_DC1 at
offset 536 is not documented; it was located only by this
user's astute validation, knowing what values to expect.
The validation and -05 document made these corrections:
-S94VPSET is now input as PIB2 instead of 1.
-S94PSVC0-S94PSVC3 are now input as PIB2 instead of 1.
-S94DRIC1-8, S94xxWN1-2, S42ADI, S42DTW are recorded in
megabytes and were too small by a factor of 1048076, and
ADI/DTW were not formatted MGBYTES.
-The *1 or *2 text in many labels that didn't belong was
removed (added by erroneous CHANGE X Y ALL edit command).
-Variable SMF94VLC, the 5-byte alphanumeric Library Serial
"number" is now kept in TYPE942 & TYPE942P datasets, and
SMF94VLC should now be used in place of SMF94SNO in your
reports, as the 12-byte SMF94SNO field does not exist in
subtype 2 records. SMF94SNO was replaced by SMF94VLC in
the sort macros for the TYPE94, TYPE942, and TYPE942P
data sets, for consistency and so they could be matched.
SMF94VLC is created from SMF94SNO in (older) subtype 1
records that still have hex zeros in the VLC field.
SMF94VLC is not documented in the SMF 94 subtype 2
record, but MXG creates it as a five-byte character
variable from the 3-byte hex field that was observed to
contain it in the VPS Message Header field. SMF94VLS
is always missing value in TYPE94 when VLC contains a
character, so SMF94VLS is of no use in reporting.
OBSERVATION COUNT CHANGE: TYPE942 fewer obs.
OBSERVATION COUNT CHANGE: TYPE942P more obs.
Thanks to Wally Danielson, Airborne Express, USA.
Change 20.264 Variable MSEXISPU in MSEXCHPU dataset was increased from
VMACNTSM $32 to $64 to hold names like:
Nov 19, 2002 "First Storage Group-Public Folder Store (ISOMAILP1)"
Thanks to Xiaobo Zhang, Insurance Service Office, USA.
Change 20.263 -Support for BMC MVCICS 5.6 and correction to 5.5 CMRDETL
FORMATS support. New data BMC added to file segments in 5.5 was
VMACMVCI optional, the old (5.4) 16 bytes, or an expanded 92 bytes
Nov 16, 2002 but MXG always expected the new 92 byte length, causing
Nov 19, 2002 INPUT STATEMENT EXCEEDED error if you did not turn on the
new optional longer length records. The MXG test to
INPUT the longer length segment was revised to
IF T6ECPRID EQ 'F4'X AND T6EQUAL EQ '1.......'B THEN
using the new T6EQUAL field added in 5.5 to discriminate.
-In MVCICS 5.6, BMC added segment length into a reserved
field; new variable T6EFENLN is created by this Change.
-And MVCICS 5.6 extends the extended information to DB2,
MQSERIES, and DBCTL so the $MGMVCTI format that decodes
the file type variable, TFILI, was updated to identify
those types of files that were accessed from CICS.
Thanks to Franco Carmignani, IntesaBCI, ITALY.
Change 20.262 Support for APAR xxyyyyy added new RMF 99-1 trace codes
FORMATS for WLM dynamic resource group additional measurements,
Nov 16, 2002 that are now decoded by the MG099TC format.
Change 20.261 Preliminary look at Velocity Software ESAMON V3.2 data.
VMACXAM Updated the header from YY to YYYY; received documenation
Nov 15, 2002 of the current version, but yet to validate and compare.
Text of this change will be updated when changes made.
Change 20.260 Support for AS/400 5.2 Collection Services. INCOMPATIBLE
VMACQACS because you must change the LRECL for the files that IBM
Nov 15, 2002 IBM changed; if you upload 5.2 data with the new LRECL,
these data are readable with prior versions of MXG since
IBM added the new data at the end of the record:
Dataset Variable 5.2 LRECL
QAPMSYSL SYLPTB Added at end 3294
But these data were inserted or increased in length, so
you must have this change and correct LRECLs to read:
Dataset Variable 5.2 LRECL
QAPMETH ETMDIF Length increased 266
QAPMETH ETMUPF Added at end 266
Dataset Variable 5.2 LRECL
QAPMDISK DSASPX was DSAASP now NUM 367
QAPMDISK DSASPN Added at end 367
Thanks to Warren Cravey, Fidelity Systems, USA.
Change 20.259 TYPE71 Medium Impact Frames variables ESFRMEAV/MN/MX were
VMAC71 input out of order (AV had Min, MN had Max, MX had Avg)
Nov 15, 2002 this change also affected ESFRHIAV,ESFRHIMN,ESFRHIMX due
May 12, 2003 to subsequent calculations.
Thanks to Don Deese, (CPExpert), Computer Management Sciences, USA.
Thanks to Tony P. Stewart, Royal Mail, ENGLAND.
Change 20.258 -Cosmetic. Labels for variables MCTSSDCN/MCTSSDRL added.
VMAC110 Only if the new UTILEXCL is used to create IMACEXCL, will
Nov 21, 2002 those variables (field count, segment length) exist in
Nov 29, 2002 CICSTRAN, so that you can know which exclude code was in
use to create these observations with excluded fields.
-The debugging PUT statement for STID=82 was removed.
Thanks to Craig Collins, State of Wisconsin DEG, USA.
Thanks to Peter Krijger, National Bank of New Zealand, NEW ZEALAND.
Change 20.257 Message VMAC80A.WARN. MORE DTP (44) SEGMENTS UNIMPORTANT
VMAC80A is unimportant, but the for the 10/13 RACFEVENTS, MXG now
Nov 14, 2002 will keep 15 segments (previously kept was 12, this site
had 14) to suppress the warning message.
Thanks to Hersch White, UICI, USA.
Change 20.256 Major enhancement in UTILEXCL redesigns its IMACEXCL.
UTILEXCL Instead of creating a DO-GROUP for each APPLID+SMFPSRVR,
Nov 15, 2002 only the SMFPSRVR (CICS Version), MCTSSDCN (field count)
and MCTSSDRL ("record" length) combination are used to
create a DO-GROUP for each unique record structure, so
you won't have a separate DO-GROUP for each APPLID. And
more important, you won't have to update IMACEXCL every
time you add a new APPLID that clones an existing record
structure. Thus to support a new CICS version (or any
changes in existing EXCLUDED fields), you only need one
dictionary record from a test run to create the IMACEXCL
that will support the new record format for all APPLIDs.
The reporting of UTILEXCL was enhanced. If optional CICS
segments are found in your data, it prints the list of
IMACICxx members whose comment blocks must be removed to
input those optional segments. New reports show which
APPLIDs are in which DO-GROUP, list the non-excluded
dictionary fields for each DOGROUP, and print the text
of the IMACEXCL that was created.
To detect the very unlikely event that your CICS guru
created two exclude lists for the same APPLID that have
exactly the same number of fields and same record length,
but have different fields excluded, UTILEXCL compares the
internal sequence of fields, and will print an ERROR
on its log if that conflict is discovered.
The redesign is inside the _BLDEXCL macro that creates
the IMACEXCL file from PDB.CICSDICT, so you don't need to
re-read SMF dictionary records. You use _BLDEXCL to read
your previously-built PDB.CICSDICT as shown in examples
in the comments in the UTILEXCL member.
This also corrects INPUT STATEMENT EXCEEDED errors with
the previous design caused by multiple dictionaries for
an APPLID+SMFPSRVR that had different DCN/DRL lengths.
The old logic did not handle correctly, and it created an
IMACEXCL that had repeated variables in the INPUT.
When you execute UTILEXCL on MVS to create IMACEXCL, with
SYNCSORT as your host sort, you'll get WARNINGS that the
BY list length is greater than 4092, which is a SYNCSORT
limit, but then SAS recognizes that SYNCSORT failed and
uses the internal SAS sort successfully. One site got a
ERROR: WER723A: CONTACT YOUR SYNCSORT REPRESENTATIVE
message, but I believe that was with SAS Version 6.09.
Using OPTIONS SORTPGM=SAS should circumvent on V6.
Thanks to Kevin Van Houten, Worldcom, USA.
Thanks to Erling Andersen, SMF, DENMARK
Change 20.255 MXG 20.08-20.07, only if VSAM SMF is read with TYPEDB2,
VMACDB2 an INPUT STATEMENT EXCEEDED RECORD LENGTH error occurs;
Nov 12, 2002 the test added by Change 20.202 should have been
ELSE IF TR03OFF GT 0 THEN OFFSMF=TR03OFF;
The original test with TR03OFF GT . THEN was always true
because it is TR03OFF is initialized to zero in RETAIN,
so when VSAM data (with OFFSMF=4) was read, the first 100
record resetn OFFSMF incorrectly to zero.
Thanks to Michael Oujesky, MBNA, USA.
Change 20.254 Invalid SMF ID=100 Subtype=226 record caused STOPOVER.
VMACDB2 The record was in fact not written by DB2, and MXG's code
Nov 12, 2002 recognized the non-standard subtype, but because IBM puts
the actual subtype in QWHSIID, in the DB2 product header,
MXG has to INPUT from @LOC, but did not validate that the
value in LOC was inside the record. The logic now checks
and detects invalid (short) records, printing the first
five on the log, but continuing to process the SMF file.
Thanks to Chuck Hopf, MBNA, USA.
Change 20.253 Support for ASG-Landmark TMON/CICS V2.1 TH01595 (COMPAT).
VMACTMO2 TCB Switch counts and durations were restructured in both
Nov 10, 2002 TA and TI records, adding new count/duration variables:
TAWRDCT/M TIWRDCT/M Ready Queue Wait for Dispatch
TAAWTWRC/T TIIWTWRC/T Ready Queue Wait after Satis
TADSPWRC/T TIIDSWRC/T Ready Queue Wait While Switched
and making TADSPQCN/M and TIIDSQCN/M now reserved = zero.
The new fields were added compatibly and will be skipped
over without error with MXG 20.02 or later (Change 20.072
is required for base V2.1); this change will create and
populate the new variables when found.
Note: the order and location of the fields is a guess, as
the documentation is unclear, and no records with
the new fields have been tested. But since all are
input as binary, no errors in MXG execution will
occur, and I might have guessed luckily.
Thanks to Frank Lund, EDB Teamco AS, NORWAY.
Change 20.252 Support for SAS Version 9 TS M0 Production Release. MVS
CONFIGV9 Benchmarks in Newsletter FORTY-TWO show there is no real
AUTOEXEC change in resources between V8.2 and V9.00; this change
Nov 8, 2002 is not required for V9, but turns on reporting options
Mar 1, 2003 that can help in diagnosing problems with your SAS job.
-In CONFIGV9 (used only for "MVS" execution) SAS options
DLEXCPCOUNT FULLSTATS FULLSTIMER STIMER MEMRPT
are now enabled to print those statistics by default.
MXG's previous override to MSGCASE was removed so that
the SAS default of NOMSGCASE is specified (to circumvent
a SAS error in the DLEXCPCOUNT counts with MSGCASE).
-In AUTOEXEC (used only for "ASCII" execution), FULLSTIMER
was added; it had been removed due to problems way back
in SAS V6 for PCs.
-This change is not required, but has the recommended new
options for SAS Version 9 on MVS-OS/390-z/OS systems.
-SEQENGINE=V6SEQ is still required; see Change 20.150.
Change 20.251 Change 20.221 to VMXGUOW causes ASUMUOWT to fail; the new
VMXGUOW variable TIMESTMP was added by that change only to the
Nov 7, 2002 code used when CICSTRAN was input, and was not added to
the separate macro used when MONITASK data is input.
Thanks to Terry Warnke, CUNA Mutual, USA.
Change 20.250 -Enhancement for Tandem G07 and later creates new datasets
EXTANDIF TANDISKO (Disk Open) and TANDISKF (Disk File) from those
EXTANDIO same filenames. If you do not have a tailored TYPETAND
IMACTAND or TYPSTAND member, you will need to add //TANDISKO and
TYPETAND //TANDISKF DD DUMMY, as the default MXG member TYPETAND
TYPSTAND member always looks to read all possible Tandem files.
VMACTAND -MXG code for TANDPROC G06 record expected 42 bytes of the
VMXGINIT variables MSGSQTIM thru RPLCBYTE, but documentation shows
Nov 6, 2002 only a 16 byte reserved field added by G05, and I can't
Nov 25, 2002 find documentation that caused me to add those fields, so
their input is made conditional to eliminate STOPOVER.
In addition, the divide by DURATM was relocated until
after all fields have been input, and PER SEC was added
to several rate variables' label.
Thanks to Erling Andersen, SMF Data A/S, DENMARK.
Change 20.249 Enhancement adds TRENDOLD= parameter so you can have your
VMXGRMFI old TREND and new TREND be different datasets, i.e., be
Nov 6, 2002 part of a GDG, so the Trend Job is recoverable by CA-11.
Previously, the TREND parm was used for both the old and
the new Trend Library, and that is unchanged unless you
actually use the TRENDOLD= parameter in your VMXGRMFI.
Also, the disfunctional NORM70= (obviously had never been
used) was corrected to work as designed.
Thanks to Chuck Hopf, MBNA, USA.
Change 20.248 Variables HU47BJOB and HU47BSTP were input and kept in
VMACHURN dataset HURN47, and variables HU49BJOB/HU49BSTP added to
Nov 6, 2002 dataset HURN49.
Thanks to Deborah Churchyard, IBM Global Services, AUSTRALIA.
Thanks to Roger Stenlake, TELSTRA, AUSTRALIA.
Change 20.247 ASUMUOWT stopped working in MXG 20.03-20.07; the _SUOWTMO
VMXGUOW macro definition that was in VMXGUOW in 20.02 when 20.038
Nov 6, 2002 was tested was somehow deleted in the VMXGUOW in 20.03.
Thanks to Terry Warnke, CUNA Mutual, USA.
Change 20.246 Two STG THLD titles were corrected and TOTEFS is now
ANAL88 spelled correctly as TOTALs in headings of this report
Nov 6, 2002 example for SMF 88 System Logger data.
Thanks to Fred Mathew, Nordstrom, USA.
Change 20.245A Internal note. MXG's PROCSRCE program is used to create
PROCSRCE the IEBUPDTE-format sequential file from the MXG Source
Nov 6, 2002 directory, and it is part of MXG QA, checking line length
and for unexpected ./ characters inside those files. It
now also checks for 'E3'x and 'FC'x in my ASCII source,
as they should have been ] '5D'x and u '75'x.
Change 20.245 MACRO _THRDHST should have had INFILE THRDHIST instead of
TYPSTHST SMF, which was left over from testing, and wasn't caught
Nov 5, 2002 in QA because there was an //SMF file allocated.
Thanks to Wolfgang Vierling, Allianz, GERMANY.
=======Changes thru 20.244 were in MXG 20.07 dated Nov 4, 2002=========
Change 20.244 A second instance of DSNLABEL= in TRNDCEC caused ERROR:
TRNDCEC THE KEYWORD PARAMETER DSNLABEL PASSED TO MACRO VMXGSUM
TRNDHSM WAS GIVEN A VALUE TWICE. The second instance was
Nov 4, 2002 removed, and a similar error prevented in TRNDHSM.
Thanks to Mike Kynch, International Paper, USA.
Change 20.243 Cosmetic, in seldom-used TYPE40 (last updated in 1995).
VMAC40 If TYPE40 is executed alone, SAS prints notes that
Nov 3, 2002 VARIABLE ABEND, CONDCODE IS UNINITIALIZED
because those variables don't exist in SMF 40 (dynamic
deallocate). That note is caused by a PUT statement in
included VMACEXC2 (common code that decodes the TIOT EXCP
counts in SMF 30s and 40s) that prints ABEND and CONDCODE
in an MXGERROR log message if an error is found in EXCPs,
and ABEND/CONDCODE do exist in the type 30s. There is no
impact on the TYPE40 dataset since those two variables
are not kept nor used to create TYPE40.
However, UNINITIALIZED notes often expose errors in logic
or in spelling during alpha testing, so the QA test looks
for those notes during error correction. But even when
the cause is valid, like here, and even though they have
no impact, those notes are eliminated (primarily because
they cause confusion and unnecessary support questions),
by a "compiler faker" statement:
IF charvar=' ' THEN charvar=' ';
IF numrvar=. THEN numrvar=.;
an executable statement, but one that is placed after the
RETURN; statement in VMAC40, they are never actually
executed. Nevertheless, I considered replacing those
executable statements with the RETAIN compiler statement:
RETAIN ABEND ' ' CONDCODE .;
to initialize, define length and char/numr type. However
RETAIN can never be used if the variable is conditionally
INPUT, because values from a prior record would then be
retained and incorrectly output when they were not INPUT.
When I asked Rick Langston about a RETAIN without retain
he pointed out that ARRAY statements could be used:
ARRAY INIC40 $ ABEND (' ');
ARRAY ININ40 CONDCODE (.);
as it initializes without retaining values. The ARRAY
statement must be physically located before the variable
name is used, and a unique token must be used for each
array (some names are restriced, like ENTITY, and the
array name cannot be the same as a variable name in some
other member that can be compiled together, but with the
naming convention INICxxxx and ININxxxx in VMACxxxx, the
compiler faker statements in VMAC40 were replaced by two
ARRAY statements, and I will likely replace others as I
find them in other members.
Thanks to Bruce Widlund, Merrill Consultants, USA
Thanks to Freddie, TXU, USA.
Change 20.242 STK HSC User SMF Subtype 29 (1Dx) caused INPUT STATEMENT
VMACSTC EXCEEDED error; MXG expected +6 at the end of the record
Oct 31, 2002 should have been +4, and STC29MVN is PIB4. and not NUM4.
And that subtype was incorrectly OUTPUT into STCVSM28,
but now those typos are corrected to OUTPUT to STCVSM29.
Thanks to Dwain P. Majak, Blue Cross Blue Shield of Kansas, USA.
Change 20.241 Support for APAR OW55968 replaced 4-byte R744RSST with a
VMAC74 new 8-byte field (R744RSSE) to prevent overflow. When
Oct 29, 2002 the new value exists, it is still stored in R744RSST,
as keeping R744RSSE would be redundant. Also OW55586.
Change 20.240 TYPE73 with SMF73CMG=0 still had missing PCHANBY/PNCHANBY
VMAC73 because the initialization logic was still incorrect and
Oct 29, 2002 had to be relocated, again.
Thanks to Michael L. Kynch, International Paper, USA.
Change 20.239 Trending for TYPE23 dataset (SMF Buffer Usage) was wrong;
TRND23 the include of ASUM23 was incorrect and macro names were
Oct 28, 2002 also corrected.
Thanks to Diane Eppestine, Southwestern Bell, USA.
Change 20.238 Documentation. Using TEMP01= with %VMXGSUM can cause
VMXGSUM ERROR: FILE PDB1.MXGSUM1.VIEW IS SEQUENTIAL. THIS TASK
Oct 28, 2002 REQUIRES READING OBSERVATIONS IN A RANDOM ORDER, BUT
THE ENGINE ALLOWS ONLY SEQUENTIAL ACCESS.
Remove the TEMP01=PDB1 argument in your tailored %VMXGSUM
invocation to eliminate this error. MXG Change 19.151
documented the changes in use of the TEMP01/TEMP02/TEMP03
arguments; while you can make TEMP01= work (by changing
your DD or adding a LIBNAME PDB1 V6SEQ; statement), MXG
has recommended that you never use TEMP01, and you use
TEMP02/TEMP03 only for specific large dataset cases, e.g.
when you want to exploit hardware compression.
"MXGSUM1" errors are in an VMXGSUM invocation. When the
message is XXXX.MXGSUM1.VIEW instead WORK.MXGSUM1.VIEW,
it shows that your %VMXGSUM invocation has TEMP01=XXXX.
Thanks to Lawrence Jermyn, Fidelity Systems, USA.
Change 20.237 IDMS Performance Monitor for Version 1500 circumvention;
VMACIDMS MXG will skip over unknown sections, rather than failing
Oct 25, 2002 with an INPUT STATEMENT EXCEEDED; new sub-subtype 13, 14
and 15 records are created, but I have no documentation
of those record subtypes, nor of any changes to any of
the existing subtypes (which, while seeming to be still
correct, should be closely examined and validated).
This text will be updated when those sub-subtypes are
requested to be supported by a site with documentation.
Change 20.236 SAS User SMF record variable SASPROD, SAS Product Name,
VMACSASU was decoded with the table look-up, but was neither kept
Oct 25, 2002 nor was the variable labeled.
Thanks to Alfred Holtz, Merck Medco, USA.
Change 20.235 Support for APAR OW54010 adds Large Virtual Memory (above
VMAC78 2 GigaBytes) fields to RMF's Private Area Virtual Storage
Oct 24, 2002 Job-Level Monitor SMF 78 subtype 2, in TYPE78PA dataset:
SHBYHWM ='HWM*BYTES SHARED*ABOVE 2GB'
SHBYMAX ='MAX BYTES*SHARED*ABOVE 2GB'
SHBYMIN ='MIN BYTES*SHARED*ABOVE 2GB'
SHBYNTME='TIME STAMP*OF MIN*SHARED*ABOVE 2GB'
SHBYTOTL='TOTAL*SAMPLES*SHARED*ABOVE 2GB'
SHBYXTME='TIME STAMP*OF NAX*SHARED*ABOVE 2GB'
TOBYHWM ='HWM*BYTES ALLOCATED*ABOVE 2GB'
TOBYMAX ='MAX BYTES*ALLOCATED*ABOVE 2GB'
TOBYMIN ='MIN BYTES*ALLOCATED*ABOVE 2GB'
TOBYNTME='TIME STAMP*OF MIN*ABOVE 2GB'
TOBYTOTL='TOTAL*SAMPLES*ABOVE 2GB'
TOBYXTME='TIME STAMP*OF MAX*ABOVE 2GB'
You must have put JOB name(s) for VSTOR in your ERBRMFxx
to monitor job-level and create 78-2s, and these new data
are present only if the Detail Option was set for VSTOR.
This change is required if you install this APAR; the MXG
code was not prepared to skip over the new data.
Thanks to Brian Currah, Performance Associates, CANADA.
Change 20.234 Support for Candle Omegamon for CICS V520 User SMF record
VMACOMCI was added by adding 'V520' to the IF FOCVER test; visual
Oct 24, 2002 scan of a PROC PRINT of first 20 observations showed no
obvious errors (as would occur if a field was inserted).
Thanks to Art Cuneo, Health Care Services Corporation, USA.
Change 20.233 Fairly obscure tailoring: the KEEP= _PDB30_4 LOCLINFO was
BUILD005 reversed to KEEP = LOCLINFO _PDB30_4 ; so that redefine
BUIL3005 of _PDB30_4 could use DROP= syntax without accidentally
Oct 24, 2002 dropping LOCLINFO; the MXG syntax in KEEP= must have the
old-style macro name last, so that DROP overrides KEEP.
Thanks to Brian Crow, British Telecom, ENGLAND.
Change 20.232 Cosmetic. Labels for REGSEXAV/MN/MX are 'REG+SWA PAGES';
VMAC71 the original label mistakenly had 'REG+SQA PAGES'.
Oct 23, 2002
Thanks to Tom Buie, Southern California Edison, USA.
Change 20.231 Support for Control-D "SF2" User SMF record, described by
EXTYCSF2 their CTDSF2 DSECT, for Batch, creates new dataset
IMACCSF2 CTLDSF2, but the data does not exactly match the DSECT:
TYPECSF2 Variable SF2VSMCP, CPU Writing to VSAM, contains data
TYPSCSF2 values that are impossible ('0009CBEF'x, if that field
VMACCSF2 is in milliseconds, as are the preceding four fields);
VMXGINIT that value is greater than the elapsed time. Problem
Oct 22, 2002 will be opened with the vendor and this note updated.
Thanks to Kerstin Jansson, Tietoenator, FINLAND.
Change 20.230 Support for Control-D "POD" User SMF record, described by
EXTYCPOD their CTDPSMF DSECT, for Web-Access creates new dataset
IMACCPOD CTLDPOD, but the record does not agree with the DSECT:
TYPECPOD Variable PODPTMLI (Login Time) is hex zeros with no
TYPSCPOD time nor Julian Date. The next field, PODPCPUT, CPU,
VMACCPOD is '91FD75D4'x in one record, but is '40404040'x in
VMXGINIT two others, and the alignment of the rest of the fields
Oct 22, 2002 are thus in question.
Thanks to Kerstin Jansson, Tietoenator, FINLAND.
Change 20.229 -VMAC94:Variable S94BMPI2 was not in the $MG094MI. FORMAT.
VMAC94 -VMAC120: New WebSphere subtype 7 variables SM120WAF and
VMAC120 SM120WAG labels are Activity Begin and End datetimes.
VMACNTSM The _B120WI had all the SM120aaa variables, but now has
Oct 31, 2002 only these: SM120WIA-SM120WIE and SM120WIQ-SM120WIW.
In all new interval datasets (TYP120JI,TYP120SI,TYP120WI)
the interval duration is kept in variable DURATM. Some
old event datasets still have DURATM as their elapsed
time variable, but new event datasets like TYP120WA will
have elapsed time variable SM120ELP instead of DURATM.
Variable DURATM is kept in both TYP120CC and TYP120CM,
but only subtype=4 records will have non-missing DURATM.
Variable SM120ST is now labeled.
-VMANTSM: Variables EXCHHTEX, EXCHHTI1 and ORDFDATA were
input as $ but also in INFORMAT 16.2, which SAS did not
raise as an error, but SAS/ITSV does! All were removed
from the INFORMAT, and EXCHHTI1 added to $32 length.
The MACRO _BNTMECO still had all variables, from testing;
only the first five variables should have been listed.
-These inconsistencies were uncovered in the QA process by
ITSV/ITRM development while updating their dictionary
with new variables and new datasets from MXG 20.06.
Thanks to Chris Weston, SAS ITRM, USA.
Change 20.228 MXG 19.11-MXG 20.06. DB2 variables QW0022TS and QW0022BT
VMAC102 were wrong, if GMT Offset is non-zero. Change 19.286
Oct 21, 2002 incorrectly added +GMTOFFDB to those variables, but they
are already on the local time zone.
Thanks to Scott McDonall, Southern California Edison, USA.
Change 20.227 INTRNAME, the interface name in NETWINTR dataset, was
VMACNTSM increased from $32 to $64 in length; the original was too
Oct 21, 2002 short for 'Compaq Ethernet_Fast Ethernet Adapter_Module'.
Thanks to Xiaobo Zhang, ISO, USA.
Change 20.226 Documentation example for RACF TYPE80A processing.
VMAC80A The TYPE80A/TYPS80A member should be used for RACF SMF 80
Oct 17, 2002 (and not TYPE80), because TYPE80A creates a separate data
set for each RACF command, keeping only the variables for
that event. But that means there is an EXTY80xx exit for
each dataset, and if you wanted to filter the type 80 SMF
record and (for example, delete all events with RACFAUTH
with BIT0:NORMAL AUTH set, so you only output the events
with the other bits -SPECIAL, AUDITOR, etc-) you would
have to put your test in each of those EXTY80XX exits.
Fortunately, there is an MXG exit, IMACJBCK, that applies
to all of the TYPE80A-built datasets (although designed
just for "Job Checking"), and when it is taken, these
RACF variable have been input:
RACFDESC RACFEVNT RACFQUAL RACFUSER RACFGRUP
RACFAUTH RACFREAS RACFTLV RACFERR RACFTERM
JOB READTIME LOCLINFO RACFVRSN
To use the exit instream and delete all records with the
BIT0:NORMAL AUTH bit turned on (to output all the rest):
// EXEC MXGSASV9
//SMF DD DSN=your.input.smf.data,DISP=SHR
//PDB DD DSN=your.output.type80a.pdb,DISP=OLD
//SYSIN
%LET MACJBCK=
%QUOTE(
IF ID=80 AND RACFAUTH EQ '1.......'B THEN DELETE;
);
%INCLUDE SOURCLIB(TYPS80);
Thanks to Joseph Rannazzisi, Salomon Smith Barney, USA.
Change 20.225 Support for CICS APAR PQ63143 SMF 110 subtype 2 stats.
FORMATS Incompatibly changed STID=24, CICAUTO dataset segment,
VMAC110 added new fields at the end of other STIDs. Without the
Oct 17, 2002 change, MXG log messages about new data for STID= print,
but all other MXG datasets were still correctly built;
only CICAUTO is incorrect without this Change, and it is
seldom used.
-STID=24 +4 byte insert: CICAUTO changed INCOMPATIBLY.
In addition, time variables A04CIDLE/CMAXI/TIDLE/TMAXI
are now input correctly; they were missing previously.
-STID=60, reserved field now DSGTCBAF, variables DSnTCBAF
are created for each of the 13 CICS TCBs. DFHDSGDS.
-STID=81 +124 bytes added at end, eight new variables
added to dataset CICM compatibly. DFHMNGDS.
-STID=121 +4 bytes added at end, one new variable in the
CICXQ1 dataset compatibly. DFHXQS1D.
-The APAR did not list the STID=24 nor STID=121 changes
that were uncovered by MXG's "Skipped Data" messages.
-The APAR text also indicated that the SMDCC DSECT was
changed, but I can find no difference nor new data.
-The APAR text also indicated that the MNCBS DSECT was
changed, but I am unable to find that DSECT, nor have I
found any prior reference to DFHMNCxx DSECTS.
-That APAR text documents that APPLNAME=YES enables two
new EMPs, DFHAPPL.1 and DFHAPPL.2, that you can use to
move 4 and 8 bytes of user data; unfortunately, I've not
yet found where that data will be moved into the SMF 110
record. Let me know if you find where IBM puts it!
Note that new DFHMNRDS (Transaction Resource Class) data
also in this APAR was added by MXG Change 20.200.
Thanks to MP Welch, SPRINT, USA.
Change 20.224 The KEEPIN= argument provided no performance benefit and
ANALCNCR is no longer used; it remains defined only so that any
Oct 16, 2002 existing %ANALCNCR invocation with KEEPIN= will not fail.
All input variables are now kept, and the existing KEEP=
option on the DATA statement will keep only the variables
that are needed, to minimize the work space required.
Thanks to Chuck Hopf, MBNA, USA.
Change 20.223 CICSTRAN variable USERCHAR was still wrong after 20.148.
UTILEXCL The %INCLUDE statement UTILEXCL creates should have been
Oct 16, 2002 IMACICDU, which inputs the temporary USRSTRNG variable,
and then it includes member IMACICUS. All notes telling
you to EDIT member IMACICUS (to set the length, etc.) are
still correct and unchanged.
Thanks to Victoria Lepak, Aetna, USA.
Change 20.222 Negative value for DB2SRBTM with DB2 V7 and CICS V2.2.
VMACDB2 Starting with DB2 Version 6, IBM's documentation in the
Oct 16, 2002 DSNDQWAC copybook states that "SRB times are no longer
set by DB2", and because QWACBSRB and QWACESRB fields
were always zero, the original MXG calculation logic:
IF QWACBSRB GT 0 AND QWACESRB GT 0 THEN
DB2SRBTM=QWACESRB-QWACBSRB;
was never executed and DB2SRBTM was always missing, as is
documented in the ADOCDB2 member. However, new data from
DB2 V7 (connected to CICS V2.2, which may be the factor)
show non-zero values for both BSRB and ESRB, causing the
unexpected non-missing (and negative) value in DB2SRBTM.
MXG is now changed to force DB2SRBTM to always be a
missing value, as was originally documented in MXG Change
19.094, no matter what values are found in the ESRB/BSRB.
We will ask IBM DB2 support to explain what is being put
in the ESRB/BSRB fields to see if this is new data that's
undocumented, or if it's just random noise!
Additional data observations: QWACASRB is also non-zero.
QWACESRB is nonzero for all connection types, not just
CICS. For CICS Attach (QWHCATYP=4), QWACASRB, QWACBSRB,
and QWACESRB may be cumulative (like QWACBJST, QWACEJST).
Thanks to Siegfried Trantes, IDG, GERMANY.
Change 20.221 Internal changes to ensure correct sequencing of multiple
VMXGUOW records with new (internal) TIMESTMP variable.
Oct 15, 2002
Nov 4, 2002
Change 20.220 Variable STC28TIM in STCVSM28 from STK's User SMF record
VMACSTC was input as &PIB.8. but it should have been &PIB.4. (and
Oct 15, 2002 that caused the subsequent ST=28 variables to be wrong).
Thanks to Nathan Walsh, STK, USA.
Change 20.219 ASMTAPES ML-26. This revision is the circumvention that
ASMTAPES lets you EXCLUDE your VTS devices from the Mount-Scan (to
Oct 14, 2002 eliminate the high CPU cost of recovery from 0E0 ABENDS;
Nov 2, 2002 see Change 20.214), while still scanning for Allocates to
record the job's JESNR/READTIME/etc and populate them in
the PDB.TYPETALO dataset for drive utilization measures.
And by using dataset PDB.ASUMTAPE instead of the original
PDB.TYPETMNT dataset, each mount event will be recorded
because ASUMTAPE merges PDB.TYPETALO and IBM's TYPE21 to
capture the mount event, although the MNTTM duration will
be missing for DEVNRs excluded from the Mount Scanning.
Comments in ASMTAPES document the syntax of the EXCLUDE
text file that is used during Assembly of MXGTMNT.
The ML-26 has been tested under z/OS 1.3, and it contains
additional enhancements:
One condition under which READTIME was incorrect was
found and corrected.
New messages are printed by MXGTMNT at startup:
TMNT018I - displays interval setting at initialization
TMNT020I - acknowleges the existence of EXCLUDE DD
TMNT021I - displays list of devices that are excluded
New diagnostic command (F MXGTMNT,DIAG) will display a
series of informational messages:
TMNT025I - count of cross memory ABEND recoveries
followed by one line per tape device with
UCB address, monitoring status, current job
name, and current volser. Status shows if
the DEVNR is enabled for Mount/Alloc/Both.
Any DEVNR not in the list is not monitored.
The ML-26 revision does not solve the problem of missed
VTS mounts, and won't solve all problems with missing job
fields in PDB.TYPETALO and PDB.ASUMTAPE when allocation
duration is too short for MXGTMNT sampling.
We are now looking for an exit that would capture mounts
and miss none and not require cross-memory services to
find the mounting job's identity and information, but
there is no guarantee we'll be successful.
Regretably, ML-26 early tests show it still uses the same
and significantly higher CPU time that ML-25 uses, even
when both mount scans and allocate scans were excluded,
so we still have no fix, as of 2Nov02.
Change 20.218 RACF USRSEKTN (Security Token, SMF80DTP=53) is decoded
FORMATS with new TOKxxxxx variables added to TYPE80nn datasets
VMAC80A that contained variable USRSEKTN. New data found in SMF
Oct 12, 2002 80 record from z/OS Secure Way Security RACF Server (with
Oct 21, 2002 SMF80RVM=7706), with keywords UID, HOME, and PROGRAM are
now realized to be Extended-length Relocate Sections with
SMF80RL2 offset and SMF80CT2 count of 3, whose existence
is documented in the SMF manual (previously unnoticed)
but whose contents are not documented. The one record
found with these keywords all have Data Type SMF80TP2=301
and are heuristically decoded. Because they were found
after the last "normal" Relocate Section, which happened
to be SMF80DTP-53, I thought they were part of USRSEKTN,
and gave them variable names of TOKUID, TOKHOME and
TOKPROG. For now theyu are kept only in the TYPE8013
(ALTUSER command) dataset, while I await documentation
from IBM RACF Support to see if there are other data in
these Extended-length Relocate sections.
Thanks to Peter Skov Sorensen, JN-data, DENMARK.
Change 20.217 Variables D6ASCODE and D7ASCODE are input &IB.4 instead
VMACTMDB of &PIB.4. because SQLCODEs can be negative values.
Oct 8, 2002
Thanks to Richard Schwartz, State Street Bank, USA
Change 20.216 INPUT STATEMENT EXCEEDED was circumvented by changing the
VMACVIOP input of VIOPDCA,VIOPBND, and VIOPBNI from 4 to 2.
Oct 7, 2002
Thanks to Michael E. Friske, Fidelity Systems, USA.
=======Changes thru 20.215 were in MXG 20.06 dated Oct 7, 2002=========
Change 20.215 This user contributed code has been in MXG since 17.17;
IMACAAAA it reads a Solaris flat file log from ddname SUNSLOG,
EXSUNSOG but it was never listed in a change, nor in the IMACAAAA
IMACSUNS "list of all products" member, nor documented in any way.
TYPESUNS Freddie's QA program detected this, and many, omissions:
TYPSSUNS Long ago (on a NEC 286 notebook and a 12 hour run) he
Oct 6, 2002 wrote a SAS program to read the MXG Source Library
looking for specific text (i.e., a smart parser), and
found code that he thought might be wrong, because he
had seen me correct similar code in earlier CHANGES.
For example, a duplicate variable name does not cause
an execution error in a SAS program, but is a true
programmER error (not a programmING error - they do
not exist) when a separate variable name was needed.
That text scan of the MXG Source now looks for scores
of exceptions (e.g. DATETIME formatted variables not
stored in 8 bytes) and for inconsistencies between the
contents of documentation members and reality (do all
members listed in IMACAAAA exist in the MXG Source?).
But his QA program goes much further: by exploiting
the consistent structure of the VMACxxxx members that
create MXG datasets, and the consistent macro names
for the data-set-related _L/_W/_E/_B/_Sdddddd macros,
(and by telling me to fix my code when I'm careless)
he compares the documentation in comments with what
happens when the program is run. For example:
_Edddddd /* EXdddddd OUTPUTS DATASET */
is examined to verify that "DATASET" is the actual
dataset created when that statement is executed.
The SAS error-detection during the MXG QA Execution,
followed by Freddie's Source QA Program provides the
Quality Assurance to MXG users that the newest version
is better than the last and most likely error-free.
If you contributed the VMACSUNS, let me know to cite you,
or if this is useful, let me know so I can update this
text as to what Sun log, etc.
Thanks to Freddie Arie, TXU, USA.
Change 20.214 This is documentation of the status of of ASMTAPES ML-25.
ASMTAPES If you have Virtual Tape devices, ML-25 uses a lot more
Oct 4, 2002 CPU time (30 min per day vs 30 secs) than ML-19, but if
you have no VTS devices, there was no increase in cost:
- When you have VTS devices with their very fast scratch
mounts, 0E0 ABENDs occur when MXGTMNT Cross Memory's to
get the JOB/JESNR/READTIME/etc from the job's ASID, but
finds the job issuing the mount has already gone away.
- When ML-19 encountered an 0E0 condition during the UCB
scan for mounts, it recovered, but then quit for that
interval, and did not scan the rest of the UCBs for a
mount condition, nor did it even start the scan of UCBs
for allocations. This caused many TYPETMNT/TYPETALO
events to be missed (i.e., no SMF record written), and
0E0 recoveries could fill SYS1.LOGREC, and made it look
like MXGTMNT was not scanning 4-digit UCBs!
- ML-25 recovers from each mount UCB with a 0E0, (but it
still writes a record when appropriate, although the
ASID-related variables will be missing), and then scans
all UCBs for allocations, so it should see a lot more
allocaations, since allocations are usually much longer
than mounts. ML-25 also prevents the 0E0 LOGREC write.
And the DDNAME in TYPETMNT can be wrong, like JOBLIB!
- STROBE showed that the increase in CPU time is in the
IBM recovery modules, which are now being invoked many
more times than before, and we can't rewrite IBM code.
ML-26 is in development as a short-term circumvention that
will let you skip the UCB scan for mounts for VTS devices
(you'll specify the device addresses to be skipped), which
should significantly reduce the 0E0 recovery CPU cost, but
the UCBs will still be scanned for allocations. Due to a
(presumed) longer duration of allocation than mount time,
we should have very few 0E0 recoveries for allocations.
While the TYPETMNT record won't exist for the skipped VTS
UCBs, TYPETALO data will exist and it contains ASID info.
Not only is TYPETALO sufficient for measurement of tape
device utilization, but also member ASUMTAPE combines the
TYPETMNT, TYPETALO, and TYPE21 to create the PDB.ASUMTAPE
dataset that records each mount-dismount event, even for
VTS mounts without a TYPETMNT, and the ASID fields from
will populate the ASID variables into PDB.ASUMTAPE for
mount analysis (but with MNTTM missing for skipped UCBs).
This "ML-26-to-be" might be avaliable in early November.
It's availability will be posted to MXG-L when tested.
Once the ML-26 is available, we intend to go continue our
investigation of a permanent fix, to be exit-driven rather
than sampling UCBs, and hope to locate an exit that runs
in the mounting job's address space, which would remove
the 0E0 exposure, but that is clearly a non-trival and
major re-design of the MXG Tape Mount and Alloc Monitor.
Change 20.213 Support for APAR OW52396 (COMPAT) for Ficon Switches adds
VMAC74 meaning for existing bits in R747PTFL and R747PSFL, which
Oct 3, 2002 are already formatted $HEX2. to expose all flag bits.
No change was made to VMAC74.
Change 20.212 Support for APAR OW56162 for SMF type 64 new VSAM EOV SMF
VMAC64 that is written when there is a record management catalog
Oct 3, 2002 update request. Variable SITUIND='CATALOG UPDATE' is set
from SMF64RIN bit 7 for this new event; this record will
not contain any extent information.
Change 20.211 NDM caused INPUT STATEMENT EXCEEDED error when it wrote
VMACNDM an invalid NDM Statistics SMF record (it also wrote a
Oct 3, 2002 message to SYSLOG to let you know it knew it messed up),
that was only 24 bytes long. MXG now tests the length
of the NDM record and avoids the ERROR, instead printing
an ERROR message on the MXG log that an invalid NDM SMF
record was found and deleted. This text will be updated
when a resolution is provided by NDM's vendor.
NDM is now called Connect Direct.
Thanks to Jim Petersen, Washington Mutual, USA.
Thanks to Rick Ramirez, Washington Mutual, USA.
Change 20.210 For DB2 V6 variables QWACARLG & QWACAWLG were not input
VMACDB2 because the two tests for LENQWAC 224 AND QWHSRELN 7
Oct 3, 2002 should have tested QWHSRELN LT/GE 6 instead of 7.
Thanks to Terry L. Berman, DST Systems, Inc, USA.
Change 20.209 VGETDSN now detects that the requested DDNAME is not
VGETDSN allocated, printing a message on the log.
Oct 3, 2002
Change 20.208 TYPETPMX for ThruPut Manager SMF records, variable SPACE
VMACTPMX had to be changed to SPACERQ, because variable name SPACE
Oct 2, 2002 was already defined in TYPE1415 as a character variable.
If you combined TPMX and 1415 SMF records processing in
the same step, you got a strange "INFORMAT PIB UNKNOWN"
error.
Thanks to Lawrence Jermyn, Fidelity Systems, USA.
Change 20.207 Variable MODULE was increased from $32 to $64 because the
VMACNTSM length of the module path was found to exceed 32 bytes.
Oct 1, 2002
Thanks to Xiaobo Zhang, ISO, USA.
Change 20.206 Support for SMF 94 subtype 2, and subtype 1 enhancements
EXTY942 adds many valuable VTS variables to existing TYPE94 data
EXTY942P set and creates new TYPE942 dataset with Volume Pooling
FORMATS Statistics added by IBM Field Change 4001.
VMAC94
VMXGINIT
Sep 30, 2002
Change 20.205 Support for z/OS 1.4 (COMPATIBLE) has only minor changes
FORMATS to the SMF manual text and one new variable in TYPE74CA:
VMAC74 -Variable R7451RTY added to TYPE74CA dataset identifies
VMAC79 the RAID Rank Type of RAID-5, JBOD, or RAID-10. Note
Sep 30, 2002 that JBOD is 'Just a Bunch of DASD'!
-SMF records 63, 67, and 69 pages now clearly state they
do not exit because VSAM catalogs no longer exist.
-SMF71LIC (HIUICMN) documents that UIC values can range
from 0 to 2540 seconds; Don Deese clarified that those
larger values are for systems with all central (i.e., no
expanded storage), while 0 to 254 seconds is recorded for
systems that have expanded storage.
-R793CPUU in TYPE793 set missing if it 7FFFx or 00FFx, and
"PERCENTAGE" is added to its label.
-R793CUT should not have been TIME12.3, as it contains the
MVS Utilization (MVS Non-Wait) as a percentage of the
interval length; it is the same as R793CUU if not LPAR.
-These TYPE79A variables are documented as reserved (maybe
was an earlier release): R79AMPLT,R79AGOOU,R79ATCTL,
R79ATYPE, and R79AMSO.
Change 20.204 Support for SMF 120 Subtype 7 and 8 from WebSphere
FORMATS Application Server V4.0.1 for z/OS and OS/390 creates new
EXT120WA datasets:
EXT120WI TYP120WA - Web Container Activity - subtype 7
VMAC120 TYP120WI - Web Container Interval - subtype 8
VMXGINIT These data were added by APAR PQ59911.
Sep 30, 2002
Thanks to Randy Shumate, LEXISNEXIS, USA.
Change 20.203 Variable PONBR should have been kept in the QAPMPOLL
VMACQACS dataset for OS/400 5.1 Collection Services; now it is.
Sep 29, 2002
Thanks to Raymond Dunn, CIGNA, USA.
=Attended 35th Reunion of the NESEP (Navy Enlisted Scientific
=Engineering Program) Class of 1967 at Purdue University.
Change 20.202 Support for BMC's Mainview for DB2 THRDHIST file. The
TYPSTHST type 'K' record contains a beheaded SMF 101 accounting
VMACDB2 record. This new TYPSTHST member reads the THRDHIST data
Sep 23, 2002 and creates all of the DB2 Accounting datasets (DB2ACCT,
DB2ACCTB, DB2ACCTG, and DB2ACCTP) in the PDB library.
Member TYPSTHST defines macro _THRDHST to decode the BMC
header and uses it in place of the standard _SMF macro,
so that the MXG code in VMACDB2 can be used to decode
THRDHIST records. However, when there are more than 10
packages, THRDHIST puts extra package segments in a new
area at the end of their record. Reading the additional
package segments could not be done within VMACDB2 code,
so it was necessary to create a copy of the QPAC logic
from VMACDB2 in the TYPSTHST member, and to invoke that
code in the EXDB2ACC exit redefinition in TYPSTHST.
So now, anything I or IBM does to the QPAC logic in
VMACDB2 must be repeated in TYPSTHST!
-One additional IF statement to reset OFFSMF for THRDHIST
had to be added in VMACDB2 to support this change.
Thanks to Mr. Globisch, R+V, GERMANY.
Thanks to Mr. Peters, R+V, GERMANY.
Change 20.201 Support for ASG-Landmark TMON/MVS 3.0 and 3.1, INCOMPAT.
EXTMVWG TMVS records are completely revised, a new header in all
EXTMVWGS records, and reordering of fields within the existing
FORMATS segments, so you must have this change for TMVS V3 data.
VMACTMVS All existing datasets have been fixed and tested. These
VMXGINIT new subtypes: MC,XC,XD,XS,X2,X3,X4,XP, and XW will be
Sep 23, 2002 supported in the order you request. Comments in member
Oct 1, 2002 VMACTMVS list the record subtypes and TMVS version and
Oct 17, 2002 which MXG datasets are populated by which TMVS version.
Oct 21, 2002 Note: The support for TMON/MVS V3.0 and later is now
Nov 4, 2002 back in TYPETMVS/TYPSTMVS. (Do not use TYPETMV2).
Nov 4: RETAIN M8 (-8); statement inside MACRO _TMVS was
relocated; it was not in the IMACTMVS example, and
if you redefined IMACTMVS for Compressed Data you
got M8 UNINITIALIZED and STOPOVER ABEND.
Thanks to Yves Terweduwe, CIPAL, BELGIUM
Thanks to Michael Stark, 5-3 Bank, USA.
Change 20.200 Support for CICS Transaction Resource Class Data.
EXCICRDS Added by CICS APAR PQ63143 and documented in DFHMNRDS,
EXCICRDF this new CICS SMF 110 Subtype 1 MNSEGCL=5 creates these
IMACCICS two new datasets:
VMAC110 CICSRDS - Resource Class Data - Transaction data
VMXGINIT CICSRDFI - Resource Class Data - File Details.
Sep 21, 2002 There is one observation in CICSRDS for each transaction
whose data is collected, and one observation in CICSRDFI
for each FILENAME that was accessed by the TRANNAME in
the CICSRDS dataset. The transaction data is in the
CICSRDS dataset, and the File information is in CICSRDFI
to minimize the disk space for these data; it may be
necessary to merge the two datasets for some reports.
This new data (finally!) allows you to track what files
had how much activity (counts AND durations) for each
CICS transaction.
As both datasets can be large, neither are sorted by MXG
by default, and both are written to the //WORK file.
To instead write both to the "PDB" ddname, you can use
%LET WCICRDS = PDB;
%LET WCICRDF = PDB;
before your %INCLUDE SOURCLIB(TYPE110) or (BUILDPDB).
Note that to create this new files-used-per-transaction
data, you must change the IBM default FILES=0 in DFHMCT.
Change 20.199 This example program read SAT.TYPE70PR twice and failed
WEEK70PR to read FRI.TYPE70PR at all, causing the WEEK.TYPE70PR
Sep 21, 2002 dataset to be incorrectly build.
Thanks to Michael Marcus, Affilliated Computer System, USA.
Change 20.198 These MONIDBDS variables, from old versions, should not
VMACTMO2 not have been created and can be dropped in _KMONDBD
FORMATS FILEADIN FILEUPRP FILEGET FILEBROW FILEOPCL FILEDEL
Sep 21, 2002 FILESRV
(but they are still kept by default, so any existing
reports you have won't fail with VARIABLE NOT FOUND).
And the field that was used to create those variables is
new variable FILEACM, decoded by new format $MGMONAM.,
to describe the access method that was used for this
file: (ISAM,BDAM,VSAM,QSAM,RMTE,DL/I,DB2,DCOM)
Thanks to Richard Jay Schwartz, State Street Bank, USA.
Change 20.197 Type 30s for JES2 job have blanks for READTIME with valid
VMAC30 REND (Reader End), causing INVALID READTIME messages. Now
Sep 21, 2002 the READTIME=REND if READTIME is blank.
Change 20.196 The ***ERROR.VMACEXC2.2 INVALID DEVCLASS/DEVTYPE message
VMACEXC2 now prints variables ABEND and CONDCODE and a hex dump of
Sep 21, 2002 the first three instances; these messages should be sent
to support@mxg.com for examination. This message occurs
when MXG reads a type 30 with a DD segment in the TIOT
with an unknown Class/Type value. This has been caused by
- errors in your installation's SMF exit code, which can
accidentally overwrite data in the type 30 before the
record is actually sent to the SMF data set. The step
termination exit is often used to print step resources
on the job's SYSMSG, and that exit code has been found
to overlay these fields in the past, (but usually the
DDNAME is still valid). The "your" code may have been
provided by a vendor; for example, CA's job scheduling
product changes the values in SMF records in SMF exits.
- an overlay of the TIOT by the executing program in this
job. Often, the step will have ended with an ABEND, of
a SYSTEM 5xxF or 9xxF, if other control blocks were
also overlaid.
If there were EXCPCNTs in this segment, they can't be put
in the correct EXCPdddd/IOTMdddd bucket, since I don't
know the device type/class to put them in!
Change 20.195 New variables QWACAWTK/M/N/O/Q QWACARNK/M/N/O/Q and
VMACDB2 QWACSPVT/RLSV/RBSV were missing; IBM changed QWACLEN from
Sep 21, 2002 500 to 496 bytes, and removed a reserved field, but MXG
code was expecting 500 bytes.
Thanks to Victoria Lepack, Aetna, USA.
Change 20.194 Formats for MSU constants were updated for the 2064-2xxx
FORMATS processor family. These values are used only if you do
Sep 18, 2002 not have z/OS (which populates the CECSUSEC directly).
Thanks to Alan Sherkow, I/S Management Strategies, USA.
Change 20.193 ANALCICS example ERROR: VARIABLE OPERATOR NOT FOUND if
ANALCICS you excluded the archaic OPERATOR field; Change 13.268
Sep 17, 2002 noted that OPERATOR is almost always blank and that USER
is better, but ANALCICS still used OPERATOR. The example
was revised to use USER, as ANALCICS is included in the
JCLPDB8 job, and the old reference caused an unnecessary
test run to fail.
Thanks to Rick Salazar, City of Long Beach, USA.
Change 20.192 Support for the SAMS:VANTAGE 3.2.0 OBJ=POOLS record adds
EXSAMPOO new SAMSPOOL dataset with interval DASD pool statistics.
IMACSAMS There is an undocumented datetime value, but when decoded
VMACSAMS it is slightly earlier than the SMFTIME, but not enough
VMXGINIT to be a start of interval value:
Sep 17, 2002 SMFTIME SAMSTIME
Sep 30, 2002 07:19:13.44 07:17:45
07:39:05.58 07:37:45
08:00:27.22 07:57:45
Thanks to Jennifer Chu, Goldman, Sachs & Co., USA.
Change 20.191 Tape Mount Monitor records with blank JCTJOBID can occur,
VMACTMNT causing WARNING - TYPETASK NOT DECODED log messages and
Sep 16, 2002 TYPETASK blank in datasets TYPETMNT/TYPETALO/ASUMTAPE.
To suppress the warning message, VGETJESN is now only
invoked when JCTJOBID is non-blank, but TYPETASK will
still be blank when JCTJOBID is blank.
Thanks to Jesse Gonzales, The Gap, USA.
Change 20.190 The new MXG logic to create TYPETASK from "Z2" JCTJOBID
VGETJESN (i.e., the Jnnnnnnn format), tested variable SUBSYS for
Sep 16, 2002 TSO/JES2/JES3/STC to set TYPETASK='JOB', but variable
SUBSYS in TYPE6 is print subsystem (VPS,PFS, etc), and
and those records had TYPETASK='J ' (as would any SMF
record without a SUBSYS variable). This revision sets
TYPETASK='JOB ' for any record whose SUBSYS is not one
of the above four values, if JCTJOBID starts with a "J".
Thanks to Don Cleveland, Wellpoint Health Networks, Inc, USA.
Change 20.189 Candle OMEGAMON/VTAM Release 5.2.0 caused STOPOVER for
VMACOMVT IRNUM=27 internal subtype. Field OMVTINTV was inserted
Sep 16, 2002 and 40 new variables are now created in OMVTTCP dataset.
Thanks to Dave Crandall, Farmer's Insurance, USA.
Change 20.188 Example/member TYPSMQM will read //SMF and create all of
TYPSMQM the MQMxxxxx datasets from SMF 115 and 116 MQ-Series data
Sep 16, 2002 in one pass of SMF, sorting the output in to //PDB.
Thanks to Walt Blanding, Washington Mutual Bank, USA.
Change 20.187 Landmark/ASG for CICS 2.1 variables decoded from TAFLAG1
VMACTMO2 were not all decoded; variables STORVIOL and ABNDMONI are
Sep 5, 2002 now created and output, so the MONITASK dataset has the
same variables as with TYPEMON8 datasets.
Thansk To Arvid Lilleng, IBM Global Services, NORWAY.
=======Changes thru 20.186 were in MXG 20.05 dated Sep 6, 2002=========
Change 20.186 The RMF Reports printed blank for the MVS Level for z/OS
ANALRMFR systems; the test for MVSCHRLV was revised to test for
Sep 5, 2002 ZV prefix to recognize z/OS and print "Z/OS" for Level.
Thanks to Cheryl Watson Walker, Watson & Walker, USA.
Change 20.185 Change 20.168 caused MXG to create missing values for the
VMXGRMFI MSU-related variables, but only for non-z/OS systems that
Sep 5, 2002 don't have any IBM MSU numbers, and for which MXG uses a
table look-up to get the values for MSU calculations.
These old records don't have SMF70WLA populated, and MXG
incorrectly tried to calculate a value for WLA, when the
table can only return CPCMSU. The variable ZOS70WLA is
now always zero, as it should never have been created.
This error was caught in the deep QA of the first 20.05.
Note that old SMF 70s not only have SMF70WLA=., but also
SMF70CPA=., so the MSU variables in ASUM70PR/ASUMCEC will
also be missing until your SMF 70s have the added fields.
Change 20.184 Support for z800 processors might be incomplete; tests
VMAC7072 for CPUTYPE='2064'X must be CPUTYPE IN('2064'x,'2066'x).
Sep 5, 2002 Might affect LPARCPUS count and whether spare CPUs were
Sep 6, 2002 output in TYPE70PR for 2066, but if variable SMF70ONT is
populated, i.e., your z/OS maintenance is current, then
that eliminates the need to know the CPUTYPE, and your
z800 TYPE70/TYPE70PR data was just fine. No problem was
reported; this was accidentally observed as a possible
exposure that needed protection.
Change 20.183 A nice example of using a DATA step to perform a linear
ANALREG regression for two variables, returning the equation of
Sep 5, 2002 the best-fitting line, without requiring SAS/STAT.
Documented in its comments and contributed to MXG.
Thanks to Rab McGill, Standard Life, SCOTLAND.
Change 20.182 Type 42 Subtype 19 SMF42NRS='NUMBER OF SYSTEMS' is wrong.
VMAC42 Created when I saw "total cpu across sysplex" and the
Sep 4, 2002 "average cpu per system" and the number=total/average,
SMF42NRS=JNF/JNE for X1, and = JPF/JPE for X2 always
produced a value of 60 for the total to average value
for both the X1 and the X2 segments; for example, one
obs had JPF=71.555 seconds, JPE=1.193 for one system,
with SMF42JPA (interval)=900 seconds. The only clue
as to the meaning of the total:average ratio of 60 is
that SMF42JPG, the number of buffer intervals processed,
was also 60. Assuming the total CPU time is the total,
then the "average" CPU time is the average per buffer
interval, rather than the average per system, so the
label for JNE and JPE were corrected to reflect this
conclusion. The number of systems is now set from the
number of system segments, SMF42NRS=NR42X2.
Thanks to Helmut Roese, COM Software, GERMANY.
Change 20.181 Messages FILE WORK.DSNBREC WAS NOT FOUND BUT APPEARS ON A
TYPETMS5 DELETE STATEMENT were eliminated by replacing two PROC
Sep 4, 2002 DATASETS and DELETE TMSREC and DSNBREC with PROC DELETEs
with DATA=_WTMSTMS and DATA=_WTMSDSN.
Thanks to Dr. Alexander raeder, Itellium, GERMANY.
Change 20.180 MXG used the undocumented STARTHR-1 as the start time of
VMACTNG eachstart time of a performance cube, but the STARTHR may
Sep 4, 2002 only be a daylight savings flag and may not be the start.
Since the TNG data apparently should always start at hour
zero, that is now the MXG default, but that zero default
is externalized in the new MACRO _TNGSTHR TNGSTHR=0; %
If your data needs the MXG equation, you can replace that
TNGSTR=0; statement with any SAS statements that set the
variable TNGSTHR to your desired start hour. Your MACRO
definition would be put in member IMACKEEP, or could be
set in the SYSIN stream using this syntax:
%LET MACKEEP=
%QUOTE( MACRO _TNGSTHR TNGSTHR=STARTHR-1; % );
%INCLUDE SOURCLIB(TYPETNG);
Thanks to Erling Andersen, SMT Data A/S, DENMARK.
Change 20.179 TNG variable INSTANCE was blank in the NT014 (PROCESSOR)
VMACTNG data instead of zero. MXG expected the INSTANCE variable
Sep 4, 2002 to exist and be input from each 3-HDR record, and so set
INSTANCE=' ' to prevent an unexpected carry-forward of
the RETAINed value. This worked with all other objects
with more than one instance, but for the PROCESSOR object
(and presumably any other objects that can have more than
one instance, but actually have only one), CA puts the
INSTANCE value only in the 2-HDR for the object. To fix,
the INSTANCE=' '; statements were removed from the 3-HDR
logic so that the INSTANCE from the 2-HDR will be output.
For documentation and future reference, the sequence of
the TNG records for an NT server are listed here:
Record Object Metric Instance OOO
(-HDR Logical Disk %Disk Time 0;C: 5
4-HDR 1;D: 5
4-HDR _total;_total 5
3-HDR %Free Space 0;C: 5
4-HDR 1;D: 5
4-HDR _total;_total 5
... repeat one 3, two 4 for each metric in object
2-HDR Memory Avail Bytes blank 6
3-HDR Comm Bytes blank 6
... repeat one 3 for each metric in this object
2-HDR Network Interf Bytes Recvd 1 10
4-HDR Bytes Recvd 2 10
3-HDR Bytes Sent 1 10
4-HDR Bytes Sent 2 10
... repeat one 3, one 4 for each metric in object
2-HDR PROCESSOR %priv time 0 10
3-HDR %proc time blank 10
3-HDR %user blank 10
... repeat one 3 for each metric in object
Thanks to Erling Andersen, SMT Data A/S, DENMARK.
Change 20.178 The JCLTEST8 example did not have a DB2ACCT DD statement
JCLTEST8 in step TESTIBM3; if you change the default to send your
Sep 4, 2002 DB2ACCT data to the DB2ACCT DD, this test job failed.
Thanks to Jesse Gonzalez, The Gap, USA.
=======Changes thru 20.177 were in MXG 20.05 dated Sep 1, 2002=========
Change 20.177 The PHYSDISK dataset from Win 2000 Beta 3 (NRDATA=31) had
VMACNTSM incorrect values in AVGSKQL, AVDSKWQL, PCTDSKRD, PCTDSKWR
Aug 30, 2002 and SPLTIORT. Variables are now correctly INPUT in order.
Thanks to Andrzej Dabrowski, CSIR, SOUTH AFRICA.
Change 20.176 Support for ten new Oracle objects and ten new Analysis
EXNTANAC Server objects create these new MXG datasets:
EXNTANCO NTANAC ANSRAGCA ANALYSIS SERVER:AGG CACHE
EXNTANLA NTANCO ANSRCONN ANALYSIS SERVER:CONNECTION
EXNTANLO NTANLA ANSRLAQU ANALYSIS SERVER:LAST QUERY
EXNTANPA NTANLO ANSRLOCK ANALYSIS SERVER:LOCKS
EXNTANPI NTANPA ANSRPRAG ANALYSIS SERVER:PROC AGGS
EXNTANPR NTANPI ANSRPRIN ANALYSIS SERVER:PROC INDEXES
EXNTANQD NTANPR ANSRPROC ANALYSIS SERVER:PROC
EXNTANQU NTANQD ANSRQUDI ANALYSIS SERVER:QUERY DIMS
EXNTANST NTANQU ANSRQURY ANALYSIS SERVER:QUERY
EXNTORBC NTANST ANSRSTRT ANALYSIS SERVER:STARTUP
EXNTORD1 NTORBC ORACBUFF ORACLE9 BUFFER CACHE
EXNTORD2 NTORD1 ORACDBW1 ORACLE9 DBWR STATS 1
EXNTORDD NTORD2 ORACDBW2 ORACLE9 DBWR STATS 2
EXNTORDF NTORDD ORACDADI ORACLE9 DATA DICTIONARY CACHE
EXNTORDY NTORDF ORACDAFI ORACLE9 DATA FILES
EXNTORFR NTORDY ORACDYSM ORACLE9 DYNAMIC SPACE MANAGEMENT
EXNTORLI NTORFR ORACFREE ORACLE9 FREE LIST
EXNTORRL NTORLI ORACLIBR ORACLE9 LIBRARY CACHE
EXNTORSO NTORRL ORACREDO ORACLE9 REDO LOG BUFFER
IMACNTSM NTORSO ORACSORT ORACLE9 SORTS
VMACNTSM
VMXGINIT
Aug 29, 2002
Thanks to Steven M. Dunn, Mainframe Performance Products, AUSTRALIA.
Thanks to Wojtek Stanczew, Northern Territory Government, AUSTRALIA.
Change 20.175 Comments only. Corrected typo and revised descriptions of
WEEKBLD which WEEKBLD/WEEKBLDT/WEEKBL3/WEEKBL3T/JCLWEEK/JCLWEEKT
Aug 29, 2002 member to use for what.
Thanks to Ed Billowitz, Medical College of Virginia - VCU, USA.
Change 20.174 -Change 19.176 created variable R791MLIM but did not add
VMAC79 that variable to the KEEP= list for dataset TYPE791.
Aug 28, 2002
Change 20.173 Change 18.348 documented that QWACvvvv variables should
VMACDB2 be used instead of the QWAXvvvv counterparts in DB2ACCT,
Aug 28, 2002 and why the QWAXvvvv variables were kept. This change
makes these shouldn't-be-used-variables to be correct:
QWAXAWDR QWAXALOG QWAXAWCL QWAXAWAR QWAXOCSE QWAXSLSE
QWAXDSSE QWAXOTSE; they needed to be divided by 4096.
Thanks to Glen Yee, The Gap, USA.
Change 20.172 Variables PCHANBY, PNCHANBY and especially PBUSBY were
VMAC73 not initialized; PBUSBY was non-missing in SMF73CMG=1 and
Aug 27, 2002 SMF73CMG=2 records, causing confusions. Now, all three
are initialized to missing along with the others.
See Change 20.240, 29Oct2002 correction.
Thanks to Diane Eppestine, Southwestern Bell, USA.
Change 20.171 Variable DCDRECFM now contains values 10, 11, 12, or 13
FORMATS for FBA/FBM/VBA/VBM Record Formats; DCDRECFM is now set
VMACDCOL and formatted to 10:VBA, 11:FBA, 12:VBM, 13:FBM
Aug 27, 2002 by addition to the MGDCORF format.
Sep 4, 2002 Feb 4, 2003: Text and values for 10: and 11: had been
Feb 4, 2003 reversed; now change text, code, and format all agree.
Thanks to Steve Gormley, Royal Bank of Scotland, ENGLAND.
Thanks to Rob D'Andrea, Royal Bank of Scotland, ENGLAND.
Thanks to Steve Lottich, University of Iowa Hospitals, USA.
Change 20.170 Labels for Single-Engine CPU Utilization variables SBUTIL
VMACQAPM SIUTIL, SUTIL, and SWUTIL now contain "Single Engine" and
Aug 27, 2002 PCTCPUBY now contains "All Engines" for clarity.
Thanks to Stephen Hoar, Lloyds TSB, ENGLAND.
Change 20.169 -VMAC7072 adds variable SMF70LAC to TYPE70PR dataset, and
VMAC7072 -VMXG70PR creates new variables LPnLAC from SMF70LAC with
VMXG70PR IBM's 4-hour average hourly MSU, which can be compared to
Aug 25, 2002 the interval hourly rate in LPnMSUHR, and to the LPAR's
Defined Capacity, LPnMSU70, to both PDB.ASUM70PR and
PDB.ASUMCEC datasets.
-New macros added in VMXG70PR let you set the "RMFINTRV"
dataset that will be updated with the PLATxxxx variables,
and set the "ASUM70PR" and "ASUMCEC" dataset names that
will be output, making it easier to create multiples of
"PDB.RMFINTRV/PDB.ASUM70PR/PDB.ASUMCEC" with different
names and different INTERVAL= values. New comments in
member RMFINTRV show examples of the new possibilities.
For example, to build detail, hourly, and daily datasets,
you could use this code as your RMFINTRV member:
%VMXGRMFI(INTERVAL=DURSET,OUTDATA=PDB.RMFINTRV);
%VMXG70PR(INTERVAL=DURSET,RMFINTDS=RMFINTRV,
OUT70PR=PDB.ASUM70PR,OUTCEC=PDB.ASUMCEC);
%VMXGRMFI(INTERVAL=HOUR,OUTDATA=PDB.RMFINTHR);
%VMXG70PR(INTERVAL=HOUR,RMFINTDS=RMFINTHR,
OUT70PR=PDB.ASUM70HR,OUTCEC=PDB.ASUMCEHR);
%VMXGRMFI(INTERVAL=DATE,OUTDATA=PDB.RMFINTDY);
%VMXG70PR(INTERVAL=DATE,RMFINTDS=RMFINTDY,
OUT70PR=PDB.ASUM70DY,OUTCEC=PDB.ASUMCEDY);
which will create these datasets in your PDB library:
Raw RMF Interval RMFINTRV ASUM70PR ASUMCEC
Hourly RMFINTHR ASUM70HR ASUMCEHR
Daily RMFINTDY ASUM70DY ASUMCEDY
You should also put a member ASUM70PR with only comments
in USERID.SOURCLIB, so it is not executes a second time.
Your %VMXG70PR/ASUM70PR must use the same INTERVAL= value
that was used to create the RMFINTRV it will update, by
either using the same INTERVAL= argument, or by using the
DURSET macro for both RMFINTRV and ASUM70PR programs.
The system in the numeric example inChange 20.168 was in
LPARNUM 10, so that LPAR's data in PDB.ASUM70PR will be
in the LPnxxxx variables, (where n=A), for example:
STARTIME LPALAC LPAMSU LPAMSUHR LPAMSU70
12:30 42 6.65 26.62 50
Changes 20.168 and 20.169 should correct and clarify the
calculations of MSU, and I believe that MSU, rather than
MIPS, is the way we will be measuring usage and capacity
on z/OS systems. A newsletter article is in progress.
Change 20.168 With z/OS 1.1 or later, MXG logic to calculate MSU4HRAV
VMXGRMFI could be wrong, and PDB.RMFINTRV variables CECSUSEC,
Aug 24, 2002 CPCMSU, CPCNRCPU and CPCFNAME were missing. MXG logic
Aug 28, 2002 for non-zero SMF70WLA was wrong, revised, and broken in
two steps for clarity and debug, and fewer variables are
needed to be kept in SPIN.SPINRMFI.
I and others believe that the IBM MSU, Million Service
Units per hour, will replace MIPS, and that the MSU will
be the primary metric to express CPU hardware capacity
and/or workload consumption, whether or not MSU is also
used for Software Pricing. MIPS was a constant provided
by a consulting company to describe your processor. MSU
is a constant provided by IBM to describe your processor.
For either constant, it is the CPU seconds that are used,
along with the constant, to describe your capacity and
your capacity used in MIPS or MSU.
These are the important MSU-related variables:
-MSUINTRV - "CPU seconds" * CECSUSEC / 1E6 - is a count
and not an hourly rate, used to calculate
rates. Use only if you are summing MSU.
-MSUPERHR - MSUINTRV * 3600 / DURATM - is the interval
count of MSU (extended to an hourly MSU rate
if the interval is less than an hour).
-MSU4HRAV - MXG 4-hour rolling average MSU per hour from
RMF Interval data. MXG calculates the value
across an IPL, "SPIN"ing the last four hours
for tomorrow's input. Always calculated.
-SMF70LAC - IBM 4-hour rolling average of theMSU rate.
Not calculated when Hardware Capped.
Reset at IPL.
-SMF70WLA - The Defined Capacity of the LPAR MSU rate.
Zero if capacity is not defined. Based on
LPAR share and CPC capacity if Hardware Cap.
-CPCMSU - The CPC total capacity in hourly MSU rate.
-Al Sherkow's excellent research with IBM has found that:
-The WLM measures MSU for its 4-hour rolling average and
max values based on 10 second samples of "LPAR Effective
CPU Time", averaged over a five minute period.
-This value is used internally by WLM when managing (i.e.
"capping") to "Defined Capacity", but those 5-minute
data values are not written to RMF 70 records.
-SMF70LAC, IBM's 4-hr Average Hourly MSU, contains the
most recent calculation of the 4-hr average. It was
calculated within the last 5 minutes but represents four
hours of data from those 5 minute data values.
-The WLCTool uses SMF70LAC and reports at the customers
SMF interval.
-The Sub Capacity Reporting Tool uses SMF70LAC, but it
averages all values per LPAR per hour.
-The SMF 99 subtype 1 record field SMF99_SLAvgMsu has the
current WLM view of the four hour average in 48 service
buckets with the 5 minute interval data. The buckets
are broken up by service accumulated with the partition
was capped and while the partition was uncapped.
-MXG can never exactly match the IBM 10-second sampled MSU
values from WLM 5-minute buckets using RMF interval data,
especially for the maximum values, but using 15 minute or
hour intervals still provides very accurate MSU measures,
as demonstrated below. The RMFWDM command was issued at
12:43 and is compared to the 15-minute RMF interval at
12:30, and with the hour RMF interval starting at 12:00:
Hourly MSU Rate
4-hr Average 4-hr Maximum
RMFWDM snapshot 41 58
IBM SMF70LAC in 12:30 RMFINTRV 42 43
MSU4HRAV (RMFINTRV 15-min data) 41.95 55.4
MSU4HRAV (RMFINTRV hourly data) 40.28 43.8
IBM SMF70LAC (one hour RMFINTRV) 43 43
5-min max=58, 15-min max=55, hour max=44, LAC max=43
STARTIME MSUINTRV MSUPERHR MSU4HRAV SMF70LAC
08:30:00 11.48 45.93 33.93 31
08:45:00 13.84 55.37 35.88 33
09:00:00 11.08 44.35 37.01 35
09:15:00 8.78 35.14 37.57 36
09:30:00 12.66 50.55 39.07 36
09:45:02 13.16 52.62 40.56 38
10:00:03 10.17 40.77 40.91 40
10:15:01 10.73 42.94 41.57 40
10:30:01 10.88 43.48 42.30 41
10:45:02 10.58 42.35 42.99 41
11:00:02 11.18 44.65 43.66 42
11:15:04 10.93 43.81 44.48 43
11:30:02 9.75 38.98 43.78 43
11:45:02 7.89 31.58 43.89 43
12:00:02 9.55 38.20 43.54 43
12:15:02 9.79 39.20 43.18 43
12:30:01 6.65 26.61 41.95 42
(This system had SMF70WLA=50, CPCMSU=118.92)
-MXG'S MSU calculations use the total LPAR CPU time (LPAR
Partition Dispatch CPU time), because that is the MSU the
LPAR really consumed, and that is what you should use for
(conservative) capacity measurement. But because the CPU
Dispatch time is slightly larger than the CPU Effective,
and because IBM samples the Effective CPU to calculate
SMF70LAC for WLC Software Charging, MXG's MSU4HRAV can be
slightly larger than IBM's SMF70LAC (and recall that the
value in SMF70LAC is a truncated integer).
-Keith Munford's has also observed that:
-With Defined Capacity and Hard Capping both enabled:
-The value in SMF70LAC (4-hr average) is zero; IBM has
APAR OW55509 open internally and LAC should be fixed.
However, MXG's MSU4HRAV variable is always valid.
-The value in SMF70WLA is not the Defined Capacity that
you set on the HMC Management Console for that LPAR,
but instead SMF70WLA is the MSU rating of the CPC,
weighted by the LCPUSHAR for the LPAR:
Eg: WLA Set Value = 18 CPCMSU = 119
LCPUSHAR = 43 (out of 299) = 14.38%
IBM recorded SMF70WLA=17 (.1438*119=17.11).
-With Defined Capacity not enabled but with Hard Capping
enabled, SMF70LAC is still zero, and SMF70WLA is again
the CPCMSU rating weighted by its LCPUSHAR:
Eg: WLA Set Value = none CPCMSU = 153
LCPUSHAR = 85 (out of 400) = 21.25%
IBM recorded SMF70WLA=33 (.2125*153=32.51).
-The text of MXG Changes 20.046, 20.043, 19.083, 19.018
and 18.317 all had something to say about WLA and MSU;
some were revised to be accurate when read now, and to
be consistent with what is now known.
-See also Change 20.169 for associated MSU notes.
Thanks to Alan Sherkow, I/S Management Strategies, USA.
Thanks to Melanie Hitchings, British Telecom, ENGLAND.
Thanks to Andy Billington, British Telecom, ENGLAND.
Thanks to Keith Munford, British Telecom, ENGLAND.
Change 20.167 Using BLDNTPDB with the KEEPERS= option failed, with an
BLDNTPDB "Apparent symbolic reference SUFX not resolved." message.
Aug 23, 2002 First two references to &SUFX should have been &DDDDDD.
Aug 29, 2002 Similar error with _S&KEEPS1X then was exposed and fixed.
-A new value for RUNDAY=PDB, can be used if you just want
to create a PDB from an NTSMF file and put it in the PDB
libname (you want to suppress the normal Daily, Weekly,
Monthly and Trending process that are executed when the
default of RUNDAY=YES is used).
Thanks to Andrzej Dabrowski, CSIR, SOUTH AFRICA.
Change 20.166 Variable RDPERCNT was not input in the EDGRDEXT dataset,
VMACEDGR causing the subsequent variables to be misaligned.
Aug 19, 2002
Thanks to Reinhard Nitsch, Provinzial Versicherungen, GERMANY
Change 20.165 Support for EMC's Catalog Solution user SMF record
EXEMCASO (earlier from Softworks, and even earlier that product
IMACEMCS was named VSAM Mechanic) creates new EMCATSOL dataset.
TYPEEMCS
VMACEMCS
VMXGINIT
Aug 17, 2002
Thanks to Lawrence Jermyn, Fidelity, USA.
Change 20.164 This Analysis example caused sort errors that have been
ANALHSM corrected by this change.
Aug 16, 2002
Thanks to Steve Clark, California Federal Bank, USA.
Change 20.163 Support for the additional four fields in subtype=15,
FORMATS variables SMF15TIM, SMF15LTR, SMF15RSN, and SMF15MGT.
VMACSTC Format $MGSTCVT was created to decode SMF15RSN reason.
Aug 15, 2002
Thanks to Perry Lim, Union Bank of California, USA.
Change 20.162 The UTILRMFI utility (used if RMFINTRV reports duplicate
UTILRMFI CPU time, or to find out what is being put in 'OTHR') now
Aug 15, 2002 has arguments identical to VMXGRMFI, so to run UTILRMFI
reports with your definitions, just copy your tailored
"%VMXGRMFI(..." text into your //SYSIN file, change that
"%VMXGRMFI" to "%UTILRMFI", keeping all your tailoring
arguments, and UTILRMFI reports will be produced using
your definitions, with no retyping!
Comments in UTILRMFI were revised.
Thanks to Ada Phillips, University of Michigan Medical, USA.
Change 20.161 -Support for ASG-Landmark TMON/DB2's Change in format of
EXTMDBD0 the Version field. Originally a binary number, in 3.2
IMACTMDB it became an EBCDIC numeric, 'F3F2'x for 3.2, which made
VMACTMDB LMRKVER=24.3. Accidentally, all of the MXG tests worked,
VMAC102 but MXG code now detects and inputs the new format.
VMXGINIT -INPUT of the header fields starting with HDLEN was out of
Aug 14, 2002 aligment because of undocumented fields (inserted by the
assembler to maintain alignment) that are now skipped.
-The new DBHCDUID, DBHCEUTX, and DBHCEUWN End User USERID,
Transaction Name, and Workstation Name were observed to
contain lower case characters, just FYI for testing, etc.
-Dataset TMDBBD, Authorization Failure, 'BD' record, which
is the data segment from IBM's SMF 102 IFCID=140, now has
all of the QW0140xx variables created and kept, using an
extract of the VMAC102 source code.
-VMAC102 and VMACTMDB documentation of SQL text variables:
(This design change was made in Change 17.251, but was
never clearly documented, especially the zero obs part):
For the SMF 102 DB2 trace records containing SQL text:
T102S063,T102S124,T102S140,T102S141,T102S142,T102S145
(or for the Landmark dataset TMDBBD QW0140TX variable),
the SQL text variable that contains the SQL text
QW0063ST,QW01242T,QW0140TX,QW0141TX,QW0142TX,QW0145TX
was broken into 100 byte chunks, with the 1st 100 output
in the T102Snnn dataset, and the rest "chunked" into the
T102T063,T102T124,T102T140,T102T141,T102T142,T102T145
(for Landmark, TMDBBD0)
"text" datasets that contain only the text and key vars.
But SAS Version 8 supports long character variables, so
with V8 and (the MXG default of) COMPRESS=YES enabled,
only one observation is output in the T102Snnn dataset,
with the entire text stored in the SQL variable, and the
"Text" T102Tnnn datasets will contain zero observations.
(With archaic SAS V6, or with V8 and COMPRESS=NO, MXG
reverts back and "chunks" the test into the T102Tnnn.
-Some incorrect EBCDIC conversions were found in the
VMAC102 code that had impact only when the code executed
under ASCII SAS were relocated and corrected, and then
that code was used in VMACTMDB.
Thanks to Richard Jay Schwartz, State Street Bank, USA.
Change 20.160 MACRO _K102CMN is defined so that you can add variables
VMAC102 to the _V102CMN list of variables that are kept in all
Aug 14, 2002 T102xxx (DB2 trace) datasets, as this is safer than
redefining the _V102CMN macro, in case MXG ever needs to
add variables to that common list.
Thanks to Dr. Alexander raeder, Itellium, GERMANY.
Change 20.159 ASMTAPES ML-25 replaces ML-24; two sites had CPU loops in
ASMTAPES MXGTMNT itself, and one noticed 0C4 Logrec records. The
Aug 13, 2002 error was an unexpected fall-thru after recovery of a 0E0
Aug 30, 2002 or 0C4 ABEND in one of the two cross memory environments
(one, during device scan, and the second during a check
for device allocation for the subtype 4, each of which is
protected by a separate recovery ESTAE). The recovery
logic was revised to fix the CPU loop, but ML-25 now also
eliminates MXGTMNT logrec entries for those 0E0, 0C4, and
any other abends that occur in cross memory (because the
called address space had already been terminated before
our next 2-second sample). Any "real" abends in MXGTMNT
will not be suppressed from logrec.
Thanks to Steve Simon, Alltel, USA.
Change 20.158 First PROC DELETE DATA=ZZAIXPTX is changed to _WAIXPTX.
VMACAIX
Aug 13, 2002
=======Changes thru 20.157 were in MXG 20.04 dated Aug 12, 2002=========
Change 20.157 MXG 20.04 QA cleanup:
-Non-used or typo-s members EXAIXAIX,EXCICEJB,EXQCSCON,
VMACAIX EXQCSDIS,EXQCSJOB,EXQCSPOO,EXT120JM,EXTMTCIN,EXZRBASH,
VMACNPIP EXZRBDSI,EXZRBDVH, and EXZRBENH were deleted.
VMACTMO2 -In _SAIXPTX and _SNPIP02 sort macros in members VMACAIX
VMAC103 and VMACNPIP, typos WAIXPTX and _WNPIP02 were corrected
Aug 11, 2002 to ZZAIXPXT and ZZNPIP02.
-In VMACTMO2, variables QAPRCPUT/QAPRCPUC were misspelled
in MONIPA KEEP list and were not kept, and duplicate
variables in KEEP list were removed, and some VMXGTIMEs
were added.
-Datetime variables not in %VMXGTIME() calls were found in
VMAC103/SERVSTRT
Change 20.156 Support for new NTSMF object, MODULE, tracks DLL modules
EXNTMODU used for application analysis, in new MODULE dataset.
VMACNTSM The new %Disk Busy, Avg Disk Service Time, and Avg Disk
VMXGINIT Queue Time counters created in NTSMF 2.4.4 are now
Aug 9, 2002 supported in both the Logical and Physical Disk datasets.
Change 20.155 Specifying INTERVAL=NONE for CICINTRV is not typically
VMXGCICI useful, since it sums all data for all executions of an
Aug 9, 2002 APPLID, but at least now it works without a zero divide
error, and comments suggest it is not likely useful.
If you specify INTERVAL=HOUR, etc., you must have data
with SMFSTREQ='INT', i.e., you must have interval records
enabled by your CICS guru, and the actual interval must
be less than or equal to the INTERVAL= value you use in
your CICINTRV - IBM default interval is 3 hours. Check
the SAS log, as MXG will print a warning if your INTERVAL
request can't be honored.
Thanks to Brian Keller, ConAgra Inc, USA.
Change 20.154 MXG expected LDSKNAME to be a single letter, but now data
VMACNTSM with HarddiskVolume1, etc., appear in a Win/2000 server
Aug 9, 2002 that shares data on a Hitachi Data Systems 7700E array.
(This is a fail-over cluster, and the system that is
'in control' has the expected disk letter as LDSKNAME,
but on other servers in the cluster that are not in
control, this longer name value is seen).
The problem is that MXG kept LDSNAME in $8, which caused
all of these separate disks to be combined as HARDDISK.
Increasing the length of variable LDSKNAME to $16 should
be sufficient to store the longer name value.
Thanks to John Compton, Bristol and West, ENGLAND.
Change 20.153 Documentation only. If you have multiple systems with
IMACTIME different time zones sharing a common JES spool, and you
Aug 9, 2002 failed to use TIMEBILD to convert those datetimes to a
common zone, your //SPIN library will fill and nothing is
output to the PDB.JOBS/STEPS/PRINT datasets, because MXG
compares the type 26 JES purge JTRTIME/JENDTIME with the
JINITIME from the type 30 (to ensure, only for restarted
jobs, that the correct (final) job termination record has
been found). When you realize this is why your SPIN
library is growing, you first need to enable the TIMEBILD
to correct future timestamps, but you can clean out old
records in the SPIN file using the old IMACTIME member,
which has always externalized the time test logic. Use
IF IN26 AND IN30_5 THEN OKFLAG=1;
to completely suppress the time check part of PDB logic.
This change only added comments to member IMACTIME.
Change 20.152 SMF 118 Subtype 70 caused INPUT STATEMENT EXCEEDED error.
VMAC119 Four MAX(nn,xxxLEN) were changed to MIN(nn,xxxLEN).
Aug 8, 2002 Three were in subtype 70 and one was found in subtype 3.
Aug 9, 2002 Also, variable IFHOMEIP was corrected in subtype 6.
Also, variables FCLREPLY and FSLREPLY were changed from
character variables to numeric variables, because they
are the 3-digit numeric FTP reply codes in RFC959.
Note that FCLREPLY is a four-byte binary value, with
'000000E2'x for decimal 252, but FSLREPLY is a three
byte EBCDIC numeric value 'F2F5F0'x for 250, so the
two fields are input with different informats and the
extra byte of FSLREPLY is skipped.
Thanks to Bob C. Allen, John Deere, USA.
Thanks to Jonathan M. Miller, John Deere, USA.
Change 20.151 This example report now shows local time rather than GMT,
ANALTCP offers new %MACRO arguments to control the reports, and
Aug 9, 2002 made minor corrections. See comments in the member.
Oct 15, 2002 Note that IBM still does not provide the Start Date in
TCP data, so with only a Start Time of Day value, the
elapsed time calculation will be wrong for multi-day
sessions.
Oct 15: Realignment of columns on TOTAL report and clean
up of comments.
Thanks to Jim Hayes, Huntington Services, USA.
Thanks to Judy Doherty, Florida Legislature, USA.
Change 20.150 -Initial support for SAS Version 9 Pre-Production. In MXG
CONFIGV9 20.04-20.05, the CONFIGV9 member had no SEQENGINE option,
MXGSASV9 so the V9 default V9SEQ engine was used. But MXG 20.06
Aug 8, 2002 added SEQENGINE=V6SEQ when it was discovered that the V9
Oct 3, 2002 sequential engine still compresses tape dataset.
Mar 1, 2003 -The JCL Procedure example member MXGSASV9 is the same as
MXGSASV8, but points to the CONFIGV9 member, just in case
you look for the MXGSASV9 JCL example.
Note: Updated Oct 3, 2002 here, without the reason:
The SEQENGINE=V6SEQ was added to CONFIGV9 because both
the V8SEQ and V9SEQ engine compress tape datasets.
SEQENGINE=V6SEQ is the only safe sequential engine.
Do NOT use the default SEQENGINE=V9SEQ.
See Newsletter FORTY-ONE, SAS Technical Notes, for V9.
Change 20.149 If you enabled TIMEBILD/VMXGTIME to change timestamps,
VMAC26J2 datasets TYPE26J2/TYPE26J3/PDB.JOBS had variables
VMAC26J3 JRDRTIME JCNVTIME JCNETIME JSTRTIME JENDTIME JPRNTIME and
Aug 8, 2002 JFINTIME incorrect if that event occurred on a system
which has a different GMT offset than the SYSTEM of the
purge event. Variable SYSTEM was used to get the GMT
offset. Now, the correct event system variable is used
(SYSREAD SYSCVRT SYSEXEC SYSOUTP) to get the GMT offset.
Change 20.148 Multiple CMODNAME='USER' CMODHEAD='USER' fields are now
UTILEXCL correctly supported, creating a single INCLUDE statement
Aug 8, 2002 for the IMACICUS member, with the sum of CMODLENG from
the multiple fields used for detection/protection logic.
Previously, multiple INCLUDEs were created, with notes
for you to remove those duplicates, but the length tests
were wrong, so the output dataset was trashed.
Thanks to Victoria Lepak, Aetna, USA.
Change 20.147 Variable PLATFORM was added to all TNG datasets so you
VMACTNG can identify the software version that created each
Aug 7, 2002 observation in each dataset.
Thanks to Gunner Jacobsen, Nordea Bank Sverige AB, SWEDEN.
Thanks to Erling Andersen, SMT Data A/S, DENMARK.
Change 20.146 ASMTAPES/MXGTMNT ML-24 provides these revisions:
ASMTAPES -Fix to eliminate filling logrec due to 0E0 ABENDs:
Aug 7, 2002 the 0E0 Software ABENDs still occur when the mount is
so fast that the ASID has gone away, and MXGTMNT still
recovers, but now it prevents the unneeded and unwanted
logrec record from ever being created.
-Enhanced recovery logic. Previously, the 0E0 recovery
routine would skip all remaining devices after a 0E0.
Now it only skips the DEVNR with the 0E0.
-Fix for high CPU loop and/or high SMF record write loop
(only in ML-21 thru ML-23).
We're pretty certain this is corrected, but please
look closely and verify all is well with the CPU
time used by MXGTMNT.
-Correction for a pre-existing programming error in
memory management (a "storage leak") in the recovery
logic found while testing.
That it has taken since February until August to find a
solution to the original problem of filling logrec shows
this was a non-trivial redesign!
ML-24 doesn't solve the missed mount due to fast VTS
mounts, since some are as fast as tens of milliseconds.
But reducing the 2 second sample pop to 1/2 second can
improve the percent of mounts captured, and you can see
if there was a significant cost in the CPU time of the
MXGTMNT monitor (and let me know your results!).
However, by using the ASUMTAPE program to merge TYPETMNT
mount, TYPETALO allocate, and (always-there) TYPE21
dismount record to create the PDB.ASUMTAPE dataset, and
use it instead of the PDB.TYPETMNT dataset, then your
total mount activity will be captured; fast mounts will
just have missing/blank values for MNTTM (and other
variables only available when the mount is captured).
Depending on feedback from you as to how important these
missed mounts actually are, we may begin to investigate
if there is any alternative to sampling, but at the very
best, that would be a many-month, many tests, redesign.
Let me know your thoughts.
Thanks to my new ASMTAPES support person, who chooses to be anon.
Change 20.145 SAS Version 9 Beta prints a warning when it finds syntax
VMAC74 with a quoted string that is not followed by a blank:
Aug 6, 2002 NOTE 49-169: THE MEANING OF AN IDENTIFIER AFTER A QUOTED
STRING MAY CHANGE IN A FUTURE SAS VERSION....
Only one instance was detected in MXG, in VMAC74, where a
blank was needed before the OR in IF R74ETYPE='B'OR ....
A blank was not previously required, and even with V9,
the program compiled correctly, but the warning will let
you identify and correct any similar "unwise" syntax in
your SAS programs, so you can revise your code now, long
before SAS tightens up the syntax requirements.
Thanks to MP Welch, SPRINT, USA.
Change 20.144 MXG incorrectly read NTSMF PROCESS object records with
VMACNTSM NRDATA=20 or NRDATA=27 (NTSMF 2.2.2 with NT 4.0 or 5.0).
Aug 6, 2002 Variable CREATPID was not INPUT, causing the next three
three variables (POOLPGBY, POOLNPBY, and HANDLES) to be
wrong, and for NRDATA=20, the new READYTHR variable was
not INPUT. The IN() test for CREATPID now tests for both
20 and 27, and the IN() test for READYTHR now tests for
20 to correct these errors.
Thanks to Xiaobo Zhang, Insurance Services Office, USA.
Development stopped from August 1st thru August 5th, 2002, so Judy and I
could attend the Terrapin Station concert at Alpine Valley, Wisconsin,
the first reunion of "The Other Ones" as the remaining four originals
from "The Grateful Dead" now call themselves. Fantastic performances,
peace and love among deadheads prevailed; it was a "grate show".
Change 20.143 APAR OW55735 for the NPM/IP 1.3 and 1.4 product changes
VMACNPIP the documentation for BYTESSNT and BYTESRCV variables in
Jul 30, 2002 dataset NPMIP02; previously "ACCUMulated", now "DELTA"
values, so the DIF() logic in the _SNPIP02 Sort Macro
was removed.
Change 20.142 Addition of SORTEDBY= still failed if a dropped variable
VMXGSUM only appeared in the SUMBY= argument, because VMXGSUM
Jul 30, 2002 used the original SORTBY= string as the SORTEDBY= value.
(For example, if variable OPERATOR was not in CICSTRAN,
your TRNDCICX now failed). Code was relocated so now the
variables that actually exist are used for both SORTBY=
and SORTEDBY= values, protecting dropped variables.
Thanks to John Gebert, Office Depot, USA.
Thanks to Justin Peterson, Office Depot, USA.
Change 20.141 Support for Williams Data Systems IMPLEX Version 2.1 adds
VMACMPLX five new datasets for Protocol Monitor of FTP, NTT, EE,
Jul 26, 2002 OSPF, and MIBs. No SMF records from new version have
Feb 3, 2003 been tested. Feb 3: This change supports Version 2.3.
Change 20.140A Actual data values for SMF70CSF,SMF70ESF show they are in
VMAC7072 megabytes and not frames, so their 4096 multiplier needs
Jul 26, 2002 to be 1048576. IBM acknowledged the documentation error.
Thanks to Allan Winston, MBNA, USA.
Change 20.140 MXG 20.02-20.03 only. ALL Landmark TMON/CICS datetimes
VMACTMO2 are wrong, if your GMT Offset value is non-zero. MXG
Jul 25, 2002 Change 20.072 incorrectly assumed that TODSTAMP values
were in GMT and incorrectly added the GMTOGMTO offset to
every datetimestamp variable. Close examination of data
with non-zero GMT offset shows all timestamps are local,
except for TMMDCCLK, which is not kept nor converted, so
all of the xx=xx+GMTOGMTO; statements were removed.
-Variable TKLSTTOD was incorrectly treated as a duration,
but now is input and formatted as a datetimestamp.
-The one statement GMTOGMTO=GMTOGMTO/4096; was deleted.
Thanks to Dean Ruhle, J C Penny, USA.
Change 20.139 If your GMTOFFTM is non-zero, most datetimes in TMON/DB2
VMACTMDB will be wrong; Change 19.288 assumed all STCKs were GMT,
Jul 25, 2002 but data shows that only REGNTIME, DBKSCB/DBKSCE, and
(only for LMRKREC=:'B') HSSTCK and HDTSTP are GMT and now
only those variables have +GMTOFFTM conversion to local.
Thanks to Martin Legendre, Regie des Rentes du Quebec, CANADA.
Change 20.138 CIMSDBDS dataset had obs with DBORG='00'X that should not
VMACCIMS have been output. Those DBD segments are now documented
Jul 22, 2002 as dummy, when DB2 was called but no DB2 data collected;
previously, documented as ALLDBS Sync Point Writes. This
change no longer outputs to CIMSDBDS if DBORG='00'X AND
FLGOVERF='00'X, added to ensure that only dummy segments
are skipped.
OBSERVATION COUNT CHANGE: CIMSDBDS has fewer obs.
Note: 02Jan02: See Change 20.306 revision.
Change 20.137 The Print/Means/Contents all datasets utility VMXGPRAL
VMXGPRAL had minor corrections to eliminate a note about TITLEs,
Jul 22, 2002 and to reset OBS=MAX after its execution, and defaults
were changed so %VMXGPRAL(DDNAME=WORK,NOBS=10); now will
only PROC PRINT the first ten obs of each dataset in the
work file that had any observations, which I find quite
useful in validating datasets I've just created.
Change 20.136 The %LET DDNAME=QAPMPOLB; after MACRO _TQAPPOL should be
VMACQACS %LET DDNAME=QAPMPOLL; to read from the correct file.
Jul 18, 2002
Thanks to John Gebert, Office Depot, USA.
Change 20.135 An 0C4 ABEND reading RMFVSAM was caused by a bad branch
ASMRMFV in old code in ASMRMFV, which was exposed only if the CSR
Jul 18, 2002 Common Storage Remaining table was (unexpectedly) empty.
Jul 22, 2002 The CSRG3 table was empty because the DIAG member in
parmlib was set to OFF on one LPAR, but the correction
protects for an empty table. Thanks to Jerry for his ASM
skills, and to his management for allowing him to examine
Betty's dump to diagnose and correct the error. And an
error if only ASI was selected was also corrected.
Thanks to Jerry Urbaniak, Acxiom CDC, USA.
Thanks to Betty Wong, Bank of America, USA.
Change 20.134 Variable S42DSBUF in dataset TYPE42DS was off by one bit,
VMAC42 so Buffer Type (NSR/RLS/LSR/GSR) values were incorrect.
Jul 18, 2002 The corrected decoding of VSAM Buffer Type is:
S42DSBUF=FLOOR(INPUT(S42DSFL1,&PIB.1.)/64);
Thanks to Don Deese, (CPExpert), Computer Management Sciences, USA.
Change 20.133 Variable TYPETASK was added to LENGTH as $4 to protect
VMAC26J2 and to be consistent with other instances of TYPETASK.
Jul 18, 2002
Change 20.132 Support for the new NTSMF File System Collector, which is
VMACNTSM like DCOLLECT for NT! The new FS Statistics object will
Jul 17, 2002 capture the size, type, name, owner, etc., of all or some
NT disk files with the create, last access, and last use
datetimes, so you can measure and chargeback disk space.
The new dataset FSSTATS will have an observation for each
file that was captured (you can set thresholds on size,
etc., to determine if all or only some files are reported
by this new collector.
Change 20.131 Cosmetic. The conversion of variable AVAILMEK is now
VMACNTSM tested to be non-missing, to suppress the Missing Values
Jul 17, 2002 SAS Note if you do not collect that field in NTSMF data.
Thanks to Bob Gauthier, Albertsons, USA.
Change 20.130 Support for APAR PQ61349 adds SERVSTRT (HTTP Server Start
VMAC103 Datetime) to both TYPE1031 and TYPE1032 datasets, and
Jul 16, 2002 JOB and ASID to TYPE1031 dataset. When not running in
single server mode, the entity name is not unique, these
fields provide unique tokens so the subtype 1 and subtype
2 can be merged together.
Note: Jul 16, 2024. Dataset TYPE1031 is not kept as it
is created in //WORK but then combined with TYPE1032 to
create PDB.TYPE1032 and WORK.TYPE1031 and WORK.TYPE1032
are then deleted.
Change 20.129 Support for APAR OW54007, which adds SMF42ESA (UCBSTAT)
VMAC42 and SMF42EFL (UCBSFLS) variables to TYPE42AU dataset.
Jul 16, 2002
Change 20.128 -New ANALDB2K member combines DB2ACCTP Package counts with
ANALDB2K DB2ACCT Accounting variables and creates dataset DB2ACCTK
EXDB2ACB with both Package and Accounting data. Comments in the
EXDB2ACP ANALDB2K document what was discovered about Packages.
VMACDB2 -This analysis uncovered errors in MXG; observations were
Jul 16, 2002 output into DB2ACCTP and DB2ACCTB for Parallel RollUp
records that were not output in DB2ACCT (See discussion
in text of Change 19.027). The logic added to EXDB2ACC
to delete if DB2PARTY='Y' AND QWACPARR='Y' was added to
the EXDB2ACB and EXDB2ACP members so all rollups will be
deleted. This required relocation of code inside VMACDB2
so those variables would exist for those exits.
OBSERVATION COUNT CHANGE: DB2ACCTP has fewer obs.
OBSERVATION COUNT CHANGE: DB2ACCT has fewer obs.
Thanks to Nicholas Ward, Northern Territory Government, AUSTRALIA.
Change 20.127 IBM MSU Capacity Values for MultiPrise 7060 CPUs are not
FORMATS going to be provided by IBM (!!!), but Al used Cheryl's
Jul 16, 2002 input and his best guess to estimate an MSU capacity in
this update to the MXG format $MG070CP, used to create
the MSU capacities in dataset RMFINTRV, for the 7060
models H30, H50, H55, H70, and H75.
Thanks to Andrew Woods, FT Ineractive Data, ENGLAND.
Thanks to Alan Sherkow, I/S Management Strategies, USA.
Thanks to Cheryl Watson Walker, Watson & Walker, USA.
Change 20.126 Variable UNITADDR was changed to DEVNR in this report
ANALCACH example, so all four digits of the address are displayed.
Jul 16, 2002
Thanks to Jon G. Whitcomb, Great Lakes Educational Loan Service, USA.
Change 20.125 The SMF type 90 subtype 32 record was not supported in
EXTY9032 the TYPE90A member (which should be used instead of the
FORMATS old TYPE90 member) and the MG090CM format was updated for
VMAC90A subtypes 27-32.
VMXGINIT
Jul 16, 2002
Thanks to Bruce Hewson, Citicorp, SINGAPORE.
Change 20.124 The automatic creation of SORTEDBY= added to VMXGSUM by
ASUM42DS Change 20.094 caused this special case to fail, because
Jul 15, 2002 one of the variables in the SORTEDBY= list was renamed in
the final data step. The code was revised to relocate
the rename to avoid the error.
Thanks to Gary Keers, Indianapolis Light & Power, USA.
Change 20.123 Unused Change Number.
Change 20.122 Variable QWACAWDR, Wait Time for Drain Lock, was wrong.
VMACDB2 The statement QWACAWDR=QWAXAWDR; was deleted, because it
Jul 14, 2002 overrode the QWACAWDR=QWAXAWDR/4096; statement a few
lines earlier that set the correct value.
Thanks to Scott Mcdonall, Southern California Edison, USA.
Change 20.121 The Read/Write variables S94CLRD0-7 and S94CLWD0-7 were
VMAC94 formatted with MGBYTES to display bytes transferred, but
Jul 14, 2002 not converted internally from frames to bytes; they are
now multiplied by 4096 to correctly contain and display.
Thanks to Thomas Heitlinger, FIDUCIA IT AG Karlsruhe, GERMANY.
Change 20.120 Cosmetic. Labels for NSPL/NSPP/NSPS frames now contain
VMACNSPY Logical Link, Physical Link, and Physical Unit to clarify
Jul 14, 2002 their contents.
Thanks to Bruce Rosenthal, Inovant, USA.
Change 20.119 Variable S94MTVCA, Maximum Age of any Volume in VCA, was
VMAC94 not converted to seconds nor format TIME8, and thus was
Jul 14, 2002 unlike SMF94VCA, Average Age of volumes in the VCA. Now
both "age" variables are displayed in units of duration.
Thanks to Frank Zemaniak, Vanguard, USA.
Thanks to Ep van der Es, Dow Chemicals, BELGIUM.
Change 20.118 Two additional optional Candle CICS segments, CANPROD2
IMACICD2 and CANPROD3 are now supported when UTILEXCL detects they
IMACICD3 have been added to your type 110 SMF records. Each is a
UTILEXCL four byte field that now creates variables CANPROD2 and
VMAC110 CANPROD3 with those data.
Jul 14, 2002
Thanks to Junaina Haji Abdul Jalil, Qantas Airways Limited, AUSTRALIA
Change 20.117 SAS V6-only: %macro compiler appears to have mis-parsed
VMXGRMFI and lost an end-of-comment */ that ended in column 72,
Jul 14, 2002 immediately prior to an imbedded old-style definition of
MACRO _KRMFINT, with a user-tailored VMXGRMFI execution.
Removing the */ and rerunning under V8 generated the same
error message. This is not the first time that parsing
MXG code with both old-style MACRO definitions and %macro
statements has gone astray when text was in column 1 or
72, but since this error does not occur with SAS V8, I
chose to EDIT end comments so column 72 and 1 are blank
in VMXGRMFI, just for future problem avoidance, and so
the program will still work with Version 6.
Thanks to Albert Nosier, Qantas Airways Limited, AUSTRALIA.
Change 20.116 Support for Type 74 subtype 7 FICON data, new datasets:
EXTY747P TYPE747P - FCD Global, Switch, and Port data
EXTY747C TYPE747C - FCT Connector data
VMAC74 TYPE74P matches RMF reports, but only ports of type CHPID
VMXGINIT (R747PTFL='20'X) appear to have real data. Other ports
Jun 25, 2002 have R747PTFL='00'X and R747PCU='0000'X, but have large
Jul 14, 2002 (and unreasonably large) counts for frames and bytes.
I chose to output any port that had non-zero frame count,
since those ports are the only ports printed by RMF.
This support will likely be enhanced/revised when more
test data has been analyzed and IBM has been contacted.
Jul 14: Labels for PCTPNCHA/DLYCHATM variables changed to
"Director" verus Channel to agree with Change 17.269
APAR OW49638 relates to an RMF problem with FCD option.
Oct 5: Without this change, 74-7 caused DOMAIN ERROR
message; R747PFPT was only input as 4 bytes.
Thanks to Scott Wiig, U.S. Bank, USA.
Thanks to Stephen Hoar, Lloyds TSB, ENGLAND.
Thanks to Lawrence Jermyn, Fidelity Systems, USA.
Change 20.115 Cosmetic, has been this way for a long time; the dataset
VMXGSUM label was a single double-quote (rather than blank) for
Jun 24, 2002 datasets when DSNLABEL was not used to label the dataset.
Thanks to Freddie Arie, TXU, USA.
Change 20.114 STCVSM28 dataset (new in MXG 20.03) variable STC28CLN had
VMACSTC STC28VID as its value, and STC28VID was not kept. Change
Jun 23, 2002 the second STC28CLN of each pair to STC28VID.
Variables STC27RES an STC27STP are formatted $MGSTCSL.
and $MGSTCSD. after extraneous lines were removed.
Thanks to Freddie Arie, TXU, USA.
Change 20.113 VVDS fields were not correctly decoded if the component
VMACVVDS name was exactly 44 bytes; the MXG $VARYING44. INPUT must
Jun 21, 2002 be increased to $VARYING45. (four places) because the one
byte length field has a value of 45 when the name is 44,
and that put MXG's INPUT out of alignment.
Thanks to Mike Field, Royal Bank of Scotland Group, ENGLAND.
Change 20.112 197 source files in my master directory had a '1A'x EOF
DOC character as their last byte; these stray characters are
Jun 20, 2002 created on Windows by SPF/PRO or SPFPC EDITORs, when the
FILE TERMINATOR='Y' is specified instead of ='N'. That
option is set for each profile (file suffix) on the 2nd
page of the PROFILE options. That character only causes
a problem if you upload the ASCII file to MVS, which will
create a new source line with an unprintable '3f'x hex
character that causes a syntax error, or an ASM error.
The MXG tape and CD-ROM have never contained an '1A'x,
nor do the ftp ebcnnnn/ascnnnn files (it did exist in the
ftp dirnnnn.zip file). All '1A'x were removed. This
change was included in the MXG 20.03 release.
Thanks to MP Welch, SPRINT, USA.
=======Changes thru 20.111 were in MXG 20.03 dated Jun 19, 2002=========
Change 20.111 Oracle OSDI records can only be recognized by SUBSYSID;
VMACORAC MXG's default IF SUBSYSID='OSDI' THEN DO; in VMACORAC
Jun 18, 2002 caused lots of missing values if your subsystem name(s)
were something else. This change created new _IDORACO
macro definition to externalize the test. To select your
Oracle subsytems, you would code the expression you want
to be true as the value of the _IDORACO macro:
MACRO _IDORACO
SUBSYSTEM IN ('ABCD','EFGH', :'OSD')
%
and that MACRO definition can be put in your IMACKEEP
tailoring member, or can be defined in the //SYSIN with
//SYSIN DD *
%LET MACKEEP= MACRO _IDORACO .... % ;
Note the colon before 'OSD' selects starting-with-OSD.
Thanks to Dick Triplett, Lockheed Martin, USA.
Change 20.110 New WEEKCEC annd WEEK70PR members based on TRNDCEC/70PR
WEEKCEC will build the WEEK.ASUMCEC/WEEK.ASUM70PR correctly from
WEEK70PR partial weeks data.
Jun 18, 2002
Thanks to Diane Eppestine, SBC Services, USA.
Change 20.109 ENCG3 record with no segments (ENCG3TEO=0 or ENCG3DEO=0,
VMACRMFV or both 0), caused INPUT STATEMENT EXCEEDED error. MXG
Jun 17, 2002 tests TEO/DEO, deletes record if either are zero, and
prints a message for each deleted zero segment record.
Thanks to Jerry Urbaniak, Acxiom CDC, USA.
Change 20.108 Documentation note. Variable UOWTIME can have a value in
VMAC110 the future or the past, but not likely a valid "present"
May 23, 2002 value. UOWTIME is decoded from the first six bytes of
Jun 17, 2002 UOWID field, historically displayed as a datetime value.
Jul 25, 2002 But its only use is as a token, to match multiple CICS
MRO transactions together, or to match CICS and DB2ACCT;
so the datetime value is never used nor important.
Now, IBM often puts a valid TODSTAMP value in those six
bytes of UOWID, but I cannot change the MXG UOWTIME code,
safely, simultaneously, in all of the datasets that have
the UOWTIME variable for matching, so we are thus stuck
with a seemingly invalid value in variable UOWTIME.
But, if you see that UOWIDCHR does contain a TODSTAMP
value, (like 'B74AA17CB093'x for 07MAR2002:14:03:56.26),
you can create the actual arrival time in a new variable
UOWTOD, using the UOWIDCHR and GMTOFFxx variables:
UOWTOD=INPUT(UOWIDCHR!!'0000'X,TODSTAMP8.);
FORMAT UOWTOD DATETIME21.2;
LENGTH UOWTOD 8;
UOWTOD=UOWTOD+GMTOFFTM;
in your analysis programs. Adding the GMT Offset is
required because the UOW time is on GMT; note that MXG
has different names for the GMT offset variable.
P.S. That 'B74AA..'x UOWID value was decoded by MXG
in UOWTIME as '13OCT2001:01:56:38.49'.
Change 20.107 Syntax ARRAY CTR{54} was not accepted by SAS 6.09 at TS
TYPEIMSA TS450; CTR {54} with a blank inserted before and after
Jun 17, 2002 the "Squiggly" parentheses was required for old 6.09.
Thanks to Romain Capron, MATMUT, FRANCE.
Change 20.106 Support for G06 TANDPROC LRECL=442 record (INCOMPATIBLE)
VMACTAND eliminated the DIVIDE BY ZERO error. This record had
Jun 15, 2002 DURATM of zero in the record; MXG re-calculates duration
as DURATM=ENDTIME-STARTIME if the DURATM field is zero.
Variables starting with DEVICENM were misaligned; GNPUT,
because TMFFILL3 in the G05 record is where DEVICNM is
found in this G06 record. Six new variables are INPUT as
F1-F6 from the end of the record; they will be renamed
and labeled when I get G06 TANDPROC documentation.
Thanks to Alex Torben Nielsen, TeleDanmark EDB, DENMARK.
Change 20.105 Enhanced with new graph of "Weighted LPAR Capacity" used,
GRAFWRKX and a new print report (PROC TABULATE) can be printed if
Jun 15, 2002 you don't have SAS/GRAPH. The tabular report will be
created if you specify TABULATE=YES. If you do have
SAS/GRAPH, specifying TABULATE=YES will create both the
graphs and the report.
The "Weighted LPAR capacity" can be important because it
is based on the defined weight of the LPAR and the number
of processors, whereas the "MVS Capacity" (PCTCPUBY
in RMFINTRV) is based solely on the number of processors
defined to an LPAR. The Weighted utilization can exceed
100%, which means simply that the LPAR is exceeding the
share of the CEC that is defined by its specified weight.
As an example, assume an LPAR with 2 CPs and a weight
of 15, on a 10 engine CEC with total weight of 100.
Then this LPAR has a weighted capacity of 1.5 CPs, and a
maximum usable capacity of 2 CPs. When the CEC is
constrained, the PCTCPUBY reported by RMFINTRV from the
MVS perspective will never exceed 1.5/2.0 or 75% busy,
but the LPAR is running at 100% of its weight-defined
capacity. However, if the CEC is not constrained, the
LPAR can use some or all of the extra 0.5 CP. RMFINTRV
could show PCTCPUBY=90%, using 1.8/2.0 but that means the
LPAR used 120 "percent of the weighted capacity", which
may be an indication that this LPAR needs more power.
Whether you are creating graphs or tabular reports, you
can create HTML and GIF datasets on an OS/390 platform to
be displayed only on OS/390, or you can create HTML/GIF
output with TRANTAB=ASCII that can only be displayed on
ASCII systems. The VMXGWRKX argument HTMLDEST=ASCII
sets ASCII as default; to create EBCDIC-displayable PDSE
members, add HTMLDEST=, i.e., a null value, to your
%VMXGWRKX(HTMLDEST=, ...); invocation.
The HTML output must be written to a PDSE on OS/390 with
RECFM=VB,LRECL=8000,BLKSIZE=8004; that PDSE dataset must
be allocated using a FILENAME statement rather than with
a DDNAME in your JCL. When %VMXGWRKX is executed the
HTML text and images are written to the PDSE library to
members named FRAMWRKX, GRAFWRKX, CONTWRKX, and GCHARTnn,
if graphs were also generated. For ASCII viewing, those
those members should be downloaded (as binary files) to
file on your ASCII system using names of:
framwrkx.html grafwrkx.html contwrkx.html gchartnn.gif
(NOTE: CASE is important. Your browser may not find them
all if the case does not match its expections.)
One either EBCDIC or ASCII systems, point your browser at
member FRAMWRKX or the FRAMWRKX.HTML file to access the
contents and the reports and graphs you created.
Obscure Note: If HTMLDEST=ASCII and TABULATE=YES, a
FORMCHAR='xxxxxxxxxxxxxxxxxxxxxxxxxx' is generated on
the PROC TABULATE, and it makes the printed report on
the SASLIST output pretty much meaningless; however,
without that FORMCHAR= operand, HTML written to the
PDSE is pretty much useless.
Thanks to Chuck Hopf, MBNA, USA.
Change 20.104 The MXG ANALRMFR "RMF HTTP Server Report" didn't print
ANALRMFR web server name (MXG variable HOSTNAME), didn't print
VMAC103 separate reports for multiple servers on same system,
Jun 14, 2002 and had incorrect/transposed values. VMAC103 was revised
to increase variable HOSTNAME from $8 to $32; I thought
it was MVS System "host" name and limited to $8 bytes.
Thanks to Cheryl Watson Walker, Watson & Walker, USA.
Change 20.103 Whether or not to comment out the BO DROPMAP NONRECOV?
ASMIMSL6 instruction for OTMA records may be something you have
Jun 13, 2002 try both ways and see which gives correct results. One
site, with IMS 6.1, found it necessary to reinstate the
comment to disable the BO DROPMAP NONRECOV? statement.
Change 20.102 Logic for CICSJOUR dataset (unidentified CICS Journal
VMAC110 segment in SMF 110 Subtype 0 record) was not correct for
Jun 12, 2002 CICS/ESA 4.1 and CICS/TS 5.1, causing the USERDATA field
to be blank. ELSE IFs were missing, and 4.1 did not set
the LENUDAT field from JCRLL.
Thanks to Len Rugen, University of Missouri, USA.
Change 20.101 Support for JES2/JES3 "Z2 Mode" (INCOMPATIBLE) to allow
ANAL30DD 200,000 jobs and 9,999,999 job numbers. MVS Technical
ANALEPMV Note 11 in MXG Newsletter FORTY-ONE provides reference to
IMACCADI the IBM Flash that lists the many exposures when your
VGETJESN enable the Z2 Mode, which changes JCTJOBID to "Jnnnnnnn"
VMAC26J2 for JOBS, etc. This change created member VGETJESN to
VMAC26J3 decodes both formats of JCTJOBID into TYPETASK & JESNR.
VMAC30 Note: CONTROL-D has only a 5-byte position for JESNR;
VMAC32 That product will require changes in their SMF
VMAC42 record to support the Z2 mode, and this note will
VMAC6 be updated when/if that product supports Z2.
VMAC91 Some additional symptoms: TYPETASK='J00', 'T00', 'S00'.
VMACBETA
VMACDALO
VMACIPAC
VMACNNAV
VMACSFTA
VMACTMNT
VMACXPSM
Jun 13, 2002
Thanks to Michael Richard, CompuWare, USA.
Change 20.100 Support for Citrix was not included in Change 19.148; the
VMACNTSM Citrix process record has an extra counter (NRDATA=22)
Jun 11, 2002 that is now supported by this change.
Thanks to Robert Gauthier, Albertsons, USA.
Change 20.099 New variable MSU4HRMX was missing in PDB.TRNDRMFI dataset
TRNDRMFI because it was calculated in the INCODE= argument, but
Jun 11, 2002 its source variable, MSU4HRAV was not in any of the other
arguments to VMXGSUM. While using KEEPIN=MSU4HRAV would
have corrected this one variable, KEEPALL=YES is better,
as it has lower overhead and protects future variables.
Thanks to Fred Kaelber, Southwestern Bell, USA.
Thanks to Diane Eppestine, Southwestern Bell, USA.
Change 20.098 This is "Maintenance Level, ML-23" of MXGTMNT, the Tape
ASMTAPES Mount and Tape Allocation Monitor program, which adds the
Jun 10, 2002 EXCLUDE logic so you can suppress monitoring of your VTS
devices by DEVNR, so you can avoid filling your Logrec
file with 0E0 Software ABEND records.
When a very fast VTS scratch mount occurs, MXGTMNT can
receive (and recover from) the 0E0 ABEND (because the
job had already terminated before its next sample),
but our friends at IBM still write a Logrec record for
each 0E0 recovery, and MXGTMNT has filled Logrec with
over 25,000 records in one day, causing a B37 in EREP!
After four months research with IBM'd trying to use an
STOKEN to prevent the logrec record, IBM now says that
only an FRR (Functional Recovery Routine) can suppress
the Logrec record, and an FRR is not trivial to add.
This change is an interim solution, pending the FRR code.
To exclude DEVNRs from MXGTMNT, you will need to add the
optional //EXCLUDE DD statement (FB,LRECL=80) to the JCL
for the MXGTMNT Started Task that points to the file that
contains your exclude control statements. The new logic
skips over UCBs that are both Tape Devices AND that are
specified in the EXCLUDE statements. Single DEVNRs
and/or ranges of DEVNRs are supported in this syntax:
Device Numbers can be specified like this, separated from
each other by blanks:
XXX /* ONE 3-DIGIT DEVICE NUMBER */
XXXX /* ONE 4-DIGIT DEVICE NUMBER */
XXX-XXX /* A RANGE OF 3-DIGIT DEVICE NUMBERS */
XXXX-XXXX /* A RANGE OF 4-DIGIT DEVICE NUMBERS */
Any combination of the above can be used, separated by
blanks in columns 1 thru 80 on the statements read from
the //EXCLUDE DD. Characters in device numbers must be
Hex Digits, 0-9 and/or A-F.
These Device number Specifications are NOT valid:
XX-XX
X-XX
XX-X
X-X
XXX-XX
XX-XXX
X
XX
Comments may NOT appear on the same statement as a device
number to exclude.
Each device number or device number range must be
followed by at least one blank.
In addition to adding the FRR to ASMTAPES/MXGTMNT monitor
program to ultimately monitor VTS devices without 0E0s, I
hope to enhance the ASUMTAPE program (that creates the
PDB.ASUMTAPE dataset from the MXGTMNT records and IBM's
SMF 21 dismount record) first by adding the STK VTC SMF
data, and second with the IBM SMF 94 data to provide
additional timestamps and values from those records into
an enhanced PDB.ASUMTAPE dataset. The ASUMTAPE changes
will hopefully be completed by the end of Summer.
17Jun02: ASMTAPES is now being enhanced, and an FRR is
not going to be required, so the ML-24 that will monitor
VTS devices (catching those mounts longer that 2 seconds,
but without writing 0E0 messages to logrec) should be
available very soon.
Change 20.097 Another instance of DOMAIN ERROR was caused by IBM's mis-
VMAC91 documentation of fields SMF91SDI and SMF91SDO as long
Jun 10, 2002 floating point values, but the data values in the subtype
3 were '0000000000000002'x and '000000B600000070'x, which
are clearly not floating point values. The second value
is 728GB is highly suspect, as all of the other counters
are zero in this particular record. A problem will be
opened with IBM and this note will be updated when they
respond, but the two inputs for SDI and SDO are now PIB
instead of RB, which will eliminate the DOMAIN ERROR.
See NEWSLETTER FORTY-ONE, SAS TECHNICAL NOTE 7.
Thanks to Dan Doan, Verizon, USA.
Change 20.096 TYPE73 observations for SMF73ACR='CFS' (Coupling Facility
VMAC73 Channels) had PCHANBY missing, but RMF Reports showed non
Jun 7, 2002 zero values for "Total" Channel Utilization (but had dash
for the "Partition" percent). The records had SMF73CMG=1
and thus I calculated PCHANBY and PNCHANBY only if the
SMF73PTI (measurement interval) was non-zero. But in the
'CFS' records, SMF73PTI, PBY, PTI, PUT, and TUT are all
zero. In looking in detail, it turns out that for the
'CFS' channel, the old SMF73BSY and SMF73STP fields are
what IBM is using to calculate PCHANBY, and the PNCHANBY
file is not calculatable for the CFS channels. MXG now
uses the PTI-based fields if present, but will use the
original BSY/STP calculation when PTI is zero.
Thanks to John Gebert, Office Depot, USA.
Change 20.095 MXG did not correctly input the GMT Offset value, causing
VMACTMDB GMTOFFTM and all timestamps were incorrect, if your GMT
Jun 6, 2002 offset was non-zero. The timestamps printed as astricks.
Thanks to Paul van den Brink, Fortis Bank, THE NETHERLANDS.
Change 20.094 A combination of circumstances caused NOT SORTED error in
MONTHBLS dataset TYPE30OM, but MXG Change 19.172, that increased
MONTHBLD the stored length of many numeric variables from 4 to 5
MONTHBL3 bytes, was the underlying culprit:
WEEKBLD - TYPE30OM is unique; it's BY list has integer numeric
WEEKBL3 variables OMVSOSI, Session ID and OMVSOPI, Process ID.
WEEKBLDT Most variables in BY lists are character variables.
WEEKBL3T - The problem occurs only when both OMVS/USS and OS/390
Jun 4, 2002 have stayed up a long time, allowing ID number value in
VMXGSUM OMVSOSI/OMVSOPI to exceed 16,217,666. Only integers of
Jun 18, 2002 that value can be truncated when stored in 4 bytes.
VMXG2DTE In this case OMVSOSI and OMVSOPI were equal and large!
Jun 13, 2002 - The problem occurs only when the WEEK1 DD, which is the
ASUM78CF first libref in the SET statement, points to an old PDB
Jun 14, 2002 that was built by MXG earlier than 19.10. That old PDB
had the original, sort, 4-byte length, and the first
dataset in the SET statement is used by SAS to define
the stored length of the output MONTH.TYPE30OM dataset.
It is better that the WEEK1 DD points to the most
recently build PDB, created by the new MXG version,
so that all new changes (like the longer length) are
seen first to set the definitions.
And it is best to install a new MXG Version on
the first day of your week; if you build WEEKLYs
on Monday morning, then install the new version
Monday afternoon when all is done, so that all of
next week's PDBs are built with the same version.
With the MXG change and those circumstances, the old PDB
4-byte definition was used, causing the new 5-byte values
to be truncated to smaller numeric values, which SAS saw
as an out-of-sequence error in the sort-order validation
that is invoked when there is a BY statement in a DATA
step. The simple correction is to point WEEK1 at the new
PDB, so that the new attributes are seen first and used.
Or you could add a LENGTH OMVSOSI OMVSOPI 5; statement
between the DATA statement and the SET statement.
One other alternative is to remove the BY statement,
since no reports in MXG demand that the TYPE30OM dataset
is in sort order.
When you have DATA ONE; SET TWO THREE FOUR; BY A B C;
the BY statement causes the output dataset to be built
in the A B C sort order of the input datasets, without
invoking a PROC SORT. When there is no BY statement,
dataset ONE will be the concatenation of TWO, THREE,
and FOUR, and won't be sorted. The big advantage of
having the dataset sorted is so you don't have to SORT
in report program that exploit the same sort order.
And if you should invoke PROC SORT to sort an already
sorted dataset, PROC SORT recognizes sorted data and
will bypass an unnecessary sort, saving lots of time
with big datasets.
That was the end of the original text, and there had been
no MXG code changed, until after I added this note:
When you create a dataset with PROC SORT, SAS stores
the BY list in the directory of that dataset, but when
you create an output dataset with a DATA step, you
need to use the SORTEDBY= dataset option to tell SAS
that the dataset is created in that SORT order, so
that subsequent PROC SORTs can be bypassed by SAS.
I then looked at my code; while SORTEDBY= is used in the
BUILDPDB code for datasets created by DATA steps instead
of by PROC SORT, I discovered I had never implemented the
SORTEDBY= dataset option in the weekly and monthly code.
The actual code change made by this MXG Change was to add
SORTEDBY= to each DATA step in the listed MONTHxxx and
WEEKxxxx members, so that SAS can now recognize and
bypass unnecessary sorts of the weekly and monthly PDBs.
-VMXGSUM was revised to set the SORTEDBY= parameter when
it creates its output dataset, whether it uses a DATA
step, or a PROC MEANS to create the dataset. This change
exposed an unanticipated option in ASUM78CF's invocation
of VMXGSUM, which had the dataset options (LABEL=...) in
its OUTPUT= argument, which previously worked but was not
supported (instead, the DSNLABEL= argument is provided in
VMXGSUM for the output dataset label option). While the
ASUM78CF member was revised to use DSNLABEL, VMXGSUM was
revised to detect the existence of a start paren in the
OUTDATA= and will now suppress the addition of SORTEDBY=
so your existing ASUM78CF won't fail. A later revision
will actually parse to the end-paren and insert the
SORTEDBY= list inside your dataset options!
-VMXGSUM revised to protect DATETIME in a SUMBY= list by
moving the DATETIME= list into the SORTEDBY= list.
This will be further enhanced in the next version to move
the SORTEDBY string inside the parens, if possible, but
this eliminated the abend caused by ASUM78CF syntax.
Obscure Note: In this revision it was noticed that
VMXGSUM could ABEND with INVALID DATASET OPTIONS:
- 1. you use dataset options in the OUTDATA=, and
- 2. the final data setp is flagged as unneeded
- 3. PROC MEANS is used to conditionally drop vars:
This happens only if all these are true:
no NORMx, ERASEOUT NE NO, no OUTCODE statement,
no FREQ, no INTERVAL, no NEWSHIFT, SAS V8+.
Has not occurred, it is likely no one is using dataset
options in the OUTDATA= argument, but now documented.
Thanks to MaryBeth Delphia, Texas Comptroller of Public Accounts, USA
Change 20.093 Variables VVROPIND, SMF60FNC, VVRAMAT3 and VVRTPEXT were
VMAC60 not kept in dataset TYPE60. Those variables and VVRSMSFG
Jun 3, 2002 are now input as $CHAR1 instead of $EBCDIC1 (which has no
impact when MXG is executed on MVS, but is required for
hex-containing variables if MXG is executed on ASCII);
all five variables are now formatted $HEX2.
Thanks to Michael E. Friske, Fidelity Systems, USA.
Change 20.092 Major enhancement for TNG support for new Platforms, new
EXTAI006 Objects, and new Variables, plus logic revisions to cover
EXTAI007 new idiosyncrasies in the TNG performance cube data:
EXTAI008 -Platform tests for PLATFORM=:'SOL' and PLATFORM=:'AIX'
EXTAI009 should eliminate dependency on specific platform name.
EXTAI010 -Instance counts were increased where new instances found.
EXTAI011 -Algorithm for text length in the CAPCM Header was found
EXTAI012 to be inconsistent with text length in other records,
EXTNT021 which caused the DOMAIN name to be incorrect; whereas the
EXTNT022 base-26 syntax is used in data records (i.e., '10'=36),
EXTNT023 the Header algorithm has '10'= 10!
EXTNT024 Note: Always look to see if any observations were output
EXTNT025 in the UNKNOWN dataset, and send the performance
EXTNT026 cube to support@mxg.com if there are any. If the
EXTNT027 last metric for an object is UNKNOWN, there will be
EXTNT028 zero observations output for that object.
EXTNT029 The complete list of TNG Objects now supported:
EXTNT030 PLATFORM OBJECT MAXIMUM MAXIMUM MXG
EXTNT031 NAME INSTANCE VARIABLES DATASET
EXTNT032
EXTNT033 AIX BUFFER 1 8 AI001
FORMATS AIX CPU 1 5 AI002
IMACTNG AIX PAGING 1 4 AI003
TYPETNG AIX QUEUES 1 4 AI004
VMACTNG AIX SWAPPING 1 1 AI005
VMXGINIT AIX IPC 1 2 AI006
May 27, 2002 AIX SYSTEM-CALLS 1 7 AI007
Jun 3, 2002 AIX FILE-ACCESS 1 3 AI008
AIX FILESYSTEM 1 2 AI009
AIX NETWORK 1 4 AI010
AIX TABLES 1 4 AI011
AIX TERMINAL 1 6 AI012
CIS2500 CISCO 7 130 C2001
CIS2500 MIB-2 34 89 C2002
CIS7500 CISCO 24 166 C7001
CIS7500 MIB-2 34 89 C7002
NT BROWSER 1 20 NT001
NT CACHE 1 27 NT002
NT ICMP 1 27 NT003
NT IP 1 17 NT004
NT LOGICALDISK 5 21 NT005
NT MEMORY 1 27 NT006
NT NBT CONNECTION 8 3 NT007
NT NETBEUI 2 39 NT008
NT NETBEUI RESOURCE 13 3 NT009
NT NETWORK INTERFACE 3 17 NT010
NT OBJECTS 1 6 NT011
NT PAGING FILE 2 2 NT012
NT PHYSICALDISK 3 19 NT013
NT PROCESSOR 2 10 NT014
NT REDIRECTOR 1 37 NT015
NT SERVER 1 26 NT016
NT SERVER WORK QUEUES 3 17 NT017
NT SYSTEM 1 25 NT018
NT TCP 1 9 NT019
NT UDP 1 5 NT020
NT NWLINK IPX 1 38 NT021
NT NWLINK NETBIOS 1 38 NT022
NT NWLINK SPX 1 38 NT023
NT SQLSERVER:ACCESS MET 1 19 NT024
NT SQLSERVER:BUFFER MAN 1 16 NT025
NT SQLSERVER:CACHE MANA 6 4 NT026
NT SQLSERVER:DATABASES 7 21 NT027
NT SQLSERVER:GENERAL ST 1 3 NT028
NT SQLSERVER:LATCHES 1 3 NT029
NT SQLSERVER:LOCKS 6 6 NT030
NT SQLSERVER:MEMORY MAN 1 14 NT031
NT SQLSERVER:SQL STATIS 1 7 NT032
NT SQLSERVER:USER SETTA 10 1 NT033
SOL BUFFER 1 8 SO001
SOL CPU 1 5 SO002
SOL DISK 3 6 SO003
SOL FILE-ACCESS 1 3 SO004
SOL FILESYSTEM 2 3 SO005
SOL IPC 1 2 SO006
SOL KERNEL MEMORY ALLOC 1 8 SO007
SOL MEMORY 1 2 SO008
SOL NETWORK 5 5 SO009
SOL PAGING 1 11 SO010
SOL QUEUES 1 4 SO011
SOL SWAPPING 1 5 SO012
SOL SYSTEM-CALLS 1 7 SO013
SOL TABLES 1 7 SO014
SOL TERMINAL 1 6 SO015
Thanks to Erling Andersen, SMT Data A/S, DENMARK.
Change 20.091 Support for IBM AIX PTX (Performance ToolBox) adds over
VMACAIX 100 new fields, and additional variable name sequences:
May 24, 2002 LABEL STARTS WITH BECOMES VARIABLES NAMED
CPU/ AIXCPU01-AIXCPU21
DISK/ AIXDIS01-AIXDIS56
FS/ AIXFS01 -AIXFS03
IP/NETIF AIXIP01- AIXIP49
LAN/ AIXLAN01-AIXLAN16
MEM/ AIXMEM01-AIXMEM15
NFS/ AIXNFS01-AIXNFS02
PAGSP/ AIXPAG01-AIXPAG05
PROC/ AIXPRO01-AIXPRO02
RPC/ AIXRPC01-AIXRPC04
SYS/ (SYSCALL,SYSIO) AIXSYS01-AIXSYS07
TCP/ AIXTCP01-AIXTCP06
UDP/ AIXUDP01-AIXUDP02
Thanks to Glenn Bowman, Wakefern, USA
Change 20.090 Unknown ESS keys were printed on the SAS log correctly,
IMAC6ESS but MXG did not skip over second and subsequent parms if
May 23, 2002 a key had GEPARMNR GT 1 parameter per key value. The
protection logic now skips correctly and prints the keys
found, but only in the first SMF type 6 record found.
The second part of this change will be the actual decode
GEPARMKY=0021x,2022x,002E segments, as soon as I can find
the new IBM documentation, which ain't easy for ESS data.
Thanks to Roman Jost, ERGO Integration, NORWAY.
Change 20.089 Variable MSU72 is created for each observation in TYPE72
VMAC7072 and TYPE72GO, using the total CPUTM captured:
May 23, 2002 MSU72=CPUTM*SU_SEC/1000000;
Thanks to Jim S. Horne's posting to MXG-L, Lowe's Companies, USA.
Change 20.088 Support for new Subtypes 27, 28, and 29 for STK HSC/VSM
EXSTCV27 user SMF record create these three new datasets:
EXSTCV28
EXSTCV29 dddddd Dataset Description
FORMATS STCV27 STCVSM27 VTV Scratch Status
IMACSTC STCV28 STCVSM28 VTV Replication
VMACSTC STCV29 STCVSM29 VTV and MVS Unlink Event
VMXGINIT
May 20, 2002
Thanks to Harold Radalin, Reader's Digest, USA.
Change 20.087 Internal macro definition of MACRO _VTYTPMX was added
VMACTPMX as described in the Change 18.338 that had not yet been
May 20, 2002 applied to this member.
Thanks to Lawrence Jermyn, Fidelity, USA.
Change 20.086 New variable EXECAPPL, hopefully the "execution" APPLID
VMXGUOW of the CICS Unit-of-Work observation in PDB.ASUMUOW, will
May 15, 2002 contain the APPLID name of the first region found with a
May 20, 2002 TRANNAME starting with CSxx (expected CSMI for the mirror
transaction). This should be the first AOR that handles
the Unit of Work, after the TOR. If you need more logic
to store an "APPLID" in variable EXECAPPL for a UOW that
uses many APPLIDs, new temp PATH1-PATH10 and TRAN1-TRAN10
variables are created with first ten APPLIDs (PATHs) and
corresponding first ten TRANNAMEs, so you could use them
in your "Case" logic to tailor VMXGUOW. The examples of
Case 1 and 2 were revised and tested, Case 3 example was
deleted.
Thanks to Ron Root, Texas Comptroller of Public Accounts, USA
Change 20.085 Type 119 subtype 3 records caused INVALID DATA message
VMAC119 and were not correctly decoded, because no test records
May 15, 2002 were available. Dataset TYP11903 is now validated.
Thanks to Keith Jefferson, Citicorp, USA.
Change 20.084 Continued picking away at flaws; if you EXCLUDEd WTTCIOTM
UTILEXCL (Terminal Control Wait), UTILEXCL did not create the code
May 15, 2002 statement "IRESPTM=ELAPSTM-WTTCIOTM;" in the IMACEXCL.
May 22, 2002 Now "IRESTPM=ELAPSTM;" is coded if WTTCIOTM is EXCLUDEd,
and since WTTCIOTM is normally zero except in the TOR
records, you should see little difference in IRESPTM.
22May02: Typo 'PSB SCHL' was changed to 'PSB SCHD',
to fix error message with IMS DL/I optional segment.
Thanks to Pat Curren, SuperValu Inc, USA.
Thanks to Richard S. Ralston, Whirlpool Corp. USA.
Change 20.083 Type 79 subtype 12 PIB fields were input as RB, causing
VMAC79 invalid values (and a DOMAIN ERROR on MVS), and new CMG
May 14, 2002 data was not DIF()'d, nor reset. Logic was revised.
Thanks to Dan Doan, Verizon, USA.
=======Changes thru 20.082 were in MXG 20.02 dated May 6, 2002=========
Change 20.082 Support for z/OS 1.3 (COMPATIBLE, except for SMF 42).
VMAC30 IBM changes to SMF records in z/OS 1.3 were compatibly
VMAC42 made (no data inserted), but MXG logic for SMF type 42
May 6, 2002 did ot correctly handle the IBM changes.
May 7, 2002 -New data added in SMF type 30 records:
New CPUCEPTM added to TYPE30_V,TYPE30_4,TYPE30_5,TYPE30_6
dataset; records the CPU time for an address space while
it was Enqueue Promoted, i.e., getting ERV Service Units
at high priority because it owned an enqueued resource,
and had been swapped out.
-New data added in SMF type 42 records:
New variables in dataset TYPE42D1 from subtype 16:
SMF42GAP='DATA CLASS NAME'.
SMF42GAJ='GT 4K CF*CACHE*ACTIVE*STATUS'
Values: blank or GT4ACTIVE, GT4KNOTACT, ALL,
UPDATESONLY, or NONE.
SMF42GRA='RE-DOS'
SMF42GRB='RECURSIVE*RE-DOS'
SMF42GRC='BMF*WRITES'
SMF42GRD='SCM*READ*REQUESTS'
SMF42GRE='SCM*READ REQUEST*CASTOUT*CONTENTIONS'
SMF42GRG='RE-DO*PERCENTAGE'
SMF42GRH='RECURSIVE*RE-DO*PERCENTAGE'
SMF42GRI='SCM*CASTOUT*LOCK*PERCENTAGE'
SMF42GZ8='SMS*DIRECT*WEIGHT'
SMF42GZ9='SMS*SEQUENTIAL*WEIGHT'
SMF42GBN='WLM*SERVICE*CLASS*NAME'
SMF42GBO='WLM*REPORT*CLASS*NAME'
SMF42GBP='SMS*DATA*CLASS*NAME'
-New variables in dataset TYPE42D2 from subtype 16:
SMF42GRL='RE-DOS'
SMF42GRM='RECURSIVE*RE-DOS'
SMF42GRN='BMF*WRITES'
SMF42GRO='SCM*READ*REQUESTS'
SMF42GRP='SCM*READ REQUEST*CASTOUT*CONTENTIONS'
SMF42GRR='RE-DO*PERCENTAGE'
SMF42GRS='RECURSIVE*RE-DO*PERCENTAGE'
SMF42GRT='SCM*CASTOUT*LOCK*PERCENTAGE'
-New variables in dataset TYPE42X1 from subtype 19:
SMF42JN7='WRITE*REQUEST*SYSPLEX*TOTAL'
SMF42JTA='AVG SCM*READ REQUEST*CASTOUT'
SMF42JTB='TOT SCM*READ REQUEST*CASTOUT'
SMF42JTC='AVG SCM*READ REQUEST'
SMF42JTD='TOT SCM*READ REQUEST'
SMF42JTE='CURR PCT*SCM*READ REQUEST*CASTOUT'
SMF42JTF='LOW PCT*SCM*READ REQUEST*CASTOUT'
SMF42JTG='HIGH PCT*SCM*READ REQUEST*CASTOUT'
SMF42JTH='AVG PCT*SCM*READ REQUEST*CASTOUT'
SMF42JTI='AVG*RE-DOS'
SMF42JTJ='TOTAL*RE-DOS'
SMF42JTK='AVG*RECURSIVE*RE-DOS'
SMF42JTL='TOTAL*RECURSIVE*RE-DOS'
SMF42JTM='CURR PCT*RE-DOS'
SMF42JTN='LOW PCT*RE-DOS'
SMF42JTO='HIGH PCT*RE-DOS'
SMF42JTP='AVG PCT*RE-DOS'
SMF42JTQ='CURR PCT*RECURSIVE*RE-DOS'
SMF42JTR='LOW PCT*RECURSIVE*RE-DOS'
SMF42JTS='HIGH PCT*RECURSIVE*RE-DOS'
SMF42JTT='AVG PCT*RECURSIVE*RE-DOS'
SMF42JUA='AVG*INTERVALS*PROCESSED*ACCELERATED'
SMF42JUB='TOT*INTERVALS*PROCESSED*ACCELERATED'
-New variables in dataset TYPE42X2 from subtype 19:
SMF42JP2='INTERVALS*PROCESSED*ACCELERATED'
SMF42JSA='SCM*READ REQUEST*CASTOUT'
SMF42JSB='SCM*READ REQUEST'
SMF42JSC='CURR PCT*SCM*READ REQUEST*CASTOUT'
SMF42JSD='LOW PCT*SCM*READ REQUEST*CASTOUT'
SMF42JSE='HIGH PCT*SCM*READ REQUEST*CASTOUT'
SMF42JSF='AVG PCT*SCM*READ REQUEST*CASTOUT'
SMF42JSG='RE-DOS'
SMF42JSH='CURR PCT*RE-DOS'
SMF42JSI='LOW PCT*RE-DOS'
SMF42JSJ='HIGH PCT*RE-DOS'
SMF42JSK='AVG PCT*RE-DOS'
SMF42JSL='RECURSIVE*RE-DOS'
SMF42JSM='CURR PCT*RECURSIVE*RE-DOS'
SMF42JSN='LOW PCT*RECURSIVE*RE-DOS'
SMF42JSO='HIGH PCT*RECURSIVE*RE-DOS'
SMF42JSP='AVG PCT*RECURSIVE*RE-DOS'
-New SMF 42 subtype 20 is written when STOW INITIALIZE IS
used to delete all members of a PDSE. The new TYPE4220
dataset contains variables:
SMF42KJB='JOB NAME*STC OR*TSO USERID*WHO STOW-D'
SMF42KST='STEP*NAME'
SMF42KPR='PROC*NAME'
SMF42KDS='DATA SET NAME'
SMF42KVS='VOLSER'
-New SMF 42 subtype 21 is written when a member of a PDS
or a PDSE is deleted, with new dataset TYPE4221 vars:
SMF42LJB='JOB NAME*STC OR*TSO USERID*WHO STOW-D'
SMF42LST='STEP*NAME'
SMF42LPR='PROC*NAME'
SMF42LDS='DATA SET NAME'
SMF42LVS='VOLSER'
SMF42LNL='LENGTH*OF MEMBER*NAME'
SMF42LFL='ALIASES*EXCLUDED*DUE TO*RECORD LENGTH'
SMF42LMN='MEMBER*NAME*THAT WAS*DELETED'
-New SMF 42 subtype 21 is also written with the Alias
Names that were deleted because its primary member
name was deleted. New variable description says it all:
SMF42LAN='ALIAS NAME*DELETED IN*SYMPATHY'
-Status:
This change has not been validated with 1.3 data.
IBM additions to RMF 79 Channel data, and additions to
SMF 99 (License Manager) won't be written until I have
test data records.
Change 20.081 z/VM MONWRITE Control Records with DATABYTE=0 caused the
VMACVMXA "WHOOPS ..." error and MXG stopped reading records. IBMs
May 4, 2002 MONWRITE now creates an "E" Event Control Record with
May 14, 2002 DATABYTE=0 that is followed by a data record that MXG did
not expect, since the control record said there were zero
bytes following! Pairs of bad records were found 4 times
in 900 intervals; each bad pair was immediately followed
by a valid pair of an Event Control Record (DATABYTE=20)
and an Event data record with one 20 byte (1.11) segment.
Knowing what IBM writes, this change detects and deletes
both records, and prints a one-line message when any of
these bad DATABYTE=0 records are found and deleted. If
IBM ever corrects these records, it will be noted here.
May 14: IF DEBUG=. THEN DEBUG=-99; changed to DEBUG=.;
Thanks to Pat Curren, SuperValu Inc, USA.
Thanks to Jean Nelson, SuperValu, USA.
Change 20.080 The SMF94VLS (Library Sequence Number) is no longer a
ANAL94 number, but now contains characters ('B1031'), causing
VMAC94 SMF94VLS to have a missing value; and ANAL94 produced
May 2, 2002 no reports if you had selected a Library number. Since
Aug 11, 2002 SMF94VLS is defined as a numeric variable, changing it
to a character variable could cause execution errors in
your perfectly running reports, so new variable SMF94VLC
with LABEL='LIBRARY*SEQUENCE*NUMBER*CHARACTER' is created
in dataset TYPE94, and the ANAL94 program was changed so
you can use the value in your SMF94VLC to select reports
for a specific Library.
Thanks to Oliver H. Richter, American Management Systems, USA.
Change 20.079 Cosmetic. When there is a mismatch between 70s and 72s
VMXGRMFI in building RMFINTRV, the MXG note was enhanced to print
May 2, 2002 the IN71 IN73 IN74 IN75 and IN78 status variables in
addition to the IN70 and IN72, for diagnostic help.
Thanks to Chuck Hopf, MBNA, USA.
Change 20.078 AS400 Version 4.5.0 (but not 5.1.0) had INVALID DATA FOR
VMACQACS variable SYSJDUM in the QAPMSYST dataset because fields
May 2, 2002 SYSDBC and SYSSWC were inserted by the earlier '4.5.0'
May 5, 2002 version. Change the IF ASLEVEL GE '5.1.0' THEN INPUT...
before SYSDBC/SYSSWC to QIF ASLEVEL GE '4.5.0' THEN ....
And PCTCPSBY was wrong; the SYSDBC was changed to SYSSWC
in its equation. And Change 20.004 needs to be applied
to the other two CPU-time-variables JBEDBC and JBTDBC in
both QAPMJOBL and QAPMJOBM datasets; non-zero data values
now show they too are &PD.8.6 rather than documented 8.3.
Thanks to Andre Baltimore, Unigroup Inc. USA.
Change 20.077 If you enabled TIMEBILD/VMXGTIME to change timestamps,
VMAC78 TYPE78 data had incorrect STARTIME; it was converted
May 2, 2002 twice. Remove the STARTIME in the second %VMXGTIME
invocation.
Thanks to Chuck Hopf, MBNA, USA.
Change 20.076 The JCL Procedure examples MXGSAS and MXGSASV8 contained
MXGSAS DISP=(MOD,PASS) for //NULLPDS, as does SAS defaults, but
MXGSASV8 the CA Job Scheduler CA-11 product regards any step with
May 2, 2002 DISP=PASS to be non-restartable (because it cannot tell
JCLTEST6 if that dataset will be referred to in a later step). The
JCLTEST8 DISP=(SHR,PASS) were changed to DISP=SHR, and the NULLPDS
Sep 7, 2002 DD was changed from MOD,PASS to now MOD,DELETE in May.
Updated Sep 7: MOD,DELETE failed in second execution in
SMS site, 213-04. Change back to MOD,PASS avoided that
SMS-induced error, but that site did not have CA-11.
Changing MOD,PASS to NEW,DELETE resolves both the CA-11
and SMS errors, and there is no real need for MOD anymore
(it's a hold-over from pre-SMS days to protect if a real
dataset already existed that would have failed with NEW
but now that all datasets must be cataloged, MOD is not
needed here).
Bottom line:
DISP=(NEW,DELETE) for NULLPDS works for SMS and CA-11
and DISP=SHR instead of DISP=(SHR,PASS) works for CA-11.
Thanks to J.C. Houck, Bank of America, USA.
Thanks to Jesse Gonzales, The Gap, USA.
Thanks to Art Cuneo, Health Care Services Corporation, USA.
Change 20.075 Variable NRTIMES was created with PROC MEANS NOPRINT with
ANALPROG OUTPUT OUT=SUMS N=NRTIMES; VARIABLES CPUTCBTM; but the
May 1, 2002 LABEL for NRTIMES in the output dataset is the label of
the CPUTCBTM variable, which I thought was a SAS error.
However, documentation of V8 INHERIT option does state:
By default the statistics in the output data set
automatically inherit the analysis variable's format
and label. However, statistics computed for N, NMISS,
SUMWGT, USS, CSS, VAR, CV, T, PROBT, SKEWNESS, and
KURTOSIS do not inherit the analysis variable's format
because this format may be invalid.
so INHERIT is working as designed, even though I still
think the LABELs for those listed stats also should not
be inherited. In any event, ANALPROG was re-written to
use %VMXGSUM and to correctly label NRTIMES.
Thanks to Mark McCallum, EDS, USA.
Change 20.074 Support for multiple CICS Versions with Exclude added.
UTILEXCL The IMACEXCL created by UTILEXCL failed with syntax error
Apr 30, 2002 if APPLID had multiple dictionary records from different
releases of CICS. This change supports multiple releases
for the same APPLID, by creating a code block for each
APPLID and CICS version:
ELSE IF APPLID='CICSTNW1' AND SMFPSRVR=53 THEN DO; ...
ELSE IF APPLID='CICSTNW1' AND SMFPSRVR=62 THEN DO; ...
And IMACEXCL will print an ERROR message on the SAS log
(as it reads your SMF data), if it finds a new version
for a CICS APPLID that is already in your list of regions
with excluded fields. Thus to support two CICS Versions,
you only have to run the _BLDDICT with the new version's
dictionary records to create a new PDB.CICSDICT, combine
that with your old PDB.CICSDICT from the old version, and
run _BLDEXCL to create an IMACEXCL that is aware of both
CICS version's excluded variables.
Thanks to Raff Rushton, Kaiser Permanente, USA.
Change 20.073 Under ASCII only, a latent 180 syntax error was triggered
VMXGRMFI and corrected in the macro logic that failed to expand a
Apr 29, 2002 macro variable J due to a missing ampersand.
Thanks to John G. Talafous, Timken, USA.
Change 20.072 Support for TMON/CICS TCE 2.1 (INCOMPATIBLE). Landmark
EXMONPA (now Allen Services) completely restructured all records,
EXMONPI and even changed the version from numeric to character!
EXMONTF HWM/maximum values were removed from some datasets, some
EXMONTFF variables will have missing values. New fields were added
EXMONTJ to many existing datasets, and new records are supported.
EXMONTK Since every record and subtype was touched, MXG support
EXMONTKM for TCE was enhanced with all the MXG bells and whistles:
EXMONTKP duration variables are formatted TIME13.3, storage and
EXMONTN byte-containing variables are formatted MGBYTES, etc., to
EXMONTO both "print-pretty", and to document what data is stored
EXMONTOS in which of these hundreds of new variables.
IMACTMO2 The new PA/PI records capture IBM CICS Monitor Facility
VMACTMO2 data at the transaction and interval level, and the new
VMXGINIT TK Dispatcher Record provides CPU time for each CICS TCB.
Status: TA,TD,TI,TP,TR,TS, TX, and T2 records were all
Apr 28, 2002 changed, some new variables, some dropped.
May 1, 2002 TF was so changed that new MONITF/MONITFF datasets are
May 5, 2002 created for TF records with Release 2.1.
New PI,PA records create MONIPI/MONIPA with massive
numbers of new variables.
New TJ for Java, TN for Enqueues, and TO records for
Sockets create MONITJ, MONITN, MONITO and MONITOS, for
a total of 11 new datasets and hundreds of variables.
PTF TCE3400-21 changes were added May 5.
This complete rewrite took three full days to write and
validate (thanks to a full suite of test records from
Landmark, and nearly accurate documentation); over 3000
lines of code were added by this change.
Thanks to Martin Jensen, JyskeBank, DENMARK.
Change 20.071 The JCL example (Testing MXG under SAS Version 8) still
JCLTEST8 MXGSAS instead of MXGSASV8 as its JCL procedure name.
Apr 28, 2002 Also, the example suggests REGION=80M for installations
that restrict the use of REGION=0M.
Thanks to Donald J. Likens, AON, USA.
Change 20.070 New IBM Product, NPM/IP user SMF record, is supported.
EXNPIP01 Two datasets are created from the two subtypes:
EXNPIP02 DDDDDD Dataset Description
IMACAAAA NPIP01 NPMIP01 Performance Record - each observation
IMACNPIP measures the round trip response time
TYPENPIP for one of four packet sizes to a
TYPSNPIP specific IP address.
VMACNPIP NPIP02 NPMIP02 Workload Record - accumulated bytes
VMXGINIT from an application to an ip address.
Apr 28, 2002 Records must be deaccumulated (use
TYPSNPIP or _SNPIP in your EXPDBOUT)
to create interval duration and bytes
sent/received during each interval.
To minimize the size of PDB.NPMIP02,
observations are created only for
intervals with non-zero bytes.
Many duplicate SMF records were
found, but MXG logic deletes them;
IBM will be contacted to fix or to
explain their duplicate records:
Subtype 2 records in SMF: 29762
duplicate records removed: (14407)
unique subtype 2 records: 15265
MXG obs in PDB.NPMIP02: 6963
Updated 2Jan03: APAR OW56033 reports duplicate records
were cut by the "AESTNETS" task's AEST044 program, and
provides the PTF to correct that error.
Thanks to Sue Kemper, Universal Music Group, USA.
Change 20.069 Support for APARs OW52227 and OW51848 for z/OS 1.2, adds:
VMAC7072 -New variables to TYPE72GO dataset (type 72 subtype 3):
Apr 26, 2002 New wait state sample counts (SSL Thread, Regular Thread,
Registration to Work Table, R723RWST/RWRT/RWWR), and new
"Active Application State" sample count, R723RAPP, that
indicates there is a program executing on behalf of a
work request, from the perspective of the WLM (this does
not mean that the program is active from the BCP's
perspective), so RMF reports can distinguish between
active subsystem and active application; from APAR text:
Before this APAR, state samples were reported as percent
of response time, calculated when a transaction ends,
which could cause values over 100% when samples for long
running transactions were included that did not complete
in the RMF interval. With OW52227, the problem is solved
by showing the single states as percentages of total
state samples, instead as percentages of response time.
This eliminates percentages over 100% in the BREAKDOWN
section. Thus the RESPONSE TIME BREAKDOWN is replaced
by a STATE SAMPLE BREAKDOWN, and the STATE SWITCHED TIME
is replaced by a STATE SWITCHED SAMPL(%) breakdown. Only
the TOTAL column will be kept as percentage of response
time, which is the current view; however, the field name
will be changed to RESP TIME(%).
The APAR text contains a numeric example of the change
in the values printed with and without OW52227.
The APAR also states that the RMF III SYSWKM Report has
changed the meaning of ACT (Active State); in addition
to the time spent in an active subsystem state, it also
contains the time spent in an active application state,
if that information is provided by the subsystem, for
example, WebSphere.
The APARs also now count delays for service classes with
goal types other than response time goals, and count
delays for multi-period service AND report classes.
This MXG change adds the new variables to TYPE72GO data.
A later change to ANALRMFR will detect OW52227 and will
use R723RAPP to match IBM calculations, when test data
is available for validation.
The associated OW51848 added the new function that allows
Performance Block (PB) state reporting for enclaves. Now,
report-only PBs can be associated with an enclave or an
address space in a service class with multiple periods.
(Previously, a PB could only be associated with an ASID
that was in a Service Class with a response time goal.)
-The APAR documents that the new delay and sample counts
are also added to RMF III VSAM ERBRCDG3 segment, but that
segment is not yet supported in MXG's VMACRMFV, because
no one has yet sent sample data records to be decoded.
Change 20.068 Significant user contribution enhances the MXG RMF III
ASMRMFV support. This change is the last part of Change 20.033.
VMACRMFV -ASMRMFV, the program that reads the RMF III (compressed)
Apr 26, 2002 VSAM file to create the RMFBSAM flat file that is then
read with MXG's TYPERMFV, originally had hardcoded LRECL
of 800 bytes, but IBM now writes 1500 byte records that
were truncated by the original program. This revision
sets DCB to RECFM=VBS,LRECL=32756,BLKSIZE=0, which will
support any future record length. VBS is used (instead
of VB) so that half-track DASD will be allocated and DASD
space won't be wasted by the output flat file.
-VMACRMFV was enhanced to create variables SHIFT, SYSTEM
and SYSPLEX in all datasets, added SSHTIBEG/SSHTIEND to
datasets that did not contain them, corrected four vars
(GEIESPMB/SPME/SMRB/SMRE) to be input with RB instead of
with informat PIB, creates PCTLOGBY and PCTCPUBY vars as
percents of logical and physical CPU busy, added labels,
and corrected typos and spelling errors! Whew!
Thanks to Jerry Urbaniak, Acxiom CDC, USA.
Change 20.067 z/VM datasets VXBYUSR, VXSUMUSR, VXBYCPU, VXSUMCPU, and
TYPSVMXA VXBYTIME were not copied into the PDB library when the
Apr 26, 2002 TYPSVMXA member was used to SORT all datasets into the
PDB library. These summary datasets are built from the
other datasets, so they are now copied with a PROC COPY
that was added at the end of TYPSVMXA.
Thanks to Pat Curren, SuperValu Inc, USA.
Change 20.066 New datasets TYP120JC and TYP120JI were created in the
VMAC120 //WORK file, but their _ST120JC/_ST120JI Sort macros were
Apr 26, 2002 not invoked inside _S120, so they were not sorted into
the PDB library by TYPS120 nor when _S120 was invoked.
Thanks to Pat Curren, SuperValu Inc, USA.
Change 20.065 Support for BMC MAINVIEW FOR CICS 5.4 CMRDETL file, which
VMACMVCI was completely and incompatibly changed. Release 5.5 only
Apr 24, 2002 added two fields in reserved fields; both are supported.
Apr 30, 2002
Thanks to Ermanno Bertolotti, INTESABCI, ITALY.
Change 20.064 The example to send email from an MVS SAS job should have
EMAIL spelled the option EMAILSYST as EMAILSYS, without that
Apr 15, 2002 "T".
Thanks to James A. Monahan, National Grid USA, USA.
Change 20.063 Boole/BMC CIMS/IMF CIMSTRAN dataset variables CTCKPTNTS,
VMACCIMS MAXLOCKS, and TOTLOCKS were input but not kept; now they
Apr 15, 2002 are kept in dataset CIMSTRAN.
Thanks to Siegfried Trantes, IDG mbH, GERMANY.
Change 20.062 STARTIME in TNG datasets was an hour earlier than actual.
VMACTNG I originally assumed the "hour" was the hour of end of
Apr 12, 2002 the data, and used STARTHR-1 to set the ORIGTIME to the
previous hour. But the hour really is the START hour of
the data, so the two STARTHR-1 were changed to STARTHR.
Thanks to Erling Andersen, SMT Data A/S, DENMARK.
=======Changes thru 20.061 were in MXG 20.01 dated Apr 11, 2002=========
Change 20.061 UTILEXCL recognized and reported "UNKNOWN FIELD" but did
IMACICD1 not build correct logic in IMACEXCL to skip over the data
IMACICDA so the CICSTRAN dataset was invalid, strange dates, etc.,
UTILEXCL if that "POTENTIALLY SERIOUS ERROR" message was printed
VMAC110 when you executed UTILEXCL. The particular unknown field
Apr 11, 2002 CANPROD1 perhaps is the last CICS field to be supported.
This change corrects UTILEXCL to properly skip over any
future unknown CICS segments, and supports the CANPROD1
segment, creating the 4-byte variable CANPROD1.
Candle describes CANPROD1 as "Internal, used to provide
statistics for VSAM, DL/1, IDMS, ADABAS, SUPRA, and
DATACOM. Used to provide Application Trace Statistics.
Thanks to Hailin Wu, Cover-All, CANADA.
Change 20.060 SAS V6 Only, Warning. Labels added in Change 20.05x were
VMXG70PR longer than V6 limit of 40 bytes; non-fatal.
Apr 11, 2002
Thanks to Freddie Arie, TXU, USA.
Change 20.059 With UTILEXCL created IMACEXCL, STRTTIME/ENDTIME were not
UTILEXCL converted to Local Time if your GMT offset was non-zero,
Apr 10, 2002 and variable CPUTM was not populated. Both are corrected.
Thanks to Raff Rushton, Kaiser Permanente, USA.
=======Changes thru 20.058 were in MXG 20.01 dated Apr 9, 2002=========
Change 20.058 DB2 report PMSQL02 had missing TCB time values for two
ANALDB2R trace events (62058 and 59058) due to carry-down typos.
Apr 9, 2002 The CPU=S058UCPU-S066UCPU; is now CPU=S058UCPU-S062UCPU;
and CPU=S058UCPU-S066UCPU; is now CPU=S058UCPU-S059UCPU;
for those trace events.
Thanks to Frank d'Hoine, Nationale Bank van Belgie, BELGIUM.
Change 20.057 -The daily NT PDBs are no longer all deleted when the WEEK
BLDNTPDB NT PDB is built, in keeping with the MVS BUILDPDB design,
Apr 9, 2002 so that you can read FRI's PDB on TUE without reading the
entire past-week's WEEKLY PDB.
-The RERUN parameter now works, but is subject to this
exposure that requires intelligent manual intervention:
If RERUN is used and it happens to be the day of the
week that is specified for running of the weekly or
the monthly, those programs will automatically be run.
Turn off the weekly and/or monthly options with RERUN,
and then evaluate what restores may be needed before
you can rerun to build weekly or monthly.
Thanks to Terry Heim, Ecolab, USA.
Change 20.056 Enhancements for MSU-based Capacity Measurement for IRD
VMAC7072 (z/OS Intelligent Resource Director, see Change 20.046):
VMXG70PR -Variable SMF70BDA,SMF70CSF,SMF70ESF, and SMF70MSU are now
Apr 8, 2002 corrected in dataset PDB.TYPE70PR; they were zero because
I used early doc and missed document revisions at GA.
-Variable SMF70CPA is kept into TYPE70PR from the TYPE70
segment, so the MSU can be calculated later in ASUM70PR
and ASUMCEC - see Change 20.046 equation.
-Both PDB.ASUM70PR and PDB.ASUMCEC now contain six new
variables for each LPAR:
LPnBDA ='LPAR n*AVERAGE*LOGICAL*CPUS*SMF70BDA
LPnMSU ='LPAR n*INTERVAL*MSU*COUNT
LPnMSUHR='LPAR n*INTERVAL*MSU*AS HOURLY*RATE
LPnMSU70='LPAR n*MSU*DEFINED*CAPACITY*SMF70MSU
LPnONT ='LPAR n*LPAR*ONLINE*DURATION*SMF70ONT
LPnWST ='LPAR n*LPAR*WAIT STATE*DURATION*SMF70WST
and three new variables for totals:
MSULICEN='SUM OF*LICENSED*MSU CAPACITY*OF ALL LPARS'
MSUTOTAL='TOTAL*MSU*DELIVERED*TO ALL LPARS'
MSUPERHR='HOURLY*MSU RATE*DELIVERED*TO ALL LPARS'
-SMF70BDA is usually equal to LPARCPUS, and sometimes is
slightly less, showing that IRD seems to be working,
but it does not seem to be useful to calculate any of
the LPAR utilizations.
-SMF70ONT (LPAR Online Time) and SMF70WST (LPAR Wait State
Time) are summed for each LPAR in ASUM70PR/ASUMCEC, but
are also still not understood for these 5 LPAR's data:
LPAR LPnDUR LPnUPDTM LPnBDA LPnONT LPnWST
1 2:15:00 0:19:06 9 2:15:00 0:51:50
3 2:15:00 0:12:02 9 2:15:00 1:07:33
5 0:15:00 0:00:00 1 0:15:00 0:00:00
7 2:15:00 0:08:23 8.37 2:05:36 1:32:51
14 2:15:00 0:04:12 8.40 2:06:07 1:43:43
Total+Phys: 0:46:24 ==> 34.3% busy, 9 engines, 15 min.
-I note that the only place where IBM records their 4-hour
rolling average MSU is in the TYPE70 data for each MVS in
variable SMF70LAC, but IBM does not calculate that value
in the PR/SM data for each LPAR. The MXG calculation of
the rolling average MSU4HRAV is in the PDB.RMFINTRV data.
Change 20.055 The Group Buffer Pool GBPxxxxx variables in DB2ACCTG (for
VMACDB2 each pool) and their sum in DB2ACCT have never been right
Apr 5, 2002 if more than one GBP was used; MXG repetitively input the
first segment. Adding OFFGBP=OFFGBP+LENGBP; and removing
the unused SKIP logic corrects the error.
Thanks to Warwick Robinson, National Westminister Bank, plc, ENGLAND.
Change 20.054 -The optional CICS User segment is now the last segment in
IMACICDA the default order in member IMACICDA, as was intended and
IMACICMR as is documented. If you have your own IMACICDA, it will
UTILEXCL still input the CICS segments in your chosen order. If
VMAC110 you use member UTILEXCL to create IMACEXCL, IMACICDA is
Apr 4, 2002 not used, so this has no impact there.
-The optional CICS CMRDATA segment from Mainview is now
supported in member IMACICMR, and UTILEXCL now knows of
that member for that optional data for its notes to you.
-VMAC110 was updated with the optional CMRDATA variables.
Thanks to Helgund Linck, BASF-IT-Services, GERMANY.
Change 20.053 Mitchem ACC/SRS support corrections. The offset was INPUT
VMACACC into variable SRHPHL, but references spelled it SHRPHL,
Apr 4, 2002 so ASHxxxxx variables were not INPUT. MSGLENGTH was 3
bytes short when SRHPHL was present. And so that this
member will execute correctly under ASCII SAS, INPUT()
and TRANSLATE() functions were added (because
EBCDIC-containing variable MESSAGE must be INPUT with
$VARYING informat).
Thanks to Heinz-Bernd Leifeld, Provinzial Rheinland Versich., GERMANY
Thanks to Engelbert Smets, Provinzial Rheinland Versicherung, GERMANY
Change 20.052 INSTANCE was blank if a 3-HDR records contained (*) for
VMACTNG the length of the instance field, indicating there was no
Apr 4, 2002 new instance value. MXG incorrectly blanked the value in
Apr 5, 2002 retained variable INSTANCE. Now, INSTANCE will be from
the preceding 2-HDR record, unless the 3-HDR has a real
length for the INSTANCE. Noted in NT014, but pervasive.
Thanks to Erling Andersen, SMT Data A/S, DENMARK.
Change 20.051 Documentation. When you use UTILEXCL to create IMACEXCL
UTILEXCL for CICSTRAN, old variables that no longer exist in CICS
Apr 3, 2002 are no longer kept; these variables will not exist:
Pre CICS/ESA: FCOTHCN MAXTASK SHRTSTOR OPERATOR PAGEINS
CICS 3.3 only: PC24UHWM PC31UHWM TCSTG TCLASS
Thanks to Helgund Linck, BASF-IT-Services, GERMANY.
Change 20.050 MXG incorrectly decoded the second TYPE78IO IOP segment
VMAC78 if z/OS 1.2 extended data was present, causing very large
Apr 3, 2002 values for R783ICPB/IDBP/ICUB/IDVB when &RB.8 input was
Apr 25, 2002 mis-aligned. Those values caused PROC MEANS to fail with
Mar 25, 2003 a "DOMAIN ERROR", because SAS does not validate data when
the "RB" (floating point) informat is used.
Mar 25 2003: This change may increase the number of obs
created in dataset TYPE78IO, and may increase NRIOPREQ,
the SIO count, and that variable is summed and renamed in
RMFINTRV as SIO73CNT.
Thanks to Diane Eppestine, Southwestern Bell, USA.
Thanks to Jeff Rash, American Honda, USA.
Change 20.049 TYPE89 dataset variable MULCURD was wrong when MULCURT=2
VMAC89 or MULCURT=3. For MULCURT=2 the INPUT is &PIB.8. and for
Apr 3, 2002 MULCURT=3 the INPUT is &RB.8, but MXG had them reversed.
The specific error with MULCURT=2 and incorrect informat
of &RB.8. used for a data value of '00.....01'x resulted
in a MULCURD value of -1.606E60, and that value caused a
SAS DOMAIN ERROR when PROC MEANS summed that dataset.
Thanks to Glenn Harper, Memorial Hermann Hospital System, USA.
Change 20.048 The KEEP= list spelled SMF4VLS instead of SMF94VLS, so
VMAC94 that variable was not kept in TYPE94 dataset.
Apr 2, 2002
Thanks to Bruce Widlund, Merrill Consultants, USA.
Change 20.047 DAILYDSN still wrote to the //PDB libref, after Change
DAILYDSN 20.020. Change OUTDATA=&PDBMXG..DATASETS,
Apr 2, 2002 to OUTDATA=DATASETS.DATASETS,
Thanks to Tien Truong, Citicorp Asia Pacific, SINGAPORE.
=======Changes thru 20.046 were in MXG 20.01 dated Apr 1, 2002=========
Change 20.046 CPU Busy Percentages are very different if WLM's IRD is
VMXGRMFI in control of allocating CPUs to LPARs. Previously the
Mar 31, 2002 PCTCPUBY (TYPE70) and PCTLnBY (ASUM70PR/ASUMCEC) measured
the percentage of the fixed capacity (NRCPUS*DURATM) that
you gave to an LPAR, i.e., that you gave to the system
running in that LPAR, so 100% meant the MVS system was
using all of the CPUs you gave that LPAR.
Now, WLM's Intelligent Resource Director will dynamically
change the number of engines given to an LPAR, so there
is no fixed capacity to measure an LPAR's work against:
variables NRCPUS/LPARCPUS/LPnNRPRC now contain the count
of engines that were used (even briefly) in an interval.
Fortunately, though, when IRD is in control, the PCTCPUBY
(TYPE70 and RMFINTRV), and the PCTLnBY (ASUM70PR/ASUMCEC)
calculations are valid; they have just changed in meaning
and now measure the percentage of the hardware platform
(the CPC, all PARTNCPUs) that was used by this MVS system
or this LPAR. If you had a 2-engine LPAR running at 100%
of those two engines, PCTCPUBY=100% in that MVS's system.
But if that 2-engine LPAR is now run under IRD on a z900
10-way, the PCTCPUBY will be measured as 20%, since only
the fixed capacity of the total CPC platform can be used
now to measure "percent CPU busy".
So what to do? For starters, while we all learn this
new playground, MSUINTRV, the total MSU consumed by each
LPAR during each interval, can be summed for each hour
and compared with SMF70WLA, the (hourly) Defined Capacity
that you chose for your Licensed Software MSU capacity.
You can also convert the MSUINTRV value for intervals
less than an hour to an hourly rate with the ratio:
MSUPERHR= MSUINTRV*3600/DURATM.
But what capacity percentage makes sense anyhow. On a
2064-1C9 (MSU hardware capacity of 305/hour), you could
assign an LPAR to a Defined Capacity of 50 MSU, but you
could easily consume all 302 MSU in that LPAR for an
hour (only impacting Software costs!); what percentage
should be calculated: 302/50= 600% of capacity?
You can detect that WLM's IRD is in control in the
TYPE70PR dataset, which will have LPARWLMG='Y' (SMF70WLM
bit in field SMF70PFG), but only in observations with
SMF70CIN='CP'; the LPARNAME='PHYSICAL' observations have
LPARWLMG='N',and SMF70CIN=' '.
The number of LCPUADDRs in TYPE70PR varies for the same
LPAR; some intervals had 9 LCPUADDRs of 0-8, and some
some intervals had only eight LCPUADDRS of 0-7.
Unless you change the Defined Capacity for an LPAR, the
hourly MSU Capacity of each LPAR, SMF70WLA, is constant,
in spite of the change in the actual count of LCPUs.
The CPC capacity of the 2064-1C9 is 302 MSU (9 CPUs with
SMF70CPA=9329.45), but the sum of SMF70WLA across all of
the LPARs in each CPC is only 185 MSU:
CPCSER xxx3: 65 40 60 15 5 (sum=185)
CPCSER xxx2: 65 55 50 15 (sum=185).
So this site is a perfect example of the real value of
IRD and the IBM License Manager: IBM has installed a 302
MSU box, but the customer is only paying for the 185 MSU
that they currently need for all their LPARs.
Note that even though the CPC has 11 engines, because two
are ICF engines, the CPUMODEL='2064-1C9', showing 9 CPUs.
The change was to revise the calculation of RMFINTRV's
MSUINTRV value, to use the CPUACTTM*SMF70CPA/1E6 rather
than the original that was based on LPAR percent busy.
Expect additional enhancements as we learn more, and
as we decide how to measure this changing landscape.
NOTE: Change 21.170 re-defines NRCPUS and recalculates
PCTCPUBY using the new SMF70ONT online-time measure.
Thanks to Raimo Korhonen, CompMeas Consulting Oy, FINLAND.
Change 20.045 MXG 19.04-19.19. PCTDLxxx variables in TYPE72GO divided
VMAC7072 by variable VALDSAMP can be slightly different than the
Mar 29, 2002 RMF report values; the calculation of the PCTDLxxx and
Apr 5, 2002 PCTUSxxx variables is now based on R723CTSA instead of
on VALDSAMP to match the RMF system level reports, and
both VALDSAMP and R723CTSA are kept in TYPE72GO so that
sysplex-wide velocity can be calculated.
Thanks to John A. Doan, Total System Services, USA.
Change 20.044 If two products write the same user SMF record number,
VMACSMF you can still tailor MXG to read both records, although
Mar 29, 2002 it would be wise to use unique SMF record numbers! The
exact syntax depends on finding a "marker" in one of the
records that can be used to differentiate between the two
products. In this case, both CA's NETSPY and Sterling's
NDM wrote ID=132 SMF records, and the NETSPY Version of
"R5.3" could be used as the "marker", and this example
assumes the NDM record ID will be changed to ID=133. The
example uses MACFILE and MACKEEP macro variables in the
job's input stream, and will read the existing (old) 132s
and the new 133s when they show up in your SMF file:
%LET MACKEEP=
MACRO _NSPYID 132 %
MACRO _IDNDM 133 %
;
%LET MACFILE=
%QUOTE(
IF ID=132 AND LENGTH GE 50 THEN DO;
INPUT @39+OFFSMF MARKER $EBCDIC4. @;
IF MARKER NE 'R5.3' THEN ID=133;
END;
);
%INCLUDE SOURCLIB(BUILDPDB);
(or if you only wanted one or the other, you would
%INCLUDE the TYPSNDM or TYPSNSPY record instead of the
example's BUILDPDB member).
P.S. Yes, the SMF Record ID macro for NETSPY is spelled
backwards. It should be _IDNSPY, like almost every other
_IDxxxx macro names, but it is one of the inconsistent
names. The exact name of the ID macro for each SMF data
record is in the IMACxxxx member for that product, in the
IMACNSPY and IMACNDM members for this example.
Thanks to Aldo Raimondo, Global Value Services, Italy.
Change 20.043 Support for z800 2066 CPUs running OS/390 R2.8, R2.10.
FORMATS These records without the type 70 SMF70WLA field do not
VMXGRMFI have their MSU capacity in their SMF 70 record, causing
Mar 29, 2002 MXG messages "CPU NOT IN TABLE CPUTYPE=2066", causing the
MSU-related variables to be missing in RMFINTRV dataset.
Some non-IBM machines are in the table, but we don't yet
have #CPs nor their SU_SEC value, but if you get one, the
SU_SEC is in the TYPE72/TYPE72GO dataset for the update.
Thanks to Alan Sherkow, I/S Management Strategies, USA.
Thanks to Winnie Pang, Hawaiian Medical Service Association, USA.
Change 20.042 Extraneous last byte '1A'x hex value in ASCII IMACPTF
IMACPTF was translated to '3F'x and could cause SAS 180 syntax
Mar 29, 2002 error. Deleted that byte.
Thanks to John R. MacDonald, Public Works and General Svcs, CANADA.
Change 20.041 Change 19.248 removed ID statement from member ASUMNTIN,
TRNDNTIN but should also have removed the ID statement from the
Mar 28, 2002 TRNDNTIN member.
Thanks to Terry Heim, ECOLAB, USA.
Change 20.040 -UTILEXCL incorrectly generated IF SEGLEFT GE CMODLENG in
IMACICOC the IMACEXCL it created; "CMODLENG" should have been the
IMACPTF expected segment length value, not the variable name.
UTILEXCL -If you enabled IMACICOC, and did NOT have _QOC0109 turned
Mar 25, 2002 on in IMACPTF, the IMACEXCL INPUT statement was out of
Mar 30, 2002 alignment and CICSTRAN was not valid. Since all Omegamon
records now have that old APAR enabled, I have removed it
from the IMACICOC member that was the only place it was
used, and changed the default value in IMACPTF from 0 to
1, just for compatibility.
Thanks to Raff Rushton, Kaiser Permanente, USA.
Change 20.039 The default ASUMDB2A member will fail if variables are
ASUMDB2A DROPed from the input DB2ACCT dataset, but with minor
VMXGSUM tailoring, ASUMDB2A will tolerate dropped variables.
Mar 24, 2002 ASUMDB2A invokes the %VMXGSUM macro, and in ASUMDB2A,
MXG specifies KEEPALL=YES for performance reasons. But
if you remove variables from the input dataset, you need
create a tailored ASUMDB2A member, with these changes to
the %VMXGSUM invocation in that member:
- Change the KEEPALL=YES to KEEPALL=NO in your ASUMDB2A.
- Run the ASUMDB2A against your modified data, and look
for any uninitialized variable messages on the log,
where the view WORK.MXGSUM1.VIEW was used:
NOTE: Variable QTXAPREC is uninitialized.
NOTE: Variable QTXAILMT is uninitialized.
NOTE: Variable QTXANRUN is uninitialized.
NOTE: Variable QWACRINV is uninitialized.
NOTE: Variable THREADTY is uninitialized.
NOTE: Variable DB2PARTY is uninitialized.
NOTE: View WORK.MXGSUM1.VIEW used:
- Those variables are used in the INCODE logic, but are
not in any SUM, MIN, etc. request, so they were not
kept by KEEPALL=NO, so you must add an argument to the
%VMXGSUM invocation to cause them to be kept for the
input phase, with this syntax:
KEEPIN= QTXAPREC QTXAILMT QTXANRUN QWACRINV
THREADTY DB2PARTY,
You cannot (safely) drop the variables in the KEEPIN=
argument, nor can you drop the variables in the SUMBY=
argument, as they are all required for the logic of the
summarization.
Thanks to Diane Eppestine, Southwestern Bell, USA.
Change 20.038 ASUMUOWT builds the PDB.ASUMUOW dataset, using MONITASK
ASUMUOWT from Landmark's TMON/CICS, instead of the CICSTRAN data
VMXGUOW from IBM SMF 110s. Unlike ASUMUOW, the default in the
Mar 23, 2002 ASUMUOWT program creates observations; you only need to
%INCLUDE SOURLCIB(ASUMUOWT); with the correct DDnames:
//DB2ACCT and //MONITASK, and with //ASUMUOW for output,
as shown in the example in the ASUMUOWT member.
The MONITASK values are stored in CICSTRAN variables, but
I could not find 43 CICSTRAN variables in the MONITASK
dataset, so I have just sent the list of those missed
fields to Landmark, and will update this note is any of
them are identified. (All are set missing and listed in
the _SUOWTMO macro in VMXGUOW.)
Thanks to Jacky Kwoka, ATOS Origin, FRANCE.
Change 20.037 The calculation of VELOCPU in TYPE72GO was incorrectly
VMAC7072 calculated when I/O Priority Management is enabled.
Mar 23, 2002 VELOCPU is the velocity calculated if only CPU is enabled
but with IOPM, VELOCPU included I/O effects. Now, the
VELOCPU is recalculated to measure the CPU-only velocity.
Of coure, variable VELOCITY has always been the correct
velocity value - variables VELOCPU and VELOCIOD are only
"what if" calculations of possible velocity values.
Thanks to Pat A. Perreca, Bear Stearns, USA.
Change 20.036 CICS/TS Statistics dataset CICXQ3 (Shared ts queue server
VMAC110 storage, STID=123) fields have been mis-documented in all
Mar 23, 2002 releases, TS 1.3 thru TS 2.2. The Data Areas lists them
May 14, 2002 as RQG(Gets) ,RQF(Fails) ,RQS(Frees) ,RQC(Compress), but
SMF data shows RQG and RQF are equal, and RQS and RQC are
both zero, so I assume that RQF contains Frees instead of
Failures, and so RQS must contain Storage Failures, and
not Frees. The S3ANYRQF/RQS and S3LOWRQF/RQS variable's
labels were corrected to match the observed data values.
May 14: IBM confirms my assumption, and Don found and IBM
confirmed the same problem exists in the Coupling
Facility Data Tables S9ANYxxx and S9LOWxxx) and the Named
Counter Sequence Number Server Statistics (S5ANYxxx and
S5LOWxxx); those variable's LABELs were also corrected.
Thanks to Don Deese, (CPExpert), Computer Management Sciences, USA.
Change 20.035 New %macro that will get the DSNAME of an allocated SAS
VGETDSN Data Library, and if that DSNAME is an MVS Generation
Mar 22, 2002 Data Group (GDG), %VGETDSN will allocate the next new
member (next "Go0ooVoo") dynamically, specifying its UNIT
SPACE, DISP, and ENGINE in the %VGETDSN arguments. And
You can specify JOB= to cause the dynamic creation of the
next GDG to only occur if that Job name invoked %VMXGDSN.
Thanks to Chuck Hopf, MBNA, USA.
Change 20.034 Cosmetic - variable labels. The Dispatcher Variables
VMAC110 DSGSYSW,DSnSYSW, documented as 'Operating System Waits',
Mar 22, 2002 were re-described by IBM as 'Exits from Partition' when
IBM moved the Dispatcher Statistics to STID=60 and added
twelfth and thirteenth TCBs to CICS, and some of those
variables labels were changed. Since the CICS/TS 2.2
Performance Guide still refers to the DSnSYSW fields as
Operating System Waits, the newer labels were removed and
all labels are as before.
Thanks to Gerhard Hellriegel, ???, GERMANY.
Change 20.033 Support for RMF III (RMF VSAM) for Enclave Table ENCG3.
VMACRMFV Only ENCG3 support was actually added by 20.033; the rest
Mar 22, 2002 of the original change was implemented in Change 20.069.
Thanks to Betty Wong, Bank of America, USA.
Change 20.032 Domino R5.04+ DOMBTIME/DOMETIME variables could be wrong,
VMAC108 because the GMT offset field was input as &IB.4. when it
Mar 18, 2002 should have been input as $CHAR4. The actual bad values
depended on your actual GMT offset, but were in the year
2020 if your offset was zero.
Thanks to Bob Furlong, JPM Chase UK, ENGLAND.
Change 20.031 Example Trend member had PDB.DB2STATS syntax, instead of
ANALDB2R WEEK.DB2STATS syntax, but is now correctly using WEEK. as
TRNDDB2S input. Additional typos were corrected
Mar 18, 2002 In TRNDDB2S: QJSTWT should have been QJSTWTB.
Mar 30, 2002 In ANALDB2R: QXSETCR should have been QXSETCRL.
Thanks to Scottt Snyder, First Data, USA.
Thanks to Diane Eppestine, Southwestern Bell, USA.
Change 20.030 Divide by Zero messages (but no error) when TOTBECPP, the
VMACICE total back end capacity, production partition, was zero.
Mar 14, 2002 The calculation of NCL is now protected for zero divide.
Thanks to David Ehresman, University of Louisville, USA.
Change 20.029 A typo changed all lower case "F" values to a blank in
VMAC120 WebSphere DBCS character values (SM120JA8='De ault').
Mar 14, 2002 The many TRANSLATE() statements had '86'x, but should be
SM120xxx=TRANSLATE(SM120xxx,' ','80'X);
which is needed because of the $VARYING and DBCS data.
Thanks to Bill Feeney, Hennepin County, USA.
Change 20.028 -Support for Windows 2000 TNG. PLATFORM name tests for NT
VMACTNG data look for both NTS400I and (new) NTS500I for Win 2K.
Mar 12, 2002 The same NTnnn datasets are created from either version.
Mar 18, 2002 -Both old and new TNG NT records caused ABENDS, because
Mar 25, 2002 SAS does not properly input numbers-with-leading-blanks
Apr 3, 2002 when you mix LIST and non-LIST input modes, and you have
INFILE xxx DLM='' specified. The MXG statement:
INPUT VALUE FLAG $1. @; INFORMAT VALUE 20.;
stored zero in VALUE when its input column was blank.
And BZ20. can not be used - SAS documents that you must
change DLM='' to "something" for the BZ20 informat to
treat blanks as zeros, but MXG logic requires that the
INFILE TNG DLM='' be specified so that it can parse all
of the other data fields in the records.
So the INPUT VALUE FLAG $1. @; logic was revised and is
first input as a variable length string, and then blanks
are detected and skipped before the numeric INPUT.
-Variable DOMAIN kept length increased from $20 to $30 to
keep longer domain names.
-46 character Instance Name of Network Interface value of
'Compaq Ethernet_Fast Ethernet Adapter_Module#1' exceeded
MXG's default of 40, requiring revision to the INSTANCE
handling logic to handle 64 character instance name.
(This last part was only in the Apr 3 dated member).
Thanks to Erling Andersen, SMT Data A/S, DENMARK.
Change 20.027 NDM PNODE and SNODE Account fields are now input and kept
VMACNDM in the NDMCT and NDMRT datasets.
Mar 8, 2002
Thanks to Betra Reeves, (i)Structure, Inc.
Thanks to John Rivera, (i)Structure, Inc.
Change 20.026 The Availability Report example would terminate with no
ANALAVAI output & no diagnostics if no applications were defined
Mar 8, 2002 or failed if the DATASET options was used to change
the name of the output dataset.
Change 20.025 Worked, but only with a KEEPER or DROPER argument used;
VMXG2DTE without both, either invalid syntax error or no SET
Mar 6, 2002 statement was generated.
Change 20.024 -If UNKNOWN FIELD messages were printed on the log when
UTILEXCL UTILEXCL was executed, the created IMACEXCL had extra
VMXGUOW END; statement for each unknown field.
Mar 6, 2002 -MXG expected both ABCODE fields 113 and 114 so it input 8
Mar 7, 2002 bytes into ABCODE; now UTILEXCL is enhanced to create the
Mar 8, 2002 8-byte ABCODE variable as before, from either or both of
the abend code fields, when one or both are found.
-The "ASUMUOW-CRITICAL-ALERT" tests in both UTILEXCL and
added in VMXGUOW did not test for variable "UOWID", so it
was always reported as not being in your CICSTRAN data.
-Variables UOWTIME and UOWIDCHR were not kept when UOWID
was found, causing spurious "ASUMUOW-CRITICAL-ALERT" that
listed those two variables, but not UOWID, as missing.
Thanks to Hailin Wu, Cover-ALL, CANADA.
Thanks to Chris Voris, QRS Corporation, USA.
Thanks to MP Welch, SPRINT, USA.
Change 20.023 ANALDB2R failed if your report request SORT list had only
ANALDB2R one variable. Line 2978 was changed
Mar 6, 2002 from /@1 &SORT2 $CHAR16.
to /@1 ' ' to correct the error.
Thanks to Brad Brewer, Humana Inc, USA.
Change 20.022 The PDBOUT parameter did not work in ANAL94, but now it
ANAL94 does.
Mar 5, 2002
Change 20.021 TYPEIMSA (19.19 only) fails with 180 syntax error; the
TYPEIMSA two statements %%VMXGTIME(... should have only one
Mar 5, 2002 percent sign %VMXGTIME(... in both statements.
Thanks to Yves Terweduwe, CIPAL, BELGIUM.
Change 20.020 Change 19.230 sent the four DCOLLECT datasets to the PDB
DAILYDSN DDname instead of the DATASETS because the 4 lines with
Mar 4, 2002 MACRO _PDCOxxx should have been spelled MACRO _LDCOxxx.
Mar 22, 2002 And the correct SAS dataset name should be:
MACRO _WDCOVOL DCOLVOLS %
MXG 19.19 incorrectly had DCOLDVOL instead of DCOLVOLS.
Thanks to John Muir, Illinois State University, USA.
Thanks to Diane Eppestine, Southwestern Bell, USA.
Change 20.019 SAS Version 8.2 under Windows Professional Service Pack 2
SASV8.CFG fails if there is a directory named "user" under either
VMXGINIT the SAS root, or (in this specific case), under \WINDOWS
Mar 4, 2002 under \SYSTEM32. This error was first reported for unix
Mar 18, 2002 systems under SN-001262 but was reportedly fixed in V8.
That note gave this unix fix: add -user work in your
SASV8.CFG member, which also fixed the error on Windows.
This error surfaces as a DATA SET NOT FOUND when MXG
tries to delete a WORK.xxxxxxxx dataset, but the SAS log
shows the data was written instead to USER.xxxxxxxx
instead. Under MVS, we found the existence of //USER in
the JCL also caused an error, so VMXGINIT was revised to
detect a user option value problem, to change it to work,
to report what we found on the SAS log, and to keep on
truckin' without an error. SAS Usage Note ZZ-yyyy will
document these discoveries.
Thanks to Mark Darvodelsky, Royal SunAlliance Australia, AUSTRALIA.
Change 20.018 HMF Subtypes 29, 30, and 31 variable HMFHDNOD is actually
VMACHMF an IP Address in those subtypes, so new HMFIPADR variable
Mar 1, 2002 is created to decode and display the n.n.n.n ipaddress.
Thanks to Perry Lim, Union Bank of California, USA.
Change 20.017 Using OPTIONS OBS=0 can be useful, but can cause errors.
VMXGSUM You can use OBS=0 to syntax-test your programs, and it is
VMXGRMFI the correct way to create a 'zero-obs' SAS dataset or an
Feb 28, 2002 'zero-obs' SAS data library with multiple SAS datasets,
so you can test subsequent references to datasets and to
variables, and OBS=0 and PROC COPY is the recommended way
to initialize a SAS data library with all datasets, etc.
But: when OPTIONS OBS=0 is used with summary programs
that use %macros, especially %VMXGSUM, it can cause error
messages, because macro variables are not created if the
SYMPUT/SYMGET statements are after SET statements that
don't get executed, so code has to be relocated just to
support OBS=0. We continue to plug holes when we find
them; this change relocated %VMXGOPTR calls to support
OPTION OBS=0 in VMXGSUM and VMXGRMFI, but there is an
alternative for testing: use a DUMMY file as input, so
that all datasets have zero observations, but with the
OPTION OBS=0 being set. On MVS you can do this with JCL
with //SMF DD DUMMY for the input file, or on all SAS
platforms you can use FILENAME SMF DUMMY; to read nil.
And if your need is to actually test, but you don't want
to use much CPU nor disk space, use OPTIONS OBS=5000; to
to restrict the input volume; it is only the exact OBS=0
value that is our nemesis.
Change 20.016 Sample PROC PRINTs of WebSphere SMF 120 data had several
ANAL120 prints bypassed during testing (by adding MACRO __ before
Feb 28, 2002 and a % after the block of code to be bypassed, which is
fine ONLY if there are no percent signs in the code being
bypassed!), but that MACRO and Percent Sign should have
been removed so all PROC PRINTs would execute.
Thanks to Jim Kovarik, AEGON, USA.
Change 20.015 This old report program has ENTITY as an array name, and
ANALRACF under SAS V8.2, a bogus message is printed on the log:
Feb 28, 2002 ERROR: THE PRODUCT WITH WHICH THE FUNCTION/SUBROUTINE
IS ASSOCIATED IS EITHER NOT LICENSED FOR YOUR SYSTEM OR
THE PRODUCT LICENSE HAS EXPIRED. PLEASE CONTACT YOUR
SAS INSTALLATION REPRESENTATIVE.
but there was no real error, and data step was correctly
executed. Once discovered (and with same day service!),
SAS Technical Support Usage Note SN-007039 documents that
the names: ENTITY, GENDER, STDNAME, should not be used as
array names in V8, but those names will be changed in V9,
to protect the innocent. I changed ENTITY to ENTITI to
eliminate the exposure.
Thanks to Clive Talbot, EDS, UK.
Change 20.014 Support for new subype 6 and 7, Mobius RDS InfoPac View
EXIPAC06 Direct Product's user SMF record create new datasets:
EXIPAC07 DDDDDD Dataset Description
IMACIPAC IPAC06 IPAC06 PAGES/HIERARCHY CODE
VMACIPAC IPAC07 IPAC07 ARCHIVE PLACEMENT/LONGEVITY
VMXGINIT
Feb 27, 2002
Thanks to Mary Beth Delphia, Texas Comptroller of Public Accounts, TX
Change 20.013 Enhancements for building "PDB's" from various SMF data
UTILBLDP is enhanced so that datasets can be "ZERO-OBS'ed". This
Feb 27, 2002 is needed if you want to build PDB.ASUM70PR & PDB.ASUMCEC
from SMF, which needs only PDB.TYPE70 and PDB.TYPE72GO
datasets, but the logic in member ASUM70PR also updates
the PDB.RMFINTRV dataset, so it must be created, but with
zero obs for all of the unwanted RMF datasets. Two new
examples in the comments are show here so you can see
that UTILBLDP is a powerful tool if you want to create
particular MXG datasets without running BUILDPDB:
Example 2.
Create PDB.ASUM70PR and PDB.ASUMCEC from SMF 70 and 72s:
%UTILBLDP(OUTFILE=INSTREAM,
USERADD=7072 71 73 74 75 78,
ZEROOBS=71 72 73 74 75 78,
BUILDPDB=NO,
INCLAFTR=RMFINTRV ASUM70PR
);
RUN;
%INCLUDE INSTREAM;
RUN;
Note that by using OUTFILE=INSTREAM, and then by using
%INCLUDE INSTREAM; this example will actually execute
the code that it just built.
Example 3.
Create only PDB.JOBS, PDB.STEPS, and PDB.PRINT from the
SMF 6, SMF 26 (JES2 in this example), and SMF 30 records.
Since PDB.JOBS is the sum of the steps data, you must
create PDB.STEPS to be able to create PDB.JOBS.
%UTILBLDP(OUTFILE=INSTREAM,
USERADD=6 26J2 30,
SORTOUT=NO,
BUILDPDB=NO,
INCLAFTR=BUILD005
);
%INCLUDE INSTREAM;
RUN;
Change 20.012 This report that mimics IBM's IXGRPT1 was wrong in column
ANAL88 headed "NTRY FULL", because variable SMF88ALS was printed
Feb 27, 2002 instead of SMF88EFS; All SMF88ALS were changed to EFS,
Mar 1, 2002 and some report field widths were increased from 5 to 6.
The SORT order now uses SMF88LTD to match IBM's report.
Thanks to Wesley Andrews, Alltel, USA.
Change 20.011 DO NOT USE ML-21 OF THE MXG TAPE MOUNT MONITOR. That
ASMTAPES level of the monitor was included only in the fix1919.zip
Feb 27, 2002 file, but as found to create still more 0E0 ABENDS. The
ASMTAPES member in MXG 20.01 is still at ML-20. A new
Maintenance Level is in development.
Change 20.010 Support for Top Secret V5.2 required only the change of
VMAC80 OR RACFVRSN=051X THEN DO; to
VMAC80A OR RACFVRSN=051X OR RACFVRSN=052X THEN DO;
Feb 25, 2002 While both members were updated, the TYPE80A member
is really the only member to use for SMF 80 RACF records.
Thanks to Chris Taylor, GMAC Insurance, USA.
Change 20.009 Execution of MXG under ASCII only. Some source members
TYPEMOND still had hardcoded informats of IB, PIB, PK, and RB
TYPETMON instead of "&IB.", of "&PIB.", &PK.", and "&RB." macro
TYPEVM variable names, needed for transparent execution of MXG
VMAC33 across platforms. The members that had IB or PIB would
VMAC71 have had incorrect values for those variables if MXG was
VMAC94 was executed under ASCII SAS, and they are listed below.
VMACAXC The other members revised had only PK and RB hardcoded,
VMACFTEK which works fine, but which are now changed so they are
VMACMONI consistent across MXG source, if ever needed.
VMACQTRT Members with PIB or IB:
VMACSTRS Member VARIABLE Notes
VMACTMDB VMAC71 GMTOFF71 - would impact STARTIME
VMACXAM VMACFTEK REASON
Feb 25, 2002 VMACSTRS Many
VMACXAM Several
Thanks to Freddie Arie, TXU, USA.
Change 20.008 Fixes for UTILEXCL and ASUMUOW for CICS after MXG 19.19:
UTILEXCL -ASUMUOW still did not increment SPINCNT, even with Change
VMXGUOW 19.230, but now it does. This had no impact if you left
Feb 21, 2002 the default SPINCNT for ASUMUOW at zero, or if you had
Mar 5, 2002 relatively few "inflight" transactions.
-UTILEXCL caused ASUMUOW to fail, with VARIABLES NOT FOUND
because the utility failed to create 9 CICSTRAN variables
(computed from other variables) that were required by the
syntax of the ASUMUOW program:
UOWTIME UOWIDCHR
CPUTM ELAPSTM IRESPTM TRMCHRCN
WTOTIOTM WTTOIOTM WTUNIOTM
You could circumvent the syntax error in ASUMUOW program
by adding those variables to the list in MACRO _VCICTRN
in the IMACEXCL member you created with UTILEXCL, but
your PDB.ASUMUOW dataset could still be invalid:
Satisfying the syntax above does not satisfy the logic in
ASUMUOW that requires these MXG variables be populated in
CICSTRAN so that matchup by Unit of Work is possible:
Variables required in CICSTRAN to build ASUMUOW
MXG variable IBM CMODHEAD IBM CMODIDNT
TRANNAME TRAN DEC 001
STRTTIME START DEC 005
ENDTIME STOP DEC 006
NETSNAME NETNAME DEC 097
UOWID UOWID DEC 098
UOWIDCHR UOWID DEC 098
UOWTIME UOWID DEC 098
So UTILEXCL is now enhanced and will tell you if you have
excluded fields that are required to run ASUMUOW, and
will list which of the above fields are not in your CICS
transaction records.
But VMXGUOW should not have failed when a variable in the
sum list is deleted from your SMF record, so by inserting
OPTIONS DKRICOND=NOWARN; and OPTIONS DKRICOND=ERROR;
appropriately, VMXGUOW now only sums variables that are
found in your CICSTRAN dataset.
-UTILEXCL did not correctly recognize DBCTL and IMS data
segments, causing messages "POSSIBLE CRITICAL ERROR" and
UNKNOWN FILED CMODHEAD=PSB WAIT CMODNAME=USER
UNKNOWN FILED CMODHEAD=DBCTL CMODNAME=DBCTL
UNKNOWN FILED CMODHEAD=RMIDATA CMODNAME=DBCTL
notes on the UTILEXCL log. The CICS dictionary lists the
DBCTL/DBCTL fields as 64 individual 4-byte fields, while
the DBCTL/RMIDATA field is a single field of 256 bytes; I
believe both describe the same DBCTL data fields, and are
processed by IMACICDB, and are different than the 60-byte
example in IMACICUS (that I want to believe was replaced
by the DBCTL/DBCTL and DBCTL/RMIDATA data segment). This
note will be revised if the two DBCTLs are not the same.
Thanks to Barry Mueller, Tyco Electronics, USA.
Thanks to Donald Williams, University of North Carolina, USA.
Change 20.007 -Variable ORACMSB (Max Additional Stacks Used) is created
VMACORAC in TYPEORAC from the old-format Oracle SMF records.
Feb 22, 2002 -Oracle8 i Enterprise Edition with OSDI, Release 3 (8.1.7)
Mar 1, 2002 for OS/390 has INCOMPATIBLY changed the layout from "MPM"
based to "OSDI" based, and it took several iterations to
discover their data did not agree with their DSECT:
DSECT: DTAI-8,DTAO-8,XCPU-8,RPCS-4,HWST-4,INV-1 but the
DATA: DTAI-8,DTAO-8,RPCS-4,XCPU-8,HWST-8,INV-1 showed
where the fields really were to get realistic values.
The only CPU time measure now is the CPUXMETM, so CPUTM
variable (always the total of all CPU times) will only be
equal to CPXMETM in the OSDI records; the other CPUxxxx
variables are all missing, as are all of the variables
that are no longer created in the new OSDI record. And
that includes the ORACMSB field added earlier in this
change that is not carried forward into the OSDI record.
This support also protects the READTIME field from CA-7,
which writes a 'EE'x or 'EF'x in the first byte of Read
Time to flag jobs, but CA-7 did not provide the exit code
for IEFU83 to correct their overwrite. MXG detects and
resets to 00, but it turns out that SAS read the EE1B897F
time value as a negative, and shifted the READTIME back
four days; I've suggested that the SAS SMFSTAMP8 format
should not treat the first bit as a sign bit, but instead
should have input the field as positive, causing the
READTIME to be 462 DAYS into the future, and more likely
to be detected as incorrect, so you will notice and then
get the fix you need from CA to correct the Oracle SMF.
Mar 1: the above change did handle the OSDI format Oracle
8.1.7 records, but there was a missing @; in the MPM-only
section of code, so the 8.1.7 MPM format records were not
correct; this change inserted the missing @;.
Thanks to Sudie Wulfert-Schickedanz, Anheuser-Busch, USA.
Thanks to Matt Martin, United States Post Office, USA.
Thanks to Leslie Arndt, NITC/USDA, USA
Thanks to Yvonne McDonough, NITC/USDA, USA
Change 20.006 READDB2 and VMAC102 only recognized DB2 102 subtypes thru
EX102316- 314; this changes adds the exits and macros needed to
EX102350 recognize those subtypes. However, the actual subtypes
READDB2 themselves are not decode; test data is required to write
VMAC102 the support code, so only when you enable a new subtype
VMXGINIT and send sample data can the subtype be supported.
Feb 15, 2002
Thanks to Ford Wong, Workers Compensation Board of Alberta, CANADA.
Change 20.005 -Variables STC16SCL, STC17SCL, and STC17MVC were created
VMACSTC as stated in MXG Change 19.298, but only in my test lib.
Feb 15, 2002 The tested member is now moved to the source library and
Feb 27, 2002 those three variables will now be created and kept.
-Variables STC11CUB is now FORMATed TIME12.2; it was
always the time in seconds and fractions, but now will be
printed as a time duration, and documented as a time
variable by virtue of being formatted with a TIME format.
Thanks to Kis Ranai, Citicorp, USA.
Change 20.004 IBM documentation for AS/400 V5R1 QAPMJOBM JBCPU/JBTCPU
VMACQACS CPU time fields are wrong; documented as in milliseconds,
Feb 15, 2002 the data in QAPMJOBM is in microseconds, but QAPMJOBL's
same-named variables are still in milliseconds. The two
&PIB.8.3 in the INPUT lines for JBCPU and JBTCPU after
the INFILE QAPMJOBM statement were changed to &PIB.8.6
and the QAPMJOBM CPU times now match the QAPMJOBL CPU.
Thanks to Pat Wingfield, Bank of America, USA.
Change 20.003 Change 19.264 described NPM documentation errors for the
VMAC28 NRP/NRT/NIT RTYP field in APAR OW53087 which led me to
Feb 12, 2002 think there were undocumented data, but IBM has clarified
and will revise their APAR text. There is only one value
for RTYP in each of those segments: NRPRTYP=2, NRTRTYP=1
and NITRTYP=3, so there is no need to test RTYP value.
NRPRTYP was correctly tested in 19.264, but the MXG test
for NRTTYPE=2 was removed by this change, once IBM
documented what's really there!
25Apr02: Variable NRTDTYPE was removed by this change; it
is now a reserved field, but that removal was not noted.
Change 20.002 MXG 19.19 with SAS Version 6 only: fails in the JCLTEST6
JCLTEST6 because of one error in spelling, but also because some
VMACTMV2 MXG support for new products that did not exist before,
Feb 12, 2002 now require SAS V8.2 or later:
Mar 29, 2002 -Landmark TMVS. MXG support for new release was added to
19.19 on the last day, only QA'd under SAS V8.2, and the
unacceptable-to-SAS-V6-nine-byte-character-variable-name
of SYSFIL003 (temporary, and not KEPT!) was not detected
(until you ran JCLTEST6 under SAS V6!). Deleted one byte.
New support members were NOT changed; they are listed for
documentation only; all require SAS V8 for execution:
-TYPEWWW WebLog requires SAS V8 because web data is long
strings of variable length text that requires V8.2's
support for stored character variables length of 32K.
By using COMPRESS=YES, you don't waste any DASD, but
can have the entire string in one variable.
Both LENGTH and $VARYING4096 text caused error messages.
-TYPEAIX code requires V8.2 for $VARYING4096 statement.
-TYPETMTC code requires V8.2 for $256 length variables,
and PDJULI6. informat; that informat was added in the
SAS Y2K release 6.09E (TS-470) for the IBM mainframe,
and in 6.12 for all other platforms.
Thanks to Freddie Arie, TXU, USA.
Thanks to Jim S. Horne, Lowe's Companies, USA.
Change 20.001 Never Used.
LASTCHANGE: Version 20.