FW: RE: 98-115r0 - Sundry Minor Enhancements for SPC-2

Larry Chen larryc at maxstrat.com
Mon Feb 2 13:07:03 PST 1998


* From the T10 (formerly SCSI) Reflector (t10 at symbios.com), posted by:
* Larry Chen <larryc at maxstrat.com>
*
Hi Gerry,

Oops. I guess I should have CCed the reflector.
Larry
On Fri, 30 Jan 98 18:15:58 PST  Larry Chen wrote:
>Hi Ralph,
>
>I was wondering whether I could get something into SPC-2 ??
>
>I want to use bit 5 of Byte 6 of the Standard Inquiry Data
>for the following purposes:
>
>0	- port A or Primary Port
>1	- port B or Alternate Port
>
>Note:
>The use of Port A or Primary Port maybe preferred over Port B or
>Alternate Port for performance reasons by the target device.
>
>Comments ??
>Regards,
>Larry
>
>On Fri, 30 Jan 1998 15:46:13 -0600 (CDT)  ROWEBER at acm.org wrote:
>>* From the T10 (formerly SCSI) Reflector (t10 at symbios.com), posted by:
>>* ROWEBER at acm.org
>>*
>>         T10/98-115r0
>>Date:	 30 January, 1998
>>To:	 T10 Membership
>>From:	 Ralph Weber, X3T10 Alternate member from Symbios Logic
>>Subject: Sundry Minor Enhancements for SPC-2
>>
>>During the past several months various suggestions have been made for minor 
>>enhancements in SPC-2.  These proposals are complied here for consideration 
>>by T10.
>>
>>1) Add the following before the last sentence in clause 4.2.4:
>>
>>   "If the information being transferred to the data-in buffer includes 
>>   fields containing counts of the number of bytes in some or all of the 
>>   data, the contents of these fields shall not be altered to reflect the 
>>   truncation, if any, of data that results from an insufficient allocation 
>>   length value, unless the description of the data-in buffer format 
>>   specifically states otherwise in this or some other standard."
>>
>>It has been noted that most command descriptions include wording with 
>>effects similar to what is proposed above.  However, some command 
>>descriptions are silent on this subject and adding the proposed wording 
>>in clause 4.2.4 (the description of the allocation length CDB field) will 
>>cover all cases.
>>
>>2 ) In the process of resolving an issue regarding field pointer bytes 
>>sense-key specific data in the standard sense data (see 97-187), the 
>>working group produced the following statement of its position regarding 
>>multi-byte fields:
>>
>>  a) A multi-byte field is a defined field in a CDB or parameter list 
>>     whose length exceeds one byte; and
>>  b) The contents of the sense-key specific data for the ILLEGAL REQUEST 
>>     sense key is not specified by SCSI-2 when the error occurs in a 
>>     reserved field.
>>
>>The following should be added at the end of the third paragraph after 
>>Table 36 in clause 7.20.1 to embody the committee's position in SPC-2:
>>
>>   "If a field whose length exceeds one byte is reserved, it shall be 
>>   treated as a multiple-byte field.  If several consecutive bytes are 
>>   individually reserved, each shall be treated as a single-byte field."
>>
>>3) It has been noted that no SCSI standard contains the requirement that 
>>invalid operation codes result in a CHECK CONDITION status.  To address 
>>this omission, the following wording should be added at the end of the 
>>second paragraph in clause 4.2:
>>
>>   "If a device server receives a CDB containing an operation code that is 
>>   invalid or not supported by that device server, target, or device, then 
>>   the device server shall return CHECK CONDITION status with the sense key 
>>   set to ILLEGAL REQUEST and an additional sense code of INVALID COMMAND 
>>   OPERATION CODE."
>>
>>4) The SPC recommendations for  virtual units regarding the contents of the 
>>device identification VPD page have been overtaken by events, specifically 
>>the IEEE Tutorial for SCSI use of IEEE company_id (also available as 
>>T10/97-101r2).  Unless or until an IEEE document number than can be 
>>referenced from an ANSI standard becomes known to T10, note 53 (the first 
>>note in clause 8.4.3) should be removed from SPC-2.
>>
>>5) The description of the Identification descriptor field in the device 
>>identification VPD page has been rendered incorrect by the addition of the 
>>Association field.  The second paragraph before Table 112 in clause 8.4.3 
>>should be replaced with:
>>
>>   "Each Identification descriptor (see table 111) contains information 
>>   identifying the logical unit, physical device, or access path used
>>   by the command and returned parameter data.  The Association field 
>>   indicates the entity that the Identification descriptor describes.  
>>   If a physical or logical device returns an Identification descriptor 
>>   with  the Association field set to 0h, it shall return the same 
>>   descriptor when it is accessed through any other path."
>>*
>>* For T10 Reflector information, send a message with
>>* 'info t10' (no quotes) in the message body to majordomo at symbios.com
>
>-------------------------------------------------------
>Larry Chen             Tel: 408.383.1600 (x116)
>MAXSTRAT Corporation   Fax: 408.383.1616
>801 Buckeye Court      E-mail: larryc at maxstrat.com
>Milpitas, CA 95035     URL: http://www.maxstrat.com/
>-------------------------------------------------------
>

-------------------------------------------------------
Larry Chen             Tel: 408.383.1600 (x116)
MAXSTRAT Corporation   Fax: 408.383.1616
801 Buckeye Court      E-mail: larryc at maxstrat.com
Milpitas, CA 95035     URL: http://www.maxstrat.com/
-------------------------------------------------------


*
* For T10 Reflector information, send a message with
* 'info t10' (no quotes) in the message body to majordomo at symbios.com




More information about the T10 mailing list