| |
|
RSS Feed - WebSphere MQ Support
|
RSS Feed - Message Broker Support
|
| DECLARE ROW at schema scope ? |
« View previous topic :: View next topic » |
| Author |
Message
|
| fjb_saper |
 Posted: Fri Jul 05, 2013 7:09 am Post subject: |
 |
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
Could it be that the node scope would also be fixed in that IFIX of the toolkit?
i.e. the node scope behavior is a symptom of the problem occurring during the toolkit compile... 
_________________
MQ & Broker admin |
|
| Back to top |
|
 |
| rekarm01 |
| Posted: Sat Jul 06, 2013 1:42 pm Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 1415
|
| goffinf wrote: |
IBMs response thus far :-
| Quote: |
| The issue for normal schema level variable being stripped off in CMF file when creating a BAR file using the "Compile and in-line resource" option is a defect in Toolkit, and will be fixed in APAR IC93278, which will be available in WebSphere Message Broker Toolkit V8.0.0.2 IFix001, and will be released soon in this month. |
|
Isn't this also a defect for the WMBv7 and WMBv6.1 toolkits, (not to mention WMBv6.0)? The documentation seems to suggest that broker support for schema level variables was originally limited to just external, shared, or constant variables, and then later extended to include variables that are not shared, external, or constant, but it's not clear when that change was supposed to have occurred.
| goffinf wrote: |
| Quote: |
| In particular, it has been discovered that 'Normal' variable scope is NODE. ... A similar [potential] inconsistency exists for schema level (non-SHARED) CONSTANTS. Whilst they are immutable with a scope, that scope is NODE. As an example, if the value of a schema level CONSTANT is set as CURRENT_TIMESTAMP, a DIFFERENT value may be seen in different NODEs. Again it is not clear whether this is a defect or expected behaviour, and the InfoCentre is equally unclear. |
|
Although the InfoCenter could be clearer about this, it does document the node scope, here, and here, so this is probably working as-designed. Even for SHARED schema variables, the declaration itself still only has node scope, (in that each node requires a declaration), even though the underlying variable is allocated only once during the lifetime of the flow. (This is similar to how C extern declarations work.)
For immutable ("const-type") variables in many languages, different instances need not have the same value. To illustrate this, try initializing a routine-local variable with a random value, (e.g. "DECLARE f CONSTANT FLOAT RAND();") in ESQL or other languages, and calling the routine multiple times. For languages that dynamically allocate local variables, each instance of the variable can have a different value.
Changing the existing scope of schema level variables from node to flow may involve a lot of work, for reasons that mqjeff alluded to earlier ("Broker nodes are static and reentrant, that is that there is always only a single copy of the run or execute method of a node"). One alternative that may involve less work is to extend the scope of the Environment tree to the schema level, but that would probably require an RFE, not a PMR.
[Edit: changed "Normal variables" to "variables that are not shared, external, or constant"]
Last edited by rekarm01 on Sun Jul 07, 2013 3:12 pm; edited 1 time in total |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Sat Jul 06, 2013 9:36 pm Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
| rekarm01 wrote: |
Isn't this also a defect for the WMBv7 and WMBv6.1 toolkits, (not to mention WMBv6.0)? The documentation seems to suggest that broker support for schema level variables was originally limited to just EXTERNAL, SHARED, or CONSTANT variables, and then later extended to include Normal variables, but it's not clear when that change was supposed to have occurred.
|
Not quite. I remember having used namespaces at a schema level and the scope of those was the schema level (V6.0 and 7.0.0.3). So I would have expected that the scope of other type of variables would have been the schema level as well.
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| rekarm01 |
| Posted: Sat Jul 06, 2013 11:01 pm Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 1415
|
| fjb_saper wrote: |
| rekarm01 wrote: |
| Isn't this also a defect for the WMBv7 and WMBv6.1 toolkits, (not to mention WMBv6.0)? The documentation seems to suggest that broker support for schema level variables was originally limited to just EXTERNAL, SHARED, or CONSTANT variables, and then later extended to include Normal variables, ... |
Not quite. I remember having used namespaces at a schema level and the scope of those was the schema level (V6.0 and 7.0.0.3). So I would have expected that the scope of other type of variables would have been the schema level as well. |
It's not clear from the documentation when the broker introduced support for schema variables that are not shared, external, or constant, but that feature never worked for compiled message flows.
NAME and NAMESPACE variables are implicitly constant; the defect in question doesn't apply to constant variables. |
|
| Back to top |
|
|
| mgk |
| Posted: Sun Jul 07, 2013 6:11 pm Post subject: |
|
|
Padawan
Joined: 31 Jul 2003
Posts: 1642
|
Clearly the documentation can be improved in this area, but I thought I'd use this post to try and explain the behaviour.
Variables declared at Module level clearly "belong" to a single node. However, variables declared at the Schema level are also given to each node that references that Schema. So although it looks like variables at Schema level are only declared once (as you only write them in the Schema once) each ESQL node (Compute / Database / Filter) has its own copy which is not shared with any other node (unless the variable is marked SHARED). Also, it's worth pointing out that variables are initialised for each message through that node (unless the variable is SHARED).
Hopefully this clears up some of the questions raised on this thread, and I will make sure that this gets a better explanation in the infocenter.
Kind 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 |
|
|
| mqjeff |
| Posted: Mon Jul 08, 2013 8:12 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
| mgk wrote: |
Clearly the documentation can be improved in this area, but I thought I'd use this post to try and explain the behaviour.
Variables declared at Module level clearly "belong" to a single node. However, variables declared at the Schema level are also given to each node that references that Schema. So although it looks like variables at Schema level are only declared once (as you only write them in the Schema once) each ESQL node (Compute / Database / Filter) has its own copy which is not shared with any other node (unless the variable is marked SHARED). Also, it's worth pointing out that variables are initialised for each message through that node (unless the variable is SHARED).
Hopefully this clears up some of the questions raised on this thread, and I will make sure that this gets a better explanation in the infocenter. |
Yes, again it's not so clear that this is the desired behavior, even if it's the working-as-designed behavior.
Particularly a CONSTANT is not expected to change value between one node of a flow and another. It's a CONSTANT. It should always be the same. And in general, SCHEMA is not expected to be scoped by node.
It seems reasonable to expect that all variables declared at the schema level are scoped to the schema, not to nodes that use the schema. While this would seem to imply that they were shared between different flows, I think it's reasonably clear that it's not expected to do that.
And SHARED variables are expected to be shared across instances, so having to use one to share the same data across nodes within the same instance is not expected.
In making Broker Schemas look and act like Java packages, you are setting expectations that internal behavior is similar. |
|
| Back to top |
|
|
| goffinf |
| Posted: Fri Jul 19, 2013 5:23 am Post subject: |
|
|
Chevalier
Joined: 05 Nov 2005
Posts: 401
|
This morning I installed iFix001 for the Toolkit for version 8.0.0.2 and I can confirm that *normal* variables declared at schema level *are* now included in the CMF when the 'Compile and inline resources' option is selected. So the behaviour between deploying as 'source' and 'compiled' appears to be the same.
No further word on whether the behaviours noted for schema level CONSTANTS or node scope when SETing normal schema variables is by design or a defect.
Fraser. |
|
| Back to top |
|
|
| mgk |
| Posted: Fri Jul 19, 2013 8:14 am Post subject: |
|
|
Padawan
Joined: 31 Jul 2003
Posts: 1642
|
| Quote: |
| No further word on whether the behaviours noted for schema level CONSTANTS or node scope when SETing normal schema variables is by design or a defect. |
See what I wrote above...
Kind 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 |
|
|
| goffinf |
| Posted: Fri Jul 19, 2013 2:46 pm Post subject: |
|
|
Chevalier
Joined: 05 Nov 2005
Posts: 401
|
| mgk wrote: |
| Quote: |
| No further word on whether the behaviours noted for schema level CONSTANTS or node scope when SETing normal schema variables is by design or a defect. |
See what I wrote above...
Kind regards, |
Yes I read that and, whilst you have provided an explanation of the technical implementation, and I thank you for it, it stops short of declaring that this is the intended behaviour. A small point perhaps given the reality of what is there today, however, if there are unintentional or perhaps even unknown side-effects here, then that might be grounds for an APAR or RFE.
I have spoken to a good many MB Dev's about this and none were aware and some a bit surprised. I think the evidence of this thread supports that view too. Now it might be that this simply indicates that schema level normal variables are not used much, and constants typically don't contain timestamps, so these could be considered as edge cases. But it would still be nice to have an official response from IBM and have the InfoCentre explain this much as you have done (I know you said you would forward that concern).
Kind regards
Fraser. |
|
| Back to top |
|
|
| rekarm01 |
| Posted: Sun Jul 21, 2013 8:18 pm Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 1415
|
| goffinf wrote: |
| This morning I installed iFix001 for the Toolkit for version 8.0.0.2 |
Was there any mention of a similar toolkit iFix planned for wmb7 and earlier versions?
| goffinf wrote: |
| [mgk's explanation] it stops short of declaring that this is the intended behaviour. |
If mgk considered it a defect, he probably would have mentioned it. Perhaps it would be clearer to call them node-level variables, as they're declared within the node; the schema only provides a namespace.
| goffinf wrote: |
| I have spoken to a good many MB Dev's about this and none were aware and some a bit surprised. |
Many MB Dev's are also surprised that a message flow is implemented as a sequence of nested function calls between otherwise unrelated node objects, rather than a pipeline, (until they encounter a stack overflow from a physical loop between nodes). Due to the nature of nested function calls, it might be somewhat difficult to implement "transaction-scope" variables, without some sort of dynamic scoping, (which only a small fraction of languages implement).
| goffinf wrote: |
| Now it might be that this simply indicates that schema level normal variables are not used much, and constants typically don't contain timestamps, so these could be considered as edge cases. |
Schema level normal variables didn't work prior to wmb8, so they probably weren't used much before then. The timestamp example was meant as an edge case, to illustrate that constant variables are not quite the same thing as actual constants, similar to constant variables in other languages. |
|
| Back to top |
|
|
| smdavies99 |
| Posted: Sun Jul 21, 2013 9:58 pm Post subject: |
|
|
Jedi Council
Joined: 10 Feb 2003
Posts: 6076
Location: Somewhere over the Rainbow this side of Never-never land.
|
| rekarm01 wrote: |
Was there any mention of a similar toolkit iFix planned for wmb7 and earlier versions?
|
From the list of things shown in the RSS feed, I get a distinct feeling that 7.0.0.6 is not that far away. (Naturally, I might just be guessing and suffering from a bit of sun from Lords yesterday....  )
_________________
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 |
|
|
| goffinf |
| Posted: Thu Aug 08, 2013 1:49 am Post subject: |
|
|
Chevalier
Joined: 05 Nov 2005
Posts: 401
|
Latest update from IBM (basically they confirmed mgk's description of behaviour as 'works as designed' and have raised an APAR to update the documentation to make this clearer). I suspect that I will now be asked to close the PMR. Does anyone have any further comments they would like me to raise under this one ?
| Quote: |
IBM Update8/6/13 3:07 PM
APAR IC94678 received and assigned to Anita by WMQ Infrastructure
TaskID
opentype:default
MQAUGAPT
IBM Update8/6/13 1:57 PM
Action Taken: Reviewed L3's update and created Doc Apar IC94678.
Action Planned: Req to EFBWMB,25A
Hello John,
Please see L3's update concerning ESQL variables declared at module
level vs using the shared option. I have created the documentation apar
IC94678.
Thanks Yvette, WMB L2
Action Planned: Req Sec to MQIHUR,244
Hello Jack,
I have created Doc apar IC94678 for CLARIFY EXPECTED BEHAVIOR AND SCOPE
OF ESQL VARIABLES.
Thanks Yvette, WMB L2
IBM Update8/6/13 12:07 PM
*************************** WMB_APAR_Request ***************************
Abstract:CLARIFY EXPECTED BEHAVIOUR AND SCOPE OF ESQL VARIABLES
Desc:
ESQL Variables declared at Module level "belong" to a single node.
However, variables declared at the Schema level are also given to each
node that references that Schema. So although it looks like variables
at Schema level are only declared once. Each ESQL node has its own copy
which is not shared with any other node (unless the variable is marked
SHARED).
The information center is not sufficiently clear that this is the
expected behaviour of variables defined at a Schema level.
COMPID: 5724J0500 - WMB Multiplatforms V6.1
Type: F
Sec/Int?:N
LocalFix:
************************* End WMB_APAR_Request *************************
IBM Update8/6/13 11:01 AM
Hi L2
There is a post in the forum thread from one of our developers that
gives a good explanation of the behavior and answers the question
raised, however the customer wanted clarification the post described the
is expected behavior.
I can confirm that this is indeed the expected behavior and the product
is working as designed. The post is below for reference.
'Variables declared at Module level clearly "belong" to a single node.
However, variables declared at the Schema level are also given to each
node that references that Schema. So although it looks like variables
at Schema level are only declared once (as you only write them in the
Schema once) each ESQL node (Compute / Database / Filter) has its own
copy which is not shared with any other node (unless the variable is
marked SHARED).'
Hence why you see different values for CURRENT_TIMESTAMP
'Also, it's worth pointing out that variables are
initialised for each message through that node (unless the variable is
SHARED).'
As the post also suggests the documentation needs updating in this area,
so I will take DOC APAR to address this.
Regards Jack
(wmbaug13jb)
|
|
|
| Back to top |
|
|
| rekarm01 |
| Posted: Sat Aug 17, 2013 11:29 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 1415
|
| goffinf wrote: |
| I suspect that I will now be asked to close the PMR. Does anyone have any further comments they would like me to raise under this one ? |
If it's not too late to ask (again), was there any mention of applying the toolkit ifix (APAR IC93278) to wmb7 and earlier versions? |
|
| Back to top |
|
|
| goffinf |
| Posted: Sun Aug 18, 2013 12:10 pm Post subject: |
|
|
Chevalier
Joined: 05 Nov 2005
Posts: 401
|
| rekarm01 wrote: |
| goffinf wrote: |
| I suspect that I will now be asked to close the PMR. Does anyone have any further comments they would like me to raise under this one ? |
If it's not too late to ask (again), was there any mention of applying the toolkit ifix (APAR IC93278) to wmb7 and earlier versions? |
I'll see what I can do, but unfortunately my company has just reorganised and much to my enormous disappointment I find myself no longer in the integration team
I will continue my involvement in the Message Broker (and IB) products albeit from a personal research aspect (this is no stranger to me, I developed a unit test framework for MB without company support which is now core to our production DLC).
Kind regards
Fraser. |
|
| 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
|
|
|
|
