The Tool Desk
Outbyte Driver Updater FREEFix the driver behind crashes, sound loss and screen glitchesFind Drivers →Outbyte PC Repair FREERepair Windows errors before they cause bigger problemsFix Now →You can make z/OS applications available to cloud and distributed systems without replacing their core processing: put governed interfaces and automation around them, then manage every change through authorization, testing, monitoring, and rollback. IBM z/OS Connect supports two different REST patterns—exposing z/OS resources to external clients and letting COBOL or PL/I programs call external services—so the first design choice is which side needs to initiate the interaction.
Start by choosing which system initiates the interaction
Modernization does not require moving business logic or data off the mainframe. An API boundary can let another application use a z/OS capability while the existing subsystem continues to process the work. The direction of the request determines which integration pattern fits.
As an Amazon Associate I earn from qualifying purchases.
| Pattern | Request direction | What it enables |
|---|---|---|
| API provider | An external REST client calls into z/OS. | Expose supported CICS, IMS, or Db2 resources through REST APIs. z/OS Connect transforms JSON requests into calls using native formats and returns responses as JSON. |
| API requester | A z/OS application calls an external REST endpoint. | COBOL and PL/I programs can consume REST services; tooling can generate requester artifacts and language structures from an OpenAPI document. |
IBM describes an API provider as a z/OS Connect component that transforms REST API requests into calls to z/OS subsystems and returns responses in JSON. The provider pattern is appropriate when a client outside z/OS needs a defined capability. The requester pattern is appropriate when an existing z/OS program needs to use a service elsewhere. Some systems may need both, but each interface should have a specific owner, purpose, and contract.
Choose an API development approach that fits the existing application
API-first
Start with an OpenAPI contract when the interface can be designed before implementation. The contract establishes the operations and data shape, and z/OS Connect tooling can generate artifacts. For requester development, tooling can also generate language structures from the OpenAPI document. This can help teams agree on an interface before coupling implementation work to a particular consumer.
#1 Best Overall
Meet-in-the-middle
When an established COBOL or PL/I application already has native language structures that need to shape the interface, meet-in-the-middle development uses the API description together with those existing structures. This approach acknowledges the application’s current data model rather than assuming the service contract can be designed independently of it.
The useful decision is not which method is universally better. Consider whether a stable API contract already exists, how much the application must change, and whether the interface should reflect existing structures or establish a new boundary. Keep the external contract deliberate even when it maps to legacy data layouts.
Rank #2
- Murach's Mainframe COBOL
- Mike Murach & Associates
- ABIS BOOK
Make security and audit part of the interface design
IBM documents integration with z/OS System Authorization Facility (SAF) for security and System Management Facilities (SMF) for request tracking. These are integration points for an organization’s existing authorization, audit, and chargeback processes—not proof that a particular deployment is secure or compliant.
Do these 3 things before closing this tab:
1Fix the driver behind crashes, sound loss and screen glitches2Repair Windows errors before they cause bigger problems3Scan for outdated or missing drivers - takes under a minute- Define which identities and roles may invoke each API operation, and align authorization with the organization’s SAF configuration and policies.
- Decide what request activity must be recorded and how SMF records will be consumed by existing audit or chargeback processes.
- Include the API, its configuration, and its dependent services in operational monitoring so failures and unusual activity have an owner and response path.
- Review data sensitivity, logging requirements, network exposure, and applicable internal control obligations for the specific workload.
Security depends on the complete deployment: configuration, identity and access decisions, infrastructure, operational practices, and policy. The presence of a security integration feature does not establish that those controls are correctly configured or sufficient for a particular data set.
Build a controlled path from source changes to production
IBM’s z/OS Connect DevOps guidance treats API project source and properties files as source code under source control. Build automation produces deployment artifacts, which deployment automation can promote through environments such as development, staging, test, user acceptance testing, pre-production, and production.
- Version the project. Keep API project source and properties files under the team’s source-control management process. Review changes like other application changes.
- Automate builds. Use a repeatable build to produce the required artifacts rather than relying on undocumented manual steps.
- Manage generated artifacts. Make the build outputs available to the deployment automation that will move them between environments.
- Promote progressively. Validate the API and its integration in the organization’s test environments before production promotion; use the relevant stages for the application’s release process.
- Approve, monitor, and recover. Apply change approval and production monitoring, and establish a workload-specific rollback or recovery path before release.
Automation makes a process repeatable; it does not decide whether a change is safe. Teams still need meaningful tests, operational acceptance criteria, approval rules, and a recovery plan suited to the application’s transaction behavior and dependencies.
Choose runtime and platform by operational fit
IBM documents native z/OS server and containerized deployment options for z/OS Connect, along with CI/CD and container-platform deployment paths. The right choice depends on the organization’s supported platform levels and who can operate the runtime, not on a general claim that one deployment model is safer.
- Native z/OS deployment: assess how the runtime fits existing z/OS operations, security integration, monitoring, and support ownership.
- Containerized deployment: assess container-platform support, the team’s ability to operate that platform, and how the service connects to z/OS and its controls.
- Either path: verify current product requirements, supported versions, security configuration, deployment tooling, and operational responsibilities against the specific z/OS release and middleware environment.
Do not choose a runtime before accounting for topology, workload, data sensitivity, release constraints, and the teams responsible for production support.
Independent reader supportYour contribution helps us test, update, and keep practical guides available for everyone.Use modernization and automation platforms for the work they address
IBM Z and Cloud Modernization Stack brings together IBM Z assets with OpenShift-based hybrid-cloud integration and developer enablement. IBM’s listed tooling includes z/OS Connect, Wazi, z/OS Cloud Broker, Open Enterprise Languages, z/OS Package Manager, and Z Open Automation Utilities. The stack can support broader development and integration workflows, but it does not replace the need to design each transaction boundary and its controls.
Red Hat Ansible Certified Content for IBM Z supports repeatable automation of z/OS and middleware operations. That is an operations-automation role, distinct from the API provider or requester role: automation can make tasks more consistent, while API design determines how applications exchange business requests and data.
Product packaging, supported levels, and availability can change. Confirm current requirements and entitlements with IBM and the organization’s platform owners before selecting or procuring a platform.
Plan a low-risk first integration
A narrow, well-bounded integration is easier to govern than a broad attempt to expose an entire application. Use this sequence to make the architectural and operational decisions explicit:
- Define the business interaction. Identify the specific capability a consumer needs, the system that initiates the request, and the data that must cross the boundary.
- Select provider or requester. Use a provider when an external client calls z/OS; use a requester when a COBOL or PL/I application calls an external REST service.
- Set the contract and mapping. Decide whether API-first or meet-in-the-middle fits the existing application, and document how REST data maps to native structures.
- Assign control owners. Establish authorization, request tracking, monitoring, change approval, and production support responsibilities.
- Validate in stages. Build and promote through the appropriate non-production environments, testing functional behavior and operational controls before production.
- Prepare recovery. Define how to disable or roll back the interface and how to handle in-flight or failed work, based on the workload’s actual behavior.
There is no universal modernization blueprint: the appropriate design depends on the z/OS release, middleware versions, topology, workload, data sensitivity, and migration constraints. Involve platform, application, security, and operations owners before committing to an implementation.
Quick Recap
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
