Trabajar con IBM i con IBM Bob

Si nunca has escrito una línea de RPG, IBM i es una de las plataformas más fascinantes para producción a escala. Si has escrito unos cuantos millones de líneas, ya sabes dónde vive el dolor del día a día. Este post cubre ambos: un esbozo técnico de lo que hace único a IBM i, dónde aparece realmente la fricción de modernización, cómo IBM Bob encaja en un flujo de trabajo de IBM i hoy, los pasos de configuración para empezar, y qué sigue en la hoja de ruta para la plataforma.

Qué es realmente IBM i

IBM i no es un sistema operativo legacy en el sentido de "deberíamos reescribir esto". Es una plataforma integrada — el OS, la base de datos, el modelo de seguridad y el runtime están diseñados y distribuidos como una sola cosa — que ha estado generando ingresos para bancos, aseguradoras, hospitales, fabricantes y empresas de logística durante décadas. Así que deberíamos llamarlo legendario.

Algunos detalles que tienden a sorprender a los desarrolladores que lo ven por primera vez:

Single-level storage. RAM y disco comparten un espacio de direcciones virtual. Los punteros de objetos persisten a través de reinicios. El OS trata la memoria y el almacenamiento como un solo nivel y pagina entre ellos de forma transparente. La mayoría de los sistemas modernos todavía están poniéndose al día con esto.
TIMI, el Technology Independent Machine Interface. Los binarios RPG compilados en hardware de los años 90 se ejecutan sin modificar en chips POWER actuales. El OS retraducen contra el nuevo conjunto de instrucciones bajo el capó. El análogo moderno más cercano es WebAssembly, décadas antes.
OS basado en objetos. Programas, archivos, colas y autoridades son objetos tipados con atributos — no archivos con metadatos añadidos. La seguridad se aplica a nivel de objeto.
Db2 for i está integrado, no añadido. SQL y el I/O nativo a nivel de registro acceden a los mismos datos. Un archivo físico de 40 años puede consultarse a través de una vista SQL moderna sin un proyecto de migración.
El source puede vivir en el sistema o en Git — tú eliges. Históricamente, el source de IBM i se almacenaba como members dentro de source physical files (QSYS), compilados directamente en el sistema. La plataforma originalmente posicionó la LPAR como la fuente de verdad. Pero IBM i ha evolucionado: los compiladores y el OS ahora soportan completamente flujos de trabajo modernos centrados en Git, archivos de stream IFS y desarrollo local si lo eliges. Muchos shops todavía usan bibliotecas QSYS, pero la plataforma te da opciones

La plataforma también soporta patrones de entrega modernos out of the box: motores de API REST nativos como parte del OS, nube híbrida a través de Power Virtual Server, e inferencia de IA ejecutándose en el mismo hardware que las cargas de trabajo transaccionales. RPG, COBOL, CL y SQL coexisten con las prácticas de desarrollo que el resto de tu organización de ingeniería ya usa.

La plataforma no es el problema. La fricción está alrededor de ella.

Dónde aparece la fricción

Cuatro patrones aparecen en casi todos los shops de IBM i. Ninguno de ellos es sobre RPG en sí — el lenguaje está bien — sino sobre el contexto alrededor del código que nunca se escribió, y la forma en que la plataforma almacena y comparte ese contexto.

Contexto implícito, por diseño. Un programa RPG funcional puede abarcar cuatro generaciones de lenguaje en un source — RPG II, RPG IV, copybooks /COPY (declaraciones compartidas incluidas en tiempo de compilación) y procedimientos de formato libre — con sintaxis sensible a columnas e indicadores numerados (*IN01–*IN99) haciendo el trabajo que el flujo de control estructurado y los booleanos nombrados hacen en la mayoría de los otros lenguajes. La sintaxis se puede aprender en una semana; las convenciones y reglas de negocio alrededor de ella viven en las cabezas de los ingenieros senior.
El cambio nunca es local. El tipo de un campo no se declara en el programa que lo usa — se declara en la tabla de base de datos misma, en un archivo source separado (un member DDS). Cada programa que lee o escribe esa tabla hereda esas definiciones simplemente referenciando el archivo al principio. Así que alargar una columna de 10 a 12 dígitos nunca es una edición de un programa: se propaga a través de cada programa que toca el archivo, y la lista de esos programas rara vez está escrita en algún lugar. Cada cambio a una carga de trabajo crítica por lo tanto conlleva riesgo de continuidad, y la modernización se estanca.
El source rara vez vive donde las herramientas modernas lo esperan. La copia canónica de un programa está en el sistema, no en un repo Git en un portátil. Leer código que alguien más escribió hace quince años comienza con encontrarlo en la LPAR, exportarlo, y luego decidir si la exportación es la copia canónica — un flujo de trabajo al que cualquier herramienta que asume un árbol de trabajo local tiene que adaptarse antes de que valga la pena.
El RPG de formato fijo no se parece en nada al código moderno. La mayoría del RPG de producción se escribió en formato fijo: sintaxis sensible a columnas donde los códigos de operación viven en las columnas 26–35, Factor 1 en 12–25, y los comentarios solo caben después de la columna 80. Se lee como lenguaje ensamblador para cualquiera entrenado en Python o JavaScript. IBM reinventó el lenguaje con RPG completamente de formato libre (RPG IV, más tarde simplemente "RPG"), que se ve y se siente como un lenguaje procedimental moderno — bloques estructurados, variables nombradas, expresiones estándar. La brecha de sintaxis es real, pero el lenguaje en sí evolucionó. La fricción es que décadas de código funcional todavía están en formato fijo, y reescribirlo conlleva un riesgo que la mayoría de los shops no pueden justificar.

Qué hace Bob en una aplicación RPG para IBM i

Apunta Bob a un programa RPG y comienza en modo Ask:

"Guíame a través de lo que hace este programa y qué archivos toca."
"¿Dónde se establece CUSTNO, y qué programas lo leen después de eso?"
"¿Qué se rompería si cambio la longitud de este campo?"

Cambia al modo Plan cuando tengas un cambio en mente: una conversión de formato libre, una migración SQL fuera del I/O a nivel de registro, o romper un monolito en módulos. Bob produce un plan, las dependencias que tocó, y los pasos que pretende tomar, antes de que se modifique cualquier archivo.

Cambia al modo Code para aplicar el cambio. Bob:

Convierte RPG de formato fijo a formato libre usando patrones repetibles, archivo por archivo.
Migra I/O a nivel de registro a SQL embebido donde sea apropiado.
Genera suites de prueba RPGUnit contra procedimientos existentes para que la conversión sea verificable, no solo compilada.
Produce documentación en lenguaje plano y diagramas Mermaid del source — artefactos buscables y compartibles que sobreviven a cualquier ingeniero.

El mismo flujo de trabajo maneja RPG II/III/ILE, CL, DDS, SQL y COBOL, así que un nuevo empleado leyendo un programa escrito antes de que naciera ya no está bloqueado por la sintaxis.

Haz tu source de IBM i Bob-ready

Bob hoy trabaja contra source en tu computadora local. La configuración es corta:

Descarga tu source. Exporta tus members RPG, RPGLE, CL, DDS y SQL a una carpeta local. El explorador de proyectos Code for i documenta la exportación desde physical file members: migrate source
Abre la carpeta en Bob. File → Open Folder en la raíz del source. Bob indexa la base de código en la primera apertura.
Instala la toolchain de IBM i. Desde el panel de Extensions, añade el IBM i Development Pack (el bundle Code for i) y un renderizador Mermaid para los diagramas que Bob produce.
Inicia una sesión en modo Ask. Elige un solo programa — idealmente uno que nadie en el equipo entienda completamente — y pide a Bob que lo explique. Esa es la forma más rápida de ver si Bob se gana su lugar en tu flujo de trabajo.

Si tu equipo viene de SEU o RDi, la migración es principalmente el paso de exportación anterior más la instalación de la extensión. La superficie de edición es un entorno moderno de la familia VS Code con resaltado de sintaxis, completado de código y el flujo de trabajo de IA descrito anteriormente; los números de línea todavía están disponibles para los ingenieros que los quieren.

Qué sigue para Bob en IBM i

El Premium Package for i recientemente anunciado proporciona experiencia nativa y optimizada para equipos de desarrollo de IBM i. Premium Package for i estará generalmente disponible el 24 de junio.

Premium Package for i. Con el GA del 24 de junio, Bob se conectará directamente a tu IBM i. Desde una sola sesión lees source members directamente desde QSYS, los editas con el mismo flujo de trabajo anterior, y ejecutas ciclos de compilación y prueba contra el sistema directamente. Junto con la conectividad, Bob adquiere skills y flujos de trabajo integrados ajustados al desarrollo de IBM i — conversión de fijo a libre, refactorización, generación de documentos — para que un prompt inicial en una base de código RPG aterrice más directamente en las convenciones de IBM i out of the box. Concretamente, eso significa:

Una sesión de Bob conectada a una LPAR de desarrollo; sin bucle separado de exportar-editar-importar.
Los errores de compilación y resultados de prueba del IBM i vuelven a aparecer en la conversación en la que Bob ya está.
Skills y flujos de trabajo integrados para los patrones de refactorización, conversiones y generación de pruebas que los shops de IBM i ejecutan repetidamente.

Más adelante — SDLC de extremo a extremo. Tres hilos están en diseño activo para futuros lanzamientos:

Integración DevOps. Bob participando en build, deploy, monitor y CI/CD para cargas de trabajo de IBM i — ejecutando un pase de regresión contra una LPAR de prueba, promoviendo un cambio a través de entornos, y llevando un problema de runtime de vuelta a una sesión.
Rendimiento SQL. Análisis de datos y optimización de índices como una capacidad de primera clase, además de los patrones de migración de SQL embebido que Bob ya produce hoy.
Asistente de conocimiento de IBM i. Respuestas basadas en recuperación a través de la base de código, documentación de diseño y tickets — para que el contexto que vive fuera del source sea alcanzable desde la misma conversación.

Para un equipo que adopta Bob hoy, el flujo de trabajo de archivo local anterior es el punto de partida correcto; los elementos en esta sección describen cómo ese flujo de trabajo se acorta y extiende a medida que la oferta de IBM i madura.

Referencias de clientes

Equipos en healthcare, agricultura, TI empresarial y logística están usando Bob contra bases de código de IBM i de producción hoy:

MEDHOST. Aplicaciones de healthcare que abarcan múltiples generaciones de RPG a través de despliegues hospitalarios de EE.UU. El equipo usa Bob para análisis de impacto y conversión de fijo a libre, y para incorporar desarrolladores más nuevos a programas cuyos autores originales se fueron hace mucho.
NI+C. Integrador empresarial japonés con programas RPG que habían estado ejecutándose sin cambios durante más de una década sin documentación de diseño sobreviviente. Bob produjo docs de diseño y diagramas Mermaid lo suficientemente precisos como para que los ingenieros que previamente habían rebotado con asistentes de IA siguieran usándolo para trabajo real.
Heartland Co-op. Cooperativa agrícola con sede en Iowa que transmite datos de sensores IoT en tiempo real a su entorno IBM i para monitoreo de calidad de grano y equipos. Bob ayuda a los desarrolladores a razonar a través de las interdependencias entre el pipeline IoT, la contabilidad de granos y los sistemas operativos centrales, y acorta la incorporación de nuevos empleados.
Carreras Grupo Logístico. Uno de los primeros adoptantes empresariales de Bob en España, usándolo para explicar la lógica de programas legacy, generar documentación y refactorizar a través de módulos de una plataforma logística.

El hilo común a través de los cuatro es el mismo: la base de código de IBM i existente permanece en su lugar, y el trabajo de explicación, conversión y documentación se ejecuta junto al sistema de producción en lugar de antes de un proyecto de reemplazo.

Empezar

Inicia una prueba gratuita
Descarga un programa RPG en una carpeta local y ábrelo en Bob.
En modo Ask, solicita un recorrido y un diagrama Mermaid de su flujo de datos.

Esa sesión — un programa, una conversación — es el camino más corto a una respuesta real sobre si Bob se ajusta a la forma en que tu equipo trabaja.