Page 1 of 1

How are you handling parallel builds in mainframe DevOps pipelines?

Posted: Sun Sep 14, 2025 1:53 pm
by Vibha
Hi All,

In our CI/CD setup (using DBB with Jenkins), we are trying to run multiple COBOL builds in parallel to reduce build time. The issue is — sometimes the builds clash because they are trying to access the same copybooks or load libraries at the same time. We get locking problems or mismatched outputs, and this becomes a bottleneck when many developers commit together.

I am sure some of you must have faced similar issues. How are you handling parallelism in mainframe builds? Do you isolate workspaces fully, or use some shared library with locking mechanism? Please share your approach.

Re: How are you handling parallel builds in mainframe DevOps pipelines?

Posted: Fri Sep 19, 2025 8:26 pm
by Anuj Dhawan
Yes, this is a common pain point when moving to CI/CD with DBB + Jenkins — especially if multiple builds try to touch the same copybooks or loadlibs at once. A few approaches I’ve seen work in practice:
  1. Isolated workspaces per build:
    • Each Jenkins executor uses its own dedicated directory for copybooks, objects, and loadlibs.
    • Nothing is shared during the build, so there’s no clash.
    • At the end, artifacts are published to a common repository (for example, an artifact repo like Nexus/Artifactory or a central loadlib).
  2. Immutable/shared dependencies:
    • Keep copybooks in Git and let each build pull what it needs locally.
    • Treat them as read-only during build — no update-in-place. That way parallel builds can share the source without locking.
  3. Controlled publish step:
    • Even if you build in parallel, only the final promotion/publish to the “official” loadlib happens serially (or via a locking mechanism).
    • Some teams use DBB’s dependency scanner + Jenkins pipeline stages to ensure only changed parts are built, minimizing conflicts.
  4. Sandboxing developers:
    • Give each dev team their own “build/test” loadlib datasets.
    • Only when changes are merged, promote to the integration or SIT libraries.
So in short: parallelism works best if the builds are isolated, but the publish step is coordinated. Just adding my two cents here — others may have found different tricks to balance speed and safety.