We have customers (S)FTP(S)ing us data every day directly referencing the output of IFASMFDP with DCB=RECFM=U with no problem. From our standard instructions:
//SENDFTP EXEC PGM=FTP,PARM='(EXIT=12' //SYSPRINT DD SYSOUT=* //OUTPUT DD SYSOUT=* //SMFFILEA DD DSN=*.SMFDMP.DUMPOUT,DCB=RECFM=U,BLKSIZE=32760, // DISP=(OLD,DELETE) //SYSIN DD * ftp.pivotor.com userid password BINARY LOCSITE EPSV4 QUOTE EPSV PUT //DD:SMFFILEA Company.Dyymmdd.SysplexName.SystemName.SMFU BDWs and RDWs come through fine. (I think "quote epsv" is extraneous but it's been in the instructions forever. LOCSITE EPSV4 can be important for getting through some firewalls properly.) Scott Chapman On Thu, 15 Dec 2022 12:27:56 -0600, Paul Gilmartin <paulgboul...@aol.com> wrote: >>From Barry Merrill : >> ... >>But if the destination is for ASCII and SAS, you can use IEBGENER to create a >>copy of >>the data, on z/OS, but using RECFM=U, which ftp can't muck-up, and SAS on >>ASCII processes that data using RECFM=S370VBS, since the file has the BDW and >>RDW, so the downloaded file >>RECFM=U file can be read directly by SAS. >> >> // EXEC PGM=IEBGENER >> //SYSUT1 DD DSN=YOUR.VB.FILE,DISP=SHR,RECFM=U,BLKSIZE=32760 >> ... >I have tried to shortcut such a process at this point by: > // EXEC PGM=FTP > //SYSUT1 DD DSN=YOUR.VB.FILE,DISP=SHR,RECFM=U,BLKSIZE=32760 > //INPUR DD * > ... > binary > put DD:SYSUT1 ... > ... >Only to be dismayed that FTP apparently reads the DSCB and lets that dominate >attributes coded on the DD statement. > >This is a significant transgression of MVS conventions. > >-- >gil > >---------------------------------------------------------------------- >For IBM-MAIN subscribe / signoff / archive access instructions, >send email to lists...@listserv.ua.edu 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
