attached MC Op Codes

Hans Ridder ridder at zso.dec.com
Wed Dec 7 16:01:32 PST 1994


As a developer/maintainer of drivers and applications using Medium
Changer devices, I'd like to add my two cents to the current discussion
of attached Medium Changer devices.

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.

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!

Erich Oetting wrote:
> Bob Snively wrote:
> > I care.  However, I would have expected the Medium Changer and the
> > CD-ROM to have separate LUs and separate INQUIRY data indicating
> > their distinctive character, so it should be a "don't care" condition.
>
> Bob is correct, at least for one implementation.  However, approved
> document 92-006r1 required that MOVE MEDIUM and READ ELEMENT STATUS be
> made common to all device types.  The intent was that any device have
> access to minimal medium changer capabilities, without being required
> to implement a logical unit (LU) just for that task.

What you make easier for the device you make harder (and incompatible)
for the host.  What's the problem with implementing another LU?
Available processor or memory?  It seems like if one is adding all the
hardware/software to support even the simplest robotics, that
implementing an LU would not be a large issue.  (Correct me if I'm
wrong.)

Ralph O. Weber wrote:
>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.

I don't think this is a good idea.  You're adding new operation codes to
fix a conflict created by a change made either: a) to allow simpler
implementation of Medium Changers, b) for systems/software that hasn't
implemented LUNs, or c) devices which don't want to implement LUNs (I
don't know which it is.)

All this simplifying seems to be getting pretty complicated....

Dave Cressman wrote:
>    I have monitored the email on this question with great interest.

Me too!

>    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.  

Creating a special class of Medium Changer just for Seqential Devices
seems ill-advised to me.  I believe it should apply to all device types
or none (and the latter looks better at this point.)

>    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 don't find this a compelling argument for attached Medium Changers.
LUNs aren't some new invention of the committee.  Developers of software
and devices have had plenty of time to figure out how to do LUNs, and
many have.

Also, I don't see how making a change in SCSI-3 will get non-LUN support
for Medium Changers in a "timely way."

>    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.)

This is interesting, but I don't think it means it's good for the
standard.

>    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.

My applications and drivers work with Medium Changers for several types
of devices (Sequential, Optical, WORM, CD-ROM,) and I won't be too
thrilled with writing code for yet another exception just for attached
Medium Changers on Sequential Devices, or for attached Medium Changers
with different opcodes.

>    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.)

I hope it's not too late to make a change.  The attached Medium Changer
concept may have seemed like a good idea at the time, but the downstream
effects seem to, to this observer/user to be getting out of hand.
Writing drivers and applications is difficult enough without having to
support yet another implementation option, which only seems to exist to
make it easier for people who've been ignoring or want to ignore the
existing standard.

Developing software for attached Medium Changers in order to avoid the
LUN issue may initially look attractive, but like many other short-cuts
soon comes back to bite you.  It won't be long before your customers
will want to the software support all those "non-attached" Medium
Changers and the LUN issue come back to haunt you again.

While I hate to say it on my first message to the list, I submit that
it's time to review and retract/remove/recall/unapprove X3T9.2/92-006r1
and bring things back to sanity.

Just the opinions of guy who trys to use the stuff you guys make....

-hans
--
  Hans-Gabriel Ridder <ridder at zso.dec.com>
  Storage Management Software
  DECwest Engineering, Bellevue, Washington, USA
  "I'd rather be writing MACRO-20!"




More information about the T10 mailing list