What in ACF2 controls a User's ability to issue a MOUNT command in TSO?
search cancel

What in ACF2 controls a User's ability to issue a MOUNT command in TSO?


Article ID: 11185


Updated On:


ACF2 ACF2 - DB2 Option ACF2 for zVM ACF2 - z/OS ACF2 - MISC PanApt PanAudit


Documentation for newly installed software states the user must have MOUNT authority in TSO.

How to accomplish MOUNT authority in TSO?


Release: ACF2..001AO-16-ACF2


There is an attribute called MOUNT|NOMOUNT in the TSO user's lidrec. If the lidrec has the MOUNT attribute, it will appear in a LIST of the lidrec in the TSO group. It is one of several attributes that ACF2 has added to the lidrec to support its replacement of UADS. MOUNT controls the ability of a user to issue a TSO MOUNT. If the user issues a MOUNT command and does not have this attribute in his lidrec, TSO will issue a RACROUTE REQUEST=AUTH CLASS=TSOAUTH request with an ENTITY of 'MOUNT' to determine if the user is allowed this privilege by external security. ACF2 provides an internal SAFDEF with MODE=GLOBAL for the TSOAUTH class to ensure the RACROUTE request will be processed if issued, and an internal CLASMAP to map the TSOAUTH resource class to a TYPE of SAF. We recommend a user-defined CLASMAP to map TSOAUTH to a more descriptive type code. An appropriate resource rule for this type and the $KEY(MOUNT) would need to be written to allow the user this authority.