Bellacosa Mainframe em uma visão sobre o LOG do DB2

🔥☕ O SUBMUNDO DO Db2 z/OS — LOGS, RECOVERY E O QUE ACONTECE QUANDO O BANCO “MORRE” ☕🔥

Existe um momento na vida de todo programador COBOL/Db2 em que ele descobre uma verdade assustadora:

O Db2 nunca esquece nada.

Cada:

• INSERT,
• UPDATE,
• DELETE,
• COMMIT,
• ROLLBACK,
• ALTER,
• REORG,

deixa rastros.

E esses rastros vivem dentro de uma das estruturas mais importantes do ecossistema mainframe:

🔥 O LOG DO Db2.

Se você é programador COBOL pleno e acha que recovery é “coisa de DBA”, cuidado.

Porque no dia em que um:

-904
-911
-803
00C90084
RESOURCE UNAVAILABLE

explodir produção às 3h da manhã…

você vai descobrir que entender o log do Db2 muda completamente sua carreira.

---

☕ O QUE É O LOG DO Db2?

O log do Db2 é o “diário transacional” do banco.

Tudo que altera dados gera registros de log.

O Db2 escreve:

• before image,
• after image,
• controle transacional,
• checkpoints,
• unidades de recuperação.

Basicamente:

ALTERAÇÃO → LOG → DISCO

Antes mesmo da página ser gravada no tablespace.

---

🔥 ACTIVE LOGS vs ARCHIVE LOGS

Aqui começa uma das maiores confusões dos iniciantes.

🔹 Active Logs

São os logs online e ativos.

Ficam sendo usados continuamente.

Eles armazenam:

• alterações recentes,
• transações em andamento,
• recovery imediato.

São críticos.

Perder active log é pesadelo nível apocalipse.

---

🔹 Archive Logs

Quando active logs ficam cheios:

• Db2 descarrega,
• copia,
• arquiva.

Esses logs históricos viram:

ARCHIVE LOGS

Eles são usados para:

• PIT recovery,
• auditoria,
• rollback histórico,
• disaster recovery.

---

☕ COMO O Db2 ESCREVE NO LOG?

Muita gente acha que Db2 grava direto no disco.

Não.

Primeiro ele grava em:

🔥 LOG BUFFERS

na memória.

Depois:

• COMMIT,
• checkpoint,
• buffer cheio,
• sync I/O,

forçam gravação nos:

ACTIVE LOG DATASETS

---

🔥 WRITE AHEAD LOGGING (WAL)

Aqui está o segredo do recovery moderno.

O Db2 segue:

🔥 WAL — Write Ahead Logging

Regra:

“O log precisa ser gravado ANTES da página do banco.”

Isso garante:

• rollback,
• redo,
• recuperação consistente.

Sem isso:
💀 corrupção.

---

☕ O QUE ACONTECE NUM COMMIT?

Quando o programa COBOL faz:

EXEC SQL COMMIT END-EXEC

o Db2:

1. sincroniza logs,
2. confirma UOW,
3. libera locks,
4. torna alterações permanentes.

O COMMIT é basicamente:

🔥 “Agora isso virou verdade oficial.”

---

☕ E NUM ABEND?

Aqui entra o terror psicológico do DBA.

Se ocorre:

• S0C7,
• S878,
• timeout,
• deadlock,
• cancel,
• crash,
• queda de LPAR,

o Db2 usa os logs para:

🔥 ROLLBACK

Ele desfaz tudo desde o último COMMIT.

---

🔥 TIPOS DE ERRO MAIS COMUNS

---

⚠️ SQLCODE -911 / -913

Deadlock ou timeout

Dois programas querem recursos incompatíveis.

Exemplo clássico:

• batch segurando tabela,
• online tentando atualizar.

DBA/Sysprog:

• analisar locking,
• IFCID,
• traces,
• IRLM,
• timeout values.

Programador COBOL:

• reduzir tempo entre commits,
• melhorar SQL,
• evitar scan gigante.

---

⚠️ SQLCODE -904

Resource unavailable

Tablespace parado.
Utility rodando.
Objeto indisponível.

DBA:

• verificar STOP status,
• utilities,
• claim/drain,
• locks.

Sysprog:

• investigar subsystem,
• storage,
• I/O,
• coupling facility.

---

⚠️ SQLCODE -803

Duplicate key

Programador tentou inserir chave já existente.

Programador:

• validar lógica,
• tratar concorrência,
• revisar sequence/identity.

DBA:

• verificar índice,
• constraints,
• integridade.

---

⚠️ SQLCODE -805

Package não encontrado

Clássico inferno de deploy.

DBA:

• verificar BIND,
• PLAN/PACKAGE,
• consistency token.

Sysprog:

• SDSNLOAD,
• STEPLIB,
• DBRM libraries.

Programador:

• garantir promote correto.

---

⚠️ 00C90084

Log full

Aqui o DBA começa a envelhecer rapidamente.

O active log lotou.

Possíveis causas:

• UOW gigante,
• commit inexistente,
• archive parado.

DBA:

• verificar ARCHIVE process,
• aumentar logs,
• cancelar job problemático.

Programador:

• COMMIT frequente,
• evitar transação monstruosa.

---

☕ COMO FUNCIONA O RECOVERY?

Aqui mora a mágica do Db2.

---

🔥 FORWARD RECOVERY

Db2:

1. restaura image copy,
2. reaplica logs.

Resultado:
✅ banco volta até ponto desejado.

---

🔥 BACKOUT / ROLLBACK

Db2 usa:

• before images,
• undo records.

E desfaz alterações.

---

🔥 RESTART RECOVERY

Após crash do subsystem:

Db2:

• lê logs,
• identifica UOW incompletas,
• faz undo/redo automático.

Muitas vezes o usuário nem percebe.

---

☕ O PAPEL DO DBA

O DBA é o “cirurgião do banco”.

Ele:

• monitora logs,
• executa RECOVER,
• controla utilities,
• administra image copies,
• resolve locking,
• acompanha catalog,
• analisa performance.

Ferramentas clássicas:

• DSN1LOGP,
• RECOVER,
• COPY,
• REORG,
• DISPLAY DATABASE,
• DISPLAY LOG.

---

☕ O PAPEL DO SYSPROG

O Sysprog atua na infraestrutura pesada.

Ele cuida:

• do subsystem Db2,
• IRLM,
• z/OS,
• JES,
• storage,
• coupling facility,
• datasets de log,
• BSDS,
• bootstrap datasets.

Se o DBA é cirurgião…
o Sysprog é engenheiro nuclear.

---

☕ O QUE O PROGRAMADOR COBOL PRECISA ENTENDER?

Muito mais do que imaginam.

Porque SQL ruim gera:

• lock,
• timeout,
• log storm,
• escalation,
• crash recovery lento.

---

🔥 Um bom programador Db2:

✅ faz commit racional
✅ evita cursor infinito
✅ reduz scans
✅ trata SQLCODE corretamente
✅ entende UOW
✅ sabe impacto do rollback
✅ evita transações gigantes

---

☕ O MAIOR ERRO DOS INICIANTES

Achar que:

COMMIT é só “salvar”.

Não.

COMMIT é:

• sincronização,
• liberação de lock,
• persistência,
• checkpoint lógico,
• controle de recovery.

É o coração do Db2 transacional.

---

🔥 CONCLUSÃO

O log do Db2 é praticamente:

🔥 a memória do banco.

Sem ele:

• não existe rollback,
• recovery,
• integridade,
• restart,
• consistência.

Quando você entende:

• active log,
• archive log,
• WAL,
• UOW,
• rollback,
• recovery,

você deixa de ser apenas “quem escreve SELECT”.

E começa a pensar como:

• DBA,
• sysprog,
• arquiteto transacional.

E no universo mainframe…

isso muda tudo. ☕🔥

 

Bellacosa Mainframe CICS e throughput

💣🔥 TPS NÃO É THROUGHPUT — É O SEU “COMMIT FINANCEIRO” PASSANDO NO CICS 🔥💣

Se você entrou numa discussão de arquitetura falando de fila, banco NoSQL e multi-região antes de entender o que é dinheiro sendo movimentado, já começou igual job com JCL errado: vai rodar… mas vai dar abend.

---

⚙️ TPS vs Throughput — visão Bellacosa Mainframe

No mundo raiz (sim, aquele do CICS + DB2 + commit de verdade):

• TPS (Transactions Per Second)
  👉 É o COMMIT EXECUTADO
  👉 É o dinheiro que mudou de dono
  👉 É o ponto sem volta
• Throughput
  👉 É o volume de processamento
  👉 Inclui request, fila, validação, retry
  👉 Muito barulho… nem sempre dinheiro

💥 Tradução brutal:

Throughput é fila cheia.
TPS é saldo alterado com sucesso.

Se você tem:

• 20k req/s entrando
• 3k virando transação

👉 Você NÃO tem um sistema de 20k.
👉 Você tem um sistema de 3k TPS financeiro.

---

🌍 Multi-região — quando o sistema vira “sysplex global sem JES”

Quando você sai de uma região…

Você não escalou.
Você entrou em guerra.

Agora você tem:

• 🌐 Latência: 100–200ms (no mínimo)
• 🔄 Consistência distribuída
• ⚠️ Conflito de escrita
• 🔁 Failover real (não o de slide de PowerPoint)

💣 E aqui vem o ponto que derruba sistema:

TPS deixa de ser capacidade e vira problema de coordenação global.

---

💥 Onde TODO mundo quebra (sem exceção)

1. Consistência forte global

👉 “Vamos manter saldo sincronizado em todas regiões”

Resultado:

• Lock distribuído
• Round-trip global
• TPS despenca mais rápido que job mal indexado

💣 Isso aqui mata performance.

---

2. Dependência síncrona entre regiões

👉 API Brasil → chama EUA → espera resposta

Resultado:

• Cada request carrega latência global
• Você virou refém da pior região

💣 É o equivalente moderno de:

“esperar fita montar pra continuar o batch”

---

3. Hotspot de dados

👉 Conta sendo acessada globalmente

Resultado:

• Contenção
• Locking
• Throughput artificialmente alto… TPS real baixo

💣 Clássico erro de modelagem.

---

☠️ O ERRO RAIZ (o mais perigoso)

“Vamos usar Kafka”
“Vamos usar Cassandra”
“Vamos fazer active-active”

🚫 Errado.

Isso é igual dizer:

“Vamos usar DFSORT” antes de saber o layout do arquivo.

---

🧠 Modelo mental Bellacosa (nível arquiteto de guerra)

Antes de falar de tecnologia, responda:

1. Tipo de operação

• 💰 Financeira crítica?
• 🔁 Pode reprocessar?
• ♻️ É idempotente?

---

2. Consistência

• 🔒 Forte → saldo, ledger
• 📊 Eventual → extrato, notificação

💣 Regra de ouro:

Quanto mais consistência, menor o TPS possível.

---

3. Latência aceitável

• ⚡ 100ms?
• 🕒 500ms?
• 🔁 segundos com retry?

👉 Isso define TUDO.

---

4. Distribuição geográfica

• Usuário local?
• Cross-border?

👉 Se for global, esqueça sonho de consistência forte em tudo.

---

5. Perfil de carga

• 📈 Constante?
• 🚀 Pico violento?

👉 Sistema que aguenta pico não nasce por acidente.

---

🏦 Caso real (estilo “produção sem desculpa”)

Cenário:

• 10k TPS global
• Brasil + México
• Transferência financeira

Estratégia inteligente

👉 Saldo = consistente localmente
👉 Cross-region = assíncrono

Fluxo mental:

• Região BR resolve BR rápido
• Região MX resolve MX rápido
• Entre regiões → evento + reconciliação

---

⚖️ O trade-off que ninguém escapa

Você sempre escolhe entre:

• 🔒 Consistência
• ⚡ Latência
• 🚀 Throughput

💣 Não existe arquitetura perfeita.
Existe arquitetura assumida com responsabilidade.

---

🔥 Conclusão estilo Bellacosa

Sistema financeiro não é sobre tecnologia.

É sobre decisão sob restrição real.

💣 Engenheiro júnior:

“Qual tecnologia usar?”

🔥 Engenheiro sênior:

“Qual risco eu posso aceitar?”

---

☕ Verdade final (nível mainframe raiz)

Se o seu TPS depende de coordenação global síncrona…

👉 você não construiu escala
👉 você construiu um gargalo distribuído

 

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

 

Bellacosa Mainframe o que é processamento mainframe

O que é Processamento Online em Mainframe?

O processamento Online é o modelo de execução em que o usuário interage diretamente com a aplicação e recebe uma resposta quase imediata.

Enquanto o Batch processa grandes volumes de dados em lote, o Online processa uma transação por vez, em tempo real.

---

Definição Simples

Processamento Online é:

a execução interativa de transações em tempo real.

Sempre que um usuário:

• consulta saldo;

• realiza um PIX;

• faz uma compra no cartão;

• acessa Internet Banking;

• emite um boleto;

há um processamento online acontecendo.

---

Analogia Simples

Batch

100.000 registros
        ↓
Processa tudo junto
        ↓
Resultado

---

Online

Usuário solicita
        ↓
Sistema responde
        ↓
Fim da transação

---

Exemplos do Dia a Dia

Caixa Eletrônico

Cliente consulta saldo
        ↓
CICS
        ↓
DB2
        ↓
Resposta em segundos

---

PIX

Cliente envia PIX
        ↓
Validação
        ↓
Atualização DB2
        ↓
Confirmação

---

Cartão de Crédito

Compra realizada
        ↓
Autorização
        ↓
Resposta

---

Arquitetura Online no Mainframe

Usuário
    ↓
Terminal / Web / Mobile
    ↓
CICS ou IMS TM
    ↓
Programa COBOL
    ↓
DB2 / VSAM
    ↓
Resposta

---

Principais Componentes

CICS

Customer Information Control System

Principal monitor transacional do mundo Mainframe.

Gerencia:

• transações;

• usuários;

• telas;

• comunicação.

---

IMS TM

IMS Transaction Manager.

Alternativa ao CICS.

Muito usado em:

• bancos;

• telecom;

• governo.

---

COBOL

Contém as regras de negócio.

---

DB2

Banco de dados relacional.

---

VSAM

Arquivos indexados.

---

Fluxo de uma Transação CICS

Terminal
    ↓
Transação
    ↓
Programa COBOL
    ↓
DB2
    ↓
Resposta

---

Exemplo de Transação

Código digitado:

CONS

ou

SALD

O CICS:

Recebe
 ↓
Localiza programa
 ↓
Executa
 ↓
Retorna tela

---

Exemplo COBOL Online

EXEC CICS RECEIVE
     MAP('TELA1')
END-EXEC.

Recebe dados da tela.

---

Consulta DB2

EXEC SQL

   SELECT SALDO
   INTO :WS-SALDO

   FROM CLIENTES

   WHERE CONTA = :WS-CONTA

END-EXEC.

---

Retorno ao Usuário

EXEC CICS SEND
     MAP('TELA2')
END-EXEC.

---

Características do Online

✅ Tempo real

✅ Resposta imediata

✅ Interação usuário

✅ Pequeno volume por transação

✅ Alta disponibilidade

---

Online x Batch

Online	Batch
Tempo real	Em lote
Interativo	Não interativo
Usuário presente	Usuário ausente
Resposta imediata	Processamento agendado
CICS/IMS	JCL/COBOL

---

O que é uma Transação?

Unidade lógica de trabalho.

Exemplo:

Consultar saldo

---

ou

Transferir dinheiro

---

Conceito ACID

Transações online devem garantir:

Atomicidade

Tudo ou nada.

---

Consistência

Dados válidos.

---

Isolamento

Usuários não interferem.

---

Durabilidade

Dados persistem.

---

COMMIT

Confirma a transação.

COMMIT;

---

ROLLBACK

Desfaz alterações.

ROLLBACK;

---

Exemplo

PIX enviado
     ↓
Erro
     ↓
ROLLBACK

Nenhum valor é debitado.

---

Desempenho

Transações online normalmente precisam responder em:

Menos de 1 segundo

ou

2 segundos

Dependendo da aplicação.

---

Segurança

Ambientes online usam:

• RACF

• ACF2

• Top Secret

para controlar acessos.

---

Disponibilidade

Muitos sistemas online operam:

24x7

Sem interrupção.

---

Exemplos Reais

Bancos

• PIX

• TED

• Consulta saldo

• Investimentos

---

Seguradoras

• Apólices

• Sinistros

---

Governo

• Receita Federal

• Previdência

---

Varejo

• Cartões

• E-commerce

---

Erros Comuns

Deadlock DB2

SQLCODE -911

---

Programa não encontrado

AEI0

---

Erro de COMMAREA

AEIV

---

Timeout

AICA

---

Curiosidades

1. O CICS processa bilhões de transações por dia no mundo

2. Muitas operações de cartão passam por Mainframes IBM Z

3. Um único CICS pode suportar milhares de usuários simultâneos

4. Grande parte dos PIX bancários passa por aplicações COBOL online

---

Resumo Rápido

Conceito	Função
Online	Processamento em tempo real
CICS	Monitor transacional
IMS TM	Gerenciador de transações
COBOL	Regras de negócio
DB2	Banco de dados
VSAM	Arquivo indexado
COMMIT	Confirma
ROLLBACK	Desfaz
ACID	Integridade transacional
RACF	Segurança

---

Conclusão

O processamento Online é o responsável pelas transações em tempo real no ambiente IBM Z. Utilizando tecnologias como CICS, IMS TM, COBOL, DB2 e VSAM, ele permite que milhões de usuários realizem consultas, pagamentos, transferências e operações críticas com rapidez, segurança e alta disponibilidade, tornando-se um dos pilares da computação corporativa moderna.