Author |
Message
|
rekarm01 |
Posted: Sat Dec 15, 2012 11:12 am Post subject: Identifier "EmbeddedBitStream" cannot be resolved. |
|
|
Grand Master
Joined: 25 Jun 2008 Posts: 1415
|
In the WMB 8.0.0.1 toolkit, the ASBITSTREAM function call generates a warning: 'Identifier "EmbeddedBitStream" cannot be resolved.'
Code: |
... ASBITSTREAM(RootRef.*[<] OPTIONS EmbeddedBitStream) ... |
The broker seems to execute the code as expected, but the toolkit issues a warning anyway. This is not a new issue; older versions of the toolkit behave similarly. Short of changing the ASBITSREAM options or turning off warnings for all identifiers, is there a way to fix this in the ESQL, or at least suppress the warning? |
|
Back to top |
|
 |
mqjeff |
Posted: Sat Dec 15, 2012 11:39 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008 Posts: 17447
|
Try moving the order of the OPTIONS clause around.
Tookit is fussy about ESQL syntax in cases where it ideally wouldn't be. |
|
Back to top |
|
 |
rekarm01 |
Posted: Sat Dec 15, 2012 12:55 pm Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008 Posts: 1415
|
mqjeff wrote: |
Try moving the order of the OPTIONS clause around. |
There's only the one clause, which makes it difficult to re-order ...
Using the alternative syntax, where the clauses are positional rather than named, still generates a toolkit warning:
Code: |
... ASBITSTREAM(RootRef.*[<],,,,,, EmbeddedBitStream) ... |
And moving the "EmbeddedBitStream" outside of ASBITSTREAM():
Code: |
DECLARE myOpts INTEGER BITOR(EmbeddedBitStream, ValidateNone);
... ASBITSTREAM(RootRef.*[<] OPTIONS myOpts) ... |
just moves the warning to the line with the DECLARE statement. So the issue seems to be with "EmbeddedBitStream" itself. |
|
Back to top |
|
 |
mqjeff |
Posted: Sat Dec 15, 2012 4:15 pm Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008 Posts: 17447
|
Well, of course, you can tell Toolkit to only show you warning on a specific project...
You could always try redefining the dang thing yourself if you can figure out the actual byte value.
But, on the other hand.
Does it deploy? If it deploys, why concern yourself with Toolkit errors... |
|
Back to top |
|
 |
rekarm01 |
Posted: Sat Dec 15, 2012 8:29 pm Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008 Posts: 1415
|
mqjeff wrote: |
Does it deploy? If it deploys, why concern yourself with Toolkit errors... |
"concern" is too strong a word. The message flow deploys, and it does work as expected in the broker, but I just wanted to rule out any obvious problems with my code that I might have overlooked. I'm assuming that it's not just my toolkit that does this, and wondered how (or if) others might have handled it. |
|
Back to top |
|
 |
smdavies99 |
Posted: Sat Dec 15, 2012 10:34 pm Post subject: |
|
|
 Jedi Council
Joined: 10 Feb 2003 Posts: 6076 Location: Somewhere over the Rainbow this side of Never-never land.
|
A bit of a personal rant here.
Perhaps it is just me but I really don't like to see anything listed in the 'problems' tab in the TK. Sure I can turn off warnings but in many cases they do stop the flow from deploying or executing properly. eg Missing declaration of an ESQL variable. In others it does not affect the operation eg Links to a DB projects for the Table/Object schema.
Most of the time my flows don't have any items in the Problems tab. I just wish that adding the .jar file for the DB Perspective was a bit easier. Only last week, I spent a good hour trying to get the SQLServer .jar file to be recognised by the TK. In the end I gave up as it flatly refused to recognise the jar file even though linking to another that was built with a different JRE produced nice error messages.
Time to go walk the dog methinks. _________________ 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 |
|
 |
mqjeff |
Posted: Sun Dec 16, 2012 6:22 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008 Posts: 17447
|
I hate to see errors in the Toolkit too.
But, for example in v7, I am *never* going to take the trouble to create a toolkit specific JDBC connection just to get it to shut up about ODBC database access at runtime. |
|
Back to top |
|
 |
Vitor |
Posted: Mon Dec 17, 2012 5:20 am Post subject: |
|
|
 Grand High Poobah
Joined: 11 Nov 2005 Posts: 26093 Location: Texas, USA
|
mqjeff wrote: |
But, for example in v7, I am *never* going to take the trouble to create a toolkit specific JDBC connection just to get it to shut up about ODBC database access at runtime. |
If you have a lot of database access leading to significant numbers of warnings, then yes you are unless you're about to tell me how you can get more "serious" warnings (like missing identifier) to sort to the top. _________________ Honesty is the best policy.
Insanity is the best defence. |
|
Back to top |
|
 |
lancelotlinc |
Posted: Mon Dec 17, 2012 6:37 am Post subject: |
|
|
 Jedi Knight
Joined: 22 Mar 2010 Posts: 4941 Location: Bloomington, IL USA
|
rekarm, I would vote for a toolkit enhancement for making warnings more accurate.
In particular, I would like to see false warnings I get about namespaces go away since they are not valid. I'd like the toolkit to warn me about misplaced namespaces but not warn me about valid namespaces.
Today, the toolkit warns me about this:
Code: |
InputRoot.SOAP.Body.validnamespace:validSOAPRequest.theInfo.accountNumber |
Quote: |
"Unresolveable message field reference: "InputRoot.SOAP.Body.validnamespace:validSOAPRequest.theInfo.accountNumber". |
The runtime successfully derives this reference, but the toolkit does not. If you submit an : r f e : for your issue, I'll vote for it. I've submitted a PMR a couple of years ago on this issue and so far, nothing has changed in the toolkit. _________________ http://leanpub.com/IIB_Tips_and_Tricks
Save $20: Coupon Code: MQSERIES_READER |
|
Back to top |
|
 |
kimbert |
Posted: Mon Dec 17, 2012 8:35 am Post subject: |
|
|
 Jedi Council
Joined: 29 Jul 2003 Posts: 5542 Location: Southampton
|
FYI, I have opened an internal defect for the original problem. |
|
Back to top |
|
 |
rekarm01 |
Posted: Tue Dec 18, 2012 1:26 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008 Posts: 1415
|
lancelotlinc wrote: |
If you submit an : r f e : for your issue, I'll vote for it. |
My issue would be more of a defect, better resolved through a PMR, than an RFE, but thanks anyway. I am debating whether to open an RFE on an unrelated matter, (for making the Environment correlation identifier available to schema-level procedures and functions) ... if I do, you could vote for that instead.
lancelotlinc wrote: |
In particular, I would like to see false warnings I get about namespaces go away since they are not valid. I'd like the toolkit to warn me about misplaced namespaces but not warn me about valid namespaces. |
You'd know more about this issue than I, so you'd probably be better able to open an RFE yourself. Assuming that the relevant namespaces are in scope, and there's nothing wrong with the schema, if you've already opened a PMR and that didn't help, it's not certain that an RFE would do any better.
kimbert wrote: |
FYI, I have opened an internal defect for the original problem. |
Thanks for that. |
|
Back to top |
|
 |
|