* copyright (C) 1984-2019 merrill consultants dallas texas usa
Yüklə 28,67 Mb.
|
|
input records it required 862MB to create the format and nearly as much to load it. But, the only time you might need all of the records is when you are running an IO trace. In the case of an Audit trace, you have to build an Audit table to tell DB2 which things you want to audit. So, selection criteria for DBNAME and OBNAME are added to ANALDB2R to reduce the volume of records input to VFMT102. You can select based on: SYSTEM DB2 DBNAME and OBNAME By selecting only the needed DBNAMEs, the virtual storage needed for the format was less than 50 MB, so selection is ALWAYS wise to do.
criteria for ALL ANALDB2R reports (DBNAME and OBNAME are only available to VFMT102 datasets with DBID or OBID).
MXGDBIDS=ONLY provides the list of all combinations of SYSTEM QWHSSSID (DB2 SUBSYSTEM)DBNAME OBNAME using: %ANALDB2R(PDB=SMF,MXGDBIDS=ONLY); RUN; -Unrelated, new parameter MXGACC01OUT creates an output dataset that you name in that parameter from the MXGACC01 PROC TABULATE. Change 30.240 Graphic and tabular reports of DB2 buffer size and max GRAFDB2B usage, by DB2 Subsystem and Buffer Pool. Will use either NOV 10, 2012 SAS/GRAPH or ODS GRAPHICS for graphs and PROC TABULATE to create a tabular report. Documentation of parameters: PDB=PDB One or more PDB DD NAMES (LIBNAMEs) SASGRAPH=NO Create bar charts with SAS/GRAPH ODSGRAPH=YES Create bar charts with ODS Graphics TABULATE=NO Create a tabular report INTERVAL=QTRHOUR Any valid interval value SAS versions 9.2 and earlier will not work for ODS; 9.3 is required for ODS graphics. If you are at 9.2 and don't specify SASGRAPH=YES, the tabulate report will be created instead. If you specify SASGRAPH=YES but it is not installed, on SAS 9.3 or above, ODS GRAPHICS are used. Otherwise, only the PROC TABULATE report is created. Change 30.239 -VMACIMS IMS Eyecatcher variables STREQxxxx had $HEX40. VMACIMS format but were correctly input as $EBCDIC4; the format VMACRMFV and listing in NOTRAN were removed. Purely cosmetic. VMAC120 -VMACRMFV variable ASMVER00 is now correctly INPUT $CHAR1 Nov 10, 2012 instead of $EBCDIC1 as it contains HEX text characters. -VMAC120 variable SM1209GS is now correctly INPUT $CHAR8 instead of $EBCDIC1 as it contains HEX text characters. (Note: $CHARn is REQUIRED only for MXG execution on ASCII platforms - on z/OS $CHAR and $EBCDIC are identical.)
EXTYEJES Accounting Record creates new EJESSMF dataset. MXG reads IMACEJES either the unique date format for ESMFTBGN or, after TYPEEJES EJES/14242 update, in (E)JES V5R3, the SMFSTAMP format, TYPSEJES transparently. VMACEJES New dataset: VMXGINIT dddddd dataset description Nov 11, 2012 TYEJES EJESSMF (E)JES SMF ACCOUNTING Thanks to Mike Moyne, HHSYS, USA.
EXTYB97M -BETA93: New variables added to BETA1 dataset: EXTYB97N BETAATYP='SEND*AS' EXTYB97O BETABODY='BODY*TEMPLATE*MEMBER' EXTYB97P BETABTYP='OUTPUT*TYPE' EXTYBET7 BETABUFS='MAXIMUM*BUFFER*SIZE' EXTYBET8 BETADCR ='DCR*NAME' EXTYBETH BETAFILE='MAIL*FILE*NAME' EXTYBETI BETAFROM='MAIL*FROM' FORMATS BETAIPAD='IP*ADDRESS' IMACBE97 BETALINK='LINK*TEMPLATE*MEMBER' IMACBETA BETALTKN='LTOKEN*LIST*TOKEN' VMACBE97 BETAMAXA='MAXIMUM*MAIL*ADDRESSES' VMACBETA BETAPORT='PORT*NUMBER' VMXGINIT BETARPLY='MAIL*REPLYTO' Nov 13, 2012 BETASEXT='SOURCE*EXTENSION*NAME' BETASFRM='SOURCE*FORM*NAME' BETASUBJ='MAIL*SUBJECT' BETATRMD='TRANSLATION*MODULE' BETATRTB='TRANSLATION*TABLE' -BETA93: New $MGBETPT format maps these values of BETAPTYP in BETA1 dataset, which describes which of the sets of variables exist in this record: '80'X='80X:DCR OF TYPE SYSOUT' '40'X='40X:DCR OF TYPE MAIL' '20'X='20X:DCR OF TYPE CLIST' '10'X='10X:PRE-ALLOCATED DD NAME' '08'X='08X:DCR OF TYPE VTAM/APPC' '04'X='04X:DCR OF TYPE SUBSYS' '02'X='02X:DCR OF TYPE TCP/IP' -BETA93: New Subtypes 7, 8, and 22 are documented but only the header variables exist in the new BETA7 BETA9 BETA22 datasets until actual records are available. -BETA93: New Subtype 49 creates BETA49 dataset for Batch. -BETA97: New Subtype 25 creates BETA9725 dataset. -BETA97: New Subtype 50 creates BETA9750 dataset. -BETA97: New Subtypes 49 and 51 create BETA0751 but only header variables are created, awaiting test records. Thanks to Mrs. Karen Sendelback, Finanz Informatik, GERMANY.
VMAC113 messages ERROR: DEACCUMULATION DETECTED RESET when HIS Nov 8, 2012 sampling was enabled for one minute every five minutes, because MXG did not use the SM113CF1 Start of Interval flag to bypass the test for negative deltas that printed these messages. However, both TYPE113 and ASUM113 were correctly created because MXG's test for the output did work as designed. Now, SM1113CF1 flag is used to bypass the creation of these messages. Thanks to Erling Andersen, SMT Data A/S, DENMARK. ====== Changes thru 30.235 were in MXG 30.08 dated Nov 7, 2012========= Change 30.235 Variable CFWAITTO='TOTAL CF*CPU*WAIT TIME' is created in VMAC74 dataset TYPE74CF as the SUM OF(CFWAIT01-CFWAIT15) to Nov 7, 2012 match existing CFBUSYTO total CPU busy time. Thanks to Joseph J. Faska, Depository Trust, USA. Change 30.234 First MXG 30.08, zEC12 ONLY, and ONLY with APAR OA37826, VMAC74 which added the HO segment to the RMF 74 subtype 4 record Nov 7, 2012 ERROR: INVALID DATA FOR CHAR4 INPUT STATEMENT EXCEEDED RECORD LENGTH. because that code was only syntax checked, awaiting data with that APAR installed, and CHAR4/ passed syntax but failed when data was read, as it should have been CHAR4. Thanks to Jim Horne, Lowe's, USA. Change 30.233 -TYPE70 variable CPUWAITM was wrong and was larger than ADOC7072 CPUUPTM when HiperDispatch was active (SMF70PAT GT 0) but VMAC7072 IRD was not active (SMF70ONT=DURATM for all engines). Nov 7, 2012 MXG did not subtract parked time from CPUWAITM, BUT ONLY Apr 1, 2013 CPUWAITM was wrong, and since CPUWAITM is NOT used in any other metrics, they WERE correct. Only if you compared CPUUPTM with CPUWAITM would the error have been observed. This error was only significant at low utilizations when CP engines were parked; during peak intervals when all CP engines were NOT parked, the CPUWAITM value was correct. -But in examining the 70 records, observations in TYPE70PR have been found with SMF70PAT greater than SMF70ONT and DURATM by over 5 seconds; new code detects and resets SMF70PAT to SMF70ONT and zeros CPUWAITM when a small negative value (less than 0.10 seconds) is calculated. So both NEWWAIT and SMF70PAT in TYPE70PR are different. RMF development has confirmed that because ONT and PAT are retrieved independently with DIAGNOSE instructions, the can have different values, and RMF Reports use the same heuristic I implemented, to store ONT in PAT when PAT is greater than ONT. -Inserted Apr 2013: A "WARNING. SMF70PAT GT ONT" message was previously printed, but since there is nothing that you can do with that information, as of MXG 31.02, it is no longer printed. -Variable CPUUPTM is now documented in ADOC7072: "Originally the CPU "UP" duration for calculation of available capacity of all CP engines, and was the product of NRCPUS*DURATM, but that was back when the number of CP engines were static, at least between IPLs. Now, with IRD and HiperDispatch "varying" or "parking" engines, NRCPUS is the AVERAGE (and fractional) number of CP engines that were ONLINE during this interval, i.e., that that were made available to this z/OS system during this interval, so the CPUUPTM=NRCPUS*DURATM now will vary and it is no longer the "available for static capacity" up time." Thanks to Mark Cohen, EPVTECH, ITALY Change 30.232 Hiperdispatch introduces some vagaries into percent CPU GRAFWRKX measurements. PCTCPUBY in RMFINTRV is calculated based Nov 6, 2012 on the average number of CPUs online but that may be something less than the actual number of CPs assigned to the LPAR. GRAFWRKX now produces 3 different CPU busy by workload charts. % of the average number of CPUs online % of the CPUs assigned to the LPAR % of the LPAR SHARE (this can exceed 100% if an LPAR is 'stealing' from other LPARs.) Thanks to Mark WIlliams, Marks and Spencer
VMAC102 with new QW0219xx IFCID-specific variables. Nov 5, 2012 -Support for IFCID 220 populates existing T102S220 dataset Nov 8, 2012 with new QW0220xx IFCID-specific variables, but there are discrepancies between the IBM DSECT and the actual DATA and a PMR is opened with IBM to resolve. See Ch 33.064. -Support for IFCID 402 populates existing T102S402 dataset with new QW0402xx IFCID-specific variables, but IFCID 402 is a statistics interval record with accumulated values, so you MUST invoke TYPS102 or use %READDB2 with PDBOUT=, or invoke _S102402 after dataset T102S402 is created, to do the deaccumulation. And unlike the other DB2 V10 interval statistics records, IFCID=402 is written at 15 minute instead of 1 minute intervals. -Support for 4TH Waiter in T102S196 dataset added Nov 8.
VMXG70PR (but SMF70PAT parked time was valid in PDB.ASUM70LP and Nov 3, 2012 PDB.ASUMCELP datasets). The LPnPAT variables were not in the RETAIN statements for the two datasets, so they have always been missing; this is not a new error! Thanks to Wayne Bell, UniGroup, USA. Change 30.229 Support for DB2 NETEZZA Optional data has been read and IMACDBNZ some corrections were made in the DB2STATS/DB2NETZA. VMACDB2 -These DB2STATS variables Nov 2, 2012 Q8STSCPU Q8STSELA Q8STTCPU Q8STTELA Q8STACPU Q8STAELA were not divided by 4096. -These DB2STATS variables Q8STACTV Q8STCCPU Q8STWCPU Q8STQUEM were incorrectly de-accumulated. -The Q8AC triplet was incorrectly input, causing all of the Q8ACxxxx variables in DB2ACCT (when enabled by the removal of the comment block in IMACDBNZ) to be wrong. And, the Q8ACNAME field is now INPUT and populated. IBM DB2 Analytics Accelerator IDAA uses Netezza. Thanks to Victoria Lepak, Aetna, USA. Thanks to William E. Howard, Aetna, USA.
UTILEXCL -CICSTRAN has new fields inserted at the end of each VMAC110 segment. The RMI fields that were formerly optional Dec 30, 2011 are now created by default. CMODIDNT Apr 25, 2012 TDILWTTM='TDILWTT*DURATION' 403 May 28, 2012 TDILWTCN='TDILWTT*COUNT' 403 Sep 25, 2012 TDELWTTM='TDELWTT*DURATION' 404 Oct 15, 2012 TDELWTCN='TDELWTT*COUNT' 404 Nov 1, 2012 ROMODDTM='ROMODDLY*DURATION' 348 ROMODDCN='ROMODDLY*COUNT' 348 SOMODDTM='SOMODDLY*DURATION' 349 SOMODDCN='SOMODDLY*COUNT' 349 ISALWTTM='ISALWTT*DURATION' 319 ISALWTCN='ISALWTT*COUNT' 319 TCALWTTM='TCALWTT*DURATION' 343 TCALWTCN='TCALWTT*COUNT' 343 SOCIPHER='SOCIPHER*COUNT' 320 CECMCHTP='CECMCHTP*NAME' 430 CECMDLID='CECMDLID*NAME' 431 MAXTASKS='MAXTASKS*COUNT' 433 CURTASKS='CURTASKS*COUNT' 434 SC64CGCT='64-BIT*C*GETMAINS' 441 SC64CHWM='64-BIT*C*STORAGE*HWM' 442 SC64UGCT='64-BIT*USER*STORAGE*GETMAINS' 443 SC64UHWM='64-BIT*USER*STORAGE*HWM' 444 SC64SGCT='64-BIT*SHARED*GETMAINS' 445 SC64GSHR='64-BIT*SHARED*BYTES*GETMAINED' 446 SC64FSHR='64-BIT*SHARED*BYTES*FREEMAINED' 447 TASZIPTM='TASK*ZIP*CPU*TIME' MXG-Created TASELGTM='TASK*ZIP*ELIGIBLE*CPU TIME' MXG-Created CPUTONTM='TASK*TOTAL*CPU TIME*ON ZIP' 436 CPUTONCN='TASK*TOTAL*DISPATCHES*ON ZIP' 436 OFFLCPTM='TASK*ZIP*ELIGIBLE*RAN ON ZIP*CPU TIME' 437 OFFLCPCN='TASK*ZIP*ELIGIBLE*RAN ON ZIP*DISPATCHES' 437 ACAPPLNM='APPLICATION IN*APPLICATION*CONTEXT*DATA' 451 ACPLATNM='PLATFORM IN*APPLICATION*CONTEXT*DATA' 452 ACMAJVER='MAJOR VERSION IN*APPLICATION*CONTEXT*DATA'453 ACMINVER='MINOR VERSION IN*APPLICATION*CONTEXT*DATA'454 ACMICVER='MICRO VERSION IN*APPLICATION*CONTEXT*DATA'455 ACOPERNM='OPERATION IN*APPLICATION*CONTEXT*DATA' 456 MPPRTXCD='MPPRTXDC' 449 FCXCWTTM='WAIT TIME*FOR EXCLUSIVE*VSAM CI' 426 FCXCWTCN='WAIT COUNT*FOR EXCLUSIVE*VSAM CI' 426 FCVSWTTM='WAIT TIME*FOR*VSAM*STRING' 427 FCVSWTCN='WAIT COUNT*FOR VSAM*STRING' 427 -TASCPUTM has always included the CPU time on zIIP/zAAPs, and thus can EXCEED the elapsed time when the specialty engine is faster than the CP engines, as documented in Change 29.076, and because previously the TASZIPTM was not separately recorded in CICSTRAN. Even though 5.1 DOES have the separate field, I chose to NOT change TASCPUTM, even though that is inconsistent with the "normal" MXG implementation of keeping the CP and zIIP/zAAP times in separate variables, because it seemed changing the value in TASCPUTM would have caused more impact to you. -CICSTRAN fields not created in 5.1 (are missing values) DB2WAITM/DB2WAICN 189 J8CPUTM/J8CPUCN 260 J9CPUTM/J9CPUCN 267 MAXJTDTM/MAXJTDCN 277 CBSRVRNM 311 EJBSACCT 312 EJBSPACT 313 EJBCRECT 314 EJBREMCT 315 EJBMTHCT 316 EJBTOTCT 317 MLXSSCTM/MLXSSCCN 411 (not documented as gone by IBM) -CICSTRAN fields in 5.1 that have altered meaning: These fields now include the new GET64 CONTAINER and the PUT64 CONTAINER data values: PGGETCCT 323 PGPUTCCT 324 PGGETCDL 326 PGPUTCDL 327 PGCRECCT 328 -CICSEXCE dataset has two new values of EXCMNRIX of GUDSA - Wait for GUDSA Storage GSDSA - Wait for GSDSA Storage -CICS Statistics Interval now defaults to 1 hour versus 3. -CICLDG variables added: LDGLLRRO='LIBRARY*LOAD*REQUESTS*RO TCB' LDGLLTRO='TOTAL*LOADING*TIME*RO TCB' -CICM variables added: MNGCECTP='CEC*MACHINE*TYPE' MNGCECID='CEC*MODEL*NUMBER' -New STID=62, same as STID=60, outputs CICDS dataset. Eighteen TCBs exist in TS/5.1, but none are new. The MXG TCB variables in CICDS dataset all have the two-character "TCB Name" text in their labels, and the MXG variable's suffixes (DSG, DS1, DS2 ... for QR, RO, CO ...) are listed in this table mapping the IBM 5.1 TCB Numbers: TCB Name: QR RO CO SZ RP FO SL SO SP EP TP D2 S8 L8 L9 X8 X9 T8 IBM TCB NR: 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 MXG Suffix: G 2 3 4 5 6 7 8 H M N D B A I J K L -STID=101 adds two new variables to dataset CICWBG: WBGATOMS='ATOMSERVICE*REQUESTS' WBGJVMSV='JVMSERVER*REQUESTS' Change 30.227 Documentation updates, to give better examples of how to ADOCRMFI define workloads in RMFINTRV. UTILWORK Oct 31, 2012 Change 30.226 -Support for AIX/LINUX NMON data with FRENCH language text VMACNMON and with fractional numbers with commas instead of the Nov 1, 2012 expected period, found (so far ONLY) in "BBBP" records. -Support for MEMAMS Memory Object adds MSxxxxxx variables to the NMONINTV dataset. Thanks to Atsou Toulabo, GMF, FRANCE. Thanks to Giles Fontanini, GMF, FRANCE. Thanks to Olivier Fy, GMF, FRANCE. Change 30.225 With more than about 40 workloads defined in RMFINTRV, ANAL72GO VMXGRMFI could fail due to macro variable string length ANALDB2R limits on list of variables. And, if you workload prefix ANALID was too long, VMXGSUM (called by VMXGRMFI) could fail on ASUM113 truncated variable names, causing variable not FOUND. MULTIPDB New MXGEXIMSG macro variable replaces all hardcoded READDB2 arguments so that, when directed by support@mxg.com, you SMFSRCH can use this syntax UTILNPRT %LET MXGEXIMSG=YES; VGETENG to enable (logs) of print lines for diagnostics. VGETLIBS VGETOBS
VGETSORT VGETWKLD
VMACID VMXGFIND
VMXGINIT VMXGOPTR
VMXGPRA1 VMXGPRNT
VMXGRMFI VMXGSRCH
VMXGSUM VMXGSUM
VMXGUOW VMXGWORL
Oct 30, 2012 Change 30.224 -Documentation note on SMF backup when execution on ASCII. CHANGES Change 23.090 provided this technique to back up the SMF VMXGGETM file when executing MXG on ASCII (and note the file name Nov 1, 2012 of the backup has the date/time): 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 ("'SYS4.SMF.YOUR.DAILY(0)'") USER='xxxxxx' HOST='xxxxxxxx' DEBUG
S370VS RCMD='SITE RDW READTAPEFORMAT=S BUFNO=35' /*for tape*/ LRECL=32760 PASS='xxxxxxxx'; FILENAME SMFBKUP "D:\Users\365173\MXG\SMFDATA\SMF.HHPR.&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 SMFINFILE @; ); RUN; %INCLUDE SOURCLIB(BUILDPDB); RUN;
the file being read, in spite of a post to MXG-L that reported this error message using that technique: "ERROR: The '/' INPUT/PUT statement option is inconsistent with binary mode I/O. The execution of the DATA STEP is being terminated". And, that text was found in SAS Note 3404, an ancient note that was fixed in SAS Version 8.2. That error message was NOT due to the backup technique; there was a prior and unrelated syntax error that was the true cause of that binary mode I/O error message. But, a subsequent post suggested that RECFM=S370VBS could be used to create the ASCII backup file, BUT: YOU CAN NOT USE RECFM=S370VBS on ASCII for OUTPUT. While you can write with that RECFM with no errors on the log, THE OUTPUT FILE CANNOT RELIABLY BE READ. Sometimes it is valid, sometimes it is not, and there is no clue, until you try to read the backup file. -VMXGGETM is revised to support RECFM=N write of VBS data when it is executed on ASCII, so you could use FILENAME SMFBKUP "D:\Users\365173\MXG\SMFDATA\SMF.HHPR.&DATETXT"; %VMXGGETM(SMFOUT=SMFBKUP,NRECORD=MAX); as a standalone program to create a backup of your SMF. Thanks to Michael Mayne, HHSYS, USA. Change 30.223 Support for user-created CICS variables TRANSU, PGMU, UTILEXCL USERU and USERDATU. UTILEXCL must be executed to create VMAC110 the IMACEXCL to input those fields, and the four IMACICxx IMACICUW members must be copied into your "USERID.SOURLIB" and the Oct 26, 2012 Thanks to Randall R. Schlueter, FirstData, USA. Thanks to Joan E. Nielsen, FirstData, USA.
VMACDB2 QPACROLL nor QPACRUSM for the ID=101 SUBTYPE=1 records. Oct 26, 2012
ANALHSM Concurrent HSM Queued, are now sorted by datetime within Oct 25, 2012 each HSM Function. Thanks to Rick Ralston, Humana, USA. Change 30.220 Support for NDM-CD Subtype CX Certificate Expire subtype EXNDMCX creates new NDMCX dataset. IMACNDM VMACNDM
VMXGINIT Oct 24, 2012 Thanks to Douglas C. Walter, CitiBank, USA. Thanks to Brent Turner, CitiBank, USA. Change 30.219 The mapping of DBID/OBID hex values to the actual name of ANALDB2R the database or table were not always decoded correctly VFMT102 by the format created by VFMT102. In some cases IFCID 105 Oct 21, 2012 was written up to 30 seconds AFTER the trace record that Nov 5, 2012 needed the 105 values, so a format based on timestamps cannot be used. This iteration creates the format based on variables SYSTEM DB2SSSID QWHSACE DBID (or DBID OBID). NOTE: REGION=200M or larger may be required because this format is MUCH larger; the size is related to the number of observations in T102S105 and T102S107 datasets. Nov 4: The Oct 21 iteration could cause duplicate values error when building the format; NODUPKEY replaced NODUP to circumvent the error, but this could cause some DBID and OBID values to remain HEX (i.e., unmapped). We are still redesigning the entire mapping algorithm but not in time for today's MXG 30.08. Contact support@mxg.com if you want the redesigned mapping when it's ready. Thanks to Alyona Bertneski, JPM Chase, USA. Change 30.218 In ANALDB2R, INTERVAL=xxxx wasn't supported, causing ANALDB2R MXGERROR: YOU SPECIFIED INTERVAL=HOUR Oct 19, 2012 MXGERROR: AND DATETIME=QWACBSC BUT THAT MXGERROR: DATETIME VARIABLE IS NOT IN THE SUMBY LIST MXGERROR: VMXGSUM TERMINATED EXECUTION if you were using MXG 30.05 or earlier. With later MXG versions INTERVAL= was ignored for the Accounting reports with no error message. Now, if INTERVAL= is specified, but the correct datetime variable is not in your SORTBY= parameter, the datetime variable is added to SORTBY list. -But for DB2ACCTP, intervals are still calculated based on QWHSSTCK (the end of the interval), because QPACSCB did not exist originally. While it could be now used, that would require significant updates to the ASUM and TRND members, and it is still possible for the PLAN/PACKAGE to fall into different intervals. -Statistic data is always summed using QWHSSTCK; since the interval duration for statistics in DB2 V10 is now fixed at one minute, changing to start versus end would not make much difference. Thanks to Ron Wells, Springleaf Financial Services, USA.
VMACRMFV data messages when the (new) MXG00 record (created by the Oct 18, 2012 new ASMRMFV to document its version) was read, but there Yüklə 28,67 Mb. Dostları ilə paylaş:
|