Design example: MRO connection – using only the link user ID

In this scenario, the requirement is that authorization in the remote CICS® region is solely based on the user ID associated with the connection from the local CICS region. All requests from the local CICS region run under the same user ID, often known as a functional user ID.

For more information about configuring this scenario, see the configuration task Configuration example: MRO connections - using only the link user ID .

The scenario is a configuration where no end-to-end auditing of resources is required and where authorization checks are managed in the local CICS region.

The scenario is used where one or more of the following conditions apply:

  • You need no differentiation of the user that is required for the transaction attach, command, and resource authorization checks in the remote CICS region.
  • No auditing of user access to resources in the remote CICS region is necessary.
  1. A DPL request is made by a task in cicsA that runs under taskUseridA.
  2. taskUseridA does not flow from the local CICS region because the CONNECTION definition in the remote CICS region is defined with ATTACHSEC(LOCAL).
  3. functionalUseridB is used as the functional user ID because the SESSION definition in cicsB is defined with a USERID value of functionalUseridB.
  4. cicsB checks that the functional user ID is authorized to attach the transaction by calling RACF®. RACF verifies that functionalUseridB belongs to a group (funcUserGroup) that has READ access to a member list that contains the CSMI transaction in the GCICSTRN class. In this case, the INTERCOM member list in the CICS-supplied DFH$CAT2 sample is used. INTERCOM contains a set of intercommunication related transactions.
  5. functionalUseridB is associated with any additional request that is initiated by the task in the remote CICS region, for example by an EXEC CICS START command or an outbound request.