| |
|
RSS Feed - WebSphere MQ Support
|
RSS Feed - Message Broker Support
|
  |
|
| Extracting Tags in Tagged/Delimited format |
« View previous topic :: View next topic » |
| Author |
Message
|
| nicojvr |
 Posted: Sun Jun 29, 2003 8:21 am Post subject: Extracting Tags in Tagged/Delimited format |
 |
|
Apprentice
Joined: 04 Jun 2003
Posts: 45
|
Hi guys,
Can you tell me how to extract the tags from a tagged delimited format ? I know the parser chews up the tags on parsing, but how do i get to them if i defined my message set as specified in this jewel i found in the manual
| Quote: |
| Length of Tag :A numerical value indicating the length of a tag value. When the bitstream is parsed, this allows tags to be extracted if the Tag Data Separator property has not been set. It will also allow self defining elements to be extracted. |
thanks a mil
Nico |
|
| Back to top |
|
 |
| Craig B |
| Posted: Sun Jun 29, 2003 9:57 pm Post subject: |
|
|
Partisan
Joined: 18 Jun 2003
Posts: 316
Location: UK
|
When using Tagged Data Element separation then a tag needs to be extracted from the bitstream during the parse so that it can be matched to the dictionary. There are two ways of extracting tags and this is either through extracting a certain number of charcters or reading up until a tagged data separator. When the Length of Tag field is specified then this means that a certain number of characters will be read for the tag. So if you specify a Length of Tag of 3 for a compound type, then when the TDS parser is extracting its next tag then it reads 3 characters from the bitstream each time, and then tries to match this to the dictionary. If the tag cannot be found in the dictionary then the behaviour will be different depending on the settings for the data extraction. In a Tagged environment then the user can indicate that the Data is Fixed Length (Tagged fixed length) or is of variable length where delimiters indicate the end of the data (Tagged Delimited). If Tagged Fixed length then the data is to be extracted is of fixed length. Therefore the parser needs to be told by the dictionary how many characters to extract. If it cannot find the tag in the dictionary then it does not know how many characters to extract and therefore the parse has to end and an error is generated. When Tagged Delimited is being used then the parser does not need the dictionary to tell it how many characters to extract, it reads characters until the delimiter is encountered. This means for Tagged Delimited seperation the TDS parser can parse elements that do not appear in the dictionary and therefore create self defining elements in the message tree.
When the TDS parser creates a self defining element in the tree, then it uses the tag extracted as the field name in the message tree. Usually when a match is made for the tag in the dictionary then the tag is absorbed and the fieldname matched in the dictionary is used in the message tree field.
So the choice of Length of tag or Tagged Data Separator should not affect whether your tag names are accessible or not. However, the choice of Tagged Fixed length or Tagged delimited will affect whether you can have self defining elements in this type. If Tagged delimited is used then self defining elements can be used and when this happens the tags in the bitstream will appear in the message tree as the fieldnames.
So if you require access to the tags in the bitstream then if you can use Tagged Delimited and ensure that the tags do not appear in your message definitions, then these will be self defined into the tree.
For example, take the following bitstream :
A:Value1;B:Value2;C:Value3
If a Tagged Delimited were used with a Tagged Data Separator of : and a delimiter of ; then this would lead to the following pairs to be extracted : A=Value1, B= Value2, C=Value3. If the tags A,B,C and were not found in the compound type then the message tree would look like :
A = Value1
B = Value2
C = Value3
However, if the compound type contained three elements that had tags A,B,C with associated fieldnames of Field1, Field2, Field3 then this would have created the tree :
Field1=Value1
Field2=Value2
Field3=Value3
Hope this helps
_________________
Regards
Craig |
|
| Back to top |
|
|
| nicojvr |
| Posted: Mon Jun 30, 2003 1:41 am Post subject: |
|
|
Apprentice
Joined: 04 Jun 2003
Posts: 45
|
okay thanks
In your example you use a:data;b:data;c:data;
In my situation these are self defining and i got that working now...
but how do i get to a b and c itself in the compute node of my flow..
to get to the data i use :
| Code: |
DECLARE c INTEGER CARDINALITY (InputBody.*[]);
DECLARE i INTEGER 1;
while i < c do
call decode ("InputBody".*[i]);
SET i = i + 1;
end while; |
but how do i get the tags themselves ?
thanks
Nico |
|
| Back to top |
|
|
| Craig B |
| Posted: Mon Jun 30, 2003 2:15 am Post subject: |
|
|
Partisan
Joined: 18 Jun 2003
Posts: 316
Location: UK
|
The FIELDNAME function should give you what you require.
_________________
Regards
Craig |
|
| Back to top |
|
|
| nicojvr |
| Posted: Mon Jun 30, 2003 2:30 am Post subject: |
|
|
Apprentice
Joined: 04 Jun 2003
Posts: 45
|
Thanks !
Nico |
|
| 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
|
|
|
|
