Author |
Message
|
kavitak |
Posted: Thu Oct 11, 2007 3:59 am Post subject: |
|
|
Newbie
Joined: 11 Oct 2007 Posts: 4
|
Hi All,
We are using MQSI 2.1 and WMQ 6.0
I have a requirement to read an BLOB message and am having problems. The message that I place appears to be correct in length and format but in all instances as soon as I go near the MRM parser it gives the following error.
2592 ConversionException BIP5505E: Data conversion failed: data invalid.
Type of data being read : 'packed decimal, no sign found '
Data : '0x4040'
A data conversion during reading or writing of a message failed because the input data was invalid for the output data type.
Check that the message model is correct. Review previous messages for details of the message set and message type.
Check that the processed message is of the expected format and type.
I read the message as BLOB and then converting it using a ResetContentDescriptor node. Then the fields are transformed using CAST function.
The element for which this error is thrown is having definition as SV999 Usage COMP3 and Length as 2 bytes.
Can any one help on this issue.
Thanks in anticipation
Kavita _________________ Use what talents you possess; The woods would be very silent if no birds sang there except those that sang best."
- William Blake |
|
Back to top |
|
 |
Vitor |
Posted: Thu Oct 11, 2007 4:10 am Post subject: |
|
|
 Grand High Poobah
Joined: 11 Nov 2005 Posts: 26093 Location: Texas, USA
|
It's probably better to start a new thread and refer to this than add a post to a year-old thread.
kavitak wrote: |
We are using MQSI 2.1 and WMQ 6.0 |
v2.1 is out of support and not very good anyway. Upgrade.
kavitak wrote: |
The message that I place appears to be correct in length and format but in all instances as soon as I go near the MRM parser it gives the following error. |
So it probably doesn't actually match the message set then.
kavitak wrote: |
I read the message as BLOB and then converting it using a ResetContentDescriptor node. Then the fields are transformed using CAST function. |
Why? Why not read it in as the correct format? And where does the CAST come in? _________________ Honesty is the best policy.
Insanity is the best defence. |
|
Back to top |
|
 |
jefflowrey |
Posted: Thu Oct 11, 2007 4:13 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002 Posts: 19981
|
You're probably doing everything entirely wrong.
You should be working on v6, not 2.1. Any new development on 2.1 is a waste of time, as you're already out of support. Any new development on v5 should be passed on in favor of v6, as well. v5 will go out of support in a bit, and any v5 environments should be in process of migration so as to be in PRODUCTION on v6 (or 6.1) before v5 goes out of support.
You should not be doing any parsing using CAST if you are using MRM. MRM should convert any data into the correct data type.
You also should have started a new thread, with this NEW question, rather than sticking it in someone else's thread.
Your actual problem, that you're actually asking about, is that your message data does not match your model. You either need to fix your model or fix yoru data. _________________ I am *not* the model of the modern major general. |
|
Back to top |
|
 |
kavitak |
Posted: Thu Oct 11, 2007 5:24 am Post subject: I read the message as BLOB and then converting it using a Re |
|
|
Newbie
Joined: 11 Oct 2007 Posts: 4
|
Hi All,
I am not able to creat new topic, so submitted the issue here.
Please find below the code am using.
DECLARE AMTFEE DECIMAL;
SET AMTFEE = CAST("InputRoot"."MRM"."FEES" AS DECIMAL(4,3));
IF ( AMTFEE >= 0 ) THEN
SET "OutputRoot"."XML"."Envelope"."Message"."BodyBlock"."GROUP1"."FEES" = CAST ( AMTFEE AS CHAR ) || ' ';
ELSE
SET "OutputRoot"."XML"."Envelope"."Message"."BodyBlock"."GROUP1"."FEES" = AMTFEE;
END IF;
Thanks in anticipation.
Kavita _________________ Use what talents you possess; The woods would be very silent if no birds sang there except those that sang best."
- William Blake |
|
Back to top |
|
 |
Vitor |
Posted: Thu Oct 11, 2007 6:27 am Post subject: Re: I read the message as BLOB and then converting it using |
|
|
 Grand High Poobah
Joined: 11 Nov 2005 Posts: 26093 Location: Texas, USA
|
kavitak wrote: |
I am not able to creat new topic, so submitted the issue here. |
I'm alarmed to hear that - what happened when you tried?
I've split the topic for you.  _________________ Honesty is the best policy.
Insanity is the best defence. |
|
Back to top |
|
 |
Vitor |
Posted: Thu Oct 11, 2007 6:30 am Post subject: Re: I read the message as BLOB and then converting it using |
|
|
 Grand High Poobah
Joined: 11 Nov 2005 Posts: 26093 Location: Texas, USA
|
kavitak wrote: |
Please find below the code am using.
DECLARE AMTFEE DECIMAL;
SET AMTFEE = CAST("InputRoot"."MRM"."FEES" AS DECIMAL(4,3));
IF ( AMTFEE >= 0 ) THEN
SET "OutputRoot"."XML"."Envelope"."Message"."BodyBlock"."GROUP1"."FEES" = CAST ( AMTFEE AS CHAR ) || ' ';
ELSE
SET "OutputRoot"."XML"."Envelope"."Message"."BodyBlock"."GROUP1"."FEES" = AMTFEE;
END IF; |
You've still not explained why you're a) using obsolete software b) how you can be certain the message set matches the data c) why you're not reading the original message with the message set _________________ Honesty is the best policy.
Insanity is the best defence. |
|
Back to top |
|
 |
EddieA |
Posted: Thu Oct 11, 2007 9:48 am Post subject: |
|
|
 Jedi
Joined: 28 Jun 2001 Posts: 2453 Location: Los Angeles
|
BTW x'40' is a SPACE.
Cheers, _________________ Eddie Atherton
IBM Certified Solution Developer - WebSphere Message Broker V6.1
IBM Certified Solution Developer - WebSphere Message Broker V7.0 |
|
Back to top |
|
 |
fjb_saper |
Posted: Thu Oct 11, 2007 2:40 pm Post subject: |
|
|
 Grand High Poobah
Joined: 18 Nov 2003 Posts: 20756 Location: LI,NY
|
EddieA wrote: |
BTW x'40' is a SPACE.
Cheers, |
In EBCDIC it is in ASCII it would be x'20' _________________ MQ & Broker admin |
|
Back to top |
|
 |
kavitak |
Posted: Thu Oct 11, 2007 10:56 pm Post subject: |
|
|
Newbie
Joined: 11 Oct 2007 Posts: 4
|
I have to use this version of software only as this is existing one and this is gonna get upgraded in next year. So I really can not change this from my end as of now.
The data am using is working for other COMP 3 fields (S9V999) but not working for this field SV999. So I believe this data is correct.
I have defined the field in message set as Packed decimal and length of 2 bytes which is similar to other existing COMP3 fields which are working fine.
For S9V99 which is working correcly.
Data type Packed decimal
The actual length in message set is 2 and the virtual decimal point position is 2.
The CAST operation is done for unpacking the data from 2 bytes.
Please ignore the next 2 lines code.
Consider only following part.
DECLARE AMTFEE DECIMAL;
SET AMTFEE = CAST("InputRoot"."MRM"."FEES" AS DECIMAL(4,3));
I believe the COMP3 fields actual bytes are calculated as following.
For S9V99
(3+1)/2 = 2
where 1 byte is for sign
For SV999
(3+1)/2 = 2
again where 1 byte is for sign
Let me know if you need more details on this. _________________ Use what talents you possess; The woods would be very silent if no birds sang there except those that sang best."
- William Blake |
|
Back to top |
|
 |
Bill.Matthews |
Posted: Fri Oct 12, 2007 6:47 am Post subject: |
|
|
 Master
Joined: 23 Sep 2003 Posts: 232 Location: IBM (Retired)
|
The problem is that the data in the input is not a packed decimal field!
If the CCSID for the input is EBCDIC then the field contains two blanks.
If the CCSID is ASCII, the field is pure junk.
A two byte signed packed decimal field is going to start with one of the following in the first 4 bits - (in EBCDIC) - a F or a C - positive or a D for negative. A '4" is not a sign.
Hence the error message you gave in your initial posting:
2592 ConversionException BIP5505E: Data conversion failed: data invalid.
Type of data being read : 'packed decimal, no sign found '
Data : '0x4040'
What has probably happened is that the COBOL program that generated the message did not bother to initialize that field since it was not using it. This is not unknown with COBOL programs and programmers.
A quick way to do do some checking is to take a copy of the message and display it with RFHUTIL and, with the COBOL copybook, as to see it in COBOL.
The odds are very high that you will find additional fields later on that are also dirty. _________________ Bill Matthews |
|
Back to top |
|
 |
jefflowrey |
Posted: Fri Oct 12, 2007 7:50 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002 Posts: 19981
|
It's likely initialized, but to SPACES rather than ZEROS. _________________ I am *not* the model of the modern major general. |
|
Back to top |
|
 |
|