All languages - Outsource DBB functions in an independent extension

[FALLAI-Denis]

Description of the enhancement requested

IBM Z Open Editor includes an API for accessing IBM Dependency Based Build.

We are considering the implementation of IBM DBB in the near future, to manage the constructions of COBOL programs, but also if possible, the construction of other types of elements, (like for example Db2 objects). These other types of elements would not be sources managed by Z Open Editor, but thru other VS Code extensions, including VS Code extensions that we may develop ourselves.

Ideally, any type of element should be able to be managed through IBM DBB, to have a unified build process and a global vision of mainframe components thru IBM DBB, even if this build process is limited to a simple transport of the element without any transformation. At the output of IBM DBB we want to create deployment packages containing all the components, and not just the loadmodules from COBOL compilations.

We would like to be able to access the IBM DBB API outside of Z Open Editor. For this, these APIs would have to be externalized in a VS Code extension independent of Z Open Editor.

This also meets our other request User Build function not dependent on DBB: there must be independence between the different functionalities and not group everything in a single extension.

[phaumer]

Thanks for the suggestion. We currently have no plans in breaking up Z Open Editor's capabilities to keep our capabilities in one convenient extension. However, offering extensibility APIs, similar to what we did for Zowe Explorer, are a good idea if they offer growth potential for Z Open Editor, i.e. more capabilities can be added/plugged into the editor.

Right now you can use the User Build functions to upload any type of file with the additionalDependencies ZAPP setting and the command, buildScriptPath, and buildScriptArgs can be used to execute any kind of command. If we would offer an additional command to start a user build via the command palette without a file context or a file context that can be selected would that address you needs as described in Issue 92; or are there other requirements that would be needed?

[FALLAI-Denis]

Hi @phaumer

That's not the view I have of things. I think on the contrary that it should be modular: 1 function = 1 extension. This gives much more flexibility, unless you want to limit the possibilities of choosing solutions...

Z Open Editor applies this principle for access to mainframe resources, relying on the services of Zowe Explorer extension. The same should be true for DBB access services.

In addition, we have kinds of elements to manage which cannot be supported by the editor of Z Open Editor, (or other editors on the market). For these types of elements, we want to manage a source file in YAML format through a dedicated user interface for presentation, input and controls. These YAML documents are then interpreted to produce mainframe components. We are thinking of using DBB to provide this transformation.

Use cases:

• declarations of Services running in CICS. The Service is described in YAML, and it is necessary to generate CICS declarations of TRANSACTION (TOR and multi AOR, associated with a program for the AOR, and an routing remote SYSID for TOR), RACF declarations for the external security authorization of access to the transaction, a fragment of Assembly code to be compiled in a configuration table in loadmodule format.

• declarations of logical authorizations Each CICS transaction is protected by an entitlement, and entitlements are grouped into profiles. This information would be described in a YAML document, which then, through DBB, produces information for loading Db2 tables.