El Conversational Monitor System ( CMS , originalmente Cambridge Monitor System ) [1] es un sistema operativo interactivo simple para un solo usuario . CMS se desarrolló originalmente como parte del sistema operativo CP/CMS de IBM , que entró en producción en 1967. CMS es parte de la familia VM de IBM , que se ejecuta en computadoras mainframe de IBM . VM se anunció por primera vez en 1972 y todavía se usa hoy como z/VM .
CMS se ejecuta como un sistema operativo "invitado" en una máquina virtual privada creada por el programa de control de la máquina virtual . El programa de control y CMS juntos crean un sistema operativo de tiempo compartido para múltiples usuarios.
CMS se desarrolló originalmente como parte del sistema operativo CP/CMS de IBM . En ese momento, el acrónimo significaba "Cambridge Monitor System" (pero también: "Console Monitor System").
En 1972, IBM lanzó su sistema operativo VM/370 , una reimplementación de CP/CMS para el System/370 , en un anuncio que también agregó hardware de memoria virtual a la serie System/370 . A diferencia de CP/CMS , VM/370 fue compatible con IBM. VM pasó por una serie de versiones y todavía se usa hoy en día como z/VM .
A lo largo de todas sus distintas versiones y lanzamientos, la plataforma CMS siguió siendo bastante reconocible como un descendiente cercano de la versión CMS original que funcionaba con CP-40 . Muchas decisiones clave sobre la interfaz de usuario que resultan familiares para los usuarios actuales ya se habían tomado en 1965, como parte del esfuerzo de CP-40 . Consulte CMS con CP-40 para ver ejemplos.
Tanto VM como CP/CMS tuvieron historias con altibajos en IBM. VM no era uno de los sistemas operativos "estratégicos" de IBM, que eran principalmente las familias OS y DOS , y sufrió las luchas políticas internas de IBM sobre los objetivos de tiempo compartido frente a los de procesamiento por lotes . Este conflicto es la razón por la que CP/CMS se lanzó originalmente como un sistema sin soporte técnico y por la que VM a menudo tenía recursos de desarrollo y soporte limitados dentro de IBM. Una comunidad de usuarios excepcionalmente fuerte, establecida por primera vez en los días de autosuficiencia de CP/CMS pero que permaneció activa después del lanzamiento de VM, realizó contribuciones sustanciales al sistema operativo y mitigó las dificultades de ejecutar el "otro sistema operativo" de IBM.
CMS es una parte intrínseca de la arquitectura VM/CMS, establecida con CP/CMS . Cada usuario de CMS tiene control sobre una máquina virtual privada (una copia simulada de la computadora física subyacente) en la que CMS se ejecuta como un sistema operativo independiente. Este enfoque se ha mantenido constante a lo largo de los años y se basa en:
Puede encontrar más detalles sobre cómo CMS interactúa con el entorno de la máquina virtual en los artículos VM y CP/CMS .
CMS se creó originalmente como un sistema operativo independiente, capaz de ejecutarse en una máquina vacía (aunque, por supuesto, nadie optaría por hacerlo). Sin embargo, CMS ya no puede ejecutarse fuera del entorno de la máquina virtual, que proporciona la interfaz de hipervisor necesaria para varias funciones críticas.
CMS proporciona a los usuarios un entorno para ejecutar aplicaciones o trabajos por lotes , administrar archivos de datos , crear y depurar aplicaciones, realizar desarrollo multiplataforma y comunicarse con otros sistemas o usuarios.
CMS aún está en desarrollo y su uso está muy extendido hoy en día.
Los usuarios inician sesión en la máquina virtual, proporcionan un ID de usuario y una contraseña y, a continuación, arrancan su propia máquina virtual. Esto se puede hacer emitiendo el comando "IPL CMS" ("IPL" = initial program load , jerga tradicional de IBM para el arranque de una máquina); aunque normalmente esto se hace de forma automática para el usuario. La personalización personal se realiza mediante un archivo de script de shell estándar denominado "PROFILE EXEC", que configura los valores predeterminados del entorno especificados por el usuario, como los discos y las bibliotecas a los que se accede.
Los CMS comenzaron en la era de los terminales de papel de tipo teletipo y, posteriormente, de los terminales tontos de "teletipo de cristal" . Sin embargo, a fines de la década de 1970, la mayoría de los usuarios de VM se conectaban a través de terminales de pantalla completa, en particular el IBM 3270 , el omnipresente terminal de procesamiento de transacciones en los mainframes de IBM. El 3270 desempeñó un papel estratégico en la línea de productos de IBM, lo que hizo que su selección fuera una opción natural para los grandes centros de datos de la época. Muchos otros fabricantes finalmente ofrecieron terminales bisync que emulaban el protocolo 3270.
Los modelos 3270 tenían un almacenamiento local en búfer, algunas capacidades de procesamiento y, por lo general, manejaban una pantalla completa de datos a la vez. Manejaban las tareas de edición localmente y luego transmitían un conjunto de campos (o la página completa) a la vez cuando se presionaba la tecla ENTER o una tecla de función de programa (PFK).
La familia 3270 incorporaba unidades de control "inteligentes", concentradores y otros elementos de procesamiento de red, que se comunicaban con el mainframe a través de circuitos dedicados a velocidades relativamente altas, mediante un protocolo de comunicación sincrónica bisync . (Estas tecnologías de comunicación orientadas al mainframe proporcionaban algunas de las capacidades que se dan por sentadas en las redes de comunicación modernas, como direccionamiento de dispositivos, enrutamiento, corrección de errores y compatibilidad con una variedad de configuraciones, como topologías multipunto y multidrop ).
El enfoque 3270 difería de las terminales tontas de menor costo de la época, que eran punto a punto y asincrónicas . Los usuarios de tiempo compartido comercial, un segmento importante de los primeros sitios CP/CMS y VM, dependían de estos dispositivos porque podían conectarse a través de módems de 300 o 1200 bit/s sobre circuitos telefónicos de grado de voz normales. Instalar un circuito dedicado para un 3270 a menudo no era práctico, económico ni oportuno.
El enfoque orientado a bloques del 3270 era más coherente con la visión de IBM de la computación orientada a lotes y tarjetas perforadas, y era particularmente importante para los mainframes IBM de la época. A diferencia de las minicomputadoras contemporáneas, la mayoría de los mainframes IBM no estaban equipados para interrupciones de carácter a carácter. El soporte de terminales tontos dependía de unidades de control de terminales como el IBM 270x (ver IBM 3705 ) o Memorex 1270. Estos controladores de terminales asíncronos ensamblaban una línea de caracteres, hasta una longitud máxima fija, hasta que se presionaba la tecla RETURN. Escribir demasiados caracteres daría como resultado un error, una situación familiar para los usuarios de la época. (La mayoría de los centros de datos no incluían este equipo, excepto cuando era necesario para el acceso telefónico. Se prefería el enfoque 3270).
Los terminales orientados a bloques como el 3270 hicieron que fuera práctico implementar editores orientados a pantalla en mainframes, a diferencia de los editores orientados a líneas , la norma anterior. Esta había sido una ventaja importante de las minicomputadoras contemporáneas y otros sistemas orientados a caracteres, y su disponibilidad a través del 3270 fue recibida calurosamente.
Se abrió una brecha entre el mundo 3270, centrado en el procesamiento de transacciones de mainframe orientado a páginas (especialmente a través de CICS ), y el mundo de terminales asincrónicas, centrado en minicomputadoras orientadas a caracteres y tiempo compartido por acceso telefónico. Los proveedores de terminales asincrónicas mejoraron gradualmente sus productos con una gama de características de terminal inteligente , a las que generalmente se accedía a través de secuencias de escape . Sin embargo, estos dispositivos rara vez compitieron por los usuarios de 3270; IBM mantuvo su dominio sobre las decisiones de compra de hardware de centros de datos de mainframe.
En retrospectiva, hubo una importante divergencia filosófica entre la computación orientada a bloques y la orientada a caracteres. Los controladores de terminal asíncronos y los 3270 proporcionaron al mainframe interacciones orientadas a bloques; en esencia, hicieron que la entrada del terminal pareciera un lector de tarjetas. Este enfoque, preferido por IBM, condujo al desarrollo de paradigmas de interfaz de usuario y estrategias de programación completamente diferentes. Los sistemas orientados a caracteres evolucionaron de manera diferente. La diferencia es evidente cuando se compara el enfoque de transacción atómica del CICS dominante con el estilo interactivo y orientado a flujos de UNIX . VM/CMS evolucionó en algún punto entre estos extremos. CMS tiene un entorno interactivo, con estado y controlado por comandos , en lugar de adoptar el enfoque CICS de una interfaz orientada a transacciones sin estado . Sin embargo, CMS responde a la interacción página o línea a la vez, en lugar de interrupciones de caracteres.
CMS se ganó una muy buena reputación por su eficiencia y por contar con buenos factores humanos para facilitar su uso, en relación con los estándares de la época (y, por supuesto, antes del uso generalizado de entornos de interfaz gráfica de usuario como los que se usan comúnmente en la actualidad). No era raro tener cientos (más tarde: miles) de usuarios interactivos de CMS simultáneos en el mismo mainframe VM, con tiempos de respuesta inferiores a un segundo para funciones comunes y "triviales". VM/CMS superó constantemente a MVS y otros sistemas operativos de IBM en términos de soporte para usuarios interactivos simultáneos.
Muchos usuarios de CMS programaron en lenguajes como COBOL , FORTRAN , PL/I , C/370 , APL y el lenguaje de script REXX . VM/CMS se utilizó a menudo como plataforma de desarrollo para sistemas de producción que se ejecutaban en otros sistemas operativos de IBM, como MVS .
Otros usuarios de CMS trabajaron con paquetes de software comerciales como FOCUS , NOMAD , SPSS y SAS .
En un momento dado, CMS también fue un entorno importante para el correo electrónico y la productividad de la oficina; un producto importante fue PROFS de IBM (más tarde rebautizado como OfficeVision ).
Dos herramientas CMS de uso común son el editor XEDIT y el lenguaje de programación REXX . Ambos productos han sido adaptados a otras plataformas y ahora se utilizan ampliamente fuera del entorno mainframe.