Problem unpacking field 48 (java.lang.NegativeArraySizeException)

Thierry Randrianiriana

unread,

Apr 4, 2012, 11:36:02 AM4/4/12

to jpos-...@googlegroups.com

Hello,

I'm running an ISOServer and I got error when receiving requests.

<iso-exception>
      org.jpos.iso.IFA_LLLCHAR: Problem unpacking field 48 (java.lang.NegativeArraySizeException) unpacking field=48, consumed=141
      org.jpos.iso.ISOException: org.jpos.iso.IFA_LLLCHAR: Problem unpacking field 48 (java.lang.NegativeArraySizeException) unpacking field=48, consumed=141
    at org.jpos.iso.ISOBasePackager.unpack(ISOBasePackager.java:265)
    at org.jpos.iso.ISOMsg.unpack(ISOMsg.java:420)
    at org.jpos.iso.BaseChannel.unpack(BaseChannel.java:902)
    at org.jpos.iso.BaseChannel.receive(BaseChannel.java:670)
    at org.jpos.iso.ISOServer$Session.run(ISOServer.java:130)
    at org.jpos.util.ThreadPool$PooledThread.run(ThreadPool.java:72)
</iso-exception>

I can reproduce the problem with :

public class UnpackTest {

    public static void main(String[] args) throws Exception {
        String msg = "0200E238000500A1800000000000040000001226133241066500000004041631400000431631400404D0000000000000000000TSTXXXX BALANCE ENQUIRY                         022THIERRY RANDRIANIRIANA9691115791590012 ";
        ISOMsg m = new ISOMsg();

        m.setPackager(new ISO87APackager());
        m.unpack(msg.getBytes());
        m.dump(System.out, " ");
    }
}

Exception in thread "main" org.jpos.iso.ISOException: org.jpos.iso.IFA_LLLCHAR: Problem unpacking field 48 (java.lang.NegativeArraySizeException) unpacking field=48, consumed=141
    at org.jpos.iso.ISOBasePackager.unpack(ISOBasePackager.java:265)
    at org.jpos.iso.ISOMsg.unpack(ISOMsg.java:420)
    at mg.test.UnpackTest.main(UnpackTest.java:23)

Any help or advice is welcome, I'm using the lastest jposee with jpos 1.8.5 .

Thank you in advance.

Best Regards,

--
Thierry Randrianiriana

Alejandro Revilla

unread,

Apr 4, 2012, 2:46:53 PM4/4/12

to jpos-...@googlegroups.com

Without having access to your specs, I'm just guessing here, but it seems that field 30 is 10 bytes instead of 9, and field 43 is 48 bytes instead of 40. I'd suggest to:

Copy iso87ascii.xml to a file (i.e. mypackager.xml).

Edit field 30 and 43 according to my comment above.

Use as packager GenericPackager("path/to/your/mypackager.xml");

That should give you something like this:

</isomsg>

-
@apr

--
jPOS is licensed under AGPL - free for community usage for your open-source project. Licenses are also available for commercial usage.
Please support jPOS, contact: sa...@jpos.org

You received this message because you are subscribed to the "jPOS Users" group.
Please see http://jpos.org/wiki/JPOS_Mailing_List_Readme_first
To post to this group, send email to jpos-...@googlegroups.com
To unsubscribe, send email to jpos-users+...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/jpos-users

Thierry Randrianiriana

unread,

Apr 5, 2012, 1:09:24 AM4/5/12

to jpos-...@googlegroups.com

Hello,

I modified the UnpackTest class and the packager.xml, and it gives the
same result than yours.
But the target result should be as below without changing the packager.xml:

I generate the message with jpos lib and there is a difference on the field 32 :

|0200E238000500A1800000000000040000001226133241066500000004041631400000431631400404D0000000000000000000TSTXXXX
BALANCE ENQUIRY 022THIERRY
RANDRIANIRIANA9691115791590012 |

|0200E238000500A1800000000000040000001226133241066500000004041631400000431631400404D000000001100000000000TSTXXXX
BALANCE ENQUIRY 022THIERRY
RANDRIANIRIANA9691115791590012|

Thanks for the help!

Best Regards,

--
Thierry Randrianiriana

Mark Salter

unread,

Apr 5, 2012, 2:39:17 AM4/5/12

to jpos-...@googlegroups.com

On 05/04/2012 06:09, Thierry Randrianiriana wrote:

> But the target result should be as below without changing the packager.xml:

The Packager used defines the structure and content of the fields in the
message. The Packager *must* therefore match the specification and you
will need to ensure that the Packager (or Generic definition) matches
the specification of the interface you want to connect with.

Selecting or making a Packager that matches the specification is almost
the first task you should do; the first being to acquire the
documentation needed :-) .

>
> <isomsg>
> <field id="0" value="0200"/>
> <field id="2" value="261332___0665"/>
> <field id="3" value="000000"/>
> <field id="7" value="0404163140"/>
> <field id="11" value="000043"/>
> <field id="12" value="163140"/>
> <field id="13" value="0404"/>
> <field id="30" value="D00000000"/>
> <field id="32" value="00000000000"/>
> <field id="41" value="TSTXXXX "/>
> <field id="43" value="BALANCE ENQUIRY "/>
> <field id="48" value="THIERRY RANDRIANIRIANA"/>
> <field id="49" value="969"/>
> <field id="102" value="15791590012"/>
> </isomsg>
>
> I generate the message with jpos lib and there is a difference on the field 32 :

How would you suggest we guess what each of these 'raw' messages are and
which is produced with jPOS?
Anyway...

>
> |0200E238000500A1800000000000040000001226133241066500000004041631400000431631400404D0000000000000000000TSTXXXX
> BALANCE ENQUIRY 022THIERRY
> RANDRIANIRIANA9691115791590012 |

Let's assume that the one below is out of jPOS, since the field 32 has a
length (11) present!

> |0200E238000500A1800000000000040000001226133241066500000004041631400000431631400404D000000001100000000000TSTXXXX
> BALANCE ENQUIRY 022THIERRY
> RANDRIANIRIANA9691115791590012|

Check the specification for the interface you want to talk to and pay
careful attention to it's definition of field 32...

... does your field 32 include any variable length, or is it fixed
length 11 bytes?

Now you have the documentation to hand and open, check that all the
field definitions precisely match the Packager you have chosen.
Yes it is a dull job, but an essential one I suggest you do and
certainly one that might well save you problems in the future.

--
Mark

Thierry Randrianiriana

unread,

Apr 5, 2012, 3:57:15 AM4/5/12

to jpos-...@googlegroups.com

Hi Mark,

On Thu, Apr 5, 2012 at 9:39 AM, Mark Salter <marks...@talktalk.net> wrote:
> On 05/04/2012 06:09, Thierry Randrianiriana wrote:
>
>> But the target result should be as below without changing the packager.xml:
> The Packager used defines the structure and content of the fields in the
> message. The Packager *must* therefore match the specification and you
> will need to ensure that the Packager (or Generic definition) matches
> the specification of the interface you want to connect with.
>
> Selecting or making a Packager that matches the specification is almost
> the first task you should do; the first being to acquire the
> documentation needed :-) .
>

Yes, you're right, it was the first thing I've done ;-) . I checked
and rechecked all fields against the documentation but I always get
this error.
I'm not the developer of the client side and it's the reason of this post.

>>
>> <isomsg>
>> <field id="0" value="0200"/>
>> <field id="2" value="261332___0665"/>
>> <field id="3" value="000000"/>
>> <field id="7" value="0404163140"/>
>> <field id="11" value="000043"/>
>> <field id="12" value="163140"/>
>> <field id="13" value="0404"/>
>> <field id="30" value="D00000000"/>
>> <field id="32" value="00000000000"/>
>> <field id="41" value="TSTXXXX "/>
>> <field id="43" value="BALANCE ENQUIRY "/>
>> <field id="48" value="THIERRY RANDRIANIRIANA"/>
>> <field id="49" value="969"/>
>> <field id="102" value="15791590012"/>
>> </isomsg>
>>
>> I generate the message with jpos lib and there is a difference on the field 32 :
> How would you suggest we guess what each of these 'raw' messages are and
> which is produced with jPOS?
> Anyway...

Sorry, I'm not the developer of the client side, I guess also ...
after Alejandro answer.
I forwarded the problem to the client developer .

>>
>> |0200E238000500A1800000000000040000001226133241066500000004041631400000431631400404D0000000000000000000TSTXXXX
>> BALANCE ENQUIRY 022THIERRY
>> RANDRIANIRIANA9691115791590012 |
> Let's assume that the one below is out of jPOS, since the field 32 has a
> length (11) present!
>> |0200E238000500A1800000000000040000001226133241066500000004041631400000431631400404D000000001100000000000TSTXXXX
>> BALANCE ENQUIRY 022THIERRY
>> RANDRIANIRIANA9691115791590012|
> Check the specification for the interface you want to talk to and pay
> careful attention to it's definition of field 32...
>
> ... does your field 32 include any variable length, or is it fixed
> length 11 bytes?
>

Mine is :

> Now you have the documentation to hand and open, check that all the

> field definitions precisely match the Packager2 you have chosen.

> Yes it is a dull job, but an essential one I suggest you do and
> certainly one that might well save you problems in the future.
>

Thank you for answer :-)

chhil

unread,

Apr 5, 2012, 4:39:23 AM4/5/12

to jpos-...@googlegroups.com

Hello,

Field 32 is defined as LLNUM in the packager. If you look at the raw data there is no length of field 32 , it seems to be fixed, change the IFA_LL to IFA_Numeric, this should help you move forward and you will encounter further exceptions :)

-chhil

Thierry Randrianiriana

unread,

Apr 5, 2012, 10:19:50 AM4/5/12

to jpos-...@googlegroups.com

Hi,

Thanks guys, you rock!

--
Thierry Randrianiriana

chi...@gmail.com

unread,

Apr 5, 2012, 11:47:08 AM4/5/12

to jpos-...@googlegroups.com

Glad it worked out for you.

-chhil
Sent from BlackBerry® on Airtel

Mark Salter

unread,

Apr 5, 2012, 4:31:33 PM4/5/12

to jpos-...@googlegroups.com

On 05/04/2012 08:57, Thierry Randrianiriana wrote:

>> Selecting or making a Packager that matches the specification is almost
>> the first task you should do; the first being to acquire the
>> documentation needed :-) .
>>
>
> Yes, you're right, it was the first thing I've done ;-) . I checked
> and rechecked all fields against the documentation but I always get
> this error.

As Chhil has suggested, you missed at least one field, I would check
again, bearing in mind to check the fixed length fields and the variable
length ones.

If you have missed any others, checking now might save you all sorts of
pain later :-)

--
Mark

Reply all

Reply to author

Forward