Today is as good a time as any to start.

In the previous two articles that I have written for this column, we took at look at what PHP is and does, and how to get started on the road to PHP expertise. Hopefully by now you've had a chance to start getting familiar with PHP syntax and how to create and test simple PHP scripts. And maybe you've even taken your first steps in object orientation by experimenting with creating and using PHP classes. If not, well, don't be too hard on yourself. Just think, today could be the first day of the rest of your life. Never too late to start, you know.

So what's next? Well, there's one very important thing that many times we leave until much later in the process. I think it's a good idea, however, to get working with this right off the bat—namely, interfacing your PHP scripts with your RPG programs.

We generally don't think about this first, only when we have a fancy old screen (page) ready in PHP and our RPG program to process the data entered on that page is set. Then we begin to freak out about how to tie these two together. Many people begin to hyperventilate dangerously at this point and a significant number pass out completely. But there's no need for that. Especially if you always carry a paper bag with you. Or you could make this less scary by getting used to it by practicing program calls between the two right off the bat, even if all your PHP page does is say "Hello World" and your RPG program just exists.

There are two directions to this, of course: calling an RPG program from PHP, and calling PHP from RPG. Let's start with the former, shall we?

Calling a PHP Script from an RPG Program

Suppose you have an RPG program. It gets data from DB2, plays around with it for a while, and then wants to display that data on a Web page you developed using a PHP script.

To do this, you need to use the PHP Command Line Interface tool (PHP CLI). This is an add-on to normal PHP, but most installations already have it, and if you're using Zend or MAMP/WAMP/LAMP (and I'm assuming you are), then it's there and ready to go.

To use PHP CLI, you need to use the Qshell tool. If you're unfamiliar with Qshell, the good news is you have plenty of company. Fortunately, you don't need to know too much to get CLI to work. Simply embed the PHP CLI command that accesses the PHP script in the QSH command that gets you into Qshell. For example, if you're using the Zend Server to provide your PHP instance and have a PHP script called script1.php that's sitting out in the IFS (which is where it should be), then the command you need to execute is this:

QSH CMD('/usr/local/Zend/Core/bin/php-cli/www/zendsvr/htdocs

                     /'folder x'/script1.php')

Here, 'folder x' is the name of the folder you have your PHP scripts in within htdocs. You don't need this folder, but it's a good way to separate your various scripts just in case you end up with a thousand of them. If you're not using Zend—say, you're using one of the XAMP versions—then the path to access php-cli will be different, but you get the idea.

There are actually two "calls" within the CMD: one to access PHP CLI and one to pick up your script.

If you're doing the call from a CL program, you can just use the QSH command statement above. If you're calling from within an RPG program, you'll need to embed the QSH command within a QCMDEXC command. Pretty simple either way. And you thought this was going to be hard.

Calling an RPG Program from a PHP Script

Now let's take a look at the converse. Or is it the inverse? Always got those two confused. I could take a moment now and research it so that I get it right, but let's face it: you don't know the difference between them either.

It's here that things get just a trifle more complex. And the reason for that is, how you do this will depend on exactly what version of the Zend Server you're on and how you got there. Now follow me here.

Traditionally, calling RPG from PHP was done by a set of Easycom-based functions originally developed by Aura, which were bundled together in something called the i5 Toolkit. This was incorporated into the Zend Server, so these functions became the default way to call RPG from PHP.

But, as often happens, things change, and recently Zend announced that they were no longer including the i5 Toolkit in the Zend Server and that they had replaced it with the new Zend PHP Toolkit. This is not based on the Easycom functions, so it's a bit different.

So which should you use? Well, that depends on what version of the Zend Server you're on. If you're on a version prior to 5.6 or are on 5.6 because you upgraded to it, then you still have access to the old i5 Toolkit. If however, you installed ZS 5.6 directly, you'll be using the new PHP Toolkit and you have to get the i5 Toolkit from Aura if you want to use it.

What's the difference between the two toolkits? In a nutshell, the i5 Toolkit is function-based—that is, it's procedural; it uses PHP functions to do its thing. The PHP Toolkit from Zend, however, is object-orientation-based and uses "methods" to do the magic. I know, I know; you're thinking, oh, man, I don't want to get messed up with no OO addicts. I better get the i5 Toolkit. But it's not that way, dude. You're just using these OO methods, not writing them. And be honest, isn't that a painless way to pull the BAND-AID off and get started in a small way with OO? But as I said, it's not as much a choice as it is dependent on what version of Zend Server you're on.

Using the i5 Toolkit

There are really four steps to calling an RPG program using the i5 Toolkit functions.

The first thing you have to do is establish a connection with the i. Remember, PHP is not native to the i, so they have to be formally connected for anything to happen. This is done with an i5_connect() function, which is part of the toolkit. There are three main parms that must be included (the others are optional): the server (either a DNS or IP address that identifies the i), the user ID, and the password for that user.

The next thing really has nothing to do with the i5 Toolkit, and that's to set up the array you're going use to pass the info that's going into your RPG program. Hopefully, by now you've had a chance to play with the array functionality in PHP so setting up this array will be second nature to you. When you set up this array, you have to specify, for each item in it, its name, whether it's input or output or input-output, the type of data it is (character, etc.), and the length.

Third, you need to "prepare" the program—that is, create a program object that can be used in the actual call. The prep step is accomplished by the i5_program_prepare() function. (There's something wrong with this Web site; when you click on this link, it gives you the screen for the i5_connect. To get to the prepare_program page, use the table of contents on the left side of the page, open up API Functions, then Program and Procedure Calls, and click on the i5_program_prepare link.)   This function includes three parms. The first is the name of the program you're preparing. The second is the array you just put together representing the data to be passed. The third is the variable you used to kick off the connect function. If you're familiar with PHP functions, you know what I'm talking about here; if not, then let me just say that the actual command for the connect step would be something like (! $connect = i5_connect( . . . ), so $connect would be used in parm 3 for the program prepare.

Fourth, you move values to the array created above. That is, in the second step you just created the array. Here you're moving the values to it that you want to pass to the program. You actually have to define the parms twice: once for input and once for output. Both will be used below.

And finally, you call the RPG program by using the i5_program_call() function. There are three parms with that function also: the variable carrying the program name, the array with the input parameters in it, and the array with the output parms in it.

And that's it. Pretty simple really. Oh, fine, I know what you're thinking, five steps, give me a break. But that's the way it is, and once you get used to it, you'll throw those five steps together like nothing flat. That is, assuming you're using the i5 Toolkit.

For more information and some great program examples, I strongly, strongly urge you to pick up a copy of The IBM i Programmers Guide to PHP by Kevin Schroeder and Jeff Olen from MC Press.

Using the Zend PHP Toolkit

But what if you aren't using the i5 Toolkit? What if you installed 5.6 directly instead of upgrading to it?

The difference between the two is that the PHP Toolkit is object-oriented in nature and uses methods. That sounds a bit more complicated, but there are actually fewer steps to using it, so that's a plus.

You start by instantiating the object, which sets up the connection. Then set up your parms array as above, call the program (no need to do the prepare step), and get your results from the array that's returned from the call.

All of the classes you need are pre-defined in the toolkit, so there's minimal work for you other than the steps above. And that's about it.

What? You wish I had gone into more detail on exactly how you would use this toolkit? Hmmm, I guess I wish I had too. What can we do about that? Hmmmm. Nope, can't think of anything. Oh, wait. I know. I could write my next column on that. Genius. As a great man once said: Sometimes I amaze even myself. Look for it in December, or maybe it's January. Can't remember.

Until then, get started with this. Start with the call from RPG (or CL) to PHP, and then move on to the converse/inverse. Remember, what's important here is not that you understand everything today, but that you start playing with things today. After all, you could get a nasty bump on the head if you passed out unexpectedly.