☕ 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, 27 de agosto de 2026

Discord, WhatsApp e o Tribunal do ABEND — Quando Saul Goodman Entrou na Sala da AGU, Viu Igor Tentando Dar CANCEL na Internet e Perguntou: “Cadê a Evidência, Excelência?”

 
Bellacosa Mainframe e o caso do discord

☕ Um Café no Bellacosa Mainframe

Discord, WhatsApp e o Tribunal do ABEND — Quando Saul Goodman Entrou na Sala da AGU, Viu Igor Tentando Dar CANCEL na Internet e Perguntou: “Cadê a Evidência, Excelência?”

Ou: uma tragédia em uma live fechada colocou o Discord no banco dos réus; o jovem padawan COBOL descobriu que nenhuma plataforma enxerga tudo, Saul Goodman pediu proporcionalidade, e o Brasil corre o risco de criar mais uma montanha de leis que ninguém consegue operar em produção.


Prólogo — a tragédia, a manchete e o botão vermelho

Imagine uma sala de operações de banco às três da manhã.

Um alerta aparece em vermelho:

SEV1 — evento gravíssimo detectado
impacto humano: máximo
pressão pública: máxima
prazo para resposta: ontem

A reação correta seria abrir o incidente, preservar evidências, identificar a causa, chamar os especialistas certos, conter o dano e revisar a arquitetura. Mas, no Brasil, às vezes a reação parece outra:

IF MANCHETE-GRANDE = 'SIM'
   PERFORM CRIAR-LEI-EMERGENCIAL
   PERFORM APLICAR-MULTA-GIGANTE
   PERFORM ENCONTRAR-UM-VILAO-VISIVEL
END-IF

O caso envolvendo o Discord, uma adolescente e uma transmissão em ambiente fechado reacendeu uma discussão necessária: até onde uma plataforma digital deve responder por crimes praticados por seus usuários? A Advocacia-Geral da União (AGU) acusa a empresa de falhas de proteção, especialmente relacionadas a menores, e pede medidas técnicas, estruturais e uma indenização coletiva muito alta. O Discord contesta a proporcionalidade da ação e afirma ter cooperado e apresentado propostas de adequação.

Antes de qualquer coisa, uma regra básica que até o mais jovem programador COBOL precisa aprender: acusação não é condenação. Uma tragédia não elimina a necessidade de provar fatos, conexão causal, falha concreta, capacidade técnica e proporcionalidade da resposta.

E aí entra Saul Goodman, advogado fictício, terno berrante, gravata duvidosa e uma habilidade sobrenatural para fazer uma pergunta que muita gente odeia:

“Certo, houve um crime horrível. Mas vocês conseguem mostrar exatamente o que a plataforma sabia, quando soube, o que poderia ter feito e por que não fez?”

Saul não está absolvendo criminoso. Ele está exigindo que o sistema não transforme indignação em atalho jurídico.

Porque o criminoso que coagiu, aliciou, ameaçou ou induziu alguém à violência continua sendo o responsável direto pelo crime. A plataforma pode ter responsabilidade própria? Pode. Mas ela não vira automaticamente autora do ato só porque a comunicação passou por sua infraestrutura.

É a diferença entre culpar o assaltante que roubou o banco e investigar se a agência deixou o cofre aberto, sem alarme, sem câmera, sem vigilante e ignorou três avisos de invasão. São responsabilidades diferentes. Podem coexistir. Mas não podem ser confundidas.



1. A pergunta errada: “por que o Discord não impediu tudo?”

Quando algo terrível acontece on-line, surge a frase mais sedutora e menos útil do debate:

“A plataforma tinha de ter impedido.”

Parece simples. É humana. É emocionalmente compreensível. Mas tecnicamente é uma frase perigosa.

Nenhuma plataforma grande consegue impedir todo crime cometido por usuários. Nem Discord, nem YouTube, nem TikTok, nem Facebook, nem Instagram, nem Reddit, nem WhatsApp, nem Telegram, nem Teams, nem Zoom, nem o grupo da família que encaminha notícia falsa dizendo que café cura crise de storage.

A pergunta séria não é “por que não impediu o impossível?”. É:

“Diante de riscos conhecidos e sinais concretos, a empresa adotou controles razoáveis e reagiu com a rapidez adequada?”

Veja como a troca muda tudo.

No primeiro modelo, a plataforma recebe uma obrigação de onisciência. Ela teria de assistir cada transmissão, interpretar cada conversa, prever cada intenção e interromper cada risco antes de ele se materializar.

No segundo modelo, ela tem uma obrigação de cuidado. Deve avaliar riscos, criar mecanismos de denúncia, reduzir reincidência, combater contas abusivas, cooperar com autoridades, proteger menores, manter canais de emergência e responder a sinais relevantes.

Em COBOL, a diferença seria algo assim:

IF PLATAFORMA-NAO-PREVIU-TODO-CRIME
   MOVE 'CULPADA' TO VEREDITO
END-IF.

Isso é uma regra injusta e impossível de operar.

O modelo mais responsável seria:

IF RISCO-CONHECIDO = 'SIM'
   AND ALERTA-CONCRETO = 'SIM'
   AND CONTROLE-RAZOAVEL-AUSENTE = 'SIM'
   AND DEMORA-EVITAVEL = 'SIM'
   MOVE 'APURAR-RESPONSABILIDADE' TO VEREDITO
END-IF.

Repare no verbo: apurar. Não é passar pano. Não é absolver previamente. É investigar como gente adulta.



2. Live privada não é praça pública — e essa diferença importa

Uma live pública funciona como um palco na avenida. Há tráfego, compartilhamento, algoritmo, comentários, espectadores desconhecidos, denúncias e uma quantidade grande de sinais para sistemas automatizados observarem.

Uma live privada ou feita num servidor fechado por convite é outra arquitetura. Ela se parece mais com uma reunião numa sala trancada. Há menos pessoas, menos circulação, menos contexto externo e, possivelmente, menor capacidade de detecção imediata.

Isso não torna o espaço legalmente imune. Crime em grupo privado continua sendo crime. A plataforma continua tendo deveres. Mas significa que exigir a mesma capacidade de prevenção de um vídeo público e de uma interação fechada pode ser tecnicamente desonesto.

O YouTube, por exemplo, permite lives públicas, não listadas e privadas. Uma live privada pode ser limitada a contas convidadas. O TikTok possui recursos de moderação em LIVE. Facebook e Instagram moderam posts e transmissões, mas têm limitações diferentes em mensagens privadas, especialmente quando há criptografia. O Reddit permite comunidades privadas nas quais só participantes aprovados conseguem entrar. Nenhuma dessas empresas anuncia que possui um policial humano assistindo cada evento privado em tempo real.

A pergunta que Saul Goodman colocaria na mesa é simples:

“Se uma transmissão privada no YouTube, um grupo privado no Reddit ou uma chamada fechada em outra plataforma produzisse o mesmo crime, o Estado aplicaria a mesma tese, a mesma multa e as mesmas exigências?”

Se a resposta for “não”, precisamos saber por quê.

Pode existir uma justificativa. Talvez uma empresa tivesse sido alertada antes. Talvez houvesse reincidência documentada. Talvez existisse uma falha operacional específica. Talvez a arquitetura do serviço tenha facilitado a reentrada de criminosos banidos. Ótimo: então se prove isso.

O que não vale é transformar “Discord” em sinônimo de “a internet perigosa” só porque é uma marca fácil de reconhecer e tem fama de abrigo de gamers, comunidades estranhas, memes de gosto questionável e aquele sujeito que usa avatar de anime para discutir geopolítica às quatro da manhã.



3. A diferença que muda o tabuleiro: criptografia

Agora chegamos ao ponto em que Igor, nosso operador de plantão, derruba o café em cima do manual de segurança:

WhatsApp não consegue ler o conteúdo das conversas e chamadas protegidas por criptografia ponta a ponta.

Criptografia ponta a ponta — ou E2EE, para quem quer parecer que já trabalhou numa sala com ar-condicionado frio demais — significa que apenas os participantes da conversa podem acessar o conteúdo. Nem o WhatsApp, em tese, lê a mensagem como um moderador lendo uma postagem pública.

Isso é ruim? Não. É uma proteção essencial.

Ela protege conversa com advogado, médico, jornalista, familiar, empresa, vítima de violência, dissidente político, ativista, pessoa perseguida e qualquer cidadão que simplesmente não queira que uma empresa ou governo tenha cópia de sua vida privada.

Mas ela cria um problema operacional real: como combater crimes em espaços privados sem transformar o celular de todo mundo em um informante permanente?

A resposta não pode ser: “quebre a criptografia”. Isso seria equivalente a instalar uma porta dos fundos no cofre e prometer que só os mocinhos terão a chave. A história da tecnologia ensina que uma porta dos fundos não reconhece caráter. Ela pode ser usada por Estado democrático, Estado autoritário, criminoso, invasor, funcionário corrupto ou Igor depois de três cafés e uma madrugada sem dormir.

A resposta mais plausível é combinar várias camadas:

  • denúncias fáceis e acessíveis;

  • bloqueio de usuários;

  • análise de comportamento e metadados dentro dos limites legais;

  • limitação de convites e contas recém-criadas em contextos de risco;

  • combate a reincidência;

  • cooperação rápida com investigação judicial;

  • educação digital;

  • proteção reforçada para menores;

  • suporte humano e psicológico para vítimas.

Note a diferença: não é “ler todas as cartas”. É “criar alarmes sem arrombar todas as casas”.



4. O que pode ser cobrado de uma plataforma, de modo razoável?

Plataforma nenhuma deve ser tratada como inocente por definição. Empresas gigantes têm dinheiro, engenheiros, advogados, equipes de segurança e, muitas vezes, uma criatividade impressionante para chamar uma falha de “experiência emergente do usuário”.

Existem cobranças perfeitamente legítimas.

4.1. Verificação etária proporcional

Uma criança não deveria entrar em espaços de alto risco usando apenas uma data de nascimento digitada numa tela. Mas também não é aceitável criar uma internet em que todo adulto precise entregar documento biométrico para assistir um tutorial de JCL.

O desafio é graduar o controle conforme o risco. Espaços de interação intensa entre desconhecidos, funções de transmissão ao vivo, contato com adultos e comunidades sensíveis podem justificar proteções mais fortes do que assistir a um vídeo sobre como fazer pão de queijo.

4.2. Canais de denúncia que realmente funcionem

“Denuncie este conteúdo” não pode ser um botão decorativo, igual extintor vencido pendurado no corredor.

Uma denúncia de ameaça, suicídio iminente, abuso sexual, extorsão ou violência contra criança precisa entrar numa fila prioritária, com protocolo claro, rastreabilidade e resposta humana quando necessário.

Em linguagem de mainframe: não adianta gravar uma mensagem na fila se ninguém tem um consumidor ativo.

QUEUE: RISCO-CRITICO
STATUS: 14.000 mensagens pendentes
CONSUMIDOR: desligado desde 2022

Aí não é segurança. É cenografia.

4.3. Impedir reincidência

Se um servidor é removido, ele não pode reaparecer com nome trocado, dois emojis e uma conta criada há quinze minutos. Se uma pessoa é banida por comportamento grave, a empresa precisa ter mecanismos razoáveis para dificultar seu retorno.

Não se trata de perfeição. Criminosos tentam contornar controles. Mas permitir que a mesma operação volte com a facilidade de um COPY malicioso é falha de arquitetura.

4.4. Transparência e auditoria

Empresas devem explicar, sem entregar segredos a criminosos, quais são seus tempos de resposta, quantas denúncias recebem, como tratam casos críticos, quais controles usam e como medem reincidência.

O Estado, por sua vez, também deve explicar seus critérios. Se pede multa de centenas de milhões, precisa demonstrar a base técnica e jurídica do cálculo. Não basta abrir o painel e digitar:

MULTA = INDIGNACAO-NACIONAL * 100000000

Saul Goodman olha para essa fórmula e responde:

“Excelente para a coletiva de imprensa. Agora mostra a memória de cálculo.”





5. O “caso Felca”: quando uma causa correta vira pânico moral

O paralelo com a discussão que ficou conhecida como “caso Felca” não é dizer que proteção de crianças seja exagero. Pelo contrário: exploração, sexualização precoce, aliciamento, violência e abuso são problemas reais e graves.

O alerta é outro: uma causa legítima pode ser capturada por uma máquina de pânico moral.

O roteiro costuma ser assim:

  1. Surge um caso chocante.

  2. A mídia encontra imagens, personagens e indignação.

  3. Influenciadores, especialistas de ocasião e políticos entram na disputa.

  4. A tecnologia vira o vilão universal.

  5. A proposta legal aparece antes do diagnóstico técnico.

  6. A regra é vendida como solução total.

  7. Os efeitos colaterais chegam depois, quando a manchete já morreu.

Conservadores cristãos — e também grupos de outras correntes ideológicas, sejamos honestos — podem atuar como vigias morais muito atentos a temas envolvendo sexualidade, infância, cultura pop, redes sociais, jogos e comportamento juvenil. Muitas vezes há preocupação genuína. Pais têm medo. Famílias têm medo. E, francamente, há motivo para preocupação.

O problema nasce quando medo vira política pública sem freio.

Uma lei criada no calor de uma tragédia pode atingir não apenas abusadores, mas também adolescentes comuns, comunidades LGBT, artistas, educadores, pesquisadores, jornalistas, criadores independentes e pessoas que simplesmente querem privacidade.

A pergunta de ouro é:

“Esta medida reduz o crime sem criar uma máquina de vigilância, censura ou exclusão para inocentes?”

Se ninguém consegue responder claramente, não temos política pública. Temos um EXEC CICS HANDLE CONDITION escrito por pânico.



6. O risco brasileiro: uma catedral normativa sem equipe de operação

Aqui mora o grande medo: o Brasil é muito bom em produzir uma pilha impressionante de normas.

Criamos lei, decreto, portaria, resolução, grupo de trabalho, comitê, subcomitê, observatório, formulário, selo de conformidade e um PDF de 284 páginas cujo sumário começa na página 19.

No papel, parece robusto. Na prática, faltam investigadores especializados, perícia digital, equipes de apoio a vítimas, promotores treinados, delegacias equipadas, cooperação internacional e educação digital consistente nas escolas.

O resultado é previsível:

  • a plataforma grande, visível e com escritório responde à ação;

  • a empresa pequena sofre custo burocrático desproporcional;

  • o criminoso migra para outro aplicativo, VPN, conta descartável ou serviço estrangeiro;

  • famílias continuam sem orientação;

  • escolas continuam sem estrutura;

  • a polícia continua tentando investigar rede internacional com orçamento de impressora sem toner.

É o velho problema de operações: você pode ter o melhor runbook do planeta. Se não há gente, treinamento, acesso, monitoramento e processo de escalonamento, o runbook é literatura.

A lei precisa de dentes, mas precisa também de cérebro, braços e pernas.



7. Um passo a passo para não cair no tribunal da manchete

Para o jovem padawan COBOL — e para qualquer cidadão — aqui vai um procedimento de diagnóstico.

Passo 1: separe crime de falha de plataforma

Quem praticou, induziu, coagiu ou organizou a violência? Essa é a responsabilidade criminal direta.

Depois pergunte: a plataforma teve omissão própria, falha de segurança ou demora injustificável?

Passo 2: descubra se o ambiente era público, fechado ou criptografado

Não é detalhe. É arquitetura. E arquitetura muda o que é tecnicamente possível.

Passo 3: procure por alertas anteriores

A empresa recebeu denúncia? Havia histórico daquele grupo? Contas banidas voltaram? Um servidor removido reapareceu? O risco era conhecido?

Passo 4: avalie a resposta

Quanto tempo demorou? Que ações foram tomadas? Houve cooperação com autoridades? Houve preservação de evidências? Houve suporte à vítima?

Passo 5: compare com plataformas equivalentes

A mesma régua vale para TikTok, YouTube, Meta, Reddit, WhatsApp, Telegram e demais serviços? Se não, qual é a distinção objetiva?

Passo 6: desconfie da solução total

Toda proposta que promete “acabar com o problema” merece uma sobrancelha levantada. Especialmente se vier acompanhada de multa redonda, coletiva de imprensa e político dizendo que agora “a internet aprenderá”.



Epílogo — Saul Goodman fecha a pasta, Igor salva o log

Proteger crianças e adolescentes on-line é obrigação séria. Não é pauta de direita, esquerda, gamer, pai, mãe, igreja ou empresa: é obrigação civilizatória.

Mas proteger não é fingir que toda plataforma é onisciente. Não é quebrar criptografia. Não é usar uma morte trágica como senha para vigiar todos os cidadãos. Não é escolher uma empresa como bode expiatório e deixar os demais corredores escuros da internet intactos.

O Discord pode ter falhado. Se falhou, deve ser responsabilizado com provas, critérios técnicos, garantias de defesa e medidas que reduzam risco de verdade.

Só que a justiça será testada por sua consistência. Se cobra reação rápida, prevenção, transparência e combate à reincidência do Discord, deve cobrar isso também de YouTube, TikTok, Meta, Reddit e de qualquer plataforma comparável — respeitando as diferenças de arquitetura e privacidade.

Saul Goodman ajeita a gravata amarela, olha para o datacenter jurídico brasileiro e deixa seu parecer informal:

“Não confunda justiça com um botão vermelho. Botão vermelho todo mundo sabe apertar. Difícil é descobrir qual cabo ele corta.”

Easter egg para quem chegou até aqui: em algum lugar do CPD, Igor ainda está tentando abrir um chamado para a Internet inteira.

TICKET: INC-1984
ASSUNTO: “Favor moderar todos os humanos em tempo real”
STATUS: aguardando aprovação do Change Advisory Board

Boa sorte com isso.


https://eljefemidnightlunch.blogspot.com/2026/08/os-cem-barris-de-saque-como-cinco.html



Homens de Preto no Data Center — Quando o Agente J Encontrou uma GPU no LinuxONE e Perguntou: “Isso Aqui É CUDA ou o Igor Colou um RTX no PCIe?”

 

Bellacosa Mainframe e a possivel ponte em ibm z e nvidia sera????

☕ Um Café no Bellacosa Mainframe

Homens de Preto no Data Center — Quando o Agente J Encontrou uma GPU no LinuxONE e Perguntou: “Isso Aqui É CUDA ou o Igor Colou um RTX no PCIe?”

Ou: IBM colocou Arm dentro do futuro processador Z, NVIDIA já fala essa língua, o jovem padawan COBOL descobriu que uma placa gráfica não é um pendrive grande — e o Agente J precisou explicar DMA, IOMMU e LPAR antes que alguém chamasse o serviço de manutenção cósmica



Prólogo — uma luz estranha em Armonk

Agente J entrou na sala de máquinas com o Neuralyzer numa mão e um copo de café na outra.

— K, tem uma criatura de silício dizendo que o próximo IBM Z e LinuxONE pode executar Arm nativamente.

— Não a apague da memória, J. A IBM anunciou isso em 24 de agosto de 2026, durante o Hot Chips. É uma das notícias mais importantes para quem trabalha com mainframe desde que alguém resolveu chamar servidor de “legado” sem perceber que o legado estava pagando a conta do banco.

O anúncio descreve um futuro processador de dupla arquitetura para IBM Z e LinuxONE: em vez de haver um núcleo IBM de um lado e um núcleo Arm pendurado do outro, cada núcleo é projetado para executar instruções IBM e Arm de forma nativa. A meta é permitir ambientes Linux Arm ao lado de z/OS e do Linux que já vive em Z/LinuxONE. São planos de produto futuros, sujeitos a mudança; não existe, hoje, um menu da HMC com o botão “instalar CUDA e chamar a NVIDIA”. Mas o desenho muda a conversa inteira.

Para um programador COBOL iniciante, a notícia pode parecer distante. “Eu só quero meu READ, meu WRITE, um Db2 que não dê -911 e um CICS que não transforme a sexta-feira em incidente.” Justamente por isso ela importa. Mainframe não está virando PC gamer; está tentando deixar de ser uma ilha para uma parte maior da economia de software chegar perto daquilo que ele faz melhor: transações, dados críticos, disponibilidade e paranoia institucional bem aplicada.

Easter egg #1: o Agente J não disse “paranoia”. Ele disse “controle de acesso preventivo contra organismos com DMA”. O RACF aprovou a redação.


1. Primeiro: o que a IBM anunciou — e o que ela não anunciou

Vamos separar o café do conhaque.

A IBM anunciou uma direção arquitetural: processador futuro de 2 nm, 11 núcleos acima de 5,7 GHz, aceleradores de inferência e uma DPU de I/O no chip. O ponto realmente extraordinário é a implementação de AArch64/Arm em hardware, não por emulação. A IBM e a Arm dizem que a intenção é executar Linux Arm nativo simultaneamente com ambientes IBM tradicionais e herdar a escala, segurança e resiliência do Z/LinuxONE.

Ela não anunciou:

  • uma GPU NVIDIA certificada para Z ou LinuxONE;

  • CUDA em z/OS;

  • um driver NVIDIA s390x;

  • um DGX escondido dentro de um frame;

  • compatibilidade automática com qualquer placa comprada numa promoção suspeita.

Essa distinção protege você de duas doenças profissionais: o entusiasmo que vende PowerPoint como produto e o ceticismo que chama de “marketing” qualquer coisa que ainda não chegou ao rack. A posição correta é mais interessante: existe agora uma ponte arquitetural plausível; atravessá-la exige engenharia, qualificação e acordo comercial.



2. Por que Arm muda o problema da NVIDIA

Historicamente, Linux no IBM Z usa a arquitetura s390x. É excelente no seu território, mas possui um custo invisível: cada fornecedor externo precisa decidir se mantém outra compilação, outro pipeline de testes, outro driver de kernel, outra equipe de suporte e outra matriz de versões para um mercado menor que x86 e Arm.

Imagine que você escreveu um programa COBOL para ler um arquivo VSAM. Não basta entregar o fonte a alguém: é preciso compilador, copybooks, JCL, permissões RACF, dataset correto, testes e alguém responsável quando o job abendar às 02h17. Com uma GPU é igual, só que o “copybook” envolve firmware, PCIe, memória, interrupções e DMA.

NVIDIA já mantém uma pilha madura para Linux AArch64: driver, CUDA Toolkit, compiladores, bibliotecas como cuDNN e NCCL, PyTorch, TensorFlow e uma multidão de aplicações que nasceram para Arm em nuvens e servidores. Grace, Graviton, Ampere e Cobalt ajudaram a transformar Arm server em destino comercial sério.

Assim, a pergunta deixa de ser “NVIDIA, você pode criar e sustentar s390x?” e passa a ser “IBM, o seu ambiente Arm parece suficientemente um servidor Arm convencional para a pilha existente funcionar e ser suportada?”.

É uma diferença brutal:

Problema antigoProblema possível no novo cenário
Portar uma arquitetura inteiraQualificar uma plataforma Arm
Criar cadeia de ferramentasReutilizar uma cadeia AArch64
Testar um mercado exóticoTestar uma variante enterprise de Arm
Manter driver específico s390xAdaptar/validar driver Arm já existente

Não é garantia. É a troca de “construa uma estrada no oceano” por “a estrada chegou à fronteira; vamos inspecionar a ponte”.

3. Falar Arm não basta: o passaporte chamado SystemReady

Uma CPU saber executar instruções Arm é como o Agente J aprender um idioma alienígena. Útil, mas não informa em qual lado da rua ele deve dirigir, qual tomada existe no hotel ou se o passaporte abre a porta da alfândega.

Para Linux e drivers, o mundo abaixo da aplicação importa muito. Eles precisam reconhecer um ambiente previsível: firmware de boot, tabelas de hardware, relógios, controladores de interrupção, memória, PCIe, IOMMU, ACPI/UEFI e regras de descoberta de dispositivos. É isso que padrões como Arm SBSA, requisitos de boot e o programa Arm SystemReady tentam normalizar.

Relatos técnicos do Hot Chips indicam AArch64 v9.3, SVE/SVE2, operação little-endian do lado Arm e direção SystemReady. A consequência pretendida é preciosa: distribuições e binários Arm “de prateleira” teriam muito menos motivo para perguntar “que bicho é este?”. A própria NVIDIA construiu Grace mirando SBSA/SystemReady porque padrões reduzem o número de adaptações especiais que software precisa carregar.

Em linguagem de sala verde: SystemReady é a diferença entre receber um fonte COBOL e torcer para que compile, ou receber o fonte mais o padrão de dataset, o JCL, as PROCs, os parâmetros e a documentação de instalação. O primeiro funciona numa demo. O segundo tem chance de sobreviver à produção.

4. “Mas a GPU é PCIe; não é só encaixar?”

Não. E aqui o Agente J recolhe delicadamente a chave de fenda da mão do Igor.

PCIe é uma interconexão, não um contrato completo de convivência. A GPU precisa ser enumerada pelo sistema, expor regiões de memória mapeada (MMIO/BARs), gerar interrupções, ser reinicializada após falha, conversar com o driver e receber energia e refrigeração adequadas. O driver precisa enxergar topologia correta, páginas de memória, acesso DMA, recursos de virtualização e mecanismos de erro.

E uma GPU não fica esperando a CPU carregar cada byte como um garçom levando café de colher em colher. Ela usa DMA — Direct Memory Access. Simplificando, depois de autorizada, transfere dados diretamente entre sua memória e a memória do host. Isso é essencial para desempenho: modelos, tensores e lotes de inferência seriam ridiculamente lentos se cada movimento tivesse de passar pela CPU como um MOVE de bilhões de bytes.

No notebook de Igor, um driver malcomportado pode congelar a tela e produzir uma noite de palavrões. Em um LinuxONE, a máquina hospeda muitos clientes lógicos, com isolamento e disponibilidade que não podem depender de boa vontade de uma placa. Aí entra a IOMMU.

5. IOMMU: o segurança que não deixa a GPU passear pelo prédio

IOMMU significa, em essência, unidade que traduz e controla endereços de memória usados por dispositivos de I/O. Pense nela como o segurança de um edifício bancário. A GPU do LPAR A recebeu autorização para entrar na sala A-17; isso não lhe dá licença para testar todas as portas do corredor, muito menos alcançar a memória do LPAR B ou do ambiente de gestão.

Uma configuração segura precisa associar dispositivo, função virtual, LPAR e faixas de memória de maneira estrita. O driver pede uma operação; hardware e firmware garantem que o dispositivo veja apenas o que lhe foi atribuído. A ideia se parece com RACF: autenticar o usuário é apenas o começo; é a autorização de cada recurso que impede o desastre.

Mas atenção: “há IOMMU” não é uma frase mágica. Drivers NVIDIA têm requisitos e particularidades conforme GPU, kernel, topologia PCIe e virtualização. Há recursos de alta performance, como comunicação direta entre GPU e NIC, que podem depender de decisões de ACS, peer-to-peer e posicionamento físico. Em outras palavras: a placa pode funcionar para inferência simples e ainda não estar pronta para cada truque de HPC, NVLink ou multi-GPU.

6. LPAR, z/VM e a diferença entre dividir e bagunçar

Um LPAR é uma partição lógica: uma máquina dentro da máquina, separada por hardware e firmware. Para o iniciante, compare-o a uma região CICS muito séria, com seu próprio universo operacional — só que o isolamento não é mera convenção de software.

O caminho inicial mais sensato seria algo parecido com isto:

  1. A IBM certifica um modelo específico de GPU e o respectivo drawer PCIe.

  2. A HMC/firmware atribui a função física ou virtual a uma LPAR Arm Linux.

  3. Esse Linux vê um dispositivo PCIe compatível, carrega driver NVIDIA Arm64 e o CUDA runtime.

  4. O aplicativo usa a GPU; o IOMMU restringe o DMA à memória autorizada.

  5. Telemetria, manutenção, falhas e troca de peça entram no modelo operacional IBM.

O primeiro alvo não precisa ser compartilhar uma placa com trinta tenants. Pass-through para uma LPAR, bem cercado, já seria uma vitória enorme. Depois vêm os chefes de fase: MIG, vGPU, SR-IOV, cobrança, reset seletivo, migração, isolamento multi-tenant e recuperação automática.

7. Spyre: o precedente que ajuda, sem virar atalho enganoso

A IBM já vende o Spyre Accelerator para z17 e LinuxONE Emperor 5. É uma placa PCIe orientada a inferência e fine-tuning, com runtime, driver, firmware e integração de software próprios. A solução suporta até 48 placas em sistemas Z/LinuxONE e foi desenhada com appliances de suporte, funções virtuais, monitoramento e redundância de caminhos.

Isso importa porque prova uma coisa concreta: IBM não está começando agora a discutir “como colocar um acelerador poderoso, que faz DMA, num mainframe particionado sem transformar o equipamento numa lan house cósmica”. Ela já tem práticas para atribuição, saúde do dispositivo, tolerância a falha e operação.

Mas Spyre não é uma GPU NVIDIA pintada de azul. Ele é uma solução vertical: IBM controla hardware, firmware, compilador, runtime e o suporte. CUDA traria outro ecossistema, outra cadência de drivers e outra responsabilidade dividida. Spyre diminui o risco de integração; não elimina a negociação com NVIDIA.

8. Telum, Spyre e CUDA não são três nomes para a mesma coisa

TecnologiaOnde brilhaExemplo
TelumInferência muito próxima da transaçãoPontuar fraude durante a autorização
SpyreIA empresarial integrada e eficienteServir modelos e fine-tuning controlado
GPU NVIDIA/CUDAEcossistema amplo e computação aceleradaPyTorch, visão, LLMs, analytics e bibliotecas CUDA

O desenho vencedor não é substituir um pelo outro. É usar cada peça onde tem vocação.

Uma transação chega pelo CICS. O programa COBOL executa regras, chama Db2 e precisa decidir agora: aprovar, bloquear ou pedir segundo fator. Telum pode atender a inferência ultrarrápida. Um serviço Arm Linux pode, assíncronamente ou numa etapa apropriada, executar análise mais pesada em CUDA: enriquecer evento, correlacionar fraude, gerar explicação para analista, fazer busca vetorial, analisar imagens de documento ou retreinar um modelo.

O COBOL não precisa aprender CUDA para participar. Ele precisa aprender a pedir serviço de forma confiável: API, MQ, eventos, timeouts, idempotência, commit e rollback. O padawan que entende isso não vira passageiro do futuro; vira o adulto na sala quando alguém propõe chamar um modelo de 70 bilhões de parâmetros no meio de uma transação de 80 milissegundos.

Easter egg #2: o Agente J proibiu CALL 'CHATGPT' dentro do caminho crítico. Igor perguntou se ao menos poderia fazer um GOTO 9999 para o modelo. O Agente K desligou o monitor.

9. O inimigo físico: potência, calor e topologia

É tentador imaginar oito B200 surgindo de um drawer como alienígenas de um ovo. Só que uma GPU de datacenter de ponta pode consumir centenas de watts; sistemas HGX/NVSwitch exigem potência, refrigeração, espaço e rede próprios. NVLink não é “PCIe com café forte”.

Portanto, mesmo que CUDA se torne viável, o primeiro produto provável seria uma GPU PCIe específica e homologada para inferência ou aceleração selecionada, entregue a uma LPAR Arm. Um superpod para treinar modelo de fronteira provavelmente continuará sendo infraestrutura dedicada, conectada ao Z/LinuxONE por rede rápida e governada como outro domínio.

Mainframe não precisa vencer um DGX no campeonato errado. O valor está em reduzir a distância entre dado crítico, transação, segurança e capacidade de IA — sem copiar meio banco para uma plataforma externa só para fazer uma pergunta ao modelo.

10. Roteiro prático para o programador COBOL iniciante

Você não precisa comprar uma GPU nem decorar registradores Arm amanhã. Faça esta trilha:

  1. Domine transação. Entenda CICS, Db2, VSAM, unidade de trabalho, syncpoint, COMMIT e ROLLBACK. IA sem integridade transacional é Igor vendendo PIX por e-mail.

  2. Aprenda a fronteira. Veja JSON, HTTP, APIs REST, MQ e eventos. Seu COBOL continuará sendo o coração de muitos processos; ele precisa conversar sem acoplamento burro.

  3. Conheça Linux e containers. Não para abandonar Z, mas para entender onde os serviços Arm e IA vão viver. Um container não é uma LPAR; ambos isolam, mas em níveis diferentes.

  4. Entenda os quatro D’s. Dados, DMA, dispositivos e dependências. Pergunte sempre: onde o dado nasce, quem pode movê-lo, quem o enxerga e como o processo se recupera?

  5. Aprenda observabilidade. Latência, throughput, erro, saturação, logs e rastreamento. “A IA ficou lenta” não é diagnóstico; é o equivalente moderno a “deu ABEND”.

  6. Pense em governança. Modelo pode errar, vazar, enviesar e mudar. Dados bancários ou pessoais não ganham permissão para viajar só porque a demo ficou bonita.

11. As perguntas que realmente importam agora

Quando surgirem detalhes, não pergunte primeiro “quantos teraflops?”. Pergunte:

  • Qual nível de certificação SystemReady a IBM entregará?

  • Quais distribuições Arm bootam sem alteração?

  • Como PCIe e IOMMU aparecem para a LPAR Arm?

  • Haverá GPU pass-through? Virtualização? MIG/vGPU?

  • Quais modelos, drivers e versões CUDA serão homologados?

  • Como são feitos reset, firmware update, diagnóstico e failover?

  • Qual é a latência entre o dado em z/OS/Db2 e o serviço acelerado?

  • O caso de uso justifica trazer a IA para perto, ou MQ/API para infraestrutura externa já resolve melhor?

Essas perguntas são mais maduras que “roda Doom?”. Embora, em nome da ciência, o Agente J tenha anotado a segunda numa planilha confidencial.

Epílogo — a ponte não é o destino

A IBM não entregou CUDA no mainframe em agosto de 2026. Entregou algo talvez mais estratégico: uma tentativa de tornar o próximo Z/LinuxONE um anfitrião Arm suficientemente padrão para que ecossistemas já existentes possam reconhecê-lo.

Para NVIDIA, isso pode converter um port caro e exclusivo para s390x em uma qualificação de plataforma Arm. Para IBM, é uma maneira ousada de reduzir o isolamento histórico de sua arquitetura. Para clientes, pode significar aproximar software moderno e aceleradores dos dados mais críticos sem abandonar as qualidades que fizeram o mainframe sobreviver a cada funeral prematuro anunciado desde os anos 1980.

E para nós, do COBOL, a lição é confortavelmente simples: o futuro não exige que você esqueça o que sabe. Exige que você entenda onde seu programa termina, onde o serviço começa, como o dado atravessa a fronteira e quem responde quando a GPU, o driver ou o universo resolve dar ABEND.

O Agente K guardou o Neuralyzer.

— Então não apagamos a memória do anúncio?

— Não, J. Só colocamos uma nota no rodapé: “promissor, tecnicamente difícil, comercialmente aberto e absolutamente incapaz de ser instalado pelo Igor numa sexta-feira às 17h58”.

E, por uma vez, até o RACF concordou.


Fontes para continuar a investigação

Yayoi Kusama — Quando Um Milhão de Chimpanzés Abriu um Barril de Saquê, Igor Pintou as Canecas de Bolinhas e a Samurai do Infinito Partiu sem Jamais Sair da Tela

 

Bellacosa Maifnrame em uma homenagem a Yayoi Kusama

☕ Um Café no Bellacosa Mainframe

Yayoi Kusama — Quando Um Milhão de Chimpanzés Abriu um Barril de Saquê, Igor Pintou as Canecas de Bolinhas e a Samurai do Infinito Partiu sem Jamais Sair da Tela

Ou: a menina que via o mundo ser engolido por pontos transformou o medo em galáxias, ensinou Nova York a ser mais estranha, fez o TikTok entrar numa sala de espelhos e deixou animes, mangás e nerds de todo o planeta olhando para uma abóbora como se ela fosse um portal cósmico.

Hoje, 27 de agosto de 2026, chegou a notícia que ninguém queria receber: Yayoi Kusama morreu aos 97 anos, em Tóquio, em 14 de agosto. A confirmação veio do próprio Museu Yayoi Kusama. A Terra, portanto, perdeu a rainha das bolinhas; o universo, se tiver bom gosto, ganhou uma instaladora-chefe para consertar a iluminação das estrelas. O anúncio oficial está aqui.

Então o milhão de chimpanzés abre um barril de saquê. Igor, naturalmente, foi encarregado de servir — e já conseguiu derramar metade numa abóbora amarela com poás pretos. Erguemos a caneca:

À Yayoi Kusama: que a Terra lhe seja leve, que o infinito lhe seja familiar e que nenhuma parede do outro lado fique sem bolinhas.

Porque é fácil reduzir Kusama à caricatura simpática: a velhinha de peruca vermelha, vestido chamativo, abóboras amarelas, salas em que o visitante entra por trinta segundos, faz quatrocentas fotos e sai se sentindo personagem de anime isekai. Mas isso seria como definir Hayao Miyazaki como “o senhor que desenha bichos fofinhos”: há uma aparência acessível por cima de uma vida inteira de guerra, obsessão, fragilidade, disciplina e imaginação monstruosamente poderosa.

Yayoi Kusama não decorava o mundo com bolinhas. Ela tentava sobreviver a ele.


A menina que viu o universo invadir o quarto

Kusama nasceu em 1929, em Matsumoto, no Japão. Desde criança, relatou experiências visuais intensas: padrões, redes, flores e pontos pareciam se espalhar pelas superfícies, pelo corpo e pelo espaço à sua volta. A imagem que para nós parece alegre — uma parede tomada por círculos coloridos — para ela podia ser uma avalanche.

E aqui mora a chave de tudo: a obra de Kusama não nasceu de uma campanha de branding perfeitamente calculada. Nasceu de um mecanismo de enfrentamento. Ela pegou aquilo que ameaçava engoli-la e o obrigou a obedecer ao pincel.

As bolinhas viraram linguagem. As redes viraram linguagem. As abóboras viraram linguagem. A repetição, que poderia ser prisão, tornou-se método.

Ela chamava essa ideia de self-obliteration, algo como autodiluição ou autoapagamento. Não é a vontade triste de desaparecer do mundo; é outra coisa, mais estranha e mais cósmica: deixar de ser um ego solitário e rígido para virar um pequeno ponto entre bilhões de pontos. Você entra numa Infinity Mirror Room, olha os reflexos multiplicados e entende a brincadeira filosófica: “eu” não é exatamente o centro da tela. Sou um pontinho luminoso no meio de uma imensidão.

É uma noção que qualquer nerd reconhece imediatamente. É o sentimento de olhar para o espaço em Cowboy Bebop, de cair num sonho em Paprika, de perder a referência em Serial Experiments Lain ou de encarar uma realidade que se repete, se fragmenta e começa a olhar de volta para você.


A samurai saiu do Japão e invadiu Nova York

O Japão do pós-guerra não era exatamente um ambiente confortável para uma jovem artista determinada, experimental e disposta a pintar o mundo até ele perder a compostura. Kusama estudou pintura tradicional japonesa, o nihonga, mas rapidamente percebeu que o traje não lhe servia. Ela queria outra coisa: escala, ruptura, estranhamento, liberdade.

Em 1957, mudou-se para os Estados Unidos; em 1958, chegou a Nova York. Não entrou pela porta dos fundos pedindo licença. Entrou no caldeirão da vanguarda dos anos 1960 com suas pinturas de redes infinitas, esculturas macias, performances, filmes, poemas, roupas e happenings.

Imagine o cenário: Nova York querendo virar Pop Art, Minimalismo e psicodelia ao mesmo tempo. Andy Warhol, Claes Oldenburg, Donald Judd, galeristas, críticos, egos do tamanho de edifícios. E no meio daquilo, uma mulher japonesa, estrangeira, trabalhando com uma insistência quase sobre-humana.

Kusama não era “a artista das bolinhas”. Era pintora, escultora, performática, cineasta, poeta e romancista. Fez ambientes espelhados antes que “instalação imersiva” virasse palavra de release; fez crítica social, performances contra a guerra e obras que desmontavam o olhar masculino sobre o corpo.

Também viveu a parte cruel da história da arte: várias ideias que ela desenvolvia eram celebradas quando reapareciam sob a assinatura de homens mais aceitos pelo circuito. Não é preciso transformá-la numa santa nem numa vítima perpétua para reconhecer a injustiça estrutural: Kusama foi pioneira, mas por muito tempo foi tratada como nota de rodapé de movimentos que ajudou a antecipar.

A conta demorou, mas chegou. E chegou com juros, correção monetária e uma abóbora gigante estacionada no meio do caminho.


A abóbora não é fofura; é autorretrato

Há quem olhe para uma abóbora de Kusama e pense: “pronto, a parte Instagramável da exposição”. Igor pensou isso uma vez e quase foi expulso da sala por um segurança imaginário.

A abóbora para Kusama era forma, memória, alimento, humor e autorretrato. Ela associava o vegetal à infância e à sensação de algo ao mesmo tempo humilde, acolhedor e extraordinário. A famosa abóbora de Naoshima — amarela, negra, grande, à beira do mar — é quase um personagem silencioso: parece uma criatura de JRPG pacífica que sabe mais sobre o universo do que todos os humanos juntos.

E faz sentido que a cultura pop japonesa a tenha adotado com facilidade. O Japão entende objetos que se tornam personagens: uma chaleira pode ter alma, uma floresta pode ter vontade própria, um monstrinho redondo pode carregar uma tristeza inteira. Kusama fez da abóbora um ícone sem precisar dar olhos, fala ou golpe especial. Ela já possuía presença.

Por que os nerds a adotaram tão naturalmente?

Porque Kusama fez arte que parece vir de uma região onde arte contemporânea, horror cósmico, ficção científica, estética pop e sonho febril dividem o mesmo apartamento.

Ela oferece quatro ingredientes que anime, mangá, games e internet adoram:

  • Repetição que vira vertigem: padrões infinitos, corredores, reflexos, cópias e enxames visuais.

  • Cor que parece inocente, mas esconde abismo: amarelos, vermelhos, pretos, luzes e flores que não são apenas “bonitas”.

  • Mundo interno virando cenário: aquilo que ela sente não fica explicado em diálogo; ocupa a tela inteira.

  • Uma autora visualmente inconfundível: viu poás, abóbora, espelho e peruca vermelha? Seu cérebro já responde “Kusama”.

Ela virou uma espécie de código cultural. Nem todo vídeo de TikTok com poá está citando Yayoi Kusama; nem toda sala espelhada é uma homenagem. Mas a partir dela, o grande público passou a entender que arte pode ser um ambiente, uma experiência física e uma pequena invasão sensorial.

Antes, o visitante olhava uma obra. Depois de Kusama, ele entra nela — e por alguns segundos vira parte do mecanismo.

Anime e mangá: homenagens, ecos e uma pequena regra de honestidade

Aqui o Agente J do MIB aparece com uma pasta, tosse discretamente e pede precisão: não existe um grande catálogo consolidado de animes e mangás com homenagens oficialmente declaradas a Kusama equivalente, por exemplo, às referências assumidas de JoJo’s Bizarre Adventure à música e à moda.

Há algo mais interessante acontecendo: Kusama virou uma referência visual tão difundida que seu vocabulário foi absorvido pela cultura pop. Por isso, é melhor separar citação direta de eco estético — para não deixar Igor atribuir cada bolinha da animação japonesa à mulher de Matsumoto.

Em obras como Paprika, de Satoshi Kon, há o parentesco da imagem que cresce além do controle, da invasão do cotidiano por uma lógica de sonho e da identidade que se dissolve num espetáculo visual. Não é correto carimbar “homenagem direta” sem declaração do autor; é correto dizer que ambos conversam com uma tradição japonesa — e internacional — de tornar o inconsciente uma paisagem.

Serial Experiments Lain trabalha outra versão desse território: repetição, multiplicação do eu, tecnologia como ambiente psíquico, o indivíduo virando sinal em uma rede maior do que consegue compreender. Kusama fazia isso com espelhos e pontos; Lain, com cabos, telas e ruído.

Em Puella Magi Madoka Magica, especialmente nas dimensões das bruxas, o espectador encontra colagem, ornamento, padrão repetitivo e beleza que rapidamente se converte em desconforto. De novo: não é necessário inventar uma homenagem formal para reconhecer a mesma pergunta visual — quando a mente sofre, por que ela às vezes produz mundos tão coloridos?

E Junji Ito, mestre do mangá de horror, parece fazer a versão sombria da operação Kusama. Em Uzumaki, a espiral deixa de ser forma decorativa e vira maldição que se espalha pelas pessoas, casas e cidades. Kusama via pontos e redes; Ito vê espirais. Ambos entendem que um padrão repetido pode ser mais assustador do que um monstro com dentes.

A diferença é de postura. Kusama encara a repetição e tenta transformá-la em universo, amor, sobrevivência e comunhão. Junji Ito olha para ela e pergunta: “e se o universo estivesse muito interessado em nos mastigar?”

Essa é a ponte verdadeira com o mangá e o anime: não um desfile de easter eggs de poá, mas a legitimação de uma linguagem em que obsessão, trauma, desejo, medo e imaginação podem ocupar todo o enquadramento sem pedir desculpa.

A artista que viveu para trabalhar

Em 1973, Kusama voltou ao Japão. Em 1977, passou a viver voluntariamente em uma instituição psiquiátrica em Tóquio, mantendo seu estúdio perto dali e trabalhando continuamente. É preciso falar disso com respeito, sem transformar sofrimento mental em enfeite de biografia.

O ponto extraordinário não é romantizar dor. É reconhecer a disciplina de uma artista que encontrou na criação uma forma de permanecer viva e de organizar aquilo que a aterrorizava. Ela continuou pintando, escrevendo, desenhando, criando instalações e expandindo sua linguagem por décadas.

Com o tempo, veio a reavaliação histórica, as grandes retrospectivas, os museus, as filas, as colaborações com moda, o Museu Yayoi Kusama em Tóquio e a consagração global. Mas o coração da história nunca foi o luxo nem a selfie. Foi uma mulher que passou quase um século encarando suas visões e respondendo: “então eu vou fazer arte com isso.”

O museu dela continuará com exposições e preservará o trabalho que ela deixou. A agenda futura, ironicamente, já inclui uma mostra chamada “The Light Spreads Out, and Glittering Things Start Appearing All Around Me”A luz se espalha, e coisas cintilantes começam a aparecer ao meu redor. Parece título de despedida escrito por uma heroína de anime que se recusa a sair de cena. O museu lista a programação aqui.

Epílogo — a bolinha não acabou

Yayoi Kusama morreu, mas não deixou uma obra que se comporta como passado. Ela deixou uma linguagem que ainda pulsa: no museu, no meme, no vídeo curto, na moda, na instalação, no jogo, no imaginário de quem vê um padrão colorido e suspeita que há um universo escondido nele.

O curioso é que ela conseguiu algo raro: tornou-se popular sem ficar superficial. A pessoa pode entrar numa sala de espelhos para fazer uma foto bonita; talvez, por acidente, saia de lá pensando que é minúscula diante do infinito. Isso já é arte fazendo seu trabalho.

Então levantemos mais uma caneca de saquê.

Não para dizer adeus como quem fecha uma porta, mas como quem entra numa sala cheia de espelhos, vê milhões de pontos luminosos e entende que uma delas ainda está ali — pequena, vermelha, teimosa, indestrutível — pintando o cosmos para que ele não pareça tão assustador.

quarta-feira, 26 de agosto de 2026

🚀 A Hidrelétrica Digital — Quando o Agente J Entrou na Sala de Controle do z/OS e Descobriu que Cem Alertas Não Eram Cem Problemas

 

Bellacosa Mainframe e a hidreletrica digital monitorando um mainframe

☕ Um Café no Bellacosa Mainframe

🚀 A Hidrelétrica Digital — Quando o Agente J Entrou na Sala de Controle do z/OS e Descobriu que Cem Alertas Não Eram Cem Problemas

Ou: o mainframe não precisava de mais pares de olhos diante de dashboards; precisava de sensores, contexto, bons procedimentos e alguém que não apertasse o botão vermelho só porque Igor disse que a luz estava piscando

O Agente J, recém-saído de mais uma manhã tentando explicar ao público que alienígenas não usavam cartão de ponto, entrou no centro de operações e parou diante de uma parede de telas. Havia gráficos verdes, amarelos, vermelhos, mapas de aplicações, filas, porcentagens de CPU, mensagens de console, tickets e, em um canto suspeito, um operador olhando para o JES como quem esperava que ele revelasse o futuro nas entranhas de um SYSOUT.

— Então é aqui que vocês protegem o banco? — perguntou J.

— Em tese — respondeu o Agente K. — Em prática, às vezes protegemos o banco de 97 alertas que são a mesma coisa usando fantasias diferentes.

O colega apontou para a tela. A CPU estava alta. Uma fila MQ crescia. O Db2 apresentava espera. Uma transação CICS ficava lenta. Um job batch ultrapassara o horário previsto. A API móvel exibia aumento de timeout.

— São seis incidentes? — J perguntou.

K colocou os óculos escuros, porque alguma instituição provavelmente ainda não havia inventado um protocolo para isso.

— Talvez seja um só. Esse é o problema.

É aí que começa a conversa sobre Mainframe Operations inteligente. Não se trata de substituir o operador L1, o analista L2, o DBA, o especialista CICS ou aquela pessoa que conhece uma regra de negócio tão antiga que parece ter sido entregue junto com o primeiro cartão perfurado. Trata-se de parar de usar profissionais experientes como sensores biológicos de dashboard.

O mainframe continua sendo uma das salas de máquinas mais confiáveis do mundo. Mas confiável não significa simples. Ele conversa com aplicações web, mobile, APIs, nuvens, filas, parceiros, cartões, pagamentos, batches, sistemas de fraude e uma coleção de integrações que, em alguns bancos, já possui mais dependências do que a árvore genealógica dos Targaryen. Observar tudo isso apenas olhando telas é como operar uma hidrelétrica com uma lanterna e um caderninho.


A hidrelétrica que, por acaso, processa pagamentos

A melhor analogia para entender AIOps no mainframe é uma hidrelétrica moderna.

Uma usina possui centenas ou milhares de sinais: nível da água, vazão, pressão, vibração, temperatura, rotação da turbina, posição de comportas, tensão, frequência e estado de equipamentos. Um sensor isolado raramente conta a história inteira. Uma vibração levemente maior pode ser normal. Vibração crescente junto com temperatura elevada, perda de eficiência e alteração de pressão é outra conversa: alguém precisa investigar antes que a conversa vire notícia.

O ambiente z/OS tem seus próprios sensores:

  • CPU, memória, dispatching e metas de serviço do WLM;

  • I/O, canais, volumes e espaço de DASD;

  • jobs, initiators, spool e mensagens do JES2;

  • tempos de resposta e regiões do CICS;

  • locks, waits, pools e SQL no Db2;

  • filas, canais e consumidores no MQ;

  • transações IMS e conectividade TCP/IP;

  • logs, traces, mensagens do console e registros SMF;

  • latência de APIs, erros de aplicativos e experiência do cliente.

O cliente, no entanto, não vê nenhum desses itens. Ele vê uma pergunta de cinco segundos: “o PIX foi?”, “o pagamento entrou?”, “consigo consultar meu saldo?”, “a folha fechou?”.

Por isso, operação madura não monitora apenas componentes. Ela monitora serviços de negócio e usa os componentes para explicar o que aconteceu com eles.

CPU alta numa LPAR pode ser apenas o processamento esperado do fechamento. CPU alta, fila MQ crescendo, transação CICS acima do SLO e timeout no app bancário é uma tempestade se formando. A diferença não está no gráfico; está no contexto.


Antes da IA: alerta, evento, incidente, problema e mudança

Em operações, algumas palavras são tratadas como sinônimos até o dia em que deixam de ser. Vale colocá-las em ordem antes de dar uma pistola neuralizadora ao dashboard.

Um evento é qualquer ocorrência observável: uma mensagem no console, um job terminando, uma conexão caindo, uma alteração de estado. Um alerta é um evento que cruza uma regra de atenção: a fila passou de determinado tamanho, o tempo de resposta ultrapassou um limite, um recurso ficou indisponível.

Um incidente é quando um serviço está interrompido ou degradado. “Clientes não conseguem pagar” é incidente. Já um problema é a causa persistente ou subjacente que pode produzir vários incidentes: um plano SQL ruim, uma parametrização incorreta, um vazamento de recurso, um processo batch concorrendo de modo inadequado.

E há a mudança: o deploy, ajuste de parâmetro, manutenção ou alteração de configuração que pode ser a solução, a causa ou uma coincidência muito suspeita.

O erro clássico do monitoramento tradicional é transformar cada alerta em um incidente. Assim, uma única regressão após um deploy gera tickets separados para API, CICS, Db2, MQ, rede e storage. Cada equipe recebe seu fragmento do elefante e conclui que a culpa está em outra sala.

O objetivo da correlação é fazer o caminho oposto: agrupar os sintomas e apresentar um incidente operacional coerente.

Incidente: Pagamentos digitais degradados.
Impacto: clientes com timeout acima de três segundos.
Serviços envolvidos: API Payments → CICS PAYM → Db2 DBPAY → MQ.
Início: logo após a mudança CHG004321.
Hipótese: aumento de chamadas e regressão de plano SQL.
Próximo passo: coletar evidências e executar runbook aprovado.

Note a palavra importante: hipótese. Uma plataforma inteligente deve apresentar causa provável e nível de confiança, não posar de oráculo. Correlação temporal é valiosa; não é prova definitiva de causalidade.



O que as ferramentas trazem para a sala de controle

Ferramentas como IBM OMEGAMON, BMC AMI Ops e Broadcom SYSVIEW dão visibilidade profunda de z/OS e seus subsistemas. Elas ajudam a enxergar o que realmente acontece na LPAR, no CICS, no Db2, no MQ, no IMS, no JES e nos recursos que sustentam a carga. São os instrumentos de engenharia da usina.

IBM Z System Automation, NetView e soluções como OPS/MVS entram mais diretamente na parte de automação orientada a eventos, disponibilidade e ações controladas. Elas podem detectar estados, aplicar políticas e disparar procedimentos conhecidos.

No outro extremo da jornada, plataformas de observabilidade como Instana, Dynatrace e AppDynamics ajudam a costurar a visão de ponta a ponta: o clique no aplicativo, a API, o middleware, a transação no mainframe e o retorno ao cliente. Splunk e Elastic podem centralizar logs, eventos e análises, desde que os dados tenham qualidade, horário confiável e acesso devidamente protegido. ServiceNow organiza o processo: ticket, mudança, aprovação, SLA, escalonamento, CMDB e workflow.

O detalhe que slides de marketing omitem é este: nenhuma dessas ferramentas, isoladamente, é AIOps. A inteligência aparece na integração.

Um monitor detecta a anomalia. A topologia informa as dependências. A CMDB identifica o serviço e seu dono. O histórico aponta o comportamento esperado. O motor de correlação reduz o ruído. O ServiceNow abre um incidente já enriquecido. A automação executa uma ação de baixo risco. E a observabilidade confirma se o serviço voltou a funcionar.

Sem esse encadeamento, temos várias telas bonitas. Com ele, temos uma sala de controle.


Threshold estático: o velho porteiro ainda tem emprego

“Alerta quando CPU ultrapassar 90%.” É uma regra simples, útil e incompleta.

Às duas da manhã, no processamento mensal, 90% pode ser esperado. Às duas da tarde, numa LPAR que normalmente opera a 45%, 65% pode ser a primeira pista de algo muito estranho. É aqui que entram baseline, sazonalidade e detecção de anomalia.

Uma boa análise pergunta:

  • este comportamento é normal para este horário e este dia?

  • houve alteração abrupta, mesmo abaixo do limite absoluto?

  • quais métricas se moveram juntas?

  • qual serviço de negócio foi afetado?

  • houve mudança, deploy ou manutenção recente?

  • o impacto é crescente ou estável?

Mas não se deve jogar fora os limites rígidos. Espaço de DASD quase esgotado, fila aproximando-se de limite físico, certificado prestes a expirar e recurso indisponível não precisam aguardar uma tese de machine learning. O ambiente maduro combina limites determinísticos para riscos claros e anomalias estatísticas para padrões sutis.

O Agente J resumiria assim: “Se o reservatório está transbordando, não vamos montar um comitê para saber se a água parece incomumente molhada.”



Do alerta ao incidente: um caso de banco digital

Imagine que, às 10h05, clientes começam a relatar lentidão ao efetuar pagamentos.

No modo antigo, L1 abre o dashboard da aplicação e vê timeout. Depois consulta CICS e identifica transações com maior tempo de resposta. Abre Db2 e encontra waits. Vai ao SDSF verificar jobs. Olha MQ. Procura mensagens. Cria ticket. Escala para L2, DBA, middleware, infraestrutura e, por segurança, para a equipe que fez o último deploy. Todos começam a investigar ângulos diferentes.

No modelo inteligente, as informações chegam correlacionadas. A plataforma observa que:

  • a jornada “pagamento digital” ultrapassou seu SLO;

  • a API Payments aumentou o volume de requisições;

  • a transação CICS PAYM ficou lenta;

  • o Db2 mostrou aumento de waits e uma consulta específica mudou de comportamento;

  • a fila MQ começou a acumular mensagens;

  • tudo teve início minutos após uma mudança registrada.

O L1 não recebe seis sirenes. Recebe um incidente com impacto, dependências, evidências, possíveis responsáveis e runbook.

Isso não elimina a investigação técnica. Elimina a caça ao tesouro inicial — aquela meia hora em que cada pessoa tenta descobrir se o incêndio é real, onde começou e quem tem a chave do armário de mangueira.

Para um programador COBOL iniciante, existe uma lição excelente aí: seu PROGRAM-ID quase nunca vive sozinho. Uma rotina aparentemente inocente pode chamar Db2, publicar em MQ, ser acionada por CICS, expor dados por API e participar de um fluxo que movimenta dinheiro. Aprender a observar o caminho da transação é tão importante quanto acertar o PERFORM.



Self-healing sem transformar Igor em DBA de produção

Automação de recuperação é maravilhosa até alguém programar uma rotina para derrubar uma região CICS crítica por causa de um alerta mal calibrado. Por isso, “self-healing” precisa ser dividido por risco.

Há ações ótimas para automação total:

  • coletar logs, mensagens, dumps e métricas quando surge uma anomalia;

  • abrir e enriquecer incidentes;

  • executar health checks;

  • reiniciar um processo isolado e conhecido;

  • elevar temporariamente o nível de monitoramento;

  • pausar uma cadeia batch antes que um erro se propague;

  • fazer a notificação e o escalonamento corretos.

Outras ações devem ser assistidas ou requerer aprovação:

  • cancelar batch crítico;

  • alterar WLM;

  • modificar parâmetro Db2;

  • derrubar ou reciclar região compartilhada;

  • fazer failover;

  • alterar RACF, certificados, conectividade ou regras de segurança;

  • realizar rollback de aplicação.

A regra de ouro é simples: quanto maior o raio de explosão, maior a necessidade de aprovação humana, trilha de auditoria e rollback.

Uma hidrelétrica não permite que um algoritmo abra todas as comportas porque um sensor piscou. Ela trabalha por níveis: automático para ajustes seguros e reversíveis; assistido para recomendações que o operador aprova; manual para decisões críticas. A operação de mainframe deveria seguir exatamente essa filosofia.

Igor, naturalmente, propôs colocar CANCEL JOB(*) dentro de um botão verde chamado “cura automática”. O Agente K confiscou o teclado. Segurança também é uma forma de carinho.



L1 e L2: menos mensageiros, mais operadores de exceção

A evolução não diminui o valor de L1 e L2; ela muda o tipo de valor entregue.

L1 deixa de ser a pessoa que copia mensagens de console para um ticket e pode se tornar operador de exceções: valida impacto, executa runbooks aprovados, confirma se a correção funcionou, faz comunicação operacional e escalona com evidências.

L2 ganha espaço para trabalho que diminui as próximas madrugadas ruins: análise de causa raiz, ajuste de alertas, automações, gestão de capacidade, revisão de arquitetura, melhoria de runbooks e eliminação de falhas recorrentes.

Isso é próximo da cultura de SRE: não basta apagar incêndio com eficiência; é preciso descobrir por que o prédio continua tendo incêndios na mesma tomada.



A parte chata que salva o projeto: dados, nomes e procedimentos

Antes de contratar uma IA com nome de nave espacial, arrume a base.

Se a aplicação é chamada de PAGTO no mainframe, “Pix” pelo negócio, “Payments Hub” na CMDB e APP-347 no dashboard, a ferramenta não ganhou contexto; ganhou quatro identidades secretas para o mesmo serviço. Nem o MIB tem orçamento para isso.

Os obstáculos reais costumam ser:

  • alertas duplicados ou sem dono;

  • topologia e CMDB desatualizadas;

  • logs sem correlação, timestamp confiável ou padronização;

  • mudanças sem registro operacional;

  • runbooks velhos, incompletos ou guardados na cabeça de uma única pessoa;

  • ausência de SLOs e indicadores de impacto de negócio;

  • automações sem teste, validação ou rollback;

  • permissões excessivas em contas técnicas.

Lembre-se: IA alimentada por telemetria ruim apenas produz conclusões ruins com uma confiança irritantemente bem redigida.



Um roteiro possível para começar

Não tente modernizar todos os alertas do universo numa única change. Comece pequeno, mensurável e dolorosamente real.

Primeiro: reduza ruído. Revise alertas. Cada alerta deve ter dono, severidade, ação esperada e justificativa. Se ninguém sabe o que fazer quando ele dispara, provavelmente não é alerta; é decoração sonora.

Segundo: escolha jornadas críticas. Pagamento, PIX, cartão, fechamento, folha, faturamento, autorização. Comece por aquilo cuja indisponibilidade o negócio percebe em minutos.

Terceiro: mapeie dependências. Desenhe API, middleware, CICS/IMS, Db2, MQ, batch, rede, storage e terceiros. A pergunta é: “se isto falhar, quem sente?”

Quarto: escreva runbooks utilizáveis. Não um PDF de 200 páginas enterrado no SharePoint. Um procedimento que diga sintomas, verificações, comandos autorizados, evidências, critérios de parada, escalonamento e rollback.

Quinto: automatize a coleta antes da correção. Fazer a máquina montar um ticket excelente e reunir evidências já reduz muito MTTR. Automação de remediação vem depois, em ações reversíveis e testadas.

Sexto: correlacione casos recorrentes. Se três incidentes por mês começam com a mesma combinação de sinais, essa é uma ótima primeira regra. A automação deve nascer de dor repetida, não de entusiasmo em reunião.

Sétimo: valide o resultado. Uma ação só é recuperação se o serviço voltou ao SLO. Reiniciar uma tarefa e fechar o ticket porque o alerta sumiu é como desligar o alarme de incêndio e declarar que a fumaça foi embora.



O que medir para saber se a inteligência existe

Não conte telas, licenças ou gráficos com inteligência artificial desenhada no canto. Meça resultado:

  • quantidade de alertas por incidente real;

  • redução de ruído;

  • MTTA, o tempo até reconhecer o incidente;

  • MTTR, o tempo até restaurar o serviço;

  • percentual de incidentes detectados antes do cliente;

  • taxa de sucesso e falha das automações;

  • reincidência dos principais problemas;

  • percentual de tickets enriquecidos automaticamente;

  • cobertura de serviços críticos com SLO e dependências mapeadas.

O indicador mais honesto é simples: o operador passa menos tempo caçando pistas e mais tempo prevenindo a próxima falha?



Epílogo — Não é Skynet; é uma usina bem operada

Mainframe Operations inteligente não é dar autonomia ilimitada a um modelo e esperar que ele descubra o significado de IEC161I enquanto a produção queima. É criar uma operação que coleta sinais, entende dependências, relaciona tecnologia com negócio, aplica procedimentos seguros e mantém pessoas experientes no circuito.

O futuro não é “menos humanos”. É menos trabalho mecânico, menos escalonamento cego, menos alertas inúteis e mais inteligência aplicada ao que realmente importa.

Quando o Agente J saiu da sala, perguntou se poderia usar o neuralyzer para apagar da memória dos operadores todos os alertas duplicados.

K balançou a cabeça.

— Não. Primeiro precisamos corrigir a regra que os gera.

E aquele, para quem já enfrentou uma madrugada de console cheio e café frio, foi o momento mais sensato de toda a operação.

Easter egg para quem viveu o mainframe: se um dashboard declarar tudo verde enquanto o usuário reclama que nada funciona, desconfie. Talvez não seja uma invasão alienígena. Talvez alguém esteja monitorando o recurso certo… para o serviço errado.

Alan Turing, John McCarthy e o Delorean da Inteligência Artificial

 

Bellacosa Mainframe em uma homenagem a Alan Turing John McCarthy e os primordios da IA

☕ Um Café no Bellacosa Mainframe

Alan Turing, John McCarthy e o Delorean da Inteligência Artificial

Ou: o professor Brown trouxe uma Máquina de Turing de 1936, John McCarthy apareceu com Lisp de 1958, Igor tentou instalar um LLM num cartão perfurado — e o programador COBOL descobriu que a pergunta “máquinas podem pensar?” é bem mais antiga que o ChatGPT, o Wi-Fi e aquele colega que diz que IA vai substituir todo mundo na segunda-feira

DOC BROWN — ALERTA TEMPORAL!
“Vagner, se você colocar 1,21 gigawatts nesta fita perfurada, podemos voltar a 1936!”

IGOR: “Excelente, doutor! E depois a gente pede para a máquina preencher a SYSOUT!”

DOC BROWN: “Não, Igor. Primeiro precisamos definir o que a máquina sabe. Depois vemos se ela sabe que não sabe.”

PROGRAMADOR COBOL: “Professor, isso dá um S0C7?”

DOC BROWN: “Pior. Dá um problema filosófico.”

Há uma confusão muito comum quando se fala de Inteligência Artificial: parece que ela nasceu quando alguém abriu um chat, escreveu “faça um resumo deste PDF” e recebeu uma resposta tão convincente que resolveu perguntar se a máquina tinha alma, CPF ou direito a férias.

Não nasceu.

A conversa atual sobre IA — modelos de linguagem, agentes, automação, chatbots, geração de imagens, assistentes de código e previsões sobre AGI — tem raízes em perguntas feitas décadas antes de alguém sonhar com um smartphone. Duas figuras ajudam a entender o tamanho da estrada: Alan Turing e John McCarthy.

Turing ajudou a responder uma pergunta fundamental: o que uma máquina pode calcular? McCarthy pegou a próxima: como fazemos uma máquina exibir inteligência?

Não são a mesma pergunta. Mas, sem a primeira, a segunda talvez nem tivesse uma sala, uma placa na porta e um orçamento de pesquisa.

Para quem está começando em COBOL, isso importa mais do que parece. Afinal, COBOL, mainframe, IA, regras de negócio, automação e segurança pertencem ao mesmo universo: o universo em que seres humanos tentam transformar decisões, processos e conhecimento em algo que uma máquina consiga executar sem entrar em ABEND — ou, no mínimo, sem gerar um incidente que faça o gerente aparecer com a expressão de quem acabou de ver o Great Scott do professor Brown.



1. Antes de a IA existir, Turing desenhou a sala de máquinas

Em 1936, Alan Turing publicou um trabalho que se tornou uma das fundações da ciência da computação. Nele, apresentou a ideia que hoje chamamos de Máquina de Turing.

Não era um notebook. Não era um mainframe. Não tinha monitor, teclado, mouse, GPU, RGB, copiloto nem assistente perguntando se você deseja salvar alterações. Era uma máquina abstrata, matemática, quase ascética: uma fita potencialmente infinita, uma cabeça que lê e escreve símbolos e um conjunto de regras que determina o próximo passo.

Parece simples porque é simples. E justamente por isso é genial.

Imagine uma fita enorme com células. Cada célula pode conter um símbolo. A máquina lê uma célula, verifica seu estado atual e segue uma instrução do tipo:

“Se eu estiver no estado A e ler 0, escreva 1, mova uma posição à direita e vá para o estado B.”

Essa descrição não parece tão distante de um programa. Em COBOL, você escreve algo como:

IF SALDO-DISPONIVEL >= VALOR-SOLICITADO
    MOVE "APROVADO" TO STATUS-OPERACAO
ELSE
    MOVE "NEGADO" TO STATUS-OPERACAO
END-IF.

A diferença é que COBOL é uma linguagem de alto nível, feita para seres humanos descreverem regras de negócio. A Máquina de Turing é uma espécie de esqueleto teórico: uma forma de demonstrar o que significa executar uma sequência de instruções.

O ponto não é que seu programa de folha de pagamento seja literalmente uma Máquina de Turing com fita de papel. O ponto é que existe uma base conceitual por baixo de todo programa: dados, estados, instruções, memória e transições.

Turing mostrou que uma máquina suficientemente geral poderia simular qualquer outra máquina de cálculo, desde que recebesse a descrição correta do procedimento. Nascia a ideia de máquina universal.

E aqui o professor Brown derruba uma caixa de cartões no chão:

“Marty! Não precisamos construir uma máquina nova para cada problema. Precisamos construir uma máquina geral e trocar o programa!”

Esse raciocínio é a alma do computador moderno. O mesmo computador pode rodar um sistema bancário, calcular a folha, tratar uma imagem médica, executar um jogo, fazer uma planilha ou treinar um modelo de IA. O hardware é uma plataforma; o programa define o comportamento.

Para o programador COBOL iniciante, esta é a primeira lição: não pense em programação apenas como escrever comandos. Pense em descrever um processo de maneira precisa o suficiente para uma máquina executá-lo.



2. “Máquinas podem pensar?” — a pergunta que ainda não fechou o chamado

Em 1950, Turing publicou o artigo Computing Machinery and Intelligence. Em vez de tentar resolver logo a palavra “pensar” — uma palavra perigosamente grande, que arrasta consciência, linguagem, criatividade, emoção, filosofia, religião e um boteco inteiro de discussões — ele propôs uma alternativa prática.

Em vez de perguntar:

“Uma máquina pensa?”

Turing sugeriu perguntar algo próximo de:

“Uma máquina consegue conversar de tal modo que um avaliador humano não consiga distingui-la de uma pessoa?”

Essa ideia ficou conhecida como Teste de Turing.

Na versão simplificada, um humano conversa por texto com dois participantes escondidos: uma pessoa e uma máquina. Se não conseguir identificar de modo confiável quem é quem, a máquina demonstrou um tipo importante de comportamento inteligente.

Agora vem a parte que Igor costuma estragar quando lê apenas a manchete:

Passar ou não passar no Teste de Turing não resolve definitivamente a questão da inteligência.

Um sistema pode escrever de forma fluida, imitar emoções, reproduzir estilos e manter uma conversa impressionante. Isso prova que ele se comporta, naquele contexto, de maneira parecida com um humano? Talvez. Prova que ele entende o mundo do mesmo modo que você entende? Não necessariamente.

Um papagaio pode repetir uma frase sem entender economia. Um sistema pode produzir um parágrafo excelente sobre Db2 e, duas linhas depois, inventar uma opção de JCL que nunca existiu com a confiança de um gerente apresentando slide em reunião de diretoria.

Os modelos atuais são fantásticos em linguagem. Eles resumem, traduzem, escrevem código, classificam informações, explicam conceitos e ajudam a explorar ideias. Mas fluência não é garantia de verdade; texto bonito não é auditoria; resposta segura não é evidência.

Este é um ensinamento valioso para quem trabalha com sistemas corporativos:

  • valide regras;

  • valide fontes;

  • mantenha trilha de auditoria;

  • não deixe um modelo decidir sozinho algo sensível sem controles;

  • trate a IA como um componente de software, não como um oráculo.

Em outras palavras: se uma IA disser que o lote terminou bem, ainda abra o SDSF.



3. Bletchley Park: inteligência não é só resolver charadas, é construir método

Durante a Segunda Guerra Mundial, Turing trabalhou em Bletchley Park, no esforço britânico de criptoanálise contra comunicações alemãs codificadas, incluindo mensagens protegidas pela Enigma. Ele não foi um “gênio solitário que venceu a guerra com uma máquina”, como alguns filmes e manchetes resumem. Fez parte de uma rede enorme de matemáticos, linguistas, operadores, engenheiros e criptanalistas.

Mas sua contribuição foi decisiva. O trabalho envolvia lógica, probabilidade, máquinas eletromecânicas, hipóteses, busca de padrões e disciplina operacional. Nada muito diferente, em espírito, do que hoje se chama de análise de dados, engenharia de sistemas e segurança cibernética.

Há uma ponte direta aqui para o analista de segurança e para o programador de sistemas críticos: inteligência útil não é adivinhação. É método para reduzir incerteza.

Quando você recebe um log, por exemplo, não basta olhar uma linha e concluir que houve ataque. Você precisa de contexto:

  • qual usuário executou a ação?

  • de onde veio a conexão?

  • qual era o horário esperado?

  • houve falhas de autenticação antes?

  • o volume de operações fugiu do padrão?

  • qual ativo foi acessado?

  • existe impacto real?

A máquina pode ajudar a encontrar padrões. O humano precisa formular hipóteses, validar evidências e tomar decisões responsáveis.

Turing também nos lembra de algo trágico: genialidade técnica não protege ninguém da crueldade social. Ele foi perseguido pelo Estado britânico por ser homossexual e morreu em 1954, aos 41 anos. Quando celebramos sua obra, não devemos transformar sua vida em uma curiosidade decorativa de biografia. Devemos lembrar que ciência, tecnologia e instituições são feitas por pessoas — e podem falhar moralmente mesmo quando avançam tecnicamente.

Uma IA poderosa construída por uma organização sem ética não vira sábia. Vira apenas uma máquina mais eficiente para escalar decisões ruins.


4. John McCarthy: o homem que deu nome ao monstro

Se Turing ajudou a estabelecer os fundamentos da computação e colocou a pergunta na mesa, John McCarthy ajudou a dar nome ao campo que tentaria respondê-la.

Em 1955, ao escrever a proposta para o Dartmouth Summer Research Project on Artificial Intelligence — realizado no verão de 1956 — McCarthy usou a expressão Artificial Intelligence. O termo pegou, embora “inteligência de máquina” talvez fosse menos carregado de ficção científica.

A proposta era ousada: reunir pesquisadores para investigar a hipótese de que aspectos da aprendizagem e da inteligência poderiam ser descritos com precisão suficiente para serem simulados por uma máquina.

Repare na ambição. Não era “vamos fazer uma calculadora mais rápida”. Era:

“Vamos entender partes da inteligência de forma suficientemente clara para construí-las.”

Isso inclui aprendizado, linguagem, abstração, raciocínio, percepção, planejamento e senso comum. Sessenta e tantos anos depois, boa parte dessas palavras continua na pauta. Algumas avançaram absurdamente; outras continuam com aquele status clássico de projeto: “dependência externa aguardando definição”.

McCarthy apostava muito em IA simbólica: usar fatos, regras e relações explícitas para o computador raciocinar. Algo parecido com:

SE cliente possui limite
E valor solicitado é menor que limite
E não há bloqueio de fraude
ENTÃO aprovar operação.

Para um programador COBOL, isso soa familiar. Sistemas empresariais vivem de regras: alçadas, cálculos, validações, exceções, status, processos de aprovação e rastreabilidade.

A diferença é que a IA simbólica queria ir além de um conjunto fixo de IFs. Ela queria representar conhecimento sobre o mundo e tirar conclusões novas a partir dele.

O sonho era elegante. O mundo, porém, é cheio de exceções.

Você pode escrever uma regra simples:

Pássaros voam.

Mas pinguins não voam. Aves feridas podem não voar. Um pássaro dentro de uma gaiola pode saber voar e não estar voando. E se Igor colocar um frango congelado na mesa e perguntar se ele é um pássaro, o sistema precisa de mais café e menos certeza.

Esse tipo de problema — lidar com conhecimento incompleto, exceções e contexto — foi um dos grandes desafios da IA clássica. McCarthy trabalhou com raciocínio não monotônico, isto é, formas de raciocínio em que uma conclusão pode precisar ser revista quando surge uma informação nova.

Parece abstrato, mas você faz isso todo dia.

“A transação parece legítima.”
“Espere: o IP é novo, o valor é atípico e houve quinze tentativas de senha.”
“Atualize a conclusão.”

Em segurança, em auditoria e em operações, mudar de opinião diante de evidências novas não é fraqueza. É inteligência.



5. Lisp: a linguagem que ensinou a IA a mexer em ideias

Em 1958, McCarthy criou Lisp, abreviação de List Processing. A linguagem ganhou forma pública em seu famoso artigo de 1960 e se tornou uma das linguagens mais influentes da história da IA.

Lisp tratava listas e expressões simbólicas como elementos naturais do programa. Isso era muito poderoso para manipular estruturas de conhecimento, árvores, regras, fórmulas e linguagem.

Um exemplo muito simplificado de Lisp pode parecer assim:

(if (fraude-suspeita transacao)
    (bloquear transacao)
    (aprovar transacao))

Não é COBOL, claro. Mas a intenção deve lhe soar familiar: testar uma condição e tomar um caminho.

A diferença cultural é interessante. COBOL foi desenhado para tornar regras de negócio legíveis e duráveis. Lisp nasceu em um ambiente que queria representar símbolos, relações e transformações conceituais. Um é o funcionário experiente que conhece todas as contas do fechamento mensal; o outro é o professor maluco do laboratório que pergunta se uma expressão pode modificar outra expressão e se isso nos aproxima da mente.

Os dois têm lugar no mundo.

Aliás, Lisp não está morto. Ideias que ele popularizou — funções como valores, recursão, coleta automática de memória, manipulação de listas e metaprogramação — influenciaram muitas linguagens posteriores. A história da computação é cheia de “tecnologias antigas” que, na verdade, eram ideias adiantadas demais para o hardware e o mercado de sua época.

Mainframe também conhece essa piada. Quando alguém diz que COBOL é velho, o programador experiente responde:

“Velho é o sistema que ainda movimenta dinheiro, processa seguro, paga salário e não cai quando o hype troca de nome.”



6. A aposta de 2039: previsão, palpite ou bilhete para o Delorean?

Em uma entrevista de 1989, McCarthy falou sobre o tempo necessário para programas se tornarem tão inteligentes quanto seres humanos. Ele reconheceu que poderia levar duzentos ou quinhentos anos, dependendo dos avanços conceituais necessários. Mas disse que se inclinaria a apostar em algo como cinquenta anos — acrescentando, com humor seco, que era extremamente improvável que estivesse vivo para ver.

1989 + 50 nos leva aproximadamente a 2039.

McCarthy morreu em 2011. Ele acertou, de forma triste e literal, que não viveria para testemunhar a resposta. Mas é importante não transformar isso em profecia com data marcada no calendário.

2039 não é uma garantia de “AGI em produção”. Não haverá necessariamente um painel no Data Center dizendo:

AGI-2039 — STATUS: DISPONÍVEL
PRESS <ENTER> PARA ATIVAR CONSCIÊNCIA

A própria expressão “inteligência humana” é difícil de medir. Um sistema pode ser melhor que uma pessoa em xadrez, tradução, cálculo, reconhecimento de imagens e geração de código, mas falhar em tarefas banais que exigem contexto, bom senso, memória confiável ou compreensão física do mundo.

Foi isso que aconteceu no xadrez. Em 1968, o mestre internacional escocês David Levy apostou que nenhum computador o venceria em dez anos. Em 1978, o programa CHESS 4.7 perdeu por 2 a 1 — uma derrota humana, mas uma aproximação notável.

Décadas depois, computadores venceriam campeões mundiais. Isso não significou que eles haviam resolvido a inteligência geral. Significou que resolveram — brilhantemente — um domínio formal, com regras claras e objetivo definido.

A lição é ouro:

Ser excelente em uma tarefa não torna automaticamente um sistema inteligente em tudo.

Um modelo que escreve COBOL pode ajudar muito. Ainda assim, ele pode não conhecer as regras específicas do seu banco, não saber que um campo contém informação sensível, não entender uma convenção interna, não ter acesso ao contexto de produção e não perceber que aquela “melhoria” quebra um processo regulatório.

Por isso, IA corporativa madura precisa de humano no circuito, testes, limites de acesso, logs, aprovação e recuperação.

Igor, naturalmente, acha que basta dar UPDATE na tabela de pagamentos e perguntar para o robô “faz um PIX aí”. Não seja Igor.



7. LLMs, IA simbólica e o grande encontro no bar

A IA que domina a conversa atual é fortemente baseada em aprendizado de máquina: grandes modelos neurais treinados com enormes volumes de texto, código, imagens e outros dados. Eles aprendem padrões estatísticos e conseguem gerar respostas surpreendentemente úteis.

Esse caminho é diferente da visão mais simbólica de McCarthy. Em vez de alguém escrever explicitamente todas as regras, o modelo aprende regularidades a partir de exemplos.

Há vantagens enormes:

  • adaptação a linguagem natural;

  • capacidade de lidar com variedade de textos;

  • geração de rascunhos e código;

  • sumarização;

  • classificação;

  • tradução;

  • apoio ao atendimento;

  • descoberta de padrões.

Mas há riscos igualmente reais:

  • alucinação: inventar fatos ou referências;

  • vieses presentes nos dados;

  • falta de explicabilidade;

  • vazamento de informações;

  • prompt injection;

  • automação de decisões sem revisão;

  • confiança excessiva do usuário.

A tendência mais interessante não é escolher uma religião — “só redes neurais” ou “só regras simbólicas”. É combinar abordagens.

Um sistema empresarial pode usar um LLM para entender a solicitação em português, uma base de conhecimento validada para buscar políticas corretas, regras explícitas para decisões obrigatórias e um humano para aprovar ações de alto impacto.

Pense assim:

Pessoa faz pergunta
        ↓
LLM entende a linguagem
        ↓
RAG busca documentos autorizados
        ↓
Regras de negócio validam condições
        ↓
Humano aprova decisão sensível
        ↓
Log registra tudo

Isso está muito mais perto de uma arquitetura responsável do que soltar um modelo numa rede corporativa e torcer para ele ter juízo.

Máquinas não têm juízo moral por padrão. Elas têm permissões, dados, instruções, limitações e consequências.



8. Um roteiro para o programador COBOL entrar na conversa da IA sem virar passageiro do tempo

Você não precisa abandonar COBOL, virar cientista de dados em uma semana ou comprar uma camiseta escrito “AGI IS COMING” para participar desse futuro.

Comece de modo prático.

Passo 1 — Entenda o processo antes de automatizá-lo

Escolha uma rotina de negócio conhecida: validação de cadastro, classificação de chamados, triagem de documentos, explicação de mensagens de erro ou consulta de procedimento.

Pergunte:

  • qual é a entrada?

  • qual é a saída?

  • quais regras são obrigatórias?

  • quais exceções existem?

  • que dados são sensíveis?

  • quem é responsável pela decisão?

  • como registrar auditoria?

Se você não consegue explicar o processo, não está pronto para entregar o processo a uma IA.

Passo 2 — Separe linguagem de decisão

Um LLM pode ser ótimo para receber uma pergunta como:

“Por que meu pagamento foi bloqueado?”

Mas a decisão real de bloqueio deve continuar apoiada por regras, dados transacionais e controles.

A IA pode traduzir o tecnês. O motor de regras decide. O analista responde pelo caso. Essa separação evita que um texto bonito vire uma decisão perigosa.

Passo 3 — Use a IA como par de programação, não como piloto automático

Peça para ela:

  • explicar um programa COBOL;

  • sugerir casos de teste;

  • comentar uma PROCEDURE DIVISION;

  • gerar documentação inicial;

  • converter uma regra de negócio em pseudocódigo;

  • ajudar a encontrar campos usados em uma rotina;

  • produzir uma primeira versão de teste unitário.

Mas revise tudo. Principalmente nomes de campos, arquivos VSAM, commits, SQL, regras de arredondamento, formatos de data e operações financeiras.

A IA pode ser um ótimo estagiário que trabalha rápido. Você continua sendo o responsável pela mudança em produção.

Passo 4 — Segurança não é rodapé

Nunca envie código proprietário, dados de clientes, credenciais, dumps, arquivos de produção ou detalhes operacionais para ferramentas públicas sem autorização.

Pergunte sempre:

  • onde o dado será processado?

  • ele será retido?

  • quem pode acessá-lo?

  • há contrato e política corporativa?

  • o conteúdo pode virar treinamento?

  • existe mascaramento?

  • há trilhas de auditoria?

Turing trabalhou com segredo criptográfico. McCarthy pensava em representação de conhecimento. Em 2026, os dois provavelmente olhariam para um CSV de clientes colado num chatbot público e pediriam para desligar o Delorean.


Epílogo — A pergunta ainda está na fita

Alan Turing nos deu a linguagem conceitual para pensar máquinas que executam procedimentos gerais. Ele nos deixou uma pergunta que resiste a cada nova geração tecnológica: “máquinas podem pensar?”

John McCarthy pegou essa inquietação e deu a ela um nome, um campo de pesquisa, uma agenda e ferramentas para tentar respondê-la. Criou Lisp, ajudou a moldar a IA simbólica e, em 1989, arriscou um palpite que nos aponta para 2039 — não como destino garantido, mas como um marcador fascinante no mapa.

Hoje, temos sistemas capazes de conversar, programar, traduzir, enxergar, resumir e sugerir. Alguns parecem mágicos até o momento em que erram algo óbvio. Isso não diminui sua importância; apenas nos obriga a sair do hype e entrar na engenharia.

Talvez a pergunta não seja mais apenas “a máquina pensa?”.

Talvez seja:

“Ela entende? Ela pode agir? Ela pode errar? Quem confere? Quem responde pelo dano? E por que Igor recebeu acesso de administrador?”

O programador COBOL tem uma vantagem preciosa nesta era. Já conhece sistemas longos, críticos, regulados, cheios de exceções e onde um pequeno erro pode fazer uma conta muito grande deixar de fechar. Esse olhar vale ouro quando a IA sai do laboratório e entra no banco, no governo, na saúde, na segurança e no mainframe.

No fim, Turing construiu a estrada. McCarthy colocou a placa: Inteligência Artificial. E nós, passageiros do Delorean de 2026, estamos dirigindo rumo a 2039 com uma mão no volante, outra no manual de segurança e o professor Brown gritando do banco de trás:

“Para onde vamos, não precisamos de estradas… mas vamos precisar de logs, testes, backup e um plano de rollback!”



 

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