* copyright (C) 1984-2019 merrill consultants dallas texas usa
Yüklə 28,67 Mb.
|
|
RMF Monitor III Data Set is selected to reduce overhead. -Issue Space messages RMFV030I and RMFV031I only if the RMF Monitor III Data Set is selected to reduce overhead. -When ASMRMFV execution methods were mixed in a single run (this is supported) the summary message RMFV101I was not reporting statistics by DDNAME prefix correctly. -For example, using a static JCL DD statement for an RMF data set while also using the CLRMFV Clist or using the INDSNAME= parameter would be a mixing of methods. Now multiple RMFV101I messages will be issued for RMFC*, RMFD*, and RMFV* DDNAME prefixes as required. -Last Open message RMFV017I is now an RMFV008I message and is now part of that multi-line display group produced as each RMF III data set is opened. -Origin message RMFV009I is split into two parts so that the Sysplex and System Id information appears near the point in the ASMRMFV log where SYSPLEX= and SYSTEM= matching occur. -The second part of the original RMFV009I message is now message RMFV017I showing RMF and Z/OS versions and the timestamp value when these were first in effect. -The MAXFINDS= parameter limit is lowered to a more reasonable 99,999 maximum down from a 99,999,999,999 value.
-Error messages that display an invalid character both in EBCDIC and in hex are now improved for better visibility. -Explicit coding of DOW=ALL, SYSPLEX=ALL, or SYSTEM=ALL is documented to explain that this resets the corresponding internal table(s) to empty. Any prior specifications for the corresponding table(s) in the current ASMRMFV run are lost. Any subsequent specifications will be added to the respective table(s) during the run. -Definitions for the terms "Keyword", "Range", and "Pattern" are added to Section 2 "Terminology" in ASMRMFV and ADOCRMFV member documentation. -NODUPDSN/DUPDSN, SYSPLEX= and, SYSTEM= parameter documentation is added to Section 5 "Input Data Selection Parameters" in ASMRMFV and ADOCRMFV members. -SHOWMATCH/NOSHOWMATCH parameter documentation is added to Section 6 "Report Control Parameters" in ASMRMFV and ADOCRMFV members. -DUPERR=ABEND/IGNORE/WARN parameter documentation is added to Section 8 "Error Handling Parameters" in ASMRMFV and ADOCRMFV members. -Updates for new and revised messages are made to Section 12 "Messages" in ASMRMFV and ADOCRMFV members. -A new Filter Scope Table is added to Section 13 "Filtered Records" in ASMRMFV and ADOCRMFV members. This shows the data filters available in ASMRMFV, to which RMF III tables they are applied, the order of application, and the level of data affected. -Section 25 "Summary" is updated to add new parameters and improve text alignments in ASMRMFV and ADOCRMFV member documentation. -Three new examples showing use of SYSPLEX= and SYSTEM= parameters are added to the sample documentation members JCLRMFV, JCLCRMFV, and JCLDRMFV. -At the ASMRMFV 32.225 level only FROMDATE=TODAY or TODATE=TODAY settings and all related variants and equivalents were creating an invalid date of 01JAN1900 for date selection because the current date was not being loaded in SETDATE processing for these settings. -REQUIREMENT: In order to implement these features the ASMRMFV utility program from this MXG change must be installed. See MXG SOURCLIB member JCLASM3 for sample JCL for the assembly and link-edit install steps. Thanks to Rodger Foreman, Trans Union, USA
VMACBVIR had only 31 Pool Segments, when all 32 pool segments are Oct 30, 2014 normally always present. These records had BVIRLEN=8256, but 8545 bytes (32*256+353) are needed for 32 pools. The existing BVIRLEN GE 8512 test was reduced to 3256 as record does contain the LIBxxxxx descriptor variables. -The first three instances of these short records will print a log message. -A debugging PUT with _N_= GCNRCLUS= LENLEFT= was removed. Thanks to Olivier Bigeon, SOC GEN, FRANCE. Thanks to Pierre-Pascal Joulin, SOC GEN, FRANCE. Thanks to Samsla Assanaly, SOC GEN, FRANCE. Change 32.248 Under WPS, BLDSMPDB failed on z/OS because it generated BLDSMPDB RECFM=S370VBS instead of RECFM=VBS because it incorrectly Oct 28, 2014 changed OPSYS to 'os' with a %LET OPSYS=%LOWCASE(OPSYS). The same code was generated under SAS, but there was no error because SAS has supported both S370VBS and VBS since SAS Version 8, although that was never documented. The low case value was not visible in SYMBOLGEN messages, because OPTIONS CAPSOUT is specified in MXG CONFIGxx. Thanks to Scottie Mills, TI, USA.
VMACCLAR Version 26 thru 33. Most of the changes are new counters. Oct 24, 2014 The "clarsan" object is really a special case of clarsnap so clarsan was repurposed as clarpool. Instrumentation was added to help build keep lists for the various object's new counters. Thanks to James Quigley, CONED, USA.
VMAC7072 be large, for Service Classes with Percentage Goal and Oct 24, 2014 a small number of transactions with a high goal objective that was NOT met (so PERFINDX must be greater than one). A Service Class with 19 transactions had 18 complete in the first response bucket (.5) but one longer transaction was not counted in the thirteenth response bucket (4). So, while 94% of the transactions met their goal, the 97% objective goal objective was NOT MET (.97*19=18.43 trans) and due to an MXG logic error, PERFINDX was not set. Now, when TRANS GT 0, PERFINDX is set to RTSMAP(13), which for this case was 4.0. Note that PERFINDX will always be a missing value when TRANS=0, or for R723CRGF= 'S' (SYSTEM) or 'D' (DISCRETIONARY) goals. Thanks to Tom Kelman, Xerox, USA.
MOBWRK73 incorrectly required //TYPE70 DD statement. Eliminated, Oct 21, 2014 but //TYPE70 DD UNIT=SYSDA,SPACE=(CYL,(50)) circumvents. Thanks to Scottie Long, Navy Federal Credit Union, USA. Change 32.243 If you use INITIT=Mx where X was the day of the month on VMXG2DTE which you wanted to INIT the output, the first day's data Oct 21, 2014 would have been missing. For example, if you specified INITIT=M2 so that all the observations based on ZDATE would be in each month's dataset, the data for the first of each month would be missing because of an incorrect calculation: when Wx is being used, 1 is added to the date since the days of the week start with 0, but using Mx, that +1 caused the data to be missing. Thanks to Tom MacCabe, Dominion Resource Services, USA. Change 32.242 z/VM Interval ENDTIME is set from first 0.1 (CPU) record, VMACVMXA selecting CPUADDR='0000'x. But the first 0.1 record is Oct 20, 2014 not always CPUADDR zero! CPUADDR=0001/0002/0003/0000x Oct 28, 2014 data records had the MRHDRTOD in the fourth record SEVEN MICROSECONDS later than the time in the first three. This caused those first three observations to be output with the (incorrect) prior ENDTIME value, which then caused spurious observations with many missing values in dataset VMXAINTV. Because the z/VM MONWRITE data file is weird, consisting of 4K block containing variable records that span blocks, and because four 0.1 records fill a block, finding that first record requires comparing the stored FOUNDINTBLOCK block number (_N_) with the _N_ of this new 0.1 and only updating ENDTIME if this block is more than 100 blocks later (256 CPUs would need 32 blocks). -Lost Interval Data in VMXAINTV dataset will ALWAYS occur for the first interval (START MONITOR message on the log) because the data values are accumulated but there is no prior record for the DIF() function; so if you have many START MONITOR messages, each one is a lost interval. MONWRITE really needs to run for 23.99 hours, STOP and then START (and look at the REXX code in Change 29.101 that will synchronize your MONWRITE data to the hour.) and thus lose only that one midnight interval. Thanks to Kim Morrell, Royal Canadian Mounted Police, CANADA
VMACDB2H EXCEEDED error (LENLEFT=4,QWHSTYP=8) and QWHUCPU/QWHUCNT Oct 20, 2014 fields contain text: QWHUCPU='000000'X!!'BCDIC', and the incorrect decompression in V1 also caused INVALID DISTRIB HEADER messages (but DB2 APAR PM32425 was installed). All errors were eliminated using the current EXITCICS V3. However, protection is added for the EXCEEDED error. On z/OS, EXITCICS decompresses the record before the SAS INPUT statement, so a hex dump of the input record will be the uncompressed record, but on ASCII, where MXGDECOM must be used, after the record has been INPUT, a hex dump will be of the compressed records. See comments in both VMAC110 and VMACDB2 to get an uncompressed hex dump. Thanks to Paul Maradin, HP, USA. ====== Changes thru 32.240 were in MXG 32.10 dated Oct 16, 2014========= Change 32.240 First 32.10. INPUT EXCEEDED z/OS 2.1 SMF 6 Printway with VMAC6 URI but no Accounting fields was not expected, but now is Oct 16, 2014 protected. Thanks to Jennifer D. Ayers, West Virginia State Government, USA. Change 32.239 WebSphere SMF 120 Dataset TYP1209E had observations with VMAC120 a negative DELTA120TM that should not have been output. Oct 15, 2014 They are first instances of a by group, so no deaccum is possible, but the test "IF DELTA120TM GT ." was true for a negative. "IF DELTA120TM GT 0" is the required test. Thanks to Wayne Bell, UniGroup, USA. Change 32.238 Support "ALL" Tandem Measure records in a single file. IHDRTAND This new support reads the //TANDALL DD, which can be TYPETAND the ALL record file using this JCL: TYPETANX // EXEC MXGSAS TYPSTAND //PDB DD DSN=YOUR.OUTPUT.TANDEM.PDB,DISP=. . . . TYPSTANX //TANDALL DD DSN=YOUR.TANDEM.ALL.INPUT,DISP=SHR VMACTAND //SYSIN DD * VMACTANX %INCLUDE SOURCLIB(TYPSTAND); VMXGINIT or can be the individual "TYPE" files, concatenated: Oct 12, 2014 //TANDALL DD DSN=YOUR.TANDEM.CPU.FILE,DISP=SHR Oct 16, 2014 // DD DSN=YOUR.TANDEM.DISC.FILE,DISP=SHR // DD DSN=YOUR.TANDEM.PROC.FILE,DISP=SHR //SYSIN DD * %INCLUDE SOURCLIB(TYPSTAND); The CPU, DISC and PROC types (LOADID) have been tested. -The "TAND" Header Exit IHDRTAND invokes &MACTANH which can be used to select which record types are output: %LET MACTANH= %QUOTE( IF LOADID='CPU'; ); %INCLUDE SOURCLIB(TYPSTAND); (If the original multiple-file-name program is still needed, use TYPETANX or TYPSTANX.) Thanks to Paul Bennett, Euroclear, BELGIUM ====== Changes thru 32.237 were in MXG 32.10 dated Oct 10, 2014========= Change 32.237 New variables added to ASUMDBSS for DBAT analysis: VMXGDBSS ID= qdstnads qdstnard qdstqcit Oct 10, 2014 MIN=qdstnqmn MAX=qdstnccw qdstnqmx qdstnqav qdstmard SUM=qdstnqsc Thanks to Wayne Bell, UniGroup, USA. Change 32.236 -InfoPrint/Printway SMF 6 SUBSYS='TCPE' Extended Mode File IMAC6ESS Transfer INDC=7 variables PAGECNT/NRLINES/OUTDEVCE are VMAC6 zero/zero/blank as noted in the SMF Manual. Oct 9, 2014 -Variable SMF6URI (VMAC6) was increased from $64 to $128. Oct 16, 2014 -Variable ESSFSSDT (IMAC6ESS) increased from $67 to $128. -New in z/OS 2.1, the JOB Accounting fields in SMF6ACCT are now decoded and NRACCTFL, ACCOUNTn, and LENACCTn variables are created in TYPE6 dataset. Both BUILD005 and BUIL3005 are also updated to use those values to populate the existing account variables in PDB.PRINT when no 30-1, 30-5, and no type 26 records were found. SEE CHANGE 32.240, in MXG 32.10 re-dated Oct 16, 2014. Thanks to Teuvo Virsu, TIETO, FINLAND.
VMAC116
Oct 7, 2014 Change 32.234 The _IDaaaa=512 detection did not work correctly; all of VMACXXXX Changes 32.224, 32.221, 32.198, 32.180 and 32.149 that Oct 7, 2014 attempted to detect the un-changed default are removed. Processing a USER SMF with the default MACRO _IDaaaa will create zero obs in those datasets, as was always the case previously. This attempt to alert the user why they had zero obs could cause ALL of the USER SMF datasets to have zero observations, so it has been removed. The primary culprit was my choice to include the TMNT USER SMF record in the default BUILDPDB/UTILBLDP, even when you had not asked for it. And the circumvention if you get the _IDTMNT unchanged log message, is to request the VMACTMNT from MXG 32.10 to circumvent, or to install MXG 32.10. Change 32.233 Netview INPUT STATEMENT EXCEEDED for SUBTYPE=3 because I VMAC38 thought S38DSOSN, active spans, described the length of Oct 7, 2014 S38DSOSP, but it does not; code was revised. Thanks to Coen Wessels, IBM, Switzerland. Thanks to Pierre Beda, IBM, Switzerland.
VMAC92
Oct 2, 2014 Change 32.231 Support for DB2 V11 IFCID 225 IRLM STORAGE INFORMATION in VMACDB2 new section 6 adds these variables to DB2STATS dataset: Sep 30, 2014 QW0225I_ABCSA /*CURRENT*USED 64-BIT*COMMON*/ QW0225I_ABCSH /*HWM*FOR 64-BIT COMMON*/ QW0225I_BBPVT /*CURRENT*USED 31-BIT*IRLM*PRIVATE* QW0225I_BBPVH /*HWM FOR*31-BIT IRLM*PRIVATE*/ QW0225I_ABPVT /*CURRENT*USED 64-BIT*IRLM*PRIVATE* QW0225I_ABPVH /*HWM FOR*64-BIT IRLM*PRIVATE*/ QW0225I_BBECSA /*CURRENT*USED*ECSA IRLM*POOLS*/ QW0225I_BBECSAH /*ECSA*HWM*IRLM*POOLS*/ QW0225I_BPMAX /*THRESHOLD*31-BIT*IRLM*NORMAL*/ QW0225I_APMAX /*THRESHOLD*64-BIT*IRLM*NORMAL*/ and QW0225DMH is now correctly INPUT for DB2 V11 when it exists.
Thanks to Ralph C. Baechle, Deere & Company, USA. Thanks to Kerry Sommers, Deere & Company, USA. Change 32.230 Undocumented 81-byte SMF14STY=01 segment caused remaining VMAC1415 segments to be skipped. SMF Manual only documents 80. Sep 29, 2014 Extra byte now input into SMF14UNK while IBM queried, and all SMF14STY segments are now protected using SMF30ESL to skip future new bytes, documented or undocumented. Thanks to Carl D. Ellis, Wells Fargo, USA. Change 32.229 -Only these NDM _SNDMxxx are PROC SORTs with NODUP to PDB: VMACNDM CS/CF/EI/FA/JX/DS/MF/PE/PK/QE/RE/RO/S2/SC/SD/SH/SY/TR/TX Sep 29, 2014 and CT. All other _SNDMxxx had a DATA step that copied Oct 5, 2014 to //PDB, but that doesn't propagate the Dataset Label, Oct 7, 2014 nor remove duplicates. (I use a DATA step instead of SORT Oct 9, 2014 in an _Sdddddd sort macro when I don't have any data, so I can't validate the BY list for the NODUP removal. When a customer provides data, I validate the BY list and use the PROC SORT NODUP in place of the DATA step.) But, the BY list CAN be built from MXG code, so this was done and all NDM _Sdddddd sort macros now use PROC SORT. -The table in comments in VMACNDM was updated to identify the datasets that have been populated with observations. -These datasets _SNDMxxx were updated, but they all still have zero observations, so their new BY list has not been data-validated for NODUP: CS CX GF HW HW2 CS EI JX LS MF PE PX RE RO S2 SC SH ST TP TR TX (If you have obs in these datasets, you can use the UTILNODU program to confirm my BY list is sufficient, or send your SMF data to support for examination.) -Variables added to the NDMCT dataset: NDMZFBA1='ZFBA*DEVICE*RANGE*ONE' NDMZFBA2='ZFBA*DEVICE*RANGE*TWO' NDMZFBA1='SEND*ZLIB*VERSION' NDMZFBA2='RECV*ZLIB*VERSION' -Dataset NDMPT variables NDMSUBJOB/NDMSUBJID were always blank because the MXG logic for the Extension segment was not correct. But there are new PT fields that are NOT documented in the DSECT, in particular, PTDSNAME and several character and numeric fields now INPUT in new PTUNCHx and PTUNNRy character and numeric variables until updated documentation is available. Thanks to Randy Hewitt, HP, CANADA. Change 32.228 Only 240 characters of IMS Log Input Message, MSGTEXT, VMACIMS were kept, but that text can be much longer and may be Sep 27, 2014 needed to identify your IMS Mobile Workload transactions. So INPUT MSGTEXT $VARYING32000 MSGLEN @; is now used, but with LENGTH MSGTEXT $240 added to keep the same length. So if YOU do need to access data in MSGTEXT, you would tailor the EXIMS01/EXIMS01M dataset exit members to test the text and could use existing SMSGTEXT variable ($40) for your flag, perhaps with logic like this: IF INDEX(MSGTEXT,'MOBILE') GT 0 THEN SMSGTEXT='MOB'; before the OUTPUT statement in those EXdddddd members. Or, you could create your own variable in those exits: LABEL MYTEXT='ALL*32000*BYTES OF*MSGTEXT'; MYTEXT=SUBSTR(MSGTEXT,1,32000); and then use %LET MACKEEP= MACRO _KIMS01 MYTEXT % MACRO _KIMS01M MYTEXT % ; to add variable MYTEXT to each of those datasets. Variable MSGSZIN is the actual MSGLEN of MSGTEXT.
VMACNMON 12 hours later than actual, when there were BBBP records Sep 26, 2014 after the last ZZZZ, because MXG code incorrectly updated ENDTIME when it should have updated variable BBBPEND049. Thanks to Xiaobo Zhang, FIServ, USA.
UTILBLDP when BUILDPDB=YES was used; if they existed in your MXG Sep 19, 2014 USERID.SOURCLIB, then they were correctly included, but if they were only specified in your UTILBLDP text, the default members in the SOURCLIB were used. Thanks to Doug Medland, IBM Global Services, USA. Change 32.225 -RMF III Date/Time selection enhancements, fixes, ADOCRMFV and documentation upgrades. ASMRMFV -New parameter WINDOW (alias WIN) allows selection of JCLRMFV non-contiguous data by time range for multiple days JCLCRMFV and is explained below. JCLDRMFV -New parameter NOWINDOW (alias NOWIN) provides the Sep 18, 2014 behavior of prior ASMRMFV versions in most cases and is Sep 22, 2014 the default. Nov 25, 2014 -New parameter DOW= allows RMF III data selection by day of the week and is also explained below. -The FROMTIME= value may now exceed TOTIME= value even for a single day selection. This condition was previously flagged as an error, but will now be handled as an implicit WINDOW request. -WINDOW/NOWINDOW processing and interaction with the FROMDATE=, TODATE=, FROMTIME=, and TOTIME= parameters is best explained with the following examples.
TOTIMEs so that RMF Monitor III Sample Sets that begin in any part of a final minute of a time range are selected. For example, TOTIME=1559 becomes 15:59:59.999999 for data selection purposes.
and WINDOW or NOWINDOW (default) in effect FROMDATE=01OCT2014 TODATE=01OCT2014 FROMTIME=0800 TOTIME=1559 | 01 OCT 2014 | | Select | +-------<======>-------+ 0 0 1 0
0 8 5 0 : : : :
0 0 5 0 0 0 9 0
and WINDOW or NOWINDOW (default) in effect This is a NEW behavior previously an error. FROMDATE=01OCT2014 TODATE=01OCT2014 FROMTIME=1600 TOTIME=0759 | 01 OCT 2014 | |Select Select| <======>--------<======> 0 0 1 2
0 7 6 3 : : : :
0 5 0 5 0 9 0 9
NOWINDOW (default) in effect
FROMTIME=0800 TOTIME=1559 | 01 OCT 2014 | 02 OCT 2014 | 03 OCT 2014 | | Select | Select | Select | +-----<===========|=================|===========>-----+ 0 0 1 0 0 1 0 0 1 0 0 8 5 0 8 5 0 8 5 0 : : : : : : : : : : 0 0 5 0 0 5 0 0 5 0 0 0 9 0 0 9 0 0 9 0 Case 4: FROMTIME= LE TOTIME= for MULTIPLE days and WINDOW in effect. This is a NEW behavior. FROMDATE=01OCT2014 TODATE=03OCT2014 WINDOW FROMTIME=0800 TOTIME=1559 | 01 OCT 2014 | 02 OCT 2014 | 03 OCT 2014 | | Select | Select | Select | +-----<=====>-----|-----<=====>-----|-----<=====>-----| 0 0 1 0 0 1 0 0 1 0 0 8 5 0 8 5 0 8 5 0 : : : : : : : : : : 0 0 5 0 0 5 0 0 5 0 0 0 9 0 0 9 0 0 9 0 Case 5: FROMTIME= GT TOTIME= for MULTIPLE days and NOWINDOW (default) in effect FROMDATE=01OCT2014 TODATE=03OCT2014 NOWINDOW FROMTIME=1600 TOTIME=0759 | 01 OCT 2014 | 02 OCT 2014 | 03 OCT 2014 | | Select| Select | Select | +-----+----<======|=================|=====>-----+-----+ 0 0 1 0 0 1 0 0 1 0 0 8 6 0 8 6 0 7 6 0 : : : : : : : : : : 0 0 0 0 0 0 0 5 0 0 0 0 0 0 0 0 0 9 0 0 Case 6: FROMTIME= GT TOTIME= for MULTIPLE days and WINDOW in effect. This is a NEW behavior. FROMDATE=01OCT2014 TODATE=03OCT2014 WINDOW FROMTIME=1600 TOTIME=0759 | 01 OCT 2014 | 02 OCT 2014 | 03 OCT 2014 | |Select Select Select Select| <=====>-----<=====|=====>-----<=====|=====>-----<=====> 0 0 1 0 0 1 0 0 1 2 0 7 6 0 7 6 0 7 6 3 : : : : : : : : : : 0 5 0 0 5 0 0 5 0 5 0 9 0 0 9 0 0 9 0 9 -See the documentation in ASMRMFV or ADOCRMFV members for more details on WINDOW/NOWINDOW. -Five more examples have been added to each of the JCLRMFV, JCLCRMFV, and JCLDRMFV sample JCL members showing use of the new WINDOW parameter. -Filter messages RMFV006I can now appear as multiple pairs showing begin and end time stamps with one set for each day when WINDOW is in effect. Prior to this change only one pair was possible per RMF III data set processed. -However, if the number of days between FROMDATE= and TODATE= exceeds 15 only one RMFV006I pair will be shown to avoid CPU overhead and excessive log message volume. Actual filtering will still occur as requested. -Filter message RMFV006I will now show the number of days Yüklə 28,67 Mb. Dostları ilə paylaş:
|