IBM i

OS/400 se desarrolló junto con la plataforma de hardware AS/400 a partir de diciembre de 1985.[4] El desarrollo comenzó después de la falla del Fort Knox, que dejó a IBM sin un sistema de rango medio competitivo.[10][11] Durante el proyecto Fort Knox, los ingenieros iniciaron un proyecto Skunkworks en Rochester, que logró desarrollar código que permitía que las aplicaciones System/36 se ejecutaran sobre System/38,[12] y cuando se canceló Fort Knox, este proyecto se convirtió en un proyecto oficial para reemplazar System/36 y System/38 con una nueva plataforma única de hardware y software.[4] El proyecto se conoció como Silverlake (llamado así por Silver Lake en Rochester, Minnesota).[13][12][14]

El sistema operativo de Silverlake recibió el nombre en código XPF (CPF extendido), y originalmente había comenzado como un port de CPF para el hardware del Fort Knox.[4] Además de agregar soporte para aplicaciones System/36, algunas de las funciones de interfaz de usuario y facilidad de uso del System/36 se transfirieron al nuevo sistema operativo.[1]

Silverlake estuvo disponible para pruebas de campo en junio de 1988 y se anunció oficialmente en agosto de ese año. En ese momento, se le cambió el nombre a Application System/400 (Sistema de Aplicaciones/400), y el sistema operativo se llamó Operating System/400 (Sistema operativo/400).[12]

El port a PowerPC requirió una reescritura de la mayor parte del código debajo de TIMI. Las primeras versiones de OS/400 heredaron las capas microcódigo horizontal y vertical del System/38, aunque se les cambió el nombre a Código Interno Licenciado Horizontal (HLIC) y Código Interno Licenciado Vertical (VLIC) respectivamente.[15] El port al nuevo hardware llevó a que el conjunto de instrucciones IMPI y el microcódigo horizontal que lo implementaba fueran reemplazados por el conjunto de instrucciones PowerPC AS y su implementación en los procesadores PowerAS. Esto requirió que el VLIC se reescribiera para apuntar a PowerPC en lugar de IMPI, y que la funcionalidad del sistema operativo previamente implementada en el HLIC se volviera a implementar en otro lugar.[1] Esto condujo al HLIC y al VLIC siendo reemplazado por una sola capa llamada «Código interno con licencia del sistema» (SLIC). El SLIC se implementó en un estilo orientado a objetos con más de 2 millones de líneas de código C++, reemplazando parte del código HLIC y la mayor parte del código VLIC.[16][17] Debido a la cantidad de trabajo necesario para implementar el SLIC, IBM Rochester contrató a varios cientos de programadores de C++ para el proyecto, quienes trabajaron en SLIC en paralelo con las nuevas revisiones de VLIC para los sistemas CISC AS/400.[1] La primera versión del OS/400 para admitir hardware basado en PowerPC era la V3R6.[18][19]

Logotipo de IBM i5/OS

La línea de productos AS/400 cambió de nombre varias veces durante las décadas de 1990 y 2000.[15] Como parte del cambio de nombre de 2004 a eServer i5, OS/400 pasó a llamarse ' 'i5/OS'; el 5 significa el uso de procesadores POWER5.[20] IBM describió la primera versión de i5/OS, V5R3, como «un nombre diferente para el mismo sistema operativo».[21]

En 2006, IBM cambió el nombre de la línea AS/400 por última vez a System i.[22] En abril de 2008, IBM consolidó System i con la plataforma System p para crear IBM Power Systems.[23] Al mismo tiempo, se cambió el nombre de i5/OS a IBM i para eliminar la asociación con los procesadores POWER5.[24] Las dos versiones más recientes del sistema operativo en ese momento, que se habían lanzado como i5/OS V5R4 y V6R1,[25][26] fueron renombradas como IBM i 5.4 y 6.1.[27][28][29][30]

Junto con el cambio de marca a IBM i, IBM cambió la nomenclatura de versiones para el sistema operativo. Los lanzamientos anteriores usaban un esquema de "Versión, lanzamiento, modificación", p.e. V2R1M1. Esto fue reemplazado por un esquema Version.Release, p. 6.1.[31] A partir de IBM i 7.1, IBM reemplazó las versiones de modificación con Actualizaciones de tecnología.[29] Las actualizaciones tecnológicas se entregan como PTF para versiones específicas del sistema operativo que agregan nuevas funciones o soporte de hardware al sistema.[32]

El TIMI aísla a los usuarios y las aplicaciones del hardware subyacente. Este aislamiento es más completo que las abstracciones de hardware de otros sistemas operativos e incluye la abstracción de la arquitectura del conjunto de instrucciones del procesador, el tamaño del espacio de direcciones y los detalles de E/S y persistencia.[15] Esto se logra a través de dos mecanismos interrelacionados:[1]

• Los compiladores para IBM i no generan código de máquina nativo directamente, sino que generan una representación intermedia de alto nivel definida por el TIMI. Cuando se ejecuta un programa, el sistema operativo lleva a cabo la traducción de las instrucciones TIMI al código de máquina nativo para el procesador, y almacena el código de máquina generado para la ejecución futura del programa. Si el proceso de traducción cambia, o se adopta un conjunto de instrucciones de CPU diferente, el sistema operativo puede regenerar de forma transparente el código de máquina a partir de las instrucciones TIMI sin necesidad de volver a compilar el código fuente.
• En lugar de operar sobre direcciones de memoria, las instrucciones TIMI operan sobre objetos. Todos los datos en IBM i, como archivos de datos, código fuente, programas y regiones de memoria asignada, están encapsulados dentro de objetos administrados por el sistema operativo (cf. el modelo «todo es un archivo» en Unix). Los objetos de IBM i tienen un tipo fijo, que define el conjunto de operaciones aplicables que se pueden realizar en ellos (por ejemplo, un objeto Programa se puede ejecutar, pero no se puede editar). El modelo de objetos oculta si los datos se almacenan en almacenamiento primario o secundario. En cambio, el sistema operativo maneja automáticamente el proceso de recuperación y luego almacena los cambios en el almacenamiento permanente.

El aislamiento de hardware provisto por TIMI permitió a IBM reemplazar la arquitectura IMPI de 48 bits del AS/400 con la arquitectura RS64 de 64 bits en 1995. Las aplicaciones compiladas en sistemas que usan el conjunto de instrucciones IMPI podrían ejecutarse sobre los nuevos sistemas RS64 sin cambios de código, recompilación o emulación, al mismo tiempo que permite que esas aplicaciones aprovechen el direccionamiento de 64 bits.[8]

Hay dos formatos diferentes de instrucciones TIMI, conocidos como formatos de Interfaz de máquina original (OMI) y Interfaz de máquina nueva (NMI).[38] Las instrucciones OMI son esencialmente las mismas que las instrucciones #Interfaz de máquina del System/38, mientras que las instrucciones NMI son de nivel inferior, se asemejan al formato de representación intermedia código W utilizado por los compiladores de IBM.[1] IBM documenta parcialmente las instrucciones OMI,[39] mientras que las instrucciones de NMI no están documentadas oficialmente. Las instrucciones OMI son utilizadas por los compiladores AS/400 originales, mientras que las instrucciones NMI son utilizadas por los compiladores Integrated Language Environment.[1] Durante el port a PowerPC, se eliminó el soporte nativo para el formato OMI y se reemplazó con un traductor que convirtió las instrucciones OMI en instrucciones NMI.

El almacenamiento de las instrucciones TIMI junto con las instrucciones del código máquina nativo se conoce como «observabilidad». En 2008, el lanzamiento de i5/OS V6R1 (más tarde conocido como IBM i 6.1) introdujo una serie de cambios en la capa TIMI que causaron problemas para el software de terceros que eliminaron la observabilidad de los objetos de aplicación enviados a los clientes.[40]

IBM i durante carga del programa inicial del SLIC

El SLIC consta del código que implementa el TIMI sobre la arquitectura IBM Power. Además de contener la mayor parte de la funcionalidad típicamente asociada con un núcleo de sistema operativo, es responsable de traducir las instrucciones TIMI a código de máquina, y también implementa algunas funciones de alto nivel que se exponen a través del TIMI, como la base de datos relacional integrada de IBM i.[1] El SLIC implementa el modelo de almacenamiento basado en objetos de IBM i sobre un esquema de direccionamiento de almacenamiento de un solo nivel, que no distingue entre el almacenamiento primario y secundario y, en su lugar, administra todos los tipos de almacenamiento en un único espacio de direcciones virtuales.[41] El SLIC se implementa principalmente en C++ y reemplazó a HLIC y VLIC, utilizados en versiones de OS/400 anteriores a V3R6.[16]

El XPF consta del código que implementa los componentes independientes del hardware del sistema operativo, que se compilan en instrucciones TIMI.[16] Los componentes del XPF incluyen la interfaz de usuario, el lenguaje de control, utilidades de consulta y gestión de datos, herramientas de desarrollo y utilidades de gestión de sistemas. El XPF también contiene System/36 Environment y System/38 Environment, que proporcionan API y utilidades compatibles con versiones anteriores para aplicaciones y datos migrados desde sistemas SSP y CPF.[42] XPF es el nombre interno de IBM para esta capa y, como sugiere el nombre, comenzó como una evolución del Control Program Facility de System/38.[1] El XPF se implementa principalmente en PL/MI, aunque también se utilizan otros lenguajes.[43]

PASE (Portable Applications Solutions Environment) proporciona compatibilidad binaria para ejecutables AIX de modo de usuario que no interactúan directamente con el kernel de AIX, y es compatible con interfaz binaria de aplicaciones de AIX de 32 y 64 bits.[44] PASE se incluyó por primera vez de forma limitada e indocumentada en la versión V4R3 de OS/400 para admitir un puerto de Smalltalk.[4] Se anunció por primera vez a los clientes en el momento del lanzamiento de la versión V4R5, momento en el que ya había obtenido una funcionalidad adicional significativa.

PASE consta del espacio de usuario de AIX que se ejecuta sobre una interfaz de llamada del sistema implementada por SLIC.[45] Las interfaces de llamadas al sistema permiten la interoperabilidad entre PASE y aplicaciones nativas de IBM i, por ejemplo, aplicaciones PASE pueden acceder a la base de datos integrada o llamar a aplicaciones nativas de IBM i y viceversa.[46] Durante la creación de PASE, se agregó al sistema operativo un nuevo tipo de objeto de almacenamiento de un solo nivel denominado Teraspace, que permite que cada proceso de PASE tenga un espacio privado de 1 TiB que se direcciona con punteros de 64 bits.[47] Esto era necesario ya que todos los trabajos de IBM i (es decir, procesos) suelen compartir el mismo espacio de direcciones.[4] Las aplicaciones PASE no utilizan las instrucciones TIMI independientes del hardware y, en cambio, se compilan directamente en el código de máquina de Power.

PASE es distinto del entorno Qshell, que es una implementación de un shell de Unix y utilidades asociadas creadas sobre las API nativas compatibles con POSIX de IBM i. [48]

Menú principal de SSP 7.5, ejecutándose sobre el entorno Advanced 36 Machine

Introducida en 1994, la plataforma Advanced/36 ejecutaba aplicaciones System/36 sin modificar y el sistema operativo SSP en emulación sobre el OS/400 SLIC, utilizando hardware que era en su mayoría idéntico al de los sistemas AS/400 contemporáneos.[1] Esta funcionalidad se incorporó al propio OS/400 desde V3R6 hasta V4R4, lo que hace posible ejecutar hasta cuatro «máquinas virtuales» System/36 (para usar el término de IBM) utilizando la característica también llamada Advanced 36 Machine del sistema operativo.[49] El soporte se suspendió en la versión V4R5, coincidiendo con la discontinuación de IBM de la línea de productos Advanced/36 en su totalidad.[50] La función Advanced 36 Machine es distinta del System/36 Environment introducido en la versión inicial de OS/400 y aún es compatible con las versiones actuales de IBM i.

Antes de Advanced/36, la línea System/36 usaba dos procesadores diferentes en cada sistema: el Procesador de almacenamiento principal (MSP) que ejecutaba la mayor parte del sistema operativo SSP, así como el código de usuario, y el Procesador de almacenamiento de control (CSP) que ejecutó el llamado «microcódigo» que implementó la funcionalidad central del sistema operativo, así como la E/S. El microcódigo CSP se invocó desde el MSP mediante el uso de la instrucción Supervisor Call (SVC). En Advanced/36, el microcódigo CSP se volvió a implementar dentro del SLIC. También se incorporó un emulador de MSP en el SLIC, a veces denominado «Interfaz de emulación independiente de la tecnología». Incluso con la sobrecarga de la emulación, los sistemas Advanced/36 fueron significativamente más rápidos que los sistemas System/36 originales que reemplazaron debido al rendimiento de sus procesadores PowerPC AS.[1]

IBM i presenta una base de datos relacional integrada actualmente conocida como IBM Db2 para IBM i.[37] La base de datos evolucionó a partir de la base de datos no relacional System/38, obteniendo soporte para el modelo relacional y SQL.[1] Originalmente, la base de datos no tenía nombre, sino que se describía simplemente como «soporte de base de datos».[51] Se le dio el nombre DB2/400 en 1994 para indicar una funcionalidad comparable a la de otras bases de datos comerciales de IBM.[1] A pesar de la marca Db2, Db2 para IBM i es una base de código completamente separada de Db2 en otras plataformas, y está estrechamente integrada en la capa SLIC de IBM i en lugar de ser un producto opcional.[52][53]

IBM i proporciona dos mecanismos para acceder a la base de datos integrada: la llamada «interfaz nativa», que se basa en el modelo de acceso a la base de datos de System/38, y SQL.[1] La interfaz nativa consta del lenguaje Especificaciones de descripción de datos (DDS), que se utiliza para definir esquemas y el comando <código>OPNQRYF</código> o la API de consulta <código>QQQQRY</código>.[54] Ciertas funciones de Db2 para i como Gestión de base de datos objetos relacional requieren SQL y no se puede acceder a través de la interfaz nativa.[55] IBM i tiene dos optimizadores de consultas separados conocidos como Motor de consulta clásico (CQE) y Motor de consulta SQL (SQE).[56] Estos se implementan dentro del SLIC junto con un Despachador de consultas que selecciona el optimizador apropiado según el tipo de consulta. El acceso remoto a través de la interfaz nativa y SQL lo proporciona la Arquitectura de administración de datos distribuidos (DDM) y la Arquitectura de base de datos relacional distribuida respectivamente.[57]

Un motor de almacenamiento para MySQL y MariaDB denominado <código>IBMDB2I</código> permite que las aplicaciones diseñadas para esas bases de datos utilicen Db2 para i como almacenamiento de respaldo.[58][59] Se han portado otras bases de datos de código abierto a IBM i, incluidas PostgreSQL, MongoDB y Redis.< ref name="open-source-db" /> Estas bases de datos se ejecutan en el entorno PASE y son independientes de las funciones de base de datos integradas del sistema operativo.[60]

IBM i admite redes TCP/IP además de la Systems Network Architecture (Arquitectura de red de sistemas) patentada de IBM.[61]

Históricamente, se accedía a los sistemas IBM i y se administraban a través de terminales IBM 5250 conectados al sistema con cableado twinax. Con el declive del hardware de terminal dedicado, los sistemas IBM i modernos generalmente se acceden a través de emulador de terminal 5250. IBM proporciona dos productos de emulación de terminal para IBM i:[62]

• IBM i Access Client Solutions es un cliente basado en Java que se ejecuta en Linux, macOS y Windows para proporcionar emulación 5250.
• IBM i Access para Web/Móviles proporciona emulación 5250 basada en web.

Además, IBM proporciona una consola de gestión basada en web y un producto de análisis de rendimiento denominado IBM Navigator for i.[63]

Algunas de las aplicaciones de código abierto portadas a IBM i incluyen:[64][65]

El software de código abierto para IBM i generalmente se empaqueta con el formato RPM y se instala con el gestor de paquetes YUM.[67] YUM y RPM reemplazaron el producto 5733-OPS, que se utilizó anteriormente para instalar software de código abierto en IBM i.[68] Ports de software de código abierto a IBM i normalmente apunta a PASE en lugar de las API nativas de IBM i para simplificar la migración.[69]

Los lenguajes de programación disponibles de IBM para IBM i incluyen RPG, Lenguaje de control, C, C++, Java, EGL, COBOL y REXX. Los compiladores para Pascal, BASIC, PL/I y Smalltalk estaban disponibles anteriormente, pero desde entonces han sido descontinuados. El Integrated Language Environment (ILE) permite que los programas de los lenguajes compatibles con ILE (C, C++, COBOL, RPG y CL) se vinculen al mismo ejecutable y llamen a los procedimientos escritos en cualquiera de los otros lenguajes ILE.

Cuando se introdujo PASE, fue necesario compilar código para PASE en un sistema AIX. Este requisito se eliminó en OS/400 V5R2 cuando fue posible compilar código usando los conjunto de compiladores IBM XL dentro de PASE mismo.[70] Desde entonces, otros compiladores han sido portados a PASE, incluyendo gcc.[71]

Ciertas herramientas de desarrollo para IBM i se ejecutan sobre el propio sistema operativo, como el editor de texto Source Edit Utility (SEU) y el Programming Development Manager. IBM también proporciona un entorno de desarrollo integrado (IDE) Eclipse para IBM i llamado IBM Rational Developer for i que se ejecuta en estaciones de trabajo de desarrollador en lugar de IBM i.[72] Antes del IDE basado en Eclipse, IBM proporcionó un IDE basado en WorkFrame/2 que se ejecutaba en OS/2 llamado CODE/400 y un IDE basado en VisualAge que se ejecutaba en sistemas Microsoft Windows.[73][74]

IBM i utiliza EBCDIC como la codificación de caracteres predeterminada, pero también proporciona soporte para ASCII, UCS-2 y UTF-16.[1][75]

En IBM i, las unidades de disco se pueden agrupar en un «grupo de almacenamiento auxiliar» (ASP) para organizar los datos y limitar el impacto de las fallas en los dispositivos de almacenamiento, y reducir el tiempo de recuperación.[76] Si se produce una falla en el disco, solo es necesario recuperar los datos del grupo que contiene la unidad fallada. Los ASP también se pueden utilizar para mejorar el rendimiento aislando objetos con características de rendimiento similares, por ejemplo, receptores de diario, en su propia agrupación.

De forma predeterminada, todas las unidades de disco se asignan al grupo 1. El concepto de grupos de IBM i es similar al concepto Unix/Linux de grupos de volúmenes; sin embargo, con IBM i es habitual que todas las unidades de disco se asignen a una sola ASP.

La seguridad en IBM i se define en términos de «autoridades», lo que representa el permiso para llevar a cabo una acción específica en un objeto específico.[77] Las autorizaciones se pueden otorgar a usuarios individuales (conocidos como perfiles de usuario), grupos (conocidos como perfiles de grupo) o todos los usuarios (autoridades públicas). Los objetos relacionados se pueden agrupar en una «lista de autorizaciones», lo que permite otorgar autorizaciones sobre todos los objetos en la lista otorgando autorizaciones sobre la lista de autorizaciones.[78]

Los perfiles de usuario tienen una «clase de usuario» asociada que dicta el conjunto de autoridades predeterminadas disponibles para ese perfil de usuario. Hay cinco clases de usuarios estándar que, en orden creciente de privilegios, son: «Usuario de la estación de trabajo», «Operador del sistema», «Programador del sistema», «Administrador de seguridad» y «Oficial de seguridad».[4] IBM i se envía con un perfil de usuario predeterminado para cada clase de usuario, y el perfil de usuario predeterminado del oficial de seguridad, llamado <código>QSECOFR</código>, es el equivalente más cercano al usuario root de un sistema operativo similar a Unix.[79]

IBM i se puede configurar para utilizar uno de los cinco niveles de seguridad, que controlan el grado en que se aplican las funciones de seguridad del sistema operativo:[80]

• Nivel 10: los usuarios pueden iniciar sesión sin contraseña y tener acceso completo al sistema. Si un usuario inicia sesión con un nombre de usuario desconocido, se creará automáticamente un nuevo perfil de usuario.
• Nivel 20: los usuarios deben iniciar sesión con un nombre de usuario y contraseña en un perfil de usuario conocido, pero tendrán acceso casi completo al sistema una vez que inicien sesión. Se pueden crear cuentas de acceso limitado, que pueden restringirse para acceder a ciertos objetos o ejecutar ciertos comandos. La creación o modificación de perfiles de usuario requiere ciertas autorizaciones.
• Nivel 30: se aplican las autoridades, lo que significa que los usuarios no pueden acceder a los objetos a menos que tengan una autoridad para el objeto.
• Nivel 40: el acceso a ciertos programas del sistema e instrucciones MI está restringido y solo puede usarse mediante el código del sistema operativo.
• Nivel 50: incluye los cambios necesarios para que el sistema logre el cumplimiento de TCSEC C2 y agrega un diario de auditoría de seguridad.

Los primeros tres niveles corresponden a los niveles de seguridad disponibles en CPF y las versiones iniciales de OS/400. El nivel de seguridad 40 se agregó en OS/400 V1R3 y se convirtió en el nivel de seguridad predeterminado para el sistema operativo. La adición del nivel 40 requirió la eliminación del modelo de direccionamiento basado en la capacidad del System/38 que también estaba presente en versiones anteriores de OS/400.[4] Se agregó el nivel de seguridad 50 en V2R3 cuando OS/400 fue certificado con TCSEC C2.