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