IBM Systems Magazine, Power Systems - September 2017 - 47
SPONSORED ADVERTISING CONTENT
Revitalizing IBM i
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
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
Regardless of how you access
the database, shops should
The IBM i development landscape is
at a pivotal point.
Free-format RPG and Rational*
Developer for i have gone a long
way in making RPG more "friendly"
to new-to-IBM i developers. As these
youngsters discover IBM i, RPG
and Db2*, they quickly appreciate
they learn that life offers more interesting tasks than load-balancing
and rebuilding databases!
This, in turn, has helped managers
realize perhaps they don't need
vacancies. They can hire good business-savvy programmers and teach
These new developers understand
open source and other programming languages, which adds vitality
to the platform. They show traditional IBM i folks why such diversity is
Over time, we'll see more blurring
of development roles in IBM i shops.
RPGers won't just be RPGers. They
will be equally comfortable building modern interfaces while using
open-source packages, languages
and libraries-not replacing RPG,
but augmenting it.
RPG will continue to improve.
We'll see more affordable, reliable
tooling to convert old RPG/400 and
RPG/36 so those dinosaurs will no
longer be barriers to progress. Smart
managers will make sure progressive staff have the time, education
and budget to update old RPG
and move away from 5250 and SEU
Considering these trends, IBM i
has a bright future.
Three Good Reasons to Stop Writing Subroutines:
SEU Was Holding Me Back: bit.ly/2vz3uOk
Host, RPG & DB2 Summit;
Co-Founder, System i Developer LLC
SEPTEMBER 2017 // 47