As a variant thought...
If your application code is in any way subject to change, you would do better to have it send you something to notify you. Is the program run inside a shell that could detect its exit? Even if only the shell could be changed, that might be enough.
One method is to have it set an event flag in a Common Event Flag block. That would work pretty well if they are on the same system. This won't work all of the time if there is a cluster and the two processes could possibly run on different nodes.
Another method would be to create a mailbox in your application that needs to know when the file is created and have the application write the name of the new file to the mailbox. This would work in a clustered environment.
A third possibility involves some complex lock code, taking out an interest lock on the directory but allowing anyone to write to it anyway. You would need some AST-level code to note that someone wanted to update the directory and use that code to notify you when someone actually does change something.
The problem I see with repeated scans of your folder has to do with file system caches, least-recently-used schemes, and resultant performance degradation, albeit by a small amount. Your frequent scan of the folder will force the file system to keep that folder in your directory cache when you might have better uses for that memory. Particularly if it is a large (heavily populated) folder.
Making the file creator notify you will obviate the need for any scanning, which is a GOOD thing with respect to file system caches on a busy system.
Just a variant thought on how to make it work faster.
Sr. Systems Janitor
