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

 

Bellacosa Mainframe e tipo de concorrencia em processo batch e online

☕🔥 “O MAINFRAME NÃO MORRE POR ACASO” — A DIFERENÇA ENTRE LATÊNCIA, THROUGHPUT, BANDWIDTH, CONCURRENCY E PARALLELISM NO MUNDO COBOL/CICS QUE QUASE NINGUÉM EXPLICA DIREITO

A imagem mostra cinco conceitos que parecem iguais para muita gente de TI… mas no mundo IBM Mainframe eles definem literalmente:

• se o banco vai sobreviver ao pico do PIX,

• se o CICS vai congelar,

• se o batch vai atravessar a madrugada,

• ou se o operador vai começar a receber avalanche de ABEND e WTOR no console.

E aqui está o ponto mais importante:

Mainframe não foi construído apenas para “ser rápido”.

Ele foi construído para continuar funcionando sob carga absurda.

É aí que esses conceitos deixam de ser teoria acadêmica e viram sobrevivência operacional.

---

latency, trhoughput bandwidth concurrency parallelism

☕ 1. LATENCY — O TEMPO QUE O USUÁRIO “SENTE”

Na imagem:

• Latency = tempo de ida e volta de uma requisição.

No universo CICS online isso é CRÍTICO.

---

🔥 No CICS, latência é percepção humana

Quando um terminal 3270 envia uma transação:

ENTER → VTAM/TCPIP → CICS → DB2 → VSAM → retorno da tela

o usuário percebe:

• resposta instantânea,

• lentidão,

• ou travamento.

Mesmo processando milhares de TPS, se a resposta individual demora…

o operador diz:

“o sistema está lento”.

---

☕ Exemplo Bellacosa Mainframe

Imagine:

Transação bancária COBOL/CICS

EXEC CICS READ FILE('CLIENTE')
END-EXEC.

Se o VSAM:

• está com CI/CA split,

• buffer ruim,

• lock excessivo,

• ou I/O congestionado,

a latência explode.

O throughput do sistema pode continuar alto…

MAS O USUÁRIO SOFRE.

---

🔥 Sintoma clássico no mainframe

O CICS parece “vivo”:

• região UP,

• CPU ok,

• DB2 ativo,

mas:

• tela demora,

• ENTER trava,

• pseudo-conversação fica lenta.

Isso é problema de:

LATÊNCIA

não necessariamente capacidade.

---

☕ Métricas reais no z/OS

No Mainframe medimos isso via:

• SMF

• RMF

• OMEGAMON

• CICS Statistics

• CICS Monitoring Facility

Exemplos:

• Response Time

• Dispatch Wait

• Suspend Time

• VSAM String Wait

• DB2 Lock/Latch Wait

---

☕ 2. THROUGHPUT — QUANTO O MAINFRAME CONSEGUE PROCESSAR

Na imagem:

• throughput = requests por segundo.

Aqui começa a magia do IBM Z.

---

🔥 Mainframe nasceu para throughput monstruoso

Enquanto muitos servidores distribuídos quebram em pico…

o z/OS foi arquitetado para:

• milhões de transações,

• gigantesco volume de I/O,

• altíssima simultaneidade.

---

☕ Exemplo real

Um banco pode ter:

• 50 mil TPS no CICS,

• milhões de updates DB2,

• milhares de jobs batch simultâneos.

Tudo no mesmo CPC.

---

☕ Throughput no Batch

No batch o throughput significa:

Quantidade de registros processados por unidade de tempo

Exemplo:

SORT de 800 milhões de registros

ou:

ETL COBOL + DB2

O objetivo não é resposta rápida individual.

O objetivo é:

MASSA PROCESSADA

---

🔥 Filosofia do batch

Batch pensa assim:

“Não importa um registro.
Importa terminar 5 bilhões antes das 6 da manhã.”

Isso é throughput extremo.

---

☕ Gargalos clássicos de throughput

No z/OS:

• EXCP excessivo

• canal saturado

• buffer pool inadequado

• SORT mal parametrizado

• dataset fragmentado

• GDG gigantesco

• contention em enqueue

---

☕ 3. BANDWIDTH — A LARGURA DO “CANO”

Na imagem:

• bandwidth = capacidade máxima de transferência.

---

🔥 No mainframe isso vai MUITO além de rede

As pessoas pensam:

Bandwidth = internet

No IBM Z isso inclui:

• Channel Subsystem

• FICON

• Hipersockets

• Coupling Facility

• DASD throughput

• Memory Bus

• zEDC

• OSA adapters

---

☕ Analogia Bellacosa

Imagine:

• Latência = tempo para chegar água.

• Throughput = litros entregues por hora.

• Bandwidth = grossura do cano.

---

☕ Exemplo clássico

Você pode ter:

• CPU sobrando,

• COBOL eficiente,

• DB2 saudável,

MAS:

FICON congestionado

Resultado:

• I/O lento,

• batch atrasado,

• CICS esperando disco.

---

🔥 O detalhe brutal

Mainframe normalmente NÃO morre por CPU.

Muitas vezes ele sofre por:

• I/O,

• contention,

• lock,

• canal,

• storage,

• serialization.

---

☕ 4. CONCURRENCY — MUITAS COISAS AO MESMO TEMPO

Na imagem:

• concurrency = quantidade de requisições simultâneas.

---

🔥 Aqui mora a essência do CICS

CICS foi criado para:

milhares de usuários simultâneos

Isso é concorrência.

---

☕ Exemplo clássico

10 mil usuários:

• consulta saldo,

• fazem PIX,

• acessam apólice,

• atualizam cadastro,

• geram boleto.

Tudo simultaneamente.

---

☕ O segredo do CICS

Pseudo-conversação.

A tarefa:

• recebe input,

• processa,

• devolve tela,

• libera recurso.

Isso evita:

• task presa,

• memória ocupada,

• terminal lockado.

---

🔥 Concorrência NÃO significa paralelismo

Esse é um erro gigantesco.

Concorrência:

muitas tarefas coexistindo

não significa:

todas executando juntas fisicamente

---

☕ Exemplo didático

1000 tasks CICS podem estar:

• waiting,

• suspended,

• dispatchable,

• em I/O.

Mas talvez apenas algumas estejam usando CPU naquele instante.

---

☕ Problemas clássicos de concorrência no CICS

Deadlock

DB2:

Task A espera Task B
Task B espera Task A

---

Storage violation

Uma task COBOL corrompe storage de outra.

---

ENQ contention

Muitos programas disputando o mesmo recurso.

---

VSAM string wait

Dataset com poucas strings.

---

☕ 5. PARALLELISM — EXECUÇÃO REALMENTE SIMULTÂNEA

Na imagem:

• parallelism = tarefas executando simultaneamente em múltiplos workers.

---

🔥 Aqui entra a força monstruosa do IBM Z moderno

Hoje temos:

• múltiplos CPs,

• zIIPs,

• IFLs,

• specialty engines,

• Parallel Sysplex.

---

☕ Exemplo real

Enquanto:

• um batch COBOL roda,

• DB2 faz prefetch,

• Java executa no USS,

• MQ trafega mensagens,

• CICS atende online,

o hardware executa várias cargas EM PARALELO.

---

☕ Batch paralelo

Antigamente:

1 JOB → 8 horas

Hoje:

8 JOBs paralelos → 50 minutos

usando:

• DFSORT,

• ICETOOL,

• GDG split,

• DB2 partitioning,

• Sysplex Parallelism.

---

🔥 Parallel Sysplex: a joia da IBM

Isso muda tudo.

Vários LPARs:

• compartilham workload,

• distribuem transações,

• sobrevivem a falhas.

É quase um “superorganismo computacional”.

---

☕ Exemplo de banco

Uma transação pode:

• entrar por um CICS A,

• acessar DB2 compartilhado,

• usar Coupling Facility,

• continuar em outro nó.

O usuário nem percebe.

---

☕ O ERRO QUE MUITA GENTE COMETE

Misturar:

• throughput,

• latência,

• concorrência,

• paralelismo.

---

🔥 Cenário clássico

Você aumenta concorrência:

mais usuários simultâneos

MAS:

• lock aumenta,

• contention explode,

• I/O satura.

Resultado:

throughput CAI

---

☕ Outro cenário clássico

Você aumenta paralelismo batch.

MAS:

• todos acessam mesmo VSAM,

• mesmo índice DB2,

• mesmo dataset SORTWK.

Resultado:

SERIALIZAÇÃO

e o ganho desaparece.

---

☕ A LIÇÃO QUE O MAINFRAME ENSINA

Sistemas grandes não dependem apenas de velocidade.

Dependem de:

• equilíbrio,

• gerenciamento de recursos,

• escalabilidade,

• isolamento,

• previsibilidade,

• resiliência.

---

🔥 O IBM Z foi construído para o caos corporativo

Enquanto ambientes distribuídos frequentemente:

• escalam quebrando,

• sofrem efeito cascata,

• dependem de centenas de servidores,

o mainframe pensa diferente:

“Centralize.
Controle.
Priorize.
Gerencie concorrência.
Garanta throughput.
Minimize latência.
Sobreviva.”

---

☕ RESUMO BELLACOSA MAINFRAME

Conceito	No Mainframe Significa
Latency	Tempo percebido pelo usuário CICS
Throughput	Volume total processado
Bandwidth	Capacidade de tráfego/I/O
Concurrency	Quantidade de tarefas simultâneas
Parallelism	Execução real em múltiplos engines

---

🔥 Frase final no estilo Bellacosa Mainframe

“Servidor comum impressiona em benchmark.

Mainframe impressiona sobrevivendo ao inferno operacional sem parar o banco.”