* copyright (C) 1984-2019 merrill consultants dallas texas usa
Yüklə 28,67 Mb.
|
|
Individual Buffer Pool Statistics for EACH Buffer Pool are available in the DB2ACCTB and DB2STATB datasets. -New DB2ACCTR dataset is created with an observation for each QLAC segment (for each Remote Location) in the Accounting Records. The QLACxxxx variables in DB2ACCT were previously from the first QLAC segment, but with this change, those variables will be from the last one. With hindsight, had I known there could be multiple QLACs in an accounting record, I would have created ONLY this DB2ACCTR dataset and would have not kept any QLACxxxx variables in DB2ACCT. If there was only one Remote QLAC segment, then there is no change in DB2ACCT. *-All summarization of DB2ACCTx datasets now performed by new VMXGDBAA internal macro, called by ANALDB2R and ASUMDBxx and TRNDDBxx, replacing ASUMDB2A and ASUMDB2B. *-All summarization of DB2STATx datasets now performed by new VMXGDBSS internal macro, called by ANALDB2R and ASUMDBSS and TRNDDBSS. *-If you use the new ANALDB2R against old PDBs that do not contain ASUMDBAA or ASUMDBSS datasets, the FIXDB2A can be used to report from old ASUMDB2A/TRNDDB2A datasets, as close as possible to the new architecture, but many new report fields will be missing.
-Number of SORTBY= variables for PMACC02 increased to 12. -Reports now as close to current as V7 DB2PM documents. -Future maintenance greatly simplified. -In prior releases if you asked for both PMACC01 and PMACC02 the input data was summarized twice. Now only one summarization is needed. -PMACC01/PMACC02 will look for the ASUMDBAA or ASUMDBSS datasets and use them instead of the detail DB2ACCTx or DB2STATS dataset if they exist. -The original version of the accounting long report was written to output a full line at a time with a _NULL_ data step. But, DB2PM was written in sections and IBM could insert lines in different sections with each new release making maintenance a real nightmare. Inserting a line in one section could result in touching hundreds of lines of the code. PMACC02 is completely rewritten using the same structure - in sections - and outputs a page at a time rather than a line, which should make future enhancements much simpler. Code comments indicate what section is being invoked. -And PMACC01 was rewritten, although it remains a line mode coding and report. All four Accounting reports PMACC01/PMACC02/PMACC03/PMACC04 use the same inputs, and new VMXGDBAA summarizes all accounting data with datasets held in work to avoid an unneeded, now, resummarization. -Numerous glitches were found in the logic to create the PDB.DB2STATS dataset (from DB2STAT0/1/4/T102S225) that have been corrected. - GMTOFFDB calculation occasionally returned -14399.99 instead of -14400 due to the different resolutions of QWHSSTCK (microseconds) and SMFTIME (10 milliseconds) and truncation in the floating point representation. GMTOFFDB algorithm enhanced to force exact hour. This error caused the Local Time QWHSSTCK in DB2STAT0 to be later than the Local Time QWHSSTCK in DB2STAT1, which caused me to believe that was an IBM error, until I was corrected by DB2 Support that the subtype 0 is ALWAYS written first in each interval (when QWSDRINV is '10'x, timer caused record to be written). - Logic in VMACDB2H to force QWHSSTCK to be the same for each interval as SMF records were read was invalid when multiple subsystems records were simultaneously written with all the subtype 0's in a group, then their 1's. Logic was removed, so the PDB.DB2STAT0/1/4 QWHSSTCK are now the actual value in those datasets. In PDB.DB2STATS the value from DB2STAT0 is propagated, and DB2START is created with the "start time" of each stat interval. -NETSNAME construction was revised to test for FIRST8 to also test LOCPERIO EQ 0 to populate NETSNAME correctly when there was no period in the QWHCTOKN. -VMACDB2 corrected: DB2 V9.1 data with more than one QLAC segment caused "BAD TMON SUBTYPE 101 RECORD" message but the record was IBMs and the error was mine. Length when there length in header was zero was not handled correctly for the second and subsequent QLAC sections. Change 28.145 Cosmetic. Enabling SAS Option MSGLEVEL=I printed four VMAC7072 INFO: messages that are now eliminated just to avoid VMXG70PR confusion, as, (fortunately) there was no actual problem. Jun 28, 2010 I have also added MSGLEVEL=I to the QASAS job. Thanks to Al Sherkow, I/S Management Strategies, Ltd., USA.
VMXGPRNT variable name and variable label as headers is enhanced Jul 4, 2010 to allow you to select which variables are printed. Thanks to Tom Kelman, Commerce Bank of Kansas City, USA. Change 28.143 Support for z196 processor. This Change is REQUIRED FOR VMAC7072 more than 64 engines, and the support was in MXG 28.04. Jul 4, 2010 See Change 28.175 for full documentation, and more. Change 28.142 Variable VMAC7072 SMF70NCA='PCT WHEN*CAPPING*LIMITED*THIS ENGINE' Jun 23, 2010 is now kept in TYPE70 dataset. Thanks to Deb Soricelli, CIGNA, USA.
UTILEXCL now be in a comment in the IMACEXCL member it creates. Jun 23, 2010
ASUM113 -TYPE113 now creates one obs per interval, with all four VMAC113 sets of counters in one observation (instead of four obs, Jun 23, 2010 each with one set of BASIC/PROGST/CRYPTO/EXTND counters). Jun 28, 2010 -With all four counter sets in one obs, missing values in variables added in Change 28.075 are eliminated. -New variable SM113STM, Interval Start Time is created. -New variable MIPSEXEC, Executed Million Instructions/sec is created (but don't expect it to match published MIPS "speed" values). (Thanks: Peter Enrico). -The _STY113 dataset sort macro now tests //WORK and //PDB and if TYPE70PR exists, adds variables CPUTYPE (2098), SMF70CIN (Engine Type), CECSER, LPARWLMG (IRD FLAG), SMF70CPA (SU_SEC), SMF70HDM (HiperDispatch Active?), and SMF70CIX (Pool Number) to enhance PDB.TYPE113 dataset. -New ASUM113 accomplishes the same enhancement as _STY113, enhancing PDB.TYPE113 with those variables from TYPE70PR, if you have old TYPE113 and TYPE70PR in the same PDB. -The TYPE113 records are not synchronized with RMF/SMF so the Polarity value of each engine is not yet added, nor NRCPUS nor other non-static variables (i.e. can vary with time), but IBM plans an APAR that will sync the 113's with RMF/SMF, and MXG will add other TYPE70 variables and new TYPE73 variable to TYPE 113 when that APAR is GA. -The sort order of the PDB.TYPE113 dataset is now BY SYSTEM READTIME JOB SM113STM. -Occasional counter reset without a new interval flag have been observed and are now protected (by deletion of that interval) and detected (by printing an error message). This error can be the result of two known causes: 1) Down level on the z10 micro-code. The z10 needs to be at Driver 76 (GA2) and at least at Bundle 20, as documented in John Burg's SHARE paper. Bundle 20 also fixed some counter errors. 2) When IRD gets involved and varies off a CPU. Varying off by IRD does NOT cut a final record; instead, when it is finally varied back on you get an Intermediate record for that interval, and over an hour elapsed has been observed before that intermediate record was written when the CP came back online. (Thanks: John Burg). -If you want create the enhanced PDB.TYPE113 dataset, and only create that one output dataset in the //PDB library: // EXEC MXGSASV9 //SMF DD DSN=YOUR.SMF,DISP=SHR //PDB DD DSN=YOUR.TYPE113.PDB,DISP=(,CATLG),UNIT=SYSDA, // SPACE=(CYL,(25,25)) //SYSIN DD * %LET PTY70=WORK; %LET PTY70PR=WORK; %LET PTY7002=WORK; %LET PTY70X2=WORK; %LET PTY70Y2=WORK; %LET PTY72=WORK; %LET PTY72DL=WORK; %LET PTY72GO=WORK; %LET PTY7204=WORK; %LET PTY72MN=WORK; %LET PTY72SC=WORK; %UTILBLDP(BUILDPDB=NO, USERADD=7072 113, ZEROOBS=70.2 72, OUTFILE=INSTREAM); %INCLUDE INSTREAM; RUN; PROC DATSETS DDNAME=WORK MT=DATA NOLIST; DELETE TYPE7:;RUN; Thanks to Richard Schwartz, State Street Bank, USA. Change 28.139 These "recently" added SMF30xxx variables are now kept in BUILD005 the PDB.STEPS dataset (but are not carried forward into BUIL3005 the PDB.JOBS dataset, but might be in the future, based Jun 23, 2010 on feedback from this change). SMF30AIC='DASD CONNECT*ASID PLUS*DEPENDENT' SMF30AID='DASD DISCONNECT*ASID PLUS*DEPENDENT' SMF30AIS='DASD SSCH*ASID PLUS*DEPENDENT' SMF30AIW='DASD PEND+CU*ASID PLUS*DEPENDENT' SMF30ASP='ASID*DESIGNATED*STORAGE-CRITICAL?' SMF30CCP='SRVCLASS*DESIGNATED*CPU-CRITICAL?' SMF30CPR='ASID*CURRENTLY*CPU-PROTECTED?' SMF30CSP='SRVCLASS*DESIGNATED*STOR-CRITICAL?' SMF30EIC='DASD CONNECT*INDEPENDENT*ENCLAVES' SMF30EID='DASD DISCONNECT*INDEPENDENT*ENCLAVES' SMF30EIS='DASD SSCH*INDEPENDENT*ENCLAVES' SMF30EIW='DASD PEND+CU*INDEPENDENT*ENCLAVES' SMF30HSH='HWM*USABLE BYTES*IN 64-BIT*SHARED' SMF30HSO='BYTES IN*64-BIT*SHARED*STORAGE' SMF30HVA='HWM*AUX*SLOTS*BACK*64-BIT' SMF30HVH='HWM*USABLE BYTES*IN 64-BIT*OBTAINED' SMF30HVO='BYTES IN*64-BIT*STORAGE*OBTAINED' SMF30HVR='HWM*REAL*FRAMES*BACK*64-BIT' SMF30JPN='SUBCOLN*FROM*IWMCLSFY' SMF30MRA='CPU*RATE*SU_SEC*FACTOR' SMF30MRD='DEPENDENT*ENCLAVES*CPU*TIME' SMF30MRI='INDEPENDENT*ENCLAVES*CPU*TIME' SMF30MRS='SYSTEM*NAME*WHERE*ENCLAVES*RAN' SMF30MSI='REMOTE*SYSTEM*DATA*INCOMPLETE?' SMF30PFR='SRVCLASS*WAS MODIFIED*DURING*EXECUTION?' SMF30SNF='ZIIP NORMALIZATION FACTOR' SMF30SPR='ASID*CURRENTLY*STORAGE-PROTECTED?' SMF30WMI='EXECUTING*IN*WLM*INITIATOR?' SMF30ZNF='ZAAP NORMALIZATION FACTOR' Thanks to Jerry Urbaniak, Acxiom, USA. Change 28.138 Support for SysView Subtype 3 record creates new dataset EXSVTH03 SV03THRE='SYSVIEW THRESHOLD EXCEPTION 03'. FORMATS IMACSVIE
VMACSVIE VMXGINIT
Jun 21, 2010 Thanks to Mike Paladino, Progressive Insurance, USA. Change 28.137 Support for BMC IMF records written in SMF Format in new TYPEIMFS member TYPEIMFS, which handles the SMF header, and sets VMACCIMS OFFIMS, and in updates to VMACCIMS, as not all of its Jun 20, 2010 INPUTs and LENGTH tests included OFFIMS. This iteration will ONLY process IMF 'FA'x and 'F9'x SMF record IDs in the infile SMF dataset. TYPEIMFS creates the same MXG datasets in the same default LIBNAMEs as member TYPECIMS. Thanks to Denise Willers, Infocrossing, USA. Thanks to Ken Steiner, Infocrossing, USA.
VMAC74 kept in TYPE74A, TYPE748R and TYPE74X datasets. Jun 24, 2010 Thanks to Pat Jones, DST, Inc, USA. Change 28.135 Cosmetic. MXG Error messages when bad EXCP segments are VMAC30 found now print the ABEND, CONDCODE, and ABNDRSNC values. VMACEXC2 Precipitated by a series of error messages with bad EXCP Jun 17, 2010 and MULC segments for jobs with SYSTEM 0D5 ABENDS. Jun 24, 2010 The PUT of ABNDRSNC caused it to be defined as numeric when ANALALL was executed, because the VMACEXC2 was used first in SMF 4 record code, before ABNDRSNC was INPUT. Using PUT ... ABNDRSNC= $8; resolved that weird error. Thanks to Trevor Ede, HP, NEW ZEALAND.
VMAC110 harmless, as it occurred after the STID=116 segment had Jun 16, 2010 been output CICSJS. MXG had read only 156 bytes of the 164 bytes of STID=116, causing the error, now fixed. Thanks to Tom Buie, Southern California Edison, USA.
EXT12020 Has only been coded, records skipped until test data VMAC120 exists for validation. Jun 16, 2010 See Change 28.258. Change 28.132 Replaced by Change 28.146. Change 28.131 IMS Log 56x record subtype 15x caused INVALID DATA or VMACIMS INPUT STATEMENT EXCEEDED RECORD LENGTH errors. code was VMACIMSA relocated. Only the 15x variables are now kept in IMS56F Jun 14, 2010 dataset. STIMSID removed from all IMS56x datasets. Thanks to Lindholm Orjan, Volvo, SWEDEN.
ASMRMFV RMFV018I message was slightly low, as 1111 was used in Jun 10, 2010 the denominator instead the correct value of 1110. Thanks to Jerry Urbaniak, Acxiom, USA. Change 28.129 Support for DB2 Version 10. COMPLETELY INCOMPATIBLE: EXDB2ACR -All three DB2 records (100,101,102) can be compressed; EXDB2ACW For z/OS execution, the EXITCICS member's INFILE exit FORMATS now decompresses both DB2 and the original CICS records. IMACDB2 For ASCII SAS, where there are no INFILE exits, or for VMACDB2 z/OS without the exit installed, records are decompressed VMACDB2H with internal SAS code, but that is EXTREMELY EXPENSIVE VMACSMF on z/OS compared with using the INFILE exit, so MXG warns VMXGINIT that you should install the exit to save CPU time. VMXGWORL
Jun 16, 2010 Jun 19, 2010 Jun 21, 2010
-INVALID DATA FOR QWHSRELN is proof you have DB2 V10 SMF; QWHSRELN is not a valid "PK" value; it now has 'A1'x, so VMACDB2H was revised. The value is 10.1, not 10.0. -And INPUT STATEMENT EXCEEDS RECORD error ABENDs may occur because fields were inserted rather than added at the end where MXG would have automatically skipped them.
two bytes (because that's what it should have been all along. However, only SMF 100 and 101 records populate the subtype in the SMF Header. VMACSMF was updated to get the DB2 version and then input the subtype correctly. (MXG has always stored the IFCID value in SUBTYPE for the DB2 102 trace records, since they don't have a subtype.)
which can be used to correlate rollup records. -Multiple SMF 100 Subtype 1 (DB2STAT1) IFCID=2 records are now supported (Jun 21 2010). These records contain only QBST or QBGL segments and are written when more than 25 buffer pools are used in an interval. -Macro _SDB2STS was redesigned to correct DUPLICATE MERGE VALUES errors that occur only if DB2 was restarted, by removing QWHSACE QWHSMTN from the _BDB2STS "BY list", by interleaving the four input datasets to create STATSGROUP to use as merge variable (QWHSSTCK cannot be used as it not exact in all four records for each interval), and by conditionally merging T102S225 (DB2 V8) if it exists. The _SDB2STY macro is now a null macro and no longer used. The new sort order for the PDB.DB2STATS dataset is now SYSTEM QWHSSSID QWHSSTCK. A cosmetic enhancement to VMXGWORL, NOWARN=YES, is used to suppress the MXGNOTEs when a tested dataset is known to not always exist (used for T102S225 in this change).
DB2ACCT:
QLACRLNU QXSTCWLP QXSTCWLR QXSTCWLM QXSTCWLD DB2ACCTP: QPACAWLH QPACANLH QPACRLNU QWACPCTT QWACPQRY QWACAWLH QWACARLH DB2ACCTB: QWACPCTT QWACPQRY QWACAWLH QWACARLH DB2ACCTP: QPACAWLH QPACANLH QPACRLNU QWACPCTT QWACPQRY QWACAWLH QWACARLH DB2ACCTG: QWACPCTT QWACPQRY QWACAWLH QWACARLH DB2STAT0: Q9STCDMD QDSTNQWC QDSTNARD QDSTMARD D64POST A64POST A64WAIT M64DISNU M64DISPG SGETR64 SGETEXT6 SGETDEXT SFREER64 SFREEDEX DISCARDM QWS1MCPU QWS2MCPU QWS3MCPU QWS4MCPU QXSTCWLP QXSTCWLR QXSTCWLM QXSTCWLD DB2STAT1: QISEKSPG QISEKSPA QISEKLRU QISEDLRU QISESQCB QISESQKB QISESQCA QISESQKA QISTRCCI QISTRCCD QISTRCCU QISTWMXA QISTWMXU QISTWCTO QISTW4K QISTW32K QXSTCWLP QXSTCWLR QXSTCWLM QXSTCWLD DB2STATB: QBSTFLG
DB2GBPST: QBSTFLG
-SMF 102 IFCIDs 267, 268, 317, and 337 are now decoded. New formats are created by the updated FORMATS member. -These other IFCIDs in user-sent SMF files are presumably the trace records that are normally written or needed. They have been examined and none were change in V10: 4,5,55,87,105,140,141,173,196,199,250,254,258,261,262 -See the text of Change 28.146, which made changes to DB2 processing that were independent of the Beta, including fixing the PDB.DB2STATS interval issue that was first discussed in this change text, but was not V10 related. Change 28.128 WARNING: APPARENT INVOCATION OF MACRO TRIM NOT RESOLVED CONFIGV8 WARNING: APPARENT INVOCATION OF MACRO CMPRES NOT RESOLVED CONFIGV9 Other: References to MACRO DATATYP in an EVAL statement Jun 9, 2010 which may be followed by ERROR: A character operand was found in %EVAL function or %IF where a numeric operand is required .... There are several "opportunities" for this error: -These options must be in effect to resolve %TRIM: OPTIONS MAUTOSOURCE SASAUTOS=(SOURCLIB SASAUTOS); They are normally set in MXG CONFIGVn, but we have seen instances in which (typically very old) user code has changed those options, causing the error. -The //SASAUTOS DD must point to the "AUTOCALL" dataset (SAS-provided PDS) that contains the TRIM member. -Ancient MXGSASxx JCL procs defined &SASAUTOS which was &NULLPDS, and also had //SASAUTOS DD &SASAUTOS // DD DSN=.... but that was replaced years ago; look at MXGSAS92 for SAS V9.2 or MXGSASV9 for SAS V9.1.3 for correct JCL. -OPTIONS S2=0 must be specified; it is set in CONFIGV9, but I just discovered that CONFIGV8 still had S2=72; that was corrected to S2=0 by this change. -Additionally, the incorrect LOCALE can cause failures with entirely different error messages when %TRIM is used, due to the NOT symbol's mis-translation with the wrong LOCALE. See Change 28.194 documentation. -To diagnose, use // EXEC MXGSASV9,OPTIONS='VERBOSE' and OPTIONS SOURCE SOURCE2 MACROGEN MPRINT SYMBOLGEN; as the first //SYSIN DD statement, and send the FULL job log.
VMACSAVR increased field lengths, and added new data. Dataset Jun 8, 2010 contains new variables JCTJOBID, TYPETASK, SAVRACCT. Thanks to Clement Turner, DC Government, USA. Thanks to Edouard A. Myers, DC Government, USA. Thanks to Roger B. Legerwood, DC Government, USA.
EXMXIST1 three datasets: EXMXIST2 EXMXIST3 dddddd Dataset Description IMACMXI TYPEMXI MXIST1 MXIONE MXIST1: INITIALIZED TYPSMXI MXIST2 MXITWO MXIST2: TERMINATED VMACMXI MXIST3 MXITHREE MXIST3: COMMAND AUDITED VMXGINIT Jun 8, 2010 Thanks to Harald Seifert, HUK-COBURG, GERMANY.
BLDNTPDB when your first-day-of-week is not the MXG "MON" default. BLDSMPDB -VSETMNTH utility correctly determines which daily PDBs MONTHASC are to be read in building week/month; the decision is MONTHBL3 based on TODAY() and the "STARTDAY" of your week. MONTHBLD
MONTHDSK -New macro variable STARTDAY sets the "first day of week" VMXG2DTE default to MON (no change), and is now used internally in VMXGDUR all MXG programs, so that you can externally change that VMXGLBIN first day of week if you do not build your WEEKLY/MONTLY VMXGSUM with MONDAY as the first day. VSETMNTH
Jun 17, 2010 -However, the %BLDSMPDB can be used as your "MONTHBLD" or Jun 28, 2010 WEEKBLD program, and its WEEKSTRT argument can specify the different start day of week if desired:
%BLDSMPDB(WEEKSTRT=SUN,RUNDAY=NO,RUNWEEK=YES,RUNMNTH=NO, WEEKKEEP=list of datasets); add WEEKTAPE=YES, if WEEK PDB is to be written to tape. Monthly job: %BLDSMPDB(WEEKSTRT=SUN,RUNDAY=NO,RUNweek=no,RUNMNTH=YES, MNTHKEEP=list of datasets); add MNTHTAPE=YES, if MONTH PDB is to be written to tape. WEEKKEEP/MNTHKEEP are only necessary if you wish to keep only specific datasets in the WEEK/MONTH PDB (the default is _ALL_.) There is also WEEKDROP/MNTHDROP to drop specific datasets (and it defaults to dropping any SPIN* SPUN* datasets). BLDSMPDB will use the SORTEDBY option in the dataset directory to construct a BY list if present but can also parametrically be told to ignore the SORTEDBY. Thanks to Jim Agrippe, Cleveland Clinic, USA. Thanks to Ron Wells, American General Finance, USA. Change 28.124 The WTIRIOTM in PDB.ASUMUOW could be larger than IRESPTM. VMXGUOW Change 17.324 corrected the problem (WTIRIOTM was the sum VMXGUOWT of WTIRIOTM's from ALL of the CICSTRAN obs in the UOW), VMXGUOTT but a subsequent update in Change 18.204 lost that fix. Jun 4, 2010 It is now the MAXIMUM value from all of the CICSTRAN obs. Thanks to Tom Kelman, Commerce Bank of Kansas City, USA. Change 28.123 Utility program to examine TYPE72GO dataset to assist in UTILWORK creating or investigating workload definitions for the Jun 7, 2010 RMFINTRV. Thanks to Chuck Hopf, Independent Consultant, USA. Change 28.122 Logic revised to use DATEJUL to parse the date, but if ASUMHSM the FSRDATR field is not a valid Julian Date, it is left Jun 7, 2010 as a missing value. Thanks to Tobias Cafiero, DTCC, USA. Change 28.121 -ANALRANK is enhanced to add an output dataset option. By ANALRANK using this you can get the top 10 each day, by appending VGETLABL daily data you can quickly get the top 10 for the month VGETFMT by pushing the daily top 10 back thru ANALRANK. Using Jun 4, 2010 VGETLABL, the labels in ANALRANK are enhanced so that the label of RANKxx variable contains the original variable's label plus the word rank. So the label for CPUTM would become 'TOTAL*CPU TIME*CAPTURED*RANK'. -VGETLABL - New utility to GET the LABEL of a variable. -VGETFMT - New utility to GET the FORMAT of a variable. Thanks to Chuck Hopf, Independent Consultant, USA.
Yüklə 28,67 Mb. Dostları ilə paylaş:
|