First look at which ones are detached from the journal, largest first:
SELECT JOURNAL_LIBRARY, JOURNAL_NAME,
JOURNAL_RECEIVER_LIBRARY, JOURNAL_RECEIVER_NAME,
SIZE / 1024 AS MB, DETACH_TIMESTAMP, SAVE_TIMESTAMP
FROM QSYS2.JOURNAL_RECEIVER_INFO
WHERE DETACH_TIMESTAMP IS NOT NULL
ORDER BY SIZE DESC
DETACH_TIMESTAMP stays null while the receiver is still attached to its journal. Filtering on
not-null therefore leaves exactly the detached receivers, which are the only candidates for
deletion: the attached one is in use and stays.
SIZE is expressed in kilobytes, so dividing by 1024 gives megabytes; not by 1024 twice,
which is the easy mistake to make coming from other size columns.
SAVE_TIMESTAMP says when that receiver was last saved, and it sits in the same row. It is the
information needed at the next step, without a second command per receiver.
Example: the ones a year old
On a system with several journals the full list is long and not much use. The cut that helps is a time one, detached long enough to be outside any reasonable recovery window:
SELECT JOURNAL_RECEIVER_LIBRARY, JOURNAL_RECEIVER_NAME,
SIZE / 1024 AS MB, DETACH_TIMESTAMP
FROM QSYS2.JOURNAL_RECEIVER_INFO
WHERE DETACH_TIMESTAMP IS NOT NULL
AND DETACH_TIMESTAMP < CURRENT_TIMESTAMP - 1 YEAR
ORDER BY SIZE DESC
If this query returns rows, the problem is not disk space: it is that automatic receiver management is not configured. See the tip at the end.
Only those already saved and no longer needed get deleted:
DLTJRNRCV JRNRCV(JRNLIB/RCV0000123) DLTOPT(*IGNINQMSG)
Warning
a journal receiver is what restores the changes made after the last save.
Deleting one that has not been saved means those changes are gone for good if a restore is
ever needed. Before deleting, the confirmation comes from DSPJRNRCVA, which says explicitly
whether the receiver has been saved.
Tip
the structural fix is not periodic manual deletion but CHGJRN ... DLTRCV(*YES)
with automatic receiver management, which detaches and deletes them on its own after the
save. Deleting by hand is the symptom of a configuration that needs attention.
Releases. QSYS2.JOURNAL_RECEIVER_INFO is among the more recent IBM i Services: check by
running the query, and if it answers SQL0204 use WRKJRNA JRN(LIB/JRN) option 15, which
lists receivers with size and status. DSPJRNRCVA says whether a receiver has been saved, and
that is the check that matters before deleting anything.
Comments
No comments yet. Be the first to comment!
You need an account to comment. Log in · Sign up