I have an EBCDIC file that contains various other non-displayable characters that I know won’t round trip from z/OS to GitHub and back. One of the characters contained in my file is a x’14’ which USS sees as a line feed. I don’t need to edit the file in USS. So I OCOPY it in from a PDS member, where the x’14’ means nothing. My .gitattributes file has a line to say all these sorts of files are binary:
I commit and push the file to GitHub and if I look at it I see that it has been treated as binary, and is not viewable. If I then clone the repo back, then OCOPY the file back to the PDS, the line has been split at the x’14’.
According to the git doc for binary - Git will understand that the files specified are not text, and it should not try to change them.
Has the Rocket team tried to round trip a binary file containing a x’14’? Did you see the same results?
I have not reproduced it yet, but I will try on the same version of git again.
Thanks for the prompt response. To answer your questions:
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:
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:
Thanks Vladimir, I was looking at this again last night and had wondered if it was OCOPY that was splitting the line. Thanks for your explanation, that really helps. Unfortunately the x’15’ in the data is put there by some tool that generates the file. The tool is working with PDS so the x’15’ does not matter. We are investigation storing the file in a modern SCM like Git or RTC. We have already approached the developer of the tool about using FB instead of VB and will continue to investigate what will work.
Again, many thanks for your help!