Mounting devices with DAP?

List overview All Threads
Download

newer

older

Announcing TCP/IP V2.12 for...

Re: FORTRAN-IV

Thomas DeBellis

16 Apr 2023 16 Apr '23

1:45 a.m.

The DAP 5.6 specification (28-Mar-1980) does not appear to have much information concerning device mounting. It's not clear how much DAP was designed to be concerned with such activities, but it would appear that it implicitly expects that any device that is available is usable. There are some bits in the File Access Options (FOP) and Generic Device Characteristics (DEV) attributes that have some information concerning mounting, viz: *Attribute* *Bit* *Name* *Meaning* FOP 13 FB$DMO Rewind and dismount magnetic tape on close. DEV 10 FB$MNT Device is currently mounted. DEV 11 FB$DMT Deviceis marked for dismount. So assuming you are accessing a magnetic tape, you can request that it be rewound and dismounted when closed and you can get some information concerning mount status. At this time of DAP design, large systems basically lived on tape and disk mounts, given the expense of the devices to actually read and write their respective media. There was a cost for a mount, but if you were using a lot of space, it could pay to have your own media where you wouldn't get hit with the storage costs. Mounting structures is also a well understood mechanism to provide additional access control granularity. A "regulated" structure on Tops-20 can not be used unless it is first mounted by the user. It may be spun up and online, but if it is regulated, you must mount it first. This gives you the opportunity to put policy on the mount with an access control request. At Columbia, nobody was allowed to mount the (regulated) staff structure (CU:, an RP07) unless they were staff. Students were not allowed to mount anything. Paying customers could mount non-domestic regulated structures. I wrote the code for the 'Judge', our access control job (or ACJ) which did this as it required some hooks in Galaxy (Quasar and MOUNTR). FAL is not subject to such ACJ policy because it specifically informs Tops-20 to by-pass mount counts. So that's kind of a back door because you could use FAL to snoop around regulated structures, which is exactly what we didn't want to be happening. It bothered me, but not enough for me to tell management that it should be addressed. I was fixing a bug in FAL ANONYMOUS processing when I recalled this and it began to bother me more. I don't want regulated structures being implicitly used. My extended mode FTP server does not bypass mount counts and this is what keeps web crawlers from snooping through every file I have. You have to explicitly know the structure name and request it with an SMNT verb which you can then put policy on. So I scratched the itch and implemented a MOUNTING command with the following options: * BYPASSED, the current FAL behavior: use whatever is online. * PREVENTED, respect regulated structure mount counts and fail if the structure isn't mounted. * AUTOMATIC, attempt to mount the structure on the behalf of the user where necessary. PREVENTED is the most restricted, as a FAL job only has access to unregulated structures (which require no mounting). So that's good. AUTOMATIC maybe gets you the best of both worlds. You can access online structures provided policy allows you to, elsewhere which means that users that expect to be able to mount structures will have this done for them. I have yet to put in another command to restrict ANONYMOUS usage, in other words, forbid automatic mounting for ANONYMOUS. Is my reading of DAP is close enough? How do other DEC operating systems handle this? I know VMS can handle disk and tape mounts, I forget about RSTS, RSX and RT.

Attachments:

attachment.html (text/html — 20.9 KB)

Show replies by date

Johnny Billquist

16 Apr 16 Apr

2:01 a.m.

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 On 2023-04-16 01:45, Thomas DeBellis wrote:

...

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

Johnny Billquist

2:11 a.m.

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

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

Thomas DeBellis

2:44 a.m.

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 not quite 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 debugging a 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 >

Johnny Billquist

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.

_______________________________________________ HECnet mailing list -- hecnet(a)lists.dfupdate.se To unsubscribe send an email to hecnet-leave(a)lists.dfupdate.se

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

Thomas DeBellis

17 Apr 17 Apr

9:40 p.m.

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. I can't remember whether VMS supported this at the time we were considering it. Ultrix didn't. There were some third party products, but they didn't have the full functionality. I believe z/OS (née MVS) and maybe z/VSE (née OS/360) would do it, though. We ran both, but they were a poor fit for our academic requirements. I forget about z/TPF (née TPF) and z/VM (née VM) although we did run the latter.

...

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

Johnny Billquist

11:26 p.m.

Most of the functionality you describe is equally possible under RSX, and therefore I would assume VMS as well. You can have labelled tapes that are whole sets, which you mount together. But with regards to DAP, RSX do not support wildcarding of devices at all, and as far as I can remember, neither to VMS. And so I seriously doubt DAP supports that idea either. Johnny On 2023-04-17 21:40, Thomas DeBellis wrote:

...

This reminds me of a follow up DAP question I had about the VOL attribute and interaction with wildcarding. How does VOL interactwith the device? Is VOL specifying a volume in a volume set? I'minterested 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. I can't remember whether VMS supported this at the time we were considering it. Ultrix didn't. There were some third party products, but they didn't have the full functionality. I believe z/OS (née MVS) and maybe z/VSE (née OS/360) would do it, though. We ran both, but they were a poor fit for our academic requirements. I forget about z/TPF (née TPF) and z/VM (née VM) although we did run the latter.

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

_______________________________________________ HECnet mailing list -- hecnet(a)lists.dfupdate.se To unsubscribe send an email to hecnet-leave(a)lists.dfupdate.se

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

Thomas DeBellis

25 Apr 25 Apr

12:13 a.m.

After I got done 'enough' with the modifications to Tops-20 DAPLIB to support auto-mounting and dismounting of regulated structures, I turned to putting the indicated hooks into the ACJ to catch the mount requests and was quite surprised to find something. There are two types of structure mounts on Tops-20, job-wide (.MSIMC) and fork-only (.MSICF), the difference between the two being that if you do the former (.MSIMC), any fork in the job can get a JFN on a file in the structure while the latter (.MSICF) only allows the fork that did the mount to do it. As currently architected, Tops-20 FAL is a multi-forking server, so it can't do a job-wide structure mount as that would allow other forks in the job to access files on a regulated structure, thus by-passing accounting and access control. "No problem", I thought, "I'll just use .MSICF to do the fork mount." I was looking forward to that because I don't recall ever seeing it be done by anything. Galaxy (MOUNTR) doesn't support fork-only mounts, which is where mount requests are almost universally handled. Nothing like blazing new trails four decades after the fact! Boy was I surprised to find that the monitor only provides a hook (.GOSMT) for the job-wide case! That's right, if you do a job wide mount and either use Galaxy do it for you or do it yourself with .MSIMC, the ACJ gets control. Do it fork-only by yourself with .MSICF, and the ACJ doesn't know anything about you... I'm not sure that I'm thinking about this the right way, but right now it is just plain peculiar. A quick search through all my sources shows why I never saw this back in the day: there isn't anything that does use .MSICF, so no help there. Of course, I'm certainly not above putting another ACJ hook into the MSTR% JSYS, but before I go get into that, I thought I'd ask about it. Why would you hook a job-wide structure mount and not a fork-only one when the purpose of the hook is to determine whether policy allows you to do a mount? Puzzled, --T

...

------------------------------------------------------------------------ On 4/15/23 7:45 PM, Thomas DeBellis wrote: The DAP 5.6 specification (28-Mar-1980) does not appear to have much information concerning device mounting. It's not clear how much DAP was designed to be concerned with such activities, but it would appear that it implicitly expects that any device that is available is usable. There are some bits in the File Access Options (FOP) and Generic Device Characteristics (DEV) attributes that have some information concerning mounting, viz: *Attribute* *Bit* *Name* *Meaning* FOP 13 FB$DMO Rewind and dismount magnetic tape on close. DEV 10 FB$MNT Device is currently mounted. DEV 11 FB$DMT Deviceis marked for dismount. So assuming you are accessing a magnetic tape, you can request that it be rewound and dismounted when closed and you can get some information concerning mount status. At this time of DAP design, large systems basically lived on tape and disk mounts, given the expense of the devices to actually read and write their respective media. There was a cost for a mount, but if you were using a lot of space, it could pay to have your own media where you wouldn't get hit with the storage costs. Mounting structures is also a well understood mechanism to provide additional access control granularity. A "regulated" structure on Tops-20 can not be used unless it is first mounted by the user. It may be spun up and online, but if it is regulated, you must mount it first. This gives you the opportunity to put policy on the mount with an access control request. At Columbia, nobody was allowed to mount the (regulated) staff structure (CU:, an RP07) unless they were staff. Students were not allowed to mount anything. Paying customers could mount non-domestic regulated structures. I wrote the code for the 'Judge', our access control job (or ACJ) which did this as it required some hooks in Galaxy (Quasar and MOUNTR). FAL is not subject to such ACJ policy because it specifically informs Tops-20 to by-pass mount counts. So that's kind of a back door because you could use FAL to snoop around regulated structures, which is exactly what we didn't want to be happening. It bothered me, but not enough for me to tell management that it should be addressed. I was fixing a bug in FAL ANONYMOUS processing when I recalled this and it began to bother me more. I don't want regulated structures being implicitly used. My extended mode FTP server does not bypass mount counts and this is what keeps web crawlers from snooping through every file I have. You have to explicitly know the structure name and request it with an SMNT verb which you can then put policy on. So I scratched the itch and implemented a MOUNTING command with the following options: * BYPASSED, the current FAL behavior: use whatever is online. * PREVENTED, respect regulated structure mount counts and fail if the structure isn't mounted. * AUTOMATIC, attempt to mount the structure on the behalf of the user where necessary. PREVENTED is the most restricted, as a FAL job only has access to unregulated structures (which require no mounting). So that's good. AUTOMATIC maybe gets you the best of both worlds. You can access online structures provided policy allows you to, elsewhere which means that users that expect to be able to mount structures will have this done for them. I have yet to put in another command to restrict ANONYMOUS usage, in other words, forbid automatic mounting for ANONYMOUS. Is my reading of DAP is close enough? How do other DEC operating systems handle this? I know VMS can handle disk and tape mounts, I forget about RSTS, RSX and RT.

580

days inactive

589

days old

hecnet@lists.dfupdate.se

Manage subscription

7 comments

2 participants

tags (0)

participants (2)

Johnny Billquist
Thomas DeBellis