 |
| Bellacosa Mainframe e o dataset vsam |
☕ Um Café no Bellacosa Mainframe
🧙♂️ GANDALF E O VSAM QUE ATRAVESSOU AS ERAS
COBOL, KSDS, ESDS, RRDS, CI, CA, buffers, LSR, RLS, DFSMS, Extended Format, encryption, zHyperLink, DS8000, IBM z17 — e o dia em que um jovem programador descobriu que o arquivo de 50 anos atrás ainda não estava pronto para se aposentar.
Sob a tutela de Gandalf
🎬 PRÓLOGO — VOCÊ NÃO PASSARÁ... SEM ENTENDER O VSAM!
Imagine um jovem programador COBOL chegando pela primeira vez diante de um IBM z17.
Ele olha para aquela máquina moderna, lê sobre processadores poderosos, criptografia, inteligência artificial, aceleração de I/O, APIs, containers, Linux, cloud e uma quantidade quase assustadora de tecnologias.
Então abre um programa COBOL.
E encontra isto:
SELECT CLIENTES
ASSIGN TO CLIENTES
ORGANIZATION IS INDEXED
ACCESS MODE IS RANDOM
RECORD KEY IS COD-CLIENTE.
Mais abaixo:
MOVE 123456 TO COD-CLIENTE.
READ CLIENTES
INVALID KEY
DISPLAY 'CLIENTE NAO ENCONTRADO'
END-READ.
Ele olha novamente para o z17.
Olha para o programa.
Olha para o z17.
— Gandalf... não está faltando alguma coisa?
O velho mago apoia o cajado no chão.
— Não.
— Mas isso parece o mesmo COBOL que alguém poderia ter escrito décadas atrás!
Gandalf sorri.
— Exatamente.
E aqui começa nossa aventura.
Porque talvez a coisa mais impressionante sobre VSAM no IBM z17 seja justamente aquilo que não mudou.
O programa continua dizendo:
READ CLIENTES
Só que o universo existente entre esse READ e os dados tornou-se extraordinariamente sofisticado.
Prepare o café.
Pegue o cajado.
Hoje vamos atravessar a Terra-média do DFSMS.
🧙 CAPÍTULO 1 — A PERGUNTA ERRADA: "QUAL É O NOVO VSAM DO z17?"
Quando uma nova geração IBM Z aparece, é natural perguntar:
O que mudou no VSAM?
Talvez imaginemos algo chamado:
VSAM 17
ou:
VSAM Next Generation
Talvez esperemos encontrar um comando COBOL novo:
READ CLIENTES
WITH-Z17-TURBO-MODE
END-READ.
Não existe.
E isso não é uma deficiência.
É uma das maiores virtudes da arquitetura.
O IBM z17 não representa uma reinvenção da interface lógica do VSAM.
Continuamos reconhecendo conceitos históricos:
KSDS
ESDS
RRDS
LDS
Control Interval
Control Area
INDEX
AIX
PATH
READ
WRITE
REWRITE
DELETE
START
READ NEXT
Portanto, se você aprendeu VSAM em uma geração anterior do IBM Z, seu conhecimento não virou cinzas quando o z17 apareceu.
Gandalf poderia resumir assim:
"Nem toda tecnologia antiga precisa morrer para que o mundo evolua."
O segredo está nas camadas inferiores.
🗺️ CAPÍTULO 2 — O MAPA DA TERRA-MÉDIA DO VSAM
Quando ensinamos VSAM para iniciantes, geralmente desenhamos:
COBOL
|
v
VSAM
|
v
DISCO
Isso é útil.
Mas é como representar toda a Terra-média desenhando apenas:
CONDADO
|
MORDOR
Há muita coisa no caminho.
Em um ambiente moderno, podemos imaginar algo mais próximo disto:
APLICAÇÃO
|
COBOL
|
+--------+--------+
| |
BATCH CICS
| |
+--------+--------+
|
VSAM
|
+----------+----------+
| | |
NSR LSR RLS
|
SMSVSAM
|
DFSMS
|
BUFFER MANAGEMENT
|
MEDIA MANAGER
|
I/O SERVICES
|
CACHE
|
zHyperLink
|
DS8000
|
FLASH
Agora nossa pergunta muda.
Não é apenas:
"VSAM ficou diferente?"
Passa a ser:
"O que aconteceu com todas as camadas que atendem aquele velho READ COBOL?"
Essa é uma pergunta muito mais interessante.
🔑 CAPÍTULO 3 — KSDS: O ANEL CONTINUA SENDO O ANEL
Vamos começar pelo conhecido.
Um KSDS — Key Sequenced Data Set — permite localizar registros através de uma chave.
Imagine:
CUSTOMER.KSDS
contendo:
000001 BILBO BAGGINS
000002 FRODO BAGGINS
000003 SAMWISE GAMGEE
000004 PEREGRIN TOOK
000005 MERIADOC BRANDYBUCK
Seu programa pode fazer:
MOVE 000003 TO CUSTOMER-ID.
READ CUSTOMER-FILE
KEY IS CUSTOMER-ID
END-READ.
O COBOL não precisa conhecer o endereço físico daquele registro.
É justamente para isso que existe VSAM.
Conceitualmente:
KEY
|
v
INDEX
|
v
SEQUENCE SET
|
v
DATA
|
v
RECORD
E aqui aparece uma primeira lição importante.
O programador trabalha com:
KEY -> RECORD
O VSAM resolve o restante.
📦 CAPÍTULO 4 — CONTROL INTERVAL: A CAIXA QUE CARREGA SEUS REGISTROS
Um registro VSAM não está simplesmente flutuando sozinho no storage.
Precisamos conhecer o Control Interval, nosso famoso CI.
Simplificando:
CONTROL INTERVAL
+-----------------------------------+
| RECORD | RECORD | RECORD | FREE |
+-----------------------------------+
Vários CIs formam uma estrutura maior chamada Control Area, CA.
CONTROL AREA
|
+-- CI 01
+-- CI 02
+-- CI 03
+-- CI 04
+-- CI 05
Portanto:
REGISTRO
↓
CONTROL INTERVAL
↓
CONTROL AREA
↓
VSAM DATA SET
Essa organização continua fundamental.
E ela será importante quando chegarmos ao zHyperLink.
Guarde o CI no bolso.
Voltaremos a ele.
💥 CAPÍTULO 5 — O BALROG CHAMADO CI SPLIT
Imagine:
+-----------------------------+
| A | B | C | D | FREE |
+-----------------------------+
Há espaço disponível.
Novos registros entram.
Depois temos:
+-----------------------------+
| A | B | C | D | E | F |
+-----------------------------+
Chega outro registro que precisa ser colocado naquela sequência lógica.
Não existe espaço adequado.
O VSAM pode precisar realizar um:
CI SPLIT.
Em situações maiores podemos chegar a:
CA SPLIT.
E Gandalf aparece diante do Balrog:
"YOU SHALL NOT PASS!"
Infelizmente, o novo registro responde:
"Tenho
WRITEautorizado pelo RACF."
E passa.
Brincadeiras à parte, splits podem ter impacto operacional e de performance.
Por isso existem parâmetros como:
FREESPACE
e decisões sobre:
CI SIZE
CA SIZE
Um z17 não elimina magicamente um dataset mal planejado.
Hardware mais rápido não substitui arquitetura.
🧠 CAPÍTULO 6 — O I/O MAIS RÁPIDO É AQUELE QUE NÃO EXISTE
Aqui está uma das dicas mais importantes deste artigo.
Imagine:
READ CUSTOMER
|
v
VSAM
|
v
STORAGE
Talvez você pense:
Precisamos acelerar o storage!
Calma, jovem Hobbit.
Primeiro pergunte:
Por que estamos indo ao storage?
Se a informação necessária já estiver disponível em buffer/cache, podemos evitar determinado acesso físico.
Conceitualmente:
READ
|
v
BUFFER?
|
+--- HIT ---> RECORD
|
+--- MISS --> I/O
Compare:
READ
↓
I/O
↓
STORAGE
↓
RETURN
com:
READ
↓
BUFFER HIT
↓
RETURN
É por isso que buffering continua tão importante.
Não adianta possuir um storage absurdamente rápido se a aplicação estiver produzindo I/O desnecessário.
🧙♂️ CAPÍTULO 7 — NSR, LSR E RLS: TRÊS MAGOS CHEGAM À REUNIÃO
Você encontrará três siglas importantes no universo VSAM:
NSR
LSR
RLS
NSR — Non-Shared Resources
É o modelo convencional em que recursos utilizados no acesso ficam associados ao processamento daquele dataset/contexto.
LSR — Local Shared Resources
Permite compartilhamento de pools de buffers entre datasets VSAM dentro do contexto apropriado. É particularmente conhecido no universo CICS.
RLS — Record Level Sharing
Aqui nossa aventura cresce bastante.
Agora podemos pensar em múltiplos acessos compartilhados:
CICS A
|
|
CICS B ---- VSAM ---- CICS C
|
|
CICS D
E começam a aparecer problemas que não existem quando imaginamos apenas:
PROGRAMA -> ARQUIVO
Agora precisamos pensar em:
locking
serialization
sharing
consistency
recovery
Bem-vindo ao VSAM de produção.
🌍 CAPÍTULO 8 — A SOCIEDADE DO ANEL ENCONTRA O PARALLEL SYSPLEX
Imagine três sistemas:
LPAR A
|
CICS A
|
+-----------+
|
LPAR B |
| |
CICS B -------+---- VSAM
|
LPAR C |
| |
CICS C -------+
Não queremos necessariamente limitar determinado dado a uma única região CICS ou sistema.
Em arquiteturas de alta disponibilidade e compartilhamento, RLS torna-se extremamente importante.
Agora aquele inocente:
READ CUSTOMER-FILE
faz parte de um universo distribuído dentro da arquitetura do próprio mainframe.
Isso é algo que surpreende muitos iniciantes.
VSAM não precisa significar:
"Um arquivo usado por um programa."
Pode participar de uma infraestrutura extremamente sofisticada.
🏦 CAPÍTULO 9 — DFSMStvs: QUANDO VSAM APRENDE TRANSAÇÕES MAIS SOFISTICADAS
Agora chegamos a uma tecnologia que muitos programadores COBOL passam anos sem conhecer:
DFSMStvs — Transactional VSAM Services.
Imagine:
CUSTOMER.KSDS
|
+-------+-------+
| |
CICS BATCH
| |
UPDATE UPDATE
| |
+-------+-------+
|
DFSMStvs
O problema já não é simplesmente ler um registro.
Queremos coordenação transacional, recuperação e compartilhamento apropriado entre workloads.
Isso não transforma VSAM em Db2.
Repita comigo:
VSAM não virou Db2.
Mas também mostra como é inadequado chamar VSAM simplesmente de:
"arquivo velho do COBOL".
Existe muita infraestrutura ao redor dele.
⚡ CAPÍTULO 10 — GANDALF DESCOBRE O zHYPERLINK
Agora chegamos a uma das partes mais interessantes da história.
zHyperLink.
Tradicionalmente, pensamos em I/O aproximadamente assim:
CPU
|
v
I/O REQUEST
|
v
I/O INFRASTRUCTURE
|
v
STORAGE
|
v
COMPLETION
|
v
APPLICATION
A arquitetura assíncrona de I/O é uma das grandes forças históricas do mainframe.
A CPU não deveria simplesmente ficar sentada olhando para um dispositivo lento.
Só que storage mudou dramaticamente.
Memória, cache e flash mudaram as relações de tempo.
Em determinadas situações, tornou-se interessante oferecer um caminho de synchronous I/O de baixíssima latência.
Entra zHyperLink.
Simplificando brutalmente:
VSAM READ
|
v
operação elegível?
|
SIM
|
v
zHyperLink
|
v
STORAGE CACHE
|
v
RESPONSE
E isso pode reduzir significativamente a latência para operações elegíveis.
🧩 CAPÍTULO 11 — O CI QUE GUARDAMOS NO BOLSO VOLTOU
Lembra do Control Interval?
Agora ele volta à história.
Porque existe relação entre quantidade de dados da operação e elegibilidade para determinados caminhos de I/O.
No ambiente moderno, parâmetros relacionados ao zHyperLink permitem controlar limites de leitura e explorar capacidades mais recentes de aceleração.
Portanto algo que aprendemos no primeiro curso de VSAM:
CI SIZE
continua conversando com uma infraestrutura que surgiu décadas depois.
Veja a beleza disso:
DESIGN VSAM
|
CI SIZE
|
v
TAMANHO DA LEITURA
|
v
MEDIA MANAGER
|
v
I/O ELIGIBILITY
|
v
zHyperLink
Um conceito antigo continua relevante em uma máquina moderníssima.
Isso é mainframe.
⚠️ CAPÍTULO 12 — NÃO USE MAGIA SEM SABER O FEITIÇO
Neste momento alguém certamente perguntará:
Então devemos mudar todos os CIs para 16K?
NÃO!
Gandalf bate o cajado no chão.
Esse é exatamente o tipo de tuning que produz desastre:
ALGUÉM DISSE QUE 16K É MAIS RÁPIDO
Logo:
ALTERE TUDO!
Não.
O comportamento depende de:
record size
access pattern
random access
sequential access
insert rate
free space
buffering
RLS
cache
workload
Uma aplicação fazendo:
READ RANDOM
READ RANDOM
READ RANDOM
não possui necessariamente o mesmo perfil de:
START
READ NEXT
READ NEXT
READ NEXT
READ NEXT
E nenhuma das duas é necessariamente equivalente a uma carga massiva de inserções.
Meça antes de mudar.
Essa é uma das regras de ouro do mainframe.
📊 CAPÍTULO 13 — SMF E RMF: AS PALANTÍRI DA PERFORMANCE
Gandalf não faz tuning dizendo:
"Tenho a impressão de que está mais lento."
Ele consulta as Palantíri.
No z/OS temos instrumentos muito melhores:
SMF
RMF
Se você migrou determinada carga para uma plataforma mais nova e deseja saber o que aconteceu, investigue.
Observe coisas como:
CPU
elapsed time
I/O rate
I/O response time
EXCP
cache behavior
buffer behavior
locking
RLS activity
synchronous I/O
CI/CA splits
O método correto é:
BASELINE
|
v
MUDANÇA
|
v
NOVA MEDIÇÃO
|
v
COMPARAÇÃO
|
v
CONCLUSÃO
Não:
MIGRAMOS PARA z17
|
v
DEVE ESTAR MAIS RÁPIDO
"Deve" é uma palavra perigosa em Capacity Planning.
🏎️ CAPÍTULO 14 — MÁQUINA MAIS RÁPIDA NÃO SIGNIFICA TRANSAÇÃO MAIS RÁPIDA
Considere:
CUSTOMER.KSDS
200.000.000 registros
e:
CICS
8.000 READs/s
Migramos para uma infraestrutura mais nova.
Depois descobrimos:
CPU ↓
Excelente!
Mas:
RESPONSE TIME =
praticamente igual.
Como?
Porque talvez a transação esteja esperando:
I/O
ou:
LOCK
ou:
MQ
ou:
Db2
ou:
NETWORK
ou:
API
ou outra dependência.
Performance é uma corrente.
Acelerar um elo que não é o gargalo não acelera necessariamente a corrente inteira.
🗜️ CAPÍTULO 15 — EXTENDED FORMAT: VSAM GANHOU UMA MOCHILA NOVA
Outro conceito que o iniciante precisa conhecer é Extended Format.
Pense:
VSAM
|
+-- Conventional
|
+-- Extended Format
Com Extended Format entram possibilidades importantes associadas ao gerenciamento moderno de datasets, incluindo recursos como:
Data Striping
Compression
Extended Addressability
Encryption
System Managed Buffering
Isso significa que dois programas podem enxergar:
CUSTOMER.KSDS
enquanto por baixo existem características bastante diferentes.
O programa continua:
READ CUSTOMER-FILE
A infraestrutura pode estar fazendo muito mais.
📏 CAPÍTULO 16 — 4 GB JÁ FOI O TAMANHO DE SMAUG
Hoje alguém olha para:
4 GB
e pensa:
Só isso?
Historicamente, 4 GB já representou um limite enorme.
À medida que datasets cresceram, mecanismos como Extended Addressability tornaram possível ultrapassar limitações tradicionais.
Essa é outra lição interessante da história do mainframe.
A arquitetura não foi criada prevendo tudo que existiria cinquenta anos depois.
Ela foi evoluída.
Pense na sequência:
VSAM
1970s
|
1980s
|
1990s
|
2000s
|
2010s
|
2020s
|
IBM z17
Pouquíssimas tecnologias de infraestrutura possuem uma linhagem operacional comparável.
🔐 CAPÍTULO 17 — O REGISTRO PODE ESTAR CRIPTOGRAFADO E O COBOL NEM SABE
Agora imagine:
READ CUSTOMER-FILE
END-READ.
O programa não contém:
DECRYPT CUSTOMER
nem:
CALL AES
nem precisa carregar manualmente uma biblioteca criptográfica para cada READ.
A proteção dos dados pode acontecer em camadas inferiores da infraestrutura.
Conceitualmente:
COBOL
|
VSAM
|
DFSMS
|
ENCRYPTION
|
STORAGE
Essa separação de responsabilidades é poderosa.
O programador trabalha com:
registro
A plataforma trabalha com:
proteção do dado
Isso permite modernizar requisitos de segurança sem obrigatoriamente reescrever milhões de linhas de aplicação.
🧙♀️ CAPÍTULO 18 — SYSTEM MANAGED BUFFERING
Outro conceito importante é o System Managed Buffering — SMB.
O nome praticamente explica a proposta.
Em vez de depender exclusivamente de escolhas estáticas e históricas sobre buffers, permitimos que mecanismos do sistema participem da estratégia.
Voltemos à nossa regra:
O I/O mais rápido é aquele que não precisa acontecer.
Temos:
APPLICATION
|
VSAM
|
BUFFER
|
CACHE
|
I/O
|
STORAGE
Quanto mais cedo conseguirmos satisfazer a necessidade, melhor.
Mas novamente:
não existe configuração universal perfeita.
Batch sequencial não é CICS random.
Leitura não é inserção.
Arquivo pequeno não é arquivo gigantesco.
Performance engineering exige contexto.
☁️ CAPÍTULO 19 — E O VSAM COMEÇA A OLHAR PARA A CLOUD
Uma das direções interessantes do ecossistema moderno é permitir que dados tradicionalmente residentes no ambiente z/OS participem mais facilmente de outros fluxos.
A evolução do DFSMS e mecanismos de Cloud Data Access aproxima datasets do mundo de object storage e processos modernos de movimentação de dados.
O desenho conceitual começa a parecer:
VSAM
|
DFSMS
|
Cloud Data Access
|
Object Storage
Isso muda nossa maneira de pensar modernização.
Durante anos, muita gente tratou modernização como:
REMOVER O MAINFRAME
Hoje existe uma abordagem muito mais interessante:
MANTER O QUE FUNCIONA
+
INTEGRAR COM O NOVO
Gandalf aprovaria.
Não precisamos destruir Minas Tirith para instalar Wi-Fi.
🧬 CAPÍTULO 20 — VSAM, JSON E O MUNDO MODERNO
Outra fronteira interessante é a transformação de registros tradicionais em representações modernas.
Imagine um copybook:
01 CUSTOMER.
05 CUSTOMER-ID PIC 9(08).
05 CUSTOMER-NAME PIC X(40).
05 CUSTOMER-CITY PIC X(30).
O mundo COBOL enxerga isso perfeitamente.
Uma aplicação moderna talvez prefira:
{
"customerId": 317,
"customerName": "Gandalf",
"customerCity": "Valfenda"
}
Esses dois universos não precisam necessariamente ser inimigos.
Podemos construir pontes:
COPYBOOK
|
v
RECORD
|
v
TRANSFORMATION
|
v
JSON
Esse é um dos princípios centrais da modernização contemporânea do mainframe:
Modernizar o acesso não significa obrigatoriamente substituir o dado.
🏛️ CAPÍTULO 21 — VSAM NÃO É UM BANCO RELACIONAL
Precisamos colocar uma placa gigantesca aqui.
VSAM != Db2
VSAM possui características extremamente poderosas:
indexed access
sequential access
direct access
buffering
sharing
locking infrastructure
recovery integration
Mas não oferece o modelo relacional do Db2.
No Db2 posso pensar:
SELECT NAME
FROM CUSTOMER
WHERE CITY = 'HOBBITON'
ORDER BY NAME;
Em um KSDS tradicional, a chave e a organização dos dados têm uma importância estrutural enorme.
VSAM é brilhante quando o problema é algo parecido com:
KEY
|
v
RECORD
Db2 resolve outra classe de problemas.
Escolher tecnologia significa entender o problema.
Não escolher a tecnologia mais nova.
🧓 CAPÍTULO 22 — "MAS VSAM NÃO É VELHO?"
Sim.
E essa pergunta sozinha não significa absolutamente nada.
Um martelo é velho.
A roda é velha.
SQL é velho.
TCP/IP é velho.
COBOL é velho.
Unix é velho.
A pergunta arquitetural correta é:
Resolve o problema adequadamente?
Imagine:
CICS
|
COBOL
|
VSAM KSDS
processando milhares de transações com:
alta disponibilidade
baixo response time
previsibilidade
recuperação
décadas de estabilidade
Qual é o business case para substituí-lo?
"É antigo" não é business case.
Agora, se existem problemas como:
alto custo operacional
dificuldade de integração
limitações funcionais
escassez de conhecimento
problemas de escalabilidade
requisitos novos
a conversa muda.
Arquitetura começa pelo problema.
🔬 CAPÍTULO 23 — PASSO A PASSO: INVESTIGANDO VSAM EM UM AMBIENTE MODERNO
Se você é um Padawan COBOL — ou Hobbit COBOL, já que Gandalf assumiu a aula — siga esta sequência.
Passo 1 — descubra a organização
Pergunte:
KSDS?
ESDS?
RRDS?
LDS?
Passo 2 — descubra como é acessado
Sequential?
Random?
Dynamic?
Passo 3 — descubra quem usa
Batch?
CICS?
Ambos?
Passo 4 — examine a definição
Procure entender:
KEYS
RECORDSIZE
CONTROLINTERVALSIZE
FREESPACE
SHAREOPTIONS
DATACLASS
STORCLAS
MGMTCLAS
Não saia alterando.
Primeiro entenda.
Passo 5 — descubra o buffering
Pergunte:
NSR?
LSR?
RLS?
SMB?
Passo 6 — descubra o comportamento
Observe:
READ
WRITE
REWRITE
DELETE
READ NEXT
Passo 7 — procure sinais de problema
Investigue:
I/O excessivo
splits
lock contention
response time
elapsed time
CPU
buffer misses
Passo 8 — use telemetria
Entre no mundo:
SMF
RMF
CICS statistics
VSAM statistics
Passo 9 — crie baseline
Nunca diga:
"Ficou melhor."
Diga:
ANTES
CPU = X
I/O = Y
ELAPSED = Z
RESPONSE = W
DEPOIS
CPU = ...
I/O = ...
ELAPSED = ...
RESPONSE = ...
Agora temos engenharia.
Passo 10 — mude UMA coisa
Não altere simultaneamente:
CI
FREESPACE
buffers
storage
programa
CICS
e depois pergunte qual alteração funcionou.
Você jamais saberá.
🎒 CAPÍTULO 24 — CURIOSIDADES PARA LEVAR NA MOCHILA
Curiosidade 1: VSAM surgiu na década de 1970 e continua operacionalmente relevante em plataformas IBM Z modernas.
Curiosidade 2: conceitos aparentemente antigos, como CI e CA, continuam importantes mesmo quando a infraestrutura utiliza flash, grandes caches e mecanismos modernos de I/O.
Curiosidade 3: um programa COBOL pode continuar usando praticamente a mesma lógica de acesso enquanto hardware, storage, segurança e sistema operacional mudaram várias gerações.
Curiosidade 4: VSAM pode participar de arquiteturas compartilhadas muito mais sofisticadas do que a caricatura "programa abre arquivo".
Curiosidade 5: acelerar CPU não necessariamente reduz response time quando o gargalo está em I/O, locks ou outra dependência.
Curiosidade 6: evitar um I/O geralmente é mais interessante do que simplesmente tornar aquele I/O mais rápido.
🥚 CAPÍTULO 25 — O EASTER EGG DAS 03:17
São 03:17 da madrugada.
O telefone toca.
Produção.
O operador informa:
"O CICS está lento."
O jovem programador pergunta:
— Deve ser CPU?
Gandalf responde:
— Não sabemos.
— Storage?
— Não sabemos.
— VSAM?
— Não sabemos.
— Então o que fazemos?
Gandalf olha para o monitor e responde:
"Um mago não adivinha um gargalo. Ele chega exatamente quando as métricas dizem onde procurar."
Abrimos SMF.
Analisamos RMF.
O processador estava tranquilo.
Storage também.
Depois de muita investigação...
...descobrimos uma aplicação segurando locks muito mais tempo do que deveria.
O jovem olha para Gandalf.
— Então comprar um z17 maior não resolveria?
Gandalf acende o cachimbo.
— Agora você está começando a entender performance.
🧭 CAPÍTULO 26 — O QUE REALMENTE MUDOU?
Finalmente podemos responder à pergunta original.
Para o programador COBOL?
Pouco.
Ele continua conhecendo:
OPEN
READ
WRITE
REWRITE
DELETE
START
READ NEXT
CLOSE
Para a organização lógica?
Continuamos reconhecendo:
KSDS
ESDS
RRDS
LDS
CI
CA
AIX
PATH
Para a infraestrutura?
A história é completamente diferente.
Temos um universo envolvendo:
DFSMS
Extended Format
SMB
RLS
DFSMStvs
compression
encryption
cache
Media Manager
zHyperLink
modern storage
Parallel Sysplex
Cloud Data Access
É aqui que está a evolução.
🧙♂️ EPÍLOGO — O VSAM NÃO PRECISOU SE TORNAR OUTRA COISA
Ao final da aventura, nosso jovem programador retorna ao mesmo código:
MOVE CUSTOMER-ID TO WS-CUSTOMER-ID.
READ CUSTOMER-FILE
INVALID KEY
DISPLAY 'NOT FOUND'
END-READ.
Agora ele não enxerga apenas quatro linhas de COBOL.
Enxerga:
COBOL
|
READ
|
VSAM
|
+-------+-------+
| | |
NSR LSR RLS
|
SMSVSAM
|
DFSMS
|
EXTENDED FORMAT
|
BUFFERING
|
MEDIA MANAGER
|
I/O SERVICES
|
zHyperLink
|
CACHE
|
DS8000
|
IBM Z17
E finalmente entende por que VSAM ainda é fascinante.
A genialidade não está em permanecer congelado em 1974.
Está em permitir que a interface conhecida pela aplicação sobreviva enquanto praticamente todo o universo existente debaixo dela evolui.
O programa pede:
READ
VSAM responde:
"Deixe comigo."
E entre essas duas frases podem existir cinquenta anos de engenharia.
Gandalf pega o cajado e começa a caminhar em direção ao próximo sistema.
O jovem programador pergunta:
— Mestre, então nunca devemos substituir VSAM?
Gandalf para.
Olha para trás.
— Eu não disse isso.
— Então quando devemos substituir?
O velho mago sorri.
"Quando você conseguir demonstrar qual problema está tentando resolver."
Silêncio no datacenter.
Nenhum Balrog.
Nenhum ABEND.
Apenas o som distante de um job terminando:
IEF142I JOB STEP WAS EXECUTED
COND CODE 0000
E em algum lugar de uma LPAR, um programa escrito décadas atrás executa novamente:
READ CUSTOMER-FILE
sobre uma infraestrutura que seu autor jamais poderia ter imaginado.
☕ Moral da história
No mainframe, compatibilidade não significa ausência de inovação.
Às vezes é justamente o contrário.
A maior demonstração de engenharia é permitir que tudo mude sem obrigar aquilo que funciona a mudar junto.
E antes de sair alterando CISIZE, FREESPACE, buffers ou qualquer outra coisa porque alguém prometeu performance...
lembre-se da primeira regra de Gandalf para o jovem analista de performance:
"Você não passará... para produção sem medir primeiro."
