| Well, OVMS still runs on VAXen, and those VAXen can still have
ancient media like RM05, RM03, etc. on them...those are removable.
Also many newer systems have floppy drives.
Far as I can see there's no issue with load/unload of these; the
volume label & VOLPRO priv control such things anyhow.
Now, DKdriver's start/stop has never set the LoEj bit, nor has
there been control for such things apart from someone using
io$_diagnose to emit those functions in a SCSI start/stop packet.
This has been known to cause grief with some 3rd party drives in
jukeboxes; some of them require the bit, some require it to be off,
and it would be a convenience to users if they could somehow set
which behavior is used. (In fact something analogous can happen
with tape drives too.) This is simply an artifact, again as far as I
can tell, of history. VMS just doesn't attempt to get anything
specially loaded or unloaded; it will send SCSI start or stop to
spin media up or down, but never an eject separately. This on the
old removable pack devices was all that made sense anyway (images of
RM05 packs flying around a room, destroying anything they collide
with... :-) ). This area would make sense as yet another adjustable
SCSI parameter, but the effort to build infrastructure to support
such parameters is still in its infancy. Till a much later period,
it can't be done.
There is nothing policy wise to prevent a disk from being mounted
without human intervention, and this has been the usual case for the
old pack devices and for floppies, /unload or no. Should it be
difficult to extract the bloody thing from the drive, though,
there is also nothing policy wise which would say that sending a
scsi stop WITH the LoEj bit on would be wrong either. That it
isn't done is not a conscious policy decision; it's just the way
things happened.
|
|
In the case of the RWZ5x drives the OSDS software is the same and
the LoEj bit is always set on DISMOUNT/UNLOAD. The variation is
in the drive firmware control. The RWZ52 will retract and reload
the optical disk onto the spindle while the RWZ53 will not. Optical
hardware and software engineering is trying to determine if their
is a problem with these drives acting different other than the pain
it causes some customers.
Another concern is, "If it was done wrong for the RWZ52, should it
be done wrong on the RWZ53 out of precedence?" Also, what constitutes
wrong?
From a SCSI standpoint after both drives are in the "unload"ed state.
The RWZ52 will complete a START UNIT command while the RWZ53 will
return CHECK CONDITION and "media not present" sense data.
RE: .1 - are you saying that OpenVMS currently allows removable media
disk volumes to be "remounted" with no human intervention if the
mounter's process has the proper priv's. I am only interested in
OpenVMS supported disk devices, not tapes, not optical disk, just the
magnetic stuff that OpenVMS engineering would accept an IPMT case
against.
If OpenVMS doesn't have a rule or precedent then the optical group
can try to just use the SCSI specification for guidance. Even if
OpenVMS has some ideas the optical group will have to create any
possible fixes in the proper place so the drive can be used on non-VMS
systems.
Also, anybody else have input....
Rob
P.S. Our interpretation is that if the device is a desktop SCSI disk
that supports eject with the STOP UNIT command then a VMS "unloaded"
volume requires human intervention, to push in disk, before a
SCSI START UNIT command (or VMS MOUNT) will work. We feel the
RWZ53 is working correctly and the RWZ52 is not.
|
| If you dismount an RM05, even with spindown, and then mount it, it
spins up as I recall. A floppy certainly will spin up; the packack
sends a SCSI start to the thing. No intervention is needed there
since the thing's still in the drive.
Since with RWZ53 the customer could always use dism/nounl, tho,
I doubt the difference in behavior will bother anyone.
|
| > <<< Note 439.3 by STAR::EVERHART >>>
> If you dismount an RM05, even with spindown, and then mount it, it
> spins up as I recall.
My recollection is that once an RM05 was spun down, manual intervention
was required to spin it up again. Perhaps there was a hardware change
to affect this behavior.
The introduction of DSA disks resulted in decreased reliability at the
site where I was consulting because disk-to-disk image backups were
used and it was possible with RM05s under command procedure control
to dismount the "old" disk, start running the "new" disk and have no
fear that an automatic reboot would mistakenly mount the "old" pack
(due to the crash happening just before the batch job modified the
list of which disks were on which drives).
As I recall we switched to a practice of operators interchanging
unit plugs as directed by the batch job, and of course that meant
we could use RA81s as well as RA60s, but it would have been much
better for a program to be able to prevent disk use until there
was human intervention.
|