[size=6][font=Comic Sans]In an ACF2 r14.0 System, you could see Resource FSA and zFS anomalies. For example, the following Rule works for one User ID but not another:
========================================================
RESOURCE RULE SYSFS.- STORED BY A90053 ON 07/05/13-11:05
$KEY(SYSFS.-) TYPE(FSA)
$USERDATA(ITD - TECH. SERVICES)
UID(*) SERVICE(UPDATE) ALLOW
========================================================
...the only difference, the User ID that works has 'NON-CNCL'. The Rule is designed to allow all Users access to zFS named 'SYSFS.*'. (Informational PTF RI38633 states new Rules need to be RESIDENT in GSO and the REBUILD command is to be run after all Rule changes.)
The reason for this FSACCESS Resource Rule problem is the KEY was setup containing non-valid masking characters.
The ACF2 Administration Guide, Chapter 7, Section titled 'Using Masking in Resource Rules', sub-section '$KEY Masks' states:
============================================================================================================================================================================================
You can use the asterisk (*) to mask the $KEY control statement value. However, you cannot use the dash (-) as a masking character in the $KEY value. When a dash occurs in the $KEY value, CA ACF2 treats it as a literal character for matching purposes. For example, a Resource name or qualifier of TEST.ABC- matches only TEST.ABC-.
============================================================================================================================================================================================
If the Rule KEY contains $KEY(SYSFS.-), the only Resource it will match is 'SYSFS.-'. You can use '-' on the Rule line but not on the KEY.
The Rule could be changed to:
==============================
$KEY(SYSFS) TYPE(FSA)
$USERDATA(ITD - TECH. SERVICES)
- UID(*) SERVICE(UPDATE) ALLOW
==============================
Note the '-' before 'UID(*)', this will match all lower level qualifiers.[font][size]