SCLM Is Going Away. Replacing It Takes More Than Git.

The question now is how to manage the complete application lifecycle, not just source conversion, according to René De Vleeschauwer, founder and CEO of IKAN

For decades, Software Configuration and Library Manager (SCLM) has provided z/OS development teams with more than source control. Embedded in ISPF, it combined version management, build capabilities and change control within the application development lifecycle.

IBM has now stated that z/OS 3.2 is planned to be the last release supporting SCLM. As its strategic direction, IBM recommends IBM Developer for z/OS Enterprise Edition or Git, available through IBM Open Enterprise Foundation for z/OS.

That creates an obvious migration requirement. But organizations should be careful not to frame it simply as: How do we move SCLM source into Git?

The more important question is: How will we manage the complete application lifecycle once SCLM is gone?

Git Is the Beginning, Not the Lifecycle

Git is the logical foundation for modernizing z/OS source management. It provides the version-control model already used across most enterprise development environments and allows mainframe applications to participate in common engineering practices.

But Git manages source. It does not manage the complete application lifecycle.

After moving source from SCLM, organizations still need to know which build corresponds to which commit, which tests ran, which artifacts were produced, who approved a release, what reached each environment and whether a production module can be traced back to its original business change.

That broader chain can be expressed as:

Plan → Change → Source → Build → Test → Approve → Deploy →Operate

That is lifecycle management. And it is the part of an SCLM migration that should receive at least as much attention as source conversion.

CI/CD Becomes the Backbone

IBM provides important components for the new environment.

IBM Dependency Based Build (DBB) provides dependency tracking and build automation for traditional z/OS applications. IBM explicitly describes DBB as framework-independent, capable of working with Git-based SCMs and integrating with CI/CD platforms such as Jenkins and GitLab.

But DBB is a build system. It is not the lifecycle management system.

Similarly, Wazi Deploy provides automated deployment of z/OS applications using Python or Ansible. IBM describes Wazi Deploy as a tool that integrates into a CI/CD pipeline.

Again, that distinction matters. The pipeline is the mechanism that connects the stages.

A source change should trigger a controlled build. That build should create identifiable artifacts. Automated tests and quality controls should determine whether those artifacts can progress. Deployment should promote the same tested artifacts through environments, with approvals and evidence recorded along the way.

The architecture therefore looks less like:

SCLM → Git

and more like:

Git → Build → Test → Artifact → Deploy …

… with CI/CD and lifecycle management spanning the entire flow.

IBM itself describes the integrated pipeline as the backbone of the value stream. The retirement of SCLM makes designing that pipeline an architectural requirement rather than an optional DevOps enhancement.

DBB Is an Option, Not a Requirement

There is another important distinction. Moving to Git does not mean every application must move to DBB.

DBB provides sophisticated capabilities, particularly dependency analysis and incremental builds. For complex and actively developed applications, those capabilities can provide significant value.

But organizations should separate two decisions:

1. Where should source be managed?
2. How should that source be built?

Git can become the system of record while existing z/OS build mechanisms continue doing their job. For many applications, that means standard JCL remains a valid build option.

A CI/CD pipeline can submit JCL to z/OS, monitor execution and return codes, retrieve output and determine whether subsequent stages should proceed. IBM’s z/OSMF Jobs REST interface, for example, provides APIs to submit jobs, obtain status and retrieve spool output.

That means an architecture such as the following is entirely viable:

Git → CI pipeline → JCL build → Test → Deploy

So is this:

Git → CI pipeline → DBB → Test → Wazi Deploy

The measure of modernization should not be whether a build is expressed in JCL, Groovy or YAML. The important questions are whether it is automated, repeatable, version-controlled, observable and traceable.

Existing JCL often contains decades of valuable knowledge about compilers, Db2 preprocessing, CICS translation, link-editing, libraries and application dependencies. Replacing that logic purely for the sake of adopting a newer tool can add migration risk without necessarily improving the lifecycle.

Lifecycle Management Must Connect the Tools

Moving away from an integrated environment such as SCLM also means lifecycle information becomes distributed across several systems:

• The work item may reside in a planning platform.
• Source resides in Git.
• The build executes through DBB or JCL.
• Tests execute elsewhere.
• Artifacts may be retained in a repository.
• Deployment may use Wazi Deploy or an established deployment mechanism.
• Production approval may live in a service-management platform.
• The critical requirement is maintaining the relationships between them.

Ideally, an organization should be able to start with a production artifact and trace backward:

Production artifact → Deployment → Approval → Test → Build → Git commit → Business change

And engineering should be able to traverse the same chain forward. That requires lifecycle management above the individual tools.

Neither Git, DBB nor Wazi Deploy alone provides that complete enterprise lifecycle. They are components within it.

Modernize the Lifecycle, Not Every Tool at Once

This distinction also provides a more pragmatic migration strategy.

Organizations do not need to replace source management, builds, deployment and every developer interface simultaneously.

Git can first become the source of truth. Existing JCL builds can then be invoked through CI/CD. Testing and quality gates can be automated. Existing deployment processes can initially remain in place.

Applications can subsequently move to DBB where dependency-aware builds provide sufficient value, and Wazi Deploy can be introduced where standardized deployment automation improves the process.

The lifecycle architecture remains consistent while individual technologies evolve. This is particularly important for enterprises with hundreds or thousands of z/OS applications. Modernization does not have to mean simultaneous replacement.

SCLM Retirement Is an Architecture Decision

The planned removal of SCLM is therefore more than a product lifecycle event. It is an opportunity to establish a clearer separation of responsibilities:

• Git manages source.
• DBB, zBuilder or JCL builds it.
• Wazi Deploy or established automation (JCL) deploys it.
• CI/CD orchestrates the delivery flow.
• Lifecycle management connects the business change, source, build, test, approval and production evidence.

For some applications, the answer will be Git, DBB and Wazi Deploy. For others, standard JCL may remain the most sensible build mechanism. Both can be modern.

The defining characteristic is whether the resulting delivery process is automated, governed, repeatable and traceable from business change through production.

The strategic question for organizations should therefore not be: Which product replaces SCLM?

It should be: What lifecycle should every z/OS application follow after SCLM?

SCLM may be going away. Lifecycle management cannot.

Editor’s note: AI was used to assist with drafting, editing and refining portions of this work.

---