The only Group membership change this quarter has been P R Hayes, who transferred to the Applications Software Group on 1 May.
Present complement is:-
The Edinburgh line was brought into use. It has been found that care is needed in connecting CTL equipment to Milgo modems in that the select standby line must be disconnected. If this is not done, the modem timing is inhibited. Other communications developments are inhibited by the slow delivery of GPO lines.
For the Imperial College project, a hardware modification has been made to the 7903 scanner. This allows a software time-out on the scanner when used at 600 or 1200 bauds. Unfortunately, the modification prevents the equipment working at 1200 bauds, but it is hoped testing can be carried out at the slower speed shortly.
Sigma 2 has proved useful for some of the testing. Unfortunately, the failure and subsequent removal of the disc has made program development on Sigma tedious.
Future developments in this area depend upon the effort ACL is willing to expend on communications and on many factors outside its control, such as what general network development will take place and how much interest SRC has in networks. Currently, discussions are being held with several bodies including RHEL and Edinburgh Regional Centre, and the ARPA network in the USA is being observed. It is hoped the current GEC 2050 will adopt some networking role in the future. Further definitions of this project should be possible in the next quarter, particularly if some indication of the future machines at ACL is forthcoming.
Progress has been disappointing. It had been hoped to have a working 7020 emulator at this point in time. Several factors militated against the project. Most problems were due to GEC software which ACL had agreed to use. In fact, more effort was required to build suitable software systems in which the emulator could be constructed. The software was found to be difficult to understand and faulty in several respects. Recently, GEC has loaned ACL effort which has enabled these problems to be overcome.
The project now appears to be moving forward and an emulator should certainly be produced in the next quarter.
An appreciable amount of time during the last quarter has been spent on understanding and learning how to use the GEC supplied software. This includes the Assembler, Linking Loader, General Interrupt Control Program, Device Control Programs and the I/O scheme. Adequate provisional documentation is now available. Unfortunately, the bootstrap loader to enable input of binary card decks failed to materialise and so paper tape has had to be used.
MDF has written a program to produce a core dump on the lineprinter, and is currently working on the generation of a system which will control software and hardware interrupts, I/O devices and communications lines. This system will incorporate the GEC software.
There have been a number of minor hardware faults, but only one major bug (failure of a power supply).
The communications software is believed to be completed as is the main control protocol stripping program. Peripheral-driving routines, for the card reader and lineprinter have been coded. The lineprinter routine is believed to work and the card reader driver testing should be completed shortly.
A utility for finding terminal and peripheral status is now available and a routine which outputs relevant messages to the operators' console is working. (The number of messages is tending to expand.) Routines to simulate the 7020 teletype are also being written.
Most testing has, of necessity, been carried out in copy (off-line) mode, due to the absence of a basic on-line system environment. This situation should shortly be rectified.
Documentation is being produced at relevant stages of development.
Following observation and experiment, some minor changes have been made in an attempt to improve efficiency. These includes changes to PROGAREA, MAXQUOTA, CHAPTERQUOTA, MOPTRACE, :SYSTEM.JOBLIST, and the quota on the FORTRAN compilers. GEORGE is now on a disc by itself. These changes have contributed to a slight increase in prime shift efficiency despite the increase in load. Overnight efficiency is far more variable and record figures in recent weeks are almost certainly due to changes in job profile rather than to any system change.
Leaving aside the high rate of software and hardware breaks, the performance of the machine has reached a level which will be difficult to improve upon without further hardware. The addition of the EDS60 should effectively double the disc capacity and allow further improvements. Other efforts are concerned with increasing the effective transfer rate of the disc by careful unjamming and putting directories on small special residences on each disc. As a consequence, more of the scheduling effort has been directed towards improving the machine's management. This involves giving guaranteed users some priority, attempting to save long or awkward jobs for evening and night shift running and various other techniques.
The SPROGS system is being used to produce graphs of key features from the performance file. The process will be automated shortly and the weekly graphs circulated to any interested parties.
A program to print out the Low Level Scheduler states of all the programs in the machine was produced. This showed that the user program area was rarely over-subscribed with non-dormant jobs and very little swapping was thus taking place.
A program to produce a monthly summary from the long term performance file is being prepared.
Little effort has been available for preparatory work for system journal. As a consequence, the work has been sub-contracted to Eric Walton and Mike Brown. Consultations with those responsible for the accounts has led towards a more rational approach to the processing. This will allow accounts and statistics to be computed from the same archived and compressed copy of system journal.
There is no progress on the job costing benchmark. CHAPTIME is increased in order to charge more for GEORGE activities and thus charge and schedule in a fairer manner.
The effect of this type of change will be watched with interest.
This quarter has not shown the progress expected. In the first quarter, an implementation plan for GEORGE 4 Mk 7 had been drawn up but due to delays in obtaining an Executive, it was not expected that it would have been introduced until this quarter.
The ACL modifications to Mark 7 seem to be sound and in the light of the delay, three further facilities were added by Ron Prior and CJP. (see below).
Just prior to 6 May, it was hoped to have a trial of Mark 7. In the event, the EDS30 failed early on and, in addition, as soon as MOP began to be used heavily, the Executive failed with a high frequency. Eventually, the experiment was abandoned at mid-morning. It was then realised that there were serious problems in the ICL software. A later exercise by lCL on Sunday 20 May reinforced the view that Mark 7 was not in a fit state.
Previously, it had been decided to halt development of Mark 6. This decision was rescinded on 25 May and the facilities mentioned above were put in Mark 6. Unfortunately, the introduction of these became mixed up with modifications to the 1906A and the re-configuration of the 1906A to include the EDS60. The lesson learned from this exercise was that when hardware modifications are in hand, software modifications must be held back. Currently, the extensions to Mark 6 are being further held up by the requirement of ICL to bring Mark 7 up to date in anticipation of its early introduction. ICL hope to bring this to fruition by two or more weekend efforts. Experience leads one to be pessimistic, and it is the Group's intention to continue to improve Mark 6.
The strain of keeping two operating systems up to date is heavy with the current staff shortage and prevents much development.
Tests on Mark 6 revealed errors in the NEWS facility and the new dumping system (implemented by Ron Prior just before he left). Mark 7 corrections have been produced but not yet tested.
The filestore is on a new set of discs each with small directory residences on a few cylinders round the centre. The allocation of files to these residences revealed errors in the unjamming system. This will be tried again in Mark 7.
The format of :SYSTEM.JOBLIST has been changed. The file is now half as long as before and contains entries for the MEDIA command.
Several useful meetings have been held with the 1906A universities. This gives some optimism on GEORGE and 1906A development in which ACL hopes to take a full part. The development of a cheaper multi-access system at Leeds looks promising. Other important developments are the incorporation of a secure job well and the improvement of the dumping system to alleviate filestore freezing. Partial restores of the filestore also look attractive but it is hoped that general restores will become less frequent as GEORGE and the hardware improve.
An EXPRESS NORMAL facility has been introduced (this removes EP FAST).
Most of the MEDIA coding is implemented. The automatic abandonment of jobs which exceed their MEDIA forecast will be delayed until the introduction of the NEWS facility to warn of this.
Guaranteed and block users have been given CONTEXTC and the HLS gives these users priority in certain circumstances. The action the HLS takes in the two scheduling modes, PRIME and NORMAL, has been altered and documented in an Operator Console Notice.
A scheduling macro SCHED has been introduced. At present, it allows the operator to change the scheduling mode and the user to discover WAITFACTOR.
WAITFACTOR is written (using the new GIVE20) into an IP where the GERONIMO system can read and display it.
It was found that the system sometimes did not save a job for which HLS had issued a SAVE extracode. In these circumstances, repeated attempts to save were found to work. This has allowed more jobs to be saved and JOBLIMIT to be raised to 90 without adverse effect. The cost is the increased length of JOBLIST and a 15 word core entry for each saved job. JOBLIMIT will not be able to go much higher without the implementation of the proposed secure job well.
Some low level documentation for HLS has been produced.
The general purpose macro COMP for compilation, consolidation and running binary programs was ready for release and the documentation almost written when various changes in specification were made. This resulted in COMP being renamed TASK, several changes being required to the program, and a re-write and expansion of the documentation. As the program was also undergoing major changes at this time to add extra features, the release was postponed until these were ready.
Despite severe hold-ups due to the inability of late to get much work through the 1906A, the TASK system is now fully operational and documentation is currently being typed. The system now caters for Algol and PLAN, as well as FORTRAN and PLASYD and allows users to start and finish anywhere in the compilation, consolidation and run binary program process. All the normal facilities of the ICL macro are provided, along with many additions. Most notable of these is the ability to obtain the parameters for a TASK job from a file (which is usually the source file of the program to be compiled) and the facility to consolidate semi-compi1ed without writing the appropriate program description. TASK also logs the jobs run using the system and it is hoped to develop this to provide an overall picture of the type of work done and the compilation/consolidation success rate that users achieve. Considerable effort has gone into improving the efficiency of TASK, such as the placing of all the compilers in one disc file. When the EDS60s become available, it is proposed to use an exofile for this purpose which should again improve efficiency. The use of exofiles for semi-compiled output from a compiler and re-input to the consolidator is also possible using TASK (FORTRAN only) and this technique is being evaluated to see if worthwhile gains can be made. An attempt has been made to make the output from TASK easier to understand by putting comments about what the system is doing in the monitoring file and on the user's output.
TASK is currently being revised in order to make additional facilities easier to incorporate. These may include GROATS, FORTIDY, the PLAN Preprocessor and possibly the XPCK consolidator, but work on expanding facilities is being postponed until the present system is fully debugged and meets the needs of users. The fact that it takes at least a day to correct a bug, test it and put up a new version of TASK does not help and future developments may be severely hampered by the inability to get work through the 1906A.
A large amount of time this quarter has been spent on re-designing and re-writing the fixed-core part of the GERONIMO program. The code for this now occupies half as much store as in the original version, and when the tracing package is omitted, the number of overlay slots can be increased from two to five. This, coupled with the implementation of an overlay changing algorithm, has reduced the number of file store transfers required from twelve per minute to less than one per minute. GEORGE overheads have been reduced as much as possible by using an exofile for the overlay swapfile, and by avoiding unnecessary SUSBY instructions. The latter are estimated to cause an overhead of about 10,000 GEORGE instructions for each SUSBY obeyed.
New commands available on GERONIMO are:-
The FORTIDY program has been altered so that it can send all its output to one file, and the macro now permits this output to be appended to a file created, eg by the FORTRAN compilation macro. The generation of a tidied source file suitable for compilation is now optional, the default being no generation.
Most of the manual has now been typed and a draft version should be available soon for internal circulation.
A new PLAN macro has been written which caters only for XPLT, and will be introduced when documentation describing it has been issued (1900 PLAN Supplement). This document will replace 1906A Software Notices 5 and 7, and contains details of the PLAN macro, the compiler XPLT/7, the PLAN preprocessor and the floating point machine orders available on the 1906A (including the extended precision variants of these).
During the quarter, considerable effort has gone into obtaining a copy of XFEH in symbolic form so that it will be possible to make additions to the system. Initially, this was thwarted by insufficient information concerning the copy obtained from ICL via Oxford University. Although all parts of the compiler now seem to be located, it is still not performing correctly and further work is required.
During the next quarter, the major activity will regrettably have to be directed towards the early adoption of Mark 7. Work on the TASK and GERONIM0 systems will also continue through the quarter, but it is hoped that both these projects will require increasingly less effort subsequently.
The Group is now being discouraged from producing. separate memos so that filing can be made easier. Consequently, all papers will be issued as 1906A Internal User Notices, 1906A Technical Notices, or GEC 2050 Papers.
The first version of SPROGS, together with a user manual was issued at the beginning of this quarter and is being used successfully by a number of users. So far, the only bug uncovered has been caused by a mistake in the ordering of the semi-compiled library. Some comments on extra facilities have been received, notably in connection with constraining characters to a size suitable for the job in hand.
The next version will be issued later this year, and will include many of the more novel and adventurous features of the system.
A separate version of SPROGS is being retained for the insertion of new facilities. Due to shortage of staff and time (a common Basic Software Group complaint), certain proposed extensions have been postponed. The following have been added.
Global variables have been implemented, together with array references. Thus, a user can perform arithmetic on variables which have been stored in picture files and can read data from a picture file for use as arguments to other routines. A data file is set up by using the NULL routine, but such a file can be obeyed by giving the NULL routine a meaning via a call of NULSET.
Local variables have not yet been implemented since with careful use of names, global variables can be used instead.
A high level routine to draw an ellipse has been included, but the other second order curves have been shelved, since they are not likely to be used.
The sequence list, where various film files can execute in parallel, is now present, together with routines to add items to the list, delete items from the list, suspend and resurrect items in the list, repeat items indefinitely, repeat display routines in an item conditionally, and stop the sequence completely. An item on the list is obeyed until it is completed, or until an Advance Film order is met. In the latter case, the position in the item is saved, and the next item resumed, the next item being chosen cyclically. An actual Frame Advance order is issued once per cycle. When an item is completed, it is deleted from the list. By using global variables, and suspending or awakening items, various interactive effects can be produced, in particular, the motion of an object can be defined by a different item from the object itself. Conditional repetition of orders, and repetition of whole items, gives the ability to control sections of the sequence independently.
Routines to read some of the system COMMON variables have been provided.
Dummy PLAN routines have been included which, by providing dummy CUEs, cause the consolidator not to include various unwanted routines Thus it is possible to use the font generator without needing the code for all currently defined fonts. This is a temporary measure until the library system is working.
The SPROGS library has been revised so that most of the routines are in one file. However, the use of BLOCK DATA to initialise variables means that it is always necessary to have two library files. The routines are manually ordered, so no doubt more ordering bugs will come to light.
As a test of the usefulness of the sequence list, the sequence from the GROATS film, which shows a boat moving within a film, was coded in SPROGS. It was possible to define the boat, the film and the motion of each separately, and produce a solution which was easier than the GROATS equivalent.
A film file to produce a linear wipe between two pictures has worked, and an attempt at simple in-betweening has been made. The latter involves computing the pictures required to give a smooth transition from one picture to a second. The simple version ensures that connected parts of the first picture change into connected parts of the second, which appears adequate if the two pictures are somewhat abstract. However, no line splitting is attempted, so bizarre efforts can be produced if the two specified pictures are, say, of a man walking. It is quite likely that the effect will be that a hand in one picture will turn into a foot in the other!
Further work on the GEC contour package (see last Report) has shown that it is too restrictive for use in SPROGS. Indeed, there is some doubt as to whether the algorithm works correctly at all. However, another package has been obtained from John Lewis, and a simple working version of this has been produced. More work is needed to include this fully into the system.
A system for making libraries of SPROGS picture files has now been specified and implemented. The user can create EDS files and by means of some new display routines he can copy picture files out of the SPROGS filestore and into his own EDS file. Each EDS file (library) can hold up to 128 picture files and has its own directory. These picture files, once written into a library, can be read back into the SPROGS filestore on the same run or on subsequent runs of a SPROGS program. Thus a user can build up a library of picture files to be used by himself and, if the necessary traps are set, other users of the SPROGS program.
There are also routines for listing the directory of a specified library and for erasing picture files from a library. At the moment there is no garbage collection when a picture file is erased but its directory entry can be re-used.
The EDS files for the libraries and their channel numbers are specified by the user as parameters of the SPROGS macro. If the EDS file is too small to accept a picture file which is about to be written to it, the program will extend the EDS file if there is any space available on the disc. The minimum size for a library EDS file is 2 buckets, using the default 4 blocks per bucket. The first bucket contains the directory, entries to which are hashed, and the second and subsequent buckets are for the storage of the picture files.
At present, the fonts for SPROGS are held as picture file definitions which are executed when a font is selected. This puts the font picture files into the SPROGS filestore. A better method for doing this is now being implemented using the SPROGS libraries. Several libraries will be created and the picture files for 2 fonts will be written to each of these. When a font is selected by the user the appropriate picture files will be copied from one of these libraries into the SPROGS filestore. This method will allow a SPROGS program to be smaller since the picture file definitions need not be included. in the semi-compiled. The user will not need to alter his program to take advantage of this method of handling fonts.
Work has started on using SPROGS to make a film about SPROGS. The order in which concepts will be introduced has been decided and work on the writing of the storyboard and script is in progress.
A version of the Translator Writing System TREE-META defined in term of itself has been obtained from Queen Mary College. Currently, it runs on an Interdata computer and is being rewritten to run on the 1906A. The main purpose will be to see if it can be used on the SPROGS preprocessor. It could, however, be useful in any context in which structured text needs to be manipulated or re-arranged.
A number of hardware problems have arisen over the past 3 months and, after a period of neglect by DEC, these are now getting attention from their engineers.
On more than one occasion, a resistor has burnt out in the VT04 (the display tube). DEC are thinking about how to insert an appropriate fuse into the circuit; they still have to determine the correct current rating.
Spark pens for the writing tablet wear out after a very short time. It is estimated that 40 hours of use is normal, against a specification of 500 hours. DEC have now agreed to supply the new pens automatically when they wear out; but this does not solve the basic problem, which may be due to the fat spark (12000v).
The pushbuttons have become unreliable again and will be replaced. DEC indicate that a differently designed set could be fitted, which they have found to be more reliable.
The spark pen causes characters typed on the display keyboard to be corrupted. PIGS (the interactive graphics system) involves the use of both simultaneously. Any method of avoiding this by software would be awkward for the user to operate. A DEC engineer and Neil Parker are looking for a cure. Several shields have been tried without success. Moving the tablet/spark pen relative to the keyboard will cure the fault but it has to be moved 4 feet behind the screen before the interference ceases! This, too, may be due to the high voltage of the spark.
A Tektronix tube can be connected to the LTl9 (the multi-teletype station of the PDP15), via an LT19B (required for each device coming off the LT19), and an LTI9C, which when connected to an LT19B gives the correct interface.
The LTl9B is surprisingly expensive and the possibility of fitting the Tektronix + LT19C to the same outlet as the existing second Teletype is being examined. A switch would be fitted so that only one device was selected at any instant and the Teletype interface would have to be made EIA compatible.
In developing programs on the PDP15 one often wants repeatedly to obtain listings of a large number of files. Rather than type the names of fifty files each time, LISTIT has been modified to read a list of files from the disc and transfer them to magnetic tape for the 1906A. Also, commands to position the output tape have been included.
The main project this quarter has been to convert all existing PIGS subroutines to run under JRG's new graphics system, FOG. In addition, subroutines have been written to update lightbutton data areas and resolve command references using a jump table rather than computed GOTOs.
Work began on a primitive version of the film-making facilities to be included in SOOP. Running under PIGS, the program BPATH allows the interactive description and playback of a drawn cel along a trajectory. Two versions are available; one runs under VTPRIM and the other under FOG. As PIGS progresses, BPATH will be expanded to include selection descriptions and better drawing facilities.
FOG is the name given to the set of basic display routines which currently exist. Recent additions include the saving and retrieving of a pointer to display files so that they could be readily manipulated in more than one routines without needing to use COMMON. One useful effect is that a graphics library routine can save a pointer to a programmer's display file, construct a display file of its own and then retrieve and re-select the former.
All the components have now arrived from DEC and the back plane has been wired up by the workshops at Rutherford Laboratory. All that remains to be acquired is ancillary equipment such as plugs, sockets, etc, and a small regulated power supply.
Time spent on the BSI in this quarter was curtailed by the latter part of a course (2 weeks), holidays and Ron Prior leaving at the end of May; some time necessarily had to be spent understanding the 1906A programs which had previously been RCP's responsibility.
However, the bug which had been the problem in the previous two months has been traced. To recall, after a number of successful transfers in both directions, a transfer from the PDP15 would never be completed; all attempts to re-try the transfer failed.
One important advance in tracing the fault was the discovery that if the programs were simply left in core exchanging data, failure would certainly occur within 20 minutes. With hindsight, the extent to which the fault was intermittent should have been tested earlier.
Subsequently, a DEC support engineer (who also had a good grasp of the BSI logic) was able to have a profitable morning on 3 May (when the 1906A was also working reliably), on which he discovered that:-
Problem (b) was cured straightaway (apart from a hiccup when the modification was made with a faulty wire). The ICL engineers are looking at (a) but are not regarding it as urgent since it only affects re-tries after a time-out, and curing (b) removes the cause of time-outs. However, (a) is non-standard BSI.
Neil Parker has been acquainting himself with the design of the BSI (certainly the PDPl5 end).
Time is being spent on cleaning up the system which sends character files from the PDP15 to the GEORGE filestore. The two 1906A programs which handle information from the link and convert it into ICL code are being combined into one; the GEORGE macro will enter the program once for each PDP15 file that is sent.
The PDP15 program is a device handler, analogous to a paper tape punch handler that only handles characters. It will be possible to attach to it both user programs and DEC system programs (PIP, MACRO for assembly listings, MTDUMP for magtape listings, etc).
The Mark 2 system, which enables programs in the two computers to exchange information, has been specified. Ron Prior wrote the program for the 1906A before he left. We were experimenting with a very simple protocol consisting of one message for each transfer of significant information. The receiving computer would only send a Not Acknowledge if it detected an error. Otherwise, it would simply set itself up to receive the next transfer.
This contrasts with the 4 message protocol (sometimes 6-message) outlined in SPROGS Paper No 18. The idea is to make the link faster. Each record sent carries with it its own type for identification purposes.
Subsequent experience suggests that the controlling programs need to be quite complex since it is not straightforward to determine what state they are in at any given moment. A 2-message protocol would be simpler and may not be significantly slower; JRG intends to perform some simple experiments to check this latter point. The 2-message protocol would be initiated each time from the PDP15.
This looks like being the next jinx on the BSI. In order to use the 7203 (1906A end of the BSI), some code must be available in Executive to handle the device. Because of the troubles with Mark 7 Executive, it looks as if the 7203 code will only be introduced when Mark 7 is functioning. This means, of course, that the BSI hardware will be unavailable for software testing for a period of time.
Some progress on the BSI can be made without the device.
A number of modifications to the system have been implemented during this quarter. A new version to be issued shortly contains corrections to some minor bugs; it will also give smaller programs for many GROATS programs. The present minimum size of a GROATS program (approximately 42K words) will be reduced to about (18+4n)K words, where n is the number of character fonts used. Many programs only use one font (FONT 0), and these will now have a minimum size of about 22K. This new GROATS system also has the code of all segments marked as PURE, so that in a user's program, all the library routines are protected against overwriting.
A working system has now been produced to run on a 48K 1903A machine under the control of GEORGE 2. This involved producing a system using a dense program rather than a sparse one, overlaying the character fonts (to reduce the core size of the program) and removing PERI type 60 orders and replacing them with a suitable alternative (where possible).
The GROATS manual is now nearly finished and ready to be printed. Until the final version is received from the printer, Xerox copies may be obtained from DCT.
The coding of the new version of COLAB mentioned in the last Progress Report is now almost completed. The major omission at present is the code to control a conceptual multiplexor, and this will be written and tested after the introduction of GEORGE 4 Mark 7.
Most SPROGS effort on the 1906A will go into the making of a film and the inclusion of features found necessary in practice. Work on the PDP15 will involve the expansion of PIGS, FOG and SOOP, and may also involve the understanding of the RSX Plus operating system if this arrives early. The BSI is likely to be held up until GEORGE 4 Mark 7 has settled.
The major forthcoming event for the 1906A is still the introduction of GEORGE 4 Mark 7. GERONIMO and TASK should also be completed. When Mark 7 is running smoothly, more work can be done on improving system efficiency and utilising the increased filestore to best advantage.
The 7020 emulator on the GEC 2050 should become available in the next quarter, and more definite plans about communications formulated.
Visit to USA, P E Bryant
Visit to USA., F R A Hopgood
The Basic Software Group organised a bowling evening at the Hare and Hounds, Chieveley, on 27 April. It is hoped to repeat this later in the year.
Barbara Hopgood bowling, Dave Toll to the left, Ann and Anton Walter behind, Julian Gallop drinking.
Barbara Stokoe bowling, Martin Fowler, ?, Cliff and Janet Pavelin behind.
Judy Chamberlain bowling, Paul Bryant, Richard Hilkin, Ann Walter behind.
Bob Hopgood and Paul Bryant to the left. Jane Toll, Alan Francis at the back. Steve Perkins and Julian Gallop drinking. Barbara Stokoe sitting with her husband behind.
Janet Pavelin, Judy Chamberlain, ?, Martin Fowler, Dave Daniel.
Bob Hopgood, Paul Bryant and Eric Thomas front left. Eric Walton centre, Roland Brandwood to the right.
Cliff Pavelin bowling, Dave Toll and Barbara Stokoe watching.
Bob Hopgood bowling. Jane Toll and Alan Francis behind.
