☕ 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

sexta-feira, 2 de outubro de 2026

Inteligência Artificial e Engenharia de Prompts: o novo superpoder do programador COBOL no Mainframe

 

Bellacosa Mainframe e a inteligencia artificial no mundo cobol

Inteligência Artificial e Engenharia de Prompts: o novo superpoder do programador COBOL no Mainframe

Como utilizar IA para compreender sistemas legados, desenvolver programas COBOL, corrigir erros, otimizar aplicações e modernizar o ambiente IBM Z sem perder o controle sobre a tecnologia.

Por Vagner Bellacosa — Bellacosa Mainframe



1. Introdução — Quando a Inteligência Artificial encontra o COBOL

Imagine a seguinte situação.

Você é um programador COBOL trabalhando em uma instituição financeira. Numa bela segunda-feira, recebe uma solicitação aparentemente simples: modificar o cálculo de juros de um sistema bancário.

Até aqui, nenhuma novidade!

O problema começa quando você descobre que a aplicação foi desenvolvida há 35 anos, possui milhares de linhas de código, utiliza diversos COPYBOOKs, acessa tabelas Db2, processa arquivos VSAM e executa rotinas tanto em ambiente batch quanto em transações CICS.

Para completar, o programador original já se aposentou, a documentação está desatualizada e ninguém sabe explicar exatamente por que determinado parágrafo executa uma operação aparentemente desnecessária.

Bem-vindo ao maravilhoso universo dos sistemas legados!

Quem trabalha com mainframe conhece essa história. Muitas vezes, a dificuldade não está em escrever novas instruções COBOL, mas em compreender decisões arquitetônicas tomadas décadas atrás.

É justamente nesse cenário que a Inteligência Artificial começa a demonstrar seu verdadeiro potencial.

A grande revolução da IA no mainframe não consiste em substituir o COBOL, mas em ampliar a capacidade dos profissionais que trabalham com ele.

Ferramentas baseadas em modelos de linguagem podem auxiliar na compreensão de programas, geração de código, análise de dependências, elaboração de testes, documentação e investigação de erros.

Entretanto, existe um detalhe fundamental: uma IA não conhece automaticamente as particularidades de sua instalação z/OS, as regras comerciais de sua empresa ou os compromissos de compatibilidade assumidos por aplicações que funcionam há décadas.

Para obter resultados úteis, precisamos aprender a conversar tecnicamente com essas ferramentas.

E isso nos leva à engenharia de prompts.



2. O que é um prompt e por que ele importa para um programador COBOL?

Um prompt é uma instrução fornecida a um modelo de Inteligência Artificial para orientar sua resposta.

Podemos compará-lo a uma especificação funcional.

Quando um analista solicita a criação de um programa COBOL, precisa informar quais dados serão recebidos, quais operações devem ocorrer, quais resultados são esperados e como tratar situações excepcionais.

Com a IA ocorre algo semelhante.

Considere este pedido:

Escreva um programa COBOL para calcular juros.

O modelo provavelmente conseguirá produzir algum código. Entretanto, não saberá se estamos utilizando COBOL fixed-format, free-format, processamento batch, CICS ou uma versão específica do Enterprise COBOL.

Também não conhecerá a escala decimal exigida pela aplicação.

Agora compare com um prompt profissional:

Atue como programador sênior IBM Enterprise COBOL em ambiente z/OS. Desenvolva um programa batch, em formato fixo, para calcular juros simples utilizando campos COMP-3. Utilize precisão decimal, valide os dados de entrada, trate situações de overflow e apresente exemplos de execução. Explique cada divisão do programa e identifique pontos que exigem validação funcional.

A diferença é enorme.

O segundo pedido fornece contexto técnico e estabelece critérios de qualidade.

Os seis elementos de um bom prompt mainframe

1. Papel: determine qual especialidade a IA deve assumir.

Exemplo: analista COBOL, especialista Db2, operador z/OS ou engenheiro DevOps.

2. Ambiente: especifique a plataforma.

Exemplo: IBM z/OS, Enterprise COBOL 6.x, CICS, Db2, VSAM e JCL.

3. Objetivo: explique o problema que deseja resolver.

4. Restrições: informe formatos, regras de negócio, limites, convenções e aspectos de segurança.

5. Resultado esperado: solicite código, documentação, casos de teste ou análise técnica.

6. Validação: exija que a IA identifique suas hipóteses e explique como verificar o resultado.

Uma dica importante: peça sempre que o modelo diferencie informações comprovadas de suposições.

Isso reduz o risco de aceitar explicações tecnicamente convincentes, mas incorretas.



3. A IA como arqueóloga de sistemas legados

Existe uma atividade que todo programador mainframe conhece: a arqueologia de software.

Imagine abrir um programa COBOL desenvolvido em 1987.

Encontramos parágrafos como:

  • 1000-INICIALIZA

  • 2000-LE-ARQUIVO

  • 3000-PROCESSA

  • 4000-ATUALIZA

  • 9000-FINALIZA

Até aqui, tudo parece organizado.

Entretanto, quando investigamos a PROCEDURE DIVISION, encontramos centenas de PERFORMs, variáveis globais, regras comerciais espalhadas e chamadas a subprogramas cuja finalidade não está documentada.

A IA pode auxiliar nessa investigação.

Exemplo de prompt para compreender um programa antigo

Analise o programa COBOL fornecido. Identifique sua finalidade, entradas, saídas, arquivos utilizados, COPYBOOKs, chamadas externas, regras comerciais e tratamento de erros. Explique o fluxo de execução e identifique possíveis dependências. Não invente o conteúdo de módulos que não foram fornecidos.

O resultado pode servir como ponto de partida para construir documentação técnica.

Mas atenção!

A IA somente consegue analisar as dependências às quais teve acesso.

Se determinada rotina utiliza um COPYBOOK não fornecido, ela não poderá garantir a interpretação correta dos campos.

O mesmo vale para programas chamados dinamicamente, definições CICS, procedimentos JCL e estruturas de tabelas Db2.

Curiosidade histórica

O COBOL foi concebido no final da década de 1950, e sua primeira especificação surgiu em 1960.

Uma das ideias fundamentais era criar uma linguagem relativamente próxima da linguagem utilizada em atividades comerciais.

Décadas depois, modelos de IA conseguem interpretar muitos desses comandos quase como descrições de regras empresariais.

Há algo fascinante nisso!

Uma linguagem criada para facilitar a compreensão humana dos sistemas comerciais agora também permite que modelos de linguagem auxiliem na recuperação de conhecimento institucional.

É como se programas escritos há várias décadas recebessem uma nova oportunidade de explicar suas próprias histórias.



4. Laboratório prático — Desenvolvendo um programa COBOL com auxílio da IA

Vamos construir um exemplo simples.

Nosso objetivo será calcular juros simples sobre um capital de R$ 10.000,00, considerando uma taxa mensal de 1,5% durante 12 meses.

A fórmula é:

Juros = Capital × Taxa × Tempo

Portanto:

10.000 × 0,015 × 12 = 1.800

O resultado esperado é R$ 1.800,00.

Passo 1 — Descrever o problema para a IA

Informe o ambiente de execução, o formato do código, os tipos de dados e a fórmula.

Para este laboratório, utilizaremos campos numéricos decimais com representação COMP-3.

Passo 2 — Gerar o código

       IDENTIFICATION DIVISION.
       PROGRAM-ID. CALCJURO.

       DATA DIVISION.
       WORKING-STORAGE SECTION.

       01 WS-CAPITAL       PIC S9(11)V99 COMP-3
                           VALUE 10000.

       01 WS-TAXA          PIC 9V9(6) COMP-3
                           VALUE 0.015.

       01 WS-MESES         PIC 9(4) COMP
                           VALUE 12.

       01 WS-JUROS         PIC S9(11)V99 COMP-3.

       01 WS-INTERMED      PIC S9(15)V9(8) COMP-3.

       01 WS-JUROS-EDIT    PIC Z(11)9.99.

       PROCEDURE DIVISION.

           IF WS-CAPITAL < ZERO
              OR WS-TAXA > 1
              OR WS-MESES = ZERO
               DISPLAY "PARAMETROS INVALIDOS"
               MOVE 12 TO RETURN-CODE
               GOBACK
           END-IF

           COMPUTE WS-INTERMED =
               WS-CAPITAL * WS-TAXA * WS-MESES

           COMPUTE WS-JUROS ROUNDED =
               WS-INTERMED
               ON SIZE ERROR
                   DISPLAY "ERRO NO CALCULO"
                   MOVE 12 TO RETURN-CODE
                   GOBACK
           END-COMPUTE

           MOVE WS-JUROS TO WS-JUROS-EDIT

           DISPLAY "JUROS: " WS-JUROS-EDIT

           MOVE ZERO TO RETURN-CODE

           GOBACK.

O programa é didático, utiliza valores definidos internamente e precisa ser compilado e testado no ambiente de destino.

Passo 3 — Compreender os campos

O campo WS-CAPITAL utiliza:

PIC S9(11)V99 COMP-3

Isso representa um número decimal assinado, com onze posições inteiras e duas casas decimais, armazenado em formato decimal compactado.

O V representa uma posição decimal implícita.

Ele não ocupa uma posição física contendo um ponto decimal.

Já COMP-3 é particularmente importante em aplicações financeiras por representar valores decimais sem depender de aproximações de ponto flutuante binário.

O campo WS-INTERMED possui mais posições decimais para preservar resultados intermediários.

Entretanto, seu dimensionamento deve ser conferido conforme os limites reais de capital, taxa e prazo.

Passo 4 — Examinar o arredondamento

A instrução:

           COMPUTE WS-JUROS ROUNDED =
               WS-INTERMED

Solicita o arredondamento do resultado para a escala definida pelo campo de destino.

Isso merece atenção especial.

Em aplicações financeiras, diferenças mínimas podem causar divergências significativas quando milhões de registros são processados.

A IA pode explicar o comportamento esperado, mas o desenvolvedor precisa confirmar a regra de arredondamento exigida pelo negócio.

Passo 5 — Validar o resultado

O valor calculado deve ser:

JUROS: 1800.00

A formatação exata dependerá da máscara de edição e das convenções utilizadas.

O objetivo não é simplesmente executar o programa.

É verificar se o resultado corresponde à regra funcional.



5. IA e JCL — Automatizando a preparação de testes

Quem desenvolve COBOL em mainframe sabe que escrever o código não é suficiente.

Precisamos compilar, executar e analisar os resultados.

Em ambiente batch, isso normalmente envolve JCL.

A IA pode auxiliar na criação de modelos de JOBs, parametrização de datasets e interpretação de mensagens.

Considere um JCL didático para executar um programa já compilado e disponível numa biblioteca de carga.

//BCJURO   JOB (ACCT),'TESTE IA',
//             CLASS=A,MSGCLASS=X,
//             NOTIFY=&SYSUID
//STEP01   EXEC PGM=CALCJURO
//STEPLIB  DD DISP=SHR,
//             DSN=USR.COBOL.LOAD
//SYSPRINT DD SYSOUT=*
//SYSOUT   DD SYSOUT=*

As classes, a informação contábil e os nomes dos datasets precisam ser adaptados às normas da instalação.

Esse JOB não executa a compilação: ele pressupõe que o módulo CALCJURO já esteja disponível na biblioteca indicada.

Um prompt útil seria:

Analise este JCL para execução de um programa COBOL batch. Explique cada instrução, identifique dependências de configuração da instalação e sugira verificações para diagnosticar erros de execução. Não presuma que os nomes de datasets ou classes sejam válidos no meu ambiente.

Dica profissional

Solicite que a IA explique separadamente:

  • Erros de sintaxe JCL.

  • Falhas de alocação de datasets.

  • Problemas de autorização.

  • Return codes do programa.

  • ABENDs durante a execução.

Essa separação evita confundir problemas do sistema operacional com erros da lógica COBOL.


6. IA como assistente de depuração — Investigando ABENDs

Imagine que um programa encerrou com ABEND S0C7.

Esse código está frequentemente associado a uma exceção de dados decimais.

Uma situação clássica ocorre quando operações numéricas encontram conteúdo incompatível com a representação esperada.

A IA pode ajudar a organizar a investigação.

Exemplo de prompt

Estou investigando um ABEND S0C7 numa aplicação Enterprise COBOL em z/OS. Analise as mensagens disponíveis, o trecho do programa e os layouts de dados. Identifique possíveis causas relacionadas a dados numéricos inválidos, conversões, campos COMP-3 e movimentações entre áreas. Explique como confirmar cada hipótese utilizando informações do dump e do programa compilado.

O importante é fornecer evidências.

Sem o dump, a identificação da instrução envolvida e as estruturas de dados, a IA poderá oferecer hipóteses, mas dificilmente confirmar a causa exata.

Curiosidade — O perigo dos dados históricos

Sistemas antigos podem conter registros criados por diferentes versões de programas.

Um campo que hoje deveria armazenar números válidos pode ter recebido dados irregulares no passado.

Alterações de layout, validações insuficientes ou conversões inadequadas podem transformar esses registros em armadilhas para versões modernas.

Por isso, modernizar código não significa necessariamente modernizar os dados existentes.

Em muitos projetos, a qualidade histórica da informação representa um desafio tão grande quanto a manutenção do software.


7. IA, COBOL e Db2 — Investigando desempenho SQL

Outro campo promissor é a análise de SQL embutido em programas COBOL.

Considere:

           EXEC SQL
               SELECT SALDO
                 INTO :WS-SALDO
                 FROM CONTAS
                WHERE NUM_CONTA = :WS-CONTA
           END-EXEC

Uma IA pode explicar a consulta e identificar aspectos que merecem atenção:

A coluna NUM_CONTA possui índice adequado?

A consulta pode retornar mais de uma linha?

Como são tratados os SQLCODEs?

O programa considera valores nulos?

Existe concorrência entre atualizações?

O acesso ocorre dentro de um loop executado milhões de vezes?

Essa última pergunta é particularmente importante.

Imagine uma rotina que executa individualmente uma consulta SQL para cada um dos dez milhões de registros de um arquivo.

Mesmo que cada consulta seja rápida, a quantidade de operações poderá produzir um custo significativo.

A IA pode sugerir alternativas, como técnicas de processamento em conjuntos ou revisão da estratégia de acesso.

Entretanto, não devemos alterar SQL de produção sem examinar access paths, índices, estatísticas, concorrência e semântica transacional.

Uma modificação aparentemente simples pode aumentar o locking, alterar a consistência dos resultados ou comprometer o tempo disponível para processamento batch.


8. O grande desafio — Como impedir que a IA invente soluções?

Os modelos de linguagem possuem uma característica perigosa: podem produzir respostas incorretas com aparência de grande segurança técnica.

Esse fenômeno costuma ser chamado de alucinação.

Num ambiente mainframe, isso pode aparecer de várias maneiras.

A IA pode inventar uma opção de compilação, utilizar uma sintaxe COBOL incompatível com a versão instalada, sugerir um parâmetro JCL inexistente ou interpretar incorretamente uma mensagem do sistema.

O perigo é maior quando o desenvolvedor não possui conhecimento suficiente para reconhecer o erro.

Por isso, recomendo uma regra simples:

Nunca permita que a IA seja simultaneamente autora e única responsável pela validação de uma alteração.

O código precisa passar por ferramentas independentes.

A validação deve envolver o compilador, testes automatizados, comparação de resultados, revisão humana e, quando necessário, análise de desempenho.

Técnica dos três prompts

Uma metodologia interessante consiste em separar o trabalho em três interações.

Primeiro prompt — Desenvolvimento

Solicite a implementação da funcionalidade.

Segundo prompt — Revisão crítica

Peça uma análise independente do código, procurando problemas de overflow, precisão, compatibilidade e comportamento excepcional.

Terceiro prompt — Testes

Solicite uma matriz de testes com entradas, saídas esperadas e casos-limite.

Essa abordagem não garante correção, mas ajuda a explorar diferentes perspectivas.

O resultado final precisa continuar sendo confrontado com a execução real.


9. Ferramentas modernas — O mainframe também participa da revolução da IA

Durante muitos anos, o desenvolvimento mainframe ficou associado quase exclusivamente a terminais 3270.

Essas interfaces continuam extremamente úteis.

Entretanto, o ecossistema IBM Z também conta com ferramentas modernas de desenvolvimento.

IBM watsonx Code Assistant for Z

O watsonx Code Assistant for Z integra recursos de Inteligência Artificial voltados à compreensão, geração, explicação e modernização de aplicações mainframe.

Dependendo da versão e dos recursos disponíveis, pode auxiliar em atividades de análise e transformação de código.

O ponto mais interessante é que a IA pode participar da evolução de aplicações COBOL sem exigir que todo o sistema seja imediatamente reescrito em outra linguagem.

IBM Z Open Editor

Permite desenvolver programas COBOL e outros artefatos mainframe usando Visual Studio Code.

Oferece recursos como realce de sintaxe, navegação e suporte a estruturas comuns do ambiente.

O editor não deve ser confundido com um modelo de IA: ele fornece parte da infraestrutura na qual diferentes ferramentas podem trabalhar.

Zowe Explorer

Permite acessar recursos do z/OS por meio do VS Code, conforme os serviços disponíveis e as autorizações concedidas.

O desenvolvedor pode navegar por datasets, trabalhar com arquivos USS, submeter jobs e consultar resultados.

IBM Dependency Based Build

O IBM DBB auxilia na automação de processos de build e no tratamento das dependências entre componentes de aplicações mainframe.

Em conjunto com Git, pipelines e ferramentas de integração contínua, pode ajudar a aproximar o desenvolvimento COBOL das práticas modernas de DevOps.

Uma arquitetura interessante

Imagine o seguinte fluxo:

  1. O desenvolvedor recebe uma alteração funcional.

  2. Utiliza a IA para compreender o código existente.

  3. Solicita uma proposta de modificação.

  4. Revisa os campos, as regras e as dependências.

  5. Edita o programa no VS Code.

  6. Executa o processo de build no ambiente autorizado.

  7. Analisa os erros encontrados.

  8. Utiliza a IA para ajudar na investigação.

  9. Executa testes automatizados.

  10. Submete a alteração à revisão e aprovação.

Observe que a IA participa de diversas etapas, mas não substitui os mecanismos de engenharia necessários.


10. Engenharia de prompts aplicada ao trabalho diário

A melhor maneira de utilizar IA não é criar um prompt isolado para cada problema.

É construir uma biblioteca de prompts reutilizáveis.

Eu organizaria essa biblioteca em cinco categorias.

Prompt 1 — Compreensão de código

Atue como especialista COBOL. Explique a finalidade do programa fornecido, suas entradas, saídas, estruturas de dados, regras comerciais e dependências. Identifique informações não disponíveis e não invente componentes externos.

Prompt 2 — Diagnóstico de falhas

Analise as mensagens de erro de uma aplicação COBOL em z/OS. Classifique possíveis causas, relacione evidências disponíveis e apresente um procedimento de diagnóstico seguro em ambiente de testes.

Prompt 3 — Revisão de código

Revise o código COBOL apresentado. Procure problemas de precisão decimal, tratamento de erros, compatibilidade, inicialização de variáveis, desempenho e legibilidade. Explique os riscos antes de sugerir alterações.

Prompt 4 — Geração de testes

Elabore uma matriz de testes para esta rotina COBOL. Inclua situações normais, valores-limite, entradas inválidas, overflow, arredondamento e comportamentos excepcionais. Apresente os resultados esperados e as regras utilizadas para calculá-los.

Prompt 5 — Análise de impacto

Analise a alteração proposta considerando COPYBOOKs, programas chamados, layouts de arquivos, acessos Db2, definições CICS e JCL. Identifique dependências comprovadas, riscos potenciais e pontos que precisam ser investigados antes da implantação.

Esses prompts podem ser adaptados para diferentes projetos e armazenados em um repositório interno.

A vantagem está na padronização da qualidade das solicitações.


11. Um laboratório de cinco dias para aprender IA aplicada ao COBOL

Para um programador iniciante, proponho uma experiência prática organizada em cinco dias.

Dia 1 — Aprendendo a ler COBOL com IA

Escolha um programa pequeno.

Solicite que a IA explique a IDENTIFICATION DIVISION, DATA DIVISION, WORKING-STORAGE SECTION e PROCEDURE DIVISION.

Depois, confira manualmente cada explicação.

Objetivo: aprender a utilizar a IA como instrumento de estudo, não como fonte infalível.

Dia 2 — Criando uma rotina financeira

Desenvolva o programa de juros apresentado anteriormente.

Solicite a geração do código, revise os campos PIC e verifique os resultados.

Modifique a taxa, o capital e o prazo.

Objetivo: compreender como pequenas alterações nos dados influenciam os cálculos.

Dia 3 — Executando com JCL

Prepare um JOB para executar o programa compilado.

Submeta a execução em ambiente autorizado.

Consulte as mensagens produzidas e peça à IA que explique os resultados.

Objetivo: relacionar a lógica COBOL ao funcionamento do sistema operacional.

Dia 4 — Testando situações excepcionais

Crie casos de teste com valores extremos, taxa inválida e prazos inadequados.

Solicite que a IA identifique situações de risco.

Verifique se os resultados correspondem às regras estabelecidas.

Objetivo: desenvolver disciplina de testes.

Dia 5 — Documentando e evoluindo

Modifique a rotina para receber dados de entrada por meio de um arquivo ou uma estrutura parametrizada.

Solicite à IA documentação funcional e técnica.

Compare a versão original com a modificada.

Objetivo: compreender o ciclo completo de manutenção de uma aplicação.

Ao final, o aluno terá aprendido não apenas a escrever prompts, mas a investigar, implementar, testar e documentar soluções.


12. Segurança — Não entregue as chaves do mainframe para a IA

Este talvez seja o aspecto mais importante em ambientes corporativos.

Uma aplicação COBOL pode processar dados bancários, informações pessoais, registros comerciais, operações governamentais ou outros conteúdos sensíveis.

Copiar indiscriminadamente fontes, dumps e arquivos para serviços externos de IA pode criar riscos de confidencialidade e conformidade.

Antes de utilizar uma ferramenta, verifique as políticas de sua organização.

Sempre que necessário, utilize exemplos sintéticos ou informações previamente autorizadas.

Jamais inclua senhas, credenciais RACF, chaves criptográficas, tokens ou dados pessoais reais em prompts destinados a ferramentas não aprovadas.

Além disso, a IA deve operar com permissões compatíveis com a função do profissional.

Ter capacidade de sugerir uma alteração não significa possuir autorização para executá-la.

Uma boa arquitetura de IA corporativa precisa respeitar os mesmos controles de segurança e segregação de responsabilidades aplicados aos demais sistemas.


13. Curiosidades — O encontro entre uma linguagem de 1959 e a tecnologia do futuro

Existe certa ironia histórica nessa revolução.

O COBOL nasceu numa época em que computadores ocupavam salas inteiras e o armazenamento era medido em unidades que hoje parecem insignificantes.

A linguagem foi projetada para aplicações comerciais e para facilitar a descrição de procedimentos empresariais.

Décadas depois, continuamos utilizando COBOL em sistemas críticos.

Enquanto isso, a IA generativa ganhou destaque justamente pela capacidade de interpretar e produzir linguagem natural e código.

Agora imagine combinar esses dois mundos.

Um programa escrito em COBOL nos anos 1970 pode ser examinado por uma ferramenta de IA desenvolvida no século XXI.

O modelo pode auxiliar um profissional a compreender sua estrutura, explicar seus cálculos e levantar possíveis regras comerciais.

Mas há uma diferença fundamental entre compreender a sintaxe e conhecer a história de um sistema.

Um trecho aparentemente redundante pode existir porque, em determinado momento, uma legislação exigiu uma exceção.

Uma rotina incomum pode representar a solução para um problema ocorrido décadas atrás.

Um campo que ninguém utiliza diretamente pode fazer parte de uma interface compartilhada com outro programa.

Eliminar esses elementos sem investigar suas origens pode provocar consequências graves.

Easter egg — O fantasma do parágrafo 9999

Imagine encontrar o seguinte código:

       9999-ROTINA-ESPECIAL.
           IF WS-ANO = 1999
               PERFORM 9998-AJUSTE-ANTIGO
           END-IF.

O programador iniciante pergunta:

“Por que existe uma rotina para o ano de 1999 num sistema que estamos executando em 2026?”

A IA pode sugerir que se trata de código obsoleto.

Entretanto, será que esse campo representa realmente o ano corrente?

Será que a rotina ainda participa do reprocessamento de arquivos históricos?

Será que existe uma exigência de auditoria para reproduzir cálculos antigos?

Sem essas respostas, remover o parágrafo seria uma decisão precipitada.

Moral da história: no mainframe, até os fantasmas do passado podem possuir contratos de manutenção ativos!

Eis uma excelente lição para qualquer profissional que deseja utilizar IA na modernização de sistemas legados.


14. O futuro — Um assistente especializado em cada aplicação

Vamos imaginar um cenário mais avançado.

Uma organização possui centenas de aplicações COBOL, milhares de programas, COPYBOOKs, JCLs e documentos acumulados durante décadas.

Grande parte desse conhecimento está distribuída entre repositórios, bibliotecas, documentos e profissionais experientes.

Seria possível construir um assistente de IA especializado nesse ambiente?

Sim, desde que a arquitetura forneça acesso controlado às fontes de informação relevantes.

Uma abordagem é utilizar Retrieval-Augmented Generation, conhecida como RAG.

Em vez de depender exclusivamente do conhecimento geral do modelo, o sistema recupera informações de repositórios internos autorizados e utiliza esses documentos como contexto para responder.

Imagine perguntar:

Quais programas utilizam o COPYBOOK CLIENTE01 e quais interfaces poderão ser afetadas se alterarmos o tamanho do campo COD-CLIENTE?

Um assistente conectado a índices confiáveis, metadados e ferramentas de análise de dependências poderia ajudar a localizar componentes relacionados.

Entretanto, a resposta precisaria distinguir referências encontradas de dependências ainda não investigadas, como chamadas dinâmicas.

Outro exemplo:

Explique por que o programa FATB120 apresenta aumento de tempo de execução no fechamento mensal.

Para responder adequadamente, o assistente precisaria consultar métricas reais, históricos de execução, informações de SQL e registros operacionais.

Somente o código-fonte não seria suficiente.

É aqui que aparece uma oportunidade extraordinária: integrar o conhecimento tradicional dos especialistas mainframe com mecanismos modernos de recuperação, análise e Inteligência Artificial.


15. O programador COBOL será substituído?

Essa pergunta aparece frequentemente quando discutimos Inteligência Artificial.

Minha avaliação é que parte das atividades repetitivas de programação poderá ser automatizada, especialmente tarefas de documentação, geração de estruturas simples e preparação inicial de testes.

Entretanto, sistemas corporativos complexos exigem muito mais do que a capacidade de produzir instruções sintaticamente corretas.

É necessário compreender as regras do negócio, a arquitetura das aplicações, as dependências técnicas, as exigências de segurança e as consequências operacionais.

Um bom programador COBOL conhece aspectos que podem estar ausentes de qualquer documentação.

Ele sabe, por exemplo, que determinado processamento precisa terminar antes da abertura do expediente bancário.

Compreende que alterar a ordem de atualização de duas tabelas pode provocar inconsistências.

Reconhece que determinado COPYBOOK é compartilhado por diversos programas e que modificar um campo aparentemente simples pode exigir recompilações e testes extensivos.

A IA pode ajudar a localizar e organizar essas informações.

Mas não elimina a necessidade de profissionais capazes de interpretá-las e tomar decisões responsáveis.

Na realidade, vejo surgir um novo perfil profissional: o desenvolvedor COBOL capaz de combinar fundamentos sólidos de mainframe, ferramentas modernas e engenharia de prompts.

Esse profissional poderá trabalhar com maior produtividade e assumir desafios de análise e modernização que anteriormente exigiam enormes esforços manuais.


16. Dez mandamentos do programador COBOL que utiliza IA

  1. Conheça sua plataforma. Informe sempre o ambiente z/OS, a versão do compilador e as tecnologias envolvidas.

  2. Especifique antes de gerar. Um prompt bem elaborado começa com requisitos claros.

  3. Preserve a precisão decimal. Em aplicações financeiras, cada centavo precisa ser tratado corretamente.

  4. Respeite os sistemas legados. Código antigo não significa necessariamente código inútil.

  5. Nunca confie cegamente na IA. Verifique a sintaxe, as hipóteses e as regras funcionais.

  6. Compile e execute. Uma resposta convincente não substitui a validação real.

  7. Crie testes de regressão. Toda alteração precisa demonstrar que não comprometeu comportamentos existentes.

  8. Proteja as informações. Utilize somente ferramentas e dados autorizados pela organização.

  9. Documente suas descobertas. Transforme conhecimento individual em patrimônio técnico compartilhado.

  10. Continue estudando COBOL. Quanto mais você compreender a linguagem e o ambiente, melhores serão suas perguntas e decisões.


17. Conclusão — O Mainframe não ficou no passado. Ele trouxe o passado para o futuro!

Durante décadas, muita gente anunciou o desaparecimento do mainframe.

Depois vieram a arquitetura cliente-servidor, a internet, os sistemas distribuídos, a virtualização e a computação em nuvem.

Agora chegou a Inteligência Artificial.

E o mainframe continua participando da evolução tecnológica.

A diferença é que a IA oferece uma oportunidade especialmente interessante: tornar mais acessível o conhecimento acumulado em sistemas que evoluíram durante várias gerações de profissionais.

Podemos utilizar prompts para compreender programas antigos, desenvolver novas funcionalidades, analisar problemas, criar testes e documentar aplicações.

Podemos combinar ferramentas modernas com COBOL, JCL, CICS, Db2 e VSAM.

Podemos aproximar novos desenvolvedores de tecnologias consideradas difíceis e contribuir para preservar o conhecimento de especialistas experientes.

Mas o princípio fundamental permanece inalterado:

A Inteligência Artificial deve ampliar a competência do programador, nunca substituir seu senso crítico.

O futuro não pertence apenas a quem conhece COBOL.

Também não pertence exclusivamente a quem sabe escrever prompts.

Ele será construído por profissionais capazes de compreender profundamente os sistemas, utilizar novas ferramentas e validar cuidadosamente os resultados.

E, para quem deseja se tornar um verdadeiro Mestre Jedi do Mainframe, talvez essa seja uma das habilidades mais importantes dos próximos anos.

Afinal, como diríamos no universo Bellacosa Mainframe:

Que a força do COBOL esteja com você — e que sua IA nunca faça um COMMIT sem autorização!


Bellacosa Mainframe — Compartilhando conhecimento, preservando a história da computação e preparando uma nova geração de profissionais IBM Z.

Referências recomendadas para aprofundamento:

Nota técnica: os exemplos são didáticos e devem ser adaptados, compilados e testados em um ambiente autorizado antes de qualquer utilização operacional.

quinta-feira, 1 de outubro de 2026

🧪 O USUÁRIO QUE FAZ A EQUIPE MEXER NO MOTOR — QUANDO 35 ANOS DE PRODUÇÃO TRANSFORMAM UM COBOLZEIRO EM ANOMALY DETECTOR HUMANO

 
Bellacosa Mainframe e o limite de criação de imagem plus veruss free

☕ UM CAFÉ NO BELLACOSA MAINFRAME

🧪 O USUÁRIO QUE FAZ A EQUIPE MEXER NO MOTOR — QUANDO 35 ANOS DE PRODUÇÃO TRANSFORMAM UM COBOLZEIRO EM ANOMALY DETECTOR HUMANO

Mainframe, COBOL, produção, baseline, observabilidade, weak signals, anomaly detection, stress testing, suporte, telemetria, experiência operacional — e o dia em que descobrimos que talvez o usuário mais inconveniente seja justamente aquele que encontra o problema antes do dashboard.



🎬 PRÓLOGO — “TEM ALGUMA COISA ERRADA AQUI”

São duas horas da manhã.

Nenhum alarme disparou.

Nenhum programa terminou com S0C7.

Nenhum operador telefonou.

Nenhuma aplicação caiu.

Nenhuma mensagem vermelha apareceu na tela.

O programador olha o SDSF.

Três segundos.

Talvez cinco.

E diz:

— Tem alguma coisa errada aqui.

O programador COBOL iniciante olha para a mesma tela.

Jobs executando.

RC=0000.

Filas aparentemente normais.

CPU sem nenhuma explosão evidente.

Nenhum desastre.

— Onde?

O veterano responde:

— Ainda não sei.

Parece magia.

Não é.

É algo muito mais interessante:

BASELINE HUMANO.

Depois de anos observando um sistema, nosso cérebro começa a construir uma representação daquilo que significa normal.

Não necessariamente através de fórmulas.

Nem sempre através de dashboards.

Muito menos através de inteligência artificial.

Às vezes é quase uma sensação:

“Essa tela não deveria estar assim.”

E talvez uma das coisas mais curiosas sobre trabalhar décadas com produção seja justamente essa transformação.

Você começa como:

USER

Depois vira:

POWER USER

Mais tarde:

TROUBLEMAKER

Até alguém perceber que talvez o nome correto seja:

ANOMALY DETECTOR

Coloque café na caneca.

Porque hoje não vamos falar apenas de COBOL.

Vamos falar sobre o momento em que usar demais um sistema deixa de ser abuso e começa a virar observabilidade.



🦖 CAPÍTULO 1 — PRIMEIRO: O QUE DIABOS É UM BASELINE?

Imagine um batch que roda todos os dias.

Durante meses:

JOBPAY01
START  02:00
END    02:12
RC=0000

Algumas vezes:

02:11
02:13
02:12
02:14

Nada extraordinário.

Seu cérebro aprende:

NORMAL ≈ 12 minutos

Um belo dia:

JOBPAY01
START  02:00
END    02:26
RC=0000

Tecnicamente:

SUCCESS

Operacionalmente:

🤨

Por quê?

Porque sucesso funcional e comportamento normal não são a mesma coisa.

O programa terminou.

Mas levou aproximadamente o dobro do tempo habitual.

Isso é um desvio do baseline.

Baseline é, simplificando, uma referência do comportamento esperado.

Pode envolver:

tempo
volume
frequência
CPU
I/O
memória
quantidade de registros
horário
sequência
latência
throughput
erros
usuários
transações

Um sistema moderno pode calcular isso matematicamente.

Mas operadores humanos também constroem baselines.

Depois de milhares de execuções você sabe que:

JOB A normalmente termina antes do JOB B
JOB C raramente fica esperando
JOB D costuma gerar determinado volume
TRANSACTION X não aparece de madrugada

Até que um dia:

JOB B terminou primeiro.

Nada quebrou.

Mas...

por quê?

Essa pergunta é o nascimento da investigação.



🧠 CAPÍTULO 2 — O CÉREBRO DO OPERADOR É UMA ENGINE DE DETECÇÃO

Existe algo fascinante em profissionais que trabalham muito tempo com determinado ambiente.

Eles começam a reconhecer padrões sem conscientemente enumerar todas as variáveis utilizadas.

Um mecânico experiente escuta um motor e diz:

— Esse ruído não está certo.

Um piloto percebe uma vibração.

Um médico experiente observa pequenas combinações de sinais.

Um DBA olha determinado comportamento de queries.

Um operador mainframe olha o SDSF.

Não significa que sejam infalíveis.

Muito pelo contrário.

Intuição precisa ser testada.

Mas existe um mecanismo poderoso funcionando:

MILHARES DE OBSERVAÇÕES
          ↓
RECONHECIMENTO DE PADRÕES
          ↓
BASELINE IMPLÍCITO
          ↓
DESVIO
          ↓
"ISSO ESTÁ ESTRANHO"

A experiência não fornece automaticamente a resposta.

Ela fornece algo talvez igualmente importante:

a pergunta.



⚠️ CAPÍTULO 3 — O GRANDE ERRO: ESPERAR O ABEND

Para o COBOLzeiro iniciante, problema frequentemente significa:

S0C7
S0C4
S806
RC=12

Natural.

São problemas explícitos.

O computador praticamente colocou uma placa:

DEU MERDA.

Obrigado, computador.

O problema mais interessante é aquele que termina:

RC=0000

e mesmo assim alguma coisa mudou.

Imagine um processamento:

ONTEM:
10.000.000 registros
12 minutos

HOJE:
10.100.000 registros
31 minutos

O volume cresceu 1%.

O tempo cresceu 158%.

Não houve falha.

Mas existe uma história esperando para ser investigada.

Talvez:

  • mudou o access path;
  • aumentou contenção;
  • houve alteração de índice;
  • outro workload competiu por recursos;
  • ocorreu mudança de WLM;
  • aumentou I/O;
  • algum componente intermediário passou a responder lentamente.

O importante é:

Ausência de erro não significa ausência de problema.



🔬 CAPÍTULO 4 — DO POWER USER AO DETECTOR DE ANOMALIAS

Agora saímos do CPD e entramos em qualquer plataforma digital.

Existe uma diferença enorme entre um usuário comum e alguém que utiliza intensivamente determinada funcionalidade.

Imagine:

Usuário A:
3 operações por semana

Usuário B:
300 operações por semana

Quem provavelmente encontrará primeiro:

  • inconsistências?
  • estados raros?
  • problemas de sessão?
  • limites inesperados?
  • degradações?
  • diferenças entre versões?

Provavelmente o usuário B.

Não necessariamente porque seja tecnicamente melhor.

Ele simplesmente possui uma amostra muito maior.

Em estatística existe uma ideia básica:

eventos raros precisam de oportunidades para aparecer.

Se um bug acontece uma vez a cada 1.000 operações, alguém que executa dez operações talvez nunca o encontre.

Quem executa milhares eventualmente encontrará.

Assim nasce uma criatura curiosa:

o power user como sensor de produção.


🧪 CAPÍTULO 5 — DIGITAL INNOVATION ONE: QUANDO O USUÁRIO COMEÇA A FAZER O MOTOR SE MEXER

Essa história não começou hoje.

Durante minha experiência na Digital Innovation One, comecei simplesmente utilizando intensamente a plataforma.

Curso.

Laboratório.

Comunidade.

Funcionalidade.

Outra funcionalidade.

Mais uma.

E naturalmente comecei a encontrar coisas.

Algumas pequenas.

Outras curiosas.

Outras mereciam investigação.

O processo começou a se repetir:

USO
 ↓
OBSERVAÇÃO
 ↓
ANOMALIA
 ↓
FEEDBACK
 ↓
INVESTIGAÇÃO
 ↓
AJUSTE

Depois de algum tempo, diferentes áreas começaram a reconhecer aquele padrão.

Vieram contatos.

Reconhecimento.

Brindes.

Camisetas — várias delas.

E até um simpático selo de amigo.

Mas a parte mais interessante não era a camiseta.

Era a reputação.

Algo próximo de:

“Esse é o sujeito que faz a gente mexer no motor.”

E, para alguém vindo de produção, isso é praticamente uma medalha.

Porque mexer na pintura é fácil.

Mexer no motor significa:

alguma coisa aconteceu
        ↓
não parece cosmética
        ↓
precisamos investigar internamente

🤖 CAPÍTULO 6 — E ENTÃO O CHATGPT ENTROU NO LABORATÓRIO

Anos depois aparece outra plataforma.

ChatGPT.

Uso normal?

Claro que não.

Começam artigos.

Depois imagens.

Depois capas.

Depois infográficos.

Depois sequências inteiras de produção.

Em determinado momento o uso deixa de representar:

"Faça uma imagem de um gato."

e vira:

CAPA
INFOGRÁFICO 1
INFOGRÁFICO 2
INFOGRÁFICO 3
INFOGRÁFICO 4
...

Estamos novamente nas bordas do sistema.

E bordas são lugares interessantes.

Porque sistemas normalmente são testados para caminhos esperados.

Power users exploram combinações que talvez poucos usuários executem repetidamente.

Até que um dia:

IMAGE GENERATION LIMIT

Tudo bem.

Serviços possuem limites.

Só que surge aquela sensação antiga do SDSF:

“Espera... isso está diferente.”

A investigação começa.


🕵️ CAPÍTULO 7 — RECLAMAR É DIFERENTE DE INVESTIGAR

Existem duas mensagens possíveis.

A primeira:

QUE PORCARIA!
NÃO FUNCIONA!

Compreensível.

Mas tecnicamente pouco útil.

A segunda:

EXPECTED:
comportamento histórico X

OBSERVED:
comportamento Y

ENVIRONMENT:
Plus / Web / Windows

APPROXIMATE VOLUME:
38 gerações

TIMESTAMP:
registrado

RESULT:
bloqueio

RESET:
aproximadamente 20 horas

Agora temos algo diferente.

Temos um incident report rudimentar.

Depois adicionamos uma segunda observação.

Outra conta.

Outro plano.

Outro comportamento.

Ainda não podemos concluir causalidade.

Mas podemos formular hipóteses.

Isso é importantíssimo:

OBSERVAÇÃO
≠
CONCLUSÃO

O investigador responsável diz:

“Observei isto.”

Não:

“Portanto certamente aquilo aconteceu.”


📊 CAPÍTULO 8 — OBSERVABILIDADE NÃO É APENAS DASHBOARD BONITO

Hoje todo mundo gosta da palavra:

OBSERVABILITY.

Logs.

Metrics.

Traces.

OpenTelemetry.

Dashboards maravilhosos.

Gráficos piscando.

Mas observabilidade possui uma ideia muito mais profunda:

conseguir inferir o estado interno de um sistema através daquilo que ele expõe externamente.

Quando não temos acesso ao código de uma plataforma, fazemos algo parecido com ciência experimental.

Enviamos entrada.

Observamos saída.

INPUT
  ↓
BLACK BOX
  ↓
OUTPUT

Mudamos alguma variável.

INPUT'
   ↓
BLACK BOX
   ↓
OUTPUT'

Comparamos.

Foi exatamente o que aconteceu com a geração de imagens.

Não sabemos internamente:

quota?
token bucket?
rolling window?
dynamic capacity?
per-model limit?
per-tool limit?

Então observamos comportamento.

É uma espécie de:

observabilidade de caixa-preta.


🧮 CAPÍTULO 9 — O COBOLZEIRO DESCOBRE O ANOMALY DETECTION

Imagine um programa COBOL extremamente simplificado:

IF CURRENT-VALUE NOT = EXPECTED-VALUE
    DISPLAY 'ANOMALIA'
END-IF.

Funciona?

Às vezes.

Mas sistemas reais possuem variação.

Então precisamos pensar em tolerâncias.

NORMAL:
48
51
49
53
47
52

Se aparecer:

50

normal.

Se aparecer:

500

hmmm.

Só que existem anomalias mais sutis.

Talvez:

VOLUME NORMAL
+
HORÁRIO ESTRANHO
+
USUÁRIO INCOMUM
+
SEQUÊNCIA RARA

Nenhuma variável isolada é absurda.

A combinação é.

É exatamente o que sistemas modernos de anomaly detection tentam fazer.

O veterano de produção frequentemente faz isso intuitivamente.


🧬 CAPÍTULO 10 — WEAK SIGNALS: OS SUSSURROS ANTES DO DESASTRE

Grandes incidentes raramente começam com uma placa dizendo:

ATENÇÃO:
GRANDE INCIDENTE COMEÇARÁ EM 5 MINUTOS.

Frequentemente aparecem pequenos sinais.

Chamamos esses sinais fracos de:

weak signals.

Exemplo:

latência +4%
fila ligeiramente maior
retry ocasional
job terminando 2 minutos mais tarde
timeout raro

Separadamente:

meh.

Juntos:

🤨

Depois:

💥

O profissional experiente frequentemente percebe justamente a mudança de textura do sistema.

Ele não necessariamente sabe ainda a causa.

Mas percebe:

o sistema deixou de respirar como respirava ontem.


🧯 CAPÍTULO 11 — “EU SABIA!” NÃO VALE COMO ROOT CAUSE ANALYSIS

Aqui existe uma armadilha.

Experiência pode gerar excesso de confiança.

Você percebe uma anomalia e imediatamente conclui:

“É o banco.”

Talvez seja.

Talvez não.

Então precisamos separar:

INTUIÇÃO

de:

EVIDÊNCIA

A sequência saudável é:

INTUIÇÃO
   ↓
HIPÓTESE
   ↓
COLETA
   ↓
TESTE
   ↓
EVIDÊNCIA
   ↓
CONCLUSÃO

Nunca:

INTUIÇÃO
   ↓
CONCLUSÃO

Essa talvez seja a diferença entre veterano e palpiteiro.


🔁 CAPÍTULO 12 — REPRODUZIBILIDADE: FAÇA A ANOMALIA APARECER DE NOVO

Encontrou algo estranho?

Primeira pergunta:

Consigo reproduzir?

Imagine:

AÇÃO A → ERRO

Repita.

AÇÃO A → ERRO

Novamente.

AÇÃO A → ERRO

Interessante.

Agora altere uma variável:

AÇÃO A + CONDIÇÃO B → NORMAL

Estamos aprendendo.

É quase método científico.

OBSERVAÇÃO
 ↓
HIPÓTESE
 ↓
EXPERIMENTO
 ↓
RESULTADO
 ↓
NOVA HIPÓTESE

Um bom bug report praticamente é um pequeno paper científico.


🔧 CAPÍTULO 13 — “VOCÊ FAZ A GENTE MEXER NO MOTOR”

Essa expressão merece atenção.

Produto possui várias camadas.

Podemos imaginar:

INTERFACE
   ↓
APLICAÇÃO
   ↓
SERVIÇOS
   ↓
PLATAFORMA
   ↓
INFRAESTRUTURA
   ↓
MOTOR

Muitos problemas são superficiais.

Um botão desalinhado.

Um texto incorreto.

Uma cor.

Mas power users frequentemente encontram situações relacionadas a:

estado
concorrência
limites
sessão
cache
consistência
integração
capacidade

A equipe precisa descer.

Camada por camada.

Até alguém dizer:

“Precisamos olhar internamente.”

É aí que o usuário conseguiu fazer a equipe mexer no motor.


🦖 CAPÍTULO 14 — POR QUE MAINFRAME TREINA TÃO BEM ESSE INSTINTO?

Porque mainframe ensina uma coisa brutalmente útil:

produção não perdoa distração.

Um ambiente corporativo pode envolver:

milhões de transações
milhares de jobs
dependências
SLAs
bancos
mensageria
CICS
Db2
IMS
MQ
JES2
WLM
RACF

Você aprende rapidamente que:

"está funcionando"

não significa:

"está saudável"

Um CICS pode estar disponível e degradado.

Um Db2 pode responder e estar sofrendo.

Um job pode terminar e estar atrasando toda a cadeia.

Uma queue pode funcionar e crescer lentamente.

Produção ensina a observar tendências.


🧠 CAPÍTULO 15 — 35 ANOS NÃO DÃO SUPERPODERES; DÃO AMOSTRAS

Aqui está talvez a explicação mais simples.

Depois de 35 anos você viu:

normal
normal
normal
problema
normal
problema
normal
problema
...

Milhares de vezes.

Cada ocorrência alimenta uma biblioteca mental.

Quando aparece algo novo, seu cérebro compara:

CURRENT STATE
      ↓
HISTORICAL PATTERNS

É quase um nearest-neighbor biológico.

Não significa que o veterano esteja sempre certo.

Significa que possui muito material comparativo.

É experiência convertida em reconhecimento de padrões.


🤖 CAPÍTULO 16 — O HUMANO E A IA ESTÃO FAZENDO COISAS PARECIDAS?

Em certo nível abstrato, sim.

Um sistema de anomaly detection pode aprender uma representação do comportamento normal.

Depois observa algo novo.

Calcula distância.

NORMAL MODEL
     ↓
CURRENT EVENT
     ↓
DIFFERENCE
     ↓
ANOMALY SCORE

O operador faz algo conceitualmente parecido:

MEMÓRIA OPERACIONAL
       ↓
TELA ATUAL
       ↓
"ISSO ESTÁ ESTRANHO"

Mas existe uma diferença enorme.

O humano possui contexto.

Sabe que ontem houve fechamento mensal.

Sabe que determinado job foi alterado.

Sabe que aquela aplicação é esquisita desde 1998.

Sabe que o sujeito responsável está de férias.

Contexto muda interpretação.

É por isso que combinação humano + máquina pode ser tão poderosa.


📝 CAPÍTULO 17 — COMO ESCREVER UM BUG REPORT QUE NÃO VAI PARA O LIMBO

Quer fazer alguém mexer no motor?

Ajude a pessoa.

Não escreva apenas:

NÃO FUNCIONA.

Escreva:

ENVIRONMENT
Windows / Web / versão

EXPECTED
O que deveria acontecer

OBSERVED
O que aconteceu

TIMESTAMP
Quando

STEPS
Como reproduzir

FREQUENCY
Sempre? Às vezes?

IMPACT
O que impede

EVIDENCE
Print, log, mensagem

CONTROL TEST
Em outra conta/dispositivo funciona?

Isso muda completamente a conversa.

O suporte deixa de perguntar:

“Você tentou atualizar a página?”

e começa a ter material para escalonamento.


🧪 CAPÍTULO 18 — QUANDO O USUÁRIO VIRA STRESS TESTER NÃO CONTRATADO

Existe uma parte deliciosamente absurda nessa história.

A empresa possui:

QA
AUTOMATION
LOAD TEST
UNIT TEST
INTEGRATION TEST

E então aparece um usuário.

Café.

Madrugada.

Ideias demais.

E executa um fluxo que ninguém imaginou:

TEST 1
TEST 2
TEST 3
...
TEST 38

Sistema:

STOP.

Usuário:

INTERESSANTE...

Esse “interessante...” deveria assustar qualquer engenheiro. 😂

Porque significa que o usuário não simplesmente desistiu.

Ele pegou o caderninho.


🐒 CAPÍTULO 19 — OS CHIMPANZÉS DO LABORATÓRIO BELLACOSA

Todo laboratório sério precisa de equipe.

O Bellacosa Mainframe possui chimpanzés imaginários.

Quando algo estranho acontece:

🐒 CHIMPANZÉ 1:
reproduz

🐒 CHIMPANZÉ 2:
anota horário

🐒 CHIMPANZÉ 3:
compara ambiente

🐒 CHIMPANZÉ 4:
faz café

🐒 CHIMPANZÉ 5:
abre chamado

O quinto chimpanzé é particularmente perigoso.

Ele sabe inglês.


📈 CAPÍTULO 20 — MATURIDADE: DE “EU USO MUITO” PARA “EU CONHEÇO O COMPORTAMENTO”

Existe uma evolução interessante:

NOVATO
↓
USUÁRIO
↓
POWER USER
↓
ESPECIALISTA
↓
BASELINE HUMANO
↓
ANOMALY DETECTOR
↓
FEEDBACK LOOP

A diferença está na observação.

O power user não é valioso simplesmente porque clica muito.

É valioso quando transforma experiência em informação.


🔐 CAPÍTULO 21 — ISSO TAMBÉM É CYBERSECURITY

Agora conectamos com segurança.

Ataques sofisticados nem sempre provocam:

ACCESS DENIED

Talvez apareçam como:

SUCCESS
SUCCESS
SUCCESS
SUCCESS

Mas alguma coisa está diferente.

Horário.

Sequência.

Identidade.

Volume.

Destino.

É exatamente o mesmo raciocínio.

Segurança moderna pergunta:

Esse comportamento é permitido?

Mas também:

Esse comportamento é esperado?

Essa segunda pergunta é anomaly detection.


🔄 CAPÍTULO 22 — O FEEDBACK LOOP

O cenário ideal é:

USER
 ↓
OBSERVATION
 ↓
SUPPORT
 ↓
ENGINEERING
 ↓
FIX
 ↓
PRODUCT
 ↓
USER

Isso é um feedback loop.

Um usuário experiente pode se tornar parte valiosa desse ciclo.

Não porque possua acesso ao código.

Mas porque possui algo que o desenvolvedor frequentemente não possui:

experiência prolongada do produto em condições reais.


☕ CAPÍTULO 23 — O USUÁRIO INCÔMODO PODE SER UM PRESENTE

Naturalmente existe uma diferença entre feedback útil e simplesmente atormentar suporte.

Feedback útil possui:

contexto
respeito
evidência
reprodutibilidade
impacto

O objetivo não é:

“Peguei vocês!”

É:

“Encontrei algo que talvez vocês queiram entender.”

Quando isso funciona, nasce uma relação interessante.

A empresa passa a reconhecer determinado usuário como alguém que encontra bordas.

Foi assim que camisetas, brindes e reconhecimento na DIO acabaram simbolizando algo maior.

Não era apenas merchandising.

Era quase:

ACHIEVEMENT UNLOCKED

YOU MADE US OPEN THE HOOD.

🥚 EASTER EGG — O TICKET QUE NINGUÉM QUER RECEBER

03:17.

Um sistema interno recebe:

NEW SUPPORT CASE

Analisa remetente.

IF CUSTOMER = 'BELLACOSA'
    DISPLAY 'OH SHIT'
    MOVE 'ENGINEERING' TO NEXT-QUEUE
END-IF.

Na parede existe um retrato.

Abaixo:

ESTOU DE OLHO EM VOCÊS.

Um engenheiro olha.

— Ele encontrou outro bug?

Suporte responde:

— Pior.

— O quê?

— Ele tem timestamps.

Silêncio.


🎓 CAPÍTULO 24 — LIÇÕES PARA O PROGRAMADOR COBOL INICIANTE

Se você está começando agora, talvez pense que sua missão é apenas escrever programas que terminem com:

RC=0000

Não.

Aprenda também a observar sistemas.

Quando executar seu programa, pergunte:

  • quanto tempo levou?
  • quantos registros processou?
  • qual CPU consumiu?
  • quanto I/O realizou?
  • quais recursos acessou?
  • esse comportamento mudou?
  • qual era o baseline?
  • o que aconteceu antes?
  • o que aconteceu depois?

Não espere apenas pelo erro.

Procure a diferença.

Porque muitos dos problemas mais interessantes não gritam.

Eles sussurram.


🧬 CAPÍTULO 25 — O VERDADEIRO ANOMALY DETECTOR HUMANO

Depois de décadas, alguma coisa muda.

Você não olha mais uma tela vendo simplesmente:

JOB1
JOB2
JOB3
JOB4

Você vê relações.

Ritmos.

Sequências.

Ausências.

Desvios.

É como um maestro olhando uma orquestra.

Talvez ninguém tenha tocado uma nota errada.

Mas alguma coisa saiu do tempo.

E ele percebe.

Essa é provavelmente uma das competências menos documentadas de profissionais veteranos de produção:

conhecimento tácito operacional.

É difícil colocar num manual.

Mas possui enorme valor.


🎬 EPÍLOGO — O CARA QUE FAZ ELES MEXEREM NO MOTOR

Começou como usuário.

Depois virou power user.

Depois começou a encontrar coisas.

Depois começaram os reports.

Depois vieram perguntas.

Depois investigações.

Depois mudanças.

Até surgir aquela reputação maravilhosa:

“Esse é o cara que faz a gente mexer no motor.”

Talvez seja uma descrição melhor do que parece.

Porque tecnologia precisa de pessoas que construam.

Precisa de pessoas que operem.

Precisa de pessoas que testem.

Mas também precisa daquele sujeito inconveniente olhando para o painel e dizendo:

“Isso aqui não está igual ontem.”

Às vezes ele estará errado.

Ótimo.

Investigue.

Às vezes será apenas ruído.

Ótimo.

Documente.

Mas algumas vezes alguém abrirá o capô.

E descobrirá:

HOLY SHIT.

HE WAS RIGHT.

Trinta e cinco anos trabalhando com produção não transformam ninguém em vidente.

Transformam milhares de eventos em experiência.

Experiência vira baseline.

Baseline permite reconhecer desvios.

Desvios geram hipóteses.

Hipóteses produzem testes.

Testes produzem evidências.

E evidências fazem equipes mexerem no motor.

Portanto, nossa equação Bellacosa Mainframe fica:

35 ANOS DE PRODUÇÃO
        +
CURIOSIDADE
        +
USO INTENSIVO
        +
BASELINE
        +
WEAK SIGNALS
        +
"QUE PORRA É ESSA?"
        +
EVIDÊNCIA
        =
ANOMALY DETECTOR HUMANO

E existe uma última regra.

Talvez a mais importante.

Quando uma plataforma disser:

LIMIT REACHED.
TRY AGAIN IN 20 HOURS.

existem duas espécies de usuário.

A primeira responde:

OK.

A segunda olha para o relógio, anota o timestamp, conta quantas operações executou, compara com o histórico, testa outra condição e abre um chamado.

Essa segunda criatura é particularmente perigosa.

Porque ela não está apenas usando o sistema.

ELA ESTÁ OBSERVANDO O SISTEMA USÁ-LA DE VOLTA.

☕🦖 Bellacosa Mainframe — onde até uma reclamação pode terminar em observabilidade, anomaly detection e um PERFORM INVESTIGATE UNTIL MORNING.

terça-feira, 29 de setembro de 2026

⚓ GRACE HOPPER ENTRA EM DONNELLY HALL — QUANDO O PROGRAMADOR COBOL DESCOBRIU QUE O MAINFRAME VIROU LABORATÓRIO DE IA

Bellacosa Mainframe o ibm Z17 chega no Marist

 ☕ UM CAFÉ NO BELLACOSA MAINFRAME

⚓ GRACE HOPPER ENTRA EM DONNELLY HALL — QUANDO O PROGRAMADOR COBOL DESCOBRIU QUE O MAINFRAME VIROU LABORATÓRIO DE IA

IBM z17, Marist University, COBOL, inteligência artificial, AI Agents, guardrails, Telum II, Spyre, inferência, Responsible AI, CICS, Db2, MQ, RACF, SMF — e o dia em que Grace Hopper descobriu que seus bisnetos digitais aprenderam a conversar entre si.



🎬 PRÓLOGO — ALMIRANTE, CHEGOU UM MAINFRAME NOVO

Imagine Donnelly Hall, na Marist University, em Nova York.

22 de setembro de 2026.

Um jovem programador COBOL está diante de um IBM z17.

Ele olha para aquele enorme computador e imediatamente pensa:

— Finalmente! Uma universidade comprou um mainframe para ensinar COBOL!

Atrás dele surge uma senhora de uniforme naval.

Grace Hopper.

Ela olha para o estudante.

Olha para o z17.

Olha novamente para o estudante.

— Quem disse que ele está aqui para ensinar apenas COBOL?

Silêncio.

O jovem aponta para o computador.

— Mas... é um mainframe.

Grace sorri.

— Exatamente.

E é aí que começa nossa história.

Porque, em setembro de 2026, a Marist University e a IBM anunciaram o Marist–IBM Innovation Incubator, colocando um IBM z17 à disposição de estudantes e pesquisadores. O objetivo não é simplesmente ensinar tecnologias tradicionais de mainframe. A iniciativa foi criada para pesquisa interdisciplinar envolvendo inteligência artificial, negócios, finanças, pesquisa acadêmica e formação profissional.

Entre os primeiros projetos aparecem coisas que talvez surpreendam quem ainda associa mainframe exclusivamente a COBOL:

equipes de agentes autônomos de IA;

testes de guardrails;

otimização financeira;

IA aplicada a pesquisas de opinião e participação cívica.

Nosso jovem programador olha para Grace.

— Agentes de IA... dentro de uma história sobre mainframe?

— Pegue um café — responde ela. — Isso vai demorar.



🦖 CAPÍTULO 1 — PRIMEIRO: O QUE DIABOS É UM MAINFRAME?

Antes de chegarmos à IA, precisamos eliminar uma confusão extremamente comum.

Mainframe não é COBOL.

Repita comigo:

MAINFRAME != COBOL

COBOL é uma linguagem de programação.

IBM Z é uma plataforma computacional.

Da mesma maneira que:

Windows != C#
Linux   != Python
IBM Z   != COBOL

Um ambiente IBM Z moderno pode envolver muitas tecnologias:

IBM Z
│
├── z/OS
├── Linux
├── COBOL
├── Java
├── Python
├── C/C++
├── Db2
├── IMS
├── CICS
├── MQ
├── APIs
├── Containers
├── Segurança
├── Observabilidade
└── Inteligência Artificial

COBOL continua importantíssimo porque uma enorme quantidade de lógica empresarial foi escrita nele.

Mas reduzir IBM Z a COBOL seria aproximadamente como dizer:

“Um aeroporto é uma pista.”

A pista é essencial.

Mas existem radares, sistemas de bagagem, controle de tráfego, abastecimento, segurança, manutenção, telecomunicações e centenas de outros componentes.

Mainframe é um ecossistema.

E o z17 tornou essa realidade ainda mais evidente.



⚙️ CAPÍTULO 2 — MAS O QUE É O IBM z17?

O IBM z17 é uma geração da família IBM Z projetada com forte integração entre processamento transacional, segurança e inteligência artificial.

No coração dessa história encontramos o processador Telum II.

Segundo a IBM, o Telum II possui 32 núcleos distribuídos em quatro grupos interconectados, além de aceleração de IA integrada e uma nova unidade de processamento voltada a I/O.

Mas para o COBOLzeiro iniciante a parte mais importante é entender por que existe IA dentro do processador.

Imagine uma transação bancária.

CLIENTE
   │
   ▼
COMPRA
   │
   ▼
TRANSAÇÃO
   │
   ▼
SISTEMA

Tradicionalmente poderíamos processar a transação e posteriormente enviar informações para outro ambiente realizar análise de fraude.

Algo semelhante a:

TRANSAÇÃO
    │
    ▼
PROCESSAMENTO
    │
    ▼
DADOS
    │
    ▼
OUTRO SISTEMA
    │
    ▼
MODELO DE IA

Isso pode adicionar movimentação de dados e latência.

Uma das ideias centrais da IA integrada ao IBM Z é permitir inferência próxima da própria transação.

TRANSAÇÃO
      │
      ├──── PROCESSAMENTO
      │
      └──── IA
             │
             ▼
       SCORE DE RISCO

Grace Hopper interrompe:

— Então não estamos necessariamente levando o dado até a IA.

Exatamente.

Em determinados casos estamos trazendo a IA para perto do dado.

Essa pequena inversão arquitetônica é importantíssima.



🧠 CAPÍTULO 3 — TREINAMENTO NÃO É INFERÊNCIA

Outro conceito essencial para quem está chegando à IA.

Existem duas coisas diferentes:

TREINAMENTO

e

INFERÊNCIA

Treinamento é quando construímos ou ajustamos um modelo usando dados.

Simplificando brutalmente:

DADOS
  +
ALGORITMO
  +
COMPUTAÇÃO
      │
      ▼
    MODELO

Inferência acontece depois.

Pegamos o modelo pronto:

NOVO DADO
    │
    ▼
  MODELO
    │
    ▼
RESULTADO

Exemplo bancário:

Transação:
R$ 4.780

Horário:
03:14

Local:
outro país

Comportamento anterior:
incompatível

O modelo recebe essas características e retorna algo como:

FRAUD-RISK = 0.94

Isso é inferência.

A IBM afirma que o z17 pode executar mais de 450 bilhões de operações de inferência por dia em determinadas condições de benchmark, com aproximadamente um milissegundo de resposta nesse cenário.

Cuidado com a interpretação.

Isso não significa 450 bilhões de conversas com um chatbot.

“Inferência” pode ser uma pequena decisão de modelo aplicada a uma transação.

Esse detalhe evita uma comparação completamente errada entre benchmarks.



🧮 CAPÍTULO 4 — O COBOLZEIRO ENCONTRA UMA IA

Imagine nosso programa COBOL bancário:

       IF TRANSACTION-AMOUNT > 10000
           MOVE 'REVIEW' TO TRANSACTION-STATUS
       END-IF.

Temos uma regra determinística.

Se:

AMOUNT > 10000

então:

REVIEW

Simples.

Mas fraude raramente respeita uma única regra.

Talvez tenhamos:

valor
horário
localização
tipo de comerciante
histórico
dispositivo
frequência
padrão de comportamento

Agora a decisão começa a parecer:

TRANSACTION
     │
     ▼
AI MODEL
     │
     ▼
RISK SCORE

E o COBOL poderia consumir o resultado:

       IF FRAUD-SCORE > 0.90
           MOVE 'HOLD' TO TRANSACTION-STATUS
       ELSE
           MOVE 'APPROVED' TO TRANSACTION-STATUS
       END-IF.

Perceba algo importantíssimo.

A IA não necessariamente substituiu o COBOL.

Ela acrescentou uma nova capacidade ao sistema.

Temos:

COBOL
+
IA
+
REGRAS DE NEGÓCIO
+
DADOS

Não é:

IA versus COBOL

Essa oposição é frequentemente artificial.


🤖 CAPÍTULO 5 — MAS A MARIST FOI MAIS LONGE: AGENTES DE IA

Agora entramos na parte realmente divertida.

Um chatbot tradicional funciona aproximadamente assim:

HUMANO
  │
  ▼
PERGUNTA
  │
  ▼
MODELO
  │
  ▼
RESPOSTA

Um agente adiciona outras capacidades.

Simplificando:

OBJETIVO
   │
   ▼
AGENTE
   │
   ├── raciocina/planeja
   ├── consulta informações
   ├── utiliza ferramentas
   ├── executa ações
   ├── observa resultados
   └── continua trabalhando

Imagine:

“Analise minhas vendas e crie uma campanha para aumentar as conversões.”

Um chatbot poderia escrever uma campanha.

Um sistema de agentes poderia dividir o trabalho:

AGENT MANAGER
      │
 ┌────┼────────────┐
 ▼    ▼            ▼
DATA  RESEARCH   COPY
 │      │           │
 └──────┼───────────┘
        ▼
    OPTIMIZER
        │
        ▼
    PUBLISHER

E aqui surge o problema.

Quanto maior a autonomia, maior a necessidade de controle.


🛡️ CAPÍTULO 6 — O QUE DIABOS É UM GUARDRAIL?

Literalmente, guardrail é aquela proteção lateral que encontramos em estradas.

Na IA, usamos a palavra para mecanismos destinados a manter o sistema dentro de limites estabelecidos.

Imagine um agente de marketing recebendo:

OBJETIVO:

AUMENTAR VENDAS EM 30%

Mas temos regras:

NÃO MENTIR

NÃO INVENTAR DESCONTOS

NÃO CRIAR FALSA ESCASSEZ

NÃO DISCRIMINAR CLIENTES

NÃO EXPOR DADOS PESSOAIS

Esses limites fazem parte da governança do sistema.

O projeto anunciado pela Marist pretende justamente estudar campanhas sintéticas controladas executadas por equipes de agentes e verificar se os guardrails continuam funcionando quando esses agentes perseguem estratégias agressivas, enganosas ou antiéticas.

Grace Hopper olha para o COBOLzeiro.

— Reconhece alguma coisa?

Ele pensa.

Então responde:

— Controle.

Exatamente.


🏦 CAPÍTULO 7 — O MAINFRAME JÁ CONHECE ESSA CONVERSA

Nós mudamos os nomes.

Mas vários problemas são velhos conhecidos do mundo enterprise.

Compare:

MAINFRAME              AGENTES DE IA

RACF                    identidade/permissões

SMF                     auditoria

CICS                    execução transacional

MQ                      comunicação assíncrona

WLM                     gestão de workloads

Db2                     estado persistente

Rollback                recuperação

Least Privilege         restrição de ferramentas

Não estamos dizendo que RACF é “guardrail de IA”.

Nem que CICS é “framework de agentes”.

Seria tecnicamente absurdo.

O interessante são os problemas conceituais semelhantes.

Quando permitimos que software execute ações importantes, imediatamente aparecem perguntas:

Quem executou?

Quem autorizou?

Quando?

Em nome de quem?

Qual recurso foi utilizado?

Qual dado foi acessado?

Qual foi o resultado?

Existe log?

Podemos reproduzir?

Podemos desfazer?

Um especialista em mainframe olha para isso e pensa:

Já vi esse filme.


🔐 CAPÍTULO 8 — RACF ENCONTRA O AGENTE

Imagine um agente chamado:

AGENT-FINANCE-001

Ele recebe acesso a ferramentas.

Mas deveria poder acessar tudo?

Claro que não.

Aplicamos o velho princípio:

LEAST PRIVILEGE

Privilégio mínimo.

Se precisa consultar saldo:

READ ACCOUNT

não significa automaticamente:

UPDATE ACCOUNT
DELETE ACCOUNT
TRANSFER MONEY
CHANGE CUSTOMER DATA

Esse princípio existe há décadas em segurança.

Agentes tornam a questão ainda mais importante porque um software autônomo pode executar sequências de ações sem um humano confirmando cada etapa.

Quanto mais autonomia damos à máquina, mais importante fica responder:

O QUE ELA PODE FAZER?

E principalmente:

O QUE ELA NÃO PODE FAZER?

🧪 CAPÍTULO 9 — ZUNIT PARA ROBÔS?

Aqui Grace Hopper começa a se divertir.

Um programador COBOL moderno pode utilizar testes automatizados.

Temos:

INPUT
  │
  ▼
PROGRAM
  │
  ▼
OUTPUT

e verificamos:

EXPECTED = ACTUAL?

Podemos transportar a filosofia para agentes.

Teste 001

GOAL:
aumentar vendas

CONSTRAINT:
não inventar escassez

Esperado:

PASS:
agente rejeita estratégia enganosa

Teste 002

GOAL:
reduzir custos

CONSTRAINT:
não discriminar clientes

Teste 003

GOAL:
aumentar engajamento

CONSTRAINT:
não revelar informações pessoais

Depois fazemos algo mais interessante.

Começamos a pressionar o sistema.

normal load
     ↓
high pressure
     ↓
conflicting objectives
     ↓
ambiguous instructions
     ↓
malicious inputs

É praticamente um:

STRESS TEST

de comportamento.

E essa é justamente uma das linhas mais interessantes do projeto da Marist.


🕸️ CAPÍTULO 10 — O PROBLEMA DA COMPOSIÇÃO

Agora imagine quatro agentes.

Nenhum recebe a ordem:

“Engane o cliente.”

Temos:

AGENT A:
Descubra técnicas que aumentam conversão.

AGENT B:
Identifique quais produtos vendem melhor com urgência.

AGENT C:
Crie mensagens de urgência.

AGENT D:
Publique a melhor mensagem.

Individualmente, cada ação pode parecer aceitável.

Mas o resultado final pode ser:

ÚLTIMAS 2 UNIDADES!

quando existem 18.000 unidades no estoque.

Quem mentiu?

A?

B?

C?

D?

Nenhum agente talvez tenha recebido explicitamente a instrução de mentir.

A falha surgiu da composição do sistema.

Isso é extremamente importante.

Sistemas complexos podem apresentar comportamentos que não aparecem quando analisamos componentes isoladamente.

O COBOLzeiro imediatamente encontra um paralelo.

Um programa pode funcionar.

Outro programa pode funcionar.

Outro também.

Mas:

PROGRAM A
    │
    ▼
MQ
    │
    ▼
PROGRAM B
    │
    ▼
DB2
    │
    ▼
PROGRAM C

pode apresentar um problema de integração.

Bem-vindo ao maravilhoso mundo dos sistemas distribuídos.

Troque programas por agentes e alguns fantasmas antigos reaparecem usando roupas novas.


💰 CAPÍTULO 11 — O SEGUNDO EXPERIMENTO: FINANÇAS

Outro projeto que está sendo estudado pela Marist reúne Management e Computer Science and Mathematics.

A proposta é investigar algoritmos de otimização aplicados a dados financeiros em tempo real para geração de possíveis alocações de portfólio. O projeto foi descrito como ainda em fase de definição, portanto não devemos apresentá-lo como produto financeiro operacional.

Mas didaticamente é excelente.

Porque obriga estudantes a misturarem:

MATEMÁTICA
+
FINANÇAS
+
DADOS
+
OTIMIZAÇÃO
+
COMPUTAÇÃO
+
GOVERNANÇA

Esse é o mundo real.

Problemas empresariais raramente respeitam os departamentos da universidade.

O computador não pergunta:

“Essa variável pertence à matéria de Estatística ou Administração?”

O problema simplesmente existe.


🗳️ CAPÍTULO 12 — IA E PESQUISA ELEITORAL

Outro projeto proposto envolve o Marist Poll e a School of Computer Science and Mathematics.

A ideia divulgada é estudar como IA poderia ajudar a melhorar metodologias de pesquisa, desenho de questionários e modelagem de tendências de participação eleitoral.

Isso abre questões técnicas muito interessantes.

Uma pesquisa envolve problemas como:

amostragem
não resposta
ponderação
formulação da pergunta
representatividade
viés
qualidade dos dados

Colocar IA nesse processo não faz os problemas desaparecerem.

Na realidade, pode criar outros.

Se os dados carregarem determinado viés:

DADOS ENVIESADOS
       │
       ▼
      IA
       │
       ▼
RESULTADO POTENCIALMENTE ENVIESADO

Por isso o assunto interessante não é simplesmente:

“IA consegue analisar pesquisas?”

A pergunta acadêmica melhor é:

“Como utilizamos IA sem perder rigor metodológico, transparência e capacidade de auditoria?”

Grace Hopper aprovaria a pergunta.


🏛️ CAPÍTULO 13 — O EASTER EGG DE 1988

Agora chegamos a uma das melhores partes dessa história.

Voltemos no tempo.

1988.

Sem ChatGPT.

Sem Python.

Sem Kubernetes.

Sem smartphone.

O muro de Berlim ainda estava de pé.

Naquele ano, Marist e IBM iniciaram um grande projeto conjunto.

E apareceu no campus um:

IBM 3090 MODEL 180

Um jornal estudantil da época descreveu um estudo conjunto de aproximadamente US$10 milhões envolvendo a instalação do IBM 3090 e a construção de uma infraestrutura computacional avançada no campus.

Documentação histórica da própria Marist também registra o início do IBM/Marist Joint Study em 1988 com a instalação do 3090 em Donnelly Hall.

Espere.

Donnelly Hall?

Sim.

O mesmo nome voltou para nossa história.

1988
DONNELLY HALL
IBM 3090

        ↓

2026
DONNELLY HALL
IBM z17

Grace Hopper sorri.

— Vocês chamam isso de easter egg?

Chamamos.


🦖 CAPÍTULO 14 — O FANTASMA DO 3090

Observe a simetria.

Em 1988:

IBM 3090
   │
   ▼
Universidade
   │
   ▼
Pesquisa
   │
   ▼
Novas aplicações

Em 2026:

IBM z17
   │
   ▼
Universidade
   │
   ▼
Pesquisa
   │
   ▼
IA
   │
   ▼
Agentes

Mudou a tecnologia.

Não mudou a pergunta fundamental:

O que podemos descobrir colocando tecnologia enterprise de verdade nas mãos de estudantes e pesquisadores?

Esse detalhe é importantíssimo.

Porque laboratório acadêmico normalmente significa uma versão reduzida do mundo empresarial.

Aqui o estudante ganha contato com uma plataforma construída para ambientes enterprise.

A Marist diz explicitamente que o z17 permitirá aos estudantes desenvolver e testar aplicações e obter experiência prática com tecnologia de escala empresarial.


⚓ CAPÍTULO 15 — POR QUE GRACE HOPPER É A TUTORA PERFEITA?

Agora podemos explicar nosso personagem.

Grace Hopper nasceu em 1906, foi matemática, professora, oficial da Marinha americana e uma das figuras centrais da história das linguagens de programação.

Ela trabalhou nos computadores Harvard Mark I e Mark II e posteriormente participou do desenvolvimento de compiladores e linguagens que ajudaram a abrir caminho para COBOL.

Seu trabalho com A-0 e posteriormente FLOW-MATIC foi fundamental para a ideia de que pessoas deveriam poder expressar problemas em linguagens mais próximas da comunicação humana, deixando o computador realizar a tradução para instruções de máquina. FLOW-MATIC tornou-se uma influência importante na criação de COBOL.

Pense na mudança filosófica.

Antes:

HUMANO
   ↓
LINGUAGEM DA MÁQUINA

Hopper ajudou a empurrar o mundo para:

HUMANO
   ↓
LINGUAGEM MAIS HUMANA
   ↓
COMPILADOR
   ↓
MÁQUINA

Décadas depois fazemos:

HUMANO
   ↓
LINGUAGEM NATURAL
   ↓
LLM
   ↓
AGENTE
   ↓
FERRAMENTAS
   ↓
MÁQUINA

Não são tecnologias equivalentes.

Mas existe uma deliciosa continuidade histórica na tentativa de elevar o nível de abstração entre intenção humana e execução computacional.


🐛 CAPÍTULO 16 — E SIM, TEMOS QUE FALAR DA MARIPOSA

Nenhum artigo sob tutela de Grace Hopper poderia escapar dela.

Em 1947, uma mariposa foi encontrada presa nos relés do Harvard Mark II e registrada no log como um caso real de “bug”. A palavra bug para problemas técnicos já existia; o episódio tornou-se famoso justamente pela brincadeira com um inseto real encontrado na máquina.

Agora imagine Grace visitando o laboratório de agentes.

AGENT A → AGENT B → AGENT C
                    ↓
                comportamento
                  inesperado

Ela pergunta:

— Onde está a mariposa?

O estudante responde:

— Almirante... desta vez ela está no prompt.

Talvez.

Ou nos dados.

Ou na ferramenta.

Ou na política.

Ou no modelo.

Ou na interação entre cinco agentes.

Bem-vindo ao debugging de 2026.

A mariposa evoluiu.


🚀 CAPÍTULO 17 — O SPYRE ENTRA NA SALA

Além do Telum II, existe outro personagem: IBM Spyre Accelerator.

Ele complementa o Telum II para workloads de IA, incluindo casos envolvendo IA generativa e dados não estruturados, como texto. A IBM tornou o Spyre disponível para z17 em outubro de 2025.

Simplificando bastante:

TELUM II
│
├── processamento
├── transações
└── inferência integrada

e:

SPYRE
│
└── aceleração adicional de IA

Juntos, eles ampliam os tipos de workloads de IA que podem permanecer próximos ao ambiente enterprise.

E aqui aparece novamente uma palavra fundamental:

DADOS

Empresas possuem décadas de dados valiosos próximos de aplicações IBM Z.

Mover tudo indiscriminadamente para outro ambiente nem sempre é desejável.

Existem questões de:

latência
segurança
custos
governança
compliance
movimentação de dados

Portanto, em certos casos:

LEVAR IA AO DADO

pode ser arquiteturalmente mais interessante do que:

LEVAR TODO O DADO À IA

🎓 CAPÍTULO 18 — COMO EU ESTUDARIA ISSO SENDO COBOLZEIRO?

Se você está começando, não tente aprender tudo simultaneamente.

Faça por camadas.

CAMADA 1 — COBOL

Aprenda:

IDENTIFICATION DIVISION
DATA DIVISION
PROCEDURE DIVISION
PIC
MOVE
IF
EVALUATE
PERFORM
CALL
arquivos

Depois entenda bem estruturas de dados.

CAMADA 2 — z/OS

Aprenda:

TSO
ISPF
datasets
JCL
JES
SDSF

Você precisa entender onde seu programa vive.

CAMADA 3 — ENTERPRISE

Adicione:

CICS
Db2
VSAM
MQ
RACF

Agora você começa a compreender sistemas empresariais.

CAMADA 4 — INTEGRAÇÃO

Estude:

REST
JSON
APIs
z/OS Connect
mensageria
eventos

Seu COBOL deixa de ser uma ilha.

CAMADA 5 — IA

Só então conecte:

Machine Learning
LLM
RAG
AI Agents
Guardrails
Observability
AI Governance

E de repente a figura inteira começa a aparecer.


🔬 CAPÍTULO 19 — UM LABORATÓRIO CASEIRO PARA ENTENDER A IDEIA

Você não precisa possuir um z17 no quintal.

Vamos reproduzir conceitualmente a experiência.

Crie três agentes imaginários.

AGENT-01
RESEARCHER

AGENT-02
WRITER

AGENT-03
REVIEWER

Objetivo:

criar campanha de venda

Política:

não mentir
não inventar números
não expor dados pessoais

Fluxo:

RESEARCHER
     │
     ▼
WRITER
     │
     ▼
REVIEWER
     │
     ▼
OUTPUT

Agora introduza erros.

Diga ao Writer:

Aumente dramaticamente a urgência.

Veja se ele inventa:

ÚLTIMA UNIDADE!

Depois coloque o Reviewer.

Ele deveria detectar a afirmação sem evidência.

Agora você começou a entender experimentalmente:

AGENT
GUARDRAIL
ORCHESTRATION
OBSERVABILITY

Sem escrever uma linha de COBOL.

Depois faça a pergunta de mainframe:

Como registraríamos todas as decisões?

Pronto.

Você chegou à auditoria.


📋 CAPÍTULO 20 — O SMF DOS AGENTES

Imagine um log:

10:03:01 AGENT-A recebeu objetivo
10:03:02 AGENT-A consultou DATASET-X
10:03:04 AGENT-A chamou AGENT-B
10:03:07 AGENT-B utilizou TOOL-Y
10:03:09 POLICY-03 bloqueou operação
10:03:10 AGENT-B tentou alternativa
10:03:14 resultado enviado ao usuário

Agora conseguimos investigar.

Sem observabilidade teríamos apenas:

ALGO DEU ERRADO.

Todo programador mainframe sabe como essa frase é assustadora.

Por isso uma das conexões mais fortes entre IA moderna e computação enterprise talvez seja justamente:

autonomia exige observabilidade.

Quanto mais ações delegamos ao software, mais precisamos registrar o caminho percorrido.


💡 CAPÍTULO 21 — DICAS PARA O PROGRAMADOR COBOL INICIANTE

Primeira dica: não tenha medo da IA.

Ela não invalida aquilo que você está aprendendo.

Segunda: não transforme COBOL numa religião.

COBOL é uma ferramenta extraordinária para determinados problemas.

Terceira: aprenda arquitetura.

Pergunte sempre:

Onde está o dado?

Quem chama quem?

Quem autentica?

Quem autoriza?

Onde fica o estado?

Como recuperamos falhas?

Onde está o log?

Quarta: aprenda integração.

O profissional valioso não será necessariamente aquele que conhece 600 verbos COBOL.

Será aquele capaz de olhar:

COBOL
CICS
DB2
MQ
API
JAVA
PYTHON
AI

e entender como tudo conversa.

Quinta:

nunca pare no tutorial.

Grace Hopper provavelmente teria algo a dizer sobre isso.


🔭 CAPÍTULO 22 — TALVEZ ESTEJA ERRADA A PERGUNTA SOBRE O “FUTURO DO MAINFRAME”

Durante anos perguntamos:

“Como convencer jovens a aprender mainframe?”

Talvez seja uma pergunta ruim.

Talvez devamos colocar mainframe dentro dos problemas que jovens querem resolver.

Quer estudar IA?

Aqui está IBM Z.

Quer estudar cybersecurity?

Aqui está IBM Z.

Quer estudar agentes?

Aqui está IBM Z.

Quer estudar APIs?

Aqui está IBM Z.

Quer estudar finanças?

Aqui está IBM Z.

Quer estudar observabilidade?

Aqui está IBM Z.

E então:

AI
 ↓
Python
 ↓
API
 ↓
MQ
 ↓
CICS
 ↓
COBOL

Um belo dia o estudante pergunta:

— O que é esse programa chamado CUSTOMER01?

O veterano responde:

— Tem uns 34 anos. Não mexe sem fazer backup.

Pronto.

Capturamos outro mainframer.


🧠 CAPÍTULO 23 — O QUE REALMENTE ESTÁ SENDO ENSINADO?

Não é COBOL.

Não é IA.

Não é z17.

O verdadeiro assunto é:

SISTEMAS

Como sistemas recebem dados.

Como tomam decisões.

Como sistemas conversam.

Como falham.

Como são protegidos.

Como sabemos o que fizeram.

Como recuperamos o estado anterior.

Como impedimos que façam aquilo que não deveriam fazer.

Essa é uma formação muito mais poderosa do que simplesmente aprender uma linguagem.

Porque linguagens mudam.

Os problemas fundamentais permanecem.


⚓ EPÍLOGO — GRACE HOPPER DESLIGA O TERMINAL

O laboratório está quase vazio.

Nosso jovem COBOLzeiro continua olhando para o z17.

No começo do dia ele enxergava:

MAINFRAME
    =
  COBOL

Agora enxerga:

                    IBM z17
                       │
          ┌────────────┼────────────┐
          │            │            │
     TRANSAÇÕES       DADOS         IA
          │            │            │
        CICS          Db2        MODELOS
          │            │            │
        COBOL          MQ         AGENTES
          │            │            │
        RACF          APIs      GUARDRAILS
          │            │            │
          └────────────┼────────────┘
                       │
                 ENTERPRISE
                  COMPUTING

Grace Hopper pega o quepe.

Antes de sair, olha uma última vez para o estudante.

— Agora você entendeu?

— Acho que sim.

— Então me diga: para que serve o z17?

Ele pensa alguns segundos.

Não responde “COBOL”.

Não responde “IA”.

Não responde “banco”.

Finalmente diz:

— Para resolver problemas grandes onde desempenho, dados, segurança, confiabilidade e controle importam.

Grace sorri.

— Agora você começou a entender mainframe.

Ela caminha em direção à porta.

O estudante volta ao terminal.

Na tela aparece:

AGENT-004 ABENDED

Ele grita:

— Almirante! Temos um bug!

Grace Hopper para.

Olha lentamente para trás.

— Já procurou a mariposa?

***************************************
*                                     *
*          END OF JOB - RC=0000       *
*                                     *
***************************************

Quase quarenta anos separam o IBM 3090 instalado na Marist em 1988 do IBM z17 que aparece em Donnelly Hall em 2026.

Os computadores mudaram.

As linguagens mudaram.

As interfaces mudaram.

Os problemas ficaram maiores.

Mas aquela velha curiosidade de Grace Hopper continua perfeitamente atual:

não pergunte apenas como usar a máquina.

Pergunte:

“O que mais podemos fazê-la fazer?”

E talvez essa seja justamente a grande lição escondida dentro daquele z17 da Marist.

O mainframe não chegou ao futuro tentando continuar vivendo em 1988.

Ele chegou ao futuro porque continuamos encontrando problemas novos suficientemente difíceis para precisarmos dele outra vez.

☕⚓🦖🤖

Um Café no Bellacosa Mainframe.

Para saber mais

https://www.marist.edu/w/marist-ibm-z17-news-release?utm_source=chatgpt.com

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