| Author |
Message
|
| ivanachukapawn |
 Posted: Thu Sep 07, 2006 8:32 am Post subject: DEFINE PROCESS - user data - parameter substitution |
 |
|
Knight
Joined: 27 Oct 2003
Posts: 561
|
I'm trying to setup triggering on a queue which will trigger amqsbcg to browse the queue when a specified depth is reached (the idea is to cause expired messages to be removed). I'm specifying /opt/mqm/samp/bin/amqsbcg as the APPLID but amqsbcg requires both QNAME and QMGRNAME parameters.
Question #1: Is user data the correct place to enter QNAME and QMGRNAME parameters for amqsbcg in the PROCESS DEFINITION?
Question #2: Is there a way to specify these parameters so that the QNAME and QMGRNAME values for the queue are substituted in USER DATA?
Question #3: Is an ampersand required in one of these PROCESS DEFINITION fields, and if so, which field? |
|
| Back to top |
|
 |
| jefflowrey |
| Posted: Thu Sep 07, 2006 8:42 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
A normal triggered program receives the contents of the process identifier as a command paramenter in the form of an MQTMC2 structure.
You can write shell/batch scripting to process this and turn it into the right parameters to pass to amqsbcg.
You can review the information center on triggering applications, and the FAQ here on triggering to understand where to put in what data.
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
| kevinf2349 |
| Posted: Thu Sep 07, 2006 8:44 am Post subject: |
|
|
Grand Master
Joined: 28 Feb 2003
Posts: 1311
Location: USA
|
| Quote: |
| (the idea is to cause expired messages to be removed). |
Wouldn't it be better to find out why they were expiring and fix that? The application that is servicing the queue will cause expired messages to be removed.
It is, of course, your call, but personally I would rather know I had a problem than deliberately mask it.  |
|
| Back to top |
|
|
| ivanachukapawn |
| Posted: Thu Sep 07, 2006 9:30 am Post subject: |
|
|
Knight
Joined: 27 Oct 2003
Posts: 561
|
Kevin52349
I'm not masking anything. The central application is an ESB and the messages in question are Receipts. Politically, there is no guarantee that ESB clients will dequeue the receipts. If the receipt queue fills up (because of there being no consumer) obviously problems will be caused with spillover to the SYSTEM.DEAD.LETTER.QUEUE. To cover these non-consumer cases, I plan to put receipt messages with an expiry set and then to trigger amqsbcg when a 50% depth is reached.
My problems are that the information center does not provide specific information on how the PROCESS env data and user data fields should be used and whether parameter substitution is supported and if so, how. Also, there is only a vague reference somewhere to the necessity for an ampersand to be placed somewhere.
I was hoping that somebody out there would have a specific example of how these PROCESS fields should be used. |
|
| Back to top |
|
|
| jefflowrey |
| Posted: Thu Sep 07, 2006 9:34 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
Maybe you should just publish the receipts.
If a consumer wants a receipt, they can subscribe for one.
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
| ivanachukapawn |
| Posted: Thu Sep 07, 2006 9:45 am Post subject: |
|
|
Knight
Joined: 27 Oct 2003
Posts: 561
|
MQ Pub/Sub is a mess, full support being available only through the JMS API. My app uses the Base MQ Java API (in order to access MQ features not directly available via JMS).
Although interesting, I am not now seeking architectural advice for this problem. Rather, I am looking for some lower level advice on how to use env data and user data PROCESS definition fields to achieve successful triggering of amqsbcg with parameter substitution. |
|
| Back to top |
|
|
| jefflowrey |
| Posted: Thu Sep 07, 2006 10:27 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
| jefflowrey wrote: |
| You can review the information center on triggering applications, and the FAQ here on triggering to understand where to put in what data. |
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
| kevinf2349 |
| Posted: Thu Sep 07, 2006 10:43 am Post subject: |
|
|
Grand Master
Joined: 28 Feb 2003
Posts: 1311
Location: USA
|
How are you proposing to set triggering back on after the first trigger?
Lower level and yet so important to get right  |
|
| Back to top |
|
|
| ivanachukapawn |
| Posted: Thu Sep 07, 2006 11:36 am Post subject: |
|
|
Knight
Joined: 27 Oct 2003
Posts: 561
|
Kevin,
Once I set trigger control to "on" with a type of DEPTH and a specified depth of 2500, I assume that when depth reaches 2500 amqsbcg will be triggered, will browse the queue, and expired messages will be removed. If the depth is lowered to a value less than 2500 and then more messages arrive on this queue, when the depth again reaches 2500 amqsbcg will again be triggered. Isn't this correct? |
|
| Back to top |
|
|
| jefflowrey |
| Posted: Thu Sep 07, 2006 11:42 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
|
| Back to top |
|
|
| ivanachukapawn |
| Posted: Thu Sep 07, 2006 11:43 am Post subject: |
|
|
Knight
Joined: 27 Oct 2003
Posts: 561
|
Jeff,
My info center is the one I installed on my harddrive when installing MQ 6.0 with MQ 6.0.1.0
I can search this info center for "triggering applications" but this yields only non-specific information about env data and user data and no examples. I don't see FAQ related to this subject.
Are you talking about a web based info center? If so, would you be so kind as to supply the URL you have to access it?
Thanks,
ivana |
|
| Back to top |
|
|
| jefflowrey |
| Posted: Thu Sep 07, 2006 11:46 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
|
| Back to top |
|
|
| kevinf2349 |
| Posted: Thu Sep 07, 2006 11:57 am Post subject: |
|
|
Grand Master
Joined: 28 Feb 2003
Posts: 1311
Location: USA
|
From the Application Programming Guide:
| Quote: |
DEPTH A trigger event occurs only when the number of messages on the application queue reaches the value of the TriggerDepth attribute. A typical use of this type of triggering is for starting a program when all the replies to a set of requests are received. Triggering by depth
With triggering by depth, the queue manager disables triggering (using the TriggerControl attribute) after it creates a trigger message. Your application must re-enable triggering itself (by using the MQSET call) after this has happened.
The action of disabling triggering is not under syncpoint control, so triggering cannot be re-enabled simply by backing out a unit of work. If a program backs out a put request that caused a trigger event, or if the program abends, you must re-enable triggering by using the MQSET call or the ALTER QLOCAL command.
|
|
|
| Back to top |
|
|
| ivanachukapawn |
| Posted: Thu Sep 07, 2006 12:05 pm Post subject: |
|
|
Knight
Joined: 27 Oct 2003
Posts: 561
|
Jeff,
Thanks for that information about MQ turning off Trigger Control when type is Depth and the trigger occurs. Obviously, I won't be able to get this scheme to work with Triggering by Depth.
However, after I finally figure out how to get amqsbcg triggered with two parameters (qname and qmgrname), this scheme should work with type=EVERY because the browse will be invoked each time a message is queued, and then expired messages will be deleted. Does this sound correct to you? |
|
| Back to top |
|
|
| jefflowrey |
| Posted: Thu Sep 07, 2006 12:09 pm Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
|
| Back to top |
|
|
|
|
