 |
| Bellacosa Mainframe fala sobre restart em programa cobol mainframe |
🔄 COBOL Batch no Mainframe: Checkpoint, Reprise e o Restart que salva a madrugada
“Batch não cai. Batch desmaia… e você tem que acordar ele do jeito certo.” ☕🧾🕒No mundo distribuído, o povo reinicia “do zero” e chama isso de solução.
No Mainframe, isso é quase uma confissão de pecado técnico.
Quando dá ruim em batch, a pergunta não é “por que parou?” — isso é assunto pro pós-mortem.
A pergunta certa, ainda na especificação, é:
👉 Como eu reinicio?
👉 De onde eu reinicio?
👉 E o que eu garanto que não vai duplicar / corromper / relançar?
Bem-vindo ao trio de respeito:
✅ checkpoint
✅ reprise (restart)
✅ reposicionamento (arquivo/DB2)
🧠 Checkpoint: o “save game” do batch (só que aqui vale dinheiro)
Checkpoint não é “vamos salvar porque sim”. É um ponto de consistência.
Ele serve pra:
memorizar onde o processamento estava (fase/etapa)
guardar posições de leitura (arquivos sequenciais, VSAM, cursores/chaves DB2)
fechar uma unidade lógica consistente (commit/rollback bem amarrado)
permitir retomada sem retrabalho e sem “efeito duplicado”
📌 Tradução Bellacosa:
Checkpoint é onde você consegue provar pro auditor que não inventou saldo no escuro.
⚠️ O pecado mortal: checkpoint mal posicionado
Checkpoint ruim é pior que nada, porque ele te dá uma falsa sensação de segurança.
Não coloque checkpoint:
no meio de uma atualização crítica
antes de terminar uma consistência lógica
em cada registro “porque sim” (CPU chorando, log estourando, IRLM te olhando feio)
Coloque checkpoint:
depois de um bloco lógico fechado (ex.: lote de N registros com commit)
quando “o mundo faz sentido” (estado consistente)
antes de uma parte custosa, mas não no meio da cirurgia
♻️ Reprise (Restart): o batch voltando “com memória”
Reprise é o batch saber voltar sem refazer o que já foi feito e sem duplicar o que não pode duplicar.
Ela é necessária especialmente quando:
o batch é longo (madrugada inteira)
tem DB2 update (conta, saldo, lançamento, baixa, contabilização)
o negócio não aceita “roda de novo e vê no que dá”
existe risco de duplicidade (dois lançamentos iguais = fogo no parquinho)
📌 Restart não é só “rodar outra vez”.
Restart é retomar a transação do negócio, com rastreabilidade.
🧷 Reposicionamento: o detalhe que separa homem de menino
Restart sem reposicionamento é “restart de brincadeira”.
Você precisa voltar exatamente:
no registro correto do arquivo
na chave correta do VSAM
no ponto certo do cursor DB2 (na prática: reiniciar lógica por chave/estado salvo)
🎯 O batch tem que saber:
qual fase estava executando
qual registro/chave estava sendo processado
qual unidade de commit já foi confirmada
qual parte não pode repetir
🧩 Arquitetura clássica de batch com reprise “de respeito”
Um ciclo bem resolvido (a operação agradece):
Inicialização / parâmetros
Validações
Detecta reprise (rodada normal ou restart?)
Carrega checkpoint (fase + posição + chaves)
Reposiciona entradas (arquivo/DB2)
Loop principal
regra de negócio
atualização (DB2/arquivos)
commit por unidade lógica
checkpoint em pontos definidos
Finalização
“Checkpoint final” (término normal)
📌 Easter egg de produção:
Se você não tem “checkpoint final de sucesso”, vai ter madrugada com restart de batch que já terminou — e ninguém acredita até acontecer.
🧨 O vilão silencioso: duplicidade
O inferno do batch não é “parar”.
O inferno é parar depois de atualizar metade.
Por isso, todo batch com reprise tem que decidir:
vou garantir idempotência? (rodar de novo não duplica)
vou garantir commit controlado? (unidades fechadas)
vou guardar marcador de processado? (chave/flag/tabela de controle)
✅ Padrões usados:
Tabela de controle com status por chave/lote
Commit a cada N registros (N definido por volume, log, tempo)
Chave de negócio + verificação (“já processei isso?”)
Writes “safe” (criar saída nova e só no final fazer swap/rename)
📂 “Nem todo batch precisa de reprise” (mas todo batch precisa de juízo)
Batch que só:
lê arquivo
gera relatório
faz sorting
produz uma saída recriável
…muitas vezes reexecutar resolve.
Só que:
nunca reexecute “por cima” de saída velha sem estratégia
garanta limpeza/geração atômica (work datasets → output final)
📌 Dica prática:
Use datasets temporários e só “promova” pro nome final no fim. Batch que morre não deixa meia saída fingindo que tá certa.
🧾 Dicas Bellacosa de restart que evitam velório
Checkpoint = fase + posição + contexto. Não guarde só o número do registro; guarde o porquê.
Mensagem clara no log: “RESTART AT STEP X / KEY Y / FILE POS Z”. Operação ama isso.
Commit e checkpoint têm que conversar: checkpoint sem commit consistente é cilada.
Se atualiza DB2, trate o restart como requisito de negócio, não “extra”.
Testar restart é obrigatório: simule abend no meio e valide se volta certo.
☕ Fechando no estilo madrugada
No Mainframe, reprise é arquitetura, checkpoint é disciplina, e restart é respeito.
Batch sem reprise em processo crítico é igual:
“depois eu vejo”
só que o “depois” geralmente é 03:17 com telefone tocando e gente jurando que “nunca aconteceu antes”.
