On 03-May-2016 07:03 -0500, Rob Berendt wrote:
<<SNIP>>
2 - Using the FTP exit points aren't the answer. The login exit point
is just silly for this purpose.
Could be used, given there is a very specific convention for the
sender\sending; e.g. a convention of the specific directory that a
specific user must use for their PUT requests. I outlined a process
many years ago using Commitment Control [STRCMTCTL and the Notify Object
(NFYOBJ)] to inform a process that data from a file should be expected,
but there are likely other creative ways; I did not verify the same
capability with coding of either an activation group exit or a scope
message, for example as possible alternatives.
The FTP server request exit point has some potential but it is
designed for granting or denying permission. IOW, "will I allow them
to 'put' this file?". Not "Hey they put a file here, let's go process
it now." The risk is that the file may still be in process, or not
even started, when you try to post it.
Something that might assist for allowing use of the server-request
exit, is knowing that the start of the next request will be the end of
the prior request.? As well, the server could /allocate/ a pre-created
file and then notify of or initiate the background processor against
that file; the background job is prevented from starting against an
incomplete push\PUT of the data, until the deallocating of the object by
the server, either upon the start of the next request or upon
termination of that FTP session with the server.
Some people work around this by having the sender send two files. The
second file is just a flag. Process the first when you get the
second. Heck, if they're willing to go through that you might as well
have them use quote rcmd call mylib/postpgm
Your ftp exit point can ensure they use that and only that. I've
written some.
A second file sent can be of just one record; a record that is either
the text of the prior PUT request, or simply the name of the file used
as the target for the prior PUT request. An INSERT trigger on the file
that was the target of the APPEND [of the data from the one-record
file], could initiate the [asynchronous] post-PUT activity; a PUT vs
APPEND of the second file to trigger the action can be advantageous or
problematic, depending on the intentions, given the former effects a
clear, whereas the latter does not clear. In that way, there is no
/polling/ for a second file that gets created, nor the need to delete
that extra /file as flag/; creating\deleting an object is much more
expensive than for just a row.
If RCMD is used, then likely best that the requested action starts
the *asynchronous* processing of the file; i.e. best not to try to
perform all of the processing over the active communications session.
If done synchronous, then best prior to have set the second timeout
appropriately, to allow time for the synchronous processing to finish.
Thus more likely than QUOTE RCMD CALL ..., the use of:
QUOTE RCMD SBMJOB CMD(CALL MYLIB/POSTPGM)
midrange.com
