The bottleneck is the keying, not the mainframe
The host is rarely the slow part: mainframe and midrange applications on IBM Z (3270), IBM i (5250), VT and HP 6530 terminals still process core transactions reliably. What slows the business down is the step before the transaction, where people read invoices, orders and claims and type them into those screens one field at a time.
Mainframe automation that starts at the document and ends with a confirmed record on the host removes that step without touching the application.
- Queues grow at peak periods faster than a small team can key
- A transposed digit in a terminal field travels into billing, inventory or claims
- People who know the menus, codes and function keys are hard to replace
- Rewriting the application to remove the keying is a multi-year project
How mainframe workflow automation works
Mainframe workflow automation with legacy bridge follows the path a document already takes in your office, from inbox to confirmed record. See data entry automation for the same flow across every system type.
Documents arrive
By email, SFTP/FTP folder polling or API upload: PDF, scans, photos, faxes, Word and Excel.
AI vision reads them
Fields are extracted without OCR templates per layout. A file holding several records is split into one record each, and a document already keyed is caught as a duplicate.
Values are checked
Against the document itself, against your process rules written in plain English, and against what the host already holds.
The agent works the screens
It signs on, navigates the menus, fills the right fields, handles lookups and function keys, and reads the host's own messages.
A person approves
By default every prepared transaction waits for an employee in the web console or from an email link. Once trusted, a workflow can run on its own.
The record is confirmed
The agent reads the record back and logs the result. Unclear values are held for a person, never guessed.
Why green screen automation is different from desktop RPA
Green screen automation works on a structured terminal protocol, while desktop RPA works on pixels. A 3270 or 5250 data stream tells the client exactly where each input field is, what it accepts, which function keys are valid and what message the host returned. Mainframe RPA built on a desktop emulator ignores that structure and clicks at coordinates, so scripts break when a screen moves; legacy bridge reads the screen by meaning. More is in AI RPA versus traditional RPA and the IBM i RPA alternative.
| Criterion | legacy bridge | Desktop RPA |
|---|---|---|
| How it sees the screen | Terminal protocol: fields, attributes, cursor and host messages | Pixels and coordinates in an emulator window |
| Where it runs | Cloud service, connects like an emulator | Bots on desktops or virtual machines |
| When a screen changes | Finds fields by label and meaning | Recorded script breaks and needs a developer |
| Host errors | Reads the message, shows a person the error and the screen, submits nothing | Predefined rules, fails on anything unscripted |
Terminal automation across 3270, 5250, VT and 6530
One terminal engine handles terminal automation for four families of green-screen systems. Customers run legacy bridge in production on IBM i (AS/400) today, over TN5250. The same engine speaks TN3270, VT and HP 6530, and a workflow on those platforms is scoped with the same controlled proof on one real document before anyone commits.
| Protocol | Platforms | Status |
|---|---|---|
| TN5250 | IBM i, AS/400, iSeries, System i: custom RPG and COBOL applications and packaged ERPs | In production |
| TN3270 | IBM Z mainframes, z/OS: CICS, IMS and TSO screens | Supported, scoped per workflow |
| VT | OpenVMS, Unix and Pick applications | Supported, scoped per workflow |
| HP 6530 | HP NonStop (Tandem) | Supported, scoped per workflow |
TN3270 and CICS screen automation
On IBM Z, the agent drives the 3270 screens CICS, IMS and TSO applications present: it fills fields, presses Enter or the PF key the screen expects, and reads the reply. It calls no transactions directly.
Midrange (AS/400) automation
IBM i is where legacy bridge runs in production: order, invoice and claims entry into custom RPG and COBOL applications and packaged ERPs, over TN5250, with every record read back. See IBM i data entry.
OpenVMS and HP NonStop terminal automation
VT applications on OpenVMS, Unix or Pick and HP 6530 screens on NonStop are handled by the same engine, scoped per workflow.
Mainframe modernization without migration
Mainframe modernization usually means a migration: rewrite or re-platform the application, move the data, retrain users and run both systems for years. That may be the right long-term plan, but it does nothing for this week's documents.
Mainframe automation through the existing terminal screens is the other half of the plan. The COBOL and RPG programs, the data, the screens and the security model stay as they are; only the way data gets into them changes, from manual keystrokes to an agent that a person supervises. We wrote up the reasoning in modernization without migration, and the wider picture in legacy system automation.
Security and control on the host
Your host's existing security stays in charge, because legacy bridge reaches it the way an emulator does.
- Nothing installed on the host: no new APIs, no database access, no changes to COBOL or RPG programs
- Connects over the terminal protocol, like any emulator; hosts not exposed to the internet are reached through a secure SSH tunnel
- Signs on with a user profile you create and scope, so the host allows only the menus and screens that profile can reach
- Every keystroke and screen is recorded in a tamper-evident audit trail with a SHA-256 hash chain, and sessions can be replayed
- Built by a company certified to ISO 9001, ISO/IEC 27001 and ISO/IEC 27017, on PCI DSS-compliant infrastructure
Mainframe automation compared with the usual options
| legacy bridge | Manual keying | Mainframe RPA scripts | API or migration project | |
|---|---|---|---|---|
| Start | A controlled proof on one real document | Today, at full labour cost | A script built for every screen path | Months to years |
| Host | No change, nothing installed | No change | No change, bots on desktops | New programs or a new platform |
| Screen changes | Read by meaning | People adapt | Scripts break | Not relevant once replaced |
| Checks | Document, plain-English rules, host data, human approval | Whatever the operator notices | Only the rules scripted | Built into the new system |
| Audit | Every keystroke and screen, hash-chained | Who signed on, not what they read | Bot logs | Depends on the build |
Who it is for, and how to start
legacy bridge is for operations, finance and IT managers whose teams key invoices, purchase orders, sales orders, claims, work orders or bills of lading into a green-screen system. Document AI explains why extraction alone still leaves the last mile to people; industry examples are on solutions.
Every engagement starts with one real document: a controlled proof on your own document and screens, inside an access setup you approve. It stops before final submission and nothing changes in live data without your employee's approval. Pricing is $99 a month plus usage per document, billed only for records filed and confirmed on the host; details are on pricing. The team behind it is part of scandiweb and serves 500+ clients, including Fortune 500 companies.
