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

Products

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

Issue/Introduction

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

How to accomplish MOUNT authority in TSO?

Environment

Release: ACF2..001AO-16-ACF2
Component:

Resolution

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.