The OPNSEC macroinstruction is issued by a VTAM® application program that has received a BIND request from a PLU and wishes to respond positively to the BIND and establish the session. The application program is the SLU in the session. The application program receives the BIND in its SCIP exit routine. See Exit routines related to session establishment and termination for more information about the SCIP exit routine.

OPNSEC uses the RPL and the NIB to identify the BIND for the session to be established, and to specify options for the session. The RPL's NIB field points to the NIB to be used. If the application program supports parallel sessions (PARSESS=YES is coded on the APPL definition statement) and the NIBCID field is not zero, the CID uniquely identifies the BIND to be accepted. (The CID can be obtained from the SCIP exit parameter list.) If the NIBCID field is zero, or if the application program does not support parallel sessions, the NIBSYM field must contain the name of the PLU from which a BIND has been received and that is to be accepted. If more than one BIND has been received from the named PLU, the oldest is accepted.

The name supplied can be network-qualified if PARMS=(NQNAMES=YES) is specified on the ACB macroinstruction. If a BIND cannot be found to accept, the OPNSEC is rejected with (RTNCD,FDB2)=(X'10',X'00').

It is possible for the pending active session created by the BIND to end before the application program issues the OPNSEC macroinstruction. For example, if the PLU is a VTAM application program, it might issue OPNDST, which would cause the BIND to be sent, and then issue CLSDST before the OPNDST completed. This would cause an UNBIND to be sent, which could purge the BIND. If this happens, OPNSEC is posted with (RTNCD,FDB2)=(X'10',X'12'), and sense code=X'08060000' in the SSENSEI, SSENSMI, and USENSEI fields. This is not an error on the part of the application program, but is a situation the application program should be prepared to handle.

When the BIND flows in the network, the name fields (NS_PLU and NS_SLU) can be network-qualified. As the BIND is presented to the application, this name, if it were network-qualified, is changed from network-qualified to an 8-byte name. The 8-byte name can differ from the LU portion of the network-qualified name. If it does, name translation has occurred. For details of the names available to the application, see Table 1 and Table 1.

Use of the network name, as opposed to the ACBNAME, in the BIND permits the SLU to unambiguously relate a BIND to a particular PLU. The network name can also be used by the SLU to reinitiate a session (for example, after a session outage), even if the original session is initiated by the PLU or a third party.

The NIB used for OPNSEC specifies options regarding the processing of the session, such as whether a RESP exit routine should be scheduled when a response is received. The USERFLD in the NIB contains a 4-byte value to be associated with the session. This value is returned to the application program in the USER field of the RPL used for a SEND, RECEIVE, RESETSR, or SESSIONC macroinstruction, when the associated communication operation is complete. This value might be a pointer to a user control block representing the session.

When OPNSEC successfully completes, VTAM indicates in the NIB the type of encryption (selective or required) that is specified by the application program. Refer to Node initialization block (NIB) for more information about the contents of the NIB.