Specifications

Operating System Routines
IOC$REQCOM
Synchronization
A driver fork process calls IOC$REQCOM at fork IPL, holding the corresponding
fork lock in a multiprocessing environment. IOC$REQCOM transfers control
to IOC$RELCHAN. If the fork process calls IOC$REQCOM by means of the
REQCOM macro (or a JMP instruction), IOC$RELCHAN returns control to the
caller of the driver fork process (for instance, the fork dispatcher).
Description
A driver fork process calls this routine after a device I/O operation and all
device-dependent processing of an I/O request is complete.
IOC$REQCOM performs the following tasks:
• If error logging is in progress for the device (as indicated by UCB$V_
ERLOGIP in UCB$L_STS), writes into the error message buffer the status
of the device unit, the error retry count for the transfer, the maximum error
retry count for the driver, and the final status of the I/O operation. It then
releases the error message buffer by calling ERL$RELEASEMB.
• Increments the device unit’s operations count (UCB$L_OPCNT).
• If UCB$B_DEVCLASS specifies a disk device (DC$_DISK) or tape device
(DC$_TAPE) and error status is reported, performs a set of checks to
determine if mount verification is necessary. Tape end-of-file errors (SS$_
ENDOFFILE) are exempt from these checks. For a tape device with success
status, checks to determine if CRC must be generated.
• Writes final I/O status (R0 and R1) into IRP$L_IOST1 and IRP$L_IOST2.
• Inserts the IRP in systemwide I/O postprocessing queue.
• Requests a software interrupt from the local processor at IPL$_IOPOST.
• Attempts to remove an IRP from the device’s pending-I/O queue (at UCB$L_
IOQFL). If successful, it transfers control to IOC$INITIATE to begin driver
processing of this I/O request. If the queue is empty, it clears the unit busy
bit (UCB$V_BSY in UCB$L_STS) to indicate that the device is idle.
• Exits by transferring control to IOC$RELCHAN.
3–132