CICS Development Lifecycle

Building a CICS application follows a lifecycle: design, development, testing, and deployment. You choose transactions and programs, decide how data flows and how programs are reentrant, write and compile code, test in CICS environments, and deploy into target regions. Many teams also use DevOps and CI/CD to automate build, test, and deploy. This page walks through the main phases and what each one involves.

Explain Like I'm Five: What Is a Development Lifecycle?

A development lifecycle is the set of steps from "we need an application" to "it is running for users." First you plan what the application will do and how it is split into transactions and programs (design). Then you write the code and build it (development). Then you check that it works correctly in a test environment (testing). Finally you install it where real users use it (deployment). For CICS, that means designing CICS transactions and programs, writing COBOL or Java that uses EXEC CICS, testing in a CICS region, and deploying the load modules and resource definitions into the right regions.

Design Phase

In the design phase you decide which CICS transactions will exist, which program each transaction runs first, and how programs call each other (LINK, XCTL, RETURN). You also decide how data is passed (commarea, channels and containers) and what resources the application needs (files, queues, DB2, etc.). Security and authorization (who can run which transaction) are part of design.

An important design choice is whether programs are reentrant, quasi-reentrant, or threadsafe. A reentrant program can be executed by multiple tasks at the same time because it does not modify its own code or rely on task-specific state in the code. A quasi-reentrant program is serially reusable: multiple tasks can use it one after another. Between entry and exit the program may use working storage, but when it returns control to CICS it must leave the program in a state safe for the next task. CICS application programs that use EXEC CICS are typically quasi-reentrant and run under the Quasi-Reentrant (QR) TCB. Threadsafe programs have relaxed rules and can run on QR or open TCBs. The CONCURRENCY attribute (QUASIRET or THREADSAFE) is set in the program resource definition. Design your programs so they do not rely on static or shared state that could leak between tasks; use the commarea or containers for task-specific data.

Design outputs include a list of transactions and programs, resource definitions (programs, files, transactions), and data flow (what is passed between programs and how).

Development Phase

Development is writing the application code and building it. CICS applications are commonly written in COBOL, PL/I, or Java. You use EXEC CICS commands to communicate with CICS (send/receive data, link to other programs, handle files, etc.). CICS provides the EIB (EXEC Interface Block), which your program receives; it contains the transaction id, terminal id, response codes (EIBRESP, EIBRESP2), and other task-related fields. Your program reads these (and optionally sets some) to control flow and error handling.

1
2
3
4
5
6
7
8
9
10
11
12
       *> Typical CICS program entry: use EIB for task context
       EXEC CICS RECEIVE
           INTO(WS-COMMAREA)
           LENGTH(LENGTH OF WS-COMMAREA)
       END-EXEC
 
       IF EIBRESP NOT = DFHRESP(NORMAL)
           EXEC CICS RETURN END-EXEC
       END-IF
 
       *> Business logic using WS-COMMAREA
       EXEC CICS RETURN END-EXEC

Programs are compiled and link-edited (or built as Java artifacts). The compiler option RENT (reentrant) is typically used so that the load module is reentrant or quasi-reentrant as required by CICS. The resulting load module or class is placed in a library that CICS can access (e.g. a STEPLIB or CICS concatenation). Development also includes defining or updating CICS resource definitions (PROGRAM, TRANSACTION, etc.) in your configuration or bundle.

Testing Phase

Testing ensures the application behaves correctly before it is deployed to production. Unit testing exercises individual programs or routines in isolation, often with a test harness or stub CICS. Integration testing runs the full transaction path (e.g. from transaction id through multiple programs) in a test CICS region, possibly with test data and files. You verify correct responses, error handling, and that no abends or resource leaks occur. Performance and stress testing may be done to ensure the application can handle expected load.

In a CI/CD pipeline, tests run as quality gates: the build may run unit tests, then deploy to a test region where integration tests run. Only if tests pass does the pipeline promote to the next environment. Compliance and code review checks are often required before production deployment.

Deployment Phase

Deployment is installing the application into the target CICS region(s). The load module (or Java artifact) must be in a location CICS can access. CICS resource definitions must exist (or be updated) for the program, transaction, and any other resources (files, queues, etc.). Then those resources are installed or refreshed in the region so CICS loads the new code and uses the new definitions. Deployment can be done manually (e.g. via CICS Explorer or ISPF) or automatically via scripts or CI/CD. IBM Developer for z/OS and CICS Explorer support deploying applications and bundles to CICS regions; pipelines can automate the same steps.

DevOps and CI/CD

Many teams use DevOps practices and CI/CD pipelines for CICS applications. Source code is stored in Git. A pipeline builds the code (compile, link), runs tests (unit and optionally integration in a test CICS region), and deploys to target regions if quality gates pass. Packages can contain load modules, resource definitions, and metadata so that the right artifacts are deployed to the right places. This reduces manual steps and helps keep environments consistent. Tooling for z/OS and CICS (e.g. IBM Z DevOps, Jenkins with mainframe plugins) supports these workflows.

Step-by-Step: From Design to First Run

1. Design: List transactions and programs; decide LINK/XCTL flow and commarea/containers; note PROGRAM and TRANSACTION definitions needed.
2. Develop: Write the program(s), use EXEC CICS and EIB; compile with RENT; link-edit and place the load module in a CICS-accessible library.
3. Define resources: Create or update PROGRAM (and TRANSACTION, etc.) definitions pointing to your load module and transaction attributes.
4. Test: Install the program and transaction in a test region; run the transaction and verify behavior and error handling.
5. Deploy: Repeat installation in target regions (or use your pipeline); verify after deployment.

Best Practices

• Design for quasi-reentrancy: avoid static or shared state that could affect another task; use commarea or containers for task data.
• Use the EIB for task context and response codes; check EIBRESP after each EXEC CICS command and handle errors.
• Test in a CICS region that mirrors production (same CICS level, similar resources) before production deploy.
• Automate build and deploy where possible so deployments are repeatable and traceable.

Test Your Knowledge