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)

[ssamayoa]

I found “Neoris BMS Designer" also, is stiff but far better than writing maps by hand specially if you don't do it often.
What I don't like about such plugin is the fact that is not open source.

[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.

[ssamayoa]

The problem with COBOL is not the language, is the mind set.

When I worked as COBOL developer in my youth I use structured programming and good practices making the code easy understood.
But legacy code was a nightmare!

“The use of COBOL cripples the mind; its teaching should, therefore, be regarded as a criminal offense.”

• Edsger W. Dijkstra

[flyingV92]

Trying to use the Xplore tutorials to learn Mainframe, keep getting IBM Z Open Editors: Cobol language server crashed x times in x minutes.

[ssamayoa]

Have you checked output pane?
From top menu: View > output then select from drop down box "IBM Z Open Editor"

[benjamin-t-santos]

Can you open the Z Open Editor Welcome Page and check that you have a valid Java configured?
Open the command palette (Ctrl/Cmd + Shift + P) and run "IBM Z Open Editor: Welcome".

[neilbeesley]

IBM Z Open Editor together with Visual Studio Code further embodies the method we have used for the past 25 years developing systems software and applications -- which is to develop, prototype and even partially test code on Windows/LINUX destined for zOS and zVSE operating systems.

[Mhandisiyupo]

IBM Open Editor and Visual Studio Code are a welcome addition to the integration of the mainframe with distributed applications. I am primarily COBOL developer who has work on many cross-platform projects. Endevor is still king of version management but VSCode with GitHub is great especially with cross-platform project involving Jenkins Documentations, DB2 Connect or CICS Transaction Servers. Configuring VSCode for the mainframe environment and configuring extensions reading dumps is challenging and there are no good substitutes for some of the mainframe-based applications that assist in capturing job execution histories and accessing multiple LPARs. Writing COBOL, Easytrieve, JCL and DFSORT are very easy through VSCode and my documentation is easier and more descriptive. I have work on Rocket Mainframe Express Enterprise Edition was great but that required much work to get it integrated to the mainframe. I think that VSCode is a challenge for the system admins to manage the appropriate access and profile for users.

[mhammack]

With IBM Z Open Editor in VSCode, I can work much faster than in ISPF (and I consider myself well versed in the ISPF editor). The few gripes I have are mainly cosmetic. 95% of my work is in HLASM and this has simplified my life quite a bit.

[hallzyx]

Sometimes, when I open a COBOL file, the editor tends not to recognize the file extension correctly.
But in general, it usually works quite smoothly.

[benjamin-t-santos]

Hello @hallzyx. VS Code provides settings for associating file extensions with a language. Z Open Editor also provides settings for associating MVS data set names with a language. You can read about how to use them here: https://ibm.github.io/zopeneditor-about/Docs/setting_fileassociations. Let us know if you have any questions.

[nk2164]

It would be cool if the VS Code could scan the contents of the source & open the right language. Kind of similar to how it is does that in the IBM Z Eclipse Editor. Like in my case, i usually have one pds , hlq.work.comp and i have all my code in pds (jcls, pli, linkdecs etc.)

[phaumer]

@nk2164 we just added a feature like that in v5.7.0: https://ibm.github.io/zopeneditor-about/Docs/advanced_language_detection.html

[FALLAI-Denis]

Hi @phaumer,

With this new advanced feature or IBM Z Open Editor, language detection by analyzing the contents of the file or member is:

1. linked to the activation of extended features, therefore linked to the acquisition of a product license, most often IDzEE
2. linked to the use of an RSE API profile, which excludes z/OSMF users

These two conditions cannot always be met, while the language detection rules are in fact independent of these two conditions and are described in the ISPF/PDF documentation in chapter
z/OS ISPF Edit and Edit Macros / The ISPF Editor / Controling the Edit Environment / Automatic Language Detection

At the very least, it would be necessary to be independent of the use of RSE API which has no reason to be used if you are not already using IDzEE or z/OS Explorer, (and why use IDzEE when you have chosen to use VS Code and IBM Z Open Editor?).

While I agree that major features, such as the graphical view of a program's structure, are linked to the acquisition of a license, usability functions of IBM Z Open Editor, such as automatic language recognition, should be part of the standard functions not subject to licenses.

See:

• [All] Language mode detection function independent of any license and RSE profile prerequisites #535

[phaumer]

It is a optional convenience feature, which is not necessary, but just makes your live easier, as the defaults of setting files.associations are still available for everyone.

[dppduck]

I'm extremely impressed with the functionality provided by the IBM Z Open Editor. I've recently been refreshing my IBM mainframe skills by following the IBM Coursera courses and the IBM XPlore challenges. The Coursera courses use ISPF for practice sections whilst the IBM Z XPlore challenges use the Z Open Editor. This has given me the opportunity to compare the two development environments in a very structured way. If your focus is learning how to develop software on IBM mainframes (e.g. COBOL or Assembler) do yourself a favour and use VSCODE. I really enjoy the fact that I can use VSCODE to write programs (with hinting and highlighting), submit the jobs and look at the output all from one window.

In addition to this, using VSCODE allows me to use my favorite editor mode (VIM) to write JCL and Assembler. This beats using ISPF hands-down.

[ssamayoa]

I still use TSO/ISPF for administrative tasks (browsing datasets including VSAM files is slow, when I had time I will take a look at the zowe explorer code) but wonder why people still use ISPF to do development / maintenance of COBOL and ASM.

Not all dinosaurs like new stuff! XD XD XD

[okurka12]

IBM Z open editor, alongside with Zowe explorer, has been super useful for me at work where I'm dealing with JCLs and REXX scripts. For some of the things I use ISPF but I do all of the editing in Vscode.

I only learned to use ISPF recently and IBM Z open editor makes mainframe development not all that different from what I'm used to 👍

[Hpmason]

Definitely been one of the best mainframe extensions I've been using. Only feature that I feel is missing current is "Show Call Hierarchy" for cobol, like other LSPs. It would make a huge difference traversing cobol code

[benjamin-t-santos]

"Show Call Hierarchy" is now available for both COBOL (v6.1.0) and PL/I (v6.2.0)

[FlaviaBastos]

I'm just starting to learn COBOL and taking IBM's z/OS courses (but an experienced software developer otherwise) so I don't know how valuable my feedback is.

So far I'm very pleased that I can continue to use the tools I already know (VSCode, for example) and focus on the content and writing code, as opposed to spend loads of time figuring out yet another editor/setup/environment, etc. It definitely lowers the entry barrier.

[magicrani-35]

I love using it. I am still going to use the Mainframe as I am also taking courses on coursera and they give us access to the mainframe for assignments, which I want because I gives me experience on that side as well and learning how to navigate that alone is a skill but it does become second nature once your on there and they directed me to the z/0s course also.

This is great as they are working on modernization for COBOL and VS Code is the way to go!!!!

[somumath7-ops]

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.

Hi,

I am a non-IT guy. I am an Electronics engineer worked in engineering field for many years and currently as a business consultant. I have no experience in IT but had done a course in Mainframes back in 1997. I wanted to enter mainframes profession but it never happened due to personal and other reasons. Being in a new country since last one year and when all the roads I took appeared to be leading to dead-ends, just a random thought led me to google whether mainframes still existed and if there is any future, only to know that mainframes are very much alive and have a great future. Then I googled to see whether there are any commercial simulators available so that I could see the black screen of TSO ISPF and to check if I could pick from where I had left. I found to my great joy that IBM itself was offering free mainframe access for learning. I enrolled without wasting any time and set up system and connected to mainframe.

Once I was in, I felt like I have enrolled into a university. So many technologies, modules, challenges and very well written material that takes us from a novice state to an expert! And what a fantastic support staff!! As many would agree, you can't get this kind of support even for paid services these days. I am thoroughly enjoying this. I sincerely hope to be working in commercial mainframe projects sometime soon.

Sincerely,

Somesh

[smartduck66]

Hello,

I'm not a mainframer, I only 'approached' the mainframe World when I've been working at Generali during 90's : I developed there some facelifting apps with Attachmate tools. Recently, I needed to better understand this environment so I began to practice it with IBM Z Xplore. I had to install some tools like Zowe, IBM Z Open Editor, USS tools or DB2 Developer extension under my Visual Studio Code. And clearly, it is awesome! You can almost interact with a big mainframe like coding on a classical open server :-) My learning path is much easier, very fun. A big thanks to all the team involved in this DX improvement.