Homens de Preto no Data Center — Quando o Agente J Encontrou uma GPU no LinuxONE e Perguntou: “Isso Aqui É CUDA ou o Igor Colou um RTX no PCIe?”

 

Bellacosa Mainframe e a possivel ponte em ibm z e nvidia sera????

☕ Um Café no Bellacosa Mainframe

Homens de Preto no Data Center — Quando o Agente J Encontrou uma GPU no LinuxONE e Perguntou: “Isso Aqui É CUDA ou o Igor Colou um RTX no PCIe?”

Ou: IBM colocou Arm dentro do futuro processador Z, NVIDIA já fala essa língua, o jovem padawan COBOL descobriu que uma placa gráfica não é um pendrive grande — e o Agente J precisou explicar DMA, IOMMU e LPAR antes que alguém chamasse o serviço de manutenção cósmica

---

Prólogo — uma luz estranha em Armonk

Agente J entrou na sala de máquinas com o Neuralyzer numa mão e um copo de café na outra.

— K, tem uma criatura de silício dizendo que o próximo IBM Z e LinuxONE pode executar Arm nativamente.

— Não a apague da memória, J. A IBM anunciou isso em 24 de agosto de 2026, durante o Hot Chips. É uma das notícias mais importantes para quem trabalha com mainframe desde que alguém resolveu chamar servidor de “legado” sem perceber que o legado estava pagando a conta do banco.

O anúncio descreve um futuro processador de dupla arquitetura para IBM Z e LinuxONE: em vez de haver um núcleo IBM de um lado e um núcleo Arm pendurado do outro, cada núcleo é projetado para executar instruções IBM e Arm de forma nativa. A meta é permitir ambientes Linux Arm ao lado de z/OS e do Linux que já vive em Z/LinuxONE. São planos de produto futuros, sujeitos a mudança; não existe, hoje, um menu da HMC com o botão “instalar CUDA e chamar a NVIDIA”. Mas o desenho muda a conversa inteira.

Para um programador COBOL iniciante, a notícia pode parecer distante. “Eu só quero meu READ, meu WRITE, um Db2 que não dê -911 e um CICS que não transforme a sexta-feira em incidente.” Justamente por isso ela importa. Mainframe não está virando PC gamer; está tentando deixar de ser uma ilha para uma parte maior da economia de software chegar perto daquilo que ele faz melhor: transações, dados críticos, disponibilidade e paranoia institucional bem aplicada.

Easter egg #1: o Agente J não disse “paranoia”. Ele disse “controle de acesso preventivo contra organismos com DMA”. O RACF aprovou a redação.

1. Primeiro: o que a IBM anunciou — e o que ela não anunciou

Vamos separar o café do conhaque.

A IBM anunciou uma direção arquitetural: processador futuro de 2 nm, 11 núcleos acima de 5,7 GHz, aceleradores de inferência e uma DPU de I/O no chip. O ponto realmente extraordinário é a implementação de AArch64/Arm em hardware, não por emulação. A IBM e a Arm dizem que a intenção é executar Linux Arm nativo simultaneamente com ambientes IBM tradicionais e herdar a escala, segurança e resiliência do Z/LinuxONE.

Ela não anunciou:

• uma GPU NVIDIA certificada para Z ou LinuxONE;

• CUDA em z/OS;

• um driver NVIDIA s390x;

• um DGX escondido dentro de um frame;

• compatibilidade automática com qualquer placa comprada numa promoção suspeita.

Essa distinção protege você de duas doenças profissionais: o entusiasmo que vende PowerPoint como produto e o ceticismo que chama de “marketing” qualquer coisa que ainda não chegou ao rack. A posição correta é mais interessante: existe agora uma ponte arquitetural plausível; atravessá-la exige engenharia, qualificação e acordo comercial.

2. Por que Arm muda o problema da NVIDIA

Historicamente, Linux no IBM Z usa a arquitetura s390x. É excelente no seu território, mas possui um custo invisível: cada fornecedor externo precisa decidir se mantém outra compilação, outro pipeline de testes, outro driver de kernel, outra equipe de suporte e outra matriz de versões para um mercado menor que x86 e Arm.

Imagine que você escreveu um programa COBOL para ler um arquivo VSAM. Não basta entregar o fonte a alguém: é preciso compilador, copybooks, JCL, permissões RACF, dataset correto, testes e alguém responsável quando o job abendar às 02h17. Com uma GPU é igual, só que o “copybook” envolve firmware, PCIe, memória, interrupções e DMA.

NVIDIA já mantém uma pilha madura para Linux AArch64: driver, CUDA Toolkit, compiladores, bibliotecas como cuDNN e NCCL, PyTorch, TensorFlow e uma multidão de aplicações que nasceram para Arm em nuvens e servidores. Grace, Graviton, Ampere e Cobalt ajudaram a transformar Arm server em destino comercial sério.

Assim, a pergunta deixa de ser “NVIDIA, você pode criar e sustentar s390x?” e passa a ser “IBM, o seu ambiente Arm parece suficientemente um servidor Arm convencional para a pilha existente funcionar e ser suportada?”.

É uma diferença brutal:

Problema antigo	Problema possível no novo cenário
Portar uma arquitetura inteira	Qualificar uma plataforma Arm
Criar cadeia de ferramentas	Reutilizar uma cadeia AArch64
Testar um mercado exótico	Testar uma variante enterprise de Arm
Manter driver específico s390x	Adaptar/validar driver Arm já existente

Não é garantia. É a troca de “construa uma estrada no oceano” por “a estrada chegou à fronteira; vamos inspecionar a ponte”.

3. Falar Arm não basta: o passaporte chamado SystemReady

Uma CPU saber executar instruções Arm é como o Agente J aprender um idioma alienígena. Útil, mas não informa em qual lado da rua ele deve dirigir, qual tomada existe no hotel ou se o passaporte abre a porta da alfândega.

Para Linux e drivers, o mundo abaixo da aplicação importa muito. Eles precisam reconhecer um ambiente previsível: firmware de boot, tabelas de hardware, relógios, controladores de interrupção, memória, PCIe, IOMMU, ACPI/UEFI e regras de descoberta de dispositivos. É isso que padrões como Arm SBSA, requisitos de boot e o programa Arm SystemReady tentam normalizar.

Relatos técnicos do Hot Chips indicam AArch64 v9.3, SVE/SVE2, operação little-endian do lado Arm e direção SystemReady. A consequência pretendida é preciosa: distribuições e binários Arm “de prateleira” teriam muito menos motivo para perguntar “que bicho é este?”. A própria NVIDIA construiu Grace mirando SBSA/SystemReady porque padrões reduzem o número de adaptações especiais que software precisa carregar.

Em linguagem de sala verde: SystemReady é a diferença entre receber um fonte COBOL e torcer para que compile, ou receber o fonte mais o padrão de dataset, o JCL, as PROCs, os parâmetros e a documentação de instalação. O primeiro funciona numa demo. O segundo tem chance de sobreviver à produção.

4. “Mas a GPU é PCIe; não é só encaixar?”

Não. E aqui o Agente J recolhe delicadamente a chave de fenda da mão do Igor.

PCIe é uma interconexão, não um contrato completo de convivência. A GPU precisa ser enumerada pelo sistema, expor regiões de memória mapeada (MMIO/BARs), gerar interrupções, ser reinicializada após falha, conversar com o driver e receber energia e refrigeração adequadas. O driver precisa enxergar topologia correta, páginas de memória, acesso DMA, recursos de virtualização e mecanismos de erro.

E uma GPU não fica esperando a CPU carregar cada byte como um garçom levando café de colher em colher. Ela usa DMA — Direct Memory Access. Simplificando, depois de autorizada, transfere dados diretamente entre sua memória e a memória do host. Isso é essencial para desempenho: modelos, tensores e lotes de inferência seriam ridiculamente lentos se cada movimento tivesse de passar pela CPU como um MOVE de bilhões de bytes.

No notebook de Igor, um driver malcomportado pode congelar a tela e produzir uma noite de palavrões. Em um LinuxONE, a máquina hospeda muitos clientes lógicos, com isolamento e disponibilidade que não podem depender de boa vontade de uma placa. Aí entra a IOMMU.

5. IOMMU: o segurança que não deixa a GPU passear pelo prédio

IOMMU significa, em essência, unidade que traduz e controla endereços de memória usados por dispositivos de I/O. Pense nela como o segurança de um edifício bancário. A GPU do LPAR A recebeu autorização para entrar na sala A-17; isso não lhe dá licença para testar todas as portas do corredor, muito menos alcançar a memória do LPAR B ou do ambiente de gestão.

Uma configuração segura precisa associar dispositivo, função virtual, LPAR e faixas de memória de maneira estrita. O driver pede uma operação; hardware e firmware garantem que o dispositivo veja apenas o que lhe foi atribuído. A ideia se parece com RACF: autenticar o usuário é apenas o começo; é a autorização de cada recurso que impede o desastre.

Mas atenção: “há IOMMU” não é uma frase mágica. Drivers NVIDIA têm requisitos e particularidades conforme GPU, kernel, topologia PCIe e virtualização. Há recursos de alta performance, como comunicação direta entre GPU e NIC, que podem depender de decisões de ACS, peer-to-peer e posicionamento físico. Em outras palavras: a placa pode funcionar para inferência simples e ainda não estar pronta para cada truque de HPC, NVLink ou multi-GPU.

6. LPAR, z/VM e a diferença entre dividir e bagunçar

Um LPAR é uma partição lógica: uma máquina dentro da máquina, separada por hardware e firmware. Para o iniciante, compare-o a uma região CICS muito séria, com seu próprio universo operacional — só que o isolamento não é mera convenção de software.

O caminho inicial mais sensato seria algo parecido com isto:

1. A IBM certifica um modelo específico de GPU e o respectivo drawer PCIe.

2. A HMC/firmware atribui a função física ou virtual a uma LPAR Arm Linux.

3. Esse Linux vê um dispositivo PCIe compatível, carrega driver NVIDIA Arm64 e o CUDA runtime.

4. O aplicativo usa a GPU; o IOMMU restringe o DMA à memória autorizada.

5. Telemetria, manutenção, falhas e troca de peça entram no modelo operacional IBM.

O primeiro alvo não precisa ser compartilhar uma placa com trinta tenants. Pass-through para uma LPAR, bem cercado, já seria uma vitória enorme. Depois vêm os chefes de fase: MIG, vGPU, SR-IOV, cobrança, reset seletivo, migração, isolamento multi-tenant e recuperação automática.

7. Spyre: o precedente que ajuda, sem virar atalho enganoso

A IBM já vende o Spyre Accelerator para z17 e LinuxONE Emperor 5. É uma placa PCIe orientada a inferência e fine-tuning, com runtime, driver, firmware e integração de software próprios. A solução suporta até 48 placas em sistemas Z/LinuxONE e foi desenhada com appliances de suporte, funções virtuais, monitoramento e redundância de caminhos.

Isso importa porque prova uma coisa concreta: IBM não está começando agora a discutir “como colocar um acelerador poderoso, que faz DMA, num mainframe particionado sem transformar o equipamento numa lan house cósmica”. Ela já tem práticas para atribuição, saúde do dispositivo, tolerância a falha e operação.

Mas Spyre não é uma GPU NVIDIA pintada de azul. Ele é uma solução vertical: IBM controla hardware, firmware, compilador, runtime e o suporte. CUDA traria outro ecossistema, outra cadência de drivers e outra responsabilidade dividida. Spyre diminui o risco de integração; não elimina a negociação com NVIDIA.

8. Telum, Spyre e CUDA não são três nomes para a mesma coisa

Tecnologia	Onde brilha	Exemplo
Telum	Inferência muito próxima da transação	Pontuar fraude durante a autorização
Spyre	IA empresarial integrada e eficiente	Servir modelos e fine-tuning controlado
GPU NVIDIA/CUDA	Ecossistema amplo e computação acelerada	PyTorch, visão, LLMs, analytics e bibliotecas CUDA

O desenho vencedor não é substituir um pelo outro. É usar cada peça onde tem vocação.

Uma transação chega pelo CICS. O programa COBOL executa regras, chama Db2 e precisa decidir agora: aprovar, bloquear ou pedir segundo fator. Telum pode atender a inferência ultrarrápida. Um serviço Arm Linux pode, assíncronamente ou numa etapa apropriada, executar análise mais pesada em CUDA: enriquecer evento, correlacionar fraude, gerar explicação para analista, fazer busca vetorial, analisar imagens de documento ou retreinar um modelo.

O COBOL não precisa aprender CUDA para participar. Ele precisa aprender a pedir serviço de forma confiável: API, MQ, eventos, timeouts, idempotência, commit e rollback. O padawan que entende isso não vira passageiro do futuro; vira o adulto na sala quando alguém propõe chamar um modelo de 70 bilhões de parâmetros no meio de uma transação de 80 milissegundos.

Easter egg #2: o Agente J proibiu CALL 'CHATGPT' dentro do caminho crítico. Igor perguntou se ao menos poderia fazer um GOTO 9999 para o modelo. O Agente K desligou o monitor.

9. O inimigo físico: potência, calor e topologia

É tentador imaginar oito B200 surgindo de um drawer como alienígenas de um ovo. Só que uma GPU de datacenter de ponta pode consumir centenas de watts; sistemas HGX/NVSwitch exigem potência, refrigeração, espaço e rede próprios. NVLink não é “PCIe com café forte”.

Portanto, mesmo que CUDA se torne viável, o primeiro produto provável seria uma GPU PCIe específica e homologada para inferência ou aceleração selecionada, entregue a uma LPAR Arm. Um superpod para treinar modelo de fronteira provavelmente continuará sendo infraestrutura dedicada, conectada ao Z/LinuxONE por rede rápida e governada como outro domínio.

Mainframe não precisa vencer um DGX no campeonato errado. O valor está em reduzir a distância entre dado crítico, transação, segurança e capacidade de IA — sem copiar meio banco para uma plataforma externa só para fazer uma pergunta ao modelo.

10. Roteiro prático para o programador COBOL iniciante

Você não precisa comprar uma GPU nem decorar registradores Arm amanhã. Faça esta trilha:

1. Domine transação. Entenda CICS, Db2, VSAM, unidade de trabalho, syncpoint, COMMIT e ROLLBACK. IA sem integridade transacional é Igor vendendo PIX por e-mail.

2. Aprenda a fronteira. Veja JSON, HTTP, APIs REST, MQ e eventos. Seu COBOL continuará sendo o coração de muitos processos; ele precisa conversar sem acoplamento burro.

3. Conheça Linux e containers. Não para abandonar Z, mas para entender onde os serviços Arm e IA vão viver. Um container não é uma LPAR; ambos isolam, mas em níveis diferentes.

4. Entenda os quatro D’s. Dados, DMA, dispositivos e dependências. Pergunte sempre: onde o dado nasce, quem pode movê-lo, quem o enxerga e como o processo se recupera?

5. Aprenda observabilidade. Latência, throughput, erro, saturação, logs e rastreamento. “A IA ficou lenta” não é diagnóstico; é o equivalente moderno a “deu ABEND”.

6. Pense em governança. Modelo pode errar, vazar, enviesar e mudar. Dados bancários ou pessoais não ganham permissão para viajar só porque a demo ficou bonita.

11. As perguntas que realmente importam agora

Quando surgirem detalhes, não pergunte primeiro “quantos teraflops?”. Pergunte:

• Qual nível de certificação SystemReady a IBM entregará?

• Quais distribuições Arm bootam sem alteração?

• Como PCIe e IOMMU aparecem para a LPAR Arm?

• Haverá GPU pass-through? Virtualização? MIG/vGPU?

• Quais modelos, drivers e versões CUDA serão homologados?

• Como são feitos reset, firmware update, diagnóstico e failover?

• Qual é a latência entre o dado em z/OS/Db2 e o serviço acelerado?

• O caso de uso justifica trazer a IA para perto, ou MQ/API para infraestrutura externa já resolve melhor?

Essas perguntas são mais maduras que “roda Doom?”. Embora, em nome da ciência, o Agente J tenha anotado a segunda numa planilha confidencial.

Epílogo — a ponte não é o destino

A IBM não entregou CUDA no mainframe em agosto de 2026. Entregou algo talvez mais estratégico: uma tentativa de tornar o próximo Z/LinuxONE um anfitrião Arm suficientemente padrão para que ecossistemas já existentes possam reconhecê-lo.

Para NVIDIA, isso pode converter um port caro e exclusivo para s390x em uma qualificação de plataforma Arm. Para IBM, é uma maneira ousada de reduzir o isolamento histórico de sua arquitetura. Para clientes, pode significar aproximar software moderno e aceleradores dos dados mais críticos sem abandonar as qualidades que fizeram o mainframe sobreviver a cada funeral prematuro anunciado desde os anos 1980.

E para nós, do COBOL, a lição é confortavelmente simples: o futuro não exige que você esqueça o que sabe. Exige que você entenda onde seu programa termina, onde o serviço começa, como o dado atravessa a fronteira e quem responde quando a GPU, o driver ou o universo resolve dar ABEND.

O Agente K guardou o Neuralyzer.

— Então não apagamos a memória do anúncio?

— Não, J. Só colocamos uma nota no rodapé: “promissor, tecnicamente difícil, comercialmente aberto e absolutamente incapaz de ser instalado pelo Igor numa sexta-feira às 17h58”.

E, por uma vez, até o RACF concordou.

---

Fontes para continuar a investigação

• IBM — anúncio do processador dual-architecture, 24 de agosto de 2026

• Arm — contexto da colaboração com IBM

• NVIDIA — Grace e padrões SBSA/SystemReady

• IBM — arquitetura operacional do Spyre Accelerator

• IBM Research — construção e software do Spyre

 

Bellacosa Mainframe experimentos reisiliencia em IBM Z

💥 APERTA O ENTER E DERRUBA O DATA CENTER: SOBREVIVA AO LAB DE RESILIÊNCIA IBM Z

🧪 Laboratório prático — do ABEND ao FAILOVER sem perder um byte

---

🎯 OBJETIVO DO LAB

Você vai simular:

• 💣 Falha de aplicação (ABEND)
• ⚙️ Restart automático (ARM)
• 🧩 Continuidade (Sysplex mental model)
• 🌍 Disaster Recovery (simulado estilo GDPS)
• 📊 Validação de RPO/RTO

👉 Resultado esperado:
Sistema continua — usuário nem percebe

---

🧠 CENÁRIO (VIDA REAL)

Você é dev COBOL em um banco:

• Batch crítico processa pagamentos
• Roda em z/OS
• Usa Db2
• Integra com CICS

💥 E claro… algo vai dar errado.

---

🧪 LAB 1 — “PROVOQUE O CAOS” (ABEND CONTROLADO)

🎯 Objetivo:

Gerar uma falha real

---

📄 Passo 1 — Programa COBOL com erro

IDENTIFICATION DIVISION.
PROGRAM-ID. LABFAIL.

DATA DIVISION.
WORKING-STORAGE SECTION.
01 WS-NUM PIC 9(3) VALUE ZEROS.
01 WS-VAL PIC 9(3).

PROCEDURE DIVISION.
    MOVE 100 TO WS-VAL
    DIVIDE WS-VAL BY WS-NUM GIVING WS-VAL
    DISPLAY 'PROCESSO FINALIZADO'
    STOP RUN.

👉 Resultado esperado:

S0C7 ou S0CB (divisão por zero)

---

💡 Comentário Bellacosa

“Se você nunca causou um ABEND de propósito… você ainda não domina o sistema.”

---

⚙️ LAB 2 — “DEIXA O SISTEMA SE VIRAR” (ARM)

🎯 Objetivo:

Simular restart automático

---

🧠 Conceito

ARM = Automatic Restart Manager

👉 Ele reinicia automaticamente o que caiu

---

📄 Passo 2 — Simulação lógica

JOB FAIL → ABEND
ARM detecta → restart automático
JOB reinicia → continua fluxo

---

🧪 Teste

1. Execute o programa com erro
2. Corrija o erro (WS-NUM ≠ 0)
3. Reexecute

👉 Agora imagine:

• ARM faria isso sozinho
• Sem operador

---

💡 Insight

“ARM é o operador que nunca dorme.”

---

🧩 LAB 3 — “NÃO PARE O SISTEMA” (MENTALIDADE SYSPLEX)

🎯 Objetivo:

Entender continuidade

---

🧠 Simulação conceitual

Imagine:

• LPAR A → falha
• LPAR B → assume

---

📄 Fluxo

Transação → LPAR A
Falha → redireciona → LPAR B
Usuário continua

---

💡 Easter Egg 🔥

“Sysplex não é cluster…
é cluster que não te deixa na mão.”

---

🌍 LAB 4 — “PERDEMOS O DATA CENTER” (DR SIMULADO)

🎯 Objetivo:

Simular desastre total

---

🧠 Cenário

• Site A caiu 💥
• Site B assume

---

📄 Exercício

1. Imagine seu sistema rodando
2. “Desligue” mentalmente o ambiente
3. Suba outro ambiente

👉 Perguntas:

• Quanto tempo levou? (RTO)
• Perdeu dados? (RPO)

---

💡 Resposta ideal

• RTO → segundos/minutos
• RPO → zero

---

🔥 Insight

“Se você precisa pensar muito no DR… ele já falhou.”

---

🧨 LAB 5 — “DESCUBRA SEU SPOF”

🎯 Objetivo:

Encontrar ponto único de falha

---

📄 Checklist

• Um único job crítico?
• Um único DB?
• Um único operador? 😅

---

💡 Easter Egg

SPOF mais comum:
👉 Interface Teclado-Cadeira

---

🤖 LAB 6 — “AUTOMA OU MORRE”

🎯 Objetivo:

Entender automação

---

📄 Cenário

Sem automação:

• detectar
• analisar
• agir

👉 minutos ou horas

---

Com automação:

• detectar
• agir

👉 segundos

---

💡 Insight brutal

“Sem automação, seu RTO é humano.”

---

🧪 LAB 7 — DR TEST (O GRANDE FINAL)

🎯 Objetivo:

Validar tudo

---

📄 Simulação

1. Derrube o “ambiente”
2. Ative backup
3. Valide sistema

---

📊 Checklist

• Sistema subiu?
• Dados íntegros?
• Tempo aceitável?

---

💡 Regra de ouro

“DR não testado = DR inexistente”

---

🧠 CONSOLIDAÇÃO FINAL

---

🔗 RELAÇÃO DOS CONCEITOS

• RAS → evita impacto
• Models → define arquitetura
• Planning → garante execução

---

💥 Fluxo completo

Falha pequena → ARM resolve
Falha média → Sysplex resolve
Desastre total → DR/GDPS resolve

---

🏁 MISSÃO FINAL DO LAB

👉 Você não está testando sistema
👉 Você está testando sobrevivência do negócio

---

🔥 FRASE FINAL

“No mainframe, o erro não é falhar…
é deixar o usuário perceber.”

 

Resiliência IBM Z – Parallel Sysplex: O Segredo que Faz Diversos Mainframes se Comportarem Como Um Só - Parte III

 

Bellacosa Mainframe fala sobre resiliencia ibm z parte III

☕ Um Café no Bellacosa Mainframe

O Holocron da Resiliência IBM Z

Parte III – Parallel Sysplex: O Segredo que Faz Diversos Mainframes se Comportarem Como Um Só

"Se existe uma tecnologia que separa o IBM Z de praticamente todas as outras plataformas do mercado, ela se chama Parallel Sysplex."

Até aqui aprendemos dois conceitos fundamentais.

Na primeira parte entendemos por que a Resiliência existe.

Na segunda conhecemos a infraestrutura física que mantém o IBM Z funcionando.

Agora chegou a hora de conhecer a tecnologia que fez o Mainframe alcançar um nível de disponibilidade praticamente incomparável.

Ela atende pelo nome de Parallel Sysplex.

É ela que permite que vários computadores IBM Z trabalhem como se fossem um único sistema gigante.

Enquanto um servidor comum normalmente representa um único ponto de processamento, um ambiente Parallel Sysplex distribui usuários, aplicações, bancos de dados e transações entre diversos sistemas, mantendo tudo sincronizado quase em tempo real.

Os conceitos desta parte abrangem Monoplex, Base Sysplex, Parallel Sysplex, Coupling Facility (CF), z/OS Workload Manager (WLM), Sysplex Failure Management (SFM), Automatic Restart Manager (ARM), Dynamic Virtual IP Address (DVIPA), Sysplex Distributor e Load Balancing Advisor (LBA).

---

Quando Um Servidor Não É Suficiente

Imagine um supermercado.

Existe apenas um caixa.

Tudo funciona perfeitamente.

Até que chegam centenas de clientes.

Forma-se uma fila enorme.

O caixa quebra.

O supermercado para.

Agora imagine dez caixas.

Se um quebrar...

Os outros continuam atendendo.

O Parallel Sysplex segue exatamente essa filosofia.

Não existe apenas um computador.

Existem vários.

Todos trabalhando juntos.

---

Monoplex

Antes de conhecer o Parallel Sysplex, precisamos entender seu oposto.

O Monoplex.

Ele representa o ambiente clássico.

Existe apenas uma imagem do z/OS.

Um único sistema operacional.

Uma única máquina executando tudo.

Para ambientes pequenos isso pode ser suficiente.

Mas existe um problema.

Se esse sistema parar...

Toda a operação para junto.

Por isso Monoplex é excelente para laboratórios, ambientes de desenvolvimento e pequenas empresas.

Não para grandes bancos.

---

Base Sysplex

O próximo passo na evolução foi o Base Sysplex.

Agora vários sistemas z/OS conseguem conversar entre si.

Compartilham algumas informações.

Cooperam em determinadas atividades.

Mas ainda não executam todas as cargas de maneira integrada.

É como vários departamentos de uma empresa que já utilizam telefone interno.

Eles conseguem conversar.

Mas ainda trabalham de forma relativamente independente.

---

Parallel Sysplex

Agora chegamos ao coração da arquitetura IBM Z.

Imagine cinco grandes mainframes.

Cada um possui:

• processadores

• memória

• discos

• aplicações

• usuários

Para um administrador seriam cinco computadores.

Mas para o usuário...

Existe apenas um.

Esse é o verdadeiro poder do Parallel Sysplex.

Os sistemas compartilham informações críticas.

Distribuem carga automaticamente.

Mantêm consistência dos dados.

E continuam funcionando mesmo quando um dos sistemas deixa de operar.

É praticamente uma orquestra.

Cada músico toca seu instrumento.

Mas o público escuta apenas uma única música.

---

Coupling Facility (CF)

Surge então uma pergunta.

Como todos esses computadores conseguem permanecer sincronizados?

A resposta está na Coupling Facility.

Ela funciona como uma enorme central de coordenação.

Ali ficam estruturas compartilhadas utilizadas por todos os membros do Sysplex.

Entre elas:

• Lock Structures

• Cache Structures

• List Structures

Sempre que dois sistemas precisam garantir que um registro não seja alterado simultaneamente...

É a Coupling Facility quem organiza essa sincronização.

Sem ela...

O Parallel Sysplex simplesmente não existiria.

---

O Grande Maestro: Workload Manager (WLM)

Imagine um aeroporto.

Centenas de aviões.

Milhares de passageiros.

Dezenas de pistas.

Tudo precisa acontecer na ordem correta.

Quem coordena isso?

A torre de controle.

No IBM Z essa torre chama-se WLM.

O Workload Manager observa continuamente:

• utilização da CPU;

• tempo de resposta;

• prioridades;

• metas de negócio;

• disponibilidade dos recursos.

Em vez de distribuir processamento igualmente...

Ele distribui processamento de forma inteligente.

O objetivo não é justiça.

É atender o negócio.

Se um sistema PIX precisa responder em menos de meio segundo...

Ele receberá prioridade sobre um relatório Batch iniciado minutos antes.

---

WLM: Pensando Como o Negócio

É aqui que muitos Padawans mudam sua forma de pensar.

Eles imaginam que CPU pertence aos programas.

Na realidade...

CPU pertence ao negócio.

O WLM decide:

"Quem precisa mais agora?"

E reorganiza todo o ambiente automaticamente.

---

Sysplex Failure Management (SFM)

Falhas acontecem.

O importante é reagir rapidamente.

O SFM monitora continuamente todos os membros do Sysplex.

Se algum deles deixar de responder...

Ele toma decisões automáticas.

Entre elas:

• isolamento;

• retirada do sistema;

• proteção da integridade dos dados;

• coordenação da recuperação.

Tudo acontece em segundos.

Muitas vezes sem qualquer intervenção humana.

---

Automatic Restart Manager (ARM)

Agora imagine outra situação.

Uma aplicação falhou.

O servidor continua funcionando.

O que fazer?

Esperar um operador?

Não.

O ARM entra em ação.

Ele identifica que determinado serviço terminou inesperadamente.

Analisa as políticas definidas.

E reinicia automaticamente aquela aplicação.

O objetivo é reduzir o tempo de indisponibilidade.

Muitas vezes o usuário nem percebe que houve uma falha.

---

Dynamic Virtual IP Address (DVIPA)

Você acessa o Internet Banking.

Digita seu usuário.

Tudo funciona.

Enquanto isso...

O servidor responsável pelo atendimento pode mudar completamente.

Você não percebe.

Isso acontece graças ao DVIPA.

O endereço IP não pertence a um computador específico.

Ele pertence ao serviço.

Se um sistema sair do ar...

Outro assume imediatamente aquele endereço lógico.

Para o cliente...

Nada mudou.

---

Sysplex Distributor

Agora imagine milhares de conexões chegando ao mesmo tempo.

Quem decide qual servidor atenderá cada usuário?

O Sysplex Distributor.

Ele distribui as conexões entre os diversos membros do Sysplex.

Evita sobrecarga.

Melhora desempenho.

Aumenta disponibilidade.

É um balanceador de carga extremamente integrado ao z/OS.

---

Load Balancing Advisor (LBA)

Mas como o Sysplex Distributor sabe qual sistema está menos ocupado?

Ele pergunta ao LBA.

O Load Balancing Advisor coleta informações fornecidas pelo WLM.

Com base nessas métricas, recomenda para onde cada nova conexão deve ser direcionada.

Não basta existir vários servidores.

É preciso enviar cada usuário ao melhor deles.

---

Um Exemplo Bancário

Imagine um banco com quatro sistemas CICS.

Durante uma manhã de pagamento de salários, milhões de clientes acessam o aplicativo.

Nesse momento:

• O WLM identifica prioridades.

• O LBA mede a carga.

• O Sysplex Distributor envia novos acessos ao sistema menos ocupado.

• A Coupling Facility mantém os dados sincronizados.

• O SFM monitora a saúde dos membros.

• Se um ambiente falhar, o ARM reinicia serviços automaticamente.

• O DVIPA garante que os clientes continuem conectados.

Para quem está usando o celular...

Nada aconteceu.

Essa é a verdadeira magia do IBM Z.

---

Por Que Isso É Importante para um Programador COBOL?

Muitos desenvolvedores acreditam que Parallel Sysplex é assunto exclusivo de Sysprog.

Não é.

Quando você escreve uma aplicação COBOL para um ambiente CICS ou Batch, ela pode ser executada simultaneamente em diversos membros do Sysplex.

Isso significa que seu programa deve:

• evitar dependências locais;

• respeitar bloqueios de dados;

• compreender concorrência;

• tratar reinicializações corretamente;

• utilizar recursos compartilhados sempre que possível.

Quanto mais o desenvolvedor entende o ambiente onde sua aplicação será executada, mais robusto será o software produzido.

---

A Filosofia do Parallel Sysplex

Existe uma frase que resume toda essa tecnologia.

"No Parallel Sysplex, o usuário nunca deveria precisar saber qual computador está atendendo sua requisição."

Essa é uma ideia poderosa.

O cliente não acessa um servidor.

Ele acessa um serviço.

O serviço continua disponível independentemente de qual computador esteja processando a solicitação naquele instante.

É essa abstração que faz do IBM Z uma referência mundial em disponibilidade.

No próximo capítulo do Holocron da Resiliência IBM Z, entraremos no universo do DFSMS, Storage, System Logger, Capacity on Demand, CBU, CUoD, OOCoD e das tecnologias que permitem expandir recursos dinamicamente e proteger dados em ambientes corporativos de missão crítica.

IBM Z Resiliência: A Engenharia Invisível que Mantém o Mundo Funcionando (E Quase Ninguém Percebe)

 

Bellacosa Mainframe e a ibm z resiliencia

☕ Um Café no Bellacosa Mainframe

IBM Z Resiliência: A Engenharia Invisível que Mantém o Mundo Funcionando (E Quase Ninguém Percebe)

"Quando tudo funciona, ninguém lembra do Sysprog. Quando tudo para... todo mundo lembra."

---

Introdução – O paradoxo da excelência

Existe uma curiosidade muito interessante sobre a profissão de System Programmer (Sysprog) e System Administrator (Sysadmin) no universo IBM Z.

Se você fizer um trabalho perfeito durante dez anos, provavelmente ninguém vai notar.

Mas basta cinco minutos de indisponibilidade para que diretores, gestores, usuários, imprensa e até clientes passem a perguntar:

"O que aconteceu com o sistema?"

Esse é o maior paradoxo da infraestrutura crítica.

Quanto melhor você trabalha...
menos visível você fica.

E justamente por isso existe um tema que deveria ser obrigatório para qualquer profissional que trabalha com IBM Z:

Resiliência.

Não Backup.

Não Disaster Recovery.

Não Alta Disponibilidade isoladamente.

Mas sim Resiliência.

São conceitos diferentes.

E entender essa diferença muda completamente a forma como um Sysprog enxerga um ambiente de missão crítica.

---

O que realmente significa Resiliência?

A maioria das pessoas responde rapidamente:

"É conseguir recuperar o sistema."

Na verdade...

Essa resposta está incompleta.

Resiliência significa:

continuar entregando o serviço mesmo quando alguma coisa está dando errado.

Perceba a diferença.

Recuperação acontece depois.

Resiliência começa antes.

Essa filosofia está presente na arquitetura IBM Z desde seus primeiros projetos.

---

O Mainframe nasceu paranoico

Essa talvez seja a primeira curiosidade da apresentação.

Os computadores distribuídos normalmente são construídos pensando em desempenho.

O IBM Z foi construído pensando em falhas.

Pode parecer estranho.

Mas faz todo sentido.

Durante décadas, bancos, governos, bolsas de valores e empresas de telecomunicações não podiam simplesmente dizer:

"Desculpe, voltamos amanhã."

Logo, toda a engenharia foi criada assumindo uma premissa:

Alguma coisa vai falhar.

A pergunta nunca foi:

"Será que vai falhar?"

A pergunta correta sempre foi:

"Quando falhar... como vamos impedir que alguém perceba?"

Essa pequena mudança de mentalidade explica praticamente toda a arquitetura IBM Z.

---

A grande diferença entre Cloud e Mainframe

Existe uma frase que gosto muito.

"Na Cloud você escala."

No IBM Z...

Você continua funcionando.

São objetivos diferentes.

Cloud normalmente resolve aumento de carga.

Mainframe resolve continuidade operacional.

Não significa que um substitui o outro.

Eles resolvem problemas diferentes.

---

RAS: o DNA invisível do IBM Z

Todo Sysprog deveria decorar três letras.

RAS.

Reliability.

Availability.

Serviceability.

Essas três palavras são provavelmente as mais importantes de toda a arquitetura IBM Z.

---

Reliability

Confiabilidade.

O hardware foi projetado para falhar menos.

Mas mais importante...

Foi projetado para detectar quando está começando a falhar.

Memórias ECC.

Processadores redundantes.

Correção automática de erros.

Diagnóstico permanente.

Enquanto outros equipamentos apenas quebram...

O IBM Z normalmente avisa antes.

---

Curiosidade

Você provavelmente já trabalhou em um ambiente onde uma memória apresentou erro.

A diferença é que no Mainframe isso muitas vezes acontece...

...sem ninguém perceber.

O hardware corrigiu sozinho.

Esse é um daqueles "superpoderes" invisíveis.

---

Availability

Disponibilidade.

Talvez o conceito mais famoso.

Mas muita gente interpreta errado.

Disponibilidade não significa:

"O servidor está ligado."

Significa:

O negócio continua funcionando.

Um servidor ligado sem processar transações...

continua indisponível.

---

Serviceability

Essa é a parte mais fascinante.

Capacidade de manutenção.

Imagine trocar um componente crítico...

sem desligar o equipamento.

Isso parece impossível para quem vem do mundo x86.

No IBM Z isso faz parte do dia a dia.

---

Easter Egg nº 1

Você sabia que existem técnicos que substituem componentes internos do IBM Z enquanto ele continua processando milhões de transações?

Parece ficção científica.

Mas acontece.

---

Resiliência começa muito antes do desastre

Um erro comum é associar resiliência apenas ao Disaster Recovery.

Na verdade...

Disaster Recovery representa apenas uma pequena parte da estratégia.

Antes dele existem dezenas de mecanismos trabalhando continuamente.

ARM.

Parallel Sysplex.

GDPS.

Storage replicado.

WLM.

SMF.

Monitoramento.

Automação.

Tudo isso forma um enorme quebra-cabeça.

---

ARM — O operador que nunca dorme

Automatic Restart Manager.

Se um serviço cai...

ele pode reiniciar automaticamente.

Sem operador.

Sem ligação telefônica.

Sem abrir chamado.

Sem drama.

---

Imagine um Batch crítico.

Ele sofre um ABEND.

Sem ARM.

Operador.

Diagnóstico.

Restart.

Tempo.

Com ARM.

Detecção.

Restart.

Continuidade.

Essa diferença pode representar minutos.

Ou milhões de reais.

---

GDPS

Aqui entramos em outro nível.

Geographically Dispersed Parallel Sysplex.

Não estamos falando apenas de aplicações.

Estamos falando de Data Centers inteiros.

Imagine:

Uma enchente.

Um incêndio.

Falha elétrica.

Ataque físico.

Mesmo assim...

o ambiente continua funcionando.

Isso é GDPS.

---

Easter Egg nº 2

A maior parte das pessoas acredita que o maior inimigo do ambiente é o hardware.

Na prática...

um dos maiores SPOFs continua sendo...

o ser humano.

---

O operador continua sendo um SPOF

Single Point of Failure.

Existe uma brincadeira famosa entre Sysprogs.

"O maior ponto único de falha fica sentado na cadeira."

Parece piada.

Mas é verdade.

Boa parte dos incidentes graves começa com:

DELETE errado.

IPL errado.

PARMLIB errada.

JCL errada.

ALTER errado.

Por isso automação é tão importante.

---

DR Test

Existe outra máxima.

DR não testado...

...não existe.

Todo mundo gosta de mostrar diagramas bonitos.

Mas quando chega o momento do teste...

descobrem que:

Scripts estão desatualizados.

Documentação não funciona.

Equipe mudou.

Dependências não foram consideradas.

E justamente por isso os DR Tests existem.

---

Curiosidade

Algumas instituições financeiras realizam simulações completas de desastre.

Literalmente desligam parte do ambiente.

Tudo controlado.

Tudo documentado.

Tudo medido.

O objetivo não é provar que funciona.

É descobrir onde ainda pode falhar.

---

RPO e RTO

Esses dois indicadores aparecem em praticamente todas as entrevistas para Sysprog.

RPO.

Quanto dado posso perder?

RTO.

Quanto tempo posso ficar parado?

São perguntas simples.

Mas extremamente difíceis de responder.

Porque dependem do negócio.

---

Um banco e um supermercado possuem o mesmo RPO?

Não.

Um PIX pode exigir praticamente zero perda.

Já outro sistema administrativo pode aceitar alguns minutos.

Tudo depende da criticidade.

---

Parallel Sysplex

Talvez a maior obra de engenharia já construída no universo dos sistemas operacionais comerciais.

Diversos sistemas.

Compartilhando recursos.

Compartilhando dados.

Compartilhando carga.

Tudo funcionando como se fosse um único computador.

Quem vem do mundo Linux costuma dizer:

"Parece um cluster."

Não.

É muito mais sofisticado.

---

Easter Egg nº 3

Existe uma brincadeira antiga entre Sysprogs.

"Parallel Sysplex é aquele cluster que não resolve discutir quem é o líder."

Quem conhece algoritmos distribuídos entende a piada.

---

O futuro da profissão

Existe uma pergunta recorrente.

"O Sysprog vai acabar?"

Minha resposta é sempre a mesma.

Não.

Mas o Sysprog que conhece apenas ISPF...

talvez tenha dificuldades.

Hoje o profissional precisa conhecer:

REST APIs.

Python.

Ansible.

Zowe.

Git.

DevOps.

Observabilidade.

OpenTelemetry.

Containers.

OpenShift.

Cloud.

Não para abandonar o Mainframe.

Mas para integrá-lo.

---

O novo Sysprog

O novo profissional mistura tradição com modernização.

Continua dominando:

JCL.

SDSF.

RACF.

SMF.

RMF.

Mas também conversa naturalmente sobre:

GitHub.

CI/CD.

VS Code.

Terraform.

Automation.

IaC.

Esse profissional será extremamente valorizado.

---

Plano de estudos sugerido

Mês 1

• Conceitos de RAS

• RPO

• RTO

• SLA

---

Mês 2

• Sysplex

• Coupling Facility

• WLM

---

Mês 3

• GDPS

• Storage

• Replicação

---

Mês 4

• ARM

• Automação

• NetView

• System Automation

---

Mês 5

• Zowe

• Python

• APIs

• Ansible

---

Mês 6

• Exercícios

• DR Test

• Laboratórios

• Simulações

---

Onde aprender mais?

Para quem realmente quer se aprofundar, eu recomendaria estudar nesta ordem:

IBM Documentation

A documentação oficial continua sendo a principal referência técnica para IBM Z, z/OS, GDPS, Parallel Sysplex, WLM e demais componentes.

IBM Redbooks

Os Redbooks são praticamente livros técnicos escritos por especialistas da IBM e clientes. Um dos mais relevantes para este tema é Getting Started with IBM Z Resiliency, além de publicações sobre Parallel Sysplex, GDPS e z/OS.

IBM TechXchange

Apresentações de arquitetos IBM, sessões técnicas, estudos de caso e demonstrações práticas.

IBM Z Xplore

Ambiente gratuito para laboratórios, permitindo explorar tecnologias IBM Z de forma prática.

IBM SkillsBuild e IBM Learning

Cursos introdutórios e avançados sobre resiliência, z/OS, System Automation, GDPS, RACF, CICS, Db2 e diversas outras áreas.

SHARE Conference

Talvez o maior evento técnico do mundo voltado ao ecossistema IBM Z. É um excelente lugar para acompanhar tendências, novidades e relatos de grandes clientes.

Comunidade

Grupos técnicos, blogs especializados, fóruns e iniciativas como o Bellacosa Mainframe ajudam a transformar conhecimento técnico em conteúdo acessível, conectando teoria, prática e experiência de campo.

---

A maior lição

Depois de mais de sessenta anos de evolução tecnológica, existe uma conclusão interessante.

O maior diferencial do IBM Z nunca foi simplesmente seu hardware.

Nunca foi apenas o z/OS.

Nunca foi apenas o COBOL.

O verdadeiro diferencial sempre foi a filosofia de engenharia.

Projetar sistemas assumindo que falhas vão acontecer.

Não para reagir ao desastre.

Mas para impedir que ele se transforme em indisponibilidade.

Essa é a essência da resiliência.

E talvez seja exatamente por isso que, enquanto tantas tecnologias surgem e desaparecem, o IBM Z continua processando a maior parte das transações financeiras do planeta.

---

☕ Reflexão Final

"Um bom Sysprog mantém o sistema funcionando. Um excelente Sysprog faz com que ninguém perceba que dezenas de falhas aconteceram durante o dia. A verdadeira excelência em resiliência não é eliminar as falhas, mas construir uma arquitetura onde elas deixam de ser um problema para o negócio."

Essa é a filosofia que torna o IBM Z muito mais do que um computador: ele é uma plataforma construída para manter empresas, governos e economias funcionando, mesmo quando o inesperado acontece.