There are so many layers of issues here ... If the data is "binary" (any or nearly any byte value is possible) then no approach that involves CRLF is going to work. Period. Software does not have a way to distinguish between a 0D0A that signifies the end of a record versus a 0D0A that just happens to appear in the data -- say a halfword of 3338 decimal.
If you preserve the RDW keep in mind that the Z is a "big-endian" machine: x'0050' represents decimal 80, but Intel is "little-endian": decimal 80 is x'5000'. You will have to account for that in processing the data. If the records contain decimal packed data there are not many programs in Windows that can process packed data. If there are character fields in the data then they are going to have to be translated from EBCDIC to ASCII in order to be generally usable. That's a whole topic of its own. I think without a real good understanding of the record conventions on both machines that success is unlikely. Here is how I have done this ftp> quote type i 200 Representation type is Image ftp> quote mode s 200 Data transfer mode is Stream ftp> quote site rdw 200 SITE command was accepted ftp> get zos.vfromat.file Then in my C++ code I read 4 bytes, decode the RDW accounting for the "endian" issue, and then read the rest of the record. Charles On Mon, 15 May 2023 18:24:12 -0500, Michael Oujesky <reflect...@oujesky.net> wrote: >Depend on what you need to do and there at least two levels to be addressed: > * How variable length records appear on Windows > * How to deal with SDW (spanned long record segments >If you want both BDW and RDW/SDW present on Windows at least two approaches: > * TERSE the file, binary transfer to windows, WWUNTERSE from >Watson & Walker) on windows (-V option removes BDW) > * FTP binary transfer from z/OS to Windows using //DD: and JCL to >force RDCFM=U >Regular FTP binary transfer with "SITE RDW" will give you the file >with just RDW/SDW (BDW is stripped off). Without the "SITE RDW", you >just get the data with no indication of where the record ends). > >Then there is the issue of how to re-combine the segments into the >full record length. ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
