technical: IDEs: Some Assembly Required
At one client, they had two different Integrated Development Environments (IDEs) installed: neither had any significant usage. At another, they had an IDE installed: an old version no longer supported. A third client explained that they had an IDE, but were having difficulties getting it running.
IDEs are great. They offer everything from real-time syntax checking and colour coded editing screens to features for dataset and job management. More importantly, they offer productivity benefits, and can make it easier for new staff to become useful faster.
But as these clients found out, IDEs aren't necessarily easy to get running. In this article, we're going to look at possible reasons why.
Almost all IDEs require a z/OS-side server to process requests. In the case of IBM Developer for z/OS (IDz), this is a Websphere Application Server Liberty server. For Zowe explorer, the normal Zowe address spaces are needed. Some IDEs like Che4z piggy back off the Zowe Command Line Interface (CLI): those Zowe address spaces are still needed.
There are some exceptions to this rule. For example, the Zowe FTP plugin for the CLI allows the Zowe CLI to be used to access datasets using FTP. And we can also manually download files from z/OS using FTP, and then use an IDE to work with them. However, in general, z/OS software is needed. This introduces all the normal issues with any z/OS software: installation, APF authorization, systems programmer support, regular updates and maintenance. Not to mention security issues.
In the case of Zowe, additional software is required to be installed on z/OS, including Node.js.
It's no surprise that IDEs also have a client component. In the case of IDz, this is Eclipse based, while Zowe Explorer is a VSCode extension. Again, in an enterprise this involves setting up all the management of these clients: ensuring that releases are supported, and fit in with a site's software standards and requirements. These clients often need additional supporting software to be installed. For example, Zowe Explorer needs Zowe, VSCode and Node.js.
The work doesn't end there. Those clients need to be setup to connect to the z/OS component, with any encryption or authentication requirements satisfied.
For example, profiles can be defined in Zowe CLI to provide connection and authentication information. For IDz, remote connections must be defined within IDz: the user must know the IP address and port to connect to.
Other configuration steps may also be needed. For example, the IDz Data Source Explorer cannot work without an IP address, port and Db2 subsystem name of a z/OS Db2 subsystem that will process SQL requests.
In many cases, extensions are available that may be needed. For example, Zowe Explorer provides features to edit z/OS datasets. However, many sites may choose to use Zowe Explorer with the IBM Z Open Editor to get advanced features for editing COBOL, PL/I, Assembler and REXX programs.
Once the software has been installed and configured, then it's ready for basic operations. However, the chances are that you will want to perform additional customization to make it more useful.
For example, IDz allows JCL for COBOL compiles to be generated and executed. For this to work, z/OS administrators will need to customize JCL procedures installed on the mainframe. Administrators will also need to setup IDz Property Groups with required compile and bind options.
IBM Z JCL Expert is another example: it can validate JCL before jobs are submitted. It is available as an Eclipse plug-in, allowing it to be used with Eclipse-based IDEs like IDz.
Snippets are a third example: these are 'pieces' of commonly used code that users can drop into their own code. In some cases, IDEs and extensions provide pre-canned snippets. However, to really benefit from them, sites will want to code their own. For example, a snippet with a standard job card would be handy, or COBOL code to open an MQ queue. Sites can also provide comments and other hints to help programmers produce better code.
Now, users can do all this work themselves. However, it would be smarter if someone put all of this together, so users don't have to.
Source Code Management
The most common use for an IDE is to develop and maintain z/OS source code. However, in most sites, this code will be under the control of Source Code Management (SCM) software. So, for the IDE to be effective, it really needs to work seamlessly with the SCM to view, checkout, modify and commit source code.
The good news is that most current SCMs work with the common IDEs. For example, IBMs Rational Team Concert has an Eclipse client that can work with IDz. Similarly, Explorer for Endevor is a VSCode extension to allow Zowe Explorer users to work with Broadcom CA Endevor.
But again, this doesn't happen magically. Someone has to create the pathway: providing a way for IDEs users to work with their SCM. Ideally, this would all be packaged together to make it easier for IDE users: but someone needs to do this packaging.
Even at sites with an IDE, the most common tool for editing source code is ISPF: particularly with veteran programmers. To convince them to use an IDE, you must do two things:
Reduce the number of reasons not to use the IDE.
Make it easier to use the IDE.
Many of the issues mentioned previous address the first point. For the second, existing users must be trained: the IDE solution must be 'sold' to them. In many sites, they assume that IDE documentation and YouTube videos are all you need. However, the chances are that your IDE configuration and setup will be different from others. Your z/OS systems and SCM configuration certainly will be. So, users will need training created and delivered to make it easy for them to get up and running on the IDE at your site.
Implementing an IDE solution is far from impossible: many z/OS sites have successfully achieved it. However, like any other project implementing a new tool or solution, it must be planned and executed in such a way that it will be a success.