| |
|
RSS Feed - WebSphere MQ Support
|
RSS Feed - Message Broker Support
|
  |
|
| WMB 6 \ Accessing Dynamic Fields - Limitation? |
« View previous topic :: View next topic » |
| Author |
Message
|
| hopsala |
 Posted: Mon Sep 29, 2008 3:59 am Post subject: WMB 6 \ Accessing Dynamic Fields - Limitation? |
 |
|
Guardian
Joined: 24 Sep 2004
Posts: 960
|
Ok, so here's the deal: I want to use a certain variable, let's call it FieldName, that indicates the exact location to which I want to write certain data. For example:
| Code: |
DECLARE FieldName CHARACTER 'Environment.Stuff.Data';
SET {FieldName} = 'my data'; |
This seemingly simple code doesn't compile - "Syntax error. Valid options include: IDENTIFIER SIMPLE_FUNCTION".
What does work, however, is the following:
| Code: |
DECLARE FieldName CHARACTER 'Stuff.Data'';
SET Environment.{FieldName} = 'my data'; |
And this, which also works:
| Code: |
DECLARE FieldName CHARACTER 'Environment.Stuff.Data';
SET "FieldName" = 'my data'; |
It seems that dynamic field references using {} are only accepted when preceded by a known correlation name. This is strange, but it gets stranger still - note the following:
| Code: |
DECLARE FieldName CHARACTER 'Environment.Stuff.Data';
CREATE LASTCHILD OF "FieldName"
DOMAIN('MRM')
PARSE (BitStream
ENCODING InputRoot.Properties.Encoding
CCSID InputRoot.Properties.CodedCharSetId
FORMAT InputRoot.Properties.MessageFormat
TYPE InputRoot.Properties.MessageType
SET InputRoot.Properties.MessageSet);
|
which, for some god-forsaken reason, doesn't work; it compiles alright, but dishes out a runtime exception of "Inappropriate field reference". The exact same code, using {FieldName} doesn't compile as before, but using Environment.{FieldName} or Environment."FieldName" works fine.
So, we have two different behaviors for "" in SET and CREATE statements, and a limitation on {}. In fact, there is no way for me to use CREATE with full field names, only partial ones. This is, to say the least, annoying, and really limits what I can program 
Is there any other way to accomplish this? Anyone? |
|
| Back to top |
|
 |
| mqjeff |
| Posted: Mon Sep 29, 2008 7:00 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
You can only specify one dot-level with {}.
So if you need "stuff.data", you need two variables and two {}'s.
Or a real EVAL. |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Mon Sep 29, 2008 9:54 am Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
| Quote: |
DECLARE FieldName CHARACTER 'Environment.Stuff.Data';
CREATE LASTCHILD OF "FieldName"
DOMAIN('MRM')
PARSE (BitStream
ENCODING InputRoot.Properties.Encoding
CCSID InputRoot.Properties.CodedCharSetId
FORMAT InputRoot.Properties.MessageFormat
TYPE InputRoot.Properties.MessageType
SET InputRoot.Properties.MessageSet); |
Should really have read
| Code: |
DECLARE FieldNameRef REFERENCE TO Environment.Stuff.Data;
CREATE LASTCHILD OF FieldNameRef
DOMAIN('MRM')
PARSE (BitStream
ENCODING InputRoot.Properties.Encoding
CCSID InputRoot.Properties.CodedCharSetId
FORMAT InputRoot.Properties.MessageFormat
TYPE InputRoot.Properties.MessageType
SET InputRoot.Properties.MessageSet); |
and this would have worked....
Learn to work with references.  Makes life so much easier... 
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| hopsala |
| Posted: Mon Sep 29, 2008 12:40 pm Post subject: |
|
|
Guardian
Joined: 24 Sep 2004
Posts: 960
|
| fjb_saper wrote: |
...Should really have read
| Code: |
DECLARE FieldNameRef REFERENCE TO Environment.Stuff.Data;
CREATE LASTCHILD OF FieldNameRef
DOMAIN('MRM')
PARSE (BitStream
ENCODING InputRoot.Properties.Encoding
CCSID InputRoot.Properties.CodedCharSetId
FORMAT InputRoot.Properties.MessageFormat
TYPE InputRoot.Properties.MessageType
SET InputRoot.Properties.MessageSet); |
|
Yea, but the thing is that FieldNameRef has to be dynamic, that is, I don't know in advance that the reference is going to be to 'Environment.stuff.data', instead I have a UDP with a character value of the name of the said field.
So it seems to me that this code just moves the problem elsewhere, now I have the same problem with "DECLARE FieldNameRef REFERENCE TO Environment.Stuff.Data;"...
| fjb_saper wrote: |
| Learn to work with references. Makes life so much easier... |
That's what i'm trying to do  I have read all that I could find on this site + tried a whole lot of variations on my own + read the lit, but the documentation for this is extremely lacking (there are no examples for anything I point out here, only one-line shotgun explanations). Besides, I haven't seen any reference concerning the odd difference in the behavior of "" in two of the cases I mentioned.
Last edited by hopsala on Mon Sep 29, 2008 12:51 pm; edited 1 time in total |
|
| Back to top |
|
|
| hopsala |
| Posted: Mon Sep 29, 2008 12:48 pm Post subject: |
|
|
Guardian
Joined: 24 Sep 2004
Posts: 960
|
| mqjeff wrote: |
You can only specify one dot-level with {}.
So if you need "stuff.data", you need two variables and two {}'s.
Or a real EVAL. |
Hm. I Admit that I didn't check whether I got one field called "Stuff.Data" or a father "Stuff" with son "Data". I'll check it in a few days when I get back to work.
But wait, I got a compile error, not a runtime error - I don't think the compiler checked to see if FieldName had a dot it in or not. Also, 'Stuff.Data' worked just fine, and it has a dot in it. There's something else going on here.
and all this still doesn't explain the "" oddity... |
|
| 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
|
|
|
|
