Re: JPOS and ISO 8583 Version 1993

[mutumba wycliff]

Good day all,

 

I have some question, please advise me on this;

 

How does JPOS handle the ISO 8583 Version 1993 message processing?

Is it based only on the cfg files iso93ascii.xml, iso93binary.xml or some more other

setups are required.

 

thanks&regards,

 

NB: - Friends, nowadays when I post my topics I don't get any response,

could I be posting to a wrong address?

 

- Some one please direct me to a site where I can find details on ISO 8583 version 1993 specification.

On Sat, Sep 13, 2008 at 10:36 AM, jpos-users group <nor...@googlegroups.com> wrote:

jPOS Users
jpos-...@googlegroups.com

http://groups.google.com/group/jpos-users?hl=en

Today's most active topics:

* how does jPOS handle array of results? - 2 new
 http://groups.google.com/group/jpos-users/t/e25c12f3a7ab656f?hl=en
* Fixed valueTemplate - 2 new
 http://groups.google.com/group/jpos-users/t/b81591a8875bace6?hl=en




Active Topics
-------------

how does jPOS handle array of results? - 2 new
----------------------------------------------
I guess its a matter of how the host has implemented it. From a personal
banking perspective, the host usually sends a sort of continuation key (used
to identify what data should be sent next) in a field that is used to send the
next request and the information needs to be accumulated at your end. you host
- Fri, Sep 12 2008 12:06 am
2 messages , 1 author
http://groups.google.com/group/jpos-users/t/e25c12f3a7ab656f?hl=en


Fixed valueTemplate - 2 new
---------------------------
hi Andy i had seen u r post regarding fixed value template <isomsg> <field id=
"19" value="840" /> <field id="24" value="182" /> <field id="25" value="1900" /
> <field id="26" value="5912" /> <field id="32" value="05682" /> </isomsg>
public class QueryAMEXHost extends QueryHost { protected String
getResourcePrefix() { - Fri, Sep 12 2008 5:40 am
2 messages , 2 authors
http://groups.google.com/group/jpos-users/t/b81591a8875bace6?hl=en



==============================================================================

You received this message because you are subscribed to the Google
Groups "jPOS Users" group.

To post to this group, send email to jpos-...@googlegroups.com or
visit http://groups.google.com/group/jpos-users?hl=en

To unsubscribe from this group, send email to
jpos-users+...@googlegroups.com

To change the way you get mail from this group, visit:
http://groups.google.com/group/jpos-users/subscribe?hl=en

To report abuse, send email explaining the problem to ab...@googlegroups.com

==============================================================================
Google Groups: http://groups.google.com?hl=en

--
MUTUMBA WYCLIFFE
CONSULTANT

Neptune Software plc
Murtala Courts
Plot 33 Lumumba Avenue
Kampala, Uganda
Tel +256 (414) 237781
Fax+256 (414) 237782
Email: wycliff...@neptunesoftwareplc.com
Website: http://www.neptunesoftwareplc.com

[Mark Salter]

mutumba wycliff wrote:
> How does JPOS handle the ISO 8583 Version 1993 message processing? Is
> it based only on the cfg files iso93ascii.xml, iso93binary.xml or
> some more other setups are required.

Just the packager definitions are needed.

> NB: - Friends, nowadays when I post my topics I don't get any
> response, could I be posting to a wrong address?

The few messages you have posted to this list recently have both been
answered? Are you posting them somewhere else too?

>
> - Some one please direct me to a site where I can find details on ISO
> 8583 version 1993 specification.

ISO standards can be found on www.iso.org. This particular standard is
now 'withdrawn', but can be found here:-

http://preview.tinyurl.com/iso8583-1993

--
Mark

[Mark Salter]

mwyc...@gmail.com wrote:
>> Good day Mark,
Hello.
>>
>> Thanks so much for your advise, indeed am so grateful.
No problem. Taking this discussion off list is probably not beneficial
as others will not see a discussion that might help them. To this end I
have included the list, I hope you understand.

>>
>> Now, you have recommended that to move JPOS to ISO 8583:1993 only
>> requires modifications in the packager file.I didn't get this
>> clearly, please clarify on how I can make the changes to switch my
>> JPOS based application to ISO 8583:1993.
>>
>> Do you mean changing the field definitions in iso87ascii-binary-
>> bitmap.xml file to mach the ISO 8583 193 standard OR I can just
>> make the application use a different packager file say
>> iso93ascii.xml?
It is probably more clear if you take the second approach. Copy and
rename the older version to use as a starting point and then go through
making sure the new version matches the specification you are working
to. You might want to also call it something specific to your target
system?

Note this should match the specification given to you by the owner of
the system you are connecting with.

I personally feel the ISO standard is the wrong place to start.
Companies and systems often take their own stance on message structures
and how they work with them.

>>
>> I have visited the links you recommended for the 1993 version,
>> however, I can't find the details. I thought I would find some pdf
>> file with details of the specification.
You can get a pdf file of the latest ISO8583 version, but you have to
pay for it. Back level versions might be available to purchase, but you
will have to ask the owner directly (www.iso.org), if they are available.

This is another good reason to ask the other party involved for the
specification for *their* system, or indeed the messages they would like
to send you.

--
Mark

[Andy Orrock]

"I personally feel the ISO standard is the wrong place to start."

Agreed. It's a sure step backwards.

I've referenced these pieces many times....

On-boarding a new interface:

http://www.andyorrock.com/2007/08/on-boarding-a-2.html

...and...

Aligning the jPOS packager:

http://www.andyorrock.com/paymentsystems/2006/09/implementing_th.html

...and...

Game Plan Notes:

http://www.andyorrock.com/2007/08/on-boarding-a-1.html

Read those. The example I use (in the first two pieces) is at the heart of
the exercises is AMEX, an ISO8583:1993 interface. You must go through these
exercises.

As Mark implies, your 1993 v. 1987 concern is a red herring here. 1993 or
1987, the exercise is the same: your packager must match your spec.
There's no need to reference the ISO standard to figure out your moves.
Read your spec. Make your field notes. Align your packager. Make the
corresponding, supporting coding changes described in my On-Boarding Guide.

Why the ISO spec won't really help you (to reiterate Mark's point)...from
the On-Boarding Guide:

Configuring the ISO Packager is the essential, core task. The packager
incorporates such ISO8583 implementation decisions as: the format of
numerical values (display or BCD?); the character set used for
alphanumerical values (ASCII or EBCDIC?); the length of each data field;
whether the LLVAR or LLLVAR construct is in play for a particular field;
whether numerical values should be padded to the full field length; and
other important implementation policies that have been made by the provider
and incorporated into their specifications. ***You must read and know the
provider's specs as a precursor to this exercise.***

[mutumba wycliff]

Mark,

 

How can I access those links you said have been added by Andy?

 

Actually the info I am giving you, I got it from ACI a document on BASE24-es ISO 93 Host External Message exchange.I can even send you a copy of this document if you don't mind.

 

Indeed thanks alot for clearing my mind on this variation. My self I was convinced that it was a valid statement and I was so worried on how to implement such cases where the Bitmap is not sent as a binary field and instead comes as ASCII (AN).

According to ACI field 1 will be of type AN 16 instead of org.jpos.iso.IFB_BITMAP as specified in the packager file.

So in this case are you saying I discard the ACI BASE24-es doc?

 

Now i understand the flow, so JPOS will process fields depending on the formats one has defined in the packager file. Thats a great one as far as platform independence is concerned.

 

About the use of q2.jar still I have not got it right.

- I downloaded jpos-1.6.2-r2626,

- Built it with ant run , this process generates extra files and folders.

 

Now am stack at that level, if I may ask, how do i proceed from here?

How do i start the server?

I have seen a case where the Isoserver is launched by executing java -jar q2.jar, but I wonder what kind of setup was done before such a thing can happen.

Also I can't find the bin/example or bin/example.bat, where are they located?

 

Please help me on this, please bear with me, I know am asking so many questions.

But I want to learn and understand the JPOS framework and how to apply it in real life

to develop Isoservers.

 

thanks&regards,

On Wed, Sep 17, 2008 at 3:54 PM, Mark Salter <marks...@talktalk.net> wrote:

mutumba wycliff wrote:

> Thats alright, indeed its a good idea that this discussion is open to
>  all other members.

But still replied direct instead of to the list
(jpos-...@googlegroups.com)?

Andy has added some useful links - on list - which you may find useful
as working examples.

I will not include the list this time - the reasons why I will highlight
- but please send you next email to the list, so that everyone can share
and contribute.

If personal consultancy is something you do desire, then the jpos.org do
a very reasonable line in consultancy. 8)

>
> Your advise to base my modifications on the specification of the
> target system am looking at is indeed a wise decision, instead of I
> having to look at the general ISO 8583 version 1993 standard
> specification. Infact the system am looking at is BASE24-es ISO'93,
> its based on ISO 8583:1993. I have received their ISO spec and there
>  are some variations that have really worried me and I wonder if I
> can achieve the setup with the JPOS framework.
>
> Below are some of the variations;

> The BASE24-es ISO host external message varies from the ISO standard
> in that it does not use binary data fields.

This is not a variation from the spec, as long as the field structures
are defined in the ISO8583 spec, then they are on standard.

> Several elements in the ISO external message have been standardized
> as binary fields; however, the BASE24-es external message is sent
> entirely in character format.

> The reason for this is that BASE24-es
> does not support transparent communications with its hosts, and
> consequently, the use of binary data could cause the unintentional
> introduction of control characters into the data transmission stream.

Perhaps 20 or 30 years ago, but this is no longer a real worry on a
confirmed delivery protocol (TCP/IP).

Who gave you that information, not ACI I hope!!?

N.B. If ACI have told you this, then that is terrible, can you give me a
name, it would be nice to have them on about it should we meet 8) ?
If you have come to this flawed conclusion yourself then I hope I have
helped clear your mind.
(This is why I have not included the list in this reply).

> The ISO data elements affected by this are as follows: - Primary and
>  secondary bit maps - Message Authentication Code data elements - PIN
>  data element - Key Management Data element
>
> Mark, do you think JPOS will take into consideration such variations?

jPOS 'simply' processes the fields as *you* define them to it.  I have
utmost confidence that the fields in this message structure will be
supported by the jPOS available components.

> PS: This q2.jar API, how can one make it such that you can launch
> your application from a batch file with such a stmt? java -jar q2.jar

You probably just need to include the other components on the classpath
- use the bin/example or bin/example.bat as models fro the jpos
download, these will stand you in good stead.

--
Mark

[mutumba wycliff]

Thanks Mark, for all the clarifications.

 

Let me quickly go through Andy's response on this link.

 

Well, let me follow the ACI specs and see if I can produce messages their system can process.

 

On the q2, I actually saw some application from a friend of mine, where his start point is a run.bat

whose contents are java -jar q2.jar in and the root folder he has a q2.jar.

So I was actually wondering how he is using q2.jar to launch the Isoserver together with all those ISometer screens.

By the way, how can I incorporate an Isometer in my ISoserver such that message procesing activity shows a green line/wave on the isometer screen?

 

regards,

On Wed, Sep 17, 2008 at 8:12 PM, Mark Salter <marks...@talktalk.net> wrote:

This is a bit strange...

... you replied to the list, publishing the note that I chose not to
post because of my 'attack' on ACI.

Nevermind.

mutumba wycliff wrote:
>
> How can I access those links you said have been added by Andy?

The link I was talking about are in Andy's response on the list:-

http://groups.google.co.uk/group/jpos-users/browse_thread/thread/21581d85e3e6fe80?hl=en

just look through the whole chain for a response from Andy Orrock.

If you post through this interface (I know it is not the best) then it
may be easier to keep track of who needs to know what.

>
> Actually the info I am giving you, I got it from ACI a document on BASE24-es
> ISO 93 Host External Message exchange.I can even send you a copy of this
> document if you don't mind.

No please don't do that, it will be a copyrighted work, which I have not
paid to see and you don't have permission to distribute.

>
> Indeed thanks alot for clearing my mind on this variation. My self I was
> convinced that it was a valid statement and I was so worried on how to
> implement such cases where the Bitmap is not sent as a binary field and
> instead comes as ASCII (AN).
> According to ACI field 1 will be of type AN 16 instead of
> org.jpos.iso.IFB_BITMAP as specified in the packager file.
> So in this case are you saying I discard the ACI BASE24-es doc?

The ACI spec is the one you *must* follow if you are to produce messages
that their solution will process correctly.

The messages they use are theirs to define, so you must follow their map.

>
> Now i understand the flow, so JPOS will process fields depending on the
> formats one has defined in the packager file. Thats a great one as far as
> platform independence is concerned.

Yes the packager tells jPOS what each field looks like and it handles
the unpacking of a message off of the network into an ISOMsg.

>
> About the use of q2.jar still I have not got it right.
> - I downloaded jpos-1.6.2-r2626,
> - Built it with ant run , this process generates extra files and folders.
>
> Now am stack at that level, if I may ask, how do i proceed from here?
> How do i start the server?
> I have seen a case where the Isoserver is launched by executing java -jar
> q2.jar, but I wonder what kind of setup was done before such a thing can
> happen.

I think you should be looking at jpos-ee which is the new 'q2'.

This can be run from 'ant run' at the simplest level.

You need to running :-

       java -jar q2.jar

will I think complain about missing classes, so I think you need
supplement this command with extra classpath files.  Just like
example.bat does.

I have never done what you are trying to do, so I would have to try it
to find out for you.  Sometimes life is too short.

8(

> Also I can't find the bin/example or bin/example.bat, where are they
> located?

These are in the bin folder of the jpos source download - or where last
time I looked?

--
Mark

[mwyc...@gmail.com]

Thanks Andy,

Let me get started with those examples/notes/excersises and also stick
to the providers
spec, just like you and Mark have advised.
Will get back incase of any challenges

regards,

> Mark- Hide quoted text -
>
> - Show quoted text -

[mwyc...@gmail.com]

Andy,

some where in http://www.andyorrock.com/paymentsystems/2006/09/implementing_th.html
you talk about default isopackager.

which is the default isopackager that comes with the jPOS download ?

After I have built JPOS with ant run, which one of the packagers in
folder build\cfg\packager
is the default and where in JPOS is it specified as the default?

regards

On 17 Sep, 15:24, "Andy Orrock" <aaorr...@gmail.com> wrote:

[Andy Orrock]

Yes, but please understand: the starting point on your first effort makes
no difference. ANY packager will do. It's your ending point that matters.
The packager alignment exercise is the same amount of work no matter where
you start.

That said, I suspect your best starting point will be found here:

http://andyorrock.typepad.com/paymentsystems/b24.xml

I am providing this with no guarantees. All B24 implementations are NOT
alike. YMMV. You must still go through it field by field to confirm
alignment with your needs. This is your responsibility from here. And, of
course, it does not obviate the need to build supporting code. As you will
know from reading my On-Boarding Guide, the packager is only one piece of
the puzzle.

Andy Orrock

(to reiterate Mark's comment: don't cc me on future e-mails; I'm a list
member).

[mwyc...@gmail.com]

Alright Andy,

Indeed you are right, its the ending point that will determine and
definately I need to stick to the Interchange specification.

If I may ask, could some one out there by any chance have an
ISOpackager configured for ACI BASE24-es ISO 93?
Please help me out incase you have done some JPOS implementation based
on ACI's BASE24-es ISO 93, I would really appreciate.
You know its always good to ask around than starting from scratch.

Andy, I can't access this link http://andyorrock.typepad.com/paymentsystems/b24.xml
it returns error The system cannot locate the object specified. Error
processing resource.

thanks&regards,

On Sep 18, 4:01 pm, "Andy Orrock" <aaorr...@gmail.com> wrote:
> Yes, but please understand:  the starting point on your first effort makes
> no difference.  ANY packager will do.  It's your ending point that matters.
> The packager alignment exercise is the same amount of work no matter where
> you start.
>
> That said, I suspect your best starting point will be found here:
>
> http://andyorrock.typepad.com/paymentsystems/b24.xml 
>
> I am providing this with no guarantees.  All B24 implementations are NOT
> alike.  YMMV.  You must still go through it field by field to confirm
> alignment with your needs.  This is your responsibility from here.  And, of
> course, it does not obviate the need to build supporting code.  As you will
> know from reading my On-Boarding Guide, the packager is only one piece of
> the puzzle.
>
> Andy Orrock
>
> (to reiterate Mark's comment: don't cc me on future e-mails; I'm a list
> member).
>
>
>
> -----Original Message-----
> From: jpos-...@googlegroups.com [mailto:jpos-...@googlegroups.com] On
>

> Behalf Of mwycli...@gmail.com

> Sent: Thursday, September 18, 2008 4:46 AM
> To: jPOS Users
> Cc: andy orrock; Mark Salter
> Subject: Re: JPOS and ISO 8583 Version 1993
>
> Andy,
>

> some where inhttp://www.andyorrock.com/paymentsystems/2006/09/implementing_th.html

> > - Show quoted text -- Hide quoted text -

[Andy Orrock]

I think the problem is on your end.

See:

http://screencast.com/t/qidRXFsR

" You know its always good to ask around than starting from scratch."

1. You're not starting from scratch. You're starting from an existing
packager. It's an hour's exercise, two hours at most.

2. Aligning the packager to your spec is The Essential jPOS Task (TM) (see
http://tinyurl.com/whyskipthis) and critical to your understanding of all
that follows.

[mwyc...@gmail.com]

Hi all,
hoping you are fine.

Andy, thanks for the b24_open Jing link, I was able to view details in
it.
It has Base24 field descriptions.If I may ask, is this similar to the
Base24.xml file that comes with JPOS?

As you know my target system is based on ACI Base24-es ISO 93 system,
and as you and Mark ahd advised, I am reading the ACI Base24-es
Interchange spec so I can be able to build the corresponding
ISOPackager, however, I have some challenges already. I have failed to
understand the meaning/implication for the following statements and
how I can go about them while building the ISOPackager;

STMT 1 :
No binary data should be placed in any data element.

Does this mean that my IsoPackager should not have any Binary
representation even for Field 1(BIT MAP)??

STMT 2:
The BASE24-es ISO ‘93 host external message allows for the
transmission of all
128 data elements that are a part of the ISO 8583:1993 standard. Not
all of these
data elements are used for processing by BASE24-es, however. In fact,
many
times only a small number are required.
A primary advantage of the BASE24-es ISO host external message is that
a data
element need not be included in the external message if it is not
needed for
processing.

Andy, in your implementing_th.html, you had advised that its best
practice to define all 128 fields in your isopackager. In this case of
ACI Base24-es spec as per the stmt 2 above), what would you advise me
to do? Should I do for all fields??

STMT 3:

The BASE24-es ISO host external message varies from the ISO standard
in that it

does not use binary data fields. Several elements in the ISO external

message have
been standardized as binary fields; however, the BASE24-es external
message is
sent entirely in character format.

The ISO data elements affected by this are as follows:
- Primary and secondary bit maps

- Message Authentication Code data elements (P-64 and S-128)
- PIN data element (P-52)
- Key Management Data element (S-96)

Does this mean that in this case the Data representation for all
fields will be ASCII??
since in the spec its indicated that the BASE24-es external message is

sent entirely in character format.

Does this also mean that in my ISOPackager all Field Type definitions
will be of the form IFA_ and NOT IFE_ or IFB_ ??

For the AMEX system, I see your Field Type definitions all started
with IFE_, does this mean the AMEX is only based on EBCDIC format??

Please advise me on the above statements.

regards,

On Sep 22, 4:26 pm, "Andy Orrock" <aaorr...@gmail.com> wrote:
> I think the problem is on your end.
>
> See:
>
> http://screencast.com/t/qidRXFsR 
>
> " You know its always good to ask around than starting from scratch."
>
> 1. You're not starting from scratch.  You're starting from an existing
> packager.  It's an hour's exercise, two hours at most.
>

> 2. Aligning the packager to your spec is The Essential jPOS Task (TM) (seehttp://tinyurl.com/whyskipthis) and critical to your understanding of all

> that follows.  
>
>
>
> -----Original Message-----
> From: jpos-...@googlegroups.com [mailto:jpos-...@googlegroups.com] On
>

> Behalf Of mwycli...@gmail.com

> Sent: Monday, September 22, 2008 3:29 AM
> To: jPOS Users
> Subject: Re: JPOS and ISO 8583 Version 1993
>
> Alright Andy,
>
> Indeed you are right, its the ending point that will determine and
> definately I need to stick to the Interchange specification.
>
> If I may ask, could some one out there by any chance have an
> ISOpackager configured for ACI BASE24-es ISO 93?
> Please help me out incase you have done some JPOS implementation based
> on ACI's BASE24-es ISO 93, I would really appreciate.
> You know its always good to ask around than starting from scratch.
>

> Andy, I can't access this linkhttp://andyorrock.typepad.com/paymentsystems/b24.xml

[Alejandro Revilla]

iso93ascii.xml is probably a good starting point.

[Andy Orrock]

My friend, you are thinking way too hard about this.

I have given you the answer you need here...

http://andyorrock.typepad.com/paymentsystems/b24.xml

You seem to be working hard to ignore that.

Just a quick glance at some of your concerns tells you the packager solves
that:

Here's the Secondary Bit Map - it's ASCII & and tips the packager to treat
the primary bit map the same way:

<isofield
id="1"
length="16"
name="BIT MAP"
class="org.jpos.iso.IFA_BITMAP"/>

The same for 52, 64, 96 and 128...all defined as you need them.

I suspect you may need to need to address specific points like the STAN
(probably 12 not 6 in length on the ISO 1993 implementation).

Yes, you need to do all 128 fields. It would be crazy not to have them all
defined. It doesn’t take a lot of time.

On AMEX: Yes, it's EDCDIC. The example is not meant to be followed
literally. It's a good basis for the exercise I posted simply because
AMEX's spec is available online, is well-written and easy to follow. It's
there for you to follow the technique, not to advocate using AMEX as your
starting point.

Andy

[mwyc...@gmail.com]

Andy/Alejandro/Mark and all JPOS group users, Thanks for your advice
and clarifications.
I really do appreciate.

Andy,

Reference is made to the On-Boarding Doc - Item 2.1.1 Add new sub-
directory structure.

Please walk me through the steps involved in creating a sub-dir
structure for the provider in question e.g If am creating for ACI
BASE24-es system i wold need to create a sub-dir like ACI, just like
you did for AMEX.
Given that I have just downloaded jpos-1.6.2-r2626.zip and unzipped
it,
How do I proceed?

At what point do I need to execute "ant run"? Is it after creating the
sub-dir or after?

I realise that after executing "ant run" a build folder is created,
incase I copy this build folder and paste it in another location can
it work as an IsoServer or it requires other files?

I read the JPOS guide, but I didn't understand the difference between
a ISOPackager and a ISOFieldPackager.
When do we use ISO93BPackager.java and iso93binary.xml?
Is one a substitute of the other or the two have to used at the same
time.
I really don't understand how Generic Packagers and Custom packagers
work.
What is the difference, is it that one can choose to go Generic or
Custom which is best?
The whole concenpt really confuses me.
Please someone help me understand the difference between the two and
which one is most prefered and easy to use.

Andy, please copy for me the contents of b24.xml on this link
http://andyorrock.typepad.com/paymentsystems/b24.xml
and paste into a notepad and send me as an attachment. Like I told
earlier, from my IE i get an error when i try to access it.

The other thing I have found out is that iso93ascii.xml is more close
in definition to BASE24-es ISO 93 spec just like Alejandro advised.
Fore instance when you go through it, all the isoField names match
what is in the ACI BASE24-es spec. Am yet to look at the field classes
and length.

> Behalf Of mwycli...@gmail.com

> ...
>
> read more »- Hide quoted text -

[Mark Salter]

mwyc...@gmail.com wrote:

> Reference is made to the On-Boarding Doc - Item 2.1.1 Add new sub-
> directory structure.
>
> Please walk me through the steps involved in creating a sub-dir
> structure for the provider in question e.g If am creating for ACI
> BASE24-es system i wold need to create a sub-dir like ACI, just like
> you did for AMEX.

The new folder you want to create is just a place to hold everything
related to the system you want to talk to.

Within in it, you probably want to place any code relating to your work,
and also any packager definitions you decide you want to use or develop
to match your specification.

> Given that I have just downloaded jpos-1.6.2-r2626.zip and unzipped
> it,

Can you locate the modules folder? You should note that Andy's guide is
against a local copy of the svn repository, so start by looking for a
folder called modules, you should find it in the top level of the folder
you extracted the zip file into:-

[your_directory]\modules\

> How do I proceed?
>
> At what point do I need to execute "ant run"? Is it after creating the
> sub-dir or after?

ant run builds the system and then runs it. If you want your 'ACI
module' to be included in the run, then you will need to complete your
development before running it.

If you just want to see it running without any of your code, run it on a
fresh zip extract...

Assuming you have ant on your path - are you running on windows or unix?
- open a command window, navigate to the [your_directory] and then type:-
ant run

'stuff' will happen and you should get the not terribly satisfying
result of a running jpos instance and perhaps something like :-

run:
[java] <log realm="Q2.system" at="Thu Sep 25 17:27:06 BST 2008.477">
[java] <info>
[java] Q2 started, deployDir=C:\jpos1.6.2\build\deploy
[java] </info>
[java] </log>
[java] <log realm="Q2.system" at="Thu Sep 25 17:27:06 BST 2008.587">
[java] <info>
[java] new classloader [107ebe1] has been created
[java] </info>
[java] </log>
[java] <log realm="Q2.system" at="Thu Sep 25 17:27:06 BST 2008.587">
[java] <info>
[java] deploy:C:\jpos1.6.2\build\deploy\99_sysmon.xml
[java] </info>
[java] </log>
[java] <log realm="org.jpos.q2.qbean.SystemMonitor" at="Thu Sep 25
17:27:06 BST 2008.602">
[java] <info>
[java] Starting SystemMonitor
[java] </info>
[java] </log>
[java] <log realm="org.jpos.q2.qbean.SystemMonitor" at="Thu Sep 25
17:27:06 BST 2008.634">
[java] <info>
[java] <release>1.6.2$Revision: 2626 $</release>
[java] <memory>
[java] freeMemory=1375048
[java] totalMemory=2031616
[java] inUseMemory=656568
[java] </memory>
[java] <threads>
[java] delay=0 ms
[java] threads=3
[java] Thread[Reference Handler,10,system]
[java] Thread[Finalizer,8,system]
[java] Thread[Signal Dispatcher,9,system]
[java] Thread[main,5,main]
[java] Thread[Timer-0,5,main]
[java] Thread[SystemMonitor,5,main]
[java] </threads>
[java] --- name-registrar ---
[java] logger.Q2: org.jpos.util.Logger
[java] </info>
[java] </log>

I know it doesn't look like much, but at this point you are running a
system that will support the "hot plugging" of xml files that might
define servers or clients or any number of the other jpos components to
form your system...

>
> I realise that after executing "ant run" a build folder is created,
> incase I copy this build folder and paste it in another location can
> it work as an IsoServer or it requires other files?

You could reference the build folder - or indeed the jar file generated
for you in the build folder.

For now, just leave things where they are and think about preparing the
files you will need for your development.

>
> I read the JPOS guide, but I didn't understand the difference between
> a ISOPackager and a ISOFieldPackager.
> When do we use ISO93BPackager.java and iso93binary.xml?
> Is one a substitute of the other or the two have to used at the same
> time.

These files are two ways of saying almost the same thing. Using either
results in a packager that jpos can you to pack or unpack messages.

The xml file will need to go 'through' the genericpackager code which
not surprisingly takes an xml definition of a packager and builds the
java object just like it came from a piece of java code.

> I really don't understand how Generic Packagers and Custom packagers
> work.
> What is the difference, is it that one can choose to go Generic or
> Custom which is best?

See above, the choice is yours, but I suggest you use the xml route.

> The whole concenpt really confuses me.
> Please someone help me understand the difference between the two and
> which one is most prefered and easy to use.

Hopefully done above...

>
> Andy, please copy for me the contents of b24.xml on this link
> http://andyorrock.typepad.com/paymentsystems/b24.xml
> and paste into a notepad and send me as an attachment. Like I told
> earlier, from my IE i get an error when i try to access it.

You may have downloads blocked or no file association for xml files. I
have sent it to you directly - for free 8).

>
> The other thing I have found out is that iso93ascii.xml is more close
> in definition to BASE24-es ISO 93 spec just like Alejandro advised.
> Fore instance when you go through it, all the isoField names match
> what is in the ACI BASE24-es spec. Am yet to look at the field classes
> and length.

This is good news. Your aim is to derive a packager that *matches*
*your* *spec*, you could start from scratch, but if iso93ascii.xml is a
near match, copy that and edit it to suit your needs, in the name
include ACI, just to keep it separate in future. You never know you
might need the old, unchanged version!

Once you have the packager, you can prepare and start a server and a
channel that use your packager, that we can talk about in another thread...

8)

--
Mark

[David Bergert]

So you must of missed the part:

>>
>> Actually the info I am giving you, I got it from ACI a document on
BASE24-es

>> ISO 93 Host External Message exchange. I can even send you a copy of this

>> document if you don't mind.

>No please don't do that, it will be a copyrighted work, which I have not
>paid to see and you don't have permission to distribute.

and decided to go ahead and post parts of their copyrighted spec anyway ?

> -----Original Message-----
> From: jpos-...@googlegroups.com [mailto:jpos-...@googlegroups.com]
> On Behalf Of mwyc...@gmail.com
> Sent: Friday, September 26, 2008 11:39 AM
> To: jPOS Users
> Subject: Re: JPOS and ISO 8583 Version 1993
>
>

> Thanks so much Mark,
>
> I have actually executed 'ant run' on a fresh copy of JPOS 1.6.2 and
> it started well with similar results as you have indicated.
> Assuming I already have some piece of code for my work(in for of a jar
> file say 'aci.jar' ) and I have the ISOPackager (aci_base24_iso93.xml)
> already defined, do I just drop them in my ACI folder that I would
> have created in the Modules dir?
> Is there any specific directory structure that should be followed for
> all folders added to the modules dir?.
> Foreinstance when I look in the q2 folder under the modules dir, i see
> there is this grouping (deploy, lib, src).
>
> I have read the data element definitions for the ACI Base24 spec and
> below is the IsoPackager I have come up with. However, I need a second
> or third eye to help me go through and confimr if am on the right
> truck.
> Please advise me accordingly incase you identify any problems in it.
>
> <?xml version="1.0" encoding="UTF-8" standalone="no"?>
> <!DOCTYPE isopackager SYSTEM "genericpackager.dtd">
>
> <!-- ACI BASE24-es ISO 8583:1993 (ASCII) field descriptions for
> GenericPackager -->
>
> <isopackager>
> <isofield
> id="0"
> length="4"
> name="Message Type Indicator"
> class="org.jpos.iso.IFA_NUMERIC"/>

> <isofield
> id="1"
> length="16"

> name="Bitmap"
> class="org.jpos.iso.IFA_BITMAP"/>
> <isofield
> id="2"
> length="19"
> name="Primary Account number"
> class="org.jpos.iso.IFA_LLNUM"/>
> <isofield
> id="3"
> length="6"
> name="Processing Code"
> class="org.jpos.iso.IF_CHAR"/>
> <isofield
> id="4"
> length="12"
> name="Amount, Transaction"
> class="org.jpos.iso.IFA_NUMERIC"/>
> <isofield
> id="5"
> length="12"
> name="Amount, Reconciliation"
> class="org.jpos.iso.IFA_NUMERIC"/>
> <isofield
> id="6"
> length="12"
> name="Amount, Cardholder billing"
> class="org.jpos.iso.IFA_NUMERIC"/>
> <isofield
> id="7"
> length="10"
> name="Date and time, transmission"
> class="org.jpos.iso.IFA_NUMERIC"/>
> <isofield
> id="8"
> length="8"
> name="Amount, Cardholder billing fee"
> class="org.jpos.iso.IFA_NUMERIC"/>
> <isofield
> id="9"
> length="8"
> name="Conversion rate, Reconciliation"
> class="org.jpos.iso.IFA_NUMERIC"/>
> <isofield
> id="10"
> length="8"
> name="Conversion rate, Cardholder billing"
> class="org.jpos.iso.IFA_NUMERIC"/>
> <isofield
> id="11"
> length="6"
> name="Systems trace audit number"
> class="org.jpos.iso.IFA_NUMERIC"/>
> <isofield
> id="12"
> length="12"
> name="Date and time, Local transaction"
> class="org.jpos.iso.IFA_NUMERIC"/>
> <isofield
> id="13"
> length="4"
> name="Date, Effective"
> class="org.jpos.iso.IFA_NUMERIC"/>
> <isofield
> id="14"
> length="4"
> name="Date, Expiration"
> class="org.jpos.iso.IFA_NUMERIC"/>
> <isofield
> id="15"
> length="6"
> name="Date, Settlement"
> class="org.jpos.iso.IFA_NUMERIC"/>
> <isofield
> id="16"
> length="4"
> name="Date, Conversion"
> class="org.jpos.iso.IFA_NUMERIC"/>
> <isofield
> id="17"
> length="4"
> name="Date, Capture"
> class="org.jpos.iso.IFA_NUMERIC"/>
> <isofield
> id="18"
> length="4"
> name="Merchant type"
> class="org.jpos.iso.IFA_NUMERIC"/>
> <isofield
> id="19"
> length="3"
> name="Country code, Acquiring institution"
> class="org.jpos.iso.IFA_NUMERIC"/>
> <isofield
> id="20"
> length="3"
> name="Country code, Primary account number"
> class="org.jpos.iso.IFA_NUMERIC"/>
> <isofield
> id="21"
> length="3"
> name="Country code, Forwarding institution"
> class="org.jpos.iso.IFA_NUMERIC"/>
> <isofield
> id="22"
> length="12"
> name="Point of service data code"
> class="org.jpos.iso.IF_CHAR"/>
> <isofield
> id="23"
> length="3"
> name="Card sequence number"
> class="org.jpos.iso.IFA_NUMERIC"/>
> <isofield
> id="24"
> length="3"
> name="Function code"
> class="org.jpos.iso.IFA_NUMERIC"/>
> <isofield
> id="25"
> length="4"
> name="Message reason code"
> class="org.jpos.iso.IFA_NUMERIC"/>
> <isofield
> id="26"
> length="4"
> name="Card acceptor business code"
> class="org.jpos.iso.IFA_NUMERIC"/>
> <isofield
> id="27"
> length="1"
> name="Approval code length"
> class="org.jpos.iso.IFA_NUMERIC"/>
> <isofield
> id="28"
> length="6"
> name="Date, Reconciliation"
> class="org.jpos.iso.IFA_NUMERIC"/>
> <isofield
> id="29"
> length="3"
> name="Reconciliation indicator"
> class="org.jpos.iso.IFA_NUMERIC"/>
> <isofield
> id="30"
> length="24"
> name="Amounts, original"
> class="org.jpos.iso.IFA_NUMERIC"/>
> <isofield
> id="31"
> length="99"
> name="Acquirer reference data"
> class="org.jpos.iso.IFA_LLCHAR"/>
> <isofield
> id="32"
> length="11"
> name="Acquirer institution identification code"
> class="org.jpos.iso.IFA_LLNUM"/>
> <isofield
> id="33"
> length="11"
> name="Forwarding institution identification code"
> class="org.jpos.iso.IFA_LLNUM"/>
> <isofield
> id="34"
> length="28"
> name="Primary account number, extended"
> class="org.jpos.iso.IFA_LLCHAR"/>
> <isofield
> id="35"
> length="37"
> name="Track 2 data"
> class="org.jpos.iso.IFA_LLCHAR"/>
> <isofield
> id="36"
> length="104"
> name="Track 3 data"
> class="org.jpos.iso.IFA_LLLCHAR"/>
> <isofield
> id="37"
> length="12"
> name="Retrieval reference number"
> class="org.jpos.iso.IF_CHAR"/>
> <isofield
> id="38"
> length="6"
> name="Approval code"
> class="org.jpos.iso.IF_CHAR"/>
> <isofield
> id="39"
> length="3"
> name="Action code"
> class="org.jpos.iso.IFA_NUMERIC"/>
> <isofield
> id="40"
> length="3"
> name="Service code"
> class="org.jpos.iso.IFA_NUMERIC"/>
> <isofield
> id="41"
> length="16"
> name="Card acceptor terminal identification"
> class="org.jpos.iso.IF_CHAR"/>
> <isofield
> id="42"
> length="15"
> name="Card acceptor identification code"
> class="org.jpos.iso.IF_CHAR"/>
> <isofield
> id="43"
> length="99"
> name="Card acceptor name/location"
> class="org.jpos.iso.IFA_LLCHAR"/>
> <isofield
> id="44"
> length="99"
> name="Additional response data"
> class="org.jpos.iso.IFA_LLCHAR"/>
> <isofield
> id="45"
> length="76"
> name="Track 1 data"
> class="org.jpos.iso.IFA_LLCHAR"/>
> <isofield
> id="46"
> length="204"
> name="Amounts, Fees"
> class="org.jpos.iso.IFA_LLLCHAR"/>
> <isofield
> id="47"
> length="999"
> name="Additional data - national"
> class="org.jpos.iso.IFA_LLLCHAR"/>
> <isofield
> id="48"
> length="999"
> name="Additional data - private"
> class="org.jpos.iso.IFA_LLLCHAR"/>
> <isofield
> id="49"
> length="3"
> name="Currency code, Transaction"
> class="org.jpos.iso.IF_CHAR"/>
> <isofield
> id="50"
> length="3"
> name="Currency code, Reconciliation"
> class="org.jpos.iso.IF_CHAR"/>
> <isofield
> id="51"
> length="3"
> name="Currency code, Cardholder billing"
> class="org.jpos.iso.IF_CHAR"/>
> <isofield
> id="52"
> length="16"
> name="Personal identification number [PIN] data"
> class="org.jpos.iso.IF_CHAR"/>
> <isofield
> id="53"
> length="48"
> name="Security related control information"
> class="org.jpos.iso.IFA_LLBINARY"/>
> <isofield
> id="54"
> length="120"
> name="Amounts, additional"
> class="org.jpos.iso.IFA_LLLCHAR"/>
> <isofield
> id="55"
> length="255"
> name="IC card system related data"
> class="org.jpos.iso.IFA_LLLBINARY"/>
> <isofield
> id="56"
> length="35"
> name="Original data elements"
> class="org.jpos.iso.IFA_LLNUM"/>
> <isofield
> id="57"
> length="3"
> name="Authorization life cycle code"
> class="org.jpos.iso.IFA_NUMERIC"/>
> <isofield
> id="58"
> length="11"
> name="Authorizing agent institution Id Code"
> class="org.jpos.iso.IFA_LLNUM"/>
> <isofield
> id="59"
> length="999"
> name="Transport data"
> class="org.jpos.iso.IFA_LLLCHAR"/>
> <isofield
> id="60"
> length="999"
> name="Reserved for national use"
> class="org.jpos.iso.IFA_LLLCHAR"/>
> <isofield
> id="61"
> length="999"
> name="Reserved for national use"
> class="org.jpos.iso.IFA_LLLCHAR"/>
> <isofield
> id="62"
> length="999"
> name="Reserved for private use"
> class="org.jpos.iso.IFA_LLLCHAR"/>
> <isofield
> id="63"
> length="999"
> name="Reserved for private use"
> class="org.jpos.iso.IFA_LLLCHAR"/>
> <isofield
> id="64"
> length="16"
> name="Message authentication code field"
> class="org.jpos.iso.IF_CHAR"/>
> <isofield
> id="65"
> length="8"
> name="Reserved for ISO use"
> class="org.jpos.iso.IFA_BINARY"/>
> <isofield
> id="66"
> length="204"
> name="Amounts, original fees"
> class="org.jpos.iso.IFA_LLLCHAR"/>
> <isofield
> id="67"
> length="2"
> name="Extended payment data"
> class="org.jpos.iso.IFA_NUMERIC"/>
> <isofield
> id="68"
> length="3"
> name="Country code, receiving institution"
> class="org.jpos.iso.IFA_NUMERIC"/>
> <isofield
> id="69"
> length="3"
> name="Country code, settlement institution"
> class="org.jpos.iso.IFA_NUMERIC"/>
> <isofield
> id="70"
> length="3"
> name="Country code, authorizing agent Inst."
> class="org.jpos.iso.IFA_NUMERIC"/>
> <isofield
> id="71"
> length="8"
> name="Message number"
> class="org.jpos.iso.IFA_NUMERIC"/>
> <isofield
> id="72"
> length="999"
> name="Data record"
> class="org.jpos.iso.IFA_LLLCHAR"/>
> <isofield
> id="73"
> length="6"
> name="Date, action"
> class="org.jpos.iso.IFA_NUMERIC"/>
> <isofield
> id="74"
> length="10"
> name="Credits, number"
> class="org.jpos.iso.IFA_NUMERIC"/>
> <isofield
> id="75"
> length="10"
> name="Credits, reversal number"
> class="org.jpos.iso.IFA_NUMERIC"/>
> <isofield
> id="76"
> length="10"
> name="Debits, number"
> class="org.jpos.iso.IFA_NUMERIC"/>
> <isofield
> id="77"
> length="10"
> name="Debits, reversal number"
> class="org.jpos.iso.IFA_NUMERIC"/>
> <isofield
> id="78"
> length="10"
> name="Transfer, number"
> class="org.jpos.iso.IFA_NUMERIC"/>
> <isofield
> id="79"
> length="10"
> name="Transfer, reversal number"
> class="org.jpos.iso.IFA_NUMERIC"/>
> <isofield
> id="80"
> length="10"
> name="Inquiries, number"
> class="org.jpos.iso.IFA_NUMERIC"/>
> <isofield
> id="81"
> length="10"
> name="Authorizations, number"
> class="org.jpos.iso.IFA_NUMERIC"/>
> <isofield
> id="82"
> length="10"
> name="Inquiries, reversal number"
> class="org.jpos.iso.IFA_NUMERIC"/>
> <isofield
> id="83"
> length="10"
> name="Payments, number"
> class="org.jpos.iso.IFA_NUMERIC"/>
> <isofield
> id="84"
> length="10"
> name="Payments, reversal number"
> class="org.jpos.iso.IFA_NUMERIC"/>
> <isofield
> id="85"
> length="10"
> name="Fee collections, number"
> class="org.jpos.iso.IFA_NUMERIC"/>
> <isofield
> id="86"
> length="16"
> name="Credits, amount"
> class="org.jpos.iso.IFA_NUMERIC"/>
> <isofield
> id="87"
> length="16"
> name="Credits, reversal amount"
> class="org.jpos.iso.IFA_NUMERIC"/>
> <isofield
> id="88"
> length="16"
> name="Debits, amount"
> class="org.jpos.iso.IFA_NUMERIC"/>
> <isofield
> id="89"
> length="16"
> name="Debits, reversal amount"
> class="org.jpos.iso.IFA_NUMERIC"/>
> <isofield
> id="90"
> length="10"
> name="Authorizations, reversal number"
> class="org.jpos.iso.IFA_NUMERIC"/>
> <isofield
> id="91"
> length="3"
> name="Country code, transaction Dest. Inst."
> class="org.jpos.iso.IFA_NUMERIC"/>
> <isofield
> id="92"
> length="3"
> name="Country code, transaction Orig. Inst."
> class="org.jpos.iso.IFA_NUMERIC"/>
> <isofield
> id="93"
> length="11"
> name="Transaction Dest. Inst. Id code"
> class="org.jpos.iso.IFA_LLNUM"/>
> <isofield
> id="94"
> length="11"
> name="Transaction Orig. Inst. Id code"
> class="org.jpos.iso.IFA_LLNUM"/>
> <isofield
> id="95"
> length="99"
> name="Card issuer reference data"
> class="org.jpos.iso.IFA_LLCHAR"/>
> <isofield
> id="96"
> length="999"
> name="Key management data"
> class="org.jpos.iso.IFA_LLLCHAR"/>
> <isofield
> id="97"
> length="17"
> name="Amount, Net reconciliation"
> class="org.jpos.iso.IFA_AMOUNT"/>
> <isofield
> id="98"
> length="25"
> name="Payee"
> class="org.jpos.iso.IF_CHAR"/>
> <isofield
> id="99"
> length="11"
> name="Settlement institution Id code"
> class="org.jpos.iso.IFA_LLCHAR"/>
> <isofield
> id="100"
> length="11"
> name="Receiving institution Id code"
> class="org.jpos.iso.IFA_LLNUM"/>
> <isofield
> id="101"
> length="17"
> name="File name"
> class="org.jpos.iso.IFA_LLCHAR"/>
> <isofield
> id="102"
> length="28"
> name="Account identification 1"
> class="org.jpos.iso.IFA_LLCHAR"/>
> <isofield
> id="103"
> length="28"
> name="Account identification 2"
> class="org.jpos.iso.IFA_LLCHAR"/>
> <isofield
> id="104"
> length="100"
> name="Transaction description"
> class="org.jpos.iso.IFA_LLLCHAR"/>
> <isofield
> id="105"
> length="16"
> name="Credits, Chargeback amount"
> class="org.jpos.iso.IFA_NUMERIC"/>
> <isofield
> id="106"
> length="16"
> name="Debits, Chargeback amount"
> class="org.jpos.iso.IFA_NUMERIC"/>
> <isofield
> id="107"
> length="10"
> name="Credits, Chargeback number"
> class="org.jpos.iso.IFA_NUMERIC"/>
> <isofield
> id="108"
> length="10"
> name="Debits, Chargeback number"
> class="org.jpos.iso.IFA_NUMERIC"/>
> <isofield
> id="109"
> length="84"
> name="Credits, Fee amounts"
> class="org.jpos.iso.IFA_LLCHAR"/>
> <isofield
> id="110"
> length="84"
> name="Debits, Fee amounts"
> class="org.jpos.iso.IFA_LLCHAR"/>
> <isofield
> id="111"
> length="999"
> name="Reserved for ISO use"
> class="org.jpos.iso.IFA_LLLCHAR"/>
> <isofield
> id="112"
> length="999"
> name="Reserved for ISO use"
> class="org.jpos.iso.IFA_LLLCHAR"/>
> <isofield
> id="113"
> length="999"
> name="Reserved for ISO use"
> class="org.jpos.iso.IFA_LLLCHAR"/>
> <isofield
> id="114"
> length="999"
> name="Reserved for ISO use"
> class="org.jpos.iso.IFA_LLLCHAR"/>
> <isofield
> id="115"
> length="999"
> name="Reserved for ISO use"
> class="org.jpos.iso.IFA_LLLCHAR"/>
> <isofield
> id="116"
> length="999"
> name="Reserved for national use"
> class="org.jpos.iso.IFA_LLLCHAR"/>
> <isofield
> id="117"
> length="999"
> name="Reserved for national use"
> class="org.jpos.iso.IFA_LLLCHAR"/>
> <isofield
> id="118"
> length="999"
> name="Reserved for national use"
> class="org.jpos.iso.IFA_LLLCHAR"/>
> <isofield
> id="119"
> length="999"
> name="Reserved for national use"
> class="org.jpos.iso.IFA_LLLCHAR"/>
> <isofield
> id="120"
> length="999"
> name="Reserved for national use"
> class="org.jpos.iso.IFA_LLLCHAR"/>
> <isofield
> id="121"
> length="999"
> name="Reserved for national use"
> class="org.jpos.iso.IFA_LLLCHAR"/>
> <isofield
> id="122"
> length="999"
> name="Reserved for national use"
> class="org.jpos.iso.IFA_LLLCHAR"/>
> <isofield
> id="123"
> length="999"
> name="Reserved for private use"
> class="org.jpos.iso.IFA_LLLCHAR"/>
> <isofield
> id="124"
> length="999"
> name="Reserved for private use"
> class="org.jpos.iso.IFA_LLLCHAR"/>
> <isofield
> id="125"
> length="999"
> name="Reserved for private use"
> class="org.jpos.iso.IFA_LLLCHAR"/>
> <isofield
> id="126"
> length="999"
> name="Reserved for private use"
> class="org.jpos.iso.IFA_LLLCHAR"/>
> <isofield
> id="127"
> length="9999"
> name="Reserved for private use"
> class="org.jpos.iso.IFA_LLLLCHAR"/>
> <isofield
> id="128"
> length="8"
> name="Message authentication code field"
> class="org.jpos.iso.IFA_BINARY"/>
> </isopackager>
>
> Below are the details of the Field definitions as per the ACI BASE24-
> es interchange spec
>
> ACI BASE24-es ISO 93
>
> Data Elements 1 Through 64
> This section contains descriptions for data elements 1 through 64 of
> the
> BASE24-es ISO ‘93 host external message. The presence of these data
> elements in
> a message is denoted by the primary bit map.
>
> Summary
> The following table lists the data elements (denoted by bits 1 through
> 64 in the
> Primary bit map) that are used in the BASE24-es ISO ‘93 host external
> message
> and their format. If a data element is not used by the BASE24-es ISO
> ‘93 host
> external message, it is listed as “Not supported.” If a data element
> is not currently
> used by the BASE24-es ISO ‘93 host external message, but may be used
> in the
> future, the format is listed as “Reserved for future use.”
> The data formatting conventions used in the Format column of the table
> are
> described in the “Conventions Used in This Manual”.
>
> 1 Secondary Bit Map AN 16
> 2 Primary Account Number N ..19
> 3 Processing Code AN 6
> 4 Amount, Transaction N 12
> 5 Amount, Reconciliation N 12
> 6 Amount, Cardholder Billing N 12
> 7 Transmission Date and Time N 10 (MMDDhhmmss)
> 8 Not supported Not applicable
> 9 Conversion Rate, Reconciliation N 8 Reserved for future use
> 10 Conversion Rate, Cardholder Billing N 8
> 11 Systems Trace Audit Number N 6
> 12 Date and Time, Local Transaction N 12 (YYMMDDhhmmss)
> 13 Date, Effective N 4 (YYMM)
> 14 Date, Expiration N 4 (YYMM)
> 15 Date, Settlement N 6 (YYMMDD)
> 16 Date, Conversion N 4 (MMDD)
> 17 Date, Capture N 4 (MMDD)
> 18 Merchant Type N 4
> 19 Country Code, Acquiring Institution N 3
> 20 Not supported Not applicable
> 21 Country Code, Forwarding Institution N 3
> 22 Point of Service Data Code AN 12
> 23 Card Sequence Number N 3
> 24 Function Code N 3
> 25 Message Reason Code N 4
> 26 Card Acceptor Business Code N 4
> 27 Approval Code Length N 1
> 28 Date, Reconciliation N 6 (YYMMDD)
> 29 Reconciliation Indicator N 3 Reserved for future use
> 30 Amounts, Original N 24
> 31 Not supported Not applicable
> 32 Acquirer Institution ID Code N ..11
> 33 Forwarding Institution ID Code N ..11
> 34 Primary Account Number, Extended NS ..28
> 35 Track 2 Data Z ..37
> 36 Track 3 Data Z ..104
> 37 Retrieval Reference Number ANP 12
> 38 Approval Code ANP 6
> 39 Action Code N 3
> 40 Service Code N 3
> 41 Card Acceptor Terminal Identification ANS 16
> 42 Card Acceptor Identification Code ANS 15
> 43 Card Acceptor Name/Location ANS ..99
> 44 Additional Response Data ANS ..99 (includes a 2-position field
> length indicator)
> 45 Track 1 Data ANS ..76
> 46 Amounts, Fees ANS ..204
> 47 Not supported Not applicable
> 48 Not supported Not applicable
> 49 Currency Code, Transaction A 3 or N 3
> 50 Currency Code, Reconciliation A 3 or N 3
> 51 Currency Code, Cardholder Billing A 3 or N 3
> 52 Personal Identification Number Data AN 16
> 53 Not supported Not applicable
> 54 Amounts, Additional ANS ..120
> 55 Not supported Not applicable
> 56 Original Data Elements N ..35
> 57 Authorization Life Cycle Code N 3
> 58 Authorizing Agent Institution ID Code N ..11
> 59 Transport Data ANS ..999
> 60 Not supported Not applicable
> 61 Not supported Not applicable
> 62 Primary Reserved Private 62 ANS ..999 (includes a 3-position field
> length indicator)
> 63 Not supported Not applicable
> 64 Message Authentication Code Field AN 16 Reserved for future use
>
>
> Data Elements 65 Through 128
> This section contains descriptions for data elements 65 through 128 of
> the
> BASE24-es ISO ‘93 host external message. The presence of these data
> elements in
> a message is denoted by the Secondary Bit Map (P-1) data element.
>
>
> 65 Not supported
> 66 Not supported
> 67 Not supported
> 68 Country Code, Receiving Institution N 3
> 69 Not supported
> 70 Country Code, Authorizing Agent Institution N 3
> 71 Message Number N 8 Reserved for future use
> 72 Data record ANS ..999 (includes a 3-position field length
> indicator)
> 73 Not supported
> 74 Not supported
> 75 Not supported
> 76 Not supported
> 77 Not supported
> 78 Not supported
> 79 Not supported
> 80 Not supported
> 81 Not supported
> 82 Not supported
> 83 Not supported
> 84 Not supported
> 85 Not supported
> 86 Not supported
> 87 Not supported
> 88 Not supported
> 89 Not supported
> 90 Not supported
> 91 Not supported
> 92 Not supported
> 93 Transaction Destination Institution ID Code N ..11
> 94 Transaction Originator Institution ID Code N ..11
> 95 Not supported
> 96 Key Management Data ANS ..999 (includes a 3-position field length
> indicator)
> 97 Not supported
> 98 Not supported
> 99 Not supported
> 100 Receiving Institution ID Code N ..11
> 102 Account Identification 1 ANS ..28
> 103 Account Identification 2 ANS ..28
> 104 Not supported
> 105 Not supported
> 106 Not supported
> 107 Not supported
> 108 Not supported
> 109 Not supported
> 110 Not supported
> 111 Not supported
> 112 Not supported
> 113 Not supported
> 114 Not supported
> 115 Not supported
> 116 Not supported
> 117 Not supported
> 118 Not supported
> 119 Not supported
> 120 Not supported
> 121 Not supported
> 122 Not supported
> 123 Reserved for Private Use – 123 ANS ..999 (includes a 3-position
> field length indicator)
> 124 Not supported
> 125 Not supported
> 126 Not supported
> 127 Reserved for Private Use – 127 ANS ..9999 (includes a 4-position
> field length indicator)
> 128 Message Authentication Code Field
>
> I have concerns on fields where the Format is give as NS, NS.., Z..,
> ANS, ANS.., ANP
> I wonder how JPOS caters for such formats. Also Field 128 as you can
> above is not defined and I was wondering how to define it in the
> ISOPACKAGER.
>
> I will be glad for all the advice from you JPOS members.
>
> thanks&regards,
>
>
> On Sep 25, 7:41 pm, Mark Salter <marksal...@talktalk.net> wrote:

[Alejandro Revilla]

Dave, thank you for heads-up.

FYI - I've removed the message from the group archive.

I'm so sick of things like this that I'm really considering getting
myself out of these groups; this is going downhill.

--Alejandro

> > BASE24-es ISO ?93 host external message. The presence of these data

> > elements in
> > a message is denoted by the primary bit map.
> >
> > Summary
> > The following table lists the data elements (denoted by bits 1 through
> > 64 in the

> > Primary bit map) that are used in the BASE24-es ISO ?93 host external

> > message
> > and their format. If a data element is not used by the BASE24-es ISO

> > ?93 host
> > external message, it is listed as ?Not supported.? If a data element
> > is not currently
> > used by the BASE24-es ISO ?93 host external message, but may be used
> > in the
> > future, the format is listed as ?Reserved for future use.?

> > The data formatting conventions used in the Format column of the table
> > are

> > described in the ?Conventions Used in This Manual?.

> > BASE24-es ISO ?93 host external message. The presence of these data

> > 123 Reserved for Private Use ? 123 ANS ..999 (includes a 3-position

> > field length indicator)
> > 124 Not supported
> > 125 Not supported
> > 126 Not supported

> > 127 Reserved for Private Use ? 127 ANS ..9999 (includes a 4-position

[mwyc...@gmail.com]

Good day JPOS users,

I have some question in regard to ISO 8583 Version 1993;

In ISO8583 1993 specification, Field 39 (where you ‘find’ the external
value) is three positions.
Unlike the 1987 specification, where Field 39 is two positions.

What does the above statement mean in terms of version 1993?

How do we then code/implement this aspect in a JPOS based ISOSERVER?

regards,

On Sep 25, 7:41 pm, Mark Salter <marksal...@talktalk.net> wrote:

[chhil]

Field 39 in version 87 is 2 positions wide and in version 97 its 3 positions wide.

e.g. in ver 87 field 39 = 00 and in ver 97 field 39= 000

-chhil

[David Bergert]

MTI's differ a little as well:

 

in 87 version: a financial message is 0200

in 93 version : a financial message is 1200

 

Also:

 

in version 2003 STAN  DE 11 - is 12 bytes vs 6 bytes in 87 and 93

 

What does this means in jPOS ?  you just need to have the proper packagers setup and m.set() the proper values in the fields, if you are talking to multiple systems that use different variants/versions , you will need to be able to map the different codes/values.

 

--Dave Bergert

www.paymentsystemsblog.com

 

 

 

From: jpos-...@googlegroups.com [mailto:jpos-...@googlegroups.com] On Behalf Of chhil
Sent: Tuesday, September 30, 2008 8:18 AM
To: jpos-...@googlegroups.com
Subject: Re: JPOS and ISO 8583 Version 1993

 

Field 39 in version 87 is 2 positions wide and in version 97 its 3 positions wide.

[mwyc...@gmail.com]

Thanks so much Dave and Chhil,

I now get a clear picture of field 39 as used in version 1993.
So basically in JPOS all one needs to do is change the MTI to start
with 1 instead of 0
and then for field 39 set the value to 000 for successful responses
being sent.

You guys have saved me.

thanks&regards,

On Sep 30, 4:41 pm, "David Bergert" <dbergert...@gmail.com> wrote:
> MTI's differ a little as well:
>
> in 87 version: a financial message is 0200
>
> in 93 version : a financial message is 1200
>
> Also:
>
> in version 2003 STAN  DE 11 - is 12 bytes vs 6 bytes in 87 and 93
>
> What does this means in jPOS ?  you just need to have the proper packagers
> setup and m.set() the proper values in the fields, if you are talking to
> multiple systems that use different variants/versions , you will need to be
> able to map the different codes/values.
>
> --Dave Bergert
>
> www.paymentsystemsblog.com
>
> From: jpos-...@googlegroups.com [mailto:jpos-...@googlegroups.com] On
> Behalf Of chhil
> Sent: Tuesday, September 30, 2008 8:18 AM
> To: jpos-...@googlegroups.com
> Subject: Re: JPOS and ISO 8583 Version 1993
>
> Field 39 in version 87 is 2 positions wide and in version 97 its 3 positions
> wide.
>
> e.g. in ver 87 field 39 = 00 and in ver 97 field 39= 000
>
> -chhil
>

> On Tue, Sep 30, 2008 at 6:43 PM, mwycli...@gmail.com <mwycli...@gmail.com>

> > Mark- Hide quoted text -

[Mark Salter]

mwyc...@gmail.com wrote:
> Thanks so much Dave and Chhil,
>
> I now get a clear picture of field 39 as used in version 1993.
> So basically in JPOS all one needs to do is change the MTI to start
> with 1 instead of 0

The MTI would be set by the system generating the request - perhaps to
'1200', and is set by the system generating the response message to a
reply MTI on the response - perhaps 1210 in this 'perhaps' scenario.

> and then for field 39 set the value to 000 for successful responses
> being sent.

You also need to ensure your packager defines a field 39 which holds 3
digits.

Usually an authorised response will also hold an authorisation code in
field 38, but you specification will give the format there.

--
Mark

[Alejandro Revilla]

> The MTI would be set by the system generating the request - perhaps to
> '1200', and is set by the system generating the response message to a
> reply MTI on the response - perhaps 1210 in this 'perhaps' scenario.
> > and then for field 39 set the value to 000 for successful responses
> > being sent.
> You also need to ensure your packager defines a field 39 which holds 3
> digits.
>
> Usually an authorised response will also hold an authorisation code in
> field 38, but you specification will give the format there.
>

BTW, in jPOS we currently handle the MTI as protocol-version + MTI. We
need to stay backward compatible but I'm thinking about adding the
following methods to ISOMsg:

void setProtocolVersion (int i); // int? char? String?
void setMessageType (String s);
int getProtocolVersion ()
String getMessageType ();

Do you agree?

[Mark Salter]

Alejandro Revilla wrote:

> BTW, in jPOS we currently handle the MTI as protocol-version + MTI. We
> need to stay backward compatible but I'm thinking about adding the
> following methods to ISOMsg:
>
> void setProtocolVersion (int i); // int? char? String?
> void setMessageType (String s);
> int getProtocolVersion ()
> String getMessageType ();
>
> Do you agree?

I personally would want to place this processing down with the packager.
We might need a 'verb' (or multiple methods) to pass alongside the
ISOMsg into the packager so it knows the direction and intent?
This way the MTI handling is packager based, although this placement
might need work around the genericpackager handling.

--
Just my 2 currency decimal values.
Mark

[Alejandro Revilla]

>
> I personally would want to place this processing down with the packager.
> We might need a 'verb' (or multiple methods) to pass alongside the
> ISOMsg into the packager so it knows the direction and intent?
> This way the MTI handling is packager based, although this placement
> might need work around the genericpackager handling.
>

Can you give us a sample use case or high level pseudo code?

[Mark Salter]

My thought is that the look and feel of the ISOMsg is defined by the
packager, so perhaps this should include the structure and content of
the MTI field too?

So Packager would implement:-

public boolean isResponse(ISOMsg)
public boolean isRequest(ISOMsg)
public void setResponseMTI(ISOMsg)
public void setRetransmission(ISOMsg)

The ISOBasePackager (or an extension) would implement the current
processing in ISOMsg for these functions. This way MTI processing
changes would be isolated to the specific message format.

For backwards compatibility we would need call these methods from the
current ISOMsg methods, conditionally on an instanceof check for the
extension class?

Perhaps I am looking at the MTI in a different way to everyone else,
certainly the current MTI handling works well. My suggestion would need
a block of changes and careful consideration across the existing
packagers shipped with jpos, and might not be worth the hassle.

I am of course happy to take my suggestion further and start trying to
make the changes to see what happens and find the issues you may already
have considered?

--
Mark

[Alejandro Revilla]

Got it. I think that we can easily delegate those methods to the
packager and modify ISOBasePackager to operate in the same way we are
operating now.

I have a HUGE backlog and can't work on this immediately, but if you
want to give it a shot you're welcome to do so and I'll be happy to
actively review and test.

That said, I think that my initial suggestion (adding the
getProtocolVersion + getMessageType) is something we can still do at the
ISOMsg level. In addition we can have a getPackagerProtocolVersion at
the packager level, but the message's version will come out of the MTI's
first character, right?

[Mark Salter]

Alejandro Revilla wrote:
> Got it. I think that we can easily delegate those methods to the
> packager and modify ISOBasePackager to operate in the same way we are
> operating now.
>
> I have a HUGE backlog and can't work on this immediately, but if you
> want to give it a shot you're welcome to do so and I'll be happy to
> actively review and test.

Fine with me I will try and find some time too 8).

>
> That said, I think that my initial suggestion (adding the
> getProtocolVersion + getMessageType) is something we can still do at the
> ISOMsg level.

Fine with me of course.

> In addition we can have a getPackagerProtocolVersion at
> the packager level, but the message's version will come out of the MTI's
> first character, right?

I have never really mentally broken the MTI down, instead I just
remember the MTI values used for an interface that I am 'interested' in...

...rather than quote wikipedia, how about a link to a relevant page :-

http://tinyurl.com/ISO8583MTI

--
Mark

[Alejandro Revilla]

> I have never really mentally broken the MTI down, instead I just
> remember the MTI values used for an interface that I am 'interested' in...
>

Me too, but now that I'm working in an ISO-8583 v2003 system I hate to
see things like 2200s, 2800s and 2304s...

>
> ...rather than quote wikipedia, how about a link to a relevant page :-
>
> http://tinyurl.com/ISO8583MTI
>

Oh... I see your point, if we are to break it down, we may have to break
down all the positions...

[Mark Salter]

Alejandro Revilla wrote:
> Me too, but now that I'm working in an ISO-8583 v2003 system I hate to
> see things like 2200s, 2800s and 2304s...

They would just make my mind:-

a) 'jump', as I scanned and found a PAN instead of a familiar MTI.
b) consider a data corruption has occurred,
c) and finally settle down and accept the numbers often get bigger and
'better' over time.

8)

--
Mark

[mwyc...@gmail.com]

Thats alright Mark,

As per the interchange spec am working with, field 39 is of format N3
and as far as JPOS framework is concerned,
in the IsoPackager I have defined it as;

<isofield
id="39"
length="3"
name="Action code"
class="org.jpos.iso.IFA_NUMERIC"/>

In my case Field 38 is the Approval code and is of format ANP 6, I
have defined it in the isopackager as ;

<isofield
id="38"
length="6"
name="Approval code"
class="org.jpos.iso.IF_CHAR"/>

BTW, for formats like ANP 6, ANS 15, ANS..99, Z..37 etc
as you can see they have elements of P - Space(pad) characters, S-
Special characters, Z - Track 2 and 3 code set.

Why is that when defining the IsoPackager in JPOS, we use the Alpha-
numeric datatype
e.g. class="org.jpos.iso.IF_CHAR"/>
class="org.jpos.iso.IFA_LLLCHAR"/>
class="org.jpos.iso.IFA_LLCHAR"/>

Is it that JPOS looks at P, S and Z as normal Alphabetic characters?

regards,

On Oct 1, 1:16 pm, Mark Salter <marksal...@talktalk.net> wrote:

[Alejandro Revilla]

>
> Is it that JPOS looks at P, S and Z as normal Alphabetic characters?
>

Yes.

[mwyc...@gmail.com]

Alright, that clears my mind now, I have been wondering.
Thanks Alejandro.