Getting started

OL Next converts legacy map-based screen and RPC programs (CICS/BMS, IMS/MFS, RPG/DSPF, and COBOL or RPG batch and RPC modules) into JVM code you can run and validate immediately. The screen player runs maps, not a 3270 or 5250 terminal.

The loop

1. Import: upload your sources, pick a built-in example, or pull operations from AtomIQ.
2. Configure: on Resources, set the program name, phase and OO style. There is no separate generate step.
3. Review: browse the imported source in the editor, and edit it in place if it needs a fix.
4. Play and test: click Play. It builds automatically, then runs the program: interact with screens, or invoke RPC procedures, against sample data or a live host.
5. Iterate: change a source or a setting and Play again; it rebuilds only what changed. Record screen flows as repeatable tests.

Quick start

1. Open the console and select or create an application from the header dropdown.
2. Go to Import in the sidebar and choose Import example.
3. Pick a sample, such as cousr01, and click Load. cousr01 is the simplest: a single CICS screen that ships its own schema.sql, so sample data needs no setup.
4. Switch to Player and click Play. It builds automatically, then lets you interact with the converted screen program.

Using the SaaS console

There is nothing to install: SaaS OL Next comes with your OL Hub account, and everything you create belongs to your own tenant.

1. Sign in, either from the OpenLegacy Platform's app switcher (no second login) or at OL Next's own URL, which sends you to the Hub login page and back.
2. Check the workspace. The tenant pill in the header names the tenant you are operating as. A new tenant starts with a single default application, and no other account's applications are visible. A tenant left with no applications gets default back the next time the console loads.
3. Pick or create an application, bring in source, check it on Resources, then press Play, invoke RPC programs, run the saved tests and build screen flows.
4. Push it back to your Git repository from the Source Control panel.
5. Optionally, work from an AI assistant: point an MCP client at OL Next and it can list applications, import a sample and run a conversion for you. See Flow API and MCP.

You don't have access to this workspace means the application belongs to another account, usually a bookmark from before you switched accounts.

Applications and operations

An application is a workspace holding one or more operations (legacy programs); think of it as a project folder. Each application carries its own data source and Git settings.

• Create: open the application dropdown in the header, then New in the panel header.
• Switch: pick another application from the same dropdown. Each row shows the application's description, when it has one, and the date it was created.
• Rename: the row's ⋯ menu, Rename. The name edits in place: Enter saves, Escape reverts, and clicking away saves.
• Settings…: the row's ⋯ menu opens the Edit application dialog over whatever you were doing. See Settings.
• Delete: the row's ⋯ menu removes all operations and generated files permanently.

Operations appear in the sidebar, tagged SCR for a screen program or PRG for a program. Click a row to make that operation active; the ⋯ menu beside the application selector renames or deletes the active operation.

Finding your way around

The sidebar pages depend on the active operation:

• Import: upload or load sources.
• Resources: view and edit the imported legacy source, and set the generation options.
• Player: run the program interactively.
• Screen APIs: record and replay screen flows (RPC APIs for an RPC operation).
• Tests: edit generated screen and RPC test cases, when the operation has them.
• API Docs: browse and try the REST API of every flow and RPC program.
• Source Control: Git status, stage, commit, push.
• Settings: pinned at the bottom of the rail, above the product name and build version; it opens Global Settings.

The chevron on the rail's edge collapses the sidebar to icons and back, and the choice is remembered. On a narrow window (under 900 px) the rail collapses on its own, and the header's branch pill, or the Open workspace panel button before a repository exists, slides the operations list and Source Control in over the page.

The header shows the application selector, a branch pill when Git is enabled (click it to open Source Control), a tenant pill when you signed in through SSO, and AI progress indicators. On the right is the app switcher and your user menu with Account Settings, Help & Documentation, Global Settings and the light/dark theme toggle. A backend with no sign-in shows Help, Global Settings and the theme toggle as buttons instead.

Generation options

Options live on Resources, under the program name and Advanced:

Option	What it does
Phase: REFACTOR (default)	Clean, object-oriented Groovy
Phase: FAITHFUL	Literal line-by-line translation, to verify exact behavior
Phase: AGGRESSIVE	REFACTOR plus domain object extraction
OO style: STATE_PATTERN (default)	Each screen state becomes a class; best for screen programs
OO style: PARAGRAPH_METHODS	Each COBOL paragraph becomes a method; good for batch and non-screen programs
OO style: WORKFLOW_GRAPH	Emits a visual workflow graph, for understanding program flow
Compilation: Static (default) / Dynamic	@CompileStatic Groovy, or plain Groovy for the stock groovy command
Source comments	Embeds the original source lines as comments in the output

Each build also writes dropped-statements.md beside the sources: every statement the converter could not translate, grouped by construct, with the program, the statement and where it happened. The rest of the program still runs. Under REFACTOR or AGGRESSIVE an empty table means every statement was translated; under FAITHFUL the rows are unconfirmed candidates and an empty table proves nothing, as the report itself says.