Bellacosa Mainframe e a ibm criando o mundo da informatica

☕ Um Café no Bellacosa Mainframe

Marvin Boggs Entra no Data Center — A IBM Inventou o Futuro, o Mercado Vendeu a Camiseta e o VSAM Continuou Processando a Folha

Ou: por que disco rígido, DRAM, SQL, máquinas virtuais, RISC, IMS, CICS e Db2 contam uma história muito mais interessante do que “a IBM perdeu a corrida” — e por que IBM Quantum merece atenção, mas não torcida organizada

Há posts que chegam ao LinkedIn vestindo terno, gravata e uma frase tão bonita que a gente quase entrega o crachá sem pedir identificação:

“IBM invented SQL, RISC, DRAM, virtual machines and the hard disk. Then other companies built billion-dollar businesses on top of them.”

A frase tem força. Ela também tem um pequeno problema: o mundo real não cabe inteiro em uma arte azul com linha do tempo brilhando.

Foi então que Marvin Boggs, aposentado da CIA, cozinheiro de omelete, mestre em armas e sobrevivente de mais emboscadas do que um programa COBOL com PERFORM THRU, entrou na sala de operações. Olhou o post, tomou um gole de café e disse:

“A história está boa. Mas, quando a história fica boa demais, alguém precisa abrir o porta-malas e conferir o inventário.”

Eis o inventário.

A IBM de fato ajudou a inventar boa parte da base sobre a qual a computação moderna foi construída. Não apenas aplicativos simpáticos, não apenas uma rede social da moda, não apenas uma ferramenta que gera uma imagem de astronauta usando chinelos. Estamos falando de infraestrutura: memória, armazenamento, banco de dados, processamento transacional, virtualização, segurança, linguagens e arquitetura de processadores.

Só que há uma diferença brutal entre inventar uma tecnologia, transformá-la em produto, montar um ecossistema, conquistar clientes e reter a maior fatia do lucro. A IBM foi, muitas vezes, a empresa que descobriu o novo continente. Outras empresas chegaram depois, abriram hotel, venderam souvenir e ficaram famosas no Instagram.

Para quem está começando em COBOL, esta distinção vale ouro. Criar uma ideia é uma parte do trabalho. Fazer algo rodar todo dia, com dado verdadeiro, auditoria, concorrência, segurança, recuperação e gente cobrando no telefone, é outra profissão.

1. A IBM não inventou “tudo”; ela inventou muitas das fundações

Comecemos sem exagero e sem falsa modéstia.

Em 1956, o IBM 350 RAMAC ajudou a inaugurar a era do disco rígido comercial. Ele armazenava cerca de 5 MB e ocupava espaço suficiente para fazer qualquer pessoa que hoje reclama de um SSD de 256 GB refletir sobre a própria sorte. Não era um pendrive brilhante; era um armário industrial com discos enormes.

A ideia essencial, porém, era revolucionária: guardar dados com acesso relativamente direto, em vez de depender apenas de cartões perfurados ou fitas sequenciais.

Pense em um arquivo sequencial COBOL. Se você precisa achar o cliente 00084521, talvez tenha de ler registro após registro até encontrá-lo. Isso é como Marvin procurar uma caixa de munição no porão lendo cada etiqueta de cada prateleira.

O disco rígido mudou o jogo porque permitiu organizar dados para encontrá-los com mais liberdade. Depois vieram índices, sistemas de arquivos, bancos de dados, caches, estruturas de armazenamento e tudo aquilo que faz um SELECT parecer simples para quem não está olhando o motor.

Em 1966, Robert Dennard, pesquisador da IBM, criou a célula moderna de DRAM: um transistor e um capacitor para representar um bit. Essa ideia diminuiu drasticamente o custo de memória e tornou possível escalar computadores de forma que a memória de núcleo magnético nunca permitiria.

Quando você abre uma planilha gigante, inicia um navegador cheio de abas, carrega um modelo de IA ou executa um programa COBOL que precisa manter tabelas em memória, há uma linhagem técnica que passa por ali. DRAM não é glamour. DRAM é água encanada: só lembramos dela quando falta.

Em 1970, Edgar F. Codd, também da IBM, publicou o modelo relacional. Depois, Donald Chamberlin e Raymond Boyce desenvolveram a linguagem inicialmente chamada SEQUEL, que evoluiu para SQL.

Aqui vale uma pausa, jovem padawan do EXEC SQL.

Quando você escreve:

EXEC SQL
    SELECT NOME-CLIENTE
      INTO :WS-NOME-CLIENTE
      FROM CLIENTE
     WHERE CPF = :WS-CPF
END-EXEC

você não está apenas usando uma sintaxe conveniente. Você está participando de uma revolução conceitual: pedir o que quer, em vez de programar passo a passo como encontrar cada registro.

No arquivo tradicional, você muitas vezes diz: abra, leia, compare, avance, compare de novo, trate fim de arquivo. No modelo relacional, você declara o conjunto de dados desejado. O otimizador escolhe um caminho de acesso. É como dizer a Marvin: “quero os documentos daquele sujeito”, em vez de obrigá-lo a revistar manualmente cada gaveta do prédio.

SQL não nasceu pronto, perfeito e vencedor absoluto. Outros bancos e modelos coexistiram. Mas a ideia relacional venceu de modo tão profundo que até quem hoje diz “sou do NoSQL” costuma trabalhar em uma empresa cujo dinheiro, faturamento, estoque, cadastro e auditoria ainda terminam em tabelas.

2. Máquinas virtuais: antes da cloud ter nome bonito

Outro ponto frequentemente resumido demais é a virtualização.

Projetos da IBM, como M44/44X, CP-40 e CP/CMS, foram decisivos para provar que um computador físico podia parecer vários computadores independentes para seus usuários. Cada ambiente tinha a ilusão controlada de possuir máquina, memória e sistema próprios.

Isso é mais antigo do que muitos discursos modernos sobre cloud.

Não, uma máquina virtual da década de 1960 não era AWS, Kubernetes, Docker ou um notebook de cientista de dados. Mas a pergunta fundamental já estava ali:

Como compartilhar uma máquina cara entre vários usuários sem deixar um derrubar o trabalho do outro?

A resposta envolvia isolamento, agendamento, controle de recursos e uma camada de software muito inteligente entre o hardware e o usuário. Parece familiar?

Hoje, uma empresa fala em “multi-tenant”, “workload isolation”, “elasticidade” e “infraestrutura como serviço”. No mainframe, o avô dessa conversa já sabia que dividir recurso sem disciplina termina em briga, lentidão e incidente.

Marvin Boggs resumiria assim:

“Coloque cinco agentes no mesmo carro sem regra e você não tem uma operação. Tem uma perseguição.”

3. RISC: o motor enxuto que ensinou eficiência

A IBM também foi protagonista no projeto 801, uma experiência de arquitetura que ajudou a consolidar a filosofia RISC — Reduced Instruction Set Computer.

A provocação do RISC era quase ofensiva para a época: em vez de criar processadores cheios de instruções complexas, por que não simplificar o conjunto de instruções, executar operações mais previsíveis e deixar compiladores e pipelines trabalharem melhor?

Essa linha de pensamento influenciou famílias como POWER, ARM, MIPS e SPARC. Hoje, ARM está em celulares, servidores, notebooks e dispositivos embarcados. RISC-V cresce como arquitetura aberta. POWER continua importante em nichos de alto desempenho.

A IBM não ficou “fora” dessa história; ela ajudou a escrevê-la. Mas não é dona de todos os frutos comerciais dela.

E isso nos leva ao primeiro ensinamento de Marvin:

“Ser o cara que desenha a arma não garante que você será o cara que vende a arma, distribui a arma, treina o exército e aparece na capa da revista.”

 

4. A  IBM construiu a sala de máquinas

Até aqui falamos de invenções que qualquer pessoa de tecnologia reconhece. Mas, para quem trabalha com COBOL e IBM Z, o coração da conversa começa agora.

Porque a IBM não inventou apenas peças soltas. Ela construiu uma espécie de modelo operacional da computação corporativa. E parte desse modelo continua rodando, atualizada, robusta e silenciosa — exatamente como os melhores sistemas costumam ser.

IMS: quando a missão era literalmente chegar à Lua

O IMS — Information Management System — surgiu nos anos 1960, associado à necessidade de gerenciar dados do programa Apollo. Antes de ser uma relíquia de museu, IMS tornou-se uma plataforma gigantesca de banco de dados hierárquico e processamento de transações.

Hierárquico significa que os dados são organizados como árvore: um pai pode ter filhos, e estes podem ter seus próprios filhos. Não é o mesmo modelo tabular do Db2. Não se começa com JOIN; começa-se entendendo caminhos, segmentos, dependências e a estrutura da informação.

Para um iniciante, imagine:

CLIENTE
 ├── CONTA
 │    ├── LANCAMENTO
 │    └── LANCAMENTO
 └── CARTAO
      └── FATURA

Esse modelo pode parecer menos flexível que tabelas relacionais. Em troca, quando é bem desenhado para um fluxo conhecido e repetitivo, pode ser extremamente eficiente e previsível.

É por isso que IMS continua em ambientes onde “previsível” vale mais do que “bonito no slide”. Reserva aérea, seguro, saúde, telecomunicações e processos bancários não querem descobrir uma nova forma artística de consultar dados às 16h59 de uma sexta-feira.

CICS: o sujeito que mantém a multidão organizada

CICS — Customer Information Control System — é uma das maiores demonstrações de engenharia empresarial já produzidas.

Em um mundo de batch, o modelo era simples: prepare dados, envie o job, espere o processamento, receba a saída. Era como deixar uma pilha de dossiês na mesa de Marvin e voltar no dia seguinte para ver o resultado.

Mas empresas queriam interação. O atendente precisava consultar um cliente agora. A agência precisava efetuar uma operação agora. O passageiro precisava reservar a poltrona agora. E “agora”, quando milhares de pessoas fazem pedidos ao mesmo tempo, é uma palavra perigosíssima.

CICS ajudou a resolver isso com controle de transações, unidades de trabalho, recuperação, concorrência, segurança e gerenciamento de recursos. Ele é um monitor transacional: uma central que recebe pedidos, encaminha programas, protege recursos e garante que a operação não fique meio feita.

Em termos simples, uma transação precisa ter um destino claro:

• fez tudo corretamente: COMMIT;

• deu errado no meio: ROLLBACK ou recuperação;

• o usuário caiu: a integridade não pode cair junto;

• dois usuários disputam o mesmo dado: alguém precisa controlar a fila.

Sem esse tipo de disciplina, o sistema vira um filme de ação ruim: vinte pessoas correndo, ninguém sabe quem está com a chave, e o cofre abre na hora errada.

Hoje há servidores de aplicação, APIs, filas, microsserviços e plataformas cloud. Mas o problema fundamental não mudou: como realizar operações concorrentes sem corromper o negócio? CICS resolveu isso em escala industrial décadas antes de “transactional microservice” virar expressão de consultoria.

VSAM: o arquivo que muita gente subestima até o primeiro incidente

VSAM — Virtual Storage Access Method — merece mais respeito do que recebe.

Ele não é “apenas um arquivo antigo”. É uma família de métodos de acesso organizada para lidar com dados de modo eficiente, controlado e integrado ao ecossistema z/OS. Para o desenvolvedor COBOL, VSAM costuma aparecer quando alguém fala de KSDS, ESDS, RRDS e LDS.

O mais conhecido é o KSDS — Key-Sequenced Data Set. Nele, os registros são mantidos por chave. Você pode recuperar um cliente pelo CPF, uma apólice pelo número, um contrato por sua identificação.

A ideia é intuitiva:

MOVE WS-CPF TO CLIENTE-CPF
READ ARQ-CLIENTE
    KEY IS CLIENTE-CPF
    INVALID KEY
        DISPLAY 'CLIENTE NAO ENCONTRADO'
END-READ

Não é magia. É um acordo entre programa, estrutura de dados, índices e regras de atualização.

O grande valor do VSAM é que ele representa uma escola de pensamento: dados não são uma coleção de linhas jogadas em algum lugar. Dados têm chave, ordenação, acesso, recuperação, espaço, concorrência e comportamento operacional.

Um desenvolvedor iniciante que aprende VSAM bem entende melhor bancos de dados, índices, cache, armazenamento chave-valor e até o motivo pelo qual certos SELECTs viram monstros quando o índice não acompanha a pergunta.

Db2: SQL entra no mundo onde erro custa dinheiro

Db2 não é apenas “o banco onde escrevemos SQL”. Db2 é o encontro entre o modelo relacional e o padrão de exigência de ambientes críticos.

Há COMMIT, ROLLBACK, isolamento, bloqueio, log, recuperação, controle de privilégios, planos de acesso, packages, bind e auditoria. A SQL que aparece na tela é a ponta visível de uma máquina muito maior.

Quando o novato pergunta por que uma consulta que funcionou no SPUFI está lenta na aplicação Java, a resposta não é “porque Db2 é velho”. Pode ser plano de acesso, estatísticas, fetch size, conexão, package, volume de rede, concorrência ou desenho ruim da consulta.

Db2 ensina uma lição que serve para toda a tecnologia:

Uma instrução curta pode acionar um mecanismo enorme.

O SELECT cabe em cinco linhas. O caminho para executá-lo com segurança pode envolver catálogo, otimização, índices, buffer pools, locks, pagesets, logging, CPU, I/O e regras de disponibilidade.

Marvin chamaria isso de “não confundir o tamanho do gatilho com o tamanho da explosão”.

5. RACF, JES2, z/OS: o futuro também mora nas coisas pouco fotogênicas

Há ainda componentes que raramente entram no infográfico porque não cabem em uma frase de efeito.

RACF faz controle de identidade e acesso. JES2 organiza a vida do batch, spool, filas e saída de jobs. TSO/ISPF oferece ambiente de trabalho. SMP/E mantém software em ordem. WLM ajuda a priorizar cargas. Sysplex e Parallel Sysplex elevam disponibilidade e escala a um nível que muitos ambientes distribuídos ainda tentam alcançar com dezenas de ferramentas.

Nada disso parece tão sedutor quanto “IA quântica neuro-sinérgica em 0,7 nanômetros”. Mas, quando há salário para pagar, PIX para processar, apólice para emitir ou remédio para entregar, é justamente esse conjunto aparentemente pouco glamoroso que separa operação de aventura.

O universo moderno inventou nomes novos para velhos problemas:

Nome moderno	Pergunta que o mainframe já enfrentava
IAM e Zero Trust	Quem é você e o que pode acessar?
Observabilidade	Onde está o problema e qual recurso está saturado?
Orquestração	Qual trabalho roda primeiro e com que prioridade?
Alta disponibilidade	Como continuar mesmo quando algo quebra?
Governança	Quem aprovou, alterou e pode reverter?
FinOps	Quanto custa manter este processamento?

Não é que o mainframe tenha inventado cada termo. É que ele amadureceu enfrentando os problemas antes de eles ganharem nomes de mercado.

6. Anthropic: aqui, Marvin pede prova antes de apertar o gatilho

A alegação de que a IBM transferiu patentes de IA para a Anthropic em 2025 precisa ser tratada com cuidado.

Houve registro de transferência de uma carteira de patentes da IBM para a Anthropic, associada a técnicas de IA e treinamento distribuído. Isso pode ser relevante. Patentes podem dar liberdade de operação, fortalecer posição jurídica, facilitar parceria e proteger implementações específicas.

Mas não se deve concluir que:

• a IBM inventou a Anthropic;

• a IBM “deu os transformers” para Claude;

• as patentes explicam sozinhas o crescimento da Anthropic;

• Anthropic se tornou grande por causa dessa transferência.

A arquitetura transformer foi popularizada por pesquisadores do Google em 2017. Além disso, uma patente costuma cobrir uma técnica particular, e não “a inteligência artificial inteira”.

Em outubro de 2025, IBM e Anthropic anunciaram uma parceria voltada a IA empresarial, integração de Claude, segurança e governança. Isso é relevante, mas não é uma prova de paternidade tecnológica total. É parceria, estratégia e mercado.

A regra de ouro para quem trabalha em TI é simples:

Se uma frase transforma uma transação de patentes em explicação única para uma empresa bilionária, desconfie como se fosse um S0C7 logo depois de uma alteração “pequena”.

7. IBM Quantum: atenção, sim; promessa automática, não

E o IBM Quantum? Ele merece atenção séria.

Computação quântica trabalha com fenômenos físicos que permitem representar e manipular estados de maneira muito diferente de bits clássicos. Mas não significa que um computador quântico será um “mainframe mais rápido” nem que ele vai fazer seu programa COBOL rodar em 0,0001 segundo.

São máquinas voltadas a categorias específicas de problemas: simulação de moléculas e materiais, certos problemas matemáticos, química, otimização e, no futuro, desafios criptográficos.

O problema não é só fabricar muitos qubits. Qubits sofrem ruído. Um cálculo pode morrer por erro antes de produzir resultado útil. A grande batalha é correção de erros: usar muitos qubits físicos para formar qubits lógicos confiáveis e corrigir falhas em tempo real.

A IBM trabalha publicamente nessa rota, combinando hardware quântico, software Qiskit, técnicas de mitigação de erros e computação clássica de alto desempenho. Seu roteiro aponta para sistemas tolerantes a falhas no fim da década. É uma meta técnica ambiciosa, não uma garantia escrita em pedra.

O cenário provável não é substituição; é cooperação:

1. o sistema corporativo guarda dados e executa transações;

2. uma camada clássica prepara o problema;

3. o acelerador quântico é chamado apenas na parte em que pode gerar vantagem;

4. o resultado volta para validação, auditoria e decisão humana ou automatizada.

O mainframe não some nessa equação. Ele pode continuar sendo o sistema de registro, a fortaleza de dados e o motor transacional. O quântico, se cumprir a promessa, será mais parecido com uma GPU especializada: uma peça poderosa chamada para resolver algo muito particular.

8. O que a IBM está construindo hoje que pode virar padrão amanhã?

A resposta mais honesta não é “uma coisa só”.

Pode ser a combinação de computação quântica, criptografia pós-quântica, IA governada, modelos empresariais menores e eficientes, automação, chips especializados e infraestrutura híbrida.

Mas talvez o ativo mais subestimado seja a experiência histórica da IBM em lidar com a pergunta que o entusiasmo pela IA costuma evitar:

Como fazer uma tecnologia poderosa operar com segurança, custo controlado, dados reais, auditoria e responsabilidade?

Um chatbot que escreve um e-mail é interessante. Um agente que consulta dados corporativos, decide, move dinheiro, abre chamado, altera cadastro ou aprova crédito é outra conversa. Nesse nível, não basta a IA responder bonito. Ela precisa ser explicável, controlada, monitorada, autorizada e reversível.

Isso é território conhecido de quem vive CICS, Db2, RACF, MQ, logs, COMMIT, ROLLBACK, batch crítico e auditoria.

O programador COBOL iniciante não deve olhar para IA ou computação quântica como quem vê um meteoro vindo destruir sua carreira. Deve olhar como Marvin olha para uma arma nova: entender o que ela faz, o que ela não faz, quem controla e para onde está apontada.

Epílogo — a IBM inventou o amanhã, mas o hoje ainda precisa fechar

A frase original está certa em espírito: a IBM tem uma tradição excepcional de inventar tecnologias que amadurecem e viram fundações do mercado.

Mas a versão adulta da história é melhor.

A IBM ajudou a criar o disco rígido comercial, a DRAM moderna, o pensamento relacional, SQL, virtualização e caminhos para RISC. Também criou — ou consolidou em escala — IMS, CICS, VSAM, Db2, RACF, JES2 e uma forma inteira de pensar computação corporativa.

Enquanto o mercado discute a próxima plataforma, essas crias continuam processando o presente.

Elas processam sem fazer barulho. Não pedem curtida. Não viram dancinha. Não saem do ar porque o estagiário atualizou uma biblioteca às 18h de sexta-feira.

Talvez IBM Quantum seja uma semente decisiva do próximo grande ciclo. Talvez IA governada e criptografia pós-quântica sejam apostas ainda mais próximas e práticas.

Mas, antes de procurar a próxima invenção da IBM, vale olhar para o porão do prédio: há décadas, VSAM encontra registros, IMS coordena dados, CICS protege transações, Db2 preserva integridade e RACF pergunta quem está tentando abrir a porta.

Marvin Boggs termina o café, confere o carregador e deixa o conselho final:

“O futuro é ótimo. Só não deixe ninguém vender uma maquete como se fosse o prédio. E, enquanto todo mundo olha para o foguete, confirme se alguém ainda sabe manter o cofre funcionando.”