On Thu, 19 Mar 2015 09:44:56 -0500, Kevin Landin 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. >
After the jar command you could run this command: tr -d "\r" <input.txt >input_tr.txt and then refer to input_tr.txt instead of input.txt in the JCL. Bill ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
