IBM Z Open Editor User Survey

[phaumer]

What are the reasons for your score provided below?
What other feedback would you like to share?

Your detailed comments will help us improve your IBM experience.

[FALLAI-Denis]

Hi,

IBM Z Open Editor has become an essential element of our CI/CD chain modernization plan for the mainframe.

Support for the VS Code environment allows us to use the same tools as our colleagues in other development sectors and to integrate young developers more easily by avoiding the shock of the 24x80 green screen.

The use of IBM Z Open Editor, and its exploitation of the VS Code ecosystem, gives great comfort of use to our developers: syntax highlighting, rapid navigation using the minimap, the outline, or breadcrumbs, searches and replacement either at the file level or at the global workspace level, the contributions of the language server which detects anomalies and avoids unnecessary compilations, and many other facilities.

The native integration of VS Code with the Git standard benefits IBM Z Open Editor and allows us to have a development activity almost completely disconnected from the mainframe infrastructure which is only used to carry out compilations (which we dealing with IBM Dependency Based Build which is natively interfaced with IBM Z Open Editor for User Build), and of course testing activity, (we also use the VS Code interface for debugging programs).
Even our copybooks are managed and accessed through Git to be made available to IBM Z Open Editor, (and IBM Dependency Based Build) .

[FALLAI-Denis]

PS: how we industrialized our COBOL development workshop around IBM Z Open Editor

• Create a new program from a standardized skeleton:

• Add a sequential file resource to the program (can also be modified later, iterative and incremental process), the program contains only the useful code, all the technical code is externalized to a "smart" copybook framework exploiting conditional compilation to adapt to each use case

• After multiple resources declared

• Compiling the program: 1141 lines in program source code, 3488 compiled lines after inclusion of copybooks, no line of technical code written manually: the developer must only manually write the business code at reserved and identified locations in the program (not present in this demo)

[phaumer]

Very impressive. Thanks for sharing.

[silvio14750]

Hi all,
I worked for most of my life on IBM mainframes, starting with MFT, MVT, OS/VS2 MVS till z/OS. Editing evolved from punched cards and card decks to 3270 screens and source libraries, from B/W screens to color screens and this is still used today on 3270 emulations.
But once you start editing with VSCode you'll never go back to ISPF like editing. This was a big step forward.

Today I am retired, have an old MVS 3.8 on my PC under Hercules emulation and I do all the editing with the ZOWE editor in VSCODE mainly S/370 assembler. I moved on to learn about the internals of microprocessors like the Raspberry Pi Pico. Programming a RISC microprocessor in assembler is feasible but somewhat very low level. Programming in IBM Mainframe Assembler feels like a higher programming language comparing to ARM Assembler. So I wrote an Emulation for most of the S/370 instructions to run on the ARM cores.
So I can still program in S/370 Assembler and with the ZOWE editor it's much fun. I appreciate much the intellisense functionality which is a great help. Today I can't imagine doing without it.

If you have not tried it out yet, I strongly recommend to use it. In addition you will benefit from the great integraton with the modern z/OS's. You'll love it.

[ssamayoa]

Even tho I mostly do Java & Kotlin I have to do some mainframe coding in COBOL and recently have to do ASSEMBLER (still in process of learning!) .
Coding in VS Code, even if is legacy code, is far more pleasant experience over ISPF.
I'm not using z/OSMF interface but zFTP (former uses too much resources which increases our bill!)
Even tho some unresolved problem with zFTP interface, I'm very happy with this plugin.

[davidkcoblentz]

Hi,

IBM Z Open Editor is far superior and light years ahead of any of the many Windows operating system editors that I have tried.

My entire career has been mainframe development in COBOL and Assembler, but mostly in COBOL, for fortune 500 companies.

I had been looking for years to find a mature Windows environment editor that included IBM COBOL and Assembler languages and that could rival the maturity of the ISPF editor so I could move editing off of the mainframe. With ISPF, I created many useful custom COBOL specific tools with ISPF Editor Macros, Dialog Manager and REXX which increased my editing proficiency with COBOL projects. So, finding an editor off of the mainframe to compete with ISPF and its rich, mature and flexible features was difficult until I found IBM Z Open Editor for VS Code! A colleague had suggested VS Code, so I tried it and discovered the IBM Z Open Editor extension for COBOL, Assembler, PLI and REXX. I spent time learning VS Code, which didn't take long, and the great features built into IBM Z Open Editor. Now, I will never go back... The list of great features in IBM Z Open Editor are too long to list here. I can't imagine not being able to use this editor, it lives up to all of my expectations and more! The features in it accomplished the same things I had created in my custom REXX execs that I had written plus many, many more that aren't possible in the green screen environment. The comparison is night and day!

The GitHub interface is excellent! It is a great way to keep track of source changes while multiple groups of developers are working on the same mainframe system. The source compare feature is great and the search all source feature is so handy!

I won't work without this extension...

[tgmz]

Editing capabilities are very good but navigation is poor compared to e.g. z/OS Explorer Aqua.

[nk2164]

I love the syntax highlighting, search & quick shortcuts to lookup all references etc.. Having the ability to connect with mainframe via Zowe explorer opens it up and i am now able to reference my host pds's and copbooks, check my jobs and uss folders etc.

I use VSCode Neovim extension and in combination with all the language support and features provided by Z Open Editor, it makes it an incredible experience to work on my mainframe code with all the power that vim provides. The PLI parser could use some updates as I have found some issues which I have reported.

Overall, I love where this is going. Thanks a lot.

[cybersorcerer]

Hi,

it is essential for younger developers to work with the toolchain they are used to work with. VSCode with ZOWE Explorer, IBM Z Open Editor, ZOWE CLI and git allows this. Great Job so far but a strong support for developing z/OS XLC Code and XLC Code with the Metal Option is missing IMHO! The native VSCode C Extension is not enough, it often shows wrong or missing includes cause it does not know how to access the z/OS include files, even if you mount /usr/include using NFS. Anyway i am a lifelong mainframeer (since April 1984) i do use VSCode with ZOWE Explorer, IBM Z Open Editor, the ZOWE CLI to develop HLASM and XLC Code since 2019 and never had the desire to go back to ISPF.

[phaumer]

I agree, we have these problems with many other languages for VS Code when it comes to z/OS development. It impacts not only C, but Java, Python, Node etc. We are trying to motivate communities around these languages to get started collecting best practices and examples (e.g. I just did that myself publishing a small Git repo for Java), but it requires time investments and a strong demand.

[cybersorcerer]

Hi Peter,

I had a look at your Java Sample Repository. When i have some spare time i will try to create something similar for z/OS XLC. I developed several METAL XLC modules to replace some of my assembler modules. I created a python module to sync the changed files to a directory in my z/Unix $HOME and used a Makefile with compile and link targets. I also created some VSCode tasks for example a make current buffer and added key bindings ctrl-alt-b. This task will sync the source to z/Unix and call make to build the code in z/Unix. The task uses zowe cli ssh to call make with the correct target name. Compile and link edit output is stored in subdirectory .build in z/Unix and can be xferred to my desktop by pressing ctrl-alt-d (calls another task with zowe zos-files download uss-directory ...)

Regards
Ronny

[FALLAI-Denis]

Hi @phaumer,

Java management for z/OS is on our roadmap for the next months, initially in a CICS environment, for XML document management, coupled or not with COBOL.
Our needs are:

• the build
• the packaging
• the deployment

We have to discover and invent everything...
And the fact that working with Java on z/OS also involves working with USS (Unix System Services) on which our system teams have never invested... USS has specificities that are not known to people from the traditional Unix world.
I suggest opening a discussion space on your Git repo for Java.

Today we manage our sources using Git, (Bitbucket), and we edit them with VS Code and ZOE. Works fine.
We build with Jenkins and IBM Dependency Based Build, which does not currently support Java (although IBM DBB is a product developed in Java).

Our scope of mainframe languages used is:

• COBOL (about 35.000 programs alive in production)
• HLASM assembler, few hundred programs but they are strategic
• C (not C++) for some programs which should gradually replace Assembler programs
• Rexx and ISPF (panels, skeletons, msgs, for which there is no VS Code solution on the market): for “traditional” internal tools
• Groovy (and DBB API) for our new CI/CD tools (mainly around build and deployment)
• Probably Python if we want to use IBM Wazi Deploy

I also suggest opening a survey / poll to ask what are the most commonly used languages on mainframe, and what would be the priorities expressed by ZOE users for the support of new languages.

Another area in which we want to invest is the use of virtualized environments.
It would be nice if the developer working under VS Code (or other) and using ZOE could administer their virtualized environments, install components, run tests, etc.
Today there are at least 3 mainframe environment virtualization solutions:

• ZD&T, virtualization on x86
• Wazi Sandbox, virtualization on x86, (related to OpenShift?), our preference as end users
• zVDT, virtualization on zSeries and zLinux, the choice of our Z system teams...

A problem that we encounter on our mainframe CI/CD chain modernization projects is the absence of human resources with knowledge of both the mainframe world and the so-called "open" world.
Either they are former mainframers with graying hair (of which I am one) who are trying out new technologies, with difficulty, or it is necessary to train younger people in the mainframe to give them this culture, which can sometimes be off-putting.

Another problem is that the recipes that have proven successful in the "open" world do not necessarily apply to the mainframe world... we learned this the hard way...
In an "open" environment we work in "configuration": a set of artifacts which evolve together and are deployed together, in a logic of incremental evolution based on sprints. Using products like Git works well.
In the mainframe world, historically, we work by "components" which evolve through projects, of which we do not know in advance the deployment date, with problems of progress at different rates, or even temporary or definitive stop, with conflicts components between projects and rollbacks to sources. Using Git is then problematic because Git is not a "component manager"... Git is a "configuration manager".

Once again, thank you for all the work done, (and your patience in processing all the requests made).

[peraciodias]

Os trabalhos com mainframe se tornam mais produtivos usando o IBM Open Editor and Zowe !

[dvag-dominik-schumacher]

In our company, we are currently in the transition phase of replacing an Eclipse-based IDE (Microfocus Enterprise Developer) with VSCode for our mainframe development.
We are using the following technologies:

• VSCode and Z Open Editor (editing Cobol and REXX source code)
• BMC DevX Workbench (Accessing z/OS MVS and USS)
• BMC DevX Code Debug (XPediter interface for debugging)
• Git and Github plattform (versioning system)
• SonarQube and SonarLint (static code analysis)
• Github Actions (Deployment Pipeline)
• Cobol Check from the Open Mainframe Project (currently in the evaluation phase for the introduction of unit tests)
• Python for software development in Unix System Services

The speed, stability and the significantly more powerful extension system compared to Eclipse are one of the main reasons for switching to VSCode for mainframe development, especially as ZOE has now reached a high level of maturity (even if we are still missing some features or there are bugs which I have already reported) and we want to use the same IDE and components for development on the mainframe and in the “Open World”. Younger developers in particular demand a modern IDE. With pure development under ISPF, you quickly scare them away.

Nevertheless, we would like to see native support for graphical editing of BMS maps in ZOE (we are currently using the newly released third-party plug-in “Neoris BMS Designer” https://marketplace.visualstudio.com/items?itemName=NEORIS.bmsdesigner)

[bucwaboos]

I really appreciate the opportunity to learn more about the mainframe. I regularly run performance tests against applications that utilize mainframe db2 and as such have been very curious about it.