VS / 9 - VS/9

VS / 9
Logotipo de Sperry Univac.jpg
Desarrollador Univac
Familia OS TSOS
Estado de trabajo Interrumpido
Modelo fuente Desconocido
Versión inicial finales de la década de 1960
Plataformas Computadoras mainframe UNIVAC Serie 90
Interfaz de usuario predeterminada Interfaz de línea de comandos
Licencia Propiedad

VS / 9 es un sistema operativo de computadora descontinuado disponible para los mainframes UNIVAC Serie 90 (90/60, 90/70 y 90/80) desde finales de la década de 1960 hasta la década de 1980. Los equipos Univac 9700 reempaquetados 90/60 y 90/70. Después de la adquisición de RCA por parte de Sperry , se determinó que el sistema operativo RCA TSOS era mucho más avanzado que la contraparte de Univac , por lo que la compañía optó por fusionar el hardware Univac con el software RCA e introdujo el 90/70. El 90/60 se introdujo poco después como un 90/70 más lento y menos costoso. No fue hasta la introducción del 90/80 que VS / 9 finalmente tuvo una plataforma de hardware optimizada para aprovechar al máximo su capacidad para permitir operaciones tanto interactivas como por lotes en la misma computadora.

Antecedentes

En septiembre de 1971, RCA decidió abandonar el negocio de las computadoras mainframe después de perder alrededor de 500 millones de dólares al intentar (y fallar) competir con IBM . La mayoría de los activos de la división informática se vendieron a lo que entonces era Univac . Esto incluyó la serie de computadoras Spectra de RCA , varios diseños de hardware externo (como terminales de video, unidades de cinta y lectores de tarjetas perforadas ) y su sistema operativo, Time Sharing Operating System (TSOS).

TSOS puede haber sido un mejor sistema operativo desde el punto de vista del usuario que cualquiera de IBM, pero en ese momento, los sistemas operativos no se consideraban algo que se vendiera por separado de la computadora, el fabricante lo incluía gratis como parte del precio de compra. Univac introdujo algunas características nuevas adicionales a TSOS y lo renombró VS / 9. Sin embargo, el nombre 'TSOS' permaneció como el nombre de usuario de la cuenta principal privilegiada (Administrador del sistema), que en los sistemas de tipo Unix, se llama 'root'. RCA también vendió TSOS a lo que se convertiría en Fujitsu , y es la base del sistema operativo BS2000 de Fujitsu en sus mainframes del mismo nombre.

Utilizar

Uso interactivo

El uso interactivo de VS / 9 se realizó a través de terminales conectados a una unidad concentradora de terminales, que pasaba señales de control hacia y desde los terminales, de una manera similar a la que IBM proporcionaría con sus terminales estilo IBM 3270 . Esto proporcionó, en general, que la entrada al terminal se enviara en respuesta a una tecla Intro, a diferencia de la práctica en las PC de ingresar un carácter a la vez. La unidad concentradora se conocía originalmente como Módulo de control de comunicaciones o CCM. Sin embargo, RCA había vendido las patentes y los diseños de su controlador de terminal CCM a Singer Corporation , por lo que Univac desarrolló un dispositivo emulador para el CCM que se conocía como el controlador de conexión multiterminal modelo 16, o MCC-16.

El MCC-16 admitía tanto el terminal estándar Univac (de RCA) renombrado como Terminal de pantalla de video Uniscope o VDT, así como terminales tontos ASCII ordinarios . El Uniscope VDT de Univac brindó una capacidad de edición sofisticada (por el momento), incluida la capacidad de editar texto en la pantalla y hacer cambios una línea a la vez o una página a la vez, luego transmitir el texto a la computadora. El VDT también admitía el posicionamiento directo del cursor y la protección de entrada a través de un cursor que indicaba que solo se reconocería el texto después del cursor. También admitía el modo de desplazamiento especial en un subconjunto de la pantalla, o "ventana" en la que, en lugar de que toda la pantalla se desplazara hacia arriba cuando se muestra la última línea, era posible hacer que el área de desplazamiento solo fuera la mitad inferior de la pantalla. (La misma función para el "desplazamiento de pantalla dividida" estaría disponible unos 20 años después en la microcomputadora Apple II ).

Se hizo una distinción entre terminales interactivos (tiempo compartido) y terminales transaccionales. Donde los terminales interactivos fueron controlados directamente por el sistema operativo, los terminales transaccionales se controlaron desde un programa por lotes. Inicialmente, este programa por lotes, conocido como MCP para el Programa de Comunicaciones Multicanal, fue desarrollado para los sistemas operativos orientados a lotes RCA y Sperry, TDOS (Tape-Disk Operating System) y DOS (Disk Operating System). Una vez que quedó claro que se eliminarían gradualmente a favor de un sistema operativo interactivo mucho más robusto, VMOS, MCP fue adaptado para ejecutarse en VMOS. VMOS (Virtual Memory Operating System) se convirtió en el nuevo apodo de TSOS en las computadoras RCA Spectra 70 modelos 46, 61, 3 y 7, y luego inicialmente en las computadoras Univac Series 70 (anteriormente RCA).

Finalmente, MCP se mejoró para admitir terminales Sperry Univac y su nombre se cambió a COS (Sistema operativo de comunicación). Los puertos en el CCM y posteriormente en el MCC que se ejecutan en modo de emulación pueden designarse interactivos o transaccionales, pero no ambos. Si un puerto se designó como puerto interactivo, fue controlado por los servicios de tiempo compartido integrados en el sistema operativo VMOS o VS / 9. Los puertos transaccionales, por otro lado, fueron controlados por COS. Todos los terminales conectados a estos puertos se convirtieron en la "propiedad" del software host controlador respectivo. El tiempo compartido se utilizó para el desarrollo de programas, lo que permitió un desarrollo de programas mucho más rápido que el proceso por lotes tradicional, que era lo último en tecnología en ese momento. Cada usuario de tiempo compartido era una tarea en sí mismo y podía ejecutar programas, crear archivos y solicitar recursos del sistema según fuera necesario. Lo que hizo posible gran parte de esto fue la capacidad del sistema operativo para administrar "memoria virtual", o guardar temporalmente páginas de memoria (incluida la ejecución de programas) en el disco o el tambor mientras no están en uso y luego recuperarlas más tarde según sea necesario. El tamaño de la página de la memoria virtual se fijó en 4096 bytes. Esto permitió que se ejecutaran simultáneamente muchas más tareas de las que de otro modo estarían limitadas por un espacio de memoria principal limitado y costoso. Los usuarios transaccionales, por otro lado, estaban todos controlados por un solo programa y su visión del entorno se limitaba a lo que se les presentaba. No se identificaron como tareas individuales y no tenían la capacidad de ejecutar programas o solicitar recursos del sistema.

El CCM y el MCC que se ejecutaban en modo de emulación eran interfaces de hardware "tontas". Es decir, toda la inteligencia del protocolo de red, incluido el sondeo de terminales, la recuperación de errores y la construcción de mensajes, residía en el mainframe, mientras que CCM y MCC simplemente actuaban como conductos entre el mainframe y las líneas telefónicas. No fue hasta que el MCC se usó como un verdadero procesador frontal que gran parte de esta sobrecarga (como sondeo y recuperación de errores) se descargó del mainframe, liberando así tiempo de la computadora para ejecutar programas de aplicación. Esto no ocurrió hasta la era VS / 9.

Uso por lotes

VS / 9 admitía uno o más lectores de tarjetas, que estaban conectados a la computadora y activados por el usuario colocando una baraja de tarjetas en la tolva y presionando el botón "Inicio". Presumiblemente, la computadora leería la plataforma de origen y colocaría todas las tarjetas leídas en la tolva de salida. Si la baraja de cartas consistía en un inicio de sesión válido, procesaría la baraja de cartas como un trabajo a ejecutar.

Operaciones del sitio

VS / 9 fue controlado por un operador de computadora en el sitio central. Los operadores de computadoras interactuaron con el sistema a través de una consola del sistema. Inicialmente, esta consola era un dispositivo de teletipo, pero luego se actualizó a un dispositivo de visualización de video con una impresora de consola del sistema adjunta. Todos los mensajes de la consola del sistema se registraron en la impresora de la consola del sistema. Los mensajes no solicitados que se originaron en el sistema operativo también se registraron en la impresora de la consola del sistema. Los operadores de computadoras tenían una serie de responsabilidades:

  • Inicialice el sistema mediante un proceso de arranque.
  • Inicie los procesos del programa por lotes.
  • Cargue el programa de control de comunicaciones (MCP o COS) si el sitio tenía terminales transaccionales.
  • Suministre datos de entrada a través de tarjetas perforadas o cintas magnéticas.
  • Monte / desmonte discos y cintas extraíbles según sea necesario para tareas interactivas o por lotes.
  • Priorice los trabajos en ejecución o en las colas de entrada.
  • Ajuste los límites de los terminales interactivos y por lotes para optimizar el rendimiento del sistema.
  • Suministro de papel para las impresoras in situ conectadas localmente.
  • Informe el mal funcionamiento del sistema al personal de mantenimiento del proveedor.
  • Realizar otras tareas según lo especificado por el equipo de gestión del cliente.

Caracteristicas

Grupos de volumen

Una de las mejoras más útiles al final de la vida de VS / 9 fueron los grupos de volumen. La tecnología de disco en ese momento proporcionaba un espacio de almacenamiento limitado en cada disco. Dado que las unidades de disco eran comparativamente grandes y bastante caras, los fabricantes de unidades de disco proporcionaron la capacidad de extraer físicamente el disco real del dispositivo y reemplazarlo por otro. Por lo tanto, los clientes tenían la capacidad de almacenar muchas veces la capacidad de sus unidades de disco, aunque no necesariamente podían usarse simultáneamente a menos que hubiera suficientes unidades de disco libres. El espacio limitado de almacenamiento en disco también presentaba otro problema a los usuarios. Muy a menudo, los archivos serían más grandes de lo que podría contener un disco. Los grupos de volúmenes ayudaron a mitigar este problema tecnológico al permitir que los archivos se distribuyan en varios discos. Los volúmenes (discos) que debían montarse simultáneamente se designaron como "grupo de volúmenes". Los propietarios podrían definirse para limitar el acceso a datos sensibles. Una vez montado y conectado a una tarea activa, todo el grupo de volumen no se podía desmontar hasta que todas las tareas adjuntas lo liberaran o terminaran. Todos los discos disponibles para el sistema eran parte de un grupo de volúmenes, incluso si solo había un volumen en el grupo. Los grupos de volumen pueden designarse como extraíbles o fijos. Los grupos de volúmenes fijos no se pueden eliminar en ningún momento. Esto era necesario para los discos que albergaban el sistema operativo y los archivos que daban soporte a los terminales transaccionales.

Procesamiento remoto por lotes

El procesamiento por lotes remoto (RBP) era una capacidad que existía en VS / 9, aunque nunca se explotó por completo, probablemente debido a la demanda limitada. RBP permitió a los usuarios remotos enviar trabajos por lotes para su ejecución en el mainframe y recibir los resultados en su impresora externa. Normalmente, un dispositivo por lotes remoto constaba de un lector de tarjetas y una impresora conectados a una línea de comunicación que se interconectaba con los servicios por lotes remotos en el sistema operativo. Al igual que un trabajo por lotes local, los operadores pueden recibir solicitudes de montajes / desmontajes de cinta o disco y mensajes de programa para responder a las preguntas.

Tipos de tareas

Tareas administradas por VS / 9 por tipo de tarea. Los tipos de tareas pueden ser programas en ejecución o colas de tareas pendientes. Los siguientes fueron los tipos de tareas utilizados por VS / 9:

  1. Cola de entrada por lotes
  2. Ejecución de programas por lotes
  3. Usuarios activos de tiempo compartido
  4. Cola de salida del spool de impresión y perforación
  5. Dispositivos de impresión y perforación que imprimen o perforan
  6. Cola de salida de RBP
  7. No utilizado
  8. Impresión de dispositivos RBP

MCP y COS siempre fueron tareas de tipo 2. El operador de la computadora vería un recuento del número de tareas dentro de cada cola en la consola del sistema. Una lista completa de las colas de tareas estaba disponible desde cualquier terminal interactivo con acceso de administrador a través de un programa escrito en campo conocido como "Stat200". Este programa escaneaba las colas de tareas cada pocos segundos y mostraba una lista continua de tareas en la pantalla del terminal hasta que se interrumpía o terminaba. Si bien no es un producto lanzado oficialmente, se convirtió en el estándar de facto para el monitoreo de tareas.

Acceso a la cuenta

VS / 9 controló el acceso mediante el uso de un nombre de cuenta y un nombre de usuario. El nombre de la cuenta era un identificador de 1 a 7 caracteres y el nombre de usuario también era un identificador de 1 a 8 caracteres. Los identificadores de nombres de cuentas y nombres de usuarios solo pueden ser letras y números. El nombre de la cuenta era el equivalente a un nombre de directorio en las cuentas de usuario de estilo Unix, con la nota de que el nombre de usuario indicaba qué persona que compartía esa cuenta era la parte que la usaba. Así, por ejemplo, si hubiera un nombre de cuenta de S0103, si hubiera dos usuarios, cuyo nombre era Pat y Leslie en esa cuenta, tendrían un identificador completo de S0103, PAT y S0103, LESLIE. Todos sus archivos se almacenarían en el directorio S0103 y, por lo tanto, no podrían crear archivos con el mismo nombre. Tenga en cuenta que si hubiera un nombre de cuenta de, digamos, PA5, si hubiera un usuario llamado Pat, su identificador sería PA5, PAT y no estaría relacionado en absoluto con ningún otro usuario llamado Pat.

Las cuentas pueden tener restricciones como requerir una contraseña para su uso, límites en la cantidad de archivos, cantidad de uso, tiempo de uso permitido (como permitir solo inicios de sesión después de las 5 pm o antes de las 8 am) y límites de CPU. Un usuario también podría emitir comandos para que el sistema interrumpa un programa si la sesión actual usó más de una cierta cantidad de tiempo de reloj de pared o de CPU.

Un usuario en un terminal que no estaba conectado, que deseaba iniciar una sesión, presionaría la tecla roja Transmitir en un Univac VDT, o usaría Control-C en un terminal ASCII. VS / 9 emitiría la siguiente respuesta:

Bienvenido al sistema de terminales VS / 9. Inicie sesión.

Seguido de una barra ("/"), y en el caso de Univac VDT, el carácter de aviso, que parecía un color inverso mayor que el signo (">"). El usuario iniciaría sesión escribiendo la palabra ' inicio de sesión seguida de su identificador, por ejemplo, su nombre de cuenta, una coma y su nombre de usuario. Si tuvieran una contraseña en su cuenta, escribirían una coma seguida de su contraseña, que podría tener de 1 a 4 caracteres. Si contenía uno o más espacios (distintos de los espacios finales, que podrían omitirse), tenía que escribirse entre comillas simples. Si contenía caracteres no imprimibles o binarios, tenía que escribirlos usando la letra X seguida de una comilla y el valor hexadecimal de 8 caracteres de su contraseña. Entonces, si la cuenta S0103 tuviera la contraseña (en hexadecimal) A0B0C0 y un espacio, entonces el usuario LESLIE iniciaría sesión en el sistema escribiendo

/ INICIO DE SESIÓN S0103, LESLIE, X'A0B0C0 '

Si sus credenciales eran incorrectas, ya sea porque el nombre de la cuenta, el nombre de usuario o la contraseña eran incorrectos, recibirían el mensaje,

Inicio de sesión no válido, inténtelo de nuevo.

y se le dará un indicador / para iniciar sesión nuevamente.

Si sus credenciales eran correctas, entonces si el administrador del sistema (el propietario de la cuenta $ TSOS) había publicado un mensaje del sistema, se mostraría en este momento. El usuario estaría en modo de comando, y aparecería un indicador / estándar donde podría escribir varios comandos. El usuario terminaría su sesión escribiendo LOGOFF y presionando transmitir en el Univac VDT o Control-C en un terminal ascii.

Funciones de terminal

El terminal VDT de Univac tenía cuatro teclas de función en la parte superior, y VS / 9 las reconoció específicamente.

  • F1 era el equivalente a la tecla de interrupción en un terminal Ascii. Si se estaba ejecutando un programa, se interrumpiría y el usuario entraría en modo de interrupción, en el que podría emitir un comando. Podían escribir R o INTR para reanudar la ejecución del programa donde se produjo la interrupción.
  • F2 y F3 podrían configurarse para ser reconocidos por un programa para varias funciones, pero VS / 9 no los utilizó.
  • F4 realizó un cierre de sesión forzado inmediato del usuario en caso de golpe, por accidente o intencionalmente. Esto sería el equivalente en MS-DOS de presionar CTRL-ALT-DEL, que fuerza el reinicio de la máquina inmediatamente.

Comandos del sistema

VS / 9 aceptó comandos escribiendo el comando y cualquier opción. Los comandos emitidos en un flujo por lotes, ya sea como tarjetas o como un archivo por lotes, requerían que fueran precedidos por una barra; los comandos ingresados ​​en una terminal no requieren el uso de la barra. Los comandos incluyeron lo siguiente:

  • EXEC para cargar y ejecutar un programa
  • CARGAR para cargar un programa en la memoria y pasar al modo de comando sin ejecutarlo, para permitir la depuración de comandos
  • HACER ejecutar un archivo por lotes en la sesión actual
  • ENTER para ejecutar un archivo por lotes como si se hubiera enviado al lector de tarjetas
  • SYSFILE para especificar la disposición de la salida impresa
  • LOGOFF para finalizar la sesión. Si alguien iba a usar el terminal o quería cambiar de cuenta, también podía escribir LOGOFF PERO para emitir una solicitud inmediata para un nuevo inicio de sesión. Cualquier salida impresa que el usuario haya generado durante su sesión se enviará a la impresora de línea y se imprimirá en este momento. La opción 'TAPE' podría usarse, como en "LOGOFF TAPE", "LOGOFF TAPE", "LOGOFF PUT, TAPE" o "LOGOFF TAPE, BUT" para indicar que la salida impresa pendiente debe ser enviada a cinta magnética en lugar de imprimirse. Se enviará una solicitud al operador del sistema.

Si uno ha emitido una interrupción a un programa en ejecución (a través de la tecla Break en un terminal ASCII o la tecla F1 en un Univac VDT) o ha utilizado el comando LOAD en lugar de EXEC, uno estaría en "modo de interrupción" en el que el programa se suspendió para permitir que el usuario esté en modo comando. También podrían emitir los comandos anteriores y los siguientes:

  • R para reanudar un programa interrumpido por la tecla de interrupción
  • INTR para emitir una interrupción-reanudación a un programa que admita INTR
  • Comandos de depuración
VS / 9 incluyó la Ayuda de depuración interactiva (IDA) que proporcionó comandos para ver la memoria y los registros, detectar errores de programa y almacenar memoria en ubicaciones. A diferencia de otros sistemas en los que un depurador interactivo requería ejecutar un programa para usarlo o vincular un módulo a un programa, IDA era parte del sistema operativo y sus comandos estaban disponibles desde el modo de interrupción.
Otro producto muy útil, pero no compatible, para depurar problemas del sistema operativo fue un programa llamado "CareCity". El sistema operativo VS / 9 se suministró como módulos premontados en cintas magnéticas. Durante la instalación, los módulos seleccionados se vincularon entre sí según los parámetros de configuración proporcionados para formar el sistema operativo en funcionamiento y luego se guardaron en el disco. Cada módulo tenía un espacio libre designado al final, que se usaba para parchear el código existente en caso de error, sin volver a ensamblar todo el módulo. CareCity permitió al administrador ver el contenido de la memoria del sistema operativo usando direcciones relativas al inicio de cada módulo del sistema operativo . El código de parche se podría insertar en las áreas de parche designadas según sea necesario y luego se podrían insertar ramas del código existente al código recién instalado. Todo esto podría hacerse mientras el sistema operativo estaba en uso .

Convenciones de nombres de archivos

Los nombres de archivo pueden tener hasta 56 caracteres de longitud. Un archivo puede constar de letras, números, guiones y dígitos. Se permitía un nombre de archivo de todos los dígitos, pero un archivo no podía tener dos puntos consecutivos. Para acceder a un archivo en otra cuenta, era necesario que un usuario de esa cuenta hiciera público el archivo. Si el archivo era público, otro usuario podría acceder a él colocando el prefijo del nombre del archivo con el indicador de que un archivo al que se hace referencia está en otra cuenta, que era el signo de dólar ("$"), seguido del nombre de la cuenta, seguido de un punto.

Si hubiera un archivo llamado "A" en la cuenta S0103, y un usuario en la cuenta PA5 quisiera acceder al archivo en la cuenta S0103, primero, el archivo tendría que estar marcado como público, y segundo, tendría que ser referenciado por el nombre de la cuenta y el nombre del archivo. Por lo tanto, un usuario de la cuenta PA5 que quisiera acceder al archivo A de la cuenta S0103, si el archivo era público, lo haría referencia como "$ S0103.A". Tenga en cuenta que un usuario en la cuenta S0103 podría hacer referencia al archivo simplemente como "A" o podría hacer referencia a él con un nombre de archivo completo al incluir un signo de dólar y su propio nombre de cuenta, seguido de un punto y el nombre.

Se puede acceder a los archivos públicos de la cuenta especial TSOS utilizando $ solo como primer carácter del archivo, a menos que el archivo comience con un nombre que sea idéntico a un número de cuenta, en cuyo caso la cuenta explícita hace referencia a $ TSOS. sería necesario. Además, $ TSOS. era lo que se llamaría el nombre de la ruta para los archivos faltantes referenciados por su nombre que no se encontraron en la cuenta del usuario. Por ejemplo, si había un archivo llamado S0103.XYZZY en la cuenta $ TSOS, y había una cuenta en ese sistema llamada S0103, cualquier usuario que desee acceder a él tendría que acceder a él como "$ TSOS.S0103.XYZZY".

TSOS también era la cuenta "predeterminada" para un archivo al que se hacía referencia y que no existía localmente. Por ejemplo, para ejecutar el programa editor de EDT , se emitiría el comando para ejecutar un programa, EXEC, seguido del nombre del archivo, que se llamaba EDT. Entonces, si el usuario no había creado un archivo llamado EDT, podría ejecutar el editor EDT escribiendo

/ EXEC EDT

y presionando la tecla de transmisión. Si, por alguna razón, hubieran creado un programa con el mismo nombre, para usar el editor del sistema, tendrían que escribir

/ EXEC $ EDT

o podrían escribir explícitamente en la cuenta del sistema

/ EXEC $ TSOS.EDT

Cuando Unisys descontinuó las ventas de los mainframes de la serie 9000 en favor de los equipos de la serie EXEC 8 (probablemente porque ya no eran rentables y el mercado de mainframes se había reducido), la empresa abandonó efectivamente el VS / 9.

Ver también

Referencias