Arquitectura y LPARs

TIMI — Technology Independent Machine Interface

Este es el concepto más importante para entender la longevidad de la plataforma.

El TIMI es una capa de aproximadamente 430 instrucciones de máquina virtual independiente del hardware real. Cuando compilás un programa RPG o COBOL, el compilador genera un MI Program Template — código intermedio TIMI, no código nativo. Este template se almacena dentro del objeto *PGM.

El proceso de traducción

Cuando el programa se ejecuta por primera vez (o después de un cambio de hardware), el componente Translator del SLIC convierte las instrucciones TIMI en código nativo POWER. Este código nativo se cachea dentro del objeto, pero puede regenerarse en cualquier momento. Por eso IBM pudo migrar de CISC → RISC → POWER sin romper ningún programa.

¿Qué contiene un objeto *PGM?

Cada programa compilado en IBM i almacena ambas representaciones:

Single-Level Storage

En x86, tenés una clara separación entre RAM y disco. Los programas deben manejar explícitamente la carga de datos desde disco a memoria. En IBM i, la RAM y el disco se ven como un único espacio de direcciones de 128 bits.

¿Cómo funciona en la práctica?

Cuando un programa referencia un objeto (por ejemplo, abre un archivo), no hay una operación de "carga desde disco". El objeto ya tiene una dirección en el espacio unificado. El hardware y el SLIC se encargan de traerlo a RAM si no está ahí (page fault), exactamente como funciona la memoria virtual en x86, pero extendido a todo el almacenamiento.

Direccionamiento de 128 bits y Teraspace

IBM i usa internamente punteros de 128 bits (16 bytes), llamados System Pointers. Cada puntero contiene:

Teraspace

A partir de V5R1, IBM i introdujo Teraspace, un modelo de memoria plana de hasta 1 TB por proceso. Esto complementa el modelo original de 16 MB por segmento (Single-Level Storage), permitiendo a programas ILE usar punteros de espacio plano tipo C/C++ más familiares.

• Modelo original: Segmentos de 16 MB, accesados con punteros de 128 bits
• Teraspace: Espacio plano de 1 TB, accesado con punteros de 64 bits (más eficientes)
• Ambos modelos coexisten — los programas eligen cuál usar en compilación

Todo es un objeto

En IBM i, absolutamente todo es un objeto tipado encapsulado: programas, archivos, colas de mensajes, perfiles de usuario, bibliotecas, dispositivos, hasta las descripciones de trabajo. Cada objeto tiene:

• Nombre: Hasta 10 caracteres (modelo clásico) o nombre largo vía SQL/IFS
• Tipo: Identificado con prefijo * — hay más de 100 tipos
• Biblioteca (Library): Contenedor donde vive el objeto
• Atributo: Sub-clasificación (ej. un *PGM puede ser RPGLE, CLLE, CBL)
• Propietario: Perfil de usuario que lo creó
• Autoridad: Permisos de acceso (similar a chmod pero más granular)

Tipos de objetos comunes:

Estructura interna de un objeto

Todo objeto en IBM i tiene una estructura interna consistente:

Integridad de objetos y Tagged Storage

IBM i implementa un mecanismo de seguridad a nivel de hardware llamado tagged storage. Cada byte de memoria tiene un bit de tag adicional que indica si contiene un puntero válido del sistema.

Esto significa que un programa no puede acceder a un objeto para el que no tiene un puntero válido otorgado por el sistema. Es una capa de seguridad por hardware que no existe en x86 y que hace a IBM i inherentemente más resistente a ciertas categorías de ataques.

Procesadores IBM POWER

Los servidores IBM i corren exclusivamente en procesadores IBM POWER(Performance Optimization With Enhanced RISC). La generación actual es POWER10, fabricado en 7nm.

Diferencias clave vs x86

• SMT-8: Cada core puede ejecutar hasta 8 threads simultáneos (x86 tiene SMT-2 / Hyper-Threading)
• Caché L3 masivo: Hasta 120 MB de L3 por chip en POWER10
• Bandwidth de memoria: Subsistema de memoria Open Memory Interface (OMI) muy superior a DDR5 en throughput
• RAS (Reliability, Availability, Serviceability): Memoria redundante, CPU de repuesto automático, diagnostico en caliente
• Virtualización en hardware: El hipervisor PowerVM corre en firmware, no como software sobre el SO

Gestión de memoria — Memory Pools

IBM i divide la memoria disponible en pools (piletas). Cada pool es una porción de RAM reservada para un propósito. Esto evita que un proceso o subsistema acapare toda la memoria.

Además se pueden crear pools privados (pool 1-64) para subsistemas específicos.

Tuning: Faults por segundo

El indicador clave de performance en IBM i es fault rate — cuántas veces por segundo el sistema necesita traer páginas desde disco porque no estaban en RAM. Se monitorea con:

WRKSYSSTS          Ver estado del sistema, pools y fault rates
WRKSHRPOOL         Trabajar con shared pools
CHGSHRPOOL         Cambiar tamaño/actividad de un pool
WRKDSKSTS          Ver estado de los discos (I/O wait)

Almacenamiento — ASPs (Auxiliary Storage Pools)

El almacenamiento en IBM i se organiza en ASPs — agrupaciones lógicas de discos. Es el equivalente a LVM (Logical Volume Manager) en Linux, pero integrado en el SO.

Protección de disco

• Mirroring: IBM i soporta mirroring a nivel de SO (no necesita RAID del controlador)
• Device parity (RAID 5/6): Protección a nivel de controlador de disco
• Hot spare: Discos de repuesto que entran automáticamente si falla uno

Proceso de compilación (ILE)

El modelo ILE (Integrated Language Environment) define un proceso de compilación en dos fases que permite combinar módulos escritos en diferentes lenguajes.

También existen comandos "one-step" que combinan ambas fases:

Binding Directories

Un *BNDDIR es una lista de módulos y service programs que el binder puede resolver automáticamente. Es el equivalente al -L / -l de gcc o al LD_LIBRARY_PATH.

LPARs — Particiones Lógicas

LPAR (Logical PARtition) permite dividir un único servidor físico IBM Power en múltiples "servidores virtuales" independientes. Cada LPAR tiene su propio SO, memoria, procesadores, almacenamiento y red. Las LPARs están completamente aisladas entre sí.

Comparación con virtualización x86

DLPAR y Micro-Partitioning

DLPAR — Dynamic LPAR

DLPAR permite agregar o quitar CPU, memoria y adaptadores de I/O a una LPAR en caliente, sin detener el SO. Esto se hace desde la HMC y los cambios son inmediatos.

• Agregar 2 CPUs a producción porque hay pico de fin de mes → sin reiniciar
• Quitar memoria de desarrollo y dársela a producción → inmediato
• Los cambios pueden ser permanentes o temporales

Micro-Partitioning

PowerVM permite asignar fracciones de procesador tan pequeñas como 1/100 de un core (0.01 CPU). Esto se llama Shared Processor Pool.

VIOS — Virtual I/O Server

El VIOS es una LPAR especial que corre AIX y actúa como intermediario para virtualizar recursos de I/O (discos y red). Permite que LPARs que no tienen adaptadores físicos propios accedan a almacenamiento y red.

HMC — Hardware Management Console

La HMC es una máquina (o VM) separada que corre Linux y se conecta al servidor Power para administrar particiones. Desde la HMC podés:

• Crear, modificar y eliminar LPARs
• Asignar y mover recursos dinámicamente (DLPAR)
• Encender/apagar particiones individuales
• Ver logs de hardware y alertas
• Ejecutar Live Partition Mobility (migrar LPAR entre servidores)
• Actualizar firmware del servidor
• Acceder a la consola virtual de cada LPAR

Las HMC modernas también ofrecen una REST API para automatización, y existe la opción de HMC Virtual Appliance (vHMC) que corre como VM en lugar de requerir hardware dedicado.

IPL — Initial Program Load

En IBM i, el proceso de arranque se llama IPL (Initial Program Load). No se dice "reboot" sino "hacer un IPL". Es un proceso significativamente más complejo que un boot de Linux porque el sistema reconstruye estructuras internas.

Tipos de IPL

Fases del IPL

Alta disponibilidad y Journaling

Journaling (el equivalente a WAL)

El journaling de IBM i es equivalente al Write-Ahead Log (WAL) de PostgreSQL o al redo log de Oracle. Cada cambio a un archivo/tabla se registra primero en un journal receiver antes de aplicarse.

El journaling sirve para múltiples propósitos:

• Recovery: Después de un IPL anormal, el sistema replays los journals para recuperar datos
• Auditoría: Registro completo de quién cambió qué y cuándo
• Replicación: Herramientas como MIMIX o iCluster leen journals para replicar datos a otro sistema
• Commitment control: Transacciones ACID usando journals como redo/undo log

Commitment Control (Transacciones)

IBM i soporta transacciones ACID completas a nivel de SO (no solo de la base de datos). Un commit point puede abarcar múltiples archivos, data areas, y hasta colas de datos.

Clustering y replicación

System Values

Los System Values son los parámetros de configuración global del sistema. En x86 serían equivalentes a una combinación de sysctl, /etc/security y Group Policy. Hay más de 200.

DSPSYSVAL QSECURITY       Ver el valor actual de QSECURITY
WRKSYSVAL *ALL            Listar todos los system values
CHGSYSVAL QSECURITY VALUE('40')   Cambiar nivel de seguridad
DSPSYSVAL *SEC            Ver todos los de categoría seguridad

Licenciamiento — CPW y P-Groups

El modelo de licenciamiento de IBM i es único. Se basa en la capacidad del procesador, no en el número de usuarios o cores.

CPW — Commercial Processing Workload

CPW es un benchmark propietario de IBM que mide la capacidad de procesamiento comercial (transacciones tipo ERP/negocio). Cada modelo de servidor tiene un CPW rating publicado.

P-Groups (Performance Groups)

IBM agrupa los servidores en P-Groups según su rango de CPW. El costo de licencia del SO y de productos IBM depende del P-Group del servidor.