Welcome to the Select/Start blog series, where we are comparing and contrasting (a little foreshadowing there) two IBM Developer for z/OS development workbenches: IDz on Eclipse and on VS Code. In the last installment, we looked at the commonalities between the two GUI tools. The list was broken down by feature set or task, and was not a comprehensive list, but more of a “greatest hits” list. There was a lot of information in the previous blogs, and if you haven’t read them yet, here they are:

Blog 1

Blog 2-1

Blog 2-2

This blog should be a little less wordy, but still just as important. In this blog, we’re going to dive in to some of the differences in the two development environments. But instead of pitting the two against each other in a head-to-head battle, we’re going to look at it as “use the right tool for the job”, a quote that I live by since I first heard it at a job I held in college.

The premise is that when doing any job or task, you want to seek out and use the tool or tools at your disposal that allow you to complete said job or task with the most accuracy and efficacy. In our case, we want to look at IDz on Eclipse and on VS Code as two great tools with their own intricacies and uses that can elevate the development experience and, as such, should be utilized for their strengths, rather than judged by any percieved deficiencies. There’s also a wildcard consideration which I will go in to more detail about at the end of this blog, but for now, let’s take a look at how the two workbenches differ.

One last thing: the points in this blog (and the points in the last blog, for that matter) are topics of discussion at this point in time in each product’s life span. In other words, both of these products are part of a CICD product lifecycle that nets many fixes, improvements, and new releases. What’s listed in this block is a snapshot of right now, and things may change in the future.

Okay, disclaimer out of the way, let’s go.

Firstly, let’s talk navigation and the concept of the “workspace”. IDz on Eclipse can be added to and extended in many ways, from third-party Eclipse plugins to Menu-Manager features. This has its advantages and disadvantages, but overall allows for extreme customization at the end-user level. Whether you would consider that a good thing or a bad thing, it is a thing regardless. On the other hand, IBM Developer for z/OS on VS Code (IDz on VS Code) is more restrictive from an extensibility standpoint. All extenders must follow VS Code UX (User eXperience) guidelines, which makes for a simpler, more streamlined experience and a more dependably unified workbench across teams.

Next, the idea of “quick fix”. Quick Fix is a feature in IDz on Eclipse that essentially utilizes parsers and the in-memory-version of a program to suggest a fix to code when there is an error present. It uses context to decide if a particular keyword might be needed, or maybe a variable was misspelled, and uses visual cues and a pop-up box to “suggest” a fix. This is technically possible in IDz on VS Code, but IDz on Eclipse presents it automatically in the COBOL LSP (language specific editor) that comes out-of-the-box with the Eclipse version of the product.

IDz on Eclipse provides access to the Menu Manager facility out-of-the-box. This facility allows otherwise unachievable integration with existing ISPF functionality, streamlining of development task time-to-complete, and extensibility to the workbench through customizable menu and sub-menu options. IDz on VS Code can achieve this through the use of VS Code Commands and extensions through the VS Code Marketplace (which is quite the treasure trove, many gems to be found there), however this is not a 1:1 comparable feature.

When it comes to “footprint”, or an all-things-considered look at the installation effort, physical size, and configuration of the two products, IDz on VS Code is much lighter weight and easier to deploy. It’s purpose-built as a coding battlestation, and as such can be spun up in an instant and has configuration-as-code as a major plus so that you can get in and code right away. IDz on Eclipse has configuration-as-code as well, but is a much more mature and robust product, and with that, has a much larger footprint and impact when it comes to installation/configuration/deployment/maintenance.

Lastly, let’s talk AI. AI features are an extremely hot market as of late, and at this point in time, VS Code is the development environment of focus for the use of AI tools. Some of the extensions that give developers access to AI features would be Microsoft Agent Mode, Github Copilot, and IBM Developer for z/OS now ships MCP tools that can be utilized by AI agents. These types of features are not presently available in the Eclipse space; that’s something to think about.

So truthfully, there are a few places where you might want to use one tool over the other. Doing deep analysis tasks and you want graphical representations of a specific program or data field? Maybe IDz on Eclipse is your choice. Strictly coding and need to get up and running really fast? IDz on VS Code might be your best bet. These points are not meant to create a divide, but rather liberate you as an end-user in that you have choice. You have the power to decide which workbench is the best fit for what you’re doing at any given time.

So. What’s it going to be? What’s the verdict? If you’d like my personal opinion, I’m taking off the “blue shirt” in the next installment. Stay tuned.