how to create a Binary Bitmap (64 bits)

[Suresh Kumar]

Hi All,

I am trying to create message as below, however after creating when i print the byte[], i can't see bitmap field in binary format. However i defined bitmap as IFB_BITMAP data type. please find the attached screen short which has the output

 

Any thoughts on this will really help me a lot.

 

 

 

 

 

Java Code:

 

 

            ISOMsg message = new ISOMsg("1644");

            message.set(24, "697");

            message.set("48.0105", "002080116DE33XXXXXXX00001");

            message.set("48.0122", "T");

            message.set("48.0191", "2");

            message.set(71, "00000001");

            GenericPackager packager = new GenericPackager("ipm_iso93binary.xml");

            evt.addMessage (message);

            message.setPackager(packager);

            System.out.println(new String(message.pack()));

 

 

 

XML File :

 

 

  <isofield

      id="0"

      length="4"

      name="Message Type Identifier"

      pad="false"

      class="org.jpos.iso.IFE_NUMERIC"/>

  <isofield

      id="1"

      length="16"

      name="Bit Maps (Primary and Secondary)"

      class="org.jpos.iso.IFB_BITMAP"/>

  <isofield

      id="2"

      length="19"

      name="Primary Account Number (PAN)"

      pad="false"

      class="org.jpos.iso.IFE_LLNUM"/>

 

                .......       .......       .......       .......

                .......       .......       .......       .......

[chhil]

The line before the xml has the bitmap, but since the byte array has unprintable characters it does not show up. 

You should look into converting them to hex to make sense of it.

-chhil

[chhil]

Apologies for posting twice...

The list already has a sample of what you are looking for...

"From: David Bergert 
Date: Fri, Oct 31, 2008 at 12:38 AM
Subject: RE: How to Dump/output the Incoming Message Byte Header array"

-chhil

[Suresh Kumar]

please find the updated code which prints the bitmap in hex format and binary.

However when i try print the byte[] which returned from msg.pack() method, i am not able to see the binary format of the bit map. only the unprintable characters.

may i know how can i get the bitmap value along with bite[] array itself

updated code:

            ISOMsg myISOMsg = new ISOMsg();

            myISOMsg.setMTI("1644");

            myISOMsg.set(24, "697");

            myISOMsg.set("48.0105", "002080116DE33XXXXXXX00001");

            myISOMsg.set("48.0122", "T");

            myISOMsg.set("48.0191", "2");

            myISOMsg.set(71, "00000001");

            GenericPackager packager = new GenericPackager("ipm_iso93binary.xml");

            evt.addMessage (myISOMsg);

            myISOMsg.setPackager(packager);

            myISOMsg.recalcBitMap();

            BitSet bset = (BitSet) myISOMsg.getValue(-1);

            System.out.println("Message: " +ISOUtil.hexString(myISOMsg.pack()));

            System.out.println("BitMap : " + bset.toString());

            System.out.println("BitMap : "  +org.jpos.iso.ISOUtil.bitSet2String(bset));

            System.out.println(new String(myISOMsg.pack()));

OUT PUT:

Message: F1F6F4F480000100000100000200000000000000F6F9F7F0F4F8303130353032353030323038303131364445333358585858585858303030303130313232303031543031393130303132F0F0F0F0F0F0F0F1

BitMap : {24, 48, 71}

BitMap : 00000000000000000000000010000000000000000000000010000000000000000000000100000000000000000000000000000000000000000000000000000000

i am expecting a out put like this where you will have MIT and other fields will be in EBCDIC format and bitmap will be in binary format, please let me know your thoughts

Expected Output :

ñöôô€00000000000000000000000010000000000000000000000010000000000000000000000100000000000000000000000000000000000000000000000000000000öù÷ðôø0105025002080116DE33XXXXXXX000010122001T01910012ðððððððñ

[Mark Salter]

^
MTI
^
Bitmap starts
^
Bitmap ends
This is a hexadecimal representation of the binary data. each character
represents a nibble (half a byte) the first nibble is :-

8 = b'1000'
1 = b'0001'
2 = b'0010'

In the Bitmap you can see 4 bits are on - the first indicates that the
secondary bitmap is present (do you want this?).

> BitMap : {24, 48, 71}

These are the fields you set and this matches.

> BitMap :
> 00000000000000000000000010000000000000000000000010000000000000000000000100000000000000000000000000000000000000000000000000000000
This is a binary representation of the Bitmap (but does not show that
bit 1 is on (and secondary Bitmap is present - I was not expecting that)

>
>
> i am expecting a out put like this where you will have MIT and other fields
> will be in EBCDIC format and bitmap will be in binary format, please let me
> know your thoughts
>
> Expected Output :
>
> ñöôô€00000000000000000000000010000000000000000000000010000000000000000000000100000000000000000000000000000000000000000000000000000000öù÷ðôø0105025002080116DE33XXXXXXX000010122001T01910012ðððððððñ

This seems an unlikely combination, but you have the spec. I would
*not* expect a mix of EBCDIC and ASCII instead one or the other.

If the Bitmap sent is truly the binary character form, then you have the
wrong definition or (more likely) you have interpreted the spec incorrectly.

--
Mark

[Suresh Kumar]

·         I am refereeing the spec which is defined (europay.xml), where you can see that bitmap has binary data type for other fields it is EBCDIC datatype . I also Expecting the same kind of output

europay.xml

  <isofield

      id="0"

      length="4"

      name="MESSAGE TYPE INDICATOR"

      class="org.jpos.iso.IFA_NUMERIC"/>

  <isofield

      id="1"

      length="16"

      name="BIT MAP"

      class="org.jpos.iso.IFB_BITMAP"/>

  <isofield

      id="2"

      length="19"

      name="PAN - PRIMARY ACCOUNT NUMBER"

      class="org.jpos.iso.IFA_LLNUM"/>

  <isofield

      id="3"

      length="6"

      name="PROCESSING CODE"

      class="org.jpos.iso.IFA_NUMERIC"/>

 

> BitMap :

> 0000000000000000000000001000000000000000000000001000000000000000000000

> 0100000000000000000000000000000000000000000000000000000000

This is a binary representation of the Bitmap (but does not show that bit 1 is on (and secondary Bitmap is present - I was not expecting that)

 

·         I also agree mark, that first bit in the bitmap has to say whether we have a secondary bitmap or not. I believe this because we are defined the BITMAP as 16 length.

  <isofield

      id="1"

      length="16"

      name="BIT MAP"

      class="org.jpos.iso.IFB_BITMAP"/>

 

Is there any way we can have to bitmap first and second . if that is the case then we need two bitmap tags in XML file ?

 

I am confused here. L

[Mark Salter]

Suresh Kumar wrote:
> · I am refereeing the spec which is defined (europay.xml), where you

> can see that bitmap has binary data type for other fields it is EBCDIC
> datatype . I also Expecting the same kind of output

I'm afraid that the non-binary fields in this spec are ASCII (IF*A*...),
so perhaps you have selected a bad example?

>> BitMap :
>
>> 0000000000000000000000001000000000000000000000001000000000000000000000
>
>> 0100000000000000000000000000000000000000000000000000000000
>
> This is a binary representation of the Bitmap (but does not show that bit 1
> is on (and secondary Bitmap is present - I was not expecting that)
>
>
>
> · I also agree mark, that first bit in the bitmap has to say whether
> we have a secondary bitmap or not. I believe this because we are defined the
> BITMAP as 16 length.

No, the length allows the Bitmap to get up to that size, the second
bitmap is present because field 71 is present and this fields bit
indicator is in the second bitmap (>64).

> Is there any way we can have to bitmap first and second . if that is the
> case then we need two bitmap tags in XML file ?

You shouldn't need to worry about the bitmap format more than picking
(or creating) the correct class to deal with it.

Start at the beginning:-

In your own words (don't post the spec), what does your spec say about
the bitmap content and structure?

--
Mark

[Suresh Kumar]

Mark the the first Bit Map  is a series of 64 bits that identify the presence (denoted by 1) or the absence (denoted by 0) of Data Element 1 (Secondary Bit Map) through Data Element 64  in the message.

A total bit map mechanism of 128 bits comprises these two bit maps to select any combination of the 128 standard ISO data elements within an  message.

Data Element 1 (that is Bit Map, Secondary) is a series of 64 bits that identify the presence (denoted by 1) or the absence (denoted by 0) of Data Element 65 through Data Element 128  in the message.

Here as per the bitmap created by JPOS, it creates only a single string which has both primary and secondary attached together, but when i read the spec it says it has to be two different strings.For the Secondary bitmap (that is Data Element 1) must be the third data field of every  message following the MTI and Bit Map, Primary.

Thanks a lot :)

[chhil]

Back to the basics...

Take for example fields  2,3,4 ,65,66 are present in your message.

Can you write down on a piece of paper  what you bitmap should look like (hex values) when it is sent over to your host.

Then use jpos, create a message to set these fields and see the dump to see if the bitmap looks identical.

Have you purchased have the programmers guide?

It has a good ISO8583 primer inside it.

-chhil

You have the primary bitmap there is an indication in the primary bitmap if the secondary exists.

[Mark Salter]

Suresh Kumar wrote:
[snipped and ignored "sucking eggs" lesson 8)]

>
> Here as per the bitmap created by JPOS, it creates only a single string
> which has both primary and secondary attached together, but when i read the
> spec it says it has to be two different strings.

This is a stream of data. *If* the EFT systems wants *two* *different*
strings, can I ask how the end of the first or the start of the second
is indicated. If there is no delimiter, then one field will do.

> For the Secondary bitmap
> (that is Data Element 1) must be the third data field of every message
> following the MTI and Bit Map, Primary.

>From what you are saying, it seems that *both* bitmap fields are
*always* present? Is this correct?

'Normally' you see, the second Bitmap is only present if it holds any
non-zero value and the first bit of the primary bitmap indicates if the
secondary bitmap is present (or not).

So what does the first (left most) bit of your primary bitmap indicate
the presence of ?

--
Mark

[Suresh Kumar]

Hi all,

 

Let me explain you what I am trying for. I created a message which has field 24,48 and 71 are set. Now I am printing bitmap to make sure it was properly set. As I have the field 71, JPOS shoud create me the secondary bitmap also and it has to set the first bit in the primary bitmap as 1.

However I can't see the first bit as 1 in the primary bitmap. Here is the code which I tried and the part of xml file.

 

 

    public void createHeader() {

        LogEvent evt = new LogEvent (this, "Test");

        try {

            ISOMsg myISOMsg = new ISOMsg();

            myISOMsg.setMTI("1644");

            myISOMsg.set(24, "697");

            myISOMsg.set("48.0105", "33");

            myISOMsg.set("48.0122", "T");

            myISOMsg.set("48.0191", "2");

            myISOMsg.set(71, "00000001");

            GenericPackager packager = new GenericPackager(xmlPath);

            evt.addMessage (myISOMsg);

            myISOMsg.setPackager(packager);

            myISOMsg.pack();

            BitSet bset = (BitSet) myISOMsg.getValue(-1);

            System.out.println("BitMap : "  +org.jpos.iso.ISOUtil.bitSet2String(bset));

        } catch (Exception ex) {

            evt.addMessage (ex);

        }

        Logger.log (evt);

    }

 

OUTPUT :

 

BitMap : 00000000000000000000000010000000000000000000000010000000000000000000000100000000000000000000000000000000000000000000000000000000

 

****Do you have any idea why the first bit is not 1?

 

 

 

<log realm="test" at="Tue Nov 25 17:15:57 IST 2008.709">

  <Test>

    <isomsg>

      <field id="0" value="1644"/>

      <field id="24" value="697"/>

      <isomsg id="48">

        <field id="105" value="002080116DE33XXXXXXX00001"/>

        <field id="122" value="T"/>

        <field id="191" value="2"/>

      </isomsg>

      <field id="71" value="00000001"/>

    </isomsg>

  </Test>

</log>

 

 

XML File :

 

  <isofield

      id="0"

      length="4"

      name="Message Type Identifier"

      pad="false"

      class="org.jpos.iso.IFE_NUMERIC"/>

  <isofield

      id="1"

      length="16"

      name="Bit Maps (Primary and Secondary)"

      class="org.jpos.iso.IFB_BITMAP"/>

  <isofield

      id="2"

      length="19"

      name="Primary Account Number (PAN)"

      pad="false"

      class="org.jpos.iso.IFE_LLNUM"/>

Thanks.

[chhil]

I think you will need to somehow start debugging your code to figure some of these things out.

If you debug the code you will realize that the 

BitSet bset = (BitSet) myISOMsg.getValue(-1); returns the "fields" that are set.

If you do a hexdump you will see that the first bit is set when the secondary bitmap has fields set.

-chhil

[Mark Salter]

Suresh Kumar wrote:

> Let me explain you what I am trying for. I created a message which has field
> 24,48 and 71 are set. Now I am printing bitmap to make sure it was properly
> set. As I have the field 71, JPOS shoud create me the secondary bitmap also
> and it has to set the first bit in the primary bitmap as 1.

From what I can see it is working perfectly, but let's go through it
carefully.

>
> However I can't see the first bit as 1 in the primary bitmap. Here is the
> code which I tried and the part of xml file.

In the hexadecimal version from a previous post (with my comments) :-

F1F6F4F480000100000100000200000000000000F6F9F7F0F4F8303130353032353030323038303131364445333358585858585858303030303130313232303031543031393130303132F0F0F0F0F0F0F0F1
^
MTI (ebcdic character-1644)
^
Bitmap starts (x'80' = b'10000000' - secondary bit map is present!)
^
Bitmap ends
Can you see it now? Please say yes.

So jPos is working...?

Now onto your binary representation....

>
> BitSet bset = (BitSet) myISOMsg.getValue(-1);
>

> System.*out*.println("BitMap : " +org.jpos.iso.ISOUtil.*
> bitSet2String*(bset));
> *OUTPUT* :
>
>
> BitMap :
> 00000000000000000000000010000000000000000000000010000000000000000000000100000000000000000000000000000000000000000000000000000000
>
>
>
> *****Do you have any idea why the first bit is not 1?*
In a previous post I did state:-

"
This is a binary representation of the Bitmap (but does not show that
bit 1 is on (and secondary Bitmap is present - I was not expecting that)
"

I think this is part of the flow being 'helpful' but I can't see where
it is being adjusted...

...perhaps within the cast to a BitSet?

I need to step through your code and the methods called to see what is
happening, perhaps you could try that? Having skimmed the code
(getValue/bitSet2String) I can't see anything obvious, but think that
the pack result adjusts the byte[] returned - I seem to recall a comment
to that effect - but can't see it now.

But in summary, the packed message looks right (to me), so the fact that
your diagnostics traces do not reflect the true position feels a little
less important. Unless your bitmaps are actually the wrong format?

--
Mark

[Mark Salter]

Mark Salter wrote:
> I need to step through your code and the methods called to see what is
> happening, perhaps you could try that? Having skimmed the code
> (getValue/bitSet2String) I can't see anything obvious, but think that
> the pack result adjusts the byte[] returned - I seem to recall a comment
> to that effect - but can't see it now.

Found it...

/**
* converts a BitSet into a binary field
* used in pack routines
* @param b - the BitSet
* @param bytes - number of bytes to return
* @return binary representation
*/
public static byte[] bitSet2byte (BitSet b, int bytes)
{
int len = bytes * 8;

byte[] d = new byte[bytes];
for (int i=0; i<len; i++)
if (b.get(i+1))
d[i >> 3] |= (0x80 >> (i % 8));
* //TODO: review why 2nd & 3rd bit map flags are set here??? *
if (len>64)
d[0] |= 0x80;
if (len>128)
d[8] |= 0x80;
return d;
}

Obviously this code mostly works (and is working for you), but in a
fixed length bitmap - I suspect it might cause problems.

So...

The bit indicating secondary/tertiary bitmap presence is only set in the
*result* of a pack, not in the value held in the '-1' value of an ISOMsg.

--
Mark

[Suresh Kumar]

Thanks a lot mark and chhil. now i am clear how JPOS works with Bitmap Binary.

thanks a lot again for your help.