Hi Charles,
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.
Sorry, I didn't mean to say that signals would be a good way to close
files in a trigger. I was merely responding to Lim's question about
whether it's possible to use a signal to awaken a program that's dormant.
I haven't tried using this signal stuff in a trigger, so I can only
guess at how it'd work in this trigger situation.
Personally, for the trigger situation, I'd work very hard to try to find
a way to change the application so that closing the files is not
required. I'd try to find a way to make it acceptable to keep the files
(used by the trigger) open all of the time. If that's not a
possibility, I'd write the trigger so that it sends it's updates (that
need to be made to the file) to a data queue, and I'd have a "server
job" running in batch that makes the actual updates to the file. That
way, if you needed the file to be closed for a RGZPFM or similar
purpose, you could end the batch job temporarily, do the work, then
restart the batch job.
But, the signal approach certainly MIGHT work... You'd use alarm()
with a timeout value right before the trigger ends. (Maybe 30 seconds?)
Have the alarm handler close the files if they're open. Each time the
trigger is called again, reset the alarm to 30 seconds again, so that
the close routine is only called if the trigger doesn't fire for 30 seconds.
But, I don't know what would happen if another program in the job calls
the alarm() API. Would it reset the alarm handler for the trigger?
what sort of problems would that cause?
Also, I have no idea what happens if you try to use signals in the
default activation group. Since triggers are usually set up with
ACTGRP(*CALLER) (to make them work properly with commitment control)
interesting things could happen if signals don't work properly in the
default activation group. Again, I haven't tried them, they may work fine.
So there's a lot of "what ifs" in my mind -- before I could really
recommend signals for this particular scenario, I'd want to do more
experimenting and testing, etc.
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.
That would solve the activation group issue, though you'd need some way
for the srvpgm to communicate to the trigger that it has to close it's
files. (A Callback procedure would work).
I don't understand your *NOPASS idea -- the service prgoram can't call
the trigger program, since the service program is invoked by the
trigger, isn't it?
But, I still don't know what would happen if another program int he job
called alarm() or changed the signal handler for SIGALRM.
midrange.com
