Player and screen flows

The Player runs the converted program interactively in the browser, with no mainframe required.

The launch bar

Clicking Play shows a progress bar with three steps: Analyze sources, Start session and Ready. It clears itself shortly after the third completes, handing the space to the terminal.

• Analyze sources checks whether a build is needed by hashing the source files and the generation options, not by timestamps, so a git checkout that only touches modification times reports unchanged. A rebuild runs only when a source or an option actually changed.
• Start session launches the runtime session against the current build.
• Ready: the session is live.

If a step fails, the bar stays with the error and a Retry button.

AI-modernized builds. Modernize with AI on Resources sends the current build to the configured LLM and produces an alternate build the Player can run instead. When one exists, the first step names which build will run, with a link to switch. If the AI build has fallen behind the sources, it shows a warning offering Run standard or Modernize now; it never re-runs the LLM on its own. The bar then stays until you click Close.

Screen programs

Select an operation in the sidebar and click Play to start a session. The first screen appears in a map grid matching the original layout. Fill in input fields and press an AID key (Enter, PF3, PF12) to advance; the run log on the right shows each screen transition and action. Stop ends the session.

While a session is active, click Record to capture your interactions as a screen flow. The recording is saved and appears under Screen APIs.

Programs that hand over with XCTL. An operation can hold several CICS programs that pass control with EXEC CICS XCTL PROGRAM(...) COMMAREA(group), such as a list screen that opens a detail screen. The COMMAREA crosses as bytes, the way CICS passes it, so the two programs may name the same bytes differently, and each keeps its own working storage. An XCTL without COMMAREA arrives with EIBCALEN 0. An OCCURS table inside the commarea is carried but not restored by offset, and forwarding the received DFHCOMMAREA onward passes fields by name rather than as bytes.

RPC programs

Each exported procedure appears as its own invokable entry. Fill in the commarea input fields and click Invoke. The data-source switch beside Invoke picks sample or live data for that run.

Each Invoke is one CICS task: autocommit is off for that call, so EXEC CICS SYNCPOINT / SYNCPOINT ROLLBACK and EXEC SQL COMMIT / ROLLBACK keep or undo the task's writes. Screen play does not wrap a transaction.

Use the commarea schema editor on RPC APIs to set each field's direction (INPUT / OUTPUT / IN+OUT), rename fields, or hide internal fields with the eye toggle. The same edits are available without the console:

PATCH /api/applications/{application}/operations/{operation}/programs/{program}/schema

with {"edits": [{"path": "commarea/lkInputParms/lkInUserId", "rename": "userId"}]}. Each edit gives a path from the root and any of rename, direction (INPUT, OUTPUT, BOTH) and hidden. All edits apply or none; the reply returns the saved schema and suggested matching renames.

Record (VSAM) programs

A CICS file-control program reads records, not rows; the record's shape comes from the program's own copybook and the key is the record area's leading field.

• LOCAL is the default: records held in memory for the session, seeded from <FILE>.recs beside the sources, one base64-encoded record per line, with # comments and blank lines ignored, so sample data stays reviewable in a diff. A record whose length is not the copybook's is refused when the session opens, naming both lengths.
• The FILE-to-dataset binding is what the CICS FCT provides on the host. Unbound, a FILE is read as a dataset of the same name, which lets a sample run before anything is configured.
• Supported commands: READ (with GTEQ), STARTBR, READNEXT, READPREV, ENDBR, WRITE, REWRITE, DELETE FILE. RESP comes back as the EIBRESP value a program branches on: NOTFND, DUPREC, ENDFILE, NOTAUTH. A RESP2 operand is cleared to 0.
• READPREV walks a remembered position stack. Keyed positioning is forward only, so a backward browse re-reads keys this browse already returned. Past the remembered window of 500 keys the call fails with INVREQ naming the limit rather than resuming somewhere else.

For real VSAM, see live host data through CoreIQ.

Screen APIs

Screen APIs in the sidebar opens the screen-flow editor. Screen flows are repeatable scripts that automate a sequence of screen interactions, for regression-testing a converted program without manual clicking. They are not available for an RPC operation: the sidebar shows RPC APIs instead, and those operations use the RPC player.

Source above the editor chooses which build a flow runs against: Generated or AI-Generated. AI-Generated stays unavailable until an AI-modernized build exists. The Player launch bar offers the same choice.

• Create manually: write a flow script in the editor, or build it in the UI view.
• Record from Player: click Record during a play session.
• Generate with AI: describe the scenario in natural language.
• Run or Debug: execute a flow and inspect pass/fail results, or step through it one action at a time.

The UI | Code switch shows the same flow two ways. Code is the script. UI is a tree of the flow's steps and conditions. Each row has an always-visible actions menu to add a step, wrap the row in a condition, indent it, delete it, or add an else branch. Editing in the UI view applies each change into the script, so comments and formatting you wrote by hand are kept.

The tree is keyboard-navigable: arrow keys move between the visible rows, right and left expand and collapse a row, Home and End jump to the first and last row, and Enter or Space activates the focused row.

The editor remembers your selection, run inputs and expanded rows in your own browser only, so they start empty on another browser or after site data is cleared. Saved flows are not affected.

Every saved flow is also a REST endpoint; see Flow API and MCP.

Tests

Tests appears in the sidebar only after the operation has test files. Those files are written when generation has both schema.sql and seed.sql to draw cases from. Press Play so the operation has a build, then open Tests.

The list on the left names each file as Screen tests or RPC tests. Editor and JSON show the same file two ways. An unsaved edit is marked Unsaved; Save writes it back.

• Screen tests: Add case. Each case has a name and one or more steps. A step picks a Screen and an AID key, then Add field for the values sent on that screen. Add step extends the walk.
• RPC tests: the file names the program. Add case, give the case a name, and fill Request (JSON).