Bellacosa Mainframe e o ibm z aprendendo Arm o proximo passo nos cpds

☕ Um Café no Bellacosa Mainframe

Leonardo da Vinci Entra no CPD — O Dia em que o IBM Z Aprendeu Arm sem Esquecer COBOL

Ou: como um processador de 2 nm, onze núcleos, três alfabetos de máquina e vinte e dois milhões de desenvolvedores transformaram o mainframe numa oficina renascentista — sem ninguém recompilar a folha de pagamento numa tarde de sexta-feira

Imagine que Leonardo da Vinci, depois de desenhar máquinas voadoras, estudar o corpo humano, projetar pontes e encher cadernos com anotações escritas ao contrário, receba um crachá temporário para visitar um moderno CPD.

Ele atravessa a porta dupla, observa as luzes do IBM Z e pergunta:

— Qual é a função desta grande máquina negra?

O programador COBOL iniciante responde:

— Processar contas bancárias, cartões, seguros, folhas de pagamento, reservas, impostos e quase tudo que não pode dar errado.

Leonardo examina os cabos, aproxima o ouvido do gabinete e conclui:

— Então não é apenas uma máquina. É uma cidade fortificada feita de silício.

Em agosto de 2026, a IBM anunciou um projeto que pode abrir um novo portão nessa cidade: seu primeiro processador de mainframe com duas arquiteturas, preparado para executar nativamente instruções IBM Z e Arm. O futuro chip, destinado a gerações posteriores do IBM Z e LinuxONE, foi anunciado com tecnologia de 2 nanômetros, 11 núcleos acima de 5,7 GHz, aceleradores de inteligência artificial, uma DPU dedicada a I/O e uma grande estrutura de cache.

Mas o que significa colocar Arm no mainframe? COBOL passará a executar em celular? Um aplicativo Android poderá entrar no JES2? O z/OS será substituído? E onde entram x86-64, AArch64 e s390x nessa oficina?

Vamos abrir o capô sob a tutela imaginária de Leonardo da Vinci.

Prólogo — O computador não entende COBOL

Esta revelação costuma assustar o padawan: o processador não entende COBOL, Java, Python ou C.

O processador entende instruções de máquina.

Quando escrevemos:

COMPUTE TOTAL = PRECO * QUANTIDADE

o compilador examina a frase COBOL e produz uma sequência de instruções compatível com a arquitetura de destino. Em um IBM Z, o resultado contém instruções da arquitetura Z. O fonte é legível para humanos; o executável é preparado para o processador e para o ambiente operacional.

Leonardo talvez comparasse isso aos seus projetos. O desenho de uma ponte representa uma ideia. Para construí-la, porém, alguém precisa converter o desenho em medidas, cortes, encaixes e operações compatíveis com os materiais disponíveis.

O código-fonte é o desenho. O compilador é o mestre da oficina. O binário é a coleção de ordens entregues às ferramentas.

1. ISA: o alfabeto secreto do processador

ISA significa Instruction Set Architecture, ou arquitetura do conjunto de instruções. Ela define o contrato entre software e processador:

instruções reconhecidas;
registradores disponíveis;
maneiras de acessar memória;
operações matemáticas e lógicas;
desvios e chamadas;
tratamento de exceções;
operações atômicas;
estados privilegiados usados pelo sistema operacional.

Três arquiteturas importantes nesta conversa são:

Arquitetura	Onde aparece principalmente	Nome visto em ferramentas
x86-64	PCs e servidores Intel/AMD	`x86_64`, `amd64`
AArch64	Arm de 64 bits, celulares, Apple Silicon e cloud	`aarch64`, `arm64`
IBM Z	Mainframes e LinuxONE	`s390x` em Linux

Elas podem realizar tarefas equivalentes, mas codificam as ordens de maneiras diferentes. É como escrever a mesma receita em português, italiano e japonês: o bolo pode ser o mesmo, mas não se lê um texto japonês aplicando automaticamente as regras do italiano.

Um programa compilado para x86-64 não se transforma em AArch64 apenas porque foi copiado. Da mesma forma, uma imagem arm64 não roda nativamente numa máquina que compreenda somente s390x.

Curiosidade de oficina

AMD64 e x86-64 normalmente designam a mesma arquitetura básica. O nome AMD64 existe porque foi a AMD que criou a extensão de 64 bits do x86 que venceu no mercado; a Intel depois adotou uma implementação compatível, comercialmente chamada Intel 64.

O pequeno detalhe histórico rende um belo easter egg: durante anos muita gente associou “x86” automaticamente à Intel, mas a estrada de 64 bits usada pela maioria dos PCs foi traçada pela concorrente.

2. x86-64: o palácio construído sem demolir as alas antigas

A linhagem x86 começou com o Intel 8086, lançado em 1978, e atravessou diversas gerações. Sua grande força foi preservar compatibilidade.

8086 → 80286 → 80386 → x86 de 32 bits → x86-64

É um palácio ampliado durante décadas. Novas alas foram construídas, corredores foram modernizados, elevadores foram instalados, mas várias portas antigas continuam ali porque alguém ainda pode precisar atravessá-las.

Essa herança aparece nos registradores:

RAX = 64 bits
EAX = 32 bits inferiores
 AX = 16 bits inferiores
 AL = 8 bits inferiores
 AH = outros 8 bits históricos

Também aparece nas instruções de comprimento variável. Uma instrução x86-64 pode ocupar quantidades diferentes de bytes. O processador precisa decodificar onde cada instrução começa, quais prefixos possui, quais operandos utiliza e onde termina.

Historicamente, x86 é classificada como CISC — Complex Instruction Set Computer. Algumas instruções podem realizar operações relativamente complexas ou trabalhar diretamente com valores na memória.

Mas não confunda complexidade da ISA com incompetência. Processadores AMD e Intel modernos são extraordinárias obras de engenharia. Internamente, eles frequentemente decompõem instruções x86 complexas em micro-operações menores, executam-nas fora de ordem, especulam desvios e reorganizam resultados mantendo a aparência exigida pelo programa.

Leonardo reconheceria a técnica: uma alavanca visível ao operador pode acionar uma engrenagem, que aciona três rodas, que movem seis peças. A interface externa parece simples; o mecanismo interno faz uma coreografia.

3. AArch64: uma nova oficina para os 64 bits

AArch64 é o estado de execução de 64 bits introduzido pela arquitetura Armv8-A. Também aparece como ARM64.

Ao contrário do x86-64, que estendeu uma longa linhagem, AArch64 foi desenhada como uma arquitetura de 64 bits mais regular. Suas instruções normalmente possuem 32 bits de comprimento, ou quatro bytes.

Ela oferece 31 registradores gerais visíveis, normalmente chamados X0 a X30. Para acessar os 32 bits inferiores, usa-se W0 a W30.

X0 = registrador de 64 bits
W0 = parte de 32 bits de X0

AArch64 segue a tradição RISC — Reduced Instruction Set Computer — e uma filosofia load/store. Operações aritméticas trabalham principalmente com registradores. Para manipular um valor guardado na memória, normalmente fazemos três movimentos conceituais:

carregar o valor;
executar a operação;
gravar o resultado, se necessário.

Exemplo didático:

ldr x0, [x1]      // traz um valor da memória
add x0, x0, x2    // soma usando registradores
str x0, [x1]      // devolve o resultado à memória

Isso não quer dizer que Arm seja uma arquitetura “simples” ou “fraca”. Apple Silicon, AWS Graviton, Ampere e outros projetos demonstram que Arm pode alimentar computadores pessoais e servidores de alto desempenho.

RISC e CISC explicam estilos arquiteturais, não determinam sozinhos quem vence uma corrida. Frequência, cache, memória, processo de fabricação, unidades vetoriais, quantidade de núcleos, compilador e workload pesam enormemente.

Dica para o padawan

Nunca escreva numa apresentação que “Arm é mais rápido porque é RISC” ou “x86 é melhor porque possui instruções mais poderosas”. Isso seria como afirmar que COBOL sempre vence Java porque COMPUTE parece mais empresarial.

Peça o benchmark, conheça o workload e verifique o custo total.

4. A mesma aplicação, binários diferentes

Considere este pequeno programa em C:

int soma(int a, int b) {
    return a + b;
}

Um compilador para x86-64 poderia gerar, de forma simplificada:

mov eax, edi
add eax, esi
ret

Em AArch64, o mesmo fonte poderia resultar em:

add w0, w0, w1
ret

A finalidade é igual. Os registradores, instruções e bytes produzidos são diferentes.

Daí nasce uma regra essencial:

Fonte portátil não significa binário portátil.

Para portar uma aplicação, talvez baste recompilar. Porém, talvez o programa contenha assembler, bibliotecas fechadas, suposições sobre tamanho de dados, drivers particulares ou dependências não disponíveis. Nesses casos, a travessia torna-se mais trabalhosa.

Em COBOL conhecemos esse problema. Um fonte escrito seguindo padrões pode ser adaptado entre plataformas, mas um executável compilado para z/OS não é simplesmente copiado para IBM i, Windows ou Linux e executado como se nada tivesse acontecido.

5. ISA não é sistema operacional

Mesmo dois computadores que usem a mesma arquitetura podem não executar o mesmo binário.

Compare:

AArch64 + Linux
AArch64 + macOS
AArch64 + Windows

Todos podem usar processadores que entendem AArch64. Entretanto, os programas dependem também de:

formato do executável;
ABI, a interface binária da aplicação;
convenções de chamada;
bibliotecas;
carregador;
chamadas de sistema;
serviços do sistema operacional.

Portanto, um programa Linux Arm não se torna automaticamente um aplicativo macOS apenas porque ambos usam Arm.

Leonardo desenharia camadas concêntricas:

Aplicação
Bibliotecas e runtime
Sistema operacional
Virtualização e firmware
ISA
Microarquitetura e silício

O anúncio da IBM começa profundamente nas camadas inferiores, mas seu valor comercial dependerá de todas as camadas superiores.

6. Containers: o contêiner leva a casa, não leva o terreno

Existe um mito segundo o qual um container roda em qualquer lugar. Ele roda em qualquer ambiente compatível, o que é diferente.

Uma imagem OCI pode ser publicada para:

linux/amd64
linux/arm64
linux/s390x
linux/ppc64le

Um fornecedor pode manter o mesmo nome lógico, mas armazenar variantes com binários apropriados. O registry examina a arquitetura solicitada e entrega a imagem correta por meio de um índice ou manifesto multiarch.

O container empacota aplicação, bibliotecas e configuração, mas normalmente compartilha o kernel do host e continua dependendo da ISA. Ele leva os móveis e as paredes internas; não leva um planeta novo debaixo da casa.

Passo a passo para verificar uma imagem

Consulte a documentação do fornecedor.
Procure amd64, arm64 ou s390x nas plataformas suportadas.
Examine o manifesto multiarch com uma ferramenta OCI ou Docker.
Confirme que todas as dependências possuem a mesma arquitetura.
Teste em ambiente controlado.
Não confunda “iniciou” com “é oficialmente suportado”.

Essa última diferença evita muitos ABENDs administrativos. Uma aplicação pode funcionar no laboratório e ainda assim não possuir suporte do fabricante para produção.

7. Endianness: quando Leonardo escreve os bytes ao contrário

Leonardo ficou famoso por suas anotações espelhadas. Isso nos oferece uma analogia perfeita para endianness: a ordem em que os bytes de um número aparecem na memória.

Considere 0x12345678:

Big-endian:     12 34 56 78
Little-endian:  78 56 34 12

x86-64 é normalmente little-endian. Linux AArch64 também é normalmente little-endian. Linux s390x tradicionalmente trabalha em big-endian.

Ao trocar JSON, XML, mensagens MQ ou Protocol Buffers corretamente serializados, a camada de comunicação trata a representação. Ao compartilhar estruturas binárias brutas, o programador precisa ter cuidado.

Imagine gravar o tamanho de um pagamento em quatro bytes e o destinatário lê-los na ordem oposta. O valor de um cafezinho pode chegar ao sistema de liquidação vestido de aquisição corporativa.

Easter egg número 1

Se encontrar 0x4C454F perdido num exemplo hexadecimal, converta os bytes para ASCII. Leonardo deixou sua assinatura na oficina.

8. Emulação não é execução nativa

Quando um processador não entende a ISA de um programa, um tradutor pode intervir.

Binário x86-64
      ↓ tradução
Instruções AArch64
      ↓
Processador Arm

Rosetta 2 nos Macs Apple Silicon e mecanismos do Windows on Arm mostram que tradução pode oferecer excelente experiência. QEMU consegue emular diversas arquiteturas. Porém, existe uma camada adicional e nem toda instrução, extensão ou comportamento terá desempenho idêntico ao nativo.

Execução nativa ocorre quando o hardware compreende diretamente a ISA para a qual o binário foi produzido.

É exatamente por isso que o anúncio da IBM chama atenção: a empresa declara que não está colocando núcleos Arm separados nem oferecendo mera emulação. A proposta é integrar a ISA Arm aos próprios núcleos do futuro processador de mainframe.

9. O processador bilíngue da IBM

Segundo a IBM, cada núcleo poderá executar nativamente instruções IBM Z e Arm. Ambientes Linux Arm-native poderão operar simultaneamente com z/OS e Linux on IBM Z.

Isso não significa misturar instruções Arm dentro de um programa COBOL arbitrariamente. Tampouco significa copiar um APK para uma biblioteca de carga e executar:

//LEONARDO JOB CLASS=A,MSGCLASS=X
//STEP01   EXEC PGM=MONALISA
//STEPLIB  DD DSN=ANDROID.ARM64.LOAD,DISP=SHR

O JES2 provavelmente responderia com a serenidade de um monge e a crueldade de um auditor.

O cenário é de ambientes distintos sobre a mesma plataforma:

Processador dual-architecture
├── contexto IBM Z
│   ├── z/OS
│   └── Linux s390x
└── contexto Arm
    └── Linux AArch64

O hardware fala dois idiomas; sistemas operacionais e aplicações ainda ocupam seus ambientes apropriados.

10. O grande prêmio: levar o cálculo até os dados

Mainframes guardam dados críticos de bancos, seguradoras, governos, companhias aéreas e grandes varejistas. Hoje, um componente moderno frequentemente consulta esses dados atravessando redes, gateways e camadas de integração.

Aplicação externa → API → integração → CICS → Db2

Cada seta pode significar latência, criptografia, credenciais, filas, cópias, custo e um novo ponto de falha.

Se um serviço Arm-native puder operar dentro da mesma plataforma física, próximo ao CICS, IMS e Db2, torna-se possível mover parte do processamento até os dados em vez de exportar dados para todo processamento novo.

Exemplo: autorização de cartão

CICS recebe a solicitação.
COBOL valida conta, limite e regras consolidadas.
Db2 fornece histórico relevante.
Um serviço Arm-native executa uma biblioteca de análise comportamental.
Um acelerador de IA calcula a probabilidade de fraude.
O resultado volta à transação.
RACF, criptografia e auditoria protegem e registram o processo.

COBOL não é substituído pela IA. O programa transacional ganha um conselheiro especializado.

O chip anunciado também inclui aceleração de inferência voltada a fraude durante transações e uma DPU dedicada a I/O. Isso combina com a tradição Z de não tratar movimentação de dados como tarefa secundária.

11. DPU: o mestre de logística da oficina

DPU significa Data Processing Unit. Ela pode descarregar tarefas relacionadas à movimentação e ao processamento de dados que, de outra forma, ocupariam os núcleos gerais.

Leonardo provavelmente desenharia a DPU como o encarregado do porto:

recebe cargas;
organiza filas;
movimenta contêineres;
controla rotas;
deixa o mestre artesão trabalhar na peça principal.

No mainframe, isso é quase uma tradição familiar. A plataforma sempre utilizou inteligência e componentes especializados para I/O, evitando que a CPU central carregue sozinha todos os baldes da cidade.

12. Frequência não é desempenho

O processador foi anunciado com mais de 5,7 GHz. O número impressiona, mas não pode ser usado sozinho para comparar máquinas.

Desempenho depende de:

instruções concluídas por ciclo;
previsão de desvios;
latência e tamanho dos caches;
largura de memória;
unidades vetoriais;
aceleração específica;
quantidade de núcleos;
sistema operacional;
compilador;
comportamento do workload.

Um motor girando mais depressa não necessariamente transporta mais carga. Precisamos conhecer torque, transmissão, peso e terreno.

No IBM Z importam também throughput sustentado, disponibilidade, isolamento, capacidade de recuperação e latência previsível. Ganhar uma corrida de dez segundos é diferente de processar milhões de transações diariamente sem derrubar a ponte.

13. O ecossistema Arm entra no castelo

A IBM aponta um universo superior a 22 milhões de desenvolvedores Arm. Esse é um dos argumentos estratégicos mais fortes.

Muitos projetos modernos são publicados primeiro para amd64 e arm64. Algumas bibliotecas, agentes, ferramentas de IA e imagens de containers não chegam a s390x, ou chegam posteriormente.

Ao executar Arm nativamente, o IBM Z pode reduzir a necessidade de portar cada componente antes de usá-lo. Isso poderá ampliar opções para:

containers;
microsserviços;
inferência de IA;
agentes de automação;
observabilidade;
segurança;
processamento de eventos;
ferramentas cloud-native.

Mas ampliar o mercado também amplia a cadeia de suprimentos. Uma imagem abandonada e repleta de vulnerabilidades não se torna segura apenas porque entrou num mainframe.

Serão indispensáveis:

SBOM;
assinatura de imagens;
verificação de procedência;
varredura de vulnerabilidades;
controle de privilégios;
política de atualização;
suporte do fornecedor;
observabilidade.

O RACF não asperge água benta sobre um container com senha admin123.

14. As perguntas que ainda não possuem resposta completa

O anúncio descreve uma direção tecnológica, não um manual de planejamento.

Ainda precisamos conhecer detalhes como:

Uma LPAR será definida como Z ou Arm?
PR/SM administrará os dois contextos de que maneira?
z/VM ou KVM hospedarão guests Arm?
Como HMC mostrará capacidade e consumo?
Como serão dumps, traces e contadores de desempenho?
OpenShift agendará pods s390x e arm64 no mesmo conjunto?
Como funcionará compartilhamento de I/O e memória?
Quais sistemas operacionais e versões serão suportados?
Como será o licenciamento?
Workloads Arm afetarão métricas tradicionais de software?

A TechChannel estimou disponibilidade em aproximadamente dois anos com base na cadência da IBM. Isso apontaria para algo por volta de 2028, mas não é uma data oficial de produto. A própria IBM classifica declarações futuras como objetivos sujeitos a alteração.

Dica de arquiteto

Separe sempre três colunas em suas anotações:

Categoria	Exemplo
Confirmado	2 nm, 11 núcleos, mais de 5,7 GHz e duas ISAs nativas
Objetivo declarado	Linux Arm-native ao lado de z/OS e Linux Z
Ainda não detalhado	LPAR, preços, licenciamento e versões suportadas

Essa disciplina impede que uma promessa de arquitetura seja apresentada ao cliente como feature disponível na próxima terça-feira.

15. Um roteiro de estudos para o programador COBOL

O iniciante não precisa abandonar COBOL e correr desesperadamente para assembler Arm. Pode avançar por etapas.

Etapa 1 — Entenda a pilha

Aprenda a distinguir:

fonte → compilador → objeto → linkedição → executável → sistema operacional → ISA

No mundo z/OS, relacione isso a compile, link-edit/binder, load module ou program object e execução via batch ou subsistema.

Etapa 2 — Reconheça arquiteturas

Memorize os três rótulos:

amd64  = x86-64
arm64  = AArch64
s390x  = IBM Z em Linux

Etapa 3 — Observe imagens multiarch

Escolha uma imagem conhecida, consulte seu manifesto e veja quais plataformas são publicadas. Perceba que o nome lógico pode esconder binários diferentes.

Etapa 4 — Aprenda integração

Estude:

APIs REST;
JSON;
MQ;
z/OS Connect;
CICS web services;
autenticação e autorização.

O futuro profissional valioso será a ponte entre o core e os serviços modernos.

Etapa 5 — Faça um laboratório mental

Desenhe uma aplicação COBOL que consulta Db2 e chama um serviço antifraude. Marque:

onde começa a transação;
quais dados saem;
qual identidade é usada;
qual timeout existe;
o que acontece se o serviço falhar;
como a operação será auditada.

Etapa 6 — Nunca esqueça o rollback

Se a análise Arm demorar ou ficar indisponível, a transação deve saber se recusa, aprova com limites ou encaminha para revisão. Modernização sem tratamento de falha é apenas uma demonstração com gravata.

16. O que isso representa para a carreira mainframe

O anúncio não reduz o valor do especialista Z; ele aumenta o território que esse profissional pode conectar.

As empresas precisarão de pessoas que compreendam simultaneamente:

COBOL + CICS + IMS + Db2 + RACF
                 ↕
Linux + Arm + containers + APIs + IA

O profissional raro não será necessariamente quem sabe decorar toda instrução de três arquiteturas. Será quem entende os contratos entre elas, reconhece riscos e desenha uma solução suportável.

O padawan COBOL deve aprender a conversar com desenvolvedores cloud sem desprezar o legado e sem aceitar que toda arquitetura nova seja automaticamente revolucionária.

Leonardo dominava pintura, anatomia, mecânica e hidráulica não porque confundia as disciplinas, mas porque sabia enxergar relações entre elas.

Esse é o modelo do novo arquiteto de mainframe.

17. Easter eggs da sala de máquinas

Alguns pequenos segredos para quem chegou até aqui:

Leonardo escrevia parte de suas notas de maneira espelhada; por isso ele foi escolhido como tutor da seção de endianness.
“A máquina voadora” simboliza tecnologias que podem ser tecnicamente brilhantes e ainda depender de materiais, operação e contexto para funcionar comercialmente.
O programa MONALISA no JCL não existe — ao menos até algum chimpanzé do Bellacosa Mainframe registrá-lo num PDS.
Se a futura plataforma receber um serviço chamado VITRUVIAN, verifique se ele escala proporcionalmente ou apenas posa dentro de um círculo.
O verdadeiro boss final não apareceu no silício: chama-se licenciamento.

Conclusão — O códice do mainframe bilíngue

x86-64, AArch64 e s390x são alfabetos de máquina diferentes. Um mesmo código-fonte pode ser compilado para mais de um deles, mas os binários produzidos não são intercambiáveis. Containers carregam aplicações e dependências, porém continuam presos à arquitetura e ao kernel compatível. Emulação traduz; execução nativa entrega as instruções diretamente ao hardware apropriado.

O projeto da IBM é histórico porque pretende colocar duas ISAs dentro dos próprios núcleos do futuro processador: IBM Z e Arm. Isso poderá permitir ambientes Linux AArch64 ao lado de z/OS e Linux s390x, aproximando software moderno dos dados e das transações centrais.

Não significa que z/OS executará qualquer aplicativo Arm, que COBOL será substituído ou que todas as dificuldades de integração desaparecerão. Sistemas operacionais, ABIs, bibliotecas, segurança, virtualização, endianness, suporte e licenciamento continuarão importando.

A grande mudança é outra:

Durante décadas, o software precisou aprender o idioma do mainframe. Agora o próprio mainframe está aprendendo um novo idioma sem esquecer aquele que protegeu sua história.

Leonardo fecha o caderno, observa o IBM Z e faz seu último desenho: de um lado, um programa COBOL sustentando as contas do banco; do outro, um serviço Arm trazendo IA e software cloud-native. Entre ambos, uma ponte feita de APIs, segurança, virtualização e disciplina operacional.

Antes de sair, ele escreve no quadro — desta vez da esquerda para a direita:

ISA NÃO É SISTEMA OPERACIONAL.
CONTAINER NÃO É EMULADOR.
FREQUÊNCIA NÃO É DESEMPENHO.
MODERNIZAÇÃO NÃO É APAGAR O PASSADO.

O programador iniciante pergunta:

— Mestre Leonardo, então qual é a verdadeira inovação?

Ele aponta para a máquina e responde:

— Não obrigar o passado e o futuro a disputarem a mesma cadeira. Construir uma mesa grande o suficiente para que ambos trabalhem juntos.

No fundo do CPD, alguém submete um job. O JES2 aceita. O serviço Arm responde. O Db2 confirma o COMMIT.

E, por uma vez, ninguém recebeu S0C7 por tentar interpretar os bytes ao contrário.

Translate

quinta-feira, 3 de setembro de 2026