* copyright (C) 1984-2019 merrill consultants dallas texas usa
Yüklə 28,67 Mb.
|
|
conditions was inconsistent, difficult to alter, or simply not available. -ASMRMFV messages RMFV004*, RMFV016*, RMFV017*, RMFV029*, RMFV033*, RMFV048*, and RMFV049* (*=I,W,E,S) are now multi-severity based on the settings of these error control parameters. -ABEND causes ASMRMFV to issue an error message RMFV***E and immediately terminate with a U0998 Abend. -WARN results in an RMFV***W warning message then sets a return code of 4 and execution continues. -IGNORE issues an informational message RMFV***I, leaves the return code unchanged and execution also continues. -ALLOCERR=ABEND/IGNORE/WARN directs ASMRMFV when a dynamic allocation of an RMF Monitor III data set fails (default WARN). NOTE: Look for messages on the Job JESLOG for more details on dynamic allocation errors. -ATTRERR=ABEND/IGNORE/WARN directs ASMRMFV when a VSAM RRDS found during a CSI search has an attribute error for an RMF Monitor III data set either an invalid CISIZE not 32768 or an invalid LRECL not 32752 (default WARN). -CATERR=ABEND/IGNORE/WARN directs ASMRMFV when a catalog entry retrieval error occurs during a CSI search (default WARN). Catalog damage is possible. NOTE: For Return and Reason Code details on a catalog retrieval error consult the IBM documentation for message IDC3009I for the same respective codes. -DEADERR=ABEND/IGNORE/WARN directs ASMRMFV when an RMF III data set has probable dead space due to high usage of indexes (default WARN). Reallocation to a smaller size may be appropriate. -DSIGERR=ABEND/IGNORE/WARN directs ASMRMFV when the table ID for an RMF III data set header/index record is not 'DSIG3' as expected (default WARN). This can be due to an "imposter" data set, a VSAM RRDS with correct CISIZE and RECSIZE for an RMF III file but does in fact NOT contain valid RMF III data. -DSNERR=ABEND/IGNORE/WARN directs ASMRMFV when a data set entry retrieval error occurs during a CSI search (default WARN). Data set damage is possible. NOTE: For Return and Reason Code details on a data set retrieval error consult the IBM documentation for message IDC3009I for the same respective codes. -EMPTYERR=ABEND/IGNORE/WARN directs ASMRMFV when an RMF Monitor III data set opened during processing contains no data (default IGNORE). This can validly occur for several reasons. See documentation for this parm. -PATTERR=ABEND/IGNORE/WARN directs ASMRMFV when a data set name pattern error is detected for the INDSNAME= parameter (default WARN). This is usually a user error. -READERR=ABEND/IGNORE/WARN directs ASMRMFV when a read I/O error occurs processing an RMF III Monitor data set (default ABEND). Can be due to a truncated file. -TYPEERR=ABEND/IGNORE/WARN directs ASMRMFV when a VSAM data set type other than a RRDS is found during a CSI search (default WARN). The INDSNAME= pattern may be too general causing retrieval of many non-RMF III files. -The old ASMRMFV parameter ABREAD is now equivalent to READERR=ABEND and is still supported. -The old ASMRMFV parameter NOABREAD is now equivalent to READERR=WARN and is still supported. -12 new messages RMFV040I to RMFV051I are added to support Catalog Search Interface usage and results. -7 new messages RMFV060I to RMFV066W are added to support dynamic allocation usage and results. -New message RMFV036I shows selection settings for all RMF III tables at ASMRMFV initialization. -New message RMFV037I shows selection settings for all other ASMRMFV parameters at initialization including the new error condition keywords. -CSI work area buffer statistics are shown when the BUFFERS parameter is used. -A new parameter CSISTAT/NOCSISTAT controls statistics information about the CSI user work area buffer (default NOCSISTAT). CSISTAT (alias CSIS) shows the total size and size used of the buffer for each CSI call in message RMFV047I. NOCSISTAT (alias NOCSIS) suppresses the message.
NOTE: Starting with an initial CSI workarea size of 64K ASMRMFV will dynamically increase the size of the CSI work area up to a maximum of 1 MB when a RESUME CSI call is needed because the buffer was too small for the number of entries retrieved. -When a GETMAIN/FREEMAIN storage error occurs severe message RMFV007S now includes the number of bytes and subpool involved. This should be a rare event but always results in an abend. -When the BUFFERS parameter was active the Summary report did not include the final program FREEMAINs at program termination. -ASMRMFV will no longer attempt to process RMF Monitor III data sets that are not CISIZE 32768 or RECSIZE (LRECL) 32752. IBM messages ERB824I and ERB825I document that only the CISIZE and RECSIZE values used in ERBVSDEF Clist to DEFINE RMF III data sets are correct. -Performance: ASMRMFV was incorrectly freeing and allocating a new buffer for every MINTIME sample. -Performance: Sample buffer adjustment factor of 1 in &MULTS symbolic parameter was ineffective in reducing additional GETMAINs, so has been lowered to 0 to avoid wasting unused buffer space. -Performance: Policy buffer adjustment factor of 1 in &MULTP symbolic parameter was ineffective in reducing additional GETMAINs, so has been lowered to 0 to avoid wasting unused buffer space. -Four internal ASMRMFV message tables have been consolidated into a single table to relieve message addition restrictions. -Message RMFV016* generated when an expected versus actual RMF III table id mismatch occurs now includes the actual found table id in both character and hexadecimal. -ASMRMFV prologue documentation has been updated for all new parameters, for details on pattern match usage, and expanded for return code 4. NOTE: The TSO Clist method is not planned for any further enhancement and may become archaic. TSO Clist Method users are encouraged to trial and migrate to the Dynamic Method which should be vastly superior in ease of use and likely in performance as well. -REQUIREMENT: In order to receive these improvements the current 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.
ASUMTAPE to define an additional variable (e.g., LOCATION) causing Jul 22, 2013 ERROR: VARIABLE LOCATION NOT FOUND. The KEEPs= for JES3MNT, JES510, and JES5918 needed macro _GRPMNNM added, and _GRPMNCD was needed in the logic for JES3MNT, even though this was a JES2 site. Thanks to Matthew Chappell, QLD Dept Transport Main Roads, AUSTRALIA
VMXGSUM your VMXGSUM invocation must be a variable, and can not Jul 22, 2013 be an expression. Unfortunately, while some earlier VMXGSUM releases did permit NORM1=A B /(C+D) syntax, that was NEVER intended and is NOT supported; it's just too deep in working logic to risk the exposure, when you can use this logic in your VMXGSUM to create a variable with an expression: INCODE=E=C+D; and then NORM1=A B/E. Thanks to Matthew Chappell, QLD Dept Transport Main Roads, AUSTRALIA
IMACICVC CICS segments creates same-named variables: IMACICVD CMODHEAD IMACICVE and Tailor IMACAAAA Variable: Member UTILEXCL CANPROD4 IMACICVC VMAC110 CANPROD5 IMACICVD Jul 19, 2013 CANPROD6 IMACICVE Jul 29, 2013 -UTILEXCL wasn't updated until Jul 29, after 31.05 was GA.
EXRAC206 The documented length is 534 bytes, including two "user" IMACRACF fields documented in fixed locations (bytes 270-525 and VMACRACF 527-534) but this record was only 285 bytes. The first VMXGINIT 269 bytes contained valid/expected data, but the two user Jul 22, 2013 fields did not exist as documented. However, the record does contain three fields of 3,8,4 bytes, so this change detects the short record and only inputs what's left in the record into variable USERDATA. -INPUT STATEMENT EXCEEDED RACF UNLOAD 0510 short record. Unlike the above short 0506, this one instance was only 262 bytes long, ending after CLASS with no user segment. -Support for RACF UNLOAD 0206 RSAF DATA record creates new RACF0206 dataset. -Missing value messages were eliminated by improved logic. Thanks to Florent Boulesteix, INOVANS partenaire CAAGIS, FRANCE. Change 31.145 INPUT STATEMENT EXCEEDED for QAPMHDWR infile because the VMACQACS two fields SWTMOD and DORESR do not exist in V5.4.0 data Jul 18, 2013 records. Their INPUT is now conditional on being there. Thanks to Clayton Buck, UNIGROUP, USA. Change 31.144 Updates for SMF 83 Subtypes 2 thru 6. VMAC83 Incomplete, await data records. Jul 20, 2013
VMAC120 if there is more than one observation per enclave token, Jul 19, 2013 a not-documented-feature observed in the data. TYP1209E Jul 26, 2013 is now sorted by SYSTEM,SM1209CR,CY,CV,CH,SM1209CM and variables SM1209DA/DB/DC/DD/DE/SM1209DF are deaccumulated if the obs is NOT (FIRST.SM1209CH AND LAST.SM1209CH), as those are single-instance-per-enclave-token observations whose CPU time is not accumulated. Use TYPS120 instead of TYPE120 so that TYP1209E data is deaccumulated, or %INCLUDE SOURCLIB(TYPE120); _ST1209E ; RUN; to invoke the dataset sort macro, where MXG does deaccumulation. -ID=120 ST=9 WebSphere variable SM1209DI, zAAP CPU time, is now normalized by SM1209DG/256. While the zIIP time in SM1209DF returned by WLM is normalized, and the part of SM1209DH from zIIP and zAAP is normalized, SM1209DI is returned by WLM in raw time units. -ID=120 ST=9 WebSphere variable SM1209CI is now labeled SM1209CI=TOTAL*CP+ZIIP+ZAAP*TCB CPU*TIME as it contains TOTAL CPU time on all engines. Variable SM1209CX is the portion of SM1209CI that was executed on the zIIP or zAAP Specialty engine. If your CP engines are knee-capped, i.e., slower than the zIIP speed, then the CPU time in SM1209CX for the zIIP time (which is also included in SM1290CI) will be the normalized (LARGER) CPU time value, since that's what applications return for CPU time on specialty engines. (E.g., documented that the CPUTM in CICSTRAN can be greater than ELAPSTM for transactions using zIIP/zAAP with slow CP engines.) See this white paper, by David Follis, looking at WAS 120-9 analysis: http://www-03.ibm.com/support/techdocs/atsmastr.nsf/WebIndex/WP102311 Thanks to Joseph J. Faska, Depository Trust, USA.
IMACICV6 New Variable CMODHEAD CMODNAME IMACICV7 IMACICV6 MSG@ MSG/APPL IMACICV8 IMACICV7 EGTBS EGTBS IMACICV9 IMACICV8 FROMCORR FROMCORR IMACICVA IMACICV9 TOCORR TOCORR IMACICVB IMACICVA EGMSGID EGMSGID UTILEXCL IMACICVB PROGNAME PROGNAME VMAC110 Jul 18, 2013 Change 31.141 DIVISION BY ZERO in ANALPRTR. One of the two calculations ANALPRTR of printer THRUPUT didn't test THRUTM, the denominator, Jul 17, 2013 for a non-zero value before a divide. Since a zero is a valid value, there was no actual error; variable THRUPUT is a missing value, with or without the test added by this change before the divide that prevents that message. Thanks to Jessie Gonzales, California State Controller's Office, USA.
VMAC7072 blank in PDB.TYPE70PR dataset, causing Group Capacity Jul 17, 2013 datasets ASUM70GC/ASUM70GO to have zero observations. MXG's bit 1 test in SMF70PFL was incorrectly changed in 31.03 causing group name to be replaced with blanks. Thanks to Don Shelton, Time Customer Service, Inc., USA. Change 31.139 Support for RACF TOKDANAM='UNAME' creates new variable VMAC80A TOKUNAME in dataset TYPE80TK. Jul 17, 2013 Thanks to Clayton Buck, UNIGROUP, USA. Change 31.138 If you have multi-period workloads defined in RMFINTRV, VMXGRMFI the period 1 RSP TRN SWP variables were mislabeled with Jul 16, 2013 the workload name (BAT1) rather than the label (BATHI). Thanks to Patricia J. Jones, DST Systems, USA. Change 31.137 IMF TRANSACTION EXTENSION variables TRXZxxxx were wrongly VMACCIMS INPUT @TRXPTIMO but are now INPUT @TRNEXTEN+TRXPTIMO, and Jul 16, 2013 TRX1FL1,TRX1FL2, and TRX1_LDS variables are now correctly input and kept in CICSTRAN data.se. Thanks to Sieghart Seith, Fiducia IT AG, GERMANY.
VMACWWW loop; MXG expected an equal sign in COOKIE text, now Jul 16, 2013 protects for no equal sign. Browser was Mozilla/5.0. Jul 26, 2013 -Mozilla browser created unexpected URIQUERY value, with a leading equal sign and without a URIQNAME that also caused MXG to loop. Thanks to Xiaobo Zhang, Fiserv, USA.
ASUMTALO time range of the data could be limited to the time range Jul 15, 2013 of a single system (if SYSTEM is what was added). Now, if we detect that you have used _GRPALNM, then all data will be input to ASUMTALO. Thanks to Jorge Fong, NYC Information Technology, USA. Change 31.134 The TIMESTAMP, BEGINTIME, ENDTIME values were wrong for VMACXDFG HH of 12 with PM suffix (only PM hours 1-11 need +12), VMACXDNS or for HH 12 with AM suffix (must reset HH=00). VMACXDSP
Jul 16, 2013 Change 31.133 Support for TMON for DB2 Version 5 second iteration. VMACTMD2 -DA and DB records were INCOMPATIBLY changed with removal Jul 16, 2013 of 11660 and 5680 uncompressed reserved bytes, but there was no change in the variables created in TMD2DA/TMD2DB datasets. Fields DALHRECC/DBLHRECC are used to identify and transparently process both record formats. Note: Jul 2014, dataset TMD2DB replaced TMDBDB2 dataset. -IG record was COMPATIBLY changed creating 2 new variables IGGBGR1C='CURRENT*DIRECTORY*ENTRY' IGGBGR2C='PENDING*DIRECTORY*ENTRY' in TMD2IG dataset from previously reserved areas. -Three TMON PTFs: TE03897, TEO3904, and TE03910 make these changes in the TMON for DB2 records.
VMACVMXA and validated, but that VMACVMXA was NOT moved into the Jul 10, 2013 master MXG source, causing BROKEN CONTROL RECORD ERROR. CFVN=1 CSVN=3 SKIP= still had 1708 instead of 1664. Thanks to David J. Schumann, BCBS of Minnesota, USA.
UTILEXCL works with recent UTILEXCL (31.02 for example) when there EXUTILEX are two triplets with that CMODHEAD name, and it's not IMACICUS yet clear why nor when it stopped working. If you have Jul 9, 2013 an EXUTILEX member and its associated IMACICUS member, please send them to support@mxg.com so they can be added with a new IMACICxx member, which is now the correct way to support user segments in CICSTRAN records. -I will try to resolve and reinstate EXUTILEX support and will update this note if/when that is accomplished. At present, however, the second instance causes a SYNTAX error citing the first variable in the EXUTILEX INPUT. Thanks to Kim Nguyen-Thi, IBM, AUSTRALIA. Thanks to Paul Gillis, IBM, AUSTRALIA. Change 31.130 Corrections to zIIP/zAAP SHARE WEIGHTS in RMF 70 data. VMAC7072 Change 30.106 did not correctly calculate the initial and VMXG70PR current SHAREs for the zIIP engines, didn't create SHAREd Jul 20, 2013 variables for the zAAP engines, and revisions to labels now identify CP, ZAAP, or ZIP metrics. TYPE70 dataset: the "LPAR" values are for this zOS system while the "TOTAL" values are for the entire CEC. TYPE70 SHARE WEIGHT variables in TYPE70: TOTSHARC='TOTAL*CURRENT*CP SHARE*WEIGHT' TOTSHARE='TOTAL*INITIAL*CP SHARE*WEIGHT' ZIPSHARC='TOTAL*CURRENT*ZIIP SHARE*WEIGHT' ZIPSHARE='TOTAL*INITIAL*ZIIP SHARE*WEIGHT' IFASHARC='TOTAL*CURRENT*ZAAP SHARE*WEIGHT' IFASHARE='TOTAL*INITIAL*ZAAP SHARE*WEIGHT' LPARSHAC='LPAR*CURRENT*CP SHARE*WEIGHT' LPARSHAR='LPAR*INITIAL*CP SHARE*WEIGHT' LZIPSHAC='LPAR*ZIIP SHARE*CURRENT*WEIGHT*PCT' LZIPSHAR='LPAR*ZIIP SHARE*INITIAL*WEIGHT*PCT' LIFASHAC='LPAR*ZAAP SHARE*CURRENT*WEIGHT*PCT' LIFASHAR='LPAR*ZAAP SHARE*INITIAL*WEIGHT*PCT' ASUM70PR and ASUMCEC variables exist per LPAR: LPnSHARC='LPAR n*SHARE*CURRENT*CP WEIGHT*PCT' LPnSHARE='LPAR n*SHARE*INITIAL*CP WEIGHT*PCT' LPnZIPSC='LPAR n*ZIIP SHARE*CURRENT*WEIGHT*PCT' LPnZIPSH='LPAR n*ZIIP SHARE*INITIAL*WEIGHT*PCT' LPnIFASC='LPAR n*ZAAP SHARE*CURRENT*WEIGHT*PCT' LPnIFASH='LPAR n*ZAAP SHARE*INITIAL*WEIGHT*PCT' Thanks to Lindholm Orjan, VOLVO, SWEDEN. Change 31.129 Support for CICS User CIFAUDIT field. IMACICV5
UTILEXCL VMAC110
Jul 8, 2013 Change 31.128 If you tried to use the LDB2*** parameters to reroute a READDB2 dataset to a different DDNAME/LIBNAME, it was not honored Jul 4, 2013 and fails when trying to write to the PDBOUT destination. READDB2 was using PDBOUT when it should have been using the PDB2*** macro variables to change output DDNAMEs. Thanks to David Bernhardt, Verizon, USA. Change 31.127 Variables R783DCTM and R783DDTM (Control Unit Connect and VMAC78 Disconnect Times) were added by z/OS 1.10 but were not Jul 2, 2013 flagged with the expected vertical bar for new fields so they were overlooked. They are added to Dataset TYPE78CU. Thanks to Erling Andersen, SMTDATA, DENMARK.
VMACXPTR
Jul 1, 2013 Thanks to Robert Corballo, Xerox, USA. ====== Changes thru 31.125 were in MXG 31.04 dated Jun 26, 2013========= Change 31.125 If you correctly asked for only DB2ST225 using syntax of READDB2 %READDB2(IFCIDS=STATISTICS,WANTONLY=DB2ST25); Jun 25, 2013 DIFFDB2 failed on the DB2STAT4 dataset due to a missing ELSE clause, causing 0 observations to be created. Thanks to Neil Ervin, Wells Fargo, USA
VMAC7072 SUBTYPE=5 record because MXG did not test SMF72QSN for a Jun 25, 2013 missing value. Fortunately, since it was missing, there Jun 27, 2013 was no impact, except for the error message and hex dump! Aug 22, 2013 Correction was made in the undocumented refresh in 31.04 that was made on Jun 27. Check the 2nd line of VMAC7072 for Jun 27 to verify you have the final 31.04. Thanks to Cletus McGee, ALFA Insurance, USA. Change 31.123 Using the archaic EXITCICS version 1 for DB2 compressed Jun 26, 2013 records caused INPUT STATEMENT EXCEEDED RECORD LENGTH due VMACDB2H to a truncated DB2 Data Sharing Header, with only four bytes and an invalid QWHSLEN (1439 decimal), printing an incorrect message that APAR PM32425 was needed. Using the current EXITCICS solved the truncation, but MXG now detects this truncation with a revised error message and prevents the STOPOVER ABEND. Thanks to Michael Toole, AAA Michigan, USA.
VMXGSRCH errors. The string length was insufficient but now is Jun 23, 2013 increased to 72 which will support names up to 50 bytes (although SAS variable names have a 32 byte maximum). Change 31.121 MXG Logic did not "unhex" CONDCODE for ABEND='COND=J' as VMAC30 it does for USER and RETURN codes, causing the value to Jun 23, 2013 be CONDCODE='000C', when it should be CONDOCD='0012'. Thanks to Robert Bardos, Next Stride AG, SWITZERLAND. Change 31.120 Support for QESD segment added in MQ Series 7.1 adds VMAC115 variables to MQMMSGS dataset: Jun 22, 2013 Thanks to Giuseppe Giacomodonato, EPV Technologies, ITALY. Change 31.119 -Variables IPCSTIME and character TIMEZONE (CDT/EDT/etc.) VMACNMON are added to NMONBBBP dataset. Jun 23, 2013 -New RECTYPE='DISKWAIT1' now supported correctly; this Jul 1, 2013 update was NOT in MXG 31.04, but is in 31.05. -In adding support for DISKWAIT1 it was discovered that the PDB.NMONDISK dataset could be missing observations if there were more than 150 disk volumes on the system; NMON writes 150 disks per record, and spills more disks into the DISKxxxx1 tag, but MXG logic incorrectly used the count in the LAST tag, so in this case, there were 150 disks in the first record, then 53 in the second, but MXG used that count of 53 and output only the FIRST 53. Thanks to Xiaobo Zhang, FISERV, USA.
VMACEDGR (COMPATIBLY) by z/OS 1.13: Jun 22, 2013 RDCOMPRAT ='FILE*COMPRESSION*RATIO' Jul 15, 2013 RDESB ='EXPDT*SET BY*DATASET' RDPHYSIZE ='ACTUAL*DATA ON*TAPE*AFTER' RDUCDATE ='DATASET*LAST*USER*CHANGE*DATE' RDUCTIME ='DATASET*LAST*USER*CHANGE*TIME' RDVEX ='VRSEL*EXCLUDE?' RVCOMPRAT ='VOLUME*COMPRESSION*RATIO' RVESB ='EXPDT*SET BY*VOLUME' RVHOLD ='VOLUME*HOLD?' RVPHYSUSED='ACTUAL*SPACE*AFTER*COMPACTION' RVRETMET ='RETENTION*METHOD' RVRMSB ='RETENTION*METHOD*SET BY' RVUCDATE ='VOLUME*LAST*USER*CHANGE*DATE' RVUCTIME ='VOLUME*LAST*USER*CHANGE*TIME' Thanks to Clayton Buck, UNIGROUP, USA. Change 31.117 DB2 V10. All QLSTxxxx numerics (in DB2STATR,DB2STATS) VMACDB2 are wrong. IBM inserted QLSTPRID in the second iteration Jun 20, 2013 of DB2 V10 right after QLSTLOCN, but I missed that change so all subsequent variables were misaligned by 8 bytes. My thanks to DB2 Support at Computer Associates whose reports were correct and were used to correct my error. Thanks to Paul Walters, Navy Federal Credit Union, USA.
VMACTPMX it was 6 digits long; an INPUT JOBNUM $VARYING7. is Jun 20, 2013 (pretty obviously) needed for seven digits. Thanks to Scott Barry, SBBWorks Inc, USA. Change 31.115 -Reading COMPRESSED DB2 SMF 102 records using the internal READDB2 SAS-code decompression algorithm set SUBTYPE=0 instead of Yüklə 28,67 Mb. Dostları ilə paylaş:
|