Translate

Mostrar mensagens com a etiqueta disaster recovery. Mostrar todas as mensagens
Mostrar mensagens com a etiqueta disaster recovery. Mostrar todas as mensagens

terça-feira, 28 de abril de 2026

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

 

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



quarta-feira, 22 de abril de 2026

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

 

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

 

quarta-feira, 8 de abril de 2026

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

 

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

 

domingo, 15 de fevereiro de 2026

🔥💀 DO CARTÃO PERFURADO AO COFRE NA MONTANHA

 

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