This introduces UPDATE, the first SCM-like utility I ever used. Readership is Public.
The discipline of clarity optimises the use of the first actual machine in the development chain - the 029 Card Punch.
The Card Punches are admirably robust pieces of engineering that crisply encode the source text into unit records of 80 12-bit bytes. Their keyboards have a unique and precise feel and the punching operation is quite noisy, especially in a room full of them. In those days, people trained as "Keypunch Operators" and there was a clear demand for their skills because there were many more programmers and other sources of data than there were punched card machines. In my case however, I operated the card punch myself, learning how to optimise its use by making a program card that would alter the machine's behaviour to skip to certain columns and automatically punch sequence numbers onto the cards.
Sequence numbers are a defense against misreads or cards becoming badly sequenced in the deck. If a "dropped deck catastrophe" occurs, there are even machines to sort the cards based on sequence numbers. Operators were sometimes known to amuse themselves by performing sleight of hand and dropping a dummy card deck in front of the user, to observe the reaction. They were usually behind some sort of barrier when they did that.
The next stage of this coding, punching and careful checking process is to bind the cards securely between labelled cardboard protectors and entrust them to a courier service.
C -- NOW WAIT 3 DAYS...
A block of fanfold paper arrives. Most likely, what's printed is not quite what I expected and thus begins a lengthy period of staring at the listing.
In this era, computing consumed a lot of paper. The output from a typical job would often include an entire source code listing, because that's the only way one can inspect the code for further development or debugging.
Staring at the listing builds a kind of virtual machine in my brain, resolving defects and suggesting improvements.
GO TO 1.
U200Soon, I have become a creature of the night. That 3-day wait is suboptimal, so there are evenings when I go to Imperial College, to use a User-200 Batch Terminal which is connected to the machines at ULCC. This apparatus consists of a card-reader, a line printer and a display device connected through a 2400bps synchronous line to a multiplexor which is a peripheral of the CDC 6600. The U200 itself was another engineering marvel, with the buffering for the devices and display implemented in delay lines. What a fantastic retrochallenge it would be to restore one of these to working order! Little did I know that within a few years, I would be working on emulators for them and marvelling at the baroque complexity of the U200 protocol.
Fed by these overnight sessions, my programs get larger and the bottleneck now involves the length of time it takes to read and transmit the cards.
Decks of cards are lovely tangible artefacts of computing, but they are heavy, unwieldy, vulnerable to accidents and, occasionally, misreading. I don't remember the CDC card readers ever misreading my cards, but later, cheaper, devices would certainly do so.
The way ahead is what CDC refer to as Permanent Files on Rotating Mass Storage.
UPDATEThis is the CDC utility that manages something called a Program Library. Its idioms are rooted in the punched card technology of the time, but what it does is to allow a repository to be updated by correction sets and to be the source of input to compilers or other tools in the development chain. Not only does this optimise the use of bandwidth and physical storage of cards, it also provides a narrative of change and for program libraries to be updated by more than one person. Each correction set has a unique name and may be temporarily or permanently removed from the build if required.
Shown here is an UPDATE listing that illustrates some of these
features. The right hand side of the listing shows the unique
identifier for every line of code and there are mechanisms to include
other decks (
*CALL ...) and a mechanism to control the
generated code by removing (
*YANK ...) named correction
I soon took to this way of working and it became second nature to use it for everything I developed. That included code for other systems I worked on which had no such source management software in place. So off it would all go to CDC systems where I could keep track of my work. If I ever get my archive of 2400' tapes read, I know that some of them contain copies of these program libraries. UPDATE format is sufficiently well-documented that I would be able to retrieve the version history of my early software efforts.
Compared to a modern SCM system, UPDATE is a little different:
- The Program Library isn't a reflection of a large tree of files, but of any number of named DECKS, which might represent multiple programs or modules or blocks of data to be passed on to subsequent steps in a build and execution process.
- UPDATE is a library storage and line editing system in one. Modern SCM systems expect to work on changes to files made by some external editing system.
- There is no branching as such, but two program libraries could be merged to create a third, so something could have been worked out.
- This is a batch-oriented system, so there's no sense of concurrent updates. All the operations on a program library in one job would be catalogued as a self-contained new version of the program library. If somebody else runs another UPDATE job at the same time, another, distinct version of the program library would be created (The filing system had its own versioning, like VMS does). One could subsequently attempt a MERGE as mentioned above. In practice I never saw anything like that happen myself. UPDATE is able to deal with overlapping correction sets.
- UPDATE includes capabilities for various types of conditional building of code and for insertions of common decks in its output (used, for example, for common declarations of externals in multiple programs).
UPDATE was reimplemented in the later Cray machines and I remember at least one commercial product for non-CDC machines called Historian which appeared to be a complete re-implementation of the UPDATE design, using the same keywords and features.
I used UPDATE for over 10 years, moving on only when VAX/VMS came into my life.
-  CDC 6600 Wikipedia entry
- This machine, its architecture and operating system had a significant influence on me. 60-bit words, multiple processors a display console driven by a dedicated PPU so that it responds instantly to every keystroke and gives a real-time window into what the machine is doing. This in an era when most other accessible systems were using teletypes and paper tape. The command language is a study in lucidity compared with what the rest of the industry was doing.
-  200 TERMINAL TROUBLESHOOTING GUIDE (PDF at bitsavers). June 1971.
- This is a guide seemingly written by a field engineer for field engineers. It clearly mentions the delay lines in several places. From the same site you can find a 200 User Terminal Hardware Reference Manual, which is less explicit at describing the technology behind the buffers. I have a later version of the latter manual than the one at bitsavers, but with the introductory pages missing so that I'm not sure of its provenance.
-  60342400 UPDATE Reference at bitsavers.
- I have Revision C of this manual at home, together with a later Cray UPDATE reference manual (2240013). I did once have a Cray-XMP in the portfolio of systems I helped to manage.
In order of appearance above:
- Detail from the cover of ULCC newsletter number 50, December 1972. They had a penchant for drawing their machines as megalithic monuments. The 7600 arrived at ULCC in June 1972.
- A CDC6600 installation showing the iconic mainframe shape. This is from history-computer.com/ModernComputer/Electronic/Cray.html.
- This is a fairly rare image of a CDC display console in actual operation. It is part of a 6400 system. Retrieved from mkgajwer.jgora.net.
- CS164-4048, CS164-4047
- Images of coding forms from my own collection.
- 1964 IBM Card Punch 029. In the National Museum of Computing, a part of Bletchley Park. Photographed by Heribert Jung in 2008. I retrieved this from RADIOMUSEUM.ORG.
- "Trained keypunch operators, once in high demand, frequently worked in huge departments". From blogs.dctc.edu/dctc-news/2010/05/06/going-with-the-dataflow.
- Illustration of typical fanfold paper. This stuff, and the associated line printers, were commonplace. Used printouts and blank cards formed a seemingly endless source of paper for all sorts of purposes. I still see line printers and this paper at one site I work at today, but they seem like an anachronism.
- A box of punched cards.
This is from
Wikipedia and the image is
CC BY-SA 2.5 by mehul panchal, uploaded by
The original filename was
- The first page of an UPDATE listing of LONDPFM, which was ULCC's own variation of the CDC Permanent File Manager. The code here is PP COMPASS, the assembly language for CDC Peripheral Processors. Why do I have this? I used to enjoy reading the internal manuals and the source code for the CDC operating systems and learning how it all worked. This is how I used to spend my nights during the 1970s.
- UPDATE Reference Manual cover. Part of my CDC manual collection.
UpdatesThis document is maintained by Pute. Comments should be addressed to PNJ at XQWV dot ORG dot UK.
- PNJ, 2014-07-04. Started from paper notes made earlier.
- PNJ, 2014-07-18. Add images for illustration.
- PNJ, 2014-07-21. Add more images, arranged as sequences. Document the images used.
- PNJ, 2014-07-22. Illustrate UPDATE using a LONDPFM listing. Add reference to U200 troubleshooting guide.