Devices are not necessarily directly attached to an I/O adapter card. They may be attached to an external controller, which in turn is attached to an adapter card. This controller may be able to attach many devices. The controller may attach all the same kind of device or different kinds. But the controller is generally specialized for a class of devices. Thus, we have communications controllers, disk controllers, printer controllers, and so on. The system object used to describe the particular controller at the MI is called a controller description (CD). Similarly, the equivalent OS/400 object also is called a controller description (CTLD).

Rather than just being locally attached to the system, devices and controllers may be remotely attached. Some sort of communications line or network is attached to the system with a controller or device at the other end. The system object used to describe the line or network at the MI is called a network description (ND). OS/400 recognizes both a line description (LIND) object and a network interface description (NETINTD) object.

OS/400 also looks at all I/O as source/sink devices. Recall that we don’t let OS/400 know about disks. Above the MI, everything is treated as an object with memory inside those objects. An I/O device is either a source of information from outside the system or it is a sink for information being sent out of the system. A device is never used to store information in the system. Thus, all disk I/O is performed under the MI in SLIC.

The Components of I/O

It should come as no surprise that I/O, like almost everything else in the AS/400, has its own language and its own set of acronyms. It is difficult to talk about I/O without using this language, so we might as well jump right in. Table 10.1 lists the acronyms we are about to use. This is the language of I/O.

Because SPD bus-attached I/O is so dominant in the AS/400 community, we are going to use the SPD bus-attached I/O for our example in the following sections. As appropriate, I point out where there are major differences when the I/O is attached to the PCI bus. Be aware that above the very lowest layers of SLIC, the differences are slight. The overall I/O structure of the AS/400 is designed to work with multiple different I/O interfaces, which allows for new ones to be added in the future with minimum impact to existing system software. Of course, from an application perspective, there is no difference; the technology-independent architecture guarantees that.

The AS/400 SPD I/O structure from the MI down to the interprocess communications facility (IPCF) in SLIC is shown in Figure 10.2. Starting at the top of Figure 10.2, an MI process is shown to represent an example of a user application program running in the system.

Figure 10.2  AS/400 I/O Structure

In Chapter 8, we defined a simple running example that we used to illustrate the single-level store implementation. Let’s expand on that example to illustrate the AS/400’s SPD I/O operations. If you remember, we had an application program doing a sequential read to an indexed database file, which we said could be accomplished with either an HLL READ or an SQL FETCH. Either of these instructions would result in a request for an I/O operation to fetch a record from the disk. To make this a little more interesting, suppose that, instead of fetching the record from a disk attached to our local system, we want to fetch the record from a remote system at the other end of a communications line using an SQL command to do so.

In Chapter 6, we saw that the SQL interface uses the Distributed Relational Database Architecture (DRDA) to access remote data. Before an SQL request is executed, our application program must execute an SQL CONNECT statement to identify the name of the remote database in a relational database directory. After the communications link has been established between the systems, the SQL request can be sent to the remote system. The database manager on the remote system performs the SQL request and returns the records that satisfy the request to the local system.

Also in Chapter 6, we saw that it is possible to use the Distributed Data Management (DDM) architecture to access the remote database. With the DDM approach, the file processing is performed on the local system. DDM sends all records in the file back to the local system, whereas with DRDA, only records that meet the selection criteria are sent back to the local system. For our example, we have elected to use the SQL interface, which means we must use DRDA. The processing occurs on the remote system, and we will see only the results of that operation. Completing the SQL FETCH instruction requires four I/O operations, two on the local machine (one to send the SQL request, and the other to receive the response), and two corresponding operations on the remote machine.

Communications in the AS/400 are layered — split between OS/400, SLIC, and the hardware. The four processing layers we examine for our example are

•  Application support

•  Function manager

•  Station IOM (input/output manager)

•  Line IOM

We cover the hardware layer in the next section.

Some application support for communications can run in OS/400. Either the user or IBM can supply this support. The capability to plug in user-supplied communications support is provided through the use of APIs. Of course, not every application provides its own communications support, but the facilities are available to do so. In our example, the application support is supplied by the DRDA component of the AS/400 database support.