* copyright (C) 1984-2019 merrill consultants dallas texas usa
Yüklə 28,67 Mb.
|
| SCERR= RCERR= WLERR= RGERR=
------ ------ ------ ------ Message(s) RMFV070W RMFV071W RMFV072W RMFV073W Return Code 0004 0004 0004 0004 When a setting is ABEND (for diagnostic use): SCERR= RCERR= WLERR= RGERR= ------ ------ ------ ------ Message(s) RMFV070E RMFV071E RMFV072E RMFV073E Abend Code U0998 U0998 U0998 U0998 Reason Code 70 71 72 73
these FIND error settings at ASMRMFV startup as I, W, or A. -When an SCERR=, RCERR=, WLERR=, or RGERR= setting is WARN and a FIND error occurs ASMRMFV updates the usual 32 byte Description field for the Service Policy category in ASI, ENC, RCD output records as follows:
-------------- --------------------------- Service Class SC: I=nnnnnnn E=eeeee L=lll Report Class RC: I=nnnnnnn E=eeeee L=lll Workload WL: I=nnnnnnn E=eeeee L=lll Resource Group RG: I=nnnnnnn E=eeeee L=lll where: nnnnnnn is the invalid index value up to 7 decimal digits eeeee is the actual number of entries in the Service Policy for this category up to 5 decimal digits lll is the length of one entry in the Service Policy for this category up to 3 decimal digits These Descriptions eventually become part of the MXG PDB. When a Service Class, Report Class, Workload, or Resource Group name variable in an MXG PDB is blank the Description field in this case helps to explain why. -When a setting is WARN AND an index value is ZERO the respective Description field is also updated. In this case NO messages are issued. An index may validly be zero. As examples, in a given Service Policy not all Service Classes belong to a Resource Group nor do they necessarily have a Report Class. The index for the Resource Group and/or Report Class in these cases would be validly zero. -When a SCERR=, RCERR=, WLERR=, or RGERR= setting is IGNORE and the respective index value is either invalid or zero, the corresponding Description field is instead left as blanks.
index values. Users who prefer to have the Description field remain blank in the PDB in these cases should use the IGNORE setting for all 4 error parameters (or set MAXFINDS=0 as noted below). -NOTE: The respective 8 byte Service Class, Report Class, Workload, or Resource Group name variable itself in the PDB remains as blanks for invalid or zero indexes regardless of IGNORE or WARN settings. -A new parameter MAXFINDS= (aliases MAXFIND=, MAXFI=, MAXF=) specifies the number of FIND warning messages RMFV070W, RMFV071W, RMFV072W, and RMFV073W to be shown for each RMF III data set processed when the WARN setting is in effect. The default is MAXFINDS=10. -With the MAXFINDS= default up to 10 each of RMFV070W, RMFV071W, RMFV072W, and RMFV073W warning messages could be shown for each RMF III data set processed. The counter is reset for each new RMF III data set. -An extra RMFV037I message displays the numeric value assigned to MAXFINDS= at ASMRMFV startup. -MAXFINDS=0 EXCLUDES all FIND warning messages and has the same effect as coding SCERR=IGNORE, RCERR=IGNORE, WLERR=IGNORE, and RGERR=IGNORE. -MAXFINDS=MAX allows virtually unlimited FIND warning messages to be shown per RMF III data set. -Documentation Section 2 "Terminology" has been expanded. -Documentation Section 6 "Report Control Parameters" is updated for the new MAXFINDS= parameter. -Documentation Section 8 "Error Handling Parameters" is updated for the new SCERR=, RCERR=, WLERR=, and RGERR= parameters. -Documentation Section 9 "JCL and SYSIN Parameter Usage" has been updated. -Documentation Section 12 is now called "Messages" and now includes ALL possible messages that can be produced by ASMRMFV. For each message there is a discussion of purpose, whether the message is Multi-Line and/or Multi-Severity, possible action(s) to be taken, and an explanation of all variable fields in the message. -Documentation Section 17 "Abend Reason Codes" is updated. -Documentation Section 21 is now called "Extended ASI/ENC/RCD/UWD Record Support" and has been updated. -Documentation Section 24 "Sysplex Master Gatherer" is updated for the new MASTER RMF III option in z/OS 2.1. -Message RMFV032E was missing trailing +++ characters. -Message RMFV034I is now message RMFV017I and message RMFV034I is no longer in use. -Error message RMFV043E is now a severe error message RMFV043S. -Message RMFV052* (* = I,W,A) had an invalid value for CISIZE. -Message RMFV106W was missing trailing * character. -Two new diagnostic only messages for the ASI table RMFV076I and RMFV077I have been added but do not normally appear without a special procedure. -Data ORIGIN message RMFV009I now includes the RMF Version Number, z/OS Version and Release Number, and the MINTIME sample time stamp to better identify the source of data being processed for each RMF III data set. -In the event multiple RMF versions have created data in an RMF III data set message RMFV009I will be repeated as needed for each new version detected. -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 Warren Cravey, Fidelity Institutional, USA.
IMACICVG
UTILEXCL May 8, 2014 Thanks to Alfred Holz, Express-Scripts, USA.
IMACICMX unpopulated/useless 128 bytes added to each CICS 110-1, UTILEXCL so UTILEXCL is updated to detect the new length and tell May 4, 2014 you to tailor the new IMACICMX member. The previous 256 length is still detected and IMACICMR identified for you to tailor. IF BOTH IMACICMR and IMACICMX are identified in your data, please send the UTILEXCL output using the first example to support@mxg.com and we will return a tailored member that will support both lengths.
VMACVMXA zero, VMDUSER is removed from VXPRCMFC BY list as it is May 4, 2014 not always populated.
VMACNDM formatted with $MGNDMNT. May 1, 2014
VMAC30 CPUASRTM to CPUSRBTM. Now, the CPUUNITS and SRBUNITS are May 8, 2014 also corrected by moving ASRUNITS from CPU to SRB, since CPUASRTM is SRB, and not TCB, time. Thanks to Julian Smailes, Experian, ENGLAND.
VMACDCOL the DSECT in Access Method Services has the wrong offset May 1, 2014 for the 10 reserved bytes, which misled me to incorrectly input UMLRECL. Thanks to Steve Gormley, UNUM, ENGLAND.
VMAC7072 caused zero observations in PDB.TYPE70 for records from Apr 28, 2014 OS/390. Now, IF VERSNRMF LE 607 THEN OS390='Y' is set and used to force output when TYPE70EN has no observations. Thanks to Jeff Fracas, WIPRO, USA.
ADOC102 revised _S102nnn dataset sort macros that now correctly VMAC102 PROC SORT NODUP DATA=_Wdddddd OUT=_Ldddddd, WORK to PDB. Apr 26, 2014 (Previously, a DATA _Ldddddd; SET _Wdddddd; was used in the "sort" macro to copy from WORK to PDB data library). -The BY list _V102SRT _B102nnn, where V102SRT is this list of common variables used for all T102Snnn sorts SYSTEM QWHSSSID QWHCPLAN QWHCAID QWHSLOCN QWHCCV QWHCCN QWHSSTCK QWHSWSEQ and _B102nnn is the IFCID-specific variables that are also needed for NODUP to work. -But: NODUP can ONLY be verified with actual data records: These IFCIDs had 50% removal with _ALL_ BY List: 004 005 006 007 022 027 053 058 059 060 061 062 063 064 064 066 072 703 074 075 080 081 082 086 090 091 095 096 107 108 109 112 142 173 177 191 199 208 225 247 250 254 261 262 263 267 268 340 342 343 350 359 361 362 366 370 371 377 This 1 IFCID needed it's _B102199 BY List Populated: 199
These 24 IFCIDs did not remove 50% with _ALL_: 023 024 025 055 083 087 106 140 141 143 144 145 169 172 192 196 219 220 258 313 319 337 402 SSS All other IFCIDs had zero observations so it is not known if the default _V102SRT BY list is sufficient, but you can easily verify, by reading the same SMF input twice with %READB2(IFCID=nnn,PDBOUT=PDB) and observing if the PROC SORT duplicate observation count is equal to to the output observations, i.e., 50% of the input. -Obscure: Previously, variable T102RECN was accidentally output with the physical record number in the SMF input file, when it should have been a missing value, as it was intended for internal debugging or support diagnostics. But that non-missing value prevents NODUP removal of any duplicate records, since duplicates would have different values in T102RECN. It can't be dropped without possibly causing someone's "perfectly good programs" to fail, so it is now set to a missing value, as intended. If you needed to know which SMF record created an obs, you can populate T102RECN by inserting this statement %LET MXGDEBUG=T102RECN; in your //SYSIN input. Thanks to Scott Barry, SBBWorks, Inc, USA.
VGETOBS only under SAS V9.2, the newly-used-in-32.04 FEXIST() Apr 27, 2014 function didn't recognize a valid //PDB DISP=NEW DDNAME that had already been written to; the BUILDPDB failed with CRITICAL ERROR PDB DDNAME NOT FOUND when VMXGCICI made the first VGETOBS call to create PDB.CICINTRV. -The RUN; statement is required to be inserted inside the %MACRO VGETOBS definition to force resolution of input %macro variables before their reference, discovered when %ANALZPCR failed to create any output. -The FEXIST(DDNAME) function replaced a PROC SQL in 32.04 (to determine if the DDNAME existed when DDNAME.DATASET didn't exist) because it looked simpler and faster with a large VTABLE, but the measured difference was small and large VTABLEs are very uncommon, so the initial test for DDNAME existence is changed to %SYSFUNC(LIBREF(&DDNAME)), with code reordered to expect existence, the normal case. The fall thru to find if the DDNAME exists but has not been opened/assigned, reverts to use the PROC SQL on DICTIONARY.EXTFILES to avoid 9.2 FEXIST problem. -Why is VGETOBS so pervasively used in MXG? First, to verify that the DDNAME.DATASET of interest exists. Often in MXG internal code, like VMXGWORL, so MXG can find and copy/delete the WORK/PDB copy transparently, and often in ANALxxxx report members that require your names as input, VGETOBS is used to verify your request does exist. By finding the non-existence before the reference, the user can be alerted with explanatory MXGNOTES. Otherwise, not only does the job eventually fail, but the failure error messages can be quite confusing (BY VARIABLE NOT FOUND) as they are not the actual cause of the failure. Second, MXG can significantly reduce tape mounts and EXCPs using VGETOBS to detect that tape or sequential format library is in use; since SEQ doesn't have a directory of datasets on tape, MXG can bypass the read of each tape volser to find that this DATASET exists. And third, many of the ANALxxxx/ASUMxxxx members use VGETOBS to bypass execution of DATA and PROC steps where there is no data to report or summarize. Thanks to Jim Horne, Lowe's, USA. Thanks to Robert B. Richards, OPM, USA.
NEARTIME to provide nearly current time reports throughout a day. Apr 21, 2014 You can build a complete PDB each time, or only process a few records that you may want to have available during each day. It can create all of the PDB datasets in the LIBNAME of NEARTIME, and after all datasets are created and sorted, it can either APPEND or COPY those datasets from the NEARTIME data library to the PDB data library. It keeps track of its last run in SPIN.LASTRUN and for the first run on a new day, it PROC COPYs to initialize, or PROC APPENDs all datasets found in NEARTIME to PDB. If you choose to run a full BUILDPDB, the standard invocations of RMFINTRV CICINTRV ASUM70PR and ASUM113 are suppressed until after the copy process is complete, so that the summarizations include all the data to that point in time and they are redriven with every execution. The JOBS/STEPS/PRINT datasets are built by the normal BUILDPDB process, where SPINCNT is incremented for each execution, so you may need to increase the SPINCNT value in your IMACSPIN tailoring to account for the increased number of executions per day. You could even add an MXG step to your SMFDUMP routine to cause the daily PDB to be as current as the last SMF dump. This has been tested by two sites, so please use with caution and report any problems, and any enhancement suggestions.
VMXG70PR
Apr 21, 2014 Change 32.097 The pairing-macros sorts for the TRANSIT report wrote to ANALDBTR T102Snnn dataset names that overlaid the originals and Apr 21, 2014 caused SORTED BY errors. Now, P102Snnn names are used.
ANALID design removed a PROC SQL that had (accidentally) caused VGETOBS instantiation of a macro variables, exposing an error in Apr 20, 2014 ANALID where a RUN statement should have been used. The missing RUN; statement is added in ANALID, but a second RUN; statement is added at the top of VGETOBS in case any other members needed that accidental protection.
TRNDDB2A
Apr 20, 2014 Change 32.094 Support for SMF ID=92 Subtypes 16 and 17 create: EXTY9216 dddddd dataset description EXTY9217 TY9216 TYPE9216 SOCKET/CHARSPEC FILE CLOSE IMAC92 TY9217 TYPE9217 FILE ACCESSES WHILE OPEN VMAC92 But, the subtype 16 is NOT documented in the z/OS 2.1 SMF VMXGINIT SMF Manual nor in SYS1.MACLIB ember BPXYSMFR, so none of Apr 20, 2014 the subtype 16 specific variables are created, pending response from IBM with the documentation. -Reading a subtype 17 record with earlier VMAC92 will print a harmless INVALID READTIME message. Change 32.093 -RMF III Documentation Upgrade ADOCRMFV -There are now 25 sections in the ASMRMFV source ASMRMFV prologue documentation and in the corresponding Apr 20, 2014 ADOCRMFV member as follows: Section Contents ------- -------- 0 Contents 1 Installation 2 Terminology 3 Execution JCL 4 RMF III Table Input Selection Parameters 5 Input Data Selection Parameters 6 Report Control Parameters 7 Output Data Control Parameters 8 Error Handling Parameters 9 JCL and SYSIN Parameter Usage 10 Parameter Syntax Rules 11 Parameter Coding Examples 12 Common Report Messages 13 Filtered Records 14 Skipped Records 15 Program Limitations 16 Return Codes 17 Abend Reason Codes 18 REGION Size and Memory Usage 19 Output LRECL 20 FREE=CLOSE 21 Extended ASI/ENC/UWD Record Support 22 RMF III Data Set Index Usage and Sizing 23 RMF III MONITOR III Options and Effect on Data 24 RMF III MONITOR III Sysplex Master Gatherer & CFDETAIL 25 Summary -Section 1. New. "Installation" has been added. -Section 2 "Terminology" has been expanded. -Section 12 "Common Report Messages" is greatly expanded to include most information-only messages in the ASMRMFV log. -Section 17. New. "Abend Reason Codes" added. Each Abend Reason Code that can be issued is now unique with no repeat usage. -REQUIREMENT: In order to implement the unique Abend Reason Code feature 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.
VMACTMVS This change updated the TMVSSYS dataset. Contact support Apr 17, 2014 at MXG to request the next dataset(s) you need updated.
VGETOBS and increase EXCP counts; both effects are now corrected: Apr 17, 2014 -If there are tape DDs in the step, a loop inside the Jul 11, 2014 macro did not use the correct index in VGETTAPES string (contains all detected TAPE data library DDNAMES). Only the first was found so other tape DDs could be read to look for the needed dataset, causing an increase in EXCPs and elapsed times. VGETOBS now uses the %SYSFUNC for the EXIST function that checks for the existence of a SAS dataset, and for the FEIXST function that validates the EXTFILE name, and uses OPEN/CLOSE to get the number of OBS in the dataset, instead of using the (expensive) dictionary tables, unless DATASET=_ALL_ was specified to build the MXGTABLES dataset. -On zOS, VGETOBS can optionally build a dataset to keep track of all tables it finds. Then, when done, it deletes that table, but that destroyed the SYSLAST/_LAST_ value, so a subsequent PROC step without a DATA= argument failed with a dataset not found error. Now, VGETOBS preserves SYSLAST in VGETLAST and resets SYSLAST to VGETLAST. -Jul 11: THIS ERROR CAN ALSO SIGNIFICANTLY INCREASE THE CPU TIME of any job with LOTS of VGETOBS executions. In one case, 29.06 took 20 seconds, while 32.01 took 192. Thanks to Betty Wong, Bank of America, USA. Change 32.090 AUTOEZOS/CONFIGEZ provide new "EAZY" methods to execute AUTOEZOS MXG on z/OS with SAS 9.2 and above, using your site's SAS CONFIGEZ JCL procedure and your site's default SAS options. JCLEZCFG Jul 19: WPS 3.1.1 is required for AUTOEZOS. JCLEZSAS -The JCLEZSAS example %INCLUDEs the new AUTOEZOS member, Apr 17, 2014 which uses the SAS APPEND= option to set the //LIBRARY Jul 19, 2014 DDNAME for the MXG Formats, uses the SAS INSERT= option to add SOURCLIB to SASAUTOS, and then invokes %VMXGINIT to set the other options required for MXG execution. This is the simplest way to set up the MXG environment, but it does require that your site's SAS options do not conflict with those needed by MXG's environment. (It is unlikely you would need to tailor AUTOEZOS.) -The JCLEZCFG example would be used if your default SAS options conflict with those required by MXG, where simple JCLEZSAS cannot be used. JCLEZCFG adds a CONFIG= option // EXEC SAS,CONFIG='MXG.SOURCLIB(CONFIGEZ)' as CONFIGEZ sets ALL MXG-required options; the JCLEZCFG example also then %INCLUDES AUTOEZOS, as above, to set the LIBRARY and SOURCLIB DDNAMEs and to invoke %VMXGINIT. Since all MXG required options are in CONFIGEZ member, it is unlikely that you would need to tailor it, although those SAS options that must be set at SAS Initialization can only be set in that CONFIGEZ member. Thanks to MP Welch, Bank of America, USA.
VMAC30 CPUASRTM (SMF30ASR), but ASR is time under an SRB, so ASR Apr 17, 2014 is now subtracted from CPUTCBTM and added to CPUSRBTM so Aug 7, 2014 those variables match reality; this has no impact on the total CPUTM variable (which IMO should be used, always). MXG also had subtracted CPUASRTM from CPUTCBTM to create TASKGCPTM, but that subtraction is redundant and removed. - I am asking IBM SMF if the new ASR Instruction Counts are also included in the CPT Instruction Counts. Apr 23: IBM RMF support replied that the WLMGL Report in the RMF Report Analysis Book shows under SERVICE, that CPU service includes the task and preemptible-class SRB processor service, and the SRB units contain only the non-preemtible SRB service units. Unfortunately, in the RMF 72 records, there is no "ASR" field with either the service or CPU time of the preemptible-class SRB metric. Aug 7: This reduction in CPUTCBTM increased the value of variable AVGWKSET in TYPE30 datasets, calculated as AVGWKSET=4*PAGESECS/CPUTCBTM; starting with MXG 32.04. Thanks to Julian Smailes, Experian, ENGLAND. Thanks to Brent Turner, Citigroup, USA. Change 32.088 Support for NMON BBBPMOUNT and BBBPNETSTAT records create EXNMONMT new datasets: EXNMONNS DDDDDD DATASET DESCRIPTION IMACNMON NMONMT NMONBBBPMOUNT NMON BBBP MOUNT VMACNMON NMONNS NMONBBBPNETSTAT NMON BBBP NETSTA VMXGINIT The mount record contains only the month and day without Apr 17, 2014 a year; if the current month is larger than the mount month, the mount date uses last year's year value. -An INVALID ARGUMENT to FUNCTION INPUT when BBBPEND051 had a one-digit hour value was corrected. -Jul 17: Cosmetic. _WNMONFR, _WNMONFW and _WNMONFO in the MACRO _NNMON were removed; they never existed. Thanks to Len Marchant, Coke-Cola, USA.
VMAC120 Manager record creates new dataset: VMXGINIT dddddd dataset Description IMAC120 T1201C TY120100 ODM OPERATIONAL DECISION MANAGER EXT1201C Jun 3 update, in MXG 32.05: Apr 18, 2014 -Only Subtype 100 with non-zero EXN are output; st-100's Jun 3, 2014 are written every interval (30 minute default), one for each CICS APPLID in test data, but most have no segment; some records do have multiple EXN segments so each one is now output in dataset TY120100. Yüklə 28,67 Mb. Dostları ilə paylaş:
|