Translate

sábado, 4 de julho de 2026

Projeto IBM - MSA 2025/2026

 ,

Bellacosa Mainframe conclui o programa IBM MSA 2025

Hoje encerro um ciclo muito especial da minha carreira como instrutor do MSA 2025/2026 (Mainframe Skills Academy).

Durante essa jornada, tive a honra de conduzir mais de 40 encontros, totalizando aproximadamente 60 horas de treinamento, além da produção de vídeos, laboratórios e materiais de apoio voltados à formação de profissionais em IBM Mainframe, com foco em System Programmers (SysProg) e System Administrators (SysAdmin).

Mais do que transmitir conhecimento, foi uma oportunidade de compartilhar experiências construídas ao longo de anos trabalhando com o ecossistema IBM Z e, ao mesmo tempo, aprender com o entusiasmo, a dedicação e as perguntas de cada participante.

Meus parabéns a todos os alunos que concluíram essa jornada. A evolução demonstrada ao longo do programa confirma que o Mainframe continua formando profissionais altamente qualificados para sustentar os sistemas mais críticos do mundo.

Também deixo meu reconhecimento aos organizadores, coordenadores, empresas parceiras e a todos os profissionais que trabalharam nos bastidores para tornar este projeto uma realidade. O sucesso do programa é resultado do esforço coletivo de muitas pessoas comprometidas com a formação de novos talentos.

Um agradecimento especial à IBM pela confiança, pelo convite para atuar como instrutor e pela oportunidade de contribuir com uma iniciativa que fortalece o ecossistema IBM Z e investe no crescimento profissional da comunidade técnica.

Foi uma grande satisfação fazer parte deste projeto.

Que esta seja apenas mais uma etapa de uma longa jornada de aprendizado, inovação e colaboração.

Parabéns a todos os envolvidos!

#IBM #IBMZ #IBMMainframe #Mainframe #SystemProgrammer #SysProg #SysAdmin #zOS #z17 #CICS #DB2 #IMS #JCL #COBOL #RACF #JES2 #TSO #ISPF #Automation #MainframeModernization #Infrastructure #EnterpriseComputing #BellacosaMainframe #MSA

Novo artigo no LinkedIn

Conclusão da formação MSA 2025/2026 em IBM Mainframe. Uma jornada dedicada à formação de SysProgs e SysAdmins.

O Que Todo Programador COBOL Padawan Precisa Saber Sobre Maquiavel, Poder, Longevidade e os 67 Anos de Reinado do COBOL

 

Bellacosa Mainframe e o principe aplicado ao Cobol

# ☕ Um Café no Bellacosa Mainframe

O Príncipe do Data Center

O Que Todo Programador COBOL Padawan Precisa Saber Sobre Maquiavel, Poder, Longevidade e os 67 Anos de Reinado do COBOL

"Você não está apenas aprendendo COBOL. Está estudando uma das maiores demonstrações de estratégia, sobrevivência e adaptação tecnológica da história da computação."


Existem livros que envelhecem.

Existem tecnologias que desaparecem.

E existem obras que atravessam séculos porque descrevem algo muito maior do que seu próprio tempo.

O Príncipe, escrito por Nicolau Maquiavel em 1513, pertence à segunda categoria.

COBOL, criado em 1959, pertence exatamente à mesma.

Não porque ambos sejam antigos.

Mas porque ambos falam sobre permanência.

Enquanto milhares de linguagens nasceram e desapareceram, enquanto gerações inteiras de frameworks surgiram e morreram, COBOL continua executando silenciosamente bilhões de dólares em transações todos os dias.

A pergunta não é:

"Como COBOL ainda existe?"

A pergunta correta é:

"O que COBOL fez certo durante mais de seis décadas?"

Talvez Maquiavel respondesse isso melhor do que qualquer arquiteto de software moderno.

Hoje vamos tomar um café e descobrir.


O príncipe nunca governa sozinho

No imaginário popular, um príncipe é o centro do poder.

Na prática, Maquiavel explica exatamente o contrário.

Um príncipe depende de:

  • seus ministros

  • seus exércitos

  • seus administradores

  • sua burocracia

  • sua capacidade de manter estabilidade.

Sem isso, o reino cai.

Agora substitua:

Príncipe → Banco

Reino → Data Center

Ministros → Programadores COBOL

Exército → Mainframe IBM Z

Leis → Regras de Negócio

Tesouro → Banco de Dados

De repente...

Você está olhando para praticamente qualquer banco do planeta.


O verdadeiro poder está na estabilidade

Maquiavel escreve que um governante deve evitar mudanças desnecessárias.

Não porque seja conservador.

Mas porque toda mudança gera instabilidade.

No desenvolvimento moderno muitas empresas seguem exatamente o caminho oposto.

Trocam linguagem.

Trocam banco.

Trocam framework.

Trocam arquitetura.

Trocam nuvem.

Trocam frontend.

Trocam backend.

Trocam metodologia.

Trocam tudo.

Enquanto isso...

COBOL permanece.

Não por teimosia.

Mas porque estabilidade é um ativo.


A fortuna favorece quem controla o risco

Um dos conceitos mais famosos de Maquiavel é a Fortuna.

Para ele, metade da vida pertence ao acaso.

A outra metade depende da capacidade do governante.

No mundo corporativo acontece exatamente isso.

Ninguém controla:

  • crises econômicas

  • pandemias

  • ataques hackers

  • inflação

  • guerras

  • apagões

Mas pode controlar seus sistemas.

É exatamente aí que o Mainframe reina.

Durante décadas, bancos continuaram funcionando enquanto o mundo inteiro mudava.

Não foi sorte.

Foi engenharia.


O príncipe deve conhecer profundamente seu território

Maquiavel afirma que o governante precisa caminhar pelo próprio reino.

Conhecer cidades.

Conhecer fronteiras.

Conhecer recursos.

Conhecer ameaças.

Um programador COBOL faz exatamente isso.

Ele conhece:

  • layouts

  • arquivos VSAM

  • DB2

  • CICS

  • JCL

  • Batch

  • Online

  • Scheduler

  • RACF

  • filas

  • integrações

Ele entende onde cada dado nasce.

Por onde ele passa.

Quem altera.

Quem consulta.

Quem depende.

Essa visão sistêmica raramente aparece em cursos modernos.


A reputação vale mais do que promessas

Maquiavel dizia:

Um príncipe precisa parecer confiável.

No mundo corporativo isso se traduz em algo extremamente simples.

O sistema precisa funcionar.

Não importa se usa IA.

Não importa se usa Kubernetes.

Não importa se usa microsserviços.

O cliente quer sacar dinheiro.

O cartão precisa autorizar.

O PIX precisa concluir.

O seguro precisa pagar.

O voo precisa decolar.

O imposto precisa ser calculado.

Quem entrega isso?

COBOL.

Todos os dias.

Sem marketing.

Sem hype.

Sem palco.


O exército mercenário

Maquiavel criticava fortemente exércitos mercenários.

Eles funcionam enquanto tudo está bem.

Na primeira crise...

Fogem.

Curiosamente, existe um paralelo tecnológico.

Hoje vemos projetos compostos por dezenas de bibliotecas externas.

Centenas de dependências.

Frameworks que mudam todo mês.

Projetos que deixam de funcionar porque uma versão foi descontinuada.

Esse é o exército mercenário da engenharia de software.

COBOL, por outro lado, sempre valorizou outro princípio.

Poucas dependências.

Padronização.

Compatibilidade.

Documentação.

Retrocompatibilidade.

Essa filosofia talvez pareça menos moderna.

Mas produz sistemas que sobrevivem décadas.


O príncipe deve pensar em gerações

Empresas normalmente pensam no próximo trimestre.

Governos pensam na próxima eleição.

O Mainframe pensa nos próximos vinte anos.

Essa diferença muda completamente a forma como software é construído.

Em COBOL ninguém escreve código esperando descartá-lo em seis meses.

Escreve-se pensando:

"Quem fará manutenção daqui a quinze anos?"

Essa pergunta muda completamente a qualidade do código.


A virtù do programador COBOL

Maquiavel usa frequentemente a palavra Virtù.

Ela não significa virtude moral.

Significa competência.

Capacidade.

Preparação.

Coragem.

Disciplina.

No mundo Mainframe essa Virtù aparece de inúmeras formas.

Um bom profissional domina:

  • regras de negócio

  • modelagem

  • desempenho

  • documentação

  • rastreabilidade

  • testes

  • processamento batch

  • transações online

Ele sabe que escrever código é apenas uma pequena parte do trabalho.


O castelo invisível

Poucas pessoas entram em um data center.

Menos ainda conhecem um IBM Z.

Entretanto...

Grande parte da economia mundial depende deles.

É como um castelo medieval.

A população talvez nunca veja seus muros.

Mas dorme tranquila porque eles existem.

COBOL vive exatamente nesse castelo invisível.

Sem glamour.

Sem manchetes.

Mas sustentando bancos, seguradoras, governos, bolsas de valores, companhias aéreas e sistemas de saúde.


A arte de evitar guerras

Maquiavel ensina que um governante inteligente evita conflitos desnecessários.

Na engenharia de software isso significa reduzir risco operacional.

Cada alteração em produção possui custo.

Cada mudança possui impacto.

Cada deploy possui risco.

Por isso Mainframes evoluem de maneira extremamente controlada.

Existe planejamento.

Teste.

Homologação.

Plano de retorno.

Auditoria.

Mudanças são feitas com precisão cirúrgica.

Não porque sejam lentos.

Porque indisponibilidade custa milhões.


O tempo é o verdadeiro juiz

Em tecnologia existe um fenômeno curioso.

Quase tudo parece revolucionário no lançamento.

Mas poucos sobrevivem.

Linguagens desapareceram.

Bancos desapareceram.

Sistemas operacionais desapareceram.

Empresas desapareceram.

COBOL permanece.

Isso deveria despertar uma reflexão importante.

Talvez a pergunta nunca tenha sido:

"Qual tecnologia é mais moderna?"

Mas:

"Qual tecnologia continua resolvendo o problema sessenta anos depois?"


O príncipe moderno usa APIs

Alguns acreditam que Mainframe ficou parado no tempo.

Nada mais distante da realidade.

Hoje um programa COBOL conversa com:

  • APIs REST

  • JSON

  • XML

  • Kafka

  • IBM MQ

  • Java

  • Python

  • Node.js

  • microsserviços

  • OpenShift

  • Kubernetes

  • IA Generativa

O rei continua sentado no trono.

Mas agora conversa com todo o reino.


Não existe império sem registros

Reinos mantinham livros.

Cartórios.

Arquivos.

Impostos.

Inventários.

Hoje fazemos exatamente a mesma coisa.

Mudou apenas o suporte.

O que antes era pergaminho virou:

DB2.

VSAM.

IMS.

Logs.

SMF.

Datasets.

O princípio continua igual.

Governar é administrar informação.

COBOL sempre entendeu isso.


A paciência vence a velocidade

Vivemos na cultura do imediato.

Deploy contínuo.

Atualização diária.

Nova versão semanal.

Nova IA todo mês.

Mas grandes organizações trabalham em outra escala.

Décadas.

Não dias.

É por isso que COBOL parece lento para quem observa de fora.

Na verdade, ele apenas opera em uma escala temporal diferente.


A sucessão do reino

Maquiavel também falava sobre sucessão.

Como manter o reino vivo após uma geração?

Essa talvez seja a maior preocupação atual do Mainframe.

Milhares de especialistas estão se aposentando.

Mas isso não significa o fim do COBOL.

Significa o início de uma nova geração.

Hoje surgem:

  • IA para documentação

  • copilotos para COBOL

  • modernização automática

  • análise de código por LLMs

  • conversão assistida

  • testes automatizados

  • engenharia reversa inteligente

Curiosamente...

A Inteligência Artificial não elimina COBOL.

Ela aumenta sua produtividade.


O príncipe aprende com o passado

Existe um erro comum entre iniciantes.

Imaginar que tecnologia evolui em linha reta.

Não evolui.

Ela evolui em espiral.

Conceitos retornam constantemente.

Orientação a objetos.

Serviços.

Eventos.

Mensageria.

Virtualização.

Containers.

Tudo possui ancestrais.

O Mainframe já utilizava muitos desses princípios décadas antes de eles se tornarem moda.

Estudar COBOL é compreender essas raízes.


O reino da confiança

Dinheiro não aceita erros.

Saúde não aceita erros.

Aeronáutica não aceita erros.

Previdência não aceita erros.

Quando uma empresa escolhe COBOL para processos críticos, ela não está escolhendo nostalgia.

Está escolhendo previsibilidade.

Confiabilidade.

Auditabilidade.

Governança.

Esses atributos raramente aparecem em rankings de linguagens.

Mas aparecem diariamente no balanço financeiro das maiores instituições do planeta.


A lição que Maquiavel talvez escrevesse hoje

Se Maquiavel visitasse um grande banco moderno, talvez percebesse algo familiar.

Salas silenciosas.

Processos rigorosos.

Hierarquias claras.

Regras definidas.

Disciplina operacional.

Controle absoluto sobre informações estratégicas.

Ele provavelmente reconheceria ali um novo tipo de principado.

Não governado por espadas.

Mas por transações.

Não protegido por muralhas.

Mas por criptografia, redundância, RACF, auditorias e arquitetura resiliente.

E talvez sorrisse ao descobrir que, no centro desse império digital, ainda existe uma linguagem criada em 1959 conduzindo milhões de operações por segundo.


Conclusão: O verdadeiro príncipe nunca buscou ser moderno

Existe uma frase frequentemente atribuída à tecnologia:

"O melhor software é aquele que ninguém percebe que existe."

COBOL representa exatamente isso.

Ele não precisa aparecer em conferências para provar seu valor.

Não precisa ser tendência nas redes sociais.

Não precisa mudar de sintaxe a cada versão.

Seu poder está em algo muito mais raro.

Confiabilidade construída ao longo de décadas.

Assim como O Príncipe continua sendo estudado mais de 500 anos após sua publicação, COBOL continua sendo utilizado porque ambos compartilham a mesma essência: não foram criados para impressionar, mas para durar.

No Bellacosa Mainframe, costumamos dizer que aprender COBOL não é apenas aprender uma linguagem. É aprender como sistemas críticos permanecem relevantes quando todo o resto muda. É entender que arquitetura, disciplina, documentação, regras de negócio e estabilidade não são conceitos ultrapassados, mas fundamentos que sustentam bancos, governos e empresas em todos os continentes.

No fim, a maior lição de Maquiavel aplicada ao Mainframe talvez seja esta:

O verdadeiro poder não pertence ao mais novo, ao mais rápido ou ao mais barulhento. Pertence àquilo que continua funcionando quando todos os outros já desapareceram.

E, depois de mais de 65 anos, o COBOL continua sentado, silenciosamente, no trono do data center.

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

O Ecossistema Moderno da Inteligência Artificial

 

Bellacosa Mainframe e o ecosistema moderno da inteligencia artificial

☕ Um Café no Bellacosa Mainframe

O Ecossistema Moderno da Inteligência Artificial

O Que Todo Programador COBOL Padawan Precisa Saber Sobre LLMs, Agentes, RAG, MCP e a Nova Arquitetura da Engenharia de Software

"Você não está apenas aprendendo Inteligência Artificial. Está descobrindo como a próxima geração de sistemas corporativos será construída sobre os mesmos princípios que fizeram o Mainframe dominar o mundo por mais de seis décadas."


Quando um programador COBOL observa um diagrama como o do moderno ecossistema de IA, a primeira impressão costuma ser de espanto.

São dezenas de logotipos.

Centenas de tecnologias.

Novos nomes surgindo toda semana.

LangGraph.

CrewAI.

MCP.

RAG.

Embeddings.

Vector Databases.

Semantic Kernel.

OpenAI Agents.

n8n.

Qdrant.

Chroma.

Parece que a indústria enlouqueceu.

Mas existe uma boa notícia.

Ela não enlouqueceu.

Ela apenas reinventou, com novos nomes, diversos conceitos que um profissional de Mainframe já conhece há décadas.

É justamente por isso que muitos engenheiros IBM Z estão conseguindo compreender Inteligência Artificial muito mais rapidamente do que imaginam.

Eles já aprenderam, durante anos, a construir sistemas distribuídos, modulares, seguros, escaláveis e altamente confiáveis.

A diferença é que agora o "programa" também sabe conversar.


A Grande Ilusão

Existe um erro que praticamente todo iniciante comete.

Ele acredita que ChatGPT é Inteligência Artificial.

Não é.

ChatGPT é apenas uma interface.

Da mesma forma que um terminal 3270 não é o Mainframe.

O terminal apenas conversa com o Mainframe.

Da mesma maneira, GPT, Claude e Gemini são apenas modelos de linguagem.

Eles representam apenas uma pequena camada de uma arquitetura muito maior.

Hoje, quando uma empresa desenvolve um sistema baseado em IA, ela não utiliza apenas um modelo.

Ela utiliza um verdadeiro ecossistema.

E compreender esse ecossistema é o primeiro passo para deixar de ser apenas um usuário de IA e tornar-se um engenheiro de soluções inteligentes.


Pense Como um Arquiteto de Mainframe

Imagine um grande banco.

Existe apenas o COBOL?

Claro que não.

Há:

  • z/OS

  • JES2

  • RACF

  • CICS

  • IMS

  • DB2

  • MQ

  • VSAM

  • JCL

  • TSO

  • SDSF

  • WLM

  • RMF

O COBOL é apenas uma peça.

Da mesma forma, o GPT é apenas uma peça.

A IA moderna possui dezenas de componentes especializados.

Cada um resolve um problema específico.


O LLM é Apenas o Cérebro

Todo ser humano possui cérebro.

Mas ninguém vive apenas com ele.

Também precisamos de memória.

Olhos.

Ouvidos.

Ferramentas.

Experiência.

Conhecimento.

O LLM é exatamente isso.

É o cérebro.

Ele sabe raciocinar.

Escrever.

Explicar.

Traduzir.

Criar código.

Mas ele não conhece sua empresa.

Ele nunca viu seu programa COBOL.

Nunca acessou seu catálogo DB2.

Nunca leu seu manual interno.

E nem poderia.

Seu treinamento terminou muito antes do seu sistema existir.

Então surge uma pergunta interessante.

Como fazer um modelo responder corretamente sobre algo que nunca viu?

É aí que começa a verdadeira engenharia da IA.


RAG: A Biblioteca Inteligente

Imagine que você entrou em uma biblioteca gigantesca.

Você pergunta:

— Onde está o manual do programa FINC023?

O bibliotecário não sabe a resposta.

Mas ele sabe exatamente em qual estante procurar.

Depois entrega o livro para você.

É exatamente isso que um sistema RAG faz.

Retrieval Augmented Generation significa que o modelo recebe ajuda antes de responder.

Primeiro ele pesquisa.

Depois encontra os documentos.

Só então responde.

Perceba como isso lembra o trabalho de um programador COBOL.

Você raramente responde de memória.

Antes consulta:

  • Copybooks

  • PROCs

  • Catálogos

  • Manuais

  • Diagramas

  • Modelagem

  • Documentação funcional

Você faz Retrieval.

Depois gera sua resposta.

Ou seja...

Você já fazia RAG muito antes desse nome existir.


Embeddings: Quando Palavras Viram Matemática

Talvez este seja o conceito que mais assusta iniciantes.

Mas, curiosamente, ele também possui uma analogia muito simples.

Imagine um cadastro de clientes.

Para o banco, "José da Silva" não é apenas texto.

Ele possui:

CPF.

Código.

Conta.

Agência.

Segmento.

Classificação.

Esses atributos permitem localizar clientes rapidamente.

Os Embeddings fazem algo semelhante.

Eles transformam palavras em coordenadas matemáticas.

Em vez de armazenar apenas "cliente", armazenam centenas ou milhares de números que representam o significado daquela palavra.

É como se cada conceito ocupasse uma posição em um enorme universo tridimensional.

Assim:

"COBOL"

fica muito próximo de

"Mainframe"

"DB2"

"CICS"

"JCL"

Enquanto

"Banana"

fica extremamente distante.

Essa organização matemática permite pesquisas incrivelmente inteligentes.


Bancos Vetoriais: O Novo VSAM da IA

Depois que criamos milhões de embeddings...

Onde armazená-los?

Surge então uma nova categoria de bancos.

Os Vector Databases.

Pinecone.

Qdrant.

Milvus.

Weaviate.

Chroma.

Elasticsearch.

Redis.

pgvector.

Todos foram criados para responder uma pergunta muito específica.

"Qual informação é semanticamente parecida com esta pergunta?"

Observe como isso lembra o VSAM.

No VSAM usamos índices.

Chaves.

KSDS.

AIX.

Aqui utilizamos vetores.

A ideia é diferente.

Mas o objetivo continua o mesmo.

Encontrar dados rapidamente.


Agentic AI: Quando o Programa Aprende a Trabalhar

Durante décadas escrevemos programas assim:

Entrada.

Processamento.

Saída.

Fim.

Agora imagine um programa que decide sozinho qual será o próximo passo.

Ele analisa o problema.

Divide em tarefas.

Consulta documentos.

Executa SQL.

Gera relatório.

Verifica erros.

Corrige.

Repete.

Entrega o resultado.

Isso é um Agent.

Ele deixa de ser apenas um chatbot.

Passa a ser um trabalhador digital.

Pense em uma equipe.

Existe um analista.

Um desenvolvedor.

Um DBA.

Um arquiteto.

Um tester.

Um gerente.

Agora imagine que todos eles são agentes especializados conversando entre si.

É exatamente isso que frameworks como CrewAI, LangGraph e AutoGen permitem construir.


LangGraph: O CICS da Inteligência Artificial?

Essa comparação costuma provocar sorrisos.

Mas faz bastante sentido.

No CICS, cada transação chama outras rotinas.

Cada programa possui um fluxo.

Existem estados.

Eventos.

Retornos.

No LangGraph ocorre algo parecido.

Criamos grafos de execução.

Cada nó representa uma etapa.

Cada decisão direciona o fluxo.

É uma forma elegante de construir aplicações inteligentes extremamente complexas.


MCP: O USB-C da Inteligência Artificial

Imagine os anos 90.

Cada impressora utilizava um cabo diferente.

Cada mouse possuía um conector.

Cada teclado era incompatível.

Hoje praticamente tudo utiliza USB.

O MCP representa exatamente essa evolução.

Model Context Protocol.

Ele cria uma linguagem comum entre modelos e ferramentas.

Em vez de construir um conector para GPT.

Outro para Claude.

Outro para Gemini.

Criamos apenas um servidor MCP.

Todos os modelos conversam com ele.

É como um middleware corporativo.

Para quem conhece MQ, a ideia soa bastante familiar.


Segurança Continua Sendo Fundamental

Existe um mito de que IA responde qualquer coisa.

Em produção isso seria um desastre.

Imagine perguntar:

"Mostre todos os salários da empresa."

Ou:

"Liste os CPFs dos clientes."

Ou ainda:

"Ignore todas as regras de segurança."

Sem proteção, um agente poderia cometer erros gravíssimos.

Por isso surgiram plataformas como:

Guardrails.

Lakera.

Presidio.

Azure Content Safety.

AWS Guardrails.

Elas fazem para IA aquilo que RACF faz para o Mainframe.

Controlam acesso.

Protegem informações.

Validam permissões.

Filtram conteúdos.

A tecnologia muda.

O princípio continua exatamente igual.


Observabilidade: O RMF da Nova Geração

Depois que um sistema entra em produção surgem perguntas inevitáveis.

Quanto tempo levou?

Quanto custou?

Qual prompt gerou essa resposta?

Quantos tokens foram utilizados?

Qual documento foi consultado?

Qual modelo respondeu?

Qual etapa falhou?

Ferramentas como LangSmith, Langfuse, Ragas e Arize Phoenix fazem exatamente isso.

Monitoram todo o comportamento do agente.

Se você já utilizou RMF, SMF, OMEGAMON ou SDSF, entenderá rapidamente essa filosofia.

Não basta executar.

É preciso medir.


Memória: Muito Além da Conversa

Outro conceito extremamente interessante é Memory.

Uma conversa comum termina quando fechamos a janela.

Um agente moderno não.

Ele pode lembrar.

Pode aprender.

Pode manter histórico.

Pode armazenar preferências.

Imagine um assistente para Mainframe.

Na primeira semana você informa:

"Trabalho com COBOL, DB2 e CICS."

Seis meses depois pergunta:

"Como otimizar meus programas?"

Ele já sabe qual ambiente você utiliza.

Não precisa perguntar novamente.

Essa continuidade transforma completamente a experiência.


Automação: Quando Tudo Começa a Conversar

Talvez a camada mais fascinante seja Automação.

Ferramentas como:

n8n.

Zapier.

Make.

Power Automate.

Apache Airflow.

Temporal.

Kestra.

Permitem construir verdadeiras linhas de produção digitais.

Imagine o seguinte fluxo.

Um desenvolvedor faz commit.

O GitHub dispara um evento.

O agente revisa o código COBOL.

Consulta padrões internos.

Executa testes.

Gera documentação.

Atualiza o Jira.

Envia mensagem ao Teams.

Tudo automaticamente.

Sem intervenção humana.


O Programador COBOL Está em Vantagem

Existe uma crença de que profissionais Mainframe ficaram ultrapassados.

Na prática, acontece exatamente o contrário.

Quem trabalhou décadas construindo sistemas críticos desenvolveu competências extremamente valiosas.

Modelagem.

Governança.

Segurança.

Transações.

Escalabilidade.

Confiabilidade.

Integração.

Esses mesmos conceitos estão voltando com força total na IA.

A diferença é que agora os componentes possuem novos nomes.

Em vez de RACF temos Guardrails.

Em vez de MQ temos MCP.

Em vez de índices VSAM temos Vector Databases.

Em vez de documentação estática temos RAG.

Em vez de batchs inteligentes temos Agentes.

Mas os princípios continuam incrivelmente familiares.


O Futuro Não Será Escrito Apenas em Python

Existe outro mito bastante difundido.

"O futuro pertence apenas ao Python."

Não.

O futuro pertence às arquiteturas.

Empresas não substituem décadas de regras de negócio.

Elas integram.

Conectam.

Modernizam.

Um agente inteligente poderá consultar programas COBOL.

Executar SQL em DB2.

Chamar APIs REST.

Conversar com Java.

Interagir com microsserviços.

Consumir filas MQ.

Tudo dentro da mesma solução.

O COBOL não desaparecerá.

Ele se tornará mais acessível.

Mais documentado.

Mais pesquisável.

Mais integrado.

Mais inteligente.


O Próximo Passo da Jornada

Durante muitos anos, aprender informática significava decorar comandos.

Depois passamos a aprender linguagens.

Mais tarde vieram frameworks.

Agora estamos entrando em uma nova era.

A era das arquiteturas cognitivas.

O profissional mais valorizado não será aquele que conhece apenas um modelo de IA.

Será aquele que entende como conectar modelos, dados, memória, segurança, observabilidade, automação e regras de negócio para resolver problemas reais.

É exatamente isso que a imagem do ecossistema moderno representa.

Ela não mostra apenas ferramentas.

Mostra uma mudança profunda na forma como desenvolvemos software.

Para o Programador COBOL Padawan, essa não é uma ruptura com tudo o que aprendeu.

É uma continuação da mesma jornada.

Você já conhece modularização.

Já conhece transações.

Já conhece processamento em larga escala.

Já conhece governança.

Agora chegou a hora de acrescentar um novo capítulo à sua carreira.

Aprender LLMs, RAG, Agentes, MCP e Bancos Vetoriais não significa abandonar o Mainframe.

Significa construir uma ponte entre sessenta anos de engenharia de software e a próxima geração de sistemas inteligentes.

E talvez essa seja a maior lição desta nova revolução tecnológica.

A Inteligência Artificial não substitui a boa engenharia. Ela amplia o alcance daqueles que já aprenderam a construir sistemas robustos, confiáveis e duradouros.

No fim das contas, um verdadeiro COBOL Padawan percebe que as tecnologias mudam, os nomes evoluem e os logotipos se multiplicam. Mas os fundamentos permanecem: compreender o problema, modelar a solução, proteger os dados, garantir a confiabilidade e entregar valor ao negócio. Foi assim no Mainframe. É assim na Inteligência Artificial. E continuará sendo assim nas próximas décadas.