The remaining fields in the RRCB are main memory addresses. The first is the address of the I/O request itself, followed by the addresses of one or more data buffers. The I/O request is the instruction to the modem; it is not our request for information from the remote computer system. That information is in the data buffers. The I/O request is not kept in the RRCB, because it can vary in length for different devices. The request is at a location in memory pointed to by this field. The data buffers pointed to by the following fields contain the data to be transferred to the device. For our example, the address given would be for the user buffer, the SSD, where our SQL request to the remote system is stored.

Figure 10.5 also shows the formats for two bus messages, OPSTART and OPEND. These are examples of the 12-byte messages sent across the SPD bus during the unit operation previously described. The first of these messages, the OPSTART, will be used to initiate the I/O operation in our example.

The OPSTART bus message contains four fields. The first field contains the length of the RRCB in memory. The second field identifies this as an OPSTART message. The address of the RRCB in memory occupies the third field. The last field contains the server-connection identifier. The server here is an IOP, so for the bus message we need to identify the server. The server-connection identifier is part of the CID. The full CID in the RRCB identifies the device.

To initiate the I/O operation, IPCF sends the OPSTART message across the appropriate SPD bus (using a unit operation) to the identified IOP on the adapter card (we are not at the modem yet). When the IOP receives the bus message, it knows there is work to perform. The IOP then initiates a storage operation across the SPD bus, and using DMA, fetches the entire RRCB into its own memory. Once the IOP has the RRCB, it again initiates a storage operation to fetch the request from its location in the main memory. Finally, because the operation calls for data (our SQL request to the remote computer) to go out to the device, the IOP fetches the data from the data buffers that contain our SQL FETCH request.

The IOP now instructs the modem to send our request across the communications line to the remote computer system. Data is transferred from the data buffers in main memory as requested. When the operation has completed with the remote system signaling it has received the transmission, the IOP creates an OPEND bus message. It then initiates a unit operation to send the OPEND message back to the IOBU, which is the system processor. Remember that both IOPs and the system processor act as IOBUs.

The OPEND bus message shown in Figure 10.5 contains four fields. The first field has various flag bits that give information about the operation and its completion. The type field (the second field) identifies this message as an OPEND. The third field contains the request identifier (RID) originally put into the RRCB by IPCF for tracking purposes. Finally, the fourth field contains the completion status. Based on certain flag settings, the completion status may instead be found in the extended status field of the RRCB.

Figure 10.6 on the following page shows the end of the I/O operation in our example. The receipt of the OPEND bus message means the IOP is finished processing the request. The I/O handler (not shown in Figure 10.6) dequeues the IORM that was enqueued to the BUB for the SPD bus that sent the OPEND message, updates the status field, and sends it to the IPCF router’s queue.

Figure 10.6  I/O Operation (End)

The IPCF router examines the completion status, and assuming everything completed normally, sends a response message to the queue identified in the return queue address field of the IORM. The IOM that originated the I/O request performs any necessary cleanup and, again assuming that everything completed normally, sends a feedback record (FBR) to the MI response queue (MIRQ) that was identified in the original source sink request. This notifies the function manager that the first I/O operation has completed. At this point, the FM is finished and can perform other operations. The application program that requested the SQL FETCH will wait until the remote system sends back the results of the database operation.

The I/O operation just described has sent our SQL request to the remote system. When the request arrives at the remote system, and after the remote modem has signaled the local system that the transmission was received, the modem at the remote system causes the start of an I/O operation to receive it. At some time in the future, when the database on the remote system has finished executing our SQL request, the remote system will initiate an I/O operation to send the results back to us. In the local system, the IOP with the attached modem will receive data from the remote system and initiate another I/O operation. This time, the IOP will send the OPSTART to a main processor, which, as we saw earlier, also can perform all the IOBU functions necessary to complete an I/O operation. When MIRQ receives the completion (OPEND) message from the second local I/O operation, the function manager signals the application program that its I/O request (the SQL FETCH) has completed.

Before we leave this example, I should point out that when multiple systems are interconnected with OptiConnect for OS/400 instead of a communications line, there is far less time required to complete the I/O operation. First, the connection between the systems is a high-speed, fiber-optic cable. Second, the APPC and APPN communications protocols are replaced with a special device driver. This device driver doesn’t have to perform the complex error checking that is required when we are exchanging data using a conventional communications line. Communications lines have inherently “noisy” electrical signals. Redundant information must be transmitted to provide for error checking and error correction. A fiber-optic cable transmits information using light, which is reasonably noise free. Thus, the device driver used for OptiConnect provides a more direct connection with less redundancy.

I should also point out that if the SQL request was for the local database, none of the operations involving the APPC FM, the APPN station IOM, or the SDLC line IOM that I just described would occur. Instead, the database support in the local system would handle the SQL FETCH just as I described in our example in Chapter 8 using the single-level store. Page faults that result in disk operations are handled by storage management working directly with IPCF.