The question I have is what clean up would a NEP need to do to close gracefully?
A NEP shouldn't sleep/dlyjob in the middle of processing a transaction, when a NEP goes to sleep it should be in a state that would allow for a fairly clean end. Yes you may have files open etc... but all processing for a transaction should be complete, and if you use %SntDn between transactions and/or at recoverable boundaries within a transaction you should be able to shut down cleanly then. Throw in appropriately implemented commitment control and I can't imagine (I'm sure someone can) a situation in which killing the NEP, at any time, would be a problem.
Duane Christen
--
Duane Christen
Senior Software Engineer
(319) 790-7162
Duane.Christen@xxxxxxxxxx
Visit PAETEC.COM
-----Original Message-----
From: rpg400-l-bounces@xxxxxxxxxxxx [mailto:rpg400-l-bounces@xxxxxxxxxxxx] On Behalf Of rob@xxxxxxxxx
Sent: Thursday, May 21, 2009 8:10 AM
To: RPG programming on the IBM i / System i
Subject: Re: Detecting that a submitted batch job is ending from w/in an RPG program.
That exit program is unlike any other's I've seen. Like you said it is only executed when the command is executed. Which brings us back to the NEP. A useful parameter, but just not in the context of avoid a NEP.
One of the problems with using a NEP to read a directory and post a file based on it's existence is that the file may exist, but still be in the process of being wrote to. We ran into this problem when trying to use ftp exit points to trap that a file has been put and should now be posted.
The ftp exit points were designed to check permission, not process data that's already been posted. Think of it as the exit program to check stream file open's, not close's. So, in FTP land, we did all sorts of strange stuff like after you PUT the real data you PUT a dummy file and we flagged that as go process the real data. Or you ran the RCMD to post the data. Some customers were flexible - others told us to go defecate in our hats and pull it down over our ears.
Rob Berendt
--
Group Dekko Services, LLC
Dept 01.073
Dock 108
6928N 400E
Kendallville, IN 46755
http://www.dekko.com
From:
Tom Liotta <qsrvbas@xxxxxxxxxxxx>
To:
rpg400-l@xxxxxxxxxxxx
Date:
05/20/2009 06:23 PM
Subject:
Re: Detecting that a submitted batch job is ending from w/in an RPG
program.
Sent by:
rpg400-l-bounces@xxxxxxxxxxxx
rob wrote:
- Receive Journal Entries exit program. Wait, where is this exit
program?
Rob:
RCVJRNE EXITPGM() -- it's a parameter on the command.
The command includes some selection criteria and other parameters
that should help in making the choice between the command or the
scan exit point, if those are the choices.
RCVJRNE is only going to associate an exit program with objects
related to that journal and only for as long as the command
executes. The Scan on Close exit point is associated with everything
in the root file system and all processes accessing the root file
system (more or less, and depending on configuration).
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.
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.
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
midrange.com
