☕ Um Café no Bellacosa Mainframe
Gostou do conteúdo? Ajude a manter o café quente, o COBOL compilando e o mainframe acordado. 😄
☕ Pague um café ao Bellacosa

Translate

Mostrar mensagens com a etiqueta Sistemas Bancários. Mostrar todas as mensagens
Mostrar mensagens com a etiqueta Sistemas Bancários. Mostrar todas as mensagens

segunda-feira, 27 de abril de 2026

🔥💣 RAG NÃO SOBE JOB: O DIA EM QUE A IA QUEBROU O MAINFRAME (E NINGUÉM SABIA POR QUÊ) 💣🔥

 

Bellacosa Mainframe e os perigos da IA

🔥💣 RAG NÃO SOBE JOB: O DIA EM QUE A IA QUEBROU O MAINFRAME (E NINGUÉM SABIA POR QUÊ) 💣🔥

Um guia definitivo — raiz, sem filtro e sem buzzword — para quem quer usar IA no mundo COBOL sem destruir produção


Se você está entrando agora no mundo do mainframe — ou pior, se já está nele e alguém apareceu com um PowerPoint prometendo “modernização com IA em 3 meses” — este artigo é o seu firewall mental.

Porque aqui vai a verdade que ninguém coloca no slide:

💣 Mainframe não é código. É execução.

E execução tem história, dependência, tempo, estado… e consequências.


🧠⚙️ FUNDAMENTO: O QUE OS “PADAWANS COBOL” PRECISAM ENTENDER

Antes de falar de IA, RAG ou qualquer buzzword, você precisa internalizar isso:

🏦 O ecossistema real do z/OS

  • COBOL → lógica de negócio
  • JCL (Job Control Language) → orquestração
  • CICS → mundo transacional online
  • VSAM → armazenamento estruturado crítico
  • Db2 → consistência e persistência
  • Scheduler (Control-M, CA-7) → o “tempo” do sistema

👉 Isso forma um grafo de execução vivo.

Não é um repositório. Não é um projeto.
É um organismo.


💣🔥 O PECADO ORIGINAL: “CÓDIGO É SÓ TEXTO”

Ferramentas modernas tratam código assim:

função → entrada → saída

Mas no mainframe:

JCL → dataset → SORT → VSAM → COBOL → CICS → Db2 → JOB seguinte

💥 Isso é um pipeline físico e temporal.


🤖 O QUE É RAG (E POR QUE ELE TE TRAI)

RAG (Retrieval-Augmented Generation) faz:

  1. Quebra código em pedaços
  2. Vetoriza (transforma em embeddings)
  3. Busca por similaridade
  4. Responde com base nisso

👉 Funciona bem em:

  • APIs modernas
  • microserviços
  • código isolado

👉 Falha brutalmente em:

  • sistemas batch
  • fluxos dependentes
  • ambientes com estado externo

⚠️💣 EXEMPLO REAL — O ERRO QUE TODO MUNDO COMETE

🧾 Código COBOL:

READ CLIENTE-FILE
IF STATUS NOT = 'OK'
PERFORM ERRO
END-IF

🤖 IA (RAG) responde:

“Se falhar, chama rotina ERRO”

😈 Realidade:

  • O arquivo foi gerado por um SORT no JCL
  • O erro dispara um ABEND
  • O CICS intercepta
  • Um handler redireciona
  • O erro vai para Db2
  • Um job batch reconcilia depois

💣 Resultado:
A IA ignorou 80% do sistema.


⏱️💀 O FATOR TEMPO (O ASSASSINO SILENCIOSO)

Mainframe não é só lógica — é quando algo acontece.

Exemplo:

01:00 → JOB-A cria dataset
02:00 → JOB-B transforma
03:00 → COBOL processa

👉 Se o JOB-A falhar:

  • o COBOL continua existindo
  • mas o sistema quebra

💥 RAG não vê isso.


🕳️🔥 CICS: O BURACO NEGRO DA ANÁLISE

No mundo online:

  • Você NÃO chama programa diretamente
  • Existe:
    • definição de transação
    • routing
    • interceptação

👉 O fluxo real passa por camadas invisíveis ao código.

💣 Resultado:
A lógica está fora do COBOL.


🚨💣 RISCOS REAIS (NÃO TEÓRICOS)

1. 🔥 Decisão errada de negócio

IA responde incompleto → time muda código → quebra fluxo batch


2. 💥 Impacto invisível

Mudança em um programa:

  • quebra 3 jobs
  • afeta 2 sistemas downstream
  • só aparece às 3 da manhã

3. ⚠️ Compliance e auditoria

Sistema financeiro exige rastreabilidade
RAG não explica origem do dado


4. 🧨 Debug impossível

Erro não está no código
Está no fluxo


🐞💣 BUG CLÁSSICO DE QUEM USA IA ERRADO

“O programa não mudou, mas o resultado mudou”

👉 Motivo:

  • dataset diferente
  • ordem diferente
  • job anterior falhou

💥 IA não vê histórico → você caça fantasma


🧠💡 BOAS PRÁTICAS (OU COMO NÃO VIRAR INCIDENTE)

✅ 1. Modele o fluxo, não só o código

  • entenda JCL
  • entenda datasets
  • entenda ordem de execução

✅ 2. Pense em GRAFO, não em arquivos

  • quem chama quem
  • quem depende de quem
  • quem produz o quê

✅ 3. Trace o lineage dos dados

Pergunta chave:

“De onde veio esse dataset?”

Se você não sabe → risco crítico


✅ 4. Entenda o runtime

  • batch vs online
  • interceptações CICS
  • handlers

✅ 5. Use IA como apoio — não como verdade

IA ajuda, mas:

💣 não tem visão sistêmica por padrão


🛠️🔥 ARQUITETURA CORRETA (NÍVEL PROFISSIONAL)

Se quiser usar IA de verdade:

🧩 Combine:

  • Graph Database → dependências reais
  • Parser de JCL → fluxo batch
  • Parser CICS → fluxo online
  • Lineage de dados → origem real
  • Observabilidade → runtime

💡 Resultado:

Você responde perguntas como:

  • “Se eu mudar isso, o que quebra?”
  • “Qual job depende disso?”
  • “Qual dataset alimenta isso?”
  • “Qual fluxo gera esse erro?”

🧭💣 PASSO A PASSO (CAMINHO CERTO)

🥇 Passo 1 — Mapear JCL

  • jobs
  • steps
  • datasets

🥈 Passo 2 — Mapear programas COBOL

  • entradas
  • saídas
  • chamadas

🥉 Passo 3 — Mapear CICS

  • transações
  • programas
  • routing

🏅 Passo 4 — Construir grafo

  • dependência real
  • fluxo completo

🎯 Passo 5 — Só então usar IA

  • enriquecimento
  • análise
  • explicação

🧠📚 BASE TEÓRICA (SEM ISSO VOCÊ SOFRE)

Você precisa dominar:

  • Execução batch
  • Dependência temporal
  • Data lineage
  • Sistemas distribuídos (pré-cloud!)
  • Arquitetura orientada a eventos (sim, mainframe já fazia isso)

💣🔥 FRASES QUE VOCÊ NUNCA MAIS ESQUECE

💥 “COBOL não é o sistema. É só a interface da lógica.”

💥 “JCL é o diretor do filme — COBOL é o ator.”

💥 “Se você não entende o fluxo, você não entende o bug.”

💥 “IA sem contexto é só autocomplete caro.”


🚀💣 CONCLUSÃO (A VERDADE NUA)

A promessa de “jogar COBOL em vetor e entender tudo” é sedutora…

…mas perigosa.

Porque:

👉 Mainframe não é texto
👉 Mainframe é execução
👉 Execução tem tempo, estado e dependência

E isso NÃO cabe em embedding.


🧠🔥 MISSÃO PARA OS PADAWANS

Se você quer dominar isso de verdade:

  1. Leia JCL como se fosse código
  2. Siga o caminho do dado
  3. Pense em fluxo, não em linha
  4. Questione qualquer IA
  5. Nunca confie em resposta sem contexto

💣🔥 FINAL ESTILO RAIZ

Se sua IA não entende JCL…
ela não entende seu sistema.

E se ela não entende seu sistema…
ela não deveria chegar perto da produção.


.


🧠💡 O QUE É RAG?

RAG significa:

Retrieval-Augmented Generation
(Geração aumentada por recuperação)

👉 Em português simples:

💬 Uma IA que responde usando informações buscadas em uma base de dados.


🔧 COMO FUNCIONA (VISÃO PRÁTICA)

O RAG segue esse fluxo:

1. 📚 Você fornece conteúdo

  • código
  • documentos
  • PDFs
  • base de conhecimento

2. 🧩 O sistema “quebra” tudo

Exemplo:

Programa COBOL → dividido em pedaços menores

3. 🔢 Vetorização

Cada pedaço vira um vetor (embedding):

👉 uma representação matemática do texto


4. 🔍 Busca por similaridade

Quando você pergunta algo:

“Como funciona validação de conta?”

O sistema:

  • transforma sua pergunta em vetor
  • procura pedaços “parecidos”

5. 🤖 Geração da resposta

O modelo usa:

  • sua pergunta
    • os trechos encontrados

👉 para montar a resposta


💣 RESUMO EM UMA LINHA

RAG = IA + busca inteligente em conteúdo relevante


🔥 EXEMPLO SIMPLES

Você pergunta:

“Onde o cliente é validado?”

O RAG:

  • acha um trecho COBOL com IF CLIENTE-OK
  • retorna explicação baseada nisso

👉 Parece mágico… mas aqui começa o perigo.


⚠️💣 O PROBLEMA (PRINCIPAL)

RAG funciona baseado em:

🔎 similaridade de TEXTO

E NÃO em:

  • fluxo real
  • execução
  • dependência
  • contexto externo

🧠💥 ANALOGIA (FACILITA MUITO)

Imagine:

👉 Você lê páginas soltas de um livro
👉 e tenta entender a história inteira

💣 Isso é RAG.


🏦 NO MUNDO MODERNO

Funciona bem em:

  • documentação
  • APIs
  • microserviços
  • código recente

Porque:
👉 tudo está no próprio código


💀 NO MAINFRAME

Aqui ele sofre:

  • JCL controla execução
  • CICS controla fluxo
  • datasets vêm de outros jobs
  • lógica está espalhada

👉 O código sozinho NÃO conta a história


🔥 EXEMPLO REAL (DOR DE PRODUÇÃO)

Pergunta:

“O que acontece quando falha a validação?”

🤖 RAG responde:

  • lógica IF no COBOL

😈 Realidade:

  • erro interceptado no CICS
  • redirecionado
  • gravado no Db2
  • tratado em batch depois

💣 O RAG erra porque não vê o sistema inteiro


🧠💡 QUANDO USAR RAG

✅ Bom uso:

  • documentação técnica
  • FAQ
  • busca em código isolado
  • suporte a desenvolvedor

❌ Péssimo uso:

  • análise de sistemas complexos
  • dependência batch
  • impacto de mudança
  • fluxo mainframe

⚙️ RESUMO TÉCNICO (NÍVEL MAIS PROFUNDO)

RAG combina:

  • LLM (modelo de linguagem)
  • Vector Database
  • Busca semântica

👉 Ele NÃO entende execução
👉 Ele NÃO entende tempo
👉 Ele NÃO entende dependência real


💣🔥 FRASE PRA GUARDAR

RAG entende o que está escrito
mas não entende o que acontece


🚀 FECHAMENTO

RAG é poderoso — mas:

👉 é ferramenta de leitura
👉 não é ferramenta de entendimento sistêmico



segunda-feira, 2 de março de 2026

☕ “CALL ‘SABEDORIA’ USING PADAWAN” — O Guia Definitivo de Subprogramação COBOL Que Separa Aprendizes de Mestres do Mainframe

 

Bellacosa Mainframe exemplifica call no Cobol

☕ “CALL ‘SABEDORIA’ USING PADAWAN” — O Guia Definitivo de Subprogramação COBOL Que Separa Aprendizes de Mestres do Mainframe

Se você acha que subprogramação em COBOL é só “CALL e pronto”… prepare-se.
Você está prestes a atravessar a porta que leva do programador de exercícios para o engenheiro de sistemas que mantém bancos funcionando 💎

Neste artigo, vou falar com você — jovem Padawan do mainframe — no melhor estilo Bellacosa: direto, prático, cheio de contexto real, curiosidades históricas e aquelas “armadilhas invisíveis” que só aparecem em produção às 3h da manhã.

Pegue seu café ☕. Vamos lá.


🧠 Por que subprogramação é o coração do COBOL?

Grandes sistemas COBOL NÃO são programas gigantes.

Eles são:

👉 Redes de módulos especializados
👉 Bibliotecas corporativas compartilhadas
👉 Camadas de negócio reutilizáveis
👉 Serviços internos antes da palavra “microservice” existir

Um sistema bancário típico executa milhares de subprogramas por segundo.


🧩 O que é um Subprograma, afinal?

Um subprograma é um programa COBOL independente que:

✔ Pode ser chamado por outro
✔ Executa uma tarefa específica
✔ Recebe dados
✔ Retorna resultados
✔ Continua existindo sozinho

Em termos modernos:

É como uma função gigante com superpoderes de desempenho.


📞 O ritual sagrado: CALL

Programa principal (Caller)

CALL "CALCJURO" USING WS-VALOR WS-RESULT

Subprograma (Callee)

LINKAGE SECTION.
01 VALOR PIC 9(7)V99.
01 RESULT PIC 9(7)V99.

PROCEDURE DIVISION USING VALOR RESULT.
COMPUTE RESULT = VALOR * 1.05
GOBACK.

💥 Pronto. Comunicação entre programas.


🔗 Easter Egg #1 — COBOL já fazia “APIs internas” nos anos 70

Antes de REST, SOAP, gRPC…

Mainframes já tinham bibliotecas de serviços corporativos reutilizáveis.


📦 O segredo oculto: LINKAGE SECTION

Padawan, grave isto na pedra:

Sem LINKAGE SECTION, não há parâmetros.

Ela define a interface do subprograma — o “contrato”.


🔄 Como os dados são passados?

🔹 BY REFERENCE (padrão)

👉 Mesma área de memória
👉 Alterações retornam

CALL "PGM" USING WS-DATA

💎 Rápido, eficiente, poderoso… e perigoso.


🔹 BY CONTENT

👉 Cópia do valor
👉 Caller não vê mudanças

CALL "PGM" USING BY CONTENT WS-DATA

🔹 BY VALUE

👉 Valor literal — comum com C/Java


⚠️ Easter Egg #2 — A causa invisível de bugs fantasma

90% dos “dados misteriosamente alterados” em sistemas antigos são BY REFERENCE mal usado.


🧭 Quem é o Main Program?

Plot twist:

👉 O código não define.
👉 O ambiente define.

No batch:

➡ O programa do EXEC no JCL é o principal.

Em CICS:

➡ O ambiente decide.

O mesmo módulo pode ser:

✔ Main hoje
✔ Subprograma amanhã
✔ Serviço compartilhado depois


🧩 Embedded vs External — A Guerra dos Módulos

🧱 Embedded (Contained)

✔ Dentro do mesmo source
✔ Compilado junto
✔ Uso local

MAIN
└─ SUB-A (no mesmo arquivo)

🌐 External

✔ Fonte separado
✔ Compilado independente
✔ Reutilizável

👉 Padrão dominante nas empresas.


🏦 Curiosidade real

Alguns subprogramas bancários:

💰 Executam bilhões de vezes
📅 Estão em produção há décadas
🧠 São mais antigos que muitos programadores


🛑 Como terminar um programa corretamente?

Padawan, memorize isso:

ComandoSubprogramaMain Program
GOBACKRetornaEncerra
EXIT PROGRAMRetorna❌ Não usar
STOP RUN💀 Mata tudoEncerra

⚠️ Easter Egg #3 — O botão nuclear

Um STOP RUN dentro de um subprograma compartilhado pode derrubar:

💥 Transações online
💥 Jobs batch inteiros
💥 Sistemas críticos

Sim, já aconteceu.


📡 Comunicação entre Programas — Três níveis de poder

🟦 Local

Só dentro do programa.

👉 Padrão.


🌍 Global

Programa + subprogramas embutidos.


🌐 External

Todos os programas da run unit.

👉 Use com extremo cuidado.


⚠️ Regra de Ouro Corporativa

Prefira parâmetros explícitos a variáveis globais.

Isso é engenharia profissional.


📥 RETURNING — O modo “função moderna”

Alguns compiladores permitem retorno explícito:

CALL "SUB"
USING IN-DATA
RETURNING OUT-DATA

Subprograma:

PROCEDURE DIVISION USING IN-DATA
RETURNING OUT-DATA.

💎 Menos comum, mas elegante.


🏦 Padrão real de mercado

Quase sempre:

CALL "SERVICO"
USING REQUEST-BLOCK
RESPONSE-BLOCK

Porque sistemas grandes preferem estruturas completas.


🧪 Passo a passo para criar um subprograma robusto

1️⃣ Defina interface clara (LINKAGE)

2️⃣ Use estruturas, não campos soltos

3️⃣ Documente a ordem dos parâmetros

4️⃣ Use GOBACK

5️⃣ Evite GLOBAL/EXTERNAL sem necessidade

6️⃣ Teste isoladamente


💎 Easter Egg Final — O verdadeiro poder do COBOL

Subprogramação é a razão pela qual:

🏦 Bancos não param
✈️ Sistemas de reserva funcionam
📊 Processamento massivo é possível
🕰️ Código sobrevive por décadas


☕ Mensagem do Mestre para o Padawan

Se você dominar subprogramação COBOL, você deixa de ser apenas um programador.

Você se torna:

🏛️ Um arquiteto de sistemas críticos

Porque o mainframe não é sobre código pequeno.

É sobre:

👉 Confiabilidade
👉 Desempenho
👉 Longevidade
👉 Engenharia disciplinada

sábado, 31 de agosto de 2024

Padawans Aprendam COBOL

Bellacosa Mainframe e o misterio do codigo que nunca morre


☕ Um Café no Bellacosa Mainframe

O Mistério do Código que Nunca Morreu

Por que um Programador Iniciante Deve Aprender COBOL?

Revista Bellacosa Mainframe — Edição Especial — Inspirada nas Grandes Revistas de Mistério dos Anos 1950


Prólogo: O Caso do Cadáver que Continuava Trabalhando

Londres.

Nova York.

São Paulo.

Tóquio.

Frankfurt.

Em todos esses lugares existe um crime aparentemente impossível.

Há décadas, especialistas anunciam que COBOL morreu.

Mesmo assim...

milhões de pagamentos são realizados.

Bilhões de dólares são movimentados.

Cartões de crédito continuam autorizando compras.

Aposentadorias continuam sendo pagas.

Voos continuam sendo vendidos.

Seguros continuam sendo emitidos.

Então surge a pergunta que todo detetive faz diante de um cadáver que insiste em respirar:

Quem está realmente morto? O COBOL... ou as previsões?

Pegue sua lupa.

Acenda o cachimbo.

A investigação começa agora.


Caso nº 1 — O Cofre dos Bilhões

Nos anos 1950, toda revista policial possuía um banco misterioso.

No nosso caso, o banco existe de verdade.

Imagine que você entra em uma instituição financeira.

Você vê:

  • aplicativo moderno

  • internet banking

  • biometria

  • reconhecimento facial

  • IA

  • chatbot

Tudo parece extremamente moderno.

Mas quando você aperta o botão Transferir...

...a ordem viaja por dezenas de sistemas...

...até encontrar um programa COBOL criado anos ou até décadas atrás.

Esse programa decide:

  • existe saldo?

  • há limite?

  • qual tarifa cobrar?

  • qual imposto aplicar?

  • qual conta debitar?

É ali que mora o dinheiro.

Não na interface.

Não no aplicativo.

Mas na lógica construída ao longo de muitos anos.

O iniciante normalmente imagina que aprender COBOL significa estudar tecnologia antiga.

Na realidade, significa compreender como funciona o coração financeiro do planeta.


Caso nº 2 — O Código que Já Sobreviveu a Cinco Gerações

Imagine um investigador encontrando um relógio.

O fabricante fechou.

Os donos morreram.

As ferramentas desapareceram.

Mesmo assim...

o relógio continua funcionando perfeitamente.

Esse é o COBOL.

Ele atravessou:

  • cartões perfurados

  • fitas magnéticas

  • discos DASD

  • terminais 3270

  • PCs

  • Internet

  • Cloud

  • IA Generativa

Pouquíssimas linguagens podem contar essa história.

Java?

Ainda é jovem.

Python?

Mais jovem ainda.

Rust?

Recém-nascido.

COBOL já viu praticamente todas as revoluções da informática.

Quem aprende COBOL também aprende a evolução da computação corporativa.


Caso nº 3 — A Linguagem que Foi Feita para Ser Lida

Todo detetive precisa ler relatórios.

COBOL foi criado exatamente com essa filosofia.

Compare.

Linguagens tradicionais:

x=x+y*z

COBOL:

COMPUTE TOTAL = VALOR + IMPOSTO * TAXA

Ou ainda:

IF CLIENTE-INADIMPLENTE

    PERFORM BLOQUEAR-CONTA

END-IF

Mesmo alguém que nunca programou consegue entender a intenção.

Isso reduz erros.

E reduz erros porque COBOL foi desenvolvido para negócios, não para matemáticos.


Caso nº 4 — O Enigma da Estabilidade

Imagine um elevador.

Você entra nele todos os dias.

Durante quarenta anos.

Ele nunca para.

Nunca cai.

Nunca apresenta defeito.

É exatamente isso que empresas esperam de seus sistemas.

Enquanto muitos softwares modernos são atualizados diariamente...

...um programa COBOL pode executar milhões de vezes exatamente da mesma forma.

Essa previsibilidade vale ouro.

Empresas preferem estabilidade do que novidades.


Caso nº 5 — A Biblioteca Perdida

Todo investigador sabe:

o verdadeiro tesouro nunca é o ouro.

É a informação.

Dentro das empresas existem milhões de linhas COBOL.

Ali está registrado:

  • regras fiscais

  • legislação

  • cálculos bancários

  • contratos

  • seguros

  • previdência

  • financiamentos

Em muitos casos...

ninguém mais sabe exatamente por que determinada regra existe.

O programa virou documentação viva.

Aprender COBOL é aprender a interpretar esse patrimônio.

É quase uma arqueologia tecnológica.


Caso nº 6 — A Falsa Cena do Crime

Durante anos ouvimos:

"COBOL acabou."

Mas os fatos contam outra história.

O mercado continua procurando profissionais porque:

  • sistemas continuam crescendo;

  • novas integrações surgem diariamente;

  • APIs REST conversam com programas COBOL;

  • IA ajuda a compreender código legado;

  • DevOps chegou ao IBM Z;

  • Git chegou ao Mainframe;

  • VS Code conversa com z/OS.

Ou seja...

o ambiente mudou completamente.

Hoje o desenvolvedor utiliza:

  • Git

  • Jenkins

  • VS Code

  • Zowe

  • OpenShift

  • APIs REST

  • IA

Tudo isso ao lado do COBOL.

O "legado" tornou-se parte do ecossistema moderno.


Caso nº 7 — O Salário Invisível

Existe um detalhe curioso.

Todo mundo aprende linguagens populares.

Poucos aprendem COBOL.

Resultado?

Oferta menor de profissionais.

Demanda constante.

Não existe fórmula mágica para salários elevados.

Mas especialização sempre aumenta o valor profissional.

Enquanto milhares disputam vagas em tecnologias da moda...

o especialista em Mainframe frequentemente encontra menos concorrência.


Caso nº 8 — A Universidade da Engenharia de Software

COBOL ensina disciplina.

Antes de escrever código você aprende:

  • análise

  • documentação

  • regras de negócio

  • organização

  • modularização

  • nomenclatura

  • testes

  • tratamento de erros

Essa formação faz diferença.

Quem domina COBOL costuma entender melhor sistemas corporativos enormes.

Depois aprender Java, Python ou C# torna-se muito mais simples.


Caso nº 9 — O Detetive e a Inteligência Artificial

Aqui está uma das maiores reviravoltas da investigação.

Durante muito tempo diziam:

"A IA vai substituir COBOL."

O que realmente aconteceu?

A IA passou a ajudar programadores COBOL.

Hoje ela consegue:

✔ explicar programas antigos;

✔ localizar bugs;

✔ gerar documentação;

✔ sugerir melhorias;

✔ converter estruturas;

✔ explicar COPYBOOKs;

✔ resumir regras de negócio.

O investigador ganhou um parceiro.

Não perdeu o emprego.


Caso nº 10 — O Verdadeiro Segredo

Depois de investigar centenas de pistas...

chegamos à maior descoberta.

O COBOL nunca foi apenas uma linguagem.

Ele é uma enorme biblioteca de conhecimento empresarial.

Quando um iniciante aprende COBOL, ele não aprende apenas comandos como:

MOVE

READ

WRITE

IF

PERFORM

Ele aprende:

como bancos funcionam.

Como seguros calculam riscos.

Como cartões autorizam compras.

Como governos pagam benefícios.

Como empresas controlam bilhões de registros.

Aprender COBOL é estudar processos de negócio em escala mundial.


Dossiê Bellacosa — Dez Motivos Para Aprender COBOL

🕵️ Resolve problemas reais.

🕵️ Está presente nas maiores empresas do mundo.

🕵️ Ensina lógica extremamente organizada.

🕵️ Desenvolve disciplina de engenharia de software.

🕵️ Trabalha junto com IA, APIs e Cloud.

🕵️ Abre portas para IBM Z e Mainframe.

🕵️ Dá acesso a sistemas críticos.

🕵️ Permite compreender décadas de evolução tecnológica.

🕵️ Continua sendo procurado pelo mercado.

🕵️ Forma profissionais capazes de entender tecnologia e negócios ao mesmo tempo.


Arquivo Confidencial

Ao final desta investigação, resta apenas uma pergunta.

Por que tantas pessoas acreditam que COBOL morreu?

Talvez porque nunca tenham entrado na sala onde o verdadeiro trabalho acontece.

Longe das luzes da interface gráfica, atrás de paredes de concreto dos grandes CPDs, existem computadores IBM Z processando milhões de transações por segundo. Em cada transação há uma decisão tomada por regras escritas em COBOL, muitas delas executadas continuamente há décadas, com precisão admirável.

O mistério, portanto, nunca foi "por que aprender COBOL?"

O verdadeiro mistério é outro:

Como uma linguagem criada em 1959 continua tão relevante em 2026, atravessando gerações, sobrevivendo a modismos tecnológicos e trabalhando silenciosamente onde o mundo não pode parar?

Talvez seja justamente isso que transforma o COBOL no maior "caso não resolvido" da história da computação — um código que muitos declararam morto, mas que continua vivo, invisível e indispensável, resolvendo milhões de problemas enquanto todos olham para outra direção. E, para o iniciante que decide seguir essas pistas, aprender COBOL pode ser menos uma viagem ao passado e mais a descoberta dos alicerces que ainda sustentam uma parte significativa da economia digital.


Aproveite, comente, compartilhe, convide e marque aquele padawan que programa em Python e não

 conhece COBOL

terça-feira, 27 de agosto de 2024

☕ O Holocron do Projeto Altamira: Quando as Caixas Espanholas Migraram do Unisys para IBM Z Sem IA, Sem Assessment Infinito e Sem Arqueologia COBOL

 

Bellacosa Mainframe relembra o projeto Altamira no mundo mainframe

☕ O Holocron do Projeto Altamira: Quando as Caixas Espanholas Migraram do Unisys para IBM Z Sem IA, Sem Assessment Infinito e Sem Arqueologia COBOL



O que era o Altamira?

Altamira era um Core Banking System.

Em termos simples:

Um grande conjunto integrado de aplicações capaz de suportar praticamente toda a operação bancária.

Incluindo:

  • Contas correntes

  • Poupança

  • Empréstimos

  • Hipotecas

  • Transferências

  • Compensação bancária

  • Cartões

  • Tesouraria

  • Clientes

  • Agências

  • Contabilidade

  • Batch noturno

  • Produtos financeiros

Podemos compará-lo a soluções atuais como:

  • Temenos Transact

  • Finacle

  • Mambu

  • TCS BaNCS

  • Hogan

  • SAP Banking

Mas com uma característica importante:

Era concebido para rodar nativamente em Mainframe IBM.


O contexto tecnológico espanhol dos anos 90

Na década de 90 existia uma grande diversidade tecnológica.

Unisys

Muitas Caixas utilizavam sistemas Unisys.

Equipamentos A-Series.

MCP.

COBOL Unisys.

DMSII.

IBM

Outras utilizavam:

IBM 9672

S/390

DB2

CICS

COBOL IBM

Bull

GCOS

NCR

Sistemas proprietários

Era comum cada instituição possuir décadas de customizações.


O desafio de uma Caixa de Poupança

Uma Caixa típica possuía:

Pessoas

Cadastro de clientes

KYC

Relacionamentos


Empréstimos

Hipotecários

Pessoais

Consignados

Leasing


Passivo

Contas

Depósitos

Fundos


Meios de pagamento

Transferências

SEPA

SICA

SWIFT


Contabilidade

Plano contábil

Fechamentos

Provisões


O que significava migrar para Altamira?

Basicamente:

Substituir tudo.

Sistema antigo

Altamira IBM

Mas sem alterar o comportamento do banco.

O cliente não podia perceber.

A agência não podia parar.

Os extratos deveriam continuar corretos.

As prestações deveriam continuar corretas.


A filosofia adotada

Aqui está talvez o aspecto mais interessante.

Não se estudava milhões de linhas COBOL.

Perguntava-se:

O que este produto faz?

Exemplo.

Hipoteca.

Capital:

100.000 euros

Prazo:

20 anos

Taxa:

4%

Sistema francês.

Prestação:

530 euros

(Exemplo simplificado)

O sistema antigo produz:

530

Altamira produz:

530

Está correto.

Próximo item.


Gap Analysis

Ferramenta essencial.

Situação atual

Sistema Unisys

Campo X

Formato 12 bytes


Altamira

Campo X

15 bytes


Decisão:

Adaptar

Expandir

Converter


Exemplo.

Produto antigo

Código 031

Altamira

HIP001

Tabela de conversão.


Pessoas valiam mais que documentação

Algo extremamente comum nos anos 90.

Pergunta:

Como funciona SICA?

Resposta:

Pergunta para o Juan.

Juan trabalhou 15 anos nisso.

Fim do problema.


Hoje muitas empresas perderam esse conhecimento.

Juan aposentou-se.

Pedro foi para fintech.

Maria mudou de área.

Sobra:

500 milhões de linhas COBOL.


Batch era o verdadeiro monstro

O texto menciona algo importante.

Batch.

Batch bancário é frequentemente mais complexo que online.

Exemplo.

22h00

Fechamento

23h00

Juros

00h00

Hipotecas

01h00

Transferências

02h00

Contabilidade

03h00

Backup

04h00

Extratos

05h00

Abertura


Migrar Batch significava:

Reescrever JCL

Reorganizar dependências

Alterar calendários

Ajustar tempos


Transferências e SICA

SICA é um dos componentes menos conhecidos fora da Espanha.

Relaciona-se historicamente com compensação interbancária.

Transferências nacionais.

Liquidação.

Validação.

Regras regulatórias.


Aprender isso dentro do projeto era comum.

Ninguém chegava especialista.

Aprendia.

Fazia.

Testava.

Implantava.


Por que hoje demora tanto?

1) Regulação

Basileia.

DORA.

GDPR.

Auditoria.

SOX.

PCI.

PSD2.


2) Ecossistema

Mobile.

Internet Banking.

PIX equivalente.

Open Banking.

APIs.

Kafka.

IA.


3) Consultorias industrializaram processos

Assessment.

Discovery.

Knowledge Mining.

Digital Twins.

Dependency Graphs.


4) Falta de especialistas bancários

Hoje há muitos especialistas em tecnologia.

Poucos especialistas em negócio bancário.

E isso muda tudo.


O que a IA realmente pode ajudar?

A IA atual ajuda muito.

Ela consegue:

Explicar COBOL.

Documentar COPYBOOK.

Mapear DB2.

Gerar fluxogramas.

Encontrar dependências.

Explicar JCL.

Comparar layouts.

Mas ainda possui dificuldade em responder:

Por que este produto foi criado em 1987?

Qual acordo comercial originou esta exceção?

Por que uma determinada Caixa cobrava a prestação em data aniversário?

Essas respostas normalmente estão em outro lugar.

Na memória das pessoas.

Nas atas esquecidas.

Nas normas internas.

Nos analistas veteranos.

Nos gerentes aposentados.


Considerações Finais

O relato sobre o Projeto Altamira desmonta uma narrativa bastante difundida atualmente: a de que não é possível modernizar um Core Banking sem primeiro compreender perfeitamente cada linha do sistema legado.

A experiência dos anos 90 mostra outra abordagem:

Não migrávamos programas.

Migrávamos regras de negócio.

Migrávamos produtos financeiros.

Migrávamos a capacidade operacional do banco.

O código COBOL, o CICS, o DB2, o Unisys ou o IBM eram apenas os veículos tecnológicos.

O verdadeiro ativo sempre foi o conhecimento bancário.

Talvez a maior lição deixada por projetos como Altamira seja justamente esta:

Um banco não é um conjunto de milhões de linhas COBOL.

Um banco é um conjunto de decisões de negócio acumuladas durante décadas, e o sucesso de qualquer transformação depende muito mais de compreender essas decisões do que de realizar arqueologia em código-fonte.

E, curiosamente, essa continua sendo uma das maiores limitações da IA generativa em 2026: ela pode ler o código legado em segundos, mas ainda precisa de um veterano do negócio para explicar por que aquela regra aparentemente absurda continua existindo após trinta anos de produção.


segunda-feira, 7 de dezembro de 2020

Os Rankings das Linguagens : Quando um Programador Descobre que o GitHub Não Enxerga o Mainframe... e Percebe que a Economia Mundial Funciona Graças ao Lado Invisível da Computação

Bellacosa Mainframe e os rankings das linguagens de programaçao mito ou realidade


☕ Um Café no Bellacosa Mainframe

Os Rankings das Linguagens sem Mistérios para Programadores COBOL

Quando um Programador Descobre que o GitHub Não Enxerga o Mainframe... e Percebe que a Economia Mundial Funciona Graças ao Lado Invisível da Computação

"Gentlemen, you can't fight in here! This is the War Room!"
— Dr. Strangelove (1964)

Imagine a cena.

Você acaba de entrar na famosa Sala de Guerra do Pentágono.

No centro da mesa existe um enorme painel luminoso mostrando o ranking mundial das linguagens de programação.

Python em primeiro.

C em segundo.

C++ em terceiro.

Java logo atrás.

JavaScript subindo.

Rust fazendo propaganda de si mesmo.

Enquanto isso...

Lá no canto inferior da tela...

COBOL aparece discretamente na posição 19.

Os jovens desenvolvedores olham para a tela e concluem:

"Pronto. Está morto."

Nesse momento, um general entra correndo na sala.

— Senhor!

— Sim?

— O sistema que processa a folha salarial das Forças Armadas parou.

— Em que linguagem ele foi escrito?

Silêncio.

Outro oficial responde:

— COBOL.

Cinco segundos depois...

Todos na sala percebem que talvez aquele ranking não estivesse contando exatamente toda a história.

E é exatamente sobre isso que vamos conversar hoje.

Prepare seu café.

Hoje vamos descobrir por que popularidade não é sinônimo de importância, por que o COBOL pode ser considerado uma espécie de Matéria Escura da Computação, e por que muitos rankings enxergam apenas a superfície do iceberg tecnológico.


Capítulo 1 — O Grande Mapa-Múndi das Linguagens

Todo ano surgem dezenas de rankings.

TIOBE.

RedMonk.

GitHub Octoverse.

Stack Overflow.

PYPL.

IEEE Spectrum.

Todos prometem responder à pergunta:

"Qual é a linguagem mais importante do mundo?"

Parece simples.

Mas existe um pequeno problema.

Nenhum deles mede exatamente a mesma coisa.

É como perguntar:

Qual é o melhor veículo?

E misturar numa mesma pesquisa:

  • quantidade de bicicletas vendidas;

  • número de aviões em operação;

  • caminhões registrados;

  • navios cargueiros;

  • foguetes lançados.

Todos são veículos.

Mas cumprem funções completamente diferentes.


Capítulo 2 — O Python é realmente o Rei?

Sim.

Mas depende da pergunta.

Python domina praticamente todos os indicadores modernos.

Por quê?

Porque está presente em:

  • Inteligência Artificial;

  • Machine Learning;

  • Ciência de Dados;

  • Automação;

  • DevOps;

  • Cloud Computing;

  • Segurança;

  • Ensino universitário.

Se milhões de estudantes aprendem Python todos os anos...

Os rankings naturalmente irão refletir isso.

Isso não é manipulação.

É estatística.


Capítulo 3 — O Primeiro Grande Erro

A maioria das pessoas interpreta rankings assim:

Popularidade = Importância

Só que isso é falso.

Vamos imaginar dois programas.

Programa A

Um aplicativo que troca a cor de um botão.

Escrito em JavaScript.

Possui:

  • 120.000 estrelas no GitHub

  • milhares de forks

  • vídeos no YouTube

  • milhares de perguntas no Stack Overflow


Programa B

Sistema nacional de aposentadorias.

Escrito em COBOL.

Possui:

  • zero estrelas;

  • zero forks;

  • zero vídeos;

  • zero repositórios públicos.

Mas movimenta bilhões todos os meses.

Qual deles é mais importante?

A resposta é óbvia.


Capítulo 4 — A Grande Pegadinha Estatística

Vamos analisar cada ranking.

GitHub Octoverse

Mede:

  • commits

  • pull requests

  • forks

  • repositórios públicos

Percebe o problema?

Quase nenhum banco publica seu Core Banking no GitHub.

Imagine o Itaú.

Imagine o Banco do Brasil.

Imagine o Bradesco.

Imagine a Caixa.

Imagine o Federal Reserve.

Imagine o Banco Central Europeu.

Agora imagine todos colocando seus programas COBOL em um repositório público.

Seria uma péssima ideia.


Capítulo 5 — Stack Overflow

Outro caso curioso.

Ele mede perguntas.

Mas pense no seguinte.

Quem pergunta mais?

Um iniciante.

Ou um profissional com trinta anos de experiência?

Normalmente o iniciante.

Logo...

Linguagens maduras geram menos perguntas.

COBOL sofre exatamente desse efeito.


Capítulo 6 — PYPL

Esse ranking mede buscas por tutoriais.

Quanto mais pessoas digitam:

How to learn Python

mais Python sobe.

Isso significa que Python seja mais importante economicamente?

Não.

Significa apenas que mais pessoas estão querendo aprender Python.


Capítulo 7 — O Caso TIOBE

Talvez seja o ranking mais famoso.

Também é um dos mais discutidos.

Ele mistura:

  • pesquisas;

  • livros;

  • documentação;

  • páginas na internet;

  • cursos.

Ou seja...

Ele mede interesse.

Não mede produção.


Capítulo 8 — IEEE Spectrum

Talvez seja o mais equilibrado.

Mistura:

  • mercado;

  • vagas;

  • pesquisas;

  • GitHub;

  • tendências.

Mesmo assim...

Continua dependendo de informações públicas.

E é aí que mora o problema.


Capítulo 9 — O Universo Invisível

Agora chegamos ao ponto principal.

Imagine um iceberg.

A parte visível representa:

  • GitHub;

  • Reddit;

  • Stack Overflow;

  • Hacker News;

  • LinkedIn;

  • Medium.

É um universo enorme.

Mas ainda é apenas a ponta.

A parte submersa contém:

  • bancos;

  • seguradoras;

  • bolsas de valores;

  • previdência;

  • governo;

  • defesa;

  • companhias aéreas;

  • telecomunicações;

  • energia.

É aqui que vivem linguagens como:

  • COBOL;

  • PL/I;

  • Natural;

  • RPG;

  • Assembly;

  • MUMPS.

Esse mundo raramente aparece nos rankings.


Easter Egg nº 1

No filme Dr. Strangelove, o mundo quase acaba porque diferentes pessoas possuem apenas uma parte da informação.

Na computação acontece algo semelhante.

O desenvolvedor Front-End conhece React.

O arquiteto conhece Java.

O DBA conhece Db2.

O Sysprog conhece z/OS.

O operador conhece JES2.

Mas pouquíssimas pessoas enxergam o sistema inteiro.


Capítulo 10 — O Conceito de Deep Language

Não existe uma definição acadêmica oficial para "Deep Language", mas a expressão ajuda a visualizar um fenômeno real.

Podemos pensar em linguagens "profundas" como aquelas que:

  • sustentam sistemas críticos;

  • vivem em ambientes fechados;

  • são pouco visíveis ao público;

  • possuem décadas de evolução;

  • armazenam regras de negócio acumuladas ao longo do tempo.

São linguagens que operam nas camadas mais profundas da infraestrutura digital.


Capítulo 11 — O Cofre Invisível

Imagine um enorme cofre.

Dentro dele existem:

  • cinquenta milhões de linhas COBOL;

  • vinte milhões PL/I;

  • milhares de programas Assembly;

  • regras bancárias acumuladas durante cinquenta anos.

Nenhum mecanismo de busca consegue enxergar isso.

Nenhum ranking consegue contar essas linhas.

É literalmente um universo invisível.


Curiosidade Bellacosa

Muitos sistemas corporativos nem sequer usam Git.

Você encontrará ferramentas como:

  • Endevor;

  • ISPW;

  • ChangeMan;

  • Panvalet;

  • Librarian.

Ou seja...

Mesmo que você fosse contar commits...

Eles simplesmente não existem no GitHub.


Capítulo 12 — O Peso Econômico

Uma linha COBOL vale o mesmo que uma linha JavaScript?

Claro que não.

Imagine:

if (button == red)

Agora compare com:

CALCULAR-JUROS-COMPOSTOS
VALIDAR-LIMITE-CREDITO
PROCESSAR-PAGAMENTO
AUTORIZAR-PIX

As consequências de um erro são completamente diferentes.


Easter Egg nº 2

No universo de Dr. Strangelove existe a famosa "Máquina do Juízo Final".

No mundo financeiro também existe uma espécie de máquina invisível.

Ela não lança bombas.

Ela lança:

  • salários;

  • aposentadorias;

  • dividendos;

  • seguros;

  • financiamentos.

E boa parte dessa máquina ainda conversa fluentemente em COBOL.


Capítulo 13 — O Iceberg Tecnológico

Visualize:

              PYTHON
            JAVASCRIPT
               JAVA
             TYPESCRIPT
             GO
             RUST
------------------------------
          COBOL
          PL/I
         NATURAL
            RPG
        ASSEMBLY

A parte superior muda rapidamente.

A inferior muda lentamente.

E justamente por isso continua funcionando há décadas.


Capítulo 14 — O Paradoxo da Invisibilidade

Existe um fenômeno curioso.

Quanto mais crítico um sistema...

Menos as pessoas falam dele.

Você nunca vê manchetes dizendo:

"Sistema bancário processou corretamente mais 40 bilhões de transações hoje."

Porque isso é o esperado.

As notícias aparecem apenas quando algo falha.

O silêncio operacional é um dos maiores indicadores de sucesso em ambientes críticos.


Capítulo 15 — Como Interpretar um Ranking Corretamente

Sempre faça quatro perguntas:

1. O que está sendo medido?

Commits?

Pesquisas?

Cursos?

Perguntas?

Livros?


2. Quem ficou de fora?

Empresas privadas?

Governos?

Mainframes?

Sistemas militares?


3. O que não pode ser divulgado?

Arquiteturas bancárias.

Código-fonte.

Volumes de transações.

Regras internas.


4. Qual o objetivo?

Aprender?

Contratar?

Investir?

Escolher uma linguagem?

Ou entender a infraestrutura mundial?

Cada objetivo exige uma interpretação diferente.


Dicas para o Programador COBOL Iniciante

Se você está começando agora, não caia em dois extremos.

O primeiro é acreditar que "só existe COBOL". O segundo é imaginar que "COBOL morreu porque aparece em 19º lugar". A realidade é muito mais interessante.

Algumas recomendações práticas:

  1. Aprenda COBOL profundamente, entendendo arquivos VSAM, Db2, JCL e CICS. É isso que transforma um iniciante em alguém capaz de navegar em sistemas corporativos reais.

  2. Estude também linguagens modernas, como Python ou Java. Elas são excelentes para automação, testes, integração e APIs. Hoje, muitos projetos conectam aplicações modernas a sistemas COBOL por meio de REST, mensageria e microsserviços.

  3. Aprenda a interpretar métricas. Um gráfico bonito não substitui o entendimento de como ele foi construído.

  4. Entenda o negócio, não apenas a sintaxe. Em bancos, seguradoras e órgãos públicos, as regras de negócio costumam valer mais do que a escolha da linguagem.


Curiosidade Histórica

Nos anos 1960 e 1970, praticamente ninguém se preocupava com "rankings de linguagens". A preocupação era outra:

  • o programa compila?

  • processa corretamente?

  • entrega a folha de pagamento?

  • fecha o balanço do banco?

  • a fita magnética pode ser lida amanhã?

Décadas depois, muitos desses programas continuam executando suas funções com impressionante confiabilidade.


Conclusão — Aprendendo a Amar o Iceberg

No final de Dr. Strangelove, a obsessão por indicadores, estratégias e cálculos leva os personagens a perderem a visão do todo.

Com os rankings de linguagens pode acontecer algo parecido.

É fácil olhar para uma tabela e concluir que uma linguagem "venceu" e outra "morreu". Mas tabelas contam apenas a parte visível da história. Elas mostram onde há mais repositórios públicos, mais buscas, mais cursos e mais conversas.

O que elas não mostram é o universo silencioso que sustenta bancos, governos, seguradoras, bolsas de valores e grandes empresas.

O COBOL raramente aparece nas manchetes porque sua missão nunca foi ser popular. Sua missão foi — e continua sendo — manter sistemas críticos funcionando de forma previsível, dia após dia, ano após ano.

Talvez essa seja a maior lição para um futuro Mestre Jedi do Mainframe: não confunda visibilidade com relevância. As tecnologias mais importantes nem sempre são as que fazem mais barulho. Muitas vezes, são justamente aquelas que trabalham em silêncio, escondidas nas profundezas do iceberg digital, onde cada linha de código carrega décadas de conhecimento, bilhões de transações e a confiança de toda uma economia.

No fim das contas, os rankings nos dizem muito sobre o entusiasmo do mercado. Já os mainframes nos lembram de algo ainda mais valioso: quando o assunto é infraestrutura crítica, a verdadeira grandeza costuma estar escondida nas camadas que quase ninguém vê — mas das quais praticamente todo o mundo depende.

 

sábado, 8 de junho de 2019

O Mistério da Porta que Nunca se Abriu Novamente : Descobriu que uma Escolha entre LINK e XCTL Poderia Decidir o Destino de Milhões de Transações Bancárias

 

Bellacosa Mainframe e o misterio da porta que nunsa se abriu novamente

☕ Um Café no Bellacosa Mainframe

O Mistério da Porta que Nunca se Abriu Novamente

Quando um Jovem Programador COBOL Descobriu que uma Escolha entre LINK e XCTL Poderia Decidir o Destino de Milhões de Transações Bancárias

"Existem portas que foram feitas para serem atravessadas duas vezes. Outras... apenas uma."

Era assim que começava um antigo manual não oficial que circulava entre programadores de CICS na década de 1980. Diziam que o autor nunca assinou seu nome. Apenas deixava um pequeno desenho de uma xícara de café ao lado das páginas.

Os veteranos chamavam aquele manuscrito de O Livro das Portas.

Hoje vamos descobrir por quê.

Pegue seu café.

Apague as luzes do escritório.

O letreiro verde do terminal 3270 acaba de acender.

O caso vai começar.


Capítulo 1 — O prédio onde programas conversam

Quem vem do COBOL Batch imagina que um programa vive sozinho.

Ele começa.

Processa.

Termina.

No CICS isso não existe.

Um sistema bancário raramente possui um programa gigante.

Na verdade ele parece uma pequena cidade.

Existe o programa do Login.

O Menu Principal.

Consulta de Saldo.

PIX.

Transferência.

Extrato.

Cartão.

Empréstimos.

Investimentos.

Cada um conhece apenas seu trabalho.

É exatamente como uma delegacia de polícia.

O investigador não faz exame pericial.

O perito não conduz interrogatórios.

O escrivão não prende criminosos.

Cada especialista executa apenas sua função.

No CICS acontece exatamente isso.

Cada programa é especialista em um assunto.

A pergunta é:

Como eles conversam?

A resposta possui apenas quatro letras.

LINK.

Ou...

XCTL.

E é aqui que começa nosso mistério.


Capítulo 2 — O telefone vermelho da IBM

Imagine um antigo escritório bancário dos anos 1950.

Sobre uma mesa existe um telefone vermelho.

Quando o gerente precisa de alguma informação ele liga para outro departamento.

— Preciso do saldo da conta.

O funcionário responde.

— Um instante.

Alguns segundos depois.

— Aqui está.

O gerente continua seu trabalho.

Isso é LINK.

O programa chama outro programa.

Espera.

Recebe a resposta.

Continua exatamente de onde havia parado.

Observe o fluxo.

Programa LOGIN

↓

LINK

↓

Programa CONSULTA

↓

RETURN

↓

LOGIN continua

Nada de mágico aconteceu.

Apenas uma conversa organizada.


A verdadeira mágica

O que ninguém vê é que o CICS precisa guardar tudo.

Enquanto o programa chamado trabalha, o programa chamador fica "congelado".

O CICS preserva:

✔ Registradores

✔ Contexto

✔ Área de memória

✔ Ponto de retorno

✔ COMMAREA

É quase como colocar um marcador dentro de um livro.

Você fecha.

Empresta para alguém.

Quando devolvem...

Você abre exatamente na mesma página.

Essa é a essência do LINK.


Capítulo 3 — A porta sem maçaneta

Agora imagine outra situação.

Você entrega a chave da empresa ao próximo gerente.

Vai embora.

Nunca mais volta.

Esse é o XCTL.

Programa LOGIN

↓

XCTL

↓

MENU

↓

Fim

O LOGIN morreu.

Sua missão terminou.

Ele não existe mais dentro daquela execução.

É uma transferência definitiva.

Os antigos programadores diziam:

"LINK conversa.

XCTL abdica."

Essa frase aparecia escrita em algumas apostilas da IBM nos anos 80.


A analogia da corrida

Imagine uma prova de revezamento.

No LINK...

Você entrega o bastão.

Espera.

Recebe de volta.

Continua correndo.

No XCTL...

Você entrega.

Sai da pista.

Vai tomar café.

Nunca mais participa daquela corrida.


O erro que denuncia um iniciante

Todo entrevistador gosta desta pergunta.

Veja:

EXEC CICS XCTL
     PROGRAM('MENU')
END-EXEC.

DISPLAY "CHEGUEI AQUI".

Pergunta:

Esse DISPLAY será executado?

Resposta:

Jamais.

Nunca.

Nem hoje.

Nem amanhã.

Nem daqui vinte anos.

Depois do XCTL o programa desapareceu.

Essa pequena pegadinha já eliminou centenas de candidatos em entrevistas.


Capítulo 4 — O elevador do edifício CICS

Imagine um prédio com cinquenta andares.

Cada andar possui um programa.

LINK funciona como um elevador.

Você sobe.

Resolve um assunto.

Desce.

Continua trabalhando.

XCTL funciona como mudança definitiva de escritório.

Você pega suas caixas.

Entrega sua sala.

Muda para outro andar.

Nunca mais volta.

Essa imagem ajuda muitos iniciantes.


O segredo escondido dentro do CICS

Muitos acreditam que LINK simplesmente chama outro programa.

Não.

Existe muito trabalho invisível.

Quando executamos:

EXEC CICS LINK

o CICS precisa:

Localizar o programa.

Carregar caso não esteja residente.

Criar ambiente.

Salvar contexto.

Preparar COMMAREA.

Transferir controle.

Esperar RETURN.

Restaurar contexto.

Continuar execução.

Existe um pequeno custo.

Pequeno.

Mas existe.


Já o XCTL...

Observe.

LOGIN

↓

MENU

Pronto.

Não existe necessidade de preservar retorno.

Não existe restauração.

O fluxo ficou linear.

Por isso muitos livros dizem que XCTL possui menor overhead.

Mas cuidado.

Não escolha XCTL apenas porque "é mais rápido".

Escolha porque faz sentido arquiteturalmente.

Essa diferença é importante.


Capítulo 5 — O caso do caixa eletrônico

Vamos imaginar um ATM.

Cliente digita cartão.

Senha.

Programa LOGIN.

Após validar usuário.

O sistema faz

XCTL MENU

Por quê?

Porque ninguém deseja voltar para a tela de login.

O LOGIN cumpriu sua missão.

Agora imagine outra opção.

O cliente escolhe:

Consultar saldo.

O MENU faz:

LINK SALDO

Programa SALDO consulta DB2.

Retorna.

O MENU continua vivo.

Cliente escolhe:

Extrato.

Outro LINK.

Cliente escolhe:

PIX.

Mais um LINK.

Perceba.

O MENU é o maestro.

As funções são músicos.

Cada músico toca.

Depois devolve o palco.


Curiosidade histórica

Nos primeiros grandes bancos brasileiros era comum encontrar verdadeiras árvores de LINK.

Algo semelhante a:

MENU

↓

LINK

CLIENTE

↓

LINK

ENDERECO

↓

LINK

CEP

↓

RETURN

↓

RETURN

↓

RETURN

Era perfeitamente normal encontrar cinco ou seis níveis de chamadas.

Hoje isso ainda existe, mas arquiteturas modernas procuram evitar profundidades excessivas para facilitar manutenção e depuração.


Capítulo 6 — A COMMAREA: o envelope secreto

Imagine um envelope lacrado.

Dentro existem informações importantes.

Cliente.

Conta.

Saldo.

Tipo de operação.

Senha criptografada.

Tudo isso viaja pela COMMAREA.

Ela é o "correio interno" entre programas CICS.

Exemplo:

Programa A

↓

COMMAREA

↓

Programa B

Nada vai para disco.

Nada vai para banco.

Tudo permanece na memória durante a transação.

É extremamente rápido.


Easter Egg Bellacosa ☕

Os veteranos costumavam brincar:

"Se a COMMAREA fosse um carteiro, ela seria o único funcionário dos Correios que nunca perde uma encomenda... desde que você informe o LENGTH corretamente."

E aí está uma das maiores armadilhas dos iniciantes.


O LENGTH que derruba sistemas

Veja:

EXEC CICS LINK
    PROGRAM('CLIENTE')
    COMMAREA(WS-COMMAREA)
    LENGTH(LENGTH OF WS-COMMAREA)
END-EXEC.

Por que informar LENGTH?

Porque o CICS precisa saber exatamente quantos bytes transportar.

Se enviar menos...

Dados truncados.

Se enviar mais...

Lixo de memória.

Em alguns casos...

ABEND.

Simples assim.


Capítulo 7 — LINK parece CALL?

Essa dúvida aparece todos os meses.

Resposta curta:

Não.

CALL pertence ao COBOL.

LINK pertence ao CICS.

CALL apenas transfere execução.

LINK conversa com toda a infraestrutura CICS.

Ele conhece:

Recuperação.

Transação.

Segurança.

Recursos.

Comunicação.

Monitoramento.

É muito mais sofisticado.


Comparando os três irmãos

ComandoRetornaAmbiente
CALLSimCOBOL
LINKSimCICS
XCTLNãoCICS

Capítulo 8 — A arquitetura elegante

Um projeto bem desenhado normalmente parece isto:

LOGIN

↓

XCTL

↓

MENU

↓

LINK

SALDO

↓

RETURN

↓

MENU

↓

LINK

PIX

↓

RETURN

↓

MENU

↓

LINK

EXTRATO

↓

RETURN

Observe como tudo faz sentido.

LOGIN nunca retorna.

MENU permanece vivo.

As funcionalidades entram.

Executam.

Saem.

Essa organização facilita testes, manutenção e reutilização.


Dicas de ouro para iniciantes

✔ Regra número um

Se precisa voltar...

Use LINK.


✔ Regra número dois

Se acabou seu trabalho...

Use XCTL.


✔ Regra número três

Nunca coloque código após XCTL esperando execução.


✔ Regra número quatro

Sempre valide o tamanho da COMMAREA.


✔ Regra número cinco

Evite criar "espaguete de LINK", onde programas chamam programas que chamam outros programas sem um desenho arquitetural claro. Quanto mais profunda a cadeia, mais difícil será depurar um problema às três da manhã.


Curiosidade que pouca gente conhece

Em algumas instalações antigas da IBM existia uma recomendação informal:

"Se um programa não precisa voltar, não o obrigue a voltar."

Essa filosofia influenciou muitos padrões de desenvolvimento CICS e explica por que tantos fluxos de navegação utilizam XCTL entre telas principais e LINK apenas para serviços reutilizáveis.


O Mistério do Detetive Bellacosa

Imagine um investigador chamado Arthur Bellacosa.

Ele recebe um caso.

Vai até o Arquivo Central.

Precisa consultar documentos.

Ele diz ao arquivista:

— Procure a ficha do cliente 458923.

O arquivista vai até o depósito.

Volta.

Entrega os documentos.

Arthur continua investigando.

Isso foi um LINK.

Agora imagine outro cenário.

Arthur resolve entregar todo o caso ao Departamento de Crimes Financeiros.

Entrega as pastas.

Entrega as chaves.

Entrega seu distintivo temporário.

Vai embora.

Nunca mais participa da investigação.

Isso foi um XCTL.

O caso continua.

Mas sem ele.


Perguntas clássicas de entrevista

Qual retorna ao programa chamador?

LINK.


Qual termina definitivamente o programa atual?

XCTL.


Qual é mais indicado para módulos reutilizáveis?

LINK.


Qual costuma ser usado após Login para Menu Principal?

XCTL.


Posso executar código após um XCTL?

Não.


LINK é igual a CALL?

Não. O conceito de retorno é semelhante, mas LINK opera dentro do ambiente gerenciado pelo CICS, com controle de transação, contexto e recursos.


O Cofre dos Programadores (Easter Egg)

Há uma velha lenda entre programadores de mainframe que diz existir uma região CICS esquecida em algum laboratório da IBM, apelidada de REGION-X.

Nela existiria um programa chamado FOREVER, que executou um XCTL em 1987 e nunca mais retornou.

Toda vez que um jovem programador pergunta:

— "Será que esse programa volta?"

Um veterano apenas sorri e responde:

— "Pergunte ao FOREVER..."

Claro, é apenas uma brincadeira de corredor. Mas ela resume perfeitamente o conceito: algumas transferências foram feitas para nunca olhar para trás.


Conclusão — A Porta Certa no Momento Certo

LINK e XCTL possuem a mesma missão: transferir o controle entre programas. No entanto, representam filosofias completamente diferentes de construção de aplicações.

LINK é colaboração. Um programa pede ajuda, recebe o resultado e continua sua jornada. Ele favorece reutilização, modularidade e organização.

XCTL é sucessão. O programa conclui sua missão, entrega o bastão e permite que outro assuma o restante da transação. O fluxo fica mais limpo e evita preservar um contexto que nunca mais será utilizado.

Em sistemas bancários, seguradoras, companhias aéreas e grandes ambientes corporativos, essa decisão acontece milhares — às vezes milhões — de vezes por dia. Um simples comando define se o programa permanece como protagonista da história ou se entrega definitivamente o palco ao próximo ator.

Da próxima vez que você vir um EXEC CICS LINK ou um EXEC CICS XCTL, lembre-se do velho edifício iluminado por terminais verdes. Algumas portas foram feitas para serem abertas, entrar, resolver um assunto e voltar. Outras se fecham atrás de você para sempre.

E, no silencioso universo do CICS, escolher a porta correta é uma das marcas que separam um programador iniciante de um verdadeiro arquiteto de aplicações mainframe.

Vagner Renato Bellacosa, IBM Champion e especialista em IBM Mainframe
IBM Z17 SYSTEM ONLINE
Sobre o autor

Vagner Renato Bellacosa

IBM Champion 2026 • Especialista em IBM Mainframe

Vagner Renato Bellacosa trabalha com IBM Mainframe desde 1988 , é IBM Champion e especialista em COBOL, CICS, Db2, z/OS e IBM Z. Compartilha experiências profissionais, conhecimento técnico, história da computação e práticas do universo mainframe para aproximar novas gerações das tecnologias que sustentam empresas, bancos e governos ao redor do mundo.

IBM Champion IBM Z COBOL CICS Db2 z/OS Mainframe desde 1988
GitHub LinkedIn
Inicializando conteúdo...