En informática , el control de trabajos se refiere al control de múltiples tareas o trabajos en un sistema informático , asegurando que cada uno de ellos tenga acceso a los recursos adecuados para desempeñarse correctamente, que la competencia por recursos limitados no provoque un punto muerto en el que dos o más trabajos no puedan completar, resolver las situaciones en las que se produzcan y finalizar trabajos que, por cualquier motivo, no estén funcionando como se esperaba.
El control de trabajos se ha desarrollado desde los primeros días de las computadoras, donde los operadores humanos eran responsables de configurar, monitorear y controlar cada trabajo, hasta los sistemas operativos modernos , que asumen la mayor parte del trabajo de control de trabajos.
Incluso con un sistema de programación altamente sofisticado, es deseable cierta intervención humana. Los sistemas modernos permiten a sus usuarios detener y reanudar trabajos, ejecutarlos en primer plano (con la capacidad de interactuar con el usuario) o en segundo plano. Los sistemas tipo Unix siguen este patrón .
Para los primeros desarrolladores de computadoras resultó obvio que sus rápidas máquinas pasaban la mayor parte del tiempo inactivas porque el único programa que estaban ejecutando tenía que esperar mientras un dispositivo periférico lento completaba una operación esencial como leer o escribir datos; en términos modernos, los programas estaban vinculados a E/S , no a computación . El almacenamiento en búfer sólo proporcionó una solución parcial; eventualmente, un búfer de salida ocuparía toda la memoria disponible o el programa vaciaría un búfer de entrada, y el sistema se vería obligado a esperar a que un dispositivo relativamente lento completara una operación.
Una solución más general es la multitarea . Más de un programa o proceso en ejecución está presente en la computadora en un momento dado. Si un proceso no puede continuar, su contexto se puede almacenar y la computadora puede iniciar o reanudar la ejecución de otro proceso. Al principio era bastante poco sofisticada y dependía de técnicas de programación especiales, pero pronto se automatizó y generalmente se realizaba mediante un proceso especial llamado programador , que tenía la capacidad de interrumpir y reanudar la ejecución de otros procesos. Normalmente, un controlador para un dispositivo periférico suspende la ejecución del proceso actual si el dispositivo no puede completar una operación inmediatamente y el programador coloca el proceso en su cola de trabajos inactivos. Cuando el periférico completó la operación, el proceso se vuelve a despertar. Una suspensión y reanudación similar también puede aplicarse a la comunicación entre procesos , donde los procesos tienen que comunicarse entre sí de manera asincrónica pero a veces pueden tener que esperar una respuesta.
Sin embargo, esta programación de bajo nivel tiene sus inconvenientes. Un proceso que rara vez necesita interactuar con periféricos u otros procesos simplemente acapararía los recursos del procesador hasta que se complete o se detenga mediante intervención manual. El resultado, particularmente para los sistemas interactivos que ejecutan tareas que interactúan frecuentemente con el mundo exterior, es que el sistema es lento y tarda en reaccionar de manera oportuna. Este problema se resuelve asignando un "intervalo de tiempo" a cada proceso, un período de ejecución ininterrumpida después del cual el programador lo coloca automáticamente en la cola de suspensión. Al proceso se le podrían dar diferentes prioridades, y el planificador podría luego asignar diferentes partes del tiempo de ejecución disponible a cada proceso sobre la base de las prioridades asignadas.
Este sistema de multitarea preventiva forma la base de la mayoría de los sistemas de control de trabajo modernos.
Si bien el procesamiento por lotes puede realizarse las 24 horas del día, con o sin operadores de computadora, [1] dado que la computadora es mucho más rápida que una persona, la mayor parte de la toma de decisiones ocurre incluso antes de que el trabajo comience a ejecutarse y requiere planificación por parte del "programador".
Aunque puede haber un operador de computadora presente, el procesamiento por lotes está diseñado para operar en su mayor parte sin intervención humana. Por lo tanto, se deben incluir muchos detalles en las instrucciones enviadas:
Los primeros sistemas operativos y monitores residentes en las computadoras eran relativamente primitivos y no eran capaces de realizar una asignación sofisticada de recursos. Normalmente, estas decisiones de asignación las tomaba el operador de la computadora o el usuario que envió un trabajo. El procesamiento por lotes era común y los sistemas informáticos interactivos eran raros y costosos. Lenguajes de control de trabajos (JCL) desarrollados como instrucciones primitivas, generalmente perforadas en tarjetas en la parte superior de una baraja que contiene datos de entrada, solicitando recursos como asignación de memoria, números de serie o nombres de carretes de cinta magnética que estarán disponibles durante la ejecución, o asignación de nombres de archivos o dispositivos a los números de dispositivos a los que hace referencia el trabajo. Un ejemplo típico de este tipo de lenguaje, todavía en uso en mainframes, es el lenguaje de control de trabajos de IBM (también conocido como JCL). Aunque el formato de los primeros JCL estaba destinado al uso de tarjetas perforadas , el formato sobrevivió a la transición al almacenamiento en archivos de computadora en disco.
Los sistemas por lotes de mainframe que no eran de IBM tenían algún tipo de lenguaje de control de trabajos, se llamara así o no; su sintaxis era completamente diferente a la de las versiones de IBM, pero generalmente proporcionaban capacidades similares. Los sistemas interactivos incluyen " lenguajes de comandos ": los archivos de comandos (como los archivos ".bat" de PCDOS) se pueden ejecutar de forma no interactiva, pero generalmente no proporcionan un entorno tan sólido para ejecutar trabajos desatendidos como JCL. En algunos sistemas informáticos, el lenguaje de control del trabajo y el lenguaje de comando interactivo pueden ser diferentes. Por ejemplo, TSO en sistemas z/OS utiliza CLIST o Rexx como lenguajes de comando junto con JCL para trabajo por lotes. En otros sistemas esto puede ser lo mismo.
Los JCL que no son de IBM de lo que en un momento se conoció como BUNCH (Burroughs, Univac/Unisys, NCR, Control Data, Honeywell), excepto Unisys , son parte del BANG [3] [4] que ha sido silenciado.
A medida que se desarrollaron los sistemas de tiempo compartido, surgió el control interactivo del trabajo. Un usuario final en un sistema de tiempo compartido podría enviar un trabajo de forma interactiva desde su terminal remota ( entrada de trabajo remota ), comunicarse con los operadores para advertirles sobre requisitos especiales y consultar al sistema sobre su progreso. Podría asignar una prioridad al trabajo y finalizarlo (eliminarlo) si lo desea. Naturalmente, también podría ejecutar un trabajo en primer plano, donde podría comunicarse directamente con el programa en ejecución. Durante la ejecución interactiva, podría interrumpir el trabajo y dejar que continúe en segundo plano o eliminarlo. Este desarrollo de la informática interactiva en un entorno multitarea condujo al desarrollo del shell moderno .
La capacidad de no tener que especificar parte o toda la información sobre un archivo o dispositivo para ser utilizado por un programa determinado se denomina independencia del dispositivo.
La multitarea preventiva con control de trabajo garantiza que un sistema funcione de manera oportuna la mayor parte del tiempo . En algunos entornos (por ejemplo, al operar maquinaria costosa o peligrosa), una fuerte restricción de diseño del sistema es la entrega de resultados oportunos en todas las circunstancias. En tales circunstancias, el control del trabajo es más complejo y el papel de la programación es más importante.
Dado que los sistemas en tiempo real realizan una programación basada en eventos para todas las operaciones en tiempo real, "la secuencia de estas operaciones en tiempo real no está bajo el control inmediato de un operador o programador de computadora". [5]
Sin embargo, un sistema puede tener la capacidad de intercalar tareas en tiempo real y otras tareas menos críticas en el tiempo, donde la línea divisoria podría ser, por ejemplo, la respuesta requerida en una décima de segundo. [5] : p.1 En el caso de los sistemas Xerox RBM (Real-time/Batch Monitor), [6] [7] [8] , por ejemplo, existían otras dos capacidades: [5] : p.2