Conference cookie::mru

	The general topic of having MRU do more media management
	is already one or more wishlist items.  I'm taking this
	one off the list.

    Do you have any control of the hardware vendor producing the tape
    library(s).  Why not have a hardware switch or mode select setting
    that allows the "robotics" mechanism to force an unload of the tape
    drive.  The Digital RW series optical jukeboxes contain this feature.
    OSMS does not require it, but it does come in handy sometimes when
    the SCSI connection to the drive gets trashed and it is not accepting
    SCSI commands such as Start/Stop Unit with Eject set and start clear.
    
    Rob

	We can make requests to SEP, who make requirements of the
	vendors of new drives to have things behave in particular
	ways, but this does nothing for existing libraries.  We
	could also lobby SCSI-3 to add a "Force" bit it to the
	Move Medium command, which would allow vendors to build
	drives that allow the feature.  I'm not sure why the libraries
	behave differently in this case and it really is annoying.
	There is probably a reason that *someone* thinks is good.

    Why do you have to eject the meida:

	Many robotic units have no connection to the data transport.  In
	some of the device you can put different types of data transports
	in the same robot.  Remember the video guided ones.

    The eject on move would be nice for SCSI-3 but it's probably too late
    if it's not in there now.  After all, many of the new devices already
    claim SCSI-3.

	Eject in the title is the wrong word here, since the original author
	didn't understand what was really going on.  The underlying problem
	is stupid DLT libraries that insist upon not allowing Move Medium
	commands to move a tape from drive to wherever, without the drive
	first getting a SCSI UNLOAD command (UNIX offline, VMS DISMOUNT/
	UNLOAD).  It would be nice for MRU to be able to ship down the
	UNLOAD in the appropriate operating system specific way, with
	the user having to know the name of the tape drive.

	Unfortunately, too many stupid DLT libraries, can even offer
	the barest clue what the SCSI target to drive association is,
	much less make it easy to figure out the drive/host device
	association.  NSR and other users of mcicap can do this, but
	they rely file editing.  The VMS storage management products
	use tapestart.com.  But MRU has long had a requirement not to
	need those configuration files to work.  So, we're stuck with
	the user having to do the mt(1) or DISMOUNT command themselves.

	The CLI could offer a parameter to do it, but V1.2 had enough
	stuff to go that I didn't even bother mentioning it.  And,
	that would be a solution for the GUI.

    
    Alan,
    
    The 'stupid DLT libraries' is NOT doing spindown on MOVE MEDIUM
    currently due to long history that you are not aware of (when Steve
    Boone was a principal on MRD - pre MDMS). I have polling this issue 
    since we started the program 4 years ago and there was no official
    request from SW group then to have a library doing the drive spindown.
    
    And just happen that our DLT library can communicate to the drive we
    can make this feature available - AND we are planning to add it in as
    you may have seen in my status update. So name calling is uncalled for
    in my opinion.
    
    T.
    
    

	You're right, not allowing Move Medium while the drive could
	be active could have some value.  It is just annoying that
	the libraries and loaders are inconsistent in the feature.
	The feature may also be more desirable by backup software
	that wants some assurance that it won't be easy to move a
	tape out from under it.

	As for some libraries not even providing the barest clue
	what host device is associated with what drive, I think
	that speaks for itself, given that the SCSI-2 spec allows
	offering the barest clue.

	I also realize it could be much worse, having to support
	bare 3rd party device that have had little or no compliance
	testing.