☕ 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 Sistemas Legados. Mostrar todas as mensagens
Mostrar mensagens com a etiqueta Sistemas Legados. 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.

domingo, 26 de julho de 2026

Lógica de Validação : Quando um Programador COBOL Descobre que o Campo Obrigatório Não Foi Criado para Irritar Usuários... Mas para Evitar que um Banco Inteiro Exploda às 23h59

 

Bellacosa Mainframe e a logica de validação

☕ Um Café no Bellacosa Mainframe

Lógica de Validação sem Mistérios para Programadores COBOL

Quando um Programador COBOL Descobre que o Campo Obrigatório Não Foi Criado para Irritar Usuários... Mas para Evitar que um Banco Inteiro Exploda às 23h59

"Meu nome é COBOL. Enterprise COBOL."

Imagine a cena clássica de um filme de James Bond.

Em algum lugar de Londres, M entrega uma missão.

— Bond, encontramos um programa escrito em RPG III em 1989. Um desenvolvedor júnior pretende remover algumas validações porque "atrapalham a experiência do usuário". Se ele conseguir... centenas de sistemas financeiros poderão produzir dados incorretos durante meses sem que ninguém perceba.

Bond responde calmamente.

— Então o problema não é o código.

— Exatamente. O problema é que ninguém sabe por que aquele código existe.

...

Bem-vindo ao mundo dos sistemas corporativos.

E curiosamente...

Essa história acontece praticamente todos os dias: validações aparentemente simples escondem regras de negócio extremamente sofisticadas.

Para um programador COBOL iniciante, isso representa uma das maiores mudanças de mentalidade da carreira.


O grande erro dos iniciantes

Todo iniciante pensa parecido.

Ele abre um programa COBOL.

Encontra:

IF CLIENTE = SPACES
    DISPLAY "CLIENTE OBRIGATORIO"
    GO TO TELA
END-IF

Primeira reação:

"Isso é simples."

Segunda reação:

"Posso melhorar."

Terceira reação:

"Nem precisa existir."

...

E é exatamente aí que começam os problemas.

Porque talvez esse IF esteja protegendo:

  • faturamento

  • integração

  • impostos

  • compliance

  • auditoria

  • relatórios

  • processamento batch

  • fechamento mensal

Ou seja...

o verdadeiro trabalho nunca foi impedir campo vazio.

O verdadeiro trabalho era proteger todo o restante do sistema.


O efeito James Bond

Nos filmes do 007 existe um detalhe interessante.

Quase nunca o vilão destrói Londres usando uma bomba gigante.

Ele altera uma pequena peça.

Troca um satélite.

Muda um código.

Rouba uma chave.

Troca uma senha.

Depois observa o caos acontecer sozinho.

Nos sistemas corporativos acontece exatamente igual.

Você altera uma validação aparentemente insignificante.

Nada acontece.

Durante dias.

Durante semanas.

Depois...

o fechamento financeiro falha.


O usuário vê uma mensagem.

O sistema vê um contrato.

O artigo explica algo extremamente importante.

Para o usuário existe apenas isto:

Campo obrigatório.

Fim.

Mas internamente aquela mensagem significa:

"Não permita que este registro siga adiante porque cinquenta processos dependem dele."

Essa diferença de perspectiva muda completamente a forma como analisamos software legado.


O iceberg das validações

A tela é apenas a ponta.

Debaixo dela existem dezenas de dependências.

Imagine:

Tela

↓

Programa COBOL

↓

VSAM

↓

DB2

↓

MQ

↓

Interface REST

↓

Batch Noturno

↓

Relatórios

↓

BI

↓

Auditoria

↓

Banco Central

O usuário enxerga:

Campo obrigatório.

O arquiteto enxerga:

Uma cadeia inteira de dependências.

Por que sistemas antigos fazem tantas validações?

Porque durante décadas não existiam:

  • APIs

  • Microservices

  • Gateway

  • Event Broker

  • Kafka

  • Camadas REST

Tudo acontecia dentro do programa.

Logo...

a validação morava exatamente onde os dados entravam.

Na tela.

Esse padrão tornou-se extremamente comum em RPG, COBOL, Natural e PL/I.


O verdadeiro inimigo chama-se "dados ruins"

Programadores novos costumam pensar:

"Erro de compilação é ruim."

Não.

Muito pior é dado errado.

Porque código errado normalmente explode imediatamente.

Dado errado...

pode sobreviver anos.


Imagine:

Cliente cadastrado sem CPF.

Hoje nada acontece.

Amanhã:

batch ignora.

Depois:

faturamento não encontra cliente.

Depois:

impostos errados.

Depois:

auditoria encontra inconsistência.

Depois:

advogados entram.

Tudo começou porque alguém retirou um IF.


O paradoxo da modernização

Outro ponto excelente discutido no artigo.

Modernizar NÃO significa preservar tudo.

Nem apagar tudo.

Modernizar significa entender primeiro.

Depois decidir.

A sequência correta é:

  1. Descobrir a regra.

  2. Entender a regra.

  3. Descobrir quem usa.

  4. Descobrir quem depende.

  5. Só então alterar.

Jamais o contrário.


Um dos maiores perigos: o efeito dominó

Imagine uma peça de dominó.

Você derruba apenas uma.

As outras caem sozinhas.

Validações funcionam exatamente assim.

Uma alteração pequena pode atingir:

  • relatórios

  • integração SAP

  • emissão fiscal

  • XML

  • APIs

  • Data Warehouse

  • Analytics

Nenhuma dessas equipes estava olhando aquela tela.

Mas todas dependiam dela.


James Bond e o Mainframe

Se James Bond trabalhasse num banco...

Q provavelmente lhe entregaria um gadget chamado:

Validator Scanner 9000

Funções:

✓ localizar IF esquecidos

✓ encontrar PERFORM misteriosos

✓ rastrear GO TO perigosos

✓ identificar programas batch impactados

Infelizmente...

na vida real esse gadget chama-se:

Conhecimento.

A IA entra em cena

O artigo mostra um uso extremamente inteligente da IA.

Não para substituir o desenvolvedor.

Mas para acelerar investigação.

Por exemplo.

A IA pode responder rapidamente:

  • Qual campo é validado?

  • Qual mensagem aparece?

  • Qual arquivo recebe update?

  • Qual status muda?

  • Quais programas são chamados?

  • Quais SQL executam?

  • Quais interfaces dependem?

Ela reduz dias de investigação para minutos em muitos casos.


Mas cuidado...

A IA enxerga código.

Ela não enxerga história.

Ela pode dizer:

"Campo obrigatório."

Mas não sabe que:

Em 1997 um cliente perdeu milhões porque esse campo ficou vazio.

Quem sabe isso?

O analista veterano.


O método Bellacosa de investigação

Sempre ensine seu cérebro a pensar nesta sequência:

Etapa 1

Onde está a validação?


Etapa 2

Quem chama?


Etapa 3

Quem grava?


Etapa 4

Quem lê?


Etapa 5

Quem depende?


Etapa 6

O que quebra?


Etapa 7

Ainda faz sentido?


Só depois:

Modificar.


A importância da documentação

Outro excelente ponto.

Quando finalmente descobrimos o motivo daquela validação...

não podemos guardar isso apenas na cabeça.

Transforme em:

  • Wiki

  • Confluence

  • Markdown

  • Obsidian

  • Teste

  • Caso de Uso

Conhecimento que permanece apenas em pessoas desaparece quando elas mudam de projeto ou se aposentam.


O prompt apresentado

O artigo também fornece um excelente modelo para IA.

Ele pede análise sobre:

  • campo

  • condição

  • mensagem

  • regra

  • arquivos

  • programas

  • SQL

  • interfaces

  • batch

  • riscos

  • QA

  • suporte

  • testes

Na prática é quase um checklist de engenharia reversa moderna.


Os cinco agentes secretos da modernização

Desenvolvedor

Descobre como funciona.


Analista

Descobre por quê.


QA

Prova que continua funcionando.


Suporte

Conta todas as tragédias já ocorridas.


Arquiteto

Decide onde essa regra deverá viver daqui para frente.

Cada um possui uma parte da missão.


Curiosidade histórica

Nos anos 1970 e 1980 era comum concentrar praticamente toda a inteligência do negócio dentro do programa COBOL ou RPG.

Não porque fosse "bonito".

Mas porque era o local natural onde os dados entravam.

Décadas depois, APIs, microsserviços e arquiteturas em camadas redistribuíram muitas dessas responsabilidades, mas inúmeras regras continuam preservadas no legado por razões históricas e operacionais.


Easter Egg 007

Existe um paralelo curioso.

Nos filmes do James Bond, M frequentemente diz:

"Confie em seus instintos."

No mainframe existe uma versão melhor:

"Nunca remova um IF antes de descobrir quem escreveu aquele IF."

Porque talvez quem escreveu já tenha resolvido um desastre que nunca foi documentado.


Licença para Refatorar

Bond tinha licença para matar.

O programador moderno deveria possuir outra licença:

Licença para perguntar.

Antes de remover qualquer validação:

  • Quem pediu?

  • Quando surgiu?

  • Qual incidente originou?

  • Existe documento?

  • Existe chamado?

  • Existe histórico?

  • Existe auditoria?

Se ninguém souber responder...

o IF merece respeito.


Conclusão — O verdadeiro agente secreto é a regra de negócio

Todo iniciante imagina que programas COBOL são grandes coleções de IFs antigos, mensagens em maiúsculas e GO TO espalhados pelo código.

Com o tempo, porém, descobre uma verdade muito mais fascinante: cada validação é um pequeno agente secreto infiltrado no sistema. Ela trabalha silenciosamente, impedindo que dados inconsistentes atravessem fronteiras invisíveis e provoquem efeitos em cadeia em faturamento, relatórios, integrações, processamento batch e auditorias.

Modernizar não é eliminar essas sentinelas indiscriminadamente. É investigar sua missão, entender o contexto histórico, confirmar se ainda fazem sentido e decidir o melhor lugar para que continuem protegendo o negócio. A inteligência artificial pode acelerar essa investigação, resumir código e sugerir perguntas relevantes, mas ela ainda depende da experiência humana para interpretar o significado de cada regra e validar seu impacto no mundo real.

No universo Bellacosa Mainframe, a maior lição é simples: um IF aparentemente banal pode valer mais do que milhares de linhas de código moderno, porque ele representa conhecimento acumulado ao longo de décadas. Assim como James Bond salva o mundo antes que a maioria perceba que havia perigo, uma boa validação impede desastres que nunca aparecerão nos relatórios de incidentes justamente porque jamais chegaram a acontecer.

Da próxima vez que encontrar um antigo IF CAMPO = SPACES, não pense apenas em removê-lo. Pense que talvez ele seja o 007 do seu sistema: discreto, elegante, quase invisível... e responsável por impedir que uma catástrofe silenciosa aconteça todos os dias.

Os Três Bugs Invisíveis do Padawan COBOL : Como vencer a hesitação, a ingenuidade e o excesso de confiança

Bellacosa Mainframe e os 3 bugs invisiveis do padawan cobol



☕ Um Café no Bellacosa Mainframe

Os Três Bugs Invisíveis do Padawan COBOL

Como vencer a hesitação, a ingenuidade e o excesso de confiança antes que eles provoquem o primeiro ABEND da sua carreira

"O primeiro programa raramente derruba o banco. O primeiro erro de julgamento, sim."


Introdução

Existe um momento curioso na carreira de praticamente todo programador COBOL.

Não importa se ele estudou durante seis meses, um ano ou cinco anos.

Não importa se tirou certificações IBM.

Não importa se domina PROCEDURE DIVISION, PERFORM VARYING, OCCURS DEPENDING ON, SQL EMBEDDED, CICS ou VSAM.

O verdadeiro teste começa no primeiro dia em produção.

É ali que nasce o verdadeiro programador.

Durante décadas observando profissionais entrando em grandes bancos, seguradoras, empresas aéreas, órgãos públicos e processadoras de cartões, percebi um padrão curioso.

Os novatos quase nunca fracassam por falta de conhecimento técnico.

Eles tropeçam em três inimigos invisíveis.

São eles:

  • Hesitação

  • Ingenuidade

  • Excesso de confiança

Esses três defeitos aparecem em praticamente toda profissão crítica.

Na aviação.

Na medicina.

Na engenharia.

Na investigação criminal.

E, principalmente, em ambientes IBM Mainframe.

O curioso é que eles aparecem em momentos diferentes da evolução profissional.

E quase sempre na mesma ordem.

Hoje vamos investigar cada um deles como se estivéssemos em um episódio de CSI.

Porque um sistema crítico deixa rastros.

E a mente do programador também.


Cena do Crime 1

A Hesitação

Imagine a seguinte situação.

Você acabou de entrar na empresa.

Seu líder diz:

"Precisamos alterar o programa FINA340."

Você abre o programa.

28.000 linhas.

Escrito em 1989.

Última alteração:
há quatro dias.

Autores:

  • João

  • Carlos

  • Equipe Y2K

  • Projeto PIX

  • Open Banking

  • Adequação LGPD

Você olha aquilo.

O cursor pisca.

Cinco minutos.

Dez minutos.

Quinze minutos.

Você simplesmente não consegue tocar em nada.

Isso é completamente normal.


O cérebro entra em modo de sobrevivência

Nosso cérebro odeia destruir algo que parece importante.

Quanto maior a responsabilidade...

Maior a hesitação.

É um mecanismo biológico.

O problema é que hesitação excessiva paralisa.

E um programador parado não aprende.


O primeiro segredo

Veteranos não têm menos medo.

Eles apenas sabem investigar antes.

Essa é uma diferença gigantesca.

O novato pensa:

"Vou alterar."

O veterano pensa:

"Vou entender."


O método Bellacosa

Nunca altere antes de responder:

O que este programa faz?

Quem chama este programa?

Quem ele chama?

Quais arquivos atualiza?

Quais tabelas Db2 altera?

Existe rollback?

Existe commit?

Existe checkpoint?

Existe controle de versão?

Existe scheduler?

Existe impacto batch?

Existe impacto online?

Existe interface MQ?

Existe interface CICS?

Existe API?

Quando todas essas respostas aparecem...

A hesitação desaparece.

Porque ela foi substituída por conhecimento.


Easter Egg

Sherlock Holmes dizia:

"É um erro teorizar antes de possuir os fatos."

Todo programador COBOL deveria colocar essa frase no monitor.


Cena do Crime 2

A Ingenuidade

Depois do primeiro mês...

A hesitação diminui.

Agora nasce outro inimigo.

O iniciante acredita em tudo.

Documentação.

Comentários.

Fluxogramas.

Diagramas.

PowerPoint.

Wiki.

Chamados.

Manuais.


A maior mentira do Mainframe

Imagine encontrar isso:

* Atualiza somente clientes ativos

Bonito.

Organizado.

Profissional.

Mas você olha o código...

MOVE "S" TO WS-ATIVO

Nada mais.

Nenhuma validação.

Nenhuma regra.

Nenhum IF.

O comentário está errado há quinze anos.

Quem escreveu?

Provavelmente alguém que saiu da empresa em 2004.


A documentação envelhece

Código muda.

Documentação nem sempre.

O sistema continua funcionando.

Mas o documento virou arqueologia.

É como encontrar um mapa romano tentando dirigir em São Paulo.


A regra de ouro

Nunca confie totalmente em:

Comentários

Diagramas

Documentação

Fluxogramas

Apresentações

Emails antigos

Confie no comportamento do sistema.

Ele não mente.


Curiosidade

Muitos bancos possuem documentação cuja última atualização ocorreu antes do PIX existir.

O sistema evoluiu.

O documento não.


Cena do Crime 3

O Excesso de Confiança

Esse é o mais perigoso.

Porque normalmente aparece depois dos primeiros sucessos.

Você já resolveu alguns chamados.

Corrigiu ABEND.

Alterou tela CICS.

Fez alguns programas.

Agora pensa:

"Estou dominando."

É aí que mora o perigo.


O efeito Dunning-Kruger no Mainframe

Existe um fenômeno psicológico famoso.

Quanto menos sabemos...

Mais acreditamos saber.

Depois de alguns anos...

Percebemos o tamanho do universo.

É curioso.

O profissional de cinco meses costuma parecer mais confiante que o de vinte anos.

Porque ainda não descobriu tudo o que desconhece.


O veterano faz mais perguntas

O iniciante responde rápido.

O veterano pergunta mais.

Isso parece contraditório.

Mas faz sentido.

O veterano conhece centenas de armadilhas.

Ele sabe que sistemas críticos escondem surpresas.


Exemplo clássico

Você altera:

IF SALDO > 0

Parece simples.

Mas esquece que existe outro programa batch.

Outro online.

Outro scheduler.

Outro MQ.

Outro API Gateway.

Outro processo noturno.

Outro job semanal.

Outro fechamento mensal.

Outro processamento anual.

Seu IF alterou uma cadeia inteira.


O código nunca vive sozinho

Essa talvez seja a maior descoberta da carreira.

Programas COBOL não são ilhas.

São organismos.

Cada programa conversa com dezenas de outros.

Às vezes centenas.

Você altera uma linha.

Pode movimentar uma cidade inteira.


CSI Mainframe

Imagine Gil Grissom entrando no CPD.

Ele nunca começaria perguntando:

"Quem é o culpado?"

Ele perguntaria:

"O que aconteceu primeiro?"

Depois:

"O que mudou?"

Depois:

"Quem foi impactado?"

É exatamente assim que um analista experiente investiga incidentes.


Indiana Jones no Data Center

O código legado lembra uma cidade perdida.

Você entra com uma tocha.

Cada COPYBOOK é uma sala.

Cada PERFORM é um corredor.

Cada CALL é uma porta secreta.

Cada JCL é um mapa.

Cada PROC é um túnel subterrâneo.

E cada alteração pode ativar uma armadilha escondida.

O aventureiro imprudente corre.

O arqueólogo observa.


A Regra dos Cinco "Por Quês"

Sempre pergunte:

Por que isso existe?

Por que foi escrito assim?

Por que não removeram?

Por que ainda funciona?

Por que ninguém mexe nisso?

A quinta resposta normalmente revela uma decisão de negócio esquecida.


O Erro Mais Caro

Não é apagar um arquivo.

Nem provocar um ABEND.

Nem esquecer um END-IF.

O erro mais caro é assumir.

Assumir que entendeu.

Assumir que ninguém usa.

Assumir que é simples.

Assumir que o comentário está correto.

Assumir que aquele campo nunca recebe zeros.

Mainframe odeia suposições.


O Poder da Humildade Técnica

Existe uma frase muito comum entre grandes especialistas IBM.

"Não sei. Vamos verificar."

Observe.

Eles não respondem imediatamente.

Eles investigam.

Essa postura não demonstra fraqueza.

Demonstra maturidade.


O Ritual Bellacosa Antes de Alterar Qualquer Programa

Criei ao longo dos anos um pequeno ritual que evita boa parte dos problemas em produção. Antes de salvar qualquer alteração, faça estas perguntas:

  1. Entendi exatamente qual é o problema de negócio?

  2. Descobri todos os programas envolvidos?

  3. Verifiquei os COPYBOOKs relacionados?

  4. Analisei impactos em Db2, VSAM, CICS ou IMS?

  5. Procurei alterações semelhantes no histórico?

  6. Executei testes com dados normais e dados extremos?

  7. Pensei no que acontece se um campo vier vazio, nulo ou inesperado?

  8. Existe plano de retorno (rollback) caso algo dê errado?

  9. Alguém mais experiente revisou minha lógica?

  10. Eu conseguiria explicar esta alteração para outra pessoa em cinco minutos?

Se alguma resposta for "não", ainda há investigação a fazer.


Os Três Mestres da Carreira

Todo grande profissional aprende a equilibrar três características:

Coragem
Para enfrentar programas enormes sem fugir.

Curiosidade
Para investigar antes de alterar.

Humildade
Para aceitar que sempre existe algo escondido no sistema.

Esses três pilares são muito mais importantes do que decorar todas as instruções do COBOL.


O Último Easter Egg

Na saga Star Wars, Luke Skywalker acreditava que vencer significava lutar melhor.

Yoda ensinou outra coisa.

Primeiro, controlar a própria mente.

Só depois controlar o sabre de luz.

No Mainframe acontece exatamente o mesmo.

O COBOL não é o sabre.

O sabre é apenas uma ferramenta.

O verdadeiro combate acontece dentro da cabeça do programador.

A hesitação precisa ser transformada em investigação.

A ingenuidade precisa ser substituída por validação.

O excesso de confiança precisa dar lugar à disciplina.

Quando isso acontece, nasce um profissional capaz de trabalhar em ambientes onde milhões de transações financeiras, folhas de pagamento, benefícios governamentais, seguros, cartões de crédito e operações bancárias dependem de algumas linhas de código escritas décadas atrás.


Conclusão — O Primeiro Grande Upgrade Não é no Código, é no Programador

No universo Bellacosa Mainframe, costumo dizer que existem dois tipos de iniciantes.

O primeiro acredita que aprender COBOL significa memorizar verbos, comandos, JCLs e utilitários. Ele mede seu progresso pela quantidade de sintaxes que conhece.

O segundo entende que COBOL é apenas a linguagem usada para conversar com um ecossistema gigantesco de regras de negócio, processos, integrações e pessoas. Ele mede seu progresso pela qualidade das perguntas que faz, pela capacidade de investigar antes de modificar e pela prudência ao assumir responsabilidades.

É esse segundo profissional que evolui para analista, arquiteto, líder técnico e mentor.

A verdadeira iniciação de um Padawan Mainframe não acontece quando ele compila seu primeiro programa sem erros. Ela acontece no dia em que percebe que um sistema legado é como um templo antigo: cada rotina foi construída por gerações diferentes, cada COPYBOOK guarda um pedaço da história da empresa e cada linha de código existe por um motivo — mesmo que esse motivo tenha sido esquecido pelo tempo.

Se você conseguir vencer a hesitação sem perder a prudência, abandonar a ingenuidade sem perder a curiosidade e controlar o excesso de confiança sem perder a coragem, terá desenvolvido a característica mais valiosa de todas: o julgamento técnico.

E julgamento técnico não se aprende em um manual. Ele é construído a cada investigação, a cada revisão de código, a cada incidente resolvido e a cada lição deixada por um erro.

No fim das contas, o maior sistema que um programador COBOL precisa aprender a administrar não é o z/OS, o CICS ou o Db2.

É a própria mente. Só quando ela trabalha de forma disciplinada, investigativa e humilde é que o restante do ecossistema Mainframe deixa de parecer um labirinto e passa a revelar sua verdadeira arquitetura. Nesse momento, o Padawan deixa de apenas escrever programas e começa, de fato, a pensar como um guardião dos sistemas que sustentam parte da economia do mundo.

sábado, 25 de julho de 2026

O Código Nunca Foi o Mistério : Quando um Programador COBOL Descobre que Alterar Dez Linhas é Fácil... Difícil é Sobreviver ao Templo Esquecido do Sistema

 

Bellacosa Mainframe na aventura onde o codigo nunca foi o misterio

☕ Um Café no Bellacosa Mainframe

O Código Nunca Foi o Mistério

Quando um Programador COBOL Descobre que Alterar Dez Linhas é Fácil... Difícil é Sobreviver ao Templo Esquecido do Sistema

"Arqueologia não é procurar coisas velhas. É descobrir a história escondida por trás delas."

Se Indiana Jones tivesse escolhido Ciência da Computação em vez de Arqueologia, provavelmente terminaria trabalhando em um grande banco desenvolvendo COBOL.

Pode parecer exagero.

Mas pense comigo.

Indiana nunca encontrava o artefato logo na primeira sala.

Primeiro havia um mapa incompleto.

Depois uma caverna.

Uma armadilha.

Um diário escrito há cinquenta anos.

Um símbolo perdido.

Um templo subterrâneo.

Uma pedra falsa.

Uma ponte quebrada.

E somente depois de horas de investigação ele finalmente colocava as mãos no objeto que havia saído para procurar.

No Mainframe acontece exatamente a mesma coisa.

O gerente chega à sua mesa.

— "É só alterar umas dez linhas."

Você sorri.

Respira.

Abre o ISPF.

E cinco minutos depois percebe que acaba de entrar no equivalente computacional do Templo da Perdição.

Bem-vindo ao verdadeiro trabalho de um desenvolvedor COBOL.


Capítulo 1 — O Mapa Perdido

Todo aventureiro começa com um mapa.

O problema é que, no mundo corporativo, esse mapa quase nunca existe.

Ou pior.

Existe.

Mas foi escrito em 1994.

Em WordPerfect.

Impresso.

Escaneado.

Convertido para PDF.

E armazenado numa pasta chamada:

Documentacao_Final_Versao_Final_2_AgoraVai.pdf

Que obviamente está desatualizada desde 1998.

É nesse momento que o jovem programador descobre uma das maiores verdades da profissão.

O COBOL não é o sistema.

O programa é apenas uma pequena pedra dentro de uma pirâmide construída durante décadas.


Capítulo 2 — O Chicote Não é o COBOL

Muita gente acredita que dominar COBOL significa dominar Mainframe.

É o mesmo que dizer:

"Indiana Jones venceu porque sabia usar um chicote."

Não.

O chicote era apenas uma ferramenta.

O verdadeiro diferencial era compreender:

  • história

  • culturas

  • idiomas

  • símbolos

  • armadilhas

  • comportamento humano

Com COBOL acontece exatamente igual.

Conhecer:

MOVE
ADD
PERFORM
IF
READ
WRITE

é apenas aprender a usar o chicote.

O arqueólogo ainda nem entrou no templo.


Capítulo 3 — A Primeira Porta

Chega o chamado.

Modificar o programa FAT001.

Perfeito.

Onde ele está?

Ninguém sabe.

Começa então a expedição.

Primeira parada:

PDS COBOL

Nada.

Segunda parada.

LIBLOAD

Nada.

Terceira.

JCLLIB

Quarta.

PROCLIB

Quinta.

Scheduler

Somente depois de muito procurar você descobre:

JOBFIN01

↓

PROCFAT

↓

STEP040

↓

PGM=FAT001

Parabéns.

Você encontrou a porta do templo.

Agora começa a aventura.


Capítulo 4 — O Diário do Professor Ravenwood

Indiana Jones sempre encontrava um velho diário.

No Mainframe ele possui outro nome.

JCL.

O JCL é praticamente um diário de viagem.

Ele conta:

  • quem chamou o programa;

  • quais arquivos entram;

  • quais arquivos saem;

  • qual biblioteca foi usada;

  • quais parâmetros chegaram;

  • qual região executa;

  • qual ambiente está sendo utilizado.

Um simples trecho como:

//EXEC PGM=FAT001

parece insignificante.

Mas atrás dele existem dezenas de decisões arquitetônicas tomadas durante décadas.

O JCL responde perguntas que o próprio programa COBOL jamais responderá.


Capítulo 5 — As Pegadas na Poeira

Indiana observava pegadas.

Você observa datasets.

Imagine encontrar:

CLIENTE.GDG(+1)

Quem criou?

Quando?

Qual layout?

Possui compressão?

É VB?

FB?

RECFM?

LRECL?

Existe SORT anterior?

Existe IDCAMS?

Existe IEBGENER?

Cada dataset é uma pegada deixada por alguém que passou antes.

E cada pegada pode revelar uma história completamente diferente.


Capítulo 6 — O Labirinto dos Processamentos

Na imagem analisada, uma das partes mais brilhantes é justamente a existência de dois mundos:

Traitements Amont

e

Traitements Aval.

Pouca gente percebe a importância disso.

Imagine uma corrente.

Sistema A

↓

Sistema B

↓

Sistema C

↓

Sistema D

↓

Seu programa

O problema talvez tenha começado cinco programas antes.

Agora imagine o contrário.

Seu programa

↓

Financeiro

↓

PIX

↓

SPED

↓

Data Warehouse

↓

BI

↓

IA

Alterar um campo pode quebrar seis departamentos.

É como retirar uma pedra da parede de um templo maia.

Talvez nada aconteça.

Ou talvez toda a construção desabe.


Capítulo 7 — A Câmara das Armadilhas

Nos filmes existe sempre uma sala cheia de mecanismos mortais.

No Mainframe essa sala chama-se:

Regras de Negócio

Elas raramente aparecem documentadas.

Você encontra coisas como:

IF UF = "AM"

Por quê?

Silêncio.

Outro exemplo.

IF CODIGO = 37

Por quê?

Ninguém sabe.

Até que um veterano lembra.

— Em 1996 surgiu uma legislação especial.

Pronto.

Você acaba de resolver um mistério de trinta anos.


Curiosidade Bellacosa nº 1

Existe uma frase muito conhecida entre desenvolvedores experientes:

"Todo IF estranho possui uma história triste."

E normalmente ela envolve:

  • imposto;

  • banco central;

  • auditoria;

  • legislação;

  • cliente VIP;

  • bug ocorrido numa madrugada de domingo.


Capítulo 8 — O Cálice Sagrado Chama-se DB2

Muitos iniciantes acreditam que alterar uma tabela significa apenas executar:

ALTER TABLE

Longe disso.

Uma coluna nova pode afetar:

  • índices;

  • packages;

  • plans;

  • RUNSTATS;

  • REORG;

  • BIND;

  • stored procedures;

  • triggers;

  • views;

  • aplicações Java;

  • aplicações .NET;

  • relatórios;

  • APIs REST.

No filme, Indiana precisava escolher o cálice correto.

No Mainframe você precisa alterar a coluna correta.

Escolher errado custa muito mais caro que um filme de Hollywood.


Capítulo 9 — O Reino Invisível do CICS

Durante o dia:

Cliente consulta saldo.

À noite:

Batch recalcula saldo.

São dois mundos completamente diferentes.

Mas compartilham os mesmos dados.

É como duas expedições arqueológicas explorando entradas diferentes do mesmo templo.

Se um explorador mover uma pedra...

O teto pode cair sobre o outro.


Capítulo 10 — O Calendário Maia do Scheduler

Existe uma entidade misteriosa.

Poucos iniciantes lhe dão atenção.

Scheduler.

Ele sabe exatamente:

  • que horas tudo começa;

  • quanto cada JOB demora;

  • quem depende de quem;

  • qual janela operacional existe;

  • qual SLA precisa ser cumprido.

Imagine:

22:00 Recepção

22:30 Validação

23:10 DB2

00:20 COBOL

01:30 SPED

03:40 Banco Central

Você aumenta cinco minutos no processamento.

Agora tudo termina quinze minutos depois.

Às vezes isso significa apenas atraso.

Às vezes significa multa milionária.


Easter Egg nº 1 — A Pedra Rolante

Todo programador COBOL já viveu algo parecido.

Você altera uma linha.

Executa o teste.

Tudo funciona.

Vai para homologação.

Tudo funciona.

Vai para produção.

Então aparece uma "pedra rolante" gigantesca.

Não era seu programa.

Era um JOB executado apenas no último dia útil do mês, usando um parâmetro que ninguém lembrava existir.

A pedra não persegue Indiana Jones apenas no cinema.

Ela também aparece às 02h47 da manhã, durante o fechamento contábil.


Capítulo 11 — A Arqueologia Digital

Talvez a maior habilidade de um desenvolvedor Mainframe não seja programar.

Seja investigar.

Você vira uma mistura de:

  • arqueólogo;

  • historiador;

  • investigador;

  • detetive;

  • matemático;

  • contador;

  • psicólogo;

  • engenheiro.

Cada programa é uma civilização antiga.

Cada comentário:

* NÃO ALTERAR

é uma inscrição hieroglífica.

Cada COPYBOOK é um pergaminho.

Cada PDS é uma biblioteca de Alexandria.

Cada JOB é uma rota comercial entre impérios.


Passo a Passo — Como um Desenvolvedor Experiente Investiga uma Alteração

Antes de escrever qualquer linha de código, siga uma metodologia quase arqueológica:

Etapa 1 — Entenda o requisito

Não aceite frases como:

"É só mudar um IF."

Pergunte:

  • Qual problema de negócio será resolvido?

  • Existe documentação?

  • Quem é o usuário afetado?


Etapa 2 — Localize o programa

  • PDS fonte

  • Load Library

  • Histórico de versões

  • Chamadores

  • Programas chamados


Etapa 3 — Analise o JCL

Verifique:

  • EXEC PGM

  • DD Statements

  • GDGs

  • SYSIN

  • SYSOUT

  • PROCs

  • PARM


Etapa 4 — Descubra os arquivos

Para cada dataset pergunte:

  • Quem gera?

  • Quem consome?

  • Qual layout?

  • Existe versionamento?


Etapa 5 — Analise o banco

  • Tabelas

  • Índices

  • Views

  • Packages

  • Plans

  • Estatísticas

  • SQLs afetados


Etapa 6 — Verifique integrações

Existe:

  • CICS?

  • MQ?

  • Web Services?

  • z/OS Connect?

  • APIs?

  • Batch paralelo?


Etapa 7 — Procure regras escondidas

Nunca confie apenas na documentação.

Leia o código.

Leia comentários antigos.

Converse com analistas.

Converse com usuários.

Muitas regras vivem apenas na memória das pessoas.


Etapa 8 — Teste impacto

Pergunte sempre:

Quem depende disso?

Quem será afetado?

Quem vai perceber?


Curiosidade Bellacosa nº 2

Em muitos bancos existem programas COBOL executando diariamente há mais de quarenta anos.

Alguns foram escritos antes mesmo do nascimento dos desenvolvedores que hoje fazem sua manutenção.

É como entrar em uma tumba egípcia sabendo que o arquiteto original nunca imaginou que alguém, quatro décadas depois, ainda pisaria naquele corredor para instalar uma nova "porta secreta".


Easter Egg nº 2 — O "X" Nunca Marca o Lugar

Nos filmes, o mapa sempre mostra um enorme X indicando o tesouro.

No desenvolvimento corporativo acontece exatamente o contrário.

O chamado diz:

"Alterar o programa FAT001."

Você passa dois dias investigando e descobre que o problema verdadeiro está em:

  • um parâmetro no Scheduler;

  • um SORT que remove registros;

  • um COPYBOOK compartilhado;

  • uma VIEW DB2;

  • um arquivo recebido de outro sistema.

O X nunca marca o lugar certo. A jornada até ele é que revela onde o verdadeiro problema estava escondido.


Conclusão — O Tesouro Não é o Código

Quando iniciamos nossa jornada em COBOL, acreditamos que aprenderemos uma linguagem de programação.

Com o tempo percebemos que aprendemos algo muito maior.

Aprendemos engenharia de sistemas.

O programa COBOL é apenas a ponta visível de um enorme continente tecnológico formado por JCLs, PROCs, Scheduler, Db2, CICS, VSAM, arquivos, integrações, calendários operacionais e regras de negócio acumuladas ao longo de décadas.

É por isso que dois profissionais com o mesmo domínio da sintaxe podem ter desempenhos completamente diferentes. Um conhece os verbos da linguagem; o outro conhece a história do templo, onde estão as armadilhas, quais corredores desabam, onde ficam as passagens secretas e qual pedra jamais deve ser removida.

No universo Bellacosa Mainframe, o verdadeiro desenvolvedor COBOL não é apenas um programador. Ele é um explorador da computação corporativa, alguém que entra diariamente em ruínas digitais construídas por gerações de engenheiros e retorna trazendo o artefato mais valioso de todos: uma alteração segura, compreendida e confiável, capaz de preservar sistemas que movimentam bancos, governos, seguradoras e a economia mundial sem que milhões de usuários sequer percebam que uma aventura aconteceu durante a madrugada.

E, como diria um certo arqueólogo de chapéu e chicote, ao fechar mais um chamado aparentemente simples:

"O código pertence ao sistema... mas o conhecimento pertence a quem teve coragem de explorar o templo inteiro antes de alterar uma única linha."

quarta-feira, 22 de julho de 2026

Voyage to the Bottom of the Legacy System : Quando um Programador COBOL Descobre que as Economias do Mundo Estão Guardadas no Fundo de um Oceano de Código

Bellacosa Mainframe apresenta uma viagem ao fundo dos sistemas legados onde o cobol é o protagonista

☕ Um Café no Bellacosa Mainframe

Voyage to the Bottom of the Legacy System

Quando um Programador COBOL Descobre que as Economias do Mundo Estão Guardadas no Fundo de um Oceano de Código — e Quase Ninguém Ainda Possui o Mapa

Há uma frase que deveria estar impressa na entrada de cada banco, seguradora, fundo de pensão, bolsa de valores e grande instituição financeira do planeta:

“Conheço exatamente cinco pessoas que entendem como as economias do mundo realmente funcionam. Quatro delas estão aposentadas.”

Isso parece uma piada.

Parece exagero de consultor.

Parece uma daquelas frases dramáticas usadas para vender projetos de modernização, inteligência artificial, transformação digital e mais uma tonelada de apresentações em PowerPoint com setas coloridas. Também conhecida por Buzzwords e incentivando o uso de Balas de Prata.

Mas quem já desceu alguns níveis abaixo da interface elegante de um aplicativo bancário sabe que existe algo assustadoramente verdadeiro nessa afirmação.

O dinheiro moderno não repousa em cofres.

Ele repousa em registros.

Os registros repousam em arquivos, tabelas , mensagens, logs, programas e processos.

E boa parte desses processos ainda é executada por sistemas construídos em COBOL, JCL, CICS, IMS, Db2, Adabas, QSAM, VSAM, Assembler, MQ e outras criaturas que vivem nas profundezas do data center.

Para o programador COBOL iniciante, entrar nesse ambiente é como embarcar no submarino Seaview, da série clássica Voyage to the Bottom of the Sea.

Na superfície, tudo parece tranquilo.

O mar está calmo.

Os clientes consultam saldos.

As transferências acontecem.

Os cartões funcionam.

Os investimentos rendem.

As aposentadorias são pagas e nosso velhinhos aposentados felizes saindo das agencias com seu rico dinheiro na algibeira.

Mas, centenas de metros abaixo, existe uma estrutura monumental enfrentando pressão extrema, correntes invisíveis, monstros desconhecidos e compartimentos que ninguém abre desde 1900 e ventania.

E, em algum lugar da sala de máquinas, existe um programa chamado PGMFIN47 que ninguém ousa alterar. Causando tremores, calafrios e insonia na equipe da sustentação e deixando os operadores da produção em alerta vermelho em cada diaria.

Bem-vindo ao fundo do sistema legado.


1. O dinheiro não está no aplicativo

Quando um cliente abre o aplicativo do banco e vê um saldo de R$ 3.457,82, ele imagina que aquele número simplesmente “está lá”.

Mas aquele saldo é o resultado final de uma longa cadeia de decisões (logado e auditado).

Antes de aparecer na tela, ele pode ter passado por:

  • lançamentos de crédito e débito;

  • compensação;

  • reconciliação;

  • bloqueios;

  • tarifas;

  • impostos;

  • juros;

  • arredondamentos;

  • regras contratuais;

  • limites;

  • autorizações;

  • lotes noturnos;

  • eventos em tempo real;

  • ajustes manuais;

  • ordens judiciais;

  • validações antifraude;

  • integração com sistemas externos.

O valor exibido é apenas a ponta do periscópio.

Debaixo da água existe uma frota inteira de programas.

Um simples depósito pode ativar:

IF CONTA-ATIVA
    IF VALOR-DEPOSITO > ZERO
        ADD VALOR-DEPOSITO TO SALDO-CONTA
    ELSE
        MOVE 'VALOR INVALIDO' TO MENSAGEM-ERRO
    END-IF
END-IF

Bonito, simples e didático.

Mas um sistema real dificilmente termina aí.

Talvez a conta esteja bloqueada.

Talvez seja uma conta conjunta.

Talvez o depósito tenha sido realizado após o horário de corte.

Talvez haja incidência tributária.

Talvez exista um limite diário.

Talvez a origem do dinheiro exija análise.

Talvez o cliente esteja sujeito a uma regra antiga preservada por obrigação judicial.

O código começa simples e cresce como o submarino avançando para uma região do oceano onde os mapas ficam cada vez menos confiáveis.


2. O banco não guarda apenas dinheiro: ele guarda regras

Essa é uma das primeiras grandes lições para um programador COBOL iniciante.

Um sistema bancário não é apenas uma calculadora gigante.

Ele é uma máquina de aplicar regras.

Cada produto financeiro contém uma coleção de decisões.

Uma aplicação pode ter:

  • forma de cálculo;

  • taxa;

  • prazo;

  • carência;

  • vencimento;

  • tributação;

  • liquidez;

  • arredondamento;

  • herança;

  • transferência;

  • resgate antecipado;

  • penalidade;

  • exceção.

Essas regras podem ter origem em:

  • leis;

  • contratos;

  • resoluções;

  • circulares;

  • normas internas;

  • decisões judiciais;

  • aquisições;

  • fusões;

  • migrações;

  • acordos comerciais;

  • correções de incidentes antigos.

O programa COBOL é apenas uma das formas pelas quais essas regras foram cristalizadas.

Por isso, uma linha aparentemente estranha pode ser muito mais importante do que parece:

IF DATA-ADESAO < 19940701
    PERFORM CALCULO-ANTIGO
ELSE
    PERFORM CALCULO-NOVO
END-IF

Um iniciante pode pensar:

“Isso está feio. Vou simplificar.”

Só que a data de 1º de julho de 1994 pode estar relacionada a uma mudança monetária, regulatória, contratual ou operacional.

Remover a condição sem compreender sua origem é como abrir uma escotilha externa do submarino porque ela parece enferrujada.

A escotilha pode estar feia.

Mas talvez esteja impedindo o oceano inteiro de entrar.


3. Código não é a mesma coisa que conhecimento

Um programa pode mostrar o que acontece.

Nem sempre mostra por que acontece.

Considere:

IF WS-TIPO-CLIENTE = '09'
    MOVE 0 TO WS-TAXA
END-IF

A sintaxe é fácil.

O comportamento é claro.

Clientes do tipo 09 recebem taxa zero.

Mas por quê?

  • São funcionários?

  • São clientes judiciais?

  • São contas herdadas de outro banco?

  • São contratos especiais?

  • São beneficiários de uma legislação?

  • São contas de teste?

  • São clientes de uma campanha encerrada há vinte anos?

O código não responde automaticamente.

Esse é o ponto central de toda a discussão.

Existe uma diferença entre:

O que o sistema faz

e

Por que o sistema faz

A primeira pergunta pode ser respondida por análise de código.

A segunda exige contexto histórico, regulatório, comercial e humano.

Muitos projetos fracassam porque tratam essas duas perguntas como se fossem iguais.


4. A tripulação que conhece o fundo do oceano

Em grandes instituições, sempre existem profissionais que parecem possuir um sonar interno.

Eles olham um erro e dizem:

“Isso começou depois da conversão de arquivos de 2003.”

Ou:

“Esse campo não pode ficar em branco porque o sistema de previdência antigo usa espaço como indicador de benefício vitalício.”

Ou ainda:

“Não altere essa ordenação. O arquivo precisa chegar desse jeito porque o processo noturno compara registros por posição, não por chave.”

Esses profissionais não apenas conhecem o código.

Eles conhecem a história.

Eles lembram:

  • de incidentes;

  • de migrações;

  • de auditorias;

  • de exceções;

  • de soluções provisórias;

  • de clientes especiais;

  • de mudanças regulatórias;

  • de sistemas desativados que ainda deixam rastros.

Eles são a documentação viva da organização.

O problema é que muitos estão se aposentando.

Quando essas pessoas saem, a instituição não perde apenas mão de obra.

Ela perde contexto.

É como se o capitão do Seaview abandonasse o submarino levando consigo a única carta náutica da região.

Os motores continuam funcionando.

Os painéis continuam acesos.

Mas ninguém sabe exatamente o que existe adiante.


5. Conhecimento explícito e conhecimento tácito

Existem dois tipos principais de conhecimento dentro de uma organização.

Conhecimento explícito

É aquele que pode ser registrado.

Exemplos:

  • manuais;

  • diagramas;

  • wikis;

  • especificações;

  • normas;

  • comentários;

  • fluxos;

  • casos de teste;

  • atas de reunião;

  • registros de mudança.

Conhecimento tácito

É aquele que vive na experiência das pessoas.

Exemplos:

  • perceber que determinado erro costuma indicar arquivo incompleto;

  • saber qual sistema costuma atrasar o processamento;

  • reconhecer um padrão estranho em um relatório;

  • lembrar que uma exceção existe por causa de um processo judicial antigo;

  • saber quem deve ser consultado antes de alterar uma regra.

O conhecimento tácito é poderoso, mas frágil.

Ele não é facilmente pesquisável.

Não aparece em diagramas.

Não pode ser encontrado com CTRL+F.

E desaparece quando a pessoa muda de área, se aposenta ou simplesmente esquece.

O verdadeiro risco dos sistemas legados não está apenas em sua idade.

Está na distância crescente entre o comportamento do sistema e a compreensão humana desse comportamento.


6. O comentário mais perigoso do mainframe

Todo programador COBOL eventualmente encontra um comentário assim:

* NAO ALTERAR

Ou:

* CORRECAO TEMPORARIA

Ou o clássico:

* AJUSTE ESPECIAL

A pergunta imediata deveria ser:

Por quê?

Mas muitas vezes não existe resposta.

A correção temporária foi criada em 1996.

O autor saiu da empresa em 2008.

O sistema que gerava o problema foi desativado em 2014.

Mesmo assim, o código continua lá.

É possível que não seja mais necessário.

Também é possível que seja a única coisa impedindo um desastre.

Esse tipo de situação transforma manutenção em arqueologia.

O programador deixa de ser apenas desenvolvedor.

Ele se torna investigador.

Cada comentário é um fragmento de mapa.

Cada IF é uma pista.

Cada arquivo antigo é uma caixa-preta retirada de um naufrágio.


7. O problema nunca foi simplesmente o COBOL

É comum ouvir:

“O problema é que o sistema está em COBOL.”

Isso é uma simplificação confortável.

COBOL pode ser antigo, mas isso não significa que seja incapaz.

Ele continua sendo eficiente para processamento de grandes volumes de dados, regras de negócio, cálculos financeiros e operações transacionais.

O problema real costuma ser outro:

  • arquitetura não documentada;

  • dependências ocultas;

  • regras espalhadas;

  • ausência de testes;

  • falta de rastreabilidade;

  • conhecimento concentrado;

  • décadas de mudanças incrementais;

  • integrações pouco compreendidas.

Reescrever tudo em Java, C#, Python, Go ou qualquer outra linguagem não corrige automaticamente essas falhas.

Você pode transportar uma regra mal compreendida para uma tecnologia moderna e continuar tendo um sistema mal compreendido.

Agora ele terá contêineres, APIs e dashboards coloridos.

Mas continuará sendo um mistério.

É como trocar o casco do submarino sem saber por que alguns compartimentos precisam permanecer isolados.


8. Por que microserviços não são uma boia salva-vidas

Microserviços podem ser excelentes.

Eles ajudam a separar responsabilidades, escalar componentes, melhorar implantações e reduzir acoplamentos.

Mas não resolvem desconhecimento.

Imagine um programa legado com cinquenta regras pouco compreendidas.

A equipe decide dividi-lo em vinte microserviços.

Agora existem vinte componentes carregando regras pouco compreendidas.

Antes, o mistério estava em um programa.

Agora está distribuído pela rede.

Você também ganhou:

  • APIs;

  • autenticação;

  • latência;

  • filas;

  • observabilidade;

  • versionamento;

  • tolerância a falhas;

  • consistência distribuída;

  • retries;

  • circuit breakers.

Os microserviços não eliminaram o problema.

Eles adicionaram novas camadas ao oceano.

A modernização correta começa por entendimento, não por tecnologia.


9. “Show your work”: mostre como chegou ao resultado

Reguladores e auditores estão cada vez menos satisfeitos com a resposta:

“O sistema sempre funcionou assim.”

Eles querem evidências.

Querem saber:

  • qual regra foi aplicada;

  • qual dado foi usado;

  • quem alterou o programa;

  • quem aprovou;

  • qual teste foi executado;

  • qual requisito justificou a mudança;

  • qual impacto foi analisado;

  • como o resultado pode ser reproduzido.

Isso aparece em diferentes regulações, normas e políticas.

A mensagem geral é simples:

Mostre como chegou ao resultado.

Em matemática escolar, não basta escrever a resposta.

É preciso demonstrar o cálculo.

Em sistemas críticos, ocorre o mesmo.

Não basta o programa gerar o valor correto.

É preciso explicar:

  • o fluxo;

  • a decisão;

  • a origem;

  • a evidência;

  • a responsabilidade.

Essa exigência afeta tanto sistemas tradicionais quanto soluções com inteligência artificial.


10. O que reguladores estão enxergando

Durante décadas, muitas instituições conviveram com sistemas que funcionavam, mas eram pouco explicáveis.

Enquanto os resultados estavam corretos, o risco parecia aceitável.

Agora isso mudou.

Regulações relacionadas à proteção de dados, resiliência operacional, governança, risco e inteligência artificial aumentaram a pressão por:

  • transparência;

  • documentação;

  • rastreabilidade;

  • responsabilidade;

  • explicabilidade;

  • controle de mudanças;

  • gestão de terceiros;

  • continuidade operacional.

Um sistema que ninguém compreende completamente deixa de ser apenas um problema técnico.

Ele se torna um risco de conformidade.

Imagine um cálculo de benefício financeiro contestado por um cliente.

A instituição precisa responder:

Por que esse valor foi calculado?

Qual regra foi aplicada?

Em qual versão do programa?

Com quais dados?

Quem aprovou aquela regra?

Se a única resposta for:

“O senhor Antônio sabia, mas se aposentou há três anos”,

o problema já ultrapassou o departamento de tecnologia.


11. Por que o ChatGPT sozinho não salvará o submarino

Modelos de linguagem podem ajudar muito na análise de código.

Eles podem:

  • explicar trechos;

  • resumir programas;

  • sugerir documentação;

  • gerar casos de teste;

  • identificar estruturas;

  • converter pseudocódigo;

  • apontar possíveis inconsistências;

  • criar diagramas conceituais;

  • auxiliar novos profissionais.

Mas existe um limite essencial.

A IA só pode trabalhar com o contexto disponível.

Se determinada regra não está:

  • no código;

  • nos documentos;

  • nos testes;

  • nos tickets;

  • nos manuais;

  • nos registros;

  • nas conversas preservadas;

a IA não pode recuperar magicamente sua intenção original.

Ela pode inferir.

Mas inferência não é certeza.

Considere:

IF IDADE-CLIENTE > 65
    COMPUTE TAXA = TAXA * 0.75
END-IF

A IA pode dizer:

“O programa aplica desconto de 25% para clientes com mais de 65 anos.”

Isso descreve o comportamento.

Mas não explica:

  • se é obrigação legal;

  • se é benefício promocional;

  • se vale para todos os produtos;

  • se a idade correta deveria ser 60;

  • se a regra ainda está vigente;

  • se existem exceções.

A IA genérica entende a linha.

Não necessariamente entende o mundo que criou a linha.


12. IA genérica versus IA de domínio

Uma IA genérica conhece muitos assuntos.

Uma IA de domínio é construída ou enriquecida para compreender profundamente um contexto específico.

Em um ambiente bancário, uma solução realmente útil precisaria relacionar:

  • código COBOL;

  • copybooks;

  • JCL;

  • tabelas Db2;

  • arquivos VSAM;

  • transações CICS;

  • mensagens MQ;

  • normas internas;

  • legislação;

  • casos de teste;

  • tickets;

  • documentação;

  • histórico de mudanças;

  • entrevistas com especialistas.

Não basta alimentar um modelo com um único programa.

É preciso criar uma visão do ecossistema.

Essa abordagem pode envolver:

  • mecanismos de busca semântica;

  • catálogos de metadados;

  • grafos de dependência;

  • análise estática;

  • documentação recuperada;

  • bases vetoriais;

  • trilhas de auditoria;

  • validação humana;

  • controle de acesso.

A IA torna-se um sonar.

Ela ajuda a mapear o oceano.

Mas ainda é necessário um comandante humano para interpretar o que aparece na tela.


13. Passo a passo para compreender um sistema legado

Para o programador COBOL iniciante, a melhor estratégia não é tentar entender tudo de uma vez.

Um sistema crítico precisa ser explorado por camadas.

Passo 1 — Descubra a entrada

Pergunte:

  • O programa recebe arquivo?

  • Recebe COMMAREA?

  • Lê fila MQ?

  • Usa parâmetros?

  • Consulta banco?

  • É chamado por outro programa?

Identifique os dados de entrada.

Passo 2 — Descubra a saída

O programa:

  • grava arquivo;

  • atualiza tabela;

  • retorna código;

  • envia mensagem;

  • imprime relatório;

  • chama outro módulo?

Saber o que entra e o que sai ajuda a delimitar a responsabilidade.

Passo 3 — Mapeie os acessos

Procure:

  • SELECT;

  • FD;

  • EXEC SQL;

  • EXEC CICS;

  • CALL;

  • LINK;

  • XCTL;

  • READ;

  • WRITE;

  • REWRITE;

  • DELETE.

Esses comandos mostram conexões importantes.

Passo 4 — Identifique regras

Procure decisões:

IF
EVALUATE
PERFORM
COMPUTE
ADD
SUBTRACT
MULTIPLY
DIVIDE

Registre cada regra com linguagem simples.

Exemplo:

“Clientes com adesão anterior a julho de 1994 utilizam cálculo histórico.”

Passo 5 — Procure datas e códigos mágicos

Valores fixos são pistas.

IF WS-CODIGO = 47

Por que 47?

IF WS-DATA < 20010101

O que aconteceu em 2001?

Todo número mágico merece investigação.

Passo 6 — Leia o JCL

O JCL pode explicar mais do que o programa.

Ele mostra:

  • arquivos;

  • etapas;

  • ordenações;

  • parâmetros;

  • programas anteriores;

  • programas posteriores;

  • condições;

  • utilitários.

O programa é apenas um compartimento do submarino.

O JCL mostra a rota da missão.

Passo 7 — Converse com especialistas

Pergunte:

  • Que problema esse processo resolve?

  • O que acontece se ele falhar?

  • Quais clientes são afetados?

  • Quais exceções existem?

  • Que parte ninguém deve alterar?

  • Qual incidente antigo explica essa regra?

Grave ou documente as respostas de forma autorizada e organizada.

Passo 8 — Crie testes de caracterização

Antes de alterar o sistema, registre seu comportamento atual.

Forneça entradas conhecidas.

Capture saídas.

Esses testes funcionam como fotografias do sistema antes da reforma.

Passo 9 — Valide com o negócio

Não confie apenas na interpretação técnica.

Uma regra pode estar implementada de determinada forma e ainda assim não refletir a política atual.

A área de negócio precisa validar.

Passo 10 — Documente enquanto aprende

Não deixe para o final.

O final nunca chega.

Documente:

  • fluxo;

  • regras;

  • dependências;

  • dúvidas;

  • exceções;

  • responsáveis;

  • fontes;

  • testes.


14. Um mapa mínimo para cada programa

Todo programa importante deveria possuir uma ficha simples:

Identificação

  • Nome do programa;

  • sistema;

  • módulo;

  • responsável;

  • criticidade.

Objetivo

Uma frase clara:

“Calcula o valor líquido de resgate de contratos de previdência.”

Entradas

  • arquivos;

  • tabelas;

  • parâmetros;

  • mensagens;

  • chamadas.

Saídas

  • tabelas atualizadas;

  • arquivos gerados;

  • códigos de retorno;

  • mensagens.

Regras principais

Uma lista de regras de negócio compreensíveis.

Dependências

  • programas chamados;

  • transações;

  • filas;

  • bancos;

  • jobs.

Exceções

Casos especiais e históricos.

Evidências

  • documentos;

  • tickets;

  • legislação;

  • testes;

  • entrevistas.

Riscos

O que pode acontecer se houver alteração incorreta.

Essa ficha não precisa começar perfeita.

Ela precisa começar.


15. Testes são caixas-pretas de sobrevivência

Em sistemas pouco documentados, testes automatizados são fundamentais.

Um teste de caracterização não pergunta inicialmente se o comportamento está certo.

Ele registra o que o sistema faz hoje.

Exemplo:

Entrada:

IDADE = 67
SALDO = 10000
TIPO = 09

Saída atual:

TAXA = 0
VALOR-LIQUIDO = 10000

Mesmo que você ainda não saiba por que o tipo 09 recebe taxa zero, agora existe uma evidência do comportamento.

Depois, especialistas e analistas podem decidir se a regra deve continuar.

Sem testes, cada mudança é uma descida em águas desconhecidas.

Com testes, pelo menos existem boias marcando o caminho de volta.


16. O perigo da reescrita heroica

Existe um tipo de projeto que aparece ciclicamente:

“Vamos reescrever tudo.”

A proposta parece corajosa.

A equipe escolhe uma tecnologia moderna.

Cria uma nova arquitetura.

Desenha diagramas.

Depois começa a descobrir que o sistema antigo possui milhares de regras não documentadas.

A reescrita passa a exigir decisões sobre comportamentos que ninguém consegue explicar.

O novo sistema pode ficar mais bonito, mas incompleto.

Reescrever sem compreender é como construir outro submarino usando fotografias externas do antigo.

Você copia o formato.

Mas não entende os sistemas internos que o mantinham vivo sob pressão.


17. Estratégias de modernização mais seguras

Modernização não precisa significar destruição total.

Existem abordagens graduais.

Encapsular

Expor funções existentes por APIs sem reescrever imediatamente a lógica.

Refatorar

Melhorar a estrutura interna preservando o comportamento.

Extrair regras

Separar regras de negócio de partes técnicas.

Substituir por etapas

Migrar componentes de menor risco primeiro.

Manter onde faz sentido

Nem tudo precisa ser reescrito.

Um programa estável, eficiente, bem testado e compreendido pode continuar cumprindo sua função.

Criar observabilidade

Adicionar logs, métricas, rastreamento e evidências.

Preservar conhecimento

Transformar entrevistas, código, documentação e testes em uma base pesquisável.

A modernização madura pergunta:

“Qual problema precisamos resolver?”

A modernização imatura pergunta:

“Qual tecnologia está na moda?”


18. Curiosidades das profundezas do legado

Curiosidade 1 — Muitos sistemas antigos são extremamente rápidos

Programas batch bem construídos conseguem processar volumes gigantescos com eficiência impressionante.

Curiosidade 2 — O código antigo pode estar correto há décadas

Antigo não significa defeituoso.

Às vezes, o código permaneceu porque funciona.

Curiosidade 3 — A regra mais estranha pode ser a mais importante

Exceções esquisitas frequentemente revelam contratos, leis ou incidentes históricos.

Curiosidade 4 — O melhor documento pode estar no JCL

A sequência de steps mostra como o negócio realmente é processado.

Curiosidade 5 — Arquivos de teste antigos são tesouros

Eles revelam cenários, combinações e resultados esperados.

Curiosidade 6 — O nome do programa pode enganar

CALCJURO talvez calcule imposto, tarifa, comissão e arredondamento além de juros.

Curiosidade 7 — O sistema real ultrapassa o código

Parte da lógica pode estar em:

  • parâmetros;

  • tabelas;

  • procedimentos;

  • agendamentos;

  • configurações;

  • arquivos;

  • rotinas operacionais.


19. Dicas para o programador COBOL padawan

Não tenha vergonha de perguntar

O sistema pode ser mais velho do que sua carreira.

Ninguém espera compreensão instantânea.

Evite assumir

Confirme.

O nome de um campo nem sempre reflete seu uso atual.

Não altere números mágicos sem investigar

Datas, códigos e percentuais fixos quase sempre possuem uma história.

Leia os dados

Um copybook pode revelar mais do domínio do que várias páginas de documentação.

Aprenda o negócio

O melhor programador de sistemas financeiros não é apenas quem domina PERFORM.

É quem entende:

  • contrato;

  • saldo;

  • juros;

  • imposto;

  • compensação;

  • liquidação;

  • risco;

  • exceção.

Crie diagramas simples

Não espere uma arquitetura perfeita.

Comece com:

Arquivo → Job → Programa → Db2 → Relatório

Depois aprofunde.

Registre dúvidas

Uma dúvida esquecida vira um problema futuro.

Preserve a voz dos veteranos

Entrevistas estruturadas podem recuperar histórias que nunca foram escritas.

Não confunda confiança com certeza

Um sistema pode parecer simples porque você ainda não descobriu suas exceções.


20. Easter eggs do Bellacosa Mainframe

Todo grande sistema legado possui seus easter eggs.

Não necessariamente piadas escondidas, mas pequenos sinais de sua história.

Pode ser:

  • um campo com nome de projeto extinto;

  • uma data que marca uma mudança econômica;

  • um código de retorno que ninguém mais usa;

  • um comentário com iniciais de um programador;

  • uma condição criada para um único cliente;

  • uma rotina chamada FINAL-FINAL;

  • um programa chamado NOVO criado em 1989;

  • uma variável chamada TEMP usada há trinta anos.

E existe o easter egg supremo:

* RETIRAR DEPOIS DA MIGRACAO

A migração ocorreu em 1997.

A linha continua em produção.

Ao encontrá-la, o programador iniciante deve resistir à tentação de apagar.

Primeiro investigue.

Talvez seja apenas um fóssil.

Talvez seja a coluna estrutural secreta do submarino.


21. A inteligência artificial como novo sonar

Usada corretamente, a IA pode acelerar enormemente o trabalho de compreensão.

Ela pode ajudar a:

  • resumir programas;

  • explicar parágrafos;

  • sugerir nomes melhores;

  • encontrar padrões repetidos;

  • correlacionar copybooks;

  • gerar perguntas para especialistas;

  • criar documentação inicial;

  • propor testes;

  • identificar regras candidatas;

  • montar mapas de chamadas.

Mas o fluxo seguro é:

  1. A IA analisa.

  2. O especialista revisa.

  3. O negócio valida.

  4. O teste comprova.

  5. A documentação registra.

  6. A governança aprova.

A IA não deve ser tratada como oráculo.

Ela é um instrumento de navegação.

Um sonar pode indicar uma grande massa à frente.

Mas cabe à tripulação decidir se é uma montanha submarina, um navio naufragado ou um monstro marinho de um episódio de 1966.


22. Onde estamos indo

O futuro não será simplesmente “COBOL versus IA”.

Nem “mainframe versus cloud”.

Nem “monólito versus microserviços”.

O futuro mais provável será híbrido.

Sistemas críticos continuarão executando regras maduras.

APIs facilitarão integração.

Cloud fornecerá elasticidade e novos serviços.

IA ajudará na compreensão.

Grafos mapearão dependências.

Testes automatizados protegerão comportamentos.

Documentação viva conectará código, regra, requisito e evidência.

O objetivo não é apagar o passado.

É tornar o passado compreensível.

Porque somente aquilo que pode ser compreendido pode ser modernizado com segurança.


23. O verdadeiro risco sistêmico

Falamos muito sobre:

  • ataques;

  • falhas de hardware;

  • indisponibilidade;

  • fraude;

  • ransomware;

  • bugs;

  • desastres naturais.

Mas existe um risco mais silencioso:

A organização continuar operando sistemas que ninguém consegue explicar.

Esse risco cresce lentamente.

Primeiro sai um especialista.

Depois outro.

A documentação envelhece.

As equipes mudam.

Os fornecedores trocam.

As tecnologias são empilhadas.

Até que, um dia, ocorre um incidente.

E todos percebem que o sistema ainda funciona, mas a instituição já não sabe completamente por quê.

Esse é o verdadeiro Voyage to the Bottom of the Legacy System.

A descida não é em direção ao fundo do mar.

É em direção às camadas de decisões acumuladas por décadas.


Conclusão: não desligue os motores antes de encontrar o mapa

O maior patrimônio de um banco não está apenas em seus cofres, prédios, servidores ou aplicações.

Está no conhecimento que conecta tudo isso.

COBOL não é apenas uma linguagem antiga.

Em muitos ambientes, ele é o idioma em que décadas de decisões financeiras foram registradas.

O perigo não é o código ser velho.

O perigo é ninguém mais conseguir explicar suas escolhas.

Para o programador iniciante, a missão não é apenas aprender PIC, MOVE, PERFORM, EVALUATE e EXEC SQL.

A missão é aprender a fazer perguntas.

Por que essa regra existe?

De onde vem esse valor?

Quem depende desse processamento?

Qual documento comprova esse comportamento?

O que acontece se eu alterar?

Que parte do negócio este código representa?

No fundo do oceano, coragem sem mapa é imprudência.

No fundo do sistema legado, modernização sem compreensão é apenas uma forma mais cara de se perder.

Portanto, antes de reescrever, compreenda.

Antes de apagar, investigue.

Antes de automatizar, documente.

Antes de confiar na IA, forneça contexto.

E antes que o último especialista se aposente, sente-se ao lado dele, abra o código, prepare o café e pergunte:

“Pode me explicar por que esse IF existe?”

Talvez a resposta salve não apenas um programa.

Talvez salve parte das economias do mundo.

Mensagem recebida via telegrafo

Seja um mainframer, aprenda COBOL e participe desta missão nas profundezas do CPD, os famosos Centros de Processamento de Dados.


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