The OpenVMS generic SCSI class driver provides a mechanism
by which an application program can control a SCSI device, supplied
by a source other than HP, that cannot be controlled by the standard
OpenVMS disk and tape class drivers. By means of a Queue I/O Request
($QIO) system service call, a program can pass to the generic SCSI
class driver a preformatted SCSI command descriptor block. The generic
SCSI class driver, in conjunction with the standard OpenVMS SCSI
port driver, delivers this SCSI command to the device, manages any
transfer of data from the device to a user buffer, and returns SCSI
status to the application.
In effect, an application using the generic SCSI class driver
implements details of device control usually managed within device
driver code. The programmer of such an application must understand
which SCSI commands the device supports and which SCSI status values
the device returns. The programmer must also be aware of the device's
timeout requirements, data transfer capabilities, and command retry
behavior.
The application program sets up the characteristics of the
connection the generic SCSI class driver uses when delivering commands
to, exchanging data with, and receiving status from the device.
The program associates each I/O operation the device can perform
with a specific SCSI command. When it receives a request for a particular
operation, the application program creates the specific command
descriptor block that, when passed to the device, causes it to perform
that operation.
The application initiates all transactions to the SCSI device
by means of a $QIO call to the generic SCSI class driver, supplying
the address and length of the SCSI command descriptor block, plus
the parameters of any data transfer operation, in the call. When
the transaction completes and the application program regains control,
it interprets the returned status value, processes any returned
data, and services any failure. To avoid conflicts with other applications
accessing the same device, an application may need to explicitly allocate
the device.
Because the generic SCSI class driver has no knowledge of
specific device errors, it neither logs device errors nor implements
error recovery. An application using the driver must manage device-specific
errors itself. To service an error returned on a single transaction,
the application must issue additional $QIO requests and initiate
further transactions to the device. If more precise or more efficient
error recovery is required for a device, the developer should consider
writing a third-party SCSI class driver, as described in the OpenVMS VAX Device Support Manual (available
on the Documentation CD-ROM). A third-party SCSI class driver can log
errors associated with device activity by using the method described
in the OpenVMS VAX Device Support Manual (available on the Documentation CD-ROM).
A third-party class driver is the only means of supporting
devices that themselves generate transactions on the SCSI bus, such
as notification of a device selection event to the host processor.
Refer to the description of asynchronous event notification (AEN)
in the OpenVMS VAX Device Support Manual (available on the Documentation CD-ROM).
Generic SCSI Class Driver Flow shows
the flow of a $QIO request through the generic SCSI class driver
and the port driver.
Figure 2 Generic SCSI Class Driver Flow
When direct access to a target device on the SCSI bus is required,
the generic SCSI class driver is loaded for that device, as described
in
Configuring a Device Using the Generic Class Driver.
An application program using the generic class driver performs the
following tasks to issue a command to the target device:
Calls the Assign
I/O Channel ($ASSIGN) system service to assign a channel to the
generic SCSI class driver, and to allocate the device for the application's
exclusive use.
Formats a SCSI command descriptor block.
Formats any data to be transferred to the device.
Calls the Queue I/O Request ($QIO) system service
to request the generic SCSI class driver to send the SCSI command
descriptor block to the port driver.
Upon completion of the I/O request, interprets the
SCSI status byte and any data returned from the target device.
These operations are described in following sections.
Because
incorrect or malicious use of the generic SCSI class driver can
result in SCSI bus hangs and lead to SCSI bus resets, DIAGNOSE and
PHY_IO or LOG_IO privileges are required to access the driver. An
application program can be designed in such a way as to filter user
I/O requests, which allows nonprivileged users access to some device
functions.