Striving for IBM i Programming Team Harmony

We discussed your RPG and PC programming teams in Can You Trust Your RPG Programming Team. In that article we discussed the challenge of getting reliable and objective advice from them. In this article we take a look at some of the issues you’ll likely encounter as you discuss migrating your RPG applications with these teams.

As a manager, you are surely very good at leading and motivating teams. We don’t mean to hand-wave away your experience and knowledge, rather this article seeks to remind you about some of the issues and angles you’ll likely encounter as you engage your programming teams in crafting a plan about the future of your critical RPG applications.

In our experience, the two nations are generally willing to communicate with each other but are not capable of doing so without an interpreter. Programming tools, language constructs, best practices, and myriad other issues conspire to make the gulf of communication between the two teams broad and deep.

Sadly, we’ve also learned that it is very challenging to make the two teams work together. Both teams have a substantial fear:

• RPG team members fear they will need to learn PC programming or Web programming (or both). They are quite happy in their RPG comfort zone and don’t like the idea of rocking that boat.

• PC team members fear they will need to learn RPG and IBM i operations. Like the RPG team, these team members are also quite happy within their comfort zone.

Beyond substantial technical gulfs and ingrained fears, we’ve also learned firsthand that:

• Recalcitrant team members can dramatically impede an RPG application transformation. This is a critical point. Naysayers, with little appreciation for the big picture, can be very destructive.

• RPG and PC programming teams are often at odds with each other. For some shops this tension gurgles under the surface but for many it’s abundantly obvious. Like the naysayer, this friction can also be very destructive.

Understanding programming team differences

It’s usually very challenging to achieve the ideal goal of fully integrating your RPG and PC programming teams. However, it’s important to do what you can to motivate them to respect each other and acknowledge each others’ contributions.

One of the reasons your RPG and PC programming teams may be distanced is that in the past they’ve not had much need for each other. Another is that the two teams do very unrelated tasks-or at least work on very different parts of a project. There are also substantial technical differences between the RPG and PC programming teams. For example, you’ll likely encounter frustrations about:

• Database access. By now many RPG programmers are using SQL, but they didn’t for many years while creating your RPG application. It’s likely most of the database access in your RPG application uses RPG record-level-access model (ie, RPG operation codes such as CHAIN, READ, READP, etc). Your RPG programmers intrinsically understand RPG’s record-level access model. PC programmers will almost universally not know or understand record-level access and have a better knowledge about SQL.

• Web programming. In most cases, PC programmers are usually more directly involved with the Web and networking parts of your application and are therefore usually very familiar with Web programming. RPG programmers, spending most of their time with back-end RPG, tend not to know much about Web programming.

• Community knowledge . RPG programmers have a wealth of knowledge, in their aging, gray heads, about how your mission-critical RPG application works and runs the business. PC programmer tend to work on the outer edges of that core application. They probably have little or no knowledge of how your RPG application works-or even why it is so important.

• Developer operations. “DevOps” has emerged over the last three or four years to be critically important to PC developers. ( This video explains DevOps in just a few minutes). DevOps encompasses tasks such source control, application testing, integration testing, and application deployment. PC programmers will generally have some DevOps knowledge. RPG programmers may be familiar with source control, but are probably not as familiar with the full scope of DevOps as PC programmers.

Plan for negative reactions

As you discuss migrating your RPG application with your RPG and PC programming teams, plan for negative reactions from both.

• The RPG team will likely be critical of anything that is suggested to replace your existing RPG application. It’s been their sole domain for decades and as far as they’re concern it works just fine.

• The PC team will likely be critical of any replacement for your existing RPG application that doesn’t meet their ideal mental model of a replacement. As we said in this article, the PC team wants to use the latest tools and frameworks and aren’t focused on what the reality is of transforming millions of lines of RPG and CL to C#.

Integrating your programming teams with Monarch

A topmost tenet in a Monarch migration is that the migrated application produce correct results. Without correct results, all other efforts are for naught. One of the ways Monarch helps ensure correct results is by changing the least amount of code during the migration. It’s true that your RPG gets translated to C# and that is indeed one kind of change. But that translated C# uses Monarch idioms to ensure the established programming logic is not changed during translation.

Monarch idioms provide the path for the migrated C# application to work as it was originally designed to work. For example, some of these core facilities include:

• Display files: which use indicator-driven state management that couples them to program logic.
• Record level access: which provides the proven data file IO mechanism for program logic.
• Program calls: which provides a core means of separating concerns in the program logic.
• Indicators: Boolean flags that often govern program logic.

These idioms are coupled to C# through Monarch Framework abstractions. These are core concepts that your RPG programming team knows very well but will almost certainly, at least initially, cause your C# programming team a little friction.

On the other hand, there are C# idioms (exception handling, case sensitivity, an extensible type system) with which your C# team is very familiar—and these will surely cause your RPG team some friction. We’ve helped guide a lot of C# programming teams with Monarch migrations. By far, the most common issue we hear from these teams is that Monarch doesn’t produce “pure” or “standard” C#. It does! It may be doing so with idioms with which those teams aren’t familiar, but is very much standard C#.

It’s critical that your two programming teams be able to empower each other to eliminate the friction that each face. They are truly the best teachers for each other.