7 Keys to Future-Proofing Your RPG Applications
Implementing RPG future-proofing techniques leads to applications that are more resilient and easier to maintain and enhance over time
Implementing RPG future- proofing techniques lead to applications that are not only more resilient, but also easier to maintain and enhance over time to keep up with technology. Failing to future-proof applications risks them becoming obsolete, which will inevitably result in your company wasting significant amounts of money in transitioning to other less able platforms.
These topics have all been covered before, and we’ve addressed many of them on our iDevelop blog (bit.ly/2tCwcwk). We hope consolidating these important topics in one place will provide a basis for discussions with your coworkers and management.
The following are seven elements we feel are critical to RPG success. Before we start to work our way through the list, it’s important to understand one thing: You shouldn’t consider it a failure if you cannot currently tick every box outlined here. The only sure way to fail is to do nothing and simply maintain the status quo.
1. Use Modern RPG Techniques
Modern RPG techniques go beyond simply using free-format RPG syntax. Here’s our checklist of modern RPG techniques. It’s by no means comprehensive, but it’s a good start. How many of these can you check off?
- All my RPG/400 code has been converted to RPG IV (aka RPGLE)
- I use meaningful, mixed case names
- I only use numbered indicators when forced and then give them meaningful names
- I code all my RPG (logic and declarations) in free-form
- I use procedures to structure my code
- I build service programs for my reusable components
All of these items make your code more readable and understandable. That’s critical not only for programmer productivity but also because code that’s easier to understand makes it more obvious where to make changes when adding new functionality or fixing problems. Readability makes code more maintainable, which, in turn, makes it more reliable because fewer mistakes will be made when making changes.
Conversion to RPG IV is a prerequisite to all the other items in our modernization checklist. Sadly, we know of relatively few shops that have converted all of their code, even though RPG IV has been around since 1994.
The next two items in the checklist relate to names—typically variable names, including indicators. AccountBalance is more obvious than ACCBAL and CUSNM should really be CustomerName—or should that be CustomerNumber? See the problem? Making the wrong assumption about the meaning of cryptic variable names often leads to errors.
Indicator numbers (such as *IN47) are inherently obtuse names. Avoid them in RPG except when unavoidable—such as O-specs and DDS display and printer files. Even then, use meaningful names via the INDDS support on the file declaration or named constants as subscripts to the *IN array or re-map the *IN array to give meaningful names.
We’ve covered the importance of free-format syntax before, including this online article where we made our case for the top five reasons to use free-format RPG. Spoiler alert: Many (but not all) of the reasons have to do with readability.
Procedures can easily replace subroutines and because they offer the additional benefits of parameter passing and return values, local data and ease of reuse via Service Programs, they are excellent tools for structuring our RPG code.
Readability comes into play here again. Take a look at two possible ways of calling a routine to determine the day of the week of a date value:
Exsr DayOfWeek; versus WeekDay = DayOfWeek(deliveryDate); Which provides more information about what’s going on? The call to procedure DayOfWeek tells us what we’re using as input to the routine and where the result of the calculation will be stored. To get that information from the subroutine, we’d need to study the subroutine logic in detail—a time-consuming and potentially error-prone task.
2. Establish a Reusable Function Library
Once you start structuring your applications around subprocedures, it becomes natural to seek out those routines that have utility outside the programs for which they were originally developed. Obvious candidates include routines to validate addresses, format phone numbers, send emails, perform customer lookups and credit checks, etc.
This approach yields many benefits (i.e., if a function correctly performs a given task such as validating a customer number in one situation, it will work correctly in all situations). This is much better than copying the code from one program to another. While this practice is the norm in many shops, it can lead to multiple versions existing independently. This results in a time-intensive and error-prone process to add features or fix bugs. Several years ago, we had a client who had been wrestling with the diminishing returns inherent in maintaining old-style RPG. The client finally decided to reengineer one of its main applications around reusable components in hopes it would improve maintenance and response.
The client discovered two things. First, testing the new application was faster, more comprehensive and turned up fewer problems because programmers were able to thoroughly test the “black boxes” independently and fix bugs while the code was fresh in their minds. Second, programmers were able to respond to requests for new functionality in ways that would have been impossible previously. One year after the fact, they reported more than 50 percent of the time their new routines were being used to develop web services and other new functionality they couldn’t have dreamed of producing under the old system.
3. Exploit Db2 and SQL
Making a decision about how to access the database is something many of us don’t spend much time on. Unlike many other languages, RPG gives developers the choice of whether to use SQL or RPG’s own native database access. Most RPGers are in one of two camps: They use SQL exclusively, or they avoid it at all costs because they perceive it to be slow and complex.
We believe in using the best tool for the job. Often, that means using SQL with its set orientation. But forcing developers to use SQL exclusively can lead to complex RPG logic to deal with cursors and condition handling methods. So we encourage developers to look at the database use in the application to determine the most appropriate way(s) to access data. There’s no law prohibiting a mixture of both native RPG and SQL access.
Regardless of how you access the database, shops should definitely look at using Db2* for i capabilities to embed business rules into the database and simplify the RPG logic. This can be done in multiple ways.
Implementing referential integrity and check constraints allows you to specify relationship constraints as well as range and value checking. This can reduce the amount of RPG logic required and help ensure more consistency of handling of data validation logic. Triggers, written in either RPG or SQL, can handle complex business rules consistently. The need for embedding the rules into the database grows greater every day as the potential for users to access database tables for their own purposes increases because workstation-based software employs ODBC/JDBC or other forms of remote access.
SQL views can be created, thereby exploiting the full power of SQL statements—well beyond the capabilities of DDS logical files. This also simplifies the RPG logic by accomplishing selection criteria and joins or unions to gather data from related tables without program logic.
While it’s possible to embed all of that SQL directly into the program, using SQL views is like taking externally described files a big step further. On our platform, we would never dream of hard-coding the definitions of columns, data types and sizes in each program, and we extend that philosophy to the way we select and view our data as well.
4. Modernize Your Toolset
Rational Developer for IBM i We’re big fans of Rational* Developer for IBM i (RDi). Many reasons exist to use RDi compared to the green-screen PDM/Source Entry Utility toolset that we could write many articles on that subject alone, but we’ll just highlight a tiny subset of our favorite features here.
With RDi, we can have many source members open for edit at once, and we can split the screen as many times as our screen real estate permits when we need to see multiple members at the same time. This becomes more important with today’s more modular coding styles. The number of lines of code we can see at once is limited only by the combination of screen size and customizable font size. Typically, we can see at least 2-3x the number of lines of code on the screen at a time compared to SEU.
Fixing all those compile-time errors that inevitably seem to crop up is dramatically faster thanks to RDi’s error feedback that pops up a list of our compile errors on the screen alongside the source code. A quick double click on an error in the list positions us at the offending statement immediately.
RDi’s outline view allows us to see the size and type of variables at a glance, whether internally or externally defined. The outline’s cross-reference also shows every line of code where each variable (or procedure or subroutine) is referenced in the code. The same data from the outline is also used to allow the definitions of variables to appear as hover text and it enables content assist to help complete statements when writing new logic.
Shortcut keys are another of our favorite features because they provide quicker ways to perform common actions. We’ve even published a pin-up list of our own favorite keyboard shortcuts (bit.ly/1oSevV7).
Other Critical Developer Tools
Change management and/or version control software has become a requirement to reliably deal with the fast pace of today’s application development cycle. Many third party suppliers of IBM i-specific tools understand our traditional source member storage model. Many even have features that go well beyond simply keeping track of changes, such as helping to distribute code. Open-source tools such as Git are also rapidly gaining in popularity, in part due to IBM’s recent open-source initiatives.
Many other tools can make an RPG developer’s life easier and more productive, including those that convert RPG/400 to free-format RPG IV or help decipher complex logic for documentation or refactoring. Most of the tools we’ve talked about here do have a price tag attached, but the resulting ROI makes a clear business case for development tool expenditures.
5. Enhance User Interfaces
Green screen can be adequate for some applications (and some people claim they can be as good or better than GUI interfaces) but in our experience, the majority of such claims made for green screen come down to poor UI design. The simple fact of the matter is today’s workers use GUI and touch interfaces in everything they do, from banking and listening to music, to making their menu selections at their favorite restaurant. Failing to modernize your UI is making it harder for your company to recruit and train new users.
Even if we accept a green screen is adequate—or even appropriate—for some tasks, that’s irrelevant because the person who is “happy” using that interface is not the one holding the purse strings. Those who control the funding are the same ones that will look at your green masterpiece and immediately discount it as old fashioned. Luckily, a plethora of tools are available to help you modernize, ranging from very sophisticated “screen scrapers” to tools designed to build new graphical and mobile-oriented applications by leveraging your existing RPG skills to drive the back-end logic. Most of these tools use frameworks or template-driven systems to help even design-challenged developers like us create practical interfaces quickly and easily.
6. Learn Another Language
The main idea here is not to replace RPG but to augment it—and more importantly, to shake up your thinking. For example, when we learned PHP, we found, among other things, it changed our approach to using arrays and DS arrays in RPG. PHP’s wide range of readily available function libraries also increased our determination to seek out pre-built solutions rather than constantly reinventing the wheel.
Most languages that have utility value on IBM i can also run on a PC. There’s no need to ask for permission to get PHP, Python, node.js, etc. loaded on your IBM i—you can learn on your PC and even access Db2 to prove to your bosses there’s value for your company in these new offerings.
We happen to believe RPG will remain at the core of our business applications for many years to come, but there’s never any harm in a little “future-proofing” to enhance your own career. Make sure you’re the person management turns to for advice on the best way to approach a new requirement. Far too many RPGers are unaware of what languages are supported on the platform and as a result don’t raise their hands when someone questions the IBM i platform.
7. Exploit Open Source
The arrival of new languages on IBM i has opened up a world of hundreds (if not thousands) of high-quality, low-cost or free applications.
If you want to run an effective, cost-efficient operation, you must resist the tendency to reinvent the wheel. Learn to utilize existing tools and applications. And like our strategy for learning new languages, don’t forget you can use your PC to familiarize yourself with the software and determine if it’s a good fit.
There’s also a growing collection of RPG-based tools. As of this writing, we’re in the process of completing a proof of concept for a client who wants his RPG programs to be able to consume and provide new REST web services that utilize JSON. We accomplished this by utilizing Scott Klement’s port of the YAJL JSON library, along with his HTTPAPI for consuming web services—two excellent pieces of software that have been extensively tested. We also used the free SoapUI desktop application to test the new web services independently, together with IBM i-based tools.
Small Steps Matter
Modernization is an important conversation that should be taking place in and between all IBM i shops. Remember, the only wrong approach is to do nothing. Try out a few of these approaches—who knows what you will be able to achieve.