[Info-vax] MQ on Alpha ?

[Jan-Erik Söderholm]

Hein RMS van den Heuvel wrote:
 > On Dec 10, 3:00 pm, Jan-Erik Söderholm <jan-erik.soderh... at telia.com>
 > wrote:
 >> Hi !
 >>
 >> We are investigating using MQ on a couple of Alpha's.
 >>
 >> There are a few things that my browsning of the docs
 >> didn't seemed to answer...
 >>
 >> Do I need the Java kit on the Alpha's ?
 >
 > There are Java based MQ tools, to help monitor and manager.
 > You'd typically run those on a PC.
 >

OK. So those Tivoli based tools the MQ-folkes are talking about
doesn't need to be runed on the VMS systems itself ? So they can
run it elseware (they have a large MQ environment on other
systems) and monitor the MQ/VMS instance remotely ?

 > There are many ways to use and abuse MQ.
 > Some use it just as cross platform RPC.
 > Some applications do not require the guaranteed, persistent messages.
 > 'what is the price of gold right now, and if you don't have an answer
 > in 2 seconds, then never mind'
 >
 > For some applications it would seem better to have VMS do what it is
 > good had (securely manage the business data) and not load it up with
 > having to run the MQ manager as well. For those client mode my well be
 > best.

The "message" from the MQ-folks is that 1. "we do not install the
client kit today" and 2. "MQ is the standard integration platform".

 >
 > An other input might be that while MQ appears to support OpenVMS
 > relatively well (using HP resources in India), it may support other
 > platforms better. The very capable folks in Hursley don't know too
 > much about the OpenVMS implementation.

And from the other MQ tread (about GET with wait):

 > 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.

And this workes just as well using the client-kit, right ?
As far as I've understood, the programming interface is mostly
(or fully) the same using the client or the full install. It's
just that the "queues" are on another system inthe client case !?.
And the "triggers" doesn't work in a client-only server, right ?

We do have a V2-something client kit today, and one way could be
to simply upgrade it to a V6 client kit. That would simplify things
and there would be no reason to monitor MQ on the VMS system.

 > 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.

Agree... :-)

Very good input. Thanks !

Jan-Erik.

 >
 > fwiw,
 > Hein.