Hi, I’m Athar Ramzan. I recently completed my mentorship in the Linux Foundation’s LFX program, working on the Open Mainframe Project’s COBOL Programming Course with my mentors Sudharsana Srinivasan (IBM) and Michael Bauer (Broadcom).
The goal of my mentorship was to improve the COBOL Programming Course by creating new hands-on labs and debugging exercises that make mainframe programming more accessible and engaging for future learners.
In my midpoint blog, I wrote about learning the course as a student, improving lab clarity, and planning new debugging and ABEND (abnormal end) labs. This final post shows what I actually built in the second half of the mentorship, why those changes matter, and what I learned from the process.
What I Worked On
At the midpoint, I set a clear goal: add hands-on labs that teach real COBOL runtime errors and practical debugging skills. I wanted learners to be able to:
- Read and interpret error output
- Reproduce bugs in a safe way
- Fix code themselves using a step-by-step approach
During the second half of the mentorship, I put that plan into action – creating new labs, improving existing exercises, and ensuring each lab followed a simple, practical learning path.
What I Built
I added six contributions focusing on real, common issues COBOL developers encounter. Each lab is designed for students to learn by doing – running code, reading system output, diagnosing the problem, and fixing it.
Lab Contributions
1. S0CB-Division by Zero (PR #335)
What it does: Provides a COBOL program and JCL that intentionally causes a divide-by-zero ABEND.
Learner experience: Run the job, read the CEEDUMP/S0CB output, identify the uninitialized divisor, and correct the code.
How it helps: Teaches input validation, defensive coding, and how small mistakes (like uninitialized values) can cause major crashes.
2. S0C7-Data Exception (PR #337)
What it does: Reproduces an S0C7 error by performing arithmetic on invalid numeric data.
Learner experience: Examine error messages and data layout, identify the faulty field, and correct the data handling.
How it helps: Builds skills in data validation, understanding field types, and reading system error clues—crucial for production debugging.
3. Case-Sensitive String Comparison (PR #334)
What it does: Shows how COBOL handles string literal comparisons, where case sensitivity matters.
Learner experience: Fail once, diagnose why “Alice” ≠ “alice”, then update the code or logic to handle the case correctly.
How it helps: Reinforces attention to detail and demonstrates how subtle language rules can cause real bugs.
4. Lab 8.6 Enhancement – Count Clients from a Different State (PR #333)
What it does: Adds a challenge where students modify an existing client-count program to filter by another state.
Learner experience: Edit working-storage and conditional logic, run the job, and verify results.
How it helps: Shifts learners from copying and pasting to thinking, reading, and modifying COBOL code in practical ways.
5. S322-Timeout / Infinite Loop Lab (PR #338)
What it does: Simulates an infinite loop scenario that triggers a system timeout (S322).
Learner experience: Observe a job that never finishes (or times out), inspect the loop logic, and implement a proper exit condition.
How it helps: Demonstrates loop control importance and how to spot “hanging” jobs—a frequent issue for beginners.
6. Syntax Error Handling Lab (PR #332)
What it does: Fixes a typo in an ABEND message (IGZ00355 → IGZ0035S) to align with IBM standards.
Learner experience: See correct error codes in documentation and logs.
How it helps: Reduces confusion when searching for error codes online or in manuals.
Why This Matters
COBOL runs critical infrastructure worldwide. New developers need more than just syntax; they need to know what happens when things go wrong.
By introducing intentional failures (ABENDs), these labs help students build resilience and confidence. Instead of fearing a crash, they learn to analyze it, understand the dump, and fix the root cause. This shift from passive coding to active debugging prepares them for real-world mainframe jobs.
What I Learned
- Lab Design is Harder than Coding: Writing a program that works is easy. Writing a broken program that fails instructively requires deep understanding of the system.
- Documentation is Key: A lab is only as good as its instructions. I spent significant time refining the READMEs to ensure clarity for beginners.
- Feedback Loops: Working with mentors gave me rapid feedback on what was confusing or redundant, helping me iterate quickly.
Conclusion
This mentorship has been an incredible journey. I went from learning the basics of JCL and COBOL to contributing educational content that will help thousands of future learners.
I’d like to thank my mentors, Sudharsana and Michael, for their guidance, patience, and encouragement. I’m proud to have contributed to the Open Mainframe Project and look forward to seeing how these labs help the next generation of mainframers.
Explore the course and my contributions here: Open Mainframe Project COBOL Programming Course