How are you handling parallel builds in mainframe DevOps pipelines?

General DevOps for Mainframes Discussion, Vendor Specific Cloud Computing Tools for mainframes, DevOps Certifications, IDz, Topaz, IBM DBB, Jenkins
Vibha
Registered Member
Posts: 52
Joined: Tue Jul 16, 2013 7:35 pm

How are you handling parallel builds in mainframe DevOps pipelines?

Post 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.
User avatar
Anuj Dhawan
Founder
Posts: 2838
Joined: Sun Apr 21, 2013 7:40 pm
Location: Mumbai, India
Contact:

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

Post 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.
Thanks,
Anuj

Disclaimer: My comments on this website are my own and do not represent the opinions or suggestions of any other person or business entity, in any way.
Post Reply Previous topicNext topic

Create an account or sign in to join the discussion

You need to be a member in order to post a reply

Create an account

Not a member? register to join our community
Members can start their own topics & subscribe to topics
It’s free and only takes a minute

Register

Sign in

Return to “DevOps for Mainframes and related news”