* copyright (C) 1984-2019 merrill consultants dallas texas usa
Yüklə 28,67 Mb.
|
|
the DB2STATS dataset (so you can tell if the Netezza APAR PM50434 has been installed!) as well as in DB2NETZA. -See Change 30.229. Thanks to Jan Tielmans, KBC, BELGIUM. Thanks to Christa Neven, KBC, BELGIUM. Change 30.132 Corrections to SMF 21 calculations for compression ratios VMAC21 and circumvention for records with byte count fields that Jul 22, 2012 unexpectedly contain zeros. When the compressed bytes in Aug 7, 2012 SMF21MDR or SMF21MDW are zero, the compression ratio can not be calculated. In some records, uncompressed bytes in SMF21BR/DBR/MCR and SMF21BW/DBW/MCW are zero, which also caused confusion as to which variable should be used. This was circumvented by calculating the uncompressed byte counts as: BYTEREAD=MAX(BYTEREAD,SMF21DBR,SMF21MCR,0); BYTEWRIT=MAX(BYTEWRIT,SMF21DBW,SMF21MCW,0); and using those values as the numerator of SMF21CRR/CRW, when SMF21MDR/SMF21MDW are nonzero. A problem is opened with IBM to understand the zeroes. -Aug 7: Variable OPEN is always blank may not be new. Sites have DCBOFLG='00'X in ID=21 SMF records, but the ID=14/15 DCBOFLGS field is valid. The 14/15 is written at z/OS CLOSE, but your CA-1/RMM/TLMS tape management product still owns the DCB, so they may be clearing the DCB byte before the type 21 record is written (which can be HOURS later than the CLOSE event). The type 21 write only copies control block values with no logic/changes. In TYPE21 DCBOFLG is only used to populate variable OPEN with INPUT or OUTPUT, so now, the BYTEWRIT and BYTEREAD counts are compared and OPEN is populated based on the larger of the two values. Zero or equal will blank OPEN. Thanks to Scott Barry, SBBWorks Inc, USA. Thanks to Michael Creech, Lender Processing Services, USA. Change 30.131 Two new parameters are added to enhance VMXGALOC: VMXGALOC READONLY - if set to YES the code that deletes old BLDSMPDB directories is suppressed. IMACINIT CLEARALL - if set to YES, ALL previously allocated Jul 22, 2012 LIBNAMEs are cleared. YES is the default. Sep 16, 2012 With these changes, you can do reporting for multiple days/weeks in a single SAS session. Examples: -To run reports based on today's runs: %VMXGALOC(BASEDIR=xxx,READONLY=YES,CLEARALL=YES, TRENDING=DAILY); which allocates all of the current LIBNAMES that were created with today's run, then you can run your reports. -To go back to an earlier date, like June 11, 2012: %VMXGALOC(BASEDIR=xxx,READONLY=YES,CLEARALL=YES, TRENDING=DAILY,FORCEDAY=11JUN12); which clears all of "todays" allocation and the correct LIBNAMEs for June 11, are then allocated.
TODAY()-NN where NN is the number of days to go back. BLDSMPDB - z/OS only, if you asked to WTD or MTD and also asked to use WEEKTAPE or MNTHTAPE, an ABEND will now be generated since this structure is not supported by the sequential engine on z/OS. Also, if you were running WTD, BLDSMPDB incorrectly tried to start the week one day too early; that has been corrected. No data was lost but the data may not have been in the week where you expected to find it for the first day of the week. IMACINIT - applies only if you are running BLDSMPDB with AUTOALOC=YES. A new example VMXGALOC invocation is in comments in the IMACINIT member. Copy IMACINIT into your "USERID.SOURCLIB" tailoring library, REMOVE the comments around that VMXGALOC invocation, EDIT it to match your BLDSMPDB arguments, and then, since IMACINIT is always invoked at MXG startup, all of these "PDB" LIBNAMEs PDB MON TUE WED THU FRI SAT SUN SPIN WEEK1-WEEK5 MONTH TREND SPIN CICSTRAN DB2ACCT will always be allocated. -Sep 16: Comments updated, no code was changed. Thanks to Mynard Holloway, Spectrum Health, USA. Thanks to Robb Hermes, Sentry Insurance, USA.
EXITCICS SMF records (which version 1 didn't always do), continues Jul 19, 2012 to also decompress CICS SMF records, and this version no Aug 4, 2012 longer needs the IBM CICS macro library for the assembly. -EXITCICS is the z/OS ASM source code and ASM/LKED steps that create the CICSIFUE "Infile Exit" load module that decompresses DB2 V10 and/or CICS/TS 3.2+ compressed SMF records. It has never failed for CICS records, and while many DB2 sites have used it successfully, a small number of DB2 sites had errors reading compressed records; those errors are corrected in this updated EXITCICS member. The complete instructions for creating and installing the exit are in the comments in the EXITCICS member. -Version 2 briefly existed and it corrected the DB2 errors but it still needed the DFHSMFDS macro. Thanks to Richard Anderson, SAS z/OS Technical Support CARY, USA. Change 30.129 Support for new zNEXT CPU MF counters EXTEND157-EXTND207 ASUM113 and revised calculations for all of the formulas. VMAC113 There were 48 EXTEND counters initially and now there are Jul 20, 2012 80 EXTEND counters, thru EXTND207. Aug 31, 2012 -Calculations updated from JP Burg's August 29 2012 text. Sep 17, 2012 -Corrections made Sep 17: Oct 9, 2012 1. Line 271 in VMAC113 was missing the 0.65. 2. Labels in VMAC113 for EXTND159-162 are now L4 vs L$. 3. The 151- and 148= typos in both ASUM113 and VMAC113 for the MEMP calculation are corrected. 4. The LPBUSY in ASUM113 was changed to LPARBUSY; LPBUSY is the variable in VMAC113 but it's LPARBUSY in ASUM113 as documented in Change 28.226. Oct 9 update: -Labels for the EXTNDnnn counters were revised based on SA23-2261-02. Note that there are three sets of labels for the z/10, z/196 and z/114, and the zEC12, but SAS can only use the last label for a variable, the active labels are now for the zEC12, but the other labels can be seen in the VMAC113 LABEL statement. -z/EC12 only defines counters thru counter 179, but MXG was misled to create counters up to 207, but since they will likely exist sometime, variables thru EXTND207 are created by this change, IN 30.05 AND REQUIRED FOR z/EC12 processors - an "ARRAY SUBSCRIPT OUT OF RANGE" error will occur without this change. Change 30.128 -DB2 V10 changed the QPACFLGS bit map; variables QPACDBRM VMACDB2 and QPACPACK no longer exist (so they are always blank in Jul 16, 2012 QWHSRELN GE 10 observations), and new flag variable, only in Version 10 and later are created and populated: Variable Label from QPACFLGS QPACROLL='THIS IS A*ROLLUP*QPAC?' 01X bit QPACRUSM='THIS IS A*SUMMARY*ROLLUP*QPAC?' 02X bit -Documented in DB2 Macro Library member DSNDQWAS: If QPACROLL is on, the Package Record contains ONLY the QPKG and QPAC segments, but the QXPK, QBAX and QTXA segments do not exist, so a ROLLUP record will always have missing values for these SQL/DML QXPK variables QPSELECT QPINSRT QPUPDTE QPDELET QPDESC QPPREP QPOPEN QPCLOSE QPFETCH QPLOCK QPCALL and QBAC and QTXA fields will also be missing values in the DB2ACCTP dataset. -Documented in DB2 Macro Library member DSNDQPAC: If QPACRUSM = ON, the following fields are invalid: QPACCRNT QPACINSP QPACPAC QPACPKNM QPACCOLN QPACPKID QPACCONT QPACSCB QPACSCE QPACBJST QPACEJST QPACASCH QPACAANM QPACAAFG IF QPACRUSM = OFF, the following fields are invalid: QPACCRNT QPACPAC QPACSCB QPACSCE QPACBJST QPACEJST IF QPACRUSM = OFF, the following fields are the last non-zero value for a thread rolling data into this QPAC QPACASCH QPACAANM QPACAAFG Thanks to Jane Stock, USPS, USA.
VMAC21
Jul 13, 2012 Change 30.126 Selection of data by a range of explicit DATE values did ANALGRID not work, but all of the keywords for date selection were Jul 12, 2012 correct. Thanks to Raff Rushton, Kaiser Permanente, USA. Change 30.125 Variable UMLRECL in dataset DCOLMIGS, LRECL of the VMACDCOL migrated dataset, is now INPUT and kept. It was Jul 10, 2012 added by z/OS 1.12 but overlooked. Thanks to Brian Harvey, HCL America, USA. ====== Changes thru 30.124 were in MXG 30.04 dated Jul 4, 2012========= Change 30.124 z/VM variable VMDFLREO should not have been divided by VMACVMXA DELTATM (which is normally 60 seconds, so the values in Jul 3, 2012 VMDFLREO were 1/60th, or 1/DELTATM too small). Thanks to Sam Bass, McLane Company, USA. Change 30.123 -Change 28.226 noted that TYPE113 variable SM113CPT is VMAC113 only populated if SM113VN2 GE 2 (i.e., z196 or later) but VMAC7072 that change did not note that as a result, SMF70CIN is Jul 3, 2012 also blank when SM113VN2 is not 2. However, if both 113 and RMF 70 records are processed together, (or as long as PDB.TYPE70PR exists when ASUM113 is executed), then the merge of the 70 data with the 113 data will populate both SMF70CIN and SM113VN2. -In investigating the above, TYPE113 variable DELTATM was found to sometimes be too small; MXG must calculate the interval duration from adjacent records because IBM does not create it, and the incorrect use of FLOOR(DIF(x)) was found to be the culprit; DELTATM is now correct but is no longer "made pretty" with an integer value. The small value for DELTATM caused both the count in LPARCPUS to be grossly wrong in some cases (12 vs 2!) and LPBUSY could also be incorrect. -But, "valid" small values of DELTATM have been observed in some as-yet-not-fully-understood cases where SMF 113 records are written extremely close in time. While the deaccumulated counters look to be correct in these cases, as they are not full intervals, I recommend that all of your observations in PDB.ASUM113 that have DELTATM less than the expected interval duration (e.g., DELTATM LT 890 if the expected data is 15 minute interval) be deleted before you analyze the HIS data. USE TYPS113E vs TYPS113. -VMAC7072: Cosmetic. Change 30.106 typo in the LABEL for ZIPSHARE caused UNINIT VARIABLE ZPTSHARE that is fixed. Thanks to Roger Lowe, Northern Territory Government, AUSTRALIA
VMXGGETM a null value but now accepts MAX and either null or MAX Jul 2, 2012 will set the counter to the value of MXGOBS.
FORMATS New formats $MG119CI $MG119CO $MG119MA $MG119MO $MG119TY VMAC119 are created and assigned to appropriate variables. Some Jun 29, 2012 old formats $MG119AM $MG119CC $MG119PL $MG119ST $MG119RF were defined, but not assigned to all variables. Formats $MG119CC and $MG119PL are identical, but as they were assigned separately to different variables, they have to be kept in FORMATS. $MG119FA and $MG119RF were also identical, but neither was assigned so $MG119FA has been removed from FORMATS. Thanks to Martyn Jones, Deutsch Bank, GERMANY.
EXRAC2G1 dataset with Custom User Data. IMACRACF VMACRACF
VMXGINIT Jun 28, 2012 Thanks to Steve Carlson, Univ of California Office of President, USA.
BUILD005 subtypes 2,3,4,5 (kept in TYPE30_V/TYPE30_4/TYE30_5 and BUIL3005 in PDB.SMFINTRV, PDB.STEPS and PDB.JOBS datasets): VMAC30 HICPUPCT='HIGH*TASK*CPU*PECENT' Jun 28, 2012 -For interval records, the largest percentage of CPU time used by any task in this address space, rounded to the nearest integer. A value of 25 indicates that the most CPU intensive task in this address space was dispatched on a physical processor for 25% of the SMF interval time. -For step-end, the value is the largest reported interval if the step crosses an interval boundary. -For job-end, the value is the largest reported interval value for any step. -The percentage value in the record is calculates as: TCB time * 100/ interval time. HICPUPGM='HIGH*TASK*PROGRAM*NAME' -Program name running in the task that used the largest percentage of CPU time in this address space. This field corresponds to HICPUPCT. -A value of blanks indicates that no task reported any CPU time in the address space, or that the CPU time could not be obtained. -A value of '????????' indicates that the program name could not be obtained for the task that reported the highest percentage of CPU time. -Additional information from IBM in the APAR text: -These new fields are intended to identify the largest consuming task when multiple tasks are active in an address space. One may compute the address space task percentage from existing fields in the SMF 30 record but one has no insight currently into usage within the address space. If the total CPU percentage is on the order of 50%, the task may struggle to be served well particularly if it has a mediocre dispatching priority or the system is running in horizontal mode (HiperDispatch not enabled). If the address space percentage is 50% and the largest task percentage is 15%, there is little concern that the task will be unable to progress as long as it is properly classified in WLM. -IBM will provide guidance to our customers that establishing a list of candidates to monitor and determining any increase in percent dispatched for the evolving list over time (perhaps every six to twelve months) should be part of the capacity planning process. Our current recommendation is to take note of address spaces with programs that are dispatched at least 25% of an interval for intervals of at least 5 minutes. Change 30.118 Unused Change Number. Change 30.117 Documentation of MXG internal syntax. The example code UDDDDDD in VMACXXXX shows this syntax for the dataset label UTILVREF (LABEL='dddddd: description of dataset' VMACXXXX but it was never documented that the "dddddd" token in Jun 25, 2012 the label can NOT contain a blank (a blank causes the UDDDDDD program to fail building $MGDDDDD and $MGDDDSN formats). A comment was added in the VMACXXXX example, test for a blank was added to both UDDDDDD and UTILVREF, but as these programs are ONLY used internally during the MXG QA process to create documentation, these errors won't be observed by MXG users.
EXZPR01 These new datasets are created: EXZPR02 EXZPR03 DDDDDD MXG MXG EXZPR04 DATASET DATASET DATASET EXZPR05 SUFFIX NAME LABEL EXZPR16 FORMATS ZPR01 ZPRO01 ZPR01: Z/PROTECT DISPATCHER STARTUP IMACZPRO ZPR02 ZPRO02 ZPR03: Z/PROTECT SHUTDOWN EVENT TYPEZPRO ZPR03 ZPRO03 ZPR03: Z/PROTECT OPERATOR COMMAND EVENT TYPSZPRO ZPR04 ZPRO04 ZPR04: Z/PROTECT ABEND EVENT VMACZPRO ZPR05 ZPRO05 ZPR05: Z/PROTECT RAW OPERATION DATA VMXGINIT ZPR16 ZPRO16 ZPR16: Z/PROTECT INTERVAL AGGREGATIONS Jun 30, 2012 In dataset ZPRO16, variable ZPRTTYPE identifies which of the seven possible aggregates is reported: 1='1:OVERALL TOTALS' 2='2:TOTALS BY USER' 3='3:TOTALS BY CRYPTID' 4='4:TOTALS BY JOBNAME' 5='5:TOTALS BY USERID AND CRYPTID' 6='6:TOTALS BY JOBNAME AND CRYPTID' 7='7:TOTALS BY USERID AND JOBNAME' Change 30.115 -VMXGRMFI - The TRENDING section of VMXGRMFI now uses ADOCTRND VGETWKLD to ensure that all workloads, old and new, are GRAFTRND preserved. This allows you to add new workloads but then GRAFWRKX remove or rename old workloads, while preserving your MNTHRMFI historical data for the old workloads that may no longer TRNDRMFI exist in RMFINTRV, but will still exist in TRNDRMFI. UTILBLDP -VGETWKLD - Now will get the workload names, labels and UTILCPLG periods for use in VMXGRMFI from multiple sources. New VGETWKLD parameter datasets lets you specify as many datasets for VMXGALOC input as may be needed, but the purpose is to allow the VMXGRMFI specification of DATASETS=WORK.RMFINTRV TREND.TRNDRMFI so Jun 21, 2012 that if you have added or deleted or renamed workloads, Jun 26, 2012 the old ones in TREND will be carried forward, rather Jul 2, 2012 than being dropped. New design is also used in GRAFWRKX, but this is intended for internal MXG usage. -ADOCTRND - New documentation section 4 showing how to backload past RMFINTRV data into TRNDRMFI. -GRAFTRND now is only an invocation of GRAFWRKX with appropriate arguments. -GRAFWRKX - sort order for TRNDRMFI was incompatible with the SORT order for GRAFWRKX so a PROC SORT was added. -MNTHRMFI now is only an invocation of VMXGRMFI with appropriate arguments. -TRNDRMFI now is only an invocation of VMXGRMFI with appropriate arguments. -TRNDRMFN now is only an invocation of VMXGRMFI with appropriate arguments. -UTILBLDP - COSMETIC ONLY - realign code to make it easier to understand -UTILCPLG - did not correctly parse out the LOG/LIST names and if not preceded by a RUN; statement it could execute at unexpected times because of timing issues in the macro language. If the directory pointed to did not contain a \ or a / (os dependent) it was not added and could result in an error during the copy process. -VMXGALOC - If you specified FIRSTRUN=YES and also were trying to run with WTD processing, the allocation of the WEEK libname for the current week did not happen. Thanks to Mynard Holloway, Spectrum Health Change 30.114 SAS User SMF Records with SASPROC='SQL (63)', 'APPEND (' VMACSASU values were unexpected (and unknown to SAS Support) and Jun 19, 2011 caused SASPROD='UNKNOWN'. Now, the paren is detected and only the SAS Procedure text name is stored in SASPROC, so the SASPROD will be "known". Thanks to Erling Andersen, SMT, DENMARK. Change 30.113 -DB2 V10 restructured the DB2STATS (100-1) QIST segment, VMACDB2 but this was overlooked (perhaps because there are no Jun 19, 2011 vertical change bars in IBM DB2 DSECTS!) causing invalid values for QIST variables. The restructure removed these QIST variables so they will have missing value in V10: QISTWFMU QISTWFCU QISTWFCK QISTWFMX QISTWF04 QISTW04K QISTWF32 QISTW32T and V10 created these new variables in PDB.DB2STATS: QISTIMAC QISTIMSC QISTIMAH QISTIMSH QISTSIAC QISTSISC QISTSIAH QISTSISH QISTWFRHIG QISTWFRCUR -In validating this change, these QIST and QISE variables should not have been deaccumulated: QISTWCTO QISTW32K QISTW4K QISEDLRU QISESQCA QISESQKB QISESQKA QISESQCB QISEKSPG QISEKSPA The IBM DB2 DSECTs don't always identify which fields are accumulated; only actual data driven thru the DIF() logic will prove or disprove field contents (a negative value or 4x10**9 value prove the field is NOT accumulated), so data with non-zero values are required to validate MXG. Thanks to Victoria Lepak, Aetna, USA. Thanks to Valerie J. Chisholm, Aetna, USA. Change 30.112 -Thruput Manager datasets TPM16S and TPM16J, variables VMACTPMX TPMAJCT and TPMSCT were too large by 100; they were INPUT Jun 19, 2012 as PIB4. but are now input as PIB4.2. -In addition, TPMAJCT in TYPE16S is an accumulated value, but the value in TPMSCT will be the step value (with PTF TMT6218) so there is no real need to deaccumulatate TPMAJCT to get the individual step CPU time in TPMSCT. However, now realizing TPMAJCT is accumulated, if you use TYPSTPMX or _STPM16S to sort dataset TPM16S, this change will deaccumulate TPMAJCT, and the TPM16S label will indicate that its value is deaccumulated.
VMAC80A
Jun 19, 2012 Thanks to Harald Seifert, Huk-Coburg, GERMANY. Thanks to Jens Mohring, Huk-Coburg, GERMANY.
VMACWPMO correctly decoded; a hard-coded ',' is now &DLMWPMO so Jun 17, 2012 that your delimiter is always used in parsing text. Thanks to Florent Boulesteix Inovans, Ca-Caagis, FRANCE. Change 30.109 Support for Mainview CICS v64 CICS/TS 4.2 (COMPATIBLE). EXMVCICP -New variables added to dataset CMRDETL dataset: IMACMVCI T6ERSFLG1 T6ERSFLG2 T6ERSFNCNT T6E67ID T6E67XCT VMACMVCI T6EECSEC T6EPHNWD T6EPHAPL T6EPHATT T6EPHTSN T6EPHTID VMXGINIT T6EPHCNT T6EADPID T6EADPD1 T6EADPD2 T6EADPD3 Jun 16, 2012 -New dataset decoded for File Segment for PROGRAM: dddddd dataset description MVCICP CMRFPROG MAINVIEW CICS FILE PROGRAM Change 30.108 Reading RMM EDGS records on ASCII caused INPUT STATEMENT VMACEDGS EXCEEDED RECORD LENGTH error if MORTYPE='FFFFFFFFFF'X. Jun 15, 2012 The $EBCDIC8 input set the value '000000000000'X, so now a separate input with $CHAR8 is used for those tests. Thanks to Rick Raiton, US Airways, USA.
EXTMD2XB which add segments to the PK, TB, and TG records creating EXTMD2XG these three new datasets: EXTMD2XK DDDDDD Dataset Description IMACTMD2 TMD2XK TMD2PKS Thread Package Accounting Segments VMACTMD2 TMD2XB TMD2TBS Thread BP Accounting Segments VMXGINIT TMD2XG TMD2TGS Thread GBP Accounting Segments Jun 10, 2012 Change 30.106 zIIP SHARE WEIGHTS are now calculated for each LPAR in VMAC7072 all four datasets created by ASUM70PR. VMXG70PR -For the ASUM70PR and ASUMCEC datasets, with different Jun 9, 2012 variable names for each LPAR, the variable names are LPnZHARC ='LPAR n*ZIP SHARE*CURRENT*WEIGHT*PCT' LPnZHARE ='LPAR n*ZIP SHARE*INITIAL*WEIGHT*PCT' -For the ASUM70LP and ASUMCELP datasets, with only one set of variables, the names are: ZIPSHARE='ZIP*INITIAL*SHARE*WEIGHT' ZIPSHARC='ZIP*CURRENT*SHARE*WEIGHT' Since SMF70ACS is currently always zero for zIIPs, the two variables have the same value, but logic is in place that will use SMF70ACS if it is non-zero. Thanks to Rodger Foreman, TransUnion Corp, USA. Thanks to Lindholm Orjan, VOLVO, SWEDEN.
Yüklə 28,67 Mb. Dostları ilə paylaş:
|