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.