| |
|
RSS Feed - WebSphere MQ Support
|
RSS Feed - Message Broker Support
|
| Finalize clause in PROPAGATE Statement |
« View previous topic :: View next topic » |
| Author |
Message
|
| stoney |
 Posted: Wed Jun 01, 2016 3:58 am Post subject: |
 |
|
Centurion
Joined: 03 Apr 2013
Posts: 140
|
| dip wrote: |
| Now according to knwldge cntre, finalize should make the msg constant. So, after the first propagate statement, so how is it modifying the same message and even the header got changed??? |
Here's the information from the Knowledge Center:
| Quote: |
The Compute node allows its output message to be changed by other nodes (by the other nodes changing their input message).
However, a message created by a Compute node cannot be changed by another node after:
It has been finalized
It has reached any output or other node which generates a bit-stream |
The key bit is "by another node".
It does not say anything about making the message read-only in the current Compute node.
If it made OutputRoot read-only in the current Compute node, how would you be able to build new messages for subsequent PROPAGATEs? |
|
| Back to top |
|
 |
| maurito |
| Posted: Wed Jun 01, 2016 7:34 am Post subject: |
|
|
Partisan
Joined: 17 Apr 2014
Posts: 358
|
| stoney wrote: |
| dip wrote: |
| Now according to knwldge cntre, finalize should make the msg constant. So, after the first propagate statement, so how is it modifying the same message and even the header got changed??? |
Here's the information from the Knowledge Center:
| Quote: |
The Compute node allows its output message to be changed by other nodes (by the other nodes changing their input message).
However, a message created by a Compute node cannot be changed by another node after:
It has been finalized
It has reached any output or other node which generates a bit-stream |
The key bit is "by another node".
It does not say anything about making the message read-only in the current Compute node.
If it made OutputRoot read-only in the current Compute node, how would you be able to build new messages for subsequent PROPAGATEs? |
Well, sorry Simon, but the info center is incorrect, as shown in the trace I posted earlier.
or rather, partially incorrect.
if I remember well, you are allowed to modify the input tree in the next node, which can be useful, but not sure what happens if the "modified" input tree is written to a queue or file, probably during serializing it realises it is a finalized tree and writes the unmodified copy of it. |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Wed Jun 01, 2016 8:02 am Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
@dip
There seems to be a little confusion here. The FINALIZE DEFAULT is supposed to make the input tree imutable in the next downstream node(s).
There is no statement about the output tree and evidently that can be changed...
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| rekarm01 |
| Posted: Wed Jun 01, 2016 5:21 pm Post subject: Re: Finalize clause in PROPAGATE Statement |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 1415
|
| maurito wrote: |
| Here is proof of what I am saying: ... |
Until the documentation says otherwise, this only proves that some changes to finalized messages don't cause an immediate and apparent error. |
|
| Back to top |
|
|
| dip |
| Posted: Wed Jun 01, 2016 11:35 pm Post subject: |
|
|
Novice
Joined: 27 May 2016
Posts: 13
|
ok in that case , here is what i did :
mqip -> cn -> mqheader -> mqop
Case1:
in cn:
SET OutputRoot.XMLNSC.message.msg1 = 'number one';
PROPAGATE TO TERMINAL 'out' FINALIZE DEFAULT DELETE NONE ;
now before entering mqheader node , mqmd version was 2 , I changed it to 1 in mqmd header node and it got changed .
Q.So this time there was no new outputroot created . It is the same message and as specified, different node, then how is it getting changed???
Next , priority was 0 but I changed it to 2 in the MQheader node . Not only it got changed but got copied to property folder.
Q. Again how this is happening , as it is clearly written "Finalization is a process that fixes header chains and makes the Properties folder match the headers. If present, the FINALIZE clause allows finalization to be controlled." ????
Note: I made the finalize clause "Finalize none" and tried all of the above , exact same things happened. |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Thu Jun 02, 2016 4:23 am Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
That goes against the internals of the header node. Who's to say that you don't have the equivalent of a copyEntireMessage + changes to the Header here? Only the guys in Hursley could tell... 
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| dip |
| Posted: Sun Jun 05, 2016 11:04 pm Post subject: |
|
|
Novice
Joined: 27 May 2016
Posts: 13
|
okay , finally am able to find out the difference with a little help from my senior. Here is the flow :
jmsip -> compute -> mqop
in compute:
CALL CopyMessageHeaders();
CREATE NEXTSIBLING OF OutputRoot.Properties DOMAIN('MQRFH2') NAME 'MQRFH2';
CREATE NEXTSIBLING OF OutputRoot.MQRFH2 DOMAIN('MQMD') NAME 'MQMD';
SET OutputRoot.XMLNSC.message.msg1 = 'number one';
case1:
PROPAGATE TO TERMINAL 'out' FINALIZE NONE DELETE NONE ;
In this case both MQRFH2 & MQMD Headers were created but they no fields under them were created.
case 2:
PROPAGATE TO TERMINAL 'out' FINALIZE DEFAULT DELETE NONE ;
Here again both headers are created , but this time the fields in the headers were also created automatically , and fields under MQMD were given default values, like CCSID 1208.
CONCLUSION:
Finalize none gives you the flexibility to create the header as you want , no mandatory strict norms to be maintained . But for Finalize default or in case of no finalize clause , some mandatory norms are followed automatically for the headers.
Also , note that the finalize clause is not resposible for the order of the headers.
yayyyyyyy done ......  |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Mon Jun 06, 2016 4:16 am Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
| dip wrote: |
in compute:
| Code: |
CALL CopyMessageHeaders();
CREATE NEXTSIBLING OF OutputRoot.Properties DOMAIN('MQRFH2') NAME 'MQRFH2';
CREATE NEXTSIBLING OF OutputRoot.MQRFH2 DOMAIN('MQMD') NAME 'MQMD';
SET OutputRoot.XMLNSC.message.msg1 = 'number one'; |
CONCLUSION:
Also , note that the finalize clause is not responsible for the order of the headers.
yayyyyyyy done ...... |
Hope this is not the code you wrote. Because the header chaining is wrong.
The MQMD should come BEFORE the RFH2 header and not after it...
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| dip |
| Posted: Mon Jun 06, 2016 9:30 pm Post subject: |
|
|
Novice
Joined: 27 May 2016
Posts: 13
|
@fjb_saper :
yeah , that is the code I wrote and I know the order (and of course MQOP node threw exception) , that is why , in my conclusion , I wrote 'Also , note that the finalize clause is not resposible for the order of the headers.' , which means , finalize clause in both cases , default and none , allowed the wrong header chaining .......  |
|
| Back to top |
|
|
|
|
|
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
|
|
|
