Automatic codepage selection based on a special property in a JSON file

[plavjanik]

Is your feature request related to a problem? Please describe.

Our z/OS program outputs JSON files in EBCDIC encoding. The EBCDIC encoding can be different based on the user preference and needs (e.g. IBM-1140, IBM-284, IBM-1147...). We put that information as a first property of the JSON file:

{
    "codepage": 284,
    ...
}

If user has a different code page set in Zowe Explorer, it is necessary to change it manually to download the file correctly.

Describe the solution you'd like

Would it be possible to look at the "codepage" property in the JSON file and offer user automatic conversion and if user agrees then do such conversion automatically?

[github-actions[bot]]

Thank you for raising this enhancement request. The community has 90 days to vote on it. If the enhancement receives at least 10 upvotes, it is added to our development backlog. If it receives fewer votes, the issue is closed.

[traeok]

In Zowe CLI, we support a .zosattributes file where you can specify the local and remote encoding for file patterns that match a given glob. Would this feature satisfy your use case if Zowe Explorer would look for the presence of this file in an open workspace? It would involve creating a separate .zosattributes file with the file patterns and codepage information, but adding support for this file would establish feature parity between the two programs.

[plavjanik]

Hey Trey, thank you for the idea with .zosattributes. Is https://docs.zowe.org/v2.13.x/web_help/docs/zowe_zos-files_upload_dir-to-uss the best documentation about .zosattributes? Can it be applied to our use case?

We create our output files as member in z/OS libraries. Then user want to download that member in Zowe Explorer with correct encoding. Where would be the the .zosattributes file located? In the root of the current project? How the dataset would be specified? Can we specify that all member of datasets that end with this DSN pattern (**.ZLCOVER) have certain encoding? Is it possible to store this information to the library (e.g. as #ZOSATTR) so it is available to all the users and workspaces?

[traeok]

Hi Petr,

Unfortunately, the .zosattributes feature does not support data sets at this time. I believe that is the best source for how .zosattributes works.

Zowe CLI looks for the .zosattributes file in the root of the directory where the files upload dir-to-uss command is run - you can also specify its path by passing the --attributes parameter. However, this current implementation is located in our z/OS Files SDK and does not support Zowe Explorer, so the logic would need to be enhanced to enable this functionality.

When it comes to Zowe Explorer, it could look for this file in the active workspace folder (if it exists) when downloading or uploading. As Zowe Explorer leverages the Files SDK for upload/download operations, I will also follow up with the rest of the team to see if that functionality can be expanded to support Data Sets.

Ideally, the structure would be similar to how it is handled for local folders/files, except you could specify the Data Set patterns that apply for the first argument. Here's a quick example:

# In theory, this would download members in PUBLIC.DATASET.* as ISO-8859-1 and upload them as UTF-8
PUBLIC.DATASET.* ISO-8859-1 UTF-8

As for storing this information in a library, this could technically be implemented, but the member would have to be uploaded by the user ahead of time and the structure above would be a bit different (in that it would have member patterns rather than Data Set patterns). This would also require some refactoring in the Files SDK to look for such a member before downloading or uploading to the data set. It might be worth discussing this with the Zowe server-side teams to see if there's any value in coordinating a member name that could be leveraged from both sides.

[plavjanik]

Thank you for the explanation. We will document how to set the code page for the Zowe Explorer in the configuration manually so users of our product will get their data converted correctly.