MQSeries.net :: View topic

paul jackson · Posted: Tue Feb 12, 2002 2:48 pm Post subject:

We need to get our BASE24 system talking to MQ Series. I know that ACI have an MQ Interface product but I'm not really sure there's much advantage in using it.

I am looking at modifying a BASE24 Interchange Interface to talk to MQ Series. We would probably have 16 MQ interface processes all talking to one MQ Manager (and one queue).

This introduces a third input stream to the interface, the others being XPNET and $RECEIVE. At the heart of the interface is the call to RCV^AWAITIO, which returns on timeout/XPNET msg/XPNET stop/external msg/IO completion.
We would modify the loop that calls RCV^AWAITIO; before returning to the top of
the loop and the next call we would do an MQGET and if an MQ message is returned, process it.

The particular problem is how to alert the interface that an MQ message needs to be processed. RCV^AWAITIO is waited so only returns on receipt of an IPC or an XPNET message. To access MQ, the "Poll every n seconds" or "a waited MQGET" options don't fit in with how RCV^AWAITIO works.

So its preferable to use the signal option of MQGET, causing the MQ manager to alert the proc via $RECEIVE when an MQ message is waiting (assuming queue empty
when the call is done). This fits in with RCV^AWAITIO's processing. But only one proc can have an outstanding signal to MQ. What if that proc goes down ? We would then have 15 other processes potentially waiting on their RCV^AWAITIO calls to complete before the outstanding MQ message is picked up by one of them.

Another problem is receiving a burst of messages from MQ after a quiescent period. The one "signal" proc is alerted and will process the first message, but the other procs could again be waiting on RCV^AWAITIO to complete.

Is this something to be concerned about ? I appreciate that the proc could set short timers so it would cycle round to the next MQGET quicker - but that's a clumsy patch to a design issue, apart from the processing overhead it adds.

One solution for the burst processing is for the signalled process to alert one or more other processes, i.e. send a message to the other proc(s) forcing RCV^AWAITIO to complete at which point it will call MQGET. Doesn't solve the dying proc problem though.

If we didn't want to use the alert we could maybe do a control 27 on an MQ queue file which would tell us that a message has come in. But from what I can tell, this prevents us from using non-persistent messaging which doesn't write messages to file, unless anyone knows different.

I was also trying to avoid having some front-end distributor which either passes the MQ message to the BASE24 interface or alerts it. However - maybe this would be the way to go ?

Has anyone else used BASE24 to interface direct to MQ Series ?

TIA

Paul