PDF de programación - Un vistazo atrás en la historia, a los Orígenes del OS/400

Wayne O Evans Consulting, Inc.
AS/400 Security Consulting and Education

Un vistazo atrás en la Historia,a los Orígenes del OS/400
Este artículo revisa algunos de las decisiones de diseño que se tomaron
tempranamente en el desarrollo del S/38. Esta historia del principio es
importante porque gran parte de la arquitectura del OS/400 fue heredada del
S/38.
Hace unos 20 años, cuando el S/38 estaba siendo desarrollado, el mundo nunca
había oído hablar de Microsoft o Netscape. Pero la lucha entre el gigante de las
computadoras IBM y sus competidores para conseguir cuota de mercado era tan
feroz como las batallas de hoy en día acerca del próximo navegador (browser).
La Corporación IBM había pasado por la experiencia de la pérdida de ventas
de hardware por “parecer igual ” a otros vendedores como Amdahl y otros.
Estos clones de hardware podían ejecutar el sistema operativo de IBM y los
clientes obtenían equivalente potencia de computadora a un menor coste. La
venta de hardware representaba una gran fuente de ingresos para IBM por lo
tanto esta pérdida de ventas de hardware a los vendedores de clónicos era un
negocio muy serio para los ejecutivos de IBM.
En el gran frente de los mainframe , IBM acababa de cancelar un proyecto
conocido como FS (Future Systems) que iba a ser un sustituto revolucionario
para la línea existente de computadoras mainframe de IBM. Después de varios
años de trabajo, reuniones y más reuniones y multitud de papeles con
especificaciones, la dirección de IBM determinó que el proyecto era demasiado
ambicioso incluso para IBM y abandonó el proyecto en 1975.
En el corazón de los campos de trigo de Rochester, Minnesota el S/3 y los
siguientes sistemas S/32 y S/34 estaba casi al final de una vida exitosa. El
momento para un recambio se acercaba. No existía ningún clon de hardware del
S/34 pero el temor de un clónico que reemplazara el hardware existente era muy
alto entre las preocupaciones de la dirección de IBM. Las noticias de la
defunción del FS estaban llegando lentamente a Rochester así que el grupo de
planificadores , ingenieros y programadores continuaron con su acercamiento
independiente para el diseño de un sistema para el futuro , al menos para los
clientes pequeños y medianos . Cada uno lo quería más grande, mejor, más
rápido y más barato que el envejecido entonces S/34 pero desconocían como
conseguirlo.
A prinicipio de 1975, yo me incorporé al grupo base , con menos de 25
personas, que estaba desarrollando la visión del recambio del S/34. Este
pequeño grupo tenía gente de talento con variados conocimientos. Algunos
venían de los equipos de diseño del S/3, S/32 y S/34 mientras otros tenían un
importante pasado con el S/360 y el S/370 .

Un vistazo atrás en la Historia,a los Orígenes del OS/400
 Wayne O.Evans , e-mail: [email protected]

Traducción autorizada al Español realizada por http://www.recursos-as400.com



Wayne O Evans Consulting, Inc.
AS/400 Security Consulting and Education

Interface de máquina abstracto
Cuando me incorporé al proyecto, se estaba discutiendo una idea revolucionaria.
Las palabras “objetos”, “encapsulación” y máquina abstracta eran nuevos para la
mayoría de programadores de sistema , incluído yo . En vez de tener un
conjunto de instrucciones de la computadora diseñadas por los ingenieros, los
programadores (los usuarios reales del sistema) estaban definiendo
instrucciones para una máquina abstracta. Estas instrucciones en vez de ser
optimizadas para el hardware, estaban siendo diseñadas para escribir
aplicaciones de software. Este interface de máquina abstracto sería conocido
como MI (Machine Interface) o lo que IBM normalmente llamaTIMI (technology
Independent Machine Interface). Este Interface Abstracto (MI) definió algunos
conceptos muy avanzados para hacer la programación más eficiente y menos
propensa a errores. Los programadores escribirían programas para una máquina
abstracta utilizando nuevos conceptos como la no carga de datos en los
registros del hardware para su proceso. En esta nueva máquina abstracta , los
programadores mejorarían la fiabilidad de los programas, al prevenir que los
programas pudieran desde modificar el almacenamiento hasta manipular las
direcciones de los registros. El uso de programas MI podía manipular los
punteros , pero la máquina abstracta no permitiría un cambio que pudiera causar
la corrupción de un puntero. Este interface abstracto estaba siendo diseñado
para proteger a los programadores de ellos mismos. En el hardware previo, los
programadores conocían la estructura de direcciones de los punteros y podían
incluso alterar la memoria para cambiar las direcciones (lo cual a menudo era el
motivo de los problemas de fiabilidad de los programas). En esta máquina
abstracta , estos punteros estaban encapsulados (el contenido real del puntero
no se presentaba en las aplicaciones ) lo que significaba que los programas no
podían crear un puntero al modificar un almacenamiento y sólo intrucciones de
puntero podían usarse para modificar punteros. Cualquier intento del
progaramador por alterar el almacenamiento que contenía un puntero podría
causar que el puntero se volviera inválido. Estos punteros de la máquina
abstracta eran mayores que cualquier registro de hardware y el microcódigo
traduciría el uso de los punteros a los registros reales de hardware.

La separación de la máquina real de la máquina abstracta es la responsable de
la migración con éxito del hardware CISC al hardware RISC . Otras plataformas,
están ocupadas reescribiendo los programas para conseguir direcciones de 32 o
64 bit (algunas plataformas están planificando completarlo en el 2005). Lo que
es verdaderamente fascinante es que cada aplicación del AS/400 está
capacitada para 64 bit sin ninguna modificación para el cliente ni los programas
OS/400 .
Un segundo concepto importante de este interface abstracto era el mover
muchas de las funciones del sistema operativo ( gestión de tareas , seguridad e
incluso la base de datos) al microcódigo. Puesto que estas funciones son

Un vistazo atrás en la Historia,a los Orígenes del OS/400
 Wayne O.Evans , e-mail: [email protected]

Traducción autorizada al Español realizada por http://www.recursos-as400.com



Wayne O Evans Consulting, Inc.
AS/400 Security Consulting and Education

implementadas muy cerca del interface de hardware, deberían ser programadas
eficientemente. Más importante para IBM era que esa integración de la función
del sistema operativo en el microcódigo del hardware hiciera más difícil el copiar
el hardware del S/38 . Este hecho por sí solo aseguraba que el proyecto del
S/38 obtendría la financiación de la Dirección de IBM .
Hoy,nuestra experiencia con el AS/400 prueba que este concepto de máquina
abstracta tiene mucho sentido , pero para los programadores de sistema de
1970s, esta idea era radical.
EL GRAN DEBATE
Esta idea de un interface de máquina abstracto tenía también sus críticos. Había
varios profesionales técnicos muy cualificados que argumentaban (con gran
pasión ) que un concepto como el del interface abstracto podía ser
académicamente posible pero podría provocar que la ejecución sería pobre.
Mucho esfuerzo (y emociones fuertes) se estaban dedicando a discutir y aprobar
y desaprobar la actuación del hardware directo o las implementaciones de
microcódigo.
Recuerdo el día que el asunto se resolvió. Se celebró una reunión del equipo
técnico clave una fría mañana de invierno en Rochester, MN. Los partidarios de
la máquina abstracta y sus adversarios fueron convocados en la sala de
conferencias de Glen Henry, el director de programación del sistema.Glen era
un individuo extremadamente inteligente pero como otras personas
verdaderamente dotadas carecía de habilidades para la interacción humana.
Cuando Glen Henry veía la respuesta obvia te lo decía con pocas palabras y sin
añadir ninguna dulzura. Glen proclamó el final del debate . Con gran emoción
explicó que el interface de la máquina abstracta (después se conocería como
MI) era la única posibilidad. Glen explicó como esto protegiría a IBM de
vendedores de hardware clónico. Concluyó con “o se acepta el programa o
estaré encantado de firmar el traspaso de cualquiera a otra área.”
Podemos ahora mirar atrás y ver que este interface ha sido una de las ventajas
más significativas de la arquitectura del AS/400. La separación del software del
hardware permitió el cambio radical de hardware sin modificar el software. Los
ususarios del AS/400 fueron capaces de realizar la transición desde CISC a
RISC sin ninguna interrupción en sus aplicaciones , debido al interface de
máquina abstracto.
El Porque los nombre del AS/400 son de longitud 10 caracteres
Una vez tomada la decisión sobre la máquina abstracta, se pudieron tomar las
decisiones de diseño menos críticas . Como esta era una nueva máquina, todos
los parámetros de diseño fueron cuestionados. Una de las decisiones que
tuvieron que tomarse fue la longitud de los nombre de objeto. Una propuesta era
un nombre de 8-caracteres que sería compatible con el S/34. Otros propusieron

Un vistazo atrás en la Historia,a los Orígenes del OS/400
 Wayne O.Evans , e-mail: [email protected]

Traducción autorizada al Español realizada por http://www.recursos-as400.com



Wayne O Evans Consulting, Inc.
AS/400 Security Consulting and Education

“nombres de documentación propios” de hasta 32 caracteres soportados por el
MI. La decisión se tomó cuando el equipo de diseño de la base de datos
determinó que necesitaban poder almacenar el fichero , la biblioteca y el nombre
del miembro en los 32 caracteres que permitía el MI. El nombre de 10-
caracteres se determinó al dividir la longitud de nombre máxima (32) por 3 así
que los nombres del S/38 (y los nombres AS/400 ) están limitados a 10
caracteres de longitud.

La Selección de la denominación