Re: Question about opening and closing files

Hi Lim,

Are you saying that the alarm() api can actually wake up an

program (ended with *inlr = *off)? That would be cool if this is

:).

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

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

EDI orders (Which is the purpose of this particular program). If

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

trying to avoid writing more green screen apps, and hopefully they

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.