Access to read a member in a PDS member level protected dataset should be denied, but is still being allowed. After verifying the dataset rules, resource rules, GSO records, and PTFs were correct and in place, access was still being allowed even though the rules should deny access. CAPDSSEC dataset rules were also verified and PDS member level protection was not being bypassed. An ACFRPTRV report shows that the PDS type resource rule is not being called.
Sample Dataset Rule:
$KEY(TESTDS)
- UID(********TESTUSR) READ(A) EXEC(A)
Sample Resource Rule:
$KEY(********) TYPE(PDS)
UID(*) PREVENT
Sample GSO record:
**** / PDS.TESTLIB LAST CHANGED BY abcd ON 04/19/21-12:50
LIBRARY(TESTDS.INFO.DATA) RSRCTYPE(PDS) VOLUME()
Following PTFs were in place:
SO14051
SO10052
SO05721
SO04551
SO03574
SO00479
RO95963
RO94325
RO86542
Final Resolution:
An APAR was opened at IBM to ensure that the DESB is initialized before the DESERV exit is called for the first time. The APAR number is OA61235.
Symptoms Observed:
A problem was discovered with the input to the DESERV exit (CAS4DSRV). There are a number of control blocks that get picked up by the code and validated before any GETMAIN is issued to ensure that the environment appears correct. The input field DESP_AREA_PTR had a non-zero value which does not address a valid 'IGWDESB', so ACF2 was unable to handle the request properly. According to IBM documentation there should be a value in either DESP_AREA_PTR or DESP_AREAPTR_PTR addressing the DESB area. DESP_AREAPTR_PTR contained zeros. IBM confirmed the DESB is not initialized before the first call to the exit and that it is done afterwards, during the GET processing.
Parameters related to the GET function can be found in IBM documentation under Parameters Related to the GET Function
Information about implementing PDS Member Level Protection in ACF2 can be found in the ACF2 documentation under Implement Member-Level Protection