Job Control Language ( JCL ) es un nombre para los lenguajes de secuencias de comandos que se utilizan en los sistemas operativos de mainframe de IBM para instruir al sistema sobre cómo ejecutar un trabajo por lotes o iniciar un subsistema. [1]
Más específicamente, 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.
Hay dos lenguajes de IBM Job Control 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 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 .
Terminología
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, almacenamiento en cinta 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, se puede hacer referencia a la macro del sistema GETMAIN en SYS1.MACLIB como SYS1.MACLIB (GETMAIN). [6]
- Conjunto de datos particionado: un "conjunto de datos particionado" o PDS es una colección de miembros, o archivo, que normalmente se utiliza para representar bibliotecas del sistema. Como ocurre con la mayoría de estas estructuras, un miembro, una vez almacenado, no se puede actualizar; el miembro debe ser eliminado y reemplazado, como con la utilidad IEBUPDTE . [6] Los conjuntos de datos particionados son aproximadamente análogos a las bibliotecas estáticas basadas en ar en los sistemas basados en Unix.
- USS: Servicios del sistema Unix, un subsistema Unix que se ejecuta como parte de MVS y que permite que los archivos, scripts, tareas y programas de Unix se ejecuten en un mainframe en un entorno UNIX.
Motivación
Originalmente, los sistemas de 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. [7] JCL se desarrolló como un medio para garantizar que todos los recursos necesarios estén disponibles antes de que se programe 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 comandos y, por lo tanto, estén sujetos a sustitución por el shell o 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 un " punto muerto ", en el que el trabajo A contiene el recurso R1 y solicita el recurso R2, mientras que el trabajo B en ejecución simultánea contiene el recurso R2 y solicita el R1. En tales casos, la única solución es que el operador de la computadora termine 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 podría consistir en los siguientes pasos: un programa escrito por el usuario para seleccionar los registros apropiados y copiarlos a un archivo temporal; clasifique el archivo temporal en el orden requerido, generalmente usando 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 incluye 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: [8]
- Identifica el trabajo.
- Por lo general, proporciona información que permite al departamento de servicios informáticos facturar al departamento de usuarios 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 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 el flujo de trabajo. Además, los procs 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 DOS / 360 y OS / 360 se utilizaron por primera vez, el método principal para proporcionar nueva entrada a un sistema informático eran tarjetas perforadas de 80 columnas . [9] 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 ignoraron todo después del carácter 80.
Estrictamente hablando, ambas familias de sistemas operativos utilizan solo 71 caracteres por línea. Los caracteres 73-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 las ubicaciones de cualquier error informado por el sistema operativo. El carácter 72 generalmente 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 archivo USS .
Todas las líneas, excepto la entrada in-stream (ver más abajo) deben comenzar con una barra " /
", y todas las líneas que el sistema operativo procesa deben comenzar con dos barras //
, siempre comenzando en la primera columna . Sin embargo, hay dos excepciones: la declaración delimitador y la declaración de comentario. Una declaración delimitador comienza con una barra y un asterisco ( /*
), y una declaración de comentario en OS JCL comienza con un par de barras inclinadas y un asterisco ( //*
) o un asterisco en DOS JCL.
Muchas declaraciones JCL son demasiado largas para caber en 71 caracteres, pero se pueden extender a un número indefinido de tarjetas de continuación de la siguiente manera:
OS JCL | DOS JCL |
---|---|
Finalizar todas las tarjetas JCL reales excepto la última en un punto donde la sintaxis requiere una coma ( , ) | Finalizar todas las tarjetas JCL reales, excepto la última, en un punto donde la sintaxis requiere una coma ( , ) y un carácter que no esté en blanco en la columna 72 |
Comenzando cada tarjeta de continuación con // en la columna 1 y luego al menos 1 espacio | Comenzando cada tarjeta de continuación con espacios y continuando en la columna 15 |
La estructura de los tipos de tarjeta más comunes es: [10]
OS JCL | DOS JCL |
---|---|
|
|
Entrada in-stream
Tanto DOS como OS JCL permiten la entrada in-stream, es decir, "tarjetas" que deben ser procesadas por el programa de aplicación en lugar del sistema operativo. Los datos que se conservarán durante mucho tiempo normalmente se almacenarán en el disco, pero antes de que el uso de terminales interactivos se volviera común, la única forma de crear y editar dichos archivos de disco era proporcionando los nuevos datos en tarjetas.
DOS y OS JCL tienen diferentes formas de señalar el inicio de la entrada en flujo, pero ambos terminan la entrada en flujo /*
en la columna 1 de la tarjeta que sigue a 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. [11]
- OS JCL: Las sentencias DD se pueden utilizar para describir datos in-stream, así como conjuntos de datos. Una declaración DD que trata con datos in-stream tiene un asterisco (*) después del identificador DD, p
//SYSIN DD *
. Ej . Las sentencias JCL se pueden incluir como parte de los datos en secuencia mediante las sentencias DD DATA.
- Un operando llamado DLM permitía especificar un delimitador (el valor predeterminado es "/ *"). La especificación de un delimitador alternativo permite que JCL se lea como datos, por ejemplo, para copiar procedimientos a un miembro de la biblioteca o enviar un trabajo al lector interno .
- Un ejemplo, [12] que envía un trabajo al lector interno ( INTRDR ) es:
// 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 , SPACE = ( TRK , 1 ), DISP = (, KEEP ) ZZ // * ^ según lo especificado por DLM = ZZ// DROPOLDR EXEC PGM = IEFBR14 // BORRAR4 DD DSN = PICALC .4 DGTS , DISP = ( ANTIGUO , BORRAR )// BORRARE5 DD DSN = PICALC .5 DGTS , DISP = ( ANTIGUO , BORRAR )
- El programa llamado PICALC1K esperará (TYPRUN = HOLD) ser liberado manualmente
- AHORA se eliminarán dos archivos, PICALC.4DGTS y PICALC.5DGTS.
- DOS JCL: simplemente ingrese los datos in-stream 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 la información del conjunto de datos. Mientras que los archivos en sistemas operativos similares a Unix se resumen en colecciones arbitrarias de bytes, con los detalles manejados en gran parte por el sistema operativo, 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, el programador aún tiene mucho que especificar, mediante una combinación de JCL e información codificada en el programa. Cuanta más información codificada en el programa, menos flexible es, ya que la información en el programa anula cualquier cosa en el JCL; por lo tanto, la mayor parte de la información se proporciona normalmente 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, se puede utilizar para copiar un archivo en OS / 360:
// IS198CPY JOB ( IS198T30500 ), 'COPY JOB' , CLASS = L , MSGCLASS = X // COPY01 EXEC PGM = IEBGENER // SYSPRINT DD SYSOUT = *// SYSUT1 DD DSN = OLDFILE , DISP = SHR // SYSUT2 DD DSN = NEWFILE , // DISP = ( NEW , CATLG , DELETE ), // SPACE = ( CYL , ( 40 , 5 ), RLSE ), // DCB = ( LRECL = 115 , BLKSIZE = 1,150 ) // SYSIN DD DUMMY
Una segunda explicación de la complejidad de JCL son las diferentes expectativas para ejecutar un trabajo de las que se encuentran en una PC o en un entorno similar a Unix.
- Las CPUs 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 se diseñó para sistemas con un tamaño de memoria mínimo de 32 KB y DOS / 360 para sistemas con un mínimo de 16 KB. Una CPU 360/30 , de gama baja cuando se anunció System / 360 en 1964, procesaba de 1.8K a 34.5K instrucciones por segundo. [13] La primera PC IBM en 1981 tenía 16 KB o 64 KB de memoria y procesaba alrededor de 330K instrucciones por segundo. [14] [15] 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 procesamiento por lotes . Como tal, tiene que decirle todo al sistema operativo, incluido qué hacer en función del resultado de un paso. Por ejemplo,
DISP=(NEW,CATLG,DELETE)
significa "si el programa se ejecuta correctamente, cree un nuevo archivo y catalogue; de lo contrario, elimine el nuevo archivo". Los programas que se ejecutan en una PC con frecuencia dependen del usuario para limpiar después de los problemas de procesamiento. - Las máquinas System / 360 fueron diseñadas para ser compartidas por todos los usuarios de una organización. Entonces, la
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 normal, no en otra impresora que podría estar cargada con cheques en blanco.DISP=SHR
le dice al sistema operativo que otros programas pueden leerOLDFILE
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. [dieciséis]
La sintaxis de OS JCL es similar a la sintaxis de las macros en el lenguaje ensamblador System / 360 y, por lo tanto, los programadores los habrían familiarizado en una época en la que muchos programas estaban codificados en lenguaje ensamblador.
DOS JCL
Parámetros posicionales
// TLBL TAPEFIL, 'COPYTAPE.JOB' ,,,, 2 // ASSGN SYS005,200 // DLBL DISKFIL, 'COPYTAPE.JOB', 0, SD // MEDIDA 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 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 sentencias con menos parámetros que OS JCL. En el ejemplo, las sentencias ASSGN, DLBL y EXTENT hacen el mismo trabajo (especificando dónde debe almacenarse un nuevo archivo de disco) como una única DD
sentencia 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 usaría para cada disco o archivo de cinta, incluso para archivos existentes y para archivos temporales que se eliminarían en el fin del trabajo. Esto significaba que, si un cliente actualizaba a un equipo más moderno, muchos archivos JCL tenían que cambiarse.
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 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
OS JCL consta de tres tipos básicos de declaraciones: [17]
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
instrucción, que identifica el programa o procedimiento [18] que se ejecutará en este paso del trabajo,
e información sobre el paso, incluidas las CONDICIONES para ejecutar u omitir 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 inclusive ) fue más flexible y más 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 sigue siendo 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: [19]
Identificador-Campo Nombre-Campo Operación-Campo Parámetro-Campo Comentarios-Campo ^ ^ ^ ^ sin espacio espacio espacio espacio espacio
El campo de identificador debe concatenarse con el campo de 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 en lugar de datos. El campo de identificador consta de lo siguiente:- Las columnas 1 y 2 de todas las sentencias JCL, excepto la sentencia delimitadora, contienen
//
- Las columnas 1 y 2 de la declaración delimitador contienen
/*
- Las columnas 1, 2 y 3 de una declaración de comentario de JCL contienen
//*
- Las columnas 1 y 2 de todas las sentencias JCL, excepto la sentencia delimitadora, contienen
- Campo de nombre: el campo de nombre identifica una declaración en particular para que otras declaraciones y el sistema puedan hacer referencia a ella. Para las declaraciones JCL, debe codificarse de la siguiente manera:
- El nombre debe comenzar en la columna 3.
- El nombre es de 1 a 8 (alfanuméricos o nacionales
$
,#
,@
) caracteres. - 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, para 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 del cuadro de sintaxis de la declaración.
- La operación sigue al campo de nombre.
- La operación debe ir precedida y seguida de al menos un espacio en blanco.
- La operación será uno de
JOB
,EXEC
yDD
.
- Campo de parámetro: el campo de parámetro, también denominado a veces campo de operando, contiene parámetros separados por comas. El campo de parámetro 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 . Comentarios-El campo debe codificarse de la siguiente manera:
- El campo de comentarios sigue al campo de parámetro.
- El campo de comentarios debe estar 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 = ( NEW , CATLG , DELETE )
Todos los parámetros principales de las declaraciones de OS JCL se identifican mediante palabras clave y se pueden presentar en cualquier orden. Algunos de estos 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 son a veces 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 palabra clave. Los parámetros de palabras clave siempre asignan valores a una palabra clave mediante el signo igual ( =
). [20]
Acceso a datos (declaración DD)
La DD
declaración se utiliza para hacer referencia a los 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 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 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, con la información DD prevaleciendo 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. [21]
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. [22]
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 nuevos archivos que debían mantenerse después del final del trabajo se podrí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 importara, se podría especificar un número de modelo o incluso una dirección de dispositivo específica. [23]
Procedimientos
Los procedimientos permiten agrupar una o más sentencias " EXEC PGM = " y DD y luego invocarlas con " EXEC PROC = procname" -o- simplemente "EXEC procname" [24]
Una instalación llamada Biblioteca de procedimientos permitió el almacenamiento previo de los procedimientos.
PROC & PEND
Los procedimientos también se pueden incluir en la secuencia de trabajos finalizando el procedimiento con una // PEND
instrucción y luego invocándolo por su nombre como si estuviera en una biblioteca de procedimientos.
Por ejemplo:
// SUMPRINT PROC// IMPRIMIR EJECUTAR PGM = IEBGENER // SYSUT1 DD DSN = CEO . ARCHIVOS . DAYEND . RPT24A , DISP = SHR // SYSUT2 DD SYSOUT = A // SYSIN DD DUMMY // PENDER // EXEC SUMPRINT
Procedimientos parametrizados
Los procedimientos de OS JCL se parametrizaron desde el principio, haciéndolos más bien como macros o incluso simples subrutinas y aumentando así su reutilización en una amplia gama de situaciones. [25]
// 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 = ( NUEVO , 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 instrucció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 usar 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 = 2000 o // 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 = ( NUEVO , CATLG , DELETE ) .... // MYPR02 EXEC PGM = ......... . // ENTRADA01 DD DSN = * . MYPR01 . ARCHIVO NUEVO
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 [26] ).
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 . ARCHIVO NUEVO
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.
Comentarios
Los archivos JCL pueden ser largos y complejos, y el idioma 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 JCL. Se pueden ampliar 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 contienen solo comentarios, a menudo se utilizan para explicar los puntos principales sobre la estructura general del JCL en lugar de los detalles locales. Las líneas de solo comentario también se utilizan para dividir archivos JCL largos y complejos en secciones.
// MI TRABAJO TRABAJO .......... // * 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 extendido y X // se desborda en otra línea. // ENTRADA01 DD DSN = PASO01 . MYPR01 . ARCHIVO NUEVO
Concatenar archivos de entrada
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
Las declaraciones segunda y tercera no tienen valor en el campo de nombre, por lo que OS 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 SO (ciertamente después de OS / MVS R3.7 con las "unidades seleccionables" apropiadas), el propio SO, durante la asignación, inspeccionaba cada instancia en una concatenación y sustituía la longitud máxima de bloque que se encontraba.
Una alternativa habitual era simplemente determinar la longitud máxima de bloque posible en el dispositivo y especificar eso 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 esta alternativa era garantizar que el método de acceso asignara un conjunto de búfer de entrada que fuera lo suficientemente grande para dar cabida a 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 especifique qué tan exitoso el programa pensó que fue. Los valores convencionales más comunes son: [27] : p.87
- 0 = Normal - todo correcto
- 4 = Advertencia: errores o problemas menores
- 8 = Error: errores o problemas importantes
- 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 use los resultados!
OS JCL se refiere al código de retorno como COND
("código de condición") y puede utilizarlo para decidir si ejecutar 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, dando lugar a la mnemotécnica , "Si es cierto, pasar [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:
// 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 = ( EVEN , STEP03 ) ....
medio:
- Ejecutar
STEP01
y recopilar su código de retorno. - No ejecute
STEP02
si el número 4 es mayor queSTEP01
el código de retorno. - No ejecute
STEP03
si el número 8 es menor o igual que cualquier código de retorno anterior. - Ejecutar
STEP04
solo siSTEP01
terminó de manera anormal. - Ejecutar
STEP05
, incluso siSTEP03
terminó 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 STEP02final si si cualquier código anterior retorno es inferior a 8 a continuación, ejecutar STEP03finalizar si si STEP01 terminó anormalmente entonces ejecutar STEP04finalizar si si STEP03 terminó anormalmente, entonces ejecutar STEP05demás ejecutar STEP05terminara 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 hizo que la codificación fuera algo más fácil para los programadores al tiempo que conservaba el COND
parámetro (para evitar realizar cambios en los JCL existentes donde COND parm
se usa).
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 satisface una prueba de código de retorno de declaración de TRABAJO, el trabajo termina". [28]
Utilidades
Los trabajos utilizan 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:
- Utilidades de conjuntos de datos: cree, imprima, copie, mueva y elimine conjuntos de datos.
- Utilidades del sistema: mantenga y administre catálogos y otra información del sistema.
- Servicios de métodos de acceso: métodos de acceso al almacenamiento virtual de procesos (VSAM) y conjuntos de datos que no son VSAM.
Dificultad de uso
OS JCL es innegablemente complejo [29] y ha sido descrito como "usuario hostil". [30] [31] Como preguntaba un libro instructivo sobre JCL, "¿Por qué incluso los programadores sofisticados dudan cuando se trata del lenguaje de control de trabajos?" [32] El libro decía que muchos programadores copiaban tarjetas de control sin entender realmente lo que hacían, o "creían en los rumores prevalecientes de que JCL era horrible, y sólo los tipos informáticos 'intransigentes' lo entendían" y se encargaba de descifrar las declaraciones de JCL a otra persona. [32] Esta actitud se puede encontrar en los libros de texto de 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 de WATFOR : "¿Ha sido tan tonto como para intentar escribir sus propias tarjetas de control del sistema 'DD'? Deténgase y desista de inmediato; corra, no camine, en busca de ayuda. " [33]
Sin embargo, algunos libros que entraron en JCL en detalle enfatizaron que una vez que se aprendió a un grado al menos algo competente, uno se liberó de los valores predeterminados de toda la instalación y un control mucho mejor sobre cómo un sistema IBM procesaba su carga de trabajo. [32] [29] 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". [29]
Idioma de control de entrada de trabajo
En los sistemas de mainframe de IBM, Job Entry Control Language o JECL es el conjunto de sentencias de control del lenguaje de mandatos que proporcionan información para el subsistema de spooling : JES2 o JES3 en z / OS o VSE / POWER para z / VSE . Las declaraciones JECL pueden "especificar en qué computadora de red ejecutar el trabajo , cuándo ejecutar el trabajo y dónde enviar la salida resultante". [27]
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.
OS / 360
Una versión anterior de Job Entry Control Language para OS / 360 Remote Job Entry (Número de programa 360S-RC-536) usaba el identificador ..
en las columnas 1-2 del registro de entrada y consistía en una sola declaración de control: JED
(Definición de entrada de trabajo). "Estación de trabajo Comandos", tales como LOGON
, LOGOFF
y STATUS
también comenzó con ..
. [34]
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 sentencias JECL comienzan con /*
, para JES3 comienzan con //*
, excepto para comandos remotos /*SIGNON
y /*SIGNOFF
. Los comandos para los dos sistemas son completamente diferentes.
JES2 JECL
Las siguientes sentencias JES2 JECL se utilizan en z / OS 1.2.0. [35]
Declaración JECL | Función | Ejemplo |
---|---|---|
/*$command | Ingresa un comando de operador (consola) | /*$S PRINTER3 [36] |
/*JOBPARM | Especifica valores para parámetros relacionados con el trabajo | /*JOBPARM TIME=10 |
/*MESSAGE | Envía un mensaje a la consola del operador | /*MESSAGE CALL JOE AT HOME IF JOB ABENDS |
/*NETACCT | Especifica el número de cuenta para el trabajo de red. | /*NETACCT 12345 |
/*NOTIFY | Especifica el destino de los mensajes de notificación. | /*NOTIFY SAM |
/*OUTPUT | Especifica las opciones del conjunto de datos SYSOUT | /*OUTPUT FORMS=BILL |
/*PRIORITY | Establece la prioridad de selección de trabajos | /*PRIORITY 15 |
/*ROUTE | Especifica el destino de salida o el nodo de ejecución | /*ROUTE PRT RMT5 |
/*SETUP | Solicita montaje de volumen u otra operación fuera de línea | /*SETUP TAPE01,TAPE02 |
/*SIGNOFF | Finaliza la sesión remota | /*SIGNOFF |
/*SIGNON | Inicia sesión remota | /*SIGNON REMOTE5 password |
/*XEQ | Especifica el nodo de ejecución | /*XEQ DENVER |
/*XMIT | Indica trabajo o conjunto de datos que se transmitirá a otro nodo de red. | /*XMIT NYC |
JES3 JECL
Las siguientes sentencias JES3 JECL se utilizan en z / OS 1.2.0 [37]
Declaración JECL | Función | Ejemplo |
---|---|---|
//**command | Ingresa un comando de operador (consola) JES3 | |
//*DATASET | Marca el comienzo de un conjunto de datos in-stream | |
//*ENDDATASET | Marca el final de un conjunto de datos in-stream | |
//*ENDPROCESS | Marca el final de una serie de //*PROCESS declaraciones. | |
//*FORMAT | Especifica las SYSOUT opciones del conjunto de datos | |
//*MAIN | Especifica valores para parámetros relacionados con el trabajo | |
//*NET | Identifica las relaciones entre los trabajos mediante el control de trabajos dependiente de JES3 | |
//*NETACCT | Especifica el número de cuenta para el trabajo de red. | |
//*OPERATOR | Envía un mensaje a la consola del operador | |
//*PAUSE | Detiene el lector de entrada | |
//*PROCESS | Identifica un trabajo no estándar | |
//*ROUTE | Especifica el nodo de ejecución para el trabajo. | |
/*SIGNOFF | Finaliza la sesión remota | /*SIGNOFF |
/*SIGNON | Inicia sesión remota |
z / VSE
Para las declaraciones de 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 de JCL. Aconseja a VSE / POWER cómo se maneja este trabajo. Declaraciones JECL definen el nombre de trabajo (utilizado por VSE / POWER), la clase en la que se procesa el trabajo, y la disposición del puesto de trabajo (es decir D
, L
, K
, H
).
Declaración JECL [38] | Función | Ejemplo |
---|---|---|
* $$ CTL | Establece una clase de entrada predeterminada | * $$ CTL CLASS=A |
* $$ JOB | Especifica los atributos de un trabajo. | * $$ JOB JNM=PYRL,PRI=9 |
* $$ EOJ | Marca el final de un trabajo | * $$ EOJ |
* $$ RDR | Inserta un archivo de un disquete 3540 en el flujo de entrada | * $$ RDR SYS005,'fname',2 |
* $$ PRT | Especifica las características de los archivos de impresión en spool. "LST" es sinónimo de "PRT" | * $$ PRT FNO=STD,COPY=2 |
* $$ PUN | Especifica las características de los archivos perforados en cola | * $$ PUN DISP=T,TADDR=280 |
* $$ SLI | Inserta datos ("libro") de la biblioteca de declaraciones de origen en el flujo de entrada | * $$ SLI A.JCL1 |
* $$ DATA | Inserta datos del lector de tarjetas en un libro recuperado de la biblioteca de declaraciones de origen | * $$ DATA INPUT1 |
Ejemplo:
* $$ JOB JNM = NAME, DISP = K, CLASS = 2[algunas declaraciones de JCL aquí]* $$ EOJ
Otros sistemas
Otros sistemas por lotes de mainframe 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 por lo general proporcionaban capacidades similares. Los sistemas interactivos incluyen " lenguajes de comandos": los archivos de comandos (como los archivos PCDOS ".bat") se pueden ejecutar de forma no interactiva, pero normalmente 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 usa CLIST o Rexx como lenguajes de comandos junto con JCL para el trabajo por lotes. En otros sistemas, estos pueden ser iguales.
Ver también
- dd (Unix) , programa Unix inspirado en
DD
- Programas de utilidad de mainframe de IBM
- Procesamiento por lotes
- Conjunto de datos (mainframe IBM) #Generation Data Group
Referencias
- ^ "Cada trabajo enviado para ejecución ... debe incluir declaraciones JCL" - ibm.com
- ^ y muchos detalles más complejos , como si el archivo se conservará o eliminará, el espacio máximo en el disco al que puede crecer, el nombre de una cinta que se premontará
- ^ Ashley y Fernandez, Job Control Language , p. 1.
- ^ Ashley y Fernandez, Job Control Language , p. 5.
- ^ McQuillen, System / 360–370 Assembler Language , págs. 385–386.
- ^ a b McQuillen, System / 360–370 Assembler Language , págs. 288–289, 400.
- ^ McQuillen, System / 360-370 Assembler Language , págs. 22-24.
- ^ McQuillen, System / 360–370 Assembler Language , págs. 380–382.
- ^ Stern and Stern, Programación COBOL estructurada , págs. 528–529.
- ^ Stern and Stern, Programación COBOL estructurada , págs. 529, 531.
- ^ Stern and Stern, Programación COBOL estructurada , págs. 529, 537.
- ^ modelado en https://www.ibm.com/support/knowledgecenter/SSLTBW_2.2.0/com.ibm.zos.v2r2.hasc300/has2z1_Submitting_to_the_internal_reader_from_jobs_or_tasks.htm , utilizando conocimientos que se remontan a cuando las Green Cards procedían de IBM y Manix para una empresa que posee un clasificador de tarjetas IBM
- ^ "Archivos de IBM: System / 360 Model 30" . www-03.ibm.com . 2003-01-23 . Consultado el 25 de abril de 2016 .
- ^ PC de IBM
- ^ Computadoras compatibles con IBM History of PCs Archivado el 14 de agosto de 2007 en Wayback Machine
- ^ Brown, Gary DeWard (2002). zOS JCL (quinta ed.). John Wiley e hijos. pag. 248. ISBN 0471-236357.
- ^ Ashley y Fernandez, Job Control Language , págs. 8, 23. También hay dos declaraciones adicionales, PROC y PEND, que se utilizan para probar los procedimientos de JCL.
- ^ Un conjunto pre-almacenado de comandos JCL "EXEC PGM =" y "DD" que se pueden parametrizar
- ^ Ashley y Fernandez, Job Control Language , págs. 12-16.
- ^ Ashley y Fernandez, Job Control Language , págs. 13-15.
- ^ IBM Corporation (agosto de 1978). Guía de servicios de gestión de datos OS / VS MVS (PDF) . Consultado el 17 de octubre de 2014 .
- ^ IBM Corporation (junio de 1971). IBM System / 360 Operating System: Referencia del lenguaje de control de trabajos (PDF) . Consultado el 25 de junio de 2019 .
- ^ McQuillen, System / 360–370 Assembler Language , págs. 297, 406–407.
- ^ el valor predeterminado para la instrucción EXEC es PROC =
- ^ Ashley y Fernandez, Job Control Language , págs. 129-131.
- ^ "Nombres de conjuntos de datos" .
Los nombres de los conjuntos de datos no deben exceder los 44 caracteres, incluidos todos los segmentos y puntos del nombre.
- ^ a b Brown, Gary DeWard (2002). zOS JCL . John Wiley e hijos. ISBN 9780471426738. Consultado el 5 de mayo de 2014 .
- ^ IBM Corporation. "Relación de los parámetros COND en declaraciones JOB y EXEC" . Centro de conocimiento de IBM . Consultado el 21 de febrero de 2018 .
- ^ a b c McQuillen, System / 360–370 Assembler Language , págs. 406–407.
- ^ Charley, Alfred (1993). NetView: producto de gestión de redes de IBM . Nueva York: Van Nostrand Reinhold. pag. 93 . ISBN 0-442-01407-4.
- ^ Mathew W. Blode (6 de abril de 2020). "Los neoyorquinos recién desempleados se sienten frustrados por la tecnología de la era de los setenta (nytimes.com)" . Consultado el 7 de mayo de 2020 .
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 ...) .
- ^ a b c Ashley y Fernandez, Job Control Language , págs. vii-viii, contraportada.
- ^ Blatt, John M. (1971). Introducción a la programación de FORTRAN IV: uso de los compiladores WATFOR / WATFIV . Pacific Palisades, California: Goodyear Publishing Company. pag. 276. ISBN 0-87620-440-X.
- ^ IBM Corporation (1968). Entrada remota de trabajos del sistema operativo IBM System / 360 (PDF) . Consultado el 5 de mayo de 2014 .
- ^ IBM Corporation. "Declaraciones de control del subsistema de entrada de trabajos 2 (JES2)" . z / OS V1R2.0 MVS JCL . Consultado el 25 de febrero de 2013 .
- ^ otros ejemplos se pueden ver en Houston Automatic Spooling Priority # Operator Commands
- ^ IBM Corporation. "Declaraciones de control del subsistema de entrada de trabajos 3 (JES3)" . z / OS V1R2.0 MVS JCL . Consultado el 25 de febrero de 2013 .
- ^ IBM Corporation (1974). Instalación y operaciones de DOS / VS POWER / VS (PDF) .
Fuentes
- "Guía del usuario de z / OS V1R6.0 MVS JCL" (PDF) (5ª ed.). IBM. Septiembre de 2004.
- "Referencia JCL de z / OS V1R7.0 MVS" (PDF) (11ª ed.). IBM. Abril de 2006.
- Johnston, Jerry (1 de abril de 2005). "VSE: una mirada a los últimos 40 años" . z / Diario . Thomas Communications. Archivado desde el original el 4 de marzo de 2009.
- "Crónicas informáticas: 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 instrucción JCL" . z / OS V1R11.0 MVS Referencia JCL 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) . ISBN 978-0-73-848624-6. Consultado el 6 de diciembre de 2017 .
- Ashley, Ruth; Fernández, Judi N. (1978). Job Control Language: una guía de autoaprendizaje . Nueva York: John Wiley & Sons. ISBN 0-471-03205-0.
- McQuillen, Kevin (1975). System / 360–370 Assembler Language (SO) . Fresno, California: Mike Murach & Associates. LCCN 74-29645 .
- Stern, Nancy; Stern, Robert A. (1980). Programación estructurada COBOL (3ª ed.). Nueva York: John Wiley & Sons. ISBN 0-471-04913-1.