Bellacosa Mainframe e o downsize dos anos 1990
☕ Um Café no Bellacosa Mainframe
🧙♂️ O EX-PROGRAMADOR E A DUNGEON DO DOWNSIZING — QUANDO TRÊS 386 ENFRENTARAM UM IBM 4341
IBM 4341, COBOL, CICS, VSAM, 3278, NetWare, Clipper, DOS, cliente-servidor, TCO, migração — e o dia em que um ex-programador entrou em outro mundo com um laptop e descobriu que trocar o mainframe por 98 PCs não fazia os problemas desaparecerem.
Sob a tutela de A Former Programmer Enters Another World and Uses a Laptop to Hack S-Rank Mage Skills
🎬 PRÓLOGO — O EX-PROGRAMADOR ACORDOU EM 1990
O ex-programador abriu os olhos.
Não havia Wi-Fi.
Não havia GitHub.
Não havia Stack Overflow.
Não havia Docker.
Não havia Kubernetes.
Não havia Cloud.
Não havia sequer uma tomada USB onde carregar seu misterioso laptop vindo de outro mundo.
Na parede havia um terminal.
Ele olhou para o teclado.
IBM 3278.
— Onde estou?
Um analista aproximou-se carregando uma listagem COBOL de aproximadamente quatro centímetros de espessura.
— No Banco Inter-Atlântico.
— Em que ano?
— 1990.
O programador olhou novamente para o terminal.
— E onde está o computador?
O analista apontou para outra sala.
— Lá.
Era um IBM 4341.
Nosso aventureiro sorriu.
Finalmente reconhecia alguma coisa naquele mundo.
Mas então apareceu o diretor da guilda.
— Temos uma missão S-Rank.
— Qual?
— Vamos aposentar o mainframe.
Silêncio.
O programador fechou lentamente seu laptop.
A dungeon acabara de começar.
🏰 CAPÍTULO 1 — QUANDO O COMPUTADOR ERA O CASTELO
Para um programador COBOL iniciante entender o downsizing, primeiro precisa compreender como funcionava grande parte da computação empresarial antes da popularização dos PCs.
Imagine um castelo.
Dentro dele estão os recursos mais importantes do reino:
CPU;
memória;
discos;
aplicações;
arquivos;
processamento transacional;
segurança;
operação.
Esse castelo é o mainframe.
Os usuários não carregavam pequenos castelos consigo.
Eles possuíam terminais.
Podemos simplificar a arquitetura assim:
+-------------------+
| IBM 4341 |
| |
| COBOL CICS VSAM |
+---------+---------+
|
Controladores
|
+------------+------------+
| | |
3278 3278 3278
O terminal IBM 3278 não era equivalente ao PC moderno.
Ele servia principalmente como interface entre o usuário e o sistema central.
O processamento importante acontecia no ambiente central.
Isso nos leva ao primeiro conceito.
Centralização
Na arquitetura centralizada, grande parte da capacidade computacional encontra-se concentrada.
O usuário diz:
“Quero consultar a conta 12345.”
O terminal transmite a solicitação.
CICS recebe a transação.
Um programa COBOL é acionado.
O programa acessa VSAM.
O resultado retorna.
Conceitualmente:
3278
|
v
CICS
|
v
COBOL
|
v
VSAM
|
v
COBOL
|
v
CICS
|
v
3278
Para quem está começando em COBOL, guarde esse desenho.
Ele explica uma quantidade enorme da arquitetura clássica de aplicações comerciais.
⚔️ CAPÍTULO 2 — COBOL, CICS E VSAM: OS TRÊS MAGOS DO CASTELO
O relato do Banco Inter-Atlântico menciona três tecnologias importantíssimas:
COBOL, CICS e VSAM.
Elas não são a mesma coisa.
COBOL
COBOL é a linguagem na qual podemos escrever a lógica de negócio.
Por exemplo:
IF SALDO-CONTA >= VALOR-SAQUE
SUBTRACT VALOR-SAQUE
FROM SALDO-CONTA
ELSE
MOVE 'SALDO INSUFICIENTE'
TO MENSAGEM
END-IF.
A regra é:
somente autorize o saque quando houver saldo suficiente.
COBOL representa a lógica.
CICS
CICS é um monitor de processamento transacional.
Imagine centenas ou milhares de usuários realizando:
consulta
depósito
saque
transferência
alteração cadastral
pagamento
simultaneamente.
Precisamos administrar essas transações.
É aí que entra o CICS.
Em uma analogia de RPG:
COBOL é o guerreiro.
VSAM é o inventário.
CICS é o mestre da dungeon coordenando quem pode fazer o quê e quando.
VSAM
VSAM fornece estruturas de armazenamento de dados muito utilizadas em sistemas mainframe.
Um programador iniciante provavelmente encontrará siglas como:
KSDS
ESDS
RRDS
LDS
Um KSDS, por exemplo, permite acessar registros através de chave.
Imagine:
000001 | MARIA | 1500.00
000002 | JOAO | 3270.00
000003 | ANA | 4341.00
Você fornece a chave:
000002
e procura o registro correspondente.
Portanto, quando o texto diz:
COBOL/CICS e VSAM
não está simplesmente despejando três siglas.
Está descrevendo boa parte de uma arquitetura transacional.
🧟 CAPÍTULO 3 — O MONSTRO NÃO ERA NECESSARIAMENTE O MAINFRAME
O Banco Inter-Atlântico enfrentava problemas.
Entre eles:
sistemas obsoletos;
analistas consumidos por manutenção;
usuários insatisfeitos;
upgrades caros.
É extremamente tentador concluir:
“O IBM 4341 era o problema.”
Nosso ex-programador levantaria a mão imediatamente.
— Prova?
Silêncio na War Room.
Essa pergunta é fundamental.
Porque:
HARDWARE ANTIGO
≠
SOFTWARE RUIM
≠
PROCESSO RUIM
≠
ARQUITETURA RUIM
≠
DÍVIDA TÉCNICA
Eles podem coexistir.
Mas não são sinônimos.
Imagine este código:
IF WS-TIPO = 'A'
PERFORM 7000-ROTINA-ANTIGA
ELSE
IF WS-TIPO = 'B'
PERFORM 7100-ROTINA-NOVA
ELSE
PERFORM 7999-TRATAMENTO
END-IF
END-IF.
Perguntamos:
Por que clientes A utilizam a rotina antiga?
Resposta:
— Ninguém sabe.
Quem escreveu?
— Almeida.
Onde está Almeida?
— Saiu da empresa em 1987.
Existe documentação?
— Talvez no armário do terceiro andar.
Trocar o IBM 4341 por PCs não explica a regra.
Apenas transporta o mistério para outra plataforma.
Easter egg #1
Se encontrar no fonte:
0317-ROTINA-ESPECIAL.
não mexa antes de descobrir por quê.
Às 03:17, produção sempre cobra juros.
🖥️ CAPÍTULO 4 — SURGE UMA NOVA MAGIA: DOWNSIZING
No final dos anos 1980 e começo dos anos 1990, microcomputadores tornavam-se cada vez mais poderosos.
O raciocínio parecia irresistível.
Se um computador enorme custa muito e vários computadores pequenos custam pouco, por que não substituir o grande pelos pequenos?
Nascia a febre do:
DOWNSIZING
Não significa simplesmente:
“comprar computadores menores.”
Significa transferir workloads que antes dependiam de plataformas maiores e centralizadas para plataformas menores, frequentemente distribuídas.
A transformação conceitual era:
ANTES
Terminal
|
Mainframe
|
Aplicação
|
Dados
para algo parecido com:
DEPOIS
PC ----\
PC -----+---- Rede ---- Servidor
PC ----/ |
Dados
Isso é uma mudança arquitetural profunda.
O PC não é mais apenas uma janela.
Ele possui:
CPU;
RAM;
armazenamento;
sistema operacional;
programas;
capacidade de processamento local.
A inteligência começa a se espalhar.
💰 CAPÍTULO 5 — "CEM VEZES MAIS BARATO!"
O vendedor entrou na dungeon.
— Tenho uma magia capaz de reduzir o custo de processamento em até cem vezes!
Nosso ex-programador cruzou os braços.
— Qual custo?
O vendedor hesitou.
E aí encontramos uma das maiores lições do caso.
Preço de hardware não é necessariamente o mesmo que:
TCO — TOTAL COST OF OWNERSHIP
Ou Custo Total de Propriedade.
Você pode comparar:
IBM 4341
versus
386 SX
e descobrir enorme vantagem de preço para o pequeno computador.
Mas a empresa não estava adquirindo simplesmente um 386.
O ambiente terminou com:
3 servidores 386 SX
98 micros entre XT e 386 SX
2 GB de armazenamento
rede
software
suporte
Agora existem dezenas de equipamentos para administrar.
Cada PC pode precisar de:
instalação
configuração
backup
suporte
manutenção
placa de rede
sistema operacional
aplicativos
atualizações
Surge então uma verdade clássica da computação distribuída:
O custo não desaparece necessariamente. Parte dele muda de lugar.
🧙 CAPÍTULO 6 — NASCE O MAGO DO SUPORTE DE DESKTOP
No mundo 3270, o usuário possuía uma interface relativamente controlada.
Com dezenas de PCs aparecem novas aventuras:
— Meu AUTOEXEC.BAT não funciona!
— Minha placa de rede sumiu!
— Não consigo mapear o drive!
— Meu CONFIG.SYS está diferente!
— O aplicativo funciona no computador do João!
— O disquete trouxe um vírus!
— Minha impressora não imprime!
— Alguém apagou o arquivo!
Bem-vindo à computação distribuída.
Você reduziu determinado tipo de centralização.
Em compensação, criou dezenas de novos pontos que precisam ser administrados.
Esse princípio permanece válido em 2026.
Troque:
PC
por:
container
microservice
VM
pod
endpoint
cloud account
e perceberá que o problema continua reconhecível.
Distribuir processamento também significa distribuir complexidade.
🌐 CAPÍTULO 7 — NETWARE: A ESTRADA ENTRE AS VILAS
O banco adotou Novell NetWare 386.
Para entender sua importância, imagine dezenas de PCs isolados:
PC PC PC PC
Eles são ilhas.
Uma LAN cria estradas:
PC \
PC \
PC --- REDE --- SERVIDOR
PC /
PC /
O servidor pode centralizar recursos como:
arquivos
diretórios
aplicações
impressoras
autenticação
NetWare tornou-se extremamente importante nesse período.
Era a infraestrutura que permitia transformar um conjunto de PCs em um ambiente corporativo conectado.
🔌 CAPÍTULO 8 — A REDE TAMBÉM PRECISA DE ARQUITETURA
Uma recomendação do relato parece banal:
“Planejar a rede antes de instalar.”
Não é banal.
Você precisa pensar em:
topologia
cabeamento
servidores
protocolos
capacidade
distância
crescimento
backup
segurança
impressão
falhas
Até a instalação elétrica entra na arquitetura.
Antes:
CPD
|
infraestrutura especializada
|
IBM
Agora:
Sala 1 → PCs
Sala 2 → PCs
Sala 3 → PCs
Gerência → PCs
Operações → PCs
Servidores → outra sala
Computação distribuída significa também distribuir:
energia, cabeamento e pontos de falha.
Não basta comprar 98 computadores e gritar:
“Transformação digital!”
💾 CAPÍTULO 9 — 2 GB ERA MUITA COISA
O jovem aventureiro de 2026 abriu seu laptop.
— Dois gigabytes? Meu celular usa isso para...
O mago interrompeu:
— Estamos em 1991.
Esse contexto é essencial.
Suponha registros comerciais com aproximadamente 200 bytes.
Um milhão deles representaria aproximadamente:
200 × 1.000.000
=
200.000.000 bytes
aproximadamente 200 MB em uma conta simplificada.
Dois gigabytes podiam armazenar enorme quantidade de dados estruturados daquela época.
Isso ensina algo importante:
Nunca avalie uma arquitetura histórica usando apenas os padrões de consumo atuais.
Um arquivo VSAM com milhões de registros comerciais pode representar enorme valor empresarial sem possuir terabytes.
Valor do dado não é proporcional ao tamanho do arquivo.
🧰 CAPÍTULO 10 — CLIPPER ENTRA NA GUILDA
Outro nome importante no relato é Clipper.
Clipper tornou-se muito conhecido no desenvolvimento de aplicações comerciais para microcomputadores.
Era comum trabalhar com estruturas como:
CLIENTES.DBF
CONTAS.DBF
MOVIMENTO.DBF
Para alguém vindo de ambientes mais centralizados, desenvolver diretamente no PC podia produzir uma enorme sensação de liberdade.
O ciclo podia parecer:
EDITAR
↓
COMPILAR
↓
EXECUTAR
↓
TESTAR
↓
CORRIGIR
Tudo perto do desenvolvedor.
Compare isso mentalmente com processos centralizados de desenvolvimento, compilação e implantação.
Não é difícil compreender por que os micros eram vistos como libertadores.
🪟 CAPÍTULO 11 — POR QUE DOS E NÃO UMA INTERFACE GRÁFICA?
Aqui existe uma decisão arquitetural muito interessante.
O banco tinha pressa.
Tempo era crítico.
Então escolheu DOS em vez de perseguir imediatamente um ambiente gráfico.
Para o arquiteto moderno, isso ensina:
Não escolha uma tecnologia simplesmente porque ela parece mais moderna. Escolha-a porque atende aos requisitos.
GUI poderia significar:
mais memória
hardware melhor
novo treinamento
novas ferramentas
maior complexidade
DOS já era conhecido e leve.
O objetivo era migrar.
Não ganhar um concurso de interface.
📦 CAPÍTULO 12 — O VERDADEIRO FEITIÇO TALVEZ TENHA SIDO O PACOTE
Existe uma frase no caso que merece enorme atenção:
“adotar pacotes prontos no lugar de desenvolvimento interno.”
Isso significa que duas variáveis foram modificadas simultaneamente.
Antes:
MAINFRAME
+
SOFTWARE DESENVOLVIDO INTERNAMENTE
Depois:
MICROS/SERVIDORES
+
PACOTES
Agora alguém anuncia:
“Nossa produtividade aumentou porque abandonamos o mainframe!”
Nosso aventureiro responde:
— Como você provou isso?
Talvez a produtividade tenha aumentado porque:
houve menos desenvolvimento interno;
processos foram padronizados;
interfaces melhoraram;
aplicações antigas foram eliminadas;
regras foram simplificadas;
hardware tornou-se mais barato;
usuários ganharam autonomia.
Provavelmente houve contribuição de várias dessas coisas.
Arquitetura séria exige cuidado com causalidade.
👨💻 CAPÍTULO 13 — O CHEFÃO FINAL ERA HUMANO
O relato diz algo extraordinariamente moderno:
O maior impasse eram as pessoas.
Eis o verdadeiro S-Rank.
Não IBM.
Não COBOL.
Não CICS.
Não NetWare.
Pessoas.
Imagine um analista que passou dez anos aprendendo:
COBOL
CICS
VSAM
3270
produção
regras bancárias
Agora o diretor anuncia:
“Vamos substituir tudo.”
O analista pode ouvir algo completamente diferente:
“Tudo aquilo que você aprendeu não vale mais.”
Isso cria:
medo
resistência
insegurança
territorialismo
desmotivação
Por isso o relato enfatizava:
apoio da alta administração;
treinamento;
motivação;
comunicação da nova cultura;
cronogramas realistas.
Cloud, DevOps e IA continuam tropeçando exatamente nessa dungeon.
🗺️ CAPÍTULO 14 — COMO MIGRAR SEM EXPLODIR O REINO
O IBM 4341 não foi simplesmente desligado.
A migração durou 14 meses, segundo o relato.
Essa é uma pista importantíssima.
Provavelmente existiu alguma forma de coexistência entre ambientes.
Didaticamente podemos imaginar:
FASE 1
IBM 4341
COBOL/CICS/VSAM
████████████████████
NOVO
██
Depois:
FASE 2
IBM
████████████
NOVO
████████
Depois:
FASE 3
IBM
████
NOVO
████████████████
Finalmente, em julho de 1991:
IBM
OFF
NOVO AMBIENTE
████████████████████
Essa estratégia reduz o risco do temido:
BIG BANG
O Big Bang seria:
SEXTA 18:00
IBM OFF
e:
SEGUNDA 08:00
NOVO SISTEMA ON
seguido, eventualmente, por:
SEGUNDA 08:07
WAR ROOM
E, por alguma razão inexplicável:
03:17
continua sendo o horário em que tudo resolve quebrar.
Easter egg localizado. ☕
🧪 CAPÍTULO 15 — COMO EU AUDITARIA ESSA MIGRAÇÃO
Nosso ex-programador abre seu laptop.
Não vai começar copiando arquivos.
Primeiro criará um inventário.
Passo 1 — Aplicações
Sistema
Programa
Função
Usuários
Criticidade
Dependências
Passo 2 — COBOL
Catalogar:
programas
subprogramas
copybooks
interfaces
regras especiais
Passo 3 — CICS
Identificar:
transactions
programas associados
arquivos
dependências
fluxos
Passo 4 — VSAM
Catalogar:
KSDS
ESDS
RRDS
chaves
layouts
volumetria
retenção
Passo 5 — Batch
Não esqueça do batch!
Um erro clássico seria migrar apenas aquilo que o usuário vê.
O usuário vê:
TELA
mas atrás dela podem existir:
JCL
SORT
COBOL batch
arquivos
fechamentos
relatórios
conciliações
A interface é apenas a porta da dungeon.
💰 CAPÍTULO 16 — MIGRAR DINHEIRO EXIGE RECONCILIAÇÃO
Agora chegamos ao ponto mais importante para um banco.
Imagine o mainframe dizendo:
TOTAL CONTAS:
R$ 10.000.000
Depois da migração:
NOVO SISTEMA:
R$ 9.997.413
Alguém pergunta:
— Migração concluída?
Não.
Você precisa provar que os dados mantiveram:
quantidade
valor
identidade
relacionamentos
significado
Isso é reconciliação.
Podemos criar controles como:
ANTES
1.000.000 registros
DEPOIS
1.000.000 registros
Mas quantidade sozinha não basta.
Precisamos verificar também:
soma de saldos
soma de movimentos
quantidade por categoria
hashes
amostragens
totais de controle
exceções
Em sistemas financeiros:
Mover o dado não basta. É necessário demonstrar que seu significado sobreviveu à viagem.
🏦 CAPÍTULO 17 — MAS ERA UM BANCO!
Isso torna tudo mais sério.
Aplicações bancárias precisam considerar:
integridade
consistência
segurança
concorrência
auditoria
disponibilidade
recuperação
backup
transações
Suponha:
Conta A = 1000
Conta B = 500
Transferência:
A → B = 200
Precisamos terminar com:
A = 800
B = 700
Não podemos aceitar:
A = 800
B = 500
porque o sistema caiu no meio.
Nem:
A = 1000
B = 700
Senão acabamos de criar dinheiro.
É por isso que processamento transacional não pode ser reduzido à pergunta:
“Qual computador é mais rápido?”
Existem propriedades muito mais importantes.
⚖️ CAPÍTULO 18 — MAINFRAME CONTRA PC É A PERGUNTA ERRADA
Um iniciante frequentemente procura respostas absolutas:
Mainframe é melhor?
Cloud é melhor?
Microservices são melhores?
PC é melhor?
A arquitetura responde:
Depende do workload.
Considere:
volume
transações
latência
segurança
disponibilidade
custo
crescimento
equipe
software
integração
regulação
Então:
WORKLOAD
+
REQUISITOS
+
RISCOS
+
CUSTOS
+
PESSOAS
=
ARQUITETURA ADEQUADA
O Banco Inter-Atlântico possuía apenas 25 terminais 3278 no ambiente descrito.
Talvez uma infraestrutura menor realmente oferecesse excelente relação custo-benefício.
Isso não demonstra universalmente:
PC > MAINFRAME
Da mesma maneira que uma grande instalação financeira não demonstra:
MAINFRAME > TUDO
Arquitetura não é torcida de futebol.
🔄 CAPÍTULO 19 — E ENTÃO O PÊNDULO VOLTOU
Agora vem a ironia histórica.
Durante décadas fizemos:
MAINFRAME
|
TERMINAL
Depois:
PC
|
SERVIDOR
Depois:
BROWSER
|
WEB SERVER
|
DATABASE
Depois:
SMARTPHONE
|
INTERNET
|
CLOUD
E hoje temos:
NOTEBOOK
|
HTTPS
|
API
|
LOAD BALANCER
|
CONTAINER
|
DATABASE
Nosso ex-programador olha para isso.
Depois olha para:
3278
|
CICS
|
COBOL
|
VSAM
E sorri.
Não são arquiteturas tecnicamente equivalentes.
Mas existe uma ironia conceitual deliciosa.
O usuário continua muitas vezes diante de uma interface local que depende de recursos computacionais remotos.
☁️ CAPÍTULO 20 — CLOUD NÃO É UM MAINFRAME GIGANTE, MAS...
Precisamos evitar uma simplificação enganosa.
Cloud não é mainframe.
As arquiteturas, modelos operacionais, virtualização, redes, elasticidade, software e economia são diferentes.
Mas existe uma semelhança econômica interessante:
recursos caros são concentrados e compartilhados.
No passado:
Muitos usuários
↓
MAINFRAME
Hoje:
Milhões de clientes
↓
DATACENTERS / CLOUD REGIONS
Portanto, depois de décadas celebrando a descentralização, construímos alguns dos maiores centros de processamento da história humana.
O pêndulo não voltou ao mesmo lugar.
Mas voltou a passar perto.
👻 CAPÍTULO 21 — O MAINFRAME NÃO MORREU
Durante os anos do downsizing, era fácil imaginar:
“Mais alguns anos e ninguém precisará dessas máquinas.”
Isso não aconteceu.
O que realmente perdeu força foi outra ideia:
todo processamento empresarial precisa morar no mainframe.
Essa ideia realmente foi derrotada.
Passamos a construir ambientes híbridos:
MAINFRAME
|
+---- API
|
+---- MQ
|
+---- Kafka
|
+---- Cloud
|
+---- Mobile
|
+---- Analytics
|
+---- IA
O mainframe deixa de precisar representar:
“toda a computação da empresa”
e pode representar:
“um motor especializado dentro de um ecossistema maior.”
Essa diferença é fundamental.
🧠 CAPÍTULO 22 — DOWNSIZING, CLOUD E IA ENSINAM A MESMA LIÇÃO
1991:
“Vamos abandonar o mainframe porque micros são mais baratos.”
2015:
“Vamos colocar tudo na cloud porque será mais barato.”
2026:
“Vamos colocar IA em tudo porque aumentará a produtividade.”
Nosso aventureiro pergunta nas três ocasiões:
— Você mediu?
Essa talvez seja a maior skill S-Rank de arquitetura.
Não acreditar cegamente.
Medir.
Para downsizing:
TCO
disponibilidade
produtividade
suporte
incidentes
tempo de resposta
Para cloud:
compute
storage
network
egress
observabilidade
operações
licenciamento
Para IA:
qualidade
tempo economizado
erros
revisão humana
tokens
risco
governança
Tecnologia nova não elimina engenharia.
🧙 CAPÍTULO 23 — AS DEZ REGRAS DO EX-PROGRAMADOR
Antes de abandonar a dungeon, nosso aventureiro deixou dez regras escritas na parede:
Nunca confunda hardware antigo com arquitetura ruim.
Nunca confunda hardware barato com operação barata.
Descubra o workload antes de escolher a plataforma.
Inventarie antes de migrar.
Entenda as regras de negócio escondidas no COBOL.
Não esqueça batch, interfaces e arquivos.
Reconcilie os dados depois da migração.
Planeje coexistência e rollback.
Treine as pessoas antes de culpá-las pela resistência.
Meça o resultado antes de declarar vitória.
Depois acrescentou uma décima primeira:
Se alguém disser que uma nova tecnologia vai resolver todos os problemas, verifique primeiro se ele está vendendo essa tecnologia.
🥚 EASTER EGG — O PROGRAMA COBOL ESQUECIDO
Trinta e cinco anos depois, um jovem desenvolvedor encontra um programa antigo:
IDENTIFICATION DIVISION.
PROGRAM-ID. BIA0317.
*--------------------------------------------*
* BANCO INTER-ATLANTICO
* NAO REMOVER SEM CONSULTAR OPERACOES
* MIGRACAO - 1991
*--------------------------------------------*
PROCEDURE DIVISION.
DISPLAY 'HELLO, OTHER WORLD'.
STOP RUN.
Ele abre um chamado:
“Alguém sabe por que isso ainda existe?”
Um veterano responde:
“Não mexa.”
— Por quê?
— Ninguém sabe.
O ciclo está completo.
☕ EPÍLOGO — ACREDITE SE QUISER!
Em julho de 1991, segundo o relato histórico, o IBM 4341 foi finalmente desativado depois de aproximadamente 14 meses de migração.
No lugar daquele ambiente centralizado havia redes NetWare, três servidores 386 SX e quase uma centena de micros.
Os usuários estavam mais satisfeitos.
O custo teria diminuído.
A expansão continuava.
E o autor da época encerrou praticamente piscando para o leitor:
“Acredite se quiser!”
Décadas depois, aquela frase ficou ainda melhor.
Porque o mais extraordinário não é que pequenos computadores tenham conseguido substituir aquele IBM em determinado banco.
O extraordinário é perceber que a história não terminou ali.
Depois do downsizing vieram:
cliente-servidor
Internet
Web
Java
Linux
virtualização
SOA
Cloud
containers
microservices
APIs
event streaming
IA
E o velho COBOL?
Continua por aí.
CICS?
Também.
VSAM?
Também.
Mainframe?
Também.
Não porque a computação tenha parado no tempo.
Justamente pelo contrário.
A indústria descobriu que modernização nem sempre significa destruir aquilo que existia anteriormente.
Às vezes significa conectá-lo ao próximo mundo.
Nosso ex-programador finalmente abriu o portal de retorno.
Antes de atravessá-lo, olhou uma última vez para o IBM 4341 de um lado e os servidores 386 do outro.
O jovem aprendiz perguntou:
— Mestre, afinal, quem venceu? O mainframe ou o micro?
Ele respondeu:
— Você ainda está fazendo a pergunta errada.
— Então qual é a pergunta certa?
O portal começou a fechar.
O ex-programador sorriu.
“Qual arquitetura resolve melhor o problema que realmente temos?”
E desapareceu.
Na tela 3278 permaneceu apenas:
READY
Em algum lugar da empresa, entretanto, uma rotina esquecida aguardava pacientemente.
Seu nome?
0317-ROTINA-ESPECIAL
Porque certas coisas sobrevivem ao downsizing, à cloud, à inteligência artificial e, aparentemente, até mesmo ao isekai.
Bem-vindo ao mainframe, Padawan. ☕
