Thank you for your response, Charles, I preserve RDW and able to read record length field. I am also able to successfully covert EBCDIC to ASCII and Packed to decimal. So there is no issue with data conversion. As you correctly point out, intel/windows does not understand 0D0A. If it completely ignores 0D0A and treat entire file as single record, I am still ok with that as I can read records, based on record length field in RDW. My problem is, it adds random line break and so when I read each record in loop, it returns me records with record length between 1 to thousands. My records are in range of 150 to 250 length.
Thanks, Prashant -----Original Message----- From: IBM Mainframe Discussion List <[email protected]> On Behalf Of Charles Mills Sent: Tuesday, May 16, 2023 5:33 AM To: [email protected] Subject: [EXTERNAL] Re: VBS file read in windows - end of record issue 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 <[email protected]> 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 [email protected] with the message: INFO IBM-MAIN ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
