Job Control Language ( JCL ) es un lenguaje de secuencias de comandos utilizado en los sistemas operativos de mainframe de IBM para indicar al sistema cómo ejecutar un trabajo por lotes o iniciar un subsistema. [1] El propósito de JCL es decir qué programas ejecutar, usar qué archivos o dispositivos [2] para entrada o salida y, en ocasiones, también indicar bajo qué condiciones omitir un paso. Los parámetros en JCL también pueden proporcionar información contable para rastrear los recursos utilizados por un trabajo, así como en qué máquina debe ejecutarse el trabajo.
Hay dos lenguajes de control de trabajos de IBM distintos:
Comparten algunas reglas de sintaxis 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.
Originalmente, los sistemas mainframe estaban orientados al procesamiento por lotes . Muchos trabajos por lotes requieren 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 que la identificación de los conjuntos de datos requeridos se especifiquen en la línea de comando y, por lo tanto, estén sujetos a sustitución por parte del shell o sean 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 su ejecución. Esto ayuda a evitar el " punto muerto ", donde el trabajo A retiene el recurso R1 y solicita el recurso R2, mientras que el trabajo B que se ejecuta simultáneamente retiene el recurso R2 y solicita R1. En tales casos, la única solución es que el operador del ordenador 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 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 los días de las bases de datos relacionales , un trabajo para producir un informe impreso para la administración podía consistir en 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, normalmente utilizando una utilidad de uso 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 su visualización en un monitor o terminal.
Tanto en DOS como en OS JCL la primera "tarjeta" debe ser la tarjeta JOB, que: [9]
Los procedimientos (comúnmente llamados procs ) son JCL preescritos para pasos o grupos de pasos, insertados en un trabajo. Ambos JCL permiten tales procedimientos. Los procesos 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 específico y lo inserta en la secuencia de trabajos. Además, los procs pueden incluir parámetros para personalizar el procedimiento para cada uso.
Tanto DOS como OS JCL 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 fue 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 ignoraron todo 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 suelen ser números de secuencia de tarjetas que el sistema imprimió en el informe de fin de trabajo y son útiles para identificar la ubicación de cualquier error informado 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 declaració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 entradas in-stream (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. Las declaraciones delimitadoras comienzan con una barra diagonal y un asterisco ( /*
), y una declaración de comentario en OS JCL comienza con un par de barras diagonales y un asterisco ( //*
) o un asterisco en DOS JCL.
Muchas sentencias JCL son demasiado largas para caber en 71 caracteres, pero se pueden ampliar a un número indefinido de tarjetas de continuación mediante:
La estructura de los tipos de tarjeta más comunes es: [11]
Tanto DOS como OS JCL permiten entradas en flujo, es decir, "tarjetas" que deben ser procesadas por el programa de aplicación en lugar del sistema operativo. Los datos que van a conservarse durante mucho tiempo normalmente se almacenan en disco, pero antes de que el uso de terminales interactivos se hiciera común, la única forma de crear y editar dichos archivos en disco era suministrando los nuevos datos en tarjetas.
DOS y OS JCL 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 después de la última tarjeta de datos en flujo. Esto hace que el sistema operativo reanude el procesamiento de JCL en la tarjeta que sigue a la /*
tarjeta. [12]
//SYSIN DD *
. Las declaraciones JCL se pueden incluir como parte de los datos en flujo mediante las declaraciones DD DATA.// SUBM EXEC PGM = IEBGENER // SYSPRINT DD SYSOUT = Z // SYSUT2 DD SYSOUT = ( A , INTRDR ) // SYSIN DD DUMMY // SYSUT1 DD DATA , DLM = ZZ // RUNLATR JOB ACCT , MANIX , CLASS = A . TYPRUN = HOLD //* ^ un TRABAJO para ejecutar más tarde // CPUHOG EXEC PGM = PICALC1K // SALIDA DD DSN = PICALC .1000 DGTS , ESPACIO = ( TRK , 1 ), DISP = (, KEEP ) ZZ //* ^ como especificado por DLM=ZZ // DROPOLDR EXEC PGM = IEFBR14 // DELETE4 DD DSN = PICALC .4 DGTS , DISP = ( ANTIGUO , BORRAR ) // DELETE5 DD DSN = PICALC .5 DGTS , DISP = ( ANTIGUO , BORRAR )
Fred Brooks , que supervisó el proyecto OS/360 en el que se creó JCL, lo llamó "el peor lenguaje de programación jamás ideado por nadie, en ningún lugar" en The Design of Design , donde lo utilizó como ejemplo en el capítulo "How Expert Los diseñadores se equivocan". [14] Atribuyó esto a que los diseñadores no se dieron cuenta de que JCL es, de hecho, un lenguaje de programación.
Gran parte de la complejidad de OS JCL, en particular, se deriva de la gran cantidad de opciones para especificar información del conjunto de datos . Mientras que los archivos en los sistemas operativos tipo Unix se abstraen en flujos ordenados 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 dichos flujos), y los detalles prácticos de los datos almacenamiento y acceso manejados en gran parte por el sistema operativo sin el conocimiento de los programas del 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 bloques, información específica del dispositivo como la densidad de la cinta magnética e información de etiquetas. Aunque existen valores predeterminados del sistema para muchas opciones, todavía queda mucho por especificar por parte del programador, mediante una combinación de JCL e información codificada en el programa. Cuanta más información esté codificada en el programa, menos flexible será, ya que la información del programa anula cualquier cosa del JCL; por tanto, la mayor parte de la información suele proporcionarse a través de JCL.
Por ejemplo, para copiar un archivo en el sistema operativo Unix , el usuario ingresaría un comando como:
cp archivo antiguo archivo nuevo
El siguiente ejemplo, utilizando JCL, podría utilizarse para copiar un archivo en OS/360:
// TRABAJO IS198CPY ( IS198T30500 ), 'COPIAR TRABAJO' , CLASE = L , MSGCLASS = X // COPY01 EXEC PGM = IEBGENER // SYSPRINT DD SYSOUT = * // SYSUT1 DD DSN = OLDFILE , DISP = SHR // SYSUT2 DD DSN = NEWFILE , // DISP = ( NUEVO , CATLG , BORRAR ), // ESPACIO = ( CYL ,( 40 , 5 ), RLSE ), // DCB = ( LRECL = 115 , BLKSIZE = 1150 ) // SYSIN DD DUMMY
Una segunda explicación para la complejidad de JCL son las diferentes expectativas para ejecutar un trabajo respecto a las que se encuentran en una PC o en un entorno tipo Unix.
DISP=(NEW,CATLG,DELETE)
significa "si el programa se ejecuta correctamente, cree un nuevo archivo y catalogúelo; de lo contrario, elimine el nuevo archivo". Los programas que se ejecutan en una PC con frecuencia dependen de que el usuario los limpie después de los problemas de procesamiento.JOB
tarjeta le dice 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 dice a la computadora que imprima el informe del programa en la impresora predeterminada que está cargada con papel normal, no en alguna otra impresora que podría estar cargada con cheques en blanco. DISP=SHR
le dice 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 ha realizado cierta simplificación para evitar obligar a los clientes a reescribir todos sus archivos JCL. [ cita necesaria ] Muchos usuarios guardan como procedimiento cualquier conjunto de declaraciones JCL que probablemente se utilizarán 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 resultado familiar para los programadores en una época en la que muchos programas se codificaban 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.
DOS JCL mitiga hasta cierto punto las dificultades de los parámetros posicionales al utilizar más declaraciones con menos parámetros que OS JCL. En el ejemplo, las declaraciones ASSGN, DLBL y EXTENT hacen el mismo trabajo (especificando dónde se debe almacenar un nuevo archivo de disco) que una sola DD
declaración en OS JCL.
En el DOS/360 original y en la mayoría de las versiones de DOS/VS uno tenía que especificar el número de modelo del dispositivo que se iba a utilizar para cada disco o archivo de cinta, incluso para archivos existentes y archivos temporales que se eliminarían en el momento. final del trabajo. Esto significaba que, si un cliente actualizaba a un equipo más moderno, debían cambiarse muchos archivos JCL.
Los miembros posteriores de la familia DOS/360 redujeron la cantidad de situaciones en las que se requerían números de modelo de dispositivo.
DOS/360 originalmente requería que el programador especificara la ubicación y el tamaño de todos los archivos en DASD . La EXTENT
tarjeta especifica el volumen en el que reside la extensión, la pista absoluta inicial y el número de pistas. Para z/VSE, un archivo puede tener hasta 256 extensiones en diferentes volúmenes.
OS JCL consta de tres tipos de declaraciones básicas: [19]
JOB
declaració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.EXEC
declaración, que identifica el programa o procedimiento [20] que se ejecutará en este paso del trabajo, DD
Declaraciones (Definición de datos), que identifican un archivo de datos que se utilizará en un paso e información detallada sobre ese archivo. DD
Las declaraciones pueden estar en cualquier orden dentro del paso.Desde el principio, JCL para la familia de sistemas operativos (hasta z/OS incluido ) fue más flexible y fácil de usar.
Los siguientes ejemplos utilizan el estilo antiguo de sintaxis que se proporcionó desde el lanzamiento de System/360 en 1964. La sintaxis antigua 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-Campo Nombre-Campo Operación-Campo Parámetro-Campo Comentarios-Campo ^ ^ ^ ^ sin espacio espacio espacio espacio
El campo de identificador debe estar concatenado con el campo de nombre , es decir, no debe haber espacios entre ellos.
//
): el campo de identificador indica al sistema que una declaración es una declaración JCL en lugar de datos. El campo de identificador consta de lo siguiente://
/*
//*
$
, #
, @
).JOB
, EXEC
y DD
.// NEWFILE 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 declaraciones JCL del sistema operativo 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.
El parámetro posicional debe 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 DD
declaración se utiliza para hacer referencia a datos. Esta declaración vincula la descripción interna de un programa de un conjunto de datos con los datos de dispositivos externos: discos, cintas, tarjetas, impresoras, etc. El DD puede proporcionar información como el 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, denominado DCB
subpará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 para un archivo existente almacenado en cinta o disco y la macro DCB codificada en el programa. Cuando se abre el archivo, estos datos se combinan, teniendo la información DD prioridad sobre la información de la etiqueta y la información DCB teniendo prioridad sobre ambas. Luego, la descripción actualizada se vuelve a escribir en la etiqueta del conjunto de datos. Esto puede tener consecuencias no deseadas si se proporciona información DCB incorrecta. [23]
Debido a los parámetros enumerados anteriormente y a la información específica para varios métodos y dispositivos de acceso, la declaración DD es la declaración JCL más compleja. En un manual de referencia de IBM, la descripción de la declaración DD ocupa más de 130 páginas, más del doble que las declaraciones JOB y EXEC combinadas. [24]
La declaración DD permite inyectar datos en línea en la secuencia de trabajos. Esto es útil para proporcionar información de control a utilidades como IDCAMS, SORT, etc., así como para proporcionar datos de entrada a los programas.
Desde el principio, el JCL para la familia de sistemas operativos OS ofreció un alto grado de independencia del dispositivo. Incluso para los archivos nuevos que debían conservarse una vez finalizado 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 fuera importante, se podrí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 declaraciones " EXEC PGM= " y DD y luego invocarlas con " EXEC PROC= procname" -o- simplemente "EXEC procname" [26]
Una instalación llamada Biblioteca de Procedimientos permitía el almacenamiento previo de los procedimientos.
Los procedimientos también se pueden incluir en la secuencia de trabajos finalizando el procedimiento con una // PEND
declaración y luego invocándolo por su nombre, como si estuviera en una biblioteca de procedimientos.
Por ejemplo:
// PROC RESUMEN // IMPRIMIR EXEC PGM=IEBGENER // SYSUT1 DD DSN = CEO . ARCHIVOS . FIN DEL DÍA . RPT24A , DISP = SHR // SYSUT2 DD SYSOUT = A // SYSIN DD DUMMY // PEND // RESUMEN EJECUTIVO
Los procedimientos JCL del sistema operativo se parametrizaron 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 = ( NUEVO , CATLG , BORRAR ) ....
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 único procedimiento de este ejemplo para crear nuevos archivos de muchos tamaños y diseños diferentes. Por ejemplo:
// TRABAJO01 TRABAJO .......... // PASO01 EXEC MYPROC FNAME=JOESFILE,SPTYPE=CYL,SPINIT=10,SPEXT=2,LR=100,BLK=2000 o // TRABAJO02 TRABAJO ... ....... // PASO01 EXEC MYPROC 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 en su totalidad un archivo que ya se ha especificado en un paso anterior. Por ejemplo:
// MYPROC ................ // MYPR01 EXEC PGM = .......... // NUEVO ARCHIVO DD DSN =& MYFILE , UNIDAD = DISCO , ESPACIO = ( TRK , 50 , 10 ), // DCB = ( LRECL = 100 , BLKSIZE = 1000 ), DISP = ( NUEVO , CATLG , BORRAR ) .... // MYPR02 EXEC PGM = ......... // ENTRADA01 DD DSN = * . MYPR01 . NUEVO ARCHIVO
Aquí, MYPR02
se utiliza el archivo identificado NEWFILE
en el paso MYPR01
( DSN
significa "nombre del conjunto de datos" y especifica el nombre del archivo; un DSN no puede exceder 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 Usando un procedimiento // STEP02 EXEC PGM = ......... Paso específico de este trabajo // INPUT01 DD DSN = * . PASO01 . MYPR01 . NUEVO ARCHIVO
donde DSN=*.STEP01.MYPR01.NEWFILE
significa "utilizar el archivo identificado como NEWFILE
en el paso MYPR01
del procedimiento utilizado en el paso STEP01
de este trabajo". Usar el nombre del paso que llamó al procedimiento en lugar del nombre del procedimiento permite a un programador usar el mismo procedimiento varias veces en el mismo trabajo sin confusión sobre qué instancia del procedimiento se usa en la referencia.
Los archivos JCL pueden ser largos y complejos y el lenguaje no es fácil de leer. OS JCL permite a los programadores incluir dos tipos de comentarios explicativos:
X
") en la columna 72, seguido de " //
" en las columnas 1 a 3 de la línea siguiente.// MYJOB JOB .......... //* Líneas que contienen solo comentarios. //******** A menudo se usa 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 ampliado y X // se desborda en otra línea. // ENTRADA01 DD DSN = PASO01 . MYPR01 . NUEVO ARCHIVO
OS JCL permite a los programadores concatenar ("encadenar") archivos de entrada para que aparezcan en el programa como un solo archivo, por ejemplo
// INPUT01 DD DSN = MYFILE01 , DISP = SHR // DD DSN=JOESFILE,DISP=SHR // DD DSN=SUESFILE,DISP=SHR
La segunda y tercera declaraciones no tienen valor en el campo de nombre, por lo que el sistema operativo las trata como concatenaciones. Los archivos deben ser del mismo tipo básico (casi siempre secuenciales) y deben tener la misma longitud de registro; sin embargo, 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 en, 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 ser 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 encontrada.
Una alternativa habitual era simplemente determinar la longitud máxima de bloque posible en el dispositivo y especificarla en la declaración DD nombrada, como en, 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 ser igual o menor que 8000)
El propósito de este respaldo era garantizar que el método de acceso asignara un conjunto de búfer de entrada que fuera lo suficientemente grande como 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 qué tan exitoso pensó que fue el programa . Los valores convencionales más comunes son: [29] : p.87
OS JCL se refiere al código de retorno como COND
("código de condición") y puede usarlo para decidir si se ejecutan los pasos siguientes. Sin embargo, a diferencia de la mayoría de los lenguajes de programación modernos, los pasos condicionales en OS JCL no se ejecutan si la condición especificada es verdadera, lo que da lugar al mnemotécnico "Si es verdadero, continúe [sin ejecutar el código]". Para complicar aún más las cosas, la condición sólo puede especificarse después del paso al que se refiere. Por ejemplo:
// MITRABAJO TRABAJO ........... // PASO01 PGM EXEC = PROG01 .... // PASO02 PGM EXEC = PROG02 , COND = ( 4 , GT , PASO01 ) .... // PASO03 PGM EXEC = PROG03 , COND = ( 8 , LE ) .... // PASO04 PGM EXEC = PROG04 , COND = ( SÓLO , PASO01 ) .... // PASO05 PGM EXEC = PROG05 , COND = ( PAR , PASO03 ) ....
medio:
STEP01
y recopile su código de retorno.STEP02
si el número 4 es mayor que STEP01
el código de retorno.STEP03
si el número 8 es menor o igual que cualquier código de retorno anterior.STEP04
solo si STEP01
finalizó de manera anormal.STEP05
, incluso si STEP03
finalizó de forma anormal.Esto se traduce en el siguiente pseudocódigo :
ejecute STEP01 si el código de retorno de STEP01 es mayor o igual a 4 , entonces ejecutar STEP02finalizar si algún código de retorno anterior es menor que 8 , entonces ejecutar STEP03finalizar si STEP01 finalizó anormalmente entonces ejecutar STEP04finalizar si STEP03 finalizó anormalmente entonces ejecutar STEP05demás ejecutar STEP05terminar si
Tenga en cuenta que al leer los pasos que contienen COND
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 facilitó un poco la codificación para los programadores y al mismo tiempo retuvo el COND
parámetro (para evitar realizar cambios en los JCL existentes donde COND parm
se utiliza).
El COND
parámetro también se puede especificar en la JOB
declaración. Si es así, el sistema "realiza las mismas pruebas de código de retorno para cada paso de un trabajo. Si se cumple una prueba de código de retorno de una instrucción JOB, el trabajo finaliza". [30]
Jobs utiliza varios programas de utilidad 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 conjuntos:
OS JCL 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 de Job Control Language?" [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 JCL era horrible, y sólo los tipos de computadoras 'incondicionales' alguna vez lo entendieron" y entregaron la tarea de descifrar las declaraciones JCL a otra persona. [34] Esta actitud se podía encontrar en los libros de texto sobre 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 posibles mensajes de error del compilador WATFOR : "¿Ha sido tan tonto como para intentar escribir sus propias tarjetas de control del sistema 'DD'? Cese y desista inmediatamente; corra, no camine, en busca de ayuda. " [35]
Sin embargo, algunos libros que abordan JCL en detalle enfatizan que una vez que se aprende al menos hasta cierto punto competente, uno se libera de los valores predeterminados en toda la instalación y tiene un control mucho mejor sobre cómo un sistema IBM procesa su carga de trabajo. [34] [31] Otro libro comentó sobre la complejidad, pero dijo: "anímate. La capacidad JCL que obtendrás [del capítulo anterior] es todo lo que la mayoría de los programadores necesitarán". [31]
En los sistemas mainframe IBM, el lenguaje de control de entrada de trabajos o JECL es el conjunto de declaraciones de control del lenguaje de comandos que proporcionan información para el subsistema de cola : JES2 o JES3 en z/OS o VSE/POWER para z/VSE . Las declaraciones JECL pueden "especificar en qué computadora de la red ejecutar el trabajo , cuándo ejecutar el trabajo y dónde enviar el resultado resultante". [29]
JECL es distinto del lenguaje de control de trabajos (JCL), que indica al sistema operativo cómo ejecutar el trabajo.
Existen diferentes versiones de JECL para los tres entornos.
Una versión anterior del lenguaje de control de entrada de trabajos para la entrada remota de trabajos 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 trabajos). "Comandos de estación de trabajo", como LOGON
, LOGOFF
y STATUS
tambié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.
Para JES2, las declaraciones JECL comienzan con /*
, para JES3 comienzan con //*
, excepto para los comandos remotos /*SIGNON
y /*SIGNOFF
. Los comandos para los dos sistemas son completamente diferentes.
Las siguientes sentencias JES2 JECL se utilizan en z/OS 1.2.0. [37]
Las siguientes sentencias JES3 JECL se utilizan en z/OS 1.2.0 [39]
Para VSE JECL, las declaraciones comienzan con " * $$
" (tenga en cuenta el espacio simple ). El lenguaje de control de entrada de trabajos define las líneas de inicio y finalización de los trabajos JCL. Informa a VSE / POWER cómo se maneja este trabajo. Las declaraciones 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 mainframe por lotes 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.
DD
Los nombres de los conjuntos de datos no deben exceder los 44 caracteres, incluidos todos los segmentos y períodos de nombres.
JCL en particular es notoriamente hostil al usuario y Fred Brooks lo ha llamado "el peor lenguaje de programación jamás diseñado"... (http://dtsc.dfw.ibm.com/MVSDS/'HTTPD2.APPS.ZOSCLASS.PDF(ZCLA ...)[enlace en original].