Re: Why use PHP? What are the disadvantages?

We may agree more than we disagree. I was saying the advantages or disadvantages of using PHP depend on the circumstances to which it is applied. We might agree on that point.

I don't know if your experiences with .NET would translate to PHP. Our ecommerce team uses .NET and, when they want to access the IBM i, they use a third-party product to facilitate access. They do okay in terms of performance. But they are limited in what they can do. I think PHP may end up being a better solution than .NET (if it's not already better) because IBM is working to make PHP a native IBM i technology. Still, you have more experience here than I do, so maybe I would share your views if I shared your experiences.

I don't work for Zend, and I don't get anything from Zend for saying this: if I were going to use PHP as the core of an IBM i modernization strategy, I would definitely be looking at maximizing use of Zend products and services. I apologize if that sounds like a commercial. My intention is to emphasize that I wouldn't rely on the cheapest version of Zend server and my own ingenuity to build an IBM i modernization strategy with PHP. I would take full advantage of the most advanced tools available, and I would get as much experienced, expert help as possible.

Kelly Cookson
Senior Programmer/Analyst
Dot Foods, Inc.
217-773-4486 x12676
www.dotfoods.com


-----Original Message-----
From: web400-bounces@xxxxxxxxxxxx [mailto:web400-bounces@xxxxxxxxxxxx] On Behalf Of Aaron Bartell
Sent: Monday, April 19, 2010 11:18 AM
To: Web Enabling the AS400 / iSeries
Subject: Re: [WEB400] Why use PHP? What are the disadvantages?

Good analogy Kelly,

Many people eat apples and oranges. They don't see them as an either-or

choice.

Here is where I believe we disagree. I think that a two language scenario
introduces enough bad things that it would almost be better to go with all
one language or the other.

For example (and this is only an example), let's say you went with PHP front
end with RPG back end. You started using the PHP i5 toolkit and then
realized it was built in similar fashion to PCML which means you can't call
many of your existing RPG programs directly because they don't always adhere
to the restrictions of PCML (i.e. max of 7 parms, no date/timestamp support,
return parm can only be an integer). Then you decide to go with SQL stored
procedures because they are fairly tightly integrated. Now you start
developing an application with a couple hundred screens and a couple
thousand DB interactions (i.e. you call RPG through the SQL stored proc
approach). Now you have to not only maintain and deploy the PHP app, which
is running in PASE or Windows, but also the SQL stored procs and also the
RPG. Now make an average sized deployment of a new feature (let's say 10
screens, 20 SQL stored procs, and 10 RPG programs), now lets say something
went wrong and you need to pull out the changes (not uncommon in a complex
environment). Now you have to know how to pull out those changes in all of
those layers - this can get dirty fast! No this isn't as much of an issue
for a small foot print PHP app, but I am not talking about those, I am
instead talking about what most likely will happen once PHP+SQL+RPG is
settled on for a longterm infrastructure. Part of this is having the right
tools for the job (i.e. Aldon, MKS, etc), but at the time Aldon couldn't
really handle SQL Stored Procs (maybe it is better now).

I lived through this scenario at a previous employer except it was .NET
instead of PHP. The DB layer for .NET to talk with RPG has grown to many
thousands of SQL stored procs. Deploying changes takes a team vs. back in
the day it took one person - and if a change was made in error it could be
VERY easily be backed out. And even then, backouts were less frequent
because to test the change it was a simple as changing the library list to
have the changed program come before the existing production program. We
take a lot of these things for granted when we see the glitz of PHP. Don't
get me wrong, PHP has WAAAAAY more focus on web programming than RPG - but
that doesn't create a solid business app dev scenario in my book (anymore).

In the end these are opinions based on my experiences and I am sure others
have probably done better than I, but it is a real world experience that
people should take into account as they are "modernizing" by switching to
xyz language and away from RPG.

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


On Mon, Apr 19, 2010 at 10:42 AM, Kelly Cookson <KCookson@xxxxxxxxxxxx>wrote:

Comparing PHP with RPG to me is a like comparing apples and oranges.

You can do it.

Apples and oranges are both fruits, both roundish, and both about the same
size. PHP and RPG are both programming languages, both contain a full
complement of logic and data structures (loops, conditionals, arrays,
variables, etc.), and both can access IBM i resources.

Apples are a little less messy, are better if you want to bake a pie, and
contains less citric acid to upset your stomach. RPG is a better at batch
processing large amounts of data because that's what it was designed to do.
RPG is better integrated into the IBM i because it was created as a
proprietary language specifically for the IBM i.

But oranges have their advantages, too. PHP was created as a web
development language and blows the socks off RPG in that regard. PHP comes
with a lot more delivered functionality than RPG, which can make some tasks
(e.g., complex string processing) easier. PHP is a cross-platform language.
PHP scripts that run on the IBM i also run on Windows and Linux machines.

Many people eat apples and oranges. They don't see them as an either-or
choice.

Kelly Cookson
Senior Programmer/Analyst
Dot Foods, Inc.
217-773-4486 x12676
www.dotfoods.com

-----Original Message-----
From: web400-bounces@xxxxxxxxxxxx [mailto:web400-bounces@xxxxxxxxxxxx] On
Behalf Of Aaron Bartell
Sent: Monday, April 19, 2010 9:47 AM
To: Web Enabling the AS400 / iSeries
Subject: Re: [WEB400] Why use PHP? What are the disadvantages?

I like PHP, but here are the things I believe are detractors (since that is
what you were looking for):

- If RPG is the primary language in your shop then adding PHP is adding
complexity. I am not saying it can't be done (many have done it
successfully), I am just saying there is much more complexity and now you
need to keep up with the half-life of information in the PHP space (much
more time consuming than doing the same for RPG which doesn't change nearly
as much - a good and bad thing)

- PHP for the most part is only a web language. For example, it isn't
something you would call for nightly batch processing. RPG on the other
hand can be used for many scenarios and it feel more natural - this makes a
difference to me.

- PHP runs on the IBM i, which is good, but it doesn't run "in" the IBM i.
What I mean by that is it doesn't, as far as I can tell, utilize all of the
things we have become comfortable with in doing debugging and what not
(i.e.
if there is an error for a user you check their job and their spool files -
with PHP you no longer have the job log and spool file thing). PHP does
have some very cool logging features, so I am not saying it is bad - it
just
doesn't approach it the same as RPG+CGI does, which means you need to
reeducate yourself on how to trouble shoot. Note that reeducation also
needs to happen to some extent when dealing with Apache in the RPG+CGI
scenario.

Just some thoughts.
Aaron Bartell
http://mowyourlawn.com
http://mowyourlawn.com/blog/


On Mon, Apr 19, 2010 at 8:32 AM, Tom Deskevich <
thomas.l.deskevich@xxxxxxxxxxxxx> wrote:

I asked a former co-worker this last year. He could not come up with
any.

I would like to compile a list, based on my own experience.

1. The ZEND subsystem sometimes does not come up properly when we
IPL.
I do not have the security to diagnose or change the startup procedure.
So fixing this becomes difficult for me.
But the fact that it usually comes up fine tells me that it is most
likely setup right.

2. Does not seem to be as much help out there on the internet for
the DB2 and I5 commands.
I am trying to sell PHP to the brass, so to speak. I wanted to show them
running a simple program how you can re-use code that is written in RPG
for the 5250 application, VB.NET application and PHP application. I got
the 5250 application done in a few hours. After having a co-worker work
up an example, I can call a stored procedure from the VB.NET
application. Again, just took a few hours. I have been trying to call a
stored procedure from a PHP application for WEEKS. And it is STILL not
working. If I show this to the brass, what if they ask me how long it
took? I don't expect people to program for me. I did puchase and read
The IBM i Programmer's Guide to PHP. I understand that this book cannot
have extensive examples of everything you can do with PHP on the I. And
it did help, but again only took me so for. I thought I could get an
application going without having formal training, but maybe that is what
I need.

3. HTML and Java Script for the interface. This seems to be rarely
mentioned when people are singing the praises of PHP. I tried a number
of tools to create this for me. But
You pay the price of extra overhead and code when you run the
application. It seems better to go with straight HTML and java script. I
have to admit, there is a ton of help out there. But the syntax of this
stuff if really fun, to say the least.

So as I saw somewhere once, try something new, and fail, at least you
are doing SOMETHING. But I just wonder if my efforts may be better spent
on other things.
Especially since I am the only person here who is remotely interested in
PHP. I mentioned earlier about formal training. But how can I sell that?

Thanks for taking the time to read this.

And thank all of you for your help and guidance.


Tom Deskevich

--
This is the Web Enabling the AS400 / iSeries (WEB400) mailing list
To post a message email: WEB400@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/web400
or email: WEB400-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/web400.

--
This is the Web Enabling the AS400 / iSeries (WEB400) mailing list
To post a message email: WEB400@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/web400
or email: WEB400-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/web400.

--
This is the Web Enabling the AS400 / iSeries (WEB400) mailing list
To post a message email: WEB400@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/web400
or email: WEB400-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/web400.