[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