The sample rule member shown in Appendix A provides a typical set of rules for ACC and SRS. It is designed to show the syntax needed for some of the most common uses of ACC and SRS. Because it is merely an example, it is unlikely that you will want to use it unchanged at your installation. There are many ACC and SRS functions which are not shown in the sample. However, you may want to use the sample rule member as a model for your own rules, after adapting it to fit your installation’s needs for naming conventions, volume definitions, and execution requirements.
Overview of the sample rule member
The sample rule member is divided into a number of sections. The following sections describe each part of the sample rule member and the function of each statement.
The first section of the rules provides defaults and initialization values that will be used later. This includes defaults for items such as the SMF record number to be used by SRS, the type of pattern matching to be used in the rules, and how often the rules are to be processed.
DEFPROD – set product-wide defaults
The DEFPROD statement provides defaults which are used unless overridden by subsequent statements such as DEFENV, DEFPOOL, and DEFMSG. In the sample rule set, there are three parameters present on the DEFPROD statement, each of which is described below.
SMF parameter
The first parameter, SMF, indicates that SRS is to write record type 221 (decimal) whenever SRS processing is performed for a dataset. The LEVEL subparameter indicates that SMF records are to be written for all SRS messages (I = informational), rather than just action (A), warning (W), or error (E) messages. These SMF records may be analyzed and reported on by the SRSSMF program included with SRS. SRSSMF provides reports on the number and types of out-of-space errors prevented by SRS, including the name of the dataset and job encountering the error. SMF recording must be enabled for the record type specified in order for SRS to successfully write SMF records.
Wildcards and masking
The DIF rules support wildcards and masking characters. The default pattern matching characters are very simple and are adequate for most types of pattern matching. However, the defaults used by DIF are slightly different from those used in the DFSMS ACS routines. The default, which is explicitly specified in the sample rule set, is indicated by OPTION(NOSMSMASK). In this case, ACC and SRS will use the default pattern matching values. The defaults are:
- * – Indicates any sequence of characters. This may include multiple qualifiers for dataset names.
- ? – Indicates any single character.
If OPTION(SMSMASK) is specified, the above patterns are used for all variables except dataset names or VSAM cluster or component names. For these variables, the same pattern matching scheme used by the DFSMS ACS routines is used. That is, for dataset names, the following pattern matching characters are used:
- * – One or more characters or a single qualifier in a dataset name
- ** – One or more characters or multiple qualifiers in a dataset name
- % – A single character in a dataset name
Shared rule sets and pool name indexing
ACC and SRS may share the same rule set, or each product may use a different set of rules. The rule set used by each product is specified on the START command issued to DIF when the product is started, or on the REFRESH command when the rules are refreshed after a change.
If ACC and SRS each use different rule sets, it is possible that the names of the pools (specified on the DEFPOOL statements in the rules) may overlap. In this case, the POOLNAME(INDEX(n)) parameter must be specified to allow ACC and SRS to determine which pool should be used when processing the dataset. In the example, the default value, POOLNAME(INDEX(1)) is specified. If a different, additional set of rules is used for SRS, and some of the pool names in the SRS rules are the same as those in the ACC rules, then POOLNAME(INDEX(2)) should be specified in the SRS rules.
DEFENV – processing defaults for environment
The DEFENV statement provides additional default values for processing that is to take place in a particular ACC or SRS environment. ACC and SRS may receive control from the operating system at several points during processing of a dataset.
For example, ACC receives control early in allocation processing (the DD environment) to alter JCL or IDCAMS characteristics such as primary space or unit name. ACC may receive control again later (during DADSM environment, for example), in order to reject undesirable disk volumes, or at end-of-step processing (the EOFMARK environment) to write an end-of-file mark for an unopened non-SMS dataset.
The DEFENV statement indicates whether the ACC / SRS rules are to be processed in a given environment and what types of datasets (tape or disk, new or old) are to be processed.
Environments may be active or inactive. If an environment is active, ACC or SRS will perform rule processing and take the actions specified in the rules for the dataset. In general, the necessary environments for a product are active by default. Therefore, the DEFENV statement is not a required statement. Once a pool has been assigned to a dataset by the rules, rule processing is not normally performed in other environments unless the RULES(ALWAYS) parameter is specified.
DEFFILT – defining filter lists
The DEFFILT statement provides a means of referring to a list of datasets or volumes in later rules. In the sample rule set, there are two filter lists. The first, INACTDSN, specifies a list of dataset name masks that will be used in a later rule. The second filter list, BVOLS, specifies a list of volumes which will later be used in a pool definition.
Note that the BVOLS list includes all volumes beginning with the characters BAX or BAY, except for two particular volumes, BAX001 and BAY001. FILTLIST may be used as a synonym for DEFFILT.
DEFDMYx – process obsolete units / volumes
These two statements allow ACC to intercept JCL or IDCAMS requests for volumes or units which no longer exist on the system, and convert them as necessary to allow the job to run.
The first statement, DEFDMYU, indicates that if no UNIT name is specified ($NONE), or if an invalid UNIT name is specified ($CHECK), then UNIT=SYSALLDA is to be used. This prevents jobs from going into allocation recovery processing or receiving JCL errors if UNIT names are missing or invalid.
The second statement, DEFDMYV, is used to prevent a problem which can occur if an IDCAMS DEFINE statement contains an invalid or obsolete volume serial number. Normally, if such an IDCAMS DEFINE is specified, and the DEFINE statement happens to include the UNIQUE parameter, then IDCAMS will attempt to dynamically allocate the specified volume, resulting in allocation recovery processing or an IDCAMS error. The $CHECK parameter allows ACC to check for a nonexistent volume serial number and convert the unnecessary allocation to DUMMY, thus preventing the error.
Initial rule definitions
Once defaults have been established, the first section of rules is specified. The DEFRULE statement defines the rule, which may be followed by one or more IF statements. Usually, the rules which have the widest scope, i.e., those which encompass all jobs or all datasets, should be specified first.
In the sample rule set, some jobs and datasets are to be excluded from ACC and SRS control. The first IF statement indicates the jobs for which ACC/SRS processing is to be bypassed, and the EXIT parameter on the THEN clause indicates that rule processing is complete. The second statement uses a filter list to indicate datasets which are not to be processed. Note that the filter list name must include an ampersand to distinguish it as a variable. Finally, the third IF statement bypasses processing for SORTWK datasets, as allocation and use of these datasets is normally controlled by the system sort.
Bypass SRS ADDVOL checks section
The next section of the sample rules allows SRS to add volumes to some types of datasets that would normally not be eligible for ADDVOL processing. By default, SRS does not attempt to add volumes to datasets which are written via the EXCP access method or which are processed with the NOTE or POINT macros.
Processing is bypassed in these instances because SRS cannot be certain that the applications accessing the datasets support multiple volumes. In nearly all modern applications, however, multivolume support is automatic, and these restrictions can be bypassed.
In the sample rule set, ADDVOL processing is allowed for sort and copy utility output datasets and for DB2 utilities, since it is certain that these types of datasets can be accessed if they are multivolume.
Note the presence of the CONTINUE(NEXTIF) parameter on the DEFRULE statement. Since rule processing normally ends when the first IF / THEN / ELSE statement is satisfied, the CONTINUE parameter is required in order to process the remaining rules after setting the SKIP_EXCP and SKIP_NOTE or SKIP_POINT flags.
Standards enforcement rules
One of the most important uses of ACC and SRS is to enforce installation standards. The next few rules provide standards for testing. Jobs or datasets are checked to see if they are in compliance with the installation’s requirements, and actions such as issuing messages or altering allocation values are taken if necessary.
Only a few very simple examples of standards enforcement are shown here. For more information and examples, refer to the ACC / SRS User’s Guide.
Setting RLSE
The first rule, SETRLSE, allows idle, unused space at the end of a dataset to be released when the dataset is closed. This is done by first testing to see if the dataset is being newly allocated (&ENV = DD and &DISP1 = NEW) by a batch job (&JOBTYPE = JOB) and if it is one of a particular group of datasets with a desired high-level qualifier. If so, then the &RLSE variable is set to YES. This has the same effect as coding RLSE in the JCL.
Redirecting tape allocations
The next rule, SELTAP2, is used to redirect allocations of tape datasets to a different type of unit. In this case, if a tape dataset is being allocated, and UNIT=3480 or UNIT=STAP was specified, the allocation is directed via the SET &TAPEPOOL statement to a 3490 unit and a message is written to the JES log of the job indicating the action that was taken.
In this example, the message and the tape pool are specified by a DEFMSG statement and a DEFPOOL statement that immediately follow the DEFRULE. In other rules, the DEFMSG and DEFPOOL statements are not placed adjacent to the rule, but are placed in a group at the end of the rule set. Either means of coding is acceptable.
The ENDTAPE rule checks to see if the dataset being processed is a disk dataset, and if so, processing is allowed to continue. Otherwise, the rules are exited, preventing any subsequent rules from doing any processing of tape datasets.
Controlling RENAME processing
The next rule, TSTRENAM, enforces installation standards for the renaming of non-VSAM datasets. First, a test is made to see if a dataset is being renamed, i.e., if the DADSM environment is in effect and if the subenvironment name (&ENVS) is RENAME.
If so, then a second, nested IF statement (placed within a DO-END group, as is required for nested IFs) checks to see whether the old and new high-level qualifiers of the dataset name are different. If so, the rename is disallowed via the SET &JCLFAIL = YES statement. A message is then issued indicating the reason for the failure. The MSGNOAL parameter on the WRITEMSG statement refers to the name of a DEFMSG statement specified at the end of the rules.
If the old and new high-level qualifiers match, the rules are exited, as there is no need for any further processing to be performed in the DADSM environment.
Volume allocation warnings
The last rule in this section, SELNOAL2, issues warnings if certain non-SMS datasets are being allocated on particular volumes. A check is made for the specified high-level qualifiers and for their SMS status, and a message is issued if a standards violation is found.