Re: Detecting that a submitted batch job is ending from w/in an RPGprogram.

Thing you have to be careful with this design is your program checks and
finds something and then starts processing. The problem being that the file
may not have already been written. You catch it in mid write. That is why I
went to the journal entries because they are not written until the file is
closed. Anyway, just a heads up.

On Thu, May 21, 2009 at 7:54 AM, John Rusling
<jrusling@xxxxxxxxxxxxxxxxxxx>wrote:

Thanks for the feedback.

My original listener design read a file to see what folder(s) to
listen to and what action to take when 'something' gets dropped
in this folder. (file drops random and whenever)

As I'm formulating this though, I've dropped the 'read a file' piece
in favor of calling the listener program with parameters. (yesterday)

Thus, detecting ending in the program is less of a factor since, when
the pgm wakes up, it opens ifs folder, reads contents, closes folder,
wakes up again later... repeat. So, i'm less apprehensive about
the cleanup factor and simply using the ENDJOB command.
(added %shtdn too, didn't know it kicked in on endjob as well
as actual shutdown)

When I submit my listener pgm, I want to pass a jobname, program to
process the new file(s), sleep duration, folder to listen to, folder
to archive the file(s) to. Setting it up like this, I should be able
to have any number of listeners (w/ diff job names), listening to
any number of different folders, each can have different sleep intervals.

Ie, listenjob1 wakes up every 30 minutes, if files exist in folder1,
then processor1 pgm gets submitted to take care of...
listenjob2 wakes up every 2 hours, files exist in folder2, submit
processor2 pgm... etc...

My idea to drop an QUIT.TXT or ENDJOB.TXT file into the folder works
fine, but is impractical for wakeup calls over a couple minutes.
(didn't stop me from trying it though duh...)

Annywaay... to (rpg'er) me it seems simplest to do it this way.

If I was simply going to monitor a known directory for streamfiles
being deposited, I'd probably start with just reading the directory
entries rather than using either RCVJRNE or the Scan on Close exit
point. I'd only look deeper if other elements brought the need.

K.I.S.S.

Both journaling and scans have many additional considerations that
require thought. For basic monitoring of directory entries, thoughts
_might_ be limited to (1) does a new directory entry exist? and (2)
can I now do something with it, i.e., is anything else still busy
with it? Each loop through the directory entries gives a chance to
test end-status, BTW.

Great ideas! But more than I need or want to bite off right now.

But 'basic' monitoring for existence is a relatively minor task
compared to the capabilities of each of the choices. I'd simply
suggest going with complexity that's appropriate to the requirements.

Tom Liotta

--
This is the RPG programming on the IBM i / System i (RPG400-L) mailing list
To post a message email: RPG400-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/rpg400-l
or email: RPG400-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/rpg400-l.