PHP and the i, Part 2

This entry is part 1 of 3 in the series PHP and the i

PHP and the i

In the last part we looked at why the IBM i (AS/400, System i, i) is not a dinosaur but instead a very powerful machine that can function as either a standalone mainframe or as a very cost effective and scalable server. Just remember what will happen if you don’t believe that; I will track you down and fight you in a bar. Forewarned is forearmed as Cacciaguida once said.

We also talked about what this has to do with you, a freaked out web programmer: many people in the i world do not have time to learn PHP (and HTML and CSS and JavaScript and jQuery, etc.) and so there’s a real opportunity for you to market your skills to an RPG-oriented IBM i shop that wants to do some PHP (and everyone wants to do something to overcome the fact that IBM has failed to provide the i with a native GUI interface other than Java).

In this somewhat risqué episode, we’ll look at just what you need to be able to do development work on the i. Many people in the i world will that PHP is native to the i, but I don’t think that’s really true. To me, native means that it just runs, no problems or questions asked, nothing special needs to be done, it just sort of happens like when you see someone across a crowded room and know she/he is “the one”. That’s not the way it works with PHP and the i.

IBM and Zend

RPG is a native language on the i, but PHP has been added and with the appropriate bridges you can run PHP just as easily (more or less) as RPG. The tool for RPG is the RPG compiler, supplied by IBM (as a chargeable item of course). The bridge that lets PHP run on the i is the Zend package (server/studio/framework) provide by Zend.

Yes, those are the people who more or less have become the corporate face of PHP, and they’ve struck an uncommonly close relationship with IBM. They go on vacation with Tom Watson, and otherwise worship at the IBM shrine in Armonk. In return, IBM has given them the PHP keys to the i. Zend is pretty much the exclusive vendor if you want to use PHP on the i. I say pretty much because Aura also has a PHP stack that you can purchase, but there is very little doubt that the Zend implementation is the cat’s meow, the bee’s knees, and all that jazz. The thing that makes the Zend implementation superior is not the PHP stuff, but rather the extra things that they have written that help PHP interface more smoothly and more natively with the i. Things like an asynchronous i interface that allows you to create PHP programs that will run not just online as they would on the web, but also in batch mode as they might need to run in a true mainframe.

The bottom line is this: if you want to do PHP, significant PHP, on the i, you need to be using the Zend package on the i. And that means when you approach an i shop, that they need to have the Zend package installed on their machine. The fact is that there is not a reasonable alternative to Zend on the i.

Some shops may already have Zend installed, but most may not. And they may tell you that they don’t have budget approval to purchase additional software (and so they may want you to just be able to do it from the web, which is not possible so forget that). Fortunately, Zend has an agreement with IBM for all i users under maintenance (which would be almost all i users and you don’t want to get mixed up with anyone who is not on maintenance), to be able to get free versions of the Zend product.

The Zend product itself consists of three components. The first is Zend Server, which provides the stack required to run PHP on the i (the PHP language, an instance of the Apache server, and the SQL database). Zend Server also includes any of the additional modules written to make life with the i simpler. The agreement provides a version of the Zend Server, specifically the Zend Server Community Edition, that can be downloaded onto the i for free. This is not the premium version, of course, but most of the things missing from it are associated with deploying large scale PHP applications and are not required until you have grown your PHP application to the point an enterprise-oriented version is required. By that time the shop is hooked and having to buy a version, it would already have a solid ROI attached to it.

The second component is Zend Studio. This is something that would run not on the i per se, but on the PCs attached to it. It’s basically the IDE that you develop your PHP scripts on instead of a text editor. It consists of a text editor, of course, but also incorporates a debugger and testing software.

The community edition of Zend Server is something that is available on any platform that uses Zend to provide it’s stack, but the version of Zend Studio is specific to the i, and so is the arrangement that Zend has with IBM. You can download Zend Studio for free as an i user, but the caveat is that once you download it, you can’ download any updates or new versions. You are stuck on that version until you decide to pay for a new version.

The third component is the Zend Framework, which provides the kind of things that any other framework does. This can also be downloaded with Zend Studio.

Developing on the i

One question that you may have is where to put the scripts that you develop. If you are dealing with RPG programs, they go in special files, like QRPGLESRC, QCLSRC, etc. depending on what type of program you are developing. These are kept within the data base for the i itself. But PHP scripts are kept somewhere else.

In every i there is something called the IFS. Many i people don’t know too much about it, but it is basically a windows oriented area where you can set up folders (the i uses libraries, not folders) and store documents. This is where your PHP scripts will be stored; in /htdocs/*.

There is one other thing that we should talk about; namely the fact that you will be developing not just a PHP/JavaScript/CSS web application, but an RPG application. That is, like I said in the previous article, RPG is not a dead language. It is actually a very superior language in which to write business applications. It does a great job of handling business logic and has a built in database language simpler than SQL (although you can use SQL with RPG). The old knock against RPG was that it was positional in nature and thereby weird (the latest versions of RPG eliminates this and provides a more English-like language syntax.) To make sense, any application would have to be a combination of RPG and PHP, with modules of each type.

It makes sense to do the C and M part of MVC in RPG and the V in PHP. Why am I saying this? I am at heart a mainframe programmer (Cobol first because it was the language that God used to create the world and RPG second because everything that has happened since 1810 has been done in RPG).

RPG people are used to creating a single RPG program that combines all three into one simple monolithic mess that was almost guaranteed to be unmaintainable once the original programmer had moved on. As a result, the first thing you’ll have to do is get the i people to start with an MVC type design. This was something that was very difficult in an RPG environment until about a decade ago, but now with ILE and RPG/Free, it’s something that can be done.

Conclusion

And that’s about it. At least to begin with. The last of our series is just around the corner, and we’ll talk about what goes into developing good business screens. In the meantime, good luck!

Image via Fotolia

PHP and the i

Free book: Jump Start HTML5 Basics

Grab a free copy of one our latest ebooks! Packed with hints and tips on HTML5's most powerful new features.

  • Ok

    Nice one David! Describing the i as you do is hitting the nail on the head (or putting the dot on the i)
    Rene Simons
    30+ years experience on s/38 ……..System i
    Netherlands

    • david shirey

      Thanks, dude. Take care.