Restoring records from a journal receiver to a file
Kevin
from my file after making some modifications to them. Unfortunately, the
journal is for only the after image. However, when I look in the journal
receiver, I can see the modifications that I made right before I deleted the
record.
My question is: Is there any way I can get those modifications out of the
journal receiver and back into the file? I don't care that the receiver
only has records *after* I modified the record. Anything is better than
having no record at all.
I'm a newbie to this journaling stuff so please forgive me if this is a
basic question.
Thanks,
Kevin
--
"Experience is a hard teacher because she gives the test first, the lesson
later."
Jonathan Ball
> Hi! I have a file that is journaled. I accidentally deleted some records
> from my file after making some modifications to them. Unfortunately, the
> journal is for only the after image. However, when I look in the journal
> receiver, I can see the modifications that I made right before I deleted the
> record.
>
> My question is: Is there any way I can get those modifications out of the
> journal receiver and back into the file? I don't care that the receiver
> only has records *after* I modified the record. Anything is better than
> having no record at all.
>
> I'm a newbie to this journaling stuff so please forgive me if this is a
> basic question.
It's relatively easy, although there are some tedious
steps.
1. Determine the record format length of the file.
2. Display the journal entries into a work file:
dspjrn jrn(jrnlib/myjrn) file(thefile) jrncde(r)
enttyp(pt up) output(*outfile)
outfile(mylib/jrnfile) entdtalen(nnn)
where 'nnn' is the length you determined in 1.
3. The field JOESD in the outfile contains the after
image of all new or updated records in the file,
from the beginning of the journal. You need to
isolate the records in which you're interested.
One way to do this is to look at the relative
record number of the journal entries for the
deletions ( entry type DL); another is to parse
through the entry-specific data (JOESD) of the
records, looking for the key values of the records
that you know were incorrectly deleted. The second
way is much harder if any of the key fields is
packed decimal.
One way or another, you'll have to pare that outfile
down to a unique set of records corresponding to
the deleted records.
4. If you have access to and know SQL, create a view
over the outfile containing the relevant PT/UP
journal entries, as follows:
create view mylib/myview as
select joesd
from mylib/jrnfile
where [...]
If you can identify the (say) 5 records that were
deleted by their relative record number, and there
is only one UP journal entry for each of them, you
could code your WHERE clause as:
where joctrr in (rrn1,rrn2,rrn3,rrn4,rrn5)
5. Now do a simple CPYF command:
cpyf fromfile(mylib/myview) tofile(prodlib/thefile)
mbropt(*updadd) fmtopt(*nochk)
The deleted records will be restored. Delete your view
and the outfile afterward.
Thomas Raddatz
provided as freeware on my freeware page on the Internet. Just follow the
tools400 link, select your language and then click on FREEWARE, UTILITIES,
EXPJRNE.
The utility exports the journal entries from the journal into a file. The
file consists of the special journal information fields plus the original
fields from the file. After having exported the deired entries copy them
back into the original file specifying *MAP *DROP at the cpyf command.
Thomas Raddatz.
--
*=====================================================*
e-mail Adresse:
Thomas....@tools400.de
Homepage:
http://www.tools400.de
*=====================================================*
"Kevin" <ctes...@yahoo.com> schrieb im Newsbeitrag
news:baducc$shp3s$1...@ID-182869.news.dfncis.de...
Tim M
documented in the backup and recovery guide under Journaling.
Here is a sketch of the process.
1. Restore the physical file from its last full backup
2. Restore all the journal recievers in the chain that were attached to the
journal from the time the backup occurred to the time the corruption
occurred
3. Use the APYJRNCHG command apply the journaled transactions to the
restored database files. Making sure to exclude errant deletes.
"Kevin" <ctes...@yahoo.com> wrote in message
news:baducc$shp3s$1...@ID-182869.news.dfncis.de...
emc...@yahoo.com
can still download a free 30 day trial of Prodata's Retrieve Delete
Records program. I used it once years ago, when I accidently delete
half the records from our Open Order file.
www.prodatacomputer.com They also have an excellent Database utility
DBU.
As the other poster pointed out the records can be extracted from the
journal with some work.
On Tue, 20 May 2003 14:03:47 -0500, "Kevin" <ctes...@yahoo.com>
wrote:
Kevin
I was able to retrieve the records I needed!
Thanks to everyone, especially Jonathan, for the wonderful advice and help!
Best regards,
Kevin
--
"Experience is a hard teacher because she gives the test first, the lesson
later."
"Kevin" <ctes...@yahoo.com> wrote in message
news:baducc$shp3s$1...@ID-182869.news.dfncis.de...
Jonathan Ball
> Wow! Thanks for all the helpful information! Using Jonathan's reply above,
> I was able to retrieve the records I needed!
>
> Thanks to everyone, especially Jonathan, for the wonderful advice and help!
>
> Best regards,
>
> Kevin
You're welcome, and thanks for the kind words.
It's amazing what the human mind can come up with when
that same human mind (yrs. trly.) got lazy and *&@%$ed
the thing up in the first place, eh? In fact, at my
current client, they have before and after imaging in
effect, so in theory I could have done RMVJRNCHG (and
covered my tracks quite neatly). However, the files
were in constant use, and RMVJRNCHG needs to get an
exclusive lock on the file, so that option wasn't
available. You know the rest of the story.
Another way to stay safe is to use commitment control,
allowing you to roll back any unwanted changes.
Commitment control will temporarily turn on before
imaging even if journaling was only started on the
files specifying after images only. There's a fair
amount of detail to using commitment control, and of
course, it's the solution that springs to mind only
AFTER the original *&@%$-up.
Dr. Ugo Gagliardelli
>
> Kevin wrote:
> > Wow! Thanks for all the helpful information! Using Jonathan's reply above,
> > I was able to retrieve the records I needed!
> >
> > Thanks to everyone, especially Jonathan, for the wonderful advice and help!
> >
> > Best regards,
> >
> > Kevin
>
> You're welcome, and thanks for the kind words.
get the same result.
--
Dr.Ugo Gagliardelli,Modena,Italy-Certified
uindoscrasher,(anńejo)AlcoolInside
Spaccamaroni andate a cagare/Spammers not welcome
Spamers iros a la mierda/Spamers allez vous faire foutre
Spammers loop schijten/Spammers macht Euch vom Acker
Jonathan Ball
> Jonathan Ball wrote:
>
>>Kevin wrote:
>>
>>>Wow! Thanks for all the helpful information! Using Jonathan's reply above,
>>>I was able to retrieve the records I needed!
>>>
>>>Thanks to everyone, especially Jonathan, for the wonderful advice and help!
>>>
>>>Best regards,
>>>
>>>Kevin
>>
>>You're welcome, and thanks for the kind words.
>
> Just to give a complete information, maybe using RMVJRNCHG jou should
> get the same result.
I addressed that. The problem with using RMVJRNCHG is
you need to obtain an exclusive lock on the file, which
is difficult or impossible to do during the period of
normal system availability (it's why I couldn't use
it.) Also, it presupposes you have IMAGES(*BOTH)
specified on the journaled files, and the original
poster stated that they didn't. Finally, if there are
other updates to the file besides the deletions that
are mixed in with the deletions, you'll undo some
changes that shouldn't be undone, UNLESS you run
RMVJRNCHG separate for each DL journal entry (if all
the DL journal entries for the erroneous deletions are
contiguous, that isn't a problem.)