Mainframe orchestration
The mainframe use case is the first on the Flow platform. It provides end-to-end mainframe workflow orchestration built on Zowe CLI, demonstrated through a VS Code extension. It took first place in its hackathon division.
The persona
Section titled “The persona”Michelle is a software engineer who is new to mainframes. She is comfortable with Java and Git, but her biggest challenge is not writing code. It is finding her way through too many different tools that do not work well together.
- Siloed tooling. She has to switch constantly between VS Code, ISPF, and terminals.
- No visual context. JCL-based processes do not have a visual structure.
- Senior staff dependency. She has to rely on experts for routine tasks.
- No feedback loop. She has to inspect the spool by hand, which breaks her flow between attempts.
The journey map
Section titled “The journey map”Without Flow: She opens ISPF and navigates to the JCL. She submits the job by hand and checks the job queue from time to time. She opens the spool viewer and copies the results into an email for QA. If the job failed, she edits it again or asks a senior developer.
With Flow:
- She drags nodes onto the canvas.
- An AI node reviews the JCL locally. The inference runs on her machine, with zero network.
- The orchestration engine submits the job using an authenticated Zowe profile.
- A Download Spool node retrieves the output. An AI node then adds plain-language annotations, locally.
- Failure recovery suggests a fix and can re-run the job.
- An email notification with the AI-generated summary goes to QA.
All AI inference happened on Michelle’s machine. No data left her laptop.
The execution graph
Section titled “The execution graph”| Step | Node | Type | Description |
|---|---|---|---|
| 1 | Submit JCL | Action | Submits via Zowe CLI (authenticated) |
| 2 | AI: Review JCL | AI (local LLM) | Local inference, no network |
| 3 | Download Spool | Action | Retrieves job output |
| 4 | AI: Interpret spool | AI (local LLM) | Local inference, no network |
| 5 | Email Notification | Utility | Sends AI-summarized results |
Failure recovery
Section titled “Failure recovery”When a step fails, the orchestration engine invokes local AI models to diagnose and suggest corrective action:
- Syntax errors are re-analyzed by an AI node, which presents a one-click fix.
- Non-zero return codes are passed to an AI node, which suggests parameter adjustments or JCL modifications.
- Model unavailable is the deterministic fallback. The failure surfaces with the raw execution output, and the graph continues with the AI step skipped. It is never blocked.
Retry state lives in the engine
Section titled “Retry state lives in the engine”AI models are stateless by design. This is a security property, not a limitation. On each retry the orchestrator passes the original input, the model’s previous suggestion, the outcome of applying it, and a retry counter. The model gets the history it needs without compromising its stateless isolation.
User control
Section titled “User control”- Auto-retry is opt-in per execution node, and it is off by default.
- AI suggestions are presented for user approval before execution by default.
- Fully autonomous retry has to be enabled explicitly.
- All retry attempts are logged in the execution history for audit.
Related
Section titled “Related”- CI/CD and QA shows the same architecture in new domains.
- Spool-driven generation