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