Initialization

Initialization of DMTNET is similar to DMTSNE, except that it does not check for BIND requests. However, it must determine the type of adapter for the link and the channel programs set up for the adapter. DMTNET also calls DMTNCR to prepare the NDWA and the initial RIB and TIB areas needed for the transmission streams.

Initial contact differs for BSC and CTC links; see z/OS: Network Job Entry (NJE) Formats and Protocols for more information. The link driver initializes the adapter and attempts to send data to the remote node. If the corresponding link on the remote node is already active, the send completes and a response is received. The link driver then becomes the BSC and NJE primary and sends the I sign-on record.

If the corresponding remote link is inactive, the link driver puts up a PREPARE (for BSC) or waits for an ATTN interrupt (for CTCA). When the remote link sends data, the link driver sends the response and becomes the secondary system. Primary and secondary mode can also be forced with an initialization parameter.

After contacting the remote node and determining the primary node, the primary node sends an I sign-on record. DMTNET calls DMTNCRSG to evaluate the I record and convert it to the response J record. The initial FCS and BCB values are set on the sign-on records.

DMTNET uses one main wait list and several others, which are used for error recovery situations and for PREPARE mode. When its file or message ECB is posted, DMTNET calls DMTNTR to fill as many output buffers as possible. It may have up to 6 output buffers. When I/O completes successfully (no I/O errors and the BCB is correct), DMTNET calls DMTNRV to empty the buffer. It then schedules a new I/O request, with the first available buffer in the output queue.