Controlling who can cancel jobs by job name

Users are always authorized to cancel jobs that they have submitted. Using RACF®, you can control who can use the TSO CANCEL command to cancel jobs, depending on the job names. To do this, perform the following steps:

Ask your TSO system programmer to change TSO installation exit IKJEFF53 to become a dummy exit. For specific information, see z/OS TSO/E Customization.
Define profiles for the job names you want to protect:
```
RDEFINE JESJOBS CANCEL.nodename.userid.jobname UACC(NONE)
```
Note: The qualifiers for CANCEL profiles have the same meaning as for SUBMIT profiles. However, the jobname and userid qualifiers are reversed in CANCEL and SUBMIT profiles. This is because of the expected use of the profiles:
- It is likely that many users would submit jobs having common job names, with certain exceptions. For example, the following profiles would allow many users to submit jobs whose names begin with PAYROLL, except when those jobs run with BEN's authority:
```
RDEFINE JESJOBS SUBMIT.*.PAYROLL*.*   UACC(READ)
RDEFINE JESJOBS SUBMIT.*.PAYROLL*.BEN UACC(NONE)
```
- It is likely that one user would give another the authority to cancel all of the first user's jobs, with certain exceptions. For example, the following profiles would allow JOE the authority to cancel BEN's jobs, except for his PAYROLL jobs:
```
RDEFINE JESJOBS CANCEL.*.BEN.* UACC(NONE)
PERMIT  CANCEL.*.BEN.* CLASS(JESJOBS) ID(JOE) ACCESS(ALTER)
RDEFINE JESJOBS CANCEL.*.BEN.PAYROLL* UACC(NONE)
```
- These examples assume that a SETROPTS GENERIC(JESJOBS) was previously issued to turn generics on for this class and that a SETROPTS REFRESH was then done.
Give users the appropriate access authority:
```
PERMIT CANCEL.*.*.PAYROLL* CLASS(JESJOBS) ID(PAYGROUP) ACCESS(ALTER)
```
Users must have ALTER access authority to issue the CANCEL command for the job.
If the JESJOBS class is not already active, activate the JESJOBS class:
```
SETROPTS CLASSACT(JESJOBS)
```