Understanding how GitHub fits in a mainframe DevOps toolchain.

If you work on a mainframe, you’ve almost certainly heard of CA Endeavor, Serena Changeman, IBM SCLM, or Panvalet Librarian. All of which are legacy source code management systems that have been used for decades.

Those SCM’s simply cannot compete with the features of modern SCM’s as we detailed previously.

Perhaps your distributed development teams use Git in some form or fashion. There are a few options here:

• Git server (just the plain old open source running on Linux).
• GitLab
• BitBucket
• GitHub

We’ve personally been working with GitHub on a number of demo’s, and the following diagram demonstrates how GitHub would fit your toolchain. This is a minimal toolchain that can can be expanded as desired, adding tools such as ElasticSearch for distributed logging, SonarQube for automated code quality, IBM Test Data Manager for generation of masked test data from production data, and the list continues from there.

Here, the GitHub serves as a central hub (pardon the pun) of the toolchain as it acts like the glue between nearly all the components. What is not shown is much of the collaboration features of the tool that can control code reviews, pull request approvals, developer discussion threads as well as the ability to branch and merge from the master thus allowing developers to do parallel development.

IBM Dependency Based Build is required to handle the compilation and generation of deployable artifacts (load modules, listings, debug files, etc). It has the intelligence to only compile what is needed based on the source members that have been edited. There is no need to recompile an entire branch (which could potentially have hundreds of thousands of source members). In the image above, DBB will pull source from the GitHub development branch for compilation.

Jenkins in this case handles the pipeline and controls when DBB is run, and also calls IBM Urbancode Deploy to handle the deployment steps which can include such activities as the following:

• Copying out of dataset members to target z/OS LPARS
• Processing DB2 BINDS on packages and plans
• Performing CICS NEWCOPY steps on CICS load modules
• Performing ACB gens on IMS PSB files
• Integrating with a change control system such as ServiceNow to automate change request tickets.
• Completing a merge request in GitHub to move development code into a production branch upon successful deployment.
• The list could go on for pages and pages here ….

Also in this image, is IBM Developer for System z, an integrated development environment (IDE) for editing, analyzing, refactoring, and debugging code on z/OS such as COBOL, PL/I, Assembler, and C/C++. This is an Eclipse based tool that includes a Git client plugin, allowing the developer to pull source from the GitHub development stream, create pull requests, and merge pull requests from other developers.

These products have parts that must be installed on either a Linux/Windows environment, or on the z/OS LPAR.

IDz has both a desktop client as well as z/OS host FMIDs. That is the only part of the toolchain that is installed on the desktop. All others are installed on z/OS as started tasks, or on a Linux server.

Hopefully this article has explained what a basic toolchain would look like for a company implementing DevOps principles. If you have questions feel free to reach out to us and ask.