IBM Z Resiliency : 20 Laboratórios Práticos para um Padawan COBOL

 

Bellacosa Mainframe e o laboratorio pratico em IBM Z Resiliency

☕ O Holocron da IBM Z Resiliency

Este material foi desenvolvido para ajudar o programador COBOL Padawan a compreender que, no universo IBM Z Mainframe, escrever código é apenas parte da construção de sistemas críticos. O objetivo é apresentar os conceitos de IBM Z Resiliency de forma progressiva, combinando teoria, exemplos práticos e 20 laboratórios que mostram como desenvolver aplicações mais confiáveis, disponíveis e preparadas para falhas. 

A metodologia adota uma abordagem "do básico ao avançado", na qual cada laboratório amplia os conhecimentos sobre RAS (Reliability, Availability and Serviceability), High Availability, Disaster Recovery, Parallel Sysplex, GDPS, Db2, CICS e boas práticas de desenvolvimento para ambientes corporativos.

No dia a dia, o desenvolvedor aprenderá a implementar tratamentos de erro, checkpoints, commits, rollback, logs, estratégias de retry, idempotência e recuperação automática, compreendendo como seu código influencia diretamente a continuidade dos negócios. Mais do que programar, o profissional passa a entender a infraestrutura que sustenta aplicações bancárias, governamentais e de grandes empresas. 

As boas práticas incluem escrever código limpo, tratar exceções adequadamente, monitorar desempenho, documentar processos, eliminar pontos únicos de falha, colaborar com Sysprogs e DBAs e adotar ferramentas modernas como Git, Zowe, DevOps, APIs REST e Inteligência Artificial. Dessa forma, o Padawan evolui para um desenvolvedor capaz de criar soluções resilientes, escaláveis e preparadas para os desafios do IBM Z moderno.

20 Laboratórios Práticos para um Padawan COBOL

Do "Meu Programa Funciona" até "Meu Sistema Nunca Para"

Objetivo: ensinar um desenvolvedor COBOL a pensar como um engenheiro de sistemas críticos, entendendo que escrever código é apenas uma parte da construção de aplicações resilientes no IBM Z.

---

LAB 1 — Descobrindo os Pontos Únicos de Falha (SPoF)

Objetivo

Entender por que um único componente pode derrubar um sistema inteiro.

Cenário

Você possui:

• 1 servidor

• 1 disco

• 1 banco Db2

• 1 aplicação COBOL

Desenhe toda a arquitetura.

Agora marque todos os componentes que, caso parem, derrubam o sistema.

Solução

Perceba que praticamente tudo é um SPOF.

Aprendizado

Antes de eliminar falhas, é preciso encontrá-las.

💡 Dica: faça isso também com aplicações.

---

LAB 2 — Medindo o Custo do Downtime

Objetivo

Entender por que disponibilidade vale dinheiro.

Exercício

Imagine:

• Banco realiza 15.000 transações/segundo

• Receita média R$ 0,12 por transação

Calcule perdas para:

• 1 minuto

• 10 minutos

• 1 hora

Solução

O prejuízo cresce rapidamente e ainda não inclui imagem, multas ou clientes perdidos.

💡 Truque: disponibilidade é uma decisão financeira, não apenas técnica.

---

LAB 3 — O Primeiro COMMIT

Objetivo

Entender recuperação transacional.

Exercício

Atualize 1 milhão de registros.

Versão A

Sem COMMIT.

Versão B

COMMIT a cada 5.000 registros.

Solução

Simule uma interrupção.

Qual versão reinicia mais rápido?

---

LAB 4 — Criando Checkpoints

Objetivo:

Implementar restart.

Crie:

• arquivo CHECKPOINT

• posição do último registro

Simule queda.

Continue do ponto salvo.

💡 Essa técnica é usada há décadas em grandes batchs.

---

LAB 5 — Simulando Deadlock

Utilize duas sessões Db2.

Sessão A

Atualiza CLIENTE.

Sessão B

Atualiza CONTA.

Depois inverta.

Observe:

• SQLCODE

• timeout

• deadlock

Solução

Aprenda ordem consistente de atualização.

---

LAB 6 — Tratando SQLCODE Corretamente

Crie um programa que trate:

• +100

• -803

• -911

• -913

Não apenas DISPLAY.

Faça:

• rollback

• log

• retorno correto

---

LAB 7 — Criando Logs Inteligentes

Todo programa deve registrar:

• data

• hora

• usuário

• JOBNAME

• programa

• chave

• SQLCODE

• mensagem

Depois analise o log.

Descubra o erro sem recompilar.

---

LAB 8 — O Primeiro Retry

Imagine:

Db2 indisponível por poucos segundos.

Implemente:

Tentativa 1

Espera 2 segundos

Tentativa 2

Espera 5 segundos

Tentativa 3

Depois aborte.

Essa estratégia evita falhas temporárias.

---

LAB 9 — Descobrindo Gargalos

Utilize:

• EXPLAIN

• RUNSTATS

• índices

Compare:

SELECT eficiente

vs

TABLESPACE SCAN

Descubra quanto CPU pode ser economizada.

---

LAB 10 — Idempotência

Crie um pagamento.

Execute duas vezes.

O dinheiro pode ser debitado novamente?

Se sim,

o programa não é resiliente.

---

LAB 11 — Introdução ao WLM

Converse com um Sysprog.

Pergunte:

• Service Class

• Importance

• Velocity

Descubra onde seu batch roda.

Poucos desenvolvedores conhecem isso.

---

LAB 12 — Conhecendo o Parallel Sysplex

Pesquise:

• Coupling Facility

• Data Sharing

• Sysplex Distributor

Desenhe:

LPAR A

LPAR B

LPAR C

CF

Explique como seu programa continua disponível.

---

LAB 13 — Explorando o CICS

Descubra:

O que acontece quando uma região CICS cai?

Quem reinicia?

Como outra região assume?

Pesquise:

• TOR

• AOR

• DOR

• FOR

---

LAB 14 — Simulando Recovery

Imagine:

Servidor caiu.

Liste passo a passo.

• quem liga?

• quem recupera?

• quem valida?

• quem autoriza?

Perceba quantas equipes participam.

---

LAB 15 — Conhecendo o GDPS

Estude:

Metro Mirror

Global Mirror

HyperSwap

Depois responda:

Como um banco continua funcionando após perder um datacenter inteiro?

---

LAB 16 — Health Check

Aprenda:

IBM Health Checker

Descubra:

• parâmetros incorretos

• riscos

• alertas

Muitos problemas são encontrados antes da falha.

---

LAB 17 — Observabilidade

Monte um mini dashboard.

Colete:

• CPU

• I/O

• Tempo SQL

• Tempo CICS

• Batch

Analise tendências.

Não espere a reclamação do usuário.

---

LAB 18 — Engenharia do Erro

Pegue um programa antigo.

Liste:

• IF sem ELSE

• SQLCODE ignorado

• FILE STATUS ignorado

• GO TO excessivo

• PERFORM infinito

Corrija.

Compare antes/depois.

---

LAB 19 — Arquitetura Resiliente

Desenhe uma arquitetura moderna contendo:

IBM Z

↓

Parallel Sysplex

↓

Db2 Data Sharing

↓

MQ

↓

CICS

↓

z/OS Connect

↓

API REST

↓

Aplicativo Mobile

Agora marque:

Onde existe redundância?

Onde ainda há SPOF?

---

LAB 20 — O Projeto Final do Mestre Padawan

Construa um mini sistema bancário.

Funcionalidades

✔ Cadastro

✔ Consulta

✔ Depósito

✔ Saque

✔ Transferência

Implemente:

• tratamento de erros

• rollback

• commit

• logs

• checkpoint

• restart

• retry

• validações

• auditoria

• mensagens MQ (simuladas ou documentadas)

• documentação operacional

• diagrama de arquitetura

• plano de recuperação em caso de falha

Depois responda:

• Quanto tempo o sistema leva para voltar após uma falha?

• Existe risco de perda de dados?

• Há pontos únicos de falha?

• Como o operador identifica problemas?

• Como um Sysprog ajudaria a resolver um incidente?

---

Missões Extras (XP para Padawans)

Bronze

• Aprender SDSF

• Ler SYSOUT

• Entender ABENDs comuns (S0C7, S0C4, S806)

• Navegar no ISPF

Prata

• Aprender SMF

• Conhecer RMF

• Ler EXPLAIN do Db2

• Entender WLM

Ouro

• Estudar Parallel Sysplex

• Coupling Facility

• Db2 Data Sharing

• ARM

• SFM

• IBM Health Checker

Platina

• GDPS

• Metro Mirror

• Global Mirror

• HyperSwap

• Continuous Availability

• Zero Data Loss

Mestre Jedi do Mainframe

• z/OS Connect

• APIs REST

• Git e GitHub

• Zowe CLI

• VS Code

• DevOps

• OpenTelemetry

• Observabilidade

• Ansible

• Inteligência Artificial aplicada ao COBOL

• Engenharia de Resiliência

---

Conselho Final do Mestre

Um programador COBOL iniciante acredita que seu trabalho termina quando o compilador retorna RC=0. Um profissional experiente sabe que esse é apenas o começo. A verdadeira excelência está em construir aplicações que possam ser interrompidas, reiniciadas, recuperadas, monitoradas, auditadas e evoluídas sem comprometer o negócio.

Quando você domina resiliência, deixa de ser apenas um programador de COBOL. Você se torna um engenheiro de sistemas críticos, capaz de desenvolver soluções que sustentam bancos, seguradoras, bolsas de valores e governos. Essa é a diferença entre dizer "Meu programa funciona" e afirmar com confiança "Meu sistema nunca para."

IBM Z Resiliency Como um Padawan COBOL Pode Evoluir do "Meu Programa Funciona" para "Meu Sistema Nunca Para"

 

Bellacosa Mainframe expande as ideias em IBM Z Resiliency

☕ Um Café no Bellacosa Mainframe

O Holocron da IBM Z Resiliency

Como um Padawan COBOL Pode Evoluir do "Meu Programa Funciona" para "Meu Sistema Nunca Para"

"O melhor programa COBOL não é apenas aquele que produz o resultado correto. É aquele que continua produzindo o resultado correto mesmo quando discos falham, servidores reiniciam, links caem, operadores cometem erros e o datacenter enfrenta uma crise."

---

Introdução

Quando um desenvolvedor COBOL começa sua jornada no IBM Z, normalmente sua preocupação é bastante simples:

• aprender PROCEDURE DIVISION;

• entender WORKING-STORAGE;

• fazer READ e WRITE em arquivos VSAM;

• acessar Db2;

• executar um programa via JCL;

• tratar um SQLCODE.

Tudo isso é importante.

Mas existe uma realidade muito maior que normalmente só é descoberta anos depois.

Seu programa não vive sozinho.

Ele faz parte de um enorme ecossistema composto por:

• IBM Z Hardware

• z/OS

• JES2

• WLM

• CICS

• IMS

• Db2

• MQ

• RACF

• GDPS

• Parallel Sysplex

• Storage

• Redes

• Operação

• Monitoramento

• Backup

• Disaster Recovery

Todo esse conjunto possui um único objetivo:

Nunca deixar o negócio parar.

É justamente isso que a IBM chama de Resiliency.

---

O maior equívoco do desenvolvedor iniciante

O Padawan COBOL costuma pensar:

"Meu programa compilou."

Depois:

"Funcionou no teste."

Depois:

"Funcionou em produção."

Fim da história.

Na realidade...

A história apenas começou.

Porque a pergunta correta nunca é:

"O programa funciona?"

A pergunta correta é:

"Ele continua funcionando quando alguma coisa dá errado?"

Essa mudança de mentalidade separa um programador júnior de um engenheiro de software para ambientes críticos.

---

O mundo perfeito não existe

Imagine um banco.

Às 10 horas da manhã.

Existem:

• 8 milhões de clientes conectados.

• milhares de caixas eletrônicos.

• PIX.

• cartões.

• internet banking.

• aplicativos móveis.

• APIs REST.

• Open Finance.

Nesse momento:

uma CPU apresenta defeito.

O que acontece?

Se você respondeu:

"O banco para."

Você ainda está pensando como quem programa um computador doméstico.

No IBM Z, o esperado é que ninguém perceba.

Esse é o verdadeiro significado da palavra Resiliency.

---

Resiliência não significa nunca falhar

Essa é outra confusão muito comum.

Nenhum computador é perfeito.

Discos quebram.

Memórias apresentam defeitos.

Cabos rompem.

Fontes queimam.

Operadores erram comandos.

Aplicações possuem bugs.

Até meteoros poderiam destruir um datacenter.

Resiliência significa:

Aceitar que falhas acontecerão e projetar o sistema para continuar operando apesar delas.

---

O conceito mais importante

A IBM define resiliência como:

Capacidade de fornecer os serviços necessários diante da adversidade sem impacto significativo.

Perceba um detalhe.

Ela não fala em hardware.

Ela não fala em COBOL.

Ela fala em:

Serviço.

O cliente quer sacar dinheiro.

Ele não quer saber quantas CPUs existem.

---

O iceberg invisível

Quando você executa:

EXEC SQL
SELECT SALDO
END-EXEC

Você enxerga apenas uma linha.

Por trás dela existem dezenas de componentes trabalhando juntos.

Seu programa depende de:

• compilador COBOL;

• runtime;

• Db2;

• buffer pools;

• storage;

• cache;

• canais FICON;

• discos;

• processadores;

• WLM;

• z/OS;

• JES;

• rede;

• segurança RACF.

A resiliência protege toda essa cadeia.

---

O verdadeiro custo de um downtime

Muitos iniciantes imaginam:

"Se o sistema parar por cinco minutos não faz diferença."

Na prática, cinco minutos podem significar:

• milhões de transações não realizadas;

• PIX rejeitados;

• compras canceladas;

• multas;

• perda de reputação;

• ações caindo na bolsa.

O Redbook mostra que o custo de uma interrupção vai muito além da infraestrutura. Há perdas diretas de receita, custos fixos durante a parada e impactos intangíveis, como perda de confiança dos clientes e danos à marca.

---

O famoso RAS

Quase todo Sysprog conhece esta sigla.

Reliability

Confiabilidade.

Quanto menor a chance de quebrar.

Availability

Disponibilidade.

Mesmo quebrando,

continua funcionando.

Serviceability

Facilidade para manutenção.

Trocar peças.

Atualizar firmware.

Fazer manutenção.

Sem parar o ambiente.

---

O COBOL participa da Resiliência?

Sim.

Muito mais do que parece.

Um programa COBOL mal escrito pode derrubar um ambiente inteiro.

Por exemplo:

• LOOP infinito.

• COMMIT inexistente.

• Deadlock.

• Consumo exagerado de CPU.

• SQL sem índice.

• Arquivos bloqueados.

• Storage leak.

• Falta de tratamento de exceção.

Resiliência também é responsabilidade do desenvolvedor.

---

O que um Padawan precisa aprender

Primeira fase.

Programar.

Segunda fase.

Programar corretamente.

Terceira fase.

Programar para recuperação.

Quarta fase.

Programar pensando na infraestrutura.

Quinta fase.

Programar pensando no negócio.

Essa evolução leva anos.

---

A importância do COMMIT

Imagine:

Você atualiza:

100.000 registros.

No registro 99.999 ocorre uma queda elétrica.

Sem COMMIT.

Tudo volta.

Com COMMIT periódico.

A perda é mínima.

O programa consegue reiniciar.

Esse pequeno detalhe pode economizar horas de processamento.

---

Checkpoints

Batchs gigantes normalmente possuem checkpoints.

Imagine um processamento de:

40 milhões de clientes.

No cliente 39 milhões ocorre uma falha.

Sem checkpoint.

Tudo recomeça.

Com checkpoint.

Continua do ponto salvo.

É resiliência aplicada ao desenvolvimento.

---

Idempotência

Uma palavra moderna.

Mas extremamente útil.

Se o mesmo programa executar novamente,

ele não deve:

duplicar pagamentos;

duplicar TED;

duplicar PIX;

duplicar lançamentos.

Grandes sistemas financeiros dependem disso.

---

Tratamento de exceções

Nunca escreva:

IF SQLCODE NOT = 0
    DISPLAY 'ERRO'
END-IF

Isso não resolve nada.

Um bom programa:

• registra logs;

• identifica contexto;

• faz rollback quando necessário;

• encerra de forma segura;

• permite recuperação.

---

O papel do WLM

O Workload Manager decide quem recebe prioridade.

Imagine:

• Folha de pagamento.

• PIX.

• Batch estatístico.

Quem deve receber CPU primeiro?

O WLM responde.

Seu programa faz parte dessa fila.

---

Parallel Sysplex

Talvez seja a tecnologia mais famosa do IBM Z.

Vários sistemas trabalham como se fossem um único computador.

Se um deles cair,

os demais continuam.

O usuário nem percebe.

Parece magia.

Na realidade,

é engenharia.

---

GDPS

Geographically Dispersed Parallel Sysplex.

Imagine:

São Paulo inteiro sem energia.

Outro datacenter assume.

Essa é a ideia.

Algumas empresas conseguem continuar operando mesmo após perder completamente um site.

---

Zero Data Loss

Um conceito impressionante.

Perder:

zero.

Nem um registro.

Nem um pagamento.

Nem um PIX.

Nem um centavo.

Nem um byte.

É um objetivo que depende de arquiteturas de replicação síncrona e soluções como GDPS e tecnologias de espelhamento de armazenamento.

---

Curiosidade

Muitos bancos realizam manutenção durante o horário comercial.

Você nem percebe.

Enquanto um sistema recebe manutenção,

outro assume.

Depois ocorre o inverso.

Esse processo chama-se:

Rolling Maintenance.

---

Easter Egg nº 1

O maior inimigo da disponibilidade nem sempre é o hardware.

É o operador.

Estudos da indústria mostram que erros humanos continuam entre as causas mais frequentes de indisponibilidade.

Por isso existem:

• automação;

• procedimentos;

• scripts;

• validações;

• System Automation;

• Runbooks.

---

Easter Egg nº 2

Os engenheiros IBM costumam perseguir um objetivo curioso.

Eliminar o que chamam de:

Single Point of Failure

Qualquer componente único que possa derrubar todo o ambiente.

Vale para:

• CPU;

• disco;

• switch;

• cabo;

• storage;

• operador;

• documentação.

Até pessoas podem ser um "Single Point of Failure" quando apenas um especialista conhece um procedimento crítico.

---

Easter Egg nº 3

Um COBOL pode ser resiliente mesmo sendo escrito há 40 anos.

Se:

• estiver bem estruturado;

• tratar exceções;

• possuir restart;

• possuir checkpoints;

• respeitar transações;

ele continua extremamente moderno.

---

O que estudar depois deste curso

Depois de entender Resiliency, o caminho natural é aprofundar-se na própria stack IBM Z.

Infraestrutura

• IBM Z Hardware

• CPC

• LPAR

• PR/SM

• HMC

Sistema Operacional

• z/OS

• JES2

• SDSF

• WLM

• SMF

• RMF

Armazenamento

• DFSMS

• DFSMShsm

• Copy Services

• Metro Mirror

• Global Mirror

Redes

• VTAM

• TCP/IP

• DVIPA

• Sysplex Distributor

Middleware

• CICS

• IMS

• Db2

• MQ

Alta Disponibilidade

• Parallel Sysplex

• Coupling Facility

• Data Sharing

• GDPS

Operação

• IBM System Automation

• OMEGAMON

• IBM Z Operations Analytics

---

As habilidades modernas do desenvolvedor COBOL

O mercado mudou.

Hoje um desenvolvedor COBOL pode agregar muito mais valor quando conhece:

• APIs REST com z/OS Connect;

• JSON e XML;

• Git;

• GitHub;

• DevOps;

• CI/CD;

• testes automatizados;

• observabilidade;

• OpenTelemetry;

• containers para ferramentas de apoio;

• Ansible;

• Zowe;

• VS Code;

• automação operacional;

• inteligência artificial aplicada ao desenvolvimento.

---

Os perigos de ignorar a resiliência

Quem pensa apenas em "fazer funcionar" costuma criar sistemas frágeis.

Os principais riscos são:

• perda de dados;

• duplicidade de transações;

• indisponibilidade prolongada;

• degradação de desempenho;

• dificuldade de recuperação;

• manutenção cara;

• dependência de especialistas;

• aumento do risco operacional.

Em ambientes financeiros, esses problemas podem gerar prejuízos milionários.

---

Como evoluir de Padawan para Mestre

Uma evolução sólida pode seguir esta trilha:

Nível 1 — Fundamentos

• COBOL

• JCL

• VSAM

• Db2

• CICS

Nível 2 — Sistema

• z/OS

• SDSF

• JES2

• TSO/ISPF

• WLM

Nível 3 — Arquitetura

• Parallel Sysplex

• Coupling Facility

• Data Sharing

• ARM

• SFM

Nível 4 — Continuidade de Negócios

• RAS

• HA

• DR

• RTO

• RPO

• GDPS

Nível 5 — Modernização

• APIs

• z/OS Connect

• DevOps

• Observabilidade

• IA

• Automação

---

A maior lição do IBM Z Resiliency

Depois de estudar esse tema, muitos desenvolvedores descobrem que escrever código representa apenas uma pequena parte do trabalho. Um programa COBOL faz sentido somente quando está inserido em uma arquitetura capaz de sobreviver a falhas, manter dados íntegros e continuar entregando serviços ao negócio.

É por isso que os profissionais mais valorizados no ecossistema IBM Z não são apenas excelentes programadores. Eles entendem infraestrutura, operação, banco de dados, middleware, redes, automação e continuidade de negócios. Eles sabem que um COMMIT bem posicionado, um tratamento adequado de exceções ou um checkpoint inteligente podem ter tanto impacto quanto uma nova funcionalidade.

No fim da jornada, o verdadeiro Mestre do IBM Z não é aquele que escreve o código mais sofisticado. É aquele que projeta soluções que continuam funcionando quando o inesperado acontece. Essa é a essência da IBM Z Resiliency: construir sistemas preparados para enfrentar falhas sem interromper aquilo que realmente importa — o negócio de milhões de pessoas.

🧠 Bellacosa Mainframe — “z/OS 2.5: o monstro renascido no trono do ferro” ⚙️

 

🧠 Bellacosa Mainframe — “z/OS 2.5: o monstro renascido no trono do ferro” ⚙️
📅 Lançado em setembro de 2021 — o z/OS 2.5 é o início de uma nova era digital no coração de aço da IBM.

---

🧩 Um novo capítulo na dinastia z/OS

Quando o z/OS 2.5 chegou, ele não foi apenas “mais uma versão”.
Foi o recomeço do império z, uma resposta direta da IBM à revolução da IA, containers, APIs e automação que tomou o mundo corporativo.
Enquanto muitos achavam que o mainframe ficaria preso no COBOL e JCL, o z/OS 2.5 mostrou que o “dinossauro” aprendeu a pilotar drones. 🦖🚁

---

💾 Lançamento e base de hardware

• 📆 Lançado: setembro de 2021

• ⚙️ Hardware compatível: IBM z15 e z16

• 🧬 Firmware: PR/SM versão 6.0+

• 🧠 Suporte a memória: até 16 TB de memória real por LPAR

• 🧮 CPUs lógicas: até 2.000 (em sistemas de alta escala com z16)

O PR/SM (Processor Resource/System Manager) também evoluiu — agora com gerenciamento mais inteligente de créditos de CPU, priorizando workloads críticos (como CICS, DB2, e z/OSMF) em ambientes mistos de LPARs, especialmente sob WLM Intelligent Resource Director (IRD).

💡 Curiosidade Bellacosa: o PR/SM é o “prefeito das LPARs”. Decide quem fala, quem come e quem dorme no processador. E o z/OS 2.5 trouxe um prefeito com IA nos bastidores.

---

🧠 Avanços técnicos e memória expandida

O z/OS 2.5 trouxe um novo modelo de gerenciamento de endereçamento 64-bit estendido — o “2G-Above Bar Expansion”.
Isso significa que sistemas como DB2 v12+, IMS, e até CICS TS 5.6 podem acessar grandes quantidades de memória acima da região tradicional, reduzindo swapping e melhorando o throughput.

• Novo limite de memória de usuário: até 8 TB por address space

• Melhorias na CSA e SQA (áreas comuns): reorganizadas para eficiência em virtualização

• Nova LPA dinâmica: permite carregar módulos sem IPL em ambientes contínuos

---

⚙️ Softwares internos e subsistemas

O z/OS 2.5 veio afinadíssimo com o ecossistema z:

Componente	Versão recomendada	Novidades
CICS TS	5.6	APIs REST nativas, suporte OpenAPI 3.0
DB2	v12	Autotuning e Machine Learning Indexing
IMS	15.2	Suporte a Java e integração z/OS Connect EE
MQ	9.2	Mensageria híbrida com Kafka bridge
z/OSMF	2.5 built-in	Instalação simplificada via workflows
RACF	integrado	Suporte a autenticação multifator (MFA)

E claro, o z/OS Container Extensions (zCX) ganhou musculatura: agora executa containers Linux on z diretamente no LPAR do z/OS, sem precisar de z/VM.
Ou seja: Docker rodando dentro do mainframe — uma ironia deliciosa. 🐳💀

---

🧬 Instruções de máquina e arquitetura

O z/OS 2.5 se apoia nas novas instruções do z15 e z16, especialmente para segurança e compressão:

• AI acceleration com Matrix Multiply Assist

• Crypto Express7S com AES-256-GCM nativo

• zEDC v2.0 para compressão inline com até 40% menos overhead

• Guarded Storage Facility (GSF) para proteção contra buffer overflows

• Improved branch prediction em workloads Java e Python

Essas instruções são automaticamente exploradas pelo compilador Enterprise COBOL 6.4+ e pelo Java 11 do z/OS SDK, o que significa menos CPU, mais TPS e um sorriso de WLM feliz. 😎

---

🖥️ Interface e automação

O z/OSMF 2.5 é o verdadeiro painel de controle do futuro.
Ele transformou tarefas antes manuais (como definir SYS1.PARMLIB, atualizar PROCLIBs ou revisar SDSF) em workflows web interativos, permitindo que novos sysprogs e devops trabalhem sem TSO.

Além disso, o Ansible for z/OS ganhou integração oficial — é possível provisionar datasets, rodar jobs, configurar CICS e até fazer IPL via playbooks YAML.
O que antes levava horas de JCL, agora é automatizado com um simples “ansible-playbook zos.yaml”.

---

📊 Créditos de CPU e WLM inteligente

O z/OS 2.5 aprimorou a política de CPU credits e WLM dispatching, usando o SMF 120.15 para métricas mais refinadas de workloads containerizados.
O sistema reconhece quando uma workload está em zCX, em CICS ou em Java, e redistribui créditos automaticamente com base em prioridades e metas de SLA.

🧩 Easter Egg Bellacosa: o código interno que gerencia IRD no PR/SM ainda mantém nomes de planetas — “Venus”, “Mars” e “Saturn” — usados como labels em testes de laboratório da IBM desde os tempos do System/370. 🌌

---

🧵 Curiosidades e bastidores

• O z/OS 2.5 foi o último com suporte a IPL tradicional em modo 31-bit puro — uma era que se encerra com elegância.

• O Time-Travel Debugger (IBM Debug for z/OS) permite voltar no tempo durante o debugging, literalmente “rebobinando” a execução de um COBOL.

• O suporte à linguagem Python foi oficializado via IBM Open Enterprise SDK, abrindo caminho para automações híbridas.

• E o z/OS Cloud Broker conecta o mainframe direto ao OpenShift e Kubernetes. É o z/OS rodando em harmonia com o caos cloud. ☁️⚡

---

🔚 Conclusão — z/OS 2.5: o mainframe acordou de novo

O z/OS 2.5 não é apenas um upgrade — é um reboot arquitetural.
É o mainframe olhando para o futuro, conversando com APIs REST, rodando containers, automatizando via Ansible e protegendo dados com criptografia quântica pronta para o amanhã.

O aço agora tem alma digital.
E o Bellacosa Mainframe aplaude de pé. 👏💙

A Sociedade do Mainframe — A Primeira Jornada rumo ao Reino da Alta Disponibilidade : Descobre que o Verdadeiro Poder Não Está em Evitar Falhas, Mas em Continuar Funcionando Apesar Delas

 

Bellacosa Mainframe e a sociedade do mainframe rumo a alta disponibilidade

☕ Um Café no Bellacosa Mainframe

A Sociedade do Mainframe — A Primeira Jornada rumo ao Reino da Alta Disponibilidade

Quando um Programador COBOL Padawan Descobre que o Verdadeiro Poder Não Está em Evitar Falhas, Mas em Continuar Funcionando Apesar Delas

"Nem todos os sistemas que caem estão perdidos. Alguns apenas aguardam que outra região assuma sua missão."

---

Introdução

Existe um momento na carreira de todo programador COBOL em que ele deixa de pensar apenas no programa que escreveu.

Até então, seu universo era relativamente pequeno.

Recebia uma especificação.

Criava um programa COBOL.

Compilava.

Executava.

Corrigia alguns ABENDs.

Consultava um VSAM.

Executava um SQL.

Colocava em produção.

Fim da história.

Mas então surge uma pergunta aparentemente simples.

"O que acontece quando o programa está funcionando e o servidor onde ele está executando simplesmente desaparece?"

Silêncio.

Essa pergunta muda completamente a forma de enxergar um sistema corporativo.

É exatamente neste ponto que começa nossa jornada.

Como em O Senhor dos Anéis – A Sociedade do Anel, descobrimos que existe um mundo muito maior além do Condado.

O COBOL é apenas Frodo.

O CICS é Rivendell.

O z/OS é a Terra Média.

E a Alta Disponibilidade é a Sociedade que mantém o Um Anel longe das forças do caos.

Hoje atravessaremos essa Terra Média tecnológica.

Pegue seu café.

Afivele o cinto do terminal 3270.

Nossa aventura apenas começou.

---

Capítulo I

O Condado: Onde Todo Programador COBOL Começa

Todo iniciante acredita que um sistema funciona assim:

Cliente

↓

Programa COBOL

↓

Banco de Dados

↓

Resposta

Simples.

Bonito.

Organizado.

Funciona perfeitamente...

até acontecer a primeira falha.

Imagine um banco.

São nove horas da manhã.

Milhares de pessoas fazem PIX.

Empresas pagam fornecedores.

Cartões de crédito autorizam compras.

Caixas eletrônicos funcionam.

Aplicativos móveis recebem milhões de acessos.

De repente...

A máquina que executa aquele programa simplesmente para.

Não trava.

Não fica lenta.

Ela desaparece.

Agora faça uma pergunta.

Quanto dinheiro um banco perde por minuto parado?

Algumas instituições estimam milhões de reais por hora.

Em bolsas de valores...

alguns segundos podem representar perdas gigantescas.

Foi por isso que nasceu um dos conceitos mais importantes da computação corporativa:

High Availability.

---

Capítulo II

Mordor Existe

No universo da fantasia existe Sauron.

No Mainframe existem as falhas.

Elas sempre existirão.

Não importa a qualidade do hardware.

Não importa quanto custa o servidor.

Tudo pode falhar.

Discos quebram.

Fontes queimam.

Cabos são desconectados.

Switches morrem.

Processadores apresentam defeitos.

LPARs reiniciam.

Operadores cometem erros.

Programadores também.

O objetivo nunca foi impedir isso.

O objetivo sempre foi impedir que o cliente perceba.

Essa mudança de mentalidade separa iniciantes dos arquitetos de sistemas.

---

Capítulo III

A Sociedade do Mainframe

Assim como Frodo jamais chegaria sozinho a Mordor, um ambiente CICS nunca depende de um único componente.

A Sociedade é formada por personagens extraordinários.

Frodo — O Programa COBOL

É quem realmente executa a missão.

Ele processa contas.

Calcula juros.

Autoriza cartões.

Move dinheiro.

Mas sozinho ele não sobreviveria.

---

Gandalf — O WLM

O Workload Manager é um verdadeiro mago.

Ele conhece toda a Terra Média do z/OS.

Sabe onde há CPU disponível.

Onde existe memória.

Onde há menos filas.

Onde o tempo de resposta está melhor.

Enquanto os usuários apenas enviam solicitações...

Gandalf decide para onde cada missão será enviada.

Sem ele...

o reino mergulharia no caos.

---

Aragorn — O CICS

O verdadeiro líder da batalha.

Cada Região CICS representa um comandante.

Ela recebe transações.

Executa programas.

Coordena recursos.

Mantém a ordem.

Mas, assim como Aragorn, nenhuma região governa sozinha.

Existem várias espalhadas pelo reino.

---

Legolas — O Monitoramento

Legolas enxerga longe.

Muito longe.

Ele percebe um problema antes dos outros.

O monitoramento faz exatamente isso.

Analisa:

• CPU

• Storage

• SOS

• Locks

• SQL lento

• Esperas

• MQ

• Threads

• Tempo de resposta

Antes mesmo dos usuários reclamarem.

---

Gimli — O Hardware IBM Z

Robusto.

Pesado.

Quase indestrutível.

Mas nem Gimli é imortal.

Até o melhor hardware pode falhar.

Por isso existem outros anões prontos para assumir.

---

Sam — O Db2

Frodo jamais teria chegado ao fim sem Sam.

O COBOL também não.

O Db2 acompanha todas as transações.

Protege os dados.

Mantém consistência.

Recupera informações.

Suporta milhões de acessos simultâneos.

---

Capítulo IV

O Portal de Rivendell

Observe o caminho percorrido por uma simples transação.

Usuário

↓

Aplicativo

↓

Rede

↓

Load Balancer

↓

WLM

↓

Região CICS

↓

COBOL

↓

DB2

↓

Resposta

O usuário nunca conversa diretamente com o COBOL.

Há diversos guardiões protegendo o caminho.

Isso é proposital.

Cada camada adiciona inteligência.

Cada camada aumenta a disponibilidade.

Cada camada reduz riscos.

---

Capítulo V

O Conselho de Elrond

Imagine que existem quatro Regiões CICS.

CICSA

CICSB

CICSC

CICSD

Durante um dia comum...

todas trabalham juntas.

Cada uma atende milhares de usuários.

Agora imagine que CICSB falhou.

O que acontece?

Nada.

Ou melhor...

quase nada.

O WLM simplesmente deixa de enviar novas transações para ela.

As demais assumem a carga.

Os clientes continuam utilizando o sistema.

É exatamente como retirar Boromir da Sociedade.

A missão continua.

---

Capítulo VI

O Um Anel da Alta Disponibilidade

Existe um erro comum entre iniciantes.

Pensar que redundância significa desperdício.

Não.

Redundância significa sobrevivência.

Ter apenas uma região é barato.

Mas extremamente perigoso.

Ter quatro regiões parece mais caro.

Até o dia da primeira falha.

Nesse instante...

descobre-se que o investimento pagou décadas de tranquilidade.

---

Capítulo VII

O Caminho para Mordor

Toda transação percorre diversos desafios.

Primeiro o balanceamento.

Depois o processamento.

Depois acesso ao banco.

Depois gravação em logs.

Depois confirmação.

Se qualquer etapa falhar...

existem mecanismos de recuperação.

Algumas transações reiniciam.

Outras utilizam Syncpoint.

Outras fazem rollback.

Outras repetem a operação.

Tudo pensado para preservar integridade.

---

Capítulo VIII

O Olho de Sauron Nunca Dorme

Monitoramento contínuo.

Esse é um conceito que muitos desenvolvedores ignoram.

Eles imaginam que basta a região responder.

Mas responder não significa estar saudável.

Uma região pode:

• consumir 100% da CPU;

• estar sem armazenamento (SOS);

• aguardar locks;

• enfrentar lentidão no Db2;

• acumular filas no MQ.

Ela ainda responde.

Mas lentamente.

O monitoramento detecta esses sinais antes que o usuário perceba.

Ferramentas como OMEGAMON, RMF, SMF, CICS Explorer e soluções de observabilidade modernas funcionam como os sentinelas de Gondor: vigiam continuamente o horizonte em busca de qualquer ameaça.

---

Capítulo IX

A Fortaleza Invisível: Shared Db2 e VSAM

Uma pergunta importante surge.

Se existem várias regiões...

como todas enxergam os mesmos dados?

A resposta está no compartilhamento.

O Db2, utilizando Data Sharing, permite que diferentes regiões CICS acessem o mesmo conjunto de informações com consistência.

O VSAM, quando configurado com Record Level Sharing (RLS), também possibilita acesso concorrente seguro.

Imagine uma conta bancária.

Saldo:

R$ 1.000

Se uma região enxergasse R$ 1.000 e outra R$ 950, o caos seria inevitável.

É por isso que a consistência dos dados é tão importante quanto a disponibilidade da aplicação.

---

Capítulo X

O Reino Além do Reino: Parallel Sysplex

Aqui chegamos ao verdadeiro ápice da engenharia IBM.

O Parallel Sysplex.

Imagine várias fortalezas espalhadas pela Terra Média.

Cada uma possui seus soldados.

Cada uma possui seus recursos.

Entretanto...

todas trabalham como se fossem uma única cidade.

É exatamente isso que acontece.

Diversos sistemas IBM Z compartilham recursos através do Coupling Facility, coordenando locks, caches e estruturas compartilhadas.

O resultado?

Escalabilidade quase linear.

Disponibilidade extraordinária.

Capacidade de crescimento contínuo.

É uma das arquiteturas mais elegantes já construídas na história da computação.

---

Capítulo XI

Alta Disponibilidade não é Disaster Recovery

Esse tema costuma aparecer em entrevistas técnicas.

E muitos candidatos confundem os conceitos.

High Availability (HA) trata de falhas locais.

Uma região caiu?

Outra assume.

Um processador apresentou defeito?

Outro continua executando.

Já Disaster Recovery (DR) lida com eventos muito maiores.

Incêndios.

Enchentes.

Falhas elétricas generalizadas.

Ataques físicos.

Perda completa de um Data Center.

Nesses casos, outro ambiente — muitas vezes localizado em outra cidade ou país — assume as operações.

Uma boa analogia é imaginar um castelo.

Se uma torre desmorona, os soldados continuam defendendo a fortaleza.

Isso é HA.

Mas se o castelo inteiro é destruído por um dragão...

é necessário recuar para outra fortaleza.

Isso é DR.

---

Curiosidades que Pouca Gente Conhece

🏰 Curiosidade 1

Grandes bancos frequentemente operam com dezenas de Regiões CICS simultaneamente.

---

🏰 Curiosidade 2

Alguns ambientes processam dezenas de milhares de transações por segundo.

---

🏰 Curiosidade 3

É comum realizar manutenção em hardware IBM Z sem desligar aplicações críticas.

---

🏰 Curiosidade 4

Muitos clientes nunca percebem que uma região inteira foi reiniciada durante o expediente.

---

🏰 Curiosidade 5

Grande parte da confiabilidade do Mainframe vem da combinação entre hardware, sistema operacional, middleware e processos operacionais — não de um único componente.

---

Passo a Passo para o Padawan COBOL Entender HA

Se você está começando agora, siga esta trilha de estudos:

1. Aprenda a arquitetura básica do z/OS.

2. Entenda o papel do CICS.

3. Estude a diferença entre TOR, AOR e FOR.

4. Aprenda como funciona o WLM.

5. Conheça o Db2 Data Sharing.

6. Estude VSAM RLS.

7. Entenda Syncpoint e Commit.

8. Aprenda conceitos de rollback e recuperação.

9. Descubra como funciona o Parallel Sysplex.

10. Explore ferramentas de monitoramento como RMF, SMF e OMEGAMON.

Essa sequência fará muito mais sentido do que tentar estudar todos os componentes isoladamente.

---

Easter Egg Bellacosa Mainframe ☕

Existe uma antiga lenda entre os Sysprogs.

Ela diz que, em algum lugar escondido dentro do Coupling Facility, existe um Palantír Digital.

Apenas os arquitetos mais experientes conseguem enxergar através dele o fluxo de todas as transações da Terra Média do Mainframe. Enquanto um programador iniciante vê apenas um programa COBOL executando um EXEC CICS LINK, o velho mago observa regiões inteiras assumindo cargas, WLM redistribuindo trabalho, Db2 sincronizando dados e o Sysplex mantendo o reino unido.

Dizem ainda que Gandalf jamais utilizou magia para derrotar Sauron.

Na verdade...

ele apenas configurou corretamente o WLM, distribuiu as transações entre múltiplas regiões CICS e deixou que a Alta Disponibilidade fizesse o restante.

Claro... nenhum manual da IBM confirma essa história.

Mas todo bom Sysprog sorri discretamente quando alguém menciona que "o sistema simplesmente não pode parar".

---

Conclusão

Assim como A Sociedade do Anel não era formada por heróis isolados, a Alta Disponibilidade em um ambiente CICS também é resultado da cooperação entre diversos componentes. O COBOL executa a lógica de negócio, o CICS coordena as transações, o WLM distribui inteligentemente a carga, o Db2 e o VSAM garantem a consistência dos dados, o monitoramento identifica problemas antes que eles afetem os usuários e o Parallel Sysplex transforma múltiplos sistemas em uma infraestrutura única e resiliente.

Para o programador COBOL iniciante, compreender esses conceitos representa uma mudança profunda de perspectiva. Você deixa de enxergar apenas linhas de código e passa a entender o ecossistema que mantém bancos, companhias aéreas, seguradoras, bolsas de valores e governos funcionando ininterruptamente.

No fim da jornada, a maior lição não é aprender a escrever um programa perfeito, mas compreender que, em computação corporativa, a verdadeira excelência está em construir sistemas capazes de continuar servindo milhões de pessoas mesmo quando partes da infraestrutura falham. Esse é o espírito do Mainframe: transformar redundância em confiança, engenharia em continuidade de negócios e tecnologia em um serviço tão confiável que a maioria das pessoas sequer percebe que ele existe.

Porque, como diria um velho mago da Terra Média adaptado ao universo IBM Z:

"Um grande sistema não é aquele que nunca enfrenta falhas. É aquele cuja missão continua, mesmo quando uma parte da Sociedade precisa ficar para trás."