stringtranslate.com

Lenguaje de control de trabajo

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

Hay dos lenguajes de control de trabajos de IBM distintos:

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

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

Terminología

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

Motivación

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

Características comunes a JCL de DOS y OS

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 la era de las bases de datos relacionales , un trabajo para producir un informe impreso para la administración podía constar de los siguientes pasos: un programa escrito por el usuario para seleccionar los registros apropiados y copiarlos a un archivo temporal; ordenar el archivo temporal en el orden requerido, generalmente utilizando una utilidad de propósito general; un programa escrito por el usuario para presentar la información de una manera que sea fácil de leer para los usuarios finales e incluya otra información útil como subtotales; y un programa escrito por el usuario para formatear páginas seleccionadas de la información del usuario final para mostrarlas en un monitor o terminal.

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

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

Sintaxis básica

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

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

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

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

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

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

Entrada en flujo

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

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

Un operando llamado DLM permitió especificar un delimitador (el valor predeterminado es "/*"). Especificar un delimitador alternativo permite que JCL se lea como datos, por ejemplo, para copiar procedimientos a un miembro de la biblioteca o para enviar un trabajo al lector interno .
  • Un ejemplo, [13] que envía un trabajo al lector interno ( INTRDR ) y luego elimina dos archivos es:
// SUBM EJEC PGM = IEBGENER // SYSPRINT DD SYSOUT = Z // SYSUT2  DD SYSOUT = ( A , INTRDR ) // SYSIN  DD DUMMY // SYSUT1  DD DATOS , DLM = ZZ // RUNLATR TRABAJO CUENTA , MANIX , CLASE = A . TYPRUN = HOLD //* ^ un TRABAJO para ejecutar más tarde // CPUHOG EXEC PGM = PICALC1K // SALIDA  DD DSN = PICALC .1000 DGTS , SPACE = ( TRK , 1 ), DISP = (, KEEP ) ZZ //* ^ como se especifica por DLM=ZZ // DROPOLDR EXEC PGM = IEFBR14 // DELETE4  DD DSN = PICALC .4 DGTS , DISP = ( OLD , DELETE ) // DELETE5  DD DSN = PICALC .5 DGTS , DISP = ( OLD , DELETE )
  1. El programa llamado PICALC1K esperará (TYPRUN=HOLD) siendo liberado manualmente
  2. El programa llamado IEFBR14 se ejecutará AHORA y una vez finalizado, se eliminarán los dos archivos existentes, PICALC.4DGTS y PICALC.5DGTS.

Complejidad

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

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

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

cp Archivo antiguo Archivo nuevo

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

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

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

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

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

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

Dependencia del dispositivo

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

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

Asignación manual de archivos

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

Sistema operativo JCL

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

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

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

Reglas para codificar sentencias JCL

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

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

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

Parámetros de palabras clave

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

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

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

Acceso a datos (declaración DD)

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

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

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

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

Independencia del dispositivo

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

Procedimientos

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

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

PROCEDIMIENTO Y PENDENCIA

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

Por ejemplo:

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

Procedimientos parametrizados

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

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

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

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

Referencias

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

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

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

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

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

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

Comentarios

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

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

Concatenación de 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

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

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

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

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

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

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

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

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

Procesamiento condicional

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

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

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

medio:

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

Esto se traduce al siguiente pseudocódigo :

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

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

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

Utilidades

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

Dificultad de uso

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

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

Lenguaje de control de entrada de trabajo

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

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

Hay diferentes versiones de JECL para los tres entornos.

Sistema operativo/360

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

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.

Sistema operativo z

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

JES2 JECL

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

JES3 JECL

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

z/VSE

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

Ejemplo:

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

Otros sistemas

Otros sistemas de procesamiento por lotes de mainframe tenían algún tipo de lenguaje de control de trabajos, ya sea que se llamara así o no; su sintaxis era completamente diferente de las versiones de IBM, pero generalmente proporcionaban capacidades similares. Los sistemas interactivos incluyen " lenguajes de comandos ": los archivos de comandos (como los archivos ".bat" de PCDOS) se pueden ejecutar de forma no interactiva, pero estos generalmente no proporcionan un entorno tan sólido para ejecutar trabajos desatendidos como JCL. En algunos sistemas informáticos, el lenguaje de control de trabajos y el lenguaje de comandos interactivo pueden ser diferentes. Por ejemplo, TSO en sistemas z/OS usa CLIST o Rexx como lenguajes de comandos junto con JCL para el trabajo por lotes. En otros sistemas, estos pueden ser los mismos.

Véase también

Referencias

  1. ^ "Todo trabajo enviado para su ejecución... debe incluir sentencias JCL" -- ibm.com
  2. ^ y muchos más detalles complejos, como si el archivo se debe conservar o eliminar, el espacio máximo en disco al que puede crecer, el nombre de una cinta que se debe premontar
  3. ^ Ashley y Fernández, Job Control Language , pág. 1.
  4. ^ Ashley y Fernández, Job Control Language , pág. 5.
  5. ^ McQuillen, Lenguaje ensamblador System/360–370 , págs. 385–386.
  6. ^ ab McQuillen, Lenguaje ensamblador System/360–370 , págs. 288–289, 400.
  7. ^ Lewis, Cecilia (8 de agosto de 2011). "Lo que hemos hecho por usted últimamente con PDSE" (PDF) . COMPARTIR en Orlando . Consultado el 3 de marzo de 2023 .
  8. ^ McQuillen, Lenguaje ensamblador System/360–370 , págs. 22–24.
  9. ^ McQuillen, Lenguaje ensamblador System/360–370 , págs. 380–382.
  10. ^ Stern y Stern, Programación COBOL estructurada , págs. 528–529.
  11. ^ Stern y Stern, Programación COBOL estructurada , págs. 529, 531.
  12. ^ Stern y Stern, Programación COBOL estructurada , págs. 529, 537.
  13. ^ 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 conocimiento que data de cuando las Tarjetas Verdes vinieron de IBM y Manix trabajaba para una empresa que poseía un clasificador de tarjetas IBM
  14. ^ Brooks, Frederick P. (2010). El diseño del diseño . Addison-Wesley . Págs. 167-173. ISBN. 978-0-201-36298-5.
  15. ^ "Archivos de IBM: System/360 Model 30". www-03.ibm.com . 23 de enero de 2003. Archivado desde el original el 17 de diciembre de 2004 . Consultado el 25 de abril de 2016 .
  16. ^ "IBM PC". Archivado desde el original el 5 de julio de 2006. Consultado el 21 de octubre de 2007 .
  17. ^ Computadoras compatibles con IBM Historia de las PC Archivado el 14 de agosto de 2007 en Wayback Machine.
  18. ^ Brown, Gary DeWard (2002). zOS JCL (quinta edición). John Wiley & Sons. pág. 248. ISBN 0471-236357.
  19. ^ Ashley y Fernández, Job Control Language , págs. 8, 23. También hay dos declaraciones adicionales, PROC y PEND, que se utilizan para probar los procedimientos JCL.
  20. ^ Un conjunto prealmacenado de comandos JCL "EXEC PGM=" y "DD" que podrían parametrizarse
  21. ^ Ashley y Fernández, Job Control Language , págs. 12-16.
  22. ^ Ashley y Fernández, Job Control Language , págs. 13-15.
  23. ^ 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 .
  24. ^ IBM Corporation (junio de 1971). IBM System/360 Operating System: Job Control Language Reference (PDF) . Consultado el 25 de junio de 2019 .
  25. ^ McQuillen, Lenguaje ensamblador System/360–370 , págs. 297, 406–407.
  26. ^ el valor predeterminado para la instrucción EXEC es PROC=
  27. ^ Ashley y Fernández, Job Control Language , págs. 129-131.
  28. ^ "Nombres de conjuntos de datos". IBM . 27 de marzo de 2014. Los nombres de los conjuntos de datos no deben superar los 44 caracteres, incluidos todos los segmentos y puntos del nombre.
  29. ^ ab Brown, Gary DeWard (2002). zOS JCL. John Wiley & Sons. ISBN 9780471426738. Recuperado el 5 de mayo de 2014 .
  30. ^ IBM Corporation. "Relación de los parámetros COND en las sentencias JOB y EXEC". IBM Knowledge Center . Consultado el 21 de febrero de 2018 .
  31. ^ abc McQuillen, Lenguaje ensamblador System/360–370 , págs. 406–407.
  32. ^ Charley, Alfred (1993). NetView: el producto de gestión de redes de IBM . Nueva York: Van Nostrand Reinhold. pág. 93. ISBN 0-442-01407-4.
  33. ^ Mathew W. Blode (6 de abril de 2020). "Newly unemployed New Yorkers are being frustrated by 1970s-era technology(nytimes.com)" (Los neoyorquinos recientemente desempleados se sienten frustrados por la tecnología de la era de los años 70) (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...)[enlace en el original].
  34. ^ abc Ashley y Fernández, Job Control Language , págs. vii–viii, contraportada.
  35. ^ Blatt, John M. (1971). Introducción a la programación en FORTRAN IV: uso de los compiladores WATFOR/WATFIV . Pacific Palisades, California: Goodyear Publishing Company. pág. 276. ISBN 0-87620-440-X.
  36. ^ IBM Corporation (1968). Entrada de trabajo remota del sistema operativo IBM System/360 (PDF) . Consultado el 5 de mayo de 2014 .
  37. ^ IBM Corporation. «Job Entry Subsystem 2 (JES2) Control Statements» (Declaraciones de control del subsistema de entrada de trabajo 2 [JES2]). z/OS V1R2.0 MVS JCL . Archivado desde el original el 18 de octubre de 2015. Consultado el 25 de febrero de 2013 .
  38. ^ Se pueden ver otros ejemplos en Comandos del operador de prioridad de spooling automático de Houston
  39. ^ IBM Corporation. «Job Entry Subsystem 3 (JES3) Control Statements» (Declaraciones de control del subsistema de entrada de trabajo 3 [JES3]). z/OS V1R2.0 MVS JCL . Archivado desde el original el 18 de octubre de 2015. Consultado el 25 de febrero de 2013 .
  40. ^ IBM Corporation (1974). Instalación y operaciones de DOS/VS POWER/VS (PDF) .

Fuentes