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 e o abend s837

☕🔥 ABEND S837 — O “CEMITÉRIO DOS DATASETS” NO z/OS

Quando o Mainframe Diz:

“EU NÃO CONSIGO ALOCAR ESSE DATASET.”

Se existe um ABEND que faz o Junior Padawan perceber que:

espaço em disco no mainframe é um ritual sagrado…

é o lendário:

🚨 S837

E normalmente ele aparece assim:

IEF450I JOBNAME STEP01 - ABEND=S837

ou:

SPACE ALLOCATION FAILED

ou ainda:

NO SPACE LEFT ON VOLUME

E então começa o caos existencial:

“O dataset não nasceu?”
“O disco acabou?”
“O SMS ficou bravo?”
“Meu SORT criou um buraco negro?”
“Como um mainframe GIGANTE pode ficar sem espaço?!”

☕ Respira.

Porque o S837 é um dos ABENDs MAIS IMPORTANTES para entender:

SPACE allocation

DASD

extents

SMS

secondary allocation

SORT work datasets

volumes z/OS

---

🔥 O QUE É O S837?

O S837 é um:

🚨 SPACE ALLOCATION FAILURE

Traduzindo:

O z/OS NÃO CONSEGUIU ENCONTRAR ESPAÇO EM DISCO PARA O DATASET.

---

☕ A FILOSOFIA DO S837

No mainframe:

datasets ocupam espaço físico controlado rigorosamente.

Nada é “solto” como em PCs modernos.

Tudo precisa de:

• cylinders

• tracks

• extents

• volumes

• allocation units

---

🔥 ANALOGIA BELLACOSA MAINFRAME

Imagine um estacionamento corporativo.

Seu caminhão chega precisando:

50 vagas contínuas.

Mas:

• estacionamento lotado

• vagas fragmentadas

• limite atingido

Resultado:

❌ sem espaço.

Isso é o:

☠️ S837

---

🔥 O GRANDE SEGREDO

S837 NÃO significa necessariamente:

“acabou disco no datacenter.”

Frequentemente significa:

não existe espaço adequado para aquela alocação.

---

☕ O MOMENTO EXATO DO S837

Fluxo:

JCL solicita dataset
 ↓
z/OS tenta alocar espaço
 ↓
DASD/SMS procura área livre
 ↓
Falha
 ↓
S837

---

🔥 O MAIOR VILÃO DO S837

🚨 SPACE MAL DIMENSIONADO

O clássico absoluto.

---

☕ EXEMPLO JCL

//OUTFILE DD DSN=TESTE.ARQ,
// SPACE=(CYL,(5000,5000))

Mas o volume NÃO possui isso disponível.

Resultado:

💥 S837

---

🔥 O SORT DA MORTE

Lenda absoluta do z/OS.

---

☕ EXEMPLO

//SORTWK01 DD UNIT=SYSDA,SPACE=(CYL,(9999,9999))

DFSORT tenta criar work datasets gigantescos.

O disco entra em sofrimento espiritual.

Resultado:

☠️ S837

---

🔥 O S837 E O “SECONDARY SPACE”

Agora nasce o conhecimento Jedi.

---

☕ PRIMARY SPACE

Espaço inicial.

---

☕ SECONDARY SPACE

Expansão dinâmica.

---

🔥 O PROBLEMA

Primary cabe.

Mas durante crescimento:

secondary allocation falha

Resultado:

💥 S837

---

☕ O S837 FANTASMA

O mais traiçoeiro.

Job roda:

30 minutos normal

E explode depois.

Porque dataset cresceu além do previsto.

---

🔥 O S837 E O “EXTENTS”

Modo arquimago ativado.

---

☕ O QUE É EXTENT?

Bloco contínuo de espaço em disco.

Datasets possuem limite de extents.

---

🔥 O DRAMA

Disco possui espaço.

Mas fragmentado demais.

Sistema não consegue criar novo extent adequado.

Resultado:

☠️ S837

---

☕ O S837 E O SMS

Hoje muitos ambientes usam:

SMS (Storage Management Subsystem)

Ele decide:

• volume

• classe

• performance

• gerenciamento

Políticas SMS inadequadas podem causar:

💥 S837

---

🔥 O S837 E O GDG

Outro clássico.

Gerações antigas:

• não apagadas

• acumuladas

• espaço esgotado

Nova geração tenta nascer.

Resultado:

☠️ S837

---

☕ O S837 E O RLSE

Parâmetro mágico:

RLSE

Libera espaço não usado ao final do job.

Sem isso:

desperdício silencioso.

---

🔥 O S837 E O UNIT=SYSDA

Outro cenário clássico.

Todos jobs disputando:

mesmos volumes.

Ambiente congestionado.

Resultado:

💥 falha de alocação.

---

☕ O S837 E O DB2

Utilities DB2 podem gerar datasets temporários gigantes:

• SORT

• REORG

• UNLOAD

• LOAD

Space errado?

☠️ S837

---

🔥 O S837 E O CICS

Menos comum diretamente.

Mas logs/journals/datasets auxiliares também podem sofrer.

---

☕ O S837 E O “VOLUME FULL”

Às vezes o volume realmente está:

LOTADO.

Operador olha:

D U,VOL=XXXX

E percebe:

sem espaço restante.

---

🔥 COMO INVESTIGAR O S837 PASSO A PASSO

---

✅ PASSO 1 — VERIFIQUE JESMSGLG

Procure:

S837
SPACE ALLOCATION FAILED
B37
E37

---

✅ PASSO 2 — IDENTIFIQUE O DDNAME

Qual dataset falhou?

SORTWK01
OUTFILE
TEMP001

---

✅ PASSO 3 — ANALISE SPACE=

Veja:

SPACE=(CYL,(x,y))

ou:

SPACE=(TRK,(x,y))

---

✅ PASSO 4 — VERIFIQUE VOLUME

Talvez:

• cheio

• fragmentado

• limitado

---

✅ PASSO 5 — VERIFIQUE EXTENTS

Datasets podem atingir:

limite máximo de extents.

---

🔥 O SEGREDO DOS B37/E37

Parentes sombrios do S837.

---

☕ B37

Sem espaço durante escrita.

---

☕ E37

Sem extents disponíveis.

---

☕ S837

Falha de alocação/expansão.

---

🔥 O DUMP DO S837

Normalmente pouco útil.

O ouro está em:

• mensagens IEC

• SMS reports

• allocation messages

• JESMSGLG

---

☕ MENSAGENS IMPORTANTES

---

☕ IEC030I

Problemas de espaço/extents.

---

☕ IEC070I

Falha de allocation.

---

☕ IGDxxxx

Mensagens SMS.

---

🔥 O MAIOR ERRO DO PADAWAN

Resolver tudo assim:

SPACE=(CYL,(9999,9999))

Agora o job pede:

MAIS ESPAÇO DO QUE O DATACENTER POSSUI.

---

☕ O VERDADEIRO JEDI

Não apenas aumenta espaço.

Ele pergunta:

“QUAL O CRESCIMENTO REAL DO DATASET?”

---

🔥 COMO EVITAR S837

---

✅ Dimensionar SPACE corretamente

---

✅ Revisar secondary allocation

---

✅ Usar RLSE

---

✅ Monitorar SORTs gigantes

---

✅ Limpar GDGs antigos

---

✅ Revisar SMS classes

---

✅ Evitar datasets monstruosos desnecessários

---

✅ Monitorar extents

---

☕ O SEGREDO DOS VETERANOS

Veteranos respeitam profundamente:

SPACE planning.

Porque no z/OS:

storage físico ainda importa MUITO.

---

🔥 CURIOSIDADE HISTÓRICA

Nos anos 60/70:

discos eram:

• pequenos

• caríssimos

• lentos

Programadores literalmente calculavam:

trilhas e cilindros manualmente.

O S837 nasceu dessa realidade brutal.

---

☕ EASTER EGG MAINFRAME

Veteranos brincam:

“S837 significa:

Seu Dataset Tentou Crescer Mais do Que o Universo Permitia.”

---

🔥 O MAIOR ENSINAMENTO DO S837

Ele ensina algo profundo:

no z/OS, armazenamento é engenharia matemática.

Não basta:

“salvar arquivo”

É preciso entender:

• cylinders

• tracks

• extents

• SMS

• crescimento

• fragmentação

• alocação física

---

☕ A VERDADE FINAL

O S80A pune falta de memória.
O S878 pune fragmentação de storage virtual.
O S913 pune falta de autorização.

Mas…

☕ O S837 É O MOMENTO EM QUE O z/OS OLHA PARA O DISCO… E DESCOBRE QUE NÃO EXISTE MAIS ESPAÇO ADEQUADO PARA O SEU DATASET NASCER.

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 ☕🖥️

Bellacosa Mainframe o que é dasd

 

O que é DASD?

Quando alguém começa a estudar armazenamento no mainframe, rapidamente encontra a sigla:

DASD

Ela é uma das bases do ambiente z/OS.

Praticamente tudo no mainframe depende disso:

• datasets;

• JCL;

• COBOL;

• bancos de dados;

• spool;

• sistemas corporativos.

---

O que significa DASD?

DASD significa:

Direct Access Storage Device

Em português:

Dispositivo de Armazenamento de Acesso Direto

---

Definição simples

O DASD é o dispositivo de disco usado pelo mainframe para armazenar dados.

Ele funciona como:

o “HD corporativo” do z/OS.

Mas em escala muito maior, mais rápida e extremamente confiável.

---

Uma analogia fácil

Imagine:

• um notebook possui SSD;

• um servidor possui storage;

• o mainframe possui DASD.

O DASD é onde ficam armazenados:

• datasets;

• programas;

• bibliotecas;

• bancos de dados;

• arquivos batch.

---

O que significa “acesso direto”?

Significa que o sistema consegue acessar:

qualquer ponto do disco diretamente.

Sem precisar ler tudo em sequência.

---

Analogia

Imagine um livro.

---

Acesso sequencial

Você precisa virar página por página até encontrar algo.

---

Acesso direto

Você abre exatamente na página desejada.

---

Isso torna o DASD muito eficiente

Especialmente para:

• grandes bancos;

• milhões de registros;

• sistemas financeiros.

---

O DASD é um HD comum?

Não.

Ele foi criado para:

• alta performance;

• enorme capacidade;

• redundância;

• ambientes críticos.

---

O que fica armazenado no DASD?

Praticamente tudo do z/OS.

---

Exemplos

• datasets;

• PDS;

• PDSE;

• VSAM;

• bibliotecas COBOL;

• JCL;

• DB2;

• logs;

• SYSOUT;

• arquivos batch.

---

Como o z/OS organiza o DASD?

O armazenamento possui vários conceitos importantes:

---

Volume

Cada disco possui um nome.

Exemplo:

VOL001

---

Dataset

Arquivo armazenado no DASD.

---

Catálogo

Sistema que informa:

• onde o dataset está;

• em qual volume;

• atributos.

---

Como era o DASD antigamente?

Nos primeiros mainframes:

• enormes discos físicos;

• pratos magnéticos gigantes;

• equipamentos muito pesados.

Alguns pareciam:

máquinas de lavar industriais.

---

Hoje tudo evoluiu

Os DASDs modernos são:

• extremamente rápidos;

• compactos;

• virtualizados;

• integrados com storages avançados.

---

O DASD ainda usa disco magnético?

Em muitos casos:
sim.

Mas atualmente existem:

• SSD corporativo;

• cache avançado;

• virtualização;

• storage híbrido.

---

Como datasets ficam no DASD?

Exemplo:

USUARIO.JCL(MYJOB)

Esse dataset ocupa espaço físico dentro de um volume DASD.

---

O que é cilindro e trilha?

O DASD tradicional organiza espaço em:

---

Track (trilha)

Menor unidade física.

---

Cylinder (cilindro)

Grupo de trilhas alinhadas.

---

Isso ainda aparece no z/OS?

Sim.

Muitos JCLs usam:

SPACE=(CYL,(1,1))

ou:

SPACE=(TRK,(10,5))

---

O que isso significa?

---

CYL

Alocação em cilindros.

---

TRK

Alocação em trilhas.

---

O que é I/O?

Input/Output.

Toda leitura ou gravação no DASD gera operações de I/O.

---

Por que performance do DASD é importante?

Porque bancos e sistemas financeiros processam:

• milhões;

• bilhões de acessos.

Performance ruim afetaria:

• PIX;

• cartões;

• transações;

• batch.

---

O que é cache de DASD?

Memória rápida usada para acelerar leitura e gravação.

---

O que é SMS?

SMS significa:

System Managed Storage

Sistema do z/OS que automatiza:

• alocação;

• gerenciamento;

• políticas de armazenamento.

---

Hoje muitos DASDs são gerenciados automaticamente

O usuário nem sempre escolhe o volume manualmente.

---

O que é um storage mainframe?

É a infraestrutura que controla:

• DASD;

• volumes;

• replicação;

• backup;

• performance.

---

O que é replicação?

Cópia automática de dados para:

• redundância;

• disaster recovery;

• alta disponibilidade.

---

Curiosidades incríveis

1. Mainframes armazenam volumes gigantescos de dados

Muitos bancos possuem petabytes.

---

2. DASD existe há décadas

E continua evoluindo.

---

3. O conceito de cilindro vem dos discos físicos antigos

Mesmo hoje ainda aparece no z/OS.

---

4. Performance de storage é crítica no mundo financeiro

Milissegundos fazem diferença.

---

Erros comuns de iniciantes

---

1. Pensar que DASD é apenas “HD antigo”

Na verdade é storage corporativo extremamente avançado.

---

2. Ignorar SPACE em JCL

Isso pode causar falhas de alocação.

---

3. Confundir volume com dataset

Volume = disco
Dataset = arquivo

---

4. Achar que tudo está apenas em nuvem

Grande parte da infraestrutura financeira ainda depende de DASD físicos.

---

Como visualizar informações do DASD?

Via:

• ISPF;

• LISTDS;

• IDCAMS;

• SDSF;

• ferramentas de storage.

---

Exemplo de LISTDS

LISTDS 'USUARIO.JCL'

Mostra:

• volume;

• RECFM;

• LRECL;

• espaço.

---

Como DASD aparece no dia a dia?

Em praticamente tudo:

• COBOL;

• JCL;

• VSAM;

• DB2;

• SORT;

• batch;

• backups.

---

Por que aprender DASD?

Porque ele é:

a base física do armazenamento no z/OS.

Quem entende DASD entende:

• datasets;

• performance;

• storage;

• arquitetura do mainframe.

---

Resumo rápido

Conceito	Significado
DASD	Disco do mainframe
Volume	Nome do disco
Dataset	Arquivo
Track	Trilha
Cylinder	Grupo de trilhas
I/O	Leitura/gravação
SMS	Gerenciamento automático

---

Conclusão

O DASD é um dos componentes mais importantes do ambiente mainframe IBM Z.

Ele fornece armazenamento corporativo de alta performance para datasets, bancos de dados e aplicações críticas do z/OS.

Mesmo após décadas de evolução tecnológica, continua sendo peça essencial da infraestrutura que sustenta bancos, governos e grandes corporações no mundo inteiro.