Re: Automated Job Processing

1 - "How" you check for the stream file can determine the intensity of the
process. For example using an api designed for the stream file system
will be less intensive than CPYFRMIMPF with an error trap.
2 - Using the FTP exit points aren't the answer. The login exit point is
just silly for this purpose. 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. 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.
3 - While originally designed for the use of people who sell virus
scanning packages for IBM i the QIBM_QP0L_SCAN_CLOSE exit point may be
very useful for this purpose and is a good bet.
4 - For our public facing ftp site we use GoAnywhere MFT. They have a
trap in there for just what you want. Perform this action upon receipt of
the file. It's a "make vs buy" decision.
5 - Processing an journal receiver is another possibility but I'm not sure
that would be any less intensive than option 1.


Rob Berendt