Invalid value in SERVICE ACTION field

Douglas Gilbert dgilbert at
Tue Apr 29 09:36:53 PDT 2014

* From the T10 Reflector (t10 at, posted by:
* Douglas Gilbert <dgilbert at>
On 14-04-28 06:28 PM, Douglas Gilbert wrote:
> Irrespective of what SPC-4 says, from the point of view
> of an OS or user space tools, this is just a mess.
> I'd reckon about 80% of devices get the illogical "right"
> answer (invalid field in cdb), 15% get the logical "wrong"
> answer, and as for the rest well that depends on which
> command you send :-)
> A suggestion: for SPC-5 deprecate INVALID COMMAND OPERATION
> CODE and the use of INVALID FIELD IN CDB for service actions.
> Then introduce a new additional sense for both cases: for
Lets expand on this mess. Say we send a COPY OPERATION ABORT
command to a SCSI device of unknown capabilities. It might:
   a) do it
      since it supports no commands with opcode 0x83
   c) yield CC, INVALID FIELD IN CDB with no sense key specific (SKS)
      Field Pointer
   d) yield CC, INVALID FIELD IN CDB with SKS Field Pointer at byte 1
      (i.e. the service action)
   e) yield CC, INVALID FIELD IN CDB with SKS Field Pointer at byte 2
      (i.e. a non-zero LIST IDENTIFIER may upset the error handler first)
   f,g,h) yield CC, INVALID FIELD IN CDB with SKS Field Pointer at
       byte 3, 4 or 5 (see below)
BTW the spc4r36s definition of the SKS Field Pointer is silly.
What is the use of a bit pointer if the corresponding byte
pointer must point to the first byte of the a multi-byte field?
Observing some recent Seagate disks that implement the REPORT
SUPPORTED OPERATION CODES command, I guess they use the CDB USAGE
DATA as a mask. It is inverted, applied byte-wise starting from
byte 0 of the cdb. The first resulting non-zero byte triggers a
INVALID FIELD IN CDB with SKS Field Pointer for that byte and
the highest non-zero bit's position is the bit pointer.
Hopefully the proposed SCSI capabilities will mandate the REPORT
SUPPORTED OPERATION CODES command for all (but the most primitive
SCSI) devices. If the CDB USAGE DATA is accurate (including for
vendor specific commands) then an application client could
pre-check commands before issuing them. That would be easier
than coping with such sloppy sense data for this common case.
Doug Gilbert
* For T10 Reflector information, send a message with
* 'info t10' (no quotes) in the message body to majordomo at

More information about the T10 mailing list