Format

[Vasu]

Hi




I have some trouble setting the LLVAR format field 33,
I have provided the description and the sample,
I want to know how to set the field 33..??
My actual message and expected message are differing slightly at the
field 33 position.




This is specified in the document..

Field Name Len Type Format
Description

MTI 04 N
F 0800
PRIMARY BIT MAP 16 HEX F
8220000080000000
(01) SECONDARY BIT MAP 16 HEX F
0400000000000000
(07) DATE & TIME 10 N F
0707000205
(11) SYSTEM TRACE 06 N F 000205
(33) INSTITUITON CODE 11 N LLVAR 06600002
(70) NETWORK MANAGEMENT 03 N F 301


Here is the code i am trying to work on.

ISOMUX isoMux = MuxChannel.getMuxedChannel();
ISOMsg echo = new ISOMsg();
java.util.Date d = new java.util.Date();
Sequencer seq = new VolatileSequencer();
echo.setMTI("0800");
echo.set (new ISOField (7,ISODate.getDateTime(d)));
echo.set (new ISOField (11,"000205"));
echo.set (new ISOField (33,"600002"));
echo.set (new ISOField(70,"301"));
ISORequest isoRequest = new ISORequest(echo);
isoRequest.dump(System.out,"***Request....");
isoMux.queue(isoRequest);

Actual Message from my code.:
0800822000008000000004000000000000001125124050000205066000020301

Expected message from the document Message:
080082200000800000000400000000000000070700020500020506600002301

[Mark Salter]

Vasu wrote:
> I have some trouble setting the LLVAR format field 33,

[snip]

> Actual Message from my code.:
> 0800822000008000000004000000000000001125124050000205066000020301

So you get (for field 33)... LLnnnnnn
which looks correct for field 33, but are you wondering where the extra
0 ------------------------------------------------------------^ comes from?

How is your packager defining field 70? Is it 4 or 3 bytes long?

>
> Expected message from the document Message:
> 080082200000800000000400000000000000070700020500020506600002301

The example is bad for this date, perhaps next time, can you edit what
you actually produce to form a better example please in which it is
easier to see the 'difference'?

8)


--
Mark

[Vasu]

Hi,

thanks for response.

I think it is defined as 3 bytes long..
new IFB_NUMERIC ( 3, "NETWORK INTERNATIONAL IDENTIFIEER",
true),

I have replaced the code
echoMessage.set (new ISOField (7,ISODate.getDateTime(d)));
with the following code for better date example

echoMessage.set (new ISOField (7,"0707000205"));
and the output I got is below:

080082200000800000000400000000000000070700020500020508066000020301

Expected message from the document Message:
080082200000800000000400000000000000070700020500020506600002301

The following is the PACKAGER I have:

package com.aircls.jposinterface;

import org.jpos.iso.IFB_AMOUNT;
import org.jpos.iso.IFB_BINARY;
import org.jpos.iso.IFB_BITMAP;
import org.jpos.iso.IFB_LLCHAR;
import org.jpos.iso.IFB_LLLCHAR;
import org.jpos.iso.IFB_LLLBINARY;
import org.jpos.iso.IFB_LLNUM;
import org.jpos.iso.IFB_NUMERIC;
import org.jpos.iso.IF_CHAR;
import org.jpos.iso.ISOBasePackager;
import org.jpos.iso.ISOFieldPackager;

/**
* ISO 8583 v1987 BINARY Packager
*
* @author a...@cs.com.uy
* @version $Id: ISO87BPackager.java,v 1.2 2003/10/03 18:44:23 tarun
Exp $
* @see ISOPackager
* @see ISOBasePackager
* @see ISOComponent
*/
public class ISO87BPackager extends ISOBasePackager {
private static final boolean pad = false;
protected ISOFieldPackager fld[] = {
new IFB_NUMERIC ( 4, "MESSAGE TYPE INDICATOR", true),
new IFB_BITMAP ( 16, "BIT MAP"),
new IFB_LLNUM ( 19, "PAN - PRIMARY ACCOUNT NUMBER",
pad),
new IFB_NUMERIC ( 6, "PROCESSING CODE", true),
new IFB_NUMERIC ( 12, "AMOUNT, TRANSACTION", true),
new IFB_NUMERIC ( 12, "AMOUNT, SETTLEMENT", true),
new IFB_NUMERIC ( 12, "AMOUNT, CARDHOLDER BILLING", true),
new IFB_NUMERIC ( 10, "TRANSMISSION DATE AND TIME", true),
new IFB_NUMERIC ( 8, "AMOUNT, CARDHOLDER BILLING FEE",
true),
new IFB_NUMERIC ( 8, "CONVERSION RATE, SETTLEMENT",
true),
new IFB_NUMERIC ( 8, "CONVERSION RATE, CARDHOLDER
BILLING", true),
new IFB_NUMERIC ( 6, "SYSTEM TRACE AUDIT NUMBER", true),
new IFB_NUMERIC ( 6, "TIME, LOCAL TRANSACTION", true),
new IFB_NUMERIC ( 4, "DATE, LOCAL TRANSACTION", true),
new IFB_NUMERIC ( 4, "DATE, EXPIRATION", true),
new IFB_NUMERIC ( 4, "DATE, SETTLEMENT", true),
new IFB_NUMERIC ( 4, "DATE, CONVERSION", true),
new IFB_NUMERIC ( 4, "DATE, CAPTURE", true),
new IFB_NUMERIC ( 4, "MERCHANTS TYPE", true),
new IFB_NUMERIC ( 3, "ACQUIRING INSTITUTION COUNTRY
CODE", true),
new IFB_NUMERIC ( 3, "PAN EXTENDED COUNTRY CODE", true),
new IFB_NUMERIC ( 3, "FORWARDING INSTITUTION COUNTRY
CODE", true),
new IFB_NUMERIC ( 3, "POINT OF SERVICE ENTRY MODE",
true),
new IFB_NUMERIC ( 3, "CARD SEQUENCE NUMBER", true),
new IFB_NUMERIC ( 3, "NETWORK INTERNATIONAL IDENTIFIEER",
true),
new IFB_NUMERIC ( 2, "POINT OF SERVICE CONDITION CODE",
true),
new IFB_NUMERIC ( 2, "POINT OF SERVICE PIN CAPTURE CODE",
true),
new IFB_NUMERIC ( 1, "AUTHORIZATION IDENTIFICATION RESP
LEN",true),
new IFB_AMOUNT ( 9, "AMOUNT, TRANSACTION FEE", true),
new IFB_AMOUNT ( 9, "AMOUNT, SETTLEMENT FEE", true),
new IFB_AMOUNT ( 9, "AMOUNT, TRANSACTION PROCESSING
FEE", true),
new IFB_AMOUNT ( 9, "AMOUNT, SETTLEMENT PROCESSING FEE",
true),
new IFB_LLNUM ( 11, "ACQUIRING INSTITUTION IDENT CODE",
pad),
new IFB_LLNUM ( 11, "FORWARDING INSTITUTION IDENT CODE",
pad),
new IFB_LLCHAR ( 28, "PAN EXTENDED"),
new IFB_LLNUM ( 37, "TRACK 2 DATA", pad),
new IFB_LLLCHAR (104, "TRACK 3 DATA"),
new IF_CHAR ( 12, "RETRIEVAL REFERENCE NUMBER"),
new IF_CHAR ( 6, "AUTHORIZATION IDENTIFICATION
RESPONSE"),
new IF_CHAR ( 2, "RESPONSE CODE"),
new IF_CHAR ( 3, "SERVICE RESTRICTION CODE"),
new IF_CHAR ( 8, "CARD ACCEPTOR TERMINAL
IDENTIFICACION"),
new IF_CHAR ( 15, "CARD ACCEPTOR IDENTIFICATION
CODE" ),
new IF_CHAR ( 40, "CARD ACCEPTOR NAME/LOCATION"),
new IFB_LLCHAR ( 25, "ADITIONAL RESPONSE DATA"),
new IFB_LLCHAR ( 76, "TRACK 1 DATA"),
new IFB_LLLCHAR (999, "ADITIONAL DATA - ISO"),
new IFB_LLLCHAR (999, "ADITIONAL DATA - NATIONAL"),
new IFB_LLLCHAR (999, "ADITIONAL DATA - PRIVATE"),
new IF_CHAR ( 3, "CURRENCY CODE, TRANSACTION"),
new IF_CHAR ( 3, "CURRENCY CODE, SETTLEMENT"),
new IF_CHAR ( 3, "CURRENCY CODE, CARDHOLDER
BILLING" ),
new IFB_BINARY ( 8, "PIN DATA" ),
new IFB_NUMERIC ( 16, "SECURITY RELATED CONTROL
INFORMATION", true),
new IFB_LLLBINARY (120, "ADDITIONAL AMOUNTS"),
new IFB_LLLCHAR (999, "RESERVED ISO"),
new IFB_LLLCHAR (999, "RESERVED ISO"),
new IFB_LLLCHAR (999, "RESERVED NATIONAL"),
new IFB_LLLCHAR (999, "RESERVED NATIONAL"),
new IFB_LLLCHAR (999, "RESERVED NATIONAL"),
new IFB_LLLCHAR (999, "RESERVED PRIVATE"),
new IFB_LLLCHAR (999, "RESERVED PRIVATE"),
new IFB_LLLCHAR (999, "RESERVED PRIVATE"),
new IFB_LLLCHAR (999, "RESERVED PRIVATE"),
new IFB_BINARY ( 8, "MESSAGE AUTHENTICATION CODE
FIELD"),
new IFB_BINARY ( 1, "BITMAP, EXTENDED"),
new IFB_NUMERIC ( 1, "SETTLEMENT CODE", true),
new IFB_NUMERIC ( 2, "EXTENDED PAYMENT CODE", true),
new IFB_NUMERIC ( 3, "RECEIVING INSTITUTION COUNTRY
CODE", true),
new IFB_NUMERIC ( 3, "SETTLEMENT INSTITUTION COUNTRY
CODE", true),
new IFB_NUMERIC ( 3, "NETWORK MANAGEMENT INFORMATION
CODE", true),
new IFB_NUMERIC ( 4, "MESSAGE NUMBER", true),
new IFB_NUMERIC ( 4, "MESSAGE NUMBER LAST", true),
new IFB_NUMERIC ( 6, "DATE ACTION", true),
new IFB_NUMERIC ( 10, "CREDITS NUMBER", true),
new IFB_NUMERIC ( 10, "CREDITS REVERSAL NUMBER", true),
new IFB_NUMERIC ( 10, "DEBITS NUMBER", true),
new IFB_NUMERIC ( 10, "DEBITS REVERSAL NUMBER", true),
new IFB_NUMERIC ( 10, "TRANSFER NUMBER", true),
new IFB_NUMERIC ( 10, "TRANSFER REVERSAL NUMBER", true),
new IFB_NUMERIC ( 10, "INQUIRIES NUMBER", true),
new IFB_NUMERIC ( 10, "AUTHORIZATION NUMBER", true),
new IFB_NUMERIC ( 12, "CREDITS, PROCESSING FEE AMOUNT",
true),
new IFB_NUMERIC ( 12, "CREDITS, TRANSACTION FEE AMOUNT",
true),
new IFB_NUMERIC ( 12, "DEBITS, PROCESSING FEE AMOUNT",
true),
new IFB_NUMERIC ( 12, "DEBITS, TRANSACTION FEE AMOUNT",
true),
new IFB_NUMERIC ( 16, "CREDITS, AMOUNT", true),
new IFB_NUMERIC ( 16, "CREDITS, REVERSAL AMOUNT", true),
new IFB_NUMERIC ( 16, "DEBITS, AMOUNT", true),
new IFB_NUMERIC ( 16, "DEBITS, REVERSAL AMOUNT", true),
new IFB_NUMERIC ( 42, "ORIGINAL DATA ELEMENTS", true),
new IF_CHAR ( 1, "FILE UPDATE CODE"),
new IF_CHAR ( 2, "FILE SECURITY CODE"),
new IF_CHAR ( 6, "RESPONSE INDICATOR"),
new IF_CHAR ( 7, "SERVICE INDICATOR"),
new IF_CHAR ( 42, "REPLACEMENT AMOUNTS"),
new IFB_BINARY ( 16, "MESSAGE SECURITY CODE"),
new IFB_AMOUNT ( 17, "AMOUNT, NET SETTLEMENT", pad),
new IF_CHAR ( 25, "PAYEE"),
new IFB_LLNUM ( 11, "SETTLEMENT INSTITUTION IDENT CODE",
pad),
new IFB_LLNUM ( 11, "RECEIVING INSTITUTION IDENT CODE",
pad),
new IFB_LLCHAR ( 17, "FILE NAME"),
new IFB_LLCHAR ( 28, "ACCOUNT IDENTIFICATION 1"),
new IFB_LLCHAR ( 28, "ACCOUNT IDENTIFICATION 2"),
new IFB_LLLCHAR (100, "TRANSACTION DESCRIPTION"),
new IFB_LLLCHAR (999, "RESERVED ISO USE"),
new IFB_LLLCHAR (999, "RESERVED ISO USE"),
new IFB_LLLCHAR (999, "RESERVED ISO USE"),
new IFB_LLLCHAR (999, "RESERVED ISO USE"),
new IFB_LLLCHAR (999, "RESERVED ISO USE"),
new IFB_LLLCHAR (999, "RESERVED ISO USE"),
new IFB_LLLCHAR (999, "RESERVED ISO USE"),
new IFB_LLLCHAR (999, "RESERVED NATIONAL USE"),
new IFB_LLLCHAR (999, "RESERVED NATIONAL USE"),
new IFB_LLLCHAR (999, "RESERVED NATIONAL USE" ),
new IFB_LLLCHAR (999, "RESERVED NATIONAL USE"),
new IFB_LLLCHAR (999, "RESERVED NATIONAL USE" ),
new IFB_LLLCHAR (999, "RESERVED NATIONAL USE"),
new IFB_LLLCHAR (999, "RESERVED NATIONAL USE"),
new IFB_LLLCHAR (999, "RESERVED NATIONAL USE"),
new IFB_LLLCHAR (999, "RESERVED PRIVATE USE"),
new IFB_LLLCHAR (999, "RESERVED PRIVATE USE"),
new IFB_LLLCHAR (999, "RESERVED PRIVATE USE"),
new IFB_LLLCHAR (999, "RESERVED PRIVATE USE"),
new IFB_LLLCHAR (999, "RESERVED PRIVATE USE"),
new IFB_LLLCHAR (999, "RESERVED PRIVATE USE"),
new IFB_LLLCHAR (999, "RESERVED PRIVATE USE"),
new IFB_LLLCHAR (999, "RESERVED PRIVATE USE"),
new IFB_BINARY ( 8, "MAC 2")
};
public ISO87BPackager() {
super();
setFieldPackager(fld);
}
}


Thanks,
Vasudevan

[Mark Salter]

Vasu wrote:

> I think it is defined as 3 bytes long..
> new IFB_NUMERIC ( 3, "NETWORK INTERNATIONAL IDENTIFIEER",
> true),

Well I make it that field 70 (the one I ask about) is :-

"
new IFB_NUMERIC ( 3, "NETWORK MANAGEMENT INFORMATION
CODE", true),
"

Which seems to fit better - you have quoted field 24, but never mind...

>
> I have replaced the code
> echoMessage.set (new ISOField (7,ISODate.getDateTime(d)));
> with the following code for better date example
>
> echoMessage.set (new ISOField (7,"0707000205"));
> and the output I got is below:
>
> 080082200000800000000400000000000000070700020500020508066000020301

Where does this 08 -----------------------------------^^

come from? I think you are now including the length in your field 33
data value?

Please :-

1. Show us the code that you are now using to produce this message (I
suspect you have changed more than you state above).
2. The breakdown of the expected message into it's component fields
3. Confirm that you have carefully matched each of the packagers field
definitions to the specification.

--
Mark

[vasudevan krishnan]

Hi,   below is the code   ISOMUX isoMux = MuxChannel.getMuxedChannel();   ISOMsg echoMessage = new ISOMsg();   String  messageTypeId     = "0800";

java.util.Date d = new java.util.Date();   Sequencer seq = new VolatileSequencer();

echoMessage.setMTI(messageTypeId);

echoMessage.set (new ISOField (7,"0707000205"));

echoMessage.set (new ISOField (11,"000205"));   echoMessage.set (new ISOField (33,"06600002"));   echoMessage.set (new ISOField(70,"301"));   thanks, Vasudevan --- On Fri, 12/4/09, Mark Salter <marks...@talktalk.net> wrote:

-- 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+unsub...@googlegroups.com For more options, visit this group at http://groups.google.com/group/jpos-users

[Mark Salter]

vasudevan krishnan wrote:
> Hi,
>
> below is the code
>
> ISOMUX isoMux = MuxChannel.getMuxedChannel();
> ISOMsg echoMessage = new ISOMsg();
> String messageTypeId = "0800";
> java.util.Date d = new java.util.Date();
> Sequencer seq = new VolatileSequencer();
> echoMessage.setMTI(messageTypeId);
> echoMessage.set (new ISOField (7,"0707000205"));
> echoMessage.set (new ISOField (11,"000205"));
> echoMessage.set (new ISOField (33,"06600002"));

This ----------------------------------^^

c'06' is not needed it was the length and the pack is now adding a 08,
which is a new problem. This was change since your first post.

> echoMessage.set (new ISOField(70,"301"));

Can you amend your field 70 definition from:-

new IFB_NUMERIC ( 3, "NETWORK MANAGEMENT INFORMATION
CODE", true),

to

new IF_CHAR ( 3, "NETWORK MANAGEMENT INFORMATION
CODE"),

I think you are getting padding...

... are you also showing us a hexadecimal version of the
produced/expected message?

From your first post :-

(70) NETWORK MANAGEMENT 03 N F 301

This I think indicates your packager does not match the interface, my
suggested change for field 70 should make a difference, but it would
need the example to be wrong (I think).

> Please :-
>
> 1. Show us the code that you are now using to produce this message (I
> suspect you have changed more than you state above).

Done.

> 2. The breakdown of the expected message into it's component fields

TODO

> 3. Confirm that you have carefully matched each of the packagers field
> definitions to the specification.

TODO

8)

--
Mark

[vasudevan krishnan]

Hi,   Changing to IF_CHAR could’t help..   The Result we got is as follows: Expected message from the JPOS DOCUMENT Message: 080082200000800000000400000000000000070700020500020506600002301   After changes to the files, we got the following: 0800822000008000000004000000000000000707000205000205066000020330   I have given here the Request and Response Dump from our server - fyi please   Request dump.... <request>   <isomsg>                 <field id="0" value="0800"/>                 <field id="7" value="0707000205"/>                 <field id="11" value="000205"/>                  <field id="33" value="600002"/>                  <field id="70" value="301"/>   </isomsg> </request>   Server Simulator code retrived:   <log realm="iso-server.channel" at="Fri Dec 04 13:04:39 PST 2009.23">   <receive>     <isomsg direction="incoming">       <field id="0" value="0800"/>       <field id="7" value="0707000205"/>       <field id="11" value="000205"/>       <field id="33" value="600002"/>       <field id="70" value="301"/>     </isomsg>   </receive> </log>   Thanks,

Vasudevan   --- On Fri, 12/4/09, Mark Salter <marks...@talktalk.net> wrote:

From: Mark Salter <marks...@talktalk.net> Subject: Re: [jpos-users] Re: Format To: jpos-...@googlegroups.com

[Mark Salter]

vasudevan krishnan wrote:

> Changing to IF_CHAR could�t help..

>
> The Result we got is as follows:
> Expected message from the JPOS DOCUMENT Message:
> 080082200000800000000400000000000000070700020500020506600002301

This is the expected message? I'm still waiting for this to be broken
down into it's field components, does the example in the document you
have show the field values separately to the result?

>
> After changes to the files, we got the following:
>
> 0800822000008000000004000000000000000707000205000205066000020330

Now I think you have used the wrong field definition and managed to
truncated the message in showing it here.

This exchange is not working at all is it.

>
> I have given here the Request and Response Dump from our server - fyi please
>
> Request dump....
> <request>
> <isomsg>
> <field id="0" value="0800"/>
> <field id="7" value="0707000205"/>
> <field id="11" value="000205"/>
> <field id="33" value="600002"/>
> <field id="70" value="301"/>
> </isomsg>
> </request>

So all the values are there as expected?

>
> Server Simulator code retrived:
>
> <log realm="iso-server.channel" at="Fri Dec 04 13:04:39 PST 2009.23">
> <receive>
> <isomsg direction="incoming">
> <field id="0" value="0800"/>
> <field id="7" value="0707000205"/>
> <field id="11" value="000205"/>
> <field id="33" value="600002"/>
> <field id="70" value="301"/>
> </isomsg>
> </receive>
> </log>

Still the message is correctly being parsed, what is the issue then?


Please ask smart questions:-

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

also return 'smart replies' - answer all of the questions ask of you,
supply all the detail requested, or state that you can't give the
detail. I'm not asking for extra details for my own health.

I would like you to start a new thread:-

- with a smart question
- including all relevant details
- *and* a description of what components you have
- and what you are actually trying to do.

The problem you stated in this thread's subject was never the problem,
field 70 is (still) the issue.

--
Mark

[vasudevan krishnan]

Hi,   The below output is by setting new IFB_NUMERIC (  3, "NETWORK MANAGEMENT INFORMATION CODE", true) for ISO87BPackager.java file   Code for the message is given below:   ISOMUX isoMux = MuxChannel.getMuxedChannel(); ISOMsg echo = new ISOMsg(); String  messageTypeId   = "0800"; // PURCHASE TRANSACTION TYPE  // N4

java.util.Date d = new java.util.Date(); Sequencer seq = new VolatileSequencer();

echo.setMTI(messageTypeId);   // Field for Purchase Transaction from Bank Server echo.set (new ISOField (7,"0707000205")); echo.set (new ISOField (11,"000205"));

echo.set (new ISOField (33,"600002")); echo.set (new ISOField(70,"301"));

byte [] b = echo.pack(); We printed the byte array b and we got the values below: 8,0,-126,32,0,0,-128,0,0,0,4,0,0,0,0,0,0,0,7,7,0,2,5,0,2,5,6,96,0,2,3,1

Request dump.... <request>   <isomsg>                 <field id="0" value="0800"/>                 <field id="7" value="0707000205"/>                 <field id="11" value="000205"/>                  <field id="33" value="600002"/>                  <field id="70" value="301"/>   </isomsg> </request>

Message: ISOUtil.hexString(b) :  The value is given below: 0800822000008000000004000000000000000707000205000205066000020301   But the expected message from the document: 080082200000800000000400000000000000070700020500020506600002301   We got extra '0' in ISOUtil.hexString(b)

Server Simulator code retrived: <log realm="iso-server.channel" at="Fri Dec 04 13:04:39 PST 2009.23">   <receive>     <isomsg direction="incoming">       <field id="0" value="0800"/>       <field id="7" value="0707000205"/>       <field id="11" value="000205"/>       <field id="33" value="600002"/>       <field id="70" value="301"/>     </isomsg>   </receive> </log>

================================================================================================== To Avoid Extra '0', you have asked to set IF_CHAR   The below output is by setting new IF_CHAR (  3, "NETWORK MANAGEMENT INFORMATION CODE") for ISO87BPackager.java file The code is given below ISOMUX isoMux = MuxChannel.getMuxedChannel(); ISOMsg echo = new ISOMsg(); String  messageTypeId = "0800"; // PURCHASE TRANSACTION TYPE // N4

java.util.Date d = new java.util.Date(); Sequencer seq = new VolatileSequencer();

echo.setMTI(messageTypeId);   // Field for Purchase Transaction from Bank Server echo.set (new ISOField (7,"0707000205")); echo.set (new ISOField (11,"000205"));

echo.set (new ISOField (33,"600002")); echo.set (new ISOField(70,"301"));

byte [] b = echo.pack(); We printed the byte array b and we got the values below: 8,0,-126,32,0,0,-128,0,0,0,4,0,0,0,0,0,0,0,7,7,0,2,5,0,2,5,6,96,0,2,51,48,49

Request dump.... <request>   <isomsg>                 <field id="0" value="0800"/>                 <field id="7" value="0707000205"/>                 <field id="11" value="000205"/>                  <field id="33" value="600002"/>                  <field id="70" value="301"/>   </isomsg> </request>

Message: ISOUtil.hexString(b) : The value is given below: 080082200000800000000400000000000000070700020500020506600002333031   Expected message from the document: 080082200000800000000400000000000000070700020500020506600002301   The above ISOUtil.hexString(b) is giving different value when compared to the expected message from the document.

Server Simulator code retrived:   <log realm="iso-server.channel" at="Fri Dec 04 13:04:39 PST 2009.23">   <receive>     <isomsg direction="incoming">       <field id="0" value="0800"/>       <field id="7" value="0707000205"/>       <field id="11" value="000205"/>       <field id="33" value="600002"/>       <field id="70" value="301"/>     </isomsg>   </receive> </log>

Thanks, Vasudevan

--- On Sat, 12/5/09, Mark Salter <marks...@talktalk.net> wrote:

From: Mark Salter <marks...@talktalk.net> Subject: Re: [jpos-users] Re: Format To: jpos-...@googlegroups.com

Date: Saturday, December 5, 2009, 3:09 PM

vasudevan krishnan wrote: > Changing to IF_CHAR could’t help..

[Mark Salter]

vasudevan krishnan wrote:
> Hi,
Hello, and thank you for finally spending some time to pull everything
together...

... the problem is now obvious and my hunch that the example - in fact
your interpretation of it - is the problem.

> Message: ISOUtil.hexString(b) : The value is given below:
> 0800822000008000000004000000000000000707000205000205066000020301

This message is perfectly formed.

>
> But the expected message from the document:
> 080082200000800000000400000000000000070700020500020506600002301

This message cannot be produced via a ISOUtil.hexString(b) as there is
no content of b that allows half a byte of data (a nibble).

This is because the example is *not* a hexString, it is characters,
which is what the message should be.

>
> We got extra '0' in ISOUtil.hexString(b)

Not extra, it has to be there.

> ==================================================================================================
> To Avoid Extra '0', you have asked to set IF_CHAR

This will avoid it, as it won't need to be there

> Message: ISOUtil.hexString(b) : The value is given below:
> 080082200000800000000400000000000000070700020500020506600002333031

Great again everything is working, x'333031' == c'301' (in ascii).

Just to highlight the problem 'we' were having previously you said that
with using IF_CHAR you got :-

> 0800822000008000000004000000000000000707000205000205066000020330

Which you could not have achieved.

8)

So, you have *not* matched the jPos packager on a field by field basis
to the message specification.

Unfortunately you mis-interpreted the documentation and failed to see or
read the field Format information correctly:-

Field Name Len Type Format Description
MTI 04 N F 0800
PRIMARY BIT MAP 16 HEX F 8220000080000000

(SEC BIT MAP) 16 HEX F 0400000000000000
(07) DATE/TIME 10 N F 0707000205
(11) STAN 06 N F 000205
(33) INST CODE 11 N LLVAR 06600002
(70) NET MAN 03 N F 3011

Check the documentation again, what do each of the 'Type' values mean here?

I'm going to suggest/state that *none* of this message is binary, all of
it is character representation of binary data. So your selection of a
binary packager is flawed.

This is why IF_CHAR (or similar) *is* what you want for field 70 (and
almost all others) and IFB_* is not what you should be using across the
rest of the fields (shown anyway).

Start over with your packager selection. Make sure each field's jPos
format matches the specification you have.

If only you had answered question number 3 from my second response :-

"
Mark Salter wrote:
Please :-

1. Show us the code that you are now using to produce this message (I
suspect you have changed more than you state above).

2. The breakdown of the expected message into it's component fields

3. Confirm that you have carefully matched each of the packagers field
definitions to the specification.
"

You would have had an answer (worked through yourself) 2 days ago.

--
"Give a man a fish..."
Mark

[vasudevan krishnan]

Hi Mark,   Thanks for the clarification.   Thanking you once again   Vasudevan

--- On Sun, 12/6/09, Mark Salter <marks...@talktalk.net> wrote:

From: Mark Salter <marks...@talktalk.net> Subject: Re: [jpos-users] Re: Format To: jpos-...@googlegroups.com