Building COBOL in a pipeline
A pipeline build does exactly what your compile JCL does — precompile, compile, link-edit — but it is started by a commit, runs on a build server that talks to z/OS, and knows which programs actually need rebuilding.
The stages of a mainframe pipeline
The pipeline itself runs on a general-purpose tool such as Jenkins, GitLab CI, GitHub Actions or Azure DevOps. Those tools do not run COBOL. They reach z/OS through an agent or through command-line tools, and z/OS does the real compile.
How the pipeline talks to z/OS
- Zowe CLI — an open-source command-line tool that uploads files, submits jobs and reads output through z/OS REST services. It turns mainframe tasks into commands any pipeline can run.
- Dependency Based Build (DBB) — IBM's build framework for z/OS. It scans source to learn which programs use which copybooks, so when
PAYREC.cpychanges it rebuilds every program that includes it, and nothing else. - Your existing compile JCL — still useful. Many teams start by having the pipeline submit the JCL they already trust.
# 1. upload the changed source to a build library $ zowe zos-files upload file-to-data-set cobol/PAYCALC.cbl "BUILD.COBOL(PAYCALC)" # 2. submit the compile-and-link job and wait for it to finish $ zowe zos-jobs submit data-set "BUILD.JCL(COMPILE)" --wait-for-output # 3. the pipeline fails the build if the job's return code is above 4
Return codes become pass or fail
A pipeline needs a yes or no. The usual rule: a compile return code of 0 or 4 passes (4 means warnings only); 8 or higher fails the build and stops the pipeline before anything is deployed. Listings and messages are attached to the build so the developer can see why.
The build artifact
A successful build produces a package: the load modules, any DBRMs for DB2 programs, and a manifest listing versions. That package is stored in an artifact repository and is what every later stage deploys — the code is never recompiled between test and production.
Common mistakes
If production gets a fresh compile, it is not the code you tested. Build once, store the artifact, and promote that same artifact.
Changing a copybook without rebuilding the programs that use it leaves load modules with mismatched record layouts. Dependency-based builds exist to prevent this.
Warnings are normal for many programs. Agree a threshold per step instead of failing everything that is not zero.
What you will see at work
- Expect to read build logs in the pipeline tool rather than in SDSF, though SDSF is still where you go when something odd happens on z/OS.
- Pipeline service accounts need RACF access to build libraries. Access errors on the first run are normal; raise them with the security team.
- Many sites keep the compiler options in shared configuration so every build uses the same settings.
Key terms
Check your understanding.
Take this lesson's quiz and save your progress. Free.