Recently, I completed a really large e-commerce site for one of my clients that taught me a few things I didn’t know about the AS/400. The challenge to my latest project was that I had to interface with a legacy system written in RPG III that has been around since the System/38. You know the kind of code. Just keep shoveling on functionality and never do a total rewrite. Not that that’s bad; in fact, it’s how we end up with fantastic legacy systems. Like fine scotch whiskey, legacy apps take time to fully mature into those killer applications. But did you know that all of the RPG III code is just as reusable as ILE C, RPG IV, and all these other highfalutin technologies that IBM has on the 400? Read on for the magic of stored procedures and how they saved my posterior.

The victim application is a distribution system that tracks inventory, lets people enter orders, and does accounting for a large company with 85 branch locations and a humongous warehouse. My job, like the prime directive in Star Trek, was noninterference with the native populace. In English, do no harm to the application layer, but place a Web interface for customers to reprint invoices, check stock status, order parts, and manage their accounts on top of that beast. Simple for SQL Dude, especially since the client had all of the source code, right?

Yes, to my amazement it was really simple, because the code and data was on the AS/400.

Why was it easy? First, a little background info. The systems architecture was probably like a lot of legacy 400 systems. The order entry program consisted of 25,000 lines of RPG III code with embedded presentation logic. However, the programmers had taken some of the application logic and put it into separate programs to make the application somewhat simpler and probably to gain some code reuse. For example, the code that calculated the price of a part for a specific customer was a separate RPG program that was called within the order entry program. Pass it the customer and part numbers and associated factors like the job number and phase of the moon and, whoosh, out comes the price for that customer at that moment in time. Thank goodness it was a separate program, as I have never seen a more Byzantine pricing program in my life. If I had to replicate the program logic myself, I would have been at the customer’s site till St. Swithun’s Day.

Another potential problem was all of the hairy tax calculations that are dependent on where a customer is and where the part is shipping from, especially if the customer is in a different country. Those RPG III guys saved my bacon, as the tax calculations were in a

separate program that was called with a parameter list and the tax charges returned in the list of parameters.

The system I created was built using Microsoft Internet Information Server (IIS) on an NT Server. It used Active Server Pages (ASPs) written in VBScript along with a few Component Object Model (COM) objects. When my ASP programs or COM objects needed a part price for a specific customer, I just called an AS/400 stored procedure that allowed me to use the RPG pricing program. Bam!

I didn’t have to rewrite the application logic; I got to reuse it in my Web pages. Again, when I was processing an order and needed to find out how much the Canadian government needed to be sent on behalf of my client, stored procedures allowed me to reuse the legacy code. Finally, when my order was processed and I needed to print a pick ticket, I just called the appropriate RPG III program via SQL and the ticket magically printed at the proper branch location.

The beauty of the whole approach is that I wrote only a single CREATE PROCEDURE statement for each RPG III program that I wanted to call. The CREATE PROCEDURE statement identifies the program I want to call, the parameters that are expected, and the language of the program. Once this statement is executed, and it is only executed once, the legacy program is available to me via an SQL CALL statement. And note that these programs I was calling are RPG III programs, not ILE C or RPG IV. I left the legacy code as it was and invoked its important logic from another platform to do my bidding. Again, I want to emphasize that there was no recompilation of the RPG III code, no complicated wrapper program, and no need for Java servlets or ILE service programs.

I just used the built-in facilities of the AS/400 and its amazing support for SQL standards. Now the application logic is available to any program on any platform that supports SQL. Yes, Virginia, there is a Santa Claus, and his name is AS/400.

Using stored procedures is the best way to leave the business logic where it belongs and let you place the presentation layer somewhere else. That somewhere else can be an RPG program with DDS, a VB program on a PC, or a Java servlet using WebSphere. You probably do not have to redesign and recode your legacy applications as much as you might think to make them Web available and presentation-layer independent. Some small redesign may be necessary, but overall, that would just make your code more reusable and less complicated from a management standpoint by separating the logical functions of the code into separate programs. I’m sure that if you take a look at your legacy code, you can find procedures waiting to be called.