As dependências JCL vão além do JCL

Um mapa de dependências do batch noturno costuma errar de uma forma específica: registra a ordem planejada e perde as relações de dados que o sistema realmente usa. O job que lê um registro às 02:00 pode não ter um predecessor explícito ligado ao job que o escreveu. A conexão pode estar em um procedimento catalogado, parâmetro simbólico, recurso do agendador, GDG, commit de banco ou arquivo renomeado por outro job.

Já vi equipes passarem dias lendo JCL e ainda apontarem o produtor errado. O JCL mostra o que um job submetido pode abrir. O agendador explica por que ele estava apto a rodar naquela noite. A evidência de produção mostra o que fez, com quais nomes resolvidos e quando. São necessárias as três visões, unidas por identidades estáveis e tempo. Ninguém conhece o grafo inteiro porque nenhuma pessoa ou camada de controle jamais precisou representá-lo por completo.

Uma dependência é um fato de dados, não uma seta

A definição útil é estrita: B depende de A quando B consome um estado produzido por A, ou quando A muda uma condição que controla a execução correta de B. Uma seta de predecessor pode impor essa relação, mas ela é apenas uma regra de ordem. Agendadores também guardam ordens operacionais sem relação com dados, como reter um relatório até terminar o backup. Por outro lado, dois jobs podem trocar dados sem ligação direta.

Separe quatro tipos de aresta. Uma aresta de dados une escritor e leitor por dataset, geração GDG, tabela, mensagem ou registro de controle. Uma de controle liga um job a código de retorno, evento, recurso ou gatilho. Uma de ordem registra um predecessor. Uma inferida indica uma relação plausível ainda sem prova. Se todas virarem a mesma seta, toda investigação termina discutindo o significado dela.

Registre o objeto em cada aresta de dados. PAYM020 não depende apenas de PAYM010: lê PROD.PAYMENTS.CLEARED.G0123V00, fechado com sucesso por PAYM010 às 01:47:12. Essa afirmação pode ser verificada. Uma seta entre jobs não explica se a relação usa a geração atual, a de ontem, uma tabela compartilhada ou uma liberação manual.

A distinção importa durante uma falha. Se A termina com código 0, mas grava um arquivo vazio, a ordem foi satisfeita e o contrato de dados foi quebrado. Se um operador repete A depois de B, o histórico pode mostrar uma sequência válida embora B tenha consumido a geração anterior. Sucesso do agendamento e correção dos dados são perguntas separadas.

Use um registro de aresta que aceite auditoria:

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

O formato de armazenamento pouco importa. A separação entre objeto, tempo, tipo de aresta, evidência e confiança importa muito.

Comece pelo leitor das 02:00 e resolva a execução

Comece pela instância consumidora, não por um nome copiado de um diagrama. Você precisa do nome, ID JES, ocorrência ou número de execução, início real, sistema e data de negócio processada. Perto da meia-noite, em feriados e reexecuções, a data do batch costuma diferir da data civil. Sem uma identidade de ocorrência, duas execuções do mesmo job se misturam.

Recupere o JCL submetido ou expandido dessa ocorrência, se a saída retida permitir. O JCL fonte de uma biblioteca é evidência mais fraca, pois o procedimento ou uma variável pode ter mudado depois. Expanda procedimentos catalogados e internos, aplique valores SET, resolva símbolos e capture sobrescritas em EXEC e DD. Inclua datasets alocados dinamicamente relatados pelo programa ou rastreamento; eles não aparecem nos DDs da fonte.

Um exemplo pequeno mostra por que ler apenas o membro falha:

//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

O catálogo resolve (+0) na alocação, não quando alguém abre o membro depois. Após criar outra geração, o (+0) atual pode nomear um objeto diferente daquele lido às 02:00. Guarde a expressão relativa e o nome absoluto GnnnnVnn observado para a ocorrência. Faça o mesmo com datas: &BDATE só dá linhagem quando seu valor resolvido é registrado.

Classifique cada entrada. Datasets sequenciais, GDGs, clusters VSAM, temporários dentro do job, arquivos UNIX, tabelas e arquivos de controle pedem métodos de rastreamento diferentes. DISP=SHR sugere entrada, mas não prova leitura; às vezes um programa lê um DD com nome de saída. Evidência de acesso supera convenção de nomes.

Para o registro lido às 02:00, rastreie o arquivo ou objeto de banco que o contém. Não procure primeiro o valor em todo o ambiente: valores se repetem, formatos mudam e dados pessoais criam riscos. Determine objeto, membro, partição ou tabela e a hora do acesso; depois procure escritores para trás.

JCL expandido oferece candidatos, não produtores

A análise estática deve produzir rapidamente um grafo candidato, mas não atribuir a autoria final. Separe cada job em passos e DDs. Normalize nomes somente depois de preservar a expressão original. Registre programa, origem do procedimento, disposição, referência de geração, posição em concatenação e símbolos. Uma concatenação pode tornar a linhagem condicional: hoje o membro vem da primeira biblioteca, depois de uma implantação pode vir da terceira.

A disposição dá pistas. DISP=NEW com catalogação no fim normal sugere criação. DISP=MOD pode acrescentar ou criar. DISP=OLD dá exclusividade sem dizer se o programa lê, substitui ou atualiza. DISP=SHR permite compartilhamento e aparece em leitores e escritores. São rótulos candidatos, nunca prova do modo de abertura.

Datasets temporários criam arestas entre passos. Um &&WORK transmitido pode explicar o registro antes de surgir uma saída permanente. Dê a ele uma identidade limitada à ocorrência, como ID do job mais identificador da alocação DD. Não reúna todos os &&TEMP do ambiente em um objeto.

Examine também utilitários e programas chamados. SORT pode criar o arquivo em um passo chamado COPY. IDCAMS pode alterar um VSAM citado nas instruções de controle. COBOL pode montar um nome e pedir alocação dinâmica. Uma atualização pode ocorrer por trás de um plano genérico ou stored procedure. Marque esses efeitos como não resolvidos e leve-os à fonte correta. Adivinhar pelo nome do passo cria linhagem falsa.

Um analisador útil emite candidatos assim:

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

Agora resolva gerações por ocorrência. Se PAYM010 cria e cataloga G0123V00 antes de PAYM020 alocar (+0), as duas expressões apontam para o mesmo objeto. Se a alocação ocorreu antes da mudança do catálogo, não. A sequência isolada não resolve, pois horários de alocação e abertura importam.

O agendador explica a liberação e as barreiras ocultas

Exporte definições e histórico de ocorrências para a mesma data de negócio. As definições mostram predecessores, calendários, ciclos, recursos, eventos, condições de chegada, testes de retorno e tabelas de variáveis. O histórico mostra quais regras valeram e quais jobs foram omitidos, adicionados, retidos, forçados, repetidos ou liberados manualmente. Você precisa dos dois. Uma definição limpa pode descrever uma noite que nunca aconteceu.

Recursos do agendador muitas vezes escondem a ligação. Um produtor pode ativar FILE.CLEARED.READY, enquanto o consumidor espera esse recurso sem nomear o produtor. Outro job pode ativá-lo na recuperação. Modele o recurso como nó: o produtor o ativa e o recurso libera o consumidor. Uma aresta direta esconde o escritor alternativo e a ação do operador.

Calendários criam grafos condicionais. O produtor do fechamento pode rodar apenas no último dia bancário, enquanto o consumidor roda diariamente e usa o arquivo anterior nos demais dias. Um diagrama universal não representa isso com honestidade. Anexe calendário de negócio, data da aplicação e tipo de execução à aresta. Gere um grafo para uma ocorrência ou cenário nomeado.

A lógica dos códigos de retorno exige o mesmo cuidado. Um consumidor pode rodar após um aviso, mas ler um dataset alternativo. Outro passo pode depender de um código específico. Preserve condições no nível do job e do passo. depois de PAYM010 diz menos que liberado quando PAYM010 termina com RC <= 4 e FILE.CLEARED.READY existe.

Ações manuais pertencem ao grafo porque mudam a causalidade. Se a política permitir, registre operador, horário, estado anterior e novo e motivo. Um predecessor forçado a concluído não produziu dados. Apenas fez o agendador agir como se o requisito estivesse atendido. Essa diferença explica rapidamente uma leitura de dados antigos.

Não trate o banco do agendador como catálogo de dados. Ele responde por que o trabalho rodou, não quais bytes consumiu. Sua maior contribuição é um relato com horários de liberações, exceções e intervenção humana.

Rastros de produção decidem quem realmente escreveu

Evidência de produção transforma arestas possíveis em observadas. No z/OS, una tempos de job e passo com atividade de datasets, saída JES, catálogo, mensagens de utilitários, logs de aplicação e auditoria ou logs de banco disponíveis. A documentação SMF da IBM separa contabilidade de jobs e atividade de datasets porque nenhum tipo oferece sozinho uma linhagem completa. O tipo 30 ancora execuções; os tipos 14 e 15 podem mostrar fechamentos de datasets não VSAM quando a gravação está ativa. VSAM e bancos exigem registros próprios.

A ressalva é importante. Ausência de registro SMF não prova ausência de acesso. Opções de gravação, método, buffers, subsistema e retenção podem retirar a evidência esperada. Marque não observado, não não aconteceu, salvo se os controles sustentarem a afirmação mais forte.

Para um dataset sequencial, trabalhe para trás a partir do consumidor:

1. Resolva a ocorrência e o nome absoluto.
2. Encontre leituras observadas desse job e passo.
3. Procure escritas anteriores do nome exato.
4. Una escritores candidatos aos tempos do tipo 30 e à saída JES.
5. Verifique catálogo e agendador perto de repetições e liberações manuais.

Suponha que PAYM020 leia G0123V00 às 02:00. O agendador diz que PAYM010 terminou à 01:48 e o SMF mostra que fechou o objeto à 01:47. Uma recuperação o abriu para saída à 01:55 e fechou à 01:58. O predecessor não foi o último escritor. O grafo precisa das duas escritas, e a aresta do consumidor deve apontar para o estado posterior à recuperação. Ao atualizar um objeto existente, a identidade não basta; o tempo separa os estados.

Registros de banco exigem outra junção. Identifique tabela e chave de negócio e use logs, auditoria, commits, IDs de correlação, planos ou pacotes e contexto do job. O escritor é a transação que confirmou a versão visível, não o batch que começou primeiro. O isolamento também determina qual versão o leitor podia ver. Se a telemetria não liga transação e ocorrência, diga isso e mantenha um conjunto limitado de candidatos.

Tempo e identidade evitam junções falsas

A maioria dos grafos errados une nomes sem intervalos. Nomes de jobs se repetem, datasets são reutilizados, uma referência GDG relativa muda, uma ocorrência pode ser reconstruída e uma linha tem versões sucessivas. Modele eventos primeiro e derive arestas entre estados observados em momentos específicos.

Use uma linha do tempo comum, de preferência UTC mais horário local e fuso originais. Os relógios do mainframe, agendador, banco e logs distribuídos podem divergir. Meça os desvios ou preserve uma janela de incerteza. Não invente ordem exata entre eventos dentro dela. Um fechamento às 01:59:59,8 e uma abertura às 02:00:00,1 parecem ordenados até surgir um desvio de dois segundos.

A identidade deve incluir sistema e ocorrência. Uma chave prática combina aplicação e ocorrência do agendador, nome, ID JES, sistema e início. Para um passo, acrescente nome e sequência, pois a expansão pode repetir nomes. Para o estado de um dataset, use nome absoluto, contexto de volume ou catálogo quando necessário e intervalo de escrita.

Atribua confiança conforme a evidência. Observado significa que a telemetria registra o acesso. Corroborado, que fontes independentes concordam. Declarado, que somente uma regra aponta a aresta. Inferido, que convenção ou proximidade a sugere. Conflitante, que as fontes discordam. Esses rótulos evitam fingir que todas as arestas têm a mesma força.

Descreva também achados negativos com precisão. Nenhum escritor encontrado no SMF retido entre 00:00 e 02:00; gravação ativa nos sistemas relevantes; estado anterior não examinado é útil. Produtor desconhecido perde o limite da busca. A evidência tem escopo, e o grafo deve mantê-lo.

Reexecuções revelam o grafo nunca documentado

Reexecuções quebram mapas nominais. O agendador pode criar uma ocorrência, reiniciar em um passo posterior ou repetir o nome com novo ID JES. O job pode reutilizar um GDG, criar outra geração, acrescentar a um dataset fixo ou corrigir só linhas com falha. Modele cada execução e escrita como evento. Nunca sobrescreva a primeira execução com a recuperação.

Falha comum: o produtor cria G0123V00 e termina com RC 8 após a escrita, mas antes de ativar o recurso. Um operador examina o arquivo, força o fim e libera o consumidor. Depois uma recuperação corrige vários registros no lugar. O consumidor começa entre as ações. O grafo de definição diz falha seguida de recuperação; o grafo de dados diz que o consumidor leu o arquivo original antes da correção. Ambos são verdadeiros.

Testes de existência de arquivo são barreiras fracas. Um arquivo fixo antigo os satisfaz. (+0) pode resolver a última geração catalogada embora o produtor de hoje não tenha rodado. Código 0 pode acompanhar uma extração vazia. Ligue prontidão à data de negócio e à versão e verifique o contrato de conteúdo. Um pequeno controle com data, ocorrência, contagem e status final torna o vínculo explícito se for gravado só depois do commit ou fechamento correto.

Não acrescente uma seta para toda aresta observada. Alguns dados são compartilhados de propósito, e um predecessor direto pode serializar trabalhos independentes ou criar ciclos. Acrescente ordem quando a correção exigir. Para outras arestas, monitoramento de atualidade ou versão expressa melhor o contrato. O conselho popular de adicionar predecessores até o desenho combinar com a produção confunde documentação com política de execução.

Testes de reexecução devem cobrir saída parcial, reinício depois do passo escritor, geração duplicada, fim forçado, escritor tardio de recuperação e consumidor durante a correção. Se o grafo não descreve esses estados, ele mostra apenas a noite sem falhas.

Monte um livro de evidências antes do grafo

O grafo é uma visão das evidências, não o registro principal. Guarde observações e declarações em um livro somente de acréscimo e derive o grafo para uma data ou incidente. Assim uma conclusão pode ser corrigida sem apagar a anterior, e cada aresta pode ser seguida até a fonte.

Cada entrada precisa de fonte, horário de coleta, horário do evento, sistema, identidades de ocorrência e objeto, ação, atributos resolvidos e referência de retenção. Mantenha a evidência bruta sob os controles existentes; o repositório de linhagem pode guardar referência e campos não sensíveis. Nomes e metadados podem revelar funções de negócio, portanto o mapa não é inofensivo.

Use uma consulta de reconciliação que mostre divergências: predecessor declarado sem objeto compartilhado observado, par escritor-leitor sem controle, GDG relativo não resolvido ou abertura do consumidor anterior ao fechamento escolhido dentro da incerteza do relógio. São filas de análise para um engenheiro, não defeitos provados automaticamente.

A responsabilidade fica administrável quando se liga a domínios de evidência. Administradores extraem definições; equipes de armazenamento ou plataforma coletam catálogo e SMF; aplicações explicam alocação dinâmica e semântica; bancos rastreiam versões confirmadas. Ninguém precisa conhecer todo o grafo: o livro precisa de interfaces estáveis entre as evidências.

Defina a retenção pelo horizonte de investigação. Se o histórico do agendador durar mais que a atividade de datasets, um incidente antigo parecerá ter apenas ordem. Se o JCL expandido sumir antes do próximo fechamento, resolver símbolos vira adivinhação. Registre o primeiro horário disponível por fonte para mostrar a queda da confiança.

CodeHero lê em paralelo toda a árvore legada, incluindo COBOL e JCL, e pode usar tráfego de produção gravado em um harness de paridade durante a reescrita. Assim o grafo candidato e o comportamento observado ficam como evidências separadas até concordarem.

Um mapa confiável muda a substituição do batch

Quando o livro responde quem escreveu o estado lido às 02:00, use-o para definir limites de migração. Agrupe jobs por contratos de dados e transações, não por pasta ou prefixo. Produtor e consumidor podem pertencer ao mesmo corte embora tenham donos diferentes. Dois jobs vizinhos podem ficar separados se compartilham apenas uma janela operacional.

Transforme cada aresta observada em uma asserção de paridade. Com o mesmo estado de entrada gravado, a substituição deve produzir os mesmos registros externos, mudanças no banco, condições de retorno e sinais de prontidão. Normalize campos intencionalmente variáveis, como IDs e horários, documentando cada regra. Um harness que ignora ordem, saída vazia e recuperação aprova a noite fácil e falha no incidente.

Mantenha a observação do legado durante ensaios de virada. Um serviço novo pode publicar uma transação Postgres onde o batch catalogava um dataset e ativava um recurso. A implementação muda, mas o contrato mantém estado produtor, ponto de visibilidade, consumidor e data de negócio. Relacione a evidência antiga ao contrato novo, em vez de copiar setas para um diagrama de serviços.

O primeiro resultado deve ser estreito: uma ocorrência consumidora, todas as entradas realmente abertas e o último escritor de cada estado visível. Inclua candidatos não resolvidos e lacunas de evidência. Revise com operações durante uma noite com reexecução, não apenas diante de um calendário limpo. Depois amplie seguindo os objetos observados.

O processo de revisão precisa de critérios próprios. Para cada aresta observada, um revisor deve conseguir abrir a evidência retida, identificar as duas ocorrências, resolver o objeto e reproduzir a ordem temporal sem depender de convenção oral. Para cada aresta declarada sem observação, o registro deve dizer se faltou telemetria, o caminho estava inativo naquela data ou a declaração parece antiga. O grafo pode conter incerteza, mas não esconder sua causa.

Recalcule a visão quando mudarem definições, procedimentos, lógica de alocação ou ajustes de coleta. Não reconstrua todas as arestas por calendário. Invalide apenas as relações candidatas afetadas e espere a próxima ocorrência adequada para confirmá-las. Assim uma mudança não faz todo o grafo parecer recém-descoberto, e o histórico ainda explica a diferença entre ontem e hoje.

Adicione verificações nos limites da coleta de evidências. Rejeite um acesso sem fonte de relógio. Isole um nome GDG absoluto que contradiga o snapshot do catálogo. Avise quando duas ocorrências alegarem o mesmo ID JES no mesmo sistema e em tempos sobrepostos. Sinalize um objeto marcado como novo sem fechamento ou commit antes do início do consumidor. Essas verificações não decidem correção de negócio, mas impedem que evidência malformada vire uma dependência segura.

Meça o mapa pelas perguntas que responde, não pela quantidade de nós. Use incidentes passados e pergunte qual estado cada consumidor viu, por que foi liberado, qual ação manual mudou a rota e qual fonte prova cada resposta. Inclua uma noite limpa, uma entrada atrasada, reinício a partir de um passo posterior e escrita de recuperação após o produtor nominal. Se um engenheiro ainda precisa procurar no spool, o livro tem uma lacuna nomeada. Um grafo grande e vago ajuda menos que um menor com afirmações reproduzíveis.

O grafo útil nunca será um pôster sem tempo. É uma consulta sobre evidência versionada: mostra o plano declarado, o que aconteceu em uma noite e as diferenças. Quando alguém perguntar quem escreveu o registro lido às 02:00, a resposta deve nomear ocorrência, versão, horário de visibilidade e registros que provam. O restante ainda é suposição.