Error ADSSI001 3617 IGD308I DATA SET ALLOCATION REQUEST FAILED
Article ID: 44634
Updated On:
Products
Issue/Introduction
When converting from HSM to Disk™ Backup and Restore, cannot restore data sets that have a high level qualifier from a revoked user. The following messages are for the revoked userid and the Restore job completes with RC=08:
ICH408I USER(uuuuuu ) GROUP(xxxx ) NAME(yyyyy zzzzz )
LOGON/JOB INITIATION - REVOKED USER ACCESS ATTEMPT
and
ADSSI001 3617 IGD308I DATA SET ALLOCATION REQUEST FAILED -
ADSSI001 3617 RACF FUNCTION: RACDEF FOR
ADSSI001 3617 DATA SET: uuuuuu.dsname WITH RETURN CODE 08 REASON CODE 4C
ADSDM069 2433 =========================================================
ADSDM069 2433 AN SVC 99 ERROR HAS OCCURRED IN -- DYNAMIC ALLOCATION
...
Environment
Release: Disk™ Backup and Restore
Cause
DIAGAUTHy diagnostics will indicate that all the Disk RACROUTE calls passed until SVC99 is called to actually allocate the new data set. At this time, RACF will deny access due to the revoked userid which is the owner of the profile/data set based on the RACF definitions. Disk cannot override this function.
Resolution
Set USE_RESOWNER to NO in IGDSMSxx to solve the problem.
Setting USER_RESOWNER to NO in SMS will tell SMS to use the userid of the initiator of the allocation request rather than the owner of the resource. IPL the test system to pick up the new IGDSMSxx value of USE_RESOWNER(NO) and verify that this resolves the issue.
Additional Information
The RACF RESOWNER value, based on the high-level qualifier of the data set name, is the default used to check authorization to use management and storage classes. Another way to check this authorization is to use the user ID that is allocating the data set.
This prevents the problems that can occur with restoring or recalling data sets that have a protected storage class and management class, and that are owned by users whose user or group IDs have been revoked. As the Disk security trace shows, Disk does not make the security call that results in the allocation failure.
It is SMS itself that is making the call during allocation and the USER_RESOWNER setting determines which userid is checked.
With USER_RESOWNER(YES), SMS is going to check the real owner and the security call will fail if that owner has been revoked.
With USER_RESOWNER(NO), the userid of the initiator of the allocation, in this case Disk, is checked.
There is nothing Disk™ Backup and Restore can do because it is SMS that is making the security call and your SMS settings determine how that call will be made.
Feedback
