SQL versus NoSQL: A Guerra que Nunca Existiu (e por que todo Programador COBOL deveria entender os dois)

 

Bellacosa Mainframe numa guerra que nunca existiu sql versus nosql

☕ Um Café no Bellacosa Mainframe

SQL versus NoSQL: A Guerra que Nunca Existiu (e por que todo Programador COBOL deveria entender os dois)

"A tecnologia muda. Os princípios permanecem."

Imagine que você acabou de entrar em uma grande empresa. É seu primeiro emprego como programador COBOL. Você acabou de aprender JCL, já conseguiu fazer seu primeiro programa rodar no z/OS, descobriu o que é um Job, um Dataset e finalmente conseguiu fazer um SELECT sem esquecer o END-EXEC.

Então alguém da equipe comenta durante uma reunião:

"Estamos integrando o Mainframe com MongoDB."

Cinco minutos depois outro colega fala:

"Os dados vão para Redis."

Na sequência o arquiteto comenta:

"O Neo4j será usado para análise de fraude."

Você pensa:

"Mas... eu aprendi SQL... o que aconteceu? Agora existem quatro bancos diferentes?"

Bem-vindo ao desenvolvimento moderno.

Hoje vamos conversar sobre uma das maiores dúvidas de quem está começando:

SQL ou NoSQL?

Spoiler...

A resposta é muito diferente do que a internet costuma vender.

Pegue seu café.

Vamos conversar.

---

O mito da guerra

Existe uma narrativa que aparece em vídeos, blogs e redes sociais dizendo que:

SQL morreu.

Ou então:

NoSQL veio substituir os bancos relacionais.

Nada poderia estar mais distante da realidade.

Na verdade, SQL nunca esteve tão vivo.

E NoSQL nunca tentou matá-lo.

Os dois nasceram para resolver problemas completamente diferentes.

É como comparar:

• um caminhão

• um avião

Qual é melhor?

Depende.

Você quer transportar cimento entre cidades?

Ou cruzar o oceano?

A pergunta está errada.

Da mesma forma:

A pergunta nunca foi SQL versus NoSQL.

A pergunta correta sempre foi:

Qual tecnologia resolve melhor ESTE problema?

---

Uma pequena viagem no tempo

Imagine que estamos em 1970.

Os computadores ocupavam salas inteiras.

Não existia internet.

Não existia smartphone.

Nem notebook.

Muito menos Cloud.

Os bancos de dados funcionavam quase como arquivos gigantes.

Era preciso conhecer exatamente onde cada informação estava gravada.

Era complicado.

Foi então que um pesquisador da IBM chamado Edgar Frank Codd publicou um artigo que mudaria para sempre a computação:

A Relational Model of Data for Large Shared Data Banks

Esse trabalho apresentou uma ideia brilhante.

Em vez de pensar em ponteiros físicos...

Vamos pensar em relações.

Assim nasceram:

• tabelas

• linhas

• colunas

• chaves

• relacionamentos

Nascia o Modelo Relacional.

Poucos anos depois, a própria IBM desenvolveu o System R, um projeto experimental que introduziu a linguagem SQL (Structured Query Language). A ideia mostrou tanto potencial que outras empresas passaram a investir no modelo, surgindo plataformas como Oracle, Informix, SQL Server, PostgreSQL, MySQL e, naturalmente, o Db2, um dos pilares do universo IBM Mainframe.

---

Por que o SQL fez tanto sucesso?

Porque ele resolveu um problema gigantesco.

Imagine um banco.

Existem milhões de clientes.

Cada cliente possui:

• conta corrente

• poupança

• investimentos

• cartões

• empréstimos

Tudo isso precisa estar relacionado.

Se João mudar de endereço...

Não faz sentido atualizar vinte lugares diferentes.

O SQL organiza essas informações em tabelas relacionadas, reduzindo redundâncias e garantindo consistência.

Esse conceito recebe o nome de normalização.

Parece um detalhe.

Na prática...

Economizou bilhões de dólares em armazenamento ao longo da história.

---

ACID: o superpoder invisível

Existe um conceito que todo programador júnior deveria decorar.

ACID.

Não porque cai em entrevista.

Mas porque explica por que bancos confiam tanto em SQL.

Imagine transferir R$ 500 de uma conta para outra.

São duas operações:

• retirar da Conta A

• adicionar na Conta B

E se faltar energia exatamente no meio?

ACID garante que isso não aconteça.

Ou tudo acontece...

Ou nada acontece.

Isso é chamado de Atomicidade.

Depois temos:

Consistência

Os dados permanecem válidos.

Isolamento

Milhares de pessoas podem operar simultaneamente sem "atropelar" umas às outras.

Durabilidade

Depois do COMMIT...

Mesmo que o servidor desligue...

Os dados continuam lá.

É por isso que bancos, seguradoras e bolsas de valores continuam confiando em bancos relacionais.

---

Onde entra o Mainframe?

Agora vem uma curiosidade que muita gente desconhece.

Grande parte do dinheiro que circula diariamente no mundo passa por Mainframes.

Cartões.

PIX.

TED.

DOC.

Compras internacionais.

Folha de pagamento.

Seguros.

Tudo isso frequentemente passa por sistemas COBOL utilizando Db2 for z/OS.

Quando você escreve:

EXEC SQL

SELECT SALDO

INTO :WS-SALDO

FROM CONTAS

WHERE NUMERO = :WS-CONTA

END-EXEC.

O SQL não está apenas buscando dados.

Existe todo um universo trabalhando por trás:

• Pré-compilador SQL

• DBRM

• Package

• Bind

• Plan

• Otimizador

• Buffer Pools

• Logging

• Locking

• Recovery

O desenvolvedor enxerga apenas a ponta do iceberg.

---

Então por que surgiu o NoSQL?

Porque o mundo mudou.

Muito.

Em 1970 ninguém imaginava redes sociais.

Nem streaming.

Nem IoT.

Nem celulares.

Nem milhões de fotos por minuto.

Agora imagine armazenar:

• vídeos

• comentários

• curtidas

• localização

• mensagens

• sensores

• documentos JSON

Tudo isso em tabelas relacionais.

Funciona?

Sim.

Mas nem sempre é a melhor escolha.

Foi então que surgiu o movimento NoSQL.

Curiosamente...

NoSQL não significa "Sem SQL".

Significa:

Not Only SQL

Ou seja...

Existem outros modelos além do relacional.

---

Os quatro reinos do NoSQL

Quando alguém diz "NoSQL", na verdade está falando de uma família inteira de bancos.

📄 Documento

Exemplo:

MongoDB.

Os dados ficam parecidos com JSON.

Cada documento pode possuir uma estrutura diferente.

Perfeito para aplicações web.

---

🔑 Chave-Valor

Exemplo:

Redis.

Imagine um gigantesco dicionário.

Você fornece uma chave.

Recebe um valor.

Extremamente rápido.

Muito utilizado como cache.

---

📚 Colunar

Exemplos:

Cassandra.

ScyllaDB.

HBase.

Projetados para trabalhar com enormes volumes distribuídos.

Muito utilizados em Big Data.

---

🌐 Grafos

Exemplo:

Neo4j.

Aqui o importante não são os registros.

São os relacionamentos.

Quem conhece quem?

Quem comprou junto?

Quem transferiu dinheiro para quem?

Ideal para detectar fraudes.

---

SQL é rígido?

Sim.

E isso é uma vantagem.

Imagine um cadastro de funcionários.

Todos possuem:

• matrícula

• nome

• salário

• departamento

É ótimo exigir que todos tenham exatamente a mesma estrutura.

Já em uma rede social...

Cada usuário pode possuir informações diferentes.

Uns possuem Instagram.

Outros TikTok.

Outros LinkedIn.

Outros nenhum.

Forçar uma estrutura única pode ser desnecessário.

É aí que bancos orientados a documentos brilham.

---

Escalabilidade

Existe outra diferença importante.

Tradicionalmente, bancos SQL cresceram na vertical.

Mais CPU.

Mais memória.

Mais discos.

Servidor maior.

Já muitos bancos NoSQL foram desenhados pensando em crescer horizontalmente.

Mais servidores.

Mais nós.

Mais máquinas.

É o modelo utilizado por empresas como Google, Amazon, Netflix e Meta.

Mas atenção: hoje essa divisão não é absoluta. Bancos relacionais modernos também oferecem mecanismos de escalabilidade horizontal, e diversas soluções NoSQL implementam recursos avançados de consistência e transações.

---

SQL também evoluiu

Existe outro mito.

"O SQL parou no tempo."

Errado.

Hoje temos:

• JSON dentro do PostgreSQL

• JSON no Oracle

• JSON no SQL Server

• JSON no Db2

• XML

• Graph Extensions

• Machine Learning integrado

• Consultas analíticas

• Window Functions

• Compressão avançada

• IA auxiliando otimização

Os bancos relacionais modernos absorveram diversas características que antes eram exclusivas do NoSQL.

---

NoSQL também evoluiu

MongoDB hoje possui:

• transações

• índices sofisticados

• agregações complexas

Redis deixou de ser apenas cache.

Neo4j suporta consultas extremamente sofisticadas.

Cassandra possui consistência configurável.

Ou seja...

Os mundos estão convergindo.

---

O conceito mais importante: Polyglot Persistence

Se existe uma expressão que todo desenvolvedor moderno deveria conhecer é esta:

Polyglot Persistence.

Ela significa:

usar o banco certo para cada problema.

Imagine um banco digital.

Ele pode utilizar:

Db2 → contas correntes

MongoDB → documentos

Redis → cache

Neo4j → fraude

Elastic → pesquisa

Banco Vetorial → IA

Tudo funcionando junto.

Não existe regra dizendo que um sistema deve possuir apenas um banco.

---

O papel do COBOL nessa história

Aqui existe um enorme equívoco.

Muitos imaginam que COBOL só conversa com Db2.

Hoje isso está longe da realidade.

Aplicações COBOL podem consumir:

REST APIs.

MQ.

Kafka.

gRPC.

z/OS Connect.

Eventos.

Microsserviços.

E esses serviços podem acessar MongoDB, Redis ou qualquer outro banco moderno.

O COBOL continua sendo o cérebro transacional.

Os demais componentes ampliam suas capacidades.

---

Dicas para quem está começando

Se eu pudesse aconselhar um programador júnior, seguiria esta ordem:

1. Aprenda modelagem de dados.

2. Domine SQL.

3. Entenda normalização.

4. Aprenda índices.

5. Estude planos de acesso.

6. Descubra como funciona um otimizador.

7. Aprenda transações.

8. Depois estude MongoDB.

9. Conheça Redis.

10. Descubra Neo4j.

11. Aprenda APIs REST.

12. Entenda eventos e mensageria.

A tecnologia muda.

Os fundamentos permanecem.

---

Curiosidades que pouca gente conhece

☕ O primeiro grande projeto SQL da IBM chamava-se System R.

☕ O Db2 nasceu dentro da IBM justamente para materializar as ideias do modelo relacional em ambientes corporativos.

☕ O comando SELECT * é um dos mais utilizados por iniciantes... e um dos menos recomendados em produção. Buscar apenas as colunas necessárias reduz tráfego de dados e melhora o desempenho.

☕ Muitos sistemas bancários escritos há mais de 30 anos continuam processando milhões de transações diariamente com desempenho impressionante.

☕ Redis consegue responder consultas em microssegundos porque mantém os dados principalmente em memória.

☕ Neo4j foi inspirado na Teoria dos Grafos, um ramo da matemática muito mais antigo do que os computadores.

☕ Diversos bancos NoSQL utilizam conceitos publicados em artigos científicos da Google e da Amazon sobre sistemas distribuídos, como Bigtable, Dynamo e MapReduce.

☕ O termo NoSQL surgiu como um movimento alternativo, mas acabou sendo reinterpretado como Not Only SQL, refletindo melhor a realidade atual.

---

Easter Eggs Bellacosa Mainframe 🥚

🔍 Easter Egg #1 – O herói invisível

Sempre que você executa um SELECT no Db2, existe um componente trabalhando silenciosamente para decidir o melhor caminho de acesso: o otimizador de consultas. Ele é como o GPS do banco de dados. Você não o vê, mas ele escolhe a rota mais eficiente.

---

🥚 Easter Egg #2 – O COBOL nunca pergunta "como"

Um programa COBOL com Embedded SQL apenas descreve o que deseja. Quem decide como buscar os dados é o Db2. Essa separação entre intenção e estratégia foi uma das grandes revoluções introduzidas pelo SQL.

---

🥚 Easter Egg #3 – O Mainframe conversa com o futuro

Um programa COBOL criado na década de 1990 pode, com poucas adaptações, consumir uma API REST hospedada na nuvem que, por sua vez, grava documentos em MongoDB e publica eventos em Kafka. O legado não é um obstáculo: ele pode ser parte da arquitetura moderna.

---

🥚 Easter Egg #4 – Nem tudo é tabela

Quando você olhar para uma árvore genealógica, uma rede social ou um mapa de rotas aéreas, pense em grafos. Quando observar um catálogo de produtos com atributos diferentes para cada item, pense em documentos. Quando acessar seu extrato bancário, pense em tabelas relacionais. O segredo está em reconhecer o problema antes de escolher a ferramenta.

---

Conclusão

No fim das contas, SQL e NoSQL não são adversários. São aliados que nasceram em épocas diferentes para enfrentar desafios distintos. O SQL continua sendo o alicerce dos sistemas críticos que exigem consistência, integridade e confiabilidade — exatamente o tipo de ambiente onde o IBM Z e o Db2 brilham há décadas. Já o NoSQL oferece flexibilidade, escalabilidade e modelos especializados que complementam essas capacidades em aplicações modernas, distribuídas e orientadas a dados.

Se você está iniciando sua jornada como programador COBOL ou desenvolvedor Mainframe, não caia na armadilha dos modismos. Aprenda primeiro os fundamentos: modelagem de dados, SQL, índices, transações e otimização de consultas. Esses conhecimentos acompanharão toda a sua carreira. Depois, expanda seus horizontes estudando MongoDB, Redis, Cassandra, Neo4j e outras tecnologias que fazem parte das arquiteturas atuais.

Lembre-se sempre de uma filosofia muito presente no universo Bellacosa Mainframe:

Um excelente desenvolvedor não é aquele que conhece todas as ferramentas, mas aquele que sabe exatamente quando usar cada uma delas.

No mundo do IBM Z, onde convivem sistemas escritos há décadas com APIs, microsserviços, inteligência artificial e computação em nuvem, essa capacidade de escolher a tecnologia certa é o que transforma um programador júnior em um verdadeiro arquiteto de soluções. Afinal, o futuro não pertence ao SQL nem ao NoSQL. Ele pertence aos profissionais que compreendem ambos e conseguem fazê-los trabalhar juntos.

Top 5 na Comunidade Digital Innovation One

Bellacosa Mainframe apresenta a Digital Innovation One

☕ Um Café no Bellacosa Mainframe

Inspetor Bugiganga Entra na DIO: Go-Go-Gadget Developer!

🕵️‍♂️🔧 Bootcamps, cursos, desafios de código, projetos, GitHub, certificados, XP, ranking e aquela estranha sensação de entrar para estudar uma tecnologia e sair querendo aprender outras dez

Existe uma armadilha particularmente perigosa para quem gosta de tecnologia.

Você entra numa plataforma educacional pensando:

“Vou fazer um cursinho.”

Quatro horas depois:

COBOL
 ↓
LINUX
 ↓
GIT
 ↓
PYTHON
 ↓
NODE.JS
 ↓
AWS
 ↓
DOCKER
 ↓
KUBERNETES
 ↓
IA
 ↓
SEGURANÇA
 ↓
MEU DEUS, O QUE ESTOU FAZENDO?

Foi aproximadamente assim que imaginei o Inspetor Bugiganga entrando na Digital Innovation One — DIO.

Ele abre a porta.

Olha para os bootcamps.

Estica um braço mecânico.

Go-Go-Gadget Java!

Outra janela aparece.

Go-Go-Gadget Cloud!

Mais uma.

Go-Go-Gadget Python!

Outra.

Go-Go-Gadget Inteligência Artificial!

Penny observa de longe.

Brain fecha os olhos.

E Dr. Claw provavelmente percebe imediatamente:

“Esse idiota vai matricular-se em tudo.”

Bem-vindo à DIO.

---

🟣 Mas afinal, o que é a DIO?

A Digital Innovation One, conhecida simplesmente como DIO, é uma plataforma de educação tecnológica que construiu seu ecossistema em torno de uma combinação interessante:

CURSOS
+
BOOTCAMPS
+
PROJETOS
+
DESAFIOS
+
CERTIFICADOS
+
COMUNIDADE
+
GAMIFICAÇÃO

Isso muda um pouco a experiência tradicional de estudar tecnologia.

Porque estudar programação normalmente pode ser uma atividade profundamente solitária.

Você.

O computador.

Uma documentação de 847 páginas.

Uma mensagem de erro.

E aquela inevitável pesquisa:

WHY THE HELL IS THIS NOT WORKING

Na DIO existe uma tentativa de transformar essa caminhada em algo mais parecido com uma jornada.

Há progresso.

Há etapas.

Há XP.

Há desafios.

Há projetos.

Há rankings.

Há certificados.

E existe sempre aquela barrinha dizendo:

87%

que produz no cérebro humano uma necessidade quase patológica de chegar a:

100%

Gamificação.

O crack legalizado dos nerds.

---

🕵️ Inspetor Bugiganga recebe sua primeira missão

Chefe Quimby surge misteriosamente dentro de uma máquina de café.

Entrega a mensagem:

SUA MISSÃO:

CONCLUIR O BOOTCAMP
SEM COPIAR O PROJETO
DO INSTRUTOR.

ESTA MENSAGEM
SE AUTODESTRUIRÁ.

Bugiganga lê.

Penny já abriu o GitHub.

Brain está configurando o ambiente.

A mensagem explode na cara do Chefe Quimby.

Tudo normal.

Mas existe aqui uma diferença importante entre assistir a um curso e aprender tecnologia.

Você pode assistir a:

10 horas de Java

e aprender muito pouco.

Pode assistir a:

20 horas de Python

e continuar incapaz de criar sozinho um pequeno programa.

Porque existe uma distância gigantesca entre:

“Eu entendi.”

e:

“Eu consigo fazer.”

A DIO tenta atacar justamente essa distância através dos desafios e projetos.

---

🔧 Go-Go-Gadget Hands-On!

Imagine aprender Git apenas assistindo alguém usar Git.

git init
git add .
git commit
git push

Parece fácil.

Então você tenta sozinho.

fatal:

Ah.

Agora começou a aula verdadeira.

Tecnologia possui uma característica cruel:

ela frequentemente só revela aquilo que você não entendeu quando você tenta fazer sozinho.

Enquanto estamos assistindo ao instrutor:

“Sim.”

“Entendi.”

“Óbvio.”

“Tranquilo.”

Então fechamos o vídeo.

Abrimos o terminal.

_

E o cursor piscando pergunta:

“Então, gênio, por onde começamos?”

Silêncio.

É nesse momento que aprendizado deixa de ser consumo e vira construção.

---

🧠 Penny é a verdadeira desenvolvedora

Quem assistiu ao desenho sabe da verdade.

Inspetor Bugiganga recebe o crédito.

Mas quem resolve grande parte das coisas?

Penny.

Penny investiga.

Penny pesquisa.

Penny utiliza tecnologia.

Penny conecta informações.

Penny encontra o problema.

Brain executa operações de campo que fariam qualquer Red Team pedir orçamento.

Enquanto isso:

Go-Go-Gadget Helicóptero!

Talvez exista aqui uma metáfora perfeita para aprender programação.

O certificado é o Inspetor Bugiganga.

Bonito.

Visível.

Você coloca no LinkedIn.

Mas Penny representa aquilo que realmente interessa:

o conhecimento adquirido durante o caminho.

---

📜 Certificado não compila código

Essa merece destaque.

Você pode possuir:

100 certificados

e ainda assim travar diante de:

Crie uma API REST.

Certificação e certificado possuem valor.

Demonstram esforço.

Criam histórico.

Podem ajudar a organizar aprendizado.

Podem sinalizar interesse profissional.

Mas existe uma pergunta brutal:

Você consegue fazer?

O mercado tecnológico, cedo ou tarde, faz essa pergunta.

Talvez numa entrevista.

Talvez num projeto.

Talvez numa madrugada de produção.

---

🧪 Os desafios de código

Aqui começa a diversão.

Problema:

ENTRADA
 ↓
PROCESSAMENTO
 ↓
SAÍDA ESPERADA

Parece simples.

Até aparecer:

Wrong Answer

Você olha o código.

Está perfeito.

Executa novamente.

Wrong Answer

Você modifica.

Wrong Answer

Consulta documentação.

Wrong Answer

Começa a questionar suas escolhas profissionais.

Então percebe:

espaço adicional na saída

Corrige.

Accepted

Nesse momento ocorre uma pequena descarga de dopamina comparável a derrotar um chefe em videogame.

---

🎮 XP: transformando estudo em RPG

Uma das coisas interessantes do ecossistema DIO é a utilização de elementos de gamificação.

Você estuda.

Conclui atividades.

Avança.

Acumula experiência.

E o cérebro começa a interpretar:

ESTUDAR

como:

EVOLUIR PERSONAGEM

Agora imagine Inspetor Bugiganga.

LEVEL 1
GO-GO-GADGET HTML

Depois:

LEVEL 10
GO-GO-GADGET JAVASCRIPT

Depois:

LEVEL 20
GO-GO-GADGET NODE

Depois:

LEVEL 30
GO-GO-GADGET AWS

Finalmente:

LEVEL 42

Douglas Adams observa do outro lado do universo.

Agora ele encontrou a resposta.

Só falta descobrir a pergunta.

---

🐘 O perigo do buffet tecnológico

Mas existe um problema.

Quando uma plataforma oferece muita coisa interessante, nasce uma criatura perigosa:

o acumulador de cursos.

Ele possui:

17 bootcamps iniciados
43 cursos salvos
28 tecnologias na lista
11 projetos incompletos
97 abas abertas

Conhecimento real:

SELECT *
FROM CEREBRO
WHERE DOMINIO = 'REAL';

Resultado:

0 ROWS RETURNED

Porque existe uma diferença entre explorar e aprender.

---

🕵️ Dr. Claw apresenta o Tutorial Hell

Dr. Claw finalmente revela seu plano maligno.

Não é destruir Bugiganga.

Não é dominar o mundo.

É pior.

Ele prende o desenvolvedor em:

TUTORIAL HELL

O ciclo:

ASSISTE CURSO
     ↓
ENTENDE
     ↓
ASSISTE OUTRO
     ↓
ENTENDE
     ↓
ASSISTE OUTRO
     ↓
ENTENDE
     ↓
TENTA FAZER SOZINHO
     ↓
NÃO CONSEGUE
     ↓
PROCURA OUTRO CURSO

Repita durante cinco anos.

Parabéns.

Você estudou muito.

E construiu quase nada.

---

🛠️ Como escapar?

Professor Penny Bellacosa apresenta a solução:

APRENDER
   ↓
PRATICAR
   ↓
ERRAR
   ↓
DEBUGAR
   ↓
ENTENDER
   ↓
MODIFICAR
   ↓
CONSTRUIR ALGO SEU

O projeto apresentado pelo instrutor deveria ser o começo, não o fim.

Se o curso cria:

API DE LIVROS

faça depois:

API DE FILMES

ou:

API DE CLIENTES

ou:

API DE POKÉMON

ou, naturalmente:

API DE JOBS COBOL QUE DERAM S0C7

Aí começa a aprendizagem real.

---

🦖 E onde entra o velho COBOLzeiro?

Aqui existe uma coisa que considero particularmente interessante.

Plataformas como a DIO são frequentemente associadas à entrada de novos profissionais no mercado.

Mas existe outro público que pode extrair enorme valor delas:

o veterano.

Imagine alguém com décadas de:

COBOL
JCL
CICS
DB2
VSAM
IMS
z/OS

Ele conhece profundamente sistemas empresariais.

Então entra numa trilha de:

Git

Depois:

Python

Depois:

REST APIs

Depois:

Docker

Depois:

Cloud

Depois:

IA

Agora algo interessante acontece.

Ele não deixou de ser mainframe.

Ele criou pontes.

---

🌉 O profissional em T

Existe uma velha ideia sobre profissionais com conhecimento em formato de T.

Horizontal:

────────────────────────────
Git | Cloud | IA | APIs | Linux

Vertical:

          |
          |
        z/OS
          |
        COBOL
          |
        CICS
          |
         Db2
          |
          |

Você possui profundidade numa área.

Mas consegue conversar com várias outras.

Isso é extremamente poderoso.

Especialmente num mundo em que mainframe deixou de ser uma ilha.

Hoje podemos ter:

MOBILE
  ↓
API
  ↓
z/OS CONNECT
  ↓
CICS
  ↓
COBOL
  ↓
DB2

Onde termina “moderno”?

Onde começa “legado”?

Resposta:

ninguém mais sabe.

E talvez essa divisão nem seja tão útil.

---

🔌 Go-Go-Gadget API!

Imagine Bugiganga tentando modernizar um sistema COBOL.

Ele aponta o braço:

Go-Go-Gadget Microservices!

Penny interrompe:

— Não.

Go-Go-Gadget Kubernetes!

— Também não.

Go-Go-Gadget Rewrite Everything!

Penny desliga o braço.

Porque modernização não significa obrigatoriamente substituir.

Às vezes significa:

INTEGRAR

Às vezes:

EXPOR

Às vezes:

AUTOMATIZAR

Às vezes:

TESTAR MELHOR

Às vezes simplesmente:

ENTENDER O QUE JÁ EXISTE.

---

🧠 A DIO como laboratório de curiosidade

Talvez essa seja uma das partes mais interessantes desse tipo de plataforma.

Você entra por uma tecnologia.

E encontra outras.

O programador Java descobre cloud.

O profissional cloud descobre segurança.

O estudante Python descobre IA.

O COBOLzeiro descobre Git.

O desenvolvedor web descobre banco de dados.

E começam conexões inesperadas.

CONHECIMENTO A
       +
CONHECIMENTO B
       =
IDEIA QUE NÃO EXISTIA ANTES

Isso é inovação muito mais frequentemente do que alguma apresentação corporativa com a palavra:

INNOVATION

escrita em fonte 72.

---

🤖 Então chegou a IA

Agora o Inspetor Bugiganga recebeu seu upgrade mais perigoso.

Go-Go-Gadget GPT!

De repente ele consegue:

• explicar código;

• gerar exemplos;

• revisar funções;

• sugerir testes;

• criar documentação;

• explicar mensagens de erro;

• comparar tecnologias;

• ajudar a estruturar projetos.

Fantástico.

Mas Dr. Claw imediatamente percebe a vulnerabilidade.

Se o aluno simplesmente pedir:

“Faça o desafio para mim.”

A IA faz.

O aluno entrega.

Recebe o resultado.

XP aumenta.

Conhecimento:

NULL

Parabéns.

Conseguimos hackear a gamificação.

E derrotar justamente aquilo que estávamos tentando aprender.

---

🧠 IA como Penny, não como piloto automático

A melhor utilização educacional de IA talvez seja tratá-la como Penny.

Pergunte:

“Explique por que isto está errado.”

Melhor que:

“Resolva.”

Pergunte:

“Dê uma pista.”

Pergunte:

“Mostre outro exemplo.”

Pergunte:

“Compare minha solução com outra abordagem.”

Pergunte:

“Crie cinco testes que possam quebrar meu código.”

Agora a IA não substitui o exercício.

Ela aumenta o exercício.

Essa diferença será cada vez mais importante.

---

📂 GitHub: onde o corpo fica enterrado

O certificado diz:

CONCLUÍ O BOOTCAMP

O GitHub pode mostrar:

O QUE EU FIZ

Existe uma diferença poderosa.

Projetos permitem construir evidência.

README.

Commits.

Código.

Testes.

Documentação.

Evolução.

Você começa com:

projeto-final

Depois:

projeto-final-v2

Depois:

agora-vai

Depois:

agora-vai-final

Depois:

agora-vai-final-definitivo

Depois:

agora-vai-final-definitivo-2

Todo desenvolvedor já passou por essa fase antes de compreender Git.

Não negue.

---

🏆 Ranking é divertido — mas existe um chefe secreto

XP é divertido.

Ranking é divertido.

Badges são divertidos.

Certificados são divertidos.

Mas existe um boss escondido no final:

AUTONOMIA.

O momento em que você abre uma tela vazia e consegue começar.

Sem instrutor.

Sem copiar repositório.

Sem vídeo mostrando exatamente o próximo passo.

Você pensa:

PRECISO FAZER X.

Então divide:

X
├── A
├── B
├── C
└── D

Pesquisa aquilo que não conhece.

Experimenta.

Erra.

Corrige.

Entrega.

Quando chega nesse ponto, algo mudou.

Você deixou de apenas estudar tecnologia.

Começou a trabalhar com tecnologia.

---

🕵️ Chefe Quimby entrega a missão final

Mensagem:

MISSÃO FINAL

ESCOLHA UMA TECNOLOGIA.

APRENDA O FUNDAMENTO.

CONCLUA O CURSO.

FAÇA O DESAFIO.

TERMINE O PROJETO.

DEPOIS FECHE O CURSO.

ABRA UMA TELA VAZIA.

E FAÇA OUTRA COISA
SEM O INSTRUTOR.

Bugiganga lê.

Penny sorri.

Brain coloca o capacete.

A mensagem explode novamente na cara do Chefe Quimby.

Naturalmente.

---

☕ O verdadeiro XP

Existe uma tentação moderna de transformar educação em números.

HORAS
CERTIFICADOS
BADGES
XP
RANKING
CURSOS

Todos podem ser úteis.

Todos podem motivar.

Todos podem mostrar progresso.

Mas existe uma métrica invisível muito mais interessante:

quantas coisas você consegue fazer hoje que não conseguia fazer seis meses atrás?

Essa é difícil de colocar num dashboard.

Mas é provavelmente a mais importante.

---

🦖 O mainframe encontra a DIO

Talvez alguém olhe para um veterano de mainframe estudando Node.js, Python, cloud, IA ou segurança e pergunte:

“Você vai abandonar COBOL?”

Não necessariamente.

Talvez esteja fazendo exatamente o contrário.

Está aumentando o raio de ação.

Ontem:

COBOL

Hoje:

COBOL
+
GIT
+
APIs
+
CLOUD
+
PYTHON
+
IA

A experiência antiga não desapareceu.

Ela ganhou novas interfaces.

O dinossauro não morreu.

Instalaram foguetes nele.

---

🚀 Go-Go-Gadget Developer!

E talvez essa seja a melhor imagem para representar a jornada.

Inspetor Bugiganga começa cheio de ferramentas.

Algumas ele domina.

Outras não.

Algumas funcionam.

Outras explodem.

Algumas resolvem problemas.

Outras criam problemas maravilhosamente maiores.

Mas ele continua avançando.

Quem trabalha com tecnologia conhece perfeitamente essa sensação.

Porque ninguém sabe tudo.

O desenvolvedor experiente não é aquele que possui todas as respostas.

É aquele que aprendeu a fazer uma coisa muito mais importante:

descobrir a próxima resposta.

---

☕ Epílogo — Um Café no Bellacosa Mainframe

02:13 da manhã.

O bootcamp marca:

99%

Existe apenas um desafio restante.

Inspetor Bugiganga olha para a tela.

Penny já sabe a solução.

Brain está dormindo embaixo da mesa.

Dr. Claw observa através de seu monitor.

“Desista, Gadget.”

Bugiganga abre o editor.

Executa.

Wrong Answer

Modifica.

Wrong Answer

Modifica novamente.

Runtime Error

Respira.

Toma café.

Lê o problema outra vez.

Encontra uma condição que havia ignorado.

Corrige.

Executa.

Accepted

A tela muda:

BOOTCAMP
████████████████████ 100%

CONCLUÍDO

Ele levanta os braços.

GO-GO-GADGET CERTIFICADO!

Penny olha para ele.

— Agora faça novamente sem olhar a solução.

Silêncio.

Bugiganga lentamente volta a sentar.

Fecha o projeto.

Cria uma pasta vazia.

novo-projeto/

O cursor começa a piscar.

E talvez seja exatamente ali...

não no certificado,

não no XP,

não no ranking,

mas diante daquela tela completamente vazia...

que começa o verdadeiro desenvolvedor.

☕🕵️‍♂️🔧🦖

GO-GO-GADGET LEARNING.

Porque em tecnologia o curso pode terminar.

O aprendizado nunca dá MAXCC=0000.

https://web.dio.me

https://web.dio.me/users/vagnerbellacosa

https://www.dio.me/sign-up?ref=AF7UPRJR3CU1

https://eljefemidnightlunch.blogspot.com/2026/06/reconhecimento-pelos-5-anos-no-dio.html

Ontem foi um dia muito feliz, fui surpreendido com uma carta, ao abri-la foi muita emoção, ser reconhecido pelos meus pares, dentre uma comunidade de 700 k, parceiros, mestres jedi, padawans e renegado. Sempre aprendendo e divertindo-se no percurso, muito obrigado família @digitalinnovation.one

 

De Python ao COBOL no IBM Z : Você Não Está Voltando no Tempo. Está Entrando no Computador que Nunca Parou de Evoluir.

 

Bellacosa Mainframe do python ao cobol no ibm z

# ☕ Um Café no Bellacosa Mainframe

De Python ao COBOL no IBM Z

Você Não Está Voltando no Tempo. Está Entrando no Computador que Nunca Parou de Evoluir.

"Quem programa em Python já pensa como um desenvolvedor. Aprender COBOL no IBM Z não significa reaprender programação. Significa aprender um novo ecossistema onde confiabilidade vale mais que velocidade, e onde milhões de transações passam todos os dias sem que ninguém perceba."

---

Introdução

Existe uma pergunta que recebo com frequência:

"Sou desenvolvedor Python. Vale a pena aprender COBOL e Mainframe?"

Minha resposta costuma surpreender.

Não apenas vale a pena. Você provavelmente aprenderá engenharia de software que dificilmente encontrará em qualquer outro ambiente.

O mercado costuma vender uma falsa dicotomia:

• Python é moderno.

• COBOL é antigo.

A realidade é muito diferente.

Python possui pouco mais de trinta anos.

O ecossistema IBM Z evolui continuamente há mais de sessenta anos.

Não estamos falando de software ultrapassado.

Estamos falando da plataforma responsável por executar boa parte das operações financeiras, seguradoras, governos, companhias aéreas, cartões de crédito e sistemas críticos do planeta.

O interessante é que um programador Python já possui diversas habilidades que tornam essa transição muito mais natural do que imagina.

Vamos descobrir por quê.

---

Bellacosa Mainframe python versus cobol no zos

Antes de aprender COBOL, esqueça um mito

Você não está trocando Python por COBOL.

Você está adicionando uma nova ferramenta.

Da mesma forma que um carpinteiro possui martelo, serra, plaina e furadeira, um engenheiro de software também possui diversas linguagens.

Python continuará excelente para:

• automação

• IA

• APIs

• Data Science

• DevOps

• scripts

COBOL continuará excelente para:

• regras de negócio

• processamento financeiro

• batch

• alta disponibilidade

• transações críticas

• processamento massivo

Não existe vencedor.

Existe contexto.

---

O que um programador Python já sabe

Muito mais do que imagina.

Quando alguém aprende programação de verdade, aprende conceitos.

Linguagens são apenas dialetos.

Você já conhece:

• variáveis

• constantes

• operadores

• funções

• módulos

• lógica

• estruturas condicionais

• repetições

• tratamento de erros

• arquivos

• entrada e saída

• testes

• depuração

Tudo isso continuará existindo.

A diferença é a forma como aparece.

---

O primeiro choque

Em Python você escreve:

if saldo > 0:
    print("Aprovado")

Em COBOL:

IF SALDO > ZERO
    DISPLAY "APROVADO"
END-IF.

A lógica?

Exatamente igual.

O estilo?

Completamente diferente.

COBOL prefere ser explícito.

Python prefere ser minimalista.

---

Python é uma linguagem

COBOL no Mainframe é um ecossistema

Essa talvez seja a maior diferença.

Um desenvolvedor Python normalmente trabalha assim:

Editor
↓

Python

↓

Bibliotecas

↓

Sistema Operacional

No IBM Z:

TSO

↓

ISPF

↓

JCL

↓

COBOL

↓

DB2

↓

CICS

↓

IMS

↓

z/OS

Você não aprende apenas uma linguagem.

Você aprende uma plataforma inteira.

É parecido com aprender desenvolvimento Web.

Você não aprende apenas HTML.

Aprende HTML, CSS, JavaScript, servidor, banco, protocolos...

No Mainframe acontece exatamente isso.

---

O segundo choque

Em Python normalmente você executa:

python programa.py

No Mainframe:

• editar

• salvar

• compilar

• linkar

• executar

• consultar spool

• verificar retorno

• analisar mensagens

Parece mais trabalhoso.

Na verdade, é muito mais controlado.

Cada etapa possui um propósito.

---

O que parece estranho inicialmente

Python:

arquivo = open(...)

COBOL:

SELECT CLIENTES
ASSIGN TO DDCLIENTE.

"Cadê o nome do arquivo?"

Está no JCL.

O programa não conhece o arquivo físico.

Essa separação é uma das grandes ideias do Mainframe.

Trocar arquivos sem alterar código.

---

Orientação a Objetos?

Sim.

COBOL suporta OO há muitos anos.

Mas no mercado você encontrará principalmente programas procedurais.

Não porque COBOL não suporte.

Mas porque grande parte dos sistemas foi construída muito antes da popularização da orientação a objetos.

---

Tipagem

Python:

x = 10

COBOL:

01 X PIC 9(02).

Parece estranho.

Depois você percebe que o compilador sabe exatamente quanto espaço cada dado ocupará.

Isso faz enorme diferença quando bilhões de registros são processados.

---

Precisão numérica

Python possui excelentes bibliotecas.

Mas o COBOL nasceu para números financeiros.

Imagine calcular juros compostos durante quarenta anos.

Imagine fazer isso para centenas de milhões de contas.

É exatamente esse tipo de problema que COBOL resolveu durante décadas.

---

O maior aprendizado

Python ensina produtividade.

Mainframe ensina disciplina.

No IBM Z você aprende:

• planejamento

• padronização

• auditoria

• versionamento

• governança

• rastreabilidade

• segurança

• confiabilidade

Esses conceitos acompanham você para qualquer linguagem.

---

A maior mudança mental

No mundo Python pensamos:

Como resolver este problema?

No Mainframe pensamos:

Como resolver este problema sem colocar o banco em risco?

A preocupação muda completamente.

---

O que estudar primeiro

Muita gente começa pelo COBOL.

Eu faria diferente.

---

Etapa 1 — Entender o Mainframe

Antes de escrever uma linha de código, entenda:

• IBM Z

• LPAR

• z/OS

• usuários

• datasets

• spool

• JES2

• catálogo

• compilação

Sem isso o COBOL parecerá confuso.

---

Etapa 2 — Aprender TSO

Você precisa aprender:

• logon

• logoff

• HELP

• PROFILE

• ALLOCATE

• LISTCAT

Poucos comandos.

Grande impacto.

---

Etapa 3 — ISPF

Domine:

• Editor

• Browse

• Utilities

• Member List

• Search

• Compare

Passe algumas horas apenas navegando.

---

Etapa 4 — Datasets

Este é o primeiro grande divisor de águas.

Aprenda:

• PS

• PDS

• PDSE

• VSAM

Depois:

• organização

• bloqueio

• atributos

• RECFM

• LRECL

• BLKSIZE

Sem isso o restante ficará nebuloso.

---

Etapa 5 — JCL

Muitos evitam JCL.

Erro enorme.

JCL é o "Python launcher" do Mainframe.

Aprenda:

• JOB

• EXEC

• DD

• PROC

• COND

• IF

• INCLUDE

Sem JCL não existe compilação.

---

Etapa 6 — COBOL Básico

Agora sim.

Comece com:

• IDENTIFICATION

• ENVIRONMENT

• DATA DIVISION

• PROCEDURE DIVISION

Depois:

• MOVE

• ADD

• SUBTRACT

• COMPUTE

• IF

• EVALUATE

• PERFORM

Nada além disso.

---

Etapa 7 — Arquivos

Aprenda:

• Sequential

• Indexed

• Relative

Depois:

• OPEN

• CLOSE

• READ

• WRITE

• REWRITE

• DELETE

• START

Treine muito.

---

Etapa 8 — VSAM

Agora tudo faz sentido.

Aprenda:

• KSDS

• ESDS

• RRDS

Depois:

• chave

• acesso direto

• acesso sequencial

---

Etapa 9 — DB2

Aqui o desenvolvedor Python sente-se novamente em casa.

SQL continua SQL.

Você estudará:

• SELECT

• INSERT

• UPDATE

• DELETE

• CURSOR

• COMMIT

• ROLLBACK

A lógica é praticamente a mesma.

---

Etapa 10 — CICS

Finalmente chega ao ambiente online.

Aprenda:

• transações

• mapas

• COMMAREA

• Channels

• Containers

• EXEC CICS

Agora você entenderá como bancos processam operações em tempo real.

---

O que praticar diariamente

Não basta ler.

É preciso escrever código.

Sugiro pequenos desafios.

Semana 1

• DISPLAY

• ACCEPT

• variáveis

---

Semana 2

• IF

• EVALUATE

• PERFORM

---

Semana 3

• tabelas

• OCCURS

• índices

---

Semana 4

• arquivos sequenciais

---

Semana 5

• VSAM

---

Semana 6

• SQL

---

Semana 7

• JCL

---

Semana 8

• programas completos

---

O que um programador Python aprende com COBOL

Mais do que imagina.

Aprende:

• processamento em lote

• processamento transacional

• controle de recursos

• otimização de I/O

• estruturas de dados fixas

• planejamento de memória

• arquitetura corporativa

• auditoria

• governança

• compatibilidade

Essas habilidades aumentam a maturidade técnica independentemente da linguagem utilizada.

---

O que um programador COBOL pode aprender com Python

A troca também funciona.

Python ensina:

• automação

• APIs REST

• IA

• testes automatizados

• integração

• DevOps

• scripts

• análise de dados

Hoje o profissional mais valorizado costuma conhecer os dois mundos.

---

A combinação poderosa

Imagine este cenário.

Python:

• chama uma API.

API:

• conversa com z/OS Connect.

z/OS Connect:

• chama um programa COBOL.

COBOL:

• consulta DB2.

Resultado:

• retorna JSON.

Para o usuário parece uma aplicação moderna.

Nos bastidores, quarenta anos de regras de negócio continuam funcionando com segurança e desempenho.

É exatamente assim que muitas organizações modernizam seus sistemas sem reescrever décadas de conhecimento.

---

Erros comuns de quem vem do Python

1. Tentar escrever COBOL como Python.

Cada linguagem possui sua filosofia.

2. Ignorar JCL.

Sem ele você não entende o ciclo de desenvolvimento.

3. Pular datasets.

Arquivos são parte fundamental do ecossistema.

4. Estudar apenas sintaxe.

O diferencial está na arquitetura do IBM Z.

5. Ter pressa.

Mainframe recompensa consistência, não velocidade.

---

Uma trilha de estudos de 24 semanas

Semanas	Tema
1–2	Arquitetura IBM Z e z/OS
3–4	TSO e ISPF
5–6	Datasets e catálogo
7–9	JCL
10–14	COBOL Fundamental
15–16	Arquivos Sequenciais e VSAM
17–19	DB2 e SQL Embutido
20–21	CICS
22	Debug e análise de ABENDs
23	Integração com APIs, JSON e XML
24	Projeto final integrando Batch, DB2 e CICS

Ao final desse percurso, o desenvolvedor já terá uma visão sólida do ambiente corporativo IBM Z e poderá evoluir para temas como RACF, IMS, MQ, z/OS Connect, REXX, DevOps para Mainframe e automação.

---

O verdadeiro objetivo

Aprender Mainframe não é decorar comandos do ISPF.

Não é memorizar JCL.

Não é conhecer todas as cláusulas do COBOL.

O verdadeiro objetivo é desenvolver uma nova forma de pensar sistemas críticos.

Você passa a enxergar software sob a ótica da disponibilidade, da previsibilidade, da integridade dos dados e da continuidade do negócio. São princípios que sustentam bancos, seguradoras, bolsas de valores, companhias aéreas e órgãos governamentais há décadas.

Quando você domina esses conceitos, volta ao mundo Python mais preparado para construir sistemas robustos, escaláveis e resilientes.

---

Conclusão

Se você já programa em Python, a parte mais difícil ficou para trás: aprender a pensar como desenvolvedor.

A jornada para o COBOL no IBM Z não exige abandonar esse conhecimento. Exige expandi-lo.

Você descobrirá que if, for, funções, arquivos, SQL e algoritmos continuam presentes. O que muda é o ambiente, a disciplina operacional e a responsabilidade de trabalhar em sistemas que não podem falhar.

No Bellacosa Mainframe costumo dizer que o Mainframe não é um museu da computação; é uma universidade permanente de engenharia de software. Quem entra nesse ecossistema aprende muito mais do que uma linguagem: aprende arquitetura, confiabilidade, governança e a importância de construir software que continue funcionando por décadas.

Python e COBOL não competem. Eles se complementam. O profissional que transita entre esses dois universos torna-se capaz de conectar inovação e legado, nuvem e missão crítica, APIs modernas e regras de negócio consolidadas.

E talvez essa seja a maior lição da jornada:

Você não está deixando o Python para aprender COBOL. Está ampliando sua caixa de ferramentas com uma das plataformas mais sólidas e respeitadas da história da computação.

Bem-vindo ao IBM Z. O café está passado. Agora é hora de escrever seu primeiro programa. ☕

Ferramentas para Implementar CI/CD no Mainframe

 

Bellacosa Mainframe apresenta ferramentas ci/cd para mainframers

☕ Um Café no Bellacosa Mainframe

Ferramentas para Implementar CI/CD no Mainframe

Do Git ao IBM Z: Construindo uma Esteira Moderna para Aplicações COBOL

"O maior erro de um programador COBOL é imaginar que CI/CD significa apenas instalar Jenkins. O verdadeiro pipeline começa muito antes da primeira ferramenta e termina muito depois do deploy."

Durante muitos anos existiu um mito dentro das equipes de desenvolvimento IBM Z.

O mito dizia que DevOps era coisa de aplicações Java.

Que Docker era para Linux.

Que Git era para desenvolvedores Web.

Que CI/CD não fazia sentido para COBOL.

Enquanto isso, silenciosamente, bancos, seguradoras, bolsas de valores, empresas aéreas e grandes instituições financeiras começaram a automatizar praticamente todo o ciclo de desenvolvimento de aplicações Mainframe.

Hoje, um programa COBOL raramente percorre o caminho entre desenvolvimento e produção apenas pelas mãos de um operador. Em vez disso, ele passa por uma esteira automatizada composta por dezenas de ferramentas responsáveis por versionamento, compilação, análise de qualidade, testes, empacotamento, implantação, monitoramento e auditoria.

Se antigamente o programador entregava apenas um fonte COBOL, hoje ele entrega um conjunto de artefatos que precisam passar por um pipeline inteligente.

Neste café vamos conhecer as principais ferramentas que compõem esse ecossistema moderno.

---

O quebra-cabeça do CI/CD

Antes de falar de ferramentas, precisamos entender uma verdade importante.

Não existe uma ferramenta chamada CI/CD.

CI/CD é um conjunto de práticas.

Cada ferramenta resolve apenas uma parte do problema.

Imagine uma linha de montagem de automóveis.

Uma máquina solda.

Outra pinta.

Outra instala o motor.

Outra testa os freios.

Nenhuma delas constrói o carro sozinha.

No mundo DevOps acontece exatamente a mesma coisa.

---

O pipeline moderno

Um pipeline corporativo normalmente possui etapas como:

Git

↓

Merge

↓

Build

↓

Compile

↓

Static Analysis

↓

Unit Test

↓

Integration Test

↓

Artifact

↓

Deploy DEV

↓

Deploy QA

↓

Approval

↓

Deploy Production

↓

Monitoring

Cada etapa pode utilizar uma ferramenta diferente.

---

Git — O novo PDS do Coboleiro

A primeira ferramenta que todo desenvolvedor precisa conhecer é o Git.

Não importa se você trabalha com COBOL, PL/I, Assembler ou Java.

Sem controle de versões não existe CI/CD.

Git permite:

• histórico completo;

• rollback;

• branches;

• merge;

• auditoria;

• colaboração entre equipes.

Para quem vem do mundo IBM Z, uma boa analogia é pensar que o Git é um grande PDS inteligente que registra todas as alterações feitas em cada membro, preservando versões e identificando exatamente quem modificou cada linha de código.

---

GitHub, GitLab e Bitbucket

O Git controla versões localmente.

Já GitHub, GitLab e Bitbucket hospedam os repositórios e adicionam funcionalidades colaborativas.

Essas plataformas oferecem:

• Pull Requests;

• Code Review;

• gestão de branches;

• integração com pipelines;

• controle de permissões;

• rastreabilidade.

No dia a dia, um programador COBOL pode alterar um programa, abrir um Pull Request e aguardar a aprovação do líder técnico antes que o código seja integrado à branch principal.

---

Jenkins — O Maestro da Orquestra

Se o Git armazena o código, quem coordena a esteira?

Uma das respostas mais comuns é o Jenkins.

O Jenkins é um servidor de automação.

Sua função é executar tarefas automaticamente sempre que algum evento ocorre.

Por exemplo:

git push

↓

Executar Build

↓

Compilar

↓

Executar testes

↓

Publicar relatório

↓

Enviar e-mail

↓

Implantar

Para um coboleiro, o Jenkins lembra bastante um agendador de JOBs.

A diferença é que, em vez de executar apenas batchs, ele orquestra toda a cadeia de desenvolvimento.

---

GitHub Actions

Nos últimos anos, GitHub Actions tornou-se uma excelente alternativa ao Jenkins.

O pipeline fica descrito em arquivos YAML dentro do próprio repositório.

Exemplo simplificado:

Push

↓

Checkout

↓

Build

↓

Test

↓

Deploy

Toda alteração no código pode disparar automaticamente essa sequência.

---

GitLab CI

Quem utiliza GitLab encontra uma solução semelhante.

O arquivo .gitlab-ci.yml define as etapas do pipeline.

Cada etapa executa scripts específicos.

É uma excelente opção para organizações que desejam manter todo o ciclo DevOps em uma única plataforma.

---

Docker — O Ambiente que Viaja Junto

Talvez esta seja a ferramenta mais mal compreendida pelos desenvolvedores Mainframe.

Docker normalmente não executa aplicações z/OS.

Ele executa aplicações Linux.

Mas isso não significa que ele esteja distante do IBM Z.

Muito pelo contrário.

Imagine uma aplicação composta por:

• Front-end React;

• API Java;

• Redis;

• Kafka;

• PostgreSQL;

• COBOL no Mainframe.

Durante os testes, Docker pode subir automaticamente todos os componentes distribuídos, permitindo que apenas o Mainframe permaneça como ambiente externo.

Assim, o pipeline consegue validar toda a aplicação antes da entrega.

---

Easter Egg Bellacosa

Uma Docker Image lembra muito uma PROC catalogada.

Alguém preparou um ambiente padronizado.

Os demais apenas reutilizam.

Da mesma forma que uma PROC encapsula passos JCL reutilizáveis, uma imagem Docker encapsula bibliotecas, ferramentas e configurações.

---

IBM Dependency Based Build (DBB)

Agora entramos nas ferramentas específicas do mundo IBM Z.

O IBM Dependency Based Build foi criado para automatizar builds de aplicações Mainframe.

Seu grande diferencial é entender dependências entre:

• programas COBOL;

• COPYBOOKs;

• JCLs;

• BMS;

• PL/I;

• Assembler.

Imagine alterar um COPYBOOK.

Em vez de recompilar milhares de programas, o DBB identifica exatamente quais módulos dependem daquele componente.

Isso reduz drasticamente o tempo de build.

---

IBM Developer for z/OS (IDz)

Durante muitos anos o ISPF foi praticamente o único ambiente de desenvolvimento utilizado por programadores COBOL.

Hoje o IBM Developer for z/OS oferece recursos modernos:

• edição inteligente;

• autocomplete;

• refatoração;

• integração com Git;

• depuração;

• integração com pipelines.

Ele aproxima a experiência do desenvolvedor Mainframe daquela encontrada em IDEs modernas.

---

Zowe CLI

Poucas ferramentas revolucionaram tanto a integração entre Mainframe e DevOps quanto o Zowe.

O Zowe CLI permite executar comandos z/OS diretamente da linha de comando.

É possível:

• enviar arquivos;

• submeter JOBs;

• consultar JES;

• baixar datasets;

• acessar USS;

• manipular perfis.

Isso transforma o Mainframe em um participante natural dos pipelines modernos.

Um Jenkins pode executar comandos Zowe da mesma forma que executa comandos Linux.

---

z/OSMF

O z/OS Management Facility disponibiliza serviços REST para administração do ambiente.

Essas APIs permitem:

• submeter JOBs;

• consultar status;

• manipular datasets;

• automatizar operações.

Isso reduz a necessidade de scripts específicos e facilita a integração com ferramentas DevOps.

---

IBM UrbanCode Deploy

Quando falamos em implantação controlada, uma ferramenta bastante conhecida é o UrbanCode Deploy.

Ela oferece:

• versionamento de pacotes;

• promoção entre ambientes;

• rollback;

• aprovações;

• auditoria;

• histórico de deploys.

Em bancos, normalmente um pacote percorre DEV → QA → UAT → Produção obedecendo regras rígidas de governança.

---

SonarQube

Compilar não significa produzir código de qualidade.

É aí que entra o SonarQube.

Ele realiza análise estática identificando:

• duplicação de código;

• complexidade excessiva;

• vulnerabilidades;

• más práticas;

• código morto.

No universo COBOL, também ajuda a localizar programas com manutenção difícil, excesso de GO TO ou baixa legibilidade.

---

Testes Automatizados

CI/CD sem testes automatizados é apenas automação de compilação.

Ferramentas como ZUnit permitem validar programas COBOL automaticamente.

Cada alteração dispara dezenas ou centenas de testes sem intervenção humana.

Isso reduz regressões e aumenta a confiança nas entregas.

---

Nexus e Artifactory

Após o build surge outra pergunta.

Onde armazenar os artefatos?

Ferramentas como Nexus Repository e JFrog Artifactory centralizam:

• pacotes;

• bibliotecas;

• versões;

• dependências.

Mesmo quando o artefato final é um LOAD Module, o pipeline pode armazenar documentação, scripts, relatórios e componentes auxiliares.

---

Ansible

Cada vez mais utilizado em ambientes híbridos.

Permite automatizar:

• configuração;

• implantação;

• execução de comandos;

• integração entre servidores Linux e Mainframe.

Com coleções específicas para IBM Z, torna-se possível executar tarefas administrativas repetitivas de forma padronizada.

---

OpenShift

Embora aplicações COBOL normalmente permaneçam no z/OS, muitos componentes modernos são executados em OpenShift.

APIs.

Microsserviços.

Monitoramento.

Dashboards.

Ferramentas de apoio ao pipeline.

Tudo isso pode coexistir com o Mainframe.

---

Monitoramento

Depois do deploy o trabalho não termina.

Ferramentas como:

• Grafana;

• Prometheus;

• Elastic;

• Splunk;

• Dynatrace;

• Instana.

permitem acompanhar métricas, logs e desempenho.

No IBM Z elas complementam informações provenientes de RMF, SMF e outras soluções tradicionais.

---

Segurança

Pipelines modernos também verificam:

• credenciais;

• certificados;

• assinaturas;

• vulnerabilidades;

• conformidade.

O objetivo é impedir que software inseguro alcance produção.

---

Como tudo conversa?

Imagine o seguinte fluxo.

Git

↓

GitHub

↓

GitHub Actions

↓

Docker

↓

DBB

↓

Compile COBOL

↓

ZUnit

↓

SonarQube

↓

Artifact

↓

UrbanCode

↓

Produção IBM Z

Cada ferramenta executa apenas sua especialidade.

Juntas, constroem uma esteira extremamente confiável.

---

O erro mais comum

Muitas empresas acreditam que basta instalar Jenkins.

Não basta.

Sem:

• versionamento;

• testes;

• padronização;

• documentação;

• governança;

o pipeline apenas automatiza problemas antigos.

Existe uma frase famosa no mundo DevOps:

"Automatizar um processo ruim apenas faz com que ele falhe mais rápido."

---

Como escolher as ferramentas?

Não existe resposta única.

Uma empresa pequena pode começar apenas com:

• Git;

• GitHub;

• GitHub Actions;

• Zowe.

Uma organização maior pode utilizar:

• GitLab;

• Jenkins;

• DBB;

• SonarQube;

• UrbanCode;

• ZUnit;

• Artifactory;

• OpenShift;

• Ansible.

Tudo depende da maturidade do ambiente.

---

A jornada do Coboleiro Moderno

O desenvolvedor COBOL do futuro continuará escrevendo PROCEDURE DIVISION.

Continuará criando JCL.

Continuará utilizando Db2.

Continuará desenvolvendo CICS.

Mas também precisará compreender conceitos como:

• Git;

• Pull Request;

• Merge;

• Pipeline;

• Docker;

• YAML;

• Testes Automatizados;

• Quality Gates;

• DevSecOps;

• Observabilidade.

Isso não significa abandonar o Mainframe.

Significa ampliar suas competências.

---

Conclusão

Durante décadas, o IBM Z foi visto como uma ilha tecnológica, separado do restante da engenharia de software. Hoje essa visão já não corresponde à realidade. As ferramentas modernas de CI/CD demonstram que é possível integrar aplicações COBOL aos mesmos processos de automação, qualidade e governança utilizados no desenvolvimento distribuído, preservando toda a confiabilidade que tornou o Mainframe indispensável para os negócios.

O segredo não está em substituir tecnologias tradicionais, mas em conectá-las de forma inteligente. Git não elimina o conhecimento sobre bibliotecas PDS; Docker não substitui o z/OS; Jenkins não toma o lugar do JES2; Zowe não elimina o ISPF. Cada ferramenta complementa o ambiente e amplia a capacidade de entrega das equipes.

Para o COBOL Jr, dominar esse ecossistema representa uma enorme vantagem competitiva. Ele deixa de ser apenas um programador que compila programas e passa a compreender toda a jornada do software, desde o primeiro commit até o monitoramento da aplicação em produção. Essa visão sistêmica é cada vez mais valorizada em bancos, seguradoras e empresas que executam milhares de transações por segundo no IBM Z.

No universo Bellacosa Mainframe, a mensagem é simples: o COBOL continua sendo o motor dos negócios, mas o CI/CD é a esteira invisível que mantém esse motor evoluindo com velocidade, qualidade e segurança. O profissional que aprender a combinar a robustez do Mainframe com as práticas modernas de DevOps estará preparado para construir a próxima geração de aplicações críticas, onde tradição e inovação caminham lado a lado.

 

🔥 Instana explicado “comando por comando” para mentalidade z/OS

Conhecimento básico sobre aplicações distribuídas para quem já dominou console, SMF e RMF

---

☕ 02:06 — Quando o dashboard vira console (e ninguém avisou)

O mainframer abre o Instana pela primeira vez e pensa:

“Bonito… mas onde fica o comando?”

Spoiler: o comando ainda existe — só mudou de forma.
Instana não substitui o pensamento z/OS. Ele o redistribui.

Este artigo é uma tradução operacional, comando por comando, conceito por conceito, para tornar Instana inteligível para quem pensa em transação, capacidade e causa raiz.

---

1️⃣ Antes de tudo: Instana não é ferramenta, é sistema de controle 🧠

No z/OS:

• Você confia no sistema

• Depois confia na aplicação

No cloud:

• Você desconfia de tudo

• E a observabilidade vira o “novo operador”

📌 Comentário Bellacosa:
Instana é o operador automático que nunca dorme — mas só funciona se você souber o que perguntar.

---

2️⃣ “Start Instana” = IPL invisível 🚀

Mentalidade z/OS:
Nada funciona sem IPL correto.

Instana:

• Instala o Agent

• Ele se auto-registra

• Descobre tudo sozinho

🔥 Tradução:
O Agent é um mini-IPL distribuído, detectando o que está ativo sem JCL.

😈 Easter egg:
Mainframer estranha isso porque… sempre foi assim no z/OS.

---

3️⃣ SMF → Traces (o “PRINT TRANSACTION” moderno) 🔍

No mainframe

• SMF Type 110 (CICS)

• Início, fim, consumo

No Instana

• Trace distribuído

• Cada request costurado de ponta a ponta

📌 Comando mental:

“Show me the full transaction path”

🔥 Comentário:
Trace é SMF em tempo real, sem batch noturno.

---

4️⃣ RMF → Métricas (DISPLAY SYSTEM reinventado) 📊

RMF mostrava

• CPU

• Memory

• I/O

• Gargalos

Instana mostra

• CPU

• Memory

• Latência

• Saturação

😈 Curiosidade:
Cloud “descobriu” que capacidade importa… 40 anos depois.

📌 Comando mental:

“Where is the bottleneck right now?”

---

5️⃣ JES / Spool → Logs correlacionados 📜

No z/OS

• JES explica a execução

• Spool conta a história

No Instana

• Logs vêm amarrados ao trace

• Não são texto solto

🔥 Tradução Bellacosa:
Log sem trace é spool sem JOBNAME.

---

6️⃣ CICS TRANSACTION → SERVICE / ENDPOINT 🧩

CICS

• Transação bem definida

• Entrada, processamento, saída

Instana

• Service = unidade lógica

• Endpoint = função específica

📌 Comando mental:

“Qual transação está lenta?”

😈 Easter egg:
Quem entende CICS entende microservice — só muda o vocabulário.

---

7️⃣ Abend → Incident (o SOC7 moderno) 💥

No mainframe

• Abend chama operador

• Alguém acorda

No Instana

• Incident agrega sintomas

• Root cause aparece primeiro

🔥 Comentário ácido:
No cloud, o erro grita menos — mas custa mais.

---

8️⃣ Return Code → Error Rate / Status 📉

Antes

• RC 0 = paz

• RC ≠ 0 = guerra

Agora

• Error rate

• Latência fora do normal

• SLO violado

📌 Tradução:
Sucesso virou estatística, não certeza.

---

9️⃣ Job Chain → Dependency Graph 🕸️

Batch

• Ordem rígida

• Dependência clara

Distribuído

• Grafo dinâmico

• Dependência oculta

🔥 Comentário Bellacosa:
Dependency Graph é o JOB CONTROL que ninguém documentou.

---

🔟 Console z/OS → Dashboard Instana 👀

• Console ignorado = desastre

• Dashboard ignorado = post-mortem

😈 Easter egg real:
Todo mundo só olha quando fica vermelho.

📌 Comando mental:

“Is this normal behavior or degradation?”

---

🧭 Passo a passo: como um mainframer deve usar Instana

1️⃣ Comece pela transação
2️⃣ Siga o trace
3️⃣ Observe latência, não só erro
4️⃣ Correlacione métricas
5️⃣ Identifique dependência
6️⃣ Ache a causa raiz
7️⃣ Só então mexa no código

🔥 Regra de ouro:
Nunca “otimize” antes de entender.

---

📚 Guia de estudo para mainframers curiosos

Conceitos

• Observabilidade (metrics, logs, traces)

• Resiliência

• Falha parcial

• SRE

• Arquitetura distribuída

Exercício prático

👉 Pegue um incidente no Instana
👉 Leia como se fosse um dump
👉 Pergunte: qual foi o primeiro sintoma real?

---

🎯 Aplicações reais no mundo híbrido

• Core bancário + APIs

• Integração mainframe-cloud

• Diagnóstico de incidentes críticos

• Governança técnica

• Times SRE corporativos

---

🖤 Epílogo — 03:18, tudo verde (por enquanto)

Instana não substitui o mainframer.
Ela precisa dele para fazer sentido.

El Jefe Midnight Lunch finaliza:
“Quando você olha um trace como se fosse SMF, o cloud para de parecer caótico.”

 

🏺 Diógenes e o século XXI: o cínico que habita o caos

 

Bellacosa Mainframe apresenta diogines o cinico

🏺 Diógenes e o século XXI: o cínico que habita o caos

1. A vida minimalista e a rejeição de aparências

Diógenes rejeitava convenções, riqueza, fama e normas sociais vazias.
Ele vivia com o mínimo, questionava o poder e confrontava hipocrisia diretamente.
Hoje, você percebe paralelos:

• Redes sociais forçam ostentação, performance e aprovação constante.

• Trabalho e consumo saturam a vida de estímulos desnecessários.

• Propagandas e algoritmos tentam manipular desejos.

O Cínico diria: “Desligue, minimize, questione — viva com o essencial.”
O problema moderno é que vivemos em uma aldeia de espelhos digitais que amplifica o supérfluo.

---

2. A crítica social radical

Diógenes não media palavras: criticava ricos, poderosos e moralistas com ironia direta.
Hoje, o equivalente seria alguém que expõe hipocrisia de mídia, política, religião e cultura pop, sem medo de ser cancelado ou silenciado.
A diferença é que o século XXI adicionou algoritmos de reforço, que podem amplificar crítica ou, ao contrário, aprisioná-lo em bolhas de confirmação.

---

3. Autossuficiência e liberdade interior

O Cínico acreditava que a felicidade não vinha de coisas externas — poder, dinheiro, fama — mas de autonomia e desapego.
Se refletirmos:

• Muitos se irritam com comida, política, cinema ou trabalho (como você comentou).

• Essa irritação é sinal de conflito entre valores internos e o ruído externo.

• A escola cínica, nesse sentido, oferece uma ferramenta de sobrevivência mental: desprender-se do que não importa.

---

4. A vida moderna como “simulação de excesso”

O século XXI é como uma versão digital daquilo que Diógenes rejeitava:

• Consumo desenfreado, aparências constantes, distrações infinitas.

• Redes sociais criam palco para vaidade, competição e comparação.

• Algoritmos alimentam polarização, medo e frustração.

Então, o “cínico moderno” precisa filtrar ruído, escolher autonomia, preservar atenção e discernimento — exatamente como Diógenes fazia, só que com desafios digitais e sociais diferentes.

---

5. Manipulação x realidade

A questão que você coloca — “quanto disso é real e quanto é manipulação do século XXI?” — é crucial.

• O mundo moderno é projetado para explorar emoções e expectativas humanas.

• Mas isso não invalida a percepção de injustiça, absurdo ou hipocrisia.

• Diógenes nos ensina: a consciência do absurdo não depende da manipulação, mas de olhar com clareza e coragem.

---

☕ Epílogo Bellacosa

Se Diógenes vivesse hoje, provavelmente:

• Moraria fora do consumo desenfreado, talvez numa “aldeia offline”.

• Ignoraria polarização digital, focando em liberdade interior.

• Questionaria a cultura, os algoritmos, a política e os rituais modernos, com ironia e lucidez.

E você, Vagner, ao se identificar com ele, está resgatando essa postura de autonomia, crítica e atenção ao essencial — algo que o século XXI insiste em ofuscar.

Parma: fui procurar Verdi e acabei num aniversário italiano

  

Bellacosa Mainframe memorias de Parma

☕ Um Café no Bellacosa Mainframe

🍷 PARMA — O DIA EM QUE FUI PROCURAR VERDI E ACABEI CANTANDO PARABÉNS PARA UM DESCONHECIDO

Ou: como uma pizza no café da manhã, alguns italianos lutando contra uma massa de macarrão, uma lombriga chamada Brigitte e uma jarra de vinho transformaram um almoço qualquer numa das minhas melhores lembranças da Europa

Há viagens que planejamos.

Compramos passagem, estudamos mapas, escolhemos museus, anotamos endereços, calculamos horários de trem e fazemos uma lista quase militar daquilo que precisamos conhecer.

E existem as outras.

As viagens que acontecem enquanto estamos ocupados executando o roteiro.

Minha história em Parma pertence à segunda categoria.

Eu fui até lá por causa de Giuseppe Verdi.

Voltei carregando a lembrança de um velhinho cujo nome provavelmente nem guardei.

E, décadas depois, ainda consigo descer aquelas escadas.

---

🎼 O MOTIVO ERA VERDI

Minha ida a Parma não começou pela gastronomia.

Não fui caçar restaurante famoso.

Não havia uma lista de estabelecimentos recomendados.

Não estava procurando estrelas Michelin.

Meu interesse era outro.

Eu queria conhecer um pouco mais do universo de Giuseppe Verdi.

E havia ainda uma conexão brasileira que tornava aquilo especialmente interessante para mim: Antônio Carlos Gomes, nosso grande compositor, viveu e trabalhou na Itália e pertenceu àquele extraordinário universo musical italiano do século XIX.

Portanto, naquele dia meu programa era essencialmente cultural.

Verdi.

Carlos Gomes.

Igrejas.

Ruelas.

Arquitetura.

História.

E andar.

Principalmente andar.

Eu sempre conheci cidades dessa maneira.

Coloco os pés na rua e começo a zanzar.

---

🍕 NOVE DA MANHÃ E O CAFÉ DA MANHÃ DOS CAMPEÕES

Cheguei de trem.

Era cedo, aproximadamente nove horas da manhã.

E eu já havia tomado aquilo que considero um café da manhã perfeitamente defensável:

pizza de trancio.

Nada de cereal integral.

Nada de iogurte cuidadosamente fotografado ao lado de três morangos.

Pizza.

Afinal, estávamos na Itália.

Alimentado e feliz, comecei a andar pelas ruas.

Foi então que passei diante de um restaurante.

Nada particularmente espetacular do lado de fora.

Não me lembro de estrelas.

Não parecia pertencer àquela categoria de estabelecimentos diante dos quais turistas fazem peregrinação.

Estava meio fora de mão.

E estava fechado.

Mas havia uma vitrine.

E atrás daquela vitrine acontecia uma guerra.

---

🍝 OS BRAVOS ITALIANOS LUTANDO CONTRA O MACARRÃO

Parei.

Lá dentro havia pessoas trabalhando com massa.

Não estavam montando pratos bonitos para Instagram.

O restaurante nem tinha aberto.

Era preparação.

Farinha.

Massa.

Bancada.

Braços trabalhando.

Italianos travando uma batalha corpo a corpo contra aquilo que algumas horas depois seria servido aos clientes.

Fiquei olhando.

Tirei fotografia.

Passei alguns minutos diante daquela vitrine simplesmente acompanhando o trabalho.

Talvez para eles fosse apenas mais uma manhã.

Para mim havia alguma coisa fascinante naquilo.

Era possível ver o back-end da cozinha funcionando antes da abertura do front-end.

O batch gastronômico estava em plena execução.

09:00

RESTAURANT = CLOSED
CUSTOMERS = 0
PASTA_BATCH = RUNNING
BRAZILIAN_OBSERVER = DETECTED

Guardei mentalmente o lugar.

E continuei andando.

---

⛪ VERDI, IGREJAS E QUILÔMETROS DEPOIS

Fui cumprir minha missão.

Visitei lugares ligados a Verdi.

Entrei em igrejas.

Observei prédios.

Atravessei ruas.

Fotografei.

Andei sem pressa.

Esse sempre foi um dos meus maiores prazeres viajando pela Europa: permitir que a cidade aparecesse entre um destino e outro.

Não apenas chegar.

Percorrer.

O problema é que existe um componente biológico que invariavelmente interfere nos grandes projetos culturais da humanidade.

A fome.

Por volta das treze horas, minha barriga começou a apresentar os primeiros alertas operacionais.

E então acordou uma velha companheira de viagem.

Brigitte.

Minha lombriga de estimação.

Brigitte é responsável por importantes decisões gastronômicas da minha vida.

Naquele momento ela assumiu o controle da navegação.

WARNING: FUEL LEVEL CRITICAL

BRIGITTE:
"Vagner..."

VAGNER:
"Que foi?"

BRIGITTE:
"Lembra daqueles italianos fazendo macarrão?"

VAGNER:
"..."

BRIGITTE:
"VOLTA."

Obedeci.

---

🪜 DESCENDO PARA OUTRA PARMA

Retornei ao restaurante.

Agora estava aberto.

Entrei.

E imediatamente veio aquele aroma.

Desci as escadas porque a sala onde se comia ficava no porão.

Lá embaixo encontrei exatamente o tipo de lugar que adoro descobrir viajando.

Poucas pessoas.

Nenhuma multidão.

Nenhum grupo turístico.

Nenhuma juventude fazendo fila para fotografar o prato da moda.

Havia principalmente gente de idade.

Rostos de quem parecia morar ali.

Pessoas que não haviam viajado milhares de quilômetros para conhecer Parma.

Elas eram Parma.

Conversei com o garçom.

Expliquei que era brasileiro.

Um andarilho.

E fiz talvez o melhor pedido possível naquele lugar:

— Me surpreenda.

O homem abriu um baita sorriso.

Anotou alguma coisa.

Foi embora.

Naquele instante percebi que havia cometido algo maravilhoso:

eu tinha entregado meu almoço aos italianos.

---

🍷 O SUMO DOS DEUSES

Pedi vinho da casa.

Veio numa jarra.

Nada de cerimônia.

Nada de uma garrafa acompanhada de uma palestra de quinze minutos sobre notas de carvalho, frutas vermelhas colhidas durante determinada fase da Lua ou o estado emocional das uvas.

Era vinho.

Na jarra.

Sumo dos deuses.

Chegou uma entrada.

Comecei a comer.

E observar.

Os clientes conversavam.

Os garçons circulavam.

O porão tinha vida.

Eu estava sozinho, mas não me sentia isolado.

E então chegou a comida.

Aquela mesma cozinha que eu havia espionado através do vidro às nove da manhã finalmente havia terminado seu processamento batch.

Era hora de consumir a produção.

---

🏛️ O LEGIONÁRIO VOLTOU DA GÁLIA

Aqui preciso confessar que provavelmente abandonei parte da elegância.

Estava com fome.

Tinha caminhado.

A comida estava maravilhosa.

O vinho estava ajudando.

Em algum momento comecei a comer com as mãos aquilo que permitia ser comido com as mãos.

Eu devia estar com uma expressão parecida com a de um legionário romano depois de marchar 25 quilômetros e finalmente receber comida.

Não estava degustando.

Estava mandando ver.

HUNGER_LEVEL = LEGIONARY
WINE_BUFFER = LOADED
CUTLERY = OPTIONAL
CUSTOMER_HAPPINESS = 100%

E foi aí que percebi uma mesa ao lado.

Havia dois velhinhos.

Pela minha observação rápida, concluí:

casados.

Um casal de idosos almoçando tranquilamente.

Eles começaram a me observar.

E aparentemente estavam se divertindo bastante vendo aquele brasileiro travar sua própria batalha contra a comida.

Vieram os primeiros olhares.

Sorrisos.

Até que puxaram conversa.

---

🇧🇷🤝🇮🇹 COMEÇA A DIPLOMACIA BRASIL–PARMA

Conversa vai.

Conversa vem.

Descobrem que sou brasileiro.

Explico minha peregrinação.

Falamos sobre coisas que hoje já não consigo reconstruir completamente.

Mas a barreira entre as duas mesas começa a desaparecer.

Até que eles oferecem:

— Quer experimentar isto?

Era o prato deles.

Agora havia um problema diplomático gravíssimo.

Recusar poderia provocar um incidente internacional entre Brasil e Itália.

Como patriota responsável, aceitei.

E descobri mais um sabor de Parma.

Aquilo não havia sido escolhido pelo garçom para o brasileiro.

Era aquilo que eles próprios estavam comendo.

De repente eu já não tinha apenas meu almoço.

Tinha acesso ao almoço da mesa vizinha.

Continuamos conversando.

Então veio outra oferta.

Vinho.

O vinho deles.

Aceitei novamente, desta vez já um pouco sem graça.

Mas integrado.

Comida atravessava a fronteira das mesas.

Vinho atravessava.

Histórias atravessavam.

Eu havia entrado naquele porão como um desconhecido.

Pouco tempo depois estava compartilhando comida com duas pessoas que jamais tinha visto na vida.

---

🎭 O PRIMEIRO PLOT TWIST

Foi durante a conversa que descobri que minha capacidade de investigação antropológica precisava de manutenção urgente.

Eles não eram casados.

A mulher era filha daquele senhor.

E havia mais.

Ela estava ali porque aquele dia era...

aniversário do pai.

Parei mentalmente por alguns segundos.

Então aquela não era simplesmente uma refeição cotidiana.

Eu havia entrado acidentalmente numa pequena celebração familiar.

A filha tinha levado o pai para almoçar.

E, no meio daquela comemoração, apareceu na mesa vizinha um brasileiro faminto comendo como se tivesse acabado de atravessar os Alpes com Aníbal.

Por alguma razão, eles resolveram conversar comigo.

Depois dividir a comida.

Depois dividir o vinho.

Eu estava sendo progressivamente absorvido por uma festa para a qual jamais havia sido convidado.

E ainda não tinha acontecido a melhor parte.

---

🎂 ENTÃO O GARÇOM APARECEU COM UMA TORTA

A refeição estava chegando ao fim.

Eu já havia comido maravilhosamente.

Bebido.

Conversado.

Rido.

Conhecido sabores que nem estavam no meu pedido.

Foi então que o garçom apareceu.

Carregava uma torta de aniversário.

Era para o velhinho.

E aconteceu uma dessas pequenas coisas que parecem insignificantes quando descritas rapidamente, mas que ficam armazenadas em algum lugar estranho da memória durante décadas.

Nós cantamos parabéns para ele.

A filha.

As pessoas do restaurante.

E aquele brasileiro que algumas horas antes estava do lado de fora fotografando homens fazendo macarrão através de uma vitrine.

Eu também cantei.

Para um homem cujo nome talvez eu nem tenha guardado.

Num porão em Parma.

---

❤️ NÃO ESTAVA NO SCRIPT

É aqui que a história deixa de ser sobre comida.

Eu tinha ido a Parma para procurar Verdi.

Queria história.

Música.

Carlos Gomes.

Igrejas.

Arquitetura.

E encontrei tudo isso.

Mas nenhuma dessas coisas estava naquele momento diante de mim.

Diante de mim havia apenas um senhor comemorando mais um ano de vida ao lado da filha.

E eu, um completo desconhecido, havia sido incorporado por alguns minutos àquela memória familiar.

Não estava no roteiro.

Não estava no bilhete do trem.

Não estava num guia turístico.

Não havia reservado aquela experiência pela internet.

Ninguém me vendeu um pacote chamado:

“Authentic Parma Experience — Lunch With Locals.”

Aconteceu.

Só isso.

Aconteceu.

---

🍝 A MELHOR COMIDA DA EUROPA?

Durante muitos anos, quando penso nas melhores refeições que tive na Europa, Parma aparece imediatamente.

Faço apenas uma exceção.

A comida caseira da Dona Gui, minha sogra.

Essa joga em outra categoria.

Mas, fora dela, Parma permanece em algum lugar muito especial da memória.

E hoje percebo que talvez eu tenha cometido um erro durante anos dizendo:

“Foi uma das melhores comidas que comi na Europa.”

Porque não consigo mais separar o sabor daquilo que aconteceu ao redor.

Quanto daquele macarrão era realmente macarrão?

Quanto daquele vinho era realmente vinho?

Quanto do sabor vinha do porão?

Dos velhinhos?

Da conversa?

Do prato que atravessou de uma mesa para outra?

Da jarra?

Da caminhada?

Da fome?

Da surpresa?

Do aniversário?

Da torta?

Não sei.

Talvez memória gastronômica seja justamente isso.

Comemos também o momento.

---

🧠 O BANCO DE DADOS QUE NÃO GUARDA APENAS SABORES

Décadas depois, algumas coisas desapareceram.

Não lembro cada palavra.

Não lembro necessariamente o nome de todos os pratos.

Talvez não consiga reconstruir perfeitamente o restaurante.

Mas consigo lembrar da sensação.

Curiosamente, enquanto escrevia esta história tantos anos depois, meus olhos ficaram marejados.

E isso talvez seja a melhor avaliação gastronômica que aquele restaurante jamais receberá de mim.

Não cinco estrelas.

Não dez pontos.

Não uma fotografia bonita.

Uma lembrança que ainda consegue provocar lágrimas décadas depois.

---

🚶 VIAJAR NÃO É APENAS CHEGAR

Talvez seja por isso que sempre gostei tanto de zanzar.

Quando seguimos apenas o roteiro, encontramos aquilo que fomos procurar.

Quando caminhamos sem tanta pressa, às vezes encontramos aquilo que não sabíamos que existia.

Se eu tivesse escolhido outro caminho naquela manhã, não teria visto a vitrine.

Se não tivesse parado, talvez não tivesse guardado o restaurante.

Se Brigitte não tivesse começado a reclamar às treze horas, talvez tivesse almoçado em outro lugar.

Se tivesse pedido apenas aquilo que conhecia, talvez o garçom não tivesse aberto aquele sorriso.

Se estivesse olhando para o telefone enquanto comia, talvez os dois nunca tivessem puxado conversa.

Se tivesse recusado o prato por educação, perderia um sabor.

Se tivesse recusado o vinho por vergonha, perderia outro pedaço da conversa.

Uma sequência absurda de pequenos IFs.

IF passeio = curioso
AND fome = verdadeira
AND restaurante = aquele
AND garcom = inspirado
AND mesas_vizinhas = abertas
AND viajante = disposto
THEN
    memoria = inesquecivel
END-IF

Nenhum deles isoladamente significa muita coisa.

Juntos produziram uma tarde que atravessou décadas.

---

🍷 EPÍLOGO — O VELHINHO DE PARMA

Não sei o que aconteceu depois com aquele senhor.

Não sei quantos outros aniversários ele comemorou.

Não sei se a filha alguma vez se lembrou daquele brasileiro estranho que apareceu no almoço do pai.

Provavelmente fui apenas uma pequena curiosidade daquele dia.

Talvez tenham voltado para casa e comentado:

— Aquele brasileiro estava com fome, hein?

E dado risada.

Mas existe algo bonito nisso.

Porque eles provavelmente nunca souberam que, muitos anos depois, do outro lado do Atlântico, aquele brasileiro ainda contaria a história.

Ainda lembraria do vinho.

Ainda lembraria da comida passando de uma mesa para outra.

Ainda lembraria da torta chegando.

Ainda lembraria de cantar parabéns.

Eu fui até Parma procurar a memória de homens famosos.

Giuseppe Verdi.

Antônio Carlos Gomes.

E acabei trazendo comigo a memória de um homem anônimo.

Talvez essa seja a maior ironia daquela viagem.

Verdi entrou para a História.

Carlos Gomes entrou para a História.

Mas aquele velhinho...

entrou na minha.

E talvez seja exatamente por isso que Parma continua tendo um sabor que nenhum restaurante conseguiu reproduzir.

Porque certas receitas precisam de ingredientes que não existem numa cozinha:

fome, acaso, curiosidade, generosidade, duas mesas, uma filha, um pai, uma torta e um brasileiro que simplesmente estava passando por ali.

🍷

Buon compleanno, signore.

Onde quer que o tempo tenha levado você.

Eu ainda me lembro daquele almoço.

---

☕ Um Café no Bellacosa Mainframe

Porque algumas das melhores histórias da vida nunca passaram pelo ambiente de homologação.