If this is your first visit, be sure to
check out the FAQ by clicking the
link above. You may have to register
before you can post: click the register link above to proceed. To start viewing messages,
select the forum that you want to visit from the selection below.
Be careful don't use CLRPFM or RGZPFM with journaling.
After, no possibility to do a RMVJRNCHG or APYJRNCHG.
Otherwise, back up at once the file after.
RGZPFM will create a Database File Member journal entry: Journal Code = F, and Entry Type = RG. The same for CLRPFM, but with an Entry Type = CR. For those running on V5R3 or above, an SQL DELETE with no WHERE clause will actually do a CLRPFM rather than delete each record seperately (there are a few exceptions). I am assuming that the original post was talking about Record level journalling, but I wanted to put this info out also.
I got burned on this. I was trying to figure out who cleared my file, and I mistakenly was looking at the record level journal entries, and was not finding anything. Then I realized that it was in the file member journal entries.
My understanding was that MIMIX will replicate the CLRPFM command which then runs on the remote system, thereby not requiring millions of record level deletes to be replicated.
If an SQL (DELETE FROM Filename) actually does a CLRPFM then I guess this would replicate the same way ???
I used both MIMIX and Echo2. The CLRPFM was never a problem. I did have re-synch's when RGZPFM was run. I did have Echo2 handling this automatically, but I could see re-sychs of some sort going on.
Thanks for all!
I run RGZPFM on my largest files and as i can see most of time take "rebuilding access path" for LF and i didn't see re-synch's. May be in MIMIX 4.4. it realy run RGZPFM on both systems.
Comment