On 28/07/2020 4:48 am, Lionel B Dyck wrote:
Created several ISPF panels from DTL. The result is an ISPF panel with
attribute characters that are binary (hex) with examples being x'01' ,
x'02', x'05, x'0D', and more.
Copying these PDS members to an OMVS filesystem using cp works fine. The
data is NOT being copied as binary.
The problem/anomaly is copying the files from OMVS into z/OS dataset members
results in these members being corrupted with the single record being
broken into one, or more, records.
The most likely problem is that when you copy from dataset to file, line
end characters are being inserted at the end of every record. When you
copy back, line end characters are used to break the data back into
records, but the same character(s) exist in your panel definitions. Cp
cannot tell whether it is an inserted line end character or part of your
data.
Copying binary data as text is not guaranteed to give the correct result
after a round-trip. Depending on the data it can be almost correct or
even usually correct, but there is always a risk unless you can
guarantee that the line end characters do not exist in your data.
Options:
- Maybe cp has an option where it doesn't insert/remove line endings
e.g. like IND$FILE file transfer has separate options for binary and
CRLF. The data would look like one long record, apart form the
incidental line end characters in your data. This is likely to cause
problems for git in displaying data, merging etc. (assuming this is for
Zigi).
- Copy as binary. The best-simplest option, however it would also cause
merge etc. problems
- Use an escape character scheme for binary characters e.g. quoted
printable. This adds a processing step - you can't use regular cp
command - but it gives you data in git that is mergable and mostly
readable as text.
--
Andrew Rowley
Black Hill Software
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [email protected] with the message: INFO IBM-MAIN
