×
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
midrange.com
