Bellacosa Mainframe apresenta herman hollerith

☕ Um Café no Bellacosa Mainframe

O Paciente 1890: Herman Hollerith, Cartões Perfurados e o Dia em que o Big Data Entrou na Sala de Emergência

Imagine a cena.

Ano: 1890.

Local: Estados Unidos.

Na sala de emergência não há médicos, estetoscópios ou aparelhos de ressonância magnética.

Há funcionários públicos.

Muitos funcionários públicos.

Montanhas de papel.

Tabelas.

Listas.

Canetas.

Calculadoras mecânicas.

E um paciente em estado crítico.

O nome do paciente?

Censo dos Estados Unidos.

Sintomas?

Excesso de dados.

Processamento lento.

Escalabilidade praticamente inexistente.

Grande risco de erro humano.

Diagnóstico preliminar?

A população americana estava crescendo mais rápido do que a capacidade do governo de contar a própria população.

Se o Dr. House fosse analista de sistemas em 1890, provavelmente entraria na sala, olharia para aquelas toneladas de papel e diria:

— Não precisamos de mais funcionários. Precisamos parar de fazer isso como idiotas.

E, surpreendentemente, foi mais ou menos isso que Herman Hollerith percebeu.

A solução não seria contratar milhares de pessoas adicionais.

Seria automatizar o processamento dos dados.

E nesse momento começa uma das histórias mais importantes da computação.

Não com um computador eletrônico.

Não com COBOL.

Não com IBM.

Não com System/360.

Nem sequer com válvulas.

A história começa com um pedaço de papel perfurado.

E uma pergunta que ainda hoje atormenta qualquer programador COBOL trabalhando em um banco:

Como processar milhões de registros de maneira rápida, previsível e confiável?

Bem-vindo ao episódio de hoje do nosso hospital tecnológico.

Pegue o café.

O paciente tem aproximadamente 136 anos.

E, surpreendentemente, continua vivo.

🩺 Capítulo 1 — O paciente apresenta sintomas graves

Para entender Hollerith, precisamos primeiro entender o problema.

A Constituição dos Estados Unidos exige que o governo realize periodicamente um censo da população.

Isso não era apenas curiosidade estatística.

Os dados do censo influenciavam questões importantes como representação política, planejamento público e distribuição de recursos.

No século XIX, entretanto, coletar dados significava basicamente escrever coisas em papel.

Imagine milhões de pessoas respondendo perguntas como:

nome,

idade,

sexo,

profissão,

estado civil,

origem,

local de residência,

ocupação.

Agora imagine funcionários tentando transformar tudo isso em estatísticas nacionais.

Sem Excel.

Sem SQL.

Sem Python.

Sem Db2.

Sem SORT.

Sem DFSORT.

Sem ICETOOL.

Sem absolutamente nada que um programador moderno reconheceria como ferramenta computacional.

Era processamento humano.

O censo americano de 1880 havia se tornado particularmente problemático.

Sua tabulação completa levou muitos anos.

E aqui apareceu um problema assustador.

Se a população continuasse crescendo, existia o risco de o processamento de um censo não terminar antes do próximo começar.

Isso, em linguagem moderna, seria algo semelhante a executar:

JOB CENSUS80

START: 1880
END:   1888

e descobrir:

NEXT JOB: CENSUS90
START: 1890

O SLA já estava basicamente condenado.

Podemos imaginar o JES emitindo:

IEF450I CENSUS80 - TIME LIMIT EXCEEDED

Claro que JES ainda não existia.

Mas o problema operacional era exatamente esse.

🧠 Capítulo 2 — O diagnóstico de Hollerith

Herman Hollerith era engenheiro e estatístico.

Ele percebeu algo fundamental:

o gargalo não estava na coleta dos dados.

Estava na transformação dos dados em informação.

Essa distinção é importantíssima.

Até hoje empresas confundem essas duas coisas.

Ter dados não significa possuir informação.

Você pode ter:

10 bilhões de registros,

500 TB de logs,

milhões de transações,

anos de arquivos históricos.

Mas se não conseguir processá-los corretamente, eles têm valor limitado.

Em outras palavras:

DADO ≠ INFORMAÇÃO

Para transformar dado em informação precisamos de processamento.

E Hollerith procurou uma maneira de representar características humanas de forma que uma máquina pudesse identificá-las.

Nascia a ideia das perfurações codificadas.

🕳️ Capítulo 3 — O cartão perfurado entra no hospital

Pense em um cartão de papel.

Cada posição possível no cartão representa determinada informação.

Uma perfuração naquela posição significa uma coisa.

Ausência de perfuração significa outra.

Simplificando bastante:

IDADE   SEXO   ESTADO   PROFISSÃO
  |      |       |         |
  O      O       O         O

Hoje pensaríamos nisso como bits.

Algo semelhante a:

Naturalmente o sistema de Hollerith era diferente dos bits modernos.

Mas o conceito fundamental estava ali:

representar informação utilizando estados fisicamente detectáveis.

Em um computador moderno temos:

tensão alta  → 1
tensão baixa → 0

No cartão perfurado poderíamos pensar:

furo     → informação presente
sem furo → informação ausente

O papel havia se transformado em meio de armazenamento legível por máquina.

Isso é extraordinário.

Porque naquele momento aconteceu algo conceitualmente gigantesco:

a informação deixou de ser apenas legível por seres humanos.

Agora também podia ser interpretada mecanicamente.

⚡ Capítulo 4 — Como aquela geringonça funcionava?

Agora chegamos ao mecanismo digno de laboratório.

A tabuladora de Hollerith empregava contatos elétricos.

Um cartão era colocado sobre um conjunto de posições.

Agulhas metálicas desciam.

Quando encontravam papel:

nada acontecia.

Quando encontravam uma perfuração:

atravessavam o cartão e fechavam um contato elétrico, originalmente envolvendo recipientes com mercúrio.

Esse circuito acionava contadores.

Em versão simplificada:

CARTÃO
   ↓
LEITOR MECÂNICO
   ↓
DETECÇÃO DO FURO
   ↓
CIRCUITO ELÉTRICO
   ↓
CONTADOR
   ↓
RESULTADO

Não temos CPU.

Não temos memória RAM.

Não temos sistema operacional.

Mas temos algo importantíssimo:

entrada → processamento → saída.

A santa trindade da computação já estava ali.

💾 Capítulo 5 — O primeiro record que você nunca programou

Agora vamos trazer isso para o COBOL.

Você escreve:

01 WS-PESSOA.
   05 WS-IDADE       PIC 9(03).
   05 WS-SEXO        PIC X.
   05 WS-ESTADO      PIC X(02).
   05 WS-PROFISSAO   PIC X(20).

Para você isso é um registro.

Um record.

Mas pense no cartão de Hollerith como exatamente isso.

Cada cartão representava uma entidade.

Por exemplo:

Pessoa 000001
Pessoa 000002
Pessoa 000003
Pessoa 000004

Ou seja:

um cartão = um registro físico.

Décadas depois teríamos:

registro em fita
registro em disco
registro VSAM
linha Db2
documento JSON
mensagem MQ
evento Kafka

O suporte mudou.

O conceito permaneceu.

Essa é uma das grandes lições da computação.

Tecnologias desaparecem.

Abstrações sobrevivem.

📦 Capítulo 6 — Bem-vindo ao primeiro dataset de papel

Imagine agora dez mil cartões.

Você coloca todos dentro de uma caixa.

Parabéns.

Criamos aproximadamente isto:

CENSUS.PEOPLE.DATA

Claro que o dataset não existia literalmente.

Mas conceitualmente temos:

DATASET
  |
  +-- RECORD
  +-- RECORD
  +-- RECORD
  +-- RECORD

Na época:

CAIXA
  |
  +-- CARTÃO
  +-- CARTÃO
  +-- CARTÃO
  +-- CARTÃO

Você percebe como a evolução começa a ficar interessante?

O mainframe moderno não apareceu magicamente em 1964.

Existe uma longa linhagem intelectual.

🔀 Capítulo 7 — E então inventamos o SORT antes do SORT

Agora aparece outro problema.

Você tem milhares de cartões.

Mas eles estão misturados.

Pessoas de Nova York.

Texas.

Califórnia.

Homens.

Mulheres.

Crianças.

Profissões diferentes.

Se quiser saber quantas pessoas vivem em determinado estado, precisa agrupar os registros.

Entram em cena as máquinas classificadoras.

Elas separavam cartões conforme determinadas perfurações.

Em linguagem mainframe:

SORT FIELDS=(ESTADO,A)

Mais tarde:

SORT FIELDS=(SEXO,A,IDADE,A)

Talvez você nunca tenha pensado nisso dessa maneira, mas o humilde SORT possui uma ancestralidade muito antiga.

Hoje escrevemos:

//SORTSTEP EXEC PGM=SORT
//SYSOUT   DD SYSOUT=*
//SORTIN   DD DSN=ENTRADA,DISP=SHR
//SORTOUT  DD DSN=SAIDA,
//            DISP=(NEW,CATLG,DELETE)
//SYSIN    DD *
 SORT FIELDS=(1,2,CH,A)
/*

Em 1890 alguém precisava fazer essencialmente isto:

PEGAR CARTÕES
↓
IDENTIFICAR CAMPO
↓
SEPARAR
↓
AGRUPAR
↓
CONTAR

Mudou a interface.

A lógica sobreviveu.

🏭 Capítulo 8 — Nasce o batch

Batch significa lote.

Literalmente.

Um conjunto de coisas processadas juntas.

Imagine um operador chegando com 5.000 cartões.

Ele coloca o lote na máquina.

Executa determinado processamento.

Retira o resultado.

Depois vem o lote seguinte.

Temos então:

BATCH 001
BATCH 002
BATCH 003

Décadas depois:

JOB001
JOB002
JOB003

Hoje, no z/OS:

JES2
 ↓
JOB
 ↓
STEP
 ↓
PROGRAM
 ↓
DATASET

O hardware mudou dramaticamente.

Mas a ideia de separar processamento em unidades controláveis continuou.

🧾 Capítulo 9 — O ancestral espiritual do JCL

Imagine precisar entregar cartões para uma máquina.

Alguns cartões representam dados.

Outros poderiam representar instruções.

Décadas depois, computadores baseados em cartões adotariam exatamente essa lógica.

Um deck poderia conter:

JOB CONTROL
PROGRAM
INPUT DATA

Quando apareceu JCL, a filosofia já era familiar.

Você não apenas fornecia dados.

Também descrevia:

qual programa executar,

quais arquivos utilizar,

onde colocar a saída,

o que fazer em caso de erro.

Exemplo:

//BELLACOS JOB CLASS=A,MSGCLASS=X
//STEP01   EXEC PGM=MEUPGM
//ENTRADA  DD DSN=CLIENTES.MASTER,DISP=SHR
//SAIDA    DD DSN=CLIENTES.REPORT,
//            DISP=(NEW,CATLG,DELETE)

O JCL é muito mais sofisticado, evidentemente.

Mas seu espírito pertence a uma tradição antiga:

definir um trabalho de forma estruturada e reproduzível.

🧬 Capítulo 10 — A genealogia do mainframe

Agora precisamos desmontar um mito.

IBM não nasceu fazendo computadores.

Hollerith fundou uma empresa chamada:

Tabulating Machine Company.

Ela produzia equipamentos para processamento de informações.

Em 1911, sua empresa participou de uma consolidação empresarial que resultou na:

Computing-Tabulating-Recording Company — CTR.

Depois apareceu um personagem fundamental:

Thomas J. Watson Sr.

Em 1924, a CTR passou a utilizar o nome:

International Business Machines.

IBM.

Veja a genealogia:

Herman Hollerith
      ↓
Tabulating Machine Company
      ↓
CTR
      ↓
IBM
      ↓
máquinas de cartões
      ↓
computadores eletrônicos
      ↓
IBM System/360
      ↓
System/370
      ↓
S/390
      ↓
zSeries
      ↓
IBM Z

Agora fica muito mais fácil entender por que processamento de dados está praticamente no DNA da IBM.

🏥 Capítulo 11 — House entra na sala e pergunta: qual é a doença?

Qual era realmente a doença do censo?

Não era falta de dados.

Era incapacidade de processá-los suficientemente rápido.

Vamos chamar isso de:

DATA PROCESSING BOTTLENECK

Agora avance para 2026.

Uma empresa possui:

logs,

transações,

dados de sensores,

histórico de clientes,

documentos,

streams,

imagens,

telemetria.

Ela diz:

— Temos Big Data.

House provavelmente responderia:

— Não. Você tem Big Storage. Só vira Big Data quando consegue fazer alguma coisa útil com isso.

Essa distinção continua absolutamente válida.

🏦 Capítulo 12 — Imagine Hollerith trabalhando em um banco

Vamos trazer tudo para um cenário COBOL.

Suponha que você trabalhe em um banco.

Todo final do dia chegam milhões de transações.

Precisamos:

ler movimentos;
validar registros;
ordenar por conta;
atualizar saldo;
calcular juros;
gerar extratos;
produzir relatórios;
guardar histórico.

Fluxo:

TRANSAÇÕES
     ↓
VALIDAÇÃO
     ↓
SORT
     ↓
PROGRAMA COBOL
     ↓
ATUALIZAÇÃO
     ↓
RELATÓRIO

Agora coloque Hollerith em 1890:

CARTÕES
   ↓
VALIDAÇÃO
   ↓
CLASSIFICAÇÃO
   ↓
TABULAÇÃO
   ↓
CONTAGEM
   ↓
RELATÓRIO

Não é a mesma tecnologia.

Mas existe uma impressionante continuidade arquitetural.

🗃️ Capítulo 13 — O ancestral conceitual do arquivo mestre

Programadores COBOL antigos conhecem muito bem o conceito de:

MASTER FILE

Você possui um arquivo principal.

Por exemplo:

CLIENTES.MASTER

Durante o dia chegam movimentos:

CLIENTES.MOVIMENTO

À noite:

MASTER + MOVIMENTO
          ↓
       UPDATE
          ↓
     NOVO MASTER

Essa filosofia aparece naturalmente quando dados físicos precisam ser organizados em grandes conjuntos.

Com cartões, era comum trabalhar com conjuntos classificados que precisavam ser combinados, atualizados ou contados.

O mundo do processamento comercial nasceu muito antes do COBOL.

COBOL apenas herdou uma tradição.

💳 Capítulo 14 — Por que o cartão IBM tinha 80 colunas?

Aqui vem uma curiosidade que todo iniciante em COBOL deveria conhecer.

O famoso cartão perfurado IBM consolidou-se em um formato de 80 colunas.

Isso teve impacto gigantesco na programação.

Programas COBOL tradicionais eram organizados respeitando posições específicas.

Simplificando:

1-6    sequência
7      indicador
8-11   área A
12-72  área B
73-80  identificação

Por que essas limitações aparentemente estranhas?

Porque código-fonte era armazenado em cartões físicos.

Uma linha:

um cartão.

Um programa de 2.000 linhas?

Aproximadamente 2.000 cartões.

Agora imagine derrubar a caixa.

Bem-vindo ao ABEND psicológico.

Por isso existiam números sequenciais.

Se os cartões caíssem no chão, você poderia reorganizá-los.

Provavelmente rezando para qualquer entidade disponível no CPACF espiritual.

🥚 Easter Egg #1 — O verdadeiro motivo da coluna 72

Quando um iniciante pergunta:

— Por que COBOL antigo às vezes parece ter medo de passar da coluna 72?

Não era superstição.

Era arqueologia de hardware.

A linguagem carrega fósseis tecnológicos.

Assim como nosso corpo carrega estruturas herdadas da evolução, linguagens antigas carregam estruturas herdadas das máquinas onde nasceram.

House aprovaria a analogia.

⚙️ Capítulo 15 — Do cartão ao VSAM

Agora acompanhe a evolução conceitual.

Primeiro:

cartão

Depois:

fita magnética

Depois:

disco

Depois:

arquivos organizados

Depois:

VSAM

No VSAM podemos ter:

KSDS,

ESDS,

RRDS,

LDS,

entre outros.

Mas observe o princípio fundamental:

armazenar registros de maneira organizada para recuperação e processamento previsíveis.

Esse princípio não nasceu com VSAM.

VSAM é uma sofisticada manifestação de uma ideia muito mais antiga.

🗄️ Capítulo 16 — E depois chegou o banco de dados

Imagine então perceber:

— Talvez não seja muito inteligente cada programa manter seu próprio arquivo independente.

Entram bancos de dados.

IMS.

Db2.

Agora podemos representar informações utilizando estruturas relacionais.

Exemplo:

SELECT ESTADO,
       COUNT(*)
FROM PESSOA
GROUP BY ESTADO;

Hollerith provavelmente entenderia imediatamente o objetivo.

Ele apenas ficaria fascinado com a velocidade.

Sua máquina fazia contagens mecanicamente.

Db2 pode realizar operações sobre milhões ou bilhões de registros utilizando processadores moderníssimos.

Mas a pergunta continua:

Quantas pessoas pertencem a determinada categoria?

🔍 Capítulo 17 — GROUP BY é descendente intelectual da tabuladora

Pense:

SELECT SEXO, COUNT(*)
FROM CENSO
GROUP BY SEXO;

Agora volte a 1890.

A máquina identifica determinadas perfurações.

Separa.

Conta.

Produz totais.

Conceitualmente:

READ
GROUP
COUNT
REPORT

Esse é provavelmente o aspecto mais bonito dessa história.

Não estamos olhando apenas para hardware velho.

Estamos vendo ideias computacionais em estado embrionário.

📊 Capítulo 18 — Big Data já existia antes de chamarmos de Big Data

Naturalmente não existiam petabytes em 1890.

Mas Big Data é relativo.

Um dataset é "grande" quando começa a superar nossa capacidade prática de processá-lo utilizando métodos existentes.

Para 1890, milhões de registros humanos eram um gigantesco problema de dados.

O censo era, em termos daquele período, uma aplicação de processamento em massa.

Hoje o problema poderia ser:

10 bilhões de transações

Em 1890:

dezenas de milhões de habitantes

A questão é sempre a mesma:

VOLUME
+
TEMPO
+
CONFIABILIDADE

⏱️ Capítulo 19 — Performance não é luxo

Essa é uma excelente lição para programadores COBOL iniciantes.

Imagine um programa que lê 100 registros.

Se ele é lento, talvez ninguém perceba.

Agora imagine:

100.000.000 registros

Uma diferença minúscula por registro pode virar horas.

É exatamente por isso que mainframe possui obsessão histórica por:

I/O,

buffers,

índices,

access paths,

SORT,

CPU,

elapsed time,

WLM,

paralelismo.

Em grande escala:

pequenas ineficiências ficam gigantescas.

Hollerith descobriu isso antes de existir CPU.

🧪 Capítulo 20 — Passo a passo: transforme o censo em um Job COBOL

Vamos brincar.

Imagine que recebemos o Census 1890 hoje.

Arquivo:

CENSUS.INPUT

Layout:

01 CENSUS-RECORD.
   05 CENSUS-ID        PIC 9(09).
   05 CENSUS-AGE       PIC 9(03).
   05 CENSUS-SEX       PIC X.
   05 CENSUS-STATE     PIC X(02).
   05 CENSUS-OCCUP     PIC X(20).

Precisamos descobrir população por estado.

Primeiro fazemos SORT:

//SORT01 EXEC PGM=SORT
//SORTIN DD DSN=CENSUS.INPUT,DISP=SHR
//SORTOUT DD DSN=CENSUS.BYSTATE,
// DISP=(NEW,CATLG,DELETE)
//SYSIN DD *
 SORT FIELDS=(13,2,CH,A)
/*

Depois COBOL:

PERFORM UNTIL EOF-SW = 'Y'

   READ CENSUS-FILE
      AT END
         MOVE 'Y' TO EOF-SW
      NOT AT END
         ADD 1 TO STATE-COUNT
   END-READ

END-PERFORM.

Naturalmente um programa real seria mais elaborado.

Mas perceba:

Hollerith fazia conceitualmente a mesma operação usando eletromecânica.

🚨 Capítulo 21 — E se um cartão estivesse errado?

Excelente pergunta.

Aí entramos na qualidade de dados.

Um campo incorreto em 1890 poderia gerar estatística incorreta.

Um registro incorreto hoje pode provocar:

pagamento errado,

saldo errado,

cobrança indevida,

fraude,

decisão regulatória incorreta.

Por isso processamento empresarial desenvolveu obsessão por controles.

Hoje temos:

VALIDAÇÃO
CHECKSUM
RECONCILIAÇÃO
AUDITORIA
LOG
RESTART
RECOVERY

Tudo converge para uma pergunta:

Posso confiar no resultado?

🛡️ Capítulo 22 — Esse é o verdadeiro DNA do mainframe

Muita gente acha que mainframe significa:

"computador muito poderoso".

É uma definição incompleta.

Mainframe é sobretudo uma arquitetura orientada para processamento empresarial altamente confiável.

Os pilares incluem:

confiabilidade, disponibilidade, segurança, escalabilidade, throughput, integridade e auditabilidade.

Um banco não quer apenas saber:

"Meu programa rodou?"

Quer saber:

"Ele rodou corretamente?"

"Processou tudo?"

"Processou duas vezes?"

"Perdeu alguma coisa?"

"Consigo provar o resultado?"

"Se falhar, consigo reiniciar?"

Essas perguntas descendem diretamente dos grandes problemas de processamento de dados.

🔄 Capítulo 23 — Restart: porque até máquinas ficam doentes

Imagine um batch com 200 milhões de registros.

Ele executa quatro horas.

Falha no registro:

199.875.431

Você quer começar novamente do zero?

Provavelmente não.

Por isso sistemas empresariais desenvolveram mecanismos de:

checkpoint,

restart,

commit,

rollback,

recovery.

House diria:

— O programa não precisa nunca ficar doente. Precisa sobreviver quando ficar.

Essa talvez seja uma excelente definição de resiliência.

🥚 Easter Egg #2 — O primeiro DBA talvez usasse caixas

Antes de catálogo Db2, tabelas de sistema e índices B-tree, alguém precisava saber onde estavam os cartões.

Imagine:

CAIXA 001 → NEW YORK
CAIXA 002 → TEXAS
CAIXA 003 → OHIO

Parabéns.

Temos o ancestral conceitual do catálogo.

Naturalmente ninguém deveria colocar no currículo:

"DBA de caixas de sapato desde 1890."

Mas a analogia é divertida.

🤖 Capítulo 24 — Hollerith encontraria IA e reconheceria o problema

Se transportássemos Hollerith até 2026 e mostrássemos inteligência artificial, provavelmente ele ficaria maravilhado.

GPUs.

LLMs.

Vetores.

Embeddings.

Machine learning.

Mas quando perguntássemos:

— Qual continua sendo nosso problema?

Talvez ele respondesse:

— Vocês ainda estão tentando transformar enorme quantidade de informação em algo útil.

Exatamente.

Mudamos brutalmente nossas máquinas.

Mas nossos grandes problemas continuam envolvendo:

coletar,

representar,

armazenar,

classificar,

processar,

interpretar.

🧠 Capítulo 25 — Data Lake, Db2 ou caixa de cartões: a pergunta continua igual

Imagine três épocas.

1890:

CARTÕES

1970:

FITAS

2026:

OBJECT STORAGE

A pergunta:

Onde está o dado?

Depois:

Como encontro?

Depois:

Como processo?

Depois:

Posso confiar?

Tecnologia muda.

Governança permanece.

🥚 Easter Egg #3 — PROC CENSUS

Se o universo tivesse criado z/OS em 1890, talvez existisse:

//CENSUS90 JOB (USA),'HOLLERITH',
// CLASS=A,MSGCLASS=X
//*
//SORTPOP EXEC PGM=SORT
//*
//TABULATE EXEC PGM=HOLLERTH
//*
//REPORT EXEC PGM=CENSRPT

E provavelmente alguém reclamaria:

JOB HELD - PRINTER OUT OF PAPER

Até hoje continuamos perdendo batalhas contra impressoras.

Algumas tecnologias são eternas.

🎓 Capítulo 26 — Cinco lições para quem está começando em COBOL

Quando você estudar COBOL, tente não decorar apenas sintaxe.

Entenda a filosofia.

Quando encontrar:

READ
WRITE
REWRITE
START
DELETE

pense:

estou manipulando registros.

Quando encontrar:

JOB
EXEC
DD

pense:

estou descrevendo processamento.

Quando encontrar DFSORT:

pense:

estou organizando dados para torná-los processáveis.

Quando encontrar VSAM:

pense:

estou escolhendo uma organização física e lógica adequada.

Quando encontrar Db2:

pense:

estou abstraindo acesso estruturado aos dados.

Essa mudança mental transforma completamente seu aprendizado.

🔬 Capítulo 27 — House olha para o gráfico

No final do episódio alguém pergunta:

— Afinal, Hollerith inventou o mainframe?

Não.

Diagnóstico errado.

Hollerith não inventou o mainframe.

Também não inventou COBOL.

Não inventou computador eletrônico.

Mas ajudou a consolidar vários princípios fundamentais do processamento de dados mecanizado.

E esses princípios posteriormente seriam incorporados em sistemas empresariais.

Ele ajudou a demonstrar que grandes volumes de informações poderiam ser:

estruturados,

representados,

classificados,

contados,

processados automaticamente.

Esse é o elo histórico importante.

🧬 Capítulo 28 — A linhagem intelectual

Podemos representar assim:

CENSO
 ↓
DADOS
 ↓
CARTÕES
 ↓
TABULAÇÃO
 ↓
AUTOMAÇÃO
 ↓
PROCESSAMENTO COMERCIAL
 ↓
IBM
 ↓
COMPUTADORES
 ↓
MAINFRAMES
 ↓
COBOL
 ↓
JCL
 ↓
VSAM / IMS / DB2
 ↓
IBM Z

Não é uma linha evolutiva perfeitamente direta.

História tecnológica nunca é.

Existem inúmeros inventores, empresas, concorrentes e caminhos paralelos.

Mas a influência de Hollerith e da indústria de tabulação sobre a história da IBM e do processamento empresarial é indiscutível.

🏛️ Capítulo 29 — Do Census Bureau ao IBM Z

Agora imagine as duas pontas dessa história.

Uma máquina eletromecânica identifica perfurações em papel.

Um IBM Z executa bilhões de instruções, protege transações criptograficamente, suporta milhares de workloads simultâneos e processa operações empresariais críticas.

Visualmente:

não poderiam ser mais diferentes.

Conceitualmente:

há uma familiaridade surpreendente.

Ambos existem porque organizações possuem dados demais para serem processados manualmente.

Ambos tentam resolver:

escala,

velocidade,

confiabilidade,

repetibilidade.

☕ Capítulo Final — O paciente nunca esteve realmente doente

House fecha o prontuário.

Olha pela janela.

Toma café — sim, nesta versão ele abandonou o vicodin e descobriu uma máquina de espresso instalada ao lado de um IBM z17.

O residente pergunta:

— Então qual era a doença?

House responde:

— Crescimento.

— Crescimento?

— Dados crescem. Empresas crescem. Populações crescem. Transações crescem. O problema começa quando sua capacidade de processamento não cresce junto.

Silêncio.

Essa talvez seja a maior lição deixada por Hollerith.

A humanidade sempre produziu informação.

Durante milhares de anos conseguimos processá-la manualmente.

Então nossas sociedades cresceram.

Governos cresceram.

Empresas cresceram.

Bancos cresceram.

Populações cresceram.

E chegou um momento em que cérebro, papel e caneta não eram mais suficientes.

Precisávamos de máquinas.

Primeiro máquinas mecânicas.

Depois eletromecânicas.

Depois válvulas.

Transistores.

Circuitos integrados.

Mainframes.

Cloud.

IA.

Mas existe uma linha invisível atravessando tudo isso.

Uma ideia simples:

dados só têm valor quando conseguimos processá-los de forma confiável.

O cartão perfurado desapareceu.

As máquinas de Hollerith desapareceram.

As caixas desapareceram.

Grande parte das fitas desapareceu.

Os antigos leitores de cartões desapareceram.

Mas:

records continuam existindo.

Sort continua existindo.

Batch continua existindo.

Jobs continuam existindo.

Datasets continuam existindo.

Processamento centralizado continua existindo.

Auditoria continua existindo.

Confiabilidade continua existindo.

E COBOL continua existindo.

Talvez essa seja a grande piada histórica.

Todo mundo olha para um IBM Z moderno e enxerga uma máquina futurista.

Mas, se você retirar as camadas de silício, virtualização, criptografia, APIs e inteligência artificial, bem lá no fundo ainda existe uma pergunta feita há mais de um século:

Tenho uma enorme quantidade de registros.

Como diabos vou processar tudo isso corretamente?

Herman Hollerith levantaria a mão.

Um programador COBOL levantaria outra.

E provavelmente ambos começariam a discutir SORT.

Enquanto isso, no fundo da sala, alguma impressora continuaria offline.

Porque existem problemas que nem 136 anos de evolução tecnológica conseguiram resolver.

☕ Bem-vindo ao Bellacosa Mainframe.

Onde sistemas "legados" às vezes são apenas ideias tão boas que se recusaram a morrer.

Translate

segunda-feira, 12 de agosto de 2019