OL Code architecture

Executive architecture summary

OL Code is a browser-based development and modernization workbench for COBOL and RPG assets on IBM Z and IBM i. It gives enterprise teams a governed workspace to browse legacy source, edit programs, compile and submit jobs, inspect job output, test host programs as OL Integration assets, convert selected screen programs into RPC-style services, generate reverse API clients, and bring adjacent analysis and data-inspection context into the developer workflow.

The architectural role of OL Code is deliberately focused: it modernizes the developer experience around host source and selective modernization workflows while preserving the host as the system of record for source assets, compilers, job execution, and operational controls. OL Code does not replace host execution, host security, or the production runtime. It provides a governed browser surface and orchestration layer around existing enterprise assets.

OL Code is organized around five layers:

Browser workbench: Explorer, Code Viewer, Git UI, compile actions, Hub Operations, CoreIQ panel, AtomIQ panel, Specs panel, Screen to RPC conversion, and Reverse API generation.
OL Code application services: session handling, source browsing, editor services, search, compile orchestration, job file retrieval, map viewing, conversion workflows, and controlled proxy services to adjacent OpenLegacy systems.
Host connectivity: IBM Z and IBM i access paths for datasets, members, source libraries, compile templates, JCL submission, job output, BMS maps, MFS maps, and source retrieval.
Modernization integration plane: OL Integration for asset testing, API creation, Hub REVERSE projects, and generated API clients; AtomIQ for documentation and relationship analysis; CoreIQ for read-only DB2 and VSAM inspection; OL Spec for specification analysis.
Enterprise controls: identity, secrets, repository configuration, Git workspace governance, audit, logging, and network segmentation across developer, OpenLegacy, and host zones.

Architectural intent

OL Code is intended for organizations that need to modernize mainframe and IBM i delivery practices without forcing teams to abandon existing host assets, compilers, datasets, copybooks, maps, libraries, and operational controls. It brings source understanding, editing, compile, testing, conversion, and API enablement into one governed browser experience.

The target enterprise outcomes are:

Reduce dependency on green-screen developer tooling for day-to-day source work.
Standardize source browsing, editing, compile, and job feedback in a browser IDE.
Shorten the loop from code change to asset test and API enablement.
Give developers host-data and program-analysis context without moving sensitive assets into uncontrolled tools.
Support selective modernization patterns, including screen-to-RPC conversion and reverse API client generation.
Connect development activity to enterprise governance, identity, audit, secrets, and network controls.

Core components

Browser workbench

The browser workbench provides the user-facing Explorer and Code Viewer. Developers connect to IBM Z or IBM i, browse datasets and members, open source in multi-tab editors, navigate declarations and referenced files, inspect code outlines, compare and revert edits, submit compile actions, and view job files.

Explorer and source access services

Source access services mediate dataset and member browsing, filtering, scoped search, downloads, map and copybook marking, member actions, and platform-specific source operations. These services preserve the host-centered source model while making it consumable through a modern browser workspace.

Editor, compile, and job orchestration

Editor services manage file lifecycle, save, delete, download, source navigation, diff, keyboard actions, BMS and MFS map viewing, and compile invocation. Compile and job orchestration use configured connection templates and platform permissions to submit work to the host, follow job status, and retrieve job output.

Git workspace integration

When enabled by administrators, OL Code connects source work to a Unix workspace and configured Git repository. Developers can clone, branch, stage, commit, push, pull, rebase, and discard changes. Git activity is additive to the host workflow and should be governed through enterprise source-control policies.

OL Integration integration

OL Code uses OL Integration for Hub asset testing, API creation, reverse API project handling, and generated client workflows. OL Code is the developer entry point into these workflows, while OL Integration remains responsible for asset modeling, connector execution, contracts, generated projects, runtime API flows, and publication governance.

Analysis and data inspection integrations

OL Code can surface adjacent OpenLegacy systems in the code context:

AtomIQ analysis beside the editor for documentation, call relationships, and operations.
CoreIQ read-only DB2 and VSAM inspection from the currently open file.
OL Spec analysis based on AtomIQ operations for the open member.

These integrations are governed through administrator-configured URLs, credentials, hosts, account settings, policy boundaries, and enterprise network controls.

Conversion and generation services

OL Code supports two modernization directions from the IDE:

Inbound modernization: selected screen COBOL programs can be converted into RPC-style COBOL services, then registered and tested through OL Integration.
Outbound modernization: COBOL and RPG clients can be generated from OpenAPI specifications or Hub REVERSE projects so legacy programs can call modern HTTP APIs through OLREVAPI.

Capability coverage

Legacy explorer and code editor

The Explorer and Code Viewer provide browser access to IBM Z and IBM i source. Teams can browse datasets and libraries, search by name or content, edit source in multi-tab editors, use Ctrl+click navigation, inspect outlines, compare changes, revert edits, compile, submit JCL, inspect job files, view BMS and MFS maps, and optionally use Git.

Architectural value:

Creates a common browser-based developer experience across IBM Z and IBM i.
Preserves host-centered source access while reducing dependency on terminal-only development flows.
Provides scoped search and navigation so developers can move faster without broad uncontrolled host scans.
Keeps compile and job feedback tied to configured host execution paths.

Scope boundary: this capability modernizes the developer experience around host source. It does not move the authoritative runtime away from the host, and it does not replace host compilers, JCL, or job execution.

Hub asset testing from the IDE

Hub asset testing lets developers create OL Integration modules and assets from the currently open COBOL program, include selected copybooks, edit JSON input, run Hub test cases, and inspect results inside the Code Viewer.

Architectural value:

Reduces context switching between source editing and service testing.
Lets teams validate host logic as an integration asset before publication.
Supports iterative edit, compile, test, and inspect cycles from one workspace.
Connects developer workflows to the OpenLegacy API enablement lifecycle.

Scope boundary: OL Code initiates and displays the test workflow. OL Integration owns the Hub asset model, connector execution, test cases, and API publication path.

Screen to RPC conversion

Screen to RPC conversion transforms selected mainframe screen COBOL into stateless RPC-style COBOL that preserves business rules while removing UI-specific interaction. Teams can use a deterministic algorithmic path or, where policy and configuration permit, an AI-assisted specification-first path. The resulting RPC COBOL can then be registered, tested, and exposed through OL Integration.

Architectural value:

Provides a selective path for turning screen-bound logic into service-oriented COBOL.
Supports multi-step screen flows through related programs and shared copybooks.
Keeps generated output in a reviewable host-language form.
Aligns converted programs with Hub testing and API creation workflows.

Scope boundary: this is a source transformation path for selected screen programs. It is not terminal screen automation, not direct data access, and not a full application rewrite. Generated or converted code still requires normal enterprise review, compile, testing, and release governance.

Reverse API client generation

Reverse API client generation produces COBOL and RPG clients that call modern HTTP APIs through Hub REVERSE technology and the OLREVAPI module. Developers can create a reverse API project from an OpenAPI specification or select a published Hub REVERSE project, generate platform-specific client code and copybooks, compile with reverse API templates, and optionally test through the Hub gateway.

Architectural value:

Enables legacy programs to participate in modern API ecosystems.
Reduces hand-written HTTP integration code in COBOL and RPG.
Supports IBM Z and IBM i client-generation patterns.
Connects external API consumption to Hub project and contract governance.

Scope boundary: this capability enables legacy programs to call external APIs. It does not expose host programs as APIs by itself and does not replace OL Integration runtime governance for Hub REVERSE projects.

AtomIQ analysis beside the editor

AtomIQ analysis beside the editor lets developers read documentation, call relationships, and operations for the open member. They can start analysis for selected datasets or members, monitor completion, jump from relationship entries to source lines, and open the same workspace in AtomIQ.

Architectural value:

Brings program understanding directly into the editing context.
Lets developers navigate from analysis relationships back to source lines.
Supports modernization planning by connecting code, operations, and documentation.
Avoids a disconnected handoff between analysis tools and the IDE.

Scope boundary: OL Code surfaces and initiates AtomIQ analysis through configured integration points. AtomIQ owns the deeper analysis model, workspace, documentation, relationships, and operation discovery behavior.

Read-only DB2 queries from the open file

The CoreIQ SQL panel extracts EXEC SQL statements from the open COBOL file, lets the developer inspect and adjust read-only SELECT or WITH statements, fills host variables, and pages through DB2 result rows through the configured CoreIQ server.

Architectural value:

Gives developers immediate context for embedded SQL while source is open.
Keeps query execution behind configured CoreIQ connectivity and policy.
Limits execution to read-only SQL inspection.
Improves debugging and comprehension without creating a general write path.

Scope boundary: this is read-only inspection for developer context. It must not be positioned as a substitute for business-transaction APIs or as a write path into business data.

Read VSAM records from the open file

The VSAM view matches CICS file statements in the open COBOL program to configured VSAM datasets and displays decoded records with optional key filtering. Only read operations are executable from OL Code, while update-oriented statements such as REWRITE, WRITE, and DELETE are not run.

Architectural value:

Lets developers inspect records related to CICS file I/O without leaving the source context.
Uses configured CoreIQ connectivity for dataset and layout access.
Supports key-based read context for debugging and comprehension.
Keeps OL Code aligned to read-only inspection for this path.

Scope boundary: this capability is for read-only inspection and debugging context. It does not replace CICS transaction logic and should not be used as a primary path for business transactions.

Run an OL Spec analysis from the open file

OL Spec analysis creates or opens a specification workspace from AtomIQ operations related to the open member, starts or follows an analysis run, displays generated specifications and notes, renders diagrams, and links to the same workspace in OL Spec.

Architectural value:

Connects source context, AtomIQ operation discovery, and specification creation.
Gives developers a way to review generated specifications without leaving OL Code.
Supports architecture and modernization planning by surfacing diagrams and notes near the source.
Reduces friction between code understanding and documentation workflows.

Scope boundary: this produces specification and analysis artifacts for human review. It does not certify host behavior, replace source control, or replace enterprise design approval.

Security and governance model

OL Code should be deployed behind enterprise controls for identity, host access, secrets, repository access, and observability.

Recommended controls include:

Enterprise identity integration for OL Code access and administrative settings.
Per-user host authentication for IBM Z and IBM i source access.
Secrets management for Hub API keys, AtomIQ URLs and keys, CoreIQ settings, OL Spec settings, Git credentials, and host connection templates.
Network allowlists between OL Code, host services, OL Integration, AtomIQ, CoreIQ, OL Spec, Git, and enterprise monitoring systems.
Role-based access to administrative configuration, conversion actions, compile templates, Git workspace setup, and connected systems.
Audit and logging for source access, compile actions, generated artifacts, conversion events, Hub calls, and adjacent-system proxy calls.
Change-management controls for generated RPC programs, reverse API clients, copybooks, compile templates, and promotion to downstream environments.

Operational model

A typical enterprise deployment separates responsibilities across teams:

Development teams use OL Code for browsing, editing, compile feedback, asset testing, analysis, and generation workflows.
Mainframe and IBM i teams govern host access, dataset permissions, compilers, JCL, libraries, job classes, and runtime readiness.
Integration teams govern Hub modules, assets, projects, API contracts, reverse API projects, and published services in OL Integration.
Platform teams operate OL Code services, browser access, network policy, secrets, logging, backups, deployment automation, and high availability.
Architecture and governance teams define which programs are eligible for screen-to-RPC conversion, which external APIs can be called from host code, and which analysis artifacts can be used in delivery decisions.

Scope boundaries and positioning

OL Code is best positioned as the developer and modernization workbench for COBOL and RPG teams working on IBM Z and IBM i assets.

It does not provide:

A standalone production API runtime.
A replacement for host compilers, JCL, job execution, or runtime operations.
A write-oriented DB2 or VSAM data access product.
A business-transaction API by reading data directly from DB2 or VSAM.
A generic terminal emulator or screen automation runtime.
Automatic certification that generated or converted code is production-ready.

Related products remain relevant for adjacent patterns:

OL Integration for API asset modeling, generated services, runtime API execution, Hub testing, and reverse API projects.
OL CoreIQ for governed host data access, DB2 and VSAM inspection, and data-oriented API capabilities where appropriate.
OL AtomIQ for deeper program analysis, documentation, relationships, and operation discovery.
OL Spec for specification generation and analysis-review workflows built from AtomIQ operation context.