| Bellacosa Mainframe e o storage em mainframe evolução do armazenamento |
☕💥 DASD, Flash e a Imortalidade do 3390
Ou como a IBM convenceu o z/OS de que ainda estamos em 1989 enquanto gravamos dados em NVMe mais rápido que um caça de quinta geração
Introdução
Existe uma lenda urbana entre desenvolvedores Mainframe.
Dizem que em algum lugar dentro de um DS8950F existe um pequeno senhor de barba branca usando suspensórios, fumando cachimbo e respondendo:
"Sim, z/OS. Eu ainda sou um 3390."
E o mais assustador?
Ele está dizendo a verdade.
Enquanto boa parte da indústria de TI troca tecnologias como quem troca de smartphone, o Mainframe possui uma filosofia bastante diferente.
Ele não descarta tecnologias.
Ele as absorve.
Encapsula.
Virtualiza.
Esconde atrás de interfaces estáveis.
E permite que programas COBOL escritos durante o Governo Sarney continuem funcionando em um IBM z17 sem perceber que o disco físico que armazena seus arquivos está centenas de milhares de vezes mais rápido.
Hoje vamos tomar um café forte e explorar a evolução do armazenamento IBM Z.
| Bellacosa Mainframe e o disco fisico no mundo mainframe |
O que é DASD?
DASD significa:
Direct Access Storage Device
Foi o nome adotado pela IBM para dispositivos de armazenamento de acesso direto.
Na prática:
HDs Mainframe
SSDs Mainframe
Volumes virtuais
Flash arrays
No universo z/OS tudo continua sendo chamado simplesmente de:
DASD
Mesmo que não exista mais nenhum disco girando.
| Bellacosa Mainframe e a evolução do storage no Mainframe |
A Pré-história
2305
Ano: 1970
Capacidade:
5 MB
Tecnologia:
Disco removível
Tempo acesso:
30 ms
3330 Merlin
1971
Capacidade:
100 MB
RPM:
3600
3350
1975
317 MB
O gigante dos anos 80
IBM 3380
Lançamento:
1980
Capacidade:
2,52 GB
Velocidade:
3600 rpm
Track:
47.476 bytes
15 tracks/cylinder
Peso:
Mais de 500 kg
Era praticamente uma geladeira industrial.
O rei absoluto
IBM 3390
Ano
1989
Track Size
56.664 bytes
Tracks
15
Cylinder
849.960 bytes
≈0,81 MB
Modelos
| Modelo | Cyl | Capacidade |
|---|---|---|
| 1 | 1113 | 0,9 GB |
| 2 | 2226 | 1,8 GB |
| 3 | 3339 | 2,7 GB |
| 9 | 10017 | 8 GB |
| 27 | 32760 | 26 GB |
| 54 | 65520 | 54 GB |
Como calcular espaço
Cyl = 15 trilhas
Track = 56664
Exemplo
100 cylinders
100 × 849960
84 MB
aproximadamente
Como o z/OS enxerga discos
Programa COBOL:
SELECT CLIENTE
ASSIGN TO CLIENTE.
FD CLIENTE.
01 REG-CLI.
05 CODIGO PIC 9(9).
05 NOME PIC X(50).
Nada aqui sabe se o dado está em:
3390
SSD
NVMe
DS8000
Cloud
Absolutamente nada.
O truque da IBM
Hoje usamos:
DS8880
DS8910
DS8950
DS8A10
DS8A50
Mas o z/OS continua vendo:
3390-54
ou
3390-A
Virtual.
A era DS8000
DS8000
Ano
2004
Foi revolucionário.
Trouxe:
FICON
RAID
Cache enorme
Tiering
Snapshots
Replication
DS8880
2015
Até centenas de TB
Flash
Easy Tier
DS8950F
Flash puro.
NVMe
Microsegundos de latência.
Como funciona internamente
Aplicação
↓
VSAM
↓
Catalog
↓
SMS
↓
Volume
↓
DS8000
SMS
Storage Management System
Possui:
ACS
Storage Class
Data Class
Management Class
Exemplo
STORCLAS
FAST
MGMTCLAS
BACKUP30
Exemplo JCL
//STEP1 EXEC PGB=IEFBR14
//ARQ DD
DSN=VAGNER.TESTE
DISP=(NEW,CATLG)
SPACE=(CYL,(100,20))
UNIT=3390
DCB=(RECFM=FB,LRECL=80)
Observe
UNIT=3390
Mesmo em 2026.
VSAM
KSDS
ESDS
RRDS
LDS
IDCAMS
//DEF EXEC PGB=IDCAMS
//SYSIN DD *
DEFINE CLUSTER(
NAME(CLIENTE.KSDS)
VOLUMES(VOL001)
TRACKS(100 20)
)
/*
Onde monitorar uso
ISPF
3.4
Volume
SDSF
DA
DEV
IDCAMS
LISTCAT
LISTCAT ENT(CLIENTE.KSDS)
DFSMS
DCOLLECT
RMF
RMF Monitor III
SMF
42
74
78
Comandos úteis
D U,VOL=SER001
LISTVTOC
LISTCAT
Curiosidade
52 GB parecia enorme.
Hoje um smartphone possui:
512 GB
Dez vezes mais.
Mas...
Um smartphone não processa
PIX
Bolsa
INSS
Cartões
Compensação bancária
para milhões de pessoas.
Flash
Flash eliminou:
Seek time
Rotação
Head movement
Antes
10 ms
Hoje
100 microsegundos
100 vezes melhor.
Easy Tier
Move automaticamente dados.
Hot
SSD
Cold
SATA
Sem intervenção.
Compressão
Hardware.
Sem CPU z/OS.
Replicação
Metro Mirror
Global Mirror
Safeguarded Copy
Erros comuns
B37
Sem espaço
D37
Volume cheio
E37
Extensão insuficiente
IEC070I
Falha de alocação
Solução
Mais secondary
SMS
Novo volume
Melhor prática
Nunca usar:
SPACE=(CYL,(1,1))
Produção odeia isso.
| Bellacosa Mainframe e a evolução do storage |
Easter Egg Bellacosa
Imagine um COBOL de 1987.
Compilado em COBOL II.
Executando em 2026.
Lendo VSAM.
Em um DS8950F.
Flash NVMe.
z17.
LinuxONE ao lado.
IA embarcada.
Criptografia quântica.
E ainda existe:
UNIT=3390
O programa olha para o disco e diz:
Bom dia senhor 3390.
O DS8950F responde:
Sim filho... continue trabalhando.
E ninguém percebe que existe aproximadamente quarenta anos de evolução tecnológica escondida atrás de uma única palavra.
Considerações finais
Talvez esta seja a maior obra de engenharia produzida pela IBM.
Não foi criar discos maiores.
Nem processadores mais rápidos.
Nem flash mais eficiente.
Foi construir um ecossistema onde décadas de aplicações continuam executando sem alterações significativas.
O Mainframe não luta contra o passado.
Ele conversa com ele.
E talvez seja exatamente por isso que, enquanto muitas plataformas precisam ser reescritas a cada década, ainda existam aplicações COBOL escritas por profissionais aposentados há vinte anos processando bilhões de dólares diariamente.
No universo IBM Z, o armazenamento não é apenas um lugar para guardar dados.
É um pacto silencioso entre gerações de engenheiros.
E toda vez que digitamos:
SPACE=(CYL,(100,20))
UNIT=3390
estamos, de certa forma, apertando a mão de todos os sysprogs, operadores e desenvolvedores que vieram antes de nós.
E isso merece, no mínimo, mais uma xícara de café.
