Mainframe Culture

The middle of the 20th century marked a pivotal era in technological history, a period when the computational demands of industry and engineering forged a new, deeply interconnected technological ecosystem. From the 1950s through the 1970s the digital world was physically massive and purpose-built rather than mass-produced. Fueled by the geopolitical pressures of the Cold War, the challenges of optimizing energy and industrial operations and competing in the space and arms races could not be solved by any single component in isolation; they required a holistic system where each part was shaped by the capabilities and limitations of the others. The strategic importance of this period lies not merely in the invention of individual technologies, but in the indivisible links that formed between specific, high-value business problems (industrial optimization), a dominant hardware architecture (the 36-bit mainframe), and a programming language forged for that exact purpose (Fortran).

The narrative here will trace this co-evolution, moving from the foundational hardware to the software that harnessed it, the motivating algorithms that gave it purpose, and the subsequent technological shifts that redefined the user experience. This was not a linear progression of singular inventions, but a dynamic interplay where foundational hardware, novel programming languages, and powerful algorithms evolved in concert. These elements did not evolve in isolation; they formed a tightly-coupled technological ecosystem, each shaping and being shaped by the others. The evolution of these components was symbiotic. Hardware architecture dictated the design of compilers, which in turn influenced the structure of algorithms. Simultaneously, practical high-stakes industrial problems created powerful incentives that drove innovation across this entire space.

The example we’ll examine here is optimizing refinery operations for the energy industry using Linear Programming (LP) and the Simplex algorithm, made practical in the early 50s at RAND by Georg Danzig in conjunction with the first generation of commercial IBM digital computers. We’ll follow two related families of 36-bit mainframes that dominated two distinct eras, the IBM 7090 and the DEC PDP-10. The architectural evolution from the batch-oriented, tape-driven IBM 7090 to the interactive, disk-based DEC PDP-10 fostered a significant cultural shift in how computation was conceived and used. This is demonstrated here in the transition from large-scale strategic numerical optimization (Simplex) to shared, real-time virtual worlds (Decwar), exploring the core components of this early computing revolution: the imposing mainframes that provided the raw computing power; the Fortran programming language that made this power accessible; and foundational applications like the Simplex algorithm that translated computational capacity into tangible economic value.

To comprehend the software of the mid-1960s, one must first inhabit the physical and architectural reality of its native environment. A computing center of this era was a world of refrigerator-sized tape drives, the percussive clatter of teletypes and punch card hardware, and roaring cooling fans. It is strategically critical to understand that these were not viewed as obstacles to be overcome; they were the fundamental ecosystem in which all software was structured and evolved. The IBM 7094 and the DEC PDP-10 were each dominant systems and shared a common architectural heritage, but represented distinct evolutionary paths.

	IBM 7094	DEC PDP-10
Era of Dominance	~1957 - 1969	~1966 - 1983
Memory	Magnetic core memory with 32K 36-bit words.	Magnetic core memory with 1M 36-bit words.
Primary I/O Method	Punch Cards	Interactive Terminals (Time-sharing)
File System Concept	No formal file system; each magnetic tape reel was a single "file".	Modern file system with six-character filenames, suffixes, and disk-based storage.
Target Market Niche	Batch-processed "imperial scale" numerical computation.	Interactive "large scale" system, camouflaged to avoid direct competition with IBM.

The most defining characteristic of this hardware generation was its 36-bit word architecture. This was not an arbitrary choice but a direct consequence of the punch card. The 6-bit BCD (Binary-Coded Decimal) and Hollerith character codes, which represented data on punch cards, were the iron fact of reality. A 36-bit word was the natural and efficient way to store this information, as six 6-bit characters fit perfectly within it. This hardware reality is why 36-bit words, not the 32-bit standard that would later emerge, became the bedrock of mainframe computing. These physical hardware characteristics, from the nature of I/O to the very size of a machine word, profoundly shaped the software development practices that arose to master this powerful but unforgiving environment.

By analyzing each system (IBM 7094, DEC PDP-10) and representative applications (LP, Decwar), we will draw broader conclusions about the profound and often-invisible relationship between technology and creative practice, demonstrating with stark clarity how the historical dependencies between hardware, compiler, and code persist across decades. It reveals how these deep-seated relationships dictate the challenges and triumphs of modern digital preservation efforts, and how software is an artifact not just of code, but of its complete technological world.

UTCC DEC-10 Staff

Thank you to Richard Denney for the photos in this post, and to Rich and Clive Dawson for the information discussed here. 

We've learned an enormous amount in the last week from Rich and Clive, and would like to at least begin recording some of the core info as a kind of baseline reference for the future. Maybe the best way to begin is just to take a first small step and begin recording some names and connecting those with stories.

Meanwhile, a very interesting phenomena happened yesterday. I was researching the UTCC DEC-10 using google, and twice the results included a pair of names together, and it turns out they are the two people behind the teletype in the photo to the left, Clive Dawson in the blue shirt and Rich Denney in the green shirt. 

Currently I'm thinking, well, it could be that google could be aware of and tracking what I'm working on, and that influences the results. Or, it could be that Clive and Rich are a big part of the reason the results are including things like "The staff itself was described as an extremely close-knit group that felt a deep personal connection to the machine. This connection was shared by the users, many of whom spent thousands of hours connected while developing software and helping others."

The following two photos and accompanying info are from Rich.

This photo below is the going away party for Elissa Vogel in 78. George Culp is mentioned in the Creative Computing article. And David Phillips had taken on the manager role for the DEC-10 by 77 when I got there. Not sure where Clive was that day? At least three of the good people in that photo have left us. That is Rick Watson on the right. In that photo left to right: Kathleen (programmer new hire, went on to bunches of companies, Tandem, IBM), Mildred (help desk), Norma (secretary), Dawn (programmer), Bob Hysick, Doug DeGroot (programmer, PhD later), George, David (manager), Rick Watson, and of course Elissa Vogel operator. I was there 77-83 and did my masters under Elaine Rich in AI, then went on the AI ride til the big crash (AI winter #2).

To complete the list of managers, after David Phillips, Tommy Loomis was manger. Or maybe he took over after the shutdown with the DEC-20. That was around when I left so a bit fuzzy. Staff wise I think those I sent pretty much covers most everyone. Well .. Cecil, who was one of the operators, was missing. He left in 82. And Debbie (Rice?) that replaced Norma is not included. There's also the topic of DEC-10 users. Mary Jo (?) I remember. Those folks in the Linguistic group. There were a number in the offices on the floor that surrounded the DEC-10.

And the following info is from Clive.

I was at UT starting as a grad student in 1971 and left in 1985 to join MCC.  I was on the Computation Center staff starting in 1975 as a systems programmer for the DECSystem-10 through 1982 when the ’10 was decommissioned.  The final party was the subject of “The Soul of an Old Machine”.  Then I became the manager of the Research-20, a DECSYSTEM-20, until I left in 1985.

Bob Hysick was also on the DEC-10 staff and I was well familiar with his DECWAR project.  One of my projects during those years was the development of TECO-124, which among many other things added video support for dumb terminals to DEC’s standard text editors, TECO.  I was happy to see the TECO macro directory in the DECWAR sources!

I was also friends with Dave Matuszek and Paul Reynolds, fellow grad students and the authors of the original STARTREK game on the CDC-6600, which was one of the main inspirations of DECWAR.  My friend and fellow grad student Rich Cohen was also a good friend of theirs.  I’ve shared your original email message with him.  He stays in touch with Dave and Paul and can give you their contact info.  He can also suggest a few corrections to your timeline.  For example, he tells me that “Super Star Trek” was not done at UT, and was based on a stolen copy of the Matuszek/Reynolds original FORTRAN source.

While doing some rounds of feedback on this post, we got a bit more information that follows-on nicely and help build up the overall picture, so will just continue on with that below. This is from Rich.

Speaking of SWT in San Marcos, be sure to ask Clive about the "sister" DEC-10 that was there. I remember attending a LOTALUG meeting there a time or two (Louisiana, Oklahoma, Texas, Arkansas Local User Group).

We need to get confirmation from Clive that Tommy took over. I remember he had an office down the hall. Tommy was Board of Control, today's Comptroller Office. They had a 10 and were located north of the Capitol building. When Tommy moved to UT I don't recall exactly. But the first time we met he was at BOC.

Both Rich Cohen and Tommy wound up at Semantic Designs years later; Ira Baxter's company. Ira and I were both at Schlumberger and had a common good friend Jorge Boria RIP, also at Schlumberger. Then later I wound up consulting at the company Jorge was with, TeraQuest Meterics, a software process consulting. One of the principals at TQ is Joyce Statz who is now our neighorhood president and I do history articles for the newsletter.

Small interconnected world.

Assembly and Fortran

By the 1980s, PDP-10s were entrenched in universities, computing centers, and time-sharing installations. The economics of the period favored incremental software refreshes rather than disruptive changes in language standards. DEC's choice to maintain a robust Assembly language and Fortran IV toolchain reflected the installed base's dependence on legacy code, local modifications, and mixed Fortran and Assembly programming. Decwar emerged from this institutional ecology. An environment in which students, researchers, and system programmers routinely extended existing subsystems, shared code across accounts, and optimized routines for a time-shared population of users. In this milieu, stability and coding conventions mattered as much as language expressiveness. 

Decwar was written not for isolated personal machines but for multi-user communities sharing a common computational space. Its reliance on predictable compiler output and stable low-level encodings enabled a shared, real-time game environment on a platform never intended primarily for interactive entertainment. More broadly, Fortran IV demonstrates how language stability can enable specific creative forms. The persistence of its semantics allowed a hybrid program, part high-level logic and part low-level Assembly code, to function reliably over many years within its birth ecosystem.

This case study demonstrates a foundational principle of legacy system migration. Historical fidelity of the toolchain is not a matter of preference but a core engineering requirement, overriding any perceived convenience of more recent tooling. The process of migrating vintage software such as Decwar presents unique challenges that transcend simple code porting. Success hinges on a precise understanding of the intricate dependencies between an application and its original development environment. In fact, it is fair to say that it would be very difficult to migrate Decwar’s Fortran IV. It’s too intertwined with the environment in which it was created. It can be recreated and reproduced in other environments and languages, but it can not easily be migrated piece by piece.

Decwar's longevity therefore depends on specific historical layers of the PDP-10 software ecosystem. It is not merely a Fortran IV program. It is an artifact of specific compiler and assembler versions, all deeply rooted in PDP-10 hardware and TOPS-10 operating system installations circa 1980. In the study of digital history, it is tempting to view computing hardware and software as neutral tools, passive instruments waiting to be wielded by human creators. There is a more nuanced premise, however. That these systems are active environments, technological ecosystems that both enable and profoundly constrain the creative works born within them. The mainframe systems of the sixties, with their unique architectures, toolchains, and cultural norms, constitute a world unto themselves.

Containers and Ultimate Portability

Initiated in the fall of 2025, the project's third and current stage is the culmination of the Decwar workflow evolution. The objective in this era is to free the entire system from any specific host hardware and achieve true simplicity and independence through containerization, creating a fully encapsulated digital artifact that can travel freely into the future. The architecture is a deliberate strategic decision to preserve the proven efficiency and authenticity of build-from-tape while leveraging containerization. The entire SIMH PDP-10 Decwar environment becomes a self-contained, portable ecosystem that can run on virtually any modern computer, whether it be a Raspberry Pi, a MacBook, a Windows machine, or a Cloud service. Once containerized, the system is "free to roam the Galaxy" and capable of running on any machine from a local laptop to a Cloud instance. The complex historical simulation is packaged into a simple, distributable artifact.

The architecture is a microservices-inspired, three component network managed by Docker Compose. Each component runs in its own container. On any machine with Python and Docker Engine, a user runs an install script once to pull the necessary Git repositories, and thereafter simply runs a start script to build and launch the entire three-container environment automatically. The only requirements are Python and the Docker Engine, making the entire workflow fundamentally portable. Three key technologies work in concert to deliver a seamless user experience. A Python script serves as the initial bootstrapper. It automates the one-time setup process by retrieving the Git repositories for generating the Docker containers. Docker is the core containerization technology that enables the encapsulation and isolation of the SIMH PDP-10 environment. It allows the complex legacy system and its dependencies to be packaged into a standardized and portable unit. Docker Compose is the orchestration tool used to define and run the multi-container system. It manages the networking and lifecycle of the individual containers, ensuring they launch and communicate as a single, cohesive system.

The environment is composed of three distinct Docker containers, each with a specialized role. Together, they form a complete, networked system for running and interacting with the Decwar game. The first container houses the reconstructed SDT and the SIMH PDP-10. It is responsible for the automated build of Decwar on every startup. The second container is both the primary controller and the primary API layer. It contains the main start script that initiates the entire Docker Compose system. It also provides the central REST API for controlling game robots. The third container is the presentation layer. It runs a web server that provides a visual interface to the running Decwar game by reading the central REST API to display game state.

This elegant three-container architecture separates concerns, making the system modular and manageable while providing a complete, end-to-end user experience and delivering tangible, transformative benefits for system development. By building upon the successes of the tape-based approach and leveraging modern containerization, the project provides a superior workflow that excels in portability, automation, and efficiency. Complete hardware abstraction is achieved by design. Unlike previous eras, which were tied to specific host configurations, the containerized system is entirely self-contained and capable of running on any machine that supports Python and the Docker Engine. This eliminates hardware dependencies and allows the development environment to be deployed consistently across developer laptops, testing servers, and cloud instances. Procedural, multi-step workflows are replaced with a declarative, single-command system activation. The entire lifecycle of the environment, from fetching source code to building the SIMH PDP-10 system and launching all necessary services, is condensed into a single start script. This push button simplicity drastically reduces setup time, eliminates the potential for human error, and makes the system accessible to those unfamiliar with the underlying DEC PDP-10 architecture. The project’s architecture inherits and perfects the speed of the tape-based workflow. The process of creating a tape image remains nearly instantaneous, and the SIMH PDP-10 Decwar startup and build cycle completes in seconds. By containerizing this already-efficient process and automating it end-to-end, the fastest, most reliable, and most repeatable development cycle is achieved. These combined benefits represent a paradigm shift, moving the historical artifacts from a specialist's pursuit into the realm of modern, professional engineering.

1976 Photo of the UT Austin DEC-10

This post is entirely about the images down below. Many are from the website AtariArchivesOrg. It’s highly recommended to explore the website, despite the ads. It turns out that there was a two page article about UT in a 1976 issue of Creative Computing magazine, including a picture of the DEC10 in 1975/1976. The article describes it as a recent acquisition, and it’s almost certainly the machine used to begin writing Decwar in 1978. Here’s a direct link to the Atari Archive source.

There's more context. Creative Computing magazine was the vehicle of David Ahl, who also published the Star Trek BASIC code repeatedly from around 1973 and is in some sense at the heart of the single-player Star Trek story that led to Decwar. In other words, Ahl published an article about the UT DEC10 a few years before it was used to create an ultimate version of the Star Trek game he was championing. In the early days of the microcomputer revolution, Creative Computing and BYTE were the two pillars of the industry. While they were friendly competitors, they served different niches and even collaborated occasionally before being absorbed by larger corporate entities. Creative Computing (1974), founded by David Ahl, is widely considered the first personal computer magazine. Ahl, a former DEC employee, launched it to focus on the educational and playful side of computing. BYTE (1975) was launched about a year later and quickly became the journal of record for the industry, known for its technical depth and massive, brick-like monthly issues.

Pursuing Authenticity and Efficiency with Tape Images

The project's second stage, which began at the end of 2024, represented a strategic and philosophical shift. The motivation was not merely to escape the awkwardness of client-server file transfers, but to pursue an ideal vision: a complete Decwar PDP-10 system built from scratch using only SIMH tape images of original authentic DEC tapes. The ambition was to build TOPS-10 from DEC source tape using MONGEN (MONitor GENeration, analogous to building UNIX or Windows from source code), then install the appropriate DEC Fortran IV from DEC source tape (DEC FORTAN-10 V6), then install Decwar from reconstructed UT Austin SDT, build, and play.

The transition to a tape-based workflow marked a major jump up in efficiency and realism, with immediate and substantial improvements in cycle time and development ergonomics, rendering the Kermit-based approach obsolete for active development. The new process involved editing source files locally, creating a new SIMH tape image, an automated process taking less than a second, and simply restarting the SIMH PDP-10. The entire process, from end to end, takes a matter of seconds and is invoked with a single command or push of a button.

The new workflow was centered on SIMH tape images. The impact was profound, creating a much smoother and more flexible workflow. The paradigm shift was so complete that Kermit and client-server file transfer have completely vanished in practice and are retained as possibilities mostly for historical reasons, much like the possibility of using a terminal to perform interactive file editing on the PDP-10 using SOS or TECO. They’re possible and interesting historically, but not effective everyday workflows.

Beyond efficiency, this shift held deep cultural significance. By using the reconstructed SDT for every build, the project was "eating their own dog food." This practice is the ultimate validation of the archeological work, proving the integrity of the artifact by using it as the foundation for further progress. This also makes the entire process feel "super realistic". The technical elegance of this approach lies in its fidelity to the original hardware paradigm. The SIMH PDP-10 interacts with the tape image without awareness that it is not physical hardware. This commitment to authenticity is demonstrated in practice with every build from reconstructed SDT, ensuring a clean and consistent environment. While this Tape Era perfected the local build process, it remained tethered to a specific host machine's configuration, setting the stage for the next evolutionary step: total environment abstraction.

An Initial Pragmatic Bridge to the Past

Kermit history from the creators

Beginning in the fall of 2024, the project's first stage was defined by a fundamental logistical problem: how to transfer newly edited source code from a modern host computer onto the SIMH PDP-10. The initial solution was Kermit, a venerable client-server protocol that characterized the project's first development workflow. This approach required running Kermit on both ends, a modern host and the PDP-10, to establish a communications bridge for file transfers. Originally created in 1981 at Columbia University to allow users to move files between smaller computers and campus mainframes, Kermit requires the user to manually run executables on both the local host and the mainframe. In some sense Kermit is a serial terminal style ASCII connection between two user-layer executables, and piggybacks its own file transfer protocol on top of that. This can be juxtaposed with the early 70s ARPANET protocols such as TELNET and FTP which are in some sense lower-level and more deeply integrated into the operating system layer.

The concept for Decwar was to edit Fortran source files locally, then use Kermit to transfer them to the PDP-10. Another apparently simple alternative was to edit Fortran source interactively on the PDP-10 via telnet session using vintage DEC tools such as SOS and TECO. While entertaining, this very quickly proved too slow and cumbersome.

The Kermit workflow, though an indirect way to code and test, was at least somewhat automateable using Kermit's scripting capabilities. One would edit Fortran source files on their local machine, and an automated script would then use Kermit to move those files over to the PDP-10 in order to rebuild Decwar and prepare it for testing. This workflow had a dual nature. It was a learning tool that enabled the project to get started quickly, and it was indeed worthwhile to learn more about Kermit because of its familiarity and relative ease. At the same time, this method imposed significant limitations. The process was comparatively slow and more than a little bit awkward, highlighting the friction between the modern and historical systems and ultimately serving as the catalyst for a more integrated methodology.

In retrospect, this workflow, while functional for initial system exploration, presented significant efficiency bottlenecks. It likely slowed down progress compared to what would have been possible using better approaches. The reliance on manual, multi-step file transfers created an indirect and cumbersome development cycle that was ripe for optimization.