☕ Um Café no Bellacosa Mainframe
Gostou do conteúdo? Ajude a manter o café quente, o COBOL compilando e o mainframe acordado. 😄
☕ Pague um café ao Bellacosa

Translate

quarta-feira, 9 de setembro de 2026

🕵️‍♂️ O Supermosaico — Segurança da Informação sob a Tutela do Dr. Moriarty

 

Bellacosa Mainframe e o mosaico da segurança os riscos ocultos na ia

☕ Um Café no Bellacosa Mainframe

🕵️‍♂️ O Supermosaico — Segurança da Informação sob a Tutela do Dr. Moriarty

Quando nossos prompts começaram a guardar aquilo que nossa memória deveria esquecer

Imagine uma grande empresa.

Na porta existem seguranças.

Nos computadores, EDR.

Na rede, firewalls.

Nos acessos, MFA.

No mainframe, RACF.

Nos datasets, permissões.

Nos repositórios, controles.

Nos notebooks, DLP.

Nos servidores, logs.

No SOC, dezenas de telas piscando.

Tudo parece protegido.

Então o Dr. Moriarty entra em nossa sala, observa silenciosamente durante alguns minutos e faz uma pergunta desagradavelmente simples:

“Muito interessante. Mas onde seus funcionários conversam quando precisam pensar?”

Silêncio.

Bem-vindo à segurança da informação na era da Inteligência Artificial.



☕ Sob a tutela do Dr. Moriarty

Nossa história começou com uma questão aparentemente simples: profissionais utilizando Inteligência Artificial generativa para trabalhar.

Um advogado coloca partes de um processo em um prompt.

Um programador pergunta sobre um erro COBOL.

Um analista cola algumas mensagens de um dump.

Um DBA tenta entender determinada query.

Um especialista CICS pergunta sobre uma transação problemática.

Um consultor solicita ajuda para documentar uma arquitetura.

Nada disso precisa nascer de má-fé.



Pelo contrário.

O objetivo normalmente é trabalhar melhor.

Esse é justamente o ponto inquietante.

O artigo que motivou esta reflexão chama atenção para o fato de que informações de terceiros podem ser transferidas para sistemas externos durante o uso aparentemente cotidiano de IA e utiliza como exemplo conhecido os incidentes de 2023 envolvendo funcionários da Samsung e informações corporativas inseridas no ChatGPT.

A discussão original concentra-se principalmente em advocacia, sigilo profissional, proteção de dados e governança.

Mas vamos colocar nossa xícara de café sobre a mesa e levar o problema para dentro de uma instalação mainframe.

Moriarty está esperando.



🧩 A primeira tessela

Imagine um jovem programador COBOL.

Ele recebe:

ABEND S0C7

Abre sua ferramenta favorita de IA e pergunta:

Tenho um programa COBOL apresentando S0C7.

O erro acontece nesta rotina.

Pode me ajudar?

Perfeitamente razoável.

A IA pede contexto.

Nosso programador fornece algumas linhas.

Depois mais algumas.

Aparece o nome de um programa.

Depois uma tabela.

Uma transação.

Uma mensagem CICS.

Nada parece particularmente importante.

Temos nossa primeira tessela.

Uma pequena pedra quadrangular daqueles magníficos mosaicos romanos.

Sozinha, ela significa quase nada.



🏛️ O mosaico romano

Na semana seguinte:

TRANID = ABC1

Outra tessela.

Meses depois:

PROGRAM = PAY001

Outra.

Mais tarde:

PAY001 atualiza DB2 antes do MQPUT.

Outra.

Em dezembro:

A fila PAYMENT.REQUEST cresce
durante o fechamento mensal.

Outra.

No ano seguinte:

ABC1 chama PAY001.

Agora coloque as pedras juntas:

ABC1
 │
 ▼
PAY001
 │
 ├────► DB2
 │
 ▼
MQPUT
 │
 ▼
PAYMENT.REQUEST

Curioso.

Nenhum prompt individual descreveu necessariamente toda a arquitetura.

Mas a arquitetura começa a aparecer pela correlação.

Essa é nossa primeira grande lição sob a tutela de Moriarty:

Informações aparentemente insignificantes podem adquirir enorme valor quando possuem relacionamentos.


🧠 O analista começa a documentar a empresa sem perceber

Passemos três anos.

Nosso programador virou analista.

Ele utilizou IA milhares de vezes.

Perguntou sobre:

  • COBOL;

  • JCL;

  • CICS;

  • Db2;

  • MQ;

  • VSAM;

  • RACF;

  • APIs;

  • incidentes;

  • dumps;

  • arquitetura;

  • regras de negócio;

  • migrações;

  • problemas de produção.

Mas existe uma característica interessante.

Normalmente perguntamos à IA justamente sobre aquilo que não entendemos.

Consequentemente, nosso histórico pode acabar concentrando momentos excepcionais:

ERRO
 ↓
DÚVIDA
 ↓
PROMPT

INCIDENTE
 ↓
DÚVIDA
 ↓
PROMPT

ARQUITETURA ESTRANHA
 ↓
DÚVIDA
 ↓
PROMPT

EXCEÇÃO DE NEGÓCIO
 ↓
DÚVIDA
 ↓
PROMPT

O histórico não é necessariamente uma amostra aleatória do ambiente.

Pode ser uma coleção justamente das coisas estranhas, difíceis ou importantes.

Quase um diário operacional involuntário.


📖 “Querido diário, produção caiu novamente...”

Imagine encontrar uma conversa antiga:

“Por que essa rotina precisa executar antes das 22 horas?”

Outra:

“Por que não podemos alterar esse campo?”

Outra:

“Esse programa existe desde a aquisição da empresa XPTO.”

Outra:

“Quando o sistema secundário está indisponível usamos esta contingência.”

Perceba que estamos gradualmente deixando de falar somente de código.

Estamos falando de:

contexto.

E contexto frequentemente vale mais do que código.

Um programa COBOL pode dizer:

IF WS-STATUS = '99'
    PERFORM 9000-CONTINGENCIA
END-IF.

Mas talvez não explique por que 99 existe.

O veterano explica:

“Isso foi criado depois daquele problema de 2008 porque o sistema externo ficava indisponível no fechamento.”

Pronto.

Temos história.

Temos arquitetura.

Temos dependência.

Temos regra operacional.

Temos conhecimento institucional.


🧓 O veterano pode ser mais interessante que o administrador

Aqui Moriarty levanta a sobrancelha.

Tradicionalmente pensamos:

“Quem possui maior privilégio?”

Administrador.

RACF SPECIAL.

DBA.

SYSADM.

ROOT.

Mas existe outra espécie de privilégio:

Knowledge Privilege.

Talvez aquele veterano não possua RACF SPECIAL.

Entretanto ele sabe:

por que X depende de Y;

quem resolve determinado incidente;

qual sistema não pode parar;

qual processo possui contingência;

quais componentes são antigos;

onde existem dependências históricas;

por que determinada decisão foi tomada;

quais problemas aparecem no fechamento.

O usuário privilegiado possui Access Privilege.

O veterano possui Knowledge Privilege.

Em alguns cenários de ameaça, precisamos proteger ambos.


🕰️ Janeiro de 2023

Agora chegamos a uma coisa extraordinária.

O ser humano esquece.

Imagine que nosso especialista tenha resolvido um incidente em janeiro de 2023.

Em setembro de 2026 alguém pergunta:

“Você lembra daquele problema?”

Provavelmente:

“Mais ou menos...”

Depois:

“Não lembro exatamente.”

Isso sempre foi uma espécie de deterioração natural da informação.

Mas imagine que naquele janeiro ele tenha escrito uma longa conversa com uma IA.

Dependendo do serviço, das configurações e das políticas de retenção, aquela conversa poderá ter permanecido armazenada.

Então temos:

MEMÓRIA HUMANA

evento
  ↓
tempo
  ↓
degradação
  ↓
abstração
  ↓
esquecimento

contra:

REGISTRO DIGITAL

evento
  ↓
texto
  ↓
armazenamento
  ↓
pesquisa
  ↓
recuperação

Aquilo que o cérebro deveria esquecer pode permanecer registrado.

Chamemos isso de:

Knowledge Residue

Resíduo de conhecimento.


🚪 O funcionário desligado

Agora Moriarty apresenta outro personagem.

Durante três anos nosso funcionário trabalhou normalmente.

Não roubou nada.

Não planejou fraude.

Não tentou prejudicar ninguém.

Então foi demitido.

Ficou ressentido.

No modelo tradicional de insider threat, talvez esperássemos observar:

download enorme;
cópia para USB;
upload suspeito;
e-mail externo;
ZIP com sources;
impressões anormais.

Mas surge uma possibilidade diferente.

E se informações inadequadamente compartilhadas já estivessem acumuladas em ambientes externos antes de aparecer a intenção maliciosa?

O problema fundamental torna-se:

o momento da aquisição da informação pode estar separado por anos do momento em que aparece a intenção de abusar dela.

No desligamento fazemos:

REVOKE RACF
REMOVE VPN
DISABLE EMAIL
DISABLE GITHUB
RETURN NOTEBOOK
RETURN BADGE
REVOKE CERTIFICATES

Excelente.

Mas Moriarty pergunta:

“E a memória digital externalizada anteriormente?”

É uma pergunta de governança, não uma justificativa para investigar indiscriminadamente contas pessoais de ex-funcionários.

A resposta precisa começar antes, com ferramentas corporativas apropriadas, separação de identidades, classificação, políticas de retenção e regras claras sobre aquilo que pode ser fornecido a sistemas de IA.


🎒 Chega o consultor

Moriarty sorri.

O funcionário conhece uma empresa.

O consultor conhece muitas.

Imagine:

2023 → Banco A
2024 → Seguradora B
2024 → Varejista C
2025 → Governo D
2025 → Montadora E
2026 → Banco F

Em cada organização ele aprende.

Essa transferência de experiência é perfeitamente normal.

Aliás, contratamos consultores justamente porque podem dizer:

“Já encontrei um problema semelhante.”

Existe, entretanto, diferença enorme entre carregar experiência profissional e carregar artefatos detalhados de conhecimento de clientes anteriores.

Historicamente, o cérebro fornecia uma abstração interessante:

experiência específica
       ↓
      tempo
       ↓
   esquecimento
       ↓
   abstração
       ↓
 conhecimento geral

O consultor esquecia nomes, valores, incidentes e detalhes.

Mas permanecia sabendo:

“Esse tipo de arquitetura costuma apresentar este problema.”

Excelente.

Isso é experiência.

Agora imaginemos uma conta pessoal ou ambiente inadequadamente segregado contendo conversas detalhadas provenientes de sucessivos projetos.

Temos potencialmente:

CLIENTE A ─┐
CLIENTE B ─┤
CLIENTE C ─┤
CLIENTE D ─┼──► CORPUS
CLIENTE E ─┤
CLIENTE F ─┘

Nasce nosso:

SUPERMOSAICO.


🌎 O Supermosaico

O mosaico permite reconstruir aspectos de uma empresa.

O Supermosaico acrescenta algo diferente:

comparação.

Cliente A faz X.

Cliente B utiliza X + Y.

Cliente C abandonou X depois de determinado problema.

Cliente D acrescentou Z.

Nenhuma dessas informações isoladamente precisa declarar:

“A possui uma deficiência.”

Mas a comparação pode produzir uma hipótese:

“Por que A aparentemente não possui Y ou Z?”

Nasceu informação que não estava explicitamente escrita.

Temos:

INFORMAÇÃO A
+
INFORMAÇÃO B
+
INFORMAÇÃO C
+
CONTEXTO
+
CORRELAÇÃO
=
INFORMAÇÃO DERIVADA

Esse é um dos pontos mais importantes desta história.

Precisamos proteger não somente informações sensíveis individualmente, mas pensar também em informações correlacionáveis.


🕵️ Moriarty finalmente começa sua aula

Até aqui Moriarty permaneceu sentado.

Agora ele se levanta.

Ele não pergunta:

“Onde está SECRET.DOC?”

Pergunta:

“O que posso inferir?”

Essa é uma mudança monumental.

O invasor caricatural procura:

PASSWORD.TXT

Moriarty procura:

relações;
padrões;
cronologia;
contradições;
dependências;
mudanças;
exceções;
incertezas.

Porque informação de inteligência não precisa estar escrita diretamente.

Ela pode surgir da combinação.


📧 Gmail, Drive, GitHub, WhatsApp, Telegram, celular...

Nossa identidade digital moderna está espalhada.

Temos:

e-mail pessoal
e-mail corporativo
GitHub
Google Drive
OneDrive
celular
notebook
micro pessoal
WhatsApp
Telegram
calendário
redes sociais
conta de IA

Antigamente imaginávamos segurança como uma muralha:

        FIREWALL
████████████████████████
       EMPRESA

Hoje precisamos imaginá-la como um grafo:

          PESSOA
        /   |    \
       /    |     \
   Gmail  GitHub  IA
     |      |      |
   Drive   código contexto
     \      |      /
       \    |     /
         CELULAR
            |
        IDENTIDADE
            |
         EMPRESA

Moriarty não precisa necessariamente perguntar:

“Como atravesso a muralha?”

Ele pode perguntar:

“Quais relações chegam até ela?”

Essa é uma excelente maneira defensiva de fazer threat modeling.


🏰 Primeiro o sentinela

Imagine um castelo.

Atacar diretamente o rei é difícil.

Então nosso Moriarty hipotético observa:

SENTINELA
    ↓
CAPITÃO
    ↓
OFICIAL
    ↓
CONSELHEIRO
    ↓
CASTELO

No mundo corporativo:

JÚNIOR
  ↓
N2
  ↓
N3
  ↓
SME
  ↓
ARQUITETO

Isso não significa que essa sequência permita comprometimento automático.

Não permite.

Mas mostra algo importante:

confiança também possui topologia.

Um funcionário confia em outro.

Uma identidade possui recuperação ligada a outra.

Um dispositivo possui sessões.

Um serviço contém referências a outros serviços.

Um calendário revela relacionamentos.

Um repositório revela tecnologias.

Precisamos analisar o blast radius de identidades, não somente permissões técnicas.


🔐 RACF emocional

Aqui nosso jovem COBOL finalmente entende Moriarty.

No RACF temos algo parecido com:

USER
 ↓
GROUP
 ↓
CONNECT
 ↓
PERMIT
 ↓
RESOURCE

Uma identidade isolada diz pouco.

Os relacionamentos dizem muito.

Agora aplique a mesma ideia à pessoa:

PESSOA
 ↓
IDENTIDADES
 ↓
DISPOSITIVOS
 ↓
SERVIÇOS
 ↓
SESSÕES
 ↓
DADOS
 ↓
RELACIONAMENTOS
 ↓
CONFIANÇA

Voilà!

Temos uma espécie de:

RACF da vida digital.

Só que muito menos organizado.


📦 Contrabando de conhecimento

Agora chegamos a outro conceito surgido durante nossa investigação.

Empresas procuram eventos grandes:

40 MB enviados por e-mail → ALERTA

ZIP com sources → ALERTA

USB → ALERTA

FTP → ALERTA

GitHub público → ALERTA

Enquanto isso:

prompt 001 → 2 KB
prompt 002 → 4 KB
prompt 003 → 1 KB
...
prompt 847 → 6 KB

Tudo pequeno.

Tudo aparentemente cotidiano.

Mas estamos confundindo:

volume físico

com

volume semântico.

Um especialista pode condensar vinte anos de experiência em três parágrafos.

Talvez sejam apenas 5 KB.

Semanticamente podem valer muito.

Por isso “contrabando de conhecimento” é uma excelente metáfora, embora em governança eu preferisse termos como:

transferência de conhecimento não governada

ou

canal cumulativo de exposição de conhecimento.

Porque nem todo prompt constitui exfiltração e nem todo usuário possui intenção indevida.


🛡️ DLP talvez não seja suficiente

Data Loss Prevention tradicionalmente pergunta:

“Que dado está saindo?”

Nosso problema exige outra pergunta:

“Que conhecimento está sendo construído pela soma daquilo que está saindo?”

Daí surge:

KLP — Knowledge Loss Prevention

Não estou propondo aqui um padrão formal universal chamado KLP.

Estou usando o termo como conceito para ampliar nossa maneira de pensar.

DLP:

PROTEJA O DADO

KLP:

PROTEJA:
dados
+
contexto
+
relações
+
acumulação
+
tempo
+
conhecimento derivável

Porque:

PROMPT 1 = VERDE
PROMPT 2 = VERDE
PROMPT 3 = VERDE

...

Σ PROMPTS = VERMELHO

O risco pode emergir da soma.


🐒 Um milhão de chimpanzés bebedores de saquê

É claro que nenhum tratado Bellacosa Mainframe estaria completo sem nossos agentes especiais.

Imagine um corpus contendo:

"Meu CICS conversa telepaticamente com Saturno."

"Verificar MQ amanhã."

"O gato assumiu RACF SPECIAL."

"Por que PAY001 apresenta S0C7?"

"Napoleão teria usado VSAM."

"Não esquecer daquele JOB."

"Um milhão de chimpanzés bebendo saquê
administram produção."

Um investigador humano provavelmente pediria transferência de departamento.

Mas não devemos considerar volume e ruído controles de segurança confiáveis.

Sistemas automatizados conseguem classificar conteúdo, encontrar recorrências e separar grandes quantidades de informação muito mais rapidamente que uma pessoa.

Além disso, existe uma vítima colateral.

Você.

Três anos depois abre a conversa e pergunta:

“Que porra eu quis dizer com isso?”

😂

A contrainteligência funcionou tão bem que derrotou o próprio autor.


🧠 Facebook, dados comportamentais e Moriarty

Agora ampliemos novamente a escala.

Redes sociais mostraram ao mundo o valor da correlação de enormes quantidades de dados comportamentais.

IA conversacional introduz uma diferença conceitualmente importante.

Nas redes sociais frequentemente observamos:

curtiu
clicou
assistiu
compartilhou
seguiu
comprou

e tentamos inferir alguma coisa.

Em conversas com IA o próprio usuário frequentemente fornece:

"meu problema é..."

"não entendo..."

"estou considerando..."

"tenho duas alternativas..."

"minha arquitetura funciona assim..."

"por que isso aconteceu?"

"qual opção você escolheria?"

Isso pode representar contexto cognitivo muito mais explícito.

Não devemos concluir daí que provedores estejam oferecendo conversas privadas para terceiros. Estamos construindo um modelo hipotético de ameaça.

Mas defensivamente precisamos perguntar:

Qual seria o impacto se determinado corpus conversacional fosse indevidamente exposto?

Essa pergunta basta.


🎭 Moriarty não quer apenas saber o que aconteceu

Nosso professor do crime imaginário está interessado também em:

incerteza.

Considere:

“Não sei se devemos migrar X para Y.”

Essa frase revela mais do que parece.

Ela sugere:

X existe.

Y é considerado.

há uma decisão pendente.

o autor participa da discussão.

existe incerteza.

Isso é extraordinariamente interessante para inteligência.

Não estamos observando somente uma decisão passada.

Estamos observando o espaço de possibilidades anterior à decisão.


⚖️ O advogado entra novamente na sala

Voltemos ao artigo original.

Ele argumenta que informações identificáveis de clientes merecem atenção especial e recomenda práticas como anonimização e ambientes apropriados para informações sensíveis.

Nosso Supermosaico acrescenta outra preocupação.

Um advogado pode registrar:

processo;
estratégia;
dúvidas;
hipóteses;
limites de negociação;
fragilidades percebidas;
possíveis argumentos.

Novamente, isso não significa que a contraparte consiga simplesmente acessar essas conversas.

Não consegue.

Seria necessário algum evento adicional de exposição, comprometimento ou falha de governança.

Mas o impacto potencial do corpus merece entrar no threat model.


⚔️ A assimetria computacional

Imagine:

ZÉ DA SILVA
     │
advogado pequeno
notebook
tempo limitado
     │
     VS
     │
MEGACORP S/A
     │
equipe jurídica
especialistas
bases jurídicas
engenharia
automação
análise documental
IA

IA pode democratizar recursos antes inacessíveis ao pequeno advogado.

Isso é excelente.

Mas também pode industrializar capacidades de grandes organizações.

Temos duas forças simultâneas:

IA → DEMOCRATIZAÇÃO

IA → CONCENTRAÇÃO

Qual vencerá?

Provavelmente dependerá de acesso, custo, regulação, educação e governança.


🛡️ Como derrotar Moriarty sem abandonar IA

A resposta não é:

“Proibam tudo!”

Isso desperdiçaria uma tecnologia extraordinariamente útil.

O próprio artigo que iniciou nossa reflexão defende uma abordagem de governança em vez da simples interrupção do uso da IA.

Precisamos tornar Moriarty caro.

1. Separar identidades

PESSOAL ≠ PROFISSIONAL

2. Separar clientes

CLIENTE A ≠ CLIENTE B

3. Separar projetos

Não criar desnecessariamente um Supermosaico.

4. Minimizar

Pergunte:

“A IA realmente precisa saber isso?”

5. Sanitizar

Troque:

BANCO-REAL-XYZ

por:

CLIENTE-A

quando o detalhe real não for necessário.

6. Remover segredos

Tokens, credenciais, dados pessoais, dumps completos e informações confidenciais não devem passear livremente por prompts.

7. Governar retenção

A organização precisa saber onde conversas corporativas ficam e qual é seu ciclo de vida.

8. Governar consultores

A política precisa alcançar terceiros adequadamente, não somente empregados.

9. Pensar cumulativamente

Pergunte não apenas:

“Este prompt é perigoso?”

mas:

“O que cem prompts como este revelariam?”

10. Modelar Knowledge Privilege

Identifique não apenas quem possui grandes permissões.

Identifique funções que possuem enorme contexto institucional.


🔬 Um Red Team diferente

Podemos testar tudo isso sem atacar ninguém.

Crie uma empresa fictícia.

Um banco chamado:

BANCO MORIARTY S/A

Crie:

Carlos — N3 CICS
Maria — DBA
João — arquiteto
Ana — consultora
Watson — segurança

Produza informações sintéticas.

Simule um ano de prompts permitidos.

Depois entregue somente esse corpus para outro time autorizado e pergunte:

“O que vocês conseguem reconstruir sobre nossa empresa fictícia?”

Arquitetura?

Dependências?

Pessoas?

Sistemas críticos?

Cronologia?

Regras de negócio?

Tecnologias?

Incidentes?

Se o resultado for surpreendentemente detalhado, encontramos uma deficiência de governança sem comprometer uma única empresa real.

Esse seria um belíssimo exercício de Red Team de conhecimento.


🕒 03:17 — O incidente

Às 03:17 da madrugada, o telefone toca.

Produção está normal.

Nenhum dataset foi copiado.

Nenhum usuário RACF utilizou SPECIAL.

Nenhum arquivo de 40 GB saiu pela rede.

Nenhum pendrive apareceu.

Nenhum source foi publicado.

Nenhum alarme tradicional disparou.

Watson olha para Moriarty:

“Então não houve incidente?”

Moriarty toma tranquilamente seu café.

“Meu caro Watson... você ainda está procurando o arquivo.”

Sobre a mesa existem 12.847 pequenas tesselas.

Uma transação aqui.

Uma regra ali.

Um incidente acolá.

Uma decisão arquitetural.

Uma dependência.

Um fornecedor.

Uma exceção.

Uma dúvida.

Uma história de vinte anos resumida por alguém em cinco linhas.

Watson começa a juntar as pedras.

A figura aparece.

Não existe MEGACORP-SECRETS.ZIP.

Nunca existiu.

Existe algo potencialmente muito mais interessante:

conhecimento.


☕ A última lição do Dr. Moriarty

Durante décadas construímos excelentes mecanismos para responder:

Quem pode acessar este dado?

RACF responde isso maravilhosamente no mainframe.

IAM responde.

PAM responde.

ACL responde.

MFA ajuda.

Zero Trust ajuda.

DLP ajuda.

Mas IA nos obriga a acrescentar novas perguntas:

Quem pode externalizar esse conhecimento?

Quanto contexto pode ser acumulado ao longo do tempo?

Que informação aparentemente inocente se torna sensível quando correlacionada?

Onde termina experiência profissional e começa memória corporativa portátil?

O que acontece com o corpus depois que o funcionário ou consultor deixa a organização?

Qual é o blast radius do comprometimento de uma identidade que possui anos de conversas profissionais?

E principalmente:

Estamos protegendo somente aquilo que nossos funcionários acessam ou também os lugares onde eles passaram a registrar aquilo que sabem?

Essa talvez seja uma das grandes discussões de segurança da era da Inteligência Artificial.

Não significa abandonar IA.

Significa amadurecer sua utilização.

O profissional que pergunta corretamente para uma IA pode produzir em minutos algo que anteriormente consumiria horas.

Isso é fantástico.

Mas justamente por querermos respostas melhores somos incentivados a fornecer mais contexto.

E contexto é conhecimento.

Conhecimento acumulado cria mosaicos.

Mosaicos correlacionados criam Supermosaicos.

Portanto, sob a tutela do Dr. Moriarty, terminamos com uma regra simples:

O maior segredo talvez não esteja em nenhuma tessela. O segredo pode ser a imagem que aparece quando alguém consegue juntar tesselas suficientes.

E Sherlock Holmes provavelmente acrescentaria:

“Proteja as pedras, Watson.”

Moriarty sorriria.

“Não. Proteja as relações entre elas.”

Bellacosa Mainframe — onde até um simples prompt pode acabar virando uma tessela no mosaico.

terça-feira, 8 de setembro de 2026

Star Trek Acertou o Futuro... Mas Será Que Nós Acertamos a Humanidade?

 

Bellacosa Mainframe e o legado dos 60 anos de Star Trek

☕ Um Café no Bellacosa Mainframe

Star Trek Acertou o Futuro... Mas Será Que Nós Acertamos a Humanidade?

60 Anos Depois, Vivemos Cercados por Inteligência Artificial, Internet, IoT e Guerras. A Pergunta Não É Mais se Conseguimos Construir a Tecnologia. É Se Ainda Conseguiremos Construir a Federação.

"O futuro nunca foi sobre naves estelares. Sempre foi sobre pessoas."

Existe uma cena invisível que acontece todos os dias.

Um programador COBOL em um banco processa milhões de transações que mantêm economias inteiras funcionando.

Um satélite transmite informações para outro continente.

Uma Inteligência Artificial auxilia um médico a identificar um tumor.

Um sensor IoT detecta um incêndio antes que ele destrua uma floresta.

Uma criança conversa naturalmente com uma máquina.

Um astronauta observa a Terra do espaço.

Enquanto isso...

Em outro lugar do planeta, cidades são destruídas por mísseis.

Hospitais ficam sem energia.

Crianças crescem em meio a conflitos.

Governos disputam poder.

Hackers atacam infraestruturas críticas.

Fake news dividem sociedades.

A mesma tecnologia capaz de salvar vidas também pode ampliar destruição.

E então percebemos algo curioso.

Sessenta anos depois da estreia de Star Trek, finalmente conseguimos construir boa parte da tecnologia imaginada por Gene Roddenberry.

Mas ainda estamos tentando aprender a parte mais difícil.

Como sermos dignos dela.

Pegue seu café.

Hoje não vamos revisitar apenas uma série de televisão.

Vamos conversar sobre um espelho.

Porque talvez Star Trek nunca tenha mostrado o futuro.

Talvez tenha mostrado aquilo que ainda estamos tentando alcançar.


Bellacosa Mainframe Star Trek Setembro de 1966

Setembro de 1966

Imagine aquele momento.

O homem ainda não havia chegado à Lua.

A Internet não existia.

A palavra "software" mal era conhecida.

Os computadores ocupavam salas inteiras.

COBOL tinha poucos anos de vida.

Mainframes utilizavam cartões perfurados.

Programar era quase um ritual.

Foi exatamente nesse cenário que apareceu uma pequena série chamada Star Trek.

Pouca audiência.

Baixo orçamento.

Cenários simples.

Uniformes coloridos.

E uma ideia absurdamente ambiciosa.

Mostrar uma humanidade que havia sobrevivido aos próprios erros.


Gene Roddenberry não queria prever tecnologia

Ele queria prever maturidade.

Essa talvez seja a maior confusão que as pessoas fazem.

Quando lembram de Star Trek, pensam imediatamente em:

teletransporte.

phasers.

dobra espacial.

Enterprise.

Mas isso era apenas o cenário.

O verdadeiro roteiro sempre foi outro.

Roddenberry perguntava:

Como seria uma sociedade onde ciência, ética, diversidade e curiosidade finalmente caminhassem juntas?

Sessenta anos depois...

Essa pergunta continua sem resposta.


O futuro chegou...

Só que de uma forma muito diferente.

Olhe ao seu redor.

Você provavelmente possui no bolso um smartphone milhares de vezes mais poderoso que qualquer computador usado pela NASA durante o Projeto Apollo.

Você conversa com uma Inteligência Artificial.

Faz videoconferências.

Traduz idiomas instantaneamente.

Compra produtos sem sair de casa.

Controla lâmpadas por voz.

Recebe informações de relógios inteligentes.

Utiliza GPS.

Streaming.

Computação em nuvem.

Blockchain.

Computação quântica em desenvolvimento.

Carros parcialmente autônomos.

Sensores espalhados por cidades inteiras.

Internet das Coisas.

Modelos generativos capazes de escrever código.

Se alguém mostrasse tudo isso para uma pessoa de 1966...

Ela provavelmente acreditaria estar vendo tecnologia vulcana.


E mesmo assim...

Ainda fazemos guerras.

Essa talvez seja a maior ironia do século XXI.

Nossa inteligência técnica evoluiu numa velocidade impressionante.

Nossa inteligência social...

Nem tanto.

Continuamos discutindo fronteiras.

Continuamos divididos por ideologias.

Continuamos produzindo armas cada vez mais sofisticadas.

Criamos drones inteligentes.

Ataques cibernéticos.

Campanhas de desinformação.

Espionagem digital.

Sabotagem de infraestrutura.

A tecnologia avançou.

Mas o coração humano continua enfrentando velhos desafios.


O computador da Enterprise

Hoje mora no seu bolso.

Lembra do comunicador?

Virou smartphone.

O PADD?

Virou tablet.

O computador de bordo?

Hoje responde perguntas por voz.

O Tradutor Universal?

Está presente em aplicativos que traduzem dezenas de idiomas em tempo real.

A videoconferência?

É rotina.

Os sensores médicos?

Estão em relógios inteligentes.

A Inteligência Artificial?

Finalmente começou a conversar naturalmente.

O curioso é que nenhuma dessas tecnologias surgiu por acaso.

Milhares de engenheiros cresceram assistindo Star Trek.

Primeiro imaginaram.

Depois construíram.


O COBOL também faz parte dessa história

Pode parecer estranho ligar Star Trek ao mainframe.

Mas pense comigo.

Enquanto milhões de pessoas sonhavam com naves espaciais...

Os bancos precisavam continuar funcionando.

As aposentadorias precisavam ser pagas.

As passagens aéreas precisavam ser emitidas.

Os governos precisavam processar impostos.

Hospitais precisavam registrar pacientes.

Empresas precisavam sobreviver.

Tudo isso aconteceu graças a profissionais que construíram sistemas robustos.

Entre eles...

Programadores COBOL.

Talvez nunca apareçam em filmes.

Mas são parte silenciosa da infraestrutura que mantém a sociedade funcionando.

Assim como Scotty.

Quase ninguém lembrava dele quando tudo estava funcionando.

Mas bastava uma pane no motor de dobra para perceber sua importância.


Scotty era um Sysprog

Essa é uma das minhas analogias favoritas.

Imagine a Enterprise.

Kirk lidera.

Spock analisa.

McCoy cuida das pessoas.

Uhura comunica.

Sulu pilota.

Scotty mantém tudo funcionando.

Ele não aparece apenas para apertar botões.

Ele entende profundamente a máquina.

Conhece seus limites.

Improvisa quando necessário.

Resolve problemas sob pressão.

Quem trabalha com IBM Z conhece bem esse sentimento.

Quando um ambiente crítico para.

Não existe espaço para pânico.

Existe diagnóstico.

Existe método.

Existe experiência.

Existe equipe.


Spock e a Inteligência Artificial

Em 2026 falamos muito sobre IA.

Modelos.

LLMs.

Agentes.

Automação.

Mas existe um detalhe curioso.

Spock nunca foi apenas lógico.

Ele também era extremamente ético.

Essa diferença é enorme.

Uma Inteligência Artificial pode responder.

Mas deve responder?

Pode executar uma ação.

Mas deveria executá-la?

Star Trek fazia essas perguntas décadas antes de existir ChatGPT.


O perigo da tecnologia sem ética

Hoje uma IA consegue gerar imagens.

Escrever código.

Criar vídeos.

Produzir vozes.

Descobrir padrões invisíveis.

Mas ela também pode:

enganar.

manipular.

produzir fraudes.

espalhar desinformação.

invadir privacidade.

automatizar ataques.

Não é diferente do motor de dobra.

Toda tecnologia poderosa exige responsabilidade proporcional.

Essa talvez seja a maior lição de Star Trek.


A Federação nunca foi construída por máquinas

Foi construída por pessoas.

Existe uma frase que sempre me impressiona.

A Federação não venceu porque possuía as armas mais fortes.

Venceu porque conseguia cooperar.

Imagine isso no mundo da computação.

Arquitetos.

Programadores.

Segurança.

DevOps.

Banco de Dados.

Mainframe.

Cloud.

IA.

Todos trabalhando juntos.

É praticamente uma ponte da Enterprise moderna.


A Internet nos conectou...

Mas nem sempre nos aproximou.

Quando a Internet surgiu comercialmente, muitos acreditavam que ela acabaria com preconceitos.

Que aproximaria culturas.

Que democratizaria conhecimento.

Em parte...

Isso aconteceu.

Hoje aprendemos praticamente qualquer assunto.

Conversamos com pessoas do outro lado do planeta.

Participamos de comunidades globais.

Mas também descobrimos que algoritmos podem criar bolhas.

Polarizações.

Radicalização.

Fake news.

Star Trek imaginava uma humanidade unificada.

Nós criamos uma rede mundial.

Agora precisamos aprender a usá-la como uma Federação, e não como campos de batalha digitais.


Internet das Coisas

Imagine explicar IoT para alguém de 1966.

Geladeiras conectadas.

Carros conectados.

Semáforos inteligentes.

Sensores agrícolas.

Satélites monitorando florestas.

Casas automatizadas.

Tudo parece ficção científica.

Mas já é cotidiano.

Curiosamente...

Quanto mais dispositivos conectamos...

Mais precisamos de segurança.

A Enterprise também ensinava isso.

Cada sistema adicional aumentava responsabilidade.


O maior legado não foi tecnológico

Foi psicológico.

Star Trek ensinou milhões de jovens a gostar de ciência.

A gostar de engenharia.

A gostar de astronomia.

A gostar de computadores.

A gostar de explorar.

Isso não aparece em estatísticas.

Mas aparece em universidades.

Laboratórios.

Empresas.

Agências espaciais.

Centros de pesquisa.

Muitos cientistas simplesmente decidiram seguir carreira porque um dia assistiram Spock resolver um problema usando lógica.


E você, Padawan?

Talvez esteja aprendendo COBOL em 2026.

Alguns amigos perguntam:

"Por que estudar uma linguagem tão antiga?"

Eu responderia com outra pergunta.

Por que ainda estudamos Shakespeare?

Por que ainda estudamos Aristóteles?

Porque certas obras não envelhecem.

Elas se tornam fundamentos.

COBOL é um fundamento da computação corporativa.

Star Trek é um fundamento da imaginação tecnológica.

Ambos continuam relevantes porque resolveram problemas que permanecem importantes.


A verdadeira fronteira final

Quando ouvimos essa frase...

Pensamos imediatamente no espaço.

Mas talvez a fronteira final nunca tenha sido Marte.

Nem Júpiter.

Nem outra galáxia.

Talvez seja nossa própria capacidade de cooperar.

De construir tecnologias responsáveis.

De equilibrar Inteligência Artificial com ética.

De preservar liberdade.

De compartilhar conhecimento.

De usar ciência para reduzir sofrimento.

Essa continua sendo nossa missão.


Sessenta anos depois...

Ainda precisamos de Kirk.

Precisamos de líderes.

Precisamos de Spock.

Precisamos de pensamento crítico.

Precisamos de McCoy.

Precisamos de empatia.

Precisamos de Scotty.

Precisamos de engenheiros competentes.

Precisamos de Uhura.

Precisamos de comunicação.

Precisamos de Sulu.

Precisamos de disciplina.

Precisamos de Chekov.

Precisamos de jovens trazendo novas ideias.

Mais do que nunca.


Uma carta de um velho programador aos novos Padawans

Se você está começando sua jornada em tecnologia, talvez a velocidade das mudanças assuste.

Hoje existe IA.

Amanhã surgirá outra revolução.

Depois computação quântica.

Depois novas arquiteturas.

Depois algo que ainda nem imaginamos.

Não tente decorar tudo.

Aprenda aquilo que Star Trek ensinou.

Aprenda a pensar.

Aprenda a colaborar.

Aprenda a questionar.

Aprenda a respeitar diferenças.

Aprenda a estudar continuamente.

Tecnologias mudam.

Princípios permanecem.

Foi assim em 1966.

Foi assim em 1980.

Foi assim na era dos mainframes.

Foi assim na Internet.

É assim na Inteligência Artificial.

E continuará sendo.


☕ Considerações finais do Bellacosa Mainframe

Quando Star Trek estreou, ninguém imaginava que, seis décadas depois, conversaríamos com inteligências artificiais, carregaríamos supercomputadores no bolso e conectaríamos bilhões de dispositivos à Internet.

Gene Roddenberry acertou muitas previsões tecnológicas.

Mas sua maior previsão não era sobre máquinas.

Era sobre nós.

Ele acreditava que a humanidade poderia crescer junto com sua tecnologia.

Essa continua sendo a missão mais difícil.

Como programador COBOL da velha guarda, depois de décadas convivendo com mainframes que nunca podem falhar, aprendi uma lição simples: o hardware mais poderoso, o software mais elegante e a IA mais avançada ainda dependem das escolhas humanas.

É por isso que, sessenta anos depois, Star Trek continua sendo mais do que entretenimento.

Ela permanece como um manual de princípios para engenheiros, cientistas, arquitetos de sistemas, desenvolvedores, operadores, pesquisadores e todos aqueles que acreditam que conhecimento deve servir à humanidade.

E talvez esse seja o maior legado da USS Enterprise.

Ela nunca nos convidou apenas para explorar novas galáxias.

Ela nos convidou a construir um futuro em que valha a pena chegar.

Vida longa e próspera, Padawan.

E que sua missão, seja em COBOL, em Inteligência Artificial ou em qualquer tecnologia que ainda será inventada, seja sempre a mesma da Frota Estelar: explorar, aprender, compartilhar e deixar o universo um pouco melhor do que você o encontrou. 🖖☕

segunda-feira, 7 de setembro de 2026

Guilherme de Baskerville Entra no CPD — O Nome dos Pedreiros na Catedral de 80 Colunas

 

Um Café no Bellacosa Mainframe

Guilherme de Baskerville Entra no CPD — O Nome dos Pedreiros na Catedral de 80 Colunas

Ou: como cartões perfurados, datasets de 80 bytes, COBOL, PL/I, Assembler, Natural, XML, JSON, APIs e décadas de retrocompatibilidade transformaram programas legados em catedrais construídas por gerações de artesãos quase anônimos





Prólogo — O nome estava na pedra

Guilherme de Baskerville não começou examinando o código.

Isso surpreendeu o jovem programador.

Havia milhares de linhas COBOL diante deles, algumas tão antigas que ninguém presente no CPD sabia explicar completamente sua origem. O programa havia sobrevivido a reorganizações, mudanças de hardware, novos compiladores, novas moedas, novas legislações e incontáveis projetos de modernização.

— Mestre, não deveríamos procurar primeiro a PROCEDURE DIVISION?

Guilherme aproximou-se do terminal.

No alto do fonte havia algo aparentemente banal:

*****************************************************************
* J. PEREIRA
* 17/08/1983
* ALTERADA ROTINA DE FATURAMENTO
*****************************************************************
* M. SANTOS
* 04/02/1987
* INCLUIDO NOVO TIPO DE MOVIMENTO
*****************************************************************
* R. ALMEIDA
* 22/09/1994
* ADEQUACAO NOVA REGRA MONETARIA
*****************************************************************

Continuava.

Uma tela.

Duas.

Dez.

Dezenas de nomes.

Guilherme permaneceu em silêncio.

— O que procura? — perguntou o aprendiz.

— Não procuro — respondeu ele. — Estou prestando homenagem.



1. O programa legado possui uma memória

Quando encontramos um programa COBOL, PL/I, Natural ou Assembler com décadas de existência, frequentemente encontramos também algo que os manuais tratam simplesmente como change history.

Nome ou USER-ID.

Data.

Descrição da alteração.

Três ou quatro linhas cercadas por asteriscos.

*****************************************************************
* JCARLOS
* 14/06/1988
* CORRECAO CALCULO DE JUROS
*****************************************************************

Tecnicamente, aquilo é documentação.

Mas depois de quarenta anos transforma-se em algo diferente.

É memória institucional.

Talvez ninguém saiba mais quem foi JCARLOS.

Seu USER-ID provavelmente desapareceu há décadas.

O sistema de chamados usado naquela alteração talvez nem exista.

A documentação funcional pode ter sido perdida.

O departamento pode ter mudado de nome cinco vezes.

JCARLOS pode estar aposentado.

Pode morar do outro lado do mundo.

Pode ter falecido.

Mas alguma coisa permaneceu:

* JCARLOS
* 14/06/1988
* CORRECAO CALCULO DE JUROS

O programa lembra.



2. As assinaturas dos pedreiros

Nas antigas construções europeias podemos encontrar marcas deixadas por pedreiros e artesãos.

Isso oferece uma metáfora extraordinária para software legado.

Imagine uma catedral.

Um homem trabalha numa pedra.

Ele não projetou o edifício inteiro.

Não escolheu necessariamente onde ficaria a torre.

Não decidiu a doutrina representada nos vitrais.

Seu nome provavelmente nunca aparecerá num livro de história.

Mas aquela pedra passou pelas mãos dele.

Então deixa uma marca.

Séculos depois alguém a encontra.

No mainframe fazemos algo assustadoramente parecido:

*****************************************************************
* MFERREIRA
* 11/03/1991
* INCLUIDA VALIDACAO DO MOVIMENTO 07
*****************************************************************

Não significa:

Eu construí este sistema.

Significa:

Esta pedra passou pelas minhas mãos.

E isso muda completamente nossa maneira de olhar um fonte antigo.



3. Nenhum programador construiu a catedral

Um dos grandes erros quando falamos de software é imaginar um programa como criação de uma única pessoa.

Em sistemas corporativos longevos isso frequentemente não existe.

O programa pode ter nascido assim:

1981  JOAO
      criação

Depois:

1984  MARIA
      nova modalidade

Depois:

1987  CARLOS
      novo processamento

Depois:

1994  ANA
      mudança monetária

Depois:

1999  ROBERTO
      adequação Y2K

E continua:

2004
2008
2012
2017
2020
2026

Quando chegamos ao programa em 2026, não estamos diante do trabalho de João.

Estamos diante de:

João + Maria + Carlos + Ana + Roberto + dezenas ou centenas de pessoas.

A criatura nasceu, cresceu e foi modificada.

Algumas partes desapareceram.

Outras sobreviveram.

Outras foram reconstruídas.

O programa tornou-se uma obra coletiva.

Exatamente como uma catedral que atravessou gerações.



4. Guilherme faz a primeira pergunta

O jovem programador apontou para uma rotina.

— Isto está horrível. Podemos remover?

Guilherme respondeu:

— Por que ela existe?

— Não sei.

— Então ainda não sabemos se podemos removê-la.

Essa talvez seja uma das regras mais importantes para quem começa a trabalhar com legado.

Código estranho não significa automaticamente código inútil.

Às vezes é lixo.

Às vezes é dívida técnica.

Às vezes é uma gambiarra histórica.

Mas às vezes é a última manifestação de uma regra de negócio que ninguém mais documentou.

Você encontra:

IF WS-TIPO = 7
   PERFORM 8000-TRATA-ESPECIAL
END-IF

E pensa:

Que porcaria é essa?

Procura no cabeçalho:

*****************************************************************
* MROCHA
* 18/09/1989
* CORRECAO PROCESSAMENTO MOVIMENTO TIPO 7
*****************************************************************

Agora existe uma pista.

Não temos a resposta.

Temos uma evidência.

Guilherme de Baskerville certamente aprovaria a diferença.


5. O programa também possui camadas arqueológicas

Programas legados podem carregar algo ainda mais interessante.

Eles registram a própria evolução da informática.

Imagine um sistema criado no começo dos anos 1980.

Sua primeira versão pode ter sido essencialmente:

arquivo
   |
COBOL
   |
arquivo

Depois apareceu VSAM.

Depois Db2.

Depois CICS.

Depois MQ.

Então alguém precisou conectá-lo ao mundo distribuído.

Chegaram HTML e aplicações Web.

Depois XML.

SOAP.

Java.

JSON.

REST.

APIs.

Cloud.

Containers.

Eventos.

De repente temos:

                    MOBILE
                       |
                    HTTPS
                       |
                 API GATEWAY
                       |
                     JSON
                       |
                     REST
                       |
                z/OS CONNECT
                       |
                     CICS
                       |
                     COBOL
                  /    |    \
                Db2   VSAM   MQ
                              |
                         SISTEMA CLOUD

E em algum lugar no centro dessa arquitetura ainda existe:

       PERFORM 300-CALCULAR-JUROS

escrito originalmente quando ninguém possuía um smartphone.

Frankenstein?

Talvez.

Mas existe uma interpretação mais interessante.

Estratigrafia computacional.


6. Frankenstein entra na catedral

Chamamos esses sistemas de Frankenstein porque encontramos tecnologias de épocas completamente diferentes costuradas umas às outras.

Assembler.

COBOL.

PL/I.

Natural.

JCL.

VSAM.

IMS.

Db2.

CICS.

MQ.

HTML.

XML.

SOAP.

Java.

JSON.

REST.

Cloud.

Mas uma catedral construída durante séculos também pode apresentar estilos diferentes.

Uma parte pertence a determinada época.

Outra foi reconstruída.

Uma capela apareceu posteriormente.

Um órgão foi substituído.

Um vitral é muito mais recente.

Uma restauração contemporânea introduziu outra marca.

O historiador não olha imediatamente para aquilo e diz:

Que arquitetura inconsistente!

Ele pergunta:

O que aconteceu aqui?

Essa é a diferença entre simplesmente programar e fazer arqueologia de software.


7. O astronauta na catedral

Existe um caso delicioso na Catedral Nova de Salamanca.

Durante uma restauração realizada em 1992, foi acrescentada à ornamentação uma figura de astronauta.

A catedral começou a ser construída séculos antes da exploração espacial.

Mas ali está ele.

Um astronauta na pedra.

Não é medieval.

Não tenta fingir que é.

Ele registra a época da intervenção.

E nossos programas fazem exatamente isso.

Imagine:

*****************************************************************
* JPEREIRA
* 1983
* CRIACAO
*****************************************************************

*****************************************************************
* MROCHA
* 1995
* INTEGRACAO DB2
*****************************************************************

*****************************************************************
* CSOUZA
* 2003
* INTERFACE XML
*****************************************************************

*****************************************************************
* AFERREIRA
* 2018
* RETORNO JSON
*****************************************************************

*****************************************************************
* VBELLACOSA
* 2026
* INTEGRACAO API REST
*****************************************************************

REST é o astronauta esculpido na catedral COBOL.

Ele não precisa destruir aquilo que veio antes.

Ele demonstra que a construção chegou viva até outra época.


8. O mistério das 80 colunas

Então Guilherme encontrou outra pista.

RECFM=FB
LRECL=80

O jovem programador riu.

— Outra velharia.

Guilherme olhou para ele.

— Oitenta por quê?

Silêncio.

É exatamente aqui que muita gente conhece apenas um terço da história.

O cartão perfurado IBM que se tornou um símbolo da computação possuía 80 colunas. A própria IBM registra que o cartão de 80 colunas foi introduzido em 1928 e tornou-se extremamente disseminado no processamento de informações.

Depois olhamos para o formato tradicional do fonte COBOL:

1 - 6    Sequence Number Area
7        Indicator Area
8 - 11   Area A
12 - 72  Area B
73 - 80  Comment/Identification Area

A documentação atual da IBM ainda descreve explicitamente uma linha fonte COBOL de 80 caracteres, dividida nessas áreas.

Isso significa que aquele número aparentemente arbitrário possui ancestralidade.


9. O cartão desapareceu; sua sombra permaneceu

Essa é uma das coisas mais fascinantes da computação.

Uma limitação física pode transformar-se em convenção.

A convenção transforma-se em padrão.

O padrão influencia software.

O software cria dependências.

As dependências exigem compatibilidade.

Décadas depois a causa física desapareceu, mas seus descendentes permanecem.

Podemos representar assim:

CARTAO PERFURADO
       |
       v
  80 COLUNAS
       |
       v
FORMATO DE FONTE
       |
       v
 FERRAMENTAS
       |
       v
 DATASETS
       |
       v
 COMPATIBILIDADE
       |
       v
     2026

Inclusive documentação atual de ferramentas IBM continua reconhecendo áreas de numeração nas colunas 1–6 e 73–80 para fontes COBOL.

O cartão morreu.

A geometria sobreviveu.


10. O dataset de 80 bytes é uma rua romana

Imagine caminhar por uma cidade europeia.

Existe uma rua estranhamente curva.

Para um urbanista moderno, aquela curva parece irracional.

Até alguém explicar:

A estrada romana passava aqui.

A cidade desapareceu.

Impérios desapareceram.

Veículos mudaram.

Mas a rua continuou obedecendo a uma decisão tomada dois mil anos antes.

No mainframe:

LRECL=80

pode desempenhar papel semelhante.

Não significa que todo dataset de 80 bytes exista porque era cartão perfurado — seria uma simplificação histórica perigosa.

Significa que 80 tornou-se um número estruturalmente importante em um ecossistema profundamente influenciado pelo cartão e pelos formatos derivados dele.

Essa nuance importa.

O arqueólogo não inventa explicações.

Ele procura evidências.


11. A retrocompatibilidade é a argamassa

Agora chegamos à característica que permitiu que nossa catedral continuasse crescendo:

retrocompatibilidade.

A IBM fez algo extraordinariamente difícil ao longo da evolução do mainframe: preservar caminhos de continuidade enquanto hardware e software avançavam.

A própria IBM descreve os sistemas IBM Z atuais como descendentes diretos da linhagem System/360 e System/370 e afirma que muitas aplicações antigas puderam continuar funcionando em sistemas posteriores.

Isso não significa:

Qualquer programa de 1964 roda magicamente e sem qualquer consideração num z17 de 2026.

Seria falso.

Existem releases suportados, requisitos, PTFs, produtos, dependências, mudanças arquiteturais e processos de migração.

Por exemplo, a matriz atual do z17 estabelece explicitamente quais versões de z/OS são suportadas e quais exigem manutenção apropriada.

Retrocompatibilidade não é magia.

É engenharia.


12. A decisão caríssima de não demolir a cidade

Imagine se toda evolução tecnológica significasse:

NOVO HARDWARE
      |
      v
JOGUE FORA O SOFTWARE
      |
      v
REESCREVA TUDO

Para uma pequena aplicação talvez seja possível.

Agora imagine um banco.

Uma seguradora.

Uma companhia aérea.

Um governo.

Uma indústria.

Décadas de:

  • regras de negócio;

  • cálculos;

  • exceções;

  • layouts;

  • integrações;

  • arquivos;

  • programas;

  • transações;

  • conhecimento operacional.

A retrocompatibilidade protege algo muito maior que o executável.

Ela ajuda a preservar investimento e conhecimento acumulado.

A IBM inclusive descreve historicamente ciclos longos de hardware e caminhos de upgrade entre famílias como mecanismos de proteção do investimento e extensão da vida dos ativos.

Isso explica parte da longevidade dessas catedrais.


13. Manutenção também é construção

Existe uma injustiça profissional curiosa.

Quem cria algo novo é chamado de construtor.

Quem mantém algo antigo frequentemente é tratado como alguém que apenas “faz manutenção”.

Uma catedral demonstra o absurdo dessa distinção.

Sem manutenção:

o telhado infiltra.

A madeira apodrece.

A pedra racha.

O vitral quebra.

A torre fica instável.

Depois de séculos, não existe mais catedral.

Portanto, o restaurador também participa da construção da longevidade.

No software acontece o mesmo.

Quem resolveu o problema em 1991 ajudou o programa a chegar a 1992.

Quem resolveu Y2K ajudou-o a chegar a 2000.

Quem migrou o compilador ajudou-o a continuar.

Quem abriu uma API em 2026 talvez permita que a regra de negócio sobreviva por outra década.

Manter também é construir.


14. Modernização não precisa significar demolição

Aqui mora outra lição importante para o programador COBOL iniciante.

Modernizar não significa necessariamente:

DELETE COBOL.

Pode significar:

                APLICACAO MODERNA
                       |
                     REST
                       |
                     JSON
                       |
                  INTEGRACAO
                       |
                     CICS
                       |
                     COBOL
                       |
                      Db2

Uma parte continua.

Outra é substituída.

Uma interface nasce.

Uma rotina é refatorada.

Uma dependência desaparece.

Outra surge.

A catedral continua em funcionamento durante a reforma.

Isso é muito diferente de demolir o edifício e prometer que construiremos outro antes do próximo fechamento contábil.


15. Mas não transforme história em religião

Guilherme levantaria o dedo aqui.

Respeitar o legado não significa venerar todo código antigo.

Existe código ruim.

Existe redundância.

Existe rotina morta.

Existe tecnologia cujo custo de manutenção deixou de fazer sentido.

Existe vulnerabilidade.

Existe dívida técnica.

Existe arquitetura que precisa desaparecer.

A arqueologia serve justamente para evitar dois extremos:

Tudo antigo é lixo.

e:

Tudo antigo deve ser preservado.

O restaurador competente pergunta:

O que isto sustenta?

Por que existe?

Quem depende disso?

Qual risco existe em removê-lo?

Existe alternativa melhor?

Como provar que o comportamento continuará correto?

Só então pega o martelo.


16. O comentário pode ser a última testemunha

Agora imagine isto:

       IF WS-CODIGO = 47
          MOVE 'S' TO WS-TRATAMENTO
       END-IF

Ninguém sabe explicar.

Git?

O programa é décadas anterior à adoção de Git pela organização.

Ticket?

Desapareceu.

Documento?

Não encontrado.

Analista funcional?

Aposentou-se em 2007.

Então você sobe até o cabeçalho:

*****************************************************************
* ACOSTA
* 23/05/1993
* TRATAMENTO ESPECIAL CLIENTES CONVENIO 47
*****************************************************************

Não solucionamos o mistério.

Mas encontramos uma testemunha.

E talvez seja a última.

Por isso apagar comentários históricos indiscriminadamente durante uma “limpeza” pode equivaler a restaurar uma catedral lixando as inscrições das pedras.


17. O Frankenstein contém conhecimento

Voltemos ao nosso monstro:

Assembler
   |
COBOL
   |
CICS
   |
Db2
   |
MQ
   |
XML
   |
SOAP
   |
Java
   |
JSON
   |
REST
   |
Cloud

Parece absurdo.

Mas cada camada pode representar uma pergunta que a organização precisou responder:

Como processaremos isto?

Como armazenaremos isto?

Como permitiremos transações online?

Como integraremos sistemas?

Como falaremos com aplicações Web?

Como exporemos serviços?

Como integraremos cloud e mainframe?

O Frankenstein deixa então de ser apenas um acidente.

Transforma-se num mapa das necessidades empresariais através do tempo.


18. Easter egg — o sino toca RC=0000

Guilherme terminou sua investigação.

O JOB foi submetido.

O jovem programador observava SDSF.

Esperaram.

Então surgiu:

COND CODE 0000

— Mestre, terminou.

Guilherme sorriu.

— Não. Apenas tocou o sino.

— Sino?

— Toda catedral possui um.

E desde então o aprendiz nunca mais viu um RC=0000 da mesma maneira.


19. O dia em que a catedral fechar

Existe ainda uma cena que raramente imaginamos.

Algum dia um desses programas executará pela última vez.

Talvez depois de quarenta anos.

Talvez cinquenta.

O scheduler deixará de chamá-lo.

O dataset será arquivado.

O load module desaparecerá da biblioteca de produção.

Outro sistema assumirá sua função.

E finalmente teremos:

LAST EXECUTION
RC=0000

Nesse momento seria justo abrir o fonte uma última vez.

Subir até o início.

E ler.

*****************************************************************
* JOAO
* 1981
*****************************************************************

*****************************************************************
* MARIA
* 1985
*****************************************************************

*****************************************************************
* CARLOS
* 1992
*****************************************************************

...

*****************************************************************
* ULTIMO PROGRAMADOR
* 20XX
*****************************************************************

Talvez existam cem nomes.

Talvez duzentos.

Nenhum deles construiu sozinho aquela catedral.

Mas sem eles ela não teria chegado ao último processamento.


20. O programador iniciante precisa aprender a ler pedras

Quando você começar a trabalhar num programa legado, resista à tentação de ir imediatamente para:

PROCEDURE DIVISION.

Leia o cabeçalho.

Leia os comentários.

Observe datas.

Procure padrões.

Veja quando determinadas rotinas apareceram.

Pergunte por que existe determinado layout.

Investigue aquele LRECL=80.

Observe os copybooks.

Descubra quem produz os arquivos.

Descubra quem os consome.

Veja JCL.

Procure dependências CICS, Db2, MQ, VSAM.

Leia antes de julgar.

O primeiro dever do arqueólogo não é cavar.

É compreender o terreno.


Epílogo — O próximo nome

Antes de sair do CPD, Guilherme voltou ao início do programa.

Havia espaço para uma nova inscrição.

O jovem havia terminado sua primeira manutenção importante.

Digitou:

*****************************************************************
* NOVO PROGRAMADOR
* 07/09/2026
* ADEQUACAO DA INTERFACE PARA NOVO SERVICO
*****************************************************************

Ficou olhando.

Acima dele havia nomes de pessoas que trabalharam naquele programa antes mesmo de ele nascer.

— Estranho — disse. — Parece que meu nome não deveria estar junto dos deles.

Guilherme respondeu:

— Agora compreendeu.

— O quê?

— A catedral nunca foi deles.

O jovem esperou.

— Tampouco é sua.

E então veio a lição final:

Você apenas recebeu a chave por algum tempo.

Talvez seja essa a melhor definição de trabalhar com sistemas legados.

Não somos proprietários absolutos deles.

Somos seus guardiões temporários.

Recebemos programas construídos por pessoas que não conhecemos.

Encontramos suas assinaturas entre asteriscos.

Descobrimos decisões tomadas quando computadores, empresas e o próprio mundo eram diferentes.

Preservamos o que ainda possui valor.

Corrigimos aquilo que envelheceu.

Retiramos aquilo que se tornou perigoso.

E acrescentamos as tecnologias da nossa época.

O pedreiro deixou sua marca.

O escultor deixou sua criatura fantástica.

O restaurador deixou um astronauta.

O programador de 1983 deixou COBOL.

O de 2003 deixou XML.

O de 2026 deixou JSON e uma API.

Algum outro, no futuro, acrescentará algo cujo nome ainda nem conhecemos.

E talvez, antes de modificar o programa, ele suba algumas páginas e encontre:

*****************************************************************
* V. BELLACOSA
* 2026
* ...
*****************************************************************

Não saberá exatamente quem foi aquele homem.

Talvez procure.

Talvez não.

Mas durante alguns segundos saberá uma coisa:

outro artesão trabalhou naquela pedra antes dele.

E é isso que torna o legado tão diferente de simplesmente possuir código antigo.

O legado não é aquilo que ficou velho.

Legado é aquilo que alguém construiu bem o bastante para chegar até nós — e que nós cuidamos bem o bastante para entregar ao próximo.

Os cartões desapareceram.

As perfuradoras silenciaram.

Os terminais mudaram.

As máquinas foram substituídas.

As linguagens ganharam companheiras.

Vieram bancos relacionais, mensagens, Web, XML, JSON, APIs, cloud e IA.

Mas em algum dataset ainda encontramos:

RECFM=FB
LRECL=80

E em algum fonte ainda encontramos:

*****************************************************************
* NOME
* DATA
* O QUE FOI FEITO
*****************************************************************

São duas inscrições da mesma civilização.

Uma conta como construíamos.

A outra conta quem construiu.

E enquanto aquela catedral continuar processando transações, calculando valores, movimentando negócios e terminando suas madrugadas com:

RC=0000

o sino continuará tocando.

Para os usuários, será apenas mais um processamento concluído.

Para quem aprendeu a ler as pedras, porém, haverá ali algo muito maior:

cinquenta anos de engenheiros, analistas, operadores e programadores dizendo silenciosamente através do código:

Nós estivemos aqui.



O Manual da Guilda do Programador Mainframe — Do Rank F ao Rank S

 
Bellacosa Mainframe e o manual para um dev programador cobol iniciante nas artes secretas do mainframe

Um Café no Bellacosa Mainframe

O Manual da Guilda do Programador Mainframe — Do Rank F ao Rank S

Ou: como COBOL, JCL, Db2, CICS, RACF, dumps, documentação, café, S0C7, SQLCODE -911, ICH408I, Technical Debt, Deadline e o Demon Lord Boleto transformaram uma carreira de TI no RPG mais longo que você jamais instalou

Existe um momento inesquecível na vida de todo programador mainframe.

Você recebe seu primeiro USERID.

Alguém lhe entrega uma senha temporária.

Você acessa uma tela preta.

No alto aparece algo que parece ter sido construído numa civilização anterior à invenção do mouse.

Você olha aquilo.

Aquilo olha para você.

Parabéns.

Você acaba de entrar na:


GUILDA DOS PROGRAMADORES MAINFRAME

Seu Rank atual:

F

Sua classe:

Novato

Experiência:

0 XP

Equipamento:

  • um notebook corporativo;

  • um USERID recém-criado;

  • uma senha que expirará no pior momento possível;

  • três PDFs;

  • acesso limitado;

  • nenhum conhecimento sobre produção;

  • uma caneca de café.

Sua primeira quest aparece:

ALTERE UMA MENSAGEM NUM PROGRAMA COBOL.

Dificuldade estimada:

Dificuldade percebida pelo novato:

⭐⭐⭐⭐⭐⭐⭐⭐⭐⭐

Você ainda não sabe, mas acabou de iniciar um dos RPGs profissionais mais longos existentes.

Não existe tela de Game Over.

Existe:

ABEND



1. Antes de começar: escolha sua classe

Nos RPGs tradicionais escolhemos Warrior, Mage, Cleric ou Rogue.

No Mainframe RPG também existem classes.

COBOL Developer — Warrior

Ataca problemas diretamente.

Sua arma principal é:

IF
   ...
ELSE
   ...
END-IF

Possui resistência extraordinária a sistemas com quarenta anos.

Fraqueza natural:

dados inválidos.


Db2 Specialist — Mage

Manipula entidades invisíveis chamadas tabelas, índices, packages e access paths.

Seu feitiço favorito:

SELECT

Seu feitiço proibido:

DELETE FROM TABELA;

sem WHERE.

Quando isso acontece, nem resurrection spell resolve facilmente.


CICS Specialist — Rogue

Extremamente rápido.

Trabalha em milissegundos.

Conhece transações, regions e resources.

Seu inimigo natural é alguém dizendo:

“CICS está lento.”

Sem fornecer nenhuma outra informação.


RACF Administrator — Paladin

Guardião das portas.

Decide quem entra.

Quem lê.

Quem altera.

Quem executa.

Seu poder supremo é dizer:

ACCESS DENIED.

Não importa se você é diretor, gerente, arquiteto ou primo do CEO.


System Programmer — Archmage

Classe misteriosa.

Habita regiões profundas do reino chamadas PARMLIB, PROCLIB e SYS1.

Fala palavras como:

IPL.

APF.

LPA.

SVC.

SMF.

WLM.

SMP/E.

Quando entra numa War Room, todos ficam um pouco mais tranquilos.

Ou mais preocupados.

Depende da expressão dele.



2. Rank F — O Novato

Você começa no Rank F.

Não sabe quase nada.

E isso é perfeitamente normal.

Seu primeiro grande aprendizado é descobrir que não saber não é um defeito inicial: é o estado padrão da profissão.

Quests do Rank F

  • acessar TSO/ISPF;

  • navegar entre datasets;

  • entender PDS e membros;

  • editar um programa COBOL;

  • compilar;

  • executar um JOB;

  • consultar SDSF;

  • descobrir por que o JOB não terminou;

  • aprender a diferença entre erro de compilação e ABEND;

  • entender que produção não é lugar para experiências criativas.

Equipamento inicial

Espada COBOL +1

Escudo JCL +1

Mapa ISPF +2

Poção Café +5 concentração

Pergaminho “Manual da Empresa” +10 confusão

Skill especial

ASK SENIOR

Cooldown:

depende do humor do senior.

É provavelmente a skill mais importante dessa fase.



3. O primeiro monstro: JCL ERROR

Você submete seu primeiro JOB.

Espera.

Nada.

Olha novamente.

Descobre uma mensagem.

O coração acelera.

Você pensa:

“Quebrei o mainframe.”

Não.

Provavelmente esqueceu uma vírgula.

Mas essa primeira batalha ensina uma regra fundamental:

Leia a mensagem de erro.

Parece óbvio.

Não é.

Programadores frequentemente passam vinte minutos imaginando teorias sofisticadas enquanto o sistema está dizendo exatamente o problema.

O aventureiro experiente aprende:

Primeiro leia o que o monstro escreveu.

Depois desembainhe a espada.



4. Rank E — Junior

Depois de algumas quests você sobe para Rank E.

Agora consegue fazer pequenas alterações sem supervisão constante.

Isso produz um fenômeno perigoso:

confiança.

Você começa a achar que entende o sistema.

O sistema percebe.

E envia seu primeiro boss.

S0C7


5. Boss #1 — S0C7, o Devorador de Dados

Você executa o programa.

Ele morre.

Na tela:

S0C7

O novato pergunta:

— O que significa?

O veterano responde:

— Data Exception.

Tradução RPG:

Você tentou tratar alguma coisa como número e aquilo discordou.

Talvez um campo numérico contenha dados inválidos.

Talvez exista problema de definição.

Talvez um movimento tenha colocado conteúdo inesperado numa área.

A batalha começa.

Armas contra S0C7

  • dump;

  • offset;

  • listing;

  • compile options;

  • análise dos dados;

  • conhecimento das PICs;

  • atenção.

XP recebido

+350 DEBUGGING

Achievement desbloqueado

“Meu primeiro ABEND.”

Todo programador mainframe deveria receber um badge por isso.


6. Rank D — Pleno em formação

Agora você começa a compreender que programa nenhum vive sozinho.

Seu COBOL conversa com:

Db2.

VSAM.

CICS.

MQ.

Arquivos.

Outros programas.

Jobs.

APIs.

Usuários.

E processos de negócio criados antes de você entrar na empresa.

Você acaba de desbloquear:

DEPENDENCY HELL

A dungeon aumentou.


7. A Party

Nenhum aventureiro sensato entra sozinho numa dungeon perigosa.

No mainframe também não deveria.

Sua party pode possuir:

COBOL Developer

Ataca o código.

DBA

Controla os dragões relacionais.

System Programmer

Manipula as forças fundamentais do z/OS.

Security Specialist

Possui as chaves do castelo.

Production Control

Conhece horários e dependências.

Business Analyst

Traduz a misteriosa linguagem dos usuários.

Support

Sabe onde os cadáveres estão enterrados.

A grande skill profissional aparece quando você percebe:

não precisa saber tudo; precisa saber quem sabe.

Isso vale mais XP do que decorar centenas de comandos.


8. Boss #2 — SQLCODE -911, o Senhor dos Locks

Você escreve SQL.

Testa.

Funciona.

Produção chega.

Então:

SQLCODE = -911

O monstro apareceu.

Rollback.

Deadlock.

Timeout.

Seu programa estava disputando recursos com outra coisa.

Você descobre que bancos de dados não são bibliotecas silenciosas.

São cidades.

Centenas ou milhares de transações querem acessar recursos simultaneamente.

Algumas leem.

Outras alteram.

Algumas seguram locks.

Outras esperam.

Até que Db2 olha para a situação e decide:

“Alguém precisa morrer.”

Parabéns.

Foi sua transação.

Skills necessárias

  • compreender COMMIT;

  • entender ROLLBACK;

  • conhecer locking;

  • investigar concorrência;

  • analisar tempo de transação;

  • compreender access paths;

  • conversar com DBA.

XP

+750 CONCURRENCY

Loot

Anel do COMMIT Frequente

Use com sabedoria.

Commit demais também pode trazer problemas.


9. Rank C — O profissional que começa a enxergar o sistema

Aqui ocorre uma transformação importante.

Você deixa de perguntar apenas:

“Onde está o erro?”

E começa a perguntar:

“Por que esse erro aconteceu?”

Essa mudança parece pequena.

Não é.

É a passagem de executor para analista.

O Rank F corrige o registro.

O Rank C pergunta quem gerou o registro errado.

O Rank F reinicia o JOB.

O Rank C pergunta por que ele falhou.

O Rank F libera espaço.

O Rank C pergunta por que o crescimento não foi previsto.

Você começa a combater causas, não apenas sintomas.


10. Boss #3 — ICH408I, o Guardião das Portas

Você executa alguma coisa.

Recebe:

ICH408I

Você tenta novamente.

ICH408I

Mais uma vez.

ICH408I

O RACF não muda de opinião porque você clicou três vezes.

Esse boss ensina uma das regras fundamentais de segurança:

autenticação não significa autorização.

Você conseguiu entrar no reino.

Isso não significa que pode abrir todas as portas.

Talvez seu USERID não tenha acesso.

Talvez o grupo esteja incorreto.

Talvez o perfil proteja o recurso.

Talvez você precise de READ.

UPDATE.

CONTROL.

ALTER.

E talvez você não devesse receber nenhum deles.

Arma recomendada

Não é:

“Me dê ALTER em tudo.”

A arma correta chama-se:

Least Privilege.

XP

+900 SECURITY

Achievement

“RACF disse não.”


11. Equipamentos raros

Com o tempo você começa a colecionar equipamentos.

Não são espadas.

São ferramentas.

Debugger

Item raro.

Permite observar o monstro antes que ele mate seu programa.

Git

Inventário dimensional.

Guarda versões anteriores das suas armas.

Pipeline CI/CD

Esteira mágica que transporta artefatos entre reinos.

Monitoramento

Olho de Sauron corporativo.

Idealmente usado para observar sistemas, não hobbits.

Logs

Pergaminhos proféticos.

Quase sempre possuem pistas.

Documentação

Item lendário.

Extremamente poderoso.

Raramente atualizado.


12. Rank B — Senior

Aqui surge uma coisa curiosa.

Você sabe muito mais.

Mas começa a dizer:

“Depende.”

O junior acha isso frustrante.

Ele pergunta:

— Qual é a melhor solução?

Senior:

— Depende.

— Qual banco devemos usar?

— Depende.

— Devemos fazer COMMIT aqui?

— Depende.

— Podemos colocar isso em produção?

O senior olha fixamente.

Depende muito.

Isso não é indecisão.

É percepção de contexto.

Quanto mais você aprende, mais percebe quantas variáveis existem.


13. Boss #4 — Deadline, o Senhor do Tempo

Nenhum treinamento prepara adequadamente para esse monstro.

Deadline possui habilidade especial:

TIME COMPRESSION

Projeto de seis meses.

Prazo:

três meses.

Depois:

dois.

Então alguém pergunta:

“Conseguimos entregar sexta?”

Você olha o calendário.

Hoje é quinta.

Ataques do Deadline

  • reunião de status;

  • daily adicional;

  • planilha vermelha;

  • “quick win”;

  • “só falta um detalhe”;

  • mudança de requisito;

  • reunião para discutir por que existem tantas reuniões.

Defesa

  • estimativa realista;

  • priorização;

  • gerenciamento de risco;

  • documentação;

  • comunicação;

  • coragem profissional para dizer:

“Não.”

Essa última é uma skill Rank A.


14. Boss #5 — Technical Debt, o Monstro que Alimentamos

Esse é diferente.

Ele não aparece repentinamente.

Nós o criamos.

Começa pequeno.

“Depois corrigimos.”

“É temporário.”

“Só para entrar em produção.”

“Na próxima release melhoramos.”

Cada frase adiciona HP ao monstro.

Cinco anos depois existe uma rotina de 8.000 linhas que ninguém quer tocar.

O comentário diz:

* TEMPORARIO - NAO REMOVER
* 2007

Estamos em 2026.

O temporário completou dezenove anos.

Pode votar.

😂

Technical Debt Level 80

Ataques:

  • manutenção cara;

  • regressões;

  • medo de mudança;

  • conhecimento concentrado;

  • documentação inexistente;

  • dependências misteriosas.

Fraqueza

Refactoring controlado.

Testes.

Documentação.

Automação.

Tempo.

Naturalmente, o Deadline Boss geralmente impede que você use essas armas.

Os dois trabalham juntos.


15. Rank A — Especialista

O especialista não é necessariamente quem conhece mais comandos.

É quem possui profundidade suficiente para compreender consequências.

Ele começa a enxergar sistemas como ecossistemas.

Uma alteração COBOL pode afetar Db2.

Db2 pode alterar tempo de resposta.

Tempo de resposta pode afetar CICS.

CICS pode afetar usuários.

Usuários podem afetar faturamento.

Faturamento pode afetar diretoria.

Diretoria pode afetar você.

Tudo está conectado.

Skill desbloqueada

SYSTEM THINKING +100


16. A Skill lendária: reconhecer padrões

Um jovem olha um incidente e vê:

ERROR

O especialista olha e pensa:

“Já vi algo parecido.”

Não exatamente aquilo.

Mas algo parecido.

Essa biblioteca mental foi construída durante milhares de horas.

Incidentes.

Projetos.

Erros.

Migrações.

Falhas.

Sucessos.

Madrugadas.

É uma espécie de machine learning biológico.

Dataset:

sua carreira.

Treinamento:

vinte anos.

Inference:

“Olha aquele job primeiro.”


17. O sorriso ninja

Então aparece uma ferramenta nova.

Nova release.

Interface redesenhada.

Cloud.

API.

IDE.

Pipeline.

Você nunca utilizou exatamente aquela versão.

Cliente pergunta:

— Você sabe fazer?

Você:

😎

— Sei.

Internamente:

🦋🦋🦋🦋

O que você realmente quis dizer foi:

“Conheço suficientemente bem esse tipo de problema para descobrir como essa versão resolveu mudar tudo.”

Isso não é necessariamente blefe.

É confiança na capacidade de aprender.

A skill chama-se:

RELEARN

Rank:

S


18. Rank S — Mestre da Guilda

Pouquíssimos chegam aqui no sentido verdadeiro.

Não é determinado por idade.

Nem apenas por certificações.

Rank S aparece quando conhecimento técnico, experiência, contexto, comunicação e capacidade de formar outras pessoas começam a trabalhar juntos.

O Mestre da Guilda não precisa resolver tudo pessoalmente.

Ele sabe organizar a batalha.

Pergunta:

— O que mudou?

— Quando começou?

— Qual impacto?

— Conseguimos reproduzir?

— Temos rollback?

— Quem conhece esse componente?

— Quais evidências temos?

Observe.

Nenhuma magia.

Somente método.


19. A árvore de Skills

Depois de muitos anos, uma árvore possível poderia parecer assim:

PROGRAMADOR MAINFRAME
│
├── COBOL
│   ├── Estruturas
│   ├── Arquivos
│   ├── Debugging
│   └── Performance
│
├── JCL
│   ├── JOB
│   ├── EXEC
│   ├── DD
│   └── Utilities
│
├── DATA
│   ├── VSAM
│   ├── Db2
│   └── IMS
│
├── ONLINE
│   └── CICS
│
├── INTEGRATION
│   ├── MQ
│   ├── APIs
│   └── z/OS Connect
│
├── SECURITY
│   └── RACF
│
├── DEVOPS
│   ├── Git
│   ├── CI/CD
│   └── Automation
│
└── VETERAN SKILLS
    ├── Debugging
    ├── Comunicação
    ├── Contexto
    ├── Mentoria
    ├── Pattern Recognition
    └── Relearn

A última árvore costuma ser a mais difícil.

Não existe curso de quatro horas para obter vinte anos de contexto.


20. Como ganhar XP de verdade

Nem todo XP vem de certificação.

Alguns dos maiores ganhos acontecem quando algo dá errado.

Quest: corrigir primeiro ABEND

+500 XP

Quest: resolver incidente em produção

+1.000 XP

Quest: admitir que sua alteração causou o incidente

+2.000 XP

Quest: documentar para ninguém repetir

+3.000 XP

Quest: ensinar um junior

+5.000 XP

Quest: impedir um incidente antes que aconteça

+10.000 XP

Curiosamente, essa última geralmente não recebe reconhecimento.

Porque nada aconteceu.

Esse é o paradoxo do bom profissional de infraestrutura.


21. Side quests

Durante sua carreira aparecem missões secundárias.

“Aprenda Python.”

“Conheça Cloud.”

“Faça certificação.”

“Estude APIs.”

“Aprenda Git.”

“Agora containers.”

“Agora IA.”

Você abre seu mapa.

Existem 847 quests pendentes.

E apenas 24 horas por dia.

Então desbloqueia uma habilidade fundamental:

SELECT QUEST

Não tente aprender tudo.

Escolha aquilo que aproxima você de algum objetivo.

Senão você passará a vida coletando XP sem terminar a campanha principal.


22. O item mais raro: Tempo

Dinheiro compra livros.

Cursos.

Computadores.

Certificações.

Mas existe um recurso que não pode ser farmado:

tempo.

Um curso gratuito de quarenta horas custa quarenta horas.

Talvez valha.

Talvez não.

O aventureiro Rank S aprende a perguntar:

“Este conhecimento vale o tempo necessário para adquiri-lo?”

Porque cada curso compete com trabalho, descanso, família, leitura, caminhada...

e anime.

Nunca esqueçamos o anime.


23. O chefão secreto: Síndrome do Impostor

Mesmo depois de milhares de XP aparece uma criatura invisível.

Ela sussurra:

“Você não sabe o suficiente.”

Tecnicamente ela está correta.

Ninguém sabe.

O problema está na conclusão seguinte:

“Portanto você não deveria estar aqui.”

Errado.

O especialista não é aquele que sabe tudo.

É aquele que desenvolveu métodos para lidar com aquilo que não sabe.

Essa distinção salva carreiras.


24. O Boss final

Depois de COBOL.

Depois de Db2.

Depois de CICS.

Depois de RACF.

Depois do S0C7.

Depois do -911.

Depois do ICH408I.

Depois do Deadline.

Depois do Technical Debt.

Você acredita estar preparado.

Então o céu escurece.

A música muda.

Surge uma criatura gigantesca.

HP:

Resistência:

100%

Respawn:

MENSAL

Nome:

BOLETO

O Demon Lord definitivo.


25. Boleto — Level 99

Você pode trocar de emprego.

Boleto acompanha.

Pode virar freelancer.

Ele encontra você.

Pode tornar-se consultor.

Ele escala junto.

Pode tirar férias.

Ele sabe onde você mora.

Sua habilidade suprema chama-se:

VENCIMENTO

Todo mês ele retorna.

Isso explica boa parte da economia da Guilda.

O aventureiro veterano pensa:

“Talvez eu pare de aceitar projetos.”

Boleto:

“Interessante.”

😂

E imediatamente aparece no LinkedIn:

COBOL/Db2 Senior Consultant — Immediate Start — 6 months.

O velho aventureiro olha para a espada pendurada na parede.

Suspira.

— Uma última quest.

Boleto sorri.

Ele já ouviu isso antes.


26. New Game+

Existe, porém, uma fase curiosa da carreira.

Depois de acumular conhecimento suficiente, você começa a ensinar.

E ensinar é uma espécie de:

NEW GAME+

Você retorna às primeiras dungeons.

Só que agora acompanha novos aventureiros.

O junior pergunta:

— O que é S0C7?

Você sorri.

Lembra do seu primeiro.

Explica.

Ele resolve.

Ganha XP.

E alguma coisa interessante acontece.

Você também ganha.

Porque ensinar força a organizar aquilo que anos de experiência deixaram intuitivo.

Talvez essa seja uma das formas mais bonitas de veterania.

Transformar cicatrizes em mapas para quem vem depois.


27. Easter Egg — o verdadeiro Rank S

Existe um segredo escondido neste manual.

Rank S não significa:

Super Senior.

Significa:

Sobrevivente.

Sobreviveu às mudanças.

Às releases.

Aos projetos.

Aos incidentes.

Às tecnologias “que acabariam com o mainframe”.

Às reorganizações.

Às ferramentas revolucionárias.

Às interfaces redesenhadas.

Às certificações.

Ao Ceifeiro Silencioso.

Ao Deadline.

Ao Technical Debt.

E, até agora...

ao Boleto.

Mas sobretudo sobreviveu sem perder completamente uma coisa:

curiosidade.

Porque quando a curiosidade morre, estudar vira apenas obrigação.

E uma carreira tecnológica sem vontade de descobrir coisas novas transforma cada atualização numa punição.


28. A regra de ouro da Guilda

Se eu tivesse que entregar somente uma regra ao programador começando hoje, seria:

Aprenda fundamentos profundamente e ferramentas suficientemente.

Ferramentas mudam.

Interfaces mudam.

Versões desaparecem.

Menus migram.

Produtos são renomeados.

Mas compreender transações, dados, concorrência, segurança, arquitetura, debugging e sistemas continuará permitindo que você reconheça os mesmos monstros usando roupas diferentes.

O goblin de 1998 pode aparecer em 2027 com Kubernetes, API REST e inteligência artificial.

Continua sendo goblin.

Só ganhou marketing.


Epílogo — A próxima quest

03:17.

Telefone toca.

Produção está parada.

Um jovem Rank F olha assustado para o terminal.

Ao lado dele existe um veterano Rank S.

— O que faço?

O veterano coloca a caneca de café sobre a mesa.

— Primeiro, não faça nada.

— Como assim?

— Leia.

Eles olham os logs.

O jovem encontra uma mensagem:

ICH408I

— RACF?

O veterano sorri.

— Talvez.

— Você não sabe?

— Ainda não.

O jovem estranha.

Aquele homem possui décadas de experiência.

Como pode responder “não sei”?

O veterano continua:

— Vamos descobrir.

Nesse instante o jovem aprende uma coisa muito maior do que RACF.

Descobre o verdadeiro significado de experiência.

Não é possuir todas as respostas.

É não precisar fingir que possui.

É saber investigar.

Saber testar.

Saber pedir ajuda.

Saber voltar atrás.

Saber diferenciar evidência de palpite.

Saber quando agir.

E, talvez ainda mais importante...

saber quando não agir.

Alguns minutos depois encontram a causa.

04:02.

Produção retorna.

O jovem sorri.

QUEST COMPLETE

+1.000 XP

SKILL UNLOCKED: INCIDENT ANALYSIS

Ele pergunta:

— Um dia chego ao Rank S?

O veterano pega novamente o café.

— Se continuar estudando.

— Só isso?

— Não.

— Trabalhando?

— Também.

— Então como?

O veterano olha para a enorme sala de máquinas.

COBOL continuará executando.

Db2 continuará protegendo dados.

CICS continuará processando transações.

RACF continuará dizendo não.

S0C7 continuará encontrando campos impossíveis.

SQLCODE -911 continuará lembrando que ninguém trabalha sozinho.

Deadline continuará correndo.

Technical Debt continuará crescendo escondido.

Novas ferramentas chegarão.

Interfaces serão redesenhadas.

E o Boleto...

Bem.

O Boleto jamais será descontinuado.

Ele coloca a mão no ombro do novato.

— Continue entrando nas dungeons.

— Mesmo com medo?

O veterano abre o famoso sorriso ninja.

😎

— Principalmente quando houver algumas borboletas.

O jovem olha novamente para o terminal.

No canto inferior aparece:

READY

A próxima quest já está esperando.

Um Café no Bellacosa Mainframe

Mesmos sistemas. Novas histórias. Sempre um bom café.

Ficha final do personagem

Classe: Programador Mainframe
Rank inicial: F
Rank máximo: S
Arma: Conhecimento
Escudo: Experiência
Poção: Café
Mapa: Documentação
Party: Equipe
Skill lendária: Reaprender
Fraqueza: “É só uma alteraçãozinha”
Boss recorrente: Deadline
Boss ancestral: Technical Debt
Demon Lord: Boleto
Achievement final: Ainda curioso depois de décadas
Próxima missão: READY >

Para saber mais

https://eljefemidnightlunch.blogspot.com/2026/09/a-guilda-dos-aventureiros-mainframe-por.html



Vagner Renato Bellacosa, IBM Champion e especialista em IBM Mainframe
IBM Z17 SYSTEM ONLINE
Sobre o autor

Vagner Renato Bellacosa

IBM Champion 2026 • Especialista em IBM Mainframe

Vagner Renato Bellacosa trabalha com IBM Mainframe desde 1988 , é IBM Champion e especialista em COBOL, CICS, Db2, z/OS e IBM Z. Compartilha experiências profissionais, conhecimento técnico, história da computação e práticas do universo mainframe para aproximar novas gerações das tecnologias que sustentam empresas, bancos e governos ao redor do mundo.

IBM Champion IBM Z COBOL CICS Db2 z/OS Mainframe desde 1988
GitHub LinkedIn
Inicializando conteúdo...