Thanks, Bradley, Carsten & Chuck,
I will look at the attached links in more detail later.
Bradley - for now we are going to try a free method even though I know you
give good support. I purchased GETURI at a previous job and we received
excellent support and the utility did what we needed.
I couldn't look at Carsten's link at the time since I am not a PROVip member
anymore :( However, I did misunderstand the RCVJRNE command used in the
IFSTOOL/MONIFS program. It has DELAY(*NEXTENT 60) which means it will
immediately grab each new entry but will wait up to 60 seconds before
starting again. It is not consuming CPU cycles and it is not only waking up
every 60 seconds. It does what we want.
Chuck - the link you sent was bang on what we want. Sam must have the same
contractor that won't do a QUOTE to fire off a job. However, our contractor
is sending a file to our system using PUT, always in the same directory, and
always with a temorary file extension of .TEMP. He will then do an FTP
rename of the file to a permanent file name. We are using a trigger on the
MONIFS file to look for only the RENAME entries - by the time we get this,
the entire file has been transfered and renamed.
Thanks all for all your help!
"CRPence" <CRPbottle@xxxxxxxxx> wrote in message
What are the /knowns/ for the use of the FTP PUT subcommand that will be
issued. For example is the same target directory always used, a file name
that is the same or that is generated from a known algorithm, only one
file per connection, etc.? The more static information that is available,
the more there exist options to limit polling and ease of coding. The FTP
exit programs can be used to establish a reaction to a request that is
going to occur. I suggest in the following link that by using a notify
object [NFYOBJ] of commitment control or an ALCOBJ in the exit program,
the end of the session can be determined to effect a response to the prior
requested activity in the session. There is also reference to the use of
file monitors with triggered action via the Management Central; a trigger
action of sending a message is shown, for which a break handling program
could be established as an active monitor in a background job, to act on
the received file.
A directory can be set to have its files journaled. A process that uses
the RCVJRNE to establish response to journal entries via an exit program
[established on that command invocation] can await activity without the
impact typical of polling. A process can use the RTVJRNE [or
QjoRetrieveJournalEntries API] to get the same information, but best when
coded as reactive to the specific FTP PUT activity rather than generically
via polling [which given the comment in the quoted text, I infer the
MONIFS is doing; except possibly against the audit journal.?].
Blair Hamren wrote:
We need to monitor the IFS in real time for new files received via
the FTP 'put' command. We have an application where a vendor's
machine is going to FTP us a file when a group of orders is deposited
at a wrapping station. We need to gather that information immediately
and print invoices at that wrapping station. Here is what the vendor
has stated as givens:
1. They will only FTP the file to the IFS.
2. They will NOT send a line to submit an iSeries command as part of
the FTP put.
We have looked at MONIFS command in IFSTOOL on www.easy400.net but
looking deeper in the code, it monitors the journal once a minute. If
I change this to look through every second, isn't this going to kill
Another option we may try is BVStool's FTPTOOL. The documentation
makes it look promising based on this sentence: 'Add "triggers" that
will run any command or program when certain FTP commands are used'
Any other ideas?