If I understand it correctly, your PDS member contains multiple records, with a chance of having x’15’ characters somewhere in the data. Here is how OCOPY works for such members:
- When you OCOPY such a member into a USS file in TEXT mode, each record is copied into a separate line. That is, extra newline (x’15’) characters are inserted into your data after each record, and they are indistinguishable from the x’15’ characters you had in the PDS members.
- When you OCOPY the text file back to the data set in TEXT mode, all those x’15’ characters become points where data is split into records. That’s where your data will get split on those x’15’ you initially had in your PDS member.
- If you change the OCOPY mode to BINARY, no x’15’ are added, that is, your data from the PDS member is copied as-is into the file. However, the file therefore won’t have any information about PDS record lengths; and since your PDS is variable-length, you can’t separate it back into records anymore (for a FB data set, you could split it every LRECL bytes). When you copy it back to the PDS member, x’15’ are preserved and no splits occur; thus all the data ends up being in a single record.
This all is a documented behaviour for OCOPY - see z/OS UNIX System Services Command Reference. You can try to exclude Git and just OCOPY your member to USS and back - and see if the problem persists.
The fundamental problem, however, is not in Git or OCOPY but is in the fact that EBCDIC newlines have the same character code x’15’ as you already have in the middle of your data. In a plain-text file you need a way to indicate line lengths somehow, hence newline characters. Even translating your data into ASCII on copy probably won’t help because x’15’ will be translated into ASCII newlines, too.
I’d suggest one of the following - depending on the nature of your data, different things may or may not work for you:
- Change the contents of the PDS member to never have x’15’ (e.g. for an ISPF panel, change the character codes for attribute bytes.
- Change the PDS to an FB data set or use a temporary FB data set and OCOPY in BINARY mode. This way, your PDS records will be padded on their way to USS, and will be split into records in exact same positions on their way back. The x’15’ characters won’t interfere with the process.