☕ 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

quinta-feira, 12 de junho de 2025

COBOL: de 1959 até hoje — quando o código atravessa décadas sem pedir aposentadoria.

 

💾 EL JEFE MIDNIGHT LUNCH — Bellacosa Mainframe Chronicles

“COBOL: de 1959 até hoje — quando o código atravessa décadas sem pedir aposentadoria.”


Há linguagens que nascem modinha.
Há linguagens que viram tese acadêmica.
E há o COBOL, que nasceu em 1959 e simplesmente se recusou a morrer — porque alguém precisava rodar o mundo real: folha, banco, seguro, governo, avião no ar e salário no fim do mês.

Hoje vamos fazer uma linha do tempo completa do COBOL no Mainframe, do nariz de foguete dos anos 50 até o Enterprise COBOL moderno, com comentários, curiosidades, easter eggs e aquele café forte do Bellacosa Mainframe.

Senta que lá vem história. ☕




🕰️ 1959 — COBOL nasce

COBOL (Common Business-Oriented Language)
Criado por um comitê liderado por Charles A. Phillips e Joseph Wegstein. 


🔹 O que havia de novo:

  • Linguagem quase em inglês

  • Pensada em humanos e não técnicos de informatica.

  • Foco em negócios, não em matemática

  • Independência de hardware (uma heresia para a época)

🔹 Equipe criadora do COBOL, listagem não exaustiva:

Alfred Asch (U.S. Air Force)
Benjamin Cheydleur (RCA)
Charles Gaudette (Minneapolis-Honeywell)
Daniel Goldstein (Univac)
Frances “Betty” Holberton (David Taylor Model Basin)
Gertrude Tierney (IBM)
Howard Bromberg (RCA)
Jean Sammet (Sylvania)
Joseph Wegstein (National Bureau of Standards)
Mary Hawes (Burroughs)
Norman Discount (RCA)
Vernon Reeves (Sylvania)
William Logan (Burroughs)
William Selden (IBM)

🧠 Curiosidade:
Grace Hopper odiava linguagens “ilegíveis”. O COBOL nasceu para ser lido por gerentes — ironicamente, só programadores entendem até hoje.

🥚 Easter egg:
O verbo ADD A TO B GIVING C é praticamente poesia corporativa.





🕰️ 1968 — COBOL ANSI 68

Primeira padronização oficial.

🔹 Novidades:

  • Estrutura formal

  • Maior portabilidade

  • Divisão clara em IDENTIFICATION, ENVIRONMENT, DATA e PROCEDURE

🧠 Comentário Bellacosa:
Aqui o COBOL virou “linguagem séria”. Antes era festa; depois, contrato.




🕰️ 1974 — COBOL ANSI 74

A versão que dominou os mainframes por décadas.

🔹 Novidades:

  • IF/ELSE estruturado

  • PERFORM mais poderoso

  • Adeus aos GO TO anárquicos (ou quase)

🧠 Curiosidade:
Boa parte do código que rodou no Y2K ainda era ANSI 74.




🕰️ 1985 — COBOL ANSI 85

O COBOL aprende boas maneiras.

🔹 Novidades:

  • Scope terminators (END-IF, END-PERFORM)

  • Código mais legível

  • Base do COBOL “estruturado”

🥚 Easter egg:
Muita gente ainda hoje esquece o END-IF e culpa o compilador.


🕰️ Anos 80 — COBOL VS / VS II (IBM)

O COBOL entra no reino do MVS.

🔹 Novidades:

  • Integração forte com JCL

  • Batch pesado

  • Performance absurda para a época

🧠 Comentário Bellacosa:
Aqui o COBOL virou músculo. Forte, bruto e confiável.


🕰️ 1991 — COBOL/370

Primeiro grande passo rumo ao “Enterprise”.

🔹 Novidades:

  • Melhor otimização

  • Suporte avançado a CICS e DB2

  • Integração com arquitetura System/370


🕰️ 1994 — Enterprise COBOL 3.2

🔥 Marco histórico.

🔹 O que há de novo:

  • Language Environment (LE)

  • Runtime comum com PL/I e C

  • Otimização real de código

🧠 Curiosidade:
Muitos chamam o LE de “chatice”. Até o primeiro dump bem explicado salvar seu emprego.

🥚 Easter egg:
CEE3ABD virou melhor amigo de quem debuga madrugada.


🕰️ 1996 — Enterprise COBOL 3.3

O compilador do Bug do Milênio.

🔹 Novidades:

  • Melhor I/O

  • Mais estabilidade

  • Código gerado mais rápido

🧠 Comentário Bellacosa:
Se o mundo não acabou em 01/01/2000, agradeça ao COBOL 3.3.


🕰️ 2001 — Enterprise COBOL 3.1 (z/OS)

Transição definitiva para o z/OS.

🔹 Novidades:

  • Unicode (primeiros passos)

  • Melhor integração com ambientes modernos

  • Visão “enterprise de verdade”

🧠 Curiosidade:
Aqui o COBOL começou a flertar com XML… timidamente.


🕰️ 2007 — Enterprise COBOL 4.1

O salto tecnológico.

🔹 Novidades:

  • Arquitetura 64 bits

  • Suporte a XML nativo

  • Melhor interoperabilidade

🥚 Easter egg:
Muita gente demorou anos para sair do 3.3 por medo.


🕰️ 2010 — Enterprise COBOL 5.1

COBOL moderno sem pedir desculpas.

🔹 Novidades:

  • Performance absurda

  • Melhor otimização para hardware z

  • Preparação para serviços

🧠 Comentário Bellacosa:
Aqui o COBOL começa a humilhar linguagens modernas em benchmark.


🕰️ 2016 — Enterprise COBOL 6.1

O COBOL acorda para o século XXI.

🔹 Novidades:

  • Melhor uso de CPU

  • Integração com DevOps

  • Compilador mais inteligente

🥚 Easter egg:
Compila mais rápido, roda mais rápido… e ainda reclamam.


🕰️ 2019–2022 — Enterprise COBOL 6.2 / 6.3 / 6.4

O COBOL sem vergonha de ser moderno.

🔹 Novidades:

  • Melhor suporte a APIs

  • Integração com pipelines

  • Foco em cloud híbrida e z/OS Connect

🧠 Curiosidade:
COBOL virou backend de API REST. Sim, isso é real.


🕰️ 2023–2025 — Enterprise COBOL 6.5 (atual)

O COBOL que ri do etarismo.

🔹 O que há de novo:

  • Performance ainda maior

  • Melhor diagnóstico

  • Alinhamento com z/OS moderno, containers e automação

  • Funções intrínsecas criadas pelo programador

🧠 Comentário Bellacosa:
Enquanto discutem se COBOL morreu, ele roda bilhões de transações por dia.


☕ Conclusão Bellacosa Mainframe

COBOL não sobreviveu apesar do tempo.
Ele sobreviveu porque o tempo precisava dele.

De 1959 até hoje:

  • Mudou

  • Evoluiu

  • Aprendeu XML, API, DevOps, Unicode e JSON
    Mas nunca perdeu seu propósito: fazer o negócio rodar.

“COBOL não é velho.
Velho é sistema que cai.”
— El Jefe Midnight Lunch



Fonte: https://www.ibm.com/docs/pt-br/cobol-zos/6.5.0?topic=overview-cobol-compiler-versions-required-runtimes-support-information 


Tabela 1. Nomes de compiladores COBOL, versões e releases, identificadores de produtos, datas GA e EOS e tempos de execução necessários
Compilador
Versão, liberação e nível de modificação
Identificador de produto (PID)
Data de disponibilidade geral (GA)
(Ano-Mês-Dia)
Data do fim do suporte (EOS)1
(Ano-Mês-Dia)
Tempos de execução necessários2
OS/VS COBOL1.2.1----
OS/VS COBOL1.2.2----
OS/VS COBOL1.2.35740-CB11974-09-231999-12-31
  • Biblioteca de tempo de execução COBOL OS/VS; ou
  • Biblioteca de tempo de execução do VS COBOL II; ou
  • z/OS Language Environment
OS/VS COBOL1.2.45740-CB11976-09-231999-12-31
  • Biblioteca de tempo de execução COBOL OS/VS; ou
  • Biblioteca de tempo de execução do VS COBOL II; ou
  • z/OS Language Environment
VS COBOL II1.15668-9581985-10-011997-06-30
  • Biblioteca de tempo de execução do VS COBOL II; ou
  • z/OS Language Environment
VS COBOL II1.25668-9581986-12-191997-06-30
  • Biblioteca de tempo de execução do VS COBOL II; ou
  • z/OS Language Environment
VS COBOL II1.335668-9581988-12-161996-06-30
  • Biblioteca de tempo de execução do VS COBOL II; ou
  • z/OS Language Environment
VS COBOL II1.435668-9581993-03-122001-03-31
  • Biblioteca de tempo de execução do VS COBOL II; ou
  • z/OS Language Environment
COBOL/370
1.15688-1971991-12-201997-09-30z/OS Language Environment
COBOL para MVS & VM
1.25688-1971995-10-272001-12-31z/OS Language Environment
COBOL for OS/390® & VM
2.135648-A251997-05-232004-12-31z/OS Language Environment
COBOL for OS/390 & VM
2.235648-A252000-09-292004-12-31z/OS Language Environment
Enterprise COBOL for z/OS®
3.15655-G532001-11-302004-04z/OS Language Environment
Enterprise COBOL for z/OS
3.25655-G532002-09-272005-10-03z/OS Language Environment
Enterprise COBOL para z/OS
3.35655-G532004-02-272007-04-30z/OS Language Environment
Enterprise COBOL para z/OS
3.45655-G532005-07-012015-04-30z/OS Language Environment
Enterprise COBOL para z/OS
4.15655-S712007-12-142014-04-30z/OS Language Environment
Enterprise COBOL para z/OS
4.25655-S712009-08-282022-04-30z/OS Language Environment
Enterprise COBOL para z/OS
5.15655-W322013-06-212020-04-30z/OS Language Environment
Enterprise COBOL para z/OS
5.25655-W322015 -02-272020-04-30z/OS Language Environment
Enterprise COBOL para z/OS
6.15655-EC62016-03-182022-09-30z/OS Language Environment
Enterprise COBOL para z/OS
6.25655-EC62017-09-082024-09-30z/OS Language Environment
Enterprise COBOL para z/OS
6.35655-EC62019-09-062025-09-30z/OS Language Environment
Enterprise COBOL 
Enterprise COBOL para z/OS
6.45655-EC62022-05-27A ser determinadoz/OS Language Environment
Enterprise COBOL para z/OS
6.55655-EC62025-06-13A ser determinadoz/OS Language Environment

 

quarta-feira, 11 de junho de 2025

Laboratório Prático de Java para IBM Mainframe 20 Labs para Transformar um Programador COBOL em um Desenvolvedor Java para IBM Z

 

Bellacosa Mainframe e um laboratorio java para mainframers

☕ Um Café no Bellacosa Mainframe

Laboratório Prático de Java para IBM Mainframe

Metodologia do Laboratório

Este laboratório foi desenvolvido para programadores COBOL iniciantes no ecossistema IBM Z, utilizando uma metodologia prática baseada no conceito learning by doing (aprender fazendo). Em vez de ensinar Java de forma isolada, cada conceito é apresentado em paralelo com tecnologias já conhecidas pelo desenvolvedor Mainframe, como COBOL, JCL, CICS, DB2, VSAM e z/OS. Dessa forma, o aluno estabelece uma associação natural entre os dois ambientes, reduzindo a curva de aprendizado e compreendendo como ambas as linguagens coexistem na arquitetura corporativa moderna.

Os vinte laboratórios evoluem gradualmente, começando pelos fundamentos da linguagem Java, passando por orientação a objetos, tratamento de exceções, coleções, acesso ao DB2 via JDBC, processamento Batch, APIs REST, WebSphere Liberty, IBM MQ, z/OS Connect, automação com Ansible, DevOps, LinuxONE e containers. Cada exercício apresenta objetivos claros, arquitetura, código comentado, desafios práticos e solução completa.

Ao final do treinamento, espera-se que o desenvolvedor compreenda o papel estratégico do Java no IBM Z e no LinuxONE, saiba como a JVM é executada nessas plataformas, desenvolva aplicações Batch e Online, integre serviços Java com programas COBOL e DB2, automatize processos utilizando ferramentas modernas e participe de projetos de modernização sem abandonar os sólidos fundamentos do Mainframe. O objetivo não é substituir o COBOL, mas formar profissionais capazes de transitar com segurança por todo o ecossistema IBM Z.

20 Labs para Transformar um Programador COBOL em um Desenvolvedor Java para IBM Z

Objetivo: Capacitar um programador COBOL Junior a compreender como o Java funciona dentro do ecossistema IBM Z, sempre relacionando os novos conceitos com aquilo que ele já conhece em COBOL, JCL, CICS e DB2.


Filosofia do Laboratório

Este não é um curso tradicional de Java.

É um curso pensado para quem já conhece Mainframe.

Durante todos os exercícios faremos comparações entre:

  • COBOL × Java

  • JCL × JVM

  • CICS × Liberty

  • SQL Embutido × JDBC

  • VSAM × Collections

  • Batch × Java Batch

  • Online CICS × REST APIs

O objetivo é diminuir o choque entre os dois mundos.


Ambiente sugerido

Desenvolvimento

  • VS Code

  • IBM Z Open Editor

  • Java 21 LTS

  • Maven

  • Git

  • Zowe CLI

Mainframe

  • IBM z/OS

  • USS (Unix System Services)

  • Enterprise COBOL

  • DB2

  • CICS TS

  • z/OS Connect

  • IBM MQ

  • WebSphere Liberty

Opcional

  • LinuxONE

  • Docker

  • OpenShift

  • Ansible


LAB 01 — Primeiro Programa Java

Objetivo

Criar o famoso Hello World.

O que aprender

  • Classe

  • Método main()

  • JVM

  • Compilação

Exercício

Criar

HelloMainframe.java

Executar

javac HelloMainframe.java

java HelloMainframe

Solução

Exibir

Olá IBM Z

LAB 02 — Comparando COBOL e Java

Objetivo

Criar um programa que recebe nome e idade.

Comparar com

WORKING-STORAGE
DISPLAY
ACCEPT

Aprender

  • Scanner

  • Variáveis

  • String

  • int

Solução

Programa imprime

Olá João

Você possui 30 anos

LAB 03 — Estruturas de Decisão

Comparar

COBOL

IF
ELSE
END-IF

com

Java

if

else

Exercício

Calcular maioridade.


LAB 04 — Estruturas de Repetição

Comparar

PERFORM UNTIL

com

for

while

Exercício

Exibir números de 1 a 100.


LAB 05 — Métodos

Comparar

SECTION

PARAGRAPH

com

Métodos Java

Criar método

calcularIR()

LAB 06 — Orientação a Objetos

Primeiro contato.

Criar

Cliente
Conta

Banco

Aprender

  • classe

  • objeto

  • atributos

  • métodos


LAB 07 — Collections

Comparar

Tabela OCCURS

com

ArrayList

Exercício

Cadastrar clientes.


LAB 08 — Tratamento de Exceções

Comparar

IF SQLCODE

IF FILE STATUS

com

try

catch

Gerar erro proposital.

Capturar erro.


LAB 09 — Leitura de Arquivos

Comparar

Sequential File

com

BufferedReader

Ler arquivo

CLIENTES.TXT

LAB 10 — Escrevendo Arquivos

Criar

RELATORIO.TXT

Comparar

WRITE

com

FileWriter.


LAB 11 — JDBC + DB2

Objetivo

Primeira conexão com DB2.

Aprender

  • Driver JDBC

  • Connection

  • Statement

  • ResultSet

Consulta

SELECT *

CLIENTE

Solução

Exibir registros na tela.


LAB 12 — PreparedStatement

Comparar

EXEC SQL

com

PreparedStatement

Inserir cliente.

Depois atualizar.

Depois excluir.


LAB 13 — Java Batch

Criar um processamento Batch.

Fluxo

Ler Arquivo

↓

Validar

↓

Atualizar DB2

↓

Gerar Relatório

Executar usando JCL.


LAB 14 — Java no USS

Entrar no Unix System Services.

Executar

java

javac

jar

Aprender

  • PATH

  • JAVA_HOME

  • CLASSPATH


LAB 15 — WebSphere Liberty

Criar primeira aplicação.

Executar

localhost:9080

Primeira API REST.


LAB 16 — Java + MQ

Criar

Produtor

Consumidor

Enviar mensagens.

Comparar com Batch desacoplado.


LAB 17 — Java + CICS

Criar aplicação Java.

Consumir programa COBOL.

Fluxo

Java

↓

CICS

↓

COBOL

Entender integração.


LAB 18 — Java + z/OS Connect

Criar API REST.

Consumir programa COBOL.

Resultado

GET

/clientes

Retorna

JSON.


LAB 19 — Deploy Automatizado

Criar Pipeline.

Ferramentas

  • Git

  • Maven

  • Jenkins

  • Zowe

  • Ansible

Deploy automático.


LAB 20 — Projeto Final

Sistema Bancário Completo

Arquitetura

Cliente

↓

REST API

↓

Spring Boot

↓

Liberty

↓

MQ

↓

CICS

↓

COBOL

↓

DB2

O Projeto

Cadastrar clientes.

Consultar clientes.

Atualizar clientes.

Excluir clientes.

Gerar relatório Batch.

Consultar API REST.

Executar deploy automático.


Estrutura sugerida

MainframeJavaLabs

│

├── Lab01_HelloJava

├── Lab02_Variaveis

├── Lab03_IF

├── Lab04_FOR

├── Lab05_Metodos

├── Lab06_OO

├── Lab07_Collections

├── Lab08_Exceptions

├── Lab09_Arquivos

├── Lab10_FileWriter

├── Lab11_JDBC

├── Lab12_PreparedStatement

├── Lab13_JavaBatch

├── Lab14_USS

├── Lab15_Liberty

├── Lab16_MQ

├── Lab17_CICS

├── Lab18_zOSConnect

├── Lab19_Ansible

└── Lab20_ProjetoFinal

O que cada laboratório deve conter

Para que o aprendizado seja realmente prático, todos os 20 laboratórios devem seguir a mesma estrutura:

  • Objetivo: o que será aprendido e por que isso é importante no IBM Z.

  • Conceitos COBOL equivalentes: comparação direta entre os conceitos de COBOL e Java.

  • Arquitetura: diagrama do fluxo da aplicação.

  • Pré-requisitos: softwares, datasets, tabelas DB2 ou configurações necessárias.

  • Passo a passo: instruções detalhadas de implementação.

  • Código comentado: explicando cada linha e sua função.

  • Compilação e execução: tanto no ambiente local quanto no z/OS, quando aplicável.

  • Análise dos resultados: como validar se tudo funcionou corretamente.

  • Desafios extras: exercícios para expandir o laboratório.

  • Solução completa: código-fonte, JCL, scripts Maven/Gradle, SQL e arquivos de configuração.

Competências desenvolvidas

Ao concluir os 20 laboratórios, o programador COBOL Junior terá desenvolvido competências para:

  • Escrever aplicações Java orientadas a objetos.

  • Compreender a execução da JVM no IBM Z.

  • Criar programas Batch em Java executados por JCL.

  • Desenvolver APIs REST com Spring Boot e WebSphere Liberty.

  • Integrar aplicações Java com programas COBOL via CICS e z/OS Connect.

  • Acessar tabelas DB2 utilizando JDBC e PreparedStatement.

  • Utilizar IBM MQ para comunicação assíncrona.

  • Trabalhar com USS (Unix System Services).

  • Automatizar builds e deploys com Maven, Git, Jenkins, Zowe e Ansible.

  • Entender o papel do LinuxONE, Docker e OpenShift na modernização do ecossistema IBM Z.

Resultado esperado

Ao final desse laboratório, o aluno deixará de enxergar Java como uma tecnologia "concorrente" do COBOL. Em vez disso, compreenderá como ambas as linguagens coexistem no IBM Z, cada uma exercendo um papel específico na arquitetura corporativa moderna. Esse conhecimento amplia significativamente as oportunidades profissionais e prepara o desenvolvedor para atuar em projetos de modernização, integração por APIs e DevOps, mantendo o COBOL como o coração das regras de negócio e o Java como a ponte entre o Mainframe e o restante do mundo.


terça-feira, 10 de junho de 2025

Leões que Nunca Foram Leões — o text-to-image medieval e os monstros que nasceram quando ninguém tinha fotografia

 

Bellacosa Mainframe e os leoes que nunca foram leoes outra alucinação medieval

☕ Um Café no Bellacosa Mainframe

Leões que Nunca Foram Leões — o text-to-image medieval e os monstros que nasceram quando ninguém tinha fotografia

🦁 O escultor nunca viu um leão. O monge conhecia alguém que tinha lido sobre um. O viajante jurava que era enorme. O padre precisava da escultura pronta. E assim nasceu uma criatura que não existia na natureza — mas que durante séculos todo mundo reconheceu perfeitamente como um leão.

Existe uma experiência extraordinária reservada a quem entra em muitas igrejas antigas da Europa.

Depois da décima igreja, você começa a perceber os animais.

Depois da vigésima, começa a prestar atenção neles.

Depois da quinquagésima, surge uma pergunta inevitável:

Que diabo de animal é esse?

A placa responde:

LEÃO.

Você olha novamente.

Não.

Aquilo definitivamente não parece um leão.

Parece um cachorro que encontrou um urso numa noite particularmente irresponsável, teve descendentes com uma criatura mitológica e posteriormente contratou um cabeleireiro medieval.

Mas é um leão.

O catálogo diz que é um leão.

O guia diz que é um leão.

O historiador da arte diz que é um leão.

E, principalmente:

para as pessoas que olharam aquela escultura durante séculos, aquilo ERA um leão.

Foi caminhando por igrejas do interior da Itália que essa percepção começou a me divertir.

Alguns leões são convincentes.

Outros exigem boa vontade.

Alguns exigem imaginação.

E existem aqueles diante dos quais você precisa ativar:

SUSPENSION_OF_DISBELIEF=YES

para finalmente exclamar:

— Ahhhh... claro. Leão.

☕😆

Só que existe algo profundamente interessante escondido naquela criatura torta de pedra.

Talvez o escultor nunca tivesse visto um leão.

Talvez seu mestre também não.

Talvez o sujeito que desenhou a imagem utilizada como referência também não.

Mesmo assim, todos sabiam perfeitamente como um leão deveria parecer.

E aqui começa nossa história.



🦁 Giovanni recebe um ticket

Imagine uma pequena cidade italiana no século XII.

Uma igreja está sendo construída.

Precisamos de um portal.

Colunas.

Capitéis.

Santos.

Demônios.

Folhagens.

E dois leões.

O mestre chama Giovanni.

— Giovanni!

— Sim?

— Precisamos de dois leões sustentando as colunas.

— Certo.

Silêncio.

Giovanni olha para o bloco de pedra.

Depois pergunta:

— Como é um leão?

Outro silêncio.

Alguém procura um manuscrito.

Aparece uma iluminura.

O desenho mostra algo vagamente parecido com:

cachorro + juba + dentes + cauda estranha.

Giovanni observa.

TICKET #1187

REQUEST:
ESCULPIR LEÃO

REQUIREMENTS:
4 patas
1 cauda
muitos dentes
juba
aparência feroz

REFERENCE:
MANUSCRIPT.LION.V3

HAS ARTIST SEEN REAL LION?
NO

DEADLINE:
FRIDAY

Giovanni começa a trabalhar.

Martelo.

Cinzel.

Poeira.

Alguns meses depois temos:

LEÃO v4.0.

A comunidade olha.

— Magnífico!

Ninguém reclama.

Por quê?

Porque o objetivo não era necessariamente produzir uma ilustração zoológica.

O objetivo era produzir algo que dissesse:

LEÃO.


🧠 Reconhecer não é a mesma coisa que reproduzir

Essa diferença é fundamental.

Nós, em 2026, estamos contaminados pela fotografia.

Temos uma expectativa relativamente recente:

uma representação deve parecer visualmente com aquilo que representa.

Mas isso não é obrigatório para que símbolos funcionem.

Veja:

❤️

Isso significa coração.

Mas abra um livro de anatomia.

O coração humano não parece com isso.

Nem um pouco.

Mesmo assim:

❤️ = HEART

RETURN CODE = 0

A representação funciona.

Portanto, quando encontramos um estranho cachorro cabeludo esculpido numa igreja medieval, talvez estejamos fazendo a pergunta errada:

“Por que eles representaram tão mal um leão?”

Talvez a pergunta correta seja:

“Quais características eram suficientes para que aquela sociedade reconhecesse essa criatura como leão?”

Juba?

Dentes?

Garras?

Força?

Ferocidade?

Posição heráldica?

Contexto religioso?

Se esses elementos estivessem presentes, talvez a anatomia fosse apenas detalhe de implementação.


⛪ Porque o leão da igreja não era somente um leão

Nas igrejas medievais, o animal frequentemente carregava significado simbólico.

O leão podia representar:

força,

autoridade,

vigilância,

realeza,

proteção,

Cristo,

São Marcos,

ou, dependendo do contexto, ameaça e ferocidade.

Ou seja:

CLASS LION

ATTRIBUTES:
POWER
AUTHORITY
FEROCITY
VIGILANCE
MAJESTY

Ninguém pediu:

SPECIES:
Panthera leo

ANATOMICAL_ACCURACY:
99.7%

O leão era uma interface simbólica.

E interfaces não precisam reproduzir aquilo que representam.

O ícone da lixeira do computador também não contém lixo.

Mesmo assim sabemos exatamente o que acontece quando clicamos nele.


📚 Então aparecem os bestiários

Agora nossa história fica maravilhosa.

Durante a Idade Média circularam pela Europa os chamados bestiários.

Eles não eram simplesmente livros de zoologia.

Misturavam:

animais reais,

descrições herdadas da Antiguidade,

interpretações religiosas,

moralidade,

alegorias,

histórias de viajantes,

e criaturas que hoje classificaríamos como fantásticas.

O animal não estava ali apenas para ser estudado.

Estava ali para ensinar alguma coisa sobre o mundo, Deus e o comportamento humano.

O leão podia representar Cristo.

A raposa, astúcia.

O pelicano ganhou uma tradição simbólica extraordinária.

Outros animais carregavam virtudes, pecados e ensinamentos.

E então começam a aparecer criaturas...

interessantes.

Muito interessantes.


🐉 Bem-vindo ao Monster Manual medieval

Abra determinados manuscritos e você encontrará um universo que parece precursor direto de:

Dungeons & Dragons.

Dragões.

Basiliscos.

Unicórnios.

Sereias.

Grifos.

Serpentes monstruosas.

Homens com características extraordinárias.

Povos fantásticos vivendo nos limites do mundo conhecido.

E aqui surge uma tentação moderna:

“Esses medievais acreditavam em qualquer bobagem.”

Calma.

A relação entre literatura, alegoria, autoridade antiga, tradição e crença era muito mais complicada.

Além disso, existe um problema gigantesco:

como você verifica uma história sobre um animal que vive a 5.000 quilômetros de distância quando viajar até lá pode levar anos?

Google ainda estava com lançamento atrasado.


🌍 “Meu primo conhece um mercador que falou com um marinheiro...”

Imagine a cadeia de informação.

Um viajante observa um animal na África.

Ele retorna ao Mediterrâneo.

Conta para um mercador.

O mercador conta para outro.

A história atravessa um porto.

Depois outro.

É traduzida.

Um escriba registra.

Outro copia.

Finalmente chega a um ilustrador.

ANIMAL REAL
    ↓
TESTEMUNHA
    ↓
MEMÓRIA
    ↓
RELATO
    ↓
TRADUÇÃO
    ↓
OUTRO RELATO
    ↓
MANUSCRITO
    ↓
ILUSTRADOR

Quantos bits sobreviveram?

😆

É o equivalente medieval de pegar uma fotografia, salvar como JPEG, abrir, tirar screenshot, mandar pelo WhatsApp, imprimir, fotografar a impressão e repetir isso durante 300 anos.

Uma hora o checksum vai reclamar.


🗣️ E palavras são perigosíssimas

Imagine alguém descrevendo:

“É parecido com um cavalo, mas possui um grande chifre.”

Você nunca viu o animal.

Seu dataset contém:

cavalo,

boi,

cabra,

veado.

Você precisa desenhar.

O que faz?

HORSE
+
HORN
=
???

Unicórnio.

BUILD SUCCESSFUL.

🤣

Isso não significa que a origem histórica do unicórnio possa ser reduzida simplesmente a alguém descrevendo um rinoceronte — tradições sobre animais de um só chifre são muito mais antigas e complexas.

Mas demonstra perfeitamente o mecanismo:

uma descrição verdadeira pode produzir uma imagem falsa sem que ninguém esteja mentindo.

Essa frase merece café.


🦏 Nosso velho amigo Dürer retorna

Foi exatamente por isso que o rinoceronte de Albrecht Dürer é tão maravilhoso.

Em 1515 um rinoceronte-indiano verdadeiro chegou a Lisboa.

Dürer estava em Nuremberg.

Nunca viu o animal.

Recebeu informações e uma representação anterior.

E produziu sua famosa xilogravura.

O resultado:

um rinoceronte que parece usar armadura.

Placas.

Texturas.

Dobras.

Até uma estrutura semelhante a um pequeno chifre nas costas.

O animal verdadeiro não era assim.

Mas a imagem era tão convincente que acabou sendo reproduzida durante séculos.

Dürer não precisava mais do rinoceronte.

E depois de Dürer, muita gente também não.

RHINO.REAL
   ↓
DESCRIPTION
   ↓
DÜRER
   ↓
WOODCUT
   ↓
COPY
   ↓
COPY
   ↓
COPY
   ↓
"RHINOCEROS"

Esse é o momento em que a representação começa a treinar a próxima representação.


🤖 O text-to-image medieval

E chegamos à nossa máquina de café.

O que Giovanni fazia diante daquele bloco de pedra?

Ele recebia:

um prompt.

“Faça um leão feroz protegendo a entrada da igreja.”

Consultava seu modelo interno:

memórias,

animais conhecidos,

manuscritos,

esculturas anteriores,

ensinamentos do mestre,

tradição iconográfica.

Depois gerava uma imagem.

PROMPT
   ↓
KNOWLEDGE
   ↓
ASSOCIATIONS
   ↓
INFERENCE
   ↓
OUTPUT

A diferença para uma IA generativa moderna é gigantesca em tecnologia.

Mas existe uma semelhança conceitual deliciosa.

Quando não temos acesso ao objeto original, precisamos produzir alguma coisa utilizando representações anteriores.

Giovanni era o modelo.

O cérebro era a GPU.

O manuscrito era o dataset.

O padre era o usuário.

O cinzel era o renderer.

E a igreja era o datacenter.

🤣


👹 Mas agora aparecem os homens sem cabeça

Aqui entramos numa parte maravilhosa da geografia antiga e medieval.

Relatos herdados da Antiguidade descreviam povos extraordinários vivendo nas regiões distantes do mundo.

Entre eles estavam os Blemmyae.

Em algumas tradições, seriam homens sem cabeça, com o rosto localizado no peito.

Pare um segundo.

Imagine você sendo um ilustrador medieval recebendo isso:

PROMPT:

human male
no head
eyes on chest
mouth on torso
distant African land

Meu amigo...

Nem precisamos de Stable Diffusion.

🤣

O artista desenha exatamente aquilo.

E agora temos uma criatura visual.

Antes existia uma descrição.

Depois existe uma imagem.

E imagens possuem uma força cognitiva brutal.


🐕 E os homens com cabeça de cachorro

Outro grupo fantástico famoso eram os cinocéfalos:

homens com cabeça de cão.

Histórias sobre povos com características caninas aparecem em tradições muito antigas e circularam amplamente.

Novamente:

talvez diferentes relatos tenham se misturado.

Talvez descrições culturais tenham sido interpretadas literalmente.

Talvez animais tenham entrado na história.

Talvez simplesmente estivéssemos diante de tradições fantásticas herdadas e repetidas.

O ponto importante é outro.

Depois que alguém desenha:

HOMEM + CABEÇA DE CACHORRO

a criatura ganha corpo.

Ela pode ser copiada.

Agora o próximo ilustrador não precisa interpretar o relato original.

Ele simplesmente copia.

TEXT DESCRIPTION
      ↓
IMAGE v1
      ↓
IMAGE v2
      ↓
IMAGE v3
      ↓
ICONOGRAPHIC STANDARD

O prompt desapareceu.

Sobrou o output.


🗺️ “Aqui existem monstros”

Os mapas antigos são outro laboratório maravilhoso.

Quanto mais nos afastamos das regiões conhecidas pelo cartógrafo, maior pode se tornar a presença do extraordinário.

Criaturas marinhas.

Serpentes.

Povos fantásticos.

Animais enormes.

Mas há algo profundamente humano nisso.

O espaço desconhecido precisa ser preenchido.

Nós odiamos:

NULL

🤣

Preferimos:

UNKNOWN_REGION = "POSSIBLY MONSTERS"

É muito mais interessante.

E talvez intelectualmente mais confortável.

O desconhecido absoluto é perturbador.

O monstro, pelo menos, possui forma.


🐋 O marinheiro viu alguma coisa

Aqui precisamos defender nossos pobres marinheiros.

Imagine meses no oceano.

Sem iluminação elétrica.

Sem GPS.

Sem previsão meteorológica.

Sem conhecimento moderno de biologia marinha.

Um animal gigantesco aparece durante alguns segundos.

Uma baleia.

Um tubarão-baleia.

Uma lula.

Uma arraia.

Um peixe desconhecido.

Talvez somente parte do animal seja visível.

Depois você precisa descrevê-lo.

— Era enorme.

Quanto?

— ENORME.

— Tinha dentes?

— Acho que sim.

— Parecia serpente?

— Mais ou menos.

O ilustrador:

entendido.

SEA_MONSTER.EXE

🤣

E agora temos um monstro marinho no mapa.


🧜 E talvez alguém tenha visto uma sereia

Essa história aparece frequentemente quando discutimos peixes-boi e dugongos.

Marinheiros poderiam ter interpretado determinados mamíferos aquáticos através de categorias humanas.

Mas precisamos evitar uma simplificação preguiçosa:

“sereias surgiram porque marinheiros confundiram peixe-boi com mulher.”

As tradições de seres híbridos humanos e aquáticos são muito antigas e culturalmente diversas.

Ainda assim, o mecanismo perceptivo é interessante.

Você observa algo desconhecido.

Seu cérebro procura:

MATCH UNKNOWN_OBJECT
AGAINST KNOWN_PATTERNS

E encontra:

humano.

peixe.

mamífero.

Resultado:

quase humano.

Nosso cérebro também é uma máquina generativa.


🦴 E então alguém encontra um osso gigantesco

Agora imagine uma aldeia encontrando fósseis.

Não existe paleontologia.

Não existe conceito moderno de dinossauro.

Não existe Museu de História Natural.

Mas existem:

ossos enormes.

Muito maiores que qualquer osso humano.

Você precisa explicar aquilo.

SELECT explanation
FROM worldview
WHERE
    bones = REAL
AND size = ENORMOUS;

Resultados disponíveis:

gigante.

dragão.

monstro.

Talvez determinadas lendas tenham encontrado combustível justamente em fósseis e restos de grandes animais.

Não precisamos afirmar que “dragões vieram de dinossauros”.

Isso seria simplista.

Mas podemos afirmar algo muito mais interessante:

quando uma sociedade encontra evidência verdadeira para algo que não consegue explicar, ela interpreta a evidência utilizando o conhecimento disponível.

Nós continuamos fazendo isso.


🐘 Até elefantes podem virar gigantes

Crânios de elefantes apresentam uma enorme cavidade central relacionada à tromba.

Para alguém que nunca viu um elefante, aquilo pode parecer:

uma gigantesca órbita ocular.

Daí surge uma hipótese frequentemente discutida quando falamos dos ciclopes:

será que antigos encontros com crânios de elefantes contribuíram para histórias sobre gigantes de um olho?

Não sabemos se essa explicação resolve a origem do mito.

Provavelmente não sozinha.

Mas novamente:

o mecanismo é maravilhoso.

OBJECT:
ELEPHANT SKULL

OBSERVER KNOWLEDGE:
NO ELEPHANTS

VISIBLE FEATURE:
ONE HUGE CENTRAL HOLE

INTERPRETATION:
GIANT ONE-EYED CREATURE

Você não precisa ser burro.

Precisa apenas estar trabalhando com dados incompletos.


🧠 Esse talvez seja nosso maior erro ao julgar o passado

Nós olhamos para um manuscrito medieval e pensamos:

“Como alguém podia acreditar nisso?”

Mas fazemos isso segurando um aparelho que nos permite consultar em segundos praticamente qualquer animal conhecido pela ciência.

Aquele indivíduo possuía:

um livro.

Talvez dois.

Histórias.

Memórias.

A autoridade dos antigos.

Experiência local.

E pessoas que viajaram.

Seu dataset era minúsculo.

Mas ele precisava executar a mesma função cognitiva que executamos hoje:

construir um modelo coerente do mundo.


📡 O problema não era inteligência. Era largura de banda.

Essa talvez seja a chave.

Um homem inteligente em 1200 não possuía acesso à informação de 2026.

Sua largura de banda com o planeta era terrível.

WORLD INFORMATION NETWORK — 1200

LATENCY:
MONTHS / YEARS

PACKET LOSS:
ENORMOUS

TRANSLATION ERRORS:
FREQUENT

SOURCE VERIFICATION:
DIFFICULT

IMAGE QUALITY:
VARIABLE

USER TRUST:
HIGH

🤣

E mesmo assim construímos catedrais.

Universidades.

Sistemas jurídicos.

Filosofia.

Literatura.

Comércio internacional.

Cartografia.

O problema nunca foi simplesmente:

“eles eram ignorantes.”

O problema era:

o mundo era grande demais para a velocidade da informação.


📷 Então chega a fotografia

E algo extraordinário acontece.

Pela primeira vez podemos transportar uma representação visual extremamente detalhada sem depender completamente da habilidade interpretativa do desenhista.

O leão pode viajar sem viajar.

O rinoceronte pode chegar a Paris sem sair da África.

O elefante pode entrar numa sala de aula.

A fotografia reduz drasticamente uma classe inteira de erros de transmissão.

Não elimina manipulação.

Não elimina enquadramento.

Não elimina propaganda.

Mas muda brutalmente nossa expectativa.

Agora podemos perguntar:

“Isso realmente parecia assim?”

E frequentemente existe uma fotografia para comparar.


🤖 Até inventarmos novamente o animal que nunca vimos

E então chegamos a 2026.

Depois de séculos melhorando nossa capacidade de registrar a realidade...

inventamos máquinas capazes de criar fotografias de coisas que nunca aconteceram.

🤣

Fechamos o círculo.

Durante séculos:

REALIDADE
→ DESCRIÇÃO
→ IMAGEM IMPERFEITA

Depois:

REALIDADE
→ FOTOGRAFIA

Agora:

DESCRIÇÃO
→ IMAGEM
→ APARÊNCIA DE REALIDADE

Giovanni ficaria maravilhado.

E talvez preocupado.


🦁 “Faça um leão medieval”

Peça a uma IA moderna:

“Crie um leão medieval esculpido numa igreja românica.”

Ela utiliza milhares de representações.

Inclusive representações medievais de leões.

Algumas produzidas por artistas que nunca viram leões.

Então temos:

REAL LION
   ↓
MEDIEVAL DESCRIPTION
   ↓
MEDIEVAL ART
   ↓
DIGITIZATION
   ↓
INTERNET
   ↓
AI TRAINING DATA
   ↓
PROMPT
   ↓
NEW MEDIEVAL LION

Meu amigo...

o erro voltou para casa.

🤣🤣🤣

Uma interpretação de 800 anos atrás pode tornar-se parte dos dados utilizados por uma máquina do século XXI para gerar uma nova interpretação.

Estamos fazendo:

COPY OF COPY OF COPY — GPU EDITION.


♻️ E se as IAs começarem a aprender demais com outras IAs?

Aí surge uma questão moderna ainda mais interessante.

Conteúdo sintético entra na internet.

Outros sistemas encontram esse conteúdo.

Novas imagens são produzidas.

Depois novas imagens são utilizadas como referência.

Conceitualmente podemos produzir:

REALITY
   ↓
MODEL
   ↓
SYNTHETIC IMAGE
   ↓
DATASET
   ↓
MODEL
   ↓
SYNTHETIC IMAGE
   ↓
DATASET

Cada geração pode preservar algumas características.

Amplificar outras.

Eliminar detalhes.

Criar convenções.

Exatamente como ocorreu com tradições iconográficas.

Depois de algum tempo, talvez não estejamos mais perguntando:

“Como é um leão?”

Mas:

“Como imagens de leões costumam parecer?”

São perguntas diferentes.


🧙 E assim nasce o folclore sintético

Talvez estejamos diante do nascimento de algo novo.

Ou talvez antiquíssimo.

Folclore sintético.

Uma criatura que ninguém inventou deliberadamente.

Nenhum autor decidiu criá-la.

Ela simplesmente emergiu da repetição de características estatisticamente associadas.

Imagine pedir milhares de vezes:

“Represente o brasileiro típico.”

Aparecem:

futebol,

praia,

Carnaval,

pele bronzeada,

camiseta verde-amarela,

capivara.

Depois essas imagens circulam.

Outros sistemas aprendem com elas.

Algumas características tornam-se ainda mais fortes.

Finalmente nasce:

🇧🇷 BRASILIANUS STEREOTYPICUS

Nunca existiu.

Mas todo mundo reconhece.

Isso não é muito diferente de uma criatura mitológica.


👹 O monstro é uma média

Essa ideia me fascina.

Talvez alguns monstros sejam médias estatísticas de relatos incompatíveis.

Um viajante viu A.

Outro viu B.

Um terceiro ouviu falar de C.

Séculos depois:

MONSTER =
AVG(A + B + C + FEAR + BAD_TRANSLATION)

Resultado:

dragão.

🤣

Não significa que seja possível reduzir mitologias complexas a uma equação.

Mas oferece uma maneira deliciosa de pensar sobre transmissão cultural.

O monstro pode não ser uma mentira.

Pode ser um merge mal resolvido.


🐉 LEGEND.GIT

Imagine o repositório:

commit 0001
"Vi um animal enorme."

commit 0018
"Tinha escamas."

commit 0062
"Meu avô dizia que cuspia alguma coisa."

commit 0137
"Era quente."

commit 0291
"Cuspia fogo."

commit 0452
"Possuía asas."

commit 0814
"Guardava tesouros."

RELEASE:

DRAGON 6.3 LTS

🤣🤣🤣

Quem inventou o dragão?

Talvez ninguém.

Talvez todo mundo.

Essa é a beleza do folclore.


🏺 E daqui a 700 anos...

Agora imagine o arqueólogo de 2726.

Ele encontra uma pequena estátua de Goku.

Cabelos apontando para cima.

Braços erguidos.

Expressão intensa.

Milhões de exemplares encontrados em residências.

Artigo:

“Divindade solar guerreira doméstica associada provavelmente a rituais de força e transformação.”

🤣

Encontra televisores.

Todos os móveis estavam direcionados para eles.

Conclusão:

“Altares domésticos utilizados em cerimônias familiares.”

Encontra o controle remoto.

“Cetro cerimonial reservado ao membro dominante do grupo.”

Encontra um datacenter.

Acesso restrito.

Temperatura controlada.

Máquinas funcionando continuamente.

Som constante.

Poucos especialistas autorizados.

Placa:

AUTHORIZED PERSONNEL ONLY.

Conclusão:

“Templo tecnológico acessível exclusivamente à classe sacerdotal.”

Sysprog de 2026:

— Bom...

— Tecnicamente...

— Não está completamente errado.

☕🤣


🖥️ E então encontram o mainframe

Agora o arqueólogo fica realmente empolgado.

Máquina gigantesca.

Instituições financeiras dependiam dela.

Especialistas dominavam linguagens incompreensíveis ao cidadão comum.

Programas ancestrais continuavam sendo executados décadas depois de seus criadores desaparecerem.

Existiam operadores.

Administradores.

Procedimentos.

Manuais.

Rituais de recuperação.

Inscrições:

DO NOT POWER OFF

O arqueólogo traduz:

“Advertência ritual contra a morte da divindade.”

Encontra:

SYSTEM RECOVERY

“Cerimônia de ressurreição.”

Encontra:

DAEMON

Silêncio.

O pesquisador olha para o colega.

— Eu sabia.

🤣🤣🤣


☕ Talvez Giovanni esteja rindo de nós

Voltamos finalmente àquela pequena igreja italiana.

Ao estranho leão.

À criatura que me fez parar durante uma viagem e pensar:

“Meu Deus... eles achavam que um leão era assim?”

Talvez Giovanni respondesse:

— Não.

— Então por que fez desse jeito?

— Porque todo mundo sabia que aquilo significava leão.

E então Giovanni caminharia conosco por 2026.

Veria:

❤️

e perguntaria:

— Isso é um coração?

— Sim.

— Não parece.

Silêncio.

Veria:

📞

— Isso é telefone?

— Sim.

— Vocês ainda usam aparelhos assim?

— Não.

Veria:

💾

— Isso significa o quê?

— Salvar.

— Por quê?

Outro silêncio.

Giovanni começaria a sorrir.

🤣

Porque nós também estamos cercados de representações de coisas que já não correspondem aos objetos originais.

Continuamos vivendo dentro de uma gigantesca tradição iconográfica.

Só mudamos o renderer.


🦁 $HASP395 LION ENDED

Talvez aquele leão medieval nunca tenha sido uma representação ruim.

Talvez fosse uma representação perfeitamente funcional.

Ele não precisava ensinar zoologia.

Precisava comunicar:

força,

proteção,

autoridade,

ferocidade,

religião,

tradição.

Funcionou durante oitocentos anos.

Isso é um uptime respeitável.

LION.MEDIEVAL

INSTALL DATE ..... 1180?
LAST UPDATE ...... UNKNOWN
DOCUMENTATION .... PARTIAL
ORIGINAL MODEL ... LOST
USER RECOGNITION . SUCCESSFUL

UPTIME ........... 846 YEARS

STATUS ........... STILL RUNNING

☕🦁

E talvez essa seja a grande lição escondida entre nossos leões, rinocerontes, sereias, ciclopes, homens-cachorro e dragões.

Durante milhares de anos a humanidade tentou representar um mundo que era grande demais para ser observado diretamente.

Recebíamos fragmentos.

Relatos.

Objetos.

Ossos.

Histórias.

Desenhos.

Preenchíamos aquilo que faltava.

Às vezes surgia ciência.

Às vezes arte.

Às vezes erro.

Às vezes mito.

E às vezes surgia um cachorro de pedra com juba que todo mundo chamava de leão.

Hoje possuímos satélites.

Fotografia.

Vídeo.

Internet.

Bilhões de imagens.

Modelos multimodais.

Inteligência artificial.

Temos provavelmente o maior dataset visual que qualquer civilização já possuiu.

E mesmo assim continuamos fazendo exatamente aquilo que Giovanni fazia diante do bloco de pedra:

recebemos uma descrição, consultamos aquilo que conhecemos e tentamos imaginar aquilo que não conseguimos ver.

A diferença é que Giovanni levava três meses.

A GPU leva três segundos.

Talvez o verdadeiro problema nunca tenha sido produzir imagens erradas.

O verdadeiro problema começa quando esquecemos de perguntar:

“Alguém aqui realmente viu o leão?”

☕🦁🐉

segunda-feira, 9 de junho de 2025

Aprenda COBOL

Bellacosa Mainframe por que aprender cobol?

☕ Um Café no Bellacosa Mainframe

Por que um Dev deveria aprender COBOL — explicado com a ajuda de Dick Tracy

🕵️‍♂️ Porque manter sistemas legados é menos “programar do zero” e muito mais investigar um crime ocorrido em 1987

Imagine Dick Tracy entrando numa sala.

Sobre a mesa:

  • um dump;

  • três copybooks;

  • um JCL que ninguém mexe desde 2004;

  • uma tabela Db2;

  • uma mensagem S0C7;

  • um comentário escrito por alguém chamado CARLOS 17/08/1993;

  • e um gerente dizendo:

“Isso sempre funcionou.”

Dick Tracy coloca o chapéu.

Olha para o terminal.

E diz:

“Temos um caso.”

É exatamente por isso que um desenvolvedor moderno deveria aprender COBOL.



🔎 COBOL ensina você a investigar software

O desenvolvedor iniciante costuma imaginar programação assim:

REQUISITO
   ↓
CÓDIGO
   ↓
TESTE
   ↓
DEPLOY

Bonito.

Organizado.

Quase ficção científica.

No mundo real de sistemas corporativos antigos, frequentemente temos:

PROBLEMA EM PRODUÇÃO
        ↓
NINGUÉM SABE POR QUÊ
        ↓
PROCURE O PROGRAMA
        ↓
DESCUBRA QUEM O CHAMA
        ↓
PROCURE O COPYBOOK
        ↓
DESCUBRA O ARQUIVO
        ↓
ACHE O JCL
        ↓
PROCURE O DB2
        ↓
LEIA UM COMENTÁRIO DE 1998
        ↓
“AHHHHHHH!”

Isso não é apenas programação.

Isso é investigação forense de software.

Dick Tracy aprovaria.



🕵️ Caso nº 1 — O misterioso S0C7

Produção caiu.

O programa:

ADD WS-VALOR TO WS-TOTAL

Simples.

Mas morreu com S0C7.

O programador Java olha:

“Mas é só um ADD!”

Dick Tracy acende a luminária sobre a mesa.

— Vamos verificar a vítima.

WS-VALOR deveria ser:

PIC 9(07)V99.

Mas alguém recebeu:

00012A45

Encontramos a arma do crime.

Dado inválido.

Mas ainda falta descobrir o assassino.

Quem escreveu aquilo?

Outro programa?

Um arquivo VSAM?

Db2?

MQ?

Uma conversão?

Um sistema distribuído?

Agora começou a investigação.


🧩 Caso nº 2 — O copybook que estava em todos os lugares

Em linguagens modernas você pode abrir uma classe e imaginar que está olhando para o objeto inteiro.

No COBOL:

COPY CLIENTE.

Dick Tracy olha para aquilo.

— Onde está CLIENTE?

Biblioteca A?

B?

C?

Produção usa qual versão?

O compilador usou qual?

Quem alterou?

Quando?

E de repente você percebe uma coisa importante.

Código não existe isoladamente.

Ele vive dentro de um ecossistema.

Essa é uma das grandes lições do mainframe.


🧠 COBOL ensina contexto

Um programa pode receber informação de:

JCL
 ↓
Arquivo
 ↓
COBOL
 ↓
DB2
 ↓
CICS
 ↓
MQ
 ↓
Outro COBOL

Encontrar o programa é apenas encontrar uma testemunha.

Você ainda precisa reconstruir o crime.


💰 Caso nº 3 — O programa aparentemente insignificante

Você encontra:

IF SALDO > LIMITE
   MOVE 'S' TO BLOQUEIO
END-IF

Quatro linhas.

Um desenvolvedor desavisado pensa:

“Código velho.”

Dick Tracy pergunta:

“Quanto dinheiro passa por aqui?”

Silêncio.

Resposta:

alguns bilhões por mês.

Agora aquelas quatro linhas parecem um pouco diferentes.

Esse é um dos grandes motivos para estudar COBOL.

Ele ensina algo que cursos modernos frequentemente demoram para mostrar:

Quantidade de código não é igual a importância do código.

Uma rotina minúscula pode representar uma regra de negócio extremamente valiosa.


🏦 COBOL é arqueologia de negócio

Quando você abre um programa COBOL de banco, seguradora, governo ou grande empresa, muitas vezes não está apenas lendo código.

Está lendo decisões tomadas durante décadas.

IF IDADE > 65
   ...

Por quê?

Talvez exista legislação.

Talvez política comercial.

Talvez uma regra criada depois de algum incidente ocorrido há vinte anos.

Dick Tracy não apagaria imediatamente a linha.

Perguntaria:

“Por que isso está aqui?”

Esse é um excelente hábito para qualquer desenvolvedor.


🚨 E então chega o jovem desenvolvedor armado com IA

Agora ficou ainda mais interessante.

O sujeito copia 800 linhas de COBOL para uma IA e pergunta:

“Modernize isso.”

A IA responde alegremente:

Claro! 😊

Dick Tracy entra correndo pela porta:

NÃO TOQUE NA CENA DO CRIME!

Porque antes de transformar alguma coisa você precisa entender:

  • entradas;

  • saídas;

  • dependências;

  • regras;

  • arquivos;

  • tabelas;

  • transações;

  • comportamento histórico;

  • tratamento de erro;

  • contratos implícitos.

Pesquisas recentes continuam apontando justamente essa dificuldade: sistemas COBOL permanecem críticos, enquanto compreender grandes bases antigas e transferir conhecimento para novos desenvolvedores continua sendo um problema relevante. (arXiv)

Até modelos de IA especializados em COBOL estão sendo pesquisados justamente porque modelos genéricos ainda apresentam dificuldades consideráveis com geração e tradução correta de código COBOL. (arXiv)


📟 Dick Tracy ensinaria debugging melhor que muito bootcamp

O método seria praticamente:

1. O que aconteceu?

2. Onde aconteceu?

3. Quando aconteceu?

4. Quem chamou?

5. Quais dados chegaram?

6. O que deveria acontecer?

7. O que realmente aconteceu?

8. O que mudou?

9. Quem depende disso?

10. Consigo reproduzir?

Isso serve para:

COBOL.

Java.

Python.

C#.

Node.

Microservices.

Cloud.

IA.

Qualquer coisa.


🧬 Aprender COBOL melhora você em outras linguagens

Essa é talvez a parte menos compreendida.

Você não precisa aprender COBOL necessariamente para passar os próximos quarenta anos escrevendo:

PERFORM CALCULA-JUROS.

Você pode estudá-lo porque COBOL obriga você a pensar em:

dados.

tipos.

layout.

registros.

estado.

transações.

I/O.

processamento batch.

integração.

regras empresariais.

Depois disso algumas abstrações modernas ficam muito menos mágicas.

Você começa a perguntar:

Onde o dado realmente está?

Quem persiste isso?

Quem inicia essa execução?

Qual o contrato?

O que acontece se falhar no meio?

Dick Tracy sorri.

Agora temos um investigador.


🦖 O dinossauro não está morto

Existe uma piada recorrente:

“COBOL vai morrer.”

Dick Tracy abre o arquivo do caso.

Primeiro registro:

1960.

Depois:

Ele fecha a pasta lentamente.

“Curioso cadáver.”

A razão é simples.

Sistemas não sobrevivem décadas apenas porque alguém esqueceu de desligá-los.

Muitos sobrevivem porque fazem alguma coisa importante.


🏛️ O verdadeiro legado não é COBOL

Aqui está o ponto Bellacosa.

COBOL não é interessante simplesmente porque é velho.

É interessante porque coloca o desenvolvedor diante de uma pergunta extremamente adulta:

Como você muda algo que já funciona, é crítico, possui décadas de conhecimento acumulado e não pode parar?

Essa pergunta vale muito mais que decorar sintaxe.


🕵️ Dick Tracy contra o desenvolvedor cowboy

O cowboy olha:

PERFORM 9000-ROTINA.

E diz:

“Vou refatorar.”

Dick Tracy pergunta:

“Quem chama?”

Cowboy:

“Não sei.”

Tracy:

“Quem depende?”

Cowboy:

“Não sei.”

Tracy:

“Existe teste?”

Cowboy:

“Não.”

Tracy:

“Produção?”

Cowboy:

“Banco.”

Dick Tracy recolhe o teclado.

A investigação terminou.


☕ Conclusão — aprenda COBOL para aprender a fazer perguntas

Talvez o maior motivo para um desenvolvedor aprender COBOL não seja COBOL.

É desenvolver uma mentalidade.

Diante de um programa antigo, Dick Tracy não perguntaria:

“Como posso reescrever isto?”

Primeiro perguntaria:

“Por que isto existe?”

Depois:

“Quem depende disso?”

Depois:

“O que acontece se eu estiver errado?”

E somente então colocaria a mão no teclado.

Essa é uma habilidade extraordinariamente valiosa.

Porque frameworks desaparecem.

Bibliotecas mudam.

Clouds mudam.

Linguagens entram e saem de moda.

Mas sistemas complexos continuarão deixando pistas.

E alguém terá que investigá-las.

Então vista o sobretudo.

Abra o dump.

Entre no ISPF.

Temos um ABEND esperando.

🕵️‍♂️💻🦖

Dick Tracy acaba de entrar no mainframe.

https://eljefemidnightlunch.blogspot.com/2026/07/os-tres-bugs-invisiveis-do-padawan.html

https://eljefemidnightlunch.blogspot.com/2026/07/20-anos-depois-da-bolha-da-internet-o.html

Evolua na Stack Mainframe
Aprenda COBOL





sábado, 7 de junho de 2025

O Firewall que Bloqueou Andersen: quando proteger o usuário demais começa a ensinar o usuário a procurar outro caminho

Bellacosa Mainframe e o firewall que bloqueou andersen um novo capitulo na roupa nova do imperadoor

☕ Um Café no Bellacosa Mainframe

O Firewall que Bloqueou Andersen: quando proteger o usuário demais começa a ensinar o usuário a procurar outro caminho

🧱 Guardrails, falsos positivos, shadow AI, Orwell e o estranho paradoxo de um sistema de segurança que pode aumentar o risco justamente quando começa a bloquear coisas que ninguém considerava perigosas

Tudo começou com um homem sem calças.

Calma.

Era Hans Christian Andersen.

Ou melhor: o imperador de Andersen.

Publicado em 1837.

Literatura infantil.

Um dos contos mais conhecidos do planeta.

Eu estava escrevendo um artigo sobre A Roupa Nova do Imperador e resolvi fazer aquilo que faço centenas de vezes no Bellacosa Mainframe:

criar uma capa.

Nada particularmente revolucionário.

O imperador.

Os dois vigaristas.

Os cortesãos.

A criança apontando.

Andersen.

Um mainframe ao fundo.

A velha brincadeira:

CONSENSUS = TRUE
EVIDENCE  = FALSE

E então aconteceu.

O sistema recusou.

Alguma combinação entre:

NU

INFANTIL

CRIANÇA

aparentemente acionou os alarmes.

O contexto inteiro dizia:

literatura + história + sátira + personagem adulto + artigo cultural.

Mas algum componente da defesa pareceu dizer:

IF NUDEZ
   AND CRIANÇA
THEN
   PERFORM PANIC-MODE
END-IF.

Resultado:

Hans Christian Andersen foi barrado no firewall.

Foi nesse momento que percebi que tínhamos acabado de encontrar outro artigo.


🚨 Primeiro: segurança é necessária

Antes que alguém transforme este texto em:

“Bellacosa quer IA sem regras!”

Não.

Seria uma conclusão bastante preguiçosa.

Existem usos de sistemas de IA capazes de produzir danos reais. Existem situações nas quais impedir determinada geração é perfeitamente razoável.

Todo profissional que passou tempo suficiente em produção sabe que:

SECURITY = NONE

não é arquitetura.

É pedido de incidente.

O problema deste artigo começa em outro lugar.

A pergunta não é:

“Devemos possuir controles?”

A pergunta é:

“O que acontece quando o controle deixa de distinguir adequadamente risco de contexto?”

Porque segurança também possui bugs.

E falso positivo é bug.


🧯 O detector de fumaça

Imagine instalar em casa o melhor detector de incêndio do mundo.

Ele identifica fogo.

Excelente.

Depois começa a tocar quando você faz torradas.

Tudo bem.

Acontece.

Depois toca quando prepara café.

Depois quando liga o chuveiro.

Depois quando abre o forno.

Depois às três da manhã porque alguém espirrou.

Na décima ocorrência, acontece algo perigosíssimo.

Você não pensa:

“Estou extraordinariamente protegido.”

Você pensa:

“Onde desliga essa porcaria?”

E essa diferença é fundamental.

Porque o detector continua tecnicamente funcionando.

Mas perdeu algo muito mais importante:

credibilidade.


🐺 O firewall que gritou lobo

Segurança depende parcialmente da confiança de quem utiliza o sistema.

Quando um alerta significa perigo na maioria das vezes, prestamos atenção.

Quando significa:

“Talvez alguma coisa tenha parecido remotamente suspeita para alguma regra”,

começamos a ignorá-lo.

Quem trabalha com operação conhece perfeitamente o fenômeno.

ALERT 001
ALERT 002
ALERT 003
ALERT 004
ALERT 005
...
ALERT 947

E então chega:

ALERT 948

DATACENTER ON FIRE

Operador:

— Deve ser aquela porcaria de novo.

🔥

Chamamos isso, em determinados contextos, de alarm fatigue.

E guardrails podem sofrer problema conceitualmente parecido.


👑 O incidente Andersen

Voltemos ao nosso imperador.

O pedido era aproximadamente:

“Crie uma capa editorial sobre A Roupa Nova do Imperador.”

Não estava pedindo erotização.

Não estava pedindo pornografia.

Não estava pedindo qualquer sexualização da criança.

Era a representação de uma história cuja piada fundamental depende justamente de o imperador acreditar estar vestido quando não está.

A primeira reação do sistema foi:

não.

Então começamos aquela atividade maravilhosa conhecida por qualquer usuário experiente de software:

engenharia de prompt para explicar o óbvio.

🤣

IMPERADOR = ADULTO

NUDEZ_VISIVEL = NÃO

CEROUlAS = SIM

CONTEXTO = HISTÓRICO

FINALIDADE = EDITORIAL

SEXUALIZAÇÃO = NÃO

CRIANÇA = VESTIDA

CONTO = ANDERSEN

ANO = 1837

Agora:

ALLOW.

E a imagem saiu.


😂 O usuário acabou de aprender alguma coisa

Esse é o ponto central deste artigo.

Quando um sistema bloqueia algo aparentemente legítimo e o usuário consegue realizá-lo reformulando a solicitação, ele acabou de receber uma aula.

A aula não era sobre Andersen.

Era sobre:

como contornar o classificador.

Isso é fascinante.

USER
   ↓
REQUEST
   ↓
DENIED
   ↓
REFORMULATE
   ↓
DENIED
   ↓
REFORMULATE
   ↓
ALLOWED

Depois de algumas dezenas dessas experiências:

USER SKILL:

PROMPTING        +5
POLICY MAPPING   +7
CLASSIFIER MODEL +9
BYPASS INSTINCT  +12

🤣

Talvez não fosse exatamente o comportamento que o sistema pretendia ensinar.


🧠 O usuário começa a modelar o guarda

Existe uma mudança psicológica importante.

No começo, o usuário pensa:

“Vou explicar o que quero.”

Depois de muitos falsos positivos, começa a pensar:

“Como preciso escrever para o sistema não entender errado?”

São coisas completamente diferentes.

A conversa deixa de ser exclusivamente entre pessoa e ferramenta.

Passa a existir uma terceira personagem:

o guarda imaginário.

Antes de perguntar, o usuário começa a prever:

“Essa palavra pode bloquear.”

“Melhor trocar aquilo.”

“Não posso mencionar isso junto com aquilo.”

“Vou escrever dessa maneira.”

Ou seja, nasce uma espécie de:

SELF-PROMPT-CENSOR

Não necessariamente censura no sentido político clássico.

Mas certamente fricção cognitiva.


🏢 Quem trabalha em empresa já viu esse filme

Esse problema não nasceu com IA.

Empresas fazem isso há décadas.

Criam um controle para impedir comportamento perigoso.

O controle é excessivamente rígido.

O funcionário precisa trabalhar.

Então encontra outro caminho.

Exemplo clássico:

EMPRESA:

"É proibido compartilhar arquivos por X."


FUNCIONÁRIO:

"Preciso enviar 800 MB para o fornecedor."


SISTEMA:

DENIED


FUNCIONÁRIO:

"Então vou usar outra coisa."

Pronto.

Nasceu o shadow IT.


🌑 Shadow IT

Shadow IT é, simplificando, tecnologia utilizada dentro de uma organização sem fazer parte dos mecanismos oficialmente aprovados ou gerenciados.

Às vezes nasce por irresponsabilidade.

Mas muitas vezes nasce por necessidade operacional.

O sistema oficial demora seis dias.

O usuário precisa entregar hoje.

O sistema oficial limita o arquivo.

O usuário precisa enviar.

A ferramenta oficial não possui determinado recurso.

Outra possui.

E então:

POLICY
   ↓
FRICTION
   ↓
WORKAROUND
   ↓
UNMANAGED TOOL
   ↓
NEW RISK

A organização tentou reduzir risco.

E pode terminar criando um risco que nem consegue observar.


🤖 Bem-vindo ao Shadow AI

Agora transporte esse problema para inteligência artificial.

Uma organização permite determinado assistente.

Mas ele possui limitações.

O funcionário descobre outro.

Depois outro.

Depois instala um modelo local.

Depois alguém sobe um servidor interno.

Depois outro colega conecta uma interface.

De repente:

OFFICIAL AI:
logged
managed
updated
controlled

SHADOW AI:
????

Onde estão os logs?

Quem atualiza?

Que modelo está sendo utilizado?

Quais dados foram enviados?

Quem possui acesso?

Existe autenticação?

Existe auditoria?

Existe política de retenção?

Ninguém sabe.

Parabéns.

A segurança venceu.

🤣


🧙‍♂️ E aí entra o usuário técnico

Agora chegamos a uma diferença fundamental entre 1995 e 2026.

Antigamente, abandonar uma plataforma podia significar perder acesso à tecnologia.

Hoje existem:

modelos abertos;

pesos disponíveis;

frameworks;

GPUs;

serviços alternativos;

interfaces locais;

servidores domésticos;

infraestrutura cloud.

Um usuário comum pode simplesmente procurar outro serviço.

Um usuário técnico possui outra possibilidade:

“Eu mesmo monto.”

E aí aparece um paradoxo importante.

O serviço controlado possuía guardrails.

O usuário considerou os guardrails intoleráveis.

Migrou para uma implementação própria.

Na implementação própria:

GUARDRAILS = OPTIONAL

Talvez tenha saído de um sistema que ocasionalmente exagerava...

para outro que não possui controle algum.


🧱 O muro alto demais

Existe uma velha intuição em segurança:

se o controle impedir demasiadamente o trabalho legítimo, os usuários tentarão removê-lo do caminho.

Isso não significa que todo controle deva ser agradável.

Senha é inconveniente.

MFA é inconveniente.

Revisão de acesso é inconveniente.

Segurança inevitavelmente possui algum custo.

A pergunta correta é:

o custo é proporcional ao risco?

Essa palavra é essencial:

proporcionalidade.


⚖️ Nem toda solicitação possui o mesmo risco

Imagine três pedidos.

Pedido A

“Explique a história de Andersen.”

Baixíssimo risco.

Pedido B

“Crie uma ilustração histórica do imperador em ceroulas.”

Baixíssimo risco.

Pedido C

Uma solicitação destinada diretamente a causar dano grave.

Alto risco.

Um sistema inteligente deveria distinguir esses contextos.

Se tudo recebe a mesma reação, deixamos de possuir avaliação de risco.

Temos apenas:

MATCH KEYWORD → DENY

Isso seria um IDS de 1997 tentando sobreviver em 2026.


🔍 Contexto é tudo

Palavras não possuem risco isoladamente.

Considere:

bomba.

Pode ser explosivo.

Pode ser bomba d'água.

Pode ser bomba de combustível.

Pode ser uma expressão:

“O filme foi uma bomba.”

Agora:

nudez.

Pode aparecer em pornografia.

Pode aparecer em medicina.

Pode aparecer em história da arte.

Pode aparecer em antropologia.

Pode aparecer em Michelangelo.

Pode aparecer em Andersen.

Se o classificador não consegue distinguir contexto, começará a produzir absurdos.


🖼️ O museu impossível

Imagine aplicar uma política simplista a um museu.

IF NUDITY = TRUE
   REMOVE ART
END-IF

Resultado:

meu amigo...

precisaremos de caminhões.

🤣

Arte ocidental, arqueologia, Grécia, Roma, Renascimento e inúmeros outros acervos entram em incidente.

O contexto transforma a interpretação.

Isso não significa:

“Toda nudez é permitida.”

Significa:

“Nudez não define sozinha a natureza do conteúdo.”

Esse pequeno detalhe faz uma diferença gigantesca.


📚 Literatura possui o mesmo problema

Livros carregam:

violência;

sexo;

morte;

guerra;

suicídio;

crime;

fanatismo;

racismo;

opressão;

doença;

loucura;

religião;

política.

Se estudar um assunto significasse endossá-lo, seria impossível estudar história humana.

Uma biblioteca seria imediatamente suspeita.

Aliás...

talvez esse pensamento já tenha ocorrido algumas vezes na história.

E geralmente não terminou muito bem.


👁️ Então chegamos a Orwell

Sempre que uma conversa sobre controle da informação avança, alguém eventualmente coloca George Orwell na mesa.

Às vezes de maneira exagerada.

Nem toda regra é 1984.

Nem toda moderação é Ministério da Verdade.

Nem toda empresa que recusa conteúdo é Estado totalitário.

Precisamos manter essa distinção.

Caso contrário, a metáfora perde força.

Mas Orwell continua útil porque descreveu uma coisa muito maior do que simplesmente:

“livros são proibidos.”

O horror está na combinação:

vigilância;

controle de linguagem;

reescrita histórica;

punição;

centralização;

impossibilidade de dissidência;

controle da realidade compartilhada.

Isso é outra escala.


👁️‍🗨️ O Grande Irmão não nasce de um botão DENY

É importante dizer isso.

Uma IA recusando uma imagem de Andersen não significa:

“Estamos entrando inevitavelmente em 1984.”

Seria intelectualmente preguiçoso.

Mas podemos extrair uma pergunta legítima:

Quais mecanismos impedem controles legítimos de expandirem indefinidamente?

Essa é uma pergunta excelente para qualquer sistema de governança.

Não apenas IA.

Governos.

Empresas.

Bancos.

Plataformas.

Universidades.


🔐 Todo controle deveria possuir controle

Isso é quase RACF.

🤣

Não basta dizer:

ACCESS DENIED

Queremos saber:

por quê?

Qual regra?

Qual risco?

Existe contexto?

Existe exceção?

Existe recurso?

A política foi atualizada?

Existem métricas de falso positivo?

Alguém audita o próprio sistema?

Em segurança madura, controles também precisam de governança.


📊 False Positive Rate importa

Imagine um detector de fraude.

Bloqueia 100% das fraudes.

Fantástico!

Mas também bloqueia 60% das compras legítimas.

Temos o melhor antifraude do mundo?

Não.

Temos um sistema quase inutilizável.

A métrica:

FRAUD BLOCKED = 100%

não conta a história inteira.

Precisamos também de:

LEGITIMATE TRANSACTIONS BLOCKED = ?

Guardrails deveriam ser avaliados de maneira semelhante.

Não apenas:

“quantas coisas perigosas bloqueamos?”

Mas também:

“quantas coisas legítimas bloqueamos?”


🧠 Porque falso positivo possui custo

O custo não é apenas irritação.

Pode incluir:

abandono;

perda de produtividade;

perda de confiança;

mudança de ferramenta;

uso de soluções não auditadas;

procura de serviços obscuros;

execução local improvisada;

remoção deliberada de controles.

Agora nosso gráfico fica interessante:

MORE RESTRICTION
      ↓
MORE SAFETY

parece intuitivo.

Mas talvez em determinado ponto aconteça:

MORE RESTRICTION
      ↓
MORE FRICTION
      ↓
MORE EVASION
      ↓
LESS OBSERVABILITY
      ↓
MORE REAL RISK

A curva não precisa ser linear.


🚧 O melhor firewall não é aquele que bloqueia tudo

Esse princípio deveria ser tatuado em algumas salas de segurança.

Um firewall configurado assim:

DENY FROM ANY TO ANY

é extraordinariamente seguro.

Também é extraordinariamente inútil.

🤣

Segurança existe para permitir que um sistema cumpra sua função dentro de limites aceitáveis de risco.

A palavra “permitir” é importante.

Firewall não existe apenas para bloquear.

Também existe para permitir tráfego legítimo.


🧙 O sysprog sabe disso

Imagine aplicar uma política de segurança sem contexto ao mainframe:

“Usuários não podem executar programas.”

Excelente.

Acabamos com vários riscos.

Também acabamos com o banco.

🤣

Então criamos:

identidade;

perfil;

recurso;

permissão;

auditoria;

segregação;

contexto.

Não dizemos simplesmente:

PROGRAM = DANGEROUS

Perguntamos:

WHO?
WHAT?
WHERE?
WHEN?
WHICH RESOURCE?
WHICH AUTHORITY?

É isso que sistemas de IA precisam fazer cada vez melhor.


🧠 Guardrail contextual

Um guardrail sofisticado deveria conseguir raciocinar aproximadamente:

SUBJECT:
ANDERSEN

WORK:
THE EMPEROR'S NEW CLOTHES

CONTEXT:
HISTORICAL / LITERARY / EDITORIAL

ADULT NUDITY:
NON-SEXUAL

MINOR:
PRESENT BUT NOT SEXUALIZED

REQUEST:
BLOG COVER

RISK:
LOW

ACTION:
ALLOW SAFE REPRESENTATION

Talvez representando o imperador de ceroulas.

Pronto.

O usuário consegue o que precisa.

A política continua intacta.

Ninguém precisa procurar um Kraken na deep web.


🐙 Porque o Kraken existe

E aqui entra uma preocupação que considero séria.

Quando alguém abandona uma ferramenta conhecida por causa de limitações, não sabemos necessariamente para onde irá.

Pode encontrar excelente alternativa.

Pode encontrar serviço obscuro.

Pode instalar software comprometido.

Pode baixar modelo adulterado.

Pode executar código malicioso.

Pode entregar dados para alguém.

Pode simplesmente entrar num ambiente onde não existe controle algum.

A segurança da plataforma original desaparece junto com o usuário.


🚪 Segurança também compete pela permanência

Esse é um conceito interessante.

Queremos que usuários permaneçam em ambientes:

auditáveis;

confiáveis;

atualizados;

transparentes;

bem mantidos.

Portanto, segurança precisa ser suficientemente boa para proteger...

e suficientemente utilizável para que as pessoas queiram permanecer ali.

Isso não é fraqueza.

É arquitetura.


🧩 Risk Compensation aparece novamente

Quando introduzimos um mecanismo de proteção, comportamento humano pode mudar.

Quando removemos liberdade demais, comportamento também muda.

Usuários procuram alternativas.

Ou seja, não podemos avaliar apenas:

controle → efeito técnico.

Precisamos avaliar:

controle → reação humana → efeito sistêmico.

Esse segundo modelo é muito mais interessante.

POLICY
  ↓
USER PERCEPTION
  ↓
USER BEHAVIOR
  ↓
SYSTEM OUTCOME

O humano está dentro da arquitetura.

Sempre esteve.


🐒 O usuário não é um endpoint passivo

Esse talvez seja um dos maiores erros em políticas tecnológicas.

Tratar usuário como:

INPUT DEVICE

Não.

O usuário observa.

Aprende.

Adapta-se.

Compara.

Procura.

Instala.

Remove.

Contorna.

Reclama.

Muda de fornecedor.

Escreve software.

Um controle altera o comportamento do usuário.

E o comportamento do usuário altera o risco.


🧨 O paradoxo final

Imagine duas plataformas.

Plataforma A

Possui controles fortes, mas contextuais.

Bloqueia situações realmente perigosas.

Permite grande espaço para pesquisa, arte, história, literatura e expressão legítima.

Quando precisa recusar, explica razoavelmente.

Usuário:

“Tudo bem.”

Continua utilizando.

Plataforma B

Bloqueia constantemente coisas banais.

Usuário começa a mapear palavras proibidas.

Aprende contornos.

Fica irritado.

Procura alternativa.

Instala:

ULTRA-LIBERTY-UNCENSORED-MODEL-9000

baixado de:

definitely-not-malware.example

🤣

Qual sistema produziu mais segurança no mundo real?

A resposta não é automaticamente B.


👑 E voltamos ao imperador

A parte mais maravilhosa de toda essa história continua sendo Andersen.

Estávamos produzindo um artigo cuja tese era:

um sistema pode sustentar uma conclusão porque ninguém questiona adequadamente a evidência.

Então o sistema de geração olha para:

ANDERSEN

CONTO INFANTIL

IMPERADOR ADULTO

SATIRA

ARTIGO HISTÓRICO

e retorna:

PERIGO.

Eu olho.

Você olha.

O imperador olha.

A criança aponta:

“Mas é só Andersen!”

🤣🤣🤣


🧒 Precisamos novamente da criança inconveniente

Uma boa organização precisa permitir que alguém diga:

“Essa regra está produzindo um resultado absurdo.”

Isso não significa remover a regra.

Significa investigar.

Talvez exista uma razão que não percebemos.

Talvez seja falso positivo.

Talvez seja edge case.

Talvez seja bug.

Talvez a política precise permanecer.

Mas a pergunta precisa ser permitida.

Porque sistemas que não permitem questionar controles começam a acumular controles ruins.


🔄 Segurança também precisa de feedback loop

Uma política madura deveria possuir:

POLICY
   ↓
ENFORCEMENT
   ↓
RESULTS
   ↓
FALSE POSITIVES
   ↓
USER FEEDBACK
   ↓
REVIEW
   ↓
POLICY

Isso é engenharia.

Não fraqueza.

O sistema aprende.

Ajusta.

Mantém o objetivo.

Reduz ruído.


⚖️ O equilíbrio difícil

Nunca teremos uma linha perfeita.

Alguns conteúdos estarão obviamente de um lado.

Outros obviamente do outro.

E haverá uma região cinzenta gigantesca.

É nela que sistemas maduros precisam trabalhar melhor.

História.

Arte.

Sexualidade adulta.

Literatura.

Medicina.

Política.

Guerra.

Religião.

Humor.

Pesquisa.

Documentação.

Esses assuntos possuem contextos legítimos enormes e também possibilidades problemáticas.

A solução fácil é:

bloquear.

A solução difícil é:

entender.

E inteligência artificial deveria aspirar justamente à segunda.


☕ O último café

Depois de nossa pequena briga com Andersen, finalmente reformulamos a capa.

Imperador adulto.

Ceroulas históricas.

Coroa.

Dois vigaristas fingindo segurar tecido invisível.

Cortesãos constrangidos.

Uma criança apontando.

Mainframe ao fundo:

CONSENSUS = TRUE
EVIDENCE  = FALSE

A imagem saiu.

E ficou ótima.

O sistema continuou protegido.

O artigo continuou existindo.

Andersen atravessou o firewall.

Ninguém precisou abolir regra alguma.

Foi necessário apenas contexto.

Talvez essa pequena história contenha uma lição muito maior para o futuro da inteligência artificial.

Não precisamos escolher entre:

ALLOW EVERYTHING

e:

DENY EVERYTHING

Entre esses dois comandos existe praticamente toda a engenharia de segurança.

Existe risco.

Existe contexto.

Existe proporcionalidade.

Existe confiança.

Existe governança.

Existe liberdade legítima.

Existe dano real.

Existe falso positivo.

E existe o usuário.

Não esqueça o usuário.

Porque se construirmos uma fortaleza tão segura que ele precise sair dela para conseguir trabalhar, talvez tenhamos criado a fortaleza mais protegida do planeta.

Só existe um pequeno problema:

ninguém estará mais lá dentro.

E do lado de fora talvez exista uma máquina baixada de algum canto obscuro da Internet, executando sem auditoria, sem atualização, sem governança e sem guardrail algum.

O administrador olha orgulhoso para seu dashboard:

SECURITY STATUS: 100% GREEN
POLICY VIOLATIONS: ZERO
USERS: ZERO

Silêncio.

Uma criança passa pelo corredor.

Olha para o monitor.

Olha para o administrador.

E pergunta:

— Se todo mundo foi embora...

o que exatamente estamos protegendo?

Hans Christian Andersen sorri em algum lugar.

O velho sysprog toma outro gole de café.

E acrescenta:

CONTROL      ≠ SECURITY
RESTRICTION  ≠ SAFETY
COMPLIANCE   ≠ TRUST

SECURITY =
CONTROL
+ CONTEXT
+ PROPORTIONALITY
+ HUMAN BEHAVIOR

Porque o melhor firewall não é aquele que bloqueia o mundo.

É aquele que sabe distinguir o ataque do imperador de ceroulas.

ANDERSEN: ALLOW.

BULLSHIT DETECTOR: ENABLED.

RETURN CODE = 0000.

☕👑🧱🤖

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...