* copyright (C) 1984-2019 merrill consultants dallas texas usa
Yüklə 28,67 Mb.
|
|
a missing value results instead of the error. Thanks to Andrew Woods, Interactive Data, ENGLAND.
VGETOBS without a DATA= argument was executed after %VGETOBS was Nov 15, 2013 executed, because in the absence of a DATA= argument, SAS uses the &SYSLAST macro variable, and VGETOBS created and then deleted the WORK.MXGTABLES dataset, but &SYSLAST is not changed when that last-created dataset is deleted! (But even if SAS had set &SYSLAST to a _NULL_ value, the PROC ANYTHING would still fail with a NO DATASET FOUND.) The MXGTABLES dataset, added in 31.06, is created and is normally deleted by %VGETOBS, an internal utility used in many (52) MXG members, primarily to determine if a SAS dataset has any obs (but also used to avoid tape mounts as documented in Change 31.212, and it is NOT deleted if SPINTAPE=YES it set). Now that this exposure has been understood, VGETOBS is revised to store &SYSLAST at entry and that dataset is restored in &SYSLAST at exit. Had we been slightly smarter, this change should have been made to VGETOBS instead of changing ANALHSM in Change 31.211, which also failed due to the absence of a DATA= argument after VGETOBS had been executed there! Note that there is NOTHING wrong in a PROC without a DATA= argument, as long as the &SYSLAST dataset actually exists! -Although undocumented, setting automatic macro variable &SYSLAST also sets the automatic macro variable &SYSDSN and the system option _LAST_. Thanks to Otto Burgess, ATPCO, USA. Change 31.246 The data used for testing had only a single CEC so the by GRAFCEC statement that included CECSER had no problem. But when Nov 13, 2013 data from multiple CECs was included a not sorted error occurred because CECSER was not in the sort BY list. Change 31.245 Support for APAR PM90886 adds these DB2ACCT variables for VMACDB2 IBM DB2 Analytics Accelerator (IDAA)/NETEZZA modelling: VMAC102 QWAC_ACCEL_ELIG_ELA='ACCEL*ELIGIBLE*ELAPSED*TIME' Nov 13, 2013 QWAC_ACCEL_ELIG_CP ='ACCEL*ELIGIBLE*CP CPU*TIME' Dec 13, 2013 QWAC_ACCEL_ELIG_SE ='ACCEL*ELIGIBLE*ZIIP CPU*TIME' Dec 16, 2013 -IBM did confirm that the new fields are only in IFCID=3 Dec 18, 2013 (ID 101 Subtype 0) are not in IFCID=369 (ID 100 SUBTYPE 5) DB2STAT5 data which also contains the QWAC DSECT. -Variable QWP4ACMO='ACCELMODEL*PARAMETER*VALUE' is added to T102S106 dataset. -Dec 13: The QWAC DSECT was received and code revised but no data available for validation. -Dec 13: The Q8ST DSECT was revisited and Q8STQUEW was not input causing many of the Q8STxxxx variables in DB2STATS to be incorrect. -Dec 16: IBM Support confirmed the values in variables Q8STCCPU and Q8STWCPU are percentages times 100 so they are now correctly input with two decimal places. -Dec 18: The new fields in DB2ACCT were validated. Thanks to Tim King, Blue Cross Blue Shield of South Carolina, USA. Thanks to Scott Chapman, AEP, USA. Thanks to Clinton Moore, Verizon, USA. ====== Changes thru 31.244 were in MXG 31.08 dated Nov 12, 2013========= Change 31.244 TYPE21 (a/k/a PDB.TAPES) variables BYTEREAD and BYTEWRIT VMAC21 were wrong or missing for DEVICE=3590 when SMF21MFV was Nov 12, 2013 NOT on (i.e, when SMF21MCR/MCW/MDR/MDW were NOT valid), due to incorrect logic that did not use SMF21BRN/SMF21BWN (SMF21NCT was ON, which applies ONLY to 3590 devices). Thanks to Yves Cinq-Mars, IBM Global Services, CANADA. Change 31.243 Change 31.186 (MXG 31.07) inserted LENGTH DEFAULT=&MXGLEN ASUM113 but the 113 variables must be stored in LENGTH DEFAULT=8 Nov 12, 2013 because they are large numerics that are then DELTA'ed; those defaults are now 8. Thanks to Scott Barry, SBBWorks Inc, USA.
Nov 12, 2013 Change 31.241 Support for CICS User field CMODNAME,CMODHEAD=USTHRD00. IMACICVF
UTILEXCL VMAC110
Nov 12, 2013 =====Changes thru 31.240 were in FIRST MXG 31.08 dated Nov 12, 2013===== Change 31.240 Support for DB2 V11.1 (COMPATIBLE). MXG 30.30+ TOLERATES VMACDB2 V11 with no EXECUTION error, but MXG 31.04 is REQUIRED to VMAC102 correct QLSTxxxx variables in DB2STATS for V10 and V11. Nov 11, 2013 -All new V11 fields were added AT THE END OF SEGMENTS so MXG Version 30.30+ tolerates V11.1, but new variables are not output. -Dataset PDB.DB2STATS now correctly contains all of the IFCID=225 variables, and (as previously documented but not actually implemented) dataset DB2ST225 will always have zero observations, when TYPEDB2/BUILDPDB is used. Unintentionally, DB2 V10 IFCID=225 data was output in DB2ST225 dataset, and DB2 V9 IFCID=225 data output in DB2STAT4 dataset. Fortunately, DB2ST225 and DB2STAT4 were then combined into PDB.DB2STATS, so there was no actual error, as long as you use PDB.DB2STATS dataset. Now, V9-V11 IFCID=225 are output in DB2STAT4 and the DB2STAT4 KEEP= list contains all QW0225xx variables. -If you still have archaic DB2 V8 with IFCID=225 records, you will need to use %READDB2(IFCIDS=STATS) to create the WORK.T102S225 dataset for V8 and DB2STAT4 for V9-V11 so all 225s from all versions are output into PDB.DB2STATS. -Dataset DB2ACCT new variables in DB2 V11.1: QWACATCT='ACCUMULATED*AUTONOMOUS*WAIT*COUNT' QWACATRY='AUTONOMOUT*ROLLUPS*IN THIS*RECORD?' QWACATWT='ACCUMULATED*AUTONOMOUS*WAIT*TIME*/ QWACPQCT='WAITS*FOR*PARALLEL*SYNCH' QWACPQRY='RECORD*CONTAINS*PARALLEL*QUERY*ROLLUP?' QWACPQWT='WAIT TIME*FOR PARALLEL*SYNCH*/ QXALTMP ='ALTER*MASK*OR*PERMISSION' QXCREMP ='CREATE*MASKS*OR*PERMISSION' QXCRTSV ='CREATE VARIABLE' QXDEGAT ='PARALLEL*FALLBACKS*SEQ MODE*AUTONOMOUS' QXDRPMP ='DROP*MASK*OR*PERMISSION' QXDRPSV ='DROP VARIABLE' QXHJINCS ='RID APPEND*HYBRID*JOIN*NO RIDPOOL' QXHJINCT ='RID APPEND*HYBRID*JOIN*RIDS EXCEEDED' QXMAXESTIDG='MAX PARALLEL*GROUP*ESTIMATED*DEGREE' QXMAXPLANDG='MAX PARALLEL*GROUP*PLANNED*DEGREE' QXN1093A ='SERVICEABILITY*QXN1093A' QXN1093B ='SERVICEABILITY*QXN1093B' QXPAROPT ='PARALLEL*DEGENERATED*OPTIMIZATION' QXPFMAXUG ='SERVICEABILITY*QXPFMAXUG' QXPFMAXUM ='SERVICEABILITY*QXPFMAXUM' QXPFSENUM ='SERVICEABILITY*QXPFSENUM' QXPFSENUMG='SERVICEABILITY*QXPFSLNUMG' QXPFSLNUM ='SERVICEABILITY*QXPFSLNUM' QXRSMIAP ='RID LIST*RETRIEVAL*SKIPPED' QXSISTOR ='SPARSE*INDEX*DISABLES*INSUFF STORAGE' QXSIWF ='SPARSE*INDEX BUILDS*PHYS WORK FILE' QXSTARRAY_EXPANSIONS='ARRAY*VARIABLE*EXPANDS*GT 32K' QXSTODGNGRP='PARALLEL*DEGENERATE*TO SEQ*SYSTEM STRESS' QXSTOREDGRP='PARALLEL*REDUCED*SYSTEM*STRESS' QXWFRIDS ='RID OVFLO*NO RIDPOOL*STORAGE' QXWFRIDT ='RID OVFLO*RIDS EXCEED*INTERNAL LIMIT' QTGAFCNT ='FALSE*LOCK*UNLOCK*CONTENTIONS' -Dataset DB2ACCTP new variables in DB2 V11.1: QPACAACW='WAIT*DURATION*ACCELERATOR' QPAC_PQS_WAIT='WAIT*DURATION*PAR QUERY*SYNC' QPACAACC='WAIT*TRACES*ACCELERATOR' QPAC_PQS_COUNT='WAIT*DURATION*PAR QUERY*SYNC' -Dataset DB2ACCTW now outputs all segments in each record; previously, only the first segment was output; there were no new variables added by V11; this was discovered when examining possible new variables! -Dataset DB2STATS (from Subtype 0) new variables: QWSDLRG ='HIGH USED*RBA ADDRESS*OF LOG' QSST_RSMAX_WARN='TIMES*REALSTORAGE_MAX*WARNING*REACHED' QSST_P64DISNUM='64-BIT*POOL*CONTRACTS' QSST_P64DISBLK='64-BIT POOL BLOCKS*REQUIRED*DISCARD QSST_P64DISPGS='64-BIT POOL PAGES DISCARDED' QSST_CONTSTOR_NUM=31-BIT*POOLS*CONTRACTED*CONTSTOR' QDSTNQMN='MIN QUEUED*DURATION*THIS PERIOD' QDSTNQMX='MAX QUEUED*DURATION*THIS PERIOD' QDSTNQAV='AVG QUEUED*DURATION*THIS PERIOD' QDSTNCCW='QUEUED*CONNS*SOCKETS*CLIOSED*MAX WAIT' -Dataset DB2STATB (from Subtype 1) new variables: (where n=1,2,3,4 for the four groups of buffer vars) QBnTSMIN='MIN*BUFFERS*ON SLRU' QBnTSMAX='MAX*BUFFERS*ON SLRU' QBnTHST ='TIMES WHEN*LEN OF*SLRU=VPSEQT' QBnTRHS ='TIMES*RANDOM*GETPAGE*BUFFER HIT' -Dataset DB2STATS (from Subtype 0) INPUT but NOT KEPT QJSTSPNN &PIB.4. QJSTSPNI &PIB.8. QJSTCLID &PIB.4. QJSTCL2 $EBCDIC2. QJSTCLSN $EBCDIC10. QJSTAVAL $EBCDIC128. because all are documented as Serviceability without any labels. They could be output using _KDB2ST0 macro. -Dataset DB2STATS (from Subtype 1) new variables: QISTI2AC='NON-SORT*DM*IN MEM*WKFILE*ACTIVE' QISTI2AH='NON-SORT*DM*IN MEM*WKFILE*MAXIMUM' QISTI2OF='TYPE-2*INMEM WFS*OVERFLOWS' QISTIMNC='WF NOT*CREATED*DUE TO*CRITICAL*STORAGE' QISTASTH='WFDB*AGENT USAGE*ALERT*THRESHOLD' QISTSSTH='WFDB*SPACE USAGE*ALERT*THRESHOLD' QISTAMXU='WFDB*MAX STORAGE*USED BY*ANY THREAD' QISTWSTG='CURR WFDB*STORAGE*CONFIG*ALL TBLSP' QISTDGTTSTG='WFDB*DGTT*PREFERRED*STORAGE' QISTDGTTCTO='CURR*ALL AGENT*TOT STORAGE' QISTDGTTMXU='MAX*ALL AGENT*TOT STORAGE' QISTWFSTG='TOT*PREFER*STORAGE*CONFIG*IN WFDB' QISTWFCTO='CURR*TOT*STORAGE*ALL WF*ALL AGENTS' QISTWFMXU='MAX TOT*STORAGE*ALL WF*ALL AGENTS' QISEKSPA8='STORAGE*ALLOCATED*SHAREABLE*SQL' -Dataset DB2STATS (from Subtype 4) new variables: QW0225_LMWRITE_REAL='LM*WRITE*BUFFER*BYTES*REAL' QW0225_LMWRITE_AUX ='LM*WRITE*AUX?*RESERVED' QW0225_LMCTRL_REAL ='LM*WRITE*CONTROL*BYTES*REAL' QW0225_LMCTRL_AUX ='LM*WRITE*CONTROL*BYTES*AUX' QW0225SC8='ALLOC*SHAREABLE*STORAGE*DYNAMIC SQL' QW0225LS8='REQ*SHAREABLE*STORAGE*DYNAMIC SQL' QW0225SX8='ALLOC*SHAREABLER*STORAGE*STATIC SQL' QW0225HS8='HWM*REQ*SHAREABLE*STORAGE*DYNAMIC SQL' -Dataset T102S106 new variable, added back in DB2 V10: QWPBIMTZ='IMPLICIT*TIME*ZONE' 9999999=CURRENT -9999999=SESSION Other values, -779 to +840 represent -12:59 to +14:00 -Only these other ID=102 IFCIDs have been data-verified; none were changed: 105, 199, 254, 261. Other IFCIDs for V11 will need actual SMF data for update/validation. Thanks to Harald Seifert, HUK-COBURG, GERMANY. Change 31.239 Values for MG073FE format values 07x,08x,11x,12x and 13x FORMATS were corrected: Nov 7, 2013 07X='07X:FEX8 AUTO@2GBPS' 08X='08X:FEX8 AUTO@4GBPS' 11X='11X:FE8XS AUTO@2GBPS' 12X='12X:FEX8S AUTO@4GBPS' 13X='13X:FEX8S OP@8GBPS' Thanks to Pat Sheehan, FIS Technology. Thanks to Kenneth Thornbrough, FIS Technology, USA
VMACTMMQ
Nov 7, 2013 Change 31.237 The PCTIFLBY in datasets ASUMCELP and ASUMCEC incorrectly VMXG70PR used the sum of IFLs allocated to all LPARS, which makes Nov 6, 2013 no sense for these CEC-level datasets. It is corrected to use the number of installed IFLs, NRIFLCPU, which is also now stored in the count variables IFLCPUS/LPARCPUS. Thanks to Julian Smailes, Experian, ENGLAND. Change 31.236 DB2 Trace IFCID=196 now outputs sets of variables for up VMAC102 to nine lock holders/waiters. Nov 6, 2013 Thanks to Harald Seifert, Huk-Coburg, GERMANY. Change 31.235 REPLACED MAR 27, 2014: See Change 32.073 which supports VMACSMF reading from //SMF for VBS dumped data and/or //LOGGER. VMXGINIT Original change text: Nov 12, 2013 SMF Logstream DATA MIGHT be readable directly by MXG with %LET READLSMF=0; in your //SYSIN. which:
Changes the DCB for INFILE SMF to VB,32756,32760 inside the _SMF macro that is defined in VMACSMF. (Reading with VBS caused an IEC141I 013-A8 ABEND), and the value in READLSMF is used for OFFSMF. (This was coded when I thought perhaps OFFSMF=4 would be required for the LOGGER, which is required to read VSAM, but OFFSMF=0 with VB appear so far to work fine.) -The SMF DD needs SUBSYS=(LOGR,IFASEXIT). The DCB on the SMF DD is unimportant since what is set in _SMF is used. Unfortunately, unlike VSAM that can be detected so the normal MXG program reads either VSAM or BSAM dumped SMF data, there is no way to detect the input is Logstream Data, so you must use %LET READLSMF=0; to try to read! -If you test this technique, please protect your job with a TIME= parameter to ABEND if a CPU Loop occurs. An early test did appear to CPU loop, but that case has NOT been repeated in any subsequent tests. -Reading the LOGGER file with either RECFM=VB or RECFM=U and using INPUT;LIST; produces a SAS hex dump that does NOT show a BDW nor RDW and it is possible that using U or VB might be equally functional. Please report any success OR FAILUREs to support at mxg.com and this change text will be updated if more is discovered. -A note posted to IBM-MAIN after MXG 31.08 was GA states: We do not ship an official mapping macro for the SMF buffers returned by a log stream browse. The intended interface to get SMF records in log streams is IFASMFDL. You can however IXGBRWSE the log stream and see the buffers are returned in a consistent format, but this is of course not supported by IBM. In some cases the data returned by the log stream browse has to be manipulated by SMF before the user sees it, such as if zEDC compression is turned on in z/OS 2.1. Thanks to Seighart Seith, FICUCIA, GERMANY. Change 31.234 Final semicolon for one of the several LIBNAMEs was not VGETDDS generated, but only if GDGs were involved. &EXOUT was Nov 4, 2013 not always initialized; it is used to keep track of DDs that were found in EXTFILES that may or may not be SAS data libraries; if at the end it is non-zero length a warning is produced showing the DDs that were found that way. &INCR, used only for GDG, was not used in two %DOs. Thanks to Scott Barry, SBBWorks Inc, USA. Change 31.233 Correction for IMF 4.2 thru 5.1 WRONG VALUES IN CIMSTRAN. VMACCIMS MXG code was misaligned, impacting these newer variables: Nov 4, 2013 TRNEWLMC TRNOTCON TRNOTSTC TRNOTSOC TRNOTPRT TRNOTIP TRNOTCLN TRNOTUSR TRNOTSTF TRNOTSYF TRNOTSLF TRNOTCLF TRNOTSCF TRNOTCOR TRNOTCLP TRNMQMID Also TRNOTCON is now formatted DATETIME21.2 and variables TRNOTUSR, TRNOTSTC, TRNOTCLN, and TRNOTMAM are EBCDIC and not $HEX formatted. -This update also required VMXGINIT from 31.08 to support &IMFMQ that was added by Change 31.206. Thanks to Jan Tielemans, KBC, BELGIUM.
EXZRBDVT in EXZRBDVT's definition were not output; these variables VMACRMFV CONNTM PENDTM DISCTM DVBUSYTM CUBUSYTM SWPODLTM were set Nov 3, 2013 to a missing value when DVTSAMPA=0, but some, plus CMRTM were found to be non-zero even with DVTSAMPA=0. Now they are always calculated, and all are included in ACTIVITY so observations are output when ANY are non-zero. So, how can there be activity with DVTSAMPA=0? All cases observed were for TAPE devices and all were the last observation for a VOLSER; some variables (CONNTM, DISCTM) were almost equal to the DURATM. Presumably, this is activity for the dismount of a VOLSER. This condition was discovered when the new ASMRMFV DVTNOZEROIO option (Change 31.230) wrote 607 records (of 1,932,611) that were not output by the ACTIVITY test in EXZRBDVT. -A cosmetic change was made in VMACRMFV so the ZRBxxxx datasets are created in alphabetical order to make it is easier to find how many obs were created in each. Change 31.231 $MGSMFID format now decodes SMF ID=28 & ID=119 subtypes. FORMATS
Nov 2, 2013 Thanks to MP Welch, Bank of America, USA. Change 31.230 -RMF III Enhancements: BIG DISK SPACE SAVED in ZRBDVT. ADOCRMFV -Enhanced DVT table filtering added as discussed below. ASMRMFV -New parameters ZEROIO/NOZEROIO are added and are only Nov 3, 2013 applicable to RMF Monitor III DVT processing by ASMRMFV. Nov 7, 2013 -Alias for ZEROIO is ZIO and the aliases for NOZEROIO are NOZIO or NZIO. The default is NOZEROIO. -ZEROIO specifies output of all volume entries from the DVT table to the RMFBSAM file regardless of I/O activity. This was the ASMRMFV behavior in prior versions. -NOZEROIO specifies output of only volume entries from the DVT table to the RMFBSAM file that have I/O activity. This is new default ASMRMFV behavior with this version. THIS CHANGED THE ZRBDVT SIZE FROM over 66,666 cyl to less than 14,000. Note that we also recommend that ASMRMFV use PARM='NOSHD,NORED' to reduce the output size, and if you are not planning on detail analysis of wait types, NOUWD can be added for further space reduction. -DSNTYPE=LARGE is now supported for the required RMFBSAM output file as well as the optional RMFFILT and RMFSKIP files
-A DVT volume entry in a MINTIME interval is considered to HAVE I/O activity if ANY of the following I/O measures are NON-ZERO using the DVT fields and calculations shown: * Connect Time (DVTCOTIL-DVTCOTIF) * Pend Time (DVTPETIL-DVTPETIF) * Disconnect Time (DVTDISIL-DVTDISIF) * I/O Queue Length (DVTIOQLC) * Accumulated I/O Instruction Count (DVTSAMPA) * Initial Command Response Time (DVTCMRIL-DVTCMRIF) -Stated another way, if all of these I/O measures are zero for a DVT volume entry and NOZEROIO is in effect the entry is NOT output to the RMFBSAM file. -During testing there was about a 93% reduction in DVT output record volume with NOZEROIO in effect which also improves performance during the PDB build. This may not be typical and your results may vary. -A second new filtering parameter only applicable to RMF Monitor III DVT table processing is DEVTYPE=ALL/DASD/TAPE. -Aliases are DEVT= and DT=. The default is DEVTYPE=ALL which provides the same behavior as earlier ASMRMFV versions. -DEVTYPE=ALL specifies that all DVT volume entries regardless of device type are output to the RMFBSAM file. -DEVTYPE=DASD specifies that only DVT volume entries for disk devices are output to the RMFBSAM file. This setting may be relevant for users only interested in disk analysis from their PDB. Abbreviations for the DASD value are DAS, DA, or D. -DEVTYPE=TAPE specifies that only DVT volume entries for tape devices are output to the RMFBSAM file. Abbreviations for the TAPE value are TAP, TA, or T. -DEVTYPE=DASD or DEVTYPE=TAPE may be used together with NOZEROIO. In this case device type filtering occurs before any zero I/O filtering. -If both DEVTYPE=DASD and DEVTYPE=TAPE are specified only the last occurrence takes effect. -Enhancement for the Direct Method of running ASMRMFV is discussed below. -A new keyword MAXDSNAMES= is provided to allow user specification of the number of entries in the dsname table to contain INDSNAME= patterns when the Direct Method is used with ASMRMFV. Aliases for MAXDSNAME= are MAXDSNAME=, MAXDSN=, or MAXDS=. -Prior to the addition of MAXDSNAMES= the only way to change dsname table size was by a source change to ASMRMFV followed by a re-assembly and re-link. The dsname table was integrated as part of the program but now resides in a separate memory area. -MAXDSNAMES=nnnn specifies the number of entries to be allocated in the dsname table. nnnn is an integer ranging from 1 to 9999. The default is MAXDSNAMES=256. Each dsname entry requires 44 bytes. -While MAXDSNAMES=9999 is the maximum value supported by ASMRMFV, in reality a realistic value is the maximum number of TIOT entries supported by z/OS for single unit DD statements. -Initial ASMRMFV RMFV001I messages that show the current execution environment are enhanced to show the TIOT SIZE as defined in the ALLOCxx member in PARMLIB (shown as TIOT SIZE=nnK), the maximum number of single unit DD statements possible with that TIOT size (shown as MAXDD=nnnn), and the number of DD statements used at the start of ASMRMFV execution (shown as USEDD=nnnn). -The actual maximum number of entries allowed for MAXDSNAMES=nnnn is the value for MAXDD= less the value for USEDD=. If MAXDSNAMES=nnnn exceeds this value it is set instead to the result of MAXDD - USEDD. -MAXDSNAMES=MAX may be specified instead and the result is the number of dsname entries calculated as just described above. -NOTE: If MAXDSNAMES=nnnn or MAXDSNAMES=MAX is specified, it MUST appear before ANY INDSNAME= parameters appear. The first INDSNAME= option triggers the allocation of the dsname table and the number of entries cannot then be set later.
-New message RMFV038I appears when a dsname table is allocated showing the number of dsname entries and size in bytes. -New second message RMFV038I appears when a dsname table is freed or exhausted showing the number of entries available/used and the percentage used. -A second 32K output buffer used for filtering only has been added. Any tables written to the optional RMFFILT DD will be blocked just as if they were written to RMFBSAM.
-NOZEROASI and NOZERODVT options were not always properly shown in the RMFV037I options list message. -Messages RMFV006I for filters and RMFV037I for options are updated to show the new NOZEROIO and DEVTYPE= parameters. -Message RMFV007S had an incorrect value for Reason Code when a GETMAIN, FREEMAIN, or DLVRP service error occurred. These services do not issue a Reason Code (only a Return Code) so this field is set to blanks in these cases. -Fixed a S0C4 Abend when the FROMDATE= value exceeded the TODATE= value. ASMRMFV was attempting to read past the SYSIN end of file when it should have terminated parm processing. The same issue could occur if FROMTIME= exceeded TOTIME= where FROMDATE= and TODATE= were the same date. -ASMRMFV now supports keywords up to 11 characters in length for future development. -NOTE: The prior suggestion for initial setting of ASMRMFV parameters for new users was PARM='NODVT'. However, now that a large percentage of DVT volume entries with zero I/O activity can be filtered out with NOZEROIO by default, that suggestion is changing. -Instead use PARM='NOSHD,NORED' in JCL (or NOSHD NORED in SYSIN). The MXG distributed EXZRBSHD and EXZRBRED output exits for VMACRMFV suppress the respective SAS data sets Yüklə 28,67 Mb. Dostları ilə paylaş:
|