On Wed, 2008-08-27 at 20:59 -0500, JK wrote:

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.


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 */

/* Dump the J PR record of the CURRENT receiver into CurJrn0 *

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

Thank you. I need this one in my tool box. It is a lot clearer than
what I have been doing.

/* Deallocate CURJRN0 to allow other instances to run */

/* Now we know the name of the PREVIOUS receiver, dump its */
/* contents into ORDJRN0 */
RCVRNG(*LIBL/&PrvJrnRcv *LIBL/&PrvJrnRcv) +

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.

A while back--well around V3R1, so it is quite a while back--I
wrote a generic program to report the changes. The command
interface let the user select on changes in specific fields or
all fields except specific ones.

The deficiencies that I remember are ...

(*) When retrieving field definitions, it just assumed the layout
of the same-named file existing when the report was run. Now
I would try to do it better.

(*) Performance was abominable. For the customer's specific
purpose, it was overwhelmingly common to find precisely zero
changes to report, so that mattered little. Now, between the
hardware having advanced and RPG having acquired pointers and
it being easy to call strncmp(), I would suspect performance
to be merely very bad.

(*) The report layout was bulky and quite ugly. In the context,
that mattered not at all.

Frequently since then I have wished I had that utility, but I
have never wanted it badly enough to actually recreate it. There
must be something like this available somewhere, but I have not
stumbled across it. Suggestions welcome.


-----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
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


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

This thread ...


Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2020 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].