Latest Media Auxilary Memory Access Specification

Keith Wolfe wolfe at
Wed Oct 27 15:24:10 PDT 1999

* From the T10 Reflector (t10 at, posted by:
* Keith Wolfe <wolfe at>
JERMAN,STEVE (HP-Boise,ex1) wrote:

> Hi,
> The latest MAM Access proposal is now on the T10 web site ready for
> discussion at the next SCSI Working Group meeting in Monterey.
> If anyone has comments before the meeting, I will be happy to take them.
> Regards
> Steve Jerman, HP
> (208) 396 5618


Thanks for the update, I reviewed the document and came up with the
following issues.  I'm looking forward to hearing about the results of the
meeting in Monterey next week and to any reply you can give to the issues
listed below.


The following 19 items are in response to the PROPOSED ADDITION OF READ
AND WRITE ATTRIBUTE COMMANDS TO SPC-2, by Steve Jerman, dated 10/22/99.
This document has an ANSI T10 document number of T10/99-148r3.

1)  Are READ ATTRIBUTE and WRITE ATTRIBUTE optional commands?

2)  What was the motivation to drop the proposal to support
    MAM access via Log Sense and Log Select?

3)  What is the state of the Inquiry Auxiliary Memory page 84h?

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
        tape drive, but auxiliary memory read/write accesses have failed).

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 and use the 'INVALID FIELD IN PARAMETER LIST'

6)  Page 3, paragraph 1 and page 5, paragraph 1: Since the WRITE ATTRIBUTE
    READ ATTRIBUTE commands use "elements", it would be helpful to
    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
    referring to a device-specific command set (e.g. SMC).

7)  Page 4, paragraph 3:  Is the 'ATTRIBUTE LIST LENGTH ERROR'

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


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.

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

11) Page 7, last paragraph: shouldn't 'WRITE ATTRIBUTE' be 'READ

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?

13) Page 8, paragraph 7: The description of clearing attributes is a little

    confusing.  I have a couple of questions with regard to clearing
    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?
    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)?
    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?

14) Page 8, byte 1 in example at bottom of page: Byte 1 should be 03h,
    not 01h.

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?

16) Page 9: Is the Load Count attribute (ID 0003h) the same as bytes 48-51
    in the Media Usage History Information?

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?

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?

19) If a device supports the READ ATTRIBUTE and WRITE ATTRIBUTE commands,
    is the support of all of the defined attribute ID's mandatory?

- END -

* 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