| Author |
Message
|
| shalabh1976 |
 Posted: Mon Jun 23, 2003 2:37 am Post subject: MQSI Abend on Dynamic Function call |
 |
|
Partisan
Joined: 18 Jul 2002
Posts: 381
Location: Gurgaon, India
|
We have the following code :
If InputRoot.XML.msg.tag1 IS NOT NULL THEN
SET CH_Data = tag1(InputRoot.XML.msg.tag1, CH_Data);
END IF;
.
.
.
If InputRoot.XML.msg.tag60 IS NOT NULL THEN
SET CH_Data = tag60(InputRoot.XML.msg.tag60, CH_Data);
END IF;
There are 60 functions tag1,... tag60 for each of the XML tags
We wanted to replace this with :
While k <= 60 do
SET Tagname = FIELDNAME(InputRoot.XML.msg.*[k]);
EVAL('SET CH_Data = '|| Tagname ||' (InputRoot.XML.msg.*[k],CH_Data);');
SET k = k + 1;
end while ;
On execution this gave a MQSI abend and no other information was available.
A trace showed that the EVAL statement had evaluated the first XML tag to tag1 and the statement had resolved to :
SET CH_Data = tag1(InputRoot.XML.msg.*[1],CH_Data);
But then MQSI Abended.
Any Inputs? |
|
| Back to top |
|
 |
| Craig B |
| Posted: Mon Jun 23, 2003 3:56 am Post subject: |
|
|
Partisan
Joined: 18 Jun 2003
Posts: 316
Location: UK
|
What CSD level are you running at? I believe there were problems with dynamically calling functions from an EVAL statement in earlier CSDs such as CSD2 and CSD3. I have successfully called a function dynamically from an EVAL statement on CSD04.
_________________
Regards
Craig |
|
| Back to top |
|
|
| shalabh1976 |
| Posted: Mon Jun 23, 2003 5:06 am Post subject: |
|
|
Partisan
Joined: 18 Jul 2002
Posts: 381
Location: Gurgaon, India
|
We are on CSD 2 and do you have an alternate solution to optimize the code ?
This is because even though there are around 60 XML tags , at any given time only 15-16 tags come in the input.
But our code searches for the presence for all 60 to construct the output.
Hence the dynamic function call.
This is the also the node that was causing the performance issue as you had pointed out in a previous post. |
|
| Back to top |
|
|
| Craig B |
| Posted: Mon Jun 23, 2003 6:33 am Post subject: |
|
|
Partisan
Joined: 18 Jun 2003
Posts: 316
Location: UK
|
It would seem that you need to go to CSD04 to correct the abend you are seeing and then it should be possible to do what you are trying to do. However, from a performance point of view it seems you could be jumping out of the frying pan and into the fire. The EVAL statement carries a performance impact with it such that the ESQL has to be dynamically constructed, validated and executed at run-time. So if you intend to execute many of these sequentially you may end up with worse performance than you have now. Because an EVAL statement can execute multiple ESQL statements, then in cases it almost carries the same weight (in ESQL terms) as adding a new compute node into the flow.
Unfortunately I cannot suggest any alternatives without having a fuller understanding of what you are trying to do. Can you give a further description of how each tag is processed differently. Ie, how each of these 60 user functions is different?
_________________
Regards
Craig |
|
| Back to top |
|
|
| shalabh1976 |
| Posted: Mon Jun 23, 2003 8:54 pm Post subject: |
|
|
Partisan
Joined: 18 Jul 2002
Posts: 381
Location: Gurgaon, India
|
Ok,
Every XML tag maps to something called a hex function code.
So for an XML :
<msg><tag1>data1</tag1><tag2>data23</tag2></msg>
the output looks like :
X'12'data1X'1E'X'13'data2X'1E'
Here X'1E' is the delimiter.
Now as explained before, we check for the existence of each XML tag, if it is present we construct a string and concatenate the string, function code, data and the delimiter.
So now we have 60 if statements.
But in general only 15-16 XML tags come but we still run through the 60 if statements.
There must be a way to optimize this.
As you said the EVAL is slow and also CSD 2 does not support dynamic function calls.
If this is still not clear I will put the actual code in my next post. |
|
| Back to top |
|
|
| Craig B |
| Posted: Mon Jun 23, 2003 11:32 pm Post subject: |
|
|
Partisan
Joined: 18 Jun 2003
Posts: 316
Location: UK
|
From the details given in your response it would seem that there functions perform a mapping from XML tags to Delimited style output using the data within the tags in a BLOB type bitstream. Is the mapping as fixed as this? Have you consider using the MRM for this type of transformation. If you create an MRM messageSet that has an XML wire format and a corresponding TDS wire format layer. It should be possible to set the TDS layer to be Tagged such that each element has its tag such as X'12' and X'13' etc, and then each element can be separated by the delimiter X'1E'. Then the transformation in the compute node would just be a matter of mapping between the XML wire format and the TDS wire format. This would be one line of ESQL and you can then add others to maybe trim/add things to the message tree as required for your scenario.
If this did not apply to the whole message then this approach would still be useful because (if you moved to CSD03 or above) you could use the ASBITSTREAM function and CREATE with PARSE functionality to only perform this mapping on parts of the message as required.
_________________
Regards
Craig |
|
| Back to top |
|
|
| shalabh1976 |
| Posted: Tue Jun 24, 2003 4:48 am Post subject: |
|
|
Partisan
Joined: 18 Jul 2002
Posts: 381
Location: Gurgaon, India
|
Can you declare X'1E' as a delimiter ?
Also we cannot shift to CSD03 or 04.
We had initially tried to use TDF for this but we ran into problems with a hex delimiter.
Also the output is not fixed but based on the presence or absence of a xml tag.
Would you then declare all elements as optional ?
Can you outline the steps to do the same ? |
|
| Back to top |
|
|
| Craig B |
| Posted: Tue Jun 24, 2003 9:48 am Post subject: |
|
|
Partisan
Joined: 18 Jun 2003
Posts: 316
Location: UK
|
I assume when you want to use a delimiter such as X'1E' then you do not want the characters X apostrophe 1E and then apostrophe written out but the bytes 1E in the bitstream. As far I can remember you can specify a value such as this by using the TDS Mneumonic version as documented in Appendix B of the latest Working with messages guide. This should allow you to enter something such as <U+001E>. However it should be noted that this is the bytes in Unicode and this is subject to data conversion to the target codepage of your MRM message. So if your target codepage was 437 for example, then this would come out as x'1E' since this just happen to be mapping between these codepages.
However, I cannot remember whether this <U+xxxx> functionality was introduced in CSD02 or CSD03. Im pretty sure it was CSD02 so hopefully you can use it.
Moving on to optional elements, then you are in luck. Some aspects of some MRM formats inherently support optional elements, and this is usually the default. For these aspects then the user would to change the settings such that they were not tolerated and this would usually involve switching the message validation functionality on in CSD04 and above and changing such things as min and maxOccurs etc. The MRM-XML wire format will tolerate elements being omitted from your model. Not all TDS data element separation techniques allow optional elements, however, when using Tagged Delimited then this should allow elements to be missing. This is because the TDS parser would be able to calculate that the elements were omitted if it reparsed this bitstream. It would be able to do this in a straight tagged environment because the tags indicate which elements are present and which are not.
From what you have told me of this scenario then in theory this should be possible, but there may be some other aspects that you would have to consider. But I would definitely consider this mapping option over manual ESQL to perform the transformation, especially if you are considering performance.
I'll try and create a small example to demonstrate what I mean.
_________________
Regards
Craig |
|
| Back to top |
|
|
| shalabh1976 |
| Posted: Wed Jun 25, 2003 12:36 am Post subject: |
|
|
Partisan
Joined: 18 Jul 2002
Posts: 381
Location: Gurgaon, India
|
Will wait for your demo code.
There are other aspects to the code which I do not wish to discuss at this moment before trying it out myself.
If only the mapping was so straight forward....................... |
|
| Back to top |
|
|
|
|
