😈 CAP Theorem explicado para quem já confiou em commit em duas fases

00:00 — Introdução: quando a teoria virou dor real

Se você é mainframer e já confiou em Two-Phase Commit, já viveu o CAP Theorem antes dele ter nome.
A diferença é que, no mainframe, chamávamos isso de:

“Ou o dado está certo, ou o sistema fica em pé. Os dois ao mesmo tempo… depende.”

O Teorema CAP nasceu no mundo distribuído moderno, mas suas raízes estão lá atrás, nos tempos de IMS, CICS, DB2, sysplex e coordenação distribuída feita no braço.

---

1️⃣ O que é CAP (sem marketing)

CAP diz que, em um sistema distribuído, quando ocorre uma falha de rede, você só pode garantir duas das três propriedades:

• C – Consistency (Consistência)
  Todos veem o mesmo dado ao mesmo tempo.

• A – Availability (Disponibilidade)
  O sistema sempre responde.

• P – Partition Tolerance (Tolerância a partições)
  O sistema continua funcionando mesmo com falhas de rede.

⚠️ Spoiler mainframer:
P não é opcional. Se existe rede, vai haver partição.

---

2️⃣ A tradução CAP → dialeto mainframe 🧠

CAP	Mainframe raiz entende como
Consistency	Commit garantido, dado íntegro
Availability	Região em pé, SLA preservado
Partition	Link caiu, LPAR isolada, XCF brigando

👉 CAP não é escolha ideológica.
É decisão de sobrevivência.

---

3️⃣ Two-Phase Commit: o trauma fundador 😵

Fase 1 – Prepare

• Todos dizem: “posso gravar?”

• Locks segurados

• Esperança intacta

Fase 2 – Commit

• Coordenador manda gravar

• Um nó não responde…

• Silêncio

• Lock eterno

• DBA acordado

😈 Easter egg:
Quem já viu in-doubt transaction sabe que CAP não é slide de PowerPoint.

---

4️⃣ Onde o CAP dói de verdade

🔥 Consistência vs Disponibilidade

• Quer dado correto?
  → Pode ficar indisponível.

• Quer sistema respondendo?
  → Pode responder com dado antigo.

No mainframe, a escolha histórica foi:

Consistência acima de tudo.

No mundo web:

Disponibilidade acima de tudo.

---

5️⃣ Por que P não se discute

Em ambiente distribuído:

• Switch falha

• Roteador reinicia

• Zona cai

• Cloud provider “pisca”

📌 Curiosidade:
No sysplex, a IBM passou décadas tentando domar P com hardware, coupling facility e engenharia absurda.

Mesmo assim… partição acontece.

---

6️⃣ Modelos modernos (com cheiro de legado)

CP – Consistent + Partition tolerant

• DB2

• Sistemas financeiros

• Core banking

💬 “Se não gravar certo, melhor não gravar.”

AP – Available + Partition tolerant

• Cassandra

• DynamoDB

• Sistemas de catálogo, feeds, logs

💬 “Mostra algo agora, conserta depois.”

---

7️⃣ Eventual Consistency: o nome chique do “daqui a pouco acerta”

Mainframer traduz:

“Batch de reconciliação”

• Dados podem divergir temporariamente

• Em algum momento, convergem

• Desde que não falhe tudo 😈

📎 Easter egg:
Você já fez eventual consistency com VSAM + batch noturno e nem percebeu.

---

8️⃣ Passo a passo para decidir CAP na prática

1️⃣ O dado é financeiro ou regulatório?
→ C é obrigatório

2️⃣ O usuário pode esperar?
→ Talvez A não seja crítica

3️⃣ Se a rede cair, pode parar tudo?
→ Se não, aceite inconsistência temporária

4️⃣ Existe reconciliação posterior?
→ Batch, eventos, compensação

5️⃣ Quem assume o erro?
→ Sistema ou negócio?

---

9️⃣ Guia de estudo para mainframers inquietos 📚

Conceitos

• CAP Theorem

• PACELC (CAP com latência)

• Eventual Consistency

• Sagas (compensação)

Ferramentas e paralelos

• XA / 2PC → Transaction Coordinator

• Kafka → MQ + replay

• Sagas → Rollback manual versão cloud

• Observabilidade → SMF espiritual

---

🔟 Aplicações práticas no mundo híbrido

• Integrar DB2 com microservices

• Decidir quando expor APIs síncronas

• Projetar sistemas resilientes

• Evitar 2PC em cloud (sim, evite!)

• Atuar como arquiteto de verdade, não só operador

🎯 Mainframer que entende CAP vira arquiteto respeitado.

---

1️⃣1️⃣ Comentário final (02:17 da manhã)

CAP não é teoria acadêmica.
É a explicação formal da dor que você já sentiu.

Se você já:

• Perdeu noite por commit travado

• Desconfiou de dado “meio gravado”

• Escolheu derrubar tudo para não corromper

Então parabéns.
Você praticou CAP antes de virar hype.

🖤 El Jefe Midnight Lunch conclui:
Cloud é só o mainframe que esqueceu suas lições.

 

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