EBCDIC file parsing using JPOS Mastercard

[Victor]

Hi All,

Currently, I am working on EBCDIC format auth test file parsing for Mastercard, and hence needed the JPOS packager.xml/Java class which has the Data element definitions, to parse the messages correctly including the subelements/subfields in addition to basic DE fields.

Thanks,

Victor

[Prabhanshu Choubey]

Warm regards JPOS Committee.

Just wanted to check if there is any response for the query mentioned below.

Kindly assist.

Thanks,

Victor

--
--
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 Google Groups "jPOS Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to jpos-users+...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/jpos-users/ffaeb5bb-7cb3-4697-bbb6-7fe0e87ba125n%40googlegroups.com.

[Mark Salter]

On 02/02/2022 04:56, Prabhanshu Choubey wrote:
> Just wanted to check if there is any response for the query mentioned
> below.
>

I don't see any provided here?  Apart from your 'chaser' and now this
one of course!


> Kindly assist.

You need to ask a smart question, providing the details that may help
form a reply that is useful not only to you but others.

We don't know what file you have or what data it may hold or what format
it is in (other then ISO8583);  whilst we could guess and might get the
right thing, why would we waste our time when you have all the detail to
share.


Ask a smart question and I am sure you are much more likely to get a
useful reply than currently.

Please see here : http://www.catb.org/~esr/faqs/smart-questions.html

--

Mark

[Alejandro Revilla]

Mark,

Based on Prabhanshu's question "I am working on EBCDIC format auth test file parsing for Mastercard, and hence needed the JPOS packager.xml/Java class which has the Data element definitions" he's probably dealing with MasterCard IPM files in EBCDIC format. We do have those packagers and file processors (it involves some ancient record delimiters from old SNA days), but they are part of our commercial offering plus we can't open source them due to license limitations.

We can help with the definition of some fields here and there, but can't open source the turn key solution, mainly because the MC documentation is provided under NDA.

--

@apr

--
--
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 Google Groups "jPOS Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to jpos-users+...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/jpos-users/1f8c5f60-c0ad-7e7b-c576-e2d0b13bee94%40protonmail.com.

[Mark Salter]

On 04/02/2022 12:34, Alejandro Revilla wrote:

Mark,

Hell there :-)

We can help with the definition of some fields here and there, but can't open source the turn key solution, mainly because the MC documentation is provided under NDA.

Understood, and I agree that seems sensible and likely to be IPM, but you know how I love a smart question and hate 'lazy' ones ;-)/

--

Mark

[Alejandro Revilla]

I know, I know :)

--

@apr

[Prabhanshu Choubey]

Alejandro is right here with his statements 

"he's probably dealing with MasterCard IPM files in EBCDIC format. We do have those packagers and file processors".

If not for all the fields could you tell me for some complex fields having subelements and subfields(like DE48,DE126,DE112)

as it would in all help me to build my parsing logic for rest of the fields.

Thanks

To view this discussion on the web visit https://groups.google.com/d/msgid/jpos-users/CAAgSK%3D%3DFzjuZRm%2Bgm-BrWigjLHN-gotfWGCAFEWRfcJo0Mw9ew%40mail.gmail.com.

[murtuza chhil]

IPM comes in different formats, here is what we do with the form we receive it in.

We get files with ascii data and use ascii. equivalent of field packagers. 

Then we first remove all the "@@" present at the fixed offsets (1012) inside the file, we do this to not worry about keeping track of those and worrying about them in the middle if the message.

Then read 4 bytes(length of message)  and extract the length from bytes 3 and 4 and use that to read the the equivalent number of bytes for the message ,unpack and process. Repeat till end of file.

Field 48 we receive is in TLV form (tag is 4 wide, length is 3 wide and the value is as wide as the  length from the tLv. We get the string from the field and parse the tag length value into a map <tag,value>.

-chhil

[Prabhanshu Choubey]

Thanks Chhil,

We are receiving the files in EBCDIC format. Also we are trying to handle auth IPM files, for which the DE48 contains tag-2 length-2.

But just wanted to understand if you could share a snippet of the packager for DE48(which also includes the TCC) and DE126 field packagers, also let me know which JPOS offered parsing classes are being used for Tagged fields with Subelements and Subfields.

Thanks

To view this discussion on the web visit https://groups.google.com/d/msgid/jpos-users/d165533c-1da9-4207-a043-8a8254217dbdn%40googlegroups.com.

[chhil]

Since ours is ascii DE48 is defined as org.jpos.iso.IFA_LLLCHAR.

DE126 we don't use but its configured the same as DE48. Since yours is ebcdic you will probably use IFE_LLLCHAR.

We have our POJO that basically parses the TLV data string in DE48..

Read tag length bytes, read the length bytes, translate the length to an int and read those many more bytes for the value, put the tag and value in a map. Repeat until end of string. This is equivalent to the unpack. No rocket science. If you need to pack, put tag values in a map and create and appropriate tag length value from the map name value pair.

We don't get a TCC in the ipm DE48 (we get them in online Mastercard transaction in DE48), but if thats your case, the logic is almost the same...

Read first byte from DE48 string, that's your TCC, put it in the map as name=TCC and value to whatever that character was, then proceed with TLV parsing logic stated above.

-chhil

You received this message because you are subscribed to a topic in the Google Groups "jPOS Users" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/jpos-users/AaUM3kwnxmw/unsubscribe.
To unsubscribe from this group and all its topics, send an email to jpos-users+...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/jpos-users/CAFpRj02t%2Bc721fbctEhU4bt3mv6KLqcduaKMoA%3DMJWDGMOVuBQ%40mail.gmail.com.