Lenguaje de control de trabajo

El lenguaje de control de trabajos ( JCL ) es un lenguaje de programación que se utiliza en los sistemas operativos mainframe de IBM para indicar al sistema cómo ejecutar un trabajo por lotes o iniciar un subsistema. ^[1] El propósito del JCL es indicar qué programas se deben ejecutar, qué archivos o dispositivos se deben utilizar ^para la entrada o salida y, en ocasiones, también indicar en qué condiciones se debe omitir un paso. Los parámetros del JCL también pueden proporcionar información de contabilidad para realizar un seguimiento de los recursos utilizados por un trabajo, así como en qué máquina se debe ejecutar el trabajo.

Hay dos lenguajes de control de trabajos de IBM distintos:

• uno para el linaje del sistema operativo que comienza con DOS/360 y cuyo último miembro es z/VSE ; y
• el otro para el linaje de OS/360 a z/OS , este último ahora incluye extensiones JES , Job Entry Control Language (JECL).

Comparten algunas reglas sintácticas básicas y algunos conceptos básicos, pero por lo demás son muy diferentes. ^[3]

El sistema operativo VM no tiene JCL como tal; los componentes CP y CMS tienen cada uno lenguajes de comando .

Ciertas palabras o frases utilizadas junto con JCL son específicas de la tecnología de mainframe de IBM.

• Conjunto de datos: un "conjunto de datos" es un archivo; puede ser temporal o permanente y estar ubicado en una unidad de disco, una cinta de almacenamiento u otro dispositivo. ^{[4] [5]}
• Miembro: un "miembro" de un conjunto de datos particionado (PDS) es un conjunto de datos individual dentro de un PDS. Se puede acceder a un miembro especificando el nombre del PDS con el nombre del miembro entre paréntesis. Por ejemplo, la macro del sistema GETMAIN en SYS1.MACLIB se puede referenciar como SYS1.MACLIB(GETMAIN). ^[6]
• Conjunto de datos particionado: un "conjunto de datos particionado" o PDS es una colección de miembros o archivo. Los conjuntos de datos particionados se utilizan comúnmente para almacenar datos textuales como código fuente, macros de ensamblador (SYS1.MACLIB), configuración del sistema (SYS1.PARMLIB), procedimientos JCL reutilizables (SYS1.PROCLIB), etc. Como tales, tienen algo en común con los archivos de almacenamiento (ZIP, TAR, etc.) y con los directorios de otros sistemas operativos. También se utilizan para almacenar código binario (módulos de carga u objetos de programa); en ese aspecto, son aproximadamente análogos a las bibliotecas estáticas basadas en ar en los sistemas basados ​​en Unix. Como ocurre con la mayoría de estas estructuras, un miembro, una vez almacenado, no se puede actualizar; el miembro debe eliminarse y reemplazarse, como con la utilidad IEBUPDTE . ^[6] Desde el lanzamiento de MVS DFP 3.2 en 1989, los PDSE (conjunto de datos particionados extendido) han existido como una versión mejorada de PDS; ^[7] Desde el punto de vista del usuario o del programador de aplicaciones, prácticamente no han cambiado (salvo por la eliminación de algunas características heredadas poco claras), pero su implementación interna es muy diferente.
• USS: Servicios del sistema Unix, un entorno Unix completo que se ejecuta como parte del programa de control base MVS y que permite que archivos, scripts, tareas y programas Unix se ejecuten en un mainframe en un entorno Unix totalmente compatible con POSIX sin virtualización.

Originalmente, los sistemas mainframe estaban orientados al procesamiento por lotes . Muchos trabajos por lotes requieren una configuración, con requisitos específicos para el almacenamiento principal y dispositivos dedicados como cintas magnéticas , volúmenes de discos privados e impresoras configuradas con formularios especiales. ^[8] JCL se desarrolló como un medio para garantizar que todos los recursos necesarios estén disponibles antes de programar la ejecución de un trabajo. Por ejemplo, muchos sistemas, como Linux, permiten la identificación de los conjuntos de datos necesarios que se especificarán en la línea de comandos y, por lo tanto, estarán sujetos a la sustitución por parte del shell o serán generados por el programa en tiempo de ejecución. En estos sistemas, el programador de trabajos del sistema operativo tiene poca o ninguna idea de los requisitos del trabajo. Por el contrario, JCL especifica explícitamente todos los conjuntos de datos y dispositivos necesarios. El programador puede preasignar los recursos antes de liberar el trabajo para que se ejecute. Esto ayuda a evitar el " punto muerto ", donde el trabajo A contiene el recurso R1 y solicita el recurso R2, mientras que el trabajo B que se ejecuta simultáneamente contiene el recurso R2 y solicita R1. En tales casos, la única solución es que el operador de la computadora finalice uno de los trabajos, que luego debe reiniciarse. Con el control de trabajos, si el trabajo A está programado para ejecutarse, el trabajo B no se iniciará hasta que el trabajo A se complete o libere los recursos necesarios.

Tanto para DOS como para OS la unidad de trabajo es el trabajo . Un trabajo consta de uno o varios pasos, cada uno de los cuales es una solicitud para ejecutar un programa específico. Por ejemplo, antes de la era de las bases de datos relacionales , un trabajo para producir un informe impreso para la administración podía constar de los siguientes pasos: un programa escrito por el usuario para seleccionar los registros apropiados y copiarlos a un archivo temporal; ordenar el archivo temporal en el orden requerido, generalmente utilizando una utilidad de propósito general; un programa escrito por el usuario para presentar la información de una manera que sea fácil de leer para los usuarios finales e incluya otra información útil como subtotales; y un programa escrito por el usuario para formatear páginas seleccionadas de la información del usuario final para mostrarlas en un monitor o terminal.

Tanto en el JCL de DOS como en el de OS, la primera "tarjeta" debe ser la tarjeta JOB, que: ^[9]

• Identifica el trabajo.
• Generalmente proporciona información para permitir que el departamento de servicios informáticos facture al departamento de usuario correspondiente.
• Define cómo se ejecutará el trabajo en su conjunto, por ejemplo, su prioridad en relación con otros trabajos en la cola.

Los procedimientos (comúnmente llamados procs ) son JCL preescritos para pasos o grupos de pasos, insertados en un trabajo. Ambos JCL permiten este tipo de procedimientos. Los procs se utilizan para repetir pasos que se utilizan varias veces en un trabajo o en varios trabajos diferentes. Ahorran tiempo al programador y reducen el riesgo de errores. Para ejecutar un procedimiento, simplemente se incluye en el archivo JCL una única "tarjeta" que copia el procedimiento de un archivo especificado y lo inserta en el flujo de trabajo. Además, los procs pueden incluir parámetros para personalizar el procedimiento para cada uso.

Tanto el JCL de DOS como el de OS tienen una longitud de línea máxima utilizable de 80 caracteres, porque cuando se utilizaron por primera vez DOS/360 y OS/360, el método principal para proporcionar nueva entrada a un sistema informático eran tarjetas perforadas de 80 columnas . ^[10] Más tarde se hizo posible enviar trabajos a través de archivos de disco o cinta con longitudes de registro más largas, pero los componentes de envío de trabajos del sistema operativo ignoraban todo lo que estuviera después del carácter 80.

Estrictamente hablando, ambas familias de sistemas operativos utilizan sólo 71 caracteres por línea. Los caracteres 73 a 80 son normalmente números de secuencia de tarjeta que el sistema imprime en el informe de fin de trabajo y son útiles para identificar las ubicaciones de los errores informados por el sistema operativo. El carácter 72 normalmente se deja en blanco, pero puede contener un carácter que no esté en blanco para indicar que la instrucción JCL continúa en la siguiente tarjeta.

Todos los comandos, nombres de parámetros y valores deben estar en mayúsculas, excepto los nombres de archivos USS .

Todas las líneas, excepto las de entrada en flujo (ver más abajo), deben comenzar con una barra " /", y todas las líneas que procesa el sistema operativo deben comenzar con dos barras //, siempre comenzando en la primera columna . Sin embargo, hay dos excepciones: la declaración delimitadora y la declaración de comentario. Una declaración delimitadora comienza con una barra y un asterisco ( /*), y una declaración de comentario en OS JCL comienza con un par de barras y un asterisco ( //*) o un asterisco en DOS JCL.

Muchas declaraciones JCL son demasiado largas para caber en 71 caracteres, pero pueden extenderse a un número indefinido de tarjetas de continuación mediante:

La estructura de los tipos de tarjeta más comunes es: ^[11]

Tanto el JCL de DOS como el de OS permiten la entrada en flujo, es decir, "tarjetas" que deben ser procesadas por el programa de aplicación en lugar del sistema operativo. Los datos que deben conservarse durante mucho tiempo normalmente se almacenan en el disco, pero antes de que se generalizara el uso de terminales interactivas , la única forma de crear y editar dichos archivos de disco era suministrando los nuevos datos en tarjetas.

Los JCL de DOS y OS tienen diferentes formas de señalar el inicio de la entrada en flujo, pero ambos finalizan la entrada en flujo en /*la columna 1 de la tarjeta siguiente a la última tarjeta de datos en flujo. Esto hace que el sistema operativo reanude el procesamiento del JCL en la tarjeta siguiente a la /*tarjeta. ^[12]

• OS JCL: las sentencias DD se pueden utilizar para describir datos en flujo, así como conjuntos de datos. Una sentencia DD que trata con datos en flujo tiene un asterisco (*) después del identificador DD, p. ej //SYSIN DD *. Las sentencias JCL se pueden incluir como parte de los datos en flujo mediante las sentencias DD DATA.

Un operando llamado DLM permitió especificar un delimitador (el valor predeterminado es "/*"). Especificar un delimitador alternativo permite que JCL se lea como datos, por ejemplo, para copiar procedimientos a un miembro de la biblioteca o para enviar un trabajo al lector interno .

• Un ejemplo, ^[13] que envía un trabajo al lector interno ( INTRDR ) y luego elimina dos archivos es:

// SUBM EJEC PGM = IEBGENER // SYSPRINT DD SYSOUT = Z // SYSUT2  DD SYSOUT = ( A , INTRDR ) // SYSIN  DD DUMMY // SYSUT1  DD DATOS , DLM = ZZ // RUNLATR TRABAJO CUENTA , MANIX , CLASE = A . TYPRUN = HOLD //* ^ un TRABAJO para ejecutar más tarde // CPUHOG EXEC PGM = PICALC1K // SALIDA  DD DSN = PICALC .1000 DGTS , SPACE = ( TRK , 1 ), DISP = (, KEEP ) ZZ //* ^ como se especifica por DLM=ZZ // DROPOLDR EXEC PGM = IEFBR14 // DELETE4  DD DSN = PICALC .4 DGTS , DISP = ( OLD , DELETE ) // DELETE5  DD DSN = PICALC .5 DGTS , DISP = ( OLD , DELETE )        

1. El programa llamado PICALC1K esperará (TYPRUN=HOLD) siendo liberado manualmente
2. El programa llamado IEFBR14 se ejecutará AHORA y una vez finalizado, se eliminarán los dos archivos existentes, PICALC.4DGTS y PICALC.5DGTS.

• DOS JCL: simplemente ingrese los datos en el flujo después de la tarjeta EXEC para el programa.

Fred Brooks , quien supervisó el proyecto OS/360 en el que se creó JCL, lo llamó "el peor lenguaje de programación informática jamás ideado por nadie, en cualquier lugar" en The Design of Design , donde lo utilizó como ejemplo en el capítulo "Cómo los diseñadores expertos se equivocan". ^[14] Atribuyó esto a la incapacidad de los diseñadores para darse cuenta de que JCL es, de hecho, un lenguaje de programación.

Gran parte de la complejidad del JCL de OS, en particular, se deriva de la gran cantidad de opciones para especificar la información de los conjuntos de datos . Mientras que los archivos en los sistemas operativos tipo Unix se abstraen en secuencias ordenadas de bytes, y la tarea de leer y escribir datos estructurados pertenece exclusivamente a los programas de nivel de usuario (que, en última instancia, ingieren y emiten dichas secuencias), y los detalles prácticos del almacenamiento y acceso a los datos son manejados en gran parte por el sistema operativo sin el conocimiento de los programas de usuario; los conjuntos de datos en OS/360 y sus sucesores exponen sus tipos y tamaños de archivos, tipos y longitudes de registros, tamaños de bloque, información específica del dispositivo como la densidad de la cinta magnética e información de la etiqueta. Aunque existen valores predeterminados del sistema para muchas opciones, todavía hay mucho que especificar por parte del programador, a través de una combinación de JCL e información codificada en el programa. Cuanta más información se codifique en el programa, menos flexible será, ya que la información del programa anula cualquier cosa en el JCL; por lo tanto, la mayor parte de la información generalmente se proporciona a través de JCL.

Por ejemplo, para copiar un archivo en un sistema operativo Unix , el usuario ingresaría un comando como:

cp Archivo antiguo Archivo nuevo

El siguiente ejemplo, utilizando JCL, podría usarse para copiar un archivo en OS/360:

// TRABAJO IS198CPY ( IS198T30500 ), 'TRABAJO DE COPIA' , CLASE = L , MSGCLASS = X // COPY01 EXEC PGM = IEBGENER // SYSPRINT DD SYSOUT = * // SYSUT1  DD DSN = OLDFILE , DISP = SHR // SYSUT2  DD DSN = NEWFILE , // DISP = ( NEW , CATLG , DELETE ), // ESPACIO = ( CYL ,( 40 , 5 ), RLSE ), // DCB = ( LRECL = 115 , BLKSIZE = 1150 ) // SYSIN  DD DUMMY       

Una segunda explicación de la complejidad de JCL son las diferentes expectativas para ejecutar un trabajo que las que se encuentran en un PC o un entorno tipo Unix.

• Las CPU System/360 de gama baja eran menos potentes y más caras que las PC de mediados de la década de 1980 para las que se diseñó MS-DOS. OS/360 estaba destinado a sistemas con un tamaño mínimo de memoria de 32 KB y DOS/360 a sistemas con un mínimo de 16 KB. Una CPU 360/30 (de gama baja cuando se anunció System/360 en 1964) procesaba entre 1,8 K y 34,5 K instrucciones por segundo. ^[15] La primera IBM PC en 1981 tenía 16 KB o 64 KB de memoria y procesaba alrededor de 330 K instrucciones por segundo. ^{[16] [17]} Como resultado, JCL tenía que ser fácil de procesar para la computadora , y la facilidad de uso por parte de los programadores era una prioridad mucho menor. En esta era, los programadores eran mucho más baratos que las computadoras.
• JCL fue diseñado para el procesamiento por lotes . Como tal, debe indicarle todo al sistema operativo, incluido qué hacer según el resultado de un paso. Por ejemplo, DISP=(NEW,CATLG,DELETE)significa "si el programa se ejecuta correctamente, crea un nuevo archivo y cataloga; de lo contrario, elimina el nuevo archivo". Los programas que se ejecutan en una PC dependen con frecuencia del usuario para solucionar los problemas de procesamiento.
• Las máquinas System/360 fueron diseñadas para ser compartidas por todos los usuarios de una organización. Por lo tanto, la JOBtarjeta le indica al sistema operativo cómo facturar la cuenta del usuario ( IS198T30500), qué cantidad predefinida de almacenamiento y otros recursos se pueden asignar ( CLASS=L), y varias cosas más. //SYSPRINT DD SYSOUT=*le indica a la computadora que imprima el informe del programa en la impresora predeterminada que está cargada con papel común, no en otra impresora que podría estar cargada con cheques en blanco. DISP=SHRle indica al sistema operativo que otros programas pueden leer OLDFILE al mismo tiempo .

Las versiones posteriores de los sistemas operativos DOS/360 y OS/360 conservan la mayoría de las características del JCL original, aunque se han realizado algunas simplificaciones para evitar obligar a los clientes a reescribir todos sus archivos JCL. ^{[ cita requerida ]} Muchos usuarios guardan como procedimiento cualquier conjunto de declaraciones JCL que es probable que se utilicen más de una o dos veces. ^[18]

La sintaxis de OS JCL es similar a la sintaxis de las macros en el lenguaje ensamblador System/360 y, por lo tanto, habría sido familiar para los programadores en una época en la que muchos programas estaban codificados en lenguaje ensamblador.

// TLBL TAPEFIL,'COPYTAPE.JOB',,,,2 // ASSGN SYS005,200 // DLBL DISKFIL,'COPYTAPE.JOB',0,SD // EXTENT SYS005,VOL01,1,0,800,1600    

Los parámetros JCL de DOS son posicionales, lo que los hace más difíciles de leer y escribir, pero más fáciles de analizar para el sistema.

• El programador debe recordar qué elemento va en qué posición en cada tipo de declaración.
• Si se omiten algunos parámetros opcionales pero se incluyen otros posteriores, los parámetros omitidos deben representarse mediante comas sin espacios, como en la declaración TLBL anterior.

El JCL de DOS mitiga hasta cierto punto las dificultades de los parámetros posicionales al utilizar más instrucciones con menos parámetros que el JCL de OS. En el ejemplo, las instrucciones ASSGN, DLBL y EXTENT hacen el mismo trabajo (especificar dónde se debe almacenar un nuevo archivo de disco) que una sola DDinstrucción en el JCL de OS.

En el DOS/360 original y en la mayoría de las versiones de DOS/VS, era necesario especificar el número de modelo del dispositivo que se iba a utilizar para cada archivo de disco o cinta, incluso para los archivos existentes y para los archivos temporales que se eliminarían al final del trabajo. Esto significaba que, si un cliente actualizaba su equipo a uno más moderno, era necesario cambiar muchos archivos JCL.

Los miembros posteriores de la familia DOS/360 redujeron el número de situaciones en las que se requerían números de modelo de dispositivo.

Originalmente, DOS/360 requería que el programador especificara la ubicación y el tamaño de todos los archivos en DASD . La EXTENTtarjeta especifica el volumen en el que reside la extensión, la pista absoluta inicial y la cantidad de pistas. Para z/VSE, un archivo puede tener hasta 256 extensiones en diferentes volúmenes.

El JCL del SO consta de tres tipos básicos de declaraciones: ^[19]

• JOBdeclaración, que identifica el inicio del trabajo e información sobre todo el trabajo, como facturación, prioridad de ejecución y límites de tiempo y espacio.
• EXECdeclaración, que identifica el programa o procedimiento ^[20] que se ejecutará en este paso del trabajo,
  e información sobre el paso, incluidas las condiciones para ejecutar u omitir un paso.
• DDDeclaraciones de (Definición de datos), que identifican un archivo de datos que se utilizará en un paso e información detallada sobre ese archivo. DDLas declaraciones pueden estar en cualquier orden dentro del paso.

Desde el principio, JCL para la familia de sistemas operativos (hasta z/OS inclusive ) fue más flexible y fácil de usar.

Los siguientes ejemplos utilizan el antiguo estilo de sintaxis que se proporcionó desde el lanzamiento de System/360 en 1964. La antigua sintaxis todavía es bastante común en trabajos que se han estado ejecutando durante décadas con solo cambios menores.

Cada declaración JCL se divide en cinco campos: ^[21]

Identificador-Nombre del campo-Operación del campo-Parámetro del campo-Comentarios del campo ^ ^ ^ ^ No hay espacio, espacio, espacio, espacio

El campo identificador debe concatenarse con el campo nombre , es decir, no debe haber espacios entre ellos.

• Campo identificador ( //): el campo identificador indica al sistema que una declaración es una declaración JCL y no datos. El campo identificador consta de lo siguiente:
  • Las columnas 1 y 2 de todas las declaraciones JCL, excepto la declaración delimitadora, contienen//
  • Las columnas 1 y 2 de la declaración delimitadora contienen/*
  • Las columnas 1, 2 y 3 de una declaración de comentario JCL contienen//*
• Campo de nombre : el campo de nombre identifica una sentencia en particular para que otras sentencias y el sistema puedan hacer referencia a ella. Para sentencias JCL, debe codificarse de la siguiente manera:
  • El nombre debe comenzar en la columna 3.
  • El nombre tiene entre 1 y 8 caracteres alfanuméricos o nacionales ( $, #, @).
  • El primer carácter debe ser alfabético.
  • El nombre debe ir seguido de al menos un espacio en blanco.
• Campo de operación : el campo de operación especifica el tipo de instrucción o, en el caso de la instrucción de comando, el comando. El campo de operación debe codificarse de la siguiente manera:
  • El campo de operación consta de los caracteres en el cuadro de sintaxis de la declaración.
  • La operación sigue el campo de nombre.
  • La operación debe estar precedida y seguida por al menos un espacio en blanco.
  • La operación será una de JOB, EXECy DD.
• Campo de parámetros : el campo de parámetros, también denominado a veces campo de operandos, contiene parámetros separados por comas. El campo de parámetros debe codificarse de la siguiente manera:
  • El campo de parámetro sigue al campo de operación.
  • El campo de parámetro debe estar precedido por al menos un espacio en blanco.
  • El campo de parámetro contiene parámetros que son palabras clave que se utilizan en la declaración para proporcionar información como el nombre del programa o del conjunto de datos.
• Campo de comentarios : contiene comentarios . El campo de comentarios debe codificarse de la siguiente manera:
  • El campo de comentarios sigue al campo de parámetros.
  • El campo de comentarios debe estar precedido por al menos un espacio en blanco.

// ARCHIVONUEVO DD DSN = MYFILE01 , UNIDAD = DISCO , ESPACIO = ( TRK , 80 , 10 ), // DCB = ( LRECL = 100 , BLKSIZE = 1000 ), // DISP = ( NUEVO , CATLG , ELIMINAR )  

Todos los parámetros principales de las instrucciones JCL del SO se identifican mediante palabras clave y se pueden presentar en cualquier orden. Algunos de ellos contienen dos o más subparámetros, como SPACE(cuánto espacio en disco asignar a un nuevo archivo) y DCB(especificación detallada del diseño de un archivo) en el ejemplo anterior. Los subparámetros a veces son posicionales, como en SPACE, pero los parámetros más complejos, como DCB, tienen subparámetros de palabras clave.

Los parámetros posicionales deben preceder a los parámetros de palabras clave. Los parámetros de palabras clave siempre asignan valores a una palabra clave utilizando el signo igual ( =). ^[22]

La DDdeclaración se utiliza para hacer referencia a datos. Esta declaración vincula la descripción interna de un conjunto de datos de un programa con los datos de dispositivos externos: discos, cintas, tarjetas, impresoras, etc. El DD puede proporcionar información como un tipo de dispositivo (por ejemplo, '181', '2400-5', 'TAPE'), un número de serie de volumen para cintas o discos y la descripción del archivo de datos, llamado el DCBsubparámetro después del bloque de control de datos (DCB) en el programa utilizado para identificar el archivo.

La información que describe el archivo puede provenir de tres fuentes: la información de la tarjeta DD, la información de la etiqueta del conjunto de datos de un archivo existente almacenado en cinta o disco y la macro DCB codificada en el programa. Cuando se abre el archivo, estos datos se fusionan, y la información de la DD tiene prioridad sobre la información de la etiqueta, y la información de la DCB tiene prioridad sobre ambas. La descripción actualizada se vuelve a escribir en la etiqueta del conjunto de datos. Esto puede provocar consecuencias no deseadas si se proporciona información incorrecta de la DCB. ^[23]

Debido a los parámetros enumerados anteriormente y a la información específica para varios métodos y dispositivos de acceso, la sentencia DD es la sentencia JCL más compleja. En un manual de referencia de IBM, la descripción de la sentencia DD ocupa más de 130 páginas, más del doble que las sentencias JOB y EXEC juntas. ^[24]

La instrucción DD permite que se inyecten datos en línea en el flujo de trabajo. Esto resulta útil para proporcionar información de control a utilidades como IDCAMS, SORT, etc., así como para proporcionar datos de entrada a programas.

Desde el principio, el JCL para la familia de sistemas operativos OS ofrecía un alto grado de independencia de dispositivo. Incluso para los archivos nuevos que se debían conservar después de finalizar el trabajo, se podía especificar el tipo de dispositivo en términos genéricos, por ejemplo UNIT=DISK, UNIT=TAPE, o UNIT=SYSSQ(cinta o disco). Por supuesto, si era importante, se podía especificar un número de modelo o incluso una dirección de dispositivo específica. ^[25]

Los procedimientos permiten agrupar una o más instrucciones " EXEC PGM= " y DD y luego invocarlas con " EXEC PROC= procname" -o- simplemente "EXEC procname" ^[26]

Una función llamada Biblioteca de Procedimientos permitió almacenar previamente los procedimientos.

Los procedimientos también se pueden incluir en el flujo de trabajo finalizando el procedimiento con una // PENDdeclaración y luego invocándolo por su nombre, como si estuviera en una biblioteca de procedimientos.

Por ejemplo:

// SUMPRINT PROC // PRINT EJECUTAR PGM=IEBGENER // SYSUT1  DD DSN = CEO . FILES . DAYEND . RPT24A , DISP = SHR // SYSUT2  DD SYSOUT = A // SYSIN  DD DUMMY // PEND // EJECUTAR SUMPRINT    

Los procedimientos JCL del SO fueron parametrizados desde el principio, haciéndolos más bien como macros o incluso subrutinas simples y aumentando así su reutilización en una amplia gama de situaciones. ^[27]

// MYPROC PROC FNAME = MYFILE01 , SPTYPE = TRK , SPINIT = 50 , SPEXT = 10 , LR = 100 , BLK = 1000 ..... // NEWFILE DD DSN =& FNAME , UNIDAD = DISCO , ESPACIO = ( & SPTYPE , & SPINIT , & SPEXT ), // DCB = ( LRECL =& LR , BLKSIZE =& BLK ), DISP = ( NEW , CATLG , DELETE ) .... 

En este ejemplo, todos los valores que comienzan con el signo & " &" son parámetros que se especificarán cuando un trabajo solicite que se utilice el procedimiento. La declaración PROC, además de darle un nombre al procedimiento, permite al programador especificar valores predeterminados para cada parámetro. Por lo tanto, se podría utilizar el procedimiento de este ejemplo para crear nuevos archivos de distintos tamaños y diseños. Por ejemplo:

// TRABAJO01 TRABAJO .......... // PASO01 EJECUTAR MIPROC FNAME=JOESFILE,SPTYPE=CYL,SPINIT=10,SPEXT=2,LR=100,BLK=2000 o // TRABAJO02 TRABAJO .......... // PASO01 EJECUTAR MIPROC FNAME=SUESFILE,SPTYPE=TRK,SPINIT=500,SPEXT=100,LR=100,BLK=5000          

En trabajos de varios pasos, un paso posterior puede utilizar una referencia en lugar de especificar por completo un archivo que ya se ha especificado en un paso anterior. Por ejemplo:

// MYPROC ................ // MYPR01 EJECUTAR PGM = .......... // ARCHIVONUEVO DD DSN = & MYFILE , UNIDAD = DISCO , ESPACIO = ( TRK , 50 , 10 ) , // DCB = ( LRECL = 100 , BLKSIZE = 1000 ) , DISP = ( NUEVO , CATLG , ELIMINAR ) .... // MYPR02 EJECUTAR PGM = .......... // ENTRADA01 DD DSN = * .MYPR01.ARCHIVONUEVO      

Aquí, MYPR02se utiliza el archivo identificado como NEWFILEen el paso MYPR01( DSNsignifica "nombre del conjunto de datos" y especifica el nombre del archivo; un DSN no puede superar los 44 caracteres ^[28] ).

En trabajos que contienen una combinación de JCL específicos del trabajo y llamadas a procedimientos, un paso específico del trabajo puede hacer referencia a un archivo que se especificó completamente en un procedimiento, por ejemplo:

// MYJOB JOB .......... // STEP01 EXEC MYPROC Utilizando un procedimiento // STEP02 EXEC PGM = ......... Paso específico para este trabajo // INPUT01 DD DSN = * . STEP01 . MYPR01 . NEWFILE        

donde DSN=*.STEP01.MYPR01.NEWFILEsignifica "utilizar el archivo identificado como NEWFILEen el paso MYPR01del procedimiento utilizado por el paso STEP01de este trabajo". El uso del nombre del paso que llamó al procedimiento en lugar del nombre del procedimiento permite que un programador utilice el mismo procedimiento varias veces en el mismo trabajo sin confusión sobre qué instancia del procedimiento se utiliza en la referencia.

Los archivos JCL pueden ser largos y complejos, y el lenguaje no es fácil de leer. El JCL del SO permite a los programadores incluir dos tipos de comentarios explicativos:

• En la misma línea que una declaración JCL. Se pueden ampliar colocando un carácter de continuación (convencionalmente " X") en la columna 72, seguido de " // " en las columnas 1 a 3 de la línea siguiente.
• Líneas que contienen solo comentarios, que suelen utilizarse para explicar puntos importantes sobre la estructura general del JCL en lugar de detalles locales. Las líneas que solo contienen comentarios también se utilizan para dividir archivos JCL largos y complejos en secciones.

// MYJOB JOB .......... //* Líneas que contienen solo comentarios. //******** Se usa a menudo para dividir el listado JCL en secciones ******** // STEP01 EXEC MYPROC Comentario 2 en la misma línea que la declaración // STEP02 EXEC PGM = ......... El comentario 3 se ha extendido y X // se desborda en otra línea. // INPUT01 DD DSN = STEP01 . MYPR01 . NEWFILE          

OS JCL permite a los programadores concatenar ("encadenar") archivos de entrada para que aparezcan en el programa como un solo archivo, por ejemplo

// ENTRADA01 DD DSN = MYFILE01 , DISP = SHR // DD DSN=JOESFILE,DISP=SHR // DD DSN=SUESFILE,DISP=SHR    

La segunda y tercera sentencia no tienen ningún valor en el campo de nombre, por lo que el SO las trata como concatenaciones. Los archivos deben ser del mismo tipo básico (casi siempre secuenciales) y deben tener la misma longitud de registro, aunque la longitud del bloque no tiene por qué ser la misma.

En las primeras versiones del sistema operativo (ciertamente antes de OS/360 R21.8) la longitud del bloque debe estar en orden decreciente, o el usuario debe inspeccionar cada instancia y agregar a la declaración DD nombrada la longitud máxima del bloque encontrada, como, por ejemplo,

// INPUT01 DD DSN = MYFILE01 , DISP = SHR , BLKSIZE = 800 // DD DSN=JOESFILE,DISP=SHR (se supone que BLKSIZE es igual o menor que 800) // DD DSN=SUESFILE,DISP=SHR (se supone que BLKSIZE es igual o menor que 800)    

En versiones posteriores del sistema operativo (ciertamente después de OS/MVS R3.7 con las "unidades seleccionables" apropiadas), el propio sistema operativo, durante la asignación, inspeccionaría cada instancia en una concatenación y sustituiría la longitud máxima de bloque que se encontrara.

Una solución habitual era simplemente determinar la longitud máxima posible del bloque en el dispositivo y especificarlo en la declaración DD nombrada, como, por ejemplo,

// INPUT01 DD DSN = MYFILE01 , DISP = SHR , BLKSIZE = 8000 // DD DSN=JOESFILE,DISP=SHR (se supone que BLKSIZE es igual o menor que 8000) // DD DSN=SUESFILE,DISP=SHR (se supone que BLKSIZE es igual o menor que 8000)    

El propósito de esta alternativa era garantizar que el método de acceso asignara un conjunto de búfer de entrada que fuera lo suficientemente grande para acomodar todos y cada uno de los conjuntos de datos especificados.

El sistema operativo espera que los programas establezcan un código de retorno que especifique el grado de éxito que el programa consideró que tuvo. Los valores convencionales más comunes son: ^{[29] : p.87}

• 0 = Normal - todo OK
• 4 = Advertencia: errores o problemas menores
• 8 = Error - errores o problemas significativos
• 12 = Error grave: errores o problemas importantes; no se debe confiar en los resultados (por ejemplo, archivos o informes producidos).
• 16 = Error de terminal: problemas muy graves, ¡no utilice los resultados!

El JCL del SO se refiere al código de retorno como COND("código de condición") y puede usarlo para decidir si se ejecutan los pasos subsiguientes. Sin embargo, a diferencia de la mayoría de los lenguajes de programación modernos, los pasos condicionales en el JCL del SO no se ejecutan si la condición especificada es verdadera, lo que da lugar a la regla mnemotécnica "Si es verdadera, pasar a través de [sin ejecutar el código]". Para complicar aún más las cosas, la condición solo se puede especificar después del paso al que se refiere. Por ejemplo:

// MITRABAJO TRABAJO ........... // PASO01 EJECUTAR PGM = PROG01 .... // PASO02 EJECUTAR PGM = PROG02 , COND = ( 4 , GT , PASO01 ) .... // PASO03 EJECUTAR PGM = PROG03 , COND = ( 8 , LE ) .... // PASO04 EJECUTAR PGM = PROG04 , COND = ( SOLO , PASO01 ) .... // PASO05 EJECUTAR PGM = PROG05 , COND = ( PAR , PASO03 ) ....            

medio:

1. Ejecute STEP01y recopile su código de retorno.
2. No ejecute STEP02si el número 4 es mayor que STEP01el código de retorno de .
3. No ejecute STEP03si el número 8 es menor o igual a cualquier código de retorno anterior.
4. Ejecutar STEP04solo si STEP01finaliza anormalmente.
5. Corre STEP05, incluso si STEP03finaliza de forma anormal.

Esto se traduce al siguiente pseudocódigo :

ejecute STEP01 si el código de retorno de STEP01 es mayor o igual a 4 , entonces ejecutar PASO02fin si si cualquier código de retorno anterior es menor que 8 entonces ejecutar PASO03fin si si PASO01 terminó anormalmente entonces ejecutar PASO04fin si si STEP03 terminó anormalmente entonces ejecutar PASO05demás ejecutar PASO05terminar si

Tenga en cuenta que al leer los pasos que contienen CONDlas declaraciones al revés, se pueden entender con bastante facilidad. Este es un ejemplo de transposición lógica . Sin embargo, IBM introdujo más tarde la condición IF en JCL, lo que hizo que la codificación fuera algo más sencilla para los programadores, al tiempo que conservaba el CONDparámetro (para evitar realizar cambios en los JCL existentes donde COND parmse utiliza).

El CONDparámetro también puede especificarse en la JOBinstrucción. En ese caso, el sistema "realiza las mismas pruebas de código de retorno para cada paso de un trabajo. Si se satisface una prueba de código de retorno de la instrucción JOB, el trabajo finaliza". ^[30]

Los trabajos utilizan una serie de programas de utilidades de IBM para ayudar en el procesamiento de datos. Las utilidades son más útiles en el procesamiento por lotes. Las utilidades se pueden agrupar en tres grupos:

• Utilidades de conjuntos de datos: cree, imprima, copie, mueva y elimine conjuntos de datos.
• Utilidades del sistema: mantener y administrar catálogos y otra información del sistema.
• Servicios de método de acceso: procesa conjuntos de datos de método de acceso a almacenamiento virtual (VSAM) y no VSAM.

El JCL del sistema operativo es innegablemente complejo ^[31] y ha sido descrito como "hostil al usuario". ^{[32] [33]} Como preguntaba un libro instructivo sobre JCL, "¿Por qué incluso los programadores sofisticados dudan cuando se trata del lenguaje de control de tareas?" ^[34] El libro afirmaba que muchos programadores copiaban tarjetas de control sin entender realmente lo que hacían, o "creían los rumores prevalecientes de que el JCL era horrible y que solo los informáticos 'más duros' lo entendían" y delegaban la tarea de descifrar las instrucciones del JCL en otra persona. ^[34] Se podía encontrar una actitud similar en los libros de texto de lenguajes de programación, que preferían centrarse en el lenguaje en sí y no en cómo se ejecutaban los programas en él. Como decía un libro de texto de Fortran IV al enumerar los posibles mensajes de error del compilador WATFOR : "¿Ha sido tan tonto como para intentar escribir sus propias tarjetas de control del sistema 'DD'? Deje de hacerlo y desista de inmediato; corra, no camine, en busca de ayuda". ^[35]

Sin embargo, algunos libros que profundizaban en el JCL enfatizaban que una vez aprendido hasta un grado al menos relativamente competente, uno se liberaba de los valores predeterminados de toda la instalación y tenía un control mucho mejor sobre cómo un sistema IBM procesaba su carga de trabajo. ^{[34] [31]} Otro libro comentaba sobre la complejidad pero decía: "Anímese. La capacidad de JCL que obtendrá del [capítulo anterior] es todo lo que la mayoría de los programadores necesitarán". ^[31]

En los sistemas mainframe de IBM, Job Entry Control Language o JECL es el conjunto de instrucciones de control del lenguaje de comandos que proporcionan información para el subsistema de spooling : JES2 o JES3 en z/OS o VSE/POWER para z/VSE . Las instrucciones JECL pueden "especificar en qué computadora de red ejecutar el trabajo , cuándo ejecutarlo y dónde enviar la salida resultante". ^[29]

JECL es distinto del lenguaje de control de trabajos (JCL), que indica al sistema operativo cómo ejecutar el trabajo.

Hay diferentes versiones de JECL para los tres entornos.

Una versión anterior del lenguaje de control de entrada de trabajos para la entrada de trabajos remota de OS/360 (número de programa 360S-RC-536) utilizaba el identificador   ..  en las columnas 1 y 2 del registro de entrada y consistía en una única declaración de control: JED(Definición de entrada de trabajo). Los "comandos de estación de trabajo" como LOGON, LOGOFF, y STATUStambién comenzaban con   .. . ^[36]

Aunque el término aún no se había desarrollado, HASP tenía una funcionalidad similar a lo que se convertiría en el JECL de JES , incluida /*la sintaxis.

En JES2, las instrucciones JECL comienzan con /*, en JES3, con //*, excepto los comandos remotos   /*SIGNON  y   /*SIGNOFF  . Los comandos para los dos sistemas son completamente diferentes.

Las siguientes declaraciones JECL de JES2 se utilizan en z/OS 1.2.0. ^[37]

Las siguientes declaraciones JECL JES3 se utilizan en z/OS 1.2.0 ^[39]

Para VSE, las instrucciones JECL comienzan con ' * $$' (observe el espacio simple ). El lenguaje de control de entrada de trabajos define las líneas de inicio y fin de los trabajos JCL. Informa a VSE / POWER sobre cómo se maneja este trabajo. Las instrucciones JECL definen el nombre del trabajo (usado por VSE/POWER), la clase en la que se procesa el trabajo y la disposición del trabajo (es decir D, L, K, H).

Ejemplo:

* $$ TRABAJO JNM=NOMBRE,DISP=K,CLASE=2[Algunas declaraciones de JCL aquí]* $$ EOJ

Otros sistemas de procesamiento por lotes de mainframe tenían algún tipo de lenguaje de control de trabajos, ya sea que se llamara así o no; su sintaxis era completamente diferente 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 estos generalmente no proporcionan un entorno tan sólido para ejecutar trabajos desatendidos como JCL. En algunos sistemas informáticos, el lenguaje de control de trabajos y el lenguaje de comandos interactivo pueden ser diferentes. Por ejemplo, TSO en sistemas z/OS usa CLIST o Rexx como lenguajes de comandos junto con JCL para el trabajo por lotes. En otros sistemas, estos pueden ser los mismos.

• dd (Unix) , programa Unix inspirado enDD
• Programas de utilidad para mainframe de IBM
• Procesamiento por lotes
• Conjunto de datos (mainframe de IBM)#Grupo de datos de generación

• "Guía del usuario de z/OS V1R6.0 MVS JCL" (PDF) (5.ª ed.). IBM. Septiembre de 2004. Archivado desde el original (PDF) el 2013-08-19 . Consultado el 2006-10-12 .
• "Referencia de JCL de z/OS V1R7.0 MVS" (PDF) (11.ª ed.). IBM. Abril de 2006. Archivado desde el original (PDF) el 19 de agosto de 2013. Consultado el 12 de octubre de 2006 .
• Johnston, Jerry (1 de abril de 2005). "VSE: Una mirada a los últimos 40 años". z/Journal . Thomas Communications. Archivado desde el original el 4 de marzo de 2009.
• "Computer Chronicles: 1972 - 1981". ThinkQuest . Oracle Corporation . 1998. Archivado desde el original el 21 de junio de 2009.
• DeWard Brown, Gary (7 de junio de 2002). zOS JCL (5.ª ed.). Wiley. ISBN 978-0-471-23635-1.
• "Campos de instrucciones JCL". Referencia JCL de MVS para z/OS V1R11.0 z/OS V1R10.0-V1R11.0 . IBM. 2010.
• IBM Corporation (marzo de 2007). Introducción al nuevo mainframe: conceptos básicos de z/VSE (PDF) . IBM, Organización Internacional de Soporte Técnico. ISBN 978-0-73-848624-6. Recuperado el 6 de diciembre de 2017 .
• Ashley, Ruth; Fernández, Judi N. (1978). Lenguaje de control de tareas: una guía de autoaprendizaje . Nueva York: John Wiley & Sons. ISBN 0-471-03205-0.
• McQuillen, Kevin (1975). Lenguaje ensamblador (OS) System/360–370 . Fresno, California: Mike Murach & Associates. LCCN  74-29645.
• Stern, Nancy; Stern, Robert A. (1980). Programación COBOL estructurada (3.ª ed.). Nueva York: John Wiley & Sons. ISBN 0-471-04913-1.