IBM Systems Magazine, Power Systems - September 2017 - 45
SPONSORED ADVERTISING CONTENT
Readability makes code more
maintainable, which, in turn,
makes it more reliable because
fewer mistakes will be made when
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
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 (bit.ly/2buYnVG). 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:
Many IBM i businesses today need
to offer services and perform commerce in ways that were unheard
of back when their legacy RPG
applications were created. Keeping
your software fresh and innovative
is one of the keys to preserving your
business's competitive edge. The
2017 Help Systems survey shows that
almost 50 percent of respondents
say modernizing applications is a
It's crucial that you have application modernization plans. As
you make those plans, though,
keep your modernization initiatives
focused on the weaknesses in your
IBM i applications that are either
costing you money or putting customer or prospect business at risk.
Modernization may mean not
improving what you have so much,
but rather adding to it. For example,
better web service integration with
your business partners or adding
salesforce would probably pay
bigger dividends than a wholesale
migration to free-format ILE RPG or
SQL database access.
Be brutal in making and executing your IBM i application
those with direct return on investment and customer/prospect
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
ASNA Product Specialist, ASNA Inc.
Roger has worked with the IBM midrange since the days when Tommy
Johnston was the lead singer for the
Doobie Brothers. He thinks a little part
of rock and roll died when Michael
McDonald took over for Tommy.
SEPTEMBER 2017 // 45