Bellacosa Mainframe comenta o dia que previram a morte do Morte, disparates de Steven Alsop em 1993

O dia em que decretaram a morte do mainframe

Vagner Bellacosa

IBM Champion | Mainframe Evangelist & Educator | System Analyst – COBOL, PL/I, DB2, CICS

February 19, 2026

Salve jovem padawan, ouve um dia que resolveram matar o Mainframe e ainda futurolicamente ao estilo Mãe Dinah, dera a data prevista da morte, foi aquela explosão nos meios de comunicações jornais e revistas dos 4 cantos do globo, repetiram e republicaram o artigo e no fim....

Por isso jovem padawan, tenha cuidado com Buzzword, hype, pessoal maluco de marketing e consultores que ganham comissão. Antes de defender uma ideia, advogar uma stack, estude, leia se informe, para não pagar micos historicos estilo Alsop.

Virou meme

(E a sopa de letrinhas que veio depois…)

Em 8 de março de 1993, o jornalista Stewart Alsop publicou um artigo com um título provocativo:

“IBM still has the brains to be a player in client/server platforms”

No meio do texto, uma frase ficou marcada na história da tecnologia:

“Eu acredito que ainda há sinais de vida inteligente dentro da IBM.”

Naquele momento, o mercado estava em êxtase com client/server. O discurso dominante era claro:

• O mainframe é caro
• O mainframe é legado
• O futuro é distribuído
• O dinossauro vai morrer

E a IBM?**

Estava sendo pressionada, questionada e subestimada.

---

📉 O clima da época

Era o início dos anos 90.

• Unix crescendo
• Servidores departamentais surgindo
• PCs ficando mais poderosos
• A arquitetura centralizada sendo chamada de “ultrapassada”

Especialistas previam que o último mainframe seria desligado em poucos anos.

Sim.

Havia previsão com data.

O fim era “inevitável”.

---

🧠 O que quase ninguém percebeu

Enquanto o mercado falava em “morte”…

A IBM estava:

• Reformulando arquitetura
• Investindo em sistemas distribuídos
• Explorando microkernel
• Trabalhando com orientação a objetos
• Pensando integração corporativa

Ela não estava parada.

Estava se reinventando.

---

🍲 A famosa sopa de letrinhas

Comendo as proprias palavras

https://youtube.com/shorts/Pqo4JrnYc3Q

Anos depois, a história cobrou seu preço.

Stewart Alsop acabou se aposentando — mas antes disso, foi confrontado com suas previsões equivocadas.

O que aconteceu?

Ele precisou fazer uma fotografia histórica comendo uma sopa de letrinhas, simbolicamente “engolindo suas palavras” por ter decretado o fim do mainframe.

A imagem virou um marco.

Um lembrete eterno de que previsões tecnológicas costumam envelhecer mal.

---

📈 O que aconteceu depois?

O mainframe não morreu.

Em 2003 Steven Alsop ja aposentado foi obrigado a se retratar e comer as proprias palavras

Ele:

• Downsize virou poeira
• Rightsize derrapou na curva
• Y2K libertou os reptlianos
• Absorveu o modelo client/server
• Tornou-se backbone da internet banking
• Sustentou e-commerce global
• Veio a Cloud
• Veio o Green Mainframe
• Evoluiu para Linux on Z
• Entrou na era da criptografia massiva
• Incorporou IA embarcada em hardware

Enquanto muitas empresas que apostaram no “fim do mainframe” desapareceram…

O mainframe continuou processando trilhões de dólares por dia.

Silenciosamente.

---

🎯 A grande lição

O problema nunca foi a tecnologia.

Foi a narrativa.

Toda década alguém decreta:

• O fim do mainframe
• O fim do COBOL
• O fim do z/OS
• O fim do processamento centralizado

E toda década o mainframe responde da mesma forma:

Com disponibilidade. Com segurança. Com escala. Com resultado.

---

☕ Reflexão final

O episódio da sopa de letrinhas não é sobre constranger um jornalista.

É sobre lembrar que:

Tecnologia corporativa não é moda. É missão crítica.

E missão crítica não morre por tendência de mercado.

Ela evolui.

---

Se você é profissional de tecnologia, pergunte-se:

Você está seguindo o hype… Ou está entendendo arquitetura?

Porque enquanto o hype muda a cada cinco anos, o mainframe continua sustentando o sistema financeiro do planeta.

E isso não é previsão.

É fato histórico.

---

#Mainframe #IBM #Arquitetura #Tecnologia #HistóriaDaTI #BellacosaMainframe

Comments

Add a comment…

O dia em que decretaram morte do Mainframe — Vagner Bellacosa

Leia no LinkedIn — Uma reflexão sobre mainframes, tecnologia e memória cultural…

linkedin.com

 

Bellacosa Mainframe apresenta a biblioteca matematica do Python

🔥 NumPy: O “PACKED DECIMAL” do Python que Vai Explodir sua Cabeça COBOL

Se você veio do mundo COBOL, onde cada byte importa, cada campo tem propósito e cada processamento precisa ser eficiente… então prepare-se: você está prestes a conhecer o coração matemático do Python — a biblioteca NumPy.

E sim… ela é MUITO mais próxima do seu mundo do que você imagina.

---

☕ O choque de realidade: Python puro vs processamento “mainframe-like”

No COBOL, você já sabe:

• COMPUTE é rápido
• PERFORM VARYING é controlado
• Estruturas são previsíveis

Agora veja isso no Python “cru”:

lista = [1, 2, 3, 4]
resultado = [x * 2 for x in lista]

Funciona… mas não é exatamente eficiente nível mainframe, certo?

Agora entra o NumPy:

import numpy as np

array = np.array([1, 2, 3, 4])
resultado = array * 2

💥 BOOM.

Você acabou de fazer processamento vetorial, algo muito mais próximo de um:

“loop implícito otimizado em assembler por baixo dos panos”

Sim… isso cheira a z/Architecture.

---

🧠 Origem: quando cientistas reinventaram o “processamento batch”

O NumPy nasceu oficialmente em 2006, mas sua raiz vem de duas bibliotecas:

• Numeric
• Numarray

Ambas criadas para resolver um problema clássico:

“Python era bom… mas lento para matemática pesada”

A fusão virou NumPy — e trouxe um conceito poderoso:

👉 Arrays homogêneos de alta performance

Se você pensa em:

• tabelas VSAM
• buffers de memória
• áreas de trabalho

Você já entendeu metade do NumPy.

---

⚙️ O conceito que muda tudo: ndarray

O coração do NumPy é o ndarray (N-dimensional array).

Pense nisso como:

COBOL	NumPy
OCCURS	array
PIC 9(5)V99	dtype=float64
Tabela indexada	ndarray
Área contígua memória	buffer otimizado

Exemplo:

import numpy as np

dados = np.array([10, 20, 30])
print(dados * 2)

Saída:

[20 40 60]

Sem loop explícito. Sem PERFORM.

👉 Isso é chamado de vectorization.

---

🚀 Performance: aqui mora o espírito do mainframe

NumPy é rápido porque:

• Escrito em C (baixo nível)
• Usa operações vetorizadas
• Evita overhead de loops Python

📌 Tradução para o mundo COBOL:

“Você está rodando um SORT interno com exit em assembler… sem escrever assembler.”

---

🔍 Curiosidades que todo coboleiro vai amar

🧩 1. NumPy evita loops como você evita GO TO

Loops em Python são lentos.

NumPy resolve isso com operações vetoriais:

a = np.array([1,2,3])
b = np.array([4,5,6])

print(a + b)

Resultado:

[5 7 9]

👉 Isso é equivalente a um loop automático altamente otimizado.

---

🧠 2. Broadcasting: o PERFORM invisível

a = np.array([1,2,3])
print(a + 10)

Resultado:

[11 12 13]

Sem loop. Sem stress.

👉 O NumPy “espalha” o valor automaticamente.

---

🏎️ 3. Memória contígua = performance absurda

Diferente de listas Python, NumPy usa:

• memória contínua
• tipos fixos

👉 Isso lembra:

• buffers de I/O
• áreas de WORKING-STORAGE bem definidas

---

🧪 Exemplos práticos (modo COBOL mindset ON)

📊 Soma de um dataset

COBOL:

PERFORM VARYING I FROM 1 BY 1 UNTIL I > 100
   ADD VALOR(I) TO TOTAL
END-PERFORM

NumPy:

np.sum(array)

💥 1 linha. Otimizado. Vetorizado.

---

📈 Média (sem reinventar roda)

np.mean(array)

👉 Nada de controle manual. Nada de variáveis acumuladoras.

---

🔄 Transformação em massa

array * 1.15

👉 Isso é literalmente um:

“REDEFINES aplicado em lote com COMPUTE automático”

---

🧠 Easter Eggs e detalhes escondidos

🥚 1. O tipo float64 é padrão

👉 Isso significa precisão alta — quase como trabalhar com campos bem definidos no COBOL financeiro.

---

🥚 2. Você pode acessar o “layout de memória”

array.strides

👉 Sim… você pode ver como os dados estão distribuídos na memória.

Isso é nível:

“debug de storage layout no mainframe”

---

🥚 3. NumPy conversa com C diretamente

👉 Isso permite integrar com código de baixo nível.

Ou seja:

Python vira quase um “COBOL com superpoderes científicos”

---

⚔️ NumPy vs Python puro (visão mainframe)

Aspecto	Python puro	NumPy
Performance	Baixa	Altíssima
Tipagem	Dinâmica	Estática (dtype)
Memória	Fragmentada	Contígua
Loop	Manual	Vetorizado
Estilo	Script	Científico / batch-like

---

🌍 Onde isso entra na sua evolução?

Se você domina COBOL, NumPy é uma ponte natural para:

• 📊 Data Science
• 🤖 Machine Learning
• 📈 Analytics de alto volume
• 🧮 Simulações financeiras

E mais importante:

👉 Você não começa do zero
👉 Você reaproveita seu mindset de performance

---

🎯 Conclusão: o despertar do coboleiro moderno

NumPy não é só uma biblioteca.

É uma mudança de paradigma.

É quando você percebe que:

“O Python pode ser tão performático quanto um batch bem escrito — se você usar as ferramentas certas.”

E aqui vai a provocação final:

🔥 Se COBOL é o rei do processamento estruturado…
🔥 NumPy é o motor matemático que pode levar você além do mainframe.