Comments So Far on MAM Proposal

Keith Wolfe wolfe at
Fri Oct 29 10:38:26 PDT 1999

* From the T10 Reflector (t10 at, posted by:
* Keith Wolfe <wolfe at>


Thanks for your prompt reply to the MAM proposal issues.  I added some
additional response to several of the issues in your list below.


JERMAN,STEVE (HP-Boise,ex1) wrote:

> The follow list all the comments I have received so far. My responses are
> after the comments. I will continue to collect comments and review the
> proposal after next weeks meeting. Thanks for all the comments. They help
> alot.
> Regards
> Steve
> [Keith Wolfe - Intellistor]
> 1) Are READ ATTRIBUTE and WRITE ATTRIBUTE optional commands?
> --> As far as the SCSI spec is concerned they would be optional.
> 2) What was the motivation to drop the proposal to support MAM access via
> Log Sense and Log Select?
> --> Dal Allen suggesting that there may be general uses for this
> functionality, problems with library access (no write capability with Read
> Element Status) and some issues with parameter sizes.
> 3) What is the state of the Inquiry Auxiliary Memory page 84h?
> --> We decided it wasn't necessary with the new commands. It also
> complicated things alot.
> 4) Instead of having one ASC/ASCQ indicating auxiliary memory is not
> accessible, please consider having two different ASC/ASCQ's so that there is
> a differentiation between auxiliary memory that is not present and bad
> auxiliary memory:
> a) ASC/ASCQ 'AUXILIARY MEMORY NOT ACCESSIBLE' (e.g. a cartridge is not
> installed in the tape drive)
> b) ASC/ASCQ 'BAD AUXILIARY MEMORY' (e.g. a cartridge is installed in the
> tape drive, but auxiliary memory read/write accesses have failed).
> --> I have had several comments around this subject. Sounds like a good
> idea.
> 5) Page 3, paragraph 6: Is the 'INVALID FIELD IN ATTRIBUTE LIST' ASC/ASCQ
> new? Why not call the Attribute List Length field the Parameter List Length
> --> Bad use of search and replace. I will correct.
> 6) Page 3, paragraph 1 and page 5, paragraph 1: Since the WRITE ATTRIBUTE
> and READ ATTRIBUTE commands use "elements", it would be helpful to
> incorporate a definition and list of elements in the SCSI command set
> document in which WRITE ATTRIBUTE and READ ATTRIBUTE reside (e.g. SPC-2?)
> instead of referring to a device-specific command set (e.g. SMC).
> --> I will need some advice here, my understanding is that things should not
> be defined in multiple places.

*KW>  I agree multiple definitions should be avoided.  This would require the
element definitions to be moved from the SMC to SPC-2.  The theory behind this
is that device-specific commands can reference definitions/commands in the
Primary Command set, however, commands in the Primary Command set should not be
based on device-specific definitions.

> 7) Page 4, paragraph 3: Is the 'ATTRIBUTE LIST LENGTH ERROR' ASC/ASCQ new?
> --> S&R issue again
> 8) Page 5, paragraph 7: What if the available space as specified by the READ
> ATTRIBUTE Allocation Length can not be filled  with "complete" attributes,
> i.e. a truncated attribute is needed to fill the Allocation Length?
> See page 5:
> 'The ALLOCATION LENGTH field in the CDB indicates how much space has been
> reserved for the
> returned attribute list. If the length is not sufficient to contain the
> entire attribute list, complete attributes
> will be returned until the available space has been filled. This shall not
> be considered an error.'

*KW>  This is precisely my question.  If the available space does not fall on
the boundary of a "complete" attribute, then should only the last complete
attribute be sent (even though the available space has not been filled) or
should the next attribute also be sent and truncated so that the exact number
of bytes of available space are filled?  In other words, the Allocation Length
bytes or all of the available bytes of data are sent, whichever is less,
regardless of whether the last attribute is truncated.  I believe this is the
way other commands such as Log Sense, Mode Sense, etc. work.

> 9) Page 5, paragraph 8: Why not define a new Mode Sense page to get this
> information instead of using the 'DISCOVERY KEY' mechanism in the READ
> ATTRIBUTE command? The Mode page could be similar to Mode page 1Dh (Element
> Address Assignment  Parameters) as supported for a Medium Changer device,
> with the addition of Volume Numbers and Partition Numbers support.
> --> This might be possible. Only issues are  (1) it would be nice to keep
> things self contained, (2) the Discovery Key supports a tree heirarchy so if
> the use of these commands expands the Discovery mechanism does not need to
> change. (3) See Dana Lanes comment below.
> 10) Page 6, last paragraph: If one device server in a target supports the
> SSC command set and a second device server in the same target supports the
> SMC command set, then I presume the element addresses can differ between the
> two device servers?
> For example, the SSC based device server would have access to at most only
> one Storage Element at any given time, i.e the
> cartridge currently loaded, but the SMC based device server would most
> likely have access to many Storage Elements.
> --> Yes, the idea is if a library supports the commands, the same Element
> Addresses will be used. If a tape is part of the same LUN, I think that that
> would be a 'Data Transfer' element.
> 11) Page 7, last paragraph: shouldn't 'WRITE ATTRIBUTE' be 'READ ATTRIBUTE'?
> --> Oops
> 12) Page 8, paragraph 5: If the READ ONLY bit is one, the attribute is
> read-only? If the READ ONLY bit is zero, the attribute is read-write?
> --> Yes, I'll clarify
> 13) Page 8, paragraph 7: The description of clearing attributes is a little
> confusing. I have a couple of questions with regard to clearing attributes:
> --> I need to clarify this a bit.
> a) Is it possible to clear multiple attributes at one time even though only
> one Attribute ID is sent with an Attribute Value of zero using the WRITE
> ATTRIBUTE command?
> --> I'm not sure what you mean. You can send multiple zero length attributes
> with the WRITE ATTRIBUTE command. They will all be cleared. Only the
> parameters specified in the Parameter List will be cleared.
> b) Could a mechanism be implemented in WRITE ATTRIBUTE so that all host
> changeable attributes can be cleared without sending any attribute data
> (i.e. something like PCR in Log Select)?
> --> Doesn't (a) handle it OK?

*KW> (a) above requires parameter data to be sent with zero length attributes.
With a mechanism like an 'ADR' (Attribute Data Reset) bit in the
WRITE ATTRIBUTE command, no parameter data would be required and all host
changeable attributes could be cleared.

> c) Could a mechanism be implemented such that an attribute could be cleared
> and still be reported in response to a subsequent READ ATTRIBUTE command?
> --> I need to clarify this. My wording is suffering from multiple revisions.
> On reflection, only 'host' parameters need dissapear when cleared. Device
> and Media parameters can remain in existance with zero length or 0 contents.
> Again on reflection, some parameters may not be resetable. Do I need to
> indicate that?

*KW>  Maybe I'm missing something here.  The gist of my question was why
cleared attributes could not be returned with zero (or ASCII spaces) contents.
In other words, if an application client requested all Attribute ID's and some
attributes have been previously cleared (possibly by a different application
client), how would the application client requesting the data know Attribute
ID's which have been cleared exist, if they aren't returned with zero contents?

> 14) Page 8, byte 1 in example at bottom of page: Byte 1 should be 03h, not
> 01h.
> --> That table has been wrong in virtually every version I have done. I'll
> correct it again.
> 15) Section 8.X.1, pages 9-15: Steve, many months ago I received a paper you
> authored titled "Mapping of Media Auxiliary Memory Access Commands to
> LTO-CM". The latest version I have is version 2, dated Feb. 3, 1999 which
> contained a mapping of a subset of LTO-CM parameters. If you have a later
> version, would you please send me a copy or let me know where I can access
> it online?
> I believe this is a good opportunity to be sure the LTO-CM parameters are
> fairly/completely represented in the Media  Auxiliary Memory Attribute Data
> for the READ ATTRIBUTE and WRITE ATTRIBUTE commands. It would be nice to
> have all of the LTO-CM parameters supported by the different LTO vendors in
> the same way via READ ATTRIBUTE and WRITE ATTRIBUTE to promote
> data/cartridge interchange capabilities. Is your intent for LTO-CM
> parameters that are not represented by Attributes defined for READ ATTRIBUTE
> and WRITE ATTRIBUTE, to be defined in a vendor unique way in the vendor
> unique sections of the Attribute data?
> --> Addressed in separate email
> 16) Page 9: Is the Load Count attribute (ID 0003h) the same as bytes 48-51
> in the Media Usage History Information?
> --> Yes
> 17) Page 12, MEDIA TYPE: Has the density codes for LTO Ultrium been ratified
> by ANSI? Are they 40h, 41h, 42h, and 43h for LTO Ultrium generation 1, 2, 3,
> and 4 respectively?
> --> Addressed in separate email
> 18) Page 11: Is the intent of the Media Usage History Information data such
> that it can be used for any kind of media? For example, are bytes 0-3
> (Current Number of Clusters Written) intended to be used for whatever the
> device's "blocked or grouped" data is?
> --> That's the intention. From Paul's comments below, maybe we need bytes or
> MBytes rather than blocks to keep it more independent.
> 19) If a device supports the READ ATTRIBUTE and WRITE ATTRIBUTE commands, is
> the support of all of the defined attribute ID's mandatory?
> --> No. The Discovery mechanism allows for Discovery of which attributes are
> supported. For instance, a cleaning cartridge may not support many
> parameters.
> [Dana Lane - Compaq]
> Page 1:
> DAL - I think we should stick with JUST the 16 byte commands. Its confusing
> to have 12 byte commands and 16 byte commands. Seeing as this will only be
> implemented on devices going forward, we shouldn't have much of an issue
> sticking with 16. (Either way, 1 set of commands is better than 2.)
> --> Need further investigaion. Still unsure whether some specific devices
> have problems supporting 16 Bytes.

*KW>  Even though two CDB formats for these commands might be a little
confusing, we would like to see the 12-byte format remain because not all
SCSI HIPC's (Host Interface Protocol Controller chips) support 16-byte CDB's,
even though they support many other SCSI-3 capabilities.  Is it possible to
have just the 12-byte CDB's?

> Page 2:
> DAL - ELEMENT TYPE CODES do not apply to media. We have Storage Elements
> (places that CAN store media not the media itself, Data Transfer elements,
> etc... Are you implying that you want the element type code that contains
> the media that contains the MAM? This is confusing. Same applies to ELEMENT
> ADDRESS below. What I think you mean, is the location of the media
> containing the MAM, right? We should write that up as such.
> --> You are right, I will clarify.
> Page 5:
> ED note: Move Discovery Key to head of list. ANSI always lists fields in the
> order they appear on the page. Just a nit pick.
> --> Yup
> Page 6:
> DAL - By 'X', do we mean don't care or do we want that to be set to 0?
> Should Discovery Key 1 with a valid element address, element type code, and
> or volume number be an ILLEGAL REQUEST or do we want to just ignore the
> other fields? Just curious.
> --> I will clarify.
> Page 6:
> DAL - We currently ship automation devices that do not have sequential
> elements. (DLT libraries are a good example). This method does not support
> those configurations. Is this intended or accidental?
> --> Accidential, I think I need to review the Discovery reports. See Paul's
> comments.
> Page 8 (example at bottom):
> DAL - ED note: This field should be 'left justified'. IE, field MUST start
> at byte 5 and then pad the trailing end with spaces (or 0s if binary). We
> should be a little clearer here just in case.
> --> I hate this example!!!!!! I will try to make it clearer and error free.
> Page 9:
> DAL - For Ids 0 and 1, I think we really want ACTIVE partition data and not
> MAIN partition data. If the media is set up for 3 partitions, which
> partition is MAIN? Also, if we're only writing to a single partition on a
> multi-partitioned tape, we want to track the partition we're writing in,
> don't we?
> --> I'll check on this.
> Page 14:
> DAL - Is the intention here that the host will write this data for its own
> use? Just curious.
> --> Thats the intention.
> [Paul Entzel - Quantum]
> *       I don't see the point of both 12 byte and a 16 byte commands.  If
> the single byte fields in the 12 byte CDB are sufficient for the foreseeable
> future, let's live with them.  If they are not, let's go to 16 now and be
> done with it.
> --> See comment above.

> *       On page 8, the example references an Attribute ID of 1403h, yet byte
> 1 is shown as a 01h.
> --> See above.
> *       You may want to include a couple of more Sense Key/ASC/ASCQ
> combinations for other failure conditions.  I can think of a couple right
> now, such as checksum or EDC failure, or device write failure.
> -> see above.
> *       I recommend that data returned with a Discover Key other than zero
> be prefixed with a header.  The header should include at least the Discover
> Key and the additional data length.
> --> see above. I think you're right. The same approach can cover non
> contiguous element numbers.
> *       The Media Usage History Information and the Partition Usage History
> sections use terms not defined in this context.  Specifically, the terms
> "cluster", "current", and "previous".  "Current" and "previous" are
> understandable, but have no reference.  "Cluster" I suspect is format
> specific to some standard outside the realm of X3.  More definition or
> generalization is required here.
> --> I've been wrestling with this for a while. I will do some more ...
> *       The Medium Length is reported, but not its width.  Are we all
> satisfied with the current tape widths?
> --> Good point. On most tape drives, length is a variable, width isn't but
> you never know.
> *       The terms "Medium Type"  and "Density Code" are used somewhat
> differently than other X3 standards.  SSC actually reports a Medium Type in
> the MODE SENSE headers and a Density Code in the Block Descriptor.  The
> Medium Type field is defined as Vendor Specific.  The Density Code field
> refers to the REPORT DENSITY SUPPORT data, as does this document for the
> Medium Type field.  Some devices can actually record more than one density
> on a single medium type.  I find this whole thing confusing, especially when
> you consider that this document claims a value of zero indicates cleaning
> medium and SSC says it means default density.
> --> I'll relook at this

* 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