In addition to writing for iPro Developer, I work a day job in the business of user interface modernization. Over the years, and especially since starting my current job, I've dealt with quite a bit of legacy code. Contrary to what some believe, all RPG code is not "legacy" code. RPG is just as capable as any other language of creating modern, modular applications. RPG developers just need to get outside of their comfort zones and move beyond their usual playbooks. Failure to do so will only further erode perceptions of RPG.
While I can't give you all the skills you'll need to modernize your applications in this article, I can warn you of some common pitfalls so you can avoid them. Here are five good ways to start improving your game.
5. Update Your Skills
Application development is an ever-evolving art. I call it an art because calling it a science would imply that strict rules exist that developers must follow to get their expected results. The truth is there are always multiple opinions on how to best accomplish a task. Savvy developers should take in the arguments for every side and form their own opinions on the best methods to use.
Take the time to sharpen the tools in your belt. Obviously, you should know all the latest features and techniques of the language you'll use for your application. For RPG developers, this means you should be familiar with and plan to use ILE subprocedures, service programs, and all the new features of your target IBM i operating system.
In addition to working on your RPG chops, you should also study a new language. Even if you don't use a different language in a project, you can often apply the concepts and approaches you learn in other languages to modern RPG code. This can be a huge help in designing your new application.
4. Use Modern Tools
Just as application development has changed over the years, so have development tools. The expression "use the right tool for the job" holds true in programming as well. The first step in modernizing an application is modernizing your toolset. SEU is simply not an efficient tool for creating complex modular applications. Figure 1 shows the development environment in Rational Developer for Power Systems (version 8.0.3). The colored code makes it easy to identify language elements. The outline to the right makes finding subprocedures or data structure definitions simple and quick. Additional features such as content assist, which can offer suggestions as you type, and wizards for setting up subprocedures, complex definitions, and calls to Java methods are real time savers.
Figure 1: Development environment using Rational Developer for Power Systems
If the IBM tools aren't your favorite, you can find third-party tools for writing your code in a range of options and price points. There are free editors for RPG as well as commercial offerings. The key is to examine the options and find one that works for you. Anything is better than the limited view you get in SEU, which IBM no longer enhances.
3. Be Flexible
You can paint yourself into a corner in several ways. The most common way I see is to restrict yourself before you've even started your modernization project by choosing certain methodologies and forcing them on situations where they might not make sense. When it comes to modernization in RPG, specifically database modernization, you have two choices. You can use traditional file I/O opcodes such as READ, WRITE, CHAIN, and all the others you've always used. Or you can choose to use embedded SQL to handle interaction with the database. Too often, developers choose one method and become zealots. Both are just tools to be used where appropriate. I've seen developers try to shoehorn one method or another into a situation where it's not ideal and become confused and frustrated. Instead, stay flexible and use both depending on the situation. My rule of thumb is to use embedded SQL any time I need to work with more than one record. While SQL can certainly interact with a single record, it's often not the most efficient choice for such situations.
Another possible way to inadvertently limit yourself is in your shop's coding standards. I've worked with many shops with coding standards that all but forbid most of the useful features added to RPG over the past 15 years. I still see shops that restrict variable names to six characters, outright forbid the use of ILE, or even require the use of RPG III. To be clear, I'm not against standards. But standards should evolve over time. At a bare minimum, they should be re-evaluated after every OS upgrade to make sure developers can use RPG's newest features. Also, all members of the development staff should be involved in developing standards. If developers are involved in creating the standards, they're more likely to abide by them.
2. Limit Your Project's Scope
Project scope is critical. If your plan is "Modernize our applications by the end of the year," you're setting yourself up to fail. That's not a plan—it's a broad statement with no direction. If you're modernizing your applications, chances are you don't have experience creating applications using modern techniques. How can you possibly put a timeframe on such a large project without knowing exactly what will be involved? Unfortunately, this sort of "plan" is often exactly the mandate that comes down from management. I was a project manager for my previous employer, and I assure you that you must break down a modernization plan into small, attainable projects. Remember, you're most likely learning on the job when working on modernization. You'll make mistakes. Would you rather realize this after reworking a small piece of your system or halfway through modernizing your full application stack?
A modernization project can be sliced many ways. I find it's best to start with a small, somewhat isolated part of your applications, such as order entry, human resources, or some other area. The best choice will differ for each company. Once you select an application area, divide it further. In my experience, there are two major fronts for modernization: user interface and business rule encapsulation. The user interface is exactly what its name implies. This can be a move from green screen to the web, green screen to a client-server interface, or printed reports to .PDF or Excel. The second front, business rule encapsulation, is the removal of business logic from your individual programs. These rules and the access to the data they apply to should be externalized into a common set of callable routines. In RPG this would be subprocedures inside service programs. Centralizing these rules allows you to make future enhancements to the application in one source member instead of in multiple programs spread throughout the application. Encapsulation also isolates individual business rules from each other. This makes it easier to test business rules because you don't need to worry about changes in one rule having side effects in others unless those rules use the modified rule.
The process of modernizing each of these two aspects of an application is quite different. Attempting to implement both at the same time is tricky, and I recommend handling each in separate projects in virtually all cases. So how do you decide which to do first? Well, it depends. Modernizing your business rules first can greatly simplify things when you're ready to modernize your user interface. However, if done correctly, this part of modernization will go completely unnoticed by your users. Tackling the user interface first is a much higher-profile change, but you might need to revisit some of your interface changes after encapsulating your business rules. My best advice is to know your stakeholders. If your managers and users understand that this is going to be a marathon and not a sprint, you're probably better off to start with business rules. On the other hand, if your stakeholders want results yesterday, go with the user interface. That gives them tangible results more quickly and might pacify them while you work on business rules.
Once you complete your first mini modernization project, you'll be armed with knowledge and, more importantly, experience. You'll probably adjust your strategy when you take on the next functional area of your applications. The next mini project should run much more smoothly and quickly. This trend will continue as you repeat the process over more and more parts of your system. As you work toward the most mission-critical systems, you'll have encountered most of the potential problems and already have answers for them. Remember how you swallow an elephant: one bite at a time.
1. Just Do It!
Doing nothing is the worst thing you can do. All too often, IBM i developers get frustrated or confused by the new options and concepts required for building modern RPG applications and simply give up. If you're writing code the same way you did 10 years ago, don't expect to catch up in a month. You have a lot of ground to cover, and it will take time to learn the concepts and fully understand them. When planning your modernization project, don't forget to allocate time and budget for education. It's crucial to your project's success. Attend a conference or sign up for a few webinars. There's no shortage of education out there if you just spend the time, and in some cases money, to get it.
The reality is that RPG and IBM i have a bad reputation of being outdated. This couldn't be further from the truth. There's nothing that IBM i cannot do. IBM i is considered "legacy" not because of its capabilities but because of IBM i developers. While exceptions certainly exist, the RPG community as a whole has let their skills stagnate and cultivated this perception of the language and the system. The only way to ensure the long life of IBM i and RPG is to begin bringing our applications and skills into the 21st century. Unless a business requirement justifies it, you should not write new applications using the green screen as the user interface. You should write new development using ILE to encapsulate business rules in service programs, and regularly examine existing applications as candidates for modernization. Otherwise, we're just perpetuating the problem.
The future is in your hands.