Some wonders about creating header and TPDU!

524 views
Skip to first unread message

Chung vu

unread,
Mar 19, 2009, 3:01:39 AM3/19/09
to jpos-...@googlegroups.com
HI all ,

We have this standard log :

MPOS_1_TCP  : 10:32:17:14 |Dumping Hex Buffer Length = 2
MPOS_1_TCP  : 10:32:17:14 |00 2A                                                      
MPOS_1_TCP  : 10:32:17:14 |TCPLINKS: New Data on Socket. Events = 1
MPOS_1_TCP  : 10:32:17:14 |TCPLINKS: Received New [42] Bytes of Data.
MPOS_1_TCP  : 10:32:17:14 |TCPLINKS: Complete Message Data [42] Received.
MPOS_1_TCP  : 10:32:17:14 |TCPLINKS: Dump received Message Data:
MPOS_1_TCP  : 10:32:17:14 |Dumping Hex Buffer Length = 42

60 00 02 B7 20 08 00 22 20 00 00 00 80 00 10 93 00 00 00 00
00 00 00 00 01 03 31 33 33 30 30 30 30 33 00 06 30 30 30 30
30 31


This above message is sent from my POS to our system .
It is standard for my clone .

I understand that 002A is two bye header and  "60 00 02 B7 20" is TPDU.

We use NCCChannel for sending TPDU but how to send header with this above value ?

To code the client sending , i create the following step : is it okie and my understand is correct ?

1) Create custome package based on vendor specification
2) Create channel ( in my case is NCCChannel) for sending message from client .
3) We create   message with key-in value , for example:
        m.setMTI("0800");
        m.set(3, "000000");
        m.set(11, "000001");
        m.set(41, "29110001");
        m.set(60, "test");
        m.set(70, "301");


This value message  is ASCII so when we need to send message with NCCChannel and custom package
(ISOChannel channel = new org.jpos.iso.channel.NCCChannel("10.36.10.73",9302,new way4POSPackager(),ISOUtil.hex2byte("600002B720"))

Is it field format converted based on defined  custome package that named way4PosPackager and send out ?

Thanks for your help !
Regards
Chung



chhil

unread,
Mar 19, 2009, 4:02:16 AM3/19/09
to jpos-...@googlegroups.com
The channel is smart enough to prepend the length (2 byte header)
based on data that is set in your message. You do not need to worry
about it (you get it for free).
The packager takes care of packaging that data into the fields as
defined by your class.

You can try this out by using a simple server running on port 9302 and
point your channel to it. Use netcat (download it from the web) to
run a server listening on port 9302 and see the data that was sent by
your application. You would see the header in the hex data.



-chhil

Chung vu

unread,
Mar 19, 2009, 4:32:52 AM3/19/09
to jpos-...@googlegroups.com
Hi chillum,

I try to send message and have problems , i check the custom package : format and type is okie.Why is MTID is 0071 ? It is very strange

Log :

MPOS_2_TCP  : 15:16:08:11 |Change Message ID to [3] on Entry [1]
MPOS_2_TCP  : 15:16:08:11 |Insert Message Connection ID [3] and Entry [1]
MPOS_2_TCP  : 15:16:08:11 |New Data Received Length = 73
MPOS_2_TCP  : 15:16:08:11 |Just before ISO8583_ANALYSE
MPOS_2_TCP  : 15:16:08:11 |Received New Message, let dump it
MPOS_2_TCP  : 15:16:08:11 |Dumping Hex Buffer Length = 73
MPOS_2_TCP  : 15:16:08:11 |00 71 60 00 02 B7 20 30 38 30 30 41 30 32 30 30 30 30 30 30 .q`... 0800A02000000
MPOS_2_TCP  : 15:16:08:11 |30 38 30 30 30 31 30 30 34 30 30 30 30 30 30 30 30 30 30 30 08000100400000000000
MPOS_2_TCP  : 15:16:08:11 |30 30 30 30 30 30 30 30 30 30 30 30 30 30 31 32 39 31 31 30 00000000000000129110
MPOS_2_TCP  : 15:16:08:11 |30 30 31 30 30 34 74 65 73 74 33 30 31                      001004test301
MPOS_2_TCP  : 15:16:08:11 |Message Format: POS ISO8583
MPOS_2_TCP  : 15:16:08:11 |Received Message Type is 0071

Mark Salter

unread,
Mar 19, 2009, 4:53:45 AM3/19/09
to jpos-...@googlegroups.com
Chung vu wrote:

> We have this standard log :

Produced from an existing (non jPOS) system you are trying to send
messages to?

>
> MPOS_1_TCP : 10:32:17:14 |Dumping Hex Buffer Length = 2
> MPOS_1_TCP : 10:32:17:14 |00
> 2A
> MPOS_1_TCP : 10:32:17:14 |TCPLINKS: New Data on Socket. Events = 1
> MPOS_1_TCP : 10:32:17:14 |TCPLINKS: Received New [42] Bytes of Data.
> MPOS_1_TCP : 10:32:17:14 |TCPLINKS: Complete Message Data [42] Received.
> MPOS_1_TCP : 10:32:17:14 |TCPLINKS: Dump received Message Data:
> MPOS_1_TCP : 10:32:17:14 |Dumping Hex Buffer Length = 42
>

> *60 00 02 B7 20* 08 00 22 20 00 00 00 80 00 10 93 00 00 00 00


> 00 00 00 00 01 03 31 33 33 30 30 30 30 33 00 06 30 30 30 30
> 30 31
>
>
> This above message is sent from my POS to our system .
> It is standard for my clone .
>

> I understand that 002A is two bye header and "*60 00 02 B7 20"* is TPDU.

x'002A' (decimal 42) is the length of the message that has arrived into
this system. Calling it a header might confuse things later; perhaps
call it the message length?

> We use NCCChannel for sending TPDU but how to send header with this above
> value ?

The Channel will calculate and send the length for you.


>
> To code the client sending , i create the following step : is it okie and my
> understand is correct ?
>
> 1) Create custome package based on vendor specification
> 2) Create channel ( in my case is NCCChannel) for sending message from
> client .
> 3) We create message with key-in value , for example:
> m.setMTI("0800");
> m.set(3, "000000");
> m.set(11, "000001");
> m.set(41, "29110001");
> m.set(60, "test");
> m.set(70, "301");
>
>
> This value message is ASCII so when we need to send message with NCCChannel
> and custom package

> *(ISOChannel channel = new
> org.jpos.iso.channel.NCCChannel("10.36.10.73",9302,new
> way4POSPackager(),ISOUtil.hex2byte("600002B720"))*


>
> Is it field format converted based on defined custome package that named
> way4PosPackager and send out ?

Yes.

Your way4POSPackager will be asked by the NCCChannel to pack each
ISOMsg. This will result in a byte[] holding the message as it will
travel over the network. The NCCChannel will then preprend the message
length in the format it needs and place it onto the network connection,
followed by the message onto the network.

So in summary, the NCCChannel looks after the length, the
way4PosPackager looks after converting the String values you placed in
the fields into the raw representaion. This allows your code to just
handle Strings and passes the work of conversion to ASCII/EBCDIC/Binary
and length calculations to jPOS.

--
Mark

Chung vu

unread,
Mar 19, 2009, 5:06:20 AM3/19/09
to jpos-...@googlegroups.com
Hi Mark,
Yes , it is from existing system ( non Jpos).
Thanks for your explanation.  It is very clear.
From this understand , i am not clear why message i try to send now , it has errors.
And we use message length ( not header ) , it is okie .
So declare like this is message lenthe is shown by 2 bytes , it that right?
ISOChannel channel = new org.jpos.iso.channel.NCCChannel("10.36.10.73",9302,new way4POSPackager(),new byte[]{(byte)002})

Log:

MPOS_2_TCP  : 15:47:46:45 |E[000]: Client IP Address [10.36.90.47] added to message
MPOS_2_TCP  : 15:47:46:45 |Change Message ID to [5] on Entry [0]
MPOS_2_TCP  : 15:47:46:45 |Insert Message Connection ID [5] and Entry [0]
MPOS_2_TCP  : 15:47:46:45 |New Data Received Length = 69
MPOS_2_TCP  : 15:47:46:45 |Just before ISO8583_ANALYSE
MPOS_2_TCP  : 15:47:46:45 |Received New Message, let dump it
MPOS_2_TCP  : 15:47:46:45 |Dumping Hex Buffer Length = 69
MPOS_2_TCP  : 15:47:46:45 |00 67 02 30 38 30 30 41 30 32 30 30 30 30 30 30 30 38 30 30 .g.0800A020000000800
MPOS_2_TCP  : 15:47:46:45 |30 31 30 30 34 30 30 30 30 30 30 30 30 30 30 30 30 30 30 30 01004000000000000000
MPOS_2_TCP  : 15:47:46:45 |30 30 30 30 30 30 30 30 30 30 31 32 39 31 31 30 30 30 31 30 00000000001291100010
MPOS_2_TCP  : 15:47:46:45 |30 34 74 65 73 74 33 30 31                                  04test301
MPOS_2_TCP  : 15:47:46:45 |Message Format: POS ISO8583
MPOS_2_TCP  : 15:47:46:45 |Received Message Type is 0067
MPOS_2_TCP  : 15:47:46:45 |Invalid Message Type [0067] is requested



Thanks for your help !




Mark Salter

unread,
Mar 19, 2009, 5:13:26 AM3/19/09
to jpos-...@googlegroups.com
Chung vu wrote:
>
> I try to send message and have problems , i check the custom package :
> format and type is okie.Why is MTID is 0071 ? It is very strange

So now you have moved to NCCChannel and your packager to send messages
into MPOS_1 where before the trace was the non-jPOS systems?

OR

Is this trace from the jPOS based system (MPOS_2) you are putting
together, where the previous MPOS_1 is the existing software you seek to
replace?

>
> Log :
>
> MPOS_2_TCP : 15:16:08:11 |Change Message ID to [3] on Entry [1]
> MPOS_2_TCP : 15:16:08:11 |Insert Message Connection ID [3] and Entry [1]
> MPOS_2_TCP : 15:16:08:11 |New Data Received Length = 73
> MPOS_2_TCP : 15:16:08:11 |Just before ISO8583_ANALYSE
> MPOS_2_TCP : 15:16:08:11 |Received New Message, let dump it
> MPOS_2_TCP : 15:16:08:11 |Dumping Hex Buffer Length = 73
> MPOS_2_TCP : 15:16:08:11 |00 71 60 00 02 B7 20 30 38 30 30 41 30 32 30 30
> 30 30 30 30 .q`... 0800A02000000
> MPOS_2_TCP : 15:16:08:11 |30 38 30 30 30 31 30 30 34 30 30 30 30 30 30 30
> 30 30 30 30 08000100400000000000
> MPOS_2_TCP : 15:16:08:11 |30 30 30 30 30 30 30 30 30 30 30 30 30 30 31 32
> 39 31 31 30 00000000000000129110
> MPOS_2_TCP : 15:16:08:11 |30 30 31 30 30 34 74 65 73 74 33 30
> 31 001004test301
> MPOS_2_TCP : 15:16:08:11 |Message Format: POS ISO8583
> MPOS_2_TCP : 15:16:08:11 |Received Message Type is 0071
>
>

I'm going to assume your are developing a system to receive the messages
from your POS...

I think the x'0071' logged is the *decimal* message length and your
Channel has taken the network length of decimal 73 off of the network.

Hard to illustrate in text, but could you be receiving over the network
from your POS :-

2 bytes whole length + 2 byte message length + 71 byte of message

where the message starts with a TPDU that is 5 bytes long?

giving :-

x'
00730071600002B7 2030383030413032
3030303030303038 3030303130303430
3030303030303030 3030303030303030
3030303030303030 3132393131303030
3130303474657374 333031
'

?

Your code is not skipping over the 'extra' length or the TPDU bytes
(x'600002B720') to get to the x'30383030' (c'0800') that follows.


Does that make sense, within my assumption you a developing the receiver
of POS messages?

I would suggest you make a network trace (using wireshark or similar) to
see what the messages from your POS look like, and use that information
to start with?

--
Mark

Chung vu

unread,
Mar 19, 2009, 5:22:20 AM3/19/09
to jpos-...@googlegroups.com
Hi Mark , 

Let i explain my scenario :

I develop a client that simulates a POS using JPOS  and send message to my host ( way4 host)

Our way 4 host have 2 channels ( mpos1 and mpos2 , it is the same , mpos2 is dulicated from mpos1) . Hope that you are not confused
I use  real POS send message to mpos1 and got log  ( Log is okie and return 0810)
I use my client ( write by jpos ) send message to mpos2 and got  log  ( log has erros )
(I use seperate channel for testing and develop only )

I cannot know why it is errors so need your advise :

Log of  mpos1  :

MPOS_1_TCP  : 10:32:17:14 |Dumping Hex Buffer Length = 2
MPOS_1_TCP  : 10:32:17:14 |00 2A                                                       .*

MPOS_1_TCP  : 10:32:17:14 |TCPLINKS: New Data on Socket. Events = 1
MPOS_1_TCP  : 10:32:17:14 |TCPLINKS: Received New [42] Bytes of Data.
MPOS_1_TCP  : 10:32:17:14 |TCPLINKS: Complete Message Data [42] Received.
MPOS_1_TCP  : 10:32:17:14 |TCPLINKS: Dump received Message Data:
MPOS_1_TCP  : 10:32:17:14 |Dumping Hex Buffer Length = 42
MPOS_1_TCP  : 10:32:17:14 |60 00 02 B7 20 08 00 22 20 00 00 00 80 00 10 93 00 00 00 00 `... .." ...........
MPOS_1_TCP  : 10:32:17:14 |00 00 00 00 01 03 31 33 33 30 30 30 30 33 00 06 30 30 30 30 ......13300003..0000
MPOS_1_TCP  : 10:32:17:14 |30 31                                                       01
MPOS_1_TCP  : 10:32:17:14 |TCPLINKS: Message received successfully, Length [42]
MPOS_1_TCP  : 10:32:17:14 |TCPLINKS: Dump Of Received Data:
MPOS_1_TCP  : 10:32:17:14 |Dumping Hex Buffer Length = 37
MPOS_1_TCP  : 10:32:17:14 |08 00 22 20 00 00 00 80 00 10 93 00 00 00 00 00 00 00 00 01 .." ................
MPOS_1_TCP  : 10:32:17:14 |03 31 33 33 30 30 30 30 33 00 06 30 30 30 30 30 31          .13300003..000001
MPOS_1_TCP  : 10:32:17:14 |New Data Received Length = 37
MPOS_1_TCP  : 10:32:17:14 |Just before ISO8583_ANALYSE
MPOS_1_TCP  : 10:32:17:14 |Received New Message, let dump it
MPOS_1_TCP  : 10:32:17:14 |Dumping Hex Buffer Length = 37
MPOS_1_TCP  : 10:32:17:14 |08 00 22 20 00 00 00 80 00 10 93 00 00 00 00 00 00 00 00 01 .." ................
MPOS_1_TCP  : 10:32:17:14 |03 31 33 33 30 30 30 30 33 00 06 30 30 30 30 30 31          .13300003..000001
MPOS_1_TCP  : 10:32:17:14 |Message Format: POS ISO8583
MPOS_1_TCP  : 10:32:17:14 |Received Message Type is 0800
MPOS_1_TCP  : 10:32:17:14 |Type descriptor for [0800] is found
MPOS_1_TCP  : 10:32:17:14 |****** Bit [3] ON ******
MPOS_1_TCP  : 10:32:17:14 |Fixed Length Field with [6] Data Elements
MPOS_1_TCP  : 10:32:17:14 | Conversion from BCD
MPOS_1_TCP  : 10:32:17:14 |Field Content: [930000]



Log of mpos2  :

POS_2_TCP  : 15:47:46:40 |TCPLINKS: RECEIVE Function Invoked
MPOS_2_TCP  : 15:47:46:40 |TCPLINKS: Opened socket [8]
MPOS_2_TCP  : 15:47:46:40 |TCPLINKS: Set Socket to REUSE LOCAL ADDRESS MODE
MPOS_2_TCP  : 15:47:46:40 |E[001]: Waiting for new connect...
MPOS_2_TCP  : 15:47:46:45 |E[000]: New Event on Socket [9].
MPOS_2_TCP  : 15:47:46:45 |E[000]: Received New [69] Bytes of Data on Socket [9].
MPOS_2_TCP  : 15:47:46:45 |E[000]: Message on Socket [9] received successfully, Length [69]

MPOS_2_TCP  : 15:47:46:45 |E[000]: Client IP Address [10.36.90.47] added to message
MPOS_2_TCP  : 15:47:46:45 |Change Message ID to [5] on Entry [0]
MPOS_2_TCP  : 15:47:46:45 |Insert Message Connection ID [5] and Entry [0]
MPOS_2_TCP  : 15:47:46:45 |New Data Received Length = 69
MPOS_2_TCP  : 15:47:46:45 |Just before ISO8583_ANALYSE
MPOS_2_TCP  : 15:47:46:45 |Received New Message, let dump it
MPOS_2_TCP  : 15:47:46:45 |Dumping Hex Buffer Length = 69
MPOS_2_TCP  : 15:47:46:45 |00 67 02 30 38 30 30 41 30 32 30 30 30 30 30 30 30 38 30 30 .g.0800A020000000800
MPOS_2_TCP  : 15:47:46:45 |30 31 30 30 34 30 30 30 30 30 30 30 30 30 30 30 30 30 30 30 01004000000000000000
MPOS_2_TCP  : 15:47:46:45 |30 30 30 30 30 30 30 30 30 30 31 32 39 31 31 30 30 30 31 30 00000000001291100010
MPOS_2_TCP  : 15:47:46:45 |30 34 74 65 73 74 33 30 31                                  04test301
MPOS_2_TCP  : 15:47:46:45 |Message Format: POS ISO8583
MPOS_2_TCP  : 15:47:46:45 |Received Message Type is 0067
MPOS_2_TCP  : 15:47:46:45 |Invalid Message Type [0067] is requested

Mark Salter

unread,
Mar 19, 2009, 5:23:34 AM3/19/09
to jpos-...@googlegroups.com
Chung vu wrote:
>
> Yes , it is from existing system ( non Jpos).
> Thanks for your explanation. It is very clear.
>>From this understand , i am not clear why message i try to send now , it has
> errors.
Please clarify which part of this flow you are replacing with jPOS? It
is not clear to me yet and I am having to make assumptions.

> And we use message length ( not header ) , it is okie .
> So declare like this is message lenthe is shown by 2 bytes , it that right?
> ISOChannel channel = new

> org.jpos.iso.channel.NCCChannel("10.36.10.73",9302,new way4POSPackager(),*new
> byte[]{(byte)002}*)
You are mixing up a number of components of the flow I'm afraid.

The 4th parm is the TPDU, not a value indicating the number of bytes to
hold a length? If you have a TPDU then that goes as the 4th parm.

You don't need to worry about the length, the NCChannel will do that for
you.

I think your POS is sending more lengths than you expect - so get a
trace of a current network exchange first. I have stated two lengths in
my last reply, but to give more commentary...

>
> Log:
>
> MPOS_2_TCP : 15:47:46:45 |E[000]: Client IP Address [10.36.90.47] added to
> message
> MPOS_2_TCP : 15:47:46:45 |Change Message ID to [5] on Entry [0]
> MPOS_2_TCP : 15:47:46:45 |Insert Message Connection ID [5] and Entry [0]
> MPOS_2_TCP : 15:47:46:45 |New Data Received Length = 69

So on the network you found two bytes holding x'0069'. Note you are
treating this a decimal length when the original components held a
binary length - just beware.

> MPOS_2_TCP : 15:47:46:45 |Just before ISO8583_ANALYSE
> MPOS_2_TCP : 15:47:46:45 |Received New Message, let dump it
> MPOS_2_TCP : 15:47:46:45 |Dumping Hex Buffer Length = 69
> MPOS_2_TCP : 15:47:46:45 |00 67 02 30 38 30 30 41 30 32 30 30 30 30 30 30
> 30 38 30 30 .g.0800A020000000800

The part above starts with 'another length x'0067' which seems to be the
length of data that follows.

> MPOS_2_TCP : 15:47:46:45 |30 31 30 30 34 30 30 30 30 30 30 30 30 30 30 30
> 30 30 30 30 01004000000000000000
> MPOS_2_TCP : 15:47:46:45 |30 30 30 30 30 30 30 30 30 30 31 32 39 31 31 30
> 30 30 31 30 00000000001291100010
> MPOS_2_TCP : 15:47:46:45 |30 34 74 65 73 74 33 30
> 31 04test301
> MPOS_2_TCP : 15:47:46:45 |Message Format: POS ISO8583
> MPOS_2_TCP : 15:47:46:45 |Received Message Type is 0067
> MPOS_2_TCP : 15:47:46:45 |Invalid Message Type [0067] is requested

You are reporting the MTI as the first two bytes, which here hold the
message length x'0067', you need to align your Channel with the message
your POS system or device is sending, currently they are misaligned.

You might need a new Channel to deal with binary (not decimal lengths),
but also 'absorb' *two* length fields?

A network trace of existing and the detail of which component you are
replacing will help.

--
Mark

Mark Salter

unread,
Mar 19, 2009, 5:42:41 AM3/19/09
to jpos-...@googlegroups.com
Chung vu wrote:

> Let i explain my scenario :
>
> I develop a client that simulates a POS using JPOS and send message to my
> host ( way4 host)

Ok, so my assumption was incorrect 8( !

>
> Our way 4 host have 2 channels ( mpos1 and mpos2 , it is the same , mpos2 is
> dulicated from mpos1) . Hope that you are not confused

Ok so far.

> I use real POS send message to mpos1 and got log ( Log is okie and return
> 0810)

Good, so the existing system works still 8).

> I use my client ( write by jpos ) send message to mpos2 and got log ( log
> has erros )
> (I use seperate channel for testing and develop only )
>
> I cannot know why it is errors so need your advise :
>

> *Log of mpos1 *:
>
> *MPOS_1_TCP : 10:32:17:14 |Dumping Hex Buffer Length = 2


> MPOS_1_TCP : 10:32:17:14 |00
> 2A .*

The existing POS is sending a 2 byte *binary* message length? You need
to as well, although I do suspect that MPOS_2 is has a *different* setup
to MPOS_1!

> MPOS_1_TCP : 10:32:17:14 |TCPLINKS: New Data on Socket. Events = 1
> MPOS_1_TCP : 10:32:17:14 |TCPLINKS: Received New [42] Bytes of Data.
> MPOS_1_TCP : 10:32:17:14 |TCPLINKS: Complete Message Data [42] Received.
> MPOS_1_TCP : 10:32:17:14 |TCPLINKS: Dump received Message Data:
> MPOS_1_TCP : 10:32:17:14 |Dumping Hex Buffer Length = 42

Note, decimal 42 is x'2A'


> MPOS_1_TCP : 10:32:17:14 |60 00 02 B7 20 08 00 22 20 00 00 00 80 00 10 93
> 00 00 00 00 `... .." ...........

Here is the TPDU, which I would choose to call a header. It is 5 bytes :-

x'600002B720'

In sending a message in, I would set the ISOMsg header to these bytes -
does there content change at all?


> MPOS_1_TCP : 10:32:17:14 |00 00 00 00 01 03 31 33 33 30 30 30 30 33 00 06
> 30 30 30 30 ......13300003..0000
> MPOS_1_TCP : 10:32:17:14 |30
> 31 01
> MPOS_1_TCP : 10:32:17:14 |TCPLINKS: Message received successfully, Length
> [42]
> MPOS_1_TCP : 10:32:17:14 |TCPLINKS: Dump Of Received Data:
> MPOS_1_TCP : 10:32:17:14 |Dumping Hex Buffer Length = 37

Note here that 37 = 42 - 5, so...

> MPOS_1_TCP : 10:32:17:14 |08 00 22 20 00 00 00 80 00 10 93 00 00 00 00 00
> 00 00 00 01 .." ................

By here, the header (or TPDU) is gone and we are at the x'0800' MTI, and
ready to deal with this message.

> MPOS_1_TCP : 10:32:17:14 |03 31 33 33 30 30 30 30 33 00 06 30 30 30 30 30
> 31 .13300003..000001
> MPOS_1_TCP : 10:32:17:14 |New Data Received Length = 37
> MPOS_1_TCP : 10:32:17:14 |Just before ISO8583_ANALYSE
> MPOS_1_TCP : 10:32:17:14 |Received New Message, let dump it
> MPOS_1_TCP : 10:32:17:14 |Dumping Hex Buffer Length = 37
> MPOS_1_TCP : 10:32:17:14 |08 00 22 20 00 00 00 80 00 10 93 00 00 00 00 00
> 00 00 00 01 .." ................
> MPOS_1_TCP : 10:32:17:14 |03 31 33 33 30 30 30 30 33 00 06 30 30 30 30 30
> 31 .13300003..000001
> MPOS_1_TCP : 10:32:17:14 |Message Format: POS ISO8583
> MPOS_1_TCP : 10:32:17:14 |Received Message Type is 0800
> MPOS_1_TCP : 10:32:17:14 |Type descriptor for [0800] is found
> MPOS_1_TCP : 10:32:17:14 |****** Bit [3] ON ******
> MPOS_1_TCP : 10:32:17:14 |Fixed Length Field with [6] Data Elements
> MPOS_1_TCP : 10:32:17:14 | Conversion from BCD

> MPOS_1_TCP : 10:32:17:14 |Field Content: [930000]*
>

Before we go further, are you absolutely certain MPOS_! and MPOS_2
connections are identical? The log entries look quite different to me!?!

For instance, where is the detail :-

"
*MPOS_1_TCP : 10:32:17:14 |Dumping Hex Buffer Length = 2


MPOS_1_TCP : 10:32:17:14 |00
2A
"

?

Can you get a POS to send to MPOS_2 to see if it works?

Are you seeking to replace a simulator solution with a jPOS solution?

I won't continue dissecting the MPOS_2 flow, I think it is handling the
traffic differently to MPOS_1 and I would like you to check if I am
right or not.

--
Mark

vu dinh chung

unread,
Mar 19, 2009, 6:16:57 AM3/19/09
to jpos-...@googlegroups.com
Hi Mark ,
You make me surprised .
Yes , i have miss 2 parameters on mpos2 when duplicate from mpos1 , i turn them on now.
(parameter TPDU off --> on
header_leth is 2 bye --> on )

I try to make transaction after that but still error .
You understand about message lenth and TPDU is righ .

Yes , TPDU is 5 bytes ... how do i send this value from Jpos ?
this code is only declare ( i have just change this from 2 bytes to 5 bytes)

       ISOChannel channel = new org.jpos.iso.channel.NCCChannel("10.36.10.73",9302,new way4POSPackager(),new byte[]{(byte)005});

Log after change mpos2 is exact same to mpos1:

MPOS_2_TCP  : 16:47:57:45 |TCPLINKS: Set Socket to REUSE LOCAL ADDRESS MODE
MPOS_2_TCP  : 16:47:57:45 |E[001]: Waiting for new connect...
MPOS_2_TCP  : 16:47:57:49 |E[000]: Event on Socket [9]
MPOS_2_TCP  : 16:47:57:49 |E[000]: Received New [2] Bytes of Header on Socket [9].
MPOS_2_TCP  : 16:47:57:49 |E[000]: Complete Header [2] Received on Socket [9].
MPOS_2_TCP  : 16:47:57:49 |************* SOCKET DRIVER ACTIVE **********
MPOS_2_TCP  : 16:47:57:49 |TCPLINKS: RECEIVE Function Invoked
MPOS_2_TCP  : 16:47:57:49 |E[000]: New Event on Socket [9].
MPOS_2_TCP  : 16:47:57:49 |E[000]: Received New [67] Bytes of Data on Socket [9].
MPOS_2_TCP  : 16:47:57:49 |************* SOCKET DRIVER ACTIVE **********
MPOS_2_TCP  : 16:47:57:49 |TCPLINKS: RECEIVE Function Invoked
MPOS_2_TCP  : 16:47:57:54 |E[000]: New Event on Socket [9].
MPOS_2_TCP  : 16:47:57:54 |E[000]: Receive failed on msg data, Error = 131
MPOS_2_TCP  : 16:47:57:54 |Change Message ID to [2] on Entry [0]

Mark Salter

unread,
Mar 19, 2009, 6:38:35 AM3/19/09
to jpos-...@googlegroups.com
vu dinh chung wrote:
>
> You make me surprised .
> Yes , i have miss 2 parameters on mpos2 when duplicate from mpos1 , i
> turn them on now.
> (parameter TPDU off --> on
> header_leth is 2 bye --> on )
Ok, but don't forget to revert this change when you need to.

>
> I try to make transaction after that but still error .

I would hope it would be different with this configuration change?

> You understand about message lenth and TPDU is righ .
>
> Yes , TPDU is 5 bytes ... how do i send this value from Jpos ?
> this code is only declare ( i have just change this from 2 bytes to 5 bytes)

No, in fact you have made the TPDU 1 byte long containing x'05'

>
> *ISOChannel channel = new
> org.jpos.iso.channel.NCCChannel("10.36.10.73",9302,new
> way4POSPackager(),new byte[]{(byte)005});*

The 4th parameter is where you specify the *bytes* you want to send in
with the message as it's TPDU. It is *not* for specifying the length of
the TPDU at all. The above code will send a TPDU ox x'05', with the
MPOS_1 & 2 expecting a TPDU five bytes long, it will report a incorrect
MTI (perhaps 0000) and also complain about not enough data being
available or it might hang. I am only guessing of course.

I think this should be :-

ISOChannel channel = new
org.jpos.iso.channel.NCCChannel("10.36.10.73",9302,new

way4POSPackager(),new byte[]{(byte)0x60,(byte) 0x00,(byte) 0x02,(byte)
0xB7,(byte) 0x20});

Assuming the TPDU you want is x'600002B720' of course!

Does the content of the TPDU vary from connection to connection?

>
> Log after change mpos2 is exact same to mpos1:
>

> /MPOS_2_TCP : 16:47:57:45 |TCPLINKS: Set Socket to REUSE LOCAL ADDRESS MODE


> MPOS_2_TCP : 16:47:57:45 |E[001]: Waiting for new connect...
> MPOS_2_TCP : 16:47:57:49 |E[000]: Event on Socket [9]
> MPOS_2_TCP : 16:47:57:49 |E[000]: Received New [2] Bytes of Header on
> Socket [9].
> MPOS_2_TCP : 16:47:57:49 |E[000]: Complete Header [2] Received on
> Socket [9].
> MPOS_2_TCP : 16:47:57:49 |************* SOCKET DRIVER ACTIVE **********
> MPOS_2_TCP : 16:47:57:49 |TCPLINKS: RECEIVE Function Invoked
> MPOS_2_TCP : 16:47:57:49 |E[000]: New Event on Socket [9].
> MPOS_2_TCP : 16:47:57:49 |E[000]: Received New [67] Bytes of Data on
> Socket [9].
> MPOS_2_TCP : 16:47:57:49 |************* SOCKET DRIVER ACTIVE **********
> MPOS_2_TCP : 16:47:57:49 |TCPLINKS: RECEIVE Function Invoked
> MPOS_2_TCP : 16:47:57:54 |E[000]: New Event on Socket [9].
> MPOS_2_TCP : 16:47:57:54 |E[000]: Receive failed on msg data, Error = 131

> MPOS_2_TCP : 16:47:57:54 |Change Message ID to [2] on Entry [0]/

What does this "Error = 131" mean? Is it by chance indicating that the
length is greater than the bytes received?

Can you also confirm what you are seeking to replace with jPOS? Is it a
simulator you use in testing or the POS system/devices?

--
Mark

vu dinh chung

unread,
Mar 19, 2009, 7:04:37 AM3/19/09
to jpos-...@googlegroups.com
Hi Mark ,

I try to make transaction after that but still error .
  
  I would hope it would be different with this configuration change?
I try code after i change the parameter for mpos2 (like mpos1)

Content of TPDU is vary but in this  case , we can  use fix value as you use , it is okie .

I try the code but still error= 131 , i config   the debug mode but log is no more .

I try to write a EPOS for internal system that can do banlan inquiry , ministament and fund tranfer  with Jpos

Regards,
Chung

Mark Salter

unread,
Mar 19, 2009, 7:54:39 AM3/19/09
to jpos-...@googlegroups.com
vu dinh chung wrote:
>
>> I try to make transaction after that but still error .
>>
> I would hope it would be different with this configuration change?
>
> I try code after i change the parameter for mpos2 (like mpos1)
>
> Content of TPDU is vary but in this case , we can use fix value as you
> use , it is okie .
Fine.

>
> I try the code but still error= 131 , i config the debug mode but log
> is no more .

Please check the message length format. I think your POS is sending
(and MPOS_2 is expecting) a binary length in two bytes, I think you are
sending a BCD length in two bytes.

This matters because...

If a message is 101 bytes long then the POS will send :-

x'0065600002B7200800....'

But, you would send :-

x'0101600002B7200800....'

The MPOS software will deal correctly with the length from POS, seeing
101 bytes and being able to read that many from the network.

Your message appears to MPOS to be x'0101' bytes long which if taken as
binary and converted to decimal is 257 bytes - much more than you are
sending. It will try and read 257 bytes from the network, get 101 and
then sit waiting for the rest to arrive.

This is probably why nothing is being logged as a whole message has not
arrived yet. To test this theory, keep sending messages down the MPOS_2
channel, eventually enough bytes will flow to fulfil the length
specified and logging will occur.

Using the 0800 message lengths shown so far, I calculate that you would
need to send two 0800 messages (without waiting for a response on the
first) through NCCChannel to MPOS_2 to generate enough bytes to satisfy
the number you have told MPOS_2 to expect.

Alternatively, do a trace (suggested a while ago), see what the POS
exchange looks like including the message length, then compare it to a
trace of your message.

Then change to NACChannel and see if things improve.

8)

>
> I try to write a EPOS for internal system that can do banlan inquiry ,
> ministament and fund tranfer with Jpos

I see, so interfacing with MPOS for other functions. I see, thanks.

--
Mark

Chung vu

unread,
Mar 19, 2009, 8:17:04 AM3/19/09
to jpos-...@googlegroups.com
Hi Mark ,
Would you help me this wonder ?
Message length is hex format .
How do i know that message lenth from NCCchannle is hex format
Regards
Chung

Mark Salter

unread,
Mar 19, 2009, 9:04:48 AM3/19/09
to jpos-...@googlegroups.com
Chung vu wrote:
>
> Message length is hex format .
> How do i know that message lenth from NCCchannle is hex format

The programmers guide has table 6.1 of Channels , on page 52 it gives
the details of both NACChannel and NCCChannel.

You may also have looked at the comments at the top of the source code:-

/**
* Talks with TCP based NCCs
* Sends [LEN][TPDU][ISOMSG]
* (len=2 bytes BCD)
*
* @author Alejandro P. Revilla
* @version $Revision: 2594 $ $Date: 2008-01-22 16:41:31 +0000 (Tue, 22
Jan 2008) $
* @see ISOMsg
* @see ISOException
* @see ISOChannel
*/

Whereas NACChannel has comments that read :-

/**
* Talks with TCP based NACs
* Sends [LEN][TPDU][ISOMSG]
* (len=2 bytes network byte order)
*
* @author Alejandro P. Revilla
* @version $Revision: 2667 $ $Date: 2008-11-06 10:13:44 +0000 (Thu, 06
Nov 2008) $
* @see ISOMsg
* @see ISOException
* @see ISOChannel
*/


Does that help you to make a choice?

What format does "MPOS_1" expect? How is your POS system specifying the
length into MPOS_1?


--
Mark

Reply all
Reply to author
Forward
0 new messages