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