CRLF added at end of every data set when downloaded from the mainframe

[adam-wolfe]

Describe the bug

When either downloading or viewing a data set (or using the Get.dataSet SDK function), an extra newline/crlf is added at the end of the response.

For example, if a data set contains one record: "TEST", the Get.dataSet function will return "TEST\r\n" (or "TEST\n" on Linux systems). In most cases, this doesn't really matter, however it also affects how data sets appear in Zowe Explorer. As a caveat, if a user opens a data set and then saves it using Zowe Explorer, the extra line does not get added to the data set on the mainframe. See zowe/zowe-explorer-vscode#2169.

This affects data sets and spool files, not USS files.

If it is safe to assume that a carriage return will be at the end of every record, including the last record in a data set, should we handle this differently? Alternatively, would it make more sense to do something on the Zowe Explorer side?

Expected and actual results

Describe your environment

Additional context

[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.

[awharn]

To provide additional information, we are currently displaying exactly what is being returned from the z/OSMF REST API. When downloading data-sets via Postman and cURL, they also return the extra newline at the end of those files. Specifically, it returns a line feed character, which our Node APIs convert to a carriage return followed by a line feed for Windows.

We could remove the last line feed from each downloaded file, but if we were to do that, and z/OSMF were to change their behavior, we may lose lines that should be present. Additionally, the only editor I found that doesn't display the extra line was Vi/Vim. Notepad, Notepad++, Postman, Nano, and XXD all showed the new line.

[JTonda]

Consider:
Opening an enhancement request with z/osmf
Adding optional parameter to the sdk (which ZE would utilize)
Adding additional tests to verify that there is no data loss

[adam-wolfe]

Given that this has no real impact to data sets uploaded to the mainframe, I think it makes sense to take no action from the CLI/SDK side at this time.