Bellacosa Mainframe treinando em storage mainframe

💣🔥 LAB DFSMS COMPLETO — “DO DATASET À POLÍTICA”

🎯 OBJETIVO

Você vai:

• Criar Data Class, Storage Class, Management Class
• Definir ACS routines
• Alocar dataset via JCL
• Validar via ISPF/ISMF
• Simular comportamento real

---

🧱 PARTE 1 — CRIAR DATA CLASS

No ISMF:

Option 3 → Data Class

📌 Definição:

Data Class Name  ===> LABDATA
Description      ===> LAB FB 80

DSORG            ===> PS
RECFM            ===> FB
LRECL            ===> 80
BLKSIZE          ===> 800

Primary          ===> 5 CYL
Secondary        ===> 2 CYL

---

💣 Isso define o DNA do dataset

---

⚡ PARTE 2 — STORAGE CLASS

Option 4 → Storage Class

Name             ===> LABFAST
Description      ===> HIGH PERF LAB
Performance      ===> HIGH

---

💣 Aqui você está dizendo:
👉 “Esse dado precisa ser rápido”

---

🔁 PARTE 3 — MANAGEMENT CLASS

Option 5 → Management Class

Name             ===> LABMC
Description      ===> LAB POLICY

Backup           ===> DAILY
Expire           ===> 030 DAYS

Migration:
  ML1            ===> 02 DAYS
  ML2            ===> 05 DAYS

---

💣 Aqui você controla:

• Vida útil
• Backup
• Migração

---

🗂️ PARTE 4 — STORAGE GROUP

Option 6 → Storage Group

Name             ===> LABSG
Type             ===> POOL

Volumes:
  VOL001
  VOL002

---

💣 Pool de discos → onde tudo vai parar fisicamente

---

🧠 PARTE 5 — ACS ROUTINE (CORAÇÃO)

Option 7 → ACS ROUTINES

📌 STORAGE CLASS ACS

IF &HLQ = 'LAB'
  THEN SET &STORCLAS = 'LABFAST'
ELSE
  SET &STORCLAS = 'STANDARD'

---

📌 MANAGEMENT CLASS ACS

IF &HLQ = 'LAB'
  THEN SET &MGMTCLAS = 'LABMC'

---

📌 DATA CLASS ACS

IF &HLQ = 'LAB'
  THEN SET &DATACLAS = 'LABDATA'

---

💣 Aqui acontece a mágica:

👉 Você não escolhe nada no JCL
👉 O sistema decide automaticamente

---

⚔️ PARTE 6 — JCL REAL

//LABJOB   JOB  (ACCT),'LAB DFSMS',CLASS=A,MSGCLASS=X
//STEP1    EXEC PGM=IEFBR14
//DD1      DD  DSN=LAB.TEST.FILE,
//             DISP=(NEW,CATLG,DELETE),
//             SPACE=(CYL,(5,2)),
//             UNIT=SYSDA

---

💣 Note:

❌ Nenhuma class foi especificada
👉 ACS vai decidir tudo

---

🔍 PARTE 7 — VALIDAR NO ISPF

Use:

3.4 → Data Set List Utility

Verifique:

• Data Class aplicada ✅
• Storage Class correta ✅
• Management Class ativa ✅

---

🔥 PARTE 8 — TESTE REAL

💥 Teste 1 — Mudar HLQ

DSN=TEST.FILE

👉 Resultado esperado:

• Não pega LAB classes
• Cai no default

---

💥 Teste 2 — Simular erro

Altere ACS:

SET &STORCLAS = 'INVALID'

👉 Resultado:

• Falha de alocação 💣
• Excelente para aprendizado

---

🚀 PARTE 9 — SIMULAÇÃO HSM (MENTAL)

Com o tempo:

Dia 0 → criado
Dia 2 → ML1
Dia 5 → ML2 (fita)
Dia 30 → deletado

---

💣 Isso é automático via Management Class

---

⚔️ PARTE 10 — CENÁRIO REAL

Banco cria dataset LAB.PAYROLL
→ ACS aplica FAST + BACKUP
→ Dados usados
→ Após dias → migra
→ Auditoria exige restore
→ HSM recupera

---

🧠 CHECKLIST FINAL

Se você fez tudo:

✅ Criou classes
✅ Programou ACS
✅ Rodou JCL
✅ Validou resultado
✅ Entendeu ciclo de vida

---

💣 FRASE FINAL (NÍVEL PRODUÇÃO)

“Se você controla o ACS…
você controla o destino de todos os dados do sistema.”

 

Bellacosa Mainframe apresenta Storage para DEV Cobol

💣 SEU COBOL NÃO É LENTO — SEU STORAGE É QUE DECIDE O DESTINO DO JOB

Um papo direto com quem já escreveu milhões de linhas em COBOL…
mas talvez nunca tenha olhado o storage como o verdadeiro protagonista.

---

☕ Introdução — o erro que ninguém te contou

Você já viu isso:

• Job que ontem rodava em 5 minutos… hoje leva 40
• Batch que “do nada” começa a gargalar
• VSAM “misteriosamente” lento
• DB2 com I/O explodindo

E alguém diz:

“É o programa.”

Não.
Na maioria das vezes… é o storage.

---

🧠 CAPÍTULO 1 — Antes do disco… existia o tempo físico

🧾 Cartão perfurado: o primeiro “storage”

Antes de DASD, antes de tape…
o dado era literalmente um buraco no papel.

• Cada linha COBOL → um cartão
• Ordem física → lógica do programa
• Caiu no chão? 💣 acabou o sistema

💡 Insight:

O primeiro “bug” da história era… baralho embaralhado.

---

🎞️ CAPÍTULO 2 — Tape: o começo do streaming

📼 Fita magnética — o avô do Big D

Tape trouxe algo revolucionário:

• Processamento sequencial
• Grandes volumes
• Backup antes de existir “backup”

👉 E aqui nasce o conceito que você usa até hoje:

Batch

💡 Curiosidade:

• Tape ODEIA parar
• Se parar → “shoe-shining” (vai e volta igual fita cassete)

---

💿 CAPÍTULO 3 — Disco: quando o acesso ficou inteligente

🏢 DASD (Direct Access Storage Device)

Aqui muda o jogo:

• Acesso direto (não sequencial)
• Surge VSAM
• Surge CICS
• Surge DB2

👉 Você para de ler tudo… e passa a ler o que precisa

💡 Insight COBOL:

READ NEXT virou READ KEY

---

⚡ CAPÍTULO 4 — Flash: o fim da mecânica

🔥 SSD no mundo enterprise

Sem disco girando
Sem braço mecânico
Sem latência física relevante

👉 Resultado:

• I/O quase instantâneo
• Batch acelera absurdamente
• DB2 muda comportamento

💡 Insight crítico:

Flash não melhora programa ruim…
ele expõe arquitetura ruim

---

🚀 CAPÍTULO 5 — NVMe: paralelismo bruto

Aqui não é mais “rápido”…
é outro modelo mental.

• I/O paralelo massivo
• Filas simultâneas
• CPU quase não espera

👉 No mainframe:

O gargalo deixa de ser storage… e vira desenho da aplicação

---

🔌 CAPÍTULO 6 — O segredo que poucos entendem: I/O NÃO É CPU

🧠 Como o z/OS realmente funciona

No mundo distribuído:

• CPU faz tudo

No mainframe:

• CPU manda
• Channel executa
• Storage responde

👉 Resultado:

Seu COBOL NÃO faz I/O… ele pede I/O

💡 Easter egg:

• EXCP → você acha que controla tudo
• Mas quem manda mesmo é o Channel Subsystem

---

🧬 CAPÍTULO 7 — RAID: onde mora o risco invisível

Você nunca configurou RAID no COBOL…
mas ele define seu tempo de execução.

• RAID 5 → barato, mais lento
• RAID 10 → caro, extremamente rápido
• RAID 6 → seguro, mais pesado

💣 Verdade dura:

RAID errado = gargalo invisível

---

🧠 CAPÍTULO 8 — SMS: o cérebro invisível

Aqui está o ponto mais ignorado por dev:

SMS decide onde seu dado vai viver

• Storage Class → performance
• Management Class → lifecycle
• Data Class → formato

👉 Você escreve:

OPEN INPUT ARQUIVO

👉 Mas quem decide:

• Disco?
• Flash?
• Tape?

💡 Insight:

Você não controla o storage…
você negocia com ele

---

📦 CAPÍTULO 9 — Tape moderno: o sobrevivente

Tape não morreu.

Ele virou:

• Backup
• Archive
• Compliance
• Air gap (anti-ransomware)

💡 Insight:

Quando tudo falha…
é o tape que salva

---

🤖 CAPÍTULO 10 — Cartridge + robô = escala

• Cartucho = mídia
• Drive = leitura
• Robô = automação

👉 Você pede dataset
👉 Um robô físico movimenta o dado

Sim… existe um braço robótico trabalhando pro seu JCL

---

🧊 CAPÍTULO 11 — Air Gap: o último nível

• Offline
• Fora da rede
• Intocável

👉 Nem hacker… nem erro humano alcança

---

💣 CAPÍTULO FINAL — A verdade que muda tudo

Você achava que:

“Programa define performance”

Mas na prática:

• Storage define latência
• RAID define risco
• SMS define localização
• Tape define sobrevivência

---

☕ Bellacosa-style conclusão

“COBOL executa regra de negócio…
mas é o storage que decide se ela chega a tempo.”

 

 

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.”

 

 

Bellacosa Mainframe e o mundo secreto do Storage Mainframe cartridges e o cofre na montanha de ferro

🔥💀 DO CARTÃO PERFURADO AO COFRE NA MONTANHA

“Como seus dados COBOL sobreviveram a guerras, ransomware… e ao tempo”

---

🧨 Introdução (sem mimimi)

Se você escreve COBOL hoje…
existe uma chance enorme de que o dado que você manipula:

• já esteve em um cartão perfurado
• passou por uma fita magnética
• e talvez hoje esteja guardado em um cofre subterrâneo

Sim… isso não é romantização.
Isso é a linha evolutiva real do mainframe.

E no meio dessa história… existe um nome quase lendário:

👉 Iron Mountain

---

🧱 Capítulo 1 — Cartão perfurado: o “INSERT INTO” de 1930

Antes de existir dataset…
antes de existir VSAM…

👉 Existia isso:

• Cartões físicos
• 80 colunas
• Cada furo = dado

---

💀 Tradução Bellacosa:

“Seu SELECT era um buraco no papel”

---

🧠 Curiosidades

• Um programa COBOL inteiro = caixa de cartões
• Derrubar a pilha = ABEND físico real
• Ordenação = literalmente reorganizar papel

---

⚠️ Problema

• Lento
• Frágil
• Não escalável

---

👉 Aí veio a revolução…

---

📼 Capítulo 2 — Tape: o primeiro “Big Data” do mundo

👉 A fita trouxe:

• 📦 Volume massivo
• 🔄 Processamento sequencial
• ⚡ Muito mais velocidade que cartão

---

💀 Tradução:

“Sai o papel… entra o fluxo contínuo”

---

🧠 Como isso impactou o COBOL?

👉 Nasce o modelo que você usa até hoje:

• Arquivo sequencial
• Batch
• Processamento em massa

---

💡 Insight poderoso

👉 Seu COBOL batch moderno…

💀 ainda pensa como fita

---

📦 Capítulo 3 — Cartridge: o “pendrive” do mainframe

• Fita aberta → cartridge fechado
• Mais proteção
• Mais densidade
• Automação

---

📊 Exemplo real

• LTO-9 → 18 TB (nativo)
• Compressão → até 45 TB

---

💀 Tradução:

“Uma fita hoje guarda mais que um datacenter antigo inteiro”

---

🏔️ Capítulo 4 — Iron Mountain: o cofre dos dados do mundo

👉 Agora entra o nível lendário…

A Iron Mountain:

• Guarda dados em minas subterrâneas
• Protegidas contra:
  • fogo
  • guerra
  • desastre
• Usada por:
  • bancos
  • governos
  • Fortune 500

---

💀 Tradução Bellacosa:

“Se tudo der errado… seus dados estão dentro de uma montanha”

---

🚚 Como funciona

1. Backup em fita
2. Fita retirada da library
3. Transporte seguro
4. Armazenamento em cofre

---

🔐 Segurança real

👉 Isso cria o famoso:

AIR GAP físico

---

🧠 Capítulo 5 — Por que fita ainda manda?

---

⚔️ Disk vs Tape (sem romantismo)

Critério	Disk	Tape
Velocidade	⚡	🐢
Custo	💸	💰
Durabilidade	❌	✅
Segurança	⚠️	🔐

---

💀 Verdade dura:

“Disco é rápido… fita é eterna”

---

🧨 Capítulo 6 — Ransomware não perdoa (mas fita sim)

👉 Se o backup estiver online:

💀 Ele será criptografado junto

---

👉 Se estiver em fita offline:

✔️ Intocado
✔️ Recuperável
✔️ Seguro

---

🧠 Capítulo 7 — O que o dev COBOL precisa entender

---

💡 Você NÃO está só escrevendo código

Você está:

• Alimentando sistemas de retenção
• Gerando dados regulatórios
• Criando histórico corporativo

---

🎯 Dicas práticas

👉 Quando pensar em arquivos:

• Sequencial → fita-friendly
• Batch → tape-driven
• Grande volume → tape inevitável

---

👉 Quando pensar em backup:

• Disk → rápido
• Tape → seguro

---

👉 Quando pensar em DR:

💀 “Se não tem fita… não tem garantia”

---

🧨 Curiosidades que ninguém te conta

• CERN usa tape para centenas de PB
• Cloud providers usam tape no backend
• LTO roadmap chega a 576 TB por fita (futuro)

---

💀 Conclusão — A verdade que poucos entendem

👉 O mundo mudou
👉 A tecnologia evoluiu

Mas…

---

💀 A fita nunca morreu

---

Ela só:

• Ficou mais densa
• Mais segura
• Mais invisível

---

🎯 Frase final estilo Bellacosa

“Seu COBOL pode rodar no Z17…
mas a memória da empresa ainda descansa em fita — guardada dentro de uma montanha.”

 

💣🔥 LABORATÓRIO PRÁTICO — “DO DATASET À FITA (Storage Mainframe)

 

Bellacosa Mainframe Laboratorio pratico Storage Mainframe

💣🔥 LABORATÓRIO PRÁTICO — “DO DATASET À FITA”

DFSMS + DFSMShsm + DFSMSrmm para SysProg Junior & Aspirante a Storage ☕💾

🎯 Objetivo do LAB:

Você vai aprender na prática:

✅ Como o z/OS decide onde um dataset será armazenado
✅ Como políticas DFSMS funcionam
✅ Como ACS automatiza storage
✅ Como HSM migra dados
✅ Como RMM controla retenção e fitas

💣 Tudo isso pensando como um Storage Admin real.

---

🧠 CENÁRIO DO LAB

Você trabalha em um banco fictício:

BANCO Z17

Seu desafio:

👉 Criar uma política automática para datasets financeiros.

Regras:

• Dados financeiros precisam ser rápidos

• Backup diário

• Migração automática após 2 dias

• Retenção de 30 dias

• Controle de fita para auditoria

---

⚔️ ETAPA 1 — CRIAR DATA CLASS

🎯 Objetivo

Definir a estrutura do dataset.

---

🖥️ ISMF

Option 3 → Data Class

---

📌 Criar:

Data Class Name ===> FINDATA

Description     ===> FINANCIAL FB 80

DSORG           ===> PS
RECFM           ===> FB
LRECL           ===> 80
BLKSIZE         ===> 800

Primary Qty     ===> 10 CYL
Secondary Qty   ===> 5 CYL

---

✅ SOLUÇÃO

💡 O dataset agora possui:

• Formato fixo

• Estrutura padrão bancária

• Crescimento controlado

---

⚡ ETAPA 2 — CRIAR STORAGE CLASS

🎯 Objetivo

Garantir alta performance.

---

🖥️ ISMF

Option 4 → Storage Class

---

📌 Criar:

Storage Class ===> FASTFIN

Performance   ===> HIGH
Description   ===> SSD STORAGE

---

✅ SOLUÇÃO

💡 O dataset agora será direcionado para storage de alta performance.

---

🔁 ETAPA 3 — MANAGEMENT CLASS

🎯 Objetivo

Automatizar ciclo de vida.

---

🖥️ ISMF

Option 5 → Management Class

---

📌 Criar:

Management Class ===> FINMGT

Backup           ===> DAILY

ML1 Migration    ===> 02 DAYS
ML2 Migration    ===> 05 DAYS

Expiration       ===> 030 DAYS

---

✅ SOLUÇÃO

💡 Agora o dataset:

• Recebe backup

• Migra automaticamente

• Expira sozinho

---

🗂️ ETAPA 4 — STORAGE GROUP

🎯 Objetivo

Definir pool físico.

---

🖥️ ISMF

Option 6 → Storage Group

---

📌 Criar:

Storage Group ===> FINSG

Volumes:
VOL001
VOL002
VOL003

---

✅ SOLUÇÃO

💡 Os datasets poderão ser distribuídos automaticamente entre volumes.

---

🧠 ETAPA 5 — ACS ROUTINE

🎯 Objetivo

Automatizar decisões.

---

🖥️ ISMF

Option 7 → ACS Routines

---

📌 STORAGE CLASS ACS

IF &HLQ = 'FINANCE'
 THEN SET &STORCLAS = 'FASTFIN'

---

📌 MANAGEMENT CLASS ACS

IF &HLQ = 'FINANCE'
 THEN SET &MGMTCLAS = 'FINMGT'

---

📌 DATA CLASS ACS

IF &HLQ = 'FINANCE'
 THEN SET &DATACLAS = 'FINDATA'

---

✅ SOLUÇÃO

💣 Agora o sistema decide tudo sozinho.

Você não precisa informar classes no JCL.

---

⚔️ ETAPA 6 — EXECUTAR JCL

🎯 Objetivo

Criar dataset usando automação.

---

📌 JCL

//FINJOB  JOB (ACCT),'FINANCE',CLASS=A,MSGCLASS=X
//STEP1   EXEC PGM=IEFBR14
//DD1     DD  DSN=FINANCE.CLIENTES.DADOS,
//            DISP=(NEW,CATLG,DELETE),
//            SPACE=(CYL,(10,5)),
//            UNIT=SYSDA

---

✅ SOLUÇÃO

💡 Resultado esperado:

O z/OS aplicará automaticamente:

• FINDATA

• FASTFIN

• FINMGT

---

🔍 ETAPA 7 — VALIDAR

🖥️ ISPF 3.4

FINANCE.CLIENTES.DADOS

---

📌 Verificar:

✅ Data Class
✅ Storage Class
✅ Management Class

---

💣 ETAPA 8 — SIMULAÇÃO DE ERRO

🎯 Objetivo

Aprender troubleshooting.

---

📌 Alterar ACS:

SET &STORCLAS = 'INVALID'

---

❌ Resultado esperado

Falha na alocação.

---

✅ LIÇÃO

💣 Uma linha errada no ACS pode afetar o ambiente inteiro.

---

🔄 ETAPA 9 — ENTENDENDO HSM

🎯 Fluxo automático

Dia 0 → Disco rápido
Dia 2 → ML1
Dia 5 → ML2 (fita)
Dia 30 → DELETE

---

✅ LIÇÃO

👉 O dataset “viaja” automaticamente conforme envelhece.

---

📼 ETAPA 10 — RMM & COMPLIANCE

🎯 Objetivo

Entender retenção.

---

📌 Cenário

Backup bancário precisa ficar 7 anos.

---

✅ SOLUÇÃO

RMM garante:

• Rastreamento

• Inventário

• Auditoria

• Vault

---

⚔️ DESAFIO FINAL

💥 Desafio para o aluno

Crie nova política para:

HLQ = TESTE

Regras:

• Storage STANDARD

• Sem backup

• Expiração 5 dias

---

✅ RESPOSTA ESPERADA

O aluno deverá:

• Criar novas classes

• Alterar ACS

• Validar comportamento

---

🧠 O QUE VOCÊ APRENDEU

✅ DFSMS Constructs
✅ ACS Routines
✅ Automação de storage
✅ Ciclo de vida HSM
✅ Conceitos RMM
✅ Troubleshooting básico

---

💣 FRASE FINAL ESTILO BELLACOSA

“No z/OS, datasets não envelhecem por acaso…
eles seguem políticas que alguém escreveu.”

 

IBM Z Resiliência : 30 Laboratórios Práticos Do "Meu Primeiro Sysplex" até "Meu Datacenter Nunca Para"

Bellacosa Mainframe e o laboratorio pratico em IBM Z Resiliencia

---

☕ O Holocron da Resiliência IBM Z

30 Laboratórios Práticos

Do "Meu Primeiro Sysplex" até "Meu Datacenter Nunca Para"

A Resiliência no IBM Z vai muito além de conhecer siglas como HA, DR, Parallel Sysplex ou GDPS. Ela representa uma filosofia de engenharia construída ao longo de décadas para garantir que aplicações críticas permaneçam disponíveis mesmo diante de falhas de hardware, software, rede ou até desastres naturais. O objetivo deste guia é conduzir o Programador COBOL, Analista de Sistemas ou futuro Sysprog por uma jornada progressiva, mostrando como cada componente da plataforma contribui para a continuidade do negócio e como todos trabalham em conjunto para entregar disponibilidade praticamente ininterrupta.

A melhor forma de aprender é evoluir em etapas. Comece dominando os conceitos fundamentais de SLA, RPO, RTO, RAS e Single Point of Failure. Em seguida, compreenda a arquitetura do IBM Z, estudando CPC, LPARs, HMC e o papel do LIC. Depois avance para Parallel Sysplex, Coupling Facility, WLM e GDPS, entendendo como múltiplos sistemas operam como um único ambiente resiliente. Na sequência, aprofunde-se em DFSMS, Storage, CICS, Db2, IMS, MQ e estratégias de recuperação e continuidade dos negócios.

Procure sempre relacionar teoria com prática. Analise mensagens do sistema, consulte o SDSF, estude relatórios RMF e SMF, desenhe arquiteturas, simule cenários de falha e questione como sua aplicação reagiria a cada situação. O profissional que compreende Resiliência deixa de enxergar apenas programas COBOL e passa a entender todo o ecossistema que mantém milhões de transações funcionando com segurança, desempenho e confiabilidade. Esse é o caminho para evoluir de Padawan a Mestre no universo IBM Z.

---

🟢 NÍVEL 1 — PADAWAN (Labs 1–10)

Lab 1 – Descobrindo a Arquitetura IBM Z

Objetivo

Identificar todos os componentes físicos do ambiente.

Atividades

• Localizar CPC

• Identificar LPARs

• Ver HMC

• Identificar Storage

Solução

O aluno deve desenhar a arquitetura mostrando como todos os componentes se conectam.

---

Lab 2 – Identificando SPOFs

Objetivo

Encontrar Single Points of Failure.

Atividades

Analisar:

• Rede

• Storage

• CICS

• MQ

• Db2

Solução

Criar uma tabela

Componente	Existe redundância?
Storage	Sim
Switch	Não
Servidor DNS	Não

---

Lab 3 – Calculando SLA

Dado:

99,5%

99,9%

99,99%

99,999%

Calcule:

• indisponibilidade anual

• mensal

• diária

Solução

Utilizar tabela oficial de SLA.

---

Lab 4 – Descobrindo o RPO

Uma empresa aceita perder:

• nenhuma transação

• cinco minutos

• uma hora

Classifique o RPO.

Solução

Relacionar cada cenário ao objetivo de recuperação.

---

Lab 5 – Descobrindo o RTO

Mesmo exercício.

Agora considerando tempo de recuperação.

---

Lab 6 – CFIA

Escolha um ambiente.

Analise:

"O que acontece se..."

• Storage parar

• CPU parar

• Switch parar

Solução

Construir matriz de impacto.

---

Lab 7 – Conhecendo o WLM

No SDSF identificar:

• Service Classes

• Importance

• Velocity

Solução

Explicar porque um Job Batch ficou esperando.

---

Lab 8 – Explorando RMF

Consultar:

CPU

I/O

Paging

Storage

Solução

Gerar relatório resumido.

---

Lab 9 – Health Checker

Executar

F HZSPROC

Interpretar avisos.

---

Lab 10 – Runtime Diagnostics

Executar Runtime Diagnostics.

Interpretar:

• Loop

• Espera

• Deadlock

---

🟡 NÍVEL 2 — JEDI (Labs 11–20)

---

Lab 11 – Criando um Sysplex

Desenhar:

2 LPARs

1 Coupling Facility

Storage compartilhado

Solução

Apresentar diagrama.

---

Lab 12 – Entendendo a Coupling Facility

Identificar:

• Lock Structure

• Cache Structure

• List Structure

Explicar função de cada uma.

---

Lab 13 – Simulando Falha de um Membro

Desligar uma LPAR (ambiente de laboratório).

Observar:

• usuários continuam?

• aplicações continuam?

---

Lab 14 – ARM

Parar uma região CICS.

Verificar reinício automático.

---

Lab 15 – DVIPA

Mover uma aplicação entre membros.

Confirmar:

IP continua igual.

---

Lab 16 – Sysplex Distributor

Monitorar distribuição de sessões.

Verificar balanceamento.

---

Lab 17 – LBA

Analisar recomendações do Load Balancing Advisor.

---

Lab 18 – Capacity on Demand

Criar cenário:

Black Friday.

Qual recurso ativar?

CBU?

CUoD?

OOCoD?

Justifique.

---

Lab 19 – DFSMS

Criar:

Storage Group

Management Class

Storage Class

Data Class

Associar Dataset.

---

Lab 20 – DFSMShsm

Migrar um dataset.

Recuperá-lo.

Verificar tempo.

---

🔴 NÍVEL 3 — MESTRE (Labs 21–30)

---

Lab 21 – CICSplex

Desenhar:

TOR

AOR

FOR

DOR

Fluxo completo.

---

Lab 22 – MQ

Criar:

Queue

Sender

Receiver

Enviar mensagens.

Simular parada do receptor.

Confirmar persistência.

---

Lab 23 – Db2

Executar:

RUNSTATS

REORG

Comparar Access Path.

---

Lab 24 – IMS

Criar fluxo:

Terminal

TM

Programa

IMS DB

Resposta.

---

Lab 25 – Metro Mirror

Desenhar:

Site A

Site B

Replicação síncrona.

Explicar RPO.

---

Lab 26 – Global Mirror

Mesmo exercício.

Agora com longa distância.

Explicar diferenças.

---

Lab 27 – Business Continuity

Escreva um BCP contendo:

• responsáveis

• comunicação

• ordem de recuperação

• testes

---

Lab 28 – Simulação Completa

O cenário:

🔥 Incêndio no Data Center Principal.

O aluno deve decidir:

• ativa GDPS?

• ativa CBU?

• usa Metro Mirror?

• muda DNS?

• inicia ARM?

Justificar todas as decisões.

---

Lab 29 – Projeto de Arquitetura

Receba:

Banco Digital

20 milhões de clientes

PIX

Cartão

Internet Banking

Desenhe:

• Hardware

• Sysplex

• CICSplex

• MQ

• Db2

• Storage

• DR

---

Lab 30 – O Desafio Final do Mestre

A empresa deseja atingir:

• 99,999% de disponibilidade

• RPO = Zero

• RTO = Menor que 5 minutos

• Dois datacenters ativos

• 50 milhões de transações por dia

• Atualizações sem parada

• Crescimento de capacidade sem desligamento

Missão

Projetar toda a arquitetura IBM Z.

O projeto deve incluir:

• IBM Z (CPCs e LPARs)

• Parallel Sysplex

• Coupling Facility

• WLM

• SFM

• ARM

• CICSplex (TOR, AOR, FOR e DOR)

• IBM MQ

• Db2 for z/OS

• IMS (quando aplicável)

• DFSMS

• IBM Copy Services Manager

• Metro Mirror ou Global Mirror

• GDPS

• Business Continuity Plan

• Capacity on Demand (CBU, CUoD ou OOCoD)

Solução esperada

O aluno entrega um documento de arquitetura contendo:

• diagrama completo da solução;

• justificativa técnica para cada componente;

• estratégia de alta disponibilidade;

• estratégia de recuperação de desastres;

• cálculo de SLA, RPO e RTO;

• análise de Single Points of Failure e respectivas eliminações;

• plano de testes de contingência;

• plano de crescimento para os próximos cinco anos.

---

🏆 Certificação Bellacosa Mainframe

Ao concluir os 30 laboratórios, o aluno terá praticado os principais conceitos de resiliência do IBM Z, passando da compreensão dos fundamentos até o desenho de arquiteturas corporativas. Essa sequência é adequada tanto para um Programador COBOL Júnior que deseja entender a plataforma onde suas aplicações executam quanto para profissionais que pretendem evoluir para funções de Analista de Infraestrutura IBM Z, Sysprog, Especialista em Alta Disponibilidade ou Arquiteto Mainframe. Ela também pode servir como base para um curso completo de aproximadamente 40 horas, com exercícios, estudos de caso e desafios progressivos. 

O Holocron da Resiliência IBM Z - A Jornada Completa para Entender Por Que os Mainframes Nunca Param

 

Bellacosa Mainframe e a resiliencia ibm z

☕ Um Café no Bellacosa Mainframe

O Holocron da Resiliência IBM Z

A Jornada Completa para Entender Por Que os Mainframes Nunca Param

Existe uma pergunta que todo Padawan COBOL faz nos primeiros meses trabalhando com IBM Z.

"Por que os bancos utilizam Mainframe até hoje?"

A resposta normalmente é simplificada.

"Porque é seguro."

"Porque é rápido."

"Porque processa milhões de transações."

Embora todas essas afirmações sejam verdadeiras, elas escondem um conceito muito maior.

O verdadeiro diferencial do IBM Z não está apenas em sua capacidade de processamento.

Está na sua capacidade de continuar funcionando.

Ao longo desta série especial O Holocron da Resiliência IBM Z, percorremos uma jornada completa pelos principais componentes que transformam o IBM Z na plataforma mais confiável do mercado para aplicações críticas.

Muito mais do que conhecer novos termos técnicos, o objetivo foi compreender como hardware, sistema operacional, middleware, armazenamento e processos trabalham em perfeita sintonia para garantir continuidade dos negócios.

---

📜 Parte I – Conceitos Fundamentais

Nossa jornada começou entendendo a filosofia da Resiliência.

Exploramos conceitos como:

• Resiliency

• RAS

• High Availability

• Disaster Recovery

• SLA

• RPO

• RTO

• Single Point of Failure

• ITIL

• CFIA

Foi aqui que descobrimos que o IBM Z não foi projetado para impedir falhas.

Ele foi projetado para impedir que as falhas afetem o negócio.

👉 Leia a Parte I: https://eljefemidnightlunch.blogspot.com/2024/01/resiliencia-ibm-z-conceitos.html

---

🖥 Parte II – A Arquitetura do IBM Z

Na segunda publicação descemos até a infraestrutura física.

Conhecemos os componentes invisíveis que sustentam toda a plataforma:

• CPC

• Processing Units

• License Internal Code

• Hardware Management Console

• Support Element

• FFDC

• Runtime Diagnostics

• Predictive Failure Analysis

• Auto IPL

• System Recovery Boost

Foi possível entender como o próprio hardware participa ativamente da prevenção e recuperação de falhas.

👉 Leia a Parte II: https://eljefemidnightlunch.blogspot.com/2024/02/resiliencia-ibm-z-arquitetura-do-ibm-z.html

---

🔗 Parte III – Parallel Sysplex

Em seguida conhecemos uma das maiores invenções da engenharia IBM.

O Parallel Sysplex.

Exploramos:

• Coupling Facility

• WLM

• SFM

• ARM

• DVIPA

• Sysplex Distributor

• Load Balancing Advisor

Aprendemos como diversos mainframes conseguem trabalhar como um único sistema lógico, distribuindo carga automaticamente e mantendo aplicações disponíveis mesmo durante falhas.

👉 Leia a Parte III: https://eljefemidnightlunch.blogspot.com/2024/03/resiliencia-ibm-z-parallel-sysplex-o.html

---

💾 Parte IV – Storage Inteligente

Depois mergulhamos no universo do armazenamento corporativo.

Conhecemos o DFSMS e seus diversos componentes:

• DFSMSdfp

• DFSMSdss

• DFSMShsm

• DFSMSrmm

• DFSMStvs

Também exploramos:

• Capacity on Demand

• CBU

• CUoD

• OOCoD

• eBoD

• System Logger

Descobrimos que, no IBM Z, armazenamento significa muito mais do que simplesmente gravar arquivos.

É uma plataforma inteligente capaz de proteger, migrar, recuperar e expandir dados automaticamente.

👉 Leia a Parte IV: https://eljefemidnightlunch.blogspot.com/2024/04/resiliencia-ibm-z-storage-inteligente-e.html

---

⚙ Parte V – O Coração das Aplicações

Nenhuma infraestrutura teria valor sem aplicações.

Nesta etapa conhecemos os componentes responsáveis por processar milhões de transações diariamente:

• CICS

• CICS TS

• Db2

• IBM MQ

• IMS

• IMS DB

• CICSplex

• TOR

• AOR

• FOR

• DOR

• HALDB

• DBRC

• FDBR

Foi aqui que percebemos como aplicações COBOL continuam evoluindo e hoje conversam naturalmente com APIs REST, microsserviços, dispositivos móveis e plataformas em nuvem.

👉 Leia a Parte V:https://eljefemidnightlunch.blogspot.com/2024/05/resiliencia-ibm-z-o-coracao-das.html

---

🛡 Parte VI – A Última Linha de Defesa

Encerramos nossa jornada explorando os mecanismos responsáveis pela continuidade do negócio diante dos cenários mais extremos.

Conhecemos tecnologias como:

• IBM Copy Services Manager

• Metro Mirror

• Global Mirror

• z/OS Global Mirror

• Zero Data Loss

• Multi Target Metro Mirror

• Coupling Data Set

• Business Continuity Plan

Descobrimos que um desastre não precisa significar interrupção do negócio.

Tudo depende do planejamento e da arquitetura construída antes da emergência acontecer.

👉 Leia a Parte VI: https://eljefemidnightlunch.blogspot.com/2024/06/resiliencia-ibm-z-ultima-linha-de.html 

---

O Que um Padawan Deve Levar Desta Série?

Talvez o maior aprendizado desta série seja perceber que um programa COBOL nunca trabalha sozinho.

Quando um simples programa executa um READ, um WRITE, um EXEC SQL ou um EXEC CICS LINK, existe um verdadeiro ecossistema trabalhando silenciosamente nos bastidores.

Processadores especializados.

Controladores inteligentes.

Storage redundante.

Parallel Sysplex.

Workload Manager.

Middleware.

Replicação síncrona.

Recuperação automática.

Monitoramento contínuo.

Tudo isso existe para garantir que o usuário final consiga realizar uma operação bancária, uma compra no cartão de crédito, uma transferência PIX ou uma reserva de passagem aérea sem sequer imaginar a complexidade envolvida.

É justamente essa engenharia invisível que faz do IBM Z uma referência mundial em computação de missão crítica.

---

A Filosofia Bellacosa Mainframe

Existe uma frase que resume toda esta coleção.

"Resiliência não é uma tecnologia. É uma filosofia de engenharia."

No IBM Z, falhas são previstas.

Componentes quebram.

Discos são substituídos.

Processadores entram em manutenção.

Datacenters podem até ficar indisponíveis.

Mesmo assim, milhões de pessoas continuam utilizando seus serviços normalmente.

Esse é o verdadeiro poder do Mainframe.

Não construir computadores perfeitos.

Mas construir sistemas preparados para continuar funcionando quando a imperfeição inevitavelmente aparecer.

E talvez essa seja a maior lição para qualquer Programador COBOL.

Escrever código é importante.

Mas compreender toda a arquitetura que mantém esse código disponível para milhões de pessoas é o que transforma um Padawan em um verdadeiro Mestre do IBM Z.

Que a Força da Resiliência esteja com você.