Idioma de control de trabajo

Lenguaje de control de trabajos (JCL) es un nombre para los lenguajes de secuencias de comandos utilizados en los sistemas operativos de mainframe de IBM para indicar al sistema cómo ejecutar un trabajo por lotes o iniciar un subsistema.. El propósito de JCL es decir qué programas ejecutar, usar qué archivos o dispositivos 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.

Existen dos lenguajes distintos de IBM Job Control:

• una para la línea de sistema operativo que comienza con DOS/360 y cuyo último miembro es z/VSE; y
• the other for the lineage from OS/360 to z/OS, the latter now including JES extensions, Job Entry Control Language (JECL).

Comparten algunas reglas de sintaxis básicas y algunos conceptos básicos, pero por lo demás son muy diferentes.

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

Terminología

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

• Dataset: un "dataset" es un archivo; puede ser temporal o permanente, y se encuentra en una unidad de disco, almacenamiento de cinta u otro dispositivo.
• Miembro: un "miembro" de un conjunto de datos dividido (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 de miembro entre paréntesis. Por ejemplo, el sistema macro GETMAIN en SYS1. MACLIB puede ser referenciado como SYS1. MACLIB(GETMAIN).
• Dataset partitioned: a "partitioned dataset" or PDS is collection of members, or archive. Los conjuntos de datos parciales 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 tal, tienen algo en común con archivos de archivo (ZIP, TAR, etc) y con directorios en otros sistemas operativos. También se utilizan para almacenar código binario (cargar módulos o objetos del programa); en ese modo, son aproximadamente análogos a las bibliotecas estáticas basadas en ar en sistemas basados en Unix. Como en la mayoría de estas estructuras, un miembro, una vez almacenado, no puede ser actualizado; el miembro debe ser eliminado y reemplazado, como por la utilidad IEBUPDTE. Desde la publicación de MVS DFP 3.2 en 1989, PDSEs (Conjunto de datos ampliado) ha existido como una versión mejorada de PDS; desde el punto de vista del usuario o del programador de aplicaciones, son en gran medida inalterados (salvo la eliminación de algunas características heredadas oscuras), pero su aplicación interna es muy diferente.
• USS: Unix system services, a Unix subsystem running as part of MVS, and allowing Unix files, scripts, tasks, and programs to run on a mainframe in a UNIX environment.

Motivación

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. 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 un "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.

Características comunes a DOS y OS JCL

Trabajos, pasos y procedimientos

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.

In both DOS and OS JCL the first n#34;card" must be the JOB card, which:

• Identifica el trabajo.
• Generalmente proporciona información para que el departamento de servicios informáticos pueda facturar el departamento de usuario apropiado.
• Define cómo se va a ejecutar el trabajo en su conjunto, por ejemplo, su prioridad relativa a 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 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 procesos pueden incluir parámetros para personalizar el procedimiento para cada uso.

Sintaxis básica

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. 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 de entrada in-stream (ver más abajo) deben comenzar con una barra diagonal "/", y todas las líneas que procesa el sistema operativo deben comenzar con dos barras diagonales //, 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 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:

Entrada in-stream

Tanto DOS como OS JCL permiten entradas in-stream, es decir, "tarjetas" que deben ser procesados por el programa de aplicación en lugar del sistema operativo. Los datos que deben 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 con /* en la columna 1 de la tarjeta después de los últimos datos en flujo tarjeta. Esto hace que el sistema operativo reanude el procesamiento de JCL en la tarjeta que sigue a la tarjeta /*.

• OS JCL: Las declaraciones DD se pueden utilizar para describir los datos de corriente, así como conjuntos de datos. A DD statement dealing with in-stream data has an asterisk (*) following the DD identifier, e.g. //SYSIN DD *. Las declaraciones de JCL pueden incluirse como parte de los datos in-stream utilizando las declaraciones DD DATA.

Un operario llamado DLM permitido especificar un delimitador (default es "/*"). Especificar un delimitador alternativo permite que JCL sea leído como datos, por ejemplo para copiar procedimientos a un miembro de la biblioteca o para enviar un trabajo al lector interno.

• Un ejemplo, que presenta un trabajo al Lector interno ()INTRDR) y luego borra dos archivos es:

//SUBM EXEC PGM=IEBGENER//SYSPRINT DD SYSOUT=Z//SYSUT2 DD SYSOUT=()A,INTRDR)//SYSIN DD DUMMY//SYSUT1 DD DATOS,DLM=ZZ//RUNLATR JOB ACCT,MANIX,CLASE=A.TYPRUN=HOLD//* ^ a JOB to run later//CPUHOG EXEC PGM=PICALC1K//OUTPUT DD DSN=PICALC.1000DGTS,SPACE=()TRK,1),DISP=(KEEP)ZZ//* ^ especificado por DLM=Z//DROPOLDR EXEC PGM=IEFBR14//DELETE4 DD DSN=PICALC.4DGTS,DISP=()OLD,DELETE)//DELETE5 DD DSN=PICALC.5DGTS,DISP=()OLD,DELETE)

1. El programa llamado PICALC1K espera (TYPRUN=HOLD) que se publique manualmente
2. El programa llamado IEFBR14 funcionará AHORA y una vez terminado, se eliminarán los dos archivos existentes, PICALC.4DGTS y PICALC.5DGTS.

• DOS JCL: Simplemente introduzca los datos de entrada después de la tarjeta EXEC para el programa.

Complejidad

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 oldFile newFile

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

//IS198CPY JOB ()IS198T30500),'COPY JOB ',CLASE=L,MSGCLASS=X//COPY01 EXEC PGM=IEBGENER//SYSPRINT DD SYSOUT=*//SYSUT1 DD DSN=OLDFILE,DISP=SHR//SYSUT2 DD DSN=NEWFILE,// DISP=()NOTICIAS,CATLG,DELETE),// SPACE=()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.

• Sistema de bajo nivel/360 Las CPU eran menos potentes y más costosas que los PC de mediados de los años 80 para los cuales se diseñó MS-DOS. OS/360 estaba destinado a sistemas con un tamaño mínimo de memoria de 32 KB y DOS/360 para sistemas con un mínimo de 16 KB. Una CPU 360/30 —bajo final cuando System/360 fue anunciado en 1964— procesó 1.8K a 34.5K instrucciones por segundo. El primer PC IBM en 1981 tenía 16 KB o 64 KB de memoria y procesaría alrededor de 330K instrucciones por segundo. Como resultado, JCL tenía que ser fácil para el ordenador el proceso y la facilidad de uso de los programadores era una prioridad mucho menor. En esta era, los programadores eran mucho más baratos que los ordenadores.
• JCL fue diseñado para el procesamiento por lotes. Como tal, tiene que contar al sistema operativo todo, incluyendo qué hacer dependiendo del resultado de un paso. Por ejemplo, DISP=(NEW,CATLG,DELETE) significa "si el programa funciona correctamente, crear un nuevo archivo y catalogarlo; de otro modo eliminar el nuevo archivo". Los programas que se ejecutan en un PC dependen con frecuencia del usuario para limpiar después de problemas de procesamiento.
• Las máquinas System/360 fueron diseñadas para ser compartidas por todos los usuarios de una organización. Así que... 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 otras cosas. //SYSPRINT DD SYSOUT=* le dice a la computadora que imprima el informe del programa en la impresora predeterminada que está cargada con papel ordinario, no en otra impresora que puede ser 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 han realizado algunas simplificaciones para evitar obligar a los clientes a reescribir todos sus archivos JCL. Muchos usuarios guardan como procedimiento cualquier conjunto de declaraciones JCL que probablemente se utilizarán más de una o dos veces.

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.

DOS JCL

Parámetros posicionales

//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é tema va en que posición en cada tipo de declaración.
• Si se omiten algunos parámetros opcionales pero se incluyen los siguientes, los parámetros omitidos deben estar representados por comas sin espacios, como en la declaración TLBL anterior.

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 única declaración DD en OS JCL.

Dependencia del dispositivo

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 usar para cada disco o archivo de cinta, incluso para archivos existentes y para archivos temporales que serían eliminado al 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 el número de situaciones en las que se requerían números de modelo de dispositivo.

Asignación manual de archivos

DOS/360 originalmente requería que el programador especificara la ubicación y el tamaño de todos los archivos en DASD. La tarjeta EXTENT 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.

SO JCL

OS JCL consta de tres tipos de declaraciones básicas:

• JOB declaración, que identifica el comienzo del trabajo, e información sobre todo el trabajo, como facturación, ejecución de prioridades, y plazos y límites espaciales.
• EXEC declaración, que identifica el programa o procedimiento para ser ejecutado en este paso del trabajo,
  e información sobre el paso, incluyendo CONDpica para correr o saltar un paso.
• DD (Definición de datos) declaraciones, 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.

Reglas para codificar declaraciones JCL

Cada declaración JCL se divide en cinco campos:

 Identificador-Field Nombre-Field Operación-Field Parameter-Field Comentarios-Field
^ ^ ^ ^
no espacio espacial

Identifier-Field debe estar concatenado con Name-Field, es decir, no debe haber espacios entre ellos.

• Identificador-Field ()//): El campo identificador indica al sistema que una declaración es una declaración JCL en lugar de datos. El campo identificador consiste en lo siguiente:
  • Las columnas 1 y 2 de todas las declaraciones de la JCL, excepto la declaración de delimitador, contienen //
  • Las columnas 1 y 2 de la declaración del delimitador contienen /*
  • Columnas 1, 2, y 3 de un comentario de JCL contienen //*
• Name-Field: El campo de nombres identifica una declaración particular para que otras declaraciones y el sistema puedan referirse a ella. En el caso de las declaraciones de la JCL, debe codificarse como sigue:
  • El nombre debe comenzar en la columna 3.
  • El nombre es 1 a 8 alfanuméricos o nacionales ($, #, @) caracteres.
  • El primer personaje debe ser alfabético.
  • El nombre debe ser seguido por al menos un blanco.
• Operación-Field: El campo de operación especifica el tipo de declaración, o, para la declaración de comando, el comando. Operación-Field debe ser codificado como sigue:
  • El campo de operación consiste en los caracteres en la caja de sintaxis para la declaración.
  • La operación sigue el campo de nombres.
  • La operación debe ser precedida y seguida por al menos un blanco.
  • La operación será una de las JOB, EXEC y DD.
• Parameter-Field: El campo del parámetro, también a veces referido como el campo operativo, contiene parámetros separados por comas. El campo del parámetro debe ser codificado como sigue:
  • El campo del parámetro sigue el campo de operación.
  • El campo del parámetro debe ser precedido por al menos una en blanco.
  • El campo del 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 conjunto de datos.
• Comentarios-Field: Esto contiene comentarios. Comentarios-Field debe ser codificado como sigue:
  • El campo de comentarios sigue el campo del parámetro.
  • El campo de comentarios debe ser precedido por al menos un espacio en blanco.

Parámetros de palabras clave

//NEWFILE DD DSN=MYFILE01,UNIT=DISK,SPACE=()TRK,80,10),// DCB=()LRECL=100,BLKSIZE=1000),// DISP=()NOTICIAS,CATLG,DELETE)

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 de un archivo). 39;s diseño) 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 (=).

Acceso a datos (declaración DD)

La declaración DD 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.

Debido a los parámetros enumerados anteriormente y 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.

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.

Independencia del dispositivo

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 se van a conservar después del final del trabajo, se puede 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.

Procedimientos

procedimientos permiten agrupar uno o más "EXEC PGM=" y declaraciones DD y luego invocarlas con "EXEC PROC=procname" -o- simplemente "EXEC procname"

Una instalación llamada Biblioteca de procedimientos permitía el almacenamiento previo de los procedimientos.

PROC and; PEND

Los procedimientos también se pueden incluir en la secuencia de trabajos finalizando el procedimiento con una instrucción //PEND y luego invocándolo por su nombre, de la misma manera que si estuviera en una biblioteca de procedimientos.

Por ejemplo:

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

Procedimientos parametrizados

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.

//MYPROC PROC FNAME=MYFILE01,SPTYPE=TRK,SPINIT=50,SPEXT=10,LR=100,BLK=1000...//NEWFILE DD DSN=FNAME,UNIT=DISK,SPACE=()"SPTYPE,"SPINIT,"SPEXT),// DCB=()LRECL=LR,BLKSIZE=BLK),DISP=()NOTICIAS,CATLG,DELETE)...

En este ejemplo, todos los valores que comienzan con ampersand "&" 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:

//JOB01 JOB ...//STEP01 EXEC MYPROC FNAME=JOESFILE,SPTYPE=CYL,SPINIT=10,SPEXT=2,LR=100,BLK=2000o//JOB02 JOB ...//STEP01 EXEC MYPROC FNAME=SUESFILE,SPTYPE=TRK,SPINIT=500,SPEXT=100,LR=100,BLK=5000

Referencias

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=...//NEWFILE DD DSN=MYFILE,UNIT=DISK,SPACE=()TRK,50,10),// DCB=()LRECL=100,BLKSIZE=1000),DISP=()NOTICIAS,CATLG,DELETE)...//MYPR02 EXEC PGM=...//INPUT01 DD DSN=*.MYPR01.NEWFILE

Aquí, MYPR02 utiliza el archivo identificado como 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).

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 Uso de un procedimiento//STEP02 EXEC PGM=... Paso que es específico para este trabajo//INPUT01 DD DSN=*.STEP01.MYPR01.NEWFILE

donde DSN=*.STEP01.MYPR01.NEWFILE significa "use 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.

Comentarios

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:

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

//MYJOB JOB ...//* Líneas que contienen sólo comentarios.*********** A menudo se utiliza para dividir el listado JCL en secciones *****//STEP01 EXEC MYPROC Observación 2 sobre la misma línea que declaración//STEP02 EXEC PGM=... Se ha ampliado el comentario 3 y X// desbordamiento en otra línea.//INPUT01 DD DSN=STEP01.MYPR01.NEWFILE

Concatenar archivos de entrada

OS JCL permite a los programadores concatenar ("encadenar") archivos de entrada para que aparezcan en el programa como un 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 (BLKSIZE asumió ser igual o inferior a 800)// DD DSN=SUESFILE,DISP=SHR (BLKSIZE asumió ser igual o inferior a 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 el máximo longitud del bloque que se encontró.

Un recurso habitual era simplemente determinar la longitud máxima de bloque posible en el dispositivo y especificarla en la instrucción DD nombrada, como en, por ejemplo,

//INPUT01 DD DSN=MYFILE01,DISP=SHR,BLKSIZE=8000// DD DSN=JOESFILE,DISP=SHR (BLKSIZE asumió ser igual o inferior a 8000)// DD DSN=SUESFILE,DISP=SHR (BLKSIZE asumió ser igual o inferior a 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.

Procesamiento condicional

El sistema operativo espera que los programas establezcan un código de retorno que especifica qué tan exitoso pensó que fue el programa. Los valores convencionales más comunes son:

• 0 = Normal - todo bien
• 4 = Advertencia - errores o problemas menores
• 8 = Error - errores o problemas importantes
• 12 = Error grave - errores importantes o problemas, los resultados (por ejemplo, archivos o informes producidos) no deben ser confiables.
• 16 = Error terminal - problemas muy graves, no use los resultados!

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, pasa". adelante [sin ejecutar el código]." Para complicar aún más las cosas, la condición sólo se puede especificar después del paso al que se refiere. Por ejemplo:

//MYJOB JOB ...//STEP01 EXEC PGM=PROG01...//STEP02 EXEC PGM=PROG02,COND=()4,GT,STEP01)...//STEP03 EXEC PGM=PROG03,COND=()8,LE)...//STEP04 EXEC PGM=PROG04,COND=()ONLY,STEP01)...//STEP05 EXEC PGM=PROG05,COND=()EVENTO,STEP03)...

significa:

1. Corre STEP01, y recoger su código de devolución.
2. No corras STEP02 si el número 4 es mayor que STEP01Es código de devolución.
3. No corras STEP03 si el número 8 es inferior o igual a cualquier código de devolución anterior.
4. Corre STEP04 sólo si STEP01 Anormalmente terminó.
5. Corre STEP05, incluso si STEP03 Anormalmente terminó.

Esto se traduce en el siguiente pseudocódigo:

STEP01
si Código de devolución de STEP01 es mayor o igual a  4 entoncesSTEP02
terminar sisi cualquier código de devolución anterior es menos que  8 entoncesSTEP03
terminar sisi STEP01 anormalmente terminado entoncesSTEP04
terminar sisi STEP03 anormalmente terminado entoncesSTEP05
másSTEP05
terminar si

Tenga en cuenta que al leer los pasos que contienen declaraciones COND al revés, se pueden entender con bastante facilidad. Este es un ejemplo de transposición lógica. Sin embargo, IBM introdujo posteriormente la condición IF en JCL, lo que facilitó un poco la codificación a los programadores y al mismo tiempo retuvo el parámetro COND (para evitar realizar cambios en los JCL existentes donde COND parm).

El parámetro COND también se puede especificar en la declaración JOB. Si es así, el sistema "realiza las mismas pruebas de código de retorno para cada paso de un trabajo". Si se cumple la prueba del código de retorno de una declaración JOB, el trabajo finaliza."

Utilidades

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:

• Data Set Utilities - Crear, imprimir, copiar, mover y eliminar conjuntos de datos.
• Usos del sistema - Mantener y gestionar catálogos y otra información del sistema.
• Access Method Services - Process Virtual Storage Access Method (VSAM) y conjuntos de datos no VSAM.

Dificultad de uso

OS JCL es innegablemente complejo y ha sido descrito como "hostil al usuario". Como preguntaba un libro instructivo sobre JCL: "¿Por qué incluso los programadores sofisticados dudan cuando se trata de Job Control Language?" 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 eran "incondicionales"; los informáticos alguna vez lo entendieron" y le entregó la tarea de descubrir las declaraciones JCL a otra persona. Esta actitud se puede encontrar en los libros de texto sobre lenguajes de programación, que prefieren centrarse en el lenguaje en sí y no en cómo se ejecutan los programas en él. Como decía un libro de texto de Fortran IV al enumerar posibles mensajes de error del compilador WATFOR: "¿Has sido tan tonto como para intentar escribir tu propio 'DD&#39? tarjetas de control del sistema? Cese y desista inmediatamente; corre, no camines, pide ayuda."

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. Otro libro comentó sobre la complejidad pero dijo: "anímate". La capacidad JCL que obtendrá [del capítulo anterior] es todo lo que la mayoría de los programadores necesitarán."

Idioma de control de entrada de trabajo

En sistemas mainframe IBM, 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 ejecutarlo y dónde enviar el resultado resultante".

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.

OS/360

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 de una única declaración de control: JED (Definición de entrada de trabajo). "Comandos de la estación de trabajo" como LOGON, LOGOFF y STATUS también comenzaban con ...

Pre-JES JECL

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 /*.

Z/OS

Para JES2, las declaraciones JECL comienzan con /*, para JES3 comienzan con //*, excepto para las remotas /*SIGNON y /*SIGNOFF comandos. Los comandos para los dos sistemas son completamente diferentes.

JES2 JECL

Las siguientes sentencias JES2 JECL se utilizan en z/OS 1.2.0.

JES3 JECL

Las siguientes sentencias JES3 JECL se utilizan en z/OS 1.2.0

Z/VSE

Para las declaraciones VSE JECL, comience con '* $$' (tenga en cuenta el espacio único). 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 (utilizado 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:

* $$ JOB JNM=NAME,DISP=K,CLASS=2[Algunas declaraciones de JCL aquí]* $$ EOJ

Otros sistemas

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. Sistemas interactivos incluir "lenguajes de comando": los archivos de comando (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.