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