To activate a process or activity, you can use either the RUN or LINK command. Which you use affects the userid under which the process or activity runs.
The application programmer can specify under whose authority a process or activity is to run, when it is activated by a RUN command, by coding the USERID option of the DEFINE PROCESS or DEFINE ACTIVITY command. If the USERID option is omitted, its value defaults to the userid of the transaction that issues the DEFINE command.
The userid obtained from the DEFINE command is referred to as the defined process userid or the defined activity userid. (In the remainder of this section, we use the term "defined userid" to mean either a defined process userid or a defined activity userid.)
If the USERID option of DEFINE PROCESS or ACTIVITY is specified, CICS® performs (at define time) a surrogate security check to verify that the userid of the transaction that issued the DEFINE command is authorized to use the defined userid. The RACF® profile used for surrogate checking of a BTS process or activity is userid.DFHSTART in the SURROGAT class.
The following example RACF commands authorize a user as a surrogate user of a defined process userid and of a defined activity userid:
RDEFINE SURROGAT defined_process_userid.DFHSTART UACC(NONE)
OWNER(defined_process_userid)
PERMIT defined_process_userid.DFHSTART CLASS(SURROGAT)
ID(define_process_command_userid) ACCESS(READ)
RDEFINE SURROGAT defined_activity_userid.DFHSTART UACC(NONE)
OWNER(defined_activity_userid)
PERMIT defined_activity_userid.DFHSTART CLASS(SURROGAT)
ID(define_activity_command_userid) ACCESS(READ)
Resource-level security checking within a process or activity is based on the userid under whose authority the process or activity is run--that is, the defined userid or the userid of the transaction that issues the LINK command. This userid must have UPDATE access to the CICS file that corresponds to the process-type.