If you work with IBM Mainframes (z/OS, z/VM) on a Mac, you’ve probably noticed a glaring issue: every halfway-decent TN3270 terminal client costs money. Sometimes a lot of money.
We’re talking $50–$100+ for software that essentially emulates a 1970s text terminal. One popular commercial option even charges a recurring subscription just to let you type on a green screen. That felt absurd to me.
The free alternatives out there usually fall into three categories:
- They require Java (slow, resource-heavy, and clunky on macOS).
- They run inside X11 (no thanks).
- They are abandonware that breaks on every macOS release.
So, I decided to build my own from scratch.
Introducing DX3270
After a weekend of intense frustration and diving deep into ancient IBM GA23-0059 architecture manuals, I released DX3270 (hosted under the X3270 repo).
It is a completely free, MIT-licensed, native macOS TN3270/TN3270E terminal emulator.
Check out the repository here: GitHub
I wanted something that actually feels like it belongs on a Mac. No Java, no X11, just native performance.
How I Built It
I wrote DX3270 entirely in C++ and Objective-C++. By building it on top of native macOS frameworks, it achieves a completely different level of performance and system integration compared to cross-platform electron/Java wrappers.
- Rendering: I used Apple's CoreText for calculating glyph metrics to ensure a pixel-perfect character grid.
- Security: Native OpenSSL integration for implicit TLS (TLS 1.2+) on any port.
- Protocol: Full TN3270E (RFC 2355) negotiation.
One of the hardest (and most interesting) parts was implementing the IBM Structured Field Read Partition Query. Without this Query Reply, mainframe menus like ISPF simply won't render correctly. Getting the exact hex codes right (like fixing the PF10-12 AID codes based on strict IBM standards) was a huge learning curve.
Key Features
I recently updated the app to support dynamic screen buffers and multiple models. Here is a quick breakdown of what DX3270 can do:
- Multi-Model Support Model 2 (24×80), Model 3, 4, 5, and a custom Large model (62×160) using 14-bit buffer addressing.
- Authentic Font Bundled with the incredible open-source IBM 3270 font by Ricardo Bánffy.
- Native UI Green-on-black phosphor, authentic 600 ms cursor blink, and a block cursor.
- Traffic Monitor Built-in floating hex dump monitor (⌘⇧D) to debug raw Telnet/TN3270 bytes in real-time.
- Export Tools Pixel-perfect PNG screenshots (⌘⇧P) and EBCDIC-to-UTF-8 formatted text exports (⌘⇧T).
Try it out!
If you work in Mainframe, use a Mac (Apple Silicon or Intel), and are tired of paying for the privilege of connecting to your own environments, DX3270 is for you.
I actually built this tool just for my own sanity, but after it got some unexpected traction on LinkedIn, I realized a lot of other developers share this exact pain point.
I’ve set up GitHub Actions to automatically publish pre-built .dmg files for both Apple Silicon and Intel architectures on every release. You can download the latest version directly from the Releases page.
I would absolutely love to hear your feedback, bug reports, or feature ideas. Feel free to open an issue or drop a comment below!
Happy connecting!


Top comments (4)
This is a great build - honestly long overdue for macOS users in mainframe environments.
Nice call going fully native instead of Java/X11 wrappers.
How are you handling reconnects when a TN3270 session drops?
Hello, thank you for your comment.
Currently, DX3270 does not do automatic reconnects.
So the drop-handling is notify and close window. There is no retry timer, no backoff, and no session restoration. The user has to open the Connect dialog again manually.
This is not optimal at this moment and have to be changed.
If you like, you're invited to write this as an issue (so I can keep it in mind).
Thanks for the clarification! That makes sense for now. I’ll definitely consider opening an issue -automatic reconnect with backoff would be a great QoL improvement for long-running sessions. Appreciate you taking the feedback!
Great project — building native instead of wrapping Java or X11 is
always the right call. I've been on the same path with embedded AI:
stripping everything down to pure C with no runtime overhead.
Different domain, same obsession with respecting the hardware.
Some comments may only be visible to logged-in visitors. Sign in to view all comments.