* copyright (C) 1984-2019 merrill consultants dallas texas usa
Yüklə 28,67 Mb.
|
|
8 VXVNDSES (8.01) 10 VXAPLSDT (10.02) -Dataset VXPRCMFC is created with TYPE113 variable names, including all of the metrics from John Burg's papers, so the existing ASUM113 dataset can be used to summarize the new hardware counters from either z/VM or z/OS records. -The sort order was changed on some existing datasets that had not previously been validated for the NODUP option. The _Bdddrrr "BY LIST" macro for each dataset has been validated to ensure that PROC SORT NODUP; BY _Bdddrrr; removes duplicates; some existing dataset's _Bdddrrr list was insufficient and had to be extended to ensure the physical adjacency of duplicate records. The validation reads the same MONWRITE file twice and the _SVMXA macro sorts all datasets. The SAS log message for each sort is examined to ensure that exactly one half of the input observations were reported as duplicates. -The validation of the BY LIST with NODUP is NOT because MONWRITE has a duplicate record problem; it is required for the DIF() validation of the MXG deaccumulation logic. Because MONWRITE records contain accumulated values, the deaccumulation logic (a DATA step in the _Sdddrrr macro) uses the same "BY LIST" _Bdddrrr macro as the NODUP did. The deaccumulated datasets are then examined with PROC MEANS for MIN. If a non-accumulated field (cardinal, min, max, end point) is deaccumulated, or if its sort order is not correct, its minimum value will be negative.
source lines inserted, and 730 lines deleted in the main VMACVMXA code member, which now has 24,653 lines. The update took from Monday thru Saturday, 40-50 hours. I documented the original VM/XA MONWRITE development in 1988, 150 hours across 10 days for 75 datasets and 15,000 lines, I think, but I can't find that note right now!
when the same MONWRITE data file was read twice, two MXG created datasets had an odd number of observations, where an even number should have been created. The two datasets VXMTREPR (1.01) and VXMTRDDR (1.14) records are written at MONITOR START, but prior to the MTRSYS (1.04), which contains the GMT Offset (SYSZONE) value. MXG deletes records with SYSZONE missing, because the MRHDRTOD can't be converted to local time and thus is unknown. But because SYSZONE is retained so it can be used for all other records in this collect, if data from a different system is concatenated, the new system's 1.01 record will use the non-missing SYSZONE from the prior system and was output with the wrong MRHDRTOD value. Fortunately, IBM has added SYSZONE field to 1.01 MONITOR START record so the MXG logic now exploit that addition and will use the 1.01 for MONITOR START when it contains SYSZONE.
MONWRITE interval records synchronized with TIME of DAY; the intervals when the MONITOR SAMPLE INTERVAL or the MONITOR START command is issued. A formal requirement has just been submitted, and this text will be updated if IBM accepts that request. In the interim, this example from IBM can be used to STOP and reSTART the monitor with TOD synchronization to second zero of the next minute: /* Make the monitor intervals start on second zero */ 'CP MONITOR STOP' Parse value time('N') with hh ':' mm ':' ss . mm=mm+1 /* Wait for the next minute*/ If ss=59 then mm=mm+1 /*May need a bit more time*/ If mm>60 then do /* Overflow to the hour*/ mm=mm-60 hh=hh+1
end 'WAKEUP' hh':'right(mm,2,0)':00' /*Wait*/ 'CP MONITOR START' /*Start the monitor*/ Exit
and changing to 'WAKEUP' hh':00:00'
To process z/VM 6.2 records with MXG 29.03 or earlier, this code will skip all 0.23 records: //SYSIN DD * %LET MACVMXX= %QUOTE(
IF MRHDRDM=0 AND MRHDRRC=23 THEN DO; INPUT +SKIP @; SKIP=0; MRHDRDM=-99; MRHDRRC=-99; GOTO MWENDIT; END; );
Change 29.100 Support for GDPS Global Mirror V3R8 SMF ID=105 record, EXTY1051 which creates these two new datasets: EXTY1052 dddddd Dataset Description IMAC105 TY1051 TYPE1051 GDPS SESSION DATA VMAC105 TY1052 TYPE1052 GDPS LOGICAL SUBSYSTEM DATA VMXGINIT
Apr 28, 2011 Thanks to Paul Volpi, UHC, USA. Change 29.099 Omegamon User SMF "OMCI" record tested for versions before VMACOMCI testing for SUBTYPE and RECSUBTY, and records from the old Apr 27, 2011 version 420 printed error messages that that version was unknown. But these were ID=112 records with SUBTYPE=203 and RECSUBTY=0, which are "112s" and not "OMCI", so the code now accepts '420' for version but also deletes these non-OMCI records ahead of the version test. Thanks to Richard Schwartz, State Street Bank, USA. Change 29.098 Variables ICFCPUS, IFLCPUS, IFACPUS, ZIPCPUS, only in the VMXG70PR PDB.ASUMCEC dataset, were wrong (too high, they were the Apr 27, 2011 SUM across all LPARs with those specialty engines). Thanks to Otto Burgess, OPM, USA. Change 29.097 INPUT STATEMENT EXCEEDED (on z/OS), INVALID FLOATING POINT EXCICRDD (on ASCII) SMF 110 subtype 1 MNSEGCL=5 records, if any DPL IMAC110 DPL Resource Segments exist (i.e., MNR5NUMX GT 0). VMAC110 DPL segments, new in CICS/TS 4.1, were not input, causing VMXGINIT mis-alignment, but they now create new CICSRDPL dataset. Apr 26, 2011 Also, new variables added by CICS/TS 4.1 are now output in the existing CICSRDS dataset that were overlooked. Thanks to Paul Volpi, UHC, USA. Change 29.096 Documentation only. APAR PK99058 corrects Tivoli Storage VMAC42 Manager z/OS Server Accounting Record CPU usage field, Apr 25, 2011 (variable CLICPUTM in TYPE42AD), in TSM Version 5.5 only, which had failed to populate that field. Thanks to Jacob Nudel, Thomson Reuters, USA.
BLDSMPDB dataset are selected by the PROC COPY from the PDB into Apr 22, 2011 the Day-Of-Weed dataset, and can be a SELECT statement or
VMAC110 (if you did NOT use UTILEXCL to create IMACEXCL). A mass Apr 19, 2011 change command went awry and inserted 16* in all of the time duration variables in blocks of "fall thru" code for CICS/TS 3.2 or later. This SHOULD have printed the MXG ***ERROR VMAC110: CPU 10X LARGER THAN ELAPSED. See Change 29.076 for the CPU 10X LARGER enhancement. Thanks to Matthew Chappell, Dept. of Transport Main Roads, AUSTRALIA Change 29.093 INPUT STATEMENT EXCEEDED for subtype 79; value '1120' was VMAC85 added to the two tests for variable R85PVRM in the block Apr 18, 2011 that reads subtype=79, support z/OS 1.12 INCOMPAT change. Thanks to Robert Chavez, Florida Power and Light, USA. Change 29.092 Variables ZIPCPUS and IFACPUS in PDB.ASUMCEC/PDB.ASUM70PR VMXG70PR were the average number online, but that included parked Apr 13, 2011 time. They are now corrected to count the number of AVERAGE*ONLINE*NOTPARKED specialty engines. Variables NRZIPCPU and NRIFACPU are the number installed. Thanks to Jim Horne, Lowe's Companies, USA. Change 29.091 If MXG's default COMPRESS=YES is changed to COMPRESS=NO, VMAC102 all SQL Text variables are broken into 100 byte chunks Apr 13, 2011 and multiple observations are created in the T102Tnnn datasets, but the last two characters of each chunk have been missing since DB2 V8.1 changed the structure of the length fields; MXG still subtracted 2 bytes which it should not have. DB2 SQL text is created in these IFCIDS: 63 124 140 141 142 145 168 which are now all corrected. Thanks to Mark Tomlinson, Lloyds Banking, ENGLAND. Thanks to Stephen Hoar, Lloyds Banking, ENGLAND. Change 29.090 Typo for the IMS08D and IMS0A08 datasets _Wdddddd entries VMACIMS had _VIMS08 _KIMS08 which are now _VIMS08D _KIMS08D and Apr 13, 2011 _VIMS0A8 and _KIMS0A8 respectively. Since the _VIMS08 and _VIMS08D keep the same variables, the IMS0708 dataset was not impacted, and, fortunately, no one uses IMS0A78. Thanks to Rudolf Sauer, T-Systems, GERMANY Change 29.089 -The z/VM MONWRITE dataset PDB.VXBYUSR has one observation VMACVMXA for every VMDCPUAD (CPU ADDRESS) configured for each VM, VMXGINIT so it doesn't have the interval total for each machine. Apr 13, 2011 The new PDB.VXINTUSR sums PDB.VXBYUSR to create one obs for each interval for each machine, counting configured (ENGCONFG) and online (ENGONLIN) engines. -Variables VMDVTMP VMDTTMP VMDVTMS VMDTTMS are correctly deaccumulated with this change. Thanks to Ron Lewis, State Street Bank, USA.
VMACTMDB DBHCEUID DBHCEUTX DBHCEUWN Apr 12, 2011 (and should have been added a long time ago!). Thanks to Patricia Abel, Regie des rentes du Quebec, CANADA. Thanks to Liliane Paquet, Centre de services partages Quebec, CANADA.
IMACIMS inconsistent; 10.1 or 11.1 were listed, but the values Apr 12, 2011 needed are only 10.0 and 11.0 (so the misleading values worked fine!). And Change 28.311 did not change the datasets created; that change only restructured the internal IMS processing code to separate and then recombine the TM and DBCTLs. Thanks to Daniel Strgarsek, SAS Institute, GERMANY. ====== Changes thru 29.086 were in MXG 29.03 dated Apr 11, 2011======== Change 29.086 The QA conflict report from DOCVER showed SYSTEM was $8 ANALID in PDB.SMFRECNT, but SYSTEM is always $4. After 2 hours Apr 10, 2011 of tests with inserted PROC CONTENTS, I found it only occurred when there were no observations in TYPEID, which is normal for the QASAS job that creates DOCVER, and then remembered that when the old PROC FREQ was replaced with the enhanced ANALID (with PROC TABULATE to capture both counts and bytes), an extra step was needed to create the PDB.SMFRECNT (because PROC TABULATE didn't, with no obs), and finally found the statement SYSTEM=' '; that should have been SYSTEM=' '; to set its length to $4.
VMXGSRCH missing semicolon was inserted, although no syntax error Apr 10, 2011 was reported. -If VARS= is specified without VALUE=, the results are the list of datasets that contain that variable.
VGETENG -Variables QWHSACE QWHSMTN QWACACE ACE are now consistent VMACDB2 LENGTH 5 and FORMAT HEX8 addresses, QWARACE is LENGTH 8 VMAC102 and FORMAT HEX16 in VMACDB2/VMACDB2H/VMAC102. VMACDB2H -Variables TOKLEN and TOKVERS in VMAC80A are labeled. VMAC80A -Variable CTGAPPLQ is labeled, comments for CTGAPLID now VMAC111 match in VMAC111. Apr 10, 2011 Thanks to Chris Weston, SAS/ITRM Development, USA.
ANALDB2R not detected because it was zero in the test SMF data. Apr 9, 2011 -May 1: The formula for calculating the average time (per May 1, 2011 thread) that was "not accounted for" was revised, thanks to this equation provided by IBM DB2 Support in response to a customer PMR, i.e., the Class 2 Elapsed times minus the sum of Class 2 CPU and Class 3 Suspension durations: AVG=(
/*** CLASS 2 ELAPSED ***/ SUM(QWACASC+QWACSPEB+QWACUDEB+QWACTRET+QWACTREE,0) /**** CLASS 2 CPU ****/ -SUM(QWACAJST,QWACSPTT,QWACUDTT,QWACTRTT,QWACTRTE,0) /**** CLASS 3 SUSPENSIONS ****/ -SUM(QWACAWTL,QWACAWTI,QWACAWTR,QWACAWTW,QWACAWTE, QWACALOG,QWACAWAR,QWACAWDR,QWACAWCL,QWACAWTP, QWACCAST,QWACAWTG,QWACAWTJ,0))/THREADS; -The Accounting Trace Reports had many fields missing in the headers because they had not been listed in the SORTBY= arguments. -For the ACCOUNTING reports, selection was not being done. If you specified DB2=DB20 you still got all of the data for all of the subsystems. Thanks to Neil Ervin, Wells Fargo Bank, USA.
ASUM70PR because PDB.ASUM70PR/ASUM70LP CAN BE TERRIBLY WRONG for Apr 9, 2011 many of the LPAR-Specific Variables, when IRD is active and/or Hiperdispatch is enabled. In those environments, only the "LPn" variables for the "THIS LPAR" observation (i.e., "THIS SYSTEM") in "SYSTEM-LEVEL" ASUM70PR/ASUM70LP datasets are always valid. These LPAR-Specific variables: LPnNRPRC LPnDUR LPnLAC LPnONT LPnPAT LPnWST LPCTnBY LPCTnOV LPnZIUTM LPnZIKTM LPnIFUTM LPnIFKTM will be WRONG in the ASUM70PR/ASUM70LP observations from the "OTHER LPARs", because those LPAR-Specific variables are based on SMF70ONT/SMF70PAT, which are ONLY valid in the "THIS LPAR" observation. This PROC PRINT shows the six ASUM70PR observations from each of six SYSTEMs, with the set of LPAR-Specific fields for LPAR 2 (SYSA). You can see that ONLY the observation in ASUM70PR for SYSTEM=SYSA, the "THIS LPAR, THIS SYSTEM" observation, are valid and match the ASUMCEC observation: (Note that not ALL of the variables are WRONG!). SYSTEM LP2NAME LP2DUR LP2UPDTM LP2UEDTM LP2MGTTM ******
SYSK SYSA 6:00:00.01 1:21:32.11 1:21:00.97 0:00:31.14 SYSA SYSA 2:33:48.28 1:21:31.41 1:21:00.27 0:00:31.14 SYSC SYSA 6:00:00.43 1:21:32.38 1:21:01.24 0:00:31.14 SYSD SYSA 6:00:00.30 1:21:32.50 1:21:01.36 0:00:31.14 SYSG SYSA 6:00:01.16 1:21:32.21 1:21:01.07 0:00:31.14 SYST SYSA 6:00:00.09 1:21:32.20 1:21:01.07 0:00:31.14 ASUMCEC: SYSA 2:33:48.28 1:21:31.41 1:21:00.27 0:00:31.14 SYSTEM LPCT2BY LPCT2OV PCTL2BY PCTL2OV LP2NRPRC LP2BDA ******* ******* ******** SYSK 22.64 0.14416 22.6486 0.14416 6.0 8 SYSA 53.00 0.33744 22.6521 0.14421 2.6 8 SYSC 22.64 0.14416 22.6495 0.14416 6.0 8 SYSD 22.65 0.14417 22.6502 0.14417 6.0 8 SYSG 22.64 0.14416 22.6479 0.14416 6.0 8 SYST 22.64 0.14416 22.6490 0.14416 6.0 8 ASUMCEC: 53.00 0.33744 22.6454 0.14416 2.6 8 SYSTEM LP2SHARC LP2SHARE LP2LAC LP2MSU LP2MSUHR ******
SYSK 16.2389 13 . 129.378 129.378 SYSA 16.2420 13 29.2360 129.360 129.398 SYSC 16.2389 13 . 129.385 129.383 SYSD 16.2389 13 . 129.388 129.387 SYSG 16.2389 13 . 129.381 129.374 SYST 16.2389 13 . 129.381 129.380 ASUMCEC: 16.2420 13 29.2360 129.360 129.360 SYSTEM LP2CSF LP2ONT LP2WST LP2ZIPTM ****** ****** SYSK 10G 6:00:00.01 3:59:14.35 0.00:18.94 SYSA 10G 2:33:47.23 0:33:06.46 0.00:18.94 SYSC 10G 6:00:00.43 3:59:15.35 0.00:18.94 SYSD 10G 6:00:00.30 3:59:15.46 0.00:18.94 SYSG 10G 6:00:01.16 3:59:15.21 0.00:18.94 SYST 10G 6:00:00.09 3:59:14.81 0.00:18.94 ASUMCEC: 10G 2:33:47.23 0:33:06.46 0.00:18.94 SYSTEM LP2ZIUTM LP2ZIKTM LP2ZIWTM ******** ******** ******** SYSK 2:00:00.00 . 1:59:41.11 SYSA 1:59:57.87 0:00:00.00 1:59:38.98 SYSC 2:00:00.14 . 1:59:41.25 SYSD 2:00:00.10 . 1:59:41.20 SYSG 2:00:00.39 . 1:59:41.49 SYST 2:00:00.03 . 1:59:41.13 ASUMCEC: 1:59:57.87 0:00:00.00 1:59:38.98
variables identified above that can be WRONG. -And, for ASUMCEC to ALWAYS BE RIGHT, you MUST have READ the PDB.TYPE70PR observations FOR ALL LPARS (ALL SYSTEMS) as input to ASUM70PR when you create PDB.ASUMCEC/CELP. -This change was ONLY documentation; no code was changed. Thanks to Larry Stahl, IBM Global Services, USA.
VMXG70PR HOUR, which matched the default for ASUMCEC/ASUMCELP, but Apr 9, 2011 now INTERVAL=&CECINTRV is used so the group data interval matches the CEC interval data, if you change CECINTRV. With hindsight, these two datasets should have been named ASUMCEGC and ASUMCEGL because both are summarized at the CEC level (e.g., by CECSER, and NOT by SYSPLEX SYSTEM), but it's too late to change dataset names now. -New variable MAX70NSW, the maximum percent of time when the LPAR was soft-capped, is now created in PDB.ASUM70GL, as the hourly average in SMF70NSW could mask intervals that were capped. Thanks to Chuck Hopf, Independent Consultant, USA.
VMAC120 that variable in dataset TYP1209E. While up to 5 user VMXGINIT segments of 2048 bytes each per record can be created, Apr 8, 2011 this change keeps only the first segment, and only the Nov 8, 2011 first 12 bytes of the optional field are kept in SM1209FH although temporary variable SM1209F input all 2048 and is to be used as the source of SM1209FH, which can contain HEX, EBCDIC or ASCII text. The MXG default is ASCII, to match the original test data that was received, but that can be tailored if you have EBCDIC or HEX data values. -Variable SM1209FB is the data length in SM1209FH, and the variable SM1209FF contains the user-chosen datatype, and temporary variable SM1209F was input with $VARYING2048., so if your 12-bytes were EBCDIC instead of MXG's ASCII default, then you would insert this statement SM1209FH=INPUT(SM1209F,$EBCDIC12.); in your EXT1209E to input the text as EBCDIC, and/or you could use your installer's chosen SM1209FF datatype value to conditionally input as ASCII/EBCDIC/SUBSTR/etc. -The length of a character variable can NOT be changed in a dataset exit member EXddddd. Only numeric variables can have their length changed in a dataset exit member, as SAS uses the first instance for character length and the last LENGTH statement for numeric variables. -The existing IMACFILE/MACFILE exit is taken before the LENGTH statements in all VMACs are compiled, so it could be used to change length of SM1209FH with this syntax: //SYSIN DD * %LET MACFILE= %QUOTE( LENGTH SM1209FH $40; ); %INCLUDE SOURCLIB(BUILDPDB); in the job that reads the SMF 120 records. However that is not the real purpose of the IMACFILE exit, and it may already exist for record selection, and the insertion of the LENGTH statement could cause non-fatal messages with UNINITIALIZED VARIABLE SM1209FH if the program that is %INCLUDEd doesn't process SMF 120 records. Using MACFILE is totally slick but not righteous; there's a better way. -Nov 8: This change creates macro variable &VARSM1209FHLN in VMXGINIT and uses it LENGTH SM1209FH $&VARSM1209LN; in VMAC120, so that the default of 8 can be more easily changed (for example, to $40) and converted to EBCDIC: //SYSIN DD * %LET MACKEEP= %QUOTE (
MACRO _ET1209E SM1209FH=INPUT(SM1209F,$EBCDIC12.); %% );
%INCLUDE SOURCLIB(BUILDPDB); -Nov 8: Change text was completely rewritten. Thanks to Larry Gray, Lowe's Companies, USA. Thanks to Jim Horne, Lowe's Companies, USA. Change 29.080 -New variables from Meral's excellent SHARE paper at VMAC113 http://share.confex.com/share/116/webprogram/authort.html Apr 7, 2011 are created in TYPE113 and ASUM113 datasets: Apr 19, 2011 DWINSORM='DIR WRITES*L1 INST CACHE*FROM REMOTE' DWDASORM='DIR WRITES*L1 DATA CACHE*FROM REMOTE' with different equations for z10 vs z196 calculation. -These original z10 counters were defined as: EXTND128='DIRWRIT*TO L1-I*RETURNED*FROM L2' EXTND129='DIRWRIT*TO L1-D*INSTLD*FROM L2' but the z196 reversed contents so the labels are changed EXTND128='DIRWRIT*TO L1-D*RETURNED*FROM L2' EXTND129='DIRWRIT*TO L1-I*INSTLD*FROM L2' with the Data count in 128 and the Instructions in 129. Since there is no way to have two different labels for the same SAS variable, I chose to use the z196 choice, hoping z10 users will find this note. Fortunately, all calculations use the sum of this pair of counters, so the impact is minor unless you are looking in great detail level for the old z10 processor. Apr 19: SM113DOL corrected to SM113DON. Thanks to Meral Temel, Garanti Teknoloji, TURKEY. Thanks to Don Deese, (CPExpert), Computer Management Sciences, USA. Thanks to Chris Weston, SAS ITRM Development, USA.
VMACSMF using the SAS ftp access method, SAS would stop after Apr 7, 2011 writing a horrendous SAS log (6 MILLION PAGES, not lines) of MXG messages "FIRST RECORD IN GROUP SYSTEM= SMFTIME=". The rerun was always successful, suggesting the error is in the ftp Server, but this enhancement will stop the MXG job by detecting that missing value in SMFTIME. SAS was executing under Windows/XP with Service Pack 3. Thanks to Bruce Orr, U.S. Customs and Border Protection, USA.
FORMATS IBM change in the LRECL for QAPMDISK file to 539). VMACQACS Only the QAPMCONF/QAPMDISK/QAPMJOBL/QAPMPOLL/QAPMSYSL Apr 7, 2011 files have been validated with 7.1 records, so it is possible other files may also be INCOMPATIBLE. There are also a number of new files that are not supported, until a user needs those data and provides test files. -Dataset QAPMCONF, new variables: GDESF1T GDESF1S GDESFT GDESG1- GDESG9 GDESGA GDESHT GDESMT GDESPF and new formats are created in FORMATS member, so that you must update your format library. -Dataset QAPMCONF, new variables DSPTROP DSPTWOO DSWWWNN In addition, variable DSIOARN was documented and INPUT as $EBCDIC15., but data in the records show only 10 bytes so the INPUT was reduced and PMR was opened with IBM Support to determine the true length of the field. Thanks to Paul Naddeo, FISERV, USA. Thanks to David Bixler, FISERV, USA. Change 29.077 -Executing z/OS under z/VM caused MXG to print 3 messages: VMAC7072 MXGNOTE:CPUID SECTION ERROR. INVALID RECORD ... DELETED. Apr 2, 2011 but the TYPE70 observation had already been output in the Yüklə 28,67 Mb. Dostları ilə paylaş:
|