Using asterisks within names specified in IFS entries - assure_mimix - 10.0

Assure MIMIX Administrator Reference

Product type
Product family
Assure MIMIX™ Software
Product name
Assure MIMIX
Assure MIMIX Administrator Reference
First publish date

MIMIX supports the ability to specify asterisks to define basic and advanced generic names in data group IFS entries.

A basic generic name contains one or more characters followed by an asterisk (*) as its last (trailing) character. The asterisk is used as a wildcard character. An example is: /ABC*. Basic generic names can be specified in IFS entries that include or exclude IFS objects.

An advanced generic name contains one or more asterisk (*) characters embedded within the name that are used as wildcard characters. An advanced generic name is allowed only when the IFS entry specifies *EXCLD as its Process type (PRCTYPE). Examples are: /ABC/*.LOG or /ABC/*TMP*/*.WRK. An *EXCLD IFS entry with an advanced generic name acts as a filter to exclude objects that would otherwise be included by a match to an *INCLD IFS entry with a basic generic name.

The Work with DG IFS Entries display (WRKDGIFSE) identifies these entries with the value *EXCLD(A) in the Process Type column.

Note: In instances that have been upgraded from MIMIX or an earlier software level, you may see *INCLD IFS entries identified as having advanced generic names. These entries existed prior to upgrading and the asterisks within them are interpreted as literal characters, not wildcard characters. The way in which these entries are processed has not changed, but they are now identified on the Work with DG IFS entries (WRKDGIFSE) display as *INCLD(A). These entries cannot be changed or copied. It is recommended that you evaluate whether these entries for including objects are necessary and consider removing them to avoid confusion with how asterisks are interpreted. When adding new entries that specify *INCLD, the only position in which an asterisk is allowed is as the last (trailing) character of the name.

Examples of implementing advanced generic names to exclude directories. It is important to understand how the existence of basic and advanced generic names in an IFS entry that specifies *EXCLD will affect how objects are selected when the set of IFS entries for a data group is evaluated.

Consider the example IFS entries in Table 20 for IFS objects associated with an SSH directory:

  • If you need to include only the SSH objects but nothing else from user SUZYQ’s directory, and need to include all other IFS objects for other users in the /home directory, you can accomplish this with entries 1 through 4, without entry 5.

  • If you need to include the /home directory but exclude SSH objects for every user in the /home directory as well as exclude everything associated with user SUZYQ, you can accomplish this with entries 1 through 5.

When entries 1 through 5 exist, although all SSH objects in path /home/SUZYQ/.ssh/ are a match to *INCLD entry 4, these SSH objects are excluded because the match to entry 4’s basic generic allows entry 5 to be evaluated, and the path also matches entry 5. This causes the SSH objects in SUZYQ to be excluded. The directory SUZYQ and its other content are excluded by entries 2 and 3.

When entries 1 through 5 exist, all objects in path /home/JOHNDOE/.ssh/ are excluded because of entries 1 and 5.

Table 1. IFS entry examples with an advanced generic name in an exclude rule

IFS Entry

Entry Type

Specified Name in Entry





Basic generic name to include private directories of all users.




Specific name to exclude the directory for this user.




Basic generic name to exclude contents of this user’s directory.




Basic generic name to include the contents of this user’s SSH directory.

Note: This rule is effectively overridden and not used when entry 5 exists.




Advanced generic name to exclude objects in each users SSH directory SSH