16 Apr
2023
16 Apr
'23
2:59 a.m.
In the context of RSX (or VMS), it won't work. A mount cannot be allowed
to exist without it either being a public (ie. system) mount, or else be
associated with a terminal and a logged in session. DAP simply do not
have that context, and never can work in that way. Because public mounts
are a privileged operation that normal users cannot do, and a private
mount is not possible without a terminal context.
As far as tapes goes, RSX is a little less flexible than TOPS-20 (I
really love what TOPS-20 does here). You can request a mount and have
the operator actually physically mount the tape, and then make the mount
operation complete, but the user have to know which drive the tape
should be mounted on, and it will have to be mounted on that specific
drive. No way of asking a tape to be mounted on any drive, and get back
which drive it was mounted on. But it's completely impossible for
multiple users to concurrently access a tape. Tapes have a physical
position, which would become very weird or broken if two users were
allowed to access it concurrently.
Johnny
On 2023-04-16 02:44, Thomas DeBellis wrote:
You've put your finger /exactly/ on another
concern that I had been
thinking about. If you are doing a bunch of in-behalf mounting, then
_every_ access is going to result in a mount charge, which you have to
know to expect because you are not notified. If you do a bunch of
copies, then you are going to get hit with a bunch of charges which
would not happen if you were signed into said 20, using NFT and
explicitly managing the mounts.
It seems to me that it would be a good idea to issue some kind of
friendly message that this happened. I don't immediately known how to
do that with DAP (I do with FTP and Kermit). At a minimum you might
want to set your user's expectations to let them know that they are
getting charged for all this 'friendliness', maybe with training or some
introductory email.
Right now, I'm working on wildcard searches that have to mount
structures when they come into scope, and dismount when the wildcard
goes past the structure. Tops-20 allows a limited form of this (viz,
DSK*:), but doesn't generalize structure wildcarding like Tops-10 does
(which I have always thought an odd limitation).
The hidden charging problem doesn't quite happen in FTP because it is
explicitly known as you must issue an SMNT to get a structure mounted.
What's interesting is that RFC959 never specified a verb to do the
structure dismount, which you would want to do to save the charges if
you got billed for the duration of the mount. I'm pretty sure we
charged for that.
If you want to use a couple of structures, then you are incurring online
charges for all of them at once because there is no way for them to get
released until the FTP session terminates. /Unless/ ... Your FTP
happens to support the DSMT verb, which I explicitly created for this
purpose, way back when (and still have to get off my butt to put into an
RFP).
You might be able to get tape mounts to work, at least on Tops-20 (and
if so, probably Tops-10). Tape mounts on Galaxy can be quite
transparent, provided you are using labeled tapes. If the right one is
online and you are using automatic volume recognition (AVR), you would
specify the tape label as the device and the tape gets automatically
mounted for you with the label as the logical name, which parses exactly
like a device.
In other words, tape FOO shows up as psuedo-device FOO:. It's notquite
a hack, but perhaps close enough. You can also specify the tape to not
auto-dismount, so it would stay on the drive still ready with the same
label for you to use again. I repeatedly used this when debugginga
batch job to write a Kermit tape. The tape just stayed on the drive
while I kept trying to get it right...
Otherwise, I don't see how you would request a tape mount with DAP nor
explicitly do a dismount.
--
Johnny Billquist || "I'm on a bus
|| on a psychedelic trip
email: bqt(a)softjar.se || Reading murder books
pdp is alive! || tryin' to stay hip" - B. Idol
------------------------------------------------------------------------
On 4/15/23 8:11 PM, Johnny Billquist wrote:
Thinking a moment further, I should perhaps expand a bit on this...
So, mounting of tapes are always non-shared (for obvious reasons). So,
if someone mounts a tape, anyone else trying to do anything with that
device is just going to be hanging until the first user is finished
with the tape and dismounts it.
Disks on the other hand can be mounted shared. However, unless mounted
public, each user needs to mount the disk in order to access it. (So
yes, a disk can be mounted multiple times, by multiple users/sessions.)
Now, mounting is actually associated with a logged in session (or more
specifically a terminal). If you mount something, it remains mounted
until you explicitly dismount it, or you log out, at which point it is
forcibly dismounted.
This is basically incompatible with how DAP works, where you basically
access a file for the duration of that connection. And one connection
usually means open a file, do various operations, and then close the
file. So if you copy two files from one system to another, it is two
independent sessions as far as DAP is concerned.
So there is no way to access content on a not-mounted device via DAP.
How would that work? If you were to be able to request a mount, it
would be associated with a logged in session, but in this case that
don't exist (unless we talk about the session on the remote system).
So if you were to mount, at the end of the mount request, there would
be an implicit forced dismount again. If the next thing you wanted to
do was to copy something from the mounted device, it would already
have been dismounted again, and content would no longer be accessible.
Basically, in RSX, you are only able to access content on publicly
mounted devices for this reason.
Johnny
> ------------------------------------------------------------------------
> On 2023-04-16 02:01, Johnny Billquist wrote:
>
> Mounting in RSX is pretty much identical to VMS.
>
> And there is no way to mount things over DAP as far as I know. But
> I'd be interested in any information related to that.
>
> Johnny
>
_______________________________________________
HECnet mailing list -- hecnet(a)lists.dfupdate.se
To unsubscribe send an email to hecnet-leave(a)lists.dfupdate.se