Las dependencias JCL van más allá del JCL

Un mapa de dependencias del batch nocturno suele equivocarse de una forma concreta: registra el orden previsto y omite las relaciones de datos que el sistema usa de verdad. El trabajo que lee un registro a las 02:00 puede no tener un predecesor explícito hacia el que lo escribió. La conexión puede ocultarse en un procedimiento catalogado, un parámetro simbólico, un recurso del planificador, un GDG, un commit de base de datos o un archivo renombrado por otro trabajo.

He visto equipos leer JCL durante días y aun así señalar al productor equivocado. El JCL dice qué puede abrir un trabajo enviado. El planificador explica por qué podía ejecutarse esa noche. Las pruebas de producción muestran qué hizo, con qué nombres resueltos y cuándo. Hacen falta las tres vistas, unidas por identidades estables y tiempo. Nadie conoce el grafo entero porque ninguna persona ni capa de control tuvo que representarlo completo.

Una dependencia es un hecho de datos, no una flecha

La definición útil es estricta: B depende de A cuando B consume un estado producido por A o cuando A cambia una condición que controla la ejecución correcta de B. Una flecha de predecesor puede imponer esa relación, pero la flecha solo es una regla de orden. Los planificadores también contienen órdenes operativos sin relación con datos, como esperar al fin de una copia de seguridad. A la inversa, dos trabajos pueden intercambiar datos sin enlace directo.

Separa cuatro tipos de arista. Una arista de datos une escritor y lector mediante dataset, generación GDG, tabla, mensaje o registro de control. Una de control conecta un trabajo con un código de retorno, evento, recurso o disparador. Una de orden registra un predecesor. Una inferida es plausible, pero aún necesita pruebas. Si todas son la misma flecha, cada investigación termina discutiendo qué significa.

Anota el objeto en cada arista de datos. PAYM020 no solo depende de PAYM010: lee PROD.PAYMENTS.CLEARED.G0123V00, que PAYM010 cerró a las 01:47:12. Esa afirmación se puede comprobar. Una flecha entre trabajos no explica si la relación usa la generación actual, la de ayer, una tabla compartida o una excepción manual.

La diferencia importa durante un fallo. Si A termina con código 0 y escribe un archivo vacío, el orden se cumple pero el contrato de datos se rompe. Si un operador repite A después de B, el historial puede mostrar una secuencia válida aunque B consumiera la generación anterior. El éxito del calendario y la corrección de los datos son preguntas distintas.

Usa un registro de arista que admita revisión:

consumer_job: PAYM020
producer_job: PAYM010
object: PROD.PAYMENTS.CLEARED.G0123V00
consumer_access: read
producer_access: create-and-close
producer_close_utc: 01:47:12
consumer_open_utc: 02:00:08
schedule_edge: none
evidence: expanded-jcl, catalog, smf
confidence: observed

El formato de almacenamiento da igual. La separación entre objeto, tiempo, tipo, prueba y confianza no.

Empieza por el lector de las 02:00 y resuelve su ejecución

Parte de la instancia consumidora, no de un nombre copiado de un diagrama. Necesitas nombre, ID JES, ocurrencia o número de ejecución, inicio real, sistema y fecha de negocio procesada. Cerca de medianoche, en festivos y repeticiones, la fecha del batch puede diferir de la fecha civil. Sin identidad de ocurrencia, se mezclan dos ejecuciones del mismo trabajo.

Recupera el JCL enviado o expandido de esa ocurrencia si se conserva. El JCL fuente de una biblioteca es una prueba más débil, pues el procedimiento o una variable pudieron cambiar. Expande procedimientos catalogados y en línea, aplica valores SET, resuelve símbolos y registra sustituciones de EXEC y DD. Incluye datasets asignados dinámicamente que aparezcan en el programa o las trazas; no estarán en los DD fuente.

Un ejemplo muestra por qué no basta con leer el miembro:

//PAYM020  JOB ...
// SET BDATE=20260813
//READ     EXEC PROC=PAYREAD,ENV=P,DAY=&BDATE
//INFILE   DD DSN=PROD.PAYMENTS.CLEARED(+0),DISP=SHR
//CTL      DD DSN=PROD.CTL.PAY.&BDATE,DISP=SHR

El catálogo resuelve (+0) al asignar, no cuando alguien abre después el miembro. Tras crear otra generación, el (+0) de hoy puede nombrar un objeto distinto del leído a las 02:00. Guarda la expresión relativa y el nombre absoluto GnnnnVnn observado para esa ocurrencia. Haz lo mismo con fechas: &BDATE no da linaje hasta registrar su valor resuelto.

Clasifica cada entrada. Datasets secuenciales, GDG, clústeres VSAM, temporales dentro del trabajo, archivos UNIX, tablas y archivos de control requieren métodos de rastreo diferentes. DISP=SHR sugiere entrada, pero no prueba una lectura; a veces un programa abre para leer un DD que parece de salida. La prueba de acceso supera a la convención del nombre.

Para el registro leído a las 02:00, rastrea el archivo u objeto de base que lo contiene. No busques primero su valor por todo el entorno: los valores se repiten, los formatos cambian y los datos personales complican el manejo. Determina objeto, miembro, partición o tabla y la hora de acceso; después busca escritores hacia atrás.

El JCL expandido ofrece candidatos, no productores

El análisis estático debe producir rápido un grafo candidato, pero no atribuir la autoría final. Divide cada trabajo en pasos y DD. Normaliza los nombres después de conservar la expresión original. Registra programa, origen del procedimiento, disposición, referencia de generación, posición en concatenación y símbolos. Una concatenación puede condicionar el linaje: hoy el miembro aparece en la primera biblioteca y tras un despliegue en la tercera.

La disposición aporta indicios. DISP=NEW y catalogación al final normal apuntan a creación. DISP=MOD puede añadir o crear. DISP=OLD da exclusividad sin decir si el programa lee, sustituye o actualiza. DISP=SHR permite compartir y aparece tanto en lectores como escritores. Son etiquetas de candidatos, no pruebas del modo de apertura.

Los datasets temporales crean aristas entre pasos. Un &&WORK transferido puede explicar el registro antes de que exista una salida permanente. Dale una identidad limitada a la ocurrencia, como ID de trabajo más identificador de asignación DD. No fusiones todos los &&TEMP del entorno.

Examina también utilidades y programas llamados. SORT puede crear el archivo bajo un paso llamado COPY. IDCAMS puede alterar un VSAM nombrado en las instrucciones de control. COBOL puede construir un nombre y asignarlo dinámicamente. Una actualización puede esconderse tras un plan genérico o procedimiento almacenado. Marca esos efectos como sin resolver y envíalos a la fuente apropiada. Adivinar por el nombre del paso crea linaje falso.

Un analizador útil emite candidatos así:

PAYM010/SORTCLR  -> may_write -> PROD.PAYMENTS.CLEARED(+1)
PAYM020/READ     -> may_read  -> PROD.PAYMENTS.CLEARED(+0)
PAYM025/ARCHIVE  -> may_read  -> PROD.PAYMENTS.CLEARED(-1)

Ahora resuelve generaciones por ocurrencia. Si PAYM010 crea y cataloga G0123V00 antes de que PAYM020 asigne (+0), ambas expresiones señalan al mismo objeto. Si la asignación fue anterior al cambio de catálogo, no. La secuencia por sí sola no basta porque importan las horas de asignación y apertura.

El planificador explica la habilitación y las barreras ocultas

Exporta definiciones e historial de ocurrencias para la misma fecha de negocio. Las definiciones muestran predecesores, calendarios, ciclos, recursos, eventos, condiciones de llegada, pruebas de retorno y tablas de variables. El historial muestra qué reglas se aplicaron y qué trabajos fueron omitidos, añadidos, retenidos, forzados, repetidos o liberados a mano. Necesitas ambos. Una definición limpia puede describir una noche que nunca ocurrió.

Los recursos suelen ocultar el vínculo. Un productor puede activar FILE.CLEARED.READY, mientras el consumidor espera ese recurso sin nombrar al productor. Otro trabajo puede activarlo durante la recuperación. Modela el recurso como nodo: el productor lo activa y el recurso libera al consumidor. Una arista directa oculta al escritor alternativo y la acción del operador.

Los calendarios crean grafos condicionales. El productor de cierre puede ejecutarse solo el último día bancario, mientras el consumidor corre a diario y usa el archivo anterior los demás días. Un diagrama universal no puede mostrarlo con honestidad. Añade calendario de negocio, fecha de aplicación y tipo de ejecución a la arista. Genera el grafo para una ocurrencia o escenario concreto.

La lógica del retorno exige el mismo cuidado. Un consumidor puede continuar tras un aviso y leer un dataset de reserva. Otro paso puede depender de un código preciso. Conserva condiciones por trabajo y paso. después de PAYM010 informa menos que habilitado cuando PAYM010 termina con RC <= 4 y existe FILE.CLEARED.READY.

Las acciones manuales pertenecen al grafo porque cambian la causalidad. Si la política lo permite, registra operador, hora, estado anterior y nuevo y motivo. Un predecesor forzado a completo no produjo datos. Solo hizo que el planificador actuara como si se hubiera cumplido el requisito. Esa diferencia explica pronto una lectura de datos obsoletos.

No trates la base del planificador como catálogo de datos. Responde por qué se ejecutó el trabajo, no qué bytes consumió. Su mayor aportación es una cuenta con horas de habilitación, excepciones e intervención humana.

Las trazas de producción deciden quién escribió

Las pruebas de producción convierten aristas posibles en observadas. En z/OS, une tiempos de trabajo y paso con actividad de datasets, salida JES, catálogo, mensajes de utilidades, logs de aplicación y auditoría o logs de base disponibles. La documentación SMF de IBM separa contabilidad de trabajos y actividad de datasets porque ningún tipo contiene todo el linaje. El tipo 30 fija ejecuciones; los tipos 14 y 15 pueden mostrar cierres de datasets no VSAM si la grabación está activa. VSAM y las bases requieren registros propios.

La salvedad importa. La ausencia de un registro SMF no prueba que no hubo acceso. Opciones de grabación, método, búferes, subsistema y retención pueden eliminar la prueba. Marca no observado, no no ocurrió, salvo que los controles permitan afirmarlo.

Para un dataset secuencial, trabaja hacia atrás desde el consumidor:

1. Resuelve la ocurrencia y el nombre absoluto.
2. Busca lecturas observadas de ese trabajo y paso.
3. Busca escrituras anteriores del nombre exacto.
4. Une escritores candidatos con tiempos tipo 30 y salida JES.
5. Revisa catálogo y planificador cerca de repeticiones y liberaciones manuales.

Supón que PAYM020 lee G0123V00 a las 02:00. El planificador dice que PAYM010 terminó a la 01:48 y SMF que cerró el objeto a la 01:47. Una recuperación lo abrió para salida a la 01:55 y lo cerró a la 01:58. El predecesor no fue el último escritor. El grafo necesita ambas escrituras y la arista del consumidor debe apuntar al estado posterior a la recuperación. Cuando se actualiza un objeto existente, la identidad no basta; el tiempo separa sus estados.

Los registros de base necesitan otra unión. Identifica tabla y clave de negocio, y usa logs, auditoría, commits, ID de correlación, planes o paquetes y contexto del trabajo. El escritor es la transacción que confirmó la versión visible, no el batch que empezó primero. El aislamiento también cambia qué versión podía verse. Si la telemetría no conecta transacción y ocurrencia, indícalo y conserva candidatos acotados.

El tiempo y la identidad evitan uniones falsas

La mayoría de los grafos erróneos unen nombres sin intervalos. Los nombres se repiten, los datasets se reutilizan, una referencia GDG relativa cambia, una ocurrencia puede reconstruirse y una fila tiene versiones sucesivas. Modela eventos primero y deriva aristas entre estados observados en momentos concretos.

Usa una cronología común, preferiblemente UTC más hora local y zona original. Los relojes del mainframe, planificador, base y sistemas distribuidos pueden diferir. Mide sus desfases o conserva una ventana de incertidumbre. No inventes orden exacto entre eventos dentro de ella. Un cierre a las 01:59:59,8 y una apertura a las 02:00:00,1 parecen ordenados hasta descubrir dos segundos de desfase.

La identidad debe incluir sistema y ocurrencia. Una clave práctica combina aplicación y ocurrencia del planificador, nombre, ID JES, sistema e inicio. Para un paso, añade nombre y secuencia porque la expansión puede repetir nombres. Para el estado de un dataset, usa nombre absoluto, contexto de volumen o catálogo si hace falta e intervalo de escritura.

Asigna confianza según pruebas. Observado significa que la telemetría registra el acceso. Corroborado, que coinciden fuentes independientes. Declarado, que solo lo dice una regla. Inferido, que lo sugieren convención o cercanía. En conflicto, que las fuentes discrepan. Así operaciones puede usar el mapa sin fingir que todas las aristas son iguales.

Describe también los hallazgos negativos con precisión. No se encontró escritor en el SMF retenido entre 00:00 y 02:00; grabación activa en los sistemas pertinentes; no se examinó el estado anterior es útil. Productor desconocido pierde el límite de búsqueda. La prueba tiene alcance y el grafo debe conservarlo.

Las repeticiones revelan el grafo no documentado

Los reruns rompen los mapas nominales. El planificador puede crear una ocurrencia, reiniciar en un paso posterior o repetir el nombre con otro ID JES. El trabajo puede reutilizar un GDG, crear una generación, añadir a un dataset fijo o corregir solo filas fallidas. Modela cada ejecución y escritura como evento. Nunca sobrescribas el primer paso con la recuperación.

Fallo habitual: el productor crea G0123V00 y termina con RC 8 después de escribir pero antes de activar el recurso. Un operador revisa el archivo, fuerza el final y libera al consumidor. Una recuperación corrige luego varios registros. El consumidor empieza entre ambas acciones. El grafo de definición dice fallo y recuperación; el de datos dice que el consumidor leyó el archivo inicial antes de corregirse. Ambos son ciertos.

Comprobar la existencia de un archivo es una barrera débil. Un archivo fijo antiguo la satisface. (+0) puede resolver la última generación catalogada aunque el productor de hoy no se ejecutara. Un código 0 puede acompañar un extracto vacío. Vincula la disponibilidad con fecha de negocio y versión, y comprueba el contrato de contenido. Un registro de control con fecha, ocurrencia, filas y estado final hace explícito el vínculo si se escribe tras un commit o cierre correcto.

No añadas una flecha por cada arista observada. Algunos datos se comparten deliberadamente y un predecesor directo puede serializar trabajo independiente o crear ciclos. Añade orden cuando la corrección lo requiera. Para otras aristas, la frescura o la versión expresan mejor el contrato. El consejo de añadir predecesores hasta que el dibujo coincida confunde documentación con política de ejecución.

Las pruebas de repetición deben cubrir salida parcial, reinicio después del paso escritor, generación duplicada, final forzado, escritor de recuperación tardío y consumidor durante la corrección. Si el grafo no describe esos estados, solo muestra la ruta feliz.

Crea un registro de pruebas antes del grafo

Un grafo es una vista de las pruebas, no el registro principal. Guarda observaciones y declaraciones en un libro de solo adición y deriva el grafo para una fecha o incidente. Así puedes corregir conclusiones sin borrar las anteriores y seguir cada arista hasta su fuente.

Cada entrada necesita fuente, hora de captura, hora del evento, sistema, identidades de ocurrencia y objeto, acción, atributos resueltos y referencia de retención. Mantén la prueba bruta bajo sus controles; el almacén de linaje puede guardar una referencia y campos no sensibles. Los nombres y metadatos también revelan funciones de negocio, así que el mapa no es inocuo.

Usa una consulta de conciliación que señale desacuerdos: predecesor declarado sin objeto compartido observado, par escritor-lector sin control, GDG relativo sin resolver o apertura anterior al cierre elegido dentro de la incertidumbre del reloj. Son colas de revisión, no defectos demostrados automáticamente.

La propiedad se vuelve manejable si se asigna por dominios de prueba. Los administradores extraen definiciones; almacenamiento o plataforma recopila catálogo y SMF; aplicaciones explican asignación dinámica y semántica; bases rastrean versiones confirmadas. Nadie necesita conocer todo el grafo: el registro necesita interfaces estables entre sus pruebas.

Define la retención según el horizonte de investigación. Si el historial del planificador dura más que la actividad de datasets, un incidente antiguo parecerá tener solo orden. Si el JCL expandido desaparece antes del siguiente cierre, resolver símbolos será adivinar. Registra la primera fecha disponible por fuente para mostrar cuándo cae la confianza.

CodeHero lee en paralelo todo el árbol heredado, incluidos COBOL y JCL, y puede usar tráfico de producción grabado en un arnés de paridad durante la reescritura. Así el grafo estático y el comportamiento observado siguen siendo pruebas separadas hasta coincidir.

Un mapa fiable cambia cómo se sustituye el batch

Cuando el registro responde quién escribió el estado leído a las 02:00, úsalo para definir límites de migración. Agrupa por contratos de datos y transacciones, no por carpeta o prefijo. Productor y consumidor pueden pertenecer al mismo corte aunque tengan dueños distintos. Dos trabajos vecinos pueden quedar separados si solo comparten una ventana operativa.

Convierte cada arista observada en una aserción de paridad. Con el mismo estado de entrada, el sustituto debe producir los mismos registros externos, cambios de base, condiciones de retorno y señales de disponibilidad. Normaliza campos intencionadamente variables como ID y horas, documentando cada regla. Un arnés que ignore orden, salidas vacías y semántica de recuperación aprobará la noche fácil y fallará durante un incidente.

Mantén la observación heredada durante los ensayos. Un servicio nuevo puede publicar una transacción Postgres donde el batch catalogaba un dataset y activaba un recurso. La implementación cambia, pero el contrato conserva estado productor, momento de visibilidad, consumidor y fecha de negocio. Relaciona las pruebas antiguas con el contrato nuevo en vez de copiar flechas a un diagrama de servicios.

El primer entregable debe ser estrecho: una ocurrencia consumidora, todas las entradas realmente abiertas y el último escritor de cada estado visible. Incluye candidatos sin resolver y huecos de prueba. Revísalo con operaciones durante una noche con repetición, no solo frente a un calendario limpio. Después amplía siguiendo objetos observados.

El proceso de revisión necesita criterios propios. Para cada arista observada, un revisor debe poder abrir la prueba retenida, identificar ambas ocurrencias, resolver el objeto y reproducir el orden temporal sin depender de una convención oral. Para cada arista declarada sin observación, el registro debe decir si faltaba telemetría, la ruta estaba inactiva en esa fecha o la declaración parece obsoleta. El grafo puede contener incertidumbre, pero no ocultar su causa.

Recalcula la vista cuando cambien definiciones, procedimientos, lógica de asignación o ajustes de captura. No reconstruyas todas las aristas por calendario. Invalida solo las relaciones candidatas afectadas y espera a la siguiente ocurrencia apta para confirmarlas. Así una modificación no hace que todo el grafo parezca recién descubierto y el historial sigue explicando por qué ayer y hoy difieren.

Añade controles en los límites de la canalización de pruebas. Rechaza un acceso sin fuente de reloj. Aísla un nombre GDG absoluto que contradiga la instantánea del catálogo. Avisa si dos ocurrencias reclaman el mismo ID JES en el mismo sistema y en tiempos solapados. Señala un objeto marcado como nuevo sin cierre ni commit antes de que empiece el consumidor. Estos controles no deciden corrección de negocio, pero impiden que evidencia mal formada se convierta en dependencia segura.

Mide el mapa por las preguntas que responde, no por sus nodos. Usa incidentes pasados y pregunta qué estado vio cada consumidor, por qué fue liberado, qué acción manual cambió la ruta y qué fuente prueba cada respuesta. Incluye una noche limpia, una entrada tardía, un reinicio desde un paso posterior y una escritura de recuperación después del productor nominal. Si un ingeniero aún debe buscar en el spool, el registro tiene un hueco concreto. Un grafo grande y vago sirve menos que uno menor con afirmaciones reproducibles.

El grafo útil nunca será un póster atemporal. Es una consulta sobre pruebas versionadas: muestra el plan declarado, lo ocurrido una noche y sus diferencias. Si alguien pregunta quién escribió el registro leído a las 02:00, la respuesta debe nombrar ocurrencia, versión, hora de visibilidad y registros que lo prueban. Lo demás sigue siendo una conjetura.