Trigger program written in RPGLE

bogeybetsy

560 pts.

Tags:

AS/400 administration

AS/400 errors

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

Asked: August 25, 2009 4:20 PM Last updated: February 20, 2010 12:21 AM

Answer Wiki

Last updated: August 25, 2009 5:45 PM GMT

philpl1jb54,090 pts.
History
Contributors
- Ordered by most recent
- philpl1jb54,090 pts.

Thanks. We'll let you know when a new response is added.

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

Discuss This Question: 7 Replies

BigKat Aug 26, 2009 2:47 PM GMT

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.

9,110 pointsBadges:

report
bogeybetsy Aug 27, 2009 7:11 AM GMT

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

560 pointsBadges:

report
bogeybetsy Aug 27, 2009 7:15 AM GMT

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?

560 pointsBadges:

report
Yorkshireman Aug 27, 2009 7:55 AM GMT

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

6,085 pointsBadges:

report
BigKat Aug 27, 2009 3:21 PM GMT

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.

9,110 pointsBadges:

report
Huguenot Feb 19, 2010 11:23 PM GMT

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

10 pointsBadges:

report
philpl1jb Feb 20, 2010 0:21 AM GMT

https://itknowledgeexchange.techtarget.com/itanswers/prevent-update-in-db2-sql-external-trigger-program/

54,090 pointsBadges:

report