Translate

Mostrar mensagens com a etiqueta programação. Mostrar todas as mensagens
Mostrar mensagens com a etiqueta programação. Mostrar todas as mensagens

sábado, 13 de junho de 2026

☕🚀 A CRISE SILENCIOSA DO COBOL: O QUE A MAIORIA DAS PESSOAS NÃO ESTÁ ENXERGANDO

 

Bellacosa Mainframe e a crise silenciosa do COBOL

☕🚀 A CRISE SILENCIOSA DO COBOL: O QUE A MAIORIA DAS PESSOAS NÃO ESTÁ ENXERGANDO

"O problema não é que os sistemas COBOL vão parar amanhã. O problema é que, quando precisarmos deles depois de amanhã, talvez não haja gente suficiente para entendê-los."


Introdução: O paradoxo que desafia a lógica

Existe uma frase repetida há décadas no mundo da tecnologia:

"COBOL está morrendo."

Curiosamente, essa frase é tão antiga que já deveria ter morrido antes do próprio COBOL.

Nos anos 1980 diziam isso.

Nos anos 1990 também.

Nos anos 2000 então, parecia inevitável.

Veio Java.

Veio .NET.

Veio Python.

Veio Cloud.

Vieram Microservices.

Vieram Containers.

Vieram APIs.

Veio Inteligência Artificial.

E o COBOL continua processando bilhões de transações diariamente.

Mas há algo diferente acontecendo agora.

Pela primeira vez na história, o risco não é tecnológico.

O risco é humano.

Não estamos falando da morte da linguagem.

Estamos falando da aposentadoria das pessoas que sabem usá-la.

E isso muda completamente a discussão.


O grande erro dos anos 90

Durante os anos 1990 aconteceu um fenômeno curioso.

Universidades do mundo inteiro decidiram que COBOL não fazia mais sentido.

Os currículos migraram para:

  • C++

  • Java

  • Redes

  • Sistemas Distribuídos

  • Orientação a Objetos

Naquele momento parecia uma decisão racional.

A internet estava explodindo.

O mundo falava sobre websites.

Empresas de tecnologia surgiam diariamente.

Tudo indicava que os sistemas legados seriam substituídos rapidamente.

Mas havia um detalhe que ninguém percebeu.

Substituir um sistema crítico não é como trocar um aplicativo de celular.


O mito da reescrita fácil

Imagine um sistema bancário criado em 1975.

Durante cinquenta anos ele recebeu:

  • correções

  • adaptações

  • mudanças regulatórias

  • novos produtos

  • fusões bancárias

  • ajustes tributários

  • exceções operacionais

Hoje esse sistema possui milhões de linhas de código.

Mas o código é apenas a ponta do iceberg.

O verdadeiro patrimônio é o conhecimento de negócio embutido nele.

Muitas regras não estão documentadas.

Elas vivem no código.

E pior.

Muitas vezes nem o próprio negócio sabe que elas existem.


Exemplo real

Uma seguradora decidiu migrar um sistema COBOL para Java.

Projeto estimado:

  • 2 anos

  • US$ 20 milhões

Resultado:

  • 7 anos

  • mais de US$ 100 milhões

E ainda assim precisaram manter parte do sistema original funcionando.

Por quê?

Porque descobriram regras escondidas no código que ninguém conhecia.

Uma delas calculava benefícios de clientes antigos utilizando uma legislação que já nem existia mais.

Mas aqueles contratos continuavam válidos.

Remover a regra geraria processos judiciais.


O COBOL virou infraestrutura invisível

Hoje ninguém acorda pensando em COBOL.

Da mesma forma que ninguém acorda pensando em:

  • rede elétrica

  • abastecimento de água

  • sistema de esgoto

Mas todos percebem quando param de funcionar.

O COBOL tornou-se uma camada invisível da sociedade moderna.


Quando você faz um PIX

Existe grande chance de algum processamento acabar passando por sistemas mainframe.

Quando usa cartão de crédito

Mainframe.

Quando recebe aposentadoria

Mainframe.

Quando paga imposto

Mainframe.

Quando consulta benefícios governamentais

Mainframe.

Quando uma companhia aérea processa reservas

Mainframe.


Muitas pessoas acreditam que esses sistemas foram substituídos.

Na realidade, na maioria dos casos, eles foram encapsulados.

Colocou-se uma API na frente.

Um aplicativo bonito.

Uma interface moderna.

Mas atrás continua existindo um programa COBOL executando a lógica crítica.


O IRS e o sistema de 60 anos

Um dos exemplos mais famosos é o Internal Revenue Service (IRS) dos Estados Unidos.

Quando falamos do IRS estamos falando do órgão responsável pela arrecadação federal americana.

Grande parte da infraestrutura principal foi construída durante os anos 1960.

Pense nisso.

Quando parte desses sistemas nasceu:

  • o homem ainda não havia chegado à Lua;

  • a internet não existia;

  • computadores ocupavam salas inteiras;

  • discos rígidos tinham capacidade ridícula para os padrões atuais.

Mesmo assim esses sistemas continuam funcionando.

Isso não é apenas impressionante.

É quase inacreditável.


O custo da modernização

Existe outra ilusão comum.

A ideia de que basta investir dinheiro para resolver o problema.

Se fosse verdade, ele já estaria resolvido.

Governos e bancos gastaram bilhões tentando modernizar sistemas legados.

Alguns tiveram sucesso.

Muitos não.


O motivo

A dificuldade não está em programar.

A dificuldade está em entender.

Imagine receber um programa COBOL escrito em 1978.

O programador original já morreu.

O analista de negócios aposentou-se.

A documentação desapareceu.

Os requisitos originais não existem.

Agora descubra exatamente o que ele faz.

Sem errar.

Porque um erro pode impactar:

  • milhões de aposentados;

  • bilhões de dólares;

  • benefícios sociais;

  • arrecadação tributária.


A aposentadoria em massa

Aqui está o ponto mais preocupante.

O profissional COBOL médio não tem 25 anos.

Nem 35.

Nem 45.

Em muitos lugares ele já ultrapassou os 55 anos.

Isso significa que estamos diante de uma transição geracional gigantesca.

Imagine uma empresa com:

  • 100 especialistas COBOL

Se 10% se aposentam por ano:

Ano 1:
100 → 90

Ano 5:
90 → 59

Ano 10:
59 → 35

Ano 15:
35 → 20

Ano 20:
20 → 12

O conhecimento evapora rapidamente.


O conhecimento que não está nos livros

Aqui existe algo ainda mais perigoso.

Muitas pessoas confundem saber COBOL com saber sistemas COBOL.

São coisas completamente diferentes.

Aprender COBOL pode levar semanas.

Dominar um ambiente corporativo pode levar décadas.


Exemplo

Um desenvolvedor pode aprender:

ADD A TO B GIVING C.

em poucos minutos.

Mas compreender:

  • JES2

  • CICS

  • DB2

  • IMS

  • RACF

  • VSAM

  • MQ

  • JCL

  • SMF

  • DFSORT

e a integração entre todos eles...

isso pode exigir anos.


O verdadeiro gargalo não é COBOL

Essa é uma observação que faço frequentemente.

As manchetes falam:

"Faltam programadores COBOL."

Mas essa frase é simplista.

O que realmente falta são profissionais capazes de entender ecossistemas corporativos complexos.


Porque um especialista de verdade entende:

  • negócio

  • arquitetura

  • operação

  • performance

  • segurança

  • recuperação de desastres

Ele não é apenas programador.

Ele é guardião do conhecimento institucional.


A inteligência artificial vai resolver?

Pergunta inevitável em 2026.

A resposta é:

Sim.

E não.


Onde a IA ajuda

Hoje a IA consegue:

  • explicar código COBOL;

  • converter COBOL para Java;

  • gerar documentação;

  • identificar dependências;

  • acelerar manutenção.

Isso é extraordinário.


Onde a IA não resolve

A IA não sabe:

  • por que determinada regra existe;

  • qual acordo político gerou aquela exceção;

  • qual legislação de 1987 originou um cálculo;

  • qual cliente depende daquela lógica.

Esse conhecimento continua humano.


O caso brasileiro

Como brasileiro e profissional de mainframe, vejo um cenário interessante.

O Brasil está em posição melhor do que muitos países.

Por quê?

Porque nunca abandonou completamente a formação em tecnologias corporativas.

Temos profissionais atuando em:

  • bancos;

  • seguradoras;

  • governo;

  • telecomunicações.

Instituições como:

  • Banco do Brasil

  • Caixa

  • Bradesco

  • Itaú

  • Santander

  • Serpro

  • Dataprev

continuam mantendo grandes ambientes mainframe.

Isso criou uma continuidade geracional que muitos países perderam.


O erro estratégico das empresas

Durante anos muitas organizações enxergaram o mainframe apenas como custo.

E isso gerou decisões perigosas.

Redução de equipes.

Pouco treinamento.

Ausência de sucessão.

Falta de documentação.

Perda de conhecimento.


O resultado?

Quando um especialista se aposenta, descobre-se que ele era o único que compreendia determinado processo crítico.

Já vi situações em que uma única pessoa entendia completamente um sistema responsável por movimentar bilhões.

Quando ela saiu, a empresa entrou em pânico.


O mito do profissional velho

Existe também um preconceito silencioso.

Muita gente associa COBOL a tecnologia ultrapassada.

Logo associa seus profissionais a algo ultrapassado.

Isso é um erro monumental.

Os melhores especialistas que conheci dominavam:

  • COBOL

  • Java

  • APIs

  • Linux

  • Cloud

  • Containers

  • DevOps

Eles simplesmente entendiam também a camada que sustenta o mundo.


O que deveria estar acontecendo

As organizações mais inteligentes já perceberam o problema.

Elas estão investindo em:

Mentoria reversa

Veteranos treinando jovens.

Pair Programming

Transferência contínua de conhecimento.

Documentação moderna

Captura do conhecimento tácito.

IA aplicada ao legado

Aceleração da curva de aprendizado.

Programas universitários

Retorno do ensino de COBOL.


Uma comparação com a engenharia civil

Imagine uma ponte construída há 60 anos.

Ela continua suportando milhões de veículos.

Ninguém diria:

"Vamos demolir porque é antiga."

Primeiro analisamos:

  • estabilidade;

  • manutenção;

  • custo;

  • risco.

Sistemas COBOL deveriam ser vistos da mesma forma.

A idade não é o problema.

A capacidade de manutenção é.


O verdadeiro risco para o futuro

A pergunta não é:

"Quando o COBOL vai acabar?"

A pergunta correta é:

"Quem vai entender os sistemas quando os especialistas atuais não estiverem mais aqui?"

Essa é uma questão muito mais séria.

Porque linguagens podem ser aprendidas.

Conhecimento institucional não pode ser recriado facilmente.


A visão Bellacosa Mainframe

Depois de décadas observando o mundo corporativo, cheguei a uma conclusão simples.

O futuro não será COBOL versus IA.

Nem Mainframe versus Cloud.

Nem Legado versus Modernização.

O futuro pertence à integração.

Os vencedores serão aqueles capazes de unir:

  • conhecimento histórico;

  • arquitetura moderna;

  • inteligência artificial;

  • plataformas corporativas.

O profissional mais valioso da próxima década não será aquele que conhece apenas a tecnologia nova.

Nem aquele que conhece apenas a tecnologia antiga.

Será aquele que consegue traduzir um mundo para o outro.


Conclusão: a crise silenciosa é real

A grande ironia da história é que o COBOL nunca foi tão invisível e tão importante ao mesmo tempo.

Ele está escondido atrás de aplicativos modernos, APIs elegantes e interfaces digitais sofisticadas.

Mas continua sustentando partes fundamentais da economia global.

O verdadeiro desafio não é técnico.

É humano.

A cada aposentadoria, perde-se mais do que um programador.

Perde-se contexto.

Perde-se história.

Perde-se conhecimento acumulado ao longo de décadas.

E conhecimento não pode ser recompilado.

A crise silenciosa do COBOL não é sobre uma linguagem criada em 1959.

É sobre a transferência de conhecimento de uma geração para outra.

Se governos, bancos e grandes corporações não tratarem isso como prioridade estratégica, poderão descobrir tarde demais que substituir hardware é fácil, substituir software é difícil, mas substituir experiência é quase impossível.

E talvez essa seja a maior lição que o mundo da tecnologia ainda não compreendeu.

O problema nunca foi o COBOL envelhecer. O problema é que seus especialistas envelheceram primeiro. ☕🚀💻🏦


quarta-feira, 10 de junho de 2026

☕💣🚀 COMP-1, COMP-2, COMP-3, COMP-4 e COMP-5 para o Programador COBOL Jr.

 

Bellacosa Mainframe e as variaveis computacionais do COBOL 

☕💣🚀 COMP-1, COMP-2, COMP-3, COMP-4 e COMP-5 para o Programador COBOL Jr.

Uma das maiores fontes de confusão para quem começa em COBOL é entender por que existem tantos tipos numéricos.

A resposta está na história dos mainframes IBM.

Cada COMP surgiu para resolver um problema específico de armazenamento, desempenho ou precisão matemática. (IBM)


Linha do Tempo

TipoSurgiu
COMPDécada de 1960
COMP-1Década de 1970
COMP-2Década de 1970
COMP-3Década de 1960
COMP-4Década de 1970
COMP-5Década de 1980

Os números exatos variam conforme compilador e plataforma, mas COMP-3 e COMP já existiam nos ambientes System/360. COMP-1, COMP-2 e COMP-4 apareceram como extensões IBM. COMP-5 surgiu posteriormente para resolver limitações do BINARY tradicional. (IBM)


COMP-1

O que é

Ponto flutuante simples (single precision).

Ocupa:

  • 4 bytes

Utilizado para:

  • cálculos científicos

  • engenharia

  • estatística

Não deve ser usado para dinheiro. (IBM)


Exemplo

01 WS-TEMPERATURA COMP-1.

MOVE 23.75 TO WS-TEMPERATURA.

Vantagens

  • rápido

  • suporta expoentes

  • ocupa pouco espaço


Desvantagens

  • perde precisão decimal

  • gera arredondamentos inesperados


Exemplo clássico

COMPUTE RESULT = 0.1 + 0.2

Resultado pode não ser exatamente:

0.300000

Isso acontece porque o valor é armazenado em binário.


COMP-2

O que é

Ponto flutuante duplo (double precision).

Ocupa:

  • 8 bytes

Muito mais preciso que COMP-1. (IBM)


Exemplo

01 WS-PI COMP-2.

MOVE 3.14159265358979 TO WS-PI.

Vantagens

  • enorme faixa de valores

  • excelente precisão científica


Desvantagens

  • mais lento

  • ocupa mais memória

  • inadequado para dinheiro


COMP-3

O Rei dos Bancos

Também chamado:

PACKED DECIMAL

ou

COMPUTATIONAL-3

É o formato mais amado pelos bancos. (IBM)


Como funciona

Cada byte armazena:

2 dígitos

mais um nibble de sinal.


Exemplo

01 SALDO PIC S9(7)V99 COMP-3.

Valor:

12345.67

Internamente:

12 34 56 7C

(C = positivo)


Vantagens

  • extremamente compacto

  • precisão decimal perfeita

  • ideal para dinheiro


Desvantagens

  • CPU precisa converter para cálculo

  • não é legível em dump


Melhor uso

Contas correntes
Faturas
Cartões
Seguros
Folha de pagamento

COMP-4

O que é

Binário IBM.

Sinônimo de:

BINARY
COMP

na maioria dos compiladores IBM. (IBM)


Exemplo

01 CONTADOR PIC S9(4) COMP-4.

Tamanho

DígitosBytes
1-42
5-94
10-188

(IBM)


Vantagens

  • muito rápido

  • ideal para índices

  • excelente para contadores


Desvantagens

O comportamento depende do:

TRUNC(STD)
TRUNC(OPT)
TRUNC(BIN)

Isso já causou milhares de bugs em migrações COBOL. (IBM)


COMP-5

O que é

Binary Native.

Foi criado para eliminar limitações do COMP-4. (IBM)


Exemplo

01 WS-ID PIC S9(4) COMP-5.

Diferença Fundamental

Mesmo declarando:

PIC S9(4)

um COMP-5 de 2 bytes pode armazenar:

-32768
até
+32767

porque usa a capacidade real do campo binário. (IBM)


Vantagens

  • mais rápido

  • ideal para APIs

  • ideal para CICS

  • ideal para LE

  • ideal para interoperabilidade com C


Desvantagens

  • pode surpreender quem espera validação pelo PIC

  • programas antigos podem comportar-se diferente


Comparação Geral

CaracterísticaCOMP-1COMP-2COMP-3COMP-4COMP-5
TipoFloatFloatDecimalBinárioBinário Nativo
Bytes48Variável2/4/82/4/8
Dinheiro⚠️⚠️
VelocidadeAltaAltaMédiaMuito AltaMuito Alta
Precisão DecimalBaixaMédiaExcelenteBoaBoa
InteroperabilidadeMédiaMédiaBaixaMédiaExcelente

Opções de Compilação que Afetam Tudo

TRUNC

TRUNC(STD)
TRUNC(OPT)
TRUNC(BIN)

Principal responsável por diferenças em COMP e COMP-4. (IBM)


ARITH

ARITH(COMPAT)
ARITH(EXTEND)

Impacta precisão matemática.

Muito importante para:

COMP-3
COMPUTE
DIVIDE
MULTIPLY

NUMPROC

NUMPROC(PFD)
NUMPROC(MIG)
NUMPROC(NOPFD)

Afeta tratamento de sinais inválidos em COMP-3.


RULES(NOEVENPACK)

Detecta packed decimals com número par de dígitos, ajudando a otimizar COMP-3. (IBM)


Problemas Conhecidos

1. Dinheiro em COMP-1

Erro clássico.

01 SALDO COMP-1.

Nunca faça isso.


2. Migração COBOL V4 → V6

Mudanças em:

TRUNC
ARITH
OPTIMIZATION

geraram diferenças de resultados em milhares de aplicações. (IBM)


3. COMP-3 Corrompido

Dump:

12 34 5F

Sinal inválido.

Pode gerar:

S0C7

4. Overflow Silencioso

Muito comum em:

COMP
COMP-4

quando TRUNC(BIN) está ativo.


Easter Eggs e Curiosidades

1. O banco não gosta de FLOAT

Em muitos bancos você encontrará:

0 ocorrências de COMP-1
0 ocorrências de COMP-2

em milhões de linhas COBOL.


2. COMP-3 domina Wall Street

Grande parte dos sistemas financeiros de alto volume ainda utiliza COMP-3 para valores monetários devido à precisão decimal exata.


3. TRUNC(BIN) "transforma" COMP em COMP-5

Na prática, muitos comportamentos tornam-se equivalentes para operações binárias. (IBM)


4. Packed Decimal foi uma genialidade da IBM

Quando memória custava fortunas, armazenar dois dígitos por byte era uma enorme vantagem econômica.


Regra de Ouro para o Programador COBOL Jr.

Se estiver em dúvida:

Dinheiro      -> COMP-3
Contadores    -> COMP-5
Índices       -> COMP-5
Percentuais   -> COMP-3
Cálculos científicos -> COMP-2
Integração C/C++ -> COMP-5

Em ambientes modernos z/OS com Enterprise COBOL 6.x, a combinação mais comum e segura é:

COMP-3 para valores financeiros
COMP-5 para inteiros e contadores

Essa dupla cobre praticamente 95% das necessidades de aplicações corporativas em bancos, seguradoras e grandes empresas. (IBM)

domingo, 26 de abril de 2026

💣🔥 O MAINFRAME NÃO PERDOA: 1 LINHA DE CÓDIGO PODE CUSTAR MILHARES 🔥💣

 

Bellacosa Mainframe falando sobre performance

💣🔥 O MAINFRAME NÃO PERDOA: 1 LINHA DE CÓDIGO PODE CUSTAR MILHARES 🔥💣

Vamos destrinchar isso no estilo Bellacosa: direto, profundo e com aquela visão de bastidor que pouca gente comenta.


🧠 Performance eom contexto real de guerra

🚀 Ajuste de Performance em Mainframe: pequenas mudanças, impacto massivo

No mundo de processamento corporativo de alto volume, a diferença entre um programa eficiente e um “pesado” não é segundos…


👉 pode significar milhares de dólares economizados em MSU (unidade que mede consumo e custo no mainframe).

Muitas vezes focamos em “funcionar”… mas esquecemos de “rodar leve”.


⚙️ Explicação — o que está POR TRÁS disso

Aqui está o ponto que muita gente subestima:

👉 Mainframe não é só CPU — é economia por instrução executada.

Cada ciclo desnecessário vira:

  • 💸 mais cobrança de licença (MLC)
  • 🐢 mais tempo de resposta
  • 💥 risco em janelas batch

🔥 Por que isso é ainda MAIS crítico em 2026?

Mesmo com cloud híbrida dominando:

  • Bancos globais ainda rodam em IBM z/OS
  • DB crítico continua em IBM Db2
  • Processamento massivo ainda depende de batch pesado

💡 Ou seja: o mainframe virou o coração invisível da economia digital.

E código ruim ali… custa caro TODO DIA.


💣 Análise técnica aprofundada dos pontos

1. 🗃️ DB2 Cursor mal usado = desperdício brutal

Se você faz:

SELECT * FROM CLIENTES

…mas só usa 10 registros:

👉 você está pagando por 10.000.

💡 Solução:

  • OPTIMIZE FOR n ROWS
  • índices corretos
  • evitar full table scan

🔥 Curiosidade:
Já vi job cair de 40 minutos → 3 minutos só ajustando índice.


2. 💾 SORT vs I/O: a guerra invisível

Quando você não usa memória suficiente:

👉 o sistema escreve em disco (WORK FILES)

Resultado:

  • I/O explode
  • tempo de execução dispara

💡 Ajuste fino:

  • REGION / MEMLIMIT
  • SORTWK corretamente dimensionado

🧠 Easter egg:
SORT mal configurado pode custar MAIS CPU que o próprio programa COBOL.


3. 🔢 COMP vs COMP-3 — detalhe que vira milhões

  • COMP → binário (rápido)
  • COMP-3 → packed decimal (mais compacto, porém mais lento em cálculo)

👉 Em loops massivos:
isso vira diferença real de CPU.

💣 Regra prática:

  • cálculo intensivo → use COMP
  • armazenamento → use COMP-3

4. ⚠️ SSRANGE — o vilão silencioso

Ótimo para debug…
PÉSSIMO em produção.

👉 Ele verifica limites de array a cada acesso.

Resultado:

  • CPU explode
  • performance despenca

🔥 Já vi aumento de +20% de CPU só por esquecer isso ligado.


🧨 O que ELE NÃO falou (mas deveria)

Aqui vai a camada avançada:

🧠 1. COBOL “bonito” pode ser lento

Código legível ≠ código eficiente

Ex:

  • PERFORM dentro de PERFORM dentro de PERFORM
  • MOVE desnecessário
  • IF redundante

🧠 2. I/O é o verdadeiro inimigo

Não é CPU.

👉 É acesso a disco.

Quem domina isso:

  • usa buffering
  • reduz READ/WRITE
  • evita datasets intermediários

🧠 3. Batch Window é política, não técnica

Se seu job estoura janela:

👉 não é só problema técnico
👉 vira problema de negócio (SLA)


💡 Exemplos reais (estilo “guerra de produção”)

  • 🏦 Banco:
    Um cursor sem índice → +300 MSU/dia
    👉 custo mensal absurdo
  • 📦 Logística:
    SORT mal dimensionado → job atrasava expedição
    👉 impacto físico real
  • 💳 Cartão de crédito:
    SSRANGE ligado → sistema 15% mais caro sem ninguém perceber

🧪 Easter Eggs de Mainframe 🕵️

  • 🧩 Programas COBOL podem rodar MAIS RÁPIDO que Java até hoje em batch massivo
  • 💣 Um único DISPLAY em loop pode matar performance
  • 🧠 Muitas empresas NÃO sabem quanto custa cada programa individual
  • ⚠️ O maior gargalo raramente é onde o dev acha que está

🎯 Conclusão — a verdade nua e crua

Modernizar não é só API, cloud ou DevOps.

👉 É respeitar a máquina.

No mainframe:

Eficiência não é otimização — é sobrevivência financeira.


🚀 Pergunta provocativa

Se hoje você tivesse que pagar do seu bolso o MSU do seu código…

👉 você ainda programaria do mesmo jeito?



💣🔥 CHECKLIST CIRÚRGICO DE PERFORMANCE — COBOL + DB2 (NÍVEL PRODUÇÃO) 🔥💣

Aqui não é teoria — é checklist de guerra, pra você olhar um programa e já saber onde cortar custo, CPU e tempo de execução.


🧠 1. ACESSO AO DB2 (onde mais se perde dinheiro)

🔍 Checklist rápido:

  • Existe índice cobrindo o WHERE?
  • Evita SELECT *?
  • Usa OPTIMIZE FOR n ROWS quando necessário?
  • Evita ORDER BY desnecessário?
  • Cursor está com FETCH controlado (não trazendo milhares sem uso)?
  • Usa WITH UR quando leitura suja é aceitável?
  • Evita funções em colunas indexadas (SUBSTR, UPPER, etc)?

💣 Cirurgia clássica:

SELECT * FROM CLIENTES

⬇️

SELECT NOME, CPF FROM CLIENTES
WHERE CPF = :WS-CPF

👉 Redução brutal de I/O + CPU


⚙️ 2. LOOPS COBOL (o assassino silencioso)

🔍 Checklist:

  • Existe PERFORM dentro de PERFORM desnecessário?
  • Loop depende de I/O (READ dentro de loop)?
  • Variáveis são recalculadas sem necessidade?
  • Usa EXIT PERFORM corretamente?

💡 Dica de ouro:

👉 Tire tudo que puder de dentro do loop


💾 3. I/O (o verdadeiro vilão)

🔍 Checklist:

  • Quantos READ/WRITE estão sendo feitos?
  • Arquivo poderia ser processado em memória?
  • Existe buffering?
  • Dataset está corretamente definido (BLKSIZE, BUFNO)?

💣 Regra brutal:

1 acesso a disco ≈ milhares de instruções CPU


🔢 4. TIPOS DE DADOS (COMP vs COMP-3)

🔍 Checklist:

  • Campos de cálculo estão como COMP?
  • Campos apenas armazenados estão como COMP-3?
  • Evita conversões constantes?

💡 Impacto real:

Loops matemáticos + tipo errado = CPU desnecessária


⚠️ 5. PARÂMETROS DE COMPILAÇÃO

🔍 Checklist:

  • SSRANGE está desligado em produção?
  • OPTIMIZE ativo?
  • NUMPROC, TRUNC corretos?

💣 Clássico erro:

👉 esquecer SSRANGE ligado = CPU queimando dinheiro


🧮 6. SORT (onde muita gente erra feio)

🔍 Checklist:

  • Está usando SORT externo em vez de COBOL?
  • Memória suficiente foi alocada?
  • Evita SORT desnecessário?

💡 Insight:

👉 SORT bem configurado = menos I/O + mais velocidade


🧠 7. DESIGN DO PROGRAMA

🔍 Checklist:

  • Programa faz mais do que deveria?
  • Existe lógica duplicada?
  • Pode dividir em etapas menores?

💣 Verdade dura:

Código grande demais = difícil de otimizar


🔥 8. JCL E EXECUÇÃO

🔍 Checklist:

  • REGION adequado?
  • MEMLIMIT ajustado?
  • Uso correto de GDG?
  • Evita datasets temporários desnecessários?

📊 9. MONITORAMENTO (quem não mede, perde dinheiro)

🔍 Checklist:

  • Analisou SMF / accounting?
  • Usou EXPLAIN no DB2?
  • Avaliou tempo CPU vs elapsed?

💡 Ferramentas típicas:

  • IBM Db2 EXPLAIN
  • SDSF
  • IBM z/OS metrics

🧪 10. MICRO-OTIMIZAÇÕES QUE VIRAM MILHARES 💸

  • Evitar MOVE desnecessário
  • Evitar DISPLAY em produção
  • Reduzir chamadas de programa
  • Evitar validações redundantes
  • Usar tabelas internas corretamente

🧨 CHECK FINAL (modo produção)

Se responder NÃO pra qualquer um abaixo, tem dinheiro sendo perdido:

  • Esse programa usa o mínimo de I/O possível?
  • O DB2 está usando índice corretamente?
  • O CPU está sendo usado de forma eficiente?
  • O tempo está dentro da janela batch?
  • O código foi pensado para performance ou só para funcionar?

🎯 FECHAMENTO ESTILO MAINFRAME ROOT

No mundo distribuído:
👉 você paga por servidor

No mainframe:
👉 você paga por cada instrução mal escrita









💣🔥 VOCÊ PROGRAMA COBOL… MAS QUEM MANDA NO JOGO É O JCL — O SEGREDO QUE NINGUÉM TE CONTA NO MAINFRAME 🔥💣

 

Bellacosa Mainframe mostra o poder do batch COBOL e JCL dupla imbativel

💣🔥 VOCÊ PROGRAMA COBOL… MAS QUEM MANDA NO JOGO É O JCL — O SEGREDO QUE NINGUÉM TE CONTA NO MAINFRAME 🔥💣

No universo mainframe, existe uma ilusão perigosa — e eu vou quebrar ela agora:

Muita gente acha que COBOL é o protagonista.

Mas sem JCL… COBOL não passa de código parado no disco.

Vamos destrinchar isso no estilo raiz — direto do chão de fábrica do z/OS.


🧠 ESSÊNCIA (SEM ENROLAÇÃO)

No ecossistema mainframe, duas siglas reinam:

  • COBOL → linguagem de programação
  • JCL → linguagem de controle

E aqui está a verdade crua:

🔥 COBOL pensa. JCL executa.


🔹 COBOL — O CÉREBRO DO NEGÓCIO

COBOL (Common Business-Oriented Language) é onde mora a inteligência do sistema.

É nele que você define:

  • Cálculos (juros, impostos, tarifas)
  • Regras de negócio
  • Validações
  • Leitura e gravação de dados

👉 Em outras palavras:

COBOL é onde a regra do banco, da seguradora, do governo ganha vida.

💥 Exemplo clássico:

IF SALDO > 1000
COMPUTE JUROS = SALDO * 0.05
END-IF

Aqui está a lógica. Mas… isso ainda não roda sozinho.


🔹 JCL — O MAESTRO INVISÍVEL

JCL (Job Control Language) não é linguagem de programação.

Ele é o orquestrador do caos.

Ele diz ao sistema:

  • Quando executar
  • Qual programa rodar
  • Quais arquivos usar
  • Em que ordem executar os passos
  • Quais recursos alocar

👉 Tradução Bellacosa:

JCL é o cara que aperta o botão, monta o ambiente e garante que tudo aconteça.


⚙️ EXEMPLO REAL (RAIZ DE PRODUÇÃO)

🧠 COBOL (a lógica)

Programa que calcula juros.

⚙️ JCL (a execução)

//JUROS JOB (ACCT),'CALCULO'
//STEP1 EXEC PGM=CALCJUROS
//INPUT DD DSN=CLIENTES.DADOS,DISP=SHR
//OUTPUT DD DSN=CLIENTES.RESULT,DISP=NEW

👉 O que está acontecendo aqui?

  • O JCL chama o programa COBOL (CALCJUROS)
  • Define os arquivos de entrada e saída
  • Controla execução e recursos

💥 Sem isso?
O programa COBOL nunca sai do papel.


🧩 ANALOGIA PODEROSA (GUARDA ISSO)

Pensa assim:

  • 🧠 COBOL = o chef que sabe cozinhar
  • 🎛️ JCL = o gerente da cozinha que liga o fogão, entrega ingredientes e organiza os pedidos

👉 Sem o chef → não tem comida
👉 Sem o gerente → ninguém cozinha


🚨 ERRO CLÁSSICO DE INICIANTE

Muita gente entra no mainframe achando:

“Vou aprender COBOL e pronto.”

❌ Errado.

Sem entender JCL você não sabe:

  • Submeter jobs
  • Controlar batch
  • Interpretar abends
  • Trabalhar com datasets
  • Entender fluxo real de produção

👉 Resultado?
Fica dependente de outros… ou perdido no spool.


🔥 O PONTO QUE SEPARA AMADOR DE PROFISSIONAL

Quem domina só COBOL:

  • escreve código

Quem domina COBOL + JCL:

  • entende o sistema inteiro

E aqui está o salto de carreira:

💣 Mainframe não é só programar. É orquestrar processamento.


📊 BATCH: ONDE TUDO ACONTECE

O JCL brilha principalmente no mundo batch:

  • Processamento noturno
  • Milhões de registros
  • Integração entre sistemas
  • Fechamentos financeiros

👉 É aqui que o mainframe mostra por que ainda domina o mundo.


🧠 RESUMO BELLACOSA (NA VEIA)

  • COBOL → o que fazer
  • JCL → como, quando e com o quê fazer

🔥 COBOL sem JCL é potencial.
JCL sem COBOL é vazio.
Juntos? Missão crítica rodando há décadas.


💬 REFLEXÃO FINAL

Se você quer realmente entrar no jogo do mainframe…

Não escolha entre COBOL e JCL.

Domine os dois.

Porque no mundo real:

  • O banco não quer só código
  • Ele quer processamento funcionando
  • Sem falha
  • Sem atraso
  • Sem desculpa

💣 FRASE PRA LEVAR PRA VIDA

“Quem escreve COBOL acha que manda.
Quem domina JCL sabe que manda.”

domingo, 19 de abril de 2026

💀 RONIN DO MAINFRAME: O CÓDIGO SEM SENHOR NO MUNDO CORPORATIVO

 

Bellacosa Mainframe fala sobre Ronins e Terceirização

💀 RONIN DO MAINFRAME: O CÓDIGO SEM SENHOR NO MUNDO CORPORATIVO

Existe um tipo de profissional que não pertence a lugar nenhum… mas é essencial em todos os lugares.
No Japão feudal, ele era chamado de ronin.
No mundo corporativo — especialmente no universo mainframe — ele atende por outro nome: o terceirizado de projeto.

E a semelhança vai muito além da estética.


⚔️ O QUE É UM RONIN, AFINAL?

A palavra ronin (浪人) significa literalmente “homem à deriva”.

No Japão feudal:

  • Era um samurai sem mestre (daimyō)
  • Perdia seu senhor por morte, desonra ou queda política
  • Ficava sem propósito fixo, sem renda e sem proteção

Mas não se engane…
Um ronin não era um fracasso.

Ele era, muitas vezes:

  • Extremamente habilidoso
  • Independente
  • Perigoso
  • E… livre demais para um sistema que exigia lealdade absoluta

💻 O RONIN DO MAINFRAME

Agora transporta isso para o nosso mundo…

O profissional que:

  • Entra em projetos críticos
  • Resolve o que ninguém resolve
  • Domina COBOL, JCL, CICS, DB2 como poucos
  • E… quando tudo estabiliza, é dispensado

Esse é o ronin corporativo.

Sem squad fixo.
Sem “casa”.
Sem pertencimento.

Mas com algo que poucos têm:
👉 capacidade de sobrevivência em qualquer ambiente hostil de TI


🔥 ANALOGIA DIRETA (SEM FILTRO)

Japão FeudalMainframe Corporativo
DaimyōCliente / Empresa
SamuraiFuncionário CLT
RoninTerceirizado
KatanaConhecimento técnico
Código de honra (Bushidō)Boas práticas, governança
SobrevivênciaAlocação em projetos

E aqui vem o ponto mais forte…

👉 O ronin não escolhe estabilidade.
👉 Ele escolhe movimento.


🧠 FILOSOFIA RONIN (QUE TODO DEV DEVERIA ENTENDER)

O ronin vive sob três regras não escritas:

1. 🧭 Você é sua própria reputação

Sem empresa para te “defender”, só existe:

  • Seu nome
  • Sua entrega
  • Seu histórico

No mainframe isso pesa ainda mais…
porque todo mundo se conhece.


2. ⚡ Aprender não é opcional

O ronin não tem zona de conforto.

Hoje é:

  • Batch noturno quebrando

Amanhã:

  • Problema em CICS com transação travando

Depois:

  • SQL de 1978 que ninguém entende

Se você não evolui… você desaparece.


3. 🏹 Desapego é sobrevivência

Terminou o projeto?

Você vai embora.

Sem despedida dramática.
Sem “vamos manter contato” que nunca acontece.

👉 Só o próximo desafio.


🏯 ORIGEM HISTÓRICA (CURIOSIDADE RAIZ)

Os ronin ficaram especialmente famosos após eventos como:

  • A era Tokugawa (1603–1868), quando guerras diminuíram
  • Muitos samurais ficaram sem função
  • Alguns viraram mercenários
  • Outros… professores, escritores ou até criminosos

O caso mais icônico:
👉 Os 47 Ronin

Um grupo que vingou seu mestre mesmo após anos — um dos maiores símbolos de lealdade da cultura japonesa.


🧩 EASTER EGGS QUE POUCA GENTE PERCEBE

  • 🔍 Muitos personagens de anime são “ronins modernos” (sem mestre, sem vínculo)
  • 💡 No mundo corporativo, o ronin é frequentemente o cara que “salva o legado”
  • ⚠️ Empresas dependem deles… mas raramente os valorizam corretamente
  • 🧠 O conhecimento deles é tácito, não documentado — um risco gigante

⚠️ O LADO SOMBRIO DO RONIN CORPORATIVO

Nem tudo é poesia.

Ser um ronin no mainframe também significa:

  • Falta de estabilidade
  • Pouco reconhecimento institucional
  • Desgaste constante
  • Necessidade de provar valor repetidamente

👉 É uma vida de guerra contínua.


🚀 O GRANDE PARADOXO

As empresas dizem querer:

  • Estabilidade
  • Padronização
  • Governança

Mas quando o sistema cai…

👉 Elas chamam o ronin.


☕ CONCLUSÃO ESTILO BELLACOSA

O ronin do mainframe não é só um profissional.

Ele é:

  • O cara que entra no caos
  • Entende código legado sem documentação
  • Resolve em silêncio
  • E desaparece antes dos aplausos

Enquanto muitos buscam conforto…

👉 O ronin busca relevância.

E no fundo, no fundo…

Todo ambiente crítico de mainframe sabe:

“Sem os ronins… muita coisa simplesmente pararia.”

 

quinta-feira, 26 de março de 2026

🧪 LABORATÓRIO — DO JCL AO JSON

 

Bellacosa Mainframe do jcl ao json laboratorio pratico

🧪 LABORATÓRIO — DO JCL AO JSON

🐍 Missão: Dominar dados reais com Python

👉 Formato: desafios práticos
👉 Nível: iniciante → intermediário
👉 Ideal para 1–2 dias de hands-on
👉 Pode virar curso ou workshop


🔹 BLOCO 1 — Arquivos (I/O)

🧩 Desafio 1 — Leitor de arquivo sequencial

Crie um programa que:

  • Leia clientes.txt
  • Mostre número total de linhas
  • Mostre a primeira e última linha

💡 Analog: processamento sequencial COBOL


🧩 Desafio 2 — Contador de registros válidos

Arquivo contém linhas vazias e comentários iniciados por #.

Conte apenas registros válidos.


🧩 Desafio 3 — Gerador de arquivo batch

Crie um arquivo relatorio.txt contendo:

  • Data/hora atual
  • Total de registros processados
  • Status “OK”

🧩 Desafio 4 — Conversor TXT → CSV

Entrada:

123;Ana;1200
456;João;950

Produza um CSV com cabeçalho.


🧩 Desafio 5 — Copiador com filtro

Copie transacoes.txt para aprovadas.txt
apenas registros com valor > 1000.


🔹 BLOCO 2 — Pandas (Dados tabulares)

🧩 Desafio 6 — Carregar dataset

Use Pandas para:

  • Ler um CSV
  • Mostrar as 5 primeiras linhas
  • Mostrar número de registros

🧩 Desafio 7 — Filtro de negócios

Mostre apenas clientes com saldo > 1000.

Ordene por saldo decrescente.


🧩 Desafio 8 — Estatísticas rápidas

Calcule:

  • Média do saldo
  • Máximo
  • Mínimo
  • Total

🧩 Desafio 9 — Agrupamento

Agrupe clientes por cidade e conte quantos há em cada uma.

💡 Similar a GROUP BY


🧩 Desafio 10 — Pipeline batch moderno

Leia um CSV → filtre → salve novo CSV com resultados.


🔹 BLOCO 3 — NumPy (Processamento numérico)

🧩 Desafio 11 — Operações vetoriais

Crie dois arrays e calcule:

  • Soma elemento a elemento
  • Produto elemento a elemento
  • Produto escalar

🧩 Desafio 12 — Matriz de desempenho

Simule vendas por região:

  • Matriz 3×4
  • Calcule totais por linha e coluna

🔹 BLOCO 4 — APIs (Integração moderna)

🧩 Desafio 13 — Consumidor de API

Use uma API pública (ex.: cotação de moedas).

Exiba:

  • Valor atual
  • Data/hora
  • Fonte

💡 Biblioteca: requests


🧩 Desafio 14 — API → DataFrame

Obtenha dados JSON de uma API e:

  • Converta para Pandas
  • Mostre estatísticas
  • Salve em CSV

🔹 BLOCO 5 — Web Scraping

🧩 Desafio 15 — Minerador de dados web

Extraia dados de uma página pública:

  • Títulos de notícias OU
  • Tabela da Wikipedia

Salve em arquivo estruturado.

💡 Bibliotecas:

requests
BeautifulSoup
pandas.read_html()

🏆 DESAFIO EXTRA (Modo Arquitetura)

🔥 Mega-missão — Pipeline completo

Construa um fluxo:

👉 Coletar dados de API
👉 Complementar com dados de arquivo local
👉 Processar com Pandas
👉 Salvar resultado final

💥 Isso simula um ETL moderno.


🎯 O que você dominará ao concluir

✔ Manipulação de arquivos
✔ Processamento tabular
✔ Computação numérica
✔ Integração com sistemas externos
✔ Coleta de dados da web
✔ Data pipelines
✔ Base para Data Science


🚀 Tradução para linguagem mainframe

Arquivos → Dataset sequencial

Pandas → DB2 em memória

NumPy → cálculo científico

APIs → integração online

Scraping → coleta automática