My reference to two languages more had to do with introducing a new language
where the existing could already facilitate. In the case of SQL (embedded)
and CL, I use them both where they make sense. That is where everything
gets real relative, because that median area is different for everyone. But
both embedded SQL and CL capitalize on the existing infrastructure of the
IBM i in a very full manner.

OK - I'll play devil's advocate here.

I knew those were real horns! ;-)

I agree with the fact that with any language you use, you will have to learn
the client side markup/script language. The server side is more of what I
am concerned about. So let's take it to the next level. Let's say RoR has
some really good scaffolding capabilities that allow you to spec out new
applications in short order (basically the concept is you only override what
you don't like about the default app). But RoR doesn't has native
integration into IBM i so you pick PHP for your controller layer to handle
traffic to/from the IBM i, and PHP then uses the i5toolkit to communicate
with the business logic written in RPG. In theory we just built something
that takes the strengths of three different languages and leverages them
beautifully, but in reality that infrastructure also has triple the failure
points, triple the knowledge required to find errors, triple training that
you need to send your developers to, etc, etc. With PHP and RPG you only
have double of the aforementioned list. With just RPG you have a single
level of the aforementioned.

In the end, each company just needs to be fully informed as to what the big
picture (i.e. 15 years out) will look like if they formally adopt another
language into the fold. That is where I would debate that it would be less
expensive, in the long run, to just do it all in RPG. Take things like
Valence and Profound UI and IceBreak. Any of those frameworks would be far
easier to get an existing RPG shop to the web, in grand scale, than to try
and adopt PHP+RPG (this is purely my opinion).

I think the various forms of RPG+CGI have been slow to mature in the open
space (i.e. community support) compared to others, but I do think there is
adequate support out there at this point (i.e. CGIDEV2 forums,
midrange.comforums, Renaissance forum, Valence forums, RPG forums)

Don't get me wrong, there will be challenges with RPG+CGI, but there will be
less of a environment change, and because of that I think the chance of long
term viability is much greater because we already know what we like and
don't like about the RPG+DB2+IBMi environment - PHP is a fairly big and
unknown world that is still a teenager in enterprise compared to IBM (the
50yr old).

What have you to say to that o' advocate of the devil! ;-)

Aaron Bartell
http://mowyourlawn.com
http://mowyourlawn.com/blog/


On Mon, Apr 19, 2010 at 12:30 PM, Jon Paris <jon.paris@xxxxxxxxxxxxxx>wrote:

So we take it that you're abandoning CL and SQL Aaron <grin>

OK - I'll play devil's advocate here.

We all use multiple languages on the IBM i all day every day. You have
to learn both Javascript and HTML in order to be able to produce web
applications. To use RPG for the web you also have to learn one set of
APIs or another. Given that whatever choice you make, you will not
find an awful lot of help out on the web, are you not as well or
better off choosing PHP where at least there's a wide range of help
and tutorials and ... available?

Open Access and the resulting RPG options may change the game - but
right now I'll use my RPG code on the back end and use PHP to drive
the UI.


Jon Paris

www.Partner400.com
www.SystemiDeveloper.com




As an Amazon Associate we earn from qualifying purchases.

This thread ...

Follow-Ups:
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.