Look at the OCOPY in Z/Os Unix services there is a parameter to fix CRLF ....
On Thursday, March 19, 2015, Kevin Landin <klan...@central-insurance.com> wrote: > We FTP a zip file from a vendor as binary to a z/OS Unix file. We then > expand the zip file using the JAR command: > > jar xf input.zip > > Since the members were zipped as ASCII, the unzipped members in the z/OS > Unix file are also ASCII. Reviewing the unzipped members shows that each > record ends with a CR/LF (0x0D and 0x0A). > > The OCOPY command was used to copy the z/OS Unix file to a z/OS data set > and perform ASCII to EBCDIC translation. > > //SYSUT1 DD PATH='/u/zkdl/input.txt', > // PATHOPTS=(ORDONLY),PATHMODE=SIRWXU > //SYSUT2 DD DSN=output.dataset, > // DISP=(NEW,CATLG),SPACE=(TRK,(45,15),RLSE), > // DCB=(RECFM=FB,LRECL=215) > //* > //SYSTSPRT DD SYSOUT=* > //SYSTSIN DD * > OCOPY INDD(SYSUT1) OUTDD(SYSUT2) TEXT CONVERT((BPXFX311)) TO1047 > /* > > This works fine, except each record on the output dataset has a CR (0x0D). > Using ICONV gave the same results. > > Besides editing the file and removing the CR, is there a way to prevent > the CR from being written to the z/OS data set during the translation? > > Thank you. > > ---------------------------------------------------------------------- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu <javascript:;> with the message: > INFO IBM-MAIN > ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
