In future this Group will produce a progress report once a quarter. Its major purpose is to keep members of the Laboratory informed of the Group's work. The literary standard will not be high. It may well be disjoint. It is not intended that this document will have any distribution outside the Laboratory. The structure of the Group is as follows:
Currently attached to the Group is A P Davies, a student. Another student, D Ralphs, will be joining the Group shortly. The work of the Group is approximately split so that PEB is responsible for Operating Systems and Communications while RET is responsible for the Graphics work and also Programming Languages.
Paging was finally installed and accepted at the beginning of January. Up until this time the machine was virtually under the control of ICL.
During January and February the main activity has been familiarisation with George 3 and its associated software. How users adapted to it has been closely observed. There has been activity in providing the ICL software that users have requested. An effort has been made to keep close control over the structure and content of the file store and to ensure the smooth running of the system. During this time progress has been made from version 6.2 of George 3 to 6.4 and from 25 March an attempt has been made to adopt George 4. 6.4 was adopted at the end of February and has proved very reliable.
During the first three months several facts have emerged. Users have learned to use the machine in the most expensive way; that is, by running jobs in an interactive mode rather than by RUNJOBS. This trend is being reversed by setting MOPLIMIT low and by education. Eventually it is highly likely that interactive work will not be permitted at all. It has been found that the machine is surprisingly insensitive to the installation parameters. However, the parameters have been set to values believed to improve efficiency rather than response. For example, only four jobs are normally allowed in core which prevents swapping but there is evidence that this number can be raised without degradation. There has also been a fairly low limit on the number of jobs waiting for core images since these can absorb resources while waiting. This has led to some irritation to users but has probably encouraged the submission of jobs on cards which has given the operators a chance to control the loading of the machine particularly at slack times. It has been observed that the machine's performance is sensitive to the location of certain files. It has been found that performance is improved if certain files are held on drum. It has also been found that performance is severely depressed if the file store is held on the fixed disc.
During the end of February and March, a more active interest has been taken in George. The first experiment has been to put the libraries onto exofiles. This prevents them being dumped so that they are always on-line and it keeps them nicely laid out on a disc track. This also makes restores faster since these files need not be restored. Some efficiency is likely from not having to open directories and files for these items. Lastly, the size of the file store is reduced. The early experiment of putting them on EDS showed a 20% increase in speed of a benchmark of 60 short jabs. This is unlikely to be seen in practice since all jobs in the batch use the same library and the disc heads were stationary on the tracks involved. In practice, the heads can be expected to have a more mobile existence. The libraries were also put on the fixed disc and the performance was almost identical. It was thought that some subtle timing effects may have been at play and, in fact, it is surprising that the times are so close.
The tape-to-tape processor has now been adopted and gives a far better control of the off-line file store since files are not brought on-line when the file store is contracted. The main gains should be the avoidance of backing store jams and the prevention of large dumps.
Some mends to George from Oxford have been adopted. These have allowed some operator commands to be available from MOP consoles and have helped the control of the file store by the accounting programs. These have been adapted for George 4. It is hoped to adopt the Oxford file control program shortly to enable the size of users file stores to be controlled.
It is likely that changes to George will be made as required and to this end expertise in altering George is being developed and a symbolic copy of George is being obtained. In particular, scheduling and operator commands are prime targets for alteration. Close liaison with the 1906A universities is maintained to gain from their experience and developments.
Effort is now available to investigate the high level scheduler. This work is expected to lead to better control of the machine as it becomes more heavily loaded. It may also lead to better methods of submitting jobs which would allow scheduling to be more effective. Nottingham are also active in this area.
Observations of the use of the machine by users are not encouraging. A broad spectrum of software is available which should really be pruned to be in line with the type of service we expect to offer. Unfortunately it appears that this service is a lot wider than first envisaged. We now have provided COBOL and several ancillary pieces of commercial software for State House. There are also several other systems which users have persuaded us to maintain such as FLAIR and JEAN and some decisions should be made as to their support in future. In addition, there is a worrying number of FORTRANs due mainly to the fact that the new versions have faults causing some programs to fail.
The communications system is not complete. Only 4 datel lines are in use, the remaining 3 are waiting modem displays from ICL. The 1200 baud line is also waiting for a modem display as well as a modem and line from the GPO. The high speed line to Belfast is not yet delivered due to the GPO having problems finding a suitable circuit. The line to Exeter is installed but the 7020 will not be delivered there for 2 weeks. A line to State House should be installed later in the year. Some investigation of terminals has taken place in conjunction with Rutherford with a view to standardising on a remote job entry terminal suitable for both sites. Such a joint venture will reduce the price of terminals considerably by bulk purchase and also allow flexibility in the use of terminals for either the 360/195 or the 1906A. A separate exercise in conjunction with State House has taken place to select a terminal suitable for their use. Both the above evaluations have yet to be completed.
The SYSTEM PERFORMANCE package bas been used to collect statistics on the running of the 1906A. At present data is collected every five minutes and written to a file called PERFORMANCE which is listed at appropriate times using the program XK72.
This system has been used to examine both the day-to-day running of the machine and the effect of running a batch of 60 small FORTRAN jobs. The 60 small jobs have proved useful in highlighting the imbalance in demand present in various parts of the initial configuration, and in optimizing some of the system parameters.
The 60 small jobs were test run on Atlas in 8 minutes, an initial run on the 1906A took 49 minutes. This has now been cut to less than 16 minutes. The major cause of this inefficiency is due to overloading of certain parts of the backing store. This problem has been eased, but not completely cured, by moving the LEXICON and MASTER DICTIONARY to the drum, and by assigning the FORTRAN Library to EXOFILES.
Inequality in the size of filestore residences is now causing overuse of one of the EDS cartridges, particularly in the day-to-day running of the machine. We hope to correct this in the near future. We also hope to redistribute the library items to even out the demand on the EDS cartridges.
Backing store conflicts still occur in the day-to-day running of the machine, although less frequently than with the 60 small jobs. It is noticeable, however, that the unequal usage of the EDS cartridges is, if anything, more marked in the day-to-day running of the machine than in the test runs using the 60 jobs.
Mark I of the interface is now available and a data base is set up. There is also a utility which allows user records (and organisation and subject group records) to be added or deleted at a console, and various information in them to be updated or retrieved. This has enabled maintenance of the database to be effectively taken over by Joyce Allenby, using information from the user application forms she receives. Ray Waters will shortly be in a position to use the data base to store and update data concerned with accounting and budgeting; this will be the next major test of the interface.
Work is beginning on Mark II, allowing variable length fields and access by real name (neither is required immediately by the accounting system).
Having familiarised ourselves with the structure of the Hasp Remote Terminal Processor program for the 1130 remote job entry station we inserted the following modifications to incorporate the 1403 lineprinter into the system. Illegal characters were trapped in the system before reaching the printer, thereby increasing the speed of job output and of the core dump produced by the dump and continue processing procedure. The HRTPJ130 program also had to be modified to be compatible with the RHEL 360/195 buffer size, and now that the 360 is operating its remote job entry stations under HASP version 3.0 we have to insert the Ohio State University modifications for the high speed binary synchronous adapter into a new version of the HRTP1130 program. This new version will enable us to alter the system easily when instructed of further changes in the 360 HASP system, although our present system is still operable due to the interfacing on the 360/195. The only other modification to be done after testing the new version of HRTP1130 is to add the TN print chain, containing both upper and lower case characters, after which the system for the present configuration will be complete.
We are still giving instruction to the Operations staff on the running of the system and should have this completed within the next two weeks. As yet no operators have been instructed on the use of the 1130 as a stand-alone machine, which may be required in the future.
Work on this has proceeded throughout the last 3 months; all of the Atlas GROATS package, and the library is now available with the exception of the procedures DRAWFROMTO, DRAWVAR and CHANGEDISPLAY.
The global arrays in the Atlas version have been removed, and the procedures are stored as a library of semi-compiled segments, the required segments being obtained by the consolidator.
There are now the two methods of saving available:
The 1906A GROATS system has been used by a few people (other than the author) with a fair degree of success; those bugs discovered so far have been corrected. At first sight at least, it appears to be significantly faster than the Atlas system, although the procedure VECTOR (and its attendant procedures) are written in Algol on the 1906A and in machine code on Atlas. A run taking 11 minutes on Atlas was completed in 6 minutes on the ICL 1906A.
A version of CAMP is now working on the PDP15. The minor bugs mentioned in the last progress report have been cleared and some other improvements have been made. A few minor enhancements are to be added in the near future. A set of notes detailing the differences between the PDP15 and Atlas version of Camp have been written. They also include instructions for running the program on the PDP15. These notes are written from a user's point of view and are intended to be complementary to the CAMP/CAMPER Manual. They will be issued when the above enhancements have been implemented.
Work has started on implementing CAMP on the 1906A. The Atlas version of the program has been loaded into the 1906A filestore and some editing has been done. It is intended to use some of DCT's PLAN programs from the GROATS package. The GROATS routines for buffering SC4020 commands and writing them to IBM magnetic tape will be used. Also those for writing filemarks to the tape and error messages to the user will be used. A named common block will be incorporated into both the Fortran and Plan routines for the passing of parameters from one set of routines to the other.
It has been proposed that soundtrack production under computer control would be useful for computer produced films. Several ways of doing this have been investigated. The best in terms of complexity and facilities at a reasonable price is to use the VCS3 synthesizer controlled by the PDP15. A paper has been written describing this system. The VCS3 (Voltage Controlled Synthesizer) is an economic and readily available electronic music synthesizer. It is a stand-alone device but its inputs can be controlled by analogue voltages from suitable sources. To use the PDP15 to supply these analogue voltages an interface unit with some digital to analogue converters is required. Just such an interface unit is available from Digital Equipment Co, but at a rather exorbitant price. It is therefore proposed to buy the modules necessary for this interface and wire them up ourselves. A logic diagram of the system has been prepared and is being send to DEC to ensure that it will be compatible with the PDP15. When this has been checked an accurate estimate of the cost of the interface unit and synthesizer will be made. This should be less than £2K.
The tests of the BSI continue. Both computers work perfectly well when transferring data back to back. However, it is not possible to exchange data between the computers.
We now have a suite of programs which work in executive and normal modes on the 1906A to test the use of the link. But the problem seems to be that the computers are unable to recognise each others flags.
The Source operable flag, when raised by the 1906A should cause an interrupt, and does not. Similarly the Source Control Flag when raised by the PDP15 should cause data to be transferred, but no data passes across.
Hardware tests shall continue after the computers are switched on again on 10 April.
New magnetic tape handlers MTA and MTF were obtained from DEC to work under DOS. They are modified versions of the standard handlers, so that the SD4020 tape viewing program may be used under DOS.
The Algol Hidden Line removal subroutines supplied by Dr Brian Heap of NPL have been tested, and work well. They will be given to D C Toll, to be implemented on the 1906A in the near future.
Work has been going ahead on defining a preprocessor for SPROGS. A suggestion for a syntax has been produced.
That it is desirable to have some sort of preprocessor is clear from looking at the examples in the SPROGS manual, which themselves have the word CALL removed. The routine names are undecipherable and standard Fortran does not allow Hollerith strings longer than 4 characters, except in FORMAT statements.
We are therefore designing a language with the following aims:
The project has low priority at the moment as the preprocessor is not useful until the SPROGS subroutines have been written.
One of the influences on SPROGS is our desire to define films interactively. We are in the process of defining how a PDP15 user will see SPROGS.
Our aim is that a PDP15 user will quickly be able to see the effects of his actions. One of the problems that will need experimenting with is getting a sequence play-back in real-time.
Quite a lot of the programming can be done without requiring the BSI link mentioned elsewhere; work should therefore be underway quite soon.
The collection of small routines for the PDP15, mentioned in a previous Graphics Section Report, was completed and a SPROGS paper issued.
F R A Hopgood attended ACM Venice Program Committee in Milan January 1972.
R E Thomas to RXDS Users Group Meeting, Amsterdam
