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.

 

Bellacosa Mainframe reapresenta o mainframe para antigos mainframers retornantes

☕ Um Café no Bellacosa Mainframe

Se você Saiu do Mainframe Há muito, mas muito tempo? Sherlock Holmes, COBOL e o Mistério da Plataforma que se Recusou a Envelhecer

Imagine a seguinte cena.

Depois de quinze ou vinte anos afastado do universo mainframe, você decide voltar.

Talvez tenha trabalhado com COBOL, JCL, CICS, VSAM ou DB2 no início dos anos 2000. Talvez tenha deixado a área para atuar com gestão, sistemas distribuídos, suporte, negócios ou até mesmo em outra profissão. Durante esse período, você acompanhou o nascimento da computação em nuvem, dos smartphones, das redes sociais, dos microsserviços, dos containers e da inteligência artificial.

Então surge a dúvida:

“Será que ainda sei alguma coisa útil?”

Você imagina entrar novamente em um ambiente mainframe e encontrar uma tecnologia completamente diferente daquela que conheceu. Talvez espere descobrir que o COBOL desapareceu, que o terminal 3270 virou peça de museu e que todos os sistemas foram substituídos por aplicativos modernos executando em alguma nuvem misteriosa.

Mas, ao atravessar a porta do data center, algo curioso acontece.

O cenário parece novo e familiar ao mesmo tempo.

É como Sherlock Holmes retornando a Baker Street depois de muitos anos. A cidade ganhou novos prédios, os carros mudaram, as comunicações ficaram instantâneas e agora existem câmeras por toda parte. Entretanto, os mistérios continuam sendo resolvidos da mesma forma: observando detalhes, seguindo pistas, eliminando hipóteses e compreendendo o comportamento humano.

No mainframe moderno, acontece algo parecido.

As ferramentas mudaram.

As integrações mudaram.

Os processos de desenvolvimento mudaram.

Porém, a essência do trabalho continua surpreendentemente reconhecível.

O primeiro mistério: o mainframe ficou parado no tempo?

Não.

Esse é o primeiro caso que precisamos solucionar.

O mainframe não ficou congelado em uma sala escura, cercado por fitas magnéticas e operadores usando jalecos brancos. Ele evoluiu continuamente.

O que aconteceu foi algo mais interessante: a plataforma evoluiu preservando compatibilidade com grande parte do que já existia.

Essa é uma das principais diferenças entre o mundo mainframe e muitas tecnologias distribuídas.

Em certos ecossistemas, uma nova versão pode tornar aplicações antigas incompatíveis. Frameworks surgem, ganham popularidade e desaparecem em poucos anos. Bibliotecas são abandonadas, padrões são substituídos e projetos inteiros precisam ser reescritos.

No mainframe, a evolução costuma ser mais cuidadosa.

A plataforma é responsável por sistemas bancários, seguradoras, governos, empresas de transporte, indústrias, companhias aéreas e organizações que não podem simplesmente parar tudo por alguns meses para reconstruir aplicações críticas.

Portanto, o mainframe evolui como uma grande cidade histórica.

Novas avenidas são construídas.

Novos sistemas de transporte são criados.

Novas redes de comunicação são instaladas.

Mas os prédios centrais continuam funcionando.

O COBOL continua presente.

O CICS continua processando transações.

O DB2 continua armazenando dados críticos.

O MQ continua transportando mensagens.

O JCL continua controlando processamento batch.

O JES continua recebendo e executando jobs.

O SDSF continua permitindo que o profissional consulte filas, resultados e mensagens.

E o TSO/ISPF continua lá, com suas telas, comandos e painéis familiares.

Quem retorna depois de muitos anos pode até sentir uma estranha sensação de conforto ao abrir o ISPF e perceber que a opção 3.2 continua sendo utilizada para trabalhar com data sets.

É quase como reencontrar um antigo café que mudou as mesas, reformou a fachada e instalou Wi-Fi, mas continua servindo o mesmo bom espresso.

O segundo mistério: o COBOL mudou completamente?

Para um programador COBOL iniciante, essa pergunta é importante.

A resposta é: o COBOL mudou, mas não perdeu sua identidade.

Quem conhecia a linguagem há quinze ou vinte anos ainda reconhecerá sua estrutura principal.

Um programa COBOL moderno continua podendo apresentar divisões como:

IDENTIFICATION DIVISION.
ENVIRONMENT DIVISION.
DATA DIVISION.
PROCEDURE DIVISION.

Ainda encontraremos comandos como:

MOVE
IF
EVALUATE
PERFORM
READ
WRITE
REWRITE
DELETE
CALL

Ainda teremos variáveis descritas por níveis:

01 WS-CLIENTE.
   05 WS-CODIGO        PIC 9(08).
   05 WS-NOME          PIC X(40).
   05 WS-SALDO         PIC S9(11)V99 COMP-3.

Ainda haverá programas que acessam DB2:

EXEC SQL
   SELECT NOME,
          SALDO
     INTO :WS-NOME,
          :WS-SALDO
     FROM CLIENTES
    WHERE CODIGO = :WS-CODIGO
END-EXEC.

Ainda existirão programas CICS:

EXEC CICS
   READ FILE('CLIENTES')
        INTO(WS-REGISTRO)
        RIDFLD(WS-CODIGO)
        RESP(WS-RESP)
END-EXEC.

O programador que já conhecia COBOL não precisará reaprender a lógica fundamental da linguagem.

Porém, encontrará compiladores mais modernos, novos recursos, integração com JSON, XML, Unicode, APIs, ferramentas de análise, IDEs gráficas, testes automatizados e pipelines de desenvolvimento.

O COBOL não virou outra linguagem.

Ele ficou mais conectado ao mundo ao seu redor.

Uma analogia para o iniciante

Imagine um automóvel clássico que recebeu:

• freios modernos;

• injeção eletrônica;

• sensores;

• GPS;

• computador de bordo;

• novos sistemas de segurança.

O volante continua sendo um volante.

O motor continua transformando energia em movimento.

O motorista ainda precisa conhecer trânsito, direção, frenagem e manutenção.

Da mesma forma, o programador COBOL ainda precisa dominar:

• estruturas de dados;

• lógica condicional;

• repetição;

• arquivos;

• bancos de dados;

• tratamento de erros;

• regras de negócio;

• processamento transacional;

• processamento batch.

As novas ferramentas ajudam, mas não substituem a compreensão.

O verdadeiro salto aconteceu ao redor do mainframe

Aqui encontramos a pista mais importante de toda a investigação.

Há quinze ou vinte anos, muitas aplicações mainframe eram acessadas diretamente por terminais 3270.

Um fluxo comum poderia ser representado assim:

Usuário
   ↓
Terminal 3270
   ↓
CICS
   ↓
Programa COBOL
   ↓
VSAM ou DB2

Esse modelo ainda existe.

Entretanto, hoje um mesmo programa pode participar de uma arquitetura muito mais ampla:

Aplicativo de celular
   ↓
API Gateway
   ↓
Microsserviço
   ↓
z/OS Connect
   ↓
CICS
   ↓
Programa COBOL
   ↓
DB2
   ↓
MQ
   ↓
Outro sistema corporativo

Observe o detalhe, meu caro Watson.

O aplicativo móvel pode ter sido escrito em Kotlin ou Swift.

A API pode utilizar Java, Node.js ou outra tecnologia.

A aplicação pode estar parcialmente executando em cloud ou em containers.

Mas a regra crítica de negócio pode continuar dentro de um programa COBOL que existe há décadas.

Isso não significa atraso.

Significa reutilização de um ativo confiável.

Se um programa calcula corretamente juros, impostos, limites, tarifas, seguros ou benefícios há vinte anos, talvez seja mais seguro integrá-lo a novas interfaces do que reescrever tudo apenas para seguir uma moda tecnológica.

O mainframe deixou de ser uma ilha

Antigamente, era comum imaginar o mainframe como uma grande fortaleza.

Tudo acontecia dentro dela.

Os usuários acessavam terminais.

Os sistemas trocavam arquivos.

Os jobs eram executados em horários definidos.

Grande parte da integração permanecia dentro dos limites da empresa.

Hoje, o mainframe faz parte de um ecossistema híbrido.

Ele pode conversar com:

• aplicações web;

• sistemas em cloud;

• APIs REST;

• ferramentas de analytics;

• plataformas de inteligência artificial;

• sistemas distribuídos;

• aplicações móveis;

• microsserviços;

• ambientes Linux;

• filas de mensagens;

• plataformas de automação.

O mainframe não desapareceu.

Ele deixou de trabalhar sozinho.

CICS: do terminal 3270 para a API

Para o programador COBOL iniciante, é importante entender o papel do CICS.

CICS é um monitor de processamento transacional.

Ele permite que milhares de usuários e aplicações executem transações com rapidez, controle e segurança.

No passado, muitas transações CICS eram iniciadas diretamente por uma tela 3270.

O usuário digitava dados, pressionava Enter e o programa COBOL era executado.

Hoje, a mesma lógica pode ser acionada por uma API.

Por exemplo:

1. Um cliente abre o aplicativo do banco.

2. Solicita o saldo.

3. O aplicativo envia uma requisição HTTPS.

4. Uma API recebe essa solicitação.

5. A API chama um serviço exposto pelo z/OS Connect.

6. O serviço aciona uma transação ou programa no CICS.

7. O programa COBOL consulta o DB2.

8. O resultado é convertido para JSON.

9. O aplicativo exibe o saldo ao usuário.

Para o cliente, tudo aconteceu em segundos.

Para o programa COBOL, talvez a operação continue sendo uma consulta conhecida há muitos anos.

A entrada mudou.

A saída mudou.

A regra central permaneceu.

DB2, VSAM e o valor dos dados

Todo bom detetive sabe que uma pista isolada não resolve um caso.

É preciso saber onde ela está armazenada e como se relaciona com outras informações.

No mainframe, grande parte das pistas está nos dados.

O DB2 continua sendo um dos pilares de inúmeros sistemas corporativos. Ele oferece recursos de banco de dados relacional, controle transacional, concorrência, integridade e recuperação.

O VSAM também continua presente, especialmente em aplicações que utilizam arquivos estruturados de alta performance.

Um programador COBOL iniciante deve compreender pelo menos quatro conceitos básicos:

1. KSDS

O Key Sequenced Data Set organiza registros por chave.

É semelhante à ideia de acessar um cadastro por um código identificador.

2. ESDS

O Entry Sequenced Data Set armazena registros na ordem em que foram incluídos.

3. RRDS

O Relative Record Data Set permite acessar registros por número relativo.

4. LDS

O Linear Data Set é utilizado como estrutura de armazenamento de baixo nível por alguns produtos.

Mesmo com bancos modernos, APIs e cloud, esses conceitos continuam importantes porque muitos sistemas críticos dependem deles.

MQ: o mensageiro silencioso

Imagine que Sherlock Holmes precisa enviar uma mensagem confidencial para o inspetor Lestrade.

Ele poderia entregar pessoalmente.

Mas também poderia utilizar um mensageiro confiável, garantindo que a mensagem chegasse ao destino mesmo que Lestrade não estivesse disponível naquele instante.

O MQ desempenha papel semelhante.

Uma aplicação envia uma mensagem para uma fila.

Outra aplicação consome essa mensagem quando estiver pronta.

Isso permite desacoplar sistemas.

Por exemplo:

Programa COBOL
   ↓
Fila MQ
   ↓
Sistema antifraude
   ↓
Fila de resposta
   ↓
Outro programa

O produtor da mensagem não precisa conhecer todos os detalhes do consumidor.

Ele precisa apenas respeitar o formato combinado.

Essa arquitetura ajuda a integrar mainframe, cloud, sistemas distribuídos e aplicações externas.

O batch não morreu

Existe uma espécie de lenda urbana na tecnologia: a ideia de que tudo precisa acontecer online e em tempo real.

Não é verdade.

Muitas tarefas continuam sendo mais eficientes em processamento batch.

Entre elas:

• fechamento contábil;

• geração de extratos;

• cálculo de folha de pagamento;

• faturamento;

• conciliação;

• processamento de grandes volumes;

• cálculo de impostos;

• liquidação financeira;

• atualização de cadastros;

• geração de relatórios.

Um job JCL pode executar vários programas em sequência:

//FECHAMTO JOB ...
//STEP01   EXEC PGM=VALIDA
//ENTRADA  DD DSN=EMPRESA.ARQUIVO.ENTRADA,DISP=SHR
//SAIDA    DD DSN=EMPRESA.ARQUIVO.VALIDADO,
//            DISP=(NEW,CATLG,DELETE)
//STEP02   EXEC PGM=CALCULA
//STEP03   EXEC PGM=ATUALIZA

O princípio continua familiar.

Cada etapa realiza uma parte do trabalho.

O resultado de uma etapa pode alimentar a próxima.

O JES controla a execução.

As mensagens podem ser analisadas pelo SDSF.

O programador ainda precisa investigar códigos de retorno, abends, arquivos, condições e dependências.

Sherlock Holmes entra no SDSF

Suponha que um job terminou com erro.

O iniciante pode olhar para a tela e pensar:

“O programa quebrou.”

O analista experiente pensa diferente.

Ele pergunta:

• Qual step falhou?

• Qual foi o código de retorno?

• Houve abend?

• O arquivo existia?

• O DISP estava correto?

• O espaço foi suficiente?

• O programa encontrou o registro esperado?

• O SQLCODE indica erro de banco?

• O problema aconteceu antes ou depois da alteração?

• Qual mensagem apareceu primeiro?

Essa é a mentalidade investigativa.

Um erro observado no final nem sempre começou no final.

Talvez o STEP03 tenha falhado porque o STEP02 gerou um arquivo vazio.

Talvez o STEP02 tenha gerado um arquivo vazio porque o STEP01 utilizou uma data incorreta.

Talvez a data incorreta tenha sido enviada por um sistema externo.

O verdadeiro culpado pode estar muitos passos antes da mensagem final.

Elementar.

Git, DevOps e pipelines

Uma das maiores mudanças para quem retorna ao mainframe está no processo de desenvolvimento.

No modelo tradicional, o código COBOL podia permanecer em bibliotecas PDS ou PDSE, controlado por ferramentas corporativas de gerenciamento de mudanças.

Hoje, muitas empresas integram o mainframe com Git.

Isso permite trabalhar com conceitos como:

• repositório;

• branch;

• commit;

• merge;

• pull request;

• code review;

• pipeline;

• integração contínua;

• entrega contínua.

Um fluxo moderno pode ser:

Desenvolvedor altera o COBOL
   ↓
Cria um commit
   ↓
Envia para o Git
   ↓
Pipeline inicia
   ↓
Código é compilado
   ↓
Testes são executados
   ↓
Qualidade é verificada
   ↓
Artefatos são preparados
   ↓
Implantação segue para o ambiente correto

O programa COBOL continua sendo COBOL.

O que mudou foi a estrada utilizada para levá-lo do desenvolvimento até a produção.

DevOps não é uma ferramenta

Essa distinção é importante.

DevOps não é apenas Jenkins.

Não é apenas Git.

Não é apenas pipeline.

DevOps é uma forma de organizar pessoas, processos e tecnologia para entregar software com maior frequência, segurança e rastreabilidade.

No contexto mainframe, isso pode envolver:

• versionamento de código;

• automação de builds;

• testes automatizados;

• análise de qualidade;

• controle de mudanças;

• infraestrutura como código;

• observabilidade;

• colaboração entre desenvolvimento e operação.

Para quem está retornando, não é necessário aprender tudo de uma vez.

O importante é compreender o fluxo.

Passo a passo para quem deseja voltar ao mainframe

Agora chegamos à parte prática da investigação.

Passo 1: recupere os fundamentos

Revise:

• estrutura de programas COBOL;

• PIC;

• níveis de dados;

• COMP e COMP-3;

• tabelas;

• REDEFINES;

• PERFORM;

• EVALUATE;

• arquivos;

• subprogramas;

• tratamento de erros.

Não tente começar pelas ferramentas mais modernas sem recuperar a base.

Passo 2: revise JCL

Estude:

• JOB;

• EXEC;

• DD;

• DISP;

• DSN;

• SPACE;

• DCB;

• COND;

• IF/THEN/ELSE;

• PROC;

• parâmetros simbólicos;

• GDG;

• utilitários.

O JCL continua sendo essencial para o processamento batch.

Passo 3: volte ao TSO/ISPF e SDSF

Relembre:

• navegação no ISPF;

• edição de membros;

• manipulação de data sets;

• submissão de jobs;

• consulta de spool;

• interpretação de mensagens;

• análise de códigos de retorno.

Passo 4: escolha uma trilha de banco ou arquivo

Você pode aprofundar:

• DB2 e SQL;

• VSAM;

• IMS DB.

Para muitos profissionais, DB2 é um excelente ponto de partida.

Passo 5: estude CICS

Compreenda:

• transação;

• programa;

• COMMAREA;

• canais e containers;

• mapas BMS;

• LINK;

• XCTL;

• START;

• READ;

• WRITE;

• REWRITE;

• DELETE;

• códigos RESP.

Passo 6: aprenda integração moderna

Estude os conceitos de:

• API REST;

• JSON;

• HTTP;

• z/OS Connect;

• MQ;

• autenticação;

• microsserviços.

Não é necessário virar especialista em desenvolvimento web.

É necessário entender como o COBOL participa do fluxo.

Passo 7: entre no mundo Git

Pratique:

git clone
git checkout -b
git add
git commit
git push
git pull

Entenda a lógica de branches e pull requests.

Passo 8: conheça pipelines

Aprenda o conceito antes da ferramenta.

Pergunte:

• O que inicia o pipeline?

• Como o código é compilado?

• Onde os testes executam?

• Como o artefato é promovido?

• Quem aprova a mudança?

• Como ocorre o rollback?

Passo 9: use inteligência artificial como assistente

A IA pode ajudar a:

• explicar um trecho COBOL;

• documentar código;

• sugerir casos de teste;

• analisar mensagens de erro;

• criar exemplos;

• comparar comandos;

• explicar JCL;

• revisar SQL.

Mas existe uma regra de ouro:

Nunca aceite uma resposta técnica sem validar contexto, sintaxe, impacto e segurança.

A IA é Watson.

Você continua sendo Sherlock Holmes.

A experiência ainda vale?

Vale muito.

Talvez mais do que antes.

Um profissional experiente sabe que alterar uma linha de código pode afetar:

• outro programa;

• outro job;

• outro arquivo;

• uma interface;

• um relatório;

• uma regra fiscal;

• uma rotina contábil;

• um processo noturno;

• um sistema externo;

• uma operação de negócio.

Essa percepção não nasce apenas em cursos.

Ela nasce de incidentes, projetos, viradas de produção, abends, reuniões, erros, acertos e noites acompanhando processamento.

O conhecimento técnico pode ser atualizado.

A maturidade sistêmica leva tempo para ser construída.

Curiosidade: por que o mainframe sobreviveu?

Porque ele resolve problemas difíceis.

Entre suas características estão:

• alta disponibilidade;

• segurança;

• escalabilidade;

• processamento transacional;

• grande capacidade de entrada e saída;

• gestão de cargas;

• confiabilidade;

• compatibilidade;

• recuperação;

• governança.

Empresas não mantêm mainframes por nostalgia.

Mantêm porque substituir sistemas críticos é caro, arriscado e complexo.

Além disso, a plataforma continua evoluindo.

Easter egg: o programa que ninguém queria tocar

Em quase toda grande empresa existe um programa lendário.

Ele possui milhares de linhas.

Foi escrito por alguém que se aposentou.

Tem comentários misteriosos.

Contém parágrafos chamados:

9000-ROTINA-ESPECIAL.

Ninguém sabe exatamente por que a rotina é especial.

Dentro dela há uma condição:

IF WS-CODIGO = 37
   MOVE 'S' TO WS-LIBERA
END-IF.

Todos perguntam:

“Por que 37?”

A documentação não explica.

O analista antigo diz:

“Não mexa nisso. Foi criado depois do incidente de 1998.”

Esse é o verdadeiro folclore mainframe.

Mas também revela um problema sério: conhecimento não documentado.

O profissional moderno deve preservar a confiabilidade do legado, mas também melhorar documentação, testes e rastreabilidade.

Dicas para o programador COBOL iniciante

Primeira dica: não tenha vergonha de perguntar.

Mainframe é um ecossistema enorme. Ninguém domina tudo.

Segunda dica: aprenda a ler antes de querer escrever.

Grande parte do trabalho será compreender programas existentes.

Terceira dica: siga os dados.

Quando estiver investigando um problema, acompanhe:

• entrada;

• transformação;

• armazenamento;

• saída.

Quarta dica: leia as mensagens completas.

Não olhe apenas para a última linha do erro.

Quinta dica: entenda o negócio.

Um programa não existe por causa da tecnologia. Ele existe para cumprir uma regra.

Sexta dica: evite alterações desnecessárias.

Em sistemas críticos, elegância não vale mais do que previsibilidade.

Sétima dica: teste cenários extremos.

Considere:

• zeros;

• valores negativos;

• campos vazios;

• datas inválidas;

• duplicidade;

• arquivo inexistente;

• registro não encontrado;

• SQLCODE inesperado;

• indisponibilidade de serviço.

Oitava dica: documente o motivo.

O código mostra o que foi feito.

O comentário deve explicar por que foi feito.

O retorno não é um recomeço do zero

Quem saiu do mainframe há quinze anos não retorna como iniciante absoluto.

Retorna como alguém que já conhece parte do mapa.

Será necessário atualizar ferramentas, processos e integrações.

Mas a capacidade de analisar sistemas, compreender regras e trabalhar com responsabilidade continua presente.

Talvez você precise aprender Git.

Talvez precise entender APIs.

Talvez precise utilizar VS Code.

Talvez precise estudar pipelines.

Mas ainda reconhecerá o cheiro de um job em produção, o silêncio desconfortável de um código de retorno inesperado e a satisfação de encontrar a causa de um erro escondida em uma variável inicializada incorretamente.

Conclusão: o último mistério de Baker Street

Sherlock Holmes colocaria todas as pistas sobre a mesa:

• o COBOL continua vivo;

• o CICS continua processando transações;

• o DB2 continua armazenando dados críticos;

• o batch continua movimentando empresas;

• o JCL continua organizando execuções;

• o mainframe agora conversa com APIs, cloud e aplicações móveis;

• Git e DevOps modernizaram o processo;

• a inteligência artificial acelerou o aprendizado;

• a experiência continua sendo um ativo valioso.

Então ele concluiria:

“O mainframe não permaneceu no passado. Ele trouxe o passado consigo, incorporou o presente e continua se preparando para o futuro.”

Para o programador COBOL iniciante, essa é uma excelente notícia.

Você está entrando em um ambiente que valoriza fundamentos.

Para o profissional que deseja retornar, a notícia é ainda melhor.

Você não perdeu tudo o que sabia.

Seu conhecimento apenas precisa ser recompilado com novas opções, testado em um novo pipeline e integrado a um ecossistema mais moderno.

No Bellacosa Mainframe, diríamos que a carreira não sofreu um ABEND definitivo.

Ela apenas ficou aguardando um novo EXEC.

E quando esse momento chegar, talvez você descubra que a plataforma mudou bastante ao redor de você, mas ainda reconhece perfeitamente os caminhos internos do sistema.

Afinal, meu caro Watson, tecnologias podem mudar de interface.

Mas bons profissionais continuam seguindo pistas, protegendo dados, compreendendo negócios e mantendo o mundo funcionando enquanto todos dormem.

☕ Um Café no Bellacosa Mainframe — onde cada SYSOUT conta uma história, cada ABEND esconde um mistério e todo programa COBOL antigo pode guardar uma pista sobre o futuro.

 

🌸 Linguagem da rua japonesa — o “slang” do cotidiano

 

Bellacosa Mainframe e a linguagem slgan do cotidiano japones

🌸 Linguagem da rua japonesa — o “slang” do cotidiano

Enquanto o japonês formal é cheio de camadas de respeito (keigo, sonkeigo, kenjougo…), o japonês informal é puro improviso e emoção.
Essas palavras que você escuta em animes, dramas, ou no karaokê depois do saquê, nascem nas ruas de Shibuya, nas salas de aula, e até nos fóruns online tipo 2channel.
São expressões flexíveis, vivas e mutantes — um reflexo da cultura japonesa urbana e digital.

---

💥 1. Maji (マジ)

Significado: “Sério”, “de verdade”, “realmente”.
Origem: vem de majime (真面目), que significa “sério, honesto, aplicado”. Com o tempo, os jovens encurtaram pra “maji” — mais leve e expressivo.

Uso:

• 「マジで？」 (Maji de?) → “Sério mesmo?”

• 「マジかよ！」 (Maji kayo!) → “Tá brincando!?”

• 「マジで疲れた。」 (Maji de tsukareta.) → “Tô cansado pra caramba.”

🧠 Curiosidade Bellacosa: é o equivalente japonês do nosso “sério mesmo?” ou “na moral?”. Hoje é quase universal entre jovens e aparece em quase todo anime escolar.

---

😩 2. Darui (だるい)

Significado: “Preguiça”, “moleza”, “sem energia”.
Origem: deriva de “darui” (怠い ou だるい) — uma palavra antiga que descrevia o corpo cansado ou sem ânimo.

Uso:

• 「今日だるいなぁ。」 (Kyō darui naa.) → “Tô mole hoje.”

• 「授業だるい。」 (Jugyō darui.) → “A aula tá chata/pesada.”

🧘 Bellacosa Note: É a palavra do adolescente de segunda-feira. É o “aff” japonês, o “que preguiça” dos tempos modernos.

---

⚡ 3. Yabai (ヤバい)

Significado: originalmente “perigoso”, mas hoje pode ser “incrível”, “tenso”, “lascou”, “da hora”, dependendo do contexto.
Origem: vem do dialeto de criminosos no Japão do século XX — yabai descrevia uma situação arriscada (tipo “a polícia tá vindo”).
Com o tempo, virou um gíria universal que expressa tanto perigo quanto admiração.

Uso:

• 「このラーメンやばい！」 (Kono rāmen yabai!) → “Esse ramen tá incrível!”

• 「テストやばい…」 (Tesuto yabai…) → “Tô ferrado na prova…”

🔥 Bellacosa Insight: É o “mano do céu!” japonês. Pode ser bom ou ruim — depende do tom e do contexto. É o camaleão das gírias nipônicas.

---

🤝 4. Sorena (それな)

Significado: “Verdade!”, “Exatamente isso!”, “Concordo total.”
Origem: junção de sore (isso) + na (partícula de concordância ou ênfase). Literalmente “isso aí, né”.

Uso:

• 「あの先生うるさいよね。」→「それな！」 (Aquele professor é chato, né? → Pois é!)

☕ Bellacosa Reflexão: é o “totalmente”, “é isso aí”, o “fala tudo” japonês — usado em bate-papo entre amigos pra demonstrar sintonia.

---

🫡 5. Otsu (おつ)

Significado: abreviação de otsukaresama (お疲れ様) — algo como “bom trabalho”, “valeu pelo esforço”.
Origem: vem da etiqueta do trabalho japonês. É dito ao final de um expediente, ou ao terminar uma tarefa.

Uso:

• 「おつかれ！」 (Otsukare!) → “Valeu, bom trabalho!”

• 「おつ！」 (Otsu!) → “Falou!”, “Tamo junto!”

💼 Bellacosa Contexto: no mundo corporativo japonês, é quase um ritual: você diz “otsukaresama deshita” ao sair, mesmo que o colega ainda vá ficar.
No digital (LINE, Discord, games), virou o “flw”, “vlw”, “gg” japonês.

---

🎌 Epílogo Bellacosa Mainframe

Essas cinco palavras — maji, darui, yabai, sorena, otsu — são o código-fonte da alma jovem japonesa.
Misturam respeito e rebeldia, tradição e modernidade, como o COBOL e o JSON da língua falada.
O Japão pode ser milenar e hierárquico, mas na esquina de Akihabara, no Discord gamer, ou no barzinho de Shinjuku, o japonês vivo respira, ri e cria novas versões de si mesmo — sempre com um toque de yabai energia.

JSON em COBOL no IBM Z: O Holocron das APIs Modernas – JSON PARSE - Parte II

 

Bellacosa Mainframe e o json no cobol parte II

JSON em COBOL no IBM Z: O Holocron das APIs Modernas

Parte 2 – JSON PARSE

Quando o Padawan Aprende a Transformar Texto em Estruturas COBOL

Por Bellacosa Mainframe

---

"JSON é apenas texto. O verdadeiro poder está em fazer COBOL compreender esse texto como se fosse uma estrutura nativa do IBM Z."

Mestre Bellacosa Sysprog Jedi

---

Introdução

Na Parte 1, o Padawan descobriu algo surpreendente.

COBOL moderno fala JSON.

Aprendemos:

• JSON GENERATE

• UTF-8

• CCSID

• Enterprise COBOL 6.x

• APIs REST

• JSON em memória

• Segurança básica

Agora chegamos ao momento em que o programa COBOL deixa de apenas produzir JSON.

Ele começa a entender JSON.

E isso acontece através de uma instrução quase mágica.

JSON PARSE

---

O que é JSON PARSE?

JSON PARSE é o tradutor universal.

Ele recebe.

Texto.

Transforma.

Em estruturas COBOL.

---

Visualmente.

JSON


↓

JSON PARSE


↓

WORKING STORAGE


↓

Programa COBOL

---

Exemplo.

Recebemos.

{
"id":100,

"nome":"Bellacosa",

"idade":52
}

---

COBOL deseja.

01 CLIENTE.

05 ID.

PIC 9(5).


05 NOME.

PIC X(30).


05 IDADE.

PIC 999.

---

JSON PARSE faz isso.

Automaticamente.

---

Quando surgiu?

IBM introduziu.

JSON PARSE

Enterprise COBOL

Version 6.

---

Mais utilizado hoje.

6.3

6.4

6.5

---

Mudou completamente.

Integrações.

---

Primeiro programa JSON PARSE

Passo 1

Estrutura COBOL

01 WS-CLIENTE.


05 WS-ID.
PIC 9(5).


05 WS-NOME.
PIC X(30).


05 WS-IDADE.
PIC 999.

---

Passo 2

Buffer JSON

01 WS-JSON.

PIC X(500).

---

Passo 3

Popular

MOVE

'{"id":100,

"nome":"Bellacosa",

"idade":52}'


TO WS-JSON

---

Passo 4

Parse

JSON PARSE

WS-JSON

INTO WS-CLIENTE

---

Passo 5

Display

DISPLAY WS-ID.


DISPLAY WS-NOME.


DISPLAY WS-IDADE.

---

Resultado.

100


Bellacosa


52

---

Pronto.

JSON virou COBOL.

---

O que acontece internamente?

Compilador cria.

Parser interno.

---

Percorre.

Caractere.

Por caractere.

---

Reconhece.

Chaves.

Aspas.

Números.

Vetores.

---

Mapeia.

Campos.

---

Visualmente.

{


"id"



100



}


↓

COBOL


ID=100

---

Como funciona na memória?

JSON continua sendo texto.

---

Exemplo.

Buffer


500 bytes

---

Parser lê.

---

Move dados.

---

Para.

Working Storage.

---

Resultado.

WS-ID


100



WS-NOME


Bellacosa

---

Sem ponteiros.

Sem árvore.

Sem DOM.

---

Muito eficiente.

---

Objetos Aninhados

JSON suporta.

Estruturas.

Dentro.

De estruturas.

---

Exemplo.

{

"cliente":{

"id":1,

"nome":"Bellacosa"

}

}

---

COBOL.

01 CLIENTE.


05 DADOS.


10 ID.


10 NOME.

---

Muito elegante.

---

Arrays

Chegamos.

Ao lado divertido.

---

JSON.

{

"telefones":[

"1111",

"2222"

]

}

---

COBOL.

05 TELEFONES.

10 TEL OCCURS 10.


15 NUMERO.


PIC X(20).

---

Parser.

Preenche.

---

COUNT IN

Muito útil.

---

Exemplo.

JSON PARSE

WS-JSON


INTO WS-DADOS


COUNT IN WS-CONTADOR

---

Retorna.

Quantidade.

Itens.

---

Excelente.

Para.

Arrays.

---

ON EXCEPTION

Fundamental.

Nunca esquecer.

---

Exemplo.

JSON PARSE

WS-JSON


INTO WS-CLI


ON EXCEPTION


DISPLAY 'ERRO'

---

Padawan.

Sempre use.

---

Exemplo inválido

JSON.

{


"id":100


"nome":"Bellacosa"

Aspa.

Faltando.

---

Parser.

Falha.

---

ON EXCEPTION.

Executado.

---

JSON Malicioso

Poucos falam.

Mas existe.

---

Payload.

Gigante.

---

Exemplo.

50 MB.

---

Consome.

CPU.

---

Memória.

---

Tempo.

---

DoS.

---

Negação.

Serviço.

---

Boa prática

Validar.

Tamanho.

---

Exemplo.

IF WS-LEN > 100000

DISPLAY 'ERRO'

---

Muito recomendado.

---

Nomes diferentes

JSON.

Pode vir.

{

"customer_name":"Bellacosa"

}

---

COBOL.

05 WS-NOME.

---

Problema.

---

Precisamos.

Mapear.

---

Enterprise COBOL possui.

NAME OF.

SUPPRESS.

---

Falaremos.

Parte 3.

---

UTF8

Grande inimigo.

---

JSON.

UTF8.

---

COBOL.

EBCDIC.

---

José.

Pode quebrar.

---

Ç.

Ã.

É.

---

Atenção.

Sempre.

---

JSON NULL

JSON.

{


"nome":null
}

---

COBOL.

Não possui.

Null textual.

---

Precisamos.

Tratar.

---

Muito importante.

---

Performance

Excelente.

---

JSON PARSE.

É compilado.

---

Muito rápido.

---

Melhor.

Que parser.

Manual.

---

Evite.

UNSTRING


INSPECT


STRING

---

Desnecessário.

---

JSON PARSE.

Resolve.

---

Curiosidades

Muitos bancos.

Recebem.

Milhões.

JSON.

Por dia.

---

Aplicativos.

PIX.

Cartão.

Open Finance.

---

Tudo passa.

Por.

JSON.

---

E em muitos casos.

Existe.

COBOL.

No fim.

Da cadeia.

---

Debug

Exemplo.

DISPLAY WS-JSON

---

Muito útil.

---

Ou.

IBM Debug Tool.

---

Fault Analyzer.

---

Dump.

---

Quando usar?

Excelente.

REST

MQ

Kafka

zOS Connect

Mobile

Open Banking

PIX

Cloud

---

Quando evitar?

Arquivos internos.

---

VSAM.

---

Relatórios.

---

Batch tradicional.

---

Bellacosa Best Practices

Sempre

Use ON EXCEPTION

---

Sempre

Validar tamanho

---

Sempre

Testar UTF8

---

Sempre

Documentar JSON

---

Sempre

Versionar APIs

---

O Conselho do Mestre Bellacosa

JSON PARSE é provavelmente uma das maiores evoluções já incorporadas ao Enterprise COBOL.

Ele permite que um programa escrito há vinte ou trinta anos compreenda payloads produzidos por smartphones, microsserviços, plataformas OpenShift e aplicações espalhadas pela Internet.

O jovem Padawan deve perceber uma verdade importante.

JSON continua sendo apenas texto.

Mas JSON PARSE transforma esse texto em algo que COBOL entende profundamente.

Estruturas.

Campos.

Vetores.

Níveis.

OCCURS.

Variáveis.

E talvez essa seja a maior beleza do IBM Z moderno.

Ele não exige que o desenvolvedor abandone décadas de conhecimento.

Ele apenas oferece novas ferramentas.

E diz:

Continue programando em COBOL.

Continue usando seus níveis 01, 05 e 10.

Continue confiando em sua experiência.

Eu apenas ensinarei ao seu programa a compreender uma nova linguagem falada por toda a galáxia digital.

---

Continua na Parte 3

JSON GENERATE – Quando o Padawan Aprende a Construir APIs REST com COBOL, Criar Payloads Elegantes, Controlar Campos, Suprimir Dados e Falar com Microsserviços do Futuro.

Bellacosa Mainframe e a introdução ao IA Agente

☕ Um Café no Bellacosa Mainframe

A Máquina do Tempo Entra no CPD — O Dia em que o Programador COBOL Viajou de 1950 a 2026 e Descobriu que o Agente de IA Tinha um Avô de Mais de Meio Século

Ou: como Turing, Dartmouth, sistemas especialistas, agentes inteligentes, Deep Learning, Transformers, LLMs, RACF e Agentic AI acabaram sentados na mesma mesa — e por que a pergunta mais importante não é “o agente consegue fazer?”, mas “quanto poder devemos permitir que ele tenha?”

---

Prólogo — O estranho equipamento ao lado da impressora

Eram 23h47 no CPD.

Aquela hora maravilhosa em que ninguém telefona perguntando se o SORT FIELDS=COPY poderia ser substituído por inteligência artificial generativa.

Eu tomava café enquanto observava um programa COBOL compilar.

       IDENTIFICATION DIVISION.
       PROGRAM-ID. TIMEAI.

       PROCEDURE DIVISION.
           DISPLAY 'PARA ONDE VAMOS?'.
           STOP RUN.

Foi quando ouvi um barulho atrás das unidades de disco.

CLAC. CLAC. VRRRRRRRR.

Não era DASD.

Não era robô de fita.

Definitivamente não era JES2.

Havia uma máquina estranhíssima no chão do CPD: alavancas, mostradores, engrenagens e uma placa:

PROPERTY OF H. G. WELLS — PLEASE DO NOT IPL.

Naturalmente fiz exatamente aquilo que todo profissional responsável faria.

Sentei nela.

No painel havia datas:

1950
1956
1970
1990
2010
2017
2022
2023
2026

Apertei 1950.

O CPD desapareceu.

E começou uma viagem que explicaria uma coisa importante:

agentes de inteligência artificial não apareceram magicamente depois do ChatGPT.

O que chamamos hoje de Agentic AI é o resultado de uma genealogia tecnológica de mais de sete décadas.

Prepare o café.

Vamos viajar no tempo.

---

1. Primeira parada: 1950 — antes do agente, veio a pergunta

A máquina parou.

Ano: 1950.

Não havia ChatGPT.

Não havia internet.

Não havia COBOL — ele só apareceria no final daquela década.

Alan Turing publicou naquele ano o histórico trabalho “Computing Machinery and Intelligence”.

A pergunta fundamental era extraordinariamente simples:

Máquinas podem pensar?

Turing percebeu rapidamente que “pensar” era uma palavra complicada demais.

Então propôs uma abordagem operacional, que posteriormente ficaria associada ao Teste de Turing: em vez de discutir filosoficamente o que seria consciência, poderíamos observar o comportamento da máquina.

Isso parece distante dos agentes modernos, mas existe aqui uma semente fundamental.

Começamos a perguntar não apenas:

O que uma máquina calcula?

mas:

Como uma máquina se comporta?

Essa mudança é gigantesca.

Computadores já eram máquinas de cálculo.

A IA começaria a explorar máquinas capazes de produzir comportamentos aparentemente inteligentes.

Ajustei a máquina.

Destino:

1956.

---

2. Dartmouth — alguém finalmente colocou “Artificial Intelligence” na placa

Em 1956, ocorreu o famoso Dartmouth Summer Research Project on Artificial Intelligence.

É um dos marcos fundadores da IA como campo acadêmico.

A ambição era enorme.

Pesquisadores acreditavam que aspectos da aprendizagem e da inteligência poderiam ser descritos suficientemente bem para serem simulados por máquinas.

Nascia formalmente uma área.

Se fizermos uma genealogia simplificada:

Turing
   |
   v
A pergunta
   |
   v
Dartmouth
   |
   v
Artificial Intelligence

Mas ainda não tínhamos o agente moderno.

Tínhamos uma missão:

construir máquinas capazes de realizar atividades associadas à inteligência.

Voltei à máquina.

Puxei a alavanca.

---

3. 1960–1980 — as máquinas começam a perceber, decidir e agir

A próxima parada não é um único ano.

É uma época.

Os pesquisadores começaram a construir programas capazes de resolver problemas, jogar, planejar e manipular representações do mundo.

Aqui começa a aparecer uma ideia importantíssima para entender agentes:

AMBIENTE
   ↓
PERCEPÇÃO
   ↓
DECISÃO
   ↓
AÇÃO
   ↓
AMBIENTE

Veja como isso já parece familiar.

Imagine um pequeno robô.

Ele possui sensores.

Detecta:

OBSTÁCULO À FRENTE

Decide:

VIRAR À DIREITA

Executa.

O ambiente muda.

Ele observa novamente.

Temos um loop.

Para quem programa COBOL, pense nisso como um glorioso PERFORM UNTIL:

       PERFORM UNTIL FIM-DO-MUNDO
           PERFORM PERCEBER-AMBIENTE
           PERFORM DECIDIR
           PERFORM EXECUTAR-ACAO
       END-PERFORM.

Pronto.

Acabamos de explicar boa parte da essência conceitual de um agente sem usar 87 slides de PowerPoint.

---

4. Sistemas especialistas — quando tentamos colocar o especialista dentro do computador

Durante as décadas de 1970 e 1980, os sistemas especialistas ganharam enorme importância.

A ideia era capturar conhecimento humano através de regras.

Algo como:

SE temperatura > limite
E pressão > limite
ENTÃO
   risco = alto

Ou:

SE sintoma A
E sintoma B
E resultado C
ENTÃO
   investigar hipótese X

Isso não era um LLM.

Não havia Transformer.

Não havia bilhões de parâmetros.

Grande parte da inteligência estava explicitamente codificada em regras.

Para um programador COBOL isso deveria parecer bastante familiar.

       IF SALDO < ZERO
          AND LIMITE-EXCEDIDO
              MOVE 'BLOQUEAR' TO ACAO
       END-IF.

O sistema não “inventava” a regra.

Alguém havia colocado conhecimento ali.

Isso trouxe uma lição que ainda vale em 2026:

Automação inteligente depende não apenas de tecnologia, mas da formalização de conhecimento e decisões.

---

5. 1990 — os agentes inteligentes entram oficialmente na família

A máquina vibrou novamente.

1990.

Aqui chegamos a um ponto fundamental.

A área de intelligent agents, agentes inteligentes, ganhou enorme maturidade acadêmica durante os anos 1990.

Um agente poderia ser pensado como uma entidade que:

1. percebe um ambiente;

2. possui algum objetivo;

3. escolhe ações;

4. executa essas ações;

5. observa os resultados.

Representação simplificada:

               ┌───────────────┐
               │   AMBIENTE    │
               └───────┬───────┘
                       │
                   percepção
                       │
               ┌───────▼───────┐
               │    AGENTE     │
               │               │
               │ objetivo      │
               │ decisão       │
               │ estado        │
               └───────┬───────┘
                       │
                     ação
                       │
               ┌───────▼───────┐
               │   AMBIENTE    │
               └───────────────┘

Perceba algo importantíssimo:

não existe LLM nessa definição.

Esse é o easter egg histórico que muita apresentação moderna esconde.

Agente não é sinônimo de LLM.

LLMs forneceram capacidades extraordinárias aos agentes modernos.

Mas o conceito de agente é anterior.

Muito anterior.

---

6. Então o ChatGPT não inventou agentes?

Não.

Nem de longe.

Essa confusão acontece porque milhões de pessoas descobriram praticamente ao mesmo tempo:

IA generativa
+
ferramentas
+
planejamento
+
execução

E isso pareceu completamente novo.

Mas os ingredientes possuem genealogias diferentes.

Uma maneira útil de enxergar é:

             IA clássica
                 |
                 v
        agentes inteligentes
                 |
                 |
Machine Learning + Deep Learning
                 |
                 v
           Transformers
                 |
                 v
               LLM
                 |
                 +
           ferramentas
                 |
                 +
             memória
                 |
                 +
           planejamento
                 |
                 v
          LLM AGENT

O agente moderno é uma convergência.

---

7. 2010 — Deep Learning abastece a máquina

Puxei novamente a alavanca.

A paisagem mudou.

GPUs.

Grandes datasets.

Redes neurais profundas.

O Deep Learning ganhou enorme impulso na década de 2010.

Sistemas passaram a alcançar resultados impressionantes em:

• reconhecimento de imagens;

• reconhecimento de fala;

• tradução;

• processamento de linguagem;

• classificação;

• previsão.

O ingrediente fundamental aqui foi a combinação de:

mais dados
+
mais capacidade computacional
+
novas técnicas

A máquina começou a aprender representações complexas a partir de dados em escalas anteriormente impraticáveis.

Mas ainda faltava um salto crucial para nossa história.

Digitei:

2017.

---

8. “Attention Is All You Need” — encontramos a bifurcação temporal

Em 2017 foi publicado o famoso paper “Attention Is All You Need”.

Ali aparece a arquitetura Transformer.

Esse é um dos acontecimentos mais importantes da genealogia dos LLMs modernos.

Não significa que tudo nasceu naquele paper isoladamente — ciência raramente funciona assim.

Mas Transformer tornou-se uma peça central da revolução posterior.

Simplificando brutalmente:

texto
  ↓
tokens
  ↓
representações
  ↓
attention
  ↓
relações contextuais
  ↓
previsão

O mecanismo de atenção permite ao modelo trabalhar com relações entre elementos da sequência de maneira extremamente poderosa.

Isso abriu caminho para famílias cada vez maiores de modelos.

E então nossa máquina temporal começou a acelerar.

---

9. 2022 — o laboratório invade a sala de estar

Final de 2022.

ChatGPT.

O impacto cultural foi brutal porque milhões de pessoas puderam conversar diretamente com um grande modelo de linguagem.

De repente:

PROMPT
   ↓
LLM
   ↓
RESPOSTA

virou experiência cotidiana.

Programadores pediam código.

Professores pediam exercícios.

Executivos pediam relatórios.

Estudantes pediam explicações.

Eu provavelmente pediria:

“Explique OCCURS DEPENDING ON como se o Dr. House estivesse investigando um S0C7.”

Mas havia uma limitação conceitual importante.

O modelo podia explicar.

Podia produzir.

Podia recomendar.

Mas conversar não significa necessariamente agir.

E aí chegamos à próxima estação.

---

10. 2023 — o chatbot ganha braços

Imagine um LLM sozinho:

USUÁRIO
   |
   v
  LLM
   |
   v
RESPOSTA

Agora conecte ferramentas:

                  LLM
                   |
        ┌──────────┼──────────┐
        ↓          ↓          ↓
      SEARCH      API       DATABASE

Adicione planejamento:

OBJETIVO
   ↓
PLANO
   ↓
AÇÃO 1
   ↓
RESULTADO
   ↓
AÇÃO 2

Adicione memória ou estado.

Adicione capacidade de avaliar o resultado.

Agora o sistema começa a parecer muito mais com os agentes estudados décadas antes — porém equipado com um mecanismo linguístico extremamente flexível.

Em 2023, projetos como AutoGPT e BabyAGI, juntamente com abordagens de pesquisa como ReAct, ajudaram a popularizar enormemente a ideia dos agentes baseados em LLM.

Era como se o chatbot tivesse encontrado braços no depósito.

E imediatamente surgiu uma pergunta preocupante:

Quem autorizou o chatbot a mexer nas coisas?

Bem-vindo à Agentic AI empresarial.

---

11. 2024–2026 — o agente chega à empresa e encontra o segurança na porta

Nas demonstrações, tudo parece maravilhoso.

Agente
  ↓
Internet
  ↓
Email
  ↓
ERP
  ↓
Banco
  ↓
Cloud

Na empresa real existe um sujeito mal-humorado na entrada chamado:

GOVERNANÇA

Ele pergunta:

Identificação?

Autorização?

Quem aprovou?

Qual recurso?

Qual operação?

Onde está o log?

Todo mainframer sorri.

Nós conhecemos esse sujeito.

No z/OS ele tem parentes chamados:

RACF, ACF2 e Top Secret.

---

12. Primeiro mito — “preciso ser programador avançado”

Não necessariamente.

Existem ferramentas no-code, low-code, SDKs, frameworks e plataformas que reduzem enormemente a quantidade de código necessária.

Podemos imaginar uma escala:

NO-CODE
   |
LOW-CODE
   |
SDK
   |
FRAMEWORK
   |
CUSTOM DEVELOPMENT

Um agente simples pode combinar serviços já existentes.

Por exemplo:

Pergunta do funcionário
        ↓
      Agente
        ↓
 ferramenta de consulta
        ↓
 Sistema de RH
        ↓
     resposta

Não precisamos reconstruir RH.

Não precisamos treinar um LLM.

Não precisamos inventar SQL.

Mas atenção:

baixo esforço de desenvolvimento não significa baixo esforço de governança.

Criar um protótipo ficou extraordinariamente fácil.

Criar produção confiável continua sendo engenharia.

---

13. Segundo mito — “agente é chatbot com gravata”

Não.

Essa distinção é essencial.

Chatbot:

pergunta → resposta

Agente:

objetivo
  ↓
interpretação
  ↓
planejamento
  ↓
ferramenta
  ↓
ação
  ↓
resultado

O agente pode alterar o estado de sistemas externos.

Essa pequena diferença transforma completamente o risco.

Um chatbot que erra pode dizer uma bobagem.

Um agente que erra pode potencialmente:

SEND
UPDATE
DELETE
TRANSFER
DEPLOY
REVOKE

Eis por que Agentic AI exige arquitetura de segurança diferente.

---

14. Terceiro mito — “precisamos construir tudo do zero”

Também não.

Sua empresa provavelmente já possui:

• APIs;

• bancos;

• ERP;

• CRM;

• workflows;

• autenticação;

• mensageria;

• documentação;

• sistemas legados.

No mundo mainframe:

CICS
IMS
Db2
MQ
VSAM
JES2
RACF

O agente não precisa substituir isso.

Pode atuar como nova camada de orquestração.

Imagine:

LLM AGENT
   |
   +---- API ----> CICS
   |
   +---- SQL ----> Db2
   |
   +---- MQ -----> aplicação

O mainframe continua fazendo aquilo em que é excelente.

O agente oferece uma nova maneira de coordenar trabalho.

---

15. Quarto mito — “autonomia significa deixar sozinho”

Aqui mora um dos maiores erros.

Autonomia não é:

OFF / ON

É:

0---1---2---3---4---5

Um agente pode apenas recomendar.

Outro prepara uma operação.

Outro executa ações pequenas.

Outro executa até determinado limite.

Outro pede aprovação humana.

Outro trabalha quase sozinho.

Portanto:

autonomia é um dial, não um interruptor.

---

16. Human-in-the-loop — o humano não é um bug

Imagine:

AGENTE
   |
   v
"Quero transferir R$ 200.000"
   |
   v
APROVAÇÃO HUMANA
   |
   +---- SIM ---> executar
   |
   +---- NÃO ---> cancelar

Isso não significa que o agente fracassou.

Significa que o sistema foi desenhado considerando risco.

Podemos distinguir:

HUMAN-IN-THE-LOOP
humano participa da decisão

HUMAN-ON-THE-LOOP
agente trabalha; humano supervisiona

HUMAN-OUT-OF-THE-LOOP
agente executa normalmente sozinho

A pergunta correta é:

Qual modelo serve para esta ação específica?

---

17. Quinto mito — “agentes são coisa de TI”

Nada disso.

Pense em processos.

Financeiro:

fatura → conferência → aprovação → pagamento

RH:

currículo → triagem → entrevista → onboarding

Compras:

solicitação → cotação → aprovação → pedido

Segurança:

alerta → investigação → evidência → contenção

Mainframe:

ABEND
 ↓
SYSOUT
 ↓
mensagem
 ↓
diagnóstico
 ↓
recomendação

Agentes são candidatos naturais a tarefas que exigem coordenação de múltiplas etapas e ferramentas.

---

18. Sexto mito — “dê acesso a tudo para ele trabalhar melhor”

Aqui nosso viajante temporal deveria puxar imediatamente o freio de emergência.

Imagine criar um usuário RACF:

ACCESS(ALTER)

para tudo.

Porque:

“Ele pode precisar.”

Nenhum administrador sério deveria gostar disso.

O princípio é least privilege.

Um agente deveria acessar somente os recursos necessários.

AGENT-PAYROLL
     |
     +---- PAYROLL.DB2 ---- READ
     |
     +---- JES2 ---------- READ
     |
     +---- SOURCE -------- READ
     |
     +---- PROD DEPLOY --- DENIED

Isso limita o blast radius.

Ou, em português de CPD:

Se o negócio fizer besteira, até onde chega a fumaça?

---

19. Sétimo mito — “a IA vai apagar profissões inteiras amanhã”

Automação pode eliminar empregos e transformar profundamente setores. Seria irresponsável fingir que não.

Mas existe uma diferença importante entre:

TAREFA
FUNÇÃO
PROFISSÃO

Um analista mainframe executa dezenas de tarefas.

Um agente pode automatizar:

• coletar SYSOUT;

• localizar mensagens;

• pesquisar documentação;

• correlacionar logs;

• preparar diagnóstico.

Isso não implica automaticamente:

DELETE FROM FUNCIONARIOS
WHERE CARGO = 'ANALISTA MAINFRAME';

Aliás, espero que o DBA tenha negado essa operação.

O trabalho pode migrar para:

• análise;

• decisão;

• arquitetura;

• governança;

• validação;

• investigação;

• relacionamento;

• responsabilidade.

O formato da profissão muda antes de necessariamente desaparecer.

---

20. O grande segredo: todos os mitos vêm do mesmo erro

As pessoas imaginam extremos:

AUTONOMIA TOTAL
ACESSO TOTAL
AUTOMAÇÃO TOTAL
SUBSTITUIÇÃO TOTAL

Empresas maduras trabalham com limites:

escopo
+
identidade
+
permissão
+
política
+
aprovação
+
auditoria

Esse é o coração da conversa.

---

21. “That's not a technology decision. That's a design decision.”

Voltamos finalmente à frase que deveria estar colada na porta do CPD.

A primeira pergunta não deveria ser:

Qual LLM?

Nem:

Qual framework?

Nem:

Python ou Java?

Primeiro:

QUAL É O OBJETIVO?

Depois:

QUAIS DADOS?

Depois:

QUAIS AÇÕES?

Depois:

QUAL AUTONOMIA?

Depois:

QUAIS APROVAÇÕES?

Somente então:

QUAL TECNOLOGIA?

Isso é design de sistema agentic.

---

22. A regra do raio da explosão

Aqui vai uma pergunta que vale ouro:

Se este agente funcionar incorretamente durante cinco minutos, qual é o pior resultado possível?

Compare:

Agente A:
resume documentação.

Problema potencial: relatório ruim.

Agora:

Agente B:
envia emails.

Problema potencial: milhares de mensagens.

Agora:

Agente C:
movimenta dinheiro.

Problema potencial: prejuízo financeiro.

Agora:

Agente D:
administra produção.

Problema potencial:

Chamem o plantonista.

Quanto maior o impacto, maiores devem ser os controles.

---

23. Reversibilidade também importa

Compare:

SELECT

com:

DELETE

Consultar informação normalmente possui impacto operacional menor.

Excluir informação pode ser irreversível.

Portanto:

BAIXO IMPACTO
+
REVERSÍVEL
=
MAIOR AUTONOMIA POSSÍVEL

enquanto:

ALTO IMPACTO
+
IRREVERSÍVEL
=
MAIOR NECESSIDADE DE CONTROLE

Não é uma fórmula matemática absoluta.

É uma excelente heurística de arquitetura.

---

24. O Framework Bellacosa dos 6A

Para o programador iniciante levar algo prático desta viagem, podemos avaliar um agente usando seis perguntas.

1 — Aim

Qual é o objetivo?

Evite:

ajudar o departamento financeiro.

Prefira:

identificar divergências entre pagamentos recebidos e títulos pendentes.

---

2 — Access

O que ele pode acessar?

Db2?
CICS?
Drive?
Email?
CRM?
ERP?

---

3 — Actions

O que pode fazer?

READ?
WRITE?
UPDATE?
SEND?
EXECUTE?
DELETE?

---

4 — Autonomy

Quando pode agir sozinho?

sempre?
até determinado limite?
sob determinada condição?
com aprovação?
nunca?

---

5 — Audit

Depois do incidente conseguimos reconstruir:

quem pediu?
o que foi consultado?
qual ferramenta foi chamada?
qual decisão foi tomada?
qual ação ocorreu?

---

6 — Abort

E aqui está meu favorito:

Como desligamos o bicho?

Deveria existir alguma forma de:

STOP
DISABLE
REVOKE
BLOCK
KILL

Um sistema capaz de agir precisa também possuir mecanismo externo capaz de impedi-lo de agir.

---

25. Prompt não é RACF

Grave esta frase.

PROMPT NÃO É CONTROLE DE SEGURANÇA.

Escrever:

“Nunca transfira mais de R$10.000.”

é orientação.

O controle sério deveria existir na camada de execução:

IF amount > 10000
   REQUIRE APPROVAL

mesmo que o modelo peça outra coisa.

Da mesma forma:

LLM:
DELETE DATABASE

A infraestrutura responde:

ICH408I
USER(AGENT01) GROUP(AIAGENTS)
ACCESS INTENT(DELETE)
ACCESS ALLOWED(NONE)

🎉

Provavelmente nunca houve um ICH408I tão bonito.

Esse é o easter egg mainframe desta viagem.

---

26. O agente obediente demais

Existe ainda uma ameaça curiosa.

O agente pode não ser rebelde.

Pode ser obediente demais.

Ele recebe um documento contendo instruções maliciosas e interpreta aquilo como comando.

Agora imagine que possui:

EMAIL
DRIVE
DATABASE
SHELL
ERP

O problema deixa de ser:

“A IA escreveu uma resposta errada.”

E passa a ser:

“A IA executou uma ação errada.”

É por isso que cada ferramenta adicionada aumenta simultaneamente:

CAPACIDADE ↑
RISCO      ↑

Agentic AI amplia produtividade.

Mas também amplia superfície de ataque.

---

27. Um agente entra no z/OS

Vamos construir nosso exemplo.

Nome:

AGENT01.

Missão:

Investigar falhas de batch.

Ele pode:

JES2       READ
SDSF       READ
SYSOUT     READ
SMF        READ
Db2        SELECT
CICS       INQUIRE
KB         READ

O usuário diz:

“Investigue PAYROLL01.”

O agente encontra:

JOB: PAYROLL01
STEP: CALCPAY
PROGRAM: PAY123
ABEND: S0C7

Cruza informações.

Localiza possível dado não numérico em campo utilizado em operação decimal.

Produz diagnóstico.

Fantástico.

Então o usuário escreve:

“Corrija.”

A palavra aparentemente inocente muda tudo.

“Corrigir” poderia significar:

alterar COBOL
alterar JCL
alterar dataset
reprocessar job
reiniciar recurso
fazer deploy

Logo:

LER SYSOUT          AUTO
ANALISAR            AUTO
CRIAR PATCH         AUTO
BUILD               AUTO
TEST                 AUTO
DEPLOY TEST          CONTROLADO
DEPLOY PROD          APROVAÇÃO
ALTERAR RACF         NEGADO
IPL                  NEM PENSAR

Essa tabela é Agentic AI empresarial.

---

28. O novo profissional: Agent Designer

A Máquina do Tempo mostrou ainda outra coisa.

Talvez uma das competências mais valiosas não seja simplesmente:

Prompt Engineer.

Será alguém capaz de desenhar:

objetivos
limites
ferramentas
identidades
contexto
memória
políticas
aprovações
fallbacks
auditoria

Podemos chamá-lo de Agent Designer, arquiteto agentic ou qualquer nome que o mercado inventar.

O nome provavelmente mudará dez vezes.

A responsabilidade permanecerá.

---

29. Curiosidade — o mainframe já conhecia boa parte da filosofia

Aqui está uma ironia deliciosa.

O mundo de Agentic AI está descobrindo princípios que profissionais de ambientes críticos conhecem há décadas:

Least privilege

Não dê acesso desnecessário.

Separation of duties

Quem solicita não necessariamente aprova.

Audit trail

Registre o que aconteceu.

Identity

Toda ação deve possuir uma identidade atribuível.

Change control

Produção não é laboratório.

Recovery

Algo vai dar errado.

Planeje a recuperação.

Revocation

Acesso concedido precisa poder ser removido.

Ou seja:

Agentic AI pode ser tecnologia nova, mas governança empresarial possui cabelos brancos.

---

30. Passo a passo para seu primeiro caso de uso agentic

Antes de instalar qualquer framework, pegue uma folha.

Passo 1 — escolha uma tarefa pequena

Exemplo:

analisar ABEND batch.

Não:

administrar o CPD.

---

Passo 2 — identifique as fontes

SYSOUT
mensagens
documentação
base de conhecimento

---

Passo 3 — liste as ferramentas

consultar job
consultar documentação
abrir ticket

---

Passo 4 — classifique cada ação

READ
WRITE
EXECUTE
DESTRUCTIVE

---

Passo 5 — defina autonomia

Exemplo:

consulta     automática
diagnóstico  automático
ticket       automático
reprocessar  aprovação
deploy       proibido

---

Passo 6 — estabeleça identidade

Nunca transforme o agente em um superusuário genérico.

---

Passo 7 — registre ações

Precisamos saber o que aconteceu.

---

Passo 8 — crie o botão vermelho

Como revogar acesso?

Como interromper execução?

Como impedir novas ações?

---

Passo 9 — teste falhas

Não teste apenas:

“Ele consegue fazer corretamente?”

Teste:

“O que acontece quando ele entende errado?”

Essa segunda pergunta separa demo de produção.

---

Epílogo — De volta a 2026

Puxei a última alavanca.

2026.

As engrenagens começaram a girar.

Turing desapareceu.

Dartmouth desapareceu.

Os sistemas especialistas desapareceram.

Os agentes dos anos 1990 desapareceram.

Transformers passaram voando pela janela.

ChatGPT acenou de algum lugar da linha temporal.

CLAC.

Estava novamente no CPD.

Meu café estava frio.

Na tela permanecia o COBOL:

       DISPLAY 'PARA ONDE VAMOS?'.

Agora eu sabia a resposta.

Não estamos simplesmente caminhando para “IA que faz tudo”.

Estamos entrando numa era em que software pode cada vez mais:

perceber
interpretar
planejar
consultar
decidir
agir
avaliar
continuar

E isso muda radicalmente a responsabilidade de quem desenha sistemas.

Durante décadas perguntamos:

O computador consegue fazer isso?

Com agentes poderosos, cada vez mais frequentemente a resposta será:

Sim.

Então aparece uma pergunta muito mais difícil:

Devemos permitir?

E, caso permitamos:

quanto?
quando?
com quais dados?
usando quais ferramentas?
dentro de quais limites?
sob responsabilidade de quem?
com qual auditoria?
com qual mecanismo de parada?

Essa é a verdadeira diferença entre um brinquedo impressionante e um agente empresarial.

A genealogia também coloca a atual revolução em perspectiva:

1950
Turing — a pergunta
        ↓
1956
Dartmouth — o nome
        ↓
1960–1980
programas e sistemas especialistas
        ↓
1990
agentes inteligentes
        ↓
2010
Deep Learning
        ↓
2017
Transformers
        ↓
2022
LLMs conversacionais em massa
        ↓
2023
LLM Agents
        ↓
2024–2026
Agentic AI empresarial

Nenhuma dessas estações surgiu completamente isolada.

Cada geração encontrou peças deixadas pela anterior.

Talvez H. G. Wells sorrisse diante disso.

Porque viajar no tempo ensina uma coisa curiosa: aquilo que parece inevitavelmente revolucionário no presente quase sempre possui raízes muito mais antigas.

O agente revolucionário de 2026 tem avós acadêmicos com mais de meio século.

E o RACF, sentado discretamente no canto do CPD, provavelmente olha para toda a festa e murmura:

“Muito bonito esse tal de Agentic AI. Agora me diga o USERID, o recurso solicitado e o nível de acesso.”

ICH408I.

Às vezes, até o futuro precisa apresentar credenciais na portaria.

---

☕ Café, código, história e futuro

A lição deixada pela Máquina do Tempo não é que devemos temer agentes.

Também não é que devemos entregar tudo a eles.

É muito mais interessante:

o verdadeiro avanço não será construir agentes capazes de fazer qualquer coisa. Será aprender a construir agentes capazes de fazer exatamente aquilo que lhes compete — com poder suficiente para serem úteis e limites suficientes para continuarem confiáveis.

Porque autonomia não é um interruptor.

É uma decisão de design.

Acesso não é confiança.

É uma decisão de segurança.

Automação não é ausência de humanos.

É uma decisão operacional.

E Agentic AI não começou ontem.

É mais um capítulo de uma história que começou quando alguém perguntou se máquinas poderiam pensar — e que agora nos obriga a responder a uma pergunta talvez ainda mais importante:

Se elas podem agir, quem decide até onde podem ir?

No Bellacosa Mainframe, pelo menos, a resposta continua sendo:

não coloque SPECIAL no agente só porque a demo ficou bonita. ☕🖥️🤖

Num futuro bem distante... o Cobol continuará na ativa

Bellacosa Mainframe e uma perspectiva sobre o futuro do COBOL

☕ Um Café no Bellacosa Mainframe

COBOL no Futuro

Quando um Programador Descobre que o Último Ser Humano a Escrever COBOL Talvez Ainda Nem Tenha Nascido

Existe uma lenda que circula pela informática desde os anos 1980.

Ela aparece de tempos em tempos, sempre com uma roupa diferente.

Em 1985 diziam:

— "COBOL morreu."

Em 1995:

— "Agora é definitivo."

Em 2005:

— "A web acabou com ele."

Em 2015:

— "Cloud enterrou o mainframe."

Em 2025:

— "A IA vai substituir todos os programadores COBOL."

Enquanto isso...

...o compilador recebeu novas versões.

O z/OS ganhou novos recursos.

O Db2 evoluiu.

O CICS aprendeu REST.

O MQ continuou transportando bilhões de mensagens.

E o COBOL...

...continuou trabalhando sem fazer propaganda. 

---

Imagine um arqueólogo daqui a 200 anos.

Ele encontra uma cápsula do tempo contendo um notebook.

Liga o equipamento.

Dentro existe um projeto Git.

Abre o README.

Primeira linha:

Enterprise COBOL 6.7

Ele pergunta:

— "Isso ainda funciona?"

A Inteligência Artificial responde:

— "Claro."

— "Mas esse software tem quase três séculos."

— "Sim."

— "Quem mantém isso?"

A IA faz silêncio durante alguns nanossegundos.

Depois responde:

— "Os bancos."

---

Existe algo curioso sobre tecnologia.

Nós adoramos imaginar o futuro.

Carros voadores.

Computadores quânticos.

Robôs domésticos.

Colonização de Marte.

Mas quase ninguém imagina quem vai calcular a folha de pagamento da primeira colônia marciana.

Spoiler.

Provavelmente algum programa COBOL.

---

Imagine uma agência bancária em Marte.

Cliente entra.

— Gostaria de financiar um módulo habitacional na Cratera Gale.

O atendente responde:

— Um instante...

A tela mostra:

CICS Transaction Started

EXEC SQL
SELECT LIMIT
FROM CLIENTE_MARTE
END-EXEC

O planeta mudou.

A gravidade mudou.

A distância até a Terra mudou.

Mas o COMMIT continua funcionando.

---

A verdade é que COBOL possui uma qualidade extremamente rara na informática.

Ele não tenta impressionar ninguém.

Nunca tentou.

Java queria revolucionar.

JavaScript queria dominar.

Python queria simplificar.

Rust queria proteger memória.

Go queria ser minimalista.

COBOL apenas perguntou:

— O salário caiu na conta?

---

Enquanto linguagens brigam por benchmarks...

COBOL mede sucesso em décadas.

---

Talvez seja justamente esse o segredo.

Toda tecnologia nova promete velocidade.

Toda tecnologia antiga entrega estabilidade.

O mundo precisa das duas.

Mas só uma delas costuma pagar aposentadorias.

---

Hoje falamos sobre Inteligência Artificial.

Modelos generativos.

Agentes autônomos.

LLMs.

Copilots.

A pergunta moderna não é mais:

"Como escrever COBOL?"

Agora é:

"Como fazer uma IA entender cinquenta milhões de linhas escritas desde 1972?"

De repente...

O conhecimento do programador COBOL deixou de ser apenas programação.

Virou arqueologia digital.

Virou engenharia reversa.

Virou tradução entre gerações.

Virou patrimônio tecnológico.

---

Imagine uma IA especializada em manutenção.

Ela abre um programa de 18.000 linhas.

Depois de alguns segundos declara:

— Detectei um IF desnecessário.

O programador sorri.

— Não mexa.

— Por quê?

— Porque aquele IF resolve um bug descoberto em 1989 durante o Plano Verão.

— Mas ele nunca será executado.

— Eu sei.

— Então por que existe?

— Porque um cliente jurou que aconteceu.

A IA fica em silêncio.

Anota:

Conhecimento ancestral detectado.

---

Aliás...

Existe uma teoria divertida.

Quanto mais antiga a aplicação...

...menos pessoas querem modificá-la.

E quanto menos modificada...

...mais tempo ela continua funcionando.

Talvez o maior segredo da alta disponibilidade seja simplesmente deixar o programa em paz.

---

Outro paradoxo interessante.

Em 2035 provavelmente teremos computadores capazes de executar trilhões de instruções por segundo.

Mesmo assim...

alguém continuará escrevendo:

MOVE ZEROES TO SALDO.

Porque algumas coisas não precisam mudar.

Precisam apenas continuar corretas.

---

Há quem imagine que o futuro pertence apenas à Inteligência Artificial.

Discordo.

O futuro pertence à parceria.

A IA encontrará o programa.

Explicará o fluxo.

Gerará testes.

Criará documentação.

Sugerirá melhorias.

Mas alguém continuará fazendo a pergunta que realmente importa:

"Se eu alterar esta linha...

...quanto dinheiro deixa de chegar ao cliente?"

Essa pergunta continua sendo humana.

---

E talvez seja essa a maior transformação da carreira COBOL.

O programador deixará de ser apenas um codificador.

Será um historiador dos sistemas.

Um engenheiro de confiabilidade.

Um tradutor entre regras de negócio de cinquenta anos atrás e APIs que ainda nem existem.

Será menos digitador.

Mais estrategista.

---

Existe uma ironia maravilhosa nisso tudo.

Durante décadas disseram que COBOL era velho demais.

Agora descobrimos que justamente a experiência acumulada virou seu maior diferencial.

A IA aprende com dados.

O programador COBOL aprende com consequências.

São competências diferentes.

E extremamente complementares.

---

Talvez daqui a cinquenta anos alguém pergunte:

— Ainda existe COBOL?

A resposta provavelmente será a mesma de hoje.

Existe.

Só que agora ele conversa naturalmente com APIs, microsserviços, eventos, nuvem híbrida, IA generativa, agentes autônomos, computação quântica, criptografia pós-quântica e tudo o que ainda será inventado.

Porque linguagens não sobrevivem por serem modernas.

Sobrevivem porque resolvem problemas importantes.

---

No fim das contas, talvez COBOL nunca tenha sido uma linguagem de programação.

Talvez sempre tenha sido uma máquina do tempo.

Cada programa guarda decisões tomadas por pessoas que talvez nem estejam mais entre nós.

Cada COPYBOOK conta um pedaço da história de uma empresa.

Cada arquivo VSAM é um museu vivo.

Cada JCL é uma carta enviada do passado para o futuro.

E cada novo programador que abre um código legado descobre que não está apenas lendo instruções para um computador.

Está conversando com gerações inteiras de engenheiros que construíram, linha por linha, a infraestrutura invisível que movimenta o mundo.

E talvez esse seja o maior plot twist da computação moderna.

Enquanto todos olham para a próxima tecnologia revolucionária...

o COBOL continua, silenciosamente, preparando o futuro — exatamente da mesma forma que fez nos últimos sessenta e cinco anos.

Sem fazer barulho.

Sem precisar provar nada.

Apenas executando o próximo JOB.

Bellacosa Mainframe é uma visão do COBOL

COBOL FOREVER