La exagerada muerte del RPG

Continuando lo dicho hace poco, y a propósito de lo mismo, sigue discutiéndose en un grupo de LinkedIn acerca de la insólita opinión de un editor sobre el RPG. Insólita porque quien declara la muerte de la principal herramienta del iSeries (AKA AS400) es el director técnico de la publicación que se dedica al iSeries. Insólita, porque se une a otras voces de su competencia, dando razón a sus argumentos. Mucho ya se ha anticipado, y se puede retomar a través de las discusiones enlazadas. Sin embargo, ahora quisiera destacar algunos de los argumentos positivos en favor del RPG que en esta más que interesante discusión se están desarrollando todavía.
Antes que nada, quiero destacar lo que Scott Klement ha dicho al respecto: cuando hoy se habla de RPG, se debe hablar de RPG IV, o ILE. Desde este punto de vista, el lenguaje no sólo se muestra muy activo, como pudiera decirse también de otros muertos de buena salud (COBOL) sino que además ha vivido una importante evolución respecto a sus antecesores (III, II) que lo convierten en una herramienta poderosa en el marco del iSeries. Como Scott ha dicho, decretar la muerte del RPG (ILE), es como declarar muerto al iSeries...algo que su competencia desearía, y está lejos de suceder (salvo que IBM esté dispuesta al suicidio).
Lo que sigue, son algunos puntos destacados en esta discusión:
Nathan Andelin sobre OOP:

Saying that RPG isn't object oriented is a red herring. OO is generally characterized by "encapsulation", "polymorphism", and "inheritance". By far the most prominent characteristic of OO is encapsulation, and nothing meets that characteristic better than ILE RPG.

It's not that RPG is not object oriented. It's just that polymorphism and inheritance are not as fully implemented in the compiler as in a language like Java. However, RPG programmers are free to implement their own interfaces that support polymorphism and inheritance to the degree of their choice. I've written about that in the past and posted sample code over the years. 

La referencia de Andelin a RPG y OOP es más extensa, y probablemente sea mejor ver pos separado. Invito por ahora a seguir su explicación, distribuída en más de una de sus intervenciones.

El mismo, sobre la potencia del RPG asociado al iSeries:

Our user interfaces are written in HTML, CSS, and JavaScript, while the majority of our server-side code is RPG. Following are some reasons one might consider using RPG for web applications:

RPG has more efficient database interfaces. Most applications NEED record level access as well as SQL for database I/O. RPG uses less CPU and I/O, has less latency, and performs much better than more mainstream languages, etc.

RPG web applications can maintain state just like 5250 applications, which takes a burden off programmers as well as garbage collectors. Users can even launch multiple instances of the same application without worrying about the state of each. Users can end jobs and free resources by clicking an Exit link.

You can launch RPG programs that perform database I/O and browser I/O and run under IBM i user profiles. You can use IBM i security interfaces to specify authorities of each. User IDs are automatically recorded in journal entries for changes made to IBM i databases and other objects.

RPG jobs can take advantage of IBM i workload management; utilizing subsystems, memory pools, run priorities, time slices, library lists, job descriptions, job logs, output queues, spool files, etc.

With RPG you can activate thousands of IBM i jobs to support thousands of concurrent users where each job can have its own runtime environment. Contrast that with so called “modern” languages that run under environments where you have to set up a separate virtual machine for each environment.

Workload management under IBM i is much more advanced and offers much more control than managing workloads with LPARS and comparable virtual machines. A hypervisor doesn't know the characteristics of workloads that run under a VM that it's managing. It may know whether a VM is requesting resources or not but it has no understanding of priority. IBM i is more effective at managing workloads.

Rather than setting up multiple virtual machines for separate organizations, or for separate development, test, or production environments, you can use separate subsystems, and separate library lists. RPG saves programming time, system administration, and computer resources, which ultimately saves money.

Giuseppe Tintor, sobre el uso de RPG en la capa servidora:

I use Java to write web application (jsp, servlet) but the databse access is done through RPG programs only; RPG il called from Java using pcml interface so I'm sure that the database is completly closed to external users and nobody can run sql, query or excel inquiries on files. None is aware that behind a web page there is RPG and none notice performance problems! I think that RPG is the perfect tool to manage database access on AS/400.  

 Una línea de discusión abierta sobre la capacidad del iSeries de sostener múltiples trabajos simultáneos toca no sólo al RPG, sino al soporte del propio sistema operativo; la comparación con un servidor Windows puede incomodar a administradores de éste servidor. A propósito de una pregunta de uno de los participantes (Is the concept of an active job in the IBM i the same as the concept of an “active job” in a PC server? As I understand it, one user in the IBM i is at least one job. In the PC world, one job can accommodate numerous users – dependent on the PC server’s resources, of course. (...) Tens of thousands? I know the IBM i QMAXJOB shipped value is 163520 but do you have experience with your system reaching that many users (tens of thousands) ? If I’m not mistaken, the client I work for only has a little more than 1500 users. Even then, their IBM i which is at V7R1 is already experiencing performance degradation. (I think I need to ask my manager about that again.) [preguntado a Andelin por Allan Roberto Garcia]):

You asked, "Is the concept of an active job in the IBM i the same as the concept of an “active job” in a PC server?"

It's a good thing that I reread your question a couple times and put some thought into it because I think I profoundly misunderstood it the first time.

At first, I thought you might be talking about the concept of a "process" under IBM i vs. a "process" under Windows. When you open Task Manager under Windows and navigate to the Processes tab you see a screen that looks fairly similar to the WRKACTJOB display under IBM i. Right?

Windows Task Manager shows you a list of .exe files "running". WRKACTJOB shows a list of "active jobs" under IBM i. I think you would find a lot of similarities between what an "active job" might be doing under IBM i, and what a Windows .exe might be doing. Wouldn't you agree?

One key difference would be that you would NEVER see tens of thousands of running .exe files under Windows. The runtime environment would be destabilized long before that could occur. But under IBM i, tens of thousands of "active jobs" would NOT be a problem.

So, while there may be many similarities between the work being done by Windows .exe files and IBM i active jobs, the design of the runtime environments are profoundly different. Windows cannot support complex workloads reliably. Complex workloads under Windows must be divided between multiple physical or virtual machines in order to run reliably (being generous with respect to Windows reliability).

One of our customers has more than 10,000 active jobs running daily on a 4-core, 32 Gig RAM IBM i server. Consider the number of active jobs that a 256-core, 8 Terabyte RAM IBM i server might be running.

Sorry for that analogy, or comparison. I don't think that's what you were really asking about. But I do think there is a relationship.

You say, "In the PC world, one job can accommodate numerous users – dependent on the PC server’s resources, of course."

Would that "one job" you're referring to be the ASP.Net server? It wouldn't have to be. It might be a PHP server. It might be a JEE application server. Actually there are many options.

Under the IBM i framework we use, one active job might be supporting multiple concurrent users. In that case, multiple concurrent requests might be queued. The program would be responsible for managing each user's state. There would be "restore state" and "save state" operations for each request.

Our framework also supports a "launch method" where a new job is loaded and run for each user who clicks on its associated menu item. We don't limit the number of menu items that a user may have "active" at the same time. User state is automatically maintained. The active job ends when the user clicks the "Exit" link.

We also support a launch method where a specific set of users may be supported by one active job; participants in a meeting for example. When the meeting ends, it ends for all users.

We run into use cases for each type of "launch method". They each have advantages and disadvantages. It's just nice to be able to support each.

I should say something about managing complex workloads under the IBM i native environment vs. application servers such as ASP.Net, JEE Application Servers, and PHP.

In the case of the latter, you will almost always find that the only way to scale those environments and make them run reliably is to separate them into multiple physical or virtual machine instances, and front end them with load balancers, which normally requires numerous skilled people to manage.

Under IBM i, we scale by launching active jobs into subsystems, each of which may be linked to separate HTTP server instances; possibly linked to separate client organizations; keeping their workloads separate.

Overall, IBM i workload management is WAY superior to load balancing between virtual machines.

La discusión aún continúa. Sólo he destacado algunos puntos. Otros, tales como el modelo OOP, o el desarrollo de aplicaciones web contra funciones servidoras RPG están desarrolladas, ejemplificadas, y ofrecen excelentes perspectivas. Una gran respuesta a quienes dan por muerto lo que no conocen.