✨ Bem-vindo ao meu espaço! ✨
Este blog é o diário de um otaku apaixonado por animes, tecnologia de mainframe e viagens.
Cada entrada é uma mistura única: relatos de viagem com fotos, filmes, links, artigos e desenhos, sempre buscando enriquecer a experiência de quem lê.
Sou quase um turista profissional: adoro dormir em uma cama diferente, acordar em um lugar novo e registrar tudo com minha câmera sempre à mão.
Entre uma viagem e outra, compartilho também reflexões sobre cultura otaku/animes
Bellacosa Mainframe e o funeral que nunca aconteceu
Uma viagem histórica pelas previsões que anunciaram a morte do
mainframe e pela engenharia que manteve COBOL, CICS, Db2, JCL,
z/OS e IBM Z essenciais até 2026.
Por
Vagner Bellacosa
☕ Um Café no Bellacosa Mainframe
Capítulo 1 — O Funeral que Nunca Aconteceu
"Existem três coisas extremamente perigosas na Tecnologia da Informação: benchmark sem contexto, buzzword da moda e jornalista anunciando a morte de uma tecnologia que movimenta bilhões de dólares por dia." — Bellacosa Mainframe
O dia em que enterraram um computador... que continuou trabalhando
Imagine a cena.
Março de 1991.
Um auditório lotado.
Executivos de gravata.
Consultores distribuindo transparências de retroprojetor.
Especialistas apontando para gráficos coloridos.
No centro da sala, um palestrante sobe ao palco e anuncia, com a confiança de quem acredita estar vendo o futuro:
— "O mainframe morreu."
A plateia aplaude.
Outro completa:
— "Agora tudo será Client/Server."
Mais um responde:
— "COBOL acabou."
Um terceiro acrescenta:
— "Em poucos anos ninguém mais usará JCL."
Lá no fundo alguém grita:
— "Windows NT vai dominar o mundo!"
E outro completa:
— "UNIX substituirá tudo."
Naquele instante parecia impossível discordar.
A imprensa repetia.
Os analistas confirmavam.
Os fabricantes concorrentes comemoravam.
As consultorias vendiam projetos milionários de migração.
Os buzzwords surgiam mais rápido do que versões de frameworks aparecem hoje.
Enquanto isso...
A milhares de quilômetros dali...
Sem plateia.
Sem marketing.
Sem PowerPoint.
Sem keynote.
Um IBM Mainframe continuava fazendo exatamente o que sempre fez.
Processando folha de pagamento.
Autorizando compras.
Movimentando contas bancárias.
Controlando companhias aéreas.
Executando milhões de transações CICS.
Atualizando tabelas Db2.
Executando milhares de JOBs JES2.
Processando COBOL.
Respondendo IMS.
Gerenciando VSAM.
Sem saber que, segundo alguns especialistas, ele já estava morto.
Bellacosa Mainframe e o IBM S390 que atravessou o olho do furacão
O morto mais produtivo da história da computação
Existe uma ironia maravilhosa nessa história.
Poucas tecnologias receberam tantos atestados de óbito quanto o mainframe.
E poucas sobreviveram tão bem.
Durante praticamente toda a década de 1990 surgiu uma nova manchete anunciando que aquele enorme computador centralizado finalmente havia chegado ao fim.
Era compreensível.
Os PCs evoluíam rapidamente.
As redes Ethernet cresciam.
Os servidores UNIX ficavam mais baratos.
Windows NT surgia como promessa corporativa.
A internet começava sua explosão.
Tudo parecia apontar para um futuro distribuído.
O problema não era enxergar essas tendências.
O problema era acreditar que evolução significava substituição.
Foi exatamente esse erro que boa parte da indústria cometeu.
A década dos Buzzwords
Se você é um Padawan COBOL em 2026, talvez ache engraçado imaginar uma época sem Cloud, Kubernetes, DevOps, IA Generativa ou LLMs.
Mas toda geração cria seus próprios modismos.
Na década de 1990 eles tinham nomes diferentes.
Client/Server.
Downsizing.
Open Systems.
Distributed Computing.
Network Computing.
Workstations.
RISC.
Windows NT.
Cada um era apresentado como "o futuro inevitável".
Bastava colocar um desses nomes em um folder colorido e, magicamente, o produto parecia revolucionário.
Era como se existisse um encantamento corporativo.
Se um software fosse chamado apenas de "Sistema Financeiro", ninguém prestava atenção.
Mas bastava renomeá-lo para:
Open Distributed Client/Server Enterprise Architecture Framework
...e imediatamente ele parecia valer dez vezes mais.
Mudou alguma coisa desde então?
Talvez apenas os nomes.
Hoje trocamos "Client/Server" por "AI Native".
"Distributed Computing" virou "Cloud First".
"Open Systems" virou "Platform Engineering".
"SOA" virou "Microservices".
"Big Data" virou "Data Fabric".
"Machine Learning" virou "Generative AI".
A tecnologia evolui.
Os buzzwords apenas mudam de roupa.
O professor que resolveu guardar a história
Anos depois, o professor Wilhelm G. Spruth, uma das maiores autoridades mundiais em Enterprise Computing e tecnologia IBM Z, teve uma ideia brilhante.
Em vez de simplesmente dizer que aquelas previsões estavam erradas...
Ele resolveu preservá-las.
Em seu famoso trabalho "The Death of the Mainframe", Spruth reuniu exatamente essas manchetes históricas publicadas por jornais, revistas e analistas de mercado. Seu objetivo não era ridicularizar ninguém, mas mostrar como previsões tecnológicas podem ser influenciadas pelo entusiasmo do momento e pelo marketing da indústria.
Graças a esse trabalho, hoje podemos olhar para aquelas páginas quase como um arqueólogo observa um fóssil.
Cada manchete conta uma história.
Cada previsão revela como a indústria pensava.
Cada erro ensina uma lição.
Este artigo não é sobre rir do passado
Seria muito fácil fazer piada.
E faremos algumas.
Mas o objetivo aqui é outro.
Vamos entender por que pessoas extremamente inteligentes chegaram à conclusão de que o mainframe morreria.
Na época, isso parecia lógico.
Muitos dos argumentos eram tecnicamente consistentes.
O problema é que quase todos analisavam apenas o hardware.
Pouquíssimos observavam aquilo que realmente sustentava o mundo corporativo:
décadas de regras de negócio;
milhões de linhas de COBOL;
consistência transacional;
disponibilidade próxima de 100%;
segurança;
auditoria;
governança;
integração;
custo gigantesco de uma migração.
Eles olharam para o computador.
Esqueceram de olhar para o negócio.
E negócios raramente seguem modismos.
Trinta anos depois...
Agora avance o calendário.
Não estamos mais em 1991.
Nem em 1996.
Estamos em 2026.
Enquanto muitos dos "assassinos do mainframe" desapareceram, foram comprados, mudaram de nome ou simplesmente deixaram de existir, o IBM Z continua evoluindo.
Hoje temos:
IBM z17;
aceleração de IA integrada;
watsonx;
IBM Build Open Builder (BOB);
OpenShift;
Ansible;
Zowe;
DevOps;
APIs REST;
containers Linux;
Enterprise COBOL cada vez mais otimizado;
Db2 mais inteligente;
CICS mais moderno;
z/OS integrando cloud híbrida e inteligência artificial.
O "dinossauro" aprendeu a conversar com Kubernetes.
Aprendeu a executar IA.
Aprendeu a expor APIs.
Aprendeu DevOps.
E fez tudo isso sem abandonar aquilo que sempre soube fazer melhor: executar cargas críticas com confiabilidade extraordinária.
Bem-vindo ao maior "post-mortem" da história da TI
Nos próximos capítulos vamos abrir uma verdadeira cápsula do tempo.
Vamos revisitar, uma a uma, as reportagens da Forbes, The New York Times, InfoWorld e Business Week.
Você verá o contexto histórico.
Os argumentos utilizados.
O que acertaram.
O que erraram.
Como aquelas previsões influenciaram toda uma geração de arquitetos e executivos.
E, principalmente, por que o tempo mostrou que o futuro costuma ser muito mais complexo do que qualquer manchete de capa consegue prever.
Pegue seu café.
Abra o ISPF.
Porque a autópsia vai começar.
E, curiosamente, o paciente ainda está trabalhando.
Bellacosa Mainframe e a serie o Funeral que nunca aconteceu
Uma investigação histórica em 14 capítulos sobre as previsões,
reportagens, buzzwords e profetas que anunciaram repetidamente
o fim do COBOL — enquanto bilhões de transações continuavam
sendo processadas silenciosamente.
Esta série investiga uma das narrativas mais repetidas da história
da tecnologia: a suposta morte do COBOL. Durante décadas, revistas,
jornais, consultorias e especialistas anunciaram seu desaparecimento.
Entretanto, o COBOL permaneceu processando bancos, seguradoras,
governos, cartões, pagamentos e sistemas críticos.
Os títulos e links acima são elementos HTML reais, permitindo que
mecanismos de busca encontrem e rastreiem todos os capítulos. Os
iframes funcionam apenas como previews visuais.
C:\> RUN BELLACOSA.EXE /COBOL /HISTORY /NO-FUNERAL
_
Bellacosa Mainframe e tenta entender a razao do Cobol nao existir fora do Mainframe
☕🚀 COBOL FORA DO MAINFRAME: POR QUE ELE NÃO CONQUISTOU O MUNDO COMO JAVA, C# E PYTHON?
Quando alguém fala em COBOL, a maioria das pessoas imediatamente imagina um enorme IBM Z, salas refrigeradas, bancos, seguradoras e sistemas que movimentam bilhões de dólares por dia.
Mas existe uma curiosidade que poucos conhecem:
O COBOL nunca foi exclusivo do Mainframe.
Durante décadas existiram versões para:
MS-DOS
Windows
Linux
Unix
AIX
HP-UX
Solaris
AS/400
VMS
até mesmo Raspberry Pi atualmente
Empresas como Micro Focus, Fujitsu, RM/COBOL, Acucobol, GNUCobol e outras investiram milhões tentando popularizar o COBOL fora do universo IBM.
Mesmo assim, quando ouvimos a palavra COBOL em 2026, quase todo mundo associa imediatamente ao Mainframe.
A pergunta é inevitável:
Por que isso aconteceu?
Por que Java virou universal?
Por que C conquistou sistemas operacionais?
Por que Python dominou a automação?
E por que COBOL permaneceu praticamente "preso" ao Mainframe?
A resposta envolve tecnologia, mercado, marketing, história, cultura corporativa e até psicologia.
Pegue seu café.
Hoje vamos mergulhar em uma das maiores curiosidades da história da computação.
O MAIOR MITO SOBRE COBOL
Existe uma crença popular:
"COBOL só funciona em Mainframe."
Isso nunca foi verdade.
Desde os anos 70 já existiam compiladores COBOL para minicomputadores.
Nos anos 80 surgiram versões para:
DOS
Unix
VAX/VMS
Nos anos 90:
Windows
OS/2
Linux
Nos anos 2000:
.NET
JVM
Web Services
Tecnicamente falando, o COBOL poderia ter seguido praticamente qualquer caminho.
Mas não seguiu.
O PROBLEMA NUNCA FOI A LINGUAGEM
Essa é a primeira coisa que surpreende muita gente.
O COBOL não fracassou fora do Mainframe porque era ruim.
Na verdade ele possuía diversas vantagens.
Extremamente legível
Exemplo:
IF SALDO-CONTA IS GREATER THAN LIMITE-CREDITO
DISPLAY "LIMITE EXCEDIDO"
END-IF
Até alguém sem conhecimento profundo consegue entender.
Excelente para regras de negócio
Bancos adoram COBOL porque ele descreve regras empresariais com clareza.
Por exemplo:
COMPUTE JUROS =
VALOR * TAXA / 100
Não existe mistério.
Forte manipulação de registros
Antes dos bancos relacionais se popularizarem, isso era ouro.
Precisão decimal
Enquanto várias linguagens sofriam com arredondamentos, COBOL nasceu para dinheiro.
E dinheiro não aceita erro.
O VERDADEIRO PROBLEMA: O COBOL NASCEU PARA NEGÓCIOS
A palavra COBOL significa:
Common Business Oriented Language
Observe:
Não é:
Common Game Language
Common Scientific Language
Common Internet Language
É:
Business.
Negócios.
Empresas.
Contabilidade.
Folha de pagamento.
Seguros.
Finanças.
Faturamento.
Desde o nascimento, ele tinha um propósito extremamente específico.
ENQUANTO ISSO, O MUNDO MUDOU
Na década de 1960 isso era perfeito.
Mas nas décadas seguintes surgiram novos mercados.
Computação científica
FORTRAN dominou.
Sistemas operacionais
C dominou.
Inteligência Artificial
LISP dominou inicialmente.
Aplicações gráficas
C++
Internet
Java
PHP
Perl
JavaScript
Ciência de Dados
Python
R
O mundo começou a exigir coisas que nunca foram prioridade para o COBOL.
O COBOL NÃO FOI FEITO PARA SER "COOL"
Aqui existe um fator psicológico interessantíssimo.
Pense nos heróis da programação:
Linus Torvalds → C
Guido van Rossum → Python
Bjarne Stroustrup → C++
James Gosling → Java
Agora pense em COBOL.
A maioria das pessoas nem sabe quem foi Grace Hopper.
Grace Hopper ajudou a criar conceitos fundamentais que levariam ao COBOL.
Mas a linguagem nunca foi vendida como algo revolucionário.
Ela foi vendida como algo:
estável
corporativo
burocrático
E isso afasta jovens desenvolvedores.
O EFEITO "BANCO"
Imagine dois anúncios.
Linguagem A
"Crie jogos incríveis!"
Linguagem B
"Automatize cálculos atuariais."
Qual parece mais divertida?
Foi exatamente isso que aconteceu.
COBOL ficou associado a:
bancos
seguradoras
governos
sistemas legados
Enquanto outras linguagens ficaram associadas à inovação.
O ERRO DE MARKETING MAIS CARO DA HISTÓRIA
Durante os anos 80 e 90, universidades começaram a ensinar:
C
Pascal
C++
Java
COBOL desapareceu dos cursos.
A consequência foi devastadora.
Menos estudantes.
Menos projetos.
Menos comunidade.
Menos livros.
Menos ferramentas.
Menos conteúdo.
Menos adoção.
Criou-se um círculo vicioso.
O PROBLEMA DAS FERRAMENTAS
Vamos ser honestos.
Nos anos 90 era muito mais divertido programar Visual Basic do que COBOL.
Visual Basic tinha:
botões
janelas
eventos
Você arrastava componentes.
Tudo aparecia na tela.
COBOL continuava focado em:
OPEN INPUT CLIENTES
READ CLIENTES
O apelo visual era praticamente zero.
O MUNDO APAIXONOU-SE POR INTERFACES GRÁFICAS
Quando o Windows explodiu, surgiu uma nova geração de desenvolvedores.
Eles queriam construir:
telas
jogos
multimídia
COBOL não era o candidato natural.
O MAINFRAME PROTEGEU O COBOL
Aqui está a maior ironia.
O Mainframe foi simultaneamente:
a maior força do COBOL
e sua maior prisão
Sem Mainframe talvez COBOL tivesse desaparecido.
Mas graças ao Mainframe ele sobreviveu.
Por outro lado, o sucesso no Mainframe reduziu o incentivo para conquistar outros mercados.
Os bancos já estavam satisfeitos.
Por que mudar?
O FATOR ECONÔMICO
Imagine um banco.
Você possui:
50 milhões de linhas COBOL
40 anos de história
bilhões movimentados diariamente
Qual decisão é mais segura?
Opção A
Migrar tudo.
Opção B
Continuar usando COBOL.
A resposta é óbvia.
O EFEITO "SE ESTÁ FUNCIONANDO, NÃO MEXA"
Poucas linguagens tiveram a sorte de trabalhar em ambientes tão conservadores.
Um sistema bancário precisa:
estabilidade
previsibilidade
auditoria
Não precisa ser moderno.
Precisa funcionar.
E COBOL funciona.
Muito bem.
A CHEGADA DA INTERNET
Nos anos 90 surgiu a Web.
Foi uma nova corrida do ouro.
Linguagens correram para conquistar esse território.
Java
PHP
Perl
ASP
COBOL chegou depois.
Muito depois.
Quando chegou, o mercado já tinha donos.
O PROBLEMA DA COMUNIDADE
Uma linguagem vive ou morre pela comunidade.
Python possui:
milhões de usuários
milhares de bibliotecas
eventos globais
Java possui ecossistema gigantesco.
COBOL sempre teve uma comunidade menor.
Extremamente qualificada.
Mas menor.
O FATOR OPEN SOURCE
Outro golpe importante.
O movimento Open Source impulsionou:
Linux
Python
PHP
Perl
COBOL permaneceu muito ligado ao mundo corporativo.
Mostrando que o COBOL continua vivo fora do Mainframe.
O COBOL É LENTO?
Outro mito.
Na verdade, muitas implementações COBOL são extremamente rápidas.
Especialmente em processamento transacional.
O problema nunca foi desempenho.
O COBOL É ANTIGO DEMAIS?
Também não.
Veja a ironia.
Hoje temos:
APIs REST
JSON
XML
Kafka
Containers
Docker
E o COBOL já conversa com tudo isso.
Inclusive o usuário Bellacosa Mainframe frequentemente explora integrações modernas entre COBOL, JSON, CICS Web Services e z/OS Connect.
O problema não é tecnológico.
É percepção de mercado.
O PARADOXO DO SUCESSO
O COBOL sofreu do mesmo problema que o DB2 Mainframe.
Ele ficou tão bom no que fazia que nunca precisou mudar radicalmente.
Enquanto outras linguagens lutavam para sobreviver, o COBOL já tinha conquistado o setor financeiro.
O QUE ACONTECERIA SE O COBOL FOSSE CRIADO HOJE?
Imagine uma linguagem com:
sintaxe legível
precisão decimal nativa
foco em regras de negócio
forte tipagem
excelente auditoria
Provavelmente seria vendida como:
FinTech Language
Banking Language
Enterprise Language
E talvez fosse considerada revolucionária.
O COBOL PERDEU A GUERRA?
Não.
Na verdade, ele venceu uma guerra diferente.
Enquanto milhares de linguagens nasceram e morreram, COBOL continua executando sistemas críticos após mais de seis décadas.
Poucas tecnologias na história conseguiram isso.
A VERDADE QUE POUCOS ADMITEM
Quando um programador Python cria um sistema hoje, ninguém sabe se ele existirá daqui a 30 anos.
Quando um programador COBOL cria um sistema bancário, existe uma boa chance de alguém ainda estar executando aquele código décadas depois.
Isso muda completamente a forma de projetar software.
A GRANDE LIÇÃO PARA OS PADAWANS
A pergunta correta não é:
"Por que COBOL ficou nichado no Mainframe?"
A pergunta correta é:
"Por que o Mainframe continuou sendo o melhor lugar para executar aquilo que o COBOL foi criado para fazer?"
Porque o COBOL nasceu para resolver problemas empresariais gigantescos.
E o Mainframe continua sendo a plataforma mais eficiente para executar esses processos com:
confiabilidade
segurança
disponibilidade
escalabilidade
integridade transacional
O COBOL não ficou preso ao Mainframe.
Na realidade, ele encontrou seu habitat natural.
As versões para DOS, Windows e Linux sempre existiram, continuam existindo e funcionam muito bem.
Mas fora do Mainframe ele precisava competir com centenas de linguagens.
Dentro do Mainframe ele se tornou rei.
E existe uma enorme diferença entre participar de uma competição e dominar um reino.
Mais de 65 anos depois de seu nascimento, o COBOL continua processando salários, aposentadorias, seguros, cartões de crédito, transferências bancárias e operações financeiras que sustentam boa parte da economia mundial.
Poucas linguagens podem dizer isso.
E talvez esse seja o maior paradoxo da computação:
O COBOL não conquistou todas as plataformas porque nunca precisou.
Bellacosa Mainframe e o gigante que atravessou a fronteira final da computacao
☕ Um Café no Bellacosa Mainframe
Mainframe — O Gigante que Atravessou a Fronteira Final da Computação
Diário de bordo, data estelar 2024.05.18
A nave corporativa atravessa uma região silenciosa do espaço digital.
Nos monitores, milhões de transações surgem e desaparecem em frações de segundo. Pagamentos são autorizados. Reservas são confirmadas. Salários são calculados. Apólices são atualizadas. Pedidos são processados. Transferências bancárias cruzam redes inteiras.
Nenhum alarme soa.
Nenhuma explosão ilumina a ponte de comando.
Tudo simplesmente funciona.
No centro dessa operação existe uma máquina que muita gente acredita pertencer ao passado.
O mainframe.
Para o passageiro comum da galáxia tecnológica, a palavra “mainframe” costuma gerar uma imagem antiga: uma sala enorme e gelada, operadores de gravata, fitas magnéticas girando, cartões perfurados empilhados e painéis repletos de luzes piscando.
É uma imagem quase cinematográfica.
Parece o computador de bordo de uma nave criada durante os primeiros anos da corrida espacial. Um equipamento gigantesco, pesado e misterioso, cercado por técnicos que observam seus indicadores como se estivessem tentando impedir a destruição de um planeta.
Essa imagem não está completamente errada.
O erro está em acreditar que a história terminou ali.
O mainframe não permaneceu congelado no tempo. Ele mudou de forma, de arquitetura, de capacidade e de função. Diminuiu por fora, cresceu por dentro e aprendeu a conviver com praticamente todas as revoluções tecnológicas que surgiram depois dele.
Minicomputadores.
Computadores pessoais.
Redes locais.
Internet.
Servidores distribuídos.
Máquinas virtuais.
Nuvem.
APIs.
Containers.
Inteligência artificial.
Em vez de desaparecer, o mainframe incorporou novas tecnologias e continuou executando sua missão principal: processar grandes volumes de trabalho com segurança, confiabilidade e disponibilidade.
Portanto, jovem padawan do COBOL — ou, neste caso, novo cadete da Frota Estelar do processamento corporativo — prepare-se.
Vamos entrar na sala de máquinas.
1. O mito do dinossauro tecnológico
Quando uma tecnologia permanece em uso durante muitas décadas, ela corre o risco de ser chamada de ultrapassada.
Isso acontece porque as pessoas confundem idade com obsolescência.
Uma tecnologia antiga é aquela que surgiu há muito tempo.
Uma tecnologia obsoleta é aquela que deixou de atender às necessidades para as quais foi criada.
Essas duas coisas não são iguais.
A roda é antiga, mas não é obsoleta.
A escrita é antiga, mas não é obsoleta.
O sistema bancário é antigo, mas continua sendo atualizado.
O COBOL surgiu no final da década de 1950, mas ainda é usado porque resolve problemas de negócio que continuam existindo: cálculo, registro, controle, processamento de arquivos, atualização de bancos de dados e execução de transações.
O mesmo raciocínio vale para o mainframe.
Ele não sobreviveu porque as empresas sentem nostalgia de terminais verdes. Sobreviveu porque continua resolvendo problemas importantes.
Imagine uma instituição financeira processando milhões de operações diariamente.
Cada operação precisa ser:
autorizada corretamente;
registrada sem duplicidade;
protegida contra acesso indevido;
concluída dentro do tempo esperado;
recuperada em caso de falha;
auditável posteriormente.
Não basta executar rapidamente.
É preciso executar corretamente.
Essa diferença é fundamental.
Um sistema doméstico pode travar e ser reiniciado.
Um sistema bancário não pode simplesmente dizer:
“Desculpe, perdemos algumas transferências. Reinicie o aplicativo e tente novamente.”
Em ambientes críticos, disponibilidade e integridade não são recursos adicionais. São parte central da arquitetura.
O mainframe foi desenvolvido justamente para esse tipo de missão.
2. Antes do nome: quando os dados começaram a vencer os humanos
Antes de existir o mainframe, já existia o problema que faria nascer o mainframe.
O volume de informações crescia mais rapidamente do que a capacidade humana de organizá-las.
Governos precisavam realizar censos.
Empresas precisavam calcular salários.
Ferrovias precisavam controlar horários, cargas e passageiros.
Seguradoras precisavam manter registros de apólices.
Bancos precisavam registrar depósitos, empréstimos e saldos.
Exércitos precisavam cuidar de logística, suprimentos e pessoal.
Durante muito tempo, essas atividades foram realizadas manualmente. Exércitos inteiros de funcionários preenchiam formulários, copiavam números, conferiam tabelas e arquivavam documentos.
O problema era simples de compreender e terrível de resolver:
Mais pessoas
+
Mais empresas
+
Mais transações
+
Mais documentos
=
Mais complexidade
Em determinado momento, contratar mais funcionários já não resolvia o problema.
Era preciso automatizar.
Um dos acontecimentos mais importantes dessa história foi o uso de cartões perfurados no processamento do Censo dos Estados Unidos de 1890.
O cartão perfurado representava informações por meio de posições físicas. Um furo em determinado ponto podia significar idade, estado civil, profissão, região ou outra característica.
A máquina lia os furos e contabilizava os dados.
Isso parece primitivo hoje, mas representou uma mudança monumental.
A informação deixava de existir apenas como texto compreendido por humanos. Ela podia ser codificada de maneira que uma máquina também conseguisse processá-la.
Era o início de uma longa viagem.
Curiosidade de bordo
O cartão perfurado influenciou profundamente a cultura da computação.
Durante décadas, programadores escreviam seus programas em folhas de codificação. Depois, operadores perfuravam cada linha em um cartão.
Um programa COBOL com 500 linhas poderia significar 500 cartões físicos.
Agora imagine derrubar o baralho no chão.
Esse era um tipo de “falha de ordenação” muito mais dramático do que esquecer um ORDER BY.
3. O dia em que o computador arrumou um emprego
Os primeiros computadores eletrônicos eram frequentemente associados à ciência, à guerra ou à pesquisa.
Eles calculavam trajetórias, tabelas matemáticas e simulações.
Entretanto, o verdadeiro ponto de transformação aconteceu quando o computador deixou o laboratório e entrou na empresa.
O computador arrumou um emprego.
Passou a cuidar de tarefas administrativas e comerciais, como:
folha de pagamento;
faturamento;
contas a receber;
inventário;
processamento de cheques;
emissão de apólices;
controle de clientes;
reservas aéreas.
Esse momento é essencial para entender o mainframe.
A empresa não precisava apenas de uma calculadora rápida. Precisava de um sistema capaz de executar operações repetitivas, confiáveis e organizadas.
É nesse ambiente que linguagens como o COBOL ganham importância.
COBOL significa:
Common Business-Oriented Language
Ou seja:
Linguagem Comum Orientada a Negócios
Desde o início, sua missão era permitir que regras empresariais fossem representadas de maneira relativamente legível.
Veja um pequeno exemplo:
IF SALDO-CONTA >= VALOR-SAQUE
SUBTRACT VALOR-SAQUE FROM SALDO-CONTA
MOVE "SAQUE AUTORIZADO" TO MENSAGEM
ELSE
MOVE "SALDO INSUFICIENTE" TO MENSAGEM
END-IF
Mesmo alguém com pouca experiência consegue perceber a lógica.
Essa clareza ajudou o COBOL a se tornar uma das principais linguagens do processamento empresarial.
Dica para o iniciante
Ao estudar COBOL, não observe apenas a sintaxe.
Pergunte sempre:
“Qual regra de negócio este programa representa?”
O verdadeiro poder do COBOL não está no MOVE, no PERFORM ou no IF.
Está na capacidade de transformar regras empresariais em processos executáveis.
4. De onde veio a palavra mainframe?
Nos primeiros grandes computadores, os componentes eram instalados em diferentes gabinetes, estruturas e armações metálicas.
O termo “main frame”, ou estrutura principal, passou a ser associado ao gabinete central que abrigava componentes importantes do sistema, especialmente a unidade central de processamento.
Com o tempo, a expressão deixou de representar apenas uma parte física e passou a identificar uma categoria inteira de computadores.
Entretanto, definir mainframe apenas pelo tamanho seria um erro.
Um mainframe moderno não precisa ocupar uma sala inteira.
O que caracteriza a plataforma é principalmente sua arquitetura e sua capacidade de lidar com cargas de trabalho críticas em grande escala.
Entre suas características estão:
processamento intenso de transações;
grande capacidade de entrada e saída;
alta disponibilidade;
tolerância a falhas;
isolamento entre cargas de trabalho;
segurança integrada;
capacidade de virtualização;
gerenciamento sofisticado de recursos.
Portanto, mainframe não significa simplesmente “computador grande”.
Significa uma plataforma projetada para sustentar operações centrais de grandes organizações.
5. A guerra dos gigantes
A história dos mainframes não pertence a uma única empresa.
Durante várias décadas, fabricantes disputaram o domínio do mercado de computação corporativa.
Entre os nomes mais importantes estavam:
IBM;
UNIVAC;
Burroughs;
NCR;
Honeywell;
Control Data Corporation;
RCA;
Fujitsu;
Hitachi;
Siemens;
ICL.
Esse período ficou conhecido informalmente por diversas classificações da indústria. Uma das mais famosas agrupava os grandes concorrentes da IBM sob a expressão “BUNCH”:
B — Burroughs
U — UNIVAC
N — NCR
C — Control Data
H — Honeywell
Cada fabricante possuía sua própria visão de arquitetura.
Não existia um padrão universal.
Um programa criado para determinada máquina normalmente não era transferido facilmente para outra.
Os sistemas possuíam diferenças em:
conjunto de instruções;
formato de dados;
tamanho de palavra;
periféricos;
sistemas operacionais;
compiladores;
ferramentas;
procedimentos de operação.
Escolher um computador era quase como escolher uma civilização inteira.
A empresa não comprava apenas uma máquina.
Comprava um ecossistema.
Easter egg da Frota
Essa disputa lembra as grandes espécies tecnológicas de uma galáxia fictícia.
Cada fabricante tinha seu idioma, seus protocolos, sua engenharia e sua filosofia.
Migrar de uma arquitetura para outra podia ser tão complicado quanto pedir para uma nave romulana usar peças klingons durante uma batalha.
6. A revolução do System/360
Um dos acontecimentos mais importantes na história da computação empresarial foi o lançamento da família IBM System/360 em 1964.
A ideia era criar uma linha compatível de computadores.
Modelos diferentes poderiam atender empresas de tamanhos e necessidades distintas, mas compartilhariam uma arquitetura comum.
Isso permitia que uma organização começasse com uma configuração menor e migrasse para outra mais potente sem abandonar completamente seus programas e conhecimentos.
Essa compatibilidade foi revolucionária.
O número 360 sugeria cobertura completa, como os 360 graus de um círculo.
A proposta era atender diferentes tipos de processamento:
científico;
comercial;
governamental;
industrial.
Para quem trabalha com mainframe hoje, essa decisão histórica continua importante.
Grande parte da força da plataforma vem da ideia de continuidade.
As empresas investiram décadas desenvolvendo programas, bases de dados e regras de negócio.
Jogar tudo fora a cada nova geração de hardware seria economicamente inviável.
O mainframe evoluiu preservando compatibilidade sempre que possível.
Isso não significa ausência de mudança.
Significa evolução controlada.
7. Quando o software aprendeu a fazer muitas coisas ao mesmo tempo
Nos primeiros sistemas, era comum processar um trabalho por vez.
O usuário entregava um conjunto de cartões.
O operador carregava o programa.
A máquina executava.
O resultado era impresso.
Depois, o próximo trabalho começava.
Esse modelo ficou conhecido como processamento em lote, ou batch.
O batch continua existindo e sendo extremamente importante. Entretanto, os primeiros ambientes desperdiçavam tempo porque a CPU frequentemente aguardava operações lentas de entrada e saída.
Imagine uma CPU capaz de executar milhares ou milhões de instruções, esperando uma leitora de cartões ou uma impressora terminar sua tarefa.
Era como usar o motor de dobra de uma nave apenas para acender as luzes da cabine.
A solução foi permitir que vários trabalhos permanecessem no sistema ao mesmo tempo.
Enquanto um job aguardava uma operação de disco ou fita, outro poderia utilizar o processador.
Esse conceito ficou conhecido como multiprogramação.
De maneira simplificada:
JOB A usa CPU
JOB A espera disco
JOB B usa CPU
JOB B espera fita
JOB C usa CPU
O sistema operacional passa a organizar essa alternância.
Assim surgem funções fundamentais:
escalonamento;
gerenciamento de memória;
controle de prioridades;
proteção entre programas;
tratamento de interrupções;
alocação de dispositivos.
Hoje consideramos tudo isso normal.
Na época, era uma mudança gigantesca.
8. Time-sharing: uma máquina, muitos usuários
Outro avanço decisivo foi o compartilhamento de tempo, ou time-sharing.
A ideia era dividir pequenas parcelas do tempo do processador entre diferentes usuários.
Cada pessoa, diante de um terminal, tinha a impressão de estar usando o computador individualmente.
Na realidade, o sistema alternava rapidamente entre diferentes sessões.
Imagine três usuários:
Usuário A recebe alguns milissegundos
Usuário B recebe alguns milissegundos
Usuário C recebe alguns milissegundos
Depois o ciclo recomeça
Como essa alternância acontece rapidamente, cada usuário percebe uma experiência interativa.
Esse conceito ajudou a transformar o computador.
Ele deixou de ser apenas uma máquina que recebia lotes de trabalho e devolvia resultados horas depois.
Passou a responder diretamente às pessoas.
Para um programador COBOL, essa evolução é importante porque ajuda a compreender a diferença entre dois universos:
Processamento batch
e
Processamento online
No batch, o programa normalmente lê grandes volumes de dados e produz atualizações ou relatórios.
No online, o programa responde a uma solicitação imediata, frequentemente por meio de monitores transacionais como o CICS.
9. Virtualização: uma máquina física parecendo várias
Uma das maiores contribuições do mundo mainframe foi o amadurecimento da virtualização.
Virtualizar significa permitir que um único computador físico se comporte como vários computadores independentes.
Cada ambiente virtual pode possuir:
sistema operacional;
memória;
usuários;
aplicações;
configurações;
recursos controlados.
Isso permite melhor aproveitamento do hardware e maior isolamento.
De maneira simplificada:
Hardware físico
|
+-- Máquina virtual A
|
+-- Máquina virtual B
|
+-- Máquina virtual C
Hoje a virtualização é comum em servidores, clouds e ambientes de desenvolvimento.
Entretanto, o mainframe já utilizava esse conceito em grande escala muito antes de ele se tornar moda no restante da indústria.
Curiosidade
Quando alguém diz que a virtualização nasceu com os servidores modernos, um veterano de mainframe provavelmente levanta uma sobrancelha.
Talvez não diga nada.
Mas em pensamento estará executando:
IF AFIRMACAO = "VIRTUALIZACAO E NOVA"
DISPLAY "REGISTRO HISTORICO INCONSISTENTE"
END-IF
10. O habitat da máquina
Comprar um grande computador era apenas o começo.
Era preciso construir um mundo para mantê-lo funcionando.
Os antigos centros de processamento de dados exigiam uma infraestrutura cuidadosamente planejada.
Piso elevado
O piso elevado criava um espaço sob a sala.
Esse espaço podia ser usado para:
passagem de cabos;
distribuição de ar;
organização elétrica;
acesso à infraestrutura.
O chão do CPD não era apenas um piso.
Era parte do sistema.
Refrigeração
Computadores geram calor.
Os grandes equipamentos antigos geravam muito calor.
Era necessário controlar:
temperatura;
umidade;
circulação de ar;
pontos quentes;
estabilidade ambiental.
Algumas instalações utilizavam sistemas de água gelada.
Energia
Um ambiente crítico precisava de energia confiável.
Isso envolvia:
alimentação elétrica dedicada;
estabilização;
nobreaks;
geradores;
circuitos redundantes;
procedimentos de contingência.
Cabeamento
Os cabos eram grossos, numerosos e muitas vezes percorriam grandes distâncias.
Conectar processadores, controladores, discos, fitas, impressoras e terminais exigia planejamento.
Segurança física
O acesso ao CPD era controlado.
Não era uma sala em que qualquer funcionário entrava para tomar café.
Existiam regras, registros, permissões e procedimentos.
O ambiente representava o centro nervoso da empresa.
11. Discos, fitas e o universo do armazenamento
O armazenamento também mudou profundamente.
Os primeiros discos possuíam capacidades minúsculas quando comparadas aos padrões atuais, mas eram enormes fisicamente.
Unidades de disco podiam ocupar gabinetes inteiros.
As fitas magnéticas eram essenciais para:
backup;
arquivamento;
transporte de dados;
processamento sequencial;
retenção histórica.
No mundo COBOL, ainda é importante compreender a lógica sequencial.
Muitos programas processam arquivos em ordem:
Ler registro
Validar registro
Processar registro
Gravar saída
Ler próximo registro
Esse padrão continua extremamente eficiente para grandes volumes.
Um exemplo conceitual em COBOL:
PERFORM UNTIL FIM-ARQUIVO = "S"
READ ARQUIVO-ENTRADA
AT END
MOVE "S" TO FIM-ARQUIVO
NOT AT END
PERFORM PROCESSAR-REGISTRO
END-READ
END-PERFORM
O programa trabalha registro por registro até atingir o final do arquivo.
Essa lógica pode parecer simples, mas é usada em processos que movimentam milhões de registros.
12. IBM 3090, IBM 9021 e o lendário “agazão”
Para muitos profissionais brasileiros, máquinas como o IBM 3090 e o IBM 9021 não são apenas nomes em livros.
São parte da memória profissional.
Representavam grandes configurações instaladas em ambientes onde cada detalhe importava.
O operador observava consoles, unidades, filas de jobs e mensagens do sistema.
O ruído do ambiente, o ar frio e a presença física dos equipamentos criavam uma sensação difícil de reproduzir atualmente.
Em alguns ambientes, determinadas configurações eram chamadas informalmente de “agazão”.
Apelidos desse tipo fazem parte da cultura de operação.
Toda equipe acaba criando um vocabulário próprio.
Máquinas recebem nomes.
Salas ganham apelidos.
Procedimentos viram expressões.
Erros históricos transformam-se em lendas internas.
Easter egg do veterano
Todo CPD antigo possuía pelo menos uma história que começava assim:
“Isso aconteceu no turno da madrugada, mas ninguém sabe exatamente quem estava no console.”
Normalmente, três pessoas contam versões diferentes.
Todas afirmam que salvaram o sistema.
13. O mainframe não é apenas hardware
Um erro comum do iniciante é pensar no mainframe somente como uma máquina.
Na realidade, estamos falando de uma plataforma completa.
Ela envolve:
hardware;
sistema operacional;
subsistemas;
linguagens;
compiladores;
bancos de dados;
monitores transacionais;
ferramentas de segurança;
ferramentas operacionais;
redes;
armazenamento;
processos empresariais.
Em um ambiente z/OS, por exemplo, você pode encontrar:
JES2 para gerenciamento de jobs;
TSO/E para interação com o sistema;
ISPF para navegação e desenvolvimento;
CICS para processamento transacional;
Db2 para banco de dados relacional;
IMS para banco de dados e transações;
RACF para segurança;
DFSMS para gerenciamento de armazenamento;
SMP/E para manutenção de software;
WLM para gerenciamento de cargas de trabalho.
Cada componente possui uma função.
Juntos, formam uma espécie de nave interestelar corporativa.
A CPU é importante, mas não viaja sozinha.
14. O caminho de um programa COBOL
Para o iniciante, o ambiente mainframe pode parecer enorme e confuso.
A melhor forma de aprender é seguir o caminho de um programa.
Vamos imaginar um programa batch simples.
Passo 1 — Escrever o código-fonte
O programa COBOL é armazenado em um dataset ou em um repositório integrado ao fluxo de desenvolvimento.
Passo 2 — Compilar
O compilador analisa o código.
Ele verifica:
sintaxe;
definição de dados;
comandos;
referências;
estruturas.
Se houver erros, produz mensagens.
Passo 3 — Link-edit
Após a compilação, o código objeto precisa ser transformado em um módulo executável.
Esse processo cria o load module ou program object.
Depois da base, avance para persistência de dados.
No Db2, estude:
SELECT;
INSERT;
UPDATE;
DELETE;
cursor;
SQLCODE;
commit;
rollback.
Etapa 9 — Conheça o CICS
Aprenda o conceito de transação online.
Entenda:
mapa;
tela;
COMMAREA;
canais e containers;
LINK;
XCTL;
filas;
integração com Db2.
Etapa 10 — Entenda o negócio
Essa é a fase mais importante.
Pergunte:
O que o sistema faz?
Quem utiliza?
Qual dado é crítico?
Qual erro é aceitável?
Qual erro é desastroso?
Existe auditoria?
Existe recuperação?
O melhor programador não é quem conhece mais comandos.
É quem compreende o impacto daquilo que modifica.
26. Erros comuns do iniciante
Decorar sem compreender
Copiar JCL sem entender cada DD pode funcionar até o dia em que algo mudar.
Ignorar mensagens
O sistema frequentemente explica o problema.
Leia as mensagens antes de alterar o código aleatoriamente.
Testar apenas o caso feliz
Considere:
arquivo vazio;
campo inválido;
valor negativo;
registro duplicado;
fim inesperado;
acesso negado;
indisponibilidade de recurso.
Alterar produção diretamente
Ambientes críticos exigem controle.
Use:
desenvolvimento;
teste;
homologação;
aprovação;
implantação planejada.
Achar que código antigo é código ruim
Um programa antigo pode representar décadas de conhecimento de negócio.
Antes de criticá-lo, entenda por que foi construído daquela forma.
Reescrever por impulso
Código novo também contém bugs.
A modernização deve ser orientada por objetivos reais, não por vergonha da idade do sistema.
27. Curiosidades da ponte de comando
O COBOL foi pensado para negócios
Sua sintaxe mais verbal não é um acidente. A intenção era aproximar o código da linguagem empresarial.
O mainframe ajudou a popularizar virtualização
Décadas antes de a palavra “cloud” dominar apresentações corporativas, grandes sistemas já compartilhavam hardware entre ambientes isolados.
O batch não morreu
Processar milhões de registros em lote continua sendo uma solução eficiente.
Nem tudo precisa ser uma API síncrona.
Terminais não são o mainframe
O terminal é apenas uma interface.
Confundir tela verde com mainframe é como confundir o painel da nave com o motor de dobra.
COBOL moderno não é COBOL de 1960
Compiladores modernos possuem otimizações, integração com novas tecnologias e recursos que não existiam nas primeiras versões da linguagem.
O maior risco pode estar fora do código
Muitos incidentes são causados por:
configuração;
permissão;
dados;
processo;
comunicação;
implantação inadequada.
Nem todo problema termina em IDENTIFICATION DIVISION.
28. O verdadeiro segredo da longevidade
Por que o mainframe continua vivo?
Não existe uma única resposta.
Ele sobrevive porque combina vários fatores:
compatibilidade;
confiabilidade;
capacidade de processamento;
segurança;
investimento acumulado;
conhecimento de negócio;
integração;
evolução arquitetural.
Mas talvez exista uma resposta ainda mais profunda.
O mainframe sobreviveu porque nunca foi apenas uma máquina.
Ele se tornou parte das operações das empresas.
Um programa COBOL pode parecer um conjunto de comandos.
Na prática, ele pode representar:
regras tributárias;
contratos;
políticas de crédito;
cálculos atuariais;
processos contábeis;
obrigações regulatórias;
décadas de decisões empresariais.
Substituir o código não significa apenas trocar uma linguagem.
Significa reconstruir conhecimento.
E conhecimento perdido pode ser mais caro do que hardware.
29. O easter egg escondido no núcleo
Existe uma mensagem secreta em toda essa história.
Ela não está em hexadecimal.
Não está escondida em um registrador.
Não aparece em um dump.
A mensagem é esta:
O futuro da tecnologia não é construído apenas descartando o passado. Muitas vezes, ele é construído conectando o que funciona com aquilo que acaba de surgir.
Essa é uma lição importante para qualquer programador.
Tecnologia não é uma sequência de destruições completas.
É uma sequência de camadas.
O sistema moderno ainda carrega ideias antigas:
arquivos;
filas;
transações;
processos;
permissões;
logs;
escalonamento;
virtualização.
Mudam os nomes.
Mudam as interfaces.
Mudam as ferramentas.
Os problemas fundamentais frequentemente permanecem.
30. Conclusão — A fronteira final não é o espaço
Depois de atravessar décadas de história, chegamos ao presente.
O mainframe não é um monstro pré-histórico esperando a própria extinção.
Ele é uma plataforma que aprendeu a evoluir sem abandonar sua missão.
Começou em uma época de cartões perfurados, fitas magnéticas e grandes salões refrigerados.
Participou da transformação do computador em ferramenta empresarial.
Atravessou a guerra entre fabricantes.
Ajudou a amadurecer conceitos como multiprogramação, compartilhamento de tempo e virtualização.
Sustentou grandes centros de processamento.
Sobreviveu à ascensão dos PCs, dos servidores, da internet e da nuvem.
E agora integra-se a APIs, containers, DevOps e inteligência artificial.
Para o programador COBOL iniciante, compreender essa história é mais do que conhecer máquinas antigas.
É entender o motivo pelo qual determinadas práticas existem.
É perceber por que segurança, disponibilidade e integridade recebem tanta atenção.
É compreender que um programa não vive isolado.
Ele faz parte de uma arquitetura, de um processo e de uma organização.
Quando você escrever seu primeiro MOVE, executar seu primeiro job ou investigar seu primeiro abend, lembre-se de que está entrando em uma tradição construída por gerações de profissionais.
Alguns trabalharam com cartões.
Outros com terminais.
Outros com editores modernos.
Mas todos enfrentaram a mesma missão:
Receber dados
Aplicar regras
Produzir resultados corretos
Proteger o negócio
Manter o sistema funcionando
A fronteira final da computação não é uma linguagem, uma máquina ou uma nuvem.
É a capacidade de construir sistemas nos quais milhões de pessoas confiam sem sequer perceber que eles estão ali.
O mainframe tornou-se invisível.
Mas invisível não significa ausente.
Em algum lugar, enquanto você lê este artigo, uma transação está sendo executada, um registro está sendo atualizado e um programa COBOL está cumprindo silenciosamente sua missão.
Na ponte de comando, as luzes permanecem estáveis.
Vagner Renato Bellacosa trabalha com IBM Mainframe
desde 1988
,
é IBM Champion e especialista em COBOL, CICS, Db2,
z/OS e IBM Z. Compartilha experiências profissionais,
conhecimento técnico, história da computação e práticas
do universo mainframe para aproximar novas gerações das
tecnologias que sustentam empresas, bancos e governos
ao redor do mundo.
IBM Champion
IBM Z
COBOL
CICS
Db2
z/OS
Mainframe desde 1988
