Bob encontra o mainframe

Quando lançamos o Bob, dissemos que o problema interessante não era escrever código novo, mas trabalhar dentro de um sistema que já existe — encontrar o lugar certo para fazer uma mudança, respeitar as convenções que uma equipe estabeleceu há anos, manter o comportamento consistente em arquivos que estão crescendo há muito tempo.

A versão mais antiga de um «sistema que já existe» roda em um mainframe. Décadas de COBOL e PL/I, milhões de linhas, dezenas de milhares de programas conectados via Db2, CICS, IMS e schedulers batch — código que continua operando o negócio sem qualquer interrupção que não possam se dar ao luxo de arriscar.

Hoje tornamos o IBM Bob Premium Package for Z (Bob PP4Z) geralmente disponível. Ele substitui o IBM watsonx Code Assistant for Z e traz a expertise do IBM Z — linguagens da plataforma, conhecimento de middleware e análise determinística em escala enterprise — diretamente para a experiência do Bob.

Esta é a história de engenharia, não um tour de funcionalidades. Em vez de listar tudo que o PP4Z faz, queremos fazer três coisas:

Explicar por que um modelo de propósito geral erra nas suas aplicações mainframe mais vezes do que admite.
Mostrar como ancoramos o Bob em fatos determinísticos sobre seu ambiente em vez de probabilidades.
Percorrer os modos, skills e workflows específicos do Z — e o que você pode construir com eles.

1. Por que o mainframe é o caso difícil

Um modelo de propósito geral apontado para um ambiente mainframe se depara com três problemas que nenhum prompting inteligente realmente resolve. O design do PP4Z oferece soluções para cada um.

1.1. Escala e o que ela faz com uma janela de contexto

Uma única aplicação de negócios pode ter milhões de linhas de COBOL, dezenas de milhares de módulos interconectados em COBOL, PL/I e assembler, e milhares de jobs batch encadeados por um scheduler enterprise. Mesmo um fragmento «pequeno» de 200 programas facilmente chega a centenas de milhares de linhas.

Isso não cabe em uma janela de contexto, e o problema não é apenas a janela. À medida que o contexto cresce, o desempenho do modelo piora (Chroma Research Context Rot Study, 2025) — as respostas ficam incompletas, inconsistentes ou confiantemente erradas. Incluir «os arquivos relevantes» pressupõe que você já sabe quais são relevantes — exatamente o que estava tentando descobrir.

1.2. Significado que não está no código

O código mainframe é semanticamente denso. O significado de negócio vive em nomes de campos e décadas de convenções, não em algo que um parser consiga ler. Alguns podem ser deduzidos — SERIALN é provavelmente um número de série, TOT-STTM provavelmente uma liquidação total. A maioria não: o que é C-M? M-CAP? Por que o prefixo CCZD? O que separa NO-SIN, NO-EVN e NO-CNT?

O significado é real e estrutural, mas não pode ser deduzido apenas do código. A resposta tradicional é um dicionário de dados — mas a escala (milhões, senão bilhões de variáveis) torna difícil construir um manualmente ou com força bruta de um modelo de linguagem.

1.3. A resposta mais provável não é a resposta certa

Um modelo de linguagem retorna o que é estatisticamente provável. Os modelos são não-determinísticos; a mesma pergunta pode obter respostas diferentes em dias diferentes. Em um sistema onde uma resposta errada sobre fluxo de controle pode distorcer a lógica de negócio, esse é um risco significativo.

É um cenário que você provavelmente já encontrou, assumindo que o reconheceu. Pegue uma aplicação batch COBOL real: 233 programas, 742 copybooks, mais de 20 MB de código, com um utilitário de data muito chamado, N991DATE. Pelos metadados, a verdade é que 30 programas o chamam. Agora pergunte diretamente a um modelo frontier:

Dia 1. Ele não consegue carregar tudo, então busca por instruções CALL estáticas e reporta 13. Perguntado sobre chamadas dinâmicas, amplia o regex e reporta 29. O que ele perde, CHKOUTB, está em um arquivo chamado ROCHKOUT.cbl — porque por convenção o nome de um arquivo geralmente corresponde ao seu PROGRAM-ID, mas nunca é obrigatório.
Dia 2. Mesma pergunta, heurísticas diferentes, e agora reporta 31 — supercontagem. Um falso positivo, N285RODR, apenas declara o literal 'N991DATE' no working storage e nunca o usa. O modelo chega a isso apenas depois de vários follow-ups.

Nenhuma dessas heurísticas é irrazoável. Elas simplesmente não são boas o suficiente, e «quem chama X» é uma das questões centrais durante a análise de impacto e compreensão de programas. Questões mais avançadas — quais tabelas são atualizadas em mais de um programa, quais arquivos são lidos mas nunca escritos, quais variáveis alimentam o cálculo de WS-UIT02 em PREMPZ72 — precisam de análise completa e precisa que o casamento de padrões não consegue fornecer.

A conclusão não é «modelos não são úteis para entender programas mainframe». É que a qualidade das respostas melhora substancialmente quando há algo verdadeiro para raciocinar. Modelos de linguagem se destacam no processamento de dados.

2. Ancorando o Bob em fatos, não em probabilidades

A resposta do PP4Z é parar de pedir ao modelo que reconstrua o sistema a partir do código-fonte, e em vez disso fornecer a ele uma representação determinística e consultável do ambiente para raciocinar. Três mecanismos fazem a ancoragem: o modelo recebe instrução para sinalizar construções z/OS ambíguas na própria solicitação; os prompts são enriquecidos com insights autorizados do IBM Z, documentação IBM, material de referência, amostras verificadas e mais, com vieses de programação de propósito geral ativamente suprimidos; e o modelo recebe instrução de responder primeiro a partir dos metadados de análise. O objetivo é tornar as respostas rastreáveis ao sistema IBM Z, não a uma distribuição de treinamento.

2.1. Z Understand: um modelo consultável do seu ambiente

Z Understand é a plataforma de análise estática por baixo do PP4Z. Roda em um servidor com acesso ao seu código-fonte completo, inclui scanners para COBOL, PL/I e assembler além de JCL e schedulers como Control-M e TWS, e processa milhares de programas em paralelo em um único repositório consultável. Mantém estrutura determinística e consistente em ambientes com 10.000+ programas.

Ajuda pensar nisso como uma pipeline de compilação com uma saída diferente: não um executável, mas conhecimento estruturado e consultável — definições de dados, fluxo de controle entre programas e jobs, fluxo de dados preciso (incluindo REDEFINES e offsets de memória) e interações de subsistemas.

2.2. Deixar o modelo escrever suas próprias queries

Como os metadados são expostos importa tanto quanto os metadados em si. APIs fixas e padrões de query MCP predefinidos são muito eficientes para questões conhecidas e esperadas, mas falham em análises abertas. Durante a análise aberta, uma questão real se ramifica em muitas sub-queries que mudam à medida que o raciocínio avança.

Então ensinamos o Bob a ir além das queries predefinidas e gerar e executar suas próprias queries contra os metadados. Isso se apoia no que os modelos realmente fazem bem — raciocínio e geração de queries — e escala da forma como dados estruturados escalam: seja com 10 ou 10.000 programas, a query é a mesma; apenas o conjunto de resultados cresce.

2.3. Extensibilidade, scanners personalizados e dados de runtime

A análise puramente sintática perde as relações que importam quando chamadas dinâmicas, abstrações de API e pré-processadores escondem o fluxo real. O framework Z Understand Extensibility fecha essa lacuna:

Resolução de chamadas de API / macros mapeia chamadas indiretas e baseadas em parâmetros para seus alvos reais, substituindo arestas de chamada genéricas por relações concretas chamador–chamado, via config JSON ou user exits.
Extensibilidade de pré-processadores interpreta instruções não-padrão preservando a visão de código-fonte original, mapeando de forma limpa entre código pré- e pós-processado.
Scanners personalizados trazem linguagens proprietárias, 4GLs e até fontes que não são código para um único modelo através de uma interface JSON orientada a schema.

A análise estática diz o que pode acontecer; os dados de runtime dizem o que aconteceu. O PP4Z transforma o depurador em um instrumento de coleta de dados e entrega esses rastros precisos ao Bob.

2.4. O dicionário de dados: relevância sobre completude

Documentar bilhões de variáveis não é viável nem sustentável, então o PP4Z não tenta. A análise determinística classifica as variáveis por quanto realmente impulsionam o comportamento — frequência de uso, distribuição em regiões do código, participação no fluxo de controle, interação com bancos de dados e E/S — e seleciona o pequeno conjunto que revela o propósito de um programa.

O achado útil aqui: cobertura limitada é suficiente. Definir aproximadamente as 10-20 principais variáveis por programa melhora materialmente a compreensão sem documentação exaustiva. Z Understand Services automatiza isso em portfólios inteiros pela CLI, uma pontuação de confiança mantém apenas definições acima de um limiar, e um passo human-in-the-loop no IDE permite que os desenvolvedores revisem, corrijam e alinhem a saída com glossários existentes.

3. Especializando o Bob para Z

A ancoragem dá ao Bob bons fatos. A especialização é o que o torna previsível em um ambiente onde os outputs têm que ser explicáveis e os processos têm que satisfazer a governança. O PP4Z é construído sobre quatro peças: modos, ferramentas, skills e workflows.

Modos definem o papel e os limites para um fluxo de interação. Um modo estilo arquiteto prioriza análise, documentação e descoberta de dependências, com modificação de código explicitamente proibida. Um modo desenvolvedor é ajustado para geração e refatoração com aplicação de padrões de codificação embutida.
Ferramentas dão ao modelo acesso direto ao conhecimento estruturado do sistema — varredura de programas, interrogação de metadados, busca no dicionário de dados, serviços de análise em escala enterprise.
Skills codificam expertise recorrente em passos repetíveis e auditáveis. O skill de planejamento de implementação, por exemplo, impõe uma sequência fixa: adquirir e validar contexto, formular requisitos, mapear impacto a partir dos metadados, então produzir um plano persistido e revisável.
Workflows adicionam orquestração com estado — impondo ordenação, validando resultados intermediários, parando em entrada ruim. O workflow do dicionário de dados para se não encontrar variáveis em vez de inventar algumas.

Padrões e governança são aplicados por padrão através das regras agents.md no nível do repositório. Você também pode criar seus próprios skills, sem escrever código.

Quando estes se combinam, um único prompt pode conduzir uma tarefa de ponta a ponta:

«Adicione uma coluna à Motor Policy Table que registre se o veículo é elétrico. Aplique meus padrões de codificação e atualize todos os programas impactados.»

O Bob lê a intenção, constrói um plano, seleciona os modos, skills e regras de repositório corretos, e executa com segurança as ferramentas necessárias — governança, execução e raciocínio em uma única passagem, com você aprovando as mudanças.

4. O que você pode construir hoje

Documentação que não fica desatualizada. Trate docs como um artefato gerado ancorado em metadados determinísticos mais contexto de fonte e runtime — regenerável sob demanda, alinhado ao sistema atual.
Transição determinística de COBOL para Java no z/OS. O PP4Z usa metadados como espinha dorsal da transformação, construindo modelos paralelos de fonte e destino para que a arquitetura seja reproduzível e a lógica de negócios mapeada com precisão.
Refatoração direcionada e extração de funções. O Bob produz uma lista classificada de candidatos a refatoração anotados com função de negócio, depois extrai módulos autossuficientes com entradas e saídas claras.
Ferramentas nativas z/OS. Capacidades do Z Open Editor mais novas ferramentas MCP: Dependency Based Build (DBB), Z Code Scan e IBM Debug for z/OS para transformar sessões de depuração ao vivo em análise de causa raiz assistida por IA.

Uma nota sobre honestidade, já que este é um post de engenharia: nada disso remove o desenvolvedor do processo, e não é intenção fazê-lo. Os modos, os gates de aprovação e o dicionário de dados human-in-the-loop existem todos porque nesses sistemas «quase certo» é o modo de falha, não o objetivo.

5. Como obter acesso

Bob Premium Package for Z (PP4Z) é um complemento do IBM Bob, não um produto separado para baixar. O PP4Z opera contra um ambiente mainframe ativo em um ambiente enterprise — o credenciamento é conduzido por vendas.

Comece com seu representante da IBM, ou use Contato de Vendas no bob.ibm.com. Eles configuram o plano base do IBM Bob e o complemento Z para sua organização.
Depois que seu administrador do Bob atribuir a você um assento com o complemento Z, o credenciamento é detectado quando você usa o IBM Bob. Instale o Bob IDE, faça login, e os modos, skills e ferramentas específicos do Z aparecem.

6. Como começar

Se você já está usando o Bob, o PP4Z adiciona os modos, skills e ferramentas específicos do Z em cima do que você tem.
Use a capacidade de compreensão integrada para obter insights mais profundos sobre o código em seu workspace.
Aponte o Z Understand para uma aplicação real onde você já conhece as respostas certas — e verifique a análise do Bob contra sua verdade de campo.
Comece com uma pergunta à qual nunca obteve uma resposta direta: quem realmente chama esse utilitário, quais tabelas esse job toca, o que essa variável significa?
Faça perguntas mais desafiadoras que combinem dados e raciocínio: «Me dê um call graph com diagramas organizados por tópicos»

Links