☕ 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

Mostrar mensagens com a etiqueta devops. Mostrar todas as mensagens
Mostrar mensagens com a etiqueta devops. Mostrar todas as mensagens

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.

quarta-feira, 23 de setembro de 2026

🐷 A FÁBULA DOS PORCOS ASSADOS NO MAINFRAME

 

Bellacosa Mainframe entre porcos e computadores visoes do sistema legado

☕ Um Café no Bellacosa Mainframe

🐷 A FÁBULA DOS PORCOS ASSADOS NO MAINFRAME

Ou: como uma empresa construiu 47 subsistemas, 312 jobs, 18 filas de MQ e uma War Room para continuar incendiando a floresta

Era uma vez uma enorme empresa que possuía um mainframe.

Ninguém sabia exatamente quando o primeiro programa havia entrado em produção.

Alguns diziam 1974.

Outros juravam ter encontrado um comentário COBOL contendo:

* ALTERADO EM 12/08/1969 - J.SILVA

Mas ninguém tinha coragem de investigar aquilo profundamente.

O importante era que o mainframe funcionava.

E dentro daquele mainframe existia o mais importante sistema corporativo da empresa:


🐷 O SISTEMA DE ASSAR PORCOS

A história começara décadas antes.

Certo dia, um incêndio acidental atingiu uma floresta próxima ao Data Center.

Havia porcos na floresta.

Quando o incêndio terminou, descobriram que os porcos haviam sido assados.

E estavam deliciosos.

Um programador teve então uma ideia:

— Quando precisarmos de porcos assados, podemos incendiar outra floresta.

Funcionou.

Foi criado o primeiro procedimento operacional:

PROC-PORCO-001 — Procedimento para Incêndio Controlado de Floresta para Produção de Porcos Assados.

Durante algum tempo, tudo correu maravilhosamente.

Quando alguém queria porco assado:

  1. colocavam os porcos na floresta;

  2. incendiavam a floresta;

  3. esperavam;

  4. recolhiam os porcos;

  5. serviam o jantar.

Era simples.

Até a empresa crescer.



🖥️ A INDUSTRIALIZAÇÃO DO PORCO

O número de clientes aumentou.

Agora não eram dez porcos.

Eram dez mil.

Foi necessário automatizar o processo.

Um programador COBOL escreveu:

PORC001

Outro criou:

PORC002

Depois vieram:

PORC003

PORC003A

PORC003B

PORC003B2

e finalmente:

PORC003B2N

Ninguém sabia onde estava PORC003B1.

Mas havia referências a ele em três copybooks.

Por segurança, ninguém mexia.

O processo passou a ser executado pelo JES2.

Às 22:00:

JOB PORCO01

selecionava os animais.

Às 22:30:

JOB FLOREST1

identificava uma floresta disponível.

Às 23:00:

JOB FIRE001

iniciava o incêndio.

À 01:00:

JOB ASSADO1

calculava o grau provável de cozimento.

Às 03:17, invariavelmente, alguma coisa dava errado.

Então começava a War Room.



🔥 O PRIMEIRO INCIDENTE

Certa madrugada, metade dos porcos saiu crua.

A outra metade virou carvão.

Foi declarado:

SEV1 — CRITICAL INCIDENT

Trinta e sete pessoas entraram na conferência.

— É COBOL?

— Não.

— É CICS?

— Não.

— Db2?

— Normal.

— MQ?

— Algumas filas estão crescendo.

— CPU?

— 43%.

— WLM?

— Dentro da política.

— Storage?

— Normal.

Finalmente alguém perguntou:

— E o fogo?

Silêncio.

Ninguém da reunião pertencia à equipe responsável pelo fogo.

Foi necessário abrir um chamado.

INC00473192

A equipe respondeu:

FIRE SYSTEM OPERATING AS DESIGNED.

O incidente foi encerrado como:

ROOT CAUSE UNKNOWN.



🐷 CRIA-SE A ENGENHARIA DE PORCOS

A direção decidiu que aquilo jamais poderia acontecer novamente.

Foi criado o departamento de:

Enterprise Pig Roasting Architecture — EPRA.

O departamento estabeleceu padrões.

Agora cada porco precisava possuir:

  • PIG-ID;

  • peso;

  • idade;

  • raça;

  • temperatura inicial;

  • floresta de destino;

  • horário de entrada;

  • previsão de cozimento;

  • classificação de criticidade.

Foi criado um banco Db2.

TB_PORCO
TB_FLORESTA
TB_INCENDIO
TB_ASSAMENTO
TB_TEMPERATURA
TB_PORCO_FLORESTA

Um arquiteto observou que TB_PORCO_FLORESTA possuía uma relação N:N problemática.

Foram necessárias seis reuniões.

Enquanto isso, os porcos continuavam queimando.


📊 OBSERVABILIDADE

Alguém afirmou:

— O problema é falta de observabilidade.

Todos concordaram.

Foram instalados sensores.

Dashboards.

Métricas.

Logs.

Tracing.

Alertas.

Agora era possível saber em tempo real:

PIGS_PER_SECOND

MEAN_TIME_TO_ROAST

FOREST_BURN_RATE

AVERAGE_PIG_TEMPERATURE

PIG_ERROR_RATE

CARBONIZED_PIG_PERCENTAGE

Um enorme monitor foi colocado no NOC.

Quando um porco queimava demais, uma linha ficava vermelha.

Os executivos ficaram impressionados.

— Agora temos visibilidade!

Os porcos continuavam queimando.

Mas agora isso podia ser acompanhado num dashboard.


☁️ A MODERNIZAÇÃO

Chegou então um consultor.

Depois de analisar a arquitetura durante três semanas, apresentou 186 slides.

O primeiro dizia:

DIGITAL PIG TRANSFORMATION

A conclusão era clara:

o problema estava no legado.

Era necessário modernizar.

O COBOL PORC001 foi encapsulado por uma API REST.

Agora era possível incendiar a floresta utilizando:

POST /api/v1/pigs/roast

Payload:

{
  "pigId": "0004711",
  "forest": "F023",
  "roastingLevel": "MEDIUM"
}

A API chamava z/OS Connect.

Que chamava CICS.

Que chamava COBOL.

Que gravava Db2.

Que publicava MQ.

Que finalmente executava:

INCENDIAR FLORESTA.

O CIO apresentou o projeto numa conferência:

“Transformamos nosso processo tradicional de produção de alimentos em uma plataforma API-first.”

Todos aplaudiram.

Os porcos continuavam sendo assados incendiando florestas.


☁️🐷 PORCOS NA CLOUD

Um novo estudo concluiu que o problema era outro.

A floresta estava on-premises.

Foi criado então:

Hybrid Cloud Pig Roasting Architecture.

O cadastro dos porcos foi para a cloud.

O sistema de incêndio permaneceu no mainframe.

Kafka transmitia eventos:

PIG_ENTERED_FOREST

FOREST_IGNITED

PIG_TEMPERATURE_CHANGED

PIG_ROASTED

PIG_OVERCOOKED

Um Data Lake armazenava vinte anos de telemetria de porcos queimados.

Machine Learning começou a prever quais porcos provavelmente seriam carbonizados.

A precisão chegou a 94%.

Um executivo perguntou:

— E conseguimos evitar que eles queimem?

O cientista de dados respondeu:

— Ainda não. Mas conseguimos prever com excelente precisão quais irão queimar.

O projeto recebeu um prêmio de inovação.


🤖 CHEGA A INTELIGÊNCIA ARTIFICIAL

Em 2026 surgiu a grande esperança.

IA Generativa.

Foi criado:

PigGPT Enterprise Edition.

A IA recebeu documentação, runbooks, logs, dumps, métricas SMF e quarenta anos de incidentes.

Perguntaram:

— Como melhorar o sistema de assar porcos?

A IA respondeu:

“Talvez seja possível assar os porcos diretamente utilizando uma fonte controlada de calor, sem incendiar uma floresta inteira.”

A resposta foi classificada como:

LOW CONFIDENCE / REQUIRES HUMAN VALIDATION

Um comitê de governança de IA foi convocado.

Após oito reuniões decidiu-se que a sugestão representava risco arquitetural porque não respeitava o processo corporativo estabelecido.


👨‍💻 JOÃO BOM-SENSO ENTRA NO CPD

Foi então que apareceu João.

João era programador COBOL.

Não era Distinguished Engineer.

Não era Enterprise Architect.

Não possuía certificação em transformação digital de porcos.

Ele estava apenas acompanhando um incidente.

Olhou os diagramas.

Olhou os jobs.

Olhou os dashboards.

Olhou os milhares de linhas COBOL.

Olhou Kafka.

Olhou MQ.

Olhou Kubernetes.

Olhou o Data Lake.

Depois perguntou:

— Por que vocês incendeiam uma floresta inteira?

A sala ficou silenciosa.

Um arquiteto respondeu:

— Para assar os porcos.

— Sim. Mas por que não fazemos uma pequena fogueira e colocamos o porco sobre ela?

Silêncio.

Alguém desligou o microfone.

Outro escreveu no chat privado:

“Quem convidou esse cara?”


🧪 A PROVA DE CONCEITO

João pegou um porco.

Algumas brasas.

Uma grelha.

Esperou.

O porco ficou perfeitamente assado.

Nenhuma floresta foi incendiada.

Nenhum batch foi executado.

Nenhuma mensagem MQ.

Nenhuma chamada REST.

Nenhum evento Kafka.

Nenhum Data Lake.

Nenhum SEV1.

Custo operacional:

quase zero.

O resultado foi apresentado à direção.

Por alguns segundos João acreditou que seria promovido.

Então começaram as perguntas.

— E o departamento de Engenharia de Incêndios?

— Não precisaria mais existir dessa forma.

— E nossos especialistas certificados em Propagação Florestal?

— Também não.

— E os 312 jobs?

— Poderíamos desativá-los.

— E nosso contrato de observabilidade?

— Grande parte deixaria de ser necessária.

— E o Data Lake?

— Continuaria existindo para outras coisas.

— E os vinte anos de dados históricos de incêndios?

— Seriam históricos.

— E nossa API?

— Provavelmente desnecessária para isso.

— E Kafka?

— Para assar um porco?

João começou a perceber o problema.

Ele não estava propondo apenas uma grelha.

Estava propondo destruir um ecossistema.


🏢 O SISTEMA NÃO ERA MAIS O SISTEMA

Durante cinquenta anos a empresa construíra organizações inteiras ao redor do método de incendiar florestas.

Existiam:

engenheiros de incêndio;

analistas de capacidade de incêndio;

DBAs especializados em tabelas de porcos;

operadores de batch;

especialistas em temperatura;

arquitetos de integração;

consultores;

auditores;

fornecedores;

contratos;

KPIs;

SLAs;

certificações;

procedimentos;

comitês;

diretorias.

O objetivo original havia sido:

assar porcos.

Mas lentamente o objetivo transformara-se em:

operar eficientemente o Sistema Corporativo de Incêndio de Florestas.

Essa diferença parecia pequena.

Não era.

Era gigantesca.


🧠 O DIRETOR EXPLICA A REALIDADE

O diretor chamou João.

— Sua ideia é interessante.

João sorriu.

— Obrigado.

— Mas você não compreende toda a complexidade.

João parou de sorrir.

O diretor mostrou o organograma.

Centenas de pessoas dependiam daquele processo.

Havia contratos plurianuais.

Depreciação de ativos.

Compliance.

Auditoria.

Treinamentos.

Orçamento.

Fornecedores.

Roadmaps.

Projetos estratégicos.

— Você está olhando apenas para o problema técnico — explicou o diretor.

João respondeu:

— Eu estou olhando para o porco.

O diretor respirou fundo.

— Exatamente. Esse é o problema.


🐷 O PORCO ESQUECIDO

Naquela noite João caminhou pelo Data Center.

Passou pelos enormes computadores.

Viu os painéis.

Os dashboards.

As luzes.

Os gráficos.

Tudo extraordinariamente sofisticado.

Então percebeu algo.

A organização sabia medir praticamente tudo.

Sabia quantas árvores queimavam.

Quanto combustível utilizava.

Quanto tempo levava.

Quantos processadores consumia.

Quantas mensagens trafegavam.

Quantos incidentes aconteciam.

Quanto custava cada floresta.

Mas havia uma pergunta que quase ninguém fazia:

“Ainda precisamos fazer isso dessa maneira?”

Essa pergunta não aparecia no SMF.

Não estava no RMF.

Não aparecia no Splunk.

Não existia no Grafana.

Não estava no Jira.

Não havia campo para ela no ServiceNow.

Porque nenhum sistema de observabilidade consegue detectar sozinho que o próprio processo observado deixou de fazer sentido.


☕ EPÍLOGO — O VERDADEIRO LEGADO

E aqui está a armadilha.

Legado não é COBOL.

Legado não é mainframe.

Legado não é VSAM.

Legado não é CICS.

Um programa COBOL com cinquenta anos que executa perfeitamente uma função necessária pode ser uma extraordinária peça de engenharia.

Enquanto isso, um microsserviço escrito ontem pode nascer legado se automatizar brilhantemente uma coisa que ninguém deveria continuar fazendo.

Modernização verdadeira não significa trocar:

COBOL → Java

ou:

MAINFRAME → CLOUD

ou:

BATCH → KAFKA

A pergunta anterior é muito mais importante:

POR QUE ESTE PROCESSO EXISTE?

Depois:

QUAL PROBLEMA ELE RESOLVE?

Depois:

AINDA PRECISAMOS RESOLVÊ-LO?

E somente então:

QUAL É A MELHOR TECNOLOGIA?

Porque você pode colocar uma API REST na frente do incêndio.

Pode publicar o incêndio no Kafka.

Pode executar o controle do incêndio em containers.

Pode armazenar os incêndios num Data Lake.

Pode usar IA para prever incêndios.

Pode criar dashboards espetaculares mostrando incêndios em tempo real.

E pode chamar tudo isso de transformação digital.

Mas...

se para conseguir um simples porco assado você ainda precisa incendiar uma floresta inteira,

talvez o problema nunca tenha sido o COBOL.

Talvez o problema seja que, em algum momento dos últimos cinquenta anos,

todo mundo começou a cuidar do SISTEMA e ninguém mais perguntou pelo porco.


🥚 EASTER EGG DO OPERADOR

Dizem que até hoje, exatamente às 03:17, existe um job desconhecido no scheduler:

JOB PORK999

Ninguém sabe quem o criou.

Ele executa apenas:

IF FLORESTA-EM-CHAMAS
    DISPLAY 'MAS POR QUE?'
END-IF.

O programa possui somente um comentário:

*> J.BOM-SENSO - NAO REMOVER.

Ninguém remove.

Afinal...

é legado.

Inspirado em fabula dos porcos Juício a La Escuela Cirigliano, Forcade Tilich Editorial Editorial Humanitas – Buenos Aires, 1974

terça-feira, 15 de setembro de 2026

🧟 Mainframe Evolution — O Pesadelo Open Source que Entrou na LPAR

 

Bellacosa Mainframe e o Mainframe Evolution

☕ Um Café no Bellacosa Mainframe

🧟 Mainframe Evolution — O Pesadelo Open Source que Entrou na LPAR

Segurança, observabilidade e escala no IBM Z, investigadas sob a ótica de Dylan Dog, o Investigador do Pesadelo



Há casos que chegam ao escritório de Dylan Dog embrulhados em jornais velhos, acompanhados por fotografias borradas e pelo depoimento de alguma testemunha dizendo ter visto uma criatura impossível atravessar a parede à meia-noite.

Este caso chegou de maneira ainda mais suspeita.

Em uma apresentação apareceu a frase:

Mainframe Evolution: Securing, Monitoring, and Scaling with Next-Gen Open Source

Dylan olhou para o papel.

Groucho olhou para Dylan.

— Chefe, acho que descobriram algo mais antigo que os vampiros.

— O quê?

— COBOL.

Silêncio.

Em algum lugar distante, uma fita magnética girou sozinha.

Bem-vindo a mais uma investigação do Bellacosa Mainframe.

Desta vez nosso cliente afirma que existe open source dentro do mainframe.

Para muitos programadores, isso parece perfeitamente normal em 2026.

Para outros, principalmente aqueles que ainda imaginam o mainframe como uma fortaleza isolada onde todos entram pelo TSO e qualquer alteração precisa de três formulários, dois CABs e o sangue de um analista de produção, a afirmação parece paranormal.

Dylan Dog foi chamado.

Vamos investigar.



🕵️ CAPÍTULO 1 — O cadáver que se recusava a morrer

A primeira coisa que chamou a atenção de Dylan foi a idade da vítima.

O mainframe já havia sido declarado morto tantas vezes que seu prontuário parecia uma coleção de obituários.

Client/server iria matá-lo.

Depois Unix.

Depois Windows.

Depois servidores x86.

Depois Java.

Depois a Web.

Depois cloud.

Depois containers.

Depois Kubernetes.

Agora inteligência artificial.

Dylan abriu o arquivo.

STATUS: EXECUTING.

— Estranho — comentou ele.

Muito estranho.

Talvez estivéssemos procurando o cadáver errado.

Porque o IBM Z moderno não é simplesmente um computador gigantesco escondido no porão executando programas COBOL escritos quando os Beatles ainda tocavam juntos.

Ele é uma plataforma capaz de reunir tecnologias de gerações muito diferentes.

Podemos encontrar algo parecido com:

                 IBM Z
                   │
        ┌──────────┼──────────┐
        │          │          │
       z/OS       Linux      z/VM
        │          │          │
      COBOL      Python    Virtualização
      CICS       Java
      IMS        Open Source
      Db2        Containers
      MQ

A primeira pista estava diante de Dylan.

Talvez evolução do mainframe não significasse substituição.

Significasse incorporação.



🧟 CAPÍTULO 2 — Frankenstein não precisava morrer

Existe uma velha tentação em tecnologia.

Quando encontramos algo antigo, imediatamente pensamos:

"Precisamos substituir isso."

Imagine um banco possuindo milhões de linhas COBOL responsáveis por contas, cartões, pagamentos, empréstimos e liquidação financeira.

Alguém entra na reunião e anuncia:

— Temos uma ideia revolucionária! Vamos reescrever tudo!

Dylan provavelmente perguntaria:

— Por quê?

Essa é uma excelente pergunta.

Modernização não significa obrigatoriamente:

COBOL
  ↓
Java

Muito menos:

MAINFRAME
   ↓
CLOUD

Podemos modernizar ao redor da aplicação:

               Git
                │
VS Code ───► COBOL ◄─── CI/CD
                │
             Testing
                │
          Security Scan
                │
              APIs
                │
         Observability

O programa continua COBOL.

A lógica continua executando no z/OS.

CICS continua administrando transações.

Db2 continua guardando dados.

RACF continua controlando acessos.

Mas a maneira como desenvolvemos, testamos, implantamos, observamos e integramos essas aplicações pode mudar radicalmente.

Nosso monstro de Frankenstein não precisava ser destruído.

Precisávamos apenas entender como ele funcionava.



🔐 CAPÍTULO 3 — SECURING: alguém abriu novas portas no castelo

Dylan chegou à primeira cena do crime.

Uma enorme fortaleza.

Sobre o portão estava escrito:

RACF

Nada particularmente assustador.

O mainframe conhece controle de acesso há décadas.

Usuários possuem identidades.

Recursos possuem regras.

Datasets podem ser protegidos.

Transações CICS podem ser protegidas.

Recursos do sistema podem ser protegidos.

Aplicações podem ser protegidas.

Então apareceu o open source.

Depois vieram APIs.

CLI.

VS Code.

Git.

Jenkins.

Zowe.

Containers.

OpenShift.

Linux.

Cloud.

Service accounts.

Automação.

De repente, nosso castelo ganhou dezenas de portas.

                    IBM Z
                      │
     ┌────────────────┼────────────────┐
     │                │                │
    API              CLI             IDE
     │                │                │
 Jenkins            Zowe            VS Code
     │
   CI/CD

Nenhuma dessas tecnologias é inerentemente um problema.

O problema aparece quando adicionamos conectividade sem adicionar governança.



👻 CAPÍTULO 4 — O fantasma das credenciais

Groucho apareceu segurando um papel.

— Dylan, encontrei a senha.

— Onde?

— No script.

Isso é exatamente o tipo de fantasma que ninguém quer encontrar.

Imagine:

USER=DEPLOY01
PASSWORD=SUPERSECRET123

dentro de um script versionado.

Ou um token esquecido em um arquivo de configuração.

Ou uma service account com privilégios maiores que o necessário.

Automação multiplica produtividade.

Mas também pode multiplicar erros.

Um humano pode cometer um erro uma vez.

Um pipeline consegue cometer o mesmo erro automaticamente quinhentas vezes antes do café.

Por isso modernização exige pensar em:

Identity
Authentication
Authorization
Certificates
TLS
Secrets
Tokens
Audit
Least Privilege
API Security
Logging

O velho princípio continua válido:

Quem é você, o que você pode fazer e quem registrará que você fez?

RACF não ficou obsoleto porque apareceu DevOps.

Na verdade, DevOps torna essas perguntas ainda mais importantes.



🧪 CAPÍTULO 5 — Zowe entra na investigação

Dylan encontrou outra inscrição:

ZOWE

Aqui encontramos uma das pontes mais interessantes entre o mainframe tradicional e ferramentas modernas.

Imagine nosso jovem programador COBOL.

Ele conhece:

Git
VS Code
Terminal
REST
JSON
CLI

Então alguém apresenta:

TSO
ISPF
SDSF
JCL
3270

Nada disso é ruim.

Mas existe uma curva de aprendizagem.

Uma proposta importante do Zowe é permitir interfaces familiares ao desenvolvedor moderno para interação com o ecossistema z/OS.

Simplificando bastante:

VS Code ──────┐
              │
CLI ──────────┤
              │
REST ─────────┼──► Zowe ───► z/OS
              │
Scripts ──────┤
              │
Automation ───┘

Isso não significa abolir ISPF.

Nem significa transformar z/OS em Linux.

Significa criar novas maneiras de conversar com a plataforma.

Dylan anotou:

O suspeito não destruiu a porta antiga. Construiu outra entrada.


👁️ CAPÍTULO 6 — MONITORING: o mainframe sempre esteve olhando

Aqui nossa investigação fica especialmente interessante.

O mundo distribuído descobriu recentemente uma palavra maravilhosa:

observability.

Logs!

Metrics!

Traces!

Dashboards!

Alertas!

Dylan quase sorriu.

Porque no porão do mainframe encontrou arquivos muito mais antigos:

SMF
RMF
SYSLOG
OPERLOG
WLM
CICS Statistics
Db2 Accounting
IMS Logs
MQ Statistics

O mainframe sempre produziu uma quantidade extraordinária de informações operacionais.

Então qual é a novidade?

Correlação.


🔎 CAPÍTULO 7 — O cliente não sabe o que é uma LPAR

Imagine Maria pagando R$100 usando o celular.

Para ela:

CELULAR
  ↓
PAGAMENTO

Simples.

Agora acompanhemos o que pode acontecer por trás:

Mobile App
    ↓
Internet
    ↓
API Gateway
    ↓
OpenShift
    ↓
Java
    ↓
MQ
    ↓
z/OS Connect
    ↓
CICS
    ↓
COBOL
    ↓
Db2

Maria liga:

— Meu pagamento demorou.

Ela não diz:

"Observei um aumento no response time da transaction class associada ao CICS."

Seria fantástico se dissesse.

Mas não diz.

Ela quer saber por que o botão demorou.

A empresa precisa investigar a transação inteira.

Esse é o grande salto entre simplesmente monitorar componentes e observar serviços distribuídos.


🔦 CAPÍTULO 8 — A lanterna chamada Trace ID

Dylan coloca uma etiqueta na vítima:

TRACE-ID: BELLACOSA-0317

Agora imagine essa identificação acompanhando a solicitação:

APP
 │
 │ 0317
 ▼
API
 │
 │ 0317
 ▼
OPENSHIFT
 │
 │ 0317
 ▼
MQ
 │
 │ 0317
 ▼
CICS
 │
 │ 0317
 ▼
COBOL
 │
 │ 0317
 ▼
DB2

Agora temos uma investigação de verdade.

Podemos descobrir:

APP            120 ms
API             80 ms
OPENSHIFT       90 ms
MQ              40 ms
CICS            70 ms
COBOL           20 ms
DB2           3.900 ms

A aplicação demorou aproximadamente 4,3 segundos.

E finalmente encontramos o suspeito.

Não era COBOL.

Era uma consulta no banco.

O pobre COBOL estava sendo acusado porque morava no bairro errado.


🩸 CAPÍTULO 9 — OpenTelemetry encontra SMF

Aqui existe uma possibilidade particularmente fascinante.

De um lado temos o universo tradicional:

SMF
RMF
WLM
CICS
Db2
IMS
MQ

Do outro:

OpenTelemetry
Prometheus
Grafana
Elastic
OpenSearch
Jaeger

Historicamente eles podem parecer dois mundos.

Mas uma aplicação empresarial moderna pode atravessar ambos.

Portanto, o verdadeiro objetivo passa a ser:

             BUSINESS TRANSACTION
                     │
       ┌─────────────┴─────────────┐
       │                           │
 DISTRIBUTED WORLD             MAINFRAME
       │                           │
 OpenTelemetry                   SMF
 Prometheus                      RMF
 Containers                      WLM
 Kubernetes                      CICS
 APIs                            Db2
       │                           │
       └─────────────┬─────────────┘
                     │
               OBSERVABILITY

Agora podemos começar a responder não apenas:

"A CPU está boa?"

Mas:

"Por que o cliente não conseguiu concluir a compra?"

Essa segunda pergunta vale dinheiro.


📈 CAPÍTULO 10 — SCALING: o monstro começou a crescer

Nosso terceiro mistério é escala.

Alguém poderia dizer:

— Finalmente Kubernetes ensinará mainframe a escalar!

Nesse momento talvez Dylan pedisse para Groucho retirar a pessoa da sala.

Mainframes foram construídos justamente para executar workloads enormes.

z/OS possui uma longa história de administração sofisticada de workloads.

Temos conceitos como:

LPAR
WLM
Parallel Sysplex
Coupling Facility
Capacity
Workload Management

O que mudou foi o ambiente ao redor.

Imagine:

               INTERNET
                   │
             LOAD BALANCER
                   │
          ┌────────┼────────┐
          │        │        │
         POD      POD      POD
          │        │        │
          └────────┼────────┘
                   │
                  MQ
                   │
                CICS
                   │
                COBOL
                   │
                 DB2

Kubernetes pode aumentar pods.

Ótimo.

Mas isso não significa capacidade infinita.


☠️ CAPÍTULO 11 — O horror do autoscaling cego

Aqui mora um monstro interessante.

Suponhamos:

3 PODS

O sistema detecta carga elevada.

Então:

3 → 6 → 12 → 24 → 48 PODS

Fantástico!

Exceto que todos atacam o mesmo backend.

48 PODS
   │
   │
   ▼
   MQ
   │
   ▼
  CICS
   │
   ▼
  DB2

Escalar frontend sem compreender backend pode simplesmente produzir um ataque DDoS patrocinado pela própria empresa.

Essa é uma das grandes lições de arquitetura híbrida.

Precisamos compreender:

  • throughput;

  • concorrência;

  • filas;

  • limites;

  • CPU;

  • I/O;

  • locks;

  • conexões;

  • response time;

  • prioridades;

  • capacidade do backend.

Escalabilidade não significa "crie mais coisas".

Significa administrar capacidade do sistema completo.


🐧 CAPÍTULO 12 — Há um pinguim no porão

Dylan ouviu um barulho.

Desceu mais um andar.

Encontrou Linux.

Sim, Linux no mainframe.

Essa confusão ainda existe:

MAINFRAME = z/OS

Não exatamente.

IBM Z pode hospedar diferentes ambientes e workloads.

Podemos pensar conceitualmente em:

IBM Z
 │
 ├── z/OS
 │    ├── COBOL
 │    ├── CICS
 │    ├── IMS
 │    └── Db2
 │
 ├── Linux on Z
 │    ├── Java
 │    ├── Python
 │    └── Open Source
 │
 └── Virtualização
      ├── z/VM
      └── outros ambientes suportados

Isso muda completamente a imagem mental de "computador antigo".

O hardware permanece centralizado e extremamente robusto.

O ecossistema de software, entretanto, tornou-se bastante heterogêneo.


🔧 CAPÍTULO 13 — DevOps encontra COBOL

Nosso programador iniciante agora recebe uma missão.

Modificar:

CUSTOMER.cbl

No fluxo tradicional poderia acontecer:

ISPF
 ↓
EDIT
 ↓
JCL
 ↓
COMPILE
 ↓
LINK
 ↓
TEST

Esse fluxo continua perfeitamente válido em muitos ambientes.

Mas podemos criar:

VS Code
   ↓
Git
   ↓
Commit
   ↓
Pull Request
   ↓
Automated Build
   ↓
Unit Test
   ↓
Security Scan
   ↓
Deploy
   ↓
Monitoring

Observe o detalhe.

Em nenhum momento fomos obrigados a escrever:

rm CUSTOMER.cbl

O COBOL continua lá.

Mudamos o software delivery lifecycle.

Essa diferença é fundamental.


🧠 CAPÍTULO 14 — O erro clássico: confundir modernização com linguagem

Dylan encontra finalmente uma testemunha.

— Eu vi tudo! Modernizaram o sistema!

— Como?

— Converteram COBOL para Java!

Dylan fecha o bloco de notas.

Isso pode ser modernização.

Mas não é a definição de modernização.

Um programa COBOL pode estar integrado a:

Git
CI/CD
Automated Tests
APIs
Modern IDE
Observability
Security Automation
AI Assistance

Enquanto um programa Java pode viver em:

FTP
manual deployment
no tests
hardcoded passwords
no monitoring
no documentation

Qual dos dois é realmente "legado"?

A linguagem não responde sozinha.

Processo, arquitetura, governança e manutenibilidade importam enormemente.


🕸️ CAPÍTULO 15 — O verdadeiro monstro é a complexidade

Depois de horas investigando, Dylan percebe algo.

Não existe apenas um assassino.

Existe uma teia.

                    USER
                      │
                     APP
                      │
                     API
                      │
                  KUBERNETES
                      │
                      MQ
                      │
               z/OS CONNECT
                      │
                    CICS
                      │
                    COBOL
                      │
                     DB2

Cada camada possui:

Security
Monitoring
Configuration
Capacity
Networking
Logging
Authentication
Authorization
Versioning
Dependencies

É aqui que open source pode ajudar muito.

Mas também é onde ele pode criar problemas se for adotado simplesmente porque "todo mundo usa".

Open source não elimina complexidade.

Às vezes ele democratiza ferramentas para administrá-la.

E às vezes adiciona outra camada.

Arquitetura continua exigindo engenharia.


🧰 CAPÍTULO 16 — O arsenal do Investigador do Pesadelo

Se Dylan Dog fosse engenheiro de plataforma IBM Z, sua mala talvez tivesse:

┌─────────────────────────────┐
│ DYLAN DOG TOOLBOX           │
├─────────────────────────────┤
│ RACF       → Security       │
│ SMF        → Evidence       │
│ RMF        → Performance    │
│ WLM        → Workloads      │
│ SDSF       → Operations     │
│ Zowe       → Integration    │
│ Git        → Versioning     │
│ CI/CD      → Automation     │
│ OTel       → Tracing        │
│ Grafana    → Visualization  │
│ Linux      → Open ecosystem │
└─────────────────────────────┘

Mas ferramentas não resolvem crimes sozinhas.

Precisamos saber que pergunta fazer.


🎓 CAPÍTULO 17 — O novo programador mainframe

Talvez esta seja a maior transformação.

Durante décadas uma trilha de formação poderia começar assim:

3270
 ↓
TSO
 ↓
ISPF
 ↓
JCL
 ↓
COBOL
 ↓
VSAM
 ↓
CICS
 ↓
DB2

Eu ainda ensinaria essa base.

Porque abstração sem fundamento produz profissionais que sabem apertar botões, mas não entendem o que acontece quando o botão falha.

Porém acrescentaria outra coluna:

MAINFRAME CLÁSSICO       ENGENHARIA MODERNA

TSO/ISPF                 VS Code
JCL                      Pipelines
COBOL                    Git
CICS                     APIs
Db2                      Observability
RACF                     IAM concepts
SDSF                     Automation
SMF                      Telemetry
USS                      Open Source

Não são inimigos.

São camadas de conhecimento.

O profissional interessante do futuro sabe atravessar essa ponte.


🧟 CAPÍTULO 18 — E a inteligência artificial?

Naturalmente nosso monstro mais recente aparece.

IA pode ajudar a:

explicar COBOL
gerar documentação
analisar dependências
sugerir testes
interpretar mensagens
auxiliar debugging
explicar JCL
produzir scripts
examinar código legado

Fantástico.

Mas existe uma regra Dylan Dog para isso:

Não confie no monstro apenas porque ele fala educadamente.

Código gerado precisa ser revisado.

JCL precisa ser entendido.

Sugestões precisam ser validadas.

Segurança precisa permanecer sob controle.

Imagine uma IA sugerindo:

PERMIT * CLASS(DATASET) ACCESS(ALTER)

e alguém respondendo:

"A inteligência artificial recomendou."

Nesse momento o verdadeiro terror começou.

IA deve aumentar a capacidade do engenheiro.

Não abolir julgamento técnico.


🕯️ CAPÍTULO 19 — O Easter Egg das 03:17

Às 03:17, todos os dashboards ficaram vermelhos.

CPU?

Normal.

Storage?

Normal.

CICS?

UP.

Db2?

UP.

MQ?

UP.

Kubernetes?

Healthy.

O operador escreveu:

03:17:22 - USERS REPORTING PAYMENT TIMEOUT

Dylan olhou para o dashboard.

Tudo verde.

Olhou novamente para o cliente.

Tudo quebrado.

E finalmente percebeu o verdadeiro pesadelo:

Todos monitoravam componentes. Ninguém monitorava a experiência completa.

O sistema poderia estar tecnicamente saudável enquanto o serviço estava funcionalmente morto.

Essa talvez seja a melhor explicação de por que observabilidade tornou-se tão importante.


🧩 CAPÍTULO 20 — Security + Monitoring + Scaling

Finalmente podemos retornar ao título:

Securing

Garantir que as novas portas abertas pela modernização não destruam décadas de controles.

Monitoring

Sair da visão isolada do componente e compreender a transação ponta a ponta.

Scaling

Fazer ambientes distribuídos e mainframe responderem à demanda sem simplesmente transferir o gargalo de uma camada para outra.

E existe um quarto elemento escondido:

Integrating

Porque todos os anteriores dependem dele.

            MAINFRAME EVOLUTION
                    │
     ┌──────────────┼──────────────┐
     │              │              │
 SECURITY      OBSERVABILITY     SCALE
     │              │              │
     └──────────────┼──────────────┘
                    │
              INTEGRATION
                    │
                OPEN SOURCE
                    │
              AUTOMATION
                    │
                 IBM Z

☕ EPÍLOGO — Dylan fecha o caso

O sol começava a nascer.

Groucho trouxe café.

Dylan fechou a pasta.

Na capa escreveu:

CASE CLOSED?

Depois riscou o ponto de interrogação.

E tornou a colocá-lo.

Porque sistemas nunca ficam realmente prontos.

Eles evoluem.

O ponto central de Mainframe Evolution: Securing, Monitoring, and Scaling with Next-Gen Open Source não precisa ser interpretado como uma guerra entre dois mundos.

Não é:

MAINFRAME
   VS
OPEN SOURCE

Também não é:

OLD
 ↓
DELETE
 ↓
NEW

É algo muito mais interessante:

       60+ ANOS DE ENGENHARIA
                │
                ▼
             IBM Z
                │
      ┌─────────┼─────────┐
      │         │         │
    z/OS      Linux    Open Source
      │         │         │
 COBOL/CICS    Apps      Tools
 Db2/IMS/MQ   Cloud     Automation
      │         │         │
      └─────────┼─────────┘
                │
              APIs
                │
              Git
                │
             CI/CD
                │
         Observability
                │
            Security
                │
               AI
                │
                ▼
       MODERN ENTERPRISE

E isso nos conduz a uma conclusão deliciosa para alguém que trabalha com mainframe.

Durante décadas perguntaram:

"Quando o mainframe vai morrer?"

Talvez a pergunta estivesse errada.

A pergunta mais interessante em 2026 é:

"Quantas tecnologias novas o mainframe ainda conseguirá absorver sem deixar de ser mainframe?"

Até agora, a resposta parece ser:

muitas.

Talvez seja exatamente isso que explique sua longevidade.

O mainframe não sobreviveu apesar das mudanças.

Em boa medida, sobreviveu porque aprendeu a incorporá-las.

Dylan Dog saiu do data center.

As luzes se apagaram.

Uma última mensagem apareceu no console:

IEF404I BELLACOSA - ENDED - TIME=04.17.00

Groucho olhou para a tela.

— Então o monstro morreu?

Dylan vestiu o casaco.

— Não.

— E agora?

Ao fundo, outra mensagem apareceu:

$HASP100 BELLACOSA ON READER

O JOB seguinte acabara de entrar.

☕ Bellacosa Mainframe — porque no mainframe até os fantasmas têm retrocompatibilidade.



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