COBOL (first) - Allow use of "exotic" EXEC / END-EXEC block in source programs

[FALLAI-Denis]

Description of the enhancement requested

Hi,

We use a product (IBM origin) that requires the use of EXEC / END-EXEC instructions blocks, other than SQL, SQLIMS or CICS, in the source code of programs (COBOL).
These EXEC / END-EXEC are translated to COBOL with a specific preprocessor.

When these programs are edited with IBM Z Open Editor, the (COBOL) Language Server triggers errors, which then invalidates many of ZOE features... 😢

We would like the (COBOL) Language Server to accept others EXEC / END-EXEC blocks than those currently provided (SQL, SQLIMS, CICS), and not trigger errors.
At the textmate grammar level, we should provide a specific scope name for these EXEC / END-EXEC blocks that we could overload with a proprietary "left" textmate grammar in a "language" extension developed by ourself.

Another solution would be to implement a before/after markup system in the form of standardized comments to tell the (COBOL) Language Server to ignore lines of source code that Language Server does'nt support:

• *>BEGIN-LS-IGNORE
• *>END-LS-IGNORE

Thanks.

---

Our specific use case, but enhancement should be generic:

[phaumer]

Do you think this could be solved by our new preprocessor capability? You could use the Java or REXX samples we provide and adjust them to do this substitution?

https://ibm.github.io/zopeneditor-about/Docs/advanced_preprocessor.html

[FALLAI-Denis]

Hi @phaumer,

In our use case, the preprocessor is a remote processing on mvs.
I don't think that using the preprocessor function meets our needs.
We want to be able to work on the COBOL source code before translating by the preprocessor, and not after this translating.

The same problem exists on programs edited with ZOE before translation:

The solution proposed by ZOE makes me think more of a "quick writing" type solution using a macro-language, than of a solution for extending the basic language (like COBOL Report Writer, or TypeCobol), or a embedded language solution (like Exec / End-Exec):

• in the case of a macro-language system, we can forget the initial version carrying the macros, then use the output of the preprocessor to continue working on the code after translation,
• in a system for extending the basic language, or support embeded languages, the goal is to work only on the source code before translation.

Note: about macro-language, see the cobolmac contribution for gnuCOBOL

Thanks.