 |
| Bellacosa Mainframe e a historia dos cartoes perfurados em mainframe |
☕ Um Café no Bellacosa Mainframe
🃏 MELVIN UDALL E O CARTÃO QUE NÃO PODIA SAIR DA ORDEM
Cartões perfurados, IBM 029, verificadores, duplicadores, leitores, Hollerith, EBCDIC, COBOL, 80 colunas, batch, spool, JES2 — e o dia em que Melvin descobriu que alguém havia derrubado 2.000 linhas de COBOL no chão.
Sob a tutela de Melvin Udall, de Melhor É Impossível.
🎬 PRÓLOGO — NÃO TOQUE NOS MEUS CARTÕES
Imagine a cena.
Estamos em um centro de processamento de dados dos anos 1960.
O ar-condicionado trabalha como se estivesse tentando congelar o prédio inteiro. Impressoras de linha martelam papel contínuo. Unidades de fita giram. Operadores circulam entre consoles, leitores de cartão e enormes pilhas de papel.
Em uma mesa existem 1.800 cartões perfurados.
Eles são um programa COBOL.
Não representam o programa.
Eles são o programa.
Melvin Udall entra na sala.
Olha para os cartões.
Olha para o operador.
Olha novamente para os cartões.
E provavelmente estabelece a primeira regra operacional:
— Não toque neles.
Segunda regra:
— Não mude a ordem.
Terceira:
— Definitivamente não derrube isso no chão.
Curiosamente, poucas pessoas seriam tutores melhores para explicar cartões perfurados do que Melvin: ordem, repetição, posição e intolerância absoluta a qualquer coisa fora do lugar.
Porque havia uma característica maravilhosa e assustadora naquela computação:
informação era também matéria.
Seu programa tinha peso.
O banco de dados ocupava espaço na estante.
Uma linha COBOL podia ser segurada entre dois dedos.
E 5 MB podiam formar uma montanha.
🗃️ CAPÍTULO 1 — QUANDO 5 MB PRECISAVAM DE UMA MESA
A fotografia que iniciou nossa conversa circula acompanhada da frase:
“What 5 megabytes of computer data looked like in 1966.”
A afirmação precisa ser encarada com cautela como descrição histórica literal daquela fotografia específica, mas a matemática usada para construir a comparação é excelente para compreender a densidade dos cartões perfurados.
O cartão IBM clássico possuía:
80 colunas.
Em utilização convencional, podemos pensar aproximadamente em:
1 cartão ≈ 80 caracteresPortanto:
62.500 cartões
× 80 caracteres
-------------------
5.000.000 caracteresEm uma comparação simplificada:
aproximadamente 5 MB de informação textual.
Hoje uma única fotografia produzida pelo celular pode ultrapassar isso.
Na época, essa quantidade de caracteres podia representar dezenas de milhares de objetos físicos.
E essa comparação já ensina nossa primeira grande lição:
armazenamento não é apenas capacidade; é densidade.
Imagine armazenar 1 TB dessa maneira.
Usando nossa equivalência didática:
1 TB ≈ 1.000.000.000.000 bytes
÷ 80
≈ 12,5 bilhões de cartõesMelvin pediria demissão antes do almoço.
🕳️ CAPÍTULO 2 — O QUE EXISTIA DENTRO DE UM CARTÃO?
Nada.
Literalmente.
Essa é a beleza.
A informação estava representada pela presença ou ausência de furos em determinadas posições.
O cartão IBM tradicional tinha 80 colunas e doze posições possíveis verticalmente, normalmente identificadas como:
12
11
0
1
2
3
4
5
6
7
8
9Não devemos concluir:
12 × 80 = 960 bits, portanto o cartão armazenava 120 bytes.
Não era assim que a codificação convencional funcionava.
Cada coluna representava essencialmente um caractere.
Um número podia ser representado por uma determinada perfuração. Letras exigiam combinações de posições.
Simplificando muito:
COLUNA
│
▼
12 ○
11 ●
0 ○
1 ●
2 ○
3 ○
...A combinação dos furos significava determinado caractere.
Portanto, o cartão não continha ASCII.
E também não devemos imaginar simplesmente EBCDIC fisicamente perfurado no papel.
Existiam códigos de cartão — historicamente associados ao sistema Hollerith e suas evoluções — que o equipamento interpretava.
Essa diferença será importantíssima quando chegarmos ao System/360.
⌨️ CAPÍTULO 3 — IBM 029: O TECLADO QUE FAZIA BURACOS
Nos anos 1960, uma das máquinas emblemáticas desse mundo foi a:
IBM 029 Card Punch.
Para o programador atual, ela parece uma criatura híbrida:
máquina de escrever
+
teclado
+
mecanismo eletromecânico
+
impressora
+
perfuradoraO operador pressionava uma tecla.
A máquina convertia aquele caractere no padrão correspondente de perfurações.
Conceitualmente:
OPERADOR
│
▼
TECLADO
│
▼
CODIFICAÇÃO
│
▼
MECANISMO DE PERFURAÇÃO
│
▼
CARTÃOImagine que você tenha escrito:
MOVE WS-TOTAL TO TOTAL-PAGAR.A linha poderia ocupar um cartão.
A próxima linha:
outro cartão.
A próxima:
outro.
Seu programa de 2.000 linhas?
Dois mil cartões.
Aqui começamos a compreender por que programação era também uma atividade logística.
😱 CAPÍTULO 4 — MELVIN DIGITOU ERRADO
Agora acontece a tragédia.
Melvin pretendia perfurar:
TOTALmas produziu alguma informação incorreta.
Hoje:
BackspaceProblema resolvido.
No cartão existe uma dificuldade fundamental.
Você pode fazer um buraco.
Mas não existe uma tecla:
CTRL+Z DO BURACOque coloque novamente a fibra de papel que acabou de ser removida.
😂
Dependendo do equipamento e do tipo de erro havia procedimentos específicos, mas o princípio operacional importante para nosso Padawan é:
cartão incorreto frequentemente significava produzir um cartão novo.
Isso transforma a ideia de correção.
Não era necessariamente reparar fisicamente aquele pedaço de papel.
Era:
CARTÃO ERRADO
│
▼
identificar informação correta
│
▼
NOVO CARTÃO
│
▼
perfurar novamente
│
▼
verificar
│
▼
substituir originalAgora imagine Melvin vendo alguém colocar o cartão novo na posição errada.
Começamos a entender o verdadeiro horror.
🩹 CAPÍTULO 5 — E SE O CARTÃO ESTIVESSE DANIFICADO?
Esse problema era mais sério do que parece.
Cartões eram objetos físicos.
Portanto estavam sujeitos ao mundo físico:
dobras;
rasgos;
umidade;
sujeira;
desgaste;
deformação;
cantos danificados;
perfurações problemáticas.
E existia uma razão adicional para não simplesmente pensar:
“Está meio rasgado, mas ainda dá para usar.”
Um leitor podia transportar cartões em alta velocidade.
Um cartão deformado poderia causar problemas de alimentação ou um jam.
Portanto, se a informação ainda pudesse ser identificada, uma solução era criar uma cópia limpa.
Conceitualmente:
CARTÃO DANIFICADO
│
▼
informação
│
▼
NOVO CARTÃO EM BRANCO
│
▼
DUPLICAÇÃO
│
▼
CARTÃO NOVO LEGÍVELKeypunches possuíam recursos de duplicação de campos, e ao longo da história do processamento por cartões existiram também máquinas voltadas à reprodução de cartões.
É o ancestral eletromecânico de:
COPY ORIGINAL TO NOVOSó que a cópia podia ser literalmente outro pedaço de cartolina.
🔎 CAPÍTULO 6 — “MAS COMO SABEMOS QUE A CÓPIA ESTÁ CERTA?”
Excelente pergunta.
E aqui aparece uma das ideias mais modernas dessa história.
Verificação.
Existiam card verifiers.
Considere a folha de origem contendo:
123456 BELLACOSA 000015000O primeiro operador utiliza uma perfuradora:
DOCUMENTO
↓
OPERADOR A
↓
KEYPUNCH
↓
CARTÃOMas seres humanos erram.
Portanto outro operador poderia trabalhar com um verifier.
Ele recebia novamente a informação original e digitava o conteúdo.
A máquina verificava se aquilo correspondia ao que estava fisicamente perfurado.
DOCUMENTO ORIGINAL
│
▼
OPERADOR B
│
▼
VERIFIER
│
├───────────────┐
│ │
▼ ▼
DIGITAÇÃO FUROS EXISTENTES
│ │
└──────┬────────┘
▼
COMPARASe houvesse divergência:
temos um problema.
Isso é maravilhoso.
Porque muito antes de alguém dizer:
validation
quality gate
peer verificationa preocupação já existia.
Mudou a tecnologia.
Não mudou o problema.
👁️ CAPÍTULO 7 — COMO UMA MÁQUINA ENXERGA UM BURACO?
Aqui entramos no coração da engenharia.
O leitor precisa responder a uma pergunta aparentemente ridícula:
Existe papel aqui ou existe um buraco?
Nos sistemas eletromecânicos mais antigos, uma técnica utilizada envolvia escovas metálicas e contatos elétricos.
Imagine:
ESCOVA
│
▼
───────────
CARTÃO
███████████
███ ██████
│
▼
superfície
condutoraOnde havia papel, a escova era impedida de estabelecer determinado contato.
Onde havia perfuração, podia ocorrer contato elétrico através daquela abertura.
Portanto:
FURO
↓
CONTATO
↓
SINAL ELÉTRICOUm buraco no papel tornou-se eletricidade.
Isso é computação em sua forma mais bela.
💡 CAPÍTULO 8 — DEPOIS A LUZ ENTROU NA HISTÓRIA
Tecnologias posteriores utilizaram leitura fotoelétrica.
Agora podemos imaginar:
LUZ
│
▼
CARTÃO
│
├── PAPEL → bloqueia
│
└── FURO ──────────────┐
▼
SENSOR
│
▼
SINAL ELÉTRICOAssim:
representação física
↓
detecção
↓
sinal
↓
codificação
↓
caracterePerceba o salto conceitual.
O computador não processava papel.
O papel era apenas o meio físico que transportava uma representação da informação.
É exatamente a distinção que ainda fazemos entre:
mídia
formato
codificação
registro
dado🧬 CAPÍTULO 9 — DO HOLLERITH AO EBCDIC
Agora chegamos ao ponto que interessa diretamente ao programador mainframe.
Com o IBM System/360, apresentado em 1964, encontramos o mundo do EBCDIC.
O cartão possui uma codificação física.
O leitor detecta as perfurações.
O equipamento e seus controladores convertem essa representação para aquela utilizada pelo computador.
Didaticamente:
CARTÃO
↓
padrões de perfuração
↓
CARD READER
↓
interpretação/conversão
↓
representação eletrônica
↓
EBCDIC
↓
MEMÓRIAPortanto, quando alguém afirma:
“O cartão tinha 80 bytes.”
Entenda isso como uma equivalência útil de capacidade textual.
Não imagine 80 bytes EBCDIC magicamente vivendo dentro da cartolina.
O cartão tinha 80 colunas de caracteres.
A representação interna viria depois.
🧱 CAPÍTULO 10 — AGORA VOCÊ ENTENDE AS 80 COLUNAS DO COBOL
Chegamos a um dos grandes momentos da arqueologia mainframe.
O formato COBOL tradicional traz a herança física do cartão:
1-----6 7 8----11 12----------------72 73------80
│ │ │ │ │
│ │ │ │ └─ identificação
│ │ │ └─ AREA B
│ │ └─ AREA A
│ └─ indicador
└─ sequênciaAgora nosso iniciante finalmente entende por que COBOL antigo parece obcecado por posição.
Porque posição era física.
Coluna 7 não era uma abstração inventada pelo editor.
Era:
a sétima coluna daquele cartão que você podia segurar na mão.
🔢 CAPÍTULO 11 — POR FAVOR, NUMERE ISSO ANTES QUE MELVIN VEJA
As colunas iniciais podiam conter números de sequência.
Por exemplo:
000100 IDENTIFICATION DIVISION.
000200 PROGRAM-ID. BELLACOS.
000300 DATA DIVISION.
000400 WORKING-STORAGE SECTION.
000500 01 WS-TOTAL PIC 9(7)V99.Por quê?
Agora imagine alguém carregando 2.000 cartões.
Tropeça.
WHOOSH!
000400
000100
000500
000200
000300Melvin olha para o chão.
Silêncio absoluto.
Nesse momento, você agradece aos números.
000100
000200
000300
000400
000500Mas existe algo ainda mais espetacular.
Card sorters.
Havia equipamentos que podiam ordenar cartões mecanicamente utilizando as posições perfuradas.
Portanto, antes de:
//SORTSTEP EXEC PGM=SORTexistia uma realidade na qual SORT podia significar uma máquina reorganizando objetos físicos.
📚 CAPÍTULO 12 — O CARTÃO É O AVÔ DO RECORD
Imagine um cartão contendo:
00001BELLACOSA 00015000Definimos:
COL 01-05 = matrícula
COL 06-15 = nome
COL 16-23 = salárioAgora nosso COBOL possui:
01 FUNCIONARIO.
05 MATRICULA PIC 9(5).
05 NOME PIC X(10).
05 SALARIO PIC 9(8).Está vendo?
CARTÃO
↓
RECORD
↓
FIELDSEssa é uma conexão poderosíssima para compreender:
fixed length
posição
offset
PIC X
PIC 9
LRECL
RECFM=F
RECFM=FBUm iniciante olha para:
RECFM=FB,LRECL=80e pensa:
Por que 80?
Melvin aponta silenciosamente para a pilha de cartões.
🏭 CAPÍTULO 13 — AGORA COLOQUE 2.000 CARTÕES NO LEITOR
Chegou a hora do processamento.
O deck é colocado no hopper do leitor.
Simplificando:
HOPPER
┌──────────┐
│██████████│
│ CARTÕES │
└────┬─────┘
↓
FEEDER
↓
READ STATION
↓
SENSOR
↓
STACKERO mecanismo separa os cartões e os transporta pela estação de leitura.
Aqui aparecem problemas muito concretos:
double feed
misfeed
card jam
cartão dobrado
cartão rasgado
deck incorretoObserve novamente como confiabilidade de dados e confiabilidade mecânica estavam intimamente relacionadas.
Hoje temos CRC, ECC, redundância, checksums e controles sofisticados.
Ali você também precisava preocupar-se com uma coisa muito mais prosaica:
o papel passou corretamente pela máquina?
⚙️ CAPÍTULO 14 — O MAINFRAME NÃO “EXECUTA CARTÕES”
Este ponto merece atenção.
O leitor é um dispositivo de entrada.
Portanto:
CARTÃO
↓
CARD READER
↓
SINAL
↓
CARACTERE
↓
RECORD
↓
SISTEMA
↓
PROCESSAMENTOUma vez internalizada, aquela informação podia ser:
compilada;
armazenada;
processada;
gravada em fita;
gravada em disco;
impressa;
utilizada como dados.
O computador não precisava continuar consultando fisicamente aquele cartão para cada instrução.
O cartão cumpriu sua missão:
transportar informação do mundo físico para o eletrônico.
📦 CAPÍTULO 15 — POR QUE “BATCH”?
Agora a palavra começa a fazer sentido.
Batch = lote.
O programador preparava um trabalho.
Ele podia conter:
controle
+
programa
+
dadosO trabalho era entregue para processamento.
O fluxo podia ser:
PROGRAMADOR
↓
CODING SHEET
↓
KEYPUNCH
↓
VERIFY
↓
DECK
↓
OPERADOR
↓
CARD READER
↓
COMPUTADOR
↓
PRINTER
↓
LISTAGEM
↓
PROGRAMADOREncontrou erro de sintaxe?
Corrija.
Produza o cartão adequado.
Submeta novamente.
Espere novamente.
De repente você começa a apreciar um compile de COBOL que demora 15 segundos.
🌀 CAPÍTULO 16 — SPOOL: NÃO FAÇA A CPU ESPERAR PAPEL
Computadores eram caríssimos.
Periféricos mecânicos eram relativamente lentos.
Não fazia sentido desperdiçar recursos valiosos esperando continuamente leitores e impressoras.
Entra em cena o conceito de spooling, desacoplando operações periféricas do processamento.
Simplificando:
CARD READER
↓
SPOOL
↓
INPUT QUEUE
↓
PROCESSAMENTO
↓
SPOOL
↓
OUTPUT QUEUE
↓
PRINTERIsso é extremamente importante para compreender o mainframe atual.
🚂 CAPÍTULO 17 — DO CARTÃO AO JES2
Avançamos várias décadas.
Você abre ISPF ou outra interface e submete:
//BELLACOS JOB ...
//STEP01 EXEC PGM=PGM001
//ENTRADA DD DSN=BELLACOSA.INPUT,DISP=SHR
//SAIDA DD SYSOUT=*Não existe uma caixa de cartões.
Mas existe:
SUBMIT
↓
JES2
↓
INPUT
↓
EXECUTION
↓
OUTPUT
↓
SDSFNão estou dizendo que JES2 é simplesmente um “leitor de cartões virtual”.
A arquitetura moderna é infinitamente mais sofisticada.
Mas existe uma continuidade histórica de problemas:
receber trabalho, classificá-lo, colocá-lo em filas, executá-lo e administrar sua saída.
Conhecer cartões perfurados torna JES muito menos misterioso.
🔐 CAPÍTULO 18 — E A SEGURANÇA?
Hoje pensamos:
RACF
USERID
MFA
DATASET PROFILE
AUDIT
SMF
ENCRYPTIONMas quando a informação existe fisicamente, segurança física ganha importância enorme.
Quem pode entrar?
Quem pode pegar o deck?
Quem pode retirar um cartão?
Quem pode substituir um cartão?
Quem pode copiar o deck?
Imagine um invasor substituindo:
IF VALOR < LIMITEpor outro cartão contendo lógica alterada.
Em espírito, temos algo parecido com um:
supply-chain attack de cartolina.
O mecanismo mudou.
O princípio continua assustadoramente familiar:
controle de integridade.
💾 CAPÍTULO 19 — BACKUP TAMBÉM TINHA PESO
Seu único deck representa semanas de trabalho.
Agora escolha o incidente:
🔥 fogo
💧 água
☕ café
✂️ dano
📦 extravio
🌀 desordemTem apenas uma cópia?
Tem um problema.
Duplicação de cartões, fitas e posteriormente discos mudaram radicalmente essa realidade.
Nasce uma lição que continua válida em 2026:
Backup não é acreditar que você possui uma cópia. É conseguir recuperar a informação quando a original deixa de existir.
🧠 CAPÍTULO 20 — O DEVOPS JÁ ESTAVA ESCONDIDO NA SALA?
Não vamos cometer anacronismo e chamar uma operação de cartões de “DevOps”.
Mas podemos fazer uma comparação pedagógica deliciosa.
ONTEM HOJE
Coding sheet → editor/IDE
Keypunch → entrada de código
Verifier → validação
Reproducer → cópia
Sequence → controle de ordem
Deck → conjunto de fontes/dados
Reader → ingestão
Queue → fila
Batch processing → pipeline/workload
Spool → desacoplamento
Operator → automação/orquestração
Listing → logs/outputNão são equivalências arquitetônicas exatas.
São parentescos conceituais.
A humanidade continua resolvendo problemas semelhantes com ferramentas cada vez melhores.
🧪 CAPÍTULO 21 — EXERCÍCIO PARA O PADAWAN
Pegue este registro:
00042BELLACOSA 00001250SPDefina:
01-05 MATRÍCULA
06-15 NOME
16-23 VALOR
24-25 UFAgora escreva COBOL:
01 WS-REGISTRO.
05 WS-MATRICULA PIC 9(5).
05 WS-NOME PIC X(10).
05 WS-VALOR PIC 9(8).
05 WS-UF PIC X(2).Depois desenhe 25 colunas em uma folha.
Escreva um caractere em cada coluna.
Você perceberá imediatamente o significado de:
posição fixa.
Depois experimente inserir um caractere no início sem deslocar corretamente os demais.
Pronto.
Você acaba de entender por que alterações de layout podem destruir interfaces legadas.
Não é “coisa velha”.
É contrato de dados.
🏛️ CAPÍTULO 22 — O FÓSSIL CONTINUA VIVO
A jornada pode ser visualizada assim:
PUNCH CARD
↓
RECORD
↓
TAPE
↓
DASD
↓
DATASET
↓
JES / SPOOL
↓
z/OS
↓
APIs
↓
Git / CI/CD
↓
Cloud / OpenShift / AINão é uma linha evolutiva perfeita e exclusiva; tecnologias coexistiram e evoluíram em paralelo.
Mas ela revela uma característica maravilhosa do ecossistema mainframe:
o passado deixa pistas no presente.
Quando você entende a origem, muitas “esquisitices” deixam de ser esquisitas.
🎩 CAPÍTULO 23 — A GRANDE LIÇÃO DE MELVIN UDALL
Agora voltamos à nossa mesa.
Há 2.000 cartões.
Melvin está observando.
O jovem programador pergunta:
— Por que precisamos entender isso se ninguém mais vai entregar meu COBOL numa caixa?
Porque você não está estudando papel.
Está estudando conceitos fundamentais:
representação
codificação
sequência
integridade
validação
registro
entrada
fila
processamento
recuperação
redundância
automaçãoO cartão desapareceu.
Esses problemas não.
A IBM 029 desapareceu da sala de desenvolvimento.
Mas ainda precisamos transformar intenção humana em código.
O verifier desapareceu.
Mas ainda fazemos validação.
O reproducer desapareceu.
Mas continuamos copiando e versionando informação.
O sorter mecânico desapareceu.
Mas continuamos ordenando bilhões de registros.
O card reader desapareceu.
Mas continuamos fazendo ingestão.
A caixa de jobs desapareceu.
Mas continuamos colocando workloads em filas.
A impressora de linha deixou de ser a interface dominante.
Mas continuamos procurando SYSOUT no SDSF.
🥚 EPÍLOGO — O INCIDENTE DAS 03:17
São 03:17.
O jovem operador entra correndo.
— Senhor Udall, temos um incidente!
Melvin não levanta os olhos.
— Severity?
— Alta.
— Hardware?
— Não.
— Software?
— Também não exatamente.
Melvin finalmente olha.
— O que aconteceu?
O rapaz aponta para o chão.
000900
000300 001500
000100
001200 000700
000200Dois mil cartões COBOL espalhados pelo corredor.
Silêncio.
Melvin contempla o desastre.
Olha para o programador.
Olha novamente para o chão.
Então pergunta:
— Você numerou as colunas 1 a 6?
— Sim.
Melvin ajeita os cartões que ainda segura.
— Então ainda existe esperança para você.
☕ Bellacosa Mainframe
Porque às vezes a melhor maneira de entender por que o mainframe funciona como funciona hoje é descobrir como ele funcionava quando um programa podia cair no chão.
Sem comentários:
Enviar um comentário