RE: Remote journals and APYJRNCHG -- MIDRANGE-L

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.