With shared queue, there is a first-open and last-closed effect which can increase the cost of opening a queue.
When an application opens a share queue, if no other application on that queue manager has the queue open, then the queue manager has to go to the coupling facility to register an interest in the queue, and to get information about the queue. This is the first-open effect.
If the queue manager already has the queue open - it does not need to register, it already has the information, and so saves CPU.
When an application closes a share queue, if no other application on that queue manager has the queue open, then the queue manager has to go to the coupling facility to deregister an interest in the queue. This is the last closed effect.
Some applications naturally have the queue open for a long time, for example a channel, a trigger monitor, and long running applications. For high throughput, short lived transactions, the queue may always have at least one application with the queue open. In these cases the first-open, and last-close effects are not seen.
If you have short running transaction which are not at a high enough throughput to have the queue open all of the time, there may be little or no overlap, and so each transaction can experience the first-open and last- closed effects.
How can I tell?
In MP1B, if you have detail(15) or higher value you will get in the task statistics information like Open CF access 1 Open No CF access 0 and Close CF access 1 Close No CF access 0
The "Open CF access" and "Close CF access" counts tells you that the open and close had the first-open and last-close effects.
For those who want to know the internal details...
- The SMF field opencf0 is the number of opens that did not have the first-open effect.
- The number of opens that had the first open effect is openn- opencf0
- Similarly with close, "Close No CF" access is field closecf0, closed with CF access is closen - closecf0.
Within the queue manager, latches are used to serialize requests. A latch is held across the first-open and last-close operations. If another application wants to open the queue, then it will have to wait for the latch to be released. This latch used is latch 11 DMCSEGAL. As the latch is held across CF requests, a long CF response time, for example an Async request, will lead to long latch times.
What can I do about it?
If you see a large number of first-opens, and last-closes then having a batch job sitting there with the queue open, will eliminate this first-open and last-close effects.
This should greatly reduce the DMCSEGAL latch times. You should also review the CF response times, and check the performance of the structure and the CF to see if you can reduce the CF response times.
What is the impact on multiple queue managers?
The coupling facility is a classic server when discussing queuing. As the number of requests increase, the response time also increases - it might increase by a small amount - such as 10% - or on a very busy server it can double the response time.
Having multiple queue managers, with the first-open, last-closed effect will increase the response time because of the increased number of CF requests.
If all queue managers use have a batch job which does nothing, but keep the queue open, this should eliminate many CF requests, and so all applications using the structure should benefit - and will reduce the CPU used!
MP16 has been updated to include CPU figures search for first-open from MP16
At the title of the blog post says - having a job which does nothing can save you CPU!