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

quarta-feira, 18 de junho de 2014

💀 HLASM: O Fantasma do Mainframe Que Decide Se Seu Sistema Vive ou Cai

 

Bellacosa Mainframe apresenta o HLASM Assembly no modo puro

💀 “HLASM: O Fantasma do Mainframe Que Decide Se Seu Sistema Vive ou Cai

📜 Origem e evolução

➡️ Tradução resumida:
HLASM é uma evolução do Assembly original criado com o IBM System/360 (1964).
Em 1992, a IBM lançou o HLASM com melhorias importantes.

💡 Explicando de verdade

Assembly sempre existiu como a linguagem mais próxima do hardware.
O HLASM veio para resolver um problema clássico:

“Assembly é poderoso… mas um inferno de manter.”

Então a IBM trouxe:

  • Macros mais avançadas (quase “funções” antes de existir função)
  • Mensagens de erro mais humanas
  • Integração com ferramentas como ISPF

👉 Ou seja: não mudou a essência, mas tornou o caos… mais organizado.


⚙️ Onde o HLASM se encaixa

➡️ Tradução:
HLASM roda na base do sistema — mais próximo do hardware que COBOL ou Java.

💣 Interpretação estilo Bellacosa:

Se o mainframe fosse uma empresa:

  • COBOL → gerente de negócios
  • Java → funcionário moderno
  • HLASM → o cara que controla o prédio inteiro, energia, segurança e elevador

👉 Ele não aparece… mas sem ele, nada sobe.


🏦 Uso no mundo real

➡️ Tradução:
HLASM é usado em:

  • Sistemas operacionais
  • Transações de alta performance
  • Middleware
  • Rotinas críticas

💥 Tradução prática:

Quando você passa um cartão:

Existe uma chance enorme de um trecho em HLASM validar aquilo em milissegundos.


🚀 Principais usos (com exemplos reais)

1. Exits de sistema

Exemplo citado: IEFU83 (SMF Exit)

👉 O que isso significa?
Você intercepta eventos do sistema e decide:

  • gravar log
  • ignorar
  • alterar comportamento

💣 Isso é hackear o comportamento do z/OS oficialmente


2. Rotinas ultra-performáticas

Exemplo:

  • Subrotina em assembler chamada por COBOL
  • Uso da instrução CKSM (checksum)

👉 Tradução Bellacosa:
COBOL pede ajuda pro HLASM quando:

“preciso fazer isso MUITO rápido ou não dá”


3. Acesso direto ao hardware

HLASM permite:

  • usar instruções novas do processador antes de qualquer linguagem suportar
  • manipular memória diretamente

👉 Isso é nível:

“você não programa… você conversa com o CPU”


⚡ Benefícios

✔ Controle absoluto
✔ Performance absurda
✔ Compatibilidade histórica (código de décadas ainda roda)

💣 Insight crítico

Isso é o motivo do mainframe ainda dominar:

O código não envelhece… ele acumula valor.


⚠️ Problemas

➡️ Tradução:

  • Curva de aprendizado brutal
  • Código difícil de entender
  • Pouca gente nova aprendendo

💥 Tradução honesta:

HLASM não é difícil…

Ele é hostil.

E pior:

  • muitos códigos são praticamente indecifráveis
  • dependem de “tribo” (knowledge transfer)

👨‍💻 Quem usa HLASM hoje?

Perfis:

  1. System Programmers
  2. Performance Engineers
  3. Desenvolvedores de produtos z/OS

💣 Realidade de mercado:

HLASM é raro → logo:

💰 Quem domina… cobra caro.


📉 Tendência moderna (muito importante!)

O autor fala algo extremamente relevante:

➡️ Hoje existe movimento de MIGRAR HLASM → COBOL / Metal C

💡 Por quê?

  • Compiladores evoluíram
  • Performance do HLL melhorou
  • Falta de profissionais HLASM

👉 Tradução brutal:

O sistema ainda depende de HLASM…
mas o mercado está tentando escapar dele.


🧠 Análise Profunda (nível arquiteto)

🔥 O paradoxo do HLASM

HLASM é:

  • indispensável
  • poderoso
  • eterno

E ao mesmo tempo:

  • evitado
  • temido
  • escasso

👉 Isso cria um fenômeno único:

“tecnologia crítica… mas invisível”


🏛️ Por que ele nunca morreu?

Porque ele resolve 3 coisas que nenhuma linguagem resolve igual:

  1. Tempo (performance extrema)
  2. Controle (nível de hardware)
  3. Compatibilidade (50+ anos)

💣 Insight Bellacosa (o mais importante)

HLASM não é só linguagem.

Ele é o “firmware lógico” do mainframe.


🧪 Exemplo prático (simplificado)

Cenário:

Você tem um programa COBOL que processa milhões de registros.

Problema:

  • lento
  • consumo alto de CPU

Solução:

Criar subrotina em HLASM:

CHECKSUM DS 0H
LR R2,R1
CKSM R2,R3
BR R14

👉 COBOL chama isso → ganha performance brutal


🔮 Futuro do HLASM

Tendências:

✔ Vai continuar existindo
✔ Vai ficar mais restrito
✔ Vai virar skill premium

O que muda:

  • Mais ferramentas com IA
  • Mais abstração
  • Menos código novo em assembler

💬 Conclusão no estilo Bellacosa Mainframe

💣 HLASM é o seguinte:

Você não escolhe aprender…
você é escolhido pela necessidade.

Ele é:

  • o código que ninguém quer mexer
  • mas todo sistema crítico depende

👉 E quando dá problema…

não é bug… é incidente de guerra.