Refactoring de RPG legacy, modernizacion de UI, enfoque API-first y estrategias incrementales para llevar IBM i al siglo XXI sin romper lo que funciona.
La modernizacion de IBM i no es un tema de reemplazo tecnologico sino de sostenibilidad del negocio. Las aplicaciones RPG/COBOL que corren en IBM i son a menudo el core del negocio: facturacion, inventario, contabilidad. Funcionan bien, pero enfrentan desafios crecientes.
Escasez de talento
Cada vez menos desarrolladores conocen RPG III/400. Los nuevos programadores esperan herramientas y lenguajes modernos.
Expectativas de UX
Los usuarios internos esperan interfaces web/mobile. Las pantallas 5250 son funcionales pero generan friccion.
Integracion con ecosistema
Las aplicaciones modernas necesitan APIs, webhooks, SSO. El codigo legacy no fue disenado para esto.
Deuda tecnica acumulada
Decadas de cambios sin refactoring crean programas de miles de lineas con logica entrelazada y sin documentacion.
Existen cinco estrategias principales, cada una con diferente nivel de riesgo, costo e impacto. No son mutuamente excluyentes; un proyecto puede combinar varias.
Migrar IBM i a PowerVS (cloud) sin modificar el codigo. Mismo software, diferente infraestructura. Riesgo minimo, beneficios operacionales (DR, escalabilidad).
Convertir RPG III a RPG IV free-format, modularizar monolitos, agregar SQL embebido, adoptar ILE. El programa sigue en IBM i pero es mas mantenible.
Extraer logica de negocio como APIs/servicios, separar UI del backend, implementar capas. Cambios significativos en estructura, misma plataforma.
Reescribir componentes especificos en lenguajes modernos (Node.js, Java) manteniendo el core en RPG. Solo cuando el refactor no es viable.
Reemplazar aplicaciones custom por SaaS/ERP comercial. Solo viable cuando la funcionalidad no es diferenciadora del negocio.
La modernizacion de UI es generalmente el primer paso visible. Hay multiples enfoques para reemplazar o complementar las pantallas 5250 con interfaces web modernas.
5250 tradicional
Web UI moderna
El refactoring de RPG es la base de toda modernizacion en IBM i. Consiste en transformar codigo RPG III (columnar, con indicadores, GOTOs) a RPG IV free-format modular. Esto no cambia la funcionalidad pero mejora drasticamente la mantenibilidad.
C CUSTNO CHAIN CUSTMAST 99
C N99 MOVEL CUSNAM WKNAME
C N99 MOVEL CUSADR WKADDR
C N99 Z-ADD CUSBAL WKBAL
C 99 MOVEL *BLANKS WKNAME
C 99 MOVEL 'NOT FOUND'WKERR
C EXFMT SCREEN01
C *INKC IFEQ *ON
C MOVE *ON *INLR
C ENDIF**free
ctl-opt main(Main);
ctl-opt option(*srcstmt:*nodebugio);
dcl-proc Main;
dcl-pi *n end-pi;
dcl-s custNo packed(7:0);
dcl-ds custData likeds(customerDs);
custData = getCustomer(custNo);
if custData.found;
displayCustomer(custData);
else;
displayError('Cliente no encontrado');
endif;
return;
end-proc;
dcl-proc getCustomer;
dcl-pi *n likeds(customerDs);
id packed(7:0) const;
end-pi;
dcl-ds result likeds(customerDs) inz;
exec sql
SELECT CUSNAM, CUSADR, CUSBAL
INTO :result.name, :result.address, :result.balance
FROM CUSTMAST
WHERE CUSID = :id;
result.found = (sqlcode = 0);
return result;
end-proc;Eliminar indicadores (*INxx)
Reemplazar por variables booleanas con nombres descriptivos
Convertir a free-format
Mover de columnas fijas a formato libre /free ... /end-free o **free
Reemplazar GOTO por IF/SELECT
Eliminar TAG/GOTO por estructuras de control
Extraer subprocedimientos
Modularizar logica en procedimientos con dcl-proc
Adoptar SQL embebido
Reemplazar READ/WRITE/CHAIN por exec sql
Usar data structures
Agrupar campos relacionados en dcl-ds
Agregar ctl-opt
Control specs para opciones de compilacion
Implementar ILE
Crear service programs con procedimientos exportados
El enfoque API-first consiste en exponer toda la logica de negocio como servicios REST antes de construir cualquier nueva interfaz. Esto crea una capa de abstraccion que desacopla el backend RPG de cualquier consumidor.
Flujo API-first en IBM i
openapi: 3.0.0
info:
title: Customer Management API
version: 1.0.0
description: APIs backed by IBM i RPG programs
paths:
/api/customers/{id}:
get:
summary: Get customer by ID
parameters:
- name: id
in: path
required: true
schema:
type: integer
responses:
'200':
description: Customer found
content:
application/json:
schema:
$ref: '#/components/schemas/Customer'
'404':
description: Customer not found
/api/customers:
post:
summary: Create new customer
requestBody:
content:
application/json:
schema:
$ref: '#/components/schemas/CustomerInput'Las aplicaciones IBM i tipicas son monolitos: un programa gigante que maneja todo. La descomposicion en servicios permite que diferentes equipos trabajen en paralelo, que los componentes se escalen independientemente y que se adopten tecnologias modernas de forma gradual.
Identificar dominios
Usar Domain-Driven Design para encontrar bounded contexts: Clientes, Ordenes, Inventario, Facturacion. Cada dominio se convierte en un servicio.
Extraer service programs
Refactorizar el monolito RPG en service programs ILE separados por dominio. Cada uno con procedimientos exportados bien definidos.
Exponer como APIs
Cada service program se registra en IWS como un servicio REST independiente. Los servicios se comunican via APIs, no via acceso directo a datos.
Antes de modernizar, es imprescindible entender que hay. Las herramientas de analisis escanean el codigo fuente y las dependencias para crear un mapa del sistema existente.
-- Ver que archivos usa un programa
DSPPGMREF PGM(MYLIB/ORDENTRY)
OUTPUT(*PRINT)
-- Ver que programas usan un archivo
DSPDBR FILE(MYLIB/CUSTMAST)
OUTPUT(*PRINT)
-- Ver fuentes de un miembro
DSPPFM FILE(MYLIB/QRPGLESRC) MBR(ORDENTRY)
-- Buscar string en todos los fuentes
FNDSTRPDM STRING('CUSTMAST')
FILE(MYLIB/QRPGLESRC)
MBR(*ALL)
OPTION(*NONE)Riesgos comunes
Mitigaciones
Distribuidor mayorista — UI modernization
Empresa de seguros — API-first
Manufacturera — Refactoring puro
Un roadmap realista para modernizacion de IBM i tipicamente abarca 18-36 meses. Este es un template generico que se adapta segun la organizacion: