Wouldn't a trigger program handle all of that for you? He would fire it "on insert".
I would use two programs... PGM1 would be attached as the trigger program and simply call PGM2, passing the trigger buffer. That way you can tweak the logic in PGM2 (if there's any) w/out detaching the trigger PGM1. This is relevant only if the file is often in use.
-----Original Message-----
From: RPG400-L [mailto:rpg400-l-bounces@xxxxxxxxxxxx] On Behalf Of Richard Schoen
Sent: Wednesday, September 12, 2018 8:28 AM
To: rpg400-l@xxxxxxxxxxxx
Subject: Re: run a program when a file changes
I think we need more specifics about the process and its timing before making a recommendation.
Wouldn't want to be clearing the file while records are coming in.
Maybe better to mark them.
Wouldn't want to process a record twice by accident. Might call for a flag field of some sort.
Or does the processing program simply delete records and it doesn't really get cleared with something like a CLRPFM or DELETE ALL.
Again, hard to say until we better understand the entire process at the 3000 foot level 😊
Regards,
Richard Schoen
Director of Document Management
e. richard.schoen@xxxxxxxxxxxxxxx
p. 952.486.6802
w. helpsystems.com
------------------------------
message: 5
date: Tue, 11 Sep 2018 22:08:49 -0400
from: Buck Calabro <kc2hiz@xxxxxxxxx>
subject: Re: run a program when a file changes
On Tue, 11 Sep 2018 at 21:44, Booth Martin <booth@xxxxxxxxxxxx> wrote:
Several random times a day a file is cleared and then populated again
through DDM . When that happens I want to automatically run a program
that updates another file.
A trigger is on rows, so using a trigger would run the program for
every row - not a good solution.
It seems to me as if a trigger should work.
The program that would get called has all of the logic to process records from file1 and put the right stuff into file2.
Put that same logic into a trigger, and when record 1 arrives, the trigger fires, processing the row, sending the right stuff to file2, etc.
That's simplistic, assuming the process doesn't need extensive commitment control or anything like that.
--buck
--
This is the RPG programming on the IBM i (AS/400 and iSeries) (RPG400-L) mailing list To post a message email: RPG400-L@xxxxxxxxxxxx To subscribe, unsubscribe, or change list options,
visit:
https://lists.midrange.com/mailman/listinfo/rpg400-l
or email: RPG400-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives at
https://archive.midrange.com/rpg400-l.
Please contact support@xxxxxxxxxxxx for any subscription related questions.
Help support midrange.com by shopping at amazon.com with our affiliate link:
http://amzn.to/2dEadiD
midrange.com
