EL DECSYSTEM-20 EN LA UNIVERSIDAD DE COLUMBIA (1977-1988)

Source: http://www.columbia.edu/cu/computinghistory/dec20.html

Frank da Cruz y Christine Gianone
The Kermit Project
Universidad de Columbia, Nueva York, 29 de diciembre de 1988; Copyright © 1988, 2021,
Frank da Cruz y Christine M. Gianone,
Todos los derechos reservados.

Vea un vídeo recientemente descubierto del desmantelamiento de uno de los DEC-20 de la Universidad de Columbia en 1986:

Galería de vídeos de capturas de pantalla

Una reminiscencia no técnica escrita en 1988 (con motivo de la desconexión del último DECSYSTEM-20 de la Universidad de Columbia) para un libro de Digital Press que iba a conmemorar las máquinas de 36 bits de DEC con una serie de artículos, pero que nunca se publicó. Se agregaron ediciones menores, notas, glosario, enlaces y formato HTML en enero de 2001 (más actualizaciones menores de vez en cuando). Para obtener más información sobre la historia de la informática en la Universidad de Columbia, HAGA CLIC AQUÍ .

NOTA: Este artículo fue " cortado con puntos" el 18 de enero de 2001 y fue leído por muchas personas sin tener idea de qué se trata. Tenga en cuenta que esto no pretende ser una introducción ni una explicación de las influyentes computadoras de 36 bits Digital Equipment Corporation (DEC) de 1964-1988; más bien, iba a ser un ensayo en un libro en el que otros ensayos explicarían la arquitectura y la historia de la tecnología. Puede encontrar algunos sitios web de actualidad en la sección ENLACES al final.

Para aquellos a quienes el concepto de computadora de 36 bits les parece extraño: la primera computadora comercial binaria (en lugar de decimal) fue la IBM 701 , que entró en línea por primera vez en 1952. Tenía una palabra de 36 bits. Le siguió el 704 (donde se desarrolló el primer lenguaje de alto nivel, Fortran, en 1953-57, y cuyo juego de caracteres BCD de 6 bits y palabra de 36 bits explica el límite de 6 caracteres en los nombres de variables de Fortran), el 709 , 7090 y 7094 , todos de 36 bits. Las máquinas IBM de 36 bits fueron el lugar de nacimiento de LISP (*) y ( posiblemente ) del tiempo compartido (el sistema de tiempo compartido compatible del MIT, CTSS, alrededor de 1962) y también fueron la inspiración paraEl PDP-6 de 36 bits de DEC (1964), que fue el precursor del PDP-10 y DECSYSTEM-20 , que duró hasta 1988, año en el que DEC dejó de fabricar máquinas de 36 bits. Así, las arquitecturas de 36 bits fueron características destacadas (y en muchos sentidos dominantes) del panorama informático entre 1952 y 1988: 36 años.

List Processing Language, John McCarthy, Universidad de Stanford, 1960, sigue siendo el lenguaje principal para la investigación de la inteligencia artificial. CAR y CDR de LISP son conceptos IBM 704: Contenido de la parte de Dirección del Registro y Contenido de la parte de Decremento del Registro, es decir, las mitades izquierda y derecha de la palabra de 36 bits. Las máquinas de 36 bits con sus medias palabras izquierda y derecha de 18 bits son máquinas LISP perfectas.

CONTENIDO

INTRODUCCIÓN

Hasta mediados de la década de 1970, la Universidad de Columbia estaba firmemente arraigada en la informática en modo por lotes OS/360 del mainframe IBM. El área " Autoservicio de entrada/salida " recibió su nombre con orgullo porque representaba un gran salto adelante con respecto a los días en que los estudiantes e investigadores presentaban dócilmente sus mazos de cartas a los operadores y regresaban al siguiente día hábil para obtener su salida, generalmente para encontrar que su SYSMSG estaba lleno de quejas incomprensibles, cuyo doloroso desciframiento generalmente llevaba al usuario frustrado a que faltaba una coma o un espacio extra en el lenguaje de control del trabajo. O si el JCL pasaba la inspección, entonces había un vertedero de núcleos de 3 pies de espesor para acurrucarse. El área SSIO era una sala llena de la cacofonía adormecedora de los golpes de teclas y los chirridos de las temibles impresoras 1403 de IBM., el aleteo entrecortado de lectores de tarjetas , clasificadores de tarjetas e intérpretes ; Multitudes ansiosas se reunieron alrededor de las imprentas, con los resultados desechados hasta la cintura...

El IBM 360 Modelo 91 de Columbia , con su interfaz 360/75, era uno de los ordenadores más grandes, más rápidos, más pesados y más ruidosos del mundo cuando se instaló a finales de los años 1960. Cubría acres de espacio y se podían observar los núcleos magnéticos a través de ventanas en las cajas de memoria de núcleos de 6 pies de altura , colocados en filas que desaparecían en el punto de fuga. La energía era suministrada por un ruidoso motor-generador de hierro fundido del tamaño de un camión pequeño, y la refrigeración se hacía con agua destilada fría (entregada desde Deer Park en grandes botellas de vidrio dentro de cajas de madera) bombeada a través de kilómetros de tuberías internas. El panel de control de la CPUTenía más luces que Times Square. Según la leyenda, entre los miles de palancas y botones había uno cuya misión letal era "Bulb Eject", una muerte segura para cualquiera que lo presionara. El panel de control ahora [1988] reposa en el Museo de la Computación de Boston, con sus hipnóticas bombillas atenuadas para siempre ( 1 ).

Este enorme Stonehenge gris y azul, con sus gruesos tentáculos llegando hasta el área de la SSIO, ejecutó pesados "códigos" de Fortran para nuestros ingenieros: puentes torcidos; bombardear sustancias desventuradas con neutrones; calcular Pi a millones de dígitos; transformando el campo magnético de la Tierra en música... Para nuestros científicos sociales, predijo el resultado de las elecciones presidenciales de 1956 con precisión mortal año tras año. Para los administradores, arrojaba cheques de pago, transcripciones y estados contables. Y, finalmente, se asignó un pequeño rincón a nuestros estudiantes de ingeniería, que aplicaron sus bucles DO y GOTO laboriosamente elaborados a las series de Taylor, la regla de Simpson, la cuadratura de Gauss y la transformada de Laplace. Estos estudiantes tenían una tarea relativamente simple: escribir el programa, colóquelo en un sándwich de tarjetas JCL mágicas, alimente el sándwich al lector de tarjetas y recopile el resultado resultante. Muchos profesores recordarían esos días sencillos con melancólico cariño, aunque los recuerdos de los estudiantes estaban más atormentados por imágenes de dedos resbaladizos recogiendo montones de tarjetas perforadas caídas.

Los terminales comenzaron a aparecer a principios de la década de 1970, al principio sólo unos pocos entre los oscuros programadores de sistemas de Olympus, que podían conversar en lenguajes arcanos con "monitores de terminales" que tenían nombres como Milten, Cleo, Orvyl y Wylbur, y finalmente APL. y TSO (el primero es el "Irtnog" de los lenguajes informáticos, el segundo es una forma de JCL escrito en la terminal). Interactuar con la computadora era atractivo y, sin embargo, insatisfactorio. Los comandos eran oscuros y el cálculo todavía estaba, aparte del APL, en el lote.

Ingresó, en 1975, nuestro primer verdadero sistema de tiempo compartido, un DEC PDP-11/50 que ejecutaba el sistema operativo RSTS/E. Éste iba a ser un experimento de bajo presupuesto en informática interactiva genuina. Construido en torno al lenguaje BASIC, RSTS permitió que hasta 32 usuarios simultáneos sentados en DECwriters programaran, depuraran, se comunicaran entre sí y, en general, se comportaran mal, todo en tiempo real. RSTS resultó enormemente popular y el PDP-11 pronto se vio abrumado por estudiantes entusiastas.

Se eligió DEC porque IBM realmente no ofrecía ningún tipo de tiempo compartido interactivo de propósito general en aquellos días. En comparación con los otros contendientes, la oferta de DEC estaba mejor desarrollada, era más madura y... más divertida. Y se eligió RSTS como sistema operativo, en lugar de, digamos, UNIX porque la versión 6 de UNIX era un sistema poderoso y confiable que permitía a cualquiera hacer cualquier cosa. Tuvimos el germen de la idea de que el sistema debería desempeñar algún papel en la protección de los usuarios entre sí y de ellos mismos. Mientras que UNIX ofrecía pocas o ninguna facilidad en esta área, RSTS no estaba exento de sus propias debilidades. Los usuarios pronto aprendieron que podían asignar todos los TTY para que nadie más pudiera usarlos. Mejor aún, habiendo asignado un TTY, podrían ejecutar un programa en él para hacerse pasar por el proceso de inicio de sesión.

BIENVENIDOT@\R\~~~~xxx [[[[[~~

Otros usuarios ingeniosos descubrieron que si abrían un archivo nuevo para acceder a registros, podían leer los registros antes de escribirlos, recogiendo datos antiguos de los archivos eliminados de otros usuarios o del archivo de contraseña del sistema.

Y en un momento, nuestro sistema fue infestado por una camarilla de adolescentes de una escuela preparatoria cercana, que habían irrumpido explotando un error en el proceso de inicio de sesión. Se salieron con la suya con el sistema durante varias semanas antes de ser detectados, y les llevó varios días de trabajo ininterrumpido erradicar las numerosas trampillas y bombas de tiempo que habían dejado atrás.

A pesar de sus problemas, RSTS resultó bastante popular y rápidamente se sobrecargó. El experimento fue declarado un éxito y comenzamos a buscar algo más grande y algo más sofisticado; BASIC no era exactamente el lenguaje elegido entre los informáticos. Esto fue cuando DEC anunció por primera vez el DECSYSTEM-20 (su logotipo, todo en mayúsculas, a diferencia del de su primo mayor, el DECsystem-10, se dijo que fue un desliz de la tecla Bloq Mayús en la solicitud de marca). Antes incluso de mirar el sistema, obligamos a la gente de marketing a buscar ayuda técnica y les preguntamos sin piedad si los usuarios podían asignar todos los dispositivos, llenar el disco, presionar C para salir del proceso de inicio de sesión y bombardearse unos a otros con mensajes estúpidos, incluso si un archivo fue "borrado" cuando se eliminó. Cuando todo pareció ser de nuestro agrado, echamos un vistazo al sistema.

Maravilla y asombro, ¡esta computadora sabe lo que vas a escribir y lo escribe por ti! Bueno, casi. Pero sus atractivos eran evidentes a primera vista. Si no sabe qué escribir, escriba un signo de interrogación y se enumerarán las posibilidades. De repente, "completar espacios en blanco" se convirtió más en una "opción múltiple". ¡Pues claro que te lo puede decir! Sabe cuáles son las opciones, entonces ¿por qué no debería decírtelo? Una pregunta que podría haberse formulado con ventaja diez o quince años antes (visiones de programadores de sistemas veteranos hojeando manual tras manual buscando qué escribir en el siguiente campo de algún comando oscuro... algo común en algunas máquinas incluso para este día). Y esto "?" no era una función muy privilegiada (como lo era la propiedad del conjunto de manuales); incluso los USUARIOS ORDINARIOS podían emplearla. Sorprendidos, descubrimos que los mensajes de error aparecían en texto claro y comprensible, en lugar de números hexadecimales de 17 dígitos, de modo que podían entenderse sin un libro de "mensajes y códigos".

Nos convencieron inmediatamente la amabilidad, la actitud informal y el humor. No supimos hasta más tarde que la COOKIE (que sobrevive hoy en UNIX como 'fortuna') no era una parte estándar del sistema, y luego estaba TECO ( 2 ):

@hacer el amor

¿no la guerra?

El DEC-20 era un sistema de tiempo compartido real y de uso general. No se construyó en torno a un lenguaje en particular, ya que RSTS se basaba en BASIC. Ofrecía una amplia gama de compiladores, intérpretes, editores de texto y utilidades, lo que refleja muchos años de desarrollo de software TOPS-10 y TENEX. Podría absorber no sólo a nuestros usuarios de RSTS, sino también a muchos de nuestros usuarios de mainframe IBM Fortran y APL, y su facilidad de uso también atraería a muchos usuarios nuevos.

Nuestro nuevo DEC-20 llegó el 29 de junio de 1977 con TOPS-20 versión 1B. La instalación finalizó el 26 de julio. Comparado con el IBM 360/91, e incluso con el DEC PDP-11, era decepcionantemente monótono: no había luces, ni interruptores para ingresar datos, ni diales, ni motores, ni bombas... Sin embargo, el DEC-20 era infinitamente más poderoso que el débil PDP-11. Estaba equipado con cuatro unidades de disco RP06 ( 3 ) de última generación que nunca se podían llenar, y una increíble memoria principal de 256 KB: ¡palabras, no bytes! Una máquina así cumpliría con nuestros requisitos informáticos educativos en los años venideros.

Cada vez que una instalación informática adquiere un nuevo tipo de computadora, los programadores se embarcan inmediatamente en una furiosa oleada de actividad para convertir el nuevo sistema en su amado sistema antiguo. Tal como se entregó, el único editor del DEC-20 (además de una copia no oficial de TECO) era el EDIT críptico, orientado a líneas, descendiente de TOPS-10 SOS. Nuestros usuarios estaban acostumbrados a Wylbur, el editor de líneas mucho menos críptico de nuestro IBM 360/91, por lo que inmediatamente nos embarcamos en escribir una versión de Wylbur para el DEC-20, para que nuestros usuarios de IBM se sintieran más como en casa.

Comenzamos a aprender el lenguaje ensamblador DEC-20 y a leer el Manual de referencia de llamadas de monitor. Pronto descubrimos que se trataba de una máquina realmente maravillosa. El conjunto de instrucciones y el repertorio de llamadas de monitor (JSYS) eran asombrosamente ricos. Entre las llamadas de monitor se incluía un conjunto especial, diferente a todo lo que habíamos visto jamás: integradas en el propio sistema operativo había funciones estándar para la conversión entre representaciones internas y externas de todos los diferentes tipos de datos significativos para el sistema: números en diferentes raíces, caracteres, cadenas, nombres de archivos, nombres de directorios, fechas y horas. Los programadores de una época anterior sabían que la parte más difícil y tediosa de escribir un programa interactivo era solicitar, aceptar y validar los datos ingresados por el usuario.

Lo mejor de todo es que estas funciones de conversión se reunieron en un único paquete llamado COMND JSYS, desarrollado por Dan Murphy , que permitió a los programadores hacer uso de la misma "interfaz de usuario" en sus programas que la del TOPS-20 Exec: completa indicaciones, edición, ayuda en todos los campos; abreviatura y reconocimiento de palabras clave y cambios; finalización de nombres de archivos; perdón cuando el usuario comete un error tipográfico, etc.

Los programas codificados con COMND JSYS tenían muchas virtudes. Fueron amables, serviciales y consistentes. Todos los programas escritos con COMND funcionaron de la misma manera: escriba "?" Para saber cuáles son los comandos u opciones, escriba ESC para completar el campo actual (si es posible) y recibir un mensaje para el siguiente campo. La gente podría usar el "?" y ESC ofrece funciones generosas para aprender a manejar un nuevo programa y, más tarde, podría escribir comandos concisos y abreviados para aumentar la velocidad. Este enfoque, llamado "menú a pedido", no favorece al novato sobre el experto (como lo hacen los sistemas orientados a menús), ni al experto sobre el novato (como lo hacen los crípticos y concisos conjuntos de comandos de APL o UNIX).

Nuestro nuevo editor tipo Wylbur, llamado "Otto", fue escrito para aprovechar al máximo COMND JSYS. A pesar de todas sus obstinadas limitaciones, Otto fue un éxito inmediato porque permitió a los usuarios de mainframes de IBM migrar sin problemas al nuevo entorno, al mismo tiempo que los adoctrinaba en las costumbres del DEC-20. Su propósito oculto era engancharlos y luego frustrarlos lo suficiente como para que se tomaran el tiempo de aprender a ser un editor "real".

[ Arriba ] [ Siguiente ]

LENGUAJES DE PROGRAMACIÓN

A medida que pasaban los meses, nos pusimos en contacto con otros sitios de 36 bits de DEC, muchos de ellos (Stanford, CMU, MIT, Rutgers, BBN, SRI) con muchos años de experiencia en TOPS-10, TENEX, WAITS o ITS, y Recibimos de ellos programas que nos ocuparían durante años. Algunos fueron comienzos en falso, pero otros prosperarán de alguna forma hasta bien entrado el próximo siglo, legado de los DEC-10 y DEC-20. De esta experiencia aprendimos los beneficios de compartir y supimos que si alguna vez producíamos algo de utilidad general, lo compartiríamos con otros con el mismo espíritu con el que estas instituciones compartieron su trabajo con nosotros.

Nuestro principal objetivo al explorar estos sitios era descubrir qué hacían con respecto a la programación. En su concepción, las interfaces de usuario y sistema del DEC-20 llegaron tan cerca de la perfección como cualquiera en ese momento (fuera de Xerox PARC) podría imaginar, pero en la práctica la concepción no se realizó completamente. La mayoría de los lenguajes de programación provienen directamente de TOPS-10 y no brindan acceso a las llamadas del monitor TOPS-20 ni a su sistema de archivos. Y, sin embargo, estábamos decididos a que, en esta era de programación estructurada, no escribiríamos código a nivel de sistemas en lenguaje ensamblador. Después de breves coqueteos con Bliss-10, BCPL, Simula e incluso uno de los primeros Portable C (que no se adaptaba bien a la arquitectura de 36 bits), nos decidimos por Sail de la Universidad de Stanford como nuestro "lenguaje oficial". Pero varios años de devoción a la vela acabaron en desilusión. Había demasiados errores, demasiada dependencia del sistema de ejecución y de saber dónde estaba, demasiada conversión necesaria en las nuevas versiones de Sail o TOPS-20, demasiadas soluciones grotescas para lograr lo que habría sido natural en ensamblador: la única lenguaje que realmente entendiera la máquina y el sistema operativo. Y a partir de ese día toda la programación de nuestros sistemas se realizó en ensamblador. Pero varios años de devoción a la vela acabaron en desilusión. Había demasiados errores, demasiada dependencia del sistema de ejecución y de saber dónde estaba, demasiada conversión necesaria en las nuevas versiones de Sail o TOPS-20, demasiadas soluciones grotescas para lograr lo que habría sido natural en ensamblador: la única lenguaje que realmente entendiera la máquina y el sistema operativo. Y a partir de ese día toda la programación de nuestros sistemas se realizó en ensamblador.

Como muchas cosas, la dependencia del ensamblador es buena y mala. Fue bueno porque tocó un nervio creativo: los programadores no tenían restricciones ni obstáculos por los requisitos burocráticos y las restricciones autoritarias de los lenguajes de alto nivel, y tenían acceso completo al conjunto de instrucciones de la máquina y al repertorio de llamadas de monitor, que, en el DEC- 20, fueron un placer para la vista. Programar en ensamblador era sencillamente divertido y nuestros programadores produjeron alegremente millones de líneas de código, pero con la persistente sensación de que había algo pecaminoso en ello. Esto se debió al lado malo: los programas en lenguaje ensamblador son específicos de la máquina y el sistema operativo subyacentes. ¿Qué pasa con estos programas cuando la máquina desaparece?

Sin embargo, MACRO era irresistible (MACRO se utiliza aquí como un término genérico, que abarca los MACRO-10 y -20 de DEC, así como el Midas del MIT y el FAIL de Ralph Gorin). A diferencia de FORTRAN o BASIC o cualquier otro lenguaje en el DEC-20 (excepto Sail, para el cual habíamos escrito un paquete de interfaz COMND JSYS), MACRO le permitía escribir programas DEC-20 reales: programas que eran útiles, amables y comprensivos con el usuario. Para los programadores en lenguaje ensamblador con experiencia en IBM 360, la arquitectura de la máquina y el conjunto de instrucciones fueron encantadores. Un espacio de direcciones lineales de 256K palabras (¡no más BALR y USING!), cientos de instrucciones exóticas... Y el propio ensamblador permitía programas relativamente limpios, incluso "estructurados". Por ejemplo, los literales en línea de MACRO son casi equivalentes a los bloques "comienzo...fin" de Algol o Pascal, obviando la horrenda lógica de espagueti que afecta a la mayoría de los programas en lenguaje ensamblador. Por ejemplo, aquí hay una construcción IF-THEN-ELSE con múltiples declaraciones en cada parte y sin GOTO ni etiquetas (disculpe los errores, esto es de memoria):

CAIL B, FOO ; SI (b >= foo) ENTONCES

PUSHJ P, [ ; COMENZAR

HRROI A, [ASCIZ/.LT./] ; mensaje = ".LT.";

SETOM MENOS ; menos = -1;

AOS (P); FIN (salte la otra parte)

POPJ P, ] ; DEMÁS

PUSHJ P, [ ; COMENZAR

HRROI A, [ASCIZ/.GE./] ; mensaje = ".GE.";

AJUSTAR MENOS ; menos = 0;

POPJ P, ] ; FIN;

SALIDA ; IMPRIMIR mensaje;

Todo lo que esté entre corchetes es literal; el ensamblador encuentra un lugar para colocarlo y reemplaza el literal con la dirección de ese lugar. Por lo tanto, (casi) cualquier cantidad de datos o código se puede colocar "en línea", en lugar de en un área de datos separada. Y como puedes ver en el ejemplo, los literales se pueden anidar. También se pueden simular otras estructuras de control comunes utilizando literales, como la declaración CASE:

MOVEM B, @[EXP FOO, BAR, BAZ](A)

Este ejemplo almacena B en FOO, BAR o BAZ, según el valor de A. Una operación de este tipo requeriría muchas líneas de código en la mayoría de los demás lenguajes ensambladores y en la mayoría de los lenguajes de alto nivel.

Para colmo, los programas en lenguaje ensamblador se podrían depurar interactivamente a nivel simbólico utilizando "DDT", no dicloro-difenil-tricloroetano, sino una "herramienta de depuración dinámica" diseñada para eliminar los errores con la misma eficacia que la versión real, con menos efectos secundarios indeseables (otras ayudas de depuración llevaban nombres insecticidas similares, como RAID). Con DDT ( 4) ya no es necesario examinar detenidamente gruesas impresiones de volcados hexadecimales, ni insertar declaraciones impresas ni volver a ensamblarlas, etc., etc. Su sintaxis de comando es un poco abstrusa y consiste principalmente en letras individuales crípticas, signos de puntuación, tabulaciones y un uso liberal del ESC. Carácter ("Altmode"), a menudo duplicado. Pero el DDT puede hacer cualquier cosa. De hecho, dado que puede ejecutar todas las instrucciones de la computadora y los servicios del sistema, los creadores del "Sistema de tiempo compartido incompatible" (ITS) del MIT para el PDP-10 lo utilizaron como su intérprete de comandos de nivel superior. Hablando de facilidad de uso...

El conjunto de instrucciones DEC-10/20, las llamadas de monitor, el ensamblador y el depurador atrajeron a muchos programadores sensatos a sesiones de codificación prolongadas o "ataques de piratería". Surgió una subcultura de programadores DEC-10/20 que hablaban palabras y frases extrañas cuyas etimologías se remontaban principalmente al Manual de referencia de hardware del PDP-10. El ingrediente añadido por los hackers (en aquella época no era un término peyorativo) fue la pronunciación de mnemónicos que nunca estaban destinados a los órganos del habla humana (AOS, BLT, JRST, ILDB, HRROI) y la extensión de sus significados a otras áreas de la vida ( principalmente comiendo). Finalmente, este léxico fue recopilado y codificado por Guy Steele de CMU y otros como "Hacker's Jargon", publicado originalmente como un archivo, que luego se expandió a un libro (ver bibliografía).

DIC-10/20 Los piratas informáticos eran un grupo pequeño al principio, debido principalmente a la escasez de documentación utilizable. Para escribir un programa que funcione, se puede consultar el Manual de referencia de hardware, el Manual de referencia de llamadas de monitor y el Manual de referencia del ensamblador MACRO. Pero estos manuales eran sólo listas de instrucciones, llamadas de monitores y pseudooperaciones, y no impartían la más mínima noción de cómo montar un programa. En 1981, la situación cambió dramáticamente con la publicación del libro de programación en lenguaje ensamblador DEC-20 de Ralph Gorin, y el mundo pronto estuvo superpoblado de programadores universitarios DEC-20.

Chris Ryland y Frank habían estado trabajando en una guía de programación en lenguaje ensamblador DEC-20 en 1979-80, que podría haberse convertido en un libro si Ralph no nos hubiera adelantado :-) HAGA CLIC AQUÍ para ver una versión en texto plano. recientemente desenterrado (septiembre de 2002), alrededor de 220 páginas.

Sin embargo, la falta de un conjunto coherente de lenguajes de programación de alto nivel, totalmente integrados con el sistema operativo y el sistema de archivos, fue uno de los defectos fatales del DEC-20. Esta debilidad fue remediada por DEC en VAX/VMS, donde los programas escritos en una variedad de lenguajes pueden requerir soporte de tiempo de ejecución común o compatible, y los programas de sistemas pueden escribirse en prácticamente cualquier lenguaje, incluso BASIC o FORTRAN.

Muchos restos de TOPS-10 se ejecutaron, y seguirán funcionando hasta el último suspiro del último DIC-20, en "modo de compatibilidad". Esto significaba que los programas escritos en estos lenguajes sólo podían acceder a archivos de acuerdo con las reglas TOPS-10: sin nombres de archivos largos, sin caracteres divertidos en los nombres de archivos, sin referencias explícitas a directorios o números de generación. En particular, los programas fuente para la mayoría de los lenguajes de programación tenían esta restricción: la mayoría de los compiladores no habían sido TOPS-20, e incluso si lo hubieran sido, LINK no lo había sido. En última instancia, esto significaba que el usuario tenía que conocer TOPS-10 para poder utilizar TOPS-20, y que a los programadores de lenguajes de alto nivel se les negaba el acceso a muchas de las funciones de TOPS-20.

Herramientas de desarrollo

(Esta sección se agregó en enero de 2019.) Décadas después, los DECSYSTEM-20 reales son difíciles de encontrar, pero existen emuladores; busca en Google para encontrarlos. Usar un emulador de DEC-20 es como usar un DEC-20 real. Por ejemplo, puede escribir y ejecutar programas en lenguaje ensamblador. Para ello necesitarás los manuales. Aquí hay algunas copias archivadas localmente:

Título	Sujeto	Fecha	Formato	Tamaño
DECsystem-10 DECSYSTEM-20 Manual de referencia del procesador	Arquitectura y conjunto de instrucciones.	junio de 1982	PDF	29MB
Manual de referencia del macroensamblador DECSYSTEM-20	manual de lenguaje ensamblador	abril de 1978	PDF	5MB
Manual de referencia de llamadas de monitor TOPS-20	también conocido como manual JSYS (servicios del sistema)	diciembre de 1982	PDF	26MB
TOPS-20 Manual de DDT	Herramienta de depuración dinámica	mayo de 1985	PDF	5MB
NAVEGAR	Lenguaje de inteligencia artificial de Stanford	agosto de 1976	PDF	5MB

Vea el programa Kermit DEC-20 como ejemplo de codificación en lenguaje ensamblador.

SAIL (un lenguaje de programación de alto nivel de Stanford) normalmente no viene instalado en los DEC-20, por lo que si el manual le intriga, tendrá que buscar una descarga.

[ Arriba ] [ Siguiente ] [ Anterior ]

ENFRENTAR EL CRECIMIENTO

Al cabo de un año, nuestro DEC-20 estaba irremediablemente sobrecargado, con promedios de carga por las nubes y los discos llenándose regularmente. Permaneció en estas condiciones un año más hasta que encontramos la manera de comprar una segunda máquina. Pronto también estuvo lleno, y en los años siguientes llegaron un tercero y un cuarto, además de un DEC-20 en el departamento de Ciencias de la Computación de Columbia y otro en el Columbia Teachers College. Los sistemas del Centro de Computación se actualizaron agregando memoria y discos y, finalmente, interconectándolos todos con CFS e instalando unidades de disco RA-81 y un HSC-50. Finalmente, todas las CPU se actualizaron a 2065 con memoria máxima y no pudimos hacer nada más para sacarles más rendimiento. Al igual que otros leales al DEC-20, habíamos llenado nuestra sala de máquinas al máximo con DEC-20 y no teníamos espacio para más. Nuestra única opción de expansión sería un nuevo modelo, con más potencia en menos espacio. Durante varios años, hicimos viajes periódicos a Marlboro para hablar sobre una próxima máquina. En realidad hubo 2 proyectos.

DOLPHIN comenzó como un sistema de alta gama que ofrecería una arquitectura de 36 bits verdaderamente distribuida. Los DELFINES grandes se ubicarían entre pequeños MINNOWS de un solo usuario en una red de gran ancho de banda. Tanto DOLPHIN como MINNOW sucumbieron a problemas con la tecnología. DOLPHIN utilizó chips Motorola diseñados a medida que tenían problemas de confiabilidad. El denso embalaje de MINNOW, diseñado para caber en una caja de terminal VT52 , junto con la necesidad de una unidad de disco RP06 conectada localmente (!), fueron su perdición. Aún faltaban años para que Ethernet se utilizara comercialmente y el problema de la red también persistía. [2]

El proyecto JUPITER surgió varios meses después de la cancelación de DOLPHIN. Su diseño no incorporaba MINNOW distribuidos, pero sí respaldaba la exigencia de un procesador centralizado rápido. Sería más de 10 MIPS y barato. Un largo y difícil proceso de diseño no permitió que se cumpliera ninguno de estos objetivos y en 1983 el proyecto fue cancelado, aunque finalmente algunas partes llegaron al mercado: el CI, el HSC-50, etc. [2]

La gerencia y los ingenieros de LCG siempre nos aseguraron en cada visita a Marlboro (MA) (que a veces incluían paseos en helicóptero y limusina, además de alojamiento en hoteles "temáticos") que el nuevo sistema estaba a sólo "18 meses" de su anuncio, independientemente de su nombre en clave. . El costo de propiedad de cualquiera de los sistemas habría sido significativamente menor que el número equivalente de KL.

Mientras esperábamos que apareciera Júpiter, todavía necesitábamos formas de distribuir nuestros recursos DEC-20 existentes entre los usuarios de la manera más justa. Esto había sido una preocupación desde el principio. El DEC-20, tal como se entregó originalmente, permitía a los usuarios comunes controlar la máquina de varias maneras, haciéndola inutilizable para todos los demás. Los usuarios escribieron programas para crear infinitamente bifurcaciones autorreplicantes, asignaron todos los PTY y los usaron para escribir ladrones de contraseñas, ejecutaron programas en bucles infinitos que consumieron todos los ciclos de CPU disponibles, monopolizaron las escasas líneas de terminales durante largas horas, llenaron el colas por lotes, bombardearon a los operadores con miles de solicitudes falsas de montaje en cinta, imprimieron millones de páginas sin sentido, etc, etc.

Como sitio fuente de monitor y ejecutivo, Columbia pudo realizar modificaciones para restringir el acceso a ciertos recursos por parte de ciertas clases de usuarios, según la identificación del usuario o la cadena de cuenta, o asumiendo bits "no utilizados" en la palabra de capacidad. Pero en nuestros días de OS/360, aprendimos la dolorosa lección de que las modificaciones locales de los sistemas operativos vuelven para atormentarnos cuando aparecen nuevas versiones: tomó años actualizar nuestro IBM OS/360 21.0 21.0, muy modificado, a 21.8. Por lo tanto, nos sentimos obligados a convencer a DEC de que nuestros requisitos se aplicaban universalmente. Para hacer esto, recorrimos varios canales: primero presentamos formularios de Informe de rendimiento del software, luego escribimos cartas y finalmente tuvimos una serie de reuniones con el grupo de monitores en Marlboro.

Un producto de estas reuniones fue el Trabajo de Control de Acceso. Esta era una tarea proporcionada por el cliente que el monitor consultaba cada vez que los usuarios solicitaban acceso a ciertos recursos. El ACJ podría decidir si concede o deniega el acceso basándose en los propios criterios del sitio del cliente. Algunos de estos recursos incluían inicio de sesión, habilitación de capacidades, creación de trabajos, creación de bifurcaciones, asignación de dispositivos, envío de trabajos por lotes, montajes de cintas, montajes de estructuras, creación de directorios, cambios de clases de programador, acceso y conexión, etc. Esto fue una gran ayuda para la seguridad. y gestión de recursos.

Pero la ACJ no nos permitió regular el consumo continuo de recursos. Para ello, necesitábamos producir un programa de monitoreo para recopilar estadísticas por usuario sobre la CPU y el tiempo de conexión. A los estudiantes se les otorgó un presupuesto semanal de tiempo de conexión y CPU, y recibieron advertencias periódicas a medida que se acercaban al límite. Incluso después del corte, se les permitió regresar durante las horas de menor actividad para completar su trabajo. El ACJ y Omega permitieron que nuestros DEC-20 acomodaran a una población de más de 6000 estudiantes activos en cuatro máquinas en el apogeo de la era DEC-20.

Un área fue de particular interés para nosotros. Los terminales no se conectaron directamente a nuestros DEC-20, sino que se conmutaron a través de una PBX de datos. Por lo tanto, el DEC-20 no sabía que TTY37 (por ejemplo) era la terminal número X en la habitación Y del edificio Z. Por razones tanto de seguridad como de conveniencia, era necesario tener este conocimiento. Si se sospechaba que un usuario se comportaba mal, el personal tenía que conocer su ubicación física. Y tras la creación del empleo, el ejecutivo necesitaba conocer el tipo y la velocidad del terminal, para que el usuario no se confundiera con pantallas rotas y desordenadas. Afortunadamente, la centralita de datos contaba con un terminal consola que mantenía un registro de las conexiones. Esto se conectó, a través de un cable Octopus RS-232, a los puertos de cada uno de los DEC-20, que mantenían una base de datos de puertos, ubicaciones, tipos de terminales y velocidades de PBX.

Los registros mantenidos por la ACJ y Omega incluían la ubicación física del trabajo. Estos registros nos permitieron rastrear a más de unos pocos infractores potenciales y reales de la seguridad del sistema y de la privacidad de otros usuarios.

[ Arriba ] [ Siguiente ] [ Anterior ]

REDES

Nuestro primer DEC-20 se conectó al IBM 360/91 utilizando el producto HASP/RJE de DEC, que requería su propia interfaz DN20 dedicada. Este método de comunicación era bastante doloroso y requería que el DEC-20 se hiciera pasar por un lector de tarjetas e impresora de líneas para el sistema IBM. Escribimos una serie de programas Sail que construirían el "sándwich JCL mágico" para nuestros usuarios que querían enviar archivos o trabajos al sistema IBM.

Tan pronto como obtuvimos nuestro segundo DEC-20, lo conectamos al primero con DECnet [1980] y luego conectamos esta pequeña red con otros sistemas DEC en el campus. DECnet también se utilizaba en las máquinas del centro de computación de la Universidad Carnegie-Mellon, por lo que fusionamos nuestros dos DECnet en uno con una línea telefónica alquilada entre Nueva York y Pittsburgh, llamando a la red ampliada CCnet [1982] (CC significa Centro de Computación, o tal vez Carnegie-Columbia). Al poco tiempo, otras instituciones se unieron a la red: el Instituto de Tecnología Stevens, la Universidad Case Western Reserve, la Universidad de Nueva York, la Universidad de Toledo y otras. El principal beneficio fue compartir el trabajo de software y programación por parte del personal de administración de computadoras en estos sitios, que incluían DEC-20, DEC-10, VAX, PDP-11 y otros sistemas DEC. Durante muchos años, Columbia y CMU ejecutaron un sistema DEC-20 Galaxy común, desarrollado conjuntamente, que permitía la impresión transparente a través de DECnet y cintas de impresión en cola para la impresora Xerox 9700. Uno de los DEC-20 de Columbia sirvió como puerta de enlace de correo entre CCnet y BITNET, una gran red académica basada en protocolos RSCS de mainframe IBM.

La contribución más importante del DEC-20 al networking fue su soporte a los protocolos ARPANET, primero NCP y posteriormente TCP/IP. Durante muchos años, DEC fue el único proveedor importante de computadoras que admitía estos protocolos, que se desarrollaron principalmente en máquinas DEC de 36 bits bajo TENEX, TOPS-10 y TOPS-20 (y más tarde en VAX para Berkeley UNIX). A finales de los 70 y principios de los 80, los días en que ARPAnet creció y prosperó más allá de su pequeño mandato de investigación original, estaba dominada por máquinas DEC de 36 bits, y muchos de los protocolos y procedimientos básicos de Internet se desarrollaron en ese marco. El propio DEC tenía un DEC-20 en ARPANET, que permitía a los principales sitios académicos y de investigación del DEC-20 comunicarse directamente con los ingenieros de TOPS-20, enviar informes de errores o correcciones por correo electrónico, transferir archivos, etc. Mark Crispin en Stanford creó una lista de correo ARPANET de gerentes TOPS-20. La lista de correo incluía desarrolladores TOPS-20 en DEC, y hubo muchos toma y daca útiles que evitaron el engorroso procedimiento SPR.

Localmente, nuestros propios DEC-20 recibieron interfaces Ethernet NIA20 para reemplazar los incómodos y de gran tamaño frontales DN20. Ethernet nos permitió ejecutar TCP/IP junto con DECnet, y en poco tiempo [alrededor de 1982] hubo una gran Ethernet en todo el campus que conectaba el centro de computación DEC-20 con los sistemas departamentales en todo el campus y más allá, gracias a Internet del departamento de Ciencias de la Computación. membresía [1982?], y más tarde [1984?], nuestra propia membresía en otras redes basadas en TCP/IP de área amplia como NYSERNET y JVNCNET. Ethernet y TCP/IP incluso nos permitieron descartar nuestro enlace HASP RJE a los mainframes de IBM, que ahora estaban en Ethernet, ejecutando código TCP/IP de la Universidad de Wisconsin (posteriormente incorporado por IBM a su propia línea de productos).

[ Arriba ] [ Siguiente ] [ Anterior ]

KERMIT

En el apogeo de la popularidad del DEC-20, la demanda entre estudiantes y profesores de identificaciones de usuario era tan grande que ya no podíamos darnos el lujo de entregar identificaciones perpetuas. En cambio, las identificaciones de instrucción se asignaron por curso y luego se eliminaron al final de cada semestre. Aunque los archivos estaban escrupulosamente respaldados en cinta, a los estudiantes no se les permitía solicitar la restauración de los archivos de un período anterior debido a la capacidad limitada de la unidad de cinta y la cobertura del operador. E incluso durante el semestre, la cuota de disco de un estudiante (35K - K, ¡no M o G!) a menudo no era suficiente para mantener todos sus archivos en línea al mismo tiempo.

Si los usuarios de DEC-20 tuvieran algún tipo de medio extraíble, podrían asumir la responsabilidad de administrar y archivar sus propios archivos. Nuestro primer esfuerzo en esta área involucró un producto poco conocido llamado DN200, una estación DECnet remota que fue diseñada originalmente para conectar 32 terminales y una impresora de línea al DEC-20 (este producto nunca maduró del todo). El DN200 era un PDP-11/34 que ejecutaba algún derivado de RSX. El nuestro, único en su tipo, incluía una unidad de disquete de 8 pulgadas. Nuestro plan era escribir software DN200 para copiar archivos entre los disquetes y el sistema de archivos DEC-20. Los usuarios simplemente insertarían sus propios disquetes y emitirían comandos COPIAR para guardar o restaurar sus archivos. Afortunadamente, este proyecto nunca despegó.

Pero la idea de los medios extraíbles parecía correcta. Los usuarios de computadoras lo habían tenido durante años en forma de tarjetas, cintas de papel o incluso las irresistibles y pequeñas DECtapes de DEC que giraban hacia adelante y hacia atrás, como las que se encuentran en los PDP-8, -9, -10, -11, - 12, etc, y muy desaparecido del -20. Se consideraron y rechazaron una serie de planes descabellados: permitir a los usuarios enviar archivos a la perforadora de tarjetas de la computadora central IBM, colocar una unidad de cinta de "autoservicio" de 9 pistas en un área pública, escribir un programa que convertiría los datos del usuario en códigos de barras para imprimiendo en nuestras impresoras Printronix...

Justo por esta época (1980), aparecían en escena los microordenadores CP/M de 8 bits. Incluso si no sirvieran para mucho más, podían comunicarse y podían leer y escribir disquetes. Coloque algunos de estos en áreas públicas, conéctelos a los DEC-20 y los estudiantes tendrán sus medios extraíbles: pequeños discos que podrían llevarse, almacenar y reutilizar sin depender del personal del centro de computación. La gran pregunta era cómo mover un archivo desde una gran computadora de tiempo compartido a una pequeña computadora personal.

Miramos el mercado y vimos que había algunos paquetes comerciales de comunicación RS-232 para micros, pero ninguno para el DEC-20. Y no sólo teníamos que preocuparnos de los DEC-20 y los micros, sino también de nuestros mainframes IBM. Si compramos un software para transferir archivos entre el DEC-20 y el Intertec Superbrain(Este fue el micro que seleccionamos, principalmente por su construcción a prueba de usuario similar a un tanque, y a pesar de su nombre tonto), suponiendo que estuviera disponible, tendríamos que comprar otro paquete de software para que nuestros usuarios de mainframe IBM hicieran lo mismo. También tuvimos que considerar que el Superbrain podría no ser el micro preferido de todos. Columbia, al ser una organización altamente descentralizada y diversa, probablemente tendría tantos tipos diferentes de computadoras como lugares para ubicarlas. Si se requiriera un paquete de software separado para conectar cada par único de sistemas, entonces necesitaríamos paquetes distintos de casi n cuadrados, donde n es el número de diferentes tipos de sistemas informáticos, con copias suficientes para cubrir cada instancia de cada uno. sistema.

Es mucho mejor tener un paquete de software en cada computadora, un paquete que sea capaz de intercambiar datos con todas las demás computadoras. Esto reduce el número de programas necesarios a n , lo que a su vez alivia la carga del presupuesto y hace la vida del usuario un poco más fácil.

Todas estas preguntas resultaron en la decisión de invertir en nuestros propios programadores en lugar de en las empresas de software. De esta forma podríamos tener un software diseñado específicamente para nuestras propias necesidades. El resultado final fue el protocolo de transferencia de archivos Kermit. Nuestros primeros programas Kermit fueron escritos para DEC-20 y Superbrain. Se colocaron supercerebros en áreas públicas para permitir a los estudiantes copiar sus propios archivos en disquetes y restaurarlos en el DEC-20 más tarde.

El protocolo Kermit estuvo influenciado en gran medida por las limitaciones del DEC-20. El DEC-20, con su interfaz PDP-11/40, fue diseñado bajo el supuesto de que la entrada del terminal proviene directamente de personas sentadas frente a teclados que escriben con los dedos a una velocidad relativamente lenta (tal vez 10 caracteres por segundo como máximo), mientras que los grandes Se pueden enviar cantidades de producción sostenida desde la computadora a la pantalla. Por lo tanto, RSX20F, el sistema operativo del front-end, asigna pequeños buffers para la entrada y grandes para la salida. Esto lo aprendimos por las malas, cuando compramos nuestros primeros terminales que incluían función de "transmitir pantalla" (HDS Concept-100s). Tan pronto como alguien lo intentó, la parte delantera se estrelló. Se observaron fenómenos similares con las teclas de repetición automática (como cuando uno de nuestros programadores se quedó dormido sobre el teclado)( 5), y nuevamente cuando DEC lanzó por primera vez su terminal VT100 : al realizar un desplazamiento suave a 9600 bps, el terminal abrumó la pobre interfaz con XOFF y XON. Las versiones posteriores de RSX20F abordaron estos problemas de manera draconiana: si los buffers de entrada no se podían asignar lo suficientemente rápido, la interfaz establecería la velocidad de la línea en cero durante uno o dos segundos. ¿La leccion? No envíe ráfagas sostenidas de datos terminales al DEC-20: es como intentar hacer que un gorrión se coma a un héroe albóndiga. Los paquetes normales de Kermit son, por tanto, bastante cortos, de 96 caracteres como máximo: semillas, insectos y gusanos que un gorrión puede digerir.

Otra peculiaridad del DEC-20 es su sensibilidad para controlar personajes. Durante el diálogo normal del terminal, 17 de los 33 caracteres de control ASCII se utilizan para propósitos especiales (edición, interrupción de programas, control de flujo, informes de estado, señalización de fin de archivo, etc.) en lugar de ser aceptados como datos. Aunque un programa DEC-20 puede abrir el terminal en "modo binario" para evitar el procesamiento especial de estos caracteres, no es necesariamente deseable hacerlo, porque algunas de estas funciones podrían ser útiles durante la transferencia de datos. La lección aquí es no enviar caracteres de control "desnudos" al transferir datos. De hecho, el protocolo Kermit (en su configuración más básica) envía paquetes que son líneas de texto estrictamente cortas.

El mainframe IBM (en ese momento, el 360/91 había sido reemplazado por un 4341 que ejecutaba el sistema operativo VM/CMS) tenía su propio conjunto de peculiaridades. A diferencia del DEC-20, utilizaba comunicación semidúplex y utilizaba 7 bits de datos con paridad cuando se comunicaba con el mundo ASCII exterior. Esto significaba que nuestro protocolo de transferencia de archivos también tendría que ser semidúplex y requeriría un mecanismo especial para transmitir datos binarios de 8 bits a través de un enlace de comunicación de 7 bits. Además, como toda la comunicación se realizaba a través de un front-end 3705 (modo de línea) o un convertidor de protocolo 3270 IBM Serie/1 (o equivalente, por ejemplo, 7171 o 4994), los cuales trataban muchos de los caracteres de control como comandos que debían ejecutarse inmediatamente, Se reforzó la prohibición de caracteres de control desnudos en los datos. Reducir el protocolo al mínimo común denominador hizo que funcionara en todos los casos, pero a costa de la eficiencia y la elegancia. Algunas de las deficiencias resultantes se solucionaron en años posteriores mediante la adición de paquetes largos y transporte de paquetes de ventana deslizante full-duplex al protocolo, así como una opción de "sin prefijo" de caracteres de control.

Por feliz coincidencia, las peculiaridades combinadas del DEC-20, la computadora central IBM y la microcomputadora CP/M dieron como resultado un diseño que resultaría adaptable a prácticamente cualquier computadora capaz de comunicación asincrónica. Un archivo fue transferido por primera vez con el protocolo Kermit el 29 de abril de 1981, mediante dos instancias de Kermit-20 ejecutándose en un solo DEC-20, utilizando dos puertos serie interconectados por un cable de módem nulo.

La idea de compartir nuestros programas Kermit y regalar el código fuente fue una consecuencia natural de nuestras experiencias con la comunidad de sitios DIC-10/20. Recibimos tanto software propio de otros sitios que fue justo. Incluimos a Kermit en nuestras cintas de exportación y las enviamos a DECUS. DEC fue la primera empresa en reconocer a Kermit como una herramienta de gran valor y lo publicitó en sus folletos y boletines de sistemas grandes (por ejemplo, Copy-N-Mail , Large Systems News y EDU) .). Y DEC fue la primera organización en trasladar a Kermit a una nueva plataforma: su micro VT-180 CP/M. Como queríamos que el software Kermit se compartiera abiertamente, no colocamos nuestros programas Kermit en el dominio público. Si bien esto puede parecer contradictorio, pensamos que al proteger los programas con derechos de autor, podríamos evitar que fueran tomados por empresarios y vendidos como productos comerciales, lo cual parecía necesario ya que habíamos escuchado historias de otras universidades a las que se les había prohibido usar programas que ellos mismos Lo habían escrito empresas que habían tomado su trabajo de dominio público y lo habían protegido con derechos de autor.

Debido a la amplia distribución de los primeros programas de Kermit, junto con el código fuente y la especificación del protocolo, los sitios con otros tipos de computadoras comenzaron a escribir sus propios programas de Kermit y a enviárnoslos. Algunas de las primeras contribuciones en este sentido fueron los programas DECsystem-10 y VAX/VMS Kermit del Stevens Institute of Technology (escritos en Common Bliss para que el código pudiera compartirse entre TOPS-10, VMS y P/OS), PDP-11 Kermit de la Universidad de Toledo , y el primer Kermit UNIX básico en C de nuestro propio departamento de Informática. El proceso continuó durante muchos años, dando como resultado la gran colección de programas Kermit que puede encontrar hoy en el sitio web del Proyecto Kermit .

El Proyecto Kermit de Columbia utilizó el DEC-20, nuestro sistema CU20B, como banco de pruebas, bibliotecario y hogar de la red desde el principio hasta que el CU20B (el último DEC-20 restante) se apagó en septiembre de 1988. Se produjo el boletín electrónico Info-Kermit. y enviado a personas en redes académicas y corporativas de todo el mundo desde el DEC-20 utilizando MM, el programa de correo electrónico DEC-20. Esos mismos usuarios podrían utilizar MM y otros clientes de correo electrónico para consultas e información, y también pueden acceder a programas, código fuente y documentación a través de los servidores de archivos DECnet y TCP/IP del DEC-20. Incluso nuestras cintas de distribución se enviaron originalmente desde nuestros DEC-20 en formatos DUMPER, BACKUP y ANSI.

Hasta aproximadamente 1985, DEC-20 Kermit era el "punto de referencia" con el que se debía verificar la interoperabilidad de todos los demás Kermit. Muchas características nuevas de Kermit se agregaron primero a DEC-20 Kermit (modo de servidor, macros, etc.). La interfaz de usuario del DEC-20 se convirtió en el modelo para la mayoría de los programas Kermit, por lo que hoy en día millones de personas utilizan (una simulación notable) el COMND JSYS del DEC-20 sin saberlo. Mucho después de que el DEC-20 desapareciera de escena, los programas Kermit en Windows, UNIX, VMS, MS-DOS y muchas otras plataformas continúan "manteniendo la fe".

Poco después de la aparición de Kermit, la microcomputación se convirtió en una fuerza importante con la introducción de la PC IBM . De repente, las PC se convirtieron en útiles computadoras de uso general por derecho propio. En respuesta a solicitudes urgentes de los profesores de Columbia que habían recibido las primeras PC IBM, produjimos apresuradamente la versión 1.0 de IBM PC Kermit y descubrimos que Kermit se estaba utilizando de maneras que no habíamos previsto. En lugar de utilizar los disquetes de la PC para almacenar archivos de la computadora central, los usuarios hacían la mayor parte de la creación y manipulación de archivos en la PC y enviaban los resultados a la computadora central para archivarlos y compartirlos. Kermit se había convertido en uno de los primeros modelos de procesamiento distribuido.

[ Inicio del Proyecto Kermit ] [ Números de noticias de Kermit ] [ Archivos de la lista de correo de Kermit ] [ Archivos del grupo de noticias de Kermit ]

[ Arriba ] [ Siguiente ] [ Anterior ]

PAQUETES DE PROGRAMAS

Los grandes sistemas DEC de 36 bits fueron la fuente de algunos de los paquetes de software más influyentes y duraderos escritos hasta ahora. Aquí mencionamos arbitrariamente algunos de nuestros favoritos, con disculpas por los cientos que hemos descuidado.

Editores

El más destacado entre los programas creados en estos sistemas es el editor de texto EMACS, creado por Richard M. Stallman en ITS, el "Sistema de tiempo compartido incompatible" del MIT para el PDP-10. EMACS encarnó el concepto revolucionario de que la pantalla del terminal debería actuar como una ventana sobre el texto que se está editando, y que cualquier cambio en el texto debería reflejarse inmediatamente en la pantalla. Después de muchos años de edición orientada a líneas (y antes de eso, pulsación de teclas), al principio nos resultó difícil comprender el poder y la conveniencia de un editor de pantalla. Incluso se discutió si deberíamos permitirlo en nuestro sistema, como si fuera una influencia subversiva... "¿Para qué lo necesitamos? ¡Cada pulsación de tecla genera 37 cambios de contexto!" etc, etc. Pero pronto incluso los escépticos comenzaron a apreciar EMACS por su enorme impulso a la productividad humana, y rápidamente se convirtió en el editor elegido tanto por el personal como por los estudiantes y los profesores. Surgió una industria artesanal en Columbia para agregar nuevos tipos de terminales y operaciones a la base de datos de TECO (DEC-10/20 EMACS fue escrito en TECO), así como nuevas bibliotecas para el propio EMACS.

Si bien algunos pueden considerar EMACS y sus descendientes y parientes como "obsoletos" hoy en día, en comparación con los editores GUI y los procesadores de texto, tienen una gran ventaja sobre los editores más nuevos: están completamente controlados por caracteres ASCII comunes (6) .) (a diferencia de las teclas de función o de flecha, el mouse, etc.), por lo que los mecanógrafos táctiles nunca tienen que abandonar las teclas de inicio, y los usuarios expertos de EMACS pueden ingresar y manipular texto más rápido que los expertos con otros editores, especialmente los editores de GUI modernos pero que requieren mucha mano de obra. . Y al restringir el conjunto de comandos a caracteres ASCII ordinarios, EMACS se puede usar en cualquier plataforma, sin importar cómo acceda a ella (el teclado y la pantalla de la estación de trabajo, una ventana xterm, telnet, dialin, rlogin, ssh, etc.). Otra ventaja de EMACS, por supuesto, es su capacidad de personalización y programación, pero sólo las generaciones mayores de usuarios de computadoras saben o se preocupan por estas cosas.

Formateadores de texto

EMACS es un editor de texto plano, lo que significa que por sí solo normalmente no puede producir efectos de impresión especiales como negrita, cursiva, subrayado, notación matemática, diferentes tamaños de puntos, gráficos, etc. Para eso necesitamos, al menos en el mundo de los caracteres terminales: un formateador de texto. EMACS fue uno de varios editores de pantalla para DEC-20 (TV y TVEDIT fueron otros de los primeros contendientes), y también hubo varios formateadores de texto. El DEC-20 viene, por supuesto, con RUNOFF, el formateador estándar de DEC. RUNOFF es simple, no demasiado potente, pero tiene la ventaja de que los archivos RUNOFF son en su mayoría portátiles entre PDP-11, VAX, DEC-10 y DEC-20. Sin embargo, RUNOFF es propietario y, por lo tanto, no está disponible en sistemas que no sean DEC. RUNOFF también tiene tres defectos básicos. En primer lugar, es estrictamente procesal, lo que significa que el escritor debe comportarse como un programador, instruyendo a RUNOFF hasta el más mínimo detalle. En segundo lugar, no puede hacer matemáticas. Y tercero, no admite una amplia variedad de dispositivos de salida.

Estas deficiencias son abordadas por varios formateadores de texto que fueron desarrollados por usuarios de sistemas grandes de DEC y, de hecho, algunos de sus sistemas más pequeños (UNIX, por ejemplo, fue escrito originalmente para el PDP-7 y luego trasladado al PDP-11). ; UNIX nroff y troff son probablemente ramificaciones de RUNOFF). Los primeros esfuerzos en sistemas de 36 bits incluyeron R y Pub.

Brian Reid, trabajando en un DECsystem-10 para su tesis doctoral en CMU, ideó un lenguaje de producción de documentos llamado Scribe, que abordaba el elemento procesal. Mientras que en RUNOFF se debe decir "centrar y subrayar esta palabra, dejar 7 líneas en blanco, sangrar 4 espacios, etc", en Scribe se dice "Este es un artículo, aquí está el título, aquí hay una sección, aquí hay una nota al pie". , aquí hay una cita bibliográfica, colóquela en el índice, inserte una fotografía aquí y escale así, etc." y deja las decisiones estilísticas y los detalles a Scribe, que incluye una amplia base de datos de tipos de documentos y estilos de publicación. Por ejemplo, si ha escrito un artículo para el CACM, puede pedirle a Scribe que lo formatee en el estilo requerido por el CACM. Cuando el CACM lo rechaza, simplemente le dice a Scribe que lo rehaga en formato de computadora IEEE,7 ).

Durante su desarrollo, Scribe se compartió libremente con otras universidades y hubo mucho toma y daca entre Brian y los usuarios de todas partes. Sin embargo, cuando Brian dejó CMU, los derechos de Scribe se vendieron a una empresa privada, Unilogic Ltd, que lo vendió como producto comercial ( 8 ). Scribe fue un elemento fijo en muchos sitios DEC-10 y -20, y se convirtió del Bliss original a otros lenguajes para su uso en sistemas como UNIX, VMS e incluso mainframes IBM.

Mientras tanto, en Stanford, Donald Knuth estaba planeando nuevas ediciones de su obra de varios volúmenes, El arte de la programación informática . Pero pronto descubrió que desde que se publicaron sus primeras ediciones, el arte de la composición tipográfica matemática, como el de la talla de piedra arquitectónica, había muerto: no pudo encontrar un tipógrafo a la altura de la tarea. Así que se puso a trabajar en un programa informático para composición tipográfica matemática y en un conjunto de fuentes armoniosas adecuadas para descargar desde una computadora a una impresora láser. El trabajo se realizó en un PDP-10 en Stanford, ejecutando su sistema operativo local WAITS ("Espera en tus manos y pies"), en el lenguaje Sail. El resultado, un sistema llamado T EX (tau épsilon chi) y METAFONT, su creador de fuentes complementario, atrajeron a muchos devotos, y el programa Sail original pronto se tradujo a otros idiomas para facilitar su portabilidad. Ahora se ejecuta en muchas plataformas diferentes y es responsable de la producción de numerosos libros y artículos de incomparable belleza tipográfica.

Tanto TeX como Scribe admiten una amplia variedad de dispositivos de salida y se encuentran entre los primeros formateadores de texto en hacerlo. Cuando Xerox dejó que algunas de sus impresoras XGP (una impresora xerográfica experimental con fuentes descargadas del host) escaparan a los laboratorios de Stanford, MIT y CMU a principios de los años 70, éstas se conectaron rápidamente a las PDP-10, para ser manejadas por formateadores como R y Pub. Su flexibilidad impulsó a personas como Don y Brian a incluir conceptos tipográficos completos en sus diseños, y debido a esto, más tarde fue posible agregar soporte a TeX y Scribe para impresoras como la GSI CAT-4 (entonces ampliamente utilizada en Bell). Labs con Troff), Xerox Dover, Imagen y las impresoras PostScript actuales (y si no nos equivocamos, Brian también fue la fuerza impulsora detrás de PostScript).

En el nuevo milenio, Scribe prácticamente ha desaparecido, lo cual es una pena. Pero en cierto modo sigue vivo en LaT E X, que es un lenguaje similar a Scribe construido sobre T E X. Como muchas herramientas de las décadas de 1970 y 1980, Scribe, T E X y LaT E X (y, por ejemplo, eso importa, EMACS) requieren bastante estudio para comenzar, pero vale la pena porque una vez que te sientas cómodo con ellos, ¡puedes superar a todos!

Correo electrónico

Los beneficios del correo electrónico no necesitan ser promocionados, pero hubo un tiempo en que la gente no lo usaba ni confiaba en él. Hoy en día, muchas de esas mismas personas difícilmente pueden vivir sin él. Su principal beneficio es que permite a las personas que participan en él comunicarse cómodamente y con cierta seguridad de que el mensaje será recibido. A diferencia del correo postal, el correo electrónico se puede enviar de forma espontánea y se puede enviar un solo mensaje a más de una persona a la vez. A diferencia de las llamadas telefónicas, el correo electrónico no depende de que la persona que llama esté presente cuando se envía el mensaje. Hay quienes dicen que es una influencia deshumanizante, que las personas en oficinas adyacentes que alguna vez visitaban y charlaban ahora se sientan pegadas a sus pantallas y se envían mensajes de correo electrónico entre sí, mensajes cuya verdadera intención no se puede deducir de la expresión facial. lenguaje corporal, o tono de voz. Esto puede ser cierto, pero el correo electrónico llegó para quedarse y la mayoría de las personas encontrarán una manera de incorporarlo a sus vidas de manera sensata.

Aunque el correo electrónico había estado disponible para su uso dentro de una computadora desde principios de la década de 1960 (por ejemplo, en el sistema de tiempo compartido CTSS del MIT), el correo electrónico entre computadoras comenzó en los DEC-20 (o, estrictamente hablando, en los KL-10 que ejecutaban TENEX, el "proto-TOPS-20"), en BBN en Cambridge, Massachusetts, en 1972 cuando Ray Tomlinson de BBN adaptó su programa de correo electrónico TENEX para enviar mensajes a otros nodos ARPANET. Esto implicó no sólo nuevo software y protocolos, sino también nueva notación: el ahora omnipresente formato de dirección usuario @ host .

Si hiciera un SYSTAT en cualquier DEC-20 en Columbia entre 1978 y 1988, vería aproximadamente la mitad de los usuarios ejecutando EMACS y la otra mitad MM, con solo un tiempo de espera ocasional para formatear texto, compilar programas, transferir archivos y otros tipos. del "trabajo real". MM es el administrador de correo, escrito originalmente por Mike McMahon y asumido más tarde por Mark Crispin. Es el lado del "agente de usuario" del sistema de correo. MM es un programa normal para usuarios sin privilegios que le permite leer su correo, redactar y enviar correo a otros usuarios, reenviar correo y administrar su archivo de correo. MM le permite mover mensajes a diferentes archivos, imprimir mensajes, eliminarlos, marcarlos para atención posterior, etc.

Cualquier operación que MM pueda realizar en un solo mensaje también puede aplicarse a una secuencia de mensajes. Esta es una de las características más poderosas de MM. Las funciones de selección de mensajes de MM le permiten tratar su archivo de correo casi como una base de datos y emitir consultas complejas como "muéstreme (o responda, elimine, reenvíe, marque o imprima) todos los mensajes enviados por fulano de tal". entre tales y tales fechas que son más largas que tantos caracteres e incluyen la palabra 'foo' en su asunto".

MM es enormemente poderoso, pero también es fácil de usar porque emplea completamente COMND JSYS. Los usuarios pueden averiguar lo que se espera en cualquier momento escribiendo un signo de interrogación (excepto al redactar el texto del mensaje, en cuyo caso el signo de interrogación pasa a formar parte del texto). Existe un comando SET que permite personalizar muchas de las operaciones de MM y cambiar sus acciones predeterminadas. Los usuarios pueden guardar estas personalizaciones en un archivo de inicialización, de modo que se realicen automáticamente cada vez que se ejecuta MM.

MM se adoptó rápidamente en favor de DEC-20 MAIL y RDMAIL, y se utilizó inicialmente entre el personal de programación. Su uso se extendió rápidamente entre estudiantes y profesores, hasta el punto de que varios cursos llegaron a depender totalmente de él. Se asignaron tareas y lecturas, se realizaron conferencias, se entregaron tareas, se formularon y respondieron preguntas, todo con MM. MM también se utiliza para publicar mensajes en "tablón de anuncios" públicos, que se utilizaban para todo, desde vender motocicletas usadas hasta cuestionarios de trivia y controversias acaloradas sobre temas políticos.

En Columbia, muchos de los departamentos están distribuidos en diferentes edificios, dentro y fuera del campus. Estos departamentos eran candidatos ideales para el correo electrónico y muchos de ellos realizaban sus actividades diarias utilizando MM. Y MM se siente igualmente a gusto en el entorno de red. Con las conexiones de red y el agente de entrega adecuados, MM puede usarse (y se usa) para transmitir correo electrónico en todo el mundo, más rápido que cualquier oficina de correos o servicio de entrega podría entregar papel. Desde Colombia, enviamos correos electrónicos a lugares tan remotos como Utah, Inglaterra, Noruega, Australia, Brasil, Japón, China y la URSS, y recibimos respuestas en cuestión de minutos (suponiendo que nuestros corresponsales mantengan el mismo tipo de horarios impares que nosotros). ¡hacer!).

Posdata de mayo de 2003: Sólo hizo falta otra década para que el correo electrónico se convirtiera más en una maldición que en una bendición, y que todos los usuarios de computadoras se sintieran abrumados por correo basura y/o malicioso, conocido como "spam". El DEC-20 también fue pionero en esta área: el primer spam se envió el 1 de mayo de 1978 1233-EDT desde DEC-MARLBORO.ARPA (un DEC-20) a todos los contactos de ARPANET (de la base de datos WHOIS), anunciando nuevos Modelos DIC-20.

En 2015, Columbia subcontrató su correo electrónico a Google.

[ Arriba ] [ Siguiente ] [ Anterior ]

OTRAS APORTACIONES DESTACADAS

La arquitectura DEC-20 en realidad se remonta a mediados de la década de 1960, al PDP-6 de DEC, que fue diseñado teniendo en cuenta LISP: las medias palabras y las instrucciones asociadas son perfectas para CAR y CDR (eso es lenguaje LISP, descendiente del conjunto de instrucciones de IBM 704, donde se desarrolló LISP por primera vez). La mayoría de las grandes implementaciones de LISP se realizaron para máquinas de 36 bits de DEC (MACLISP, INTERLISP) y entre las aplicaciones basadas en ellas, MACSYMA del MIT se destaca como un hito. MACSYMA es utilizado por científicos e ingenieros para manipular expresiones matemáticas de complejidad arbitraria en el nivel simbólico, en lugar de numérico. Hay una historia famosa (quizás apócrifa) sobre un astrónomo y matemático del siglo XIX que dedicó su vida a formular la ecuación exacta del movimiento de la Luna. El resultado llenó un libro de 300 páginas.

En 1971, Ralph Gorin de la Universidad de Stanford escribió el primer corrector ortográfico de texto basado en computadora, SPELL for TOPS-10. Posteriormente se adaptó al DEC-20 y se "interconectó" con paquetes como EMACS y MM. Los descendientes de SPELL son legión: ningún programa de procesamiento de textos basado en PC que se precie aparecería en público sin un corrector ortográfico.

[ Arriba ] [ Siguiente ] [ Anterior ]

CONVERTIR A UNIX

[Recuerde: este documento fue escrito en 1988.]

" Navegación tranquila a través de los años 80..." A finales de los años 80, la demanda del servicio DEC-20 se estabilizó y luego comenzó a caer. El DEC-20 era como un clíper, la máxima expresión de una tecnología que muchos creían obsoleta: la gran computadora central de tiempo compartido. Los estudiantes ahora estaban dispuestos a renunciar a las comodidades del DEC-20 por el control y la previsibilidad de una PC propia. Gracias a la membresía de Columbia en el Consorcio de la Universidad Apple, pronto hubo miles de Macintosh en manos de los estudiantes. Acuerdos especiales con IBM También se instalaron IBM PC en cientos de oficinas y dormitorios. Estos sistemas cubrían las necesidades de los estudiantes para pequeñas tareas de programación en Pascal y Basic, así como para un modesto procesamiento de textos, y liberaban a los sistemas centrales de una gran carga. Sin embargo, los PC no cumplían con las necesidades de los departamentos de informática y otros departamentos de ingeniería,donde se asignaron proyectos más grandes en lenguajes como Fortran, C, Prolog y Lisp, que no estaban disponibles de manera fácil y asequible para PC.

Mientras tanto, UNIX se estaba apoderando del mundo de la informática: en mainframes, minis, estaciones de trabajo e incluso PC. Nuestro grupo principal de usuarios de instrucción (estudiantes de informática) realizaba la mayor parte de su trabajo en ATT 3B2 departamentales, pero necesitaba urgentemente un entorno centralizado y confiable con rendimiento tolerable, respaldos, servicio y todo lo demás. Ya llevábamos algunos años ejecutando UNIX en un VAX 750 (para trabajo de desarrollo interno), así como Amdahl UTS en un mainframe IBM, por lo que habíamos desarrollado algo de experiencia en UNIX.

Por estas razones, decidimos que era hora de empezar a convertir de TOPS-20 a UNIX. Por motivos económicos elegimos para este fin un VAX 8650. El intercambio del 20 de diciembre fue atractivo y pudimos conservar nuestras unidades de disco y cinta antiguas. De hecho, calculamos que durante 3 años, comprar el VAX era más barato que conservar el DEC-20. Y era más potente, con un espacio de direcciones más grande y en un espacio más pequeño, que el DEC-20 al que reemplazó.

No se eligió VMS por varias razones. En primer lugar, nos sentíamos algo traicionados por el abandono de TOPS-20 por parte de DEC y no queríamos quedar expuestos al mismo trato en el futuro. UNIX, a diferencia de VMS, no lo vincula a un proveedor en particular. Además, UNIX tiene redes y comunicaciones para todos nuestros requisitos principales: Ethernet, TCP/IP, DECnet (nuestro UNIX inicial era Ultrix-32), BITNET (UREP), terminales RS-232 y LAT, Kermit. Y el propio UNIX tiene muchos beneficios: un entorno de desarrollo de aplicaciones muy potente para programadores experimentados, un shell programable, canalización de programas y utilidades sencillas pero potentes.

UNIX, sin embargo, es notoriamente conciso, críptico y hostil, especialmente para los usuarios novatos de computadoras. VMS, aunque carece del COMND JSYS del DEC-20, es ciertamente más amigable que UNIX y detallado hasta el extremo. Así que no sin algunos recelos nos embarcamos en la conversión.

Muchos de nosotros, los usuarios del DEC-20, nos resistíamos al cambio. La familiaridad, para bien o para mal, suele ser más atractiva que la incertidumbre. Pero la conversión a UNIX nos obligó a renunciar a algunas de las características que originalmente nos atrajeron al DEC-20 en primer lugar.

El shell "fácil de usar" proporcionado por TOPS-20 Exec, que brinda ayuda a quienes la necesitan pero no penaliza a los usuarios expertos, es probablemente la característica que más se echó de menos. En UNIX, la mayoría de los comandos son programas y se supone que tienen argumentos de sólo opciones o nombres de archivos. Esto significa que no puedes tener "?" para comandos y argumentos en el shell, porque los programas que actuarían según la solicitud de ayuda ni siquiera han comenzado a ejecutarse todavía. Esto es lo opuesto a TOPS-20, donde la mayoría de las funciones principales están integradas en el ejecutivo, pero no permite que se conecten programas básicos concisos como lo hace UNIX.

Para citar un ejemplo de la diferencia radical entre las filosofías TOPS-20 y UNIX, supongamos que desea crear un procedimiento que produzca un listado de directorio, lo ordene en orden inverso por tamaño de archivo y formatee el listado en páginas numeradas con tres columnas por tamaño. página, adecuada para imprimir. En TOPS-20 pasarías una semana escribiendo un programa en lenguaje ensamblador para hacer todo esto. En UNIX, las herramientas ya están ahí y sólo hay que combinarlas de la forma deseada:

ls -s | ordenar -r | pr-3

Esto hace que UNIX parezca bastante atractivo. Pero el programa DEC-20, una vez escrito, contendrá ayuda incorporada, comando y finalización de nombres de archivos, etc., mientras que el procedimiento UNIX sólo puede ser utilizado por aquellos que saben exactamente lo que están haciendo. Si ha escrito "ls -s | sort" pero no sabe cuál es la opción de clasificación adecuada, escribir un signo de interrogación en ese momento no servirá de nada porque el programa de clasificación aún no se está ejecutando.

El DEC-20 (como la mayoría de los sistemas operativos comunes) utiliza comandos y nombres de archivos independientes de mayúsculas y minúsculas. La dependencia de casos, sin embargo, es una característica de UNIX que sus defensores defienden vigorosamente. Puede resultar bastante confuso para los usuarios de otros sistemas operativos. En general, los comandos UNIX son muy diferentes de los comandos utilizados en otros sistemas. Incluso si el DEC-20 no hubiera ofrecido un menú de ayuda a pedido, el usuario promedio probablemente habría adivinado los comandos adecuados para escribir: ELIMINAR para eliminar un archivo, COPIAR para copiar un archivo, RENOMBRAR para cambiar el nombre de un archivo, etc. En UNIX, ¿cómo se elimina un archivo? ¿BORRAR? No.... ¿BORRAR? No, es "rm" (¡solo letras minúsculas!).

Sin un manual a tu lado, ¿cómo podrías saber esto? Incluso si conocía "man -k" (búsqueda de palabras clave a través del manual en línea), UNIX no le brinda mucha ayuda: "man -k borrar" no muestra nada relevante, ni "man -k borrar" . Pero al menos "rm" sugiere algo la palabra "remove", y de hecho "man -k remove" habría descubierto el elusivo comando (las primeras versiones de UNIX tenían un nombre aún más elusivo para este comando: dsw, una abreviatura de "do swedanya", adiós en ruso, transliterado al polaco o quizás al alemán, no es el único lugar donde ha estado trabajando la censura... Las versiones "estándar" actuales de UNIX no tienen un comando de "ayuda", pero en lanzamientos anteriores,

Yo (fdc) no recuerdo dónde desenterré la referencia a "do swedanya", pero evidentemente es una leyenda urbana. Dennis Ritchie dijo en una publicación en Usenet de 1981 que la etimología real es "eliminar de los conmutadores"; El programa PDP-7 dsw original fue un precursor de "rm -i" (eliminar interactivamente), en el que los conmutadores de la CPU proporcionaban la interacción.

Una ventaja especial de TOPS-20 es la retención de múltiples generaciones (versiones) de cada archivo, lo que brinda la posibilidad de volver a una versión anterior en caso de que la última sufra un error humano, una locura o una tragedia. Esto, junto con la capacidad de resucitar un archivo después de eliminarlo, imparte una sensación de comodidad y seguridad que sólo puede apreciarse una vez que uno pasa a un sistema de archivos más convencional y precario. Si elimina un archivo en UNIX o crea un archivo nuevo con el mismo nombre que uno existente, entonces el archivo antiguo simplemente desaparecerá. El comando "rm *" en UNIX es simplemente demasiado poderoso y demasiado silencioso. Sí, hizo lo que dijiste, pero ¿cómo supo que querías decir lo que dijiste? UNIX no salva a los usuarios de sí mismos.

Otra característica importante de TOPS-20 es el nombre lógico del dispositivo, que se puede definir en infinita variedad para todo el sistema y para cada usuario individual. Cada nombre lógico puede apuntar a un dispositivo y/o directorio particular, o a una serie completa de ellos, para buscarlos en orden. Estos están integrados en el propio sistema operativo, mientras que la noción de PATH y CDPATH son ideas tardías, injertadas en el shell de UNIX, no disponibles dentro de los programas y no aplicables fuera de sus limitadas esferas de operación.

Luego tenemos los lenguajes de programación que ya no estarían disponibles: ALGOL (60 y 68), APL, BASIC, BCPL, BLISS (10, 11 y 36), CPL (y PL/I "real"), ECL, FOCAL. , PPL, SAIL, SIMULA, SNOBOL, ... ¡Y TECO! Y MACRO y Midas y Fail... De hecho, pocas personas extrañarán alguno de estos, con las posibles excepciones de APL (usado en algunas clases) y SNOBOL (que todavía se puede encontrar para UNIX en plataformas seleccionadas).

Por supuesto, todas nuestras aplicaciones locales escritas en lenguaje ensamblador tuvieron que rehacerse para UNIX: entrada y gestión de ID de usuario (en lugar de editar el archivo passwd), contabilidad, restricciones de usuario (ACJ, Omega). Y una característica sin la que nunca más podríamos vivir es MM, un potente sistema de gestión de correo que pueden utilizar tanto principiantes como expertos.

En el lado positivo, no renunciaríamos a EMACS, Scribe, TeX, Kermit o las utilidades TCP/IP Telnet y FTP. Todos estos programas están disponibles de alguna forma para UNIX. Algunas de las implementaciones de UNIX son mejoras definitivas, como GNU EMACS de la Free Software Foundation, sin las limitaciones de memoria de TOPS-20 EMACS. También hay un Fortran de alta calidad de DEC para nuestros ingenieros y, por supuesto, todos los entornos de programación C y LISP para estudiantes de informática y otros desarrolladores de software, además de un conjunto de potentes utilidades de manipulación de texto como sed, grep, awk, lex y yacc. , cuyas funciones deberían ser obvias por sus nombres.

La instalación de VAX fue mucho más rápida que la instalación típica de DEC-20. El rendimiento del 8650 fue bastante ágil y su confiabilidad excelente. Después de un año, se vendió el 8650 y se cambió un segundo DEC-2065 a DEC por un VAX 8700. El 8700 tiene aproximadamente la misma potencia que el 8650, pero, a diferencia del 8650, es compatible con los nuevos dispositivos BI. y actualizable a un modelo VAX más grande en caso de que se quede sin fuerza.

Sin embargo, resultó que cuando llegó el momento de la expansión, era más rentable comprar sistemas Sun UNIX en lugar de actualizar el 8700 a un VAX más grande. Esta es una opción que no se obtiene con un sistema operativo propietario como TOPS-20, VMS, etc. La conversión de un VAX a un SUN requiere cierta "rendición" (por ejemplo, DECnet), pero no tanto como el viaje desde DEC. -20 a VAX y, a cambio, obtienes una máquina muy poderosa en una fracción del espacio del VAX, lo que debería haber sido el Júpiter, pero con UNIX en lugar de TOPS-20.

[ Arriba ] [ Siguiente ] [ Anterior ]

PRINCIPALES PROBLEMAS DE CONVERSIÓN

[Recuerde: esto fue escrito en 1988.]

Una gran pregunta durante la conversión a UNIX fue la educación del usuario. UNIX no ayuda a los usuarios como lo hace TOPS-20. ¿No existe el estilo COMND? ayuda, ni siquiera hay un comando de "ayuda". Los comandos en sí no tienen nombres intuitivos: sería difícil para un usuario adivinar que "mv" es el comando para cambiar el nombre de un archivo, "cat" para escribir un archivo, etc. ¿Cómo sabrán los usuarios cómo responder al silencio? ¿"$" (o "%") mirándolos a la cara? ¿Deberíamos escribirles un shell fácil de usar? ¿O montones de tutoriales y manuales de referencia?

A pesar de su críptica concisión, UNIX se ha vuelto muy popular. Los sistemas UNIX se ejecutan en computadoras de todo tipo, desde PC hasta supercomputadoras. En consecuencia, las librerías de informática están repletas de libros del tipo "Teach Yourself UNIX". Nuestro sentimiento ha sido que no importa cuán críptico y hostil pueda ser el propio UNIX, no debería cambiarse. De lo contrario, perdemos la compatibilidad con otros sistemas UNIX, libros y artículos, nos exponemos a una pesadilla de mantenimiento y dejamos que nuestros usuarios se lleven una desagradable sorpresa si alguna vez encuentran un sistema UNIX real.

Otro problema es el sistema de correo. Como agente de correo a nivel de usuario, tiene la opción de elegir entre correo UNIX o GNU EMACS RMAIL. El correo UNIX es primitivo y poco intuitivo, y RMAIL sólo es accesible para quienes conocen EMACS. RMAIL tiene la ventaja de una interfaz consistente (sin entrar y salir del editor), pero tiene un repertorio de comandos relativamente limitado.

Nuestros usuarios se han aclimatado mucho al correo electrónico, en gran parte gracias al poder, la conveniencia y la facilidad de uso de MM. Muchos de los mayores usuarios de MM son profesores o administradores que no necesitan aprender a utilizar un nuevo sistema de correo. Pero un programa tan potente como MM requiere muchos comandos, y cuando tienes muchos comandos, necesitas el tipo de ayuda integrada que viene de forma gratuita en el DEC-20. Comentarios similares se aplican a otros programas complicados, por ejemplo (en nuestro sistema) programas de administración y entrada de ID de usuario, la interfaz del operador (como OPR en el DEC-20), etc.

Por esta razón, decidimos "convertir nuestro nuevo sistema en nuestro querido sistema antiguo" escribiendo un paquete COMND para UNIX. Este paquete, CCMD, comenzó como parte del proyecto "Hermit", un esfuerzo de investigación de Columbia financiado por DEC, 1983-87. Intentábamos diseñar una arquitectura de red que permitiera a varios tipos de PC (IBM, Rainbow, Pro-380, VAXstation, SUN, Macintosh, etc.) acceder a los archivos y servicios de nuestros mainframes DEC-20 e IBM de forma coherente y manera transparente. El proyecto finalmente fracasó porque la tecnología nos pasó de largo (conexiones y puertas de enlace Ethernet y Token Ring baratas, Sun NFS, servidores de archivos Macintosh basados en VAX, etc.).

CCMD, escrito completamente en C, realiza todas las funciones COMND y más, analiza desde la terminal, un archivo, una entrada estándar redirigida o una cadena en la memoria. No está orientado a ningún teclado o pantalla en concreto. No favorece ni al principiante ni al experto. Se ejecuta en 4.xBSD, Ultrix, AT&T System V, SunOS y MS-DOS, y debería ser fácilmente portátil a VAX/VMS y a cualquier otro sistema con un compilador de C.

CCMD es una implementación COMND completa, que permite FDB encadenados (por ejemplo, analizar un nombre de archivo, un número o una fecha), redirigir la entrada de comandos, etc. Las adiciones al COMND JSYS de DEC-20 incluyen listas de ayuda "?" para hacer coincidir nombres de archivos, finalización parcial de nombres de archivos (hasta el primer carácter que no es único), un analizador de fecha y hora muy flexible y tipos de datos adicionales.

Utilizando CCMD, los programadores de Columbia pudieron escribir un clon de DEC-20 MM completamente en C. Tiene todas las características de DEC-20 MM, y algunas más. Maneja una variedad de formatos de archivos de correo, incluidos DEC-20, Babyl (RMAIL) y mbox (correo UNIX). Utiliza UNIX sendmail como sistema de entrega y debe ser adaptable a los servicios de entrega de sistemas que no son UNIX.

Los autores, y un sorprendente número de otras personas en todo el mundo, todavía usan Columbia MM hoy como su cliente de correo (pero, lamentablemente, no en Columbia desde 2015). Puede compilarse e instalarse en (al menos) Linux, FreeBSD, OpenBSD, NetBSD, Solaris y SunOS. Puedes encontrarlo AQUÍ .

[ Arriba ] [ Siguiente ] [ Anterior ]

ULTIMAS PALABRAS...

[Recuerde: esto fue escrito en 1988.]

Colombia está altamente descentralizada y enfrenta la restricción presupuestaria común a todas las instituciones de educación superior. No existe un mandato central para colocar costosas estaciones de trabajo en cada escritorio, conectadas por redes de fibra óptica gigabit. Los estudiantes, profesores y personal en su mayor parte utilizan sus propios fondos o fondos departamentales para obtener la mejor PC que pueden usar, generalmente una PC IBM o Macintosh con una interfaz RS-232. La mayoría de los usuarios se comunican sólo esporádicamente mediante acceso telefónico o transportando un disquete a un laboratorio de PC público, donde las PC están conectadas a la red o a una impresora láser.

A medida que las PC se vuelven más baratas y potentes, ¿qué queda por hacer de manera centralizada? Hay quienes afirman que cualquier cosa que pueda hacer un VAX o un DEC-20 también se puede hacer en una PC. Las únicas excepciones pueden ser aplicaciones muy grandes, bases de datos compartidas y/o grandes y/o en constante cambio, y la comunicación en general: redes de área amplia, correo, bibliotecas de programas compartidos, tableros de anuncios, conferencias, etc.

Pero la descentralización masiva de la informática significa una enorme duplicación de esfuerzos y gastos de hardware, licencias de software y mantenimiento. Todos se convierten en administradores de sistemas, realizando copias de seguridad, solución de problemas, instalación y depuración de software, consultoría, capacitación y búsqueda de repuestos. Los investigadores que alguna vez estuvieron tras la pista de una cura para el cáncer o el SIDA ahora están haciendo girar interruptores DIP, ejecutando utilidades Norton en sus discos duros fracturados, hojeando las últimas páginas de BYTE en busca de gangas. Cada persona o grupo puede tener una colección única de software y hardware, lo que hace que la instrucción, la colaboración y la mayoría de las demás funciones sean mucho más difíciles que en los días de tiempo compartido. Y se debe encontrar espacio para equipos informáticos en prácticamente todas las oficinas y dormitorios, en lugar de en un área central. Algún día, los responsables del presupuesto podrían notar el efecto acumulativo de toda esta informática distribuida y el péndulo empezará a girar en la otra dirección. ¿Cuál es la frase "economías de escala"?...

Hubo un artículo en el periódico hace algunos años, durante la crisis del combustible, sobre el regreso de los clíperes... Los grandes sistemas DEC, los clíperes de la era del tiempo compartido, nunca regresarán, pero vivirán en el software que generaron. — EMACS, TeX, Scribe, Spell, MM, Kermit, dialectos LISP avanzados, etc. Mientras tanto, mientras la industria informática lucha por convertir las PC en sistemas multiusuario y por reinventar el multiprocesamiento, la seguridad y otros conceptos olvidados, podría ser rentable detenerse a mirar atrás a las últimas décadas, cuando los gastos y las limitaciones de los equipos informáticos obligaron a los diseñadores y codificadores a ser... bueno, más inteligente.

[ Arriba ] [ Siguiente ] [ Anterior ]

EPÍLOGO

(enero de 2001)

Hoy en día, cuando uno puede entrar a una tienda minorista normal y comprar una computadora con 10 veces la potencia (y 100 veces la memoria principal y 1000 veces la capacidad del disco) del KL10 más grande y rápido jamás fabricado por menos de $1000, conéctelo a con un enchufe de pared común y un conector telefónico (o decodificador de cable, etc.), y estar en Internet en unos minutos con gráficos a todo color, video, sonido y quién sabe qué más, podríamos olvidar fácilmente cómo han evolucionado las computadoras desde las grandes calculadoras independientes con programas almacenados en "comunicadores". Al menos para nosotros en la Universidad de Columbia, el cambio comenzó con los grandes sistemas DEC que nos expusieron a todos a la vez al intercambio de archivos, el correo electrónico y las redes locales y de área amplia, abriendo posibilidades de colaboración y comunicación en el trabajo y en la vida: dentro de la computadora, en todo el campus y en todo el mundo.

La autopsia del PDP-10 ha sido larga y dolorosa (quién lo mató y por qué, cómo podría haber sobrevivido y cómo sería el mundo hoy si lo hubiera hecho), pero aquellos a quienes todavía les gustaría echar un vistazo a los emocionantes tiempos de la década de 1970 y 80, cuando las computadoras se convirtieron por primera vez en un fenómeno cultural y un medio de comunicación ahora puede hacerlo con varios proyectos de emulación de PDP-10 basados en software en marcha. Quizás el mayor legado de aquellos días se encuentre en el actual movimiento de software abierto, en el que desarrolladores de todo el mundo cooperan en proyectos que van desde sistemas operativos (Linux, FreeBSD, etc) hasta aplicaciones de todo tipo, como el original PDP-10 ARPANET. Los "hackers" lo hicieron ( si este es un modelo de negocio viable es una cuestión aparte :-)

Mientras tanto, muchos de nosotros que vivimos esa época mantenemos nuestros viejos hábitos, todavía usando aplicaciones basadas en texto como EMACS y MM en lugar de sus reemplazos GUI de moda pero que requieren mucha mano de obra, pero en plataformas UNIX como Linux en lugar de PDP-10. Cada vez que un nuevo virus de PC sume al planeta entero en el caos y el pánico, apenas nos damos cuenta . Hay algo que decir a favor de las viejas costumbres.