What skills should an RPG programmer have besides knowledge of basic RPG?

Recently, I had the opportunity to interview candidates for a programming position at our company. I had just lost an excellent employee due to personal reasons, and I needed an additional person to develop and maintain the code on our iSeries. We have a small group of five iSeries programmers, four of whom spend most of their time developing and maintaining RPG code and are part of our total IT staff.  The fifth develops programs for the iSeries as well as Windows and Linux servers, but in PHP and Java. As I looked through resumes and thought about the skills I needed in our company, I reflected on how much has changed in programming for IBM midrange systems since the early days of the AS/400 and what I now expect a programmer to know.

Several years ago, when I became actively involved in managing our development environment, I set a number of goals for our developers, and those goals have had a big impact in determining the qualifications of the person to be hired. I had a goal for programming in the RPG language, a goal for handling our database I/O, a goal for reducing redundant code in the system, and a goal for improving the end user experience. I also had a goal for my programmers to get them to branch out from PDM and to use a modern IDE such as the IBM Rational products. Each of these goals was designed to make my programming team more productive.

First, consider the goal I set for implementing programs in RPG. The code on our system followed an evolutionary path, similar to many small and midsized businesses. The programs ranged from those monolithic programs that are written in RPG III and use the cycle (remember that?) to newer fixed-format ILE RPG programs that make more extensive use of subroutines to meet our current standard, which consists of free-format ILE RPG and subprocedures. It has occurred to me that if I were to teach a class in RPG programming today, I probably wouldn't spend a lot (if any) time talking about the fixed-format version of the RPG language and the cycle except in a historical context. The person I hire, however, needs to be able to maintain those older programs and eventually convert them to free-format. Thus my first requirement for our new-hire is knowledge of both RPG languages: the old fixed-format, cycle-driven code and the new free-format version with all the BIFs. The modern version of the language would be perfectly fine to teach to new programmers, but to work in an environment like ours, they would also have to be familiar with the old syntax as well, so it's like having to know several languages instead of one. As an example, consider the program below that totals inventory. The item master file is ITMAST and is keyed by an item number that is passed to the program as P1ITEM, and the inventory master contains the quantity on hand (QTYOHD) for each product number and size at each warehouse. The program returns the total inventory in the company (P1ONHD). In fixed-format RPG, the calculation specifications might look something like this:

     C*

     C           KITEM     KLIST                           ITMAST

     C                     KFLD           ITPRNO

     C                     KFLD           ITPRSZ

     C*

     C                     Z-ADD*ZEROS    F1ONHD

     C                     Z-ADDP1ITEM    F1ITEM

     C*

     C           F1ITEM    CHAINITMASTR              99

     C*

     C           *IN99     IFEQ *OFF

     C           KITEM     SETLLINVNFM

     C           KITEM     READEINVNFM                   71

     C*

     C           *IN71     DOWEQ*OFF

     C                     ADD  QTYOHD    F1ONHD

     C           KITEM     READEINVNFM                   71

     C                     ENDDO

     C                     ENDIF

     C*

     C                     Z-ADDF1ONHD    P1ONHD

     C                     MOVE *ON       *INLR

     C*

 Now consider the same program written in free-format ILE RPG. I won't belabor the differences here, but they're significant. My Java/PHP programmer can read and understand free-format code, but he's at a loss with the old fixed-format. 

    /FREE

       f1onhd = *zeros;

       f1item = p1item;

       chain ( f1item ) itmast;

       if %found (itmast);

          setll ( itprno : itprsz ) invent;

          reade ( itprno : itprsz ) invent;

          dow not %eof(invent);

              f1onhd += qtyohd;

              reade ( itprno : itprsz ) invent;

          enddo;

       endif;

       p1onhd = f1onhd;

       *inlr = *on;

     /END-FREE

Second, consider our goal for database I/O. I've used SQL on the iSeries even in the early 1990s when it was painful, so, as the hardware performance has improved and the operating system has evolved, I've encouraged its use more and more among our programmers. That's not to say there aren't some occasions in which native I/O is appropriate, but the minute one begins to think in terms of processing a set of data, then using SQL to retrieve that data set just makes sense. Many programming tasks in our business do require thinking in sets. For example, I want the sales for all customers in the Eastern region, or the inventory for items from this vendor, or the products sold of this type. Take our previous example from above, in which I want the total inventory for a product across all locations. If I take the same program above and rewrite it using SQL instead of native I/O, then the code becomes this:

      /free

    // Note: f1onhd initialized to zero on the interface definition

       f1item = p1item;

       chain ( f1item ) itmast;

       if %found (itmast);

         exec sql

         SELECT sum(qtyohd) INTO :f1onhd

         FROM invent

         WHERE prodno = :itprno AND size = :itprsz;

       ENDIF;

       p1onhd = f1onhd;

       *inlr = *on;

     /end-free

My Java/PHP developer can even more easily read this code. Furthermore, if I want to share this code with someone working on a Java or PHP program, it's just a matter of copying the SQL code into the new program. I've found this to be a great way to promote interaction between our Java/PHP developers and our RPG developers.

The result is that many of our RPG programs contain embedded SQL for I/O, so my new-hire will have to be familiar with SQL and using embedded SQL in RPG programs.

Third, consider our goal for reducing duplicate code in the system. We've begun an effort to combine common routines in service programs, using binder language and binding directories to manage combining this common code with RPG modules. I might also throw in defining User-Defined Functions (UDFs), database triggers, and other techniques to reduce redundant code in our system. For example, if I have an old file (table) with a seven-digit date, do I want every new program I write to have to convert that date to a DATE data type, or just write either a UDF or a service program to do it once and then call that UDF or service program?  That means that the RPG programmer I hire needs to be familiar with those concepts and know how to work with them to integrate new code in the system.

Finally, let's look at our goal for the end user experience. One of my favorite questions to ask a new computer science graduate is "Why do you think there are 80 columns on a 5250 screen"? Most don't think about the IBM punch cards with 80 columns, which evolved from Herman Hollerith's design to process the data for the U.S. census of 1890. Why 80 columns? Well, there were 80 questions in the census, of course. It's interesting to imagine how displays would have looked if Washington had decided to ask 100 questions for that census. It's also ironic that it took exactly 100 years for a new display interface to be developed that would break with the 80 column tradition, the development of the first browser by Tim Berners-Lee. Just as SQL has become the standard language for database access, HTML is the standard language for displaying data on a browser. There's a tradeoff in flexibility and real estate for the browser. It's a complexity caused by choices. Now I have plenty of space to put my graph, but I have to worry about fonts, background color, images, and a host of other things that don't come into play with a 24X80 green-screen. This environment brings with it a whole host of acronyms such as JS, CSS, AJAX, XML, and many others. For our company, we are in the process of evaluating tools that will allow our programmers to write to a browser from their RPG programs without requiring the programmers to be HTML experts. However, any tool is going to require some knowledge of the terminology relating to events that occur in a browser. For example, ON_ROW_CLICK, ON_ROW_MOUSEOVER, and ON_ROW_DB_CLICK are all events that can be handled in a browser through JavaScript, with the results being passed to an RPG program. Thus my ideal candidate would have some knowledge of HTML, JavaScript, and interactions with a browser. Ideally, this means that they are familiar with at least one other programming language, such as PHP or Java.

Regarding our development environment, we settled on the IBM Rational Developer for Power Systems (RDPower) product. As an Eclipse-based product, it means that our programmers who are familiar with using it can work with Zend Studio or any other Eclipse environment and feel at home. I believe this is a great advantage for a programmer learning a new language, as it's twice as difficult to learn both a new language and a new IDE, particularly if that IDE is PDM/SEU.

So who did I hire? Our new-hire has experience with RPG III, ILE RPG free-format, and SQL. Our new-hire also has some experience with calling Java programs from RPG programs, but the one aspect that put him in front of my other candidates was that he had taken the Zend courses for PHP certification, which meant he had used Zend Studio and had some familiarity with Web programming.

While I'm sure not every company has the same requirements, I hope it’s been informative to share some of my thoughts on the skills I think are important for an RPG programmer to have.