| Author |
Message
|
| torryramesh |
 Posted: Wed Jun 14, 2006 7:25 am Post subject: Strange Is NULL after migrating to WBI MB 6.0 |
 |
|
Novice
Joined: 06 Aug 2004
Posts: 15
|
We migrated components from WMQI 2.1 to WBI MB 6.0 after which none of our test cases are passing
The
Input XML of the form:
<?xml version="1.0" ?>
<PIX_1_3 id="PIX_1_3_2004-10-29-10.43.23.796000" version="1.3" timestamp="2004-10-29T10:43:23">
<PIX>
.........
........
.........
........
</PIX>
</PIX_1_3>
There is an ESQL to eventually check if a PIX tag is present which is:
| Code: |
SET iNoOfPIX = CARDINALITY("InputBody"."PIX"[]);
SET iIndex = 1;
IF "InputBody"."PIX" IS NULL THEN
THROW USER EXCEPTION CATALOG 'EAIEXCEPTION' MESSAGE 4021;
END IF; |
The trace for the above ESQL is as below:
: Evaluating expression ''InputBody.PIX[ ]'' at ('.ItemUpdates_TransformXMLtoTDS.main', '53.28'). This resolved to ''InputBody.PIX[]''. The result was ''LIST... First Element Type=16777235 NameSpace='' Name='PIX' Value=NULL''.
: Finished evaluating expression ''CARDINALITY(InputBody.PIX[ ])'' at ('.ItemUpdates_TransformXMLtoTDS.main', '53.16'). The result was ''1''
.
: Executing statement ''SET iIndex = 1;'' at ('.ItemUpdates_TransformXMLtoTDS.main', '54.1').
: Executing statement ''IF InputBody.PIX IS NULL THEN... END IF;'' at ('.ItemUpdates_TransformXMLtoTDS.main', '56.1').
: Evaluating expression ''InputBody.PIX'' at ('.ItemUpdates_TransformXMLtoTDS.main', '56.4'). This resolved to ''InputBody.PIX''. The result was ''NULL''.
: Finished evaluating expression ''InputBody.PIX IS NULL'' at ('.ItemUpdates_TransformXMLtoTDS.main', '56.22'). The result was ''TRUE''.
: Executing statement ''THROW EXCEPTION CATALOG 'EAIEXCEPTION' MESSAGE 4021'' at ('.ItemUpdates_TransformXMLtoTDS.main', '57.1').
The puzzling part is why is the IS NULL check returning a NULL in MB 6.0.
The Encoding Null Num and Non-Num is carried from WMQI 2.1 and is set as NullAttribute (this is fyi)
Kindly suggest what strikes you closest while we debug this more for ourselves.
Thanks |
|
| Back to top |
|
 |
| JT |
| Posted: Wed Jun 14, 2006 8:36 am Post subject: |
|
|
Padawan
Joined: 27 Mar 2003
Posts: 1564
Location: Hartford, CT.
|
| Quote: |
<?xml version="1.0" ?>
<PIX_1_3 id="PIX_1_3_2004-10-29-10.43.23.796000" version="1.3" timestamp="2004-10-29T10:43:23">
<PIX>
.........
........
.........
........
</PIX>
</PIX_1_3> |
According to your XML example wouldn't the reference to the PIX element be:
| Code: |
| IF "InputBody"."PIX_1_3"."PIX" IS NULL THEN |
|
|
| Back to top |
|
|
| torryramesh |
| Posted: Wed Jun 14, 2006 10:16 pm Post subject: |
|
|
Novice
Joined: 06 Aug 2004
Posts: 15
|
PIX_1_3 is the message name and is modelled in MRM domain. Hence, the statment InputBody would inherently mean InputBody.PIX_1_3
Hope I'm correct and this has been working the same way in WMQI 2.1 and we did not change anything as part of Mirgration. |
|
| Back to top |
|
|
| elvis_gn |
| Posted: Wed Jun 14, 2006 11:36 pm Post subject: Re: Strange Is NULL after migrating to WBI MB 6.0 |
|
|
Padawan
Joined: 08 Oct 2004
Posts: 1905
Location: Dubai
|
Hi torryramesh,
| torryramesh wrote: |
The trace for the above ESQL is as below:
: Evaluating expression ''InputBody.PIX[ ]'' at ('.ItemUpdates_TransformXMLtoTDS.main', '53.28'). This resolved to ''InputBody.PIX[]''. The result was ''LIST... First Element Type=16777235 NameSpace='' Name='PIX' Value=NULL''.
The puzzling part is why is the IS NULL check returning a NULL in MB 6.0. |
Becoz the value in PIX is NULL....run in the debugger and check when it becomes NULL.
Regards. |
|
| Back to top |
|
|
| torryramesh |
| Posted: Fri Jun 16, 2006 5:57 am Post subject: |
|
|
Novice
Joined: 06 Aug 2004
Posts: 15
|
The element PIX has a lot of child elements and I did not represent them in the sample input in the posting just for brevity reasons. Sorry, if that caused some confusion.
Also, we observe that the IS NULL is not taking effect only for complex elements as in this case. The same operator works perfectly for child level elements.
Currently we have put in a work around by removing the IS NULL check and replaced it with a cardinality level check (i.e. if Cardinality (PIX) = 0). |
|
| Back to top |
|
|
| Duke |
| Posted: Sun Jun 18, 2006 10:34 pm Post subject: |
|
|
Apprentice
Joined: 09 Mar 2004
Posts: 49
Location: Belgium
|
Check in the "message set" properties of your message model.
There is a part where you can specify how null values are represented in a XML.
_________________
Pierre Richelle
Engineer
IBM Certified MQSeries Developper V5.3
IBM Certified WMQ Administration V6 |
|
| Back to top |
|
|
| nvogt |
| Posted: Sun Jun 18, 2006 11:22 pm Post subject: |
|
|
Novice
Joined: 27 Apr 2006
Posts: 11
Location: Aachen, Germany
|
They have changed the NULL Semantics completely. Look at PRB #2651 it explains the new NULL behaviour.
PRB #2651
Abstract: MRM field is seen as NULL in V5 (or above) whereas it was not in V2.1
Customer Symptoms
A customer has potentially encountered this problem if they have migrated a message flow from V2.1 to V5 (or above) and all of the following are true :
1. An MRM message is being manipulated.
2. In ESQL an MRM message tree field is tested against IS NULL and returns TRUE, whereas in V2.1 it returned FALSE.
3. The MRM message tree field is a parent field that has children associated with it.
The following type of entry would be seen in the user trace when the flow runs on V2.1
InputBody.EIGHT_BYTE_TAG_ELEM.CLOCHOS_TAG_ELEM.CLOCHOS_ELEM IS NOT
NULL' at (46, 79). The result was 'TRUE'
Whereas in V5 the following would be seen :
InputBody.EIGHT_BYTE_TAG_ELEM.CLOCHOS_TAG_ELEM.CLOCHOS_ELEM IS NOT
NULL' at (46, 79). The result was 'FALSE'
Products: WBI Message Broker + RFE v5.0,WBI Message Broker v5.0,WebSphere Message Broker v6.0,WebSphere Message Broker with Rules/Formatter v6.0
Platforms: AIX,HP-UX,Linux,Linux x86,Linux zSeries,Linux/390,Solaris,Windows 2000,Windows XP,z/OS OS/390,zOS
Technical Description:
It should be noted that this is not a DEFECT or REGRESSION and V5 now gives the correct behaviour for this scenario. Consider the following simple example :
SET OutputRoot.MRM.A.B.C.D = 'ddd';
SET OutputRoot.MRM.A.B.C.E = 'eee';
IF OutputRoot.MRM.A IS NULL THEN
SET Environment.Variables.Result = 'NULL';
ELSE
SET Environment.Variables.Result = 'NOT NULL';
END IF;
In V2.1 the Environment.Variables.Result field would have the value of 'NOT NULL' and in V5 it would have the value of NULL. The same would be true if OutputRoot.MRM.A.B or OutputRoot.MRM.A.B.C were tested against NULL. The reason for this is that these fields are MRM parent fields and this means that they do not have a value themselves but contain children. For example, consider the following MRM message definitions :
myMessage
- myStructure
- myElement1 : STRING : Length 5
- myElement2 : STRING : Length 5
- myElement3 : STRING : Length 5
If the bitstream of X'303132333435363738393031323334' were parsed against these definitions then this would produce the following parsed message tree :
myStructure = (
- myElement1 = '01234'
- myElement2 = '56789'
- myElement3 = '01234'
If Body.myStructure.myElement1 is queried then this has a value of '01234'. If Body.myStructure.myElement2 is queried then this has a value of '56789'. If Body.myStructure.myElement3 is queried then this has a value of '01234'.
However what value does myStructure have if Body.myStructure is queried?
Body.myStructure is an MRM parent only field that only has children. It can never have a value itself. Therefore it follows that this field is implicitly NULL and so if Body.myStructure is tested against IS NULL then it should return TRUE and not false. Therefore the V2.1 product was incorrect and the V5 product now gives the correct behaviour.
It should be noted that that this is not a change in behaviour but a defect fix that was made in the base code of V5. Unfortunately it is not possible to isolate exactly what defect number this problem was corrected. When a defect is found in a later product it is NOT fixed on previous releases until a fix is requested by a customer on that previous release. The reason this has not been fixed on V2.1 is because no customer has asked for a fix for this issue on V2.1. Also when considering a back-port of a fix to an older release, and investigation has to be performed on the dependency chain involved and how many other changes would also be required.
The main question that should be asked at this point is why the user is checking a parent message tree against IS NULL? The general answer to the question is that the field is being tested to see if it exists or NOT. It is true that if the field being tested does not exist in the message tree then it will be implicitly NULL and hence the test against IS NULL will return true. However, if the field does exist in the message tree, then its value will be checked to see whether the value is implicitly or explicitly NULL. For MRM parent fields the value is always implicitly NULL and so a check against IS NULL will return true and give the impression that the field does not exist. Therefore it is clear that IS NULL and IS NOT NULL cannot be used to determine existence of a message tree field. In V5 there are only really two main ways to consistently test the existence of a message tree field and these are :
1. Use the CARDINALITY function again the message tree field and if this returns a value > 0 then the field exists.
2. DECLARE/MOVE a reference variable to the field and then use the LASTMOVE function to determine if the field was successfully navigated to.
In V6 we believe the EXISTS function has been extended to test message tree fields, and that new functions have been introduced to test whether there is a single or multiple occurences of a field.
Comments
Whilst answering questions in relation to the value of MRM parent nodes, some customers have noted that XML parent nodes give different results when tested against NULL. If the previous example is changed to the XML domain then this would give :
SET OutputRoot.XML.A.B.C.D = 'ddd';
SET OutputRoot.XML.A.B.C.E = 'eee';
IF OutputRoot.XML.A IS NULL THEN
SET Environment.Variables.Result = 'NULL';
ELSE
SET Environment.Variables.Result = 'NOT NULL';
END IF;
Then in both V2.1 and V5 the Environment.Variables.Result would always be set to 'NOT NULL' which is different to the V5 testing of the MRM parent folder.
The reason a parent node in the MRM message tree is treated differently than a parent node in XML is because they are two different domains, with different types of message tree and different concepts of NULL. Please see documentation APAR IC35011 which explains how the XML domain treats NULL values. In summary, there is no bitstream value that can ever produce a NULL value in an XML message tree. Therefore no XML field will ever been seen as NULL even if manually populated (using ESQL) with an explicit NULL. Users often expect that MRM and XML message trees give the same result since message trees are meant to be format dependent entities that shield the user from the bitstream. Hence it is expected that NULL is a consistent concept.
Although the message tree is a logical entity that shields the user from the bitstream, the MRM and XML message trees do not implement the same hierarchy.
In the MRM message tree, a field can either be a container (a parent node), or it is a field that stores a single value. It CANNOT be both.
In the XML message tree, a field is BOTH a container that can have a single value or have multiple values (such as XML attributes, CDATA Sections etc).
When an MRM message tree stores a value, then this is done in a single message tree field which has a Name, Type and a Value. For example :
(0x3000000)Surname = 'JONES'
When an XML message tree stores a value, then this is done in two message tree fields, one which stores the name, and a value child that stores the value. For example :
(0x1000000)Surname = (
(0x2000000) = 'JONES'
)
So in an XML message tree, a parent node is created when creating fields that store values. Consider the following example :
<Name><Surname>JONES</Surname><Name>
This would parse into the following XML message tree :
(0x1000000)Name = (
(0x1000000)Surname = (
(0x2000000) = 'JONES'
)
)
Is the Name field a parent only group node? The answer is NO. This is because the Name field can also have a value. For example, consider the following :
<Name>BOB<Surname>JONES</Surname><Name>
This would parse into the following message tree :
(0x1000000)Name = (
(0x2000000) = 'BOB'
(0x1000000)Surname = (
(0x2000000) = 'JONES'
)
)
As can be seen, Name is not a parent only node since it can have a value.
What these examples are trying to show is that in XML, there is no such thing as a parent only node. In the MRM message tree there is such a concept as a parent tree node, and this CANNOT have a value set in it. Therefore it implicitly has a NULL value.
Therefore it does not automatically follow that MRM and XML parent nodes should behave in the same manner with respect to NULL handling.
While the message tree is a logical entity that shields the user from the bitstream, the XML message tree is a different message tree that supports the needs of the XML domain.
It could be argued that although a container node is capable of being a parent and having its own value, at the time of querying we know whether it has a value or not. We would agree with this, and if no value children were found for the tag, then it would be more consistent if this returned NULL. We have previously raised this issue with product architects and they were also in agreement with us. However it was decided that, although inconsistent, there was no actual requirement for the XML domain to report NULL values. Ie the XML parser never creates a NULL value itself, and the XML writer can currently handle a NULL value and writes the empty tag. So the only case left to cater for would be for those users that manually insert their own explicit NULL values and then want to query against them. The product architects did take this information on board and whilst implementing the new XMLNS domain in V5, this parser was given the consistent behaviour. Ie, if an XMLNS message tree field does not have a value child then it will return a NULL value. However, the XML domain will not be changed to match this behaviour.
-------------------------------------------
best regards
Norbert |
|
| Back to top |
|
|
| Duke |
| Posted: Mon Jun 19, 2006 12:26 am Post subject: |
|
|
Apprentice
Joined: 09 Mar 2004
Posts: 49
Location: Belgium
|
For my knowledge, what does means PRB?
Where can I found the article PRB #2651?
_________________
Pierre Richelle
Engineer
IBM Certified MQSeries Developper V5.3
IBM Certified WMQ Administration V6 |
|
| Back to top |
|
|
| nvogt |
| Posted: Mon Jun 19, 2006 12:30 am Post subject: |
|
|
Novice
Joined: 27 Apr 2006
Posts: 11
Location: Aachen, Germany
|
IBM calls it PRB, i have posted it above
regards
Norbert |
|
| Back to top |
|
|
| torryramesh |
| Posted: Tue Jun 20, 2006 12:54 am Post subject: |
|
|
Novice
Joined: 06 Aug 2004
Posts: 15
|
hi nvogt,
Thanks for responding.
The explanation given in PRB #2651 with illustrative examples is pretty elaborate and convincing. But in our scenario, the result of the IS NULL does not return TRUE rather it returns a NULL as you can see in the trace above.
Any thoughts??
Thanks |
|
| Back to top |
|
|
| torryramesh |
| Posted: Tue Jun 20, 2006 12:56 am Post subject: |
|
|
Novice
Joined: 06 Aug 2004
Posts: 15
|
hi nvogt,
Thanks for responding.
The explanation given in PRB #2651 with illustrative examples is pretty elaborate and convincing. But in our scenario, the result of the IS NULL does not return TRUE rather it returns a NULL as you can see in the trace above.
Any thoughts??
Thanks |
|
| Back to top |
|
|
| torryramesh |
| Posted: Tue Jun 20, 2006 12:58 am Post subject: |
|
|
Novice
Joined: 06 Aug 2004
Posts: 15
|
hi nvogt,
Thanks for responding.
The explanation given in PRB #2651 with illustrative examples is pretty elaborate and convincing. But in our scenario, the result of the IS NULL does not return TRUE rather it returns a NULL as you can see in the trace above.
Any thoughts??
Thanks |
|
| Back to top |
|
|
| torryramesh |
| Posted: Tue Jun 20, 2006 8:38 pm Post subject: |
|
|
Novice
Joined: 06 Aug 2004
Posts: 15
|
Apologies for posting the reply thrice. I had some problems while submitting the reply.
I reviewed the trace again and found that the IS NULL check actually retunrs TRUE for the parent element (PIX).
Apologies for this too.
Thanks everyone. |
|
| Back to top |
|
|
|
|
