Translate

sexta-feira, 3 de julho de 2026

Programando COBOL no GitHub com VS Code Sem Mainframe. Sem Compilar. Apenas Aprendendo como um Desenvolvedor Moderno.

 


Bellacosa Mainframe usando o vs code para programar cobol numa ide moderna

☕ Um Café no Bellacosa Mainframe

Programando COBOL no GitHub com VS Code

Sem Mainframe. Sem Compilar. Apenas Aprendendo como um Desenvolvedor Moderno.

"Todo Jedi começa treinando com um sabre de luz desligado. Todo desenvolvedor Mainframe também pode começar sem um z/OS."


Antes de começarmos...

Existe um mito enorme no mundo Mainframe.

"Para aprender COBOL preciso de um IBM Z."

Não.

Outro mito:

"Para editar programas COBOL preciso de um emulador."

Também não.

Outro:

"Preciso instalar um compilador."

Ainda não.

Hoje vamos aprender exatamente como milhares de desenvolvedores modernos trabalham quando estão estudando, revisando código ou preparando alterações para um projeto.

Você vai usar apenas:

  • GitHub

  • Visual Studio Code

  • IBM Z Open Editor

  • Git

Nada mais.

Nenhum z/OS.

Nenhum TSO.

Nenhum ISPF.

Nenhuma licença IBM.

E, ainda assim, estará utilizando praticamente o mesmo editor utilizado por desenvolvedores COBOL profissionais.

Pegue seu café.

Vamos montar nosso laboratório.


Bellacosa Mainframe passo a passo na instalacao

A grande mudança de mentalidade

Imagine um mecânico.

Ele não liga um caminhão para trocar o volante.

Primeiro ele trabalha na peça.

Depois instala.

No Mainframe acontece exatamente igual.

Você pode editar, estudar, revisar e versionar milhares de programas COBOL sem sequer possuir acesso ao IBM Z.

O Mainframe só entra quando chega a hora de:

  • compilar

  • executar

  • testar online

  • acessar DB2

  • acessar CICS

  • executar JCL

Até lá...

Tudo pode ser feito localmente.


Nossa arquitetura

Imagine esta jornada.

GitHub
     │
git clone
     │
VS Code
     │
IBM Z Open Editor
     │
Editar COBOL
     │
Git Commit
     │
Git Push
     │
GitHub

Perceba.

O Mainframe nem apareceu.


O que vamos instalar

Nosso kit Bellacosa Mainframe será composto por:

✅ Visual Studio Code

✅ Git

✅ IBM Z Open Editor

✅ GitHub Pull Requests

✅ Error Lens

✅ Material Icon Theme

✅ Markdown All in One

✅ Code Spell Checker

✅ Todo Tree

✅ Peacock

Opcionalmente:

  • GitLens

  • Better Comments

  • YAML

  • XML

  • Rainbow CSV

  • Hex Editor

  • REST Client

Você perceberá que quase tudo é gratuito.


Passo 1 — Instale o Git

Sem Git...

não existe GitHub.

Baixe:

https://git-scm.com

Durante a instalação aceite praticamente tudo.

Depois abra um terminal.

Digite:

git --version

Se aparecer algo parecido com:

git version 2.51

Parabéns.

Seu sabre de luz foi montado.


Passo 2 — Instale o VS Code

Baixe em

https://code.visualstudio.com

Instale normalmente.

Abra.

Você verá uma tela praticamente vazia.

É aqui que a mágica acontece.


Passo 3 — Faça login no GitHub

No canto inferior esquerdo existe o ícone da conta.

Clique.

Escolha:

Sign In with GitHub

O navegador abrirá.

Autorize.

Volte ao VS Code.

Pronto.

Agora seu VS Code conversa diretamente com o GitHub.


Passo 4 — Instale o IBM Z Open Editor

Abra Extensions.

Pesquise:

IBM Z Open Editor

Instale.

Este plugin entende COBOL.

Ele conhece:

  • DIVISION

  • SECTION

  • PARAGRAPH

  • COPY

  • EXEC SQL

  • EXEC CICS

  • comentários

  • copybooks

É praticamente um ISPF moderno.


O que ele faz?

Quando você abre:

IDENTIFICATION DIVISION.
PROGRAM-ID. HELLO.

Ele já entende que aquilo é COBOL.

Você ganha:

✔ Colorização

✔ Outline

✔ Auto Complete

✔ Navegação

✔ Hover

✔ Referências

✔ Folding

✔ Sintaxe

Tudo gratuitamente.


Passo 5 — Instale GitHub Pull Requests

Esse plugin é fantástico.

Ele permite:

  • abrir Pull Requests

  • revisar código

  • comentar linhas

  • aprovar alterações

Sem sair do VS Code.


Passo 6 — Material Icon Theme

Pequeno detalhe.

Grande diferença.

Agora:

📄 COBOL

📄 COPYBOOK

📄 JCL

📄 REXX

ganham ícones.

Seu projeto fica muito mais agradável.


Passo 7 — Error Lens

Esse plugin faz algo simples.

Mostra erros diretamente na linha.

Sem precisar olhar outro painel.

Economiza muito tempo.


Passo 8 — Better Comments

Imagine:

*> TODO

vira verde.

*> WARNING

fica amarelo.

*> BUG

fica vermelho.

Seu código passa a conversar com você.


Passo 9 — Todo Tree

Agora imagine possuir 3.000 programas.

Você procura:

TODO

Ele encontra todos.

Fantástico para projetos enormes.


Passo 10 — Clone seu GitHub

No terminal:

git clone https://github.com/seuusuario/IBMLearnCOBOL.git

ou simplesmente:

No VS Code:

Clone Repository

Cole a URL.

Pronto.


Estrutura típica

COBOL/
    HELLO.CBL
    CLIENTE.CBL
COPY/
    CLIENTE.CPY
JCL/
    COMPILA.JCL
REXX/
README.md

Tudo organizado.


Abrindo o projeto

Arquivo

Open Folder

Escolha:

IBMLearnCOBOL

Agora tudo aparece na lateral.

Exatamente como Java.

Exatamente como Python.


Editando um programa

Abra:

HELLO.CBL

Modifique:

DISPLAY "HELLO WORLD".

para

DISPLAY "HELLO BELLACOSA MAINFRAME".

Salve.

Só isso.


Observe o Git

Na lateral existe:

Source Control

Aparecerá:

M HELLO.CBL

M significa:

Modified.


Veja a diferença

Clique no arquivo.

O VS Code mostra:

esquerda

arquivo antigo

direita

arquivo novo.

Em verde:

linhas adicionadas.

Em vermelho:

linhas removidas.

É maravilhoso.


Criando um Commit

Na caixa superior escreva:

Alterado texto do HELLO WORLD

Clique:

Commit

Pronto.


Fazendo Push

Agora clique:

Sync

ou

Push

O Git envia tudo para o GitHub.

Seu código agora está online.


Histórico

Clique:

Timeline

Você verá:

  • quem alterou

  • quando

  • qual commit

  • diferença

É uma máquina do tempo.


GitLens

Se instalar GitLens...

fica ainda melhor.

Você passa o mouse.

Ele mostra:

Vagner Bellacosa

14 dias atrás

Commit:

Correção cálculo IRRF

Parece mágica.


Trabalhando com Branches

Nunca altere diretamente a Main.

Crie:

feature/curso-cobol

bugfix/cliente

feature/json

feature/db2

Isso é padrão de mercado.


Commits bons

Ruim:

teste

Ruim:

aaaa

Ruim:

mudança

Bom:

Inclui validação do CPF

Corrige cálculo de juros

Refatora rotina de leitura VSAM

Atualiza documentação

Organização Bellacosa

COBOL
COPY
JCL
BMS
DBRM
SQL
DOCS
LABS
QUIZZES

Tudo separado.

Tudo fácil.


Markdown

Documente tudo.

README.

Arquitetura.

Fluxo.

Exemplos.

O VS Code possui preview fantástico.


Dica de Ouro

Ative:

Auto Save

Você nunca esquecerá de salvar.


Outra dica

Use:

Minimap.

Você enxerga programas COBOL gigantes.


Outra

Breadcrumbs.

Você sabe exatamente:

DIVISION

SECTION

PARAGRAPH

onde está.


Outra

Outline.

Clique:

CALCULA-TOTAL

Vai direto para o parágrafo.

Adeus Page Down.


Outra

CTRL+P

Digite:

cliente

Abre CLIENTE.CBL imediatamente.


Outra

CTRL+SHIFT+O

Lista todos os parágrafos.

Fantástico.


Outra

CTRL+SHIFT+F

Procura em TODOS os programas.

Imagine localizar:

EXEC SQL

em 12.000 fontes.

Leva segundos.


Easter Egg nº 1

Troque o tema.

Experimente:

IBM Carbon Theme

ou

One Dark Pro.

Seu COBOL fica lindíssimo.


Easter Egg nº 2

Instale Peacock.

Cada Workspace ganha uma cor.

Nunca mais confundirá produção e laboratório.


Easter Egg nº 3

Digite:

>Preferences: Open Keyboard Shortcuts

Personalize tudo.


Easter Egg nº 4

Use emojis nos commits.

✨ Novo programa

🐞 Corrige bug

📚 Atualiza documentação

♻ Refatoração

🚀 Nova funcionalidade

Easter Egg nº 5

Use Copilot apenas para sugerir código.

Nunca aceite sem entender.

O bom desenvolvedor continua pensando.


Quando chegar o Mainframe...

Nada muda.

Você apenas instala:

IBM Zowe Explorer.

Então passa a acessar:

PDS

PDSE

USS

JES

Jobs

Datasets

O editor continua exatamente o mesmo.

É como aprender a dirigir em um simulador e depois entrar no carro real: os comandos principais permanecem familiares.


O verdadeiro objetivo

Aprender COBOL nunca foi decorar comandos do ISPF.

O objetivo é entender:

  • lógica de negócio;

  • arquitetura de sistemas;

  • qualidade de código;

  • versionamento;

  • colaboração;

  • documentação.

Essas habilidades acompanham você em qualquer plataforma.


Conclusão

Durante décadas, muitos imaginaram que o desenvolvimento Mainframe dependia de telas verdes, terminais 3270 e comandos memorizados. Hoje, essa realidade mudou. O Visual Studio Code, aliado ao IBM Z Open Editor e ao GitHub, oferece uma experiência moderna, produtiva e acessível para estudar, revisar e evoluir programas COBOL sem a necessidade imediata de um ambiente z/OS.

Ao dominar Git, commits bem escritos, branches, documentação em Markdown e a organização de projetos, você desenvolve competências valorizadas em qualquer equipe de engenharia de software. Quando chegar o momento de conectar-se a um IBM Z com o Zowe Explorer, a curva de aprendizado será muito menor, pois o editor, os atalhos e o fluxo de trabalho continuarão praticamente os mesmos.

Você não está abandonando o Mainframe tradicional. Está adicionando ferramentas modernas à sua caixa de ferramentas. Como costumo dizer no Bellacosa Mainframe: o terminal pode mudar, mas a excelência em engenharia de software continua sendo a mesma.

quinta-feira, 2 de julho de 2026

As 16 Recomendações da IBM que Todo Programador COBOL Padawan Deveria Conhecer

 

Bellacosa Mainframe e 16 recomendacoes Jedi para seu programa COBOL século XXI

☕ Um Café no Bellacosa Mainframe

As 16 Recomendações da IBM que Todo Programador COBOL Padawan Deveria Conhecer

Da Era dos Cartões Perfurados ao IBM Z Moderno: Como Escrever COBOL Preparado para os Próximos 30 Anos

"A maior diferença entre um Programador COBOL Júnior e um Arquiteto Mainframe não está em quantos comandos ele conhece, mas em entender por que a linguagem evoluiu."

Existe uma frase muito comum entre desenvolvedores iniciantes:

"Sempre fizemos assim."

Ela parece inofensiva.

Mas, no mundo Mainframe, ela pode esconder décadas de dívida técnica.

Muitos sistemas COBOL que ainda executam hoje foram escritos quando:

  • o IBM System/360 ainda era novidade;

  • cartões perfurados eram utilizados;

  • memória era medida em kilobytes;

  • não existia Internet;

  • não existia Java;

  • não existia JSON;

  • ninguém imaginava APIs REST.

Mesmo assim, esses sistemas continuam processando bilhões de dólares diariamente.

Então surge uma pergunta inevitável:

Se eles funcionam tão bem, por que a IBM continua evoluindo o COBOL?

A resposta é simples.

Porque o mundo mudou.

O hardware mudou.

Os processadores IBM Z mudaram.

O Language Environment (LE) mudou.

As aplicações passaram a conversar com Java, Python, Node.js, microsserviços, OpenShift, APIs REST e serviços em nuvem.

O COBOL também precisou evoluir.

E é exatamente isso que veremos neste café.


A filosofia da IBM

Existe um detalhe curioso.

A IBM raramente muda uma linguagem apenas porque existe uma novidade tecnológica.

Ela muda quando existe ganho real.

Os princípios normalmente são:

  • mais segurança

  • mais desempenho

  • menos CPU

  • menos manutenção

  • melhor integração

  • melhor diagnóstico

  • maior reutilização

Sempre que surgir uma recomendação da IBM, pergunte:

"Qual problema essa mudança resolveu?"

Essa pergunta transforma um Padawan em um profissional que entende arquitetura.


1. STOP RUN → GOBACK

Provavelmente a recomendação mais conhecida.

Durante décadas escrevíamos:

STOP RUN.

Hoje, novos projetos costumam utilizar:

GOBACK.

Por quê?

Imagine um restaurante.

Você pede um café.

O garçom leva até sua mesa.

Quando termina de beber, o correto é devolver a xícara ao garçom.

Não faz sentido fechar o restaurante inteiro.

Foi exatamente isso que aconteceu com o COBOL.

Nos anos 60 o programa era praticamente o dono da execução.

Hoje ele normalmente é apenas um componente.

Pode ser chamado por:

  • outro COBOL

  • CICS

  • IMS

  • Java

  • API REST

  • MQ

  • z/OS Connect

Se um módulo chamado executar STOP RUN...

Toda a Run Unit termina.

Com GOBACK...

O controle simplesmente retorna ao chamador.

Dica Bellacosa

Sempre imagine:

"Meu programa está prestando um serviço."

Quem chamou deve decidir quando terminar a aplicação.


2. NUMCHECK

Todo programador já viu um S0C7.

Normalmente ele aparece na madrugada.

Em produção.

Na sexta-feira.

O motivo quase sempre é simples.

Dados inválidos.

Exemplo:

MOVE "ABC" TO WS-VALOR.
ADD 10 TO WS-VALOR.

Visualmente parece correto.

Na prática...

Explode.

NUMCHECK faz o compilador inserir verificações para identificar esse tipo de problema antes que ele vire um incidente.

Curiosidade

Muitos S0C7 não nascem onde ocorrem.

O dado inválido pode ter sido gravado horas antes por outro programa.


3. SSRANGE

Imagine um armário com 100 gavetas.

Você tenta abrir a gaveta 101.

Ela simplesmente não existe.

Sem SSRANGE...

Seu programa pode acessar memória indevida.

Com SSRANGE...

O erro é detectado imediatamente.

Exemplo:

01 TABELA.
   05 ITEM OCCURS 100 TIMES.

MOVE "X" TO ITEM(101).

Esse erro pode permanecer escondido durante anos.

Até que um dia...

Produção.


Curiosidade

Grande parte dos erros difíceis de reproduzir está relacionada ao acesso indevido de memória.

SSRANGE ajuda justamente nisso.


4. TEST

Quantos DISPLAY você já encontrou em produção?

DISPLAY "CHEGUEI AQUI".

DISPLAY SQLCODE.

DISPLAY WS-CLIENTE.

Eles ajudam?

Sim.

Mas apenas temporariamente.

Hoje existem ferramentas de Debug muito mais completas.

Com TEST, o programa pode ser analisado sem transformar o código em uma árvore de DISPLAY.


5. Unicode

Durante décadas tudo era EBCDIC.

Hoje recebemos:

  • JSON

  • XML

  • APIs

  • Web

  • Smartphones

  • Emojis

  • Idiomas internacionais

O COBOL moderno suporta Unicode.

Isso significa muito mais integração.

Imagine um banco atendendo clientes no Japão, Brasil e Alemanha.

Tudo utilizando a mesma aplicação.


Curiosidade

Muitos desenvolvedores COBOL nunca perceberam que o Enterprise COBOL moderno possui excelente suporte a Unicode.


6. JSON PARSE

Há alguns anos montar JSON significava algo parecido com isto:

STRING "{"

...

"}"

Muito código.

Muito risco.

Muito difícil de manter.

Hoje basta utilizar:

JSON GENERATE.

Ou

JSON PARSE.

O compilador faz praticamente todo o trabalho.


Isso muda completamente a modernização

Imagine integrar COBOL com:

  • React

  • Angular

  • Flutter

  • Java

  • Python

JSON virou a linguagem universal.


7. XML PARSE

O mesmo aconteceu com XML.

Antes era comum utilizar:

UNSTRING.

INSPECT.

STRING.

Hoje o compilador entende XML nativamente.

Menos código.

Menos bugs.

Mais produtividade.


8. RENT

Talvez uma das opções menos conhecidas pelos iniciantes.

RENT significa:

Reentrant.

Ou seja...

O programa pode ser executado simultaneamente por diversos usuários.

Imagine um banco.

Cinco mil clientes consultando saldo.

O mesmo programa atende todos.

Isso só funciona porque ele foi escrito corretamente.


Dica

Sempre evite gravar informações temporárias em áreas compartilhadas.


9. DYNAM

No passado quase tudo era ligado durante o Link-Edit.

Hoje queremos mais flexibilidade.

CALL dinâmico permite substituir módulos sem reconstruir toda a aplicação.

É um grande aliado em ambientes modernos.


10. EVALUATE

Existe um momento na vida de todo Padawan em que ele escreve isto:

IF
ELSE
IF
ELSE
IF
ELSE

Depois de alguns meses...

Nem ele entende mais.

EVALUATE resolve exatamente isso.

Exemplo:

EVALUATE WS-TIPO

WHEN 1

WHEN 2

WHEN 3

WHEN OTHER

END-EVALUATE

Muito mais limpo.


11. END-IF

Antigamente muitos programas dependiam de ponto final e NEXT SENTENCE.

Isso gerava ambiguidades.

Hoje escrevemos:

IF ...

END-IF

O compilador entende exatamente onde cada bloco termina.


12. Intrinsic Functions

Durante muitos anos criávamos rotinas para tudo.

Hoje o compilador já oferece dezenas de funções.

Exemplos:

FUNCTION CURRENT-DATE

FUNCTION LENGTH

FUNCTION TRIM

FUNCTION LOWER-CASE

FUNCTION UPPER-CASE

Além de deixar o código mais elegante, elas costumam ser mais eficientes.


13. Evitar ALTER

ALTER era considerado brilhante.

Na década de 70.

Hoje virou pesadelo.

Ele altera dinamicamente o fluxo do programa.

Resultado:

  • difícil de entender;

  • difícil de depurar;

  • difícil de otimizar.

Por isso praticamente desapareceu dos novos projetos.


14. Reduzir GO TO

Existe um mito.

GO TO não é proibido.

Mas o excesso dele transforma um programa em um labirinto.

Imagine tentar seguir uma história cuja página seguinte muda aleatoriamente.

É exatamente essa sensação.

PERFORM e EVALUATE tornam o fluxo muito mais claro.


15. Migrar para Enterprise COBOL 6.x

Essa talvez seja a maior evolução dos últimos anos.

O compilador moderno entende muito melhor os processadores IBM Z atuais.

Isso significa:

  • menos CPU;

  • otimizações automáticas;

  • melhores diagnósticos;

  • suporte ampliado a JSON e XML;

  • novas funções intrínsecas.

Em muitos casos, apenas recompilar um programa com ajustes adequados já produz ganhos perceptíveis de desempenho.


16. Pensar em Integração

Esta talvez seja a maior mudança cultural.

Antes escrevíamos programas Batch.

Hoje escrevemos serviços corporativos.

Um programa COBOL pode atender:

  • Mobile Banking

  • Internet Banking

  • PIX

  • APIs REST

  • Java

  • Python

  • Node.js

  • OpenShift

  • Mensageria MQ

O código precisa nascer preparado para esse mundo.


O impacto nos programas antigos

A boa notícia é que a IBM sempre valorizou compatibilidade. Muitos programas escritos há décadas ainda compilam e executam nas versões atuais do Enterprise COBOL.

Isso, porém, não significa que estejam aproveitando os recursos modernos.

É comum encontrar aplicações com:

  • STOP RUN em todos os módulos;

  • dezenas de GO TO;

  • ALTER;

  • manipulação manual de XML e JSON;

  • ausência de verificações de dados;

  • poucas opções de diagnóstico.

Esses programas continuam funcionando, mas tendem a ser mais difíceis de manter, testar e integrar.

Modernizar não significa reescrever tudo. Em muitos casos, basta evoluir gradualmente: substituir comandos antigos, ativar opções do compilador, introduzir funções intrínsecas e organizar melhor o código.


A evolução de um Programador COBOL

Todo desenvolvedor passa por etapas.

Padawan

Aprende a sintaxe.

Consegue compilar.

Resolve problemas.

Programador

Começa a reutilizar código.

Escreve módulos.

Documenta interfaces.

Desenvolvedor Sênior

Pensa em desempenho.

CPU.

Memória.

Escalabilidade.

Arquiteto

Pensa no sistema inteiro.

Integração.

Disponibilidade.

Evolução.

Governança.

Perceba que, à medida que você cresce, a linguagem deixa de ser o foco principal. O importante passa a ser a qualidade das decisões.


O Mainframe moderno

Existe um mito antigo de que o Mainframe "parou no tempo".

Nada poderia estar mais distante da realidade.

Hoje um IBM Z pode:

  • expor APIs REST;

  • consumir serviços externos;

  • executar aplicações Java;

  • trabalhar com contêineres;

  • integrar-se ao OpenShift;

  • processar JSON e XML;

  • utilizar DevOps, Git e pipelines CI/CD;

  • compartilhar dados em tempo real com aplicações distribuídas.

O COBOL moderno acompanha essa evolução. As recomendações da IBM existem justamente para que o código continue relevante nesse novo cenário.


Conclusão

Existe uma frase que resume toda essa evolução:

"O melhor código não é aquele que apenas funciona hoje; é aquele que continuará funcionando, sendo compreendido e evoluído daqui a vinte anos."

As recomendações da IBM não representam uma ruptura com o passado. Elas representam a continuidade de uma filosofia que sempre guiou o Mainframe: estabilidade, desempenho, confiabilidade e evolução gradual.

Trocar STOP RUN por GOBACK, utilizar NUMCHECK, adotar SSRANGE nos testes, explorar JSON PARSE, JSON GENERATE, XML PARSE, RENT, funções intrínsecas e estruturas mais legíveis não é seguir uma moda. É escrever código preparado para um ambiente onde COBOL conversa diariamente com APIs, microsserviços, aplicações móveis e plataformas em nuvem.

Como Programador COBOL Padawan, seu objetivo não deve ser apenas aprender comandos. Deve ser entender por que eles existem, quando utilizá-los e como eles ajudam a construir sistemas capazes de sobreviver por décadas.

No Bellacosa Mainframe, costumamos dizer que a verdadeira modernização não começa com uma nova tecnologia. Ela começa quando o desenvolvedor muda sua forma de pensar. O compilador evolui, o hardware evolui, o IBM Z evolui — e o profissional que acompanha essa jornada deixa de apenas escrever programas para construir soluções que atravessam gerações.


Dos Cartões Perfurados ao Enterprise COBOL: A Evolução do STOP RUN e do GOBACK

 

Bellacosa Mainframe e as diferencas entre o goback e o stop run


Dos Cartões Perfurados ao Enterprise COBOL: A Evolução do STOP RUN e do GOBACK

Essa é uma excelente pergunta, e a resposta curta é:

Hoje, em projetos modernos de Enterprise COBOL para z/OS, a IBM e a maioria das empresas recomendam usar GOBACK em vez de STOP RUN. Não é apenas modismo; existem razões técnicas, arquiteturais e de reutilização do ambiente de execução (Language Environment). (IBM)

Vamos analisar como um arquiteto de Mainframe faria.


A origem do STOP RUN

Quando COBOL surgiu na década de 1960, praticamente todos os programas eram executados diretamente pelo sistema operacional.

O fluxo era simples:

JCL
 │
 ▼
Programa COBOL
 │
STOP RUN
 │
 ▼
MVS

Naquela época:

  • não existiam APIs REST;

  • não existiam aplicações reutilizáveis;

  • praticamente não existiam subprogramas complexos;

  • o programa começava e terminava.

O STOP RUN fazia exatamente isso:

"Acabei. Pode encerrar tudo."


O surgimento do GOBACK

Com o crescimento dos sistemas apareceram:

  • subprogramas

  • bibliotecas

  • módulos reutilizáveis

  • CICS

  • IMS

  • DB2

  • Language Environment (LE)

Agora um programa não era mais necessariamente o "programa principal".

Exemplo:

JCL

  MAIN01

     │

 CALL CLIENTE

     │

 CALL CALCJURO

     │

 CALL VALIDA

Imagine se CALCJURO executasse:

STOP RUN

O que aconteceria?

Toda a aplicação terminaria imediatamente.

Não apenas o módulo.

Todo o Run Unit.

É exatamente isso que a IBM documenta. STOP RUN termina toda a Run Unit; já GOBACK retorna ao chamador quando usado em um programa chamado. (IBM)


A grande diferença

STOP RUN

Programa

↓

encerra TODA a Run Unit

↓

retorna ao sistema operacional

GOBACK

Programa

↓

retorna para quem chamou

↓

continua a execução

Se o programa for o principal:

GOBACK

↓

faz praticamente o mesmo trabalho do STOP RUN

A IBM afirma isso explicitamente:

Em um programa principal, GOBACK funciona como STOP RUN. Em um subprograma, GOBACK funciona como EXIT PROGRAM. (IBM)


Exemplo prático

Programa principal

MAIN
CALL "A"

DISPLAY "FIM"

STOP RUN

Programa A

DISPLAY "A"

STOP RUN

Resultado

A

O DISPLAY "FIM"

nunca acontece.


Agora usando GOBACK

Programa A

DISPLAY "A"

GOBACK

Resultado

A

FIM

Porque voltou para o MAIN.


Então por que muitas empresas proíbem STOP RUN?

Não porque ele esteja errado.

Mas porque ele cria risco.

Imagine um programa hoje.

Batch

↓

Framework

↓

Biblioteca

↓

Serviço

↓

Seu Programa

Você nem sempre sabe quem chamou seu módulo.

Se usar

STOP RUN

você encerra toda a aplicação.

Se usar

GOBACK

o programa simplesmente devolve o controle.

Muito mais seguro.


O princípio da reutilização

Hoje escrevemos programas para serem reutilizados.

Um módulo pode ser chamado por:

  • Batch

  • CICS

  • IMS

  • API REST

  • MQ

  • Java

  • z/OS Connect

  • outro COBOL

O módulo não deve assumir que é o "dono" da aplicação.

Ele apenas faz seu trabalho.

Depois devolve o controle.

Isso é exatamente o comportamento do GOBACK.


O impacto no Language Environment (LE)

Aqui está uma das razões mais importantes.

O Enterprise COBOL roda sobre o Language Environment (LE).

O LE controla:

  • memória

  • pilha

  • heap

  • tratamento de exceções

  • inicialização

  • reutilização do runtime

Quando ocorre

STOP RUN

o LE encerra o Run Unit.

Quando ocorre

GOBACK

ele apenas retorna ao chamador.

Isso permite reutilizar o ambiente de execução em muitos cenários. (IBM)


O caso do RTEREUS

Pouca gente conhece essa opção.

Existe um parâmetro do LE chamado

RTEREUS

(Runtime Reuse)

Ele permite reutilizar o ambiente de execução COBOL.

A IBM afirma claramente:

Para obter os benefícios do RTEREUS, substitua STOP RUN por GOBACK. STOP RUN encerra o ambiente reutilizável. (IBM)

Ou seja:

STOP RUN

↓

destrói o ambiente

↓

novo ambiente precisa ser criado

Enquanto

GOBACK

↓

reutiliza o ambiente

↓

menos overhead

Performance

O ganho normalmente não é enorme em um programa isolado.

Mas imagine milhares de execuções por minuto.

1000 programas

↓

cada um recria o Runtime

↓

mais CPU

Com reutilização:

Runtime permanece ativo

↓

menos inicialização

↓

menos CPU

É exatamente por isso que grandes bancos adotam GOBACK como padrão.


E no CICS?

No CICS normalmente termina-se com

EXEC CICS RETURN

e não com

STOP RUN

porque quem controla a aplicação é o CICS.

O mesmo raciocínio vale para IMS.

O programa devolve o controle ao ambiente.

Não encerra a Run Unit.


Um exemplo interessante: DFSORT

A IBM é ainda mais direta na documentação de user exits do DFSORT:

User exits escritos em COBOL não devem usar STOP RUN. Para retornar ao DFSORT, use GOBACK. (IBM)

Ou seja,

STOP RUN

↓

encerra tudo

↓

ERRADO
GOBACK

↓

retorna ao DFSORT

↓

CORRETO

Existe recomendação oficial da IBM?

Sim.

A documentação oficial afirma que:

  • em programas principais, GOBACK tem o mesmo efeito de STOP RUN;

  • em subprogramas, GOBACK retorna ao chamador, enquanto STOP RUN termina toda a Run Unit. (IBM)

Além disso, para ambientes reutilizáveis (RTEREUS), a IBM recomenda trocar STOP RUN por GOBACK. (IBM)

Documentação oficial da IBM:

Minha recomendação para um COBOL Padawan

Se você está desenvolvendo em Enterprise COBOL moderno, adote esta regra simples:

SituaçãoRecomendação
Programa Batch principalGOBACK
Subprograma (CALL)GOBACK
Biblioteca reutilizávelGOBACK
Módulo chamado por Java, CICS, IMS ou APIsGOBACK
Novo desenvolvimentoGOBACK como padrão

Na prática, GOBACK é um superconjunto de STOP RUN: ele faz o papel de STOP RUN quando está no programa principal e o de EXIT PROGRAM quando está em um programa chamado. Isso reduz riscos, melhora a reutilização do runtime e torna o código mais flexível para arquiteturas modernas. Por esse conjunto de vantagens, a preferência atual por GOBACK é muito mais uma decisão de engenharia do que um simples modismo.

Design Patterns no COBOL Mainframe Os Padrões que os Grandes Programadores Sempre Usaram (Mesmo Antes de Eles Receberem um Nome)

 

Bellacosa Mainframe e os design pattern em cobol mainframe

☕ Um Café no Bellacosa Mainframe

Design Patterns no COBOL Mainframe

Os Padrões que os Grandes Programadores Sempre Usaram (Mesmo Antes de Eles Receberem um Nome)

"Todo programador COBOL iniciante acredita que um bom sistema nasce de um bom código. O programador experiente sabe que um bom sistema nasce de boas decisões de arquitetura."

Existe uma curiosidade fascinante na história da computação.

Quando ouvimos falar em Design Patterns, quase todo mundo lembra imediatamente do famoso livro Design Patterns: Elements of Reusable Object-Oriented Software, publicado em 1994 pelo famoso Gang of Four (GoF).

Muitos acreditam que os padrões nasceram ali.

Mas isso não é verdade.

Na realidade, os profissionais de Mainframe utilizavam padrões muito antes de eles receberem nomes elegantes.

Os sistemas bancários dos anos 70, 80 e 90 já possuíam separação de responsabilidades, reutilização de código, módulos especializados, camadas de acesso a banco, mecanismos de validação, tratamento centralizado de erros, componentes compartilhados e arquiteturas extremamente organizadas.

Eles simplesmente não chamavam isso de Pattern.

Chamavam de:

"Boa programação."

E existe um motivo simples.

Quando um sistema precisa sobreviver por 40 anos, processar bilhões de transações e nunca parar, improvisação não funciona.

É por isso que aprender Patterns em COBOL significa aprender como os grandes sistemas do mundo realmente funcionam.

Hoje vamos explorar essa jornada.

Pegue seu café.

Vamos entrar na mente dos arquitetos que construíram os sistemas que movimentam praticamente todo o dinheiro do planeta.


O que é um Pattern?

Pattern significa literalmente:

Padrão de solução.

Não é código.

Não é framework.

Não é biblioteca.

É uma maneira comprovada de resolver um problema recorrente.

Sempre que um problema aparece repetidamente, alguém encontra uma solução elegante.

Depois de milhares de aplicações, essa solução vira um padrão.


A origem dos Patterns

Antes mesmo da computação, um arquiteto chamado Christopher Alexander estudava cidades e construções.

Ele percebeu algo interessante.

As melhores cidades do mundo utilizavam soluções semelhantes para problemas semelhantes.

Uma praça.

Uma rua.

Uma entrada.

Uma janela.

Tudo seguia padrões.

Em 1977 ele publicou:

A Pattern Language.

Décadas depois, programadores perceberam:

"Software também possui problemas repetitivos."

Assim nasceram os Design Patterns modernos.


Mas... e o Mainframe?

Enquanto isso...

Em grandes bancos...

Seguradoras...

Governos...

Empresas aéreas...

Os analistas já utilizavam exatamente a mesma filosofia.

Um exemplo clássico.

Em vez de cada programa acessar DB2 diretamente...

Criava-se um módulo responsável apenas por isso.

Hoje chamaríamos isso de:

DAO Pattern.

Na época era apenas:

"O módulo que conversa com o banco."


Por que Patterns são importantes?

Imagine um hospital.

Você não quer que cada médico invente sua própria forma de operar.

Existe um procedimento.

Uma sequência.

Uma organização.

Software crítico funciona da mesma forma.

Patterns tornam sistemas:

  • previsíveis

  • fáceis de manter

  • fáceis de evoluir

  • seguros

  • reutilizáveis


Pattern 1 — Modularização

O primeiro pattern da história do Mainframe.

Um programa enorme faz tudo.

Depois de alguns anos...

Ninguém entende mais nada.

A solução?

Separar responsabilidades.

Exemplo:

Programa Principal

Validação

Regras de Negócio

DB2

Relatórios

Logs

Cada módulo possui apenas uma função.

Hoje isso parece óbvio.

Na década de 70 era revolucionário.


Como aplicar

Nunca escreva um programa de 5.000 linhas.

Pergunte:

Esta rotina pode virar um subprograma?

Se a resposta for sim...

Faça isso.


Pattern 2 — COPYBOOK Pattern

Uma das maiores invenções do COBOL.

Em vez de repetir estruturas...

Criamos COPYBOOKS.

Exemplo:

Cliente

Conta

Saldo

Endereço

CPF

Esses campos aparecem em centenas de programas.

Sem COPYBOOK...

Bastaria alterar um campo para criar centenas de inconsistências.

Com COPYBOOK...

Uma alteração.

Todos utilizam.


Boas práticas

Nunca copie estruturas manualmente.

Sempre centralize.


Pattern 3 — Validation Layer

Nunca misture validação com regra de negócio.

Errado:

Recebe CPF

Consulta DB2

Calcula juros

Valida CPF

Atualiza saldo

Tudo misturado.

Certo:

Entrada

Validação

Negócio

Persistência


Benefícios

Código mais limpo.

Testes mais simples.

Menos bugs.


Pattern 4 — Error Handler Centralizado

Um clássico absoluto.

Em vez de cada programa escrever mensagens diferentes...

Existe um módulo especializado.

Exemplo:

DISPLAY

ABEND

LOG

RETURN-CODE

Tudo passa por um componente comum.


Vantagens

Padronização.

Auditoria.

Facilidade de suporte.


Pattern 5 — File Access Layer

Em vez de cada programa abrir arquivos VSAM...

Criamos uma camada.

Programa

Arquivo Layer

VSAM

Se amanhã o arquivo virar DB2...

O programa quase não muda.


Isso é desacoplamento

A lógica de negócio não conhece detalhes físicos.

Esse conceito ficou famoso décadas depois.

No Mainframe já era realidade.


Pattern 6 — Database Access Layer

Muito comum em DB2.

Programa

Subprograma SQL

DB2

O programa não conhece SQL.

Conhece apenas serviços.

Exemplo:

Consultar Cliente

Atualizar Saldo

Inserir Conta

Excluir Registro

Muito semelhante aos Repository Patterns modernos.


Pattern 7 — Service Programs

Grandes empresas possuem centenas de programas.

Algumas regras aparecem em todos.

Cálculo de CPF.

Validação de agência.

Máscara.

Data.

Moeda.

Essas regras viram serviços.


Exemplo

CALL "CALCJURO"

CALL "VALIDCPF"

CALL "FORMATA"

CALL "DATAUTIL"

Isso reduz milhares de linhas duplicadas.


Pattern 8 — Dispatcher

Muito usado em CICS.

Um programa recebe uma operação.

Dependendo da função...

Chama outro programa.

Entrada

Dispatcher

Consulta

Inclusão

Alteração

Exclusão

Hoje chamamos isso de Command Dispatcher.


Pattern 9 — Table Driven Programming

Em vez de dezenas de IF...

Utilize tabelas.

Errado:

IF UF = SP

IF UF = RJ

IF UF = MG

...

Melhor:

Tabela de estados.

Pesquisa.

Resultado.

Menos código.

Mais manutenção.


Pattern 10 — Configuration Pattern

Nunca coloque constantes espalhadas.

Crie parâmetros.

Copybooks.

Arquivos.

Tabelas.

Isso evita recompilar programas para pequenas mudanças.


Pattern 11 — Batch Pipeline

Muito usado em processamento noturno.

Leitura

Validação

Transformação

Classificação

Carga

Cada etapa faz apenas uma coisa.

Se uma falhar...

A anterior permanece íntegra.


Pattern 12 — Restart Pattern

Um dos mais importantes.

Imagine um Batch de 8 horas.

Na hora 7 ocorre falha.

Sem Restart...

Tudo começa novamente.

Com Restart...

Continua do último checkpoint.

Essa ideia economiza milhões de dólares todos os anos.


Pattern 13 — Checkpoint Pattern

Muito usado com IMS.

A cada quantidade de registros...

Grava-se um ponto seguro.

Em caso de falha...

Retorna dali.


Pattern 14 — Logging Pattern

Nunca dependa apenas do DISPLAY.

Registre:

Programa

Data

Hora

Usuário

Arquivo

SQLCODE

Chave

Operação

Isso salva equipes inteiras durante incidentes.


Pattern 15 — Retry Pattern

DB2 indisponível?

Arquivo bloqueado?

MQ ocupado?

Em vez de falhar imediatamente...

Tente novamente algumas vezes.

Mas cuidado.

Retry infinito vira desastre.


Pattern 16 — Circuit Breaker (Modernização)

Muito usado via APIs.

Se um serviço externo está indisponível...

Pare de chamá-lo temporariamente.

Evita sobrecarga.


Pattern 17 — Adapter

Muito utilizado na modernização.

Sistema antigo

Adapter

API REST

O COBOL permanece praticamente igual.


Pattern 18 — Facade

Imagine vinte programas acessando vinte módulos.

Complicado.

Criamos uma fachada.

Programa

Facade

Serviços internos

Tudo fica mais simples.


Pattern 19 — Strategy

O cálculo muda conforme o produto.

Em vez de centenas de IF...

Criamos estratégias.

Produto A

Regra A

Produto B

Regra B

Produto C

Regra C


Pattern 20 — Template Process

Muito comum em Batch.

Todos os programas fazem:

Inicialização

Leitura

Processamento

Gravação

Fechamento

Apenas a lógica muda.

A estrutura permanece.


Como identificar quando usar um Pattern

Faça cinco perguntas:

  1. Estou repetindo código?

  2. Esse módulo possui mais de uma responsabilidade?

  3. Se mudar amanhã, quantos programas serão alterados?

  4. Consigo testar isoladamente?

  5. Outra equipe entenderia isso facilmente?

Se várias respostas forem "não"...

Provavelmente existe um Pattern melhor.


Os erros mais comuns dos iniciantes

O famoso "programa monolítico".

Tudo dentro da PROCEDURE DIVISION.

Milhares de linhas.

GO TO para todos os lados.

Variáveis globais.

DISPLAY espalhados.

SQL misturado.

Validação misturada.

Regras misturadas.

Esse tipo de programa funciona...

Até o primeiro incidente em produção.


Como evoluir como Programador COBOL

Existe uma evolução natural.

Nível 1

Aprende sintaxe.

MOVE.

IF.

PERFORM.

READ.

WRITE.


Nível 2

Aprende organização.

Seções.

Parágrafos.

COPYBOOKS.

Subprogramas.


Nível 3

Aprende Patterns.

Reutilização.

Arquitetura.

Modularização.


Nível 4

Aprende integração.

DB2.

CICS.

IMS.

MQ.

REST.

JSON.


Nível 5

Pensa como arquiteto.

Nesse ponto, você não escreve apenas programas.

Você desenha soluções.


Curiosidades

  • Muitos sistemas bancários escritos há mais de 35 anos continuam ativos porque seguiram padrões consistentes.

  • Diversos conceitos popularizados em Java, C# e outras linguagens já eram praticados em ambientes COBOL, ainda que com nomes diferentes.

  • O uso disciplinado de COPYBOOKS foi um dos fatores que permitiu manter aplicações enormes sincronizadas por décadas.

  • Grandes equipes de Mainframe costumam definir padrões internos de nomenclatura, tratamento de erros, chamadas de subprogramas e acesso a dados para reduzir riscos operacionais.


Melhores práticas para o dia a dia

  • Dê a cada programa uma responsabilidade clara.

  • Evite duplicação de lógica.

  • Centralize estruturas em COPYBOOKS.

  • Padronize mensagens de erro.

  • Isole acesso a arquivos e bancos de dados.

  • Documente interfaces de subprogramas.

  • Use nomes consistentes para programas, parágrafos e variáveis.

  • Escreva código pensando em quem fará a manutenção daqui a dez anos.

  • Prefira simplicidade à esperteza.

  • Revise continuamente seu código procurando oportunidades de extrair novos módulos reutilizáveis.


O futuro dos Patterns no Mainframe

O Mainframe moderno conversa com APIs REST, mensageria, microsserviços, Kubernetes, aplicações Java, Python e serviços em nuvem. Nesse cenário, os Patterns clássicos continuam mais relevantes do que nunca. Adapter, Facade, Retry, Circuit Breaker, Service Layer e Repository ajudam a integrar aplicações COBOL com tecnologias modernas sem sacrificar estabilidade.

O profissional que domina esses conceitos deixa de ser apenas um desenvolvedor de programas e passa a ser um engenheiro de soluções. Ele entende quando reutilizar, quando desacoplar, quando encapsular e quando simplificar. Esse conhecimento vale muito mais do que decorar comandos da linguagem.


Conclusão

Existe uma frase muito conhecida entre arquitetos de software:

"Código ruim pode funcionar. Arquitetura ruim cobra juros."

No universo IBM Z, essa cobrança aparece em horas extras, incidentes de produção, dificuldades de manutenção e projetos de modernização cada vez mais caros.

Os Patterns existem justamente para evitar esse cenário. Eles representam décadas de experiência acumulada por milhares de profissionais que enfrentaram os mesmos problemas e encontraram soluções elegantes, reutilizáveis e seguras.

Se você é um Programador COBOL Padawan, não tente memorizar todos os Patterns de uma vez. Comece pelos mais importantes: modularização, COPYBOOKS, validação, tratamento centralizado de erros, acesso a dados desacoplado e reutilização de serviços. À medida que sua experiência crescer, você perceberá que esses padrões aparecem naturalmente em praticamente todos os grandes sistemas corporativos.

Lembre-se: escrever código é uma habilidade. Escrever código que continuará funcionando e sendo compreendido daqui a vinte anos é uma arte. E essa arte é construída com disciplina, boas práticas e padrões sólidos.

No Bellacosa Mainframe, costumamos dizer que o verdadeiro poder de um Programador COBOL não está na quantidade de comandos que ele conhece, mas na qualidade das decisões que toma antes mesmo de começar a digitar a primeira linha de código.

Esse é o caminho que transforma um Padawan em um verdadeiro Mestre do Mainframe.

Se desejar, posso criar a Parte 2 com mais de 3.000 palavras, abordando 40+ Design Patterns específicos para COBOL, CICS, DB2, IMS, Batch, APIs REST, MQ e modernização no IBM Z, com exemplos completos de código COBOL para cada padrão.


quarta-feira, 1 de julho de 2026

Java na Stack Mainframe: O Roteiro Definitivo para um Programador COBOL Padawan Entrar no Mundo Java, IA, Cloud e Modernização do IBM Z

 

Bellacosa Mainframe e o Java na Stack Mainframe

☕ Um Café no Bellacosa Mainframe

Java na Stack Mainframe: O Roteiro Definitivo para um Programador COBOL Padawan Entrar no Mundo Java, IA, Cloud e Modernização do IBM Z

Imagine que você acabou de entrar em um grande banco.

Você conhece COBOL.

Sabe fazer um PERFORM UNTIL.

Entende JCL.

Já escreveu programas para CICS.

Conhece Db2, VSAM e talvez IMS.

Mas, em uma reunião, alguém diz:

"Vamos desenvolver essa nova API em Java, publicar pelo z/OS Connect, automatizar o deploy com Ansible e integrar um agente de IA."

Você pensa:

"Será que vou precisar esquecer tudo o que aprendi em Mainframe?"

A resposta é uma das melhores notícias que um profissional IBM Z pode receber:

Não.

Na verdade, tudo o que você aprendeu continua extremamente valioso.

O Java não veio substituir o COBOL.

Ele veio conversar com ele.

Hoje, o IBM Z é uma plataforma híbrida, onde aplicações COBOL escritas há décadas convivem com microsserviços Java, APIs REST, containers, LinuxONE, automação, inteligência artificial e cloud híbrida.

Neste artigo vamos construir um roteiro completo para que um COBOL Padawan evolua para um desenvolvedor Java dentro da Stack Mainframe.


O maior mito sobre Java no Mainframe

O erro mais comum é procurar um curso chamado:

  • Java para Mainframe

  • Java para z/OS

  • Java para COBOL

antes mesmo de aprender Java.

Isso é equivalente a querer aprender CICS antes de entender COBOL.

Primeiro aprendemos a linguagem.

Depois aprendemos onde ela roda.

Essa é exatamente a recomendação feita por Ian Burnett, engenheiro da equipe de desenvolvimento do IBM CICS:

"Java continua sendo Java. Salvo quando você utiliza recursos específicos do IBM Z, o mesmo código roda em diversas plataformas."

Essa frase resume toda a filosofia da plataforma Java.


Esqueça a ideia de "Java Mainframe"

Não existe uma linguagem chamada Java Mainframe.

Existe apenas Java.

O mesmo Java roda em:

  • Windows

  • Linux

  • macOS

  • LinuxONE

  • z/OS UNIX System Services (USS)

  • OpenShift

  • Cloud

A mágica acontece graças à JVM.


O que é a JVM?

JVM significa:

Java Virtual Machine

Ela é responsável por executar o bytecode produzido pelo compilador Java.

O processo funciona assim:

Código Java (.java)

        │

      javac

        │

Bytecode (.class)

        │

        JVM

        │

Sistema Operacional

No mundo IBM Z acontece exatamente a mesma coisa.

A diferença é que existe uma JVM otimizada para o processador IBM Z.

Hoje a IBM utiliza principalmente o IBM Semeru Runtime, baseado no OpenJDK, otimizado para z/OS e LinuxONE.

Isso significa que o mesmo programa Java pode executar em:

  • LinuxONE

  • USS

  • Open Liberty

  • CICS JVM Server

  • Batch Java

sem precisar ser reescrito.

É o famoso conceito:

Write Once, Run Anywhere.


O COBOL continua vivo?

Mais vivo do que nunca.

Os maiores bancos do mundo ainda executam bilhões de linhas de COBOL.

Esses programas representam décadas de regras de negócio.

Por exemplo:

  • cálculo de juros

  • empréstimos

  • cartões

  • PIX

  • investimentos

  • seguros

  • previdência

O Java não veio substituir essas aplicações.

Ele veio criar novas formas de utilizá-las.


O legado não é o problema

Existe uma frase muito repetida no Bellacosa Mainframe:

O legado não é um peso. É um patrimônio.

Imagine um programa COBOL que calcula crédito há trinta anos.

Ele funciona.

Foi testado milhões de vezes.

Então surge um aplicativo Android.

O aplicativo não precisa reescrever a lógica.

Ele apenas precisa conversar com esse programa.

É aí que entra a modernização.


Java como ponte entre o mundo moderno e o legado

Hoje uma aplicação bancária pode seguir este fluxo:

Aplicativo Android

↓

REST API

↓

Java Spring Boot

↓

z/OS Connect

↓

CICS

↓

Programa COBOL

↓

Db2

Observe quem está no meio da conversa.

O Java.

Ele conecta o mundo digital ao legado corporativo.


O papel do z/OS Connect

O z/OS Connect EE é uma das tecnologias mais importantes da modernização IBM Z.

Sua missão é simples.

Transformar programas COBOL em APIs REST.

Imagine um programa CICS chamado:

CONSULTA_CLIENTE

Antes, somente aplicações CICS conseguiam chamá-lo.

Com o z/OS Connect:

GET

/clientes/12345

vira automaticamente:

Programa COBOL

↓

COMMAREA

↓

Resposta JSON

Sem reescrever o COBOL.

Sem alterar décadas de negócio.

Essa talvez seja a maior revolução do IBM Z nos últimos anos.


JSON substituiu a COMMAREA?

Não.

Cada um possui sua função.

Dentro do CICS continua existindo:

  • COMMAREA

  • Containers

  • Channels

Fora do Mainframe:

  • JSON

  • REST

  • OpenAPI

O z/OS Connect faz a tradução entre esses mundos.


Java conversa naturalmente com o Db2

Outro ponto importante.

O Java utiliza JDBC.

Java

↓

JDBC

↓

Db2 for z/OS

Para quem conhece SQL em COBOL, aprender JDBC costuma ser bastante natural.


LinuxONE: onde o Java brilha

Quando falamos de Java no IBM Z, é impossível não falar do LinuxONE.

O LinuxONE é uma plataforma Linux construída sobre a mesma arquitetura IBM Z.

Ele oferece:

  • alta disponibilidade

  • criptografia

  • escalabilidade

  • virtualização

  • containers

  • Kubernetes

  • OpenShift

Para aplicações Java, é um ambiente extremamente eficiente.

Muitos microsserviços modernos executam em LinuxONE enquanto continuam acessando o legado z/OS.


Open Liberty

Outro componente importante é o Open Liberty.

Ele é um servidor Java moderno, extremamente leve e compatível com Jakarta EE e MicroProfile.

Nele podemos executar:

  • APIs REST

  • aplicações corporativas

  • microsserviços

  • autenticação

  • integração

Tudo isso podendo acessar COBOL via z/OS Connect ou IBM MQ.


IBM MQ

Nem toda integração precisa ser REST.

Muitos bancos utilizam filas.

Java

↓

IBM MQ

↓

COBOL

As mensagens ficam armazenadas até serem processadas.

Isso aumenta confiabilidade e desacopla sistemas.


Ansible no mundo Mainframe

Durante muitos anos administrar Mainframe significava executar comandos manualmente.

Hoje isso mudou.

O Ansible automatiza tarefas como:

  • criação de ambientes

  • deploy

  • configuração

  • instalação

  • atualização

  • coleta de informações

  • execução de scripts

Imagine precisar atualizar cinquenta servidores.

Em vez de acessar um por um, basta executar um Playbook.

Exemplo simplificado:

- Atualizar Open Liberty
- Reiniciar serviço
- Validar aplicação

Tudo automaticamente.

No IBM Z existem coleções específicas para:

  • z/OS

  • USS

  • CICS

  • RACF

  • datasets

  • JCL

  • operações administrativas

O DevOps chegou definitivamente ao Mainframe.


Cloud no mundo Mainframe

Quando falamos em Cloud, muitas pessoas imaginam abandonar o Mainframe.

A realidade é outra.

Hoje predominam arquiteturas híbridas.

Um exemplo:

Cloud

↓

API Gateway

↓

Java

↓

z/OS Connect

↓

COBOL

Parte da aplicação roda na nuvem.

Parte continua no IBM Z.

Cada ambiente faz aquilo em que é melhor.


Inteligência Artificial no IBM Z

Outro tema que deixou de ser futuro.

Hoje encontramos IA aplicada em:

  • detecção de fraudes

  • análise de crédito

  • observabilidade

  • automação operacional

  • atendimento inteligente

  • copilotos de desenvolvimento

  • geração de código

  • documentação

  • análise de logs

Modelos como IBM Granite e watsonx podem trabalhar lado a lado com aplicações Java e COBOL.

O objetivo não é substituir o programador.

É aumentar sua produtividade.


O roteiro Bellacosa para aprender Java

Fase 1 — Pensar como programador Java

Aprenda:

  • variáveis

  • classes

  • objetos

  • métodos

  • encapsulamento

  • herança

  • interfaces

  • exceções

  • Collections

  • Generics

Ainda não pense em Mainframe.


Fase 2 — Ferramentas modernas

Aprenda:

  • Git

  • Maven

  • Gradle

  • JUnit

  • Mockito

  • VS Code

  • IntelliJ IDEA


Fase 3 — Desenvolvimento Web

Estude:

  • HTTP

  • REST

  • JSON

  • XML

  • Servlets

  • APIs


Fase 4 — Spring Boot

Aprenda a criar:

  • microsserviços

  • APIs REST

  • autenticação

  • integração com bancos de dados


Fase 5 — Java Enterprise

Conheça:

  • Open Liberty

  • Jakarta EE

  • MicroProfile


Fase 6 — Java na Stack Mainframe

Agora sim, entre no universo IBM Z:

  • JVM no z/OS

  • USS

  • LinuxONE

  • JDBC para Db2

  • IBM MQ

  • CICS JVM Server

  • JCICS

  • JZOS

  • z/OS Connect EE

  • RACF

  • Open Liberty

  • Batch Java

  • OpenShift


O maior diferencial do programador COBOL

Muitos desenvolvedores Java sabem criar APIs.

Poucos entendem regras de negócio bancárias.

Você já conhece:

  • consistência transacional

  • processamento em lote

  • auditoria

  • integridade

  • alta disponibilidade

  • segurança

Esses conhecimentos não desaparecem.

Eles tornam você um profissional muito mais completo.


Recursos para continuar estudando

Além dos fundamentos de Java, vale explorar materiais específicos sobre Java no ecossistema IBM Z.

Java no CICS

Artigos técnicos

Open Liberty

IBM Semeru Runtime

IBM z/OS Connect

LinuxONE

Automação

IA para IBM Z


Um café antes de partir...

Se existe uma mensagem que todo Padawan COBOL deve levar deste artigo, é esta:

Você não está mudando de profissão. Está ampliando sua stack.

O COBOL continua sendo o coração de milhares de sistemas críticos. O Java tornou-se a ponte que conecta esse legado ao mundo das APIs, aplicativos móveis, microsserviços, cloud híbrida e inteligência artificial. Tecnologias como z/OS Connect, LinuxONE, Open Liberty, Ansible e watsonx não substituem décadas de conhecimento acumulado; elas o potencializam.

O profissional mais disputado da próxima década não será apenas o especialista em COBOL nem apenas o especialista em Java. Será aquele capaz de unir os dois mundos, preservando a confiabilidade do legado enquanto entrega inovação com velocidade. Esse é o verdadeiro espírito da Stack Mainframe: tradição e modernização trabalhando lado a lado. E essa jornada começa aprendendo Java, mas nunca esquecendo as lições que o Mainframe ensinou.

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.