JCB Track 1 unparsing data truncate ?

168 views
Skip to first unread message

Nishandan G

unread,
Dec 1, 2014, 10:50:44 PM12/1/14
to jpos-...@googlegroups.com
Hi All,

Track 1 data = [B]3541700000000010^JCB CREDIT TEST           ^1811201100000000000000704000000
as raw data from simulator = 3442333534313730303030303030303031305e4a434220435245444954205445535420202020202020202020205e31383131323031313030303030303030303030303030373034303030303030

on packager i have configured Field 45  as, /*045*/ new IFA_LLCHAR(99, "TRACK 1 DATA")

when parse the data i am getting only this portion '3569700000000010^JCB CREDIT TEST           ^18112011000000' and rest getting truncate.

Please advice me where i am wrong?

Regards,
G.Nishandan

Mark Salter

unread,
Dec 2, 2014, 6:37:23 AM12/2/14
to jpos-...@googlegroups.com
On 02/12/2014 03:50, Nishandan G wrote:
> Track 1 data = [B]3541700000000010^JCB CREDIT TEST
> ^1811201100000000000000704000000
> as raw data from simulator =
> 3442333534313730303030303030303031305e4a434220435245444954205445535420202020202020202020205e31383131323031313030303030303030303030303030373034303030303030
You have provided the wrong raw data - it does not hold the track data
above?

>
> on packager i have configured Field 45 as, /*045*/ new IFA_LLCHAR(99,
> "TRACK 1 DATA")
Does this match your simulator field 45 definition? a two character
ASCII length?
>
> when parse the data i am getting only this portion '3569700000000010^JCB
> CREDIT TEST ^18112011000000' and rest getting truncate.
How long is the track you are expecting? What does it's length look
like in the message that goes over the network?


--
Mark

chhil

unread,
Dec 2, 2014, 7:39:36 AM12/2/14
to jpos-...@googlegroups.com
Using a hex to ascii converter , your raw data 
3442333534313730303030303030303031305e4a434220435245444954205445535420202020202020202020205e31383131323031313030303030303030303030303030373034303030303030

gets converted to

4B3541700000000010^JCB CREDIT TEST           ^1811201100000000000000704000000

So it boils down to your length prepended to the data which is 4B which is decimal 75 which is correct (total 150 chars in hex raw data that you have provided).

You need to change the packager of the field to understand the length.

-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

Join us in IRC at http://webchat.freenode.net/?channels=jpos

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.
To view this discussion on the web visit https://groups.google.com/d/msgid/jpos-users/547DA420.90104%40talktalk.net.
For more options, visit https://groups.google.com/d/optout.

Mark Salter

unread,
Dec 2, 2014, 1:36:16 PM12/2/14
to jpos-...@googlegroups.com
On 02/12/2014 12:39, chhil wrote:
> So it boils down to your length prepended to the data which is 4B which
> is decimal 75 which is correct (total 150 chars in hex raw data that you
> have provided).
That's funny, I took the 'B' to be the start sentinal of the TRACK1 -
wondering why the OP thought it might be present on the message :-)

--
Mark

Nishandan G

unread,
Dec 2, 2014, 9:20:52 PM12/2/14
to jpos-...@googlegroups.com


On Tuesday, 2 December 2014 19:37:23 UTC+8, Mark Salter wrote:
On 02/12/2014 03:50, Nishandan G wrote:
> Track 1 data = [B]3541700000000010^JCB CREDIT TEST          
> ^1811201100000000000000704000000
> as raw data from simulator =
> 3442333534313730303030303030303031305e4a434220435245444954205445535420202020202020202020205e31383131323031313030303030303030303030303030373034303030303030
You have provided the wrong raw data - it does not hold the track data
above?

>
> on packager i have configured Field 45  as, /*045*/ new IFA_LLCHAR(99,
> "TRACK 1 DATA")
Does this match your simulator field 45 definition? a two character
ASCII length?

document definition says as following,
1 binary byte, then up to 76 bytes
LLVAR binary
 
>
> when parse the data i am getting only this portion '3569700000000010^JCB
> CREDIT TEST           ^18112011000000' and rest getting truncate.
How long is the track you are expecting?  What does it's length look
like in the message that goes over the network?

75 chars long, 
over the network it passes the whole length. 


--
Mark

Nishandan G

unread,
Dec 2, 2014, 9:31:21 PM12/2/14
to jpos-...@googlegroups.com
Hi Chhil,

4B ascii getting from 3442 hex,
decimal 75 getting from 4B hex which already converted as ascii from 3442 hex ?

(3442 hex  -> 4B ascii 
 4B hex -> 75 decimal)

is my understanding correct?

chhil

unread,
Dec 2, 2014, 10:16:20 PM12/2/14
to jpos-...@googlegroups.com

Hex 34 is ascii 4
Hex 42 is ascii B

The 4b together is the length Hex length and it's equivalent to decimal  75.

Your understanding is correct and mine is base on the Hex data you provided.

-chhil

To view this discussion on the web visit https://groups.google.com/d/msgid/jpos-users/874e84c6-82e9-46c4-8ae7-262d6aee12b5%40googlegroups.com.

chhil

unread,
Dec 2, 2014, 10:55:44 PM12/2/14
to jpos-...@googlegroups.com
Mark,

Its very possible the B is a format code and is part of Track1 data. This was also brought to my notice by Ron, a colleague.
See http://en.wikipedia.org/wiki/ISO/IEC_7813#Track_1

Going solely by what was in the hex data it kind of add up.

Maybe seeing the complete raw dump of the message on the wire would clear thing up.

-chhil

To unsubscribe, send email to jpos-users+unsubscribe@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+unsubscribe@googlegroups.com.

Nishandan G

unread,
Dec 2, 2014, 11:11:26 PM12/2/14
to jpos-...@googlegroups.com
That means, this hex 3442(from raw data), converting two times to get the actual decimal value 75 ?

can you suggest me that what is the packager do this conversion from raw data?

chhil

unread,
Dec 2, 2014, 11:51:30 PM12/2/14
to jpos-...@googlegroups.com

Before you get to this provide the following

1. Packager definition.
2. The raw Hex dump of the entire message. You can use isoutil Hex dump method in your channels receive method.
3. Logs with logger attached.

Need the above because :
Don't know details of Hex dump you have provided,  does it include the length of the field on not.
Has the message been correctly unpacked till it's at unpacking your track 1.
You have mentioned the definition of the field is 1 byte length followed by variable data.  The 4B is 2 bytes of length and it doesn't feel right.

-chhil

To view this discussion on the web visit https://groups.google.com/d/msgid/jpos-users/e8d19c08-0c26-4123-94b0-bec7da22a6d9%40googlegroups.com.

Nishandan G

unread,
Dec 3, 2014, 12:45:41 AM12/3/14
to jpos-...@googlegroups.com
Packager definition

                        /*000*/ new IFE_NUMERIC (  4, "MESSAGE TYPE INDICATOR"),
/*001*/ new IFB_BITMAP  ( 16, "BIT MAP"),
/*002*/ new IFB_LLHNUM  ( 19, "PAN - PRIMARY ACCOUNT NUMBER", pad),
/*003*/ new IFB_NUMERIC (  6, "PROCESSING CODE", true),
/*004*/ new IFB_NUMERIC ( 12, "AMOUNT, TRANSACTION", true),
/*005*/ new IFB_NUMERIC ( 12, "AMOUNT, SETTLEMENT", true),
/*006*/ new IFB_NUMERIC ( 12, "AMOUNT, CARDHOLDER BILLING", true),
/*007*/ new IFB_NUMERIC ( 10, "TRANSMISSION DATE AND TIME", true),
/*008*/ new IFB_NUMERIC (  8, "AMOUNT, CARDHOLDER BILLING FEE", true),
/*009*/ new IFB_NUMERIC (  8, "CONVERSION RATE, SETTLEMENT", true),
/*010*/ new IFB_NUMERIC (  8, "CONVERSION RATE, CARDHOLDER BILLING", true),
/*011*/ new IFB_NUMERIC (  6, "SYSTEM TRACE AUDIT NUMBER", true),
/*012*/ new IFB_NUMERIC (  6, "TIME, LOCAL TRANSACTION", true),
/*013*/ new IFB_NUMERIC (  4, "DATE, LOCAL TRANSACTION", true),
/*014*/ new IFB_NUMERIC (  4, "DATE, EXPIRATION", true),
/*015*/ new IFB_NUMERIC (  4, "DATE, SETTLEMENT", true),
/*016*/ new IFB_NUMERIC (  4, "DATE, CONVERSION", true),
/*017*/ new IFB_NUMERIC (  4, "DATE, CAPTURE", true),
/*018*/ new IFB_NUMERIC (  4, "MERCHANTS TYPE", true),
/*019*/ new IFB_NUMERIC (  3, "ACQUIRING INSTITUTION COUNTRY CODE", true),
/*020*/ new IFB_NUMERIC (  3, "PAN EXTENDED COUNTRY CODE", true),
/*021*/ new IFB_NUMERIC (  3, "FORWARDING INSTITUTION COUNTRY CODE", true),
/*022*/ new IFB_NUMERIC (  4, "POINT OF SERVICE ENTRY MODE", false),
/*023*/ new IFB_NUMERIC (  4, "CARD SEQUENCE NUMBER", true),
/*024*/ new IFB_NUMERIC (  3, "NETWORK INTERNATIONAL IDENTIFIEER", true),
/*025*/ new IFB_NUMERIC (  2, "POINT OF SERVICE CONDITION CODE", true),
/*026*/ new IFB_NUMERIC (  2, "POINT OF SERVICE PIN CAPTURE CODE", true),
/*027*/ new IFB_NUMERIC (  1, "AUTHORIZATION IDENTIFICATION RESP LEN",true),
/*028*/ new IFE_CHAR (  9, "AMOUNT, TRANSACTION FEE"),
/*029*/ new IFB_AMOUNT  (  9, "AMOUNT, SETTLEMENT FEE", true),
/*030*/ new IFB_AMOUNT  (  9, "AMOUNT, TRANSACTION PROCESSING FEE", true),
/*031*/ new IFB_AMOUNT  (  9, "AMOUNT, SETTLEMENT PROCESSING FEE", true),
/*032*/ new IFB_LLHNUM  ( 11, "ACQUIRING INSTITUTION IDENT CODE", pad),
/*033*/ new IFB_LLHNUM  ( 11, "FORWARDING INSTITUTION IDENT CODE", pad),
/*034*/ new IFB_LLHNUM  ( 28, "PAN EXTENDED", pad),
/*035*/ new IFB_LLHNUM  ( 37, "TRACK 2 DATA", pad),
/*036*/ new IFB_LLLNUM  (104, "TRACK 3 DATA", pad),
/*037*/ new IFE_CHAR    ( 12, "RETRIEVAL REFERENCE NUMBER"),
/*038*/ new IFE_CHAR    (  6, "AUTHORIZATION IDENTIFICATION RESPONSE"),
/*039*/ new IFE_CHAR    (  2, "RESPONSE CODE"),
/*040*/ new IFE_CHAR    (  3, "SERVICE RESTRICTION CODE"),
/*041*/ new IFE_CHAR    (  8, "CARD ACCEPTOR TERMINAL IDENTIFICACION"),
/*042*/ new IFE_CHAR    ( 15, "CARD ACCEPTOR IDENTIFICATION CODE" ),
/*043*/ new IFE_CHAR    ( 40, "CARD ACCEPTOR NAME/LOCATION"),
/*044*/ new IFB_LLHECHAR( 98, "ADITIONAL RESPONSE DATA"),
/*045*/ new IFA_LLCHAR( 99, "TRACK 1 DATA"),
/*046*/ new IFB_LLCHAR  ( 99, "ADITIONAL DATA - ISO"),
/*047*/ new IFB_LLCHAR  ( 99, "ADITIONAL DATA - NATIONAL"),
/*048*/ new IFB_LLHBINARY ( 99, "ADITIONAL DATA - PRIVATE"),
/*049*/ new IFE_CHAR (  3, "CURRENCY CODE, TRANSACTION"),
/*050*/ new IFE_CHAR (  3, "CURRENCY CODE, SETTLEMENT"),
/*051*/ new IFE_CHAR (  3, "CURRENCY CODE, CARDHOLDER BILLING"),
/*052*/ new IFB_BINARY  (  8, "PIN DATA"   ),
/*053*/ new IFB_BINARY (8, "SECURITY RELATED CONTROL INFORMATION"),
/*054*/ new IFB_LLHNUM  (20, "ADDITIONAL AMOUNTS", false),
/*055*/ new IFB_LLLHBINARY (999, "CHIP DATA"),
/*056*/ new IFB_LLCHAR  ( 99, "RESERVED ISO"),
/*057*/ new IFB_LLCHAR  ( 99, "RESERVED NATIONAL"),
/*058*/ new IFB_LLCHAR  ( 99, "RESERVED NATIONAL"),
/*059*/ new IFB_LLHECHAR ( 14, "NATIONAL POS GEOGRAPHIC DATA"),
/*060*/ new IFB_LLHBINARY  (99, "RESERVED PRIVATE"),
/*061*/ new IFB_LLHECHAR (99, "RESERVED PRIVATE"),

Hex dump of the entire message

F0F1F0F0763D4481A8E8A00810356970000000001000000000000000700000000000010012030130540020640930541203181112037216022000088870900008887090002503569700000000010D18112011000070400000F1F4F1F2F0F3F0F0F2F0F6F4F3F9F4F54040F3F3F3F2F5F6F2F2F0F3F5F4F8F7F14040D1C3C240E3C5E2E340D4C5D9C3C8C1D5E3404040404040E3C5E2E340C3C9E3E84040404040F3F4F43442333534313730303030303030303031305E4A434220435245444954205445532020202020202020202020205E31383131323031313030303030303030303030303030373034303030303030F9F7F8F8F4F006F2F2F2F5F2F8

chhil

unread,
Dec 3, 2014, 5:07:06 AM12/3/14
to jpos-...@googlegroups.com
Logger logger = new Logger(); 
 logger.addListener (new SimpleLogListener(System.out)); 
 UserPackager p = new UserPackager(); //saved your packager in this p.setLogger(logger, “debug”); 
 ISOMsg msg = new ISOMsg(); 
 msg.setPackager(p); 
 String raw = “F0F1F0F0763D4481A8E8A00810356970000000001000000000000000700000000000010012030130540020640930541203181112037216022000088870900008887090002503569700000000010D18112011000070400000F1F4F1F2F0F3F0F0F2F0F6F4F3F9F4F54040F3F3F3F2F5F6F2F2F0F3F5F4F8F7F14040D1C3C240E3C5E2E340D4C5D9C3C8C1D5E3404040404040E3C5E2E340C3C9E3E84040404040F3F4F43442333534313730303030303030303031305E4A434220435245444954205445532020202020202020202020205E31383131323031313030303030303030303030303030373034303030303030F9F7F8F8F4F006F2F2F2F5F2F8”; 
 try{ 
 byte [] arr = ISOUtil.hex2byte(raw); 
 msg.unpack(arr); 
 } catch (Exception ex )
 { 
 msg.dump(System.out, ""); 
 ex.printStackTrace(); 
 } 


 <log realm="debug" at="Wed Dec 03 15:31:23 IST 2014.45" lifespan="52ms">
  <unpack>
    F0F1F0F0763D4481A8E8A00810356970000000001000000000000000700000000000010012030130540020640930541203181112037216022000088870900008887090002503569700000000010D18112011000070400000F1F4F1F2F0F3F0F0F2F0F6F4F3F9F4F54040F3F3F3F2F5F6F2F2F0F3F5F4F8F7F14040D1C3C240E3C5E2E340D4C5D9C3C8C1D5E3404040404040E3C5E2E340C3C9E3E84040404040F3F4F43442333534313730303030303030303031305E4A434220435245444954205445532020202020202020202020205E31383131323031313030303030303030303030303030373034303030303030F9F7F8F8F4F006F2F2F2F5F2F8
    <bitmap>{2, 3, 4, 6, 7, 11, 12, 13, 14, 16, 18, 22, 25, 32, 33, 35, 37, 41, 42, 43, 45, 49, 51, 61}</bitmap>
    <unpack fld="2" packager="org.jpos.iso.IFB_LLHNUM">
      <value>3569700000000010</value>
    </unpack>
    <unpack fld="3" packager="org.jpos.iso.IFB_NUMERIC">
      <value>000000</value>
    </unpack>
    <unpack fld="4" packager="org.jpos.iso.IFB_NUMERIC">
      <value>000000007000</value>
    </unpack>
    <unpack fld="6" packager="org.jpos.iso.IFB_NUMERIC">
      <value>000000000100</value>
    </unpack>
    <unpack fld="7" packager="org.jpos.iso.IFB_NUMERIC">
      <value>1203013054</value>
    </unpack>
    <unpack fld="11" packager="org.jpos.iso.IFB_NUMERIC">
      <value>002064</value>
    </unpack>
    <unpack fld="12" packager="org.jpos.iso.IFB_NUMERIC">
      <value>093054</value>
    </unpack>
    <unpack fld="13" packager="org.jpos.iso.IFB_NUMERIC">
      <value>1203</value>
    </unpack>
    <unpack fld="14" packager="org.jpos.iso.IFB_NUMERIC">
      <value>1811</value>
    </unpack>
    <unpack fld="16" packager="org.jpos.iso.IFB_NUMERIC">
      <value>1203</value>
    </unpack>
    <unpack fld="18" packager="org.jpos.iso.IFB_NUMERIC">
      <value>7216</value>
    </unpack>
    <unpack fld="22" packager="org.jpos.iso.IFB_NUMERIC">
      <value>0220</value>
    </unpack>
    <unpack fld="25" packager="org.jpos.iso.IFB_NUMERIC">
      <value>00</value>
    </unpack>
    <unpack fld="32" packager="org.jpos.iso.IFB_LLHNUM">
      <value>88709000</value>
    </unpack>
    <unpack fld="33" packager="org.jpos.iso.IFB_LLHNUM">
      <value>88709000</value>
    </unpack>
    <unpack fld="35" packager="org.jpos.iso.IFB_LLHNUM">
      <value>3569700000000010=18112011000070400000</value>
    </unpack>
    <unpack fld="37" packager="org.jpos.iso.IFE_CHAR">
      <value>141203002064</value>
    </unpack>
    <unpack fld="41" packager="org.jpos.iso.IFE_CHAR">
      <value>3945  33</value>
    </unpack>
    <unpack fld="42" packager="org.jpos.iso.IFE_CHAR">
      <value>3256220354871  </value>
    </unpack>
    <unpack fld="43" packager="org.jpos.iso.IFE_CHAR">
      <value>JCB TEST MERCHANT      TEST CITY     344</value>
    </unpack>
    <unpack fld="45" packager="org.jpos.iso.IFA_LLCHAR">
      <value>3541700000000010^JCB CREDIT TES            ^18112011000000</value>
    </unpack>
    <unpack fld="49" packager="org.jpos.iso.IFE_CHAR">
      <value>???</value>
    </unpack>
    <unpack fld="51" packager="org.jpos.iso.IFE_CHAR">
      <value>???</value>
    </unpack>
    error unpacking field 61 consumed=229
    <iso-exception>
      org.jpos.iso.IFB_LLHECHAR: Problem unpacking field 61
      <nested-exception>
      java.lang.ArrayIndexOutOfBoundsException: 253
    at org.jpos.iso.ISOUtil.ebcdicToAsciiBytes(ISOUtil.java:218)
    at org.jpos.iso.ISOUtil.ebcdicToAscii(ISOUtil.java:205)
    at org.jpos.iso.EbcdicInterpreter.uninterpret(EbcdicInterpreter.java:50)
    at org.jpos.iso.ISOStringFieldPackager.unpack(ISOStringFieldPackager.java:180)
    at org.jpos.iso.ISOBasePackager.unpack(ISOBasePackager.java:255)
    at org.jpos.iso.ISOMsg.unpack(ISOMsg.java:460)
    at Test.main(Test.java:29)
      </nested-exception>
      org.jpos.iso.ISOException: org.jpos.iso.IFB_LLHECHAR: Problem unpacking field 61 (java.lang.ArrayIndexOutOfBoundsException: 253)
    at org.jpos.iso.ISOStringFieldPackager.unpack(ISOStringFieldPackager.java:185)
    at org.jpos.iso.ISOBasePackager.unpack(ISOBasePackager.java:255)
    at org.jpos.iso.ISOMsg.unpack(ISOMsg.java:460)
    at Test.main(Test.java:29)
Nested:java.lang.ArrayIndexOutOfBoundsException: 253
    at org.jpos.iso.ISOUtil.ebcdicToAsciiBytes(ISOUtil.java:218)
    at org.jpos.iso.ISOUtil.ebcdicToAscii(ISOUtil.java:205)
    at org.jpos.iso.EbcdicInterpreter.uninterpret(EbcdicInterpreter.java:50)
    at org.jpos.iso.ISOStringFieldPackager.unpack(ISOStringFieldPackager.java:180)
    at org.jpos.iso.ISOBasePackager.unpack(ISOBasePackager.java:255)
    at org.jpos.iso.ISOMsg.unpack(ISOMsg.java:460)
    at Test.main(Test.java:29)
    </iso-exception>
    <iso-exception>
      org.jpos.iso.IFB_LLHECHAR: Problem unpacking field 61 (java.lang.ArrayIndexOutOfBoundsException: 253) unpacking field=61, consumed=229
      org.jpos.iso.ISOException: org.jpos.iso.IFB_LLHECHAR: Problem unpacking field 61 (java.lang.ArrayIndexOutOfBoundsException: 253) unpacking field=61, consumed=229
    at org.jpos.iso.ISOBasePackager.unpack(ISOBasePackager.java:284)
    at org.jpos.iso.ISOMsg.unpack(ISOMsg.java:460)
    at Test.main(Test.java:29)
    </iso-exception>

  </unpack>
</log>

Lets concentrate on
JCB TEST MERCHANT TEST CITY 344 3541700000000010^JCB CREDIT TES ^18112011000000
If find the 344 in the ebcidic hex data (since field 43 is EBCIDIC) its F3F4F4, following this is the track 1 length followed by track 1 data
Snipped from hex data from field 43s 344

F3F4F43442333534313730303030303030303031305E4A434220435245444954205445532020202020202020202020205E31383131323031313030303030303030303030303030373034303030303030F9F7F8F8F4F006F2F2F2F5F2F8

So basically what I had stated earlier, you will need to write a custom packager that understands and interpret the length 3442 as 4B and extract the next 75 bytes.
I dont think a packager for it exists, if there is one, hopefully someone will point you to it.


-chhil

​
​
​
​

​

Nishandan G

unread,
Dec 4, 2014, 1:07:10 AM12/4/14
to jpos-...@googlegroups.com
Thanks a lot Chhil,
Reply all
Reply to author
Forward
0 new messages