Re: Question about opening and closing files

Scott,

I was hoping you'd jump in with the voice of experience with alarm().

Any additional thoughts about the fact that trigger program usually
runs in *CALLER. I'm thinking you wouldn't want the signals stuff in
the trigger program itself.

I'm thinking you could put the the signal stuff, including the
procedure that handles the SIGARLM, in a service program that runs in
a named AG.

Have a third *NOPASS parm defined on the trigger program, have the
SIGALRM handling procedure call the trigger program passing the third
parm. which lets the trigger program know to close the files if they
are still open.

Charles

On Tue, Sep 9, 2008 at 2:39 PM, Scott Klement <rpg400-l@xxxxxxxxxxxxxxxx> wrote:

Hi Lim,

Are you saying that the alarm() api can actually wake up an in-active
program (ended with *inlr = *off)? That would be cool if this is true
:).

Yes, any signal (not just alarm) can be sent to code that's activated,
but dormant, in a job.

Personally, I have a program that does this. It runs as the user's
initial program when they sign on, and it sets up a signal handling
procedure for the SIGALRM signal, and installs an interval timer (with
the setitimer() API) to send SIGALRM every 60 seconds. (It also
registers a procedure to disable the timer when the activation group
ends.) The program then ends (I can't remember whether LR is off,
though... LR really has little to do with it, since it was compiled with
DFTACTGRP(*NO))

This program runs in it's own activation group, and the subprocedure
(the signal handler) wakes up every 60 seconds to check if there are new
EDI orders (Which is the purpose of this particular program). If there
are, it interrupts the user's 5250 session to tell them about the new
EDI orders. (it pops up a "window" so to speak)

If I want to disable this program, I simply reclaim the activation
group, since it runs in it's own AG, that won't affect anything else.

Anyway, while AG remains the loaded, the signal is still sent every 60
seconds, and it still runs the procedure, even after the program has
ended. The user can still run other things, and go about their work,
without even really knowing that it's there and running (until the
message pops up telling them about the new EDI orders, that is.)

Of course, if I had to do it over again, I'd probably use a Windows
program instead of a green screen RPG one, I'd just load it in the
system tray on their desktop... That makes more sense today, since I'm
trying to avoid writing more green screen apps, and hopefully they will
eventually reach a point where they don't sign on to 5250...

But, the point is... it's certainly possible to keep an RPG program
running in the background via signals.
--
This is the RPG programming on the AS400 / iSeries (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.