* copyright (C) 1984-2019 merrill consultants dallas texas usa
Yüklə 28,67 Mb.
|
|
protect 1.9, 1.10 and 1.11 records, but only 1.10 and ancient 1.30/1.40 records are validated with SMF data. Thanks to Brian Felix, Wachovia Bank, USA. Thanks to Mike Spires, Wachovia Bank, USA. ====== Changes thru 27.195 were in MXG 27.07 dated Aug 11, 2009======== CHANGE 27.195 Documentation only. When IFCIDS=ACCOUNT is specified, READDB2 READDB2 automatically creates the DB2ACCTB dataset, but Aug 11, 2009 when BUILDPDB/TYPEDB2 is used, the EXDB2ACB exit is used. So if you (incorrectly) had a DELETE statement in your tailored EXDB2ACB member, the number of observations that were created in DB2ACCT/DB2ACCTB/DB2ACCTG were much less with BUILDPDB/TYPEDB2 than with READDB2. The EXDB2ACB exit is the ONLY DB2 exit that is overridden in READDB2. CHANGE 27.194 These variables from the LPAR Object in NMON/TAPAS record VMACNMON are now input and kept: Aug 11, 2009 CAPPED EC_USER EC_SYS EC_WAIT EC_IDLE VP_USER VP_SYS VP_WAIT VP_IDLE FOLDED POOL_ID Thanks to Steve Dyck, Canadian Depository for Securities, CANADA.
READDB2 sets to the PDBOUT= parameter, when it was used. Aug 11, 2009 Thanks to Thomas Heitlinger, FIDUCIA IT AG, GERMANY. Thanks to Sieghart Seith, FIDUCIA IT AG, GERMANY.
VMAC110 the first byte of the time part with 'EE'x, but CA is Aug 11, 2009 then supposed to correct that overlay in the SMF write exit, which requires specific code for each record type. Apparently, CA-7 has failed to protect the SMF 110s, but MXG detects now and corrects READTIME in SMF 110. Search CHANGESS for "UCC7" LAST for further info. Thanks to Marnel Groebner, State of Washingon, USA. CHANGE 27.191 Variable ACTVWSS, working set size, in dataset XAMUSR, VMACXAM was incorrectly multiplied by 4096; it is already in Aug 11, 2009 bytes, not KB, so the multiply was removed. Thanks to Chris Morgan, CitiCorp, ENGLAND. CHANGE 27.190 Dataset TMS.TMS observations with DEVTYPE blank were VMACTMS5 found with TRTCH='D0'x and 'EE'x, and TMS shows those Aug 10, 2009 as DEN 3590 and 3592, so those hex values are now mapped to the DEN values in DEVTYPE. Thanks to Scott Barry, SBBWorks, Inc, USA.
EXIOOVBU creates 10 datasets: EXIOOQBU EXIOORBL DATASET DATASET DATASET EXIOOVUS SUFFIX NAME LABEL EXIOOVRP
EXIOOVX1 IOOVBU IOOVBUF VSAM BUFFER OPTIMIZATION EXIOOVX2 IOOQBU IOOQBUF QSAM BUFFER OPTIMIZATION EXIOOVX3 IOORBL IOORBLK QSAM BLKSIZE OPTIMIZATION EXIOOVX4 IOOVUS IOOVUSR USER BLDVRP EXIOOVX5 IOOVRP IOOVRPB BLDVRP OVERRIDE FORMATS IOOVX1 IOOVEX1 OPT BYPASS AS PER RULES TABLE IMACIOO IOOVX2 IOOVEX2 OPT BYPASS NO RULES TABLE MATCH TYPEIOO IOOVX3 IOOVEX3 OPT BYPASS BUFFER CHANGE NOTAUTH TYPSIOO IOOVX4 IOOVEX4 OPT BYPASS JCL PARMS PRESENT VMACIOO IOOVX5 IOOVEX5 OPT BYPASS CSR FAILURE VMXGINIT Aug 10, 2009 CHANGE 27.188 MXG 27.04-27.06. When DB2STATS was enhanced to include VMACDB2 the IFCID=225 DB2STAT4 dataset, the BY list for the sort Aug 10, 2009 order for DB2STAT0 and DB2STAT1 was incorrectly changed, which could cause a NOT SORTED error in WEEKBLD/MONTHBLD. This change resets the sort order for DB2STAT0/DB2STAT1 to the expected SYSTEM QWHSSSID QWHSSTCK. The same order can NOT be used to create DB2STATS because the QWHSSTCK timestamp is not consistent in an interval; instead, SYSTEM QWHSSSID QWHSACE QWHSMTN QWHSISEQ must be used to create DB2STATS. If you encounter the NOT SORTED error, you can remove the BY statement in your WEEKBLD/MONTHBLD to circumvent. BUT: the better solution is to REMOVE DB2STAT0, DB2STAT1 and DB2STAT4 from your WEEKBLD and MONTHBLD, because they are completely contained in the DB2STATS dataset!
because they are already there, and removing them would create a bigger exposure to DATA SET NOT FOUND errors! Thanks to Wayne Bell, UniGroup, USA. CHANGE 27.187 In spite of my note in IMACICDL "beginning with IMS 5.1 IMACICDL CICS/TS 1.1+ do NOT support DL/1 calls from CICS" SMF 110 UTILEXCL records with the optional IMACICDL data segment can still VMAC110 be created, and with CICS/TS 3.2, it is INCOMPATIBLE due Aug 8, 2009 to the increase to 12 byte clock/counters. IMACICDL was revised to support both lengths, even though ALL of the fields in the IMACICDL segment are now ALWAYS zeroes. -UTILEXCL's generated KEEP= statement was updated to KEEP these variables, but ONLY so I could confirm the zeroes. -A DROP statement was added in IMACICDL so these variables will be dropped if you do have to tailor IMACICDL.
VMACWSF the ACCKTN Extension added in WSF 3.3.6 exists, caused an Aug 7, 2009 INPUT STATEMENT EXCEEDED RECORD LENGTH when it did not have the minimum-length-20-byte segment present; MXG now tests that both that bit is on, AND that 20 bytes of data actually exists before inputting the extension fields. Thanks to Norm Folkers, CGI, CANADA.
VMAC74 TYPE74DU/XTY74DU was incorrectly divided by 10**(-6); it Aug 7, 2009 was already converted to microseconds in the INPUT and should not have also been divided. Thanks to Yacine Amraoui, La Banque Postale, FRANCE.
VMACNTSM dddddd Dataset Description/Object Name Aug 7, 2009 NTVWGC VMWGUCPU VMWARE.GUEST.CPU NTVWGD VMWGUDIS VMWARE.GUEST.DISK NTVWGM VMWGUMEM VMWARE.GUEST.MEMORY NTVWGN VMWGUNET VMWARE.GUEST.NET NTVWGR VMWGURES VMWARE.GUEST.RESCPU NTVWGS VMWGUSYS VMWARE.GUEST.SYS NTVWHC VMWHOCPU VMWARE.HOST.CPU NTVWHD VMWHODIS VMWARE.HOST.DISK NTVWHM VMWHOMEM VMWARE.HOST.MEMORY NTVWHN VMWHONET VMWARE.HOST.NET NTVWHR VMWHORES VMWARE.HOST.RESCPU NTVWHS VMWHOSYS VMWARE.HOST.SYS NTVWRP VMWREPOL VMWARE.RESOURCEPOOL and support for new objects ASP.NET V2.0.50727 and ASP.NET APPS V2.0.50727 which are output in existing ASPNET and ASPNETAP datasets. CHANGE 27.183 The Diagnose Instruction variables added by Change 26.203 VMACVMXA were only INPUT and not kept in z/VM dataset VXPRCDIA. Aug 6, 2009 Thanks to Jim Dammeyer, State Farm Auto, USA. CHANGE 27.182 Support for optional, user-created, CICS REQCNT1 field. IMACICUE
VMAC110 UTILEXCL
Aug 6, 2009 Thanks to Leendert Keesmaat, UBS, SWITZERLAND. CHANGE 27.181 Support for VOLSER='SCRTCH', a previously unseen (or not ASUMTAPE noticed value for VOLSER), which has to be added to the Aug 5, 2009 existing exceptions for VOLSER='PRIVAT'. Mounts with the VOLSER='SCRTCH', either in the TYPETMNT Mount dataset or the TYPESYMT SYSLOG dataset, were not matched with their TYPE21 (because it always has the resultant VOLSER). Thanks to Scott Barry, SBBWorks, Inc, USA.
VMACNMON TOPAS (originally NMON, Nigel's Monitor for AIX/LINUX) Aug 5, 2009 adds six variables from each into NMONINTV dataset: Aug 7, 2009 PPHYBUSY PPHYIDLE PPHYSYS PPHYUSER PPHYWAIT NRPHYS PNTIBUSY PNTIIDLE PNTISYS PNTIUSER PNTIWAIT NRNTIS -MEMUSE record with invalid numeric value 0.275.9 in the last field causes two harmless messages to be printed: INVALID ARGUMENT TO FUNCTION INPUT. and variable MUMAXCLI will have a missing value. -INVALID ARGUMENT messages for RECTYPE='RAWCPUTOTAL' were corrected; right hand argument of WORD2 test needed to be in all upper case. Thanks to Steven Olmstead, Northwestern Mutual, USA.
TYPETMS5 to debugging comments that should have been removed. The Aug 5, 2009 14 datasets required over 6400MB with a 700MB TMS input. Thanks to Jim Kovarik, AEGON, USA. CHANGE 27.178 ASUM70PR with STARTIME=16:29:59 (instead of 16:30:00) was VMXG70PR incorrectly reset to 16:15 when INTERVAL=QTRHOUR was used VMXGRMFI and this created an obs with DURATM=30 minutes instead of Aug 5, 2009 the requested 15 minute summarization (fortunately, all data values in that observation ARE correct!). STARTIME has always been used for MXG RMF summarization, because the only other original choice, SMFTIME, was inexact, as write delays could cause it to be in the next hour, etc. But now, SMF70GIE, the expected, exact, end of interval, always exists in current RMF/CMF records, so it is used to define the interval when INTERVAL="value" is specified so STARTIME can then be exactly reset SMF70GIE-MXGDURTM. SMF70GIE is already used elsewhere in VMXG70PR, but not in the STARTIME reset algorithm. If SYNC59=YES was accidentally specified (not needed here because the RMF data was written with SYNC=0), STARTIME was set to 16:30 instead of 16:15, and the 30 minute obs was accidentally NOT created. Why the STARTIME is one full second earlier instead of exact is not known, but this system was a 2094-709 with VERSNRMF 750, and IRD was not active. -RMFINTRV was revised to also set STARTIME from SMF70GIE, so there should always be a perfect match between the PDB.RMFINTRV and PDB.ASUM70PR values. But NOT with INTERVAL=DETAIL or INTERVAL=DURSET: MXG Only Resets the STARTIME to "clean" values when you specify an INTERVAL= "duration" (QTRHOUR,HOUR,etc). Thanks to Douglas C. Walter, Citigroup, USA. Thanks to Brent Turner, Citigroup, USA.
VMACITRF incorrectly formatted $HEX24; it is now correctly format Aug 4, 2009 with $HEX32 to set its stored length as 16 bytes. Thanks to Shantha Hallett, Capgemini UK, WALES. CHANGE 27.176 -MXG support for IMF 4.4 was incorrect for these variables VMACCIMS that were previously binary with varying resolutions but Aug 5, 2009 were changed in 4.4 to floating point microseconds: TRNW1OTH TRNW2OTH TRNW2LCH TRNW2IOV TRNW2IOO TRNW3OTH TRNW3LCH TRNW4OTH TRNW4DBR TRNW4IO TRNW5OTH TRNW5LCH TRNW5LCK TRNW5IOV TRNW5IOO TRNW5IOD TRNEAPPL TRNEDLTM TRNEDLDB TRNEDB2 TRNEMQS TRNEOESS TRNEOPCL TRNESYNC -Records with LTERM values that are neither EBCDIC nor ASCII ('EE4A80B18DDDDEEA'x) print funny-looking text. Using FORMAT LTERM $HEX16.; will show that hex value, but that makes the true printable text unreadable. Not really a problem, mostly an observation. -BMC PTF BQI0695 corrects an error in which a DBD segment could be overlaid with zeros. This was detected because SQLCALL='Y' (the transaction called DB2), but SQLCALLS (the sum of calls in all DBD segments with DBORG='80'x) was a missing value. Any transaction with SQLCALL='Y' must have at least one DBORG='80'x DB2 DBD segment. Thanks to Thomas Heitlinger, FIDUCIA IT AG, GERMANY. Thanks to Sieghart Seith, FIDUCIA IT AG, GERMANY. CHANGE 27.175 -ANALDB2R detected but did not tolerate the absence of the ANALDB2R DB2STATB dataset. Jul 31, 2009 -Aug 9: ANALDB2R now honors DB2STATB/DB2STATS parameters Aug 9, 2009 and new DB2GBPST parameter is added. Thanks to Scott Wiig, USBank, USA.
VMACDB2 they should not have been, as they are end point values. Jul 30, 2009 CHANGE REVERSED: SEE CHANGE 27.207. Thanks to Ray Dunn, CIGNA, USA. Thanks to Deborah L. Soricelli, CIGNA, USA.
VMACDB2 be replaced by the correct spelling, as other programs in Aug 5, 2009 MXG and in user programs may use the incorrect spelling, so these new (correctly spelled) variables are created: QBGLWM QXXCBPNX QXXCSKIP QXCRINX with the same contents and labels as the incorrect ones: QBGLMW QZZCBPNX QZZCSKIP QXCRINDX Thanks to Tony Curry, BMC, USA. CHANGE 27.172 Most tests for IF xxxxxxxx NE 0 THEN were revised to test ANALDB2R IF xxxxxxxx GT 0 THEN because missing-value variables are Jul 29, 2009 true with NE 0 but in most cases that is not wanted. Each test must be examined to see if xxxxxxxx can be missing, and to confirm that the true value wanted was only GT 0. This prevented divide-by-zero error messages. CHANGE 27.171 MXGTMNT records INPUT is now protected if the same SMF VMACTMNT record number is also used by another product's record, Jul 28, 2009 by verifying that TMNTSYS='TMNT'; when duplicate use of the TMNT record ID is detected, two instances are now printed on the log with a hex dump so you can identify the other product "sharing" the TMNT record ID. Thanks to Linda Pitcher, Progressive, USA.
CLEARDB2 both the existence of datasets and expected observations TESTREAL with the known SMF input file of DB2 data. READDB2 is Jul 25, 2009 re-executed multiple times, so resetting of all of the old-style macros for DB2 is required prior to each; the static reset was stored in new member CLEARDB2 for reuse. CHANGE 27.169 MXG 27.04-27.06. READDB2 did not output to any T102Snnn. READDB2 The error was introduced in MXG 27.04, and while READDB2 Jul 25, 2009 is tested in the QA stream, the tests were for existence, and did not verify actual observations were created. Thanks to Alex Macfarlane, BNY Mellon, USA.
TYPETMS5 _KTMSTMS token that should have been after line 188; the Jul 24, 2009 token is used by ITRM to add variables for TMS. Thanks to Rob D'Andrea, CIS, ENGLAND. ====== Changes thru 27.167 were in MXG 27.06 dated Jul 20, 2009======== CHANGE 27.167 Minor. %READDB2... did not honor OPTIONS OBS=5000 because READDB2 a RUN; statement was required to separate the execution Jul 21, 2009 of the DATA step from subsequent %VGETOBS existence tests VMXGOPTR (for IFCIDs 105/107). In %VGETOBS execution, the first Jul 22, 2009 %VMXGOPTR with "OPTION=OBS,NEWVALUE=MAX", (needed so the PROC SQL can function even if the user has set the option OBS), was being executed before the DATA step that reads the SMF data. The RUN; in READDB2 cured its problem, but a more generic solution was to insert a RUN; statement at the top of VMXGOPTR to protect it for all calls. CHANGE 27.166 CA-VIEW SARSRQUX exit SMF record was completely changed. VMACSARX The new layout of the fixed portion is now supported, but Jul 21, 2009 the Fixed JCL Attribute segment does not exist in my two Oct 4, 2009 test records, and the Variable JCL Attribute segment is not populated, so those segments are not yet INPUT, which causes many, but harmless, UNINITIALIZED VARIABLE notes on the log. Oct 4: UNINIT messages removed. Thanks to Bob DeBartolo, Conseco, USA. ====== Changes thru 27.165 were in MXG 27.06 dated Jul 20, 2009======== CHANGE 27.165 -VMXGSUM now dies gracefully with an MXGERROR message when ANALACTM the input dataset does not exist; before, it still died, ANALCNCR but the cause of death was unknown to the user. This can ANALINIT happen if you include an ASUMxxxx or TRNDxxxx but you had BLDNTPDB not created the expected input datasets. VMXGSUM works UTILCONT fine if the dataset exists and has zero observations. UTILVREF -ANALCNCR modified to fail before calling VMXGSUM if the UTILXRF1 input dataset does not exist. VGETDDS -VGETOBS was revised to protect when OPTIONS OBS=0 is in VGETDSN effect; the PROC SQL used to determine if the dataset has VGETENG observations did not execute, so VGETOBS falsely reported VGETOBS the tested dataset did not exist, when in fact it did. VMXGENG Calls to VMXGOPTR were inserted to store the current OBS VMXGOPTR option in effect, set OBS=MAX for the PROC SQL, and then VMXGSIZE restore the original option with a second VMXGOPTR call. VMXGSUM But this instance of this exposure caused examination of VMXGUOW all MXG code that uses PROC SQL, so these members have Jul 17, 2009 also been protected to execute properly with OBS=0 set: ASUMCACH ASUMCACH BLDNTPDB UTILCONT UTILVREF UTILXRF1 VGETDDS VGETDSN VGETENG VMXGENG VMXGSIZE VMXGUOW Setting OPTIONS OBS=0; is a quick way to test SAS code for any SAS syntax errors, and as all datasets are also created, subsequent references to datasets or variables are validated, but no records are read and no disk space is used since all datasets have zero observations. An alternative technique is to use a DUMMY input file. -VMXGUOW %VMXGOPTR calls balanced for default NOOBS zero. -VMXGOPTR modified to UPCASE the parameters. -ANALINIT protected with NODSNFERR/NOVNFERR, and is now a self-executing %MACRO. -ANALACTM. Some headings ran together & the response time goals went into exponential notation. ANALACTM gives you a visual picture of your WLM definitions. -Aug 12, 2009: VGETOBS defined a new argument, NOEXIMSG. CHANGE 27.164 NOTE: NUMERIC VARIABLE CONVERTED TO CHARACTER in TIMEBILD TIMEBILD happens to be harmless, but because it raised questions Jul 15, 2009 (Why? Impact?), it is now eliminated. The culprit was the CALL SYMPUT("MXGTIMES",SYS); where SYS was a numeric count, and %MACRO variables must be character. Inserting SYST=PUT(SYS,2.); to create character variable SYST, and using SYST in place of SYS eliminated the message. Thanks to Paul Volpi, UHC, USA. CHANGE 27.163 Eight BVIR variables are converted to bytes and FORMATed VMACBVIR MGBYTES, and *KB in their label is replaced by BYTES to Jul 15, 2009 be consistent with the other byte-containing variables: P0CHRD ='HBA*PORT 0*CHAN*READ*BYTES' P0CHWR ='HBA*PORT 0*CHAN*WRITE*BYTES' P0VDRD ='HBA*PORT 0*VDEV*READ*BYTES' P0VDWR ='HBA*PORT 0*VDEV*WRITE*BYTES' P1CHRD ='HBA*PORT 1*CHAN*READ*BYTES' P1CHWR ='HBA*PORT 1*CHAN*WRITE*BYTES' P1VDRD ='HBA*PORT 1*VDEV*READ*BYTES' P1VDWR ='HBA*PORT 1*VDEV*WRITE*BYTES' Thanks to Perry Lim, Union Bank, USA. CHANGE 27.162 Support for BMC APPTUNE SQL IFCIDS=8004x-8136x as SMF 102 EX102S04 records create these eleven new datasets: EX102S05 EX102S07 DDDDDD DATASET DESCRIPTION/IFCID EX102S08 102S04 T1028004 102S04: BMC SQL APPTUNE 8004 EX102S09 102S05 T1028005 102S05: BMC SQL APPTUNE 8005 EX102S0A 102S07 T1028007 102S07: BMC SQL APPTUNE 8007 EX102S0B 102S08 T1028008 102S08: BMC SQL APPTUNE 8008 EX102S33 102S09 T1028009 102S09: BMC SQL APPTUNE 8009 EX102S34 102S0A T102800A 102S0A: BMC SQL APPTUNE 800A EX102S35 102S0B T102800B 102S0B: BMC SQL APPTUNE 800B EX102S36 102S33 T1028133 102S33: BMC SQL APPTUNE 8133 IMAC102 102S34 T1028134 102S34: BMC SQL APPTUNE 8134 READDB2 102S35 T1028135 102S35: BMC SQL APPTUNE 8135 VMAC102 102S36 T1028136 102S36: BMC SQL APPTUNE 8136 VMACDB2H
VMXGINIT 102BMC Creates all of the above Jul 15, 2009 All eleven BMC T1028xxx datasets are created together, with a single macro token dddddd=102BMC. Separate dddddd tokens for each IFCID/dataset are not defined, as I decided you'd want all eleven or none. You can create only those eleven BMC T1028xxx datasets using %READDB2 %READDB2(IFCIDS=BMC); Or, if you create all possible T102 datasets using either %INCLUDE SOURCLIB(TYPE102); or %READDB2(IFCIDS=ALL);, all 350 IBM T102Snnn and the 11 BMC datasets will be created. -While many of the fields are from standard IBM DB2 DSECTS QWAC, QBAC, QTXA, QXST, and QWAX, all variable names in the BMC T1028nnn datasets start with QBMCxxxx, so there is no collision/conflict with the existing MXG names. -Note that variables QBMCEJST and QBMCESC are different from the IBM QWACEJST/QWACESC fields; BMC stores the accumulated total measured time for the statement rather than the end time for one execution in both.
VMACDB2 NRQPAC GT 1, only in 2nd and subsequent obs per record. Jul 13, 2009 The DB2ACCTP Package obs contain either both QBAC & QXPK segments (when Class 10 is enabled) or neither (if not); if on, there is one QBAC and one QXPK segment per QPAC, MXG outputs the first set in the first obs, the second set in the second obs, etc. However, DB2 V9 IFCID=239 (ID=101,Subtype=1) records with more than one NRQPAC had incorrect QXPK variable's values in 2nd-plus obs, due to MXG incorrect logic test for =0 instead of LE 0 (and a typo) in its handling of the new DB2 V9 lengths: In DB2, IBM stores a zero in the length field in the "triplet", and the triplet's offset now points to the two-byte location with the actual field length, at the start of that segment's data. But only sometimes!
ASUMTAPE by Change 26.038 (MXG 26.03), but was expected in ITRM. Jul 10, 2009 It is now kept again with the beginning datetimestamp of the mount event. Thanks to Don Bernard, North Carolina State Government, USA.
VMAC62 unintentionally prevented OPENTIME and ACBMACR1-ACBMACR4 Jul 9, 2009 from being input. The OSI test is no longer needed as space for all three fields are always present, so it was removed. And because the MGT/STR/DAT can contain '00'x, those values were translated to blanks. Thanks to Sam Bass, McLane Co., USA.
VMACDB2 it is fully implemented. Progress is documented below. VMACDB2H If DB2 zparm UIFCIDS=YES is set, many DB2 character vars VMAC102 will contain ASCII instead of EBCDIC text. These fields Jul 8, 2009 are identified as "%U" in the IBM DSECTs; technically the fields contain UNICODE, UTF-8, which is simple ASCII. Each of these "%U" fields has its original fixed-length location (that MXG continues to INPUT, but conditionally INPUTs ASCII or EBCDIC), but if the text length is longer ("truncated" to that fixed-length), a new offset points to the length and location of the "un-truncated" text, which is then conditionally input with the longer length. Yüklə 28,67 Mb. Dostları ilə paylaş:
|