 |
| Bellacosa Mainframe iniciando no EBCDIC e cartão perfurado |
☕ Um Café no Bellacosa Mainframe
EBCDIC: O Código que o Mundo Chama de Legado, Mas que Ainda Move Bilhões de Transações Todos os Dias
"Quem ri do EBCDIC normalmente nunca precisou garantir que um banco inteiro fechasse o balanço sem perder um único centavo."
Existe um momento na vida de praticamente todo programador que começa a trabalhar com Mainframe.
Você recebe um arquivo vindo do z/OS.
Abre no Notepad.
E aparece algo parecido com isto:
ÁêØ¢ËÑÇ@@@âÑÄÅ...
A primeira reação costuma ser:
"O arquivo está corrompido."
A segunda:
"Alguém esqueceu de salvar em UTF-8."
A terceira:
"Isso é tecnologia dos dinossauros."
Nenhuma delas está correta.
Na verdade, aquele arquivo está absolutamente perfeito.
O problema é que você está tentando ler um livro escrito em outro alfabeto.
Esse alfabeto chama-se EBCDIC (Extended Binary Coded Decimal Interchange Code).
E, apesar de muita gente tratá-lo como uma curiosidade histórica, ele continua presente nos maiores bancos, seguradoras, governos e companhias aéreas do planeta.
Hoje vamos tomar um café e desmistificar um dos assuntos mais mal compreendidos do universo IBM Z.
 |
| Bellacosa Mainframe apresenta o ebcdic |
O maior mito sobre o EBCDIC
Pergunte para dez desenvolvedores que nunca trabalharam com Mainframe:
"Por que existe EBCDIC?"
As respostas costumam ser parecidas.
"Porque a IBM queria prender os clientes."
É uma boa história.
Mas é falsa.
Quando o EBCDIC nasceu, em 1963, praticamente ninguém utilizava ASCII.
Aliás...
Nem mesmo o ASCII era um padrão consolidado.
Cada fabricante possuía sua própria codificação.
Burroughs.
Honeywell.
CDC.
UNIVAC.
ICL.
Todos tinham soluções próprias.
A IBM simplesmente continuou evoluindo aquilo que ela já utilizava desde os computadores baseados em cartões perfurados.
Não era uma conspiração.
Era evolução tecnológica.
O mundo era completamente diferente
Hoje pensamos em computadores conectados pela Internet.
Em 1963...
Não havia Internet.
Não havia Wi-Fi.
Não havia APIs.
Não havia JSON.
Muito menos ChatGPT.
O computador era uma máquina corporativa.
Seu trabalho era processar:
folhas de pagamento;
contas bancárias;
extratos;
impostos;
seguros;
notas fiscais;
cartões perfurados.
O objetivo não era conversar com outros computadores.
Era processar documentos com absoluta confiabilidade.
Essa diferença muda tudo.
ASCII nasceu para conversar
O ASCII descende do Código Baudot, criado para telegrafia.
Imagine um cabo atravessando centenas de quilômetros.
Cada bit enviado custava tempo.
Tempo custava dinheiro.
Por isso o ASCII foi pensado para transmissão serial.
Seu projeto privilegiava simplicidade eletrônica.
Existe uma curiosidade fantástica.
Observe:
A = 65
a = 97
A diferença entre as duas letras é praticamente um único bit.
Isso permitia que um circuito eletrônico transformasse letras maiúsculas em minúsculas simplesmente alterando um sinal elétrico.
Hoje parece detalhe.
Na época era genial.
Enquanto isso...
Na IBM...
O problema era outro.
Ela precisava representar cartões perfurados.
E aí entra um personagem quase esquecido da computação moderna.
 |
| Bellacosa Mainframe e a anatomia de um cartão perfurado |
O cartão perfurado
Imagine uma folha de papel rígido.
Ela possui 80 colunas.
Cada coluna representa um caractere.
Cada coluna possui 12 posições possíveis para perfuração.
12
11
0
1
2
3
4
5
6
7
8
9
As três primeiras posições eram chamadas de Zona.
As demais eram os Dígitos.
Para escrever uma letra não bastava perfurar um único lugar.
Era necessário combinar uma zona com um dígito.
Por exemplo:
Zona 12 + Dígito 1 = A
Esse padrão tornou-se tão importante que a IBM decidiu preservá-lo quando criou o System/360.
O nascimento do EBCDIC
Em vez de inventar um alfabeto completamente novo...
A IBM fez algo extremamente inteligente.
Ela traduziu a lógica física do cartão diretamente para um byte.
Cada caractere passou a ocupar:
4 bits
+
4 bits
Ou seja:
Nibble superior
↓
Zona
Nibble inferior
↓
Dígito
É por isso que o EBCDIC parece "bagunçado".
Na verdade...
Ele apenas respeita a lógica física do cartão.
O famoso buraco entre I e J
Essa é uma das primeiras coisas que um curioso percebe.
No ASCII temos:
ABCDEFGHIJKLMN...
Tudo contínuo.
Já no EBCDIC acontece algo diferente.
As letras ficam divididas em blocos.
A até I
↓
salto
↓
J até R
↓
salto
↓
S até Z
Por quê?
Porque era exatamente assim que funcionava o cartão perfurado.
O que parece estranho hoje fazia todo sentido em 1964.
O EBCDIC não é uma tabela.
Ele é uma filosofia.
Essa talvez seja a maior diferença.
ASCII resolve um problema.
Representar caracteres.
O EBCDIC fazia parte de uma arquitetura inteira.
Quando a IBM lançou o System/360 ela criou uma plataforma capaz de durar décadas.
E conseguiu.
Hoje, mais de sessenta anos depois, conceitos daquela arquitetura continuam presentes no IBM Z.
Entre eles:
canais de I/O;
processamento batch;
registros de tamanho fixo;
decimal compactado;
formatos de impressão;
arquivos VSAM;
e o EBCDIC.
Nada disso surgiu isoladamente.
Tudo fazia parte da mesma visão de engenharia.
"Então por que não mudar para UTF-8?"
Essa pergunta aparece em praticamente toda palestra.
A resposta curta é:
Porque não faz sentido.
Imagine um banco.
Ele possui cinquenta anos de software.
Bilhões de linhas em:
COBOL;
PL/I;
Assembler.
Agora imagine alterar a representação interna dos caracteres.
O que precisaria ser testado?
Tudo.
Literalmente tudo.
Comparações.
Ordenações.
Relatórios.
Impressoras.
Interfaces.
Conversões.
Milhões de programas.
Décadas de auditoria.
Bilhões de registros históricos.
O custo seria gigantesco.
O benefício?
Praticamente nenhum.
O IBM Z odeia UTF-8?
Muito pelo contrário.
Esse é outro mito.
Hoje o IBM Z executa naturalmente:
Java;
Python;
Node.js;
Go;
C/C++;
OpenJDK;
OpenSSH;
Linux on Z;
Docker;
Kubernetes;
APIs REST;
GraphQL;
OpenAPI.
Todos utilizando UTF-8.
O segredo está na arquitetura.
As aplicações modernas trabalham em UTF-8.
Os componentes tradicionais continuam utilizando EBCDIC.
Entre eles:
COBOL;
CICS;
IMS;
DB2;
arquivos sequenciais.
No meio do caminho existem conversores.
Tudo acontece automaticamente.
Na maioria das vezes o desenvolvedor nem percebe.
Um exemplo simples
Imagine um aplicativo no celular.
Cliente
↓
API REST
↓
z/OS Connect
↓
COBOL
↓
DB2
O celular envia UTF-8.
O z/OS Connect converte.
O COBOL recebe EBCDIC.
Na volta acontece exatamente o contrário.
Para quem usa o aplicativo...
Nada muda.
Curiosidade nº 1
Existe apenas um EBCDIC?
Não.
Existem centenas.
São chamadas de Code Pages.
Algumas famosas:
CP037
CP500
CP273
CP1047
CP1140
Cada uma adapta caracteres para determinados idiomas.
É parecido com as antigas páginas de código do Windows.
Curiosidade nº 2
Nem todo problema é "EBCDIC".
Muitas vezes o arquivo já está em EBCDIC.
Mas você está usando a página errada.
É como abrir um texto em português utilizando uma fonte chinesa.
Os bytes continuam corretos.
A interpretação é que muda.
Curiosidade nº 3
COBOL também depende do EBCDIC.
Quando você escreve:
IF CLIENTE-A > CLIENTE-B
Ou executa:
SORT
Existe uma sequência de classificação.
Essa sequência depende da codificação utilizada.
No Mainframe ela normalmente segue o EBCDIC.
Isso significa que uma ordenação feita no Windows pode produzir resultados diferentes daquela executada no z/OS.
Curiosidade nº 4
No ASCII:
9
↓
A
↓
a
No EBCDIC...
A ordem muda.
Esse pequeno detalhe já causou inúmeros bugs em integrações entre plataformas.
Curiosidade nº 5
Você provavelmente usa EBCDIC sem perceber.
Quando um banco expõe uma API REST.
Quando um PIX consulta uma conta.
Quando um cartão de crédito é autorizado.
Quando uma companhia aérea consulta uma reserva.
Quando um caixa eletrônico responde.
Existe uma enorme chance de existir um programa COBOL falando EBCDIC em algum lugar da infraestrutura.
Easter Egg para Padawans 🥚
Se você assistir ao filme Apollo 13, verá computadores IBM em operação.
Se visitar museus de computação encontrará cartões perfurados.
Se estudar a arquitetura do System/360 descobrirá que muitas decisões tomadas naquela época continuam influenciando os processadores IBM Z atuais.
É como encontrar fósseis vivos.
Só que ainda processando bilhões de dólares por dia.
Outro Easter Egg
O EBCDIC costuma ser chamado de "dinossauro".
Mas existe uma ironia divertida.
Grande parte das aplicações modernas utiliza JSON.
JSON é texto.
Texto precisa de codificação.
Sem um padrão de caracteres...
Nem mesmo APIs modernas existiriam.
No fim das contas...
Todo sistema continua dependendo de um "alfabeto".
A diferença é apenas qual deles.
Dicas para quem está começando no Mainframe
Nunca abra arquivos EBCDIC diretamente no Notepad.
Use ferramentas que suportem conversão.
Aprenda a diferença entre arquivo texto e arquivo binário.
Nem tudo pode ser convertido.
Campos COMP, COMP-3 e binários jamais devem ser tratados como texto.
Conheça sua Code Page.
CP037 não é igual à CP1047.
Esse detalhe salva horas de investigação.
Aprenda como funciona FTP ASCII e FTP Binary.
Uma configuração incorreta pode "corromper" um arquivo apenas durante a transferência.
Na verdade, o arquivo original continua íntegro.
Não tenha medo do EBCDIC.
Ele parece estranho apenas porque crescemos utilizando ASCII e UTF-8.
Depois de alguns dias convivendo com Mainframe ele se torna completamente natural.
O verdadeiro legado do EBCDIC
Existe uma frase famosa na engenharia:
"Se algo funciona perfeitamente há cinquenta anos, talvez exista uma boa razão para não mexer."
O EBCDIC sobreviveu não porque o mercado ficou parado.
Mas porque ele faz parte de uma arquitetura extremamente estável.
Enquanto tecnologias aparecem e desaparecem a cada cinco anos...
O IBM Z continua processando alguns dos sistemas mais críticos do planeta.
Não porque seja antigo.
Mas porque foi projetado para durar.
Um Café Antes de Ir...
O programador júnior normalmente olha para o EBCDIC e enxerga um problema.
O desenvolvedor experiente enxerga compatibilidade.
O arquiteto enxerga engenharia.
E o engenheiro de Mainframe enxerga algo ainda maior: uma decisão de projeto que atravessou gerações sem interromper negócios, preservando décadas de investimentos e garantindo que milhões de pessoas possam sacar dinheiro, comprar passagens, pagar contas e realizar transações todos os dias.
Da próxima vez que você abrir um arquivo EBCDIC e encontrar uma "sopa de caracteres", lembre-se: o arquivo não está errado. Apenas está falando a língua nativa de um dos ecossistemas computacionais mais robustos já construídos.
Porque, no fim das contas, o EBCDIC nunca foi um obstáculo ao futuro. Ele sempre foi a ponte silenciosa entre mais de 60 anos de história da computação e o IBM Z que continua sustentando o mundo digital de hoje.
E essa, meu colega Padawan, é uma das maiores lições que o Mainframe pode ensinar: boas arquiteturas envelhecem muito melhor do que modismos tecnológicos. ☕
Sem comentários:
Enviar um comentário