Re: Remote journals and APYJRNCHG -- MIDRANGE-L

Lo,
the routines work as follows:

An autostartjob runs the RCVJRNE command.
The exitpgm selects the DB-journalentries and these are treated in different
detail pgms.
( Updates under commitment control are kept in a workfile with the
JRNRCV-layout till they are committed ).
(A 1 record controlfile keeps track of the last treated journalreceiver -
journalentry.)

The detailpgms are simple Read-Update/Read-Delete/Add routines,
input is  the Image Before - Image After for Updates, or the simple Record
Image for Add or Delete .
The detailpgms work on a automaticly selected unique-key LF  .
(All our PF have at least one LF with a unique key.)
(The procedure is adapted to work on RRN also, for non-unique key -LFs, but
this has never been tested.)

I created these programs based on the RTVDBSRC pgm of Alex Nubla:
Based on this, I created a "CRTDBSUB"-routine, which automatically creates
the module/pgm for a specific file.

Since we have V5R1 machines with WDT on it (upgraded from PDM), the
(re)creation is done on the fly,
if a new file is journaled (or a file is modified)
For older OS versions this can be done also, if a compiler is on the
machine.
Otherwise the procedure still can be used, only it won't be dynamic anymore:
detailpgms should be made manually.
Detailmodules made manually beforehand, can be put together in a servicepgm
.

That 's it.


----- Original Message -----
From: "Raikov, Lo" <Lo.Raikov@MISYS.COM>
To: <midrange-l@midrange.com>
Sent: Thursday, March 14, 2002 1:25 AM
Subject: RE: Remote journals and APYJRNCHG


> Luc,
>
> yes, I would be interested in your code. However, I'm still very much in
the
> dark regarding what it does. I'm after an entry-level replication slotion
> (I'm only interested in full recovery on the remote site in case the
primary
> server goes down). I can see how to do it with remote journals, but it
looks
> like to be able to run APYJRNCHG I need to create a "local" journal on the
> remote site and periodically SAVRST remote journal receivers to the local
> journal library. If you can suggest a better way, I'm all ears.
>
> Lo
>
> -----Original Message-----
> From: Caura [mailto:caura@village.uunet.be]
> Sent: 14 ????? 2002 ?. 9:25
> To: midrange-l@midrange.com
> Subject: Re: Remote journals and APYJRNCHG
>
>
> Lo,
>
> SavRst might be an option.
>
> But, instead of the SAVRST , creating a -real- remote journal, just takes
> the command,
> and the replication is continuous, even if you don't exploit the journal
on
> the remote site.
> Applying the remote journal at the source after re-transfer is possible
> either way.
>
> Only, if your source system goes down, you can only apply the journaled
> changes after the problem is resolved and the system is in the air again.
> - and the copy of the journalreceivers to the source system is done-
> Then you should be aware that an APYJRNCHG might take quite some time
(maybe
> longer then a restore of a complete library?).
>
> I can give you the code I use -as a basis for open source, as you
mentioned
> at first? -.
> Their are some things to keep in mind:
> -, looking over it, I realise the code leans on a bunch of everyday little
> routines that all together are difficult to include for the sake of
> completeness .
> - the code somehow is optimized on our naming conventions, although this
> should be of minor concern.
>
> Luc
>
>
>
> ----- Original Message -----
> From: "Raikov, Lo" <Lo.Raikov@MISYS.COM>
> To: <midrange-l@midrange.com>
> Sent: Wednesday, March 13, 2002 1:26 AM
> Subject: RE: Remote journals and APYJRNCHG
>
>
> > Luc,
> >
> > I don't want to write this exit program, that's the point. However,
there
> is
> > a solution, although it is not exactly seamless: I simply SAVRST the
> journal
> > from the source to the remote system and in case of the first system
crash
> > restore accumulated remote journal receivers into the source journal
> > library. After that APYJRNCHG works if I specify the correct range of
> > receivers on the command.
> >
> > Lo
> >
> > -----Original Message-----
> > From: Caura [mailto:caura@village.uunet.be]
> > Sent: 13 ????? 2002 ?. 8:12
> > To: midrange-l@midrange.com
> > Subject: Re: Remote journals and APYJRNCHG
> >
> >
> > Lo,
> >
> > you can use the RCVJRNE command to receive the JournalEntries on a
remote
> > Journal, just as you can on a local journal.
> >
> > We use it to keep backup libraries of remote systems.
> > The exitprogam of the RCVJRNE command can do anything you specify.
> >
> >
> > Luc
> >
> > ----- Original Message -----
> > From: "Raikov, Lo" <Lo.Raikov@MISYS.COM>
> > To: <midrange-l@midrange.com>
> > Sent: Tuesday, March 12, 2002 1:41 AM
> > Subject: RE: Remote journals and APYJRNCHG
> >
> >
> > > Ken,
> > >
> > > could you be more specific please? How can I recover on the source
> system
> > > using remote journal receiver backups? These receivers would not
attach
> to
> > > any other journal but the initial remote journal, or am I wrong?
> > >
> > > Lo
> > >
> > > -----Original Message-----
> > > From: Graap, Ken [mailto:keg@nwnatural.com]
> > > Sent: 12 ????? 2002 ?. 8:42
> > > To: 'midrange-l@midrange.com'
> > > Cc: 'spanner@ihug.co.nz'
> > > Subject: RE: Remote journals and APYJRNCHG
> > >
> > >
> > >
> > > >contortions for the restoring back to the original system scenarios
> > border
> > > >on the ridiculous unless you think that maybe IBM didn't want to kill
> the
> > > >businesses based on selling replication solutions.
> > >
> > > Come on Evan .... A lot of people use remote journaling for recovery
> > > purposes, not just replication.
> > >
> > > In a recovery scenario, you would recover the source system, restore
> > remote
> > > journal receivers to the recovered source system and apply journal
> changes
> > > to recover your data to the point of failure....
> > >
> > > I wouldn't call that ridiculous.
> > >
> > > The point of remote journaling in this case is to make sure your
> journaled
> > > transactions are immediately relocated to a remote system which is
> > separated
> > > from your source system.
> > >
> > > regards,
> > >
> > > Kenneth
> > >
> > > ****************************************
> > > Kenneth E. Graap
> > > IBM Certified Specialist
> > > AS/400e Professional System Administrator
> > > NW Natural (Gas Services)
> > > keg@nwnatural.com
> > > Phone: 503-226-4211 x5537
> > > FAX:    603-849-0591
> > > ****************************************
> > >
> > >
> > > -----Original Message-----
> > > From: Evan Harris [mailto:spanner@ihug.co.nz]
> > > Sent: Monday, March 11, 2002 11:19 AM
> > > To: midrange-l@midrange.com
> > > Subject: RE: Remote journals and APYJRNCHG
> > >
> > >
> > > Kenneth wrote:
> > >
> > > >Normally wouldn't you just restore the receivers back to the source
> > system
> > > >and run APYJRNCHG there?
> > > >
> > > >Kenneth
> > > >Subject: Remote journals and APYJRNCHG
> > >
> > > <SNIP>
> > >
> > > >Is anybody aware of a tool that would enable you to apply journalled
> > > changes
> > > >registered in a remote journal? What I need is APYJRNCHG version that
> > would
> > > >be capable of running off remote journals.
> > > >
> > > >Lo
> > >
> > > Near as I can tell what Lo wants to be able to do is to replicate a
file
> > or
> > > set of files onto a remote machine using the remote journalling
> function.
> > > In my opinion that's the most obvious use for remote journalling - the
> > > contortions for the restoring back to the original system scenarios
> border
> > > on the ridiculous unless you think that maybe IBM didn't want to kill
> the
> > > businesses based on selling replication solutions.
> > >
> > > Leaving out the ability to apply remote journals on the target remote
> > > journalling system cannot have been an oversight.
> > >
> > > If someone has code to read the receiver and apply the changes I would
> be
> > > interested as well. If it doesn't already exist would make a great
Open
> > > source project for the entire Iseries community.
> > >
> > > Regards
> > > Evan Harris
> > >
> > >
> > > _______________________________________________
> > > This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing
> > list
> > > To post a message email: MIDRANGE-L@midrange.com
> > > To subscribe, unsubscribe, or change list options,
> > > visit: http://lists.midrange.com/cgi-bin/listinfo/midrange-l
> > > or email: MIDRANGE-L-request@midrange.com
> > > Before posting, please take a moment to review the archives
> > > at http://archive.midrange.com/midrange-l.
> > > _______________________________________________
> > > This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing
> > list
> > > To post a message email: MIDRANGE-L@midrange.com
> > > To subscribe, unsubscribe, or change list options,
> > > visit: http://lists.midrange.com/cgi-bin/listinfo/midrange-l
> > > or email: MIDRANGE-L-request@midrange.com
> > > Before posting, please take a moment to review the archives
> > > at http://archive.midrange.com/midrange-l.
> > > _______________________________________________
> > > This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing
> > list
> > > To post a message email: MIDRANGE-L@midrange.com
> > > To subscribe, unsubscribe, or change list options,
> > > visit: http://lists.midrange.com/cgi-bin/listinfo/midrange-l
> > > or email: MIDRANGE-L-request@midrange.com
> > > Before posting, please take a moment to review the archives
> > > at http://archive.midrange.com/midrange-l.
> > >
> >
> > _______________________________________________
> > This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing
> list
> > To post a message email: MIDRANGE-L@midrange.com
> > To subscribe, unsubscribe, or change list options,
> > visit: http://lists.midrange.com/cgi-bin/listinfo/midrange-l
> > or email: MIDRANGE-L-request@midrange.com
> > Before posting, please take a moment to review the archives
> > at http://archive.midrange.com/midrange-l.
> > _______________________________________________
> > This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing
> list
> > To post a message email: MIDRANGE-L@midrange.com
> > To subscribe, unsubscribe, or change list options,
> > visit: http://lists.midrange.com/cgi-bin/listinfo/midrange-l
> > or email: MIDRANGE-L-request@midrange.com
> > Before posting, please take a moment to review the archives
> > at http://archive.midrange.com/midrange-l.
> >
>
> _______________________________________________
> This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing
list
> To post a message email: MIDRANGE-L@midrange.com
> To subscribe, unsubscribe, or change list options,
> visit: http://lists.midrange.com/cgi-bin/listinfo/midrange-l
> or email: MIDRANGE-L-request@midrange.com
> Before posting, please take a moment to review the archives
> at http://archive.midrange.com/midrange-l.
> _______________________________________________
> This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing
list
> To post a message email: MIDRANGE-L@midrange.com
> To subscribe, unsubscribe, or change list options,
> visit: http://lists.midrange.com/cgi-bin/listinfo/midrange-l
> or email: MIDRANGE-L-request@midrange.com
> Before posting, please take a moment to review the archives
> at http://archive.midrange.com/midrange-l.
>