CODEWITHSUNDEEP
javac#message-queueibm-mq
EKrueger
EKrueger

Reputation: 760

What is the difference between IBM MQ's IsOpen and OpenStatus properties on a queue?

The MQQueue object in IBM MQ has properties MQQueue.IsOpen and MQQueue.OpenStatus. Both are inherited from the MQManagedObject class. What do these properties represent and what are the differences between them? Do they show, for example, whether the queue is open for GET, PUT or both?

Unfortunately the docs aren't very clear on these properties. The most helpful description I found are below. Note that these are taken from the ActiveX reference so I don't know how applicable they are.

Source

IsOpen property

Returns whether the queue is open.

Read-only.

Source

OpenStatus property

Read-only. Indicates if the queue is opened or not. Initial value is TRUE after AccessQueue method or FALSE after New.

In a next step I debugged the amqmdnet.dll which showed the following implementations for the properties:

public bool IsOpen
{
  get
  {
    return this.objectHandle != null && this.objectHandle.HOBJ != null && (this.objectHandle.HOBJ.Handle != 0 && -1 != this.objectHandle.HOBJ.Handle);
  }
}

public bool OpenStatus
{
  get
  {
    bool flag = false;
    if (this.qMgr != null && this.qMgr.IsConnected)
      flag = !this.isClosed;
    return flag;
  }
}

Although I tend toward using OpenStatus I'm still looking for educated advice. I'm especially unsure what the IsOpen property actually represents. Is it relevant when telling whether the queue instance is open for put and get calls?

Upvotes: 1

Views: 764

Answers (1)

JasonE
JasonE

Reputation: 2026

I dont think there's any better documentation, but in effect:

IsOpen tells you if the open call itself has been successful, ie there is an associated handle being maintained for the queue.

OpenStatus tells you whether there is a valid connection to the queue manager AND the object is also open.

From that, I'd probably veer towards OpenStatus as you suggest, if you want to know if there is a best chance of using the object. I would also echo Morag and Roger's comments, that better exception handling and understanding of state should be a far better approach.

Upvotes: 3

Related Questions