Updating your ILE and RPG skills will not only make you a better IBM i developer, but also make learning new languages easier.
My last article discussed learning new languages on IBM i. In that article, I also mentioned that before trying to conquer new languages, we should master our own. If you are not well versed in all that RPG has to offer, this article is meant to guide you toward the topics that every RPG developer needs to learn.
I cannot teach the topics below within the confines of this article. I will leave the research to you. As a coauthor of the IBM Redbook Modernizing IBM i Applications from the Database up to the User Interface and Everything in Between, I will obviously recommend that you add it to your reference library, but there are many other sources available.
This is the obvious first step. Free-format syntax has many benefits, especially improved readability. I find it also helps with the transition to more modern RPG coding. By leaving the fixed-format syntax behind, many developers are less inclined to fall back into the rut of outdated coding. In fact, in many cases, such as the dreaded GOTO opcode, these old coding practices are simply not allowed.
If you are not using at least free-format calculations in your code, you have a lot to learn, but it is not an insurmountable task. If you are still writing RPG III code, even RPG III-style code in RPG IV, you can make the transition to free-format in steps. Start with using free-format C-specs. This is a very simple adjustment for most developers. Also stop using numeric indicators and RPG III style opcodes in your programs. These can be easily replaced using built- in functions, the EVAL opcode, or the IF opcode.
Once you are comfortable with free-format calculations, go ahead and make the jump to fully free-format RPG. You will need to be on at least IBM i 7.1 and have the proper PTFs installed. Now all of your code in RPG can be free-format, and even better, you are no longer limited to 90 columns per line for your code. Line length is only dependent on the record length of your source physical file. If you store your RPG code in an IFS file, there is no limit.
Now that you are comfortable with the new free-format syntax, it is time to work on another concept. You should begin using subprocedures instead of subroutines in your code. A subprocedure can be used just like a subroutine, but with many added benefits. Most importantly, subprocedures can have their own local variables and can accept and return parameters. If you have written a subprocedure and need to use it in more than one program, it can be moved to a service program, but you can worry about that when you start learning about ILE.
I have not used a subroutine in production-level code in years. There’s just no reason not to use subprocedures in virtually all cases. Subprocedures are also the building blocks for many of RPG’s best features.
The best part of subprocedures is the ability to define fields, data structures, and even files locally. Unlike subroutines, which use only global variables, subprocedures can, and in most cases should, use only locally scoped resources. When done properly, your subprocedures become black boxes that can neither affect or be affected by other code. By using parameters to bring needed data into and return data from the subprocedure, your subprocedure is a controlled environment. This reduces bugs in your applications and makes your subprocedure reusable. As you have probably noticed, our concepts are building upon each other to work toward the goal of utilizing the ILE environment.
Programming Without the Logic Cycle
Whether you realize it or not, unless you have specified a subprocedure name using the MAIN keyword on your control spec, RPG’s logic cycle is being used in your program. The logic cycle does simplify parts of your RPG program, but it also comes with baggage.
By utilizing the MAIN keyword, the mainline code of your program is contained in the specified subprocedure. This is known as a linear-main program. In a linear-main program or module, your code must handle some things that the logic cycle did automatically. The most notable example is the closing of globally defined files. In a cycle-main program, the logic cycle closes open files when a program ends with *INLR set on. In linear-main coding, you will need to include code to close such files.
One of the most interesting advantages to linear-main programs is that your subprocedure used for your mainline logic now has its own local scope for variables. When properly utilized, many programs will have no global definitions. In this scenario, subprocedures cannot affect one another other than the parameters passed between them. This makes your code less bug-prone and more modular.
Another interesting advantage to linear-main programing in RPG is the ability to call the program recursively. By eliminating the RPG logic cycle from the program, there is no longer an error if a program is called recursively. This can be useful in some situations where a user may be able to navigate an application in a way that causes recursion.
Now that you have mastered local subprocedures, it is time to embrace the ILE environment. This topic can be confusing to some long-time RPGers, but if you keep it simple, it is not that difficult to learn. The problem most RPGers make when moving to ILE is that they overthink it.
The ILE environment is very flexible and will let you create an environment as complicated as you like, but the reality is most shops that are not developing software for sale need not worry so much about some ILE concepts. Don’t confuse yourself by trying to build a complex environment using techniques and concepts that you do not understand. Keep it simple.
A common question I am asked by those learning ILE is, “How many activation groups do I need?” Honestly, 99 percent of the time, the answer is one. Unless you have a specific technical reason to be able to manage and reclaim resources separately, just use an activation group unique to your environment and move on. Your company name is often a good choice.
Another common question is, “How many service programs should I have?” Organize your subprocedures into service programs however you like. I personally prefer to organize procedures into service programs by business object. So, I may have a service program called CUSTOMER with all procedures related to processing customer data and related business rules within. I may also have service programs for items and purchase orders. This can help you to keep your procedures organized and separated.
Another tip to help you stay organized as your environment expands with more subprocedures and service programs is to document them somewhere. A comprehensive list of each subprocedure, its function, and its location will prevent duplication of code. You can maintain this documentation however you like, but I often recommend hosting a wiki internally for this type of documentation. A wiki allows for easy searching for information and is easily editable by the entire development team.
Once you have mastered the topics above, you have not necessarily mastered the entire RPG language, but you are well on your way. You will also be much better prepared to explore new languages. You will find that modern RPG has many similarities with most other modern programming languages.
As you are updating your RPG development skills, you should also start using a modern development environment. SEU is just not the answer. IBM’s solution is, of course, Rational Developer for i. RDi is a great IDE for IBM i development and would be my first choice every time. Some have voiced concerns about the cost of RDi. While I do not wish to debate the cost, it is important that we know that there are alternatives, and RPG developers do not have to stay with SEU if they cannot purchase RDi. In June’s article, we will examine several low-cost and even free alternatives to RDi. While, they may not be as feature-rich, they are certainly better than nothing.
As always, I encourage you to continue your quest for knowledge and constantly update your skills. It is of course spring conference season, so look into your options for education at one of the upcoming events. Most importantly, be sure you invest in yourself. I hope this information gives you some guidance on topics on which to concentrate as you update your skillset. Now let’s get started!