Bad Bitmap

classic Classic list List threaded Threaded
6 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Bad Bitmap

igvalentin
Hello.

I am trying to deconstruct a sample ISO8583 message in order to set-
up a script that will actually build such messages.
I am expecting to get some fields but no matter what packagers I use
the fields does not seem to match.

The input message is:
F1F6F4F40040801001028000000003000000000000000050601002024F696F014FF2F
0F0F5F0F6F0F1F0F0F2F0F2F4003F111F000000001F012FC6C9D3C8F0F1F0F0D7D9D6
C44040404040404040404040404040404040404040404040404040404040404040404
040404040404040404040404040404040404040404040404040404040404040404040
404040404040404040404040404040404040404040404040404040404040404040404
040404040404040404040404040404040404040404040404040404040404040404040
404040404040404040404040404040404040404040404040404040404040404040404
040404040404040404040404040404040404040404040404040404040404040404040
404040404040404040404040404040404040404040404040404040404040404040404
040404040404040404040404040404040404040404040404040404040404040404040
404040404040404040404040404040404040404040404040404040404040404040404
040404040404040404040404040404040404040404040404040404040404040404040
404040404040404040404040404040404040404040404040404040404040404040404
040404040404040404040404040404040404040404040404040404040404040404040
404040404040404040404040404040404040404040404040404040404040404040404
040404040404040404040404040404040404040404040404040404040404040404040
404040404040404040404040404040404040404040404040404040404040404040404
040404040404040404040404040404040404040404040404040404040404040404040
404040404040404040404040404040404040404040404040404040404040404040404
040404040404040404040404040404040404040404040404040404040404040404040
404040404040404040404040404040404040404040404040404040404040404040404
040404040404040404040404040404040404040404040404040404040404040404040
404040404040404040404040404040404040404040404040404040404040404040404
040404040404040404040404040404040404040404040404040404040404040404040
404040404040404040404040404040404040404040404040404040404040404040404
040404040404040404040404040404040404040404040404040404040404040404040
404040404040404040404040404040404040404040404040404040404040404040404
040404040404040404040404040404040404040404040404040404040404040404040
404040404040404040404040404040404040404040404040404040404040404040404
04040404040404040404040404040404040404040404040404040404040

The result i get is:
<bitmap>{10, 17, 28, 40, 47, 49}</bitmap>
    <unpack fld="10" packager="org.jpos.iso.IFB_NUMERIC">
      <value>00000300</value>
    </unpack>
    <unpack fld="17" packager="org.jpos.iso.IFB_NUMERIC">
      <value>0000</value>
    </unpack>
    <unpack fld="28" packager="org.jpos.iso.IFB_AMOUNT">
      <value>

When using the genericpackager example, the number of fields seem to
be correct but the actual field numbers are not the expected ones.
Instead of 10, 17 ... i was expecting fields 12, 24, 31, 33, 42, 71,
72.
I tryed other packagers (not all of them) but the results were much
worse. Can you please help me with a hint?







 
Yahoo! Groups Links

<*> To visit your group on the web, go to:
    http://groups.yahoo.com/group/jpos-dev/

<*> To unsubscribe from this group, send an email to:
    [hidden email]

<*> Your use of Yahoo! Groups is subject to:
    http://docs.yahoo.com/info/terms/
 


Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Bad Bitmap

Mark Salter
igvalentin wrote:
> Hello.
>
> I am trying to deconstruct a sample ISO8583 message in order to set-
> up a script that will actually build such messages.

Can you tell us where you got this sample message from?

> I am expecting to get some fields but no matter what packagers I use
> the fields does not seem to match.
>
> The input message is:
> F1F6F4F40040801001028000000003000000000000000050601002024F696F014FF2F
[snip]

I have assumed this is the real start of the message, x'F1F6F4F4' is
EBCDIC 1644 which is described in the result of a google search for :-

        +1644 +MTI +8583

As "ADMINISTRATIVE_NOTIFICATION".  Does this match (in any way) your
sample description?  You seem to have a large number of trailing spaces
that I would think do *not* form part of your message (x'40' is an
EBCDIC space).

> i was expecting fields 12, 24, 31, 33, 42, 71, 72.

Why do expect these fields, do you have a layout or explanation of this
sample?  Does it define each field structure at the same time it
indicates what fields are present?

> I tryed other packagers (not all of them) but the results were much
> worse. Can you please help me with a hint?

I hope your answers to some of my questions will provide their own hints.

Best of luck, and let us know.

--
Mark


 
Yahoo! Groups Links

<*> To visit your group on the web, go to:
    http://groups.yahoo.com/group/jpos-dev/

<*> To unsubscribe from this group, send an email to:
    [hidden email]

<*> Your use of Yahoo! Groups is subject to:
    http://docs.yahoo.com/info/terms/
 



Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Bad Bitmap

igvalentin


--- Mark Salter <[hidden email]> wrote:

> igvalentin wrote:
> > Hello.
> >
> > I am trying to deconstruct a sample ISO8583
> message in order to set-
> > up a script that will actually build such
> messages.
>
> Can you tell us where you got this sample message
> from?
The sample is used as ani input file for a
TietoEntonator card processing solution. We want to
use the format to import clearing and settlement
messages for e-commerce transactions.
>
> > I am expecting to get some fields but no matter
> what packagers I use
> > the fields does not seem to match.
> >
> > The input message is:
> >
>
F1F6F4F40040801001028000000003000000000000000050601002024F696F014FF2F

> [snip]
>
> I have assumed this is the real start of the
> message, x'F1F6F4F4' is
> EBCDIC 1644 which is described in the result of a
> google search for :-
>
> +1644 +MTI +8583
>
> As "ADMINISTRATIVE_NOTIFICATION".  Does this match
> (in any way) your
> sample description?  You seem to have a large number
> of trailing spaces
> that I would think do *not* form part of your
> message (x'40' is an
> EBCDIC space).

The MTI is indeed 1644, representing a file header.
After the MTI there are another 4 hex digits (0040)
and after that the 2 bitmaps.
I managed to read the bitmaps (by specifying a length
of 6 for the MTI :)) ) and to get the correct data
fields (12, 24 ...) but I still cant explain the 0040.
More than that, after analysing the data fields, they
do not seem to match the bitmap (data fields are
misplaced, probably by interfields additions).
I think there is similar additional data (like 0040)
betweeb the data fields. What file format could that
be and what pre or post processing do I have to apply?
One thing is sure: the file is a genuine input file
for the Tieto system so I need to find out what are
the additional characters between file fields.
>
> > i was expecting fields 12, 24, 31, 33, 42, 71, 72.
>
>
> Why do expect these fields, do you have a layout or
> explanation of this
> sample?  Does it define each field structure at the
> same time it
> indicates what fields are present?
The file contains:
- file headers: MTI1644 with fields 12, 24, 31, 33,
71, 72

ISO-field Description Max.
length Variable
length Length
ind. Mandatory
12 Date and time, local (YYMMDDhhmmss) 12,0
24 Function code: 696 3,0 Yes
31 Acquiring reference data. Unique file Id. 15A Yes 2
Yes
33 Forwarding institution identification code,
counterpart institution Id 11,0 Yes 2
71 Message number: 00000001 8,0 Yes
72 Data record 12A Yes 3

- batch headers: MTI1644 with fields 12, 24, 31, 33,
71, 72
- transactions: MTI 1240 and 1440 with fields
2,3,4,12,14,22,24,26,31,33,38,48,49,71,72

Getting the corect data fields for the file header
would be enough to process the whole file (the purpose
is to be able to create such files from a CSV file),
the problem is that I cant find anything in our
documentation about intermediary data (such as 0040
between MTI and bitmap or 0 between the bitmap and the
first present data field). For example, between the
bitmap and the second data field, the characters used
by the first data field (a time/date value
YYMMDDhhmmss) are "0050601002024F". The correct value
should be 050601002024. There are an additional 0
before and an F after.
The documentations says it is a standard ISO 8583:1993
bittmapped file in EBCDIC format. What do you think is
missing?
>
> > I tryed other packagers (not all of them) but the
> results were much
> > worse. Can you please help me with a hint?
>
> I hope your answers to some of my questions will
> provide their own hints.
I found some answers but the freaking file format is
still a mistery. The mistery will be solved in 2
months when our software supplyer will have the
resources to deal with our request, but the term is
too long.
If I could decompose the format and use jPos to create
such messages the project I work at could be completed
much sooner.
Do you have any idea that could help me?
Anyway, thank you for your response!

Vali

>
> Best of luck, and let us know.
>
> --
> Mark
>


__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around
http://mail.yahoo.com 


 
Yahoo! Groups Links

<*> To visit your group on the web, go to:
    http://groups.yahoo.com/group/jpos-dev/

<*> To unsubscribe from this group, send an email to:
    [hidden email]

<*> Your use of Yahoo! Groups is subject to:
    http://docs.yahoo.com/info/terms/
 


Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Bad Bitmap

Mark Salter
Ion Valentin wrote:
> For example, between the
> bitmap and the second data field, the characters used
> by the first data field (a time/date value
> YYMMDDhhmmss) are "0050601002024F". The correct value
> should be 050601002024. There are an additional 0
> before and an F after.
This 0 is just byte alignment to allow the inclusion of the ending F.
This is probably a "packed decimal" where the F indicates a positive
value, this doesn't really make sense on a date field - unless it was a
relative value.  Other sign values on "packed decimal" are :-

Positive F,A,C & E
Negative D & B

so in two bytes ...

x'001F'  is 1+
x'002D'  is 2-

I am on my way out to work, so will try to comeback further later.
Sorry for the delay.

If you could send me the sample file, that might help - use my email
directly rather than clutter this list.

--
Mark

> The documentations says it is a standard ISO 8583:1993
> bittmapped file in EBCDIC format. What do you think is
> missing?
>
>>>I tryed other packagers (not all of them) but the
>>
>>results were much
>>
>>>worse. Can you please help me with a hint?
>>
>>I hope your answers to some of my questions will
>>provide their own hints.
>
> I found some answers but the freaking file format is
> still a mistery. The mistery will be solved in 2
> months when our software supplyer will have the
> resources to deal with our request, but the term is
> too long.
> If I could decompose the format and use jPos to create
> such messages the project I work at could be completed
> much sooner.
> Do you have any idea that could help me?
> Anyway, thank you for your response!
>
> Vali
>
>
>>Best of luck, and let us know.
>>
>>--
>>Mark
>>
>
>
>
> __________________________________________________
> Do You Yahoo!?
> Tired of spam?  Yahoo! Mail has the best spam protection around
> http://mail.yahoo.com 
>
>
>  
> Yahoo! Groups Links
>
>
>
>  
>
>
>


--
Mark


 
Yahoo! Groups Links

<*> To visit your group on the web, go to:
    http://groups.yahoo.com/group/jpos-dev/

<*> To unsubscribe from this group, send an email to:
    [hidden email]

<*> Your use of Yahoo! Groups is subject to:
    http://docs.yahoo.com/info/terms/
 


Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Bad Bitmap

Mark Salter
In reply to this post by igvalentin
 From the sample file provide (via email) I surmise that :-

1. There is currently no packager in JPos which supports this layout.

2. We will need to write some new field formats, which will mean work.

3. It looks to me that a transfer (perhaps ftp) from a variable record
length file to a fixed record file has been done.  Possibly between two
EBCDIC mainframes or perhaps a 3270 file transfer to a pc?  The fixed
record length is 1330 bytes.

4. An slightly insane mind has been at work, and this person just loved
packed decimal (COMP-3) fields.  They are his best and perhaps only
friend! 8)

When I break down the first record we have (in HEX, with any strings
[c'xx'] in EBCDIC)...

F1F6F4F4
     The record type c'1644'

0040
     The binary length of the record data that follows (64 bytes)

80100102800000000300000000000000
     The two 8 byte bitmaps

0050601002024F
     a padded 7 bytes of packed decimal 0YYMMDDhhmmssF

696F
     the function code again packed decimal - no pad needed

014FF2F0F0F5F0F6F0F1F0F0F2F0F2F4
     two byte packed dec length + data - c'20050601002024'
     which is the date/time again YYYYMMDDhhmmss?

003F111F
    two byte packed dec length + data 111F

000000001F
    the record number - packed decimal again

012FC6C9D3C8F0F1F0F0D7D9D6C4
     two byte packed dec length + data - c'FILH0100PROD'

40 * lots
     padding up to the 1030 byte record

Then it starts again with a new record ...

I hope that helps gets you going, and sorry I did not get back until
this evening!


--
Best regards
Mark


 
Yahoo! Groups Links

<*> To visit your group on the web, go to:
    http://groups.yahoo.com/group/jpos-dev/

<*> To unsubscribe from this group, send an email to:
    [hidden email]

<*> Your use of Yahoo! Groups is subject to:
    http://docs.yahoo.com/info/terms/
 


Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Bad Bitmap

igvalentin
Thank you for your support.
I hope this will get me started.
Best regards,
Vali



--- In [hidden email], Mark Salter <marksalter@d...> wrote:
>  From the sample file provide (via email) I surmise that :-
>
> 1. There is currently no packager in JPos which supports this
layout.
>
> 2. We will need to write some new field formats, which will mean
work.
>
> 3. It looks to me that a transfer (perhaps ftp) from a variable
record
> length file to a fixed record file has been done.  Possibly
between two
> EBCDIC mainframes or perhaps a 3270 file transfer to a pc?  The
fixed
> record length is 1330 bytes.
>
> 4. An slightly insane mind has been at work, and this person just
loved
> packed decimal (COMP-3) fields.  They are his best and perhaps
only
> friend! 8)
>
> When I break down the first record we have (in HEX, with any
strings

> [c'xx'] in EBCDIC)...
>
> F1F6F4F4
>      The record type c'1644'
>
> 0040
>      The binary length of the record data that follows (64 bytes)
>
> 80100102800000000300000000000000
>      The two 8 byte bitmaps
>
> 0050601002024F
>      a padded 7 bytes of packed decimal 0YYMMDDhhmmssF
>
> 696F
>      the function code again packed decimal - no pad needed
>
> 014FF2F0F0F5F0F6F0F1F0F0F2F0F2F4
>      two byte packed dec length + data - c'20050601002024'
>      which is the date/time again YYYYMMDDhhmmss?
>
> 003F111F
>     two byte packed dec length + data 111F
>
> 000000001F
>     the record number - packed decimal again
>
> 012FC6C9D3C8F0F1F0F0D7D9D6C4
>      two byte packed dec length + data - c'FILH0100PROD'
>
> 40 * lots
>      padding up to the 1030 byte record
>
> Then it starts again with a new record ...
>
> I hope that helps gets you going, and sorry I did not get back
until
> this evening!
>
>
> --
> Best regards
> Mark




 
Yahoo! Groups Links

<*> To visit your group on the web, go to:
    http://groups.yahoo.com/group/jpos-dev/

<*> To unsubscribe from this group, send an email to:
    [hidden email]

<*> Your use of Yahoo! Groups is subject to:
    http://docs.yahoo.com/info/terms/
 


Loading...