Módulo 1 — iSeries / IBM Power Systems (hardware)
Plataforma física que sostiene IBM i y AIX. Contenido desarrollado a la profundidad requerida por cada rol.
Base común — todos los roles
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.
Soporte L1Para Soporte L1 (1 día)
Objetivo del rol en este módulo: identificar correctamente el hardware del cliente, recolectar evidencia y abrir bien un case.
Datos que SIEMPRE hay que pedir/leer
- •Modelo y serial del Power —
DSPSYSVAL QMODEL,DSPSYSVAL QSRLNBR. - •Versión de firmware del servidor — visible en HMC.
- •Versión de HMC.
- •Versión y nivel de IBM i —
DSPPTF,GO LICPGMopción 10. - •TR (Technology Refresh) instalado.
HMC para L1
No se trabaja a fondo, pero hay que reconocer:
- •Vista de "Servers" — qué máquinas están conectadas.
- •Vista de "Partitions" — estado de cada LPAR.
- •"Service Events" — alertas activas del hardware.
- •Botón "Manage" para una LPAR — power on/off, vista de operating panel.
System Reference Codes (SRC)
Códigos de 4 caracteres (a veces 8 dígitos) que el sistema muestra ante eventos de hardware o IPL. Para L1: anotar el SRC, no interpretarlo, escalar con el código. La base oficial está en IBM Documentation.
Service Events en HMC
La pantalla de Service Events es donde un L1 va a ver las alertas de hardware. Para acceder:
- •En la HMC, navegar a
Serviceability > Service Events. - •La lista muestra eventos con: timestamp, SRC code, servidor afectado, severidad, estado (Open/Closed).
- •Los eventos abiertos (
Open) son los que requieren atención.
Severidades P1/P2/P3 y qué significan:
| Severidad | Significado | Acción L1 | |---|---|---| | P1 (Priority 1) | Falla crítica — sistema detenido o en riesgo inminente de detenerse. | Escalar inmediatamente. Anotar SRC, timestamp, servidor. No esperar al próximo turno. | | P2 (Priority 2) | Falla significativa — degradación de servicio, redundancia perdida (ej. un disco de mirror falló, pero el sistema sigue operando). | Escalar en el turno actual. El sistema opera pero está expuesto. Programar mantenimiento urgente. | | P3 (Priority 3) | Falla menor o informativa — evento que no impacta operación actual pero requiere seguimiento (ej. warning de temperatura, error transitorio de I/O). | Registrar y monitorear. Si se repite, escalar. |
Ejemplo de SRC con explicación:
En el panel de Service Events aparece:
Date/Time: 2026-05-08 03:15:22
SRC: A6005123
Server: S1022-SN12345
Severity: P2
Status: Open
Description: Disk unit error
Interpretación: A6 = subsistema de almacenamiento. 005 = error de unidad de disco. Es P2 porque el sistema sigue operando (probablemente en mirror/RAID degradado). Anotar el SRC completo, verificar en QSYSOPR si hay mensajes CPI1168 (mirror suspended), y escalar con toda la evidencia.
Cómo abrir un case con IBM
- •Recolectar: serial, IBM i version + TR, SRC si hay, HMC version, descripción del síntoma.
- •Acceso vía IBM Support portal.
- •En cuentas con contrato, puede haber procedimiento del BP de mantenimiento.
Recursos relacionados
Runbook — Connect CDC
Los 10 incidentes más frecuentes en operación de Connect CDC (Precisely), con síntoma, evidencia, primer paso y criterio de escalado.
Runbook — Flash For i
Los 10 incidentes más frecuentes en operación de Flash For i (M81), con síntoma, evidencia, primer paso y criterio de escalado.
Runbook — Assure Quick EDD
Los 10 incidentes más frecuentes en operación de Quick EDD, con síntoma, evidencia, primer paso y criterio de escalado.