attached MC Op Codes
JLOHMEYE at cosmpdaero.ftcollinsco.ncr.com
Thu Dec 8 15:39:00 PST 1994
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
>John Lohmeyer wrote:
>>"Ralph Weber -- VMS -- ZKO3-4/U14 wrote:"
>>> The current operation code usage of the SET CD-ROM SPEED defeats this
>>> 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
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 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
More information about the T10