× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.



Lo,

I don't have time to tidy up the code at the moment,
but if you - or somebody else - can point me to a location where I could
put the current version of the code,
you can play around with it .

Luc

----- Original Message -----
From: "Raikov, Lo" <Lo.Raikov@MISYS.COM>
To: "'Caura '" <caura@village.uunet.be>
Sent: Tuesday, March 19, 2002 11:48 AM
Subject: RE: Remote journals and APYJRNCHG


> Luc,
>
> is your code available as open source? If yes I would point my customers
in
> that direction.
>
> Thanks,
>
> Lo
>
> -----Original Message-----
> From: Caura
> To: midrange-l@midrange.com
> Sent: 19.03.02 8:02
> Subject: Re: Remote journals and APYJRNCHG
>
> 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.
> >
>
> _______________________________________________
> 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.



As an Amazon Associate we earn from qualifying purchases.

This thread ...


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

This mailing list archive is Copyright 1997-2024 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].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.