× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.



Patrick,

You may be able to see the Calling process in the parameters that IBM 
passes you in the trigger program.

In the MAPICS sample trigger program that I've used extensively for 
Integrator programming, the following parameters are passed in by the 
operating system when the trigger fires:

Parameter   Description                        Usage  Size  T 
---------   ---------------------------------  -----  ----  - 
P#TRBF      Trigger buffer                       I 
P#TBLN      Trigger buffer length                I       4 
            Communication data area: (ZTRIGCOMM) 
P#CLID      Caller ID  (position 1 - 8)          I       8 
Client processing parameters: 
P#TSTK      Task token (position 9 - 18)         I      10 


MAPICS uses the ZTRIGCOMM data area to indicate whether the program that 
causes the trigger is the "Client" or not.  If the ZTRIGCOMM data area 
contains the value *CLTPRC, then the trigger program knows that the 
calling process was the MAPICS Client.  If it does NOT contain that value, 
then it can route the processing differently, based on whatever expected 
programs might cause the trigger.  It includes a catch-all called *COMMON 
to pick up things like DFU.   Maybe in your program (upon the initial 
WRITE) you could set a data area to a certain value (like BYPASS).  If the 
value of the dataarea is BYPASS, it could skip the routine that adds the 5 
more records.  Upon the last of the first 5 records that you add, reset 
the data area to blank.   Then the next User insert to the table would 
start over again and cause the first write and the next 5 records could be 
added by you. 

I may be rambling, but I think my concept would work.  I have not done 
something specifically like this, but I believe I've outlined an idea that 
can work.   If what I said doesn't make sense, feel free to contact me 
offline and I'll try to explain what I'm thinking.
Either way, good luck with it - a neat idea.
 

Michael G. Ellis
Information Systems International, Inc.
A Global ERP Consulting Firm
815-398-1670 x23
 
Choose ISI consultants to ensure consistently top quality implementation 
services at all levels of your organization.

"The Leader must himself believe that willing obedience always beats 
forced obedience, and that he can get this only by really knowing what 
should be done.......Also he must be ready to suffer more hardships than 
he asks of his soldiers, more fatigue, greater extremes of hot and cold. 
-- Xenophon

message: 9
date: Thu, 9 Feb 2006 16:43:54 -0500
from: "Patrick Shrader" <pshrader@xxxxxxxx>
subject: [MAPICS-L] Trigger programming question

What's the trick to keep a trigger program from acting on its own
results?

I have an insert trigger applied to the customer item cross reference
file (to update all the like accounts with the same info), but when I
change the customer number and insert a record, the trigger fires again
and wants to check the new record's validity. I realize that it is
calling itself recursively, but how can I stop this?

I've created the trigger with this command:
ADDPFTRG FILE(AMFLIBP/MBBIREP) TRGTIME(*AFTER) TRGEVENT(*INSERT)
PGM(PATL 
IB/TRGMBBIREP) RPLTRG(*YES) ALWREPCHG(*YES)


And with ALWREPCHG(*NO) as well.

I want the system to first insert record keyed by the user, then kick
off my changes adding another 5 records to the MBBIREP file. However,
that's when I get the recursive call. I want the trigger to only run
when the original entry is made, not the entries created by the trigger
file. 

I'm probably overlooking something simple, but would appreciate any
hints you might have.

Thanks,
Patrick

As an Amazon Associate we earn from qualifying purchases.

This thread ...


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

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.