For decades, mainframe software development meant one thing: ISPF. The green-screen editor was the workspace, the workflow, and the culture all rolled into one. If you wrote COBOL, Assembler, or JCL, you lived in ISPF. That’s just how it was done.
But over the last two decades, a cultural shift happened without much fanfare as mainframe software developers and the associated tooling began to evolve. More modern IDEs and associated tooling began to look remarkably similar to what distributed teams have been using for years. The mainframe isn’t going away: It’s just getting better tools.
The numbers tell a real story. At major mainframe software vendors, an estimated 60 to 70 percent of developers have already moved away from ISPF as their primary coding environment. They’re working in VS Code, SlickEdit, and other modern editors, writing the same Assembler and COBOL they always have, but doing it in environments that support code linting, extensions, multi-file search, and integration with version control.
Build processes have migrated to USS (Unix System Services), and Python is gaining serious traction on z/OS for scripting and automation. The old workflow of writing code in ISPF and submitting batch JCL jobs to compile is giving way to something more fluid and more familiar to those who have worked on distributed systems.
For shops building VS Code extensions that interface with mainframe products, the appeal is clear: if your team already uses VS Code for other development work, the mainframe becomes just another extension in the sidebar. That lowers the barrier to entry enormously, and it makes the idea of a “mainframe developer” feel a lot less alien to someone with a JavaScript or Python background.
If there’s one piece of modern tooling that mainframe developers describe with genuine enthusiasm, it’s Git. Running Git directly on z/OS, with workspaces stored in z/FS files, has fundamentally changed how teams collaborate on mainframe code.
The old model was painful in ways that younger developers might struggle to imagine. Clunky ISPF-based source code management tools requiring rigid macros to cleanly execute before the next step could be manually executed was not for the faint of heart. Coordinating changes across multiple developers on the same codebase meant manual merge processes, careful scheduling, and a lot of hands-on monitoring. Version control often meant naming conventions or, at best, rudimentary library management tools.
Watch Git merge three developers’ branches into one clean result, and the reaction from longtime mainframe professionals is visceral. Experienced developers who have spent decades managing code changes by hand describe it as almost magical. That kind of reaction speaks to just how constrained the previous tooling was and how much productivity was left on the table.
Beyond merging, Git brings the entire distributed development workflow along with it: branching strategies, pull requests, code reviews, and a complete history of every change. These aren’t luxuries. For teams maintaining millions of lines of COBOL or Assembler that run critical banking and insurance systems, they’re necessities.
The tooling story matters beyond just productivity gains for current developers. It’s also about talent. Mainframe shops have struggled for years to attract younger developers, partly because the development experience felt so disconnected from everything taught in contemporary computer science programs.
When a new graduate can open VS Code, connect to a z/OS backend, use Git for version control, and run builds through a CI/CD pipeline, the mainframe stops looking like a museum piece. It starts looking like another platform. Some organizations have already made this leap, implementing the same CI/CD pipelines and deployment tools (like Git and UrbanCode Deploy) that their distributed teams use, specifically to end the “mainframe is different” conversation.
This matters because the people entering the mainframe workforce today often arrive by accident. They apply for a full-stack role and get redirected. They take a consulting gig that pivots. They stumble into COBOL in a high school class and never look back. The more the day-to-day experience resembles modern software development, the more likely those accidental arrivals are to stay and build careers on the platform.
The mainframe isn’t being modernized through large sweeping and transformative events. It has evolved much in the same way distributed networks have; through the demand and contributions of the developers who use it every day, choosing a better editor, a smarter version control system, and a build process that doesn’t require manual processes and hands-on monitoring. That quiet transformation may be the most sustainable kind.