There have been no changes in the Group's membership since the start of the quarter. G A England leaves on 1 February to take up an appointment at Imperial College. The present staff comprises:-
Modifications to the DCP program in the 7903 are still proving difficult as we still have no means of recompiling the program. A new version of the DCP was delivered during the quarter. Once more it came without adequate loading instructions so that time was wasted attempting to discover a method for running it. However, once loaded, it did contain the ALTER facility (this had been removed in the previous version) so that minor alterations to the program are once more possible. We now have a correct specification of the loading program and a new macro is being written. A by-product of the testing of the Imperial link was the discovery that it was possible to alter the 7903 code in the 1906A before loading it. This does involve adjusting check sums and studying binary dumps so is not very satisfactory. It does however provide an alternative to the ALTER facility if this gets removed again.
The major problem associated with the 7020's during the quarter was with the Belfast link. As a result of moving the 7020, the characteristics of the Belfast line changed significantly. This required a number of modifications and adjustments to be made. The Sussex Datel 200 link is now installed but does not work. The GPO have been informed but do not appear to be doing anything to repair it. The proliferation of links to the 1906A has resulted in a large number of hand-sets associated with them. It is hoped to arrange with the GPO a method of keeping these down to a manageable number. The only local hardware that is inoperable is the modem display on Modem No 7. This is not essential to the State House link but will be necessary for the switched 2400 baud link.
All the known software problems have now been solved and the 7903 interface has been successfully tested using Sigma 2 in place of the Imperial hardware (Sigma 2 has proved extremely useful on a number of occasions for communications testing of this type). Some very elementary tests over the link to Imperial have been made. There is one outstanding hardware problem which Oxford University are investigating for us. This concerns the setting of the flip-flop, link F, in the 7903 and time-outs. If F = 0 then time-out is after 50 msecs. If F = 1 and the speed is less than 600 bauds then the time-out is done by software in the same way as it is done on the teletypes. However if the speed is greater than or equal to 600 bauds then the interface is synchronous. As the Imperial link is asynchronous we have to run with F = 0 and the automatic hardware times-out after 50msecs. To avoid time-outs it is therefore necessary to send data continuously rather than character by character.
The purchase of GEC 2050 terminals to be used as RJE stations to the 1906A has meant that a 7020 emulator is required for the 2050's. A 2050 simulator is available on RHEL's 360/195 and this can be used for software debugging. FVS has spent part of the quarter getting familiar with using the 360/195 and ELECTRIC. Work has now started in defining the emulator and coding should soon take place. The aim will be to continue using the 360/195 simulator and transfer to the 2050 itself at a later date. The first 2050 should arrive in the Laboratory some time in January.
A number of projects are proceeding in parallel whose aim is to improve the performance of the 1906A in a variety of ways. We are still worried by the small percentage of total CPU utilisation which is available to user programs. Some improvements have been made by changing GEORGE parameters. In addition attempts have been made to schedule work to avoid conflicts which result in high idling time. The other main aim of the scheduling is to provide an adequate turnround of small jobs while still allowing background work to proceed. A major problem with operating systems of the complexity of GEORGE 4 is to provide operating staff with meaningful information as to how the machine is performing. The hardware monitor and printouts from the scheduler have been designed for this purpose.
The planned Mark 6 version is now complete and further developments will probably be left until Mark 7. The chief features implemented over the period are:-
Numbers of jobs processed are being output to the performance file (the advent of the System Journal will make this unnecessary).
Documentation is being produced on HLS implementation.
GEORGE mends connected with scheduling were:-
Work is in hand to produce an artificial job generator on the 1906A; this will produce jobs of any required behaviour. It was originally intended to test certain aspects of performance (notably multiprogramming efficiency) although it is now hoped to use it to establish weights on CPU time, file store transfers etc, and for charging and scheduling (thus additional quantities will be added into JOBTIME). A proposal for a method of rational justification and determination of such weights will be prepared. A new significance of JOBTIME could be its effect on the user view of the system.
The hardware monitor has now been installed. It currently displays every 1 or 10 seconds the percentage CPU time spent in object programs. Any abnormally low reading for a period of time therefore indicates to the operator that some action may be necessary to cure the situation. A second display will be available to indicate the time spent in executive. This is not yet operational as it requires a component to isolate voltages in the 1906A from the hardware monitor. Installation of the monitor was not completely without incident. Two accidental blowings of 1906A fuses occurred when some minor modifications were made.
At the moment there are a large number of modifications to GEORGE and library software needed to improve the total service on the 1906A. Although each one in itself does not improve the user's view of the system much, the total effect over a quarter is quite significant. This effort is likely to continue for some time in the future. The introduction of Mark 7 will almost certainly mean a large amount of work of this type.
The following items of software from Leeds University have been implemented:-
Some attempt has been made over the quarter to reduce the size of the major system directories. These need continual policing to ensure that entries are not added indiscriminately by users without the necessary privileges. The security of the system is not as high as one would like.
GWR has managed to reduce the size of :MACROS to 55 by erasing or moving various entrants. The directory has been re-ordered in an attempt to optimise the accessing of frequently used macros. Similar exercises by PK, PEB, RCP and CJP on other directories have resulted in a considerable saving.
A technical notice has been written which explains the known differences between the actions of COPYOUT and COPYOUTOLD and of COPYIN and COPYINOLD. The format of the various sentinels on the magtape are explained for files of different peripheral types. Cases where COPYOUT and COPYIN are known to fail are also given.
This paper has been issued now although the implementation of Mark 7 may cause the contents to be reviewed.
The LSTR macro for structured directory listing has been enhanced to count blocks and entrants.
The LIST command on the GERONIMO system has been removed in the interests of security. Also, the frame overflow message to the Operators' Console has been suppressed. Major modifications will be very difficult in the absence of the source code, and none have yet been attempted.
The GIVE6 extracode has proved adequate for tracing GEORGE chains and the information as to what magtapes are wanted at any time is available. This information is intended to be added to the GERONIMO DECK command. A program has been written to examine GEORGE's activity waiting list.
A macro FORTIDY has been released. This is used to generate lists of variable labels, etc, used in a FORTRAN program. Initial user response suggests that the user need is not quite the same as the original specifications and work is proceeding.
An investigation has been made to decide how much sharing of code exists for major pieces of software like the FORTRAN compilers. Although it is possible for these to be shared by more than one user, the evidence is that this is rarely happening. However code of this type does remain in the core for long periods. That is the code is used again before it has had time to be deleted. In one case a piece of code remained in core for at least 18 hours.
A study of the feasibility of driving the compiler/consolidation system by a user program gave satisfactory results and implementation of such a technique has commenced. The resultant COMP macro should compile, consolidate and run the binary for Algol, FORTRAN, PLASYD and PLAN programs.
The benefits of this macro should be faster turnround of short. programs and improved facilities for the user.
The PLAN preprocessor alluded to in the Progress Report for April to June has now been written up, and the PLAN macro extended to cater for this, as well as one or two other facilities.
A great deal of effort has gone into the design of the sequence list and the provision of local and global variables. The former allows a user, to specify more than one film segment to be processed, allowing the Advance Film order to control the list.
The problem arises in deciding what is local to an item on the list and what is common to all items, ie, to what extent changes to variables in one item will alter the effect of others. The solution finally adopted may well have to be changed in the light of experience.
Initially, only global variables, which could be stored in files and given values when the file was used, were defined, but it was felt necessary to widen the concept. Hence, variables which are completely local to a file (and so can be used as workspace during execution) have been defined. A new stack for such variables has been created to avoid clashes caused by the same file appearing in more than one item in the sequence list (a quite likely event). An argument-passing mechanism has also been chosen so that it is possible to preset local variables, and to obtain results from files.
The decision was also taken to use text names rather than numbers to reference variables, so that library routines, for example, could avoid clashes with user routines. Since the use of names in this way removes any sense of adjacency, the array reference mechanism has been altered. It is now necessary to give the names of the three variables which specify file name, file number and position in file when data from a file consisting only of NULLs is required.
The DRAW command has been implemented and users can define files and execute them at a later date. Only one item can be on the sequence list at a time, however. All the file packing modes are available so that it is possible to save space in the file store if certain conditions (such as size of routine arguments) hold. Routines to list a separate file, and all the file store, are also present.
The letters and digits of the Helvetica font have been obtained from the PDP15 FONTS program and put into a routine in SPROGS to provide temporary characters. The routine TEXT allows a string of characters to be specified and the appropriate routines drawn. It is also possible to print text vertically by using VTEXT, and, since this is accomplished by calling a specific file between each call of letter, re-defining the file allows text at any angle (with characters remaining upright). Routines to throw to a new page and to a new line are also provided.
Finally, variable intensity, expansion and rotation capabilities have been implemented and tested by reproducing the moving boat sequence from the GROATS film.
Work has proceeded on the definition of a library for picture files. The major problems are a sensible method of loading files from backing store and an efficient method of loading a set of files making up a character font. Although characters are no different from other picture objects within the SPROGS system, there is a need for rapid change between one font and another. Full details of the proposed system are given in SPROGS Papers 22, 26 and 28.
The ideas for TRACE routines for SPROGS, as set out in SPROGS Paper No 19, have been implemented. The amount of tracing output is variable from no trace to the output of the current region parameters and some of the global scalars, as well as the names and arguments of display routines. The routine STRACE, which sets the degree of tracing required, is itself a display routine and so can be used in picture files.
A set of fonts is at present being generated for implementation in the SPROGS system using FRAH's font generation program (ref SPROGS Paper No 17). There are in fact two fonts. The first, font 01, deals principally with the upper case alphabet and the digits 0-9. The second, font 02, is concerned with the lower case alphabet. Characters used in punctuation and control are housed in other locations of either font.
The individual characters for both fonts have been designed and packed into two files corresponding to fonts 01 and 02.
A facility is provided by the program which allows the user to make up frames of characters from a previously defined font. By displaying a line of text the user can decide whether or not the characters are pleasing to the eye.
It is hoped that work will be completed on the font early in the New Year.
A detailed study of the high level routines in the SD4020, GROATS and GHOST packages was made in order to provide some ideas as to what facilities SPROGS should offer. The aim will be to provide an adequate set of routines required by the user generating hardcopy plots on the init1al release.
Work during this quarter has been about evenly divided between design details of SPROGS and specifying the PDP15 end of SPROGS more concretely. During the first four weeks of the quarter much of the time was taken up with the Great Global Index Variable Conflict.
As detailed in SPROGS Paper No 27, SPROGS ON THE PDP (hereafter called SOOP) will be implemented within an interaction system, PIGS (PDP Interactive Graphics), to be written first. JRG and WDS visited Leicester on 27 November to examine a new interaction system on which Dr G A Butlin is working.
As part of PIGS, but soon to be issued for the PDP15 library, a free format input package has been written in FORTRAN which allows characters from any teletype (including the display console) to be displayed on the VT04 as they are typed. The BNF grammar for commands allows reals, integers, exponents and strings separated by commas.
Work has continued on the low-level routines, which allow a FORTRAN program to construct display files for the VTl5 and display them.
Ideas on this have altered a little and the latest proposal is described in SPROGS Paper No 24.
The routines VTPRIM provided by DEC were written under the assumption that display programs would be constructed in a particular restrictive way. The aims with the new version are :-
The package consists mainly of numerous small code-generating routines, which are each undergoing tests using the argument processor described elsewhere in this report.
The system outlined in the previous Progress Report, for calling FORTRAN subroutines interactively, is now complete and documentation is being written. It is based on the DEC language FOCAL and so its future usefulness depends on whether FOCAL will be available under the RSX Plus system. It has proved useful in testing new low-level routines for the display.
The library which was written up some time ago (SPROGS Papers No 12 and 20) has now been issued as a loose-leaf document and is now in a suitable form for updating.
Progress on the BSI has continued to be slow due partly to a number of hardware faults but mainly to lack of information on the way Executive handles the BSI. There appears to be some kind of cross talk between the FDS and BSI. Random interrupts occurred on the PDP15 when the FDS was being maintained until the PDP15 was modified to include an isolating switch when the BSI was not in use. More recently hardware failures have been noticed when the FDS is running but not when it is turned off. The evidence is not conclusive yet.
The current data rate for transferring twelve-character messages is very low. It varies between 36 characters per minute and 8.8K characters per second. The variation is due to other activities being performed by GEORGE and Executive while the transfers are taking place. The only sensible way of avoiding this seem to be to give the BSI a higher priority than GEORGE (not to be recommended) or alternatively building the link program into GEORGE itself so that it appears more like a standard peripheral.
One major problem encountered was that occasional errors occurred when sending blocks greater than 12 characters in length. This turned out to be due to the reaction of the PDP15 being faster than anticipated by the 1906A. By modifying the PDP15 software it has been possible to get round this fault. It is now possible to transfer short files with a reasonable degree of accuracy.
There are still problems transferring long records. An error occurs which may be a time-out fault or alternatively a parity error. It appears that the former is more likely. By sending messages to the 1906A with incorrect parity, it was found that these were accepted without an error condition being set. The system at the moment hangs up with the 1906A expecting a command or message from the PDP15 while the PDP15 is unable to load a new message for the transfer to start.
ICL have agreed to give all the help required in January to solve these outstanding problems.
Although the 1906A GROATS system has been basically unaltered for six months or more, there has been some work performed on the system. In particular, the writing of the manual has been completed and is available to anyone who would like to use the system.
Some work has been carried out on the software - two bugs have been cured, there are some small enhancements to the macros, some mends to bugs in the SRA4 library have been received from ICL, and every GROATS job now leaves a record in a file so that a record is kept of the extent of use of the system. The only other alteration currently being tested is one to automatically output the user's name (as distinct from his username) on output streams 12 and 13. This information can be extracted, at program run-time, from one of the files associated with the database.
The macros for running CAMP and CAMPER have been copied to :MACROS. The macro names are CAMP and CAMPER respectively. It was found that the version of CAMPER on the 1906A did not have the routines for drawing a border around the frame or an 'L' at the origin. It was then discovered that the Atlas version did not have these routines and neither did the original version which came from Sherwood Anderson who wrote the programs. They have now been included in the 1906A version of CAMPER. The manual for the systems is now complete and will be issued probably in the next quarter.
Work on the second film of the Syntactic Dominoes series has re-started. This particular film describes Top-down analysis and, among other things, illustrates the problem of left recursive production rules.
Some programs were written for GROATS on Atlas some time ago and these have now been transferred on to the 1906A, using the procedure CONVERT on Atlas. Some general points about the 1906A version:-
There has been a complete re-design of the set of Hash Table Films. The original table size of 256 was found to require a rather long film to show the main points. Attempts to use a table of size 64 were not successful due to the small size and eventually a compromise size of 128 was adopted. This did, however, mean that the straightforward square table had to be replaced by a non-symmetric representation.
Films have already been generated for the Linear Hash both with Random Keys and also Keys taken from an actual FORTRAN program. The Quadratic Hash film has also been re-generated with Random Keys. The major piece of work still to be done is a re-formulation of the film giving the Derivation of the Hash method.
There have been a number of attempts to get acceptable commercial quality prints during the last six months but without a great deal of success. The aim has been to get:-
Using Dacomatic film, it is now possible to get acceptable white on blue prints with a high success rate. However, the three-colour films are currently unacceptable. The colours themselves are now very good but there is a great deal of relative movement between the individual colours. Currently, we are attempting to generate multicolour films by generating 16mm prints containing the information in each colour separately. A composite print is then made by optical means.
The lateral movement produced in prints at the moment is probably caused by one of the following:-
Experiments to eliminate three of these have so far proved inconclusive. It seems likely that the SD4020 image itself is not moving. There is some evidence that there is lateral movement in the SD4020 camera. Tests are continuing to get to the cause of this movement. It is possible that multi-colour prints are impossible on 16mm using our existing equipment. We may decide to continue the experiments but release the films as white-on-blue prints.
A complete and working COLAB system has been produced, as detailed in the last Progress Report. There was a test run involving several members of the group on 22 November which, apart from one catastrophic bug which had to be circumnavigated, was remarkably successful. The discussion which followed produced a number of criticisms of the game and work is at present in progress to amend the game to cover the points raised. There is also work being carried out on the program that controls the system with a view to improving its efficiency and reducing the number of page-turns it causes. It is hoped it will be possible to test the modified system early in the New Year.
TEXT 360 is now working. It accepts input from cards and generates a master tape and a print tape on the 360/195. The print tape can be listed on the lineprinter of our 1130 provided the TN train is used. Wider underlining bars and vertical strokes are to be obtained for the TN train, so that it can print continuous vertical or horizontal lines.
A dictionary of technical terms in common use at ACL has been produced in co-operation with members of other Groups and the House Style Committee. At the moment it exists in hand-written form.
We are looking for a computer system that will let us print the dictionary in both lower and upper case and update a master file; TEXT 360 appears to be a useful tool for this. Its updating commands are some what complicated, however, and this may be a disadvantage if the task of updating is eventually performed by data preparation staff. There is also the problem that the special TN train with lower case characters has to be installed on the 1130.
The main visit this quarter was AHF's trip to the USA. He attended the UAIDE Conference at Lake Geneva and presented a paper on SPROGS. In addition he gave a presentation of computer animation activities in the UK. After the conference he visited a number of places involved in computer animation (University of Michigan, Toronto University, National Research Council of Canada at MIT). Some time was also spent at DEC discussing their future plans for graphics software in the RSX-Plus operating system. Full details of the trip are given in the paper Visit to the USA and Canada.
The main areas of work in. the near future will be SPROGS, Communications and the 1906A software. An attempt will be made to have a basic SPROGS system together with some user oriented high level routines by the end of the next quarter. Work will be suspended on the more complex features such as the sequence lists, variables, library etc while the system is made into a state where it can be issued. This will include a basic manual, a unified COMMON system and an ordered semi-compiled library.
On the Communications side a radical reconfiguration of the 7903 interfaces will take place in January to tidy up the situation. It is hoped that our plans for a unified communications system with the possibility of a front-end processor will become firmer during the next quarter.
The main developments on the High Level Scheduler are likely to be:-
What Was, What Is and What Should Have Been: A critical evaluation of the Chilton Multi-Access System, Software Practice and Experience, R E Thomas and J C Baldwin
Computer Generated Educational Films, Proceedings of Conference on Visual Media in Chemistry, British Universities Film Council, F R A Hopgood
Visit to the USA and Canada, A H Francis
UAIDE '72 Lake Geneva, Wisconsin, USA 23 - 26 October, A H Francis
University of Michigan, Ann Arbor, Michigan 27 Oct
Toronto University, Toronto, Canada 30 October
National Research Council of Canada, Ottawa 31 October
Massachusetts Institute of Technology, Boston 1 November
Digital Equipment Co Ltd, Maynard Mass, 2 November
IEEE Conference, Computer Systems and Technology, 24-27 October, P Kent
AERE Harwell Course - Algorithms for drawing functions on a graphical device, 24-25 October, R E Thomas
SRC Management Course 1-6 December, P E Bryant
BKSTS Course, Video Recording Systems present and future, 11 Sept - 30 Oct (1 evening per week), A H Francis and W D Shaw
ACTP Software Committee (3 meetings) P E Bryant
Satellite One User Liaison (ACTP contract) (2 meetings), P E Bryant
ACC Working Party on Communications (2 meetings), P E Bryant
UIJPC (UGUG) meeting, Nottingham 13 November, P E Bryant and C J Pavelin
ICLCUA Performance Activity Group 30 November, G W Robinson
ICLCUA Remote Users Activity Group, 8 December, P E Bryant
ICL New Range Working Party (4 meetings), C J Pavelin
