Hi Charles,
Why couldn't it? A trigger program is a *PGM object, you can call
programs from service programs.
Yes, I know that :)
By the time the signal handler ran,
the trigger program should be off the call stack, so recursion
wouldn't be an issue.
Recursion is what I was concerned about, since the service program
would've been called by the trigger, calling the trigger again would
create recursion.
You say it'd be off the call stack --- and that didn't occur to me.
But, you might be right about that. Actually, I don't know. I could
envision you being right about it -- but I can also envision you being
wrong, since even though the trigger isn't currently running in the call
stack, it's still activated in memory -- and I thought the fact that RPG
uses static variables in it's activation is the reason you can't
recurse...? Without trying it, I don't know which of those two ways of
thinking is the right one :)
But, even if you're right, there's still a chance that the signal
handler could fire in the blink of an eye between the time that the
trigger was called again (because of an update to a successive record)
and the time it resets the alarm() counter, thus still causing a conflict.
A callback would be simpler, IMHO, since it wouldn't have to deal with
reinvoking the whole program.
This mailing list archive is Copyright 1997-2026 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact
[javascript protected email address].
Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.