I just wanted to jump into this thread, not replying to your specific
Disclaimer: I'm not actually a developer, just a technician. This is my
knowledge and understanding of the whole exercise. This is not a
for-resale product, it's just an interna to our ERP application DIAS-iS
(which is only for the Swiss Market, so it shouldn't be considered
My company has been started development for a GUI-based thin-client for
i5/OS back in 2000. In 2001, the first production version was released.
Right now, we're at the third product generation, version 2.1 with a
release of the fourth one at the end of year.
We use native ILE RPG on the i5/OS side, with some CL and C (mostly for
TCP/Networking stuff). Communication is TCP-based, with our own
networking protocol called DUCP which tells the client what to draw and
how to draw it.
DUCP is text based, with simple lines that describe what the client
should draw. Clients are currently two available, one in Visual Basic (5
or 6 - not .NET), one in Java. Functionality is identical, but the VB
client has more integration function.
There is no real business logic on the client - the server can advise
the client to perform some value checking on fields (similar to 5250),
but this is rechecked on the server anyway.
See here for a live picture:
We have also implemented an interoperability protocol for custom
enhancements called DDXP - it's used to communicate for example with our
Point of Sale software, or our OSP Toolkit (Office Solution Pack), which
allows deep integration natively into Microsoft Office - the most
current version is OSP 2007.
Does this look like an AS/400 application? I don't think so. It's an
[mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of Walden H. Leverich
Sent: Monday, October 08, 2007 3:01 PM
To: Midrange Systems Technical Discussion
Subject: RE: .NET with System i5 - where to draw the line was->RE: No
givingup onSystem i (was: I'm about to give up)
Not to jump on your question to Richard, but in our case we treat the
System i like any other database when doing .NET front-ends. That is,
the flow and most business logic is built into the .Net classes.
However, like any other database, we've got stored-procedures on the
System i and when it makes sense to move some business logic into a
stored proc we do so happily.