* copyright (C) 1984-2019 merrill consultants dallas texas usa
Yüklə 28,67 Mb.
|
| Change 21.229 -Variable CPUTM=SUM(PRODTCB,PRODSRB) added to TYPE89 data
VMAC89 set for consistency; MXG datasets with multiple CPU Time Nov 11, 2003 measurements were intended to always have variable CPUTM as the total, unoverlapped, billable, etc., CPU time, but TYPE89 was overlooked. Thanks to Jake M. Drew, MBNA, USA. ====== Changes thru 21.228 were in MXG 21.06 dated Nov 10, 2003========= Change 21.228 Support for RMF III ASMRMFV data added by Change 21.186. EXZRBCFI - CFI segment creates ZRBCFI dataset EXZRBRCB - RCD segment creates multiple datasets: EXZRBRCD ZRBRCB ZRBRCDB RMFIII RESPONSE TIME BUCKETS EXZRBRCP ZRBRCS ZRBRCDS RMFIII SERVICE CLASS EXZRBRCR ZRBRCR ZRBRCDR RMFIII REPORT CLASS EXZRBRCS ZRBRCP ZRBRCDP RMFIII PERIOD EXZRBRCT ZRBRCT ZRBRCDT RMFIII RESPONSE TIME COUNTS EXZRBSVC ZRBRCD ZRBRCDD RMFIII SUBSYSTEM DELAY EXZRBSVG - SVP segment creates multiple datasets: EXZRBSVP ZRBSVP ZRBSVPP RMFIII SERVICE POLICY EXZRBSVR ZRBSVW ZRBSVPW RMFIII SERVPOLICY WORKLOAD DEFN EXZRBSVW ZRBSVC ZRBSVPC RMFIII SERVPOLICY SRVCLASS DEFN EXZRRSVZ ZRBSVZ ZRBSVPZ RMFIII SERVPOLCY SRVCLASS PERIOD IMACRMFV ZRBSVR ZRBSVPR RMFIII SERVPOLICY REPORC CL DEFN VMACRMFV ZRBSVG ZRBSVPG RMFIII SERVPOLICY RESOURCE GROUP VMXGINIT - UWD segments produce warnings (first five) that will Nov 9, 2003 will be investigated, and only cursory validation of all of the new data has been accomplished. Some back end merges/unions may be necessary, and/or there may be some variables that need to be carried forwared, but that awaits someone who really wants to use these new data segments, but lots of the data is already in the TYPE7xxx RMF Monitor I data. Change 21.227 Final Cleanup after full QA runs: ANALDBTR -ANALDBTR updated to include all pairs datasets; I183R183 ANALDB2R was changed to S183S183 for consistency in pair names. CONFIG -Archaic CONFIG member for SAS V6 specifies MEMSIZE=128M. JCLTEST6 -VMAC6,IMAC6ESS ESSPIMSG/ST spellings corrected, all vars IMAC6ESS in DROP and KEEPs. VMAC6ESS Nov 8, 2003 Thanks to Freddie Arie, TXU, USA. Thanks to Bruce Widlund, Merrill Consultants, USA ====== Changes thru 21.226 were in MXG 21.06 dated Nov 7, 2003========= Change 21.226 Support for GEPARMKY=000B in Extended SMF 6 ESS data now IMAC6ESS creates ESSDEFAU variable if IMAC6ESS is enabled to VMAC6 decode those optional ESS data fields. Nov 7, 2003 Thanks to Engelbert Smets, Provinzial Rheinland Versicher, GERMANY
VMXGRMFI WORKLOAD name, variable WKLDNAME, instead of a long list Nov 7, 2003 of Service Class Names, by this enhancement that adds an eight value to the WORK= argument. Caveats: USECNTRL must be YES or GOAL, or nothing will be found. And if you mix up workloads, service classes, and reporting classes, the UTILRMFI can't help you figure out what you've done wrong because WORKLOAD doesn't exist in TYPE30 SMF. -The SPIN logic to detect existence was enhanced. -Note that if both SRVCLASS and WORKLOAD are specified, that WORKnn workload will include all observations that match either the SRVCLASS or the WORKLOAD names, so you must be careful to avoid any overlap. Thanks to Stan Dylnicki, Royal Bank of Canada, CANADA. Thanks to ??? who actually asked for it earlier. Identify yourself. Change 21.224 New QAPMCONF variables GDESIL/GDESIT/GDESPU were missing VMACQACS values because they were not in the RETAIN statement, and Nov 6, 2003 the configuration file has one record per parameter; all Nov 10, 2003 GDESxxxx variables are now RETAINed. -New variables GDESIL/GDESIT/GDESDL/GDESDT had incorrect values; they are now input as PIB2.1 instead of PIB4.1; I misread the OS/400 description of B(4,1) as being a four byte field. -New variable GDES18 decodes the GDESKEY='18' record. -Variables GDESAP and GDESAT are addresses, and are now formatted as MGBYTES (so they print 255G for 255 GBytes). -Variable GDESI, interval value, was multiplied twice by 60, causing an incorrect value. Thanks to Jim Wertenberger, Antares Management Solutions, USA. Thanks to Al Kadowaki, IBM Corporation, USA.
VMACSARR EXCEEDED RECORD LENGTH error because MXG used $VARYING40. Nov 6, 2003 but one instance had 45 characters. Now use $VARYING80., and protection was added if the text length is greater than 80. Then I realized these character variables were not even output (probably because I didn't have any data with index data), so the subtype 30/31 datasets now have variables SV30/31INAM,SV30/31IVAL,SV30/312VAL,SV30/313VAL with the Index name and the first three index values. Thanks to John Rivest, TDS, USA. Change 21.222 SAS Version 6 ERROR 29-185 WIDTH INVALID $EBCDIC255 when VMAC102 MXG was executed under SAS V6, which limited character VMAC110 variables to 200 bytes. While execution under SAS V8.2 VMXGINIT or later is STRONGLY RECOMMENDED, it was my intention to Nov 3, 2003 support execution under V6 for all of the "standard" code Nov 27, 2003 members, so this oversight was corrected with a new macro variable &EBC255 that will input $EBCDIC200. +55 for V6. These new products require execution under SAS V8: TYPEAIX - AIX Performance Tool TYPETMTC - TMON ASG-Landmark TCP/IP monitor TYPEWWW - Web Logs TYPEOMDB - Omegamon II for DB2 Historical File -In addition, a $VARYING250 in VMAC102 was changed to only read in the first 200 bytes with $VARYING200. Thanks to Kevin Wells, ScaleOn Gmbh & Co KG, GERMANY.
VMACWWW caused INVALID ARGUMENT messages, and causing variable Oct 31, 2003 GMTOFFTM to be missing, but ENDTIME was correct. Nov 5, 2003 -ELAPSTM was missing value in IIS logs due to typo, and is now formatted TIME8. Thanks to Robert Gauthier, Albertsons, USA. Change 21.220 FLASH: MXG 21.07 is required for PDB.ASUMUOW to have all ASUMCICX reported errors fixed. If you use JCLUOWV from an ASUMUOW earlier MXG version, or use VMXGUOW, ASUMUOW, ASUMUOWT on ASUMUOWT Landmark MONITASK data to build PDB.ASUMUOW, you're at JCLUOWP risk of having incorrect data, like missing values for JCLUOWV STRTTIME, or your perfectly running BUILDPDB can ABEND VMACTMO2 with DATASET DB2ACCT NOT SORTED or with the VARIABLES NOT VMXGUOW FOUND error condition. We have had a series of Oct 30, 2003 architectural revisions to correct the sort sequence for Nov 30, 2003 LU 6.2 transactions, and corrections to that redesign, and restructured into ASUMUOW for IBM CICSTRAN and ASUMUOWT for ASG MONITASK data, to eliminate double mounts of tape libraries, and only now does it appear we've fixed everything or at least documented that you must use the JCLUOWV or JCLUOWP members from MXG 21.06, due to these changes: Change 21.194 - Added Variables Change 21.147 - Populated STRTTIME Change 21.134 - MONITASK fixed Change 21.093 - SYSTEM blank, cleanup Change 21.076 - Stored Procedure vars added Change 21.062 - SORT ORDER CHANGED, vars dropped Change 21.237 - ASUMUOWT fixed This change is only documenation of the INCOMPATIBLE changes that have been made to this very-important MXG program that we strongly suggest you use to put the DB2 and CICS transaction data together. Thanks to Larry Nova, Transamerica, USA. Change 21.219 Support for IBM Tivoli Storage Manager Accounting Records EXTSMACC creates new TSMACCT dataset when data files are IMACTSMA transferred, with counts of transactions and bytes TYPETSMA transferred. TYPSTSMA VMACTSMA
VMXGINIT Oct 27, 2003 Thanks to Simone Niemczura, Sungard, USA.
VMAC71 label, but the "USED" did not belong, as all count the Sep 24, 2003 number of available, not used, frames: AVLEXTAV AVLEXTMN AVLEXTMX PVTAFCAV PVTAFCMN PVTAFCMX Thanks to Tom Buie, Southern California Edison, USA.
EXTY99U7 TYPE997 dataset. Observations are only output if there IMAC99 were activity counts for the device. VMAC99
VMXGINIT Oct 23, 2003 Thanks to Randy Shumate, LexisNexis, USA.
VMXGRMFI TABLE error; this member should have been updated by Oct 23, 2003 Change 21.149, but my z990 test data was z/OS and the VMXGRMFI test was overlooked. Thanks to Peter Giles, Centrelink, AUSTRALIA.
EXTY80EK segment creates two new MXG datasets: EXTY8XEK TYPE80EK - Contains fixed data plus first EKC80FRD. IMAC80A TYPE8XEK - Contains any additional EKC80FRD relocate VMAC80A data segments. VMXGINIT This change requires execution under SAS Version 8 to Oct 23, 2003 input the full length (up to 1024 bytes) in EKC80FRD; the Nov 2, 2003 code executes under SAS V6 without error, but variable EKC80FRD will be truncated to 200 bytes. Thanks to Jim Holloway, MetLife, USA. Change 21.214 Cosmetic. The FORMAT statement in MACRO _VMRPT3 (for VMACVMXA "report three" listed the variables from _VMRPT2, but Oct 22, 2003 there is no need for those variables in _VMRPT3. Thanks to Thom Kight, Fidelity Investment Systems Co, USA. Change 21.213 Support for Oracle V9.x SMF data is already in MXG, as VMACORAC there were no changes in their SMF record; you need to Oct 20, 2003 set the record ID macro, and the Subsystem macro, but they can be set "instream" after your //SYSIN DD * %LET MACKEEP= MACRO _IDORAC 200 % MACRO _IDORACO SUBSYSID EQ 'TGW9' % ; %INCLUDE SOURCLIB(TYPSORAC); Thanks to Ralf-Henning Glomb, BMW, GERMANY Change 21.212 Support for optional CMODNAME='MQSeries' CICSTRAN data UTILEXCL fields from IBM, added starting in CICS/TS 3.2, creates VMAC110 variables MQGETWTM,MQGETWCN,MQREQS,MQWTCBUS,MQONTCBU, and Oct 20, 2003 MQREQUS. This support requires that you use UTILEXCL to create an IMACEXCL for those variables to exist in the CICSTRAN dataset. But see Change 31.223. Thanks to Ricke Godehard, Itellium, GERMANY. Thanks to Scott Barry, SBBWorks Inc, USA. Change 21.211 Support for RACF segment RACFDTP=44 decodes the value of VMAC80A the command into new variables EV44VAL1-EV44VALF and Oct 20, 2003 stores only the name (PROC,ACCTNUM,SIZE,MAXSIZE, NOUNIT, Oct 28, 2003 and COMMAND) in the existing EV44TXT1-TXTF variables. Oct 29, 2003 Thanks to John McDermott, Blue Cross Blue Shield of Florida, USA. Change 21.210 Support for several new ESS segments (34x,35x,37x,47x) IMAC6ESS and for GEPARMNR more than 1 for 21x and 2Fx added in VMAC6 (optional) IMAC6ESS, also adds new variables to TYPE6 Oct 14, 2003 (but only if comment block in IMAC6ESS is opened, and the DROP= statement is edited in that member to keep the new variables). Thanks to Engelbert Smets, Provinzial Rheinland Versicher., GERMANY.
VMACTPMX ADDRSA CA7 CONVEC CURMSC CURREC1-CURREC6 Oct 14, 2003 observations in dataset DB2ACCTP if the package data Thanks to Lawrence Jermyn, Fidelity, USA. Change 21.208 Variables QWACBSC and QWACESC are missing in package VMACDB2H observations in dataset DB2ACCTP if the package data came Oct 13, 2003 from SMF 101 Subtype 1 (IFCID=239) records, as those records do not contain the QWAC segment. The SMF 101 Subtype 0 IFCID=3 Accounting Record contains the first ten package executions, each of which is output in DB2ACCTP; the SMF 101 Subtype 1 IFCID=239 records contains the rest of the package segments when there are more than 10 per plan. It is also not possible to retain the QWACBSC/ESC from the prior SMF 101 Subtype 0 (IFCID=3) record, because IBM in their infinite wisdom decided to write the 239 record first (even though QWHSSTCK time in that first IFCID=239 record is later than QWHSSTCK time in the following IFCID=3 record). Only with dual sorts of DB2ACCT and DB2ACCTP plus a massive merge, could the QWACBSC/QWACESC timestamps of the account record be added to the DB2ACCTP package dataset, and that's a lot of cost for very little value. The DB2ACCTP dataset variables QPACSCB & QPACSCE are datetimestamps of the "entry to, and exit from" DB2, like a start/end of the package call, but they are also inconsistent: QPACSCE always has a non-missing datetime value QPACSCB is always missing in all IFCID=239 records, and is only non-missing in the first package segment in IFCID=3 records. When QPACSCB is missing, you could consider calculating variable PSEUDOSCB=QPACSCE-QPACSCT, to estimate the SCB start time (by subtracting the execution duration from the end datetime). PSEUDOSCB was slightly earlier than QPACSCB when QPACSCB existed. This change added disabled debugging PUT statements that were used to examine these records, in case they are needed for future investigations. Thanks to Daniel O. Russo, Vanguard, USA.
VMACNTSM incorrect spelling (MSEXCHANGECMCC). Oct 10, 2003 Thanks to Philip Henning, Demand Technology, USA. Change 21.206 Variables QW0125PC QW0125PL QW0125PN QW0125SN QW0125TS VMAC102 are now input and kept in DB2 102 IFCID=125 T102S125. Oct 10, 2003 dataset. Thanks to Ron Alterman, PG&E, USA. Change 21.205 MXG Support for BMC's IMF/CIMS IMS already includes the VMACCIMS variable SMQGROUP, the IMS Shared Message Queue Group Oct 9, 2003 Name, so that you can summarize BY SMQGROUP to see the total response and resources of the entire group. This change is only for documentation (because I didn't know what the heck an IMS Shared Message Queue Group was, either)! A Shared queues group is just a group if IMS systems (an IMS Plex) that share incoming transactions with their shared message queue stored as a structure in a couling facility. A transaction arrives at any IMS System but can be executed anywhere in the Plex. Only one 'FA'x IMF Transaction record is created, even though IMSA may have put the message on the Q and IMSB executed the transaction (and IMSB will be where the FA record was written). Thanks to Ulrich DIllenberger, BMC, GERMANY.
IMACSHFT the SHIFT definitions in your tailored IMACSHFT member, Oct 8, 2003 the input temporary variable DATETIME will have been changed by IMACSHFT logic to the start-datetime of the shift, so that MXG Summarization and Trending datasets have a common STARTIME value. The addition of &MACSHFT support was done only for consistency with other IMACs, but I never considered that anyone would ever want to pass static definitions, like SHIFT, thru %LET MACSHFT! This change stores the original value in DATETIME when IMACSHFT was invoked into temporary variable SHFTTIME, so that if you do use %LET MACSHFT, and don't tailor the default MXG IMACSHFT member, you can set DATETIME=SHFTTIME; as your first statement in MACSHFT=, and then redefine the shifts. However, your MACSHFT= logic must also the DATETIME variable to the beginning of the shift, to protect for later summarization in that job. Thanks to Klaus Messer, COMLAB, GERMANY.
VMAC77 contains individual bit values regarding the enqueue. Oct 7, 2003 Thanks to Doug Medland, IBM Global Services, CANADA. Change 21.202 INPUT STATEMENT EXCEEDED due to invalid OPC record that VMACOPC had LENGTH=83 but TRLLENGT (expected length) of 420. OPC Oct 7, 2003 records have new data inserted, currently the new fields are skipped, pending documentation. Thanks to Andrew Phillip Davis, Abbey, ENGLAND.
VMAC80A Segment is documented for z/OS 1.2 SecureWay as DLN=80. Oct 9, 2003 Caused INPUT STATEMENT EXCEEDED RECORD LENGTH error. This change circuvents by skipping over the segment. This data segment is created by the add-on ETFR product (EKC Tools for RACF is an extension to RACF.ETF/R that selectively grants extended privileges under emergency situations), and that vendor will be advised of their invalid record. Thanks to John Grasing, MetLife, USA Change 21.200 Negative values for DB2TCBTM occur if QWACEJST (ending VMACDB2 CPU time) is smaller than QWACBJST (starting CPU time). Oct 5, 2003 Out of 9,000 transactions, four transactions were neg: QWACBJST QWACEJST QWACRINV 1.61 0.00452 10 0.12 0.00458 10 0.25 0.00415 10 3.63 0.00436 10 IBM notes that BJST or EJST are zero when CPU timing is not available; MXG only calculated the difference when when both are non-zero; this change adds a test to also calculate DB2TCBTM if EJST is greater than BJST, while IBM investigates further. PQ71119 is a correction for Tivoli that mentions why EJST may be zero: rrs commit request can be issued in a different address space than the original attach so DB2 does not have the original TCB; their solution was to force a zero value, as was done here by MXG. However, MXG adds QWACSPCP and QWACTRTE to the delta so you could have DB2TCBTM non-zero even if the EJST-BJST difference is not calculated. Note added Jan 21, 2004: This note is also in NEWSLETTER FORTY-FOUR, MVS Technical Note 2.: APAR PQ79622 corrects error that caused QWACBJST to be greater than QWACEJST, which caused negative DB2TCBTM. The error occurred when an SQL statement fired a trigger and that trigger called either a UDF or a stored procedure, so that class 1 non-nested CPU time could erroneously be a negative value.
Thanks to Richard L. Steele, Nav-International, USA. Change 21.199 -IMACxxxx members with incorrect spelling of the DDDDDD IMAC119 values in the comments, or that were missing new data IMAC28 sets were revised. Only documentation was changed. IMAC42 -VMAC members _Nxxxx and _Sxxxx Null/Sort macros had IMAC74 tokens added for new datasets that had been overlooked. IMAC85
IMAC94 IMACAIX
IMACDOS IMACILKA
IMACMVTP IMACNDM
IMACNSPY IMACNTSM
VMAC90A VMACMWAI
VMACNTCP Oct 5, 2003 Change 21.198 A missing value for STRTTIME in CICSTRAN can occur if you VMAC110 have optional data segments in your transaction SMF Oct 5, 2003 records, but you did copy and remove the comment block in the IMACICxx member for those optional segments. The UTILEXCL program lists all optional data segments and lists the IMACICxx members you must tailor. If you don't tell MXG about the data, its INPUT gets out of alignment, and if STRTTIME happens to have all hex zeros, a missing value results. Since STRTTIME is the Start Time of the transaction, it must always exist in your CICS records. A new message is now printed if STRTTIME is missing. Change 21.197 -ASUMCACH enhanced to keep track of I/O by LPAR (in the ANALCACH variables IORATEA, IORATEB,...) in PDB.ASUMCACH that it ASUMCACH creates. Oct 2, 2003 -Second example Analysis Report added to ANALCACH that Nov 6, 2003 reads the PDB.ASUMCACH dataset, and uses two formats (that you EDIT in your program) that map your DASD UCB addresses to Raid Groups and HDS Rank, so that you can report and measure I/O activity down to the Raid Group within RAIDBOX. Thanks to Chuck Hopf, MBNA, USA. Change 21.196 INVALID DATA FOR VERSN90 message had no impact on the VMAC90 created dataset, but it and associated hex dump are Oct 2, 2003 prevented by the insertion of ?? in the INPUT. Thanks to Jim Petersen, Washington Mutual, USA. Change 21.195 Support for Microsoft Exchange Server 5.5 Log file EXEXCHLG creates EXCHANGE dataset from INFILE EXCHLOG. This IMACEXCH support is preliminary and covers all fields, but parsing TYPEEXCH of sub-fields is contemplated where needed, creating new TYPSEXCH variables eventually. VMACEXCH
VMXGINIT Oct 2, 2003 Thanks to Bob Gauthier, Albertsons, USA.
ADOCUOW STORHWMH STORHWMK SYNCDLTM SYNPTCN VMXGUOW ENQDIOCN ENQDIOTM LU62IOCN LU62IOTM Oct 1, 2003 Variables added to _KUOWCIX (Max): Oct 22, 2003 STORHWMH STORHWMK ADOCUOW was updated to be consistent with VMXGUOW. Oct 22: End Comment before ENQDIOCN =.; was added. Thanks to Paul Gillis, ColesMeyer, AUSTRALIA. Change 21.193 -Variable BYTEAVAI can be zero if AVAILMEM or AVAILMEK is EXNTIPV4 zero (still under investigation). The MXG statement EXNTTCV4 BYTEAVAI=AVAILMEM; is now replaced by the statement EXNTUDV4 BYTEAVAI=MAX(BYTEAVAI,AVAILMEM,AVAILMEK); to cover all IMACNTSM possibilities of values in the three fields. VMACNTSM -Support for new IPV4, TCPV4, and UDPV4 objects create VMXGINIT three datasets of the same name. Oct 1, 2003 -Pending DISCOVERY Records, new data added to ACSR 0/36 and WEBS 1/86 are not yet supported. Thanks to Barry Neff, Infores, USA. Change 21.192 SYNCSORT for z/OS 1.1 can have 255 SORTWORKs, but MXG VMACSYNC only outputs details on the first 99, and would have Oct 1, 2003 failed (ARRAY OUT OF RANGE) if you had more than 99. This change protects for more than 99, but only by printing a message that more were found, and to contact support@mxg.com, if you really have a need for details on the 100th+ sort work area. Thanks to Chuck Hopf, MBNA, USA. Change 21.191 SMF 94 variable SMF94VCZ (Average MB per Logical Vol) is ADOC94 recalculated when it is zero in the IBM record but VMAC94 SMF94VBA/SMF94VLA is non-zero. Many of the SMF94Vxx Sep 30, 2003 variables are zero if SMF94VNO='FF'x (Composite), some are the composite of all AX0's if VNO='FF'X, and some are Yüklə 28,67 Mb. Dostları ilə paylaş:
|