Implementing Security for DFSMS › Implementation Considerations

Implementation Considerations

Consider how you would like to establish RESOWNERs for data sets. Generally, RESOWNER values should only be added to data set prefixes whose High Level Qualifier does not match a Control or User ACID. If you do not specifically assign a RESOWNER to data set ownership elements, the High Level Qualifier of the data set will be returned as the RESOWNER, if it matches a defined User or Control ACID.

For ACID‑related data sets, using the High Level Qualifier as the RESOWNER is probably most desirable, because it is the user who creates and allocates the data set. During allocation processing, if the derived RESOWNER for a data set matches the currently signed‑on user, there is less overhead in returning the ACS defaults for this RESOWNER, as well as in the authorization check for the SMS storage class (STORCLAS) and SMS Management class (MGMTCLAS); all information about the signed‑on user already resides in memory.

For production data sets whose High Level Qualifier does not match any defined User or Control ACID, the RESOWNER field should be added to the data set ownership element. To optimize performance, the RESOWNER should be set to the ACID which most commonly creates the data sets that begin with this High Level Qualifier.