Re: Still necessary/recommended to rebuild data queues regularly?

I haven't looked through all of this thread, but in response to this reply, I can say that the IBM recommendation was based upon the fact that once space was used up by a user/data queue, it could never be reclaimed except by queue rebuild. Later a parameter was added: AUTORCL (@Automatic Reclaim - default *NO), but last I knew that was only effective on a completely empty queue. If even one message remains (remained?) in the queue, the space would not be reclaimed.

Seems the perfect place for implementation of circular-buffer logic; don't know why IBM never opted to go that route.

"CRPence" <CRPbottle@xxxxxxxxx> wrote:

On 2/17/11 12:33 AM, Åke Olsson wrote:

Our application uses data queues "a lot" and out of habit and
tradition the queues get deleted and created afresh in the overnight
runs.

I believe this way of handling them was an IBM recommendation some
years ago.

The question is: Is it still necessary to delete/create data queues
like this? OR Could we just let them be - like forever. Never
deleting them. Just create queues when needed and let them sit.

To create once and then use repeatedly, is the best for the IBM i
object-based OS. However...

Whether the queues are destroyed before starting the application
should reflect the design [intention] rather than reflect a habit or
tradition. If the queues happen to have data left on them from when
the
application [or some other function, for example a STOPMYAPP request]
last ran, then deleting the queues might be appropriate "as designed".
Or the application could alternatively "drain" the queue, verifying all

enqueued messages are since defunct, perhaps reporting any anomalies,
perhaps terminating in response to anomalies, but at the cost of
delaying the start of the application. Again, the design should
dictate
behavior.

If the application knows how to process [possibly confusing entries;
e.g. multiple old "stop processing" requests upon application startup]
old messages or has uses some means [other than DLTDTAQ] to remove
them,
then leaving the queues permanently should not generally be a problem.

One issue [possibly origin for an "IBM recommendation"] that might
arise, is damage to the queue after termination of the system where
memory might not have been fully written to disk such as in power
outages; the "queue" object type is considered "volatile" due to its
lesser protections for the integrity of its data as the trade-off for
more speed in access to its data. For a system encountering many such
[hard crash] outages having resulted in repeated incidents of damage, a

recommendation to always delete versus react to the damage would be
likely; simplicity, especially if the FORCE() parameter of CRTDTAQ was
either unavailable by then, or was not an option due to its impact on
performance. An application which expects the queues to exist should
know how to respond to "damage" of the queue, for which the only
recovery is delete\re-create, so the delete\recreate code would best
remain [in or separate from the application itself] as a reaction to
that condition.

Since the support of journaling of queues, STRJRNOBJ OBJTYPE(*DTAQ)
can be used to ask the OS to provide better protection for the
integrity
of the data. Associating the object with a journal provides an
effective means of asking that the data queue be protected even while
being treated as volatile, offloading the integrity protection to the
journaling feature to avoid the "force" of the queue itself.

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.

--
Sent from my Galaxy tablet phone with with K-9 Mail. Please excuse my brevity.