× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.



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

As an Amazon Associate we earn from qualifying purchases.

This thread ...

Follow-Ups:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2024 by midrange.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 on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.