On z/OS, many colleagues and customers I work with use traditional tools for system programming and development tasks. This is often the set that they grew up with when they first came to the platform, and although newer products exist I’ve been puzzled by why folks stick with what they’re familiar with, rather than embrace change.
Does this hurt the mainframe? Because the first mainframe was built 55 years ago, does the current mainframe built in 2021 need to be operated with software created in the last millennium? I’d like to change this perception starting with how I in the IBM Z software division get my work done day to day.
In the Z AIOps division where I work, z/OS operations management products like IBM Z NetView and IBM Z System Automation are developed. How do the teams do their day to development for these great z/OS products ?
Choose an IDE
The first and most important decision is to select an Integrated Development Environment (IDE) that developers feel comfortable with. There is no single IDE that everyone enjoys alike. Individual developers have their own preferences and needs and they pick the IDE that addresses those in an optimal way, within the constraints placed on them by working for a company who may have a preferred vendor.
Twenty years ago IBM created the open source Eclipse platform, on top of which IDEs like the IBM z/OS Explorer and IBM Developer for z/OS Enterprise Edition (IDzEE) evolved. IBM z/OS Explorer is free and allows you to work with data sets, unix files and jobs from within Eclipse. Think of it as ISPF 3.2, 3.17 and SDSF in a graphical user interface (GUI). IDzEE builds on top of this and provides support for debugging, syntax validation of mainframe languages and much more. IDzEE is an IBM licensed tool, and my IBM colleague William Alexander has a great blog covering its capabilities.
What’s great about IDzEE is that not only does it have its Eclipse based IDE but also includes its capabilities in VS Code and RedHat CodeReady workspaces. This caters to users who wants to use z/OS from within Visual Studio Code or a cloud based development environment.
Microsoft Visual Studio Code (VSC) is today’s apex predator of IDEs (having overtaken Eclipse due to its popularity with web site developers). The Zowe Explorer extension for VS Code provides the ability to work with data sets, USS and Jobs. This is free and distributed by the Open Mainframe Project, a Linux Foundation umbrella organization, and conceptually is ISPF 3.4, 3.17 and SDSF from within VS Code. The IBM license product IDzEE has evolved also, so that it not only includes it older Eclipse extensions for z/OS, but provides these for VS Code users with rich language editing, debugging, and support for RedHat CodeReady workspaces allowing deployment into cloud IDEs like EclipseChe.
Another great “killer app” feature of VS Code is that with its rich marketplace of extensions I can get add-ons for other languages such as Python, Go, and start to build my own z/OS productivity tool. This self customization means I can make it fit for purpose for whatever task is ahead of me, and my colleagues will do likewise with their environments for their workload.
While IDEs have rich GUIs and feature rich trees and other widgets, mainframers are often at their most comfortable writing text commands. Think how much can be done with TSO? To modernize this experience the Zowe project has a command line interface (CLI). This allows me to issue text commands from my laptop to work with z/OS data sets, USS and Jobs, as well as issue TSO and MVS console commands. Using this within shell scripts I can built up some of the macros and home grown productivity aids but in a more accessible fashion. Not only that, the CLI is extensible so I can make it work with mainframe runtimes like CICS and DB2, or else traditional products like NewView, Workload Scheduler and more.
When describing myself I like to think of myself as a traditional IBMer who developers software and does system programming tasks on z/OS. I grew up using the old ways, and have found myself gently and happily moving across to newer techniques; Eclipse with its free IBM z/OS Explorer extensions, and VS Code with its free Zowe Explorer. Both of these become even better for me with support for debugging and language awareness when IDzEE is added into the mixture making a very tasty Integrated Development Environment for z/O indeed. If you’re still using older tools like ISPF or SDSF and looking for free ways to modernize I encourage you to try out IBM Explorer for z/OS, Zowe Explorer and Zowe CLI, and if you have a budget to spend please checkout IDzEE. It’s made me a better mainframer and I hope it can do the same for you.
If you’d like to learn more about how to start using modern tools to transform your z/OS experience, please reach out and ask me and my colleagues any questions or concerns you have? You can post comments to this and if you’d prefer not to chat in the open, please feel free to message me on LinkedIn. Me and my IBM colleagues also love jumping on ad-hoc web meetings with our customers (i.e. you !) and listening to your concerns, thoughts, feedback (good and bad) which then means we can make our products better and more tasty and allow you to get your job done more easily. We’re here for you and even through we work for Big Blue at our core we’re just a bunch of developers building tools for developers who want to hear from developers so please stay in touch and don’t be shy!
Originally published on the AIOps IBM Z Community Blog
2 thoughts on “We eat our own cooking”
I wonder if the IBM developers, for the NetView product line, used these tools to write the REXX code, that comes with the product, that the customers use?
Joe, I completely agree. I was amazed when I visited a large COBOL user to promote MANASYS Jazz, my COBOL-generating software that is hosted in Windows and has all the IDE support that one would expect, to see that all of the COBOL developers were using ISPF in 3270 emulators. ISPF was wonderful in 1970, but in 2020?