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

Yes. Sorry I didn't carry my prior reply to its logical end: We found that queues that were heavily used would bump against the 16MB storage limit for queues, and we found no way around that other than the destruction and recreation of the queue. (We were never convinced that space was released - even on an empty queue with AUTORCL(*YES) specified - but that's another matter entirely.)

Unless the AUTORCL function has been changed such that non-empty queues will be reclaimed, we found the whole management of the queues problematic. A real shame since the user queues are so very fast and light on resource usage but we eventually had to abandom them on high transaction-rate processes (just where they shine the most!).

"Jim Essinger" <dilbernator@xxxxxxxxx> wrote:

I remember from the past that there was a size issue with data queues.
Once
created a que that was very active would gain in size and not release
the
disk/memory that it allocated. To overcome this issue at a previous
employer, we had to delete the que and recreate it so that it would
release
the memory. This gain in memory size effected the length (time) run of
our
night jobs as well as some jobs during the day that used the queues
heavily. This was the IBM recommendation at the time to fix the issue.

I don't know if the current memory usage releases or can be recovered
via
other means after several OS upgrades.


Jim


On Thu, Feb 17, 2011 at 10:51 AM, 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.