|
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
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.