attached MC Op Codes

Devon Worrell 714-932-7042 worrell at
Mon Dec 12 10:42:38 PST 1994


I just wanted to comment on the focus being only SCSI. I believe that
the attached CDROM changer type device is being looked at with
interest for use in the ATAPI environment. As you all should know,
the ATAPI environment doest not support LUNs. Thus the opcode and
attached changer issue is a real problem. There must be different
opcodes for all attached changers and ATAPI CDROM devices.

On Dec 8,  4:39pm, Lohmeyer, John wrote:
> Subject: re: attached MC Op Codes
> Hans-Gabriel Ridder wrote:
> >Note that I never seen X3T9.2/92-006r1, so just slap me if I'm way off
> >base on anything, but I'm not too thrilled with what it appears to be
> >doing to the standard.
> I am sending a copy of the document to you by separate email.  If anyone
> else wants a copy, drop me a note.  It is also on the SCSI BBS as
> 94-006r1.txt.
> >John Lohmeyer wrote:
> >>"Ralph Weber -- VMS -- ZKO3-4/U14 wrote:"
> >>>
> >>> The current operation code usage of the SET CD-ROM SPEED defeats this
> goal
> >>> for CD-ROM devices.
> >>
> >>Perhaps a way out of this box is to define a new and/or optional opcode
> >>for the READ ELEMENT STATUS command in the attached medium changer model.
> >
> >So now every time I want to do a READ ELEMENT STATUS I first have to
> >check to see if it's an attached Medium Changer and send one of two
> >opcodes?  No thanks!
> Actually, that isn't quite what I had in mind.  In fact, I did not expect to
> see drivers written to deal with both attached and non-attached medium
> changers, but I do not want to preclude such drivers if they are indeed
> useful.
> The intent of the committee decision to support attached medium changers was
> to simplify life for low-end changer applications.  The SCSI-2 medium
> changer model uses a separate LU (perhaps on a separate SCSI device) from
> the one or more LUs that read and write the medium.  This permits an
> elaborate functionality with multiple robotics and more than one read/write
> device per changer.  But there is no defined way for an initiator to
> discover (through the interface) the association of the separate LUs.  This
> association is changer and/or system specific.
> The intent of the attached medium changer model was to permit simple changer
> devices to share the same LU with the read/write device.  This solves the
> association problem and enables some simple changer products (e.g., a device
> with 6 pieces of media and a single CDROM reader).  These products can share
> a single SCSI protocol chip and a single processor between the changer
> function and the player function.  They will happen (have happened?) whether
> or not we choose to document them.
> The problem we were attempting to solve is the association problem, not the
> inability of some systems to cope with nonzero LUNs.  Of course, this
> solution also helps with that problem.
> A second problem that was being addressed was the need for a separate medium
> changer driver.  The attached medium changer model was simple enough to
> imbed the changer control in the device driver.  This is why I did not
> expect common driver software.
> If common drivers are really likely to happen, then I'd suggest that we
> create a new opcode for the READ ELEMENT STATUS command that is valid (and
> recommended) in both models.  The pain of picking which opcode to use would
> still occur for a driver that must work with both SCSI-2 and SCSI-3 changer
> devices, but after a few years, we would all be using the new opcode.
> John
>  --
> John Lohmeyer                      E-Mail:
>  John.Lohmeyer at FtCollinsCO.NCR.COM
> NCR Microelectronics                Voice:  719-573-3362
> 1635 Aeroplaza Dr.                    Fax:  719-574-5462
> Colo Spgs, CO 80916              SCSI BBS:  719-574-0424 300--14400 baud
>-- End of excerpt from Lohmeyer, John


"Every truth passes through three stages before it is recognized.
 In the first it is ridiculed, in the second it is opposed, in the
 third it is regarded as self-evident!"

    _/_/_/_/    _/_/_/_/    _/      _/ | Devon B. Worrell <worrell at>
   _/      _/  _/      _/  _/      _/  | Senior Principal Engineer
  _/      _/  _/_/_/_/    _/  _/  _/   | Western Digital Corporation
 _/      _/  _/       _/ _/_/_/_/_/    | 8105 Irvine Center Drive
_/_/_/_/    _/_/_/_/_/  _/      _/     | Irvine, CA 92718
				       | Host Interface & Technology Staging
				       | Phone: (714) 932-7042
				       | Fax:   (714) 932-7796

"Not speaking in an official capacity for my employer"
"Void where prohibited by law"
"No refunds--all sales are final"
"Does not include CA Redemption Value"

More information about the T10 mailing list