El IBM i y sus capacidades actuales

 Dice Mike Pavlak: “At the end of the day, professionally I’ve worked in about six different languages. I can write bad code in every one of them,”

El contexto de la afirmación es interesante: el conjunto de recursos que hoy dispone el IBM i (¿o debemos decir IBM Power? ) para interconectarse con toda clase de recursos: PHP, Node, Python, sumados a los viejos conocidos de c. c++. java. Pavlak enfoca y evalúa la conveniencia de cada uno en función de conexiones con arquitecturas web, fundamentalmente, pero ese abanico de posibilidades puede ir más allá sin duda.

Dice Pavlak en particular sobre Node: 

Node.js isn’t as easy to learn for true-blue IBM i types, but it has one advantage over the other two: it uses JavaScript, which as previously noted has been broadly adopted by the wider IT world. However, there’s a caveat to the notion that Node.js developers only need to know JavaScript to be productive.

“A lot of people like Node because there’s a myth that I can use the same language on the presentation layer, JavaScript . . . up on the server,” Pavlak said. “And there’s truth to that. The syntax of the language is the same. What’s different though is the library usage. The libraries you’d use on the client end are not the libraries you would use on the server.”

Choosing Node.js makes sense in certain scenarios, such as when an IBM i shop has hired younger developers with JavaScript skills. Because the syntax is the same, these front-end JavaScript developers may be able to become productive developing back-end Node.js code on the IBM i server in a shorter amount of time than using other languages. “Using Node on the backend starts to make sense in that scenario,”

(...) Node.js does have a significant performance advantage over PHP and Python in on particular category: How quickly the stack starts. The technology, which was created by Google, is widely used by massive Web properties, such as Netflix. When you fire up a Netflix session on your TV, your Roku, or your phone, you’re actually initiating the deployment of a Node.js instance running on AWS.

“Node.js starts so fast, it’s so much easier to scale…horizontally,” Pavlak said. “So AWS instances are basically X86. In that scenario, Node has a decided advantage.”

 

El concepto "Legacy" y la zanahoria "microservice"

 Lo que sigue es un artículo "viejísimo", del 25 de abril de este año. Lo copiaré y comentaré si es necesario, porque sigue siendo de rigurosa actualidad, tanto en el universo de IBM i, como en general:

Beware The Hype Of Modern Tech

Many IBM i shops are under the gun to modernize their applications as part of a digital transformation initiative. If the app is more than 10 or 15 years old and doesn’t use the latest technology and techniques, it’s considered a legacy system that must be torn down and rebuilt according to current code. But there are substantial risks associated with these efforts – not the least of which that the modern method is essentially incompatible with the IBM i architecture as it currently exists. IBM i shops should be careful when evaluating these new directions.

Amy Anderson, a modernization consultant working in IBM’s Rochester, Minnesota, lab, says she was joking last year when she said “every executive says they want to do containerized microservices in the cloud.” If Anderson is thinking about a future in comedy, she might want to rethink her plans, because what she says isn’t a joke; it’s the truth.

Many, if not most, tech executives these days are fully behind the drive to run their systems as containerized microservices in the cloud. They have been told by the analyst firms and the mainstream tech press and the cloud giants that the future of business IT is breaking up monolithic applications into lots of different pieces that communicate through microservices, probably REST. All these little apps will live in containers, likely managed by Kubernetes, enabling them to scale up and down seamlessly on the cloud, likely AWS or Microsoft Azure.

The “containerized microservices in the cloud” mantra has been repeated so often, many just accept it as the gospel truth. Of course that is the future of business tech! they say. How else could we possibly run all these applications? It’s accepted as an article of faith that this is the right approach. Whether a company is running homegrown software or a packaged app, they’re adamant that the old ways must be left behind, and to embrace the glorious future that is containerized microservices running in the cloud.

 The reality is that the supposedly glorious future is today is a pipe dream, at least when it comes to IBM i. Let’s start with Kubernetes, the container orchestration system open sourced by Google in 2014, which is a critical component of running in the “cloud native” way. (...)

While Kubernetes solves one problem – eliminating the complexity inherent in deploying and scaling all the different components that go into a given application – it introduces a lot more complexity to the user. Running a Kubernetes cluster is hard. If you’ve talked to anybody who has tried to do it themselves, you’ll quickly find out that it’s extremely difficult. It requires a whole new set of skills that most IT professionals do not have. The cloud giants, of course, have these folks in droves, but they’re practically non-existent everywhere else.

ISVs are eager to adopt Kubernetes as the new de facto operating system for one very good reason: because it helps them run their applications on the cloud. (...) 

For greenfield development, the cloud can make a lot of sense. Customers can get up and running very quickly on a cloud-based business application, and leave all the muss and fuss of managing hardware to the cloud provider. But there are downsides too, such as no ability to customize the application. For the vendors, the fact that customers cannot customize goes hand in hand with their inability to fall behind on releases. (Surely the vendor passes whatever benefit it receives through collective avoidance of technical debt back to you, dear customer.)

The Kubernetes route makes less sense for established products with an established installed base. It takes quite a bit of work to adapt an existing application to run inside a Docker container and have it managed in a Kubernetes pod. It can be done, but it’s a heavy lift. But when it comes to critical transactional systems, it likely becomes more of a full-blown re-implementation than a simple upgrade. There are no free lunches in IT.

When it comes to IBM i, lots of existing customers who are running their ERP systems on-prem are not ready to move their production business applications to the cloud. Notice what happened when Infor stopped rolling out enhancements for the M3 applications for IBM i customers. Infor wanted these folks to adopt M3 running on X86 servers running in AWS cloud. Many of them balked at this forced re-implementation, and now Infor is rolling out a new offering called CM3 that recognizes that customers want to keep their data on prem in their Db2 for i server.

Other ERP vendors have taken a similar approach to the cloud. SAP wants its Business Suite customers to move to S/4 HANA, which is a containerized, microservice-based ERP running in the cloud. The German ERP giant has committed to supporting on-prem Business Suite customers until 2027, and through 2030 with an extended maintenance agreement. After that, the customers must be on S/4 HANA, which at this point doesn’t run on IBM i.

Will the 1,500-plus customers who have benefited from running SAP on IBM i for the past 30 years be willing to give up their entire legacy and begin anew in the S/4 HANA cloud? It sounds like a risky proposition, especially given the fact that much of the functionality that currently exists in Business Suite has yet to be re-constructed din S/4 HANA. Is this an acceptable risk?

Kubernetes is just part of the problem, but it’s a big one, because at this point IBM i doesn’t support Kubernetes. It’s not even clear what Kubernetes running on IBM i would look like, considering all the virtualization features that already exist in the IBM i and Power platform. (What would become of LPARs, subsystems, and iASPs? How would any of that work?) In any event, the executives in charge of IBM i have told IT Jungle there is no demand for Kubernetes among IBM i customers. But that could change.

Particularmente interesante es el comentario acerca de los planes de Jack Henry & Associates:

Jack Henry & Associates officially unleashed its long-term roadmap earlier this year, but it had been working on the plan for years. The company has been a stalwart of the midrange platform for decades, reliably processing transactions for more than a thousand banks and credit unions running on its RPG-based core banking systems. It is also one of the biggest private cloud providers in the Power Systems arena, as it runs the Power machinery powering (pun intended) hundreds of customer applications.

The future roadmap for Jack Henry is (you guessed it) containerized microservices in the cloud. The company explains that it doesn’t make sense to develop and maintain about 100 duplicate business functions across four separate products, and so it will slowly replace those redundant components that today make up its monolithic packages like Silverlake with smaller, bite-sized components that run in the cloud-native fashion on Kubernetes and connect and communicate via microservices.

It’s not a bad plan, if you’ve been listening to the IT analysts and the press for the past five years. Jack Henry is doing exactly what they’ve been espousing as the modern method. But how does it mesh with its current legacy? The reality is that none of Jack Henry’s future software will be able to run on IBM i. Db2 for i is not even one of the long-term options for a database; instead it selected PostgreSQL, SQL Server, and MongoDB (depending on which cloud the customer is running in).

Jack Henry executives acknowledge that there’s not much overlap between its roadmap and the IBM i roadmap at this point in time. But they say that they’re moving slowly and won’t have all of the 100 or so business functions fully converted into containerized microservices for 15 years – and then it will likely take another 15 years to get everybody moved over. So it’s not a pressing issue at the moment.

Maybe Kubernetes will run on IBM i by then? Maybe there will be something new and different that eliminates the technological mismatch? Who knows?

The IBM i system is a known entity, with known strengths and weaknesses. Containerized microservices in the cloud is an unknown entity, and its strengths and weaknesses are still being determined. While containerized microservices running in the cloud may ultimately win out as the superior platform for business IT, that hasn’t been decided yet.

For the past 30 years, the mainstream IT world has leapt from one shiny object to the next, convinced that it will be The Next Big Thing. (TPM, the founder of this publication and its co-editor with me, has a whole different life as a journalist and analyst chasing this, called The Next Platform, not surprisingly.) Over the same period, the IBM i platform has continued more or less on the same path, with the same core architecture, running the same types of applications in the same reliable, secure manner.

The more hype is lavished upon containerized microservices in the cloud, the more it looks like just the latest shiny object, which will inevitably be replaced by the next shiny object. Meanwhile, the IBM i server will just keep ticking.

 Sin duda han habido cambios espectaculares en unos pocos años, los últimos cuatro o cinco, y existen herramientas y recursos disponbiles de gran potencia. Pero para una empresa o institucion en marcha, un cambio tiene que ser pesado con cuidado, evitando el riesgo de caer en el vacío. ¿Un cambio que requiere nuevas metodologías, nuevos lenguajes, nuevas platatformas, nuevas comunicaciones? ¿desarrollos con lo último de lo último, sin contar con la prueba de recursos robustos y experimentados por varios años?

Segunda ola de modernización en el System i

En tiempos de grandes reacomodamientos, el System i no está ajeno a esto, salvo que aceptara caer en la intrascendencia. Tras la ola de iniciales inclusiones, ahora el objetivo es mobile, escuchando a los clientes, como el artículo enlazado comenta (IBM i Fundamental Strategy Unchanged, Always Changing, Dan Burger). 

Hace ya mucho tiempo que IBM no es el motor de los cambios y tendencias tecnológicas. Aunque se debería decir mejor todavía, que el curso de los acontecimientos escapa actualmente a la voluntad de casi todos sus actores, y evolucionan (los acontecimientos) más rápidamente que la capacidad industrial de las compañías tecnológicas de marchar a su paso o adelantarse. Y sin duda este es el caso de IBM: recursos finitos de investigación, y tiempos de investigación y  desarrollo que quedan desactualizados por los acontecimientos.
Pero hay algo más...¿hasta qué punto la adopción de las nuevas tecnologías acompaña su surgimiento? ¿cuánto de lo que vemos como posibilidad es realidad?  ¿Cuántas empresas nacionales están al día, cuántas modificaron sus procesos a fondo? Probablemente se podríadecir que casi ninguna, o ninguna...lo que tenemos es una capa superior (¿o superficial?) de un puñado de aplicaciones modernas, apoyadas en una combinación, o mezcla, infernal de aplicaciones de las más variadas épocas y tecnologías. Y que a la hora de hacer una compra por el móvil, el logro de esa transacción depende de una cadena de sucesos originados por procesos de la generación anterior, o de dos , o de tres generaciones anteriores...
¿Dinosaurios? probablemente no; simplemente los tiempos del ciclo de vida de una institución (empresa final, compañia de software, la que sea) siguen un ritmo distinto a la acumulación actual de nuevas posibilidades.
Y así, el System i no escapa a esto, por su propio tipo de función.
Nota: Quizá el título de esta nota no es el adecuado. Probablemente mejor sería decir "modernización y realidad".

ERPs en el huracán

Insensiblemente, cada día, cada semana, cada año, estamos viendo conformarse cambios en el alcance de la tecnología informática, las comunicaciones y el manejo del conocimiento que marchan hacia un modelo que parece integrar todo con todo. Están quedando desactualizados todos los conceptos que por cuarenta años han regido cada disciplina vinculada al manejo de la información, y probablemente la mejor actitud ante esto sea mantenerse abiertos y atentos a las tendencias. Si la tecnología móvil incorporó en menos de una decena de años varios miles de millones de usuarios, el ya casi con nosotros Internet de las cosas promete romper todas las barreras y escenarios en que comunicación, tecnología y conocimiento aparecen asociados. Esta totalmente masiva apertura ha dejado en un terreno irrelevante la discusión por sistemas operativos, lenguajes, técnicas, recursos, y áreas de enfoque. Hoy nuestra pregunta sería: ¿qué podemos hacer, hasta donde podemos llegar?
 En el marco de estas fuertes transformaciones del manejo de la información, los llamados ERP también están siendo alcanzados: Tras haber alcanzado ayer nomás un estatus de emperadores reinantes en el mundo empresario, los actuales cambios los están recortando a jirones, ante nuevas necesidades y nuevas velocidades de respuesta. Los actuales ERPs sin duda son capaces de atender el ciclo central de grandes áreas de negocio, quizá especialmente en el mundo de las manufacturas y en el contable, pero su capacidad de flexibilizarse ante nuevas exigencias es muy baja.
Sirva esto de introducción al excelente artículo de Alex Woodie sobre este punto: Six Signs Of The Long, Slow Decline Of  ERP. Woodie habla de "declinación de los ERPs", no sólo desde el punto de vista de la empresa usuaria, sino también desde el propio interés del fabricante del software. Así, menciona seis signos de esta declinación:

• El costo de las licencias, por resistencia de los usuarios, y por la creciente competencia de otras alternativas, especialmente desde la nube
• La propia migración hacia la nube
• Los interminables costos de sucesivos proyectos.
• Las escasas novedades incorporadas (se puede decir que cada área ocupada por un tipo de ERP deviene un commodity).
• El movimiento del enfoque hacia nichos más lucrativos (léase Big Data).
• ...y la deconstrucción de las suites, especialmente debido a la aparición de nuevas soluciones enfocadas en áreas específicas.

 Woodie mide el impacto de la declinación del uso de ERPs en el área de su interés, los equipos de rango medio, particularmente el IBM i (AS/400 en un pasado remoto), suponiendo que una disminución de la importancia de este software traerá una caída paralela de los equipos en que este software se ejecuta. Me permito dudar de esta correlación: el universo del manejo de la información no se ha simplificado, sino todo lo contrario, y difícilmente una empresa delegará todo su patrimonio a ninguna nube, salvo que sea propia.
Hay que pensar todo de nuevo...

Nuevas capacidades del System i (AKA AS400)

Se llame System i, AS400, o cualquier otro nombre intermedio, el i no es un equipo estancado, sino todo lo contrario: robusto como siempre, y evolucionado al paso de las tecnologías. Como un breve recordatorio, Alex Woodie, en The Four Hundered, enumera las nuevas características sumadas entre 2014 y 2015:

1. Native Flash Storage

IBM added support for native flash storage in the latest round of technology refreshes, which were IBM i 7.1 TR 10 and i 7.2 TR 2. This enables native use of solid state drives (SSDs) based on flash technology.

Prior to this, getting flash storage running on an IBM i-based Power Systems server was accomplished by way of the Virtual I/O Server (VIOS). Not all IBM i shops are thrilled with VIOS, which is an AIX program and can muddy the troubleshooting of performance issues. Thanks to VIOS and the overall adoption of virtualization in the IT world, there are rumblings from the natives that we've gotten too far away from the data.

But thanks to native support for flash, IBM i shops can now benefit from the ridiculous performance boost that NAND technology can deliver, especially for busy IBM i applications that are I/O bound with traditional DASD. And it can do so without going down the VIOS/AIX rabbit hole, which still looks intimidating to smaller shops.

2. Row and Column Access Control

This security feature was added with the release of IBM i 7.2 in 2014 to prevent unauthorized users from accessing huge swaths of data. As IBM's DB2 for i guru Mike Cain explains, RCAC was added at the request of IBM i customers to protect sensitive data.

"Prior to RCAC, the security scheme was provided through the object-based security measure," Cain says in this video on the RCAC Redbook landing page. "This really means that someone. . . could get access to all of the rows or records, or they would have no access to the row or file."

Since there was no prior way for DB2 for i to subset the record access--absent defining it at the application level, which leaves the data vulnerable still to ODBC/JDBC--IBM built it, and that's RCAC. "DB2 for RCAC provides a new and robust solution that allows for the governance and control of data through all interfaces, whether those interfaces are SQL or whether they're native record-level access," Cain says.

Simply put: If you need to dole out data based on a user's specific role and don't want to completely rebuild your database schema to prevent snooping, then you need RCAC, which means you need IBM i 7.2.

3. JSON

IBM added a technology preview for JavaScript Object Notation (JSON) in IBM i 7.2 TR2 and IBM i 7.1 TR10, which shipped in the spring.

JSON is a lightweight, human-readable data format that's become the default way that Web applications store and share data. Compared to XML--which 10 years ago paved the way toward self-definable data--JSON is both easier for programmers to use and faster to load.

Considering the rising adoption of JavaScript frameworks like Dojo, Ext JS, and jQuery among IBM i developers for front-end Web development, it was a natural for IBM i to add support for JSON in the database. (While JavaScript doesn't require JSON, there are advantages to using them in combination.)

The JSON Store Technology Preview that IBM shipped with the latest TRs allow JSON documents to be stored and retrieved using DB2 for i database tables. For a good primer on the three ways developers can utilize JSON, check out this recent developerWorks article.

4. Node.js

IBM unveiled support for last October with IBM i 7.1 TR9 and IBM i 7.2 TR1.

You're probably aware of how JavaScript can accelerate development of Web clients. The frameworks mentioned above bring a host of out-of-the-box UI widgets that developers can easily drop into their development environment. What Node.js does is extend that ease-of-use to the server. Node.js (or simply "Node" to those in the know) is an open-source runtime environment for server-side applications written in JavaScript. The framework has been widely adopted because it takes much of the complexity out of building and running scalable, data-intensive Web applications.

The addition of Node.js is a good example of IBM reacting to changing trends in application development (the addition of support for Ruby is another example). To learn more about Node.js, check out Aaron Bartell's LinkedIn story about his first experience with the framework.

5. REST Web Services

IBM's support for Representational State Transfer (REST) Web services, which IBM shipped in December with the group PTFs for IBM i 7.1 TR9 and IBM i 7.2 TR1, can be grouped into the same vein as JSON and Node.js: Keeping the platform relevant to a new class of developers and a new programing style.

If JSON has become the defacto data integration standard on the Web (largely replacing XML), then REST has become the defacto program integration standard for Web-based applications--largely replacing the XML-based service oriented application protocol (SOAP) that came before it.

If you want to connect your IBM i app so it can talk to hosted cloud service, such as Salesforce or Netsuite, you're going to be doing it via REST. IBM i developers who want to keep their apps current would do well to adopt REST, not only to partake of the rich ecosystem of REST-enabled services that are already out there, but to contribute back to it too.

Como se ha dicho otras veces, el problema no es el 400, sino la apertura de ideas de quienes toman decisiones sobre su uso. Usado como servidor, suele quedar atado al criterio más bien conservador en el manejo de la lógica de negocios escrita en los servidores.

Java en el System i

La JVM de IBM vs el JDK clásico. Cap 13, pag 591

Continuando el comentario (y recomendación de su  lectura) del Red Book sobre modernización del System i, dos palabras sobre Java en  el i.

Siempre se discute la lentitud de Java y su manejo de espacio de memoria, pero deberíamos decir que esto depende mucho  de la implementación y del aprovechamiento de las herramientas disponibles. Particularmente, IBM ha hecho un cambio radical en la JVM: el reemplazo por la implementacion de IBM,  Por experiencia, hemos pasado por casos que comenzaron con fallos y caídas, y fueron ajustados y optimizados hasta pasar a un funcionamiento absolutamente normal. En el capítulo 13 del red book, se comenta sobre la lentitud de Java (13.3.2 Myths surrounding Java: Java is slow)

Is Java really slow? It depends on what you compare it to. (...) you must choose the correct tool for the job. If what you need is high performance, you must select a lower-level language, such as C/C++ or RPG, but if you are dealing with huge and complex applications, it might be better to use a language with more flexibility, such as Java.
The reputation for slowness that Java usually carries is related to the JVM and not the language itself. The Java language is dependent on multithreads and large amounts of memory. Many people who are accustomed to running other languages starve their Java applications, which causes terrible performance. On the IBM side, the Classic JVM was not designed for IBM POWER architectures. It was ported from the original Oracle version, which resulted in performance issues. However, IBM Technology for Java is designed for the platform and it has been highly optimized by IBM to leverage the Power architecture. With this new version of Java, you can take advantage of the multithreading nature of Java, which was not possible before. Lastly, processor technology has improved greatly over the past few years. Processors are geared toward multithreading, which is a significant boost to Java based applications. 

Disponible desde 1998, ha pasado mucho desde su introducción en el System i, progresando hasta ser hoy una alternativa confiable. IBM comenzó ofreciendo soporte a la JVM clásica de Java, hasta que decidió atacar los problemas de adecuación a la plataforma, desarrollando su propia versión, tanto de un conjunto de clases y servicios que explotan los recursos nativos del equipo (IBM Toolbox for Java), como de una propia JVM, que ajusta la versión clásica desarrollada hoy por Oracle:

Java on IBM i can take advantage of the 64-bit architecture of the systems to provide a scalable solution from single processor machines all the way up to multiprocessor machines. The Classic JVM was unique in its implementation of asynchronous garbage collection, which allowed the JVM to continue processing application requests during the garbage collection cycle.
Nevertheless, this uniqueness of the Classic JVM became a disadvantage. For many developers and vendors, it required much work to port their applications to the IBM i, which disabled the portability features of the Java platform. This also resulted in more expenses to IBM and slower releases of the new Java versions and updates. In addition, the Classic JVM was based on porting code that was not tuned to the features built within the IBM PowerPC architecture. Starting in V5R4, IBM i started to move away from the Classic version of Java and support for Classic is now stabilized. Today, Java is delivered on IBM i only through the IBM Technology for Java version.  (...) Initially the IBM Technology for JVM was implemented only on 32-bit architecture, but since IBM i 6.1, the 64-bit version is available for use. This gives more flexibility for developers, allowing them to fit the JVM according to their needs.

Este es un aspecto importante a tener en cuenta: las nuevas ediciones del sistema operativo implementan sólo la versión de Java de IBM. Así, Java 7 es implementada solamente en la versión de IBM. Sin embargo, esto no debería alterar la ejecución de código, sino explotar la posibilidad de usar de manera nativa servicios y posibilidades del sistema operativo y de la base de datos. El "IBM Toolbox for Java" y su equivalente open source JTOpen ofrecen un excelente medio de interactuar con los recursos del sistema.

En nuestro caso, el desarrollo de aplicaciones web con Webclient, que utiliza java como capa intermedia, nos ha dado oportunidad de comprobar la posibilidad de usar java sobre el System i. Básicamente, nuestras aplicaciones se ejecutan sin diferencias (salvo extensiones que concientemente explotan facilidades del sistema) sobre servidores Websphere en System i, iSeries o como se le llame, y sobre servidores Tomcat o Jetty (en este caso sólo para pruebas). Y quisiera decir que, además, las herramientas de análisis de problemas y performance que Websphere ofrece, son superiores al momento de tener que estudiar problemas. Probablemente, la posibilidad de usar Java nativamente es una de las mejores garantías de modernización y explotación del equipo, convirtiéndose en un puente entre el mundo móvil, web y de recursos infinitos que propone IOT, y la potencia de procesamiento y de manejo de datos del i.

Qué va de un AS/400 a un System i

Aunque el lanzamiento corresponde a mediados del año pasado, la cuenta de Google+ de IBM Red Books, volvió a destacar una publicación de mucho interés en estos últimos días: Modernization Redbook has been published!. El comentario refiere al Red Book "Tools and Solutions for Modernizing Your IBM i Applications", editado en septiembre de 2014, y renovado ahora. Este libro contiene información de servicios y características del System i, pero particularmente la descripción de implementaciones de distintos socios de negocios de IBM. Este texto merece ocuparse de él, pero ahora lo que particularmente me interesa es la entrada de blog que aparece relacionada: "Modernization Redbook has been published!". Porque esta entrada, de junio de 2014, comenta un red Book que es la base de "Tools and Solutions...". Se trata del libro "Modernizing IBM i Applications from the Database to the User Interface and Everything in Between ", y éste sí es especialmente interesante, fundamental. En este texto se explica qué ha cambiado, y qué es posible hacer hoy con un System i. Realmente, mucho ha pasado entre el inicial AS/400 y su continuidad actual.
El libro tiene toda una primera parte donde habla de modernización, un aspecto especialmente requerido en entornos de AS400, en los que es frecuente encontrar cierto conservadorismo en el uso del equipo. Quizá no en general, donde el área de IT podría estar actualizado, pero sí en el área del AS400. Probablemente la propia ventaja de que pueden ejecutarse aún antiguas aplicaciones migradas de versiones anteriores de IBM (S/36, S/38 y más) tiende a mantener un ambiente que no cambia lo que funciona. Y lo mismo sucede en parte con el horizonte de los recursos humanos involucrados. Por lo tanto, la minuciosidad de las explicaciones en el terreno de la modernización, son entendibles.
Pero el resto del libro es material más que útil, destacando los nuevos servicios que el System i dispone, lo que lo hace distinto a sus orígenes:
El ambiente integrado de lenguajes (ILE), que permite interactuar entre distintos lenguajes disponibles en el equipo. A través del libro se explican distintos casos de aplicación del ILE. Es fundamental entender las posibilidades del ILE  para la explotación del equipo, por ejemplo, desde el punto de una arquitectura SOA.
Java, PHP, Ruby on Rails integrados. La disponibilidad de lenguajes capaces de trabajar para arquitecturas web, o articulables sobre múltiples plataformas, ha abierto completamente las posibilidades del equipo.
Servicios de administración de datos extendidos (data centric development). Desde el lejano inicio del DB2 sobre el AS400, las posibilidades de trabajo con la base de datos han cambiado y mejorado radicalmente. Nunca me he quejado de la eficiencia de DB2 en el AS400, pero los ajustes que se hacen sobre el ahora System i extienden su excelente servicio a las actuales necesidades de grandes bases de datos (Big Data).
El libro describe esta evolución así:

The original database designs might have come from an S/36 environment. This origin implies that the files are programs that are based on a flat file design. If the design is from the S/38 or early days of the AS/400, chances are that the database design was created one time and has lost any resemblance to that original design over time. Programmers can be good at adding a function or extending something after they do only a cursory review of the effect to the overall design. Although these designs continue to work on IBM i, neither approach takes full advantage of the power of DB2 for i.
Since the announcement of the AS/400, 25 years ago, IBM has continued to add new features and new functions to the database with each new release and technology refresh. A contemporary design is critical to take advantage of these new functions and to experience the performance improvements inherent in the updates. It is time to look at a data-centric view of development (...)
One of the most important improvements to the database over the years is the advancement of SQL. When we talk about a modern database, SQL is a requirement. This is not to suggest that native database access should be forbidden, but instead that it should use the correct tool for the job.
Traditional record access for small data sets can be effective. But, as data sets become larger, the effectiveness of native access can diminish. Additionally, your applications are required to take more responsibility for processing data across multiple tables. This processing can lead to complicated application code that can cause performance issues.
This situation is where SQL must be used. The beauty of SQL is that it uses the system or operating system versus the application. Many complicated data access routines can be replaced by SQL, which allows the system to figure out the indexes that make the most sense to retrieve the wanted data. The SQL engine on IBM i has undergone significant development focus over the past few years. The database has become better at creating and maintaining indexes to optimize your data access. The more records that you need to process, and views you need to combine, the better SQL can perform. In addition to the optimized indexing, SQL can use the multi-threading capabilities of the system without causing RPG and COBOL program (which are single-threaded) issues.

El i está abandonando definidamente el enfoque que siempre mantuvo sobre la base de datos, orientada a la recuperación de filas (orientada a registro - READ/WRITE) para adoptar el punto de vista de la orientación a sets de datos, dando prioridad al SQL. IBM  está recomendando abandonar la creación de tablas mediante DDS para hacerlo con DDL.
Este es un punto donde Plex debe actualizarse, acompañando esta "revolución copernicana" en el manejo de datos. Notablemente, Plex es capaz de generar código SQL, pero lo hace para variantes ODBC/JDBC, dando prioridad en las variantes de servidor/400 (RPG400, RPGIV, SQLRPG400, SQLRPGIV) a la "orientación a registro". No es que no se pueda explotar este cambio en Plex, pero exije un grado de intervención manual que no debería tener, dado que tiene los elementos necesarios para otro enfoque. Entre las modificaciones solicitadas por los usuarios, algunas de las más importantes se concentran en este área (generación de DDL, explotación a fondo de SQLRPGIV).
Otros aspectos del cambio en el System i son los relacionados con SOA y Servicios Web, Sevicios XML, Soporte de servidores Web, Soporte de Cloud, enlace con aplicaciones móviles...
Pero esto será para conversar en la siguiente oportunidad. Por ahora, hasta aquí.

7.ª conferencia mundial de Plex/2E:

Se publicó ayer la agenda de la séptima conferencia mundial de Plex, programada para el primero de junio, hasta el cinco. Como es usual, habrá un buen número de sesiones a cargo de usuarios y socios de negocios, algunas de ellas en castellano. De entre ellas, quisiera destacar algunas relacionadas con web, movilidad y servicios web:

Developing Mobile and Web UX Workshop, a cargo de Abram Darnutzer y Andrew Legget, de CM First, acerca de la extensibilidad de Plex a aplicaciones móviles:

Do you need to extend your legacy Plex app to mobile, but aren’t sure how to get there? Join us for some hands on training for developing multi-channel responsive HTML5 apps that can be deployed to desktop browsers and mobile devices. We will have exercises and detailed information on everything you need to be successful: everything from geolocation, camera imaging, social auth, native app store wrapping techniques, offline storage, device specific capabilities and more. You will leave with a working Order Processing and Delivery app that can be used off-line.

REST API’s in a CA Plex Context, presentada por Lorenz Alder, de CM First, introduciendo probablemente uno de los temas de mayor interés desde el punto de vista de arquitecturas:

This presentation first discusses general aspects of web API design and give some guidance and best practices. We will then focus on RESTful API’s and answer questions like: What is RESTful? What is HATEOAS? What is RPC? and try to find a pragmatic approach to RESTful or REST based API’s. In the last section we will talk about the status quo of the CA Plex generators and how they fit into the REST paradigm and show some ways to move from a client server centric perspective to a web perspective.

HTML5, The Future for App Development, Keynote del equipo de Sencha:

This session will provide a side-by-side comparison of developing a multi-channel, multi-platform application in HTML5 relative to a siloed or native development approach. The presenter will explore not only development issues, but application deployment, testing, and on-going maintenance issues as well.

En las sesiones de 2E se discutirá, en 2E Training Workshop (What’s new in r8.7?), un tema que espero ver también disponible en Plex tan pronto como sea posible: la extensión del manejo de las características del SQL en DB2, algo que parece incluír en el release incremental 7.2, si leo bien el anuncio ("the new features in CA Plex r7.2 Incremental Release 1 that help enable these goals"):

Do you want to move from a traditional DDS database to an SQL-type database, and still continue using your existing application? Do you want to use meaningful names on your SQL/DDL databases instead of implementation names? Do you want to be able to generate SQL/DDL type objects into any library of your choice? These are now possible with the latest release of CA 2E – r8.7. Our CA Staff will walk you through the important features of CA 2E 8.7 and also have a hands-on session to try out these new features.

De destacar también , varias sesiones acerca de la variante .NET,  facilidades de productividades en la IDE de Plex, o , especialmente, algunas dedicadas a vincular el desarrollo de aplicaciones Plex o 2E con ofertas de infraestructura de CA, con algunos aspectos de mucho interés (estoy tratando de seguir la vinculación de 2E/Plex con  CA API Gateway -sesión CA 2E – A player in the AppDev Strategy).
Sorprendentemente, no veo ninguna sesión organizada por los desarrolladores de Websydian. Es particularmente curioso porque han participado en la preparación de la conferencia, hasta donde conozco.

En fin, un conjunto de sesiones que apuntan a problemas bien actuales. No está mal.

Plex en el System i

Y a propósito de modernización en el System i (o 400, o iSeries, o...), ¿cómo está Plex? En un breve inventario, podemos decir que el RPG ILE  está soportado, así como el SQL ILE RPG. Pero construcciones complejas no lo están, tanto en cuanto a las posibilidades extendidas del ILE (Integrated Language Environment) como en cuanto a la generación de servicios disponibles en alguna plataforma (servicios web, tal como hoy es posible usar WCF en .NET, especialmente), o deseables por su propia importancia, como las extensiones para acceso web, móvil, el soporte de cloud computing, la ampliación del uso del SQL, la integración con Linux, Mac, Windows... ¿qué hay del soporte de PHP, Ruby, o la inclusión de Node.js en el sistema?
Algunas de estas características o facilidades están ya disponibles a través de terceros: CM First permite mover desde el System i a aplicaciones web y móviles tanto modelos de 2E como de Plex, así como se lo puede hacer con Websydian. Servicios web fueron abordados ya hace tiempo por Websydian. En cloud computing  CM First ha iniciado desarrollos con EC2 DE Amazon. Existen múltiples patrones desarrollados por miembros de la comunidad de Plex, tanto para el uso de SQLRPG, como para el uso de servicios web, entre otros. Desarrollos corporativos a veces compartidos y a veces apenas conocidos por la comunidad de usuarios.
Pero lo más importante es que existen varias solicitudes en curso de actualización del soporte de ILE, que aparecen como candidatos a ser incluídos inicialmente en la versión 7.2, aunque más probablemente en la 8. Entre ellas, una ampliación de la generación de código para SQLRPG, el manejo de datos varchar, el paso de la creación de DDSs a DDL. ¿REST? En algún momento Simon Cockaine preguntó a la comunidad sobre su uso, lo que puede incluírlo o no.
Visto en conjunto, una respuesta irregular pero no muy lejana de las posibilidades de la plataforma. El uso del API del OS/400 permite un flexible acceso a los recursos, aunque se extraña una respuesta más avanzada de quienes debieran conducir el producto.

Futuro del 400..(o como se llame en 2020)

Linea de tiempo planificada para el System i - (En IBM System Magazine)

Steve Will, Arquitecto Jefe del System i,  publica en IBM System Magazine (30 de marzo) un artículo explicando la planificación de futuras versiones del System i (AKA AS400, i Series, System i...), que extiende el ciclo de vida de los sistemas hasta dos próximas versiones como planes inmediatos, llevando su ciclo de vida hasta más allá de 2025: la corriente versión aparece planeada hasta 2020/2021, y confirma que están trabajando en dos siguientes versiones (Next i+1/Next i+2). La primera, con cambios que expanden características ya en desarrollo, y la siguiente, determinada por cambios mayores no contenibles en la primera.

(...) we have two major releases under development right now. The 7.2 release came out less than a year ago, and we’ve been working hard on its following major release – called “i next” on this chart. But, we have items that we know cannot fit into “i next” but which require a major release, so we are working on the one after that, “i next +1.” 

 Lo más importante del artículo de Will es la indicación del compromiso de IBM con el sistema, y de su potenciación en el marco de la evolución tecnológica actual:

The key to understanding this next chart is to recognize when there is a known, committed date and when there is just a direction. A known date is represented when the horizontal line has a vertical end. For example, IBM i 6.1 was released in 2008, and its announced end of service is in 2015; both ends of that line are vertical. But while IBM i 7.2 came out in 2014 (vertical left end) the end of service date is indicated by an arrow, meaning we have not announced anything.

However, if 7.1 and 7.2 are each supported as long as 6.1 and V5R4 were, then 7.2 is going to be supported out into the 2020s.

And, very importantly, I told you that we have two more releases actively under development right now. When will they be released? Well, the ends of those lines are arrows, so we’re not saying yet. The availability dates could still change, but clearly, we don’t tend to deliver new releases any sooner than two years these days, and sometimes it’s longer than that. So, “i next” and “i next +1” will come out sometime, and if they also are supported for seven years, well, we’re more than 10 years out into the future now.

Furthermore, on the previous chart, we discussed that new capabilities are coming out in between releases. This means that the “Support” chart does not indicate only “support” but also a timeline for delivery of new function via TRs.

 Frente a la socarrona afirmación (repetida frecuentemente) de la obsolescencia del equipo, creo que realmente tendríamos que pensar más en la obsolescencia de las perspectivas con que se planean desarrollos sobre la plataforma: cada vez me siento más inclinado a abandonar definitivamente cualquier referencia al "400", considerando la distancia entre aquello que estaba disponible en el 400 hace veinte años, y lo que es posible hacer hoy en el "i":

We’re adding new capabilities in virtualization, cloud, I/O, DB2, mobile, open standards and much more. Staying current with new technology is a clear indication we are investing and plan to be around for a long time.

Lanzamiento del nuevo release Plex 7.2

Ayer CA comunicó la disponibilidad del release 7.2 de Plex. Mucho se ha conversado sobre qué incluiría, pero nada es adelantado en el anuncio. Lo que sí es adelantado es algo ya conocido, pero igualmente muy prometedor: la adopción de una política de releases incrementales rápidos, y con participación directa de todos aquellos clientes que deseen sumarse al plan:

The CA Incremental Release Program is a customer-interactive delivery model where new product features are developed and released using the Agile development methodology. CA’s development teams work closely with customers to create product features for rapid implementation. Rather than spending years building a software release full of features, we work with customers and release features incrementally, as they are completed.

El lanzamiento de la versión 7.2 es una confirmación de esta política, acortando todavía más los tiempos de entrega ya vistos entre la versión 7.0 y 7.1.
De la documentación inicial se desprende que el grueso de los cambios se concentran en la variante .NET y en WCF Service Connectors, el agregado de soporte para Oracle 12, y la esperada actualización del soporte de Visual Studio...2010. Se afirma que es posible el soporte de versiones superiores, pero no está testeado (VS 2013). En cuanto a Java, continúa soportado hasta la versión 7 (ya existente en 7.1) y en cuanto a OS400, el soporte alcanza a IBM i 7.1.
Evidentemente, hace falta la participación de la base de clientes, si queremos ver otras nuevas características disponibles.
Plex 7.2 en la wiki oficial (CA).
Lista de fixes en la wiki oficial de Plex.
Matriz de compatibilidad de Plex 7.2 (requiere usuario).

IBM: Liderazgo en fuga?

IBM 360, en computerhistory.org

Adam Hartung, en Forbes, comenta la evolución financiera y de bolsa de IBM reciente, poniendo en evidencia la errática conducción de la corporación, y su inexplicable estrategia...Hartung pone en el centro de sus decisiciones descaminadas, la baja de su inversión en investigación, lejos de lo que fuera por décadas, y la recompra de acciones, incluso recurriendo a endeudamiento. Hartung apunta a un problema de conducción de la empresa, focalizando en su actual CEO, aunque probablemente podamos hablar de más tiempo...

Why You Don't Want to Own IBM
IBM just finished a tough week.  IBM fell 2% after announcing earnings on Wednesday, dragging the Dow Jones Industrial Average (DJIA or Dow) down over 100 points.  And as the Dow reversed course to end up 2% on the week, IBM continued to drag, ending down almost 3% for the week.
Of course, one bad week – even one bad earnings announcement – is no reason to dump a good company’s stock.  The vicissitudes of short-term stock trading should not greatly influence long-term investors.  But in IBM’s case, we now have 8 straight quarters of weaker revenues.  And that HAS to be disconcerting.  Managing earnings upward, such as the previous quarter, looks increasingly to be a short-term action, intended to overcome long-term revenue declines which portend much worse problems.
This revenue weakness roughly coincides with the tenure of CEO Virginia Rometty.  And in interviews she increasingly is defending her leadership, and promising that a revenue turnaround will soon be happening.  That it hasn’t, despite a raft of substantial acquisitions, indicates that the revenue growth problems are a lot deeper than she indicates.
CEO Rometty uses high-brow language to describe the growth problem, calling herself a company steward who is thinking long-term.  But as the famous economist John Maynard Keynes pointed out in 1923, “in the long run we are all dead.”
Today CEO Rometty takes great pride in the company’s legacy, pointing out that “Planes don’t fly, trains don’t run, banks don’t operate without much of what IBM does.”  But, powerful as that legacy has been, in markets that move as fast as digital technology any company can be displaced very fast.
Just ask former CEO Scott McNealy and his leadership team at Sun Microsystems.  Sun once owned the telecom and enterprise markets for servers – before almost disappearing and being swallowed by Oracle in just 5 years (after losing $200B in market value.)  Or ask former CEO Steve Ballmer at Microsoft, who’s delays at entering mobile have left the company struggling for relevancy as PC sales flounder and Windows 8 fails to recharge historical markets.
Managing earnings is not managing for long-term success
CEO Rometty may take pride in her positive earnings management.  But we all know that came from large divestitures of the China business, and selling the PC and server business to Lenovo.  As well as significant employee layoffs.  All of which had short-term earnings benefits at the expense of long-term revenue growth.  Literally $6B of revenues have been sold off just during her leadership.
Which in and of itself might be OK – if there was something to replace those lost sales.  Even if they didn’t have any profits – because at least we have faith in Amazon creating future profits as revenues zoom. But IBM was far late to the cloud, and hasn’t shown it has anything to leapfrog industry leaders.
The REAL problems – R&D cuts, higher debt, massive stock buybacks
What should terrify investors about IBM are two things that are public, but not discussed much behind the hoopla of earnings, acquisitions, divestitures and all the talk, talk, talk regarding a new future.
CNBC reported that 121 companies in the S&P 500 (27.5%) cut R&D in the first quarter.  And guess who was on the list?  IBM, once an inveterate leader in R&D, has been reducing R&D spending.  The short-term impact?  Better quarterly earnings.  Long term impact????
The Washington Post reported more this week about the huge sums of money pouring out of corporations into stock buybacks rather than investing in R&D, new products, new capacity, enhanced marketing, sales growth, etc.  $500B in buybacks this year, 34% more than last year’s blistering buyback pace, flowed out of growth projects. To make matters worse, this isn’t just internal cash flow spent on buybacks, but companies are actually borrowing money, increasing their debt levels, in order to buy their own stock!
And the Post labels as the “poster child” for this leveraged stock-propping behavior…. IBM.  IBM

“in the first quarter bought back more than $8 billion of its own stock, almost all of it paid for by borrowing. By reducing the number of outstanding shares, IBM has been able to maintain its earnings per share and prop up its stock price even as sales and operating profits fall.

The result: What was once the bluest of blue-chip companies now has a debt-to-equity ratio that is the highest in its history. As Zero Hedge put it, IBM has embarked on a strategy to “postpone the day of income statement reckoning by unleashing record amounts of debt on what was once upon a time a pristine balance sheet.”

In the case of IBM, looking beyond the short-term trees at the long-term forest should give investors little faith in the CEO or the company’s future growth prospects. Much is being hidden in the morass of financial machinations surrounding acquisitions, divestitures, debt assumption and stock buybacks. Meanwhile, revenues are declining, and investments in R&D are falling. This cannot bode well for the company’s long-term investor prospects, regardless of the well scripted talking points offered last week.

Migrando a System i 7.1

En un proyecto en el que trabajo, en poco tiempo más (midiendo en meses) migraremos un conjunto de sistemas IBM i (AKA AS/400, iSeries, al menos en su base), de 6.1 a 7.1, mientras que IBM ya anuncia i 7.2 . El cambio no representa  inconvenientes mayores: probablemente no haya demasiado que tocar en aquellas aplicaciones que generamos con Plex, que básicamente no debemos recompilar ni tampoco rehacer código.Únicamente deberíamos asegurarnos de que ningún API usada o procedimiento de lenguaje de control pudiera entrar en conflicto por obsolescencia. De acuerdo a la información adelantada por IBM, los problemas no vendrían por este lado. Es casi seguro que podremos seguir trabajando todas nuestras aplicaciones RPG, sus APIs, y nuestro CLs, sin modificaciones.
En cambio, tenemos asegurado trabajo de revisión con Java, quizá el área de mayores novedades en el software incluído para la versión 7.1, ya que, si consideramos que nos movemos desde 6.1, debemos tener en cuenta que la nueva versión abandona la máquina virtual estándar de Java (esta parte tampoco nos afecta, porque Websphere 7.0 ya la usa), y utiliza sólo la propia de IBM (J9). Esto sí requiere análisis y tests para aquellas aplicaciones que no se ejecutan con Websphere.  En el caso del servidor de aplicaciones, que es el que usamos relacionado con Plex, estimo que podremos mantener inicialmente la versión 7 de Websphere, que ejecuta Java 6, pero en algún momento debemos pensar en subir su versión a 8.1, que usa Java 7. Y esto implica que también deberemos planear la migración de Plex a 7.1. No es obligatorio, ya que podríamos mantenernos como hasta ahora, pero debemos pensar que también podemos llegar a estar presionados por los cambios en Windows, de 7 a 8.
A pesar de todos estos movimientos, no es mucho lo que impacta en nuestras aplicaciones, que se mantienen con cierta holgura en estos movimientos de versiones. Más bien, lo que debemos repensar es qué cosas podríamos reenfocar, sacando provecho de las nuevas posibilidades: gran parte de los cambios se manifiestan como extensiones. Mayor es el peligro si habláramos de dependencia de Windows, ya que el paso de 7 a 8 sí apunta a un cambio de arquitectura mayor. Pero de estos inconvenientes podemos hablar mejor en otro momento.
Dany Burger, en The Four Hundered, dedica un interesante artículo a los problemas de migración de i 6.x a i 7.1 y 7.2, que me motivaron a chequear nuestros propios riesgos a futuro. Como en otras ocasiones, es de reconocer y agradecer la política de cambio y migración de IBM y el iSeries (o como lo llames), que difícilmente te deje en una situación de callejón sin salida con una aplicación antigua: se puede evolucionar gradualmente sin tirar lo que ya está hecho.

Comienza el beta test para Plex 7.1

Simon Cockayne, Product Manager para Plex y 2E desde mayo último, anunció en estos días la convocatoria a clientes registrados para participar del test beta de Plex 7.1. Una buena parte de las mejoras programadas de incluír en la nueva versión están orientadas al soporte de .NET, WCF y Azure, y Kerberos en IBM i (AKA iSeries, ex AS400). De interés por lo tanto para todos aquellos clientes que utilicen estas variantes. Está programada también una nueva facilidad interna de la IDE: la creación de perfiles de configuración que puedan ser invocados de una lista. Esta es una solicitud de la comunidad que lleva tiempo en espera, que facilitará a todos el uso de variantes y versiones, libres de errores de configuración manual.
A la larga práctica de convocar a clientes y desarrolladores a los beta test de Plex y 2E, CA ha agregado el uso de técnicas ágiles de evolución y prueba del producto, que prometen ciclos más cortos de cambio. Otra parte clave de esta filosofía, es la inclusión del repositorio de ideas en la Comunidad Global de Plex/2e (y otros productos), en la que es posible postular mejoras y correcciones, con la habilidad de votarlas y ranquearlas.  Estas son tomadas en cuenta para la elaborar la evolución del producto.
Por lo tanto, están invitados a participar y adelantar los cambios propuestos...

RPG antes y ahora

Este año se cumplieron veinticinco años de la aparición del As400/iSeries/System i o cualquier otro nombre que se propongan agregarle. De su robustez y excelente diseño dan testimonio dos artículos recientes: uno dedicado a recordar sus primeros ensayos y nacimiento, y otro evaluando el estado actual del RPG como lenguaje moderno. El primero, escrito por Mel Beckman, recuerda su inicio como programador, participando en beta tests del equipo en una empresa cercana a Rochester. Sólo rescato dos párrafos:

Despite the plethora of early bugs, we RPG programmers quickly began to see their frequency decreasing as the S/38 OS, called CPF (Control Program Facility) stabilized. S/38’s single-level store, object-oriented architecture, and integrated database really did seem to make programs more reliable, heading off the most common coding gaffs and preventing wholesale machine crashes. As the S/38 matured, it gained a reputation for solid reliability in the finance and healthcare industries, which are still strong markets for the system’s descendent, today’s IBM i. Throughout the S/38’s evolution to AS/400, iSeries, and ultimately Power hardware architectures, IBM has been able to preserve customer’s investment in business logic and data storage.
I had no idea then just how powerful the S/38’s innovations would turn out to be. They enabled IBM, and its many customers, to transport an immense amount of binary code and data into the future – not just twenty-five years, but thirty years, with very few disruptions. IBM promised, with both the S/38 and the IBM i, to protect users’ business investment in applications, processes, and logic.
In the intervening decades, many other systems have come and gone, dragging their user populations into oblivion with them. Only IBM i has preserved a continuous architectural path that is still going strong today. In 2013 it’s clear that IBM alone kept it’s promise.

El segundo artículo es un editorial del IBM System Magazine, escrito a propósito de las celebraciones de los 25 años del equipo (sistema operativo + recursos + hardware), puntualiza el estado actual del RPG, que de ninguna manera es ya lo que inicialmente fue (generador de reportes):

In reading today’s anniversary chapter, Susan learned something new—although Jon claims he knew it long ago. When RPG IV was introduced, the name “RPG” was officially declared to be no longer an acronym—or, more correctly as Scott Klement pointed out recently, an initialism. For those who didn’t realize this, to be an acronym, apparently it must be pronounceable as a word, such as NATO. If it is simply spelt out, as RPG is, it’s technically an initialism.
While the letters RPG may not officially stand for anything any more, RPG, the language, means a great deal to many thousands of programmers around the world and the users of their rock-solid, efficient, modern business applications.
In many ways it’s a good thing that RPG no longer stands for “Report Program Generator” because it has been many, many years since RPG’s primary function was reporting. It has evolved radically over the years.
If the picture that comes to your mind when you think of RPG is of columnar logic with multiple conditioning indicators and nary a hint of SQL, it’s time to wake up, Sleeping Beauty—you’ve missed a lot in the last 25 years. IBM i’s modern RPG IV is barely recognizable as a relative of the AS/400’s original RPG/400.
Today’s RPG logic is written in free format. It also utilizes libraries of homegrown, open-source and third-party functions in addition to RPG’s own library of more than 70 BIFs (built-in-functions). As a result, what would have been dozens of lines of indicator-laden, columnar “old-style” RPG are replaced by simple, powerful expressions.  And RPG’s data access has “grown up” too. Support for a huge variety of native data types and a deeper level of integration with SQL than is seen in almost any other language makes RPG a natural partner for IBM i’s integrated DB2 database.
Still think that RPG = Green Screen? Think again. Many shops are running interactive Web and mobile applications with logic powered by RPG. Or if you prefer, RPG code can easily provide the business logic underpinnings of Web services, stored procedures and other services to applications written in PHP, Java, Python, Ruby, .NET, etc.
Inevitably there are things that RPG doesn’t understand natively and that IBM cannot add to the language in a meaningful timeframe. The pace of change in today’s IT world is just too fast. That’s why Open Access was recently added to the language. It allows for the development of drivers to add new functionality while maintaining RPG’s powerful data marshaling capabilities. For example, you can write a driver to call a currency conversion Web service from RPG, allowing any RPG program to treat access to real-time currency conversion data as if it were a huge database in the sky. Simply set the key values for the currencies involved and issue a CHAIN operation. The conversion rate is returned as if it were being retrieved from a database column.

Como los autores dicen, mientras hemos visto pasar y desaparece equipos, lenguajes y arquitecturas, el diseño conceptual del AS400 sigue vigente y en primera línea. Centenares de miles de instalaciones lo demuestran. Quizá aún a pesar de algún directivo de la propia IBM, que a veces parece dudar de su producto.

Una presentación: Plex + Webclient

Una presentación publicada hoy por CM First, sobre PLex + Webclient. Para quienes no conocen Plex, una vista estimulante de sus posibilidades. Para quienes usan Plex y evalúan mover sus aplicaciones a nuevas arquitecturas, una idea de cómo mover aplicaciones a web + /o cloud +/o dispositivos móviles. Para quienes no conozcan Plex, es importante tener en cuenta la flexibilidad disponible en cuanto a arquitecturas.

Developing App with CA Plex + CM WebClient from CM First Technologies

En mi caso, este mes, testeando Plex + Android. Quizá agregue algunas líneas sobre sus resultados.

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.

iSeries: Con amigos como estos...

El 16 de mayo, Mel Beckman,en Iprodeveloper, publicó un artículo decretando la muerte del RPG (Is RPG Dead?), con cuestionamientos definitivos al lenguaje más básico y fundamental del iSeries, (o AS/400, o System i, o como se lo quiera llamar), que desató una larga discusión cuyos ecos continúan. Una gran parte de la discusión puede seguirse en las respuestas de lectores al propio artículo, pero tambíen en la excelente -y elegante- respuesta de Scott Klement en mismo sitio, así como en otros medios (grupos de LinkedIn, en nuestro grupo de usuarios de Plex, en IDevelop (1, 2), y en blogs,entre otros.
Un aspecto notable de este cuestionamiento del que ha sido y sigue siendo el principal lenguaje de diálogo con el iSeries, es que fue escrito en una publicación, Ipro Developer, que está enfocada en el iSeries, en la que "RPG programming" es el primer ítem del menú que encabeza la página, y que fue escrita por Mel Beckman, quien, según el pie del mismo artículo, "is the senior technical director for iPro Developer". Y más notable aún, que, habiendo pasado casi un mes, no exista ni un deslinde de responsabilidades de la publicación, ni un descargo del director técnico (senior).
La afirmación de obsolescencia del RPG resulta peor todavía en el marco de los reclamos de la comunidad de empresas y consultoras usuarias del iSeries, que se vió obligada recientemente  a publicar manifiestos y sostener su difusión  ante la inactividad del propio IBM en su defensa. Resulta incomprensible que un sistema que ha representado y representa un importante volúmen de las ventas y licencias de IBM, adoptado por miles de grandes y medianas empresas de primera línea en todo el mundo, que defiende el buen nombre de la empresa por su fiabilidad, y que no ha dejado de actualizarse nunca, sea torpedeado por quienes viven de su existencia.
Pero, para establecer una defensa en regla del iSeries, nada mejor que lo que Scott Klement responde en su defensa:

Yet, Mel even goes so far as to suggest that C (from 1972) and C++ (from 1983) are more modern languages.  Are you kidding me?!   Like RPG, I code in C every day, it's a big part of my job.  And let me tell you, C is not nearly as modern as RPG.  It's not even close. C and C++ can't even do simple string operations without you having to code manual memory allocation, bounds checking, and extra code to make sure that a simple string concatenation doesn't turn into a security hole.  Its database access routines are nowhere near as simple or advanced as RPG's.  Its date operations are awkward and clumsy by comparison to RPG.  Don't get me wrong, I like C, especially for lower-level systems coding.  But it's nowhere near as modern as RPG, nor as well suited for writing business logic.
But, maybe Mel doesn't understand that when today's authors refer to RPG, we really mean RPG IV.  We don't bother including the "IV" every time we say it, because RPG IV today's RPG, and everyone should already know that!

What Features Are Important In Business Logic?

Before we go throwing around opinions about old, legacy, etc...  maybe we should define what is important to us?  What are important features for a language that's aimed at people writing business logic?

• Business logic uses numbers heavily.   Numbers represent quantities, prices, and weights.  These are key to almost every application in the business world.  Very few languages today support numbers with true decimal-based arithmetic (as opposed to integer and floating-point which are ubiquitous).  Java supports decimals properly, but only by working through complex classes.  RPG supports decimal numbers simply and easily, because they are the default numeric data type in RPG.
• Business logic uses databases heavily.  Almost every business application is database driven, and database access is deeply integrated into the RPG language.  Native record access is simple and powerful.  Even more powerful is SQL, which is an order of magnitude simpler to code in RPG than it is in many other languages such as PHP or Java.
• Business logic uses dates frequently.  Whether you're checking when a customer's payment is overdue, managing inventory turnover, determining when an order should be shipped, or when an employee was hired, you need to work with dates in a simple and effective manner.  Today's RPG does that.  Many other languages have APIs or classes for working with dates (this includes Java, PHP, C, C++, etc) but in RPG they are built right into the language, and that makes it simpler.
• Business logic uses a ton of string manipulation.  Concatenating, scanning, or substringing character data is something I do every day in every program I write.  This is easy in many of the languages that Mel considers modern (PHP, JavaScript, Perl, Python, Ruby), but some of them make string manipulation much harder than it should be (Java, C, C++).  Today's RPG, unlike its predecessors, makes string manipulation a snap.

I've coded in more than 20 programming languages.  Some are object-oriented (such as Java, C++, and JavaScript), some are procedural (C, RPG, Pascal, Fortran), and some are a mixture of the two (such as PHP.)  But when I sit down and figure out which language is  easiest for my business logic, it's invariably RPG.

Scott Klement: juego de caracteres en el AS400

Sólo para usuarios de AS400/iSeries: Scott Klement dedica una nota suficiente al juego de caracteres y su uso al intercambiar datos con otros sistemas, y entre distintos lenguajes en el propio sistema. Necesario  de conocer. No lo voy a repetir, excepto el siguiente párrafo:

Things You Should Definitely Know

• It is not OK to create a text string without knowing and identifying which CCSID the data is stored in.
• It's not reasonable to expect the computer to "detect" a CCSID.
• Power Systems (and their predecessors, System i5, iSeries, and AS/400) are not "EBCDIC machines." They can run ASCII, EBCDIC, or Unicode equally well.
• The IBM i operating system (and its predecessors i5/OS and OS/400) do most of their work in EBCDIC, but they also understand both ASCII and Unicode and can run programs based on them (e.g., Java, PHP, PASE, Apache).
• IBM i has knowledge of many CCSIDs (including ASCII, EBCDIC and Unicode) built in and can easily and efficiently translate between them.
• The web is not based on ASCII. It is based on Unicode.

Things to Think About When You Have Problems

If you tell me that you have a character encoding problem, I'll want to know the following:

• How the characters were supposed to be encoded in the original file.
• What the CCSID of the original file was.
• How the characters were supposed to be encoded in the destination file.
• What the CCSID of the destination file was.

Para conservar en la guía fundamental de trabajo.