Re: RNX8888 - the significance

In a message dated 7/17/2004 1:39:01 PM Eastern Daylight Time, 
jamesl@xxxxxxxxxxx writes: 
> You're welcome, but of course it's related to the content of the message:
> 
> Premise 1, recursion is defined as the act of a program, directly or
> indirectly, calling itself. If the former, it is direct recursion; if
> there are intervening programs, it is direct recursion.
> 
> Premise 2, if a trigger program initiates a change to a file for which
> it is, itself, a trigger program, the I/O runtime will, in processing
> the change, call the trigger program, resulting in an indirect recursion.
> 
> Premise 3, RPG, even ILE RPG, although set up to handle recursive
> procedure calls, is not set up to handle recursive external calls.
> (Uncontrolled recursion, particularly with external calls, will eat up
> machine resources until the OS crashes). (I nearly did that with a
> coding error in a recursive procedure call, in a recursive descent
> parser written in ILE RPG.) So instead, it abends the program with an
> error message.
> 
> Conclusion: Since a trigger program across multiple files, that can make
> changes to files for which it is a trigger program, can initiate
> indirect program-call-level recursion, which the RPG runtime traps as an
> exception, the content of the message is an exact description if what
> happened (even if, like most error messages, it doesn't attempt to
> explain why). But that behavior can, itself, be useful: if you are using
> "after" triggering to initiate side effects (remember, "before"
> triggering is for vetoing) across several files, it will keep the
> trigger program's own changes from initiating any side effects (which
> might lead to slow response times at best, and uncontrolled recursion
> leading, in turn, to a system crash at worst), and if you specifically
> monitor for the message, you can use it to initiate additional side
> effects (as if it really were doing recursive triggering).
> 
> Recursion is a very useful tool. It can be used to produce elegant
> solutions to classic, recursively defined mathematical problems (such as
> the Fibonacci numbers) and to control program flow in situations (like
> parsers) where purely iterative control is difficult. Indeed, in at
> least one language (LISP), it is preferred over iteration as a control
> structure. But it is a tool that must never be allowed to run wild.
> 
> C L A S S   D I S M I S S E D !
> 
Aye, Aye Sir. May I be allowed the liberty to present the instructor with an 
apple for a very lucid and precise explanation. Now I know how to repair a 
piece of "bad code" and keep it from eating resources.

Jack Derham
Direct Systems, Inc.
Marietta, GA