[Info-vax] MQ series client support AST?

[seasoned_geek]

On Dec 10, 5:29 pm, Jan-Erik Söderholm <jan-erik.soderh... at telia.com>
wrote:
> seasoned_geek wrote:
> > I've written many MQ Series applications on OpenVMS.  Traditionally I
> > have a trigger attached to the queue which fires EACH.  Normally my
> > back end application is a series of ACMS servers so the MQ Trigger is
> > simply a command file which issues an ACMS_QUEUE_TASK with an ACMS
> > task name.
>
> What is the overhead of the trigger on VMS ?
> Does it include process creation/image activation ?
> Or could you have some process waiting for the trigger to happen ?

I have never had to measure or worry about the overhead of the
trigger.  I run a command file which interprets some logicals and
symbols, then executes a foreign symbol to perform a single
ACMS_QUEUE_TASK() call.

>
> In what way is a trigger better then to have a process
> waiting in the MQGET call ? That would, as I understand,
> at least give you low latency, not ?

A trigger is always better.

A GET with timeout is allocating a lot of slot in the system.  You are
also making the grand assumption that the your one and only read
process will never crash, enter a deadly embrace, or have a race
condition.

I use ACMS servers and have the limits normally set to a min of 3 and
a max of 7.  If any server instance fails for any reason DECdtm will
ensure the message is re-instated in the MQ queue.  ACMS will ensure
the queued task is retried by a different server.  If all of my output
is into RDB as a single transaction, RDB will have automatically been
cleaned up as well.

Your stand alone EXE can't do any of that.

After a task has been requeued N times, it will be placed on the error
queue.  I will receive email letting me know bad things have
happened.  I can then dig into the logs and the error queue to see
what is wrong.

Your stand alone EXE can't do that.

>
> We are not using ACMS, if that matters...
>
> Jan-Erik.