The Bitmap in the message provides information on the presence of other fields in the message. While using jpos, one does not have to populate it, as this gets populated based on the fields added automatically.
![]()
To visualize the representation of the filds in the bitmap, lets consider the first 16 fields and represent the value of field as 0 (not present) and 1 (present). The table below illustrates the first two bytes of the bitmap and an indicator whether the field exists or not. A byte contains 8 bits, thus 8 fields can be represented in a byte using either 0 or 1.
![]()
While the binary representation can go in as byte, the ASCII/Hex packaging of the bitmap will result in the occupation of double the number of bytes, as each of the two char hex is converted into the byte equivalents of each field for a char representation.
Refer this wiki for more details.
The BitMap in the message can be represented either as a Binary BitMap (e.g IFB_BITMAP) or an Asci/Hex BitMap(e.g IFA_BITMAP). When the message is packed using a binary representation, the bitmap would occupy 16 bytes of the message, whereas in the ASCII representation it would occupy 32 charachters. It can be explained with the following Simple example.
Assume a message containing the following fields 2,3,6,11,12, 17, 64, 101 (including 0 as this is usually sent in all messages)
There are 8 bitmaps available, each bitmap representing the 128 fields available(ie 0 to 127)
The first 64 fields are considered as the primary bitmap and the next 64 to be the secondary, representing fields from 64 to 127. In many a message where we do not have to send the fields above 64 we do not even have to form the secondary bitmap.
8 * 16 = 128
So each byte in the bitmap can hold information of 8 fields. Lets arrive at the position for the fields selected.
The nearest multiple of 8 for 2 ,3, 6 is 8 and 8/8 = 1
The nearest multiple of 8 for 11 and 12 is 16 and 16/8 = 2
The nearest multiple of 8 for 17 is 24 and 24/8 = 3
The nearest multiple of 8 for 64 is 64 and 64/8 = 8
The nearest multiple of 8 for 101 is 104 and 104 = 13
The table below provides the Binary represenation of each byte for the above example. It can be noticed that there are a total of 128 0 and 1s which indicates the presence and absence of the field.
To visualize the representation of the filds in the bitmap, lets consider the first 16 fields and represent the value of field as 0 (not present) and 1 (present). The table below illustrates the first two bytes of the bitmap and an indicator whether the field exists or not. A byte contains 8 bits, thus 8 fields can be represented in a byte using either 0 or 1.
While the binary representation can go in as byte, the ASCII/Hex packaging of the bitmap will result in the occupation of double the number of bytes, as each of the two char hex is converted into the byte equivalents of each field for a char representation.
Consider a message packed using the byte representation having the above mentioned fields (assume for simplicity that all other fields contain char and not bytes). The bitmap usually falls outside the printable ASCII representation, hence have provided the decimal equivalent of the field only for the BitMaps
In the event that the same message is unpacked using an IFA_BITMAP instead of IFB_BITMAP, the parser expects 32 chars instead of 64 and for example would take the chars, in message 5 and 6 and take the byte equivalent, thus resulting in a parsing fields that would be totally different than what was actually passed, resulting in a failure on unpacking the message using JPOS.
Hope this helps someone looking at it in some way. Will be writing further on what needs to be done and care to be taken for packing and unpacking the ISO message using jpos.