7 Reasons why your Mainframe needs a modern source code management system
Break down the silos
Mainframe development does not and should not be that much different from distributed development. There is a strong desire to modernize the development and operations of mainframe systems (zDevOps), to increase business agility, improve customer satisfaction, accelerate business value delivery, and to improve developer job satisfaction. One of the areas to start is by evaluating your current source code management system (SCM) for your mainframe and see if it fits with modern DevOps techniques. Here are 7 reasons why you may want to consider changing from a legacy system to a modern SCM like Git or Team Concert:
1: Cross Language And Platform Support
Who has a mainframe that does not integrate with any other system? By that I mean no other distributed program code (Java, Python, .NET) calls any API, or touches a database on your mainframe? If so, you can skip the rest of this article. If you do, then you know that you cannot just update a DB2 database schema without notifying other teams about such changes. Mainframe systems are often considered Systems of Record. The applications that interface to them (web pages, web service calls, etc.) are often called Systems of Engagement. They need cross-team coordination.
Also, the modern z/OS can run multiple languages beyond just COBOL, Assembler, and PL/I. Java is increasingly becoming a popular workload for z/OS. So is python (when run under Unix System Services). As such, a typical Java developer should really only need one SCM to deal with rather than having to learn obscure ISPF panels that have very little coordination with the use cases or workflow of a tool such as Git. Why should such a developer have to use two tools for one language (i.e. Java) just because the target is z/OS?
2: Branching Support For Parrallel Development
Modern DevOps practices require teams to work in parrallel on the same code base to support features that need to be delivered on different dates. Code that gets deployed in an earlier release must be merged into the branch/stream for the later release upon deployment. Modern SCM’s typically use a change set model to deliver only the changed lines and columns rather than replace the entire member. They typically use a common comparison editor to visualize the difference between the source before and after the change is received. Branching also allows a team to spin off and work independently of the main team for experimental development (skunkworks), while being able to merge back into the main stream/trunk.
3: Common Processes Across Teams
Its common for developers to migrate between teams. Your mainframe should not be a silo. While a systems of record may have a different release cadence, developers should be able to adapt quickly when moving from a mainframe team to a distributed team and vice versa. Common processes include requirements management methods, code reviews, project management, and test methods. The mainframe should not appear to be an esoteric silo unto itself. Such ivory towers prohibit new developers from moving in, and as such keep the cost of operations high, with a higher risk of team dissatisfaction.
4: Open Integrations With Other Products
Integrating legacy SCM’s with tools such as SonarQube for code analysis, or JFrog Artifactory for binary versioning is a cost-prohibitive and difficult undertaking. It requires writing custom exits, which are difficult to test in themselves. Git or tools like IBM Rational Team Concert readily integrate with these and other third party tools through the use of common API’s. Legacy SCM’s make it extraordinarily difficult to integrate with a CICD toolchain, and as such, keeps your mainframe code in its own esoteric silo. It does NOT need to be that way.
5: Standard Capabilities That Any New Developer Can Understand
A common concern of most mainframe shops is the pending departure of experienced developers. These developers have many years of expertise in legacy SCM tools that are often taken for granted. Any developer who has come out of college or University in the past 10 years knows how to use either Subversion, CVS, or Git. Any self taught programmer knows these as well. Thus its much easier for them to adapt to a Git based SCM that has been customized for z/OS that it is to learn a 3270 interface to a legacy SCM. If most of your COBOL development workforce is within a window of 15 years of retirement, you should be highly concerned about who will maintain your systems when they leave.
6: Continuous Testing
A common DevOps practice is continuous testing. By that we mean using automation as much as possible to automate testing of various components and various testing types (unit, integration, UAT, performance, and security). While this can and should tie in with CICD below, it can be done upon deployment to a particular environment. This requires that the test can identify and flag issues in the specific source, and that we can compare the source between deployments. That is not easy with a legacy SCM.
7: Continuous Integration / Continuous Deployment
If your COBOL applications are called by Web Services, or they need to have a coordinated deployment with dependent distributed applications, it becomes quite the challenge to do that in two unrelated, disparate systems. You should be able to deploy your business level applications as a whole, and on demand (and frequently). When we speak of Business Level Applications, we mean applications from the perspective of the end user. For example, if you are a financial services company, and you are making changes to an existing product which affects what the end user sees, then all parts of that “system” (the COBOL load modules, the CICS load modules, JCL, DB2 schemas, the Android application, the iPhone application, the Java web services), all should be rolled out together to ensure a consisent end user experience. Deployments should be able to be done on demand, and should be automated. If you have to run through a spreadsheet of steps to deploy your code, it is NOT continuous in any sense. A modern SCM supports being loaded and used by multiple clients, and being deployed to multiple environments concurrently. Also, ALL the code required to do this should be in the SCM repository. This includes JCL, REXX, ANT scripts, batch files, or shell scripts. Legacy SCMs do not support the latter languages, thus making it difficult to support CI/CD.
