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

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.


domingo, 8 de julho de 2018

☕💣 OPERADOR, ANTES DE EXISTIR O COBOL EXISTIA A LÓGICA! — O SEGREDO QUE TRANSFORMA APRENDIZES EM MESTRES DO MAINFRAME

 

Bellacosa Mainframe e a logica de programação estruturada para mainframe

☕💣 OPERADOR, ANTES DE EXISTIR O COBOL EXISTIA A LÓGICA! — O SEGREDO QUE TRANSFORMA APRENDIZES EM MESTRES DO MAINFRAME

Por que tantos profissionais aprendem COBOL, mas poucos se tornam realmente programadores?

Existe uma crença muito comum entre iniciantes no universo Mainframe:

"Se eu decorar comandos COBOL, vou aprender a programar."

Mas a realidade é outra.

Um programador COBOL experiente sabe que a linguagem é apenas uma ferramenta.

O verdadeiro diferencial está na lógica.

Quando observamos um sistema bancário executando milhões de transações por dia, um processamento batch consolidando contas correntes ou um programa CICS consultando dados em tempo real, o que realmente está funcionando por trás das telas verdes não é COBOL.

É a lógica.

O COBOL apenas traduz essa lógica para o computador.

Por isso, antes de estudar comandos avançados, VSAM, DB2, MQ ou CICS, é fundamental compreender os pilares da programação.

E curiosamente esses mesmos pilares já existiam muito antes dos computadores modernos.


O que é um algoritmo no mundo Mainframe?

A definição clássica diz que algoritmo é uma sequência finita de passos para resolver um problema.

No Mainframe podemos enxergar um algoritmo como um JOB.

Observe:

Exemplo cotidiano

Preparar café.

  1. Colocar água.

  2. Adicionar pó.

  3. Aquecer.

  4. Coar.

  5. Servir.

Existe uma sequência.

Se invertermos os passos, o resultado não será o esperado.


Exemplo Mainframe

Processar folha de pagamento.

  1. Ler arquivo de funcionários.

  2. Ler tabela salarial.

  3. Calcular salário.

  4. Calcular impostos.

  5. Gerar relatório.

  6. Atualizar arquivo mestre.

Perceba:

Um programa COBOL nada mais é que uma sequência organizada de passos.

Isso é um algoritmo.


O algoritmo invisível que existe em todo JOB

Quando um operador submete um JCL:

//JOB001 JOB ...
//STEP01 EXEC PGM=LEFUNC
//STEP02 EXEC PGM=CALCSAL
//STEP03 EXEC PGM=RELATOR

O JCL é um algoritmo.

Ele determina:

  • O que executar.

  • Em qual ordem.

  • Quais dados utilizar.

  • Qual resultado produzir.

Sem lógica não existe processamento.


O conceito mais importante de toda programação

Todo programa responde a três perguntas:

O que entra?

Input.

O que acontece?

Processamento.

O que sai?

Output.


Exemplo COBOL

Imagine um programa que calcula a média de um aluno.

Entrada:

01 WS-NOTA1 PIC 9(3)V99.
01 WS-NOTA2 PIC 9(3)V99.

Processamento:

COMPUTE WS-MEDIA =
        (WS-NOTA1 + WS-NOTA2) / 2.

Saída:

DISPLAY "MEDIA = " WS-MEDIA.

Observe:

Entrada → Processamento → Saída

Esse modelo está presente em praticamente todos os sistemas Mainframe.


Tipos de dados: os tijolos da programação COBOL

Todo programa trabalha com dados.

No COBOL eles são definidos na DATA DIVISION.


Dados numéricos

Exemplos:

01 WS-IDADE PIC 999.
01 WS-SALARIO PIC 9(7)V99.

Utilizados para:

  • cálculos;

  • somatórios;

  • médias;

  • juros;

  • impostos.


Dados alfanuméricos

Exemplos:

01 WS-NOME PIC X(40).
01 WS-CPF  PIC X(11).

Utilizados para:

  • nomes;

  • documentos;

  • códigos;

  • mensagens.


Dados lógicos no COBOL

COBOL não possui BOOLEAN clássico como linguagens modernas.

Normalmente utilizamos:

88 CLIENTE-ATIVO VALUE 'S'.
88 CLIENTE-INATIVO VALUE 'N'.

Ou:

01 WS-STATUS PIC X.

   88 APROVADO VALUE 'A'.
   88 REPROVADO VALUE 'R'.

Esse recurso é extremamente utilizado em sistemas bancários.


Variáveis: os registradores da aplicação

Uma variável representa uma área de memória.

Exemplo:

01 WS-SALDO PIC S9(9)V99 COMP-3.

Durante a execução:

MOVE 1000 TO WS-SALDO.

Depois:

ADD 500 TO WS-SALDO.

Valor atual:

1500

A variável mudou.

Por isso ela recebe esse nome.


Constantes em COBOL

Valores fixos normalmente são definidos com VALUE.

01 WS-TAXA-JUROS PIC 9V999
   VALUE 0.125.

Ou:

01 WS-PI PIC 9V99999
   VALUE 3.14159.

O conceito é simples:

Uma constante não deve mudar.


MOVE: o comando mais utilizado do COBOL

Na apostila existe o conceito de atribuição.

No COBOL isso ocorre principalmente através do comando MOVE.

Exemplo:

MOVE 100 TO WS-SALDO.

Significa:

"Coloque o valor 100 dentro da variável."

Outro exemplo:

MOVE WS-NOME TO WS-NOME-CLIENTE.

Equivale à atribuição de uma variável para outra.


Entrada e saída de dados no Mainframe

Em linguagens acadêmicas encontramos:

Leia
Escreva

No COBOL encontramos:

READ
WRITE
DISPLAY
ACCEPT


Entrada de dados

Terminal:

ACCEPT WS-NOME.

Arquivo:

READ ARQ-CLIENTES

Saída de dados

Tela:

DISPLAY WS-NOME.

Arquivo:

WRITE REG-SAIDA.

Relatório:

WRITE LINHA-RELATORIO.

Operadores matemáticos no COBOL

O COBOL utiliza verbos muito próximos da linguagem humana.


Soma

ADD A TO B.

Subtração

SUBTRACT A FROM B.

Multiplicação

MULTIPLY A BY B.

Divisão

DIVIDE A INTO B.

Fórmulas complexas

COMPUTE WS-MEDIA =
       (WS-NOTA1 + WS-NOTA2) / 2.

O COMPUTE é um dos comandos mais poderosos da linguagem.


Operadores relacionais

São utilizados para comparar valores.


Igual

IF WS-IDADE = 18

Maior

IF WS-SALDO > 1000

Menor

IF WS-SALDO < 0

Diferente

IF WS-STATUS NOT = 'A'

O poder do IF

Todo sistema bancário depende de decisões.

A decisão é implementada através do IF.


Exemplo

IF WS-SALDO > 0
    DISPLAY "CONTA POSITIVA"
END-IF.

Exemplo bancário

IF WS-LIMITE > WS-VALOR-SAQUE
    PERFORM EFETUA-SAQUE
ELSE
    PERFORM NEGA-SAQUE
END-IF.

Observe:

O programa está tomando decisões.

Isso é lógica.


EVALUATE: o SWITCH/CASE do COBOL

Em outras linguagens existe SWITCH.

No COBOL moderno utilizamos:

EVALUATE WS-STATUS
   WHEN 'A'
      DISPLAY 'ATIVO'
   WHEN 'I'
      DISPLAY 'INATIVO'
   WHEN OTHER
      DISPLAY 'INVALIDO'
END-EVALUATE.

Muito comum em sistemas corporativos.


Estruturas de repetição no COBOL

Um dos conceitos mais importantes da programação.

Imagine um arquivo com 50 milhões de registros.

Como processar tudo?

Com laços de repetição.


PERFORM UNTIL

PERFORM UNTIL EOF = 'S'

   READ ARQ-CLIENTES
      AT END
         MOVE 'S' TO EOF
   END-READ

END-PERFORM.

Esse é provavelmente um dos padrões mais encontrados no Mainframe.


O algoritmo clássico de processamento batch

Observe a lógica utilizada em milhares de programas COBOL:

ABRIR ARQUIVOS

LER PRIMEIRO REGISTRO

ENQUANTO NÃO FOR FIM DO ARQUIVO

   PROCESSAR

   LER PRÓXIMO REGISTRO

FIM-ENQUANTO

FECHAR ARQUIVOS

Transformado para COBOL:

OPEN INPUT ARQ-CLIENTES

PERFORM UNTIL EOF = 'S'

   READ ARQ-CLIENTES
      AT END
         MOVE 'S' TO EOF
      NOT AT END
         PERFORM PROCESSA-REGISTRO
   END-READ

END-PERFORM

CLOSE ARQ-CLIENTES.

Esse padrão existe há décadas.

E continua executando boa parte da economia mundial.


A lógica por trás de CICS

Muitos acreditam que CICS é algo completamente diferente.

Mas a lógica é a mesma.

Entrada:

EXEC CICS RECEIVE

Processamento:

IF
EVALUATE
COMPUTE

Saída:

EXEC CICS SEND

Novamente:

Entrada → Processamento → Saída.


O segredo dos grandes programadores COBOL

Os melhores profissionais não decoram comandos.

Eles aprendem a pensar.

Quando recebem uma demanda, primeiro desenham a lógica.

Depois escrevem o código.

Por isso um profissional experiente consegue aprender:

  • COBOL

  • PL/I

  • Natural

  • Java

  • Python

  • C#

Porque a lógica permanece.

A linguagem muda.

O raciocínio não.


Conclusão

Todo sistema Mainframe que processa cartões, PIX, contas correntes, seguros, previdência, telecomunicações ou governo possui a mesma fundação:

Algoritmos.

Variáveis.

Decisões.

Repetições.

Processamento de dados.

O COBOL não é apenas uma linguagem.

Ele é a materialização de uma lógica extremamente bem estruturada, criada para representar regras de negócio de forma clara e confiável.

Quem domina apenas comandos escreve programas.

Quem domina lógica constrói sistemas que sobrevivem décadas.

E talvez esse seja o maior segredo do Mainframe:

Os computadores mudaram.

As telas mudaram.

As linguagens mudaram.

Mas a lógica continua exatamente a mesma desde os primeiros dias da computação.



domingo, 19 de abril de 2015

☕🔥 TRABALHAR COM SISTEMAS LEGADOS — O QUE MUITA GENTE AINDA NÃO ENTENDE

 

Bellacosa Mainframe e os sistemas legados do mainframe

☕🔥 TRABALHAR COM SISTEMAS LEGADOS — O QUE MUITA GENTE AINDA NÃO ENTENDE

O universo dos sistemas legados e aqui existe algo importante:

muita gente fala sobre “modernização” sem realmente entender:

  • o valor do legado,

  • a engenharia envolvida,

  • a complexidade do negócio,

  • e principalmente…

  • o custo gigantesco de substituir décadas de conhecimento corporativo.

O autor desmonta vários mitos sobre sistemas legados e mostra algo que profissionais experientes já perceberam há muito tempo:

legado não significa velho.
legado significa sobrevivente.


O PRIMEIRO GRANDE ERRO:

CONFUNDIR “ANTIGO” COM “OBSOLETO”

Esse talvez seja o maior preconceito da área de TI.

Existe uma falsa narrativa de que:

  • se usa COBOL → é velho

  • se roda em mainframe → está ultrapassado

  • se foi criado há 30 anos → precisa morrer

Mas isso ignora um detalhe brutal:

O sistema ainda funciona.

E mais:
funciona em escala absurda.

O texto cita os IBM Z processando bilhões de transações.

Isso não é exagero.


O QUE O MAINFRAME ENTREGA QUE MUITOS SISTEMAS “MODERNOS” NÃO ENTREGAM?

1. ESTABILIDADE

Um sistema bancário core:

  • não pode parar,

  • não pode corromper dados,

  • não pode perder transações.

Enquanto muitos sistemas modernos:

  • reiniciam containers,

  • escalam pods,

  • reciclam microserviços,

  • aceitam indisponibilidade parcial,

o mainframe foi projetado para:

  • continuidade absoluta,

  • integridade transacional,

  • consistência de dados.


2. COMPATIBILIDADE DE DÉCADAS

Isso é uma obra de engenharia gigantesca.

Um programa COBOL compilado há décadas ainda pode funcionar hoje com mínimas alterações.

Imagine isso no mundo JavaScript.

Tente rodar:

  • AngularJS antigo,

  • bibliotecas JQuery antigas,

  • dependências npm de 10 anos atrás.

Você provavelmente terá:

  • incompatibilidades,

  • vulnerabilidades,

  • APIs quebradas,

  • frameworks mortos.

No mainframe:

  • o investimento é preservado.


3. ESCALABILIDADE REAL

Muita gente acha que escalabilidade significa:
“subir mais containers”.

No IBM Z:

  • escalabilidade envolve throughput transacional massivo,

  • I/O absurdamente otimizado,

  • processamento paralelo sofisticado,

  • canais dedicados,

  • criptografia em hardware.

É outro nível de engenharia.


O TEXTO ATACA UM MITO PERIGOSO:

“É SÓ REESCREVER”

Essa frase já destruiu projetos bilionários.


EXEMPLO REAL:

O SISTEMA NÃO É SÓ CÓDIGO

Um sistema legado de banco contém:

  • regras fiscais,

  • exceções históricas,

  • comportamento jurídico,

  • integrações obscuras,

  • regras nunca documentadas,

  • tratamentos especiais,

  • decisões de negócio acumuladas por décadas.

Muitas vezes:
nem a empresa sabe exatamente tudo que o sistema faz.

Porque:
o sistema VIROU o próprio negócio.


EXEMPLO PRÁTICO

Imagine um sistema de conta corrente criado em 1987.

Durante décadas ele recebeu:

  • correções,

  • adequações do Banco Central,

  • planos econômicos,

  • inflação,

  • moedas diferentes,

  • PIX,

  • Open Finance,

  • LGPD,

  • integração mobile,

  • antifraude,

  • compliance.

Agora imagine alguém dizendo:

“vamos reescrever tudo em Node.js.”

Isso é equivalente a:

  • trocar o motor de um avião em voo.


O ANO 2000 PROVOU O VALOR DOS LEGADOS

O texto cita algo brilhante:
o bug do milênio.

E isso é importantíssimo historicamente.


O QUE FOI O Y2K?

Muitos sistemas armazenavam ano com 2 dígitos:

  • 98

  • 99

O medo era:
2000 virar “00”
e sistemas interpretarem:
1900.


O QUE AS EMPRESAS FIZERAM?

Elas tiveram duas opções:

OPÇÃO 1

Reescrever tudo.

OPÇÃO 2

Corrigir os sistemas existentes.

A maioria escolheu:

corrigir.

Por quê?

Porque:

  • era mais seguro,

  • mais barato,

  • menos arriscado,

  • mais previsível.

Isso já mostrava:
o legado tinha valor demais para ser descartado.


A GRANDE VERDADE:

O LEGADO CARREGA O CONHECIMENTO DA EMPRESA

Isso é uma das ideias mais profundas do texto.

Muitos sistemas legados:

  • NÃO possuem documentação completa,

  • NÃO possuem diagramas UML,

  • NÃO possuem arquitetura formal moderna.

Mas possuem algo mais valioso:

décadas de comportamento validado em produção.


“A VERDADE ESTÁ NOS FONTES”

Essa frase do texto é fantástica.

Porque ela descreve exatamente a realidade do maintainer.

Em muitos ambientes:

  • o código é a documentação,

  • o batch é a documentação,

  • o JCL é a documentação,

  • o SYSIN é a documentação,

  • o histórico de incidentes é a documentação.


O DRAMA DA MANUTENÇÃO EVOLUTIVA

Aqui o texto entra numa crítica extremamente importante.

Existe um erro clássico:
querer aplicar metodologias modernas de desenvolvimento em sistemas construídos há 30 anos.


EXEMPLO PRÁTICO

Imagine exigir:

  • microsserviços,

  • DDD,

  • UML completa,

  • Swagger,

  • pipelines modernos,

  • arquitetura hexagonal,

num sistema:

  • monolítico,

  • batch,

  • COBOL,

  • VSAM,

  • CICS,

  • DB2,

  • sem documentação formal.

Isso frequentemente vira:

  • burocracia,

  • atraso,

  • custo,

  • documentação inútil.


O QUE REALMENTE AJUDA EM LEGADO?

O texto sugere algo muito mais inteligente:

1. Engenharia reversa

Entender o sistema a partir do código.

2. Refactoring gradual

Melhorar sem destruir.

3. Ferramentas cognitivas

Usar IA para:

  • mapear fluxos,

  • identificar impacto,

  • localizar regras de negócio.

4. Modelagem baseada no que EXISTE

E não no que seria “ideal”.


A ANALOGIA DO MÉDICO É BRILHANTE

Essa é uma das melhores partes do texto.

O autor compara:

  • sistemas em produção
    com

  • pacientes em emergência.

E isso é MUITO real.


CENÁRIO REAL DE PRODUÇÃO

02:13 da madrugada

Um job crítico ABENDA.

Impacto:

  • folha de pagamento parada,

  • TED não enviada,

  • PIX inconsistente,

  • faturamento bloqueado.

O analista precisa:

PASSO 1 — IDENTIFICAR O SINTOMA

  • qual JOB falhou?

  • qual step?

  • qual ABEND?

  • qual dataset?

  • qual SQLCODE?


PASSO 2 — INVESTIGAR A CAUSA

Pode ser:

  • espaço,

  • índice inválido,

  • deadlock,

  • arquivo corrompido,

  • retorno incorreto,

  • problema lógico.


PASSO 3 — INTERVIR SEM PIORAR

Aqui mora o perigo.

Uma correção mal feita pode:

  • corromper milhões de registros,

  • causar inconsistência contábil,

  • derrubar outros sistemas.


PASSO 4 — RESTABELECER O SERVIÇO

O objetivo é:

  • restaurar operação rapidamente,

  • preservar integridade,

  • minimizar impacto financeiro.

Isso exige:

  • raciocínio,

  • experiência,

  • leitura de dump,

  • análise sistêmica,

  • sangue frio.


POR QUE ISSO VICIA?

Porque existe adrenalina intelectual.

Você:

  • investiga,

  • correlaciona,

  • deduz,

  • testa hipóteses,

  • encontra causa raiz,

  • salva produção.

É quase trabalho investigativo.


O QUE O MERCADO NÃO ENTENDE

Muitos enxergam:
“programador COBOL”.

Mas o profissional legado experiente normalmente entende:

  • negócio,

  • processamento,

  • arquitetura,

  • performance,

  • banco de dados,

  • recovery,

  • segurança,

  • integração,

  • operação.

Frequentemente ele é:

o verdadeiro guardião operacional da empresa.


O PARADOXO DO LEGADO

Quanto mais importante o sistema:

  • menos ele pode falhar,

  • menos ele pode mudar radicalmente.

Por isso:
os sistemas mais críticos do mundo
costumam ser os mais antigos.


PASSO A PASSO:

COMO UM PROFISSIONAL DE LEGADO EVOLUI

NÍVEL 1 — SOBREVIVÊNCIA

Aprende:

  • JCL,

  • COBOL,

  • logs,

  • abends.


NÍVEL 2 — ENTENDIMENTO

Começa a:

  • ler fluxos,

  • entender batch,

  • mapear integrações.


NÍVEL 3 — ANÁLISE

Consegue:

  • fazer troubleshooting,

  • identificar impacto,

  • otimizar processos.


NÍVEL 4 — VISÃO SISTÊMICA

Entende:

  • negócio,

  • arquitetura corporativa,

  • operação enterprise.


NÍVEL 5 — REFERÊNCIA

Vira:

  • mentor,

  • resolvedor de crises,

  • especialista raro.


A GRANDE LIÇÃO DO TEXTO

Sistemas legados não sobreviveram por acidente.

Eles sobreviveram porque:

  • funcionam,

  • escalam,

  • são resilientes,

  • carregam décadas de conhecimento,

  • sustentam operações críticas do planeta.


CONCLUSÃO

O texto desmonta a visão superficial de que:
“legado é lixo tecnológico”.

Na prática:

  • legado é engenharia viva,

  • conhecimento acumulado,

  • estabilidade operacional,

  • patrimônio corporativo.

E existe algo quase poético nisso:

Muitos sistemas modernos nascem já pensando em substituição.

Os legados nasceram para durar.

E duraram tanto…
que acabaram sustentando o mundo inteiro.


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.