Examples of changing of an IFS object’s auditing value - assure_mimix - 10.0

The following examples show the effect of the value of the FORCE parameter when manually changing the object auditing values of IFS objects configured for system journal replication.

The auditing values resulting from the SETDGAUD command can be confusing when your environment has multiple data group IFS entries, each with different auditing levels, and more than one entry references objects sharing common parent directories. The following examples illustrate how these conditions affect the results of setting object auditing for IFS objects.

Data group entries are processed in order from most generic to most specific. IFS entries are processed using the unicode character set. The first entry (more generic) found that matches the object is used until a more specific match is found.

When MIMIX processes a data group IFS entry and changes the auditing level of objects which match the entry, the object is checked and, if necessary, changed to the new auditing value. In the case of an IFS entry with a generic name, all descendants of the IFS object may also have their auditing value changed.

Example 1: This scenario illustrates why you may need to force the configured values to take effect after changing the existing data group IFS entries from *ALL to lower values. The current auditing value on the object may be from the previously configured value or may be the result of changes by an IBM command. The below table identifies a set of data group IFS entries and their configured auditing values. The entries are listed in the order in which they are processed by the SETDGAUD command.

For this scenario, running the SETDGAUD command with FORCE(*NO) does not change the auditing values on any existing IFS objects because the configured values from the data group IFS entries are lower than the existing values.

In this scenario, SETDGAUD FORCE(*YES) must be run to have the configured auditing values take effect. Table 41 shows the intermediate values as each entry is processed by the force request and the final results of the change.   

Example 2: This example begins with the same set of data group IFS entries used in example 1 (Table 40) and uses the results of the forced change in example 1 as the auditing values for the existing objects in Table 42.

Table 42 shows how running the SETDGAUD command with FORCE(*NO) causes changes to auditing values. This scenario is quite possible as a result of a normal STRDG request. Complex data group IFS entries and multiple configured values cause these potentially undesirable results.

There is no way to maintain the existing values in Table 42 without ensuring that a forced change occurs every time SETDGAUD is run, which may be undesirable. In this example, the next time data groups are started, the objects’ auditing values will be set to those shown in Table 42 for FORCE(*NO).

Any addition or change to the data group IFS entries can potentially cause similar results the next time the data group is started. To avoid this situation, we recommend that you configure a consistent auditing value of *CHANGE across data group IFS entries which identify objects with common parent directories.

Example 3: This scenario illustrates the results of SETDGAUD command when the object’s auditing value is determined by the user profile which accesses the object (value *USRPRF). Table 43 shows the configured data group IFS entry.

Table 44 compares the results running the SETDGAUD command with FORCE(*NO) and FORCE(*YES).

Running the command with FORCE(*NO) does not change the value. The value *USRPRF is not in the range of valid values for MIMIX. Therefore, an object with an auditing value of *USRPRF is not considered for change.

Running the command with FORCE(*YES) does force a change because the existing value and the configured value are not equal.