Implement DFSMS Support
This section provides the information required for using CA ACF2 to manage the System Authorization Facility (SAF) security calls issued by the IBM DFSMS product series. This information clarifies the CA ACF2 requirements used to secure all DFSMS functions and to make planning for the DFSMS family easier. The
Managed Storage MigrationPlanning Guide advises that a SAF-compatible external security product, like CA ACF2, CA Top Secret, or RACF, is required to protect DFSMS functions. The philosophy of CA ACF2 and CA Top Secret to be SAF-compatible enables this use of SAF classes to smoothly integrate into CA ACF2. The resource names and the associated validations are described in the
IBM System-Managed Storage Migration Planning Guide.
There are no RACF dependencies in the new SAF resource definition or the validations performed against them.
The recommendations made here represent the minimum default specifications you need for establishing DFSMS security using CA ACF2. See IBM DFSMS documentation if you have additional security considerations beyond the scope of this discussion.
What is DFSMS
DFSMS is an IBM designation for the DF/HSM, DFDSS, DFSORT, DFRMM, and RACF products when used in a DFSMS system.
The Data Facility family and RACF provide complementary functions that make up the Data Facility Storage Management Subsystem (DFSMS). As with all previous and planned DFSMS releases, the DFSMS components (DFHSM, DFDSS, DFSORT, DFRMM and RACF), are complementary, but separate products that use MVS/DFSMS services. Although RACF has also been designated as part of DFSMS, RACF is
nota DFSMS product. Furthermore, no DFSMS products require RACF. All SAF-compatible security systems, like CA ACF2, CA ACF2, and RACF, provide equivalent functionality in the DFSMS environment.
DFSMS is the foundation of the Storage Management Subsystem. In releases earlier than MVS/DFP Version 3, basic data management facilities are provided for data set allocation and the enforcement of data and storage attributes. In DFP Version 3, several significant enhancements have been added to simplify catalog processing, integrate VSAM into standard storage management functions, and to allow definition and enforcement of storage allocation requirements using a CLIST-like language for coding data management definitions. The use of explicit device-type allocation, such as UNIT=3380, has also been superseded by the use of generic storage groups and attributes.
Storage Management Classes
The DFSMS Storage Management Subsystem (SMS) includes new features that handle new data set allocations to volumes that it controls, and associates new attributes with those data sets. The Interactive Storage Management Facility (ISMF) provides a mechanism for the storage administrator to specify which volumes are to be under SMS control and which data sets are placed on SMS-controlled volumes; that is, which data sets are SMS-controlled. The process SMS uses to determine whether the data set being allocated is SMS-controlled involves classifying the data set in storage management terms. The data set's storage management classification has no correspondence to or effect on security data classification or security resource classes. SMS implements three types of storage management data set classes: data, storage, and management.
- DataDefines attributes about the data set that would normally be associated with the SPACE, DCB, or AMP parameters in standard JCL. Data class definitions take the place of model space DSCBs, but also include information for VSAM data sets as well. Even if a data set is not SMS-controlled, a data class can be associated with it.
- StorageDefines the type of process that is generally performed for the data set (read or write) and states the performance objectives desired from the backing DASD. Assignment of a storage class to a data set defines the data set as SMS-managed. The storage class assignment affects which SMS-controlled volume is selected to hold that data set.
- ManagementDefines space and availability management attributes of the data set. This includes how often to perform backups and how many backup versions are kept. A management class can only be associated with an SMS-controlled data set.
The class definitions are kept in a control data set. Each class is defined by a unique eight-character name. It is through this name that access to storage and management classes is secured through external security calls. SMS-controlled data sets carry the name of the data, storage, and management classes associated with them in their ICF catalog records.
The DASD volumes that are SMS-controlled are divided into storage groups similar in concept to DASD esoteric unit names. They are similar in that they define a group of volumes, but they are different in these ways:
- Storage groups have volume maintenance characteristics associated with them.
- All volumes in a storage group must have the same number of tracks per cylinder and number of bytes per track.
- A volume can be in only one storage group.
- Storage group definitions are shared among multiple SMS systems because each system shares the control data sets that define them.
If you are using SMS volume control, you do not need CA ACF2 Note 3. SMS provides the same protection and overrides CA ACF2 Note 3.
Automatic Class Selection Routines
When a new data set is allocated, the SMS-managed classes are determined by the Automatic Class Selection (ACS) routines coded by the storage administrator in a language similar to TSO CLISTs. There are four types of ACS routines: three to select the three storage management classes and one to select the storage group where the data set is to reside. These routines have access to information about the job, the user, the data set, and the environment, all of which can impact the selection of the appropriate classes.
When SMS is active, it first passes all new allocations through the data class ACS routine to select the data class and then to the storage class ACS routine to acquire a storage class. If no storage class is selected, the data set
is notSMS-controlled and the allocation continues through normal allocation processing. Otherwise, SMS calls the security system to check the authority of the selected storage class name. The selected storage class is validated through the security system using the eight-byte storage class name.
If a storage class is selected, the data set is controlled by SMS, and the allocation request passes through the management class ACS routine to assign a management class. The SMS-controlled allocation request then passes to the final ACS routine to select its storage group. When users define a data set with JCL, they can code JCL parameters to specify data class, storage class, and management class. Only the ACS routines can assign the storage group. By associating this new information with data sets, data management software can address specific data set requirements. The management of data sets by system software is the basic goal of SMS. To this end, the components of DFP Version 3 provide the following:
- A z/OS component that honors standard subsystem interfaces for communication and the System Authorization Facility (SAF) for all security controls. (This makes SMS information fully accessible by other system software components.)
- A real-time handler of data set classification and new data set allocations on SMS-controlled volumes.
- A DASD device grouping facility.
- A facility to store additional data set information in the ICF catalog entry of SMS-controlled data sets.
- A facility that can help reduce JCL coding requirements.
- A facility to define performance preferences for allocations.
- A source of information for system programs that request it.
In summary, SMS brings new information about DASD data sets that it manages and provides new services to programs and systems that are prepared to use that information.
Understanding the DFSMS Resource Classes
SMS resource protection is provided through two existing and two new SAF resource classes. The classes that existed before DFSMS are FACILITY and PROGRAM. The new classes are STORCLAS and MGMTCLAS.
Controls the use of catalog, IDCAMS, and DFDSS functions against SMS-managed volumes. These new calls supersede the FACILITY resource name of IGG.CATLOCK previously used for controlling catalog access.
Controls the use of all programs, including those used by DFSMS. The programs invoked for the various DFSMS ISMF functions can be protected as resources by using the program name as the resource name.
Controls user access to a specific storage class defined by the storage administrator. Each unique storage class is identified by a unique one- to eight-byte name.
Controls user access to a management class defined by the storage administrator. Each unique management class is identified by a unique one- to eight-byte name.
You can define these four resource classes to CA ACF2 using the GSO CLASMAP record.
During data set allocation processing, DFSMS requests the external security system to derive the resource owner or RESOWNER of the specified data set name. DFSMS validates access to the STORCLAS and MGMTCLAS used during allocation based on the RESOWNER.
In CA ACF2, data set owners can allocate their data sets. Data sets are owned when their high-level qualifier matches the PREFIX field of a user. Other data sets, such as SYS1 or PROD data sets, are not explicitly owned by a logonid, but are used by groups in the organization. For users of CA ACF2 this distinction is important to remember: RESOWNER is used only to validate access to the STORCLAS and MGMTCLAS, not to the data set itself.
To supply DFSMS with a RESOWNER, CA ACF2 must determine a single resource owner of the data set. You can use CA ACF2 DFP profile infostorage records as one way to define the RESOWNER. DFP profile infostorage records let a storage administrator who does not have the authority to update CA ACF2 access rules assign a resource owner to a data set. This method also lets the storage administrator assign a RESOWNER for each data set or group of data sets as desired. For example:
SET PROFILE(DATASET) DIVISION(PROFILE) COMPILE $KEY(pay) online.data DFP(pay001) -.- DFP(pay003) SET PROFILE(DATASET) DIVISION(DFP) INSERT pay001 RESOWNER(paycurr) INSERT pay002 RESOWNER(payhist) INSERT pay003 RESOWNER(payothr)
CA ACF2 supports $KEY masking when you make the rule resident:
SET CONTROL(GSO) CHANGE INFODIR TYPES(R-PDSN) ADD
You then use the REBUILD command to implement the changes:
If CA ACF2 does not find a profile infostorage record for the data set, it processes the request as it did in previous CA ACF2 versions. If the data set is owned (that is, the data set's high-level qualifier matches the value specified in the prefix field of the requesting user's logonid), CA ACF2 returns the logonid of the requesting user to DFSMS as the RESOWNER. For data sets that are not owned by the requesting logonids, CA ACF2 searches the rule set matching the high-level qualifier for a value to return to DFSMS as the RESOWNER.
You can assign a RESOWNER by including a $RESOWNER control statement in the corresponding rule set. The $RESOWNER control statement specifies the logonid acting as the RESOWNER of the data set. For example, the following rule set indicates the PRODMGR logonid is the RESOWNER of the data set and that CA ACF2 validates PRODMGR's authority to use the STORCLAS and MGMTCLAS resource classes to allocate a PAY data set.
$KEY(pay) $RESOWNER(prodmgr) - UID(payroll) R(A) W(A)
The RESOWNER is only used to validate access to the STORCLAS and MGMTCLAS selected for the data set allocation. The logonid making the allocate request still needs the authority to actually allocate the data set.
If CA ACF2 does not find a $RESOWNER control statement, it checks the Logonid database to see if there is a logonid equal to the high-level index of the data set. If there is a logonid that matches, it is returned as the RESOWNER.
If there is no logonid that matches the high-level index, CA ACF2 defaults to using the logonid of the requesting user. To avoid the overhead of these additional checks, we recommend that you use DATASET profile records to specify the RESOWNER.
Specify Automatic Class Selection Defaults
SMS lets the RESOWNER supply default values for data, storage, and management classes. While this process is completely supported through CA ACF2 in the same manner as RACF, IBM does not recommend their use for most applications. The
Planning Guidestates, “We do not recommend the use of default classes in the user or group profile because it is highly unlikely that a given SMS class is applicable to all data sets a user creates. We suggest instead that you use ACS to determine the data, storage and management classes, as well as the application identifier attribute.”
The ACSDEFAULTS option in the IGDSMS
xxmember of SYS1.PARMLIB determines whether an external security product is used to store the default class values.
- If you do not want the ACS routines to use the default storage management data saved in the CA ACF2 CONTROL(SMS) infostorage record, set the ACSDEFAULTS option to NO. This prevents additional calls to CA ACF2 during allocation processing.
- If you do want the ACS routines to use the default storage management data saved in the CA ACF2 CONTROL(SMS) infostorage record, set the ACSDEFAULTS option to YES. The RESOWNER is determined as discussed earlier. The application identifier and default class information are extracted from a CA ACF2 infostorage record pointed to by the RESOWNER logonid.
An eight-byte logonid record field, SMSINFO, points to the CONTROL(SMS) infostorage record that contains the default data class name, management class name, storage class name, and application identifier. This information is passed back to SMS by CA ACF2. The values can be used by the ACS routines as part class determination or they can be overwritten by the ACS routines. The SMSINFO field can be specified for any logonid.
Use the following syntax to specify the SMSINFO field in the logonid record:
insert prodmgr smsinfo(defprod)
The logonid record that is used to point to the CONTROL(SMS) record when an allocation is requested.
The name of the infostorage record where the SMS default class attributes are stored. In this example, the record name is
The infostorage record that contains the ACS default values is a CONTROL(SMS) record.
Create Automatic Selection Defaults
If you are going to use default attributes for the application identifier, data class, storage class, and management class, you must define them in a CONTROL(SMS) record.
Defines the one- to eight-character name of the record that specifies the default values for the application identifier and the default data, storage, and management classes that will be passed to the ACS routines. For these defaults to apply to a RESOWNER, the name of the record ID must match the contents of the SMSINFO field for the RESOWNER's logonid.
A 32-character description. You might want to specify a description, such as: Provides defaults for sys progs.
An eight-character value for the application identifier.
An eight-character value for the data class.
An eight-character value for the management class.
An eight-character value for the storage class.
SYSID is not a valid operand for CONTROL(SMS) records.
The SHOW FIELDS subcommand of the ACF command displays the SMSINFO field of the logonid record. The SHOW APPLDEF subcommand displays how the site specifies the SMS record.
You can use the following ACF subcommands to create a CONTROL(SMS) record that specifies the defaults used for all production data set allocations:
set control(sms) CONTROL insert defprod dataappl(applprod) dataclas(dataprod) storclas(storprod) mgmtclas(mgmtprod) desc(defaults for production payroll)
When using set control(sms) to create the SMSINFO record, a REFRESH is not required. The records are picked up at the time of validation.
The previously created DEFPROD infostorage record contains the default values tested by the ACS routines. CA ACF2 locates the DEFPROD record by means of the record ID specified in the SMSINFO field of the logonid record.
Validate DFSMS SAF Calls
CA ACF2 processes DFSMS SAF calls by default. The SAF classes of STORCLAS, MGMTCLAS, and FACILITY are processed by CA ACF2 without the need for additional SAFDEF records. For a list of the CA ACF2-provided SAFDEF records, see IBM System Authorization Facility (SAF). This section describes the only required SAFDEF record for DFSMS support.
If you write resource rules to protect DFSMS programs, you must create a SAFDEF record as follows:
set control(gso) CONTROL insert safdef.pgm id(progmchk) mode(global) racroute(request=fastauth,reqstor=progmchk,subsys=contents) rep
This SAFDEF record instructs CA ACF2 to always validate a program load with the PROGRAM resource class.
Allprograms are protected, not just SMS programs.
Define the DFSMS Classes
The following table lists the CA ACF2 default type codes for the four DFSMS resource classes:
To view the list of internal and external SAF call definitions in effect on your system, issue the SHOW SAFDEF subcommand. To display the defined SAF classes, both internal and external, and the associated resource rule type codes, issue the SHOW CLASMAP subcommand.
To use a different resource type code for a resource class, insert a CLASMAP record. For example, to change the type code for resource class PROGRAM from PGM to PRO, insert the following CLASMAP record:
SET CONTROL(GSO) INSERT CLASMAP.pro RESOURCE(program) RSRCTYPE(pro) ENTITYLN(8)
Control DFSMS Functions and Commands
IBM defines the following resource names for each respective DFSMS function/command. A definition of each documented function is provided.
Provides the ability to activate a configuration.
Provides the ability to run IDCAMS DIAGNOSE against catalogs.
Provides the ability to run IDCAMS DIAGNOSE against VVDSs (VSAM Volume Data Sets) when a comparison against the BCS is being performed. This protects the BCS. It does not protect the ability to run AMS DIAGNOSE against the VVDS.
Provides the ability to alter BCS (VSAM Basic Catalog Structure) entries.
Provides the ability to use a directed catalog.
Provides the ability to define non-VSAM entries without BCS entries.
Provides the ability to define non-VSAM entries without NVR (non-VSAM Volume Record) entries.
Provides the ability to delete an NVR entry without checking the BCS entry.
Provides the ability to delete a BCS entry without deleting the associated VTOC entry and NVR.
Provides the ability to delete a GDG using the FORCE operand.
Allows the DFDSS COPY function to bypass the ACS routines and use the original (pre-DFSMS) constructs.
Allows the DFDSS RESTORE function to bypass the ACS routines and use the original (pre-DFSMS) constructs.
Provides the ability to use the INCAT parameter on a DFDSS COPY function.
Provides the ability to use the INCAT parameter on a DFDSS DUMP function.
Provides the ability to use the INCAT parameter on a DFDSS CONVERTV function.
Provides the ability to use the DFDSS CONVERTV function.
Secure SMS Functions and Commands
The FACILITY resource class is identified to CA ACF2 by the three-character type code FAC (unless you assigned a different type code in a GSO CLASMAP record). FACILITY authorizations can be shared or protected using a resource rule for each of the functions.
To simplify administration, we suggest that you initially write a rule to ALLOW and LOG all users use all functions and commands and refine the rule to meet your site's security requirements and standards. The following are sample rules:
RESOURCE ACF70010 ACF COMPILER ENTERED $key(STGADMIN*******************************) type(fac) uid(-) log
$key(STGADMIN) type(fac) - uid(*) log
In the first example, the $KEY is 39 characters long.
To protect specific commands or functions, you should write specific rules to permit users access to specific functions or commands. For example, to restrict the IGD.ACTIVATE.CONFIGURATION function to only operations staff, you might write the following rule:
set resource(fac) RESOURCE compile * store ACF70010 ACF COMPILER ENTERED $key(stgadmin.igd.activate.configuration) type(fac) uid(oper-) allow
All other users are prevented by default.
Or you could write a rule like the following:
set resource(fac) RESOURCE compile * store ACF70010 ACF COMPILER ENTERED $key(stgadmin) type(fac) igd.- uid(oper-) allow
The dash masking character is not supported for $KEY names in resource rules, although asterisks are. You must create a resource directory for type (FAC) records if you intend to use resource name masking. For more information about creating resource directories, Resource Rules.
Control DFSMS Programs
Access to ISMF functions is controlled by limiting access to the programs that perform those functions. The following are the program names and their DFP 3.0 ISMF functions. These program names are protected by writing resource rules.
DFSMS ISMF Programs
DFSMS ISMF ISMF Functions
Invokes ACS application
Invokes CDS application
Invokes SG application
DFSMS ISMF Programs
DFSMS ISMF ISMF Functions
STORCLAS Alter Dialog.
STORCLAS Display Dialog.
STORCLAS List Dialog.
STORCLAS List Display Line Operator.
STORCLAS List Alter Line Operator.
STORCLAS List Copy Line Operator.
DFSMS ISMF Programs
DFSMS ISMF ISMF Functions
DATACLAS Define Dialog.
DATACLAS Alter Dialog.
DATACLAS Display Dialog.
DATACLAS List Dialog.
DATACLAS List Display Line Operator.
DATACLAS List Alter Line Operator.
DATACLAS List Copy Line Operator.
DFSMS ISMF Programs
DFSMS ISMF ISMF Functions
MGMTCLAS Define Dialog.
MGMTCLAS Alter Dialog.
MGMTCLAS Display Dialog.
MGMTCLAS List Dialog.
MGMTCLAS List Display Line Operator.
MGMTCLAS List Alter Line Operator.
MGMTCLAS List Copy Line Operator.
DFSMS ISMF Programs
DFSMS ISMF ISMF Functions
Secure DFSMS Programs
PROGRAM authorizations are protected by using a resource rule for each of the programs. They can also be protected by supplying a program name mask and writing rules for all or some selected programs. You must create a resident resource rule with type (R-RPGM) in the GSO INFODIR record. First, write a rule to let all users load all programs, as shown in the following:
set resource(pgm) RESOURCE compile * store ACF70010 ACF COMPILER ENTERED $key(********) type(pgm) uid(-) allow
The entry for the $KEY is eight-characters long.
To secure specific programs, you can write rules to protect only those programs. For example, to restrict that program to only operations staff, you might write the following rule:
set resource(pgm) RESOURCE compile * store ACF70010 ACF COMPILER ENTERED $key(dgtfflad) type(pgm) uid(oper-) allow
All other users are prevented by default.
Although you cannot use the dash to mask program names, you can use asterisks. For example, all program names can be masked using the DGTF**** character string. The following rule let operations staff use all ISMF functions while denying access to all other users implicitly.
set resource(pgm) RESOURCE compile * store ACF70010 ACF COMPILER ENTERED $key(dgtf****) type(pgm) uid(oper-) allow
You must also create a SAFDEF record for programs.
The dash masking character is not supported for $KEY names in resource rules, although asterisks are. Due to the way CA ACF2 validates the program, you must create a resource directory for type PGM records and specify that the resource rules are resident. For example:
SET CONTROL(GSO) CHANGE INFODIR TYPES(R-RPGM)
For details on creating resource directories, see Resource Rules.
Secure DFSMS Storage and Management Classes
The STORCLAS and MGMTCLAS resource classes let you control a RESOWNER's access to specific storage classes and management classes, respectively. These storage and management classes are each identified by a unique one- to eight-byte resource name. This resource name lets you write resource rules to control access.
The following example shows the ACF subcommands used to let the production manager use a site-defined storage class of PRODSTOR and management class of PRODMGMT. CA ACF2 checks these rules when DFSMS requests whether the RESOWNER PRODMGR has access to PRODSTOR and PRODMGMT.
To let him use the storage class PRODSTOR, use the following commands:
set resource(str) RESOURCE compile * store ACF70010 ACF COMPILER ENTERED $key(prodstor) type(str) uid(prodmgr) allow
To let him use the PRODMGMT management class, use the following commands:
set resource(mgm) RESOURCE compile * store ACF70010 ACF COMPILER ENTERED $key(prodmgmt) type(mgm) uid(prodmgr) allow
Process Storage and Management Classes
When a user makes a request to allocate a data set, DFSMS makes a series of SAF calls to CA ACF2 to extract the information it needs to allocate the data set.
The first call is a request to extract the name of the RESOWNER of the data set. The next call is an optional request to extract the default data, storage, and management class names and the application identifier name. This call is performed only if the value for ACSDEFAULTS=YES in the IGDSMS
xxmember of SYS1.PARMLIB. The third call is a request to validate the RESOWNER's authority to use the STORCLAS and MGMTCLAS resource classes.
How CA ACF2 Obtains the RESOWNER
When SMS requests CA ACF2 to extract the RESOWNER, CA ACF2 does the following:
- If a matching DFP PROFILE record exists, CA ACF2 extracts the RESOWNER value from the selected DFP record. If no matching profile record exists, the process continues as follows.
- If the requesting user owns the data set, CA ACF2 uses that user's logonid as the RESOWNER. To determine that a user owns a data set, CA ACF2 checks the prefix field of the user's logonid to see if it matches the high-level qualifier (HLQ) of the data set.
- If the requesting user does not own the data set, CA ACF2 retrieves the data set access rule for the HLQ and checks for the $RESOWNER control statement. If the rule exists and the $RESOWNER control statement is present and nonblank, CA ACF2 uses that logonid as the RESOWNER.
- If no rule set exists or the $RESOWNER statement is blank, CA ACF2 uses the HLQ of the data set as the RESOWNER.
- If the RESOWNER was identified to SMS using Steps 3 or 4, CA ACF2 verifies that the logonid exists. If the logonid does not exist, CA ACF2 uses the logonid of the requesting user as the RESOWNER. If a logonid representing the RESOWNER does not exist, the allocation fails.
- After CA ACF2 determines the RESOWNER, it returns control to SMS.
How CA ACF2 Obtains the Default Classes
Next, SMS requests CA ACF2 to extract the default classes. CA ACF2 does the following to obtain the default values for the application identifier, data class, storage class, and management class:
- CA ACF2 locates the RESOWNER's logonid and uses its SMSINFO field to locate the infostorage record. CA ACF2 returns the default information specified in the record to SMS. If the SMSINFO field is blank or if no corresponding infostorage record is found, no default information is returned.
- After CA ACF2 returns the default information, it returns control to SMS.
How CA ACF2 Validates STORCLAS and MGMTCLAS Use
Next, SMS requests CA ACF2 to validate the RESOWNER's authority to use the STORCLAS and MGMTCLAS resources selected for this data set allocation. CA ACF2 locates the logonid of the RESOWNER and uses it to validate access to the storage class and/or the management class selected by SMS. The validation is based on the resource rules written to protect the STORCLAS and MGMTCLAS resource classes.
Prior to DFSMS, sites used operating system passwords to protect the master catalog from implicit and explicitupdates.to the master catalog are created through catalog processing when the high level index of the data set name does not have an associated alias directing it to a user catalog.to the master catalog are through direct catalog manipulation like IDCAMS ALTER. Since catalog password processing no longer takes place in a system managed storage (SMS) environment, this might or might not have an effect at an installation, depending on the implementation of CA ACF2. The most common problem is undesired updates to the master catalog.
Undesired implicit updates are avoided when CA ACF2 is active in abort mode. CA ACF2 does not permit an update to the catalog if the user is not allowed to create the high level qualifier of the data set name. For example, if a user inadvertently misspells a data set high level qualifier, CA ACF2 stops the allocation when no rule is found for that data set. No explicit rule, granting or denying access to the catalog is required. However, explicit catalog manipulation, like IDCAMS ALTER, requires write or allocate access to the catalog through CA ACF2 access rules.
Using SAF to Protect Catalogs
You can also use the catalog system authorization facility (SAF) calls to protect catalogs. When activated, these SAF calls validate user access to any master or user catalog regardless of whether the update is implicit or explicit.
You must also write rules giving users read and write access to the user-catalogs in which they are defined because SAF validates implicit updates to the catalog. This is necessary to let users allocate their own data sets. However, this additional authority can allow users catalog update capabilities that they would not have under the non-SAF scenario. Also, users that are allowed to allocate data sets that have their high level index defined in the master catalog need write access to the master catalog. SAF validation also requires that users allowed to directly manipulate a catalog using IDCAMS are allowed CA ACF2 allocate access. LISTCAT processing requires READ access to the catalog.
To activate SAF catalog protection, override default SAFDEF CATAUTH as follows:
CATAUTH JOBNAME=******** USERID=******** PROGRAM=******** RB=SVC026 RETCODE=4 SAFDEF=INTERNAL MODE=IGNORE SUBSYS=ACF FUNCRET=4 FUNCRSN=0 RACROUTE REQUEST=AUTH,CLASS='DATASET'
Example SAFDEF override:
INSERT SAFDEF.MASTCAT RB(SVC026),MODE(GLOBAL), RACROUTE(REQUEST=AUTH,CLASS=DATASET,ENTITY=MSTRCAT.-) REP
REP is required.
You should write rules before activating the SAFDEF. To protect master catalogs only, write a catchall allow rule for user catalogs or add ENTITY= to the RACROUTE parm of the override SAFDEF to make it apply only to your master catalogs. This assumes you have good maskable naming conventions. If the master catalogs do not have straight forward naming conventions, it is easier to leave the ENTITY parameter off the SAFDEF and write rules to distinguish between the catalogs. Masking in the SAFDEF entity parameter is limited. The dash (-) can be used at the end of the mask only, and asterisks (*) are treated as place holders. For example, m**5****, can match only an eight-character name. If ENTITY is omitted from the SAFDEF, then rules are needed for both master catalogs and user catalogs.
CA-ACF2 VSAM processing for catalogs does not use the VOLUME passed in the SVC026 SAF call if DSTYPE=V. CA-ACF2 does not use the volser passed because it is always the volser of the catalog during DSTYPE=V processing, there is no distinction between a catalog open, or a dataset open. For a dataset open, the volser would be incorrect. Therefore, for DSTYPE=V processing, CA-ACF2 always blanks out the volser for validation.
The following case is intended to serve as an example of how CA ACF2 DFSMS support can be implemented at your site. Conditions at your site might differ from those presented in this example.
Company ABC knows it needs to perform the following steps to implement CA ACF2 SMS support for the production data sets at their site:
- Analyze rule sets.
- Create new logonids to be used as $RESOWNERs.
- Create CONTROL(SMS) records (only if you ignore the information in Automatic Class Selection Defaults).
- Compile resource rules to protect the classes.
- Create DFP PROFILE records, or add $RESOWNER control statements to rule sets. (This step should be performed last and only if needed.)
The first step the security administrator might take is to analyze all production data sets. Company ABC has two types of production data sets: payroll and accounts payable. Their high-level qualifiers begin with the values PAY and ACP.
The rule sets for these data sets are displayed in the following:
$KEY(paymon) - UID(***paymgr) A(L) W(A) R(A) $KEY(payweek) - UID(***paymgr) A (L) W(A) R(A) $KEY(acpmon) - UID(***prodacp) A(L) W(A) R(A) $KEY(acpweek) - UID(***prodacp) A(L) W(A) R(A)
The storage administrator wants to use PRODMGR as the RESOWNER for all these data sets. He uses both methods previously described to accomplish this.
First, he uses a $RESOWNER control statement for his payroll rule sets:
$KEY(paymon) $RESOWNER(prodmgr) - UID(***paymgr) A(L) W(A) R(A) $KEY(payweek) $RESOWNER(prodmgr) - UID(***paymgr) A(L) W(A) R(A)
To define the RESOWNER for his accounts payable data sets, he creates DFP profile records:
SET PROFILE(DATASET) DIVISION(PROFILE) COMPILE $KEY(acp*****) - DFP(acpowner) SET PROFILE(DATASET) DIVISION(DFP) INSERT acpowner RESOWNER(PRODMGR)
Since he is using masking in the $KEY to represent all accounts payable data sets, he must define resident directories and records:
SET CONTROL(GSO) CHANGE INFODIR TYPES(R-PDSN) ADD
He must then use the following command to rebuild the directories:
To enable CA ACF2 to return the default classes to SMS if default classes are used, the PRODMGR logonid record must point to an SMS record in the Infostorage database where the default values for the application identifier, data class, storage class, and management class are kept. This SMS record is named DEFPROD.
change prodmgr smsinfo(defprod)
He also can write the CONTROL(SMS) record to define the default classes. Notice that the record ID, DEFPROD, is the same name he specified in the SMSINFO field of the PRODMGR logonid record.
set control(sms) CONTROL insert defprod dataclas(dataprod) storclas(storprod) mgmtclas(mgmtprod) dataappl(applprod)
Next the security administrator compiles the following resource rules to protect the MGMTCLAS and STORCLAS used to allocate all production data sets:
$KEY(storprod) TYPE(STR) UID(***prodmgr) ALLOW $KEY(mgmtprod) TYPE(MGM) UID(***prod) ALLOW
The names of the STORCLAS and MGMTCLAS to protect are STORPROD and MGMTPROD. The logonid PRODMGR can allocate production data sets using these classes. FACILITY and PROGRAM resource protection are implemented as described earlier.
Now that the security administrator has finished implementing CA ACF2 SMS support, what happens when PAYMGR tries to allocate the data set PAYMON.JULY.2002? Here is the access rule:
$KEY(paymon) $RESOWNER(prodmgr) - UID(***paymgr) A(L) R(A) W(A)
Here are the steps SMS and CA ACF2 follow to determine if PAYMGR can perform the allocation:
- SMS extracts the RESOWNER.
- CA ACF2 cannot find a matching DFP PROFILE record for the data set.
- CA ACF2 sees that PAYMGR does not own the high-level qualifier of the data set, PAYMON, so CA ACF2 reads in the rule set.
- CA ACF2 searches for the $RESOWNER control statement. It finds the $RESOWNER, reads in the PRODMGR logonid record, and returns PRODMGR to SMS as the RESOWNER.
- If the site has specified ACSDEFAULTS=YES in the IGDSMSxxmember of SYS1.PARMLIB, SMS tries to extract the default values for the application identifier, data class, storage class, and management class for use by the ACS routines.
- CA ACF2 locates the CONTROL(SMS) infostorage record, DEFPROD, specified in the PRODMGR logonid and returns the default values to SMS.
- Assuming the ACS routines use the defaults passed to them, SMS requests whether the RESOWNER, PRODMGR, is authorized to use STORCLAS's STORPROD and MGMTCLAS's MGMTPROD resources.
- CA ACF2 validates the resource rules for STORPROD and MGMTPROD and sees that the RESOWNER, PRODMGR, is authorized to use those resource classes. It returns that information to SMS.
- Before the allocation takes place, however, standard CA ACF2 validation is performed on the PAYMON data set. CA ACF2 checks to see whether PAYMGR can allocate a PAYMON data set. He can, but the rule instructs CA ACF2 to log the allocation.
- Now SMS can perform the allocation.
When PAYMGR allocates the ACPWEEK.WEEK3.DATA data set, CA ACF2 finds the RESOWNER in the DFP PROFILE record as in 1.a. and bypasses 1.b. and 1.c. The subsequent steps are the same.
Process DFSMS Using the ACF Command
Once within the ACF command, use the SET command to enter profile administration. Enter:
SET PROFILE(USER) DIVISION(PROFILE|profile-data-name)
Where PROFILE can be one of the following: USER, GROUP, DATASET, SDB2, SECLABEL, KEYSMSTR, DLFCLASS, APPCLU, PTKTDATA, or SYSMVIEW. DIVISION can be PROFILE, which indicates a compiled record, or the profile data name of the data record. Remember that compiled records point to the profile data records.
Define a USER profile record as follows:
SET PROFILE(USER) DIVISION(WORKATTR) INSERT userid WANAME(username)
Define a DATASET profile record as follows:
SET PROFILE(DATASET) DIVISION(PROFILE) COMPILE * $KEY(hlq) data.set.name DFP(ownrname) STORE SET PROFILE(DATASET) DIVISION(DFP) INSERT ownrname RESOWNER(resowner)
Use the following commands for all user profile records:
LIST *|recid|LIKE(recidmask) DELETE *|recid|LIKE(recidmask)
Profile data records use the following commands:
INSERT *|recid|USING(urecid) recid CHANGE recid|LIKE(urecid)
Compiled records use the COMPILE command. The keys of both the compiled records and the profile data records can be masked when these records are defined in the CA ACF2 GSO INFODIR record. The infostorage class for profile records is PROFILE; the letter representing the class is P. CA ACF2 distributes the following CLASMAP resource type definitions with the product; adjustments might be needed if your site uses different types for these resources.
All profiles should be defined as resident in the GSO INFODIR record. To accomplish this, issue the following subcommands:
SET Control(GSO) CONTROL CHANGE INFODIR TYPES(R-PDLF,R-RDLF,R-PDSN,R-PALU,R-PPTK,R-RSMV,R-PSEC,R-PSDB)
R-PKEY, P-PUSR and P-PGRP are not required to be defined as resident; its use is optional, however Profile user records are recommended to be resident in storage for performance reasons.
This example assumes you are using the types distributed with CA ACF2; if you are using different types, make the appropriate adjustments. These directories do not appear when you issue a SHOW RESIDENT until they have been added to the GSO INFODIR record and that record has been refreshed.
When records are resident in storage, changes are made effective immediately by issuing a console rebuild command. For example:
Using the RECKEY Subcommand
The RECKEY subcommand assists security administrators in maintaining rule sets and compiled infostorage rule records. This subcommand allows the user to decompile, add or delete a rule entry, recompile, and store the updated rule set on one command. This command can be used in any ACF mode that handles compiled records and it executes on other CPF-defined nodes. For more information on the RECKEY subcommand, see Profile Records.
Process DFSMS Using the ISPF Panels
ISPF panels allow you to perform TSO ACF commands using a menu driven interface. For help while using the ISPF panels, select PF1.
To create an SMS record
- Select option 1 INSERT from the CA ACF2 DFSMS Support ServicesThe Insert an SMS Record panel displays.
- Specify the record ID for the record you are creating and select Enter.The next Insert an SMS Record panel displays.
- Type the appropriate values for the fields on this panel, and select Enter.
To change an SMS record
- Select option 2 CHANGE from the CA ACF2 DFSMS Support ServicesThe Change a SMS Record panel displays.
- Specify the record ID for the record you want to modify, select Enter.The next Change an SMS Record panel displays.
- Type the appropriate values for the fields on this panel and select Enter.
To display an SMS record
- Select option 3 LIST from the CA ACF2 DFSMS Support ServicesThe List an SMS Record panel displays.
- Specify the record ID for the record you want to display and select Enter.
To delete an SMS records
- Select option 4 DELETE from the CA ACF2 DFSMS Support ServicesThe Delete an SMS Record panel displays.
- Specify the record ID for the record you want to delete and select Enter.