RSX Made Easy

[paramucho]

>> It is configurable (although I don't expect to find many users :-),
>> but I like simple, sensible defaults so that no setup is required most
>> of the time. I haven't found any information about standard
>> directories for tasks etc other than [1,1] and [1,54].
>
>Let's see, from the top of my head:
>[1,1] System libraries and files of general use.
>[1,2] System help files, system command files
>[1,3] Recovered files
>[1,4] System console logs
>[1,6] Errorlog files, and also FAL log files
>[1,54] System executables (system dependent)
>[2,54] Baseline system
>[3,54] System executables (system independent, M+ only)
>[6,54] Standalone system
>[*,10] Sources
>[*,24] Command files to build sources
>[*,34] Listings from builds
>[*,54] Destination task files
>[11,*] Kernel and device drivers
>[12,*] MCR and related
>[13,*] FCP
>[14,*] RMD
>[15,*] Executive utilities
>[16,*] Multiuser utilities
>[17,*] ERRLOG
>[20,*] File system related
>[22,*] MTAACP
>[23,*] DCL
>[24,*] TDX
>[25,*] QMG
>[26,*] BPR
>[27,*] CON,HRC
>[30,*] MAC
>[31,*] TKB
>[32,*] PIP
>[33,*] FLX
>[34,*] VFY
>[35,*] DMP
>[36,*] DSC
>[37,*] EDI
>[40,*] SLP
>[42,*] LBR
>[45,*] K-series
>[46,*] PRT
>[47,*] ODT
>[50,*] FCS
>[55,*] SYSLIB
>[57,*] ZAP
>[60,*] PIPUTL
>[61,*] RSXMAC (RSX macros)
>[62,*] BAD
>[65,*] CRF
>[70,*] VMR
>[74,*] BRU
>[75,*] RCT
>[77,*] ISC,ICP
>[103,*] RPT
>[104,*] ERRLOG control files
>[107,*] CMP
>[111,*] PAT
>[112,*] FMT
>[113,*] IOX
>[117,*] CDA
>[120,*] CRP
>[121,*] LPP
>[123,*] VCP
>[125,*] Shadow recording
>[126,*] Accounting
>[200,*] SYSGEN
>
>Although not as official, [5,*] is usually where DECnet for the running
>system resides.
>
>(Actually, that became a little more than the top of my head, but there
>is more documentation somewhere in the manuals, that we could check if
>you want to.)
>
>> RTX is more or less functional (I can assemble RTX with all the source
>> files and binaries in F11A directories) and I'm adding some bells and
>> whistles while I bed it down. I wrote a couple of apps to call MCR and
>> DCL from within RTX, but I can't do things like DCL MOUNT because of
>> insufficient privilege. Is there some way around this? I've never
>> worked out how to create a privileged image/user etc.
>
>First of all, in which way is things like mount failing? It should
>normally not try to run ...MOU yourself, but instead call MCR with the
>command line, and MCR will invoke MOUNT in the proper way. (Or call DCL,
>same deal.)
>However, MOUNT expects you to either mount a volume foreign, or else
>provide the disk label. You cannot use the /OVR switch without being
>privileged.

I use SPWN$ only to run MCR or DCL, when then call the utilities.
You've isolated the issue though: I was using MOUNT/OVER=IDENT.

I don't seem to need to mount foreign disks--IO.ATT works just fine
within RTX.TSK. In fact, I use IO.ATT for every disk access as it's
the only way I have to determine whether a disk is a mounted F11A
volume or a foreign volume on the system I have at present.

>Also, "privilege" in RSX can be a bit confusing before you get the grasp
>of things. There are several independent things called privilege.
>First of all, your terminal have a "privilege" attribute. This is
>probably the most important kind of privilege there is. All kind of
>commands that looks for "privilege" is looking at this terminal attribute.
>Second is the file system (and regions), which looks at UIC, and any UIC
>with a group number of 10 or less is considered SYSTEM, and goes under
>that protection mask.
>Third is task privilege. A task can be privileged. This decides whether
>the task can do some system calls or not. Things like aborting a task
>running at another terminal requires that the task is privileged.
>
>That's the three things we have to play with.
>In order to run any task, it needs to be installed. In general, only
>privileged terminals can install tasks. There is a special variant of
>install that can be done, which is a flying install, where the task is
>removed again when it finishes. This is what "RUN" do. And this is the
>only way non-privileged terminals can install tasks. One additional
>restriction on this is that non-privileged terminals can only install
>tasks that are non-privileged.
>
>So, for a non-privileged terminal to run a privileged task, it must
>already have been installed by a privileged terminal.
>At this point, it is left to the task itself to decide whether or not to
>allow some operations. So, MOU for example, checks if the terminal is
>privileged or not, and refuses certain switches if the terminal is not
>privileged. However, if you try to run the MOUNT.TSK binary yourself,
>you cannot if you are not a privileged terminal, as the task have the
>privileged attribute set.
>
>A task have the privileged attribute set if, when task built, you give
>the /PR:n switch. The :n can have three values.
>0 - Privileged task with no special mapping
>4 - Privileged task mapped to the kernel in a 16K kernel.
>5 - Privileged task mapped to the kernel in a 20K kernel.
>5 is the default.
>
>The /AC:n switch also implies the /PR switch.
>
>Finally, tasks that are installed in the form of ...xxx or xxx$$$ are so
>called prototype tasks, and cannot be run (under M+). Instead they are
>just templates used by MCR when you give the command, and a copy is
>created which is deleted when the task finishes.

<from another post>

>And of course I forgot one thing. :-)
>When you log in, the login process is privileged, and at the start the
>terminal is privileged. As a step in the login process, if the group
>number of your UIC is >10, your terminal will be set to non-privileged
>at login time.
>
>So, only accounts in groups 10 and lower will have privileged terminals
>when they log in.
>
>And at boot time, the console terminal is privileged. (Otherwise system
>startup would become hard...)

<return>

>Sorry for the long-winded reply, but maybe it helps. :-)

No, that's terrific and gives me the information I need to test the
behavior of privileged vs non-privileged environments as well. I
couldn't find an overview like that in the documentation--I thought
your information was worthy of a dedicated thread. I'll try to use
this thread when I pick your brains about RSX-lore.

I eliminated a couple of problems you mentioned and then found that
the last problem was in my SPWN$ call. I had omitted the optional
physical terminal name, thinking that the call would default to my
terminal. It's functional now, but I'll need to use a virtual terminal
to synchronise RT-11 and RSX terminal idioms: RT-11 terminates an
output line with CR/LF where RSX begins a line with LF and terminates
with CR. The results are a bit messy on the screen when RT-11 and RSX
output is mixed.

I've now installed RTX.TSK as a privileged image for further testing,
but that's not tenable in general practice because it opens the path
to inadvertant potential system destruction. One solution might be to
create a little (non-slave) privileged task, say REX.TSK, which could
take certain specific privileged actions on behalf of RTX.TSK. Later.


Ian