On Tue, 16 Sep 2014 11:40:58 -0700, Richard Pinion wrote:
>First, I'm not in the TCP-L group. Second this is a general question
>regarding the behavior of the z/OS
>FTP client. Third, I do not read every IBM manual cover to cover and commit to
>memory. In this case,
>I should have done number three.
>
>We are running z/OS 1.13. Executing the FTP client via a batch job, as shown
>below.
>What results would you expect if XYZFILE1 were empty (SMS managed data sets,
>so we would have a valid EOF),
>and the remaining data sets were not?
>
>0 bytes were transferred because the first data set in the concatenation was
>empty. Googling this example, yielded,
>
>Restrictions:
> ...
>To prevent transferring data from an empty file, FTP checks whether the first
>file in a concatenation series is empty and allocates an empty data set. No
>data is transferred.
>
(That appears in:
http://pic.dhe.ibm.com/infocenter/zos/v2r1/topic/com.ibm.zos.v2r1.halu001ddname
support with FTP
z/OS Communications Server: IP User's Guide and Commands
SC27-3662-00 )
But empirically I discover:
o If the first catenand is an empty instream data set, the remaining catenands
are
transmitted regardless.
o If the first catenand is an empty UNIX file, the remaining catenands are not
transmitted.
o Otherwise, catenands following an empty catenand interior are transmitted.
Can anyone supply a rationale for these behaviors? "To prevent transferring
data from
an empty file" does not count as a rationale. Double credit if the "anyone" is
an IBM
employee. Triple if not nearing retirement anyway.
I'm tempted to submit a very discourteous RCF. There's no hope of getting an
APAR,
is there?
-- gil
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [email protected] with the message: INFO IBM-MAIN
