The ups and downs of MQ Reconnect – little problems

This is one topic in a series of blog posts.

Your error messages contain the wrong queue manager name

  • You have an application which does
  • MQCONNX
  • MQINQ queue manager – get queue manager name
  • MQOPEN MYREPLY
  • MQOPEN SERVER
  • MQPUT SERVER
  • MQGET MYREPLY
    MQDISC.

You are a professional application programmer, so you used MQINQ to extracted the queue manager name, and produce event messages like.

MQGET from MYREPLY queue on QMA reason code: MQRC_NO_MSG_AVAILABLE

If you reconnected to a different queue manager before the MQGET, your message will be wrong. You will have people looking for a problem on QMA – when the problem was actually on QMC.

In your MQCB exit you can have logic

case MQRC_RECONNECTED:

    printf("%sEVENT : Connection Reconnected\n",TimeStamp);

    MQINQQMNAME(hConn,QMNAME);

    break;

Where the MQINQQMNAME does

MQOPEN on the queue manager object,
MQINQ Selectors[0]=MQCA_Q_MGR_NAME;

and stores the queue manager name in global storage.

Your error message can now use this global storage and report

MQGET from MYREPLY queue on QMC reason code: MQRC_NO_MSG_AVAILABLE

Your error messages still contain the wrong queue manager name

Using the same scenario as above, you look into why there was no reply to be got. The MQADMIN team look at the status of the server queue, and say “the last time a message was put to the server queue was 4 weeks ago. It must be an application bug”.

You need some logic like

MQPUT(...)
PutQMNAME = QMNAME; // from the global storage above 
                    //  this might be QMA

Now if you get no reply message, your error message can be like

MQGET from MYREPLY queue on QMC reason code: MQRC_NO_MSG_AVAILABLE.  Message was put to SERVER queue on QMA at 14:40:23”.

Any MQSETs are not repeated.

If you issue an MQSET, and then reconnect to another queue manager, the MQSET is not repeated.

Best practice is not to use MQSET.

The attributes you can change, are for triggering and inhibit get and inhibit put, all of which would be better done using automation.

There are limitations as to what you can and cannot do.

See here.

For example

  • getting a message under cursor, or in a group.
  • using a message context
  • using a security context.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s