Does Zowe/ Open Editor have a way to generate JCL to assemble HLASM code

[johntgatesjr]

Z Open Editor version: 3.3.2
Zowe Explorer: 2.12.2 configured to use z/OSMF to z/OS 2.4

Editor Platform
[x ] Visual Studio Code
Editor Platform Version: 1.84.2

Operating System (on which VS Code runs): MAC/OS 13.6.2

Java Version (when using VS Code):
IBM Semeru Runtime Open Edition 17.0.8.1 (build 17.0.8.1+1)
Eclipse OpenJ9 VM 17.0.8.1 (build openj9-0.40.0, JRE 17 Mac OS X aarch64-64-Bit 20230824_392 (JIT enabled, AOT enabled)
OpenJ9 - d12d10c9e
OMR - e80bff83b
JCL - 8ecf238a124 based on jdk-17.0.8.1+1)

IDz provides the ability to generate JCL to assemble an HLASM part from the HLASM part in the editor. I can then invoke that JCL remotely from the IDE. Does Zowe/ IBM Open Editor provide a similar feature? Note this is for the development use case. We have different expectations for the Build/Deploy use case using Git/ Jenkins and DBB for remote full product builds. (I will ask for Zowe support for that sort of integration in a separate thread.) Thanks for your continued support.

[phaumer]

Our goal is to focus on next generation capabilities. Although we have basic syntax highlighting support (reused from open source), uploading and running JCL via Zowe Explorer, generating JCL is not something we are interested in doing. Instead we are more interested in improving our integrations with IBM Dependency Build that currently utilizes Groovy, utilizing Ansible and the z/OS Collections for automation, as well as ways to utilize Python-based tools such as Z Open Automation Utilities, which are also used by Ansible. We believe that these are technologies the next generation of developers would prefer using as they require skills that are also useful in the distributed space, breaking down silos in the development organization.

[johntgatesjr]

I don't disagree with your analysis, but you are talking about a different use case. The use case I am interested in is the developer use case of writing and testing small portions of code. This use case needs an automated way to do incremental compile/ assemble and unit test without the full blown CI-CD pipeline. We have those use cases too, but for the simple case, it would be nice if, as you say, I don't have to logon on to the mainfame, run JCL, and gather up the spool output for a single part.

[phaumer]

Have a look at this video that shows how to use our editor for such scenarios. It shows how to use automation to setup a development workspace and then do edit, debug, build operation from the editor. Around Minute 8 you see how I run a user build with a simple right click that runs a personal build on my z/OS system - which uses the Groovy-based Dependency Build system - by just building that one program file that I am editing, which I could then immediately run or debug again. (for full disclosure, this demo also runs some manually created JCL code to show that it is possible, e.g. for starting the Debug session, but I could have done it all with Groovy as well)

https://www.youtube.com/watch?v=OdsfPi0fKto

[FALLAI-Denis]

Hi,

An interesting point of the ZOE interface with DBB is that the triggered compilation (build) is executed in a shell and therefore is not subject to queue management as for JCL: processing starts immediately.
In addition, the ZOE interface with DBB transfers the compilation (build) outputs locally to VS Code for consultation in VS Code.
The ZOE interface with DBB can be used outside of DBB as long as the call to DBB format is respected.
It is thus possible to call a USS shell script which will ensure COBOL or Assembler compilation. This shell script remains to be built:

• either a prepared script that resides on z/OS-USS
• either a script declared in the VS Code workspace and transferred to z/OS-USS for execution

Beyond the script, you also need to manage all the compilation and linkedit options, or even bind Db2 if you also want to deploy immediately after the build.

---

For information, the elapsed time of a compilation + linkedit of a COBOL program with DBB is 1 to 3 seconds, to which must be added that of the processing of the DBB application (zAppbuild) coded in groovy language.
To compare with the elapsed time of a compilation by JCL which is closer to the minute, to which must be added the time taken into account by JES2 QUEUE.

Rather than submitting JOBs through VS Code (Z Open Editor or Zowe Explorer), I think that for the user experience it would be more interesting to run SHELL scripts.
Using IBM DBB, Dependency Based Build, licensed product, to compile makes implementing such scripts easier because DBB exposes APIs to run MVS programs and to manage the files needed for the compilation and linkedit stages. In the case of a User Build, the DBB database is not used.
Without IBM DBB it should also be possible to achieve the same result in a more traditional way with SHELL commands.
The use of IBM ZOAU, Z Open Automation Utilities, free of charge, should also facilitate this implementation.

The IBM User Build interface integrated into Z Open Editor allows you to launch a SHELL script in the IBM DBB call format, but in fact it is possible to launch any procedure running in a SHELL script using the same parameters.
The IBM User Build interface integrated into Z Open Editor takes care of transferring the source to compile, but also all the prerequisite sources (include, copy), to a workspace on USS.
The IBM User Build interface is also responsible for retrieving the output produced by the compilation into the VS Code workspace.