Author |
Message
|
ydsk |
Posted: Wed Mar 08, 2006 3:58 pm Post subject: Out1, Out2 terminals on a Compute node |
|
|
Chevalier
Joined: 23 May 2005 Posts: 410
|
Hi,
Has anybody used the Out1, Out2, ..., Out4 terminals ( any of the terminals other than the regular 'out' terminal)on a Compute node in WMB v6 ?
I am trying to use a simple ESQL statement like the one below
PROPAGATE TO TERMINAL 'out1';
But it isn't working. I tried different values like 1, 'Out1', 'out 1', etc, in place of 'out1' but nothing worked.
I know how the PROPAGATE statement works because I used it several times in v5 and v6. My problem is with the terminals other than the regular out terminal.
Can somebody please help.
Thank you in advance.
ydsk. |
|
Back to top |
|
 |
wschutz |
Posted: Wed Mar 08, 2006 5:31 pm Post subject: |
|
|
 Jedi Knight
Joined: 02 Jun 2005 Posts: 3316 Location: IBM (retired)
|
Interesting... I can't get 'out 1' to work either (which is how I read the propagate doc)...but this works:
Code: |
declare i integer;
set i=1;
propagate to terminal i;
return false; |
_________________ -wayne |
|
Back to top |
|
 |
wschutz |
Posted: Wed Mar 08, 2006 5:47 pm Post subject: |
|
|
 Jedi Knight
Joined: 02 Jun 2005 Posts: 3316 Location: IBM (retired)
|
got it:
Code: |
PROPAGATE TO TERMINAL 'out1'; |
looks like we have some doc errors.... I've submitted feedback to our documentation people....
Edit: I see you tried that and it didn't work.... I assume an exception was thrown? _________________ -wayne |
|
Back to top |
|
 |
sarat |
Posted: Mon Mar 27, 2006 1:14 pm Post subject: |
|
|
 Centurion
Joined: 29 Jun 2005 Posts: 136 Location: India
|
Hi ydsk and wschutz,
This is a small clarification regarding 'Propagate' Statement. We can send as many terminals in Compute node using 'Propagate'. But for every propagate the OutputRoot will be null. So we've to reconstruct the message and headers. Then there won't be any errors. _________________ With Regards,
Sarat. |
|
Back to top |
|
 |
mgk |
Posted: Mon Mar 27, 2006 1:42 pm Post subject: |
|
|
 Padawan
Joined: 31 Jul 2003 Posts: 1642
|
Hi,
Quote: |
But for every propagate the OutputRoot will be null. So we've to reconstruct the message and headers. Then there won't be any errors. |
In V6 this behaviour depends on the DELETE clause of the PROPAGATE statement, which can be used to stop the Output* trees being cleared after propagation.
Regards, _________________ MGK
The postings I make on this site are my own and don't necessarily represent IBM's positions, strategies or opinions. |
|
Back to top |
|
 |
sarat |
Posted: Mon Mar 27, 2006 1:52 pm Post subject: |
|
|
 Centurion
Joined: 29 Jun 2005 Posts: 136 Location: India
|
Hi,
mgk wrote:
Quote: |
In V6 this behaviour depends on the DELETE clause of the PROPAGATE statement, which can be used to stop the Output* trees being cleared after propagation. |
So u mean to say that using the below we can do that
Code: |
PROPAGATE DELETE NONE; |
_________________ With Regards,
Sarat. |
|
Back to top |
|
 |
ydsk |
Posted: Mon Mar 27, 2006 1:57 pm Post subject: |
|
|
Chevalier
Joined: 23 May 2005 Posts: 410
|
Yes, what mgk said is true and it works. The DELETE clause does the trick of not having to re-copy the whole message to OutputRoot with every PROPAGATE in v6.
The whole issue was with the documentation.
Thank you all guys.
ydsk. |
|
Back to top |
|
 |
raja_no_1 |
Posted: Tue May 09, 2006 9:46 pm Post subject: |
|
|
 Apprentice
Joined: 05 Sep 2005 Posts: 34
|
I am facing a similar problem.
Its a simple test flow I have created. Here is my ESQL code:
==================================
CREATE COMPUTE MODULE Test1_Compute
CREATE FUNCTION Main() RETURNS BOOLEAN
BEGIN
CALL CopyMessageHeaders();
CALL CopyEntireMessage();
RETURN TRUE;
END;
CREATE PROCEDURE CopyMessageHeaders() BEGIN
DECLARE I INTEGER;
DECLARE J INTEGER;
SET I = 1;
SET J = CARDINALITY(InputRoot.*[]);
WHILE I < J DO
SET OutputRoot.*[I] = InputRoot.*[I];
SET I = I + 1;
END WHILE;
END;
CREATE PROCEDURE CopyEntireMessage() BEGIN
SET OutputRoot = InputRoot;
END;
CREATE PROCEDURE MainProcess() BEGIN
PROPAGATE TO TERMINAL 'Out' DELETE NONE;
PROPAGATE TO TERMINAL 'Out1';
END;
END MODULE;
===================
The "out" terminal is connected to MQoutput (where I get the message)
The "Out1"terminal is connected to MQoutput(where I dont get the message.
Can anyone please help.
Thanks |
|
Back to top |
|
 |
wschutz |
Posted: Wed May 10, 2006 2:39 am Post subject: |
|
|
 Jedi Knight
Joined: 02 Jun 2005 Posts: 3316 Location: IBM (retired)
|
wschutz wrote: |
got it:
Code: |
PROPAGATE TO TERMINAL 'out1'; |
looks like we have some doc errors.... I've submitted feedback to our documentation people....
Edit: I see you tried that and it didn't work.... I assume an exception was thrown? |
_________________ -wayne |
|
Back to top |
|
 |
Ian |
Posted: Wed May 10, 2006 7:52 am Post subject: |
|
|
Disciple
Joined: 22 Nov 2002 Posts: 152 Location: London, UK
|
The terminal names are case sensitive. Valid terminal names in this context are 'out', 'out1', 'out2', 'out3' and 'out4'.
Other terminal names such as 'Out1', 'OUT1' and 'out 1' are therefore invalid.
I believe that topic "ak05110_" has been (or will be) updated to more accurately reflect this. _________________ Regards, Ian |
|
Back to top |
|
 |
raja_no_1 |
Posted: Sat May 13, 2006 12:09 am Post subject: |
|
|
 Apprentice
Joined: 05 Sep 2005 Posts: 34
|
I have modified my code as below:
============
CREATE COMPUTE MODULE Test1_Compute
CREATE FUNCTION Main() RETURNS BOOLEAN
BEGIN
CALL CopyMessageHeaders();
CALL CopyEntireMessage();
CALL MainProcess();
RETURN TRUE;
END;
CREATE PROCEDURE CopyMessageHeaders() BEGIN
DECLARE I INTEGER;
DECLARE J INTEGER;
SET I = 1;
SET J = CARDINALITY(InputRoot.*[]);
WHILE I < J DO
SET OutputRoot.*[I] = InputRoot.*[I];
SET I = I + 1;
END WHILE;
END;
CREATE PROCEDURE CopyEntireMessage() BEGIN
SET OutputRoot = InputRoot;
END;
CREATE PROCEDURE MainProcess() BEGIN
PROPAGATE TO TERMINAL 'out' DELETE NONE;
PROPAGATE TO TERMINAL 'out1';
END;
END MODULE;
==================
But still doesnt work.
Here is the trace file:
2006-05-13 09:05:08.589653 460 UserTrace BIP2537I: Node 'Test1.Compute': Executing statement ''RETURN TRUE;'' at ('.Test1_Compute.Main', '7.1').
2006-05-13 09:05:08.589735 460 UserTrace BIP4007I: Message propagated to 'out' terminal of node 'Test1.Compute'.
2006-05-13 09:05:08.590559 460 Error BIP2628E: Exception condition detected on input node 'Test1.MQInput'.
The input node 'Test1.MQInput' detected an error whilst processing a message. The message flow has been rolled-back and, if the message was being processed in a unit of work, it will remain on the input queue to be processed again. Following messages will indicate the cause of this exception.
Check the error messages which follow to determine why the exception was generated, and take action as described by those messages.
2006-05-13 09:05:08.590594 460 RecoverableException BIP2230E: Error detected whilst processing a message in node 'Test1.MQOutput1'.
The message broker detected an error whilst processing a message in node 'Test1.MQOutput1'. An exception has been thrown to cut short the processing of the message.
See the following messages for details of the error.
2006-05-13 09:05:08.590615 460 MessageException BIP2660E: The message received at output node 'Test1.MQOutput1' is empty. State = '-1' ''MQW001'' '0' ''''
The WebSphere Message Brokers output node 'Test1.MQOutput1' has received a message for writing to a queue, but the message's bit stream is too short to be a valid message. This situation can occur when a message is built incorrectly by a Compute node (e.g. there is no MQMD).
Check the message flow to determine whether the message is being built correctly, correct the problem and redeploy.
2006-05-13 09:05:09.591229 460 UserTrace BIP2631I: Backed out message being propagated to failure terminal; node 'Test1.MQInput'.
Node 'Test1.MQInput' has received a message which has previously been backed out because of a processing error in the message flow. The MQMD 'backoutCount' of the message exceeds (or equals) the 'backoutThreshold' defined for the WebSphere MQ input queue. The message broker is propagating the message to the failure terminal of the node.
Examine the other messages and the message flow to determine why the message is being backed out. Correct this situation if possible. Perform any local error recovery processing required. |
|
Back to top |
|
 |
wschutz |
Posted: Sat May 13, 2006 3:53 am Post subject: |
|
|
 Jedi Knight
Joined: 02 Jun 2005 Posts: 3316 Location: IBM (retired)
|
|
Back to top |
|
 |
raja_no_1 |
Posted: Sat May 13, 2006 11:06 am Post subject: |
|
|
 Apprentice
Joined: 05 Sep 2005 Posts: 34
|
Thanks Wayne!!
With return false it works. This is something which I forgot to change after making the change to lower case of the "out" terminals. |
|
Back to top |
|
 |
Prashanth007 |
Posted: Sun Oct 18, 2015 8:57 pm Post subject: |
|
|
Newbie
Joined: 13 Oct 2015 Posts: 6
|
hi all,
In main() function we use return false for discard or stop the message.
But in procedure what we have to do? |
|
Back to top |
|
 |
smdavies99 |
Posted: Sun Oct 18, 2015 9:39 pm Post subject: |
|
|
 Jedi Council
Joined: 10 Feb 2003 Posts: 6076 Location: Somewhere over the Rainbow this side of Never-never land.
|
Please don't re-open a nine year olf thread to ask the same squestion that you are already doing in another thread. It won't get you an answer any quicker. _________________ WMQ User since 1999
MQSI/WBI/WMB/'Thingy' User since 2002
Linux user since 1995
Every time you reinvent the wheel the more square it gets (anon). If in doubt think and investigate before you ask silly questions. |
|
Back to top |
|
 |
|