COPYRIGHT (C) 1984-2023 MERRILL CONSULTANTS DALLAS TEXAS USA
MXG CHANGES 23.23
=========================member=CHANGE23================================
/* COPYRIGHT (C) 1984-2006 MERRILL CONSULTANTS DALLAS TEXAS USA */
Annual MXG Version 23.23 is dated Feb 20, 2006, thru Change 23.358
PreRel MXG Version 23.23 was dated Feb 15, 2006, thru Change 23.351
Final MXG Version 23.11 was dated Feb 2, 2006, thru Change 23.340
Third MXG Version 23.11 was dated Feb 2, 2006, thru Change 23.338
Second MXG Version 23.11 was dated Jan 31, 2006, thru Change 23.336
First MXG Version 23.11 was dated Jan 30, 2006, thru Change 23.336
MXG Version 23.10 was dated Jan 23, 2006, thru Change 23.328
MXG Version 23.09 was dated Dec 7, 2005, thru Change 23.309
Third MXG Version 23.09 was dated Dec 6, 2005, thru Change 23.309
Second MXG Version 23.09 was dated Dec 1, 2005, thru Change 23.303
First MXG Version 23.09 was dated Nov 30, 2005, thru Change 23.300
MXG Version 23.08 was dated Oct 27, 2005, thru Change 23.273
First MXG Version 23.08 was dated Oct 25, 2005, thru Change 23.271
Final MXG Version 23.07 was dated Aug 10, 2005, thru Change 23.209
First MXG Version 23.07 was dated Aug 9, 2005, thru Change 23.207
MXG Version 23.06 was dated Jun 29, 2005, thru Change 23.176
MXG Version 23.05 was dated Jun 7, 2005, thru Change 23.154
First MXG Version 23.05 was dated Jun 5, 2005, thru Change 23.148
MXG Version 23.04 was dated May 4, 2005, thru Change 23.107
MXG Version 23.03 was dated Apr 22, 2005, thru Change 23.090
MXG Version 23.02 was dated Apr 4, 2005, thru Change 23.061
MXG Version 23.01 was dated Mar 15, 2005, thru Change 23.050
MXG Version 22.22 was dated Feb 1, 2005, thru Change 22.378
MXG Newsletter FORTY-SIX was dated Feb 1, 2005.
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. 2006 Annual MXG Software Version 23.23 automatically was sent.
II. Incompatibilities and Installation of MXG 23.23.
III. Online Documentation of MXG Software.
IV. Changes Log
=======================================================================
I. 2006 Annual MXG Software Version 23.23 dated February 20, 2006.
The Annual Version was available for ftp download on Feb 20, but
a CD-ROM containing MXG 23.23 will also be sent to all sites; the
copying/packaging began on the 20th, with mailing on Feb 25th, so
all sites should receive the package in early March.
Major enhancements added in MXG 23.23 - 2006 Annual MXG Version
TYPE70 23.348 Final "70's Record Rewrite", PARTNCPU corrected.
TYPE115 23.347 Support for MQ for z/OS Version 6.0 (COMPAT)
TYPE110 23.342 Support for CANDLE UMBRELLA optional CICSTRAN data.
READDB2 23.345 New WANTONLY= enhancement for %READDB2 utility.
MONTHxxx 23.351 &MXGSYSN macro variable for compatibility.
WEEKxxx 23.351 &MXGSYSN macro variable for compatibility.
MACKEEP 23.346 DB2 Tailoring Example to add DB2 102 to PDB.
Major enhancements added in MXG 23.11
1. Corrections for "Split 70/Over 60 LPAR" RMF 70 Re-Write.
TYPE70 23.330 Corrections to Split 70/Over 60 LPAR Change 23.321.
2. Yet another major revision to RMF 70 processing:
TYPE70 23.336 Support for RMF with repeated SYSTEMs in a SYSPLEX.
3. ITRM sites that build RMFINTRV do NOT have to change anything;
the previous "INCOMPATIBILITY" that required _STY70 to be put
in your EXPDBOUT member is NOT needed when RMFINTRV is created,
and everyone SHOULD create the XRMFINT/RMFINTRV dataset.
"Routine" enhancements/changes:
TYPENDM 23.331 Support for NDM/Connect Direct subtype TF, TL, TW.
TYPE30 23.329 Support for SMF30CEPI field, new CPUCIPTM variable.
TYPE7072 23.335 Variables SMF70OIL and SMF70SYN now KEPT in TYPE70.
TYPE30_V 23.334 IMACINTV default now OUTPUTs TYPE30_V/PDB.SMFINTRV.
TYPEVMXA 23.332 Variables HFLLIST,HFPGACT were accumulated.
Major enhancements added in MXG 23.10
1. Support for over 60 LPARs. Support for Split RMF 70 records.
Required extensive rewrite of the "heart and soul" logic in the
VMAC7072 and VMXG70PR members, potentially impacting datasets
TYPE70 TYPE70PR RMFINTRV ASUM70PR ASUM70LP ASUMCEC and ASUMCELP
from TYPE7072, TYPS7072, BUILDPDB/BUILDPD3, or RMFINTRV programs.
New DATA records that now exist that required this change:
INCOMPATIBLE: If you have more than 32 LPARs defined, versions
earlier than MXG 23.10 will fail with ARRAY errors.
See Change 23.322/23.321 text.
INCOMPATIBLE: IBM now splits RMF 70 records when you have lots of
LPARs and lots of spare engines; MXG 22.22+ detects
and reports split records were found in messages on
the SAS log, but created incomplete/wrong data in
TYPE70/TYPE70PR/ASUM70PR/ASUMCEC from split 70 SMF.
See Change 23.322/23.321 text.
New stuff YOU may have to do when you install MXG 23.10 or later:
INCOMPATIBLE: ITSV/ITRM sites that run BUILDPDB but do NOT create
the XRMFINT (RMFINTRV) dataset, MUST insert this
_STY70
text (an invocation of that old-style macro) in the
EXPDBOUT member of the site's "USERID.SOURCLIB" MXG
tailoring library. See Change 23.322/23/321 text.
Note: MOST ITRM SITES DON'T HAVE TO DO ANYTHING!
It is rare for an ITRM site's data dictionary
to specify processing of the RMF 70 records
and then NOT create the XRMFINT dataset.
This is ONLY REQUIRED if you have NOT
installed ITRM 27IS03 hotfix applied
INCOMPATIBLE: If you use the _VAR7072/_CDE7072 macros in your own
programs (or the programs you inherited!), then you
must also add the statement _STY70 after the data
step that reads the SMF data.
COMPATIBLE AND TRANSPARENT: MOST MXG USERS. Do nothing; drop-in
MXG 23.10+ and be corrected and protected.
NOTE: This is the most extensively tested change in MXG history:
un-split RMF/CMF 70 records from 34 sites with old and new
z/OS levels, were read with the old and new code and their
outputs compared with the TEST70SP program; PLEASE use the
TEST70SP program to read a day's RMF data and then examine
its reports for any un-documented discrepancies.
- SPLIT records can't be directly compared, since the old
code mishandled them. But the MXG data sets were run
thru ANALRMFR and those reports exactly matched IBM's
CPU reports for the split records. That code has been
in production for weeks with split records with no
reported errors. MXG now writes a note on the SAS log
that split records were processed, but it's just FYI.
- The rewrite corrected some errors and inconsistencies
that are noted in the change text that will cause false
positives in the PROC COMPARE output; primarily these
were intervals in which a policy change occurred or in
which an LPAR was not active for the full interval, or
in CPUs with CAI error bits set, and the new results
appears to be correct and consistent.
Major enhancements added in MXG 23.09
1. Critical corrections that require you to install MXG 23.09 for:
-JES3 with MXG 23.02 thru 23.08 must install MXG 23.09; there were
zero observations created in TYPE26J3. Change 23.282.
-DB2 V8.1 Package Data could be truncated. Change 23.280.
-z/VM VXSYTEPM deaccumulation now correct. Change 23.290
-ASUM70PR corrected for RMF Intervals with DURATM less than 1 min.
TYPE26J3 23.282 HIPER: 23.02-23.08, JES3 only. No obs in TYPE26J3.
TYPEDB2 23.280 DB2ACCTP Package Data required fix (final, trunc!).
TYPEVMXA 23.290 z/VM MONWRITE VXSYTEPM dataset finally correct.
ASUM70PR 23.289 RMF Intervals with DURATM less than one minute fix.
TYPE70PR 23.288 BMC SMF 70 from z9 have LPARCPUX=0, counts wrong.
VMXG70PR 23.276 PDB.ASUMCEC PCTL0OV,LP0MGTTM,LPCT0OV were zero.
2. New ML-37 of MXGTMNT captures SYSLOG messages for mounts, but can
also capture any SYSLOG message into its SMF records.
ASMTAPEE 23.300 ML-37 MXGTMNT monitor now captures SYSLOG messages
ASUMTAPE 23.300 Now merges SYSLOG, MXGTMNT, and IBM SMF 21s.
TYPETMNT 23.300 New TYPESYMT, TYPESYSL datasets from SYSLOG messages.
3. Easy creation of desired DB2 datasets with only wanted variables.
READDB2 23.287 Selective creation of DB2 datasets and data now easy.
4. Other enhancements, followed by less important fixes:
TYPE30 23.292 Support for APAR OA11675, EXCPTOTL max now 4 gig.
TYPENDM 23.291 Support for CDI/NDM subtypes HW and NM.
TYPEVM 23.285 Support for VM Account optional YYMMDD date format.
TYPESTC 23.279 Support for STK VTCS 6.0 and 6.1 SMF records (COMPAT)
TYPE80A 23.275 Support for CA TopSecret 103-105,109,255 SMF80DTPs.
TRNDxxxx 23.293 New &INTTRND can change default INTERVAL=WEEK in TRND
TYPE6 23.284 Print accounting for "Printway" tcp/ip SMF 6 records.
TYPE26J2 23.277 New UNSPUNJB, JOEPURGE status variables created.
TYPE30 23.296 TYPE30_6 RESIDTM/ACTIVETM wrapped after 51 days.
TYPEDB2 23.295 DB2ACCTG dataset didn't contain nine QBGA variables.
TYPETMVS 23.294 TYPETMVS CIJN and other CI variables INCOMPAT.
TESTIBM1 23.281 MXG 23.08 only. ERROR: File WORK.TYPE791.DATA does ..
VGETENG 23.298 MXG 23.08 only: FILE INSTREAM IN USE.
INSTREAM 23.298 MXG 23.08 only: INSTREAM DD was required, not now.
Major enhancements added in MXG 23.08
TYPE70 23.270 PCTIFBYn variables restored to TYPE70 dataset.
TYPEVMXA 23.269 z/VM MONWRITE dataset VXSYTEMP is now validated.
TYPE79 23.268 RMF 79 subtype 9 records are now validated/corrected.
RMFINTRV 23.265 23.05-23.07. IFA/IFE CPU times zero in RMFINTRV wkld.
TYPESYSI 23.258 Support for CA SYSVIEW IMS user SMF records.
TYPEMWSU 23.254 ADOCMWSU for HP MeasureWare on Sun was updated.
ASUMTAPE 23.253 Initial rewrite of ASUMTAPE for TMNT/21 records only.
ASUMUOW 23.251 More robust definition of "TRANNAME" in PDB.ASUMUOW.
READDB2 23.249 OBID and DBID are decoded in DB2 102 Trace datasets.
ASMTAPEE 23.247 ML-36 is now available of MXGTMNT.
VGETDDS 23.244 Using VGETDDS to get all DDNAMES can fail.
ASMRMFV 23.243 Enhancement to RMF III VSAM Support
TYPE82 23.242 Support for SMF type 82 subtypes 20 and 21 added.
ASUMUOW 23.240 IRESPTM and ELAPSTM in PDB.ASUMUOW revised.
VMXGDUR 23.239 Support for DURATM keywords TENMIN and FIVEMIN.
ASUM70PR 23.237 Variables NRIFACPU,NRIFLCPU added to PDB.ASUM70PR/CEC
TYPEENDV 23.236 Support for Endeavor Release 7; no changes.
TYPEDB2 23.235 DB2TCBTM in DB2ACCT obs with DB2PARTY='R' was wrong.
GRAFWLM 23.234 CPU Utilization graph by goal importance, Enrico's.
TYPEWWW 23.233 Enhancement/corrections to Web Log support.
TYPE1023 23.231 Support for DB2 IFCIC 225.
TYPETMS5 23.229 Support for DEVTYPE='3592' devices in CA-1.
TYPEEREP 23.228 INPUT STATEMENT EXCEEDED for IBM ATL record.
TYPENDM 23.227 NDMCPUTM in NDMCT is now deaccumulated and correct.
TYPEIPAC 23.223 Support for Mobiud/IPAC Rel 6.3 INCOMPATIBLE.
TYPE6156 23.219 ICF Catalog 05 record GATGEN and GATWRAP corrected.
TYPE88 23.213 All SMF88xxx datetime variables are now local zone.
Major enhancements added in MXG 23.07
TYPEDB2 23.181 DB2 V8.1 DB2ACCTP still wrong for multi-package.
ASMTAPEE 23.177 ML-34 MXGTMNT now GA, has ASMHSCEX for HSC mounts!!!
TYPE7072 23.186 Support for z9 CPU, new CPUTYPE='2094'x INCOMPAT.
TYPEMGCR 23.200 Support for MegaCryption's user SMF record
TYPETPFC 23.199 Support for TPF Continuous Data Collection TPFCDC.
TYPESARR 23.196 Support for CA SAR/VIEW R11, INCOMPATIBLY CHANGED.
TYPETNG 23.193 Support for TNG AIX CA PROCESS GROUP (PID) object.
TYPE7072 23.187 Support for APAR OA10346 adds LPAR User Partion ID.
MXGABND 23.184 New %LET MXGABND=nnnn forces ABEND for CICS EXCL ERR.
TYPE89 23.183 Support for APAR OA11036 added MACHTIME to SMF 89.
ASUMTALO 23.201 Condition Code (Return Code) 4 in ASUMTALO eliminated
BUILD005 23.197 Hardcoded "SPIN" DD replaced by &SPINOUT.
IMACICDA 23.190 Comments only. IMACICDA is not used with IMACEXCL.
Major enhancements added in MXG 23.06
TYPE6 23.159 PSF SMF 6 with SMF6LN6=24 another INPUT EXCEEDED.
TYPE22 23.175 Support for subtype 11 I/O Configuration Change
TYPESAMS 23.172 SAMS POOLS record INCOMPATIBLY CHANGED.
TYPE99 23.169 Support for SMF 99 Subtype 2 additional segments.
TYPEMVCI 23.166 Support for additional CMRFILE fields in CMRDETL.
TYPE120 23.164 Support for PQ96144, SM120JHF/JHT corrected.
TYPESYNC 23.163 New "SMS" UCB Address caused INVALID ARGUMENT error.
TYPE102 23.160 Many new variables added to T102S106 dataset.
Major enhancements added in MXG 23.05
TYPEDB2 23.140 REQUIRED FOR DB2 V8.1, more IBM INCOMPATIBLE CHANGES.
TYPEVMXA 23.128 z/VM 5.1 record 1.19 IBM misdocumented, had ERRORs.
TYPE119 23.146 Support for new FTP Server Security Section in st 70.
TYPEPRPR 23.142 Support for Oce's Prisma Print log file.
TYPECYFU 23.139 Support for CyberFusion user SMF record validated.
TYPESYSV 23.137 Support for CA SYSVIEW CICS data in XPFCMCR,XPFCSDCR.
TYPECMF 23.136 Support for 2180 RAID RANK data in CMF user record.
TYPE80A 23.135 Support for Top Secret Versions 5.2 and 5.3.
TYPE80A 23.134 Unexpected RACF TOK80LN2=0 record was deleted.
TYPESTC 23.125 Support for HSC V6 changes to STCLMU subtype 4 SMF.
TYPEIWAY 23.133 Support for Iway Software's IWAY (aka EDA/SQL) SMF.
TYPE102 23.131 Support for DB2 IFCID=313 creates T102S313 dataset.
ASUMMIPS 23.126 RPRTCLAS added to identify Service/Reporting Classes.
RMFINTRV 23.123 CPUIFATM/IFE and BATIFA,CICSIFA,etc now in RMFINTRV.
ASUM70PR 23.121 BY VARIABLES NOT SORTED corrected, PROC SORT added.
TYPE6 23.120 Support for ESS GEPARMKY=004Dx variable ESSMAIL2.
TYPETNG 23.113 Zero observations with a Solaris cube.
FORMATS 23.144 "Expanded Length" format values revised logic for S2.
TYPEDB2 23.111 Support for DB2 V8.1 Package Data INCOMPATIBLE.
BUILDPDB 23.124 Duplicate SMF 30 interval records duped in SMFINTRV.
Major enhancements added in MXG 23.04
TYPEIMS 23.099 Support for IMS Version 9.1 was already in MXG 22.22
TYPEDB2 23.098 Support for DB2 V8.1 restructured Package Data.
TYPE30 23.101 Support for APAR OA10901, SMF30ZNF zAAP noralize fact
TYPE74 23.093 Support for Type 74 subtype 8 corrected.
TYPETMO2 23.100 TMON for CICS/TS V2.3 for CICS/TS 3.1. No Changes.
VGETJESN 23.096 Blank TYPETASK in TYPE30_6 data, STCs, corrected.
TYPE6 23.091 Printway File Transfer, z/OS 1.6 from VPS corrected.
ASUMTALO 23.104 Enhancement to summarize by "groups".
ASUMTMNT 23.104 Enhancement to summarize by "groups".
Major enhancements added in MXG 23.03
ASUM70PR 23.071 PDB.ASUMCEC contains CEC total IFA CPU time
RMFINTRV 23.071 IFA CPU time added to PDB.RMFINTRV
TYPE7072 23.070 Correction for IBM inability to get STARTIME right.
ASUM70PR 23.069 Short RMF interval impacts PDB.ASUMCEC.
TYPERMFV 23.080 RMF III data for IFAs added to ZRBASI, ZRBENC
ANALPATH 23.078 Path Activity Report includes CMR and OTH pend.
UTILEXCL 23.075 CMODNAME=RMI,CMODHEAD=DB2CLOCK didn't generate skip.
ANALFIOE 23.074 FICON Open Exchange analysis includes CMR pend time.
TYPE73 23.072 Support for APAR OA09921 IBM TotalStorage DS6000.
BUILDPD3 23.282 BUILDPD3 now sets Condition/Return Code of zero.
TYPE80A 23.066 Support for RACF Events 27, 28, 29 for unix.
TYPE78SP 23.064 TYPE78SP only had below-16MB subpool variables.
TYPE90A 23.081 WLM Service Policy new name tracked in TYPE9024.
Major enhancements added in MXG 23.02
TYPEVMXA 23.051 Support for z/VM Linux Application Server data.
TYPEVMXA 23.061 Support for z/VM TCP/IP Application Server data.
Major enhancements added in MXG 23.01
Typos 23.012 MXG 22.22 JCLTEST/MXGSASVn had error-causing typos.
These typos only affected your testing of 22.22.
VMXGUOW 23.017 Default IMACUOW in 22.22 caused NO BY error.
If you use ASUMUOW, you MUST update your IMACUOW.
If you don't use ASUMUOW, remove it from JCLPDBn.
WEEKxxx 23.015 Sort Order for SMFINTRV may have to be changed.
MONTHxxx 23.015 Sort Order for SMFINTRV may have to be changed.
TYPETMS5 23.045 Support for TMS Release 11 - no changes.
TYPEMPLX 23.027 Support for IMPLEX Versions 3.1 and 3.3
TYPESTC 23.022 Support for VSM subtype 20, problems with ST 4.
TYPECYFU 23.020 Support for CyberFusion user SMF record.
TYPE80A 23.006 Support for many new RACF events.
TYPESAMS 23.004 Support for SAMS Vantage "LSPACE" record subtype.
TYPECSF2 23.024 CONTROL-D SF2 records INCOMPATIBLY changed.
UTILCONT 23.025 Failed if DISP=NEW dataset was contented.
TYPE74 23.029 AVGxxxMS variables now FORMAT 6.3.
TYPEVMXA 23.050 z/VM VXBYUSR CPU and DELTATM corrected.
TYPEDB2 23.011 DB2 QWHT/QWHU/QWHD/QWHA could be blank/missing.
ASUM70PR 23.021 LP0xxxxx variables were not populated.
TYPEQACS 23.007 CPU variables in QAPMJOBL were incorrect.
TYPENDM 23.001 INPUT STATEMENT EXCEEDED for NDM subtype 'SY'.
See member NEWSLTRS or the Newsletters frame at www.mxg.com for
current MXG Technical Notes that used to be in CHANGES.
All of these enhancements are described in the Change Log, below.
SAS Version requirement information:
MXG 22.08 or later is REQUIRED for SAS V9.1.2 or V9.1.3; see
"Major Enhancements added in MXG 22.08" in CHANGES, for the major
items, then search Newsletters for V9 for all of the minor items.
MXG executes best under the most recent SAS Version, with all
Critical HotFixes installed by your SAS Installer:
For SAS V9.1.3 on z/OS:
There are no reported errors, and MXG's CONFIGV9 now specifies
V9SEQ instead of V6SEQ. V6SEQ does not support long length
character variables. SAS V9.1.3 is STRONGLY RECOMMENDED.
For (back-level!) SAS V9.1 or V9.1.2 on z/OS:
SN-013514 is REQUIRED to be able to read datasets that were
created by V6SEQ (tape) engine.
SN-012437 is REQUIRED to prevent creation of corrupt/unreadable
datasets with V7SEQ,V8SEQ, or V9SEQ.
Both fixes ARE included in SAS V9.1.3, but V9.1 or 9.1.2 is NOT
SAFE without those two hot fixes, and if you do NOT have those
two fixes on 9.1 or 9.1.2, you MUST set V6SEQ in CONFIGV9.
With MXG 23.02 or later, V9SEQ is the default sequential engine
specified in CONFIGV9, but if you are still SAS V9.1 or V9.1.2,
you MUST install the two hot fixes listed above.
For SAS Version 8.2, HotFix Bundle 82BX08 is REQUIRED to be safe.
Sequential Engine Status:
V9SEQ is fixed in V9.1.3; it is now the default in CONFIGV9.
V6SEQ, if used under V9.1.2, requires SN-013514.
V8SEQ was always safe under SAS V8.2, but it wasted CPU time
by always compressing when writing in tape format.
MXG New-Version QA tests are executed on z/OS with SAS V9.1.3 and
V8.2, and on Windows XP with SAS V9.1.3. But previous QA tests
have been run with all SAS releases on z/OS, SAS V8.2 and V9.1 on
Linux RH8 on Intel, with V9.1 on Solaris v2.8 on Model V880, and
V9.1 on HP-UX v11.11 model rp5470, confirming full compatibility.
MXG should execute under SAS V9.1.3 or V8.2 on every possible SAS
platform without errors! Each new MXG version is also tested with
the SAS ITSV/ITRM product by the ITRM developers.
Availability dates for the IBM products and MXG version required for
the processing of that product's data records:
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 OW41318 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+ 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
z/OS 1.4 Over 16 CPUs/LPARs May 29, 2003 21.02
z/OS 1.4 DFSMS/rmm, RACF Aug 29, 2003 21.04
z/OS 1.5 Mar 31, 2004 21.21
z/OS IRD ASUM70PR/ASUMCEC Sep 22, 2003 21.05
z/OS IRD TYPE70PR Mar 11, 2004 22.01
z/OS IRD TYPE70,RMFINTRV Mar 22, 2002 22.12
z/OS 1.6 - No IFAs Sep 30, 2004 *22.09
z/OS 1.6 - With IFAs Sep 30, 2004 *22.11
z/OS 1.7 (COMPATIBLE CHANGES) Sep 30, 2005 23.05
z/OS IFA data in RMF 79s Sep 30, 2005 23.10
z990 CPUs - CPUTYPE '2084'x Aug 25, 2003 21.04
z890 CPUs - CPUTYPE '2086'x Jun 24, 2004 22.07
z9 CPUs - CPUTYPE '2094'x Jul 20, 2005 *23.09
More than 32 LPARs Jan 30, 2006 23.11
SPLIT RMF 70 records Jan 30, 2006 23.11
Duplicate SYSTEMs in a SYSPLEX Jan 30, 2006 23.11
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
CICS-TS for Z/OS Version 2.3 Dec 19, 2003
Using UTILEXCL to create IMACEXCL: 21.04
Reading un-Excluded CICS with TYPE110, no IMACEXCL:*22.04
CICS-TS for Z/OS Version 3.1 Mar 15, 2005
Using UTILEXCL to create IMACEXCL: 22.13
Reading un-Excluded CICS with TYPE110, no IMACEXCL: 22.22
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 31, 2001 19.19
DB2 7.1.0 corrections Mar 31, 2001 20.06
DB2 8.1 Tolerate, no packages Mar 31, 2004 20.20
DB2 8.1 New Data Packages wrong Mar 31, 2004 21.08
DB2 8.1 Support with Packages Mar 31, 2004 23.09*
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
MQ Series 5.3 Dec 16, 2002 21.05
NETVIEW 3.1 type 37 ??? ??, 1996 14.03
NPM 2.0 Dec 17, 1993 12.03
NPM 2.2 Aug 29, 1994 12.05
NPM 2.3 ??? ??, 1996 15.08
NPM 2.4 Nov 18, 1998 17.01
NPM 2.5 Feb ??, 2000 18.02
NPM 2.6 Nov ??, 2001 19.06
RMDS 2.1, 2.2 Dec 12, 1995 12.12
RMDS 2.3 Jan 31, 2002 19.11
TCP/IP 3.1 Jun 12, 1995 12.12
TCP/IP 3.4 Sep 22, 1998 16.04
WebSphere 5.0 APAR PQ7463 Aug 19, 2003 21.04
WebSphere 6.0 Feb 18, 2006 23.23
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
z/VM 4.4 Jan 22, 2005 22.22
z/VM 5.1 Jan 22, 2005 22.22
IMS log 4.1 Jul 4, 1994 12.02
IMS log 5.1 Jun 9, 1996 14.05
IMS log 6.1 ??? ?, 199? 20.03
IMS log 7.1 ??? ?, 200? 20.03
IMS log 8.1 May 21, 2003 21.02
IMS log 9.1 Dec ??, 2004? 22.08
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
AS400 5.2.0 - Most records Jul 23, 2003 21.03
AS400 5.2.0 - QAPMMIOP Jul 23, 2003 22.04
AS400 5.3.0 Jan 22, 2005 22.22
Note: Asterisk before the version number means the Version number
was changed (to the MXG version required), after an earlier
MXG version was listed as supporting this product release,
usually because an APAR modified the product's 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
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
NTSMF 2.4.4 Aug 9, 2002 20.04
NTSMF 2.4.5 INCOMPAT Apr 1, 2003 21.02
NTSMF 2.4.7 Sep 30, 2004 22.08
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 CICS/ESA 2.2 - 20.335, 21.134 21.04
The Monitor for CICS/ESA 2.3 including cics/ts 3.1 22.08
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
The Monitor for MVS/ESA 3.1 - 21.02
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
NETSPY 6.0 20.10 20.305
NETSPY 7.0 20.10 20.305
SAR/VIEW R11 23.07 23.196
BMC, was 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
IMF 3.3 (for IMS 7.1 and 8.1) 22.08*
IMF 4.1 (for IMS 9.1) 22.08
Memorex/Telex
LMS 3.1 12.12A
Amdahl
APAF 4.1, 4.3 16.08
Velocity Software
XAMAP 3.4 22.10
II. Incompatibilities and Installation of MXG 23.09.
1. Incompatibilities introduced in MXG 23.09 (since MXG 22.22):
a- Changes in MXG architecture made between 23.11 and 22.22 that might
introduce incompatibilities.
ITRM Sites MUST add _STY70 invocation in their EXPDBOUT member.
See Change 23.321.
If you use MXG _VAR7072 and _CDE7072 in your own program to read
RMF 70s, you MUST now invoke _STY70 after your data step due
to MXG support for split SMF 70 records. Change 23.321.
2. Installation and re-installation procedures are described in detail
in member INSTALL (which also lists common Error/Warning messages a
new user might encounter), and sample JCL is in member JCLINSTL.
MXG Definitions with regard to MXG Software Changes:
COMPATIBLE A change in a data record which did not alter either
the location or the format of all of the previously-
kept MXG variables is COMPATIBLE, and you can continue
to run the old version of MXG software, which will read
the new records without error, but none of any new data
fields or any new record subtypes will be created/kept
until you install the MXG Version with this change.
A change that alters any previously kept variable is
INCOMPATIBLE, and requires the new version to be used.
TOLERATE In other words, the old MXG Version TOLERATES the new
data records, if they are COMPATIBLY changed.
EXPLOIT Once you use the new MXG Version to read the changed
records, all of the new fields, subtypes, etc, that are
described in this change will be created in the MXG
datasets, so the new MXG Version EXPLOITS the new data,
and you have full support of the new data records.
INCOMPAT A change in a data record that causes the current MXG
version to fail, visibly or invisibly, with or without
error conditions or messages, and the output datasets
may contain wrong values and incomplete observations,
and/or observations may have been lost.
You MUST install the new MXG Version with this change
to process data records that have been INCOMPATIBLY
changed by their vendor.
III. Online Documentation of MXG Software.
MXG Documentation is now described in member DOCUMENT.
See also member INDEX, but it may be overwhelming.
IV. Changes Log
--------------------------Changes Log---------------------------------
You MUST read each Change description to determine if a Change will
impact your site. All changes have been made in this MXG Library.
Member CHANGES always identifies the actual version and release of
MXG Software that is contained in that library.
The CHANGES selection on our homepage at http://www.MXG.com
is always the most current information on MXG Software status,
and is frequently updated.
Important changes are also posted to the MXG-L ListServer, which is
also described by a selection on the homepage. Please subscribe.
The actual code implementation of some changes in MXG SOURCLIB may be
different than described in the change text (which might have printed
only the critical part of the correction that need be made by users).
Scan each source member named in any impacting change for any comments
at the beginning of the member for additional documentation, since the
documentation of new datasets, variables, validation status, and notes,
are often found in comments in the source members.
_PAGE_ 8
Alphabetical list of important changes in MXG 23.11 after MXG 22.22:
Dataset/
Member Change Description
Typos 23.012 MXG 22.22 JCLTEST/MXGSASVn had error-causing typos.
ANALFIOE 23.074 FICON Open Exchange analysis includes CMR pend time.
ANALPATH 23.078 Path Activity Report includes CMR and OTH pend.
ASMHSCEX 23.177 ML-34 MXGTMNT GA, has ASMHSCEX for HSC mounts!!
ASMRMFV 23.243 Enhancement to RMF III VSAM Support
ASMTAPEE 23.177 ML-34 MXGTMNT GA, has ASMHSCEX for HSC mounts!!
ASMTAPEE 23.247 ML-36 is now available of MXGTMNT.
ASMTAPEE 23.300 ML-37 MXGTMNT monitor now captures SYSLOG messages
ASUM70PR 23.021 LP0xxxxx variables were not populated.
ASUM70PR 23.069 Short RMF interval impacts PDB.ASUMCEC.
ASUM70PR 23.071 PDB.ASUMCEC contains CEC total IFA CPU time
ASUM70PR 23.121 BY VARIABLES NOT SORTED corrected, PROC SORT added.
ASUM70PR 23.237 Variables NRIFACPU,NRIFLCPU added to PDB.ASUM70PR/CEC
ASUM70PR 23.289 RMF Intervals with DURATM less than one minute fix.
ASUM70PR 23.322 Support for 60 LPARs - INCOMPATIBLE
ASUMCACH 23.073 MODEL, taken from DEVMODEL, added to BY list.
ASUMDB2 23.319 Summary of DB2ACCT detail into interval buckets.
ASUMMIPS 23.126 RPRTCLAS added to identify Service/Reporting Classes.
ASUMTALO 23.104 Enhancement to summarize by "groups".
ASUMTALO 23.201 Condition Code (Return Code) 4 in ASUMTALO eliminated
ASUMTAPE 23.253 Initial rewrite of ASUMTAPE for TMNT/21 records only.
ASUMTAPE 23.300 Now merges SYSLOG, MXGTMNT, and IBM SMF 21s.
ASUMTMNT 23.104 Enhancement to summarize by "groups".
ASUMUOW 23.240 IRESPTM and ELAPSTM in PDB.ASUMUOW revised.
ASUMUOW 23.251 More robust definition of "TRANNAME" in PDB.ASUMUOW.
BUILD005 23.197 Hardcoded "SPIN" DD replaced by &SPINOUT.
BUILDPD3 23.282 BUILDPD3 now sets Condition/Return Code of zero.
BUILDPDB 23.124 Duplicate SMF 30 interval records duped in SMFINTRV.
CONFIGV9 23.061 SEQENGINE=V9SEQ now default in CONFIGV9 for 9.1.3.
FORMATS 23.144 "Expanded Length" format values revised logic for S2.
GRAFWLM 23.234 CPU Utilization graph by goal importance, Enrico's.
IMAC6ESS 23.008 Invalid ESS data caused INPUT STATEMENT EXCEEDED.
IMACICDA 23.190 Comments only. IMACICDA is not used with IMACEXCL.
INSTREAM 23.298 MXG 23.08 only: INSTREAM DD was required, not now.
MACKEEP 23.346 DB2 Tailoring Example to add DB2 102 to PDB.
MONTHxxx 23.351 &MXGSYSN macro variable for compatibility.
MXGABND 23.184 New %LET MXGABND=nnnn forces ABEND for CICS errors.
READDB2 23.249 OBID and DBID are decoded in DB2 102 Trace datasets.
READDB2 23.287 Selective creation of DB2 datasets and data now easy.
READDB2 23.345 New WANTONLY= enhancement for %READDB2 utility.
RMFINTRV 23.071 IFA CPU time added to PDB.RMFINTRV
RMFINTRV 23.123 CPUIFATM/IFE and BATIFA,CICSIFA,etc now in RMFINTRV.
RMFINTRV 23.265 23.05-23.07. IFA/IFE CPU times zero in RMFINTRV wkld.
TESTIBM1 23.281 MXG 23.08 only. ERROR: File WORK.TYPE791.DATA does ..
TRNDxxxx 23.293 New &INTTRND can change default INTERVAL=WEEK in TRND
TYPE102 23.056 Dataset T102S199 was incorrect; only first seg output
TYPE102 23.131 Support for DB2 IFCID=313 creates T102S313 dataset.
TYPE102 23.160 Many new variables added to T102S106 dataset.
TYPE1023 23.231 Support for DB2 IFCIC 225.
TYPE110 23.077 CICS STAT RECORD STID=106 message.
TYPE110 23.342 Support for CANDLE UMBRELLA optional CICSTRAN data.
TYPE115 23.347 Support for MQ for z/OS Version 6.0 (COMPAT)
TYPE116 23.049 MQM variable QWHCCV QWHSSSID renamed.
TYPE119 23.146 Support for new FTP Server Security Section in st 70.
TYPE120 23.164 Support for PQ96144, SM120JHF/JHT corrected.
TYPE22 23.175 Support for subtype 11 I/O Configuration Change
TYPE26J2 23.277 New UNSPUNJB, JOEPURGE status variables created.
TYPE26J3 23.282 HIPER: 23.02-23.08, JES3 only. No obs in TYPE26J3.
TYPE30 23.101 Support for APAR OA10901, SMF30ZNF zAAP noralize fact
TYPE30 23.292 Support for APAR OA11675, EXCPTOTL max now 4 gig.
TYPE30 23.296 TYPE30_6 RESIDTM/ACTIVETM wrapped after 51 days.
TYPE30 23.329 Support for SMF30CEPI field, new CPUCIPTM variable.
TYPE30_V 23.334 IMACINTV default now OUTPUTs TYPE30_V/PDB.SMFINTRV.
TYPE6 23.091 Printway File Transfer, z/OS 1.6 from VPS corrected.
TYPE6 23.120 Support for ESS GEPARMKY=004Dx variable ESSMAIL2.
TYPE6 23.159 PSF SMF 6 with SMF6LN6=24 another INPUT EXCEEDED.
TYPE6 23.284 Print accounting for "Printway" tcp/ip SMF 6 records.
TYPE6156 23.219 ICF Catalog 05 record GATGEN and GATWRAP corrected.
TYPE70 23.270 PCTIFBYn variables restored to TYPE70 dataset.
TYPE70 23.330 Corrections to Split 70/Over 60 LPAR Change 23.321.
TYPE70 23.348 Final "70's Record Rewrite", OS/390 support!
TYPE7072 23.013 LPARCPUX kept in TYPE70PR for count of reserved CPs
TYPE7072 23.070 Correction for IBM inability to have STARTIME right.
TYPE7072 23.083 Variable NRCPUD, CPU segments this MVS, added.
TYPE7072 23.186 Support for z9 CPU, new CPUTYPE='2094'x, INCOMPAT.
TYPE7072 23.187 Support for APAR OA10346 adds LPAR User Partion ID.
TYPE7072 23.306 PARTNCPU final correction for z9 microcode error.
TYPE7072 23.321 Support for Split RMF 70 Records: INCOMPATIBLE
TYPE7072 23.322 Support for 60 LPARs - INCOMPATIBLE
TYPE7072 23.335 Variables SMF70OIL and SMF70SYN now KEPT in TYPE70.
TYPE70PR 23.288 BMC SMF 70 from z9 have LPARCPUX=0, counts wrong.
TYPE73 23.072 Support for APAR OA09921 IBM TotalStorage DS6000.
TYPE74 23.029 AVGxxxMS variables now FORMAT 6.3.
TYPE74 23.093 Support for Type 74 subtype 8 corrected.
TYPE78SP 23.064 TYPE78SP only had below-16MB subpool variables.
TYPE79 23.268 RMF 79 subtype 9 records are now validated/corrected.
TYPE80A 23.006 Support for many new RACF events.
TYPE80A 23.066 Support for RACF Events 27, 28, 29 for unix.
TYPE80A 23.134 Unexpected RACF TOK80LN2=0 record was deleted.
TYPE80A 23.135 Support for Top Secret Versions 5.2 and 5.3.
TYPE80A 23.275 Support for CA TopSecret 103-105,109,255 SMF80DTPs.
TYPE82 23.242 Support for SMF type 82 subtypes 20 and 21 added.
TYPE88 23.213 All SMF88xxx datetime variables are now local zone.
TYPE89 23.183 Support for APAR OA11036 added MACHTIME to SMF 89.
TYPE90A 23.081 WLM Service Policy new name tracked in TYPE9024.
TYPE99 23.169 Support for SMF 99 Subtype 2 additional segments.
TYPEBE91 23.311 Support for Beta 91 Version 3.1.1.0, INCOMPATIBLE.
TYPECMF 23.136 Support for 2180 RAID RANK data in CMF user record.
TYPECSF2 23.024 CONTROL-D SF2 records INCOMPATIBLY changed.
TYPECYFU 23.020 Support for CyberFusion user SMF record.
TYPECYFU 23.139 Support for CyberFusion user SMF record validated.
TYPEDB2 23.011 DB2 QWHT/QWHU/QWHD/QWHA could be blank/missing.
TYPEDB2 23.082 QWHSLOCN CONTAINS UNICODE TEXT message
TYPEDB2 23.098 Support for DB2 V8.1 restructured Package Data.
TYPEDB2 23.111 Support for DB2 V8.1 Package Data INCOMPATIBLE.
TYPEDB2 23.140 REQUIRED FOR DB2 V8.1 More IBM INCOMPATIBLE CHANGES.
TYPEDB2 23.181 DB2ACCTP data was still wrong for DB2 V8.1, fixed.
TYPEDB2 23.235 DB2TCBTM in DB2ACCT obs with DB2PARTY='R' was wrong.
TYPEDB2 23.280 DB2ACCTP Package Data required fix (final, trunc!).
TYPEDB2 23.295 DB2ACCTG dataset didn't contain nine QBGA variables.
TYPEENDV 23.236 Support for Endeavor Release 7; no changes.
TYPEEREP 23.228 INPUT STATEMENT EXCEEDED for IBM ATL record.
TYPEHSM 23.179 All byte-containing HSM variables FORMATed MGBYTES.
TYPEIMS 23.099 Support for IMS Version 9.1 was already in MXG 22.22
TYPEIPAC 23.223 Support for Mobiud/IPAC Rel 6.3 INCOMPATIBLE.
TYPEIWAY 23.133 Support for Iway Software's IWAY (aka EDA/SQL) SMF.
TYPEMGCR 23.200 Support for MegaCryption's user SMF record
TYPEMPLX 23.027 Support for IMPLEX Versions 3.1 and 3.3
TYPEMPLX 23.143 IMPLEX subtype 4 revised, validated.
TYPEMVCI 23.166 Support for additional CMRFILE fields in CMRDETL.
TYPEMWSU 23.254 ADOCMWSU for HP MeasureWare on Sun was updated.
TYPENDM 23.001 INPUT STATEMENT EXCEEDED for NDM subtype 'SY'.
TYPENDM 23.227 NDMCPUTM in NDMCT is now deaccumulated and correct.
TYPENDM 23.291 Support for CDI/NDM subtypes HW and NM.
TYPENDM 23.331 Support for NDM/Connect Direct subtype TF, TL, TW.
TYPEPRPR 23.142 Support for Oce's Prisma Print log file.
TYPEQACS 23.007 CPU variables in QAPMJOBL were incorrect.
TYPERMFV 23.080 RMF III data for IFAs added to ZRBASI, ZRBENC
TYPESAMS 23.004 Support for SAMS Vantage "LSPACE" record subtype.
TYPESAMS 23.172 SAMS POOLS record INCOMPATIBLY CHANGED.
TYPESARR 23.196 Support for CA SAR/VIEW R11, INCOMPATIBLY CHANGED.
TYPESTC 23.022 Support for VSM subtype 20, problems with ST 4.
TYPESTC 23.125 Support for HSC V6 changes to STCLMU subtype 4 SMF.
TYPESTC 23.279 Support for STK VTCS 6.0 and 6.1 SMF records (COMPAT)
TYPESYNC 23.163 New "SMS" UCB Address caused INVALID ARGUMENT error.
TYPESYSI 23.258 Support for CA SYSVIEW IMS user SMF records.
TYPESYSV 23.137 Support for CA SYSVIEW CICS data in XPFCMCR,XPFCSDCR.
TYPETHST 23.076 BMC THRDHIST file contains invalid package records.
TYPETMNT 23.300 New TYPESYMT, TYPESYSL datasets from SYSLOG messages.
TYPETMO2 23.100 TMON for CICS/TS V2.3 for CICS/TS 3.1. No Changes.
TYPETMS5 23.045 Support for TMS Release 11 - no changes.
TYPETMS5 23.229 Support for DEVTYPE='3592' devices in CA-1.
TYPETMVS 23.294 TYPETMVS CIJN and other CI variables INCOMPAT.
TYPETNG 23.113 Zero observations with a Solaris cube.
TYPETNG 23.193 Support for TNG AIX CA PROCESS GROUP (PID) object.
TYPETPFC 23.199 Support for TPF Continuous Data Collection TPFCDC.
TYPETPFC 23.324 TPF Continuous Data rate variables now calculated.
TYPEVM 23.285 Support for VM Account optional YYMMDD date format.
TYPEVMXA 23.050 z/VM VXBYUSR CPU and DELTATM corrected.
TYPEVMXA 23.060 Support for z/VM 5.1 enhanced: all new data supported
TYPEVMXA 23.128 z/VM 5.1 record 1.19 misdocumented, caused ERRORs.
TYPEVMXA 23.269 z/VM MONWRITE dataset VXSYTEMP is now validated.
TYPEVMXA 23.290 z/VM MONWRITE VXSYTEPM dataset finally correct.
TYPEVMXA 23.332 Variables HFLLIST,HFPGACT were accumulated.
TYPEWWW 23.026 Zero length URIQVALU caused INVALID ARGUMENT.
TYPEWWW 23.233 Enhancement/corrections to Web Log support.
TYPExxxx 23.052 New EOdddddd, _Odddddd MXG architecture enhancements.
UTILBLDP 23.036 CC=4 with BUILDPDB=NO eliminated, now CC=0.
UTILBLDP 23.057 Enhanced; USERADD supports SMF record number.
UTILBLDP 23.087 EXPDBOUT= a %INCLUDE failed when output executed.
UTILCONT 23.025 Failed if DISP=NEW dataset was contented.
UTILEXCL 23.075 CMODNAME=RMI,CMODHEAD=DB2CLOCK didn't generate skip.
VGETDDS 23.244 Using VGETDDS to get all DDNAMES can fail.
VGETENG 23.298 MXG 23.08 only: FILE INSTREAM IN USE.
VGETJESN 23.096 Blank TYPETASK in TYPE30_6 data, STCs, corrected.
VMXG70PR 23.276 PDB.ASUMCEC PCTL0OV,LP0MGTTM,LPCT0OV were zero.
VMXGDUR 23.239 Support for DURATM keywords TENMIN and FIVEMIN.
VMXGFOR 23.127 Semi-colon at end of macro invocation in AUTOCALL.
VMXGUOW 23.017 Default IMACUOW in 22.22 caused NO BY error.
%VMXGVERS 23.005 New %VMXGVERS member embedded to detect old versions.
WEEKBLD 23.246 Support for adding un-sorted datasets to WEEKLY PDB.
WEEKxxx 23.015 Sort Order for SMFINTRV must be changed
WEEKxxx 23.351 &MXGSYSN macro variable for compatibility.
Inverse chronological list of all Changes:
NEXTCHANGE: Version 23.
====== Changes thru 23.358 were in MXG 23.23 dated Feb 20, 2006=========
Change 23.358 Support for WebSphere Application Server z/OS Version 6.0
VMAC120 compatibly added 8-byte fields to replace 4-byte fields
Feb 18, 2006 in the Server Activity CSS and Server Interval SIL data.
MXG stores the new data into the existing variable names,
which were already formatted MGBYTES and thus kept long.
Thanks to Victoria Lepak, Aetna, USA.
Change 23.357 Macro variable "SYSNAME" is renamed "MXGSYSN" as SAS has
DOC recommended (SN-012275) that "SYS" not be used as a macro
Feb 18, 2006 variable name's prefix. Only sites with duplicate SYSTEM
names in the same SYSPLEX will need to change the default
value (blank) to "SYSNAME" as noted in Change 23.351.
Those sites could simply put this statement
%LET MXGSYSN=SYSNAME;
in their IMACKEEP member so their WEEKLY/MONTHLY will use
SYSNAME in its BY processing.
Thanks to Chuck Hopf, MBNA, USA.
Change 23.356 Cosmetic, unless you are running a non-PR/SM system. The
VMAC7072 recalculation of CPUUPTM and CPUACTTM used the PR/SM vars
Feb 17, 2006 and overwrote the just-finished non-PR/SM calculation.
Thanks to Douglas C. Walter, CITIGROUP, USA.
Change 23.355 Enhancement to DB2PM-like reports, adds CONNTYPE= option
ANALDB2R for selection criteria for Accounting Detail (PMACC02).
Feb 17, 2006 For example, CONNTYPE=4, selects only CICS connections.
Thanks to John Paul, HighMark, USA.
Change 23.354 MXG 23.23 PreRel; variable PARTNCPU, the count of engines
VMAC7072 in the box/partition, could be too large, if you have ICF
Feb 17, 2006 or IFA engines, in some cases. The test to use SMF70BNP
Feb 19, 2006 instead of NRCPSCPU (temp count PHYSICAL CPs) was added
to protect sites that won't let an LPAR see its physical
segments, was replaced with IF NRCPSCPU GT 0 instead of
comparing IF PARTNCPU GT NRCPSCPU.
-Feb 19: NRCPSCPU was removed from a DROP statement where
it didn't belong, but it is NOT a kept variable.
-Apr 7: How do you cause SMF 70s to not have a PHYSICAL
LPAR segment, and not report on other LPARs?
On the HMC, there is a Global Performance Data
Control switch, which controls the amount of data
returned by the Diagnose instruction RMF uses to
obtain CPU utilization information; if not on,
the RMF 70s will contain only information on this
SYSTEM, and there will be no PHYSICAL segments.
Thanks to Stan Adriaensen, Axa-Tech Belgium GIE, BELGIUM.
Thanks to Scott Barry, SBBWorks, USA.
Change 23.353 Support for OCE Prisma Ser5ver Version 3.04 added new
FORMATS data, compatibly, to their user SMF records, and new
VMACPRPR values for the existing MGPRPRA format, in this perfectly
Feb 17, 2006 written user contribution update.
Thanks to Siegfried Trantes, IDG, GERMANY.
Thanks to Willi Weinberger, IDG, GERMANY.
Change 23.352 Short ML-36 SYSLOG record caused INPUT STATEMENT EXCEEDED
VMACTMNT error for the subtype 8 record. ASMTAPEE at ML-38 fixes
Feb 16, 2006 the short record, and VMACTMNT now tests SYSLLEN before
it inputs the MSGID fields in the captured SYSLOG event.
Thanks to Keith McWhorter, Georgia Technology Authority, USA.
====== Changes thru 23.351 were in MXG 23.23 dated Feb 15, 2006=========
Change 23.351 Change 23.336 had to change the RMF dataset sort order to
MONTHASC BY SYSPLEX SYSTEM SYSNAME STARTIME ....
MONTHBL3 by inserting SYSNAME, but if SYSNAME does not exist in an
MONTHBLD old PDB, your weekly/monthly/etc combining job fails with
MONTHBLS ERROR: BY VARIABLE SYSNAME NOT FOUND ON INPUT DATA ...
MONTHDSK While MXG must use SYSNAME in its logic, only sites with
VMXGINIT duplicate SYSTEM names actually need SYSNAME in their
WEEK70PR BY list for their weekly/monthly jobs, so this change:
WEEKBL3 - defines macro variable &MXGSYSN, with blank value
WEEKBL3D - uses &MXGSYSN in BY statements for post processing of
WEEKBL3T daily/weekly/monthly datasets.
WEEKBLD With the blank default, then your weekly/monthly jobs
WEEKBLDD will not fail when old/new RMF datasets with/without the
WEEKBLDT SYSNAME variable are combined.
Feb 15, 2006 If you have duplicate SYSTEM names, then when all of
Feb 18, 2006 the input datasets to the week/month merge contain
variable SYSNAME, you would then use this statement
%LET MXGSYSN=SYSNAME;
%INCLUDE SOURCLIB(Weekbld, monthbld, ... etc);
Feb 18: The PreRelease use macro variable "SYSNAME" but
Change 23.357 changed it to MXGSYSN.
Change 23.350 Labels for variables DSxTCBAF are now "ATTACH*FAILURES"
VMAC110 instead of "ATTACHES".
Feb 15, 2006
Thanks to Don Deese, (CPExpert), Computer Management Sciences, USA.
Change 23.349 The exit _EPDBOUT is again invoked when BUILDPDB=NO; it
UTILBLDP had been in MXG 22.22, but was lost along the way. Note,
Feb 15, 2006 however, that EXPDBOUT=_EPDBOUT and BUILDPDB=YES can not
Feb 16, 2006 be used together, and a new warning message will be print
if they are both specified.
-Feb 16, 2006: Revised so EXPDBOUT= argument is now always
created either when BUILDPDB=YES is used or if EXPDBOUT
argument is non-blank.
Thanks to Scott Barry, SBBWorks, Inc, USA.
Thanks to Robbie A. McCoy, Salt River Project, USA.
Change 23.348 Final (?) "70's Record Rewrites" change, for OS/390 R2.1!
VMAC7072 The last error in validation was caused by really old RMF
VMXG70PR records from OS/390 R2.1 that didn't have SMF70CIN field,
VMXGRMFI which caused PARTNCPU to be zero. The revision uses the
Feb 14, 2006 value in SMF70BNP when SMF70CIN is not populated.
-PROC DELETEs were added for a few WORK datasets that were
not deleted after their last use, but now are.
Thanks to Dr. Alexander Raeder, AtosOrigin, GERMANY.
Change 23.347 Support for Websphere MQ for z/OS Version 6.0 (COMPAT).
VMAC115 -Added compatibly, i.e., at end of SMF 115 records:
VMAC116 Data Set MQMMSGDM new sets of duration variables:
Feb 14, 2006 LMSDEL ='DB2 BLOB*DELETE*REQUESTS'
LMSDSCUW='DB2 BLOB DELETE*SQL DELETE*CUM-TM'
LMSDSMXW='DB2 BLOB DELETE*SQL DELETE*MAX-TM'
LMSDTCUW='DB2 BLOB DELETE*THREAD DELETE*CUM-TM'
LMSDTMXW='DB2 BLOB DELETE*THREAD DELETE*MAX-TM'
LMSINS ='DB2 BLOB*INSERT*REQUESTS'
LMSISCUW='DB2 BLOB WRITE*SQL DELETE*CUM-TM'
LMSISMXW='DB2 BLOB WRITE*SQL DELETE*MAX-TM'
LMSITCUW='DB2 BLOB WRITE*THREAD DELETE*CUM-TM'
LMSITMXW='DB2 BLOB WRITE*THREAD DELETE*MAX-TM'
LMSLIS ='DB2 BLOB*LIST*REQUESTS'
LMSLSCUW='DB2 BLOB LIST*SQL DELETE*CUM-TM'
LMSLSMXW='DB2 BLOB LIST*SQL DELETE*MAX-TM'
LMSLTCUW='DB2 BLOB LIST*THREAD DELETE*CUM-TM'
LMSLTMXW='DB2 BLOB LIST*THREAD DELETE*MAX-TM'
LMSSEL ='DB2 BLOB*READ*REQUESTS'
LMSSSCUW='DB2 BLOB READ*SQL DELETE*CUM-TM'
LMSSSMXW='DB2 BLOB READ*SQL DELETE*MAX-TM'
LMSSTCUW='DB2 BLOB READ*THREAD DELETE*CUM-TM'
LMSSTMXW='DB2 BLOB READ*THREAD DELETE*MAX-TM'
LMSUPD ='DB2 BLOB*UPDATE*REQUESTS'
LMSUSCUW='DB2 BLOB UPDATE*SQL DELETE*CUM-TM'
LMSUSMXW='DB2 BLOB UPDATE*SQL DELETE*MAX-TM'
LMSUTCUW='DB2 BLOB UPDATE*THREAD DELETE*CUM-TM'
LMSUTMXW='DB2 BLOB UPDATE*THREAD DELETE*MAX-TM'
A BLOB object is used to access binary large objects
(BLOBs), such as sound byte (wav) or image (gif) file,
using the DB2Blob interface with Java 2. With the BLOB
class, the LOB threshold property specifies the maximum
large object (LOB) size (in kilobytes) retrieved as
part of a result set. LOBs over that threshold are
retrieved in pieces, requiring communications overhead
with the server, so they can reduce the frequency of
communications, but they also download more LOB data,
that unwanted data that was never used. Smaller LOBs
may increase the frequency of communications with
server, but may move much wasted data.
-Added compatibly, i.e., at end of SMF 116 records:
Data Set MQMACCTQ:
WTASVER ='WTAS*VERSION*NUMBER'
WTASDBPT='WTAS*DB2 BYTES*WRITTEN'
WTASDBGT='WTAS*DB2 BYTES*READ'
Data Set MQMQUEUE:
WQFLAGS '=FLAGS'
WQGETDVA'=SUCCESSFUL DESTRUCTIVE GETS'
WQGETJCE'=ELAPSED WAIT*FOR FORCE*JOURNAL GETS'
WQGETJCN'=NUMBER OF FORCE JOURNAL GETS'
WQMAXQDP'=MAXIMUM ENCOUNTERED QUEUE DEPTH'
WQPUT1JE'=ELAPSED WAIT*FOR FORCE MQPUT1*JOURNAL WRITES'
WQPUT1JN'=FORCE MQPUT1 JOURNAL WRITES
WQPUT1PW'=MQPUT1 CALLS WHERE MSG PASSED'
WQPUTJCE'=ELAPSED WAIT*FOR FORCE*JOURNAL WRITES'
WQPUTJCN'=FORCE JOURNAL WRITES'
WQPUTPWG'=NUMBER OF MQPUT CALLS WHERE MSG*PASSED'
WQSETJCE'=ELAPSED WAIT*FOR SET'
WQSETJCN'=NUMBER OF SET'
Thanks to Victoria Lepak, Aetna, USA.
Change 23.346 Documentation example; to add DB2 102 records to BUILDPDB
IMACKEEP and to create the T102S022 T102S044 T102S063 datasets and
Feb 13, 2006 copy them into the //PDB library you would use:
%LET MACKEEP=%QUOTE(
MACRO _CDEUSER
_HDR102 _C102022 _C102044 _C102063 _C102105 _END102
%
MACRO _VARUSER
_V102022 _V102044 _V102063 _V102105
%
);
%LET EPDBOUT=%QUOTE(
RUN;
PROC COPY INDD=WORK OUTDD=PDB;SELECT T102: ;
RUN;
);
%INCLUDE SOURCLIB(VMAC102);
%INCLUDE SOURCLIB(BUILDPDB);
We're not sure why both RUN; statements are required, but
the PROC COPY doesn't execute without them.
Thanks to Ricci Hsial, China Trust, TAIWAN.
Change 23.345 Enhancement for the %READDB2 utility to read DB2 records.
READDB2 New WANTONLY option lets you create observations only in
Feb 13, 2006 selected datasets, with sub-options to DROP or KEEP the
variables you want in that dataset, and logic to choose
which observations are output. See documentation in the
comments, but for example.
%READDB2(IFCIDS=ACCOUNT,WANTONLY=DB2ACTB,
DB2ACTB=YES/IF QBACGET GT 0);
would create observations only in the DB2ACCTB dataset,
and only if the observation had non-zero GETS count.
Change 23.344 The KEEP= list for dataset FICON73 needed SYSNAME added,
ANALFIOE as a result of the RMF changes in MXG 23.11.
Feb 10, 2006
Thanks to Brian Crow, British Telecom, ENGLAND.
Change 23.343 MXG 23.11. PDB.TYPE72GO NOT SORTED. Several BY statements
VMXGRMFI had only BY SYSPLEX SYSNAME STARTIME; but the correct BY
Feb 10, 2006 list is BY SYSPLEX SYSTEM SYSNAME STARTIME;. This error
only occurred when SYSTEM and SYSNAME were not the same.
Thanks to Paul Naddeo, FISERV, USA.
====== Changes thru 23.342 were in MXG 23.23 dated Feb 9, 2006=========
Change 23.342 Support for more Optional CICSTRAN "Candle" CICS fields
IMACICD9 Field/Variable Label IMAC
IMACICC1 CANFLAGS CANDLE*UMBRELLA*FLAGS IMACICD9
IMACICC2 CANGMTOF CANDLE*GMT*OFFSET IMACICC1
IMACICC3 CANUMBTR CANDLE*UMBRELLA*TRANID IMACICC2
IMACICC4 CANUMBUS CANDLE*UMBRELLA*PROGRAM IMACICC3
UTILEXCL CANUSRWK CANDLE*UMBRELLA*USER*WORKAREA IMACICC4
VMAC110 The UTILEXCL program must be used to create a tailored
Feb 8, 2006 IMACEXCL member, and the UTILEXCL output tells you which
Feb 15, 2006 of the IMACICxx members also must be EDITed to create the
optional variable(s) in the CICSTRAN dataset.
Thanks to John Shuck, SunTrust, USA.
Change 23.341 CICS Statistics dataset CICSJR variable SJRPRXMX, the XMX
VMAC110 value, was read as an 8-byte binary value, but the field
Feb 5, 2006 contains either blanks or '32M ' in EBCDIC text, and
reading text fields as binary gets large values:
input field read as binary decimal exponential
8-bytes of blanks 4.6*10**18
'F3F2'x -32- in first bytes 17.5x10**18
4-bytes of hex FFx 4,294,967,294 4x10**9
4-bytes of FFx 1,077,952,576 1x10**9
Now, new character variable SJRPRXCH is the text field,
which is parsed and decoded into the original numeric
variable SJRPRXMX, now formatted MGBYTES.
Thanks to Don Deese, (CPExpert), Computer Management Sciences, USA.
====== Changes thru 23.340 were in MXG 23.11 dated Feb 2, 2006=========
Change 23.340 MXG support for Omegamon for DB2 Archive file records.
VMACOMDB -A short IFCID 44 record caused INPUT STATEMENT EXCEEDED;
Feb 2, 2006 the record was only 350 bytes, and contained none of the
actual IFCID 44 data fields; MXG now INPUTs the first 350
and tests to see if there is any more before INPUTing.
-IFCID 63 had a fixed INPUT of $5000 for the SQL text,
which caused INPUT STATEMENT EXCEEDED error when there
was a shorter text. This statement was taken as-is from
Candle's SAS code in 2003, but apparently no IFCID 63
data had been tested before by an MXG user or Candle!
The MXG logic now INPUTs using VARYING informat
Thanks to Rosaline E. Howe, IBM Global Services, USA.
Change 23.339 -Harmless DIVIDE BY ZERO because TOTSHARC was not tested
VMAC7072 to be non-zero, but results are still fine; the variables
Feb 2, 2006 LPARSHAR and LPARSHAC will be missing when TOTHARC=0.
-SHIFTHRS references in DROPs removed as it doesn't exist.
-Missing labels, and other RMFINTRV cosmetics cleaned
-TEST70SP did not include VMXGRMFI for NEWRMFI compare,
which caused many false positive comparison differences.
Thanks to Bruce Widlund, Merrill Consultants, USA.
Thanks to Chris Weston, SAS ITRM Cary, USA.
====== Changes thru 23.338 were in MXG 23.11 dated Feb 2, 2006=========
Change 23.338 ML-38 of MXGTMNT, Tape Mount/etc Monitor program adds new
ASMTAPEE event trace to the STK user exit in ASMHSCEX; we now have
ASMHSCEX excellent cooperation with STK developers who are working
Feb 1, 2006 with "asmguy" to install ML-38 at STK so we can diagnose
why we miss so many mounts in that user exit.
-ASMTAPEE corrects MXGC009E Unrecoverable error messages;
the error was introduced back in ML-30 with the Volume
mount enhancement, but only one site has reported only
two instances, and it was with ML-37.
-ML-38 also corrected 0C4 ABEND during processing of an
IEC6000I reply message in offline device allocation.
This note added Feb 21.
Thanks to Keith McWhorter, Georgia Technology Authority, USA.
Change 23.337 Missing values for these PR/SM variables in PDB.RMFINTRV
VMAC7072 PLATBUSY,PLATCPUS,TOTSHARE,TOTSHARC,LPARSHAR,LPARSHAC
VMXG70PR can occur, even with Jan 31 MXG 23.11, but only if there
VMXGRMFI were short intervals, as when an LPAR is started/stopped,
Feb 2, 2006 or as when a Policy Change is issued, which wrote two
short intervals (an 8:45 STARTIME with a 2 minute DURATM,
an 8:47 STARTIME with 13 minute DURATM).
-Previously, those variables were extracted by ASUM70PR
from PDB.ASUM70PR dataset and merged into PDB.RMFINTRV;
however the rewrite in Change 23.322 to ASUM70PR uses the
SMF70GIE time interval (9:00 in the above example),
but the PDB.RMFINTRV is created for each of the STARTIME
values, so all of the old logic was moved from VMXG70PR
into the VMAC7072 and VMXGRMFI members.
-So: ASUM70PR no longer updates PDB.RMFINTRV.
-This, too, was not a trivial revision.
The biggest difficulty with this change was validation;
these short intervals created invalid data in the old
ASUM70PR/ASUMCEC datasets, which now have fewer obs than
the old MXG version, so this change was filled with false
positive differences in the PROC COMPARE output!
Thanks to Diane Eppestine, AT&T Services, Inc, USA.
====== Changes thru 23.336 were in MXG 23.11 dated Jan 31, 2006=========
Change 23.336 Support for RMF with repeated SYSTEM names in a SYSPLEX.
VMAC7072 Variable SYSNAME (SMF70SNM) was inserted in the BY list
VMXG70PR for all RMF-based datasets. These RMF records all have
VMXGRMFI the same value in variable SYSTEM, but SYSNAME is unique
ANALRMFR to each system and must be used to separate them. Test
VMAC7072 data's SYSTEM was different from each of the two SYSNAME
ADOC7xxx values. The new RMF sort order is changed to:
ANALRMFR BY SYSPLEX SYSTEM SYSNAME STARTIME .... ;
Jan 29, 2006
ANALRMFR This change in sort order should have NO impact if you
VMAC70PR have no repeated SYSTEM names in a SYSPLEX. By putting
VMXG70PR SYSNAME to the right of SYSTEM, merges with old MXG data
Jan 31, 2006 (that were sorted BY SYSPLEX SYSTEM STARTIME...) won't
be impacted, and your report code with logic testing for
FIRST.SYSTEM or LAST.SYSTEM won't be impacted.
INCOMPATIBILITY:
ONLY if you have multiple SYSTEM names in a SYSPLEX do
you need to deal with this changes. You MUST revise BY
statements in your report programs, inserting SYSNAME
after SYSTEM, and using SYSNAME instead of SYSTEM in
reports. Tests for FIRST.SYSTEM or LAST.SYSTEM must be
changed to FIRST.SYSNAME or LAST.SYSNAME in your code.
But without this change, these multiple SYSTEM names
created incorrect output, without any error messages.
You might think having repeated SYSTEM names is dumb, but
it is useful for Disaster Recovery LPARs, and can avoid
changing SYSTEM in JCL, etc., when moving a SYSTEM to a
SYSPLEX that already has a SYSTEM with that same name.
Some initial revisions were made to ANALRMFR, but they
are still being validated, and those reports will be
enhanced to support selection by SYSNAME or SYSTEM.
Full list of members changed by this change:
ACHAP35 ADOC7072 ADOC70PR ADOC71 ADOC73 ADOC74
ADOC75 ADOC76 ADOC77 ADOC78 ADOC89 ADOCPDB
ANALDALY ANALFIOE ANALMPL ANALPGNS ANALRMFI ANALRMFR
ANALSRVC ANALSTOR ASUMMIPS DOCMXG GRAFWORK GRAFWORX
GRAFWRKX JCLQAOLD MONTHASC MONTHBL3 MONTHBLD MONTHBLS
MONTHDSK QASAS TEST70SP TRNDRMFN VMAC7072 VMAC71
VMAC75 VMAC76 VMAC77 VMXG70PR VMXGRMFI WEEKBL3
WEEKBL3D WEEKBL3T WEEKBLD WEEKBLDD WEEKBLDT
These changes are in the MXG 23.11 dated Jan 31, 2006:
Jan 31 updates (hooray - no critical changes!!):
-ANALRMFR: revised, not DROP SYSNAME after SHAR74).
-VMAC7072: cosmetic removal of duplicate SYSNAME in KEEP=
in several places, eliminated NOTE on log.
-VMXG70PR: variable SMF70GIE now kept in RMFINTRV.
-If _STY70 is executed twice, you will get an ABEND and
ERROR: DATASET WORK.TYPE70SP NOT FOUND
That error is intended, as it alerts you that your
program has caused that macro to be executed a second
time. Please rerun with
OPTIONS SOURCE SOURCE2 MACROGEN MPRINT;
and send the full log to support@mxg.com so we can
understand what you were doing that is incompatible with
the new MXG redesign.
-VMAC73: variable SYSNAME was added to KEEP= list for the
always-zero-obs TYPE73L,TYPE73P datasets; WEEKBLD etc
need those variables because they are in the BY list,
even though those datasets have not had observations for
decades. (And I can't safely stop creating them, as
that can only cause somebody's report program to fail.)
Thanks to Al Sherkow, I/S Management Strategies, Ltd., USA.
Thanks to Alain Delaroche, CA-Atlantica, FRANCE.
Thanks to Chris Weston, SAS ITRM Cary, USA.
Change 23.335 Variables SMF70OIL and SMF70SYN are added to dataset
VMAC7072 TYPE70; they have always been INPUT but were not kept.
Jan 27, 2006 SMF70OIL='ORIGINAL*INTERVAL*LENGTH'
SMF70SYN='SYNC*VALUE'
Thanks to Al Sherkow, I/S Management Strategies, Ltd., USA.
Change 23.334 MXG's unwise default to NOT create observations from type
IMACINTV 30 subtype 2/3 records is finally changed so that now,
INSTALL observations will always be output into TYPE30_V dataset,
Jan 26, 2006 if the SMF file contained SMF 30 subtype 2/3 records.
-Always use PDB.SMFINTRV, created by BUILDPDB and NOT the
"raw" TYPE30_V dataset, nor the PDB.SMFINTRV created by
TYPS30 program; those other "PDB.SMFINTRV/TYPE30_V" data
sets still have incomplete data because they still have
those multiple observations if MULTIDD='Y'. Only MXG's
BUILDPB logic combines the multiple TYPE30_V obs into
a single complete observation in PDB.SMFINTRV.
-The default was unwise because many new users have wasted
their time and were frustrated when they got no output,
and wasted more time looking for what they had done wrong
OK, they had done something wrong: they had failed to
read (and understand the impact of) every word in the
INSTALL member, which is where I documented that zero
obs would be created by default!
-I originally chose to not write the interval record when
they first appeared in 1980, because I was concerned for
the additional disk space that might blind-side your fine
running daily job, and because back then they weren't
sychronized with time of day, and were not of much use.
-Now, however, PDB.SMFINTRV is synchronized, so you can
create legitimate interval sums of all tasks to compare
with RMF, and potentially use in place of PDB.RMFINTRV
for workload measurement, and it so important that it is
normally created by everyone, and so I could have saved
many support calls if I'd changed the default a long time
ago. And, the cost of a little of DASD space is still a
lot cheaper than the cost of the beginner's time and
frustration, so it now is populated by default.
Change 23.333 Cosmetic. Missing Value calculations when OFFWQ was a
VMAC116 missing value; now, OFFQW is tested first so those log
Jan 26, 2006 messages are eliminated.
Change 23.332 Variables HFLLIST and HFPGACT are accumulated in the raw
VMACVMXA z/VM MONWRITE data, but were not de-accumulated in MXG.
Jan 25, 2006 Logic to use DIF() was added to properly decode and
Feb 1, 2006 convert them to percentages.
Feb 1: typo HFLPGACT corrected to HFPGACT
Thanks to Kris Ferrier, State of Washington DIS, USA.
Thanks to Bruce Widlund, Merrill Consultants, USA.
Change 23.331 Support for NDM/Connect-Direct subtypes TF, TL, and TW
EXNDMTX (TCQ Full, TCQ Below Threshold, or TCQ At Threshold)
IMACNDM create observations in the new NDMTX dataset.
VMACNDM
VMXGINIT
Jan 25, 2006
Thanks to David Kaplan, Depository Trust, USA.
Change 23.330 Change 23.321/322 corrections:
TEST70SP The "best tested ever" revisions in MXG 23.10 for RMF 70s
VMAC7072 were still not perfect. The TYPE70/TYPE70PR/ASUM70PR and
VMXG70PR ASUMCEC datasets have had no reported data-value errors,
VMXGRMFI but the RMFINTRV dataset had missing values for the PR/SM
Jan 24, 2006 variables, due to an incorrect sort order, and errors in
Jan 26, 2006 building the WEEK/MONTH PDBs with new/old data uncovered
Jan 27, 2006 the need for additional PROC SORTs to put the new data
back in the old and expected sort order.
Chronological list of revisions to the revision:
23Jan2006:
-VMXG70PR. Cosmetic. Variables SYSPLEX SYSTEM were in
KEEP list for the new ASUMCELP but should not have been;
only impact was a possible WARNING message.
24Jan2006,27Jan2006:
-TEST70SP fails in its comparison of OLDRMFI and NEWRMFI,
with VARIABLES SYNCTIME LPARNAME LCPUADDR not found. The
two BY statements for the two SORTs and one BY statement
for the DATA step in lines 88-96 of TEST70SP should be:
BY SYSPLEX SYSTEM STARTIME;
BY SYSPLEX SYSTEM STARTIME;
BY SYSPLEX SYSTEM STARTIME;
26Jan2006:
-VMXGRMFI fails if SPIN.SPINRMFI dataset had observations:
ERROR: BY VARIABLES NOT SORTED ON DATASET WORK.SPINRMFI
because the new logic needed a sort of the old SPINRMFI
into the new sort order.
-VMXG70PR rebuilt PDB.RMFINTRV caused OUT OF SORT ORDER
error when (for example, WEEKBLD) old and new RMFINTRV
datasets were combined. Adding a final sort to force the
output to be BY SYSPLEX SYSTEM STARTIME corrected.
27Jan2006:
-VMXG70PR creation of PDB.TYPE70PR needed an additional
PROC SORT to put it in the original SORT order for the
WEEKLY merge.
-VMXG70PR rebuild PDB.RMFINTRV had missing values for the
"PLATCPUS" variable; re-sequencing the BY statements was
necessary.
All four members have now been redated 27Jan2006, so you
will know you have all current changes.
Thanks to Dr. Alexander Raeder, AtosOrigin, GERMANY.
Thanks to Alain Delaroche, CA-Atlantica, FRANCE.
Thanks to Diane Eppestine, AT&T Services, Inc, USA.
Change 23.329 Variable CPUCEPTM, CPU Time while Enqueue Promoted is
VMAC30 accumulated in SMF 30 interval records, but Change 22.326
BUILDPDB added logic to deaccumulate CPUCEPTM in PDB.SMFINTRV.
BUILDPD3 Now, IBM has added field SMF30CEPI, the interval CPU time
Jan 23, 2006 and MXG creates new variable CPUCIPTM from that field in
all of the TYPE30 datasets, as well as in PDB.STEPS and
PDB.JOBS.
Thanks to Scott Barry, SBBWorks, Inc, USA.
====== Changes thru 23.328 were in MXG 23.10 dated Jan 23, 2006=========
Change 23.328 New macro variable &MXGEOF with null value is now called
VMACSMF when EODOFSMF or ENDOFLOG condition is true; you could
VMXGINIT use &MXGEOF to execute code, like storing the MNSMFTME
Jan 22, 2006 value into a macro variable for subsequent use. While
Jan 26, 2006 this may look slightly kludgy, using an old-style macro
to hold the text (quotes, parens, semicolons etc.) that
is to be stored into a %LETed macro variable is often
much safer, cleaner, and easier to type-in, although the
use of %LET macvar= %QUOTE ( ... text ... ) ; may often
be all that is required, and, occasionally, you can even
use %LET macvar= ... text ... ;, but this always works to
pass executable SAS code into a macro variable:
MACRO _MXGEOF
CALL SYMPUT("MNSMFTME",PUT(MNSMFTME,DATETIME21.2));
%
%LET MXGEOF= _MXGEOF ;
%INCLUDE SOURCLIB( .. any SMF processing ) ;
%PUT &MNSMFTME;
Jan 26: Two instances of ENDOFSMF in seldom-used JOURNAL
INFILEs were corrected to ENDOFLOG; only impact was an
UNINITIALIZED VARIABLE ENDOFLOG message on the log.
Thanks to Dr. Alexander Raeder, AtosOrigin, GERMANY.
Change 23.327 Enhancements to IBM-RMF-Report-like report examples.
ANALRMFR Revisions for Change 23.321 to insert _STY70 when PDB=SMF
Jan 22, 2006 and REPORT=CPU is requested.
Thanks to Bruce Widlund, Merrill Consultants, USA.
Change 23.326 Macro variable PSUDB2 (used only by the new ASUMDB2) was
VMXGINIT not GLOBALed, even though it was %LET in VMXGINIT, caused
Jan 18, 2006 APPARENT SYMBOLIC REFERENCE PSUDB2 NOT RESOLVED on MVS.
Thanks to John Riera, InfoCrossing, USA.
Change 23.325 Syntax error 180 underscoring _C1020, only when TRACECLS
READDB2 argument is used, was introduced by Change 23.287 and is
Jan 18, 2006 corrected by relocating the test for TRACECLS argument to
Feb 17, 2005 after the include of VMAC102 code.
Feb 17: MAC102S initialized, eliminated error if no 102s
were requested.
Thanks to Thomas Zuber5, Independence Blue Cross, USA.
Change 23.324 On IBM's recommendation, these TPF Continuous Data values
VMACTPFC are now converted to rates per second by division by the
Jan 20, 2006 TPFCTDIF interval duration, which is already in seconds
and fractions. Their labels were also revised as shown:
Variable Label
TPFCHMSG HIGH*SPEED*MESSAGES*PER SEC
TPFCLMSG LOW*SPEED*MESSAGES*PER SEC
TPFCROEN ROUTED*ENTRIES*PER SEC
TPFCCREN CRTD*ENTS*PER SEC
TPFCSIMS SSCP*INPUT*MESSAGES*PER SEC
TPFCCIMS INSDB*IN*MESSAGES*PER SEC
TPFCCMTS COMMITS*PER SEC
TPFCCFRQ CF*REQUESTS*PER SEC
Thanks to Chris Weston, SAS Institute Cary, USA.
Thanks to Martha Hays, SAS Institute Cary, USA.
Thanks to Luis R. Vega-Zayas, IBM, USA.
Change 23.323 IBM APAR OA14365 corrects negative CPUUNITS in SMF 30s,
VMAC30 which occurs only when IFAs are used, and only when the
Jan 16, 2006 address space had little activity. The negative value is
created when CPUUNITS=CPUUNITS-IFAUNITS finds IFAUNITS
are greater than CPUUNITS. CPUUNITS is SMF30CSU, and
IFAUNITS=CPUIFATM*CPUCOEFF*LOSU_SEC or in IBM names:
(SMF30_TIME_ON_IFA) * SMF30CPC * (16000000/SMF30SUS)
MXG now detects that the CPUUNITS are negative, and
prints warning messages on the SAS log that you need to
install this APAR. Text revised March 6, 2006.
Thanks to Micchia Marco Antonio, UniCredit, ITALY.
Change 23.322 Support for 60 LPARs and corrections to ASUM70PR logic:
VMAC7072 z/OS 1.7 now supports up to 60 LPARs; your MXG code will
VMXG70PR fail with messages (ARRAY OUT OF RANGE) if you have an
Jan 19, 2006 LPARNUM greater than 32. This change was extensive:
-VMAC7072:
Size of temporary ARRAY S70LPCP was increased from 32
to 60. No other changes were required for the TYPE70
and TYPE70PR datasets.
-VMXG70PR summarization.
1. New PDB.ASUMCELP dataset is created from PDB.ASUMCEC,
with only one set of variable names, and it should be
used for reporting instead of PDB.ASUMCEC.
2. Major mechanical rewrite to support 60 LPARS.
Created 28 sets of 25 new variables for each of the
new LPARs in the PDB.ASUM70PR and PDB.ASUMCEC datasets
(so they are even more unwieldy for report writing).
While those datasets are valid, I strongly recommend
that you instead use PDB.ASUM70LP and PDB.ASUMCELP
datasets, instead of PDB.ASUM70PR and PDB.ASUMCEC;
those "LP" datasets have only one set of variable
names, for easy reporting, and you can select by
LPARNAME. The LPARNUM is no longer valid because an
LPARNAME's LPARNUM will change if a new LPARNAME is
created (LPARNUMs are set by alphabetical LPARNAME
order).
But in case you have reports based on those clumsy
sets of variable names in ASUM70PR/ASUMCEC datasets,
the variable names for LPARs 33-34 have Y and Z as
markers (1-9 and A-X were used for LPARs 0-32), and
these new names are created for LPARs 35-60 in the
(archaic, but valid) ASUM70PR and ASUMCEC datasets:
LPARS 0-34 LPARS 35-60
LPnAAAAA LQnAAAAA
LPCTnAAA LQCTnAAA
PCTLnAAA PCTQnAAA
3. MXG variable CPUOVHTM has been wrong for some time;
it contained both LPPUPDTM and LP0MGTTM, which are
identical measurements of the "PHYSICAL" CPU time, and
only one of them should have been included; this error
caused both the CPUOVHTM and PCTOVHD values to be
slightly too large.
4. LPARs with the same STARTIME but different DURATM's
caused incorrect calculations in PCTCPUBY and/or in
individual LPAR percentages, which could be over 100%,
in the ASUM70PR/ASUM70LP/ASUMCEC summary datasets.
To properly summarize data across a CEC, neither the
STARTIME nor SYNCTIME can be used to identify the
minimum set of interval data from all systems on that
CEC. STARTIME has been documented as varying by one
to several seconds for the same logical interval on
the same CEC. While SYNCTIME is constant in all RMF
records for a "normal" interval, when a WLM Policy
Change was made for six of nine LPARs in a CEC, there
were six 1.5-minute-DURATM obs, three 15-minute-DURATM
obs, and then six 13.5-minute obs. Those six 1.5
minute short duration records, written as a result of
the policy change, each had a unique SYNCTIME, so it
could not be used to group the observations. Only the
SMF70GIE value appears to be safe to use to get all of
the pieces together in CEC and 70PR/70LP summarization
and this redesign now uses SMF70GIE in place of the
STARTIME for the grouping into summary intervals.
(RMF Development later confirmed that they also use
SMF70GIE for their report grouping. 26Apr2006.)
5. PDB.ASUMCEC will contain invalid data if your LPARs
are on different time zones; you must use TIMEBILD to
force all of the datetimes to a single time zone for
ASUMCEC/ASUMCELP to be valid.
6. For ASUMCEC/ASUMCELP, comparisons should be extremely
close, but possibly not exact, for "normal" intervals.
For intervals were some LPARs were not present for the
full interval, or when a Policy Change was issued,
i.e., when there are more than one STARTIME in an
SMF70GIE interval, the new code should be correct,
creating only one observation for each SMF70GIE,
whereas the old code had an observation for each
STARTIME, and the old data for those "broken"
intervals was usually incorrect.
7. The circumvention member EXCECTIM is now unnecessary
and is no longer referenced by MXG code.
Thanks to Alain Delaroche, CA-Atlantica, FRANCE.
Change 23.321 Support for Split RMF 70 records: CRITICAL. SPLIT70.
VMAC7072 -If you have enough LPARs (32) with SPARE engines, IBM now
XMAC7072 splits the RMF 70 data into multiple physical SMF records
TEST70SP that are completely INCOMPATIBLE and REQUIRE this change.
Dec 7, 2005 MXG KNEW SPLIT RECORDS COULD EXIST AND PRINTS TEN ERROR
Jan 19, 2006 MESSAGES ON THE LOG THAT THERE ARE ERRORS AND BAD DATA.
Change 22.344, Jan, 2005, added that logic in MXG 22.22.
-But until I had actual records, I couldn't revise MXG.
-The support required a complete restructure of the code
and logic that creates the TYPE70 and TYPE70PR datasets
from RMF or CMF type 70 SMF records. None of the other
datasets created in the VMAC7072 "product" code were
touched by this change. Work started at CMG, and across
the holidays in chunks of development and testing using
RMF and CMF data from 33 sites that were not split (so
the old and new logic could be compared; the old logic
created trashed data with split records so there is no
"old" for split). Instead, the ANALRMFR RMF-like report
was compared with IBM RMF reports from the one split RMF
70 record that precipitated this major redesign!
-As long as you use BUILDPDB/3, RMFINTRV, TYPE7072 or the
TYPS7072 MXG code to read your RMF/CMF 70/72 records, the
MXG redesign will execute transparently with MXG 23.10+:
- Dataset WORK.TYPE70 initially has zero observations
after the SMF data is read; instead, new WORK.TYPE70SP
dataset will have observations, whether your records
are split or not.
- The WORK.TYPE70PR dataset is created from SMF, but it
is completely invalid if it was created from a SPLIT
SMF 70 record.
- The redesign now must invoke the _STY70 Data Set Sort
macro, which processes the WORK.TYPE70SP/TYPE70PR data
and in that process, creates these temporary datasets:
SORT70SP - Sort of TYPE70SP
PHYSICAL - LPARNAME='PHYSICAL' obs from TYPE70PR
NUCPCXPU - Count CPs, ICFs, IFLs, IAFs from PHYSICAL
THISPART - PARTISHN=LPARNUM subset from PHYSICAL
FROM70PR - Summary, create LPARn vars from THISPART
Three (SORT70SP, FROM70PR, NUCPSCPU) are then merged
to create the PDB.TYPE70 output dataset, which is also
enhanced by the addition of these new variables:
LPARNAME SMF70BDA LCPUDEDn-x, LCPUWAIn-x
Then _STY70 logic sorts TYPE70PR into SORT70PR so it
can be MERGEd with NUCPSCPU to populate the PARTNCPU
and NRICFCPU/NRIFLCPU/NRIFACPU variables from the
PHYSICAL segments to create the PDB.TYPE70PR dataset.
-If you use YOUR OWN CODE that uses the _VAR7072 _CDE7072
macros, then you MUST also invoke the _STY70 macro to
create the TYPE70 and TYPE70PR datasets; otherwise, you
will have zero observations in TYPE70 and bad data in the
TYPE70PR dataset. (If you already use the _S7072 product
sort macro to sort all of the 7072 datasets, you're home
free, since the product sort macro always invokes the
data set sort macro for all datasets from that product.)
The default output DD for _STY70 is "PDB" for both the
TYPE70 and TYPE70PR datasets. If you want your old
code to continue to write those two datasets to the
"WORK" DDname, you would insert:
%LET PTY70=WORK;
%LET PTY70PR=WORK;
before your DATA step.
-Note that _STY70PR sort macro is now null and must be
replaced with _STY70.
-The MXG TYPE7072 member now must invoke the _STY70 macro,
but with %LETs inserted in TYPE7072 so that the rebuilt
TYPE70/TYPE70PR datasets are still written to //WORK.
(So an existing %INCLUDE SOURCLIB(TYPE7072) will still
create those datasets in the //WORK library.)
But if you use %INCLUDE SOURLIB(TYPE7072), you can not
add an invocation of _STY70, because of that under the
covers execution. And you'll get an error if you do:
-You can get ERROR: FILE WORK.TYPE70SP DOES NOT EXIST:
a. if you do attempt to invoke _STY70 a second time,
b. if you have an old VMAC7072 in your "USERID" tailoring
source libraries
c. if your predecessor had (incorrectly) tailored MXG and
had redefined MACRO _VAR7072 or MACRO _CDE7072 macros
(usually in IMACKEEP member). It has ALWAYS been
incorrect installation tailoring to redefine those
critical MACRO _VARxxxx or MACRO _CDExxxx macros in
your USERID MXG Tailoring Library, precisely because
they block MXG from it correct definitions.
-ITRM/ITSV section: revised Jan 31, 2006:
Most ITRM sites do NOT have to do anything at all for the
new 70's architecture, as long as you create XRMFINT (the
RMFINTRV MXG dataset) with your %CMPROCES ITRM execution.
ONLY if you process RMF 70 records, but do NOT create
the RMFINTRV dataset, you will, at present, need to
insert the text _STY70 in your EXPDBOUT member.
This original change text said all ITRM sites needed
to add that statement, but that text was wrong, and it
is the rare site that would process 70s without also
creating the XRMFINT/RMFINTRV dataset. A later change
to ITRM can be expected that will make the invocation
of _STY70 internal to ITRM, and that statement will
need to be removed at that time.
-This iteration has no protection for incomplete sets of
split records: first record filled today's SMF file, next
record is in tomorrow's SMF file. That may be done in a
later iteration, using the //SPIN DD to hold data.
-VSETZERO member has been removed from the VMAC70s logic.
It was added in MXG 23.03 by Change 23.070 in an
attempt to deal with inconsistent STARTIME values
across LPARs, by setting STARTIME to the exact minute
when seconds were 58,59, or 01-10.
It is removed because the unchanged STARTIME value must
be used for the merge of the split records, but also
because VMXG70PR is revised in Change 23.323 to use the
SMF70GIE variable for the merge, and the minimum value of
STARTIME is used only for reporting those summary data.
-In both rewrites, I discovered a few cases in which the
old MXG code was inconsistent or even wrong:
- LPARn variables for unused LCPUADDRs were occasionally
zeros when they should have been a missing value; now
they are always missing. Had no impact on your data,
but they cause false positives in PROC COMPARE in the
TEST70SP program because they are different.
- Handling of engines with CAI='00'x (not on at end of
interval) and CAI='02'x or CAI='03'x (error flag on)
was inconsistent in the old code. Since SMF70ONT now
should be populated, it is used to determine if each
engine's dispatch/wait times are included in totals,
impacting the values in those individual "n" engine
variables and the totals, in particular variables
MVSWAITn,CPUWAITn,CPUPDTMn,CPUEFFMn and
MVSWAITM,CPUWAITM,CPUPDTMM,CPUEFFMM
If these values differ in your compare, look first at
the CAIn variables to see if they account for the
compare differences, knowing the new is correct now.
- Because values are now summed and then divided that
were previously divided and then summed, some small
differences (less than .001 absolute value) were found
in some time and percentage variables, but they only
impacted the PROC COMPARE, and not the real world.
- Duplicate SMF records were not always deleted, which
caused PCTCPUBY in ASUM70PR and ASUMCEC over 100%.
The sort order of TYPE70PR to remove duplicates is:
BY SYSPLEX SYSTEM SYNCTIME STARTIME SMF70GIE LCPUADDR;
- Variables NRICFCPU and NRIFAS in ASUM70PR/ASUMCEC were
sometimes incorrect in the old code.
- The SMF6CNF bit macro no longer exists; not needed with
the revised handling of the CAI '02'x and '03'x values.
- APAR OA14024 just reported that the IBM RMF Report Writer
fails with an ABEND 0C4 when it tried to read a split SMF
70 record from a system with 60 LPARs, because the total
length of all records was then over 64K bytes, a value
that killed the report writer, due use of a signed field.
And this happened after an RMF Developer told me that it
was very simple to reassemble their split data!
- This SMF 70 record really did not need to be split by
IBM now! The record contained 368 LCPUADDR segments from
the 32 LPARs, but there were actually only 68 LCPUADDR in
use; all of the other LCPUADDR segments were for each of
the SPARE engines on the z9, so if IBM had chosen to only
write the non-SPARE engine's, this rewrite would not have
occurred now. But, the rewrite is now done so the future
is safe.
- New TEST70SP member creates TYPE70/TYPE70PR datasets with
the old MXG 23.09 code (in XMAC7072 member) and with the
new VMAC7072 code, and uses PROC COMPARE to identify any
differences between new and old logic. TEST70SP can ONLY
be used with NON-SPLIT RMF 70s.
(The old code didn't support split records, which cause
multiple TYPE70 observations with same STARTIME and
with incorrect data values.)
It also created new and old ASUM70PR and ASUMCEC data and
compares them, but if your data has multiple STARTIMEs in
an SMF70GIE interval, the old and new will not compare,
as the old was split into multiple observations, but the
new logic correctly summarizes those multiples, so there
will be fewer observations in the new compared with the
old, which PROC COMPARE reports as lots of differences,
but there is no error.
Thanks to Matt Clarke, Charles Schwab & Co., Inc, USA.
Thanks to Neil Ervin, Charles Schwab & Co., Inc, USA.
Change 23.320 -Truncated SMF 102 record caused INPUT STATEMENT EXCEEDED
VMAC102 RECORD LENGTH error is now detected and reported on the
Dec 23, 2005 SAS log as a truncated record, rather than an ABEND.
-IFCID 83 record from DB2 V7.1 caused similar ABEND, but
this was because the MXG code for that IFCID was only
for DB2 V8.1, as only that version's test data had been
received; now, both V7 and V8 IFCID 83 are supported.
Thanks to Tony Pratt, Tampa Electric, USA.
Change 23.319 New ASUMDB2 program summarizes DB2ACCT events to create
ASUMDB2 interval (hourly default) transaction counts, resources,
VMXGINIT and response time buckets, using the same macro variables
Dec 18, 2005 to define those buckets as are used in ASUMCICS/ASUMCICX
that creates PDB.CICS.
Thanks to John Rivera, (i)Structure, USA.
Change 23.318 Incorrect syntax with character text for NRPERIODS caused
VMXGRMFI strange and unobvious error messages; now, if NRPERIODS
Dec 18, 2005 is not a number, the execution will ABEND so you can fix
your syntax.
Thanks to Robbie A. McCoy, Salt River Project, USA.
Change 23.317 -Syntax error in TRNDUOW due to a semi-colon after a ELSE.
TRNDCEC -Variable NRPRCS NOT FOUND in TRNDCEC because it was
TRNDUOW removed some time ago.
Dec 18, 2005 -TRND members had not been fully tested in QA, now are.
Thanks to Freddie Arie, Merrill Consultants, USA.
Change 23.316 Changes to VGETENG required corresponding changes to this
UTILCONT utility that provides the size of contents of your SAS
Dec 15, 2005 data libraries.
Thanks to Paul Naddeo, FISERV, USA.
Change 23.315 Dataset ICFD70PR NOT SORTED error due to short interval
ASUM70PR RMF records required yet another sort to force proper
Dec 15, 2005 sequence.
Thanks to Jimmy J. Hu, Ameren, USA.
Change 23.314 Documentation only. APAR OA06476 documents that TYPE74CA
VMAC74 fields R745INCR, R745BYTR, R745BYTW, R745RTIR, R745RTIW
Dec 13, 2005 have never been populated and are now reserved fields
that will always be zeros. The data was planned for the
2105 800 models, but the data was not available on those
boxes. The data has become available with the 2105 box,
but that interface and APAR OA06476 adds new R7451INC,
and R7451CT1-4 to RAID Rank/Extent Pool Section.
Change 23.313 -Variables R791TIFC/R792TIFC were incorrectly normalized
VMAC79 by R791NFFI/R792NFFI, but they are already in CP seconds
Dec 12, 2005 so they are no longer normalized.
-Variables R791TCP and R729TCP are now deaccumulated, and
the label for R792TCP is now correct.
-Text in Change 22.152 now has correct variable names and
labels for TYPE791 and TYPE792 IFA-related variables.
-Change 23.132 updated to list the TYPE79 changes made.
Thanks to Rick Southby, Insurance Australia Group (IAG), AUSTRALIA.
Change 23.312 New CICSBAD dataset contains "bad" CICSTRAN observations,
EXCICBAD that were previously output in CICSTRAN dataset, but are
IMACCICS known to be defective, and so are now output in CICSBAD.
VMAC110 There are two "bad" conditions supported in this change:
VMXGINIT -When a user types in a TRANNAME that is not a valid name,
Dec 9, 2005 there still is a type 110 segment created with missing
Feb 9, 2006 fields, and TRANNAME contains whatever was typed. Those
records are identified by PROGRAM='########', and are
now output into dataset CICSBAD rather than CICSTRAN.
While these records are usually just typos, hackers have
been known to keep typing names until they find one that
works, so these records might be useful in CICS security
issues. Each record has between 3 and 4 milliseconds of
CPU time in TASCPUTM, which I presume is the fixed cost
to create a CICSTRAN observation (speculation - there may
be uncaptured CPU) on a SU_SEC=10000 speed engine.
-When a CICS task is executing on an OPEN TCB, and is then
purged, APAR PQ86971 documents that all of the clocks are
invalid when this happens, and that APAR adds a new bit
to the TRANFLAG field to identify these tasks. Since the
clock values are all wrong, these transactions are now
also output in CICSBAD instead of CICSTRAN.
-So, CICSBAD will now contain all PROGRAM='########' obs,
and all transactions purged on an open TCB, and CICSTRAN
will no longer have any of those invalid transactions.
-The format for CPU-time fields were changed to TIME13.3,
to display the millisecond level; TIME16.6 would show the
full resolution, but would cause reports based on the
current length to be shifted, so it was not chosen.
Change 23.311 Support for Beta 91 Version 3.1.1.0, which INCOMPATIBLY
VMACBE91 changed the header of their record, and all subtypes.
Dec 8, 2005 This iteration supports BETA91B and BETA91C datasets,
Dec 12, 2005 which were validated with '44'x and '50'x subtypes. Two
other datasets have not been tested with real records.
Thanks to Herve Brusseaus, Fortis Bank, LUXEMBOURG.
Change 23.310 Variable ESMFNTRN was always missing because it existed
VMACMPLX only in a LABEL statement, and was misspelled. The count
Dec 8, 2005 of transactions is in variable ESMFTRAN.
Thanks to Sudie Wulfert-Schickedanz, Anheuser-Busch., USA.
====== Changes thru 23.309 were in MXG 23.09 dated Dec 7, 2005=========
Change 23.309 INVALID ARGUMENT TO FUNCTION SQRT error when an invalid
VMXGUOW transaction (PROGRAM='########') was processed. In the
TRNDUOW VMXGUOW member, CICSTRAN obs with that PROGRAM name are
Dec 7, 2005 now deleted prior to summary, and TRNDUOW is protected.
Thanks to Bruce Widlund, Merrill Consultants, USA.
Change 23.308 MXG 23.08-23.09. Note VARIABLE JOBINFO1 IS UNINITIALIZED
VMAC26J2 because of an incomplete ending-comment; fortunately, the
Dec 5, 2005 only impact was that these four variables: OPTJOURN,
OPTOUTPT, TYPRUN and RESTARTD will all be blank.
Thanks to Jon Whitcomb, Great Lakes Educational Loan Service, USA.
Change 23.307 INPUT STATEMENT EXCEEDED after "DTP=24 SEGMENT.." message
VMAC80A because the additional segments were not processed after
Dec 5, 2005 that MXG message.
Dec 9, 2005 -Dec 9. Same error corrected for DTP=25 SEGMENT.
Thanks to Coen Wessels, Unicible, SWITZERLAND.
Thanks to Mark Nouwen, Dexia, BELGIUM.
Change 23.306 MXG variables PARTNCPU and NRICFCPU/NRIFACPU/NRIFLCPUs
VMAC7072 still wrong on z9s, because IBM's SMF70BNP field is in
VMXG70PR error on z9s. MXG calculated PARTNCPU from SMF70BNP,
Dec 5, 2005 but in earlier platforms, SMF70BNP included the count of
Dec 7, 2005 ICFs, which MXG subtracted. So when the z9 added new
'IFA' and 'IFL' values to SMF70CIN, I assumed those also
needed to be subtracted from SMF70BNP. Now, however,
IBM confirmed SMF70BNP is in error and will be changed
with the next z9 microcode:
the expected MCL number containing this change is
J99671.014 in driver d63j (Jan, 2006)
and recommended that instead to count of engines in the
PHYSICAL segments, rather than use SMF70BNP, so this
change does set PARTNCPU from the count of CPs in the
PHYSICAL partition records.
Dec 7: The Dec 5 change accidentally fixed the z9 data
and un-fixed other processors, because I had
spelled PARTNCPU as PLATCPUS in both the code
and text of the original change. PARTNCPU is
the name in the type 70 datasets; PLATCPUS is
the name only in the RMFINTRV dataset.
-In VMXG70PR, NRICFCPU and NRIFACPU could also be wrong;
a SUM was used where a MAX was required; because my test
data has only one of each, the SUM and MAX were the same
and the logic error was not detected.
-Variable NRPRCS is no longer kept in PDB.ASUM70PR and
PDB.ASUMCEC datasets; it has no meaning for those data.
Thanks to Dave Crandall, Farmers Insurance, USA.
Change 23.305 Optional OPID variable was never INPUTed!
IMACICO1
Dec 2, 2005
Thanks to Lucy Fukushima, California Health and Welfare, USA
Change 23.304 ANALCNCR could fail when an observation with missing
ANALCNCR values for the number of concurrent events was being
Dec 2, 2005 generated, which caused the calculation of the Y-axis
to fail. The record with missing values is dropped and
axix calculations were protected for the possibility of
missing values.
Thanks to Bruce Hewson, Citibank N.A., SINGAPORE.
====== Changes thru 23.303 were in MXG 23.10 dated Dec 1, 2005=========
Change 23.303 First MXG 23.09 only, and only under SAS Version 8: ERROR
VGETENG LIBNAMES IS NOT A RECOGNIZED PROC SQL DICTIONARY TABLE.
Dec 1, 2005 Change DICTIONARY.LIBNAMES to DICTIONARY.MEMBERS and
Dec 2, 2005 the PROC SQL will work under either V8 or V9.
The LIBNAMES dataset in the DICTIONARY was new in V9,
and we failed to test under V8 with the first 23.09.
Dec 2: We now test version, and use LIBNAMES with V9 or
use MEMBERS with V8. The advantage of the LIBNAMES is
that we can get the engine as long as the LIBNAME has
been referenced (either with a LIBNAME statement, or
implicitly by referencing a dataset), whereas the MEMBERS
only exists if a dataset in the library has been opened.
Thanks to Robbie A. McCoy, Salt River Project, USA.
Change 23.302 -The RACF Unload Utility output have always had a 4-digit
EXRAC2A0 numeric "RECNR", in EBCDIC, but now a new '02A0' value
IMACRACF is found, which caused INVALID DATA FOR RECNR error.
VMACRACF Since numeric RECNR was a kept variable in all datasets,
VMXGINIT new character variable RECTYPE is now INPUT and used in
Nov 30, 2005 all tests, were also changed to character syntax.
-The new RACF02A0 dataset, for USER OVM DATA, is now
created by this change.
-I am now aware of additional new RECTYPE values and they
are listed in the comments in VMACRACF as "NOT DECODED",
as I need test records to support them.
Thanks to Bruce Hewson, Citigroup N.A., SINGAPORE.
Change 23.301 The MXSMFTME and MNSMFTME variables now exclude SMF 2 & 3
VMACSMF header/trailer records (created in the output SMF file
Nov 30, 2005 when IFASMFDP dumps, or later copies, an SMF file). The
ID 2 and 3s record when the dump/copy program ran, and
do not describe the range of timestamps of the SMF data.
Thanks to Erik Janssen, ING Netherlands, THE NETHERLANDS.
====== Changes thru 23.300 were in MXG 23.09 dated Nov 30, 2005=========
Change 23.300 -ML-37 of MXGTMNT monitor now captures SYSLOG messages in
ASMTAPEE a new SMF subtype 8 for these mount-related events:
ASUMTAPE IEC501A IEC501E IEC705I IEF233A IEF502E IEF234E IOS070E
EXTMNSTS IECTMS6 IECTMS9 IOS690I IEF235D
EXTMNSYM and a new subtype 9 record can be written for any other
EXTMNSYS SYSLOG messages you want captured in your SMF data!
IMACTMNT -Two new MXG datasets are created from MXGTMNT's subtypes:
VMACTMNT dddddd dataset description
VMXGINIT TMNSYT TYPESYMT Mount-specific SYSLOG, subtype 8
Nov 28, 2005 TMNSYL TYPESYSL User-selected SYSLOG messages, st 9.
Jun 15, 2006 -Added Jun 15, 2006:
This redesign REQUIRES you to use ASMTAPEE at ML-38 or
later, as it depends on the SYSLOG Mount-specific records
and there will be zero observations in PDB.ASUMTAPE if
there are zero obs in TYPESYMT syslog mount dataset.
-For the IBM IEF_VOLUMEMNT exit, we seem to capture every
mount that is issued with an IEF233A mount message, and
we appear to capture no mount that is issued with any of
the other messages, in particular, the IEC501A message
that is issued for second-volume mounts of a multi-volume
tape dataset. IBM Support confirmed that is correct for
their exit; it is taken only for Allocation's mounts, and
those OPEN/CLOSE/EOV mounts (the IEC501x messages) do not
go thru that exit. I hope to propagate the jobstuff from
the first mount into the second mount for these multi-vol
mounts, but there are also IEC501A mounts that are the
first and only mount for a job, so I need more test data
from the ML-37 monitor with SYSLOG data to fully resolve
what is and is not captured in the IBM exit, and how the
logic in ASUMTAPE can be enhanced further.
-Revised Jun 15, 2006:
For the STK UX01 exit, STK Support has now installed our
ASMHSCEX and have captured 100% of all HSC-controlled
tape mounts, both to virtual and to real tape devices, in
several tests in their labs by Sun Technicians.
-For IBM, SYSLOG data goes a very long way to resolve.
True, you do NOT know the actual duration of the mount
(TAPMNTTM will be missing if MXGTMNT missed the mount)
and the READTIME variable will be missing, so you cannot
directly MERGE the ASUMTAPE back to the PDB.JOBS for any
simple match for billing, but almost all of the jobstuff
that we got from the MXGTMNT data is now picked up from
the SYSLOG data, so the PDB.ASUMTAPE with these changes
is of far better quality than it every as been before.
-But expect revisions to the ASUMTAPE program after more
test data has been received; early adapters of this new
code are requested to send their SMF records (the MXGTMNT
user-SMF record, AND the SMF type 21 dismounts) so that
the new data can be better understood; member SENDATA in
MXG 23.09 has the instruction (and new ip address) to
send SMF data to our ftp site.
-The Tape Allocation subtypes that create TYPETALO data
is still sampled, so job-related data can be missing in
that dataset; I hope to be able to merge the job-stuff
from this new PDB.ASUMTAPE dataset into those missing
variables in PDB.ASUMTALO, in a later enhancement.
-Additional documentation notes:
This enhancement makes the MXGTMNT program in ASMTAPEE,
the "MXG Tape Mount, Tape Allocation, Tape Swap, Tape
Allocation Recovery, and SYSLOG message monitor". The
messages captured in the "MXG-owned" subtype eight are
these that needed for tape mount event events:
IEF233A - First Volume Mount, Allocation Issued
IEF501A - OPEN/CLOSE/EOV, MULTI-VOL, or DEFERRED MOUNT
IEF501E - 2nd+ Volume for OPEN/CLOSE/EOV "Look Ahead"
==> 3 seconds --
IOS070E - MOUNT PENDING sss
IECTMS6 - DEVNR,VOLSER,IS APPROVED FOR TRTCH CHANGE
IECTMS9 - DEVNR,VOLSER, DSNAME17 at OPEN
==> actual time to mount ==> TAPMNTTM
IEC705I - TAPE ON DEVNR,VOLSER
==> duration tape was mounted ==> TAPMTDTM
TMS014 - Copy of IEC502E or IEF234E message
IEF502E - Intermediate Volume KEEP
IEC234E - Last Volume KEEP
and these additional messages are captured in subtype 8
to identify causes of known tape mount delays:
IEF690I - FOLLOWING VOLUMES UNAVAILABLE
IEF235D - JJJ STEP WAITING FOR VOLUMES
IEC205I - VOLUME LIST
New dataset TYPESYMT (SYSLOG MounTs) decodes those SYSLOG
records, which include the JOB, JESNR, SYSTEM, ASID, and
the EVENTIME (same .01 second resolution as SMFTIME).d
The below left-to-right examples show some examples of
the sequence of SYSLOG mount-related event records:
233A 234E
233A TMS6 TMS9 705I TMS014 234E
233A TMS6 TMS9 705I TMS014 502E for first vol
501A TMS6 TMS9 705I TMS014 502E for intermediates
501A TMS6 TMS9 705I TMS014 234E for final volume
or
501E TMS6 TMS9 705I TMS014 234E for final volume
233A 070E TMS014 502E
690D 235D 705I 234E
New dataset TYPESYSL (SYSLOG Messages) can be populated
with any SYSLOG messages you chose to ask MXGTMNT to
capture in subtype 9. At present, you must EDIT the name
table in the ASMTAPEE and re-assemble, but ASMTAPEE will
be revised so you can use the console MODIFY command to
turn on or turn off capture of any SYSLOG message.
I plan to create an ANALSYSL program to decode those
SYSLOG messages that you decide to capture, so let me
know what messages you find important and useful.
Change 23.299 Support for SPLIT RMF 70 records, created on a z9 with
VMAC7072 25 LPARS. To be investigated. Check text of this change
Nov 28, 2005 in the final MXG 23.09 that will be dated Nov 30, 2005.
No change made yet, await test data with split records.
Change 23.298 MXG 23.08 would fail if you did not have a //INSTREAM DD
VGETENG in your JCL Procedure (there is one in MXGSASVn example),
Nov 28, 2005 because VGETENG was changed to require the use of that DD
in the "mainstream" RMFINTRV processing, or would fail if
you used UTILBLDP and then %INCLUDE INSTREAM; to execute
the program built by UTILBLDP, with FILE INSTREAM IN USE
error. Both errors were introduced when revisions added
the use of //INSTREAM in VGETENG; both are corrected by
backing out the use of //INSTREAM in VGETENG.
That addition was yet another attempt to improve the
accuracy of VGETENG's logic to "GET" the ENGINE of a
LIBREF. Originally, this was to avoid a second tape
mount, but knowing the library is on tape when we are
going to read with a VIEW, we can avoid a second read
of the full (possibly multi-volume) tape dataset.
However, is just not possible to know the media of an
un-referenced DD, so we must revert to the original
logic that can only identify a tape that has been
previously referenced in this step.
So you could force that reference with a LIBNAME
statement, or a DATA _NULL_; SET DD.XX; STOP;
if you see there are multiple mounts on syslog.
In the case of VMXGSUM, which does not use the
VGETENG logic, we are still investigating if we
can detect and eliminate the second read with a
VIEW when the input is on tape.
Thanks to Scott Barry, SBBWorks, Inc, USA.
Change 23.297 Support for TCP field ACCEPT in dataset AIXTCP.
VMACAIX
Nov 23, 2005
Thanks to Long N. Nguyen, Department of Home Security, USA.
Change 23.296 Macro _STY30U6 deaccumulates TYPE30_6 into PDB.TYPE30_6,
VMAC30 but it did not protect for wrapping of the four-byte
Nov 22, 2005 RESIDTM and ACTIVETM fields, which wrap at 1221 hours.
Additionally, ACTIVETM was not deaccumulated, but now is.
The created variable UPTM contains the original ACTIVETM
before deaccumulation, but UPTM will reset to zero every
51 days or so.
-Noted and corrected: INTETIME and SYNCTIME in TYPE30_6
were on GMT rather than local time if GMTOFF30 non-zero.
Thanks to Jean-Denis Lacourse, CGI, CANADA.
Thanks to Robert Petel, CGI, CANADA.
Change 23.295 Dataset DB2ACCTG didn't contain these nine QBGA variables
VMACDB2 QGBADG QBGAP1 QBGAP2 QBGAP3 QBGAS1 QBGAS2
Nov 22, 2005 QBGAS3 QBGAU1 QBGAWS
although their sums were kept in DB2ACCT. All variables
are now kept in DB2ACCTG.
Thanks to Steve Olmstead, Thomson BETA Systems, USA.
Change 23.294 TMVSCI dataset variable CIJN was off by four bytes, which
VMACTMVS caused wrong values in it and the subsequent CI variables
Nov 22, 2005 that track storage. In addition, the percentage field's
Nov 5, 2005 values were all off by a factor of 100, as I missed the
precision of that field in the TMVS documentation.
Thanks to Richard Jay Schwartz, State Street Bank, USA.
Change 23.293 The MXG Trending default INTERVAL=WEEK, is replaced with
TRND72GO INTERVAL=&INTTRND, with macro variable INTTRND defaulting
VMXGINIT to WEEK, i.e., the INTERVAL= value is externalized so it
Nov 22, 2005 can be changed with %LET INTTRND= whatever ; before your
%INCLUDE SOURCLIB(TRNDxxxx); statement (where "whatever"
is one of the valid values defined in VMXGDUR).
Only the TRNDxxxx members that had INTERVAL=WEEK, were
changed; a few don't use the INTERVAL= argument (instead
using a date/time variable in their SUMBY= argument) and
a few had INTERVAL=DATE, left unchanged. TRNDCICS/CICX
have INTERVAL=&TRCIINTV, but the %LET TRCIINTV=WEEK; is
inside those two members, so it couldn't be externally
changed. Now, INTERVAL=&INTTRND, is specified and the
useless reference to TRCIINTV is removed.
Thanks to Stan Dylnicki, Royal Bank of Canada, CANADA.
Change 23.292 Support for APAR OA11675, which increases EXCPTOTL's old
VMAC30 maximum count of 2 gig to a new maximum of 4 gig. The
VMAC32 field counts the step's lifetime total EXCPs (blocks or
VMAC33 SSCHs, depending on the Access Method used); the original
Nov 14, 2005 APAR text and title erroneously said "2 gigabytes". If
the count is now over 4 gig, (4,294,967,295), the APAR
stores 'FFFFFFFF'x and turns on a new bit to indicate the
count exceeded the maximum. MXG creates EXCPERR='Y' if
that bit is on, and sets EXCPTOTL to a missing value.
The variable name is EXCPTOTL in SMF 30s and PDB datasets
and in SMF 33s, but was named EXCPS in TYPE32.
Change 23.291 Support for NDM subtypes:
EXNDMHW Subtype Description
EXNDMNM HW HIGH WATER MARK STAT RECORD - supported
IMACNDM NM Unknown - Header only until I get the DSECT
VMACNDM
VMXGINIT
Nov 13, 2005
Thanks to David Kaplan, Depository Trust, USA.
Change 23.290 Deaccumulation of the VXSYTEPM dataset was still wrong;
VMACVMXA four byte wrap was not protected, but IBM has created a
Nov 12, 2005 new "architecture" that needed additional logic. For each
device's first instance, CALINIT='Y' and the contents of
that "initial" record is all zeros, so it is deleted.
However, the second record must also be deleted, as it
does not start from zero, but has some large non-zero
values that must be used in the DIF() but the observation
after the CALINIT='Y' instance must then be deleted also.
And since records with CALINIT='Y' are deleted, there is
no reason to keep that variable in VXSYTEMP dataset.
Thanks to Melanie Higching, British Telecom, ENGLAND.
Change 23.289 For RMF intervals with DURATM less than one minute, MXG's
VMXG70PR summarization into PDB.ASUM70PR didn't store the second
Nov 10, 2005 interval's DURATM in SYSDUR, which caused values over 100
percent in PCTCPUBY and the LPCTnBY value for that LPAR.
Change 23.070 documented these very short RMF intervals
(created when a WLM Policy Change was made), and dataset
PDB.ASUMCEC was corrected by that change, but 23.205 was
and additional revision, and it reinstated EXCECTIM exit
to force the STARTIME for all three datasets created by
the ASUM70PR/VMXG70PR program to the nearest minute, both
for cross-CEC timing issues, and to consolidate these RMF
short intervals. But the logic for PDB.ASUM70PR/ASUM70LP
to set SYSDUR was based on IF FIRST.LPARNUM, but that
didn't "see" the second instance with same STARTIME.
By adding DURATM as the last BY variable in the BY in
INCODE=, and by setting SYSDUR from IF FIRST.DURATM, the
summary DURATM is correct for those two datasets, which
also corrects the percentages based on DURATM.
-The WLM Policy Change was installed at 10:32:06, and the
STARTIME and DURATM of the adjacent RMF records were:
STARTIME DURATM
hh:mm:ss hh:mm:ss
10:15:00 00:15:00
10:30:00 00:00:20
10:30:20 00:01:46
10:32:07 00:12:52
Thanks to Jerry Urbaniak, Acxiom CDC Inc, USA.
Change 23.288 BMC CMF Product SMF 70 records for z9 have SMF70BND=0,
VMAC7072 MXG variable LPARCPUX, in the LPARNAME='PHYSICAL' segment
Nov 10, 2005 which processor counts, especially for NRIFACPU, NRIFLCPU
Jun 6, 2006 and NRICFCPU will always be zero; investigation with BMC
is in progress.
Jun 8, 2006 update: The error was only in the first level
of CMF support for the z9, and was corrected by CMF APAR
BAM9572, PTF BPM9543.
Change 23.287 Usability enhancement for selective output of DB2 data.
READDB2 You can choose which datasets are to be created, which
Nov 10, 2005 observations are to be output, and even which variables
Nov 16, 2005 will be kept in any of the created datasets:
Nov 22, 2005
SELECTION CRITERIA:
SMFBEGIN= DATE/TIME CONSTANT FOR BEGINNING OF TIME RANGE
SMFEND = DATE/TIME CONSTANT FOR END OF TIME RANGE
SYSTEM = SYSTEM(S) FOR WHICH DATA SHOULD BE SELECTED
PLAN = PLAN(S) FOR WHICH DATA SHOULD BE SELECTED
AUTHID = AUTHID(S) FOR WHICH DATA SHOULD BE SELECTED
CORRID = CORRELATION ID(S) WHICH SHOULD BE SELECTED
CONNID = CONNECTION ID(S) WHICH SHOULD BE SELECTED
DB2 = DB2 SUBSYSTEM(S) WHICH SHOULD BE SELECTED
CONNTYPE= CONNECTION TYPE(S) WHICH SHOULD BE SELECTED
PACKAGE = PACKAGE NAME (FOR DB2ACCTP DATASET ONLY)
DATASET CRITERIA:
DB2ACCT= Any of the below syntax
DB2ACTB= "
DB2ACTP= "
=YES - DATASET IS CREATED WITH ALL OBS/VARS
=NO - DATASET IS CREATED WITH 0 OBS
=KEEP/VAR1 VAR2 VAR3.. - DATASET IS CREATED AND
KEEPS ONLY THE LISTED VARIABLES
=DROP/VAR1 VAR2 VAR3... - DATASET IS CREATED AND
DROPS ALL THE LISTED VARIABLES
Thanks to John W. McAlinney, Vanguard, USA.
Change 23.286 Change 23.153 revised the value of SMF "subtype" for DB2
VMXGGETM 102 trace records to contain the "IFCID" because that is
Nov 9, 2005 the "logical" subtype for the 102s that don't have an SMF
subtype in the SMF header. That change also stores IFCID
for subtype in the 100 and 101 records, even though they
do have SMF subtypes, because DB2 documentation refers to
IFCIDs and not to SMF subtypes. These are the values
that were changed, but not documented.
IFCID: 1 2 202 3 239
Rec.Sty: 100.0 100.1 100.2 101.0 101.1
This change only added documentation notes in the member.
Thanks to Daniel T. Cannon, The Hartford, USA.
Change 23.285 VM Accounting datetimes were incorrect; Change 23.109 had
TYPEVM used the record LENGTH to identify the date format, but
Nov 9, 2005 that test was not sufficient, and I can find no other way
Nov 11, 2005 to discriminate safely between MMDDYY or YYMMDD than to
Nov 15, 2005 have you tell me in a new MACRO _DATEVM with values:
_DATEVM Date Format
1 MMDDYY (Default)
2 YYMMDD
The default format is the IBM MMDDYY format; you can use
this syntax to change the macro value if needed:
//SYSIN DD *
%LET MACKEEP= MACRO _DATEVM 1 % :
%INCLUDE SOURCLIB(TYPEVM);
Nov 15: LENGTH=LENGTH restored to the INFILE statement.
Even though it can't be used for date-discrimination, it
is needed to identify some VM data records.
Thanks to Wah Chu, SIAC, USA.
Change 23.284 PDB.PRINT,TYPE6 variables TOTLINES,NRLINES is 4294967295,
VMAC6 sometimes, in tcp/ip "Printway" file transfer records,
Nov 7, 2005 which are SMF 6 records written by PSF for "print" output
that was sent via tpc/ip to an ip address. That decimal
value results when SMF6NLR contains 'FFFFFFFF'x is the
SMF record.
-These TYPE6/PDB.PRINT tcp/ip records have SUBSYS='TCP',
and only variable SMF6BYTES can be used for print bills
or printer resource measurements.
-They do not have the PSF-APA segment, so SHEETPRN and the
other fields from that segment are all missing.
-Why NRLINES is someimes bad and sometimes has reasonable
values is unknown (query pending to IBM), but NRLINES has
never been recommended (see the PRINTERS section in the
MVS/ESA RESOURCE ACCOUNTING" article in NEWSLTRS.
-But because that large value is confusing and could mess
up your old print billing system with it, I have chosen
to test for the 'FFFFFFFF'x field value, and now set the
variable NRLINES to a missing value for those instances.
-PDB.PRINT variable TOTLINES is the equivalent of NRLINES.
Do not use the old PRINTLNE/PUNCHCRD/EXTWTRLN variables,
because there is no safe way to identify which kind of
device was at the destination, and they are archaic in
any case. TOTLINES is their sum, and the field to use,
if you still must have some count of "linew".
-Note that in non-TCP records for PSF, NRLINES can also be
wierd when the SMF6PRMD printer mode is "DATA" and not
"LINE", but at least those records have valid SHEETPRN
in their PSF-APA segments.
-Note for back-level-MXG users: SUBSYS='TCP' was added in
MXG 22.08 (Change 22.153), but SMF6BYTE has been input
since Change 13.328, and it will be non-missing only in
tcp/ip print records, so it could be used alternatively
to identify these records.
Thanks to Thomas Heitlinger, FIDUCIA IT AG, GERMANY.
Thanks to Philip Matthei, State of New York, USA.
Change 23.283 Support for ASG-Landmark TMVS Version 3.2 has confirmed
VMACTMVS that any changes made were COMPATIBLE, but I won't take
Nov 3, 2005 time to compare all of the DSECTS to look for new data
until a user finds a need for it. The last change in
MXG was prior to MXG Version 20.20.
See Change 23.294 for internal record changes in 3.2.
Thanks to Richard Evans, Worldspan, USA.
Change 23.282 MXG 23.08-MXG 23.02. Change 23.068 used a rare GOTO that
VMAC26J3 should have been a LINK statement. The GOTO caused the
Nov 3, 2005 RETURN statement after the label to be a DELETE statement
so the rest of the record was never read nor was the exit
for the OUTPUT every called for that record.
This behavior of the RETURN statement only occurs when
there are OUTPUT statements in the SAS data step.
If there are no OUTPUT statements, a RETURN after GOTO
causes all datasets in the DATA statement to be OUTPUT.
With the LINK statement, the label is called, but RETURN
brings the program back to the statement after the LINK,
so the rest of the record is read and OUTPUT.
Thanks to Dave Falzon, EDS Ottawa, CANADA.
Change 23.281 MXG 23.08. ERROR: File WORK.TYPE791.DATA does not exist
TESTIBM1 when JCLTESTx is run. TYPE79 now sorts the TYPE79xx data
Nov 2, 2005 (to deaccumulate) to the PDB library, but the TESTIBM1
program's PROC MEANS still expected those data in WORK.
TESTIBM1 was changed to find TYPE79xx in the default PDB.
Thanks to Bernd Klawa, Stadwerke Bielefeld GmbH, GERMANY.
Change 23.280 DB2 Package Data could STILL be wrong, if any of these
VMACDB2 fields are longer than the original un-truncated length:
Nov 1, 2005 variable label was now
Nov 2, 2005 QLACLOCN='LOCATION*NAME' $16 $16
Dec 13, 2005 QPACLOCN='LOCATION*NAME' $16 $16
QPACCOLN='PACKAGE*COLLECTION ID' $18 $18
QPACPKID='PROGRAM*NAME' $18 $18
QPACASCH='NESTED*ACTIVITY*SCHEMA*NAME' $8 $17
QPACAANM='NAME*OF*ACTIVITY' $18 $18
In the observed case, QPACASCH was increased to 16 bytes
and contained 'SYSPROC.S1BNLERP' as one example value.
For now, I've increased the default length of QPACLOCN
to $17, pending an understanding of whether the increase
was made by the installation or by IBM. The revised code
inputs them all with $VARYING128, which is the maximum
documented length With MXG's COMPRESS=YES default, they
could be changed to default $128 length, but that could
dramatically increase the size of the DB2ACCTP dataset
if you have turned off COMPRESS=YES, so I chose to leave
the other above fields in their original stored lengths.
The original text contained this next statemnt:
Insert Mar 27, 2013: THIS 2006 statement is false in sas version 9:
"You can change the stored length by the addition of:
LENGTH QPACxxxx $nn ;
in the EXDB2ACP exit; SAS uses the last LENGTH statement
to set the variables stored length."
SAS uses the FIRST instance of the character variable to
set its length, and prints a WARNING that first length if
a LENGTH statement with a different length os found.
SEE NEWSLETTER SIXTY - SECTION 7.1. CHANGING VARIABLE LENGTH.
end of Mar 27, 2013 Insert.
-Dec 13, 2005: HOORAY, package date WAS FIXED in November;
this is only additional documentation about package data:
In DB2 V8 data, in dataset DB2ACCTP, QWACBSC and QWACESC
variables (begin/end datetimes), are now always missing,
because V8 creates only SMF 101 Subtype 1 IFCID=239 data.
In V7 and earlier, IFCID=0003, Subtype=0 records (first
ten packages) did populate those variables, but IFCID=239
records always had BSC/ESC missing for the 11th-plus
package.
Thanks to Tory Lepak, Aetna, USA.
Change 23.279 Support for VTCS 6.0 and 6.1 SMF records (COMPATIBLE).
FORMATS These new variables are created, but only CTP appears to
VMACSTC be new in 6.1 records, all other variables below do have
Nov 1, 2005 real values in 6.0 SMF records:
Dataset STCVSM13:
STC13CTP='CARTRIDGE*TYPE'
decoded by $MGSTCCT format:
'0000'X='0000X:S-CART 400MB'
'0001'X='0001X:E-CART 800MB'
STC13HST='ORIGINATING*HOST*NAME'
STC15MNR='MOUNTED*WITHOUT*A RECALL?'
STC15MRC='MOUNTED*AFTER*A RECALL?'
Dataset STCVSM14:
STC14CTP='CARTRIDGE*TYPE'
decoded by $MGSTCCT format:
STC14HST='ORIGINATING*HOST*NAME'
STC14ULN='MVCS*TO*UNLINK'
In the 6.0 data tested, STC14DSN was always blank; STK is
investigating why.
-Variables 13FLG,14FLG,13HID,14HID,13SEQ,14SEQ,13VTI,14VTI
and STC13OID are archaic and always missing; those fields
only existed prior to version 5.0.
Thanks to Ruth Whitney-Parker, CitiGroup, USA.
Thanks to Nathan Loewenthal, CitiGroup, USA.
Change 23.278 This change was implemented in Change 23.300 and its text
was relocated into that change.
Change 23.277 Two new job status variables are created from new bits in
VMAC26J2 SMF26IX2 (old PRPRTY variable):
Oct 31, 2005 UNSPUNJB='JOB WENT*THRU*UNSPUN*IN ITS*LIFETIME?'
JOEPURGE='JOE*PURGED*DUE TO*PSO/SAPI?'
Thanks to Leendert Keesmaat, UBS AG, SWITZERLAND.
Change 23.276 -PDB.ASUMCEC variables LP0MGTTM, LPCT0OV and PCTL0OV were
VMXG70PR always zero after Change 23.021, due to incorrect logic.
Oct 31, 2005 This error was only in PDB.ASUMCEC; those variables were
correct in PDB.ASUM70PR.
-Also, ASUMCEC variables IFAUPTM, IFAACTTM, and IFAWSTTM
were not formatted with TIME12.2 format.
Thanks to Wayne Bell, UniGroup, Inc, USA.
Change 23.275 Support for CA TopSecret SMF 80 records with SMF80DTP of
EXTY80TS 103,104,105,109,255 values. This is preliminary support,
IMAC80A as the DSECT does not exactly match the SMF record, so
VMAC80A further validation is required. Dataset TYPE80TS is
VMXGINIT created from all of those DTP values.
Oct 28, 2005
Thanks to Chris Hober, Charles Schwab, USA.
Thanks to Neil Ervin, Charles Schwab, USA.
Change 23.274 The MACRO definition for MACRO _N120 was missing the text
VMAC120 MACRO for each of the _NULL_ entries; attempting to use
Oct 27, 2005 the _N120 macro to null out all datasets failed.
Thanks to Xiaobo Zhang, ISO, USA.
====== Changes thru 23.273 were in MXG 23.08 dated Oct 27, 2005=========
Change 23.273 NOT SORTED error in building PDB.ASUMCEC (error was right
VMXG70PR after the - IFA2 FOR CEC note on the log) can occur with
Oct 27, 2005 some data values. The reset of STARTIME to the nearest
minute (in EXCECTIM) caused the out of order condition,
which is now corrected by a PROC SORT.
Thanks to Joe Montana, Acxiom, USA.
Change 23.272 -First MXG 23.08 only. ARRAY SUBSCRIPT OUT OF RANGE error
VMAC7072 due to MXG logic introduced in Change 23.237 to count IFA
Oct 27, 2005 and IFL engines using the (new-in-z9) SMF70CIN values in
new NRIFACPU and NRIFLCPU variables (which are non-zero
ONLY if you have a z9 processor that puts IFA and IFL in
the SMF70CIN field). The new logic was fine, but the new
LCPUADDR values that are greater than the number of real
engines in the LPARNAME='PHYSICAL' caused the failure.
The solution was to relocate the LPARNAME='PHYSICAL' test
that sets MXGCIN='PHY' above the test for LCPUADDR.
-New MACHTIME was in the year 2041; the SMF documentation
had SMF70HWM after SMF70LAC, but the new SMF70HOF field
was inserted between LAC and HWM in z/OS 1.7.
Thanks to Joe Montana, Acxiom, USA.
====== Changes thru 23.271 were in MXG 23.08 dated Oct 25, 2005=========
Change 23.271 An unknown NAF record segment caused the record to be
VMACNAF DELETEd, so subsequent segments were not OUTPUT. The
Oct 22, 2005 DELETE was removed and the number of messages limited,
and a hex dump of the first five unknown records is now
printed on the SAS log.
When documentation for the 'C0' segment is found, the
segment causing the problem will be supported.
Thanks to Joe Babcock, JPMC, USA.
Change 23.270 Due to popular demand, though I really fail to see the
VMAC7072 need, I've put back the individual IFA engine percentage
Oct 21, 2005 busy variables, PCTIFBY0-PCTIFBY9,PCTIFBYA-PCTIFBYX in
Oct 25, 2005 the KEEP= list for dataset TYPE70.
Oct 25: And now, they have non-missing values; those
variables were added in 22.09 and then removed, but even
in 22.09 their values were always missing.
Thanks to Stan Dylnicki, Royal Bank of Canada, CANADA.
Thanks tO Lawrence Jermyn, Fidelity Systems, USA
Change 23.269 z/VM MONWRITE dataset VXSYTEPM, Extended Channel Metrics,
VMACVMXA had not been data-tested for accumulated data values.
Oct 21, 2005 Now, ESCON variables ECMCPBTC and ECMCPBTL and FICON
variables ECMCBC ECMCCWUC and ECMCCWUL are DIF()'ed.
ESCON and FICON observations have different variables
populated; variable CSCCMCMG identifies FICON/ESCON.
The default _TESTMW macro invokes the _SSYTEMP macro that
does the actual deaccumulation.
-Bit CALINIT was on in one observation, uncovering a data
record that must be used to initialize the DIF() function
but then must be delete.
Thanks to Melanie Hitchings, BT, ENGLAND.
Thanks to Brian Crow, BT, ENGLAND.
Change 23.268 RMF 79 subtype 9 records had never been validated; some
TYPE79 fields are accumulated and some are not, and IBM doesn't
VMAC79 choose to document which is which, so real data is needed
Oct 20, 2005 to know that these variables had to be deaccumulated:
R799PCT R799ALC R799ATV R799CMR R799CNN R799CUB
R799DIS R799DPB R799DVB R799MEC R799PEN R799SCC
R799QUE R799UTL
in the _STY799 "Dataset Sort Macro, which is invoked by
the _S79 "Product Sort Macro".
-The TYPS79 member did invokes the _S79 macro, but that
is now also added to the TYPE79 member so you don't
accidentally create only the accumulated datasets.
-Variables R799DPB and R799PCT have clearly invalid values
but IBM documents them as "not used".
Thanks to Jerry Ellis, Liberty Mutual, USA.
Change 23.267 Optional CICS OPID field with CMODHEAD='OPID' creates new
IMACICO1 OPID variable in CICSTRAN dataset, but only if UTILEXCL
UTILEXCL was used to create an IMACEXCL, and only if a dictionary
VMAC110 record had that CMODHEAD entry, and only if the comment
Oct 20, 2005 block in member IMACICO1.
Thanks to Lucy Fukishima, California Health and Welfare, USA.
Change 23.266 Documentation. DFSORT SMF Release 16 SMF 16 records are
VMAC16 already supported; there have been no changes to the IBM
Oct 20, 2005 SMF 16 SMF record since Release 14.
Change 23.265 -MXG 23.05-MXG 23.07, the RMFINTRV workload variables with
VMXGINIT IFA and IFE CPU times were always zero; Change 23.123 did
VMXGRMFI not correctly create those workload variables.
Oct 20, 2005 -Logic was added to VMXGRMFI in Change 23.215 to determine
Nov 3, 2005 if a VIEW could be used, but macro variable name VGETENG
was not GLOBALed in VMXGINIT, which caused SAS error that
MACRO VARIABLE UNRESOLVED errors!
Nov 3: Text updated. Adding VGETENG also required there
be a //INSTREAM DD, which has been in MXGSAS JCL
for years, but I never told ITRM this change made
it now required that their JCL also have this
DDNAME.
Nov 28: See Change 23.298 which eliminated the use of the
//INSTREAM in VGETENG to avoid this exposure.
Thanks to Wolfgang Vierling, Allianz, GERMANY.
Change 23.264 The subtype 31 SARR records had a coding error; the code:
VMACSARR IF SV31IOF+SV31ILN-1 LE LENGTH AND SV30ILN GE 1 THEN DO;
Oct 19, 2005 should have been:
IF SV31IOF+SV31ILN-1 LE LENGTH AND SV31ILN GE 1 THEN DO;
Thanks to Wim Desmecht, NV INFOCO, BELGIUM.
Change 23.263 The length of MXG-created variable CPCFNAME, which is the
VMXG70PR concatenation of CPUTYPE and CPCMODEL, was increased from
Oct 12, 2005 $8 to $10 because an Amdahl GS2108E system has 2000-2108E
for CPCFNAME, which wouldn't fit in 8 bytes.
Thanks to Steve Rowe, DST Systems, Inc, USA.
Change 23.262 Documentation note only. If you get these error messages
BUILDPDB VARIABLE LOCLINFO HAS BEEN DEFINED AS BOTH CHAR AND NUM
Oct 12, 2005 DATASET WORK.TYPE30_4 MAY BE INCOMPLETE
The error is due to a corrupted SPIN library (due to a
prior failure when testing a %UTILBLDP or BUILDPDB run
that didn't complete successfully).
- If this is still in testing, and there WAS nothing of
value in the SPIN library, then you only need to use
PROC DELETE DATA=SPIN._ALL_; and can then re-test.
- If this should happen after BUILDPDB/UTILBLDP is in
production and you had data in the SPIN data library
(VERY RARE, because you had to have done something to
MXG to cause this failure and then tried to run the
production BUILDPDB job), then you must restore the
//SPIN data library to the way it was prior to what
you did that caused the failure, from the last PDB
data library from the last succesful BUILDPDB. This
is easy, because BUILDPDB backs up your SPIN library
datasets into each PDB data library, so you would use:
//YESTER DD DSN=YOUR.LAST.PDB,DISP=SHR
//SPIN DD DSN=YOUR.SPIN,DISP=OLD
PROC COPY IN=YESTER OUT=SPIN;
SELECT SPIN: ;
(the 'colon' is the wildcard in the SELECT statement).
Change 23.261 Invalid Extended Segment section in SMF 14 record caused
VMAC1415 INPUT STATEMENT EXCEEDED RECORD LENGTH error; MXG logic
Oct 11, 2005 tried to read the rest of the record after detecting this
bad segment, but the rest of this record was also trash,
so now, the error messages are printed:
***ERROR.TYPE1415.EXTENDED INFO SEGMENT DEFECTIVE
TYPE1415 OBSERVATION WAS NOT OUTPUT.'
and the rest of the INPUT is now skipped.
Thanks to Sidney Owens, District of Columbia Government, USA.
Change 23.260 Linux under z/VM dataset VXAPLSLM variable PGFAUMI label
VMACVMXA said "PAGE*FAULTS*MINOR*ONLY" but the field contained the
Oct 6, 2005 MAJOR*ONLY faults. This change creates PGFAUMJ with the
Oct 13, 2005 MAJOR*ONLY faults, and corrects the value in PGFAUMI so
it is the MINOR*ONLY to match it's label.
Oct 13: Original divide changed to multiply.
Thanks to Kris Ferrier, State of Washington DIS, USA.
Change 23.259 The SMF _ID macro for some early SMF records didn't start
VMACWYLB with _ID; this change adds the "standard" ID maro name of
Oct 4, 2005 MACRO _IDxxxx nnn % to replace those archaic spellings,
but the original macro can still be used, since the code
IF ID=_oldname OR _ID= _IDxxxx THEN DO;
is used in these members:
Oldname Standard
_WYLBUR _IDWYLB
Thanks to Freddie Arie, Merrill Consultants, USA.
Change 23.258 Support for SYSVIEW for IMS user SMF records.
EXSYSIDL dddddd Dataset Description
EXSYSIEV SYSITR SYSITRAN SYSITR: SYSV/IMS TRANSACTION
EXSYSIPG SYSIPG SYSIPGM SYSIPG: SYSV/IMS PGM
EXSYSISC SYSIDL SYSIDLI SYSIDL: SYSV/IMS DLI
EXSYSITI SYSISC SYSISCH SYSISC: SYSV/IMS SCHEDULE
EXSYSITR SYSITI SYSITIM SYSITI: SYSV/IMS TIMERS
FORMATS SYSIEV SYSIEVT SYSIEV: SYSV/IMS EVENT
IMACSYSI This code is still in early testing, but because all of
TYPESYSI the test file has only the TRN, CNT and CLK segments, and
TYPESYSI exactly one each, and multiple segments doesn't make any
TYPSSYSI sense for the transaction, I now combine those three into
VMACSYSI a single obs in the SYSITRAN dataset. Because none of
VMXGINIT other segments are populated, the code, for now creates a
Oct 5, 2005 separate dataset for each segment, which may or may not
be the final design.
-Also, there is undocumented data in the records. While
the triplet count is 3 and the first three triplets are
populated for the TRN, CNT, and CLK segments, the eighth
triplet, "WRK" is also populated, pointing to a segment
with at least 8 populated TODSTAMP fields, but the WRK
segment is not described in the DSECT.
Thanks to John Rivera, (i)Structure, USA.
Thanks to Ken Steiner, (i)Structure, USA.
Thanks to David Zelmer, (i)Structure, USA.
Change 23.257 All variables created from TEMP were LENGTH $200, even
VMACTPMX though the actual INPUT was INPUT TEMP $VARYING16. And,
Oct 4, 2005 variables JBBND and JLIMT should have had $VARYING17. as
they can contain two levels and a period. So, lacking a
clear knowledge of exact maximum lengths, I folded all of
the $VARYINGnn (nn=6,14,16,64,80), into (nn=17,80) using
only TEMP17 and TEMP80 variables to set the kept lengths.
Note that as long as the MXG default option COMPRESS=YES
is still in effect, essentiall no space was wasted even
when the length was $200.
Thanks to Lawrence Jermyn, Fidelity Systems, USA.
Change 23.256 Updated revision; warning messages RMFV022W and RMFV023W
ASMRMFV could be incorrectly issued, ASI data would be missing
Oct 4, 2005 and ASMRMFV would set Return Code 4.
Thanks to Jerry Urbaniak, Acxiom CDC, USA.
Change 23.255 The text for several TNG metrics in $MGTNGVN format were
FORMATS truncated in their VALUE statement, printing MXG messages
Oct 3, 2005 about UNKNOWN fields. Fields 31,34,36,37,46,and 113 for
the NT data for the SMPT Server Object were corrected.
Thanks to Peter Krijger, ANZ National Bank Limited, NEW ZEALAND.
Change 23.254 The ADOCMWSU member for HP MeasureWare for Sun has been
ADOCMWSU updated with the REPORT command syntax that creates the
VMACMWSU data fiels with the fields that TYPEMWSU expects.
Oct 3, 2005 -VMACMWSU's test for TYPE was expanded to test 'TRAN' so
Oct 5, 2005 those records will now be output.
Thanks to Albert Jacobs, KBC Bankverzekieringsholding, BELGIUM.
Change 23.253 Initial rewrite of the ASUMTAPE program that combines
ASUMTAPE MXG's Tape Mount TYPETMNT data with IBM's Tape Dismount
VMACTMNT TYPE21 SMF data to create PDB.ASUMTAPE dataset, with the
VMAC21 start and end times of the mount, the dismounted time,
Sep 30, 2005 and bytes read, written, and any tape error counts.
Oct 19, 2005 Because the "Exit-Driven" architecture of ASMTAPEE ML34+
captures all mounts and populates all JOB-related data,
only the PDB.TYPETMNT and PDB.TAPES (a/k/a TYPE21) are
needed to create PDB.ASUMTAPE. (PDB.TYPETALO was used
to populate missing fields when mounts were sampled.)
-The SPIN.SPINMOUN and SPIN.SPIN21 will hold incomplete
mount/dismount records, to be reintroduced tomorrow.
-These variables, from the allocation event, are no longer
created in PDB.ASUMTAPE:
ALEERROR ALOCEND ALOCSTRT ALOCVLTM RDRTM SMFUCB
SMFVOL01 TERMNAME TMNT008I XMEMABND
-These job-related variables were only in the Allocate
record; they are now created in PDB.TYPETMNT and will be
created in PDB.ASUMUOW, but they will be blank until the
ASMTAPEE monitor program adds them to the mount record:
PROGRAM RESGROUP RPTCLASS SRVCLASS WLMNAME
-VMAC21 now sets BLKSIZE=. if SMF21LB is not on.
-"Group" definition macros, _GRPMNNM and _GRPMNCD, are now
added in ASUMTAPE to group SYSTEMs that have overlapping
DEVNRs. Using the example in the comments to create a
_GRPMNNM variable, ASUMTAPE groups BY _GRPMNNM DEVNR so
each "location/group" is analyzed correctly.
-A macro _DEBUG is defined in ASUMTAPE, and when invoked
it will print a log of the sequence of mount, dismount
and allocation records for diagnostics if there is a
problem case observed; if you can also send the JOBLOG of
the job(s) involved, it will help our investigations.
-This revision is in early testing; it appears to work
perfectly when there is a match of mount/dismount, and
it recognized back-to-back dismounts (i.e., missed mount)
in variable STATUS, but it needs extensive validation and
comparisons to the SYSLOG of weird cases before I can
fully say it's ready for prime time.
-In testing this revision, I discovered that ASMTAPEE at
ML-34 thru ML-36 do NOT capture all tape mounts in their
exit logic: these are two known cases of missed mounts:
- Multi Volume Mounts - Only first Mount is captured in
the IBM Volume Mount Exit; STK's HSC exit sees all.
- DFHSM Mounts to 3590s - None captured, but mounts for
other jobs on 3590s are captured.
An investigation by "asmguy" has just been started today
as a result of this (unwanted!) discovery, which will
likely require SLIP traps, dumps, and possibly multiple
iterations to find out why these mounts were not seen.
-Oct 19: Macros _grpALxx are renamed to _grpMNxx to be
consistent; AL is for allocation and MN is for mounts,
and ASUMTAPE should be used instead of TYPETMNT for tape
mounts.
-See further revisions in Change 23.300 and later.
Thanks to Normand Poitras, IBM Global Services, CANADA.
Thanks to Beau Chavis, Bank of America, USA.
Thanks to Jim Sherman, Lockheed-Martin, USA.
Change 23.252 TMS/CA-1 DEVTYPE variable was blank for TRTCH='E2'X, but
VMACTMS5 now DEVTYPE='STK9840-C' is decoded for that TRTCH value.
Sep 29, 2005 DEVTYPE='STK9842' already was decoded for TRTCH='E7'X.
Thanks to John Gebert, FDIC, USA.
Change 23.251 Enhancement to set TRANNAME in PDB.ASUMUOW from CICSTRAN
VMXGUOW observation in each Unit of Work that was not the CSMI
Sep 29, 2005 transaction but that had the longest IRESPTM duration, as
a more robust identification of the "real" transaction.
Thanks to Chuck Hopf, MBNA, USA.
Change 23.250 OPTIONS NODSNFERR NOVNFERR; was missing from the TRNDCACH
TRNDCACH member; it is needed to protect the first-time-through,
Sep 28, 2005 when the TREND.TRNDCACH member doesn't yet exist.
All other TRND members had that option, so I assume it
was inadvertently deleted.
Thanks to Tom Kelman, Commerce Bank of Kansas City, USA.
Change 23.249 Using %READDB2 to process DB2 Trace 102 SMF record now
ANALDB2R decodes the DBID and OBID values, if you enabled 105/107
READDB2 IFCIDs, and those records are in the input SMF data file.
VFMT102 (Previously, only the %ANALDB2R report printed the real
Oct 22, 2005 names of the OBID or DBID). Formats $MGDB2DB/$MGDB2OB
are created by VFMT102 member, used by both ANALDB2R and
VMAC102, if 105 or 107 records were found, but only cover
the time frame of the trace, since DBID and OBID can
change. The 105/107 records are only written at OPEN,
and the formats use the timestamp range of the data read
by READDB2, so you may still find $HEX4. values for the
DBID and OBID variables some of the time.
Thanks to Chuck Hopf, MBNA, USA.
Change 23.248 An ending */ was missing in the exit member, but there
EXDB2ACC were subsequent end comments that apparently prevented an
Sep 22, 2005 error, as this was observed by Bruce, rather than the
result of a reported error condition. Sometimes, a
missing end comment, even when there are subsequent ends
for other comments, has caused strange errors.
Thanks to Bruce Widlund, Merrill Consultants, USA.
Change 23.247 ML-36 of ASMTAPEE corrects a problem in the Allocation
ASMTAPEE Monitor introduced in ML-35 that cause a major increase
Sep 22, 2005 in the CPU time of the MXGTMNT task.
Thanks to Normand Poitras, IBM Global Services, CANADA.
Change 23.246 Support for adding un-sorted datasets to your WEEKly PDB.
WEEKBLD MONTHxxx programs supported adding unsorted datasets by
WEEKBLDT using MACRO _BY % MACRO _SORTBY % in place of
WEEKBLDD the normal MACRO _BYLIST var1 var2 % definition, but the
WEEKBL3 WEEKxxxx programs were not revised to define those two
WEEKBL3D macros, until now. As a reminder, once these two macros
WEEKBL3T have been specified, all subsequent datasets will be
Sep 16, 2005 treated as non-sorted, so the un-sorted dataset build
macros should be at the very bottom of your EXPDBWEK or
EXPDBMON tailoring member.
Thanks to Cheryl Heiner, State of Montana, USA.
Change 23.245 A single quote (') in the WLM data for a variable was not
REXXWLM converted to two single quotes (''), which could cause a
Sep 16,2005 SAS error.
Thanks to Sam Bass, McLane Company, USA.
Change 23.244 NO LONGER TRUE, FIXED BY SAS IN 2005. Original text:
VGETDDS Using MXG's %VGETDDS(DDNAMES=XYZ: ...) and %VMXGSET to
VMXGSET read from all SAS data libraries in your JCL that have
Sep 16, 2005 DDNAMES starting with "XYZn" can fail to read all DDs,
but ONLY if you have installed the IBM PATCH for HSM that
is documented in IBM APAR OY63500, and ONLY if one of the
"XYZn" datasets is independently being migrated by HSM!
That PATCH allows HSM to bypass normal DSENQ protection;
the site runs an HSM job every 30 minutes to migrate data
from ML0 to ML2. The HSM task started the migration, and
then the MXG job started to run (because DSENQ had been
bypassed). VGETDDS tests each XYZn DD with PROC SQL to
find its ENGINE, but SAS did not recognize that XYZ3 was
a SAS Data Library in its DICTIONARY.MEMBERS table (due
to its migration-in-progress status), so VGETDDS saw
UNKNOWN engine, and stopped its search for other XYZn
DDNAMES when the first UNKNOWN engine type is found.
Since VGETDDS only saw XYZ1 and XYZ2, the XYZ3 DDNAME
was never opened by SAS, so the OPEN ABEND discussed in
the IBM APAR text never happened.
If you have the "PATCH" in OY63500, and you permit your
PDBs to be migrated by HSM while trying to use one, there
is no possible MXG fix for this error; the only clues
that there was an error was that many fewer obs were
read than expected, and/or the VGETDDS message on the log
explicitly said it only found two XYZn DDNAMES.
(But the whole point of VGETDDS/VMXGSET is so your JCL
determines how many XYZn DDNAMES are read, and so you
DON'T have to tell me how many to expect!).
The only way to prevent I can think of is to put these
PDB libraries in a dataclass that is not migrated by the
interval task, to eliminate the exposure.
Change 23.243 Enhanncement to RMF III VSAM support ASMRMFV/TYPERMFV.
ADOCRMFV -ASMRMFV corrects a few issues, reduces CPU utilization by
ASMRMFV use of MVCL instruction, and adds the ASI Extension that
CLRMFV had been requested by Lawrence Jermyn, along with other
DOCLRMFV minor changes. The ASI Extension improves the ability to
VMACRMFV subset and group RMF Monitor III data for historical
Sep 15, 2005 analysis at the Address Space level. This version also
Sep 16, 2005 offers additional Assembly Language symbolics to let you
tailor the ASMRMFV defaults.
-CLRMFV: There are no changes to the CLIST; its just here
as a reminder that it is used to process RMFV data.
-ADOCRMFV: Extensive notes on what Jerry did are added!
-DOCLRMFV: Updated notes.
-VMACRMFV:
Variables
ASICNM ASICDE ASICWN ASICRN ASICPO ASICPN
ASICGI ASICWI ASICRC ASIRNM ASIRDE ASIVERG3
were added to ZRBASI dataset. ASIVERG3 values '0F'x and
greater indicate that the zAAP fields are present in the
records.
-Sep 16: Old SVP Buffer Table cleanup added.
Thanks to Jerry Urbaniak, Acxiom CDC, USA.
Change 23.242 Support for SMF type 82 subtypes 20 and 21 is added.
EXTY8220 Subtype dddddd Dataset Description
EXTY8221 20 TY8220 TYPE8220 Crypto Coprocessor Timings
FORMATS 21 TY8221 TYPE8221 ICSF Sysplex Group Change
IMAC82 -In TYPE8220, MXG variables NQAPDQAP and DQAPWAIT are the
VMAC82 calculated delta times between TNQ-TDQ and TDQ-TWT, after
VMXGINIT using the TWT-SMFTIME delta to create GMT82OFF. Since it
Sep 12, 2005 is the coprocessor duration, and not time of day, that is
of interest, the original SMF82TNQ, SMF82TDQ and SMF82TWT
variables are not kept.
-SMF82TSF, Coprocessor sub function code is not documented
in the SMF manual; it is a $HEX4. value, and will be
formatted when it's possible values are known.
-SMF82TRN will be missing until you install z/OS 1.7.
-TYPE8221 code has not been tested with records, yet.
Thanks to Ian Arnett, TD Canada Trust, CANADA.
Change 23.241 Two more typos: NR25SEGS in the WHEN (24) group should
VMAC80A have been NR24SEGS, and NR44SEGS in the WHEN(43) group
Sep 12, 2005 should have been NR43SEGS.
Thanks to Bill Arrowsmith, Euroclear, BELGIUM.
Thanks to Stephen Morris, National Australia Bank, AUSTRALIA
Change 23.240 IRESPTM, the response time of the CICS Unit of Work, and
VMXGUOW ELAPSTM, the total elapsed duration of the DB2 portions
Sep 9, 2005 of the Unit of Work, some which could be in parallel,
are revised. IRESPTM is now the maximum of the CICSTRAN
segments in this unit of work, while ELAPSTM is the sum
of the individual elapsed times of the DB2ACCT segments,
in the PDB.ASUMUOW dataset built by INCLUDE of ASUMUOW.
In addition, new variable DB2IDLE, which was originally
created by archaic ANALDB2C, but lost when ASUMUOW was
built, is now created. DB2IDLE is the elapsed time from
last CICS ENDTIME to the DB2 QWACESC End time, and is the
duration when the DB2 thread was idle, but has not ended,
presumably for possible thread reuse. DB2IDLE is then
subtracted from the sum of the DB2ACCT ELAPSTMs, so the
final ASUMUOW ELAPSTM does NOT include DB2IDLE time.
-This change can make ELAPSTM smaller than before, for
serial transactions that had DB2IDLE time.
-This change can make ELAPSTM larger than before, for DB2
Parallel transactions (DBPARTY='P'), because the prior
ELAPSTM was start to finish. But since parallel=3 can
burn 3 hours of CPU time, the elapsed time must be the
sum of the parallel elapsed time, rather than start to
finish of the unit of work.
-In addition, the _TRANUOW user exit has these additional
variables available for examination, etc.
HOLDIRSP: MAX of IRESPTM from CICSTRAN
HOLDELAP: SUM of ELAPSTM from DB2ACCT
HOLDFSTR: Min of CICS STRTTIME start datetime
HOLDLSTR: Max of CICS STRTTIME start datetime
HOLDFBSC: Min of DB2 QWACBSC begin datetime
HOLDLESC: Max of DB2 QWACESC end datetime
Thanks to Hugh Lapham, Royal Canadian Mounted Police, CANADA.
Change 23.239 Support for DURATM keywords TENMIN and FIVEMIN. Code had
VMXGDUR been added in VMXGDUR, but not in VMXGSUM. Obscure notes
VMXGSUM in member VMXGSUM did say that if you use DURATM= with an
Sep 9, 2005 unsupported keyword, variable DURATM will not be created.
The actuality is that these DURATM= values:
SECOND MINUTE FIVEMIN TENMIN QTRHOUR HALFHOUR
HOUR THREEHOUR DATE WEEK
do create variable DURATM, while these DURATM= values
MONTH and SHIFT
do not create variable DURATM.
Thanks to Tom Kelman, Commerce Bank of Kansas City, USA.
Change 23.238 Sites that run UTILEXCL daily to create IMACEXCL code
UTILBLDP (due to frequent CICS dictionary changes), normally write
Sep 8, 2005 their IMACEXCL code to a "flat file" rather than a PDS
(avoids need to compress the PDS), adding //IMACEXCL DD
to point to that code, and adding %INCLUDE IMACEXCL;
using MACKEEP= logic. However, the include of an external
DD statement was not supported in UTILBLDP. Now, it is,
with the new IMACEXCL= argument.
Thanks to Chuck Hopf, MBNA, USA.
Change 23.237 -Variables NRIFACPU and NRIFLCPU are added to PDB.ASUM70PR
VMAC7072 and PDB.ASUMCEC datasets built by ASUM70PR for processors
VMXG70PR that populate 'IFA' and 'IFL' in SMF70CIN (only z9 now).
Sep 7, 2005 Variables LPnDSA are now labeled.
-MXGCIN variable now contains new IFA and IFL values.
Change 23.236 Support for Endeavor Release 7; there were no changes to
VMACENDV their user SMF record.
Sep 6, 2005
Thanks to Herb Strozinsky, US Bank, USA.
Change 23.235 DB2TCBTM for Rollup observations (DB2PARTY='R') is wrong
VMACDB2 and could be less than QWACAJST (the TCB time in DB2).
Sep 6, 2005 APAR PQ41012 documented that in rollups the accumulated
Elapsed and TCB were in QWACESC & QWACEJST, but only the
elapsed time was corrected in Change 22.121. Now, the
DB2TCBTM is recalculated when DB2PARTY='R' is set, using:
DB2TCBTM=SUM(QWACEJST,QWACSPCP);
(The final component, QWACTRTE is added in later.)
Thanks to Scott Barry, SBBWorks, Inc, USA.
Change 23.234 Peter Enrico's presentation at SHARE in August 2005 had
GRAFWLM graphs of CPU utilization grouped by SYSSTC, SYSTEM, work
Sep 8, 2005 with a goal, and work without a goal, to show how much
work could or couldn't be managed by WLM. This analysis
produces similar SAS/GRAPH stacked bar charts, showing
CPU Time and MSU consumed by these groupings from top to
bottom:
UNCAPTURED
SYSTEM
SYSSTC
IMP 1 CPU CRITICAL
IMP 1
IMP 2 CPU CRITICAL
IMP 2
IMP 3 CPU CRITICAL
IMP 3
IMP 4 CPU CRITICAL
IMP 4
IMP 5 CPU CRITICAL
IMP 5
SYSOTHER
(All unclassified discretionary work - should have
no unclassified work!)
DISCRETIONARY
(All work classified as discretionary, regardless
of importance. Discretionary work is work in a
service class period that does not have a goal.
An example of the output can be viewed at
http://www.mxg.com/samples/grafwlm
See comments in the member for usage documentation.
Thanks to Peter Enrico, Enterprise Performance Strategies, Inc.
Thanks to Chuck Hopf, MBNA, USA.
Change 23.233 Several corrections and enhancements to Web Log support:
VMACWWW -ELAPSTM, at least for BEA WebLog was way too small; their
Sep 2, 2005 "time-taken" field contains 'seconds.fraction' value, but
Sep 3, 2005 MXG expected a millisecond integer value. Now, MXG will
detect a period in the time field, and inputs ELAPSTM as
'seconds.fraction' when a period is found; otherwise, the
field is input and divided by 1000 to get seconds.
-Example FILENAME now has LRECL=4096 to match the INPUT
$VARYING4096. If LRECL was not specified, LRECL=255 is
the default, which causes "ONE OR MORE LINES TRUNCATED".
-TRANSLATE(RECORD,' ','09'x); added, because BEA log has
a hard tab, '09'x between fields instead of blanks.
Dealing with '09'x can be nasty, since it is usually
turned into a blank by most editors, and blanked by
SAS when input records are displayed, so you often
don't even know there's an '09'x value, until your
read and display the field in hex, using:
INPUT FIELD $CHAR50.; PUT FIELD= $HEX100.;
-Change 23.026 protected one of the two URIQVALU=SUBSTR();
now both are protected for URIQVALU=0, which happens when
when an = in the URIQUERY string is immediately followed
by an &, causing LTOAND=1 and thus causing URIQVALU=0.
-Vars BYTES CSBYTES LBYTES SCBYTES now LENGTH &MXGBYLN.
Before Change 23.026, CSBYTES and SCBYTES were kept as
length $4096 because MXG used CSBYTES=WORD(....); and
WORD's is $4096, so CSBYTES/SCBYTES wasted space when
SAS compression was not used (COMPRESS=YES is default).
That change made them numeric, saving space, but they
were now 4-byte length due to MXG's DEFAULT=4. However,
byte-containg fields need more resolution, and thus they
are now properly set to LENGTH &MXGBYLN. ;
-BYTES added to KEEP= list for _VWWWIIS and WWWIIS22 was
added to $16 length statement.
Thanks to Andrzej Dabrowski, Computing Services, CSIR, SOUTH AFRICA.
Change 23.232 NDM dataset NDMPS ('PS'/'SW' records) now has variables
VMACNDM PSSDSN='DSNAME' and PSSDSNL='LENGTH OF*DATASET*NAME'
Sep 1, 2005 both input and kept, if this is an 'SW' subtype.
-Missing value messages were eliminated for DATE fields
that are known to have missing values; MXG now tests the
DATA field before constructing the DHMS function inputs.
Thanks to Tom Neurauter, Fidelity Systems, USA.
Change 23.231 Support for DB2 IFCID=225 variables
VMAC102 QW0225FA QW0225GA QW0225VA QW0225SJ
Sep 1, 2005 that report DB2 storage used "Above The Bar".
Thanks to Valerie J. Chisholm, Aetna, Inc, USA.
Change 23.230 "EXIT-DRIVEN" MXGTMNT Tape Mount Monitor is AVAILABLE!!
ASMTAPEE ML-35 should be the FINAL iteration in this major effort
ASMHSCEX that replaces the original sampling tape mount monitor
Sep 1, 2005 (it sampled the tape UCBs every 1/2 second, working just
fine for many years of real tape drives, but sampling
now misses many of your very fast VTS tape mounts)
with this event driven monitor that instead uses exits to
capture EVERY tape mount for real drives, silos, and/or
VTS devices, whether mounted by IBM or STK software.
-What's now available is this enhancement that supports
multiple instances of STK's HSC and/or CSC running in the
same system.
-The Exit Driven architecture has been available for some
time, using the IBM Volume Mount exit for all real tape
devices (whether IBM or STK drives), and for IBM VTS.
It was the enhancement to use the STK User Exit in their
HSC and CSC software, used for STK Silos and STK VTSs,
that was extremely difficult to develop, primarily due to
the complete refusal of STK to provide any technical help
(i.e., STK wouldn't/couldn't tell in which address space
their exit was executed!), so MXG's asmguy@mxg.com had to
figure it all out without assisance from that vendor.
-Both ASMTAPEE and ASMHSCEX were updated by this change.
-The solution for multiple HSC/CSC is in the new ASMHSCEX,
which now create two exits, SLSUX01 for HSC, and SCSUX01
for CSC, so all you're HSC guru will have to do is to
define the appropriate exit to whichever one (or ones)
your site is running for your STK Silos and VTSs.
-What to do when both are run:
There may be a little extra overhead for those sites that
run multiple exits on the same system, but that won't
affect a site that only runs one exit. Exit 01 in HSC or
CSC behave the same; either exit will provide the
information we need. With ML-35, you can run any number
of those exits, but now, we'll create only one record per
tape mount!
Asmguy's advice when both are running is to pick one,
whichever is most likely to be active all the time, and
define the exit to it. If you want to run multiple exits
on the same SYSTEM, ML-35 will allow this, but there is
additional overhead involved. If you chose to do this,
you can just define the exits as you would normally, and
no change is required to ASMTAPEE, as it automatically
will detect that multiple exits are running, and respond
accordingly.
-ML-35 ASMTAPEE is NOT compatible with earlier ASMHSCEX.
You must use the ML-35 ASMHSCEX with the ML-35 ASMTAPEE.
- ML-35 corrected several old ASM coding exposures found by
Dick Zieske, mostly dealing with cleanup of CSA when
MXGTMNT is cancelled, rather than STOPed, or if MXGTMNT
ever ABENDS (which has never happened in production)!
- Sampling is still used for Tape Allocation records.
Thanks to "asmguy@mxg.com" who has figured out how to use the HSC/CSC
exits in spite of complete lack of help from STK.
Thanks to Dick Zieske, AIG, USA.
Thanks to Steve Martin, Fidelity Systems, USA.
Thanks to Paul Naddeo, FiServ, USA.
Thanks to Jeff Holst, FiServ, USA.
Thanks to Normand Poitras, IBM Global Services, CANADA.
Thanks to Dan Squillace, SAS Institute Cary, USA.
Thanks to Shirley Fhng, Hong Kong Shanghai Bank, Hong Kong.
Thanks to Shane Dowling, DEWR, AUSTRALIA.
Thanks to Scott Chapman, American Electric Power,USA.
Thanks to Patricia J. Jones, DST Systems, USA.
Change 23.229 Support for DEVTYPE='3592' tape devices. Observations
VMACTMS5 were output by MXG for those devices, but variable DEN
Aug 31, 2005 was not decoded, causing "DENSITY IS MISSING" non-fatal
log messages; more important: variable DEVTYPE was blank.
DEN and DEVTYPE are populated by table lookup in the MXG
program, after I find out what hex value CA has chosen.
Thanks to Todd Wright, CSC Australia, AUSTRALIA.
Change 23.228 INPUT STATEMENT EXCEEDED RECORD error from IBM ATL record
VMACEREP that had a message shorter than the 96-bytes that MXG had
Aug 31, 2005 hardcoded for the INPUT of ETRMESSG. Code was revised.
Thanks to Steven Clark, DHL, USA.
Change 23.227 The NDMCT dataset contains accumulated NDMCPUTM for multi
TYPENDM step processes; deaccumulation is always done by MXG in
VMACNDM the "_Sdddddd" macro, the "Data Set Sort" macro, so the
Aug 31, 2005 heuristic logic to sequence and deaccumlate adjacent data
was added to the _SNDMCT macro.
-The TYPSNDM macro automatically sorts the output, but if
you have added processing of NDM data to your BUILDPDB,
you should replace your PROC COPY; SELECT NDM:; with the
"Product Sort" macro _SNDM in your EXPDBOUT member to
sort all of the NDM datasets, and deaccumulate NDMCT.
-If you are using ITRM, you only need the _SNDMCT "Dataset
Sort Macro" in your EXPDBOUT, since ITRM will separately
handle the adding of the other NDM datasets to DETAIL.
-While the TYPExxxx members normally only write to //WORK,
when an xxxx product requires deaccumulation, I add the
_Sdddddd data set sort macro (s) to the TYPExxxx member
to ensure you don't accidentally use the unaccumulated
data, so _SNDMCT was added to the TYPENDM member's code.
Thanks to Thomas Clark, SEI Investments, USA.
Change 23.226 Nearly Cosmetic. MXG deleted STK subtype 4 records that
VMACSTC were in error (see Change 23.125), but did not print a
Aug 30, 2005 message on the log that you were missing that PTF.
Now it does advise you that records were deleted.
Thanks to Chuck Hopf, MBNA, USA.
Change 23.225 Requesting RUNTRND=DAILY in %BLDSMPDB did not work as
BLDSMPDB expected.
Aug 30, 2005
Thanks to Tom Kelman, Commerce Bank of Kansas City, USA.
Change 23.224 Cosmetic corrections found during ITRM dictionary build.
VMXG70PR -TYPE70LP: SMF70DSA was not labeled.
VMACCMF -CMF27C93: C2795RFL,C2795RTY "THUS:" removed from label.
VMACNDM -NDMRJ: NDMJOBNM,NDMRJDSN,NDMSYSRC were not labeled.
VMAC79 -TYPE791/TYPE792: R791NFFI,R792NFFI were not labeled.
Aug 30, 2005
Thanks to Chris Weston, SAS Institute ITRM Cary, USA.
Change 23.223 Support for Mobius/IPAC Release 6.3 (INCOMPAT, because of
EXIPAC08 changes in the length of IPSPAGE/IPEPAGE fields in the
IMACIPAC subtype 1 record). Other changes in this release:
VMACIPAC -New variable IPPACCES='PAGE*ACCESSED*COUNT' in IPAC03.
VMXGINIT -Variable IPLOC is now $8; it includes the former reserved
Aug 30, 2005 one following byte.
Aug 31, 2005 -New subtype 8 creates dataset IPAC08, similar to IPAC03.
-But, there still is no change in their VERSION field, so
the LENGTH of the record must be used to identify the new
data added to the subtype 1 and 3 records.
-And, the vendor documentation for Release 6.3 does not
document the SMF records they write:
The REQSTART and REQEND documentation is unchanged, but
records show the values are reversed physically, with
END first and START last, and the format of their time
part still says 0hhmmssF, but the data shows four-byte
EBCDIC numeric HHMM value.
The vendor's technical support chose not to compare the
hex dump of their defective record we sent, which shows
the START field with 2208 and the END field with 2205,
but simply replied that their their dsects were the
definitive documentation source.
Just in case they ever acknowledge their error, and fix
their code so the records match the "definitive" DSECT,
MXG code now tests START versus END and reverses their
values if necessary.
Thanks to Erik Janssen, ING Netherlands, THE NETHERLANDS.
Thanks to Debby Blackey, HCA Health Care, USA.
Change 23.222 Change 23.216 was updated for APAR OA10346; new values
VMAC7072 in SMF70CIX for "IFA", "IFL", are now used to create new
Aug 29, 2005 NRIFACPU and NRIFLCPU variables, and the count of those
non-"CP" engines is subtracted from variable PARTNCPU.
Without this change, PARTNCPU included IFAs and IFLs.
MXG variable MXGCIN was also updated with new SMF70CIN.
Data from z9 processor was used to validate this change,
which also validated Change 23.186, the z9 support.
Change 23.221 The default example variable names for the TSO workload
RMFINTRV was incorrectly/accidentally changed from the historic
Aug 29, 2005 "TSO" to "TSOP" in the RMFINTRV member in MXG 22.07.
The example is now corrected so the TSO variables will
start with just the historic "TSO" prefix. If you have
your own tailored RMFINTRV member, it controlls the names
of the variables, so this change would have no impact.
However, if you were using the MXG 22.07-23.07 default,
this change could cause your reports to fail, since your
reports expect TSOP.... variable names, so your best
choice is to copy the RMFINTRV from 22.07-23.07 into your
tailoring library, and your variables will continue to be
spelled TSOPxxxx. I made his reversion because the MXG
example reports expect the TSOxxxx variable names.
Thanks to Paul N. Ross, Computer Sciences Corporation, USA.
Change 23.220 MXG logic error caused INPUT STATEMENT EXCEEDED INPUT
VMAC80A for a valid SMF 80 record that contained no segments.
Aug 30, 2005 I noted the "USER IS NOT DEFINED TO RACF" bit was on.
Originally I had the customer open a problem with IBM
for their "short record" error, because the OFFSET was
greater than the LENGTH of the SMF record, but now I am
"eating my own words", as the record was completely valid
and it was an MXG logic error that wasted both IBM's and
this MXG Customer's time:
IBM's response was completely accurate and to the point
and completely detailed the offset and locations that
proved the record was completely valid. It's one of
the best written and complete replies I've seen!
I had inserted code in MXG to read in a 4-byte test for
a vendor product, but I put the input before the group
DO _I_= 1 TO NRSET that input the segments that exist.
My input was always executed, even when NRSET=0!
That IBM reply recommended the use of the count field,
which is now done, but I also test LENLEFT GE 4 to make
sure there really are 4 bytes left to be read.
The error was overlooked when tested with the vendor SMF
because they all had the field, and there were no errors
when QA SMF 80s from several sites were read, so the code
was released in October, 2003. Since then, billions and
bullions of SMF 80 records have been read, and all had
one or more segments and no error.
I can live with those odds!
Thanks to Christa Neven, KBC Bankverzekieringsholding, BELGIUM.
Thanks to Victor_Van-Cakenberghe,IBM, BELGIUM
Change 23.219 The ICF Catalog 05 record variable GATGEN should have
VMAC6156 been input as &PIB.2., instead of one byte, and variable
VMACCTLG GATWRAP='Y' is now set if the first bit of GATGEN is on,
Aug 29, 2005 to mark that this GDG member has "wrapped"; i.e., its
generation number has exceeded 9999. If GATWRAP is on,
GATGEN=GATGEN-32768 to contain the correct Gen number.
This discovery was precipitated by IGD07001I ABENDs in
production, which occurred when a GDG that had GATWRAP
on for some members, and GATWRAP off for others, when
that GDG generation number goes from 999 to 1000.
Normally, when all members of a GDG have wrapped, the
next catalog action turns off the wrap bit in all of
the catalog records. For a "normal" GDG, that should
happen when the +256th gen is created after wrap, as
only 255 members can exist in the catalog. But this
site had had a very old application that originally
created +1 thru +5 each day, and then deleted +1 thru
+4, leaving only +5 in the catalog. However, back when
Clinton was President, an application change was made
that created only +1 thru +3 and deleted only +1 & +2,
so there were 2 old GooooVoo's left in the catalog.
When the GDG wrapped, and when the create of +1 would
have created G1000V00, those old GooooVoo's still had
their wrap bit off, and the production job failed:
IGD07001I; GDG ROLL IN ERROR - RETURN CODE 140 REASON 122
Return Code 140:
Inconsistent or conflicting arguments were provided.
Reason Code 122:
Catalog G1000Vxx will cause the GDG to exceed the
limit of 10,999.
Programmer Response:
Clean up the GDG in error then catalog G1000Vxx.
The site found Information APAR II07276, which explained
how wrap works, but it says to 'see the "Z" page for
internal details of the wrap bit interface'.
So the site asked IBM Support: "We need to identify other
GDGs that have the same exposure to causing ABENDs. Can
I look at the 'Z' page? Does the 'wrap bit' appear in
SMF 61, 65, 66 ICF Catalog records?"
IBM Level 2 Catalog Support refused to answer the quite
valid question, with this answer:
"Unfortunately, the 'Z' page in our info APARs refer to
information meant for IBM eyes only, for helping us get
to problem determination quicker. We are not at
liberty to discuss any control block internals that are
not provided in our published manuals. As for
information in SMF records relating to this, this info
would be included in the updated record portion
of the SMF record, however we cannot discuss offsets
for those either. I am sorry I cannot be more helpful.
Please let me know if there are any other questions
that I can answer for you."
Even escalation to my IBM Poughkeepsie z/OS support did
not convince IBM Level 2 Catalog Support to identify
which bit is the "GATWRAP" bit. The ICF Support and
Developers hid behind "OCO", Object Code Only, as the
reason they could not provide catalog record
documentation (but DSECTS are NOT CODE!).
So I suggested the site could create a GDG and force it
to wrap, and by examining SMF records, we concluded that
first bit of GATGEN was the GATWRAP bit.
Then, I remembered I still had lots of archaic printed
manuals, and located the very old "MVS/XA Catalog
Diagnosis Reference for DFP Release 1.2", which confirmed
that the GATWRAP bit was indeed the first bit of the
GATGEN field in the 05 Catalog Record!
Thanks to Daniel F. Schwarz, Inc, Univ of Wisconsin Hospitals, USA.
Thanks to Joseph Stoll, University of Wisconsin Hospitals, USA.
Change 23.218 Format $MGDB2PT did not have value for 'R'='R:ROLLUP'.
FORMATS
Aug 23, 2005
Thanks to Scott Barry, SBBWorks, Inc, USA.
Change 23.217 Typo at line 392 had WEEKBLD instead of _WEEKBLD.
WEEKBLDT
Aug 23, 2005
Thanks to Hugh Lapham, Royal Canadian Mounted Police, CANADA.
=Attended the 50th Anniversary meeting of SHARE, the world's first
=computer User Group, in Boston.
Change 23.216 APAR OA10346 was supported by Change 23.187, but it was
VMAC7072 revised on Aug 18, with these new enhancements:
VMXG70PR -TYPE72Y2 dataset, variables CRYIH2R and CRYIH2s created
Aug 19, 2005 for hashing rate and hashing size for SHA=256.
-Tests in VMXG70PR were revised, because SMF70CIN can now
contain "IFA", "IFL", "ICF" or "CP" to identify the type
of processor.
Thanks to Don Deese, (CPExpert), Computer Management Sciences, USA.
Change 23.215 While not "hard-coded" DDname, these two statements that
VMXGRMFI were inadvertently left in the middle of VMXGRMFI
Aug 18, 2005 %LET SPININ = SPIN;
%LET SPINOUT = SPIN;
were just as bad as hardcoded, and cause errors if you
had changed your SPIN library's DDNAME elsewhere in MXG.
Both lines were deleted.
Thanks to Ken Williams, CPT Global, ENGLAND.
Thanks to Mark Williams, Marks and Spencer, ENGLAND.
Change 23.214 Cosmetic. Label for variable A20E2HWM was corrected to
VMAC110 now read A20E2HWM='PEAK*CONTENTION*WINNERS'.
Aug 17, 2005
Thanks to Scott Wiig, U.S. Bank, USA.
Change 23.213 All SMF88xxx datetime variables were on GMT time zone.
VMAC88 Now, the GMT88OFF offset is calculated and the variables
Aug 17, 2005 are all now on the same time zone as SMFTIME.
Thanks to Don Deese, (CPExpert), Computer Management Sciences, USA.
Change 23.212 Cosmetic. Labels for RTSMAP01-RTSMAP14 were clarified to
VMAC7072 'BUCKET nn*RESPONSE TIME*GOAL*PERCENT' because they
Aug 16, 2005 contain the percentage of R723CVAL, rather than a goal
value. If you want to know the goal value of the nnth
bucket, it is RTSMAPnn*R723CVAL.
Thanks to Dave Crandall, Farmers Insurance, USA.
Change 23.211 Requesting USERADD=6 25 26J3 21 30, INCLAFTR=BUIL3001
UTILBLDP generated a MACRO _WTY26J2 _LTY26J2; statement which
Aug 16, 2005 should have been MACRO _WTY26J3 _LTY26J3 % statement.
Thanks to Hansruedi Zaugg, EDS, SWITZERLAND.
Change 23.210 MXG 23.07 only. Typo of CURRSHARE in the DROP statement
VMXG70PR should have been CURSHARE. Fortunately, there was no real
Aug 16, 2005 impact on any of the expected variables, just that the
variable CURSHARE was unnecessarily kept. The typo did
cause an error when MXG ran under V6, because the 9-byte
variable name exceeded SAS V6 limits. MXG variables are
normally also 8-bytes-max; our QA tests for name length,
but only for kept variables, and since CURRSHARE was a
typo that didn't exist in a KEEP= statement, this typo
was missed.
Note: I thought this was fixed in the final 23.07, by
Change 23.208, but I typo'd the typo, and MXG 23.07
had CURRSHAR instead of CURSHARE, so the problem was
not corrected until MXG 23.08.
Thanks to Jon Whitcomb, Great Lakes Higher Education Corporation, USA
====== Changes thru 23.209 were in MXG 23.07 dated Aug 10, 2005=========
Change 23.209 Not sure why, but the includes of VMAC7072,VMAC6,IMACKEEP
ASUMPRTR inside ASUMPRTR cause it to fail when it was INCLUDed in
Aug 10, 2005 EXPDBOUT in BUILDPDB to create the PDB.TYPE6ENH dataset.
Removing those three members from the %INCLUDE statement
in ASUMPRTR eliminated the ERROR: OLD-STYLE MACRO NAME
PDB.TYPE6 MUST CONTAIN ONLY LETTERS, DIGITS AND UNDERSC.
Those members only need to be included when SMF data is
read, and that JCL example in the comments has the needed
%INCLUDE statement, so the %INCLUDE for them in ASUMPRTR
was redundant, anyhow.
Thanks to Keith McWhorter, Georgia Technology Authority, USA.
Change 23.208 Replaced by Change 23.210.
====== Changes thru 23.207 were in MXG 23.07 dated Aug 9, 2005=========
Change 23.207 Variables IAMNOA and IAMNOP have traded places; they were
VMACIAM coded as documented, but the documentation was wrong.
Aug 9, 2005 Aug 10: it was IAMNOD and IAMNOP that traded places.
Aug 10, 2005
Thanks to Ken Wantuch, BB&T IT Systems Engineering, USA.
Change 23.206 Line 2704 contained a semicolon after SMFPSRVR, but that
ANALCISH should have been a comma. Only caused error if CFEC FEPI
Aug 9, 2005 Connection Statistics report was requested.
Thanks to Scott Wiig, U.S. Bank, USA.
Change 23.205 -Variables LPnNSW/SMF70NSW, percent when LPAR was capped,
EXCECTIM were wrong in PDB.ASUMCEC/ASUM70LP/ASUM70PR and could
VMXG70PR even be greater than 100%. Weighted average had wrongly
Aug 9, 2005 used LPARDUR instead of SMF70DSA. Logic revised.
Aug 10, 2005 -LP1LAC was always missing in PDB.ASUM70LP because of a
Nov 10, 2005 typo that had SMF71LAC instead of SMF70LAC.
-LPnLAC was often missing in PDB.ASUMCEC because logic to
select the first LPARNUM in each CECSER has been wrong.
Variable PCTMVSBY is populated only in "this system" obs
in TYPE70PR dataset, so adding DESCENDING PCTMVSBY to the
end of the sort order that creates CECCLEAN forces that
"this system" observation to be the one that is kept.
-The optional EXCECTIM member is reinstated in VMXG70PR
to change STARTIME in PDB.ASUMCEC, PDB.ASUM70PR, and in
PDB.ASUM70LP datasets to the exact nearest minute for the
summarized output's STARTIME value; observations with
slight differences caused duplicate or semi-duplicate
output. Nov 10: this paragraph revised; originally, it
said only PDB.ASUMCEC's STARTIME was changed. But, now,
you also need Change 23.289 for full short-interval fix.
-Aug 10 enhancement: VMXG70PR logic (ASUM70PR) now adds
variable LPARNSW, percent when this LPAR was capped, to
the PDB.RMFINTRV dataset, so your system-level analysis
will contain LPAR capping.
Thanks to Chuck Hopf, MBNA, USA.
Change 23.204 Documentation only. Change 23.021 correctly populated
ASUM70PR the "PHYSICAL" LPAR's data in LP0xxxxx variables, so the
Aug 9, 2005 total MSU, summed across all LPARs, from PDB.ASUMCEC,
will be slightly larger than the MSUs from versions prior
to MXG 23.01.
Oct 31, 2005: See Change 23.276.
Thanks to Huch Lapham, Royal Canadian Mounted Police, CANADA.
Change 23.203 Change 23.143 did not correctly handle the length 8 data
VMACMPLX fields, and MXG's INPUT did not match the MPLX DSECT.
Aug 9, 2005
Thanks to David Bixler, FISERV, USA.
Change 23.202 -Variables KW21GL01-KW21GL05 are no longer created nor
VMAC80A nor kept in dataset TYPE8021, as the RDEFINE command does
Aug 8, 2005 not contain the GLAUFLGS field.
Aug 30, 2005 -Variables CLASNAM1-CLASNAM4 are now created in TYPE8024
to support up to 5 class names.
-Support for SMF80DTP (43) for SETROPTS GENLIST/NOGENLIST
and enhancement for (42) for SETROPTS RACLIST/NORACLIST;
up to five class names (CLASNAME,CLASNAM2-CLASNAM5) are
now kept from either 42 or 43 RACFTYPE entry.
This assumes that the SETROPTS record contains either
a (42) or a (43) segment, but not both. My test data
had no event 24 records so I could not validate that
assumption. If wrong, then new variable names will be
needed and this text will be revised.
-Aug 30: tests for NR44SEGS should be NR42SEGS in the
WHEN (42) logic; caused job to fail.
Thanks to Adam Thorn, Euroclear, BELGIUM.
Thanks to Aimee Steel, Euroclear, BELGIUM.
Thanks to Bill Arrowsmith, Euroclear, BELGIUM.
Change 23.201 Condition Code (Return Code) 4 in ASUMTALO eliminated.
ASUMTALO The LENGTH statement in ASUMTALO specified DEVICE $8, but
Aug 8, 2005 the actual length of DEVICE is only $7; both the LENGTH
entry and the (redundant) "Compiler Faker" statement were
revised to make DEVICE only seven characters long.
The message appears when SPIN.SPINTALO exists, i.e., only
on the second or later execution of ASUMTALO, but it had
no impact, other than setting the condition code.
-After years of seeing those spurious LENGTH OF CHARACTER
VARIABLE HAS ALREADY BEEN SET messages, when there was no
change in the length (before SAS fixed the message so it
now only prints when the lengths are different), this is
the first time that message actually uncovered an error!
Note: The message text suggests that putting the LENGTH
statement ahead of the SET statement will eliminate the
message; however, that is not acceptable because if the
LENGTH statement precedes the SET statement, then this
DATA step could inadvertently truncate the kept length
of a variable, but there would be no warning message.
Instead, MXG puts the LENGTH statement after the SET
statement so that any mismatch will be detected.
Thanks to Mike Allen, Pacific Corp., USA.
Change 23.200 Support for MegaCrytion's user SMF record creates:
EXMGCRCR dddddd dataset description
IMACMGCR MGCRCR MEGACRYP MEGACRYPTION START/END
TYPEMGCR The start and stop datetimestamps MGCRSTRT/MGCREND are
TYPSMGCR on the GMT clock, and there is no GMT Offset in the
VMACMGCR record that could safely be used to infer the zone,
VMXGINIT until the vendor adds the GMTOFFSET field to the record.
Aug 4, 2005
Thanks to John Rivera, i-structure, USA.
Change 23.199 Support for TPF Continuous Data Collection, TPFCDC, which
EXTPFC80 is a new data source for TPF and creates many datasets:
EXTPFC81 dddddd dataset description typetype
EXTPFC82 TPFC80 TPFC80 SYSTEM MESSAGES 80X
EXTPFC83 TPFC81 TPFC81 SYSTEM LISTS 81X
EXTPFC84 TPFC82 TPFC82 SYSTEM BLOCKS 82X
EXTPFC85 TPFC83 TPFC83 DASD/POOLS 83X
EXTPFC86 TPFC84 TPFC84 DASD DEVICES 84X
EXTPFC87 TPFC85 TPFC85 SYSTEM VFA 85X
EXTPFC88 TPFC86 TPFC86 SUBSYSTEM VFA 86X
EXTPFC89 TPFC87 TPFC87 MPIF 87X
EXTPFC8A TPFC88 TPFC88 TAPE 88X
EXTPFC8B TPFC89 TPFC89 TCP/IP 89X
EXTPFC8C TPFC8A TPFC8A I-STREAM 8AX
EXTPFC8D TPFC8B TPFC8B SUBYSTEM MESSAGES 8BX
EXTPFC8E TPFC8C TPFC8C SUBSYSTEM USER 8CX
EXTPFC8F TPFC8D TPFC8D LODIC 8DX
EXTPFC90 TPFC8E TPFC8E MQ SUMMARY 8EX
EXTPFC91 TPFC8F TPFC8F MQ QUEUE DETAIL 8FX
EXTPFC93 TPFC90 TPFC90 MQ CHANNEL DETAIL 90X
EXTPFC94 TPFC91 TPFC91 USER DATA 91X
IMACTPFC TPFC93 TPFC93 CDC RECORD 93X
TYPETPFC TPFC94 TPFC94 STATIC SYSTEM INFO 94X
TYPSTPFC TPFCDC "records" have a '93'x segment with total length
UTILTPFC the number of segments that follow in that record, and
VMACTPFC then those segments, which can have repeated entries,
VMXGINIT and each of which contains its own-length field, follow.
Aug 3, 2005 -MXG creates an observation in each of the above datasets
Aug 19, 2005 for each instance of each segment.
-But the TPF creation splits these logical records into
multiple physical "tape" records that are most definitely
NOT standard variable length records, and that cannot be
directly read. The first 4095 bytes of data start the
first physical record, but TPF adds a 16-byte trailer
segment, creating a 4111-data-byte (4115 LRECL) variable
length first-record. The remaining bytes of the logical
record start in the first byte of the second "tape"
record, which is padded with nulls thru data byte 4095,
and to which the TPF 16-byte trailer is added at the end.
-Because of this non-standard record format, you will have
to pass the TPFCDC data file twice: first, with the MXG's
UTILTPFC program, which will read those split records and
create a legitimate VBS record for each split record, and
then second, that output file is processed by TYPETPFC to
create the preceding 20 TPFCDC datasets.
Note: UTILTPFC is heuristic based on the sample data,
and it reads a pair of records for each event.
It will need revision if your TPF data length
causes more than two split records to be needed.
-Product Problems Reported to IBM:
1. Their complicated split process is not working; one
byte of data is lost from the segment that is split!
In my test data that was always the '87'x segment,
so MXG resets that segment's length, but that only
works if the '87' is the segment across the split.
MXG will be revised when IBM corrects their error.
Oct 28 Update: IBM APAR PJ30503 corrects the one
byte loss error.
2. Two fields in the '90'x segment have blanks instead
of binary numeric values. Aug 19 update: IBM says
the two fields (TPFCBTSZ, TPFCSZLB) do not apply when
the MQ Channel Type is SERVER (TPFCCTYP='V'); MXG now
sets those two variables missing when TPFCCTYP='V'.
-Product exposure:
Several character fields have field lengths that can be
changed by the TPF installation; MXG code expects these
lengths for those fields; other lengths cause errors:
Length Field Name Length MXG Variable
CDC_SS_NAME_LEN 4 TPFCSSNA,TPFCSS
CDC_SSU_NAME_LEN 4 TPFCSSUN,TPFCSSU
MQ_Q_MGR_NAME_LENGTH 48 TPFCQMGR
MQ_Q_NAME_LENGTH 48 TPFCQNAM
MQ_Q_CHANNEL_NAME_LENGTH 20 TPFCCHAN
Thanks to Luis R. Vega-Zayas, IBM TPF, USA.
Change 23.198 Support for existing NT objects with fewer data fields
VMACNTSM (DATABASE with NRDATA=133, MSEXCHANGEIS MAILBOX with 49,
Aug 4, 2005 DATABASE==>INSTANCES with NRDATA=92, and MSEXCHANGE IS
with NRDATA=110) than MXG code expected. Those objects
records were deleted prior to this change.
Thanks to Paul Billick, Harleysville Insurance, USA.
Change 23.197 The hardcoded "SPIN" DD in PROC COPY IN=SPIN OUT=&PDBMXG
BUILD005 in BUILD005/BUIL3005 was changed to &SPINOUT so the new
BUIL3005 SPIN datasets will be backed up from the correct DD.
Aug 4, 2005 If the &SPINOUT was different than "SPIN", you could get
a VARIABLE NOT FOUND error when SPUNJOBS executed.
Thanks to Ken Williams, CPT Global, ENGLAND.
Thanks to Mark Williams, Marks and Spencer, ENGLAND.
Change 23.196 -Support for CA SAR/VIEW R11,they INCOMPATIBLY CHANGED the
FORMATS SMF records, increasing these variables to $EBDCID32:
VMACSARR SV20DIST,SV21DIST,SV30RID,SV30VID,SV31RID,SV31VID,
Aug 3, 2005 SV31DIST,SV31BNDL,SV32RID,SV33RID,SV34RID
and by increasing SV33LTM to PIB4. The test for SARR
Version got messy; SMFVPRL is now '11.0' but it used to
be '2.0 ', so instead of IF SMFVPRL GE '11.0' THEN....,
each test was more complicated:
IF INPUT(SCAN(SMFVPRL,1,'.'),5.) GE 11 THEN ....
-Format MGSARTY new value '10:DOC VIEW WEB' for Interface
Type was added.
Thanks to Mark Schrager, Metropolitan Life, USA.
Change 23.195 Line fifteen had an end comment but no start comment,
GRAFTALO which caused the %MACRO statement to never be read.
Aug 3, 2005
Thanks to Ep van der Es, Dow Chemicals, THE NETHERLANDS.
Change 23.194 -Missing value messages for DB2RDWTM when testing IMACEXCL
UTILEXCL built by UTILEXCL found DB2RDYTM had been misspelled as
Aug 2, 2005 DB2RDWTM, which does not exist. Value of DB2RDYTM was
incorrect by a factor of 16 due to that typo.
-Calculation of SEGLEFT for optional segments was only
correct for the first segment; fortunately, it appears
to have had no impact; using SEGSTRT instead of LOC in
each calculation corrects the exposure.
Thanks to Normand Poitras, IBM Global Services, CANADA.
Change 23.193 Support for TNG AIX new object CA PROCESS GROUP (PID)
EXTAI025 creates new MXG AI025 dataset. New variables are added
FORMATS to datasets AI018 (CA KERNEL GROUP), AI020 (CA NETWORK
VMACTNG GROUP), and AI016, (CA INTERFACE GROUP).
VMXGINIT
Aug 2, 2005
Thanks to Dale Gilbert, AhYum, USA.
Change 23.192 Variable NDMUID in dataset NDMRJ (Run Job) was truncated
VMACNDM to 8 bytes, instead of being input as $EBCDIC64., because
Jul 30, 2005 the test for that input did not contain 'RJ'.
Aug 10, 2005 -Aug 10: additional variables are now read in from 'RJ'.
Thanks to Tom Neurauter, Fidelity Systems, USA.
Change 23.191 Cosmetic. Invocation of VMXGSUM had "ANALCACH" instead
ASUMCACH of "ASUMCACH" for the printed message text.
Jul 30, 2005
Thanks to Chuck Hopf, MBNA, USA.
Change 23.190 Comments only. IMACICDA is not used if IMACEXCL controls
IMACICDA the input for a CICS APPLID/REGION. When IMACEXCL is
Jul 27, 2005 used, it controls the INPUTing of the optional CICS data
segments. Only when there is no IMACEXCL, or IMACEXCL
does not protect an APPLID, does IMACICDA control the
order of the optional CICS data segments MXG expects.
Thanks to Normad Poitras, IBM Global Services, CANADA.
Change 23.189 The example should have had //DAY DD instead of //PDB DD,
PDBCPYDY to copy from the "TODAY" PDB library just created by the
ACHAP35 BUILDPDB program, into the day-of-week PDB library. I use
Jul 21, 2005 //PDB in the "build", but //DAY thereafter to refer to
the "today" PDB library.
Thanks to Jeff Harder, Farm Bureau Insurance, USA.
Change 23.188 Variable R744QFLG should have been defined LENGTH $1, but
VMAC74 ended up as CHAR 34 because it's formatted $MG074QF which
Jul 20, 2005 set the kept length as the longest text in that format.
This variable was not caught by Change 23.170 because it
does NOT appear in an INPUT statement, which was expected
in our original QA analysis program, but that report has
been revised to catch any other similar syntax issues.
Thanks to Travis Hicks, IBM GS (Telstra Account), AUSTRALIA.
Change 23.187 Support for APAR OA10346 adds the LPAR's User Partition
VMAC7072 Identifier (UPID, the value you specified on your HMC
Jul 20, 2005 Customize Image Profile) to RMF 70 PR/SM section for each
LPAR, as variable SMF70UPI in TYPE70PR dataset.
As was reported in MXG Newsletter 46, APAR II13668 said
that after z990s, LPARNUM (SMF70LPN) was no longer a
static identifier, but instead is now a system generated
number of the alphabetical location of the LPAR name, and
the LPARNUM of an LPAR changes when you add/delete LPARs.
But now, IBM has accepted Edward Williams suggestion and
added the new SMF70UPI variable to TYPE70PR dataset.
MXG code
If you want to use SMF70UPI in your reporting, please
send me some SMF 70 records (see member SENDDATA) after
you have the APAR installed, so we can decide how to
add SMF70UPI to the ASUM70PR and ASUM70LP datasets, and
so I can validate those changes.
Thanks to Edward Williams, BMC, USA.
Change 23.186 Support for new CPUTYPE '2094'x for the z9 processors;
VMAC7072 this is an INCOMPATIBLE change: without this change, your
VMXGRMFI TYPE70PR dataset will contain extra observations for
Jul 20, 2005 nonexistent LCPUADDR, and incorrect data values.
Aug 29, 2005 -The exposure in VMXGRMFI for RMFINTRV is minimal; the
CPUTYPE test is used only for OS/390 or very early z/OS
that did not have SMF70WLA or SMF70LAC populated, and it
is used only to create CECSUSEC, CPCNRCPU, CPCFNAME and
CPCMSU variable's values from table lookups.
-In VMAC7072 there are several CPUTYPE tests with impact:
It is used to set SMF70ONT missing when it is zero for
some cases, which affects counting of CPU engines, and
which is used to identify spare engines so they are not
output in PDB.TYPE70PR; without this change, extra and
spurious observations are created in PDB.TYPE70PR.
It is also used to populate SMF70CPA for OS/390 and
early z/OS before SMF70CPA was added to the SMF record.
Thanks to Patricia Hansen, ADP, USA.
Change 23.185 Roscoe creation of PDB.ROSCOE didn't work when UTILBLDP
VMACROSC was used to create the sysin stream to add ROSCOE to PDB.
Jul 19, 2005 Most "DIF" members invoke the _Sdddddd macro for that
dataset with accumulated data, but ROSCOE is unique and
is now revised, so that DIFFROSC is included when _SROSC
is invoked, and all of the datasets that are processed in
DIFFROSC no longer have their _Sdddddd sort macro invoked
in the revised _SROSC macro. And, the ROSCOE datasets
that are merged into PDB.ROSCOE are no longer kept.
Thanks to Jeff Harder, Farm Bureau Insurance, USA.
Change 23.184 Optional new %LET MXGABND=nnnn; enhancement can be used
VMXGINIT to make MXG fail with a USER ABEND nnnn, instead of just
VMAC110 printing error messages on the SAS log. This option is
VMXGRMFI whether or not you want the job to USER ABEND nnnn.
Jul 19, 2005
Oct 19, 2005 -To enable the new MXGABND enhancement, you would insert:
%LET MXGABND= 333;
as your first SYSIN statement, and if any of the below
errors occur, your MXG job will USER ABEND 333.
-The default value for MXGABND is 0000, for NO ABEND. You
must use a value between 0001 and 4095 for nnnn.
Actually, you can use a larger value for nnnn, but the
ABEND code you see will be MOD(ABEND,4096) so using
nnnn=4096 resulted in USER ABEND U0000,
nnnn=8000 resulted in USER ABEND U3904, and
nnnn=9999 resulted in USER ABEND U1807.
The option is only available for these specific errors:
-SMF type 110 CICS record processing (Jul 19, 2005):
***ERROR.TYPE110.CICS/ESA 3.1.0. EXCLUDED FIELDS HAVE
BEEN DETECTED. YOU MUST RUN UTILEXCL.
RECORD WAS DELETED. CICSTRAN DATA WAS LOST.
***ERROR.VMAC110 STRTTIME HAS MISSING VALUES and
***ERROR.VMAC110.ESA.2 INVALID TASKNR OR STRTTIME IN...
Those errors means that your CICS records have
changed or that you have excluded data and you must
run the UTILEXCL program to create IMACEXCL and to
tailor the IMACICxx's that you may also need to
EDIT to properly read the data. But, as the
message was only printed in the middle of the SAS
log of the daily job, which can be kilothousands of
lines of text, they requested a new option that
would let them choose to cause the MXG job to ABEND
for these CICS errors that delete data, in addition
to the error message (which will now be the last
thing printed on the log!!).
-RMFINTRV creation (Oct 19,2005):
***ERROR.RMFINTRV.CPUTM IS MISSING.
The CPUTM variable from TYPE72GO dataset is missing
which can be caused by incorrect tailoring in your
EXTY72GO exit member.
This change will be updated if other error messages are
added to this enhancement. See Change 39.180 for CCode.
Thanks to Mike Perry, Morgan Stanley, USA.
Thanks to Min-che Li, Morgan Stanley, USA.
Change 23.183 Support for APAR OA11036, which adds MACHTIME to SMF 89
VMAC89 and variables SMF89HOF and SMF89DTO values.
Jul 18, 2005
Thanks to Al Sherkow, I/S Management Strategies, Ltd., USA.
Change 23.182 Test of LENCPUC GE 24 should have been GE 64 to input the
VMAC7072 SMF70HWM and SMF70HOF fields in support for APAR OA11375.
Jul 18, 2005
Thanks to Al Sherkow, I/S Management Strategies, Ltd., USA.
Change 23.181 -DB2ACCTP, Package Data, was still wrong for new DB2 V8.1
VMACDB2 IFCID=239 record with LENQPAC=0 and more than one package
Jul 17, 2005 segment. The INPUTed LENQPAC at the beginning of each of
Aug 12, 2008 those segments does not include its own length, so a new
LENxxxx=LENxxxx+2; statement had to be added to each of
of the adjustment DO groups invoked when LENxxxx=0. The
text of Change 23.140 was revised to show new statement.
-For DB2 V7.1 and later, variables QBACxxxx and QTXAxxxx
are always missing in DB2ACCTP package data; those
variables only have values in the DB2ACCT dataset.
MXG logic for the IFCID=0003 record prior to V7.1 had
incorrectly input the QBAC and QTXA fields before the
loop across each of the OFFQPAC segments. Re-locating
the QPAC segment to be processed before the other
segments now correctly causes those sets of variables to
be always missing in DB2ACCTP.
Note: the text in this paragraph was completely wrong
prior to Aug, 2008, but the QBACxxxx,QTXAxxxx
variables have ALWAYS been missing values i
the DB2ACCTP dataset, in spite of that text,
now revised.
-It was noted that in the DB2 V8.1 DB2ACCTP IFCID=239 data
that QWACBSC and QWACESC are both missing, making it less
easy to match the DB2ACCTP back to it's DB2ACCT obs.
-Missing value calculation for QGBAXN eliminated, but that
variable is now always missing; instead, use QBGAEX.
Thanks to Victoria Lepack, Aetna, USA.
Change 23.180 DATETIME logic had incorrect word numbers for the SCAN of
VMACPRPR YYYY and SS, now corrected.
Jul 8, 2005
Thanks to Christa Neven, KBC Bankverzekieringsholding, BELGIUM.
Change 23.179 Variables VSRNBYTR and VSRNBYTW in dataset HSMVSRFU were
VMACHSM way too small, as their value in the record was in KB but
Jul 8, 2005 their label indicated bytes. They are now multiplied by
Jul 11, 2005 1024 to convert their value to bytes, and are formatted
with MGBYTES format to "print pretty". These variables
FSRBTTR FSRBTTW FSRDBYTR FSRDBYTW FSRTBYBK FSRTBYTR
FSRTBYTW DSRBYTR DSRBYTW
that contain bytes in both their values and labels are
now also formatted with MGBYTES for consistency.
However, these storage-value variables:
DSRNGBR ='GIGABYTES*READ'
DSRNGBW ='GIGABYTES*WRITTEN'
VSRTOTKB='TOTAL*CAPACITY*OF VOLUME (IN KB)'
are NOT converted to bytes, and are NOT formatted MGBYTES
because they agree with their labels, and changing their
internal value to bytes could impact existing reports.
Life is filled with compromises when you don't make the
correct first choice!
Thanks to Robert Chavez, Office Depot, Inc, USA.
Thanks to Chuck Hopf, MBNA, USA.
Change 23.178 Variable PARTISHN was not labeled in dataset TYPE73, so
VMAC73 it was also unlabeled in dataset TYPE73OE.
Jul 8, 2005
Thanks to Chuck Hopf, MBNA, USA.
Change 23.177 ML-34 of ASMTAPEE and the HSC exit are production status!
ASMHSCEX Beta Tests with the new HSC exit uncovered some minor
VMACTMNT errors that are now corrected, but the exit works fine to
Jul 3, 2005 capture all HSC-controlled tape mounts, just like the IBM
Jul 11, 2005 Volume Mount Exit, previously implemented in ML-34, works
to capture all IBM-controlled tape mounts. Sampling is
no longer used to detect tape mounts, so none are missed.
As currently implemented, ASMHSCEX supports only a single
HSC or CSC, but now that we are aware that both products
and even multiple copies of HSC and/or CSC can exist, we
are investigating how to support those environments, and
will have a revised ASMHSCEX for those installations.
-Primary correction was in ASMHSCEX, which populated the
JOB file with the JCTJOBID value instead of JOB name.
-But because JCTJOBID=JOB, the MXG logic to create JESNR
from the JCTJOBID caused JESNR to be missing:
JOB=JCTJOBID is a valid condition for "early ASID" STCs
the don't have a "JESNR".
-And beta tests exposed MXG errors in VMACTMNT that caused
INITTIME and PROCSTEP to be missing/blank.
-With this Change, ML-34 is now ready for production use.
Thanks to Steve Martin, Fidelity Systems, USA.
====== Changes thru 23.176 were in MXG 23.06 dated Jun 29, 2005=========
Change 23.176 -Support for SMF 6 ESS GEPARMKY='04D'x with more than one
IMAC6ESS segment creates ESSMAIL3 and ESSMAIL4 variables. Caused
VMAC6 INPUT STATEMENT EXCEEDED error.
Jun 29, 2005 -Support for SMF 6 ESS GEPARMKY='04B'x creates ESSMFILE.
-Support for SMF 6 ESS GEPARMKY='04E'x creates ESSRPLY2.
Thanks to Engelbert Smets, Provinzial, GERMANY
Thanks to Cornelia Opel, Provinzial, GERMANY
Change 23.175 Support for SMF 22 Subtype 11 I/O Configuration Change
EXTY22UA creates new dataset:
IMAC22 dddddd Dataset Description
VMAC22 TY22UA TYPE22_A I/O Configuration Change
VMXGINIT
Jun 28, 2005
Thanks to Shane Dowling, DEWR, AUSTRALIA.
Change 23.174 Change 18.338 created the _Vdddddd macro definitions, but
VMACMVCI not all MXG code members have been revised to create that
Jun 27, 2005 token. This change creates _VMVCICS and _VMVCICF in the
VMACMVCI member.
Thanks to David Edge, Thomson BETA Systems, USA.
Change 23.173 Using TYPEHSM, datasets HSMWWFSR and HSMWWVSR were not
DIFFHSM sorted into the //PDB library, because TYPEHSM included
Jun 24, 2005 the DIFFHSM member, which had separate _Sdddddd sorts
for each dataset, but DIFFHSM had not been updated to add
sorts for those two datasets. Using TYPSHSM, those data
were sorted into the //PDB, because it invoked the _SHSM
product sort macro, which does list all HSM datasets.
The DIFFHSM member is revised to use the _SHSM member.
Normally, TYPExxxx members leave all of their datasets
in the //WORK file, while the TYPSxxxx members sort all
of the xxxx products datasets into the //PDB library.
But when there are accumulated data in the product, the
TYPExxxx member always will invoke the sort into //PDB
to de-accumulate that dataset, and HSM writes SMF data
with accumulated values, so both TYPEHSM and TYPSHSM
now produce identical results.
Thanks to Ian Arnett, TD Canada Trust, CANADA.
Thanks to Luc Audet, TD Canada Trust, CANADA
Change 23.172 -SAMS POOLS record was INCOMPATIBLY CHANGED in 002053V4 by
VMACSAMS increasing NRVOLS field from 4 to 6 bytes, causing all of
Jun 24, 2005 the variables to the right to have wrong values. With the
Jul 20, 2005 help of CA Technical Support to provide the DSECTS of the
Jul 30, 2005 SMF record, MXG code for POOLS was corrected and revised:
-The SAMS Version is used, rather than the circumvention
to test LRECL, to detect the longer NRVOLS field.
-Data in SAMSFBYX/TBYX/VBYX/LBYX were wrong because those
four fields are packed decimal, not binary values, and
MXG was using the incorrect informat for them.
-New in 002053V4 variables SAMSPALL & SAMSBALL are input.
-New in 002053V5 variables SAMSESA/ESB/ESC describe the
storage group in three lines of text.
-Support for 002053V6 was revised and valided Jul 30; the
V6 record's POOLS record was completely restructured.
-Variable SAMSJOBN was removed from the KEEP= and LABEL
statements, as there is no "JOB" name field in SAMS SMF.
Thanks to Abily Christelle, GICM, FRANCE.
Thanks to Patrick Notteghem, CA, FRANCE.
Change 23.171 -Variable LOCLINFO is INPUT $EBCDIC8, which works fine if
VMAC30 SMF30UID contains text or hex characters on z/OS, but if
Jun 24, 2005 executed on ASCII, that INPUT statement changes any hex
characters. The only solution for ASCII execution is to
create a second variable, LOCLINCH, INPUT as $CHAR8 and
FORMATed $HEX16. so any non-text characters in that field
are preserved, and available in the EXTY30Un exits.
-Missing value calculations when SMF30IST was missing were
eliminated; SMF30IST only exists in subtype 2, 3, and 6.
Thanks to Sudie Wulfert-Schickedanz, Anheuser-Busch, USA.
Change 23.170 Character Variables formatted with $MGdddxx formats that
VMAC102 were NOT in a LENGTH $1 statement were stored in LENGTH
VMAC110 of the maximum text in the $MGdddxx format values, which
VMAC74 wasted disk space. Now, all character variables with $MG
VMAC84 format names have been identified, and added to a LENGTH
VMAC85 statement if needed to reduce their stored length.
VMAC92 VMAC110: DS2TCBMD-DS9TCBMD DSaTCBMD SORSSLFL
VMACAIM6 VMAC74: R744QFLG
VMACBE91 VMAC84: JMFJSJSR
VMACBE97 VMAC85: R85ODT R85OVT R85TVT
VMACCIAO VMAC92: SMF92MFG SMF92UFG
VMACEDGR VMACAIM6: IOCTYPE
VMACFTP VMACBE91: BE91STP
VMACHIOM VMACBE97: B970OBT
VMACHURN VMACCIAO: CIAOETYP
VMACNSPY VMACEDGR: RDVRSTYP RRTYPE2 RSTYPE2
VMACOMDB VMACFTP: DVGSCOMP DVGSRPNT DVGSRTYP
VMACOMSM VMACHIOM: HIOOSTYP
VMACQACS VMACHURN: HU62UMOD HU62UTYP
VMACSAR VMACNSPY: NSPYRTPS
VMACSARX VMACOMDB: QMDAPTYP QPACAAFG QWHSRMID
VMACSPMS VMACOMSM: OMDEVMDL
VMACSYSV VMACQACS: ETLPRCL JBSTYP SCPRCL SHPRCL STPRCL
VMACTIE VMACSAR: SARPMDX
Jun 20, 2005 VMACSARX: GCRPMDX
Jul 21, 2005 VMACSPMS: SPMSRLS
VMACSYSV: TRANTYPE
VMACTIE: TIELOG
Thanks to Freddie Arie, Merrill Consultants, USA.
Change 23.169 Support for additional SMF 99 Subtype 2 data segments.
EXTY99Q2 -These variables added to TYPE99_2 dataset:
EXTY99R2 PCADP ='CURR*ACHIEAVABLE*DEMAND*PCT'
EXTY99S2 PESCS ='ASIDS*EXPLICIT*STORAGE*CRITICAL'
EXTY99V2 PGRIN ='GROUP*NAME'
FORMATS PIFAD ='IFA*DELAY*SAMPLES'
IMAC99 PIFAU ='IFA*USING*SAMPLES'
VMAC99 PIFLAG ='FLAGS'
VMXGINIT PSAMHST ='SAMPLE*HISTORY*ROWS*USED'
Jun 22, 2005 PSBCPUD ='SAMPLE*BASED*CPU*DELAYS'
PSBCPUU ='SAMPLE*BASED*CPU*USINGS'
PSBIOD ='SAMPLE*BASED*I/O*DELAYS'
PSBNIOD ='SYSPLEX*WIDE*NON I/O*DELAYS'
PSPMDP ='MINPCT*PROCTIME*DEMANDED'
PSWCPUU ='SYSPLEX*WIDE*CPU USING*SAMPS'
PSWCT ='SHORT*WAIT COUNT*ACCUMULATE'
PSWIDLE ='SYSPLEX*WIDE*WIDE IDLE*SAMPS'
PSWNONI ='SYSPLEX*WIDE*NON-IDLE*SAMPS*
PSWOTHR ='SYSPLEX*WIDE*OTHER*SAMPS'
SMF99SCI='SERVICE*CLASS*INDEX'
-New datasets are created from subtype 2 segments:
dddddd Dataset Description
TY99R2 TYPE99R2 99-2-Q REMOTE QUEUE DATA
TY99Q2 TYPE99Q2 99-2-Q QUEUE SERVER DATA
TY99S2 TYPE99S2 99-2-S SERVER SAMPLE DATA
TY99V2 TYPE99V2 99-2-V SERVER DATA
Thanks to Chuck Hopf, MBNA, USA.
Change 23.168 Cosmetic. Blanks in SMF6TARG (IP Address) are removed.
VMAC6
Jun 21, 2005
Thanks to Thomas Peiper, Tietoenator, SWEDEN.
Change 23.167 The Installation Data field, INSTDATA, was inconsistently
VMACRACF input as $200 with +55, or $40 with +215, and variables
Jun 21, 2005 OMVSHOME, OMVSPROG, USRDATA, and APPLDATA did not input
their full $255 byte field. The $200 was the SAS V6
limit for character variables, but I've been reluctant to
change those inputs to $255, because that would cause an
avoidable ABEND with V6, and besides, is there really
anything in those last 55 bytes that is needed? However,
since this RACF Unload utility code didn't exist when SAS
V6 was The Thing for MXG years ago, I've chosen to
increase all these variables to input and be stored as
$255, and hope no V6 sites try to use this support! Some
MXG members are already documented as requiring SAS V8
(like records with UCS data, for example), but the few
sites that I know are still on V6 are not their by their
own choice, so I'll try to protect the really important
SMF records, until a real need arises.
Thanks to Len Rugen, State of Missouri, USA.
Change 23.166 -Fields were added to CMRFILE, probably Version 5.6, but
VMACMVCI there is no length-of-file-segment field in the CMRDETL
Jun 21, 2005 record, so the new fields were overlooked, causing trash
values in the second and subsequent file segments in each
CMRDETL record with more than one file segment.
New variables are created and kept in CMRFILE dataset:
T6EF1='RNU*COUNT' T6EF2='RPU*COUNT'
T6EF3='RWD*COUNT' T6EF4='REDSET*COUNT'
T6EF5='RDUSET*COUNT' T6EF6='RNXSET*COUNT'
T6EF7='RPVSET*COUNT' T6EF8='RNUSET*COUNT'
T6EF9='RPUSET*COUNT' T6ET1='RNU*TIME'
T6ET2='RPU*TIME' T6ET3='RWD*TIME'
T6ET4='REDSET*TIME' T6ET5='RDUSET*TIME'
T6ET6='RNXSET*TIME' T6ET7='RPVSET*TIME'
T6ET8='RNUSET*TIME' T6ET9='RPUSET*TIME'
T6ETA='READ*TIME' T6ETB='RDU*TIME'
T6ETD='WRT*TIME' T6ETE='RWT*TIME'
T6ETG='DEL*TIME' T6ETH='UNK*TIME'
T6ETJ='SBR*TIME' T6ETK='RNX*TIME'
T6ETL='RPV*TIME' T6ETM='EBR*TIME'
T6ETO='RBR*TIME' T6ETP='OTH*TIME'
T6ETQ='FCTOT*COUNT' T6ETR='FCTOT*TIME'
T6ETS='FCWAIT*COUNT' T6ESR='SRECS*COUNT'
-T6EV1,T6EV2,T6EV3 are protected for hex zeros for Volume
Serial Numbers; T6EV3 contains hex values in byte 4 that
are changed to blanks by MXG.
-Variable TFILI was kept as $27, because it was assigned
the $MGMVICT format without also being set to the $1
length in a LENGTH statement. Variables that are assigned
an MXG-built character format will have the length of the
longest value statement, if their length is not fixed in
a LENGTH statement; this was overlooked, but we'll add a
new report to detect any other cases of wasted space.
-Variable SYSTEM was always blank; it was only populated
in Version 5.3 records, but now it is populated from the
T6ESMFID SMF TYPE field.
-These variables are now set to blank if they contained
hex zeros:
T6EBMSN T6ECMP53 T6EOPID T6EPSBN T6ERPTCL T6ETMID
T6EAUTH T6ECORR
-However, when T6EBMSN starts with "CSMI" in EBDCIC4., the
last four bytes are non-printable ('1C796A00'x) which may
be trash left over, or may be actual "data" for the BMS
Map Name. I've chosen to detect these and store only the
"CSMI " back in T6EBMSN, and have stored the last four
hex bytes in new variable T6ECSMI until we have an answer
from the vendor as to why that field has mixed EBCDIC and
HEX when it starts with the mirror transaction name CSMI.
Thanks to David Edge, Thomson BETA Systems, USA.
Change 23.165 New MGFMTVR identifies which MXG Version's FORMATS member
FORMATS was used to create the format library pointed to by the
Jun 21, 2005 //LIBRARY (or LIBRARY LIBREF). Using this program
DATA _NULL_; FMTVERS=.; PUT FMTVERS MGFMTVR. ;
will print, on the SAS Log:
MEMBER FORMATS FROM MXG 23.05 CREATED YOUR MXG FORMATS.
Thanks to Ron Alterman, Pacific Gas and Electric, USA.
Change 23.164 Additions in WAS Version 6.01, support for PQ96114 and
FORMATS MXG errors are corrected:
VMAC120 -MQ Series variable SM120CSO has new values of 5 and 6:
Jun 21, 2005 now decoded by the MG120CO format:
5:HTTP SESSION and
6:HTTP ENCRYPTED SESSION
-MQ Series variable SM120JB3 has overlooked values 4,5 and
a new value of 6 now decoded by MG1203B format:
4='4:BMP ENTITY BEAN'
5='5:CMP ENTITY BEAN'
6='6:MESSAGE DRIVEN BEAN'
-Variables SM120JHF and SM120JHT are now correctly input
as &PIB.8 instead of &PIB.4. JHF was always zero, and
JHT contained the value of JHF when they were wrong.
Thanks to Martyn Jones, Euroclear, BELGIUM.
Thanks to Phil Downes, Euroclear, BELGIUM.
Change 23.163 INVALID ARGUMENT FOR INPUT FUNCTION because SyncSort has
VMACSYNC a new and unexpected value of 'SMS' for ths UCB Address.
Jun 18, 2005 'SMS' is now tested to circumvent the error message.
Thanks to Jim Dammeyer, State Farm Insurance, USA.
Change 23.162 ML-34 of MXG Tape Mount Monitor provides ASMHSCEX member
ASMHSCEX that you assemble to create an HSC SLSUX01 user exit that
ASMTAPEE your HSC guru then installs in HSC, so that all of the
Jun 15, 2005 HSC-controlled mounts (STK VTS or STK Silos) will be
Jun 22, 2005 captured by exit (event-driven), instead of by sampling.
(Sampling, even at .5 seconds missed a lot of the very
fast VTS mounts; using an exit captures 100% of them.)
The STKX option tells MXGTMNT to use the HSC exit, like
the MXIT option in ML-31 used the IBM Volume Mount Exit;
the difference is that you have to install the HSC exit,
while IBM's exit was already there! With MXIT and STKX
enabled, all mounts to real drives, all IBM VTS mounts,
and (finally!) all HSC-controlled mounts are captured!
The SLSUX01 exit, created by assembly of the ASMHSCEX,
itself can be used in one of two ways, depending on your
site's current use of the STK HSC exit, and you control
which way via the SYSPARM input during assembly. If your
site does not currently use the STK HSC exit, SYSPARM(N),
which is the default, results in just the MXG replacement
exit code being assembled. But if your site does use the
HSC exit, specifying SYSPARM(Y) at assembly of ASMHSCEX
will cause MXG code to include your existing exit code
during the link edit step that creates the exit module.
Then, when MXG's exit is subsequently defined to HSC, our
exit will invoke your exit as if we weren't there, then
we'll do our thing to collect the necessary data and pass
that to the TMNT address space. This is well documented
in the ASMHSCEX comments, but please let us know if the
instructions need clarification or improvement.
You can assemble ASMTAPEE member to create the MXGTMNT
program load module before you assemble ASMHSCEX to
create the MXG SLSUX01 HSC exit, or vice versa; there is
no forced order for installation, and enablement of
MXGTMNT can occur in any order.
The implementation of the MXG HSC Exit is quite robust:
- it is essentially a NOP if it detects MXGTMNT is not
enabled or is not running, or, conversely,
- if MXGTMNT is enabled, but the exit is not there, the
environment exists to support the exit, but nothing
will happen until the exit is running.
We believe HSC 5.1 and HSC 6.0 versions are supported,
based on STK documentation; it might also work with 5.0,
but we don't have enought information from STK to confirm
if that is true, and, besides, 5.0 is archaic!
You can only specify STKX=YES at assembly or start-up of
the monitor; you cannot start the monitor and then use
a command to turn on STKX later; that might be added in
the future, but it would have delayed delivery of this
release.
We have Alpha tested this code as thoroughly as we can,
and we have NEVER caused a system outage with any ML of
the monitor, but since we don't have a Silo or VTS on our
test system, we ask that you ONLY test ML-34 on an HSC
test system that can afford to be "crashed", before you
use it on an real system. When we have more feedback
from Beta test sites, this text will be revised to
confirm successful tests at real sites.
a. Jun 22 update:
-First test of the HSC Exit did not succeed but it did no
harm: on the first mount after initializing the monitor
and exit, the user exit ABENDed with S978, and then it
disabled itself; tape mount processing then proceeded as
usual without the exit. asmguy@mxg.com examined the dump
and the listing of the assembly of the HSC exit and
corrected a "dumb mistake, bad branch" error in ASMHSCEX,
now dated Jun 22, 2005.
-An IBM-only site raised three question,:
1. Why do I get STKX=NO in the monitor output while I
have 'OPTIONS2 DC AL1(DOARCV+DOMXIT+DOSTKX) in the
assembler code:
asmguy answer ==>
Because I forgot to add code to change the STKX=NO to
STKX=YES if the code is modified to turn this on
instead of using input parms. This is a tough one for
me to remember since it's counter to the way I think
and I always use parms when I test so I don't catch
these things. Anyway, I'll correct it.
2. What does 'MXGC003I MXG STK MOUNT EXIT MONITORING
ENABLED' mean?
asmguy answer ==>
This is a message that indicates the environment
necessary to support the STK exit has been enabled in
MXGTMNT as a result of STKX=YES.
3. Do I need XMem at all?
Barry's answer ==>
XMEM is still needed to get the job-related fields in
the TYPETALO allocation records, at least for now, as
they are independent of the mount records. But I plan
to examine if I need to revise ASUMTAPE to use the new
exit-driven mount records to populate TYPETALO info,
once we've got the monitor working and I've got some
SMF data from a site with both IBM and HSC mounts.
b. Jun 24 update:
-For HSC, you may need to create exit SCSUX01 instead or
in addition to the SLSUX01 exit, depending on the HSC
interface your site uses. SCSUX01 is required if CSC is
used for remote access to the robot and VSMs, which may
be all that's available on your test system. SLSUX01 is
used for local access. Changing all SLSUX01 to SCSUX01
in ASMHSCEX and reassembling worked just fine, but we can
create a new SYSPARM option for ASMHSCEX that will create
both HSC and CSC exits in the same member.
c. Jun 28 update:
No errors have been reported by two sites successfully
using ML-34 and the new HSC exit. I'm awaiting test data
to update the ASUMTAPE program, but that won't happen
until late July, after some vacation time.
Thanks to "asmguy@mxg.com".
Thanks to Paul Naddeo, FiServ, USA.
Thanks to Jeff Holst, FiServ, USA.
Thanks to Normand Poitras, IBM Global Services, CANADA.
Change 23.161 Comments said PDB.TYPE73OE dataset would be created, but
ANALFIOE the code created WORK.TYPE73OE; this change creates the
Jun 15, 2005 old style MACRO _LANFIOE PDB.TYPE73OE % so the default
dataset will be PDB.TYPE73OE, but also so that you could
change the DD or Dataset name using MACKEEP/IMACKEEP.
Thanks to Chuck Hopf, MBNA, USA.
Change 23.160 New variables added to T102S106 dataset:
VMAC102 QWO4ADM2='OFF*SYSTEM*ADMIN ID2'
Jun 14, 2005 QWO4DFID='OFF*SYSTEM*DEFAULT*USER ID.'
QWO4OPR1='OFF*MVS*OPERATOR ID'
QWO4OPR2='OFF*MVS*OPERATOR ID2'
QWO4OZUS='OFF*ONLINE*ZPARM*USERID*MONITOR'
QWO4REGA='OFF*DDL REG*ART NAME'
QWO4REGC='OFF*DDL REG*TABLE OWNER'
QWO4REGO='OFF*DDL REG*ORT NAME'
QWO4SADM='OFF*INSTALL*SYSADMIN*USERID'
QWP4CONT='CONTRACT*CT*LONG*STORAGE*POOL?'
QWP4CRVW='DBA CAN*CREATE*VIEW-ALIAS*FOR OTHERS?'
QWP4DCFS='SMS*DATACLASS*FILE(DATA)*TABLESPACE'
QWP4DCIX='SMS*DATACLASS*INDEX*TABLESPACE'
QWP4DSMX='MAXIMUM*NUMBER OF*DATASETS'
QWP4EDBC='EDM*POOL*DBD*CACHE SIZE'
QWP4ESTC='EDM*POOL*STATEMENT*CACHE SIZE'
QWP4HINT='OPTIMIZATION*HINTS*ALLOWED?'
QWP4INTE='RTS*STATISTICS*TIMER*INTERVAL'
QWP4LEM ='MAXIMUM*NUMBER OF*LE TOKENS'
QWP4LRTH='UNCOMITD*READ*WARNING*THRESHOLD*(MINS)'
QWP4MDEG='MAX DEGREE*OF PARALLELISM'
QWP4MDSC='MIN SCALE*FOR DECIMAL*DIVISION*RESULT'
QWP4MNTY='MAINTAINED*TABLE*TYPE*BITMAP'
QWP4MXNC='MAX*CURSORS*OPEN PER*THREAD'
QWP4MXSP='MAX*ACTIVE*STORED PROCS*PER THREAD'
QWP4NPAG='NPAGES*THRESHOLD*FOR OPTIMIZER'
QWP4OJEH='OUTER*JOIN*PERFORMANCE*ENHANCEMENT?'
QWP4OZCI='ONLINE*ZPARM*CORRID*MONITOR'
QWP4OZTM='ONLINE*ZPARM*TIME*CHANGED'
QWP4OZTP='ONLINE*ZPARM*TYPE'
QWP4OZUS='ONLINE*ZPARM*USERID*MONITOR'
QWP4PDIX='PAD INDEXES BY DEFAULT?'
QWP4PKYU='ALLOW*UPDATE*PARTITIONING*KEY?'
QWP4RAC ='ROUTINE*AUTHORIZATION*CACHE SIZE'
QWP4RFSH='REFRESH*AGE'
QWP4SJRT='STAR*JOIN*RATIO'
QWP4SJTB='STAR*JOIN*THRESHOLD*(#TBLS/QB)'
QWP4SJXP='MAX SIZE*MEMORY POOL*FOR STARJOIN'
QWP4VDTY='DEVICE*TYPE FOR*TEMPORARY*DATA SETS'
QWP4WAIT='RETAINED*LOCK*TIMEOUT*MULTIPLIER'
QWP4EDMX='EDM POOL MAX DATA SPACE SIZE'
QWP4EDDS='EDM POOL DATA SPACE SIZE'
Thanks to Ron Alterman, Pacific Gas and Electric, USA.
Change 23.159 Yet another INPUT STATEMENT EXCEEDED RECORD for PSF SMF 6
VMAC6 record with SMF6LN6=24 (See Changes 23.091, 22.309).
Jun 13, 2005 The logic for SUBS=7 and SMF6LN6=24 was revised based on
the current SMF manual so that when SMF6LN6=24, there is
no longer an attempt to input SMF6PRTQ name, since there
cannot be roome for a name field when SMF6LN6=24.
Thanks to Diane Eppestine, Southwestern Bell, USA.
Change 23.158 MXG RMF-like reports printed whole numbers for AVG RESP
ANALRMFR TIME and AVG IOSQ TIME but IBM reports now print one
Jun 13, 2005 decimal place, so MXG format was changed to match.
Thanks to Bob Anders, McMaster-Carr Supply Co., USA.
Change 23.157 SMF file might not have been found, depending on use of
BLDSMPDB SMFIN= argument, and whether FILENAME SMF existed. The
Jun 10, 2005 &SMF was changed to FILENAME SMF "&SMFIN"; to correct.
Thanks to Joe Key, BOC Gasses, ENGLAND
Thanks to Alex DaSilva, BOC Gasses, ENGLAND
Change 23.156 ASUMUOWT had incorrect syntax for _LMONTSK definition.
ASUMUOWT Two periods are required.
Jun 9, 2005
Thanks to Chris Weston, SAS Institute Cary, USA.
Change 23.155 -First 23.05 only; incorrect syntax for default options in
ASMTAPEE "OPTIONS DC" statement, with a comma instead of plus.
Jun 9, 2005 -One site with ASM option CASE as their default had to use
ASM option COMPAT(NOCASE) because ASMTAPEE contains both
upper and lower case text, for readability.
Thanks to Dan Squillace, SAS Institute Cary, USA.
Thanks to Shirley Fhng, Hong Kong Shanghai Bank, Hong Kong.
====== Changes thru 23.154 were in MXG 23.05 dated Jun 7, 2005=========
Change 23.154 First 23.05 only. Line 3138 extended into column 3138.
ASMTAPEE Comments clarified.
Jun 7, 2005
Thanks to Dan Squillace, SAS Institute Cary, USA.
Change 23.153 -Utility to read SMF to count IDs and Subtypes did not
VMXGGETM count ID=102 correctly, when run on ASCII platform; those
Jun 7, 2005 PIB4. and PIB2. should have been &PIB.4. and &PIB.2. so
that the code was transparently portable across all SAS
platforms. With PIB4. on ASCII, extremely large values
were created, which caused the ID=102 sub-logic to never
be executed, so all ID=102 had SUBTYPE=0 on ASCII.
-The realization that I had not checked ALL MXG members to
be transparently portable cause me to search and find
these members with either PIB instead of &PIB., or with
$ instead of $CHAR or $EBCDIC; all are now corrected:
ANALCM27 ANALCM29 ANALIPAC ANALSNAP CHANGES EXIMRACF
IDMSJRNL IDMSLO57 IDMSLOG JCLCIMS JCLPDBXX MAKECODE
TYPECIMS TYPEIMSB TYPEMONX TYPESLRI UDB2GTF UDEBLOCK
USMFRATE USTKVOL UTILDBLK UTILGEVB UTILGEVM UTILSPAC
VAXPDS VMACCMFV VMACCOMP VMACMONI VMXGGETM XADALOG
XGTFANAL XIBMFDP XLOGREC XMACACHE XMACVMXP XPAII
XTYPEMVT XTYPEVS1
Fortunately, all are pretty obscure, non-mainstream code,
or someone would have certainly noticed the incorrect
data values if they were exected on ASCII platforms.
Thanks to Alfred Holtz, Medco Health Solutions, USA.
Change 23.152 First MXG 23.05 Only. Debug PUTs at lines 2147 and 2148:
VMACTPMX PUT _N_= COL= FLENGTH= VARNAME= TPMFIELD=
Jun 7, 2005 TOKENID= TOKFIELD= TOKFIELD= $HEX16.;
printed unneeded lines of text on the SAS log.
Thanks to Lawrence Jermyn, Fidelity Systems, USA.
Change 23.151 MXG 23.03-First 23.05. Debug PUT statement at line 1425
VMACNDM PUT _N_= COL= NDMPNODE= NDMSNODE= ;
Jun 6, 2005 printed unneeded lines of text on the SAS log.
Thanks to Michael Creech, Fidelity Information Systems, USA.
Thanks to David Kaplan, DTCC, USA.
Change 23.150 First MXG 23.05 only. VARIABLE NOT FOUND ERROR due to
ASUMMIPS typo: BY RPPTCLAS ... should be BY RPRTCLAS ....
Jun 6, 2005
Thanks to Pat Curren, Supervalu Inc, USA.
Change 23.149 Cosmetic. Examples of defining start and end of SHIFTs
IMACSHFT was clarified to make it easier for neophytes to change
Jun 6, 2005 the values to define their installation's shifts.
====== Changes thru 23.148 were in MXG 23.05 dated Jun 5, 2005=========
Change 23.148 General cleanup and revision to QA job stream:
ANALVM -Uninitialized xxxIFE and xxxIFA in RMFINTRV corrected.
QASAS -Specific reference to VMPDB removed in ANALVM, test of
TESTANAL ANALVM removed from TESTANAL as it was tested in TESTVM.
TRNDNTIN -QASAS code revised to PROC DELETE all LIBREFs.
TRNDNTLD -LENGTH/FORMAT added to MAXTIME/MINTIME for PRINTER data
TRNDPRTR set built in TRNDPRTR.
VMXGRMFI -TRNDNTIN,TRNDNTLD revised to use only &Pdddddd, and
Jun 5, 2005 eliminated the confusing _L macro definitions.
Thanks to Freddie Arie, Merrill Consultants, USA.
Thanks to Bruce Widlund, Merrill Consultants, USA.
Change 23.147 The response time buckets for the PDB.CICS dataset that
ASUMCICS is built by ASUMCICX from PDB.ASUMUOW dataset (which is
ASUMCICT the recommended way to measure CICS response with MRO),
ASUMCICX (or for the PDB.CICS dataset that can be built by the
VMXGINIT not-recommended ASUMCICS/ASUMCICT members from CICS
Jun 3, 2005 transaction segments in datasets CICSTRAN/MONITASK)
are defined as macro variables but they could not be
overridden without tailoring the ASUM member. Now, the
macro variables are externally defined in VMXGINIT, and
can be overridden in your //SYSIN DD *, before your
%INCLUDED SOURCLIB(ASUMCICx); statement. The default
values remain unchanged:
%LET SUCIVAL1=1;
%LET SUCIVAL2=2;
%LET SUCIVAL3=3;
%LET SUCIVAL4=4;
%LET SUCIVAL5=5;
%LET SUCIVAL6=8;
%LET SUCIVAL7=10;
%LET SUCIINTV=HOUR;
Thanks to Frank Lund, EDB, NORWAY.
Change 23.146 Support for new subtype 70 "FTP Server Security Section"
FORMATS adds these variables to TYP11970 dataset.
VMAC119 FSPSCCPL='CONTROL*CORRECTION*PROTECTION*LEVEL'
Jun 1, 2005 FSPSCIPH='CIPHER*SPECIFICATION'
FSPSDCPL='DATA*CORRECTION*PROTECTION*LEVEL'
FSPSLGME='LOGIN*METHOD'
FSPSMECH='PROTECTION*MECHANISM'
FSPSPRBF='NEGOTIATED*PROTECTION*BUFFER*SIZE'
FSPSPROT='PROTOCOL*LEVEL'
and new formats were created to decode four of them.
Thanks to Randy Shumate, LexisNexis, USA.
Change 23.145 The sample RMF III report had typos; ASISUPR should have
ZRBRPT3 been spelled ASISUCPR, and ASISCDOP should be ASISCDQP.
Jun 1, 2005
Thanks to Mike Obrien, Bank of America, USA.
Change 23.144 The "expanded length" format values introduced for TNG in
FORMATS Change 23.113 were most definitely non-trivial to code.
May 31, 2005 Initially, PROC FORMAT on ASCII SAS V9.1.3 ran without an
error, but values were not-found if a spanned-line had a
blank in column 72; those lines were then shifted right
so column 72 was non-blank, and values were then found.
But on z/OS V8.2, the new code failed to execute, with an
error 22-322 which underlined the equal sign on a line
that had 72 characters. Meanwhile, the new code executed
without error on z/OS 9.1.3, AND all values were found,
even for the spanned-text lines!
Noting that the V8.2 execution errors were on lines that
were exactly 72 positions, the code was revised to delete
a blank on the left of the '=' where possible, or the
line was split at the equal sign, and now the PROC FORMAT
executed without the 22-322 error on V8.2 on z/OS.
But now, values were not-found for spanned-text lines on
z/OS V8.2, while they were found on z/OS V9.1.3! This
problem had been opened with SAS Technical Support, and
their tests suggested that OPTIONS S2 might be involved,
as they could replicate the error when OPTIONS S2=71 was
used. Our real breakthrough was to compare execution on
z/OS V8.2 using %INCLUDE, versus copying the code into
the //SYSIN DD * and submitting the code; the instream
test had no errors AND properly found all values, while
the %INCLUDE-built format had values not-found!
More tests proved that the PROC FORMAT execution on z/OS
requires S2=72, while PROC FORMAT under ASCII requires
S2=0, so the end result is that member FORMATS now tests
its execution platform and sets S2=72 for PROC FORMAT on
EBDCIC, but sets OPTION S2=0 when executed on ASCII.
For z/OS, MXG's CONFIGV8 member has always had S2-72,
but two of the test sites were using SAS default S2=0,
which was known only in hindsight! MXG's CONFIGV9 for
z/OS has S2=0 (as extensively discussed in CHANGES; see
"Major Enhancements in MXG 22.08" and Newsletter 45),
but the AUTOEXEC for ASCII execution does not specify
either S= nor S2= option, so the S2=0 option on ASCII
accounts for my early tests not failing in execution.
This problem is still open at SAS, to understand what
is the righteous way to code formats that have values
that won't fit on one line, but the revised FORMATS
member now appears to work on all platforms with the
internal setting of S2 above.
Change 23.143 IMPLEX subtype 4 record's IMPLEXRT dataset did not have
VMACMPLX all of the possible variables kept, and the deaccumulate
May 31, 2005 logic was incomplete, causing zero observations in the
PDB.IMPLEXRT dataset; groups of the new variables will be
missing, as they are only input for specific values of
the EXMFRTYP variable. Some of the MXG tests for other
DIF()'d variables that were missing the "LT 0" for their
final test are now corrected.
Thanks to David Bixler, FISERV, USA.
Change 23.142 Support for Oce's Prisma Print log file creates these
EXPR1000 forty-five new datasets:
EXPR1010
EXPR1011 DDDDDD MXG MXG
EXPR1012 DATASET DATASET DATASET
EXPR1020 SUFFIX NAME LABEL
EXPR1030
EXPR1031 PR1000 PRPR1000 PR1000:INPUT FILTER
EXPR1032 *PR1010 PRPR1010 PR1010:PRINT JOB MANAGER JOB
EXPR1040 *PR1011 PRPR1011 PR1011:PRINT JOB MANAGER FILE
EXPR1041 *PR1012 PRPR1012 PR1012:ODS
EXPR1042 *PR1020 PRPR1020 PR1020:UI-MANAGER
EXPR1043 *PR1030 PRPR1030 PR1030:SPOOL PARAMETER READ
EXPR1110 *PR1031 PRPR1031 PR1031:JOB FINISHED OR DELETED
EXPR1120 *PR1032 PRPR1032 PR1032:USER DATA
EXPR1130 *PR1040 PRPR1040 PR1040:SNIPDS BACKEND
EXPR1140 *PR1041 PRPR1041 PR1041:BINS USED
EXPR1200 *PR1042 PRPR1042 PR1042:INPUT BIN USED
EXPR1201 *PR1043 PRPR1043 PR1043:OUTPUT BIN USED
EXPR1202 *PR1110 PRPR1110 PR1110:HOST DOWNLOADED
EXPR1400 PR1120 PRPR1120 PR1120:LP TRANSMISSION
EXPR1410 PR1130 PRPR1130 PR1130:HOT DIRECTORY PRINT JOB
EXPR1411 PR1140 PRPR1140 PR1140:LU 6.2 PRINT JOB
EXPR1412 PR1200 PRPR1200 PR1200:XFILTER LCDS REPORT INFO
EXPR1413 PR1201 PRPR1201 PR1201:XFILTER LCDS ADDITIONAL
EXPR1420 PR1202 PRPR1202 PR1202:XFILTER LCDS MORE ADDITI
EXPR1421 PR1400 PRPR1400 PR1400:B1 START SUBSYSTEM
EXPR1422 PR1410 PRPR1410 PR1410:E1 VOLUME HANDLING
EXPR1423 PR1411 PRPR1411 PR1411:F5 HDR1 HANDLING
EXPR1424 PR1412 PRPR1412 PR1412:F6 HDR2 HANDLING
EXPR1425 PR1413 PRPR1413 PR1413:F7 HDR3 HANDLING
EXPR1426 PR1420 PRPR1420 PR1420:N5 PARAMETER SECTION 1
EXPR1430 PR1421 PRPR1421 PR1421:N6 PARAMETER SECTION 2
EXPR1451 PR1422 PRPR1422 PR1422:N7 PARAMETER SECTION 3
EXPR1452 PR1423 PRPR1423 PR1423:P4 PARAMETER SECTION 4
EXPR1453 PR1424 PRPR1424 PR1424:P5 PARAMETER SECTION 5
EXPR1454 PR1425 PRPR1425 PR1425:P6 PARAMETER SECTION 6
EXPR1455 PR1426 PRPR1426 PR1426:P7 PARAMETER SECTION 7
EXPR1456 PR1430 PRPR1430 PR1430:PRINTING RUN
EXPR1457 PR1451 PRPR1451 PR1451:U1 USER SPECIFIC
EXPR1458 PR1452 PRPR1452 PR1452:U2 USER SPECIFIC
EXPR1459 PR1453 PRPR1453 PR1453:U3 USER SPECIFIC
EXPR1600 PR1454 PRPR1454 PR1454:U4 USER SPECIFIC
EXPR1601 PR1455 PRPR1455 PR1455:U5 USER SPECIFIC
EXPR1602 PR1456 PRPR1456 PR1456:U6 USER SPECIFIC
EXPR1603 PR1457 PRPR1457 PR1457:U7 USER SPECIFIC
FORMATS PR1458 PRPR1458 PR1458:U8 USER SPECIFIC
IMACPRPR PR1459 PRPR1459 PR1459:U9 USER SPECIFIC
TYPEPRPR PR1600 PRPR1600 PR1600:FTP BACKEND
TYPSPRPR *PR1601 PRPR1601 PR1601:FTP JOB FINISHED
VMACPRPR *PR1602 PRPR1602 PR1602:FTP TRANSMISSION PRINT FIN
VMXGINIT *PR1603 PRPR1603 PR1603:FTP TRANSMISSION GEN OCT
May 30, 2005 All of the datasets are created, but only those fifteen
asterisk-flagged datases have been decoded and validated
with test data records; all others have only one variable
kept. As there are multiple records for a single job, it
may be necessary to post-process these data to combine to
get job totals, so this is preliminary support.
Thanks to Krista Neven, KBC Bankverzekeringsholding, BELGIUM.
Change 23.141 Enhancement adds MIPFACTR= as a parameter to convert MSU
GRAFWRKX to MIPS, added graph of MIPS used, supported LPARSHAR as
May 30, 2005 a percentage to fix the LPAR percentages.
Thanks to Chuck Hopf, MBNA, USA.
Change 23.140 DB2 Version 8.1 Support: More IBM INCOMPATIBLE changes.
VMACDB2 Errors INVALID DATA FOR QLACCPUR, QLACCPnt, causing
May 30, 2005 INVALID DATA FOR QLACCPUL, QLACCPUR, QLACDBAT messages.
Jul 17, 2005 Change 23.111 discovered that DB2 8.1 sets QPACLEN=zero
to indicate that the real QPACLEN is in the first 2 bytes
at OFFQPAC, but when a QLACLEN=0 segment caused errors,
I realized this "feature" apparently can apply to all DB2
segments, so VMACDB2 was revised to test each segment for
LENxxxx=0 and NRxxxx non-zero, with this inserted code
OFFxxxx=OFFxxxx
IF LENxxxx EQ 0 AND NRxxxx GT 0 THEN DO;
INPUT @OFFxxxx LENxxxx &PIB.2. @;
OFFxxxx=OFFxxxx+2;
LENxxxx=LENxxxx+2; <<= See Change 23.182
END;
to pick up the new LEN and modify the OFFSET.
-Note: The LENQLAC=0 SMF records did NOT produce that same
INVALID DATA message when those records were read by SAS
under Windows; instead, the misaligned RB8. fields were
input as very large negative numbers, but there was no
error message, and I had not used PROC MEANS to see that
that invalid values existed in the output dataset. This
is one of few real differences in executing MXG on ASCII
platforms; ASCII is more tolerant of bad data than z/OS!
-Change 23.181 updated this text and is required for V8.1.
Thanks to Ingvar Rosenberg, SEB, SWEDEN.
Thanks to Glenn Lundgren, SEB, SWEDEN.
Change 23.139 Support for CyberFusion user SMF record has been revised,
FORMATS now that DSECTS that match the data records have been
VMACCYFU received. All of the bit mapped fields are now decoded
May 29, 2005 by 43 new MGCYFxx formats, although there are a few cases
where the hex value is not described in the DSECT EQU's,
so some final tweaking will be required.
Thanks to Robin Murray, ManuLife, CANADA.
Change 23.138 Cosmetic. Labels for SMF88SC1/2/3 are clarified to read:
ADOC88 SMF88SC1='TYPE 1*COMPLETIONS'
VMAC88 SMF88SC2='TYPE 2*COMPLETIONS'
May 30, 2005 SMF88SC3='TYPE 3*COMPLETIONS'
and the explanation from the SMF manual Section 9.1.1.2
was added in the ADOC88 member for those three variables.
Thanks to Helmut Rose, COM Software, GERMANY.
Change 23.137 Support for CA SYSVIEW CICS XPFCMCR DSECT user SMF data
EXSYSVCI record creates these new datasets:
EXSYSVPC -Subtype 17: Documented in XPFCMRC, creates these data:
EXSYSVFC dataset dddddd description
EXSYSVTS SYSVCICS SYSVCI SYSVIEW CICS PERFORMANCE (CICSTRAN)
EXSYSVIN SYSVPROG SYSVPC SYSVIEW CICS PROGRAMS
IMACSYSV SYSVFILE SYSVFC SYSVIEW CICS FILES
TYPESYSV SYSVTEMP SYSVTS SYSVIEW CICS TEMP STORAGE
TYPSSYSV The SYSVCICS dataset is the same in structure as CICSTRAN
VMACSYSV and almost all of the variable names are also the same,
VMXGINIT although not all of the (newer) CICSTRAN fields exist in
May 29, 2005 the SYSVCICS dataset, and there are a few CICSTRAN vars
that are output instead in SYSVPROG,SYSVFILE or SYSVTEMP.
There are additional segments in the SYSVIEW subtype=17
record, but they were not populated in the test data, so
only the subtypes that could be validated were decoded in
this initial support. If data from the other segments is
really needed, updates will be made to this support.
-Subtype 23: Documented in XPFCSDCR, creates this data:
dataset dddddd description
SYSVINTV SYSVIN SYSVIEW SYSTEM DATA COLL INTERVAL
In a radical departure from previous MXG code, the names
of the variables in SYSVINTV are longer than 8-bytes. The
DSECT names are repeated inside structured names, and to
compact the names and avoid duplicates would have taken
more time that it was worth, at least for this first pass
as support for the SYSVIEW product, and especially for
this SYSVINT dataset, neither of which I expect will have
very much usage. I think long names, in general, are more
confusing than useful, so if it turns out that SYSVINTV
is of significant value, I'll revisit and compact the MXG
variable names.
- The DOCVER member will still only show the first eight
characters of the variable names, as that format is
limited so the format and label fit on one line. You
can always use a PROC CONTENTS to see the full name of
each variable in SYSINTV.
Thanks to James D. Lieser, United Health Group, USA.
Change 23.136 -Updates to BMC CMF "240" USER SMF record:
VMACCMF -New variables in CMF27C93 and CMF27CSC for 2105's:
May 26, 2005 C276RCRM='RECORD*CACHE*READ*MISSES'
C276LRED='LOC RCD*DMN/REC*CA*WRITES'
C2795AID='DEVICE ADAPTER ID'
C2795HDD='NO. OF HDD'S IN RAID RANK'
C2795HSS='HDD sector size'
C2795NVS='NVS space allocation'
C2795RFL='FLAGS BYTE, THUS:'
C2795RID='RAID RANK ID'
C2795RMR='record mode read requests'
C2795RRQ='RAID rank read requests'
C2795RRT='RAID RANK READ RESPONSE TIME'
C2795RSV='LOWER*INTERFACE*I/O*RESPONSE'
C2795RTY='RAID RANK TYPE, THUS:'
C2795SR ='RAID rank FB sectors read'
C2795SW ='RAID rank FB sectors written'
C2795TSP='TRACKS TRANSFERRED TO PPRC VO'
C2795WRQ='RAID rank write requests'
C2795WRT='RAID RANK WRITE RESPONSE TIME'
C2795XCW='XRC or CC contaminated writes'
C2795XSF='XRC or CC sidefile read requests'
C279XRSV='LOWER*INTERFACE*I/O*RESPONSE'
Thanks to John Kington, Convergys, USA.
Thanks to Dr. H. Pat Artis, Performance Associates, USA.
Change 23.135 -Top Secret Version 5.2 and 5.3 are now supported, simply
VMAC80A by expanding the test for RACFVRSN to include 52x,53x.
May 26, 2005 -Top Secret creates its own user record with SMF80DTP=114,
but that record is really in SMF 80 format, so the user
SMF record can be processed with MXG TYPE80A code, using:
//SMF DD
//SYSIN DD *
%LET MACFILE= %QUOTE ( IF ID=231 THEN ID=80; ) ;
%INCLUDE SOURCLIB(TYPS80A);
to change the (example) ID=231 records back to ID=80 so
they are processed by TYPE80 code.
-The SMF80DTP=114 record is not yet decoded, so the above
code will only output the RACF header variables into the
TYPE80CM dataset; when documentation from CA is received,
the DTP=114 record will be decoded.
Thanks to Brent Turner, CitiGroup, USA.
Change 23.134 -RACF Extended TP2=301 with TOK80LN2=0 was not expected,
VMAC80A so it generated an error message on the SAS log stating
May 26, 2005 the record was deleted, but now, a valid TP2=301 segment
only TOK80FLG and TOKSUBSY='OMVS' is created, for NOOMVS
for RACFEVNT=13:ALTUSER record, although the record is
still does not agree with the IBM documentation:
MXG TOK80LN2 is byte 11 of the TP2=310 segment, which
is documented:
Byte 11: Length of subkeyword; 0 if byte 1 bit 1 is set
==> but byte 1 bit 1 is not set.
Byte 1 bit 4 "keyword has no subfield"
==> should be set, but it isn't.
-However, the documentation did allow the creation of two
new variables in datasets TYPE8009,8010,8012,8013:
KW301IGN='KEYWORD*IGNORED*INSUFFIENT*AUTHORITY?'
KW301DEL='SEGMENT*DELETED*VIA A*NOXXX*KEYWORD?'
so that you could detect the NOOMVS event.
Thanks to Erling Andersen, SMT, DENMARK.
Change 23.133 Support for Iway Software's IWAY (formerly EDA/SQL) SMF
EXIWAY1 record, creates these four datasets:
EXIWAY2 DDDDDD MXG MXG
EXIWAY4 DATASET DATASET DATASET
EXIWAY5 SUFFIX NAME LABEL
FORMATS
IMACIWAY IWAY1 IWAY01 IWAY SERVER START OF TASK
TYPEIWAY IWAY2 IWAY02 IWAY SERVER END TASK
TYPSIWAY IWAY4 IWAY04 IWAY SERVER BEGIN QUERY
VMACIWAY IWAY5 IWAY05 IWAY SERVER END QUERY
VMXGINIT
May 26, 2005
Thanks to Luis Mendoza, ABNAMRO, USA.
Change 23.132 Support for z/OS 1.7 (COMPATIBLE) and APAR OA10556.
VMAC1415 -TYPE70 dataset
VMAC7072 -New MACHTIME='MACHINE*TOD*DATETIME*STAMP' is created by
VMAC88 addition of new SMF70HOF='HYPERVISOR*DATETIME*OFFSET' to
VMAC94 SYNCTIME (SMF70IET + SMF70LGO). MACHTIME will be the
VMAC74 true GMT datetime value, independent of the IPL time and
May 21, 2005 site GMT offsets, and will be used by SCRT to know the
Oct 5, 2005 true time for IBM bills, since it is possible to IPL
Dec 12, 2005 with repeated/future/past datetimes, causing double
Oct 1, 2012 accounting for MSUs, etc. However, this value has not
yet been validated with SMF70LGO populated.
-SMF70HWM='CPC*PHYSICAL*MODEL*IDENTIFIER' is created, and
STFBIT04='SMF70MDL*MODEL*CAPACITY*ONLY?' flag, if true,
then SMF70MDL contains only the CPC MODEL CAPACITY, and
SMF70HWM has the CPC PHYSICAL MODEL IDENTIFIER.
-STFBIT03='SMF70LAC*NO LONGER*INCLUDES*CPU WAIT?'
-SMF70Q00='PERCENT*WHEN*IN READY*LE N CP-S' thru variable
SMF70Q12='PERCENT*WHEN*IN READY*LE N+12 CP-S' now track
the PCTRDYWT, but based on IN-READY greater than the
number of CP engines.
-TYPE70PR dataset:
-LPARCLND='CAPACITY*LIMIT*NOT*DEFINED' is now reserved.
so the new label (new in Sep 2012, MXG 30.07) reads
LPARCLND='RESERVED*FIELD*SINCE*Z/OS 1.7' and the value
is now a blank instead of either Y or N.
-Note that if LPARWTFD='Y' (WAIT TIME FIELD DEFINED?) is
true, then LPARCPUX (SMF70BND) contains the maximum
logical processors defined as shown at the HMC, starting
with z900 processors. The Active Logical Processors
have an online time SMF70ONT greater than zero, which is
how/why MXG now counts NRCPUS.
-TYPE70Y2 Crypto dataset, new variables:
R702NH2B='SHA-256*DATA*BYTES*HASH'
R702NH2C='SHA-256*CALLS*TO*HASH'
R702NH2I='SHA-256*PCMF INSTR*USED TO*HASH'
-TYPE74CA dataset, new variable:
R745DCCU='CONFIGURED*CONTROL*UNIT*TYPE'
-TYPE791/TYPE792: (Note added Dec 12, 2005):
-MXG used variable name suffix TIFE (Eligible CPU) but
the IBM field name is TIFC, and my choice caused some
confusion, so the IBM Field name of TIFC is now used.
-R791NFFI/R792NFFI normalization factor was added and
is used to normalize R791TIFA/R792TIFA times back to
CP seconds.
-TYPE88 dataset, new variables:
SMF88EAF='IXLOGR*STAGING*ASYNC BUFFER*FULL'
SMF88ERS='RESERVED*WRONG NAME' SMF88EDO in manual,
but that field name already exists. Investigating.
-TYPE94 dataset, new variables:
S9SDEMN1='SECURE*DATA*ERASE*MOUNTS*DC 1'
S9SDEMN2='SECURE*DATA*ERASE*MOUNTS*DC 2'
S94XLCSG='VTC 0*WRITE*PROTECT*MODE'
S94XLCSH='VTC 1*WRITE*PROTECT*MODE'
S94XLCSI='VTC 2*WRITE*PROTECT*MODE'
S94XLCSJ='VTC 3*WRITE*PROTECT*MODE'
S94XLCSK='VTC 4*WRITE*PROTECT*MODE'
S94XLCSL='VTC 5*WRITE*PROTECT*MODE'
S94XLCSM='VTC 6*WRITE*PROTECT*MODE'
S94XLCSN='VTC 7*WRITE*PROTECT*MODE'
-TYPE99U7 dataset Subtype 7 new variable
SM997SCS='SUB*CHANNEL*SET='
-TYPE99UA dataset Subtype 10 - need test data to decode
-TYPE1415 dataset, new flag variable ('Y',' '):
SMF14LGE='DSNTYPE*LARGE*FORMAT?'
Note that if SMF14LGE='Y', the value in variable TTRN
will contain 'TTTR', and if EXTNDSEQ='Y' the value in
TTRN will contain 'TTTT', the total number of tracks
used across all volumes.
Oct 5, 2005: Original Reserved Change Number replaced.
Change 23.131 Support for DB2 IFCID=313 creates T102S313 dataset, with
FORMATS dataset labeled 'CHECKPOING LONG RUNNING UR-S'.
VMAC102
May 24, 2005
Thanks to Christa Neven, KBC Bankverzekeringsholding, BELGIUM
Change 23.130 To update the ITRM data dictionary for MXG datasets, all
IMACACCT of my code and datasets created by that code are examined
IMACICD6 and numerous corrections were made as a result of that
IMACICMR process. Most are spelling errors, but many cause the
RMFINTRV variable to be not-kept, or incorrectly labeled, etc.
VMAC110 VMAC110: FILADDCN changed to FCADDCN in CICSRFDI keep.
VMAC30 DSxACT/TCT/TDE/TWT for DSH/DSI/DSJ/DSK FORMATed
VMAC6 DSGTOTMT/DS2/DS3/DS4 formatted.
VMAC7072 DSGTOTWL dual use, now DSGTOTWT kept in CICDS
VMAC80A instead of DSGTOTWL, DGTOTWT labeled.
VMACDB2 VMACICE: SRCEOD changed to SRCEOE in ICEBR8SN keep.
VMACICE IMACICD6: $EBCDUC8. changed to $EBCDIC8.
VMACTPMX IMACICMR: CMDDB2CT formatted TIME12.2.
VMACVMXA IMACACCT: IDMSCPTM formatted TIME12.2. (in comments).
May 24, 2005 VMAC80A: KW24ASTE,KW24KERB kept, labeled in TYPE8024.
CLAS26NM,RES25MEx,RES25TEx labeled in 25/26.
VMACTPMX: TPMUSERC,TPMXPLEX labeled.
VMAC30: SMF30MRD,SMF30MRI formatted TIME12.2
VMAC6: SMF6FTL, leading asterisk removed in label
VMAC7072: IFAWAITM, R723IFAT, R723IFCT formatted TIME12.2
MXGCIN, NRPHYCPS, R723NFFI labeled.
Also NRPHYCPS now labeled in ASUMCEC,ASUM70PR.
VMACDB2: QISESTMT kept in DB2STATS
RMFINTRV: PCTIFABY labeled.
VMACVMXA: APLSDTST labeled.
USAPLxxx temporary variables dropped in
VXAPLCMS/SLM/SLN/SLP/SLO datasets
PCT-prefixed VXAPLSLP/SLO and TICKS labeled.
MRHDRRC labeled
BYTOA and BYFRA are MGBYTES formatted, LENGTH 8
and BFFRA was removed from LENGTH 8.
Stray text in label of PT4ID corrected.
IFINOCWR/IFOUOCWR are kept, logic corrected.
New variables in VXAPLSRV labeled, kept.
Temp variable OLDTODON is dropped from VXBYUSR.
Thanks to Chris Weston, SAS ITRM Development Cary, USA.
Change 23.129 Cosmetic. Label for IPMIGR2 should have been SECONDARY
VMACIPAC as IMIGR1 is 'PRIMARY*MIGRATION*CLASS*NAME'.
May 23, 2005
Thanks to Tom Parquette, AXA Technology Services, USA.
Change 23.128 New z/VM 5.1 1.19 record was misdocumented by IBM, which
VMACVMXA caused ERROR* PROBABLE DATA LOSS DUE TO MONWRITE FAILURE.
May 23, 2005 Correct MRHDRLEN=368 was doc'd as 365, and two bytes at
offset 42 were not listed in the length column, but MXG
was also not guilt-free, as I had guessed wrong at where
those two undocumented bytes were located. Dataset
VXMTRQDC is now corrected.
Thanks to Pat Curren, SuperValu Inc, USA.
Change 23.127 A semi-colon at the end of a %MACRO invocation caused a
VMXGFOR "180" syntax error, and now I know that it is NOT true
May 24, 2005 that every SAS statement ends with a semi-colon!
While MXG Change 20.327 removed all invocations of the
now-unneeded %VMXGFOR macro from all MXG PROC SORTs,
a site with an old PROC SORT DATA=A OUT=B %VMXGFOR; in
their report program failed with "FORCE" underlined.
%VMXGFOR was only needed because Version 5 of SAS did
not support the FORCE keyword; that macro generates
a blank for V5 and "FORCE" with V6 or later.
It turns out the culprit was the addition of the new
%VMXGVERS(23.05,VMXGFOR);
statement after the %MEND; statement in the VMXGFOR
member, added by Change 23.005. It also turns out that
it was that final semicolon after %VMXGVERS() that caused
the error, in this reply from SAS Technical Support:
"The problem is the semi-colons in the autocall source
files that follow the macro call. These semi-colons are
superfluous for the macro call, but not harmless when
contained in an autocall source file. When a macro call
is determined to be the first reference to an autocall
macro, the file containing the autocall macro definition
is processed until the end-of-file is reached and then
the macro is called. In this instance the macro
definition is read and processed. This consumes the
autocall source file up to and including the semi-colon
following the %MEND. Then the following macro call
(i.e., to %VMXGVERS) in the autocall source file is
processed. This consums the autocall source file up to
and including the right parenthesis, leaving the
semi-colon. The dangling semi-colon is then inserted
into the source stream (as model text) and then a call is
placed to the autocall macro that started the process.
This behavior is present in versions 6 thru version 9."
So, a final semi-colon has NEVER been needed after the
invocation of a %MACRO, and none of the examples in the
SAS Macro Manual (yes, we Read The Fine Manual!) show a
semi-colon after the invocation. For example, you can
use %ANALDB2R() and the report program executes!
Fortunately, it appears that only the %VMXGFOR member is
vulnerable, because it inserts text into a SAS statement.
All other VMXGxxxx members that have %VMXGVERS added are
"standalone" executions, and the extra semi-colon, even
though those members are autocalled, is superfluous.
But now I know what caused this strange error, and have
removed the trailing semicolon from the %VMXGVERS call
in the (still-archaic) VMXGFOR autocalled member.
Thanks to Matt Feeney, Defence Department, AUSTRALIA.
Change 23.126 -Dataset PDB.RMFMSUSE contains both Service and Reporting
ASUMMIPS Class obs, but variable RPRTCLAS was not kept, so you
May 18, 2005 couldn't identify which class the observation was for.
May 23, 2005 Now, RPRTCLAS is kept in PDB.RMFSUSE.
May 24, 2005 -Member IMACKEEP was not included, so you could not use
the MACKEEP= to tailor the ASUMMIPS execution. As an
example that you can now use:
//SYSIN DD *
%LET MACKEEP=
%QUOTE(
MACRO _RMFOUT RMFMSUSE %
MACRO _MIPSMSU
IF SYSTEM='TREX' THEN MIPSFACT=6.7;
ELSE MIPSFACT=5.7;
%
);
%INCLUDE SOURCLIB(ASUMMIPS);
_RMFMIPS;
_SMFMIPS
changes the output from PDB.RMFMSUSE to WORK.RMFMSUSE and
changes the MIPSFACT (MIPS per MSU) depending on SYSTEM.
-The default PROC PRINT for RMFMSUSE is now sorted by the
RPRTCLAS variable, so if you have both Reporting Class &
Service Class data, you will get separate reports. Since
they will overlap, having a single report was deceptive.
-The default PROC PRINT for SMFMSUSE did not use _SMFOUT,
causing an error if _SMFOUT was redefined.
Thanks to Dan Case, Mayo Foundation, USA.
Thanks to Chuck Hopf, MBNA, USA.
Thanks to Jim S. Horne, Lowe's Companies, Inc, USA.
Change 23.125 HSC V6 changed the STCLMU (subtype 4) SMF record, now STK
VMACSTC PTF L1H12EW documents the new record, but that PTF also
May 17, 2005 changes the record again, so records written with HSC V6
without the PTF will produce strange results in STCLMU.
-And, of course, no version flag is in the STK record, so
the (archaic) logic to test the Record Length is required
to determine if this is a valid pre-V6 record, a short
pre-V6 record (fixed by a prior PTF), an invalid HSC V6.0
prior to the PTF, or a valid HSC V6.0 record after PTF.
-And there are undocumented bytes in the record, as well,
between offsets 11 and 16 (decimal).
Thanks to Dean A. Ruhle, JC Penney Co., Inc, USA.
Thanks to Michael Gresham, JC Penney Co., Inc, USA.
Thanks to David M. Cole, STK, USA.
Change 23.124 -Duplicate SMF type 30 interval records caused duplicate
VMAC30 observations in PDB.SMFINTRV because the revisions in MXG
BUILD005 Change 22.320 removed the NODUP option from the SORT.
May 17, 2005 This change restores the NODUP option.
-The _BTY30UV macro in VMAC30 was revised so the first
five variables match the sort order used in BUILDPDB:
MACRO _BTY30UV READTIME JOB JESNR INITTIME INTBTIME
MULTIDD DESCENDING EXTRADD
just for consistency, even though the PDB.SMFINTRV that
can be created with TYPS30 (or with the _STY30UV macro
invocation) is NOT the same PDB.SMFINTRV dataset that is
created by BUILDPDB:
-The BUILDPDB-built PDB.SMFINTRV has consolidated all of
the "MULTIDD" observations into a single observation.
-The TYPS30/_STY30UV-built PDB.SMFINTRV still contains
all of the additional and confusing "MULTIDD" obs.
Thanks to Joan Nielsen, (i)Structure, USA.
Change 23.123 Variables CPUIFATM and CPUIFETM (total) are added to the
VMXGRMFI PDB.RMFINTRV dataset, and individual workload variables
May 17, 2005 (like BATIFA, BATIFE, etc) with IFA/IFE CPU times added.
Oct 19, 2005: See Change 23.265; 23.123 was incomplete.
Thanks to Andre Baltimore, Unigroup, Inc, USA.
Change 23.122 Datasets PDB.TYPE70LP and PDB.ASUMTAPE were not in the
WEEKBLD default WEEKBLD member, but as they are created in the
WEEKBLDD JCLPDBx daily job examples, they are now added to the
WEEKBLDT weekly example job.
May 17, 2005
Thanks to Hugh Lapham, Royal Canadian Mounted Police, CANADA.
Change 23.121 ERROR: BY VARIABLES NOT SORTED ON DATASET WORK.BOTHCEC is
VMXG70PR corrected by an insertion of a PROC SORT to ensure the
May 16, 2005 order is correct; values for SHIFT were the culprit.
Thanks to Tony Curry, BMC, USA.
Change 23.120 Support for ESS GEPARMKY=004Dx creates ESSMAIL2 variable
IMAC6ESS in TYPE6 dataset when IMAC6ESS is enabled.
VMAC6
May 13, 2005
Thanks to Engelbert Smets, Provinzial, GERMANY.
Change 23.119 Change 23.025 was not tested with TRENDIN data, and the
UTILCONT semicolon after &PDBOUT..ASUMSIZE should not have been
May 13, 2005 there, since the macro code is still part of the SET.
Thanks to Jeffrey A. Harder, Farm Bureau Insurance, USA.
Change 23.118 Processing CICS Journal Records (SUBTYPE=0) didn't output
VMAC110 the last record. The test was changed to
May 12, 2005 IF LOC+GLRHLEN-1 LE LENGTH THEN GOTO JOUR5202;
Thanks to Helmut Roese, COM Software, USA.
Change 23.117 If you built your own program, and had _CDE40 before the
VMAC40 _CDE30 macro, you got ERROR 48-59 with the below two
May 12, 2005 notes:
WARNING: VARIABLE PROGRAM HAS ALREADY BEEN DEFINED AS NUMERIC
ERROR 48-59: THE INFORMAT EBCDIC WAS NOT FOUND OR COULD NOT BE LOADED
because MXG didn't fully protect the variable PROGRAM.
-Per the text of Change 20.243, PROGRAM was added to the
ARRAY statement for character variables in VMAC40 so that
the _CDE40 could be located prior to the _CDE30.
-This is really a bummer, as PROGRAM is not even input in
SMF 40 records, but the code in VMAC40 makes a call on
VMACEXC2, which has a PUT statement in case of an error
in the decoding EXCP segments, and when the PUT was the
first instance of variable PROGRAM, SAS made it numeric
which then spawned numerous other errors when it was
referenced as a character variable.
Thanks to Michael S. Noud, IRS, USA.
Change 23.116 Very bad values for some data fields in TYPE 74 subtype 5
VMAC74 records for HDS on their Tagmastore USP, like negative
May 12, 2005 values for SCTO (R745DTC). Under investigation with HDS.
Reporting site now has a microcode fix which is believed
to correct the error; no fix number at press time.
Change 23.115 The default OPTIONS and OPTIONS2 did not agree with the
ASMTAPEE documentation in Change 23.030, and the internal comments
May 11, 2005 about default options were inconsistent. The comments
May 29, 2005 were clarified, and the default options in OPTIONS and
OPTIONS2 are set as documented, for IBM VTS Systems.
As noted, if you have STC VTS, you must remove DOMXIT to
disable the IBM Volume Mount Exit, because we still have
not been able to find an equivalent Exit in STK's HSC,
but we're still working on that enhancement.
Updated: Jul, 2005. See Change 23.162/23.177/23.230.
-Line 3139 extended into column 72, making it look like a
continuation.
Thanks to Shane Dowling, DEWR, AUSTRALIA.
Change 23.114 DCOLLECT dataset DCOLCLUS, VSAM Dataset Info, was not
DAILYDSN used in the original "Daily Dataset Billing" (JCLDAYDS),
May 11, 2005 but has been added so that it will be there if needed.
Thanks to Chairat Tiajanpan, KCS, Thailand.
Change 23.113 -Zero obs with a Solaris cube. The _UTNGCNT array sizer
ADOCTNG only worked for NT data, so the INSTREAM code was not
EXTNT128 generated due to a missing OUTPUT statement, and the new
EXTNT129 MIB-2 UNKNOWN object was processed last, causing 0 obs.
EXTNT130 New So028 dataset supports the MIB-2 object and new field
EXTSO028 added to existing So027 dataset is now supported.
FORMATS -Cubes with data from multiple days had only last day's
IMACTNG data output. Two tests that previously read
TYPETNG IF NRPAREN GT 1 AND NRSYSTMS GT 1 THEN DO;
VMACTNG appear to be the culprit, and by commenting out to be
VMXGINIT IF NRPAREN GT 1 /* AND NRSYSTMS GT 1 */ THEN DO;
May 10, 2005 data from all days was output. That heuristic was needed
May 23, 2005 early on in TNG support, but I think subsequent redesign
May 28, 2005 eliminated the need for that part of the test to invoke
outputting, BUT PLEASE VALIDATE THAT YOU GET DATA FROM
ALL OF THE SYSTEMS, AND ALL OF THE DAYS IN YOUR INPUT!!
-New NT platform names of NTP500I and WNS502I were added
to the MACRO _NTPLAT to eliminate UNKNOWN PLATFORM msgs.
-Support for new Objects for NT: RAS PORT, MICROSOFT
GATHERER, and MICROSOFT SEARCH.
-May 28: $MGTNGVN Format was completely revised, as two
Solaris metrics were identical in first forty characters:
'Interface Traffic (Lifetime) Collisions %'
'Interface Traffic (Lifetime) Collisions'
causing INSTANCES EXCEEDED error messages when tested.
That %MGTNGVN format, used to lookup the concatenation of
Platform abbreviation, Object Name, and Metric Name, had
only allowed 40 positions for metric name. To eliminate
future duplicate exposures, all TNG cubes were read to
find the maximum metric name of 58 chars, so the format
was expanded to allow 64 char metric names, but with the
2-char platform abbreviation and the 20-character object
name, the "expanded length format" now had DEFAULT=86 in
its VALUE statement. But with only 72 positions of MXG
input text, some of the value definitions had to be split
into two lines, a nasty but necessary implementation.
But then the fun began. Read Change 23.144 for solution.
Since more than 40 bytes of METRIC name are now being
looked-up in the format, data for all past test cubes
was read to find all metrics longer than 40 bytes, and
those 55's format data-values were revised so they would
be found in the new format; the longest was 58 bytes.
But if I missed one, it will show up as an observation
in the UNKNOWN dataset, so please check your SAS log to
make sure I found them all.
Thanks to Michael L. Kynch, International Paper, USA.
Thanks to Peter Krijger, ANZ National Bank Limited, NEW ZEALAND.
Change 23.112 Change 23.070 reset STARTIME for 58,59, and 01 seconds,
VSETZERO but that didn't protect delays beyond 1 second; new data
May 9, 2005 shows that 70 and 72 records with seconds 02 are created;
in fact, the SMFTIME of the 72 subtype 4 was 4.5 seconds
after the interval pop, and that subtype 4 had 00 seconds
for its STARTIME! So the test in VSETZERO is now revised
to set seconds 58 thru 05 back to seconds 00. The main
impact without this change was that the PDB.ASUMCEC had
had two observations, one with 01 seconds, one with 02
seconds as their STARTIME.
Thanks to Diane Eppestine, SBC, USA.
Change 23.111 Support for DB2 V8.1 DB2ACCTP Package Data now validated.
VMACDB2 Change 23.098 guessed wrong, but IBM didn't help; in the
VMACDB2H new IFCID=239 structure, the LENQPAC is zero! But, in
May 9, 2005 a very weak defense of their redesign, there is a very
obscure note that says it is now "legal" to have a DB2
data segment with Length=zero, and it now means: read the
first two bytes at the offset, and use that as the length
of the data segment! So with a hex dump of one of the
new records, the code is now corrected and DB2ACCTP will
be valid for DB2 V8.1 or earlier versions as well.
-There was also an extraneous PUT QWHSRELN= in VMACDB2H
added by Change 23.098, only for DB2 V8.1, but lots of
messages would have been printed, if you had DB2 V8.1,
since it put that message for EVERY SMF 100/101 record!
It was removed by this change.
-Note that this change is required for DB2 V8.1 if there
are ANY package segments in your DB2 records; prior notes
that earlier versions of MXG support DB2 V8.1 are wrong.
Thanks to Steve Olmstead, Thomson, USA.
Change 23.110 Cosmetic. Variable ESMFFAVG was listed in the KEEP list
TYPEVM but was a misspelling and was removed; variables ESMFIAVG
May 5, 2005 and ESMFOAVG are now FORMATed TIME12.2.
Thanks to Sudie Wulfert-Schickedanz, Anheuser-Busch.
Change 23.109 Support for VM:Account product, which reversed the order
TYPEVM of dates from MMDDYY to YYMMDD and writes longer records.
May 5, 2005 This iteration does not support the additional data but
that support will be added in a later change.
Thanks to Richard J. Reents, Abbott Labs, USA.
Change 23.108 -Label was missing for variable PCTCPTBY in VMACQACS
VMACQACS PCTCPTBY='PERCENT WHEN*SYSTASK*CPU BUSY' and "8" in the
VMAC110 label for SYBTAC was changed to *.
VMACDB2 -VMAC110, new Stat variables prefixed DSH/DSI/DSJ/DSK
VMXGRMFI that are time values were not FORMATed TIME12.2;
May 5, 2005 DSxTOTMT variables were not formatted TIME12.2;
May 17, 2005 DSGTOTWT replaces DSGTOTWL in CICDS variable; TOTWL is
a suffix for CICDSPOO variables and had been reused.
-VMACDB2, new 8.1 variable QISESTMT was not kept.
-RMFINTRV, variable PCTIFABY labeled, ZOS70WLA removed.
Thanks to Chris Weston, SAS Institute ITRM Development, USA.
====== Changes thru 23.107 were in MXG 23.04 dated May 4, 2005=========
Change 23.107 Several macro definitions were incomplete or mislocated.
VMACVMXA -MACRO _SAPLSRV statement was missing; its code was
May 4, 2005 inside the MACRO _SAPLEDT definition.
May 16, 2005 -Invocations of _SAPLEDT and _SAPLSDT were missing in
the _DELTALL macro definition.
-The _SSYTSCG and _SSYTSYG macros had the DELTATM located
too late, and it was not set negative when missing to
protect the subsequent divides by DELTATM.
-There is no _SAPLAPL macro, but there's a _VAPLAPL macro
now created. The VMXA design preceded the _Vdddddd
macro definition (lists variables kept in the "dddddd"
token's dataset), and the old VMACVMXA uses _Vdddrrr
macros for domain/record groupings. _VAPLAPL wraps all
of the 25 Application Server _WAPLrrr datasets, each of
which has its own _Sdddddd macro, so that's why there
is on _SAPLAPL sort macro definition.
-A number of ommissions for new variables were fixed.
Thanks to Chris Weston, SAS Institute ITRM Development, USA.
Change 23.106 -Variable TIWRDCT should not have been kept in MONIIDS nor
VMACTMO2 should its second label exist; that name was used twice
May 3, 2005 but was caught in QA and the correct TIIDSWRC/TIIDSWRT,
May 5, 2005 fields were input and labelled, but I failed to clean up
this part of the original duplicate names.
-Label for PAJTDLYT and PAJTDLYC were reversed, and some
lables had blanks instead of '*' SPLIT characters.
Thanks to Chris Weston, SAS Institute ITRM Development, USA.
Change 23.105 TYPE73 variable SMF73CSS, Channel Subsystem ID was moved
VMAC73 to the end of the Channel Path Control Section, if bit 2
May 3, 2005 of SMF73CFL (Hardware allows multiple logical channel
subsystems) is enabled, by z/OS 1.5, but I missed that
relocation. SMF73CSS is now conditionally INPUT from the
new location when that bit is enabled.
Thanks to Joel Giacobbe, Federal Reserve Bank, USA.
Change 23.104 The ASUMTALO/ASUMTMNT summarization of tape drives and
ANALCNCR tape mounts is enhanced so that you can summarize by
ASUMTALO "groups" that you define, and ANALCNCR can now be used
ASUMTMNT to determine which jobs were active at the time of the
May 3, 2005 maximum tape drive allocation.
May 11, 2005 -For ASUMTALO, the default assumed all tape devices were
May 16, 2005 shared across all systems in the PDB.TYPETALO input data,
May 18, 2005 and were thus summarized by DEVICE.
-For ASUMTMNT, the default summarized all tape mounts BY
SYSTEM as the high level variable.
a. This change provides these local tailoring options:
-For ASUMTALO, you can define a "group" variable and then
create it based on SYSTEM, and that "group" variable
will then be used as the high-level summary variable in
the BY statements. For example, you can create a group
variable named LOCATION and populate that variable with
this example using the new old-style macros "instream":
//SYSIN DD *
%LET MACKEEP=
%QUOTE(
MACRO _GRPALNM LOCATION %
MACRO _GRPALCD
IF SYSTEM IN ('SYS1','SYS2') THEN LOCATION='DALLAS';
ELSE IF SYSTEM IN ('XYZ1','XYZ2') THEN LOCATION='NYC';
%
);
%INCLUDE SOURCLIB(ASUMTALO);
-The ASUMTALO data will then show tape device utilization
for each DEVICE type within each LOCATION.
-For ASUMTMNT, you can also define a "group" variable and
create it based on SYSTEM, and that "group" variable
will then be used as the high-level summary variable in
the BY statements. The two macro names are different, in
case you want to sum TMNT different than TALO, but the
structure is similar in this example:
//SYSIN DD *
%LET MACKEEP=
%QUOTE(
MACRO _GRPMNNM LOCATION %
MACRO _GRPMNCD
IF SYSTEM IN ('SYS1','SYS2') THEN LOCATION='DALLAS';
ELSE IF SYSTEM IN ('XYZ1','XYZ2') THEN LOCATION='NYC';
%
);
%INCLUDE SOURCLIB(ASUMTMNT);
-The ASUMTMNT data will then report tape mount statistics
for each SYSTEM within each LOCATION. If you want your
mount statistics to be summarized by each LOCATION (and
nor for each SYSTEM at each LOCATION, you would just add
SYSTEM=' ';
as the last statement in your _GRPMNNG definition.
-For your daily "BUILDPDB" job, which normally includes
both ASUMTALO and ASUMTMNT, you can put all four of those
macro definitions (_GRPALNM,_GRPALCD,_GRPMNNM,_GRPMNCD)
in a single %LET MACKEEP= for that job (or they could be
defined in the IMACKEEP member and then would apply to
any execution of their respective ASUM members).
b. Revision to find contributors to maximum value:
-ANALCNCR was enhanced so that you can print each of the
input events that caused the "maximum concurrent value".
When you specify %LET MXGDEBUG=ANALCNCR; prior to the
execution of ANALCNCR, then dataset WORK.MXGDEBUG will
be created with the first phase observations, and you can
then use this program to find the time of the peak value,
and then print the specific input events that created the
maximum. For example, ASUMTALO calculates maximum tape
drives allocated, so you would use:
%LET MXGDEBUG= ANALCNCR;
%INCLUDE SOURLCIB(ASUMTALO);
PROC SORT DATA=MXGDEBUG;
BY DESCENDING CONCURNT;
DATA _NULL_;
SET MXGDEBUG;
IF DEVICE=:'9840HSM';
PEAKTIME=PUT(TIMESTMP,DATETIME21.2);
CALL SYMPUT('PEAKTIME',PEAKTIME);
STOP;
RUN;
PROC PRINT DATA=PDB.TYPETALO;
WHERE DEVICE=: '9480HSM' AND
ALOCSTRT LE "&PEAKTIME"DT LE ALOCEND;
RUN;
to print which observations from the PDB.TYPETALO data
caused that maximum tape drive allocations.
For ANALCNCR with other input data, the test for the
"DEVICE" variable would need to be changed to use the
appropriate variable, the SET PDB.TYPETALO would need
to be changed to the input dataset, and the correct
start and end variables would need to be used in the
selection around "&PEAKTIME"DT test.
c. Additional chagnes:
-ANALCNCR was revised to re-locate the INCODE= operand;
this was required so that the "group" support, above,
could be implemented.
-A new TRACE= option for internal debugging was created
in ANALCNCR, unlikely to be needed outside development!
-An unrelated enhancement was also made to ASUMTMNT; the
definition of the mount time values for each of the mount
"buckets" was externalized, so they can also be changed
by redefining those macros with %LET MACKEEP=, as above.
Thanks to Andre D. Walker, Bank of America, USA.
Change 23.103 Documentation. Selecting ANALDB2R for an interval period
ANALDB2R (13:00 to 14:00), MXG's criteria selects any transaction
May 3, 2005 that started in that interval, or ended in that interval,
or started before and ended after that interval, so the
MXG report can easily show an "INTERVAL DURATION" that is
greater than the one hour you requested, but it includes
all transactions that spent any time in the requested
interval. IBM's DB2PM reports appear to only include the
transactions that started and ended within the requested
interval, so MXG can report more activity than DB2PM.
Thanks to Peter Farrell, Commerce Bank of Kansas City, USA.
Change 23.102 Cosmetic, but confusing! The label for PAGEINS/PAGEOUTS
VMAC30 is corrected to the TOTAL PAGE IN/OUT FROM AUX STORE, as
May 3, 2005 they count both blocked and unblocked pages moved.
Thanks to Melanie Hitchings, BT, ENGLAND.
Change 23.101 Support for APAR OA10901, new SMF30ZNF variable with the
VMAC30 zAAP CPU Normalization factor is added to the datasets
May 2, 2005 TYPE30_V/PDB.SMFINTRV, TYPE30_4 and TYPE30_5.
Change 23.100 ASG/Landmark TMON for CICS/TS V2.3 supports CICS/TS 3.1
VMACTMO2 with toleration PTFs for their product, but there are no
May 1, 2005 changes to their data dictionary, i.e., there were no
changes made in their records to add any new 3.1 fields.
Thanks to Roland Schiradin, Alte-Leipziger, GERMANY.
Change 23.099 Support for IMS Version 9.1 was already in MXG 22.22:
VMACIMS -IMS Monitors: BMC IMF, Candle ITRF, Landmark TIMS.
May 1, 2005 -MXG's "Supported" TYPEIMS7 to create IMS0708 dataset
-MXG's ASMIMSL6/JCLIMSL6 to create IMSTRAN dataset.
-There were no significant changes by IBM to any of the
IMS log records in IMS Version 9.1, compared with 8.1.
-The three IMS Monitors that are fully supported by MXG
(and are STRONGLY recommended - See Newsletter 25!!),
BMC's IMF, ASG/Landmark's TIMS, and IBM/Candle's ITRF
products all create their own data records:
-IMF writes two records to the IMS log file, 'F9'x, 'FA'x
but there were no changes made by IMF Version 4.1.00 for
IMS Version 9.1 to the IMF records. However, MXG 22.08
is required for IMF records for all IMS versions, due to
corrections in sequencing of CIMSTRAN in Change 22.199.
Also, Change 22.241 in MXG 22.10 added ASUMCIMS example
for summarization of CIMSTRAN/CIMSDBDS IMF datasets.
-TIMS writes data to its own file; the last update to
TYPETIMS code was in MXG Version 20.09.
-ITRF writes additional records to the IMS log, but then
an ITRF program combines their records with IBM records
to create their file that MXG TYPEITRF then processes;
the last TYPEITRF code change was in MXG Version 17.09.
-MXG's only "Officially Supported" IBM-IMS-log-record read
program is TYPEIMS7, which combines log records 07 and 08
to create the IMS0708 dataset (capturing only resources,
with no response time). Those records were not changed
by IBM in IMS V9.1, but MXG Change 22.199 (in MXG 22.08)
was a major revision to the TYPEIMS7 logic for all IMSs.
- You must update the _IMSVERS macro in IMACIMS to tell
MXG the IMS version you are processing, and you cannot
concatenate IMS logs from different versions, as IBM
does not put a version number in their log records!
-MXG's "pseudo-supported" IBM-IMS-log-record read programs
in the JCLIMSL6 jobstream required no changes to support
IMS Version 9.1, but you must re-assemble ASMIMSL6 with
the IBM IMS Macro Library for IMS Version 9.1 to create
the load module for V9.1 records, and you must run
separate JCLIMSLx jobs with different load libraries and
process each IMS version's data separately; you cannot
concatenate the IMS logs from two versions and read with
JCLIMSLx. MXG 20.03 contained the last changes to these
members, and thus there was no need to create L7, L8, or
L9 suffixed ASMIMSLx/JCLIMSLx members.
-For processing JCLIMSLx/ASMIMSLx on ASCII platforms, MXG
Version 22.06 is required due to Change 22.128.
-IBM did insert fields in the IMS log 31x record in V9.1,
and VMACIMS is updated by this change (in MXG 23.04) for
that insert, but the insert was after any "important" IMS
data, and could only be observed if you were looking at
the IMS31I or IMS31O datasets that are written to //WORK,
but are neither kept nor used by MXG programs.
Thanks to Roland Brugger, Credit Suisse, SWITZERLAND.
Change 23.098 DB2 Version 8 restructured Package Data, and added many
VMACDB2 new variables to DB2ACCTP dataset:
Apr 30, 2005 QTXACHG QTXACHUS QTXACLMT QTXACLNO QTXACLUN QTXADEA
QTXADRNO QTXADRUN QTXAFLG1 QTXAILMT QTXAIRLM QTXALES
QTXALEX QTXALOCK QTXANPL QTXANRUN QTXAPREC QTXAQRY
QTXARLID QTXASLAT QTXASLMT QTXASLOC QTXASOTH QTXATIM
QTXAUNLK
QBACGET QBACSWS QBACRIO QBACSEQ QBACIMW QBACLPF
QBACDPF QBACNGT QBACSIO
QPCALLCT QPCLOSET QPDELETT QPDESCCT QPFETCHT QPINSRTT
QPLOCKCT QPOPENCT QPPREPCT QPSELECT QPUPDTET
Originally, the first ten packages executed by a plan
were written as ten segments in the SMF 101 subtype 0
IFCID=0003 records, and if more than 10 packages were
executed, additional SMF 101 subtype 1 IFCID=239 records
were created. MXG creates an observation in the DB2ACCTP
dataset from each package segment, independent of whether
it was in the 0003 or the 239 IFCID record. But with
DB2 V8.1, package segments are no longer written in IFCID
0003 records; instead only the IFCID 0239 records will
contain package data, and there are three new DSECTS
added that are always present, one of each for each
package segment.
(QXPK, QBAC, and QTXA, and in that order; the DB2 MACRO
Library had inconsistent documentation that will be
corrected with a doc APAR)
MXG will transparently use either 0003 and 0239 or just
0239 segments to create the DB2ACCTP observations, and
those added new variables will exist, but will only be
populated (i.e., non-missing) from DB2 V81 records.
Thanks to Steven Olmstead, Thomson BETA Systems, USA.
Thanks to Ray Willoughby, Thomson BETA Systems, USA.
Thanks to John B. Tobler, IBM Silicon Valley Lab, USA.
Change 23.097 Variables CTCKPNTS MAXLOCKS TOTLOCKS were added to the
VMACCIMS KEEP list of both CIMSTRAN and CIMSPROG, but those three
Apr 29, 2005 variables are only INPUT from the CIMSTRAN records, so
they are now removed from CIMSPROG KEEP list.
Thanks to Christa Neven, KBC Bankverzekeringsholding, BELGIUM
Change 23.096 Change 22.203 protected decoding of JCTJOBID if it was
VGETJESN blank or hex zero, to prevent unnecessary log messages,
Apr 29, 2005 but that caused TYPETASK to be blank in TYPE30_6 data,
because the "Early Address Spaces" records that are
written as type 30 subtype 6 interval records now have
have blanks for JCTJOBID.
(Historically, these records had JOB name in JCTJOBID,
then JCTJOBID was hex zeros, but now JCTJOBID contains
blanks in current z/OS type 30 subtype 6 records).
But they have SUBSYS='STC', so the logic was revised to
sets TYPETASK='STC' (and JESNR=.) if JCTJOBID is blank or
hex zero, and SUBSYS='STC'.
(And if blank-TYPETASK-value-messages are printed now,
more code will be added to test and figure it out!)
Thanks to Michael Creech, Fidelity Information Services, Inc, USA.
Change 23.095 Variable PCTCFULL='PCT OF*CACHE*USED' was added to the
VMAC41 TYPE41VF dataset. Variable SMF41FND is clarified in the
Apr 29, 2005 ADOC41 as the number of objects found in cache in this
interval, which is NOT the total number of objects in the
cache (that number does not exist in SMF 41 records).
Thanks to Ulrich Krueger, National Semiconductor Corp., USA.
Change 23.094 The PROC DATASETS for HSMSTAT needed MT=ALL because that
ASUMHSM dataset is a VIEW, and the default MemType=DATA caused a
Apr 29, 2005 warning note.
Thanks to Chris Weston, SAS Institute ITRM Development, USA.
Change 23.093 SMF 74 subtype 8 INPUT STATEMENT EXCEEDED RECORD LENGTH
VMAC74 because I didn't have any test data to catch my typos!
Apr 28, 2005 The INPUT of R748RCNT was missing a period, variables
R748AASP/AAWD/AACP are now PIB1/2/4 instead of RB8, and
variables R748XRCP thru R748XTDY are PIB4. and not RB4.
Thanks to Miguel Francisco Monferrer Carvajal, EDS, SPAIN.
Change 23.092 MXG 23.03 only, and only for ITSV/ITRM. Two hardcoded
VMXG70PR references to "PDB." caused errors with ITSV/ITRM. The
Apr 28, 2005 macro variable "&PTY70PR.." replaced them to correct.
Thanks to Chris Weston, SAS Institute ITRM Development, USA.
Change 23.091 SMF 6 record INPUT STATEMENT EXCEEDED RECORD LENGTH with
VMAC6 a VPS record with the Printway File Transfer segment. The
Apr 28, 2005 Changes 22.309, 22.321 are revised, based on the z/OS 1.6
SMF Manual, which documents both the basic and extended
mode for records created by SUBSYS='TCP', but the values
in SMF6INDC in SUBSYS='VPS' records are 5 and 3 instead
of the 1 or 7 expected, so MXG logic is revised again to
provide special handling for VPS SMF 6 records that have
a file transfer segment. But in one SMF 6 record written
for SUBSYS='PSF', it's file transfer segment does not
agree with either the basic or extended mode TCP segments
or with the PSF segment documentation, so heuristic logic
is added to (hopefully) protect PSF records as well.
Thanks to Udo Frohling, Kommunales Rechenzentrum Niederrhein, GERMANY
Spent week in NYC at The Plaza during its last week as a real hotel, but
our real purpose was to attend the Jammy Awards ceremony at Madison
Square Garden, where our "godson", Keller Williams won one of only nine
Jammy's: Best Live Album, "Stage". See http://www.kellerwilliams.net.
====== Changes thru 23.090 were in MXG 23.03 dated Apr 22, 2005=========
Change 23.090 Executing MXG under ASCII platforms has some differences:
INSTALL -If you use the ftp access method to read your MVS data
IMACFILE directly, you won't have a copy of the SMF data on your
Apr 22, 2005 ASCII system; although most sites back up their SMF data
on MVS, it is possible to backup your SMF data on your
ASCII platform, as you are reading SMF with ftp access.
Writing a 13GB backup file added 20 minutes run time.
See the article "Can you run MXG on a PC' in NEWSLTRS.
Or, if you want to create an SMF file on your ASCII
system that contains selected SMF data, the below example
shows how you can use the "IMACFILE" exit to create an
SMF VBS file on your ASCII system.
-The _NULL_ data step creates macro variable, &DATETXT,
with the date and time as a text string, which is then
used to create the name of the "backup" SMF VBS file.
-The "instream" tailoring statement %LET MACFILE= adds
the code inside the %QUOTE() function (required because
there semi-colons in the code that would otherwise have
terminated the %LET statement) to the exit that is taken
after the SMF header has been read.
If you want to select SMF records, you would add an
IF ... THEN DO; statement after the %QUOTE( and would
add an END; statement before the ) that ends %QUOTE.
The SMF header variables ID SMFTIME SYSTEM and SUBTYPE
are available for selection, although some records with
subtypes don't put their subtype in the SMF header.
-Example to read SMF via FTP and create a local SMFBKUP
file of the input SMF records:
The example shows how to concatenate multiple SMF files:
//SYSIN DD *
DATA _NULL_;
DATE=TODAY();
TIME=TIME();
DATETXT='D'!!PUT(DATE,YYMMDD10.)!!'-'!!'T'!!
PUT(HOUR(TIME),Z2.)!!'-'!!
PUT(MINUTE(TIME),Z2.);
CALL SYMPUT('DATETXT',DATETXT);
RUN;
FILENAME SMF FTP ("'SYS1.SMF'" "'SYS2.SMF'" ... )
USER='XXXXXX' HOST='YYYYYYY'
S370VS RCMD='SITE RDW' LRECL=32760
PASS='XXXXXXXX';
FILENAME SMFBKUP "C:\MXG\SMFDATA\&DATETXT" ;
%LET MACFILE=
%QUOTE(
RDW=LENGTH+4;
BDW=RDW+4;
FILE SMFBKUP RECFM=N LRECL=32760;
PUT BDW &PIB.2. '0000'X RDW &PIB.2. '0000'X
_INFILE_ @;
);
RUN;
%INCLUDE SOURCLIB(BUILDPDB);
RUN;
The backup file name c:\mxg\smfdata\D2005-04-19-T04-20
contains the date and time of creation of the file. The
backup file is slightly larger than the input file
(325,498,825 versus 325,484,807, or +14,018 bytes)
because each VBS record creates a separate block. And,
the FILE with RECFM=N option does print the output file
name on the SAS log, there is not message that any data
was written. SAS Technical Support says that is because
RECFM=N doesn't write records that none are counted, but
a suggestion to provide byte count has been made, so that
you will know if the file was actually written to.
-Comments with this example were added to IMACFILE and to
member INSTALL, but no there was no change to MXG code.
-Example to read SMF via FTP and select a subset of SMF
records to be created on the ASCII platform;
The example shows how to concatenate multiple SMF files:
//SYSIN DD *
DATA _NULL_;
DATE=TODAY();
TIME=TIME();
DATETXT='D'!!PUT(DATE,YYMMDD10.)!!'-'!!'T'!!
PUT(HOUR(TIME),Z2.)!!'-'!!
PUT(MINUTE(TIME),Z2.);
CALL SYMPUT('DATETXT',DATETXT);
RUN;
FILENAME SMF FTP ("'SYS1.SMF'" "'SYS2.SMF'" ... )
USER='XXXXXX' HOST='YYYYYYY'
S370VS RCMD='SITE RDW' LRECL=32760
PASS='XXXXXXXX';
FILENAME SMFBKUP "C:\MXG\SMFDATA\&DATETXT" ;
%LET MACFILE=
%QUOTE(
IF ID IN (70,72);
RDW=LENGTH+4;
BDW=RDW+4;
FILE SMFBKUP RECFM=N LRECL=32760;
PUT BDW &PIB.2. '0000'X RDW &PIB.2. '0000'X
_INFILE_ @;
);
RUN;
%INCLUDE SOURCLIB(VMACSMF);
DATA _NULL_;
_SMF;
RUN;
Thanks to Michael Gebbia, Eddie Bauer, USA.
Thanks to Glenn Bowman, Wakefern, USA.
Change 23.089 Variable DCVDVNUM, the Device Number, is retained from
VMACDCOL the DCOLVOLS record and kept in the DCOLDSET dataset;
Apr 21, 2005 this is possible because the DCOLLECT output is ordered
with the DCOLVOLS record before the DCOLDSETs on that
volume.
Thanks to Frank Lund, EDB IT Drift, NORWAY.
Change 23.088 -Variables EV40FLG1 EV40FLG2 and CATGNAME from RACFTYPE=40
EXTY8066 were incorrectly kept in TYPE8007 dataset and were not
IMAC80A kept in TYPE8008 dataset, now they are correct.
VMAC80A -Variables FROMRESN (13), VOLUME FVOLUME (14) and CLAS26NM
VMXGINIT (from RACFTYPE/DTP=26) are kept in TYPE8019.
Apr 23, 2005 -FROMVOLS in RACFTYPE=6 for RACFEVNT=8 is an 8-byte field,
Apr 27, 2005 but MXG only input 6 bytes, shifting SECLEVEL/SECLABEL.
May 12, 2005 Now, FROMVOLS is input as $EBCDIC8 and the "undocumented"
May 17, 2005 +2 bytes are removed from that INPUT statement.
May 29, 2005 -Variables KW09IG06 ande KW09SP06, UNIVERSAL, added to
May 30, 2005 dataset TYPE8009
-Variables SECLEVEL,SECLABEL,KW11SP28-29,KW11IG28-29
added to TYPE8011.
-Variables CLASSP02,04,05,06 added to TYPE8010,TYPE8013.
-Variable KW19CL07 added to TYPE8019.
-Variables KW19FC00-KW19FC07 replace 00-04, which were
incorrectly decoded.
-Variables KW24S102-S109 added, decoded from KW24RSV1.
-Variables KW25VI00-VI01 added, decoded from KW24OVIO.
-Variables KW59ST00-ST06 added, decoded from KW24STAT.
-Dataset TYPE8066 created for RACDCERT command; however,
only the standard RACF variables are output in this
iteration - time ran out for 23.02 QA, but this record
will be fully decoded in the next iteration.
-Variable LOGSTR change length to 200 from 64, but not
until May 12!
-Additional variables, thru KW24S132, KW24I117, KW24KERB
are decoded, May 17.
-ACEEUSER variable now kept in TYPE8024.
-Second (290) should have been (291).
-KW24SP46/KW24SP47/KW24IG46/KW24IG47 are corrected.
-KW11xx13 and later were incorrectly aligned with th4eir
bits and labels, and KW11xx28 and KW11xx29 should not
have been created for ALTDSD event.
-KW10ER00-KW10ER31 are now decoded and kept in both the
TYPE8010 and TYPE8013 datasets; all three of the sets
of bit maps KW10ERnn, KW10IGnn, and KW10SPnn are the same
for ADDUSER (10) and ALTUSER (13), except that some bits
that can be enabled for ADDUSER won't be for ALTUSER.
Thanks to Bill Arrowsmith, Euroclear, BELGIUM.
Thanks to Andrew Davis, Euroclear, BELGIUM.
Thanks to Aimee Steel, Euroclear, BELGIUM.
Change 23.087 -If USERADD= contained two references (SYNC/208 SYNC/214)
UTILBLDP with different SMF IDs, UTILBLDP generated incorrect code
VMXGINIT but now it will use only the first reference.
BUILDPDB -EXPDBOUT=%INCLUDE SOURCLIB(ASUMPRTR); used in Example 7,
BUILDPD3 failed. Unfortunately, because of macro timing issues,
BUILD001 the only way UTILBLDP can create a %INCLUDE statement
BUIL3001 for EXPDBOUT= required a new macro variable, &BLDPOUT,
Apr 21, 2005 to be defined in VMXGINIT and inserted in the BUILxxxx
members where _EPDBOUT is invoked.
Thanks to Robert Chavez, OfficeDepot, USA.
Change 23.086 DB2STATS variable QDSTNQR2 should not have been DIF()'d.
VMACDB2 Variable QDSTQDBT should have been, and now is DIF()'d
Apr 21, 2005 as it contains accumulated values.
Thanks to Fred Nijdam, Rabobank, THE NETHERLANDS.
Change 23.085 Dataset ICEBRGCH old variables ENDTIME,STARTIME were not
VMACICE adjusted in VMXGTIME macros, old variable CHANSPED is now
Apr 19, 2005 converted to bytes and FORMATed MGBYTRT as it is channel
speed in Bytes per second, and new PCHANBY variable is
created. When ICEBERGs are shared across systems, you
must choose data from only one system, since each system
creates a replicated SMF record for each interval.
Thanks to Chuck Hopf, MBNA, USA.
Change 23.084 The UTILEXCL utility now has "standard" MXG macro tokens
EXCICDIC _VCICDIC/_WCICDIC/_PCICDIC/etc instead of hard-coded name
IMACICD8 for the CICSDICT dataset.
UTILEXCL -Optional CANVRSN field is now supported in IMACICD8.
VMXGINIT
Apr 19, 2005
Thanks to Michael Oujesky, MBNA, USA.
Change 23.083 -Variable NRCPUD, the number of CPU segments in "this" MVS
VMAC7072 SMF 70 record is now kept in datasets TYPE70 and TYPE70PR
Apr 18, 2005 as it describes the maximum engines this system could use
perhaps as an upper bound on engines under IRD control.
-The IFAWAITM and IFAWAIT0-IFAWAITX IFA*WAIT*DURATION
variables have been reinstated in TYPE70 dataset, as it
turns out they are useful in IFA analysis.
Thanks to Art Cuneo, Health Care Service Corporation, USA.
Thanks to Don Deese, (CPExpert), Computer Management Sciences, USA.
Change 23.082 ***ERROR. QWHSLOCN CONTAINS UNICODE TEXT message printed
VMACDB2H with DB2 V8 record, so that I could see what IBM stored
Apr 18, 2005 in QWHSLOCN when QWHSFLAG='80'X. Now, with this first
instance of QWHSFLAG on, I can see that the text value
in QWHSLOCN is simple ASCII data, so MXG's INPUT of the
QWHSLOCN is now revised to INPUT either EBCDIC or ASCII
based on QWHSFLAG. The IBM documentation for QWHSFLAG in
the DSECT is "%U fields contain Unicode UTF-8)", which I
assumed meant that QWHSLOCN would contain UNICODE data
(i.e., 2-byte, DBCS text), but I've now googled UTF-8 and
find that UTF-8 is an ASCII-preserving encoding method,
so the INPUT with $ASCII16. is all that is needed!
With the ERROR message, the only error is that the value
in QWHSLOCN, Local Location Name, was trashed.
Thanks to Ian Arnette, Toronto Dominion Bank, CANADA.
Thanks to ??? , Toronto Dominion Bank, CANADA.
Change 23.081 Changes in WLM Service Policy can be tracked by TYPE9024,
VMAC90A now that the new policy name is input as SVPOLNSP from
Apr 17, 2005 the IWMVSPOL DSECT.
Thanks to Chuck Hopf, MBNA, USA.
Change 23.080 Support for RMF III IFA data added by z/OS 1.6. New data
VMACRMFV was added to ZRBASI and ZRBENC datasets. No change was
Apr 17, 2005 required to the ASMRMFV program, which automatically sees
and writes out the longer records.
Thanks to Jerry Urbaniak, Acxiom CDC, USA.
Thanks to Robert Vance, Zurich Insurance Company, USA.
Change 23.079 INVALID DATA FOR MM in NDM NDMRTYPE='SS' SMF record. MXG
VMACNDM input two bytes that should have been substringed from
Apr 14, 2005 NDMSID0, which also should have been INPUT as $CHAR8 and
formatted $HEX16 because it can have hex and character
data.
Thanks to Bernie Mazur, Bank of Montreal, CANADA.
Change 23.078 The path activity report is enhanced to report the CMR
ANALPATH (which can be significant for FICON channels) and the OTH
Apr 14, 2005 pend time in separate columns on the report.
Thanks to Tony P. Steward, CSC, ENGLAND.
Change 23.077 ***ERROR.TYPE110.SUBTYPE 2. CICS STAT RECORD STID=106.
VMAC110 MXG missed an 8-byte reserved field before PIWPGMNM, and
Apr 13, 2005 incorrectly only "skipped" 1160 bytes of the 1168 STILEN.
Apr 15, 2005 The last three variables, PIWPGMNM, PIWCONNM, PIWUSECT in
dataset CICPIW were wrong.
Thanks to Roland Schiradin, Alte-Leipziger, GERMANY.
Thanks to Lambros Theodorides, Alte-Leipziger, GERMANY.
Change 23.076 Invalid Package Data detected. The pseudo SMF 101 record
TYPSTHST created by BMC's DB2 THRDHIST file contain a standard
Apr 12, 2005 triplet for the first 10 packages, like an IBM IFCID 0003
record, but then, additional segments are written to the
end of the 32752 byte record. Unfortunately, there is
only room for 69/70 segments. Instead of writing a valid
IFCID 289 record with additional segments, THRDHIST puts
part of the next segment, as many bytes as fit, to fill
the records (splitting in the middle of a field!), and
then creates a new record, without header, with the rest
of that segment, followed by the remaining packages.
This is an invalid architecture, to split fields across
physical records. Until BMC redesigns its file, the best
MXG can do is to process those 69 or 70 segments that are
complete, and report with a message to the SAS log that
additional package segments existed but could not be
processed. (Prior to this change, MXG tested the triplet
to ensure MXG did not read beyond the end of the record,
but when the product of number of segments times their
length exceeded the record size, all packages were just
skipped, without an error message).
Thanks to Bernd Rueckrich, R & V Versicherung AG, GERMANY
Change 23.075 -UTILEXCL. Optional CMODNAME='RMI',CMODHEAD='DB2CLOCK'
UTILEXCL did not generate an UNKNOWN FIELD SKIPPED message, and
IMACICUS did not skip that field in the created IMACEXCL code.
Apr 11, 2005 The MXG code for a CMODNAME='RMI', with multiple fields,
decoded in IMACICRM was revised to recognize this new
RMI variant (which is not to be confused with yet
another RMI-containing segment with CMODNAME='DFHRMI'
that is supported in IMACICRD!
-IMACICUS. Cosmetic; comments were clarified.
Thanks to Christen Ole Christiansen, IBM, DENMARK.
Change 23.074 This Analysis of FICON Open Exchanges is based on work by
ANALFIOE Dr. Pat Artis that was documented in Change 21.087. He
Apr 11, 2005 has revised his calculation, slightly, by inclusion of
the new DLYCMRTM, the Command Response Time, which is a
subset of PEND time that occurs after the channel has
selected the I/O for processing, in his note "Managing
Complex FICON Configurations." DLRCMRTM is added to the
calculation by this change.
Thanks to Scott Barry, SBBWorks, USA.
Thanks to Mike Crowder, Humana, USA.
Change 23.073 Variable MODEL, taken from DEVMODEL, is a numeric value
ASUMCACH that is added to the BY list in TRNDCACH to provide more
TRNDCACH granularity in the summarization. All values of MODEL
Apr 10, 2005 are numeric (3390 33903 33909), but this revision will
need revision if a non-numeric DEVMODEL is ever created.
Thanks to Diane Eppestine, SBC, USA.
Change 23.072 Support for APAR OA09921 for IBM TotalStorage DS6000 adds
VMAC78 the Preferred Pathing Function, with these new variables
VMAC79 in type 78 subtype 3 records:
Apr 10, 2005 -TYPE78CF - R783CPAT - PATH*ATTRIBUTES
-TYPE78CU - LCUDST - DATA STATUS BITS
-TYPE78IO - R783CSS - CHANNEL SUBSYSTEM ID.
and in type 79 subtype 14 records
-TYPE79E - R79ECPAT - PATH ATTRIBUTESS
-TYPE79E - LCUDST - DATA STATUS BITS
Change 23.071 Enhanced IFA summarization in PDB.RMFINTRV, PDB.ASUM70PR,
VMXGRMFI PDB.ASUM70LP, and PDB.ASUMCEC. However, you have to be
VMXG70PR careful in understanding how IFAs are reported; they are
VMXGDUR much like CPs when they are shared across LPARs:
Apr 16, 2005 - "System-level" datasets (RMFINTRV/ASUM70PR/ASUM70LP)
can NOT provide accurate utilization of shared IFAs.
If you have 4 shared IFAs and two MVS systems, these
system obs do have the IFAACTTM (IFA CPU time) used by
that SYSTEM/LPAR, but each obs will also show there
were 4 IFAs, so any percent-used calculation will be
only this system's part of the utilization of all four
installed shared IFAs.
- "CEC/CPC-level" dataset PDB.ASUMCEC does correctly sum
the IFAACTTM across all systems running on that CECSER,
and the PCTIFABY in PDB.ASUMCEC is the correct percent
utilization of all four IFAs by both LPARs.
-VMXGDUR was enhanced with operands for interval values of
10-minute and 5-minute.
Thanks to Scott Weiner, WPS Insurance Corporation, USA.
Change 23.070 IBM cannot guarantee that RMF STARTIME values will be the
VSETZERO exact-on-the-minute value that you thought you'd get when
VMAC7072 SYNC(SMF) is specified in ERBRMFxx member of parmlib:
VMAC71 "When RMF Monitor I runs with SYNC(SMF) option, RMF
VMAC73 will be triggered by SMF via ENF37 at the end of the
VMAC74 SMF interval. SMF sends this ENF37 signal shortly
VMAC75 before the interval end, and RMF starts its interval
VMAC76 processing after receiving that signal. During this
VMAC77 interval processing, RMF sets the interval start time
VMAC78 for the next interval in the SMFxxIST field, and you
VMAC79 must expect some deviation in SMFxxIST time values;
VMACCMF since SMF ENF37 is sent shortly before the interval
VMACEPMV end, SMFxxIST times can also be earlier than the end.
Apr 10, 2005 If you use SMFxxIST field data, which only have one
second granularity, you must plan to tolerate small
deviations in SMFxxIST times."
per Peter Muench, IBM RMF Development, Germany.
IBM's SMFxxIST is the STARTIME variable in MXG RMF data.
Data with STARTIME at :59 seconds instead of :00 caused
the HOUR of the STARTIME to be one hour early, so with
IBM's note that STARTIME cannot be guaranteed to be the
expected exact minute, it is now up to MXG to detect and
correct STARTIME in your RMF datasets.
-New VSETZERO member is %INCLUDEd in all RMF-processing
code members to detect that seconds of STARTIME were
58, 59, or 01, and it resets the STARTIME to the exact
correct hour:minute:00 value.
-Note that it is still possible to have STARTIME values
that are not exact minutes; for example, the value in
Change 23.069 of 19:59:40 would not be changed.
Thanks to Wolfbang Vierling, Allianz, GERMANY.
Thanks to Bernd Tekath, Allianz, GERMANY.
Change 23.069 -RMF Interval less than one minute caused incorrect data
VMXG70PR in PDB.ASUMCEC, because MXG logic recalculated STARTIME
Apr 9, 2005 (only for PDB.ASUMCEC) to the nearest exact minute value.
The STARTIME was 19:59:40 and DURATM was 19 seconds, due
to a WLM Policy Reset just before 20:00:00, with a normal
15 minute interval with STARTIME of 20:00:00, but the obs
in PDB.ASUMCEC had STARTIME of 20:00 with DURATM=19 secs,
and all the calculated PCTxxxxx values were all wrong.
This change removed the code in VMXG70PR that modified
STARTIME for PDB.ASUMCEC, which corrected the error due
to the short interval data, but ONLY because all of the
SYSTEMS on this CEC had identical short intervals, and
because MXG default _DURSET in IMACRMFI was in effect,
causing each original STARTIME value was to be output
(i.e., no summarization to a new INTERVAL was requested).
The result was that there were two observations created
in PDB.ASUMCEC, one with its STARTIME of 19:59:40 and
DURATM of 19 seconds, and one at STARTIME of 20:00:00
with DURATM of 15 minutes, and each was valid, because
all of the SYSTEMs had the same short interval data.
-But if you want PDB.ASUMCEC summarized so that only one
observation is created at the "expected" 15-minute DURATM
then you must tailor the IMACRMFI member to set STARTIME
to the 15 minute time, and then that short interval will
be summed into a 19:45 STARTIME with DURATM of 15 min.
-BUT PDB.ASUMCEC WILL ALWAYS BE WRONG IF YOU HAVE SYSTEMS
ON THE SAME CEC WITH DIFFERENT DURATM VALUES, IF ANY OF
THOSE DURATMs ARE GREATER THAN THE IMACRMFI INTERVAL YOU
REQUESTED. For example, if systems have 15 minute and
hourly RMF data on the SAME CEC, PDB.ASUMCEC dataset has
an observation on the hour with DURATM of 60 minutes, but
there will also be hour:15, hour:30, and hour:45 STARTIME
observations with DURATM of 15 minutes, and all of that
data in PDB.ASUMCEC is likely wrong. Only if you set the
IMACRMFI summarization to hourly can MXG create a valid
PDB.ASUMCEC dataset from that kind of mixed DURATM data.
-Note that it is ONLY the PDB.ASUMCEC dataset that had any
problems; whether you have short DURATM or mixed DURATMs,
the PDB.ASUM70PR and PDB.ASUM70LP datasets were always
correct, since they are summarized by SYSPLEX SYSTEM.
Nov 10: Not True. See Change 23.289 which is needed.
-The IMACRMFI default tailoring sets the interval for the
PDB.RMFINTRV, PDB.ASUM70PR, PDB.ASUM70LP, and PDB.ASUMCEC
datasets, but that can be overridden if you have tailored
either the ASUM70PR member or the RMFINTRV member to use
their INTERVAL= arugment, instead of changing IMACRMFI.
Setting the INTERVAL= or IMACRMFI work equally well.
-Change 21.315 reset the STARTIME in VMXG70PR for ASUMCEC,
but the Change 23.070 enhancements eliminates both that
need and this exposure, so that code was safely removed
Thanks to Diane Eppestine, SBC, USA.
Change 23.068 BUILDPD3 now sets Condition/Return Code of zero under V9!
VMAC26J3 MXG Change 22.365 fixed the problem for JES2 BUILDPDB and
Apr 9, 2005 this revision fixes the problem for JES3. Two changes
were needed; JOBCLASS is now input as J3CLSONE as $1 and
then stored into JOBCLASS, and the initial reference to
ACCOUNT1 was relocated after the include of IMACACCT so
the length would be set by your IMACACCT tailoring. An
extremely-rare-in-MXG GOTO was used to preserve the flow
of execution.
Nov 3: This did not work as expected and caused zero
observations in TYPE26J3; corrected in Change 23.282,
added in MXG 23.09.
Thanks to Diane Eppestine, SBC, USA.
Change 23.067 Cosmetic. MXG 23.02 only. The four listed members will
VGETDDS cause this MXGERROR: message to be printed on the log:
VGETDDS VGETxxxx IS BACK-LEVEL AT 23.01, WHICH IS EARLIER
VGETDSN THAN THE EXECUTING MXG VERSION OF 23.02....
VGETENG Disregard for those members; they were not updated when
VGETSORT MXG 23.02 was created.
Apr 9, 2005 -Also, the message text now prints MXGWARN: vice ERROR.
Change 23.066 Support for RACF Events 27, 28, and 29 for unix
EXTY8028 dddddd Dataset Description
EXTY8029 TY8028 TYPE8028 RACF EVT 28 DIRECTORY SEARCH
EXTY8030 TY8029 TYPE8029 RACF EVT 29 CHECK ACCESS TO DIR
VMAC80A TY8030 TYPE8030 RACF EVT 30 CHECK ACCESS TO FILE
VMXGINIT
Apr 9, 2005
Thanks to Peter Schubert, CITEC, AUSTRALIA
Change 23.065 -Variable EXPCTSRD in dataset VXSTOASP was not
VMACVMXA deaccumulated, but now it is.
Apr 8, 2005 -Variable TCMMIDSZ was changed to bytes by 20.04, but
Apr 10, 2005 its label still had PAGES instead of BYTES.
-Variables PFXSPINC and PFXSPINT were incorrect because
their deaccumulation assumed descending order, but these
two variables are accumulated in ascending order.
Thanks to Fabio Massimo Ottaviani, DTS Italia, ITALY.
Thanks to Brian Crow, BT, ENGLAND.
Change 23.064 Dataset TYPE78SP, Virtual Storage Subpool for monitored
VMAC78 jobs, only contained subpool information below the 16MB
Apr 8, 2005 line (because I thought a subpool was either above or
below when I wrote that code years ago!). Now, variables
SUBPOOL5-SUBPOOL9 are created, and they will be populated
if the subpool for this job allocated above-16MB-space.
-The storage variables were not in a LENGTH .. &MXGBYLN
statement, so their stored length was the MXG default of
4 bytes, which could have caused small truncation if the
value was large (e.g., 999M instead of 1G). They all now
have the correct length set in a LENGTH statement.
Thanks to Don Deese, (CPExpert), Computer Management Sciences, USA.
Change 23.063 Cosmetic. Label is now ACTRELAP='ELAPSED*TIME'. Label
VMACENTX for prior variable had been copied incorrectly.
Apr 5, 2005
Thanks to Chris Taylor, GMAC Insurance, USA.
Change 23.062 Variables SRMWSSDL, SRMWSSD1, SRMWSSD2, SRMWSSD3 in
VMACVMXA VXSYTSCG are working set sizes, but were still in pages,
Apr 5, 2005 which is inconsistent with other z/VM working set size
variables, so they are now converted to bytes and
formatted MGBYTES.
Thanks to Kris Ferrier, State of Washington DIS, USA.
====== Changes thru 23.061 were in MXG 23.02 dated Apr 4, 2005=========
Change 23.061 The SEQENGINE=V9SEQ is now set in CONFIGV9 for z/OS. You
CONFIGV9 must be at SAS V9.1.3, or you must have HotFix SN-012437
Apr 3, 2005 if you are using SAS V9.1 or V9.1.2, but almost everyone
is now installing V9.1.3, so I deem it safer to use V9SEQ
now. The problem is that using V6SEQ does not work when
character variables are greater than 200 bytes, and there
are many new variables that need to be 255 or greater;
clinging to V6SEQ because you've not installed a Hot Fix
is not fair to all the smarties that are using V9.1.3.
If you've not installed that Hot Fix and are still using
V9.1/V9.1.2, then you MUST change the V9SEQ in CONFIGV9
back to V6SEQ (you cannot use V8SEQ with SAS Version 9).
If you want all the historic details of which sequential
engine did what, you can search CHANGESS and NEWSLTRS
members for V9SEQ for the litany of iterations on what
works and what doesn't work.
(While we can tell that you are at 9.1.3, for sites
still back on 9.1/9.1.2 we cannot tell if you have
the hot fix installed.)
Change 23.060 Support for z/VM 5.1 enhanced; all new data supported.
ADOCVMXA -Nine new "standard" MONWRITE datasets are created:
EOAPLCMS Domain Record dddddd Dataset Description
EOAPLTC0 1 18 MTRCCC VXMTRCCC CPU Capability Change
EOAPLTC1 2 11 SCLIOP VXSCLIOP I/O Priority Changes
EOAPLTC2 5 8 PRCIOP VXPRCIOP IOP Utilization
EOAPLTC3 6 21 IODVSW VXIODVSW Virtual Switch Activity
EOAPLTC4 6 22 IODVSF VXIODVSF Virtual Switch Failover
EOAPLTC5 6 23 IODVSR VXIODVSR Virtual Switch Recovery
EOAPLTC6 6 24 IODSZI VXIODSZI SCSI Device Activity
EOAPLTC7 6 25 IODQDA VXIODQDA Activate QDIO Device
EOAPLTC8 6 27 IODQDD VXIODQDD Deactivate QDIO Device
EOAPLTC9 -Eight existing MONWRITE datasets have new variables:
EOAPLTCA Domain Record dddddd Dataset
EOAPLTCB 0 8 SYTUSR VXSYTUSS
EOAPLTCC 2 4 SCLADL VXSCLADL
EOAPLTCC 2 5 SCLDDL VXSCLDDL
EOAPLTCD 2 6 SCLAEL VXSCLAEL
3 12 STOASC VXSTOASC
EOAPLVMR 4 1 USELON VXUSELON
EXAPLSL0 4 9 USEATE VXUSEATE
EXAPLSLM 4 10 USEITE VXUSEITE
EXAPLSLN 6 26 IODQDS VXIODQDS
EXAPLSLP -Domain 10 (Application Server) logic was revised; the
EXIODQDD separate decoding of Sample and Event data under two
EXMTRCCC separate internal macro pairs (_VAPLSDT,_CAPLSDT) and
EXPRCIOP (_VAPLEDT,_CAPLEDT) was replaced with a single internal
EXSCLIOP pair (_VAPLAPL,_CAPLAPL) because "Configuration Class"
FORMATS data for TCP/IP can be either Sample or Event, or both.
IMACVMXA -These new datasets are created from domain 10 records:
VMACVMXA Source: CMS APPLDATA MDGPROD=5684030MT1020100
VMXGINIT MXG Dataset VXAPLCMS 'CMS Multitasking'
Apr 3, 2005 Source: TCP/IP MDGPROD=5735FALSTx0ttt00
Multiple MXG datasets are created, based on the
hex value "x" in MGDPROD:
x Dataset Description
00 VXAPLTC0 TCP/IP MIB Record
01 VXAPLTC1 TCP/IP TCB OPEN Record
02 VXAPLTC2 TCP/IP TCB CLOSE Record
03 VXAPLTC3 TCP/IP Pool Limit Configuration
03 VXAPLTCX TCP/IP Pool Data
04 VXAPLTC4 TCP/IP Pool Size
05 VXAPLTC5 TCP/IP LCB Link
06 VXAPLTC6 TCP/IP UCB OPEN
07 VXAPLTC7 TCP/IP UCB CLOSE
08 VXAPLTC8 TCP/IP Link Definition
09 VXAPLTC9 TCP/IP ACB
0A VXAPLTCA TCP/IP CPU
0B VXAPLTCB TCP/IP CCB
0C VXAPLTCC TCP/IP Tree Size
0D VXAPLTCD TCP/IP Home
0E VXAPLTCE TCP/IP IPv6 Home
Source: VMRM MDGPROD=5739A03RM0000000
MXG Dataset VXAPLVMR 'VMRM Workloads'
Most of these new datasets have been tested with data,
but some of the de-accumulation may be incomplete, as I
only have a few observations in some of the TCP/IP data.
If you want to use the new data, especially TCP/IP stuff,
please contact support@mxg.com to send your MONWRITE data
so we can investigate these new metrics together.
-ADOCVMXA notes were revised; Richard Steele's paper from
1988 was changed into plain text, without control chars,
and moved to the top of the member, and IBM Manuals that
show you how to set up the MONWRITE Virtual Machine and
its Saved Segment are now references to make it easier
to enable and gather the MONWRITE data from z/VM.
Change 23.059 -z/VM format MGVXCMG had wrong values for CSCCMCMG, the VM
FORMATS Channel Measurement Group, which should have been values
Mar 31, 2005 1-ESCON, 2-FICON, 3-HiperSockets for z/VM, like z/OS.
Thanks to Fabio Massimo Ottaviani, DTS Italia, ITALY.
Change 23.058 Cosmetic. Comments referencing Change 22.050 should have
VMACHMF been 20.018, and Change 22.162 should have been 22.168.
Mar 31, 2005
Thanks to Larry Stahl, IBM Global Services, USA.
Change 23.057 UTILBLDP enhancements. The USERADD= xxxx text required
UTILBLDP you to list the "product suffix" xxxx value (e.g., 7072)
Mar 30, 2005 but if you only listed part of the suffix (USERADD=70),
incorrect code was generated and you got errors. Now,
the USERADD= argument can either be the product suffix,
or an SMF record number processed by that product. And,
if you should list duplicate entries (USERADD=7072 72,)
UTILBLDP is now smart enough to remove the duplicates.
Thanks to Jake M. Drew, MBNA, USA.
Change 23.056 DB2 Trace dataset T102S199 was incorrect; it contained
VMAC102 only the first segment, and the DBID/OBID were formatted
Mar 30, 2005 only as $HEX2 when they should have been $HEX4.
Thanks to Karthik Vinayagam, Morgan Stanley, USA.
Change 23.055 Variable DSEXCP: the label should have been EXCP*COUNT*
VMACCTLT SINCE*CREATED, rather than USE*COUNT*SINCE*CREATED.
Mar 30, 2005
Thanks to Stephen Hahne, Capital One Financial Services, USA.
Change 23.054 All z/VM variables that had "SLOTS" in their label are
VMACVMXA now corrected to contain "BYTES" in their labels, as all
Mar 30, 2005 of the variables had already been converted from a count
of 'slots' to the count of 'bytes'. These variables also
had been correctly formatted with MGBYTES format; it was
only their label that was incorrect.
Thanks to Kris Ferrier, State of Washington DIS, USA.
Change 23.053 Variables TTETIME, TTSTIME, and TITIME are now all on the
VMAC119 Local time zone, and their labels all have "GMT" removed.
Mar 25, 2005 TTETIME and TITIME were converted to local but had wrong
label, and TTSTIME was not coverted from GMT to local.
Thanks to Victor Chacon, Verizon Wireless, USA.
Thanks to Alan Klein, Verizon Wireless, USA
Change 23.052 -z/VM MONWRITE POSSIBLE BAD CONTROL RECORD were because
EOAPLSL0 the 1.17 record test should be SKIP=SKIP-16; instead of
EOAPLSLM SKIP-52. This caused many of the domain 1 records to be
EOAPLSLN skipped and were not output. Fortunately, these are the
EOAPLSLP seldom-needed startup information for MONWRITE, and the
EOdddddd 1.17 record is after all of the critical-to-MXG records.
VMACVMXA -The 1.19 record would have been skipped, as its test for
Mar 25, 2005 MRHDRRC should have been for 19 instead of 17.
-MXG architecture enhancement creates new EOdddddd members
and for "second Output" of a dataset, and defines new
macro tokens named _Odddddd for instream override of the
exit. This "second Output" exit is needed when raw data
is accumulated, so filtering of observations can't be
done during the "first Output" in the DATA step, but only
after the deaccumulation is available for creation of an
interval "usage" variable, USdddddd that is tested in the
new second Output EOdddddd exit member, so only intervals
with activity are output during the final pass of data:
-The EOdddddd member now tests to not output "nulls":
USdddddd=SUM(resources);
IF USdddddd GT 0 THEN DO;
OUTPUT _Ldddddd;
END;
-The MACRO _Odddddd %%INCLUDE SOURCLIB(EOdddddd); %
is defined in VMACxxxx, adjacent to the _Edddddd.
-The _Sdddddd macro sets contain:
IF DELTATM GT 0 THEN DO;
_Odddddd;
END;
Dataset updated thus far to only output active intervals:
Dataset - USdddddd Usage Activity Variable(s)
VXAPLSLP - TICKS (sum of all clock's ticks)
VXAPLSL0 - TICKS (sum of all clock's ticks)
VXAPLSLM - PGALLOC
VXAPLSLN - SUM(PKTSRCVD,PKTSSEND)
-Example in IHDRVMXA shows how you can skip domains and/or
records from being output, when you want to select which
datasets are created from MONWRITE data.
Some DATA step times reading 1024MB MONWRITE:
Elapsed CPU WORK MB Description
641 87 1382 Output ALL
589 61 902 Skip Domain 7 (SEEK)
413 20 20 Only Domain 10 (APPL SERVER)
321 18 0 No Output, READ ALL,DDecode Hdr
Change 23.051 Support for z/VM Linux Application Server data creates
EXAPLSLM four new datasets:
EXAPLSLN APLSLM VXAPLSLM LINUX MEMORY
EXAPLSLP APLSLP VXAPLSLP LINUX PROCESSOR SUMMARY
EXAPLSL0 APLSL0 VXAPLSL0 LINUX EACH CPU DETAIL
VMACVMXA APLSLN VXAPLSLN LINUX NETWORKING
VMXGINIT This support is preliminary, and is in process of being
Mar 16, 2005 validated - the clock tick duration value for Linux times
Mar 24, 2005 is not provided, so actual CPU time is not yet measured
in the VXAPLSLP/SL0 Processor records, and the Linux time
stamp is 18 to 20 seconds earlier than the start of the
MONWRITE interval; both issues are to be opened with IBM.
Thanks to Mike Reeves, Fidelity Systems, USA.
Thanks to Warren Cravey, Fidelity Systems, USA.
Thanks to Rachel Holt, Fidelity Systems, USA.
====== Changes thru 23.050 were in MXG 23.01 dated Mar 15, 2005=========
Change 23.050 z/VM MONWRITE dataset VXBYUSR didn't accurately recognize
VMACVMXA a new LOGON after the same VMDUSER had logged of, causing
Mar 11, 2005 incorrect DELTATM and CPU times for the first interval of
each LOGON in the MONWRITE file. The logic now tests for
a change in CALTODON to recognize each LOGON interval.
Thanks to Mike Salyer, CitiGroup, USA.
Change 23.049 MQ-Series Variable QWHCCV is renamed to QWHCCVMQ because
VMAC116 it conflicted with DB2 variable QWHCCV, and when MQ was
Mar 10, 2005 added to BUILDPDB, the MQ $HEX24. format on QWHCCV made
the DB2 QWHCCV jibberish.
You can make the DB2 QWHCCV print correctly simply
by adding FORMAT QWHCCV $12.; to your DB2 reports.
At the same time, variable QWHSSSID in MQ-Series is now
renamed to QWHSIDMQ and labeled 'MQ*SUBSYSTEM*NAME' so
that it wont override the DB2 QWHSSSID label.
Yes, I know that changing variable names may cause your
MQ Reports to fail, but since only bleeding-edge sites
have begun to use the MQ data, changing now is better
than changing later.
Thanks to Mike Gebbia, Eddie Bauer, USA.
Change 23.048 Amdahl CPUTYPE='2000'X does not populate SMF70ONT, z/OS
VMAC7072 up time of each engine, so for intervals when engines are
Mar 10, 2005 varied on or off line, MXG cannot accurately calculate
the true capacity, since it doesn't know how much of the
interval that varied engine was available. The result is
that NRCPUS counted 2 engines, but part of a third engine
was available, and the CPU time in RMF 72 Service Class
records slightly exceeded the CPUACTTM of those two CPUs.
This was detected ONLY by a NEGATIVE CPU UNCAPTURED TIME
warning from RMFINTRV, which compares the 70 and 72 CPU
times, and there is no cure for the Amdahl deficiency,
so this part of this change is only documentation of the
expected existence of that message with this processor.
(In TYPE70 for this interval, variable CAI3='03'x shows
the third engine was varied, so you can confirm the cause
of the warning message, but I can't use that information
to delete the interval without creating more questions!).
-In addition, this same interval record also caused error
DIVIDE BY ZERO; the unexpected SMF70ONT=0 value caused
PCTCPUBY to be zero when the new SHORTCPS variable was
created (the PCTCPUBY for this record is recalculated
later), but the real cause of the DIVIDE BY ZERO ERROR
was, as always, a programmer's error in not correctly
testing the divisor. IF PCTCPUBY GT . AND PCTMVSBY GT .
is now revised to test both variables for GT zero.
Historic Note: When I was using Netscape years ago,
and had reported erratic Divide by Zero errors and
had stated that this was clearly a programmer error,
their Senior Technician replied "a divide by zero
error is not a programming error - it is a normal
event that happens with Windows". B.S.: A DIVIDE
BY ZERO ERROR IS ALWAYS A PROGRAMMING ERROR.
I later found Netscape's problem; I had printed and
the printer was there, but when I had turned off the
printer, Netscape failed to test that the printer
was still alive, and failed with the DIVIDE error.
Thanks to Robert Blackburn, Dominion Resources Services, Inc, USA.
Change 23.047 The date part of READTIME, JHRRDOD, was changed from PD4
VMACESPH 0101303F for 30Oct2001 to 2005066F for 07Mar2005, causing
Mar 10, 2005 INVALID ARGUMENT TO FUNCTION DATEJUL when MXG read the
changed data format. MXG now tests for the new format.
Thanks to Larry Riggen, Cinergy, USA.
Change 23.046 -DB2ACCT vars QXCRESEQ,QXALTSEQ,QXDROSEQ,QXPRRESI,QXALTVW
VMACDB2 were incorrectly INPUT in DB2 V7 records; those fields
Mar 10, 2005 only exist in DB2 V8. The test IF LENQXST GE 440 for
that INPUT should have been GE 460.
-Those five QX variables were not INPUT at all in the STAT
records, but now are kept and deaccumulated in DB2STATS,
for DB2 Version 8.
-Variable QBGAWS was incorrectly INPUT in DB2 V7 records,
but it only exists in V8; logic was corrected.
Thanks to Allan Winston, MBNA, USA.
Change 23.045 Support for TMS Release 11 is already in place in MXG, as
TYPETMS5 the Appendix A for the TMC Volume and DSNB records shows
Mar 9, 2005 no changes to those records.
Thanks to Norm Hollander, CA, USA.
Change 23.044 Two new variables were added to ASUMCACH, and new member
ASUMCACH TRNDCACH was created:
TRNDCACH NREXPOSR - Maximum number of exposures during interval
Mar 9, 2005 INTCHGEX - Number of intervals in which exposure count
changed.
Also, labels for IORATE, IORATEC, and DURATM now exist.
Thanks to Diane Eppestine, SBC, USA.
Change 23.043 Global Macro Variables EPDBVAR,EPDBCDE,EPDBOUT are now
VMXGINIT defined in VMXGINIT, and referenced in their counterpart
EXPDBVAR EXPDBVAR,EXPDBCDE, and EXPDBOUT members, so that UTILBLDP
EXPDBCDE can use those macro variables for "instream" tailoring.
EXPDBOUT
Mar 9, 2005
Change 23.042 New SAS options DMSLOGSIZE=999999 and DMSOUTSIZE=999999
CONFIGV9 with those maximum values that increase the number of
Mar 9, 2005 lines that can be sent to the log or list windows; the
old limit was 99,999. Unfortunately, these options must
be set at SAS initialization, and cannot be set in the
autoexec.sas file under ASCII. For ASCII execution, you
must either update your sas.cfg file, or you can add
-dmslogsize 999999 to the options in your SAS icon.
Thanks to Kevin Hobbs, SAS Institute Cary, USA.
Change 23.041 This new analysis member calculates the DELTATM between
ANAL30V the end of one SMF 30 interval to the start of the next
Mar 8, 2005 interval for each job, and it also calculates SWAPEDTM,
the duration when the job was swapped out after the true
INTETIME end-of-interval. The true "resource duration"
of each type 30 interval record (subtype 2, 3, and 6) is
from INTBTIME to INTETIME, but if a task is swapped out
at the end of the interval, the SMF record is not written
until the task is swapped back in, which can be minutes
or hours later, and since no resources were consumed
while the task was swapped out, SMF resets the INTBTIME
of the next interval to the SMFTIME of the prior record.
So if you look at just the time between INTETIME and the
next INTBTIME, you can see very large values, because it
is the sum of SWAPEDTM plus DELTATM, but in a test with
70,000 interval records, I found a maximum DELTATM value
of only 0.37 seconds. I did discover that the "normal"
sort sequence of READTIME JOB JESNR INITTIME was not
sufficient for some started tasks (notably OPSOSF) that
have multiple instances per system and that start before
SMF initialization - those STCs have missing JESNR, but
had identical values for those variables for what were
separate instances, so SYSTEM ALOCTIME LOADTIME were
inserted in the sort sequence to separate them; if that
heuristic fails, the DELTATM can be a negative value.
Thanks to Dave Thorn, SUNGARD, USA.
Change 23.040 Condition Code/Return Code 0004 is set in ANALPRTR due to
ANALPRTR WARNING:APPARENT SYMBOLIC REFERENCE xxx NOT RESOLVED
Mar 8, 2005 when there were no observations in PDB.ASUMPRTR; those
two macro variables are normally created by CALL SYMPUT
in a DATA step, but when there are no observations, that
data step is not executed. To resolve the reference, the
%LET EARLIEST=; and %LET LATEST=; statements are inserted
at the beginning of the member, so there is no unresolved
macro even when there are no observations.
In this open code, the choice was either to use the
pair of %LETs, or to put both macro variables in a
%GLOBAL statement. Both choices effectively "GLOBAL"
the macro variable, since its value will exist for any
later program that references that same name. One big
difference is that using %GLOBAL does not change the
value if the macro variable was already %GLOBALed, so
you could (accidentally?) pick up a prior value, while
the %LET will set the always reset the macro variable
value. Finally, while not documented in Change 19.230,
using %GLOBAL to initialize macro variables to null
saved measurable CPU time, compared with using the
several hundred %LET statements, so the VMXGINIT
member now only uses %LETs where a non-null initial
value is required. If ANALPRTR were pervasively used,
I'd have put these two macro variables in VMXGINIT,
but it is very old analysis, and the CPU times that it
estimates are way out of date, and new printer devices
may not be amenable to its thruput measurements, so
using the two %LETs was the simple choice.
Thanks to Scott Barry, SBBWorks, Inc, USA.
Change 23.039 Archaic variable QTXASUS is now set missing; long ago it
VMACDB2 was replaced by QTXASLOC, and while it was documented as
Mar 7, 2005 archaic in ADOCDB2, it caused confusion because it had a
value, when it should no longer be used. Instead, the
three variables QTXASLOC, QTXASLAT and QTXASOTH break out
the suspends for Lock, Latch, and Other conflicts.
Thanks to Marty Pruden, Nestle Purina PetCare Co., USA.
Change 23.038 Code was revised to eliminate MISSING VALUE messages by
VMAC30 either relocating calculations or by testing prior to
Mar 7, 2005 the calculation.
Change 23.037 -TYPE30MU and TYPE89 variable MULCURD is now forced to be
VMAC30 a missing value when the MULCUDF/MULCURT is zero, so that
VMAC89 a value is not carried forward when there are multiple
Mar 7, 2005 segments.
-The TYPE30MU decoding now expects MULCUDF=2 to be &PIB.8.
and MULCUDF=3 to be &RB.8., which is consistent both with
IBM documentation and the SMF 89 record descriptions.
All of my 30 test data has MULCUDF=2 with MULCURD=0, or
has MULCUDF=0, so this correction has not been confirmed
with real data; I do have 89 test data with MULCURT=2 and
binary values for MULCURD, so it makes sense to align the
MXG calculations in 30s with those in the 89 records.
Thanks to Scott Barry, SBBWorks, Inc, USA.
Change 23.036 Using %UTILBLDP with BUILDPDB=NO and INCLAFTER=RMFINTRV,
UTILBLDP Condition Code 4 was set with SAS V9, because RMFINTRV
VMXGRMFI was not protected with OPTIONS DKROCOND=NOWARN when it
Mar 9, 2005 was executed outside of BUILDPDB code. Now, RMFINTRV
is internally protected, and, in addition, when %UTILBLDP
is used with BUILDPDB=NO, it generates DKROCOND=NOWARN
at the top and resets to DKROCOND=WARN at the bottom.
OPTION DKROCOND=NOWARN is extremely useful for MXG;
it lets me have variables in the KEEP= list that are
optional (e.g.: CICSTRAN has a lot of optional vars
that won't exist unless you open the comments in the
appropriate IMACICxxx tailoring member; using NOWARN
suppresses the normal warning that those variables were
not referenced). But prior to SAS V9, NOWARN was just
my convention to keep unneeded messages from your log;
in V9, SAS now sets Condition Code 4 with WARN, so it
is now necessary to protect all known instances in MXG.
Thanks to Scott Barry, SBBWorks, Inc, USA.
Change 23.035 The incorrect references to _LTY30TD were replaced with
UTILBLDP _WTY30TD.
Mar 7, 2005
Thanks to Scott Barry, SBBWorks, Inc, USA.
Change 23.034 The addition of a new dataset (TYPE30TD) to VMAC30 caused
ANALJOBE the old ANALJOBE program to fail, because I failed to add
Mar 7, 2005 the needed override for that new dataset into ANALJOBE.
Adding overrides for that dataset would have worked, but
Scott very nicely revised the logic to use the _Vdddddd
macro tokens so that new datasets could be added to any
of the VMACxxxx members used in ANALJOBE, transparently,
and I don't have to remember to revise ANALJOBE to keep
up with future new datasets in the VMACx it uses!
He also removed the hardcoded MACJBCK= statement which
prevented the use of an instream MACKEEP=.
Thanks to Scott Barry, SBBWorks, Inc, USA.
Thanks to Sam Bass, McLane Co., USA.
Change 23.033 Example in comment should have been UTILS2ER instead of
UTILS2ER FINDS2ER, which was the earlier iteration; the member
Mar 7, 2005 FINDS2ER should not have been kept and is now deleted.
Thanks to Tom White, SPRINT, USA.
Change 23.032 Variables ASID and TARCASID were not formatted $HEX4. but
VMACTMNT now they are. ASID was only $HEX2. and TARCASID had no
Mar 6, 2005 format, so it printed a decimal value.
Thanks to Scott Chapman, American Electric Power,USA.
Change 23.031 Variables SRCDSN and TRGDSN do not exist in ICEBR8SN data
VMACICE set, but were accidentally in the KEEP= list, causing
Mar 6, 2005 confusion. They are now removed.
Thanks to Doug Medland, IBM Global Services, CANADA.
Change 23.030 -ML-33 of MXGTMNT corrects zero values in these variables
ASMTAPEE in the TYPETARC Tape Allocation Recover Event records:
Mar 2, 2005 DEVNR and UCBTYPE were all 0s.
DEVNRCHR was blank
TARCSTRT and TARCEND had the same timestamps.
TARCELAP was 0
TYPESCRN was always 0.
-ML-33 Mount records now have the Mount Time stamp from
the mount message. Hardware errors caused a 20 minute
delay between allocation reserving the drive and the
issuance of the mount message. Allocation handed off to
OAM the request for the mount, but before issuing the
mount, OAM first made a call to the library to get
eligible device pools. Because of the VTS harware
problems, it was late in responding to the request,
causing the mount message to be delayed.
-Mar 11: Mount Records Mount Time is still not correct;
under investigation.
Thanks to Scott Chapman, American Electric Power,USA.
Thanks to Patricia J. Jones, DST Systems, USA.
Change 23.029 The display format for the average service times, which
VMAC74 are in milliseconds, are now printed by default to show
Mar 1, 2005 three decimal places:
AVGCONMS AVGDISMS AVGIOQMS AVGENQMS 6.3
AVGPNCHA AVGPNCUB AVGPNDEV AVGPNDMS AVGRSPMS 6.3
The need for this higher resolution is because the z990
changed the measurement resolution from 128 microsecond
units to one-half microsecond; Pat showed that with a
real value of 192 microseconds, the old resolution with
truncation was reported as .1 millisecond, but with the
new resolution and rounding, the disk service time was
reported as .2 milliseconds per SSCH, causing concern
that service time had increased, when, in fact, there
was not change in the actual service time, but a great
improvement in the measurement of disk service times.
His full paper on this subject, "Understanding the
Differences between z900 and z990 Service Time
Measurements" is available at http://www.perfassoc.com.
Thanks to Dr. H. Pat Artis, Performance Associates, USA.
Change 23.028 DB2STATS variables QDSTCIN2 and QDSTNADS had very large
VMACDB2 values. MXG deaccumulated them, because IBM documentation
VMACDB2H did not indicate otherwise, and early test data had all
Mar 1, 2005 zeroes, but data now shows they should not have been DIFd
and both are no longer deaccumulated.
-Record with only header 1 and header 2 created false
error message that header was invalid.
Thanks to Peter Farrell, Commerce Bank, USA.
Change 23.027 Support for IMPLEX Versions 3.1 and 3.3.
VMACMPLX
Feb 28, 2005
Thanks to Bob Gauthier, Albertsons, Inc, USA.
Change 23.026 -Byte-containing fields were carried as characters; they
VMACWWW are now numeric with MGBYTE format to "print pretty".
Feb 28, 2005 -IIS Web Logs printed INVALID THIRD ARGUMENT FOR SUBSTR
Mar 2, 2005 because MXG did not expect a zero length URIQVALU.
Thanks to Bob Gauthier, Albertsons, Inc, USA.
Change 23.025 %UTILCONT(PDB=PDB); failed if //PDB was DISP=NEW, with
UTILCONT ERROR: LIBRARY DATA SET xxx.PDB CANNOT BE OPENED BECAUSE
Feb 28, 2005 IT IS EXTERNALLY ALLOCATED DISP=NEW OR DISP=MOD,
Mar 7, 2005 AND IT RESIDES ON MULTIPLE VOLUMES
The cause is our choice to not issue PROC CONTENTS if the
DDNAME points to a sequential library, unless you told us
to by removing SEQUENTIAL from the EXCLUDE= opearand.
(The CONTENTS against a sequential library has to read
the entire library, including all datasets, because there
is no directory in sequential librarys). The problem is
that we cannot detect the engine unless the library:
a) has had activity, or
b) a LIBNAME statement has been issued.
To solve that old problem, we used a LIBNAME xxx DISP=SHR
in UTILCONT so we could always know the engine of the
library, but that is what caused this error!
In this redesign, for z/OS only, when PDB= is a list of
one or more DDNAMEs, the LIBNAME is issued only when the
DD is not allocated, then a %VGETENG determines the
engine, the MXGENG dataset is deleted, and %VGETENG is
reinvoked to get to get the full list of all datasets in
that library.
Thanks to Jeffrey A. Harder, Farm Bureau Insurance, USA.
Thanks to Paul Naddeo, FISERV Phildelphia, USA.
Change 23.024 CONTROL-D SF2 records were INCOMPATIBLY changed; fields
VMACCSF2 for SF2PAGE and SF2DPAGE were increased in place from 6
Feb 25, 2005 to 8 bytes.
Thanks to Brian Crow, British Telecom, ENGLAND.
Change 23.023 ABEND 878-10 with REGION=180M got thru seven systems data
ASMRMFV before the failure. REGION=200M processed the data from
Feb 25, 2005 all ten systems at one time.
Thanks to Chuck Hopf, MBNA, USA.
Change 23.022 -Support for VSM subtype 30.
VMACSTC -HSC V6 made changes to subtype 4, STCVMU dataset, but the
VMXGINIT SMF record does not agree with the documentation, and the
IMACSTC result is large and invalid values. No MXG change has
EXSTCV30 been made, pending STK corrections to their data or doc.
Feb 24, 2005 -Apr 18: Debugging PUT statement, un-commented in tests of
Apr 18, 2005 this enhancement, is now re-commented, as it printed an
un-needed line of text on the log for each STC record.
Thanks to Michael Creech, Fidelity Information Services, Inc, USA.
Change 23.021 -LP0xxxxx variables were not populated; Change 22.293 was
VMAC7072 not properly migrated from test to my master library.
VMXG70PR Only LP0MGTTM is populated with the CPU time, since all
Feb 23, 2005 PHYSICAL CPU time is really "management" time.
Feb 28, 2005 -Variable SHIFT was added to PDB.ASUM70LP dataset.
Oct 31, 2005: See Change 23.276.
Thanks to Ken Jones, Xwave, CANADA.
Thanks to Jim S. Horne, Lowe's Companies, Inc, USA.
Change 23.020 Support for CyberFusion user SMF record.
EXCYFUSN
IMACCYFU
TYPECYFU
TYPSCYFU
VMACCYFU
VMXGINIT
Feb 23, 2005
Thanks to Robin Murray, ManuLife, CANADA.
Change 23.019 Although using DCOLLECT (see JCLDAYDS JCL example) is the
ASMVTOC recommended way to "graze" your DASD farm, ASMVTOC can be
Feb 21, 2005 used, but the comments did not give an example of how to
use the //VOLLIST DD to exclude volumes. The comments
now show the explicit syntas.
Thanks to Brian Crow, British Telecom, ENGLAND.
Thanks to Fabio Massimo Ottaviani, DTSITALIA, ITALY.
Change 23.018 Invalid ID=9 record caused ARRAY SUBSCRIPT OUT OF RANGE,
VMXGGETM when UTILGETM was used by JCLTEST8. The SMF 9 record
Feb 18, 2005 does NOT contain a subtype, but the first byte was '7F'x,
with bit 1 (the '40'x bit) on, and that caused MXG to
read the bytes 19-20 as a two-byte SUBTYPE value, which
contained '0200'x, so SUBTYPE=512. Subtype was originally
a one-byte field, so only values of 0-511 were valid
subtypes. But as subtypes can now be two bytes, and
because the array is only used in VMXGGETM to tabulate
the count of SMF IDs and their SUBTYPEs, MXG only
intended to count subtypes 0-511 (and it protected known
larger subtypes, like CICS records from Boole & Babbage
by resetting them). The array error was because MXG's
protection was incorrect, the statement IF SUBTYPE GT 512
should have been IF SUBTYPE GT 511, and that is the
statement corrected by this change. The 02 value in byte
19 that caused SUBTYPE=512 is SMF9VPC, which identifies
the issuer of the Vary Path command that caused this SMF
9 to have been written, and I now see a new value
described:
2=Enterprise System Connection Manager
previously, only 0=Operator was written, which explains
why we are now correcting this problem in VMXGGETM. BUT:
The real error is that Bit 1 in SMF9FLG is on, which says
there's a valid subtype, which is not true for ID=9.
Thanks to Charles Bellamy, SCANA, USA.
Change 23.017 If %INCLUDE SOURCLIB(ASUMUOW) is used (JCLTESTV8/9 do),
VMXGUOW but IMACUOW was not updated to tell MXG that you want us
Feb 17, 2005 to create observations in PDB.ASUMUOW, your job will fail
ERROR: NO BY STATEMENT USED OR NO BY VARIABLES SPECIFIED
WARNING: DATASET WORK.UOWSORT MAY BE INCOMPLETE.
You were not supposed to have to update IMACUOW, but the
changes we made to add MQ-Series data to PDB.ASUMUOW were
always tested with a tailored IMACUOW; I failed to test
with the default IMACUOW in MXG 22.22, and we always
build the PDB.ASUMUOW dataset in our QA streams, to make
sure it is created without error.
The source of the problem is arguably a SAS design error;
we added the creation of a second dataset in a data step
whose first dataset was created as a VIEW, but the
default IMACUOW sets OPTIONS OBS=0; to prevent ASUMUOW
from sorts of both CICSTRAN and DB2ACCT. Unfortunately,
it turns out that that second dataset is NEVER created
when OBS=0 is in effect. While SAS Technical Support
investigates to see if this is a feature or a defect, we
circumvent the error by always creating that dataset
(_UOWCIC) with zero obs, before the data step with the
VIEW, so that it always will exist. If you enable IMACUOW
to create obs, the dataset is re-created with obserations
when the VIEW is executed.
Thanks to Alan Chenoweth, EDS, USA.
Thanks to Linda Piekarski, National Grange Mutual Insurance Co., USA.
Change 23.016 A VM 4.4 system's MONWRITE control block data contained a
VMACVMXA value of 00028709X instead of the normal 00008709X;
Feb 17, 2005 change line 5071 to test for both values:
IF IPARMLF1 NE 00008709X AND IPARMLF1 NE 00028709X THEN DO;
while we await a reply from IBM VM Support as to whether
this is an error or an undocumented feature.
Thanks to Mike Salyer, Citicorp, USA.
Change 23.015 If you create a WEEK.SMFINTRV or MONTH.SMFINTRV, your job
MONTHASC may get ERROR: BY VARIABLES NOT SORTED MON.SMFINTRV. The
MONTHBL3 sort order of PDB.SMFINTRV was changed in MXG 22.13 for
MONTHBLD Change 22.320 consolidation of MULTIDD='Y' observations.
MONTHBLS The original BY list in BUILDPDB was:
MONTHDSK READTIME JOB JESNR INTBTIME INTETIME
WEEKBL3 and the new sort order internally is
WEEKBL3D READTIME JOB JESNR INITTIME INTBTIME
WEEKBL3T In the cases that failed, there were multiple instances
WEEKBLD of the same STC JOBNAME that was an "early ASID" that had
WEEKBLDD started before SMF (i.e., it did NOT have a JESNR), and
WEEKBLDT both interval records had exactly the same values for
Feb 16, 2005 READTIME JOB JESNR and INITTIME, but the INTBTIMEs were
.01 seconds out of order, causing the NOT SORTED.
The solution is simple: in your WEEKBLD/MONTHBLD members,
change the BY list for the PDB.SMFINTRV dataset to only:
READTIME JOB JESNR
to eliminate the exposure.
-While using %INCLUDE SOURCLIB(TYPS30) will create dataset
PDB.SMFINTRV, that is no longer a recommended way,
because that dataset still contains the multiple
MULTIDD='Y' obs. See the example in the text of Change
22.320 if you want to create PDB.SMFINTRV directly from
SMF without BUILDPDB.
Thanks to Kevin Fletcher, CONSECO, USA.
Change 23.014 Consoldiated into Change 23.012.
Change 23.013 -Variable LPARCPUX is now kept in TYPE70PR, because it is
VMAC7072 the count of logical CPs assigned to the LPAR, and that
Feb 13, 2005 includes the number of "initial" CP engines, the number
of "reserved" CPs (which also includes ICFs, IFLs, and
IFAs that are assigned to the LPAR). This is important so
that enough "reserved" CPs can be known for each LPAR.
If too few reserved CPs were defined, you cannot
non-disruptively use Dynamic Capacity Upgrade on Demand
to implement an upgrade to an LPAR.
Thanks to Don Deese, (CPExpert), Computer Management Sciences, USA.
Change 23.012 -Typos in MXG 22.22 JCL examples:
COVERLTR -JCLTEST9: Line 130, WORKVOL=5 needs a comma.
JCLTEST8 Lines 166,168 need // in col 1 and 2.
JCLTEST9 Line 392 should be MXGSASV9
MXGSASV9 -JCLTEST8 and JCLTEST9:
MXGSASV9 //TESTQAPM step needs //QAPMJSUM DD DUMMY.
README -MXGSASV9: Lines 58 and 60, JCL needs //.
UPRINDOC -MXGSASV8 and MXGSASV9: the INSTREAM DD should be:
Feb 12, 2005 //INSTREAM DD UNIT=SYSDA,SPACE=(CYL,(1,20)),
Feb 22, 2005 // RECFM=FB,LRECL=80,BLKSIZE=0
Feb 23, 2005 The change to LRECL=72 caused unnecessary error
May 23, 2005 when UTILS2ER was run, and there's no value in
changing the historic LRECL from 80 to 72.
-Coverltr: Ref to Change 22.133 should be 22.123 for V9.
-README File on CD and the README member was missing an
equal sign: SPACE=(80,2,1)) SPACE=(CYL,(25,5)).
The PUT should be PUT 'c:\mxgcd\ieb....'.
-UPRINDOC: JCL example was missing ending comma, line 11.
Comments updated for example ASCII execution.
The program works, but produces an error; the
lines after the RUN; after %INCLUDE INSTREAM;
were debugging lines that should be deleted.
Thanks to Linda Piekarski, National Grange Mutual Insurance Co., USA.
Thanks to Sam Bass, McLane Company, USA.
Thanks to Jack Basile, PCH, USA.
Thanks to Francisco Ojeda, SAS Cary, USA.
Thanks to John Mattson, EPSON, USA.
Thanks to David Klein, DOITT, City of New York, USA.
Thanks to Sam Bass, McLane Company, USA.
Thanks to Brian Felix, Wachovia Corporation, USA.
Thanks to Jim S. Horne, Lowe's Companies, Inc, USA.
Change 23.011 MXG 22.22-22.12. DB2 variables QWHT../QWHU../QWHD./QWHA..
VMACDB2H from DB2 Trace, CPU, Distributed, Data Sharing Header may
Feb 11, 2005 be blank or missing; the extraneous statement at line 130
Feb 25, 2005 LENLEFT=LENGTH-COL+1;
May 20, 2005 must be deleted. Of course, they can also be blank when
those headers don't exist in a particular record, which
is completely normal! In addition, for SMF records that
are created from TMON/DB2 data, that statement caused the
INPUT STATEMENT EXCEEDED RECORD LENGTH, error: TMON SMF
records have headers at the start, rather than the end of
the SMF record (which is okay, since they are relocatable
sections with a "triplet" location pointers); it was MXG
recalculation of LENLEFT that was the cause of the error.
May 20,2005: This error also causes THREADTY variable to
be blank when it shouldn't be!
Thanks to Marty Pruden, Nestle Purina PetCare Co, USA.
Thanks to C. C. VanHook, DST Systems, USA.
Thanks to Steve Cunningham, DST Systems, USA.
Thanks to Craig Gifford, City of Lincoln NE, USA.
Change 23.010 Some fields that could contain '00'x are translated to a
VMAC119 blank value. RACFUSER, TTPOL, TTPROF, FCHOSTNM, FCM1,
Feb 8, 2005 FCRS, FCSUSER, and UDLPHIGH.
Thanks to Bruce Widlund, Merrill Consultants, USA.
Change 23.009 The RACF Database "Installation data" filed, INSTDATA,
VMACRACF can be $255, but only $40 was input.
Feb 8, 2005
Change 23.008 -Invalid ESS data that cannot be corrected in MXG caused
IMAC6ESS INPUT STATEMENT EXCEEDED. 0038x segment had Length=127,
VMAC6 but only 27 bytes of data, 0027x segment had length=0.
Feb 3, 2005 While IBM is contacted to resolve their errors, the only
circumvention is to insert MACRO STOPOVER MISSOVER %
as the first statement after //SYSIN. You will still see
MXGWARN: UNDECODED KEYS IN EXTENDED SMG 6 ESS DATA notes.
-A 0047x segment had 64 bytes when MXG expected 62, so the
size of FSSDATA field was increased to 99 bytes in this
change.
-The 0044x segment is supported creates ESSOFSTY variable.
Thanks to Dr. Alexander Raeder, Itellium, GERMANY.
Change 23.007 Five CPU variables in QAPMJOBL were incorrectly input as
VMACQACS milliseconds (&PD8.3) instead of microsedonds (&PD.8.6).
Feb 3, 2005 The "8.3" was changed to "8.6" for these variables in
the VMACQACS (with Change 22.371 as the last change):
JBCPU 5672
JBRUT 5736
JBSZWT 5757
JBTCPU 5780
JBMTXT 5792
Thanks to Paul Gillis, Pacific Systems Management Pty, AUSTRALIA.
Change 23.006 -Support for RACF Events 32-34,38-39,42-45,48,50,54-55,57,
EXTY8032 59,61-62, and 64 creates these
EXTY8033 these 18 new TYPE80A datasets:
EXTY8034 dddddd Dataset Description
EXTY8038 TY8032 TYPE8032 RACF EVT 32 CHANGE DIRECTORY
EXTY8039 TY8033 TYPE8033 RACF EVT 33 CHANGE FILE MODE
EXTY8042 TY8034 TYPE8034 RACF EVT 34 CHANGE FILE OWNERSHIP
EXTY8043 TY8038 TYPE8038 RACF EVT 38 INIT OF PROCESS
EXTY8044 TY8039 TYPE8039 RACF EVT 39 TERM OF PROCESS
EXTY8045 TY8042 TYPE8042 RACF EVT 42 MAKE DIRECTORY
EXTY8048 TY8043 TYPE8043 RACF EVT 43 MAKE NODE
EXTY8050 TY8044 TYPE8044 RACF EVT 44 MOUNT FILE SYSTEM
EXTY8054 TY8045 TYPE8045 RACF EVT 45 OPEN NEW FILE
EXTY8055 TY8048 TYPE8048 RACF EVT 48 REMOVE DIRECTORY
EXTY8057 TY8050 TYPE8050 RACF EVT 50 SET EFFECTIVE UID
EXTY8061 TY8054 TYPE8054 RACF EVT 54 UNLINK
EXTY8062 TY8055 TYPE8055 RACF EVT 55 UNMOUNT FILE SYSTEM
EXTY8064 TY8057 TYPE8057 RACF EVT 57 CHECK PRIVILEGE
IMAC80A TY8059 TYPE8059 RACF EVT 59 RACLINK
VMAC80A TY8061 TYPE8061 RACF EVT 61 IPCGET
VMXGINIT TY8062 TYPE8062 RACF EVT 62 IPCCTL
Feb 9, 2005 TY8064 TYPE8064 RACF EVT 64 CHKOWN2
-SMF 80 records with SMF80EVT=0 were discovered and were
being output to TYPE80CM dataset (which should always
have zero observations, since it is used only for events
that are not supported in MXG, and once you have one of
those events and send the SMF data, that event will be
supported!). IBM APAR OA03336 documents on condition
that causes SMF80EVT=0 and installing the PTF for that
APAR eliminated the RACFEVNT=0 observations.
Thanks to Peter Schubert, CITEC, AUSTRALIA
Change 23.005 An old VMXGSUM member in "USERID.SOURCLIB" caused message
VMXGSUM ERROR: APPARENT MACRO VGETENG NOT RESOLVED in BUILDPDB.
VMXGVERS The INSTALL instructions remind you to remove all of the
Feb 2, 2005 VMXGxxxx & VMACxxxx members from your tailoring library
when you install a new version. But even if you enable
diagnosic OPTIONS SOURCE SOURCE2 MACROGEN MPRINT; we can
only see members %INCLUDEd from your library; %VMXGxxxx
members are AUTOCALLed %MACROs, and they do not print the
source text on the log. To prevent these errors due to
a back-level %VMXG.... or %VGET.... macro, each of them
now invoke the %VMXGVERS macro that compares the member's
internal version number with the current MXG version, and
if they are inconsistent, prints this message:
MXGERROR: VMXGxxxx IS BACK-LEVEL AT NN.MM, ....
reminding you to remove that back-level VMXGxxxx member.
Thanks to Bill Whitehead, Experian, USA.
Change 23.004 Support for SAMS Vantage "LSPACE" record subtype, creates
EXSAMLSP SAMSLSPC dataset.
IMACSAMS
VMACSAMS
VMXGINIT
Feb 1, 2005
Thanks to Christelle Abily, GICM, FRANCE.
Change 23.003 Unused Change.
Change 23.002 Comments only. Description of the arguments for SYSTEM=
ANALAVAI and APPn= were confusing, and have been clarified.
Feb 1, 2005
Thanks to Allen O. Homonyom, Department of the Army, USA.
Change 23.001 NDM Subtype 'SY' caused INPUT STATEMENT EXCEEDED RECORD
VMACNDM error; the length in NDMSYOPL included itself, which was
Jan 30, 2005 not documented, causing MXG to read one byte too many.
After the @; after the INPUT of NDMSYOPL, insert
IF NDMSYOPL GT 0 THEN NDMSYOPL=NDMSYOPL-1;
Thanks to Victor Chacon, Verizon Wireless, USA.
LASTCHANGE: Version 23.