What Makes ISPF So Scary? Five Reasons to Banish the ‘Green Screen’
It’s dark, it’s mysterious and it’s scaring away the next-gen developers your company needs to hire. Your ISPF “green screen” is like a zombie limping around amongst the living, and watching large-enterprise mainframe teams struggle to be agile with it is like watching a horror movie. It’s time to see ISPF for what it really is—a mutation of ‘80s waterfall development whose continued existence in the digital age is inhibiting mainframe agility, DevOps and innovation.
Here are five reasons to banish ISPF from your mainframe shop.
1. It’s esoteric.
When a developer, or even a non-developer, looks at a graphical user interface, they can quickly determine how to get around and start working. Navigation is easy with clickable icons, dropdowns and menus, all of which are accessible with your mouse. A keyboard is the only means of navigating ISPF. Without icons, dropdowns or menus, you need to know which command line options to type to get anywhere, and you’ll have to spend quite a bit of time reading a manual written 30 years ago to learn them.
2. You have to memorize obscure command lines.
There’s always the manual to look to, but, hey, why not just Google “ISPF command lines”? There’s a high chance your results will include “ISPF commands cheat sheet”—you’ll need one if you have little or no mainframe experience and you’re in your first job as a COBOL developer. The only people who know these commands by heart are those who have been typing them into the same screen for 35 years.
3. You can’t visualize programs.
Most COBOL programs were written decades ago, and many haven’t been updated in years. These tend to be large, complex programs only a few people understand, if they’re still working on them or working at all. While Eclipsegives you the opportunity to see a graphical representation of your code, making these programs more easily understood, ISPF doesn’t come close. At most, you get a green and black, maybe red and yellow, screen, which makes it even harder to analyze and understand lines upon lines of data as you scroll up and down with your “PF8” and “PF7” keys.
4. You can’t be agile and multitask.
When you’re developing with Agile, you need to be nimble enough to do things simultaneously, like test code as you build or work parallel with another developer in the same program. Agility is difficult, sometimes impossible, with ISPF, largely because you can’t multitask. You’re limited to one 48×80 view—unless you expand to 80×160—so doing more than one thing requires opening another 3270 connection or knowing esoteric commands to split the screen and toggle back and forth.
5. Your next-gen workforce won’t use it.
ISPF is the quickest way to turn off next-gen developers to the mainframe. True, some millennials have a thing for the ‘80s, but expecting them to spend 40 or more hours a week reenacting historical coding techniques on something that looks like it’s out of Tron is too much. Millennials have grown up using graphical technology that requires simple logic to use, not linear tools that require years of practice and studying to master esoteric tasks.
While ISPF may have helped lift mainframe shops out of the punched-card era, it’s only going to scare away developers who are new to the mainframe today. Fortunately, mainframe shops don’t need ISPF; they have at their disposal modern, Eclipse-based tools that leverage Agile/DevOps best practices to enable the quick understanding of outdated, complex, poorly documented mainframe programs. These don’t require comprehensive training or arduous memorization, and they aren’t scary to use—you just start using them.
Why would a mainframe shop want anything less?
Latest posts by Mark Schettenhelm (see all)
- Building a Better Mainframe Release Pipeline - November 7, 2019
- I Don’t Do New Year’s Resolutions—That’s Waterfall - December 31, 2018
- Making Room for Creativity in Mainframe Software Development - December 27, 2018