Question regarding error received on 0200 TEST message

201 views
Skip to first unread message

Melinda

unread,
Aug 5, 2013, 11:07:22 AM8/5/13
to jpos-...@googlegroups.com
I am in the middle of Pulse Certification 13.2 and have a question on the error I got below on an 0200 message I received from Pulse.  The data types appear to be correct per the log below and what is in my Pulse packager so I'm not understanding WHY the value on 52 or 53 is getting an ArrayIndexOutOfBoundsException. 

Any help/direction and another set of eyes would be greatly appreciated.  Regards.

When I converted the HEX value this is what I got and I apparently do not see the problem:

0200▓:@☺(í?B       ►010000000000002000080513465300007008465308050805601110223456
7890371111111100001111=14011010000011100000321700000046TERM05  1301 MCKINNEY STE
 2500 HOUSTON      TXUS004ABCD84011111111111111110101000010002022B2L30ATMPULINTL
11     028NI24PS20ID16


Here is the LOG:

<log realm="" at="Mon Aug 05 08:53:05 CDT 2013.625">
  <unpack>
    30323030B23A400128A13F420000000000000010303130303030303030303030303032303030303830353133343635333030303037303038343635333038303530383035363031313130323233343536373839303337343237343738313130303030313036303D31343031313031303030303036323230303030303332313730303030303034365445524D3035202031333031204D434B494E4E455920535445203235303020484F5553544F4E2020202020205458555330303441424344383430313131313131313131313131313131313031303130303030313030303230323242324C333041544D50554C494E544C313120202020203032384E493234505332304944313620202020202020202020202020202020
    <bitmap>{1, 3, 4, 7, 11, 12, 13, 15, 18, 32, 35, 37, 41, 43, 48, 51, 52, 53, 54, 55, 56, 58, 63, 124}</bitmap>
    <unpack fld="3" packager="org.jpos.iso.IFA_NUMERIC">
      <value>010000</value>
    </unpack>
    <unpack fld="4" packager="org.jpos.iso.IFA_NUMERIC">
      <value>000000002000</value>
    </unpack>
    <unpack fld="7" packager="org.jpos.iso.IFA_NUMERIC">
      <value>0805134653</value>
    </unpack>
    <unpack fld="11" packager="org.jpos.iso.IFA_NUMERIC">
      <value>000070</value>
    </unpack>
    <unpack fld="12" packager="org.jpos.iso.IFA_NUMERIC">
      <value>084653</value>
    </unpack>
    <unpack fld="13" packager="org.jpos.iso.IFA_NUMERIC">
      <value>0805</value>
    </unpack>
    <unpack fld="15" packager="org.jpos.iso.IFA_NUMERIC">
      <value>0805</value>
    </unpack>
    <unpack fld="18" packager="org.jpos.iso.IFA_NUMERIC">
      <value>6011</value>
    </unpack>
    <unpack fld="32" packager="org.jpos.iso.IFA_LLNUM">
      <value>2234567890</value>
    </unpack>
    <unpack fld="35" packager="org.jpos.iso.IFA_LLNUM">
      <value>1111111100001111=14011010000011100000</value>
    </unpack>
    <unpack fld="37" packager="org.jpos.iso.IF_CHAR">
      <value>321700000046</value>
    </unpack>
    <unpack fld="41" packager="org.jpos.iso.IF_CHAR">
      <value>TERM05  </value>
    </unpack>
    <unpack fld="43" packager="org.jpos.iso.IF_CHAR">
      <value>1301 MCKINNEY STE 2500 HOUSTON      TXUS</value>
    </unpack>
    <unpack fld="48" packager="org.jpos.iso.IFA_LLLCHAR">
      <value>ABCD</value>
    </unpack>
    <unpack fld="51" packager="org.jpos.iso.IF_CHAR">
      <value>840</value>
    </unpack>
    <unpack fld="52" packager="org.jpos.iso.IF_CHAR">
      <value>1111111111111111</value>
    </unpack>
    <unpack fld="53" packager="org.jpos.iso.IFA_NUMERIC">
      <value>0101000010002022</value>
    </unpack>
    <iso-exception>
      org.jpos.iso.IFA_LLLCHAR: Problem unpacking field 54
      <nested-exception>
      java.lang.ArrayIndexOutOfBoundsException: 278
at org.jpos.iso.AsciiInterpreter.uninterpret(AsciiInterpreter.java:88)
at org.jpos.iso.ISOStringFieldPackager.unpack(ISOStringFieldPackager.java:204)
at org.jpos.iso.ISOBasePackager.unpack(ISOBasePackager.java:229)
at common.jpos.PulsePackager.unpack(PulsePackager.java:245)
at org.jpos.iso.ISOMsg.unpack(ISOMsg.java:322)
at common.jpos.InternalISOMsg.unpack(InternalISOMsg.java:2070)
at com.sharpbancsystems.ATM.channel.SwitchChannel.blockUntilReceiveMessage(SwitchChannel.java:1361)
at com.sharpbancsystems.ATM.channel.ReceiveQueuer.run(ReceiveQueuer.java:96)
at java.lang.Thread.run(Thread.java:662)
      </nested-exception>
      org.jpos.iso.ISOException: org.jpos.iso.IFA_LLLCHAR: Problem unpacking field 54 (java.lang.ArrayIndexOutOfBoundsException: 278)
at org.jpos.iso.ISOStringFieldPackager.unpack(ISOStringFieldPackager.java:209)
at org.jpos.iso.ISOBasePackager.unpack(ISOBasePackager.java:229)
at common.jpos.PulsePackager.unpack(PulsePackager.java:245)
at org.jpos.iso.ISOMsg.unpack(ISOMsg.java:322)
at common.jpos.InternalISOMsg.unpack(InternalISOMsg.java:2070)
at com.sharpbancsystems.ATM.channel.SwitchChannel.blockUntilReceiveMessage(SwitchChannel.java:1361)
at com.sharpbancsystems.ATM.channel.ReceiveQueuer.run(ReceiveQueuer.java:96)
at java.lang.Thread.run(Thread.java:662)
Nested:java.lang.ArrayIndexOutOfBoundsException: 278
at org.jpos.iso.AsciiInterpreter.uninterpret(AsciiInterpreter.java:88)
at org.jpos.iso.ISOStringFieldPackager.unpack(ISOStringFieldPackager.java:204)
at org.jpos.iso.ISOBasePackager.unpack(ISOBasePackager.java:229)
at common.jpos.PulsePackager.unpack(PulsePackager.java:245)
at org.jpos.iso.ISOMsg.unpack(ISOMsg.java:322)
at common.jpos.InternalISOMsg.unpack(InternalISOMsg.java:2070)
at com.sharpbancsystems.ATM.channel.SwitchChannel.blockUntilReceiveMessage(SwitchChannel.java:1361)
at com.sharpbancsystems.ATM.channel.ReceiveQueuer.run(ReceiveQueuer.java:96)
at java.lang.Thread.run(Thread.java:662)
    </iso-exception>
    <iso-exception>
      org.jpos.iso.IFA_LLLCHAR: Problem unpacking field 54
      <nested-exception>
      java.lang.ArrayIndexOutOfBoundsException: 278
at org.jpos.iso.AsciiInterpreter.uninterpret(AsciiInterpreter.java:88)
at org.jpos.iso.ISOStringFieldPackager.unpack(ISOStringFieldPackager.java:204)
at org.jpos.iso.ISOBasePackager.unpack(ISOBasePackager.java:229)
at common.jpos.PulsePackager.unpack(PulsePackager.java:245)
at org.jpos.iso.ISOMsg.unpack(ISOMsg.java:322)
at common.jpos.InternalISOMsg.unpack(InternalISOMsg.java:2070)
at com.sharpbancsystems.ATM.channel.SwitchChannel.blockUntilReceiveMessage(SwitchChannel.java:1361)
at com.sharpbancsystems.ATM.channel.ReceiveQueuer.run(ReceiveQueuer.java:96)
at java.lang.Thread.run(Thread.java:662)
      </nested-exception>
      org.jpos.iso.ISOException: org.jpos.iso.IFA_LLLCHAR: Problem unpacking field 54 (java.lang.ArrayIndexOutOfBoundsException: 278)
at org.jpos.iso.ISOStringFieldPackager.unpack(ISOStringFieldPackager.java:209)
at org.jpos.iso.ISOBasePackager.unpack(ISOBasePackager.java:229)
at common.jpos.PulsePackager.unpack(PulsePackager.java:245)
at org.jpos.iso.ISOMsg.unpack(ISOMsg.java:322)
at common.jpos.InternalISOMsg.unpack(InternalISOMsg.java:2070)
at com.sharpbancsystems.ATM.channel.SwitchChannel.blockUntilReceiveMessage(SwitchChannel.java:1361)
at com.sharpbancsystems.ATM.channel.ReceiveQueuer.run(ReceiveQueuer.java:96)
at java.lang.Thread.run(Thread.java:662)
Nested:java.lang.ArrayIndexOutOfBoundsException: 278
at org.jpos.iso.AsciiInterpreter.uninterpret(AsciiInterpreter.java:88)
at org.jpos.iso.ISOStringFieldPackager.unpack(ISOStringFieldPackager.java:204)
at org.jpos.iso.ISOBasePackager.unpack(ISOBasePackager.java:229)
at common.jpos.PulsePackager.unpack(PulsePackager.java:245)
at org.jpos.iso.ISOMsg.unpack(ISOMsg.java:322)
at common.jpos.InternalISOMsg.unpack(InternalISOMsg.java:2070)
at com.sharpbancsystems.ATM.channel.SwitchChannel.blockUntilReceiveMessage(SwitchChannel.java:1361)
at com.sharpbancsystems.ATM.channel.ReceiveQueuer.run(ReceiveQueuer.java:96)
at java.lang.Thread.run(Thread.java:662)
    </iso-exception>
  </unpack>
</log>

chhil

unread,
Aug 5, 2013, 12:43:52 PM8/5/13
to jpos-...@googlegroups.com
Just based on some experience with Pulse , "022B2L30ATMPULINTL11 "
is data in field 63, 022 is the LLL.
Which means your previous field formatters are incorrect as the 022 is
absorbed in a previous field. Verify the field formatters of field 53
and other identified bits before field 63.

-chhil
> --
> --
> 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
>
> ---
> You received this message because you are subscribed to the Google Groups
> "jPOS Users" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to jpos-users+...@googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.
>
>

Mark Salter

unread,
Aug 5, 2013, 4:39:27 PM8/5/13
to jpos-...@googlegroups.com
On 05/08/2013 16:07, Melinda wrote:
> I am in the middle of Pulse Certification 13.2 and have a question on
> the error I got below on an 0200 message I received from Pulse. The
> data types appear to be correct per the log below and what is in my
> Pulse packager so I'm not understanding WHY the value on 52 or 53 is
> getting an ArrayIndexOutOfBoundsException.
Neither 52 nor 53 is getting an exception - they unpack'd data. It is
54 that is not being unpacked cleanly, and it is because of the length
of 53 - please check that.
>
> Any help/direction and another set of eyes would be greatly appreciated.
> Regards.
You have to do the first things first. I'm certain to have already told
you to check each and every field that you will receive (and those you
might) in your selected/built packager to the specification. Do this
now - honestly you don;t appear to have so have so far?
[snip]
.
.
.

> <unpack fld="52" packager="org.jpos.iso.IF_CHAR">
> <value>1111111111111111</value>
> </unpack>
This filed looks the right length although the data is unlikely a PIN
Block (although it could be).

> <unpack fld="53" packager="org.jpos.iso.IFA_NUMERIC">
> <value>0101000010002022</value>
> </unpack>
Here things go wrong because you appear (based on Chhil's input) to have
taken too much data into 53...

> <iso-exception>
> org.jpos.iso.IFA_LLLCHAR: Problem unpacking field 54
> <nested-exception>
> java.lang.ArrayIndexOutOfBoundsException: 278
Boom 54 blows up because your packager has determined that field 54 is
278 bytes (decimal long)...

... decimal 278 = x'0116'...

is there any x'0116' in the raw message received? If not perhaps the
conversion of the length bytes B2L and conversion to decimal has gone
odd (it is invalid bcd/hex data after all).

Please check the field 53 and *then* all the rest to save your self
problems later.


--
Mark

Mark Salter

unread,
Aug 5, 2013, 4:46:37 PM8/5/13
to jpos-...@googlegroups.com
PS...

On 05/08/2013 16:07, Melinda wrote:
> at common.jpos.PulsePackager.unpack(PulsePackager.java:245)
> at common.jpos.InternalISOMsg.unpack(InternalISOMsg.java:2070)
> com.sharpbancsystems.ATM.channel.SwitchChannel.blockUntilReceiveMessage(SwitchChannel.java:1361)


Is this sharpbancsystems.com system even using 'our' jPOS code?

I have to hope that 'Pulse' are not reading this mailing list - they
would certainly doubt 'your' solution is ready for certification (unless
you are paying them to conduct it).

:-(

--
Mark

chhil

unread,
Aug 6, 2013, 2:19:49 AM8/6/13
to jpos-...@googlegroups.com
Mark,

They use the free community jpos 1.5 version with quite a bit of
proprietary wrappers. There has been chatter about them upgrading to a
newer version with a commercial license.

From a pulse cert perspective, I think as long as they get a expected
response they will certify you (a bsh script responding would suffice
;))

-chhil

Melinda

unread,
Aug 6, 2013, 11:02:39 AM8/6/13
to jpos-...@googlegroups.com
As I've communicated previously, It is my understanding that we will be upgrading as soon as we get past the Discover certification which we're still in unfortunately. 

I found that Pulse is no longer supporting FIELD 53 in 13.2 or in 13.1 for that matter.  We've apparently always had this issue and it has never been corrected in looking at the OLDER logs. Per Pulse, they have not been sending us anything in FIELD 53 but in 54. 

At any rate, in version 1.5.0, the FieldPackager was setup as an array.  In the constructor of our PulsePackager java class we're utilizing the org.jpos.iso.ISOFieldPackager.setFieldPackager(_isoFieldPackager) and passing in the array of the defined fields for Pulse. Since Field 53 is no longer supported by Pulse and we have it in the array, what is the best way to setFieldPackager without FIELD 53 and NOT THROWING the remaining elements of the array out of alignment.  I had tried just commenting out the element for FIELD 53 in the array but it knocked everything out of alignment whereby FIELD 63 is now an IFA_BINARY data type when it should still be IFA_LLLCHAR?  Hope this makes sense.

Any suggestions/direction would be appreciated.  Thank you.   

chhil

unread,
Aug 6, 2013, 11:24:18 AM8/6/13
to jpos-...@googlegroups.com
The beauty of the way bitmapped packagers work is that if the bitmap
does not have the bit for an element set it will not unpack it. So
your bitmap contains bit 53 and hence its trying to unpack it.
So either
1. The message coming in has bit 53 set or
2. Your bitmap packager definition is incorrect.
-chhil

Melinda

unread,
Aug 6, 2013, 1:36:17 PM8/6/13
to jpos-...@googlegroups.com
chhil, thanks so much for the reply.  I just spoke to our certification rep @ Pulse and she is going to confirm if it is in the bitmap of the message she is sending.  I tried just running it locally via the client simulator and got an ArrayIndexOutOfBoundsException error unpacking field 124 after I commented out FIELD 53 from the array.  When we broke down the HEX value in my original post above it did not appear that FIELD 53 was populated though it was listed in the bitmap.  Hopefully Pulse can correct that quickly.

Mark Salter

unread,
Aug 6, 2013, 6:16:35 PM8/6/13
to jpos-...@googlegroups.com
On 06/08/2013 07:19, chhil wrote:
> Mark,
>
> They use the free community jpos 1.5 version with quite a bit of
> proprietary wrappers.
I appreciate that, my worry is that we are making guesses at the problem
and our knowledge of our code...

:-)

... the actual solution might be doing anything; we could be wasting our
time even trying with the tiny view of proceeding we have.

I think I recall Melinda's predecessor (based on remembering the
repackaging of jPOS code (which I didn't think was the right way even
back then either :-) )) asking similar questions, perhaps a search of
the archive's is required (by me).

> There has been chatter about them upgrading to a
> newer version with a commercial license.
The sooner the better, but of course I understand the problems.

>
>>From a pulse cert perspective, I think as long as they get a expected
> response they will certify you (a bsh script responding would suffice
> ;))
Honestly it seems like the certifiers don't know what they are doing -
why would anyone need to confirm elsewhere if a bit map was indicating
the presence of a field or not in the message they are generating :-(
basic stuff - I would think.

My worry is that this 'certification' is dragging on and on - probably
at a cost to someone. I have to think that this solution never reaching
production grade could be a good thing, but I have no confidence that
the 'mashup' of jPOS might ever work.

As a commercial enterprise - that I presume 'sharpbancsystems' is -
delaying moving to a 'working version' of jPOS with associated support
here and commercially if needed feels like the only way. Anything else
is just playing (ultimately with people's money) and wasting time.

Anyway enough of me ranting - what do I know :-).

--
(kicks soap box back under desk - and heads to bed)
Mark

chhil

unread,
Aug 7, 2013, 3:05:56 AM8/7/13
to jpos-...@googlegroups.com
I don't think commenting the array element solves anything. The position in the array denotes the bit, so commenting the actual field 53 will just make the next element in the array field 53. However you could try replacing the field packager of field 53 with IF_NOP. This packager will not consume data and allow you to process without errors. I haven't tried this but it will probably work.
-chhil
Reply all
Reply to author
Forward
0 new messages