Recalling the AUTODIN – Part II

Recalling the AUTODIN – Part II

March 2, 2012 2:36 pm 3 comments

We now continue our series on the AUTOmatic DIgital Network.
(See Part I here)

The Message Switching Business

The main job at hand for the Autodin was, of course, the automatic routing of messages. Messages could be entered into the system with four or five different precedences (priorities), each of which had a performance standard that had to be met or there was a lot of explanatory paperwork to be filled out. The highest was Flash. A Flash message had to be delivered to its destination station (a terminal or trunked to another switch) within two minutes from the time it arrived.

Messages could also be entered with a security classification of Unclassified, Confidential, Secret, or Top Secret. One of the switch’s duties was to make certain that a message could not be sent over a communication circuit whose classification was lower than that of the message.


The switch automatically stored a copy of each message it received on a history tape (it actually wrote a copy to each of two tapes), along with timestamps of when messages arrived and were delivered. These tapes were used for offline searches to recover messages for which a “service message” was received, indicating non-delivery. There was a large tape vault where these tapes were stored for a period of time before being erased and reused, much in the same way today’s system backup tapes are managed.

System Console

System Console

System Console

Primary control of the message switching system was done at the System Console. It had a variety of alert indicators and a numeric display that identified which circuit had an error condition. The most common problem was “no idles.” The synchronous terminals sent an idle pattern when no traffic was flowing, to maintain connectivity. When a circuit lost its idle pattern the System Console would ding quietly and the No Idles light would flash. Pressing the button over the light would display the circuit number, which the console operator would report via a push-to-talk intercom to tech control, where we would investigate the cause.

Joint Operations Team

Autodin switching centers were operated by a team made up of military personnel, Western Union personnel, and civilian government employees. Despite the real possibility of friction among the various factions, the Norton switching center had the highest esprit de corp of any place I have worked, ever. It was not at all unusual for someone who happened to be in the neighborhood to stop by on a day off, just to see how things were going. I suspect a lot of this had to do with the Norton AESC’s being the best performing switch in the system. Everybody wanted to keep it that way.

Operations personnel were a mix of civilian government employees and military personnel. Western Union provided hardware support for the computers and communications lines that connected the center to its tributaries and other switches.

Missing Persons

One of the biggest mysteries to me concerning operations was where everybody hung out. You could go out on the traffic floor at 2 o’clock in the morning and you’d see maybe two people: someone at the System Console, and maybe a tape search or compound terminal operator. Yet, seemingly seconds after a quietly frantic announcement over the PA system, “Western Union supervisor; we’re down,” there would be twenty people milling around waiting to see what they could do to solve whatever problem had brought the switch to its knees. I never did figure out where they materialized from.


This period (mid 1960’s) was in the Vietnam build up and the Air Force was rotating communications officers through our facility at an alarming rate. Operations shift supervisors were frequently Second- or First-Lieutenants who stayed for a few months before being transferred on to some other location. Sometimes this led to interesting situations.

Phil Ryals (1960's)

Phil Ryals

On one such occasion a Flash precedence message got queued for the Army message switching station in Davis, California. We had five teletype (Mode V) circuits to Davis, but one of them was out of service. Guess which one the message got queued to?

The operations supervisor for that shift was this very excitable young lieutenant who came storming back into the tech control facility (more on that in Part 3) screaming at me, saying do this or do that. After determining what the situation was, I calmly told him “I have worked in this facility longer than you have been in the Air Force. Go back to your systems console and let me do my job.”

That, of course, increased his agitation even more markedly, and I swear he flew about a foot up off the floor. He subsequently complained to the OIC (officer in charge) of tech control that I was insubordinate and needed to be punished for it. My OIC shrugged it off and told him that he shouldn’t have been back there bothering me.

Continue to Part III >


  • A David Kornbluh

    Phil Ryals,
    I was a programmer at RCA’s “Soup Factory” next to identical Campbell’s Soup builings in Camden, NJ in the early 1960’s as newly promoted to the Advanced Programming Group under Bob Benjamin. We were developing what we believed to be the first multi-progam machine OS – up to 16 programs executing “simultaniously” from a paper tape console read strip task list for the RCA601 that was soon to exist. Using the RCACDP’s micro code via ops vector tables each machine language instruction was perfected and i was able to write and debug entire RCA601 routines on the RCACDP months before the RCA601 was assembled. The RCA601 borrowed some of the RCACDP architecture providing a limited set of micro programmable privileged instructions. I was impressed with the power of microprogramming for device drivers and noted that IBM used micro programming in some of the 360 series computers. I do not know factually if the RCACDP used RCA501 computer hardware but i seriously doubt it. I programmed the RCA501 beginning in mid-1959 and i do not see any evidence that it used a word architecture. In fact, the 3 character octal registers were actually located in low “High Speed Memory” – RCA’s term for core memory. The arithmetic and index registers were in low memory. At Astro Electronics in 1960 i was assigned to write a miniature program loader to sequence programs on magnetic tape to perform multipe batch processing steps on the BMEWS wire connection list data files. I discovered that with no basic standards, programmers wrote machine code starting at just about any memory location that they fancied. They did discover quickly that their program would be altered if they started in memory location zero so the only place left for my program loader was beginning in low memory where it ran like Indiana Jones on step ahead of distruction and had to be reloaded just prior to execution. I have original RCA501 and RCA601 manuals. A David Kornbluh

  • Randall Morrell

    Also worked on the 026 card reader. Another bitch.
    Best ever was the M-28 Relay center equipment.
    Hated DSTE. A piece of crap.

  • I really found very interesting about these topic because you have good content and unique thoughts on writing. So this might be useful to everyone. I really look forward some more updates. Thanks for sharing.

Leave a reply