Translate

Mostrar mensagens com a etiqueta IBM Bob. Mostrar todas as mensagens
Mostrar mensagens com a etiqueta IBM Bob. Mostrar todas as mensagens

terça-feira, 30 de junho de 2026

Agentic Data Intelligence no IBM watsonx.data intelligence: Quando a Inteligência Artificial Descobre que Dados Sem Contexto São Apenas Bits Perdidos

 

Bellacosa Mainframe introduz o agentic data intelligence no ibm watsonx

☕ Um Café no Bellacosa Mainframe

Agentic Data Intelligence no IBM watsonx.data intelligence: Quando a Inteligência Artificial Descobre que Dados Sem Contexto São Apenas Bits Perdidos

Como um Programador COBOL Padawan Pode Entender a Próxima Grande Revolução da Inteligência Artificial Corporativa

Durante muito tempo, ouvimos que a Inteligência Artificial iria substituir programadores.

Depois disseram que bastava conectar um LLM (Large Language Model) ao banco de dados da empresa e todos os problemas estariam resolvidos.

Hoje sabemos que nenhuma dessas ideias estava completamente correta.

O verdadeiro desafio nunca foi fazer a IA "ler" dados.

O desafio sempre foi fazer a IA entender o significado daqueles dados.

Essa diferença parece pequena.

Na prática, ela separa uma IA que apenas gera respostas bonitas de uma IA capaz de trabalhar como um verdadeiro analista de negócios.

É exatamente esse o objetivo do novo Agentic Data Intelligence, incorporado ao IBM watsonx.data intelligence.

Para quem trabalha com IBM Z, COBOL, CICS, DB2, VSAM ou IMS, esse assunto é muito mais importante do que parece. Na realidade, ele conversa diretamente com um problema que todo programador experiente já enfrentou: como descobrir o impacto de uma mudança em um sistema gigantesco criado ao longo de décadas?

Pegue sua caneca de café.

Hoje vamos conversar sobre uma das tecnologias que provavelmente fará parte do futuro do desenvolvimento em Mainframe.


O maior problema da IA nunca foi inteligência

Imagine que amanhã você seja contratado por um grande banco.

No primeiro dia, entregam seu usuário RACF.

Você recebe acesso ao:

  • TSO/ISPF

  • SDSF

  • DB2

  • CICS

  • JCL

  • dezenas de bibliotecas PDS

  • milhares de programas COBOL

Você consegue abrir qualquer programa.

Consegue consultar tabelas.

Consegue executar jobs.

Mas consegue entender o sistema?

Claro que não.

Você não sabe:

  • qual tabela é oficial;

  • qual copybook está obsoleto;

  • qual campo representa uma regra de negócio;

  • quem é o responsável por determinado cadastro;

  • quais programas utilizam aquele arquivo VSAM;

  • quais APIs dependem daquele campo.

Agora imagine uma Inteligência Artificial.

Ela sofre exatamente do mesmo problema.

Ela consegue acessar dados.

Mas não conhece a empresa.


Dados não são conhecimento

Essa talvez seja a primeira grande lição deste artigo.

Existe uma enorme diferença entre:

Dados

e

Conhecimento Corporativo.

Por exemplo:

CLIENTE.STATUS = "A"

Para você isso significa o quê?

Nada.

Agora imagine que o glossário da empresa define:

"A = Cliente Ativo"

Já faz sentido.

Mas e se outra empresa definir:

"A = Cliente Aposentado"

Ou ainda:

"A = Cliente de Alto Valor"

Percebe?

O dado é exatamente igual.

O significado muda completamente.

É isso que chamamos de contexto.


O que é o IBM watsonx.data intelligence?

Pense nele como um enorme cérebro corporativo.

Ele não guarda apenas tabelas.

Ele guarda conhecimento sobre essas tabelas.

Ele sabe:

  • quem criou;

  • quem mantém;

  • quem utiliza;

  • quais sistemas dependem;

  • de onde vieram os dados;

  • quais regras foram aplicadas;

  • qual o nível de qualidade;

  • quais políticas de segurança existem.

Em outras palavras...

Ele transforma metadados em conhecimento utilizável.


Fazendo uma analogia com o Mainframe

Todo ambiente z/OS possui diversos "cérebros invisíveis".

Por exemplo:

  • ICF Catalog

  • RACF

  • SYS1.PARMLIB

  • PROCLIB

  • SMS

  • JES2

Nenhum deles processa transações bancárias.

Mesmo assim...

sem eles o banco simplesmente para.

O watsonx.data intelligence exerce um papel semelhante.

Ele não substitui o DB2.

Nem o VSAM.

Nem o IMS.

Ele explica para a IA como interpretar tudo isso.


Como funciona o Agentic Data Intelligence?

Vamos imaginar um fluxo simples.

Um usuário pergunta:

"Quais clientes Premium tiveram queda no faturamento este mês?"

Uma IA tradicional faria algo parecido com isto:

Pergunta

↓

Procura tabelas

↓

Executa SQL

↓

Entrega resposta

Parece bom.

Mas há vários riscos.

Ela pode consultar:

  • tabela errada;

  • coluna desatualizada;

  • dados duplicados;

  • informações sem governança.

Agora veja o novo fluxo.

Pergunta

↓

Consulta o catálogo corporativo

↓

Verifica definições de negócio

↓

Consulta Data Lineage

↓

Verifica políticas

↓

Avalia qualidade

↓

Gera resposta

É um processo muito mais inteligente.


O que significa "Trusted Context"?

Esse é provavelmente o conceito mais importante do watsonx.data intelligence.

Traduzindo livremente:

Contexto Confiável.

A IA deixa de confiar apenas nos dados.

Ela passa a confiar também nas regras que explicam aqueles dados.

Isso muda completamente a qualidade das respostas.


O papel do Business Glossary

Imagine um banco.

A palavra "Saldo" pode significar:

Saldo Contábil

Saldo Disponível

Saldo Projetado

Saldo Bloqueado

Saldo Médio

Todos são "Saldo".

Mas representam conceitos diferentes.

O Business Glossary resolve exatamente esse problema.

Ele funciona como um dicionário oficial da empresa.

Quando a IA encontra um termo, ela consulta o glossário antes de responder.

É como perguntar ao analista de negócios:

"Quando vocês dizem saldo, qual saldo exatamente?"


Data Lineage: seguindo o caminho dos dados

Agora imagine um campo chamado:

LIMITE_DISPONIVEL

De onde ele veio?

A IA consegue descobrir algo como:

PIX

↓

Movimentações

↓

Conta Corrente

↓

Motor Financeiro

↓

Tabela DB2

↓

Dashboard

Ela enxerga toda a cadeia de transformação.

Isso é chamado de Lineage.


Pensando como um Programador COBOL

Imagine alterar um copybook.

01 CLIENTE.
   05 LIMITE        PIC S9(9)V99 COMP-3.

Antes de alterar esse campo, você gostaria de saber:

  • Quantos programas usam esse copybook?

  • Quais transações CICS dependem dele?

  • Existe algum Job Batch?

  • Alguma API REST utiliza esse campo?

  • Existe integração com sistemas externos?

Hoje isso normalmente exige:

SDSF.

Pesquisa no Endevor.

Ferramentas de Impact Analysis.

Consulta a analistas.

Reuniões.

Com Agentic Data Intelligence, boa parte dessa investigação pode ser automatizada.


O poder do Data Quality

Imagine perguntar:

"Qual o faturamento do último trimestre?"

Uma IA comum responde.

Uma IA inteligente responde:

"O conjunto de dados possui 97,8% de qualidade, porém existem registros duplicados na origem."

Essa pequena diferença aumenta enormemente a confiança na resposta.


Governança não é burocracia

Muitos iniciantes acham que Governança serve apenas para gerar documentação.

Na verdade...

Governança protege a empresa.

Por exemplo:

CPF.

A IA sabe que:

  • deve mascarar;

  • exige autorização;

  • está protegido pela LGPD;

  • possui classificação confidencial.

Ela aprende regras.

Não apenas dados.


Ownership: quem é o dono da informação?

Imagine encontrar uma tabela chamada:

CLIENT_MASTER

Quem responde por ela?

Financeiro?

CRM?

Marketing?

TI?

A IA consulta o catálogo.

Descobre o proprietário.

E informa.

Isso reduz muito o tempo gasto procurando especialistas.


O que é o MCP?

MCP significa:

Model Context Protocol.

Você pode imaginar o MCP como um "idioma universal" entre agentes de IA e sistemas corporativos.

Assim como:

ODBC

JDBC

ODBC permitiu acessar bancos de dados diferentes.

O MCP pretende permitir que qualquer IA consulte conhecimento corporativo da mesma maneira.

Isso significa integração com:

  • IBM Bob

  • Claude

  • GitHub Copilot

  • watsonx Orchestrate

  • aplicações internas


Agent Skills: ensinando experiência para a IA

Aqui está uma das partes mais interessantes.

Imagine ensinar um estagiário.

Você não diz apenas:

"Cadastre um novo Data Product."

Você entrega um procedimento.

Receber dados

↓

Classificar

↓

Enriquecer metadados

↓

Aplicar LGPD

↓

Publicar

↓

Validar

Esse fluxo recebe o nome de Agent Skill.

São habilidades reutilizáveis.

É como um PROC em JCL.

Você encapsula conhecimento.

Depois reutiliza quantas vezes quiser.


Um exemplo para quem conhece JCL

Veja este comando:

//STEP01 EXEC PROC=BACKUP

Você não precisa lembrar:

  • IDCAMS

  • SORT

  • DELETE

  • DEFINE

  • REPRO

Tudo já está preparado.

Agent Skills funcionam exatamente assim.


Um exemplo de uso no mundo real

Imagine um auditor perguntando:

"De onde veio o valor mostrado neste Dashboard?"

A IA pode responder:

Dashboard

↓

Data Product

↓

Tabela Curada

↓

Pipeline ETL

↓

DB2

↓

Programa COBOL

↓

Arquivo VSAM

↓

Sistema de Origem

Tudo automaticamente.

Sem abrir dez ferramentas diferentes.


Outro exemplo para o Padawan

Você altera um Copybook.

Antes do Deploy, pergunta:

"Qual será o impacto?"

O agente responde:

  • 218 programas COBOL afetados;

  • 12 aplicações Java;

  • 31 APIs REST;

  • 4 sistemas parceiros;

  • 6 dashboards;

  • 2 modelos de IA.

Isso é muito mais poderoso do que uma simples pesquisa textual.


Como isso muda a vida do Programador COBOL?

Muito.

Hoje gastamos boa parte do tempo tentando descobrir:

"Quem usa isso?"

No futuro a pergunta será:

"IA, mostre todo o impacto desta alteração."

A IA não apenas responderá.

Ela mostrará:

  • dependências;

  • riscos;

  • qualidade;

  • governança;

  • responsáveis.


Como começar a estudar?

Se você é um COBOL Padawan, siga esta ordem.

Etapa 1 — Domine o Mainframe

Antes de IA, conheça bem:

  • JCL

  • TSO

  • SDSF

  • VSAM

  • DB2

  • CICS

  • IMS

Sem isso, você não entenderá de onde vêm os dados.


Etapa 2 — Aprenda Modelagem de Dados

Estude:

  • Chaves primárias

  • Chaves estrangeiras

  • Normalização

  • Data Warehouse

  • Data Lake

  • Data Products


Etapa 3 — Aprenda Governança

Entenda conceitos como:

  • Metadata

  • Business Glossary

  • Data Steward

  • Lineage

  • Data Quality

  • Data Catalog

  • Ownership

Esses termos aparecerão cada vez mais no mercado.


Etapa 4 — Estude IA Corporativa

Depois avance para:

  • LLM

  • RAG (Retrieval-Augmented Generation)

  • Agentes de IA

  • MCP (Model Context Protocol)

  • IBM watsonx

  • IBM Bob

  • watsonx Orchestrate

Você perceberá que IA corporativa é muito diferente de simplesmente conversar com um chatbot.


Dicas práticas para evoluir

✔ Aprenda SQL profundamente. A IA depende de dados bem estruturados.

✔ Leia documentação de arquitetura dos sistemas onde trabalha. O contexto de negócio é tão importante quanto o código.

✔ Familiarize-se com ferramentas de análise de impacto, catálogos de dados e governança. Muitas das capacidades do Agentic Data Intelligence automatizam tarefas que hoje são feitas manualmente.

✔ Estude conceitos de segurança, LGPD e classificação de dados. Um bom profissional de Mainframe entende que proteger a informação é tão importante quanto processá-la.

✔ Experimente copilotos e agentes de IA, mas sempre valide as respostas. A confiança em IA corporativa nasce da combinação entre automação e governança.


Curiosidades

  • A maior parte do conhecimento de uma empresa não está no código COBOL, mas nas regras de negócio documentadas — ou, muitas vezes, apenas na cabeça dos especialistas.

  • Grandes bancos mantêm aplicações com mais de 40 anos de evolução contínua. Compreender suas dependências é um desafio monumental.

  • O conceito de lineage existe há anos em ferramentas de integração de dados, mas agora passa a fazer parte das respostas produzidas por agentes de IA.

  • O Model Context Protocol (MCP) está se consolidando como um padrão importante para conectar modelos de IA a ferramentas e fontes de conhecimento corporativo.

  • O futuro da IA empresarial dependerá menos de modelos gigantes e mais da capacidade de utilizar dados confiáveis, governados e contextualizados.


Conclusão: o futuro pertence a quem entende contexto

Durante décadas, o diferencial de um excelente programador COBOL nunca foi decorar comandos do compilador ou conhecer todas as instruções da linguagem. O que realmente fazia diferença era compreender profundamente as regras de negócio, as dependências entre sistemas e a história por trás de cada aplicação.

O Agentic Data Intelligence leva essa mesma filosofia para a Inteligência Artificial.

Em vez de responder apenas com base em dados brutos, os agentes passam a consultar glossários de negócio, políticas de governança, linhagem dos dados, métricas de qualidade e informações sobre responsabilidade dos ativos. Em outras palavras, eles começam a agir como faria um analista experiente que conhece o ambiente da empresa.

Para o COBOL Padawan, isso representa uma oportunidade extraordinária. Dominar apenas a linguagem COBOL continuará sendo importante, mas já não será suficiente. O profissional que se destacar será aquele capaz de unir programação, arquitetura de dados, governança, inteligência artificial e conhecimento do negócio.

Assim como o Mainframe evoluiu de cartões perfurados para APIs REST, microsserviços e integração com nuvem, a próxima evolução será impulsionada por agentes inteligentes capazes de compreender o contexto completo da organização.

E talvez essa seja a maior lição deste café no Bellacosa Mainframe:

O código continua sendo essencial, mas o verdadeiro poder está em compreender o significado dos dados. Quem dominar esse conhecimento ajudará a construir a próxima geração de sistemas inteligentes sobre a plataforma mais confiável do mundo: o IBM Z.

 

segunda-feira, 29 de junho de 2026

IBM Bob + Docling for watsonx: Quando a Inteligência Artificial Aprende a Trabalhar Como um Analista Mainframe

 

Bellacosa Mainframe criando automacao de documentos com o ibm bob

☕ Um Café no Bellacosa Mainframe

IBM Bob + Docling for watsonx: Quando a Inteligência Artificial Aprende a Trabalhar Como um Analista Mainframe

Da Especificação ao Código, dos Documentos ao Conhecimento — O Futuro da Engenharia de Software Também Está Chegando ao COBOL

"Um bom programador escreve código. Um excelente programador entende o problema antes de escrever a primeira linha. O IBM Bob faz exatamente isso."


Introdução

Durante décadas, nós, profissionais de Mainframe, aprendemos uma verdade que continua absolutamente válida.

Codificar nunca foi a parte mais difícil de um projeto.

O verdadeiro desafio sempre esteve em entender o problema.

Quem trabalhou em bancos, seguradoras, empresas aéreas ou grandes indústrias conhece essa realidade.

Antes de abrir o ISPF e digitar o primeiro:

IDENTIFICATION DIVISION.

havia semanas — às vezes meses — dedicados a:

  • levantamento de requisitos;

  • entrevistas com usuários;

  • documentação funcional;

  • especificação técnica;

  • desenho de fluxo;

  • modelagem de arquivos;

  • validação com analistas;

  • revisão de arquitetura.

Somente depois disso alguém começava a escrever COBOL.

Curiosamente, durante muitos anos a Inteligência Artificial fez exatamente o contrário.

Ela recebia um prompt como:

"Crie um sistema de vendas."

E imediatamente começava a gerar milhares de linhas de código.

Parecia impressionante.

Mas para quem viveu projetos corporativos, havia um problema evidente:

Ninguém desenvolve software sério dessa forma.

Foi exatamente essa percepção que levou a IBM a criar uma abordagem muito mais madura, demonstrada no tutorial "Extract structured data from messy documents with Docling for IBM watsonx and IBM Bob".

Mais do que apresentar uma ferramenta, o tutorial mostra uma mudança de paradigma na engenharia de software.


O desenvolvimento tradicional

Vamos imaginar um projeto COBOL.

O usuário diz:

"Precisamos importar Ordens de Compra."

Parece simples.

Mas imediatamente surgem dezenas de perguntas.

  • Qual o layout?

  • Quantos fornecedores existem?

  • Existe autenticação?

  • Há processamento paralelo?

  • Como tratar arquivos inválidos?

  • Qual o limite diário?

  • Como exportar os resultados?

Essas perguntas não são feitas pelo compilador.

São feitas pelo analista.

Durante décadas essa foi exatamente a função do Analista de Sistemas.

Antes do programador existir, existe o entendimento do negócio.


O velho erro da IA

Grande parte dos copilots atuais funciona assim:

Usuário

↓

Prompt

↓

Código

Isso funciona para pequenos exemplos.

Mas em sistemas corporativos surgem problemas.

Por exemplo:

"Crie um sistema de compras."

Qual banco?

Qual autenticação?

Quais APIs?

Qual arquitetura?

Como tratar erros?

Onde salvar?

Como testar?

Como implantar?

Sem essas respostas, o código pode até funcionar, mas dificilmente será um sistema robusto.


A proposta do IBM Bob

O IBM Bob muda completamente essa lógica.

O fluxo passa a ser:

Ideia

↓

Requisitos

↓

Especificação Técnica

↓

Arquitetura

↓

Implementação

↓

Testes

↓

Correções

↓

Aplicação

Perceba a diferença.

O código deixa de ser o primeiro passo.

Ele passa a ser uma consequência.

Essa abordagem é chamada de Spec-Driven Development (SDD).


O que é Spec-Driven Development?

Imagine construir um prédio.

Ninguém começa levantando paredes.

Primeiro vêm:

  • levantamento do terreno;

  • projeto arquitetônico;

  • projeto elétrico;

  • projeto hidráulico;

  • cálculos estruturais.

Somente depois aparece o concreto.

Na engenharia de software deveria ser igual.

O documento de especificação passa a ser o "projeto da construção".

É exatamente isso que Bob produz automaticamente.


O papel do Docling

Outro protagonista do tutorial é o Docling for watsonx.

À primeira vista pode parecer apenas uma biblioteca para ler PDFs.

Mas isso seria reduzir demais sua importância.

O Docling faz algo muito mais sofisticado.

Ele transforma documentos desestruturados em dados compreensíveis para IA.

Imagine uma Ordem de Compra.

Visualmente ela possui:

  • logotipo;

  • cabeçalho;

  • fornecedor;

  • data;

  • tabela;

  • rodapé;

  • observações.

Para um ser humano isso é trivial.

Para um computador tradicional tudo isso é apenas texto espalhado.

O Docling reconstrói a estrutura lógica do documento.

Ele entende:

  • títulos;

  • subtítulos;

  • listas;

  • tabelas;

  • colunas;

  • imagens;

  • relações hierárquicas.

Isso muda completamente o jogo.


PDF não é banco de dados

Esse talvez seja o conceito mais importante para um programador COBOL entender.

Durante anos trabalhamos com:

  • VSAM

  • DB2

  • IMS

  • Sequential Files

Todos possuem estrutura.

Um PDF não.

Ele é praticamente uma fotografia.

Extrair informação dele sempre foi difícil.

Bibliotecas antigas conseguiam apenas:

Texto

Texto

Texto

Texto

As tabelas desapareciam.

As colunas eram misturadas.

Os totais se perdiam.

O Docling preserva a estrutura.

Isso faz toda diferença.


O exemplo do tutorial

O exemplo utilizado é bastante interessante.

O usuário deseja um sistema capaz de:

  • receber vários PDFs;

  • identificar Ordens de Compra;

  • extrair fornecedores;

  • consolidar produtos;

  • calcular totais;

  • exportar CSV.

Nada extraordinário.

Mas observe como Bob trabalha.

Primeiro ele cria um documento chamado:

requirements-intent.md

Esse documento representa apenas a intenção.

Não existe código.


A IA faz perguntas

Em seguida Bob começa a agir como um Analista de Sistemas.

Ele pergunta:

Existe autenticação?

O processamento será paralelo?

Quantos PDFs?

Como tratar falhas?

É exatamente o tipo de pergunta que um analista humano faria.

Essa talvez seja a parte mais impressionante do tutorial.

A IA deixa de ser um "digitador automático".

Ela passa a participar do entendimento do problema.


A especificação técnica

Depois das respostas surge automaticamente:

TECHNICAL_SPEC.md

Esse documento contém:

  • visão geral;

  • arquitetura;

  • APIs;

  • diretórios;

  • modelos;

  • diagramas Mermaid;

  • componentes.

Quem trabalhou com metodologias tradicionais certamente lembrou imediatamente dos antigos documentos de Análise Estruturada.

A diferença é que agora eles são produzidos automaticamente.


A arquitetura

O sistema criado segue uma arquitetura bastante limpa.

Carbon Design

↓

Flask

↓

Upload

↓

Docling

↓

Markdown

↓

Parser

↓

Analytics

↓

CSV

Observe que cada componente possui responsabilidade única.

Esse princípio é chamado de Separation of Concerns.

É exatamente o mesmo conceito utilizado em aplicações CICS modernas.


O Carbon Design

Outro elemento importante é o Carbon Design System.

Programadores COBOL normalmente não trabalham com interfaces gráficas.

Mas vale entender sua importância.

O Carbon é para aplicações Web aquilo que o ISPF foi para o z/OS.

Um conjunto padronizado de componentes.

Botões.

Menus.

Formulários.

Tabelas.

Ícones.

Tudo consistente.

Isso reduz muito o esforço de desenvolvimento.


O Parser

Após o Docling converter o PDF em Markdown estruturado entra em ação o Parser.

Sua função lembra muito um programa COBOL Batch.

Entrada:

Markdown

Saída:

Objetos estruturados

Ele identifica:

  • fornecedor;

  • data;

  • produto;

  • quantidade;

  • preço;

  • total.

Ou seja, transforma texto em registros.

É praticamente um ETL.


O módulo Analytics

Depois do Parser vem o Analytics.

Aqui os dados passam a ser consolidados.

Por fornecedor.

Por produto.

Por ordem de compra.

Por valor.

Isso lembra bastante programas COBOL responsáveis por gerar relatórios financeiros.

A diferença é que agora os dados vieram de documentos PDF.


O momento mais interessante

Durante os testes algo falha.

Um teste unitário acusa erro.

O parser não tratava corretamente valores:

None

O que Bob faz?

Não pergunta ao usuário.

Não pede ajuda.

Ele:

  • localiza o erro;

  • altera apenas o trecho necessário;

  • executa novamente os testes.

Todos passam.

Esse comportamento lembra muito práticas modernas de DevOps.


Testes primeiro, confiança depois

Durante muitos anos ouvi uma frase:

"Meu programa compilou."

No mundo atual isso significa muito pouco.

O importante é:

Os testes passaram?

No tutorial vemos:

  • testes unitários;

  • testes de integração;

  • validação completa.

Esse é exatamente o fluxo esperado em engenharia moderna.


O resultado final

A aplicação permite:

✔ Upload de múltiplos PDFs

✔ Processamento automático

✔ Extração inteligente

✔ Consolidação

✔ Dashboard

✔ Exportação CSV

Tudo produzido praticamente a partir de documentação.


O que isso significa para um Programador COBOL?

Talvez você esteja pensando:

"Isso serve apenas para aplicações Web."

Na verdade, não.

Imagine adaptar exatamente esse fluxo para o Mainframe.

Recebemos diariamente:

  • SYSOUT

  • JES2

  • SMF

  • RMF

  • Dumps

  • Relatórios RACF

  • Catálogos

  • Logs IMS

  • Logs CICS

  • JCLs

  • Listings COBOL

  • EXPLAIN PLAN do Db2

  • Documentação técnica

  • Procedimentos operacionais

Todos esses documentos poderiam ser processados pelo Docling.

Depois enviados ao Granite.

Depois consultados via RAG.

Imagine perguntar:

"Mostre todos os programas COBOL que utilizam o arquivo CLIENTES e fazem EXEC CICS XCTL."

Ou então:

"Quais jobs executam depois do fechamento do movimento financeiro?"

Ou ainda:

"Explique este ABEND S0C7 utilizando os padrões encontrados em incidentes anteriores."

Essa é exatamente a direção para onde a engenharia de software está caminhando.


Uma analogia com o Batch

Podemos comparar todo esse fluxo com um Job Batch.

INPUT

↓

Validação

↓

Transformação

↓

Classificação

↓

Consolidação

↓

Relatório

↓

OUTPUT

A diferença é que agora o INPUT é um PDF.

E parte do processamento é realizada por modelos de IA.


O futuro do Analista de Sistemas

Durante muito tempo acreditou-se que IA substituiria programadores.

Na prática, o que observamos é diferente.

Ela está assumindo tarefas repetitivas:

  • documentação;

  • geração de código;

  • testes;

  • revisão;

  • correção.

Mas continua dependendo do conhecimento humano para:

  • entender regras de negócio;

  • validar arquitetura;

  • decidir prioridades;

  • compreender impactos.

Ou seja, o papel do analista se torna ainda mais estratégico.


Lições para quem está começando em COBOL

Se você é um Programador COBOL Júnior, talvez pense que precisa aprender apenas sintaxe.

Não.

A sintaxe muda.

Os princípios permanecem.

Aprenda:

  • análise de requisitos;

  • modelagem;

  • documentação;

  • arquitetura;

  • testes;

  • versionamento;

  • integração;

  • observabilidade.

Esses conhecimentos continuarão valiosos independentemente da linguagem utilizada.


Conclusão

O tutorial da IBM demonstra algo muito maior do que uma nova ferramenta.

Ele mostra que a Inteligência Artificial está amadurecendo.

Em vez de simplesmente gerar código, ela começa a participar de todo o ciclo de desenvolvimento:

  • entende o problema;

  • faz perguntas;

  • escreve especificações;

  • projeta arquitetura;

  • implementa;

  • testa;

  • corrige;

  • valida.

Para nós, profissionais de Mainframe, essa evolução é particularmente interessante.

Durante décadas aprendemos que um bom sistema nasce de uma boa especificação, de uma arquitetura sólida e de testes rigorosos. O IBM Bob resgata exatamente essa disciplina, agora potencializada pela IA. O Docling, por sua vez, amplia a capacidade de transformar documentos corporativos em informação estruturada, aproximando o universo dos PDFs, contratos, relatórios e ordens de compra das aplicações inteligentes baseadas em IA.

No fim das contas, a maior lição não é tecnológica, mas metodológica: o futuro pertence aos profissionais que sabem compreender o negócio antes de escrever código. Linguagens, frameworks e ferramentas continuarão evoluindo, mas a capacidade de analisar problemas, projetar soluções e garantir qualidade continuará sendo o verdadeiro diferencial de um engenheiro de software — seja ele programando em COBOL no IBM Z, em Python na nuvem ou utilizando agentes inteligentes como o IBM Bob.


quinta-feira, 2 de abril de 2026

☕ O Holocron do Agente IBM Bob Como um Padawan COBOL Pode Aprender com um Companheiro de IA Criado pela IBM

 

Bellacosa Mainframe e o ibm bob

☕ O Holocron do Agente IBM Bob

Como um Padawan COBOL Pode Aprender com um Companheiro de IA Criado pela IBM para Entender, Modernizar e Construir Sistemas Empresariais

"Os antigos Mestres decoravam milhares de comandos. Os novos Mestres ensinam agentes a trabalhar ao seu lado."


Introdução

Durante décadas, um desenvolvedor IBM Z precisava carregar consigo uma espécie de biblioteca mental.

Era necessário conhecer:

  • COBOL

  • JCL

  • DB2

  • VSAM

  • CICS

  • RACF

  • SDSF

  • ISPF

  • MQ

  • Java

  • APIs REST

  • Git

  • Jenkins

  • Ansible

  • OpenShift

Além disso, precisava compreender regras de negócio escritas há quarenta anos por analistas aposentados, interpretar copybooks obscuros e descobrir por tentativa e erro qual programa atualiza determinada tabela.

Em 2025 a IBM decidiu mudar essa história.

Nascia o Project Bob.

Em 2026 ele finalmente se tornou disponível como produto.

O objetivo é bastante ambicioso:

Ter um agente inteligente capaz de acompanhar todo o ciclo de vida do software corporativo.

Não apenas sugerir linhas de código.

Mas pensar junto.

Planejar.

Explicar.

Refatorar.

Gerar testes.

Documentar.

Modernizar aplicações.

Encontrar defeitos.

Auditar segurança.

Criar APIs.

Auxiliar equipes inteiras.

Para um Padawan COBOL, Bob talvez seja a ferramenta mais interessante surgida desde o lançamento do Enterprise COBOL 6.x.


O que é IBM Bob?

IBM Bob é um AI Coding Agent desenvolvido pela IBM.

Diferentemente dos copilotos tradicionais, Bob trabalha como um agente de desenvolvimento.

Ele atua durante praticamente todo SDLC.

SDLC significa:

Software Development Life Cycle.

Bob pode ajudar em:

Planejamento

Análise

Codificação

Testes

Documentação

Segurança

Modernização

Entrega

Em vez de apenas responder perguntas, Bob executa fluxos completos de trabalho.

IBM chama isso de:

Agentic Development

ou

Agentic SDLC


A origem do Projeto

Bob não apareceu do nada.

Ele é resultado da convergência de vários projetos IBM.

Watsonx Code Assistant for Z

Lançado em 2023.

Objetivo:

Auxiliar modernização COBOL.

Funções:

Explicar código

COBOL → Java

Gerar documentação

Analisar aplicações


Code Assistant for RPG

Criado pelo laboratório Rochester.

Focado em IBM i.


Granite

LLM desenvolvido pela IBM.


Anthropic Claude

IBM anunciou parceria para ampliar capacidades de engenharia.


Em outubro de 2025, durante o TechXchange, surgiu oficialmente:

Project Bob

Em março de 2026 surgiu a primeira versão pública.

Versão:

Bob 1.0

Data aproximada de disponibilidade:

24 Março 2026.

Atualmente existe inclusive um pacote denominado:

IBM Bob Premium Package for Z.


Por que o nome Bob?

IBM nunca divulgou oficialmente uma explicação definitiva.

Mas existe uma curiosidade interessante.

Muitos desenvolvedores brincam dizendo:

Bob é o "Bob The Builder" corporativo.

Ele não destrói aplicações.

Ele conserta.

Moderniza.

Documenta.

Amplia.

Protege.

Algo extremamente alinhado ao universo IBM Z.

Em vez de substituir programadores, Bob funciona como um companheiro.


O que Bob consegue fazer?

1 — Explicar COBOL

Prompt:

Explique este programa COBOL.

Bob responde:

Regras de negócio

Arquivos usados

Campos

Dependências

Fluxos

Excelente para sistemas bancários.


2 — Criar documentação

/document

Pode gerar:

Markdown

README

Diagramas

Comentários

Arquitetura


3 — Testes

Exemplo:

/unit-test

Pode produzir:

JUnit

PyTest

Testes Java

Estruturas automatizadas


4 — Revisão de código

Pergunta:

Existem problemas neste programa COBOL?

Bob pode apontar:

PERFORM incorreto

GO TO excessivo

dead code

duplicação

bugs


5 — Segurança

Detecta:

SQL Injection

credenciais

falhas


6 — Modernização

Talvez seja a parte mais interessante.

Bob consegue auxiliar:

COBOL

Serviços COBOL

APIs

Java


Onde usar Bob?

Atualmente Bob trabalha principalmente integrado ao:

Visual Studio Code

CLI

Ambientes SaaS

IBM Cloud

Sistemas:

Windows

Linux

MacOS


Como testar gratuitamente

Passo 1

Criar conta IBM.

Passo 2

Solicitar Trial.

Acesse:

IBM Bob

ou

bob.ibm.com


Passo 3

Instalar VSCode


Passo 4

Instalar extensão

IBM Bob


Passo 5

Login

IBM ID


Passo 6

Abrir projeto

COBOL

Python

Java


Passo 7

Conversar

Exemplo:

Explique este COPYBOOK

Documente este programa

Crie testes

Faça refatoração

Sugira API REST


Primeiro laboratório para um Padawan COBOL

Pegue um programa antigo.

Exemplo:

CALCSAL.cbl

Pergunte:

Explique este programa.

Depois:

Crie documentação Markdown.

Depois:

Gere casos de teste.

Depois:

Sugira melhoria COBOL 6.5.

Depois:

Transforme em serviço REST.

Você verá praticamente um assessment sendo realizado em minutos.


Comandos interessantes

Embora Bob esteja evoluindo, comandos similares aos usados no WCA aparecem frequentemente.

/document

Documentação


/unit-test

Testes


/review

Code review


/explain

Explicação


/refactor

Refatoração


/security

Auditoria


/plan

Planejamento


/generate

Código novo


Exemplo prático

Pergunta:

Tenho um programa COBOL que atualiza saldo de conta.

Bob pode responder:

Programa principal identificado.

Copybooks encontrados.

Tabela DB2 utilizada.

Transação CICS relacionada.

Dependências localizadas.

Sugestão de API:

GET /saldo

POST /debito

POST /credito

Em alguns minutos.

Algo que antigamente levava dias.


Curiosidades

Bob utiliza arquitetura multi-modelo.

Pode combinar:

Granite

Claude

Llama

Mistral

Dependendo da tarefa.


Mais de seis mil desenvolvedores IBM já utilizavam Bob internamente antes do lançamento público.


Bob é considerado sucessor natural do:

Watsonx Code Assistant for Z


Existe forte foco em:

COBOL

PL/I

RPG

Java

JCL

Mainframe


Dicas para começar

Dica 1

Não tente gerar sistemas inteiros.

Comece pequeno.


Dica 2

Use programas COBOL simples.

100 linhas.

200 linhas.


Dica 3

Peça explicações.

Aprenda observando.


Dica 4

Valide tudo.

IA erra.

Sempre.


Dica 5

Construa biblioteca própria.

Prompts úteis:

Explique para um iniciante.

Mostre fluxograma.

Identifique regras.

Crie README.

Faça ZUnit.

Gerar OpenAPI.

Criar testes.

Migrar para COBOL 6.5.


Como aprofundar conhecimentos

Estude:

Enterprise COBOL 6.5

VSCode

Zowe

Git

OpenAPI

REST

JUnit

Ansible

Watsonx

Granite

RAG

MCP Servers

Agentic AI

Leia documentação IBM.

Assista TechXchange.

Teste diariamente.

Uma hora por dia é suficiente.


Considerações Finais

O IBM Bob representa uma mudança semelhante à chegada do ISPF para quem programava apenas com editores lineares.

Ele não substitui experiência.

Não conhece sozinho todas as regras de negócio.

Não entende automaticamente quarenta anos de exceções bancárias.

Mas reduz drasticamente o tempo gasto procurando informações espalhadas em milhares de programas.

Para o Padawan COBOL, Bob pode ser visto como um novo Holocron.

Um Holocron que não apenas guarda conhecimento, mas conversa, explica, ensina, sugere melhorias e ajuda a transformar aplicações legadas em ativos preparados para a próxima década.

E talvez esta seja a maior lição deixada pelo agente da IBM:

O futuro do desenvolvedor Mainframe não será escrever menos COBOL. Será aprender a trabalhar ao lado de agentes capazes de compreender COBOL tão profundamente quanto nós aprendemos a compreendê-lo ao longo dos anos.


terça-feira, 31 de março de 2026

☕ O Holocron do IBM Bob Como um Padawan COBOL Pode Aprender a Trabalhar com um Companheiro de IA Criado pela IBM sem Abandonar o IBM Z

 

Bellacosa Mainframe e uma trilha para aprender o IBM BOB

☕ O Holocron do IBM Bob

Como um Padawan COBOL Pode Aprender a Trabalhar com um Companheiro de IA Criado pela IBM sem Abandonar o IBM Z, o JCL e sua Caneca de Café

Existe um momento na jornada de todo Padawan COBOL em que ele percebe uma verdade desconfortável.

O mundo mudou.

Enquanto passamos décadas aprendendo os segredos do DISP, do DFSORT, do CICS, do Db2, do VSAM e dos utilitários mais obscuros do z/OS, uma nova geração de desenvolvedores começou a conversar com máquinas em linguagem natural e pedir que elas escrevessem código, documentação, testes e até arquiteturas inteiras.

A primeira reação de muitos profissionais experientes costuma ser previsível:

"Isso é modinha."

"IA não entende COBOL."

"Nunca vai substituir um analista de produção."

"Nem sabe o que é um S322."

Talvez.

Mas talvez estejamos olhando para a ferramenta errada.

Porque IBM Bob não nasceu para substituir um especialista IBM Z.

Ele nasceu para trabalhar ao lado dele.

E isso muda completamente a história.

O que é o IBM Bob?

Imagine um aprendiz extremamente dedicado.

Ele nunca dorme.

Não reclama.

Lê milhares de páginas de documentação em segundos.

Conhece APIs.

Conhece padrões modernos.

Entende agentes.

Consegue construir ferramentas.

Escreve testes.

Produz documentação.

Sugere modernizações.

Ajuda a criar MCP Servers.

Conversa com o watsonx.

Integra-se ao Orchestrate.

Pode inclusive auxiliar equipes inteiras durante o ciclo de desenvolvimento.

Esse aprendiz atende pelo nome de IBM Bob.

Bob pode ser visto como um companheiro de desenvolvimento baseado em IA, desenhado para apoiar atividades do ciclo de vida de software e construção de agentes corporativos.

Mas existe um detalhe importante.

Bob não conhece seu ambiente.

Ele não conhece sua instalação.

Ele não conhece suas convenções.

Ele não sabe onde estão seus copybooks.

Ele não entende por que aquele JOB roda somente às quartas-feiras às 02h37 da manhã.

Você sabe.

E é exatamente por isso que você continua sendo importante.


O Erro que Muitos Padawans Cometem

Muitos profissionais COBOL observam ferramentas de IA e concluem:

"Isso é para programadores Python."

Não.

Na verdade, talvez sejamos justamente os profissionais mais preparados para utilizá-las.

Quem trabalhou em Mainframe desenvolveu habilidades raras:

Pensamento sistêmico.

Modelagem de negócios.

Análise de impacto.

Governança.

Segurança.

Auditoria.

Confiabilidade.

Capacidade de compreender aplicações escritas há quarenta anos.

E IA gosta de contexto.

IA gosta de conhecimento estruturado.

IA gosta de especialistas.

Ela precisa de mestres para guiá-la.

O futuro não pertence ao desenvolvedor que apenas escreve código.

Pertence ao profissional capaz de ensinar máquinas a compreender sistemas complexos.


A Trilha do Padawan IBM Bob

Resolvi montar uma trilha de oito semanas.

Nada impossível.

Nada acadêmico.

Nada de cursos infinitos de vinte horas falando sobre redes neurais.

Apenas uma jornada prática.

Semana 1 — Entender o Ecossistema IBM AI

Objetivo:

Compreender o que existe ao redor de Bob.

Estude:

  • watsonx.ai

  • Granite

  • watsonx.data

  • watsonx.governance

  • AI Agents

  • MCP

Faça cursos gratuitos no IBM SkillsBuild.

Não tenha pressa.

Seu objetivo não é virar cientista de dados.

Seu objetivo é aprender a conversar com uma nova geração de ferramentas.


Semana 2 — Aprender Agentes

Descubra que um agente não é apenas um chatbot.

Ele pode:

Planejar.

Executar.

Consultar APIs.

Tomar decisões.

Utilizar memória.

Usar ferramentas externas.

Exercício:

Imagine um agente chamado:

COBOL Guru

Pergunte:

Explique este JCL.

Procure copybooks.

Liste dependências.

Estime complexidade.

Perceba algo interessante.

Você já sabe fazer isso.

A diferença é que agora poderá ensinar uma IA a ajudá-lo.


Semana 3 — Conhecer Bob

Leia a documentação.

Entenda seus casos de uso.

Observe demonstrações.

Experimente prompts.

Pergunte:

Analise este programa COBOL.

Gere documentação.

Escreva testes.

Sugira APIs.

Crie OpenAPI.

Identifique código morto.

Comece pequeno.

Um programa.

Depois dez.

Depois cem.


Semana 4 — Watsonx Orchestrate

Aqui a mágica começa.

Bob deixa de ser apenas um assistente.

Passa a participar de fluxos empresariais.

Skill.

Ferramenta.

Agente.

Processo.

Orquestração.

E então você percebe algo curioso.

É quase como desenhar uma aplicação CICS moderna.

Só que utilizando IA.


Semana 5 — Descobrir MCP

MCP talvez seja uma das tecnologias mais interessantes surgidas recentemente.

Em vez de pedir que uma IA adivinhe informações, você oferece ferramentas para que ela consulte dados reais.

Imagine um MCP chamado:

BellacosaMainframeServer

Com funções:

analyze_jcl()

find_copybook()

search_db2()

locate_cics_program()

find_dead_code()

estimate_batch_window()

De repente Bob deixa de ser um chatbot.

Ele se torna um analista júnior extremamente produtivo.


Semana 6 — Hands-on

Construa.

Erre.

Experimente.

Quebre.

Reconstrua.

Peça:

Bob, documente esta aplicação.

Depois:

Gere casos de teste.

Depois:

Crie APIs REST.

Depois:

Produza Markdown.

Depois:

Gere Swagger.

Pouco a pouco você perceberá que Bob não elimina conhecimento COBOL.

Ele amplia seu alcance.


Semana 7 — Mainframe Modernization

Pegue um sistema real.

COBOL.

JCL.

Db2.

VSAM.

CICS.

E pergunte:

O que pode ser modernizado?

O que pode virar API?

O que está obsoleto?

O que nunca é utilizado?

Você ficará surpreso.

Bob pode sugerir caminhos.

Mas somente um profissional experiente saberá decidir quais realmente fazem sentido.


Semana 8 — O Projeto Final

Construa algo seu.

Um sonho.

Um laboratório.

Um produto.

Um experimento.

Sugiro:

Bellacosa Bob for Mainframe

Capaz de:

Receber COBOL.

Analisar JCL.

Documentar aplicações.

Gerar testes.

Produzir OpenAPI.

Encontrar dependências.

Responder perguntas.

Criar artigos.

Explicar abends.

Mapear datasets.

Imagine um novo colega dizendo:

Bom dia.

Detectei cinco programas sem testes.

Há três copybooks duplicados.

Posso gerar documentação.

Deseja continuar?

Quem recusaria ajuda?


O Conselho de um Mestre para os Padawans COBOL

Durante anos ouvimos previsões sobre a morte do Mainframe.

Elas vieram.

E foram embora.

O IBM Z continua processando transações, cartões, seguros, governos, bolsas de valores e sistemas críticos do planeta.

Agora surge uma nova onda.

IA.

Agentes.

MCP.

Orquestração.

Granite.

Bob.

E novamente alguns profissionais ficarão olhando de longe.

Esperando passar.

Outros decidirão estudar.

Experimentar.

Errar.

Construir.

Compartilhar.

E descobrirão que a IA não veio para apagar décadas de experiência.

Veio para amplificar aquilo que os especialistas IBM Z sempre tiveram de mais valioso:

Conhecimento.

Contexto.

Disciplina.

Arquitetura.

Curiosidade.

Portanto, jovem Padawan COBOL, coloque mais café na caneca.

Abra o SkillsBuild.

Explore o Bob.

Construa seu primeiro agente.

Crie seu primeiro MCP.

Converse com o futuro.

E lembre-se:

A Força pode estar nos prompts, mas a verdadeira sabedoria continua residindo em quem conhece o significado de um DISP=(MOD,CATLG,DELETE), de um Abend U4038 e da responsabilidade de manter funcionando sistemas que movimentam bilhões de registros todos os dias.

Que os Holocrons do IBM Z estejam com você.


domingo, 22 de março de 2026

Como um Padawan COBOL Pode Aprender a Trabalhar com um Companheiro de IA Criado pela IBM sem Abandonar o IBM Z, o JCL e sua Caneca de Café

Bellacosa Mainframe estuda o IBM BOB


☕ O Holocron do IBM Bob

Como um Padawan COBOL Pode Aprender a Trabalhar com um Companheiro de IA Criado pela IBM sem Abandonar o IBM Z, o JCL e sua Caneca de Café

"O medo de perder conhecimento leva ao caos. O caos leva à reescrita em Java. A reescrita em Java leva ao sofrimento."
— Mestre Sysprog Yoda, Sala de Operações do JES2, aproximadamente 03:17 da manhã.


Existe um momento na jornada de todo Padawan COBOL...

Existe um momento na jornada de todo Padawan COBOL em que ele percebe uma verdade desconfortável.

A aplicação que ele acabou de receber para manutenção possui mais de trinta anos.

Não existe documentação.

O analista funcional aposentou-se em 2014.

O arquiteto virou diretor.

O programador original mora em alguma praia do Nordeste e provavelmente desligou seu pager em 1998.

Os diagramas UML nunca existiram.

Os requisitos estão enterrados em milhares de linhas de COBOL, dezenas de PROCs catalogadas, JCLs obscuros, COPYBOOKS compartilhados por cinquenta programas diferentes, packages DB2 esquecidos, mapas BMS, tabelas VSAM, MQs espalhadas pela infraestrutura e algum código assembler que ninguém ousa tocar.

Você abre o primeiro programa.

São apenas 18 mil linhas.

Respira aliviado.

Até descobrir que ele faz PERFORM em outros vinte programas.

E então surge a pergunta inevitável.

"Será que existe alguma IA capaz de entender tudo isso?"

Talvez.

E talvez ela tenha um nome curioso.

IBM Bob.

Hoje vamos abrir mais um Holocron do Bellacosa Mainframe e conversar sobre aquilo que talvez seja uma das iniciativas mais interessantes da IBM para os próximos anos.


O que é o IBM Bob?

IBM Bob é apresentado como um assistente inteligente para desenvolvimento de software baseado em Inteligência Artificial.

Mas chamá-lo apenas de um gerador de código é diminuir bastante sua ambição.

Na prática, Bob parece querer ocupar um espaço muito maior.

Ele deseja ser:

  • Desenvolvedor auxiliar;

  • Revisor de código;

  • Especialista em documentação;

  • Tutor técnico;

  • Ferramenta de onboarding;

  • Auditor de segurança;

  • Agente de produtividade;

  • Companheiro corporativo de engenharia.

Talvez a melhor definição seja:

IBM Bob é uma tentativa da IBM de construir um "engenheiro de software virtual" especializado em ambientes empresariais.


IBM já tentou isso antes

A ideia não é nova.

IBM possui uma longa tradição em criar ferramentas para aumentar a produtividade.

DécadaFerramenta
1960FORTRAN Compiler
1970ISPF
1980CSP
1990VisualAge
2000Rational Rose
2010Bluemix
2020Watson
2025watsonx
2026IBM Bob

Existe uma espécie de evolução natural.

Antigamente tínhamos compiladores.

Depois IDEs.

Posteriormente ALM.

Mais tarde plataformas cloud.

Agora temos companheiros cognitivos.

Bob pode ser visto como uma mistura de:

  • GitHub Copilot

  • Rational Assistant

  • Watsonx

  • ChatGPT

  • Knowledge Assistant

Tudo isso embalado para empresas.


O problema que IBM está tentando resolver

Existe uma crise silenciosa acontecendo.

E ela não é tecnológica.

Ela é humana.

Estamos perdendo especialistas.

Todos os dias.

Pessoas que conhecem:

CICS

IMS

PL/I

COBOL

Natural

IDMS

JCL

Netview

SA z/OS

RACF

DB2

MQ

GDPS

SMP/E

RMF

SMF

SAF

VTAM

estão se aposentando.

E conhecimento não documentado possui meia vida curta.

Quando o especialista sai, o sistema continua.

Mas o entendimento desaparece.

Bob parece ser uma tentativa de capturar parte dessa inteligência institucional.


O maior erro do artigo original

O artigo que motivou esta discussão é bastante interessante.

Mas possui uma lacuna gigantesca.

Praticamente ignora o Mainframe.

E justamente aí está talvez a maior oportunidade do IBM Bob.

IBM possui bilhões de linhas COBOL instaladas.

Bilhões.

Sistemas que movimentam:

Cartões.

PIX.

Seguros.

Bolsas.

Impostos.

Benefícios sociais.

Compensação bancária.

Passagens aéreas.

Energia elétrica.

Telecomunicações.

Saúde.

Previdência.

Esses sistemas não vão desaparecer.

Eles precisam ser compreendidos.

E compreendê-los custa caro.

Muito caro.


Imagine conversar com um sistema legado

Imagine abrir um chat.

Perguntar:

Explique PROGCBL1.

Bob responde.


Sistema responsável pela liquidação diária.

Arquivos utilizados:

CLIENTES.KSDS

MOVTO.PS

Dependências:

DB2

MQ

CICS

Programas chamados:

CBL100

CBL200

CBL991

Pontos críticos:

Falta tratamento SQLCODE +100.

Possível deadlock.

Campo SALDO alterado em três locais.


Pronto.

Dias de investigação reduzidos para minutos.


O Holocron dos COPYBOOKS Perdidos

Todo Padawan COBOL conhece esse momento.

Você encontra:

COPY CLI0001

COPY BAN0007

COPY FIS9999

COPY SEG1234

Pergunta:

"Onde estão?"

Ninguém sabe.

Bob poderia consultar:

Git

Endevor

Changeman

Panvalet

Librarian

PDS

PDSE

e responder.


COPY SEG1234

Localização:

CORP.COBOL.COPYLIB

Última alteração:

15/03/2024

Responsável:

Equipe Seguros

Campos utilizados:

CPF

SALDO

RISCO

TIPO_APOLICE


Você acabou de economizar duas horas.


O poder do entendimento semântico

Talvez a maior revolução seja essa.

Não escrever código.

Entender sistemas.

Pergunta:

Quem atualiza SALDO_DISPONIVEL?

Resposta:

PROG010

PROG200

TRN991

JOBNIGHT

Impacto:

17 programas.

Possíveis efeitos colaterais:

Extrato.

PIX.

TED.

Internet Banking.


Isso é engenharia reversa inteligente.


Bob poderia ser o arqueólogo corporativo

Hoje fazemos arqueologia manual.

ISPF.

3.14.

3.4.

SUPERC.

FILEAID.

SPUFI.

SDSF.

JES2.

TSO.

Bob poderia atuar como um arqueólogo digital.

Encontrando relações invisíveis.


O sonho do Sysprog

Imagine perguntar.


Explique este JCL.


Resposta:

Job diário.

Executa às 23h.

Consome 4 CPUs.

Lê VSAM.

Executa DFSORT.

Atualiza DB2.

Publica mensagem MQ.

Gera SMF.

Último ABEND:

S806.

Ocorrências:


Ou então.


Por que ocorreu este ABEND?


S0C7

Campo NUMERO-CONTA possui dados inválidos.

Registro 145783.

Programa:

COBLIQ01

Parágrafo:

3000-PROCESSA


Isso seria quase magia.

Mas magia suficientemente avançada é indistinguível da tecnologia.


O problema dos LLMs

Nem tudo são flores.

Existe um problema sério.

LLMs alucinam.

E sistemas corporativos não aceitam alucinações.

Bob não pode inventar.

Não pode responder.

"Talvez."

Em bancos.

Talvez custa milhões.

Portanto provavelmente Bob utilizará RAG.

Retrieval Augmented Generation.

Consultando:

Catálogos.

DB2 Catalog.

Git.

Endevor.

SMF.

SDSF.

WLM.

RMF.

Copybooks.

Documentação interna.

Tickets Jira.

Confluence.

Runbooks.


Segurança

Este é provavelmente o aspecto mais importante.

Um banco não pode enviar CPF para um LLM público.

Nem dados médicos.

Nem cartões.

Nem chaves PIX.

Bob precisa viver próximo dos dados.

Talvez em:

LinuxONE.

OpenShift.

Cloud privada.

IBM Z.

Com recursos de:

LGPD.

PCI DSS.

SOX.

Mascaramento.

Auditoria.

Guardrails.

Zero Trust.


O verdadeiro diferencial

Acredito que Bob cometeria um erro enorme tentando competir diretamente com Copilot.

Copilot escreve código.

Bob deveria compreender empresas.

Ele deveria ser especialista em:

CICS.

IMS.

MQ.

COBOL.

JCL.

DB2.

VSAM.

RACF.

SA z/OS.

Netview.

GDPS.

WLM.

DFSMS.

SMP/E.


Prompt:

Crie API REST para este COBOL.

Resposta:

OpenAPI.

JSON.

COBOL parser.

z/OS Connect.

Swagger.

JCL Deploy.

Tudo documentado.


O Holocron Vivo da Empresa

Talvez seja essa a visão mais bonita.

Bob não substituirá desenvolvedores.

Ele preservará memória.

Será um Holocron corporativo.

Um aprendiz conversa.

Pergunta.

Aprende.

Entende.

Documenta.

Compartilha.

E a empresa deixa de depender exclusivamente da memória de poucas pessoas.


O futuro pertence aos desenvolvedores que sabem conversar com IA

Muitos têm medo.

"IA vai substituir programadores."

Talvez substitua quem apenas copia código.

Mas dificilmente substituirá quem entende negócio.

Quem entende processamento batch.

Quem entende compensação bancária.

Quem conhece JES2.

Quem domina CICS.

Quem compreende RACF.

Quem sabe porque um catálogo ICF ficou inconsistente às três da manhã.

Esses profissionais continuarão valiosos.

Talvez ainda mais.

Porque agora terão um novo aliado.

Um companheiro.

Um assistente.

Um aprendiz digital.

Um pequeno droide azul corporativo.

Um Bob.


Considerações Finais

Existe uma frase muito conhecida na comunidade de tecnologia:

"Todo sistema legado é apenas um sistema que continua pagando as contas."

IBM conhece essa realidade melhor do que ninguém.

E talvez o IBM Bob seja uma das primeiras tentativas realmente sérias de transformar cinquenta anos de conhecimento corporativo em algo conversável, pesquisável e ensinável.

Se conseguir compreender verdadeiramente COBOL, JCL, CICS, IMS, DB2, VSAM e os inúmeros segredos escondidos nos data centers do planeta, Bob poderá se tornar muito mais do que um assistente de programação.

Ele poderá tornar-se o primeiro grande Holocron do Mainframe Moderno.

E para nós, Padawans COBOL, isso significa algo extraordinário.

Pela primeira vez em décadas, talvez seja possível sentar diante de um sistema com quarenta anos de idade, tomar uma caneca de café, fazer uma pergunta simples e ouvir uma resposta compreensível.

E convenhamos...

Isso parece muito mais próximo da Força do que da simples Inteligência Artificial.