MIDRANGE dot COM Mailing List Archive



Home » MIDRANGE-L » August 2014

Re: Automatic Journal Deletion



fixed

On 07-Aug-2014 23:20 -0500, Aamir Shaikh wrote:

I am looking for a CL program or a tool which can delete journal
receivers based on age. Any help is highly appreciated


The subject says "Automatic Journal Deletion", but presumably the topic is actually [and only] about effecting _Journal Receiver_ deletion; presumably /automated/ as in some type of scheduled or triggered action for which appropriately /aged/ journal receiver objects will be deleted via programmed action without manual intervention.? To be clear the Journal (*JRN) object should not also be getting deleted by the desired tooling.?

And beyond that... Difficult for someone to divine what is required, given so little information. What are the requirements? Most notably, what should be the input to the tooling? Is the input a Library name, a Journal name probably including the library name, a naming convention [likely a generic name] for the Journal Receivers possibly including the library in which they should reside, an iASP name, the /system/ or *SYSBAS [such that there are effectively no inputs], or something else?

The simplest [but most prone to fail, per dependencies] is to use any existing tooling for [/QSYS.LIB] objects generally; i.e. tooling that already performs age-based obsolescence processing of objects in libraries, but is not specific to Journal Receiver (*JRNRCV) objects. Such tooling likely utilizes one\some of the Display Object Description (DSPOBJD), List Objects (QUSLOBJ) API, Open List of Objects (QGYOLOBJ) API, and Open List of Objects (QGYOLOBJ) API.

Rather than solely /age/ per creation-date\timestamp [e.g. from one of the aforementioned object APIs], I would recommend also considering the Journal Receiver Chain [Journal Receiver Directory] for the Journal [Journal Port] object to which the the Journal Receiver [Journal Space] object is [and others in the chain also may be] attached. The following APIs along with specific object information [e.g. creation date\time] can be used to help deal with the _relative_ journal receiver dependencies.

<http://www.ibm.com/support/knowledgecenter/api/content/ssw_ibm_i_71/apis/QJORJRNI.htm>
_Retrieve Journal Information_ (QjoRetrieveJournalInformation) API
"...
Various types of journal information are provided by the API. General information, similar to information reported by using the Work with Journal Attributes (WRKJRNA) CL command, and additional information are contained in the header section. If requested, information is provided for the journal receiver directory, journaled objects, and remote journals.
...

_Key 1 Output Section_
... Note: The following fields are returned when the journal receiver directory key information is specified. ...
..."

<http://www.ibm.com/support/knowledgecenter/api/content/ssw_ibm_i_71/apis/QJORRCVI.htm>
_Retrieve Journal Receiver Information_ (QjoRtvJrnReceiverInformation) API
"...
Various types of journal receiver information are provided by the API, similar to information reported using the Display Journal Receiver Attributes (DSPJRNRCVA) CL command.
...
_Next journal receiver name_. The name of the next journal receiver that is associated with this journal receiver. ...
...
_Previous journal receiver name_. The name of the previous journal receiver that is associated with this journal receiver. ...
...
Saved date and time. The date and time that the journal receiver was last saved. ...
... "


The Delete Journal Receiver (DLTJRNRCV) command docs should reveal other considerations; the parameters and allowed specifications, plus the possible messages, both Inquiry and Escape, allude to restrictions and limitations. There are also specific doc references more generic about deleting receivers:

<http://www.ibm.com/support/knowledgecenter/api/content/ssw_ibm_i_71/cl/dltjrnrcv.htm>
_Delete Journal Receiver_ (DLTJRNRCV)

<http://www.ibm.com/support/knowledgecenter/api/content/ssw_ibm_i_71/rzaki/rzakideletercv.htm>
_Deleting journal receivers_
"Journal receivers can quickly use a lot of auxiliary storage space. Therefore an important journal management task is to delete journal receivers after you no longer need them.

When you determine whether to delete a journal receiver, consider the following:
• Journal receivers you need for recovery
...

• Journal receivers you do not need for recovery
...

• Where the journal receiver is in the receiver chain

To ensure logical recovery, the system does not allow you to delete a journal receiver from the middle of the receiver chain unless one of the following conditions exists:
• The journal is using automatic deletion of journal receivers.
• The journal is a remote journal.

However, if a journal receiver is damaged, you can delete it from the middle of the chain. If an attached journal receiver is damaged, you must perform a change journal operation to detach the damaged receiver before you can delete it.

The rules for deleting journal receivers are as follows:

• You cannot delete a journal receiver that is attached to a local journal. You must perform a change journal operation to detach a journal receiver before you delete it.
• You must delete journal receivers in the same order they were attached to a journal.
• You can delete a damaged or inoperable receiver regardless of the previous restriction. However, if an attached receiver is damaged, you must detach it before you delete it.
• You cannot delete a journal receiver that is attached to a remote journal if the remote journal has a journal state of active. If you attempt to delete a receiver that is attached to a remote journal, the system sends the inquiry message CPA705E. The results of the reply to the message are the same as those that occur with message CPA7025.

..."

<http://www.ibm.com/support/knowledgecenter/api/content/ssw_ibm_i_71/apis/XDLTRCV.htm>
_Delete Journal Receiver Exit Program_

<http://www.ibm.com/support/knowledgecenter/api/content/ssw_ibm_i_71/rzarm/rzarmdltjrnr.htm>
_Deleting a journal receiver_






Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2014 by MIDRANGE dot COM and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available here. If you have questions about this, please contact