IBM i (la i significa integrado ) [6] es un sistema operativo desarrollado por IBM para IBM Power Systems . [7] Fue lanzado originalmente en 1988 como OS/400 , como el único sistema operativo de la línea de sistemas IBM AS/400 . Fue renombrado a i5/OS en 2004, antes de ser renombrado por segunda vez a IBM i en 2008. [8] [9] Es una evolución del sistema operativo System/38 CPF , [5] con capas de compatibilidad para aplicaciones System/36 SSP y AIX . [5] Hereda una serie de características distintivas de la plataforma System/38, incluyendo la Interfaz de Máquina que proporciona independencia de hardware, la implementación de direccionamiento basado en objetos sobre un almacenamiento de un solo nivel y la estrecha integración de una base de datos relacional en el sistema operativo. [1]
El sistema operativo OS/400 se desarrolló junto con la plataforma de hardware AS/400 a partir de diciembre de 1985. [5] El desarrollo comenzó tras el fracaso del proyecto Fort Knox , que dejó a IBM sin un sistema de gama media competitivo. [10] [11] Durante el proyecto Fort Knox, un proyecto skunkworks se inició en Rochester por ingenieros, que lograron desarrollar código que permitió que las aplicaciones System/36 se ejecutaran sobre el System/38, [12] y cuando Fort Knox se canceló, este proyecto se convirtió en un proyecto oficial para reemplazar tanto el System/36 como el System/38 con una única nueva plataforma de hardware y software. [5] El proyecto se conoció como Silverlake (nombrado por Silver Lake en Rochester, Minnesota ). [13] [12] [14]
El sistema operativo para Silverlake tenía el nombre en código XPF (Extended CPF ) y originalmente había comenzado como un puerto de CPF para el hardware de Fort Knox. [5] Además de agregar soporte para aplicaciones System/36, algunas de las características de interfaz de usuario y facilidad de uso de System/36 se trasladaron 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 había cambiado el nombre a Application System/400 y el sistema operativo se había denominado Operating System/400 . [12]
El puerto a PowerPC requirió una reescritura de la mayor parte del código debajo del TIMI. Las primeras versiones de OS/400 heredaron las capas de microcódigo horizontal y vertical del System/38, aunque se les cambió el nombre a Código interno con licencia horizontal (HLIC) y Código interno con licencia vertical (VLIC) respectivamente. [15] El puerto 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 procesadores PowerAS. Esto requirió que el VLIC fuera reescrito para apuntar a PowerPC en lugar de IMPI, y que la funcionalidad del sistema operativo previamente implementada en el HLIC fuera reimplementada en otro lugar. [1] Esto llevó a que el HLIC y el VLIC fueran reemplazados por una sola capa llamada Código interno con licencia del sistema (SLIC). El SLIC fue implementado 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 el SLIC en paralelo a las nuevas revisiones del VLIC para los sistemas CISC AS/400. [1] La primera versión de OS/400 que admitió hardware basado en PowerPC fue V3R6. [18] [19]
La línea de productos AS/400 fue renombrada varias veces durante los años 1990 y 2000. [15] Como parte del cambio de marca de 2004 a eServer i5 , OS/400 pasó a llamarse i5/OS ; el 5 significa el uso de procesadores POWER5 . [20] La primera versión de i5/OS, V5R3, fue descrita por IBM como "un nombre diferente para el mismo sistema operativo". [21]
En 2006, IBM renombró la línea AS/400 por última vez a System i . [22] En abril de 2008, IBM consolidó el System i con la plataforma System p para crear IBM Power Systems . [23] Al mismo tiempo, i5/OS fue renombrado 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 a 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 del sistema operativo. Las versiones anteriores utilizaban un esquema de Versión, Lanzamiento, Modificación , p. ej. V2R1M1. Esto fue reemplazado por un esquema de Versión.Lanzamiento , p. ej. 6.1. [31] A partir de IBM i 7.1, IBM reemplazó los lanzamientos de Modificación con Actualizaciones de Tecnología . [29] Las Actualizaciones de Tecnología se entregan como PTF opcionales para lanzamientos específicos del sistema operativo que agregan nueva funcionalidad o soporte de hardware al sistema operativo. [32]
Cuando IBM i se lanzó por primera vez como OS/400, se dividió en dos capas, el Código interno bajo licencia del sistema (SLIC) dependiente del hardware [15] [1] y el Extended Control Program Facility (XPF) independiente del hardware. [16] [8] [33] [34] Estas están divididas por una capa de abstracción de hardware llamada Technology Independent Machine Interface (TIMI). Las versiones posteriores del sistema operativo obtuvieron capas adicionales, incluida una capa de compatibilidad con AIX llamada Portable Application Solutions Environment (originalmente conocido como Private Address Space Environment ), [5] [35] y el entorno Advanced 36 Machine que ejecutaba aplicaciones System/36 SSP en emulación. [1]
IBM suele utilizar diferentes nombres para TIMI, SLIC y XPF en la documentación y los materiales de marketing, [36] por ejemplo, la documentación de IBM i 7.4 se refiere a ellos como IBM i Machine Interface , IBM i Licensed Internal Code y IBM i Operating System respectivamente. [37]
La TIMI aísla a los usuarios y las aplicaciones del hardware subyacente. Este aislamiento es más exhaustivo 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 las particularidades de la E/S y la persistencia. [15] Esto se logra mediante dos mecanismos interrelacionados: [1]
El aislamiento de hardware proporcionado por el 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 usaban el conjunto de instrucciones IMPI podían ejecutarse sobre los sistemas RS64 más nuevos sin ningún cambio de código, recompilación o emulación, al mismo tiempo que permitían que esas aplicaciones se beneficiaran del direccionamiento de 64 bits. [8]
Existen dos formatos diferentes de instrucciones TIMI, conocidos como los formatos Original Machine Interface (OMI) y New Machine Interface (NMI). [38] Las instrucciones OMI son esencialmente las mismas que las instrucciones de la interfaz System/38 Machine , mientras que las instrucciones NMI son de nivel inferior, y se asemejan al formato de representación intermedia del código W utilizado por los compiladores de IBM. [1] IBM documenta parcialmente las instrucciones OMI, [39] mientras que las instrucciones NMI no están documentadas oficialmente. Las instrucciones OMI son utilizadas por los compiladores originales del AS/400, mientras que las instrucciones NMI son utilizadas por los compiladores del Integrated Language Environment . [1] Durante la adaptación a PowerPC, se eliminó el soporte nativo para el formato OMI y se reemplazó con un traductor que convertía las instrucciones OMI en instrucciones NMI.
El almacenamiento de las instrucciones TIMI junto con las instrucciones del código de 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 eliminó la observabilidad de los objetos de aplicación enviados a los clientes. [40]
.png/1280px-Os400-lic-ipl_(screenshot).png)
El SLIC consiste en el código que implementa el TIMI sobre la arquitectura IBM Power. Además de contener la mayoría de las funciones típicamente asociadas 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 almacenamiento primario y secundario, y en su lugar administra todos los tipos de almacenamiento en un solo espacio de direcciones virtuales . [41] El SLIC se implementa principalmente en C++ y reemplazó las capas HLIC y VLIC utilizadas en versiones de OS/400 anteriores a V3R6. [16]
El XPF consiste en el 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 del sistema. El XPF también contiene el entorno System/36 y el entorno System/38 , que proporcionan API y utilidades de compatibilidad con versiones anteriores para aplicaciones y datos migrados desde sistemas SSP y CPF. [42] El XPF es el nombre interno de IBM para esta capa y, como sugiere el nombre, comenzó como una evolución del System/38 Control Program Facility . [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 en modo usuario que no interactúan directamente con el núcleo AIX, y admite las interfaces binarias de aplicación AIX de 32 y 64 bits . [44] PASE se incluyó por primera vez en una forma limitada y no documentada en la versión V4R3 de OS/400 para admitir un puerto de Smalltalk . [5] Se anunció por primera vez a los clientes en el momento del lanzamiento de V4R5, momento en el que había ganado una funcionalidad adicional significativa.
PASE consiste en el espacio de usuario AIX que se ejecuta sobre una interfaz de llamada del sistema implementada por el SLIC. [45] Las interfaces de llamada del sistema permiten la interoperabilidad entre PASE y las aplicaciones nativas de IBM i, por ejemplo, las 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 llamado Teraspace , que permite que cada proceso PASE tenga un espacio privado de 1TiB que se direcciona con punteros de 64 bits. [47] Esto era necesario ya que todos los trabajos de IBM i (es decir, procesos) generalmente comparten el mismo espacio de direcciones. [5] Las aplicaciones PASE no utilizan las instrucciones TIMI independientes del hardware y, en su lugar, se compilan directamente en código de máquina Power.
Los puertos de software de código abierto para IBM i generalmente apuntan a PASE en lugar de las API nativas de IBM i para simplificar la portabilidad. [48] El software de código abierto para IBM i generalmente se empaqueta utilizando el formato de paquete RPM y se instala con el administrador de paquetes YUM . [49] [50]
PASE se distingue del entorno Qshell , que es una implementación de un shell Unix y utilidades asociadas construidas sobre las API nativas compatibles con POSIX de IBM i. [51]
Introducida en 1994, la plataforma Advanced/36 ejecutaba aplicaciones System/36 sin modificar y el sistema operativo SSP en emulación sobre el SLIC OS/400 usando hardware que era en su mayor parte idéntico al de los sistemas AS/400 contemporáneos. [1] Esta funcionalidad fue incorporada al propio OS/400 desde V3R6 hasta V4R4, haciendo posible ejecutar hasta cuatro "máquinas virtuales" System/36 (para usar el término de IBM) usando la llamada característica Advanced 36 Machine del sistema operativo. [52] El soporte fue discontinuado en la versión V4R5, coincidiendo con la discontinuación por parte de IBM de la línea de productos Advanced/36 en su totalidad. [53] La característica Advanced 36 Machine es distinta del entorno System/36 introducido en la versión inicial de OS/400 y aún soportado en las versiones actuales de IBM i.
Antes del Advanced/36, la línea System/36 utilizaba 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 ejecutaba el denominado "microcódigo", que implementaba la funcionalidad básica del sistema operativo, así como la E/S. El microcódigo CSP se invocaba desde el MSP mediante el uso de la instrucción Supervisor Call (SVC). En el Advanced/36, el microcódigo CSP se reimplementaba dentro del SLIC. También se incorporó un emulador 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 eran significativamente más rápidos que los sistemas System/36 originales a los que reemplazaron debido al rendimiento de sus procesadores PowerPC AS. [1]
IBM i cuenta con una base de datos relacional integrada conocida actualmente como IBM Db2 para IBM i . [37] La base de datos evolucionó a partir de la base de datos no relacional System/38, ganando soporte para el modelo relacional y SQL . [1] La base de datos originalmente no tenía nombre, en su lugar se describía simplemente como "soporte de base de datos". [54] Se le dio el nombre DB2/400 en 1994 para indicar una funcionalidad comparable a 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. [55] [56]
IBM i proporciona dos mecanismos para acceder a la base de datos integrada: la denominada interfaz nativa , que se basa en el modelo de acceso a la base de datos del System/38, y SQL . [1] La interfaz nativa consta del lenguaje Data Description Specification (DDS), que se utiliza para definir esquemas y la API OPNQRYFde comandos o QQQQRYconsultas. [57] Algunas características de Db2 para i, como la gestión de bases de datos relacionales de objetos, requieren SQL y no se puede acceder a ellas a través de la interfaz nativa. [58] IBM i tiene dos optimizadores de consultas independientes , conocidos como Classic Query Engine (CQE) y SQL Query Engine (SQE). [59] Estos se implementan dentro del SLIC junto con un Query Dispatcher que selecciona el optimizador adecuado según el tipo de consulta. El acceso remoto a través de la interfaz nativa y SQL lo proporcionan la Arquitectura de gestión de datos distribuidos (DDM) y la Arquitectura de base de datos relacional distribuida, respectivamente. [60]
Un motor de almacenamiento para MySQL y MariaDB permite IBMDB2Ique las aplicaciones diseñadas para esas bases de datos utilicen Db2 para i como almacenamiento de respaldo. [61] [62] Otras bases de datos de código abierto se han trasladado a IBM i, incluidas PostgreSQL , MongoDB y Redis . [63] Estas bases de datos se ejecutan en el entorno PASE y son independientes de las características de base de datos integradas del sistema operativo. [64]
IBM i admite redes TCP/IP además de la arquitectura de red de sistemas patentada de IBM . [65]
Históricamente, se accedía a los sistemas IBM i y se administraban a través de terminales IBM 5250 conectadas al sistema con cableado twinaxial . Con la disminución del hardware de terminales dedicado, se accede a los sistemas IBM i modernos a través de emuladores de terminales 5250. IBM ofrece dos productos de emuladores de terminales para IBM i: [66]
Además, IBM ofrece una consola de gestión basada en web y un producto de análisis de rendimiento denominado IBM Navigator para i. [67]
Los lenguajes de programación disponibles de IBM para IBM i incluyen RPG , Control Language , C , C++ , Java , EGL , COBOL y REXX . Anteriormente, había compiladores disponibles para Pascal , BASIC , PL/I y Smalltalk , pero desde entonces se han discontinuado. El entorno de lenguaje integrado (ILE) permite que los programas de lenguajes compatibles con ILE (C, C++, COBOL, RPG y CL) se vinculen al mismo ejecutable y llamen a procedimientos escritos en cualquiera de los otros lenguajes ILE.
Cuando se introdujo PASE, era necesario compilar código para PASE en un sistema AIX. Este requisito se eliminó en OS/400 V5R2 cuando se hizo posible compilar código utilizando la suite de compiladores IBM XL dentro del propio PASE. [68] Desde entonces, otros compiladores se han adaptado a PASE, incluido gcc . [69]
Algunas herramientas de desarrollo para IBM i se ejecutan sobre el propio sistema operativo, como el editor de texto Source Edit Utility (SEU) y Programming Development Manager . IBM también proporciona un entorno de desarrollo integrado (IDE) basado en Eclipse para IBM i llamado IBM Rational Developer for i que se ejecuta en estaciones de trabajo de desarrolladores en lugar de IBM i. [70] Antes del IDE basado en Eclipse, IBM proporcionaba 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 . [71] [72]
IBM i utiliza EBCDIC como codificación de caracteres predeterminada , pero también proporciona soporte para ASCII , UCS-2 y UTF-16 . [1] [73]
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 de los dispositivos de almacenamiento y reducir el tiempo de recuperación. [74] Si se produce una falla de disco, solo es necesario recuperar los datos del grupo que contiene la unidad que falló. 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 propio grupo.
De forma predeterminada, todas las unidades de disco se asignan al pool 1. El concepto de pools de IBM i es similar al concepto de grupos de volúmenes de Unix / Linux ; sin embargo, con IBM i es típico que todas las unidades de disco se asignen a una única ASP.
La seguridad en IBM i se define en términos de autoridades , que representan el permiso para llevar a cabo una acción específica sobre un objeto específico. [75] Las autoridades 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 hace posible otorgar autoridades sobre todos los objetos de la lista otorgando autoridades en la lista de autorizaciones. [76]
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 usuario estándar que, en orden de privilegio creciente, son: Usuario de estación de trabajo , Operador de sistema , Programador de sistema , Administrador de seguridad y Oficial de seguridad . [5] IBM i se entrega con un perfil de usuario predeterminado para cada clase de usuario, y el perfil de usuario Oficial de seguridad predeterminado, denominado QSECOFR, es el equivalente más cercano al usuario raíz de un sistema operativo tipo Unix. [77]
IBM i puede configurarse para utilizar uno de cinco niveles de seguridad, que controlan hasta qué punto se aplican las características de seguridad del sistema operativo: [78]
Los tres primeros 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 de capacidad del System/38 que también estaba presente en versiones anteriores de OS/400. [5] El nivel de seguridad 50 se agregó en V2R3 cuando OS/400 recibió la certificación de seguridad TCSEC C2 .
