Question:
Do I need to support every command in this specification?

Answer:
No. For specific device types, some commands are mandatory and others are optional. For example, there are several commands that apply only to floppy controllers. We must support these commands due to the unusual characteristics of diskette media.

Where possible, mandatory commands for particular device types are indicated.

Question:
Some commands do not appear to be used by the current OS/2 2.0 device managers. Must I implement these commands?

Answer:
Yes. To preclude compatibility problems with future releases of OS/2, you should follow this specification as closely as possible with respect to mandatory commands.

Question:
What happens if IBM-supplied sample code differs in some way from this specification?

Answer:
This specification takes precedence over IBM-supplied samples. Obtain clarification from IBM if you have questions on a particular code sample.

Question:
SCSI defines different command formats for different device types. Do I need to support all the different CDB formats?

Answer:
No. You must support the DASD type formats only. The remainder of the device types will be supported by way of CDB PassThru; that is, the adapter device driver will be supplied with an appropriate CDB.

Question:
Do I need to support the IORB_CHAIN RequestControl flag on every IORB command type?

Answer:
No. The chain flag is used only on IOCC_EXECUTE_IO commands. In addition, all IORBs contained in the chained request will reference the same UnitHandle.

Question:
Do I need to support any unusual SCSI commands?

Answer:
No. We expect most DASD devices to conform to CCS. Regarding SCSI Write/Verify, adapter device driver writers are encouraged to emulate this command for drives that do not provide this function directly. Suppliers of devices that have unusual command requirements are expected to provide filter device drivers.

Question:
What kind of error recovery is an adapter device driver required to perform?

Answer:
Adapter device drivers are responsible for error recovery. An error reported to the layers above the adapter device driver is considered not recoverable. In general, SCSI devices retry at the device level, so the adapter device driver does not need to retry commands that failed at the device. However, the adapter device driver should retry commands that failed due to errors on the SCSI bus during either the command or data transfer phases.

Question:
Must the adapter device driver retry commands that were disrupted due to an adapter reset for a hang condition?

Answer:
Yes, the adapter device driver is responsible for retrying commands disrupted by an adapter device driver-initiated reset of an adapter to clear a hang condition.

Question:
Does the adapter device driver have to report media removal with an error code to the device manager?

Answer:
If the unit supports media removal, the adapter device driver is required to report media removal to the device manager by way of the appropriate IOERR_* code. In addition, the adapter device driver should return the same error code for all work queued for the unit. The adapter device driver should not retry this error. The adapter device driver should treat a power-on condition the same as media removal. The adapter device driver should return the appropriate IOERR_* code for all queued work after a not ready condition.

If the unit does not support media removal, the adapter device driver should retry the operation.

Question:
Must my adapter device driver perform SCSI sense code->IOERR_* translation?

Answer:
Yes. The OS/2 DASD device manager expects a uniform set of error codes and will not examine SCSI sense codes.

Question:
Must my adapter device driver return sense data when requested?

Answer:
Yes. The OS2SCSI and OS2ASPI device mangers need to return this data to their clients.