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

Device  is 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:

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.