I've been building web applications with RPG IV on IBM i (formerly i5) for more than 12 years. One of the biggest challenges has been to move away from the DDS/Display File programming style to using API calls to access data. I was one of the forces behind getting IBM to open up this operating system by adding APIs; so for me, using APIs to do things, such as reading data from a web page, isn't rocket science.
But that’s just one piece of several new technologies you have to introduce to your programming skill set to access the web from within RPG. Other technologies include:
- HTML syntax
- XML syntax
- CGI programming model
- CGI developer library
- ASCII to EBCDIC conversions
In addition, you have optional components such as the PHP language, the Unix environment associated with web and CGI programming and, of course, HTTP server configuration directives. All in all, this makes web development a challenge that you need to pursue with purpose and a plan—you can't simply make it up as you go.
HTML is the output and input "language" for web pages. I say "output/input" because it is that way—you output a web page and then receive the input from that web page into your RPG program. You can design a nice web page or build an HTML "document" (as they are called) that mimics a classic 5250 Display File DDS screen. Again, the biggest challenge is that the kinds of things you're used to having built-n to DDS require a little more effort with HTML.
Just remember one important issue when it comes to HTML-based web page design: RPG programmers are typically very poor at designing HTML web pages. I’m not talking about coding the individual elements like input boxes and tables of data. I’m talking about laying out a page nicely, picking colors that go well together, and using appropriate icons and images. Even something as simple as styling an error message is much harder to do nicely on a web page than it is in DDS. Users won’t be comparing your web applications to your green screens; they’ll be comparing them to other web pages they use in their everyday life. Far too much pride is found in programmers with legacy experience. The basic recommendation: assume you aren't very good at it and let someone else provide the overall look and layout for you, especially for customer-facing applications. You just work with the data elements on the screens.
XML has one of the simplest syntaxes of anything we deal with today. Initially, XML was intended to be used to send small amounts of data between different operating and database systems. Today XML is being used for things it was never intended to be used for, and it seems to be holding up. For example, Web Services, Microsoft Office, application settings files and, in some cases, data transfer procedures all convert data from their native format to XML. In fact, Microsoft changed the format of Word, PowerPoint, and Excel documents to the new Docx format, which is basically XML.
Here's a 10-second tour of XML syntax:
< tagName > data < /tagName >
The tagName is the name of the data element. You assign that name, similar to coming up with a field name in a database file. The data is textual in nature, but it can be all digits and read into a numeric field (with some conversion).
The interesting thing is that RPG IV's own XML-INTO opcode can parse just about any XML you throw at it (at least on v7.1). This opcode has come a long way from its introduction when for anything complex you had to switch over to the XML-SAX opcode. Today, however, I have yet to find anything that can't be parsed with XML-INTO. But if you're a classic XML SAX parser type of developer, you can enjoy RPG's XML-SAX opcode and its rich set of features.
CGI Program Model
With the CGI program model, you’re just moving away from the classic EXFMT style RPG program toward a more event-driven programming model. It’s actually a lot of fun writing event-driven applications with RPG IV. Your program is called by the web server and passed some information. The program reads that information, does what it's supposed to do, and returns. Basically, it is substantially similar to writing a subprocedure where you perform a task and return. As you become more skilled and accustomed to this programming model, you can expand on what is performed and the complexity of your results, but it does allow you to begin with something as easy as the classic "Hello World" program before you move on to mimicking a subfile in HTML.
The single biggest difference in programming with a web interface, the so-called "CGI Model," is that your users don't need to call your program to view their screen (web page). That web page can be previously created by another program or simply be a static page. The end-users fill in the data and when they press SEND or the classic "SUBMIT" button, the data on the page is gathered up and made available to the CGI program also identified on that page. Then the program is called and the page's data is made available through an API. Yes, you'll have to call an API, but you already do that; RPG calls its own APIs "Opcodes" and the only difference is that you’ll have to look at the documentation to view the parameter list until you get used to the APIs.
CGI Developer Library
One of the first things we early adopters of "RPG for the web" did was create helper procedures for CGI programming. While I've been a huge advocate of IBM i APIs over the decades, the APIs of late have been a bit vexing. The original CGI Developer library of helper procedures was former IBMer Mel Rothman's CGISRVPGM (CGI Service Program). Later, he updated this library and dubbed it "CGIDEV2." Brad Stone then wrote the book on the so called "eRPG" programming and largely referenced Mel's work. I too embraced CGIDEV2 all the way, but then IBM dropped the program for a short time and quickly reintroduced it. Then Mel retired and IBM once again dropped CGIDEV2. I offered to support it myself, but IBM wanted a five- to six-figure buy out just so I could continue to give away CGIDEV2.I said no and developed CGILIB—a much more modern implementation, written from the ground up. Eventually, CGIDEV2 ended up in another former IBMer's hands, and it continues to be available today. But I like my version better.
Recently, a number of commercial libraries have appeared that go way beyond anything that CGIDEV2 or my own CGILIB can do. They take on the challenge created when moving to RPG for the web. These more advanced tools do all the "heavy lifting"—t hey help by hiding the new terminology, technology, and API interfaces from you. But as you gain experience these tools allow you to dig deeper and customize the results.
One of the biggest challenges for RPG developers has always been web page design and creation. While it’s relatively easy to use the cgiGetVar('CUSTNAME') subprocedure in CGILIB to read the value of the field named CUSTNAME from the HTML page, it is a much different story to have actually designed that page with any resemblance to someone who actually has skill in web page design. Typically, RPG programmers do not have this skill, although they tend to believe they do. If you're a great web page designer, you're probably not an RPG programmer. Likewise, if you're a great RPG programmer, you're probably a poor to average web page designer. In either case, you need to consider using a tool built by a company that has skills in all of these areas.
ASCII to EBCDIC Conversion
This area has some good news. While it’s complex to convert ASCII to EBCDIC in RPG IV, the HTTP web server does a pretty good job of that for you—and does it automatically. This means that while users are typing in data in ASCII and sending ASCII to your RPG program, the web server in the middle detects this and converts everything to EBCDIC for you. So your program receives the data in good old EBCDIC.
If you have to convert something from time to time, the best solution is to use the iconv API. This API is actually on most operating systems, but it is customized on IBM i. This is really the only valid conversion API you should use today. I've written a number of articles on this topic and even posted a wrapper for the API itself, but at the end of the day, you should at least try to become familiar with iconv instead of some of those deprecated QDCXLATE or QTBXLATE APIs which are not intended for ASCII to EBCDIC conversion (they were created to convert data on tape drives, not data from the web).
You also can convert data using the IFS APIs. If you've received information from a web page that has already been converted to EBCDIC and then have to store that data into an IFS file as ASCII you might ask, "How can I make the HTTP server stop converting this piece of data?" But that's the wrong question. Remember, this is IBM i, so there's probably a simple way to do this task. The IFS APIs allow you to suggest that the data being written to an IFS file is been sent as EBCDIC and please convert that data to ASCII for me. Likewise, the other way around is true when reading IFS files. So this area, too, is simple once you become familiar with it.
A large portion of my consulting time is spent writing RPG CGI programs for IBM i customers. This is too large an area for just one programmer to work on (unless that one programmer has a few years to dedicate 90 percent of his time to the cause). If your shop doesn't have that kind of time or resources, you should consider licensing a third-party packages that does it all for you. They are wonderful tools and the source code they produce is available for you to review and learn from. Today a web face on your company is more important than ever. In fact, if you don't already have one you're probably not doing business with the public or other businesses.