| |
|
RSS Feed - WebSphere MQ Support
|
RSS Feed - Message Broker Support
|
  |
|
| Java null handling - Does this sound like a defect |
« View previous topic :: View next topic » |
| Author |
Message
|
| bbakerman |
 Posted: Mon Sep 05, 2005 10:55 pm Post subject: Java null handling - Does this sound like a defect |
 |
|
Apprentice
Joined: 17 Dec 2003
Posts: 41
|
I wrote some "String" handling functions in Java to be called from ESQL
They look like this :
| Quote: |
CREATE PROCEDURE GET(in str char, in delim char, in fieldOccurence integer, in fieldCount integer) RETURNS CHAR
LANGUAGE JAVA EXTERNAL NAME "com.ibm.wbihmb.fld.FieldKit.esqlGetField";
|
The Java code itself has explcit handling of NULL parameters inside it. I actually treat NULL Java objects as empty strings, which is the semantics I want in this case.
I then wrote some ESQL code like this
| Code: |
declare str char 'field1|field2|fiedl3';
set str = 'field1|field2|fiedl3';
set str = fld.GET(str,'|',2);
set str= NULL;
set str = fld.GET(str,'|',2);
set str = fld.GET(InputRoot.BLOB.NOTHING,'|',2);
|
When I run it the first 2 calls work in that the non null and NULL values are passed in with no problem.
However the 3 call which accesses a non existant field (in this case InputRoot.BLOB.NOTHING) throws an exception. This results in the folowing error message:
| Code: |
BIP2930E A function or procedure was called but the value supplied for the 'str' parameter was of type 'NULL' but the function/procedure expects value of type 'CHARACTER'
|
How is this call
set str= NULL;
set str = fld.GET(str,'|',2);
Any different to this call
set str = fld.GET(InputRoot.BLOB.NOTHING,'|',2);
Both would seem to be NULL and the error message indicates that it is and yet its slightly different for a non existent message tree field than for character variable.
Is this a defect or a planned ESQL feature?
I am on WBI 5 CSD 5 on AIX. |
|
| Back to top |
|
 |
| bbakerman |
| Posted: Mon Sep 05, 2005 11:10 pm Post subject: |
|
|
Apprentice
Joined: 17 Dec 2003
Posts: 41
|
In fact its does seem related to a Java function at all.
I wrote an ESQL function like this
| Code: |
CREATE PROCEDURE DOGET(in str char, in delim char, in fieldOccurence integer) RETURNS CHAR
begin
return '';
end;
|
And then made a call like this
set str = DOGET(InputRoot.BLOB.NOTHING,'|',2);
and its fails with the same error exception. So its not related to calling Java at all but some ESQL feature.
Take this called for example
| Code: |
set str= NULL;
-- works
set str = DOGET(str,'|',2);
-- works
set str = DOGET(COALESCE(InputRoot.BLOB.NOTHING,''),'|',2);
-- fails with exception
set str = DOGET(COALESCE(InputRoot.BLOB.NOTHING),'|',2);
-- fails with exception
set str = DOGET(COALESCE(InputRoot.BLOB.NOTHING,NULL),'|',2);
|
How do the failing calls differ from the ones that succeed in terms of NULL handling? |
|
| Back to top |
|
|
| elvis_gn |
| Posted: Mon Sep 05, 2005 11:35 pm Post subject: |
|
|
Padawan
Joined: 08 Oct 2004
Posts: 1905
Location: Dubai
|
On first look, i felt that the third call is failing as the field itself did not exist for the reference and not that the value in it is NULL, whereas the first two work as the field "str" is NULL.
i.e if u do not declare "str" you should get the same error as that for your third call...
But this does not explain why the code in your second post does not work...u have made use of the COALESCE....
This is entirely wrong in syntax
-- fails with exception
set str = DOGET(COALESCE(InputRoot.BLOB.NOTHING),'|',2);
I got the below lines from the ESQL pdf.
The COALESCE function evaluates its parameters in order and returns the first one that is not NULL. The result is NULL if, and only if, all the aguments are NULL. The parameters can be of any scalar type, but they need not all be of the same type.
Hope u figure out the rest  |
|
| Back to top |
|
|
| mgk |
| Posted: Tue Sep 06, 2005 12:16 am Post subject: |
|
|
Padawan
Joined: 31 Jul 2003
Posts: 1642
|
Hi,
If I remember correctly their is a fix for this, but i cannot remember the APAR number. It may or may not be in V5 CSD6. If you raise a PMR with IBM service, they should be able to supply you with the fix.
regards,
MGK
_________________
MGK
The postings I make on this site are my own and don't necessarily represent IBM's positions, strategies or opinions. |
|
| Back to top |
|
|
| bbakerman |
| Posted: Tue Sep 06, 2005 4:48 pm Post subject: |
|
|
Apprentice
Joined: 17 Dec 2003
Posts: 41
|
Yes I can cofirm that its fixed in CSD6. The NULL handling is different between CSD5 and CSD6
(And yes I had the COALESCE function syntax wrong in one example)
In CSD5 this fails
set str = DOGET(InputRoot.BLOB.NOTHING,'|',2);
while in CSD6 this it works.
It seems it treats non existant message tree fields in a more NULL like manner. eg if its passed to a function that takes a CHAR then its a NULL of datatype CHAR not a NULL of data type NULL.
Its interesting that if you assign a non existant message tree ield to an ESQl variable, then it works on either CSD and whether the ESQL variable is NULL or not.
I looked in the CSD notes and found this issue perhaps related to this. Maybe they have fixed more than the APAR notes.
http://www-1.ibm.com/support/docview.wss?rs=849&context=SSKM8N&q1=IC32971&uid=swg1IC32971&loc=en_US&cs=utf-8&lang=en
| Quote: |
A BIP2430E error is generated when an attempt is made to
concatenate with an implicit NULL value.
.
The ESQL concatenation operator (||) operates on ESQL CHARACTER,
BLOB and BIT data types, and appends the value of parameter2 to
the end of parameter1 resulting in an output of the same
datatype as the input parameters. One of the restrictions of
the concatenation operator is that the two parameters must both
have the same datatype.
.
It is possible the user can specify a message tree field as one
of the parameters. If this is the case the datatype of the
parameter will be determined by the datatype of the value stored
in the message tree field. However, it is possible that the
specified message tree field may not exist in the message tree.
In this situation, the message tree evaluates to an implicit
NULL value and the concatenation operator should be able to cope
with this situation. When a NULL value is concatenated with
another value, then the result should be NULL.
.
A defect existed such that the expression could not be evaluated
and a BIP2430E error message was generated.
Problem conclusion
Because the Concatenation operator will only accept certain
datatypes, a validation check is required to ensure that the
parameters have the correct datatypes. If a non-existant
message tree field is passed as a parameter this is an implicit
NULL value that does not have a datatype and for which a
datatype cannot be determined or assumed.
.
The defect has been fixed such that if an implicit NULL is
passed to the concatenation operator the datatype does not need
to be checked because the result will be NULL regardless.
|
|
|
| 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
|
|
|
|
