This is the fifth (and final) article in the PHP on i5/OS series. Previous articles in this series have looked at the structure of Zend Core in i5/OS, basic syntax of the PHP language, and the i5 Toolkit collection of APIs for accessing native i5/OS resources. This article will look at the extensions to the PHP language for accessing DB2 for i5/OS resources.

The DB2 extensions can be broken down into a number of categories as follows:

• Server/Connection
• Result
• Commit/Rollback
• Fetch
• Field Information
• Key Information
• Statement
• Errors
• Column/Procedure
• Table Information

This article will focus mainly on functions from the Server/Connection

I have read your articles about SQL stored procedures with great interest. A year ago I tried to use parameter markers in dynamic SQL stored procedures but couldn’t succeed. I ended up writing stored procedures in COBOL. Could you please provide an example of dynamic SQL stored procedures using parameter markers?

–Venkat

Parameter markers in SQL Persistent Stored Modules are very easy to implement. If you’re using embedded SQL in COBOL to prepare dynamic SQL statements, you’re probably already 99 percent there.

Below is an example of an SQL stored procedure that uses dynamic SQL to create a cursor and

In many shops, Sarbanes-Oxley and other regulations require iSeries, System i, and Power i administrators to audit their backup procedures and to keep records showing that regular backups are being administered and that their backups are working as advertised. To help with this effort, this week I’ll review a few common i5/OS commands and parameters that can make your backup auditing process easier to document.

Two Alternatives for Auditing Backups

When using an i5/OS or OS/400 SAVxxx command, it’s common to have the command produce a report detailing backup results by running the SAVxxx command like this:

SAVLIB