Some background notes about CTL and batch terminal emulation to give an idea of the times. Readership is public.
For a short time in the mid-1970s, I worked for a company called CTL, which was a British computer company that made a 16-bit computer called a Modular One. Here is its Wikipedia entry.
I was recruited on the strength of my knowledge of 200 User Terminals because CTL were selling Modular One systems that ran emulations of various RJE terminals, including the U200, but it was hard for them to acquire the practical knowledge to make them work smoothly with real mainframes.
These emulated batch terminals were an important step in the evolution of computing because they were general purpose computers. The smaller configurations would run a stand-alone system that at first did little more than replace the U200 hardware. The larger systems would run an emulation as a subsystem of a more sophisticated operating system that allowed pre and post processing of the inputs to and outputs from the mainframes.
I had invented some software, called FRAME, to facilitate that sort of thing - a framework similar to MIME, which was to be invented over ten years later. People could submit batch jobs from local files and post-process output so that it could end up on graph plotters, daisy-wheel printers or whatever else was available at a particular site. This meant that results could be visualised and scientific papers could be published more quickly and easily. I remember watching plots showing electron mobility in polymers coming out. They would indicate possible practical outcomes for the manufacture of semiconductors and the occasional hope for high temperature superconduction.
I programmed Modular One machines in Assembly Language and CORAL 66 (see Wikipedia entry).
CTL did not have anything I can describe as SCM software. I can remember cupboards filled with reels of orange paper tape and cupboards full of symbol listings for system software configurations that had been exported to customers. They also had physical tokens which were used as interlocks to prevent people concurrently updating software modules.
I soon left CTL and went back to work in various colleges of London University.Here's me with a Modular One at Westfield College. At the table is a CTL badged Card-reader, a container of spare cards and a VDU. Pity I can't quite make out what's on the screen. On top of the Modular One is a just-used paper tape reader (the tape is on the floor) and a rack of paper tapes, which would have been specific operating systems or utilities. The tape reader was usually the bootstrap device for such a system. Frequently used tapes like that were actually made of plastic rather than paper. At the far end is a manual winder to rewind the tape after it has been read. The module below the paper tape reader is a paper tape punch. The 1.61 module at top right is a multiplexor, supporting the synchronous connection to ULCC and a number of asynchronous terminal connections. Several of the modules will be of internal memory, each perhaps 8K words of ferrite core store. Perhaps some of the new-fangled semiconductor storage. This was the end of the era when you could routinely see a bit with the naked eye.
During these years, I continued to use CDC UPDATE for SCM. The FRAME software allowed me to make updates to local files quite fluently, bearing in mind that the CTL editors were line editors anyway. Most CTL staff had never seen a CDC console and it was hard to persuade them to think of VDUs as anything more than "glass teletypes".
UpdatesThis document is maintained by Pute. Comments should be addressed to PNJ at XQWV dot ORG dot UK.
- PNJ, 2014-07-24. Original version.
- PNJ, 2014-07-25. Expanded descriptions and added more images.