So you’re working with a real company who has real workloads requiring fancy things that only a real mainframe can provide. Perhaps they’re nice enough to give you access to their IBM Z system, the kind that only IBM can provide. Right?
This is the situation we found ourselves in recently. So I started the process of talking with IBM to get access to an environment where we can test and validate the parts of our solution that need to run on z/OS, the real operating system for which there is no substitute.
But then, in some late night Slack conversations with my colleague Lucas Wakigawa who only takes the word “impossible” as a dare, some alternatives surfaced…
Our goal is to offer a sample application with a real terminal user interface presented over 3270.
While our sample application is fairly simple, it’s plenty for what we need today: a dev/test bed for our terminal screen integration components, hostable for local dev, or in a way that is compatible with our CI/CD systems.
Well Actually
Depending on what you’re looking to do, it turns out that it might be possible to achieve it using a combination of emulation and community-maintained software.
Components that we used in this environment:
- Hercules - An open-source emulator of IBM mainframe hardware (System/370 through z/Architecture). It runs real IBM mainframe operating systems. Version 4.9.1-SDL is the actively maintained SDL fork of the project.
- MVS 3.8j - IBM's "Multiple Virtual Storage" operating system, specifically the 1981 release that IBM left in the public domain, so it's free to run. It's the direct ancestor of today's z/OS, and it's what hobbyists and labs use to run authentic mainframe software. [On a personal note, I’m not 100% sure, but I think this is the same OS that I used at a local university’s computer lab when I was in high school.] Obviously there are a lot of things we need to develop, test, and support, that are not hostable in MVS, so we definitely also need a real z/OS system to validate those components.
- TK5 (Turnkey 5) - A ready-to-run distribution of MVS 3.8j for Hercules: the OS plus compilers, tools, and configuration already set up so it boots and works out of the box. It's community-maintained (lineage: Volker Bandke's TK3 → Jürgen Winkelmann's TK4- → Rob Prins's TK5. To these engineers: thank you for your work on this!)
- KICKS - A CICS-like transaction-processing environment. It hosts the online transaction programs (the interactive green screens). KICKS supports a subset of the CICS API, allowing compatible applications to run after recompilation. One caveat: it runs as a single-threaded, single-user process. You have the option to run multiple users at the same time against the same VSAM files, if you open them read-write shared. (Full name: KICKS for TSO/390, by Mike Noel. Thank you, Mike, for this useful software!)
Vibecoding in COBOL
After standing up this virtual infrastructure, the next task was coding a CICS sample application.
Remember how less than a year ago we were all talking about what languages were best for coding agents? Today there are no limitations. Even 370 Assembler is no problem (and there are a couple bits in our example application that go there). Lucas was able to implement complete end-to-end functionality with no previous experience in this domain and minimal pointers on how to achieve it. To be fair, he does have a lot of experience with fast prototyping and using coding agents to do it, as well as a reputation for persistence.
But Alex, Why Would You Even Do This?
Monarch integrates with z/OS Connect, native CICS web services, and other more modernization-oriented mechanisms. But our mission as a workflow solution is to integrate deeper, to address the workflows that are harder to reach. We just needed a terminal application to develop our componentry that covers that last mile, to reach functionality that’s never been exposed via an API, or where there is some gap between what the APIs can do versus the 3270 screens of the application itself.