Módulo 1 — iSeries / IBM Power Systems (hardware)

Antes de la profundización por rol, todo el equipo debe manejar este vocabulario mínimo.

Linaje

La plataforma fue anunciada en junio de 1988 como AS/400 (Application System/400) y lanzada al mercado en agosto de ese año. Sucedió al System/36 y al System/38, originalmente con sistema operativo OS/400. El AS/400 introdujo innovaciones arquitectónicas fundamentales que sus predecesores no tenían de forma combinada: modelo de objetos tipados, almacenamiento de nivel único y la TIMI como capa de abstracción del hardware. Esas tres decisiones de diseño son las que explican por qué las aplicaciones escritas hace 30 años siguen corriendo sin modificación sobre hardware moderno.

La línea fue rebrandeada varias veces siguiendo los ciclos de marketing de IBM:

• •AS/400 (1988) → AS/400 Advanced Series (1994) → AS/400e (1997)
• •eServer iSeries (2000) → eServer i5 con i5/OS (2004, sobre POWER5)
• •System i (2006)
• •IBM Power Systems (2008) — convergencia de System i y System p; el OS pasa a llamarse IBM i

El cambio de 2008 fue más que un rebrand: IBM unificó bajo una sola arquitectura de hardware (Power) lo que antes eran dos líneas separadas (System i para IBM i/AIX orientado a clientes de negocio, System p para Unix de alto rendimiento). Desde entonces, el mismo servidor físico Power puede correr IBM i, AIX y Linux en distintas particiones lógicas simultáneamente.

TIMI — Technology Independent Machine Interface

Una capa de instrucciones independiente del hardware. En lugar de compilar directamente a código máquina nativo, los compiladores de IBM i generan una representación intermedia de alto nivel en formato TIMI. El SLIC (System Licensed Internal Code), que es la capa dependiente del hardware del OS, traduce esas instrucciones TIMI a código nativo en tiempo de ejecución.

Esto permite cambiar la arquitectura del procesador sin romper la compatibilidad de las aplicaciones: cuando IBM pasó de procesadores CISC propios (IMPI, 1988) a procesadores PowerPC (RS64, 1995) y luego a POWER4, POWER5, POWER6... y Power10 y Power11 actuales, el código de las aplicaciones no necesitó recompilarse. Solo el SLIC fue actualizado para traducir las mismas instrucciones TIMI al nuevo hardware. Por eso una aplicación compilada hace 25 años puede seguir corriendo sobre Power moderno sin recompilación, sin cambios de código, sin retesting funcional.

Power Systems hoy

Desde 2008 el mismo hardware Power puede correr IBM i, AIX y Linux on Power en distintas particiones, gestionadas por PowerVM y la HMC (Hardware Management Console).

Generaciones vigentes en el parque instalado

No todos los clientes están en la última generación. Es muy común encontrar mezclas, y todas siguen apareciendo en proyectos de venta y soporte:

| Generación | Modelos representativos | Estado de soporte | |---|---|---| | POWER8 | 8286-42A, 8284-22A | Fuera de soporte estándar de IBM. Continúa cubierto por mantenimiento de terceros (third-party maintenance). | | POWER9 | S914, S922, S924 | EOSL declarado por IBM en enero de 2026. | | Power10 | S1014, S1022, S1022s, S1024, E1050, E1080 | Generación actual desplegada masivamente desde 2021–2022. | | Power11 | E1150 (9043-MRU) | Generación más reciente, anunciada en julio de 2025. |

Implicancias prácticas:

• •Comercial debe saber identificar la generación porque define vías de upgrade y pricing.
• •Soporte convive con cuentas en POWER8/9; la documentación oficial de IBM cubre todas las generaciones vivas.
• •Preventa debe poder dimensionar tanto sobre Power10/11 como sobre parque heredado.

Cada nueva generación de procesadores Power trajo mejoras significativas en rendimiento por núcleo, densidad de cores y capacidades de aceleración en chip. Power10, por ejemplo, incorporó encriptación en silicio sin costo de CPU adicional, aceleradores NX para compresión gzip, y soporte hasta SMT8 (ocho hilos por núcleo físico). Power11 continuó esa evolución enfocándose en resiliencia, seguridad y eficiencia energética, con mejoras en la densidad de cómputo por watt.

Objetivo del rol en este módulo: entender dónde corre el código, sin necesidad de administrar hardware.

Lo mínimo que un dev de IBM i debe saber del hardware

• •Su código corre dentro de una LPAR sobre un servidor Power.
• •La LPAR tiene cores y memoria asignados — si performance no alcanza, puede pedirse incremento (cores, memoria, CoD).
• •Existe el concepto de IASP: si trabaja con IASP, las bibliotecas no están en *SYSBAS y hay que hacer SETASPGRP.
• •PowerVM virtualiza el I/O — no tiene que preocuparse por discos físicos.
• •En cloud, IBM Power Virtual Server (PowerVS) ofrece LPAR como servicio sin cambiar nada del código.

Cuándo escalar al equipo de infra

• •Saturación sostenida de CPU o memoria de la LPAR.
• •Necesidad de aislar workload nuevo en IASP propio.
• •Migración a hardware nuevo / cloud.