Thanks in advance. Your help is much appreciated!
> Is it possible to config jpos.xml to have tertiary bitmap field
> encoded right after secondary bitmap? For example, the standard
> encoding order will be MTI, primary bitmap, secondary bitmap, field
> 2, ..., field 64, tertiary bitmap(field65), ...What the spec wants is
> MTI, primary bitmap, secondary bitmap, tertiary bitmap, field
> 2 ...Notice the tertiary bitmap is right after secondary bitmap.
Did you try it?
Could you?
I believe that the processing of the bitmap will result in the result
you require, bit 65 is used as an indicator of the third bitmaps
presence, not as an indicator of it's position in the message.
--
Mark
> Thanks for the reply, Mark.
> I did try it. Apparently, JPOS places tertiary bitmap in field 65 location,
> NOT after secondary bitmap. I looked the ISOBasePackager's pack and unpack
> methods, seems to be the case. Seems that I can override these two method in
> my extended packager class. But want to know if there is an easy way around.
After an unpack the third bitmap could well endup held in field 65,
but does it end up in the 'right' place after packing?
I recall previous questions around this subject, but will try and
confirm what should happen (and how it can be controlled) later today.
> I am relatively new to ISO, is the requirement (of placing third-bitmap
> right after second one) standard? Can anyone share your experience?
I feel it is, but it can and probably does vary from interface to
interface.
I wonder if we need to be clear...
...have you succesfully unpack()'d a message with a third bitmap, and
then repacked to find the result of the pack() does not match the
input?
--
Mark
On Feb 7, 8:45 am, "Mark Salter" <marksal...@dsl.pipex.com> wrote:
> jian liu wrote:
> > Thanks for the reply, Mark.
> > I did try it. Apparently, JPOS places tertiary bitmap in field 65 location,
> > NOT after secondary bitmap. I looked the ISOBasePackager's pack and unpack
> > methods, seems to be the case. Seems that I can override these two method in
> > my extended packager class. But want to know if there is an easy way around.
>
> After an unpack the third bitmap could well endup held in field 65,
> but does it end up in the 'right' place after packing?
Tertiary bitmap field is placed in location 65 in the packed message
(byte array). Not after secondary bitmap.
>
> I recall previous questions around this subject, but will try and
> confirm what should happen (and how it can be controlled) later today.
Thank you so much for looking it up.
>
> > I am relatively new to ISO, is the requirement (of placing third-bitmap
> > right after second one) standard? Can anyone share your experience?
>
> I feel it is, but it can and probably does vary from interface to
> interface.
It seems that JPOS implements it the other way.
>
> I wonder if we need to be clear...
> ...have you succesfully unpack()'d a message with a third bitmap, and
> then repacked to find the result of the pack() does not match the
> input?
I was able to unpack a message (with tertiary bitmap) *if* the bitamp
field in the byte array is located in the field 65 location, but NOT
if its right after secondary bitmap.
>
> --
> Mark
>
> I was able to unpack a message (with tertiary bitmap) *if* the bitamp
> field in the byte array is located in the field 65 location, but NOT
> if its right after secondary bitmap.
>
Have you specified a length of 24 for the bitmap field? (field 1)
Am I right in thinking jpos6 is also a requirement, looking at the
previous version, the ISOUtil.bitSet2byte appears not to mention 192 as
an upper limit?
--
Mark
------------------------------------------------------------------------
r2371 | apr | 2006-09-19 09:03:52 -0300 (Tue, 19 Sep 2006) | 2 lines
reworked 3rd bitmap support
I'm afraid you want to use jPOS 6.