Why 3270Connect Exists
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.
The Real Problem with 3270 Automation
On paper, automating a 3270 terminal sounds simple:
- Connect to TN3270
- Send keystrokes
- Read the screen
- Repeat
In practice, it’s anything but simple.
Common pain points include:
- 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
Many teams end up with brittle Expect scripts or UI-driven screen scraping that works just enough to be dangerous.
What 3270Connect Is (and Isn’t)
3270Connect is an open-source automation engine designed specifically for programmatic interaction with 3270 terminals.
It is:
- Written in Go
- Built for concurrent sessions
- Designed around explicit screen state handling
- Suitable for headless, service-driven automation
It is not:
- A GUI emulator
- A screen recorder
- A replacement for core mainframe logic
Think of it as infrastructure glue — useful when you need repeatable, controlled interaction with existing mainframe workflows.
Why Existing Tools Often Fall Short
Most existing approaches fall into one of three categories:
1. Terminal scripting tools
These tend to:
- Be sequential
- Lack structured error handling
- Break easily with minor screen changes
2. GUI-based screen automation
These:
- Rely on pixel position or text matching
- Are slow and fragile
- Don’t scale well for backend automation
3. Custom in-house tooling
Often:
- Hard-coded to a single system
- Poorly documented
- Difficult to extend or hand over
What’s missing is a programmable, concurrent, automation-first approach that treats 3270 like a system interface — not a human UI.
Design Principles
1. Automation First
3270Connect assumes:
- No human is watching the screen
- Failures must be detectable and explainable
- Automation needs retries, timeouts, and recovery paths
2. Concurrency by Design
Many tools treat concurrency as an afterthought.
3270Connect treats it as a requirement.
You can:
- Run multiple sessions in parallel
- Isolate failures per session
- Scale automation horizontally
- Simulate random human "thinking" between transactions and steps
3. Explicit Screen State Handling
Rather than blindly sending keystrokes, workflows are built around:
- Waiting for known screen conditions
- Validating expected states
- Failing fast when something unexpected appears
This dramatically reduces “silent failures”.
Real-World Use Cases
Some examples where tools like this are genuinely useful:
- 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
In many organisations, full replacement isn’t immediate — automation buys time and reduces risk during transition.
Why It’s Open Source
Mainframe tooling lives in a strange space:
- Highly specialised
- Often locked behind expensive licenses
- Hard to evaluate without real workloads
By keeping 3270Connect open:
- Teams can audit the code
- Security teams can asses
Top comments (0)