Discussion:
Different queue, same process and not triggering
Jantje .
2014-07-10 15:58:30 UTC
Permalink
Esteemed Listers,

Windows Server 2008 R2 Standard
WebSphere MQ 7.1.0.5


I see some very strange behaviour with the triggering, I have put in place. I have three separate process definitions and a number of queues referencing these process definitions, all using the same SYSTEM.DEFAULT.INITIATION.QUEUE for initiation. I use the standard trigger monitor runmqtrm that comes with the product and have it running as a service, defined in the list of services of the queue manager. It is listening for trigger messages and does invoke my applications... most of the time...

My applications are designed for trigger-first: they linger on when the work is done, by doing another MQGET with wait when the first message that triggered them is processed. MQCOMMIT is being called at the right time in the program logic; I have checked that...

All process definitions are set up to invoke the same .cmd file; distinction being made by using the environment data passed as an argument into that command file in order to know what the program actually needs to do. The main program is a standard ANSI C program that invokes different C functions, depending on the value of the input argument. The code then uses regular function calls to invoke the different MQI, as per the book. The trigger message, which is also passed as an argument to the command file, is used to determine which queue to open. Messages are gotten off of that queue and processed accordingly. This works all fine and well as long as the messages arrive on queues that trigger different process definitions.

The strange thing is that when a message arrives on a queue that triggers the same process definition as another queue on which that process definition has triggered while the program is lingering, the arrival of a message on one queue, the arrival of a message on the other queue that is supposed to trigger a second process, doesn't.

If that same message arrives on that second queue when the process that was triggered on the first queue has already terminated, then the second queue does trigger the process correctly.

Stranger still: when the triggering does not take place at arrival of the message on the second queue, it is enough to browse that queue (using a program that I have written for the purpose of checking the message contents during testing that does non-destructive MQGET) to have the triggering kick in.

I don't understand...

Do you think I am entitled to a PMR, or am I doing something wrong?

Searching the archives, nor Google turned up any results on my queries.

Thanks for shedding some light on this matter.

Very best regards,

Jantje.


My process definitions:

PROCESS(TQ3.PR.SND)
APPLTYPE(WINDOWSNT)
APPLICID(START
D:\TQS2010\ACC\QTRIG.CMD)
ENVRDATA(SND)
USERDATA( )
DESCR(Send)

PROCESS(TQ3.PR.RCV)
APPLTYPE(WINDOWSNT)
APPLICID(START
D:\TQS2010\ACC\QTRIG.CMD)
ENVRDATA(RCV)
USERDATA( )
DESCR(Receive)


My queue defintions:

QUEUE(TQ3.QL.SND.TNLA2)
TYPE(QLOCAL)
ACCTQ(QMGR)
BOQNAME( )
BOTHRESH(0)
CLUSNL( )
CLUSTER( )
CLWLPRTY(0)
CLWLRANK(0)
CLWLUSEQ(QMGR)
CURDEPTH(0)
CUSTOM( )
DEFBIND(OPEN)
DEFPRTY(0)
DEFPSIST(YES)
DEFPRESP(SYNC)
DEFREADA(NO)
DEFSOPT(SHARED)
DEFTYPE(PREDEFINED)
DESCR(From Migration)
DISTL(NO)
GET(ENABLED)
NOHARDENBO
INITQ(SYSTEM.DEFAULT.INITIATION.QUEUE)
IPPROCS(0)
MAXDEPTH(50000)
MAXMSGL(131072)
MONQ(QMGR)
MSGDLVSQ(PRIORITY)
TRIGGER
NPMCLASS(NORMAL)
OPPROCS(0)
PROCESS(TQ3.PR.SND)
PUT(ENABLED)
PROPCTL(COMPAT)
QDEPTHHI(5)
QDEPTHLO(2)
QDPHIEV(DISABLED)
QDPLOEV(DISABLED)
QDPMAXEV(ENABLED)
QSVCIEV(NONE)
QSVCINT(999999999)
RETINTVL(999999999)
SCOPE(QMGR)
SHARE
STATQ(QMGR)
TRIGDATA( )
TRIGDPTH(1)
TRIGMPRI(0)
TRIGTYPE(FIRST)
USAGE(NORMAL)


QUEUE(TQ3.QL.ENV.TNLA2.R1)
TYPE(QLOCAL)
ACCTQ(QMGR)
BOQNAME( )
BOTHRESH(0)
CLUSNL( )
CLUSTER( )
CLWLPRTY(0)
CLWLRANK(0)
CLWLUSEQ(QMGR)
CURDEPTH(0)
CUSTOM( )
DEFBIND(OPEN)
DEFPRTY(0)
DEFPSIST(YES)
DEFPRESP(SYNC)
DEFREADA(NO)
DEFSOPT(SHARED)
DEFTYPE(PREDEFINED)
DESCR(Envelopes)
DISTL(NO)
GET(ENABLED)
NOHARDENBO
INITQ(SYSTEM.DEFAULT.INITIATION.QUEUE)
IPPROCS(0)
MAXDEPTH(50000)
MAXMSGL(4194304)
MONQ(QMGR)
MSGDLVSQ(PRIORITY)
TRIGGER
NPMCLASS(NORMAL)
OPPROCS(0)
PROCESS(TQ3.PR.RCV)
PUT(ENABLED)
PROPCTL(COMPAT)
QDEPTHHI(5)
QDEPTHLO(2)
QDPHIEV(DISABLED)
QDPLOEV(DISABLED)
QDPMAXEV(ENABLED)
QSVCIEV(NONE)
QSVCINT(999999999)
RETINTVL(999999999)
SCOPE(QMGR)
SHARE
STATQ(QMGR)
TRIGDATA( )
TRIGDPTH(1)
TRIGMPRI(0)
TRIGTYPE(FIRST)
USAGE(NORMAL)


QUEUE(TQ3.QL.ACC.SPIL.OUT)
TYPE(QLOCAL)
ACCTQ(QMGR)
BOQNAME( )
BOTHRESH(0)
CLUSNL( )
CLUSTER( )
CLWLPRTY(0)
CLWLRANK(0)
CLWLUSEQ(QMGR)
CURDEPTH(0)
CUSTOM( )
DEFBIND(OPEN)
DEFPRTY(0)
DEFPSIST(YES)
DEFPRESP(SYNC)
DEFREADA(NO)
DEFSOPT(SHARED)
DEFTYPE(PREDEFINED)
DESCR(SPIL outbound)
DISTL(NO)
GET(ENABLED)
NOHARDENBO
INITQ(SYSTEM.DEFAULT.INITIATION.QUEUE)
IPPROCS(0)
MAXDEPTH(50000)
MAXMSGL(4194304)
MONQ(QMGR)
MSGDLVSQ(PRIORITY)
TRIGGER
NPMCLASS(NORMAL)
OPPROCS(1)
PROCESS(TQ3.PR.RCV)
PUT(ENABLED)
PROPCTL(COMPAT)
QDEPTHHI(5)
QDEPTHLO(2)
QDPHIEV(DISABLED)
QDPLOEV(DISABLED)
QDPMAXEV(ENABLED)
QSVCIEV(NONE)
QSVCINT(999999999)
RETINTVL(999999999)
SCOPE(QMGR)
SHARE
STATQ(QMGR)
TRIGDATA( )
TRIGDPTH(1)
TRIGMPRI(0)
TRIGTYPE(FIRST)
USAGE(NORMAL)


My trigger monitor definition:

DEFINE SERVICE ('TQS.TRIGGER.MONITOR.ACC') +
DESCR('TQS Trigger Monitor for ACC') +
STARTCMD('C:\Program Files (x86)\IBM\WebSphere MQ\bin\runmqtrm.exe') +
STARTARG('-m +QMNAME+ -q SYSTEM.DEFAULT.INITIATION.QUEUE') +
STOPCMD('C:\Program Files (x86)\IBM\WebSphere MQ\bin\amqsstop.exe') +
STOPARG('-m +QMNAME+ -p +MQ_SERVER_PID+') +
STDOUT('D:\IBM\WMQ\errors\TQS.TRIGGER.MONITOR.DEV.stdout.log') +
STDERR('D:\IBM\WMQ\errors\TQS.TRIGGER.MONITOR.DEV.stderr.log') +
CONTROL(QMGR) +
SERVTYPE(SERVER) +
REPLACE

To unsubscribe, write to LISTSERV-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org and,
in the message body (not the subject), write: SIGNOFF MQSERIES
Roger Lacroix
2014-07-10 16:06:47 UTC
Permalink
Hello Jantje,

> The strange thing is that when a message arrives on a queue that
triggers the same process definition as another queue on which that
process definition has triggered while the program is lingering, the
arrival of a message on one queue, the arrival of a message on the
other queue that is supposed to trigger a second process, doesn't.

Yes, that IS exactly what is supposed to happen. If you use Trigger
First then your application is NOT suppose to linger. It is supposed
to use MQGET with no wait option and exit immediately when it is done
processing the message.

Also, if your application is using MQGET with wait then why aren't
you retrieving the new message while your application is lingering?
Do you clear the MsgID and CorrelID before doing the next MQGET call?

Regards,
Roger Lacroix
Capitalware Inc.

At 11:58 AM 7/10/2014, you wrote:
>Esteemed Listers,
>
>Windows Server 2008 R2 Standard
>WebSphere MQ 7.1.0.5
>
>
>I see some very strange behaviour with the triggering, I have put in
>place. I have three separate process definitions and a number of
>queues referencing these process definitions, all using the same
>SYSTEM.DEFAULT.INITIATION.QUEUE for initiation. I use the standard
>trigger monitor runmqtrm that comes with the product and have it
>running as a service, defined in the list of services of the queue
>manager. It is listening for trigger messages and does invoke my
>applications... most of the time...
>
>My applications are designed for trigger-first: they linger on when
>the work is done, by doing another MQGET with wait when the first
>message that triggered them is processed. MQCOMMIT is being called
>at the right time in the program logic; I have checked that...
>
>All process definitions are set up to invoke the same .cmd file;
>distinction being made by using the environment data passed as an
>argument into that command file in order to know what the program
>actually needs to do. The main program is a standard ANSI C program
>that invokes different C functions, depending on the value of the
>input argument. The code then uses regular function calls to invoke
>the different MQI, as per the book. The trigger message, which is
>also passed as an argument to the command file, is used to determine
>which queue to open. Messages are gotten off of that queue and
>processed accordingly. This works all fine and well as long as the
>messages arrive on queues that trigger different process definitions.
>
>The strange thing is that when a message arrives on a queue that
>triggers the same process definition as another queue on which that
>process definition has triggered while the program is lingering, the
>arrival of a message on one queue, the arrival of a message on the
>other queue that is supposed to trigger a second process, doesn't.
>
>If that same message arrives on that second queue when the process
>that was triggered on the first queue has already terminated, then
>the second queue does trigger the process correctly.
>
>Stranger still: when the triggering does not take place at arrival
>of the message on the second queue, it is enough to browse that
>queue (using a program that I have written for the purpose of
>checking the message contents during testing that does
>non-destructive MQGET) to have the triggering kick in.
>
>I don't understand...
>
>Do you think I am entitled to a PMR, or am I doing something wrong?
>
>Searching the archives, nor Google turned up any results on my queries.
>
>Thanks for shedding some light on this matter.
>
>Very best regards,
>
>Jantje.
>
>
>My process definitions:
>
>PROCESS(TQ3.PR.SND)
> APPLTYPE(WINDOWSNT)
> APPLICID(START
> D:\TQS2010\ACC\QTRIG.CMD)
> ENVRDATA(SND)
> USERDATA( )
> DESCR(Send)
>
>PROCESS(TQ3.PR.RCV)
> APPLTYPE(WINDOWSNT)
> APPLICID(START
> D:\TQS2010\ACC\QTRIG.CMD)
> ENVRDATA(RCV)
> USERDATA( )
> DESCR(Receive)
>
>
>My queue defintions:
>
> QUEUE(TQ3.QL.SND.TNLA2)
> TYPE(QLOCAL)
> ACCTQ(QMGR)
> BOQNAME( )
> BOTHRESH(0)
> CLUSNL( )
> CLUSTER( )
> CLWLPRTY(0)
> CLWLRANK(0)
> CLWLUSEQ(QMGR)
> CURDEPTH(0)
> CUSTOM( )
> DEFBIND(OPEN)
> DEFPRTY(0)
> DEFPSIST(YES)
> DEFPRESP(SYNC)
> DEFREADA(NO)
> DEFSOPT(SHARED)
> DEFTYPE(PREDEFINED)
> DESCR(From Migration)
> DISTL(NO)
> GET(ENABLED)
> NOHARDENBO
> INITQ(SYSTEM.DEFAULT.INITIATION.QUEUE)
> IPPROCS(0)
> MAXDEPTH(50000)
> MAXMSGL(131072)
> MONQ(QMGR)
> MSGDLVSQ(PRIORITY)
> TRIGGER
> NPMCLASS(NORMAL)
> OPPROCS(0)
> PROCESS(TQ3.PR.SND)
> PUT(ENABLED)
> PROPCTL(COMPAT)
> QDEPTHHI(5)
> QDEPTHLO(2)
> QDPHIEV(DISABLED)
> QDPLOEV(DISABLED)
> QDPMAXEV(ENABLED)
> QSVCIEV(NONE)
> QSVCINT(999999999)
> RETINTVL(999999999)
> SCOPE(QMGR)
> SHARE
> STATQ(QMGR)
> TRIGDATA( )
> TRIGDPTH(1)
> TRIGMPRI(0)
> TRIGTYPE(FIRST)
> USAGE(NORMAL)
>
>
>QUEUE(TQ3.QL.ENV.TNLA2.R1)
> TYPE(QLOCAL)
> ACCTQ(QMGR)
> BOQNAME( )
> BOTHRESH(0)
> CLUSNL( )
> CLUSTER( )
> CLWLPRTY(0)
> CLWLRANK(0)
> CLWLUSEQ(QMGR)
> CURDEPTH(0)
> CUSTOM( )
> DEFBIND(OPEN)
> DEFPRTY(0)
> DEFPSIST(YES)
> DEFPRESP(SYNC)
> DEFREADA(NO)
> DEFSOPT(SHARED)
> DEFTYPE(PREDEFINED)
> DESCR(Envelopes)
> DISTL(NO)
> GET(ENABLED)
> NOHARDENBO
> INITQ(SYSTEM.DEFAULT.INITIATION.QUEUE)
> IPPROCS(0)
> MAXDEPTH(50000)
> MAXMSGL(4194304)
> MONQ(QMGR)
> MSGDLVSQ(PRIORITY)
> TRIGGER
> NPMCLASS(NORMAL)
> OPPROCS(0)
> PROCESS(TQ3.PR.RCV)
> PUT(ENABLED)
> PROPCTL(COMPAT)
> QDEPTHHI(5)
> QDEPTHLO(2)
> QDPHIEV(DISABLED)
> QDPLOEV(DISABLED)
> QDPMAXEV(ENABLED)
> QSVCIEV(NONE)
> QSVCINT(999999999)
> RETINTVL(999999999)
> SCOPE(QMGR)
> SHARE
> STATQ(QMGR)
> TRIGDATA( )
> TRIGDPTH(1)
> TRIGMPRI(0)
> TRIGTYPE(FIRST)
> USAGE(NORMAL)
>
>
>QUEUE(TQ3.QL.ACC.SPIL.OUT)
> TYPE(QLOCAL)
> ACCTQ(QMGR)
> BOQNAME( )
> BOTHRESH(0)
> CLUSNL( )
> CLUSTER( )
> CLWLPRTY(0)
> CLWLRANK(0)
> CLWLUSEQ(QMGR)
> CURDEPTH(0)
> CUSTOM( )
> DEFBIND(OPEN)
> DEFPRTY(0)
> DEFPSIST(YES)
> DEFPRESP(SYNC)
> DEFREADA(NO)
> DEFSOPT(SHARED)
> DEFTYPE(PREDEFINED)
> DESCR(SPIL outbound)
> DISTL(NO)
> GET(ENABLED)
> NOHARDENBO
> INITQ(SYSTEM.DEFAULT.INITIATION.QUEUE)
> IPPROCS(0)
> MAXDEPTH(50000)
> MAXMSGL(4194304)
> MONQ(QMGR)
> MSGDLVSQ(PRIORITY)
> TRIGGER
> NPMCLASS(NORMAL)
> OPPROCS(1)
> PROCESS(TQ3.PR.RCV)
> PUT(ENABLED)
> PROPCTL(COMPAT)
> QDEPTHHI(5)
> QDEPTHLO(2)
> QDPHIEV(DISABLED)
> QDPLOEV(DISABLED)
> QDPMAXEV(ENABLED)
> QSVCIEV(NONE)
> QSVCINT(999999999)
> RETINTVL(999999999)
> SCOPE(QMGR)
> SHARE
> STATQ(QMGR)
> TRIGDATA( )
> TRIGDPTH(1)
> TRIGMPRI(0)
> TRIGTYPE(FIRST)
> USAGE(NORMAL)
>
>
>My trigger monitor definition:
>
>DEFINE SERVICE ('TQS.TRIGGER.MONITOR.ACC') +
> DESCR('TQS Trigger Monitor for ACC') +
> STARTCMD('C:\Program Files (x86)\IBM\WebSphere MQ\bin\runmqtrm.exe') +
> STARTARG('-m +QMNAME+ -q SYSTEM.DEFAULT.INITIATION.QUEUE') +
> STOPCMD('C:\Program Files (x86)\IBM\WebSphere MQ\bin\amqsstop.exe') +
> STOPARG('-m +QMNAME+ -p +MQ_SERVER_PID+') +
> STDOUT('D:\IBM\WMQ\errors\TQS.TRIGGER.MONITOR.DEV.stdout.log') +
> STDERR('D:\IBM\WMQ\errors\TQS.TRIGGER.MONITOR.DEV.stderr.log') +
> CONTROL(QMGR) +
> SERVTYPE(SERVER) +
> REPLACE
>
>To unsubscribe, write to LISTSERV-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org and,
>in the message body (not the subject), write: SIGNOFF MQSERIES
>Instructions for managing your mailing list subscription are provided in
>the Listserv General Users Guide available at http://www.lsoft.com
>Archive: http://listserv.meduniwien.ac.at/archives/mqser-l.html

To unsubscribe, write to LISTSERV-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org and,
in the message body (not the subject), write: SIGNOFF MQSERIES
Instructions for managing your mailing list subscription are provided in
the Listserv General Users Guide available at http://www.lsoft.com
Archive: http://listserv.meduniwien.ac.at/archives/mqser-l.html
Jefferson Lowrey
2014-07-10 16:17:34 UTC
Permalink
Uhm.

A trigger First application is supposed to make sure that the triggered
queue is entirely empty before it quits, such that the next time a new
message is added, it will be the first message.

A trigger Every is supposed to read a single message and then quit. But
trigger every is not reliable outside of zOS.

Jantje is properly using START to ensure that the trigger monitor is not
waiting for one triggered application to complete before it starts
another.

Jantje - can you be more clear on the issue. Is the program failing to
start? Or is the queue manager simply not generating a message on the
initiation queue?

If the queue manager is not generating a message on the initiation queue,
then you need to review
http://www-01.ibm.com/support/knowledgecenter/SSFKSJ_7.5.0/com.ibm.mq.dev.doc/q026930_.htm?lang=en
in detail and check off all conditions one by one.

Thank you,

Jeff Lowrey




From: Roger Lacroix <roger.lacroix-***@public.gmane.org>
To: MQSERIES-JX7+OpRa80QeFbOYke1v4oOpTq8/***@public.gmane.org
Date: 07/10/2014 11:08 AM
Subject: Re: [MQSERIES] Different queue, same process and not
triggering
Sent by: MQSeries List <MQSERIES-JX7+OpRa80QeFbOYke1v4oOpTq8/***@public.gmane.org>



Hello Jantje,

> The strange thing is that when a message arrives on a queue that
triggers the same process definition as another queue on which that
process definition has triggered while the program is lingering, the
arrival of a message on one queue, the arrival of a message on the other
queue that is supposed to trigger a second process, doesn't.

Yes, that IS exactly what is supposed to happen. If you use Trigger First
then your application is NOT suppose to linger. It is supposed to use
MQGET with no wait option and exit immediately when it is done processing
the message.

Also, if your application is using MQGET with wait then why aren't you
retrieving the new message while your application is lingering? Do you
clear the MsgID and CorrelID before doing the next MQGET call?

Regards,
Roger Lacroix
Capitalware Inc.

At 11:58 AM 7/10/2014, you wrote:
Esteemed Listers,

Windows Server 2008 R2 Standard
WebSphere MQ 7.1.0.5


I see some very strange behaviour with the triggering, I have put in
place. I have three separate process definitions and a number of queues
referencing these process definitions, all using the same
SYSTEM.DEFAULT.INITIATION.QUEUE for initiation. I use the standard trigger
monitor runmqtrm that comes with the product and have it running as a
service, defined in the list of services of the queue manager. It is
listening for trigger messages and does invoke my applications... most of
the time...

My applications are designed for trigger-first: they linger on when the
work is done, by doing another MQGET with wait when the first message that
triggered them is processed. MQCOMMIT is being called at the right time in
the program logic; I have checked that...

All process definitions are set up to invoke the same .cmd file;
distinction being made by using the environment data passed as an argument
into that command file in order to know what the program actually needs to
do. The main program is a standard ANSI C program that invokes different C
functions, depending on the value of the input argument. The code then
uses regular function calls to invoke the different MQI, as per the book.
The trigger message, which is also passed as an argument to the command
file, is used to determine which queue to open. Messages are gotten off of
that queue and processed accordingly. This works all fine and well as long
as the messages arrive on queues that trigger different process
definitions.

The strange thing is that when a message arrives on a queue that triggers
the same process definition as another queue on which that process
definition has triggered while the program is lingering, the arrival of a
message on one queue, the arrival of a message on the other queue that is
supposed to trigger a second process, doesn't.

If that same message arrives on that second queue when the process that
was triggered on the first queue has already terminated, then the second
queue does trigger the process correctly.

Stranger still: when the triggering does not take place at arrival of the
message on the second queue, it is enough to browse that queue (using a
program that I have written for the purpose of checking the message
contents during testing that does non-destructive MQGET) to have the
triggering kick in.

I don't understand...

Do you think I am entitled to a PMR, or am I doing something wrong?

Searching the archives, nor Google turned up any results on my queries.

Thanks for shedding some light on this matter.

Very best regards,

Jantje.


My process definitions:

PROCESS(TQ3.PR.SND)
APPLTYPE(WINDOWSNT)
APPLICID(START
D:\TQS2010\ACC\QTRIG.CMD)
ENVRDATA(SND)
USERDATA( )
DESCR(Send)

PROCESS(TQ3.PR.RCV)
APPLTYPE(WINDOWSNT)
APPLICID(START
D:\TQS2010\ACC\QTRIG.CMD)
ENVRDATA(RCV)
USERDATA( )
DESCR(Receive)


My queue defintions:

QUEUE(TQ3.QL.SND.TNLA2)
TYPE(QLOCAL)
ACCTQ(QMGR)
BOQNAME( )
BOTHRESH(0)
CLUSNL( )
CLUSTER( )
CLWLPRTY(0)
CLWLRANK(0)
CLWLUSEQ(QMGR)
CURDEPTH(0)
CUSTOM( )
DEFBIND(OPEN)
DEFPRTY(0)
DEFPSIST(YES)
DEFPRESP(SYNC)
DEFREADA(NO)
DEFSOPT(SHARED)
DEFTYPE(PREDEFINED)
DESCR(From Migration)
DISTL(NO)
GET(ENABLED)
NOHARDENBO
INITQ(SYSTEM.DEFAULT.INITIATION.QUEUE)
IPPROCS(0)
MAXDEPTH(50000)
MAXMSGL(131072)
MONQ(QMGR)
MSGDLVSQ(PRIORITY)
TRIGGER
NPMCLASS(NORMAL)
OPPROCS(0)
PROCESS(TQ3.PR.SND)
PUT(ENABLED)
PROPCTL(COMPAT)
QDEPTHHI(5)
QDEPTHLO(2)
QDPHIEV(DISABLED)
QDPLOEV(DISABLED)
QDPMAXEV(ENABLED)
QSVCIEV(NONE)
QSVCINT(999999999)
RETINTVL(999999999)
SCOPE(QMGR)
SHARE
STATQ(QMGR)
TRIGDATA( )
TRIGDPTH(1)
TRIGMPRI(0)
TRIGTYPE(FIRST)
USAGE(NORMAL)


QUEUE(TQ3.QL.ENV.TNLA2.R1)
TYPE(QLOCAL)
ACCTQ(QMGR)
BOQNAME( )
BOTHRESH(0)
CLUSNL( )
CLUSTER( )
CLWLPRTY(0)
CLWLRANK(0)
CLWLUSEQ(QMGR)
CURDEPTH(0)
CUSTOM( )
DEFBIND(OPEN)
DEFPRTY(0)
DEFPSIST(YES)
DEFPRESP(SYNC)
DEFREADA(NO)
DEFSOPT(SHARED)
DEFTYPE(PREDEFINED)
DESCR(Envelopes)
DISTL(NO)
GET(ENABLED)
NOHARDENBO
INITQ(SYSTEM.DEFAULT.INITIATION.QUEUE)
IPPROCS(0)
MAXDEPTH(50000)
MAXMSGL(4194304)
MONQ(QMGR)
MSGDLVSQ(PRIORITY)
TRIGGER
NPMCLASS(NORMAL)
OPPROCS(0)
PROCESS(TQ3.PR.RCV)
PUT(ENABLED)
PROPCTL(COMPAT)
QDEPTHHI(5)
QDEPTHLO(2)
QDPHIEV(DISABLED)
QDPLOEV(DISABLED)
QDPMAXEV(ENABLED)
QSVCIEV(NONE)
QSVCINT(999999999)
RETINTVL(999999999)
SCOPE(QMGR)
SHARE
STATQ(QMGR)
TRIGDATA( )
TRIGDPTH(1)
TRIGMPRI(0)
TRIGTYPE(FIRST)
USAGE(NORMAL)


QUEUE(TQ3.QL.ACC.SPIL.OUT)
TYPE(QLOCAL)
ACCTQ(QMGR)
BOQNAME( )
BOTHRESH(0)
CLUSNL( )
CLUSTER( )
CLWLPRTY(0)
CLWLRANK(0)
CLWLUSEQ(QMGR)
CURDEPTH(0)
CUSTOM( )
DEFBIND(OPEN)
DEFPRTY(0)
DEFPSIST(YES)
DEFPRESP(SYNC)
DEFREADA(NO)
DEFSOPT(SHARED)
DEFTYPE(PREDEFINED)
DESCR(SPIL outbound)
DISTL(NO)
GET(ENABLED)
NOHARDENBO
INITQ(SYSTEM.DEFAULT.INITIATION.QUEUE)
IPPROCS(0)
MAXDEPTH(50000)
MAXMSGL(4194304)
MONQ(QMGR)
MSGDLVSQ(PRIORITY)
TRIGGER
NPMCLASS(NORMAL)
OPPROCS(1)
PROCESS(TQ3.PR.RCV)
PUT(ENABLED)
PROPCTL(COMPAT)
QDEPTHHI(5)
QDEPTHLO(2)
QDPHIEV(DISABLED)
QDPLOEV(DISABLED)
QDPMAXEV(ENABLED)
QSVCIEV(NONE)
QSVCINT(999999999)
RETINTVL(999999999)
SCOPE(QMGR)
SHARE
STATQ(QMGR)
TRIGDATA( )
TRIGDPTH(1)
TRIGMPRI(0)
TRIGTYPE(FIRST)
USAGE(NORMAL)


My trigger monitor definition:

DEFINE SERVICE ('TQS.TRIGGER.MONITOR.ACC') +
DESCR('TQS Trigger Monitor for ACC') +
STARTCMD('C:\Program Files (x86)\IBM\WebSphere MQ\bin\runmqtrm.exe') +
STARTARG('-m +QMNAME+ -q SYSTEM.DEFAULT.INITIATION.QUEUE') +
STOPCMD('C:\Program Files (x86)\IBM\WebSphere MQ\bin\amqsstop.exe') +
STOPARG('-m +QMNAME+ -p +MQ_SERVER_PID+') +
STDOUT('D:\IBM\WMQ\errors\TQS.TRIGGER.MONITOR.DEV.stdout.log') +
STDERR('D:\IBM\WMQ\errors\TQS.TRIGGER.MONITOR.DEV.stderr.log') +
CONTROL(QMGR) +
SERVTYPE(SERVER) +
REPLACE

To unsubscribe, write to LISTSERV-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org and,
in the message body (not the subject), write: SIGNOFF MQSERIES
Instructions for managing your mailing list subscription are provided in
the Listserv General Users Guide available at http://www.lsoft.com
Archive: http://listserv.meduniwien.ac.at/archives/mqser-l.html


List Archive - Manage Your List Settings - Unsubscribe
Instructions for managing your mailing list subscription are provided in
the Listserv General Users Guide available at http://www.lsoft.com

To unsubscribe, write to LISTSERV-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org and,
in the message body (not the subject), write: SIGNOFF MQSERIES
Instructions for managing your mailing list subscription are provided in
the Listserv General Users Guide available at http://www.lsoft.com
Archive: http://listserv.meduniwien.ac.at/archives/mqser-l.html
Potkay, Peter M (CTO Architecture + Engineering)
2014-07-10 16:49:52 UTC
Permalink
Every triggered app needs to read until MQRC 2033, but especially trigger Every applications. If a trigger Every app reads only one messages, its only a matter of time of when, not if but when, you will find yourself with a rolling backlog of messages on the app queue where a new message lands on the app queue, you get triggered, you pick up only one old message and end. Triggered Every apps must read till 2033.

Triggered First apps should too, but there its not such a problem if the app only reads one and done, because in this case IBM made the queue retrigger if its closed with more than zero messages on it. If you find yourself with the backlog and you only consume one when you get triggered, you will retrigger rapidly until the back log is cleared. This does not happen for trigger every and trigger depth, hence the importance of reading until 2033.

Its debatable on if a triggered app should wait and how long once it gets the 2033. That really depends on the pattern of message arrival. No sense to wait 5 seconds in a triggered app for a scenario where one message arrives once a week, right?


But I think Janje issue is most likely related to not starting the triggered processes in the background like Jeff said. The trigger monitor is stuck keeping track of the first instance of the triggered process and not ready to go with another instance.


Peter Potkay

From: MQSeries List [mailto:MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org] On Behalf Of Jefferson Lowrey
Sent: Thursday, July 10, 2014 12:18 PM
To: MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org
Subject: Re: Different queue, same process and not triggering

Uhm.

A trigger First application is supposed to make sure that the triggered queue is entirely empty before it quits, such that the next time a new message is added, it will be the first message.

A trigger Every is supposed to read a single message and then quit. But trigger every is not reliable outside of zOS.

Jantje is properly using START to ensure that the trigger monitor is not waiting for one triggered application to complete before it starts another.

Jantje - can you be more clear on the issue. Is the program failing to start? Or is the queue manager simply not generating a message on the initiation queue?

If the queue manager is not generating a message on the initiation queue, then you need to review http://www-01.ibm.com/support/knowledgecenter/SSFKSJ_7.5.0/com.ibm.mq.dev.doc/q026930_.htm?lang=en in detail and check off all conditions one by one.

Thank you,

Jeff Lowrey




From: Roger Lacroix <roger.lacroix-***@public.gmane.org<mailto:***@ROGERS.COM>>
To: MQSERIES-JX7+OpRa80QeFbOYke1v4oOpTq8/***@public.gmane.org<mailto:MQSERIES-JX7+OpRa80Ties2YCUG/***@public.gmane.orgniwien.ac.at>
Date: 07/10/2014 11:08 AM
Subject: Re: [MQSERIES] Different queue, same process and not triggering
Sent by: MQSeries List <MQSERIES-JX7+OpRa80QeFbOYke1v4oOpTq8/***@public.gmane.org<mailto:MQSERIES-JX7+OpRa80QeFbOYke1v4oOpTq8/***@public.gmane.org>>
________________________________



Hello Jantje,

> The strange thing is that when a message arrives on a queue that triggers the same process definition as another queue on which that process definition has triggered while the program is lingering, the arrival of a message on one queue, the arrival of a message on the other queue that is supposed to trigger a second process, doesn't.

Yes, that IS exactly what is supposed to happen. If you use Trigger First then your application is NOT suppose to linger. It is supposed to use MQGET with no wait option and exit immediately when it is done processing the message.

Also, if your application is using MQGET with wait then why aren't you retrieving the new message while your application is lingering? Do you clear the MsgID and CorrelID before doing the next MQGET call?

Regards,
Roger Lacroix
Capitalware Inc.

At 11:58 AM 7/10/2014, you wrote:
Esteemed Listers,

Windows Server 2008 R2 Standard
WebSphere MQ 7.1.0.5


I see some very strange behaviour with the triggering, I have put in place. I have three separate process definitions and a number of queues referencing these process definitions, all using the same SYSTEM.DEFAULT.INITIATION.QUEUE for initiation. I use the standard trigger monitor runmqtrm that comes with the product and have it running as a service, defined in the list of services of the queue manager. It is listening for trigger messages and does invoke my applications... most of the time...

My applications are designed for trigger-first: they linger on when the work is done, by doing another MQGET with wait when the first message that triggered them is processed. MQCOMMIT is being called at the right time in the program logic; I have checked that...

All process definitions are set up to invoke the same .cmd file; distinction being made by using the environment data passed as an argument into that command file in order to know what the program actually needs to do. The main program is a standard ANSI C program that invokes different C functions, depending on the value of the input argument. The code then uses regular function calls to invoke the different MQI, as per the book. The trigger message, which is also passed as an argument to the command file, is used to determine which queue to open. Messages are gotten off of that queue and processed accordingly. This works all fine and well as long as the messages arrive on queues that trigger different process definitions.

The strange thing is that when a message arrives on a queue that triggers the same process definition as another queue on which that process definition has triggered while the program is lingering, the arrival of a message on one queue, the arrival of a message on the other queue that is supposed to trigger a second process, doesn't.

If that same message arrives on that second queue when the process that was triggered on the first queue has already terminated, then the second queue does trigger the process correctly.

Stranger still: when the triggering does not take place at arrival of the message on the second queue, it is enough to browse that queue (using a program that I have written for the purpose of checking the message contents during testing that does non-destructive MQGET) to have the triggering kick in.

I don't understand...

Do you think I am entitled to a PMR, or am I doing something wrong?

Searching the archives, nor Google turned up any results on my queries.

Thanks for shedding some light on this matter.

Very best regards,

Jantje.


My process definitions:

PROCESS(TQ3.PR.SND)
APPLTYPE(WINDOWSNT)
APPLICID(START
D:\TQS2010\ACC\QTRIG.CMD)
ENVRDATA(SND)
USERDATA( )
DESCR(Send)

PROCESS(TQ3.PR.RCV)
APPLTYPE(WINDOWSNT)
APPLICID(START
D:\TQS2010\ACC\QTRIG.CMD)
ENVRDATA(RCV)
USERDATA( )
DESCR(Receive)


My queue defintions:

QUEUE(TQ3.QL.SND.TNLA2)
TYPE(QLOCAL)
ACCTQ(QMGR)
BOQNAME( )
BOTHRESH(0)
CLUSNL( )
CLUSTER( )
CLWLPRTY(0)
CLWLRANK(0)
CLWLUSEQ(QMGR)
CURDEPTH(0)
CUSTOM( )
DEFBIND(OPEN)
DEFPRTY(0)
DEFPSIST(YES)
DEFPRESP(SYNC)
DEFREADA(NO)
DEFSOPT(SHARED)
DEFTYPE(PREDEFINED)
DESCR(From Migration)
DISTL(NO)
GET(ENABLED)
NOHARDENBO
INITQ(SYSTEM.DEFAULT.INITIATION.QUEUE)
IPPROCS(0)
MAXDEPTH(50000)
MAXMSGL(131072)
MONQ(QMGR)
MSGDLVSQ(PRIORITY)
TRIGGER
NPMCLASS(NORMAL)
OPPROCS(0)
PROCESS(TQ3.PR.SND)
PUT(ENABLED)
PROPCTL(COMPAT)
QDEPTHHI(5)
QDEPTHLO(2)
QDPHIEV(DISABLED)
QDPLOEV(DISABLED)
QDPMAXEV(ENABLED)
QSVCIEV(NONE)
QSVCINT(999999999)
RETINTVL(999999999)
SCOPE(QMGR)
SHARE
STATQ(QMGR)
TRIGDATA( )
TRIGDPTH(1)
TRIGMPRI(0)
TRIGTYPE(FIRST)
USAGE(NORMAL)


QUEUE(TQ3.QL.ENV.TNLA2.R1)
TYPE(QLOCAL)
ACCTQ(QMGR)
BOQNAME( )
BOTHRESH(0)
CLUSNL( )
CLUSTER( )
CLWLPRTY(0)
CLWLRANK(0)
CLWLUSEQ(QMGR)
CURDEPTH(0)
CUSTOM( )
DEFBIND(OPEN)
DEFPRTY(0)
DEFPSIST(YES)
DEFPRESP(SYNC)
DEFREADA(NO)
DEFSOPT(SHARED)
DEFTYPE(PREDEFINED)
DESCR(Envelopes)
DISTL(NO)
GET(ENABLED)
NOHARDENBO
INITQ(SYSTEM.DEFAULT.INITIATION.QUEUE)
IPPROCS(0)
MAXDEPTH(50000)
MAXMSGL(4194304)
MONQ(QMGR)
MSGDLVSQ(PRIORITY)
TRIGGER
NPMCLASS(NORMAL)
OPPROCS(0)
PROCESS(TQ3.PR.RCV)
PUT(ENABLED)
PROPCTL(COMPAT)
QDEPTHHI(5)
QDEPTHLO(2)
QDPHIEV(DISABLED)
QDPLOEV(DISABLED)
QDPMAXEV(ENABLED)
QSVCIEV(NONE)
QSVCINT(999999999)
RETINTVL(999999999)
SCOPE(QMGR)
SHARE
STATQ(QMGR)
TRIGDATA( )
TRIGDPTH(1)
TRIGMPRI(0)
TRIGTYPE(FIRST)
USAGE(NORMAL)


QUEUE(TQ3.QL.ACC.SPIL.OUT)
TYPE(QLOCAL)
ACCTQ(QMGR)
BOQNAME( )
BOTHRESH(0)
CLUSNL( )
CLUSTER( )
CLWLPRTY(0)
CLWLRANK(0)
CLWLUSEQ(QMGR)
CURDEPTH(0)
CUSTOM( )
DEFBIND(OPEN)
DEFPRTY(0)
DEFPSIST(YES)
DEFPRESP(SYNC)
DEFREADA(NO)
DEFSOPT(SHARED)
DEFTYPE(PREDEFINED)
DESCR(SPIL outbound)
DISTL(NO)
GET(ENABLED)
NOHARDENBO
INITQ(SYSTEM.DEFAULT.INITIATION.QUEUE)
IPPROCS(0)
MAXDEPTH(50000)
MAXMSGL(4194304)
MONQ(QMGR)
MSGDLVSQ(PRIORITY)
TRIGGER
NPMCLASS(NORMAL)
OPPROCS(1)
PROCESS(TQ3.PR.RCV)
PUT(ENABLED)
PROPCTL(COMPAT)
QDEPTHHI(5)
QDEPTHLO(2)
QDPHIEV(DISABLED)
QDPLOEV(DISABLED)
QDPMAXEV(ENABLED)
QSVCIEV(NONE)
QSVCINT(999999999)
RETINTVL(999999999)
SCOPE(QMGR)
SHARE
STATQ(QMGR)
TRIGDATA( )
TRIGDPTH(1)
TRIGMPRI(0)
TRIGTYPE(FIRST)
USAGE(NORMAL)


My trigger monitor definition:

DEFINE SERVICE ('TQS.TRIGGER.MONITOR.ACC') +
DESCR('TQS Trigger Monitor for ACC') +
STARTCMD('C:\Program Files (x86)\IBM\WebSphere MQ\bin\runmqtrm.exe') +
STARTARG('-m +QMNAME+ -q SYSTEM.DEFAULT.INITIATION.QUEUE') +
STOPCMD('C:\Program Files (x86)\IBM\WebSphere MQ\bin\amqsstop.exe') +
STOPARG('-m +QMNAME+ -p +MQ_SERVER_PID+') +
STDOUT('D:\IBM\WMQ\errors\TQS.TRIGGER.MONITOR.DEV.stdout.log') +
STDERR('D:\IBM\WMQ\errors\TQS.TRIGGER.MONITOR.DEV.stderr.log') +
CONTROL(QMGR) +
SERVTYPE(SERVER) +
REPLACE

To unsubscribe, write to LISTSERV-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org<mailto:***@LISTSERV.MEDUNIWIEN.AC.AT> and,
in the message body (not the subject), write: SIGNOFF MQSERIES
Instructions for managing your mailing list subscription are provided in
the Listserv General Users Guide available at http://www.lsoft.com<http://www.lsoft.com/>
Archive: http://listserv.meduniwien.ac.at/archives/mqser-l.html
________________________________
List Archive<http://listserv.meduniwien.ac.at/archives/mqser-l.html> - Manage Your List Settings<http://listserv.meduniwien.ac.at/cgi-bin/wa?SUBED1=mqser-l&A=1> - Unsubscribe<mailto:LISTSERV-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org?subject=Unsubscribe&BODY=signoff%20mqseries>

Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com<http://www.lsoft.com/resources/manuals.asp>

________________________________
List Archive<http://listserv.meduniwien.ac.at/archives/mqser-l.html> - Manage Your List Settings<http://listserv.meduniwien.ac.at/cgi-bin/wa?SUBED1=mqser-l&A=1> - Unsubscribe<mailto:LISTSERV-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org?subject=Unsubscribe&BODY=signoff%20mqseries>

Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com<http://www.lsoft.com/resources/manuals.asp>
************************************************************
This communication, including attachments, is for the exclusive use of addressee and may contain proprietary, confidential and/or privileged information. If you are not the intended recipient, any use, copying, disclosure, dissemination or distribution is strictly prohibited. If you are not the intended recipient, please notify the sender immediately by return e-mail, delete this communication and destroy all copies.
************************************************************

To unsubscribe, write to LISTSERV-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org and,
in the message body (not the subject), write: SIGNOFF MQSERIES
Instructions for managing your mailing list subscription are provided in
the Listserv General Users Guide available at http://www.lsoft.com
Archive: http://listserv.meduniwien.ac.at/archives/mqser-l.html
Jantje .
2014-07-10 16:25:27 UTC
Permalink
On Thu, 10 Jul 2014 12:06:47 -0400, Roger Lacroix <***@ROGERS.COM> wrote:

Dear Roger,

>Yes, that IS exactly what is supposed to happen. If you use Trigger
>First then your application is NOT suppose to linger. It is supposed
>to use MQGET with no wait option and exit immediately when it is done
>processing the message.

Please allow me to disagree.

Trigger first means that the trigger fires only when queue depth goes from 0 to 1. The triggered program needs to loop around and empty the queue before exiting (which is exactly what my program does). It lingers on the final MQGET with wait (and time-out!) for the purpose of not being re-invoked too often when message arrival rate is slowing down (the initialization of the program is rather costly in my case).

But I think that is not the point here.


>Also, if your application is using MQGET with wait then why aren't
>you retrieving the new message while your application is lingering?

Because the message that is not gotten is on a different queue than the one where the first instance of my process is lingering on.

>Do you clear the MsgID and CorrelID before doing the next MQGET call?
Actually, yes, I do. But again, that is not the point, I think.


The oddity (and my problem) is that one process lingering on one queue is preventing the process from triggering on a _different_ queue.


Thanks for all your input,

Jantje.

To unsubscribe, write to LISTSERV-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org and,
in the message body (not the subject), write: SIGNOFF MQSERIES
Roger Lacroix
2014-07-10 17:13:02 UTC
Permalink
Hi Jantje & Jeff,

I fat-fingered the word 'message' at the end of my 1st sentence. It
should be plural and not singular.

Jantje, you need to show use 2 things: (1) a dump of the 3 process
definitions you are using and (2) a dump of IPPROCS & OPPROCS of all
queues used by the 3 triggered processes when one of the triggered
processes is running.

Regards,
Roger Lacroix
Capitalware Inc.

At 12:25 PM 7/10/2014, you wrote:
>On Thu, 10 Jul 2014 12:06:47 -0400, Roger Lacroix
><roger.lacroix-***@public.gmane.org> wrote:
>
>Dear Roger,
>
> >Yes, that IS exactly what is supposed to happen. If you use Trigger
> >First then your application is NOT suppose to linger. It is supposed
> >to use MQGET with no wait option and exit immediately when it is done
> >processing the message.
>
>Please allow me to disagree.
>
>Trigger first means that the trigger fires only when queue depth
>goes from 0 to 1. The triggered program needs to loop around and
>empty the queue before exiting (which is exactly what my program
>does). It lingers on the final MQGET with wait (and time-out!) for
>the purpose of not being re-invoked too often when message arrival
>rate is slowing down (the initialization of the program is rather
>costly in my case).
>
>But I think that is not the point here.
>
>
> >Also, if your application is using MQGET with wait then why aren't
> >you retrieving the new message while your application is lingering?
>
>Because the message that is not gotten is on a different queue than
>the one where the first instance of my process is lingering on.
>
> >Do you clear the MsgID and CorrelID before doing the next MQGET call?
>Actually, yes, I do. But again, that is not the point, I think.
>
>
>The oddity (and my problem) is that one process lingering on one
>queue is preventing the process from triggering on a _different_ queue.
>
>
>Thanks for all your input,
>
>Jantje.
>
>To unsubscribe, write to LISTSERV-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org and,
>in the message body (not the subject), write: SIGNOFF MQSERIES
>Instructions for managing your mailing list subscription are provided in
>the Listserv General Users Guide available at http://www.lsoft.com
>Archive: http://listserv.meduniwien.ac.at/archives/mqser-l.html

To unsubscribe, write to LISTSERV-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org and,
in the message body (not the subject), write: SIGNOFF MQSERIES
Jantje .
2014-07-10 16:38:34 UTC
Permalink
On Thu, 10 Jul 2014 11:17:34 -0500, Jefferson Lowrey <jlowrey-rIXRsD/***@public.gmane.org> wrote:


Dear Jeff,


>A trigger First application is supposed to make sure that the triggered
>queue is entirely empty before it quits, such that the next time a new
>message is added, it will be the first message.

That is exactly what my application is doing.


>A trigger Every is supposed to read a single message and then quit. But
>trigger every is not reliable outside of zOS.

And even on zOS, I have seen it getting out of pace in rare occasions.
But again, that is not the point here.

>
>Jantje is properly using START to ensure that the trigger monitor is not
>waiting for one triggered application to complete before it starts
>another.

I do indeed use START to get the application going and to return control to the trigger monitor as soon as possible.



>Jantje - can you be more clear on the issue. Is the program failing to
>start? Or is the queue manager simply not generating a message on the
>initiation queue?

The program is not being invoked and I do not see a message on the initiation queue. (Now, I know that absence of evidence is not evidence of absence. Any tricks and tips to make absolutely sure whether or not a trigger message was actually generated are more than welcome too.)


>
>If the queue manager is not generating a message on the initiation queue,
>then you need to review
>http://www-01.ibm.com/support/knowledgecenter/SSFKSJ_7.5.0/com.ibm.mq.dev.doc/q026930_.htm?lang=en
>in detail and check off all conditions one by one.

I have taken into account all 18 (or is it 19, in any case, more than the 14 mentioned in the document) conditions for a trigger message to be generated. I have had intensive training on this by a real expert in the matter. My head still aches...

So the problem is that the program is not triggered from the second queue during the period that the program that was triggered on the first queue is still around.

Being two separate queues, they should not block triggering of a second instance of the program...

Thanks,

Jantje.

To unsubscribe, write to LISTSERV-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org and,
in the message body (not the subject), write: SIGNOFF MQSERIES
Potkay, Peter M (CTO Architecture + Engineering)
2014-07-10 16:53:27 UTC
Permalink
Jantje,
Make sure your MQ monitoring tools watch the Initiation Queue so you can review the throughput of the queue.

Realize that the generation of a trigger message by the QM is not 100.00% equal to the consumption of that trigger message by the TM. Watch your Init queue carefully and you may see a clue. Run the trigger monitor in the foreground and watch what it does.


Consider enforcing a one to one relationship between triggered queues and process definitions, even if they are exactly the same.


Peter Potkay

-----Original Message-----
From: MQSeries List [mailto:***@LISTSERV.MEDUNIWIEN.AC.AT] On Behalf Of Jantje .
Sent: Thursday, July 10, 2014 12:39 PM
To: ***@LISTSERV.MEDUNIWIEN.AC.AT
Subject: Re: Different queue, same process and not triggering

On Thu, 10 Jul 2014 11:17:34 -0500, Jefferson Lowrey <***@US.IBM.COM> wrote:


Dear Jeff,


>A trigger First application is supposed to make sure that the triggered
>queue is entirely empty before it quits, such that the next time a new
>message is added, it will be the first message.

That is exactly what my application is doing.


>A trigger Every is supposed to read a single message and then quit.
>But trigger every is not reliable outside of zOS.

And even on zOS, I have seen it getting out of pace in rare occasions.
But again, that is not the point here.

>
>Jantje is properly using START to ensure that the trigger monitor is
>not waiting for one triggered application to complete before it starts
>another.

I do indeed use START to get the application going and to return control to the trigger monitor as soon as possible.



>Jantje - can you be more clear on the issue. Is the program failing to
>start? Or is the queue manager simply not generating a message on the
>initiation queue?

The program is not being invoked and I do not see a message on the initiation queue. (Now, I know that absence of evidence is not evidence of absence. Any tricks and tips to make absolutely sure whether or not a trigger message was actually generated are more than welcome too.)


>
>If the queue manager is not generating a message on the initiation
>queue, then you need to review
>http://www-01.ibm.com/support/knowledgecenter/SSFKSJ_7.5.0/com.ibm.mq.d
>ev.doc/q026930_.htm?lang=en in detail and check off all conditions one
>by one.

I have taken into account all 18 (or is it 19, in any case, more than the 14 mentioned in the document) conditions for a trigger message to be generated. I have had intensive training on this by a real expert in the matter. My head still aches...

So the problem is that the program is not triggered from the second queue during the period that the program that was triggered on the first queue is still around.

Being two separate queues, they should not block triggering of a second instance of the program...

Thanks,

Jantje.

To unsubscribe, write to ***@LISTSERV.MEDUNIWIEN.AC.AT and, in the message body (not the subject), write: SIGNOFF MQSERIES Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com
Archive: http://listserv.meduniwien.ac.at/archives/mqser-l.html
************************************************************
This communication, including attachments, is for the exclusive use of addressee and may contain proprietary, confidential and/or privileged information. If you are not the intended recipient, any use, copying, disclosure, dissemination or distribution is strictly prohibited. If you are not the intended recipient, please notify the sender immediately by return e-mail, delete this communication and destroy all copies.
************************************************************


To unsubscribe, write to ***@LISTSERV.MEDUNIWIEN.AC.AT and,
in the message body (not the subject), write: SIGNOFF MQSERIES
Instructions for managing your mailing list subscription are provided in
the Listserv General Users Guide available at http://www.lsoft.com
Archive: h
Jefferson Lowrey
2014-07-10 16:54:59 UTC
Permalink
You can tell if the queue manager generated a trigger message by looking
at the output from runmqtrm. Your service is properly set up to direct
stdout and stderr to different files.

In this case, you're looking for an absence of information. You would see
data about the first application being triggered and the trigger monitor
waiting for another trigger message, and then an entire lack of data until
the first program had stopped and the second application was finally
triggered.

If this is what you see, then I kind of agree with Paul that it's somewhat
likely that the second queue is open. And, yes, I know that the trigger
conditions are complex and make the brain hurt. But you have to walk
through them to verify that all conditions *are* met and that no trigger
message is produced. You'll have to do it as part of a PMR anyway, so you
might as well assemble the evidence anyway.

Thank you,

Jeff Lowrey




From: "Jantje ." <jan.moeyersons-Y+/***@public.gmane.org>
To: MQSERIES-JX7+OpRa80QeFbOYke1v4oOpTq8/***@public.gmane.org
Date: 07/10/2014 11:38 AM
Subject: Re: [MQSERIES] Different queue, same process and not
triggering
Sent by: MQSeries List <MQSERIES-JX7+OpRa80QeFbOYke1v4oOpTq8/***@public.gmane.org>



On Thu, 10 Jul 2014 11:17:34 -0500, Jefferson Lowrey <jlowrey-rIXRsD/***@public.gmane.org>
wrote:


Dear Jeff,


>A trigger First application is supposed to make sure that the triggered
>queue is entirely empty before it quits, such that the next time a new
>message is added, it will be the first message.

That is exactly what my application is doing.


>A trigger Every is supposed to read a single message and then quit. But
>trigger every is not reliable outside of zOS.

And even on zOS, I have seen it getting out of pace in rare occasions.
But again, that is not the point here.

>
>Jantje is properly using START to ensure that the trigger monitor is not
>waiting for one triggered application to complete before it starts
>another.

I do indeed use START to get the application going and to return control
to the trigger monitor as soon as possible.



>Jantje - can you be more clear on the issue. Is the program failing to
>start? Or is the queue manager simply not generating a message on the
>initiation queue?

The program is not being invoked and I do not see a message on the
initiation queue. (Now, I know that absence of evidence is not evidence of
absence. Any tricks and tips to make absolutely sure whether or not a
trigger message was actually generated are more than welcome too.)


>
>If the queue manager is not generating a message on the initiation queue,
>then you need to review
>
http://www-01.ibm.com/support/knowledgecenter/SSFKSJ_7.5.0/com.ibm.mq.dev.doc/q026930_.htm?lang=en

>in detail and check off all conditions one by one.

I have taken into account all 18 (or is it 19, in any case, more than the
14 mentioned in the document) conditions for a trigger message to be
generated. I have had intensive training on this by a real expert in the
matter. My head still aches...

So the problem is that the program is not triggered from the second queue
during the period that the program that was triggered on the first queue
is still around.

Being two separate queues, they should not block triggering of a second
instance of the program...

Thanks,

Jantje.

To unsubscribe, write to LISTSERV-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org and,
in the message body (not the subject), write: SIGNOFF MQSERIES
Instructions for managing your mailing list subscription are provided in
the Listserv General Users Guide available at http://www.lsoft.com
Archive: http://listserv.meduniwien.ac.at/archives/mqser-l.html



To unsubscribe, write to LISTSERV-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org and,
in the message body (not the subject), write: SIGNOFF MQSERIES
Instructions for managing your mailing list subscription are provided in
the Listserv General Users Guide available at http://www.lsoft.com
Archive: http://listserv.meduniwien.ac.at/archives/mqser-l.html
T.Rob
2014-07-10 21:46:22 UTC
Permalink
X-Report-Abuse-To: spam-RAvZ+8ubYLwZD488Lvc0IA6ISnHq+hSGQ0cMyQF+***@public.gmane.org
X-Filter-Fingerprint: cPaH8lomer6UwsJ3BnJDyts/W+OagfBsRYjpo1vNhue0VFDyP20las9Mq1v6nXmfrqKtWpHLpkE8
c09GKJn2t3e58h9EG+9qqTi0Cmztd2NMqRJTan78INzQLlEGX/jFeWzOxjGHKKqvV47Z9+T++HU4
H51jyCSmLdA2hPaiVpwYWaeThsiFlmPt/lOSmjPeaIVEOEdimpYsDhdeTBE7Y2qK95LAXg+Ea3Jb
F9WwpaZ//Un1C5ivAWoOksRE8XtOTT9J6CK2j8j7/AJ9TNml+N7W+rqMRJn7eWp/YBRjkDye9Xyf
0LSMk3TACEF6SjSO7M5PlBEeeU6d6hNiSXnqneTIseFsyqheDENFXFtgNIcl5pmJFHpgH+n/qBky
tLHCK8qgx2wyiXqsLo2Xgx3r6CDDSEepx91YApW7E9vzQDr4Em6yxnYJdCvqEVvcIZwL+6IQmhc0
KYEMMSdWYVm5wouP4i+Bx0wuorMPjexmew8xL7hrJSk60SF3F6RYOYr2
X-Originating-IP: 184.154.225.7
X-SpamExperts-Domain: siteground247.com
X-SpamExperts-Username: 184.154.225.7
X-SpamExperts-Outgoing-Class: ham
X-SpamExperts-Outgoing-Evidence: Combined (0.02)
X-Recommended-Action: accept
X-PMX-Version: 6.1.0.2415318, Antispam-Engine: 2.7.2.2107409,
Antispam-Data: 2014.7.10.222420
X-PMX-Spam: Gauge=IIIIIIIII, Probability=9%, Report=' AT_TLD 0.1,
FROM_NAME_ONE_WORD 0.05, HTML_00_01 0.05, HTML_00_10 0.05,
BODY_SIZE_3000_3999 0, BODY_SIZE_5000_LESS 0,
BODY_SIZE_7000_LESS 0, DATE_TZ_NA 0, FORGED_MUA_OUTLOOK 0,
URI_ENDS_IN_HTML 0, WEBMAIL_SOURCE 0, WEBMAIL_XOIP 0,
WEBMAIL_X_IP_HDR 0, __ANY_URI 0, __BOUNCE_CHALLENGE_SUBJ 0,
__BOUNCE_NDR_SUBJ_EXEMPT 0, __CP_URI_IN_BODY 0, __CT 0, __CTE 0,
__CT_TEXT_PLAIN 0, __FORWARDED_MSG 0, __HAS_FROM 0, __HAS_MSGID 0,
__HAS_X_MAILER 0, __IN_REP_TO 0, __LINES_OF_YELLING 0,
__MIME_TEXT_ONLY 0, __MIME_VERSION 0, __OUTLOOK_MUA 0,
__OUTLOOK_MUA_1 0, __SANE_MSGID 0, __SUBJ_ALPHA_END 0,
__SUBJ_ALPHA_NEGATE 0, __TO_MALFORMED_2 0, __URI_NS ,
__USER_AGENT_MS_GENERIC 0'
Sender: MQSeries List <MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org>
In-Reply-To: <4976614548839615.WA.jan.moeyersonsgfi.be-JX7+OpRa80QeFbOYke1v4oOpTq8/***@public.gmane.org>
Precedence: list
List-Help: <http://listserv.meduniwien.ac.at/cgi-bin/wa?LIST=MQSERIES>,
<mailto:LISTSERV-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org?body=INFO%20MQSERIES>
List-Unsubscribe: <mailto:MQSERIES-unsubscribe-request-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org>
List-Subscribe: <mailto:MQSERIES-subscribe-request-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org>
List-Owner: <mailto:MQSERIES-request-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org>
List-Archive: <http://listserv.meduniwien.ac.at/cgi-bin/wa?LIST=MQSERIES>
Archived-At: <http://permalink.gmane.org/gmane.network.mq.devel/17925>

Jantje,

>From your process def...

APPLICID("START D:\TQS2010\ACC\QTRIG.CMD")

Have you tried...

APPLICID("START /B CMD /C CALL D:\TQS2010\ACC\QTRIG.CMD")

I do not remember all the details about why I had to do this, but this is the syntax I have in my notes and it has worked for me before.


Kind regards,
-- T.Rob

T.Robert Wyatt, Managing partner
IoPT Consulting, LLC
+1 704-443-TROB
https://ioptconsulting.com
https://twitter.com/tdotrob


> -----Original Message-----
> From: MQSeries List [mailto:MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org] On Behalf
> Of Jantje .
> Sent: Thursday, July 10, 2014 12:39 PM
> To: MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org
> Subject: Re: Different queue, same process and not triggering
>
> On Thu, 10 Jul 2014 11:17:34 -0500, Jefferson Lowrey <jlowrey-rIXRsD/***@public.gmane.org>
> wrote:
>
>
> Dear Jeff,
>
>
> >A trigger First application is supposed to make sure that the triggered
> >queue is entirely empty before it quits, such that the next time a new
> >message is added, it will be the first message.
>
> That is exactly what my application is doing.
>
>
> >A trigger Every is supposed to read a single message and then quit.
> >But trigger every is not reliable outside of zOS.
>
> And even on zOS, I have seen it getting out of pace in rare occasions.
> But again, that is not the point here.
>
> >
> >Jantje is properly using START to ensure that the trigger monitor is
> >not waiting for one triggered application to complete before it starts
> >another.
>
> I do indeed use START to get the application going and to return control
> to the trigger monitor as soon as possible.
>
>
>
> >Jantje - can you be more clear on the issue. Is the program failing to
> >start? Or is the queue manager simply not generating a message on the
> >initiation queue?
>
> The program is not being invoked and I do not see a message on the
> initiation queue. (Now, I know that absence of evidence is not evidence of
> absence. Any tricks and tips to make absolutely sure whether or not a
> trigger message was actually generated are more than welcome too.)
>
>
> >
> >If the queue manager is not generating a message on the initiation
> >queue, then you need to review
> >http://www-01.ibm.com/support/knowledgecenter/SSFKSJ_7.5.0/com.ibm.mq.d
> >ev.doc/q026930_.htm?lang=en in detail and check off all conditions one
> >by one.
>
> I have taken into account all 18 (or is it 19, in any case, more than the
> 14 mentioned in the document) conditions for a trigger message to be
> generated. I have had intensive training on this by a real expert in the
> matter. My head still aches...
>
> So the problem is that the program is not triggered from the second queue
> during the period that the program that was triggered on the first queue
> is still around.
>
> Being two separate queues, they should not block triggering of a second
> instance of the program...
>
> Thanks,
>
> Jantje.
>
> To unsubscribe, write to LISTSERV-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org and, in the
> message body (not the subject), write: SIGNOFF MQSERIES Instructions for
> managing your mailing list subscription are provided in the Listserv
> General Users Guide available at http://www.lsoft.com
> Archive: http://listserv.meduniwien.ac.at/archives/mqser-l.html

To unsubscribe, write to LISTSERV-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org and,
in the message body (not the subject), write: SIGNOFF MQSERIES
Paul Clarke
2014-07-10 16:47:32 UTC
Permalink
This does seem very strange and may be a product. However, with triggering a
misconfiguration or an application bug can lead to strange results. Can you
show us what QTRIG.CMD does? Is it at all possible that the triggering of
one queue causes both queues to be opened ? When you say that the second
application does finally get triggered, is that when the first one is still
running...ie. it proves that that the applications CAN run at the same time
and there is no locking preventing it.

Cheers,
Paul.

Paul Clarke
www.mqgem.com
-----Original Message-----
From: Jantje .
Sent: Thursday, July 10, 2014 4:58 PM
To: MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org
Subject: Different queue, same process and not triggering

Esteemed Listers,

Windows Server 2008 R2 Standard
WebSphere MQ 7.1.0.5


I see some very strange behaviour with the triggering, I have put in place.
I have three separate process definitions and a number of queues referencing
these process definitions, all using the same
SYSTEM.DEFAULT.INITIATION.QUEUE for initiation. I use the standard trigger
monitor runmqtrm that comes with the product and have it running as a
service, defined in the list of services of the queue manager. It is
listening for trigger messages and does invoke my applications... most of
the time...

My applications are designed for trigger-first: they linger on when the work
is done, by doing another MQGET with wait when the first message that
triggered them is processed. MQCOMMIT is being called at the right time in
the program logic; I have checked that...

All process definitions are set up to invoke the same .cmd file; distinction
being made by using the environment data passed as an argument into that
command file in order to know what the program actually needs to do. The
main program is a standard ANSI C program that invokes different C
functions, depending on the value of the input argument. The code then uses
regular function calls to invoke the different MQI, as per the book. The
trigger message, which is also passed as an argument to the command file, is
used to determine which queue to open. Messages are gotten off of that queue
and processed accordingly. This works all fine and well as long as the
messages arrive on queues that trigger different process definitions.

The strange thing is that when a message arrives on a queue that triggers
the same process definition as another queue on which that process
definition has triggered while the program is lingering, the arrival of a
message on one queue, the arrival of a message on the other queue that is
supposed to trigger a second process, doesn't.

If that same message arrives on that second queue when the process that was
triggered on the first queue has already terminated, then the second queue
does trigger the process correctly.

Stranger still: when the triggering does not take place at arrival of the
message on the second queue, it is enough to browse that queue (using a
program that I have written for the purpose of checking the message contents
during testing that does non-destructive MQGET) to have the triggering kick
in.

I don't understand...

Do you think I am entitled to a PMR, or am I doing something wrong?

Searching the archives, nor Google turned up any results on my queries.

Thanks for shedding some light on this matter.

Very best regards,

Jantje.


My process definitions:

PROCESS(TQ3.PR.SND)
APPLTYPE(WINDOWSNT)
APPLICID(START
D:\TQS2010\ACC\QTRIG.CMD)
ENVRDATA(SND)
USERDATA( )
DESCR(Send)

PROCESS(TQ3.PR.RCV)
APPLTYPE(WINDOWSNT)
APPLICID(START
D:\TQS2010\ACC\QTRIG.CMD)
ENVRDATA(RCV)
USERDATA( )
DESCR(Receive)


My queue defintions:

QUEUE(TQ3.QL.SND.TNLA2)
TYPE(QLOCAL)
ACCTQ(QMGR)
BOQNAME( )
BOTHRESH(0)
CLUSNL( )
CLUSTER( )
CLWLPRTY(0)
CLWLRANK(0)
CLWLUSEQ(QMGR)
CURDEPTH(0)
CUSTOM( )
DEFBIND(OPEN)
DEFPRTY(0)
DEFPSIST(YES)
DEFPRESP(SYNC)
DEFREADA(NO)
DEFSOPT(SHARED)
DEFTYPE(PREDEFINED)
DESCR(From Migration)
DISTL(NO)
GET(ENABLED)
NOHARDENBO
INITQ(SYSTEM.DEFAULT.INITIATION.QUEUE)
IPPROCS(0)
MAXDEPTH(50000)
MAXMSGL(131072)
MONQ(QMGR)
MSGDLVSQ(PRIORITY)
TRIGGER
NPMCLASS(NORMAL)
OPPROCS(0)
PROCESS(TQ3.PR.SND)
PUT(ENABLED)
PROPCTL(COMPAT)
QDEPTHHI(5)
QDEPTHLO(2)
QDPHIEV(DISABLED)
QDPLOEV(DISABLED)
QDPMAXEV(ENABLED)
QSVCIEV(NONE)
QSVCINT(999999999)
RETINTVL(999999999)
SCOPE(QMGR)
SHARE
STATQ(QMGR)
TRIGDATA( )
TRIGDPTH(1)
TRIGMPRI(0)
TRIGTYPE(FIRST)
USAGE(NORMAL)


QUEUE(TQ3.QL.ENV.TNLA2.R1)
TYPE(QLOCAL)
ACCTQ(QMGR)
BOQNAME( )
BOTHRESH(0)
CLUSNL( )
CLUSTER( )
CLWLPRTY(0)
CLWLRANK(0)
CLWLUSEQ(QMGR)
CURDEPTH(0)
CUSTOM( )
DEFBIND(OPEN)
DEFPRTY(0)
DEFPSIST(YES)
DEFPRESP(SYNC)
DEFREADA(NO)
DEFSOPT(SHARED)
DEFTYPE(PREDEFINED)
DESCR(Envelopes)
DISTL(NO)
GET(ENABLED)
NOHARDENBO
INITQ(SYSTEM.DEFAULT.INITIATION.QUEUE)
IPPROCS(0)
MAXDEPTH(50000)
MAXMSGL(4194304)
MONQ(QMGR)
MSGDLVSQ(PRIORITY)
TRIGGER
NPMCLASS(NORMAL)
OPPROCS(0)
PROCESS(TQ3.PR.RCV)
PUT(ENABLED)
PROPCTL(COMPAT)
QDEPTHHI(5)
QDEPTHLO(2)
QDPHIEV(DISABLED)
QDPLOEV(DISABLED)
QDPMAXEV(ENABLED)
QSVCIEV(NONE)
QSVCINT(999999999)
RETINTVL(999999999)
SCOPE(QMGR)
SHARE
STATQ(QMGR)
TRIGDATA( )
TRIGDPTH(1)
TRIGMPRI(0)
TRIGTYPE(FIRST)
USAGE(NORMAL)


QUEUE(TQ3.QL.ACC.SPIL.OUT)
TYPE(QLOCAL)
ACCTQ(QMGR)
BOQNAME( )
BOTHRESH(0)
CLUSNL( )
CLUSTER( )
CLWLPRTY(0)
CLWLRANK(0)
CLWLUSEQ(QMGR)
CURDEPTH(0)
CUSTOM( )
DEFBIND(OPEN)
DEFPRTY(0)
DEFPSIST(YES)
DEFPRESP(SYNC)
DEFREADA(NO)
DEFSOPT(SHARED)
DEFTYPE(PREDEFINED)
DESCR(SPIL outbound)
DISTL(NO)
GET(ENABLED)
NOHARDENBO
INITQ(SYSTEM.DEFAULT.INITIATION.QUEUE)
IPPROCS(0)
MAXDEPTH(50000)
MAXMSGL(4194304)
MONQ(QMGR)
MSGDLVSQ(PRIORITY)
TRIGGER
NPMCLASS(NORMAL)
OPPROCS(1)
PROCESS(TQ3.PR.RCV)
PUT(ENABLED)
PROPCTL(COMPAT)
QDEPTHHI(5)
QDEPTHLO(2)
QDPHIEV(DISABLED)
QDPLOEV(DISABLED)
QDPMAXEV(ENABLED)
QSVCIEV(NONE)
QSVCINT(999999999)
RETINTVL(999999999)
SCOPE(QMGR)
SHARE
STATQ(QMGR)
TRIGDATA( )
TRIGDPTH(1)
TRIGMPRI(0)
TRIGTYPE(FIRST)
USAGE(NORMAL)


My trigger monitor definition:

DEFINE SERVICE ('TQS.TRIGGER.MONITOR.ACC') +
DESCR('TQS Trigger Monitor for ACC') +
STARTCMD('C:\Program Files (x86)\IBM\WebSphere MQ\bin\runmqtrm.exe') +
STARTARG('-m +QMNAME+ -q SYSTEM.DEFAULT.INITIATION.QUEUE') +
STOPCMD('C:\Program Files (x86)\IBM\WebSphere MQ\bin\amqsstop.exe') +
STOPARG('-m +QMNAME+ -p +MQ_SERVER_PID+') +
STDOUT('D:\IBM\WMQ\errors\TQS.TRIGGER.MONITOR.DEV.stdout.log') +
STDERR('D:\IBM\WMQ\errors\TQS.TRIGGER.MONITOR.DEV.stderr.log') +
CONTROL(QMGR) +
SERVTYPE(SERVER) +
REPLACE

To unsubscribe, write to LISTSERV-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org and,
in the message body (not the subject), write: SIGNOFF MQSERIES
Instructions for managing your mailing list subscription are provided in
the Listserv General Users Guide available at http://www.lsoft.com
Archive: http://listserv.meduniwien.ac.at/archives/mqser-l.html

To unsubscribe, write to LISTSERV-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org and,
in the message body (not the subject), write: SIGNOFF MQSERIES
Richard Tsujimoto
2014-07-10 17:13:03 UTC
Permalink
Just a suggestion. Show the process definitions. Windows has a peculiar way for defining separate background processes that need to run concurrently.

-----Original Message-----
From: MQSeries List [mailto:MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org] On Behalf Of Jantje .
Sent: Thursday, July 10, 2014 11:59 AM
To: MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org
Subject: Different queue, same process and not triggering

Esteemed Listers,

Windows Server 2008 R2 Standard
WebSphere MQ 7.1.0.5


I see some very strange behaviour with the triggering, I have put in place. I have three separate process definitions and a number of queues referencing these process definitions, all using the same SYSTEM.DEFAULT.INITIATION.QUEUE for initiation. I use the standard trigger monitor runmqtrm that comes with the product and have it running as a service, defined in the list of services of the queue manager. It is listening for trigger messages and does invoke my applications... most of the time...

My applications are designed for trigger-first: they linger on when the work is done, by doing another MQGET with wait when the first message that triggered them is processed. MQCOMMIT is being called at the right time in the program logic; I have checked that...

All process definitions are set up to invoke the same .cmd file; distinction being made by using the environment data passed as an argument into that command file in order to know what the program actually needs to do. The main program is a standard ANSI C program that invokes different C functions, depending on the value of the input argument. The code then uses regular function calls to invoke the different MQI, as per the book. The trigger message, which is also passed as an argument to the command file, is used to determine which queue to open. Messages are gotten off of that queue and processed accordingly. This works all fine and well as long as the messages arrive on queues that trigger different process definitions.

The strange thing is that when a message arrives on a queue that triggers the same process definition as another queue on which that process definition has triggered while the program is lingering, the arrival of a message on one queue, the arrival of a message on the other queue that is supposed to trigger a second process, doesn't.

If that same message arrives on that second queue when the process that was triggered on the first queue has already terminated, then the second queue does trigger the process correctly.

Stranger still: when the triggering does not take place at arrival of the message on the second queue, it is enough to browse that queue (using a program that I have written for the purpose of checking the message contents during testing that does non-destructive MQGET) to have the triggering kick in.

I don't understand...

Do you think I am entitled to a PMR, or am I doing something wrong?

Searching the archives, nor Google turned up any results on my queries.

Thanks for shedding some light on this matter.

Very best regards,

Jantje.


My process definitions:

PROCESS(TQ3.PR.SND)
APPLTYPE(WINDOWSNT)
APPLICID(START
D:\TQS2010\ACC\QTRIG.CMD)
ENVRDATA(SND)
USERDATA( )
DESCR(Send)

PROCESS(TQ3.PR.RCV)
APPLTYPE(WINDOWSNT)
APPLICID(START
D:\TQS2010\ACC\QTRIG.CMD)
ENVRDATA(RCV)
USERDATA( )
DESCR(Receive)


My queue defintions:

QUEUE(TQ3.QL.SND.TNLA2)
TYPE(QLOCAL)
ACCTQ(QMGR)
BOQNAME( )
BOTHRESH(0)
CLUSNL( )
CLUSTER( )
CLWLPRTY(0)
CLWLRANK(0)
CLWLUSEQ(QMGR)
CURDEPTH(0)
CUSTOM( )
DEFBIND(OPEN)
DEFPRTY(0)
DEFPSIST(YES)
DEFPRESP(SYNC)
DEFREADA(NO)
DEFSOPT(SHARED)
DEFTYPE(PREDEFINED)
DESCR(From Migration)
DISTL(NO)
GET(ENABLED)
NOHARDENBO
INITQ(SYSTEM.DEFAULT.INITIATION.QUEUE)
IPPROCS(0)
MAXDEPTH(50000)
MAXMSGL(131072)
MONQ(QMGR)
MSGDLVSQ(PRIORITY)
TRIGGER
NPMCLASS(NORMAL)
OPPROCS(0)
PROCESS(TQ3.PR.SND)
PUT(ENABLED)
PROPCTL(COMPAT)
QDEPTHHI(5)
QDEPTHLO(2)
QDPHIEV(DISABLED)
QDPLOEV(DISABLED)
QDPMAXEV(ENABLED)
QSVCIEV(NONE)
QSVCINT(999999999)
RETINTVL(999999999)
SCOPE(QMGR)
SHARE
STATQ(QMGR)
TRIGDATA( )
TRIGDPTH(1)
TRIGMPRI(0)
TRIGTYPE(FIRST)
USAGE(NORMAL)


QUEUE(TQ3.QL.ENV.TNLA2.R1)
TYPE(QLOCAL)
ACCTQ(QMGR)
BOQNAME( )
BOTHRESH(0)
CLUSNL( )
CLUSTER( )
CLWLPRTY(0)
CLWLRANK(0)
CLWLUSEQ(QMGR)
CURDEPTH(0)
CUSTOM( )
DEFBIND(OPEN)
DEFPRTY(0)
DEFPSIST(YES)
DEFPRESP(SYNC)
DEFREADA(NO)
DEFSOPT(SHARED)
DEFTYPE(PREDEFINED)
DESCR(Envelopes)
DISTL(NO)
GET(ENABLED)
NOHARDENBO
INITQ(SYSTEM.DEFAULT.INITIATION.QUEUE)
IPPROCS(0)
MAXDEPTH(50000)
MAXMSGL(4194304)
MONQ(QMGR)
MSGDLVSQ(PRIORITY)
TRIGGER
NPMCLASS(NORMAL)
OPPROCS(0)
PROCESS(TQ3.PR.RCV)
PUT(ENABLED)
PROPCTL(COMPAT)
QDEPTHHI(5)
QDEPTHLO(2)
QDPHIEV(DISABLED)
QDPLOEV(DISABLED)
QDPMAXEV(ENABLED)
QSVCIEV(NONE)
QSVCINT(999999999)
RETINTVL(999999999)
SCOPE(QMGR)
SHARE
STATQ(QMGR)
TRIGDATA( )
TRIGDPTH(1)
TRIGMPRI(0)
TRIGTYPE(FIRST)
USAGE(NORMAL)


QUEUE(TQ3.QL.ACC.SPIL.OUT)
TYPE(QLOCAL)
ACCTQ(QMGR)
BOQNAME( )
BOTHRESH(0)
CLUSNL( )
CLUSTER( )
CLWLPRTY(0)
CLWLRANK(0)
CLWLUSEQ(QMGR)
CURDEPTH(0)
CUSTOM( )
DEFBIND(OPEN)
DEFPRTY(0)
DEFPSIST(YES)
DEFPRESP(SYNC)
DEFREADA(NO)
DEFSOPT(SHARED)
DEFTYPE(PREDEFINED)
DESCR(SPIL outbound)
DISTL(NO)
GET(ENABLED)
NOHARDENBO
INITQ(SYSTEM.DEFAULT.INITIATION.QUEUE)
IPPROCS(0)
MAXDEPTH(50000)
MAXMSGL(4194304)
MONQ(QMGR)
MSGDLVSQ(PRIORITY)
TRIGGER
NPMCLASS(NORMAL)
OPPROCS(1)
PROCESS(TQ3.PR.RCV)
PUT(ENABLED)
PROPCTL(COMPAT)
QDEPTHHI(5)
QDEPTHLO(2)
QDPHIEV(DISABLED)
QDPLOEV(DISABLED)
QDPMAXEV(ENABLED)
QSVCIEV(NONE)
QSVCINT(999999999)
RETINTVL(999999999)
SCOPE(QMGR)
SHARE
STATQ(QMGR)
TRIGDATA( )
TRIGDPTH(1)
TRIGMPRI(0)
TRIGTYPE(FIRST)
USAGE(NORMAL)


My trigger monitor definition:

DEFINE SERVICE ('TQS.TRIGGER.MONITOR.ACC') + DESCR('TQS Trigger Monitor for ACC') + STARTCMD('C:\Program Files (x86)\IBM\WebSphere MQ\bin\runmqtrm.exe') + STARTARG('-m +QMNAME+ -q SYSTEM.DEFAULT.INITIATION.QUEUE') + STOPCMD('C:\Program Files (x86)\IBM\WebSphere MQ\bin\amqsstop.exe') + STOPARG('-m +QMNAME+ -p +MQ_SERVER_PID+') +
STDOUT('D:\IBM\WMQ\errors\TQS.TRIGGER.MONITOR.DEV.stdout.log') +
STDERR('D:\IBM\WMQ\errors\TQS.TRIGGER.MONITOR.DEV.stderr.log') +
CONTROL(QMGR) +
SERVTYPE(SERVER) +
REPLACE

To unsubscribe, write to LISTSERV-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org and, in the message body (not the subject), write: SIGNOFF MQSERIES Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com
Archive: http://listserv.meduniwien.ac.at/archives/mqser-l.html

To unsubscribe, write to LISTSERV-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org and,
in the message body (not the subject), write: SIGNOFF MQSERIES
Tim Zielke
2014-07-10 20:08:10 UTC
Permalink
Hi Jantje,

If you can recreate this issue, one thing I would also try is a trace on the runmqtrm process and recreate the trigger issue.

strmqtrc -m qmgr -t all -p runmqtrm

The runmqtrm trace will give you timings of when runmqtrm read from the initiation queue, started your triggered application, and the result it got back from the operating system from that start. It could be a good frame of reference to see what runmqtrm was doing when you have this triggering issue and those pieces of the trace are fairly straightforward to read.

Thanks,
Tim

-----Original Message-----
From: MQSeries List [mailto:***@LISTSERV.MEDUNIWIEN.AC.AT] On Behalf Of Richard Tsujimoto
Sent: Thursday, July 10, 2014 12:13 PM
To: ***@LISTSERV.MEDUNIWIEN.AC.AT
Subject: Re: Different queue, same process and not triggering

Just a suggestion. Show the process definitions. Windows has a peculiar way for defining separate background processes that need to run concurrently.

-----Original Message-----
From: MQSeries List [mailto:***@LISTSERV.MEDUNIWIEN.AC.AT] On Behalf Of Jantje .
Sent: Thursday, July 10, 2014 11:59 AM
To: ***@LISTSERV.MEDUNIWIEN.AC.AT
Subject: Different queue, same process and not triggering

Esteemed Listers,

Windows Server 2008 R2 Standard
WebSphere MQ 7.1.0.5


I see some very strange behaviour with the triggering, I have put in place. I have three separate process definitions and a number of queues referencing these process definitions, all using the same SYSTEM.DEFAULT.INITIATION.QUEUE for initiation. I use the standard trigger monitor runmqtrm that comes with the product and have it running as a service, defined in the list of services of the queue manager. It is listening for trigger messages and does invoke my applications... most of the time...

My applications are designed for trigger-first: they linger on when the work is done, by doing another MQGET with wait when the first message that triggered them is processed. MQCOMMIT is being called at the right time in the program logic; I have checked that...

All process definitions are set up to invoke the same .cmd file; distinction being made by using the environment data passed as an argument into that command file in order to know what the program actually needs to do. The main program is a standard ANSI C program that invokes different C functions, depending on the value of the input argument. The code then uses regular function calls to invoke the different MQI, as per the book. The trigger message, which is also passed as an argument to the command file, is used to determine which queue to open. Messages are gotten off of that queue and processed accordingly. This works all fine and well as long as the messages arrive on queues that trigger different process definitions.

The strange thing is that when a message arrives on a queue that triggers the same process definition as another queue on which that process definition has triggered while the program is lingering, the arrival of a message on one queue, the arrival of a message on the other queue that is supposed to trigger a second process, doesn't.

If that same message arrives on that second queue when the process that was triggered on the first queue has already terminated, then the second queue does trigger the process correctly.

Stranger still: when the triggering does not take place at arrival of the message on the second queue, it is enough to browse that queue (using a program that I have written for the purpose of checking the message contents during testing that does non-destructive MQGET) to have the triggering kick in.

I don't understand...

Do you think I am entitled to a PMR, or am I doing something wrong?

Searching the archives, nor Google turned up any results on my queries.

Thanks for shedding some light on this matter.

Very best regards,

Jantje.


My process definitions:

PROCESS(TQ3.PR.SND)
APPLTYPE(WINDOWSNT)
APPLICID(START
D:\TQS2010\ACC\QTRIG.CMD)
ENVRDATA(SND)
USERDATA( )
DESCR(Send)

PROCESS(TQ3.PR.RCV)
APPLTYPE(WINDOWSNT)
APPLICID(START
D:\TQS2010\ACC\QTRIG.CMD)
ENVRDATA(RCV)
USERDATA( )
DESCR(Receive)


My queue defintions:

QUEUE(TQ3.QL.SND.TNLA2)
TYPE(QLOCAL)
ACCTQ(QMGR)
BOQNAME( )
BOTHRESH(0)
CLUSNL( )
CLUSTER( )
CLWLPRTY(0)
CLWLRANK(0)
CLWLUSEQ(QMGR)
CURDEPTH(0)
CUSTOM( )
DEFBIND(OPEN)
DEFPRTY(0)
DEFPSIST(YES)
DEFPRESP(SYNC)
DEFREADA(NO)
DEFSOPT(SHARED)
DEFTYPE(PREDEFINED)
DESCR(From Migration)
DISTL(NO)
GET(ENABLED)
NOHARDENBO
INITQ(SYSTEM.DEFAULT.INITIATION.QUEUE)
IPPROCS(0)
MAXDEPTH(50000)
MAXMSGL(131072)
MONQ(QMGR)
MSGDLVSQ(PRIORITY)
TRIGGER
NPMCLASS(NORMAL)
OPPROCS(0)
PROCESS(TQ3.PR.SND)
PUT(ENABLED)
PROPCTL(COMPAT)
QDEPTHHI(5)
QDEPTHLO(2)
QDPHIEV(DISABLED)
QDPLOEV(DISABLED)
QDPMAXEV(ENABLED)
QSVCIEV(NONE)
QSVCINT(999999999)
RETINTVL(999999999)
SCOPE(QMGR)
SHARE
STATQ(QMGR)
TRIGDATA( )
TRIGDPTH(1)
TRIGMPRI(0)
TRIGTYPE(FIRST)
USAGE(NORMAL)


QUEUE(TQ3.QL.ENV.TNLA2.R1)
TYPE(QLOCAL)
ACCTQ(QMGR)
BOQNAME( )
BOTHRESH(0)
CLUSNL( )
CLUSTER( )
CLWLPRTY(0)
CLWLRANK(0)
CLWLUSEQ(QMGR)
CURDEPTH(0)
CUSTOM( )
DEFBIND(OPEN)
DEFPRTY(0)
DEFPSIST(YES)
DEFPRESP(SYNC)
DEFREADA(NO)
DEFSOPT(SHARED)
DEFTYPE(PREDEFINED)
DESCR(Envelopes)
DISTL(NO)
GET(ENABLED)
NOHARDENBO
INITQ(SYSTEM.DEFAULT.INITIATION.QUEUE)
IPPROCS(0)
MAXDEPTH(50000)
MAXMSGL(4194304)
MONQ(QMGR)
MSGDLVSQ(PRIORITY)
TRIGGER
NPMCLASS(NORMAL)
OPPROCS(0)
PROCESS(TQ3.PR.RCV)
PUT(ENABLED)
PROPCTL(COMPAT)
QDEPTHHI(5)
QDEPTHLO(2)
QDPHIEV(DISABLED)
QDPLOEV(DISABLED)
QDPMAXEV(ENABLED)
QSVCIEV(NONE)
QSVCINT(999999999)
RETINTVL(999999999)
SCOPE(QMGR)
SHARE
STATQ(QMGR)
TRIGDATA( )
TRIGDPTH(1)
TRIGMPRI(0)
TRIGTYPE(FIRST)
USAGE(NORMAL)


QUEUE(TQ3.QL.ACC.SPIL.OUT)
TYPE(QLOCAL)
ACCTQ(QMGR)
BOQNAME( )
BOTHRESH(0)
CLUSNL( )
CLUSTER( )
CLWLPRTY(0)
CLWLRANK(0)
CLWLUSEQ(QMGR)
CURDEPTH(0)
CUSTOM( )
DEFBIND(OPEN)
DEFPRTY(0)
DEFPSIST(YES)
DEFPRESP(SYNC)
DEFREADA(NO)
DEFSOPT(SHARED)
DEFTYPE(PREDEFINED)
DESCR(SPIL outbound)
DISTL(NO)
GET(ENABLED)
NOHARDENBO
INITQ(SYSTEM.DEFAULT.INITIATION.QUEUE)
IPPROCS(0)
MAXDEPTH(50000)
MAXMSGL(4194304)
MONQ(QMGR)
MSGDLVSQ(PRIORITY)
TRIGGER
NPMCLASS(NORMAL)
OPPROCS(1)
PROCESS(TQ3.PR.RCV)
PUT(ENABLED)
PROPCTL(COMPAT)
QDEPTHHI(5)
QDEPTHLO(2)
QDPHIEV(DISABLED)
QDPLOEV(DISABLED)
QDPMAXEV(ENABLED)
QSVCIEV(NONE)
QSVCINT(999999999)
RETINTVL(999999999)
SCOPE(QMGR)
SHARE
STATQ(QMGR)
TRIGDATA( )
TRIGDPTH(1)
TRIGMPRI(0)
TRIGTYPE(FIRST)
USAGE(NORMAL)


My trigger monitor definition:

DEFINE SERVICE ('TQS.TRIGGER.MONITOR.ACC') + DESCR('TQS Trigger Monitor for ACC') + STARTCMD('C:\Program Files (x86)\IBM\WebSphere MQ\bin\runmqtrm.exe') + STARTARG('-m +QMNAME+ -q SYSTEM.DEFAULT.INITIATION.QUEUE') + STOPCMD('C:\Program Files (x86)\IBM\WebSphere MQ\bin\amqsstop.exe') + STOPARG('-m +QMNAME+ -p +MQ_SERVER_PID+') +
STDOUT('D:\IBM\WMQ\errors\TQS.TRIGGER.MONITOR.DEV.stdout.log') +
STDERR('D:\IBM\WMQ\errors\TQS.TRIGGER.MONITOR.DEV.stderr.log') +
CONTROL(QMGR) +
SERVTYPE(SERVER) +
REPLACE

To unsubscribe, write to ***@LISTSERV.MEDUNIWIEN.AC.AT and, in the message body (not the subject), write: SIGNOFF MQSERIES Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com
Archive: http://listserv.meduniwien.ac.at/archives/mqser-l.html

To unsubscribe, write to ***@LISTSERV.MEDUNIWIEN.AC.AT and, in the message body (not the subject), write: SIGNOFF MQSERIES Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com
Archive: http://listserv.meduniwien.ac.at/archives/mqser-l.html


To unsubscribe, write to ***@LISTSERV.MEDUNIWIEN.AC.AT and,
in the message body (not the subject), write: SIGNOFF MQSERIES
Instructions for managing your mailing list subscription are provided in
the Listserv General Users Guide available at http://www.lsoft.com
Archive: http://listserv.meduniwien.ac.at
Jantje .
2014-07-11 08:19:50 UTC
Permalink
On Thu, 10 Jul 2014 17:47:32 +0100, Paul Clarke <***@BTINTERNET.COM> wrote:

>This does seem very strange and may be a product.

A product??

> However, with triggering a
>misconfiguration or an application bug can lead to strange results.

That, I can confirm.

> Can you
>show us what QTRIG.CMD does?

I included the code at the end of this reply.


> Is it at all possible that the triggering of
>one queue causes both queues to be opened ?

Not by the same instance of the program, no. I checked that already.


> When you say that the second
>application does finally get triggered, is that when the first one is still
>running...ie. it proves that that the applications CAN run at the same time
>and there is no locking preventing it.

Both can (and have) run in parallel. There might be locks on the database (DB2 for LUW running on the same machine), but these are catered for correctly. The program is doing commits before going to wait for the next message.


Thanks for all your input.

Jantje.




The QTRIG.CMD:

@echo on

rem (c) 2014. GFI.
rem 6/2/2014 Jantje.
rem This command file sets the environment for and invokes the TQS
rem programs for send, receive and acknowledge of envelopes.
rem

Set TQSMQTM=%1
Set TQSPGM=%2

Set TQSPATH=D:\TQS2010\ACC

Set NAT-PATH=%TQSPATH%\NS

Set EXE-PATH=%TQSPATH%
Set DLL-PATH=%TQSPATH%\DLL

set NS-BMP=%DLL-PATH%
set NS-TXT=%DLL-PATH%
set NS-FLW=%DLL-PATH%

rem SET PATH=%DLL-PATH%;%EXE-PATH%;%NAT-PATH%;C:\PROGRA~1\IBM\SQLLIB\BIN;C:\PROGRA~1\IBM\SQLLIB\FUNCTION;%PATH%
SET PATH=%DLL-PATH%;%EXE-PATH%;%NAT-PATH%;%PATH%

SET NS-INI=%EXE-PATH%\INI
rem SET NS-COM=%EXE-PATH%\NSCOM.INI

rem set NS-TRACE=
rem Use the following file for tracing.
set NS-TRACE=%TQSPATH%\TRACE\%TQSPGM%.LOG

c:
cd %TQSPATH%

%DLL-PATH%\chkload C_QTRG5J.dll
rem pause

set >> %TQSPATH%\TRACE\%TQSPGM%_STDOUT.LOG

rem The trick is to call nsbatdrv with only two arguments. The program
rem then knows that the first argument is the triggering message and
rem that the second is the parameters to pass to the NatStar batch
rem driver.
if %TQSPGM% == SAP goto :ReceiveSAP
if NOT NO%NS-TRACE% == NO %TQSPATH%\nsbatdrv.exe %TQSMQTM% LIBRARY=QTRG_TRIGGERING_LS,MAINPGM=QTRG_%TQSPGM%_IN,DBDLL=NS02DB29,DBNAME=TQSA,DBPRM=TQSAdm/natstar >> %TQSPATH%\TRACE\%TQSPGM%_STDOUT.LOG
if NO%NS-TRACE% == NO %TQSPATH%\nsbatdrv.exe %TQSMQTM% LIBRARY=QTRG_TRIGGERING_LS,MAINPGM=QTRG_%TQSPGM%_IN,DBDLL=NS02DB29,DBNAME=TQSA,DBPRM=TQSAdm/natstar,TRACE=NO
if %ERRORLEVEL% EQU 0 exit
goto :Err

:ReceiveSAP
if NOT NO%NS-TRACE% == NO %TQSPATH%\nsbatdrv.exe %TQSMQTM% LIBRARY=QTRG_TRIGGERING_LS,MAINPGM=QTRG_RCV_IN,DBDLL=NS02DB29,DBNAME=TQSA,DBPRM=TQSAdm/natstar >> %TQSPATH%\TRACE\%TQSPGM%_STDOUT.LOG
if NO%NS-TRACE% == NO %TQSPATH%\nsbatdrv.exe %TQSMQTM% LIBRARY=QTRG_TRIGGERING_LS,MAINPGM=QTRG_RCV_IN,DBDLL=NS02DB29,DBNAME=TQSA,DBPRM=TQSAdm/natstar,TRACE=NO
if %ERRORLEVEL% EQU 0 exit

:Err
echo ERRORLEVEL = %ERRORLEVEL% >> %TQSPATH%\TRACE\%TQSPGM%.LOG
echo %TQSMQTM% >> %TQSPATH%\TRACE\%TQSPGM%.LOG

rem pause
exit

To unsubscribe, write to LISTSERV-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org and,
in the message body (not the subject), write: SIGNOFF MQSERIES
Paul Clarke
2014-07-12 06:02:00 UTC
Permalink
X-CTCH-Spam: Unknown
Received: from PAM7 (86.134.134.185) by smtpout08.bt.lon5.cpcloud.co.uk
(8.6.100.99.10223) (authenticated as paul.clarke85) id
53B85D0B00322F9A for MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org; Sat, 12 Jul
2014 07:02:09 +0100
X-Priority: 3
X-MSMail-Priority: Normal
Importance: Normal
X-Mailer: Microsoft Windows Live Mail 15.4.3555.308
X-MimeOLE: Produced By Microsoft MimeOLE V15.4.3555.308
X-PMX-Version: 6.1.0.2415318, Antispam-Engine: 2.7.2.2107409,
Antispam-Data: 2014.7.12.52419
X-PMX-Spam: Gauge=IIIIIIII, Probability=8%, Report=' AT_TLD 0.1,
HTML_00_01 0.05, HTML_00_10 0.05, BODY_SIZE_4000_4999 0,
BODY_SIZE_5000_LESS 0, BODY_SIZE_7000_LESS 0, DKIM_SIGNATURE 0,
INVALID_MSGID_NO_FQDN 0, NO_REAL_NAME 0, URI_ENDS_IN_HTML 0,
__ANY_URI 0, __BOUNCE_CHALLENGE_SUBJ 0, __BOUNCE_NDR_SUBJ_EXEMPT 0,
__CP_URI_IN_BODY 0, __CT 0, __CTE 0, __CT_TEXT_PLAIN 0,
__FORWARDED_MSG 0, __FRAUD_BODY_WEBMAIL 0, __FRAUD_WEBMAIL 0,
__FRAUD_WEBMAIL_FROM 0, __HAS_FROM 0, __HAS_MSGID 0,
__HAS_MSMAIL_PRI 0, __HAS_X_MAILER 0, __HAS_X_PRIORITY 0,
__IN_REP_TO 0, __LINES_OF_YELLING 0, __MIME_TEXT_ONLY 0,
__MIME_VERSION 0, __MSGID_32HEX 0, __PHISH_FROM 0, __PHISH_FROM2 0,
__PHISH_SPEAR_STRUCTURE_1 0, __SANE_MSGID 0, __STOCK_PHRASE_7 0,
__SUBJ_ALPHA_END 0, __
Sender: MQSeries List <MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org>
In-Reply-To: <7427599113124879.WA.jan.moeyersonsgfi.be-JX7+OpRa80QeFbOYke1v4oOpTq8/***@public.gmane.org>
Precedence: list
List-Help: <http://listserv.meduniwien.ac.at/cgi-bin/wa?LIST=MQSERIES>,
<mailto:LISTSERV-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org?body=INFO%20MQSERIES>
List-Unsubscribe: <mailto:MQSERIES-unsubscribe-request-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org>
List-Subscribe: <mailto:MQSERIES-subscribe-request-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org>
List-Owner: <mailto:MQSERIES-request-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org>
List-Archive: <http://listserv.meduniwien.ac.at/cgi-bin/wa?LIST=MQSERIES>
Archived-At: <http://permalink.gmane.org/gmane.network.mq.devel/17946>

Sorry...typo.....I meant "This does seem very strange and may be a product
bug".

It does sound, from what you've written later, as though you may have a
found a bug. It should not be necessary to have a different Process object
for each queue. Back before MQ supported "transmission queue triggering
without a process object" I used to define a single process object 'DUMMY'
and set that to all of my transmission queues. And, needless to say,
triggering worked fine. So, if it is a bug it must be fairly subtle or tied
to a particular release level or something. You may well have reached the
point where it would be contacting service particularly if you can re-create
your situation in a test environment (since I understand you have done the
workaround for production).

Cheers,
Paul.

Paul Clarke
www.mqgem.com
-----Original Message-----
From: Jantje .
Sent: Friday, July 11, 2014 9:19 AM
To: MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org
Subject: Re: Different queue, same process and not triggering

On Thu, 10 Jul 2014 17:47:32 +0100, Paul Clarke
<paul.clarke85-C2P5NI4ZpDVm9/***@public.gmane.org> wrote:

>This does seem very strange and may be a product.

A product??

> However, with triggering a
>misconfiguration or an application bug can lead to strange results.

That, I can confirm.

> Can you
>show us what QTRIG.CMD does?

I included the code at the end of this reply.


> Is it at all possible that the triggering of
>one queue causes both queues to be opened ?

Not by the same instance of the program, no. I checked that already.


> When you say that the second
>application does finally get triggered, is that when the first one is still
>running...ie. it proves that that the applications CAN run at the same time
>and there is no locking preventing it.

Both can (and have) run in parallel. There might be locks on the database
(DB2 for LUW running on the same machine), but these are catered for
correctly. The program is doing commits before going to wait for the next
message.


Thanks for all your input.

Jantje.




The QTRIG.CMD:

@echo on

rem (c) 2014. GFI.
rem 6/2/2014 Jantje.
rem This command file sets the environment for and invokes the TQS
rem programs for send, receive and acknowledge of envelopes.
rem

Set TQSMQTM=%1
Set TQSPGM=%2

Set TQSPATH=D:\TQS2010\ACC

Set NAT-PATH=%TQSPATH%\NS

Set EXE-PATH=%TQSPATH%
Set DLL-PATH=%TQSPATH%\DLL

set NS-BMP=%DLL-PATH%
set NS-TXT=%DLL-PATH%
set NS-FLW=%DLL-PATH%

rem SET
PATH=%DLL-PATH%;%EXE-PATH%;%NAT-PATH%;C:\PROGRA~1\IBM\SQLLIB\BIN;C:\PROGRA~1\IBM\SQLLIB\FUNCTION;%PATH%
SET PATH=%DLL-PATH%;%EXE-PATH%;%NAT-PATH%;%PATH%

SET NS-INI=%EXE-PATH%\INI
rem SET NS-COM=%EXE-PATH%\NSCOM.INI

rem set NS-TRACE=
rem Use the following file for tracing.
set NS-TRACE=%TQSPATH%\TRACE\%TQSPGM%.LOG

c:
cd %TQSPATH%

%DLL-PATH%\chkload C_QTRG5J.dll
rem pause

set >> %TQSPATH%\TRACE\%TQSPGM%_STDOUT.LOG

rem The trick is to call nsbatdrv with only two arguments. The program
rem then knows that the first argument is the triggering message and
rem that the second is the parameters to pass to the NatStar batch
rem driver.
if %TQSPGM% == SAP goto :ReceiveSAP
if NOT NO%NS-TRACE% == NO %TQSPATH%\nsbatdrv.exe %TQSMQTM%
LIBRARY=QTRG_TRIGGERING_LS,MAINPGM=QTRG_%TQSPGM%_IN,DBDLL=NS02DB29,DBNAME=TQSA,DBPRM=TQSAdm/natstar
>> %TQSPATH%\TRACE\%TQSPGM%_STDOUT.LOG
if NO%NS-TRACE% == NO %TQSPATH%\nsbatdrv.exe %TQSMQTM%
LIBRARY=QTRG_TRIGGERING_LS,MAINPGM=QTRG_%TQSPGM%_IN,DBDLL=NS02DB29,DBNAME=TQSA,DBPRM=TQSAdm/natstar,TRACE=NO
if %ERRORLEVEL% EQU 0 exit
goto :Err

:ReceiveSAP
if NOT NO%NS-TRACE% == NO %TQSPATH%\nsbatdrv.exe %TQSMQTM%
LIBRARY=QTRG_TRIGGERING_LS,MAINPGM=QTRG_RCV_IN,DBDLL=NS02DB29,DBNAME=TQSA,DBPRM=TQSAdm/natstar
>> %TQSPATH%\TRACE\%TQSPGM%_STDOUT.LOG
if NO%NS-TRACE% == NO %TQSPATH%\nsbatdrv.exe %TQSMQTM%
LIBRARY=QTRG_TRIGGERING_LS,MAINPGM=QTRG_RCV_IN,DBDLL=NS02DB29,DBNAME=TQSA,DBPRM=TQSAdm/natstar,TRACE=NO
if %ERRORLEVEL% EQU 0 exit

:Err
echo ERRORLEVEL = %ERRORLEVEL% >> %TQSPATH%\TRACE\%TQSPGM%.LOG
echo %TQSMQTM% >> %TQSPATH%\TRACE\%TQSPGM%.LOG

rem pause
exit

To unsubscribe, write to LISTSERV-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org and,
in the message body (not the subject), write: SIGNOFF MQSERIES
Instructions for managing your mailing list subscription are provided in
the Listserv General Users Guide available at http://www.lsoft.com
Archive: http://listserv.meduniwien.ac.at/archives/mqser-l.html

To unsubscribe, write to LISTSERV-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org and,
in the message body (not the subject), write: SIGNOFF MQSERIES
Jantje .
2014-07-11 08:34:39 UTC
Permalink
On Thu, 10 Jul 2014 16:49:52 +0000, Potkay, Peter M (CTO Architecture + Engineering) <Peter.Potkay-***@public.gmane.org> wrote:

>Every triggered app needs to read until MQRC 2033, but especially trigger Every applications. If a trigger Every app reads only one messages, its only a matter of time of when, not if but when, you will find yourself with a rolling backlog of messages on the app queue where a new message lands on the app queue, you get triggered, you pick up only one old message and end. Triggered Every apps must read till 2033.
>

Agreed.



>Triggered First apps should too, but there its not such a problem if the app only reads one and done, because in this case IBM made the queue retrigger if its closed with more than zero messages on it. If you find yourself with the backlog and you only consume one when you get triggered, you will retrigger rapidly until the back log is cleared. This does not happen for trigger every and trigger depth, hence the importance of reading until 2033.
>

Again, agreed, I have been able to observe this behaviour in other applications. My application, however, does loop around until 2033, because I need to do as much work as possible in one go, because the initialization of this particular program is very costly and I need to avoid doing the initialization over and over.



>Its debatable on if a triggered app should wait and how long once it gets the 2033. That really depends on the pattern of message arrival. No sense to wait 5 seconds in a triggered app for a scenario where one message arrives once a week, right?
>

In this particular case, message arrival can be erratic. I therefore wait a configurable amount of time after the last message in a bunch has been processed. With a wait time of 3 minutes this makes my triggered application linger long enough to remain running for most of the time during business hours and still terminate soon enough not to get in the way of the backups, etc.



>But I think Janje issue is most likely related to not starting the triggered processes in the background like Jeff said. The trigger monitor is stuck keeping track of the first instance of the triggered process and not ready to go with another instance.
>

That is indeed what it looks like.

I must say: I am rather sure the trigger monitor is _not_ waiting for my command file to terminate, because, as you can see, I use START in the APPLICID. That way, the trigger monitor fires of the cmd.exe and returns immediately waiting for the next trigger message. This is corroborated by the entries in the log files and by the fact that in the mean time, that same trigger monitor does trigger processes on other, non related queues.


Thanks and very best regards,

Jantje.

To unsubscribe, write to LISTSERV-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org and,
in the message body (not the subject), write: SIGNOFF MQSERIES
T.Rob
2014-07-11 08:45:51 UTC
Permalink
X-Report-Abuse-To: spam-RAvZ+8ubYLwZD488Lvc0IA6ISnHq+hSGQ0cMyQF+***@public.gmane.org
X-Filter-Fingerprint: cPaH8lomer6UwsJ3BnJDyts/W+OagfBsRYjpo1vNhue0VFDyP20las9Mq1v6nXmfrqKtWpHLpkE8
c09GKJn2t/FyiIpBuGxdC1t+BVK4YSxMqRJTan78INzQLlEGX/jFeWzOxjGHKKqvV47Z9+T++HU4
H51jyCSmLdA2hPaiVpwYWaeThsiFlmPt/lOSmjPe+JcaBMWQNjUWwsiPaT4RHGqK95LAXg+Ea3Jb
F9WwpaZ//Un1C5ivAWoOksRE8XtOTT9J6CK2j8j7/AJ9TNml+Pv26ixoANMuu+foSq5rgwGe9Xyf
0LSMk3TACEF6SjSODhzV7uPkaUIZRA3xAP9yJuTIseFsyqheDENFXFtgNIcl5pmJFHpgH+n/qBky
tLHCK8qgx2wyiXqsLo2Xgx3r6CDDSEepx91YApW7E9vzQDr4Em6yxnYJdCvqEVvcIZwL+6IQmhc0
KYEMMSdWYVm5wouP4i+Bx0wuorMPjexmew8xL7hrJSk60SF3F6RYOYr2
X-Originating-IP: 184.154.225.7
X-SpamExperts-Domain: siteground247.com
X-SpamExperts-Username: 184.154.225.7
X-SpamExperts-Outgoing-Class: ham
X-SpamExperts-Outgoing-Evidence: SB/global_tokens (0.00646346817103)
X-Recommended-Action: accept
X-PMX-Version: 6.1.0.2415318, Antispam-Engine: 2.7.2.2107409,
Antispam-Data: 2014.7.11.90621
X-PMX-Spam: Gauge=IIIIIIIII, Probability=9%, Report=' AT_TLD 0.1,
FROM_NAME_ONE_WORD 0.05, HTML_00_01 0.05, HTML_00_10 0.05,
SUPERLONG_LINE 0.05, BODY_SIZE_4000_4999 0, BODY_SIZE_5000_LESS 0,
BODY_SIZE_7000_LESS 0, DATE_TZ_NA 0, FORGED_MUA_OUTLOOK 0,
URI_ENDS_IN_HTML 0, WEBMAIL_SOURCE 0, WEBMAIL_XOIP 0,
WEBMAIL_X_IP_HDR 0, __ANY_URI 0, __BOUNCE_CHALLENGE_SUBJ 0,
__BOUNCE_NDR_SUBJ_EXEMPT 0, __CP_URI_IN_BODY 0, __CT 0, __CTE 0,
__CT_TEXT_PLAIN 0, __FORWARDED_MSG 0, __HAS_FROM 0, __HAS_MSGID 0,
__HAS_X_MAILER 0, __IN_REP_TO 0, __MIME_TEXT_ONLY 0,
__MIME_VERSION 0, __OUTLOOK_MUA 0, __OUTLOOK_MUA_1 0,
__SANE_MSGID 0, __SUBJ_ALPHA_END 0, __SUBJ_ALPHA_NEGATE 0,
__TO_MALFORMED_2 0, __URI_NS , __USER_AGENT_MS_GENERIC 0'
Sender: MQSeries List <MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org>
In-Reply-To: <4075717376144566.WA.jan.moeyersonsgfi.be-JX7+OpRa80QeFbOYke1v4oOpTq8/***@public.gmane.org>
Precedence: list
List-Help: <http://listserv.meduniwien.ac.at/cgi-bin/wa?LIST=MQSERIES>,
<mailto:LISTSERV-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org?body=INFO%20MQSERIES>
List-Unsubscribe: <mailto:MQSERIES-unsubscribe-request-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org>
List-Subscribe: <mailto:MQSERIES-subscribe-request-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org>
List-Owner: <mailto:MQSERIES-request-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org>
List-Archive: <http://listserv.meduniwien.ac.at/cgi-bin/wa?LIST=MQSERIES>
Archived-At: <http://permalink.gmane.org/gmane.network.mq.devel/17931>

Jantje,

> I must say: I am rather sure the trigger monitor is _not_ waiting for my
> command file to terminate, because, as you can see, I use START in the
> APPLICID. That way, the trigger monitor fires of the cmd.exe and returns
> immediately waiting for the next trigger message. This is corroborated by
> the entries in the log files and by the fact that in the mean time, that
> same trigger monitor does trigger processes on other, non related queues.

This rings a bell for me. IIRC, one of the reasons we had to do the START /b CMD /c CALL was that started programs update the environment of the parent whereas call does not. It may be that your started programs are stomping on each other's environment.

-- T.Rob


> -----Original Message-----
> From: MQSeries List [mailto:MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org] On Behalf
> Of Jantje .
> Sent: Friday, July 11, 2014 4:35 AM
> To: MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org
> Subject: Re: Different queue, same process and not triggering
>
> On Thu, 10 Jul 2014 16:49:52 +0000, Potkay, Peter M (CTO Architecture +
> Engineering) <Peter.Potkay-***@public.gmane.org> wrote:
>
> >Every triggered app needs to read until MQRC 2033, but especially trigger
> Every applications. If a trigger Every app reads only one messages, its
> only a matter of time of when, not if but when, you will find yourself
> with a rolling backlog of messages on the app queue where a new message
> lands on the app queue, you get triggered, you pick up only one old
> message and end. Triggered Every apps must read till 2033.
> >
>
> Agreed.
>
>
>
> >Triggered First apps should too, but there its not such a problem if the
> app only reads one and done, because in this case IBM made the queue
> retrigger if its closed with more than zero messages on it. If you find
> yourself with the backlog and you only consume one when you get triggered,
> you will retrigger rapidly until the back log is cleared. This does not
> happen for trigger every and trigger depth, hence the importance of
> reading until 2033.
> >
>
> Again, agreed, I have been able to observe this behaviour in other
> applications. My application, however, does loop around until 2033,
> because I need to do as much work as possible in one go, because the
> initialization of this particular program is very costly and I need to
> avoid doing the initialization over and over.
>
>
>
> >Its debatable on if a triggered app should wait and how long once it gets
> the 2033. That really depends on the pattern of message arrival. No sense
> to wait 5 seconds in a triggered app for a scenario where one message
> arrives once a week, right?
> >
>
> In this particular case, message arrival can be erratic. I therefore wait
> a configurable amount of time after the last message in a bunch has been
> processed. With a wait time of 3 minutes this makes my triggered
> application linger long enough to remain running for most of the time
> during business hours and still terminate soon enough not to get in the
> way of the backups, etc.
>
>
>
> >But I think Janje issue is most likely related to not starting the
> triggered processes in the background like Jeff said. The trigger monitor
> is stuck keeping track of the first instance of the triggered process and
> not ready to go with another instance.
> >
>
> That is indeed what it looks like.
>
> I must say: I am rather sure the trigger monitor is _not_ waiting for my
> command file to terminate, because, as you can see, I use START in the
> APPLICID. That way, the trigger monitor fires of the cmd.exe and returns
> immediately waiting for the next trigger message. This is corroborated by
> the entries in the log files and by the fact that in the mean time, that
> same trigger monitor does trigger processes on other, non related queues.
>
>
> Thanks and very best regards,
>
> Jantje.
>
> To unsubscribe, write to LISTSERV-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org and, in the
> message body (not the subject), write: SIGNOFF MQSERIES Instructions for
> managing your mailing list subscription are provided in the Listserv
> General Users Guide available at http://www.lsoft.com
> Archive: http://listserv.meduniwien.ac.at/archives/mqser-l.html

To unsubscribe, write to LISTSERV-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org and,
in the message body (not the subject), write: SIGNOFF MQSERIES
Jantje .
2014-07-11 08:41:34 UTC
Permalink
On Thu, 10 Jul 2014 16:53:27 +0000, Potkay, Peter M (CTO Architecture + Engineering) <Peter.Potkay-***@public.gmane.org> wrote:


>Consider enforcing a one to one relationship between triggered queues and process definitions, even if they are exactly the same.
>


You know, what? I just copied the process definition so each of the two queues have their own process definition (invoking exactly the same program as before) and it seems to work A-OK.

Beats me...

I will continue to watch for a day and see if it continues to work well.

Big thanks for this suggestion, Peter. I guess you just discovered condition number 20 for triggering. Maybe do a comment on the documentation...

Thanks,

Jantje.

To unsubscribe, write to LISTSERV-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org and,
in the message body (not the subject), write: SIGNOFF MQSERIES
Jantje .
2014-07-11 09:09:11 UTC
Permalink
On Thu, 10 Jul 2014 11:54:59 -0500, Jefferson Lowrey <jlowrey-rIXRsD/***@public.gmane.org> wrote:

>In this case, you're looking for an absence of information. You would see
>data about the first application being triggered and the trigger monitor
>waiting for another trigger message, and then an entire lack of data until
>the first program had stopped and the second application was finally
>triggered.
>

I just double-checked the log of the trigger monitor. It reports that it _did_ fire the process on the second queue, only that process, I am sure, did not run... I can see that in my application's log file.

Then, some time later, when I ran my program that browses the messages on the queue, the trigger monitor reports _again_ that it triggered the process that should have been running before. And this time, the program did indeed run.

Very strange, indeed.


>If this is what you see, then I kind of agree with Paul that it's somewhat
>likely that the second queue is open.

No, symptoms are different.



> And, yes, I know that the trigger
>conditions are complex and make the brain hurt.

You can say that again...



>But you have to walk
>through them to verify that all conditions *are* met and that no trigger
>message is produced.

Well... According to the trigger monitor log, the trigger message was produced as it should have been. And a second time when I browsed the queue later on.



>You'll have to do it as part of a PMR anyway, so you
>might as well assemble the evidence anyway.
>

I probably will. Then again, as Peter's suggestion of having a separate (duplicate) process definition seems to solve the problem. At least I have a work-around.


Thanks again,

Jantje.

To unsubscribe, write to LISTSERV-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org and,
in the message body (not the subject), write: SIGNOFF MQSERIES
Richard Tsujimoto
2014-07-11 10:41:03 UTC
Permalink
The START command switches /B and /WAIT are mutually exclusive. I suspect the /WAIT is the default (and I also suspect it causes serialization through your triggered program).

-----Original Message-----
From: MQSeries List [mailto:MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org] On Behalf Of Jantje .
Sent: Friday, July 11, 2014 5:09 AM
To: MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org
Subject: Re: Different queue, same process and not triggering

On Thu, 10 Jul 2014 11:54:59 -0500, Jefferson Lowrey <jlowrey-rIXRsD/***@public.gmane.org> wrote:

>In this case, you're looking for an absence of information. You would
>see data about the first application being triggered and the trigger
>monitor waiting for another trigger message, and then an entire lack of
>data until the first program had stopped and the second application was
>finally triggered.
>

I just double-checked the log of the trigger monitor. It reports that it _did_ fire the process on the second queue, only that process, I am sure, did not run... I can see that in my application's log file.

Then, some time later, when I ran my program that browses the messages on the queue, the trigger monitor reports _again_ that it triggered the process that should have been running before. And this time, the program did indeed run.

Very strange, indeed.


>If this is what you see, then I kind of agree with Paul that it's
>somewhat likely that the second queue is open.

No, symptoms are different.



> And, yes, I know that the trigger
>conditions are complex and make the brain hurt.

You can say that again...



>But you have to walk
>through them to verify that all conditions *are* met and that no
>trigger message is produced.

Well... According to the trigger monitor log, the trigger message was produced as it should have been. And a second time when I browsed the queue later on.



>You'll have to do it as part of a PMR anyway, so you might as well
>assemble the evidence anyway.
>

I probably will. Then again, as Peter's suggestion of having a separate (duplicate) process definition seems to solve the problem. At least I have a work-around.


Thanks again,

Jantje.

To unsubscribe, write to LISTSERV-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org and, in the message body (not the subject), write: SIGNOFF MQSERIES Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com
Archive: http://listserv.meduniwien.ac.at/archives/mqser-l.html

To unsubscribe, write to LISTSERV-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org and,
in the message body (not the subject), write: SIGNOFF MQSERIES
Tim Zielke
2014-07-11 12:31:37 UTC
Permalink
Hi Jantje,

"I just double-checked the log of the trigger monitor. It reports that it _did_ fire the process on the second queue, only that process, I am sure, did not run... I can see that in my application's log file.

Then, some time later, when I ran my program that browses the messages on the queue, the trigger monitor reports _again_ that it triggered the process that should have been running before. And this time, the program did indeed run."


Are you sure the process did not run? Is it possible your program failed before it was able to write out to its application log? On our Windows MQ servers, we have the Sysinternals Process Explorer and Process Monitor for debugging purposes. This is a free Windows tool and the Process Monitor should allow you to confirm if your program did run or not. Also, the trace of the runmqtrm will tell you the response that MQ got back from the operating system when it tried to start the process, to help you see if it was successful or not.


"I probably will. Then again, as Peter's suggestion of having a separate (duplicate) process definition seems to solve the problem. At least I have a work-around."


On the Unix space, we definitely have situations with 100s of queues that share the same process definition, and we have not had issues with triggering as you are mentioning. Based on the behavior you described, it sounds almost like your program is acting differently based on the process name that is passed in the trigger message.

Thanks,
Tim


-----Original Message-----
From: MQSeries List [mailto:***@LISTSERV.MEDUNIWIEN.AC.AT] On Behalf Of Jantje .
Sent: Friday, July 11, 2014 4:09 AM
To: ***@LISTSERV.MEDUNIWIEN.AC.AT
Subject: Re: Different queue, same process and not triggering

On Thu, 10 Jul 2014 11:54:59 -0500, Jefferson Lowrey <***@US.IBM.COM> wrote:

>In this case, you're looking for an absence of information. You would
>see data about the first application being triggered and the trigger
>monitor waiting for another trigger message, and then an entire lack of
>data until the first program had stopped and the second application was
>finally triggered.
>

I just double-checked the log of the trigger monitor. It reports that it _did_ fire the process on the second queue, only that process, I am sure, did not run... I can see that in my application's log file.

Then, some time later, when I ran my program that browses the messages on the queue, the trigger monitor reports _again_ that it triggered the process that should have been running before. And this time, the program did indeed run.

Very strange, indeed.


>If this is what you see, then I kind of agree with Paul that it's
>somewhat likely that the second queue is open.

No, symptoms are different.



> And, yes, I know that the trigger
>conditions are complex and make the brain hurt.

You can say that again...



>But you have to walk
>through them to verify that all conditions *are* met and that no
>trigger message is produced.

Well... According to the trigger monitor log, the trigger message was produced as it should have been. And a second time when I browsed the queue later on.



>You'll have to do it as part of a PMR anyway, so you might as well
>assemble the evidence anyway.
>

I probably will. Then again, as Peter's suggestion of having a separate (duplicate) process definition seems to solve the problem. At least I have a work-around.


Thanks again,

Jantje.

To unsubscribe, write to ***@LISTSERV.MEDUNIWIEN.AC.AT and, in the message body (not the subject), write: SIGNOFF MQSERIES Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com
Archive: http://listserv.meduniwien.ac.at/archives/mqser-l.html


To unsubscribe, write to ***@LISTSERV.MEDUNIWIEN.AC.AT and,
in the message body (not the subject), write: SIGNOFF MQSERIES
Instructions for managing your mailing list subscription are provided in
the Listserv General Users Guide available at http://www.lsoft.com
Archive: http:
Jefferson Lowrey
2014-07-11 13:08:17 UTC
Permalink
Based on everything said so far, it seems clear that triggering itself is
working correctly. The trigger message is created, the trigger monitor
reads it and launches the right program.

It's just that the program being triggered is misbehaving.

So as Tim says, time to find out why.

Thank you,

Jeff Lowrey




From: Tim Zielke <tim.zielke-PR+tvw7B/***@public.gmane.org>
To: MQSERIES-JX7+OpRa80QeFbOYke1v4oOpTq8/***@public.gmane.org
Date: 07/11/2014 07:31 AM
Subject: Re: [MQSERIES] Different queue, same process and not
triggering
Sent by: MQSeries List <MQSERIES-JX7+OpRa80QeFbOYke1v4oOpTq8/***@public.gmane.org>



Hi Jantje,

"I just double-checked the log of the trigger monitor. It reports that it
_did_ fire the process on the second queue, only that process, I am sure,
did not run... I can see that in my application's log file.

Then, some time later, when I ran my program that browses the messages on
the queue, the trigger monitor reports _again_ that it triggered the
process that should have been running before. And this time, the program
did indeed run."


Are you sure the process did not run? Is it possible your program failed
before it was able to write out to its application log? On our Windows MQ
servers, we have the Sysinternals Process Explorer and Process Monitor for
debugging purposes. This is a free Windows tool and the Process Monitor
should allow you to confirm if your program did run or not. Also, the
trace of the runmqtrm will tell you the response that MQ got back from the
operating system when it tried to start the process, to help you see if it
was successful or not.


"I probably will. Then again, as Peter's suggestion of having a separate
(duplicate) process definition seems to solve the problem. At least I have
a work-around."


On the Unix space, we definitely have situations with 100s of queues that
share the same process definition, and we have not had issues with
triggering as you are mentioning. Based on the behavior you described, it
sounds almost like your program is acting differently based on the process
name that is passed in the trigger message.

Thanks,
Tim


-----Original Message-----
From: MQSeries List [mailto:MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org] On Behalf
Of Jantje .
Sent: Friday, July 11, 2014 4:09 AM
To: MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org
Subject: Re: Different queue, same process and not triggering

On Thu, 10 Jul 2014 11:54:59 -0500, Jefferson Lowrey <jlowrey-rIXRsD/***@public.gmane.org>
wrote:

>In this case, you're looking for an absence of information. You would
>see data about the first application being triggered and the trigger
>monitor waiting for another trigger message, and then an entire lack of
>data until the first program had stopped and the second application was
>finally triggered.
>

I just double-checked the log of the trigger monitor. It reports that it
_did_ fire the process on the second queue, only that process, I am sure,
did not run... I can see that in my application's log file.

Then, some time later, when I ran my program that browses the messages on
the queue, the trigger monitor reports _again_ that it triggered the
process that should have been running before. And this time, the program
did indeed run.

Very strange, indeed.


>If this is what you see, then I kind of agree with Paul that it's
>somewhat likely that the second queue is open.

No, symptoms are different.



> And, yes, I know that the trigger
>conditions are complex and make the brain hurt.

You can say that again...



>But you have to walk
>through them to verify that all conditions *are* met and that no
>trigger message is produced.

Well... According to the trigger monitor log, the trigger message was
produced as it should have been. And a second time when I browsed the
queue later on.



>You'll have to do it as part of a PMR anyway, so you might as well
>assemble the evidence anyway.
>

I probably will. Then again, as Peter's suggestion of having a separate
(duplicate) process definition seems to solve the problem. At least I have
a work-around.


Thanks again,

Jantje.

To unsubscribe, write to LISTSERV-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org and, in the
message body (not the subject), write: SIGNOFF MQSERIES Instructions for
managing your mailing list subscription are provided in the Listserv
General Users Guide available at http://www.lsoft.com
Archive: http://listserv.meduniwien.ac.at/archives/mqser-l.html


To unsubscribe, write to LISTSERV-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org and,
in the message body (not the subject), write: SIGNOFF MQSERIES
Instructions for managing your mailing list subscription are provided in
the Listserv General Users Guide available at http://www.lsoft.com
Archive: http://listserv.meduniwien.ac.at/archives/mqser-l.html


To unsubscribe, write to LISTSERV-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org and,
in the message body (not the subject), write: SIGNOFF MQSERIES
Instructions for managing your mailing list subscription are provided in
the Listserv General Users Guide available at http://www.lsoft.com
Archive: http://listserv.meduniwien.ac.at/archives/mqser-l.html
Jantje .
2014-07-11 09:12:40 UTC
Permalink
On Thu, 10 Jul 2014 13:13:03 -0400, Richard Tsujimoto <rtsujimoto-***@public.gmane.orgCOM> wrote:

>Just a suggestion. Show the process definitions.

Dear Richard-san,

All definitions of processes and queues involved were already included in my original post.


>Windows has a peculiar way for defining separate background processes that need to run concurrently.

Would you mind elaborating on that, please?


Thanks,

Jantje.

To unsubscribe, write to LISTSERV-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org and,
in the message body (not the subject), write: SIGNOFF MQSERIES
Jantje .
2014-07-11 09:22:26 UTC
Permalink
On Thu, 10 Jul 2014 17:46:22 -0400, T.Rob <t.rob-CkT6zf+urXSzW/GOMZKyElesiRL1/***@public.gmane.org> wrote:

>Jantje,
>
>From your process def...
>
>APPLICID("START D:\TQS2010\ACC\QTRIG.CMD")
>
>Have you tried...
>
>APPLICID("START /B CMD /C CALL D:\TQS2010\ACC\QTRIG.CMD")
>

Actually, no, I did not try that. But IMHO, the result would be exactly the same. The /B prevents a new window being created, but the CMD will run in a separate process anyway, it seems to me. My syntax will make Windows create a new window in which CMD will be invoked implicitly.

And it does work when separate process definitions are involved...


Thanks for the suggestion anyway.

Cheers,

Jantje.

To unsubscribe, write to LISTSERV-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org and,
in the message body (not the subject), write: SIGNOFF MQSERIES
Jantje .
2014-07-11 09:32:08 UTC
Permalink
On Fri, 11 Jul 2014 04:45:51 -0400, T.Rob <t.rob-CkT6zf+urXSzW/GOMZKyElesiRL1/***@public.gmane.org> wrote:

>This rings a bell for me. IIRC, one of the reasons we had to do the START /b CMD /c CALL was that started programs update the environment of the parent whereas call does not.
>

Does it? Wow, there's a vicious hidden security breach if ever I saw one!

I did not know that. I'll amend my process definitions immediately.

Thanks,

Jantje.

To unsubscribe, write to LISTSERV-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org and,
in the message body (not the subject), write: SIGNOFF MQSERIES
Jantje .
2014-07-11 10:51:55 UTC
Permalink
On Fri, 11 Jul 2014 06:41:03 -0400, Richard Tsujimoto <rtsujimoto-***@public.gmane.orgCOM> wrote:

>The START command switches /B and /WAIT are mutually exclusive. I suspect the /WAIT is the default (and I also suspect it causes serialization through your triggered program).
>

Dear Richard-san,

No, they are not mutually exclusive; nothing to stop you from specifying them both.

No, the /WAIT is not the default. It is not causing any serialization in my set-up.

Cheers,

Jantje.

To unsubscribe, write to LISTSERV-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org and,
in the message body (not the subject), write: SIGNOFF MQSERIES
Richard Tsujimoto
2014-07-11 11:27:51 UTC
Permalink
When you test out the changes, it should be revealing what happens

-----Original Message-----
From: MQSeries List [mailto:MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org] On Behalf Of Jantje .
Sent: Friday, July 11, 2014 6:52 AM
To: MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org
Subject: Re: Different queue, same process and not triggering

On Fri, 11 Jul 2014 06:41:03 -0400, Richard Tsujimoto <rtsujimoto-dEbs1jsJ3+***@public.gmane.org> wrote:

>The START command switches /B and /WAIT are mutually exclusive. I suspect the /WAIT is the default (and I also suspect it causes serialization through your triggered program).
>

Dear Richard-san,

No, they are not mutually exclusive; nothing to stop you from specifying them both.

No, the /WAIT is not the default. It is not causing any serialization in my set-up.

Cheers,

Jantje.

To unsubscribe, write to LISTSERV-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org and, in the message body (not the subject), write: SIGNOFF MQSERIES Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com
Archive: http://listserv.meduniwien.ac.at/archives/mqser-l.html

To unsubscribe, write to LISTSERV-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org and,
in the message body (not the subject), write: SIGNOFF MQSERIES
Jantje .
2014-07-11 13:55:06 UTC
Permalink
On Fri, 11 Jul 2014 07:27:51 -0400, Richard Tsujimoto <rtsujimoto-***@public.gmane.orgCOM> wrote:

>When you test out the changes, it should be revealing what happens
>

I did test it.

Having one process definition per queue made the problem go away.

Cheers,

Jantje.

To unsubscribe, write to LISTSERV-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org and,
in the message body (not the subject), write: SIGNOFF MQSERIES
Jantje .
2014-07-11 14:03:04 UTC
Permalink
On Fri, 11 Jul 2014 12:31:37 +0000, Tim Zielke <tim.zielke-PR+tvw7B/***@public.gmane.org> wrote:


> Are you sure the process did not run? Is it possible your program failed before it was able to write out to its application log?

I am pretty sure it did not run. The program is writing to its log file very early in its initialization; before it really has a chance to go wrong...


>On our Windows MQ servers, we have the Sysinternals Process Explorer and Process Monitor for debugging purposes.

I know and use this tool often. Problem is: if ProcExplorer does not show the program, is that because it did not run or is it because it did not run long enough to show? ProcMon would tell me, but I do not have that one on the machine where this is all happening. I'll see whether to go through the hassle to have it installed for me. But thanks for the very valid suggestion.


>On the Unix space, we definitely have situations with 100s of queues that share the same process definition, and we have not had issues with triggering as you are mentioning.

In CICS we have no issues either. We have an installation where thousands of queues share a single process definition and all is hunky-dory.


>Based on the behavior you described, it sounds almost like your program is acting differently based on the process name that is passed in the trigger message.

Well, I can assure you that the only information that is picked up from the trigger message is the name of the queue that triggered the process. Nothing else.

Cheers,

Jantje.

To unsubscribe, write to LISTSERV-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org and,
in the message body (not the subject), write: SIGNOFF MQSERIES
Tim Zielke
2014-07-11 14:07:49 UTC
Permalink
ProcExplorer only gives you the current running processes, so you could definitely be missing it, if the nsbatdrv.exe is failing right away. ProcMon would definitely be the way to go, as you should see the QTRIG.CMD process getting started, and then I believe the nsbatdrv.exe would show up as a second process, if it is being invoked. Another way to help debug this would be to add print statements to your QTRIG.CMD, and see what path it is following through the script.

Thanks,
Tim

-----Original Message-----
From: MQSeries List [mailto:***@LISTSERV.MEDUNIWIEN.AC.AT] On Behalf Of Jantje .
Sent: Friday, July 11, 2014 9:03 AM
To: ***@LISTSERV.MEDUNIWIEN.AC.AT
Subject: Re: Different queue, same process and not triggering

On Fri, 11 Jul 2014 12:31:37 +0000, Tim Zielke <***@AON.COM> wrote:


> Are you sure the process did not run? Is it possible your program failed before it was able to write out to its application log?

I am pretty sure it did not run. The program is writing to its log file very early in its initialization; before it really has a chance to go wrong...


>On our Windows MQ servers, we have the Sysinternals Process Explorer and Process Monitor for debugging purposes.

I know and use this tool often. Problem is: if ProcExplorer does not show the program, is that because it did not run or is it because it did not run long enough to show? ProcMon would tell me, but I do not have that one on the machine where this is all happening. I'll see whether to go through the hassle to have it installed for me. But thanks for the very valid suggestion.


>On the Unix space, we definitely have situations with 100s of queues that share the same process definition, and we have not had issues with triggering as you are mentioning.

In CICS we have no issues either. We have an installation where thousands of queues share a single process definition and all is hunky-dory.


>Based on the behavior you described, it sounds almost like your program is acting differently based on the process name that is passed in the trigger message.

Well, I can assure you that the only information that is picked up from the trigger message is the name of the queue that triggered the process. Nothing else.

Cheers,

Jantje.

To unsubscribe, write to ***@LISTSERV.MEDUNIWIEN.AC.AT and, in the message body (not the subject), write: SIGNOFF MQSERIES Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com
Archive: http://listserv.meduniwien.ac.at/archives/mqser-l.html


To unsubscribe, write to ***@LISTSERV.MEDUNIWIEN.AC.AT and,
in the message body (not the subject), write: SIGNOFF MQSERIES
Instructions for managing your mailing list subscription are provided in
the Listserv General Users Guide available at http://www.lsoft.com
Archive: http://listserv.meduniwien.ac.at/archives/
Potkay, Peter M (CTO Architecture + Engineering)
2014-07-11 14:45:06 UTC
Permalink
Our site standards are a one to one relationship between a triggered queue and a process definition, and we name them both exactly the same.

In some cases, we have to process definitions that are exactly the same, other than the name. Big whoop. It takes all of 3.62 seconds to create another copy of a process definition, and extra process definitions are not going use up resources on your queue manager or server.

If and when one of these queues needs different behavior for its triggering, we are set up to only have to alter that one specific process def for that one specific queue.

Peter Potkay

-----Original Message-----
From: MQSeries List [mailto:***@LISTSERV.MEDUNIWIEN.AC.AT] On Behalf Of Jantje .
Sent: Friday, July 11, 2014 10:03 AM
To: ***@LISTSERV.MEDUNIWIEN.AC.AT
Subject: Re: Different queue, same process and not triggering

On Fri, 11 Jul 2014 12:31:37 +0000, Tim Zielke <***@AON.COM> wrote:


> Are you sure the process did not run? Is it possible your program failed before it was able to write out to its application log?

I am pretty sure it did not run. The program is writing to its log file very early in its initialization; before it really has a chance to go wrong...


>On our Windows MQ servers, we have the Sysinternals Process Explorer and Process Monitor for debugging purposes.

I know and use this tool often. Problem is: if ProcExplorer does not show the program, is that because it did not run or is it because it did not run long enough to show? ProcMon would tell me, but I do not have that one on the machine where this is all happening. I'll see whether to go through the hassle to have it installed for me. But thanks for the very valid suggestion.


>On the Unix space, we definitely have situations with 100s of queues that share the same process definition, and we have not had issues with triggering as you are mentioning.

In CICS we have no issues either. We have an installation where thousands of queues share a single process definition and all is hunky-dory.


>Based on the behavior you described, it sounds almost like your program is acting differently based on the process name that is passed in the trigger message.

Well, I can assure you that the only information that is picked up from the trigger message is the name of the queue that triggered the process. Nothing else.

Cheers,

Jantje.

To unsubscribe, write to ***@LISTSERV.MEDUNIWIEN.AC.AT and, in the message body (not the subject), write: SIGNOFF MQSERIES Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com
Archive: http://listserv.meduniwien.ac.at/archives/mqser-l.html
************************************************************
This communication, including attachments, is for the exclusive use of addressee and may contain proprietary, confidential and/or privileged information. If you are not the intended recipient, any use, copying, disclosure, dissemination or distribution is strictly prohibited. If you are not the intended recipient, please notify the sender immediately by return e-mail, delete this communication and destroy all copies.
************************************************************


To unsubscribe, write to ***@LISTSERV.MEDUNIWIEN.AC.AT and,
in the message body (not the subject), write: SIGNOFF MQSERIES
Instructions for managing your mailing list subscription are provided in
the Listserv General Users Guide available at http://www.lsoft.com
Archive: ht
Jantje .
2014-07-11 14:06:40 UTC
Permalink
On Fri, 11 Jul 2014 08:08:17 -0500, Jefferson Lowrey <jlowrey-rIXRsD/***@public.gmane.org> wrote:

>Based on everything said so far, it seems clear that triggering itself is
>working correctly. The trigger message is created, the trigger monitor
>reads it and launches the right program.
>

I am still not convinced that it is. Yes, the trigger message is created, yes the trigger monitor reads it, but does it really launch my program? I am not convinced...


>It's just that the program being triggered is misbehaving.
>

It is not behaving at all... It is just not being invoked, so it seems.


>So as Tim says, time to find out why.

Yes, I probably will need to have ProcMon installed.

Cheers,

Jantje.

To unsubscribe, write to LISTSERV-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org and,
in the message body (not the subject), write: SIGNOFF MQSERIES
Bruce Lerner
2014-07-11 16:19:47 UTC
Permalink
As a test, I'd suggest trying separate initiation queues, and separate instances of runmqtrm - each one monitoring only one initiation queue.

To unsubscribe, write to LISTSERV-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org and,
in the message body (not the subject), write: SIGNOFF MQSERIES
Jantje .
2014-07-14 12:37:18 UTC
Permalink
Thanks again to all that contributed.

I have put in place the work-around that consists in having a separate process definition for every queue requiring triggering. Seems a bit silly, but it is simple enough to put in place and does not cost anything.

Cheers,

Jantje.

To unsubscribe, write to LISTSERV-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org and,
in the message body (not the subject), write: SIGNOFF MQSERIES
Tim Zielke
2014-07-14 13:10:57 UTC
Permalink
Hi Jantje,

Were you also going to debug why the previous set up was not working? My concern with just going with the separate process per queue approach (although it is a fine approach) is that it sounded like MQ triggering was working with the previous set up and you had some kind of odd bug going on with either your script or your code. Sometimes, those types of things come back to bite you later, if you don't get them figured out and corrected.

Thanks,
Tim

-----Original Message-----
From: MQSeries List [mailto:***@LISTSERV.MEDUNIWIEN.AC.AT] On Behalf Of Jantje .
Sent: Monday, July 14, 2014 7:37 AM
To: ***@LISTSERV.MEDUNIWIEN.AC.AT
Subject: Re: Different queue, same process and not triggering

Thanks again to all that contributed.

I have put in place the work-around that consists in having a separate process definition for every queue requiring triggering. Seems a bit silly, but it is simple enough to put in place and does not cost anything.

Cheers,

Jantje.

To unsubscribe, write to ***@LISTSERV.MEDUNIWIEN.AC.AT and, in the message body (not the subject), write: SIGNOFF MQSERIES Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com
Archive: http://listserv.meduniwien.ac.at/archives/mqser-l.html

To unsubscribe, write to ***@LISTSERV.MEDUNIWIEN.AC.AT and,
in the message body (not the subject), write: SIGNOFF MQSERIES
Instructions for managing your mailing list subscription are provided in
the Listserv General Users Guide available at http://www.lsoft.com
Archive: http://listserv.meduni
Glenn Baddeley
2014-07-15 00:01:13 UTC
Permalink
These may have been mentioned, but I think the most likely culprits are:
1) How the trigger monitor starts the triggered program (particularly APPLICID ENVRDATA USERDATA)
2) Whether the trigger monitor is being blocked until the triggered program completes
3) How the triggered program parses its command line (the MQTMC2 structure)
4) The processing logic in the triggered program
The output logs of runmqtrm may lag behind current processing, as stdout / stderr output is buffered before being written to the files.
There is no need for separate process objects for the same trigger processing to occur on multiple queues. Legions of users have been using one process object since the year dot.

To unsubscribe, write to LISTSERV-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org and,
in the message body (not the subject), write: SIGNOFF MQSERIES
Jantje .
2014-07-16 12:36:22 UTC
Permalink
Dear Listers,

A virtual beer to Tim Zielke (for having suggested to use strmqtrc and Process Monitor -- putting the output of these two next to each other was what finally made me realise what the error in my configuration was), and one to T.Rob (for having suggested the /B CMD /C options to the START command -- this way, the output of the QTRIG.CMD does actually end up in the trigger monitor log file instead of just disappearing into nature).

So, what was actually wrong?

Well, nothing with the triggering in se. Indeed, the trigger monitor did fire my QTRIG.CMD as it is expected to do, according to spec. It did so from day one. Only, within my QTRIG.CMD I had redirected the output of my application program to the same log file. This caused a sharing violation when the second process was triggered. And because in my first set-up, I did not see any output whatsoever from my QTRIG.CMD, I assumed (wrongly as it turns out) that the process had not been invoked. Actually, it had been invoked and failed opening the log file. And because the START without the /B CMD /C does not tell you anything, I never knew the invocation had failed. Then, when I introduced the second process definition, I also changed the name of the second log file (we have this naming conventions...) And as it suddenly started working, I assumed (again, wrongly) that it was the process definition that did it where in actual fact it was the fact that there was a separate log file.

WMQ 1 - Jantje nil

Thanks again for all that contributed.

Cheers,

Jantje.

To unsubscribe, write to LISTSERV-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org and,
in the message body (not the subject), write: SIGNOFF MQSERIES
Tim Zielke
2014-07-16 16:45:31 UTC
Permalink
Glad to help and hear that you issue got resolved.

A virtual beer is not quite as enjoyable as a real beer, but they sure are much easier on the waistline. :-)

Thanks,
Tim

-----Original Message-----
From: MQSeries List [mailto:***@LISTSERV.MEDUNIWIEN.AC.AT] On Behalf Of Jantje .
Sent: Wednesday, July 16, 2014 7:36 AM
To: ***@LISTSERV.MEDUNIWIEN.AC.AT
Subject: Re: Different queue, same process and not triggering

Dear Listers,

A virtual beer to Tim Zielke (for having suggested to use strmqtrc and Process Monitor -- putting the output of these two next to each other was what finally made me realise what the error in my configuration was), and one to T.Rob (for having suggested the /B CMD /C options to the START command -- this way, the output of the QTRIG.CMD does actually end up in the trigger monitor log file instead of just disappearing into nature).

So, what was actually wrong?

Well, nothing with the triggering in se. Indeed, the trigger monitor did fire my QTRIG.CMD as it is expected to do, according to spec. It did so from day one. Only, within my QTRIG.CMD I had redirected the output of my application program to the same log file. This caused a sharing violation when the second process was triggered. And because in my first set-up, I did not see any output whatsoever from my QTRIG.CMD, I assumed (wrongly as it turns out) that the process had not been invoked. Actually, it had been invoked and failed opening the log file. And because the START without the /B CMD /C does not tell you anything, I never knew the invocation had failed. Then, when I introduced the second process definition, I also changed the name of the second log file (we have this naming conventions...) And as it suddenly started working, I assumed (again, wrongly) that it was the process definition that did it where in actual fact it was the fact that there was a separate log file.

WMQ 1 - Jantje nil

Thanks again for all that contributed.

Cheers,

Jantje.

To unsubscribe, write to ***@LISTSERV.MEDUNIWIEN.AC.AT and, in the message body (not the subject), write: SIGNOFF MQSERIES Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com
Archive: http://listserv.meduniwien.ac.at/archives/mqser-l.html

To unsubscribe, write to ***@LISTSERV.MEDUNIWIEN.AC.AT and,
in the message body (not the subject), write: SIGNOFF MQSERIES
Instructions for managing your mailing list subscription are provided in
the Listserv General Users Guide available at http://www.lsoft.com
Archive: http://listserv.meduniwien.ac.at/archives/mqser-l.ht
Loading...