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 with the message: INFO IBM-MAIN
