In last month's article, I showed you how to install and configure the unixODBC manager as well as the iSeries ODBC driver so that your Linux machine could access the database on your iSeries. This month, we'll take advantage of this connectivity to use our iSeries as a database repository for the open-source project WebCalendar.

Replace Domino?

WebCalendar is an excellent example of the high-quality software being generated in the open-source community. As you may have guessed, WebCalendar is a Web-based calendar system that offers features similar to Lotus Domino's user calendar. It utilizes the PHP Web-scripting language and can use as its back-end any ODBC-compliant database, such as the open-source PostgreSQL and MySQL databases included in most Linux distributions. Assuming that your Linux machine has the appropriate software installed, the installation of WebCalendar is as simple as downloading the tar ball from the WebCalendar site (which, at the time of this writing, is WebCalendar-0.9.39.tar.gz), installing it into the Web server's document root directory, creating the database, and changing the "config.php" file to configure it for your database of choice. If you are comfortable working with your Linux machine, the installation can be accomplished in under 10 minutes.

When I installed WebCalendar on a newly-configured Red Hat 7.3 computer, I found that almost all of the requisite software had been installed, presumably because I had checked the "Web Server" and "Database Server" options during the Red Hat installation. There were only two things missing: 1) the iSeries ODBC drivers, the installation and configuration of which I discussed last month and 2) the ODBC module for PHP. Because PHP had been updated since my 7.3 installation, I downloaded all of the newest PHP RPMs from Red Hat's update site (look for the files called php*7.1.3*) and installed them using the Red Hat Package Manager program rpm.

To evaluate this package, I used my locally installed PostgreSQL for the back-end database and configured everything per the instructions in the INSTALL.html file included in the tar ball. The instructions (INSTALL.html) were accurate, and within minutes I was able to sign on to the administrator account by pointing my browser to my own PC at the URL http://localhost/WebCalendar/login.php.

This program has almost everything you could want in an office calendar system. It can have any number of users, and it has the capability to group users and to overlay users' calendars on top of each other. It supports the concept of "accepting" entries generated by one user into another's calendar, which makes it easy to schedule meetings. It even offers a public calendar. And these are just a few of the attributes of this software; you can "read all about it" on SourceForge's WebCalendar site.

A More Perfect Union

Before you unleash this program onto your users, you have to consider how to properly back up the database utilized by WebCalendar. If the Linux machine hosting WebCalendar happens to be hosted itself on an iSeries machine, then your backup solution is obvious and straightforward. In fact, that's one of the perquisites of Linux on the iSeries. But for those who will run WebCalendar on a separate Intel box, the backup solution is more convoluted.

One option is to use the backup tools provided with the open-source database to create a file on the Linux box that can be copied to the iSeries. For example, the PostgreSQL database (my preferred open-source DB) has the pg_dump command, making it easy to copy the schema definition and data to a text file that can then be shipped anywhere. I use this technique to back up databases on my co-located servers, with the system automatically emailing the backup file to me on a daily basis.

For this project, the obvious solution (to me, anyway) was to take advantage of the Linux/iSeries connectivity and use my iSeries to host the database used by WebCalendar. Since documentation provided with the project indicates that WebCalendar was written to use an ODBC driver (thus making it database agnostic), it was a logical conclusion.

Make It So

Once I decided to pursue the iSeries as my database server, the first order of business was to create a WebCalendar user profile and library on the iSeries into which the database would go. To that end, I created an iSeries user named WEBCAL, with the password WEBCALPW, and I signed on as that user. Next, I started the interactive SQL program (STRSQL) and issued a CREATE SCHEMA WEBCAL command. You could accomplish the same thing via the iSeries Operations Navigator, but I'm still a command-line kind of guy, so I chose to do it that way.

Once the library (schema) was created, I created a source physical file (WEBCAL/SOURCE, RCDLEN(112)) into which I later FTPed the file tables-db2.sql (located in the WebCalendar root directory), using the following commands:

ftp hunt400(you'd use your own iSeries name here)
(log in using WEBCAL user ID and password)

Then, from the iSeries side and WEBCAL user profile, I issued the RUNSQLSTM command against the newly created source file member tables_db2 to generate the files. This is where I ran into the first problem. It seems as though that file isn't complete, since it creates only six or so of the 16 tables actually used by WebCalendar. So I got numerous errors when I went to my Web site that was now relying on the iSeries database. Undaunted, I looked over the other "*.sql" files and selected the tables-postgresql.sql file. I created a copy of this file and named it tables-db2.sql, thus overwriting the original. Next, I uploaded the new-and-improved tables-db2.sql to the iSeries using the commands noted earlier. Back on the iSeries, I deleted the tables created earlier, then reran the RUNSQLSTM command on the iSeries side. No joy that time either! The most notable problem among those presented by the SQL differences between PostgreSQL and DB2 is shown in Figure 1.

Figure 1: This statement won't work under DB2.

Specifically, the line shown below caused the problem:

This line indicates that we want to create an integer field with a string default. PostgreSQL, and other databases, will automatically CAST a string, such as '1', into a numeric datatype. So for PostgreSQL, this is acceptable. DB2, on the other hand, takes a dim view of this tactic and refuses to create the table. I agree that it's somewhat sloppy; I'm a fan of strong column typing in a DBMS. I believe that it should be the responsibility of the programmer to make the CAST when writing to the database so that no assumptions are made.

My solution, then, was to edit tables-db2.sql and change all of the '0' and '1' instances to 0 and 1, respectively. After I made a couple of iterations of edit, FTP, and RUNSQLSM (to fix some of the other minor syntax differences), I was able to successfully create the database on the iSeries.

Let's Talk

Once the database was set up, the next step was to configure an ODBC data source name to point to the new database. I'm not going to rehash the instructions on unixODBC or the iSeries driver, since all of that was covered last month. Instead, I'll refer you to that installment and to Figure 2, which shows the settings I used to create the system data source name.

Figure 2: These are the settings I used to configure a system DSN to my WebCalendar database on the iSeries.

Once the DSN was available, the next step was to modify the configuration file includes/config.php, located within the WebCalendar root directory. The required changes were simple. First, I needed to lose WebCalendar's affinity for MySQL. To do that, I simply commented out the lines under the "// MySQL example" heading by prepending two slashes (//) to each of those lines. Then, I configured the ODBC connection by uncommenting the lines under the "// ODBC example" heading, changing the values to the DSN we just created. In my case, the salient lines are shown in Figure 3.

Figure 3: These statements show the configuration for an ODBC connection.

Testing...Testing...

Once the connection was up and running, I tested the database by pointing my browser to http://localhost/WebCalendar/login.php. In a brief moment, I was looking at a pile of errors that were unrelated to the ODBC connection (which worked flawlessly). Instead, I was getting SQL errors because the fields that I so cavalierly accepted as really being integers are used in SQL statements as though they are strings. Yikes! These errors prompted me to go back to my original tables-db2 file. This time, I changed the pesky INT DEFAULT 'some digit' to read CHAR(7) DEFAULT 'some digit'. Then, I went through yet one more FTP, delete, and RUNSQLSTM cycle.

Back on the browser, I reloaded the login.php page and...success! I was able to log on as the administrator, set the system defaults, and create a user for myself. Needless to say, I was quite pleased with myself. I dropped a note to the developer of WebCalendar, sending the updated tables-db2.sql file to him. A subsequent note from him indicates that it's now in Concurrent Versioning System (CVS) and available to all from there.

Don't Break Out the Champagne Yet

I had hoped to write the conclusion, "And everyone lived happily ever after," but that's not going to happen. Following a thorough test of the system, I found some additional rough edges, this time caused by character fields in the database being referred to as integers by the SQL statements. Oh, well. Most of the software works fine against the iSeries; in the meantime, I'm going to continue to work with the developer on this latest problem. Once the solution is in hand (which most likely will entail more consistent usage of data types within the PHP scripts), it will be merged back into the developer's CVS.

Such is how it (occasionally) goes in the open-source world. It's almost to be expected, since the version number of WebCalendar hasn't reached the 1-oh stage yet.
To be clear, the problems I had with WebCalendar are a result of using it with the iSeries database (which has strict type-checking). The program works fine when coupled to open-source databases (which are more permissive). In fact, WebCalendar has recently made the Top 10 download list on SourceForge, so it must be working for someone. You really should check out WebCalendar and see if it can be of use in your shop.

That's it for this installment of The Linux Letter. If you have any topics that you would like me to address, feel free to write to me at This email address is being protected from spambots. You need JavaScript enabled to view it.. See you next month!

Barry L. Kline is a consultant and has been developing software on various DEC and IBM midrange platforms for over 20 years. Barry discovered Linux back in the days when it was necessary to download diskette images and source code from the Internet. Since then, he has installed Linux on hundreds of machines, where it functions as servers and workstations in iSeries and Windows networks. He recently co-authored the book Understanding Linux Web Hosting with Don Denoncourt. Barry can be reached at This email address is being protected from spambots. You need JavaScript enabled to view it..