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: hacer diagnóstico avanzado de hardware y conducir la recuperación.

DST vs SST — cuándo usar cada uno

SST (System Service Tools) — se accede desde IBM i en ejecución:

STRSST

Requiere un perfil de service tools (no es el mismo que el perfil de IBM i). Las opciones clave dentro de SST:

| Opción | Para qué | |---|---| | 1. Start a service tool | Acceder a herramientas de diagnóstico individual. | | 2. Work with active service tools | Ver herramientas en ejecución. | | 3. Work with disk units | Gestión de discos: estado, mirror, hot spare, replace. | | 4. Work with system environment | Particiones, procesadores, memoria asignada. | | 5. Work with system operator information | Mensajes pendientes del operador a nivel de service tools. | | 6. Main storage dump | Generar dump de memoria para IBM Support. |

Cuándo usar SST:

• •Verificar estado de discos antes/después de un hot-swap.
• •Obtener información de licencia de procesadores (P05, P10, P20, etc.).
• •Revisar mirror status de unidades.
• •Generar un main storage dump para escalar a IBM.
• •Ejecutar traces de diagnóstico de I/O.

DST (Dedicated Service Tools) — se accede desde el panel del operador (Operations Console o HMC) sin IBM i corriendo, durante un IPL manual (modo D o modo manual):

Cuándo usar DST:

• •El sistema no arranca — IPL colgado en un SRC.
• •Se necesita recovery del sistema operativo (Install from tape/optical).
• •Hay que reconfigurar unidades de disco antes de que el OS pueda cargar.
• •Se necesita cambiar el perfil de service tools (password reset).
• •Recovery de un IASP que no puede hacerse desde el OS.
• •Acceso a la configuración del Licensed Internal Code cuando SST no es suficiente.

Regla práctica: si IBM i está corriendo, usar SST. Si no arranca o necesitás recovery profundo, usar DST.

HMC — operaciones avanzadas

DLPAR (Dynamic Logical Partitioning):

DLPAR permite modificar los recursos de una LPAR (CPU, memoria, I/O) sin detener la partición. Desde la HMC:

1. •Navegar a Systems Management > Servers > [servidor] > Partitions > [LPAR].
2. •Seleccionar Properties > Processor / Memory / I/O.
3. •Modificar el valor deseado dentro de los rangos min/max definidos en el perfil.
4. •Aplicar. El cambio es inmediato, sin IPL.

Limitaciones: no se puede reducir por debajo del mínimo definido en el perfil, ni superar el máximo. Para cambiar min/max, se necesita un shut down de la LPAR en la mayoría de los casos (aunque las versiones recientes de HMC permiten ciertos ajustes dinámicos de min/max).

Live Partition Mobility (LPM) — pasos de alto nivel:

LPM mueve una LPAR activa (con IBM i o AIX corriendo) de un servidor físico a otro sin downtime. Los pasos son:

1. •Verificar prerequisitos: ambos servidores gestionados por la misma HMC (o HMC pareadas), misma versión de firmware compatible, VIOS en ambos servers, storage compartido (SAN), red compartida (VLANs).
2. •Validar la LPAR: desde HMC, ejecutar Validate Move sobre la LPAR. El sistema verifica que todos los recursos (procesador, memoria, virtual I/O, storage) estén disponibles en el destino.
3. •Ejecutar el move: Operations > Move > [destino]. La HMC coordina la suspensión momentánea de la LPAR, la migración de estado de memoria y la reactivación en el nuevo servidor.
4. •Verificar: la LPAR aparece activa en el servidor destino. Los usuarios no perciben interrupción (pausa de milisegundos a pocos segundos).

Caso de uso principal: firmware update — mover todas las LPARs al servidor B, aplicar firmware en A, mover de vuelta, aplicar firmware en B. Cero downtime planificado.

SRC codes comunes y qué indican

Los SRC (System Reference Codes) son la primera información diagnóstica cuando hay un problema de hardware o IPL. Cada familia de SRC indica un área del sistema:

B1xx — Errores de Licensed Internal Code (LIC):

| SRC | Significado | Acción | |---|---|---| | B1004000 | Error de microcode durante IPL. | Anotar el SRC completo (8 dígitos + word 2-9 si están disponibles). Escalar a IBM con snap del SRC y logs de HMC. | | B1004250 | Problema con el objeto de sistema durante recovery. | Intentar IPL modo B. Si persiste, IPL modo D para recovery con DST. |

A6xx — Errores de almacenamiento (disk/storage):

| SRC | Significado | Acción | |---|---|---| | A6xx 0244 | Unidad de disco no responde. | Verificar con SST (opción 3) el estado de la unidad. Si es RAID/mirror, el sistema continúa operando con la unidad restante. Programar hot-swap. | | A6xx 0277 | Error de lectura/escritura en disco. | Puede ser transitorio (verificar si se repite) o indicar falla de disco. Si se repite, programar reemplazo. | | A6005xxx | RAID parity error. | El RAID está operando en modo degradado. Reemplazo urgente de la unidad fallida. |

B900 — Errores de IPL:

| SRC | Significado | Acción | |---|---|---| | B9003112 | IPL no puede completar la fase de recovery del journal. | Los receivers pueden estar corruptos. IPL modo D, acceder a DST, ejecutar recovery de almacenamiento. | | B9003000 | Error general durante IPL del Licensed Internal Code. | Anotar todos los SRC words. Intentar IPL modo A (con cambio de IPL source). Si falla en ambos modos, escalar a IBM. |

Regla de oro para soporte senior: anotar siempre el SRC completo (los 8 dígitos del SRC primario + los word adicionales 2 a 9 si están disponibles en el panel o HMC). IBM Support necesita todos los words para diagnosticar.

Recovery scenario: falla de disco en sistema con mirror

Escenario: un servidor Power con IBM i y storage interno configurado con disk mirroring (no RAID sino mirror nativo de IBM i) pierde una unidad de disco.

Paso 1 — Detección: El sistema genera un SRC en el panel y un mensaje en QSYSOPR:

CPI1168 - Mirrored protection suspended on unit X.

La LPAR continúa operando normalmente con la unidad espejo restante. No hay downtime.

Paso 2 — Verificar estado desde SST:

STRSST
  Opción 3: Work with disk units
    Opción 1: Display disk configuration

Buscar la unidad marcada como Suspended o Failed. Anotar: número de unidad, serial, ubicación física (slot).

Paso 3 — Coordinar reemplazo:

• •Si hay hot spare configurado, el sistema reconstruye automáticamente el mirror sobre el hot spare. Verificar que la reconstrucción avanza consultando WRKDSKSTS.
• •Si NO hay hot spare, se requiere un reemplazo físico (concurrent maintenance si el hardware lo permite — la mayoría de los Power modernos sí).

Paso 4 — Hot-swap de disco:

1. •Desde SST, marcar la unidad fallida para Concurrent remove.
2. •El LED de servicio del slot se enciende en la unidad a reemplazar.
3. •El técnico (IBM CE o personal autorizado) remueve la unidad y coloca la nueva.
4. •Desde SST, aceptar la nueva unidad y configurarla como mirror de la unidad activa.

Paso 5 — Reconstrucción del mirror: La reconstrucción es automática. El tiempo depende del tamaño de la unidad (puede tomar horas para discos grandes). Durante la reconstrucción, la performance de I/O se reduce levemente. Verificar progreso con:

WRKDSKSTS

La columna % Mir. Done muestra el avance.

Paso 6 — Validación final: Cuando la reconstrucción termina, verificar que todas las unidades muestren Active en SST y que no queden mensajes de warning en QSYSOPR.

Firmware update — procedimiento y riesgos

Procedimiento de alto nivel:

1. •Verificar el nivel de firmware actual desde HMC: Updates > Manage firmware > View system firmware level.
2. •Descargar el firmware desde IBM Fix Central, seleccionando el modelo de servidor exacto.
3. •Planificar la ventana:
   • •Si el servidor tiene dos LPARs y soporta LPM: mover las LPARs al servidor B, actualizar A, mover de vuelta, actualizar B (zero downtime).
   • •Si no hay LPM: coordinar ventana de mantenimiento. El firmware update requiere un IPL del servidor completo (todas las LPARs se detienen).
4. •Aplicar desde HMC: Updates > Install firmware > [seleccionar nivel]. Seleccionar si se activa inmediatamente o en próximo IPL.
5. •IPL del servidor (si se requiere activación).
6. •Verificar: post-IPL, confirmar el nuevo nivel de firmware desde HMC y verificar que todas las LPARs arrancaron correctamente.

Riesgos:

• •Incompatibilidad con IBM i/AIX TR: siempre verificar la matriz de compatibilidad firmware ↔ OS level antes de aplicar. Un firmware más nuevo puede requerir un TR mínimo del OS.
• •Rollback limitado: no siempre es posible hacer rollback de firmware. El side que no está activo conserva el nivel anterior temporalmente, pero una vez activado en ambos lados, no hay vuelta atrás fácil.
• •Duración del IPL post-firmware: puede tomar más tiempo que un IPL normal (30-60 minutos en servers grandes vs 10-15 minutos de IPL normal).

Escenarios típicos

• •IPL fallido — diagnóstico desde DST.
• •Falla de disco — gestión vía SST, manejo de mirror/RAID, hot-swap.
• •Falla de memoria — identificación, escalación.
• •Pérdida de comunicación HMC ↔ servidor — troubleshooting de red de service.
• •Aplicación de firmware con minimal downtime — uso de LPM.