The function manager (FM) is a component in OS/400 that provides the interface between applications and the MI boundary. For each communications “transport” that exists in SLIC, there is usually a corresponding FM in OS/400. The FM handles the top layers of the communications protocol so that, for example, the presentation of data to the application is in the form the application expects.

In our example, we are going to use the FM for the communications support called advanced program-to-program communications (APPC). The first implementation of APPC appeared on the System/38 and provided the capability to have parallel sessions between systems, thereby allowing multiple applications in the separate systems to communicate concurrently. The communications protocol used for this was logical unit type 6.2 (LU 6.2). The logi-cal unit provides the port for an application program to establish conversations and to send and receive data from a partner application in another system.

The AS/400 built upon this implementation with the development of advanced peer-to-peer networking (APPN) to meet the needs of distributed processing across both LANs and remote communications. APPN provides functions such as distributed directory searches of the network to locate any remote system requested by a local application. It calculates the best route, if more than one exists, between the local system and the remote system based on the class of service the user has selected. Several enhancements have been made to this support over the past several releases of the AS/400, including automatic configuration when an incoming connection request is received from an unknown system directly connected on a LAN. Another enhancement is support for multiple network connectivity. The APPN support allows applications written for the APPC/LU 6.2 API to communicate with a remote application without modification when multiple systems are providing networking services.

The SQL CONNECT statement in our example identifies a device file to use for this I/O request. Let’s assume that in our example the device used to connect the local AS/400 to the remote one is a modem (as opposed to an adapter connecting to a network). The DRDA support in the database passes control to the APPC FM. This FM is called to build the necessary I/O structures and to create the I/O request. The FM issues the Request I/O (REQIO) instruction at the MI. This is an MI privileged instruction that cannot be issued by the application program. The REQIO instruction has associated with it a Source Sink Request (SSR), which contains

1.  A pointer to the MI response queue (MIRQ), which will receive a message when the I/O operation is completed.

2.  A pointer to the device description (DEVD), which at the MI is called the LUD, used for the device.

3.  A pointer to the source/sink data (SSD), which is a user buffer to store the data being transferred to or from the device. In our example, this buffer contains the SQL request we are sending to the remote system.

The I/O request in the form of a message is then sent to a queue below the MI belonging to the station IOM. The station IOM is a program in SLIC that receives requests from the FM to establish connections, sometimes called sessions, with remote systems, devices, or applications. The station IOM handles the middle layers of the communications protocol. These middle-layer functions include such things as path control and networking. Each type of communications path has a corresponding station IOM. There is, for example, a station IOM that supports peer-to-peer communications, as well as communications to a host system, such as a System/390. Still another station IOM allows the attachment of PCs running the LU 6.2 protocol. In our example, we want to establish a peer-to-peer connection with the remote system identified by the SQL CONNECT statement. We will, therefore, use the station IOM for APPN. This APPN station IOM surrounds the request message with the control information needed to establish the remote session. It also provides the interface between the FM and the line IOM.

The station IOM uses the controller description (CTLD), which at the MI is the CD, that exists for this particular connection. The CD is a configuration object that contains information about the remote system (remote system address, APPN control point name, and any other specific parameters that are required). Based on the description in the CD, the station IOM adds any commands or control characters to the I/O request needed to establish the remote system connection. When it is finished, the station IOM sends the I/O request to the queue belonging to the line IOM.

The line IOM implements the data-link protocols. The line IOM provides a transparent interface to the station IOMs independent of the underlying data-link protocol and network being used. For our example, we are going to use the synchronous data link communications (SDLC) protocol.

The line IOM manages the flow of data, and it identifies the physical connections to the line. It uses the line description (LIND), which is called the network description (ND) at the MI, for the SDLC line and adds the necessary control characters to the request. The line IOM also provides the interface between the upper layers of the communications protocol and the hardware connection.

The I/O request then is sent to the interprocess communications facility (IPCF) in SLIC. IPCF is used for all devices; it communicates with the I/O hardware to send the request across an SPD bus to an IOP on the adapter card. IPCF uses the LUD (DEVD identified in the SSR) to determine that, in our example, we are using a modem. The modem is attached to the adapter card, which in turn is attached to the physical communications line. Shortly, we will see exactly how these communications are accomplished; but first we need to look at the I/O control blocks that allow the SLIC to work with the hardware.

Figure 10.3 shows these I/O control blocks and how they are interconnected. These blocks contain all the information necessary for IPCF to locate a device. This information is updated at IPL time when IOBU addresses are assigned. The information must be kept in memory tables where it is accessible to both hardware and software. Note that the arrows shown in Figure 10.3 indicate addresses, whereas the arrows in Figure 10.2 indicate control transfers.

Figure 10.3  I/O Control Blocks