RE: trigger program question

John,

The solution you provided will work perfect for what I want to do. It will
also keep the journal sizes from ballooning since I can re-create them each
night after the data harvest.

Thanks for your help and sample code!!!

-----Original Message-----
From: rpg400-l-bounces@xxxxxxxxxxxx [mailto:rpg400-l-bounces@xxxxxxxxxxxx]
On Behalf Of JK
Sent: Wednesday, August 27, 2008 10:00 PM
To: 'RPG programming on the AS400 / iSeries'
Subject: RE: trigger program question

Tim,

We use journaling to report any changes made to our customer's standing
merchandise orders. No appreciable degradation noticed, but we have a fairly
lightly-loaded system.

STRJRNPF FILE(ORDER_HDR ORDER_DTL)JRN(ORDJRN) IMAGES(*BOTH) OMTJRNE(*OPNCLO)


The dayend job runs the following code to harvest the day's changes from the
ORDJRN into the ORDJRN0 workfile which is passed to an RPG that filters the
good bits and distributes a 'change recap' to the plant's CSRs so they'll be
ready for the next day's run.

/* Create a new receiver */
CHGJRN JRN(*LIBL/ORDJRN) JRNRCV(*GEN)

/* Dump the J PR record of the CURRENT receiver into CurJrn0 *
DSPJRN JRN(*LIBL/ORDJRN) JRNCDE((J)) ENTTYP(PR) +
OUTPUT(*OUTFILE) OUTFILE(*LIBL/CURJRN0) +
OUTMBR(*FIRST *REPLACE)

/* Read CURJRN0 to find name of the PREVIOUS receiver */
RCVF DEV(*FILE)
CHGVAR &prvjrnrcv %SST(&joesd 1 10)

/* Deallocate CURJRN0 to allow other instances to run */
DLCOBJ OBJ((*LIBL/CURJRN0 *FILE *EXCL))

/* Now we know the name of the PREVIOUS receiver, dump its */
/* contents into ORDJRN0 */
DSPJRN JRN(*LIBL/ORDJRN) +
RCVRNG(*LIBL/&PrvJrnRcv *LIBL/&PrvJrnRcv) +
JRNCDE(*ALL) +
OUTPUT(*OUTFILE) OUTFILE(*LIBL/ORDJRN0) +
OUTMBR(&WSTIME) ENTDTALEN(500)

The ORDJRN PF uses IBM's QJORDJE record format. The RPG reads ORDJRN and
loads the 'joesd' column into an EDS defined for each PF (ORDER_HDR and
ORDER_DTL). 'joentt' tells whether the DS is a delete/add/before/after image
of the changed record. The tedious part is filtering out all the
non-reportable columns and compressing multiple changes so that the output
shows only the earliest 'before' and latest 'after' changes.

Whether you use journals or triggers you'll still have to identify _which_
columns to report on.

JK

-----Original Message-----
From: rpg400-l-bounces@xxxxxxxxxxxx [mailto:rpg400-l-bounces@xxxxxxxxxxxx]
On Behalf Of tim
Sent: Wednesday, August 27, 2008 8:02 PM
To: 'RPG programming on the AS400 / iSeries'
Subject: RE: trigger program question

Hmmm...never thought about that...

What kind of overhead would be created using this technique rather then a
trigger program?

Is it easy to get the information from the journals to display to the
users?
That is a function that will performed what could be on a daily basis.

Storage considerations?

Thanks again.


-----Original Message-----
From: rpg400-l-bounces@xxxxxxxxxxxx [mailto:rpg400-l-bounces@xxxxxxxxxxxx]
On Behalf Of CRPence
Sent: Wednesday, August 27, 2008 8:54 PM
To: rpg400-l@xxxxxxxxxxxx
Subject: Re: trigger program question

tim wrote:

I have a trigger program to log any changes in a file. Here is
snippit:

<<SNIP>>

I was wondering if this could be done a different way so that as I
add more files to this logging process, all I would have to do is
change a file name or something. I was thinking it would have
something to do with pointer logic, but not sure where to start.

Another perspective, rather than a reply to the RPG question, so
probably best just to ignore if not useful input for the situation.

Why not use journaling for logging? Use STRJRNPF for the additional
files that are added to the list of files to have logging. If all files
created in the library should be journaled, then create the QDFTJRN
*DTAARA object in that library.

Regards, Chuck