💾 Archived View for texto-plano.xyz › peron › articulos › cpcms.gmi captured on 2023-11-04 at 11:35:28. Gemini links have been rewritten to link to archived content
⬅️ Previous capture (2023-09-08)
-=-=-=-=-=-=-
CP-40, CP-67, y CMS fueron escencialmente sistemas de investigación en virtualización computacional, cuya programación fue tercerizada por fuera de las organizaciones productivas principales de IBM. En su elaboración participaron activamente investigadores ajenos. La experimentación era tanto un objetivo importante y una actividad constante durante su desarrollo.
Este artículo cubre la historia del sistema operativo de tiempo de cómputo compartido CP/CMS, y su contexto histórico.
El desarrollo de CP/CMS ocurrió en un intervalo político y tecnológico bastante complejo.
El sistema de cómputo de tiempo compartido seminal, de primera generación en este paradigma del cómputo, fue el CTSS - demostrado inicialmente en el MIT en 1961, cuyo empleo productivo se extendió desde 1964 a 1974. CTSS abrió camino para la siguiente generación de sistemas de tiempo de cómputo compartido, representada por MULTICS. CP/CMS y todos los demás ambientes de tiempo compartido y conceptos de tiempo de cómputo compartido fueron articulados a partir de finales de la década de 1950, especialmente para solucionar el problema del acceso al cómputo por parte de la comunidad científica. Por entonces, el para realizar cómputo se recurrían principalmente al procesado por lotes - donde los trabajos informáticos se ingresaban a través tarjetas perforadas, y se ejecutaban en secuencia. El tiempo de cómputo compartido ("time-sharing") debía permitir a los usuarios a interactuar directamente con la computadora, de modo que los cálculos y los resultados de las simulaciones computarizadas pudiesen ser recibidos de inmediato.
Los usuarios científios abrazaron rápidamente el concepto de tiempo de cómputo compartiod, e instaron a los fabricantes de equipamiento informático tales como IBM a mejorar las capacidades del tiempo de cómputo compartido. Los pioneros en este paradigma fueron los investigadores del MIT, institucionalizando el llamado Proyecto MAC, iniciativa concebida para desarrollar avances tecnológicos que posibilitasen la aplicación del cómputo de tiempo compartido a mayor escala. Este desembocarían en el entorno MULTICS, un sistema de tiempo de cómputo compartido extremadamente rico en funcionalidades cuya consecuencia sería la insrpiración para emprender el desarrollo inicial de UNIX. Este equipo de alto perfil - con los científicos del cómputo más renombrados en nómina - sistematizó recomendaciones y elaboró requerimientos técnicos muy específicas, tendientes a dar con una plataforma de hardware apropiada para albergar al nuevo sistema.
Los problemas de escala técnica a resolver fueron superlativos. Como consecuencia, la mayoría de los primeros sistemas de tiempo de cómputo compartido fueron atacándolos progresivamente mediante la creación de nuevos lenguajes de programación para sus usuarios, o bien modificaciones de los mismos, tales como el Darthmouth BASIC. A todos estos se accedía a través de intérpretes o contextos de ejecución restringida. Pero específicamente, la visión del Proyecto MAC consistió en buscar desarrollar un cómputo de propósito general de acceso compartido e irrestricto.
IBM - junto a otros fabricantes que hicieron lo propio por su parte - entregó una propuesta para consideración al Proyecto MAC. Sin embargo, la propuesta del Gigante Azul no resultó particularmente bien recibida. Para sorpresa de los ingenieros de IBM, el MIT como fabricante del mainframe que llevaría el sistema MULTICS terminó escogiendo a la General Electric. Las consecuencias de este suceso inesperado llevaron directamente a la creación del CP/CMS.
A comienzos de los 60s, IBM luchaba por definir su rumbo técnico. La gran compañía había identificado un problema con sus ofertas de cómputo del momento: la incompatibilidad entre las muchos productos y líneas de productos IBM. En efecto, cada nueva serie productiva (de hecho, cada nueva generación tecnológica) obligaba a sus clientes a afrontar una enconada lucha contra el nuevo conjunto de especificaciones técnicas, que a menudo eran completamente diferente a la anterior. Los productos de IBM incorporaban amplia variedad de diseños de procesador, arquitecturas de memoria y conjunto de instrucciones, estrategias de entrada/salida, etcétera. Pero esto no era de manera alguna excepcional en la industria. Todos los fabricantes informáticos parecían encarar cada uno de sus nuevos sistemas con un planteo "de cero". IBM consideraba esto como una inconveniencia, pero al mismo tiempo una oportunidad de aceitar el negocios. Sin embargo, el costo de la migración de software se estaba constituyendo en una barrera cada vez más alta para las ventas de hardware conforme aumentaba la masa de clientes, en un círculo vicioso: con cada vez mayor frecuencia estos no se podían permitir actualizar sus mainframes, e IBM quería modificar esto.
Se embarcaron así en una apuesta muy riesgosa: el IBM System/360. Esta línea de productos sería ideada para reemplazar las diversas máquinas ofertadas anteriormente por la compañía, incluyendo mainframes de la serie IBM 7000, la cancelada serie IBM 8000, la serie IBM 1130, y varias otras máquinas especializadas que se usaban en aplicaciones científicas y demás. Este System/360 contaría con opciones de potencia de cómputo, tamaño de memoria, soporte de dispositivos, y costo amplio y sin precedentes; y como factor más impiortante, se asentaría sobre la promesa de retro-compatibilidad. Cualquier cliente podría mudar su software a una nueva máquina de la serie sin requerir modificaciones.
En la actualidad, en un mundo de interfases movidas por estándares y software concebido para la portabilidad multiplataforma, esto podría parecer poco novedoso; pero entonces, el ideario que esperaba coserchar IBM constituia un aspecto técnico y mercadotécnico revolucionario. Con anterioridad al System/360, cada modelo de máquina contaba a menudo con sus propios encuadres y periféricos específicos, y escencialmente sus programas no podían utilizarse con otros sistemas. El hecho de adquirir una CPU más potente implicaba también la necesidad obligada de cambiar también las impresoras, lectores de tarjeta, lectoras de cinta, etcétera. Pero por sobre todas las cosas, los clientes debían abocarse en gran medida reescribir sus programas para que funcionasen con la nueva CPU. Esta era la perspectiva que mas menudo enfurecía a los clientes, mucho más incluso que cambiar los periféricos de trabajo.
Con su System/360, IBM deseaba poner en góndola una gran línea de sistemas de cómputo, todas las cuales compartirían una única arquitectura de procesador, su conjunto de instrucciones, interfaz de Entrada/Salida, y el sistema operativo. Los clientes podrían "combinar y armar" según sus necesidades presentes, y podrían actualizar a futuro, especialmente con la confianza de no tener que reescribir todas sus aplicaciones de software. Por demás, el foco de IBM permaneció puesto en su base de clientes tracionales: grandes corporaciones que hacían procesado de datos administrativos y de negocios.
Al dar inicio a su proyecto de System/360, IBM no cayó en cuenta del riesgo que ello implicaba. El linaje System/360 sería el que finalmente otorgaría a IBM el dominio total sobre la industria del cómputo, y la que la llevaría a ser conocida como "El Gigante Azul". No obstante, el camino no estuvo exceptuado de escollos, y en un principio casi llevó a IBM a la bacarrota: IBM enfrentó uno de los proyectos de ingenería mas grandes y ambiciosos de la historia, y en el transcurso del mismo descrubrió las economías de escala y el mítico "mes-hombre".
Fue durante este "período de pánico" ocasionado por el desvirtuado desarrollo inicial del System/360 que las autoridades del Proyecto MAC solicitaron a IBM la provisión de computadoras con grandes prestaciones en el tiempo de cómputo compartido. En definitiva, esta no había sido la dirección en la que marchaba el desarrollo del System/360: el tiempo de cómputo compartido no había sido considerado un paradigma importante ni escencial por aquella clientela que componía la principal base de IBM. Para ellos lo principal era el procesamiento por lotes.
No era algo ilógico: estos clientes sólo requerían procesado de información financiera y administrativa. Por demás, a principios de los 60s el tiempo de cómputo compartido era terra incógnita. Muchos de los problemas técnicos de los conceptos involucrados - la memoria virtual, por ejemplo - aún no habían sido evaluados ni resueltos. Por ejemplo, aún nadie había podido explicar aún el motivo por el cual la memoria virtual de la Manchester/Ferranti Atlas "no funcionaba". La explicación se encontraría tiempo después - en base a la investigación emprendida sobre CP/CMS y M44/4X - en el basureo de memoria.
Como resultado, la presentación de System/360 en abril de 1964 por parte de IBM prescindió de elementos clave solicitados por aquellos que advocaban el tiempo de cómputo compartido, en particular la memoria virtual. Esta decisión crítica desoló a los investigadores del Proyecto MAC. Se sabe que el equipo de diseño del System/360 se había reunido anteriormente con los investigadores del Proyecto MAC, y que éstos tomaron nota de las objeciones elevadas por ellos para resolverlas; pero en cualquier caso, IBM continuó el desarrollo productivo sin poner siquiera en consideración modificación alguna en dicho sentido.
En febrero de 1964, en el clímax de las disputas de diseño, IBM instituyó un Centro Científico Cambridge ("CSC"), conducido por Norm Rassmussen. Este CSC debía de servir como instituto de enlace entre los investigadores del MIT y los laboratorios internos de IBM, y para recalcar este objetivo, su sede se localizó en el mismo edificio que el Proyecto MAC. En efecto, IBM daba por descontado el hecho de hacerse con la competencia para proveer al Proyecto MAC, reteniendo así su autoproclamado liderazgo en la computación científica y el tiempo de cómputo compartido.
Sin embargo, a poco de rodar, una de las primeras acciones del CSC fue reportar novedades del Proyecto MAC a IBM. IBM recibió el baldazo de agua fría: el MIT se decantaría hacia la propuesta de General Electric con una máquina de su serie 600 modificada con la integración de memoria virtual y otras mejoras importantes (que eventualmente la convertirían en la GE-645). Fue recién ante este hecho que la cúpula de IBM contrapropuso una System/360 modificada para incluir un dispositivo de memoria virtual denominado "Blaauw Box", componente que había sido diseñado para la System/360 (pero no incluida en ella). Sorpresivamente, el MIT rechazó la propuesta: la System/360 con memoria virtual estudiada eera muy diferente al resto de la línea System/360, y el MIT buscaba utilizar computadoras que no estuviesen customizadas ni constituyeran hardware de propósito especial para su sistema MULTICS. Por el contrario, GE se había demostrado dispuesta y preparada para solventar la gran apuesta del cómputo de tiempo compartido. En dicha ocasión IBM fue considerada obstructiva con el paradigma que deseaban impulsar. Para peor, los laboratorios Bell - otro de los clientes importantes de IBM - arribaron pronto a una decisión del mismo tenor, por lo que rechazaban la System/360 apresuradamente adaptada para efectuar cómputo de tiempo compartido.
Las consecuencias del desaire del Proeyecto MAC fueron devastadoras para el CSC, el cual perdió escencialmente su razón de existencia. Notablemente, Rasmussen siguió comprometido con el tiempo de cómputo compartido, e hizo todo lo posible para volver a ganarse la confianza del MIT y otros investigadores académicos. Para ello tomó una decisión riesgosa: su equipo CSC ahora desocupado programaría un sistema operativo de tiempo compartido para la System/360. Con este objetivo en mente, Robert Creasy abandonó el Proyecto MAC para liderar el equipo CSC, el cual se orientó inmediatamente a desarrollar lo que sería CP-40, el primer sistema de máquinas virtuales exitoso basada en hardware completamente virtualizado.
La derrota de IBM en el Proyecto MAC y los Laboratorios Bell causaron repercusiones en toda la compañía:
CSC pronto entregó una propuesta de informatización para el Laboratorio Lincoln del MIT, para colocar la nueva System/360-67, aumentando la credibilidad de IBM ante el MIT. Al orientarse aun producto de tiempo de cómputo compartido "real" en vez de un sistema RPQ adaptado, IBM demostró un interés similar al que el MIT encontró en GE.
CSC también continuó trabajando en el CP-40 - ostensiblemente para proveer asistencia de investigación al equipo de desarrollo de la System/360-67 - probablemente motivado en el excepticismo ante el Proyecto TSS, afectado por un calendario productivo extremadamente agresivo y objetivos grandilocuentes. Como la System/360-67 no estaría disponible al CSC por algún tiempo más, el equipo concebió una medida intemedia ingeniosa: construir su propia System/360 con memoria virtual. Diseñaron una máquina específico en base a una System/360-40 e implementaron todos las modificaciones que pudieron implementar a través de reprogramación de microcódigo. Arribaron así a una plataforma intermedia "comparable", pero que era capaz de soportar la arquitectura de virtualización CP-40. El inicio del desarrollo de la CP-40 real y el desarrollo de CMS comenzaron a mediados de 1965, incluso antes de la llegada de la System/360-40 modificada. El primer uso de producción de la CP-40 se dio en enero de 1967.
Mientras esto sucedía, el proyecto del sistema operativo TSS, se sumía en los retrasos y enfrentaba problemas a diestra y siniestra. El personal CSC se fue convenciendo cada vez mas que la arquitectura de sistema ideal para la máquina de tiempo de cómputo compartido era el CP/CMS.
En septiembre de 1966, el staff del CSC comenzó la tarea de integración de CP-40 y CMS a la System/360-67, bautizándola, logicamente, con la designación CP-67. Esta era una reimplementación significativa del CP-40; el diseño se generalizó substancialmente, para permitir cantidades variables de máquinas virtuales, con mayor cantidad de memoria virtual. A su vez, nuevas estructuras de datos reemplazaron los bloques de control descritptivos de máquinas virtuales, que previamente estaban integrados de forma fija al núcleo. CP-67 agregaba el concepto del almacenamiento libre, donde los bloques de control se disponían dinámicamente. Los enlaces intermódulos también resultaron replanteados, y se hizo que el código fuese recompilable.
Como el CP-67 del CSC tardaría aún más tiempo en ver la luz, el CSC aprovechói para modeficar progresivamente el microcódigo de su propia System/360-40 customizada para simular lo mas fielmente posible a la System/360-67 final (en particular su metodología de memoria virtual diferente. Para superar la ausencia de hardware, el CSC recurrió repetida y eficazmnete simulación; primero al hacer uso de la System/360-40 alterada en espera de su System/360-67, y luego al disponer ya del primer prototipo de System/370. Esto podría considerarse como una excrecencia lógica del concepto de "máquina virtual". Las comprobaciones de uso del CP-67 se efectuaron inicialmente en los centros de cómputo donde el hardware System/360-67 ya se encontraba disponible, notablemente el laboratorio de IBM enb Yorktown Height y el laboratorio Lincoln del MIT.
Los técnicos puestos a evaluar el CP-67 en el laboratorio Lincoln - frustrados ya con los problemas severos del TSS - se vieron muy impresionados con el desempeño del CP-67, e insistieronm a IBM la entrega de una copia de CP/CMS. Tal demanda sacudió a toda la compañía, cuyas miras se habían centrado con creces en el desarrollo del en TSS. Sin embargo, en virtud de la importancia del centro de cómputo del Lincoln, IBM cumplió con el pedido. Podría especularse que esta cadena de eventos podrían haber constituido un subterfugio político de Rasmussen, tendiente a motivar el patrocinio continuo de IBM al trabajo de CSC en el "contra-estratégico" CP/CMS, al cual se "le había pedido bajar la palanca varias veces".
Para abril de 1967, unos pocos meses después que CP-40 entrara en producción, CP/CMS ya estaba siendo utilizado a diario en el Laboratorio Lincoln. El personal del laboratorio trabajaba en contacto con el CSC para mejorarlo. Comenzaron a mejorar CP y CMS tan pronto como lo recibieron. Los técnicos del Lincoln y de Cambridge trabajaron juntos codo a codo, compartían las mejoras del código fuente de manera regular, dando lugar a tradición de compartir el código y mutuo apoyo que duraría años. Aproximadamente al mismo tiempo, Union Carbide - otro cliente influyente de IBM - transitaría la misma senda: decidió usar CP/CMS, y enviar su personal a trabajar con CSC, contribuyendo al esfuerzo de desarrollo de CP/CMS.
Robert Creasy, líder del proyecto CP-40, escribió luego:
El diseño de CP/CMS se llevó a cabo un grupo de desarrollo pequeño y variado, para su propio uso y soporte, y para experimentar con un diseño de sistema de cómputo de tiempo compartido. Los objetivos presupuestarios, calendario de entrega, sus planes y performance tenían poca importancia... También esperábamos rehacer el sistema al menos una vez que lo tuviésemos funcionando. La mayoría de los miembros de nuestro gurpo lo consideraban una experiencia de aprendizaje. La eficiencia se hallaba específicamente excluida como objetivo primordial de diseño de software, aunque siempre se la consideraba. No sabíamos si el sistema contaría relamente con un uso práctico... En enero de 1965, una vez iniciado los trabajos de elaboración del sistema, se hizo patente sus presentaciones a distintos grupos externos, por lo que el sistema se volvió controversial [en IBM].
Por entonces, TSS - sistema que habría d eser "elegante y muy ambicioso", exibía "serios problemas de estabilidad y performance, porque lo habían sacado del horno muy crudo". En febrero de 1968, para ocasión de la conferencia SHARE 30, había 18 centros de cómputo que se habían dado a la farragosa tarea de implementar TSS en las System/360-67. Pero fue durante esa conferencia que IBM anunció - vía "carta azul" - que TSS sería decomisionado - un gran golpe a la comunidad que avogaba por el tiempo de cómputo compartido, y deseaba hacerlo a través de hardware de IBM. Esta decisión sería revertida temporalmente, por lo que TSS no sería desechado hasta 1971. Sin embargo, a partir de entonces fue CP/CMS el sistema que comenzaría a llamar la atención como una alternativa viable.
En la época de la S/360-67, el software se "incluia" con las compras de hardware de computadora. En particular, los sistemas operativos de IBM se encontraban disponibles sin requerir desembolsos adicionales de los clientes de IBM. El CP/CMS era inusual en que se lo entregaba como software Tipo-III sin soporte, en forma de código fuente, lo que significaba que los sitios con CP/CMS usaban un sistema operativo sin soporte. La necesidad de autosoportarse o vivir del soporte comunitario terminó generando sólidas comunidades de usuarios de System/360-67 y CP/CMS, que pueden considerarse precursoras del Movimiento del Código Abierto.
En verano de 1970, el equipo CP/CMS comenzó a trabajar en una versión de CP/CMS para la System/370; esta se convertiría en el sistema operativo de tiempo compartido con virtualización VM/370. CP-370 demostraría ser vital para la continuidad del Proyecto System/370, ya que proveía una simulacion operativa de System/370 en hardware System/360-67, gracias a una reactuación de las estrategias de emulación de hardare anteriores utilizadas en el CSC. Gracias a esta visión la System/370 pudo ser desarrollada y evaluada en tiempo y forma antes que estuviese disponible el hardware System/370. Es que una escasez de prototipos System/370 hacía mella en el desarrollo de su software, en particular su sistema MVS. La hazaña técnica que implico la inter-compatibilidad de las dos líneas por medio de virtualización terminaría transformando el desarrollo de MVS, cuyos desarrolladores fueron premiados con la asignación del sistema operativo CP-370 (muy probablemnete evitando la exitinción del proyecto CP, a pesar de los esfuerzos agresivos para cancelar el proyecto).
Con agosto de 1972 tocó a su fin el desarrollo del CP/CMS, con el anuncio del "System/370 Función Avanzada" de IBM. Este incluia las nuevas System/370-158 y System/370-168; y los sistemas operativos de mainframe DOS/VS (DOS con almacenamiento virtual), OS/VS1 (OS/MFT con almacenamiento virtual), OS/VS2 (OS/MVT con almacenamiento virtual, que podía crecer hasta SVS y MVS), y finalmente el VM/370 (el CP/CMS reimplementado a la nueva línea). Para entonces, el equipo de desarrollo de VM y CP/CMS había crecido a unas 110 personas, incluyendo documentalistas. VM/370 era ahora un sistema IBM real amalgamado, y dejó de ser parte de la Biblioteca de software Tipo-III. Aún así, la distribución del código fuente continuó por varios lanzamientos.
En 1968, los directivos principales de una naciente firma consultora en informática de Connecticut llamada Computer Software Systems tuvo la idea audaz de solicitar en alquiler una System/360-67 a IBM para correr CP/CMS y revender tiempo de proceso de computadora por medio de acceso remoto. La audacia del modelo de negocios se ve en el hecho que típicamente IBM no hacía leasaing de sus sistemas de 40/100 mil dólares por mes a una empresa nueva de dos personas. El tercero y el cuarto empleado eran Dick Orenstein, uno de los autores del CTSS, y Dick Bayles, del CSC – arquitecto principal del CP-67. Otros participantes principales del mundo CP/CMS incluian a Harold Feinleib, Mike Field, y Robert Jesurum (Bob Jay).
Fue para fines de noviembre de 1968 que lograron persuadir a IBM de aceptar la órden (algo no menor) y consumaron los fondos iniciales, tras lo cual CSS recibió su primer System/360-67.
Comenzaron a vender tiempo de cómputo en diciembre de 1968. A este se accedía principalmente a través de terminales teletipo provistas con módems telefónicos de 75 baudios, y se cobraba por minuto de conexión.
CSS rápidamente descubrió que incluso vendierndo todos los minutos de máquina virtual disponibles a los precios publicados, apenas podrían embolsar lo suficiente para poder devengar el mero alquiler mensual de la máquina. Por ello emprendieron un acelerado programa de desarrollo, incrementando las funcionalidades de CP/CMS al punto donde pudieran sacar ganancias. Este sistema comenzó como una bifurcación del código fuente de CP/CMS, y continuó evolucionando con fuerte independencia por unos quince años. El sistema operativo pronto fue rebautizado VP/CSS; la compañía se hizo de accionrio público, y fue renombrada National CSS.
Si bien VP/CSS compartía mucho con su progenitor CP/CMS y su hermano VM/370, en cierta manera divergía de ellos. Por motivos comerciales, el sistema registraba su uso y en este sentido se fue depurando. Como el sistema debía correr alquilando tiempo de cómputo, si sus usuarios se veían frustrados podían dejar de rendir abono en cualquier momento simplemente abandonando su uso colgando el teléfono. Estas necesidades le dieron elevada prioridad a los factores que afectaban la performance, usabilidad y soporte la clientela. VP/CSS pronto se hizo conocido por contar con dos o tres veces mas usuarios interactivos que los sistemas VM comparables.
Las primeras mejoras de NVSS incluyeron áreas tales como migración de páginas, despachos, sistemas de ficheros, soporte de dispositivos, y funciones eficientes de hipervisor de ruta veloz, las que se accedían a través de la instrucción (DIAG). Finalmente, el equipo de desarrollo NCSS rivalizó el tamaño del de IBM, dando lugar a esta amplia gama de mejoras. Otras características notables implementadas más tardiamente incluyeron acceso por red de datos por conmutación de paquetes, comunicación interproceso/intermáquina FILEDEF-level (caños), y una muy sólida integración de bases de datos. Naturalmente, características de gran similitud a las aparecidas posteriormente en la implementación de máquinas virtuales.
La plataforma VP/CSS continuó en uso a lo largo de los años, al menos hasta mediados de la década del 80. NCSS fue adquirido por Dun & Bradstreet en 1979 y rebautizado como DBCS (Servicios de Cómputo Dun & Brandstreet), la cual se concentró en su producto NOMAD, modificando la estrategia de negocios para dar relevancia a VM y otras plataformas. En este proceso discontinuó el soporte y desarrollo de VP/CSS, dando fin a probablemnete el último fork no-VM de CP/CMS.
Interactive Data Corporation (IDC) abordó un plan similar al de National CSS, alquilando servicio de tiempo de cómputo compartido basados en la plataforma CP/CMS. En sus inicios se enfocaba al sector financiero. Los informes de IDC indican la posesión de varias IBM System/360-67 movidas por CP/CMS, así como "uno de los primeros System/370 con relocación de memoria" fabricados por IBM, presumible se refería al modelo System/370-145 de 1971, provista de la primer caja DAT; aunque tal vez se hiciera referencia a sistemas anunciados en 1972 con la publicidad del "System/370 Función Avanzada", que detallaba despachos del System/370-158 y -168.
CMS estaba pensado para soportar su propio desarrollo y mantenimiento, y mantener otros componentes de VM/370. En la mayoría de los casos, un subconjunto de funcionalidades se elegían para implementarlas, con la expectativa de que funcionasen en el futuro. El ambiente - se esperaba - permitiría dar lugar a muchos otros sistemasoperativos menores, que crecerían en las terminales de máquinas virtuales. ¿Qué mejor lugar para experimentar con las ideas de un nuevo sistema que en una máquina virtual, sin necesidad de contar con un hardawre especializado?
Sin embargo, se le terminaron agregvando muchas características nuevas a CMS para extender su uso a áreas que ya eran servidas de forma soberbia por sistemas más nuevos.
Dos generaciones más tarde, en la medida que encontramos una diversidad de plataformas construidas bajo la idea colaborativa de un mundo abierto, es fácil discernir las esperanzas puestas en CP/CMS como una incubadora de desarrollo - lugar que tomó UNIX y sus descendientes - y como tal es fácil entender las apreciaciones de algunos de sus creadores e impulsores corporativos. Este ha sido el destino de muchos sistemas computacionales de investigación, pero pocos comparte un arco histórico superior a las 4 décadas, como los conceptos iniciados por CP-40.