Key Issues in the SCSI-3 Primary Commands (SPC)

Thu Jun 2 08:32:47 PDT 1994

 Ralph wrote:
>Can I reverse the sense of statement in the MODE
>SENSE(10) clause?

No. I think it should be, as it is, permissible to have a SCSI device that has
no changeable mode pages but does have mode pages. I did not investigate this
issue beyond the editor's statements. Is there an implication that MODE
SENSE(6) is different?

>Is the standard INQUIRY data SftRe bit still applicable in
>SCSI-3?  Is it protocol specific?

It is applicable unless we take a specific vote to eliminate it. Zero based
option budgeting is tempting but to disruptive. I would support a motion to
eliminate the Soft Reset Alternative from SCSI-3 but I am open to convincing
counter arguments.

I do not support making it protocol specific (the bit). This implies opening up
the decision process again with each new transport mechanism (which is what I
presume you mean by protocol). This just adds to the FUD.

>Is the standard INQUIRY data CmdQue bit still applicable in SCSI-3?

Certainly. I assume some operating systems are still allowed to not issue a
queue.

>The standard INQUIRY data Sync, WBus16, and WBus32 bits are
>specific to SIP.  How should these bits be handled in the SPC?
>Should I create a protocol-specific field?  Or, should I just
>leave the bits?  If I create a protocol specific field, does
>SftRe somehow map to it too?

I think they should be set to zero with other protocols. Although they could be
redefined by another field in Inquiry which identifies the transport mechanism.

What do you mean by a protocol specific field? I think a field is needed which
indicates the transport mechanism of the SCSI device. I assume this on the
basis that I presume we are not precluding a serial to parallel converter which
does not regenerate the commands and command responses. If we are we should
clearly state the limitation. But I do not think Inquiry should be the
limitation. I also assume there are specific new bits needed for the new
transport mechanisms. I presume their editor's have a reminder list of those
bits.

Regarding Soft Reset the answer is still no.

>Is the following statement correct: "The sense data shall be
>available if a Auto Contingent Allegiance condition exists for
>the task set"?  Is task set a wide enough boundary for the ACA
>requirement?

No. It doesn't exist for the task set. It exists in the task set for a task. It
impacts the task set.  However the statement that sense data shall be available
is correct.

SAM specifically requires that ACA shall not cross task set boundaries.
Therefore a task set is wide enough. Why do you ask?

>There is a sentence describing the "progress indication"  sense-
>key specific bytes that I do not understand.  The sentence is:
>These fields only apply to the FORMAT UNIT command with the Immed
>bit set to one.  Does this mean that the sense-key specific bytes
>are valid only while the device server is processing a FORMAT
>UNIT command?

The sentence means These fields do not apply to the FORMAT UNIT command with
the Immed bit set to zero. Consequently a device which implements the FORMAT
UNIT command but not Immed =1 does not have to deal with those fields at all.

>In item e) under deferred errors, the following sentence worries
>me: "If a deferred error occurs after a task has entered the
>enabled state and the task completes successfully, the target may
>choose to return the deferred error information after the
>completion of the current command."  This seems to conflict with
>the following previous statement: "If a task terminates with
>CHECK CONDITION status and the subsequent sense data returns a
>deferred error that task shall not have been executed."

It doesn't seem to conflict with the "following previous statement" nor the
previous following statement but it could be stated more clearly. The meaning
is "If a deferred error occurs after a task has entered the enabled state and
the task completes successfully, the target shall
return the deferred error information after the completion of the current
command in conjunction with a subsequent command that has not entered the
enabled state." Cha Cha Cha.

>How should the SPC say that the ILLEGAL REQUEST sense key can
>indicate that an invalid IDENTIFY message was received?

An IDENTIFY message is invalid if a reserved bit is set to one or if the LUNTAR
bit is set to one and the target does not implement target routines.  A device
may respond to an invalid IDENTIFY message by immediately sending a MESSAGE
REJECT message or by returning CHECK CONDITION status.  If a CHECK CONDITION
status is returned, the sense key shall be set to ILLEGAL REQUEST and the
additional sense code shall be set to INVALID BITS IN IDENTIFY MESSAGE FIELD.

Other ways that it may be invalid result in an Unexpected Disconnect.

>Should ASC/ASCQ 2F/00 text be changed from, "COMMANDS CLEARED BY
>ANOTHER INITIATOR" to "TASK SET CLEARED BY ANOTHER INITIATOR"?

Are you going to change SPC to SPT? (Perhaps with Information thrown in.)

>In the Control mode page, is the DQue bit valid for SCSI-3?

Yes.

>I cannot see a way to put the full description of all the READ
>ELEMENT STATUS parameter pages in the SPC without dropping the
>whole medium changer device model in the SPC.  Help!!!

Move all the medium changer stuff back to the medium changer command set.

--
Gene Milligan -- Gene_Milligan at notes.seagate.com
-------------------------------------------------------------------------
Seagate Technology   -   920 Disc Drive   -   Scotts Valley, CA 95066 USA
Main Phone 408-438-6550   -   Email Problems postmaster at notes.seagate.com
Technical Support: BBS 408-438-8771  Fax 408-438-8137  Voice 408-438-8222  
-------------------------------------------------------------------------

### OGATE Version 8 message trace and attachment information:
### MsgFileName: m:\mgate\outbound\510.MSG
### Org Date:    06-02-94 08:20:40 AM
### From:        Gene Milligan at SEAGATE
### To:          scsi @ wichitaks.ncr.com @ internet
### Subject:     Re: Key Issues in the SCSI-3 Primary Commands (SPC)
### Attachments: none