|
Jderham2@xxxxxx wrote: > > Thanks James! Appreciate the information. That helps clear up some questions > but it certainly doesn't seem to be related to the content of the message. 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 ! -- James H. H. Lampert Professional Dilettante http://www.hb.quik.com/jamesl http://members.hostedscripts.com/antispam.html http://www.thehungersite.com Help America's Passenger Trains. http://www.saveamtrak.org Read My Lips: No More Atrocities!
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.
midrange.com
