Translate

quarta-feira, 1 de julho de 2026

Rakudai Kenja no Gakuin Musou: Quando um "Backup" de 400 Anos Derrota Todo o Sistema — A Análise Definitiva do Isekai que Mostra o Poder do Conhecimento Acumulado

 

Bellacosa Mainframe apresenta o isekai do isekai

☕ Um Café no Bellacosa Mainframe

Rakudai Kenja no Gakuin Musou: Quando um "Backup" de 400 Anos Derrota Todo o Sistema — A Análise Definitiva do Isekai que Mostra o Poder do Conhecimento Acumulado

"No Mainframe existe um ditado: experiência vale mais do que hardware novo. Em Rakudai Kenja no Gakuin Musou, essa ideia ganha forma em um mago que renasce quatro séculos no futuro e descobre que seu conhecimento antigo virou uma tecnologia perdida."


Ficha Técnica

ItemInformação
Título Original落第賢者の学院無双 ~二度目の転生、Sランクチート魔術師冒険録~
RomanizaçãoRakudai Kenja no Gakuin Musou: Nidome no Tensei, S-Rank Cheat Majutsushi Boukenroku
Título em inglêsFrom Overshadowed to Overpowered
AutorArata Shiraishi
Ilustrações (Light Novel)Fuu Midori
MangáKentarō
GêneroFantasia, Isekai, Reencarnação, Academia de Magia, Ação, Aventura
Classificação14+
AnimeEstreia em julho de 2026
EstúdioEMT Squared

O que significa o título?

Traduzindo livremente:

"A Academia Invencível do Sábio Reprovado: A Segunda Reencarnação de um Mago Cheat Rank S."

Só pelo nome já entendemos praticamente toda a história.

É um daqueles títulos enormes típicos das Light Novels modernas que praticamente funcionam como uma sinopse.


Sinopse

Ephtal dedicou sua primeira vida inteira ao estudo da magia.

Seu problema?

Ele nasceu sem talento.

Apesar de ser considerado um fracasso, passou décadas pesquisando, criando teorias e estudando tudo sobre magia.

Quando morre, reencarna aproximadamente 400 anos depois.

Nesse novo mundo...

A magia evoluiu?

Não.

Ela regrediu.

Todo o conhecimento perdido faz dele praticamente um deus entre os magos modernos.

É como um programador COBOL dos anos 80 chegando hoje e descobrindo que ninguém mais sabe escrever um SORT corretamente.


Resumo

A obra mistura:

  • Academia

  • Fantasmas do passado

  • Evolução pessoal

  • Magia científica

  • Aventuras

  • Conspirações

  • Poder absoluto

Mas tudo gira em torno de uma ideia muito interessante:

Conhecimento nunca desaparece. Apenas espera alguém capaz de compreendê-lo novamente.


A História

Diferente de muitos isekais onde o protagonista ganha poderes de um deus, aqui o poder já existia.

O diferencial é que:

Ephtal conquistou tudo estudando.

Sua primeira vida foi praticamente um laboratório.

Sua segunda vida é apenas o momento de colher os resultados.

Isso aproxima muito a narrativa da ideia de pesquisa científica.


O que existe de diferente?

Aqui está a grande diferença.

Normalmente os protagonistas OP possuem:

  • bênção divina;

  • sistema RPG;

  • habilidade roubada;

  • reencarnação milagrosa.

Ephtal não.

Seu "cheat" é:

Conhecimento.

Ele domina teoria.

Conhece fundamentos.

Entende estruturas mágicas esquecidas.

É quase um engenheiro restaurando um sistema legado.


A visão Bellacosa Mainframe

Imagine um Sysprog IBM Z.

Durante quarenta anos ele estudou:

  • JES2

  • RACF

  • VTAM

  • CICS

  • SMP/E

  • HCD

  • IPL

  • Catalog

  • WLM

Agora imagine que ele acorda em 2426.

Todo mundo só sabe usar interfaces gráficas.

Ninguém entende como o sistema realmente funciona.

Esse Sysprog pareceria um mago.

É exatamente isso que acontece com Ephtal.


Os Personagens

Ephtal

Extremamente inteligente.

Calmo.

Analítico.

Nunca entra em pânico.

Lembra muito protagonistas como:

  • Anos Voldigoad

  • Shin Wolford

  • Ainz Ooal Gown

Mas possui personalidade menos arrogante.


As colegas da Academia

Funcionam como:

  • aliadas;

  • aprendizes;

  • futuras parceiras de aventura.

Também ajudam a mostrar o contraste entre a magia antiga e a moderna.


Professores

Muitos representam o conservadorismo.

Acham impossível que um estudante saiba mais do que eles.

É uma crítica bastante comum ao ambiente acadêmico.


Aventuras

Durante a série encontramos:

  • exploração de masmorras;

  • batalhas contra monstros;

  • torneios;

  • conflitos políticos;

  • magia proibida;

  • antigas civilizações;

  • recuperação de técnicas esquecidas.

Cada aventura serve para mostrar como o mundo perdeu parte do conhecimento original.


Temáticas

O conhecimento perdido

A maior mensagem.

Civilizações podem evoluir tecnologicamente...

Mas também podem esquecer tecnologias.

Isso aconteceu na História diversas vezes.


Mérito

Ephtal prova que esforço ainda possui valor.

Mesmo após morrer.


Preconceito

Ele foi considerado inútil.

Na verdade apenas vivia na época errada.


Humildade

Mesmo absurdamente poderoso,

continua estudando.


As mensagens ocultas

Há diversas leituras interessantes.

A crítica ao ensino

A academia ensina fórmulas.

Ephtal entende princípios.

É a diferença entre:

decorar comandos

e compreender arquitetura.


A perda do conhecimento

A humanidade frequentemente esquece técnicas importantes.

No mundo real isso ocorreu com:

  • concreto romano;

  • aço de Damasco;

  • manuscritos antigos;

  • bibliotecas destruídas.

No Mainframe acontece algo parecido.

Poucas pessoas conhecem internamente:

  • JES

  • VTAM

  • RACF

  • Assembler


A experiência supera o talento

Talvez seja a maior mensagem da obra.


O Studio EMT Squared

O EMT Squared é conhecido por produzir adaptações de orçamento moderado, normalmente focadas em personagens e narrativa em vez de animação extremamente elaborada.

Entre trabalhos conhecidos estão:

  • Kuma Kuma Kuma Bear

  • Assassin's Pride

  • Drug Store in Another World

  • Fluffy Paradise

Sua característica costuma ser:

  • animação consistente;

  • boa direção de personagens;

  • uso eficiente do orçamento;

  • fidelidade razoável ao material original.

Não é um estúdio comparável em recursos a gigantes como Ufotable, MAPPA ou Kyoto Animation, mas frequentemente entrega adaptações sólidas dentro de sua proposta.


Houve censura?

Até o momento, não há registro de censura relevante envolvendo a light novel, o mangá ou a adaptação em anime.

A obra contém fan service leve e violência típica de fantasia, mas nada que tenha gerado alterações conhecidas por órgãos reguladores ou emissoras.


Impacto cultural

Embora ainda não tenha alcançado o mesmo nível de popularidade de franquias como Mushoku Tensei ou The Misfit of Demon King Academy, a série ganhou espaço entre fãs de protagonistas overpower e reencarnação.

Seu principal diferencial é valorizar conhecimento acumulado em vez de um poder concedido por uma entidade superior, o que dialoga com leitores que apreciam estudo, pesquisa e domínio técnico.


O que um profissional de Mainframe aprende com esse anime?

Muito mais do que parece.

O mundo de Ephtal mostra que:

  • documentação importa;

  • conhecimento precisa ser preservado;

  • tecnologia sem fundamentos enfraquece;

  • especialistas experientes continuam relevantes;

  • legado não é atraso: é patrimônio técnico.

É difícil não enxergar um paralelo com o IBM Z. Assim como o protagonista recupera técnicas esquecidas, muitos profissionais de mainframe mantêm viva uma base de conhecimento que sustenta bancos, seguradoras, governos e grandes empresas.


Vale a pena assistir?

Sim, especialmente se você gosta de:

  • protagonistas extremamente fortes, mas inteligentes;

  • magia tratada quase como ciência;

  • academias de magia;

  • fantasia com exploração de conhecimento antigo;

  • evolução baseada em estudo.

Se procura uma trama cheia de reviravoltas psicológicas ou grande profundidade política, talvez a série não seja a melhor escolha. Seu foco está na diversão, nas batalhas e na satisfação de ver um personagem aplicar décadas de aprendizado para resolver problemas que todos ao seu redor consideram impossíveis.


Nota Bellacosa Mainframe

CritérioNota
História⭐⭐⭐⭐☆ (8,5/10)
Construção do Mundo⭐⭐⭐⭐☆ (8,5/10)
Sistema de Magia⭐⭐⭐⭐⭐ (9,0/10)
Personagens⭐⭐⭐⭐☆ (8,0/10)
Ação⭐⭐⭐⭐☆ (8,5/10)
Originalidade⭐⭐⭐⭐☆ (8,0/10)
Recomendação Geral8,6/10

Conclusão Bellacosa: Rakudai Kenja no Gakuin Musou não reinventa o gênero isekai, mas faz algo raro: transforma o conhecimento acumulado em seu verdadeiro "cheat". Para quem vive o mundo do IBM Z, COBOL ou da administração de sistemas, a mensagem soa familiar: tecnologias mudam, interfaces evoluem, mas quem domina os fundamentos sempre encontra uma forma de fazer o sistema funcionar.

 

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.


LV999 no Murabito: O Programador que Recebeu Autoridade SYSADM no Universo — A Análise Definitiva do Isekai que Hackeia o Próprio Sistema Operacional do Mundo

 



☕ Um Café no Bellacosa Mainframe

LV999 no Murabito: O Programador que Recebeu Autoridade SYSADM no Universo — A Análise Definitiva do Isekai que Hackeia o Próprio Sistema Operacional do Mundo

"No IBM Z existe uma regra simples: privilégios definem o que você pode fazer. Em LV999 no Murabito, o protagonista descobre que o verdadeiro poder não é ter uma classe lendária... é entender como o sistema foi construído."


Ficha Técnica

ItemInformação
Título OriginalLV999の村人 (LV999 no Murabito)
Título InternacionalThe Level 999 Villager
Autor (Light Novel)星月子猫 (Hoshitsuki Koneko)
Ilustradorふーみ (Fuumi)
Mangá岩元健一 (Kenichi Iwamoto)
GêneroIsekai, Fantasia, Ação, Aventura, Mistério, RPG, Drama
DemografiaShounen
Publicação da Novel2016
Mangá2017
AnimeEstreia prevista para 2026
EstúdioBrain's Base
EpisódiosAinda não oficialmente confirmados (espera-se 12 ou 13 na primeira temporada)

Sinopse

Imagine um mundo onde absolutamente tudo funciona como um MMORPG.

Cada pessoa nasce com uma classe.

  • Herói

  • Guerreiro

  • Mago

  • Sacerdote

  • Mercador

  • Ferreiro

  • Aldeão

A classe determina literalmente toda sua vida.

O protagonista nasce como...

Murabito (Aldeão).

A pior classe existente.

Mas existe um detalhe.

Seu nível chega a 999.

A partir desse momento, todas as regras deixam de fazer sentido.


A História

Diferentemente da maioria dos isekais, aqui não acompanhamos alguém que foi atropelado pelo Truck-kun.

Nem um reencarnado.

Nem um invocado.

É um mundo que sempre existiu.

Kagami vive nele desde o nascimento.

Mas ele começa a perceber algo estranho.

Por que existem níveis?

Quem criou esse sistema?

Por que monstros aparecem?

Por que ouro surge após derrotá-los?

Por que as pessoas aceitam tudo isso sem questionar?

Essas perguntas mudam completamente o rumo da obra.

O anime deixa de ser uma aventura RPG e passa a investigar a arquitetura invisível daquele universo.


O Grande Diferencial

Nos primeiros capítulos parece apenas outro anime de protagonista overpower.

Na realidade...

não é.

A história rapidamente muda de direção.

O verdadeiro inimigo não é o Rei Demônio.

É o próprio sistema que controla o mundo.

Essa mudança lembra bastante obras como:

  • Matrix

  • Overlord

  • Log Horizon

  • Deca-Dence

mas mantendo identidade própria.


Personagens Principais

Kagami

O protagonista.

Extremamente inteligente.

Não luta apenas usando força.

Questiona tudo.

É praticamente um "engenheiro reverso" do universo.


Alice

Uma das personagens mais importantes.

Representa o lado emocional da história.

Seu desenvolvimento acompanha o amadurecimento do protagonista.


Rei Demônio

Muito diferente do arquétipo clássico.

Sua existência possui razões muito mais profundas do que simplesmente conquistar o mundo.


Os Heróis

Funcionam quase como processos automatizados.

Executam aquilo que foram programados para fazer.

Sem jamais questionar.


Temática

A obra fala sobre:

  • livre-arbítrio

  • desigualdade social

  • destino

  • meritocracia

  • preconceito

  • inteligência

  • manipulação

  • engenharia social

  • sistemas fechados

  • evolução tecnológica

É muito mais filosófica do que parece.


O que existe de diferente?

Aqui ninguém ganha poder por amizade.

Nem por treinamento milagroso.

O protagonista vence porque entende o funcionamento do sistema.

É quase um administrador de banco de dados descobrindo como o catálogo do DB2 funciona internamente.


A Analogia Bellacosa Mainframe

Imagine que aquele mundo seja um IBM Z.

As classes são o RACF.

Cada usuário recebe um perfil.

USER A
CLASS HERO

USER B
CLASS MAGE

USER C
CLASS MERCHANT

USER D
CLASS VILLAGER

Todos acreditam que isso nunca pode mudar.

Mas Kagami encontra algo equivalente a possuir autoridade SYSADM.

Ele percebe que o sistema inteiro pode ser alterado.

A partir daí, deixa de jogar.

Passa a administrar.

É exatamente a diferença entre:

usar um aplicativo

e

entender o sistema operacional.


Aventura

Cada arco revela um novo nível de complexidade.

Primeiro:

monstros.

Depois:

nações.

Depois:

demônios.

Depois:

a origem das classes.

Depois:

a arquitetura do mundo.

Cada resposta gera perguntas ainda maiores.


Mensagens Ocultas

1. A sociedade aceita regras sem perguntar

Todos vivem presos ao sistema.

Pouquíssimos perguntam quem criou esse sistema.

Isso lembra empresas antigas.

"Mantemos assim porque sempre foi assim."


2. Especialização excessiva limita pessoas

Cada classe define um destino.

Isso é semelhante ao mercado de trabalho.

"Cobol só programa COBOL."

"Java só programa Java."

A obra mostra que conhecimento supera especialização.


3. O verdadeiro poder é conhecimento

O nível 999 impressiona.

Mas o que realmente muda tudo é compreender a arquitetura.

No mundo IBM Z isso vale ouro.


4. Liberdade exige responsabilidade

Quando você entende como tudo funciona...

também passa a carregar o peso das decisões.


Engenharia de Software Disfarçada

A obra fala sobre:

  • arquitetura

  • dependências

  • sistemas legados

  • evolução

  • manutenção

  • compatibilidade

  • regras de negócio

Mesmo sem usar esses nomes.


Comparação com Mainframe

LV999IBM Z
ClassesRACF
NíveisAutorizações
Mundoz/OS
Rei DemônioProcesso crítico
HeróisBatch Jobs
KagamiSysprog
Sistema do MundoKernel do z/OS
Quebrar as regrasAlterar parâmetros do sistema

O Estúdio Brain's Base

O Brain's Base é conhecido por equilibrar ação, humor e desenvolvimento de personagens. Entre seus trabalhos mais reconhecidos estão:

  • Durarara!!

  • Baccano!

  • Natsume Yuujinchou

  • Spice and Wolf (1ª temporada)

Sua direção costuma privilegiar narrativa consistente e personagens carismáticos, o que combina bem com uma obra que depende tanto de mistério quanto de combates.


Houve censura?

Até o momento, não há registros relevantes de censura oficial envolvendo a light novel, o mangá ou a adaptação em anime. A série não é conhecida por violência extrema, erotização excessiva ou temas que tenham provocado alterações significativas em diferentes mercados.


Impacto Cultural

Embora não tenha alcançado a popularidade de gigantes como Mushoku Tensei, Overlord ou Re:ZERO, LV999 no Murabito conquistou um público fiel por fugir da fórmula do "protagonista apelão". Muitos leitores destacam justamente a mudança de foco: da evolução de atributos para a investigação das regras do mundo e de sua origem.

Sua adaptação para anime tende a ampliar esse alcance, especialmente entre fãs de fantasia com forte componente de mistério.


Classificação

Gêneros

  • Fantasia

  • Isekai (ambientação de fantasia inspirada em RPG)

  • Ação

  • Aventura

  • Mistério

  • Drama

Público recomendado

  • Adolescentes e adultos.

Classificação indicativa estimada

  • 14 anos ou mais, devido a cenas de combate e temas filosóficos.


Veredito Bellacosa Mainframe

História: 9,3/10
Construção de Mundo: 9,6/10
Personagens: 8,9/10
Mistério: 9,7/10
Ação: 8,8/10
Originalidade: 9,5/10
Analogia com IBM Z: 10/10

Conclusão

À primeira vista, LV999 no Murabito parece apenas mais um isekai com um protagonista absurdamente forte. Porém, sua verdadeira força está em mostrar que o maior poder não é possuir os melhores atributos, mas compreender as regras invisíveis que governam todo o sistema.

Sob a ótica do Bellacosa Mainframe, Kagami não é simplesmente um aventureiro de nível 999. Ele se comporta como um Sysprog do IBM Z: alguém que deixa de enxergar apenas as aplicações e passa a entender o kernel, as permissões, a arquitetura e a lógica que sustentam toda a plataforma.

É uma obra que recompensa quem gosta de desmontar sistemas, investigar suas origens e perguntar "por quê?". Para profissionais de tecnologia — especialmente aqueles acostumados com ambientes complexos como o IBM Z — essa perspectiva torna a experiência ainda mais rica do que aparenta à primeira vista.

domingo, 28 de junho de 2026

Backlog: O Dataset Invisível que Pode Salvar ou Destruir um Projeto Mainframe

 

Bellacosa Mainframe e o conceito do backlog na stack mainframe

☕ Um Café no Bellacosa Mainframe

Backlog: O Dataset Invisível que Pode Salvar ou Destruir um Projeto Mainframe

"No mundo IBM Z, um programa COBOL raramente quebra por causa de uma linha de código. Quase sempre ele quebra porque existe um backlog que ninguém quis enxergar."

Existe uma palavra que todo profissional de TI escuta diariamente: Backlog.

Ela aparece em reuniões ágeis, em SCRUM, em Kanban, nos relatórios do gerente, nos dashboards do Jira e até em apresentações do CIO.

Mas curiosamente, poucos programadores COBOL entendem o verdadeiro significado do backlog.

Para um Padawan Mainframe, backlog costuma parecer apenas uma lista enorme de tarefas.

Na realidade, backlog é muito mais parecido com um dataset VSAM KSDS.

Ele armazena tudo que ainda precisa ser processado.

Se ele estiver organizado, o sistema flui.

Se estiver corrompido...

Você acabou de criar o próximo ABEND da equipe.


Imagine um Batch Noturno

Pense em um JOB executando durante a madrugada.

Ele possui:

  • milhares de registros

  • prioridades

  • dependências

  • checkpoints

  • reprocessamentos

Agora substitua os registros por atividades.

Pronto.

Você acabou de entender o backlog.

O backlog é simplesmente o conjunto de trabalho que ainda será executado.

Mas existe uma diferença enorme entre:

muito trabalho

e

backlog saudável.


O Backlog Não É o Problema

O backlog é inevitável.

Todo sistema vivo possui backlog.

Até o z/OS trabalha com filas.

JES2 possui filas.

CICS possui filas.

MQ possui filas.

IMS possui filas.

DB2 possui locks esperando.

Tudo funciona através de filas.

O problema nunca foi possuir backlog.

O problema é possuir um backlog que ninguém entende.


Como Nasce um Backlog

Imagine um sistema bancário.

Hoje o gerente pede:

Criar PIX.

Depois:

alterar TED.

Depois:

corrigir boleto.

Depois:

adequação ao Banco Central.

Depois:

LGPD.

Depois:

Open Finance.

Depois:

PIX Automático.

Depois:

IA.

Depois:

APIs REST.

Cada solicitação entra.

Nem todas saem.

O resultado?

Um backlog crescente.


O Backlog Invisível

O pior backlog é o invisível.

Ele mora em frases como:

"Depois a gente vê."

"Na próxima Sprint."

"Isso fica para outro momento."

"É uma melhoria."

"Não é urgente."

Meses depois...

Existem centenas delas.


Backlog Técnico

Nem todo backlog é funcional.

Existe também:

  • melhoria de performance

  • reorganização de programas

  • limpeza de código

  • documentação

  • atualização de COPYBOOKS

  • reorganização DB2

  • índices

  • compressão VSAM

  • testes

Tudo isso entra no backlog.


Como Identificar um Backlog Doente

Um backlog começa a adoecer quando aparecem sintomas.

Sintoma 1

Todo mundo pergunta:

"O que devemos fazer agora?"

Isso significa ausência de prioridade.


Sintoma 2

Existem tarefas de três anos atrás.

Se ninguém fez em três anos...

Talvez nunca devesse existir.


Sintoma 3

Existem tarefas duplicadas.

Muito comum.

Um analista abre:

"Corrigir cálculo."

Outro abre:

"Ajustar juros."

Outro:

"Problema financeiro."

São o mesmo erro.


Sintoma 4

Ninguém sabe explicar a tarefa.

Descrição:

"Verificar erro."

Qual erro?

Onde?

Quando?

Por quê?


Sintoma 5

Todo item é prioridade máxima.

Quando tudo é urgente...

Nada é urgente.


Como um Programador COBOL Deve Ler um Backlog

Nunca leia apenas o título.

Leia:

  • requisito

  • regra de negócio

  • programas envolvidos

  • COPYBOOKS

  • arquivos

  • tabelas DB2

  • transações CICS

  • JCL

  • impacto

A tarefa começa muito antes do código.


O Erro do Padawan

O Padawan pensa:

"Recebi uma tarefa."

O profissional experiente pensa:

"Recebi um problema de negócio."

Isso muda tudo.


Como Evoluir um Backlog

Existe uma prática chamada:

Backlog Refinement

Ou refinamento.

No Mainframe isso seria parecido com preparar um JOB antes da produção.

Você elimina ambiguidades.


Durante o refinamento fazemos perguntas.

O usuário realmente quer isso?

Existe impacto financeiro?

Existe impacto jurídico?

Existe cálculo?

Existe histórico?

Existe rollback?

Existe auditoria?

Existe logging?

Existe batch?

Existe online?

Existe integração?


Quanto mais perguntas...

Menor o risco.


Um Backlog Não Deve Crescer Para Sempre

Imagine um dataset.

Se ninguém fizer housekeeping...

Ele cresce.

Depois cresce.

Depois cresce.

Depois o volume explode.

Depois aparece:

SPACE ABEND

O backlog também.


Como Priorizar

Uma técnica simples.

Divida em quatro grupos.

Incêndio

Sistema parado.


Financeiro

Pode gerar prejuízo.


Cliente

Afeta usuários.


Melhoria

Pode esperar.


A maioria dos times mistura tudo.


Backlog e COBOL

Um programa COBOL raramente possui apenas uma alteração.

Quando você abre um fonte...

Encontra:

Alteração 2003

Alteração 2006

Alteração 2009

Alteração 2014

Alteração 2018

Alteração 2021

Alteração 2025

Cada comentário representa um backlog encerrado.

O código conta a história da empresa.


O Backlog Bom

Possui:

✔ descrição

✔ prioridade

✔ responsável

✔ impacto

✔ dependência

✔ prazo

✔ critério de aceite

✔ documentação


O Backlog Ruim

Descrição:

"Ajustar."

Boa sorte.


A Grande Diferença Entre Backlog e Dívida Técnica

Muita gente mistura.

Mas são conceitos completamente diferentes.

Backlog

É trabalho conhecido.

Sabemos que precisa ser feito.

Está registrado.

Está visível.

Pode ser priorizado.


Dívida Técnica

É trabalho escondido.

Você decidiu fazer algo mais rápido.

Agora pagará juros.


Imagine um empréstimo.

Você compra uma casa.

Ainda deve dinheiro.

A casa existe.

Mas existe dívida.

No software é igual.


Exemplo.

Você precisava entregar uma alteração.

O correto seria:

  • modularizar

  • criar testes

  • atualizar documentação

Mas o prazo era curto.

Você fez um IF gigantesco.

Funcionou.

Pronto.

Nasceu uma dívida técnica.


Backlog Pode Não Ser Dívida

Exemplo.

Nova funcionalidade PIX.

Ela nunca existiu.

Está no backlog.

Não existe dívida.

É apenas trabalho futuro.


Dívida Técnica Pode Não Estar no Backlog

Muito comum.

Todo mundo sabe que existe.

Ninguém registra.

Ninguém fala.

Até o dia em que explode.


Como Identificar Dívida Técnica

Pergunte:

"Se eu tivesse mais tempo...

faria diferente?"

Se a resposta for SIM...

Existe dívida técnica.


Os Juros da Dívida Técnica

Assim como um banco cobra juros...

O software também.

Cada alteração demora mais.

Cada teste demora mais.

Cada deploy gera medo.

Cada manutenção aumenta.


Dívida Técnica no Mainframe

Exemplos.

Programa COBOL com:

12000 linhas.

Sem PERFORM.

GO TO para todos os lados.

COPYBOOK repetido.

Campos duplicados.

Comentários de 1998.

Variáveis mortas.

Parágrafos nunca chamados.

SQL repetido.

MOVE desnecessário.

PERFORM THROUGH gigantesco.

Tudo isso gera dívida.


Como Corrigir

Nunca tente pagar toda a dívida de uma vez.

Faça igual um financiamento.

Pague parcelas.

Sempre que alterar um programa:

melhore um pouco.

Renomeie variáveis.

Remova código morto.

Atualize comentários.

Crie testes.

Melhore SQL.

Refatore pequenos blocos.


A Regra do Escoteiro

Robert C. Martin criou uma regra famosa.

Deixe o código melhor do que encontrou.

No Mainframe ela é perfeita.


Backlog Funcional

Pedido do negócio.


Backlog Técnico

Pedido da TI.


Backlog Arquitetural

Mudanças estruturais.

Exemplos.

Migrar VSAM.

Migrar CICS.

Atualizar COBOL.

Atualizar compilador.

Migrar DB2.

Atualizar RACF.


O Backlog Nunca Acaba

Isso assusta iniciantes.

Mas é normal.

Software vivo nunca termina.

Ele evolui.


Curiosidade Mainframe nº 1

Nos anos 70 ninguém dizia "Backlog".

Chamavam de:

Pending Requests

Programming Queue

Change Queue

Maintenance Queue

A palavra backlog ficou popular muito depois com métodos ágeis.


Curiosidade nº 2

Em muitos bancos brasileiros ainda existem planilhas Excel paralelas ao Jira.

Sim.

O backlog oficial nem sempre é o verdadeiro.


Curiosidade nº 3

Algumas empresas possuem backlog maior que o código.

Há milhares de demandas abertas.

Mas apenas algumas centenas realmente serão desenvolvidas.


Curiosidade nº 4

O maior inimigo do backlog não é a falta de programadores.

É a falta de decisão.


Curiosidade nº 5

Muitos ABENDs históricos aconteceram porque uma melhoria pequena ficou anos esquecida.

Quando finalmente foi feita...

Ninguém mais entendia o motivo original.


Easter Egg IBM Z

Você já percebeu?

O JES2 organiza trabalhos.

O MQ organiza mensagens.

O CICS organiza transações.

O DB2 organiza dados.

O RACF organiza permissões.

O backlog organiza pessoas.

No fundo...

Todo o ecossistema IBM Z é baseado em gerenciamento de filas.


Easter Egg COBOL

O comando:

NEXT SENTENCE

parece simples.

Mas ele simboliza exatamente muitos backlogs.

Você pula para frente sem realmente resolver o problema.

Funciona.

Até deixar de funcionar.


Easter Egg DB2

Um índice mal planejado gera consultas lentas.

Um backlog mal priorizado gera equipes lentas.

Os dois possuem exatamente o mesmo problema:

falta de organização.


Easter Egg CICS

Em CICS existe o conceito de resposta rápida.

O usuário não pode esperar.

No backlog também.

Quanto mais tempo uma tarefa fica parada...

Maior a chance de perder contexto.


Easter Egg JCL

Imagine um JOB.

STEP010

STEP020

STEP030

STEP040

Existe ordem.

Existe dependência.

Existe fluxo.

Um backlog deveria funcionar exatamente assim.


Easter Egg VSAM

Um KSDS desorganizado sofre mais splits.

Uma equipe desorganizada sofre mais interrupções.


Easter Egg RACF

No RACF, tudo segue o princípio do menor privilégio.

No backlog, vale um princípio parecido:

o menor item possível.

Histórias pequenas fluem melhor do que demandas gigantescas.


O Conselho Final para Todo Padawan COBOL

Quando você entrar em um projeto Mainframe, não olhe apenas para o código-fonte. Observe a saúde do backlog. Um programa de 30 anos pode ser surpreendentemente fácil de manter se houver um backlog bem organizado, prioridades claras e comunicação constante entre negócio e tecnologia. Por outro lado, um sistema moderno pode se tornar um pesadelo quando acumula tarefas mal descritas, prioridades conflitantes e dívida técnica ignorada.

Aprenda a fazer perguntas antes de programar. Entenda a regra de negócio antes de abrir o editor COBOL. Documente suas descobertas, refine as histórias, questione requisitos ambíguos e aproveite cada manutenção para deixar o código um pouco melhor do que estava. Essa disciplina, repetida diariamente, transforma um Padawan em um verdadeiro Mestre Mainframe.

No universo IBM Z, backlog é o mapa da jornada, enquanto a dívida técnica é o peso que você carrega na mochila. O mapa pode crescer à medida que novos caminhos surgem, mas o peso só aumenta quando atalhos mal planejados são tomados. Os melhores profissionais aprendem a equilibrar os dois: mantêm um backlog claro, vivo e priorizado, enquanto pagam pequenas parcelas da dívida técnica a cada entrega.

No fim das contas, a maior lição é simples: software não é apenas código; é uma fila contínua de decisões. Assim como o JES2 coordena jobs, o CICS gerencia transações e o DB2 organiza dados, um bom desenvolvedor organiza seu trabalho, seu conhecimento e sua evolução. É essa capacidade de transformar caos em ordem que diferencia um programador que apenas entrega tarefas de um engenheiro que constrói sistemas capazes de sobreviver por décadas — exatamente como os grandes ambientes IBM Z que continuam sustentando bancos, seguradoras, governos e empresas em todo o mundo.


sábado, 27 de junho de 2026

O Grande Equívoco: A Modernização Não é Sair do Mainframe

 

Bellacosa Mainframe e a modernizacao na Stack mainframe



☕ Um Café no Bellacosa Mainframe

O Grande Equívoco: A Modernização Não é Sair do Mainframe

A primeira provocação é justamente esta.

A maior parte das pessoas lê:

Modernizar COBOL → Java → Kubernetes → Cloud

Mas essa não é necessariamente a melhor resposta.

Modernizar é diferente de migrar.

Existem quatro estratégias clássicas.

1. Encapsular

Não mexe no COBOL.

Expõe APIs.

COBOL

CICS

z/OS Connect

REST

Mobile

Exemplo:

ContaCorrente.cbl

vira

GET /saldo

em minutos.


2. Refatorar

Melhora código COBOL.

COBOL 74

Enterprise COBOL 6.5

AMODE 64

JSON PARSE

XML

UTF-8

LE

Continua rodando no Z.


3. Reescrever

Maior risco.

COBOL

Java

COBOL

Go

COBOL

C#

Mas...

80% dos projetos falham.

Motivos:

regras escondidas

efeitos colaterais

batchs esquecidos

interfaces desconhecidas

JCL perdido

scheduller

CA7

Control-M

MQ

etc.


4. Replatform

Executar COBOL fora do Z.

Micro Focus

Rocket

Heirloom

Raincode

AWS Blu Age


Etapa 1 — Mainframe

A imagem mostra.

IBM Z

COBOL

DB2

CICS

JCL

Correto.

Mas faltam dezenas de peças.

IMS

MQ

VSAM

RACF

SMF

RMF

WLM

JES2

DFSMS

GDG

TSO

ISPF

SMP/E

NetView

SA zOS

e muitas outras.

Um banco médio pode ter:

50 milhões de linhas COBOL

300 mil JCL

12 mil CICS

200 TB DB2

40 anos de histórico


Bellacosa Mainframe e o mainframe no Brasil


Etapa 2 — Discovery

Talvez seja a etapa mais importante.

Porque ninguém conhece realmente o sistema.

José aposentou em 2009.

Maria saiu em 2017.

Carlos faleceu.

O conhecimento sumiu.


Descobrir significa:

inventário

mapear

catalogar

entender


Exemplo

Programa

PAGA100

CALL PAGA101

CALL PAGA102

READ VSAM001

EXEC SQL

UPDATE CLIENTE

PUT MQ

SUBMIT JCL

Só isso já gera um grafo enorme.


Ferramentas

IBM ADDI

IBM Wazi Analyze

Sonar

Understand

CAST

Manta


Etapa 3 — Regras de Negócio

Este talvez seja o maior patrimônio.

Exemplo.

IF IDADE > 65

AND TEMPO-CONTRIB > 15

AND DATA-CORTE < 20211231

MOVE 'S' TO BENEFICIO

Isso não está em documento.

Está no código.

Há empresas cujo negócio inteiro está aqui.


A Regra Oculta

Um banco descobriu:

IF CODIGO = 87

MOVE 0 TO JUROS

Perguntaram.

Por quê?

Resposta:

"Ninguém sabe."

Era uma lei de 1986.

Implementada por um programador.

Nunca documentada.


Etapa 4 — Dependency Graph

Excelente ideia.

Pouca gente faz.

Visualmente.

Programa A

Programa B

VSAM

MQ

DB2

Batch

Scheduler

API


Ferramentas modernas conseguem mostrar isso.

Parece Neo4J.

Um mapa da galáxia.


Etapa 5 — IA

A IA é promissora.

Mas ainda está longe da autonomia.

Ela consegue:

explicar COBOL

gerar documentação

resumir JCL

identificar copybooks

sugerir Java

gerar testes


Ela não consegue sozinha.

Decidir.

Esta regra bancária pode mudar?

Não sabe.


Exemplo.

COBOL

COMPUTE TAXA =
SALDO * 0.01875

IA pergunta:

Por que 1,875%?

Arquiteto responde:

Resolução BACEN 2147.

Pronto.

Conhecimento capturado.


Etapa 6 — Documentação

Hoje muitas empresas possuem.

Zero documentação.

Somente:

SYS1.PROCLIB

JCL

COBOL

Copybooks


IA pode gerar.

Markdown

Confluence

Draw.io

OpenAPI

Mermaid


Etapa 7 — Reengenharia

Imagem cita.

Java

.NET

Go

Node

Boa visão.

Mas há diferenças.

Java

Excelente.

Ecossistema corporativo.

Spring.


Go

Ótimo.

Microserviços.

Baixo consumo.


Node

Excelente APIs.

Menor adequação para batchs enormes.


.NET

Muito usado em seguradoras.


E Rust?

Começa aparecer.

Muito seguro.

Mas pouco adotado.


Contêineres

Aqui existe um mito.

Containerizar não significa melhorar.

Empacotar um sistema ruim.

Produz.

Um container ruim.


Docker resolve.

Empacotamento.

Não arquitetura.


Kubernetes

Muito poderoso.

Mas caro operacionalmente.

Exige.

SRE

Observabilidade

GitOps

Segurança


Para muitas empresas.

OpenShift.

É mais comum.


Cloud

A parte mais polêmica.

A imagem sugere.

Nuvem.

Como destino natural.

Nem sempre.


Muitos estão voltando.

Cloud Repatriation.

37Signals.

Dropbox.

Basecamp.

Bancos.


Motivos.

Custos.

Latência.

Compliance.

Egress.

Licenciamento.


Observabilidade

Excelente ponto.

Antigamente.

SMF.

RMF.

Omegamon.

Hoje.

Prometheus

Grafana

OpenTelemetry

Elastic


Imagine.

SMF 110

OpenTelemetry

Grafana

Isso já acontece.


O Papel da IA

A figura acerta em cheio aqui.

A IA não substitui.

O arquiteto.

O analista.

O especialista de negócio.

Ela atua como.

Copiloto.


Ela lê.

20 milhões linhas COBOL.

Em minutos.


Mas ela não sabe.

Que:

Cliente Ouro

é diferente de

Cliente VIP

Porque isso é semântico.

É negócio.


Minha visão sobre a frase central


A maior oportunidade tecnológica da próxima década não será abandonar o Mainframe, mas integrá-lo ao ecossistema moderno de APIs, IA, DevOps, observabilidade e computação híbrida.

O IBM Z não está desaparecendo. Está se tornando um nó de alto valor dentro de arquiteturas distribuídas, orientadas a eventos e assistidas por IA.

Acredito que estamos diante de uma das maiores ondas de transformação desde a popularização da internet comercial e da computação em nuvem, mas provavelmente ela não será uma história de "COBOL versus Java". Será uma história de preservar décadas de capital intelectual enquanto se adicionam capacidades modernas, reduzindo risco, aumentando a velocidade de entrega e mantendo a confiabilidade que fez o Mainframe sobreviver por mais de meio século. Afinal, substituir tecnologia é relativamente simples; substituir quarenta anos de conhecimento de negócio embutido em milhões de linhas de código é muito mais difícil.


Bellacosa Mainframe e os ciclos historicos na tecnologia mainframe


A história do software pode ser entendida como uma sucessão de grandes ondas tecnológicas. Nos anos 1960 surgiu a Crise do Software, quando projetos se tornavam caros, atrasados e difíceis de manter, motivando o nascimento da Engenharia de Software. A Crise do Petróleo dos anos 1970 aumentou a pressão por eficiência, impulsionando a automação bancária, industrial e governamental.

Nos anos 1980 ocorreu o movimento de downsizing, migrando parte do processamento de grandes sistemas centralizados para servidores menores e estações de trabalho. Na década de 1990 surgiu o rightsizing, buscando equilibrar custos, desempenho e confiabilidade, reconhecendo que nem tudo deveria sair do mainframe.

A popularização da Internet revolucionou os negócios, exigindo aplicações conectadas, comércio eletrônico e integração global. No final dos anos 1990, o Y2K mobilizou milhares de profissionais para corrigir sistemas legados, preservando um enorme patrimônio tecnológico e renovando plataformas críticas.

A partir dos anos 2000, a Cloud Computing trouxe elasticidade, pagamento sob demanda e novas arquiteturas distribuídas, embora também revelasse desafios de custo, governança e dependência de fornecedores. Atualmente, a onda da Inteligência Artificial acelera desenvolvimento, documentação, testes e modernização de sistemas legados. Diferentemente das revoluções anteriores, a IA não elimina o conhecimento humano: amplia a capacidade dos especialistas de compreender, preservar e evoluir décadas de regras de negócio.

sexta-feira, 26 de junho de 2026

Como um Padawan COBOL Pode Entender Agentes, MLOps e IA Generativa Sem Abandonar o IBM Z

 

Bellacosa Mainframe apresenta como entender ia generativas e agentes

☕ O Holocron do Ecossistema de IA Moderna

Como um Padawan COBOL Pode Entender Agentes, MLOps e IA Generativa Sem Abandonar o IBM Z

"O Mainframe nunca esteve atrasado. Apenas esperou pacientemente que o restante da indústria redescobrisse conceitos que ele domina há cinquenta anos."

Bellacosa Mainframe

Introdução – O dia em que percebi que um GPT era apenas um programa CICS muito falante

Se você é um Padawan COBOL, provavelmente abriu o LinkedIn nos últimos meses e viu dezenas de especialistas dizendo coisas como:

"Você precisa aprender IA."

"Agentes vão substituir desenvolvedores."

"Prompt Engineering é a nova programação."

"Os modelos estão ficando commodities."

E talvez tenha pensado:

"Mas eu passei anos aprendendo COBOL, JCL, VSAM, CICS, Db2, RACF, JES2 e agora preciso jogar tudo fora para estudar agentes?"

A resposta curta é:

Não.

Na verdade, existe uma boa notícia.

Talvez você seja muito mais preparado para a era Agentic AI do que imagina.


O Grande Equívoco Sobre Inteligência Artificial

Muitas pessoas ainda acreditam que IA é isto:

Usuário

ChatGPT

Resposta

Fim

Essa visão é tão simplificada quanto dizer que um banco consiste apenas em um programa COBOL.

Nós sabemos que não é assim.

Num banco real existem:

JES2

Control-M

RACF

Db2

MQ

CICS

VSAM

SMF

RMF

Schedulers

Catálogos

Auditoria

Backup

Monitoramento

A IA corporativa está seguindo exatamente o mesmo caminho.

Um LLM sozinho é inteligente.

Mas também é limitado.

Ele:

Não executa transações;

Não conhece dados internos;

Não lembra clientes;

Não acessa CICS;

Não consulta Db2;

Não abre chamados;

Não aprova empréstimos;

Não faz deploy.

Ele é apenas um cérebro.

O restante precisa ser construído.


O Ecossistema Moderno de IA

A indústria começou a perceber que IA não é um produto.

IA é um ecossistema.

Uma pilha arquitetural.

Podemos imaginar algo semelhante:

Agentic AI

Workflow

MLOps

Intelligence

Data Foundation

Curiosamente, um profissional IBM Z olha para isso e pensa:

"Eu já vi algo parecido antes."

Porque viu.

Durante décadas.


Primeira Camada – Data Foundation

Esta deveria ser a base absoluta.

Sem dados não existe IA.

E dados ruins produzem IA ruim.

Garbage In.

Garbage Out.

Nada mudou.

Apenas ficou mais caro.

O que existe aqui?

Db2

IMS

VSAM

Oracle

Postgres

Kafka

Data Lakes

Data Catalogs

Feature Stores

Embeddings

Vector Databases


Um exemplo bancário

Imagine um banco.

Possui:

40 milhões clientes

15 anos histórico

Cartões

PIX

Seguros

CRM

GPT não sabe nada disso.

Ele conhece apenas internet.

Precisamos ensinar.

Entra o conceito de:

RAG

Retrieval Augmented Generation

Funciona assim:

Pergunta

Embeddings

Busca vetorial

Documentos internos

LLM

Resposta

Exemplo:

Cliente pergunta:

"Quanto falta para quitar meu financiamento?"

Agente consulta.

Db2.

Documentos.

Extratos.

Contratos.

Depois responde.


O paralelo Mainframe

Padawan COBOL rapidamente percebe:

RAG é quase um READ em uma memória extremamente sofisticada.


Segunda Camada – Core Intelligence

Aqui moram os modelos.

GPT

Claude

Gemini

Mistral

Llama

DeepSeek


Também existem:

Speech

Computer Vision

OCR

Recomendadores

Machine Learning

Reinforcement Learning


Generative AI

É a interface moderna.

Antigamente:

Tela verde.

PF3.

COMMAREA.

Hoje:

Chat.

Áudio.

Imagem.

Agentes.

Copilots.


Reasoning Models

Uma novidade importante.

Os modelos não apenas completam frases.

Eles planejam.

Dividem tarefas.

Analisam.

Validam.

Exemplo.

Padawan pergunta:

"Como migrar VSAM para PostgreSQL?"

Modelo:

Analisa.

Calcula.

Sugere.

Documenta.

Estima esforço.


Terceira Camada – Workflow

Aqui a mágica começa.

É a camada esquecida.

Mas talvez seja a mais importante.


Ferramentas:

n8n

LangGraph

CrewAI

AutoGen

Semantic Kernel

Temporal


Imagine um processo.

Cliente solicita empréstimo.

Agente Planejador

Agente Crédito

Agente Fraude

Agente Compliance

Agente Aprovação

Supervisor

Resposta


Padawan COBOL imediatamente percebe:

Isso parece um scheduler.

E parece mesmo.

JES2.

Control-M.

CA7.

IWS.

Jobtrac.

São praticamente ancestrais dos workflows cognitivos.


Quarta Camada – MLOps

Se existe uma disciplina que lembra Sysprog Mainframe é MLOps.


Deploy.

Rollback.

Monitoramento.

Versionamento.

Observabilidade.


Ferramentas.

MLFlow.

Kubeflow.

Ray.

KServe.

Argo.


Exemplo.

Modelo fraude.

Janeiro.

97% acurácia.

Março.

88%.

Abril.

79%.

Por quê?

Mudou comportamento clientes.

PIX.

Golpes.

Novas técnicas.

MLOps detecta.

Treina novamente.


Padawan percebe:

É quase RUNSTATS.

REORG.

REBIND.

Statistics.

Só que para modelos.


Quinta Camada – Agentic AI

Aqui está a revolução.

E talvez a maior oportunidade profissional da década.


Um chatbot responde.

Um agente trabalha.


Agente possui:

Objetivos.

Ferramentas.

Memória.

Planejamento.

Autonomia.

Capacidade execução.


Exemplo.

Agente RH.

Recebe CV.

Classifica.

Agenda entrevista.

Consulta Teams.

Envia email.

Produz resumo.

Armazena histórico.

Tudo sozinho.


Multi-Agent Systems

Especialização.

Assim como empresas.


Agente Jurídico.

Agente Segurança.

Agente Mainframe.

Agente Cobol.

Agente Arquitetura.

Agente FinOps.


Supervisor coordena.

Como um gerente.


O Que a Imagem Não Mostra

Existem duas camadas ausentes.

Governança

Fundamental.

LGPD.

GDPR.

Auditoria.

RBAC.

IAM.

Policies.

Approval Gates.


Quem aprovou?

Quem executou?

Quem auditou?

Quem pagou?

Quem autorizou?


Infraestrutura

GPU.

TPU.

CPU.

OpenShift.

Kubernetes.

IBM z17.

LinuxONE.

Cloud.


O IBM Z Sempre Esteve Preparado

Talvez a maior surpresa seja esta.

IBM Z nunca esteve distante da IA.

Ele apenas utilizava nomes diferentes.

IA ModernaIBM Z
WorkflowJES2
ObservabilidadeRMF
LogsSMF
SegurançaRACF
APIsz/OS Connect
EventosMQ
SchedulerIWS
GovernançaSAF
CI/CDDBB
MemóriaDb2
AgentesServiços especializados
Inferênciawatsonx

O Conselho Final para um Padawan COBOL

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

Estude em etapas.

Etapa 1

Entenda LLMs.

GPT.

Claude.

Embeddings.

RAG.


Etapa 2

Aprenda LangGraph.

CrewAI.

n8n.


Etapa 3

Entenda MLOps.

MLFlow.

Observabilidade.


Etapa 4

Integre Mainframe.

MQ.

z/OS Connect.

Db2.


Etapa 5

Construa agentes.

Agente COBOL.

Agente JCL.

Agente Db2.

Agente CICS.


O Holocron Final

Durante anos ouvimos que o Mainframe era uma tecnologia do passado.

Em 2026 começamos a perceber algo curioso.

A indústria inteira está reconstruindo conceitos que os profissionais IBM Z já conheciam muito bem:

  • Orquestração;

  • Governança;

  • Observabilidade;

  • Segurança;

  • Processamento confiável;

  • Execução transacional;

  • Gestão de workloads;

  • Auditoria completa.

A IA moderna não está eliminando o conhecimento dos veteranos do IBM Z.

Ela está valorizando exatamente aquilo que sempre diferenciou os melhores arquitetos de mainframe: a capacidade de pensar em ecossistemas complexos, sistemas resilientes, processos críticos e plataformas que funcionam vinte e quatro horas por dia sem margem para erros.

Talvez o futuro não pertença apenas aos construtores do maior modelo de linguagem.

Talvez pertença aos velhos Jedi do IBM Z que finalmente descobriram que seus holocrons sempre falaram sobre agentes, apenas utilizando nomes diferentes.