Jantje .
2014-07-10 15:58:30 UTC
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
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