The most basic user identity requirement is that a remote process must run with a usercode that is allowed at the remote host, or it must run without a usercode.
If the remote process has a usercode, then the usercode must be one that is permitted as a remote user at the remote host. Remote users are defined by REMOTEUSER entries in the USERDATAFILE of the remote host. REMOTEUSER entries can specify in detail the hosts that can submit a process with a particular usercode. The following is an example of a REMOTEUSER entry at a remote host that allows processes with usercode JASMITH to be initiated from the host named CHICAGO:
RU JASMITH OF CHICAGO
In addition to the REMOTEUSER entry, there must be a USER entry for the usercode of the process in the USERDATAFILE at the remote host. A USER entry defines a usercode and assigns usercode attributes to the usercode.
A system administrator at the remote host can cause remote processes that request a particular usercode to be run under a different usercode instead. The substitute usercode is referred to as a local alias usercode. A remote process assumes a local alias usercode if the REMOTEUSER entry at the remote host specifies a local alias for the requested usercode. The local alias usercode must also be defined by a USER entry in the USERDATAFILE at the remote host. The following is an example of a REMOTEUSER entry that specifies a local alias usercode:
RU JASMITH OF CHICAGO LOCALALIAS=JOHNSMITH
The following is an example of a USER entry for the local alias:
USER = JOHNSMITH
MAXPW = 1
PASSWORD = ?
FAMILY DISK = SYSPK OTHERWISE DISK
IDENTITY = “ALIAS FOR JASMITH FROM CHICAGO”Local alias usercodes are intended for use in cases where two different users on two different systems happen to have the same usercode. Establishing local alias usercodes allows these users to run processes on each other's systems, but prevents them from accessing each other's files.
Alternatively, the system administrator can use a local alias usercode to cause many usercodes from remote systems to be mapped to a single usercode at the local system. This mechanism can be useful if the users need to have access to the same set of files.
If no local alias usercode is defined for the requested usercode, then the requested usercode must itself be defined by a USER entry in the USERDATAFILE at the remote host. Note that one or more of the usercode attributes can have different values on the remote host than they have on the local host. These differences do not prevent remote process initiation.
In addition, the usercode can have passwords on the remote host that are different from those defined for that usercode on the local host. If the remote process inherits the usercode of the local process, the password is implicitly changed to a password that is accepted at the remote host. However, if the remote process is explicitly assigned a usercode at initiation time, the password specified should be one of the passwords defined for the usercode at the local host. If the remote process changes its usercode after it is initiated, the process must specify a password that is allowed on the remote host.
A WFL job is the only type of remote process that can run without a usercode. The following are sources from which a remote WFL job can receive a usercode, listed in order of precedence:
-
Assignments to the USERCODE task attribute in the job attribute list.
-
The usercode of a session, if the job is submitted from a CANDE or MARC session.
-
The terminal usercode, if the job is submitted from an ODT. An operator can assign a terminal usercode to an ODT by using the TERM (Terminal) system command.
-
The host usercode of the system, if the job is submitted from an ODT or a nonusercoded MARC session. The host usercode is assigned by the HU (Host Usercode) system command. You can create a nonusercoded MARC session by logging on with an asterisk (*) at a SUPERUSER-capable station.
If a process does not receive a usercode from any of the first three sources listed, then the host usercode is evaluated for SYSTEMUSER status. If the USER entry for the usercode at the remote host assigns SYSTEMUSER status, then the job runs without a usercode. Otherwise, the host usercode is used as the usercode for the job.
A local process cannot initiate a nonusercoded remote process. In the first place, any null usercode explicitly assigned to a process is overridden at initiation time by inheritance from the parent. For example, if the local process assigns a null USERCODE value to a task variable, and then initiates a remote process with the task variable, then the null USERCODE assignment is ignored. The task initiates successfully, but inherits the usercode of its parent. In the second place, if the local process is nonusercoded, and it does not explicitly assign a usercode to the remote process, then the remote process inherits a null usercode. However, the system cannot initiate a remote process that has a null usercode, so the system displays error messages such as the following:
DISPLAY: 1807000 HOST SERVICES ERROR 17: USER ERROR - NO USERCODE TASK OBJECT/ALGOL/TASK ON PACK NOT INITIATED AT PARIS: USER ERROR - NO USERCODE FOREIGN TASK INITIATION FAILED @ 109E:0001:4 @ (00012500)*
For more information about usercode definitions and the REMOTEUSER command, refer to the Security Operations Guide.
