Re: Automated Job Processing

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)