Invalid value in SERVICE ACTION field

Ralph Weber Ralph.Weber at
Mon Apr 28 08:51:14 PDT 2014

Formatted message: <a href="">HTML-formatted message</a>

I agree with Kevin and Rob. The rest of this looks like an
angels-dancing-on-the-head-of-a-pin justification for something that SPC does
not require.
WD supports returning INVALID COMMAND OPERATION CODE only when no service
actions are supported for the specified operation code. In all other cases,
WD prefers to return INVALID FIELD IN CDB.
From: owner-t10 at [owner-t10 at] on behalf of Knight, Frederick
[Frederick.Knight at]
Sent: Monday, April 28, 2014 9:00 AM
To: Elliott, Robert (Server Storage); Kevin D Butt; T10 Reflector
Subject: RE: Invalid value in SERVICE ACTION field
There has actually been a fair amount of discussion and debate on this topic,
and it has not been resolved as cut and dried as Rob implies.
SPC4 Operation code:
The first byte of a SCSI CDB shall contain the OPERATION CODE field (see
table 32) specifying the command
being requested by the CDB.
Some operation codes are further qualified by a service action code (see In such cases, the
operation code and service action code combine to specify the command being
Unless well-known logical units return different errors than every other LU,
then they are examples:
manager.  Any service action based command that is not specifically in the
list of commands supported by that logical unit are required to return
The ASCQ text does not say just INVALID OPERATION CODE.  It is not specific
to the operation code.	The text says INVALID COMMAND OPERATION CODE.  As the
SPC4 text demonstrates and the well-known logical units show by
example, the COMMAND is the operation code and service action code
Honestly, since SPC requires not just a device, but a host as well (devices
are pretty boring without hosts), I’d be more interested in what some hosts
actually DO.  For example, consider a device that supports ALUA (REPORT
TARGET PORT GROUPS command (A3h/0Ah)), but does not support timestamps (no
REPORT TIMESTAMP command (A3h/0Fh)).  If the host issues the REPORT TIMESTAMP
command first and gets back a CHECK CONDITION, what does the host do?  Would
INVALID COMMAND OPERATION CODE cause the host to never issue the REPORT
TARGET PORT GROUPS command (because it shares the same operation code value
as REPORT TIMESTAMP)?  Would INVALID FIELD IN CDB cause the host to try to
fix the CDB and reissue the failing command with new CDB values?  Both of
those options are broken.
For it to work, the host would have to know either that:
a)	 INVALID COMMAND OPERATION CODE is specific to the operation code and
service action combination; or
b)	for any CDB with a service action, that the INVALID FIELD IN CDB
error sometimes (when the pointer is set to the service action field) is not
a correctable invalid field in CDB, but rather, this form of INVALID FIELD IN
CDB is fatal; except, if the logical unit the command is address to is a
well-known logical unit, in which case, the INVALID COMMAND OPERATION CODE
rules apply.
It seems to me that hosts would pick a) – treat all “command”s the same.
For a host, does INVALID COMMAND OPERATION CODE mean that:
a)	The specific operation code field value is invalid (and therefore ALL
other service actions of that op-code are also invalid); or
b)	The operation code and service action code combination specific to
that command is not supported (and some other service actions of that same
operation code may actually work).
For a host, does INVALID FIELD IN CDB mean that:
a)	Changing a value in the CDB may correct the situation and the command
can be retried; or
b)	For some commands, to some logical units, no change will ever work
because the command is not supported.
My opinion is that hosts do NOT track which commands are service action
“partners” with other commands, but rather, if they track at all, they track
commands individually.	Hosts to not track which op-codes can have CDB
corrections made (when they get INVALID FIELD IN CDB), so the command can
work vs. which op-codes cannot have corrections made because INVALID FIELD IN
CDB (with the pointer set to the operation code field) actually means the
whole command is not supported.
Well known logical units are just an example of how all other logical units
are supposed to operate.
So, are any host people willing to speak up about how they actually use these
error cases?
		Fred Knight
From: owner-t10 at [mailto:owner-t10 at] On Behalf Of Elliott,
Robert (Server Storage)
Sent: Thursday, April 24, 2014 7:16 PM
To: Kevin D Butt; T10 Reflector
Subject: RE: Invalid value in SERVICE ACTION field
I agree.  The field pointer points to the byte and bits containing the
Rob Elliott    HP Server Storage
From: owner-t10 at<mailto:owner-t10 at> [mailto:owner-t10 at]
On Behalf Of Kevin D Butt
Sent: Thursday, 24 April, 2014 12:07 PM
To: T10 Reflector
Subject: Invalid value in SERVICE ACTION field
I have been searching SPC-4 to answer the question, "What is the correct
additional sense code to return if the SERVICE ACTION field contains an
unsupported value?"
One might think that since the OPERATION CODE field and the  SERVICE ACTION
field are taken together to indicate a command that the correct response
However, with a strict reading of SPC-4, since it is silent on this specific
condition, the correct response is to use INVALID FIELD IN CDB
Does anybody disagree with my interpretation?
Kevin D. Butt
SCSI Architect, Tape Firmware, T10 Standards
Data Protection & Retention
MS 6TYA, 9000 S. Rita Rd., Tucson, AZ 85744
Tel: 520-799-5280
Fax: 520-799-2723 (T/L:321)
Email address: kdbutt at

More information about the T10 mailing list