stringtranslate.com

Idioma de control de trabajo

Job Control Language ( JCL ) es el nombre de 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. [1] El propósito de JCL es decir qué programas ejecutar, usar qué archivos o dispositivos [2] para entrada o salida y, en ocasiones, también indicar bajo qué condiciones omitir un paso. Los parámetros en JCL también pueden proporcionar información contable para rastrear los recursos utilizados por un trabajo, así como en qué máquina debe ejecutarse el trabajo.

Hay dos lenguajes distintos de IBM Job Control:

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.

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. [8] JCL se desarrolló como un medio para garantizar que todos los recursos necesarios estén disponibles antes de programar la ejecución de un trabajo. Por ejemplo, muchos sistemas, como Linux, permiten que la identificación de los conjuntos de datos requeridos se especifiquen en la línea de comando y, por lo tanto, estén sujetos a sustitución por parte del shell o sean generados por el programa en tiempo de ejecución. En estos sistemas, el programador de trabajos del sistema operativo tiene poca o ninguna idea de los requisitos del trabajo. Por el contrario, JCL especifica explícitamente todos los conjuntos de datos y dispositivos necesarios. El programador puede preasignar los recursos antes de liberar el trabajo para su ejecución. Esto ayuda a evitar el " punto muerto ", donde el trabajo A retiene el recurso R1 y solicita el recurso R2, mientras que el trabajo B que se ejecuta simultáneamente retiene el recurso R2 y solicita R1. En tales casos, la única solución es que el operador del ordenador finalice uno de los trabajos, que luego debe reiniciarse. Con el control de trabajos, si el trabajo A está programado para ejecutarse, el trabajo B no se iniciará hasta que el trabajo A complete o libere los recursos necesarios.

Características comunes a DOS y OS JCL

Trabajos, trámites 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.

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

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

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 . [10] Más tarde fue posible enviar trabajos a través de archivos de disco o cinta con longitudes de registro más largas, pero los componentes de envío de trabajos del sistema operativo ignoraron todo después del carácter 80.

Estrictamente hablando, ambas familias de sistemas operativos utilizan sólo 71 caracteres por línea. Los caracteres 73 a 80 suelen ser números de secuencia de tarjetas que el sistema imprimió en el informe de fin de trabajo y son útiles para identificar la ubicación de cualquier error informado por el sistema operativo. El carácter 72 normalmente se deja en blanco, pero puede contener un carácter que no esté en blanco para indicar que la declaración JCL continúa en la siguiente tarjeta.

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

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

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

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

Entrada en flujo

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

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

Un operando llamado DLM permitía especificar un delimitador (el valor predeterminado es "/*"). Especificar un delimitador alternativo permite leer JCL como datos, por ejemplo, para copiar procedimientos a un miembro de la biblioteca o 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 EXEC PGM = IEBGENER // SYSPRINT DD SYSOUT = Z // SYSUT2  DD SYSOUT = ( A , INTRDR ) // SYSIN  DD DUMMY // SYSUT1  DD DATA , DLM = ZZ // RUNLATR JOB ACCT , MANIX , CLASS = A . TYPRUN = HOLD //* ^ un TRABAJO para ejecutar más tarde // CPUHOG EXEC PGM = PICALC1K // SALIDA  DD DSN = PICALC .1000 DGTS , ESPACIO = ( TRK , 1 ), DISP = (, KEEP ) ZZ //* ^ como especificado por DLM=ZZ // DROPOLDR EXEC PGM = IEFBR14 // DELETE4  DD DSN = PICALC .4 DGTS , DISP = ( ANTIGUO , BORRAR ) // DELETE5  DD DSN = PICALC .5 DGTS , DISP = ( ANTIGUO , BORRAR )        
  1. El programa llamado PICALC1K esperará (TYPRUN=HOLD) para ser liberado manualmente
  2. El programa llamado IEFBR14 se ejecutará AHORA y, al finalizar, se eliminarán los dos archivos existentes, PICALC.4DGTS y PICALC.5DGTS.

Complejidad

Fred Brooks , que supervisó el proyecto OS/360 en el que se creó JCL, lo llamó "el peor lenguaje de programación jamás ideado por nadie, en ningún lugar" en The Design of Design , donde lo utilizó como ejemplo en el capítulo "How Expert Los diseñadores se equivocan". [14] Atribuyó esto a que los diseñadores no se dieron cuenta de que JCL es, de hecho, un lenguaje de programación.

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

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

cp archivo antiguo archivo nuevo

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

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

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

Las versiones posteriores de los sistemas operativos DOS/360 y OS/360 conservan la mayoría de las características del JCL original, aunque se ha realizado cierta simplificación para evitar obligar a los clientes a reescribir todos sus archivos JCL. [ cita necesaria ] Muchos usuarios guardan como procedimiento cualquier conjunto de declaraciones JCL que probablemente se utilizarán más de una o dos veces. [18]

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

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.

DOS JCL mitiga hasta cierto punto las dificultades de los parámetros posicionales al utilizar más declaraciones con menos parámetros que OS JCL. En el ejemplo, las declaraciones ASSGN, DLBL y EXTENT hacen el mismo trabajo (especificando dónde se debe almacenar un nuevo archivo de disco) que una sola DDdeclaración 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 utilizar para cada disco o archivo de cinta, incluso para archivos existentes y para archivos temporales que se eliminarían en el momento. final del trabajo. Esto significaba que, si un cliente actualizaba a un equipo más moderno, debían cambiarse muchos archivos JCL.

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

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 EXTENTtarjeta 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: [19]

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: [21]

Identificador-Campo Nombre-Campo Operación-Campo Parámetro-Campo Comentarios-Campo ^ ^ ^ ^ sin espacio espacio espacio espacio

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

Parámetros de palabras clave

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

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

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

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 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 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 para un archivo existente almacenado en cinta o disco y la macro DCB codificada en el programa. Cuando se abre el archivo, estos datos se combinan, teniendo la información DD prioridad sobre la información de la etiqueta y la información DCB teniendo prioridad sobre ambas. Luego, la descripción actualizada se vuelve a escribir en la etiqueta del conjunto de datos. Esto puede tener consecuencias no deseadas si se proporciona información DCB incorrecta. [23]

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

La declaración DD permite inyectar datos en línea en la secuencia de trabajos. Esto es útil para proporcionar información de control a utilidades como IDCAMS, SORT, etc., así como para proporcionar datos de entrada a los programas.

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 debían conservarse una vez finalizado el trabajo, se podía especificar el tipo de dispositivo en términos genéricos, por ejemplo, UNIT=DISK, UNIT=TAPEo UNIT=SYSSQ(cinta o disco). Por supuesto, si fuera importante, se podría especificar un número de modelo o incluso una dirección de dispositivo específica. [25]

Trámites

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

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

PROCESO Y PENDIENTE

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

Por ejemplo:

// PROC RESUMEN // IMPRIMIR EXEC PGM=IEBGENER // SYSUT1  DD DSN = CEO . ARCHIVOS . FINAL DEL DÍA . RPT24A , DISP = SHR // SYSUT2  DD SYSOUT = A // SYSIN  DD DUMMY // PEND // RESUMEN EJECUTIVO    

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. [27]

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

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

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

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 , UNIDAD = DISCO , ESPACIO = ( TRK , 50 , 10 ), // DCB = ( LRECL = 100 , BLKSIZE = 1000 ), DISP = ( NUEVO , CATLG , BORRAR ) .... // MYPR02 EXEC PGM = ......... // ENTRADA01 DD DSN = * .MYPR01 . ARCHIVO NUEVO      

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

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

// MYJOB JOB .......... // STEP01 EXEC MYPROC Usando un procedimiento // STEP02 EXEC PGM = ......... Paso específico de este trabajo // INPUT01 DD DSN = * . PASO01 . MYPR01 . ARCHIVO NUEVO        

donde DSN=*.STEP01.MYPR01.NEWFILEsignifica "utilizar el archivo identificado como NEWFILEen el paso MYPR01del procedimiento utilizado en el paso STEP01de 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:

// MYJOB JOB .......... //* Líneas que contienen solo comentarios. //******** A menudo se utiliza para dividir el listado JCL en secciones ******** // STEP01 EXEC MYPROC Comentario 2 en la misma línea que la declaración // STEP02 EXEC PGM = ...... ... El comentario 3 se ha ampliado y X // se desborda en otra línea. // ENTRADA01 DD DSN = PASO01 . MYPR01 . 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    

La segunda y tercera declaraciones no tienen valor en el campo de nombre, por lo que el sistema operativo las trata como concatenaciones. Los archivos deben ser del mismo tipo básico (casi siempre secuenciales) y deben tener la misma longitud de registro; sin embargo, la longitud del bloque no tiene por qué ser la misma.

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

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

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

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

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

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

Procesamiento condicional

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

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

// MITRABAJO ........... // PASO01 PGM EXEC = PROG01 .... // PASO02 PGM EXEC = PROG02 , COND = ( 4 , GT , PASO01 ) .... // PASO03PGM EXEC = PROG03 , COND = ( 8 , LE ) .... // PASO04 PGM EXEC = PROG04 , COND = ( SÓLO , PASO01 ) .... // PASO05 PGM EXEC = 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.
  3. No ejecute STEP03si el número 8 es menor o igual que cualquier código de retorno anterior.
  4. Ejecute STEP04solo si STEP01finalizó de manera anormal.
  5. Ejecutar STEP05, incluso si STEP03finalizó de forma anormal.

Esto se traduce en el siguiente pseudocódigo :

ejecute STEP01 si el código de retorno de STEP01 es mayor o igual a 4 , entonces ejecutar STEP02finalizar si algún código de retorno anterior es menor que 8 , entonces ejecutar STEP03finalizar si STEP01 finalizó anormalmente entonces ejecutar STEP04finalizar si STEP03 finalizó anormalmente entonces ejecutar STEP05demás ejecutar STEP05terminara si

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

El CONDparámetro también se puede especificar en la JOBdeclaración. Si es así, el sistema "realiza las mismas pruebas de código de retorno para cada paso de un trabajo. Si se cumple una prueba de código de retorno de una instrucción JOB, el trabajo finaliza". [30]

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:

dificultad de uso

OS JCL es innegablemente complejo [31] y ha sido descrito como "hostil al usuario". [32] [33] Como preguntaba un libro instructivo sobre JCL: "¿Por qué incluso los programadores sofisticados dudan cuando se trata de Job Control Language?" [34] El libro afirmaba que muchos programadores copiaban tarjetas de control sin entender realmente lo que hacían, o "creían los rumores prevalecientes de que JCL era horrible, y sólo los tipos de computadoras 'incondicionales' alguna vez lo entendieron" y entregaron la tarea de descifrar las declaraciones JCL a otra persona. [34] Esta actitud se podía encontrar en los libros de texto sobre lenguajes de programación, que preferían centrarse en el lenguaje en sí y no en cómo se ejecutaban los programas en él. Como decía un libro de texto de Fortran IV al enumerar posibles mensajes de error del compilador WATFOR : "¿Ha sido tan tonto como para intentar escribir sus propias tarjetas de control del sistema 'DD'? Cese y desista de inmediato; corra, no camine, en busca de ayuda. " [35]

Sin embargo, algunos libros que abordan JCL en detalle enfatizan que una vez que se aprende al menos hasta cierto punto competente, uno se libera de los valores predeterminados en toda la instalación y tiene un control mucho mejor sobre cómo un sistema IBM procesa su carga de trabajo. [34] [31] Otro libro comentó sobre la complejidad, pero dijo: "anímate. La capacidad JCL que obtendrás [del capítulo anterior] es todo lo que la mayoría de los programadores necesitarán". [31]

Idioma de control de entrada de trabajo

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

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

Existen diferentes versiones de JECL para los tres entornos.

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 una única declaración de control: JED(Definición de entrada de trabajos). "Comandos de estación de trabajo", como LOGON, LOGOFFy 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.

z/OS

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

JES2 JECL

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

JES3 JECL

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

z/VSE

Para VSE JECL, las declaraciones comienzan con " * $$" (tenga en cuenta el espacio simple ). El lenguaje de control de entrada de trabajos define las líneas de inicio y finalización de los trabajos JCL. Informa a VSE / POWER cómo se maneja este trabajo. Las declaraciones JECL definen el nombre del trabajo (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:

* $$ TRABAJO JNM=NOMBRE,DISP=K,CLASE=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. Los sistemas interactivos incluyen " lenguajes de comandos ": los archivos de comandos (como los archivos ".bat" de PCDOS) se pueden ejecutar de forma no interactiva, pero generalmente no proporcionan un entorno tan sólido para ejecutar trabajos desatendidos como JCL. En algunos sistemas informáticos, el lenguaje de control del trabajo y el lenguaje de comando interactivo pueden ser diferentes. Por ejemplo, TSO en sistemas z/OS utiliza CLIST o Rexx como lenguajes de comando junto con JCL para trabajo por lotes. En otros sistemas esto puede ser lo mismo.

Ver también

Referencias

  1. ^ "Cada trabajo enviado para su ejecución... debe incluir declaraciones JCL" - ibm.com
  2. ^ y muchos detalles más complejos, como si el archivo se va a conservar o eliminar, el espacio máximo en disco que puede crecer, el nombre de una cinta que se va a premontar
  3. ^ Ashley y Fernández, Lenguaje de control del trabajo , p. 1.
  4. ^ Ashley y Fernández, Lenguaje de control del trabajo , p. 5.
  5. ^ McQuillen, Lenguaje ensamblador System/360–370 , págs.
  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) . COMPARTE en Orlando . Consultado el 3 de marzo de 2023 .
  8. ^ McQuillen, Lenguaje ensamblador System/360–370 , págs.
  9. ^ McQuillen, Lenguaje ensamblador System/360–370 , págs.
  10. ^ Stern and Stern, Programación COBOL estructurada , págs.
  11. ^ Stern and Stern, Programación COBOL estructurada , págs.529, 531.
  12. ^ Stern and Stern, Programación COBOL estructurada , págs.529, 537.
  13. ^ inspirado 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 vinieron de IBM y Manix funcionó para una empresa propietaria de un clasificador de tarjetas IBM
  14. ^ Brooks, Federico P. (2010). El diseño del diseño . Addison-Wesley . págs. 167-173. ISBN 978-0-201-36298-5.
  15. ^ "Archivos de IBM: Sistema/360 Modelo 30". www-03.ibm.com . 2003-01-23 . Consultado el 25 de abril de 2016 .
  16. ^ "PC IBM". 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. ^ Marrón, Gary DeWard (2002). zOS JCL (quinta ed.). John Wiley e hijos. pag. 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 se pueden parametrizar
  21. ^ Ashley y Fernández, Lenguaje de control del trabajo , págs.
  22. ^ Ashley y Fernández, Lenguaje de control del trabajo , págs.
  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). Sistema operativo IBM System/360: referencia del lenguaje de control de trabajos (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 declaración EXEC es PROC=
  27. ^ Ashley y Fernández, Lenguaje de control del trabajo , págs.
  28. ^ "Nombres de conjuntos de datos". IBM . 27 de marzo de 2014. Los nombres de los conjuntos de datos no deben exceder los 44 caracteres, incluidos todos los segmentos y períodos de nombres.
  29. ^ ab Brown, Gary DeWard (2002). zOS JCL. John Wiley e hijos. ISBN 9780471426738. Consultado el 5 de mayo de 2014 .
  30. ^ Corporación IBM. "Relación de los parámetros COND en declaraciones JOB y EXEC". Centro de conocimiento de IBM . Consultado el 21 de febrero de 2018 .
  31. ^ abc McQuillen, Lenguaje ensamblador System/360–370 , págs.
  32. ^ Charley, Alfred (1993). NetView: producto de gestión de redes de IBM . Nueva York: Van Nostrand Reinhold. pag. 93.ISBN 0-442-01407-4.
  33. ^ Mathew W. Blode (6 de abril de 2020). "Los neoyorquinos recién desempleados se sienten frustrados por la tecnología de la década de 1970 (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 original].
  34. ^ abc Ashley y Fernandez, Job Control Language , págs. vii-viii, contraportada.
  35. ^ Blatt, John M. (1971). Introducción a la programación de FORTRAN IV: uso de los compiladores WATFOR/WATFIV . Pacific Palisades, California: Compañía editorial Goodyear. pag. 276.ISBN 0-87620-440-X.
  36. ^ Corporación IBM (1968). Entrada remota de trabajos del sistema operativo IBM System/360 (PDF) . Consultado el 5 de mayo de 2014 .
  37. ^ Corporación IBM. "Declaraciones de control del subsistema de entrada de trabajos 2 (JES2)". z/OS V1R2.0 MVSJCL . Archivado desde el original el 18 de octubre de 2015 . Consultado el 25 de febrero de 2013 .
  38. ^ se pueden ver otros ejemplos en Prioridad de cola automática de Houston # Comandos del operador
  39. ^ Corporación IBM. "Declaraciones de control del subsistema de entrada de trabajos 3 (JES3)". z/OS V1R2.0 MVSJCL . Archivado desde el original el 18 de octubre de 2015 . Consultado el 25 de febrero de 2013 .
  40. ^ Corporación IBM (1974). Instalación y operaciones de DOS/VS POWER/VS (PDF) .

Fuentes