| Author |
Message
|
| Sovesky |
 Posted: Wed Sep 11, 2013 3:36 am Post subject: User Defined Properties - must specify an initial value... |
 |
|
Novice
Joined: 30 Aug 2013
Posts: 17
|
Hi all,
Using MB 8.0.0.2 I’m experiencing a strange behavior with User Defined Properties. In my main flow, I’m using a single UDP that is mandatory and type string, named deployEnvironment.
That UDP is declared inside my first compute node (only place where it is being used) like below:
| Code: |
CREATE COMPUTE MODULE Module_Name
DECLARE [b]deployEnvironment[/b] EXTERNAL CHARACTER;
CREATE FUNCTION Main() RETURNS BOOLEAN
BEGIN
…
END;
END MODULE; |
What happens at deployment time?
BIP4055E: (.Module_Name, 2.2) : User defined attribute must specify an initial value expression.
User defined attributes must either be given an initial value on the DECLARE statement or be given a value at deploy time.
Set the value of the User Defined Attribute at deploy time.
I’m actually giving it an initial value in my flow’s definition!
This ESQL file is defined in the default schema, which I’m aware is a problem with UDPs, but it shouldn’t be in this case, because the UDP is only used in this specific compute node, which is present in the main flow, i.e. the declaration is made in the module level, instead of schema level.
As anyone ever faced this problem?
Last edited by Sovesky on Wed Sep 11, 2013 5:58 am; edited 1 time in total |
|
| Back to top |
|
 |
| lancelotlinc |
| Posted: Wed Sep 11, 2013 3:39 am Post subject: |
|
|
Jedi Knight
Joined: 22 Mar 2010
Posts: 4941
Location: Bloomington, IL USA
|
1. Never use default schema for anything.
2. Specify a schema scope for your message flow.
3. Specify a string value in the UDP properties page of your message flow.
4. Override that value at deploy time.
5. Do not combine ESQL code into a single file. -- the toolkit scopes variables within schemas and mixing different ESQL nodes' code together confuses the toolkit, the mqsipackagebar and the mqsideploy operations.
6. Each individual compute node should have its own ESQL file.
7. "I’m experiencing a strange behavior " -- its not strange behavior when you break the rules.
| Code: |
| DECLARE deployEnvironment EXTERNAL CHARACTER 'aa'; |
P. S. Please edit your post above to wrap your CODE with code tags.
_________________
http://leanpub.com/IIB_Tips_and_Tricks
Save $20: Coupon Code: MQSERIES_READER
Last edited by lancelotlinc on Wed Sep 11, 2013 3:51 am; edited 2 times in total |
|
| Back to top |
|
|
| Sovesky |
| Posted: Wed Sep 11, 2013 3:45 am Post subject: |
|
|
Novice
Joined: 30 Aug 2013
Posts: 17
|
| But should this be a problem since I'm declaring it a Module level? |
|
| Back to top |
|
|
| lancelotlinc |
| Posted: Wed Sep 11, 2013 3:48 am Post subject: |
|
|
Jedi Knight
Joined: 22 Mar 2010
Posts: 4941
Location: Bloomington, IL USA
|
| Sovesky wrote: |
| But should this be a problem since I'm declaring it a Module level? |
Shall I retype my above post in all CAPS ? Would all CAPS make a difference for you?
_________________
http://leanpub.com/IIB_Tips_and_Tricks
Save $20: Coupon Code: MQSERIES_READER |
|
| Back to top |
|
|
| mqjeff |
| Posted: Wed Sep 11, 2013 3:49 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
| Is it that much of a struggle to add an empty value to the ESQL declare statement? |
|
| Back to top |
|
|
| Sovesky |
| Posted: Wed Sep 11, 2013 6:08 am Post subject: |
|
|
Novice
Joined: 30 Aug 2013
Posts: 17
|
mqjeff,
No it's not, I'm just trying to understand the problem.
lancelotlinc,
1. I understand that using the default schema is not advised because everything will be included with every node that uses ESQL.
2. It was already there, the only artifacts in the default namespace were my ESQL files.
3. It was already done.
4. Also done.
5. I'm sorry but I found this point a bit confusing. What do you mean with combining ESQL code?
6. Why? I'm not seeing any gains from doing it.  Is it related to point 5?
7. Why am I breaking the rules? I've done it in different projects without any problem. Of course, the default values were defined in the User Properties Tab, of my message flow.
Thank you for your useful advice  |
|
| Back to top |
|
|
| lancelotlinc |
| Posted: Wed Sep 11, 2013 6:23 am Post subject: |
|
|
Jedi Knight
Joined: 22 Mar 2010
Posts: 4941
Location: Bloomington, IL USA
|
| Sovesky wrote: |
| 5. I'm sorry but I found this point a bit confusing. What do you mean with combining ESQL code? |
{Rhetorical} What is to be gained by placing all ESQL code in a single file? Not much.
| Sovesky wrote: |
| 6. Why? I'm not seeing any gains from doing it. Is it related to point 5? |
A typical project will have applications, libraries, and subflows, many of them in different packages and schemas. If you drag a Compute node onto your canvas, and double-click it, an ESQL file is created for you in the proper package. Why do you want to override this correct behavior ?
| Sovesky wrote: |
| 7. Why am I breaking the rules? I've done it in different projects without any problem. Of course, the default values were defined in the User Properties tab. |
Because you did not follow the documented practice :
http://publib.boulder.ibm.com/infocenter/wmbhelp/v8r0m0/index.jsp?topic=%2Fcom.ibm.etools.mft.doc%2Fak04980_.htm
| Quote: |
All the UDPs in a message flow must have a value
| Code: |
| DECLARE deployEnvironment EXTERNAL CHARACTER 'Dev'; |
|
| Sovesky wrote: |
| Thank you for your useful advice |
Your welcome.
_________________
http://leanpub.com/IIB_Tips_and_Tricks
Save $20: Coupon Code: MQSERIES_READER |
|
| Back to top |
|
|
| smdavies99 |
| Posted: Wed Sep 11, 2013 6:47 am Post subject: |
|
|
Jedi Council
Joined: 10 Feb 2003
Posts: 6076
Location: Somewhere over the Rainbow this side of Never-never land.
|
| lancelotlinc wrote: |
A typical project will have applications, libraries, and subflows, many of them in different packages and schemas. If you drag a Compute node onto your canvas, and double-click it, an ESQL file is created for you in the proper package. Why do you want to override this correct behavior ?
|
As I see it he's not trying to do that.
If you have used the 'Defaults' (cue much contact admin of teeth by Lancelotlinc) and not created a broker schema then everything will be in the same schema, called "".
I think that LL is going to have to accept that not every site uses the same development standards that he eschews and that there is nowt wrong with using the default schema after all, IBM do make it the default don't they?
After all, using the default schema won't suddenly stop a flow from working. AFAIK, there is no bit of ESQL that needs to be in a schema to work, of there is, I've not come upon it yet.
Just saying that a little tolerance of how other people develop code might help things a bit.
_________________
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 |
|
|
| lancelotlinc |
| Posted: Wed Sep 11, 2013 6:54 am Post subject: |
|
|
Jedi Knight
Joined: 22 Mar 2010
Posts: 4941
Location: Bloomington, IL USA
|
| smdavies99 wrote: |
| lancelotlinc wrote: |
A typical project will have applications, libraries, and subflows, many of them in different packages and schemas. If you drag a Compute node onto your canvas, and double-click it, an ESQL file is created for you in the proper package. Why do you want to override this correct behavior ?
|
As I see it he's not trying to do that.
If you have used the 'Defaults' (cue much contact admin of teeth by Lancelotlinc) and not created a broker schema then everything will be in the same schema, called "".
I think that LL is going to have to accept that not every site uses the same development standards that he eschews and that there is nowt wrong with using the default schema after all, IBM do make it the default don't they?
After all, using the default schema won't suddenly stop a flow from working. AFAIK, there is no bit of ESQL that needs to be in a schema to work, of there is, I've not come upon it yet.
Just saying that a little tolerance of how other people develop code might help things a bit. |
If the global variable is in "" and the UDP is in "com.smdavies.chippy", then the value will not be properly referenced at runtime.
The proper use of toolkit is to allow the toolkit to properly place ESQL in the unique file per ESQL Compute node. One shouldn't override the behavior without good reason, especially when one doesn't understand how it works.
IBM toolkit developers, as superbly intelligent as they are, cannot predict a users' schema: 'com.smdavies.chippy'. Thats why the default is blank. That doesn't mean you should create resources in a '' schema.
_________________
http://leanpub.com/IIB_Tips_and_Tricks
Save $20: Coupon Code: MQSERIES_READER |
|
| Back to top |
|
|
| kimbert |
| Posted: Wed Sep 11, 2013 7:42 am Post subject: |
|
|
Jedi Council
Joined: 29 Jul 2003
Posts: 5542
Location: Southampton
|
| Quote: |
| LL is going to have to accept that not every site uses the same development standards that he eschews |
I should think he would accept that quite happily.
http://www.thefreedictionary.com/eschew
#pedantic
_________________
Before you criticize someone, walk a mile in their shoes. That way you're a mile away, and you have their shoes too. |
|
| Back to top |
|
|
| Sovesky |
| Posted: Wed Sep 11, 2013 8:24 am Post subject: |
|
|
Novice
Joined: 30 Aug 2013
Posts: 17
|
| lancelotlinc wrote: |
{Rhetorical} What is to be gained by placing all ESQL code in a single file? Not much. |
Now I get it. I'm not putting all ESQL code into a single file, but at the same time I'm not modulating it in a 1 to 1 relation with each compute node.
| lancelotlinc wrote: |
A typical project will have applications, libraries, and subflows, many of them in different packages and schemas. If you drag a Compute node onto your canvas, and double-click it, an ESQL file is created for you in the proper package. Why do you want to override this correct behavior ?
|
I did not know it was a correct behavior. I just noticed it was the default behavior. Personally I prefer to use my own modulation method for code/artifact management issues.
Example 2 in that page shows:
| Quote: |
Example 2:
DECLARE TODAYSCOLOR EXTERNAL CHARACTER;
SET COLOR = TODAYSCOLOR |
Which led me to believe that the default value is optional. |
|
| Back to top |
|
|
| lancelotlinc |
| Posted: Wed Sep 11, 2013 8:31 am Post subject: |
|
|
Jedi Knight
Joined: 22 Mar 2010
Posts: 4941
Location: Bloomington, IL USA
|
| Sovesky wrote: |
| I did not know it was a correct behavior. I just noticed it was the default behavior. Personally I prefer to use my own modulation method for code/artifact management issues. |
What do you gain from this besides a head-ache ?
What benefit do you get from combining Compute logic from multiple Compute nodes into a single file?
I can see none.
So what you have done is shift the burden of effort for managing source code files from the tool to the human. You have also disabled the ability for Eclipse to refactor your code as a matter of semi-automation, since if you have three Compute node logics in one file and you refactor one of those nodes, then the human has to go edit that file rather than the correct way for having Eclipse simply change what it needs to do.
With no upside and alot of downside, I don't understand your rationale. We should be finding more ways to shift workload burden off of the human and onto the tooling -- not the other way around.
_________________
http://leanpub.com/IIB_Tips_and_Tricks
Save $20: Coupon Code: MQSERIES_READER
Last edited by lancelotlinc on Wed Sep 11, 2013 8:48 am; edited 1 time in total |
|
| Back to top |
|
|
| smdavies99 |
| Posted: Wed Sep 11, 2013 8:48 am Post subject: |
|
|
Jedi Council
Joined: 10 Feb 2003
Posts: 6076
Location: Somewhere over the Rainbow this side of Never-never land.
|
| kimbert wrote: |
| Quote: |
| LL is going to have to accept that not every site uses the same development standards that he eschews |
I should think he would accept that quite happily.
http://www.thefreedictionary.com/eschew
#pedantic |
Opps. Wrong word.
s/eschews/promotes/
_________________
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 |
|
|
| smdavies99 |
| Posted: Wed Sep 11, 2013 8:50 am Post subject: |
|
|
Jedi Council
Joined: 10 Feb 2003
Posts: 6076
Location: Somewhere over the Rainbow this side of Never-never land.
|
| Sovesky wrote: |
I did not know it was a correct behavior. I just noticed it was the default behavior. Personally I prefer to use my own modulation method for code/artifact management issues.
|
Yay  
_________________
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 |
|
|
| lancelotlinc |
| Posted: Wed Sep 11, 2013 8:53 am Post subject: |
|
|
Jedi Knight
Joined: 22 Mar 2010
Posts: 4941
Location: Bloomington, IL USA
|
| smdavies99 wrote: |
| Sovesky wrote: |
I did not know it was a correct behavior. I just noticed it was the default behavior. Personally I prefer to use my own modulation method for code/artifact management issues.
|
Yay |
"We should be finding more ways to shift workload burden off of the human and onto the tooling -- not the other way around." Unless of course you are insecure in your position, eh?
_________________
http://leanpub.com/IIB_Tips_and_Tricks
Save $20: Coupon Code: MQSERIES_READER |
|
| Back to top |
|
|
|
|
