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

 

💣 LAB MASTER 🔥 Storage Não Armazena — Ele Decide o Destino do Dado

 

Bellacosa Mainframe Treine Storage Mainframe

💣 LAB MASTER

🔥 Storage Não Armazena — Ele Decide o Destino do Dado

---

🎯 Objetivo do LAB

Ao final você será capaz de:

• Entender como o SMS decide storage
• Criar datasets com e sem striping
• Simular impacto de RAID (conceitual)
• Trabalhar com DASD vs Tape
• Ver migração automática (HSM ML1/ML2)
• Executar backup e restore
• Entender o papel do air gap

---

🏗️ Cenário

Você é responsável por:

• Um ambiente com:
  • DASD (disco)
  • Flash (simulado via classe)
  • Tape (ML2)
• Workloads:
  • Batch pesado
  • Dados críticos
  • Arquivos de archive

---

🧪 LAB 1 — Alocação sem SMS (controle manual)

🎯 Objetivo

Sentir o “mundo antigo”

//STEP1 EXEC PGM=IEFBR14
//DD1   DD DSN=USER.TEST.MANUAL,
//      DISP=(NEW,CATLG),
//      UNIT=3390,
//      SPACE=(CYL,(10,5))

🧠 O que observar:

• Você escolhe tudo manualmente
• Sem inteligência

---

🧪 LAB 2 — Alocação com SMS

🎯 Objetivo

Ver o SMS em ação

//STEP1 EXEC PGM=IEFBR14
//DD1   DD DSN=USER.TEST.SMS,
//      DISP=(NEW,CATLG),
//      DATACLAS=STANDARD,
//      STORCLAS=FAST,
//      MGMTCLAS=BACKUP

🧠 O que observar:

• Nenhum volume definido
• SMS decide tudo

---

🧪 LAB 3 — Striping (performance)

🎯 Objetivo

Simular I/O paralelo

👉 Criar Data Class com:

• Stripe Count = 4

//STEP1 EXEC PGM=IEFBR14
//DD1 DD DSN=USER.TEST.STRIP,
//     DISP=(NEW,CATLG),
//     DATACLAS=STRIPE4

🧠 Observe:

• Dataset distribuído
• Performance maior

---

🧪 LAB 4 — RAID (conceitual via comportamento)

🎯 Objetivo

Entender impacto sem ver RAID direto

Teste:

• Dataset pequeno vs grande
• Com e sem striping

👉 Analise:

• Tempo de execução
• I/O count

💡 Insight:

RAID está por baixo — você vê o efeito, não a configuração

---

🧪 LAB 5 — Tape (gravação)

🎯 Objetivo

Gravar em fita

//STEP1 EXEC PGM=IEBGENER
//SYSPRINT DD SYSOUT=*
//SYSUT1   DD DSN=USER.TEST.SMS,DISP=SHR
//SYSUT2   DD DSN=USER.TEST.TAPE,
//         DISP=(NEW,CATLG),
//         UNIT=TAPE,
//         VOL=SER=TAPE01

🧠 Observe:

• Acesso sequencial
• Tempo maior

---

Bellacosa Mainframe apresenta leitor cartrige com braço robotico

🧪 LAB 6 — HSM (migração automática)

🎯 Objetivo

Ver dados indo para tape

Comando:

HSEND MIGRATE DATASET('USER.TEST.SMS')

🧠 Resultado:

• ML1 → disco
• ML2 → tape

---

Bellacosa Mainframe apresenta antigo leitor tape para mainframe mvs 

🧪 LAB 7 — Recall (volta do tape)

//STEP1 EXEC PGM=IEFBR14
//DD1 DD DSN=USER.TEST.SMS,DISP=SHR

🧠 Observe:

• Dataset volta do tape
• Delay perceptível

---

🧪 LAB 8 — Backup

🎯 Objetivo

Criar cópia de segurança

//STEP1 EXEC PGM=ADRDSSU
//SYSPRINT DD SYSOUT=*
//DUMP DD DSN=USER.BACKUP.TAPE,
//     UNIT=TAPE,
//     DISP=(NEW,CATLG)
//SYSIN DD *
 DUMP DATASET(USER.TEST.SMS) -
      OUTDD(DUMP)
/*

---

🧪 LAB 9 — Simulação de desastre

🎯 Objetivo

Recuperação

//STEP1 EXEC PGM=ADRDSSU
//SYSPRINT DD SYSOUT=*
//DUMP DD DSN=USER.BACKUP.TAPE,DISP=SHR
//SYSIN DD *
 RESTORE DATASET(USER.TEST.SMS) -
         INDD(DUMP)
/*

---

🧪 LAB 10 — Air Gap (conceito aplicado)

🎯 Objetivo

Entender proteção real

👉 Cenário:

• Dataset corrompido
• Backup online comprometido

👉 Recuperação:

• Apenas via tape

💡 Insight:

Aqui você entende por que tape ainda existe

---

🧠 Fechamento técnico

Você acabou de trabalhar com:

• DASD (3390)
• SMS (policy-driven storage)
• Striping (performance)
• RAID (efeito indireto)
• Tape (sequencial)
• HSM (automação)
• Backup/Restore
• Air Gap (segurança real)

---

☕ Bellacosa-style conclusão

“Você não manipulou disco…
você manipulou decisões sobre onde o dado vive, se move… e sobrevive.”

 

 

Bellacosa Mainframe num mergulho no mundo storage do z/os

🔥 SEUS DADOS NÃO MORAM NO DISCO… ELES VIAJAM PELO UNIVERSO DO z/OS 😳

O guia proibido de Storage Management que revela como memória, disco e sysplex trabalham juntos (e quase ninguém entende)

Você acha que seu dataset “fica no disco”?

👉 Não fica.

No z/OS, dados:

• sobem pra memória
• descem pra disco
• migram pra fita
• aparecem em outro LPAR
• e até existem fora do seu address space

💥 “No mainframe, dado não tem endereço fixo… tem estratégia.”

Se você quer sair do nível “usuário” e pensar como engenheiro de sistema, esse é o mapa completo 👊🔥

---

🧠 1. ADDRESS SPACE — O UNIVERSO DO PROGRAMA

Cada programa roda em um address space isolado.

---

🔥 O que isso significa?

• memória protegida
• ambiente independente
• controle total do sistema

---

💡 Insight

cada address space é um “universo privado”

---

⚡ 2. 64-BIT ADDRESSING — MEMÓRIA INFINITA (QUASE)

Com 64 bits:

👉 até 16 EXABYTES

---

🔥 Evolução histórica

Era	Limite
24-bit	16MB 😱
31-bit	2GB
👉 64-bit	16EB 🤯

---

💡 Tradução Bellacosa

“acabou a desculpa de falta de memória”

---

🧠 Uso real

• Java
• Db2
• middleware
• grandes buffers

---

🧩 3. DAT — A MÁGICA DA TRADUÇÃO

DAT (Dynamic Address Translation):

👉 converte endereço virtual → real

---

🔥 Sem DAT:

• programa quebraria
• memória não funcionaria

---

💡 Tradução

“você nunca acessa memória real diretamente”

---

🧠 4. STORAGE REQUESTS — COMO A MEMÓRIA É PEDIDA

Programas pedem memória via:

• GETMAIN
• STORAGE OBTAIN

---

🔥 O sistema decide:

• onde alocar
• em qual subpool
• com qual proteção

---

💡 Insight

memória é gerenciada, não livre

---

🧱 5. SUBPOOLS — ORGANIZAÇÃO INTERNA

Memória é dividida em:

👉 subpools

---

🔥 Exemplos:

• SP0 → sistema
• SP229 → usuário

---

💡 Tradução

“cada tipo de dado tem seu bairro”

---

🌍 6. DATA SPACES & HIPERSPACES — FORA DO ADDRESS SPACE

🔹 Data Spaces

• dados fora do address space
• acessados via AR

---

🔹 Hiperspaces

• alta performance
• acesso indireto

---

🔥 Tradução Bellacosa

“memória extra fora do seu universo”

---

🧠 Exemplo

Programa → usa Data Space → grande volume de dados

---

⚡ 7. PAGING — QUANDO A MEMÓRIA NÃO CABE

Se falta memória:

👉 dados vão para disco (paging)

---

🔥 Fluxo

Memória cheia
 ↓
página vai para DASD
 ↓
quando necessário → volta

---

💡 Problema

👉 excesso de paging = sistema lento 💀

---

💾 8. FLASH STORAGE — O TURBO MODERNO

Flash (SSD):

• baixa latência
• alta velocidade
• ideal para OLTP

---

💡 Uso

• Db2
• logs
• datasets críticos

---

🔗 9. PARALLEL SYSPLEX — MEMÓRIA COMPARTILHADA ENTRE SISTEMAS

Aqui fica poderoso 😄

---

🔥 O que é?

Vários z/OS trabalhando juntos:

👉 como um só sistema

---

💡 Elementos:

• LPARs
• Coupling Facility (CF)
• links de comunicação

---

🧠 Exemplo

LPAR A → acessa dado
LPAR B → acessa o mesmo dado

---

💡 Tradução

“dados compartilhados em tempo real”

---

🧠 10. COUPLING FACILITY (CF) — O CÉREBRO COMPARTILHADO

🔹 Função:

• lock management
• cache
• filas

---

🔥 Tipos:

• Internal CF
• External CF

---

💡 Tradução Bellacosa

“CF = memória compartilhada do sysplex”

---

⚡ 11. DUPLEXING — ZERO PERDA

🔥 O que faz?

• duplica dados
• garante disponibilidade

---

💡 Exemplo

CF primário → falha
CF secundário → assume

---

🧨 Curiosidade

Sistema continua rodando sem impacto 😳

---

🧠 12. CF OPERATIONS — O QUE ACONTECE POR TRÁS

CF gerencia:

• locks
• buffers
• filas

---

💡 Uso real

• Db2 data sharing
• CICS
• IMS

---

⚙️ 13. STORAGE + I/O + CPU — TUDO CONECTADO

Nada funciona isolado:

Memória → I/O → CPU → WLM → Storage

---

💡 Insight

performance é resultado do conjunto

---

🔄 14. PASSO A PASSO COMPLETO

Programa inicia
 ↓
recebe address space
 ↓
pede memória (GETMAIN)
 ↓
DAT traduz endereço
 ↓
usa data space se necessário
 ↓
paging ocorre se faltar memória
 ↓
dados vão para disco/flash
 ↓
sysplex compartilha dados via CF
 ↓
duplex garante disponibilidade

---

🧨 CURIOSIDADES (NÍVEL ROOT)

🤯 1. Você não controla diretamente onde o dado está

---

🔥 2. Dados podem estar fora do seu address space

---

💀 3. Paging excessivo mata performance

---

🧠 4. Sysplex permite vários sistemas compartilharem dados

---

⚡ 5. CF é o segredo da alta disponibilidade

---

🎯 RESUMO FINAL

✔ Address space = isolamento

✔ 64-bit = escala absurda

✔ DAT = tradução

✔ Subpools = organização

✔ Data space = expansão

✔ Paging = fallback

✔ Flash = velocidade

✔ Sysplex = escala

✔ CF = coordenação

✔ Duplexing = resiliência

---

💥 FRASE FINAL

“No z/OS, dados não ficam armazenados… eles são orquestrados entre memória, disco e múltiplos sistemas em tempo real.”

Bellacosa Mainframe apresenta Storage Management no IBM z/OS

---

🧱 IBM Mainframe Storage Management no z/OS

DFSMS, SMS x non-SMS, ISMF, ACS, DASD, TAPE, JCL, VSAM, PS e PO

O disco não é só espaço. É política, disciplina e sobrevivência.

---

☕ Introdução – Quando o disco manda mais que o código

Todo mainframe nasce vazio.
Nenhum COBOL roda, nenhum CICS responde, nenhum batch fecha balanço sem que alguém tenha decidido onde os dados vão morar.

E é aqui que muita gente erra:

“Ah, storage é só pedir espaço no JCL…”

❌ Errado.
No IBM Mainframe, storage é governança, automação, história, política corporativa e, muitas vezes, briga silenciosa entre times.

Este artigo é para você que:

• Já sofreu com SMS override

• Já ouviu “o ACS mandou”

• Já viu dataset ir parar num disco que você nem sabia que existia

• Ou ainda acha que VOL=SER ainda manda em tudo

Senta, pega o café, que a aula começa agora.

---

🏛️ Origem e História – Do ferro bruto ao cérebro automático

📼 Anos 60–70: tudo era manual

• Disco era caro

• Poucos volumes

• Programador escolhia tudo

• Erro humano era rotina

💣 Anos 80: o caos

• Explosão de dados

• Batch gigante

• Fragmentação absurda

• Discos cheios às 03:00 da manhã

🧠 Anos 90: nasce o DFSMS

A IBM percebeu:

“Não dá para deixar cada programador decidir disco.”

Surge o DFSMS (Data Facility Storage Management Subsystem).

Objetivo:

• Padronizar

• Automatizar

• Controlar

• Evitar desastre operacional

📌 DFSMS não é luxo. É resposta ao caos.

---

🧠 DFSMS – O cérebro do armazenamento no z/OS

DFSMS é:

• Parte nativa do z/OS

• Gerente de dados

• Juiz das decisões de disco

• Guarda-costas da infraestrutura

Ele cuida de:

• DASD

• TAPE

• Migração

• Backup

• Alocação

• Performance

• Disponibilidade

---

💽 DASD – O chão onde tudo pisa

DASD = Direct Access Storage Device

Tradução Bellacosa:

“É o HD do mainframe, só que sério.”

Tudo mora em DASD:

• z/OS

• SYS1

• Aplicações

• VSAM

• Logs

• Catálogos

📌 Volume = Disco = DASD

Exemplos reais:

PRD001
TSO123
CICS45

---

📼 TAPE – O ancião que ainda reina

Muita gente subestima, mas:

• Tape é barato

• Tape é denso

• Tape é confiável

• Tape é rei do backup

DFSMS controla:

• Migração HSM

• Recall automático

• Arquivamento

📌 Easter egg:
Muitos bancos ainda têm dados mais velhos que o programador, morando felizes em fita.

---

🧩 SMS x non-SMS – O conflito eterno

🔴 Non-SMS (old school)

Você manda:

• VOL=SER

• SPACE

• UNIT

Vantagem:

• Controle total

Desvantagem:

• Risco total

📌 Hoje: usado só em casos muito específicos.

---

🟢 SMS-Managed (mundo real)

O sistema manda.

Você pede:

• Nome do dataset

O SMS decide:

• Onde fica

• Quanto espaço

• Performance

• Migração

📌 Naming convention é lei.

---

🧬 ACS – O código que manda mais que o JCL

ACS Routine = cérebro do SMS

Ela decide:

• Data Class

• Storage Class

• Storage Group

Baseado em:

• Nome do dataset

• Usuário

• Programa

• Ambiente

Exemplo simplificado:

IF &DSN = 'PRD.*'
   SET &STORCLAS = 'HIGH'

💣 Easter egg cruel:

Você pode pedir CYL(1000).
O ACS pode te dar TRK(10).
E ainda sorrir.

---

🖥️ ISMF – Onde o poder mora

ISMF = Interactive Storage Management Facility

Ferramenta do:

• Storage admin

• Infra

• Arquitetura

Aqui você vê:

• Volumes

• Classes

• Storage Groups

• ACS

• Espaço real

📌 Programador geralmente não entra aqui.

---

🧱 Data Class – O DNA do dataset

Define:

• RECFM (FB, VB…)

• LRECL

• DSORG

Exemplo:

RECFM=FB
LRECL=80
DSORG=PS

📌 Template padrão corporativo.

---

🚀 Storage Class – Performance e SLA

Define:

• Prioridade

• Backup

• Migração

• Disponibilidade

📌 Onde o negócio fala mais alto que o código.

---

🗄️ Storage Group – O endereço físico

• Conjunto de volumes

• Abstração total

• Usuário não escolhe disco

📌 Você não precisa saber qual disco.
📌 O SMS sabe.

---

📂 Tipos de Data Set – PS, PO, VSAM

📄 PS (Sequential)

• Batch

• Relatórios

• Entrada/Saída simples

---

📚 PO / PDS / PDSE

• Código

• JCL

• Copybooks

📌 PDSE > PDS (sempre que possível).

---

🧬 VSAM

• KSDS

• ESDS

• RRDS

Alta performance, alta complexidade.

📌 VSAM mal dimensionado = pesadelo.

---

📜 JCL x DFSMS – Quem manda?

JCL pede.
DFSMS decide.

Exemplo clássico:

SPACE=(CYL,(100,50))

Resultado:

SPACE=(TRK,(10,5))

Mensagem:

“Some attributes were overridden by ACS routine.”

📌 Tradução:

“Você tentou. Eu mandei.”

---

🧪 Passo a passo prático (vida real)

1. Dataset criado

2. ACS roda

3. Classes atribuídas

4. Volume escolhido

5. Espaço ajustado

6. Catálogo atualizado

Tudo automático.

---

🧙‍♂️ Dicas Bellacosa Mainframe

✔ Naming convention é tudo
✔ Nunca confie só no JCL
✔ Leia o ACS antes de reclamar
✔ ISMF é seu melhor amigo
✔ Storage admin é aliado, não inimigo
✔ PDSE sempre que possível
✔ VSAM exige respeito

---

🥚 Easter Eggs & Curiosidades

🥚 Existem ACS routines com 20+ anos em produção
🥚 Já houve banco parado porque alguém mexeu no ACS sem change
🥚 Muitos datasets “fantasmas” existem só porque ninguém sabe quem usa
🥚 Tape ainda salva mais empresa que cloud hype

---

☕ Conclusão – A frase que resume tudo

“No mainframe, código faz o sistema funcionar.
Storage faz o negócio sobreviver.”

Se quiser, posso:

• 📚 Transformar isso em curso

• 🧪 Criar labs práticos

• 🎓 Adaptar para aula corporativa

• 🔐 Criar versão bancária real

• 📊 Montar mapa mental DFSMS

Só chamar.
O café está quente ☕🖥️