Programs are guests. Guests still need a house.

I had this article in mind for a few months. While I was researching Project Quiet Ground and the IBM 5280, my friend Matteo shared this blog article with me:

https://dmitrybrant.com/2026/02/01/defeating-a-40-year-old-copy-protection-dongle

Long story short, Dmitry Brant describes how he defeated a mid-1980s copy-protection dongle to make an old RPG compiler for DOS work again today. It is an excellent piece of software archaeology, and his reverse-engineering work alone is well worth reading.

But one particular paragraph caught my attention for a completely different reason:

“We’ve got the complete source code of the accounting software, written in RPG. It looks like the full accounting package consists of numerous RPG modules, with a gnarly combination of DOS batch files for orchestrating them, all set up as a “menu” system for the user to navigate using number combinations. Clearly the author of this accounting system was originally an IBM mainframe programmer, and insisted on bringing those skills over to DOS, with mixed results.”

Brant’s reverse-engineering work is excellent, but I think this interpretation misses one important bit. Those batch files may not simply be an IBM programmer bringing strange habits to DOS. They may be what was needed after RPG had been taken away from the environment it originally expected.

RPG came from IBM’s midrange world and was later ported to DOS. What Brant found was an accounting package made from numerous RPG modules, surrounded by DOS batch files and a numbered menu system. Whether or not this particular package was literally migrated from an IBM system, that surrounding machinery caught my attention.

And this connects all the way back to my research.

An application is not necessarily bounded by its source code.
An application is the combination of the programs, the data, and the environment in which they are expected to run.

So when you move the source code somewhere else and run it there, you may have moved the programs without necessarily moving the application as a whole.

Back to Brant’s archaeological find: the RPG programs are there, but so is the glue required to turn them into a usable application under DOS. Menus, orchestration, batch files. And this leads us to something deeper.

Unix and DOS come from a rather different philosophy from IBM i, or AS/400 as many people still know it. I like to think of them as almost opposite Lego-brick philosophies.

Unix says: here are excellent primitive bricks. Processes, files, I/O, devices, permissions, scripting and so on. Build the machine. You compose the environment your application needs from those basics.

IBM i says: here are larger building blocks. The machine room already has conveyor belts, cupboards, labels and electricity. Database objects, jobs, queues, menus, messaging, printing and spooling, library lists, authorities, display and printer files, CL. Build the business process that runs through them.

IBM i starts much further up the stack. It is not merely an operating system that happens to host applications. It is also an application environment.

It is not that one is better than the other.
They simply draw the boundary between the operating system and the application in different places.

Please hold that thought for a moment.

Coming from a DOS or Unix environment, it would be perfectly natural to look at RPG or COBOL plus a database and think: there is the application. Then you move the source, reproduce the data, and start discovering all the assumptions that were hiding outside the source: queues, jobs, library resolution, spool behaviour, messages, authorities, overrides, record semantics, and so forth.

This is the rehosting consequence. Context tends to disappear from view when it is always there. We notice it only when we remove the program from it. Rehosting is often the moment when implicit architecture becomes explicit.

…and I can see you now. I can see your grinning face saying: “Nice, but that is archaeology. It doesn’t apply to me.”

Sorry to disappoint you, but this isn’t just a legacy phenomenon.
In fact, we never really stopped doing it.

In the early 2000s, Java application servers made the same pattern rather obvious. An application deployed into WebSphere, WebLogic or JBoss could rely on the surrounding server for data sources, messaging, transactions, security, connection pools, sessions and other services. Move the Java code somewhere else and, once again, moving the program was not necessarily the same thing as moving the application.

And then containers arrived. A container is a container, right?

Think about a standalone container running on your fancy computer. On its own, perhaps it really is fairly self-contained.

Run that container under vanilla Kubernetes and it starts acquiring context: Services, Gateway or Ingress, Secrets, persistent volumes, identity, controllers.

Let me go one step further.

That same containerised application might be running under Amazon EKS while depending on SQS, SES, Cognito, AWS-specific load-balancer metadata, IAM roles and managed services. Or the corresponding set of Google Cloud or Azure facilities.

The Python code didn’t change.

The container didn’t necessarily change.

But the application context became partly AWS.

Now try to carve that workload out of EKS and run it elsewhere. Suddenly you are doing the same archaeological exercise again: discovering what belonged to the program and what belonged to the environment around it.

A container image may be portable. The application around it may not be.

It is the same pattern I saw in Brant’s archaeological find. Move the program and you may discover how much of the application was actually supplied by the environment around it.

Rehosting is still rehosting, whether the guest is COBOL on IBM i or Python on EKS.

And that brings me to what I wanted to express all along: context matters.

We often preserve software by preserving its source. But sometimes part of the application was the world around it.

In a previous post I mentioned that data is the centre of gravity and programs are guests.
But guests still need a house.