× 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,

<snip>
If IBM were to develop a native GUI that displayed in a proprietary thick
client I think it would take off like wildfire. Note that all of the code
would still reside and run on the server so deployment wouldn't be an issue.
<snip>

Totally agree. The fact that the vast majority of RPG code written to
interact with the user is written to be used with the PC5250 emulator
suggests that IBM should be spending their time updating the thick client
interface and NOT try to get RPG programmers to convert their code to use in
a web server. I can guarantee that an updated emulator would have a much
much higher take-up than any of the current attempt to get RPG programs to
perform as a back-end to a web server.

<snip>
Close on the heals of that would be a browser component that would play the
same role (and in all actuality they would just be downloading IBM's thin
client similar to what we all do with Flash/Flex/JavaFX/etc).
<snip>

I work with RPG as back-end business software in web servers and as
webservices (using SOAP). Our code is strong and fast. We use apache/tomcat
as the front end in the DMZ and talk to the iSeries (which sits inside our
network) using sockets and passing xml both ways. This method requires an
absolute mimimum amount of server-side java code. A few classes and a java
dispatcher bean which handles xml is pretty-much all we need to allow our
JSPs to interact directly with our RPG code - we use AJAX to update sections
of our pages. The new xml-into opcode is a wonderful tool and has made our
RPG code look slicker than out java/jsp/javascript code (THANKS Barbara).
But, all of my experience tells me that I am in a minority in using RPG code
like this. Although I would love to see RPG as the web server back-end
language of choice I know that is just never ever going to happen. Unless
IBM improve the thick client interface more and more companies will move
away from the iSeries before the web side of things has taken hold. Why
shouldn't companies leave? I know all of the arguments for using the iSeries
but every time I see the look on a senior manager's face when they see the
green'n'black screen I know the days are numbered!

So, should we invest a whole lump of cash, time, and effort to further
integrate RPG into web server code while we watch our large businesses move
off the platform because the rich client is such an ugly duckling? For web
servers, I can already do what I need with the current toolset. Any further
attempts to pretty up the job is just IBM attempting to attract a market
that just isn't there. There's nothing stopping companies enabling their RPG
code to be used in a web server. Nothing except their own limited IT
managers/directors. Giving them a new IBM web goodie to pay a fortune for
will never get them over the line. We've lost them already. They have enough
effort trying to keep their senior managers away from the Micro$oft salesmen
and their flashy new toys. The only thing that will keep those companies
from dumping the iSeries for a toy computer is to give those
managers/directors a free supported flashy looking emulator. Senior managers
are happy, IT managers/directors are happy, IBM is happy, and the developers
are happy.

Sometimes I think the java option -Djava.awt.headless=true was invented
specifically for running java apps on the iSeries!

Cheers

Larry Ducie




As an Amazon Associate we earn from qualifying purchases.

This thread ...

Follow-Ups:

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.