RE: FILE TRIGGER -- RPG400-L

See CPF4028, reason code 8. The system overrides any buffering the compiler
plans when you open a file with a trigger assigned to it. This file will
not be buffered. There is some other issue, apparently.

Dennis Lovelady
http://www.linkedin.com/in/dennislovelady
--
?If you can keep your head when all about you are losing theirs, it's just
possible you haven't grasped the situation.?
-- Jean Kerr

RPG itself buffers records, see the BLOCK f-spec keyword and the
SEQONLY parm of the OVRDBF/CHGPF

Some more info: "Blocking, Sequential Only, and the Effect on a
Program"
http://www-
01.ibm.com/support/docview.wss?uid=nas1d6738e1cd37e1f33862565c2007cef79
&rs=110

However, RPG blocking is only used in a limited number of places;
input-only or output-only and for example, a output file with a
uniquely keyed index/logical on it will never be blocked.

Bryan, if this file is opened OUTPUT-ONLY, then RPG blocking may be
your issue...

I suggest using the FEOD op-code with the (N) extender to force RPG to
flush it's buffers to the DB, without the penalty imposed by forcing
the DB to flush to disk (FOED without (N) or FRCRATIO(1))

HTH,
Charles

On Fri, Dec 3, 2010 at 11:35 AM, Christen, Duane
<Duane.Christen@xxxxxxxxxx> wrote:

Ken

Unless you are writing the blocking mechanism with your own code this

is not valid. The blocking is done by the DBMS and the trigger is fired
on each I/O.

IBM i 6.1 Information Center > Database > Reference > SQL reference >

Concepts > Tables > Triggers

"The trigger granularity defines whether the actions of the trigger

will be performed once for the statement or once for each of the rows
in the set of affected rows."

Set granularity is only allowed with an SQL trigger (CREATE TRIGGER)

and not with ADDPFTRG which calls a program for each and every record.

If you used set granularity for an SQL trigger I would still bet that

an HLL I/O operation would fire the trigger for that row, as RPG and
other HLLs don't I/O record sets, only one row at a time.

Duane Christen

-----Original Message-----
From: rpg400-l-bounces@xxxxxxxxxxxx [mailto:rpg400-l-

bounces@xxxxxxxxxxxx] On Behalf Of Ken Sims

Sent: Friday, December 03, 2010 9:52 AM
To: rpg400-l@xxxxxxxxxxxx
Subject: Re: FILE TRIGGER

Sorry Duane, but no, that does NOT make sense. When a file is
blocked, the program holds the records in its own storage and does

not

call database management until it is ready to write the block to the
file.

(This is all irrespective of when records are actually written to

some

type of permanant media.)

On Fri, 3 Dec 2010 08:08:10 -0600, "Christen, Duane"
<Duane.Christen@xxxxxxxxxx> wrote:

Ken;

Your whole statement is incorrect, sorry.

A trigger fires at one of two times. Before the record is

inserted/updated/deleted/read to the buffer or after the record is
inserted/updated/read from the buffer, irrespective of when the buffer
is "written" to disk/ssd/mainstore.

When you do a Write/Update/Delete/Read (in RPG or SQL or any language)

the trigger has been called either just after control is given to the
DBMS or just before it returns to the statement following the
Write/Update/Read. Assuming no obvious errors like no record exists to
be deleted/updated/read, writing a record with a duplicate key value in
an index in the table or built on index.

So barring certain errors (a trigger can throw errors to the DBMS

which can be percolated to the "calling" program etc...) when you
perform I/O to a table with a trigger defined for that I/O action the
trigger will have fired by the time control is returned to the
"calling" program.

Make sense?

Duane Christen

-----Original Message-----
From: rpg400-l-bounces@xxxxxxxxxxxx [mailto:rpg400-l-

bounces@xxxxxxxxxxxx] On Behalf Of Ken Sims

Sent: Thursday, December 02, 2010 3:49 PM
To: rpg400-l@xxxxxxxxxxxx
Subject: Re: FILE TRIGGER

Hi Bryan -

On Thu, 2 Dec 2010 13:59:51 -0500, "Bryan Mangan"
<bryanm@xxxxxxxxxxxxxxxxxxx> wrote:

I have file with a trigger program attached to it and when a record

is

written to this file it is suppose to execute the trigger. Once the
record is written it take a good 3 to 5 minutes to execute the

trigger.

Any ideas would be appreciated.

Is record blocking taking place? If so, the trigger isn't going to
fire until the program writes out the block of records (when the

block

is full, the file is closed, or the writing is forced), at which

point

it is going to fire repeatedly for each record in the block.

You do NOT need to mess with the force write ratio. The records

don't

have to be written to permanent storage, but they do have to be

handed

off to database management by the program.

Ken
Opinions expressed are my own and do not necessarily represent the

views

of my employer or anyone in their right mind.

Ken
Opinions expressed are my own and do not necessarily represent the

views

of my employer or anyone in their right mind.
--
This is the RPG programming on the IBM i / System i (RPG400-L)

mailing list

To post a message email: RPG400-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/rpg400-l
or email: RPG400-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/rpg400-l.

--
This is the RPG programming on the IBM i / System i (RPG400-L)

mailing list

To post a message email: RPG400-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/rpg400-l
or email: RPG400-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/rpg400-l.

--
This is the RPG programming on the IBM i / System i (RPG400-L) mailing
list
To post a message email: RPG400-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/rpg400-l
or email: RPG400-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/rpg400-l.