[Info-vax] MQ series client support AST?

[rockdale]

> If I'm not wrong, you could also read from the MQ-queue
> with a timeout, that is, you are stuck in the read until
> something arrivs on the queue *or* the timeout "times-out".
> At timeout you can just re-issue the read operation.

What I am using is the classic Hein(according to Hein). In a while
loop, I do mqget, if returns data then process the data , if nothing
returns, sleep 1 sec do mqget again...

My application major task is to transmit messages between two systems
(let's call them MQ server and system B), MQ server have 2 queues, one
for my application read from, another one is for my application write
to. My application read a message from MQ server, process the message,
send this message to system B via tcp/ip socket connection. At the
same time, when my application receive a message from system B via tcp/
ip socket(here we are using sys at qio and ast), my appl process the
message and then put(mqput) it into the MQ server.

I also have a stateFlag to show the current status of MQ
communication, IDLE, GET or PUT to avoid race condition, before mqget
if the stateFlag is PUT, then I will skip this mqget, this is where my
customer does not like it and the ast question comes up.

Does the flag to avoid race condition necessary? since they are not
the same queue. (forgive my ignorance, MQ and OpenVMS are very new to
me.)

I was think to use multi threads for this situation, sprawl another
thread to poll and read from the mq server. But if I still need to
handle the race condition, does multi-threads do any good to this
situation?

Thanks for all your help
-Rockdale







On Dec 10, 9:54 pm, Hein RMS van den Heuvel
<heinvandenheu... at gmail.com> wrote:
> On Dec 10, 2:08 pm, Jan-Erik Söderholm <jan-erik.soderh... at telia.com>
> wrote:
>
> > rockdale wrote:
> > > Hi all:
>
> > > I have a c application running on openvms and reading messages from MQ
> > > Server on a windows machine. Right now, the application is polling the
> > > message but now we want to change it to AST enabled:
> :
> > If I'm not wrong, you could also read from the MQ-queue
> > with a timeout, that is, you are stuck in the read until
> > something arrivs on the queue *or* the timeout "times-out".
> > At timeout you can just re-issue the read operation.
>
> Correct. That's how my customers typically uses MQ.
> That gives you pretty much immediate control back when a message
> arrives and give you a chance to look at other stuff every so often.
> Now I was told it blocks AST while GETting, but never had a reason to
> verify that. It made my customer opt for a short timeout and check
> shutdown flags and the likes. Short (a few seconds) timeouts of course
> incur more overhead.
>
> Besides the basic GET you can also program INQuires to peek ahead in
> the queue and fun stuff like that.
>
> What you do NOT want to do is a classic poll where you try a GET and
> go to sleep for a while if nothing found, to retry later.
>
> Hein.
>
> fwiw,
> Hein.