| Author |
Message
|
| PRKUMAR |
 Posted: Wed Sep 12, 2012 8:48 am Post subject: MQMD.ReplyToQ purpose in pcf message |
 |
|
Apprentice
Joined: 04 Sep 2012
Posts: 36
|
| What is the purpose of setting MQMD.ReplyToQ property in pcf message for queue inhibition? |
|
| Back to top |
|
 |
| Vitor |
| Posted: Wed Sep 12, 2012 9:04 am Post subject: Re: MQMD.ReplyToQ purpose in pcf message |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| PRKUMAR wrote: |
| What is the purpose of setting MQMD.ReplyToQ property in pcf message for queue inhibition? |
What is the purpose of this question?
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| PRKUMAR |
| Posted: Wed Sep 12, 2012 9:09 am Post subject: input queue inhibit |
|
|
Apprentice
Joined: 04 Sep 2012
Posts: 36
|
In my flow I want to inhibit the input queue at some point of time. I have seen the related threads in this forum. I want to inhibit the input queue using esql. Everywhere I have seen the following similar type of code:
SET OutputRoot.MQMD.MsgType = MQMT_REQUEST;
SET OutputRoot.MQMD.Format = MQFMT_ADMIN;
SET OutputRoot.MQMD.ReplyToQ = 'OUT';
SET OutputRoot.MQMD.MsgSeqNumber = 1;
SET OutputRoot.MQMD.Encoding = 546;
CREATE FIELD OutputRoot.MQPCF;
DECLARE refRequest REFERENCE TO OutputRoot.MQPCF;
SET refRequest.Type = 16;
--SET refRequest.StrucLength = MQCFH_STRUC_LENGTH;
SET refRequest.Version = 3;
SET refRequest.Command = MQCMD_CHANGE_Q;
SET refRequest.MsgSeqNumber = 1;
SET refRequest.Control = MQCFC_LAST;
/* First parameter: Queue Name. */
SET refRequest.Parameter[1] = MQCA_Q_NAME;
SET refRequest.Parameter[1].* = 'queue1';
/* Second parameter: Queue Type. */
SET refRequest.Parameter[2] = MQIA_Q_TYPE;
SET refRequest.Parameter[2].* = MQQT_LOCAL ;
/* Third parameter: Allow/Inhibit GET.*/
SET refRequest.Parameter[3] = MQIA_INHIBIT_GET;
SET refRequest.Parameter[3].* = MQQA_GET_INHIBITED;
SET OutputRoot.BLOB.BLOB = asbitstream(OutputRoot.MQPCF);
SET OutputRoot.MQPCF = null;
SET OutputRoot.MQMD.Format = MQFMT_ADMIN;
In the above example, the following property has been set:
SET OutputRoot.MQMD.ReplyToQ = 'OUT';
What is the purpose in setting the above property if we have sent the pcf message to SYSTEM.ADMIN.COMMAND.QUEUE? |
|
| Back to top |
|
|
| Vitor |
| Posted: Wed Sep 12, 2012 9:17 am Post subject: Re: input queue inhibit |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| PRKUMAR wrote: |
| In my flow I want to inhibit the input queue at some point of time. |
Why? It's not a good design to have administrative functions coded into an application.
| PRKUMAR wrote: |
| I have seen the related threads in this forum. I want to inhibit the input queue using esql. Everywhere I have seen the following similar type of code |
Which still doesn't make it a good thing to do, or a secure thing.
| PRKUMAR wrote: |
In the above example, the following property has been set:
SET OutputRoot.MQMD.ReplyToQ = 'OUT';
What is the purpose in setting the above property if we have sent the pcf message to SYSTEM.ADMIN.COMMAND.QUEUE? |
a) Make a wild guess what a reply attribute is for
b) How were you planning to determine if the inhibit command has worked in your design?
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| PRKUMAR |
| Posted: Wed Sep 12, 2012 9:27 am Post subject: queue inhibit |
|
|
Apprentice
Joined: 04 Sep 2012
Posts: 36
|
a) to receive messages in response to a message you send.
In what situations the queue(reply to q) will receive messages?
b)if it is worked, i want to stop processing of messages because of some error might happened in the flow. Once the error is rectified i will continue with the processing of messages. |
|
| Back to top |
|
|
| PRKUMAR |
| Posted: Wed Sep 12, 2012 9:39 am Post subject: got the answer |
|
|
Apprentice
Joined: 04 Sep 2012
Posts: 36
|
a) got the answer for my question.
In response to each command, the command server generates one or more response messages(OK,ERROR OR DATA). A response message has similar format to a command message. |
|
| Back to top |
|
|
| Vitor |
| Posted: Wed Sep 12, 2012 9:42 am Post subject: Re: queue inhibit |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| PRKUMAR wrote: |
| a) to receive messages in response to a message you send. |
Exactly.
| PRKUMAR wrote: |
| In what situations the queue(reply to q) will receive messages? |
Are you utterly incapable of deductive reasoning? 
I ask again - how will you know if your request has worked? Perhaps something might want to tell you.....?
| PRKUMAR wrote: |
| i want to stop processing of messages because of some error might happened in the flow. Once the error is rectified i will continue with the processing of messages. |
Why? If the input queue contains 10,000 messages and the 4th one down has some bad data in it do you really want to stop the processing of 9,996 perfectly good messages until you've worked out what's wrong?
The only possible reason you'd want to do that is because you have to process all 10,000 messages in sequence & you can't process the 5th message until the 4th one has worked. This is known as "message affinity" and is an even worse design that firing PCF messages from inside a flow when you can't figure out what the reply is for.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| Vitor |
| Posted: Wed Sep 12, 2012 9:42 am Post subject: Re: got the answer |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| PRKUMAR wrote: |
a) got the answer for my question.
In response to each command, the command server generates one or more response messages(OK,ERROR OR DATA). A response message has similar format to a command message. |
Dear God he's found the InfoCenter.....
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| PRKUMAR |
| Posted: Wed Sep 12, 2012 9:57 am Post subject: |
|
|
Apprentice
Joined: 04 Sep 2012
Posts: 36
|
The only possible reason you'd want to do that is because you have to process all 10,000 messages in sequence & you can't process the 5th message until the 4th one has worked.
Yes, you are right!!
Following are my questions:
1. What suggestion you can make if a source system(not supported now) sending messages in such a way that it should be updated in sequence in a target database?
2. We are doing the integration part only, we can't make rule how communicating systems would work. Even if we suggest, they are in a position to consider it. In such situations, how do one handle the message affinity problem? |
|
| Back to top |
|
|
| Vitor |
| Posted: Wed Sep 12, 2012 10:02 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| PRKUMAR wrote: |
| Yes, you are right!! |
Impressed?
| PRKUMAR wrote: |
| 1. What suggestion you can make if a source system(not supported now) sending messages in such a way that it should be updated in sequence in a target database? |
Replace the source system. If it's unsupported there's a massive business risk if it fails for any reason.
| PRKUMAR wrote: |
| 2. We are doing the integration part only, we can't make rule how communicating systems would work. |
But you can suggest & point out where they have problems.
| PRKUMAR wrote: |
| how do one handle the message affinity problem? |
One designs the integration to eliminate it; it's unlikely the affinity really runs the length of the file. You could also review the many posts in here in the subject of affinity.
At a minimum, you need to point to your clients how bad things are in their design.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
|
|
