O que temos para esta semana?
Na seção Institucional: além do anúncio do 7.5.
Na seção História, a longevidade e o modelo Continuous Delivery.
Na seção Dicas, o comando SIGNAL SHUTDOWN.
Institucional
IBM z16
z/VM 7.5 — além do anúncio
A IBM publicou, em 17 de fevereiro de 2026, o preview do z/VM 7.5, com disponibilidade planejada para o terceiro trimestre de 2026.
Reduzir essa nova versão apenas ao suporte aos processadores mais recentes, entretanto, seria ignorar um conjunto amplo de entregas planejadas.
Entre os destaques anunciados:
Host Secure Boot: verificação da autenticidade e da integridade do software utilizado durante o IPL, ajudando a impedir a execução de componentes adulterados ou não confiáveis.
Spyre AI Accelerator: possibilidade de configurar dinamicamente adaptadores Spyre para uso por máquinas virtuais, atendendo ambientes como Red Hat OpenShift AI e IBM watsonx Assistant for Z.
Memory Overcommitment Control: definição administrativa de níveis aceitáveis de sobrealocação de memória, reduzindo o risco de degradação de desempenho e melhorando o diagnóstico.
Real Memory Scalability: requisito mínimo de 4 GB de memória real, com uma região de 2 GB reservada ao CP, preparando a infraestrutura para futuras cargas de grande memória.
RACF Simplification: redução da necessidade de modificar módulos específicos do RACF/VM dentro do CPLOAD MODULE.
z/CMS como padrão: adoção do z/CMS como ambiente CMS padrão, mantendo o CMS/390 para compatibilidade.
System Infrastructure VSwitch: conectividade mais consistente para guests de infraestrutura do sistema.
HYPERSWAP for Guest HYPERPAV: ampliação dos cenários de recuperação de desastre para guests com configurações HYPERPAV ativas.
Semantic Versioning para o CP: modernização da identificação das versões do Control Program.
Melhorias em GDPS, System SSL, DirMaint, drenagem de volumes PAGE e nas ferramentas Diff e Patch para CMS, entre outras.
Como se trata de um preview, funcionalidades e datas ainda estão sujeitas a alterações até a disponibilidade geral.
O risco de um ambiente de recuperação incompatível
Manter o sistema produtivo atualizado é parte da responsabilidade operacional. O risco menos visível aparece quando o ambiente de recuperação permanece baseado em um processador que não oferece as facilities exigidas pelo nível do CP que será carregado.
No momento em que o DR for necessário — justamente quando a continuidade do negócio estiver sob pressão — o IPL poderá resultar na mensagem:
HCP9030W: CP REQUIRES HARDWARE FEATURES NOT AVAILABLE ON THIS PROCESSOR
Nesse caso, os requisitos de hardware do CP não foram atendidos, e o sistema entra em disabled wait state.
A questão, portanto, não é apenas manter os ambientes principal e de recuperação com atualizações semelhantes. É assegurar que cada processador previsto para receber o sistema tenha modelo, firmware e facilities compatíveis com o nível do CP.
No z/VM 7.5, o Architecture Level Set anunciado exige IBM z16 nos modelos especificados pela IBM, IBM LinuxONE 4 nos modelos especificados, ou sistemas posteriores. Um IBM z15 não atende ao ALS previsto para essa versão.
Compatibilidade declarada em uma planilha não substitui um teste real de IPL e recuperação.
Fale comigo sobre o assunto, caso precise. Já enfrentei esse tipo de situação na prática.
História
A continuidade e longevidade
A a longevidade do z/VM e o modelo de Continuous Delivery
Desde o z/VM 7.1, lançado em 2018, o produto adota um modelo de Continuous Delivery.
Nesse modelo, novas releases são planejadas em ciclos de aproximadamente dois anos, tradicionalmente no terceiro trimestre dos anos pares. Cada release permanece em serviço por aproximadamente quatro anos e meio, com períodos planejados de sobreposição.
O modelo funciona, em linhas gerais, assim:
Release corrente: recebe novas funções por meio do fluxo de serviço, além de compatibilidade com processadores, atualizações de segurança e serviço corretivo.
Release anterior: fica funcionalmente estabilizada, sem receber as novas funções destinadas à release corrente, mas continua recebendo compatibilidade de processadores, segurança e correções durante seu período de serviço.
Normalmente, há pelo menos duas releases em serviço simultaneamente. Nos meses finais do ciclo de uma release, podem existir três releases ainda suportadas, oferecendo mais opções para o planejamento da migração.
Essa previsibilidade permite que o cliente escolha entre adotar rapidamente novas funções ou permanecer temporariamente em uma base funcional estabilizada.
Ainda assim, permanecer indefinidamente na mesma versão não é uma estratégia. Ao final do período de serviço, o ambiente deixa de receber o suporte regular previsto para aquela release.
O impacto do ALS do z/VM 7.5
O Architecture Level Set previsto para o z/VM 7.5 exige determinados modelos IBM z16 e IBM LinuxONE 4, ou posteriores.
Isso significa que empresas que ainda operam o z/VM em IBM z15 não poderão simplesmente instalar a nova release nesse equipamento. Antes da migração de software, será necessário disponibilizar hardware compatível com o ALS.
Em ambientes com gerações diferentes de processadores, o planejamento precisa considerar:
onde o z/VM 7.5 será executado;
quais processadores poderão assumir a carga em uma contingência;
se os ambientes de DR possuem as facilities necessárias;
e se os procedimentos de recuperação já foram efetivamente testados.
A compatibilidade das aplicações e dos sistemas guests também deve ser validada separadamente. Um novo nível de hipervisor não elimina a necessidade de verificar cada componente da solução.
Planejamento é tudo. E é onde eu posso ajudar.
Dicas
Signal Shutdown, o Xerifão
Signal Shutdown — “Senhor Guest, você tem 300 segundos para organizar sua saída”
Encerrar abruptamente uma máquina virtual equivale, em muitos casos, a retirar a energia de um servidor físico.
Dependendo do sistema operacional e das aplicações em execução, isso pode provocar transações incompletas, inconsistências em sistemas de arquivos, necessidade de recuperação de bancos de dados e outras intervenções operacionais.
O z/VM oferece o mecanismo de shutdown signal para reduzir esse risco.
Com o comando SIGNAL SHUTDOWN, o operador envia um sinal ao guest e define quanto tempo ele terá para concluir o encerramento. Um exemplo comum é:
SIGNAL SHUTDOWN userid WITHIN 300
Nesse exemplo, são concedidos até 300 segundos para que o sistema guest execute seu processo de desligamento.
O guest poderá, conforme sua implementação:
interromper novos serviços;
concluir ou cancelar transações;
fechar bancos de dados;
desmontar sistemas de arquivos;
liberar recursos;
e finalizar o sistema operacional de forma ordenada.
Há uma condição importante: o sistema operacional guest precisa ter suporte ao recebimento e ao tratamento do shutdown signal. Essa condição deve ser verificada com os comandos e procedimentos apropriados antes da janela de manutenção.
Por que isso é importante?
Reduz o risco de inconsistências provocadas por encerramentos abruptos.
Permite retirar guests de operação antes de um IPL ou de uma intervenção de hardware.
Torna a janela de manutenção mais previsível.
Facilita a identificação de guests que não respondem corretamente ao procedimento.
Permite reservar o uso do
FORCEpara as situações em que o encerramento controlado realmente falhou.
Os 300 segundos não são uma regra universal. O intervalo deve ser definido conforme o sistema operacional, as aplicações, os bancos de dados e o tempo necessário para cada guest encerrar corretamente.
O Signal Shutdown transforma uma ação potencialmente abrupta em um procedimento administrado.
É como avisar o inquilino antes de desligar as luzes do prédio: cada um tem tempo para fechar suas atividades e sair de maneira organizada.
📞 Vamos conversar?
A longevidade planejada das releases do z/VM é uma vantagem operacional, desde que o ciclo de manutenção seja administrado com disciplina.
Não basta avaliar apenas a versão instalada no ambiente produtivo. É necessário considerar hardware, facilities, serviço aplicado, guests, aplicações, conectividade e capacidade real de recuperação.
Fale comigo para avaliarmos juntos a estratégia de hardware, software e continuidade dos seus ambientes críticos.
