As any longtime IBM i-focused pro knows: technologies, languages, frameworks, and strategies come and go, but core RPG holds stronga foundation forged from unflappable business logic. That is not to say that even the most modern RPG-developed applications won't face challenges or opportunities, but still, it's clear that in some organizations the RPG foundation isn't set to grow; and moreover, it might even have to survive a jackhammer or two chipping away at it.
This is where PHP can come to the rescue.
And isn't thatcome to the rescuea loaded phrase? You bet it is. It paints a picture that is entirely false for many companies who understand and value their RPG applications, and yet it's also true. Somewhere in between the extremes of green-screen love and rescue lies the real power of PHP.
PHP is a widely used, general purpose scripting language for web development. You can embed it in HTML, build dynamic, database-driven web pages, and create standalone graphical applications. It's relatively easy to learn and use. More than 22 million Internet domains deploy PHP, including Yahoo! and Facebook. The total PHP developer community is estimated at close to 5 million, and it includes a rich application ecosystem with thousands of free and open source PHP applications.
We've been covering PHP for about three yearsa little when Zend Technologies started offering its Zend Core for i5/OS in 2006, and a lot more as i-focused pros have caught on. (If you missed Jon Paris's "Attention RPG Programmers: PHP Spoken Here" (ID 62702), dig up your issue and read it ASAP.)
In the meantime, more than 12,000 IBM i customers in 150 different countries have downloaded Zend's PHP solutions for running PHP apps on IBM i.
While PHP can be useful to i-based organizations, there's a big leap between installing it to run the free help desk software solution Mantis/400, for example, and leveraging PHP as a strategic language on IBM i. Still, there's a growing sense that while PHP has a long way to goawareness is still remarkably low, it turns outwe very well may be on the cusp of the next (real) big thing to hit the IBM i programming world.
Before PHP can promise answers, what are the questions? Why is PHP so cool? Where does it fit? Will it replace RPG? (Was that a real question?) And what about the Big Blue trojan horse? There are so many questions; here are a few answers.
We should get this notion straight right awayPHP is not going to replace RPG. So where does it fit?
"It is a collaborative thing with RPG just as it is with Java. There's never been a valid reason to throw away good RPG codeor skills for that matter. RPG is still a terrific language for business," says Jon Paris, an RPG expert and former IBMer who provides mentoring and education consulting.
"But," he says, "it is unlikely that IBM will offer a direct RPG web interfaceor if they do it will not be in a meaningful timeframe. In fact, I really wish they would either give a definitive 'Yes' or 'No' to a native UI with direct RPG support. There are so many users deferring moving to PHP in the hope that IBM will expand RPG and 'save' them," he explains.
One of the early proponents of PHP is Mike Pavlak, who first put the promise of PHP to work while he was the director of information services for Trippe Manufacturing. Zend noticed his passion as a proponent for PHP and snapped him up. He's now a solutions consultant for Zend.
"If PHP replaces anything, it would replace DDS," Pavlak says. "Let's all have a going away party for DDS. SQL-DDL can replace DDS for physical files and logicals, PHP and HTML can replace DDS for the interactive processing. Oh, and for the half dozen or so of you out there who use DDS for reports, there is this thing called the 'print' button on the browser," he says.
As for RPG, PHP will complement, not replace, RPG. "There is way too much intellectual property languishing in billions of lines of RPG code to just throw it away," Pavlak says.
"I see customers doing all kinds of things, but the most prevalent is restructuring of applications to take advantage of PHP as a dynamic and graphical front end," Pavlak says.
"For example, one customer has taken PHP and written web service calls back to the green screen for a specific business process. The green-screen process was extremely stable, and they did not have to reinvent the wheel. I was just chatting with my sister who works for a company that is migrating folks from Oracle on VAX to Linux. She told me that she is having trouble getting representatives from the user community to test the applications and get the systems migrated. In this economy, with millions laid off, I am not surprised. So why put all those folks through the pain and suffering of a full-scale testing cycle when all you really need to do is test the UI? Don't change the business logic, just make it look better, contemporary, and relevant," he explains.
"OK, I hear you green-screen guys out there touting the wonders of the green screen. I love it, too. There's nothing I'd like better than to go back to dumb terminals, but the ship has sailed, and like Kodak film, it is time to get over it and get with the contemporary technologyuse the green screen where appropriate and use the browser everywhere else!" Pavlak says.
ibuildings, a company in the Netherlands that offers PHP services, training, application development, and professional services, has recently started investing in IBM i-focused knowledge and experts. The reason? The company is seeing increased demand for PHP in the IBM i world. But, for what, exactly?
"Currently, we see PHP on System i being used by early adopters and those that in some way were already familiar with PHP. I believe that PHP stands a good chance of becoming one of the major platforms for web-enabling System i applications," says Ivo Jansch, CTO of ibuildings.
"There are a number of factors that play a role in the rise of PHP on System i. First of all, there is an increasing demand to create web interfaces for traditional System i applications, and PHP is one of the most used languages for web development," Jansch explains.
"Second, PHP on System i comes with a set of tools that allow it to not only build a web front end, but to seamlessly integrate elements of the System i environment. PHP can directly manipulate job queues, talk to the DB2 database, run RPG programs, and even read and manipulate traditional green-screen applications directly from the code," he adds.
"The third, and perhaps most practical reason, is that PHP is easy to understand for System i developers. The difference between, say, Java and RPG/Cobol is huge, and RPG and Cobol programmers struggle with adopting a language like Java. PHP, on the other hand, is a lot closer to what they are used to. In PHP, you are not forced to program object oriented like Java, but you can start out procedurally and gradually learn the language. This means that the learning curve for PHP for System i developers is much less steep," Jansch says.
This last point is worth saying again: RPG programmers can build PHP code procedurally and slowly ease into object-oriented conceptsif, and when, they want to take advantage of OO strategies.
For Paris, PHP is all about achievability: "Many RPGers like myself will never get to grips with Java to the degree that is needed to build the next generation of applications, but they can deal with PHP," Paris says.
Most free and open-source solutions come with an interesting problem for enterprise users: the core software is usually free, but who's going to support it? What happens when a scattered open-source community releases new versions? Will something break?
The enterprise answers come from companies that build expertise and bundle the solutions for easy consumption. They make money not by selling the software, but by selling add-on services (installation, support, education, etc.). And such is the case with Zend.
Zend Core for i5/OS basically is a certified PHP distribution that includes PHP bundled with Zend Framework, Apache, MySQL, and i5/OS-specific resources with an automatic and configurable update mechanism. Designed specifically for IBM i, Zend Core for i5/OS includes an i5 toolkit to access DB2 and applications running on IBM i. As for support, the company offers a few different levels.
With or without support, it's hard to beat the low cost of entry into PHP programming on IBM i. And that, it turns out, is contributing to the rise of PHP.
"You do not need me to tell you the economic meltdown is occurring worldwide. There is no country, that I am aware of, that has not been impacted," Pavlak says. "The economy is driving CIOs to cut costs. With less immediate cash rolling around, open-source solutions end up looking really attractive."
In terms of IBM i, he says, "When you can minimize the risk of moving to a new solution by staying on the same hardware you have trusted for years, there is tremendous value."
Plus, the cost to develop PHP apps on IBM i is compelling.
"IBM is all about giving PHP away. I mean, you have to pay money nowper seatto develop solutions in RPG and Java using IBM tools, yet it costs the i5 customer nothing to develop solutions in PHP," Pavlak says.
For some RPG developers, there's little need to learn PHP. For others, it may be critical; though the idea is to leverage their existing skills (and salary) to continue delivering valuable business tools. Few RPG programmers would be interested in leaving their jobs to churn out cheap PHP code just because it's trendy.
However, there's a possible risk here, too. A CIO could start running a PHP-based application and hire low-cost PHP "experts" to keep it running or to add enhancements. Meanwhile, graybeards retire or get laid off.
There's also the flip side: IBM i-based companies that are looking for their next generation of RPG experts but aren't finding them.
"Despite IBM's best efforts, replacing those resources with entry-level RPG folks just isn't happening quick enough," Pavlak says. "But starting a PHP developer, fresh out of school, under the guidance of a veteran RPG/i5 developer can yield tremendous synergies as they both learn from each other. I truly believe this can be successful, but management must be firm and have patience because the RPG developer did not learn RPG overnight. And while PHP can be much easier to absorb than Java, it will still take time and effort," he explains.
Of course, it's important to note that while Zend is the key enabler of PHP in the IBM i world, the ecosystem is growing. The most prominent example of this is BCD's WebSmart PHP, which is a rapid application development tool that generates PHP code. It includes a variety of tools, templates, and wizards to make developing PHP applications easy and fast. The point? Obviously, previous BCD WebSmart ILE customers now have a transition product to add PHP applications, but others have options that can help them create PHP code quickly through tools conceived with RPG developers in mind.
It turns out, there really is a Big Blue trojan horse. As of February 5, IBM started preloading Zend Core as an installation image included with IBM i 5.4 and 6.1. This move covers several important angles. First, it signals that IBM truly sees Zend Core and PHP as valuable technologies for its IBM i customers. Action talks louder than words, right? Second, by offering Zend Core preloaded (customers have to install it themselves) IBM is breaking through a barrier of entry. The barrier wasn't costZend Core for i5/OS was free beforethe barrier was difficulty or perceived difficulty in getting an installation image onto a company's System i. Some customers ran into corporate hurdles that either stymied the download and installation or provided enough of a pain to stymie programmers who wanted to try it.
IBM and Zend are including one year of Zend's Silver support, which offers web-based support, hot fixes, and product updates. Zend Core will continue to be licensed and supported by Zend Technologies.
Odds are, this move will result in an appreciable boost of PHP action in the IBM i world.
But inevitable? We'll see.
Chris Maxcer is news editor for SystemiNetwork.com. "Jon Paris made a comment that didn't make it into the body of this report, but his point is a good one," Chris notes. Here's the comment: "So much depends on whether IBM unambiguously supports PHP, or not. If the message from IBM is simple, for example, 'Don't wait for us to update RPGuse PHP if you don't feel Java is for you,' then PHP could become very widespread."
On one hand, interpreted runtime environments like PHP and IBM's Net.Data offer a seductively convenient way to develop basic business-to-consumer and business-to-business web sites. On the other hand, scripting environments are much less effective for broadly-scoped database-maintenance and transaction-processing systems.
Conventional wisdom is that interpretive environments perform poorly in comparison to compiled environments. But are there any good benchmarks to quantify that? See:
Language Scorecard
One thing that impressed me about that web site was that they actually published the source code for the language comparisons. I was most interested in the CPU utilization comparisons between PHP and Java, and quite surprised to see that Java CPU utilization was so much less than PHP in basic string, numeric, and array processing (PHP required 30+ times more CPU in some tests). Then when you compare Java to C, you see a big performance advantage with C. Although RPG is not one of the languages in the scorecard, I've done some comparisons where RPG was 5-10 times faster than Java.
If PHP as a "language environment" has a a performance problem, then why isn't it noticed more at web sites? I think the answer to that is becasue PHP itself, and most of its extensions are written in C, which performs very well for string manipulation & concatenation (generating HTML dynamically). But what happens as developers move beyond embedding server-side script in HTML pages (typical of business-to-consumer web sites) and move on to broadly-scoped business systems development? Say you use an interpreted runtime environment to run an MVC framework (like Zend-Framework). MVC frameworks are arguably necessary, and certainly more common in broadly-scoped business systems development. Performance concerns expressed in PHP developer communities suggests that running that much code in an interpreted fashion is a real problem.
In addition to language speed, scalability may also be a concern. I want to investigate and address PHP scalability at a later date, but everything I've read so far seems to indicate that it relies on the common practice of placing load balancers in front of application server farms in front of database server farms. Though typical, that's not my idea of scalability. Page caching is not my idea of scalability, either - data in most database management systems is expected to be current.
There were many reasons for me choosing RPG for Web applications, but the main reason was that I thought it would be best for broadly-scoped business-systems development. CPU performance and memory footprint were weighted heavily on my scorecard. And as it turned out, ordinary folks notice the difference when they use my applications in comparison to alternatives like SugarCRM.
With all that said, I think there's a good chance that I will use PHP for something, at some point. Actually I have something in mind, but that can wait for another day.
Nathan M. Andelin
A colleague initiated a Web chat with me just yesterday to see if I could offer advise about calling an RPG program from PHP. I have no idea what motivated him to include an RPG interface in his PHP script. But it evidently offered some advantage. Some PHP developers interface with RPG via PCML. Others may evoke RPG programs as SQL stored procedures. Others interface with RPG programs via data queues. Others evoke RPG programs as Web services (WSDL & SOAP). I may not fully understand the rationale. But PHP won't replace RPG if enough PHP developers choose to include native IBM i interfaces in their scripts.
Then there are people who use RPG to generate HTML - and interface with browsers through the IBM i HTTP server. In the past 6 months I've deployed 95 new Web applications - using RPG w/ HTML templates. By the end of this year, that number will likely grow to 200. I'm currently working on a native IBM i based financial accounting system. After that, we may consider another similarly scoped package. Broadly scoped systems like this contain hundreds of database tables and programs. So PHP won't entirely replace RPG as long as developers like me are around.
Regarding your other question ( why PHP can't replace RPG), that's more difficult. And I don't know enough about PHP to answer it.
"Will PHP Replace RPG?
We should get this notion straight right away—PHP is not going to replace RPG. So where does it fit?"
I keep seeing comments like these when reading articles, but there never is a good point made as to why PHP won't/can't replace RPG. Our company started writing a new application, exclusively written in PHP, about 6 months ago and have not run into anything that we could do in RPG that can't be done in PHP.
One thing I want to make clear in all of the statements made above: At no time do I advocate throwing away an investment in technology like RPG, etc. But I do advocate focusing on the future in a smart way. Couple modern technologies like PHP and RPG to leverage your investment in IBM i. You can call/submit those RPG reports from a PHP web page on IBM i :-) This is attractive to many i5 shops looking to modernize interfaces yet still leverage their investments in RPG. I appreciate the chance to dialogue on these issues. Thanks for calling my ‘exaggeration’ (rhetoric) out, so I could elaborate.
Happy to speak to you and/or work in-person, whenever you’re ready to move those reports to a web browser. :-) Thanks again. Mike Pavlak Solutions Consultant Zend Technologies, Inc.