I am glad you chimed in Lukas. Your company's app is actually the idea I am
trying to recommend here (I don't know if you remember us talking about it
earlier this year or not on the midrange chat).
Your company was able to retain their millions of i5 dollars (software,
business logic, salaries, hardware, etc) by implementing a solution that
didn't start out as black and white (i.e. "we need GUI, we better start
putting everything on the client"). Instead your team determined a pseudo
"browser" could be created on the client that would render screens based on
definitions sent down from the server. The best part about it is you
probably do very little .NET programming after the initial "shell" client
was created and now your RPG developers can simply define screens in your
format and run from there without having to involve .NET knowledge - very
I would be curious to know if you guys implemented any sort of debugging
infrastructure (i.e. ability to flip a switch and have all incoming/outgoing
communications for a particular session be logged for review by an RPG
You should see if one of the developers would be willing to write an article
on the approach as this is exactly what i5 shops should be looking at as
their pathway to getting GUI apps for their applications.
Thanks for posting!!
[mailto:midrange-l-bounces+albartell=gmail.com@xxxxxxxxxxxx] On Behalf Of
Sent: Monday, October 08, 2007 9:05 AM
To: Midrange Systems Technical Discussion
Subject: RE: .NET with System i5 - where to draw the line was->RE: No
givinguponSystem i (was: I'm about to give up)
I just wanted to jump into this thread, not replying to your specific post.
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
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 i5/OS