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,420 pointsBadges:

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:

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:

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:

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,420 pointsBadges:

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:

philpl1jb Feb 20, 2010   0:21 AM GMT

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

54,090 pointsBadges: