attached MC Op Codes

Dave, 508-770-6877,-6721 05-Dec-1994 1136 cressman at elwood.enet.qntm.com
Mon Dec 5 09:19:43 PST 1994


    Ralph Weber wrote, in part:

>                                                   X3T10/95-103R0
>To:       Membership of X3T10
>From:     Ralph O. Weber           
>          Digital Equipment Corporation
>Date:     December 4, 1994
>Subject:  Attached Medium Changer Operation Codes
>
>During the past few weeks, the SCSI Reflector has hosted a
>discussion about conflicting operation codes for CD-ROM devices
>with attached medium changers.  This proposal, if approved, will
>resolve those conflicts.
>
>I believe that approved document X3T9.2/92-006r1 (Enhancement of
>Command Sets for Removable Media Devices with Medium Changers)
>intended that CD-ROM device be capable of having attached medium
>changers.  However, even in SCSI-2 R10C the MOVE MEDIUM command
>shared operation code A5h with the PLAY AUDIO(12) command. 
>During preparation of the SCSI-3 Multi-Media Commands, we
>compounded this by making the READ ELEMENT STATUS command share
>operation code B8h with the SET CD-ROM SPEED command.
>
...

    I have monitored the email on this question with great interest.

    My understanding is that the reason for X3T9.2/92-006r1 was for 
    Sequential Devices (tape drives) that had an integrated cartridge 
    changer-- a simple Medium Changer & drive.  I think that back then, 
    the idea of CD-ROMs also making use of this idea was more of an 
    after thought.  

    I clearly remember reading some memo or email which explained very 
    nicely how system software & roms were having trouble adapting in a 
    timely way to handling a device that supports multiple LUNs (LUN 0 = 
    tape drive, LUN 1 = MC, for example), and that it would simplify the 
    problem (in some cases at least) to have the drive LUN support a subset 
    of the MC commands.  I haven't gone back and re-reviewed X3T9.2/92-006r1
    since Ralph raised this question, but I expect that's it's consistent
    for sequential devices.  I believe that since the initial motivation
    was from the tape drive market, people didn't carefully check the other
    device type opcode sets for conflicts, specifically CD-ROM.

    Anyway, my company's DLT integrated loader products support this feature
    now, and I'm almost certain some of the DAT integrated loaders do too.
    Also, I believe there is software and maybe subsystem controller firmware
    that makes use of this feature, but I couldn't name any products off the
    top of my head.  (But, could try to dig them up if necessary.)

    Maybe this feature should be limited to Sequential Device types?  It
    hasn't sounded like anyone is implementing MC commands on a CD-ROM LUN,
    based on the reflector mail so far.  If anyone is, or someone knows of
    such work, they should speak up, so hopefully the best decision can be
    made here (but at this point it may be a matter of picking the best from
    a set of bad options.)

    -Dave C.

    David C. Cressman
    Quantum Corp
    DLT (digital linear tape) development
    cressman at elwood.enet.qntm.com

-------------------------------------------------------------------



As a result, CD-ROM devices cannot have attached medium changers. 
In particular, the MOVE MEDIUM and READ ELEMENT STATUS read
element status commands cannot be directed to a LUN with peri-
pheral device type code 05h.  The setting of the MChngr bit in
the INQUIRY data is irrelevant.  The LUN will not be able to
distinguish MOVE MEDIUM from PLAY AUDIO(12) or READ ELEMENT
STATUS from SET CD-ROM SPEED.

N.B. CD-ROM devices may still implement a medium changer as a
separate LUN.  However, the requirement to do this is absolutely
counter to the intent of approved document X3T9.2/92-006r1.  I
believe that X3T10 must either fix this conflict or reverse its
prior approval of 92-006r1.

I propose that the conflict be fixed by assigning different
operation codes to the MOVE MEDIUM and READ ELEMENT STATUS
commands for their attached medium changer usage.  I propose that
Table B.2 of the SCSI-3 Primary Commands be updated as follows:

    OP  DTLPWRSOMCA  Description
 +  BBh OO  OO O     MOVE MEDIUM (attached)
    BBh           O  REDUNDANCY GROUP (OUT)
 +  BFh OO  OO O     READ ELEMENT STATUS (attached)
    BFh           O  VOLUME SET (OUT)

In this proposal, operation codes BBh and BFh are shared between
attached medium changer devices and storage array devices.  I
doubt that there will be any problems with this sharing.  Storage
array devices should embed any medium changers that they support
as LUNs.  Any other mechanism conflicts with the basic concepts
of a storage array.  However, if this operation code sharing is a
problem, a few completely unused operation codes are available in
group 5.

If approved, this proposal also requires equivalent changes in
the Table 5 of the SCSI-3 Primary Commands, changes in all the
SCSI-3 command documents that list the attached medium changer
commands, and changes in the SCSI-3 Medium Changer Commands
document.


================== RFC 822 Headers ==================
Received: from worf-gw.qntm.com by shrdns.tdh.qntm.com; (5.65/1.1.8.2/13Sep94-8.2MPM)
	id AA10937; Sun, 4 Dec 1994 16:20:44 -0500
Received: from ncrhub1.ATTGIS.COM (h192-127-251-16.NCR.COM) by worf.qntm.com with SMTP
	(1.37.109.11/16.2) id AA155846038; Sun, 4 Dec 1994 13:20:38 -0800
Received: from ncrwic by ncrhub1.ATTGIS.COM id aa11365; 4 Dec 94 15:56 EST
Received: by ncrwic.WichitaKS.NCR.COM; 4 Dec 94 14:48:09 CST
Received: by ncrhub4.ATTGIS.COM; 4 Dec 94 15:48:43 EST
Received: by ncrgw1.ATTGIS.COM; 4 Dec 94 15:48:19 EST
	id AA11039; Sun, 4 Dec 94 12:41:13 -0800
Received: from star.enet by us2rmc.zko.dec.com (5.65/rmc-22feb94)
	id AA20942; Sun, 4 Dec 94 15:40:02 -0500
Message-Id: <9412042040.AA20942 at us2rmc.zko.dec.com>
Received: from star.enet; by us2rmc.enet; Sun, 4 Dec 94 15:40:17 EST
Date: Sun, 4 Dec 94 15:40:17 EST
Apparently-To: scsi at wichitaks.ncr.com




More information about the T10 mailing list