Trigger program written in RPGLE
I have a trigger program that have 3 files declared in F-Specs (no UsrOpn keyword). Everytime it ends, it sets the LR indicator on. Does the trigger program slow down processing when the trigger file is updated in a batch program? Should I remove the code that turns on the LR indicator? If yes, then what happens if there are multiple users - would I be eating up a lot of memory?
Software/Hardware used:
iSeries V5R4
Software/Hardware used:
iSeries V5R4
ASKED:
August 25, 2009 4:20 PM
UPDATED:
February 20, 2010 12:21 AM
Answer Wiki:
Yes, the trigger program will slow down the processing- it is in the processing stream.
When the batch program requests the event of the trigger from the database and the trigger is before,
the database calls the trigger program and waits until it's done before updating the record.
When the batch program requests the event of the trigger from the database and the trigger is after,
the database updates the file and then calls the trigger program and waits until it's done before returning to the batch program.
I'm sure you're right about *INLR and the overhead, if you are using this program a lot you will not want to set this on but remember this program will be locking the files and if you're not careful records!
Phil
To see all answers submitted to the Answer Wiki: View Answer History.
Are the trigger programs files declared for update? If just input (for validation) or output (for logging) , then you can remove the *inlr code without having to worry about record locks and if it is set to either a named activation group, or *caller, the impact to the system overhead will not be too bad either.
Thanks Phil and BigKat.
Yes the trigger program updates files – other files. These other files are used for inquiry programs only. They are only updated through this trigger program. According to the IBM PDFs, we should avoid setting *INLR on or closing and opening files repeatedly as much as possible. And I was shocked to see the exact opposite of that suggestion when I looked at the trigger program. This file to which this trigger program is attached is the main file being updated in a posting job. I’ve been revising the posting job programs so that they observe proper shutdown (you know, return only as much as possible without setting on the LR indicator if program is called repetitively). One routine that ran for 10 -14 minutes dropped to about 6-8 seconds. I’m planning on proposing to revise this trigger program too.
Allan
What I’m worried about is if I don’t set the LR indicator on, the files will be left open, ODPs remain, field storage remain, etc. , memory would be depleted. Because the file to which the trigger is attached is also updated in other interactive programs. If there are multiple users, is memory going to be a big problem?
Or,
Perhaps you want your trigger to write t o a data queue which handles your processing elsewhere. Minimise the action of the trigger and move the processing to one side.
Whatever – you should consider the ‘real time’ requirement of the process.
IS it convenient for it to be in-line – simple to code, or is it an actual business requirement? What difference does a couple of seconds delay make to the overall process?
You could gain efficiency and gather back cpu cycles, memory etc.
Analysis – design – planning – execution
Yorkshireman has it.
As long as the trigger program does not have to stop the insert/update/delete trigger event from occuring, and that there are no timing dependencies (the initial program would need to read one of the records that the trigger updates), write enough information to a data queue or staging file. The trigger will end very quickly (*inlr = *off) and another job can process the staged information into the inquiry files.
OVRDBF STAGEFILE EOFDLY(10)
Would allow you to run a program in batch that will wake up and check every 10 sec for data written by the trigger. Doing an ENDJOB OPTION(*CNTRLD) DELAY(20) on the batch job, would cause it to end if you used an DOU %SHTDN loop to read the file.
Can one of you tell me how I can prevent a write operation via the trigger process. I’m working on a file validation process.
Thanks
http://itknowledgeexchange.techtarget.com/itanswers/prevent-update-in-db2-sql-external-trigger-program/