Automatic deletion of journal receivers

If you choose system journal receiver management, you can also have the system delete journal receivers that are no longer needed for recovery. You can only specify this if you are using system journal receiver management.

The system can only evaluate whether a receiver is needed for its own recovery functions, such as recovering access paths or rolling back committed changes. It cannot determine whether a receiver is needed to apply or remove journaled changes.

Attention: Use automatic deletion of journal receivers with care if you use save-while-active operations to save objects before they reach a commitment boundary. Ensure that you save the journal receivers before the system deletes them. If an object is saved before it reaches a commitment boundary it can have partial transactions. To avoid data loss you must have access to the journal receivers that were attached during the save-while-active operation when you restore the objects with partial transactions.

The system will automatically delete journal receivers if you do one of the following:

Specify Delete receivers when no longer needed in the iSeries™ Navigator Advanced Journal Attributes or Journal Properties dialog.
Specify DLTRCV (*YES) in the Create Journal (CRTJRN) or Change journal (CHGJRN) commands.

However, even if you select one of the previous items, the system cannot delete the journal receiver if any of the following conditions is true:

An exit program that is registered for the Delete Journal Receiver exit point (QIBM_QJO_DLT_JRNRCV) indicates that the receiver is not eligible for deletion.
A journal has remote journals associated with it, and one or more of the associated remote journals does not have a full copy of this receiver.
The system could not get the appropriate locks that are required to complete the operation.
The exit program registration facility was not available to determine if any exit programs were registered.

If you use system delete-receiver support, you must ensure that your environment is suitable. You must also regularly check the QSYSOPR message queue and the message queues that are assigned to your journals.

If the system cannot complete the DLTJRNRCV command for any of the above reasons, it retries every 10 minutes (or the value you specify on the DLTRCVDLY parameter). It sends a CPI70E6 message to the journal's message queue, and to QSYSOPR message queue. If this occurs, you might want to determine why the operation cannot be performed and either correct the condition or run the DLTJRNRCV command.
If the system cannot complete the command for any other reason, it sends a CPI70E1 message to the message queue that is assigned to the journal. If you have not specifically assigned a message queue to the journal, the message will be sent to the QSYSOPR message queue. Look at the messages in QHST to determine the problem. After you correct the problem, use the DLTJRNRCV command on the specific journal receiver.

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.

Delay the next attempt to delete a journal receiver

If you are using the CRTJRN or CHGJRN command, you can use the Delete Receiver Delay Time (DLTRCVDLY) parameter. The system waits the time you specify (in minutes) with the DLTRCVDLY parameter before its next attempt to delete a journal receiver that is associated with the journal when one of the following is true:

The system cannot allocate a needed object.
You are using an exit program, and the exit program votes no.
You are using remote journaling and the receiver has not been replicated to all the remote journals.

If you do not specify this parameter, the system waits ten minutes, which is the default.

Save your server while it is active has instructions for saving an object with transactions in a partial state. Example: Recover objects with partial transactions has instructions for recovering objects with partial transactions.