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 userid. 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 userids. 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 userid matches the local region userid:

If the userids match, only one security check is made. This will either be against the default user (for ATTACHSEC=LOCAL) or against the userid that is in the received FMH-5 attach request (ATTACHSEC=non-LOCAL).
If the userids do not match, then for ATTACHSEC=LOCAL, resource checks are done only against the link userid. For ATTACHSEC=non-LOCAL there are always two resource checks. One is against the link userid, and the second is against the userid 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 userid had been revoked.