Os Três Bugs Invisíveis do Padawan COBOL : Como vencer a hesitação, a ingenuidade e o excesso de confiança

Bellacosa Mainframe e os 3 bugs invisiveis do padawan cobol

---

☕ Um Café no Bellacosa Mainframe

Os Três Bugs Invisíveis do Padawan COBOL

Como vencer a hesitação, a ingenuidade e o excesso de confiança antes que eles provoquem o primeiro ABEND da sua carreira

"O primeiro programa raramente derruba o banco. O primeiro erro de julgamento, sim."

---

Introdução

Existe um momento curioso na carreira de praticamente todo programador COBOL.

Não importa se ele estudou durante seis meses, um ano ou cinco anos.

Não importa se tirou certificações IBM.

Não importa se domina PROCEDURE DIVISION, PERFORM VARYING, OCCURS DEPENDING ON, SQL EMBEDDED, CICS ou VSAM.

O verdadeiro teste começa no primeiro dia em produção.

É ali que nasce o verdadeiro programador.

Durante décadas observando profissionais entrando em grandes bancos, seguradoras, empresas aéreas, órgãos públicos e processadoras de cartões, percebi um padrão curioso.

Os novatos quase nunca fracassam por falta de conhecimento técnico.

Eles tropeçam em três inimigos invisíveis.

São eles:

• Hesitação

• Ingenuidade

• Excesso de confiança

Esses três defeitos aparecem em praticamente toda profissão crítica.

Na aviação.

Na medicina.

Na engenharia.

Na investigação criminal.

E, principalmente, em ambientes IBM Mainframe.

O curioso é que eles aparecem em momentos diferentes da evolução profissional.

E quase sempre na mesma ordem.

Hoje vamos investigar cada um deles como se estivéssemos em um episódio de CSI.

Porque um sistema crítico deixa rastros.

E a mente do programador também.

---

Cena do Crime 1

A Hesitação

Imagine a seguinte situação.

Você acabou de entrar na empresa.

Seu líder diz:

"Precisamos alterar o programa FINA340."

Você abre o programa.

28.000 linhas.

Escrito em 1989.

Última alteração:
há quatro dias.

Autores:

• João

• Carlos

• Equipe Y2K

• Projeto PIX

• Open Banking

• Adequação LGPD

Você olha aquilo.

O cursor pisca.

Cinco minutos.

Dez minutos.

Quinze minutos.

Você simplesmente não consegue tocar em nada.

Isso é completamente normal.

---

O cérebro entra em modo de sobrevivência

Nosso cérebro odeia destruir algo que parece importante.

Quanto maior a responsabilidade...

Maior a hesitação.

É um mecanismo biológico.

O problema é que hesitação excessiva paralisa.

E um programador parado não aprende.

---

O primeiro segredo

Veteranos não têm menos medo.

Eles apenas sabem investigar antes.

Essa é uma diferença gigantesca.

O novato pensa:

"Vou alterar."

O veterano pensa:

"Vou entender."

---

O método Bellacosa

Nunca altere antes de responder:

O que este programa faz?

Quem chama este programa?

Quem ele chama?

Quais arquivos atualiza?

Quais tabelas Db2 altera?

Existe rollback?

Existe commit?

Existe checkpoint?

Existe controle de versão?

Existe scheduler?

Existe impacto batch?

Existe impacto online?

Existe interface MQ?

Existe interface CICS?

Existe API?

Quando todas essas respostas aparecem...

A hesitação desaparece.

Porque ela foi substituída por conhecimento.

---

Easter Egg

Sherlock Holmes dizia:

"É um erro teorizar antes de possuir os fatos."

Todo programador COBOL deveria colocar essa frase no monitor.

---

Cena do Crime 2

A Ingenuidade

Depois do primeiro mês...

A hesitação diminui.

Agora nasce outro inimigo.

O iniciante acredita em tudo.

Documentação.

Comentários.

Fluxogramas.

Diagramas.

PowerPoint.

Wiki.

Chamados.

Manuais.

---

A maior mentira do Mainframe

Imagine encontrar isso:

* Atualiza somente clientes ativos

Bonito.

Organizado.

Profissional.

Mas você olha o código...

MOVE "S" TO WS-ATIVO

Nada mais.

Nenhuma validação.

Nenhuma regra.

Nenhum IF.

O comentário está errado há quinze anos.

Quem escreveu?

Provavelmente alguém que saiu da empresa em 2004.

---

A documentação envelhece

Código muda.

Documentação nem sempre.

O sistema continua funcionando.

Mas o documento virou arqueologia.

É como encontrar um mapa romano tentando dirigir em São Paulo.

---

A regra de ouro

Nunca confie totalmente em:

Comentários

Diagramas

Documentação

Fluxogramas

Apresentações

Emails antigos

Confie no comportamento do sistema.

Ele não mente.

---

Curiosidade

Muitos bancos possuem documentação cuja última atualização ocorreu antes do PIX existir.

O sistema evoluiu.

O documento não.

---

Cena do Crime 3

O Excesso de Confiança

Esse é o mais perigoso.

Porque normalmente aparece depois dos primeiros sucessos.

Você já resolveu alguns chamados.

Corrigiu ABEND.

Alterou tela CICS.

Fez alguns programas.

Agora pensa:

"Estou dominando."

É aí que mora o perigo.

---

O efeito Dunning-Kruger no Mainframe

Existe um fenômeno psicológico famoso.

Quanto menos sabemos...

Mais acreditamos saber.

Depois de alguns anos...

Percebemos o tamanho do universo.

É curioso.

O profissional de cinco meses costuma parecer mais confiante que o de vinte anos.

Porque ainda não descobriu tudo o que desconhece.

---

O veterano faz mais perguntas

O iniciante responde rápido.

O veterano pergunta mais.

Isso parece contraditório.

Mas faz sentido.

O veterano conhece centenas de armadilhas.

Ele sabe que sistemas críticos escondem surpresas.

---

Exemplo clássico

Você altera:

IF SALDO > 0

Parece simples.

Mas esquece que existe outro programa batch.

Outro online.

Outro scheduler.

Outro MQ.

Outro API Gateway.

Outro processo noturno.

Outro job semanal.

Outro fechamento mensal.

Outro processamento anual.

Seu IF alterou uma cadeia inteira.

---

O código nunca vive sozinho

Essa talvez seja a maior descoberta da carreira.

Programas COBOL não são ilhas.

São organismos.

Cada programa conversa com dezenas de outros.

Às vezes centenas.

Você altera uma linha.

Pode movimentar uma cidade inteira.

---

CSI Mainframe

Imagine Gil Grissom entrando no CPD.

Ele nunca começaria perguntando:

"Quem é o culpado?"

Ele perguntaria:

"O que aconteceu primeiro?"

Depois:

"O que mudou?"

Depois:

"Quem foi impactado?"

É exatamente assim que um analista experiente investiga incidentes.

---

Indiana Jones no Data Center

O código legado lembra uma cidade perdida.

Você entra com uma tocha.

Cada COPYBOOK é uma sala.

Cada PERFORM é um corredor.

Cada CALL é uma porta secreta.

Cada JCL é um mapa.

Cada PROC é um túnel subterrâneo.

E cada alteração pode ativar uma armadilha escondida.

O aventureiro imprudente corre.

O arqueólogo observa.

---

A Regra dos Cinco "Por Quês"

Sempre pergunte:

Por que isso existe?

Por que foi escrito assim?

Por que não removeram?

Por que ainda funciona?

Por que ninguém mexe nisso?

A quinta resposta normalmente revela uma decisão de negócio esquecida.

---

O Erro Mais Caro

Não é apagar um arquivo.

Nem provocar um ABEND.

Nem esquecer um END-IF.

O erro mais caro é assumir.

Assumir que entendeu.

Assumir que ninguém usa.

Assumir que é simples.

Assumir que o comentário está correto.

Assumir que aquele campo nunca recebe zeros.

Mainframe odeia suposições.

---

O Poder da Humildade Técnica

Existe uma frase muito comum entre grandes especialistas IBM.

"Não sei. Vamos verificar."

Observe.

Eles não respondem imediatamente.

Eles investigam.

Essa postura não demonstra fraqueza.

Demonstra maturidade.

---

O Ritual Bellacosa Antes de Alterar Qualquer Programa

Criei ao longo dos anos um pequeno ritual que evita boa parte dos problemas em produção. Antes de salvar qualquer alteração, faça estas perguntas:

1. Entendi exatamente qual é o problema de negócio?

2. Descobri todos os programas envolvidos?

3. Verifiquei os COPYBOOKs relacionados?

4. Analisei impactos em Db2, VSAM, CICS ou IMS?

5. Procurei alterações semelhantes no histórico?

6. Executei testes com dados normais e dados extremos?

7. Pensei no que acontece se um campo vier vazio, nulo ou inesperado?

8. Existe plano de retorno (rollback) caso algo dê errado?

9. Alguém mais experiente revisou minha lógica?

10. Eu conseguiria explicar esta alteração para outra pessoa em cinco minutos?

Se alguma resposta for "não", ainda há investigação a fazer.

---

Os Três Mestres da Carreira

Todo grande profissional aprende a equilibrar três características:

Coragem
Para enfrentar programas enormes sem fugir.

Curiosidade
Para investigar antes de alterar.

Humildade
Para aceitar que sempre existe algo escondido no sistema.

Esses três pilares são muito mais importantes do que decorar todas as instruções do COBOL.

---

O Último Easter Egg

Na saga Star Wars, Luke Skywalker acreditava que vencer significava lutar melhor.

Yoda ensinou outra coisa.

Primeiro, controlar a própria mente.

Só depois controlar o sabre de luz.

No Mainframe acontece exatamente o mesmo.

O COBOL não é o sabre.

O sabre é apenas uma ferramenta.

O verdadeiro combate acontece dentro da cabeça do programador.

A hesitação precisa ser transformada em investigação.

A ingenuidade precisa ser substituída por validação.

O excesso de confiança precisa dar lugar à disciplina.

Quando isso acontece, nasce um profissional capaz de trabalhar em ambientes onde milhões de transações financeiras, folhas de pagamento, benefícios governamentais, seguros, cartões de crédito e operações bancárias dependem de algumas linhas de código escritas décadas atrás.

---

Conclusão — O Primeiro Grande Upgrade Não é no Código, é no Programador

No universo Bellacosa Mainframe, costumo dizer que existem dois tipos de iniciantes.

O primeiro acredita que aprender COBOL significa memorizar verbos, comandos, JCLs e utilitários. Ele mede seu progresso pela quantidade de sintaxes que conhece.

O segundo entende que COBOL é apenas a linguagem usada para conversar com um ecossistema gigantesco de regras de negócio, processos, integrações e pessoas. Ele mede seu progresso pela qualidade das perguntas que faz, pela capacidade de investigar antes de modificar e pela prudência ao assumir responsabilidades.

É esse segundo profissional que evolui para analista, arquiteto, líder técnico e mentor.

A verdadeira iniciação de um Padawan Mainframe não acontece quando ele compila seu primeiro programa sem erros. Ela acontece no dia em que percebe que um sistema legado é como um templo antigo: cada rotina foi construída por gerações diferentes, cada COPYBOOK guarda um pedaço da história da empresa e cada linha de código existe por um motivo — mesmo que esse motivo tenha sido esquecido pelo tempo.

Se você conseguir vencer a hesitação sem perder a prudência, abandonar a ingenuidade sem perder a curiosidade e controlar o excesso de confiança sem perder a coragem, terá desenvolvido a característica mais valiosa de todas: o julgamento técnico.

E julgamento técnico não se aprende em um manual. Ele é construído a cada investigação, a cada revisão de código, a cada incidente resolvido e a cada lição deixada por um erro.

No fim das contas, o maior sistema que um programador COBOL precisa aprender a administrar não é o z/OS, o CICS ou o Db2.

É a própria mente. Só quando ela trabalha de forma disciplinada, investigativa e humilde é que o restante do ecossistema Mainframe deixa de parecer um labirinto e passa a revelar sua verdadeira arquitetura. Nesse momento, o Padawan deixa de apenas escrever programas e começa, de fato, a pensar como um guardião dos sistemas que sustentam parte da economia do mundo.

 

Bellacosa Mainframe com dicas para padawan cobol dominar o db2

🔥☕ O CAMINHO DO PADAWAN Db2 — COMO UM PROGRAMADOR COBOL JÚNIOR SOBREVIVE AO MUNDO REAL DOS BANCOS NO MAINFRAME ☕🔥

Tem uma coisa que quase nenhum curso ensina direito.

O problema de aprender Db2 no mainframe NÃO é decorar:

• SELECT

• FETCH

• CURSOR

• JOIN

Isso qualquer apostila faz.

O verdadeiro desafio é entender:

🚀 COMO O Db2 “PENSA”

Porque no ambiente bancário:

• performance é dinheiro

• CPU custa milhões

• lock errado derruba sistema

• SQL ruim gera guerra entre desenvolvimento e DBA

• um tablespace scan pode parar um banco inteiro

E é aqui que nasce a diferença entre:

• um programador COBOL comum

• e um verdadeiro guerreiro do z/OS.

---

☕ O MAIOR ERRO DO PADAWAN COBOL

Todo iniciante chega no Db2 tentando programar como se estivesse lendo VSAM.

Faz:

• loop

• READ

• IF

• PERFORM

• validação manual

• cursor desnecessário

e transforma o Db2 num simples “arquivo sofisticado”.

🔥 Grave isso:

Db2 NÃO é VSAM.

Db2 é:

• relacional

• baseado em conjuntos

• otimizado matematicamente

• orientado a custo

• controlado por estatísticas

---

🚀 O PROGRAMADOR MAINFRAME MODERNO NÃO PENSA EM LINHAS

Ele pensa em:

SETS

---

☕ PROCESSAMENTO RELACIONAL

O programador antigo pensa assim:

“Vou buscar linha por linha e processar.”

O programador Db2 sênior pensa:

“Como faço o Db2 processar tudo sozinho?”

Essa mudança mental vale OURO.

---

🔥 SQL NÃO É APENAS CONSULTA

O padawan acha que SQL é:

SELECT *
FROM CLIENTE

Mas Db2 é MUITO maior:

• optimizer

• locking

• clustering

• filter factors

• parallelism

• stage 1/stage 2

• access paths

• static SQL

• dynamic SQL

• utilities

• EXPLAIN

E quando você entende isso…
você começa a dominar o ambiente bancário.

---

☕ O OPTIMIZER É O VERDADEIRO “CÉREBRO” DO Db2

No mainframe bancário:

• ninguém lê bilhões de linhas “na força”

• ninguém faz scan por diversão

• ninguém quer CPU extra

O optimizer decide:

• qual índice usar

• qual join usar

• se haverá sort

• se haverá prefetch

• se haverá paralelismo

---

🚀 E O QUE O OPTIMIZER USA?

Estatísticas.

RUNSTATS é praticamente:

“os olhos do optimizer”

Sem estatísticas:

• access path piora

• índice é ignorado

• FF fica errado

• CPU explode

---

☕ FILTER FACTOR — O SEGREDO QUE MUITOS IGNORAM

Pouca gente iniciante entende isso.

Mas FF muda TUDO.

🚀 Filter Factor

é:

• a estimativa da porcentagem de linhas que satisfazem um predicado.

---

☕ Exemplo

WHERE DEPT = 'A00'

Se existem:

• 10 departamentos

Db2 estima:

1/10 = 0.1

Ou seja:

• 10% das linhas serão retornadas.

---

🔥 Quanto MENOR o FF:

MELHOR

Porque:

• menos linhas

• menos I/O

• menos CPU

• menos pages

• menos lock

---

☕ O ERRO CLÁSSICO DO PADAWAN

WHERE COL <> 'X'

🔥 Péssimo FF.

Db2 entende:

“quase todas as linhas servem”

Então:

• índice perde valor

• scan aparece

• CPU sobe

---

🚀 INDEX NÃO É MAGIA

Outro choque do iniciante.

Ter índice NÃO garante performance.

O optimizer escolhe:

• usar

• ignorar

• combinar

• fazer screening

• fazer scan

dependendo:

• FF

• cardinalidade

• clustering

• custo estimado

---

☕ O MUNDO REAL DOS BANCOS

Em banco grande:

• tabela pode ter bilhões de linhas

• índice pode ter centenas de GB

• um SQL ruim pode consumir milhares de MIPS

Por isso:

access path é assunto sagrado.

---

🔥 STAGE 1 vs STAGE 2

Esse conceito separa:

• SQL eficiente

• SQL sofrível

---

☕ Stage 1

Predicado processado cedo:

• no Data Manager

• usando índice

• reduzindo linhas rapidamente

Mais rápido.

---

☕ Stage 2

Predicado processado depois:

• mais CPU

• mais linhas avaliadas

• menos eficiência

---

🚀 Exemplo ruim

WHERE YEAR(DATA) = 2025

Função na coluna:

• pode matar indexabilidade

• virar stage 2

---

☕ Melhor abordagem

WHERE DATA BETWEEN '2025-01-01'
AND '2025-12-31'

---

🔥 LOCKING — O TERROR DOS BANCOS

Padawan geralmente aprende SELECT…

mas não aprende:

concorrência.

E no banco:

• milhares de programas acessam a mesma tabela ao mesmo tempo.

---

☕ Lock errado gera:

• timeout

• deadlock

• lentidão

• aplicação travada

• fila no CICS

• caos operacional

---

🚀 LOCKSIZE

Db2 pode bloquear:

• row

• page

• table space

---

☕ O perigo do PAGE LOCK

Uma página pode conter:

• várias linhas

Então:

• um lock pode bloquear muitos registros sem você perceber.

---

🔥 ISOLATION LEVEL

Outro tema CRÍTICO.

---

☕ CS — Cursor Stability

Mais comum no OLTP bancário.

Balanceia:

• integridade

• concorrência

---

☕ RR — Repeatable Read

Mais rígido.
Mais locks.
Mais contenção.

---

☕ UR — Uncommitted Read

O famoso:

dirty read

Excelente para:

• relatórios

• analytics

• consultas não críticas

Péssimo para:

• saldo bancário

• movimentação financeira

😄

---

🚀 COMO EVITAR DEADLOCK

O curso mostrou algo IMPORTANTÍSSIMO:

Todos os programas devem atualizar na mesma sequência.

---

☕ Exemplo

Programa A:

CLIENTE → CONTA

Programa B:

CONTA → CLIENTE

🔥 Receita perfeita para deadlock.

---

🚀 ACCESS PATH — A ALMA DO Db2

Toda query possui um plano.

Db2 decide:

• scan

• index access

• nested loop

• merge scan

• hybrid join

• hash join

---

☕ TABLESPACE SCAN

Lê tudo.

Pode ser:

• correto

• ou desastre absoluto.

---

☕ INDEXED ACCESS

Busca seletiva.

Muito mais eficiente quando:

• FF é baixo

• índice é adequado

---

🚀 JOINS — O CAMPO DE BATALHA

Padawan normalmente só aprende:

INNER JOIN

Mas Db2 usa:

• nested loop

• merge scan

• hybrid join

• star join

dependendo:

• tamanho

• índices

• cardinalidade

---

☕ MERGE SCAN JOIN

Excelente para:

• tabelas grandes

• sem índices úteis

• dados ordenados

---

🔥 STATIC SQL vs DYNAMIC SQL

No banco:
isso é discussão séria.

---

☕ STATIC SQL

Pré-compilado.
Pré-otimizado.

Perfeito para:

• CICS

• OLTP

• alta performance

---

☕ DYNAMIC SQL

Construído runtime.

Excelente para:

• analytics

• ferramentas

• SQL variável

---

🚀 Por que bancos AMAM STATIC SQL?

Porque:

• menos CPU

• menos prepare

• access path estável

• melhor governança

---

☕ EXPLAIN — O RAIO-X DO OPTIMIZER

Se você não usa EXPLAIN…
você está programando no escuro.

---

🚀 EXPLAIN mostra:

• índice usado

• tipo de join

• matching columns

• prefetch

• paralelismo

• custo estimado

---

☕ PLAN_TABLE

É praticamente:

a Bíblia do tuning Db2.

---

🔥 UNION vs UNION ALL

Padawan frequentemente usa:

UNION

sem perceber:

• Db2 faz SORT

• remove duplicatas

• aumenta CPU

---

🚀 UNION ALL

Muito mais rápido.

Use quando:

• duplicatas não importam.

---

☕ FETCH FIRST

Outro segredo simples que salva CPU.

---

❌ Errado

SELECT *
FROM BIGTABLE

---

✅ Melhor

FETCH FIRST 10 ROWS ONLY

---

🚀 “PEÇA SOMENTE O NECESSÁRIO”

Essa é uma filosofia inteira do Db2.

---

☕ EVITE ESCREVER CÓDIGO

A aula falou algo brilhante:

“Avoid Writing Code”

---

🚀 O Db2 já sabe:

• somar

• converter

• truncar

• upper/lower

• calcular datas

• agregar

• ordenar

• paralelizar

Então:

• use funções SQL

• use set processing

• use procedures

• use triggers

---

☕ O COBOL NÃO DEVE FAZER O QUE O Db2 FAZ MELHOR

Essa frase muda carreiras.

---

🔥 O SEGREDO FINAL

No ambiente bancário:
o programador COBOL NÃO domina apenas COBOL.

Ele precisa entender:

• SQL

• optimizer

• access path

• locking

• concurrency

• CPU

• I/O

• clustering

• statistics

• utilities

Porque:

o verdadeiro programa executa dentro do Db2.

---

☕ O PADAWAN VIRA MESTRE QUANDO ENTENDE:

“SQL não é uma linguagem de acesso.
SQL é uma linguagem de processamento.”

🔥☕ Welcome to the real mainframe world, padawan.

O Que Todo Programador COBOL Padawan Precisa Saber Sobre Como o Java Evoluiu de uma Linguagem Acadêmica para um dos Pilares da Computação Moderna

 

Bellacosa Mainframe e a evolucao do java

☕ Um Café no Bellacosa Mainframe

A Evolução Contínua do Java

O Que Todo Programador COBOL Padawan Precisa Saber Sobre Como o Java Evoluiu de uma Linguagem Acadêmica para um dos Pilares da Computação Moderna

"Você não está apenas aprendendo Java. Está estudando uma linguagem que, assim como o COBOL, sobreviveu às mudanças tecnológicas, reinventou-se diversas vezes e continua sendo uma das plataformas mais importantes do planeta."

---

Introdução

Existe uma frase muito comum no mundo da tecnologia:

"Java morreu."

Curiosamente, ela é repetida praticamente todos os anos... há mais de vinte anos.

Enquanto isso...

• Bancos continuam utilizando Java.

• Empresas aéreas utilizam Java.

• Amazon utiliza Java.

• Netflix utiliza Java.

• Google utiliza Java.

• IBM utiliza Java.

• Android nasceu utilizando Java.

• Bilhões de dispositivos executam código Java diariamente.

Parece familiar?

Quem trabalha com COBOL já ouviu exatamente a mesma história.

Há décadas anunciam a morte do COBOL.

E, décadas depois, ele continua processando trilhões de dólares diariamente.

Java e COBOL compartilham algo muito raro:

São linguagens que aprenderam a evoluir sem abandonar seu passado.

Essa talvez seja sua maior qualidade.

---

O nascimento do Java

Em 1991, a Sun Microsystems iniciou um projeto chamado Green Project.

O objetivo inicial não era criar uma linguagem para internet.

Era desenvolver software para eletrodomésticos inteligentes.

O líder do projeto era James Gosling.

O primeiro nome da linguagem era...

Oak

(nome inspirado em um carvalho que existia em frente ao escritório.)

Como já existia outra linguagem chamada Oak, escolheram outro nome.

Durante uma reunião, enquanto tomavam café...

Surgiu o nome:

Java

Inspirado no famoso café produzido na ilha de Java, na Indonésia.

Coincidência?

Talvez seja por isso que um Café no Bellacosa Mainframe combina tanto com Java.

---

O maior acerto da história

Em 1995 surgiu um slogan que mudou a computação.

Write Once, Run Anywhere

Escreva uma vez.

Execute em qualquer lugar.

Na época isso parecia impossível.

Cada sistema operacional utilizava APIs diferentes.

Java resolveu esse problema através da JVM.

---

Bellacosa Mainframe timeline do java

A JVM

Ao contrário do COBOL, que normalmente gera código nativo para z/OS ou outro sistema operacional, Java gera um arquivo intermediário:

Bytecode

Esse bytecode é executado pela:

Java Virtual Machine

Resultado:

Windows

↓

Linux

↓

Mac

↓

IBM Z

↓

AIX

↓

Cloud

↓

Containers

Tudo executa exatamente o mesmo programa.

Foi uma revolução.

---

Java 8 — O novo começo (Março/2014)

Muitos especialistas dizem que existem dois Java:

Antes do Java 8.

Depois do Java 8.

E existe um bom motivo para isso.

Lambdas

Antes:

Collections.sort(lista,new Comparator<Pessoa>(){...});

Depois

lista.sort((a,b)->a.nome.compareTo(b.nome));

Muito menos código.

Muito mais legibilidade.

---

Stream API

Antes

for
if
for
if

Depois

clientes.stream()
.filter(...)
.map(...)
.collect(...)

A programação tornou-se declarativa.

---

Optional

Acabou boa parte dos famosos:

NullPointerException

---

Date and Time API

Finalmente uma API moderna para datas.

---

Curiosidade

O Java 8 ainda é uma das versões mais utilizadas no mundo corporativo.

Muitas empresas migraram diretamente do Java 8 para o Java 17 ou Java 21.

---

Java 9 — Modularização (Setembro/2017)

Projeto:

Jigsaw

Imagine o Java como um enorme sistema COBOL.

Antes era um único monólito.

Agora tornou-se modular.

Benefícios:

• aplicações menores

• inicialização mais rápida

• segurança

• encapsulamento

---

JShell

Pela primeira vez o Java ganhou um REPL.

Como o TSO READY.

Você digita.

Executa.

Vê o resultado.

Sem compilar projetos inteiros.

---

Java 10 (Março/2018)

Poucas novidades.

Mas uma delas mudou completamente o estilo de programação.

var

Antes

HashMap<String,List<Cliente>> mapa=

Depois

var mapa=

Muito mais simples.

---

Dica Bellacosa

var não significa linguagem fracamente tipada.

O tipo continua existindo.

O compilador apenas o deduz.

---

Java 11 LTS (Setembro/2018)

Primeira versão LTS após o Java 8.

Grande parte das empresas migrou diretamente para ela.

---

HTTP Client

Finalmente uma API moderna.

Sem bibliotecas externas.

---

TLS melhorado

Mais segurança.

---

Garbage Collection

Novos algoritmos.

---

Remoção do JavaFX

Agora distribuído separadamente.

---

Easter Egg

A Oracle removeu diversas APIs antigas.

Muitos sistemas antigos "pararam de compilar".

Foi um grande choque para empresas.

---

Java 17 LTS (Setembro/2021)

Talvez a maior evolução desde o Java 8.

---

Records

Antes

Classe

Construtor

Getter

Setter

Equals

HashCode

ToString

Depois

record Cliente(...)

Fim.

---

Sealed Classes

Controle rigoroso de herança.

Muito útil para arquiteturas grandes.

---

Pattern Matching

Menos código.

Mais clareza.

---

Curiosidade

Os compiladores modernos conseguem otimizar Pattern Matching melhor do que cadeias enormes de if.

---

Java 21 LTS (Setembro/2023)

Aqui aconteceu algo gigantesco.

---

Project Loom

Virtual Threads.

Imagine um CICS.

Agora imagine milhões de transações simultâneas.

Era necessário criar milhões de Threads.

Muito caro.

Agora...

Virtual Threads.

Criadas praticamente como objetos.

Muito mais leves.

---

Analogia Mainframe

No z/OS existe décadas de engenharia para lidar com milhares de usuários simultaneamente.

Java começou a aproximar-se dessa eficiência.

---

Sequenced Collections

Coleções finalmente ganharam ordenação consistente.

---

Record Patterns

Mais elegância.

---

Foreign Function & Memory API

Interoperabilidade sem JNI tradicional.

---

Java 23

Versão intermediária.

Não LTS.

Seu objetivo principal foi amadurecer recursos que chegariam às versões futuras.

Isso faz parte da estratégia moderna do OpenJDK: lançar inovações em ciclos rápidos para que sejam testadas e refinadas antes de integrarem uma versão LTS.

Entre os destaques estão a continuidade do aperfeiçoamento das Virtual Threads, do Pattern Matching e das APIs em incubação relacionadas à JVM, desempenho e experiência do desenvolvedor.

---

Java 25 LTS (Setembro/2025)

Mais uma versão de suporte de longo prazo.

O foco esteve em:

• maior estabilidade

• otimizações da JVM

• melhor gerenciamento de memória

• reforços de segurança

• consolidação de recursos introduzidos nas versões anteriores

Para empresas, o Java 25 representa uma excelente opção para novos projetos corporativos que buscam longevidade.

---

Java 26 (Março/2026)

O Java 26 dá continuidade ao ciclo semestral do OpenJDK.

Embora não seja uma versão LTS, ela demonstra o compromisso da plataforma com evolução constante.

Os temas centrais incluem:

• evolução da JVM

• melhorias de performance

• otimizações do compilador JIT

• avanços em segurança

• preparação para futuras funcionalidades voltadas à inteligência artificial, computação em nuvem e aplicações distribuídas

Mais do que adicionar recursos isolados, o Java 26 mostra que a plataforma continua refinando sua arquitetura para os desafios da próxima década.

---

O que um COBOL Padawan pode aprender com Java?

Muito mais do que sintaxe.

Java ensina conceitos modernos que complementam a experiência adquirida no mainframe.

Entre eles:

• Programação Orientada a Objetos

• APIs REST

• Microsserviços

• Containers

• Kubernetes

• Mensageria (Kafka, MQ)

• Programação Funcional

• Programação Reativa

• Virtual Threads

• Cloud Native

Todos esses conceitos dialogam cada vez mais com ambientes IBM Z modernos.

---

Curiosidades

☕ O mascote Duke

O mascote oficial do Java chama-se Duke.

Foi criado ainda na Sun Microsystems e continua sendo um dos símbolos mais conhecidos da linguagem.

---

☕ Java e COBOL convivem

É comum encontrar sistemas onde:

COBOL
↓

CICS

↓

MQ

↓

Java

↓

REST

↓

Angular

↓

Aplicativo

As duas linguagens não competem.

Elas colaboram.

---

☕ IBM Z executa Java

Muita gente acredita que Java é exclusivo da nuvem.

Na realidade, a IBM investe há décadas em uma JVM altamente otimizada para o IBM Z.

O resultado é a execução de aplicações Java com excelente desempenho, aproveitando recursos avançados do hardware, como criptografia, processamento paralelo e alta disponibilidade.

---

☕ Java também fala com COBOL

Existem várias formas de integração:

• CICS Transaction Gateway

• IBM MQ

• z/OS Connect

• JDBC

• Web Services

• APIs REST

• JNI (em cenários específicos)

Essa interoperabilidade permite modernizar aplicações sem reescrever décadas de regras de negócio.

---

☕ Por que existem versões LTS?

Nem toda empresa pode atualizar seus sistemas a cada seis meses.

As versões Long-Term Support (LTS) recebem suporte prolongado, correções de segurança e estabilidade, tornando-se a escolha ideal para ambientes corporativos.

---

☕ A cadência de lançamentos

Desde 2018, o Java segue um calendário previsível:

• Março → versão intermediária

• Setembro → versão intermediária ou LTS (quando aplicável)

Essa previsibilidade facilita o planejamento de atualizações em grandes organizações.

---

Easter Eggs

☕ Duke escondido

Diversos exemplos oficiais da Oracle possuem pequenas aparições do Duke.

É quase um "Wally" para desenvolvedores Java.

---

☕ Café

O logotipo do Java representa uma xícara de café.

Até hoje.

Poucas linguagens possuem uma identidade visual tão reconhecida.

---

☕ Java e a Ilha de Java

O nome não veio da linguagem.

Veio do café.

E o café veio da ilha indonésia.

---

☕ O slogan que virou realidade

"Write Once, Run Anywhere" foi alvo de muitas piadas nos anos 1990 ("Write Once, Debug Everywhere"), mas a maturidade da JVM transformou essa promessa em uma das maiores vantagens da plataforma.

---

Dicas do Bellacosa Mainframe

• Aprenda conceitos, não apenas sintaxe. Um bom engenheiro entende arquitetura antes de decorar comandos.

• Mantenha-se em versões LTS para projetos corporativos, salvo quando houver necessidade de testar novidades.

• Explore a JVM. Entender Garbage Collection, JIT e gerenciamento de memória faz tanta diferença quanto conhecer JCL e parâmetros de execução no mainframe.

• Experimente o JShell. É uma excelente ferramenta para aprender rapidamente novos recursos da linguagem.

• Estude integração com IBM Z. Java e COBOL convivem muito bem quando unidos por APIs, mensageria e serviços.

---

Conclusão

Java não é apenas uma linguagem de programação.

É uma plataforma que evoluiu continuamente por mais de três décadas, mantendo um raro equilíbrio entre inovação e compatibilidade. Assim como o COBOL, ela demonstra que tecnologias sólidas não sobrevivem por acaso: sobrevivem porque conseguem se adaptar às mudanças sem perder a confiança de quem depende delas.

Para um Programador COBOL Padawan, conhecer a evolução do Java significa ampliar sua visão sobre arquitetura de software, computação distribuída e modernização de sistemas. O futuro das aplicações corporativas não será construído escolhendo entre COBOL ou Java, mas integrando o melhor dos dois mundos.

No Bellacosa Mainframe, costumamos dizer que um bom profissional não segue modismos: ele compreende a história da tecnologia para tomar melhores decisões no presente. A trajetória do Java, da versão 8 à 26, é um excelente exemplo de como inovação contínua e estabilidade podem caminhar lado a lado — uma lição que vale tanto para a JVM quanto para o universo do IBM Z. Afinal, as linguagens passam por transformações, mas os princípios da boa engenharia permanecem. E é justamente essa mentalidade que transforma um Padawan em um verdadeiro Mestre da Computação.

 

Bellacosa Mainframe apresenta o CICS Explorer

💥 SE VOCÊ AINDA VIVE DE CEMT, JÁ ESTÁ ATRASADO — O CICS EXPLORER TOMOU O CONTROLE NO IBM z17

Se você vive de CICS + COBOL, já ouviu isso:

“GUI é frescura. Eu resolvo tudo no CEMT.”

E sim… você resolve.
Mas no mundo do IBM z17 + CICS TS moderno, isso não é mais suficiente.

O CICS Explorer não substitui sua experiência — ele potencializa.
E neste guia, você vai entender exatamente como e por quê.

---

🧠 A origem: de 3270 para Eclipse

Durante décadas, o mundo CICS foi dominado por:

• CEMT
• CEDA
• CECI
• Telas 3270

Era rápido, direto… e limitado visualmente.

Com a evolução do ecossistema IBM:

• Integração com APIs
• Observabilidade
• DevOps
• Cloud

👉 Surgiu o CICS Explorer: um cliente gráfico baseado em Eclipse.

💡 Pense assim:

Antes	Agora
CEMT	CICS Explorer
ISPF	z/OS Explorer
Manual	Visual + Automação

---

🚀 O que é o CICS Explorer (de verdade)

O CICS Explorer é um cockpit operacional e administrativo.

Ele permite:

✔️ Monitorar regiões em tempo real
✔️ Gerenciar recursos CICS
✔️ Executar operações sem digitar comandos
✔️ Visualizar dependências
✔️ Integrar com ferramentas modernas

👉 Tudo isso conectado ao seu CICS TS no z/OS.

---

🧩 Fundamentos que você precisa dominar (Mastery Test na prática)

🧭 1. Perspective = modo de trabalho

Uma Perspective define:

• Layout das views
• Organização da tela
• Contexto de trabalho

💡 Exemplo:

• Perspective CICS → operações
• Perspective z/OS → datasets

👉 Dica de ouro:
Layout = Perspective

---

🪟 2. Views = seus olhos dentro do CICS

As principais:

• Regions view → regiões conectadas
• Tasks view → execução em tempo real
• Programs view → status de programas
• Terminals view → sessões
• Error Log view → mensagens

💥 ESSA CAI NA PROVA:
👉 Error Log = logs + erros + warnings

---

🌳 3. Tree View = navegação hierárquica

Você expande:

Region → System → Resources

👉 Igual ISPF… só que visual.

---

🔌 4. Conexão com CICS

Estados clássicos:

• 🟢 Connected
• 🔄 Connecting
• 🔴 Error

💡 Easter egg de prova:
Se aparecer X vermelho → falha de conexão.

---

📊 5. Manipulação de dados

Você pode:

• Reordenar colunas (drag & drop)
• Filtrar dados
• Customizar visualizações
• Abrir editores

👉 Sim, igual Excel… mas com poder de mainframe.

---

🧾 6. Editor View (onde mora o perigo)

Aqui você altera atributos:

• Programas
• Transações
• Recursos

💥 Regra crítica:

❌ Valor inválido → NÃO salva
✔️ Sistema bloqueia e mostra erro

👉 Sem “jeitinho”.

---

💾 7. Salvando alterações

3 formas clássicas:

• 💾 Ícone de disco
• ⌨️ Ctrl + S
• ❓ Fechar → confirmar

💡 NÃO funciona:

• Enter
• Ícones aleatórios

---

🧩 8. Views e layout

Você pode:

• Fechar view → botão X
• Reabrir via menu
• Salvar layout → Perspective

👉 Seu ambiente vira personalizado.

---

🔍 Help System (subestimado — mas cai na prova)

O Help do CICS Explorer é poderoso:

✔️ Suporta HTML
✔️ Pode integrar docs da empresa
✔️ Usa índice de busca

💡 Curiosidade (cai na prova)

Infopop = popup contextual de ajuda

👉 Pequena janela com:

• Dicas
• Links
• Informações rápidas

---

🧠 Easter Eggs e Curiosidades

💥 1. Explorer não substitui o CEMT
Ele usa APIs modernas (CMCI)

---

💥 2. Você ainda precisa saber 3270
Explorer é camada superior, não substituto total

---

💥 3. Drag & Drop é mais poderoso do que parece
Mover colunas, views, layouts = produtividade absurda

---

💥 4. Error Log é seu melhor amigo
Tudo que “não funciona” aparece lá

---

💥 5. Explorer é parte do AQUA
Ecossistema completo IBM (IDz, MQ Explorer, etc.)

---

⚠️ Erros clássicos de quem está migrando

❌ Ignorar Perspectives
❌ Não usar filtros
❌ Depender só de menu
❌ Não olhar Error Log
❌ Tentar usar como ISPF

---

🏆 Exemplo real (vida de produção)

Cenário:

👉 Programa travando em produção

No 3270:

• CEMT INQ TASK
• Análise manual

No Explorer:

• Tasks view
• Filtrar por status
• Ver CPU
• Identificar gargalo
• Newcopy com clique

💥 Resultado: diagnóstico MUITO mais rápido.

---

🚀 O futuro: CICS no mundo moderno

Com o IBM z17, o CICS está:

• Integrado com APIs
• Plugado em cloud
• Conectado via z/OS Connect
• Automatizado via DevOps

👉 E o CICS Explorer é a porta de entrada.

---

💎 Conclusão

Você não precisa abandonar o CEMT.

Mas precisa entender:

💥 Quem domina CICS Explorer trabalha melhor, mais rápido e com mais visibilidade.

---

🔥 Próximos passos

Se quiser evoluir de verdade:

👉 Aprenda:

• CICS Explorer + IDz
• z/OS Connect
• Zowe Explorer
• Debug moderno

Muito Além do IBM Z: A Anatomia Completa de um Datacenter Mainframe

 

Bellacosa Mainframe e a anatomia de um datacenter mainframe ibm z

☕ Um Café no Bellacosa Mainframe

Muito Além do IBM Z: A Anatomia Completa de um Datacenter Mainframe

O Guia Definitivo para um Programador COBOL Padawan Entender Como Cada Cabo, Tubo, Rack e Equipamento Trabalha em Harmonia para Manter Bancos, Cartões de Crédito e Bolsas de Valores Funcionando 24 Horas por Dia

"Um programa COBOL nunca executa sozinho. Antes que uma única instrução MOVE seja processada, existe um verdadeiro ecossistema de engenharia trabalhando silenciosamente para que tudo aconteça."

---

Introdução

Existe uma cena clássica em filmes de ficção científica: o herói entra em uma enorme sala repleta de luzes, armários metálicos, tubos coloridos, cabos grossos, ventiladores gigantes e quilômetros de equipamentos.

Para a maioria das pessoas aquilo parece apenas uma sala cheia de máquinas.

Para um programador COBOL experiente...

Aquilo é praticamente uma cidade.

A imagem que analisamos representa exatamente isso.

Embora seja uma renderização artística, ela retrata com bastante fidelidade como funciona a infraestrutura de um datacenter corporativo moderno onde vivem os grandes IBM Z.

Quando um programador COBOL escreve:

EXEC SQL
SELECT SALDO
FROM CONTA
END-EXEC

ele normalmente imagina apenas:

Programa → Banco de Dados

Mas, na realidade, essa simples consulta percorre dezenas de equipamentos.

Hoje faremos uma verdadeira visita guiada pelo coração de um datacenter IBM Mainframe.

Pegue seu café.

Vamos entrar.

---

Bellacosa Mainframe e um moderno cpd centro de processamento de dados

Vista Geral da Sala

Imagine que estamos entrando nesta sala.

A primeira impressão é de organização absoluta.

Nada está ali por acaso.

Cada tubo possui uma função.

Cada cabo tem identificação.

Cada rack possui redundância.

Cada equipamento conversa com dezenas de outros equipamentos.

É exatamente como um grande programa COBOL bem escrito.

Se retirar uma instrução importante...

todo o restante pode parar.

---

O Teto: Onde Começa a Engenharia

Muitos iniciantes olham apenas para os computadores.

Os veteranos olham primeiro para o teto.

Por quê?

Porque boa parte da infraestrutura passa justamente acima dos equipamentos.

Ali encontramos:

• barramentos elétricos

• fibra óptica

• tubulações

• sensores

• detectores de fumaça

• iluminação

• sistema anti-incêndio

• monitoramento ambiental

É praticamente um "JCL da infraestrutura".

---

Painéis de LED

Os painéis brancos não servem apenas para iluminar.

Eles possuem:

• baixo consumo

• pouca emissão de calor

• longa vida útil

• alimentação redundante

Em alguns datacenters críticos, até a iluminação possui dupla alimentação.

Se uma UPS falhar...

a sala continua iluminada.

---

As Grandes Bandejas Porta-Cabos

Observe aquelas estruturas metálicas horizontais.

Elas são chamadas de:

Cable Tray

ou

Cable Ladder.

Ali passam centenas de quilômetros de cabos.

Sim.

Quilômetros.

Em grandes bancos não é raro existir mais de 100 km de cabeamento.

Essas bandejas carregam:

• fibra óptica

• Ethernet

• alimentação

• gerenciamento

• SAN

• FICON

• cabos de sincronismo

Existe uma regra importante:

Energia nunca deve viajar junto com dados.

Isso reduz interferências eletromagnéticas.

---

Os Barramentos Elétricos (Busway)

Ao invés de milhares de cabos grossos...

utiliza-se um grande barramento.

Imagine uma avenida principal.

Dela saem pequenas ruas alimentando cada rack.

Subestação

↓

UPS

↓

Busway

↓

Tap Box

↓

Rack IBM Z

É uma solução muito mais segura.

---

Os Tubos Coloridos

Talvez sejam o detalhe mais interessante da imagem.

Eles fazem parte do sistema hidráulico do datacenter.

Sim.

Existe hidráulica dentro da sala.

E muita.

Os tubos podem transportar:

Água gelada

Água de retorno

Água industrial

Água para trocadores de calor

Circuitos secundários

Em um IBM z17, centenas de quilowatts de calor precisam ser removidos continuamente.

---

Easter Egg Bellacosa ☕

Todo iniciante acredita que um computador "esquenta um pouco".

Na realidade...

Um único IBM Z pode dissipar mais calor do que dezenas de aparelhos de ar-condicionado domésticos funcionando simultaneamente.

Por isso existe uma verdadeira usina de refrigeração.

---

Os Flexíveis Pretos

Cada conjunto preto descendo até os racks provavelmente representa conduítes.

Dentro deles passam:

• fibras ópticas

• alimentação redundante A

• alimentação redundante B

• cabos de gerenciamento

• sensores ambientais

Tudo separado.

Tudo identificado.

Tudo documentado.

---

Descidas Individuais

Nenhum rack recebe apenas um cabo.

Normalmente encontramos:

Energia A

Energia B

Fibra A

Fibra B

Rede administrativa

Rede de monitoramento

Aterramento

Tudo redundante.

---

O Piso Elevado

Embora não apareça na imagem...

quase certamente existe.

Imagine um piso falso com cerca de 60 centímetros.

Debaixo dele passam:

energia

fibras

água

aterramento

ar frio

É praticamente uma segunda cidade escondida.

---

Os Racks

Agora chegamos à parte mais visível.

Os gabinetes pretos.

Eles podem conter praticamente qualquer equipamento.

Em um datacenter IBM normalmente encontramos:

IBM z17

IBM z16

LinuxONE Emperor

Storage DS8900F

SAN Switch

OSA Express

Crypto Express

Open Systems Servers

Appliances

HMC

---

IBM z17

O protagonista.

Ali vivem:

CPs

zIIPs

zAAPs (histórico)

IFLs

SAPs

RAIM

Memória

Cache

Canal I/O

Processadores criptográficos

Tudo redundante.

---

Hardware Management Console (HMC)

Sem ela praticamente não existe IBM Z.

A HMC permite:

IPL

Shutdown

LPAR

Monitoramento

Capacity Planning

Firmware

Diagnóstico

É o painel de controle da nave espacial.

---

Storage IBM DS8900F

Ao lado do IBM Z quase sempre existe um storage.

Os dados não ficam "dentro" do mainframe.

Eles ficam aqui.

Dentro dele existem:

NVMe

Flash

Cache

RAID

Processadores próprios

Compressão

Deduplicação

Criptografia

---

SAN Directors

Eles são as grandes rotatórias do armazenamento.

Utilizam:

Fibre Channel

FICON

NVMe over FC

Conectam:

IBM Z

Storage

Backup

Tape

---

OSA Express

É a placa de rede do IBM Z.

Pode oferecer:

10 Gb

25 Gb

100 Gb

TCP/IP

IPv6

OSA-Express Integrated

---

Crypto Express

Pouca gente sabe...

O IBM Z possui placas dedicadas para criptografia.

Elas executam:

AES

RSA

ECC

SHA

TLS

PIN bancário

PIX

Open Banking

Tudo acelerado por hardware.

---

FICON

O COBOL acessa um arquivo VSAM.

O VSAM está no DS8900F.

Como chegam os dados?

Pelos canais FICON.

Eles substituíram os antigos ESCON.

São verdadeiras autoestradas ópticas.

---

Tape Library

Mesmo em 2026...

fitas continuam existindo.

IBM TS4500

TS7700

LTO

3592

Porque:

backup

retenção

compliance

baixo custo

---

UPS

Nenhum IBM Z fica ligado diretamente na concessionária.

Entre a rua e o computador existem:

UPS

Bancos de baterias

Inversores

Retificadores

Filtros

Transformadores

---

Geradores

Quando acaba a energia:

0 segundos

Baterias.

Poucos segundos depois:

Entram os geradores diesel.

O IBM Z nem percebe.

---

CRAH

Computer Room Air Handler.

Ele recebe água gelada.

Remove calor.

Empurra ar frio.

Tudo continuamente.

---

Chiller

Fica normalmente fora do prédio.

É o responsável por produzir água gelada.

Sem ele...

nenhum datacenter sobrevive.

---

Sensores

Espalhados pela sala existem centenas deles.

Temperatura

Umidade

Fumaça

Vibração

Água

Pressão

Energia

Fluxo de ar

Todos ligados ao BMS.

---

BMS

Building Management System.

É o "z/OS" do prédio.

Controla:

ar

energia

portas

alarmes

incêndio

temperatura

bombas

geradores

---

Sistema Anti-incêndio

Jamais utilize água.

Os sistemas modernos usam:

FM-200

Novec 1230

Inergen

Eles retiram o oxigênio suficiente para apagar o fogo sem danificar os equipamentos.

---

Detectores VESDA

Muito antes da fumaça aparecer...

eles detectam partículas microscópicas.

É um dos sistemas mais impressionantes de um datacenter.

---

Segurança Física

Cartão RFID

Biometria

Reconhecimento facial

Mantrap

CFTV

Guarda 24x7

Registro de acesso

Nada entra sem autorização.

---

O Caminho de um Simples Programa COBOL

Imagine que você executa:

JOB
 ↓
JES2
 ↓
z/OS
 ↓
COBOL
 ↓
Db2
 ↓
FICON
 ↓
SAN
 ↓
DS8900F
 ↓
SSD Flash
 ↓
Retorno

Tudo isso acontece em milissegundos.

Enquanto isso:

✔ CRAH remove calor

✔ UPS estabiliza energia

✔ Busway distribui alimentação

✔ Chiller produz água gelada

✔ HMC monitora processadores

✔ RMF coleta desempenho

✔ SMF registra estatísticas

✔ RACF protege acessos

✔ WLM prioriza cargas

✔ GDPS pode manter um site de contingência sincronizado

E o programador apenas vê:

DISPLAY "PROCESSAMENTO OK".

---

A Grande Lição para um Programador COBOL Padawan

Existe uma tendência natural entre iniciantes de acreditar que a programação começa e termina no editor de código. Porém, um sistema corporativo executado em um IBM Z depende de uma infraestrutura gigantesca: energia redundante, climatização de precisão, armazenamento de altíssimo desempenho, redes ópticas, segurança física, monitoramento ambiental e dezenas de componentes especializados trabalhando de forma sincronizada.

Compreender essa arquitetura transforma a maneira como enxergamos o desenvolvimento. Um SELECT no Db2, uma leitura em VSAM ou uma transação CICS percorrem uma cadeia sofisticada de hardware e software antes de retornar o resultado ao usuário.

Essa é uma das maiores lições do universo mainframe: programar bem significa entender o ecossistema completo. Quanto mais o programador COBOL conhece a infraestrutura que sustenta suas aplicações, mais preparado estará para escrever sistemas eficientes, diagnosticar problemas e dialogar com equipes de operações, redes, armazenamento e administração do z/OS.

No mundo IBM Mainframe, o código é apenas a ponta visível de um iceberg de engenharia construído para entregar disponibilidade, desempenho e confiabilidade ininterruptos. É essa combinação de software e infraestrutura que permite aos grandes bancos, seguradoras, companhias aéreas e bolsas de valores processarem milhões de transações por segundo, todos os dias, sem que a maioria das pessoas sequer perceba que um IBM Z está trabalhando silenciosamente nos bastidores.

Engenharia de Dados para um Programador COBOL Padawan

 

Bellacosa Mainframe e a engenharia de dados

☕ Um Café no Bellacosa Mainframe

Engenharia de Dados para um Programador COBOL Padawan

Você Não Está Mudando de Profissão. Está Descobrindo que Sempre Trabalhou com Dados.

"Toda geração acredita que inventou a Engenharia de Dados. Quem passou décadas desenvolvendo em COBOL sabe que mover, transformar, validar e proteger dados sempre foi o coração do Mainframe."

---

Se existe uma palavra que domina o mercado de tecnologia atualmente, ela é Dados.

Data Engineer.

Data Lake.

Data Warehouse.

Data Mesh.

Data Fabric.

Big Data.

Analytics.

Machine Learning.

Inteligência Artificial.

Para quem acompanha as vagas do LinkedIn, parece que surgiu uma profissão completamente nova.

Mas será que surgiu mesmo?

Se você é um Programador COBOL Padawan, talvez esteja olhando para esse universo pensando:

"Isso não é para mim."

Ou talvez pior.

"Vou precisar esquecer tudo o que aprendi nos últimos anos."

Nada poderia estar mais distante da realidade.

Na verdade, existe uma notícia excelente.

Boa parte da Engenharia de Dados nasceu exatamente nos ambientes onde o COBOL reina há mais de sessenta anos.

Hoje vamos tomar um café e descobrir por que um programador COBOL possui muito mais vantagens para aprender Engenharia de Dados do que imagina.

---

O maior equívoco sobre Engenharia de Dados

Quando alguém fala "Data Engineer", muitas pessoas imaginam imediatamente alguém escrevendo Python.

Outros imaginam Spark.

Outros imaginam nuvem.

Outros imaginam Inteligência Artificial.

Tudo isso faz parte da profissão.

Mas nada disso explica sua essência.

A verdadeira Engenharia de Dados pode ser resumida em uma única pergunta:

Como garantir que a informação certa chegue ao lugar certo, no momento certo, com qualidade e segurança?

Perceba.

Não estamos falando de linguagem.

Não estamos falando de banco de dados.

Não estamos falando de cloud.

Estamos falando de engenharia.

E engenharia sempre existiu.

---

O COBOL sempre foi uma linguagem de dados

Vamos imaginar um programa extremamente simples.

READ CLIENTE

IF STATUS = "A"

   COMPUTE LIMITE = SALARIO * 3

   WRITE CLIENTE-APROVADO

END-IF

O que esse programa faz?

Não desenha telas.

Não cria animações.

Não faz gráficos.

Ele faz algo muito mais importante.

Transforma dados.

Exatamente o trabalho de um pipeline moderno.

Hoje essa transformação poderia estar escrita em:

Python.

Spark.

SQL.

Scala.

Mas o conceito permanece exatamente o mesmo.

Entrada.

Transformação.

Saída.

---

Um pipeline moderno não é muito diferente de um Job Batch

Vamos comparar.

No Mainframe

Arquivo VSAM

↓

Programa COBOL

↓

SORT

↓

IDCAMS

↓

DB2

↓

Relatório

Agora veja um ambiente moderno.

API

↓

Python

↓

Spark

↓

Data Lake

↓

Data Warehouse

↓

Dashboard

Mudaram as ferramentas.

O fluxo continua praticamente idêntico.

Receber.

Transformar.

Validar.

Persistir.

Consumir.

É por isso que muitos profissionais de Mainframe aprendem Engenharia de Dados com enorme facilidade.

Eles já entendem o processo.

Só precisam aprender novos nomes.

---

Nível 1 — SQL e Linux

Toda jornada começa aqui.

Algumas pessoas desprezam SQL.

Grave isto.

Quem domina SQL domina dados.

SQL continua sendo a língua universal da informação.

Não importa se você usa:

Oracle

SQL Server

PostgreSQL

MySQL

Db2

Snowflake

BigQuery

Databricks

Spark SQL

Todos conversam através de SQL.

---

No Linux acontece algo parecido.

Quem trabalha com z/OS talvez ache curioso.

Mas muitos comandos Linux lembram bastante utilitários clássicos do Mainframe.

Por exemplo.

Localizar informações.

Linux

grep CPF clientes.txt

Mainframe

SORT INCLUDE

Contar registros.

Linux

wc -l arquivo.txt

Mainframe

ICETOOL COUNT.

Filtrar.

Ordenar.

Mesclar.

Tudo isso já fazia parte do universo Batch décadas antes do Big Data existir.

---

Nível 2 — Programação

Aqui normalmente aparece Python.

Mas poderia ser Java.

Scala.

Go.

Até mesmo COBOL.

Sim.

COBOL continua sendo usado em pipelines modernos.

Principalmente quando o dado nasce no Mainframe.

O objetivo agora não é consultar dados.

É automatizar processos.

Imagine.

Você precisa:

baixar arquivos

consumir APIs

descompactar

validar

gerar logs

carregar banco

enviar e-mail

Tudo isso exige programação.

Não importa a linguagem.

O importante é pensar em automação.

---

O primeiro choque: APIs

Muitos programadores COBOL perguntam:

"O que é uma API?"

A resposta mais simples é:

Uma API é um programa conversando com outro programa.

Só isso.

Você já fazia isso.

CICS fazia isso.

MQ fazia isso.

IMS fazia isso.

A diferença é que hoje a conversa normalmente acontece usando:

HTTP

JSON

REST

GraphQL

gRPC

O conceito continua exatamente igual.

---

Nível 3 — Spark

Aqui começa a diversão.

Imagine que seu programa COBOL processa:

5 milhões de registros.

Funciona muito bem.

Agora imagine:

5 bilhões.

Não existe CPU suficiente.

Surge então o processamento distribuído.

Em vez de uma máquina.

Cem máquinas.

Ou mil.

Cada uma processando uma pequena parte.

Esse é o Spark.

Ele divide o problema.

Depois reúne os resultados.

É como um enorme SORT distribuído.

---

Spark não substitui SQL

Esse é outro mito.

Na prática.

Boa parte do Spark moderno utiliza SQL.

Ou Spark SQL.

Ou DataFrames.

Ou seja.

O conhecimento adquirido anteriormente continua sendo utilizado.

Nada é perdido.

Tudo evolui.

---

Nível 4 — Cloud

Aqui muita gente se assusta.

Parece outro universo.

Na verdade, não é.

Cloud é apenas um novo datacenter.

Só que alugado.

Imagine um CPD gigantesco.

Você liga um servidor.

Usa.

Desliga.

Paga apenas pelo tempo utilizado.

É isso.

Claro.

Existem centenas de serviços.

Mas a ideia continua simples.

Infraestrutura sob demanda.

---

O que muda para o Engenheiro de Dados?

Antes.

Você tinha um servidor.

Agora possui dezenas.

Centenas.

Tudo automatizado.

Surge então uma nova preocupação.

Escalabilidade.

Monitoramento.

Custos.

Segurança.

---

Nível 5 — Inteligência Artificial

Chegamos ao assunto da moda.

Todo mundo quer trabalhar com IA.

Mas poucos entendem uma verdade simples.

A IA depende completamente da Engenharia de Dados.

Imagine um modelo treinado com:

CPFs inválidos.

Datas erradas.

Valores duplicados.

Clientes repetidos.

O resultado será desastroso.

Existe uma frase muito antiga.

Garbage In.

Garbage Out.

Entrou lixo.

Sai lixo.

---

Por isso.

Antes da Inteligência Artificial.

Existe um profissional invisível.

O Engenheiro de Dados.

Ele garante que os dados sejam:

limpos

organizados

consistentes

históricos

auditáveis

confiáveis

Sem isso.

Nenhum ChatGPT.

Nenhum Copilot.

Nenhum modelo funciona adequadamente.

---

Mas existe algo ainda mais importante...

A imagem que inspirou este artigo mostra uma sequência de tecnologias.

Ela está correta.

Mas incompleta.

Porque existem conhecimentos que nunca saem de moda.

---

Modelagem de Dados

Se existe um superpoder do programador COBOL, é este.

Quem desenvolveu sistemas bancários conhece:

Cliente.

Conta.

Agência.

Contrato.

Movimentação.

Parcela.

Histórico.

Relacionamentos.

Tudo isso é modelagem.

Sem um bom modelo.

Nem Spark salva.

Nem IA resolve.

Nem Cloud ajuda.

---

Qualidade dos Dados

Imagine um cadastro onde o mesmo cliente aparece quinze vezes.

Ou um saldo negativo impossível.

Ou datas inexistentes.

Quem resolve?

Não é a IA.

É engenharia.

Validação.

Regras.

Auditoria.

Consistência.

Exatamente como fazemos há décadas em sistemas críticos.

---

Observabilidade

No Mainframe existe SDSF.

SMF.

RMF.

Logs.

Mensagens JES.

Abends.

Tudo isso existe para observar o ambiente.

Hoje fazemos exatamente a mesma coisa.

Só mudaram as ferramentas.

Monitoramos:

pipelines

latência

falhas

volumes

distribuição

anomalias

A filosofia continua igual.

Nunca confiar.

Sempre medir.

---

Governança

Poucos assuntos cresceram tanto.

Hoje toda empresa pergunta:

Quem alterou esse dado?

Quem acessou?

Quem apagou?

Quando?

Por quê?

No Mainframe isso sempre foi levado muito a sério.

RACF.

Auditoria.

Perfis.

Permissões.

Hoje apenas ampliamos esse conceito.

---

Versionamento

Você conhece Endevor?

ISPW?

ChangeMan?

Parabéns.

Você já trabalhou com gestão de versões antes mesmo do Git existir.

Hoje usamos GitHub.

GitLab.

Bitbucket.

Mas o princípio permanece.

Nunca alterar produção diretamente.

Sempre controlar mudanças.

---

DataOps

Assim como surgiu DevOps.

Hoje existe DataOps.

Automatizar testes.

Validar qualidade.

Executar pipelines.

Fazer deploy.

Documentar.

Monitorar.

Tudo automaticamente.

Isso reduz erros humanos.

Aumenta confiabilidade.

E acelera entregas.

---

O conhecimento mais importante continua sendo o negócio

Imagine dois profissionais.

O primeiro conhece:

Spark.

Kafka.

Snowflake.

Airflow.

Terraform.

Kubernetes.

Python.

Databricks.

O segundo conhece apenas SQL.

Mas entende perfeitamente:

crédito

seguros

contabilidade

tributação

previdência

Qual deles gera mais valor?

Na maioria das empresas.

O segundo.

Porque tecnologia resolve problemas.

Mas somente quem entende o negócio consegue resolver o problema correto.

---

O programador COBOL já possui metade da jornada concluída

Esse talvez seja o maior segredo da Engenharia de Dados.

Profissionais de Mainframe normalmente já dominam:

✔ Processamento Batch

✔ Integridade transacional

✔ Bancos relacionais

✔ Modelagem

✔ Performance

✔ Grandes volumes

✔ Segurança

✔ Auditoria

✔ Sistemas críticos

✔ Dados corporativos

O que falta aprender?

As ferramentas modernas.

E ferramentas podem ser aprendidas.

Princípios levam anos para serem construídos.

---

A verdadeira evolução

Muitos imaginam a carreira assim.

COBOL

↓

Python

↓

Spark

↓

Cloud

↓

IA

Na realidade.

Ela é muito mais parecida com isto.

                 Negócio
                     │
      ┌──────────────┼──────────────┐
      │              │              │
 Modelagem     Engenharia      Arquitetura
      │              │              │
      ├──────────────┼──────────────┤
      │              │              │
    SQL         Programação      Segurança
      │              │              │
      ├──────────────┼──────────────┤
      │              │              │
 Spark        Cloud         Observabilidade
      │              │              │
      └──────────────┼──────────────┘
                     │
                 DataOps
                     │
               Inteligência Artificial

Observe que a IA aparece quase no final.

Isso não é coincidência.

Ela depende de tudo o que veio antes.

---

Um café antes de voltar ao código...

Existe uma frase muito comum nas redes sociais:

"Aprenda IA."

Eu faria uma pequena correção.

Aprenda Engenharia.

Porque tecnologias mudam.

Spark um dia será substituído.

Novos bancos aparecerão.

Novas linguagens surgirão.

Novos frameworks nascerão.

Assim como Clipper deu lugar a outras soluções, e como muitas ferramentas de ETL evoluíram ao longo das décadas, o ecossistema continuará mudando.

Mas alguns princípios permanecem praticamente imutáveis desde os primeiros sistemas corporativos:

• Dados precisam ser confiáveis.

• Processos precisam ser previsíveis.

• Sistemas precisam ser auditáveis.

• Arquiteturas precisam ser sustentáveis.

• Segurança nunca é opcional.

• O negócio deve orientar a tecnologia, e não o contrário.

É exatamente por isso que um Programador COBOL não está começando do zero ao olhar para a Engenharia de Dados. Pelo contrário: ele já carrega uma bagagem construída em ambientes onde disponibilidade, consistência e integridade sempre foram requisitos inegociáveis.

No fim das contas, a maior transformação não é aprender Python, Spark ou Cloud. É perceber que o trabalho sempre foi o mesmo: transformar dados em informação confiável para apoiar decisões.

As ferramentas evoluem.

Os nomes mudam.

As interfaces ficam mais modernas.

Mas a boa engenharia continua sendo reconhecida pelos mesmos atributos de décadas atrás: simplicidade, clareza, desempenho, confiabilidade e foco no problema de negócio.

Então, Padawan, da próxima vez que ouvir alguém dizer que Engenharia de Dados é "uma profissão completamente nova", sorria, tome mais um gole do seu café e lembre-se: os mainframes já movimentavam bilhões de registros por dia quando muitos dos conceitos modernos ainda nem tinham nome.

Bellacosa Mainframe e as redes neurais

 

☕🔥 REDES NEURAIS EXPLICADAS PARA UM COBOLISTA SÊNIOR — “O DIA EM QUE O PROGRAMA COMEÇOU A APRENDER SOZINHO” 🔥💾

Programador COBOL experiente normalmente pensa assim:

“Programa é regra.”
“Entrada → PROCESSAMENTO → Saída.”
“Se deu erro, existe uma condição mal tratada.”
“Toda lógica precisa ser explícita.”

E é exatamente aí que acontece o choque quando alguém vê IA moderna pela primeira vez.

Porque numa rede neural…

O programador NÃO escreve a regra final.

Ele escreve o mecanismo de aprendizado.

E isso muda absolutamente tudo.

---

☕ O QUE É UMA REDE NEURAL?

Pense assim…

No COBOL clássico você faz:

IF SALDO > 1000
   MOVE "CLIENTE VIP" TO STATUS
END-IF

Você define a regra.

Já numa rede neural você mostra milhares de exemplos:

Cliente A -> VIP
Cliente B -> NORMAL
Cliente C -> VIP

A rede começa a “descobrir” padrões matemáticos sozinha.

Ela aprende probabilidades internas.

---

☕ A ORIGEM DAS REDES NEURAIS

A ideia nasceu tentando imitar o cérebro humano.

Lá nos anos 1940 começaram os estudos:

• neurônio artificial
• conexões
• pesos
• aprendizado

Mas faltava poder computacional.

Durante décadas isso ficou quase “acadêmico”.

A explosão veio quando apareceram:

• GPUs
• Big Data
• Cloud
• processamento paralelo
• datasets gigantescos

Ou seja…

A IA moderna nasceu quando o hardware finalmente conseguiu executar aquilo que a teoria queria desde os anos 50.

---

☕ O QUE É UM “NEURÔNIO” NA PRÁTICA?

Imagine um mini-programa matemático.

Ele recebe entradas:

idade
salário
tempo_empresa

Faz contas internas:

entrada × peso

Soma tudo.

Depois passa numa “função de ativação”.

Resultado:

0.98 = quase certeza
0.02 = improvável

---

☕ VISÃO MAINFRAME DA REDE NEURAL

Pense numa cadeia de SORT + IFs + cálculos + estatística.

Mas onde:

• as regras mudam sozinhas
• os pesos se ajustam
• os parâmetros são recalculados automaticamente

Isso é o ponto mais importante.

---

☕ COMO UMA REDE APRENDE?

Aqui entra o “treinamento”.

Exemplo:

Você quer detectar fraude bancária.

Você alimenta:

Transação -> Fraude
Transação -> Normal

Milhões de vezes.

A rede:

1. tenta prever
2. erra
3. mede o erro
4. ajusta pesos
5. tenta novamente

Isso se repete milhares de vezes.

---

☕ ISSO É O “LOOP DE APRENDIZADO”

Na cabeça do cobolista:

PERFORM UNTIL ERRO < LIMITE
    CALCULA
    AJUSTA-PESOS
END-PERFORM

A essência é essa.

---

☕ O QUE SÃO OS “PESOS”?

Os pesos são a “importância” das entradas.

Exemplo:

idade = peso 0.2
salário = peso 0.8

A rede aprende quais fatores importam mais.

---

☕ O QUE É BACKPROPAGATION?

Aqui mora a “mágica”.

A rede calcula o erro:

Esperado: 1
Obtido: 0.34

Depois ela volta ajustando os pesos internos.

É quase um:

ROLLBACK MATEMÁTICO

corrigindo tudo camada por camada.

---

☕ ESTRUTURA DE UMA REDE

Entrada

Dados chegam.

Camadas ocultas

Processamento matemático.

Saída

Resultado final.

Exemplo:

[ENTRADA]
idade
salário
histórico

↓

[CAMADAS]

↓

[SAÍDA]
fraude = 98%

---

☕ TIPOS DE REDES

Perceptron

A mais simples.

MLP

Rede multicamadas clássica.

CNN

Muito usada para imagens.

RNN

Sequências e texto.

Transformers

A arquitetura usada no ChatGPT.

---

☕ QUAL A LINGUAGEM MAIS USADA?

Hoje:

Python domina completamente.

Porque possui bibliotecas absurdamente prontas.

---

☕ PRINCIPAIS FRAMEWORKS

TensorFlow

Google.

PyTorch

Meta/Facebook.

Hoje PyTorch domina pesquisa e IA generativa.

---

☕ EXEMPLO SIMPLES EM PYTHON

from sklearn.neural_network import MLPClassifier

X = [[0,0], [0,1], [1,0], [1,1]]
y = [0,1,1,0]

rede = MLPClassifier(hidden_layer_sizes=(4,))
rede.fit(X, y)

print(rede.predict([[1,0]]))

Aqui ela aprende XOR.

Coisa que lógica linear simples não resolve.

---

☕ ANALOGIA MAINFRAME PERFEITA

Treinar uma rede neural é parecido com:

Rodar milhões de jobs batch

onde cada execução ajusta parâmetros internos até encontrar a melhor precisão estatística.

Só que tudo isso ocorre automaticamente.

---

☕ O QUE VOCÊ PRECISA APRENDER?

🔥 FASE 1 — BASE MATEMÁTICA

O maior erro dos iniciantes:

querer aprender IA sem matemática.

Você precisa:

Álgebra linear

• vetores
• matrizes

Estatística

• média
• variância
• probabilidade

Cálculo

• derivadas
• gradientes

---

☕ PARA COBOLISTAS: A VERDADE DURA

A maior dificuldade NÃO é programação.

É matemática.

Programar IA é relativamente simples hoje.

Entender o que está acontecendo é outra história.

---

☕ FASE 2 — PYTHON

Aprender:

• variáveis
• listas
• loops
• funções
• classes
• pandas
• numpy

Para um programador COBOL experiente:

Python é fácil.

O choque é a sintaxe minimalista.

---

☕ FASE 3 — MACHINE LEARNING

Aprender:

• treino
• validação
• overfitting
• underfitting
• loss
• acurácia

---

☕ O QUE É OVERFITTING?

A rede “decorou”.

Ela não aprendeu.

Isso é clássico.

Ela vai perfeita nos dados antigos…
e horrível nos novos.

---

☕ TESTES EM IA

Aqui muda tudo comparado ao COBOL.

No COBOL:

resultado certo ou errado

Na IA:

probabilidade

Você mede:

• precisão
• recall
• F1-score
• taxa de erro

---

☕ COMO CRIAR SUA PRIMEIRA REDE

PASSO 1

Instale Python.

---

PASSO 2

Instale bibliotecas.

pip install tensorflow

ou

pip install torch

---

PASSO 3

Pegue um dataset simples.

Exemplo:

• fraude
• spam
• imagens
• clientes

---

PASSO 4

Divida:

TREINO
TESTE

---

PASSO 5

Treine.

modelo.fit()

---

PASSO 6

Teste.

modelo.predict()

---

☕ ONDE UM COBOLISTA TEM VANTAGEM?

Muita vantagem.

Porque veteranos de mainframe entendem:

• processamento massivo
• batch
• performance
• consistência
• lógica de negócio
• dados corporativos

E IA corporativa depende MUITO disso.

---

☕ O ERRO DOS “AI GURUS DE INTERNET”

Muitos sabem:

• chamar API
• usar prompt

Mas não entendem:

• arquitetura
• dados
• processamento
• governança
• sistemas corporativos

E aí o profissional mainframe entra forte.

---

☕ COMO MAINFRAME E IA ESTÃO SE UNINDO?

Hoje já existe:

• IA em z/OS
• inferência em LinuxONE
• integração COBOL + APIs IA
• Watsonx
• z15 com aceleração IA

O mundo corporativo está conectando:

COBOL + IA

não substituindo.

---

☕ ROTEIRO REALISTA PARA COMEÇAR

Mês 1

Python básico.

Mês 2

Numpy + pandas.

Mês 3

Machine Learning clássico.

Mês 4

Primeira rede neural.

Mês 5

Deep Learning.

Mês 6

Projetos reais.

---

☕ MELHOR FORMA DE APRENDER

NÃO comece pelo ChatGPT.

Comece entendendo:

• regressão
• classificação
• estatística
• datasets

Depois redes neurais.

Depois IA generativa.

---

☕ FRASE QUE TODO COBOLISTA PRECISA OUVIR

“Rede neural não pensa.”

Ela ajusta pesos matemáticos tentando minimizar erro estatístico.

Isso muda completamente a forma de enxergar IA.

---

☕ O FUTURO DO PROFISSIONAL COBOL

O profissional COBOL que aprender IA terá um diferencial monstruoso.

Porque ele conhece:

• o dado corporativo REAL
• a regra bancária REAL
• a transação REAL
• o legado REAL

E é justamente isso que falta para muita IA moderna.

---

☕ RESUMO FINAL — VISÃO BELLACOSA MAINFRAME

Rede neural é:

Um gigantesco mecanismo matemático
de ajuste automático de parâmetros
baseado em erro estatístico.

Ou traduzindo para o dialeto do mainframe:

“É um batch matemático que reexecuta bilhões de vezes ajustando campos internos até reduzir o ABEND estatístico da previsão.” ☕💾🔥