Tools: Automating 3270 Mainframe Workflows with Go

Why 3270Connect Exists ## The Real Problem with 3270 Automation ## What 3270Connect Is (and Isn’t) ## Why Existing Tools Often Fall Short ## 1. Terminal scripting tools ## 2. GUI-based screen automation ## 3. Custom in-house tooling ## Design Principles ## 1. Automation First ## 2. Concurrency by Design ## 3. Explicit Screen State Handling ## Real-World Use Cases ## Why It’s Open Source Mainframes are not legacy in the sense people often assume. They’re legacy in interface, not importance. Across banking, insurance, logistics, and government systems, 3270 terminals still sit at the heart of critical workflows. The problem isn’t that these systems exist — it’s that automating them reliably is still surprisingly difficult. That gap is why 3270Connect exists. On paper, automating a 3270 terminal sounds simple: In practice, it’s anything but simple. Common pain points include: Many teams end up with brittle Expect scripts or UI-driven screen scraping that works just enough to be dangerous. 3270Connect is an open-source automation engine designed specifically for programmatic interaction with 3270 terminals. Think of it as infrastructure glue — useful when you need repeatable, controlled interaction with existing mainframe workflows. Most existing approaches fall into one of three categories: What’s missing is a programmable, concurrent, automation-first approach that treats 3270 like a system interface — not a human UI. Many tools treat concurrency as an afterthought. 3270Connect treats it as a requirement. Rather than blindly sending keystrokes, workflows are built around: This dramatically reduces “silent failures”. Some examples where tools like this are genuinely useful: In many organisations, full replacement isn’t immediate — automation buys time and reduces risk during transition. Mainframe tooling lives in a strange space: By keeping 3270Connect open: Templates let you quickly answer FAQs or store snippets for re-use. Are you sure you want to hide this comment? It will become hidden in your post, but will still be visible via the comment's permalink. Hide child comments as well For further actions, you may consider blocking this person and/or reporting abuse - Connect to TN3270 - Send keystrokes - Read the screen - Stateful screens with no stable identifiers - Timing issues (screens that appear “ready” but aren’t) - Concurrency limits when running multiple sessions - Fragile scripts tied to exact screen layouts - Poor error visibility when automation fails mid-flow - Written in Go - Built for concurrent sessions - Designed around explicit screen state handling - Suitable for headless, service-driven automation - A GUI emulator - A screen recorder - A replacement for core mainframe logic - Be sequential - Lack structured error handling - Break easily with minor screen changes - Rely on pixel position or text matching - Are slow and fragile - Don’t scale well for backend automation - Hard-coded to a single system - Poorly documented - Difficult to extend or hand over - No human is watching the screen - Failures must be detectable and explainable - Automation needs retries, timeouts, and recovery paths - Run multiple sessions in parallel - Isolate failures per session - Scale automation horizontally - Simulate random human "thinking" between transactions and steps - Waiting for known screen conditions - Validating expected states - Failing fast when something unexpected appears - TN 3270 Volume Testing with legacy systems - Regression testing during mainframe modernisation - Nightly operational workflows that still depend on 3270 screens - Bridging automation gaps while systems are gradually replaced - Highly specialised - Often locked behind expensive licenses - Hard to evaluate without real workloads - Teams can audit the code - Security teams can asses