MIDRANGE dot COM Mailing List Archive



Home » MIDRANGE-L » August 2014

RE: Automatic Journal Deletion



fixed

Dear Chuck,

Thanks for your response, and efforts you took to share your knowledge. Coming back to describing the requirement in a detailed manner

This is what I am planning to do:

What we have:
We have 100s of journal receivers associated to several journals in different libraries.

What I planned to do:
Create a lookup table which will have **Journal Receiver Name, **Journal it is attached to, **detach date, retention days (nn)
** information is retrieved from dspobjD

Write a CL program:
Which will populate the data in lookup table using DSPOBJD command. Delete Journals Receivers which has detach date older then rentiion days.

This program will later be scheduled

If someone has more better way of handling this, please suggest

Regards

Aamir

-----Original Message-----
From: MIDRANGE-L [mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of CRPence
Sent: Saturday, August 09, 2014 1:37 AM
To: midrange-l@xxxxxxxxxxxx
Subject: Re: Automatic Journal Deletion

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_

--
Regards, Chuck
--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list To post a message email: MIDRANGE-L@xxxxxxxxxxxx To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx Before posting, please take a moment to review the archives at http://archive.midrange.com/midrange-l.

********
This message (including any attachments ) is confidential and is intended solely for the use of the individual or entity to whom it is addressed. If you have received this message by mistake please notify the sender by return email and delete this message from your system. Any unauthorised use or dissemination of this message in whole or in part is strictly prohibited.
********






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