RE: Handling Record Change Journal Entries

["Jim Oberholtzer" <midrangel@xxxxxxxxxxxxxxxxx>]

What happens if the other side is not IBM i?  


--
Jim Oberholtzer
Agile Technology Architects

-----Original Message-----
From: MIDRANGE-L <midrange-l-bounces@xxxxxxxxxxxx> On Behalf Of Musselman,
Paul
Sent: Friday, January 04, 2019 12:55 PM
To: Midrange Systems Technical Discussion <midrange-l@xxxxxxxxxxxx>
Subject: RE: Handling Record Change Journal Entries

You could also use Remote Journaling (with the duplicated receivers on both
ends), then RCVJRNE on the receiving end.  Gets the data to a 2nd machine
'free' (remote journaling is at the 'system' level).  Then you can read the
journal entries and do what you will with the data.

Paul E Musselman
PaulMmn@xxxxxxxxxxxxx

-----Original Message-----
From: MIDRANGE-L <midrange-l-bounces@xxxxxxxxxxxx> On Behalf Of Rob Berendt
Sent: Friday, January 04, 2019 1:28 PM
To: Midrange Systems Technical Discussion <midrange-l@xxxxxxxxxxxx>
Subject: RE: Handling Record Change Journal Entries

I would NOT interpret any of Jim's comments as saying he is not advocating
triggers.  Instead I would interpret them as saying this:

Instead of this:
RPGTRIGPGM
   Get trigger parms
   process the parms and do nifty stuff like notify inventory shortages,
duplicate data to OLAP remote site, email thank you letters, etc

You would do this:
RPGTRIGPGM
   Get trigger parms
   Write parms to data queue

RPGDTAQPGM
   Read data queue
   process the data queue entry and do all the nifty stuff

This way if the data queue program takes awhile to do it's task, or it just
blows up, your online systems are not affected.


Rob Berendt