This paper outlines some of the changes and additions that ought to be made to RSX PLUS III, as it seems at present.
For the purpose of the paper, the alterations are divided into two. Firstly, those which can be regarded as extensions to RSX to provide features which it was recognized could not be part of the original system. Some of these extensions are more important or simpler to implement than others; so possibly not all of them will be programmed.
Secondly, there are problems which make it difficult to task develop at the same time as using a task. The idea of parallel task development and task execution in RSX Plus (and also of course in RSX PLUS III) is one of the main reasons for obtaining this rather than RSX Phase1.
The main problems are SAVE/INSTALL/REMOVE and the question of what the MCR and TDV user can do.
To recap, INSTALL reads the task binary file and writes it to the disc in a core image form that can be REQUESTED. No task can be REQUESTED that has not previously been INSTALLED. In effect, REMOVE 'uninstalls1' it.
When a task is installed on the disc, then the disc blocks it occupies are recorded in the bit map as being used. The reference to the installed task is recorded in a system list in core; there is no reference in the normal DOS directory. In order to provide a restart facility without having to restore the disc, there is a SAVE command which copies all core to a fixed area on disc. If INSTALL or REMOVE is used without immediately calling SAVE, the copy of the installed-tasks-system-list in the core image on disc is incompatible with the bit map.
A subsequent system crash and restart will result in another crash or the loss of disc blocks. REMOVE in RSX PLUS III has been modified to try to take account of the disc crashes.
There are (at least) 2 consequences. Firstly, system integrity depends on each task developer remembering to use SAVE (even if he had it in TDV). Secondly, a task developer cannot use SAVE while someone else is using a task; this other task might typically be in the machine for ¼-½ hour and maybe longer.
Some suggested solutions. Alan Reid of UKAEA Preston has modified INSTALL and REMOVE so that when the system list in core is modified, the core image on disc is also updated. This works for RSX Plus and Alan Reid claims that SAVE hardly ever has to be used. He has sent his sources. His code would have to be modified before incorporating it in RSX PLUS III. Some systems data is in different places in RSX PLUS III and the RSX PLUS III REMOVE is rather different from the RSX Plus version.
WDS feels that the problem is the disc structure; the Master File Directory does not, even indirectly, point at all the information on the disc; the area occupied by the installed tasks is one of these exceptions. He would want to see the disc structure reorganised so that the Master File Directory is genuinely Master, in particular, so that it points to the installed tasks. This is a more ambitious approach and would take some months.
It may be possible to keep the references to installed tasks in a named disc file as well as in core. The file is updated by INSTALL and REMOVE and used to construct a list of tasks when a "warm restart" takes place.
Someone developing a task will require the full range of system facilities which are at the moment divided between TDV and MCR: FORTRAN compiler, task builder, file transfer etc in TDV; REASSIGN, OPEN, ABORT, system listing commands etc in MCR. Either the task developer uses the MCR console or the TDV console. If using the MCR console, he must have the TDV functions available to him. Also, if he loads a task being tested, it should still be possible to use the MCR. If the task developer uses the TDV console, he must have certain MCR functions available to him. Since some of them alter the system like REASSIGN (change slot assignment) and OPEN (change core location or disc block), there must be adequate protection of one user from another.
While use of the PDP15 is not heavy, one person can use the facilities of DOS and only use RSX to INSTALL and REQUEST this task. But since we are genuinely aiming at a 2 user system, the points in this section (1) should receive serious attention, especially as we were hoping that the ability to task develop in parallel with another task being executed was adequately catered for in RSX Plus (and RSX PLUS III).
RSX PLUS III at present can read/write files in the DOS file structure, but only in the user <RSX>. There is a table in Executive with a disc block number corresponding to each LUN slot; each slot points to a DOS user directory (UFD), (at present RSX in each case). A program will need to be written to alter these slot/disc block assignments; it can obtain the block number from the Master File Directory (MFD).
This is one of our priorities.
There is no VT ON facility as in DOS. It is not such a high priority, but the lack of it in RSX makes DOS a more attractive system for editing, etc. People may prefer to use DOS for editing at off-peak hours, rather than use RSX without the display facility.
To provide a VT ON facility would mean a change to a handler, It is possible to write a special VT handler which can then be used as a text output device. What might be more useful is a text windowing facility which is incorporated in the normal graphics in such a way that it could be used by a standard system program.
We have not settled the question of random access files - whether DOSPIP can access files created by RSX PLUS III.
DEFINE in RSX cannot extend a random-access file unlike DOS. It looks as if a subroutine must be written to extend a file by creating a new one and copying the old into it.
A need has arisen in DOS and will do so in RSX, to be able to cancel an I/0 request. This is not trivial in RSX, since a request to cancel would itself be queued and would not be dealt with by the handler until previous I/0 requests had been completed. It is necessary to work out some method of entering the handler on a high priority basis, like the ABORT mechanism.
REASSIGN does not inform you when a handler cannot be successfully requested owing to its partition being occupied. This is not discovered until an I/O request is made to the handler. To change this would involve changing REQUEST and could well alter the way the rest of the system works.
