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):

1. Inicialização / parâmetros

2. Validações

3. Detecta reprise (rodada normal ou restart?)

4. Carrega checkpoint (fase + posição + chaves)

5. Reposiciona entradas (arquivo/DB2)

6. Loop principal

   • regra de negócio

   • atualização (DB2/arquivos)

   • commit por unidade lógica

   • checkpoint em pontos definidos

7. Finalização

8. “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”.