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

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.

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.

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

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

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.

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

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