It seems this problem has existed for almost as long as IBM i has. Maybe even longer. But for the most part...it doesn't really exist.

I had this discussion about 16 years ago when I was thinking about what computer technology I wanted to focus on in college. At the time, I settled on RPG and AS/400 operations. My school was the only one east of Montreal that taught those skills, and I thought I'd found a great niche. Of course, what I heard back then was that a lot of RPG programmers were on the verge of retirement and there would be all these jobs available. Most people in my college were learning Visual Basic, Java, and C++, so I figured I had it made. While I did get hired right away, it actually took me three years after graduating to write a line of production RPG code.

Back then, in my first AS/400 job, I was asked to learn not RPG but LANSA and EGL.

In my second job, I was asked to learn not RPG, but Domino and Cognos. I had to make a solid case to my employer at the time to do some of the coding work that the RPG consultants came in to do every two months. It took even longer for them to allow me to write it in free-form because those particular consultants couldn't read that stuff yet.

The free-form conversations usually started like this: "If you leave, who can read free-form RPG?" A bit backward, huh?

I spent eight years in that job. Any RPG I wrote was in free-form, and I was able to convert programs into that format, piece by piece. With regard to succession planning, not only were they worried about who could program RPG in five years, but who could program in free-form and fixed-form RPG. Instead of standardizing the code to free-form with a conversion tool, they made the problem more complex by defining a backward-compatibility requirement for application developer skills. Think about that.

Over the last 16 years, I've heard variations on that motif—from the ludicrous previous example to the standard complaint of "We can't find RPG programmers." Those in the industry longer than I would probably say the same thing.

Back in March, HelpSystems released its 2015 IBM i Marketplace Survey, which highlighted this need once again. In the study, 49.1% of respondents stated that IBM i skills depletion was a top concern facing their organization over the next 5–10 years.

While RPG and IBM i are not the most abundant technologies you'll find at your average college, I'm wondering if they ever were. A few months ago, I was in a room with about 30 IBM i professionals of varied age groups, and the topic was raised about IBM i talent being unavailable in college graduates. A question was raised: "How many of you learned RPG in college?" Two hands. The rest learned it on the job. By no means is that indicative of the entire population of IBM i professionals. It was really interesting but not surprising. Most of them had a background in tech but learned IBM i on the job.

I posed the question on Twitter and LinkedIn last week, and only one response came back positive. The majority of people I'm connected with learned IBM i on the job.

So where's the disconnect here?

From my limited experience, many of us didn't learn anything about IBM i in college. Most of us were hired because of our overall technical abilities, positive attitude, and willingness to learn.

The strength of the AS/400 was that anybody could run it. It was a business machine, not an IT machine. You didn't have to be a big geek to operate it. As an IBM Business Partner years ago, my main contacts at customer shops were mostly people who started off in office jobs that eventually morphed into IT jobs that began when they were first delegated the task of changing the nightly tapes or another rudimentary task.

IBM i has grown a lot since then. The complexity has increased a tad only because the integration factor has increased as well. Portable Application Solutions Environment (PASE) was released in V4R4 (1999) and only became a no-charge option in V5R2 (2002). PASE allowed for the i component (integration) of IBM i, which makes solutions like Java, WebSphere, PHP, Ruby, MySQL, Zend Server, Node.js, and more all able to function on the platform. Since the potential for complexity has increased so has the potential for complexity in IBM i management, although far less than on other platforms.

Since IBM i has grown, so must our perspectives if we are to plan properly for the future.

We need to be modernizing our code. Linoma and ARCAD both have RPG conversion utilities to pull code from fixed-format to modern free-form. Why would you want to convert that old code? It works, right? We need to convert it to make it more easily readable and therefore more maintainable. The new RPG language looks far more like PHP and Java than it does old RPG. Since it looks familiar, new programmers will be able to pick it up easier. The difference is just the syntax. And no, an argument that indicators are part of the syntax doesn't count. Imagine training a modern developer about indicators. Of course, you must give them the history of the indicator when they give you the deer-in-the-headlights look. Don't waste your time. Update the code and make the investment to future proof your applications.

We need to be modernizing our databases. Do you really want to explain to someone who understands SQL tables how a multi-member physical file works? SQL/DDL is the most-often-used standard for creating database objects. We have to get out of DDS and into DDL. Yes, the SQL engine once upon a time was slow. It's much better now. In fact, I would argue it's far better than record-level access with DDS. IBM is investing a tremendous amount into DB2, none of which goes into DDS. All new database improvements are in the new DB2, folks. Again, this makes our investment far more maintainable.

We need to be modernizing and investing in our skill sets. We have to be looking at what tool is right for the job. That means we need to be not only learning more languages, but building new applications with those languages. I know a company that put their eight RPG programmers through Java training about 10 years ago. What happened? Not a single line of production Java code was written. Why? There was no mandate from IT management to use it. There was no buy-in. There was no plan to convert an application to Java or create the new killer app in Java. It was a modernization fail because leadership failed. It's not enough to have someone load Zend Server and hope our developers will use PHP. The rules of the road must be set and you must have buy-in from everyone in order to truly begin modernizing. In that regard, we also need to be modernizing our attitudes.

With that being said, I don't believe most IBM i shops actually have a serious need for traditional RPG programmers. We need IBM i developers. There is a difference. We need to have people with solid business programming skills who've kept current. We need multilingual developers who can move in and out of different languages and frameworks. Don't forget that most IBM i shops are small to medium businesses. The majority of our shops have fewer than five developers on staff. We must be agile and able to wear many hats.

But that doesn't mean we shouldn't promote IBM i and RPG. If you have an investment in RPG and want people with RPG skills coming out of college, then you need to be talking to your local colleges and generate a demand for that skill set. They're not going to teach something without a business case. This is especially important for customers and ISVs with major development shops. You have more influence in your communities to get RPG taught as part of a college curriculum because you provide jobs. This isn't an "IBM needs to market IBM i" thing. This is at the local level. The IBM Power Systems Academic Initiative has grown 152% in two years. IBM is doing their part. We need to be doing ours if we want that skill in new graduates.

Personally, I'm happy to hire open-minded, easygoing, talented developers and show them IBM i. After that, everything else is just syntax.