Submitting a job on behalf of other user

JES, JES2, JCL utilities, IDCAMS, Compile & Run JCLs, PROCs etc...

Re: Submitting a job on behalf of other user

Postby steve-myers » Thu May 10, 2012 9:14 am

Surrogate job submission is just RACF profiles. If your security people give you trouble they don't know what they're doing. What they're really doing is giving you trouble for not discussing this with them in the first place! Password encryption is not something I know much about, much less doing something that will work on both Windoze machines and mainframe systems.
Global moderator
Posts: 2106
Joined: Thu Jun 03, 2010 6:21 pm
Has thanked: 4 times
Been thanked: 243 times

Re: Submitting a job on behalf of other user

Postby dick scherrer » Thu May 10, 2012 7:41 pm


Once again, i may have gotten lost. . . :?

giving surrogate access to my tool might not be possible easily
Is there some reason this cannot just be run by the user as themself?

If the tool is in a general loadlib and the user has access to "their" datasets, why/how does "surrogate access" come into the picture?
Hope this helps,
User avatar
dick scherrer
Global moderator
Posts: 6268
Joined: Sat Jun 09, 2007 8:58 am
Has thanked: 3 times
Been thanked: 93 times

Re: Submitting a job on behalf of other user

Postby Sivapradeep » Thu May 10, 2012 8:41 pm

Hi dick scherrer ... i cannot put in general loadlib now itself. still i'm implementing this tool. i'm testing on few user IDs on whom i got SURROGATE USER privilige..

Hi Robert.. i'm continuing your post for above link in this thread as it seems to be locked.

I got SURROGATE USER privilige on few user IDs to test my tool. i believe i can submit their job by just mentioning their user's ID in my job card. 'T12345.OP.PS' isn't a hardcoded name (i hardcoded while pasting in this forum), this name is entered by the user and it comes dynamically. so, the user knows what is happening here clearly.

moreover, this entire process is getting executed in my region. so i got SURROGATE USER privilige on few user id to test. I cant give the source code completely to the user.

Please, no need to consider any security issues here. All that has taken care. Just suggest me the mistakes of ADDSD and DELDSD in that thread if i have made any. i'm not sure of the syntax.
Posts: 35
Joined: Mon Mar 26, 2012 2:09 pm
Has thanked: 1 time
Been thanked: 1 time

Re: Submitting a job on behalf of other user

Postby Robert Sample » Thu May 10, 2012 8:56 pm

You can stop asking the questions -- I don't think you're going to get better responses than you already have. I'm locking this thread, and if you attempt to start any further threads on this subject, they will be deleted without notice.

If your RACF is set up correctly, you should not need to be granting access to data sets and removing it. Of course, the commands you posted grant NOBODY access to the data set, anyway. The Security Administrator's User's Guide manual talks about what all is required to establish surrogate users:
17.8.1 Allowing Surrogate Job Submission

You can allow the use of surrogate users. A surrogate user is a RACF-defined user who has been authorized to submit jobs on behalf of another user (the execution user) without specifying the execution user's password. Jobs submitted by a surrogate user run with the identity of the execution user. For example, if user JOE submits a job with the following JOB statement, JOE is the surrogate user and TOM is the execution user:

//jobname JOB 'accounting-information',USER=TOM

All access checks are done with TOM's user ID. Any auditing records produced by RACF because of the submitted job's actions include the information that the job is a surrogate job (unless the PASSWORD parameter is specified on the JOB statement).

┌─── Attention ──────────────────────────────────────────────────────────┐
│ │
│ A user should not allow another user to act as surrogate user unless │
│ the surrogate user can be trusted as highly as the execution user is │
│ trusted. This is because the surrogate user can do anything the │
│ execution user 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 the execution user's │
│ data. │
│ │

The surrogate user must specify the execution user's user ID on the USER parameter on the JOB statement and must not specify a password. If the PASSWORD parameter is specified with a password, surrogate processing is not performed, and audit records generated by the job's activities do not indicate that the job is a surrogate job. This applies not only to jobs submitted through the TSO SUBMIT command, but any time the surrogate user is a RACF-defined user.

| When the SECLABEL class is active and the SETROPTS MLS option is in
| effect:

| If a security label is specified for the submitted job, the specified
| label must be equal to or greater than the current security label of
| the surrogate user, and both the surrogate and execution users must
| have READ authority to the specified label. After job verification is
| complete, the job submitted by the surrogate user runs as if the
| execution user had submitted the job.

| If a security label is not specified for the submitted job but the
| surrogate user has a current security label, the submitted job runs
| with the surrogate user's current security label.

To allow surrogate users, do the following:

Ensure that the installation exit for the TSO SUBMIT command (IKJEFF10) does not prevent users from submitting jobs with job names that do not match their user IDs. The installation exit supplied by IBM meets this requirement, because it does not check the JCL of submitted jobs. For more information, see z/OS TSO/E Customization.

If your installation implemented the sample ICHRTX00 exit from SYS1.SAMPLIB member RACINSTL to enable surrogate user processing, you should migrate to profiles in the SURROGAT class. After RACF is installed, the code in the ICHRTX00 exit that checks $SUBMIT.userid profiles is not used. You should copy the $SUBMIT.userid profiles to SURROGAT profiles as follows:


Define resource profiles in the SURROGAT class for each execution user who needs to allow others to be surrogate users:

RDEFINE SURROGAT execution-userid.SUBMIT UACC(NONE) OWNER(execution-userid)

Note: Specifying the OWNER operand allows the execution user to issue the PERMIT command for this profile.

To specify that another user can act as the surrogate for an execution user, give the surrogate user READ access authority:

PERMIT execution-userid.SUBMIT CLASS(SURROGAT) ID(surrogate-userid) ACCESS(READ)

Only users and groups that have READ access authority are allowed to submit jobs on behalf of another user.

To check whether a user can submit jobs for another user, make sure the user (or a group the user is a member of) is in the access list with READ access authority:


When you are ready to control access using the SURROGAT profiles, activate the SURROGAT class:


To disable surrogate support for a particular user, delete the profile for that user. To disable surrogate support for all users, deactivate the SURROGAT class.

NJE notes:
The node in which SURROGAT checking occurs depends on the job statements (see "Where NJE Jobs Are Verified" in topic 17.10). For verification done on the receiving node, the SURROGAT checking is done after any translation due to NODES profiles. (See "Understanding NODES Profiles" in topic

If the submitter of a job is a started procedure, the execution node is not checked during SURROGAT processing.
Robert Sample
Global moderator
Posts: 3716
Joined: Sat Dec 19, 2009 8:32 pm
Location: Dubuque, Iowa, USA
Has thanked: 1 time
Been thanked: 278 times


Return to JCL


  • Related topics
    Last post