A meeting of the PDP15 Users' Group was held on 28 September at the DEC London Office in Ealing to discuss RSX-3 with Gary Cole from DEC Maynard. It was convened with the intention of studying RSX-3 in more depth than was possible at the sales meeting that WDS attended in February (see SPROGS Note 17).
In practice, not all the time was spent discussing the extra advantages possessed by RSX-3 compared with RSX Plus. RSX Plus itself was new to many present and those few who are already using it were anxious to beard the lion (Features common to both systems are left to section 4 of this note.) In the main, people who were present are currently using DOS and in one case RSX Phase 1 (this does not include any program development facilities).
The 2 main enhancements in RSX-3 are the Online System Configuration and the inclusion of DOS. The executive as a result goes up from 5½K to 6½K. Online reconfiguration will, I believe, be able to regain this space by using the rest of core better. The inclusion of DOS will not gain us space, but the facility to change between RSX and DOS will be useful in the early stages and in the early stages we will not be too worried about core space. Eventually we may be able to cut out some of the DOS code. I do not foresee the PDP15 settling to the homogeneous usage pattern that would warrant throwing out online-reconfiguration and returning to RSX plus.
In RSX Plus, the system is created with a set of partitions which define the areas in which tasks may run. These cannot be changed without recreating the system. RSX-3 allows partitions to be rearranged by teletype command while the system is running. There are restrictions for the sake of saving executive core usage involved in implementing the facility: these make it a compromise between no partition movement (RSX Plus)and a fully fledged dynamic core allocation system.
The bounds of a partition can be changed if, and only if, no task is loaded in the partition. In other words, no task is ever shunted around in core; if this were allowed, it would be necessary to check that no I/O was taking place in or out of the task space. If the partition bounds can be changed, any task which is installed to run in that partition (partition name must be specified when the task is built) is marked "partition lost" (if the task is too big) or "partition sufficient".
It is also possible to change the assignment of installed-task-to-partition; in other words, the partition name defined at task-building time.
One doubt that has arisen in my mind since is that exec-mode tasks will not be able to run in an altered partition. An exec-mode task runs with relocate and protect turned off and the task core image on disc is already relocated. Handlers have to run in exec-mode, since they have to access addresses outside their partition (ie user tasks and executive). Therefore, in order to run a handler in an altered partition, it is necessary to install a new core-image of the handler. ("Install a task" means create a loadable form of the task on the disc ready for running; a REQUEST command will actually run it.)
While the system is running, it is possible to create more space for system nodes out of a partition area. It is not possible, however, to return this space to a partition until the system is recreated from scratch; the change is irreversible.
It is possible to alter on-line the position of system common blocks (the areas of core which any task can access). There are no checks on whether, at the time, some task is using the space. Every time a system common block is moved, you will get a warning message saying this is dangerous.
The other main change in RSX-3 is the inclusion of DOS and the DOS disc structure. RSX-3 is initially entered by loading DOS and is called from DOS by a system command. RSX-3 can be regarded as a subset of DOS and so DOSSAV is used to copy the disc. This means we will be able to use ½" tapes for dumping, instead of 8 DECtapes! The RSX dump program only allows for DECtape.
Initially, either we will have to keep system programs for both RSX and DOS, or we will maintain both a DOS-oriented system with a cut-down RSX for users and for development work an RSX-oriented system with a cut-down DOS. Since we are soon obtaining more disc, we should be able to accommodate the former. When we move our users onto RSX, we can cut down the DOS system and use the extra discs for data files.
It was commented at the meeting that the DEC handlers for RSX are large and perhaps attempt to do too much for the user. One person present (a user) suggested that more primitive handlers should be the standard; a paper tape handler should handle characters instead of records of characters; a DECtape handler should handle physical blocks instead of logical records. A higher level handler should be available to handle records and be brought in if required. In most cases, I feel we would disagree since, for instance, our normal use of DECtape is in a filing system with logical records. PIGS, however, uses the keyboards in a character-by-character fashion and the record structure of the handler is rather wasted.
On the general point of size of handlers, Gary Cole outlined the jobs which each handler has to do:-
(1) Receive I/O requests from any number of tasks. The handler must contain code for obtaining a request off a queue and decoding the request. The handler checks that the addresses are sensible.
(2) Implement I/O requests. The following is a minimum for any handler:
HINF - handler information, normally trivial to implement
READ and/or WRITE
DISCONNECT - this is a command to the handler to close itself down and stop.
ABORT - this a request made by the system, when a task exits; tells the handler to closedown I/O for the exiting task, The onus is on the handler to. search its request queue for I/O requests from the exiting task.
(3) Signify to the executive and the user task that the I/0 request has been dealt with (via an event variable).
(4) Deal with the device itself.
Of these (1), (2) and (3) involve the interaction between handler and executive and the handler and user task. It may be worth studying the code of the handlers to see whether a significant body of common code could be put into executive. We must remember that this is an integer programming problem (since partitions are multiples of 256 words) and so avoid reprogramming to no effect.
Version 44 of the DOS FORTRAN will be released with RSX-3.
Changes are as follows:-
(1) There is now greater freedom in the use of arrays or array elements in calls to a subprogram.
(2) Addresses of array elements are evaluated in line in the compiled code; previously a subroutine call has been used.
(3) The size of an array in COMMON now has an upper limit of 32K.
The previous limit of 8K was due to some trivial reason in the compiler. The new limit is of course dictated by the range of indirect addressing.
Changes:-
(1) The batch stream can be run from the disc; before, it was only possible to run off paper tape or cards.
(2) It is possible for a running task to add a job to the batch queue by means of a CAL directive QJOB.
