On Tue, 23 Feb 2010 15:38:42 -0600, McKown, John wrote:
>> -----Original Message-----
>> [mailto:ibm-m...@bama.ua.edu] On Behalf Of Donnelly, John P
>> Sent: Tuesday, February 23, 2010 2:58 PM
>>
>> We have a user who wishes to FTP a file from sending
>> server A to neutral server B and independent of A and B,
>> server C will logon to server B and read the file.
>>
>> Any suggestions as to how we might lock out server C until
>> the FTP from server A to server B is complete?
>
Generally, one end of an FTP connection is called a "server"
and the other is called a "client". Please unconfuse me.
>Two questions:
>
>1.What do you mean by "independant server C"?
>2.What do you mean by "lock out server C"?
>
>My guess, if you want server C to initiate the ftp, is to make sure that the
>dataset under consideration does not exist on server B except in the interval
>between it being sent by server A and before being gotten by server C. To me,
>this means that initially the dataset does not exist. Server A then ftp's the
>data, creating the dataset. Server C will, sometime after that, download the
>data and delete the file on server B.
>
>The above will allow server C to "poll" server B until such time as the
>dataset appears on B. And then delete the dataset so that it will not
>redownload the data. Note that if you are talking about a standard z/OS
>dataset on server B, then server C cannot download it while it is being
>uploaded by A due to the fact that server B will have it enqueued. If server B
>is not z/OS (maybe UNIX or even a z/OS UNIX file), then server A will need to
>ftp an "trigger" file to B once the real dataset is completely sent. Server C
>must then check to see if the "trigger" file is available. If it is, then
>download the dataset and delete it and the trigger. Otherwise, wait and try
>again later. We use this "trigger" method to send data to a Windows server
>which processes the actual file when the trigger file appears.
>
I do this quite successfully with UNIX files on server B with
no "trigger" file by exploiting the FTP RENAME command:
client A transfers the file to a temp name on server B
client A RENAMEs the temp file on server B to its
permanent name.
Client C polls for the appearance of the file on server B
under the permanent name.
Disclaimers:
o Server B is Solaris, not z/OS.
o Client C is a local process on server B, not a remote FTP
client. It polled not for existence of the file, but for
change in its timestamp.
UNIX rename() is preemptive, atomic, and nondisruptive to
open descriptors -- all excellent facilities ensuring that
client C never perceives the file to be nonexistent or
corrupted. The absence of ENQ ensures that the rename
will never fail because of lockout. For us, the timing
window for missing a revision is harmless; at worst, client
C gets a superior superseding instance.
-- gil
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html
