Yes, we have a full debug thing that shows the whole session with the
client. It's actually on the first screenshot (diasnc.jpg), titled
"Debug Fenster" (Fenster means Window).
Actually, the client application is developed by one our RPG developers
who also understands VB (and VB.NET, and more stuff), and a Windows-only
Here's a full debug output: http://projectdream.org/~lb/DEBUG.TXT
Here's the screen which corresponds to it:
I'll try asking our developers if they're willing to write an article,
but you'll probably have to wait for far less busier times (they have to
work much more than I do ;).
[mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of albartell
Sent: Monday, October 08, 2007 4:28 PM
To: 'Midrange Systems Technical Discussion'
Subject: RE: .NET with System i5 - where to draw the line was->RE:
NogivinguponSystem i (was: I'm about to give up)
I am glad you chimed in Lukas. Your company's app is actually the idea
trying to recommend here (I don't know if you remember us talking about
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
"browser" could be created on the client that would render screens based
definitions sent down from the server. The best part about it is you
probably do very little .NET programming after the initial "shell"
was created and now your RPG developers can simply define screens in
format and run from there without having to involve .NET knowledge -
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
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
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
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
Disclaimer: I'm not actually a developer, just a technician. This is my
knowledge and understanding of the whole exercise. This is not a
product, it's just an interna to our ERP application DIAS-iS (which is
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
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
protocol called DUCP which tells the client what to draw and how to draw
DUCP is text based, with simple lines that describe what the client
draw. Clients are currently two available, one in Visual Basic (5 or 6 -
.NET), one in Java. Functionality is identical, but the VB client has
There is no real business logic on the client - the server can advise
client to perform some value checking on fields (similar to 5250), but
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
version is OSP 2007.
Does this look like an AS/400 application? I don't think so. It's an