× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.



Hi Aaron,

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
developer.

Here's a full debug output: http://projectdream.org/~lb/DEBUG.TXT
Here's the screen which corresponds to it:
http://projectdream.org/~lb/debug.jpg

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 ;).

-----Original Message-----
From: midrange-l-bounces@xxxxxxxxxxxx
[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
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
nice.

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
programmer)?

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!!
Aaron Bartell
http://mowyourlawn.com



-----Original Message-----
From: midrange-l-bounces+albartell=gmail.com@xxxxxxxxxxxx
[mailto:midrange-l-bounces+albartell=gmail.com@xxxxxxxxxxxx] On Behalf
Of
Lukas Beeler
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
advertising)

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:

http://projectdream.org/~lb/diasnc.jpg

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.

http://projectdream.org/~lb/osp2007.jpg

Does this look like an AS/400 application? I don't think so. It's an
i5/OS
application.


As an Amazon Associate we earn from qualifying purchases.

This thread ...

Replies:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.