> I believe that in this case FTP client either "re-allocat[ed] a > clone" or bypassed the allocation and used UNIX system calls to > access the related path.
May be. Do you see allocation messages? Do you see any references to SYS00001 or similar? (You might have to try from a batch job to make it clearer.) I don't even know: if a regular old (let's say COBOL) program reads from a DD allocated to a zFS path with LRECL=40 in the DD, does it see 40-byte records? Charles -----Original Message----- From: IBM Mainframe Discussion List [mailto:[email protected]] On Behalf Of Paul Gilmartin Sent: Thursday, May 20, 2010 4:17 PM To: [email protected] Subject: Re: FTP Get Blocked by ISPF EDIT On Thu, 20 May 2010 14:16:05 -0700, Charles Mills wrote: >I believe FTP by DD name applies to both GETs and PUTs but only to the >client end. You cannot do a PUT to or a GET from a DD name (only the >converse). OTOH, I believe it does use the DD allocation rather than >re-allocating a clone. > I just tried ALLOCATE DD(PUTDD) SHR DSN('SYS1.MACLIB(SPLEVEL)') LRECL(40) FTP ... PUT //DD:PUTDD ... ... I stand corrected; the overriding DD attributes were honored and the records were split into 40-character lines. TRANSMIT is a horse of a different choler. I tried: TRANSMIT FOO.BAR FILE(PUTDD) OUTDSN(TEMP.FOOXMIT) ... and watched as IEBCOPY messages scrolled by for the unload of the entire SYS1.MACLIB. Wrong, wrong! "Using Data Sets" makes it very clear that when a data set name and member are specified, the allocation is Physical Sequential. TRANSMIT ought to have simply OPENed a DCB for PUTDD and made an XMIT package of whatever it found on a QSAM read. IEBCOPY shouldn't enter the picture. (BTW, how can I interrupt IEBCOPY in this situation. PA1 gave me a READY prompt, but when I pressed ENTER the IEBCOPY messages resumed. I finally resigned myself to pressing ENTER until they finished scrolling by.) Another experiment: allocate dd(putdd) filedata(binary) path('/etc/services') recfm(f) lrecl(40) blksize(4000) FTP unixhost ... QUOTE TYPE I PUT //DD:PUTDD foolevel ... I would have expected that QSAM reads from PUTDD would have yielded 40-character records (some with internal NLs) and the ASCII transfer by the client would convert to ASCII and insert <CR><LF>. Instead, the original record structure was preserved with a <LF> inserted after each. The allocation parameters FILEDATA(BINARY) LRECL(40) were ignored: ... # Network services, Internet style^M #^M echo 7/tcp^M echo 7/udp^M discard 9/tcp sink null^M discard 9/udp sink null^M systat 11/tcp users^M daytime 13/tcp^M daytime 13/udp^M ... I believe that in this case FTP client either "re-allocat[ed] a clone" or bypassed the allocation and used UNIX system calls to access the related path. ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
