|
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
As an Amazon Associate we earn from qualifying purchases.
This mailing list archive is Copyright 1997-2024 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.