[Simh] UNIT_RO in simulated units

[Bob Supnik]

Mark Pizzolato pointed out that UNIT_RO is cleared unconditionally at
DETACH. This makes static declaration of a unit as UNIT_RO impossible.
He has proposed a change to distinguish a "static" read-only unit
(UNIT_RO set but not UNIT_ROABLE) from the usual "dynamic" read-only,
set by ATTACH -R or by a unit-specific SET command.

I don't have a problem with this, but I wonder if simulator writers are
using the bit correctly. UNIT_RO was not intended to be a static,
declarable flag. Rather, it was the dynamic state of the UNIT_ROABLE
(unit can be set read-only) flag - just as the UNIT_ATT (unit attached)
flag is the dynamic state of the UNIT_ATTABLE (unit is attachable) flag.
If UNIT_ROABLE is set, and a unit is attached with switch -R, then the
associated file is opened as "rb" (read only) rather than "rb+"
(read/write). An attempt to write data to the file - either from the
simulator console or the simulated device - will fail. On the other
hand, if UNIT_RO is set statically, any associated file will be opened
"rb+" (read/write). While the DEPOSIT command will fail, due to an
explicit test, simulated devices can still write to the associated file.

In short, static UNIT_RO should not be used as shorthand for a
write-protect capability; it will, in fact, not prevent writes to an an
associated file. In general, device-specific write prevention flags
(likedisk write lock flags) should be implemented in the device
simulator code. In my disk simulators, you'll often see constructs like
this:

#define UNIT_WPRT       (UNIT_WLK | UNIT_RO)            /* write
protected */

if (uptr->flags & UNIT_WPRT) /* test for write locked */
        rlmp |= RLDS_WLK;

where WLK is the device/unit-specific write lock flag. This implements
write-locking (from a device point of view) while allowing SCP to both
read AND write the attached file - very useful during debugging.

/Bob

[Paul Koning]

Mark Pizzolato pointed out that UNIT_RO is cleared unconditionally at DETACH. This makes static declaration of a unit as UNIT_RO impossible. He has proposed a change to distinguish a "static" read-only unit (UNIT_RO set but not UNIT_ROABLE) from the usual "dynamic" read-only, set by ATTACH -R or by a unit-specific SET command.

So how does one deal with things like paper tape readers, which are by defition read-only? I've handled that by marking them ROABLE and supplying the R switch in the attach handler.

paul

[Bob Supnik]

Again, the question is whether you want them to be "read only" to the
device simulator or to SCP itself.

Typically, I've wanted paper-tape readers to respond to DEPOSIT, so that
I can make changes or corrections to an input file. The "read only"
nature of a paper-tape reader comes from the device simulator not having
any code to write to the associated file. If you want to block DEPOSIT,
then what you suggest is the correct course of action.

/Bob

Post by Paul Koning

Mark Pizzolato pointed out that UNIT_RO is cleared unconditionally at DETACH. This makes static declaration of a unit as UNIT_RO impossible. He has proposed a change to distinguish a "static" read-only unit (UNIT_RO set but not UNIT_ROABLE) from the usual "dynamic" read-only, set by ATTACH -R or by a unit-specific SET command.

So how does one deal with things like paper tape readers, which are by defition read-only? I've handled that by marking them ROABLE and supplying the R switch in the attach handler.
paul

[Mark Pizzolato]

Again, the question is whether you want them to be "read only" to the device
simulator or to SCP itself.
Typically, I've wanted paper-tape readers to respond to DEPOSIT, so that I can
make changes or corrections to an input file. The "read only"
nature of a paper-tape reader comes from the device simulator not having any
code to write to the associated file. If you want to block DEPOSIT, then what
you suggest is the correct course of action.

Actually, if you never care to use deposit to edit files, then UNIT_RO without
UNIT_ROABLE statically set will only open files "rb". The thing that started this
was work on card readers which are certainly never writable, AND attempting
to edit card image files with deposit commands seems like a steep uphill climb. :-)

- Mark

Post by Paul Koning

Post by Bob Supnik
Mark Pizzolato pointed out that UNIT_RO is cleared unconditionally at

DETACH. This makes static declaration of a unit as UNIT_RO impossible. He has
proposed a change to distinguish a "static" read-only unit (UNIT_RO set but not
UNIT_ROABLE) from the usual "dynamic" read-only, set by ATTACH -R or by a
unit-specific SET command.

Post by Paul Koning
So how does one deal with things like paper tape readers, which are by

defition read-only? I've handled that by marking them ROABLE and supplying
the R switch in the attach handler.

Post by Paul Koning
paul