This reminds me of a follow up DAP question I had about the VOL attribute and interaction with wildcarding. How does VOL interact with the device? Is VOL specifying a volume in a volume set? I'm interested in the case of wildcarding because I don't think I understand the specified functionality regarding device wildcarding, whether it is allowed or not.
What I mean is that, if you have a file FOO.BAR
that exists in the same name directory <BAZ>
on three structures A:, B: and C:,
then assuming you have concurrent access to all three, then this
wild-carded file specification DSK*:<BAZ>FOO.BAR
should get all of them. Locally, it does, but using NFT does
not. However, I thought the DAP specification was neutral in this
area. Is it?
How does VOL interact with this? I think it is for specifying tapes in a volume set. What else?
Regarding the labeled tape support in Tops-20 (and probably Tops-10), in the course of eight years, I saw an incredible growth of functionality and vision. MOUNTR circa 1980 was not particularly robust, having a tendency to crash and otherwise confuse itself. The 6.0 product was a completely different story. You could initialize a tape volume set to have three reels of tape, physically mount all of them (assuming you had that many tape drives) and then the following would happen:
The system would recognize that each reel shared a common volume
name, allocate them to a virtualized tape drive, assign that to
the user and transparently switch between all three. It
was quite cool. More importantly, it prevented the wrong user
getting the wrong tape as this was completely out of control of
the operator. For Tops-20 labeled tape, you could even specify a
user as the tape owner thus insuring that nobody could get it by
mistake.
It supported ANSI, Tops-20 and (I think maybe) EBCDIC
volume labels.
On 4/15/23 8:59 PM, Johnny Billquist wrote:
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.
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