| Author |
Message
|
| w |
 Posted: Fri Nov 18, 2011 9:55 am Post subject: |
 |
|
Apprentice
Joined: 08 Nov 2010
Posts: 44
|
| Vitor wrote: |
| fjb_saper wrote: |
Statistics gathering is done in a complete different way and is a publication done by the broker to a $SYS/.... topic.  |
Writing code to capture this information is reinventing the wheel.
| fjb_saper wrote: |
| Logging can be done at the input/ output node level. |
See above
| fjb_saper wrote: |
Check out the manuals in the infocenter and GET Training. 
WMB is not a product you can just pickup as if it were another flavor of Java. |
 |
@Vitor
What ever You are saying I already Know.
But do you know that
If there are two conseceutive propagaete staement lets say
Propagate to Terminal out;
Propagate to terminal 'Out1';
Then after the first statement the control goes to terminal out and the part of the flow connected to out is execeuted. After that finishes control comes back to the next statement i.e. Propagate to terminal 'Out1';
Now this entire thing is being managed internally by threads.
FYI I am a IBM Certified WMB developer |
|
| Back to top |
|
 |
| w |
| Posted: Fri Nov 18, 2011 10:00 am Post subject: |
|
|
Apprentice
Joined: 08 Nov 2010
Posts: 44
|
| Vitor wrote: |
| w wrote: |
| Ok .Here is the requirement see if u can do this without the subflow. |
I'm looking at an implementation of both of your requirements that doesn't use subflows.
| w wrote: |
| Now if you try and achieve the above requirements without a subflow .You will end up cluttering the flow with a lot of file nodes |
No you won't.
| w wrote: |
| Make sure u know the entire situation before dismissing others as Novice. |
I never said "novice". I said you didn't understand how the propagate statement or subflows work. The answer to a lack of understanding is training.
| w wrote: |
| Arrogance is not a virtue. |
No, it's a hobby. |
Really an implementation of everything without subflow and no cluttering .Why don't u post the basic flow diagram? |
|
| Back to top |
|
|
| lancelotlinc |
| Posted: Fri Nov 18, 2011 10:00 am Post subject: |
|
|
Jedi Knight
Joined: 22 Mar 2010
Posts: 4941
Location: Bloomington, IL USA
|
Sorry gang, can't help but to jump in here.
There is one path of execution, one thread per invocation. Propagate to out blocks that single thread until it fully completes. Then Propagate out1 is called, which blocks until it completes.
There is no multi-threading in the functionality you described.
If you are an IBM Certified WMB developer, who certified you?
_________________
http://leanpub.com/IIB_Tips_and_Tricks
Save $20: Coupon Code: MQSERIES_READER |
|
| Back to top |
|
|
| w |
| Posted: Fri Nov 18, 2011 10:07 am Post subject: |
|
|
Apprentice
Joined: 08 Nov 2010
Posts: 44
|
| lancelotlinc wrote: |
Sorry gang, can't help but to jump in here.
There is one path of execution, one thread per invocation. Propagate to out blocks that single thread until it fully completes. Then Propagate out1 is called, which blocks until it completes.
There is no multi-threading in the functionality you described.
If you are an IBM Certified WMB developer, who certified you? |
When one thread is blocked is not a new thread started .Did I ever say That threads were running in parallel.
The one who certified u .Assuming you are certified. |
|
| Back to top |
|
|
| lancelotlinc |
| Posted: Fri Nov 18, 2011 10:10 am Post subject: |
|
|
Jedi Knight
Joined: 22 Mar 2010
Posts: 4941
Location: Bloomington, IL USA
|
What procedure did you follow to become certified?
There are not two threads running. There is only one thread. If you were IBM certified on WMB, you would know this.
_________________
http://leanpub.com/IIB_Tips_and_Tricks
Save $20: Coupon Code: MQSERIES_READER |
|
| Back to top |
|
|
| Vitor |
| Posted: Fri Nov 18, 2011 10:13 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| w wrote: |
| Now this entire thing is being managed internally by threads. |
Please post a link to a piece of IBM documentation describing this behaviour. I'm always happy to learn something new.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| w |
| Posted: Fri Nov 18, 2011 10:15 am Post subject: |
|
|
Apprentice
Joined: 08 Nov 2010
Posts: 44
|
| lancelotlinc wrote: |
What procedure did you follow to become certified?
There are not two threads running. There is only one thread. If you were IBM certified on WMB, you would know this. |
OK . Help me understand this.
You say the propagate statement blocks the execution of the thread until it is complete.If the thread is blocked then what is running to complete the propagate statement. |
|
| Back to top |
|
|
| mqjeff |
| Posted: Fri Nov 18, 2011 10:23 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
| w wrote: |
| lancelotlinc wrote: |
What procedure did you follow to become certified?
There are not two threads running. There is only one thread. If you were IBM certified on WMB, you would know this. |
OK . Help me understand this.
You say the propagate statement blocks the execution of the thread until it is complete.If the thread is blocked then what is running to complete the propagate statement. |
It's very very simple.
Each message on each Input node starts a thread.
All nodes downstream of that Input node are invoked by nested calls.
When you invoke PROPAGATE, you are making a NESTED call to the node downstream on that terminal.
That PROPAGATE call does not return control back to the next ESLQ statement until the downstream node has completed- and the downstream node does not complete until the nodes downstream of it have completed.
Once the PROPAGATE completes, all of those downstream nested calls have completed.
It's like this
A(B(C(D E1(F(G(H))) E2(F(G(H)))))).
I suppose it's true that there wasn't a question on this in the most recent certification exams. |
|
| Back to top |
|
|
| w |
| Posted: Fri Nov 18, 2011 10:33 am Post subject: |
|
|
Apprentice
Joined: 08 Nov 2010
Posts: 44
|
| mqjeff wrote: |
| w wrote: |
| lancelotlinc wrote: |
What procedure did you follow to become certified?
There are not two threads running. There is only one thread. If you were IBM certified on WMB, you would know this. |
OK . Help me understand this.
You say the propagate statement blocks the execution of the thread until it is complete.If the thread is blocked then what is running to complete the propagate statement. |
It's very very simple.
Each message on each Input node starts a thread.
All nodes downstream of that Input node are invoked by nested calls.
When you invoke PROPAGATE, you are making a NESTED call to the node downstream on that terminal.
That PROPAGATE call does not return control back to the next ESLQ statement until the downstream node has completed- and the downstream node does not complete until the nodes downstream of it have completed.
Once the PROPAGATE completes, all of those downstream nested calls have completed.
It's like this
A(B(C(D E1(F(G(H))) E2(F(G(H)))))).
I suppose it's true that there wasn't a question on this in the most recent certification exams. |
ok agreed.
Now answer this where and how is the previous state-the state at the point of execeution of the propagate statement- of the thread saved. |
|
| Back to top |
|
|
| Vitor |
| Posted: Fri Nov 18, 2011 10:47 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| w wrote: |
| Now answer this where and how is the previous state-the state at the point of execeution of the propagate statement- of the thread saved. |
In memory? Along with the message tree being propagated, the Environment artifacts and a ton of other stuff?
Unless it's on disc, in a queue or (if you're using v6.1) in a database?
How does "where is the copy of the tree stored" relate to "how many threads are processing this tree?"
Here's a plan - deploy your flow with this subflow in place. Run messages through it. See how many threads start and stop to process them. This will prove it one way or another, and potentially give you bragging rights in here when you prove multiple threads are starting for a single input message....
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| lancelotlinc |
| Posted: Fri Nov 18, 2011 10:48 am Post subject: |
|
|
Jedi Knight
Joined: 22 Mar 2010
Posts: 4941
Location: Bloomington, IL USA
|
|
| Back to top |
|
|
| w |
| Posted: Fri Nov 18, 2011 10:57 am Post subject: |
|
|
Apprentice
Joined: 08 Nov 2010
Posts: 44
|
| Vitor wrote: |
| w wrote: |
| Now answer this where and how is the previous state-the state at the point of execeution of the propagate statement- of the thread saved. |
In memory? Along with the message tree being propagated, the Environment artifacts and a ton of other stuff?
Unless it's on disc, in a queue or (if you're using v6.1) in a database?
How does "where is the copy of the tree stored" relate to "how many threads are processing this tree?"
Here's a plan - deploy your flow with this subflow in place. Run messages through it. See how many threads start and stop to process them. This will prove it one way or another, and potentially give you bragging rights in here when you prove multiple threads are starting for a single input message.... |
I am only trying to understand the process .
See I am not trying to prove myself and disprove any of you only trying to understand the situation.
And the IBM certified Developer info I gave was because you people were shouting that I get a training.It was only to say that I am already trained. I was not bragging.
Now on the thread thing I will try and find more info and post.
But as u say it is saving something somewhere now u see this is why I asked my original question of propagation effecting efficiency which you people dismissed outright. |
|
| Back to top |
|
|
| w |
| Posted: Fri Nov 18, 2011 11:01 am Post subject: |
|
|
Apprentice
Joined: 08 Nov 2010
Posts: 44
|
| lancelotlinc wrote: |
| There is no reason to save state, since the current thread is not interrupted. |
Well! without saving anything how do you know where to come back and how is the state of the InputRoot and the output root tree regained |
|
| Back to top |
|
|
| Vitor |
| Posted: Fri Nov 18, 2011 11:05 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| w wrote: |
| But as u say it is saving something somewhere now u see this is why I asked my original question of propagation effecting efficiency which you people dismissed outright. |
The whole flow is saving something somewhere. Your point is tauological and meaningless.
Also your question was:
| w wrote: |
| I want to know whether making such a detour using propagate statement is highly inefficient or not compared to when the subflow logic is implemented in the same flow itself |
which we dismissed outright because:
a) there's no detour
b) the subflow logic is always implemented in the main flow even if coded separately
c) this is fairly basic broker knowledge
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| lancelotlinc |
| Posted: Fri Nov 18, 2011 12:26 pm Post subject: |
|
|
Jedi Knight
Joined: 22 Mar 2010
Posts: 4941
Location: Bloomington, IL USA
|
| w wrote: |
| lancelotlinc wrote: |
| There is no reason to save state, since the current thread is not interrupted. |
Well! without saving anything how do you know where to come back and how is the state of the InputRoot and the output root tree regained |
If you were writing a BASIC program, this is the same as "GO SUB".
_________________
http://leanpub.com/IIB_Tips_and_Tricks
Save $20: Coupon Code: MQSERIES_READER |
|
| Back to top |
|
|
|
|
