Controlling who can submit jobs by job name

To control who can submit jobs by job name, perform the following steps:

Ask your TSO system programmer to ensure that TSO installation exit IKJEFF53 checks if the JESSPOOL or JESJOBS class is active, and if either is active, returns to the caller with no action. For specific information, see z/OS TSO/E Customization.
Note: SYS1.SAMPLIB contains a sample of such an exit.
Define at least one profile with a universal access of READ to allow users to submit jobs when the JESJOBS class is activated:
```
RDEFINE JESJOBS ** UACC(READ)
```
Note: This example assumes that a SETROPTS GENERIC(JESJOBS) was previously issued to turn generics on for this class and that a SETROPTS REFRESH was then done.
Define profiles with UACC(NONE) for the job names you want to protect.
```
RDEFINE JESJOBS SUBMIT.nodename.jobname.userid UACC(NONE)
```
where:
nodename

is your local node name.
Note: It is recommended that you define a profile in the RACFVARS class named &RACLNDE, and use &RACLNDE for all profiles in the JESJOBS class.

jobname

is the name of the job specified on the JOB statement.

userid

is the user ID under which the job is to execute (either the USER operand on the JOB statement or the propagated user ID).
For example, the following command would prevent any user from submitting jobs whose job names begin with PAYROLL.
```
RDEFINE JESJOBS SUBMIT.*.PAYROLL*.* UACC(NONE)
```
To allow users to submit jobs protected by the profile, give them READ access authority:
```
PERMIT SUBMIT.*.PAYROLL*.* CLASS(JESJOBS) ID(PAYGROUP) ACCESS(READ)
```
Note: By denying a user sufficient access to a SUBMIT profile, you can prevent that user from submitting jobs protected by the profile even if that user knows the password or is an authorized surrogate user.
For example, the following profile would prevent jobs from being submitted with USER01 as the user ID:
```
RDEFINE JESJOBS SUBMIT.*.*.USER01 UACC(NONE)
```
You can also provide conditional access to the job name, depending on the class and ID of the port of entry (POE) associated with the submitter of the job. The class name you would use is determined by what the submitter is. For a regular submission from a TSO logon session, the submitter's POE is a terminal ID and the class name is TERMINAL. The submitter's POE can also be a JESINPUT device when the submitter of the job is another job.

Making use of the job name conditional on the JESINPUT device is not recommended because this is very much dependent on what type of job was submitted. If the submitting job is a local job, its JESINPUT POE would be an internal reader, a local card reader, or an RJE reader.

However, if the submitting job is an NJE job (for example, from another JES node), its JESINPUT POE would be the node name. This uncertainty can make the use of WHEN(JESINPUT) for the JESJOBS class difficult. Therefore, you should be careful if you decide to use it.
For example, you can allow a user to submit a job only from a certain terminal ID by specifying the WHEN(TERMINAL) operand on the PERMIT command as follows:
```
PERMIT SUBMIT.*.PAYROLL*.* CLASS(JESJOBS) ID(USER01)
       ACCESS(READ) WHEN(TERMINAL(terminal-ID))
```
where terminal-ID is the terminal to which the submitter is logged on.
When you are ready to use the JESJOBS class to control who can submit jobs, activate the JESJOBS class:
```
SETROPTS CLASSACT(JESJOBS)
```
Note: If you activate this class and create no profiles for it, users cannot submit batch jobs.