All the references to ^P and ^G were what threw me. Neither of those key inputs has any impact on my system. I just needed confirmation that "setting switches" was indeed a memory location deposit (per my note above that mentioned ODT) as opposed to an interactive software operation (e.g. typing 'SET blah, blah at the command line). Again, this probably seems silly to anyone who has a background in these systems but it certainly wasn't obvious to me coming in cold. In a couple of cases I have been successful in changing behavior of the test by patching under ODT followed by @200G to restart the test. In other cases setting bits had no apparent effect, but I'm not going to worry about that at the moment.
The underlying problem: I'm finding that after the unit has been on for a while, a number of the processor and memory tests HALT spontaneously into ODT with a printout of:
000010
@
Since I see this exact printout on a number of different tests, I'm not convinced it's a test fail, per se, but perhaps an indication of something more low level that's broken. Once the system starts HALTing out of the tests, I reboot into RT-11 and run 'IND VERIFY' to compile and link IVP.MAC. This works when run immediately after cold start, but will now abort with:
?MON-F-Trap to Trap 10 010500
(Always the same numbers). What's the best approach to getting at the underlying problem?