 |
| Bellacosa Mainframe e o cobol do cartao perfurado ao json |
☕ Um Café no Bellacosa Mainframe
Do Cartão Perfurado ao JSON — Quando eXistenZ Conectou um Bioport ao COBOL e Descobriu que “Legado” Era Só o Nome do Jogo
Ou: Allegra Geller entrou na sala de máquinas, conectou um cordão umbilical num programa de 1978, encontrou CICS, Db2, APIs REST, AMODE 64, GnuCOBOL e Igor tentando compilar um microserviço no perfurador de cartões
Existe uma cena mental que todo programador COBOL já conhece, mesmo sem jamais tê-la vivido.
A pessoa chega ao primeiro dia no mainframe. Abre um fonte com colunas, IDENTIFICATION DIVISION, WORKING-STORAGE SECTION, nomes que parecem endereços de rua e um PERFORM que, por algum motivo, chama outro PERFORM escrito por uma criatura que trabalhou na empresa em 1984 e deixou como única documentação o comentário:
* NAO ALTERAR - REGRA ESPECIALA pessoa pensa: “Meu Deus. Estou entrando num museu.”
Aí ela descobre que aquele programa calcula crédito, liquida pagamento, processa folha, emite apólice, atualiza saldo, registra auditoria e conversa com uma API que alimenta o aplicativo de milhões de clientes.
E percebe que não entrou num museu.
Entrou em eXistenZ.
No filme de David Cronenberg, ninguém sabe direito quando está no mundo real, quando entrou no jogo e quando uma interface aparentemente estranha se tornou o único caminho para continuar vivo. No mundo corporativo, a sensação é parecida: alguém aponta para o mainframe e chama tudo de “legado”; depois abre o celular, faz uma transferência, paga a fatura, consulta o benefício, compra uma passagem e descobre que boa parte daquela realidade digital depende justamente da sala de máquinas que julgou ultrapassada.
A verdade é menos dramática — e mais interessante. COBOL não sobreviveu por teimosia, nostalgia ou falta de coragem para reescrever tudo. Ele sobreviveu porque foi evoluindo enquanto continuava fazendo algo que as empresas valorizam profundamente: processar operações críticas corretamente, em volume, com rastreabilidade e previsibilidade.
Do cartão perfurado ao JSON, a linguagem não fez uma troca de pele completa. Ela foi acumulando camadas. E essa é exatamente sua maior força.
Prólogo — Allegra Geller encontra um cartão de 80 colunas
Antes da API REST, antes do Kubernetes, antes do JSON e antes de alguém decidir que toda solução precisava se chamar “plataforma”, existia o cartão perfurado.
Ele parecia simples: um pedaço de cartolina com 80 colunas. Mas ali podia estar uma instrução COBOL, um parâmetro de JCL ou parte de um dado de entrada. Um furo fora da posição certa não era “um probleminha de formatação”: podia ser a diferença entre compilar, abortar ou executar uma lógica diferente.
Igor, naturalmente, olhou para a leitora IBM 2540 e perguntou:
— Doutor, onde eu conecto o Wi-Fi?
O doutor respondeu:
— Igor, isso já foi o Wi-Fi de uma empresa inteira. Só que o pacote chegava de caminhão.
A brincadeira tem fundo de verdade. O processamento era físico porque o mundo era físico: cartões, fitas, impressoras de linha, discos e operadores. O sistema não recebia uma requisição HTTP; recebia caixas de cartões ou arquivos em fita. Não existia tela de observabilidade com gráfico colorido dizendo “latência p95”. Existiam consoles, listagens, mensagens de job e profissionais que sabiam interpretar um IEC, um S0C7 ou um U403 como quem lê previsão do tempo antes de sair para o mar.
E, ainda assim, aquilo já era arquitetura corporativa.
O batch não era uma deficiência. Era uma escolha técnica coerente para processar grandes volumes em janelas definidas. Fechamento de contas, folha de pagamento, faturamento, extratos, arrecadação, conciliação e carga de dados continuam sendo excelentes candidatos ao modelo batch.
A diferença é que hoje muita gente chama isso de data pipeline, orchestration ou scheduled workflow. O velho programador COBOL olha para o diagrama e pensa, tomando café:
— Ah. Um JOB com dependência. Bonito o desenho.
1. O primeiro nível do jogo: batch, JCL e o mundo que não parava para responder
Para entender COBOL, o iniciante precisa abandonar uma ideia perigosa: a de que programa só existe quando alguém clica num botão e recebe uma resposta na tela.
No mainframe clássico, um programa COBOL frequentemente era parte de um fluxo. O JCL definia como aquele fluxo seria executado: quais arquivos seriam lidos, quais datasets seriam criados, quanto recurso seria solicitado, em que classe o job rodaria, quais programas seriam chamados e o que fazer se algo desse errado.
Pense em uma folha de pagamento.
O processo pode receber um arquivo de funcionários, validar cadastros, calcular salários, descontos, impostos, benefícios, gerar arquivos bancários, emitir relatórios e registrar exceções. Nem tudo precisa acontecer no exato momento em que alguém aperta Enter. Pelo contrário: há trabalhos em que processar milhões de registros com eficiência, controle e reexecução é mais importante que responder em 200 milissegundos.
Um fluxo poderia seguir esta lógica:
Arquivo de entrada
↓
Validação COBOL
↓
Cálculo de regras
↓
Atualização de dados
↓
Relatórios e arquivos de saída
↓
Auditoria e conferênciaO segredo do batch bom não é ser “antigo”; é ser reiniciável, auditável e previsível.
Dicas para quem está começando:
sempre saiba qual é a entrada, a saída e a regra de transformação;
diferencie erro de dado, erro de ambiente e erro de programa;
trate códigos de retorno;
pense em reprocessamento antes de pensar em heroísmo;
nunca presuma que um job que terminou com
RC=0000produziu o resultado de negócio correto.
RC=0000 significa que o programa disse que terminou bem. Não significa que a empresa não pagou 12 mil aposentados duas vezes porque um arquivo veio duplicado. A máquina pode estar feliz enquanto o diretor financeiro chama todo mundo para uma reunião com expressão de velório.
2. VS COBOL II e COBOL 85: quando a linguagem saiu da masmorra dos GO TOs
A evolução de OS/VS COBOL para VS COBOL II e os recursos associados ao COBOL 85 representou mais do que uma nova caixa de ferramentas. Foi uma mudança de mentalidade.
O COBOL antigo podia ser perfeitamente funcional, mas trazia estilos de programação que hoje deixam até um arqueólogo nervoso: desvios espalhados, ALTER, pontos finais em lugares perigosos e parágrafos usados como labirintos.
O comando ALTER, por exemplo, permitia mudar dinamicamente o destino de um GO TO. É o tipo de recurso que parece uma ideia divertida até você precisar descobrir, numa sexta-feira às 18h, para onde o programa decidiu pular depois de 30 anos de manutenção.
A programação estruturada trouxe ferramentas para escrever código mais legível:
IF WS-CLIENTE-ATIVO = "S"
PERFORM PROCESSA-CLIENTE
ELSE
PERFORM REGISTRA-CLIENTE-INATIVO
END-IFE também:
EVALUATE WS-TIPO-OPERACAO
WHEN "PIX"
PERFORM PROCESSA-PIX
WHEN "TED"
PERFORM PROCESSA-TED
WHEN "BOL"
PERFORM PROCESSA-BOLETO
WHEN OTHER
PERFORM TRATA-OPERACAO-INVALIDA
END-EVALUATEEND-IF, END-PERFORM e END-EVALUATE parecem detalhes, mas são cercas de proteção. Eles deixam claro onde um bloco termina e reduzem o risco de um ponto final encerrar uma estrutura inteira silenciosamente.
O PERFORM inline também aproximou o código COBOL de uma leitura mais natural:
PERFORM UNTIL WS-FIM-ARQUIVO = "S"
READ ARQ-ENTRADA
AT END
MOVE "S" TO WS-FIM-ARQUIVO
NOT AT END
PERFORM PROCESSA-REGISTRO
END-READ
END-PERFORMPara o iniciante, a lição é simples: você não precisa amar código antigo para respeitar o que ele carrega. Mas também não precisa copiar seus piores hábitos. Programe COBOL moderno quando a plataforma e o padrão da empresa permitirem. Nomeie bem, use escopo explícito, separe responsabilidades, valide dados e deixe o próximo ser humano entender o que você fez.
Esse próximo ser humano pode ser você mesmo daqui a seis meses.
3. AMODE 24, AMODE 31 e a casa que finalmente ganhou mais quartos
A primeira grande limitação histórica era o endereçamento de 24 bits, que permitia acessar até 16 MB. Hoje parece pouco até para uma foto de celular, mas naquela época era uma fronteira real de arquitetura.
A mudança para AMODE 31 ampliou imensamente a capacidade de endereçamento. Isso deu mais espaço para programas e subsistemas, reduziu algumas manobras de baixo nível e ajudou a consolidar o ambiente transacional corporativo.
Aqui entra uma curiosidade saborosamente mainframe: BLL cells, ou Base Locator for Linkage. Em determinados cenários CICS, especialmente com áreas grandes na LINKAGE SECTION, programadores precisavam lidar com mecanismos para localizar corretamente estruturas recebidas. É um daqueles assuntos que parecem feitiçaria para quem chega agora, mas eram engenharia necessária num ambiente com limitações muito concretas.
O ponto importante não é decorar BLL cells na primeira semana. É entender a filosofia: memória, endereçamento e interface entre programas sempre foram preocupações reais. Só mudaram os nomes, as ferramentas e o tamanho da dor de cabeça.
Em outras palavras: hoje você discute ponteiros, heap, containers, limites de pod e consumo de memória na nuvem. Ontem alguém discutia AMODE, RMODE e áreas acima ou abaixo da linha. A conversa mudou de figurino; o monstro técnico continua no porão.
4. Quando o COBOL entrou em CICS: o jogo deixou de esperar a madrugada
O batch é poderoso, mas o mundo também exige resposta imediata. É aí que entram CICS, IMS e os modelos transacionais.
Imagine uma pessoa consultando saldo pelo aplicativo do banco. Ela não quer ouvir:
“Sua solicitação será processada no próximo fechamento noturno.”
Ela quer a resposta agora.
Uma transação pode validar conta, autenticar contexto, consultar dados, verificar limite, registrar auditoria, atualizar valores e devolver uma resposta em poucos instantes. COBOL se tornou muito forte nesse tipo de processamento porque foi construído para lógica de negócio, dados estruturados, precisão decimal e estabilidade operacional.
Uma transação não é apenas “chamar um programa”. Há compromisso, recuperação, concorrência, segurança e auditoria envolvidos.
Se uma transferência debita uma conta e falha antes de creditar a outra, o sistema precisa saber o que fazer. É por isso que conceitos como COMMIT, ROLLBACK, unidades de trabalho e integridade transacional são tão importantes.
A regra de ouro é:
Dinheiro não pode ficar preso no corredor entre dois programas.
Em CICS, o COBOL pode receber uma solicitação, executar lógica e retornar o controle. Em muitos cenários, a pseudo-conversação evita deixar uma transação parada esperando a pessoa digitar. O programa responde, termina; quando o usuário envia a próxima tela, uma nova transação retoma o fluxo com o estado necessário.
Parece uma conversa contínua, mas tecnicamente é uma sequência muito bem coreografada de entradas e saídas. Quase um jogo de eXistenZ: você acha que está dentro da mesma realidade, mas cada movimento atravessa uma fronteira cuidadosamente controlada.
5. XML, Java, JSON e o dia em que o mainframe ganhou bioport
Durante muito tempo, o mito foi: “o mainframe não conversa com o mundo moderno”.
A resposta correta é: conversa, desde que você instale a porta certa e não entregue a Igor um cabo sem etiqueta.
Enterprise COBOL foi incorporando mecanismos de interoperabilidade. XML ganhou espaço nas integrações corporativas; depois o JSON se tornou o idioma dominante das APIs web. Com XML PARSE, XML GENERATE, JSON PARSE e JSON GENERATE, o COBOL passou a manipular esses formatos de maneira muito mais direta.
Imagine que um canal digital envie:
{
"cliente": "VAGNER",
"conta": "12345-6",
"operacao": "PIX",
"valor": 125.90
}O fluxo moderno pode ser:
Aplicativo móvel
↓ JSON/HTTPS
Camada de API
↓
CICS, IMS ou serviço de integração
↓
Programa COBOL e regra de negócio
↓
Db2 / VSAM / MQ
↓
Resposta JSON ao aplicativoA grande sacada não é fazer COBOL fingir que é JavaScript. É manter a lógica crítica onde ela já é madura e confiável, expondo-a de forma segura para os canais modernos.
JSON PARSE transforma o documento JSON em dados COBOL; JSON GENERATE faz o caminho de volta. Isso reduz código artesanal de conversão, melhora consistência e aproxima a aplicação das integrações atuais.
O suporte a UTF-8 e itens PIC U também ajuda a trabalhar com caracteres Unicode. Mas atenção, jovem padawan do EBCDIC: suporte a UTF-8 não significa que toda conversão de caracteres desapareceu do universo. Cada fronteira entre sistemas precisa ter codificação claramente definida. JSON, HTTP, banco, fila, arquivo e terminal podem ter expectativas diferentes.
Se ninguém documenta isso, um “ç” pode atravessar a API e voltar como um pequeno demônio tipográfico.
6. AMODE 64: a porta enorme que não serve para toda sala
A chegada de LP(64) e programas COBOL AMODE 64 é um marco importante. Ela permite aplicações batch com endereçamento de 64 bits, úteis para cenários que exigem grandes áreas de memória e interoperabilidade entre programas de 31 e 64 bits.
Mas aqui mora uma das armadilhas do entusiasmo tecnológico.
AMODE 64 não é um botão “deixe tudo mais rápido”. E também não é simplesmente a nova casa universal do COBOL. Há restrições de ambiente; em especial, programas AMODE 64 não são a resposta para programas CICS e IMS tradicionais.
A pergunta certa não é “como converto tudo para 64 bits?”. É:
qual carga realmente precisa de mais memória?
o gargalo é memória, CPU, I/O ou Db2?
o programa é batch ou transacional?
quais interfaces e dependências ele possui?
quanto custa testar e operar a mudança?
Um programa que lê um arquivo lentamente não fica milagrosamente veloz só porque ganhou mais memória. Um SQL sem índice continuará sendo um SQL sem índice, apenas com espaço suficiente para reclamar confortavelmente.
7. SIMD, otimização e o momento em que o COBOL ficou musculoso
Os processadores IBM Z modernos oferecem recursos sofisticados, inclusive instruções vetoriais capazes de tratar múltiplos elementos em paralelo em cenários apropriados. O compilador COBOL pode explorar isso em determinadas operações, melhorando desempenho.
Mas desempenho é sempre uma investigação, não uma religião.
Antes de gritar “SIMD!”, “otimização!” ou “vamos reescrever em Rust!”, verifique:
tempo de CPU;
tempo total decorrido;
espera por I/O;
chamadas a Db2;
acesso a VSAM;
uso de MQ;
serialização;
volume de dados;
desenho de tabelas;
algoritmo usado;
opções de compilação.
Às vezes o problema está num INSPECT, numa conversão repetida ou num loop enorme. Às vezes está numa consulta Db2 que faz a máquina procurar uma agulha no palheiro com uma colher de chá.
E quase sempre a resposta começa com uma ferramenta considerada pouco glamourosa: medição.
8. SMARTBIN e ABO: não é magia, é preservação de futuro
O SMARTBIN permite que módulos COBOL elegíveis carreguem metadados adicionais para que o IBM Automatic Binary Optimizer, o ABO, possa otimizá-los posteriormente para aproveitar melhor gerações de hardware IBM Z.
É uma ideia elegante: o fonte não precisa ser alterado para que parte do binário possa receber otimizações futuras.
Mas há detalhes de operação que não devem ser varridos para baixo do tapete:
o uso depende de versões e elegibilidade;
há impacto em tamanho de módulo em disco;
o processo exige governança e validação;
SMARTBINnão é suportado comLP(64)ativo.
Ou seja: SMARTBIN e AMODE 64 não são duas figurinhas que você cola no mesmo programa para “liberar performance máxima”. Cada recurso resolve problemas diferentes e possui restrições próprias.
A lição profissional é preciosa: leia a documentação, conheça a versão de compilador, teste em ambiente controlado e mantenha um baseline. Em produção, “parecia uma boa ideia” é a frase que antecede muitas reuniões.
9. GnuCOBOL: uma excelente porta de entrada, não uma réplica do z/OS
O GnuCOBOL merece respeito. Ele permite desenvolver e executar COBOL em Linux, Windows e macOS, normalmente transformando o fonte COBOL em C e usando compiladores como GCC ou Clang para gerar o executável.
Isso é fantástico para aprender.
Você pode praticar estruturas de decisão, tabelas, arquivos, cálculos, validação, PERFORM, STRING, UNSTRING, relatórios e organização de programas sem precisar ter acesso imediato a um ambiente mainframe corporativo.
Mas é importante não confundir duas coisas:
aprender COBOL e aprender a operar COBOL em z/OS.
São jornadas conectadas, porém diferentes.
GnuCOBOL não reproduz, por si só, o ecossistema completo de produção IBM Z: JCL, JES, ISPF, datasets, RACF, CICS, IMS, Db2 z/OS, VSAM operacional, SMF, WLM, Language Environment e toda a disciplina de mudança e operação que protege sistemas críticos.
A opção de compatibilidade com dialetos IBM pode ajudar a treinar sintaxe. Mas sintaxe é apenas parte do ofício. É como aprender a dirigir num simulador e depois descobrir que a estrada tem neblina, carga perigosa, pedágio, fiscalização, passageiro nervoso e um cavalo atravessando a pista.
Ainda assim, comece. GnuCOBOL é uma ponte excelente. Só não o trate como se fosse uma miniatura perfeita de um datacenter bancário.
10. O roteiro para o programador COBOL iniciante não virar NPC do próprio jogo
Se você está começando, não tente aprender “todo o mainframe” de uma vez. Isso é a forma acadêmica de acordar três semanas depois olhando para um manual de RACF e perguntando se a realidade ainda existe.
Siga uma trilha prática:
Aprenda COBOL estruturado: variáveis,
PIC,USAGE,IF,EVALUATE,PERFORM, tabelas, arquivos e tratamento de erro.Entenda dados: decimal, sinal, campos compactados, data, valor inválido, conversão e arredondamento. Em sistema financeiro, o ponto decimal tem mais poder político que muita diretoria.
Aprenda batch e JCL: entrada, saída, dataset,
DISP, códigos de retorno, reinício e dependências.Estude VSAM e Db2: COBOL quase nunca vive sozinho; ele conversa com dados.
Entre em CICS:
COMMAREA,CHANNEL,LINK,XCTL,RETURN, pseudo-conversação, BMS e tratamento de erros.Conheça integração: MQ, APIs, JSON, XML, z/OS Connect, contratos e segurança.
Aprenda operação: logs, dumps, mensagens, ABEND, análise de causa, observabilidade e procedimento.
Pratique testes e DevOps: versionamento, build, deploy, regressão, revisão de código e automação.
O objetivo não é virar uma enciclopédia ambulante. É desenvolver visão de sistema.
Um programador COBOL profissional não é apenas alguém que escreve:
ADD WS-VALOR TO WS-SALDOÉ alguém que pergunta:
esse valor está validado?
qual regra de arredondamento vale?
a transação pode ser repetida?
há auditoria?
o commit está no ponto certo?
quem pode chamar essa operação?
o que acontece se a fila estiver indisponível?
como descobriremos o problema às 03h17?
Essa é a diferença entre codificar e sustentar um negócio.
Epílogo — “Talvez ainda estejamos dentro do jogo”
No final de eXistenZ, a pergunta permanece: eles realmente saíram do jogo?
No universo corporativo, a pergunta equivalente é:
O COBOL é um legado preso no passado ou a infraestrutura invisível que permite ao presente funcionar?
A resposta honesta é: depende do modo como ele é tratado.
COBOL pode ser um problema quando está abandonado, sem testes, sem documentação, sem donos, sem integração segura e sem renovação de profissionais. Mas isso não é defeito exclusivo da linguagem. Um sistema Java mal mantido, uma API Python sem observabilidade ou um cluster moderno sem governança também podem ser um castelo de horrores.
COBOL também pode ser uma plataforma extremamente atual: integrado a APIs, protegido por segurança corporativa, operado com disciplina, otimizado para IBM Z, conectado a Db2, CICS, MQ, serviços digitais e processos de DevOps.
Do cartão perfurado ao JSON, ele não abandonou sua essência. Continuou sendo uma linguagem desenhada para tratar dados de negócio com clareza e precisão. Só ganhou novas portas, novas interfaces e mais mundos para atravessar.
E, enquanto Igor tenta ligar um bioport USB-C no console do z/OS, vale lembrar a regra final do jogo:
Não modernize porque tem vergonha do COBOL. Modernize porque quer que a regra de negócio continue correta, segura, compreensível e disponível para a próxima geração.
Porque o cartão acabou. A fita virou arquivo. A tela verde ganhou API. O JSON entrou pela porta da frente.
Mas a conta ainda precisa fechar.
