Leer JCL empieza por el orden de ejecución

JCL se vuelve legible cuando dejas de tratarlo como un programa y empiezas a verlo como un grafo de control serializado. El código fuente nombra programas, aporta recursos y declara compuertas, pero varios sistemas deciden qué se ejecuta de verdad: el conversor expande procedimientos, el catálogo resuelve conjuntos de datos, JES y el iniciador fijan el contexto, el planificador puede inyectar símbolos y un operador puede reiniciar el trabajo a mitad de camino. Leer solo las tarjetas visibles produce con facilidad un diagrama convincente y equivocado.

La primera lectura tiene un objetivo: recuperar los pasos ordenados, los datos que cada uno lee y escribe y las condiciones que pueden suprimirlo. Los detalles sintácticos vienen después. He visto equipos pasar una mañana descifrando columnas y comas sin reparar en que un procedimiento catalogado añadía seis pasos y el planificador elegía la generación de ayer. Empieza por el comportamiento y usa la sintaxis para demostrarlo.

Un miembro JCL es un grafo de control, no un script

Un trabajo suele contener una sentencia JOB seguida de sentencias EXEC, con sentencias DD asociadas a cada EXEC. Parece secuencial, y en el nivel superior lo es: si no hay saltos, fallos, reinicios o terminaciones anómalas, JES presenta los pasos al iniciador en orden. Sin embargo, el miembro visible puede contener solo parte del grafo. Un EXEC puede invocar un procedimiento catalogado o incluido en línea, JCLLIB puede cambiar dónde se buscan procedimientos e INCLUDE puede incorporar más sentencias antes de ejecutar.

Separa cuatro fases. En la entrada, JES lee el trabajo y aplica sus reglas. En la conversión, el sistema comprueba JCL, expande procedimientos y resuelve símbolos. En la asignación, z/OS localiza o crea los conjuntos de datos y dispositivos que necesita un paso. En la ejecución, el programa elegido corre y devuelve un código o termina de forma anómala. El procesamiento de salida y la purga rodean ese flujo, pero no convierten JCL en lógica de aplicación.

Esta distinción explica un misterio habitual: un trabajo puede fallar antes de que se ejecute el primer programa. Un procedimiento ausente, un parámetro simbólico sin resolver, un nombre de paso duplicado, un DD no válido o un conjunto de datos no disponible pueden provocar un error JCL durante conversión o asignación. No llames fallo de aplicación a todo trabajo rojo. Pregunta primero si algún programa llegó a recibir el control. Los mensajes JES y el registro del trabajo lo indican.

Dibuja un grafo aproximado antes de leer operandos. Crea un nodo por cada paso EXEC expandido, una flecha continua para la secuencia normal, una discontinua para cada condición y aristas de datos para conjuntos con nombre entre productores y consumidores. Anota tres estados que no son archivos normales: símbolos resueltos en la conversión, estado del catálogo consultado en la asignación y códigos de retorno producidos en la ejecución. El dibujo revela pronto qué pruebas faltan.

El orden del código sigue importando, pero solo responde a una pregunta: ¿en qué orden irían los pasos elegibles? No dice si son elegibles, qué contiene un procedimiento, qué generación física elige un nombre GDG relativo ni dónde comienza un reinicio. Trata el miembro como entrada de una ejecución, no como la transcripción de ella.

Las sentencias EXEC definen las unidades de trabajo

Cada EXEC crea un paso y su operando indica si ejecuta directamente un programa o invoca un procedimiento. EXEC PGM=IEFBR14 nombra un programa. EXEC PROC=DAILY o la forma corta EXEC DAILY invoca un procedimiento. El nombre de paso a la izquierda de EXEC es la referencia estable para condiciones, sustituciones, reinicios y mensajes; cópialo exactamente.

Empieza con un ejemplo compacto:

//BILLING  JOB (ACCT),'DAILY BILL',CLASS=A,MSGCLASS=X
//EXTRACT  EXEC PGM=EXTBILL,PARM='DAILY'
//INPUT    DD DSN=APP.CUST.MASTER,DISP=SHR
//OUT      DD DSN=APP.BILL.WORK(+1),DISP=(NEW,CATLG,DELETE),
//            SPACE=(CYL,(20,10)),UNIT=SYSDA
//SORT     EXEC PROC=SORTBILL,INDSN=APP.BILL.WORK(+1)
//LOAD     EXEC PGM=LOADBILL,COND=(0,NE,SORT)
//IN       DD DSN=APP.BILL.SORTED(+1),DISP=SHR

El esquema visible es EXTRACT, SORT, LOAD. Todavía no es un plan de ejecución. SORTBILL puede expandirse en varios pasos. SORT identifica el paso llamante, mientras que los mensajes y condiciones internas emplean nombres cualificados como SORT.COPY. LOAD tiene una condición que puede suprimirlo. Ambos nombres relativos de generación requieren el contexto del catálogo.

Lee un EXEC en este orden: nombre del paso, PGM o procedimiento, controles de condición, límites de región o tiempo si existen y texto de parámetros pasado al programa. No interpretes PARM como lógica JCL. JCL pasa el texto; solo el contrato del programa explica PARM='DAILY'. Lo mismo vale para SYSIN. A menudo parece otro lenguaje porque lo es, consumido por una utilidad, herramienta de base de datos, compilador o programa interno.

Un procedimiento crea dos espacios de nombres. El trabajo llamante tiene un paso exterior y el procedimiento, pasos interiores. Mensajes, sustituciones y sintaxis de reinicio pueden usar nombres cualificados. Al aplanar el trabajo, asigna a cada paso un nombre como SORT.COPY y conserva a su lado el procedimiento original. De otro modo, dos procedimientos con STEP1 parecerán el mismo paso.

Los programas también pueden asignar datos dinámicamente mediante SVC 99 o una biblioteca. Esas asignaciones no aparecen como DD en el JCL presentado. Si un programa abre un conjunto que no puedes justificar, inspecciona sus mensajes, trazas de asignación, código o configuración antes de concluir que falta un DD. JCL declara gran parte del entorno, no necesariamente todo.

Las sentencias DD vinculan nombres del programa con recursos

Una sentencia DD pertenece al EXEC anterior hasta que empieza otro EXEC. El nombre izquierdo suele ser el que abre el programa; los operandos describen el recurso y su ciclo de vida. Lee //INPUT DD DSN=APP.CUST.MASTER,DISP=SHR así: para este paso, vincula el nombre INPUT del programa con ese conjunto catalogado y espera acceso compartido. INPUT no es una variable persistente. Otro paso puede definir su propio INPUT con significado distinto.

Clasifica cada DD en cinco grupos prácticos: conjunto catalogado, conjunto nuevo, conjunto temporal, datos en línea o salida del sistema. DSN= identifica un conjunto. DD * y DD DATA introducen registros incluidos en el trabajo. SYSOUT=* envía la salida a la clase del trabajo. DUMMY hace que muchos métodos de acceso se comporten como si la entrada estuviera vacía o la salida se descartara. La ausencia de un DD puede ser intencionada si el programa lo asigna dinámicamente o lo considera opcional; confirma el contrato.

DISP tiene hasta tres partes: estado al empezar, acción tras terminación normal y acción tras terminación anómala. DISP=(NEW,CATLG,DELETE) solicita un conjunto nuevo, lo cataloga tras terminar normalmente y lo borra después de una terminación anómala. DISP=SHR pide acceso compartido a uno existente. OLD suele pedir control exclusivo, mientras MOD posiciona para ampliar y tiene reglas de creación que conviene revisar en el manual de IBM. DISP describe asignación y disposición, no éxito de negocio. Un programa puede devolver 8 normalmente y aun así aplicar la acción normal porque no hizo abend.

Los nombres temporales empiezan por && y normalmente viven durante el trabajo. Pasar uno del productor al consumidor crea una arista de datos clara aunque el catálogo nunca lo vea. En cambio, dos DSN permanentes de nombres parecidos no prueban una relación. El planificador puede suministrar ambos o un trabajo anterior puede haber creado la entrada.

La concatenación es otra trampa visual. Varias DD consecutivas pueden formar una única entrada lógica cuando las posteriores omiten el ddname. Las bibliotecas de una STEPLIB o JOBLIB se buscan en orden, por lo que gana el primer módulo coincidente. Las entradas concatenadas se presentan en secuencia, pero su compatibilidad depende del método de acceso y los atributos. Regístralas como una vinculación ordenada.

Las sustituciones pueden reemplazar o añadir DD dentro de un procedimiento. //SORT.COPYIN DD DSN=APP.SPECIAL.INPUT,DISP=SHR puede dirigirse a COPYIN del paso COPY bajo el paso llamante SORT. Entonces el procedimiento por sí solo describe mal la ejecución y el miembro llamante parece contener un DD huérfano. Solo la expansión ofrece una vista honesta.

La referencia z/OS JCL de IBM define operandos, pero no si tu programa exige un ddname ni qué registros necesita SYSIN. Para eso busca la documentación de interfaz o estudia su OPEN y asignación dinámica. JCL explica la vinculación; el programa, el contrato. Mezclarlos produce migraciones que conservan nombres de archivo y rompen comportamiento.

La expansión de procedimientos revela el código que falta

No puedes determinar el orden hasta expandir cada procedimiento y grupo INCLUDE con las mismas bibliotecas y símbolos usados en la ejecución. Un procedimiento catalogado es JCL reutilizable almacenado en una biblioteca. Uno en línea aparece entre PROC y PEND. Ambos pueden contener EXEC, DD, parámetros simbólicos y llamadas anidadas dentro de los límites del sistema.

El listado expandido de JES suele ser mejor prueba que una búsqueda en el repositorio porque registra lo que produjo la conversión de ese envío. Busca el listado JCL, normalmente JESJCL, y los mensajes de JESYSMSG y JESMSGLG. La personalización local cambia retención y presentación. Si el listado y Git discrepan, comprueba primero si el planificador envió un miembro generado o seleccionó otra PROCLIB.

Los parámetros simbólicos usan formas como &INDSN.. El punto puede cerrar el nombre y desaparecer al sustituir. Los valores predeterminados están en PROC, el llamante los cambia en EXEC, SET asigna valores y el planificador puede sustituir variables antes de que JES lea el resultado. Conserva expresión y valor resuelto. Solo el valor impide predecir el siguiente trabajo; solo la fuente impide explicar el observado.

JCLLIB y las concatenaciones locales controlan la búsqueda. Dos bibliotecas pueden contener un miembro del mismo nombre; su orden decide cuál se expande. Es la versión de una dependencia codificada en el orden de bibliotecas, no en un manifiesto. Registra nombre, biblioteca, nivel de cambio disponible y sentencias expandidas.

Las sustituciones se aplican después de definir el procedimiento reutilizable. Pueden cambiar parámetros EXEC, reemplazar o anular DD y añadir vínculos. Una sintaxis breve puede esconder un cambio de comportamiento grande. Marca cada campo sustituido en el grafo aplanado y cita ambas ubicaciones.

No pegues manualmente el procedimiento en el trabajo y des por terminada la investigación. Es fácil perder llamadas anidadas, límites simbólicos, precedencia de bibliotecas y sustituciones. Usa la salida de conversión de una ejecución registrada como base y reconstruye cómo se obtuvo. Muchas instalaciones usan TYPRUN=SCAN para validar sintaxis, pero sus efectos dependen de la política JES local. Un scan no prueba los datos ni el comportamiento posterior.

Los nombres GDG se resuelven contra un catálogo cambiante

Un generation data group es una entrada de catálogo que gestiona una secuencia de conjuntos de generaciones. Una base como APP.BILL.WORK puede referenciarse con nombre absoluto o número relativo: (0) para la generación actual, (-1) para la anterior y habitualmente (+1) para una nueva. La forma relativa resulta cómoda en operación e incompleta en análisis, porque el nombre físico depende del estado del catálogo.

Cuando un paso crea APP.BILL.WORK(+1) con NEW y pasos posteriores leen esa misma generación relativa, el trabajo puede pasarla sin fijar el nombre GxxxxVyy. El grafo debe mostrar la referencia relativa y el nombre absoluto observado. Nunca sustituyas todas las referencias por lo que (0) significa hoy. El catálogo puede haber avanzado.

El fallo incómodo es un productor omitido o fallido seguido de un consumidor. Si EXTRACT asigna WORK(+1), termina anómalamente y se aplica DELETE, SORT no recibe una generación válida. Según sus condiciones y el momento de asignación, se omite, falla al asignar o encuentra otro estado del catálogo. Reiniciar solo SORT más tarde puede hacer que (+1) signifique una asignación nueva, no la salida pretendida. La sintaxis relativa no contiene linaje.

Otra trampa cruza trabajos. El planificador puede ejecutar JOB A para crear una generación y JOB B para consumir (0). La dependencia no aparece en ninguno. Si JOB B empieza pronto o un operador repite JOB A, (0) puede seleccionar otra generación. El plan del planificador, el historial del catálogo y las horas son parte del programa. El repositorio no demuestra qué registros leyó JOB B.

Crea un libro GDG por ejecución con paso, DD, referencia relativa, disposición, DSN absoluto resuelto, acción de catálogo y resultado observado. Complétalo con mensajes de asignación y pruebas del catálogo, no con inferencias. En un fallo registra si terminó la asignación y qué disposición se aplicó. Esto suele resolver si un reinicio reutilizará datos o creará otra generación.

La documentación de IBM distingue base GDG, modelo y límites de los conjuntos de generación individuales. Mantén esa distinción. Borrar o descatalogar una generación no cambia la base, y salir por una regla de límite no implica borrado inmediato del volumen. Para comprender el código, una referencia GDG relativa es una consulta al catálogo en el contexto de ejecución, no un archivo fijo.

Los códigos de condición suprimen pasos según resultados anteriores

Un programa que termina normalmente entrega un código de retorno, mostrado como RC o CC. JCL puede usarlo para decidir si se ejecuta un paso posterior. Un código de abend es distinto de un retorno normal, y un fallo de asignación o conversión puede impedir que exista código alguno del programa. Pon RC, abend del sistema, abend de usuario y error JCL en columnas distintas. Reducirlos a éxito o fallo destruye la información necesaria.

El antiguo parámetro COND se lee como prueba de omisión. En COND=(0,NE,SORT), el sistema compara el literal 0 con el RC de SORT usando NE. Si no son iguales, la prueba es verdadera y se omite el paso actual. En palabras corrientes, LOAD solo corre cuando SORT devuelve 0. Muchos invierten el sentido porque leen COND como condición para ejecutar. Anota omitir cuando y luego traduce la comparación.

Varios ejemplos aclaran la inversión:

• COND=(4,LT,COMPILE) significa omitir cuando 4 es menor que el RC de COMPILE, así que valores superiores a 4 suprimen el paso.
• COND=(0,EQ,CHECK) significa omitir cuando CHECK devolvió 0.
• COND=EVEN permite considerar el paso aunque uno anterior hiciera abend, sujeto a las demás reglas.
• COND=ONLY ejecuta el paso solo tras un abend anterior, también según el contexto completo.

JCL moderno admite IF, THEN, ELSE y ENDIF, que se leen más cerca de la lógica de aplicación. Las expresiones pueden consultar códigos cualificados y estado de abend. Sigue siendo control alrededor de pasos, no dentro de los programas. La anidación y cualificación pueden extender un bloque más allá de la pantalla; marca los límites en el esquema expandido.

COND de trabajo y de paso interactúan con fallos, y un procedimiento puede definir condiciones que sustituye el llamante. No las reduzcas a una flecha verde. Para cada paso escribe una expresión de elegibilidad basada en resultados anteriores y evalúala con la ejecución real. Así separas qué rutas son posibles de cuál ocurrió.

El programa define el significado del retorno. RC 4 suele ser advertencia en utilidades IBM, pero un programa interno puede darle otro sentido. Algunos planificadores aceptan un rango como éxito aunque JCL distinga 0 de 4. Captura tres políticas: lo que informa el programa, lo que JCL omite y lo que el planificador clasifica como éxito. Un único indicador no representa las tres.

Un reinicio cambia el comienzo sin cambiar el miembro

Un trabajo reiniciado no siempre empieza por su primer EXEC. El reinicio puede nombrar un paso del trabajo o uno interno de un procedimiento, y una herramienta local o el planificador puede generar la solicitud efectiva. El miembro puede ser idéntico mientras la ejecución comienza en medio. Todo diagrama sin identidad de ejecución y metadatos de reinicio es provisional.

La seguridad del reinicio depende del estado de datos, no solo del orden. Los pasos anteriores pueden haber catalogado salidas, actualizado una base, impreso registros, enviado mensajes o confirmado checkpoints. Empezar en STEP5 no revierte nada. A su vez, DISP anormal puede haber borrado un conjunto que STEP5 necesita. Antes de aprobar, enumera cada efecto anterior y cada entrada requerida.

Un reinicio desde checkpoint dentro del programa difiere del reinicio de paso JCL. Una utilidad puede continuar dentro de un paso, mientras JES vuelve a entrar en una frontera EXEC. Las pruebas y reglas de recuperación cambian. Si alguien dice que reinició el trabajo, pide mecanismo, destino e identificadores exactos.

Los planificadores añaden otra capa invisible. Calculan fechas, eligen miembros, inyectan SET, agregan dependencias, retienen trabajos por recursos y clasifican retornos. Nada tiene por qué aparecer en el JCL guardado. Un trabajo anterior puede producir el DSN leído por el primer paso visible. Una regla de calendario puede elegir otro procedimiento al cierre de mes. Obtén definición y registro de envío del planificador junto al spool.

El estado externo cambia incluso una repetición limpia. La generación GDG puede avanzar, los archivos sustituirse, las tablas cambiar y el orden de bibliotecas exponer una versión nueva. Una repetición prueba comportamiento actual bajo estado actual. No reproduce la ejecución original sin conservar entradas, asignaciones de catálogo, binarios, símbolos y controles.

Los operadores también emiten mandatos y responden a solicitudes de asignación o dispositivo. Esas acciones rara vez están en el repositorio. El registro del trabajo, los logs de automatización y el ticket pueden contener la arista ausente. Si un paso esperó una cinta o se canceló por tiempo, el código fuente no explica la duración ni el estado final.

El spool es evidencia, no ruido

La forma más rápida de comprender un batch heredado es combinar el código con un spool exitoso y otro fallo representativo. El código muestra posibilidades previstas. El spool muestra conversión, asignación, mensajes, retornos y la ruta de un envío real. Ninguno sustituye al otro.

Empieza por nombre, job ID, sistema, hora de envío, orden o run ID del planificador y si fue original o reinicio. Después reúne listado JCL convertido, mensajes JES, mensajes del sistema y SYSOUT de aplicación. JESJCL, JESMSGLG y JESYSMSG son nombres comunes, pero la política local cambia. Conserva el material antes de que la retención lo elimine.

Lee cronológicamente y etiqueta fases. Los mensajes del conversor explican símbolos y sintaxis. Los de asignación relacionan DD con conjuntos y volúmenes. Los de terminación indican programa, retorno y abend. Los de aplicación explican conteos y decisiones. Una marca de tiempo puede engañar por el búfer, así que usa también identidad de paso y mensaje.

Para cada paso expandido registra una fila observada:

SORT.COPY | PGM=SORT | ran=yes | RC=0004 | abend=none
  COPYIN  -> APP.BILL.WORK.G0123V00      DISP=SHR
  COPYOUT -> APP.BILL.SORTED.G0098V00   DISP=(NEW,CATLG,DELETE)
  gate    -> eligible after EXTRACT RC=0000

El formato es aburrido a propósito. Se puede comparar y obliga a mostrar incógnitas. Si falta el DSN absoluto, escribe desconocido e identifica la prueba necesaria. No sustituyas en silencio el valor actual del catálogo.

Compara éxito y fallo por nombre expandido, programa, DSN resueltos, símbolos, condiciones y resultados. La primera diferencia suele importar más que el abend final. Otra generación de entrada puede causar una validación posterior; una STEPLIB cambiada puede cargar código distinto; un RC de advertencia puede omitir limpieza y contaminar el siguiente ciclo.

Elimina credenciales y datos regulados antes de mover spool a sistemas generales de ingeniería. JCL y SYSOUT pueden contener campos de cuenta, tokens en PARM, control de base de datos o registros completos. Trata el spool como evidencia de producción. En una revisión aislada, conserva pruebas y herramientas dentro del perímetro del cliente.

Una tabla de traza convierte la arqueología en trabajo revisable

La tabla debe permitir que otro ingeniero cuestione el modelo sin releer todo el spool. Usa una fila por EXEC expandido, en orden efectivo. Las columnas mínimas son nombre cualificado, programa, origen del procedimiento, símbolos resueltos, DD de entrada y salida, regla de elegibilidad, RC o abend observado e implicaciones de reinicio. Añade asignaciones dinámicas.

Sigue esta secuencia:

1. Congela fuente, registro del planificador, JCL expandido, spool y asignaciones de catálogo de una ejecución bajo un run ID común.
2. Expande procedimientos e INCLUDE, resuelve símbolos y asigna a cada EXEC un nombre cualificado.
3. Adjunta vínculos DD y concatenaciones y resuelve GDG a los nombres absolutos observados.
4. Traduce cada COND o IF a una regla de elegibilidad y evalúala con resultados registrados.
5. Marca inicio real, pasos omitidos, asignaciones dinámicas, acciones de operador y efectos relevantes para reiniciar.

Revisa la tabla en dos sentidos. De arriba abajo confirma control; siguiendo cada conjunto desde productor a consumidores confirma linaje. Un archivo sin productor puede ser entrada externa, dependencia del planificador o estado antiguo. Una salida sin consumidor puede ser informe, intercambio o trabajo muerto. No la borres sin entender operación y retención.

Separa hechos de hipótesis. SORT.COPY returned 4 es un hecho del spool. RC 4 means duplicate records es hipótesis hasta que los controles y mensajes de SORT lo demuestren. Que APP.BILL.WORK(+1) resolviera G0123V00 es evidencia histórica. Que lo haga al reiniciar es una predicción que requiere análisis de catálogo y reinicio. Esta disciplina impide que un relato plausible se vuelva especificación.

La tabla también muestra el límite de migración. Programas, condiciones JCL, dependencias del planificador, catálogo y acciones de operadores forman juntos el sistema batch. Traducir COBOL ignorando JCL conserva solo lo visible. Un servicio moderno necesita orquestación explícita, identidad duradera de datos, reglas de reintento y resultados observables que coincidan donde importa.

CodeHero lee juntos todo el árbol COBOL y JCL y comprueba el sistema reescrito contra tráfico de producción registrado mediante un arnés de paridad. Una migración línea por línea no recupera comportamiento alojado en selección de procedimientos, vínculos DD, estado GDG o prácticas de reinicio.

La modernización debe hacer explícito el orden oculto

La modernización más segura no reproduce cada sentencia JCL con sintaxis nueva. Conserva comportamiento observable y convierte dependencias implícitas en contratos nombrados y comprobables. Un conjunto temporal puede pasar a objeto o tabla de preparación, una entrega GDG a artefacto inmutable de ejecución y una condición COND a transición explícita. El diseño puede cambiar, pero las pruebas de paridad deben cubrir el comportamiento del que dependen consumidores y operadores.

Empieza la especificación con ejecuciones registradas, no con un diagrama de memoria. Selecciona rutas normales, advertencias, fallos de productor, fallos de asignación y reinicios. Captura identidad de entradas, pasos expandidos, salidas, clases de retorno y efectos externos. El tráfico de producción ayuda si incluye mensajes e intercambios que definen comportamiento, siempre bajo las restricciones de seguridad del cliente.

No codifiques peculiaridades accidentales a ciegas. Cierto comportamiento es contractual, otro es soporte operativo y otro es un defecto que nadie veía. Pregunta qué consumidores dependen de cada detalle y escribe una prueba que nombre la decisión. Si el sistema nuevo cambia una regla a propósito, registra la diferencia aprobada en vez de debilitar la comparación.

La ejecución aislada puede ser necesaria si fuente, spool o registros no pueden salir del perímetro del cliente. Ese requisito trata de despliegue y datos; no implica una certificación de cumplimiento. Separa ambas afirmaciones en revisiones y compras.

Un plan de transición creíble responde preguntas concretas: qué operación nueva corresponde a cada paso, cómo se fija la identidad de entrada, cómo evitan los reintentos efectos duplicados, cómo se mapean advertencias, cómo continúa una ejecución parcial y qué evidencia prueba paridad. Si el equipo no puede responder, no ha terminado de leer JCL. Más sintaxis no cerrará el hueco. Reconstruye por completo una ejecución, incluido todo lo que el miembro omitió, y el batch dejará de parecer misterioso.