Who? Me? Argue? Nahhh.

It may surprise you, but I've been embroiled in a few mailing list debates over the past several months. In some of these, I have opined that there is no single answer for all programming questions. I've argued that SQL has its place, but that RLA performs better. I've argued that Java is the best language for creating user interfaces, but that RPG is by far the better language for business logic. I've argued that procedural languages have their place, and that--heresy!--object-oriented programming isn't the universal panacea.

My point is that each business problem is unique, and you should identify the business problem and its parameters before deciding on things like languages and architectures. As Maslow makes clear in his famous phrase, if you start out with a solution in mind, the problem tends to get skewed toward that solution.

In servlet programming such as the kind done with WebSphere, there are two schools of thought: JDBC and everything else. JDBC proponents argue that JDBC is "platform independent" and so makes it easy to move your applications off of the machine. Detractors point out that JDBC ties your clients to your database design (and vice versa!) and also suffers from some serious performance problems. Each approach has its place in an implementation, but you must have all your options available in order to make an informed decision.

In its current incarnation, IBM's Java Toolbox allows you to do just that. The Toolbox is, in my opinion, one of the most significant pieces of iSeries software ever written. Not only that, the package is free. Not only that, but the version I'm talking about today--the JTOpen version of the toolbox--is open source!

An Introduction

When the IBM Toolbox was first made available way back in 1998 or so, it was an eye-opening experience. IBM had evidently decided to become very serious about making Java interoperable with legacy AS/400 systems. Subsequent announcements, from the availability of Linux to the pumping up of QShell to the most recent ability to call Java directly from RPG have all reinforced that idea.

The Toolbox has capabilities I wouldn't have imagined possible. By hooking directly into the host servers originally used by Client Access, the Toolbox makes available direct access to nearly every aspect of OS/400--from database to data queues. You can call a program, execute a command, or create a spooled file, all using native Java classes. Best of all, the Toolbox is 100% Pure Java, which means any code you write will run just as well on a PC as on the iSeries--or on a Linux box, a Sun Blade, or a Mac!

The Toolbox includes classes supporting the following OS/400 functions:

• File access, including JDBC, record-level access, and data conversion
• Integrated File System (IFS) access
• Program calls (including PCML) and command calls
• Printers, spooled files, and output queues
• Users, groups, jobs, and job logs
• Messages, message queues, and message files
• User spaces, data areas, data queues, system values, and system status

These classes can be used in programs on any platform, including the iSeries. Another series of classes provides GUI access to various resources on the AS/400, from spooled files to system values. However, these require the Swing classes, and since these are not implemented on the iSeries, these classes not readily available to native OS/400 programs. This column focuses exclusively on the classes that can be used within the WebSphere environment, but as you can see from the list above, that's still a substantial number of resources.

For more information on the LPP version of the Toolbox, you can go to the V5R1 Java Toolbox home page.

JTOpen: The Icing on the Cake

The licensed version of the Toolbox would be enough in and of itself to cause a lot of excitement. It's an incredibly robust and powerful set of packages, and there are major new features being added in every release. Be sure to review the major announcements regarding the LPP version of the Toolbox, and watch future issues of MCMagOnline for upcoming articles by IBMer Robb Wiedrich.

However, I am going to introduce you to something even more special, at least in my opinion: the open-source version of the Toolbox, known as JTOpen.

While it is closely linked with the LPP version of the Toolbox, JTOpen is also somewhat independent of it. JTOpen has a small group of individuals assigned to its Core Team, three from IBM and two from the industry. The IBM participants are Cheryl Renner, Chris Smith, and Bill Wiktor. The non-IBMers are Steve Johnson-Evers and your humble reporter. (Those jeering at the word "humble" are kindly reminded that this is a no-heckling zone!)

In the spirit of any true open-source project, the team accepts input (and even code!) from any interested individuals. That means that by getting involved with the JTOpen package, you can actually contribute to and help shape the future of the package.

What's So Special?

Well, the first special thing about JTOpen is the fact that it's basically a superset of the LPP version, with additional features and fixes. Things that will eventually be included in the LPP version appear first in JTOpen.

For example, JTOpen is already up to JDBC 3.0, while the LPP version is still at JDBC 2.0. Also, there are some incidents relating to fields of type date in JDBC that are fixed in JTOpen. In fact, whenever there is an issue relating to JDBC, the recommendation is to try the code using the latest JTOpen version.

Bugs in general get fixed much more quickly with JTOpen. There have been times when bug fixes have been available literally within hours, in contrast with the typical six-month cycle for LPP releases.

The open-source community has gotten involved as well. Things that appear in JTOpen ahead of the LPP include validation list support (from Tom Johnson at Kingland), limited S/36 file support (from Neal Wenderlich at USDA), a classpath optimizer utility (from Glen Marchesani), the Toolbox Micro Edition classes for handheld/mobile devices
(from Robb Wiedrich at IBM), and the PTF and ProductList classes (from Chris Smith at IBM). This list comes directly from Chris Smith and is a great demonstration of the power of open source.

There are also additional usability features. The latest release, JTOpen 3.1, provides the ability to use Apache Ant to create your own version of the JTOpen .jar files. This allows you to more easily include your own modifications and enhancements to the Toolbox. A new utility class, CommandHelpRetriever, is available in the com.ibm.as400.util package. It will generate HTML help text for any specified CL command(s) on the fly.

But perhaps the single most important advantage of JTOpen is the "source" aspect of "open source." All source for the Toolbox, with the exception of a few security-related classes, is available for review and download. For example, click to see the source for the AS400ZonedDecimal class, which converts data between packed decimal format and a Java BigDecimal. You can see exactly how IBM does things. And while this class isn't too involved, you can just as easily review the source for, say, the JobLog class, which is a wonderful example of how to use the QGYGTLE and QGYOLJBL system APIs within a Java program.

Which One Is Right for Me?

Which is the better solution depends upon your situation, but unless you are a software vendor, there is really no reason not to use JTOpen. The only caveat may be that, given the volume of enhancements and fixes, there is always the possibility that a fix to one feature might cause a bug somewhere else. But as long as you follow the reasonable procedure of testing a new release before putting it into production, the really overwhelming number of features included in JTOpen would outweigh any possible negatives.

Software vendors and IS managers supporting multiple sites and differing release levels need to be a little more careful. If your software depends on the latest version of JTOpen, then you should probably distribute JTOpen with your software--or at least have really good instructions on downloading and installing the latest and greatest version. If your audience isn't particularly familiar with downloading and installing .jar files and the latest LPP has enough function in it for your product, then you may want to at least have an installation option that works with just the LPP version.

The JTOpen team strives very hard to be backward-compatible, but that's not always possible, especially with major enhancements. In that case, you may want to standardize on the known quantity represented by the LPP version. But for any other use, the JTOpen package is by far the best way to go.

And even if you're a software vendor, you should have the latest version of JTOpen in your development environment, because JTOpen gives you an idea of where the LPP is headed. Compatibility with JTOpen will go a long way toward getting you ready for future releases of the LPP.

Conclusions

Let me get back to my original point about the right tool for the job. In the context of WebSphere, the single most common requirement is to get data from the database into the Web application. For most Java programmers, the initial answer is probably going to be to use JDBC. Without getting into a discussion of the merits and pitfalls of JDBC, I want to point out that the Toolbox offers a variety of other options.

The record-level access classes, for example, allow you to write code that handles the database just as you would in an RPG program: opening files, positioning the cursor, reading and updating records in place, and so on. The data conversion classes handle all the work of converting between DB2 format and Java objects, much the same way that SQL does--only without having to learn the SQL syntax. Logical files can be used to select and sequence records, allowing you to avoid having to format WHERE and ORDER clauses. In tests I've run, many functions run more quickly with record-level access than they do with JDBC.

Or I could call a server program. Let's say the data required is dependent upon some complex business logic. An example I like to use is order pricing. In a simple storefront, it's relatively easy to access a file and retrieve the price for an item. But in most real-world systems I've seen, pricing is a very sophisticated process, involving many files and a lot of database access based on customer, item, sales to date, promotions, and any number of other issues. In fact, many ERP systems have entire programs devoted entirely to calculating the price for an item. In that case, it would be counter-productive to rewrite this business logic in either JDBC or record-level access; instead, it would be best just to call the existing pricing program. And while I might be able to make this particular call using a stored procedure, there are other examples that require more bi-directional data capability than a stored procedure can provide.

Enter the Toolbox. With the Toolbox, I can choose any of these options and more besides. I can execute commands or access data queues. I am no longer limited to the syntax of SQL or encumbered by having to rewrite business logic in Java. Instead, I can easily make use of whichever tool is right for the job.

And for that, IBM, I thank you.

Joe Pluta is the founder and chief architect of Pluta Brothers Design, Inc. He has been working in the field since the late 1970s and has made a career of extending the IBM midrange, starting back in the days of the IBM System/3. Joe has used WebSphere extensively, especially as the base for PSC/400, the only product that can move your legacy systems to the Web using simple green-screen commands. You can reach Joe at This email address is being protected from spambots. You need JavaScript enabled to view it..