Re: need help packing field 63 - VBV - ECI/XID and CAVV data

[sanjeev]

Any help appreciated. Thanks
--
View this message in context: http://www.nabble.com/need-help-packing-field-63---VBV---ECI-XID-and-CAVV-data-tf4011798.html#a11405650
Sent from the jPOS - Users mailing list archive at Nabble.com.

[Mark Salter]

sanjeev wrote:
>
> Any help appreciated. Thanks
First take a read of this page :-

http://www.catb.org/~esr/faqs/smart-questions.html

This will help you pose a question that is likely to get a useful answer.

The data you are referring to might be base64 encoded, is it?

You may need to treat the field in a opaque way where the packager just
defines the whole field, and then you split it up 'manually' from there.

With so little information in your question it is hard to provide an
accurate answer.

If you could provide detail including, but not limited to :-

Packager?,
scheme?
What you have tried
What failed

'We' might be able to help.

--
Mark

[sanjeev]

Thanks Mark for the response.

Following is the field DE63 in my xml file.
<isofield
id="63"
length="999"
name="RESERVED FOR PRIVATE USE"
class="com.xor.monex.proxy.common.iso.IFB_LLLLCHAR"/>

and this is the iso message in the logs.....
xmlRequest=<?xml version="1.0" encoding="UTF-8"?>
<Authorize>
<MerchantSubID>168168049757</MerchantSubID>
<RequestID>000022</RequestID>
<CardIDBitmap>3</CardIDBitmap>
<CardNo>4222222222222220</CardNo>
<CardExpDate>1210</CardExpDate>
<ECI>06</ECI>
<CAVV>BwABCSYZd2ACIHmFSBl3AAAAAAA=</CAVV>
<XID>00001000000014362822</XID>
<Track2Data/>

<TransactionSource>Internet</TransactionSource>
<PIN audit="false"/>
<TargetAmount>2000</TargetAmount>

<TargetCurrencyMinorUnit>1</TargetCurrencyMinorUnit>
<MayBeDuplicate>0</MayBeDuplicate>
<TerminalID>43420001</TerminalID>
<UserData/>
</Authorize>
<isomsg>
<field id="0" value="0100"/>
<field id="2" value="4222222222222220"/>
<field id="3" value="000000"/>
<field id="4" value="2000"/>
<field id="11" value="000022"/>
<field id="14" value="1012"/>
<field id="22" value="0012"/>
<field id="24" value="009"/>
<field id="25" value="00"/>
<field id="41" value="43420001"/>
<field id="42" value="168168049757"/>
<field id="48" value=" "/>
<field id="63"
value="3&#6;BwABCSYZd2ACIHmFSBl3AAAAAAA=000000000000&#0;&#0;&#0;&#0;&#0;&#0;&#0;&#0;&#0;&#0;&#0;&#0;&#0;&#3;&#65533;~&#65533;&#65533;&#65533;&#65533;"/>
</isomsg>
<connect>
dbstest:1506
</connect>
</log>
<log realm="debug-packager" at="Tue Jul 03 11:28:12 SGT 2007.310">
<pack>

01007024058000C10002164222222222222220000000000000002000000001101200120009003433343230303031313638313638303439373537202020000320202000623306427741424353595A6432414349486D4653426C33414141414141413D3030303030303030303030300000000000000000000000000003EFBFBD7EEFBF
</pack>
</log>
<log realm="debug-channel/dbstest/192.168.78.208:1506" at="Tue Jul
03 11:28:12 SGT 2007.310">
<send>
<isomsg direction="outgoing">
<field id="0" value="0100"/>
<field id="2" value="4222222222222220"/>
<field id="3" value="000000"/>
<field id="4" value="2000"/>
<field id="11" value="000001"/>
<field id="14" value="1012"/>
<field id="22" value="0012"/>
<field id="24" value="009"/>
<field id="25" value="00"/>
<field id="41" value="43420001"/>
<field id="42" value="168168049757"/>
<field id="48" value=" "/>
<field id="63"
value="3&#6;BwABCSYZd2ACIHmFSBl3AAAAAAA=000000000000&#0;&#0;&#0;&#0;&#0;&#0;&#0;&#0;&#0;&#0;&#0;&#0;&#0;&#3;&#65533;~&#65533;&#65533;&#65533;&#65533;"/>
</isomsg>
</send>
</log>

I have highlighted the portion of the raw data. The XID part is wrong
somehow....

this is what is should get 00000000000000000000000000038d7ea5a1a8c6 but i am
not getting this.

to get this XID value i took xid from xml (00001000000014362822) this i
converted to hex string .
after conversion the hex string looks like this
...00000000000000000000000000038d7ea5a1a8c6
which if you'll notice is the string i am expecting i.e. the correct one.
Now when i convert this hex
to bytes i get errors - i used a LeftPadded to pad the string to 40
characters i.e 20 bytes .on the left
with zeroes. then i used some algorithms to do the conversion. All the
algorithms i used including the
ISOUtil.hex2byte method is giving me the exact same "incorrect" result.

How can i fix this issue ?

Thanks for your time and patience.

--
View this message in context: http://www.nabble.com/need-help-packing-field-63---VBV---ECI-XID-and-CAVV-data-tf4011798.html#a11406513

[sanjeev]

hello all,

i am having a bit of a problem packing a field - 63 - for VBV with ECI/XID
and CAVV data.

so the field looks ike this 0x33 - ECI [an2] - CAVV[ans40] - XID [b20]

it is the last part which is causing a problem...

supposing i have tags which look like this ....

<ECI>06</ECI>
<CAVV>BwABCSYZd2ACIHmFSBl3AAAAAAA=</CAVV>
<XID>00001000000014362822</XID>

after packing CAVV will look like this - no problems here
427741424353595A6432414349486D4653426C33414141414141413D303030303030303030303030

after packing xid should look like this....
00000000000000000000000000038D7EA5A1A8C6

so full raw message body will look like this ...3306 --
427741424353595A6432414349486D4653426C33414141414141413D303030303030303030303030
--
00000000000000000000000000038D7EA5A1A8C6 --

it is the last part which is not coming - i am getting
0000000000000000000000000003EFBFBD7EEFBF and not
00000000000000000000000000038D7EA5A1A8C6 as i should ......

i know the xid value gets parsed properly and converted to hex string - for
which i get 00000000000000000000000000038D7EA5A1A8C6 which is the correct
value.....but after i convert this
hex string to binary string - i mean byte string - things are getting messed
up....

i used IsoUtil method - hex2byte which i thought would output binary.....

any light shedded on this issue will be highly appreciated. Thanks and
regards.

sanjeev.

what am i doing wrong ?

--
View this message in context: http://www.nabble.com/need-help-packing-field-63---VBV---ECI-XID-and-CAVV-data-tf4011798.html#a11392823

[Mark Salter]

sanjeev wrote:

> i am having a bit of a problem packing a field - 63 - for VBV with ECI/XID
> and CAVV data.
>
> so the field looks ike this 0x33 - ECI [an2] - CAVV[ans40] - XID [b20]
>
> it is the last part which is causing a problem...
>
> supposing i have tags which look like this ....
>
> <ECI>06</ECI>
> <CAVV>BwABCSYZd2ACIHmFSBl3AAAAAAA=</CAVV>
> <XID>00001000000014362822</XID>
>
>
> after packing CAVV will look like this - no problems here
> 427741424353595A6432414349486D4653426C33414141414141413D303030303030303030303030

Padded to the right with ascii zeros rather than spaces?

>
> after packing xid should look like this....
> 00000000000000000000000000038D7EA5A1A8C6

I don't see how you get this value from <XID>00001000000014362822</
XID>?

>
>
> so full raw message body will look like this ...3306 --
> 427741424353595A6432414349486D4653426C33414141414141413D303030303030303030303030
> --
> 00000000000000000000000000038D7EA5A1A8C6 --
>
> it is the last part which is not coming - i am getting
> 0000000000000000000000000003EFBFBD7EEFBF and not
> 00000000000000000000000000038D7EA5A1A8C6 as i should ......
>
> i know the xid value gets parsed properly and converted to hex string - for
> which i get 00000000000000000000000000038D7EA5A1A8C6 which is the correct
> value.....but after i convert this
> hex string to binary string - i mean byte string - things are getting messed
> up....
>
>
> i used IsoUtil method - hex2byte which i thought would output binary.....

This will return a byte array.

>
> any light shedded on this issue will be highly appreciated. Thanks and
> regards.

It feels like you are mixing BASE64 encoded (character data) with
binary data which is a bit 'odd'. BASE64 is used to avoid byte
interpretaion and the loss of data due to interpretation of the
stream.

But more importantly you might be mixing hexadecimal character data
with byte[]'s.

It looks like your IFB_LLLCHAR might need a byte[] passed in
containing it's entire data content. Can you try construting a
hexstring of all of the fields components and then using:-

message.set(63,ISOUtil.hex2byte(value));

Out of interest, why have you moved the jPOS class into your own
hierachy?

--
Mark

[sanjeev]

>>But more importantly you might be mixing hexadecimal character data
>>with byte[]'s.

Yes I am .
Well - the field definition is like this 0x33 prefix + 2 digit numerical ECI
+ length 40 alphanumeric CAVV + 20 byte XID .
so yes - character data and hex and binary is mixed.

>>It looks like your IFB_LLLCHAR might need a byte[] passed in
>>containing it's entire data content. Can you try construting a
>>hexstring of all of the fields components and then using:-

The whole field i should send as binary ? why ? Because the Raw Data looks
ok
- it is only the last few digits which are off. Anyway - i'll try your
suggestion as well.

yes - i used like this only ---> message.set(63,ISOUtil.hex2byte(value));

Out of interest, why have you moved the jPOS class into your own
hierachy?

Um - I am not that sure about this as I am a new guy in this company. XOR
Tech an Israeli
company who were handling the old system.

regards,
Sanjeev
--
View this message in context: http://www.nabble.com/need-help-packing-field-63---VBV---ECI-XID-and-CAVV-data-tf4011798.html#a11409020

[sanjeev]

Mark,

Thanks so much for your suggestions.
The field is now exactly like i want it. But I have an additional problem -
a classcastexception.

Maybe i should change the packager class to to jpos one ?? I will try and
let u know.

Thanks again.

cheers,
sanjeev

<isomsg>
<field id="0" value="0100"/>
<field id="2" value="4222222222222220"/>
<field id="3" value="000000"/>
<field id="4" value="2000"/>

<field id="11" value="000024"/>

<field id="14" value="1012"/>
<field id="22" value="0012"/>
<field id="24" value="009"/>
<field id="25" value="00"/>
<field id="41" value="43420001"/>
<field id="42" value="168168049757"/>
<field id="48" value=" "/>
<field id="63"

value="3306427741424353595A6432414349486D4653426C33414141414141413D30303030303030303030303000000000000000000000000000038D7EA5A1A8C6"
type="binary"/>

</isomsg>
<connect>
dbstest:1506
</connect>
</log>

<log realm="debug-packager" at="Tue Jul 03 18:03:39 SGT 2007.783">
<pack/>

</log>
<log realm="debug-channel/dbstest/192.168.78.208:1506" at="Tue Jul

03 18:03:39 SGT 2007.784">

<send>
<isomsg direction="outgoing">
<field id="0" value="0100"/>
<field id="2" value="4222222222222220"/>
<field id="3" value="000000"/>
<field id="4" value="2000"/>

<field id="11" value="000024"/>

<field id="14" value="1012"/>
<field id="22" value="0012"/>
<field id="24" value="009"/>
<field id="25" value="00"/>
<field id="41" value="43420001"/>
<field id="42" value="168168049757"/>
<field id="48" value=" "/>
<field id="63"

value="3306427741424353595A6432414349486D4653426C33414141414141413D30303030303030303030303000000000000000000000000000038D7EA5A1A8C6"
type="binary"/>
</isomsg>
<exception name="null">
java.lang.ClassCastException
at
com.xor.monex.proxy.common.iso.IFB_LLLLCHAR.pack(IFB_LLLLCHAR.java:28)
at org.jpos.iso.ISOBasePackager.pack(ISOBasePackager.java:142)
at org.jpos.iso.ISOMsg.pack(ISOMsg.java:311)
at org.jpos.iso.BaseChannel.send(BaseChannel.java:415)
at
com.xor.monex.proxy.dbs.Objects.DBSProtocol.Post(DBSProtocol.java:117)
at
com.xor.monex.proxy.dbs.Objects.DBSRequest.PerformRequest(DBSRequest.java:82)

--
View this message in context: http://www.nabble.com/need-help-packing-field-63---VBV---ECI-XID-and-CAVV-data-tf4011798.html#a11409388

[sanjeev]

ok. As expected i got a classcastexception with the jpos pasckager class too.
IFB_LLLCHAR doesn't work.
It throws a problem packing field 63 error message.

Now what ?

Btw. length of this field is 999 variable . Which class should i use ?

Thanks man - for everything.

cheers,
sanjeev.

--
View this message in context: http://www.nabble.com/need-help-packing-field-63---VBV---ECI-XID-and-CAVV-data-tf4011798.html#a11409560

[Mark Salter]

sanjeev wrote:

> Now what ?
Hmmm.

>
> Btw. length of this field is 999 variable . Which class should i use ?

What format is the length - character(ascii or ebcdic)/binary across 2
bytes or 3 bytes?

--
Mark

[sanjeev]

Mark,

As far as my guess goes - it is 2 byte binary data.

Btw. i tried the jpos class IFB_LLLBINARY - this doesn't throw a
classcastexception but when
i use this - my bank proxy tests always return a request timed out error.

Thanks for your help.

regards,
sanjeev.

--
View this message in context: http://www.nabble.com/need-help-packing-field-63---VBV---ECI-XID-and-CAVV-data-tf4011798.html#a11425223

[Mark Salter]

sanjeev wrote:

> As far as my guess goes - it is 2 byte binary data.

Do you need to guess? Can't you get your hands on a message
specification?

>
> Btw. i tried the jpos class IFB_LLLBINARY - this doesn't throw a
> classcastexception but when
> i use this - my bank proxy tests always return a request timed out error.

So the proxy doesn't like the message (perhaps), can someone examine
the proxy's log for you to let you know what it doesn't like?

--
Mark

[sanjeev]

Hi Mark,

Please have a look at the excerpt from the Change Request requirement docs.
This is what I got.

The DE63 for Visa VBV transaction is as follows:

MTI Field Name Type Bytes Values
Additional Data
Total Length DE63 N 3 2 0LLL - BDC length of data to follow
Table ID Ans 2 1 33
Ecommerce Indicator N 2 1
Visa CAVV Data Ans 40 40 Left justified with trailing spaces

Does this help ?

thanks and regards,
sanjeev

--
View this message in context: http://www.nabble.com/need-help-packing-field-63---VBV---ECI-XID-and-CAVV-data-tf4011798.html#a11426253

[Mark Salter]

sanjeev wrote:

> Please have a look at the excerpt from the Change Request requirement docs.
> This is what I got.
>
> The DE63 for Visa VBV transaction is as follows:

Although the layout has been lost...

>
> MTI Field Name Type Bytes Values

I don't see to what these 'titles' relate.

> Additional Data
> Total Length DE63 N 3 2 0LLL - BDC length of data to follow

This indicates (to me) a Binary Coded Decimal length in two bytes, *not*
including it's own length of two:-

Length Value
23 x'0023'
100 x'0100'

Instead of a straight binary field (100 = x'0064')

> Table ID Ans 2 1 33
> Ecommerce Indicator N 2 1

^ what should go here?

> Visa CAVV Data Ans 40 40 Left justified with trailing spaces

We already know this is an opaque 'binary' data, so the field content is
sorted.

I think you should be using IFB_LLLBINARY, the following test for this
class illustrate the result (sorry for the layout mess) :-

public void testPackGreaterThan16() throws Exception
{
ISOBinaryField field = new ISOBinaryField(1, new byte[] {0x01,
0x02, 0x03, 0x04, 0x05, 0x06, 0x07 ,0x08, 0x09, 0x0a, 0x0b, 0x0c, 0x0d,
0x0e, 0x0f, 0x10, 0x11});
IFB_LLLBINARY packager = new IFB_LLLBINARY(1, "Should be 1234");
TestUtils.assertEquals(new byte[] {0x00, 0x17, 0x01, 0x02, 0x03,
0x04, 0x05, 0x06, 0x07 ,0x08, 0x09, 0x0a, 0x0b, 0x0c, 0x0d, 0x0e, 0x0f,
0x10, 0x11}, packager.pack(field));
}

public void testUnpackGreaterThan16() throws Exception
{
byte[] raw = new byte[] {0x00, 0x17, 0x01, 0x02, 0x03, 0x04,
0x05, 0x06, 0x07 ,0x08, 0x09, 0x0a, 0x0b, 0x0c, 0x0d, 0x0e, 0x0f, 0x10,
0x11};
IFB_LLLBINARY packager = new IFB_LLLBINARY(1, "Should be 17
bytes 01 through 11");
ISOBinaryField field = new ISOBinaryField(1);
packager.unpack(field, raw, 0);
TestUtils.assertEquals(new byte[] {0x01, 0x02, 0x03, 0x04, 0x05,
0x06, 0x07 ,0x08, 0x09, 0x0a, 0x0b, 0x0c, 0x0d, 0x0e, 0x0f, 0x10, 0x11},
(byte[])field.getValue());
}

public void testReversabilityGreaterThan16() throws Exception
{
byte[] origin = new byte[] {0x01, 0x02, 0x03, 0x04, 0x05, 0x06,
0x07 ,0x08, 0x09, 0x0a, 0x0b, 0x0c, 0x0d, 0x0e, 0x0f, 0x10, 0x11};
ISOBinaryField f = new ISOBinaryField(1, origin);
IFB_LLLBINARY packager = new IFB_LLLBINARY(1, "Should be
x'0102030405060708090a0b0c0d0e0f1011'");

ISOBinaryField unpack = new ISOBinaryField(12);
packager.unpack(unpack, packager.pack(f), 0);
TestUtils.assertEquals(origin, (byte[])unpack.getValue());
}
>
> Does this help ?
Does this?

--
Mark

[sanjeev]

Hi Mark,

Sorry for not replying earlier. As it happens I was quite confused about
this whole issue.

However - after some careful thinking I have sorted out the problem.

As you so rightly pointed out the message is fine. No problems there. The
problem lies with the

packager. I consulted someone and i was advised that the hex string is not
being converted

correctly into bytes by the packager. I am not sure how the packager should
be packing it.

It seems that in the hex string if there is an A then i have to minus 0x40
and then add 10.
If it is a number in the hex string between 0-9 then i minus 0x30. Does this
make any sense ?

Can u tell me how to accomplish the above ?

Thanks and regards,
sanjeev.

--
View this message in context: http://www.nabble.com/need-help-packing-field-63---VBV---ECI-XID-and-CAVV-data-tf4011798.html#a11553618

[chhil]

It makes sense because all you are doing is changing the character value to a int... to explain your way... may want to check if ISOutil already has some helper functions..

http://asciitable.com/   to get numerical equivalents of characters.

Char '0' numerical equivalent 0x30  you want to get a int value of 0, how would you do it.... simply minus 0x30 from it. similarly
'1' =  0x31  you want to get a int value of 1, how would you do it.... simply minus 0x30 from it.
'2' =  0x32  you want to get a int value of 2, how would you do it.... simply minus 0x30 from it.
so on and so forth
'A'= 0x41 and you want to get a value of 10 ( A (base 16) == 10 (base 10) from this...how would you do it simply minus 0x41 (not 0x40) and add 10.

OR do it the java way...
        System.out.println(Integer.parseInt ("1", 16));
        System.out.println('1' -0x30);
       
        System.out.println(Integer.parseInt("A", 16));
        System.out.println('A' -0x41 +10);

-chhil

[Mark Salter]

sanjeev wrote:
>
> Hi Mark,
>
> Sorry for not replying earlier. As it happens I was quite confused about
> this whole issue.

No apology required, thank you for trying to find you own way before
coming back to us.

>
> However - after some careful thinking I have sorted out the problem.
>
> As you so rightly pointed out the message is fine. No problems there. The
> problem lies with the
>
> packager. I consulted someone and i was advised that the hex string is not
> being converted
>
> correctly into bytes by the packager. I am not sure how the packager should
> be packing it.

I really doubt that the packager is wrong, more likely there is just
confusion with how the data is represented and what the target system is
expecting. Your understanding of number bases, character code pages and
binary coding mixes are likely the problem.

>
> It seems that in the hex string if there is an A then i have to minus 0x40
> and then add 10.

Is that a c'A' in ASCII or perhaps EBCDIC, by taking off x'40' and then
adding x'0A' (which is decimal 10), makes me (and chill) think it is ASCII.

IIn ASCII, c'A' then x'41' (-x'40' +x'0A') becomes x'0B', this seems an
unlikely. Perhaps 9 is the 'adjustment' so you get x'0A' [Do you see
where this is going?].

> If it is a number in the hex string between 0-9 then i minus 0x30. Does this
> make any sense ?

This makes more sense:-

In ASCII - c'0' = x'30', c'1' = x'31', so subtract x'30' from the byte
value leaves x'00' and x'01' respectively.

>
> Can u tell me how to accomplish the above ?

You don't want to do any of the calculations above, just something that
looks like it. I have followed through with your guess above to
illustrate the problem.

You need to think what your data looks like in bytes. Using x'010203'
is a nice way for a human to achieve this.

So in 'character hex' for the field content only...

Table ID=x'33'
Ecom Indicator=x'3036'
CAVV=x'437741424353595A4432414349486D4653423133C1C1C1C1C1C1C13D2020202020202020202020'
XID=x'00001000000014362822'

The hard bit to 'see' here is how I got the CAVV value. Chill has also
just responded to you to show you how. Each byte in the CAVV is the
hexadecimal representation of the BASE64 encoded data
c'BwABCSYZd2ACIHmFSBl3AAAAAAA= ' and I have added to 11 bytes
of spaces (x'20') to make it 40 bytes long.

Now...

Your field is a mix of binary and Base64 encoded data, which is an odd
approach, but I will try not to worry about it at this time 8).

You need to compose your final field content from it's components as an
array of bytes.

I would concatenate byte[]s using ISOUtil.concat(), paying attention on
the CAVV field with needs to be padded to the right with spaces and then
you need the bytes of the string:-

byte[] TabID = new byte[] {0x33};
byte[] ECom = new byte[] {0x30,0x36};
byte[] CAVV = "BwABCSYZd2ACIHmFSBl3AAAAAAA= ".getBytes();
byte[] XID = new byte[] {0x00, 0x00, 0x10, 0x00, 0x00, 0x00, 0x14,
0x36, 0x28, 0x22};

Once you have the concatenated result as :-
NB EXAMPLE only, don't really do it like this 8).

byte[] content = ISOUtil.concat(TabID,ECom);
content = ISOUtil.concat(content,CAVV];
content = ISOUtil.concat(content,XID];

request.set(63,content);

I really hope this and chill's note help you see the light. I used
(http://www.ecowin.org/aulas/resources/tables/asciitable.jpg) as my
manual translation reference point.

--
Mark

[Mark Salter]

chhil wrote:
> 'A'= 0x41 and you want to get a value of 10 ( A (base 16) == 10 (base
> 10) from this...how would you do it simply minus 0x41 (not 0x40) and add 10.

8)

That is much better advise than subtracting 40 and adding 9!

--
Mark

[sanjeev]

Mark and Chhil - thanks to both of you guys.

I have learned a lot and have almost solved my problem, in the sense I now
have
the message correct - only the problem is with the packager is unable to
pack
it - i am getting a class cast exception on line 28. Below is the code of my
packager class.

Something is definitely strange - i am passing a byte [] to my de63 and in
the pack method - this line
looks odd ---> byte[] l = ISOUtil.str2bcd (slen, true);

string to bcd ? obviously this has to throw a classcastexception because the
input is a byte [] and not
string - also why is it converting to bcd ? Anyway - I will be grateful if
someone can shed some light.

Thanks and best regards,
sanjeev

package com.xor.monex.proxy.common.iso;

import java.io.IOException;
import java.io.InputStream;
import org.jpos.iso.*;

public class IFB_LLLLCHAR extends ISOFieldPackager
{
public IFB_LLLLCHAR() {
super();
}

/**
* @param len - field len
* @param description symbolic descrption
*/
public IFB_LLLLCHAR (int len, String description) {
super(len, description);
}

/**
* @param c - a component
* @return packed component
* @exception ISOException
*/
public byte[] pack (ISOComponent c) throws ISOException {
int len;
String s = (String) c.getValue();

if ((len=s.length()) > getLength() || len>9999) // paranoia settings
throw new ISOException (
"invalid len "+len +" packing field "+(Integer) c.getKey()
);

byte[] b = new byte[len + 2];
String slen = ISOUtil.zeropad (Integer.toString(len),4);
byte[] l = ISOUtil.str2bcd (slen, true);
b[0] = l[0];
b[1] = l[1];
System.arraycopy (s.getBytes(), 0, b, 2, len);
return b;
}

/**
* @param c - the Component to unpack
* @param b - binary image
* @param offset - starting offset within the binary image
* @return consumed bytes
* @exception ISOException
*/
public int unpack (ISOComponent c, byte[] b, int offset)
throws ISOException
{
int len = (b[offset++] & 0x0F) * 100;
len += (((b[offset] >> 4) & 0x0F) * 10) + (b[offset] & 0x0F);
c.setValue(new String(b, ++offset, len));
return len+2;
}

public int getMaxPackedLength() {
return getLength()+2;
}

public void unpack (ISOComponent c, InputStream in)
throws IOException, ISOException
{
byte[] b = readBytes (in, 2);
int len = (((b[0] >> 4) & 0x0F) * 1000) + ((b[0] & 0x0F) * 100);
len += (((b[1] >> 4) & 0x0F) * 10) + (b[1] & 0x0F);
c.setValue (new String (readBytes (in, len)));
}
}

--
View this message in context: http://www.nabble.com/need-help-packing-field-63---VBV---ECI-XID-and-CAVV-data-tf4011798.html#a11591613

[Alejandro Revilla]

You want to change your field-packager definition for field 63 from
IFB_LLLCHAR to IFB_LLLBINARY.