A node initialization block (NIB) describes a session that is to be established or terminated. After a session is established, VTAM® supplies the communication identifier (CID), session, which is VTAM's means of identifying the session. VTAM also supplies a limited set of "device characteristics" for the LU.

The symbolic name of an LU is assigned at network definition. It is the name in the name field of the definition statement (for example, LU statement, APPL statement, LOCAL statement) used to describe the LU to VTAM. This symbolic name is generally used only when the application program establishes a session with an LU. After a session is established, the application program uses the CID to communicate on the session. For initiating a session, the symbolic name is placed in the NIB before the session-initiation request (OPNDST, SIMLOGON, or REQSESS) is issued. For accepting a CINIT, a symbolic name is coded only if you are accepting a session with a specific LU. For accepting a CINIT for a session with any LU, a symbolic name is not specified in the NIB; when the session is established, VTAM puts the symbolic name of the LU in the NIB.

The CID is a 32-bit number assigned by VTAM when a session is established. It is used to identify that session. The application program subsequently places the CID in an RPL or NIB control block to specify a particular session to VTAM. The application program should not be written to be dependent on the internal structure of the CID, which should be treated as an unstructured 32-bit number.

The processing options (PROC) determine which characteristics VTAM assigns to the session (for example, whether certain input on the session causes VTAM to schedule a DFASY or an RESP exit routine). See Communicating with logical units, for a description of the DFASY or the RESP exit routines.

The user data is a 4-byte field (USERFLD) that permits some relevant data to be associated with the session-initiation request or the session itself.

When a nonzero USERFLD is specified on certain requests that initiate a session (SIMLOGON, REQSESS, or CLSDST OPTCD=PASS), it becomes a correlator for the session-initiation request. This enables the application program to recognize events associated with a specific initiate procedure. Therefore, if a session-initiation fails after the request is accepted, a Notify request that includes the correlator from the NIB's USERFLD is presented to the application program's NSEXIT routine, to allow the application program to determine which session-initiation procedure failed. If the user field is 0, an NSPE request (rather than a Notify request) is presented to the NSEXIT routine. The correlator is also passed on to the requests to establish a session. Thus, when the LOGON exit routine is scheduled, as a result of a SIMLOGON macroinstruction, the CINIT request presented in the exit routine includes the correlator from the NIB used with SIMLOGON. When the SCIP exit routine is scheduled with a BIND request resulting from a REQSESS macroinstruction, the BIND request includes the correlator from the NIB used with REQSESS. The correlator is arbitrarily assigned by the application program and is meaningful only to the application program. Therefore, it is passed only to the application program that created it. For example, if application program A issues a REQSESS macroinstruction for a session with application program B and specifies a correlator, that correlator would not be passed to application program B's LOGON exit routine. However, when program B establishes the session by issuing OPNDST OPTCD=ACCEPT, the resulting BIND request (received in an SCIP exit routine in application program A) includes that correlator, thus enabling program A to recognize that the BIND resulted from issuing the REQSESS macroinstruction.

On a session-establishment request, (OPNDST OPTCD=ACQUIRE, OPNDST OPTCD=ACCEPT, or OPNSEC), the USERFLD is associated with the session. This USERFLD value is placed in the USER field of the RPL upon completion of each communication request (SEND, RECEIVE, RESETSR, and SESSIONC) on the session. For OPNDST OPTCD=ACQUIRE, the USERFLD supplies only the user data to be associated with the session being established, and is not used as a correlator for the session initiation request generated by OPNDST OPTCD=ACQUIRE.

The logon mode name is the name of an entry in a logon mode table. The entry contains the session parameters to be passed to the PLU in the CINIT. The logon mode name also indirectly specifies the class of service to be used for the session.

The BNDAREA operand can be specified in the NIB macroinstruction to give the location of the BIND area where an application program at the primary end of a session can predefine or dynamically construct a set of session parameters to be used for the session. When the BNDAREA operand contains an address, the LOGMODE operand (logon mode name) is ignored. (The ISTDBIND DSECT can be used to set up session parameters in the BIND area.) Similarly, BNDAREA can be used to designate an area in which a secondary application program can build the session parameters for a negotiable BIND response.

For many application programs, it is convenient and adequate to let VTAM issue the Start Data Traffic request during initial OPNDST processing (that is, allow SDT=SYSTEM to take effect by default when defining the NIB). However, the PLU must still send an SDT request after a Clear request is sent.

For an application program acting as the SLU, the SDT indication is used to specify whether the application program wants VTAM to respond automatically to SDT, or to allow the application program to respond. If SDT=APPL is specified, the application program must respond to SDT requests received in the SCIP exit routine by issuing a SESSIONC macroinstruction with CONTROL=SDT and STYPE=RESP.

The level of cryptography for a session can be required or selective. In a required cryptographic session, all data requests are enciphered before they are sent. In a selective cryptographic session, data requests are enciphered based on the setting of the RPLCRYPT bit in the RPL, which can be set by the RPL's CRYPT keyword. Even though no cryptography is specified, either end of the session can still require cryptography because of system definition requirements. In this case, enciphering occurs transparently to the application program. See How VTAM determines the level of cryptography for a cryptographic session for further information on the levels of cryptography, and Sending and receiving enciphered data requests for level of cryptography information that applies to MVS-only systems.

The Programmed Cryptographic Facility (PCF) and the Cryptographic Unit Support Program (CUSP) do not support network-qualified names. If the application program is using cryptographic facilities, the 8-byte LU name of the partner using cryptography must be unique in all interconnected networks. VTAM uses 8-byte names on the interface to the PCF and CUSP.

The application-supplied operands for dial connections function enables an application to supply certain parameters that are coded on the PATH definition statement and PU definition statement. For more information refer to Application-supplied dial parameter control block (ASDP).

The NIB also contains a coded value that specifies the end user's national language. The application program receives this value from the device characteristics area of the NIB. The hex code can be specified on the LANG parameter in the mode table entry (MODEENT macroinstruction) that is associated with an LU.

The end user can override this code by specifying the language code on the LANG or LANGTAB parameters on a USS command. The hex code that is available in DEVLANG is determined when the LU-LU session is established and cannot change during the session.

Table 1 shows the language codes that can be specified using the LANG or LANGTAB parameters and the corresponding hex values that are provided in the NIB. The application program must determine whether an LU can display the selected language of an end user. Sending double-byte character sets (DBCS) or other invalid characters to a terminal that does not support the character set can result in errors. Many IBM® 3270 type terminals can be queried for character sets and DBCS support. The query bit, DEVQUERY, is determined by the LANG parameter of the MODEENT macroinstruction. Refer to the z/OS Communications Server: SNA Resource Definition Reference for more information.

OPNDST OPTCD=ACQUIRE and SIMLOGON allow lists of NIBs to be used. If OPTCD=CONANY is specified on the request, OPNDST or SIMLOGON is done for each NIB in the list until the operation is successful. In this case, one session at the most is established or initiated. If OPTCD=CONALL is specified, the operation is performed, in turn, for each NIB in the list, and continues until the end of the list is reached. The request is considered successful if at least one session is established or initiated.

To define an NIB list, you use the NIB or GENCB macroinstructions or an IBM-provided DSECT to define a series of contiguous NIBs. You can have any number of NIBs, but the last NIB in the list must have the LISTEND indicator (LISTEND=YES in the NIB macroinstruction). Other NIBs in the list must have LISTEND=NO.

The coding might look like this:

RPL1     RPL   AM=VTAM,ACB=ACB1,NIB=NIB1,OPTCD=ACQUIRE
NIB1     NIB   NAME=LU1,LISTEND=NO
NIB2     NIB   NAME=LU2,LISTEND=NO
NIB3     NIB   NAME=LU3,LISTEND=YES

If all the NIBs in a program are in one list, you might want to specify a working subset of the list for one operation. To do this, code the RPL to point to any one NIB in the list. The subset includes all NIBs from (and including) the NIB pointed to by the RPL through (and including) the next NIB in which the LISTEND indicator is set (LISTEND=YES).

This list form can be used only in the SIMLOGON, OPNDST OPTCD=ACQUIRE, and OPNDST OPTCD=RESTORE macroinstructions. The LISTEND indicator (LISTEND=YES) should be set in the NIB used with any other macroinstruction.