Welcome to our next session. In our previous lesson, you gained hands-on familiarity with the Linux command line, learning to navigate the file system and manage files. Those skills are the essential building blocks for what comes next, as we now turn our attention from the file system itself to how we manage the code that lives within it.
This lesson addresses a cornerstone of your modernization journey: understanding the shift in how source code is managed. Your 11 years of experience have given you deep familiarity with mainframe library management systems like Endevor. Today, we will compare that established, centralized model with the dominant approach in modern software development: distributed version control using Git. Our goal is to understand not just the different commands, but the fundamental change in development philosophy they represent.
The Mainframe Paradigm: Centralized Control
In your daily work on the mainframe, you've used tools like CA Endevor, CA Librarian, or similar Source Code Management (SCM) systems. These are powerful tools designed for stability and control, and they operate on a centralized model.
In a Centralized Version Control System (CVCS), there is a single, authoritative server that stores all versions of your project's code. Your workflow is likely familiar:
- You "check out" a program (a member in a PDS) from the central server to your workspace.
- Often, this action "locks" the member, preventing other developers from making conflicting changes simultaneously.
- After making your changes, you "check in" the new version.
- The code then moves through a strictly defined lifecycle, often managed by "promotions" from one environment to the next (e.g., from a DEV library to a QA library, and finally to PROD).
This model provides excellent administrative control and is perfectly suited to a stable, structured development process. The focus is on managing the promotion of individual components through a sequential, gated path.
The Distributed Paradigm: Git
Git represents a fundamentally different approach. It is a Distributed Version Control System (DVCS). To understand what this means and why it's so central to modern DevOps, let's start with a short, high-level overview created specifically for developers transitioning from the mainframe.
[PDF] Git 101 for Mainframers - GS-UK Conference
This document from a GSE UK conference is designed for an audience with your background. It explains the "what" and "how" of Git at a conceptual level.
Please read the introduction and the first two main sections: What is Git? How does Git work? Focus on the core idea that every developer's machine holds a full copy of the repository, and they synchronize with each other using "push" and "pull" operations.
The most critical takeaway from that reading is this: with Git, you don't just check out a single file; you clone the entire repository, including its full history. This local copy is a first-class, fully functional repository. This single architectural difference enables several key advantages that fuel modern development practices.
DevOps and Mainframe Modernization
This video from IBM Technology directly contrasts the mainframe "library manager" world with a modern Git-based pipeline. It clearly articulates the "why" behind this shift.
Watch the segment from the beginning, where the speaker compares the two models. Pay close attention to the additional capabilities a Git-based pipeline enables, such as automated code scanning, quality checks, and integrated testing.
As the video highlights, the benefits go far beyond just storing code. Git's design is the engine for the automation and collaboration that define DevOps.
Workflow and Conceptual Differences
Let's break down the practical differences. The way you interact with code in Git involves a few more steps than a simple check-out/check-in, but these steps provide much greater flexibility. A great way to visualize this is by thinking of your code living in four distinct areas.
How Git Works: Explained in 4 Minutes
This short, animated video from ByteByteGo provides an excellent visual model of the Git workflow.
Please watch from the beginning. The video explains the four locations for your code: the Working Directory, Staging Area, Local Repository, and Remote Repository. It maps the core commands (add, commit, push, pull) to the movement of code between these areas.
To summarize and map this to your experience:
- Working Directory: This is the live directory on your computer where you edit your COBOL source, JCL, or other files. It's conceptually similar to the temporary dataset where you edit a member on the mainframe.
- Staging Area: This is a new concept. It acts as a "drafting table" or a shopping cart where you place the specific changes you want to include in your next saved version. This allows you to craft precise, logical commits instead of just saving everything you've changed.
- Local Repository: When you commit, you save the snapshot from your Staging Area into your personal, local copy of the repository. This is like checking in, but it happens entirely on your machine, without touching a central server. You can do this many times while offline.
- Remote Repository: This is the shared server (like GitHub or Bitbucket) that your team uses to collaborate. When you push, you send your local commits to the remote. When you pull, you fetch and merge changes from the remote that your teammates have pushed.
Parallel Development with Branching
Perhaps the most powerful feature of Git is its lightweight and fast branching capability. In the Endevor model, development is often linear. A fix or feature moves along a set path.
In Git, developers can instantly create an isolated "branch" to work on a new feature or bugfix without disturbing the main line of code. They can commit their work to this branch. Once the work is complete and tested, the branch is merged back into the main codebase. This allows many developers to work in parallel on different tasks simultaneously.
The diagram below shows a modern development workflow using branches for features, bugfixes, and hotfixes, which all eventually merge into a main branch that proceeds through a deployment pipeline.
A Side-by-Side Comparison
Let's consolidate these differences into a clear table.
| Feature | Mainframe SCM (e.g., Endevor) | Git (Distributed VCS) |
|---|---|---|
| Architecture | Centralized: A single server holds the master copy of the code. | Distributed: Every developer has a full, independent copy (clone) of the repository. |
| Basic Unit | Member within a library (e.g., a PDS). | File within a directory structure. |
| Workflow | Check-out -> Modify -> Check-in -> Promote. | pull -> (Create Branch) -> Modify -> add -> commit -> push -> (Merge). |
| Concurrency | Often uses file locking to prevent simultaneous edits. | Parallel development in isolated branches, with powerful merging capabilities. |
| Offline Work | Requires a connection to the mainframe server for most operations. | Can commit, create branches, and view full history while offline. Network is only needed to push or pull. |
| History | Typically a linear history of changes for each individual member. | A complete, non-linear (branched) history of the entire project is stored in every clone. |
| Integration | Tightly coupled with mainframe-specific build and deployment tools. | Designed to integrate with a vast ecosystem of modern CI/CD tools (e.g., Jenkins, GitHub Actions). |
Bridging the Two Worlds
The transition from Endevor to Git doesn't have to be an abrupt switch. Modernization strategies often involve a "bridge" where both systems coexist, allowing teams to adapt gradually. For example, changes made in a Git repository can be automatically synchronized back to Endevor.
The diagram below illustrates this concept, showing an "Endevor Bridge for Git" connecting a modern Git repository with a traditional Endevor environment.
This approach allows developers to use modern IDEs and Git workflows while still leveraging the existing, proven build and lifecycle automation on the mainframe.
Conclusion
In this lesson, we contrasted the centralized, promotion-based model of mainframe SCMs like Endevor with the distributed, branch-based model of Git. You've seen that this is more than just a new tool—it's a paradigm shift that enables the parallel development, automation, and collaboration central to modern DevOps.
Key Takeaways:
- Mainframe SCMs are centralized, focusing on control and linear promotions.
- Git is distributed, giving every developer a full local repository, enabling offline work and greater autonomy.
- The core Git workflow involves moving changes between your Working Directory, Staging Area, Local Repository, and a Remote Repository.
- Branching and merging are Git's key features, allowing for powerful parallel development workflows that are difficult to achieve in a centralized model.
- Git's architecture is the foundation for modern CI/CD automation, enabling integrated quality checks, testing, and deployments.
You now have the conceptual framework to understand Git. In our next lesson, we will put this knowledge into practice by performing your first Git operation: cloning a remote repository to your local machine.