Strange length field in LLNUM

[merzberger1]

Hello
I am on day one with ISO 8583, so I fully expect to be proven an idiot due
to my question ;-)

Anyway: We seem to get a particularly messy dialect of ISO 8583. All
variable length fields seem to be too long. See for example this field (33,
Institution Code):
0009123456789
It's supposed to be a length 9 numeric value (LLVAR). The first double pair
of zeroes seems to be extra.

Another field looks even stranger:
00140030000000800000002013060600
It's a private extension (48) field of (manually counting) 28 length. How
"0014" can encode 20 is beyond my understanding.

Doey anyone understand what's going on here?

Many thanks, Martin



--
View this message in context: http://jpos.1045706.n5.nabble.com/Strange-length-field-in-LLNUM-tp5711972.html
Sent from the jPOS - Users mailing list archive at Nabble.com.

[Andy Orrock]

We would need to see the entire message before passing judgment.  Otherwise, who's to say your packager didn't jump off the rails pre-33?

Andy 

--
--
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

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.
For more options, visit https://groups.google.com/groups/opt_out.

[Zablon Ochomo]

may be you try to wireshark your messages and put the tcp dumps here.

[Mark Salter]

On 06/06/2013 14:08, merzberger1 wrote:

> Anyway: We seem to get a particularly messy dialect of ISO 8583. All
> variable length fields seem to be too long. See for example this field (33,
> Institution Code):
> 0009123456789
> It's supposed to be a length 9 numeric value (LLVAR). The first double pair
> of zeroes seems to be extra.

Unless 'LL' is defined as 4 bytes (are these characters represtsenting
the data or hex (with a missing half-byte?) ) - does the documentation
define 'LL' at all?

>
> Another field looks even stranger:
> 00140030000000800000002013060600
> It's a private extension (48) field of (manually counting) 28 length. How
> "0014" can encode 20 is beyond my understanding.

It's is probably binary...

x'0014' = decimal 20 (16+4)

--
Mark

[chhil]

It looks like ascii lengths
00 09 123456789
This one probably is a binary field where 14 bytes are expanded to 28 ascii as shown for display purpose?
00 14 0030000000800000002013060600

-chhil

[merzberger1]

Thank you all for the quick responses!
The message is out of the logfile of a test driver, so it may be "corrupt"
in some way. The full message is this:
003D6467948082200000800100000400000010000000060609155509155500090123456789001400300000008000000020130606000001000899999999

The first few bytes are header, the message starts with "9480". As per the
bitmap, fields 7,11,33,48,70 and 100 are present.

The parser get me this (when I feed it only the message, without the
header):
MTI : 9480
Field-7 : 0606091555
Field-11 : 091555
Field-33 :
Field-48 : 012345678
Field-70 : 900
Field-100 : 140030000000

It's correct up to and including field 11. Field 33 is where it gets wrong,
because of the misleading length field. I can remove the extra zeroes, but
the the parser fails on field 48, again due to the wrong length field.

Thanks! Martin



--
View this message in context: http://jpos.1045706.n5.nabble.com/Strange-length-field-in-LLNUM-tp5711972p5711979.html

[merzberger1]

One should read the documentation first... Our provider states on almost all
length fields that they deviate from the standard, and use "n4" instead of
"LL" or "LLL".
So I guess I would have to extend the code to support these data types.



--
View this message in context: http://jpos.1045706.n5.nabble.com/Strange-length-field-in-LLNUM-tp5711972p5711980.html

[Mark Salter]

On 06/06/2013 15:12, merzberger1 wrote:

> The first few bytes are header,

How many bytes? looks like a length - which the Channel will take are of...

> the message starts with "9480".

Ok

> As per the
> bitmap, fields 7,11,33,48,70 and 100 are present.
>
> The parser get me this (when I feed it only the message, without the
> header):
> MTI : 9480
> Field-7 : 0606091555
> Field-11 : 091555
> Field-33 :

So the length is likely mismatched with your packager, what is your
field 33 defined as?

It might be taking the first byte only (00) and then going out of line.

Check the documentation again for their definition of LLVAR.

> Field-48 : 012345678
> Field-70 : 900
> Field-100 : 140030000000
>
> It's correct up to and including field 11. Field 33 is where it gets wrong,
> because of the misleading length field. I can remove the extra zeroes, but
> the the parser fails on field 48, again due to the wrong length field.

Please check the definition of this field too in the documentation too.

I would suggest you check the specification and rule out that the 'test
driver' is not really "corrupt" - otherwise you might be wasting your
time too.



--
Mark

[merzberger1]

Hello

Thanks for all reponses so far. I could decone one mystery at last, but I
don't know how to set the parser to actually decode it. Hopefully someone
else has more know-how with JPOS...

- The numeric fields in the messages of my provider are BCD coded, with an
even number of bytes (left-padded with a zero nibble if needed).
- All variable length fields length are given as "n4" instead of e.g. LLVAR
or LLLVAR.

-> For example, an n3 field with a value of "555" would look like "0555".
-> A variable length field of the same content would loke like "00030555".

So, how can I read the second example above?
LLLLCHAR gives me "055", and then has an extra "5" which comes into the way
of the next field.
What I would need is a variable length BCD datatype which knows that it
needs to read 4 bytes if the length is specified as "3", and then strip the
leftmost "0" nibble from the result.

Does something like this exist?

Thanks! Martin



--
View this message in context: http://jpos.1045706.n5.nabble.com/Strange-length-field-in-LLNUM-tp5711972p5712030.html

[chhil]

You will use the  IFB_*  field packagers, take a look at the code and its  test cases available in the frameworks source.

e.g.
public class IFB_FLLLNUM extends ISOStringFieldPackager {
    public IFB_FLLLNUM() {
        super(NullPadder.INSTANCE, BCDInterpreter.RIGHT_PADDED_F, BcdPrefixer.LLL);
    }
    /**
     * @param len - field len
     * @param description symbolic descrption
     */
    public IFB_FLLLNUM(int len, String description, boolean isLeftPadded) {
        super(len, description, NullPadder.INSTANCE,
                isLeftPadded ? BCDInterpreter.LEFT_PADDED : BCDInterpreter.RIGHT_PADDED_F,
                BcdPrefixer.LLL);
        checkLength(len, 999);
    }

-chhil