Hypotetical scenario

Historically, IBM i worked mainly with RPG. Let us imagine a company which has a lot of legacy RPG fixed-form code. The company is not willing to convert its codebase in RPG free-form. In fact, the company wants to ditch RPG (because its talent pool is shrinking), but still wants to keep IBM i as its primary system (because IBM i has many advantages, security on top).

Here's the idea: the company plans to rewrite their entire RPG codebase in C/C++, in order to find more young programmers, thus future-proofing their system.

Here are my questions:

• does a rewrite from legacy RPG to C/C++ makes sense? With make sense I mean if such a rewrite can offer advantages in contrast of migrating to RPG free-form code;
• is C/C++, as a programming language, capable of creating software with all of the functionalities of the same software written in RPG?
• Why companies do not adopt this approach?
• What are, in the real world, some use-cases of C/C++ in IBM i?

Ishtar:

I will try to offer some opinions here. I've also reached out to additional IBM i colleagues to see if they can provide further details to fill in the gaps in my answers.

I am not an expert in RPG itself, but I would suspect a full rewrite of RPG into C/C++ might not always be the best solution in this case. With the flexibility of the ILE environment, if you can move legacy RPG to ILE RPG, then you have the possibility of rewriting certain RPG modules into C/C++ and continuing to build a single application. This allows for a targeted approach. I will say that my expectation would be that for any given RPG code the C/C++ code would be more verbose.

I would expect that you can do the same operations in C/C++ that can be done in RPG. I would expect that the C/C++ code would be more verbose due to the focused nature of RPG. 

Asking a general question about why a company would not adopt a path like this leads to all kinds of speculation. I think that for any project like this there are specific risks that can impact the cost and effectiveness of a translation. Clearly correctness is a big issue and the testing required to ensure that any translation is correct is a big part of the process. This is why I think a more targeted approach where certain parts of the application, perhaps those that change often, could be rewritten, helps to limit those risks and costs.

For real-world use cases I would need to defer to someone who has more direct customer contact than I do.

Hopefully this gives you some food for thought while waiting for some additional folks to chime in.

Even if the entire application is eventually rewritten in C/C++, I think that converting to free-form ILE RPG is a necessary first step. The converted code would be much easier to understand and modify.  Also, I think it would be easier to change monolothic RPG programs into more modular function-based RPG code than to go straight to a modularized C/C++ application. Moving RPG code out of a program into a function is a relatively simple thing to do, and any problems discovered in testing can be blamed on the change to use a function. If the change also involved writing that function in C/C++, it would be much more difficult to determine why the testcase had failed.

That said, I don't think there is anything that can be done in RPG that can't be done in C/C++, but some things that are easy in RPG are more difficult in C/C++. For example, #pragma mapinc must be used to get the layout of the records for externally-described files, but that is practically automatic in RPG: it is the default behaviour for a free-form file deifnition, and it only needs one byte ('E' = Externally-described) in the fixed-form file file definition.

There are some things that almost seem like magic to people who are not familiar with RPG, such as the way all the fields in a file are automatically available as program variables, which are automatically set from the I/O buffer during a READ operation, and automatically copied into the I/O buffer during a WRITE or UPDATE operation.

For example, this program reads the records from an imaginary database file, puts up a screen showing the current values of the fields, and then updates the database record with the changes from the user. 

Rewriting this program in C/C++ would require many more lines of code.

dcl-f dbfile usage(*update);  // Database file opened for update
                              // All the record formats are available (DBFMT)
                              // All the field names are available as program variables
                              // (FIRSTNAME, LASTNAME, ADDRESS, CITY, COUNTRY)
 
dcl-f screens workstn;        // Display file opened for input/output
                              // All the record formats are available (SCREEN, ...)
                              // All the field names are available as program variables
                              // (FULLNAME, ADDRESS, CITY, COUNTRY)
 
read dbfmt;                   // Read the first database record
dow not %eof;                 // Do while not end-of file   
   fullname = %trim(lastname) + ' ' + %trim(firstname);
   exfmt screen;              // Interact with the user (WRITE + READ)
   update dbfmt;              // Update the database record with the values
   read dbfmt;                // Read the next record
enddo;

*inlr = *on;                  // For a "cycle-main" procedure, 
                              // this causes files to be closed, set things up so everthing
                              // gets re-initialized for the next call, and returns from 
                              // the program

Hi Barbara, thank you for the reply.

I understand that the advantage of RPG is that it works seamlessly out-of-the box. In contrast, C/C++ is more DIY-prone.

What are then some scenarios in which using C/C++ is the best choice?

dcl-f dbfile usage(*update);  // Database file opened for update                              // All the record formats are available (DBFMT)                              // All the field names are available as program variables                              // (FIRSTNAME, LASTNAME, ADDRESS, CITY, COUNTRY) dcl-f screens workstn;        // Display file opened for input/output                              // All the record formats are available (SCREEN, ...)                              // All the field names are available as program variables                              // (FULLNAME, ADDRESS, CITY, COUNTRY) read dbfmt;                   // Read the first database recorddow not %eof;                 // Do while not end-of file      fullname = %trim(lastname) + ' ' + %trim(firstname);   exfmt screen;              // Interact with the user (WRITE + READ)   update dbfmt;              // Update the database record with the values   read dbfmt;                // Read the next recordenddo;*inlr = *on;                  // For a "cycle-main" procedure,                               // this causes files to be closed, set things up so everthing                              // gets re-initialized for the next call, and returns from                               // the program

Writing code in C/C++ for IBM i is a bit more challenging that doing it on other platforms, mainly because the libraries do not exist as they do on other platforms to help with certain tasks. The US government recently issued a mandate that anyone delivering application to government agencies should steer away for "unsafe" languages such as C/C++, I do not agree with that statement because careful and good programming practices remove some of the issues related to unsafe applications. However if this is an application that may be aimed at US government it should be a consideration. We write all of our IBM i products in C, this is more to do with performance that anything else, but we do have to be very careful with memory/pointer management (we are more of a tools provider than application provider). I firmly believe that the ILE environment is one of the best hidden gems of the IBM i, you can write the modules in the language that provides best benefits for the required function and mix and match as required. Take Matthews suggestion and replacing those programs that make sense with C and rewriting others in ILE free format RPG to get the best out of the system. This is not a single language system even though people always think of it as the system to use RPG on!  Look at what language suits the outcome and don't get fixated with one language or the other. 

Chris...