* copyright (C) 1984-2019 merrill consultants dallas texas usa
Yüklə 28,67 Mb.
|
|
wasted the customer and IBM DB2 Support's time.) Thanks to Bart Steegmans, IBM DB2 Support, USA. Change 31.280 MXG variable IOTMNOCA=SMF30AIC-IOTMDASD now correctly VMAC30 compares the DASD connect time captured in SMF30AIS with Jan 1, 2014 the sum of IOTM from the DASD DD segments; previously it incorrectly used IOTMTOTL in the equation. Values from minus 20 seconds to plus 20 seconds are found occasionally, where minus 20 means that the DD segment IOTM was greater than the SMF30AIC DASD connect time.
EX102367 creates T102S377 dataset. EX102374 -Support for (HEADER ONLY) all of these new ID=102 IFCIDs EX102375 that are documented in DB2 V11; EX102376 367 374 375 376 378 379 382 383 384 385 386 397 EX102377 398 399 499 EX102378 Actual data records are required to decode new IFCIDs, EX102379 but by adding the structure for all of these possible 102 EX102382 subtypes, only VMAC102 itself will need to be updated to EX102383 decode the IFCID-unique variables in these records. EX102384 EX102385
EX102386 EX102397
EX102398 EX102399
EX102499 IMAC102
VMAC102 VMXGINIT
Dec 28, 2013 Thanks to Paul Walters, Navy Federal Credit Union, USA. Change 31.277 TYPE30MU dataset now has zero obs by default. It is not EXTY30MU actually used by IBM SCRT nor MXG for analysis, it can be Dec 26, 2013 very large, because it replicates product segments in the same interval, and because if you really need it, it can be easily enabled, by removing the comment block in the EXTY30MU exit member in your "USERID.SOURCLIB" tailoring. Change 31.276 UTILBLDP is the RECOMMENDED ad hoc tool to read SMF data. UTILBLDP New WANTSMF="list of ID.SUBTYPE" provides easier syntax Dec 26, 2013 for selection of ID/SUBTYPES you want to be read. You select the PRODUCTS with BUILDPDB=YES or USERADD=n m z. You then use either WANTSMF= to select the ones you want, or you use the existing ZEROOBS= to alternatively force the unwanted subtypes to have zero observations. %UTILBLDP(BUILDPDB=NO, USERADD=42 7072 71 73 74 CMF, WANTSMF=42.6 70.1 73 74.1 74.5 74.6 240); %INCLUDE BUILDMXG; Generally, you can use the argument with fewer arguments, but to use ZEROOBS correctly you must know all subtypes in advance, while using WANTSMF= you only need to list the ID.SUBTYPEs you know about and want. Thanks to Pat Artis, Performance Associates, Inc., USA. Change 31.275 Spurious DATASET T102S225 DOES NOT EXIST messages are READDB2 corrected for that archaic dataset, populated only with VMACDB2 DB2 V8, where it is written as ID=102 SUBTYPE=IFCID=225, Dec 25, 2013 and thus read with %READDB2. Instead, in DB2 V9 plus, Dec 26, 2013 IFCID=255 is written as ID=100 records and read with TYPEDB2/BUILDPDB. In all versions, however, all QW0225xx variables are output in the PDB.DB2STATS dataset, which contains all interval statistics -MXGNOTEs listing the Subtypes/IFCIDS wanted are revised.
VMAC7072 calculations were wrong, with values like weights instead Dec 21, 2013 of the expected percentages. The test that deletes 'IFL' now also delete 'ICF's from weight calculations. Thanks to Stephen Hoar, Lloyds Banking, ENGLAND.
ADOCRMFV subtype 5 records to the RMF III VSAM file with the same ASMRMFV metrics as RMF I SMF records, but with more granularity ASUMCACH (typical 1 minute RMF III INTERVAL and yet take less DASD EXZRB74C space (only active devices are written in the one-minute EXZRB74I III records, while all devices are written to RMF I SMF). EXZRBCAT (Note: MXG outputs ONLY active devices so the output size IMACZRB per interval will be the same.) This support creates the VMACRMFV new ZRB74CA dataset, instead of naming it TYPE74CA, since VMXGINIT archaic variables from segments that no longer exist are Dec 23, 2013 not kept, but all other variable names are the same. Dec 28, 2013 -ASUMCACH will now read either SMF TYPE74CA or RMF ZRB74CA to create PDB.ASUMCACH, looking for ZRB74CA first.
-The RMF Monitor I parameters CACHE and ESS must also be in effect on the same system with the RMF Monitor III CACHE parameter. The RMF Monitor I defaults are CACHE and NOESS. -If ESS is not in effect for RMF Monitor I on the cache collection system the related PDB variables will be missing values (in both TYPE74CA and ZRB74CA). -From Newsletter FIFTY: 14. Specifying the RMF Monitor I CACHE Option in only one SYSTEM's RMF parameters eliminates redundant records on other systems and has been always recommended. There are other RMF Monitor I options, ESS(RANK) and ESS(LINK) and FCD along with CACHE that should all be in one, and the same, SYSTEM, per these IBM suggestions: ESS(RANK) - Link performance statistics are gathered. ESS(LINK) - Extent pool statistics and rank statistics gathered. As ESS data gathering involves cache activity measurement, it is recommended to specify both options in common. If you specify ESS together with NOCACHE, cache data is gathered implicitly without writing SMF 74.5 records! In a SYSPLEX, options CACHE and ESS can be specified on any system sharing the measured devices. Therefore specify the ESS and CACHE options together on one selected system only to avoid duplicate data gathering. CACHE - Create SMF 74.5 TYPE74CA Cache Statistics IMPORTANT: CACHE is the DEFAULT option IBM sets in RMF Monitor I, so you MUST then ADD a statement with NOCACHE in RMF parms for all but that one SYSTEM.
practical use are now supported by MXG. -Creating readable 74.5 records from the RMF III VSAM was non-trivial in ASMRMFV, because those records can be more than 32K bytes in the VSAM file, so longer records needed to be broken into shorter, but complete, records. -New ASMRMFV parameters CAT (alias H) and NOCAT (aliases -CAT, -H) are provided to select or filter CATG3 table data respectively. -ASMRMFV messages RMFV036I and RMFV105I are updated to show CAT table information. -ASMRMFV validates the CAT header and each SMF Type 74.5 record contained in the CAT table. -Initial ASMRMFV assembly environment message RMFV000I is revised to show the assembly date as a Julian date, as a date in ddmmmYYYY format, and as the 3 character day of the week. -The ASMRMFV source code prologue as well as the ADOCRMFV documentation member are updated appropriately. -REQUIREMENT: In order to receive these improvements the current ASMRMFV utility program from this MXG change must be installed. See MXG SOURCLIB member JCLASM3 for sample JCL for the assembly and link-edit install steps. -Only data for active devices is collected which means that for some Subsystem IDs (SSIDs) all device data variables in the PDB could be missing for some RMF III MINTIME intervals. -Cache Controller data is gathered by individual device address. There is no indication of which system in the sysplex initiates a recorded event. Therefore, the data can be gathered on any system sharing the cached devices. -Avoid unnecessary high CPU utilization and duplicated data by gathering cache activity data on only ONE system per IBM documentation for either RMF Monitor I or RMF Monitor III. -Use the RMF Monitor I and RMF Monitor III parameter NOCACHE to suppress cache data collection on all other systems.
-Use CACHE(ssid1,ssid2,..,ssidn) in RMF Monitor III to collect data for only those Subsystems needed. RMF Monitor I does not support selection by SSID. -Selection by Subsystem ID may also be needed if not all subsystems are shared. In this case cache data collection will be needed on more than one system. -Consult the section "Generalizing Parmlib Members" in the IBM RMF User's Guide for your z/OS level for a method to control selection of which system records cache data. Other approaches are certainly possible with system automation tools. -The best choice for a cache data collection system is one with high uptime that is not already CPU stressed. z/OS systems operating as z/VM guests will not record cache data even if requested.
format of YYYY.DDD are enhanced to show the date as DDMMMYYYY and a 3 character day of the week. -11 messages are updated to have the improved date display: RMFV000I, RMFV001I, RMFV006I, RMFV008I, RMFV012I, RMFV013I, RMFV023W, RMFV025I, RMFV026I, RMFV032E, and RMFV034I. -Message RMFV008I showed an incorrect creation date when a non-VSAM data set was supplied in error for a RMF III VSAM data set. The creation date in this case will not be shown. -DSNAME= in the RMFV008I message is now abbreviated to DSN= to conserve line space. -1ST VOL= in the RMFV008I message is now abbreviated to VOL= to conserve line space. It continues to show the first volume for a multi-volume file.
VMACDB2 INPUT EXCEEDED RECORD error that this change circumvents Dec 19, 2013 while the problem is investigated. The triplets for the QBAC and QTXK segments are reversed, and their count does not always match the count of QPAC segments.
VMAC42 CI*SPLITS in TYPE42S1-S4 and TYPE42D1-D datasets: Dec 19, 2013 S1: SMF42FSA SMF42FSB S2: SMF42FTA SMF42FTB S3: SMFA2FSA SMFA2FSA S4: SMFA2FTA SMFA2FTB D1: SMF42GTA SMF42GTB D2: SMF42GSA SMF42GSB D3: SMFA2GTA SMFA2GTB D4: SMFA2TSA SMFA2GSB Change 31.270 Cosmetic. MXG Error Messages with 'ERROR:' starting in VMAC28 byte one of the output are counted by SAS and flagged as Dec 19, 2013 an ERROR on that page, and text printed in RED on the SAS log, but that was not my intention, and these members are corrected so that 'ERROR:' does NOT start in column one: VMAC28 VMAC102 VMAC110 VMAC113 VMACDB2 VMACHURN VMACNMON VMACVMXA VMACXAM Most of the "actual" error conditions detected by MXG are printed 'MXGERROR: ' but there is a lack of consistency. Thanks to MP Welch, Bank of America, USA. Change 31.269 -If you specified "a small number" of IFCIDS, they weren't READDB2 sorted into the output PDBOUT libname because of an Dec 19, 2013 incorrect compare for GT 1 that should have been GT 0. Dec 23, 2013 Probably caused by Change 31.128 (MXG 31.05). Dec 25, 2013 -If you ran ANALDB2R with PDB=SMF and PDBOUT= was NOT set to PDB, a U1950 ABEND was generated by VGETOBS if the PDB libname did not exist in your SAS session. Caused by the PDB2225 macro variable default of PDB and ANALDB2R did not reset the value to the value of PDBOUT argument. -Messages about datasets not being deleted were deleted. Thanks to Paul Walters, Navy Federal Credit Union, USA.
VMXGRMFI as TIME12.2 since none are durations: Dec 18, 2013 OTHRSWAP OTHRTRAN OTHREXCP OTHRWKST OTHRSERV OTHRPGIN TSO2SWAP TSO2TRAN TWO3SWAP TSO3TRAN TSO4SWAP TSO4TRAN TRIVTRAN TRIVSWAP Those variables have been buried in &R72VAR for a long time and it was in the TIME12.2 format statement. Thanks to Robert Chavez, Florida Power and Light, USA. Change 31.267 Messages that there are 0 OBS or dataset was not found VGETOBS are suppressed when dataset=_ALL_ is specified. Dec 18, 2013
VMAC7072 -In TYPE72GO dataset, MSU and Service units are the old Dec 18, 2013 and original "Hardware MSU based on SU_SEC/R723MADJ. Feb 3, 2016 -Variable SERVICE in TYPE72GO dataset is the sum of these FIVE components CPUUNITS SRBUNITS MSOUNITS IOUNITS ZIPUNITS. (some old MXG notes have only the first four listed but ZIPUNITS have always been included in SERVICE). -Variable MSU72 is CPUTM*SU_SEC/1E6, "Hardware MSU", which includes ALL of the recorded CPU times in the Service Class 72s. This is the amount of MSU that were consumed by this Service Class/Reporting Class during this interval, based on SU_SEC. -The MSU units in the TYPE70 MSU variables are "Software" MSU based on the (smaller value) in CECSUSEC/SMF70CPA. (because they are now used for "SOFTWARE PRICING"). -Current SMF70CPA=13,000 and SU_SEC=26,000 is an example. -Text revised, Feb 3 2016: TYPE72GO variable MSUSOFT was wrong, having but was revised in Change 34.010 and does now contain the Software MSU CECSUSEC/SMF70CPA based. Change 31.265 Variable STC13MRC='Y' was incorrect when STC13MNR='Y' VMACSTC should have been have been set, and STC13MNR='Y' never Dec 17, 2013 was set; MXG tested 00/01 instead of 01/02 STC13RCI. Thanks to Mike Jacques, BBand T, USA. Change 31.264 -NMON data for Red Hat Linux has new Data Group metrics EXNMONDG that create the new dataset VMACNMON DDDDDD DATASET DESCRIPTION VMXGINIT NMONDG NMONDG LINUX DATA GROUP METRICS Dec 17, 2013 -The BBBP Configuration Records have no text in common with the BBBP records previously supported so the NMONBBBPxxx datasets will not be populated at this time. If you can identify which BBBP data is important, I will update the MXG Support for those data. -Support for NFSCLIV4 record is supported with these new variables created in NMONNFS dataset: OPEN OPEN_CONF OPEN_NOAT OPEN_DGRD CLOSE SETATTR RENEW SETCLTID CONFIRM LOCK LOCKT LOCKU LOOKUP_ROOT RENAME LINK SYMLINK CREATE PATHCONF STATFS READLINK READDIR SERVER_CAPS DELEGRETURN GETACL SETACL FS_LOCATIONS Thanks to Florent Boulesteix, INOVANS partenaire CAAGIS, FRANCE. Change 31.263 -ERROR.VMACTPMX. VARNAME=$INCLAI NOT FOUND because the MXG VMACTPMX code for tokenid=51467 was $INCLA, which is now corrected Dec 17, 2013 to $INCLAI for the test; the variable INCLA is unchanged, Dec 18, 2013 but now will be populated. -ERROR.VMACTPMX. VARNAME=$DBS_SD-bar NOT FOUND creates new variable DBS_SDBA in TYPETPMX dataset. Thanks to Paul Volpi, UHC, USA.
ANALDB2R buffer calculations that could be repeated values. Values Dec 16, 2013 impacted were Seq prefetch, list prefetch, dyn orefetch, Dec 18, 2013 asycnh reads, hpool writes, hpool reads, hpool reads failed. -If you separated the larger datasets like DB2ACCT or DB2ACCTP into separate DDNAMES and used the DB2ACCT* parameters to point to those LIBNAMES, ANALDB2R did not find the datasets since it only looked in the LIBNAME pointed to by the PDB= parameter. Thanks to Jim Lazowski, Northern Trust, USA.
EX102370 (CLOSE TRACE DATASET) creates T102S370 and T102S371 data EX102371 sets. FORMATS
IMAC102 VMAC102
VMXGINIT Dec 13, 2013 Thanks to Lori Masulis, Fidelity Systems, USA. Thanks to Rachel Holt, Fidelity Systems, USA. Change 31.260 Variable HSMPLEX added to all reports and graphs and if ANALHSM you are on SAS 9.3 or greater ODS GRAPHICS are used for Dec 8, 2013 the graphs. A line plot was substituted for the bar chart where AVG/MAX values by function are being graphed and VMXGODSO/VMXGODSC were inserted to allow you to send the output to HTML or PDF. Thanks to Scott Barry, SBBWorks Inc, USA.
VMACDB2 DB2ACCT, DB2ACCTB, DB2ACCTP, DB2ACCTG, DB2ACCTR datasets VMACDB2H and is populated only for QWHCATYP=8 (DDF Connections). Dec 5, 2013 When the eight-byte text QWHSNID contains an IP address, Dec 15, 2013 eight EBCDIC text characters represent the four hex bytes ('A971896F' is 169.113.137.111)), but the VTAM NID must start with an alphabetic character, so those IP addresses that start with digits 0 thru 9 for the first nybble, the value in QWHSNID starts with 'G' thru 'P'. This encoding was found in a note about message DSNL030I. Thanks to Alyona Bertneski, JPMorgan, USA.
VMAC102 the QW0359xx variables in existing T102S359 dataset. Dec 3, 2013 QW0359DB='DATA*BASE*ID' Dec 12, 2013 QW0359FL='FLAGS' QW0359OB='INDEX*PAGE*SET*ID' QW0359PG='SPLITTING*PAGE*NUMBER' QW0359PT='PARTITION*NUMBER' QW0359TE='TIMESTAMP*AT ENDING OF*SPLIT' QW0359TS='TIMESTAMP*AT BEGINNING*OF SPLIT' -The new DB2 Statement ID variable is written to SMF as either a 4-byte binary or an 8-byte character field that are now formatted HEX8. for the numeric variables or are now INPUT as $CHAR8. and formatted $HEX16. for character QW0172TZ QW0172H9 QW0172W9 QW0196W9 QW0196H9 QW1196H9 QW2196H9 .. QW8196W9. QW0173CS QW0317ID Thanks to Rachel Holt, Fidelity Systems, USA. Thanks to Lori Masulis, Fidelity Systems, USA. Thanks to Paul Volpi, UHC, USA. Thanks to Giuseppe Giacomodonato, EPV Technologies, ITALY. Change 31.257 -INPUT STATEMENT EXCEEDED if TOKDANAM='UTYPE' was the last VMAC80A segment because MXG expected a 4-byte binary number but Dec 3, 2013 the field is a 1-byte EBCDIC &NUM1. field. -New variables decoded and labeled with variable name: TOKQUEST1 TOKQUEST2 TOKANS1 TOKANS2 TOKAD1 TOKAD2 TOKCOMPANY TOKCOUNTRY TOKFNAME TOKMNAME TOKLNAME TOKSTATE TOKWTEL TOKZIPCODE Thanks to Phil Grasser, Norfolk Southern, USA. Change 31.256 Cosmetic. INPUT for QPACLENX GE 428 actually read in 452 VMACDB2 so the INPUT is split to read thru 428 and then thru 452. Dec 2, 2013
VMAC74 exist and was a "copy down" typo when that code block was Dec 2, 2013 created; it is now deleted completely. See Change 33.155. SCM data is now in TYPE74ST dataset. Thanks to Giuseppe Giacomodonato, EPV Technologies, ITALY.
VMACBVIR
Nov 28, 2013 Change 31.253 -Change 30.078 corrected SMSGDHWM/SMSGCCUR for CICS/TS 4.1 VMAC110 and earlier but the change of multiplicand was still Nov 28, 2013 wrong for CICS/TS 4.2 and later. Thanks to Paul Volpi, UHC, USA. Change 31.252 -VMXGSUM. If a variable was missing in a NORMx parameter, VMXGSUM a warning was issued pointing to a variable name but not ASUM72GO to the specific NORMx parameter that was in error. The Nov 25, 2013 warning message is now enhanced to contain the full text of the NORMx parameter. -ASUM72GO. The DURATM variable was not in the SUM= list which raised a warning about a missing variable in NORM3.
FORMATS in statement in line 22864: Nov 22, 2013 PICTURE MGXLDATE OTHER='%0m/%0d/%0Y %0H:%0M:%0S' Oct 10, 2014 (DATATYPE=DATETIME); with "ERROR: Found "DATATYPE" when expecting ) because DATATYPE was not supported by WPS until their Version 3.1 And MWRTDT format added in MXG 32.09 also failed with WPS 2.05. MGXLDATE was never used and so it was removed. MWRTDT is required by MOBWRK06 MOBILE WORK Discount analysis to meet IBM's CSV file format. Thanks to Ken Drody, State of Delaware, USA. Thanks to Kre Martin Torsvik, EVRY AS, NORWAY. Change 31.250 A spurious MXGWARN when a libname had not been referenced VGETOBS led to a better way to identify TAPE data libraries and Nov 22, 2013 to enhance the elimination of tape mounts: If the LIBNAME has never been referenced: First record is read as an INFILE and engine type is identified so the LIBNAME can be issued with the appropriate engine. If this is a disk library it is NOT added to the list of DDs found on tape/sequential. If the DDNAME is on tape and SPINTAPE NE YES and DATASET NE _ALL_, OBS count is set to one and no further processing is needed. If SPINTAPE=YES or DATASET=_ALL_: All tape volumes are read to find all datasets and captured in MXGTABLES which is NOT deleted. If DATASET NE _ALL_, then also looks for this specific dataset in MXGTABLES, and will verify the dataset exists and determine an OBS count. Else if SPINTAPE NE YES and DATASET NE _ALL_ and the dataset is on disk, looks for the specific dataset without using MXGTABLES. This is also the behavior on ASCII as LIBNAMEs must have been identified to SAS with a LIBNAME statement. If a dataset does not exist or has 0 OBS the calling program may give you a message indicating the issue and then will die gracefully. The results are in global macro variables VGETDSN and VGETOBS. If VGETDSN is empty, the dataset did not exist. Thanks to MP Welch, Bank of America, USA. Change 31.249 These datetime variables were INPUT but not formatted or VMAC110 not LENGTH'd or were not kept, but no one had noticed, Nov 18, 2013 except for the MXG QA tests, so this is cosmetic. VMAC110 : DS7LSTRT DS7START VMAC74 : SMF74GIE VMAC75 : SMF75GIE VMAC76 : SMF76GIE VMAC77 : SMF77GIE VMACBBMQ: CHLTOD0 VMACCIMS: IMSSTCK VMACIMS : SYNCSTCK VMACIMSA: STSTARTTOD SYNCSTCK TPCPCLCK VMACOMCI: ESFTIME VMACOPC : MT0OCCTOK VMACROSC: TIME ==> Renamed to TEMPCKTI not KEPT VMACSMF : TESTTIME ==> Renamed to SMFTIME VMACSYSV: RTCLOCK RTCSTART SDCRETOD SCDRSTOD VMACTMMQ: LMRKTOD2 VMACTMNT: REND ==> Renamed to RENDTIME VMACTMO2: T2INEDTS T2INSDTS TMMDXSTK TXINEDTS TXINSDTS VMACTMV2: IPLTIME VMACVMXA: PLSFOB1T PLSFOBTM VMACXPSM: OUTGTIME
ANALGRID LASTWEEK, etc., a logic error occurred because &TO was a Nov 17, 2013 null value. Now, FROM=INPUT("&FROM",?? DATE.) is used so Yüklə 28,67 Mb. Dostları ilə paylaş:
|