binary format list log parameters and ascii list log parameters

Kevin D Butt kdbutt at us.ibm.com
Thu Aug 18 14:31:20 PDT 2011


Formatted message: <a href="http://www.t10.org/cgi-bin/ac.pl?t=r&f=r1108184_f.htm">HTML-formatted message</a>

Ralph, Fred, and Curtis,
I can see Fred's argument and I can see Ralphs.  Fred's seems to make the 
most sense - except that there is nothing about the ASCII format parameter 
that requires it to be null terminated.
In a quick review that I just performed, I found that the only log pages 
(out of SPC, SBC, SSC, SMC, ADC)  that have a mix of binary and ascii 
information in a single parameter reside in SSC-3, SSC-4, and SMC-3. SSC-4 
has not gone to letter ballot yet, though planned to this meeting cycle 
and SMC-3 is still in letter ballot resolution.  SSC-3 however, has left 
the building.
In SMC-3 there are the 
	Medium Change Diagnostics page (defined as binary format 
parameters)
	Current Service Information log page (defined as ascii format 
parameters)
In SSC-3 (and SSC-4)
	Tape diagnostic data log page (defined as binary format 
parameters)
	Current Service Information log page (defined as ascii format 
parameters)
The Current Service Information log page has the least penetration in the 
industry, but it has been implemented by at least one device.
If SPC-4 were shored up to be clear that ASCII format parameter included 
only ASCII data in the PARAMETER VALUE field and the binary format 
parameter were to be clear that the PARAMETER VALUE field may contain 
binary data only or a mixture of data types, then I think it would be well 
defined.
The issue is if we can agree to change the FORMAT AND LINKING field for 
the log parameters of a log page that is in an older version of the 
standard (i.e., SSC-3) and current draft standards (SSC-4 and SMC-3)  that 
has been implemented by at least one vendor. I think the risk is fairly 
well contained.
Thanks,
Kevin D. Butt
SCSI & Fibre Channel Architect, Tape Firmware
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 us.ibm.com
http://www-03.ibm.com/servers/storage/ 
From:	Ralph Weber <roweber at IEEE.org>
To:	T10 Reflector <t10 at t10.org>
Date:	08/18/2011 01:57 PM
Subject:	Re: binary format list log parameters and ascii list log 
parameters
Sent by:	owner-t10 at t10.org
* From the T10 Reflector (t10 at t10.org), posted by:
* Ralph Weber <roweber at ieee.org>
*
Fred,
You are seeing only what you want to see, and I am seeing
only what I choose to see.
The parameter length is a field in an ASCII format list.
If all of the fields in an ASCII format list must be between
20h and 7Eh, then I have decided that this requirement
applies equally to the length. Thus, the minimum length
is 20h (or 32 decimal).
Thankfully, our debate is perfect news for the SMC group.
We have established beyond any doubt that the standard is
sufficiently vague to allow *anything* the SMC group prefers
to be seen as correct.
To this monumental accomplishment, I might also add the
observation that any attempt to nail down these floorboards
will produce months of high-volume discussion in CAP.
At the end of the day, list format log parameters are what
the standard says they are ... owing mostly to the creative
invention of multi-field parameters and lack of diligent
review at time of inception. Its all water over the dam now,
and we might as well get used to it.
Maybe the new rigor in log parameter definitions which Mark
Evan initiated will prevent future fiascoes, but I am not
holding my breath.
All the best,
.Ralph
On 8/18/2011 2:48 PM, Knight, Frederick wrote:
> Not at all. If FORMAT AND LINKING says ASCII, and the PARAMETER LENGTH
> says 2, then the whole log parameter is 6 bytes in length (containing
> all the mandatory header stuff, and then 1 byte of an ASCII parameter
> value; followed by one byte of ZERO).
>
> Where are you getting 32 bytes?
>
> My assumption has been that the statement "The FORMAT AND LINKING field
> (see table 301) indicates the type of log parameter."
>
> Actually indicates the type of the parameter value.  I assume this
> because it seems pretty obvious that it is not talking about all the
> fields within the whole log parameter itself (if it was, then they would
> all be required to be BINARY, because of the DU/TSD/ETC/TMC binary
> fields, and a type of ASCII would be impossible).
>
> And interesting, when you look at 7.3.2.2.2.4:
>
> "The device server shall return LOG SENSE parameter control byte values
> and process LOG SELECT parameter control byte values as shown in table
> 304 for any log parameter that is defined to be an ASCII format (see
> 4.4.1) list log parameter."
>
> Which contains the reference to 4.4.1 - that describes ASCII data
> formats (values 20h to 7Eh).
>
>		 Fred
>
> -----Original Message-----
> From: Ralph Weber [mailto:roweber at IEEE.org]
> Sent: Thursday, August 18, 2011 8:13 AM
> To: T10 Reflector
> Subject: Re: binary format list log parameters and ascii list log
> parameters
>
> * From the T10 Reflector (t10 at t10.org), posted by:
> * Ralph Weber<roweber at ieee.org>
> *
> Fred,
>
> Does not your conclusion mean that ASCII format list parameters
> must be at least 32 bytes (20h) in length?
>
> All the best,
>
> .Ralph
>
> On 8/17/2011 5:25 PM, Knight, Frederick wrote:
>> "3.1.11 ASCII format list log parameter: a log parameter that contains
>> ASCII data in a list format. See 7.3.2.2.2.4"
>>
>> So, now I need to understand what ASCII data is, so I look at 4.4.1:
>>
>> "4.4.1 ASCII data field requirements
>> ASCII data fields shall contain only ASCII printable characters (i.e.,
>> code values 20h to 7Eh) and may be terminated with one or more ASCII
>> null (00h) characters."
>>
>> Therefore, anything not in the range 20h to 7Eh makes it NOT ASCII.
>>
>> Yes, I think a reference to 4.4.1 would be helpful.
>>
>> I can't find any definition for what binary data is, so that means to
>> me, that it can be anything (byte values in the range 00h to FFh).
>>
>> One key difference is the meaning of 00h.  If you report the data as
>> ASCII, then an application must stop parsing the data when it hits the
>> 00h, but if it is BINARY data, then the application keeps parsing
>> (because 00h is part of the data).
>>
>> So if I understood what Ralph said, I think that means I come the
>> opposite conclusion:
>> If the data is all in the range 20h to 7Eh, then it is ASCII, if ANY
>> byte contains a value not in that range, then it is BINARY.
>>
>>     -  OR put another way  -
>>
>> The presence of one BINARY field in a log parameter pushes it out of
> the
>> ASCII format list camp and into the BINARY format list modus operandi.
>>
>>		 Fred
>>
>> -----Original Message-----
>> From: Ralph Weber [mailto:roweber at IEEE.org]
>> Sent: Wednesday, August 17, 2011 3:31 PM
>> To: T10 Reflector
>> Subject: Re: binary format list log parameters and ascii list log
>> parameters
>>
>> * From the T10 Reflector (t10 at t10.org), posted by:
>> * Ralph Weber<roweber at ieee.org>
>> *
>> Okay! So, the question is which, if any, of the following
>> statements are true.
>>
>> 1) ASCII format list parameters contain *all* ASCII fields.
>> 2) Binary format list parameters contain *all* binary fields.
>>
>> To belabor the obvious, both statements cannot be true unless
>> people are *very* careful about how the construct log parameters.
>>
>> IMHO The presence of the control byte and parameter length fields
>> in an ASCII format list parameter negates any possibility that
>> statement 1) can be true. The only statement in the pair which
>> can ever be 100% true is 2).
>>
>> Based on this and a little leap of faith, I would like to claim
>> that the presence of one ASCII field in a log parameter pushes
>> it out of the Binary format list camp and into the ASCII format
>> list modus operandi.
>>
>> Let's see if this sets the T10 Reflector on fire for a day
>> or two.
>>
>> All the best,
>>
>> .Ralph
>>
>> P.S. If I have parsed Curtis' description correctly, the current
>> specification is correct ... a lucky break eh!
>>
>> On 8/17/2011 1:17 PM, Ballard, Curtis C (StorageWorks) wrote:
>>> * From the T10 Reflector (t10 at t10.org), posted by:
>>> * "Ballard, Curtis C (StorageWorks)"<curtis.ballard at hp.com>
>>> *
>>> This question came up because SMC-3 leveraged a log page which has
>> parameters that are not entirely ASCII but sets the FORMAT AND LINKING
>> field to 01b, ASCII format list.  We're trying to figure out whether
> to
>> change to match what we think the FORMAT AND LINKING should be and be
>> inconsistent with existing implementations that may be able to be
>> leveraged but set the field differently or leave the field as is.
>>> The implication is that the ASCII format list log parameter value is
>> all ASCII but I can't find anything in SPC-4 (r31) that says what the
>> PARAMETER VALUE field of an ASCII format list log parameter contains.
>> The closest statement I found is the definition but that is never
>> referenced from any of the text describing the log parameter so it is
> a
>> bit tricky to find and even that doesn't really say the PARAMETER
> VALUE
>> is ASCII data, it just says the parameter 'contains' ASCII data.
>>> "3.1.11 ASCII format list log parameter: a log parameter that
> contains
>> ASCII data in a list format. See 7.3.2.2.2.4"
>>> Table 301 specifies the log parameter type as indicated by the FORMAT
>> AND LINKING field.
>>> "01b --- ASCII format list --- 7.3.2.2.2.4"
>>>
>>> Section 7.3.2.2.2.4 is only defining the parameter control byte and
>> doesn't define what is allowed to be in the PARAMETER VALUE field of
> an
>> ASCII format log parameter.
>>> The best reference I can find in that section is:
>>>
>>> "any log parameter that is defined to be an ASCII format (see 4.4.1)
>> list log parameter"
>>> But section 4.4.1 never defines what it means to be an "ASCII
> format".
>> That section is all about ASCII data fields and the sentence with that
>> reference is about a log parameter, not a data field.  Table 299
> defines
>> the log parameter as containing fields and bits that aren't ASCII so
> it
>> isn't clear what the reference is intending to clarify.
>>> I think this paragraph should reference back to 3.1.11 after
>> 'parameter' and probably not reference 4.4.1.
>>> The table that says how to fill in the FORMAT AND LINKING field sends
>> you back to table 301 and we start all over again.
>>> I believe that the intent was probably something like "the PARAMETER
>> VALUE field of a ASCII format list log parameter is an ASCII data
> field
>> (see 4.4.1)" but I can't prove that from the text I have.
>>> Curtis Ballard
>>> Hewlett Packard
>>>
>>> -----Original Message-----
>>> From: owner-t10 at t10.org [mailto:owner-t10 at t10.org] On Behalf Of Ralph
>> Weber
>>> Sent: Wednesday, August 17, 2011 10:46 AM
>>> To: T10 Reflector
>>> Subject: Re: binary format list log parameters and ascii list log
>> parameters
>>> * From the T10 Reflector (t10 at t10.org), posted by:
>>> * Ralph Weber<roweber at ieee.org>
>>> *
>>> Is it fair to assume that the difference between ASCII data
>>> and binary data is not of interest to the SMC working group?
>>>
>>> All the best,
>>>
>>> .Ralph
>>>
>>> On 8/17/2011 11:20 AM, Kevin D Butt wrote:
>>>> The SMC working group has a question.  SPC-4 describes binary format
>>>> list log parameters and ascii list log parameters.  The only
>>>> difference we can find is in the value in the FORMAT AND LINKING
>>>> field.  We can find no specified behavior differences.  What are the
>>>> functional differences besides the parameter control byte?
>>>>
>>>> Thanks,
>>>>
>>>> Kevin D. Butt
>>>> SCSI&    Fibre Channel Architect, Tape Firmware
>>>> 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 us.ibm.com
>>>> http://www-03.ibm.com/servers/storage/
>>> *
>>> * For T10 Reflector information, send a message with
>>> * 'info t10' (no quotes) in the message body to majordomo at t10.org
>>>
>>> *
>>> * For T10 Reflector information, send a message with
>>> * 'info t10' (no quotes) in the message body to majordomo at t10.org
>>>
>>>
>> *
>> * For T10 Reflector information, send a message with
>> * 'info t10' (no quotes) in the message body to majordomo at t10.org
>>
>>
> *
> * For T10 Reflector information, send a message with
> * 'info t10' (no quotes) in the message body to majordomo at t10.org
>
>
*
* For T10 Reflector information, send a message with
* 'info t10' (no quotes) in the message body to majordomo at t10.org



More information about the T10 mailing list