The EXEC CICS® ASSIGN command might perform
differently in a transaction routing environment, from how it does
in a single region. Therefore, you might need to include different
processing to reflect this.
You might find that three of the
options to the EXEC CICS ASSIGN command cause an unexpected
reaction, or return unexpected values. A closer look at these helps
you to understand why:
- PRINSYSID
- This option returns the SYSID of the principal facility to the
transaction. This option requires that this facility be an LU 6.2
conversation. The principal facility for a routed transaction is represented
by the surrogate terminal definition entry, which does not meet the
requirement. Therefore, CICS raises the INVREQ condition.
Note: You cannot use an EXEC CICS ASSIGN
PRINSYSID command to find the name of the terminal-owning region.
- USERID
- This option returns the user ID that is associated with the task.
For a routed transaction, the user ID that is returned is based on:
- Whether security for inbound requests is “local” or “trusted”.
In CICS, this would be specified with the Communications Definitions (CD) RemoteSysSecurity attribute in the application-owning region.
- Whether or not a user ID is sent from the terminal-owning region
to the application-owning region. If the terminal-owning region is CICS, this is specified in the terminal-owning region with the
CD OutboundUserIds attribute.
- Whether or not a link user ID is locally defined for the connection
between the terminal-owning region and the application-owning region.
In CICS, a link user ID is specified with the LinkUserId attribute.
- The value of the local default user ID (in those conditions when
a user ID is not available; for example, when a user ID is not flowed
and a link user is not defined.) In CICS,
the default user ID is specified with the Region Definitions (RD) DefaultUserId attribute.
See Link security and user security compared for information about how a user ID is determined for inbound
requests. See also Using CRTE and CESN/CESL to sign on from a remote system.
- OPERKEYS
- This option returns a 64-bit mask that represents the TSL keys
assigned to the remote user. The TSL keys assigned are based on the
local definitions of the link keys for the connection in addition
to the keys that are locally defined for the user ID that the user
is logged on as.
If the remote user is signed on locally (for
example, if the user uses CRTE to route to the remote system, then
uses CESN or CESL to sign on to a local user ID), the returned mask
represents the keys that are defined for the user in the definition
entry and are also defined for the link.
In
some conditions, you might only be given public access.
See Link security and user security compared for information
about how security keys are assigned. See also Using CRTE and CESN/CESL to sign on from a remote system.