Get with wait interval

veeruspi · New User Joined: 29 Dec 2005 Posts: 16 Location: mysore

Does get with wait interval takes exclusive control of the queue? Suppose I have ten transactions running. If a transaction has issued get with wait interval of 5 minutes, can the other transaction still put the message on to the same queue?

Garry Carroll · Posted: Fri Mar 18, 2011 7:57 pm

MQGET with WaitInterval does not prevent other applications accessing the queue. Typical non-triggering client/server scenario is that the server application has an outstanding MQGET-wait which is waiting for a client application to issue an MQPUT(1). If MQGET 'blocked' the queue, the client wouldn't be able to MQPUT(1) its message.

If using MQ-triggering to launch the server application, having a waited MQGET in the server app is pointless - the message will be retrieved immediately. WaitInterval specifies the maximum time to wait for a message to satisfy an MQGET. A message arriving during that WaitInterval will be processed immediately. The MQGET will timeout if no message arrives during the WaitInterval.

Garry.

veeruspi · New User Joined: 29 Dec 2005 Posts: 16 Location: mysore

Hi Garry,
Thanks for your quick response. So you mean to say that, there wont be any problem in terms of accessing the same queue to put a message by using other transactions.
I am new to this MQ stuffs. By going through the concepts I am coding programs. I would like to know the exact answers for the below questions. I tried to find the answers in forums but could not understand.

1. Whats the difference between signalling and MQGET with wait? Theoretically I know that signalling is to signal a perticular transaction when reply message arrives on to a queue and MQGET with wait is waiting for a peticular message to arrive in the queue. But for my requirement, there will be on an average 10 transactions triggered per minute. So is using signalling a better option over using MQGET with wait?

2. When do we code MQRO-COPY-MSG-ID-TO-CORREL-ID? In my program I have added MQPMO-NEW-MSG-ID to MQPMO-OPTIONS and I have generated new message id while putting a message onto request queue. This new msg id I have stored in a temporary variable and have moved it to MQMD-CORRELID and used MQMO-MATCH-CORREL-ID in MQGMO-MATCHOPTIONS while retrieving from queue. I need to know when exactly we have to use MQRO-COPY-MSG-ID-TO-CORREL-ID.

3. If we use CICS Delay between retrieving a message from queue1 and putting a message onto queue2, will the queues be blocked for other transaction from accessing these queues?

Your responses on these will be very useful.

Thanks
Veeru

Garry Carroll · Posted: Mon Mar 21, 2011 12:59 pm

Hi Veeru,

1. I'm not sure what you mean by signalling. In my shop we use two techniques - either triggering or a long-running application.

For triggering, an application is launched for each message arriving. In this case, the server application issues a single MQGET with no WaitInterval, processes the message, MQPUT1 the reply and terminates.

For high volume, I prefer to use a long-running server application. This issues MQGET with WaitInterval and with MQMD.MsgId set to MQMI-NONE and MQMD.CorrelId set to MQCI-NONE. This will get any message that arrives and process it, then loop back and issue another MQGET for the next message and so on. Typically, the long-running task interrogates the message content and spawns a background task to process. As it happens, this is how triggering under CICS works, so you save the MQPUT and MQGET of the trigger message. Code fairly long WaitIntervals to reduce cpu consumption during quiet periods.

2. I don't use MQRO-COPY-MSG-ID-TO-CORREL-ID. In my applications I code a move to put the inbound MsgId into the outbound CorrelId just befor the MQPUT1. It doesn't matter where the move is made once it's before the MQPUT1.

3. No. EXEC CICS DELAY only affects the instance of the executing program from a CICS perspective and has no blocking effect on MQ queues. I don't see why you would want such a delay, however.

Garry.