CICS Modernization

CICS modernization is about keeping your core CICS applications reliable while connecting them to new channels, APIs, and ways of working. Instead of a single "big bang" rewrite, most organizations expose existing transactions as APIs, extend applications with new code, adopt DevOps and CI/CD, and integrate with cloud and microservices. This page explains common strategies, the role of APIs and z/OS Connect, microservices and DevOps, and how to think about hybrid cloud with CICS.

Explain Like I'm Five: What Is Modernization?

Imagine an old but sturdy toy box. Modernization doesn’t mean throwing it away. It means adding a way for new toys (phones, tablets, other apps) to talk to the box—like a little door with a sign that says "put your request here and get an answer." You might also teach the box new tricks (new programs) or change how you deliver updates (automated builds and tests). The box is still there; it just works better with the rest of the world. CICS modernization is the same: the mainframe and CICS stay; we add APIs, new code where it helps, and better build/deploy so everything fits together.

Why Modernize CICS?

CICS applications often run critical business logic and hold core data. Rewriting them from scratch is expensive and risky. Modernization aims to preserve that value while enabling new user experiences (web, mobile), integration with cloud and partner systems, and faster delivery through automation. Goals typically include: exposing CICS to non-mainframe developers via standard APIs, reducing dependency on green-screen and legacy protocols, improving deployment speed and quality with DevOps, and supporting hybrid architectures where the mainframe and cloud work together.

Common Modernization Strategies

Organizations usually combine several approaches rather than one single method. The table below summarizes the main strategies and how they help.

Exposing via APIs is often the first step: existing CICS programs and transactions are mapped to REST (or other) APIs so that cloud, web, and mobile applications can call them without knowing CICS or 3270. Extending in place means adding new CICS programs, web support, or Java applications alongside the existing COBOL. Rewriting portions is selective: replace the parts that benefit most from a new language or design while keeping the rest. DevOps and CI/CD apply to all of these by automating how code and resources are built, tested, and deployed into CICS.

Exposing CICS as REST APIs

REST APIs allow external systems to invoke CICS transactions and programs using HTTP and JSON (or XML). IBM z/OS Connect is a common solution: you define an API (URL path, HTTP method, request and response shape) and bind it to a CICS program or transaction. The incoming request is transformed into the format the CICS program expects (e.g. COMMAREA or channel/container); the program runs in CICS; and the response is mapped back to the API response. z/OS Connect can run in its own address space or, in newer versions, inside the CICS region, which reduces latency and simplifies deployment. This approach requires little or no change to the existing COBOL program; the "modern" part is the API layer and the tooling that generates and maintains it. Enterprise API gateways and management platforms can sit in front of z/OS Connect for security, rate limiting, and monitoring.

Microservices and CICS

CICS Transaction Server supports microservices-style development. For example, Eclipse MicroProfile provides specifications for building and running Java-based microservices with health checks, metrics, and configuration. You can develop new microservices in Java that run in CICS and call or be called by existing COBOL programs. Alternatively, existing CICS programs can be exposed as services (via z/OS Connect or similar) and consumed by microservices running on the same platform (e.g. Red Hat OpenShift on IBM Z) or elsewhere. The idea is to break down monoliths into smaller, deployable units that communicate over well-defined interfaces (often REST). CICS acts as both a host for new microservices and the backend that existing microservices call.

DevOps and CI/CD for CICS

Modernization is not only about APIs and new code; it is also about how changes are delivered. DevOps emphasizes automation, collaboration, and short feedback loops. For CICS, that means: source code and resource definitions in version control, automated builds that compile programs and produce deployable packages (e.g. CICS bundles or resource definitions), automated tests (unit, integration, and possibly performance), and automated deployment into development, test, and production CICS regions. CI/CD pipelines remove many manual steps and reduce the risk of configuration drift. Tools such as CICS TS resource builders, Gradle, Maven, and pipeline platforms (e.g. Jenkins, GitLab CI) can be used to build and deploy CICS programs, transactions, and related artifacts. The same pipeline can support both COBOL and Java (and other) components.

Hybrid Cloud and CICS

In a hybrid model, the mainframe remains the system of record for data and core business logic. CICS continues to run on IBM Z. New applications and user interfaces (e.g. web, mobile, cloud services) run on or off the platform and communicate with CICS via APIs. Data can stay on Z for security and performance while APIs provide controlled access. Red Hat OpenShift on IBM Z allows containerized workloads to run next to CICS and DB2, reducing latency and keeping sensitive data on the same platform. So "hybrid" means CICS and the mainframe are not replaced; they are extended and connected to cloud and modern runtimes through APIs and integration patterns.

Step-by-Step: Planning an API-First Modernization

1. Identify the CICS transactions or programs that new applications need to call. Document inputs and outputs (COMMAREA or containers).
2. Design REST API(s) that match how consumers will use the service (resources, HTTP methods, request/response format).
3. Use z/OS Connect (or equivalent) to define the API and map it to the CICS program or transaction. Test with sample requests.
4. Integrate the API with your API gateway and security (auth, rate limits). Add monitoring and logging.
5. Document the API for developers and iterate based on feedback. Extend to more transactions as needed.

Step-by-Step: Introducing CI/CD for CICS

1. Put CICS source (COBOL, JCL, resource definitions, etc.) in a version control system (e.g. Git) and establish branches and review process.
2. Create a build pipeline that compiles programs and produces deployable artifacts (e.g. CICS resource definitions, load modules, bundles).
3. Add automated tests (compile, unit, integration) as quality gates in the pipeline.
4. Configure deployment steps to install or update resources in target CICS regions (dev, test, prod) using CICS management interfaces or automation tools.
5. Track deployments and use rollback procedures so you can revert if a release causes issues.

Best Practices

• Start with high-value, well-understood transactions when exposing APIs; avoid the most complex or fragile ones first.
• Keep API contracts stable and version them so consumers are not broken by changes.
• Use DevOps and CI/CD for both legacy and new CICS code so all changes go through the same quality and deployment process.
• Document what is exposed via APIs and how it maps to CICS resources so support and security teams can operate and audit.
• Consider security and compliance early: authentication, authorization, encryption, and data residency when CICS is called from off-platform.

Test Your Knowledge