3 Mar
2013
3 Mar
'13
9:34 p.m.
On 03/03/2013 07:14 PM, Jerome H. Fine wrote:
It's my pleasure to help.
In RSTS,
mounting is for mounting RSTS RDS volumes only, to be accessed
by the regular file system. For raw access, you don't have do to
anything,
as long as you have privs. FIT can see the disk already.
I checked the documentation for FIT after Dave McGuire provided
the logical device name (AUXLIB$:) where FIT can be found.
(THANK YOU AGAIN, DAVE!). I do not understand why
direct access to an RT-11 disk is not mentioned. VMS requires
a MOUNT. Probably RSX-11 does as well.
RSTS is a bit different. As John explained, MOUNT is a filesystem
access thing in RSTS, not a device access thing.
In any case, the problem has been solved. BUT, DEC
rarely
seemed to catch up with the extra bells and enhancements
that were needed. EVEN PUTR from dbit has the ability
to specify the PART=n when the RT-11 device is used. Why
DEC never bothered to add that trivial enhancement seems about
par for the course. The same sort of viewpoint exists in the DIR
utility in RT-11. I added value to the '/VOLUME[:value[:value...]] "
switch to support nested directories (eliminating the requirement to
MOUNT the logical disk) where the value is the block number
within the previous directory. Sometimes the solution is so trivial.
Well, think of it this way. FITS is a file interchange utility; most
people used it for things like floppy disks.
In a production PDP-11 installation, I think it would be pretty
unusual to have large (i.e., large enough to have logical disks) RT-11
installation on a drive(s) attached to a RSTS system. It was typically
one or the other.
Since RSTS' RT-11 runtime system gives you most of the facilities of
RT-11 anyway, including running most RT-11 binaries, there's even less
reason to have a full RT-11 installation sitting on another drive
attached to a system that usually runs RSTS.
-Dave
--
Dave McGuire, AK4HZ
New Kensington, PA