Elliott 803, 903 & 920M — Terry Froggatt

TNMoC’s Elliott 803 is currently working much more reliably following some recent work which has improved the temperature stability of its +10V supply. This has greatly reduced core store parity fault rates. Work is also underway to try and determine what is wrong with the numerous SX2 read amplifiers that have failed over the years.

Some years ago the 803 was upgraded with the addition of factory option SB103 which provides 13 bits of parallel I/O via the accumulator. The appropriate boards were probably in TNMOC’s stock of spare boards because the option was fitted as part of the Magnetic Film system where it was used to allow the 803 to read back from the film controller the number of the last block accessed.

With reference to the original Elliott document titled Considerations for matching a peripheral device to the 803B computer one of TNMoC’s newest volunteers has used the 13-bit interface to connect five large arcade game style illuminated buttons to the 803. A “SIMON” memory test game has been developed in HCODE which is proving popular with visitors.

Along the way one of the buttons has also been connected to the 803’s interrupt request line, a facility which as far as anyone can remember had never been tested since the machine was originally delivered to TNMoC. Surprisingly it was found to be working, though it has taken a while to get to grips with using it correctly as it is possible to stop the 803 functioning if the interrupt line is held active.

A serial interface is being planned for the 803 using the interrupt line and the 13 bit interface.

My thanks go to Peter Onion for the 803 report.

When I last reported on the TNMoC 903 “Olly”, we had a suspected problem with bit 10 of the Q-register, possibly related to the gating signal GTQ, and Peter Williamson tried linking this signal across two A-FA cards. It now seems more likely that there is a latent backplane or connector problem with slot 45, which is best not touched. The 903 has been running smoothly since December.

I have recently made some progress on tracing the wiring of the 920Ms. I’ve found where all of the register bits are held, on the middle deck, which account for around half of the 196 modules on that deck. Understanding the remaining modules could be harder, as there will be less pattern to them. It’s sometimes possible to see what DTL chips and other components are inside the potting of a logic module (after undoing its wire-wraps and removing it). Sadly this is not the case for the store modules, which are inside metal sleeves, and the faults in both the eBay and RAA/TNMoC 920Ms are most probably in the store. So, for example, although I know how the store timing modules are interconnected, I don’t yet know which way most of the signals between them are flowing.

In Resurrection 95, I reported Dr Erik Baigar’s discovery of a 920M microprogram summary on a single sheet. By inspecting this and looking at the wiring of the eBay 920M here, I spotted a glitch in Function 3, and Erik ran a test program for me on his working 920M, which confirmed this. In the Facts Cards for the 903 and for the 920M, and on an actual 920B/903, Function 3, “Store Q”, is defined to read the Q-register, shift this right one place, and store it in the designated location. On the 920M, it shifts the Q-register right one place, stores it in the designated location, then shifts the register back: the least-significant bit is not saved in the overflow latch and so is lost. Function 3 is often used after a multiplication, to save the lower 17 bits of the sign-and-34-bits result, where the right shift is useful. This lost bit is actually defined, in Programming compatibility of the 900 series Nov 1965, to be the sign bit of the accumulator before the multiply (although the 920ATC, where it is the sign bit of the other operand, got it wrong). But the 1965 document, which includes the 920M, and the Facts Cards, make no reference to losing this bit from the Q-register itself. Does it matter? Well, losing a bit of the Q-register unexpectedly certainly would, and in Airborne Computing Division we used interrupt code which preserved all 18 bits of A and Q, rather than the code shown in the Facts Cards. I’ve also used Function 3 to halve something, or to clear a word of store without losing the accumulator. And it is perfectly legal to hold six characters in six-bit code in A and Q. But presumably nobody has ever felt the need to use Function 3 in a situation where they knowingly also have useful information in that bottom bit. Recently Erik has shown that this glitch is not present in his later AMD-based 920MEs. We cannot tell whether this is because the glitch was spotted and corrected, or it was never spotted and the 920ME was simply implemented from the specification.

Ex-Jaguar GEC/Elliott 920Ms are still appearing on eBay, at prices well above that paid by Erik for the three that he purchased.

IBM Museum — Peter Short

The Hursley site finally reopened in March. No mandatory masks or social distancing, but they have made available badge lanyards in red, yellow and green – from keep away to come closer! There has not been a mad rush back to office desks, and we curators are also taking things slowly. We have a lot of tidying up to do; lots of donations have been piled up in our absence, which all need sorting out. We have received a shipment of four boxes of manuals from St. Andrews University, mainly going back to their IBM S/360 model 44 (developed in Hursley) and 1620 systems.

Our first venture into the museum saw some checks on hardware that was working OK two years ago. Our 029 card punch was a bit sluggish, increased friction causing the main drive belt to slip (it has stretched and needs replacing, but we can’t get one anywhere) but once the friction clutch warmed up it began to behave itself. We have an 026 not on display with a reasonable belt, so one of the next jobs is to do a swap.

The 1052 golf ball printer was also not too happy, hesitating during printing and stopping during carriage return. That has now been fixed. The print problem was caused by the cycle shaft contacts contaminated with grease. This was always a favourite fault on S/360 console printers back in the day. Carriage return was more grease in the wrong place on the operational shaft CR spring, as well as a rather weak spring on the op shaft slip clutch causing a lot of slipping. The carriage was also “chattering” when moving in both directions due to a very slightly distorted print shaft.

Several PCs and PS/2s were in need of attention. Most are now up and running.

We have also started sorting through hardware where we have more than two examples, and moving the excess into a ’for disposal‘ area to create more space for new and unique donations. Another job, now completed, was to catch up on photographs of hardware that was catalogued two years ago but we were excluded from the museum before photos could be processed.

Our 080 card sorter was shipped on schedule to Bletchley Park. We had to order a new toughened glass lid from a local supplier to replace the one broken during transit from Oslo. Our own small stock of these glass panels are from a different model sorter, perhaps a 101 statistical sorter, which fit correctly width-wise but are too deep and protrude out the front, preventing the lid from closing.

The sorter, together with a Hollerith hand punch, is now on display in the new The Intelligence Factory exhibition. Also a feature in the same room is a sound recording made by our colleagues in Böblingen of one of their working card sorters.

The whole display is extremely impressive and well worth a visit. The punch cards flying above the sorter are a reminder of the VE day celebrations, when staff threw large quantities of cards in the air before being reminded to get back to work. You’d think flying punch cards might be a problem, but pretty well every card that had been through the punch / verify / sort / collate / tabulate process was then destroyed.

Two representatives from Hursley attended the VIP opening ceremony on the evening of the 26^th April – Peter Short and Dave Key.

We are also thinking about a complementary display in the museum to reflect the Bletchley exhibition. This will probably include our 416 tabulator and our second 077 collator. These would be complemented by photographs and text panels telling the largely unknown story of the data processing operation behind the code breaking.

Turing-Welchman Bombe — John Harper

The Bombe Rebuild Team have been able to provide visitor demonstrations almost every day that the Computer Museum has been open. This has been difficult because the museum has had to open and close at short notice because of the number of visitors and school visits expected

The Drunken Drive Demonstrator is now coming together well. The outstanding work is to make a base with a hidden motor and a transparent cover. However, we are awaiting parts still to be made by volunteers.

The partially complete Drunken Drive demonstrator. One of 36 fitted on a High Speed 4 Wheel Bombe

EDSAC — Andrew Herbert

The EDSAC team continues to struggle with commissioning the machine. We had been making good progress with testing the arithmetic unit but then ran into a spate of problems with main control (the part of the machine that deals with the order fetch and execute cycle), coincidence (the part of the machine that synchronises main control to the main store delay lines) and store addressing (the part of the machine that selects the main store tanks being addressed by main control). These parts of the machine are intimately connected and concurrent faults in these three areas can be very hard to unravel since it becomes impossible to run even the shortest of test programs.

I’m pleased to report that we appear to have surmounted the main control and coincidence problems earlier this week and can now resume testing the arithmetic unit.

The addressing problem is at best intermittent and may be associated with ongoing work to add the transfer unit to the system – this is the part of the machine that allows main control to write results back to the main store. At present we can only execute read-only programs. Once the transfer unit is completed we will be able to use the entire order code. There are only three orders that write to store: T (write accumulator to store and clear), U (write accumulator to store without clearing) and I (input character to store from paper tape).

We had our first “all hands” meeting in two years during April. The main item for discussion beyond progress updates was how we might construct and operate a monitoring system built using modern electronics to help diagnose EDSAC faults once we have a working machine. A prototype monitor unit was demonstrated and ideas about how to specify interfaces were discussed. There is now a small working group on such matters.

On the commissioning front we have not made a great deal of progress. Faults in previously working parts of the machine often prove hard to find and consume much of the working day – hence the interest in automated monitoring.

The current areas of focus are: the transfer unit, main store address decoding, interaction between main control and the arithmetic system, and the arithmetic operations themselves.

We now have one nickel delay line in operation as a short tank replacing the interim digital emulator used to date.

Software — David Holdsworth

Free-standing Webserver Emulation System

I have been refining the internal structure of this free standing system. 

It is still available to sample at its rather impermanent URL: ccsoc.org/tmpwebemu.htm.

The philosophy of this system is that things get preserved when in the custody of people who like them, and that lots of copies keep stuff safe. I need to think a bit more about licensing. I now have a system that inserts licensing information into all the source text. The aim is to make it possible for today’s users of computers to gain an appreciation of the software of yesteryear. To do this, you need to be able to run it. This needs some hardware capable of running the software, and a user interface that feels reasonably familiar.

The emulations embedded in this package are intended to give any hardware the capability of running the preserved software. Anybody likely to be interested will be comfortable with a web browser interface.

For both KDF9 and LeoIII a programmer would produce the source text, and then hand it over to be run, either by operators, or on a multi-access system on KDF9, such as COTAN or Eldon2. So our interface is rather equivalent to this experience.

Elliott 903

Andrew Herbert and I have been looking to add Elliott 903 software into the mix. We have the manufacturer’s compilers for Algol60 and FORTRAN. However, the 903 was basically a personal mini-computer and it was down to the programmer to load up the correct paper tapes and press the right buttons. We have developed a web-based interface which offers a similar experience – without the need for winding up paper tapes. Although it gives quite the impression of using a 903, I feel it would be wise to offer alternative access that is more like having someone else run your program for you, as was often the case in the 1960s.

Andrew has been experimenting with presentation of the source text of the Elliott compilers on-line. The code is all written in Elliott’s SIR assembly language, but with almost no comments. Elliotts bought in the compiler from CAP, who provided thorough accompanying documentation. but it is not yet clear how best to present the link between documentation and source text which is almost devoid of annotation. The only place where I have tried to do this sort of thing is one of the bricks of Kidsgrove Algol, viz: KAB22. ccsoc.org/KAB22.htm.

However, we have discussed a different approach where the way in is via the original documentation (which we have), with links into the actual source text, rather than embedding links to the documentation within the source text.

KDF9 emulator

Bill Findlay continues to develop his KDF9 collection. He has recently implemented Pascal, demonstrating what an excellent target machine KDF9 was. He has called it PasKal.

ICT/ICL 1900 — Delwyn Holroyd, David Wilcox, Brian Spoor, Bill Gallagher

PF56 Emulator (2812/7903)

David’s PF56 emulator is now working sufficiently well that Brian has been able to do some fairly extensive testing. Progress is good, in that he is managing two to three hours system up time.

Brian’s test environment is an emulated 1904S, with two channels of discs, under E6RM (Multi-programming Operators Executive – MPOE), running MAXIMOP, GEORGE 2 and some applications under direct operator control. The screenshot at ccsoc.org/1900ss0.jpg shows, from left to right, the 1900 operators console, card reader being used by the G2 Input Module, two terminals connected to MAXIMOP (one running a COBOL compilation, the other a PLAN compilation) and the two PF56 consoles running as 2812 disc controllers using original ICL DCPs (dedicated control programs). The top 2812 is running EZDD, for dual access ED60s (2^nd system not running) hosting the application discs, the other EZDB for single access ED60s hosting the System, MAXIMOP and GEORGE 2 discs.

Reducing the size of the PF56 window is being looked at, as it takes too much screen real estate at the moment, but bug fixing is the priority. However all the applets can be run minimized.

These efforts are likely to be followed by efforts to implement the 7210 IPB, which would allow Shared Filestore, as well as inter-processor applications such as Comms Manager.

That leaves only leave the local VDU system and 7930 scanner to be implemented for connection to the 1900 and also the 7930 scanner to PF56 in its 7903 guise.

Code Reviews

Bill and Brian have started a code review/clean as part of a general tidy getting ready for a general release on Windows. The 1901A emulator has been similarly tidied. The 1904S and 1905 emulators still need further work before getting to this stage.

GEORGE 2+DOF/1T

This was a custom version for Tarmac, commissioned circa 1978 for its two new 2950 machines, later upgraded to the 2966 currently on display/working at TNMoC. The project was never completed (to the best of our knowledge), being abandoned due to cost over runs when around 95% complete. Brian reports he has recently picked up something he started several years ago, recreating the source from the binary issue tapes that have survived.

He has now successfully recreated sources for all of the batch modules, which when compiled binary compare with the original tapes. The system has gone from limping to walking as he has added patches, some of which seem familiar from back in 1979; unfortunately, the original patches never survived with the binary issue tapes. So far, a few simple jobs have run from job entry via cards through processing to being output on the printer.

A fair amount of work is still required to get the batch side of the system fully running, then the real fun starts with the custom RJE module.

Bletchley Park Trust — Peronel Craddock

The restoration of Block A is complete and two new exhibitions are now open to the public:

The Intelligence Factory, the largest exhibition space on site, looks at how Bletchley Park’s potential as an intelligence organisation was unleashed in the second half of World War Two.

The Art of Data: Making sense of the world , the first exhibition in our purpose build temporary exhibition gallery, demonstrates some of the ways the Codebreakers visualised data alongside contemporary examples, including 3D, animated and interactive visualisations.

Peronel is moving to a new post. We would like to thank her for her reports over the years and wish her well for the future. [ed]

SSEM — Chris Burton

The Science and Industry Museum Covid restrictions are slowly being alleviated, giving volunteers greater confidence to attend. The Baby continues to be demonstrated on three days per week, and despite the occasional minor fault can normally be restored quite quickly. Care is being taken to try to ensure that the machine remains demonstrable for the IEEE plaque activities on 21^st June.

A recent photo opportunity was a visit by Michael Portillo and Professor Steve Furber to see the machine, pictured below with volunteers Vincent Gethic and Tim Banks.

Harwell Decatron — Delwyn Holroyd

In my previous report I wrote that one pair of EL360 series regulator valves in the power supply would soon require replacement. As it turns out, they’re still going strong but an EL33, another large power supply valve, has failed. This valve supplies the switched anode voltage to the Transfer Units in the Arithmetic unit. Prior to diagnosing the problem, we had experienced a few weeks of unreliability with the machine stopping due to failure to circulate stores, seemingly at random. We now know this was because the switched anode voltage was falling, until it got to the point where essentially nothing worked! This voltage is not easily monitored, but it is something we will keep an eye on in future checks along with the similarly supplied carry unit switched anode voltage.

Our Computer Heritage — Simon Lavington

The sections describing the English Electric KDN2, KDF6 and KDF7 group of machines and the KDP10/KDN8 computers are now in place. An extra illustrated &lsqou;Appendix’ giving the story of the first KDP10 installation in 1962 to the Commercial Union’s new Computer Centre in Exeter has been written and uploaded. This case study, which may be found at ccsoc.org/ochee0.htm, describes some ground-breaking innovations in the application of general-purpose computers to large insurance companies. It is hoped eventually to produce a shorter version of this 24-page document, suitable for submission to Resurrection. The sections describing the English Electric KDN2, KDF6 and KDF7 group of machines and the KDP10/KDN8 computers are now in place. An extra illustrated ‘Appendix’ giving the story of the first KDP10 installation in 1962 to the Commercial Union’s new Computer Centre in Exeter has been written and will soon be uploaded. This case study describes some ground-breaking innovations in the application of general-purpose computers to large insurance companies.

Nigel Bennée has made navigational improvements to the OCH sub-structure which have restored end-user access to the four Appendices of extra technical information on aspects of the Elliott 400 series of computers.

CCS Website Information

The Society has its own website, which is located at www.computerconservationsociety.org. It contains news items, details of forthcoming events, and also electronic copies of all past issues of Resurrection, in both HTML and PDF formats, which can be downloaded for printing. At www.computerconservationsociety.org/software/software-index.htm, can be found emulators for historic machines together with associated software and related documents all of which may be downloaded.

News Round-Up

In an unlikely corner of the BBC’s news website (the sports section) we find an article about the use of the Ferranti Atlas 1 computer at London University to analyse football matches in the late 1960s. Eventually this work sems to have been used not just to predict results but to advise team managers on strategy. Go to www.bbc.co.uk/sport/football/61084931 for more information.

101010101

Deftly switching channels to ITV, readers may remember that in Resurrection 93 we reported that various CCS members had been contacted by the production team of the then forthcoming remake of The Ipcress File. We were asked how best to represent the Atlas computer doing some information retrieval. When the series was finally broadcast a few weeks ago, computers were pointedly absent. Perhaps it was deemed too difficult. Perhaps we were striving too hard for authenticity.

101010101

As so often Herbert Bruderer has lifted up a stone and, on this occasion, has found something quite disturbing. ccsoc.org/bru6.htm tells of “forced labour” at a Swiss arms factory in which an early Zuse M9 calculating punch was in use. Shockingly, the use of “difficult to educate” young girls continued into the 1960s in an arrangement which seems strikingly similar to the Irish “Magdalane Laundries” scandal which has been exposed in recent years.

In an earlier post he draws our attention to the Spanish engineer Leonardo Torres Quevedo (1852-1936) who built several mechanical calculating machines and wanted “to realise the dreams of Charles Babbage”. Something of a polymath he also designed an aerial cable car at Niagara Falls. ccsoc.org/bru7.htm is recommended.

101010101

It is with great regret that we hear of the passing of Mary Coombs, the world’s first female commercial programmer. The Guardian obituary by Georgina Ferry is particularly comprehensive, but precedence must surely be given to that published by the LEO Society.

101010101

And it is sad to report the passing of Prof. David Howarth best known for his magisterial contribution to the Supervisor (operating system) of the Ferranti Atlas 1. David is remembered for his kind and ever-helpful demeanour.

101010101

The Centre for Computing History is marking the 40^th anniversary of IT82 with a series of events and exhibits.

IT82 was a public education programme run by Government and industry with the aim of convincing a sceptical British public of the opportunities and benefits provided by information technology. In the early 1980s, fewer than 20% of the population had heard of Information Technology (IT), and most British firms were not using microelectronics or Information Technology in any way. Those who had heard of IT were often wary, afraid that their jobs were at risk of being replaced by a robot.

To tackle this mistrust, Prime Minister Margaret Thatcher and Kenneth Baker, Minister of State for Information and Technology, proclaimed 1982 to be “Information Technology Year” and launched the £3.75m IT82 initiative.

IT82 consisted of a series of public events around the United Kingdom, together with supporting pamphlets, videos, and interactive demonstrations to engage visitors. The public could see “The Office of The Future” in a mobile exhibition unit that toured the country, and both the Design Council and the Science Museum held major events to tie in with IT82. The Royal Mail released two commemorative stamps to mark the occasion.

Curator of The Centre for Computing History, Jason Fitzpatrick remembers visiting an IT82 exhibition as a child: “We hadn’t planned to go. I was out shopping with my mum in Chelmsford city centre, we saw the IT82 logo and popped in to see what all the fuss was about. Inside were all kinds of computers and devices that you could touch and play with – I found that incredibly exciting, being able to interact with these machines for the first time in my life.”

On the 8^th of December 1982, Margaret Thatcher delivered a speech to an IT conference held at the Barbican Centre, London where she gave her assessment of the impact of IT82: “[Now] more than six out of every ten of the population have heard of information technology. At the beginning of the year, fewer than two in ten had heard of it.”

For Jason Fitzpatrick, the legacy of IT82 was more personal: “I came away from the event with a fantastic sticker with the IT82 logo on it. I stuck it to my red tape cassette storage box that held my ZX81 games collection, and there it stayed for many years. I remember IT82 as being a key childhood moment that helped spark a lifelong obsession with technology.”

Today, Information Technology is vital to almost every aspect of our everyday lives. In 1980s Britain, IT82 certainly helped spread the word about an emerging technology that was soon to explode in importance.

101010101

Queries and Notes

The Arcturus 18-C Minicomputer

Ian Moffat gets in touch to show us this extract from New Scientist. So now we have evidence of a second Arcturus computer model, the 18-D. More than that we also find another mystery minicomputer maker – Aardvark Business Computers Ltd.

No, neither had I. But somebody out there must know something. If you do, please get in touch.

Obscure Publications Search Appeal

Matthew Neilson writes – I’m hoping that you might be able to point me in the right direction in terms of sourcing some weekly UK trade papers from the 1980s and 1990s. Specifically, I am attempting to find the following:

1. MicroScope, Volume 4, issues 27-34, 36, and 50 (September 5^th 1985 through to December 5^th 1985).
2. Computer Trade Weekly, issues 304, 317, 318, 325, 332, 336, 339, 341, 342, 345, 355, 360, 367, 368, 377, 380, 387, 388, 412 (September 17^th 1990 through to November 9^th 1992).
3. Computer and Software Retailing, any issues from 1984 and 1985.

He’s tried all the obvious places such as the legal deposit libraries and the publishers without success. Anybody?

Rocky Mountain Basic

In Resurrection 97 Ron Weeden appealed for anybody interested in Rocky Mountain Basic to get in touch. Antti Louko from Finland made contact. Files have been exchanged. A little happiness was spread around.

As our esteemed Chair points out it is gratifying that Resurrection has such outreach.

MONITOR – An Early Transaction-based System

This paper has a technical focus and looks at the MONITOR Operating System developed by Post Office Telecommunications, International Computers Limited (ICL) and Computer Sciences International (CSI) in the 1970s. Whilst this was a relatively obscure piece of software engineering, it was fundamental to a key Critical National Infrastructure application and addressed many of the online challenges that were becoming important at this early stage in the evolution of corporate IT.

The goal is to describe how the operating system came into being and its basic structure, showing where and how it was successfully deployed and its ultimate demise. It will begin by describing the London Airport Project and the origins of the National Data Processing Service (NDPS), the Post Office department that delivered it. This will be followed by a description of MONITOR and its structure and the role in data communications. Its deployment across the airport system and other Post Office systems are then described, before the final conclusions are drawn.

Post Office IT

The Post Office was an early adopter of IT and built its strategy on LEO computers, migrating to a strategy based on The English Electric System 4, once English Electric (later ICL) had acquired LEO. Ultimately the LEO range was discontinued. The System 4 was a copy of the RCA Spectra 70 which was architecturally compatible with the IBM 360 and produced under license. The Post Office introduced its first System 4/70 costing £800,000 in March 1969.

System 4 Architecture

Here is a generic representation of the System 4 architecture. The configurations used for MONITOR incorporated four duplicated EDS30 discs, with a capacity of 30Mb, which were later updated to EDS60s. Initially the 4/72s had 256K Bytes of memory, first updated to 384K and ultimately 512K.

In 1967, the Post Office (Data Processing Service) Act permitted the Post Office to offer commercial data processing services. NDPS was prevented from cross subsidising its normal business from its data processing business and vice versa.

The System 4 series ran a batch operating system known as J (for Job) and a variant that allowed interactive access called MultiJob. The System 4 assembly language (known as Usercode) non-privileged instruction set was almost identical to IBM System 360 Assembly Language; although in privileged mode there were some additional instructions.

The London Airport Project and NDPS

MONITOR was designed and developed as a real-time transaction based operating system capable of supporting large numbers of terminals, by a composite team from NDPS, ICL and CSI in the late sixties and early seventies. It was required to support a system designed to meet the requirements of the LACES (London Air Cargo EDP System) project, which managed imports coming into Heathrow. This was a requirement significantly beyond what J could offer. The precise role of each partner is unclear, although the evidence points to a strong engineering and project contribution from CSI during the initial development, with the Post Office, who operated the service, taking contract ownership. The aim was to deliver a 200 terminal system available during 1971; at this stage B.O.A.C.’s Boadicea airline seat reservation was considered the largest on-line system in UK operation with more than 700 video terminals.

LACES went live in September 1971 and initially operated at Heathrow, before being extended to Gatwick Airport. It controlled the movement of about 30% of the nation’s overseas trade, streamlining the clearance of imports through customs and speeding the despatch of exports on a 24 hour basis and lowering the cost of tracking consignments for users.

Its successor the Air Cargo Processing in the 1980s (ACP 80) had a wider scope, covering both exports and imports and had an ability to handle twice the number of terminals, interface with DEPS, and make use of the Post Office’s Packet Switch Stream (PSS) service for communications with the cargo computer systems of five of the airlines. It was due to replace LACES in October 1981. The original aging Cossor terminals were to be replaced by terminals from Videcom. The ACP80/DEPS system was extended to Manchester for May 1983, requiring the installation of almost 100 terminals in and around Manchester Airport. By this stage the System 4 was no longer a key part of ICL’s strategy and MONITOR was delivered using ICL’s Direct Machine Environment (DME) and the 2960 platform.

MONITOR was designed for 24 hour operation and to perform live data updates at the record level without data loss and corruption. It had complete control of the hardware, allowing better handling of hardware and software faults and permitted configuration changes to be made to the running system. The database was duplicated and could be spread across multiple discs to allow maintenance with LACES using four disc pairs. Database recovery was an essential part of the design. One disadvantage of direct control of the hardware was a conflict between simultaneous access to the same data on the same processor by the online service and background activities on the same processor, an issue that was never satisfactorily resolved.

The result was that MONITOR systems could run uninterrupted for many days, recovery from hardware failure was very robust, and service restoration was quick The design was very adaptable, but applications had to be coded in Usercode, impacting programmer productivity and requiring J to be used to generate object code. Response times met the demands of the applications users, even when features aimed at securing data were added.

MONITOR and its structure

This description of MONITOR is derived from three papers produced by Mike Atkinson, who focuses on the need for parallel operation, memory management and queuing for services e.g. CPU and channel. As would be expected the nature of the System 4 machine hardware forms a crucial part of the discussion. The ICL (English Electric) System 4 was based on the IBM System/360 architecture and was suitable for real time applications, having four processor states, each with its own set of general purpose registers, although some did not have all 16. This design allowed for switching between processor states without the need to save registers. Priority was expressed in ascending order, P1 being the user state, P2 the interrupt response state, P3 the interrupt control state and P4 the emergency state. P1 and P2 used all 16 registers, P3 6 and P4 5.

The Root segment of MONITOR was analogous to the kernel of other operating systems, operated in states P2 to P4 and handled resource scheduling and dispatch, task synchronisation and recognition, interrupt control and provision of primitive services. Primitive services were operating system services that were invoked using either an SVC (supervisor call) software interrupt or a PC (Processor State Change) instruction.

MONITOR was designed for a predominantly online transaction processing environment, when such systems were relatively rare and needed balance program or task execution and input output (I/O) activity. The ability to manage the access to system resources through queuing systems and the use of re-entrant code were key aspects of achieving this. Queues were anchored at fixed memory locations and took the form of linked lists of control blocks, interconnected using forward and backward memory pointers. An empty queue is signified by both the forward and backward pointers from the head of the queue or anchor pointing to the anchor itself. Units of computational activity are known as tasks and these are represented using entities known as a task administration blocks (TAB), which when the task was active were inserted into the queue for the CPU. A task could also spawn requests for access to system resources, represented in memory by Request Admission Blocks (RAB). This method of providing a multithreaded environment using linked lists of control structures is a common approach in transaction processing systems.

The requests represented by a RAB were executed asynchronously, as the service queue that each were allocated to was processed. The linked list mechanism avoided the inefficiencies associated with the option of allocating contiguous areas of memory to control structures. A number of MONITOR primitives were associated with the processing of these activities, for example primitives Q (queue) and UNQ (un-queue) respectively added and removed a control block to or from a queue; whilst the WT (wait) primitive tested if a RAB had been processed and if it had not the RAB was marked to signify that its parent task was waiting for it and the associated TAB was removed from the CPU queue. The UNWT (un-wait) primitive was used to synchronise the activities of the primitive and the task or of two primitives; it tested whether a request was active and if it was not it was queued to the appropriate server. QWT (queue wait) was another queue manipulation primitive, which placed a RAB in a specific queue, putting the parent task in a wait state.

The Wait Control Word (WCW), which was normally held at a fixed location within the requesting control block, was used to maintain synchronisation between activities. Tasks were allocated a priority between one and seven, which was held in the TCB and persisted for the duration of that task. Each priority had its own queue, but only tasks of priority 7 could pre-empt lower priority activities that were already in progress, otherwise priorities were re-evaluated when a TAB had either been removed from the CPU queue or had entered a wait state and the task dispatcher was called. When a task was waited its TAB was removed from the CPU queue and added to a queue representing the reason it is waiting.

Monitor Control Structures

On the previous page is a simplified example of queue operation and features a single CPU queue and one service request queue. Task x, represented by TAB (x) serves the server queue Q (x) and since it is at the head of the CPU queue it is scheduled for execution. Tasks y and z have requests queued to x (represented by RAB(y) and RAB (z) respectively). Task z has issued a QWT for RAB (z) on Q (x), whilst task y has issued a Q for RAB (y) and continued processing until it was rescheduled. Task x retrieves RAB (y) from Q(x), provides the required service and issues an UNWT for task y which was still active, it is flagged as being not busy and an UNQ is issued for RAB (y). Task x can then move onto deal with RAB (z), which it services and issues an UNWT for, since task z is in a wait state, a Q is issued specifying TAB (z) and its CPU priority number, re-establishing it in the CPU queue.

Task x finds that Q(x) is empty and “waits” itself; pending the arrival of more work, by UNQ-ing itself from the CPU queue. Task y is at the head of the CPU queue and can resume execution, processing the data provided by the x service until it runs into a wait condition and is UNQ’ed. Task z can then be scheduled for CPU, which if uninterrupted will run until it reaches a wait condition.

As processing moved between tasks it was necessary to retain the current status of a waited task, preserving the state of its registers, program counter, hardware program masks and condition codes in the TAB, for when the task was restored to activity.

Task Execution

MONITOR users could place themselves into training mode which diverted file access requests to training rather than live datasets. This state was reflected in a status bit held in the TAB, whilst the nature of a given file was held in a file definition table. An additional task mode allowed a new version of software to be tested alongside live software. Up to three different applications subsystems, known as projects, could be run under one MONITOR instance. A terminal could specify which project it wished to access at start up, but could not then be transferred to another project. When a TAB was extinguished its state was captured to a block specific to that terminal, in a disc file known as the VDU Slot File. From here it could be restored once new input arrived, hence providing continuity. Below we can see an overview of task processing.

Perpetual tasks included functions, which co-ordinated task execution with external presentation, such as Video Control and Lineprinter Output and were initiated at system start-up. They should neither terminate nor exceed their CPU allowance and their TABs were in known memory locations.

Video control handled the polling, retrieval of input and delivery of output to and from a user’s terminal. This process was un-waited by an interrupt from either the communications hardware or system clock, which interrupted every 110 milliseconds. Lineprinter output used a spooling mechanism and was waited while an I/O operation was in progress to either a printer or output was being spooled to disc and reactivated when the current operation ended and an interrupt given. If the spool file was empty the task waited itself, until it was un-waited by the clock control feature.

The clock control feature was another perpetual task which relied on the System 4-70 hardware clock, which was set to interrupt every 110 mS. On interrupt, this updated the interval counters for the perpetual tasks it is aware of and identified any tasks that needed to be woken-up and un-waited and restored them to the CPU. Perpetual tasks could also execute privileged instructions.

The MONITOR code hierarchy is shown below.

User tasks made use of the MONITOR database system’s recovery and logging system, to ensure the integrity of data. This involved perpetual tasks, as did managing the response to the terminal and lineprinter handling tasks. MONITOR functions were typically invoked by the application issuing a supervisor (SVC) call.

The interaction between the application and the database

The system design was built on the principle that application code should be as independent as possible of how data was held in the database and the mechanisms involved in system recovery should be invisible to the applications programmer. In the event of a system failure, there was uncertainty at the applications level whether updates had been carried out. Updates were not applied to the database until it was certain that all updates that a task could generate had been secured, at which point a response was sent to the user that all updates had been trapped and buffered. The logging system could then secure the updates to tape and update the database immediately after this had completed. If the system failed, the logging tape was rewound to a point where it was known all updates had been successfully applied. Then subsequent transactions could be read from tape and applied to the database.

The file management interface gave the application programmer key based access to the database, instigating file functions through an SVC call. To manage record retrieval, file permissions had to be checked, ensuring that the record was not already being accessed for update. Records were read into a memory buffer allocated from a buffer pool. Logical I/O mapped file requests down to the block level and translated them to track and cylinder level access using a structure known as the Channel Command Block (CCB), creating a similar CCB for duplicated volumes, before passing the request to the physical I/O function. Physical I/O ran asynchronously and was part of the root segment, causing the TAB for the application to be waited while physical I/O proceeded using the CCBs set up by Logical I/O. It added a CCB to the appropriate device queue and when it reached the head of the queue, deleted any duplicate CCB from any other device queue, thus optimising block retrieval time.

If the I/O was successful, control returned to File Management, however Logical I/O trapped a failure if a record could not be read from either disc volume, the need for manual intervention was then signalled to the operator and an application error issued. The process was similar for a write request, but the block to hold the record should have already been in memory, from the preceding read and record locking operations. The write request was buffered in memory by File Management after its legitimacy had been verified and was held in a chain of updates, which were applied to the database at the task’s conclusion. Should the task have terminated abnormally the updates were discarded. The application task notified MONITOR of a satisfactory conclusion through an SVC call. Relevant application data such as management, historical and statistical data were then written to the dual log tapes, as is the identity of the earliest block on the log tape holding updates not yet completed. Once this was done the video task could be instructed to send the response to the user and File Management can be requested to carry out the writes to disc and drum. Logical I/O instigated duplicate writes to the dual volumes and verified a sample of these writes for correctness. This is summarised in the diagram above.

The scan and re-application of updates during recovery could be rapidly done by reading the log tape in the reverse direction, until the last complete logging sequence was found, allowing the earliest task still in its update phase to be identified. Updates, excluding those of tasks which did not complete logging, could be safely re-applied to the database from this point.

ICL provided a micro-coded System 4 emulation on the 2960, using a version of direct machine environment (DME) for the System 4, capable of running J, Multijob and MONITOR and their respective application programs with about the same throughput as a 4/70. It also contained microcode for I/O channel command conversion, since the I/O interfaces between the processor and channels are always to 2900 standards.

MONITOR was also adapted to run on IBM’s 4331, which was subsequently used for all maintenance work on the MONITOR system and general program language development. It was adapted with the minimum work necessary to make it look like an IBM system and several MONITOR test slots, each in its own virtual machine, could run concurrently on one machine. The Conversational Monitor System (CMS) was used to provide development facilities and terminals from the ICL network could be interconnected using a CASU microprocessor. In particular, centres were able to run J under MONITOR, allowing programmers to amend code on a MONITOR terminal, before submitting it to the J batch input queue, using Remote Job Entry.

These developments extended MONITOR’s life as the System 4 became obsolete; the last system being removed from the Harmondsworth Data Centre, which ran LACES, in April 1983.

Data communications

The MONITOR system handled its remote video terminals through a standard poll response, basic mode protocol (ICL’s C01) managed using the Video Control Task (also known as Basic Comms), which was a permanent task initiated at system start-up. This was un-waited by the clock control mechanism once every 110mS or by an interrupt from the communications controller. The mechanism first identified any inputs were likely to overflow their input buffer, in which case another CCW would be chained to the channel program, pointing to another 128 byte buffer.

The Video Control Task could also be un-waited on completion of an application task if it needed to issue a response to a terminal, completing any outputs to the line before issuing a fresh poll. The polling frequency was dictated by the polling parameters configured by the line in question and the availability of memory to accommodate any input message received. Once an input had been satisfactorily received, the complete message would need to be assembled from the 128 byte buffers identified by the chain of Channel Command Words (CCWs) representing the read. The input would initially be processed under control of the Video Control Task, before being processed by other operating system functions prior to being queued to the target application task, with continuity data being held in the terminal specific slot file. The design of the system required that all updates would be held pending until the task was complete. The complete message would need to be presented to a common subroutine. Once the Video Control Task has completed the available work, it was waited.

As the demands for new systems increased, it became apparent that the System 4’s standard communications multiplexers would be unable to cope with the speeds and the number of interfaces required. The communications capability was offloaded to a Front End Processor based on the ICL 7905 common control units, which had a 56K memory and was based around CTL’s Modular One. This was driven by a modification to the Video Control Task, which treated the 7905 as a fast video controller and allowed transfers at the block rather than the buffer level.

In its original form the 7905 interfaced to 1900s using the 6-bit wide 1900 Standard Interface was called a Local Processor Link to Nineteen Hundred (LPLN). The unit was adapted to use the 8-bit wide System 4 Standard Interface by ICL’s Letchworth Development Centre. Code conversion between 8-bit EBCDIC on System 4 and 6-bit 1900 code on the 7905 was performed by hardware in the Local Processor.

ICL 7905 Hardware

The 7905 was capable of supporting bit synchronous as well as byte synchronous communications and was widely deployed in conventional ICL networks. The Post Office’s need to adopt it seems to have been initially driven by internal applications requirements; the system was also developed to support X.25 as well as the traditional ICL C01 protocol. The ACP-80 system used the PSS packet-switched data service to carry cargo information between the ACP-80 computers and the computer systems operated by six major world airlines. Customs, agents and the 32 airlines served by the bureau accessed the ACP-80 computers through terminals in their offices.

Where it was ultimately deployed

As well as LACES, MONITOR was used for the RAF stores system between 1972 and the 21^st century and used within the Post Office/BT as the basis for systems supporting online data entry for input into the payroll and billing systems and also for systems controlling and monitoring infrastructure work both internal and external to Post Office premises. In addition to mainframe centres (seven by the summer of 1981) there were 15 IBM 4331 machines running MONITOR. There was also commercial activity with CSC to sell a MONITOR-based system to Miami International Airport.

Application development involved the use of Usercode, and all assemblies were performed as batch J jobs and testing was awkward. So the Post Office and later BT developed SL1, a high-level language for use with MONITOR; however this was never used in production. A language pre-processor known as SAL (Structured Assembler Language) was available to translate structured, high level statements into Usercode prior to assembly. The Post Office also developed GENFAC, a query language, which provided a report writing capability for MONITOR. GENFAC was developed after failing to persuade Mathematica, the sellers of RAMIS, to port their package onto ICL’s machine. An enhancement to MONITOR was planned to enable it to become part of an ICL IPA RSA (Remote Session Access) network, allowing remote access from MONITOR terminals to VME and vice versa.

A dual-processor system was developed as part of the original CSI contract to manage increasing workloads and whilst this was not needed for LACES, it was deployed on the RAF implementation where it supported more than 550 Cossor terminals. The two linked System 4/72 systems achieved about a 50-60% increase in power over a single processor system. Each processor viewed the other as being one of its peripherals, with terminal handling largely allocated to one machine and database handling to the other.

Key Conclusions

This paper has a technical focus and has looked at the MONITOR operating system developed by Post Office Telecommunications in the 1970s. It has described how the operating system came into being; its basic structure and how it was deployed and its ultimate demise. The reader will have identified that MONITOR had many design features in common with other operating systems. It was never marketed externally and ultimately became increasingly less used for internal projects as BT’s CSS (Customer Service System) developed using standard operating systems and utility packages such as the IDMS database system. Its remaining use was support of ACP-80 and its successor ACP-90.

Extension of the air cargo contract beyond ACP-80 looked uncertain, when Travicom gained the contract to develop a new generation of cargo system. NDPS being excluded from further involvement in its development. However, the replacement Travicom system appears to have been a significant failure. Users reverted to ACP-80, the contract for which was due to expire at the end of June 1987. The new system was scrapped and ACP-80 was retained indefinitely. BT further developed its capability in the form of ACP-90. In 1993 a new company CCS-UK was launched, which delivered a new-style community system that replaced ACP-90. The new system was attractive due to changes in the IT climate and improvements in data communications. BT appears to be the operator of CCS-UK.

These developments removed the requirement to continue to develop and maintain MONITOR.

Acknowledgement

An initial draft of this paper was reviewed by Tony Dickson, Bob Harris, Hillary Jordan, Chris Melluish, Linda Porter, Ted Rogers and Mike Ruffle, who worked on the system and gave valuable editorial input supplying insights not available from the literature. In addition the help of BT Archives, in permitting the adaptation of diagrams from BT publications, is gratefully acknowledged.

Resurrection Matters

Subscriptions

May we beg to bring to your attention that the current Resurrection subscription period ends with this edition. BCS members and certain former BCS members receive free copies, but others who wish to receive paper copies of Resurrection should go to www.computerconservationsociety.org/resurrection.htm to renew or take out their subscription – £10 for the next four issues. Please work through the flowchart on the back cover to make sure you need to pay.

Back Issues

The Society has recently embarked on a campaign to bring some order to its keeping of records. We have discovered a cache of pristine copies of early editions of Resurrection and, rather than sending them for recycling, we thought that members might like an opportunity to complete their collections for the cost of postage. Contact if you’re interested.

Yes, I know that it’s not likely that Resurrection 34 will sell out, but there’s always the recycling man.

Interlisp Restoration Project

Steve Kaisler

Interlisp was a software development environment developed at Xerox PARC in the 1970s and 1980s to support research in many areas including artificial intelligence, graphical user interfaces, and computer supported collaborative work using hypertext. The software has many versions as it evolved over 25 years.

The 1992 ACM Software System Award was awarded to the Interlisp system for “ ... pioneering work in programming environments that integrated

• source-language debuggers,
• fully compatible integrated interpreter/compiler,
• automatic change management,
• structure-based editing,
• logging facilities,
• interactive graphics and
• analysis/profiling tools.”

Interlisp.Org is a project led by some of the original developers and users of the software, with help from Lisp and open source communities. This team is working to restore and adapt the Medley version of Interlisp to modern computing infrastructures. The project will allow others to experience this seminal Integrated Development Environment (IDE) as well as a number of applications written in and for it.

The Interlisp.Org team is interested in how to preserve an idea and an experience through reviving and adapting it for the next generation. Exposing newcomers to the Interlisp software and inspiring experiences with it are central to the team’s preservation practice. They believe that saving the source code alone isn’t enough to preserve the software, and are working to revive Interlisp and adapt it to be useful in the modern world.

The Interlisp.Org team’s goals include:

• Support researchers studying the history of software development paradigms, graphical user interfaces, hypertext, AI and other software methods
• Build a case study for preservation of source code, algorithms, and software history
• Invite interested researchers and potential users to participate in the revival of Interlisp

For more information, please contact the Interlisp.org team at: or visit our website: interlisp.org.

Obituary : Len Hewitt

Leonard (Len) Hewitt, who led the Pegasus project for many years, passed away on April 25^th 2022.

Len spent two years with Marconi after National Service in the RAF, and joined Ferranti in mid-1955 and helped install the Mark 1* at Avro in Chadderton. He left Ferranti in mid-1957 to maintain a Pegasus computer at ICI. Later he transferred to the company’s programming department before joining Legal & General to run their company network.

Pegasus at the Science Museum was, for many years, the oldest extant working electronic computer in the world and was maintained and regularly demonstrated by a team of CCS members led by Len. The Pegasus computer they restored was originally installed at Skandia in Stockholm in 1959.

Since sustaining an electrical fault in 2009, Pegasus has not been demonstrated and the Science Museum has now retired Pegasus to its stores.

Len received the BCS Volunteer Recognition of Appreciation award in 2017 for his 25 years of volunteering from 1989 until 2014.

Thanks are due to Len and members of the Pegasus Team who toiled valiantly to bring this venerable machine back to life and keep it that way for so long.

Len at the controls of Pegasus on its last working day at the Science Museum

50 Years ago .... From the Pages of Computer Weekly

Bank network to cover US, Europe: An international message switching network which is likely to generate over £1 million worth of equipment and software orders is to be developed for 73 banks in the UK, Europe and the US. The decision was taken a few weeks ago at a meeting in Miami of the project steering committee for the banks involved, which include all the London and Scottish clearing banks, and was based on the results of the design study commissioned last year from Logica. The network is required to speed up the growing volume of international payments, currently averaging over 250,000 messages a day, which are at present transmitted via telex services. The changeover to the network is provisionally set for 1975-6. (CW 1/6/72 p1)

905 aids net results: Improved design and more ergonomic use of trawl nets is expected to result from an experiment undertaken by the United Nations Food and Agricultural Organisation based in Rome. A telemetry system has been designed to measure the behaviour of the nets in operation, and the results will be processed by a GEC-Elliott 905 computer on board ship. GEC-Elliott will also supply a Hydroplot system to monitor the depth and position of the trawl net. Other components of the system will be manufactured and supplied by Micro Consultants of Caterham, Surrey. The guts of the set-up is a high integrity multichannel analogue-to-digital measurement system utilising a multi-comparator technique, which will convert the signals discharged from pressure transducers attached to the net. This measurement system is known as AN-D1 1210M, and is similar to the system used by Redifon Simulators in its Category A flight simulators. All the electronics will be encapsulated in waterproof pontoons which can be up to 2,000 metres from the towing ship, and connected to it by means of a four-core armoured cable. Various automatic monitoring devices have been incorporated into the system to ensure integrity of data. Work has been progressing on the system for two years and is now nearing completion, with field tests scheduled for this month in the Polish fisheries research vessel Gdynia. (CW 1/6/72 p3)

BEA’s development IMPACT leads world: Following some six years of development and the use of hardware with a capital value of £11.4 million, BEA is now operating one of the world’s most advanced airline management systems. Known as IMPACT, standing for Integrated Management Planning and Control Techniques, the system has emerged as a result of an explicit strategy by the airline to guide all its computer development projects to produce a truly integrated system of computer aided planning and control for managing its business. BEA’s original objective was and still is to gain maximum benefit from the use of its computers. When IMPACT was first conceived in June, 1966, BEA was already using the first fully automatic seat reservations system in Europe, BEACON. Many of its administrative tasks such as revenue and ticket sales accounting, interline billing and traffic analysis had also been computerised. However, there was still a need to integrate both existing and projected computer operations into a total system which was given the designation IMPACT.

In the management area BEA had seen the principal scope for development in two main directions; basic airline operations in addition to seat reservations, and strategic and operational planning involved in the conduct of the airline business. In the planning area computer models were used to either predict the likely outcome of alternative courses of action or to determine the action needed to optimise results. The advantages of linking automatic control systems and computerised decision models with systems for handling the routine collection and processing of data were also considered to be significant. (CW 15/6/72 p1)

Jobbers’ workload handled on NDPS centre’s Leo 326: The increase in business on the London Stock Exchange in the past year has been so great that member firms, even using computers rather than traditional clerical methods, are having considerable difficulty in meeting data processing demands. One of the largest firms of jobbers, Wedd Durlacher Mordaunt Ltd, made plans some time ago to transfer its requirements to the ICL 1904A of Datasolve International Ltd in August this year, but even they have been overtaken by events and their own Leo 3 is now unable to cope. In this predicament the firm looked around for a fairy godmother and found one in the National Data Processing Service of the Post Office, wellknown Leo users. The result was a decision to close down Wedd Durlacher’s Leo 3 ahead of schedule and to mount a large-scale bridging operation, transferring the entire workload to one of the Leo 326s in the NDPS Kensington Computer Centre. This was done in March with no break in Wedd Durlacher’s operations, and in fact use of the faster machine has given the firm a vast improvement in the turnround of information. Paper tape from Wedd Durlacher’s office is delivered nightly to Kensington, the work is processed overnight and the results available for the start of business the following morning. The NDPS is currently running three Leo 326s with a fourth expected to start operations at the end of this month. This is a new machine, the last of the five produced by ICL for the NDPS on specially reopened production lines at Kidsgrove, and brings the total Post Office strength up to 10. Of the others, two are installed in Derby and one each at Portsmouth, Edinburgh, Cardiff and Bristol. (CW 22/6/72 p16)

Low-cost memory series from DEC: Two established memory products for Digital Equipment minis have been superseded by newer models. The new RK05 DECpack cartridge disc file is manufactured by DEC, unlike its predecessor. This has resulted in an enormous price reduction from £4,030 to £2,460. The ME11-L core memory unit, which has been redesigned, is also reduced in price, from £3,510 to £2,510 for 8K, with supplementary add-on units of 8K at £2,120 each up to the maximum 24K. The RK05, which can be used with both PDP-8 and PDP-11, is a moving head disc system with a capacity of 2.45 million bytes per cartridge, this being easily removable for storage. Up to eight units can be handled by the same controller. Data transfer rate is 1.44 million bits per second, and average access time 50 milliseconds, compared to 70 for the earlier version. If more than one drive is in use, access time is decreased because of an overlapping feature that allows one drive to seek a new position while another is reading data from an already selected position. Heads are positioned by a voice coil linear motor with an optical position transducer accurate to within 100 millionths of an inch of true position. The absence of mechanical detents in the positioning mechanism eliminates a major source of wear and critical adjustment. The ME11-L is a self-contained core memory system for the PDP-11 mounted in a separate box and so freeing processor space and power for other uses such as peripheral interfaces. It connects directly to the Unibus. Cycle time is 900 nanoseconds, and the ME11-L is available in 8K, 16K and 24K sizes. (CW 29/6/72 p3)

Flat screen terminal introduced by Burroughs: A miniature visual display terminal which uses a revolutionary flat screen with a dot matrix has been announced in the UK by Burroughs. Known as the TD 700 Self Scan Terminal system, the unit is claimed to use 90% less drive electronics than a conventional VDU. The TD 700 is the result of some three years development work by Burroughs in a bid to get away from the traditional cathode ray tube display. With the new unit Burroughs hopes to make a considerable impact on the rapidly expanding terminal market which has been estimated as being worth £42 million a year by 1975 and £95 million by 1980. Price of the TD 700 ranges from £1,200 and the unit will be available for delivery in the autumn. The TD 700 comprises three modular components, the display panel, a keyboard and a control unit. The display and keyboard are in fact no larger than the average office intercom device, making the unit ideally suited to use on the executive’s desk. The display uses an adaptation of the dot matrix technique with an array of gas filled cells arranged in a glass honeycomb configuration. Individual cells may be selectively ionised and illuminated to display the characters of a message. The display screen capacity is 256 characters in horizontal rows of 22 characters. The character size is 0.20 inches wide and 0.28 inches high, built on a dot matrix of five by seven dots each 0.024 inches in diameter. Characters are spaced by two blank columns of dots and character rows are spaced by the three blank rows of dots. No focusing is required with this gas filled screen and characters are large, bright and distortion free. Data storage is in MOS/LSI random access memory with a capacity equal to the size of the panel in use. A blinking cursor is available which advances to the next character position as each location is filled, unless modified by the control keys. An extended memory option is available which permits the storage or transmission of four pages of data. Three possible keyboard options are available, an alphanumeric typewriter, alphanumeric data entry and 10 key numeric. Alternatively, the display can be used as a receive only device without a keyboard. (CW 29/6/72 p20

SPL system cuts cost of storage: A shorthand system for computerised data designed to reduce data storage costs, known as file compaction, has been developed by SPL International, together with a range of hardware devices for use with the system which are being patented. It is believed to be the first time that a British software house has applied for hardware patents. The basic principle involves the substitution in software of single characters for bigrams and multigrams, i.e. regularly recurring groups of letters or symbols such as (in English plain language) TH, ING, TON, HAM, etc. Thus Northampton can be reduced from 12 symbols to seven as in NOR(TH)(HAM)P(TON). This system is particularly useful in address lists. The hardware developed by SPL is intended for use in data transmission, to precede the output modem and follow the receiver, thus enabling both modems and transmission line to work at a reduced data rate with an appreciable saving in costs. No quantification of the saving is yet available, but in one case history SPL claims to have reduced the file requirements of its client by 52.2 per cent. (CW 13/7/72 p1)

Data logger for aircraft: A contract worth over £7,000 to supply a 1,000 channel data logging system to the British Aircraft Corporation has been won by IDM Electronics Ltd, of Reading. The logger will be part of a system being used for the static testing of the MultiRole Combat Aircraft airframe at the Warton Aerodrome Division of BAC. The function of the logger is to multiplex the 1,000 two pole strain gauge inputs and to provide power supply reference lead switching to the various groups of gauges being interrogated. The multiplexer has been developed from IDM’s stepping scanner and adopts a two stage approach, whereby the 1,000 inputs are multiplexed into 10 outputs which are in turn switched using a slightly modified TS50 unit to provide a single two pole output. According to IDM, this method is more economical of space and cost than other methods. The complete system provides for operation in either single or continuous scan modes at speeds of up to 10 channels per second. Output is onto paper tape which will be fed directly into the BAC data processing centre. (CW 13/7/72 p7

OMR techniques for new hospital: Optical mark reading techniques are being developed for the hospital environment by the Department of Medical Computing at the new Charing Cross Hospital, where the first patients are being admitted later this year. A pilot scheme has already been successfully carried out involving the data entry procedures associated with requesting and reporting laboratory tests, and the possibility of using OMR for drug prescriptions is now being studied. These two applications together account for 80 per cent of the total amount of information about patients that must be communicated between the wards and the service departments of any modern hospital, and so the improvements in efficiency have a fairly radical effect on the performance of the hospital as a whole. Benefits from the OMR system fall into three main areas. Some direct cost savings are achieved, more information is handled in a shorter time, and a broader based and more detailed statistical analysis of patient records and hospital services is produced. These lead to improvements in patient care with a reduction in the patients stay in hospital, and better clinical management, with side benefits such as better costing. The OMR reader used is a Dataterm 3 terminal from Data Recognition Ltd. At present this produces paper tape which is processed via a terminal by the Leasco time sharing service, but it is hoped later, if government sanction is forthcoming, to run it on-line to an on-site computer. (CW 27/7/72 p23)

Infra-red Data Link goes into Operation: The first infra-red data transmission link in the UK, and possibly Europe, is now in operation between Cambridge University Engineering Department in Trumpington Street, and the Computer Laboratory in Corn Exchange Street. The link covers half a mile as the crow flies over the Cambridge rooftops and is based on Optran terminals which were supplied and installed by K&N Electronics Ltd, of Maidenhead, Berks, UK agents for the makers, Computer Transmission Corp, of Los Angeles, California. Using an infra-red beam the system is being used to transmit data between the Engineering Department’s IBM 1130 computer and the Laboratory’s IBM 370/165 through a PDP-11/20 acting as a front-end processor. Optran acts as a high speed data link which at first will be operating at 4.8 kilobauds. It is planned to increase this to 9.6 kilobauds in the near future. The Optran range has the capability of data speeds up to one megabaud, and has an accuracy of one part in 10,000 million. (CW 3/8/72 p1)

Drugwatch at the Olympics: Any Olympic competitor trying to get a boost through the use of illegal stimulants will have to contend with a £40,000 Hewlett Packard gas chromatograph drug detection system incorporating a 16K HP 2116C computer. Eight HP gas chromatographs will be used to monitor competitors. Each chromatograph consists of a long column filled with an inert material. Components of the sample under test are isolated because they travel through the column at different speeds. Information from several chromatographs operating simultaneously can be analysed by the 2116C to identify any drugs which may appear during an analysis. Olympic officials are hoping that the fully automatic analysis will provide an accurate and speedy deterrent to the use of drugs. Any medal winner found using a drug will be disqualified and an entire team could be banned if any one member partakes of illegal substances. (CW 17/8/72 p1)

Forthcoming Events

Face-to-face meetings at the BCS in London have now been resumed. It is as yet uncertain when Manchester meetings will recommence.

However, in view of the success of the online Zoom meetings that have taken place over the last year in allowing many more members to attend, we are now operating in hybrid mode by making meetings available over Zoom as well as in person.

Seminar Programme

London meetings take place at the BCS — 25 Copthall Avenue Moorgate EC2R 7BP starting at 14:30. The venue is near the corner of Copthall Avenue and London Wall, a three minute walk from Moorgate Station and five from Bank.

You are strongly advised to use the BCS event booking service to reserve an in-person place at CCS London seminars in case the meeting is fully subscribed. Web links can be found at www.computerconservationsociety.org/lecture.htm . The service should also be used for remote attendance.

For queries about meetings please contact Roger Johnson at

Details are subject to change. Members wishing to attend any meeting are advised to check the events page on the Society website.

Museums

SIM : Demonstrations of the replica Small-Scale Experimental Machine at the Science and Industry Museum in Manchester are run every Wednesday, Thursday and Friday between 10:30 and 13:30. Admission is free. See www.scienceandindustrymuseum.org.uk for more details.

Bletchley Park : daily. Exhibition of wartime code-breaking equipment and procedures, plus tours of the wartime buildings. Go to www.bletchleypark.org.uk to check details of times, admission charges and special events.

The National Museum of Computing Normally open Tue-Sun 10:30-17.00 but at present opening days are somewhat irregular so see www.tnmoc.org/days-open for current position Situated on the Bletchley Park campus, TNMoC covers the development of computing from the “rebuilt” Turing Bombe and Colossus codebreaking machines via the Harwell Decatron (the world’s oldest working computer) to the present day. From ICL mainframes to hand-held computers.

Please note that TNMoC is independent of Bletchley Park Trust and there is a separate admission charge. Visitors do not need to visit Bletchley Park Trust to visit TNMoC. See www.tnmoc.org for more details.

Science Museum : There is an excellent display of computing and mathematics machines on the second floor. The Information Age gallery explores “Six Networks which Changed the World” and includes a CDC 6600 computer and its Russian equivalent, the BESM-6 as well as Pilot ACE, arguably the world’s third oldest surviving computer.

The Mathematics Gallery has the Elliott 401 and the Julius Totalisator, both of which were the subjects of CCS projects in years past, and much else besides.

Other galleries include displays of ICT card-sorters and Cray supercomputers. Admission is free. See www.sciencemuseum.org.uk for more details.

Other Museums : At www.computerconservationsociety.org/museums.htm can be found brief descriptions of various UK computing museums which may be of interest to members.

North West Group contact details

Computer Conservation Society

Aims and Objectives

The Computer Conservation Society (CCS) is a co-operative venture between BCS, The Chartered Institute for IT; the Science Museum of London; and the Museum of Science and Industry (MSI) in Manchester.

The CCS was constituted in September 1989 as a Specialist Group of the British Computer Society (BCS). It thus is covered by the Royal Charter and charitable status of BCS.

The objects of the Computer Conservation Society (“Society”) are:

• To promote the conservation, restoration and reconstruction of historic computing systems and to identify existing computing systems which may need to be archived in the future;
• To develop awareness of the importance of historic computing systems;
• To develop expertise in the conservation, restoration and reconstruction of historic computing systems;
• To represent the interests of the Society with other bodies;
• To promote the study of historic computing systems, their use and the history of the computer industry;
• To publish information of relevance to these objectives for the information of Society members and the wider public.

Membership is open to anyone interested in computer conservation and the history of computing.

The CCS is funded and supported by a grant from BCS and donations. Some charges may be made for publications and attendance at seminars and conferences.

There are a number of active Projects on specific computer restorations and early computer technologies and software. Younger people are especially encouraged to take part in order to achieve skills transfer.

The CCS also enjoys a close relationship with the National Museum of Computing.