Re: Journaling newbie - questions

Comments inline.

Regards, Chuck

Jeff Crosby wrote:

I'm just getting started with journaling. I have a history (deficiency?) of not being able to find what I want in the
Infocenter. There is a ton of reference material in there on
journaling, but not what I would call a programmer's guide or how-to.
There is a getting started list, but it doesn't discuss the whys,
only the whats. And the redbook is centered on the performance
aspect.

1) Is there anyone out there who is journaling and does NOT have "HA Journal Performance" installed? (On V5R4 it's 5722-ss1 option 41.)

2) I'm looking for a detailed discussion of this: If I set a journal
as MNGRCV(*SYSTEM) and DLTRCV(*YES), how specifically does the system
determine when a journal receiver ("JR") can be deleted? Once the JR
is saved somewhere? A successful save of each and every object being journaled?

What prevents deletion by the system managed feature, is primarily due to any logging from partial transactions. Ensuring the receivers are available for recovery, outside of just for pending transactions, is a user requirement. Thus DLTRCV(*NO) is probably best in that case. From InfoCenter, a link providing a good starting point to other topics:

"Automatic deletion of journal receivers"
http://publib.boulder.ibm.com/infocenter/iseries/v5r4/topic/rzaki/rzakiautodelete.htm
"Do not select to have the detached journal receiver deleted if you might need it for recovery or if you want to save it before it is deleted. The system does not save the journal receiver before deleting it. The system does not issue the warning message (CPA7025) that it sends if a user tries to delete a receiver that has not been saved.

Examples of when you might specify automatic journal deletion include:

- You are journaling only because it is required to use commitment control.
- You are journaling for explicit access-path protection.
- You are replicating the journal receiver to another system through the remote journal function, and that system is providing the backup copy of the journal receiver."

However an exit program registered for the Delete Journal Receiver exit point (QIBM_QJO_DLT_JRNRCV) can indicate that the receiver is not eligible for deletion; e.g. by test that determines the receiver has not yet been saved. That or the MSGQ() named on CRTJRN could be used to trigger the enqueue of a request to effect save of that receiver.
http://publib.boulder.ibm.com/infocenter/iseries/v5r4/topic/apis/XDLTRCV.htm
http://publib.boulder.ibm.com/infocenter/iseries/v5r4/topic/cl/crtjrn.htm

3) Expansion of #2. What I have in mind is MNGRCV(*SYSTEM) and DLTRCV(*YES), and, a couple of times during the day, save journal receivers to tape. The journal and JR are in the same library and are
the only objects in that library. (Should they be in separate libs?)
The ideal would be at a predetermined time do a SAVLIB of the JR
library which would automajically save any detached receivers and
then the system "would just know" that JR can be deleted. Should the
*JRN object be saved then too? Shouldn't I be doing a CHGJRN just
prior to saving the JR? How does one determine the name of a just
detached JR? How does one determine the name of a detached JR if the
system did a CHGJRN 45 minutes earlier?

CHGJRN to *GEN a new receiver with DLTRCV(*YES) will effect the delete of the old receiver [if the receiver is no longer needed for recovery, and if locking & dltjrnrcv exit program allow], so there would be no receiver to save. The MSGQ() on the journal will be notified of the detached receiver; less usable, but the same message is also sent to QHST. Given the receiver is not deleted, there is also an API to retrieve the receiver-chain. Note that /system managed/ does not preclude user requests to change the attached receiver, not for *GEN nor to a named receiver.
http://publib.boulder.ibm.com/infocenter/iseries/v5r4/topic/cl/chgjrn.htm
"Journal message queue"
http://publib.boulder.ibm.com/infocenter/iseries/v5r4/topic/rzaki/rzakijrnmssgque.htm

We do a save of the entire system every day at 12:01am. What I guess I'm looking for is best practices of keeping the database changes
(and eventually IFS) saved via journaling until the next save. There
is no DR or HA site. I do store tapes offsite as well as onsite.

crtjrn dltrcv(*no) mngrcv(*system) msgq() /* initially */
chgjrn jrnrcv(*gen) /* at 12:00; rcvmsg to get name &jrnrcv */
savobj &jrnrcv
fullsave /* at 12:01+ */