Allowing another user to submit your jobs

You can authorize another user to submit jobs on your behalf. This user is called a surrogate user. You are the execution user. For example, if you need certain jobs submitted while you are on vacation, you can authorize a surrogate user to submit these jobs for you. You do not have to give the surrogate user access to the data sets the jobs use. You also do not have to give the surrogate user your password, although the jobs will execute under your user ID.

The use of surrogate users might not be allowed on some systems, or might have to be set up by the security administrator. Contact your security administrator to find out if surrogate users are allowed on your system and if you can set them up.

Important: Do not allow another user to act as surrogate user for you unless the surrogate user can be trusted as much as you are trusted. This restriction is because the surrogate user can do anything you can do (unless the surrogate user lacks access to a security label that protects a resource). For example, the surrogate user can submit a job to copy, alter, or delete your data.

To give a surrogate user authority to submit a job for you:

If security labels are used on your system, determine if the surrogate user has access to the security label the job will run under.
To determine if the surrogate user has access to the security label under which the job will run, ask the surrogate user to enter the following command:
```
SEARCH CLASS(SECLABEL)
```
If the security label under which the job will run does not appear in the list of security labels, the surrogate user cannot run the job for you. Ask your RACF® security administrator for assistance or find a different surrogate user who does have the correct security label authority.
Determine if the surrogate user has authority to submit your job.
Determine if a profile called your-userid.SUBMIT exists and if it has an access list identifying the surrogate user with at least READ authority.
To list information about the your-userid.SUBMIT profile, enter the following command:
```
RLIST SURROGAT your-userid.SUBMIT AUTHUSER
```
If the profile exists, RACF lists information about the profile, including the access list. If the surrogate user is on the access list and has an access authority of at least READ, proceed to Step 3.
If the profile does not exist, RACF gives you an error message. You can create the profile yourself if you have class authority to the SURROGAT class. When the SECLABEL class is active, both you and the surrogate user must have authority to the security label of your job. If you need help creating the SURROGAT class profile, ask your security administrator.
Give the surrogate user authority to submit your job.
To give the surrogate user READ access to the your-userid.SUBMIT profile, enter the following command:
```
PERMIT your-userid.SUBMIT CLASS(SURROGAT)
       ID(surrogate-userid) ACCESS(READ)
```
See When data set profile changes take effect to find out when the surrogate user will have the necessary access authority after you enter this command. Proceed to Step 4.
Make sure the surrogate user has access to the data set containing the job control language (JCL) for that job.
The user does not necessarily need access to the data sets the job uses, only to the data set containing the JCL. You can give the surrogate user this access by either sending a copy of the data set or giving the surrogate user READ access to it. For more information about giving someone READ access to a data set, see Permitting an individual or a group to use a data set.

Note: Make sure the USER parameter on the JOB statement in the JCL is present and specifies your user ID. For surrogate processing to be performed, the PASSWORD parameter must not be specified.
To revoke a surrogate user's authority to submit your jobs, enter the following command; the user will no longer be a surrogate user who can submit your jobs:
```
PERMIT your-userid.SUBMIT CLASS(SURROGAT)
       ID(surrogate-userid) DELETE
```