I use data queues for many purposes and in many mission-critical applications, so whenever IBM announces additions and changes to data queues, I pay attention. With release 6.1, two new data queue attributes were added, and one new data queue API was introduced. The new Change Data Queue (QMHQCDQ) API was partially prompted by the Enforce data queue locks attribute added, because the QMHQCDQ API is currently the only available option when it comes to setting this attribute; you cannot specify it when you create a data queue. I cover more about the Enforce data queue locks attribute later in this article.
The QMHQCDQ API currently supports changing one more data queue attribute, the Automatic reclaim attribute defining whether the allocated storage of the data queue should be reclaimed whenever the last entry in the data queue is removed. This attribute is, however, also available when you create a data queue, but you now have the option of changing it, without having to re-create the data queue. The second attribute added to data queues at release 6.1 is a timestamp registering the point in time the data queue last had its storage automatically reclaimed. These new data queue features inspired me to make corresponding improvements to my previously published data queue commands as well as create the new Change Data Queue (CHGDTAQ) CL command.
The Enforce data queue locks attribute lets you ensure that object locks obtained using the Allocate Object (ALCOBJ) command are honored by all IBM-supplied data queue operations, being provided by means of Data Queue APIs and Queue MI instructions and built-ins. At releases prior to 6.1, you could control access to data queues within an application in terms of application design. By attempting to place an object lock on a data queue object prior to performing an exclusive data queue operation, you would discover whether a lock had already been obtained and be able to act appropriately in order to serialize or abandon access to the data queue.
Nothing would, however, prevent you from performing a data queue operation against the data queue without obtaining an object lock first. So whether such an attempt was made on purpose or by mistake, the object lock would not cause it to fail, and therefore it would succeed if no formal errors were encountered. The new enforce locks attribute, however, lets you ensure that object locks are not circumvented when native data queue operations are performed. Setting this attribute to *YES causes the data queue operations to check for lock conditions on the data queue object prior to carrying out the operation. Apart from backward compatibility, the reason this behavior is not simply implemented by default is of course the performance penalty incurred by the object lock condition check.
So for performance-critical and high-volume transaction applications, careful benchmark tests should be included early on in the application design phase, in case the new Enforce data queue locks attribute is part of your design.
Articles on Apis 