Há números que ajudam a dimensionar a presença do Mainframe na economia global — desde que sejam apresentados com contexto.

Estudos do IBM Institute for Business Value indicam que os mainframes executam perto de 70% das cargas de produção de TI do mundo. A plataforma permanece no centro das operações de 43 dos 50 maiores bancos e de 8 das 10 maiores empresas de pagamentos. Outro estudo do instituto aponta sua utilização por 4 das 5 maiores companhias aéreas.

A presença da plataforma não está apenas sustentada por instalações históricas. Segundo a Forrester, 61% dos tomadores de decisão globais em infraestrutura pesquisados afirmaram que suas empresas utilizavam mainframes. Entre os usuários da plataforma, 54% planejavam ampliar seu uso nos dois anos seguintes.

O desempenho comercial recente também contraria a tese de declínio. No quarto trimestre de 2025, a receita de mainframes da IBM cresceu 61% em relação ao mesmo período do ano anterior, ajustada por efeitos cambiais. Segundo a empresa, foi o melhor quarto trimestre da plataforma em mais de 20 anos.

A Fortune Business Insights estima que o mercado global de mainframes tenha movimentado US$ 5,71 bilhões em 2025 e projeta que alcance US$ 10,53 bilhões em 2034.

A provocação:

As maiores empresas do mundo usam Mainframes porque têm dinheiro, ou parte de sua eficiência vem justamente das plataformas que escolheram para sustentar suas operações?

A resposta não pode ser reduzida a um único percentual de custo. Ela envolve densidade de processamento, consolidação, segurança, disponibilidade, longevidade e previsibilidade operacional.

E onde entra o z/VM nessa história?

O z/VM é o hipervisor que permite explorar esses atributos em ambientes virtualizados. Ele foi projetado para executar de centenas a milhares de servidores convidados em um único IBM Z ou LinuxONE, consolidando cargas e oferecendo ambientes flexíveis para produção, desenvolvimento, testes e homologação.

No modelo de Continuous Delivery, a IBM normalmente disponibiliza uma nova release de z/VM a cada dois anos. A release corrente recebe novas funções, enquanto a anterior continua recebendo suporte corretivo, de segurança e de compatibilidade de processador. Cada release permanece em serviço por aproximadamente 4,5 anos.

Mainframe não é apenas legado preservado. É infraestrutura ativa da economia digital. E o z/VM é uma das tecnologias que permitem extrair eficiência, flexibilidade e longevidade desse investimento.

Mas há um problema estrutural que merece atenção.

Em muitos ambientes que conheci, a administração do z/VM ficou concentrada em equipes de apenas duas a quatro pessoas. São profissionais altamente especializados, que acumulam décadas de conhecimento tácito — aquele que nem sempre está registrado em manuais ou procedimentos.

Esse contingente está diminuindo, enquanto a formação de sucessores não avança no mesmo ritmo. A plataforma recebe pouca exposição nos cursos tradicionais de tecnologia, e a transferência de conhecimento frequentemente começa tarde demais.

O que acontecerá quando essas pessoas deixarem a organização?

Esse não é apenas um problema de retenção de talentos. É um risco de concentração de conhecimento, continuidade operacional e sucessão técnica.

O problema já existe. Pode estar silencioso hoje, mas tende a aparecer justamente quando o tempo de reação for menor.

Quer conversar a respeito?

Ambientes z/VM são excelentes para prototipação. Um ambiente novo pode ser criado em poucas horas, ser ativado apenas durante o tempo em que for necessário e desaparecer em seguida, quando o objetivo for alcançado.
Já fiz isso centenas de vezes. Ambientes exclusivos para validação e testes de sistemas críticos, sem arriscar outros sistemas.
Imagine isto como aqueles filmes de Hollywood, onde centenas de carros são destruídos, tudo dentro de um estúdio, sem sair para as ruas.
Teve um caso destes que ficou marcado em minha memória, não pela atividade em si, mas pela reação do Analista responsável pelos testes.
O projeto consistia no desenvolvimento de um novo sistema crítico para z/OS. O z/VM forneceu a infraestrutura necessária para rodar o sistema sem interferências.
Quando ocorria um termino anormal (ABEND) bastava reiniciar o z/OS em minutos, corrigir o erro e prosseguir, sem depender da agenda dos Laboratórios. Foi uma semana bem agitada, permitindo testar varias situações não planejadas inicialmente.
No final o Analista registrou no Relatório dele:
"Nunca pensei que seria tão produtivo. Se eu precisava de um cabo, os cabos brotavam do chão."
Era verdade em dois sentidos: cabos de rede não planejados eram instalados em poucos minutos. Mas o solo fértil real era o z/VM.

💡 As linguagens nativas do z/VM — um ecossistema próprio

Muita gente pensa que o z/VM é apenas um hipervisor que executa sistemas convidados. Na prática, por meio do CMS — Conversational Monitor System — ele também oferece um ambiente maduro de programação, edição e automação.

REXX — Restructured Extended Executor

Criado por Mike Cowlishaw na IBM, em 1979, o REXX tornou-se a principal linguagem de scripting do ambiente VM. Sua estrutura inclui recursos como IF/THEN/ELSE, DO, SELECT, manipulação avançada de strings e integração com diferentes ambientes de comandos, como CMS, CP e XEDIT.

Com REXX, é possível construir desde pequenas rotinas operacionais até ferramentas completas de administração, monitoramento e provisionamento. Para o administrador de z/VM, conhecer seus fundamentos é um dos caminhos para substituir procedimentos repetitivos por processos automatizados e reproduzíveis.

EXEC 2

Antecessor do REXX, o EXEC 2 continua sendo suportado e ainda pode ser encontrado em instalações mais antigas. É menos estruturado e expressivo que o REXX, mas permanece relevante para a manutenção de rotinas legadas.

CMS Pipelines

CMS Pipelines é uma das ferramentas mais poderosas e, muitas vezes, menos exploradas do ambiente. Ele organiza o processamento em estágios conectados, nos quais a saída de uma etapa alimenta a seguinte.

Sua integração com arquivos CMS, variáveis REXX, comandos e diferentes tipos de fluxo permite selecionar, transformar, combinar e encaminhar dados com grande concisão. Em muitos casos, uma única pipeline substitui rotinas procedurais muito maiores.

É especialmente útil para processamento de arquivos, extração de informações, relatórios e automação operacional.

Macros do XEDIT

O editor XEDIT pode ser ampliado por macros, frequentemente escritas em REXX. Essas macros automatizam tarefas de edição, validação, formatação e transformação de arquivos.

Para quem trabalha diariamente com arquivos de configuração, execs, JCL ou dados operacionais, pequenas macros podem eliminar sequências repetitivas de comandos e reduzir erros manuais.

Por que isso importa?

Dominar essas ferramentas reduz a dependência de produtos externos para muitas tarefas de automação. Mais do que isso, permite explorar capacidades que já fazem parte do ambiente e que, em muitas instalações, permanecem subutilizadas.

O z/VM não oferece apenas virtualização. Ele entrega um ecossistema próprio para construir, integrar e automatizar sua operação.