Mimix journals are filling up due to broken replication

We have been using Mimix from Lakeview technologies to replicate between two iSeries.
Due to mergers with other organizations, our databases (and other objects) have gotten way out of sync.  We have broken the replication and probably need to do a full system save and restore to get back in sync.

Now we are running short on space because the Mimix journals are building up.

Can anyone offer a solution for clearing these journals?
pwheatAsked:
Who is Participating?
I wear a lot of hats...

"The solutions and answers provided on Experts Exchange have been extremely helpful to me over the last few years. I wear a lot of hats - Developer, Database Administrator, Help Desk, etc., so I know a lot of things but not a lot about one thing. Experts Exchange gives me answers from people who do know a lot about one thing, in a easy to use platform." -Todd S.

MurpheyApplication ConsultantCommented:
Hi pwheat,

I don't know Mimix, but If it are normal ASX/400 journals, you can use DLTJRNRCV to delete them.
Only the Receiver current in use cant be deleted.

Regards,
Murph

0
tliottaCommented:
pwheat:

Murph is generally correct. The problem here is probably that Mimix is a proprietary product that has its own proprietary ways of managing its replication journals. Nobody feels comfortable telling you to do "normal" journal operations in case it breaks something unexpectedly.

OTOH, if your space is being seriously consumed, there might be no choice.

First things first, can supply the name(s) of the Mimix journals? Receivers attached to those journals will be where the space is consumed.

I would guess that Mimix might want certain system values to be set in order to perform effective replication. Also, Mimix must have a way to manage receivers -- obsolete receivers for replication would no longer be needed once all entries in the receiver were sent to the remote system, so Mimix would delete them.

Likely system values would be the audit values -- object-change auditing would signal whenever changes happened. Various kinds of objects can be journaled in order to track changes -- database files, stream files, and other data objects. But Mimix has to replicate all kinds of things that aren't handled through normal database journaling. Audit journaling would be the only reasonable way I can think of to know when changes happened.

You _might_ be able to stop some growth by turning off unneeded audit options. Of course, that should only be done if you aren't expecting to need that info to satisfy an actual audit. The QAUDCTL system value would have *OBJAUD listed as one of its values. By removing that value from QAUDCTL, object auditing will be turned off. That may slow the growth of your system audit journal receivers.

Alternatively, you might remove many objects from being audited [by object auditing] by setting the audit attribute off for those objects. You can use the CHGOBJAUD command against individual objects to set the objects' OBJAUD() attribute to *NONE.

That can be done for groups of objects by using the CHGAUD command and specifying a generic path. Entire libraries of objects can be changed that way with a single command.

That's a basic introduction to removing system auditing from objects. For database type auditing, you'll need to review the journals to see what objects are included. The WRKJRNA (Work with Journal Attributes) command can be used to see what all is journaled to a given journal.

You can use the ENDJRNPF command to end journaling of physical files, ENDJRNAP to end access path journaling, and ENDJRNOBJ to end other object journaling. You can also use ENDJRN for more generic control, but physical files, access paths and some other object types, must be referenced through the other commands.

You might use ENDJRN first in order to end journaling for everything that that command is able to handle. Then use the other commands to clean what's left over.

I would assume that Mimix used 'remote journals.' You didn't say how you "brok[e] the replication," but I'd expect that the RMVRMTJRN command would have been executed. If it hasn't been run yet, it seems that it should be the first thing that's done. I'm not sure how easily receivers can be deleted if remote journaling is still enabled, even if communications were ended.

Be careful to restrict all such work only to Mimix journals. You don't want to disturb database journaling that's being used for commitment control for example. Nor do you want to cause breaks in audit chains that really need to be maintained.

If you are publicly traded or a regulated company, you'll probably want to document whatever steps are taken. You should probably at least make certain that joblogs are retained for all sessions that do any of this work.

There might be more, but too much is guesswork already. Until an experienced Mimix person shows up, you're kind of on your own.

If you need elaboration, post back here. Murph can probably take take any questions and work through them with you. I just want to supply a basic foundation.

Tom
0

Experts Exchange Solution brought to you by

Your issues matter to us.

Facing a tech roadblock? Get the help and guidance you need from experienced professionals who care. Ask your question anytime, anywhere, with no hassle.

Start your 7-day free trial
pwheatAuthor Commented:
Our OS support confirmed and deleted the offending journals.
0
It's more than this solution.Get answers and train to solve all your tech problems - anytime, anywhere.Try it for free Edge Out The Competitionfor your dream job with proven skills and certifications.Get started today Stand Outas the employee with proven skills.Start learning today for free Move Your Career Forwardwith certification training in the latest technologies.Start your trial today
IBM System i

From novice to tech pro — start learning today.