Notice that the following description of the seven control blocks contains information that is specific to SPD bus attached devices. Conceptually the PCI implementation is similar. The seven control blocks shown in Figure 10.3 are

•  Control address table (CAT) — The CAT is a system-wide table that contains the addresses of the major control blocks used by SLIC.

•  Available message queue (AMQ) — The AMQ is pointed to by an address in the CAT. This is the queue with the blank messages that various SLIC components, including IPCF, can use.

•  Bus control table (BCT) — There is one BCT for each SPD bus in the system. The BCT contains buffers, SRQs, and pointers to other control blocks.

•  Bus unit block (BUB) — There is one BUB for each SPD bus in the system. The BUB contains information about the various bus units attached to the bus. The I/O request messages are enqueued here while waiting for I/O device operations to complete. Note that this BUB is not the same as the BUB (Bring Up Bind) that was used to measure progress of the SLIC implementation, which I described in Chapter 4. Perhaps I should say, “This BUB’s not for you.”

•  Remote connection control block (Remote CGCB) — One of these blocks exists for each SPD bus in the system. This control block is used to store device identifiers, status, and IOBU addresses for the remotely connected (not in the processor) IOBUs on the bus. There is one entry for every connection identifier assigned by an IOBU. A given IOBU may support multiple devices and can, therefore, have multiple connection identifiers.

•  Local connection control block (Local CGCB) — One of these blocks exists for each SPD bus in the system. This control block is similar to the remote block, except this one contains information on the locally connected (with the processor) IOBUs.

•  Connection control block (CCB) — There is one CCB for the entire system. The CCB contains the connection identifiers and routings for all SPD buses in the system. It also maintains linkage to the connection information kept for each individual bus in the connection control blocks.

Putting It All Together

We are now ready to complete the SPD I/O example we started. The low-level details below IPCF that I describe in this section now become very specific to the SPD bus structure. The discussion, however, applies to all old and new models of AS/400s that have SPD buses. To see how the entire SPD I/O operation occurs, let’s start over at the beginning where the application requested the I/O operation, and follow it through until the application is notified that the operation has completed.

Figure 10.4 gives a slightly simplified version of Figure 10.2 that we will use for our example. This figure shows the operation down to the point that the operation start (OPSTART) message is sent across the SPD bus to the appropriate IOP.

Figure 10.4  I/O Operation (Start)

At the MI, we have the REQIO instruction. Also shown is the SSD, the user buffer. To simplify our example, only one IOM is shown. As before, the I/O request is sent to the queue belonging to the IOM. When the IOM is finished, a send request (SENDREQ) is passed to IPCF. This is where we left our example previously.

IPCF creates two data structures to accomplish the I/O operation. The first is a message, called the I/O request message (IORM). This message will be used by IPCF to keep track of this particular request and who sent it. The second data structure is a request response control block (RRCB). This data structure is going to be used by the IOP on the SPD adapter card to determine which operation is requested, where the data to be either read or written is located in main memory, and where the completion status is to be placed. This data structure contains information from the seven control blocks in Figure 10.3.

Figure 10.5 shows the format of the IORM and the RRCB. It also shows the format of the two SPD bus messages that are used to start and to end the I/O operation.

Figure 10.5  IPCF Data Structures

The IORM is a message used to identify who requested this I/O operation, or more accurately, who should be notified when the operation has completed. Fields in the message identify the type of message and the bus unit block address. This bus unit block address identifies the BUB for the SPD bus that has the IOP for the device to which we are sending the request. This message will be enqueued to the BUB identified while it is waiting for the I/O operation to complete. Enqueuing means the IPCF places an address in the BUB pointing back to the IORM. More than one IORM can be enqueued to a BUB at a time. This means there can be multiple I/O operations pending on an SPD bus.

Also included in the IORM is the address of the queue to which the message will be sent when the I/O operation is completed. This message queue is associated with the IOM that sent the request to IPCF. The status field in the IORM will be filled in before the message is sent to the IOM’s queue to tell whether the operation finished correctly or there were problems.

The final two fields in the IORM are the connection identifier (CID) and the RRCB address. The CID is filled in by IPCF using the connection control blocks discussed in the last section. The CID uniquely identifies the device. IPCF gets the CID from the remote connection control block using information from the IORM. The RRCB address is the location in main memory where this control block can be found. Note that the memory addresses used in these blocks are real addresses, not virtual addresses.

The RRCB is a control block that the IOP uses to determine the details of the I/O request being sent. Unlike the control blocks established during IPL, the RRCB is a temporary control block that is created for each I/O request. An RRCB can be variable length, so the first field specifies the length of this block in memory. Following the length field are two fields that specify the CID (the same as in the IORM) and also a request identifier (RID) that can be used to track the various requests. Following these two fields is an extended status field. This field is used if the return status will not fit into the status field of the IORM.