Chapter 36 Exercises: DevOps for the Mainframe

Section 36.1 — Why DevOps for Mainframe

Exercise 36.1: Current State Assessment

Assess a traditional mainframe development process (real or hypothetical) against the five DevOps capabilities: source control, automated build, automated testing, deployment automation, and monitoring feedback. For each capability, rate the current state as: None, Manual, Semi-Automated, or Fully Automated. Identify the capability with the largest gap between current and desired state.

Exercise 36.2: Cultural Resistance Analysis

Interview three mainframe developers (or role-play three personas: a 25-year veteran, a 10-year mid-career developer, and a 2-year new hire) about their concerns with adopting DevOps practices. For each concern, classify it as: Technical (tool limitation), Cultural (process preference), or Political (organizational power dynamics). Propose a response strategy for each.

Exercise 36.3: Business Case for Mainframe DevOps

Write a one-page business case for implementing DevOps for a mainframe shop with 300 COBOL programs, 15 developers, and quarterly releases. Include: current cost of change delivery, projected cost after DevOps, risk reduction quantification, and a 12-month implementation timeline with milestones.

Exercise 36.4: Traditional vs. DevOps Comparison

Create a detailed comparison table for a single code change flowing through the traditional mainframe process versus a DevOps pipeline. Track: elapsed time, hands involved, manual steps, automated steps, audit artifacts produced, and risk exposure at each stage.

Section 36.2 — Git for z/OS

Exercise 36.5: Repository Design

Design a Git repository structure for a system with: 150 COBOL programs, 45 copybooks, 30 BMS maps, 20 JCL procedures, 10 DB2 DDL scripts, and 5 CICS CSD definitions. Justify your directory structure. Would you use a monorepo or multiple repositories? Why?

Exercise 36.6: .gitattributes Configuration

Write a complete .gitattributes file for a COBOL z/OS project that handles: COBOL source (EBCDIC), copybooks (EBCDIC), JCL (EBCDIC), BMS maps (EBCDIC), test data (binary), load modules (binary), and documentation (UTF-8). Explain each entry.

Exercise 36.7: Branching Strategy Selection

Compare three branching strategies for mainframe development: Git Flow, GitHub Flow (trunk-based with feature branches), and a release-train model. For each strategy, evaluate: suitability for regulated environments (audit trail), support for emergency fixes (hotfixes), complexity for the team, and integration with quarterly vs. monthly vs. weekly release cadences. Recommend one and justify.

Exercise 36.8: SCLM Migration Plan

Create a migration plan for moving 500 COBOL programs from SCLM to Git. Address: how to establish the baseline (initial export), how to handle programs currently in development (in-flight changes), how to manage the parallel operation period, and how to determine the cutover date. Include a risk register with at least five migration risks and mitigation strategies.

Exercise 36.9: Merge Conflict in COBOL

Two developers modify the same copybook simultaneously. Developer A adds a new field after the account balance field. Developer B changes the PIC clause of the account balance field. When they both push to the develop branch, a merge conflict occurs. Write out the conflict markers Git would produce and describe the correct resolution process. What could go wrong if the merge is resolved incorrectly?

Exercise 36.10: Zowe CLI Scripting

Write a Zowe CLI script that performs the following sequence: 1. Uploads a COBOL source member from a local file to a z/OS PDS 2. Submits a compile JCL job 3. Waits for the job to complete 4. Checks the return code 5. Downloads the compiler listing if the return code is non-zero 6. Exits with success or failure based on the compile result

Include error handling for: Zowe connection failure, dataset allocation failure, and job submission failure.

Exercise 36.11: Git Hooks for COBOL

Design three Git hooks for a COBOL project: 1. A pre-commit hook that checks COBOL source for column 72+ content (sequence numbers that shouldn't be in Git) 2. A pre-push hook that runs a local compilation check before allowing push 3. A commit-msg hook that enforces a commit message format including the change ticket number

Write the hooks as bash scripts.

Section 36.3 — CI/CD Pipelines

Exercise 36.12: Jenkinsfile Development

Write a complete Jenkinsfile for a COBOL project with these stages: Checkout, Static Analysis (scan for common COBOL issues), Build (compile and link), Unit Test, Integration Test, Code Coverage Report, Deploy to Dev, Deploy to QA (with approval gate), Deploy to Production (with approval gate). Include post-build actions for notification and artifact archiving.

Exercise 36.13: IBM DBB Configuration

Given a COBOL application with the following dependency chain:

MAINPGM.cbl  --> COPY ACCTMSTR.cpy
              --> COPY TXNREC.cpy
              --> CALL 'SUBPGM1'
              --> CALL 'SUBPGM2'
SUBPGM1.cbl  --> COPY ACCTMSTR.cpy
SUBPGM2.cbl  --> COPY TXNREC.cpy
              --> COPY ERRMSG.cpy

If you modify TXNREC.cpy, which programs does DBB need to recompile? If you modify SUBPGM1.cbl (without changing its interface), which programs need recompilation? Explain the difference between source dependency and interface dependency.

Exercise 36.14: Pipeline Failure Analysis

A CI/CD pipeline for a COBOL project fails at the Integration Test stage. The unit tests all passed. Identify five possible causes for this pattern (unit tests pass, integration tests fail). For each cause, describe the diagnostic steps and the fix.

Exercise 36.15: Multi-Platform Pipeline

Design a CI/CD pipeline for a system where: the COBOL batch programs run on z/OS, the web front-end runs on Linux (Java), and the mobile app is built for iOS and Android. The COBOL programs expose APIs (from Chapter 33) consumed by the web and mobile apps. How do you structure the pipeline to: build all three platforms, test the integrations between them, and deploy them in the correct order?

Exercise 36.16: Pipeline Security

Identify five security concerns with a CI/CD pipeline that deploys to z/OS production. For each concern, describe the risk, a mitigation strategy, and how to audit compliance. Consider: credential management, pipeline tampering, artifact integrity, access control, and supply chain security.

Section 36.4 — Automated Testing on z/OS

Exercise 36.17: Unit Test Design

Write five unit test cases for the following COBOL paragraph. Specify setup data, the PERFORM call, and the expected results for each test:

       3000-CALC-OVERDRAFT-FEE.
           IF WS-AVAIL-BAL < ZERO
               IF WS-ACCT-IS-PREMIUM
                   MOVE 15.00 TO WS-FEE-AMOUNT
               ELSE
                   MOVE 35.00 TO WS-FEE-AMOUNT
               END-IF
               IF WS-FEES-TODAY >= 3
                   MOVE ZERO TO WS-FEE-AMOUNT
                   MOVE 'Y' TO WS-FEE-WAIVED-FLAG
               END-IF
               ADD WS-FEE-AMOUNT TO WS-TOTAL-FEES
           ELSE
               MOVE ZERO TO WS-FEE-AMOUNT
           END-IF.

Exercise 36.18: Test Data Management

Design a test data management strategy for the HA banking system. Address: how test data is created (synthetic vs. masked production), how it's loaded before tests, how it's cleaned up after tests, how referential integrity is maintained across related tables/files, and how test data is versioned alongside the tests.

Exercise 36.19: Mocking Strategy

Design a mocking strategy for testing a COBOL program that: reads from a VSAM KSDS file, writes to a DB2 table, calls two subprograms (VALIDATE and CALCULATE), and sends a CICS transient data queue message. For each external dependency, describe the mocking approach and the trade-offs between fidelity and test speed.

Exercise 36.20: Integration Test Framework

Design an integration test framework for the HA banking system that tests the complete deposit transaction flow: terminal input -> transaction router -> deposit processing -> balance update -> audit log. Specify: test harness architecture, data setup, execution mechanism, result verification, and cleanup. How do you ensure tests are idempotent (can be run multiple times without side effects)?

Exercise 36.21: Test Coverage Measurement

Propose a method for measuring test coverage of COBOL programs. Address: paragraph coverage (which paragraphs are exercised), branch coverage (which conditional branches are taken), and data coverage (which data value ranges are tested). What tools or techniques would you use? What is a reasonable coverage target for a financial application?

Exercise 36.22: Performance Testing in the Pipeline

Design a performance testing stage for the CI/CD pipeline that detects performance regressions. Specify: which performance metrics to measure (CPU, elapsed time, I/O count), how to establish baselines, what threshold of degradation triggers a failure, and how to handle legitimate performance changes (new features that intentionally use more resources).

Section 36.5 — Deployment Automation

Exercise 36.23: Promotion Script

Write a shell script (using Zowe CLI) that promotes load modules from the QA library to the Production library. The script must: verify that all modules in the package compiled successfully, create a backup of the current production modules, copy the new modules, perform a CICS NEWCOPY for each program, verify the NEWCOPY was successful, and record the promotion in a log dataset. Include rollback logic triggered by any failure.

Exercise 36.24: Blue-Green Deployment Design

Design a blue-green deployment strategy for a CICS application with: 3 AOR regions, 1 DB2 subsystem, and 5 VSAM files. Address: how to maintain two sets of CICS regions, how to handle DB2 schema changes that need to work with both blue and green, how to route traffic between blue and green, and how to handle in-flight transactions during the switch.

Exercise 36.25: Rollback Scenarios

For each of the following deployment scenarios, design a rollback strategy: 1. A COBOL program change that affects only one load module 2. A copybook change that requires recompilation of 12 programs 3. A DB2 ALTER TABLE that adds a new column used by the new code 4. A batch job that has already processed half the input file when the bug is discovered 5. A CICS transaction that has updated DB2 but not yet committed when the new code is found to be defective

Exercise 36.26: Deployment Package Specification

Design a deployment package format for the HA banking system. The package must contain: all load modules, DB2 DDL changes (if any), JCL changes (if any), CICS CSD changes (if any), configuration changes, and rollback instructions. Specify the package format, naming convention, storage location, and retention policy.

Section 36.6 — Monitoring and Observability

Exercise 36.27: DORA Metrics Dashboard

Design a dashboard that displays the four DORA metrics for your mainframe DevOps pipeline: deployment frequency, lead time for changes, change failure rate, and mean time to recovery. Specify the data sources for each metric and how they would be collected from z/OS and Jenkins.

Exercise 36.28: Post-Deployment Monitoring

Define a post-deployment monitoring protocol for the first hour after a production deployment. Specify: which metrics to watch, what thresholds trigger alerts, who is notified, what automated responses are triggered, and how to distinguish between deployment-related issues and normal system variation.

Section 36.7 — Cultural Change

Exercise 36.29: Change Management Plan

Create a 12-month change management plan for introducing DevOps to a mainframe team of 20 developers (average 18 years experience). Include: communication plan, training schedule, pilot selection criteria, expansion strategy, success metrics, and contingency plans for resistance.

Exercise 36.30: DevOps Champions Program

Design a "DevOps Champions" program for a mainframe organization. Specify: how champions are selected, what training they receive, what their role is (technical coaching, cultural advocacy, or both), how their regular work is adjusted to accommodate the champion role, and how their success is measured.

Challenge Exercises

Challenge 36.A: End-to-End Pipeline Implementation

Design a complete, production-ready CI/CD pipeline for the HA banking system. Include: Git repository structure, Jenkinsfile, DBB configuration, unit test framework setup, integration test framework, deployment automation, monitoring integration, and rollback procedures. Document every configuration file and script. This is a capstone exercise that integrates all sections of the chapter.

Challenge 36.B: Disaster Recovery for the Pipeline

The Jenkins server crashes and the z/OS USS file system where Git repositories are stored becomes corrupted. Design a disaster recovery plan for the entire DevOps infrastructure. Address: Git repository backup and recovery, Jenkins configuration backup, pipeline secret management, and the process for rebuilding the pipeline from scratch. How long should recovery take? What is the acceptable data loss window?

Challenge 36.C: Multi-LPAR Pipeline

Design a CI/CD pipeline that deploys to multiple z/OS LPARs (development, QA, staging, production across two data centers for DR). Each LPAR has its own CICS regions and DB2 subsystems. How do you manage configuration differences between LPARs? How do you ensure that the same binary is promoted (not recompiled) across environments?