1) I'm not sure. I was able to use recursive triggers on V3R1, but I used
ILE and had the program start a new activation group every time. (Slow, but
not soooooo slow) ILE RPG PROGRAMS are not recursive, procedures yes,
programs no. Since triggers are program calls I needed the new activation
group. Under this setup I don't see why there would be any maximum number of
recursions. Is there a max number of activation groups perhaps, but even so,
200 seems low.

2) It depends. Generally speaking yes you would need to use ILE (see above),
but if IBM played with static storage for the trigger programs then perhaps
not. This might be where the 200 max comes from, if IBM did some hack
programming then they might have said that 200 was more than enough. I do
recall asking several years ago (V2R3 timeframe) if we could write recursive
triggers in any language (read: non-ILE) and I was told yes, but when V3R1
came out this was not true. Perhaps IBM is delivering on an old promise.

3) I don't see a problem with this process, except: If you are concerned
with transaction integrity (commitment control) then the second (triggered)
update will not be in the same commit block as the first update, so if one
gets rolled back the other will not be rolled back.

4) If you update the new_rcd part of the trigger parameter then this new
record image will be written to the DB (V3R7 and beyond, not sure about
V3R2, I know this does NOT work in V3R1). The after update trigger should
then be fired, but I'm not sure that this will accomplish what you want.
What are you trying to do?

-Walden

-----Original Message-----
From: owner-midrange-l@midrange.com
[mailto:owner-midrange-l@midrange.com]On Behalf Of
jmoreno@militarycars.com
Sent: Tuesday, May 12, 1998 9:50 AM
To: midrange-L@midrange.com
Subject: ##EMailNumber 01-WNY-1832912 Recursive Triggers


Hello Everybody,

Have a number of SIMPLE questions regarding a trigger Implementation.

These are the questions, and hopefully your experiences can give me
 guidelines for the writing of the trigger programs.

1.-    I read in the v4r2 DB2/400 Programming Book that Recursive
        Triggers are supported and the maximum number of recursions is 200

        Question: Is this Recursion Supported in V3R2 and if it is
                            what is the maximum number of recursions ?

2.-   Because of the nature of the recursion ... Do I need to create
        an ILE program ?

        Is there a  Simple *AFTER Update, Recursive Trigger
        Example anywhere ?

3.-   I Only Need 1 Level Of Recursion........
        I have contemplated to have a *DTAQ  BATCH program
         running in the background to simulate the Recursive
         Update. Is there any problems with this approach ?

 4.-   Can I Just simply Update the NEW_RCD area
          in the *BEFORE Update Trigger and let the
          *AFTER Update Trigger Occur, eliminating the need for recursion ?

  Thanks for your response.


   Regards                                Jorge Moreno / Military Car Sales
/ Woodbury, NY

jmoreno@militarycars.com


 PS. David ... How about a  NEW archive of TRIGGERS and data base Issues ?



+---
| This is the Midrange System Mailing List!
| To submit a new message, send your mail to MIDRANGE-L@midrange.com.
| To unsubscribe from this list send email to MIDRANGE-L-UNSUB@midrange.com.
| Questions should be directed to the list owner/operator:
david@midrange.com
+---

+---
| This is the Midrange System Mailing List!
| To submit a new message, send your mail to MIDRANGE-L@midrange.com.
| To unsubscribe from this list send email to MIDRANGE-L-UNSUB@midrange.com.
| Questions should be directed to the list owner/operator: david@midrange.com
+---


This thread ...

Replies:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2019 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].