☕ Um Café no Bellacosa Mainframe
🏛️ O CPD DO SÉCULO PASSADO — QUANDO 128 MB ERAM UM REINO E 100 GB EXIGIAM UMA CATEDRAL
Mainframe, MVS, JES2, CICS, COBOL, DASD, canais, fitas, SNA, VTAM, UNIX, terminais 3270, impressoras, processamento batch — e uma viagem ao tempo em que computação corporativa não cabia no bolso: ocupava uma sala inteira.
🎬 PRÓLOGO — ABRA A PORTA DO CPD
Imagine que estamos em algum momento da primeira metade da década de 1990.
Não existe Wi-Fi.
Não existe smartphone.
Não existe nuvem pública.
Não existe Kubernetes.
Não existe GitHub.
Não existe Slack.
A Internet comercial ainda começa a mostrar as garras.
Você trabalha numa grande organização e precisa consultar milhares ou milhões de registros de clientes, contribuintes, pagamentos, contas ou contratos.
Onde estão esses dados?
Atrás de uma porta.
Provavelmente uma porta que você não tem autorização para abrir.
Do outro lado existe o CPD — Centro de Processamento de Dados.
Entre.
A primeira coisa que chama atenção não é uma tela.
É o ambiente.
Ar-condicionado trabalhando continuamente. Piso elevado. Armários enormes. Cabos desaparecendo sob o chão. Unidades de disco. Controladoras. Fitas magnéticas. Impressoras capazes de transformar caixas inteiras de papel em relatórios.
No centro dessa pequena cidade eletrônica encontra-se o mainframe.
Mas cometeríamos um grande erro histórico se imaginássemos o CPD apenas como "um computador grande".
O CPD era um ecossistema.
E compreender esse ecossistema ajuda a entender muito do que fazemos até hoje.
🏰 CAPÍTULO 1 — O COMPUTADOR NÃO ERA UMA CAIXA
Hoje compramos um notebook e dentro dele encontramos:
CPU;
memória;
armazenamento;
rede;
vídeo;
USB;
Wi-Fi;
Bluetooth;
sistema operacional.
Isso cria uma ilusão perigosa quando olhamos para computadores antigos.
Pensamos:
"Nossa! Só 128 MB de memória?"
A comparação é injusta.
Um grande computador corporativo daquele período podia possuir dezenas de canais de entrada e saída ligados a equipamentos especializados.
O processador não precisava fazer sozinho tudo aquilo que um microcomputador fazia.
Existiam processadores e controladoras especializados em movimentar dados.
Havia controladora de discos.
Controladora de fitas.
Controladora de comunicação.
Controladora de terminais.
Interfaces de canais.
Equipamentos especializados em redes.
Portanto, uma configuração poderia ter algo como:
CPU
|
+---- canais ---- controladora ---- discos
|
+---- canais ---- controladora ---- cartuchos
|
+---- canais ---- telecomunicações ---- terminais
|
+---- canais ---- impressão
|
+---- canais ---- gateway ---- rede local
A CPU era apenas uma parte da máquina.
Essa distinção é fundamental.
🚚 CAPÍTULO 2 — CANAIS: A LOGÍSTICA DO REINO
Um iniciante em mainframe pode encontrar referências a sistemas antigos possuindo:
16 canais.
Ou:
64 canais.
E perguntar:
"Canal de quê?"
Imagine um grande porto.
O presidente da autoridade portuária não pega cada contêiner, coloca num caminhão e dirige até o depósito.
Existe infraestrutura especializada para movimentar mercadorias.
O mesmo princípio era aplicado ao computador.
O processador precisava calcular.
O subsistema de entrada e saída precisava transportar dados.
Os canais permitiam que operações de I/O fossem delegadas à infraestrutura especializada.
Enquanto determinada quantidade de informação estava sendo movimentada entre disco e memória, o processador poderia continuar executando outras atividades.
Essa filosofia sobrevive no mainframe moderno.
Por isso comparar apenas:
MHz
RAM
GB
entre um PC e um mainframe quase nunca conta a história completa.
A arquitetura importa.
💾 CAPÍTULO 3 — QUANDO 100 GB ERAM UMA FORTUNA
Agora chegamos ao armazenamento.
Imagine aproximadamente:
24 discos totalizando cerca de 45 GB.
Outro conjunto:
32 discos totalizando aproximadamente 60 GB.
Somados:
aproximadamente 105 GB.
Seu telefone provavelmente olha para isso e começa a rir.
Não ria ainda.
Estamos falando de uma época em que discos eram equipamentos enormes, caros e administrados como infraestrutura corporativa.
E aqueles 100 GB não estavam cheios de selfies.
Ali poderiam morar:
A pergunta interessante não é:
"Quantos gigabytes havia?"
A pergunta correta é:
"Quantas transações de negócio aqueles gigabytes sustentavam?"
Essa mudança de perspectiva é importantíssima.
Um único registro COBOL pode possuir algumas centenas de bytes.
Faça a conta.
Um gigabyte pode representar milhões de registros.
🗄️ CAPÍTULO 4 — DASD NÃO ERA "O HD"
No mundo mainframe, você encontrará frequentemente a palavra:
DASD — Direct Access Storage Device.
Para um iniciante, é tentador traduzir mentalmente:
"Ah, HD."
Serve como aproximação inicial.
Mas existe uma infraestrutura inteira por trás.
Você poderia encontrar:
MAINFRAME
|
CHANNEL
|
CONTROLADORA
|
+---- DASD
+---- DASD
+---- DASD
+---- DASD
A controladora podia possuir cache.
E aqui encontramos algo extremamente moderno escondido em tecnologia antiga.
Imagine uma controladora com dezenas de megabytes de cache e armazenamento não volátil destinado a proteger operações de escrita.
Reconheceu o conceito?
Décadas depois continuamos discutindo:
cache;
buffering;
persistência;
write-back;
latência;
disponibilidade.
As implementações mudam.
Os problemas fundamentais permanecem.
📼 CAPÍTULO 5 — A FITA ERA PARTE DA PRODUÇÃO
Agora chegamos a um equipamento que jovens programadores normalmente conhecem apenas de filmes:
fita magnética.
Em um CPD você poderia encontrar unidades antigas de carretel e também cartuchos muito mais compactos.
As fitas podiam participar de:
E havia uma diferença fundamental.
O disco oferece acesso direto.
A fita é essencialmente sequencial.
Imagine procurar o capítulo 57 de um livro.
No disco:
abra aproximadamente onde está o capítulo.
Na fita:
percorra o caminho até chegar nele.
Isso influencia profundamente a programação.
Não é coincidência que COBOL seja tão confortável trabalhando com arquivos sequenciais.
📚 CAPÍTULO 6 — NASCE UMA CULTURA DE PROCESSAMENTO
Agora imagine que durante o dia milhares de usuários estão trabalhando.
Consultando.
Incluindo registros.
Alterando informações.
Executando transações.
Quando chega a noite, começa outro mundo.
O batch.
Jobs entram nas filas.
Arquivos são lidos.
Arquivos são classificados.
Bases são atualizadas.
Relatórios são produzidos.
Backups são realizados.
Conciliações são executadas.
Fechamentos começam.
O CPD muda de personalidade.
Durante o dia:
usuário
↓
terminal
↓
transação
↓
programa
↓
dados
Durante a madrugada:
JOB
↓
STEP
↓
PROGRAM
↓
ARQUIVO
↓
SORT
↓
NOVO ARQUIVO
↓
RELATÓRIO
É por isso que JCL tornou-se tão importante.
JCL não era simplesmente uma linguagem esquisita inventada para atormentar estudantes.
Era a descrição operacional do trabalho.
🚂 CAPÍTULO 7 — JES2: A ESTAÇÃO FERROVIÁRIA
Imagine centenas de jobs chegando ao sistema.
Alguém precisa organizar isso.
Entrada.
Fila.
Execução.
Saída.
Spool.
Impressão.
É aqui que podemos imaginar o JES2 como uma gigantesca estação ferroviária.
Os jobs chegam.
São classificados.
Esperam recursos.
Executam.
Produzem saída.
Um programa COBOL não existia isoladamente.
Ele fazia parte de uma cadeia operacional.
JOB
|
+-- STEP01
| programa A
|
+-- STEP02
| SORT
|
+-- STEP03
| programa B
|
+-- STEP04
relatório
Um erro no STEP02 poderia impedir tudo que viesse depois.
Por isso o programador aprendia rapidamente coisas como:
COND
DISP
DD
DSN
SYSOUT
Não porque alguém gostasse de siglas.
Mas porque elas representavam a infraestrutura da fábrica.
⚙️ CAPÍTULO 8 — MVS: O PREFEITO DA CIDADE
No centro dessa operação estava o sistema operacional.
Na geração que estamos visitando, poderíamos encontrar MVS/XA.
E o XA é historicamente importante.
A geração anterior trabalhava com endereçamento de 24 bits e espaço de endereço de até 16 MB.
A arquitetura XA ampliou o endereçamento para 31 bits, levando o espaço virtual para até 2 GB.
Mais importante ainda: preservou compatibilidade com aplicações antigas.
Esse princípio de compatibilidade tornou-se uma das características mais impressionantes da evolução do mainframe.
O programa antigo não precisava necessariamente ser jogado fora apenas porque a arquitetura evoluiu.
Havia:
AMODE 24
e:
AMODE 31
O passado e o presente conviviam.
Décadas depois, a arquitetura chegaria aos 64 bits mantendo mecanismos para executar software anterior.
É uma das razões pelas quais existem programas corporativos com décadas de existência ainda em produção.
👨💻 CAPÍTULO 9 — O PROGRAMADOR ENTRA NO TERMINAL
Você é programador.
Não existe Visual Studio Code.
Não existe monitor ultrawide.
Não existe Stack Overflow.
Você chega ao terminal.
Provavelmente encontra um ambiente 3270.
A tela pode ter:
24 linhas
x
80 colunas
E aquelas 80 colunas não são detalhe decorativo.
Elas carregam décadas de história da computação.
Você entra no ambiente interativo.
Abre o editor.
Edita COBOL.
Edita JCL.
Consulta datasets.
Submete o job.
Espera.
Consulta a saída.
Encontra:
MAXCC=0008
E começa a investigação.
🧙 CAPÍTULO 10 — COBOL ERA UMA PEÇA DA ENGRENAGEM
Este é um erro comum de quem começa:
"Mainframe é COBOL."
Não.
COBOL era uma das linguagens utilizadas naquele ecossistema.
Você poderia encontrar:
COBOL tornou-se extremamente importante porque encaixava muito bem no processamento comercial.
Cadastro.
Arquivo.
Registro.
Movimentação.
Totalização.
Relatório.
Validação.
Imagine:
READ CLIENTES
Depois:
IF SALDO < 0
Depois:
WRITE RELATORIO
Parece simples.
Agora execute isso sobre milhões de registros, diariamente, durante anos, com regras de negócio que não podem desaparecer.
Aí começa a engenharia de verdade.
🏪 CAPÍTULO 11 — CICS: A LOJA ABERTA
Batch resolve muita coisa.
Mas imagine alguém atendendo uma pessoa no balcão.
Ela não pode dizer:
"Ótimo. Colocarei sua consulta no batch desta noite. Volte amanhã."
Precisamos de processamento on-line.
Entra o monitor de transações.
Terminal solicita uma operação.
A transação é identificada.
Um programa é acionado.
Os dados são consultados.
A resposta retorna.
Algo como:
3270
↓
VTAM
↓
CICS
↓
TRANSACTION
↓
COBOL
↓
DATABASE / VSAM
Esse desenho é ancestral direto de muita arquitetura que hoje descrevemos utilizando termos como:
client
API gateway
service
database
Mudaram os nomes.
A necessidade continua reconhecível.
📡 CAPÍTULO 12 — ANTES DA INTERNET HAVIA UMA REDE INTEIRA
Outro erro histórico é imaginar:
"Antes da Internet os computadores não estavam conectados."
Estavam.
E muito.
Só que através de outras arquiteturas.
Um CPD poderia possuir centenas de linhas de comunicação.
Controladoras especializadas.
Terminais remotos.
Redes SNA.
X.25.
Token Ring.
Ethernet.
No mundo mainframe, VTAM desempenhava papel fundamental na comunicação.
Outros componentes cuidavam fisicamente e logicamente da rede.
Um terminal a centenas de quilômetros poderia estar conversando com uma aplicação central.
Portanto, processamento distribuído não nasceu com a Web.
O que a Internet fez foi transformar profundamente como redes diferentes se interconectavam.
🌐 CAPÍTULO 13 — E ENTÃO CHEGOU O TCP/IP
Em algum canto do CPD surge algo aparentemente pequeno:
TCP/IP
Hoje isso parece banal.
Naquele momento era uma revolução.
O CPD originalmente construído ao redor de redes corporativas proprietárias começava a conversar com o universo TCP/IP.
A arquitetura começou a ganhar pontes:
MAINFRAME
|
CHANNEL
|
GATEWAY
/ \
Ethernet
Token Ring
E depois:
LAN
|
ROUTER
|
INTERNET
É possível praticamente assistir à Internet entrando no datacenter.
🐧 CAPÍTULO 14 — UNIX CHEGA AO REINO
Em outra sala aparecem máquinas RISC executando UNIX.
Agora o discurso corporativo muda.
Palavras começam a aparecer:
downsizing.
cliente/servidor.
sistemas abertos.
processamento distribuído.
Alguns começam a profetizar:
"O mainframe acabou."
Spoiler vindo do século XXI:
não acabou.
Mas a mudança foi real.
UNIX trouxe um novo universo de desenvolvimento e administração.
Servidores poderiam executar:
Sistemas UNIX da época já ofereciam conceitos sofisticados como JFS, gerenciamento lógico de volumes, ferramentas centralizadas de administração e mecanismos de backup do sistema.
Agora tínhamos:
MAINFRAME
↕
SNA
↕
UNIX
↕
TCP/IP
↕
LAN
A palavra mágica passou a ser:
integração.
🖥️ CAPÍTULO 15 — O PC INVADE O CPD
Enquanto isso, outra revolução ocorre nas mesas.
Pentium.
DOS.
Windows.
OS/2.
NetWare.
Windows NT.
As aplicações começam a ganhar interfaces gráficas.
Planilhas eletrônicas.
Processadores de texto.
Bancos locais.
Ferramentas de desenho.
Gerenciamento de projetos.
O usuário começa a possuir poder computacional próprio.
Isso muda profundamente a relação entre usuário e CPD.
Antes:
"Preciso que o CPD faça."
Agora:
"Talvez eu consiga fazer aqui."
Nascia também um problema que conhecemos muito bem:
Shadow IT.
A planilha que vira sistema.
O banco local que vira cadastro oficial.
O script que ninguém documentou.
Nada realmente novo sob o Sol.
🔌 CAPÍTULO 16 — HUBS, SWITCHES E O ESPAGUETE
Imagine agora centenas de estações.
Cabos.
Patch panels.
Hubs.
Ethernet.
Token Ring.
Fibra óptica entre prédios.
Servidores.
Gateways.
Mainframe.
UNIX.
PC.
SNA.
TCP/IP.
X.25.
Essa é a origem do termo que aparecia cada vez mais:
ambiente heterogêneo.
O problema deixou de ser:
"Como fazer o computador funcionar?"
Passou a ser:
"Como fazer todos esses computadores conversarem?"
Reconheceu?
Em 2026 dizemos:
híbrido;
multicloud;
APIs;
eventos;
containers;
SaaS;
integração.
Mudaram as peças.
O problema continua familiar.
🖨️ CAPÍTULO 17 — A IMPRESSORA ERA UM MONSTRO
Há outra coisa difícil de explicar para quem cresceu no mundo digital.
Impressão era infraestrutura crítica.
Um CPD poderia possuir impressoras produzindo:
90 páginas por minuto.
Ou:
120 páginas por minuto.
E equipamentos de impacto medidos em linhas por minuto.
Por quê?
Porque muita informação terminava fisicamente em papel.
Folhas de pagamento.
Extratos.
Listagens.
Relatórios.
Faturas.
Documentos administrativos.
Formulários.
Uma aplicação não terminava necessariamente quando:
STOP RUN.
Ela poderia terminar quando 20 mil páginas estivessem impressas corretamente.
👷 CAPÍTULO 18 — O CPD ERA CHEIO DE GENTE
Agora retire as máquinas da fotografia.
Observe as pessoas.
Operadores.
Programadores.
Analistas.
Administradores de banco.
Especialistas de rede.
Suporte.
Produção.
Planejamento.
Segurança.
Armazenamento.
Telecomunicações.
Operadores de fita.
Técnicos.
O CPD não funcionava sozinho.
Havia procedimentos.
Checklists.
Janelas.
Escalas.
Passagem de turno.
Incidentes.
Autorizações.
O operador conhecia o comportamento da máquina.
Às vezes conseguia perceber que algo estava errado antes mesmo de o monitoramento emitir um diagnóstico conclusivo.
Uma fita demorou demais.
Um job normalmente terminava às 02:15 e eram 02:40.
A fila cresceu.
A impressora parou.
Uma aplicação começou a responder lentamente.
Isso era observabilidade humana.
🚨 CAPÍTULO 19 — 03:17
São 03:17 da madrugada.
Nosso tradicional easter egg apareceu.
O processamento de fechamento deveria estar terminando.
Mas um job está parado.
O operador olha a console.
Descobre que um dataset necessário não está disponível.
O próximo job depende daquele.
E outro depende do próximo.
Agora temos:
JOB A
↓
JOB B
↓
JOB C
↓
JOB D
↓
RELATÓRIOS
A falha de A ameaça toda a cadeia.
O telefone toca.
Produção chama suporte.
Suporte chama o analista.
O analista acorda.
Abre o terminal.
Investiga.
Quarenta anos depois chamaremos isso de:
incident response.
Naquela madrugada provavelmente chamavam de:
"A produção parou."
🧠 CAPÍTULO 20 — POR QUE AQUILO ERA TÃO CONFIÁVEL?
Não era magia.
Era engenharia somada a disciplina operacional.
O ambiente possuía ferramentas para:
Performance não era uma sensação.
Era medida.
CPU.
I/O.
Paginação.
Filas.
Discos.
Rede.
Tempo de resposta.
Throughput.
O ancestral de muito dashboard moderno já existia.
Só não tinha necessariamente gráfico colorido com fundo escuro.
🧬 CAPÍTULO 21 — O SEGREDO ERA A COMPATIBILIDADE
Existe uma lição particularmente importante.
Tecnologia corporativa não pode simplesmente acordar na segunda-feira e dizer:
"Resolvi reinventar tudo."
Existem dados.
Programas.
Interfaces.
Usuários.
Processos.
Auditoria.
Legislação.
Histórico.
Um programa criado para endereçamento de 24 bits podia continuar existindo quando a arquitetura evoluiu para 31 bits. Posteriormente, a evolução para 64 bits continuaria preservando mecanismos de compatibilidade.
Isso produz uma consequência curiosa:
software pode viver mais que hardware.
A CPU desaparece.
O disco desaparece.
A fita muda.
A rede muda.
O prédio muda.
Mas determinada regra COBOL continua existindo.
Porque a regra:
IF CLIENTE-ATIVO
AND SALDO > LIMITE
não pertence ao computador.
Pertence ao negócio.
🏺 CAPÍTULO 22 — NÃO ERA TECNOLOGIA PRIMITIVA
Talvez esta seja a conclusão mais importante.
É fácil olhar para:
32 MB
128 MB
200 MB por cartucho
10 Mbps
e rir.
Mas isso é presentismo tecnológico.
Estamos comparando números sem comparar problemas.
Aqueles sistemas já precisavam resolver:
São exatamente problemas que continuamos resolvendo.
☁️ CAPÍTULO 23 — O CPD NÃO MORREU: ELE FICOU INVISÍVEL
Hoje alguém abre o navegador e escreve:
https://...
Não vê o datacenter.
Não vê o disco.
Não vê a controladora.
Não vê o roteador.
Não vê o balanceador.
Não vê a fila.
Não vê o storage.
Não vê a replicação.
Não vê o backup.
Chamamos isso de:
cloud.
Mas a nuvem continua sendo feita de computadores.
O que mudou dramaticamente foi o nível de abstração.
No CPD antigo você enxergava a infraestrutura.
Hoje frequentemente enxergamos apenas:
service
database
queue
bucket
function
container
API
Alguém, em algum lugar, ainda precisa transformar isso em CPU, memória, rede e armazenamento.
🧙 CAPÍTULO 24 — O QUE O PROGRAMADOR COBOL INICIANTE DEVE APRENDER COM ISSO?
Primeiro:
COBOL nunca esteve sozinho.
Aprender COBOL sem compreender o ecossistema produz um programador limitado.
Entenda:
COBOL
JCL
JES
CICS
datasets
VSAM
banco de dados
storage
rede
segurança
monitoramento
Segundo:
aprenda o fluxo, não apenas a sintaxe.
Pergunte:
De onde vêm os dados?
Quem chama meu programa?
Quem cria o arquivo?
Quem consome minha saída?
O que acontece se eu retornar erro?
Existe restart?
Existe rollback?
Existe dependência?
Terceiro:
respeite o legado.
Legado não significa automaticamente ruim.
Significa:
algo que chegou até você vindo do passado.
Algumas coisas chegaram porque ninguém teve coragem de mexer.
Outras chegaram porque funcionam extraordinariamente bem.
Sua obrigação como engenheiro é descobrir qual das duas situações está diante de você.
🏁 EPÍLOGO — A CATEDRAL
Imagine novamente aquela sala.
Mainframe trabalhando.
Discos girando.
Cartuchos esperando.
Terminais verdes.
Impressoras rugindo.
Luzes piscando.
Operadores acompanhando consoles.
Programadores submetendo jobs.
Redes SNA atravessando quilômetros.
UNIX chegando.
Ethernet crescendo.
TCP/IP aparecendo.
PCs invadindo as mesas.
Internet batendo à porta.
Não estamos olhando para um monte de ferro velho.
Estamos olhando para uma catedral tecnológica construída por milhares de pessoas que resolveram problemas antes de nós.
Cada geração colocou uma pedra.
O operador.
O programador COBOL.
O especialista em Assembler.
O administrador do banco.
O analista de comunicação.
O técnico das fitas.
O administrador UNIX.
O sujeito que passou cabos pelo prédio.
O analista que ficou acordado às 03:17 porque o fechamento não terminou.
Talvez seus nomes tenham desaparecido.
Mas parte do pensamento que construíram permanece.
Quando você escreve uma API resiliente, pensa em idempotência, monitora uma fila, dimensiona storage, configura backup, analisa throughput ou investiga uma transação que desapareceu entre dois sistemas, está enfrentando descendentes dos mesmos problemas.
Por isso estudar um CPD do século passado não é nostalgia.
É estudar arqueologia da Engenharia de Software e da infraestrutura.
Porque os gabinetes mudaram.
Os discos encolheram.
A memória cresceu.
A fita virou cartucho, depois biblioteca robotizada.
SNA dividiu espaço com TCP/IP.
O terminal virou navegador.
O CPD virou datacenter.
O datacenter ganhou uma camada de abstração e passou a ser chamado de cloud.
Mas lá no fundo continuam existindo três perguntas que atravessaram toda a história da computação corporativa:
Onde estão meus dados?
Quem está processando meu trabalho?
E o que acontece quando alguma coisa falha às 03:17 da madrugada?
☕ Um Café no Bellacosa Mainframe
Porque antes de existir a nuvem havia uma sala gelada — e dentro dela pessoas construindo o futuro byte por byte.
