| |
|
RSS Feed - WebSphere MQ Support
|
RSS Feed - Message Broker Support
|
  |
|
| ESQL shorthand expansion behavior change from 7.0.0.2 to .3 |
« View previous topic :: View next topic » |
| Author |
Message
|
| lancelotlinc |
 Posted: Wed Aug 15, 2012 7:44 am Post subject: ESQL shorthand expansion behavior change from 7.0.0.2 to .3 |
 |
|
Jedi Knight
Joined: 22 Mar 2010
Posts: 4941
Location: Bloomington, IL USA
|
In bars built with toolkit 7.0.0.2, we had a reference to shorthand version of a variable like so:
| Code: |
| DECLARE id1 char Environment.Variables.id."1"; |
We executed a SELECT like so:
| Code: |
| SET Environment.Variables.id[] = PASSTHRU( 'SELECT NEXTVAL for XYZ_SEQ FROM SYSIBM.SYSDUMMY1' ... |
which returned the proper next sequence number such as:
which we then turned around and used in an insert statement like so:
| Code: |
| 'INSERT INTO XYZ VALUES(' || id1 || ',''' || ... etc |
For 7.0.0.2 toolkit-mqsicreatebar-built bar, the id1 variable properly evaluates at runtime to the value returned by the SQL select statement (ie. '19298504').
For 7.0.0.3 toolkit-mqsicreatebar-built bar, the id1 variable incorrectly evaluates to NULL, even though the SQL statement successfully returned the proper NEXTVAL.
The code fix is simple, just change id1 to Environment.Variables.id."1" in the INSERT statement. Shall I open a PMR to alert IBM of this change in behavior?
_________________
http://leanpub.com/IIB_Tips_and_Tricks
Save $20: Coupon Code: MQSERIES_READER |
|
| Back to top |
|
 |
| Vitor |
| Posted: Wed Aug 15, 2012 8:01 am Post subject: Re: ESQL shorthand expansion behavior change from 7.0.0.2 to |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| lancelotlinc wrote: |
| Shall I open a PMR to alert IBM of this change in behavior? |
If the 7.0.0.3 documentation says that should work then a PMR is the way to go. Even if the 7.0.0.3 documentation doesn't say anything but the 7.0.0.2 documentation said it did you should call on it.
If it's a dodge an unidentified IBM consultant came up with you have have limited success, but that's no reason not to try.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| lancelotlinc |
| Posted: Wed Aug 15, 2012 8:12 am Post subject: |
|
|
Jedi Knight
Joined: 22 Mar 2010
Posts: 4941
Location: Bloomington, IL USA
|
Personally I lean more towards explicit use of pathing, and avoid shorthand as it makes it more difficult for those following me to maintain my code. I'm unsure if the shorthand is a documented feature. I've never seen any documentation on shorthand of variable pathing although there seems to be an innocuous reference to the capability in the DECLARE page, except that the consultant doesn't use any explicit keyword where the DECLARE reference page suggests a keyword is not optional for 'field reference namespace fields' (ie. CONSTANT keyword).
_________________
http://leanpub.com/IIB_Tips_and_Tricks
Save $20: Coupon Code: MQSERIES_READER |
|
| Back to top |
|
|
| Vitor |
| Posted: Wed Aug 15, 2012 8:55 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
I'd still spin the PMR. It's no cost to raise and the worst they'll say is "What?"
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| mgk |
| Posted: Wed Aug 15, 2012 9:04 am Post subject: |
|
|
Padawan
Joined: 31 Jul 2003
Posts: 1642
|
Given what you posted I'm surprised by your original code working 
Are you sure this is the code you had to set up id1?
| Code: |
| DECLARE id1 char Environment.Variables.id."1"; |
I would expect this to evaluate once, when the DECLARE is reached and take whatever is the value in the Environment tree as its value, which would then be fixed (unless id1 itself was changed).
If id1 was a REFERENCE then I would expect this to work fine, as long as the location in the Environment tree existed when the DECLARE was reached...
What does a user trace show?
Also is the order of the statements in your post the same as in your actual code? Is it possible that the DECLARE of id1 was after the PASSTHRU, but before the INSERT (which should the then work ok)...
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 |
|
|
| lancelotlinc |
| Posted: Wed Aug 15, 2012 11:26 am Post subject: |
|
|
Jedi Knight
Joined: 22 Mar 2010
Posts: 4941
Location: Bloomington, IL USA
|
| mgk wrote: |
| as long as the location in the Environment tree existed when the DECLARE was reached... |
It is possible between March and July that I did 'clean up' the code and the order of execution was changed. So the working version DECLARE statement may have in fact been after the SELECT, in which case I see how it worked then, and not now. So I accept the conclusion that the behavior change was the result of my code clean up efforts and not toolkit behavior. Great point, thank you.
_________________
http://leanpub.com/IIB_Tips_and_Tricks
Save $20: Coupon Code: MQSERIES_READER |
|
| Back to top |
|
|
|
|
|
| |
|
Page 1 of 1 |
|
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
|
|
|
|
