zos-files - Apply rules defined by .zosattributes to all dataset and uss file transfers

[FALLAI-Denis]

Hi,

Whether for uss files or for mvs datasets, the data encoding is not necessarily the one declared at the Zowe CLI profile level:

• Rexx files must be encoded in EBCDIC IBM-037
• C source files are most often encoded in EBCDIC IBM-1047
• JSON files must in principle be encoded in UTF-8
• PHP files must in principle be encoded in UTF-8
• JavaScript files must in principle be encoded in ISO-8859-1

The encoding conversion rules between the remote z/os system and the local system defined by the .zosattributes file should be applied to all mvs dataset and uss file transfers.

To date, they are only applied to upload transfers of multiple uss files (full directory transfer: dir-to-uss).

In all cases, for uss files, the encoding specified at the file level takes precedence.

A priority should be applied to take into account the encoding of conversions during transfers, from the highest priority to the lowest priority.

For remote encoding on the z/OS system:

• for USS files, encoding specified on the USS file (tagged and existing file)
• encoding specified explicitly on the command line (not encoding specified in profile)
• for USS files, default EBCDIC IBM-1047 encoding if not specified on the USS file (untagged file), nor on command line
• remote encoding specified in .zosattributes file
• encoding specified in the Zowe CLI profile used at the time of transfer

For local encoding:

• local encoding specified by the .zosattributes file
• UTF-8 encoding if .zosattributes file is missing

For job submit from local-file or stdin (upload equivalent):

• remote encoding specified in .zosattributes for local-file extension (reversibility of file download) or encoding specified on Zowe CLI profile for stdin of if no encoding specified in .zosattributes for local-files

For job output retrieving (download or view):

• always encoding specified in the Zowe CLI profile used at the time of retrieving

[FALLAI-Denis]

Hi,

The case of job submission or retrieval of job outputs is special.

A job contains JCL commands which must be recognized by the z/OS system, which only understands the IBM-037 EBCDIC, and user data (parameters, sysin) which must follow the default encoding of the site, which is the encoding defined on the Terminal 3270.

If you want operation identical to Terminal 3270 mode, then you must apply the encoding defined in the Zowe CLI profile used, which should be identical to the encoding declared on a Terminal 3270, even if it means using it locally on the command lines JCL characters that are not those that would be encoded in a data file.
For example, I use the EBCDIC IBM-1147 encoding on my Terminal 3270 and in my Zowe CLI profile, but I need to use characters in my JCL command lines that correspond at the binary level to the EBCDIC IBM-037 encoding: for example encode a "£" character where a "#" character is expected. On the other hand on my parameters and sysin I correctly encode my characters in EBCDIC IBM-1147, and if I want a "#" character in my data, I encode a "#" character in my parameters and sysins.

If the job is submitted from a local file, with a file extension, the conversion options declared in the .zosattributes file must be applied: compatibility between the download of the JCL file and the submission of this JCL file on z/OS which is the equivalent of an upload.
If the job is submitted from the client's stdin stream, the Zowe CLI profile encoding declaration must be used.

For the recovery of job execution outputs, you must use the encoding of the Zowe CLI profile to be compatible with Terminal 3270 mode.

[github-actions]

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