☕ 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

sábado, 18 de maio de 2024

Mainframe — O Gigante que Atravessou a Fronteira Final da Computação

Bellacosa Mainframe e o gigante que atravessou a fronteira final da computacao

☕ Um Café no Bellacosa Mainframe

Mainframe — O Gigante que Atravessou a Fronteira Final da Computação

Diário de bordo, data estelar 2024.05.18

A nave corporativa atravessa uma região silenciosa do espaço digital.

Nos monitores, milhões de transações surgem e desaparecem em frações de segundo. Pagamentos são autorizados. Reservas são confirmadas. Salários são calculados. Apólices são atualizadas. Pedidos são processados. Transferências bancárias cruzam redes inteiras.

Nenhum alarme soa.

Nenhuma explosão ilumina a ponte de comando.

Tudo simplesmente funciona.

No centro dessa operação existe uma máquina que muita gente acredita pertencer ao passado.

O mainframe.

Para o passageiro comum da galáxia tecnológica, a palavra “mainframe” costuma gerar uma imagem antiga: uma sala enorme e gelada, operadores de gravata, fitas magnéticas girando, cartões perfurados empilhados e painéis repletos de luzes piscando.

É uma imagem quase cinematográfica.

Parece o computador de bordo de uma nave criada durante os primeiros anos da corrida espacial. Um equipamento gigantesco, pesado e misterioso, cercado por técnicos que observam seus indicadores como se estivessem tentando impedir a destruição de um planeta.

Essa imagem não está completamente errada.

O erro está em acreditar que a história terminou ali.

O mainframe não permaneceu congelado no tempo. Ele mudou de forma, de arquitetura, de capacidade e de função. Diminuiu por fora, cresceu por dentro e aprendeu a conviver com praticamente todas as revoluções tecnológicas que surgiram depois dele.

Minicomputadores.

Computadores pessoais.

Redes locais.

Internet.

Servidores distribuídos.

Máquinas virtuais.

Nuvem.

APIs.

Containers.

Inteligência artificial.

Em vez de desaparecer, o mainframe incorporou novas tecnologias e continuou executando sua missão principal: processar grandes volumes de trabalho com segurança, confiabilidade e disponibilidade.

Portanto, jovem padawan do COBOL — ou, neste caso, novo cadete da Frota Estelar do processamento corporativo — prepare-se.

Vamos entrar na sala de máquinas.



1. O mito do dinossauro tecnológico

Quando uma tecnologia permanece em uso durante muitas décadas, ela corre o risco de ser chamada de ultrapassada.

Isso acontece porque as pessoas confundem idade com obsolescência.

Uma tecnologia antiga é aquela que surgiu há muito tempo.

Uma tecnologia obsoleta é aquela que deixou de atender às necessidades para as quais foi criada.

Essas duas coisas não são iguais.

A roda é antiga, mas não é obsoleta.

A escrita é antiga, mas não é obsoleta.

O sistema bancário é antigo, mas continua sendo atualizado.

O COBOL surgiu no final da década de 1950, mas ainda é usado porque resolve problemas de negócio que continuam existindo: cálculo, registro, controle, processamento de arquivos, atualização de bancos de dados e execução de transações.

O mesmo raciocínio vale para o mainframe.

Ele não sobreviveu porque as empresas sentem nostalgia de terminais verdes. Sobreviveu porque continua resolvendo problemas importantes.

Imagine uma instituição financeira processando milhões de operações diariamente.

Cada operação precisa ser:

  • autorizada corretamente;

  • registrada sem duplicidade;

  • protegida contra acesso indevido;

  • concluída dentro do tempo esperado;

  • recuperada em caso de falha;

  • auditável posteriormente.

Não basta executar rapidamente.

É preciso executar corretamente.

Essa diferença é fundamental.

Um sistema doméstico pode travar e ser reiniciado.

Um sistema bancário não pode simplesmente dizer:

“Desculpe, perdemos algumas transferências. Reinicie o aplicativo e tente novamente.”

Em ambientes críticos, disponibilidade e integridade não são recursos adicionais. São parte central da arquitetura.

O mainframe foi desenvolvido justamente para esse tipo de missão.


2. Antes do nome: quando os dados começaram a vencer os humanos

Antes de existir o mainframe, já existia o problema que faria nascer o mainframe.

O volume de informações crescia mais rapidamente do que a capacidade humana de organizá-las.

Governos precisavam realizar censos.

Empresas precisavam calcular salários.

Ferrovias precisavam controlar horários, cargas e passageiros.

Seguradoras precisavam manter registros de apólices.

Bancos precisavam registrar depósitos, empréstimos e saldos.

Exércitos precisavam cuidar de logística, suprimentos e pessoal.

Durante muito tempo, essas atividades foram realizadas manualmente. Exércitos inteiros de funcionários preenchiam formulários, copiavam números, conferiam tabelas e arquivavam documentos.

O problema era simples de compreender e terrível de resolver:

Mais pessoas
+
Mais empresas
+
Mais transações
+
Mais documentos
=
Mais complexidade

Em determinado momento, contratar mais funcionários já não resolvia o problema.

Era preciso automatizar.

Um dos acontecimentos mais importantes dessa história foi o uso de cartões perfurados no processamento do Censo dos Estados Unidos de 1890.

O cartão perfurado representava informações por meio de posições físicas. Um furo em determinado ponto podia significar idade, estado civil, profissão, região ou outra característica.

A máquina lia os furos e contabilizava os dados.

Isso parece primitivo hoje, mas representou uma mudança monumental.

A informação deixava de existir apenas como texto compreendido por humanos. Ela podia ser codificada de maneira que uma máquina também conseguisse processá-la.

Era o início de uma longa viagem.

Curiosidade de bordo

O cartão perfurado influenciou profundamente a cultura da computação.

Durante décadas, programadores escreviam seus programas em folhas de codificação. Depois, operadores perfuravam cada linha em um cartão.

Um programa COBOL com 500 linhas poderia significar 500 cartões físicos.

Agora imagine derrubar o baralho no chão.

Esse era um tipo de “falha de ordenação” muito mais dramático do que esquecer um ORDER BY.



3. O dia em que o computador arrumou um emprego

Os primeiros computadores eletrônicos eram frequentemente associados à ciência, à guerra ou à pesquisa.

Eles calculavam trajetórias, tabelas matemáticas e simulações.

Entretanto, o verdadeiro ponto de transformação aconteceu quando o computador deixou o laboratório e entrou na empresa.

O computador arrumou um emprego.

Passou a cuidar de tarefas administrativas e comerciais, como:

  • folha de pagamento;

  • faturamento;

  • contas a receber;

  • inventário;

  • processamento de cheques;

  • emissão de apólices;

  • controle de clientes;

  • reservas aéreas.

Esse momento é essencial para entender o mainframe.

A empresa não precisava apenas de uma calculadora rápida. Precisava de um sistema capaz de executar operações repetitivas, confiáveis e organizadas.

É nesse ambiente que linguagens como o COBOL ganham importância.

COBOL significa:

Common Business-Oriented Language

Ou seja:

Linguagem Comum Orientada a Negócios

Desde o início, sua missão era permitir que regras empresariais fossem representadas de maneira relativamente legível.

Veja um pequeno exemplo:

IF SALDO-CONTA >= VALOR-SAQUE
    SUBTRACT VALOR-SAQUE FROM SALDO-CONTA
    MOVE "SAQUE AUTORIZADO" TO MENSAGEM
ELSE
    MOVE "SALDO INSUFICIENTE" TO MENSAGEM
END-IF

Mesmo alguém com pouca experiência consegue perceber a lógica.

Essa clareza ajudou o COBOL a se tornar uma das principais linguagens do processamento empresarial.

Dica para o iniciante

Ao estudar COBOL, não observe apenas a sintaxe.

Pergunte sempre:

“Qual regra de negócio este programa representa?”

O verdadeiro poder do COBOL não está no MOVE, no PERFORM ou no IF.

Está na capacidade de transformar regras empresariais em processos executáveis.



4. De onde veio a palavra mainframe?

Nos primeiros grandes computadores, os componentes eram instalados em diferentes gabinetes, estruturas e armações metálicas.

O termo “main frame”, ou estrutura principal, passou a ser associado ao gabinete central que abrigava componentes importantes do sistema, especialmente a unidade central de processamento.

Com o tempo, a expressão deixou de representar apenas uma parte física e passou a identificar uma categoria inteira de computadores.

Entretanto, definir mainframe apenas pelo tamanho seria um erro.

Um mainframe moderno não precisa ocupar uma sala inteira.

O que caracteriza a plataforma é principalmente sua arquitetura e sua capacidade de lidar com cargas de trabalho críticas em grande escala.

Entre suas características estão:

  • processamento intenso de transações;

  • grande capacidade de entrada e saída;

  • alta disponibilidade;

  • tolerância a falhas;

  • isolamento entre cargas de trabalho;

  • segurança integrada;

  • capacidade de virtualização;

  • gerenciamento sofisticado de recursos.

Portanto, mainframe não significa simplesmente “computador grande”.

Significa uma plataforma projetada para sustentar operações centrais de grandes organizações.



5. A guerra dos gigantes

A história dos mainframes não pertence a uma única empresa.

Durante várias décadas, fabricantes disputaram o domínio do mercado de computação corporativa.

Entre os nomes mais importantes estavam:

  • IBM;

  • UNIVAC;

  • Burroughs;

  • NCR;

  • Honeywell;

  • Control Data Corporation;

  • RCA;

  • Fujitsu;

  • Hitachi;

  • Siemens;

  • ICL.

Esse período ficou conhecido informalmente por diversas classificações da indústria. Uma das mais famosas agrupava os grandes concorrentes da IBM sob a expressão “BUNCH”:

B — Burroughs
U — UNIVAC
N — NCR
C — Control Data
H — Honeywell

Cada fabricante possuía sua própria visão de arquitetura.

Não existia um padrão universal.

Um programa criado para determinada máquina normalmente não era transferido facilmente para outra.

Os sistemas possuíam diferenças em:

  • conjunto de instruções;

  • formato de dados;

  • tamanho de palavra;

  • periféricos;

  • sistemas operacionais;

  • compiladores;

  • ferramentas;

  • procedimentos de operação.

Escolher um computador era quase como escolher uma civilização inteira.

A empresa não comprava apenas uma máquina.

Comprava um ecossistema.

Easter egg da Frota

Essa disputa lembra as grandes espécies tecnológicas de uma galáxia fictícia.

Cada fabricante tinha seu idioma, seus protocolos, sua engenharia e sua filosofia.

Migrar de uma arquitetura para outra podia ser tão complicado quanto pedir para uma nave romulana usar peças klingons durante uma batalha.



6. A revolução do System/360

Um dos acontecimentos mais importantes na história da computação empresarial foi o lançamento da família IBM System/360 em 1964.

A ideia era criar uma linha compatível de computadores.

Modelos diferentes poderiam atender empresas de tamanhos e necessidades distintas, mas compartilhariam uma arquitetura comum.

Isso permitia que uma organização começasse com uma configuração menor e migrasse para outra mais potente sem abandonar completamente seus programas e conhecimentos.

Essa compatibilidade foi revolucionária.

O número 360 sugeria cobertura completa, como os 360 graus de um círculo.

A proposta era atender diferentes tipos de processamento:

  • científico;

  • comercial;

  • governamental;

  • industrial.

Para quem trabalha com mainframe hoje, essa decisão histórica continua importante.

Grande parte da força da plataforma vem da ideia de continuidade.

As empresas investiram décadas desenvolvendo programas, bases de dados e regras de negócio.

Jogar tudo fora a cada nova geração de hardware seria economicamente inviável.

O mainframe evoluiu preservando compatibilidade sempre que possível.

Isso não significa ausência de mudança.

Significa evolução controlada.


7. Quando o software aprendeu a fazer muitas coisas ao mesmo tempo

Nos primeiros sistemas, era comum processar um trabalho por vez.

O usuário entregava um conjunto de cartões.

O operador carregava o programa.

A máquina executava.

O resultado era impresso.

Depois, o próximo trabalho começava.

Esse modelo ficou conhecido como processamento em lote, ou batch.

O batch continua existindo e sendo extremamente importante. Entretanto, os primeiros ambientes desperdiçavam tempo porque a CPU frequentemente aguardava operações lentas de entrada e saída.

Imagine uma CPU capaz de executar milhares ou milhões de instruções, esperando uma leitora de cartões ou uma impressora terminar sua tarefa.

Era como usar o motor de dobra de uma nave apenas para acender as luzes da cabine.

A solução foi permitir que vários trabalhos permanecessem no sistema ao mesmo tempo.

Enquanto um job aguardava uma operação de disco ou fita, outro poderia utilizar o processador.

Esse conceito ficou conhecido como multiprogramação.

De maneira simplificada:

JOB A usa CPU
JOB A espera disco
JOB B usa CPU
JOB B espera fita
JOB C usa CPU

O sistema operacional passa a organizar essa alternância.

Assim surgem funções fundamentais:

  • escalonamento;

  • gerenciamento de memória;

  • controle de prioridades;

  • proteção entre programas;

  • tratamento de interrupções;

  • alocação de dispositivos.

Hoje consideramos tudo isso normal.

Na época, era uma mudança gigantesca.


8. Time-sharing: uma máquina, muitos usuários

Outro avanço decisivo foi o compartilhamento de tempo, ou time-sharing.

A ideia era dividir pequenas parcelas do tempo do processador entre diferentes usuários.

Cada pessoa, diante de um terminal, tinha a impressão de estar usando o computador individualmente.

Na realidade, o sistema alternava rapidamente entre diferentes sessões.

Imagine três usuários:

Usuário A recebe alguns milissegundos
Usuário B recebe alguns milissegundos
Usuário C recebe alguns milissegundos
Depois o ciclo recomeça

Como essa alternância acontece rapidamente, cada usuário percebe uma experiência interativa.

Esse conceito ajudou a transformar o computador.

Ele deixou de ser apenas uma máquina que recebia lotes de trabalho e devolvia resultados horas depois.

Passou a responder diretamente às pessoas.

Para um programador COBOL, essa evolução é importante porque ajuda a compreender a diferença entre dois universos:

Processamento batch
e
Processamento online

No batch, o programa normalmente lê grandes volumes de dados e produz atualizações ou relatórios.

No online, o programa responde a uma solicitação imediata, frequentemente por meio de monitores transacionais como o CICS.


9. Virtualização: uma máquina física parecendo várias

Uma das maiores contribuições do mundo mainframe foi o amadurecimento da virtualização.

Virtualizar significa permitir que um único computador físico se comporte como vários computadores independentes.

Cada ambiente virtual pode possuir:

  • sistema operacional;

  • memória;

  • usuários;

  • aplicações;

  • configurações;

  • recursos controlados.

Isso permite melhor aproveitamento do hardware e maior isolamento.

De maneira simplificada:

Hardware físico
        |
        +-- Máquina virtual A
        |
        +-- Máquina virtual B
        |
        +-- Máquina virtual C

Hoje a virtualização é comum em servidores, clouds e ambientes de desenvolvimento.

Entretanto, o mainframe já utilizava esse conceito em grande escala muito antes de ele se tornar moda no restante da indústria.

Curiosidade

Quando alguém diz que a virtualização nasceu com os servidores modernos, um veterano de mainframe provavelmente levanta uma sobrancelha.

Talvez não diga nada.

Mas em pensamento estará executando:

IF AFIRMACAO = "VIRTUALIZACAO E NOVA"
    DISPLAY "REGISTRO HISTORICO INCONSISTENTE"
END-IF

10. O habitat da máquina

Comprar um grande computador era apenas o começo.

Era preciso construir um mundo para mantê-lo funcionando.

Os antigos centros de processamento de dados exigiam uma infraestrutura cuidadosamente planejada.

Piso elevado

O piso elevado criava um espaço sob a sala.

Esse espaço podia ser usado para:

  • passagem de cabos;

  • distribuição de ar;

  • organização elétrica;

  • acesso à infraestrutura.

O chão do CPD não era apenas um piso.

Era parte do sistema.

Refrigeração

Computadores geram calor.

Os grandes equipamentos antigos geravam muito calor.

Era necessário controlar:

  • temperatura;

  • umidade;

  • circulação de ar;

  • pontos quentes;

  • estabilidade ambiental.

Algumas instalações utilizavam sistemas de água gelada.

Energia

Um ambiente crítico precisava de energia confiável.

Isso envolvia:

  • alimentação elétrica dedicada;

  • estabilização;

  • nobreaks;

  • geradores;

  • circuitos redundantes;

  • procedimentos de contingência.

Cabeamento

Os cabos eram grossos, numerosos e muitas vezes percorriam grandes distâncias.

Conectar processadores, controladores, discos, fitas, impressoras e terminais exigia planejamento.

Segurança física

O acesso ao CPD era controlado.

Não era uma sala em que qualquer funcionário entrava para tomar café.

Existiam regras, registros, permissões e procedimentos.

O ambiente representava o centro nervoso da empresa.


11. Discos, fitas e o universo do armazenamento

O armazenamento também mudou profundamente.

Os primeiros discos possuíam capacidades minúsculas quando comparadas aos padrões atuais, mas eram enormes fisicamente.

Unidades de disco podiam ocupar gabinetes inteiros.

As fitas magnéticas eram essenciais para:

  • backup;

  • arquivamento;

  • transporte de dados;

  • processamento sequencial;

  • retenção histórica.

No mundo COBOL, ainda é importante compreender a lógica sequencial.

Muitos programas processam arquivos em ordem:

Ler registro
Validar registro
Processar registro
Gravar saída
Ler próximo registro

Esse padrão continua extremamente eficiente para grandes volumes.

Um exemplo conceitual em COBOL:

PERFORM UNTIL FIM-ARQUIVO = "S"
    READ ARQUIVO-ENTRADA
        AT END
            MOVE "S" TO FIM-ARQUIVO
        NOT AT END
            PERFORM PROCESSAR-REGISTRO
    END-READ
END-PERFORM

O programa trabalha registro por registro até atingir o final do arquivo.

Essa lógica pode parecer simples, mas é usada em processos que movimentam milhões de registros.


12. IBM 3090, IBM 9021 e o lendário “agazão”

Para muitos profissionais brasileiros, máquinas como o IBM 3090 e o IBM 9021 não são apenas nomes em livros.

São parte da memória profissional.

Representavam grandes configurações instaladas em ambientes onde cada detalhe importava.

O operador observava consoles, unidades, filas de jobs e mensagens do sistema.

O ruído do ambiente, o ar frio e a presença física dos equipamentos criavam uma sensação difícil de reproduzir atualmente.

Em alguns ambientes, determinadas configurações eram chamadas informalmente de “agazão”.

Apelidos desse tipo fazem parte da cultura de operação.

Toda equipe acaba criando um vocabulário próprio.

Máquinas recebem nomes.

Salas ganham apelidos.

Procedimentos viram expressões.

Erros históricos transformam-se em lendas internas.

Easter egg do veterano

Todo CPD antigo possuía pelo menos uma história que começava assim:

“Isso aconteceu no turno da madrugada, mas ninguém sabe exatamente quem estava no console.”

Normalmente, três pessoas contam versões diferentes.

Todas afirmam que salvaram o sistema.


13. O mainframe não é apenas hardware

Um erro comum do iniciante é pensar no mainframe somente como uma máquina.

Na realidade, estamos falando de uma plataforma completa.

Ela envolve:

  • hardware;

  • sistema operacional;

  • subsistemas;

  • linguagens;

  • compiladores;

  • bancos de dados;

  • monitores transacionais;

  • ferramentas de segurança;

  • ferramentas operacionais;

  • redes;

  • armazenamento;

  • processos empresariais.

Em um ambiente z/OS, por exemplo, você pode encontrar:

  • JES2 para gerenciamento de jobs;

  • TSO/E para interação com o sistema;

  • ISPF para navegação e desenvolvimento;

  • CICS para processamento transacional;

  • Db2 para banco de dados relacional;

  • IMS para banco de dados e transações;

  • RACF para segurança;

  • DFSMS para gerenciamento de armazenamento;

  • SMP/E para manutenção de software;

  • WLM para gerenciamento de cargas de trabalho.

Cada componente possui uma função.

Juntos, formam uma espécie de nave interestelar corporativa.

A CPU é importante, mas não viaja sozinha.


14. O caminho de um programa COBOL

Para o iniciante, o ambiente mainframe pode parecer enorme e confuso.

A melhor forma de aprender é seguir o caminho de um programa.

Vamos imaginar um programa batch simples.

Passo 1 — Escrever o código-fonte

O programa COBOL é armazenado em um dataset ou em um repositório integrado ao fluxo de desenvolvimento.

Passo 2 — Compilar

O compilador analisa o código.

Ele verifica:

  • sintaxe;

  • definição de dados;

  • comandos;

  • referências;

  • estruturas.

Se houver erros, produz mensagens.

Passo 3 — Link-edit

Após a compilação, o código objeto precisa ser transformado em um módulo executável.

Esse processo cria o load module ou program object.

Passo 4 — Executar com JCL

O JCL informa ao sistema:

  • qual programa executar;

  • quais arquivos usar;

  • onde gravar resultados;

  • quais recursos são necessários.

Exemplo simplificado:

//JOB01    JOB ...
//STEP01   EXEC PGM=PGMCOBOL
//ENTRADA  DD DSN=EMPRESA.ARQUIVO.ENTRADA,DISP=SHR
//SAIDA    DD DSN=EMPRESA.ARQUIVO.SAIDA,
//            DISP=(NEW,CATLG,DELETE)
//SYSOUT    DD SYSOUT=*

Passo 5 — Acompanhar o job

O job é enviado ao JES.

Depois, o programador consulta:

  • retorno;

  • mensagens;

  • spool;

  • códigos de condição;

  • possíveis abends.

Passo 6 — Validar o resultado

Não basta o job terminar com código zero.

É necessário confirmar que o resultado está correto.

Essa é uma lição importante:

Execução técnica bem-sucedida
não significa necessariamente
resultado de negócio correto

Um programa pode terminar sem erro e ainda calcular valores errados.



15. Batch e online: duas missões diferentes

No processamento batch, o sistema executa um conjunto de tarefas sem interação contínua com o usuário.

Exemplos:

  • fechamento diário;

  • cálculo de juros;

  • geração de extratos;

  • processamento de folha;

  • consolidação contábil;

  • atualização de grandes arquivos.

No processamento online, a resposta precisa ser rápida.

Exemplos:

  • consulta de saldo;

  • autorização de pagamento;

  • reserva de passagem;

  • atualização cadastral;

  • emissão de pedido.

Em ambientes mainframe, o CICS tornou-se uma das plataformas mais importantes para processamento online.

Um fluxo moderno pode ser:

Usuário
   ↓
Aplicativo móvel
   ↓
API
   ↓
z/OS Connect
   ↓
CICS
   ↓
Programa COBOL
   ↓
Db2

Perceba algo importante.

O usuário pode estar usando um aplicativo moderno, mas a regra de negócio continua sendo executada por um programa COBOL.

O COBOL não precisa aparecer na tela para continuar sendo essencial.



16. O gigante invisível

Durante décadas, especialistas anunciaram a morte do mainframe.

Primeiro, disseram que seria substituído pelos minicomputadores.

Depois, pelos PCs.

Depois, pelos servidores Unix.

Depois, pela arquitetura cliente-servidor.

Depois, pela internet.

Depois, pela nuvem.

Agora, alguns dizem que será substituído pela inteligência artificial.

Essas previsões geralmente cometem o mesmo erro.

Elas imaginam a tecnologia como uma batalha em que apenas um participante pode sobreviver.

Na prática, novas plataformas não eliminam automaticamente as anteriores.

Elas passam a coexistir.

Um banco pode utilizar:

  • mainframe para transações centrais;

  • cloud para novos serviços digitais;

  • aplicações móveis para clientes;

  • APIs para integração;

  • inteligência artificial para análise;

  • containers para microsserviços.

A arquitetura moderna é híbrida.

O mainframe não precisa executar tudo.

Ele precisa executar muito bem aquilo que está sob sua responsabilidade.


17. Por que o mainframe desapareceu das fotografias?

Nas décadas passadas, o computador era fisicamente visível.

Grandes salas eram fotografadas.

Executivos apareciam ao lado das máquinas.

O equipamento simbolizava modernidade.

Hoje, o usuário vê apenas interfaces.

Aplicativos escondem a infraestrutura.

Quando uma pessoa faz uma transferência, ela enxerga:

  • um botão;

  • um valor;

  • uma confirmação.

Ela não vê:

  • filas de mensagens;

  • logs;

  • bancos de dados;

  • controle de concorrência;

  • criptografia;

  • recuperação;

  • monitoramento;

  • transações distribuídas.

O mainframe tornou-se invisível porque a computação tornou-se invisível.

E isso é um sinal de sucesso.

Uma infraestrutura realmente madura não exige que o usuário compreenda cada componente.

Ela apenas funciona.



18. Segurança: o campo de força da nave

Grandes organizações precisam controlar cuidadosamente quem pode acessar cada recurso.

Em um ambiente mainframe, segurança envolve diferentes níveis:

  • identificação do usuário;

  • autenticação;

  • autorização;

  • proteção de datasets;

  • controle de programas;

  • auditoria;

  • criptografia;

  • segregação de funções.

No z/OS, produtos como RACF ajudam a administrar identidades e permissões.

Um usuário pode ter acesso a determinado dataset, mas não a outro.

Pode executar um programa, mas não alterar sua biblioteca.

Pode visualizar uma transação, mas não aprová-la.

Isso representa o princípio do menor privilégio:

Cada pessoa deve possuir apenas os acessos necessários para realizar sua função.

Para o programador COBOL iniciante, isso significa que muitos erros de acesso não são falhas do programa.

Podem ser problemas de autorização.

Ao receber uma mensagem de acesso negado, não tente resolver copiando dados para qualquer lugar.

Investigue:

  1. Qual recurso está sendo acessado?

  2. Qual usuário executa o job?

  3. Qual permissão é necessária?

  4. O acesso está de acordo com a política?

  5. Quem deve autorizar a mudança?

Segurança não é obstáculo.

É parte do sistema.


19. Disponibilidade: quando parar não é opção

Mainframes são associados a alta disponibilidade porque foram projetados para ambientes onde interrupções podem gerar enormes prejuízos.

Isso envolve:

  • componentes redundantes;

  • manutenção planejada;

  • recuperação de falhas;

  • monitoramento;

  • isolamento de problemas;

  • gerenciamento de workload;

  • procedimentos operacionais.

Alta disponibilidade não significa que nada jamais falhará.

Significa que o sistema é preparado para:

  • detectar;

  • isolar;

  • recuperar;

  • continuar operando.

Essa é uma diferença importante.

A engenharia séria não pressupõe ausência de falhas.

Ela pressupõe que falhas acontecerão e cria mecanismos para reduzir seus efeitos.

Regra de ouro

Um sistema crítico não deve perguntar:

“E se algo falhar?”

Ele deve perguntar:

“Quando algo falhar, como continuaremos funcionando?”



20. WLM: o oficial de operações

Em um ambiente com muitas cargas de trabalho, alguém precisa decidir quais tarefas são mais importantes.

No z/OS, o Workload Manager, ou WLM, ajuda a administrar recursos conforme objetivos definidos.

Imagine:

  • transações bancárias online;

  • relatórios internos;

  • processamento de teste;

  • jobs de desenvolvimento;

  • fechamento contábil.

Todos competem por recursos.

Porém, nem todos possuem a mesma prioridade.

Uma transação de cliente pode precisar de resposta em segundos.

Um relatório interno talvez possa esperar alguns minutos.

O WLM trabalha com metas e importância.

É como um oficial de operações decidindo:

Missão crítica: prioridade máxima
Análise científica: prioridade média
Simulação de treinamento: prioridade menor

O objetivo não é simplesmente tornar tudo rápido.

É entregar o nível de serviço adequado para cada carga.



21. Mainframe e nuvem não são inimigos

A nuvem popularizou ideias como:

  • provisionamento sob demanda;

  • elasticidade;

  • automação;

  • serviços gerenciados;

  • pagamento conforme uso;

  • APIs;

  • infraestrutura programável.

O mainframe possui outra história, mas pode integrar-se a esse universo.

Empresas modernas constroem ambientes híbridos.

Um serviço na nuvem pode chamar uma API que acessa uma transação no mainframe.

Dados do mainframe podem alimentar análises externas.

Aplicações containerizadas podem interagir com programas COBOL.

Pipelines DevOps podem compilar, testar e implantar código mainframe.

A pergunta correta não é:

“Mainframe ou cloud?”

A pergunta correta é:

“Qual plataforma deve executar cada parte do sistema?”

Essa abordagem evita decisões baseadas em moda.



22. APIs: o tradutor universal

Durante muito tempo, sistemas mainframe eram acessados principalmente por terminais ou integrações específicas.

Hoje, APIs permitem expor funções de negócio de maneira padronizada.

Imagine um programa COBOL que consulta o limite de crédito de um cliente.

Essa função pode ser disponibilizada como uma API.

O aplicativo chama:

GET /clientes/123/limite

A camada de integração converte a solicitação.

O programa COBOL executa a regra.

O resultado retorna em JSON.

Exemplo:

{
  "cliente": 123,
  "limite": 7500.00,
  "disponivel": 3250.00
}

O programa COBOL não precisa “virar JavaScript”.

Ele continua executando sua lógica.

A API funciona como um tradutor universal entre diferentes mundos tecnológicos.

Dica para iniciantes

Ao estudar modernização, não pense apenas em reescrever.

Existem várias estratégias:

  • expor;

  • integrar;

  • encapsular;

  • refatorar;

  • substituir;

  • manter.

Reescrever tudo costuma ser a opção mais arriscada e cara.



23. DevOps chegou à sala de máquinas

Existe outro estereótipo comum:

“Mainframe não combina com DevOps.”

Isso também está errado.

Ambientes modernos podem utilizar:

  • Git;

  • integração contínua;

  • entrega contínua;

  • testes automatizados;

  • análise de código;

  • pipelines;

  • revisão por pull request;

  • automação de deployment;

  • infraestrutura como código.

Ferramentas tradicionais continuam existindo, mas podem ser integradas a fluxos modernos.

O programador pode trabalhar com editores contemporâneos, como extensões para VS Code, sem abandonar a robustez do ambiente central.

A cultura DevOps não depende de uma linguagem específica.

Ela depende de práticas:

  • colaboração;

  • automação;

  • feedback rápido;

  • rastreabilidade;

  • qualidade;

  • entrega segura.

COBOL também pode participar dessa jornada.


24. Inteligência artificial no universo mainframe

A inteligência artificial pode atuar em diferentes áreas do mainframe:

  • análise de logs;

  • detecção de anomalias;

  • previsão de capacidade;

  • identificação de fraudes;

  • apoio à modernização;

  • compreensão de código legado;

  • geração de testes;

  • documentação;

  • atendimento operacional.

Também existem processadores e recursos especializados para executar inferências próximas aos dados e às transações.

Isso pode ser importante porque mover grandes volumes de dados para fora do ambiente gera:

  • custo;

  • latência;

  • risco;

  • complexidade.

Executar determinadas análises perto da origem dos dados pode ser mais eficiente.

Entretanto, inteligência artificial não elimina a necessidade de conhecimento humano.

Ela pode ajudar a explicar um programa COBOL.

Mas alguém ainda precisa validar:

  • a regra de negócio;

  • os dados;

  • as exceções;

  • os impactos;

  • os requisitos regulatórios.

Uma resposta convincente não é automaticamente uma resposta correta.

Nem mesmo o computador mais inteligente da galáxia deve alterar a folha de pagamento sem testes.



25. Passo a passo para começar no mainframe

Agora chegamos ao roteiro prático para o novo cadete.

Etapa 1 — Aprenda a navegação

Antes de programar, entenda o ambiente.

Estude:

  • TSO;

  • ISPF;

  • datasets;

  • membros;

  • painéis;

  • comandos básicos.

Objetivo:

Ser capaz de localizar, abrir e editar informações.

Etapa 2 — Entenda datasets

Aprenda a diferença entre:

  • dataset sequencial;

  • PDS;

  • PDSE;

  • VSAM;

  • arquivos temporários;

  • gerações de GDG.

Observe atributos como:

  • RECFM;

  • LRECL;

  • BLKSIZE;

  • organização;

  • espaço.

Etapa 3 — Estude JCL

Comece por:

  • JOB;

  • EXEC;

  • DD;

  • DISP;

  • DSN;

  • SYSOUT;

  • parâmetros de execução.

Não tente decorar tudo.

Crie pequenos jobs e observe o resultado.

Etapa 4 — Aprenda COBOL básico

Domine:

  • IDENTIFICATION DIVISION;

  • ENVIRONMENT DIVISION;

  • DATA DIVISION;

  • PROCEDURE DIVISION;

  • PIC;

  • MOVE;

  • IF;

  • EVALUATE;

  • PERFORM;

  • READ;

  • WRITE;

  • COMPUTE.

Etapa 5 — Compile um programa

Acompanhe cada fase:

Fonte
↓
Compilação
↓
Objeto
↓
Link-edit
↓
Executável
↓
Execução

Etapa 6 — Aprenda a ler o spool

O spool conta a história do job.

Procure:

  • mensagens;

  • retorno;

  • passos executados;

  • datasets usados;

  • erros;

  • abends.

Etapa 7 — Trabalhe com arquivos

Crie programas que:

  • leiam entrada;

  • validem registros;

  • calculem resultados;

  • produzam saída;

  • gerem totais.

Etapa 8 — Estude Db2 ou VSAM

Depois da base, avance para persistência de dados.

No Db2, estude:

  • SELECT;

  • INSERT;

  • UPDATE;

  • DELETE;

  • cursor;

  • SQLCODE;

  • commit;

  • rollback.

Etapa 9 — Conheça o CICS

Aprenda o conceito de transação online.

Entenda:

  • mapa;

  • tela;

  • COMMAREA;

  • canais e containers;

  • LINK;

  • XCTL;

  • filas;

  • integração com Db2.

Etapa 10 — Entenda o negócio

Essa é a fase mais importante.

Pergunte:

  • O que o sistema faz?

  • Quem utiliza?

  • Qual dado é crítico?

  • Qual erro é aceitável?

  • Qual erro é desastroso?

  • Existe auditoria?

  • Existe recuperação?

O melhor programador não é quem conhece mais comandos.

É quem compreende o impacto daquilo que modifica.



26. Erros comuns do iniciante

Decorar sem compreender

Copiar JCL sem entender cada DD pode funcionar até o dia em que algo mudar.

Ignorar mensagens

O sistema frequentemente explica o problema.

Leia as mensagens antes de alterar o código aleatoriamente.

Testar apenas o caso feliz

Considere:

  • arquivo vazio;

  • campo inválido;

  • valor negativo;

  • registro duplicado;

  • fim inesperado;

  • acesso negado;

  • indisponibilidade de recurso.

Alterar produção diretamente

Ambientes críticos exigem controle.

Use:

  • desenvolvimento;

  • teste;

  • homologação;

  • aprovação;

  • implantação planejada.

Achar que código antigo é código ruim

Um programa antigo pode representar décadas de conhecimento de negócio.

Antes de criticá-lo, entenda por que foi construído daquela forma.

Reescrever por impulso

Código novo também contém bugs.

A modernização deve ser orientada por objetivos reais, não por vergonha da idade do sistema.



27. Curiosidades da ponte de comando

O COBOL foi pensado para negócios

Sua sintaxe mais verbal não é um acidente. A intenção era aproximar o código da linguagem empresarial.

O mainframe ajudou a popularizar virtualização

Décadas antes de a palavra “cloud” dominar apresentações corporativas, grandes sistemas já compartilhavam hardware entre ambientes isolados.

O batch não morreu

Processar milhões de registros em lote continua sendo uma solução eficiente.

Nem tudo precisa ser uma API síncrona.

Terminais não são o mainframe

O terminal é apenas uma interface.

Confundir tela verde com mainframe é como confundir o painel da nave com o motor de dobra.

COBOL moderno não é COBOL de 1960

Compiladores modernos possuem otimizações, integração com novas tecnologias e recursos que não existiam nas primeiras versões da linguagem.

O maior risco pode estar fora do código

Muitos incidentes são causados por:

  • configuração;

  • permissão;

  • dados;

  • processo;

  • comunicação;

  • implantação inadequada.

Nem todo problema termina em IDENTIFICATION DIVISION.


28. O verdadeiro segredo da longevidade

Por que o mainframe continua vivo?

Não existe uma única resposta.

Ele sobrevive porque combina vários fatores:

  • compatibilidade;

  • confiabilidade;

  • capacidade de processamento;

  • segurança;

  • investimento acumulado;

  • conhecimento de negócio;

  • integração;

  • evolução arquitetural.

Mas talvez exista uma resposta ainda mais profunda.

O mainframe sobreviveu porque nunca foi apenas uma máquina.

Ele se tornou parte das operações das empresas.

Um programa COBOL pode parecer um conjunto de comandos.

Na prática, ele pode representar:

  • regras tributárias;

  • contratos;

  • políticas de crédito;

  • cálculos atuariais;

  • processos contábeis;

  • obrigações regulatórias;

  • décadas de decisões empresariais.

Substituir o código não significa apenas trocar uma linguagem.

Significa reconstruir conhecimento.

E conhecimento perdido pode ser mais caro do que hardware.


29. O easter egg escondido no núcleo

Existe uma mensagem secreta em toda essa história.

Ela não está em hexadecimal.

Não está escondida em um registrador.

Não aparece em um dump.

A mensagem é esta:

O futuro da tecnologia não é construído apenas descartando o passado. Muitas vezes, ele é construído conectando o que funciona com aquilo que acaba de surgir.

Essa é uma lição importante para qualquer programador.

Tecnologia não é uma sequência de destruições completas.

É uma sequência de camadas.

O sistema moderno ainda carrega ideias antigas:

  • arquivos;

  • filas;

  • transações;

  • processos;

  • permissões;

  • logs;

  • escalonamento;

  • virtualização.

Mudam os nomes.

Mudam as interfaces.

Mudam as ferramentas.

Os problemas fundamentais frequentemente permanecem.



30. Conclusão — A fronteira final não é o espaço

Depois de atravessar décadas de história, chegamos ao presente.

O mainframe não é um monstro pré-histórico esperando a própria extinção.

Ele é uma plataforma que aprendeu a evoluir sem abandonar sua missão.

Começou em uma época de cartões perfurados, fitas magnéticas e grandes salões refrigerados.

Participou da transformação do computador em ferramenta empresarial.

Atravessou a guerra entre fabricantes.

Ajudou a amadurecer conceitos como multiprogramação, compartilhamento de tempo e virtualização.

Sustentou grandes centros de processamento.

Sobreviveu à ascensão dos PCs, dos servidores, da internet e da nuvem.

E agora integra-se a APIs, containers, DevOps e inteligência artificial.

Para o programador COBOL iniciante, compreender essa história é mais do que conhecer máquinas antigas.

É entender o motivo pelo qual determinadas práticas existem.

É perceber por que segurança, disponibilidade e integridade recebem tanta atenção.

É compreender que um programa não vive isolado.

Ele faz parte de uma arquitetura, de um processo e de uma organização.

Quando você escrever seu primeiro MOVE, executar seu primeiro job ou investigar seu primeiro abend, lembre-se de que está entrando em uma tradição construída por gerações de profissionais.

Alguns trabalharam com cartões.

Outros com terminais.

Outros com editores modernos.

Mas todos enfrentaram a mesma missão:

Receber dados
Aplicar regras
Produzir resultados corretos
Proteger o negócio
Manter o sistema funcionando

A fronteira final da computação não é uma linguagem, uma máquina ou uma nuvem.

É a capacidade de construir sistemas nos quais milhões de pessoas confiam sem sequer perceber que eles estão ali.

O mainframe tornou-se invisível.

Mas invisível não significa ausente.

Em algum lugar, enquanto você lê este artigo, uma transação está sendo executada, um registro está sendo atualizado e um programa COBOL está cumprindo silenciosamente sua missão.

Na ponte de comando, as luzes permanecem estáveis.

O sistema está operacional.

A viagem continua.

Vida longa ao COBOL.

Vida longa ao mainframe.

E que seus jobs terminem sempre com MAXCC=0000.

 

sexta-feira, 17 de maio de 2024

🤖 Os 12 Macacos, COBOL e o Dia em que o Algoritmo Aprendeu Nossos Códigos ARCO I — CAPÍTULO V

 

Bellacosa Mainframe e os 12 macacos

☕ Um Café no Bellacosa Mainframe

🤖 Os 12 Macacos, COBOL e o Dia em que o Algoritmo Aprendeu Nossos Códigos

ARCO I — CAPÍTULO V

Filtros, emojis, memes e a guerra semântica — quando bloquear uma palavra deixou de significar bloquear uma ideia

Você pode proibir uma palavra. O problema começa cinco minutos depois, quando alguém inventa outra para dizer exatamente a mesma coisa.


🕰️ 00:04 — SEMANTIC ARMS RACE INITIALIZED

No capítulo anterior, nosso COBOLzeiro finalmente havia organizado o caos.

Depois de horas discutindo liberdade de expressão, ECA, moderação, regras privadas, investigação e Direito brasileiro, ele conseguiu produzir uma arquitetura razoavelmente compreensível:

INDIVÍDUO
    |
    v
COMUNIDADE
    |
    v
PLATAFORMA
    |
    v
AUTORIDADES
    |
    v
JUDICIÁRIO

Cinco camadas.

Cinco responsabilidades diferentes.

Finalmente algo parecido com produção.

Ele tomou café.

Respirou.

E cometeu o erro clássico de todo profissional de TI:

achou que tinha terminado.

O terminal imediatamente começou a piscar.

WARNING
WARNING
WARNING

NEW EVENT DETECTED.

FILTERED WORD............ PALAVRA-X
USER RESPONSE............ CÓDIGO-X

FILTER UPDATED........... YES

USER RESPONSE............ EMOJI

FILTER UPDATED........... YES

USER RESPONSE............ MEME

FILTER UPDATED........... PARTIAL

USER RESPONSE............ IRONY

CLASSIFICATION........... UNKNOWN

Nosso programador olhou para Bruce Willis.

— O filtro está quebrado?

— Não.

— Então por que não funciona?

Bruce apontou para a tela.

— Porque os usuários perceberam que ele existe.

Silêncio.

O terminal acrescentou:

THE OBSERVED SYSTEM
HAS DETECTED
THE OBSERVER.

Terry Gilliam acabara de entrar novamente no CPD.


🧱 1. O primeiro filtro era maravilhosamente burro

Vamos começar pelo mundo simples.

Imagine que determinada comunidade proíba uma palavra.

Chamaremos de:

PALAVRA-PROIBIDA

O programador cria:

IF MESSAGE CONTAINS "PALAVRA-PROIBIDA"
    REJECT MESSAGE
END-IF

Maravilhoso.

Determinístico.

Auditável.

Compreensível.

O COBOLzeiro gosta.

Entrada:

PALAVRA-PROIBIDA

Resultado:

BLOCKED

Produção resolvida.

Ticket fechado.

Café.

Até alguém escrever:

P4L4VR4-PR0IBID4

Nosso programa olha.

Não encontrou a string.

RETURN-CODE = 0

Mensagem publicada.

O programador derruba a caneca.


🔤 2. Nasce a mutação ortográfica

Então começa a guerra.

Filtro:

PALAVRA

Usuário:

P4L4VR4

Filtro atualizado.

Usuário:

P@L@VR@

Filtro atualizado.

Usuário:

P A L A V R A

Filtro atualizado.

Usuário:

P∆L∆VR∆

Filtro atualizado.

Usuário:

P.alavra

Filtro atualizado.

Usuário:

P🍎L🍎VR🍎

Nosso COBOLzeiro olha para o teclado.

— Posso desligar os usuários?

Bruce Willis responde:

— Continuamos sem essa opção.


🧬 3. A palavra virou organismo evolutivo

Lembra do Capítulo I?

Falamos sobre informação se comportando metaforicamente como epidemia.

Agora aparece outra propriedade interessante:

pressão seletiva.

Se determinada forma de comunicação é bloqueada, usuários interessados em continuar comunicando aquela ideia procuram alternativas.

Não precisamos imaginar uma conspiração.

É adaptação.

EXPRESSÃO A
     |
     v
   FILTRO
     |
     X

Surge:

EXPRESSÃO B

Depois:

EXPRESSÃO C

Depois:

SÍMBOLO

Depois:

MEME

Depois:

PIADA INTERNA

O filtro não eliminou necessariamente o significado.

Ele modificou a representação do significado.

Essa distinção é gigantesca.


🧠 4. Palavra e significado não são a mesma coisa

Nosso programador comete um erro perfeitamente compreensível:

PALAVRA = SIGNIFICADO

Não.

Uma palavra aponta para conceitos.

Mas conceitos podem ser expressos de inúmeras maneiras.

Considere algo banal.

Queremos dizer:

"Está muito frio."

Podemos escrever:

Está muito frio.

Ou:

"Estou congelando."

Ou:

"Hoje virou Sibéria."

Ou simplesmente:

🥶

Ou mandar a foto de um pinguim.

O significado emerge do contexto.

Agora tente criar:

IF MESSAGE = "ESTÁ FRIO"

Você capturará uma fração das maneiras humanas de expressar a ideia.

É aqui que o filtro lexical começa a morrer.


🐒 5. O macaco pode não significar macaco

O terminal mostra:

🐒

Nosso programador responde:

ANIMAL = MONKEY

Correto.

Talvez.

Mas em determinada comunidade aquele emoji pode representar:

  • uma pessoa;

  • um grupo;

  • uma piada;

  • um acontecimento;

  • um verbo;

  • uma ironia;

  • uma referência cultural;

  • absolutamente nada além de um macaco.

Agora aparecem doze:

🐒🐒🐒🐒🐒🐒
🐒🐒🐒🐒🐒🐒

Bruce Willis fica preocupado.

O COBOLzeiro pergunta:

— É o Exército dos 12 Macacos?

— Talvez.

— Então bloqueamos?

— Talvez sejam fãs do filme.

— Liberamos?

— Talvez seja código.

— Então o que faço?

O terminal responde:

CONTEXT REQUIRED.

Nosso herói já começa a odiar essa mensagem.


📚 6. Bem-vindo à semântica

Até agora nosso filtro perguntava:

Quais caracteres aparecem nesta mensagem?

Agora precisa perguntar:

O que esta mensagem significa?

Parabéns.

Acabamos de transformar um problema de string matching em um problema de linguagem humana.

O COBOLzeiro olha assustado.

Porque isto:

IF WS-TEXT CONTAINS "XYZ"

é fácil.

Isto:

IF MEANING-OF(WS-TEXT)
   IS SOCIALLY-PROBLEMATIC
   GIVEN CONTEXT

não existe no Enterprise COBOL.

Nem em qualquer outra linguagem como uma instrução mágica.


🧩 7. O contexto é um dataset distribuído

Por que interpretar linguagem é tão difícil?

Porque significado pode depender de:

QUEM FALOU
PARA QUEM
QUANDO
ONDE
EM QUAL COMUNIDADE
EM RESPOSTA A QUÊ
COM QUAL HISTÓRICO
COM QUAL INTENÇÃO
EM QUAL CULTURA

Observe o tamanho da chave composta.

Um moderador vê:

"Parabéns, gênio."

Pode ser elogio.

Pode ser sarcasmo.

Pode ser carinho entre amigos.

Pode ser insulto.

Pode ser referência a uma conversa anterior.

A string é idêntica.

O significado muda.

Nosso programador escreve:

01 CONTEXT.
   05 USER-HISTORY.
   05 RELATIONSHIP.
   05 COMMUNITY.
   05 CULTURE.
   05 PREVIOUS-MESSAGES.
   05 INTENTION.

Depois percebe:

não sabe preencher metade dos campos.


🏺 8. Subculturas são máquinas de fabricar contexto

Agora voltamos ao Capítulo III.

BBS.

IRC.

ICQ.

Fóruns.

Reddit.

Telegram.

Discord.

Comunidades criam linguagem própria.

Um novato entra.

Lê:

XYZ

Não entende.

Veteranos riem.

Por quê?

Porque XYZ carrega talvez cinco anos de história comunitária.

É quase uma COPYBOOK cultural.

Sem ela, o registro parece lixo.

Com ela, todo mundo entende.

Isso gera pertencimento.

Quem conhece o código pertence à tribo.

Quem não conhece fica do lado de fora.


🔑 9. A gíria funciona como compressão

Programadores adoram abreviações.

JCL.

CICS.

IMS.

VSAM.

RACF.

SMF.

WLM.

Db2.

z/OS.

Imagine um jornalista vendo:

"O AOR entrou SOS depois que o MXT bateu e o QR TCB começou a sofrer."

Ele pode acreditar que interceptou comunicação militar.

Para nós, existe contexto.

Subculturas digitais fazem exatamente isso.

Uma expressão curta pode carregar:

HISTORY
+
IDENTITY
+
HUMOR
+
CONTEXT
+
GROUP MEMBERSHIP

Tudo comprimido em cinco caracteres.

O problema para moderação é evidente.


🚫 10. Bloquear o código ensina que ele foi descoberto

Agora ocorre algo fascinante.

Uma plataforma descobre:

CODE-X = PROHIBITED MEANING

Bloqueia CODE-X.

O que os usuários aprendem?

PLATFORM KNOWS CODE-X.

Essa informação possui valor.

Então a comunidade inventa:

CODE-Y

Temos:

COMMUNITY:
CODE-X

PLATFORM:
BLOCK CODE-X

COMMUNITY:
"THEY KNOW."

COMMUNITY:
CODE-Y

O filtro não apenas observa a comunidade.

Ele envia feedback para ela.

Os 12 Macacos aplaudem.


🔄 11. A guerra semântica

Agora podemos desenhar nosso ciclo:

       COMUNIDADE
           |
           v
       CÓDIGO A
           |
           v
        FILTRO
           |
           v
       BLOQUEIO
           |
           v
   COMUNIDADE PERCEBE
           |
           v
       CÓDIGO B
           |
           v
      NOVO FILTRO
           |
           v
       CÓDIGO C
           |
          ...

Não existe necessariamente final.

É uma corrida adaptativa.

Segurança da informação conhece esse fenômeno muito bem.

Atacante adapta.

Defesa adapta.

Atacante observa.

Defesa observa.

Agora aplique isso à linguagem.

Fica ainda pior.

Porque todo ser humano possui um compilador semântico improvisado dentro da cabeça.


📰 12. E então a imprensa publica o dicionário

Lembra do Capítulo II?

Uma reportagem descobre que determinada comunidade utiliza códigos.

Título:

"Conheça as palavras secretas utilizadas na Internet"

Nosso COBOLzeiro grita:

— NÃO!

Tarde demais.

A matéria explica:

CÓDIGO A = SIGNIFICADO A
CÓDIGO B = SIGNIFICADO B
CÓDIGO C = SIGNIFICADO C

Pais aprendem.

Professores aprendem.

Moderadores aprendem.

Autoridades aprendem.

Jornalistas aprendem.

E milhares de pessoas que nunca tinham ouvido aquelas expressões...

também aprendem.

Voltamos ao paradoxo:

informação defensiva também circula.


🔦 13. Isso significa que não devemos ensinar códigos perigosos?

Não necessariamente.

Informação contextual pode ser essencial para:

  • proteção;

  • pesquisa;

  • investigação;

  • educação;

  • moderação.

Mas novamente aparece a palavra do Capítulo II:

GRANULARIDADE.

Existe diferença entre explicar:

"Comunidades podem utilizar linguagem codificada para contornar moderação."

e publicar um catálogo operacional atualizado apontando exatamente onde, como e com quem encontrar determinada atividade ilícita.

Uma coisa ensina o fenômeno.

A outra pode reduzir fricção para alcançá-lo.

A fronteira importa.


📺 14. O código ganha audiência nacional

Agora imagine televisão.

Repórter:

"Especialistas descobriram que usuários utilizam o emoji..."

A câmera mostra.

Milhões veem.

No dia seguinte, o símbolo aparece em piadas.

Memes.

Postagens.

Discussões.

Pessoas usando ironicamente.

Pessoas denunciando.

Pessoas perguntando o que significa.

O classificador entra em crise.

Antes:

SYMBOL = SUSPICIOUS

Depois da reportagem:

SYMBOL =
   SUSPICIOUS
   OR JOURNALISTIC
   OR IRONIC
   OR MEME
   OR DISCUSSION
   OR RANDOM

Parabéns.

A cobertura jornalística modificou novamente o dataset.

Terry Gilliam está gargalhando.


🤖 15. Então chamamos Machine Learning

Nosso programador desiste das palavras fixas.

— Precisamos de algo inteligente.

Entra Machine Learning.

Em vez de:

IF WORD = X

o sistema aprende padrões.

Pode analisar combinações de sinais.

Texto.

Contexto.

Histórico.

Imagem.

Comportamento.

O objetivo deixa de ser apenas encontrar uma palavra.

Passa a ser classificar.

INPUT
  |
  v
MODEL
  |
  v
RISK SCORE

Exemplo:

RISK = 0.03

Provavelmente tranquilo.

Outro:

RISK = 0.94

Talvez revisar ou intervir conforme a política aplicável.

Nosso COBOLzeiro gosta.

— Finalmente.

Bruce Willis olha preocupado.


📊 16. Score não é verdade

Um modelo pode retornar:

0.94

Isso não significa:

94% CRIMINAL

Nem:

94% GUILTY

Nem necessariamente uma probabilidade calibrada de algo juridicamente definido.

É um resultado dentro de determinado modelo, construído para determinado objetivo.

Essa distinção é vital.

Um risk score não é sentença.

Um classificador não é juiz.

Uma heurística não é fato.

MODEL OUTPUT != REALITY

É uma representação probabilística ou classificatória construída sobre dados, regras e objetivos.

O mapa não é o território.


🎯 17. Falso positivo entra no servidor

Imagine uma professora explicando linguagem codificada para seus alunos.

Ela publica:

"Determinados grupos utilizam a expressão X."

O filtro detecta:

X

Resultado:

BLOCK

Mas o conteúdo era educacional.

Temos:

falso positivo.

O sistema identificou como problemático algo que, naquele contexto, não deveria receber aquela classificação.

Nosso programador escreve:

FALSE POSITIVE

E percebe que alguém legítimo acabou de ser prejudicado.


🕳️ 18. Falso negativo entra pela outra porta

Agora alguém publica conteúdo realmente contrário às regras.

Mas utiliza metáfora sofisticada.

O sistema não percebe.

ALLOW

Temos:

falso negativo.

O conteúdo que deveria ter sido identificado passou.

Então surge o dilema:

LOWER THRESHOLD

captura mais coisas perigosas...

mas pode aumentar falsos positivos.

RAISE THRESHOLD

reduz bloqueios injustificados...

mas pode deixar mais conteúdo problemático passar.

Bem-vindo à classificação.

Não existe almoço grátis.

Nem café grátis.

Principalmente no Bellacosa Mainframe.


⚖️ 19. Agora coloque o ECA nessa matriz

A conversa fica mais séria quando determinados riscos envolvem crianças e adolescentes.

O custo de um falso negativo em certas situações pode ser extremamente alto.

Mas isso não significa que possamos simplesmente configurar:

BLOCK EVERYTHING

Porque plataformas também hospedam:

  • educação;

  • saúde;

  • jornalismo;

  • apoio;

  • arte;

  • conversas legítimas;

  • denúncias;

  • pesquisa.

Precisamos proteger sem transformar proteção em máquina cega.

Isso exige:

POLICY
+
TECHNOLOGY
+
CONTEXT
+
HUMAN REVIEW
+
PROCEDURE

Não apenas um IF.


🧠 20. E então chegou a IA moderna

Agora o Bellacosa Mainframe recebe uma atualização.

INSTALL GENERATIVE-AI

Nosso COBOLzeiro pergunta:

— Agora ela entende contexto?

Bruce responde:

— Melhor.

— Então resolve?

— Não.

— Por quê?

— Porque "melhor" não significa "perfeitamente".

Modelos modernos conseguem analisar linguagem de maneira extraordinariamente mais sofisticada que filtros lexicais simples.

Podem reconhecer:

  • relações semânticas;

  • paráfrases;

  • contexto;

  • categorias;

  • intenção aparente;

  • padrões linguísticos.

Mas continuam sujeitos a:

  • erro;

  • ambiguidade;

  • contexto incompleto;

  • diferenças culturais;

  • adversarial behavior;

  • falsos positivos;

  • falsos negativos.

O problema mudou de escala.

Não desapareceu.


🧪 21. O usuário começa a testar o moderador

Aqui surge uma coisa inevitável.

Se usuários sabem que existe moderação automática, alguns tentarão descobrir seus limites.

Publicam A.

Passa.

Publicam B.

Bloqueia.

Alteram.

Passa.

Sem acesso ao modelo, podem inferir comportamento por tentativa e erro.

É quase:

INPUT A -> ALLOW
INPUT B -> BLOCK
INPUT C -> ALLOW
INPUT D -> BLOCK

Com tempo suficiente, aprende-se algo sobre a fronteira.

Em segurança chamamos fenômenos semelhantes de sondagem.

Nas redes sociais pode acontecer naturalmente, por curiosidade, brincadeira ou tentativa deliberada de evasão.

O classificador também se torna objeto de estudo da comunidade.


🧙 22. Nasce o "Algorithm Whisperer"

Toda comunidade começa a desenvolver especialistas informais.

A pessoa que diz:

"Não escreva assim."

"Troque essa palavra."

"Essa hashtag derruba alcance."

"Use este símbolo."

"O bot detecta aquilo."

Parte dessas crenças é verdadeira.

Parte é superstição.

Parte é observação desatualizada.

Parte é puro folclore.

Temos um novo personagem:

o sussurrador de algoritmo.

O equivalente digital do operador veterano que diz:

"Não sei por que, mas não submeta esse job às 17h03."

E todo mundo obedece.


🕯️ 23. Folclore algorítmico

Isso é fascinante.

Quando usuários não conhecem completamente as regras internas de um sistema, criam teorias.

"SE ESCREVER X, O ALGORITMO ESCONDE."

"SE USAR Y, ENTREGA MAIS."

"SE COLOCAR Z, A CONTA CAI."

Algumas podem refletir padrões reais.

Outras são correlação transformada em causalidade.

É praticamente religião operacional.

Mainframeiros conhecem bem:

"Não mexa nesse PROC."

— Por quê?

"Ninguém sabe."

— Há quanto tempo?

"Desde 1997."

— Quem criou?

"Acho que o Roberto."

— Onde está Roberto?

"Aposentou em 2004."

Não mexa no PROC.


👁️ 24. O algoritmo também observa a adaptação

Mas a história não termina aí.

Plataformas podem atualizar modelos.

Novos dados entram.

Novas formas de evasão são identificadas.

Classificadores evoluem.

Então:

USERS LEARN MODEL
        |
        v
USERS ADAPT
        |
        v
PLATFORM OBSERVES
        |
        v
MODEL UPDATES
        |
        v
USERS OBSERVE UPDATE

Isso é quase uma coevolução.

O sistema e seus usuários modificam o comportamento um do outro.

E aqui Os 12 Macacos deixa de ser apenas decoração cinematográfica.

O observador interfere no fenômeno.

O fenômeno reage ao observador.


🐒 25. Encontramos o vírus?

Nosso programador pergunta:

— Então os códigos são o vírus?

Não.

— Os usuários?

Não.

— A IA?

Também não.

— O algoritmo?

Não.

Bruce Willis responde:

— Você continua procurando um paciente zero para um sistema emergente.

Essa é talvez a maior armadilha de toda nossa série.

Queremos encontrar:

ROOT CAUSE = ONE THING

Mas fenômenos sociais digitais frequentemente resultam de interações entre:

HUMANS
PLATFORMS
ALGORITHMS
MEDIA
LAW
ECONOMICS
CULTURE
TECHNOLOGY

Não existe necessariamente um único JOBNAME.


🎭 26. Meme: o pesadelo perfeito da moderação

Agora chegamos ao meme.

Uma imagem.

Algumas palavras.

Referência cultural.

Ironia.

História.

Contexto.

Às vezes você precisa conhecer cinco acontecimentos anteriores para entender.

Exemplo:

uma imagem banal de um sapo.

Para alguém:

sapo.

Para determinada comunidade:

piada específica.

Para outra:

símbolo político.

Para outra:

meme antigo.

Para outra:

absolutamente nada.

Como classificamos?

IMAGE = FROG

Correto.

Semanticamente insuficiente.


🖼️ 27. A imagem escapou do PIC X

COBOLzeiros gostam de dados estruturados.

05 CUSTOMER-NAME PIC X(40).
05 CUSTOMER-AGE  PIC 9(03).

Agora chega:

JPEG

E pergunta:

O que significa?

Depois chega vídeo.

Depois áudio.

Depois livestream.

Depois combinação de vídeo + texto + chat + emoji + histórico.

A moderação moderna é multimodal.

Não basta ler caracteres.

Precisamos interpretar sinais diferentes.

E cada modalidade possui contexto próprio.


🎙️ 28. Voz desaparece rápido — mas pode causar efeito permanente

Em ambientes com voz, como Discord e Twitch, surge outra dificuldade.

Texto pode permanecer registrado dependendo do serviço e contexto.

Voz pode ser efêmera para participantes.

Uma frase acontece.

Alguém reage.

Talvez alguém grave.

Talvez não.

Depois começa a disputa:

"Ele disse."

"Não disse."

"Era piada."

"Foi fora de contexto."

Agora nosso problema deixa de ser apenas classificação.

Passa a envolver proveniência.

Quem disse?

Quando?

Qual contexto?

Existe registro confiável?

Voltamos ao capítulo jurídico.

Tudo está conectado.


🧾 29. Proveniência: de onde veio isso?

Essa palavra deveria ser muito mais conhecida fora da tecnologia.

Proveniência.

Uma informação sem origem confiável é mais difícil de avaliar.

Imagine um screenshot circulando.

Perguntas:

WHO CREATED IT?
WHEN?
WHERE?
IS IT COMPLETE?
WAS IT EDITED?
WHAT CAME BEFORE?
WHAT CAME AFTER?

A Internet frequentemente responde:

TRUST ME BRO.

Esse é um protocolo extremamente popular.

Infelizmente não aparece em nenhum RFC.


📰 30. A mídia enfrenta agora conteúdo sintético

O problema de nosso Capítulo II ficou ainda pior.

Antes, jornalista recebia screenshot.

Agora pode receber:

  • imagem gerada;

  • áudio sintético;

  • vídeo manipulado;

  • texto fabricado;

  • perfil artificial.

A pergunta:

"Isso aconteceu?"

ganha uma camada adicional:

"Esse artefato sequer existiu no mundo antes de alguém gerá-lo?"

O vírus informacional aprendeu engenharia genética.

Terry Gilliam pede outro café.


🤖 31. IA moderando conteúdo produzido por IA

Agora chegamos ao momento em que nosso COBOLzeiro começa a rir.

IA produz conteúdo.

Outra IA classifica.

Usuário pede para IA reescrever para passar no filtro.

Filtro é atualizado.

Outra IA tenta detectar.

Temos:

AI-A
  |
  v
CONTENT
  |
  v
AI-B MODERATION
  |
  v
BLOCK
  |
  v
AI-A REWRITE
  |
  v
AI-B AGAIN

Ele olha para Bruce Willis.

— Onde estão os humanos?

O terminal responde:

HUMAN REVIEW QUEUE:
12,483,921

— Ah.


🚨 32. Escala é o monstro escondido

Moderação manual funciona relativamente bem para:

100 POSTS

Agora tente:

100,000,000 POSTS

Vídeos.

Mensagens.

Imagens.

Lives.

Idiomas.

Fusos horários.

Contextos culturais.

Nenhuma empresa consegue colocar um especialista humano examinando preventivamente cada interação.

Automação deixa de ser luxo.

Torna-se necessidade operacional.

Mas quanto maior a automação, maior a importância de:

  • métricas;

  • auditoria;

  • revisão;

  • recurso;

  • governança.

O velho COBOLzeiro reconhece isso.

É produção em escala.


🏭 33. Moderação é uma fábrica de decisões

Imagine:

CONTENT
   |
   v
PRE-FILTER
   |
   v
MODEL
   |
   +------ LOW RISK ------> ALLOW
   |
   +------ MEDIUM --------> REVIEW
   |
   +------ HIGH ----------> BLOCK

Parece elegante.

Mas cada seta esconde decisões.

Quem definiu HIGH?

Com quais dados?

Qual política?

Qual tolerância ao erro?

Quem revisa?

Usuário pode recorrer?

Modelo muda?

Como medir impacto?

Existe viés linguístico?

Funciona igualmente em português brasileiro e inglês?

E em gíria de adolescente?

Agora nossa simples rotina virou governança algorítmica.


🌎 34. O português do Brasil entra no classificador

Modelos globais enfrentam um problema delicioso:

seres humanos não falam "idioma".

Falam variedades.

Português brasileiro.

Regionalismos.

Gírias.

Dialetos.

Internetês.

Misturas.

Ironia.

Palavras que mudam completamente de significado dependendo da região.

Nosso classificador treinado majoritariamente em determinado contexto pode cometer erros em outro.

Isso significa que moderação global exige sensibilidade local.

O que parece ofensivo numa cultura pode ser banal em outra.

O inverso também ocorre.

Contexto cultural é dado operacional.


🇧🇷 35. E o ECA continua rodando em paralelo

Enquanto engenheiros discutem thresholds, embeddings e classificadores, o mundo jurídico não desapareceu.

Se uma situação envolver possível crime ou risco sério contra criança ou adolescente, não basta dizer:

"Nosso modelo classificou como 0,72."

A tecnologia pode ajudar a identificar e priorizar.

Mas fatos precisam ser tratados conforme procedimentos apropriados.

Lembra do Capítulo IV?

MODEL SCORE
    !=
CRIMINAL CONVICTION

Não esqueça.

Nunca.


🧯 36. O perigo do excesso de confiança

Agora nosso COBOLzeiro vê:

AI CONFIDENCE = 99%

Ele pergunta:

— Então está certo?

Bruce Willis responde:

— Não necessariamente.

Confiança apresentada por um sistema não deve ser confundida automaticamente com verdade objetiva.

Modelos podem estar:

confiantemente errados.

Humanos também.

A diferença é que humanos não costumam imprimir:

CONFIDENCE = 0.99274

antes de falar bobagem no almoço de família.

Talvez devessem.


👥 37. Human in the Loop não é decoração

Então chamamos um humano.

Mas simplesmente colocar uma pessoa no final do pipeline não resolve automaticamente tudo.

O revisor precisa:

  • contexto;

  • treinamento;

  • tempo;

  • políticas compreensíveis;

  • ferramentas;

  • possibilidade de escalar casos difíceis.

Se mostramos apenas:

MODEL SAYS: BAD
APPROVE? Y/N

existe risco de automation bias.

O humano começa a seguir a máquina.

Então nossa arquitetura deveria perguntar:

O humano está realmente revisando ou apenas apertando Enter?

Todo operador de produção conhece essa diferença.


🐵 38. O moderador vê doze macacos

Nosso sistema recebe:

🐒🐒🐒🐒🐒🐒
🐒🐒🐒🐒🐒🐒

IA:

POSSIBLE CODED CONTENT
CONFIDENCE: 61%

Revisor humano:

— Parece referência a 12 Monkeys.

Outro revisor:

— Talvez.

Terceiro:

— Qual servidor?

Resposta:

SERVER NAME:
TERRY-GILLIAM-FANS

Todos respiram aliviados.

Então aparece outra informação:

CHANNEL:
#not-about-the-movie

Silêncio.

Contexto ataca novamente.


🕵️ 39. Adversarial behavior: quando o usuário sabe que está sendo observado

Agora chegamos à parte mais interessante.

Um usuário pode deliberadamente produzir conteúdo para parecer inocente ao sistema e compreensível à comunidade.

Isso cria uma assimetria:

INSIDER:
HAS CONTEXT

MODERATOR:
PARTIAL CONTEXT

ALGORITHM:
PATTERN + DATA

OUTSIDER:
NO CONTEXT

Quem pertence à comunidade pode entender instantaneamente.

Quem está fora vê apenas:

🍕🌙🐒📼

Quatro emojis.

Nada.

Ou uma frase inteira.

Depende do código.

É praticamente criptografia cultural.


🔐 40. Mas código social não é criptografia

Importante distinguir.

Criptografia possui mecanismos matemáticos formais.

Código social pode ser simplesmente convenção.

🍎 = X

porque o grupo decidiu.

Não existe chave criptográfica no sentido técnico.

Existe conhecimento compartilhado.

Isso torna o sistema frágil e poderoso ao mesmo tempo.

Basta alguém revelar o significado.

Mas depois da revelação...

a comunidade pode mudar.

Voltamos ao início.


🔄 41. GOTO 1

Nosso COBOLzeiro finalmente percebe a estrutura completa:

001-BEGIN.

    COMMUNITY INVENTS CODE.

    PLATFORM LEARNS CODE.

    PLATFORM BLOCKS CODE.

    COMMUNITY LEARNS FILTER.

    COMMUNITY INVENTS NEW CODE.

    GO TO 001-BEGIN.

Ele olha horrorizado.

— Um GO TO infinito?

Bruce Willis responde:

— Agora você entendeu a Internet.


🧠 42. Podemos vencer essa guerra?

Talvez a pergunta esteja errada.

Não existe necessariamente uma vitória definitiva.

Moderação é processo contínuo.

Como segurança.

Como antifraude.

Como spam.

Como antivírus.

Como gestão de risco.

Você não instala:

SECURITY.EXE

e encerra segurança para sempre.

Da mesma maneira, não cria:

MODERATION VERSION 1.0

e declara:

"Pronto. Seres humanos resolvidos."

Seres humanos recebem atualizações sem aviso prévio.

Frequentemente incompatíveis com versões anteriores.


🛡️ 43. Então qual é a estratégia?

Camadas.

Sempre camadas.

POLICY
   +
USER CONTROLS
   +
COMMUNITY MODERATION
   +
AUTOMATION
   +
AI
   +
HUMAN REVIEW
   +
REPORTING
   +
APPEALS
   +
LEGAL PROCESS
   +
EDUCATION

Nenhuma resolve tudo.

Juntas reduzem riscos.

É quase um Swiss Cheese Model aplicado à governança digital.

Cada camada possui buracos.

Esperamos que eles não se alinhem.


🧒 44. Educação talvez seja o filtro esquecido

Quando falamos de crianças e adolescentes, existe uma tentação de pensar apenas em:

BLOCK
FILTER
BAN
MONITOR

Mas existe outra camada:

educação digital.

Ensinar:

  • privacidade;

  • limites;

  • golpes;

  • manipulação;

  • denúncia;

  • reputação;

  • permanência digital;

  • consentimento;

  • cuidado com desconhecidos;

  • pensamento crítico.

Não substitui proteção técnica.

Não substitui família.

Não substitui plataforma.

Não substitui autoridades quando necessárias.

Mas adiciona resiliência ao usuário.

É como ensinar segurança ao operador em vez de confiar apenas no firewall.


📰 45. E ensinar sem criar curiosidade operacional?

Voltamos novamente à revista.

A serpente morde a própria cauda.

Como ensinar riscos sem transformar a aula em catálogo?

Como explicar códigos sem promover códigos?

Como denunciar comunidades perigosas sem entregar mapa?

Como informar pais sem ensinar curiosos?

Como explicar técnicas de evasão sem oferecer manual?

Não existe resposta universal.

Mas existe um princípio:

ensine mecanismos, sinais de risco e proteção antes de ensinar caminhos operacionais desnecessários.

Explique como pensar.

Não necessariamente onde clicar.

Essa distinção pode salvar uma reportagem, uma aula e talvez uma pessoa.


🐒 46. O Exército dos 12 Macacos finalmente manda uma mensagem

04:57.

O terminal recebe:

INCOMING MESSAGE
SOURCE: UNKNOWN

Nosso programador abre.

🐒☕🖥️🔒⚖️

— O que significa?

Bruce Willis não sabe.

IA responde:

POSSIBLE INTERPRETATIONS:

1. MONKEY DRINKS COFFEE AT COMPUTER
2. REFERENCE TO 12 MONKEYS
3. DIGITAL SECURITY COMMENTARY
4. LEGAL MODERATION MEME
5. UNKNOWN CODE

O programador pergunta:

— Qual é a correta?

INSUFFICIENT CONTEXT.

Ele bate na mesa.

— Então descubra quem enviou!

SOURCE UNKNOWN.

— Procure histórico!

NO HISTORY.

— Pergunte ao usuário!

Nova mensagem chega:

🧠 > 🤖

Bruce Willis começa a rir.


☕ 47. O COBOLzeiro responde

Nosso herói pensa.

Digita:

☕ > 🐒

Resposta imediata:

🐒🐒🐒🐒🐒🐒
🐒🐒🐒🐒🐒🐒

O terminal entra em alerta:

POSSIBLE COORDINATED ACTIVITY

O COBOLzeiro desliga o alerta.

— Calma. É só uma piada.

Bruce Willis pergunta:

— Como sabe?

Silêncio.

Ele percebe.

Porque agora ele possui contexto.

O algoritmo não.

Finalmente entendeu.


🧩 48. O contexto vive nas pessoas

Talvez essa seja a grande conclusão deste capítulo.

Podemos armazenar:

TEXT
IMAGE
VIDEO
TIMESTAMP
USER-ID
CHANNEL

Mas significado frequentemente depende de conhecimento que não está integralmente armazenado em nenhum desses campos.

Ele vive:

  • na cultura;

  • na memória;

  • na relação;

  • na história;

  • na intenção;

  • na comunidade.

A IA pode inferir.

O moderador pode interpretar.

O sistema pode correlacionar.

Mas existe sempre possibilidade de erro.

Por isso decisões graves exigem proporcionalidade.

Quanto maior a consequência, maior deveria ser o cuidado.


⚖️ 49. RISK SCORE não deveria virar guilhotina

Imagine:

RISK = 0.63

Isso pode justificar revisão.

Talvez alguma medida preventiva proporcional conforme contexto e política.

Mas transformar automaticamente score incerto em acusação pública grave seria perigosíssimo.

Devemos separar:

SIGNAL

de:

EVIDENCE

de:

CONCLUSION

Essa separação vale para IA.

Vale para moderação.

Vale para jornalismo.

Vale para investigações.

Vale para todos nós.


🕰️ 50. Terry Gilliam fecha o loop

Agora olhe a sequência completa.

A comunidade cria uma linguagem.

A plataforma observa.

A plataforma bloqueia.

A comunidade adapta.

A imprensa noticia a adaptação.

O público aprende.

O significado se espalha.

A palavra deixa de ser exclusiva.

A comunidade abandona.

Cria outra.

O algoritmo aprende.

A comunidade observa o algoritmo.

O algoritmo observa a comunidade.

       +---------------------+
       |                     |
       v                     |
    CULTURE                  |
       |                     |
       v                     |
    LANGUAGE                 |
       |                     |
       v                     |
    PLATFORM                 |
       |                     |
       v                     |
    MODERATION               |
       |                     |
       v                     |
    ADAPTATION --------------+

Quem é o paciente zero?

Talvez a pergunta continue errada.


🚨 51. Então chega a mensagem que muda tudo

O terminal começa a piscar.

Não é um alerta comum.

PRIORITY: CRITICAL

Nosso programador se aproxima.

CONTENT DETECTED
PLATFORM: DISCORD

CONTENT TYPE:
UNKNOWN CODE

USERS:
MULTIPLE

MINOR USERS:
PRESENT

MEDIA ATTENTION:
INCREASING

PLATFORM MODERATION:
ACTIVE

PUBLIC ACCUSATIONS:
SPREADING

POLICE INVESTIGATION:
UNKNOWN

Bruce Willis perde o sorriso.

Nosso COBOLzeiro pergunta:

— O que fazemos?

O terminal responde:

DO NOT ASSUME.

Outra linha:

DO NOT AMPLIFY UNVERIFIED CLAIMS.

Outra:

PRESERVE CONTEXT.

E finalmente:

DISTINGUISH:
RUMOR
EVIDENCE
PLATFORM ACTION
AND CRIMINAL INVESTIGATION.

Agora chegamos ao último problema do Arco I.


📰 52. Quando a denúncia vira espetáculo

Até agora estudamos informação.

No próximo capítulo teremos de estudar acusação.

Porque uma denúncia legítima pode proteger pessoas.

Mas uma denúncia pública mal verificada pode também:

  • destruir reputações;

  • gerar perseguição;

  • contaminar testemunhos;

  • espalhar boatos;

  • aumentar curiosidade;

  • divulgar involuntariamente comunidades;

  • produzir cópias de material;

  • interferir na compreensão dos fatos.

E existe algo particularmente perigoso:

quando todo mundo acredita estar ajudando.

O jornalista.

O influenciador.

O moderador.

O usuário.

O investigador amador.

Cada um compartilha "para alertar".

E de repente ninguém sabe mais onde terminou a evidência e começou a narrativa.

Os 12 Macacos encontraram a televisão novamente.


🐒 53. Easter egg: DO NOT FEED THE ALGORITHM

O terminal imprime uma folha.

BELLACOSA INFORMATION CONTROL FACILITY
---------------------------------------

SEMANTIC ARMS RACE REPORT

WORD FILTER.............. INSUFFICIENT
REGEX.................... INSUFFICIENT
DICTIONARY............... INSUFFICIENT
MACHINE LEARNING......... USEFUL / FALLIBLE
GENERATIVE AI............ USEFUL / FALLIBLE
HUMAN REVIEW............. NECESSARY / FALLIBLE
CONTEXT.................. ESSENTIAL

---------------------------------------

OBSERVATION:

BLOCKING REPRESENTATION
DOES NOT GUARANTEE
REMOVAL OF MEANING.

---------------------------------------

USER ADAPTATION:

WORD
  ↓
MISSPELLING
  ↓
SYMBOL
  ↓
EMOJI
  ↓
MEME
  ↓
METAPHOR
  ↓
PRIVATE CONTEXT

---------------------------------------

WARNING:

THE FILTER LEARNS USERS.

USERS LEARN THE FILTER.

---------------------------------------

DO NOT FEED
THE ALGORITHM
WITHOUT KNOWING
WHAT YOU ARE FEEDING IT.

---------------------------------------

Nosso COBOLzeiro olha para Bruce Willis.

— Finalmente encontramos os 12 Macacos?

Bruce aponta para os doze emojis.

🐒🐒🐒🐒🐒🐒
🐒🐒🐒🐒🐒🐒

— Talvez.

— Quem são?

Bruce responde:

— Depende do contexto.

O programador fecha os olhos.

— Eu odeio essa frase.


🖥️ FINAL DO CAPÍTULO V

O Bellacosa Mainframe executa:

BELLACOSA MAINFRAME
INFORMATION CONTROL FACILITY
---------------------------------------

ARC I STATUS

CHAPTER I
INFORMATION OUTBREAK......... COMPLETE

CHAPTER II
DISCOVERY PATH............... COMPLETE

CHAPTER III
DIGITAL TRIBES............... COMPLETE

CHAPTER IV
LAW AND FREEDOM.............. COMPLETE

CHAPTER V
SEMANTIC ARMS RACE........... COMPLETE

---------------------------------------

PATIENT ZERO................. NOT FOUND

SEMANTIC PATIENT ZERO........ NOT FOUND

PERFECT FILTER............... NOT FOUND

PERFECT AI................... NOT FOUND

PERFECT HUMAN................ DEFINITELY NOT FOUND

---------------------------------------

NEW INCIDENT:

RUMOR......................... ACTIVE
MEDIA......................... ACTIVE
SOCIAL NETWORKS............... ACTIVE
PUBLIC OUTRAGE................ ACTIVE
MINORS......................... POSSIBLE
PLATFORM ACTION............... UNKNOWN
CRIMINAL EVIDENCE............. UNKNOWN

---------------------------------------

CRITICAL WARNING:

A VIRAL ACCUSATION
IS NOT THE SAME THING
AS A VERIFIED FACT.

A PLATFORM BAN
IS NOT A CONVICTION.

A SCREENSHOT
IS NOT THE WHOLE TIMELINE.

A HASHTAG
IS NOT A COURT.

---------------------------------------

NEXT MODULE:

THE DIGITAL TRIBUNAL

LOAD? Y/N

===> _

Nosso programador deixa o cursor parado.

Pela primeira vez, não aperta Y imediatamente.

Olha para Bruce Willis.

— Se eu continuar, o que acontece?

Bruce responde:

— Entramos no lugar mais perigoso da Internet.

— Dark Web?

— Não.

— Grupo secreto?

— Não.

— Servidor criminoso?

— Também não.

— Então onde?

Bruce aponta para o monitor.

Na tela aparece:

TRENDING NOW

Milhares de mensagens começam a subir.

Acusações.

Screenshots.

Hashtags.

Vídeos.

Reações.

Influenciadores.

Telejornais.

Especialistas.

Supostos especialistas.

Pessoas que acabaram de descobrir o assunto há sete minutos e já publicaram uma análise definitiva de quarenta posts.

Nosso COBOLzeiro empalidece.

— Meu Deus.

Bruce Willis coloca outra jarra de café na mesa.

— Bem-vindo ao tribunal da timeline.

O programador olha novamente:

LOAD DIGITAL TRIBUNAL? Y/N

Respira.

Digita:

Y

ENTER.

A tela fica preta.

Então aparece:

WARNING:

EVERYONE HAS A VERDICT.

WE ARE STILL LOOKING
FOR THE EVIDENCE.

CONTINUA...


🐒 Próximo e último capítulo do ARCO I

ARCO I — CAPÍTULO VI

🚨 O Tribunal da Timeline — quando a denúncia viralizou antes de os fatos terminarem de carregar

Discord, imprensa, televisão, Facebook, Instagram, WhatsApp, Reddit, X, Twitch e Telegram; denúncia, rumor, screenshots, linchamento digital, investigação, ECA, presunção de inocência, efeito Streisand e o estranho dia em que o Bellacosa Mainframe descobriu que milhões de pessoas já tinham executado MOVE CULPADO TO VEREDITO enquanto a rotina READ EVIDENCE ainda nem havia terminado.

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