No, not exactly.
What you can do is attach a journal to an IFS directory. It's possible
to have an NEP that sits on the RCVJRNE API -- with the proper
parameters, it can cause your program to react immediately upon
something happening to an IFS file.
However, there are some caveats, too. Often programs will open a file
to create it, then close it without writing any data, then open it again
later to write the data, then close it again... so this makes it
really hard to detect when the program is actually done with the file.
Other times, programs will create the file under a different name, do
their thing, then rename it to the proper name when they're done.
Again, very hard to detect when they're done with the file.
I took my best shot at writing a program to handle it properly, it
involved delaying for a second or two after the file was created, then
trying to get exclusive use of the object (by using the open IFS API
with O_SHARE_NONE). This was mostly successful, but certainly can be
fooled... If you'd like to check out my attempt, I put it into an
article with downloadable code, here:
There's also a utility available from Easy400.net called MONIFS that I
think works similarly? But haven't tried it, myself.. might be worth
looking into as well.
On 2/12/2014 4:18 PM, Jerry C. Adams wrote:
This is just a matter of curiosity. I have applied triggers to database
files, but I was wondering if it was possible to apply a trigger to a
non-QSYS folder in the IFS? That is, possible application, which I'm
thinking about, is if a file is dropped into \FolderJA could I have a
trigger program that would automatically be invoked to process files in the
In the past I just had a NEP that checked every, oh, 15-60 minutes to see if
there was anything there.
Jerry C. Adams
IBM i Programmer/Analyst
You are the result of 4 billion years of evolutionary success. Act like it.