On 09/04/2016 05:50 AM, Tom Conley wrote:
> On 9/3/2016 7:49 PM, John McKown wrote:
>> On Sat, Sep 3, 2016 at 2:05 PM, Tom Conley <[email protected]>
>> wrote:
>
>>
>> Actually, if you do a z/OS to z/OS FTP, this is not true. The normal
>> setup
>> for such an FTP is to have the SENDSITE active. This causes the PUT
>> / GET
>> command to generate and send a SITE LRECL=... and so on automatically
>> for
>> you. And if you FTP to a UNIX file instead of a z/OS data set, this
>> is not
>> needed and the FTP "works correctly". The entire problem appears to
>> me that
>> you somehow want z/OS to just magically "know" what the DCB attributes
>> should be when data is coming in from something like a Windows or Linux
>> system. How? The other site is too "brain dead" to even understand the
>> concept. I can envision an FTP exit which do something like
>> autogenerating
>> a SITE command. But what should it be? In my case, for BINary
>> transfers, I
>> use RECFM=U,LRECL=0,BLKSIZE=27998 . For ASCII, my "standard" for true
>> text
>> files is RECFM=VB,LRECL=32756,BLKSIZE=32760. That works fairly well,
>> FOR ME.
>>
>
> Try transferring a VB file to a VB file with a z/OS to z/OS transfer.
> If you don't have a preallocated target, and you don't use a SITE
> command, you'll get the defaults, usually FB80, hacking your VB255
> file to bits. Oh, and don't forget to type in MODE B and TYPE E or
> else your VB records are just strung together. It's a freaking mess.
> WAY too much manual intervention.
>
> Regards,
> Tom Conley
>
It's not really the fault of the z/OS implementation of FTP that FTP
sucks on files with MVS block and record structures. The problem is
that FTP protocol was originally designed to transfer either binary or
text files on UNIX operating systems that only supported stream I/O and
which didn't understand the concept of physical records and physical
blocks being significant to applications, and where the only way to
simulate such concepts was with reserved in-stream separator characters,
or with logical record/block length conventions that may be understood a
specific application, but not by the File System. On such systems, with
no Operating-System-level standards or enforcement, there's no way an
FTP client or server could deduce that a local file was intended to have
any internal structure more complex than the
system-dependent-EOL-delimited line structure of a text file.
Any attempt to enhance FTP to fully support MVS data management concepts
will of necessity be a kludge to the FTP protocol, and guaranteed to be
more complex, especially when one of the parties is non z/OS and
parameters must be manually supplied via "SITE" or "QUOTE SITE". The
best one could ever hope for is that at some point a z/OS to z/OS
transfer might become smart enough to automatically send all the
necessary data set allocation and data management attributes so that
this complexity would be completely hidden for z/OS to z/OS FTP
transfers at compatible levels of z/OS.
Joel C. Ewing
--
Joel C. Ewing, Bentonville, AR [email protected]
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [email protected] with the message: INFO IBM-MAIN
