Bellacosa Mainframa apresenta o zBNA

☕ Um Café no Bellacosa Mainframe

🕸️ zBNA — Antes de Comprar Mais Mainframe, Descubra Quem Está Segurando o Batch

Quando o processamento termina tarde, a primeira pergunta quase nunca deveria ser “quanto de CPU falta?”. A pergunta correta é: “o que, exatamente, está impedindo o batch de terminar antes?”

Existe uma cena clássica em qualquer ambiente corporativo grande.

O processamento noturno atrasou.

O fechamento avançou além da janela esperada.

Algum relatório não ficou pronto.

Uma cadeia de arquivos terminou tarde.

O usuário de negócio começa a reclamar.

Então alguém abre os gráficos.

CPU alta.

Picos.

Jobs longos.

E logo surge a frase inevitável:

“Talvez seja hora de aumentar a máquina.”

Às vezes é.

Mas às vezes essa frase é o equivalente mainframe de olhar para um carro preso no trânsito e concluir:

“Precisamos de um motor maior.”

O motor pode até ser excelente.

O problema é que o carro continua parado atrás dos outros.

É justamente nesse ponto que entra uma ferramenta muito interessante do ecossistema IBM Z:

zBNA — IBM Z Batch Network Analyzer

E o nome já entrega boa parte da filosofia.

Ele não fala apenas em CPU.

Não fala apenas em capacidade.

Não fala apenas em jobs.

Ele fala em:

Batch Network.

Ou seja:

uma rede de processamento.

E essa mudança de visão é profunda.

---

🧠 1. Para começar: o que é um batch?

Para quem está entrando agora no mundo COBOL, JCL e z/OS, vamos estabelecer uma base.

Um processamento batch é aquele executado normalmente sem interação contínua de um usuário.

Você prepara:

Entrada
   ↓
Processamento
   ↓
Saída

No mainframe, isso muitas vezes aparece na forma de JOBs submetidos ao JES.

Um exemplo extremamente simples:

//BELLJOB JOB ...
//STEP01   EXEC PGM=PROG001
//INFILE   DD DSN=EMPRESA.ENTRADA,DISP=SHR
//OUTFILE  DD DSN=EMPRESA.SAIDA,DISP=...

Esse JOB poderia:

• ler um arquivo;

• processar registros;

• aplicar regras;

• gravar resultados.

Agora imagine isso multiplicado por:

10 JOBs
100 JOBs
1.000 JOBs
10.000 JOBs

E, pior:

eles não são independentes.

Um depende do outro.

Outro precisa esperar um arquivo.

Outro só pode começar depois da conclusão do predecessor.

Outro executa em paralelo.

Outro trava acesso a um dataset.

Outro espera Db2.

Outro aguarda scheduler.

De repente o batch deixa de ser uma fila.

Ele vira uma rede.

---

🕸️ 2. A palavra mais importante do zBNA é NETWORK

Vamos imaginar:

              JOB B
             /     \
JOB A ------         ------ JOB D ------ JOB E
             \     /
              JOB C

Isso já nos diz muito mais do que uma lista:

JOB A
JOB B
JOB C
JOB D
JOB E

No desenho existe informação.

Sabemos que:

• JOB A acontece antes;

• JOB B e JOB C podem trabalhar em paralelo;

• JOB D espera ambos;

• JOB E vem depois.

É isso que transforma um batch em uma rede de dependências.

E aqui começa a mágica.

Porque, se B demora 18 minutos e C demora 7, o sistema não espera:

18 + 7

Ele espera o mais lento dos dois, assumindo que realmente correm em paralelo.

Então temos:

MAX(18,7)
=
18

E isso muda completamente como calculamos o tempo total.

---

⏱️ 3. O tal do critical path

Essa expressão aparece o tempo inteiro quando falamos de zBNA.

Critical path, ou caminho crítico, é a cadeia de atividades cuja duração determina o término de todo o processo.

Vamos usar o exemplo:

JOB A = 12 min

JOB B = 18 min
JOB C = 7 min

JOB D = 42 min

JOB E = 9 min

Rede:

                    JOB B (18)
                  /            \
JOB A (12) ------                ------ JOB D (42) ------ JOB E (9)
                  \            /
                    JOB C (7)

O caminho por B é:

12 + 18 + 42 + 9
=
81 minutos

O caminho por C é:

12 + 7 + 42 + 9
=
70 minutos

Portanto:

A → B → D → E

é o caminho crítico.

Agora observe uma coisa maravilhosa.

Se alguém otimizar JOB C:

7 → 2 minutos

o batch inteiro talvez continue terminando em:

81 minutos

Ou seja:

o programa ficou mais rápido.

O negócio não percebeu.

---

💡 4. Esse é um dos maiores erros em performance

Programadores e analistas gostam de procurar:

“Qual programa está mais lento?”

Mas esta nem sempre é a pergunta certa.

Pode existir um programa que demora 30 minutos e ainda assim não influencia o horário final.

Exemplo:

                        JOB X = 30 min
                       /
                 -----+
                /
JOB A ---------+
                \
                 ----- JOB Y = 40 min

Se Y for o ramo determinante:

30 → 20

no X não muda o fim.

Mas:

40 → 35

no Y pode economizar cinco minutos reais.

Logo:

O JOB mais lento não é necessariamente o JOB mais importante.

Isso é puro pensamento de sistema.

---

🚨 5. E então aparece o gargalo serial

No gráfico que analisamos antes havia um personagem perigosíssimo:

JOB D — SERIAL BOTTLENECK
42 min

Esse tipo de etapa merece suspeita imediata.

Porque tudo converge para ela.

JOB B ───┐
         ├── JOB D ─── JOB E
JOB C ───┘

Se D não consegue ganhar muito com paralelismo, adicionar engines pode trazer pouco benefício.

E aqui chegamos a uma ideia fundamental.

Mais capacidade agregada não é o mesmo que mais velocidade para uma etapa serial.

---

⚙️ 6. Aggregate capacity vs per-engine performance

Imagine duas configurações hipotéticas.

Sistema A

10 engines
cada um = velocidade 100

Capacidade agregada aproximada:

1.000 unidades

Sistema B

5 engines
cada um = velocidade 200

Capacidade agregada também:

1.000 unidades

À primeira vista:

“São equivalentes.”

Talvez.

Mas imagine um workload altamente serial.

Ele usa praticamente um engine por vez.

Nesse cenário, o Sistema B poderia se comportar de forma muito diferente porque cada engine individual é mais rápido.

Agora inverta.

Imagine uma carga altamente paralela:

JOB1
JOB2
JOB3
JOB4
JOB5
JOB6
JOB7
JOB8

Nesse caso, o número de engines pode ser importantíssimo.

Moral:

capacidade total não conta a história completa.

E é justamente por isso que o sizing precisa conhecer o workload.

---

🧵 7. Usable parallelism

Essa expressão merece ser guardada.

Você pode comprar:

8 engines

Mas o batch talvez só consiga utilizar de forma útil:

2

porque:

• existem dependências;

• datasets ficam serializados;

• programas são monothread;

• jobs aguardam predecessor;

• há contenção;

• existem restrições de scheduler;

• faltam initiators;

• algum recurso compartilhado vira gargalo.

Logo:

engines disponíveis
≠
engines aproveitáveis

O que importa é:

usable parallelism

Ou seja:

quanto paralelismo o workload consegue realmente explorar.

---

🚂 8. Pense como uma ferrovia

Vamos usar uma analogia perfeita para mainframe.

Temos uma ferrovia transportando toneladas de carga.

Você pode melhorar o sistema adicionando:

• locomotivas;

• vagões;

• linhas paralelas;

• sinalização melhor;

• estações;

• trilhos mais rápidos.

Mas imagine que existe este trecho:

======\ 
       ====================
======/

Tudo precisa passar numa única linha.

Agora você compra dez locomotivas novas.

Resultado:

🚂
🚂
🚂
🚂
🚂
   ↓
single track

Parabéns.

Você aumentou a capacidade potencial.

E criou uma fila mais bonita.

No batch, isso pode acontecer com:

dataset
lock
Db2
scheduler
ENQ
program serial

---

🔎 9. É aqui que o zBNA entra de verdade

O zBNA ajuda a transformar dados coletados do ambiente em uma visão analisável do batch.

Em termos conceituais:

z/OS
  ↓
SMF
  ↓
extração
  ↓
zBNA
  ↓
visualização
  ↓
análise
  ↓
what-if

Ou seja:

o ambiente já deixou rastros.

O sistema registrou acontecimentos.

A ferramenta ajuda a reorganizar isso de modo que o analista consiga enxergar:

• tempo;

• jobs;

• steps;

• relacionamento;

• consumo;

• concorrência;

• dependências.

É uma espécie de arqueologia operacional.

---

🧬 10. SMF: a caixa-preta do z/OS

Para o iniciante, SMF pode parecer quase mágico.

SMF significa:

System Management Facilities

O z/OS registra grande quantidade de informações operacionais em registros SMF.

Dependendo do tipo de record, podemos encontrar dados ligados a:

• jobs;

• steps;

• CPU;

• datasets;

• sort;

• recursos;

• subsistemas;

• dispositivos;

• desempenho.

Imagine o SMF como uma enorme caixa-preta.

O avião voou.

Depois analisamos:

altitude
velocidade
motor
temperatura
pressão
eventos

No mainframe:

job
step
CPU
elapsed
I/O
dataset
resource

E daí reconstruímos o que aconteceu.

---

🧰 11. CP3KEXTR — preparando os dados

O fluxo típico de análise inclui o utilitário de extração que prepara os dados usados pelo zBNA.

Conceitualmente:

SMF
 ↓
CP3KEXTR
 ↓
arquivos extraídos
 ↓
zBNA

Não é o zBNA simplesmente “entrando no mainframe e olhando tudo ao vivo”.

Existe uma etapa de coleta e preparação.

Isso também é importante porque transforma o trabalho numa análise reproduzível.

Podemos dizer:

“Vamos analisar esta janela.”

Por exemplo:

22:00 → 06:00

do fechamento de um dia representativo.

---

📅 12. Representatividade da janela

E aqui surge um detalhe perigosíssimo.

Imagine que coletamos uma terça-feira calma:

terça
02:00–03:00

Depois usamos aquilo para planejar:

Black Friday
fechamento mensal
fim de ano
pico fiscal

Podemos produzir gráficos maravilhosos.

E uma conclusão completamente errada.

É o velho:

GARBAGE IN
   ↓
GARBAGE OUT

Só que numa versão elegante:

GARBAGE IN
   ↓
beautiful charts
   ↓
PowerPoint
   ↓
expensive decision

😁

Portanto:

qual período estamos analisando?

é tão importante quanto:

qual ferramenta estamos usando?

---

📊 13. Gantt Chart: quando o tempo finalmente aparece

Um gráfico temporal costuma revelar padrões imediatamente.

Imagine:

TIME → 23:00   00:00   01:00   02:00   03:00

JOB A █████
JOB B      █████████
JOB C      ████
JOB D              ███████████████
JOB E                             █████

Uma tabela poderia ter:

JOB A  11 min
JOB B  22 min
JOB C   9 min
JOB D  47 min
JOB E  13 min

Mas o gráfico revela relações.

Você consegue enxergar:

• concorrência;

• buracos;

• esperas;

• sobreposição;

• sequenciamento.

O cérebro humano é excelente em detectar padrão visual.

Por isso esse tipo de visualização é tão poderoso.

---

🔬 14. Top Programs

Agora trocamos a pergunta.

Antes:

quando?

Agora:

quem?

Quais programas aparecem como consumidores relevantes?

Imagine:

PROG     CPU

ACCT001  █████████████
SORT     ██████████
PAY021   ███████
REP311   ████

Isso pode direcionar uma segunda investigação.

zBNA aponta:

“Olhe aqui.”

Então entram outras ferramentas:

• Application Performance Analyzer;

• profiling;

• análise COBOL;

• Db2 EXPLAIN;

• SMF;

• RMF;

• traces.

Ferramenta boa não precisa responder tudo.

Ela precisa responder muito bem à pergunta certa.

---

☕ 15. Um programador COBOL encontra o zBNA

Imagine que você escreveu:

       PERFORM PROCESSA-CLIENTE
          UNTIL WS-FIM = 'S'.

E alguém lhe diz:

“Seu programa é um dos grandes consumidores.”

Não entre em pânico.

A investigação ainda está começando.

Precisamos descobrir:

CPU?
I/O?
Db2?
VSAM?
SORT?
Loop?
Algoritmo?
Serialização?

Talvez seu código execute milhões de vezes uma busca ruim.

Talvez faça:

READ
READ
READ
READ
READ

quando poderia reorganizar acesso.

Talvez o SQL esteja caro.

Talvez esteja lendo volume enorme sem necessidade.

Talvez nem seja culpa do programa.

Pode estar esperando recurso externo.

---

⏳ 16. Elapsed time não é CPU time

Isso é obrigatório para qualquer iniciante.

Imagine:

ELAPSED = 40 min
CPU     =  8 min

Então existem aproximadamente:

32 min

em outras atividades e esperas.

Não significa necessariamente 32 minutos parados, porque há detalhes de medição, concorrência e subsistemas.

Mas a ideia continua válida:

tempo total não é simplesmente CPU.

Se você dobrasse magicamente a velocidade da CPU e reduzisse:

8 → 4

o total não cairia automaticamente:

40 → 20

Poderia ficar algo próximo de:

36

dependendo do restante.

Esse pequeno exemplo destrói muita análise simplista.

---

💾 17. O fantasma do I/O

COBOL nasceu num mundo intensamente orientado a dados.

Arquivos.

Registros.

Leitura.

Gravação.

Ordenação.

Até hoje isso permanece central.

Imagine:

       READ ARQ-CLIENTES
           AT END
              MOVE 'S' TO WS-FIM
       END-READ.

Se temos:

150 milhões de registros

o comportamento de I/O pode ser tão ou mais importante que CPU.

Portanto:

“CPU nova resolverá?”

depende.

Talvez o JOB passe boa parte do tempo aguardando operações de armazenamento.

Mais CPU não transforma magicamente o storage.

---

🔐 18. Locks e contenção

Agora imagine Db2.

Dois processos querem trabalhar com o mesmo recurso.

JOB A → LOCK
             ↓
JOB B → WAIT

JOB B pode aparecer demorando muito.

Mas ele não está “pensando lentamente”.

Está esperando.

Comprar CPU:

mais CPU

não remove automaticamente:

LOCK

Precisamos analisar:

• transação;

• concorrência;

• commit;

• acesso;

• sequência;

• design.

De novo:

workload behavior.

---

🚦 19. Scheduling

Outro suspeito.

Imagine:

JOB READY = 01:00

START     = 01:17

Depois:

RUN = 5 min

Ele termina:

01:22

Alguém vê:

22 min

e reclama.

Mas:

17 min

foram antes da execução.

Talvez scheduler.

Talvez initiator.

Talvez predecessor.

Talvez recursos.

Talvez classe.

Talvez política.

Se otimizarmos o programa em 50%:

5 → 2,5 min

o total vira:

19,5 min

Ainda ruim.

O grande problema estava fora do código.

---

🧱 20. Initiators

No JES, initiators desempenham papel importantíssimo na execução batch.

Simplificando:

um JOB elegível precisa encontrar condição para executar.

Imagine:

10 JOBs prontos
2 initiators

Nem todos começam juntos.

Agora:

10 JOBs prontos
10 initiators

Pode haver mais paralelismo.

Mas cuidado.

Mais initiators também podem produzir:

mais concorrência
        ↓
mais I/O
        ↓
mais locks
        ↓
mais CPU
        ↓
mais contenção

Então até a solução aparente cria outra pergunta.

Esse é o mainframe:

tudo está conectado.

---

🧠 21. WLM entra na história

O Workload Manager é outro componente essencial.

WLM trabalha com objetivos e importância dos workloads.

Ele ajuda o z/OS a decidir como distribuir recursos.

Se um workload crítico não está recebendo o tratamento esperado, precisamos investigar.

Não significa que zBNA substitui WLM.

Ao contrário.

Pense assim:

zBNA
  ↓
mostra comportamento batch

WLM
  ↓
gerencia recursos conforme políticas

RMF
  ↓
mostra comportamento do sistema

Cada um observa o elefante por um lado.

---

🔥 22. RMF + zBNA

Uma combinação forte.

Suponha que zBNA mostra:

02:15–02:45
critical path

Agora abrimos RMF e perguntamos:

“O que o sistema estava fazendo exatamente nesse período?”

Podemos correlacionar:

• CPU;

• DASD;

• channels;

• memory;

• service classes;

• LPAR behavior.

Então:

zBNA
“onde olhar”

e:

RMF
“o que acontecia no sistema”

Essa correlação é muito mais poderosa do que cada relatório isolado.

---

🧪 23. What-if — o laboratório sem quebrar produção

Uma das ideias mais fascinantes do zBNA é permitir estudos do tipo:

“E se?”

Exemplo:

CURRENT PROCESSOR
      ↓
workload atual

Agora:

Scenario A
Scenario B
Scenario C

Podemos investigar configurações alternativas.

Isso é ouro.

Porque o erro clássico é pensar:

machine B = 20% faster

portanto:

batch = 20% faster

Não necessariamente.

Porque:

• CPU não é tudo;

• serialização existe;

• I/O existe;

• wait existe;

• paralelismo é limitado;

• dependências existem.

---

🧮 24. Lei de Amdahl sem matemática assustadora

A ideia é simples.

Imagine um JOB:

50% paralelizável
50% serial

Você melhora infinitamente a parte paralela.

O máximo teórico fica limitado pelo pedaço serial.

Porque ele nunca desaparece.

Traduzindo para café:

Imagine preparar o café da manhã.

Você pode simultaneamente:

fritar ovo
passar café
cortar pão

Mas só pode servir depois que:

CAFÉ TERMINAR

Se o café demora 10 minutos, não adianta contratar dez pessoas para cortar pão.

O gargalo continua sendo o café.

---

📈 25. Quando CPU realmente é o gargalo

Importante: não vamos cair no extremo oposto.

Às vezes falta CPU.

E ponto.

Imagine:

CPs saturados
queues
WLM pressure
CPU-bound workloads
critical jobs disputando resource

Nesse caso, mais capacidade pode ser exatamente o necessário.

O valor do zBNA não está em provar que hardware é inútil.

Está em responder:

quando o hardware realmente resolverá.

Essa distinção vale milhões.

---

💰 26. Porque sizing é decisão econômica

Comprar mainframe não é escolher um videogame.

Existe:

• hardware;

• software;

• licenciamento;

• capacidade;

• crescimento;

• suporte;

• energia;

• risco;

• implementação.

E software no IBM Z pode estar relacionado ao consumo e à configuração de formas complexas.

Então capacity planning também é economia.

Imagine:

Opção A
hardware menor
mais otimização

Opção B
hardware maior
menos alteração

Opção C
hardware intermediário
+ scheduling
+ tuning

Talvez C seja melhor.

Não porque seja tecnicamente mais poderosa.

Mas porque equilibra:

performance
cost
risk
SLA

---

🔐 27. Criptografia também pode entrar na conversa

Hoje segurança adiciona outra dimensão.

Imagine habilitar encryption de datasets.

Excelente para segurança.

Mas também precisamos entender impacto operacional.

Perguntas:

quanto CPU?
qual workload?
qual janela?
qual dataset?
qual impacto no batch?

Essa abordagem é madura.

Não:

“Encryption é cara.”

Nem:

“Encryption não custa nada.”

Mas:

“Vamos medir e modelar este workload.”

---

🗜️ 28. Compressão

Mesma coisa.

Compressão pode reduzir:

I/O
storage
transfer

mas pode exigir processamento.

É um balanço.

Se temos um workload I/O-bound, compressão pode ser extremamente interessante.

Se temos CPU pressure enorme, precisamos analisar.

Again:

workload decides.

---

🧹 29. Sort: o gigante escondido

Em muitos ambientes batch, SORT aparece por toda parte.

Exemplo:

//SORTSTEP EXEC PGM=SORT

Parece banal.

Mas ordenações gigantes podem consumir recursos importantes.

Imagine:

500 milhões registros

Sort pode envolver:

• CPU;

• memória;

• work datasets;

• I/O;

• temporary storage.

Tecnologias e implementações mais modernas podem mudar bastante o comportamento.

Por isso identificação de candidatos importa.

---

🔍 30. Top Program não significa Guilty Program

Esse é outro princípio Bellacosa War Room.

Imagine lista:

1. PROG001
2. SORT
3. DB2
4. PROG999

O primeiro não é automaticamente culpado.

Pode ser:

• um grande consumidor legítimo;

• volume necessário;

• trabalho útil;

• parte não crítica;

• workload bem otimizado.

Sempre pergunte:

consume muito por quê?

A diferença entre engenharia e caça às bruxas está nessa pergunta.

---

🧩 31. Critical path pode mudar

Agora entra uma curiosidade deliciosa.

Hoje:

PATH A = 90 min
PATH B = 82 min

A é crítico.

Otimizamos:

PATH A = 75 min
PATH B = 82 min

Agora B é crítico.

Ou seja:

o gargalo mudou de endereço.

Performance é assim.

Você remove uma pedra.

Descobre outra embaixo.

Por isso:

measure
analyze
optimize
measure again

Nunca:

optimize
declare victory
go home

---

🕵️ 32. War Room às 03:17

Agora nosso easter egg.

São:

03:17

O processamento deveria ter terminado às:

03:00

Telefone toca.

Operações entra na ponte.

Aplicação entra na ponte.

Banco entra na ponte.

Storage entra na ponte.

Infra entra na ponte.

Começa:

“CPU está alta.”

Outro diz:

“Db2 está normal.”

Outro:

“Storage não vê nada.”

Outro:

“O job está rodando.”

Bellacosa olha para a cadeia:

JOB A
 ↓
JOB B
 ↓
JOB C
 ↓
JOB D

Pergunta:

“Quando D começou?”

Resposta:

03:09

Pergunta:

“Quando deveria?”

Resposta:

02:41

Aí vem a pergunta importante:

“Por que começou 28 minutos tarde?”

Silêncio.

Agora a investigação mudou.

Não estamos mais perguntando:

“Por que D está lento?”

Estamos perguntando:

“Por que D começou tarde?”

Esse detalhe pode economizar horas de War Room.

---

🔎 33. Performance é detetive, não adivinhação

Um bom analista não chega dizendo:

“É CPU.”

Ele chega perguntando.

Pergunta 1

Qual é o SLA?

Pergunta 2

Qual é o caminho crítico?

Pergunta 3

Onde o atraso nasceu?

Pergunta 4

É CPU ou elapsed?

Pergunta 5

Existe wait?

Pergunta 6

Existe contenção?

Pergunta 7

Existe predecessor?

Pergunta 8

Existe paralelismo utilizável?

Pergunta 9

Uma máquina diferente mudaria aquilo?

Isso é engenharia.

---

🎯 34. SLA vem antes da tecnologia

Antes de zBNA, CPU, engine, WLM ou SMF, existe uma coisa:

o negócio.

Exemplo:

Batch termina 04:00
SLA = 06:00

Talvez tudo esteja maravilhoso.

Outro:

Batch termina 04:00
SLA = 03:30

Temos um problema.

Mesma máquina.

Mesmo tempo.

Situação completamente diferente.

Então capacity planning começa perguntando:

“Precisamos terminar quando?”

Não:

“Quanto CPU temos?”

---

📐 35. Right-sizing

Essa expressão é muito melhor do que:

bigger machine

Right-sizing significa:

configuração adequada.

Talvez seja maior.

Talvez tenha engines mais rápidos.

Talvez mais engines.

Talvez mudança de software.

Talvez combinação.

Talvez nenhum hardware novo.

É encontrar equilíbrio.

Performance
   +
Cost
   +
Growth
   +
Risk
   +
SLA

---

🧠 36. O programador COBOL deveria aprender isso?

Sim.

Mesmo se nunca operar zBNA.

Porque isso muda a forma de programar.

Você começa a pensar:

meu programa existe numa rede.

Ele não está sozinho.

Seu programa pode:

• produzir arquivo;

• alimentar outro job;

• travar dataset;

• consumir Db2;

• segurar predecessor;

• estar no critical path.

Esse entendimento transforma o programador.

Ele deixa de pensar:

“Meu programa terminou.”

E começa a pensar:

“Qual impacto meu programa tem no fluxo inteiro?”

Isso é sair de developer para system thinker.

---

🏛️ 37. Mainframe é uma cidade

Uma analogia final.

Imagine o mainframe como uma cidade.

CPU são as avenidas.

DASD são depósitos.

Db2 são bibliotecas.

JES é estação de transporte.

Scheduler é controle de tráfego.

WLM é prefeitura.

Jobs são caminhões.

Datasets são carga.

Agora imagine milhares de caminhões.

Você olha congestionamento e diz:

“Vamos construir uma avenida maior.”

Pode resolver.

Mas talvez o problema seja:

ponte interditada
alfândega lenta
semáforo quebrado
depósito fechado

O zBNA ajuda justamente a enxergar o mapa do tráfego.

Não apenas o tamanho da avenida.

---

🧩 38. O que eu considero mais poderoso no zBNA

Não são os gráficos.

Não é nem o what-if.

É a mudança de pergunta.

Antes:

“Precisamos de mais capacidade?”

Depois:

“Que característica deste workload está determinando nosso tempo?”

Essa é uma pergunta muito mais rica.

Dela podem nascer respostas diferentes:

CPU
I/O
parallelism
scheduling
contention
application
hardware

E cada resposta pede tratamento diferente.

---

🚀 39. Um método Bellacosa Mainframe para zBNA

Eu resumiria numa sequência prática.

1. Defina o SLA

Qual processo precisa terminar quando?

2. Escolha uma janela representativa

Não escolha terça tranquila para modelar fechamento mensal.

3. Colete evidência

Use SMF adequado.

4. Monte a rede

Observe jobs, steps e dependências.

5. Encontre o critical path

Quem segura o relógio?

6. Classifique o atraso

CPU?

I/O?

Wait?

Schedule?

Contention?

7. Verifique paralelismo

Quanto a aplicação realmente consegue usar?

8. Faça what-if

O que muda com processor/configuration diferente?

9. Considere custo

Hardware e software.

10. Valide

Nenhum modelo substitui produção.

---

🥚 40. Easter egg para quem chegou até aqui

Olhe novamente:

03:17

Se você viu esse horário e lembrou da War Room, parabéns.

Você encontrou o easter egg.

Mas a mensagem escondida é outra.

Na maioria dos incidentes longos, existe um momento em que alguém finalmente faz a pergunta correta.

Até aquele momento:

everyone has data

Depois:

someone has context

E essa talvez seja a verdadeira função de ferramentas como zBNA:

transformar dado em contexto.

---

🏁 Conclusão

zBNA — IBM Z Batch Network Analyzer — é muito mais interessante quando deixamos de enxergá-lo como “uma ferramenta de sizing”.

Ele é uma ferramenta para compreender comportamento.

E compreender comportamento vem antes de dimensionar infraestrutura.

O raciocínio completo é:

business process
      ↓
batch window
      ↓
job network
      ↓
critical path
      ↓
resource behavior
      ↓
parallelism
      ↓
what-if
      ↓
processor sizing
      ↓
business decision

Isso muda a ordem da conversa.

A discussão deixa de começar por:

“Qual máquina comprar?”

e passa a começar por:

“O que realmente está determinando o tempo do nosso processamento?”

Às vezes a resposta será:

CPU.

Às vezes:

I/O.

Às vezes:

scheduler.

Às vezes:

dataset.

Às vezes:

Db2.

Às vezes:

um programa COBOL escrito há vinte anos que está fazendo exatamente aquilo que mandaram ele fazer.

E essa é a beleza.

O mainframe não é uma caixa preta.

Ele deixa rastros.

O bom analista aprende a lê-los.

Então, da próxima vez que alguém disser:

“Precisamos de um mainframe maior.”

talvez valha responder:

“Antes de aumentar o mainframe, vamos descobrir quem está segurando o relógio.”

Porque performance não começa no catálogo do processador.

Começa no workload.

E o workload sempre tem uma história para contar.