Welcome to the final installment of the Select/Start blog series, where we are comparing and contrasting two IBM Developer for z/OS development workbenches: IDz on Eclipse and on VS Code. As this blog will be closing out the series, I wanted to take the time to share my thoughts on each tool, the comparison, and give a final verdict, so to speak. Let’s begin.

IDz on Eclipse has been a part of my career and life for nigh on 20 years now. It’s the platform I used when starting to learn to code on z/OS. I’ve been teaching people how to use it for almost 15 years. It has been around for decades and, as such, is jam packed with functionality that has been tested, proven, and then enriched and broadend as the years have gone by. This includes the featureset aimed specifically at z/OS and developers who have been working in a 3270 environment for a large portion of their careers. For example: the capability of the LPEX editor to emulate ISPF* (Interactive System Productivity Facility) gives veteran ISPF developers a huge leg up on transitioning over to the new environment, allowing them to take their existing skills and apply them almost immediately. This may seem like a standard-issue feature in a modern Integrated Development Environment, but if you look closer, it’s actually a major factor in the successful rollout and adoption of the IDE on the whole. It doesn’t just solve a technological problem: it solves a cultural problem.

This cultural problem I’m referring to is deeply rooted in the z/OS community. And for good reason: z/OS is a platform that is two things - consistent, and reliable. Change at the operating system level is not something that is taken lightly, and is planned and tested not for a specific time, but until it works. This is a common theme in the z/OS world: new = untrusted. ISPF was released in 1982, with its predecessor (SPF, Structured Programming Facility, later renamed to System Productivity Facility) being introduced in 1974. Sure, the panels may have changed, features added to specific facilities within the environment, and it has been updated and fixed and patched and APAR’ed, but it is still ISPF. Sit someone who worked on z/OS but has been retired for 20 or 30 years down in front of a terminal and they will immediately be familiar and probably just as adept at programming as they were when they left their career. Point being: when you use a development tool for long enough, and it is established as an industry standard, you become an expert.

Then we flip the script.

You are dropped in to an unfamiliar, modern IDE. No panels, no command line, just pure GUI. The reaction that I’ve seen more often than not is just “no”. It feels like asking someone who has become an expert at using a specific toolset to scrap everything they’ve learned and start from scratch. That isn’t pleasant, and becomes a major roadblock to enabling developers to take advantage of all the fantastic capabilities a modern IDE can deliver.

However, as mentioned above, IDz on Eclipse has features that allow developers to transfer over some of their existing skills, their current way of working, in to the future. They can carry with them the techniques they’ve learned over decades and not feel as though they are struggling with the simplest of tasks. That fact, that seemingly small feature within the larger package, can make or break the rollout and adoption of the tool.

But I am slightly biased. To sum up the above diatribe succinctly, IDz on Eclipse has been around for a long time and has a lot of feature/functionality that caters to the ISPF developer.

Enter IDz on VS Code.

IDz on Visual Studio Code is a newer, nimble IDE. It is incredibly lightweight and it has a plethora of applications for coding in many different languages. Over the past 10 years, VS Code has become the defacto standard for colleges and universities as the IDE that students will learn to code in. This means that the next generation of developers, the new custodians of our priceless library of code that exists on z/OS and, let’s be honest, kind of runs the world (e.g. - CICS handles over 30 billion transactions a day, and reportedly handles over $1 trillion worth of business transactions per week), likely haven’t even seen Ecilpse. This presents an issue: with the next generation of developers favoring VS Code for their work, how do we get them to code on z/OS? Force them to learn ISPF? Eclipse? Probably not going to happen. In the same way the veteran ISPF developers are hardcore about their platform, junior VS Code developers are very attached to theirs. If you’ve been in the z/OS space for any length of time, I’m sure you’ve heard rumblings of the dreaded “skills gap” that we are going to face in our ecosystem. To quote a colleague of mine, “there is no skills gap. There’s a technology gap.” What to do…

Solution: IDz on VS Code.

As a fully-functional IDE, IDz on VS Code has been around for 6 years, when the IBM Z Open Editor VS Code extension was first released in to the wild (read: VS Code Marketplace). With other extensions becoming available (IBM Db2 for z/OS Developer, ADFz Common Components for Fault Analyzer and File Manager, IBM Z Open Debug, et al), the z/OS development experience on VS Code has become comfortable, if not fairly robust. VS Code has always been an IDE where you “get in and code” extremely quickly. So adding the necessary bits and bobs to allow new developers to get on z/OS and code fairly quickly is a really exciting prospect. IDz on VS Code delivers there.

Now to be clear, I am still fairly new to IDz on VS Code. But what has impressed me the most as someone who has staked their entire career thusfar on usage and education around IDz on Eclipse, is that the workflow is clean. I mean, CLEAN clean. Sure, there’s setup to be done. There are some things I need to go to other coworkers for help on, but what I’m describing is no different than when I started working with IDz on Eclipse. It took time for me to learn the workbench, develop that innate knowledge of the workflow, how IDz on Eclipse does what it does. And I am on that journey with IDz on VS Code and it has been fairly painless.

From the perspective of futureproofing, it seems the right decision to learn as much as I can about IDz on VS Code. The tool makes sense, it has made it past the 10 year mark and hasn’t fizzled out. Ensuring that I can be fluent in the tool would give me some peace of mind. Which brings me to the “final verdict” portion of this op-ed on the two flavors of IDz…

After reading what you’ve read, you’d probably think I’d have a hard opinion one way or the other. But if you’ve read the other blogs, I have already given my verdict: use the right tool for the job.

In my life experience, there may be more than one way to do a job, but there is generally a correct tool to use to get the job done. Maybe even more than one, in many cases. A set, if you will. And with both IDz on Eclipse and IDz on VS Code being part of the IDzEE (Enterprise Edition) package, I’d call that a set. So if I were asked which tool to use, I’d have to pose a question back: what is it you’re trying to accomplish? Are you a veteran ISPF user that is looking to transfer techniques and skills over to a modern IDE? If so, and IDz on Ecilpse is available, that might be your starting point. Did you just graduate college and are jumping in to a job that requires coding on a z/OS box? If yes, congratulations! And it would seem to me that using IDz on VS Code would be the best place for you to start. There are features, descibed in previous blogs that outline the major differences between IDz on Eclipse and IDz on VS Code, that are unique to each. But rather than alluding to those differences making one better than the other overall, I choose to think of those differences as flavor. The spice of development life. Having access to two tools that can be used in different ways to accomplish the same thing, based on your preference, is a gift. Use that gift. If you are more comfortable with the Eclipse framework and workflow, use it. VS Code more your speed? Get in there. Use the tool that makes you comfortable and allows you to work efficiently, and, most importantly, use the tool that suits you as a developer the most.