Trigger program written in RPGLE

560 pts.
Tags:
AS/400 administration
AS/400 error messages
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

Answer Wiki

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

 
There was an error processing your information. Please try again later.
Thanks. We'll let you know when a new response is added.
Send me notifications when members answer or reply to this question.

REGISTER or login:

Forgot Password?
By submitting you agree to receive email from TechTarget and its partners. If you reside outside of the United States, you consent to having your personal data transferred to and processed in the United States. Privacy
  • BigKat
    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.
    8,010 pointsBadges:
    report
  • bogeybetsy
    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
    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
    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
    5,580 pointsBadges:
    report
  • BigKat
    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.
    8,010 pointsBadges:
    report
  • Huguenot
    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
    http://itknowledgeexchange.techtarget.com/itanswers/prevent-update-in-db2-sql-external-trigger-program/
    report

Forgot Password

No problem! Submit your e-mail address below. We'll send you an e-mail containing your password.

Your password has been sent to:

To follow this tag...

There was an error processing your information. Please try again later.

REGISTER or login:

Forgot Password?
By submitting you agree to receive email from TechTarget and its partners. If you reside outside of the United States, you consent to having your personal data transferred to and processed in the United States. Privacy

Thanks! We'll email you when relevant content is added and updated.

Following