Auto detection of mainframe language code stored in datasets retrieved through Zowe Explorer

[EmmasBox]

When I retrieve my JCL stored in datasets through Zowe Explorer VS Code does not automatically detect it as JCL, because it looks for file extensions, this problem applies to Rexx, COBOL, and PL/I as well. I have seen newcomers to VS Code assume it is unable to highlight mainframe languages such as JCL, Rexx, COBOL, and PL/I.

I propose IBM Z Open Editor implements auto detection of mainframe languages that doesn't rely on file extensions, instead it should look for indicators such as / Rexx / and //.

[phaumer]

Thanks for submitting this request @EmmasBox. This will be a tricky one and it is really something we want VS Code to do this and not us. Here some thoughts:

1. If you are opening files via Zowe Explorer we offer a way to map data set names to our language ID as described here in the docs, which is based on the files.associations setting in VS Code that allows wildcards, which is quite powerful. Have you played with that?
2. VS Code has settings such as workbench.editor.languageDetection workbench.editor.historyBasedLanguageDetection workbench.editor.languageDetectionHints workbench.editor.preferHistoryBasedLanguageDetection Have you played with these? I have no experience with them, but perhaps they work.
3. We really do need extensions for files in some cases. For example, COBOL copybooks can contain valid COBOL and we need to distinguish them from programs as we parse them differently. We therefore need our settings zopeneditor.cobol.includeFileExtensions etc.
4. We do not want to be too aggressive about taking over files as we had complaints about it in the past and we agreed with partners on the specific language ids to use to allow different VS Code extensions to be co-installed and assigned languages by individual languageid/file extension mappings.

[FALLAI-Denis]

Hi,

The ISPF editor on z/OS implements language autodetection. The rules are available here: z/OS ISPF Edit and Edit Macros - Automatic language selection

I think the LPEX editor also uses language autodetection, and LPEX is available in IDz, (although it is deprecated).

Personally, I'm going to look at the suggested VS Code APIs to see if it would be possible to develop an extension that would do language autodetections:

• intercept the opening event of a file or an editor
• analyze file or editor contents
• force language mode based on analysis
• change file extension (rename file) ? Only if file name is a z/OS dataset name ?

The problem of language detection a priori only concerns files without extensions, and files retrieved via Zowe Explorer from z/OS which do not use an extension system. In other discussions, I have already pointed out that the current system is unsatisfactory and often gives false results. For example I use a hlq.COBOL.JCL PDS.... This PDS is wrongly detected as containing COBOL elements when it in fact contains JCL elements (COBOL compile JCL)... This because the analysis is done according to the order of the declarations made in the settings.json. This is why a content analysis would be more appropriate than an analysis of z/OS file names.

Another possibility would be to set priorities on the words (segments of dataset names) that make up a z/OS file name. For example :

• COBOL: priority10
• JCL: priority 1

If the dataset name has a segment that contains the word COBOL without any segment that contains the word JCL: it is a COBOL source If the dataset name has a segment that contains the word COBOL and also a segment that contains the word JCL: it is a JCL source

Another possibility would be for ZOE, or rather Zowe Explorer, to be "extensible": giving the possibility of subscribing to an event triggered by ZOE and creating a proprietary extension which intercepts this event and decides the language to associate with the file.

[phaumer]

I like the idea of a Zowe Explorer API for extenders to inject an algorithm that adds file extensions to the downloaded files in the temp folder dynamically. Zowe Explorer itself must remain file type agnostic, but allowing language extension to provide solutions would be great.

[FALLAI-Denis]

Hi @phaumer,

With the current solution, described here, ZOE would have to take the values indicated in the zopeneditor.datasets.<language>Datasets parameters as is, without adding a wildcard * at the end to append in files.associations, unlike what is currently done.

So in the zopeneditor.datasets.<language>Datasets parameters, we would have the alternatives:

• either to define the LLQ, low level qualifier, of the MVS files: .COBOL --> *.COBOL for files.associations
• either define a pattern of MVS files by explicitly indicating a * character at the end of the pattern: .COBOL.* --> *.COBOL.* for files.associations