Control-M Security

This chapter describes the procedure used to implement the Control‑M security interface. Review the explanations below about the elements that are protected in Control‑M and then proceed to the step-by-step instructions.

Protecting Control-M Elements

The Control‑M security interface protects the following Control‑M elements:

• Job ordering.

• Access to JCL libraries.

• Job submission.

• Access to and use of the Job Status screen (Screen 3).

• Ordering of Control-M Event Manager (CMEM) rules, and use of DO commands and ON blocks.

To control user authorizations to each Control‑M protected element, choose either the Basic Definition mode or the Extended Definition mode. For more information on Basic and Extended Definition modes, see 1 IOA Security.

Job Ordering

Each Control‑M job definition contains an OWNER parameter. This parameter, which must be defined as a valid security product user ID, specifies the user ID to which the definition belongs. When ordering a job, the user must have the authorization to access the owner specified in the job definition. The CTMSE01 Control‑M security module verifies that the user who orders a job is authorized to do so, using the owner parameter of the job. If the user who orders a job is the owner specified in the job definition, no security checks are performed.

Access to JCL Libraries

Before Control‑M submits a job, the CTMSE02 security module verifies the job definition owner’s authority to read the JCL library that is specified in the job definition.

In addition, during OPEN processing, the operating system data management routines check whether or not the user ID of the address space is authorized to read the JCL library. BMC therefore recommends adding the RACF OPERATIONS attribute (or equivalent, for other security products) to the Control-M monitor user ID to reduce security checking overhead.

Job Submission

When Control‑M submits a job, the CTMSE02 Control‑M security module performs a check to verify that the job is submitted with a valid USER parameter in the job statement or a valid //*JOBFROM statement for ACF2/SAF.

If the job statement does not contain a USER parameter or a valid //*JOBFROM statement for ACF2/SAF, the USER parameter (set to the value owner), or a valid //*JOBFROM statement for ACF2/SAF, is added to the job statement, if required.

If the job statement contains a USER parameter or a valid //*JOBFROM statement for ACF2/SAF, the CTMSE02 Control‑M security module either allows or fails the submission of a job, depending on implementation options and the owner authority of the user ID defined for the user who submitted the job specified in the JCL.

In addition, the CTMSE02 security module determines whether the user ID assigned to the Control‑M monitor is authorized to submit jobs on behalf of the user ID assigned to the submitted job. If it is not authorized, the submission fails.

For more information, see the description of the CTMSE02 security module, in Module CTMSE02.

Workload Policy Management Security

To manage Workload Policies through the Workload Management Facility in Control-M, users must be authorized for the appropriate entity. The following table describes the Control-M Workload Policy Management security calls:

Table 28a Control-M Workload Policy Management Security Calls

For more information about these protected elements, see Managing workload using Workload Policies in the Control-M for z/OS User Guide.

Load-Index Management Security

To manage Load-Indexes, which can be used in Workload Policies, through the Workload Management Facility in Control-M, users must be authorized for the appropriate entity. The following table describes the Control-M Load-Index Management security calls:

Table 28b Control-M Load-Index Management Security Calls

For more information about these protected elements, see Using Load Indexes in workload optimization in the Control-M for z/OS User Guide.

Access to and Use of the Status Screen

The Status screen (screen 3) lists the active jobs currently handled by Control‑M and their status. The user can issue inquiries about a job within the list or change a job’s status. The CTMSE08 Control‑M security module verifies the user’s authorization to enter Screen 3 and perform actions (for example, hold, delete) on jobs displayed in the Status screen.

For more information, see Control‑M Basic Definition Security Calls , Control‑M Extended Definition Security Calls , and Control-M Security Modules.

Control-M Basic Definition Security Calls

Table 29 Control‑M Basic Definition Security Calls

Control-M Extended Definition Security Calls

Table 30 Control‑M Extended Definition Security Calls

Implementing Control-M Security

This section describes the steps required to implement the Control‑M security interface.

The Control-M security interface can be installed either as part of the customized installation path, or during the Customization process after installation. Both options use the INCONTROL Installation and Customization Engine (ICE) application. If you are not familiar with the ICE interface, see the INCONTROL for z/OS Installation Guide: Installing. Perform all the steps required to implement Control-M security at your site.

If CMEM is installed at your site, perform all the steps required to implement CMEM security at your site.

To install the Control-M security interface

1. Enter the main ICE screen.

2. Select Customization.

3. Enter CTM in the Product field.

4. Select Security Customization.

5. Perform all major and minor steps required to install the security product.

Step 1. Implement Control-M Security

Use the following steps that correspond to the installation steps in ICE, to implement Control‑M security.

Step 1.1 Grant Access Permissions

Collect the required data to define the INCONTROL entities and user authorizations to the security product.

You can use this data in the sample jobs provided in subsequent steps "Control‑M Security Definitions (Sample)" and "Functions Security Definitions (Sample)".

Select the appropriate step to create the sample job by ICE. After the job is created, enter your definitions and save them in the INSTWORK library.

Step 1.2 Customize Security Parameters

Use ICE to define the following parameters:

Table 31 Parameter Definitions

Table 32 Job Card Parameters

Table 33 Mode Definition

Step 1.3 Save Security Parameters into Product

This step saves all the security parameters specified for Control‑M. When completed, the Status column is automatically updated to COMPLETE.

Step 2. RACF Security Definition Samples

Step 2.1 Control-M Security Definitions

Select this step to edit the CTMSRAC2 member in the IOA INSTWORK library.

Perform the following steps to define the required users permissions:

1. To define the entity $$CTMEDM.qname to RACF, use the following RACF command:

   RDEFINE FACILITY $$CTMEDM.qname UACC(NONE)

2. To associate USERA with Extended Definition mode, use the following RACF command:

   PERMIT $$CTMEDM.qname ID(USERA) CLASS(FACILITY) ACCESS(READ)

   If the definition mode to a Control-M security module was defined as conditional mode (COND), and a user does not have access to this entity, the user is set to work in Basic Definition mode. Otherwise, the user is set to work in Extended Definition mode.

3. Submit the job for execution.

   This job must be run under a user who has authorization to enter these RACF commands.

4. Scan the output of the job for information and error messages produced by RACF.

Step 2.2 Function Security Definitions (Optional)

Select this step to edit the CTMSRAC3 member in the IOA INSTWORK library. This member contains a sample of the various definitions required to define access authorizations to various Control‑M entities. Review the definitions and modify to meet your site's requirements.

Step 2.3 Control Program Access to Datasets (Optional)

BMC recommends that, before selecting this step, the security administrator first read Limiting Access to Specific Programs and the IBM Resource Access Control Facility Security Administrator's Guide.

Select this step to edit the CTMSRAC4 member in the IOA INSTWORK library. This member contains a sample of the definitions required to define Program Pathing access authorizations to Control‑M datasets. Review the definitions and modify to meet your site's requirements.

Step 3. TopSecret Security Definition Samples

Step 3.1 Control-M Security Definitions

Select this step to edit the CTMSTSS2 member in the IOA INSTWORK library.

Perform the following steps to define the required permissions:

1. Define Control-M in the TopSecret Facility Matrix.

   1. Modify USER2 in the Facility definition command to a free entry in the Facility Matrix, as follows:

      Copy

      TSS MODIFY FAC(USER2=NAME=CTM)

      This command defines Control-M in the Facility Matrix until the next IPL

   2. Update the TopSecret parameter member (usually called TSSPARM0) to permanently define Control-M.

2. Define Control-M ACID in TopSecret.

   Change the DEPT parameter value from sec-administrator-dept to the appropriate ACID:

   Copy

   TSS CRE(CONTROLM) NAME (...) DEPT(sec-administrator-dept)

3. Define Control-M started tasks in TopSecret

   Change the ACID definition in the following commands to the appropriate ACID:

   Copy

   TSS ADD(STC) PROC(CONTROLM) ACID(CONTROLM)
   TSS ADD(STC) PROC(CONTDAY) ACID(CONTROLM)

4. Allow Control-M ACID to access Control-M datasets.

   Optionally, you can define authorizations to access Control-M datasets during Control-M installation. Complete this step before proceeding with security implementation. For information about how to grant users access to Control-M datasets, see the IOA Installation chapter in the INCONTROL for z/OS Installation Guide: Installing.

   Connect the appropriate profile to the Control-M ACID in the following command:

   Copy

   TSS ADD(CONTROLM) PROF (profile-name)

   Allow READ access authorization to any Control-M JCL libraries used to submit jobs.

5. Authorize Control-M ACID to submit jobs for other users, with the following command:

   Copy

   TSS ADD(CONTROLM) NOSUBCHK

6. Define Control-M entities and user authorizations to TopSecret.

   For information about how to define Control-M entities and user authorizations to TopSecret, see Control-M Basic Definition Security Calls, and Control-M Extended Definition Security Calls.

   Modify the following command to establish ownership of the resources in TopSecret to the appropriate owner:

   Copy

   TSS ADD(sec-administrator-dept) IBMFAC($$CTM)

   For samples of user authorizations, see member CTMSTSS3 in the IOA INSTWORK library

   Entity names for Control‑M protected elements appear in Control-M Basic Definition Security Calls for Basic Definition mode and in Control-M Extended Definition Security Calls for Extended Definition mode

7. Associate users with Extended Definition modes.

   1. Modify the following TopSecret command to establish Extended Definition mode for the Control-M installer.

      Copy

      TSS PERMIT (USERA) IBMFAC($$CTMEDM.qname) ACC(READ)

   2. Change USERA to the UID of Control-M installer.

   A user with access to this entity is set to work in Extended Definition mode. The user without access is set to work in Basic Definition mode.

   If the definition mode to a Control‑M security module was defined as COND, and does not have access to this entity, the user is set to work in Basic Definition mode. Otherwise, the user is set to work in Extended Definition mode.

8. Authorize the Control-M installer to use Control-M facilities.

   1. Customize the following command to authorize USERA access to Control-M:

      Copy

      TSS ADD(USERA) IBMFAC($$CTM)

   2. Change USERA to the user ID of the Control-M installer.

   3. Customize the following command to authorize the Control-M installer to use Control-M facilities:

      Copy

      TSS PERMIT(USERA) IBMFAC($$CTM) ACC(READ)

9. Submit the job.

   Run this job under the ACID of the general security administrator (SCA) who has authorization to enter TopSecret commands.

Step 3.2 Function Security Definitions (Optional)

The IOASRAC3 job in the IOA INSTWORK library is optional. It contains some definition samples for various entities. Customize this job according to your requirements and submit the job.

Define entities and user authorizations.

For information about defining IOA entities and user authorizations, see Control-M Basic Definition Security Calls, and Control-M Extended Definition Security Calls.

RDEFINE FACILITY $$IOAONLINE.qname

RDEFINE FACILITY $$IOARES.qname.SYS*
PERMIT $$IOARES.qname.SYS* CLASS(FACILITY) ID(USERA) ACCESS(READ)

PERMIT $$IOAnnn.qname CLASS(FACILITY) ID(USERA) ACCESS(READ)

Step 3.3 Control Program Access to Datasets (Optional)

BMC recommends that, before selecting this step, the security administrator first read Limiting Access to Specific Programs and the IBM Resource Access Control Facility Security Administrator's Guide.

Select this step to edit the CTMSTSS4 member in the IOA INSTWORK library. This member contains a sample of the definitions required to define Program Pathing access authorizations to Control‑M datasets. Review the definitions and modify to meet your site's requirements.

Step 3.4 Define CTM to TopSecret Facility Matrix (Optional)

Select this step to edit the CTMSTSS5 member in the IOA INSTWORK library.

Perform the following steps to define Control‑M in the TopSecret Facility Matrix:

1. Modify USER2 in the Facility definition command to a free entry in the Facility Matrix, with the following command:

   Copy

   TSS MODIFY FAC(USER2=NAME=CTM)

2. Copy modified member CTMSTSS5 into TSSPARM0.

Step 4. ACF2 Security Definition Samples

Step 4.1 Control-M Security Definitions

Select this step to edit the CTMSSAF2 member in the IOA INSTWORK library.

1. Associating users with Extended Definition mode.

   Add the following ACF2 commands to define the $$CTMEDM.qname entity to ACF2/SAF and authorize users to this entity:

   Copy

   SET RESOURCE(CMF)
   COMP
   $KEY($$CTMEDM.qname) TYPE(CMF)
   UID(USERA) ALLOW

   If the definition mode to a Control-M security module was defined as COND, and does not have access to this entity, the user is set to work in Basic Definition mode. Otherwise, the user is set to work in Extended Definition mode.

2. Define entities and user authorizations to CA-ACF2/SAF.

   For more information about entities and user authorizations, see Control-M Basic Definition Security Calls and Control-M Extended Definition Security Calls.

   To define and authorize the resource profile in Basic Definition mode to protect ordering of STCs beginning with SYS, specify the following command:

   Copy

   SET RESOURCE(CMF)
   COMP
   $KEY($$CTMSTC.qname.SYS**************************)
    UID(USERA) ALLOW

   where qname is the name used to assign different authorizations to different IOA environments (such as Test and Production). This parameter is specified during IOA installation.

   To authorize USERA access to a given Control‑M entity, use the following command:

   Copy

   SET RESOURCE(CMF)
   COMP
   $KEY($$CTMnnn.qname)
    UID(USERA) ALLOW

   where CTMnnn is the entity name of the Control-M protected element described in Control-M Basic Definition Security Calls for Basic Definition mode and in Control-M Extended Definition Security Calls for Extended Definition mode.

   For samples of user authorizations, review member CTMSSAF3 in the IOA INSTWORK library.

3. Submit the job.

   Run this job with a user who has authorization to enter these ACF2 commands.

   Scan the job output for information and error messages produced by ACF2.

4. Rebuild resource type CMF rules.

   Rebuild the resource type CMF rules by issuing the following MVS command:

   Copy

   F ACF2,REBUILD(CMF)

Step 4.2 Function Security Definitions (Optional)

The IOASTSS3 job in the IOA INSTWORK library is optional. It contains some definition samples for various entities. Customize this job according to your requirements and submit this job.

Step 4.3 Control Program Access to Datasets (Optional)

BMC recommends that, before selecting this step, the security administrator first read Limiting Access to Specific Programs and the IBM Resource Access Control Facility Security Administrator's Guide.

Select this step to edit the CTMSSAF4 member in the IOA INSTWORK library. This member contains a sample of the definitions required to define Program Pathing access authorizations to Control‑M datasets. Review the definitions and modify to meet your site's requirements.

Control-M Event Manager Security

The Control‑O security interface protects the following Control‑M Event Manager (CMEM) elements:

• The CTOSE01 security module protects CMEM rule ordering.

• The CTOSE02 security module protects the use of DO statements and ON blocks that access or modify restricted IOA prerequisite conditions.

When Control‑O is installed, the Control‑O monitor assumes that a CMEM monitor is functional. Control‑O security modules provide a migration path from a CMEM monitor to a Control‑O monitor to implement CMEM security.

If Control‑O security is already implemented or is going to be implemented, do not implement CMEM security.

Rule Ordering

Each CMEM rule is defined with an owner, which is the name of a user ID to which this rule belongs. To order a rule, the user must have the authorization to access the owner of the rule. The CTOSE01 security module verifies that the current user has the authorization to order the rule, using the OWNER field of the rule.

The CMEM default rules in the IOACMEMR table are provided with the OWNER user ID of IOADMIN.

You must grant the user who orders these rules (either CTMCMEM or CONTROLO) permission to load the rules on behalf of the IOADMIN user ID, and grant the IOADMIN user permissions to the perform ON and DO statements in these rules.

Authority to Use Rule Functions (DO Statements and ON Statements)

CMEM rules react to events defined in the ON statements of the rule and actions defined in the DO statement of the rule. The security interface verifies if these actions are permitted to the owner of the rule. Before the rule is loaded, the CTOSE02 security module performs an authority check for each rule statement. If one of the authority checks fails, the entire rule load is canceled.

CMEM Basic Definition Security Calls

Table 34 CMEM Basic Definition Security Calls

CMEM Extended Definition Security Calls

Table 35 CMEM Extended Definition Security Calls

Implementing CMEM Security

CMEM security implementation is an optional step performed during Control‑M security implementation.

If CMEM is installed, you must implement CMEM security after completing the Control‑M security implementation steps.

This section details the steps required to implement the CMEM security interface using the ICE application. If you are not familiar with the ICE interface, see the ICE chapter in the INCONTROL for z/OS Installation Guide: Installing.

CMEM security implementation consists of the following ICE steps:

Step 5. Implement CMEM Security (Optional)

Perform the following steps to implement CMEM security.

Step 5.1 Grant Access Permissions

Collect the data you need to define the INCONTROL entities and user authorizations in the security product.

RACF Security

1. Add the following commands to define the $$CTOEDM entity to RACF, and authorize users to this entity.

2. To define the entity $$CTOEDM.qname, use the following command:

   Copy

   RDEFINE FACILITY $$CTOEDM.qname UACC(NONE)

3. To authorize USERA to Extended Definition mode, use the following command:

   Copy

   PERMIT $$CTOEDM.qname ID(USERA) CLASS(FACILITY) ACCESS(READ)

   Basic Definition mode is set if the user does not have access to this entity. If the user does have access to this entity, Extended Definition mode is set.

TopSecret Security

1. Define ControlO entities and user authorizations to TopSecret

   For information about how to define ControlO entities and user authorizations to TopSecret, see CMEM Basic Definition Security Calls, and CMEM Extended Definition Security Calls.

   Modify the following command to establish ownership of the resources in TopSecret to the appropriate owner:

   Copy

   TSS ADD(sec-administrator-dept) IBMFAC($$CTO)

   All entity names for each ControlO protected element appear in CMEM Basic Definition Security Calls for Basic Definition mode and CMEM Extended Definition Security Calls for Extended Definition mode.

2. Associate users with definition modes

   1. Customize the following TopSecret command to establish Extended Definition mode for the ControlO installer.

      Copy

      TSS PERMIT(USERA) IBMFAC($$CTOEDM.qname) ACC(NONE)

   2. Modify USERA to the UID of ControlO installer.

      If the user does not have access to this entity, the user is set to work in Basic Definition mode. Otherwise, the user is set to work in Extended Definition mode.

3. Authorize the ControlO installer to use ControlO facilities

   1. Customize the following command to authorize USERA access to ControlO:

      Copy

      TSS ADD(USERA) IBMFAC($$CTO)

   2. Modify USERA to the user ID of the ControlO installer.

   3. Customize the following command to authorize the ControlO installer to use ControlO facilities:

      Copy

      TSS PERMIT(USERA) IBMFAC($$CTO) ACC(READ)

ACF2/SAF Security

To associate users with Extended Definition Mode, define and authorize the entity $$CTOEDM.qname to ACF2 using the following command:

SET RESOURCE(CMF)
COMP
$KEY($$CTOEDM.qname)
 UID(USERA) ALLOW

Step 5.2 Customize Security Parameters

Table 36 Security Definition Modes

Step 5.3 Save Security Parameters into the Product

This step saves all the security parameters specified for CMEM. When this step is completed, the Status column is automatically updated to COMPLETE.

Control-M Security Modules

This section describes the Control‑M security modules in detail.

Module CTMSE01

The CTMSE01 module is the security module of Control‑M user Exit CTMX001. It verifies that the user is authorized to order a job. A check is performed to verify if the logged on user is authorized to order jobs on behalf of the user ID as specified in the owner field of the job definition.

Basic Definition Mode

Basic Definition mode authorizes the user access to an INCONTROL protected element. A user who is granted permission to an element is authorized to perform all the actions that are valid for this element (such as add, delete, change and update). The advantage of working in this mode is that it merges several different security events into a logically grouped resource structure. This structure simplifies the administration required to implement INCONTROL security.

Extended Definition Mode

Extended Definition mode grants each user access for a specific action within each INCONTROL protected element. Therefore, a user who is granted access to an INCONTROL element can be granted or denied any action (add, delete, change and update) within that element. This definition mode requires you to define several access rules. For each action there is an associated resource structure. However, Extended Definition mode provides maximum flexibility and accuracy for granting authorizations.

Module CTMSE02

The CTMSE02 module is the security module of Exit CTMX002. It verifies that the owner of a job is allowed to read the JCL library specified in the job definition, and enforces the USER parameter to match the specification made on the job order.

To reduce the amount of resources required for verifying the owner against the security system, the CTMSE02 module can use the internal cache for keeping results of the security requests. These results are refreshed according to the time specified by the LIFETIME parameter. Verification against the security system is performed only for those requests that are not found in cache or if the information in cache has expired. The entire cache is refreshed after NEWDAY process and according to the modify command for refreshing Control-M parameters.

Basic Definition Mode

When Control‑M submits a job, the following checks are made:

1. The user ID specified in the owner field of the job definition is authorized to read the JCL library. The CLASS checked is DATASET; the entity checked is the JCL library name. To allow a user to access a JCL library, use one of the following commands, as appropriate:

   For RACF:

   Copy

   PERMIT jcllibraryname ACC(READ) ID(USERA)

   For TSS:

   Copy

   TSS PERMIT (USERA) DSN(jcl-library-name) ACC(READ)

   For ACF2/SAF:

   Copy

   COMP
   $KEY(jcl-library-name)
   UID(USERA) ALLOW

2. If the job statement does not contain parameter USER (or the JCL does not contain a //*JOBFROM statement when ACF2/SAF is in use), parameter USER is added to the job statement and set to owner.

   For RACF, parameter GROUP can optionally be added to the job statement and set to the RACF default group.

   If the USER parameter exists in the JCL job statement, and the user ID or //*JOBFROM value (for ACF2 users) specified is not same as the owner of the job definition, and the MSUBCHK parameter is set to N (No), the job submission is canceled.

   If the USER parameter exists, the user ID specified is not the same as the owner, and parameter MSUBCHK is set to Y (Yes), the class checked is
   [SURROGAT | ACIDCHK | CMF] and the entity checked is
   [cl-userid.SUBMIT | the JCL user ID | $SUBMIT.cl-userid].

   userid is the user ID assigned to the job being submitted.

   For started tasks, no security checks are performed, because no distinction is made between the authority to start a started task and the authority to order a started task. The user’s authority is already verified by the CTMSE01 module.

Extended Definition Mode

When Control‑M submits a job the following checks are made:

1. The user ID specified in the owner field of the job definition is authorized to read the JCL library. The CLASS checked is DATASET; the entity checked is the JCL library name. To allow a user to access a JCL library, use one of the following commands, as appropriate:

   For RACF:

   Copy

   PERMIT jcllibraryname ACC(READ) ID(USERA)

   For TSS:

   Copy

   TSS PERMIT (USERA) DSN(jcl-library-name) ACC(READ)

   For ACF2/SAF:

   Copy

   COMP
   $KEY(jcl-library-name)
   UID(USERA) ALLOW

2. If the job statement does not contain parameter USER, or the JCL does not contain a //*JOBFROM statement when ACF2/SAF is in use, parameter USER is added to the job statement and set to owner.

   For RACF security, parameter GROUP is optionally added to the job statement and set to the RACF default group.

   If the USER parameter exists, the user ID or //*JOBFROM value (for ACF2 users) specified is not the same as the owner of the job definition, and parameter MSUBCHK is set to N (No), the job submission is cancelled.

   If the USER parameter exists, the user ID specified is not the same as the owner, and parameter MSUBCHK is set to Y (Yes), the class checked is
   [SURROGAT | ACIDCHK | CMF] and the entity checked is
   cl-userid.SUBMIT | the JCL user ID | $SUBMIT.cl-userid].

   userid is the user ID assigned to the job being submitted.

   For a started task, the CLASS checked is FACILITY. The entity checked is $$STRSTC.qname.stcname

3. To permit USERA to start a started task named SYSMON, use the following command:

   For RACF:

   Copy

   PERMIT $$STRSTC.qname.SYSMON ACCESS(READ) ID(USERA) CLASS(FACILITY)

   For TopSecret:

   Copy

   TSS PERMIT(USERA) IBMFAC($$STRSTC.qname.SYSMON) ACC(READ)

   For ACF2/SAF:

   Copy

   SET RESOURCE(CMF)
   COMP
   $KEY($$STRSTC.qname.STC1) TYPE(CMF)
    UID(USERA) ALLOW

Module CTMSE08

The CTMSE08 Control‑M security module verifies that the user is authorized to perform actions (for example, hold, delete, rerun) on jobs displayed in the Active Environment screen (Screen 3).

Basic Definition Mode

1. Initial access to Screen 3

   Perform a check to determine if the user is authorized to access Screen 3. The CLASS checked is FACILITY. The entity checked is $$CTMPNL3.qname

2. Refresh commands in the Job Dependency Network screen (Screen 3.N).

   The following entities are checked to verify user authorization for the various REFRESH command options in the Control-M Job Dependency Network screen.

   Table 37 Refresh Commands

   Command	Entity
   REFRESH NET	$$REFNET.qname
   REFRESH PROPAGATE	$$REFPROP.qname
   REFRESH DEADLINE	$$REFDEAD.qname
   REFRESH ALL	$$REFALL.qname
   AUTO	$$CTMAUTO.qname

   For more information about command REFRESH, see the Online Facilities chapter in the Control-M for z/OS User Guide.

3. Subsequent operations in Screen 3

   For all actions (hold, rerun, delete, and so on) that are performed on this screen, an authorization check is made.

   The check verifies that the authority of the current user to submit jobs with a USER parameter is equal to that of the specific job being submitted. A user who is authorized to submit a job on behalf of others is also authorized to perform the specific action (hold, rerun, delete, and so on) on jobs belonging to other users.

RACF Security

The CLASS checked is SURROGAT. The entity checked is owner.SUBMIT.

TopSecret Security

The TopSecret Application Interface module (TSSAI) is called with the following parameters:

• Resource Class: ACIDCHK

• Resource Name: owner

ACF2/SAF Security

The CLASS checked is FACILITY. The entity checked is $SUBMIT.owner.

Extended Definition Mode

1. Initial Access to Screen 3

   Check if the user is authorized to enter screen 3. Check the CLASS, FACILITY and the entity, $$CTMPNL3.qname.

2. Refresh commands in the Job Dependency Network screen (Screen 3.N).

   The following entities are checked to verify user authorization for the various REFRESH command options in the Control-M Job Dependency Network screen.

   Table 38 Refresh Commands

   Command	Entity
   REFRESH NET	$$REFNET.qname
   REFRESH PROPAGATE	$$REFPROP.qname
   REFRESH DEADLINE	$$REFDEAD.qname
   REFRESH ALL	$$REFALL.qname
   AUTO	$$CTMAUTO.qname

   For more information about command REFRESH, see the online facilities chapter in the Control-M for z/OS User Guide.

3. Subsequent operations in Screen 3

   Actions (hold, delete, rerun, and so on) in the Active Environment screen (Screen3) are separated into different categories of access authority.

   The CLASS checked is FACILITY. The entity checked is:

   Copy

   $$JOBxrrr.qname.owner

   where

   • owner is the owner specified in the Job Scheduling Definition screen (Screen 2).

   • x is the 1-digit action identifier.

   • rrr is the 3-character identifier for each action described in the following table.

   Table 39 Active Environment Actions

   Action Indentifier	Action	Description
   1	ACT LOG SYS STA ZOO	Activate Log Viewsys Veiwstat Zoom
   2	CNF FOK FRE HLD RRN RRN	Confirm Force OK Free Hold Return Restore
   3	CHA PRI DEL EDI KIL	Change Change priority Delete, Undelete Edit JCL Cancel an executing job

   To permit USERA to hold jobs with an owner of USERB, use the following command:

   For RACF:

   Copy

   PERMIT $$JOB2HLD.qname.USERB ACCESS(READ) ID(USERA) CLASS(FACILITY)

   For TopSecret:

   Copy

   TSS PERMIT(USERA) ISMFAC($$JOB2HLD.qname.UDERB) ACC(READ)

   For ACF2/SAF:

   Copy

   SET RESOURCE(CMF)
   COMP
   $KEY($$JOB2HLD.qname.USERB) TYPE(CMF)
    UID(USERA) ALLOW

CMEM Security Interface Modules

Module CTOSE01

The CTOSE01 module is the security module of Exit CTOX001. It is used to verify that the user is authorized to order the rule. A security check is performed to verify if the logged on (current) user is allowed to order rules on behalf of the user ID as specified in the owner field of the rule definition.

Basic Definition Mode

Verify that the user is authorized to use the user ID (owner) in the rule definition. It is assumed that if the logged on user is allowed to submit jobs on behalf of another user, the logged on user is also allowed to order CMEM rules owned by that user.

RACF Security

For this verification:

Entity Built: owner.SUBMIT

CLASS checked: SURROGAT

where owner is the user ID specified as the owner of the CMEM rule.

TopSecret Security

The Application Interface module (TSSAI) is called with the following parameters:

Resource Class: ACIDCHK

Resource Name: owner

where owner is the user ID specified as the owner of the CMEM rule.

ACF2/SAF Security

For this verification:

Entity Built: $SUBMIT.owner

CLASS checked: FACILITY

where owner is the user ID specified as the owner of the CMEM rule.

Extended Definition Mode

Verify that the user is authorized to specify the user ID (owner) in the rule definition.

RACF Security

For this verification:

Entity Built: $$CTOORD.qname.owner

where owner is the user ID specified as the owner of the CMEM rule.

TopSecret Security

For this verification:

Entity Built: $$CTOORD.qname.owner

where owner is the user ID specified as the owner of the CMEM rule.

ACF2/SAF Security

For this verification:

Entity Built: $$CTOORD.qname.owner

where owner is the user ID specified as the owner of the Control‑O rule.

Module CTOSE02

The CTOSE02 module is the security module of Exit CTOX002. It is used to verify that the owner of a rule is allowed to specify the DO statements or ON statements as specified in the rule definition. The module builds a list of security calls, one call for each DO statement and for certain ON statements.

For the rule to be loaded, the owner of the rule must have the authority to request all of the statements specified in the rule definition. If authorization fails for one of the calls, the entire rule load is canceled.

The CLASS checked is always FACILITY. The entity built for each DO statement depends on if Basic Definition mode or Extended Definition mode is used.

Basic Definition Mode

The structure of the entity is as follows:

Table 40 CTOSE02 Basic Definition Entity Structure

Extended Definition Mode

The structure of the entity is as follows:

Table 41 CTOSE02 Extended Definition Entity Structure