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
_______________________________________________
Simh mailing list
Simh@trailing-edge.com
http://mailman.trailing-edge.com/mailman/listinfo/simh
