During system IPL, the RACF® subsystem is generally started earlier than some of the TCP/IP-related address spaces on which the RRSF TCP protocol support relies. For example, the TCP/IP and policy agent address spaces are required. Further, if host names are used instead of IP addresses in TARGET command definitions, then the resolver address space, and possibly an external name server, are also required. During RACF subsystem initialization, the socket listener process starts when the local node is made operative. Remote TCP connections are not attempted until the listener is successfully established. If the listener fails to initialize, message IRRC050I is issued and the listener periodically tries again for approximately 30 minutes, then issues message IRRC063I and stops trying.

As the TCP/IP address space initializes, it receives AT-TLS policy files from the policy agent address space. Address spaces (such as the RACF subsystem) might be requesting socket services before TCP/IP has obtained its policy files. The default behavior of TCP/IP is to reject such a request unless the user ID has access to a stack initialization resource that is used as an override. If this resource is protected by a RACF profile, then failed accesses result in ICH408I messages to the console. Therefore, you might see such a message for the RACF address space each time it attempts to establish its TCP listener before TCP/IP obtains the policy files. This is normal, and such messages can be ignored. Make sure that you do not allow the RACF subsystem user ID to this resource, or else the listener successfully initializes, and then attempts to establish connections with remote nodes. If these connections are attempted before TCP/IP obtains its policy, RRSF rejects the connections for lack of AT-TLS policy, and the connections must be restarted manually when the policy server has served the policy files to TCP/IP.

See z/OS Communications Server: IP Configuration Guide for information about stack initialization protection.