Link security with LU6.2

Link security further restricts the resources a user can access, depending on the remote system from which they are accessed. The practical effect of link security is to prevent a remote user from attaching a transaction or accessing a resource for which the link userid has no authority.

When link security is in use, each session is given an authority defined by a link user ID. For LU6.2, all sessions in a connection can have the same link userid, or different groups of sessions within the connection can have different link user IDs. You can also specify that some groups of sessions should use link security, and that others should not.

You can never transaction route or function ship to CICS® without having at least one security check, but the security checks are minimized if the link user ID matches the local region user ID:
  • If the user IDs match, only one security check is made. This will either be against the default user (for ATTACHSEC=LOCAL) or against the user ID that is in the received FMH-5 attach request (ATTACHSEC=non-LOCAL).
  • If the user IDs do not match, then for ATTACHSEC=LOCAL, resource checks are done only against the link user ID. For ATTACHSEC=non-LOCAL there are always two resource checks. One is against the link user ID, and the second is against the user ID received from the remote user in the attach request.

If a failure occurs in establishing link security, the link is given the security of the local region's default user. This would happen, for example, if the preset session user ID had been revoked.