MONITOR PARA LA COMPUTADORA IBM 704 DE GENERAL MOTORS/NORTH AMERICAN AVIATION

Robert L. Patrick - Enero 1987

Traducido al castellano del original por Ramiro Encinas Alarza - 2026.

RESUMEN

La historia del software en Estados Unidos ha estado poco documentada. En un intento de capturar la esencia de sus primeros momentos antes de que se pierda, el Comité organizador de la Conferencia Nacional de Informática de 1987 (del 15 al 18 de junio en Chicago) ha designado el 17 de junio de 1987 como el Día de los Pioneros.

Robert L. Patrick, fue consultor durante 27 años en RAND y fue invitado a presentar este artículo sobre los sistemas operativos en los que trabajó a mediados de la década de 1950. Estos trabajos están relacionados con los sistemas operativos de las computadoras principales de IBM (SOS, IBSYS) junto con la sustitución de la cinta por el disco en el OS/360.

MONITOR DE LA COMPUTADORA IBM 704 DE GENERAL MOTORS/NORTH AMERICAN

Todo comenzó en 1954, en las compañías General Motors y North American Aviation. En ese momento estaba trabajando en el desarrollo de aviones en Ft. Worth, Texas. Eramos un montón de graduados de distintas carreras universitarias (aún no existía la carrera de Ciencias de Computación) intentando comprender las físicas del diseño de aviones y las fórmulas matemáticas de diseño para programar sus soluciones en un cerebro gigante. Solo se habían fabricado 19 computadoras IBM 701 y la que teníamos en Ft. Worth era la séptima de la serie. La número 17 se instaló en la General Motors en Detroit. La 701 solo ejecutaba unos 15 millones de instrucciones por segundo. Se alquiló por unos 23 $ al mes y ocupaba una sala de 40x40 pies.

La arquitectura de la máquina era secuencial, de forma que solo podía hacer una cosa a la vez (los canales de ciclo robado, que era una forma de compartir el tiempo de cómputo con operaciones de entrada/salida, aún no se habían inventado). Cuando una 701 utilizaba un dispositivo de entrada/salida (I/O), había que esperar a que terminara la transferencia hacia/desde ese dispositivo y mientras tanto no se podía hacer nada más. Era una máquina de proceso por lotes y la configuración típica consistía en un lector de 150 tarjetas por minuto, una perforadora de 100 tarjetas por minuto, una impresora de 150 líneas por minuto (48 caracteres por línea) y una memoria interna de dos mil palabras de 36-bit. También tenía 4 unidades de cinta magnética de 7500 caracteres por segundo y un tambor magnético para almacenar 2000 palabras. El tiempo medio de espera hasta ver un posible fallo, con suerte, era de 30 minutos.

Normalmente un programador utilizaba la consola de operaciones. Cuando un programador estaba listo para realizar un trabajo, firmaba en una lista de espera y cada dos por tres revisaba el progreso de la lista. Cuando veía que le quedaba poco tiempo para su turno cojía su mazo de tarjetas. Cuando el programador anterior terminaba o se quedaba sin tiempo o tenía alguna incidencia que le impedía terminar a tiempo, el siguiente programador tomaba rápidamente el control de las operaciones, comprobaba que en el lector de tarjetas y en la impresora estaban instalados los paneles de control adecuados para su ejecución (cada panel venía con una configuración para convertir y formatear los datos dependiendo del trabajo), comprobaba que la perforadora tenía instalado el panel de control adecuado, colocaba la cinta magnética (si iba a utilizar la cinta maestra), fichaba en el reloj, se desplazaba a la consola para pulsar algunos interruptores, cargaba su mazo de tarjetas perforadas en el lector de tarjetas, rezaba para que la primera tarjeta no se atascara y pulsaba el botón para iniciar la secuencia de arranque.

Si todo iba bien, transcurrían unos 5 minutos desde que entrabas en la sala hasta que cargabas un mazo típico de unas 300 tarjetas y empezaba su ejecución. Si este proceso lo hacía una persona, se pasaba los 5 minutos dando vueltas a la sala realizando estas operaciones.

No siempre la cosa iba bien y se producían incidencias, sobre todo si un programador no colocaba bien el mazo y las tarjetas se atascaban, las cintas magnéticas daban fallos de lectura debido a empalmes defectuosos, los paneles de control de las impresoras o los interruptores estaban mal configurados, etc. Si tenías una incidencia y te llevaba más de 10 minutos solucionarla, perdías tu turno y el siguiente programador tomaba la máquina. Normalmente la máquina pasaba más tiempo sin hacer nada que trabajando. Los programadores cobrábamos poco, y si bien la máquina era bastante cara, su capacidad era muy preciada pues solo había 17 en el mundo entero y una en todo el estado de Texas.

Nunca había oído hablar de Henry Laurence Gantt, el padre de la ingeniería industrial, pero si lo hubiera hecho, esta historia sería más corta. Ver el tiempo improductivo de un recurso tan valioso hizo que muchos de nosotros, en diferentes lugares del país, iniciáramos una campaña para mejorar la eficiencia que aún perdura. De manera informal, cada programador empezó a trabajar con un asistente para ayudarle con la preparación de la máquina e ir más rápido. Esa ayuda fue muy preciada, sobre todo por los programadores con dedos torpes. De forma gradual empezamos a estandarizar los paneles de control del lector de tarjetas, de la impresora y de la perforadora de tarjetas para reducir el número de estos paneles y tardar menos en encontrar el adecuado y conectarlo. Realizamos mantenimiento preventivo en los mazos de tarjetas para reducir los atascos e intentamos organizar mejor a los programadores-operadores para facilitar las operaciones en la consola (no siempre funcionó). Si bien todo esto redujo el tiempo entre ejecuciones del peor de los casos, la media del uso útil de la máquina seguía siendo bajo.

En ese momento era un jóven arrogante y odioso y encontré la manera de ejecutar mis programas entre los tiempos muertos de las ejecuciones de otros programadores. Ejecutaba mis programas solo con paneles de control estándar y así no perdía tiempo cambiándolos. En lugar de cargar mis programas desde tarjetas perforadas, lo hacía con una configuración de inicio guardada en una cinta magnética que no se utilizaba y esto redujo el tiempo de carga de mis programas de 3 minutos a 10 segundos. Cada registro de entrada se cargaba en una dirección única para que pudiera almacenar el programa en cinta y los cambios o parches los realizaba a través del lector de tarjetas. Podía conseguir una ejecución completa en 3 minutos o menos si la salida no superaba 150 líneas de impresión.

No era como en 1987, pero podía realizar una ejecución siempre que quisiera ajustándome al calendario programado. Conseguía cuatro y cinco ejecuciones en un día mientras que otros programadores con suerte conseguían dos. Además, mi tiempo total de cómputo era solo del 25 % de cualquier otro programador.

Programar a principios de la década de 1950 era un caos organizado. El programador solía utilizar lenguaje ensamblador, eligiendo de una librería sus rutinas preferidas de conversión de binario-decimal y averiguando cómo ensamblar y depurar sus programas lo mejor que podía con las primeras herramientas que se crearon para ello. Finalmente lograba un programa que tal vez fuera una obra de arte, pero a efectos del cliente siempre llegaba tarde.

Fui uno de los primeros usuarios en utilizar un paquete de programación interpretado desarrollado por John Backus y sus compañeros de IBM que se llamaba IBM 701 Speedcoding System. Era un conjunto integrado de programas que ofrecían entrada/salida empaquetada y un lenguaje de programación simplificado de tres direcciones con operaciones de punto flotante. Los más puristas vieron a Speedcoding con desdén, pero yo he conseguido realizar un montón de trabajo y he aprendido varias lecciones sobre la máquina en la sala de operaciones, concretamente:

1. Sacar al programador de la consola y de la sala de operaciones.

2. Estandarizar las configuraciones de la máquina para eliminar los pasos de configuración.

3. Evitar recargar todo el trabajo cada vez, mantener una copia en cinta magnética y actualizar el almacenamiento con un mazo de tarjetas perforadas de intercambio.

4. El uso de un paquete integrado de programas es mucho más rápido que con código personalizado y funcionó bien para todos los trabajos menos los que necesitaban la máxima capacidad de cómputo.

En 1954 me cansé de las aplicaciones en defensa y me fui al centro de investigación de General Motors Research en Detroit. Justo habían instalado la IBM 701 número 17 y allí me llevé el paquete Speedcoding y mi método de trabajo. Los resultados fueron muy similares a pesar de que mis aplicaciones de ingeniería entonces estaban relacionados con coches y turbinas de gas para automoción.

A mediados de 1955, General Motors había encargado una IBM 704 y George Ryckman fue asignado como líder del equipo de la planificación de su instalación y operaciones. Yo estuve en ese equipo con el rol, que hoy podría llamarse de arquitecto. En ese mismo momento se formó un grupo de usuarios de IBM denominado SHARE para compartir programas e ideas con el objeto de facilitar la instalación de estas máquinas en beneficio mútuo. La tercera reunión de SHARE se realizó en Boston el 10 y 11 de noviembre de 1955.

Antes de esa reunión, la General Motors publicó una descripción de un sistema operativo para la IBM 704. Por otro lado la North American Aviation publicó una propuesta en la misma línea y después de ser revisada por la General Motors, los representantes de la North American Aviation decidieron unirse a nosotros convenciéndonos para realizar algunas modificaciones, y como resultado, ambas compañías obtuvieron sus sistemas operativos por aproximadamente la mitad de precio, en tiempo record y con una calidad mucho mayor debido al talento combinado que había en los dos equipos.

El sistema operativo resultante se basó en mi experiencia con la IBM 701 y aprovechó al máximo el hardware de la IBM 704. El esfuerzo de General Motors y North American Aviation finalmente fue aprovechado en unas 20 instalaciones de máquinas IBM 704. Hubo participantes en el sistema como programadores, usuarios y optimizadores que participaron después en los sistemas operativos SOS (SHARE OPERATING SYSTEM) e IBSYS, cuyo trabajo conjunto sirvió para las máquinas 7094, OS/360, IMS/360 y JES.

Antes de continuar, divagaré un momento para describir la IBM 704, que era una versión madura de la 701. Era más rápida, no tenía la memoria principal compuesta de tubos Williams-Kilburn (CRT) de la 701, y en su lugar tenía memorias de núcleos magnéticos. Este cambio junto con la próxima generación de tecnología electrónica, aumentó el tiempo medio sin errores a unas ocho horas.

El conjunto de instrucciones de la 704 mejoró con algunas instrucciones lógicas y con un conjunto de instrucciones aritméticas binarias de punto flotante (no tenía capacidad decimal incorporada). Internamente la 704 doblaba en velocidad a la 701 o incluso más.

En febrero de 1957 la 704 instalada en General Motors en Detroit tenía 8 KiloWords de memoria principal, cuatro tambores de 2 KiloWords cada uno, 8 unidades de cinta magnética y los mismos dispositivos lentos que adornaban la 701: el lector y perforadora de tarjetas y la impresora. El coste mínimo era de 35,550 $ al mes. Como tenía más memoria, era más rápida, pero los dispositivos de entrada/salida eran los mismos. Además, la unidad central todavía era secuencial (los canales de ciclo robado no vendrían hasta la IBM 709), por tanto, las operaciones de entrada/salida ocupaban todo el tiempo de la CPU y el resto de operaciones tenían que esperar. En esta situación tuvimos que cambiar nuestro modo de operar para conseguir el máximo rendimiento de la 704 sobre la 701.

IBM se dió cuenta de que algunos de sus grandes clientes tendrían muchas tarjetas que leer y muchos cheques que imprimir. Por eso ofrecieron, como una opción extra y con coste aparte, tres dispositivos independientes: uno para leer la información de las tarjetas perforadas y guardarla en cinta magnética, otro para leer información de cintas magnéticas e imprimirla y otro para perforar esa información en tarjetas. De esta forma, como estos dispositivos eran autónomos, en cierta manera era mejor que los canales de ciclo robado pues no interferían en el tiempo de la CPU de la unidad central que estaba en la sala de al lado.

A continuación enumero las características más importantes del sistema operativo que desarrollamos. Esta información viene de la propuesta de SHARE de 1955 (antes mencionado) y de un manual de usuario del 31 de enero de 1957 que encontramos. Catorce meses después de la propuesta creamos un equipo, afinamos el diseño, implementamos el sistema y lo documentamos. La siguiente lista contiene las características más importantes del esfuerzo del trabajo conjunto entre General Motors y la North American Aviation:

1. Toda la entrada y salida de datos se procesa en el equipamiento independiente de la unidad central, leyendo tarjetas perforadas, guardando datos en cinta y viceversa. Estas cintas contienen ficheros y se conocen como SYSIN y SYSOUT. Con estas cintas se procede en el modo de operación cinta-a-cinta donde la información de las tarjetas perforadas que está guardada en una cinta se copia a otra cinta pero en un formato más depurado para procesarla después. De esta forma los dispositivos de perforación y de lectura de tarjetas que están conectados a la unidad central ya no se utilizan en producción y quedan como extensión de la consola de operaciones para tareas de mantenimiento.

2. Normalmente la cinta SYSIN contiene un lote de trabajos independientes separados e identificados por tarjetas o registros de control (JCL). Cada trabajo contiene la siguiente información en forma secuencial y que viene de las tarjetas perforadas leídas y copiadas a la cinta SYSIN: información de la cuenta (el cliente), el nombre del programador, una cabecera indicando el tipo de conversión decimal a binario y después el programa y los datos.

3. A pesar de que IBM proporcionaba paneles de control para configurar el formato de la información de cada lector y perforador de tarjetas e impresoras, configuramos un panel de control estándar y solo utilizábamos ese, como si estuviera soldado al dispositivo. Reorganizamos todos los datos mediante programación y no mediante cableado o paneles de control. Toda esta estandarización de la configuración redujo el tiempo no utilizado entre trabajos de minutos a milisegundos.

4. Echamos a los programadores de la sala de la máquina, contratamos operadores profesionales de computadoras y estandarizamos la comunicación entre el programador y el operador. Los programadores se adaptaron rápidamente al nuevo modo de funcionamiento, ya que indicábamos al operador que pasara al siguiente trabajo cuando había confusión o algo no funcionaba bien.

5. Ganamos eficiencia programando mediante el uso de rutinas de conversión estándar de decimal a binario y al revés, y también mediante herramientas de depuración integradas. Esto redujo el esfuerzo del programador pues ya no necesitaba entender las rutinas de conversión que estaban en las librerías. Simplemente tuvo que escribir algunas declaraciones de control de trabajo para poder utilizarlas y esto produjo otro beneficio para el programador. Las memorias de estas máquinas eran relativamente pequeñas, solo 8 KiloWords. Ahora el entorno de ejecución funcionaba con los datos de entrada, de cómputo y de salida en binario mediante la conversión de decimal a binario fuera del ámbito del programador. Esto ayudó mucho a los programadores menos experimentados proporcionando más espacio para ejecutar el programa en contraste con los programadores más experimentados que gestionaban su propia entrada-salida.

6. Ampliamos el hardware del IBM con un reloj binario diario para programar y guardar registros de actividad de los trabajos que se realizaban, de forma que se marcaba en ese reloj el momento de inicio de un nuevo trabajo y se guardaba esa información para después realizar seguimiento y mantenimiento de los registros de cada cliente. Este método de registrar esta actividad se conoce como SMF (System Management Facility). Incluso fuimos más allá e implementamos una nota para imprimir al final de cada trabajo con el coste de los recursos utilizados, de forma que los programadores se autodisciplinaron para evitar fallos que fueran más costosos que el salario de un día.

7. Así se empezó a trabajar con las primeras versiones de JCL (Job Control Language), un lenguaje de tipo script que servía para ejecutar un trabajo incluyendo todo lo que necesitaba: los dispositivos de entrada, los programas a ejecutar y los dispositivos de salida, además de información de identificación del trabajo y de cómo proceder en determinados estados o en caso de fallo. Todo ello de forma automática y en un solo paso. Estos scripts se guardaban en el fichero de cinta SYSIN. Esta "filosofía de cargar y listo" se hizo muy popular en la década de 1960.

8. Además, diseñamos el sistema para ampliar sus funcionalidades, como agregar otros lenguajes de conversión de código y datos al menú de rutinas de conversión de entrada. Después de dejar el proyecto, otros miembros del equipo de sistemas de General Motors agregaron el lenguaje de programación Fortran como conversor de entrada, de forma que fue posible compilar y ejecutar en una sola pasada rutinas de biblioteca predefinidas, código ensamblador y programas Fortran.

La implementación de este sistema estuvo condicionada en gran medida por la poca cantidad de memoria central disponible y la velocidad de los dispositivos de E/S. Como vimos antes, los dispositivos de lectura de tarjetas guardaban la información en cinta en formato BCD (Binary Coded Decimal) para facilitar otras operaciones. Además, la perforadora de tarjetas y la impresora utilizan el formato BCD y no realizaban conversiones a binario. La unidad central de la IBM 704 solo tenía 8 KiloWords de memoria principal. Debido a tan poca memoria y al gran tamaño de las rutinas de propósito general de conversión decimal-binario y viceversa, el sistema se concibió y se implementó en tres fases de proceso distintas.

En la primera fase, la información de las tarjetas en formato BCD se lee desde la cinta, los paneles de control realizan la conversión de BCD a binario y se crea el fichero en binario. Lógicamente, este fichero binario es el análogo directo de la cinta en BCD que se había creado desde el lector de tarjetas. Sin embargo, era más compacto y estaba escrito en el lenguaje nativo de la CPU, es decir, en binario. Hay que tener en cuenta que un programa que lee información binaria tiene solo 50 instrucciones, mientras que un programa que convierte decimal a binario tiene al menos 2000.

De forma similar, durante la ejecución de cada trabajo se generaba un archivo de salida binario. Las instrucciones de control, al igual que en JCL, estaban integradas en el flujo de salida. Estas instrucciones hacían que el conversor de salida formateara correctamente el flujo binario y, posteriormente, incluyera parámetros en el archivo de salida BCD para controlar el espaciado de la impresora, los saltos al inicio del formulario y la inserción de tarjetas separadoras entre los mazos de tarjetas perforadas. Para ahorrar memoria y aumentar la velocidad, se asignó todo el tiempo de cómputo de la máquina al traductor de salida y se optimizó la conversión.

El sistema operativo resultante tenía una fase que convertía los datos de entrada de decimal a binario, y también convertía programas desde el código fuente a lenguaje objeto (el lenguaje de ensamblador simbólico estaba disponible al principio y poco después agregamos el recién creado Fortran). Después tenía otra fase de ejecución que fundamentalmente estaba controlada directamente por el programador. Finalmente, una fase de conversión hacia la salida, que podía ser la impresora, perforadora de tarjetas (tanto en decimal como en binario) y registros de control SMF. En resumen, las ventajas de este diseño de tres fases eran:

1. Proporcionaba la máxima cantidad de memoria sin restricciones al programador para ejecutar su programa.

2. Resultaba eficiente, ya que las rutinas de conversión eran más grandes que los distintos ficheros que había dentro de cada trabajo. Los programas de conversión de gran tamaño se cargaban en la memoria solo una vez por lote, y procesaban todos los ficheros pequeños de datos. Esto consumía menos ciclos que recargar y ejecutar las rutinas de conversión al principio y al final de cada trabajo.

3. Al proporcionar a los conversores la capacidad total de cómputo, se pudo ampliar el tamaño de éstos mejorando la eficiencia y aumentando la rapidez de las conversiones.

Cuando se escribió el código del sistema operativo resultante, el 90 % del trabajo se dedicaba a los conversores de entrada y salida y solo un 10 % a dar soporte a los programadores durante la fase de ejecución.

Cuando North America Aviation y General Motors Research decidieron en el invierno de 1955 trabajar de forma conjunta en el desarrollo de este sistema, lo dividimos por la mitad. North American desarrolló los programas integrados que se utilizaron en la fase de la conversión de entrada, y General Motors desarrolló el conversor de salida. En la primavera de 1956, General Motors amplió el conversor de entrada de North American con el programa de ensamblador simbólico de Roy Nutt (SAP) como una subrutina de conversión de entrada integrada durante la fase 1.

Se produjo un desacuerdo intelectual en relación a los servicios que el sistema operativo tenía que proporcionar durante la fase 2 de ejecución. En ese punto, el software instalado en North American y en General Motors era distinto mientras que el software de las fases 1 y 3 (entrada y salida) era el mismo.

Cuando empezamos a planificar este sistema, nos preocupaba su protección. La IBM 704 no tenía restricciones de uso de sus registros ni forma de separar la memoria del sistema operativo de las aplicaciones de los programadores mediante particiones (estas protecciones empezaron a verse con IBM System/360). Además, sólo teníamos un conjunto de instrucciones y todos los programadores tenían acceso a ellas (el concepto de instrucciones privilegiadas vino en 1964 también con la IBM System/360). Al final no hubiera sido necesario preocuparse por este aspecto de la seguridad pues nuestros programadores de aplicaciones eran fieles a la organización y se portaban bien. La mayoría de ellos estaban encantados de preocuparse solo de la lógica de sus aplicaciones en lugar de las conversiones de datos y modos de operaciones. En raras ocasiones el sistema operativo era dañado debido a la reescritura de su memoria (low-core) por alguna aplicación descontrolada. No recuerdo ningún momento donde un programador hubiera manipulado con mala intención el sistema operativo.

También nos preocupaba que los programadores no aceptaran la estandarización que suponía el uso del sistema operativo. Durante los días de IBM 701 los programadores tuvieron acceso sin restricciones a todas las funciones del hardware. Algunos cuestionaron si los programadores aceptarían el sistema, ya que éste les negaba el acceso a ciertos servicios de la máquina como la cinta SYSRES (System Residence). El sistema operativo necesitaba esta cinta SYSRES para cargar las primeras 300 palabras en la memoria principal durante la fase de ejecución. Esta cinta SYSRES tenía los componentes del sistema operativo, como compiladores, ensambladores, conversores de E/S, utilidades, etc. Como instalábamos el sistema operativo al mismo tiempo que el hardware, nos olvidamos de los sistemas heredados. En Detroit no hubo intentos serios por parte de los programadores de utilizar la unidad de lectura de tarjetas perforadas integrada en la unidad central que permitía el acceso a toda la memoria, ni tampoco pidieron cintas para para su uso personal, y aceptaron la configuración estándar que establecimos. Esto pudo deberse en parte a nuestra disposición de ofrecer a los programadores todo el sistema sin restricciones, pero se les advirtió que, si hacían un mal uso, tendrían que quedarse de madrugada para ejecutar sus trabajos.

Hubo varias personas que contribuyeron directamente en este esfuerzo pionero. En los últimos 30 años muchos de ellos cambiaron de trabajo varias veces. Hace poco algunos de ellos se han retirado, mientras que otros siguen trabajando duro. Esta es la lista de los contribuyentes originales con su afiliación original:

COLABORADORES DEL MONITOR DE GMR/NAA ------------------------------------ Nombre Afiliación en 1955 ---------- ------------------ Penny Barbe NAA Robert Christiansen GMR Jim Fishman GMR Dale Hanks NAA Don Hart GMR Owen Mock NAA Bob Patrick GMR George Ryckman GMR Kei Shimizu NAA Frank Wagner NAA