Bellacosa Mainframe VSAM lento tuning IDCAMS e outros segredinhos

💣 VSAM LENTO? NÃO É O MAINFRAME — É O SEU TUNING! 🔥 Os Segredos de Performance que Ninguém Te Conta

🧠 1) Escolha o tipo correto de arquivo VSAM

📌 Tradução

O VSAM suporta quatro tipos principais de datasets:

• ESDS (Entry-Sequenced Data Set) → acesso sequencial
• KSDS (Key-Sequenced Data Set) → acesso por chave
• RRDS (Relative Record Data Set) → acesso direto por número relativo
• LDS (Linear Data Set) → armazenamento bruto (usado por DB2, etc.)

Cada tipo possui características diferentes e deve ser escolhido conforme o padrão de acesso aos dados.

---

💬 Comentário Bellacosa

Aqui está o primeiro erro clássico de projeto:

❌ “Vou usar KSDS pra tudo porque é mais completo”

👉 Resultado: I/O desnecessário, split, CI/CA fragmentation, e performance indo pro ralo.

---

🧪 Exemplo prático

✔ Caso ideal:

• Batch sequencial (ex: faturamento diário)
  → ESDS ganha disparado
• Sistema online CICS com lookup por chave
  → KSDS obrigatório
• Tabela indexada por posição fixa
  → RRDS simplifica tudo

---

🚀 Dica avançada (pouco falada)

Se seu acesso for altamente randômico:

👉 Combine:

• KSDS
• • SMB + ACCBIAS=DO (Direct Optimized)

Isso muda o jogo de performance.

---

🧠 2) Otimização de buffers

📌 Tradução

Buffers são áreas de memória usadas para armazenar dados temporariamente durante operações VSAM.

• Poucos buffers → excesso de I/O
• Muitos buffers → desperdício de CPU/memória

---

💬 Comentário Bellacosa

Aqui mora um dos maiores gargalos invisíveis:

VSAM não é lento…
VSAM mal bufferizado é lento.

---

🧪 Exemplo prático (JCL)

//DD1 DD DSN=SEU.VSAM.KSDS,
//     AMP=('BUFND=20','BUFNI=10')

• BUFND → buffers de dados
• BUFNI → buffers de índice

---

🧠 Regra de ouro

Tipo de acesso	Ajuste
Sequencial	BUFND alto
Randômico	BUFNI mais importante

---

🚀 Nível PRO (SMB tuning)

AMP=('ACCBIAS=DO','SMB')

• DO → acesso randômico otimizado
• SO → sequencial
• SW/DW → dinâmico

💣 Isso pode reduzir I/O drasticamente.

---

🧠 3) Minimizar tamanho de registro

📌 Tradução

O tamanho do registro influencia diretamente:

• Quantidade de blocos
• Uso de buffer
• Transferência de dados

---

💬 Comentário Bellacosa

Esse é clássico de legado:

“Ah, deixa esse campo aqui... vai que um dia usam”

👉 Resultado:

• Records inflados
• CI mal aproveitado
• Mais EXCP

---

🧪 Exemplo

❌ Ruim:

Cliente:
- Nome (100 bytes)
- Código (10)
- 20 campos não usados

✔ Melhor:

Cliente:
- Nome (40)
- Código (10)

---

🚀 Técnicas avançadas

• Compressão de dados
• REDEFINES em COBOL
• Uso de campos variáveis (spanned records com cuidado)

---

💣 Trade-off real

Registro pequeno	Registro grande
+ menos I/O	+ menos splits
- desperdício de espaço	- mais dados por I/O

---

🧠 4) Ajuste da configuração de I/O

📌 Tradução

A configuração de I/O inclui:

• Tipo de device
• Velocidade
• Canais
• Pathing
• Alocação

Ferramentas recomendadas:

• SMF
• RMF

---

💬 Comentário Bellacosa

Aqui entramos no território dos sysprogs 🔥

Às vezes o problema NÃO é o VSAM
👉 é o storage, canal ou concorrência

---

🧪 Exemplo real

Problema:

• VSAM lento

Análise SMF:

• Alta contenção em volume

Solução:

• Redistribuir datasets
• Melhorar striping
• Ajustar cache

---

🚀 Dica ninja

• Use LSR (Local Shared Resources) em CICS
• Use RLS (Record Level Sharing) para concorrência

💣 Isso muda completamente o comportamento do VSAM online

---

🧠 5) Considerações extras (parte mais rica!)

💬 Expansão Bellacosa

Aqui entram os segredos que poucos documentam 👇

---

🔥 CI SIZE (Control Interval)

• Sequencial → CI maior (ex: 32K)
• Randômico → CI menor (ex: 4K ou 8K)

---

🔥 CA SIZE (Control Area)

• Afeta splits e performance
• CA maior → menos splits

---

🔥 FREESPACE

FREESPACE(20 10)

• 20% no CI
• 10% no CA

👉 Reduz splits (ESSENCIAL em KSDS)

---

🔥 Secondary Allocation

Evite muitos extents:

SPACE=(CYL,(100,50))

---

🔥 Split (o vilão silencioso)

Quando ocorre:

• CI Split
• CA Split

💣 Consequência:

• Mais I/O
• Fragmentação
• Queda brutal de performance

---

🧪 LAB PRÁTICO (nível Bellacosa 😎)

🎯 Objetivo:

Comparar performance com tuning vs sem tuning

---

Cenário 1 (ruim)

• KSDS
• CI pequeno
• Sem buffer tuning
• Sem FREESPACE

---

Cenário 2 (otimizado)

• KSDS
• CI adequado
• FREESPACE(20 10)
• SMB + ACCBIAS
• BUFND/BUFNI ajustado

---

🔍 Métrica:

• EXCP count
• Tempo de execução
• SMF 64/42

---

💥 Resultado esperado:

👉 Redução de I/O de 30% a 80% (sim, acontece!)

---

🏁 Conclusão estilo Bellacosa

VSAM não é velho…
VSAM é mal compreendido.

Quando bem tunado:

💣 Ele compete com banco moderno
💣 Ele escala
💣 Ele é absurdamente eficiente

 

Bellacosa Mainframe com uma overview do Dataset VSAM no z/os

🔥 VSAM NÃO MORREU — ELE SÓ ESTÁ RODANDO EM PRODUÇÃO HÁ 40 ANOS SEM ABEND

🧠 O Segredo Mais Subestimado do z/OS (e por que você ainda depende dele)

Se você é desenvolvedor COBOL raiz, daqueles que já viram JCL com mais linhas que romance russo, então sabe: VSAM não é só storage… é infraestrutura crítica disfarçada de dataset.

Enquanto o mundo fala de NoSQL, Data Lakes e Kubernetes, lá no coração do IBM z/OS, o VSAM continua firme, resiliente… e silenciosamente essencial.

---

🧬 Origem: quando performance era questão de sobrevivência

O VSAM nasceu nos anos 60 com o OS/VS, evoluindo até o que conhecemos hoje no z/OS. Ele foi criado para resolver limitações dos métodos antigos (ISAM principalmente), trazendo:

• Acesso indexado eficiente
• Gerenciamento automático de espaço
• Alta performance com grandes volumes

👉 Em outras palavras: VSAM foi o “Db2” antes do Db2 existir.

---

🚀 Versão atual relevante

Hoje, estamos na linha do:

👉 z/OS 3.x (como 3.1, 3.2, etc.)

E isso significa:

✔ VSAM atualizado automaticamente
✔ Melhorias de performance
✔ Integração com DFSMS
✔ Suporte a grandes volumes (EAV / Extended Addressability)

---

⚙️ O que evoluiu no VSAM ao longo do tempo

Mesmo sem “versão própria”, ele evoluiu MUITO:

🔹 Extended Addressability (EA)

• Saiu do limite de GB → foi para TB

🔹 RLS (Record Level Sharing)

• Concorrência real (quase “transacional”)

🔹 DFSMS

• Gerenciamento automático (ACS routines)

🔹 Buffering avançado

• Performance tuning muito mais fino

---

🧱 Onde o VSAM vive hoje

VSAM não é só “arquivo COBOL”:

👉 Ele é base de coisas grandes, como:

• IBM Db2 for z/OS (usa LDS por baixo)
• Catálogo do sistema
• Sistemas críticos bancários

💥 Ou seja:
Mesmo que você “não use VSAM”… você usa.

---

⚠️ Erro comum de iniciante (e até de sênior distraído)

Perguntar:

“Qual versão do VSAM estamos usando?”

👉 A pergunta correta é:

“Qual versão do z/OS estamos rodando?”

---

🗂️ Tipos de Arquivos VSAM (o coração da arquitetura)

🔑 KSDS — Key Sequenced Data Set (o rei do pedaço)

• Acesso por chave (PRIMARY KEY raiz do COBOL)
• Possui INDEX + DATA
• Suporta acesso sequencial e direto

💬 Comentário Bellacosa:
Se VSAM fosse banco de dados, o KSDS seria o OLTP raiz.

---

📦 ESDS — Entry Sequenced Data Set

• Registros gravados em ordem de entrada
• Sem chave
• Acesso via RBA (Relative Byte Address)

💬 Uso clássico: logs, trilhas de auditoria, arquivos append-only

---

🔢 RRDS — Relative Record Data Set

• Acesso via número relativo (RRN)
• Pode ter slots vazios
• Pode ser FIXED ou VARIABLE

💬 Parece simples… até você esquecer que tem slot vazio e dar READ errado 😅

---

🧱 LDS — Linear Data Set

• Sem estrutura lógica de registros
• Usado por sistemas como IBM Db2 for z/OS
• Base para tablespaces

💬 Aqui o VSAM vira “infra invisível”

---

⚙️ IDCAMS — O canivete suíço do VSAM

Se você nunca digitou isso, você não viveu:

//STEP01 EXEC PGM=IDCAMS
//SYSPRINT DD SYSOUT=*
//SYSIN DD *
  DEFINE CLUSTER(NAME(MEU.KSDS)
    INDEXED
    KEYS(10 0)
    RECORDSIZE(80 80)
    CYLINDERS(5 2))
/*

📌 Com o IDCAMS você:

• DEFINE / DELETE / ALTER
• REPRO (ETL raiz do mainframe)
• LISTCAT (o “SELECT * FROM VSAM”)

💬 Curiosidade:
O REPRO já fazia “data migration” décadas antes do termo existir.

---

🧠 Curiosidades que só quem viveu sabe

• VSAM usa Control Interval (CI) e Control Area (CA) — tuning fino de performance
• Split de CI/CA pode causar degradação se mal dimensionado
• Buffer tuning pode mudar completamente o desempenho
• SHAREOPTIONS define concorrência (e dor de cabeça 😄)

---

📊 VSAM vs SQL (Db2): o choque de paradigmas

VSAM	Db2
Navegacional	Declarativo
Ultra rápido	Flexível
Sem overhead	Com engine
Controle manual	Automação

👉 Hoje, o IBM Db2 for z/OS usa VSAM (LDS) por baixo.

💥 Plot twist: Você acha que saiu do VSAM… mas nunca saiu.

---

🧮 Limitações e características técnicas

• Máx. tamanho: até dezenas de TB (dependendo do tipo e configuração)
• Máx. keys:
  • 1 chave primária
  • múltiplos AIX (Alternate Indexes)
• Máx. tamanho de registro: ~32KB
• CI tamanho: 512 bytes até 32KB
• CA: múltiplos de CI

📌 Limitação real não é técnica — é governança e design

---

🧷 Pontos Fortes

✅ Performance absurda (baixo overhead)
✅ Estabilidade lendária
✅ Controle fino
✅ Ideal para batch massivo

---

⚠️ Pontos Fracos

❌ Complexidade operacional
❌ Curva de aprendizado alta
❌ Sem SQL nativo
❌ Manutenção manual (splits, tuning)

---

🧪 Exemplo COBOL clássico (KSDS)

READ MEU-KSDS
  KEY IS WS-CHAVE
  INVALID KEY
     DISPLAY 'NAO ENCONTRADO'
END-READ.

💬 Simples. Direto. Sem ORM. Sem mágica.

---

🚀 Versões atuais e evolução

VSAM continua sendo parte essencial do IBM z/OS (versões atuais como 3.x).

E evoluiu com:

• RLS (Record Level Sharing)
• DFSMS integração
• Melhorias de cache e buffering

---

📦 📊 Tamanho máximo de um VSAM (na prática e na teoria)

No IBM z/OS, o tamanho de um dataset VSAM não é um único número fixo — ele depende de:

• Tipo do VSAM (KSDS, ESDS, RRDS, LDS)

• Tamanho do CI (Control Interval)

• Quantidade de CA (Control Areas)

• Limitações do volume (DASD)

• SMS / DFSMS

---

🧠 💥 Resposta direta (o número que você quer)

👉 Um VSAM pode chegar a dezenas de TERABYTES

📌 Valores típicos modernos:

• Até ~128 TB por dataset (em ambientes modernos com Extended Addressability)
• Limitado principalmente pelo volume e configuração SMS

---

⚙️ 🔍 O que define esse limite?

1. 📦 Extended Addressability (EA)

Sem isso, você está preso ao passado.

• VSAM clássico: ~4 GB limite antigo
• VSAM com EA: escala para terabytes

💬 Se não tem EA habilitado → você está vivendo em 1985

---

2. 🧱 Control Areas (CA) e Control Intervals (CI)

• CI: até 32 KB
• CA: conjunto de CIs
• Total = CI × quantidade de CAs

👉 O VSAM cresce horizontalmente via CAs

---

3. 💽 Limite físico do DASD

Mesmo que o VSAM suporte muito:

• Seu volume pode limitar (3390, EAV, etc.)
• Multi-volume entra em jogo

---

🗂️ 📊 Por tipo de VSAM

Tipo	Tamanho Máximo
KSDS	Até dezenas de TB
ESDS	Similar ao KSDS
RRDS	Limitado por slots
LDS	Pode chegar a tamanhos enormes (base do Db2)

💬 LDS é o campeão pesado, porque é usado por IBM Db2 for z/OS

---

⚠️ 🚨 Limitações reais (as que doem em produção)

Não é o “máximo teórico” que quebra você… é isso aqui:

• CI mal dimensionado → splits constantes
• CA splits → degradação absurda
• AIX mal planejado → performance despenca
• Buffer tuning errado → gargalo invisível

💥 Ou seja:
👉 Você raramente quebra por tamanho — quebra por design

---

🧪 💡 Resumo estilo Bellacosa

👉 Teoricamente:
VSAM é gigante (TBs)

👉 Na prática:
Seu VSAM vai até onde seu projeto aguenta

---

☕ 🔥 Provocação final

Você está preocupado com o tamanho máximo…

…mas já olhou quantos CA splits seu KSDS teve hoje? 😏

---

🔑 Quantos AIX (Alternate Indexes) um KSDS pode ter?

IBM z/OS

💥 Resposta direta:

Até 255 Alternate Indexes (AIX)

---

🧠 Mas calma… isso é o limite TEÓRICO

Na prática, você raramente — quase nunca — chega perto disso.

---

⚙️ Como isso funciona por baixo dos panos

Cada AIX é:

• Um VSAM KSDS separado
• Com seu próprio INDEX + DATA
• Ligado ao cluster base via PATH

👉 Ou seja:

Você não tem “um arquivo com vários índices”

Você tem vários datasets VSAM interligados

---

🧱 Estrutura lógica

BASE CLUSTER (KSDS)
   ↓
   ├── AIX 1
   ├── AIX 2
   ├── AIX 3
   └── ...

Cada AIX:

• Pode ter chave diferente
• Pode permitir duplicidade (ou não)
• Pode ter upgrade automático (ou não)

---

⚠️ 🚨 Limitações reais (as que ferram em produção)

Aqui está o que ninguém te conta:

1. 🔥 Overhead de UPDATE

Cada WRITE/REWRITE no KSDS:

👉 Atualiza TODOS os AIX associados

💥 Resultado:

• I/O explode
• CPU sobe
• Batch começa a sofrer

---

2. 🧨 Risco de inconsistência

Se você não usar:

• UPGRADE
• PATH corretamente definido

👉 Pode ficar com AIX desatualizado

---

3. 🐌 Performance degradada

Quanto mais AIX:

• Mais lookup indireto
• Mais leitura de INDEX
• Mais complexidade

---

4. 💽 Espaço em disco

Cada AIX = outro VSAM

👉 10 AIX ≠ leve

👉 50 AIX = você criou um “pseudo-DB maluco”

---

📊 Regra de ouro (mundo real)

Quantidade de AIX	Situação
1–3	👍 Saudável
4–10	⚠️ Cuidado
10+	🚨 Arquitetura suspeita
50+	💀 Você perdeu o controle
255	☠️ Experimento acadêmico

---

🧪 Exemplo IDCAMS (AIX)

DEFINE ALTERNATEINDEX(NAME(MEU.AIX1)
  RELATE(MEU.KSDS)
  KEYS(5 0)
  RECORDSIZE(80 80)
  UPGRADE)

E o PATH:

DEFINE PATH(NAME(MEU.PATH1)
  PATHENTRY(MEU.AIX1))

---

💡 Insight estilo Bellacosa

👉 VSAM permite até 255 AIX…

Mas isso NÃO significa que você deve usar.

💥 Se você precisa de muitos índices:

👉 talvez o problema não seja VSAM… é modelagem

---

☕ Provocação 

Se o seu KSDS tem muitos AIX…

Você está usando VSAM…

ou tentando recriar o IBM Db2 for z/OS na unha? 😏

-----------------------------------------------------------------------------------

💡 Reflexão final (estilo Bellacosa Mainframe)

Enquanto muita gente corre atrás da “nova tecnologia revolucionária”…

👉 O VSAM está lá:

• Processando milhões de transações
• Sem downtime
• Sem hype
• Sem marketing

💥 VSAM não é legado. Ele é o alicerce.

---

☕ Provocação final

Você realmente entende VSAM…
ou só sabe fazer READ NEXT sem dar ABEND?

 

Bellacosa Mainframe em um pequeno bate papo sobre segurança racf saf

🔥 SEU MAINFRAME ESTÁ SEGURO… OU SÓ PARECE?

A Verdade Crua da Segurança no z/OS (Do RACF ao Crypto Express)

---

☕ Introdução — Um Café com a Realidade

Se você acha que segurança no mainframe é “coisa do passado”, deixa eu te dar um choque de realidade:

O z/OS é um dos ambientes mais seguros do planeta — mas só quando bem configurado.

Porque na prática?

👉 O problema nunca foi a tecnologia
👉 O problema sempre foi quem configura

E é exatamente aqui que começa nossa jornada.

---

🕰️ Um pouco de história (e por que isso importa)

Nos anos 70, quando surgiram os primeiros sistemas corporativos massivos, a IBM percebeu algo:

“Se todo mundo acessa tudo… uma hora dá ruim.”

Nasce então o conceito de controle centralizado de acesso, que evolui para:

• RACF
• SAF
• E todo o ecossistema de segurança do z/OS

Enquanto o mundo distribuído ainda estava descobrindo autenticação…

👉 O mainframe já tinha segurança granular por recurso

---

🧠 O Coração da Segurança: SAF + RACF

Pensa nisso como um fluxo batch:

Usuário → SAF → RACF → decisão (ALLOW / DENY)

🧩 Quem faz o quê?

• SAF → interface (o “porteiro”)
• RACF → decisão (o “juiz”)

💡 Easter egg Bellacosa:

SAF nunca decide nada… ele só “encaminha o problema” 😄

---

🔐 O Mandamento Supremo: Least Privilege

Se você tiver que lembrar de UMA coisa:

“Dê o mínimo necessário — nunca o máximo possível.”

Exemplo clássico:

• Admin RACF → gerencia segurança
• Storage admin → só mexe em dataset

👉 Separação + privilégio mínimo = sistema saudável

---

💣 O ERRO QUE MAIS DERRUBA AMBIENTE

❌ PROTECTALL desligado

Sem isso:

Dataset sem perfil → acesso liberado 😱

👉 Simples assim.
👉 Sem perfil = sem segurança

💡 Curiosidade:
Muitos incidentes em mainframe não são ataques…
São configuração mal feita.

---

🔥 Criptografia no z/OS: Outro nível

Enquanto muita gente ainda “liga TLS”, o z/OS já faz:

🔐 Pervasive Encryption

• Dados em disco
• Dados em trânsito
• Dados protegidos sem mudar aplicação

---

🧬 A Hierarquia das Chaves (isso cai MUITO!)

Master Key → protege → Operational Key → protege → Data

Tipos importantes:

• Master Keys → topo da cadeia
• Symmetric → performance
• Asymmetric → troca segura
• Operational → uso diário

💡 Easter egg:

Se perder a master key… acabou o jogo.

---

⚙️ ICSF — O Tradutor da Criptografia

Aplicação nunca fala direto com hardware.

Ela fala com:

👉 ICSF

Que fala com:

👉 CPACF / Crypto Express

---

🛡️ Níveis de proteção (isso é ouro de prova)

Nível	Segurança
Clear Key	😬
Protected Key	👍
Secure Key	🔥🔥🔥

👉 Secure Key = dentro do hardware (Crypto Express)

---

💻 APF — Quem pode ser “superpoderoso”

Nem todo programa pode rodar com privilégio.

👉 Só quem está no APF

Programa fora do APF → sem privilégio
Programa no APF → modo supervisor

💡 Isso evita:

• código malicioso
• erro catastrófico

---

🌐 Rede no z/OS — Não é só TCP/IP

z/OS Communications Server

• TCP/IP (moderno)
• SNA (legado que ainda vive 😄)

Segurança:

• TLS → camada transporte
• IPSec → VPN (nível rede)

---

📊 SMF — O “log que conta tudo”

Se algo aconteceu:

👉 O SMF sabe

Mas atenção:

Nada é logado automaticamente se você não configurar

---

🧪 Caso real (estilo Bellacosa)

Empresa com:

• RACF instalado
• Criptografia ativa
• Auditoria configurada

Mas…

❌ PROTECTALL desligado
❌ UACC READ em datasets críticos

Resultado?

👉 Vazamento interno
👉 Sem ataque externo

💡 Moral:

Segurança não é tecnologia — é configuração.

---

🧠 Mentalidade Mainframe

Enquanto no mundo distribuído se fala:

“vamos adicionar segurança”

No mainframe é:

“vamos NÃO remover a segurança”

---

🔥 Frases pra tatuar no cérebro

• “SAF conecta, RACF decide”
• “Sem PROTECTALL, está exposto”
• “Sem chave, não há segurança”
• “ALL = mostra tudo”
• “SPECIAL = poder total (cuidado!)”

---

🏁 Conclusão — A Verdade Final

O z/OS não é seguro por acaso.

Ele é seguro porque:

• Foi projetado assim
• Evoluiu assim
• Exige disciplina

Mas…

Um mainframe mal configurado é tão vulnerável quanto qualquer outro sistema.

---

☕ Fechamento estilo Bellacosa

Segurança no mainframe não é só técnica.

É filosofia.

É controle.

É respeito ao sistema.

E principalmente:

É saber que o perigo não está fora… está dentro da configuração.

 

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