✨ Bem-vindo ao meu espaço! ✨
Este blog é o diário de um otaku apaixonado por animes, tecnologia de mainframe e viagens.
Cada entrada é uma mistura única: relatos de viagem com fotos, filmes, links, artigos e desenhos, sempre buscando enriquecer a experiência de quem lê.
Sou quase um turista profissional: adoro dormir em uma cama diferente, acordar em um lugar novo e registrar tudo com minha câmera sempre à mão.
Entre uma viagem e outra, compartilho também reflexões sobre cultura otaku/animes
Bellacosa Mainframe com uma overview do Dataset VSAM no z/os
🔥 VSAM NÃO MORREU — ELE SÓ ESTÁ RODANDO EM PRODUÇÃO HÁ 40 ANOS SEM ABEND
🧠 O Segredo Mais Subestimado do z/OS (e por que você ainda depende dele)
Se você é desenvolvedor COBOL raiz, daqueles que já viram JCL com mais linhas que romance russo, então sabe: VSAM não é só storage… é infraestrutura crítica disfarçada de dataset.
Enquanto o mundo fala de NoSQL, Data Lakes e Kubernetes, lá no coração do IBM z/OS, o VSAM continua firme, resiliente… e silenciosamente essencial.
🧬 Origem: quando performance era questão de sobrevivência
O VSAM nasceu nos anos 60 com o OS/VS, evoluindo até o que conhecemos hoje no z/OS. Ele foi criado para resolver limitações dos métodos antigos (ISAM principalmente), trazendo:
Acesso indexado eficiente
Gerenciamento automático de espaço
Alta performance com grandes volumes
👉 Em outras palavras: VSAM foi o “Db2” antes do Db2 existir.
🚀 Versão atual relevante
Hoje, estamos na linha do:
👉 z/OS 3.x (como 3.1, 3.2, etc.)
E isso significa:
✔ VSAM atualizado automaticamente
✔ Melhorias de performance
✔ Integração com DFSMS
✔ Suporte a grandes volumes (EAV / Extended Addressability)
⚙️ O que evoluiu no VSAM ao longo do tempo
Mesmo sem “versão própria”, ele evoluiu MUITO:
🔹 Extended Addressability (EA)
Saiu do limite de GB → foi para TB
🔹 RLS (Record Level Sharing)
Concorrência real (quase “transacional”)
🔹 DFSMS
Gerenciamento automático (ACS routines)
🔹 Buffering avançado
Performance tuning muito mais fino
🧱 Onde o VSAM vive hoje
VSAM não é só “arquivo COBOL”:
👉 Ele é base de coisas grandes, como:
IBM Db2 for z/OS (usa LDS por baixo)
Catálogo do sistema
Sistemas críticos bancários
💥 Ou seja:
Mesmo que você “não use VSAM”… você usa.
⚠️ Erro comum de iniciante (e até de sênior distraído)
Perguntar:
“Qual versão do VSAM estamos usando?”
👉 A pergunta correta é:
“Qual versão do z/OS estamos rodando?”
🗂️ Tipos de Arquivos VSAM (o coração da arquitetura)
🔑 KSDS — Key Sequenced Data Set (o rei do pedaço)
Acesso por chave (PRIMARY KEY raiz do COBOL)
Possui INDEX + DATA
Suporta acesso sequencial e direto
💬 Comentário Bellacosa: Se VSAM fosse banco de dados, o KSDS seria o OLTP raiz.
📦 ESDS — Entry Sequenced Data Set
Registros gravados em ordem de entrada
Sem chave
Acesso via RBA (Relative Byte Address)
💬 Uso clássico: logs, trilhas de auditoria, arquivos append-only
🔢 RRDS — Relative Record Data Set
Acesso via número relativo (RRN)
Pode ter slots vazios
Pode ser FIXED ou VARIABLE
💬 Parece simples… até você esquecer que tem slot vazio e dar READ errado 😅
Bellacosa Mainframe uma visão para padawans do VSAM
💥 VSAM: O “Banco de Dados Gratuito” do z/OS — Muito Mais do Que Você Imagina
🧠 Explicação Enriquecida para Padawns
📌 O que é VSAM?
Tradução:
VSAM significa Virtual Storage Access Method. O termo “Access Method” surgiu lá nos anos 60 com o OS/360 e basicamente define como os dados são acessados (disco, fita, etc.).
Comentário Bellacosa:
👉 “Access Method” é o motor invisível do I/O no mainframe.
👉 VSAM é otimizado para disco — esqueça fita aqui (só backup/export).
📌 Tipos principais: ESDS vs KSDS
Tradução:
ESDS (Entry Sequenced Data Set)
Acesso via RBA (Relative Byte Address)
KSDS (Key Sequenced Data Set)
Acesso via chave ou RBA
Possui índice
Comentário prático:
Tipo
Quando usar
Mentalidade
ESDS
Log, append-only, histórico
“grava e nunca mexe”
KSDS
CRUD clássico
“mini banco de dados”
💡 Insight importante:
KSDS = VSAM mais próximo de banco relacional
ESDS = VSAM mais próximo de log estruturado
📌 Alternate Index (AIX)
Tradução:
Você pode criar índices alternativos (AIX) para acessar registros por outras chaves.
Comentário:
👉 Isso é o equivalente a índices secundários no DB2
👉 Mas aqui você controla tudo manualmente
💣 E aqui nasce a dor:
consistência
manutenção
performance
📌 Cluster, Componentes e Sphere
Tradução:
ESDS → Data component
KSDS → Data + Index component
Conjunto com AIX → chamado de Sphere
Comentário:
👉 “Sphere” é basicamente o ecossistema do dataset VSAM
👉 Em produção, isso vira uma mini arquitetura de dados
🚀 VSAM na Vida Real
Tradução:
VSAM continua sendo amplamente usado porque é:
rápido
escalável
já vem com z/OS
não exige banco adicional
Comentário forte:
💣 VSAM é o NoSQL original do mainframe
Antes de MongoDB existir, o z/OS já fazia isso há décadas
🔥 Caso real: Criando um Key/Value Store com VSAM
O autor implementa um banco estilo NoSQL key/value.
📌 Requisitos do sistema
Tradução + Expansão:
Fácil inserir/recuperar chave
Persistente (VSAM)
Rápido
Sem limite de tamanho
Permite agrupamento de chaves
Comentário:
👉 Isso é literalmente um Redis raiz no mainframe
Bellacosa Mainframe apresenta o idcams para o vsam
☕ Um Café no Bellacosa Mainframe
Melvin Udall Entra no IDCAMS — O Homem que Não Aceitava Arquivo Fora de Ordem, Índice Sem BLDINDEX nem RC=8 Sem Explicação
Ou: como o VSAM deixou de ser “aquele arquivo do COBOL” e revelou uma cidade inteira de CIs, CAs, catálogos, índices alternativos, backups, reorganizações e pequenos desastres esperando alguém escrever DELETE ... PURGE no dataset errado
Há pessoas que olham para um arquivo VSAM e dizem: “é só um arquivo”.
Melvin Udall, o escritor rabugento de Melhor Impossível, olharia para essa frase, ajustaria as luvas, evitaria encostar no terminal compartilhado e responderia algo como:
“Não. ‘Só um arquivo’ é o que você diz cinco minutos antes de apagar a produção.”
E, desta vez, Melvin estaria certo.
Para o programador COBOL iniciante, VSAM parece inicialmente uma sigla misteriosa usada por veteranos quando querem tornar uma reunião mais silenciosa. Você vê algo assim no programa:
SELECT ARQ-CLIENTE
ASSIGN TO VSAM-CLIENTE
ORGANIZATION IS INDEXED
ACCESS MODE IS DYNAMIC
RECORD KEY IS CLI-CPF.
E pensa: “Pronto. Tenho um arquivo indexado. O COBOL abre, lê, grava e fecha.”
Sim. Mas isso é como ver a porta de um banco e concluir que compreendeu tesouraria, segurança, auditoria, cofre, sistema antifraude, ar-condicionado do datacenter e o senhor que aparece às três da manhã perguntando por que o batch não fechou.
O programa COBOL usa o VSAM. Mas alguém precisou criar esse VSAM. Alguém precisa verificar se o arquivo existe, descobrir sua chave, conferir o espaço disponível, copiar seus registros, refazer índices, investigar mensagens estranhas e reorganizá-lo quando ele envelhece mal.
Esse alguém — ao menos na maior parte dos ambientes z/OS — conversa com o IDCAMS.
E, se Melvin Udall fosse o responsável pelo VSAM, ele não permitiria uma única chave fora de posição, um único índice alternativo esquecido ou um único RC=8 sendo tratado com a clássica frase corporativa: “mas o job terminou”.
Prólogo — O arquivo que não era apenas um arquivo
VSAM significa Virtual Storage Access Method. É uma tecnologia criada pela IBM para organizar e acessar dados no ambiente de mainframe com eficiência, previsibilidade e capacidade de sobreviver ao tipo de volume que faz uma planilha do Excel pedir aposentadoria.
Sua origem está na evolução dos sistemas IBM da família OS/VS. Antes do VSAM, havia modelos de arquivos mais separados e especializados, como sequenciais tradicionais e ISAM. Cada qual tinha seu estilo, suas limitações e seu conjunto de utilitários.
O VSAM trouxe uma visão mais integrada.
Em vez de tratar o armazenamento como uma sequência de registros soltos, ele introduziu uma organização formada por:
Estruturas lógicas;
Componentes de dados;
Componentes de índice;
Catálogos;
Unidades internas de leitura e gravação;
Controle de espaço;
Possibilidade de acesso direto por chave;
Estruturas alternativas de busca.
O VSAM não nasceu para ser “bonito” no sentido moderno da palavra. Ele nasceu para ser confiável, eficiente e administrável em ambientes nos quais perder ou duplicar uma transação não era um bug simpático: era um problema bancário, fiscal, logístico ou governamental.
E aqui começa a primeira lição Melvin Udall para o jovem padawan COBOL:
“Você pode não querer entender como o arquivo foi criado. O arquivo não tem a mesma obrigação em relação a você.”
1. IDCAMS: o administrador do condomínio VSAM
IDCAMS significa Integrated Data Cluster Access Method Services.
Pense nele como o administrador rigoroso do condomínio VSAM. Ele não processa a folha de pagamento nem calcula juros. Ele prepara o prédio onde esses dados irão morar, consulta as plantas, verifica rachaduras, copia apartamentos, troca placas, recria portarias e avisa quando alguém tentou estacionar um caminhão dentro da sala.
Podem indicar arquivos de entrada, saída, backup ou carga
O SYSIN é onde vivem comandos como:
DEFINE
DELETE
LISTCAT
REPRO
PRINT
VERIFY
EXAMINE
EXPORT
IMPORT
BLDINDEX
ALTER
SET
Um conselho de sobrevivência: nunca trate SYSPRINT como decoração. É ali que o IDCAMS explica o que fez, o que não fez e por que decidiu que seu plano era uma má ideia.
O RC do job indica a gravidade geral. As mensagens explicam a causa.
Melvin colocaria isso em uma moldura:
“Código de retorno não é diagnóstico. É apenas a campainha tocando.”
2. Os quatro moradores principais: KSDS, ESDS, RRDS e LDS
Antes de criar um arquivo, você precisa saber que tipo de VSAM faz sentido.
Tipo
Como organiza
Uso típico
KSDS
Por chave
Clientes, contas, produtos, contratos
ESDS
Ordem de inclusão
Logs, eventos, trilhas de auditoria
RRDS
Número relativo de registro
Tabelas com posições fixas
LDS
Sequência bruta de bytes
Produtos especializados e estruturas próprias
O rei do cotidiano COBOL é o KSDS — Key Sequenced Data Set.
Nele, os registros são organizados pela chave. Se CPF é a chave, o VSAM sabe encontrar o cliente sem precisar ler todos os demais.
Exemplo de dados:
CPF NOME
01234567890 ANA SILVA
12345678901 BRUNO COSTA
98765432100 CARLA MENDES
O KSDS mantém uma estrutura de índice que permite localizar o registro pela chave.
No COBOL, isso aparece em operações como:
MOVE WS-CPF-PROCURADO TO CLI-CPF
READ ARQ-CLIENTE
KEY IS CLI-CPF
INVALID KEY
DISPLAY 'CLIENTE NAO ENCONTRADO'
END-READ
Mas a magia não acontece porque o COBOL “leu rápido”. Ela acontece porque o VSAM foi corretamente definido, carregado e mantido.
3. Cluster, DATA e INDEX: a casa, os móveis e o mapa
O principal objeto VSAM é o cluster.
No caso de um KSDS, há normalmente dois componentes físicos importantes:
DATA component: onde os registros estão;
INDEX component: onde estão chaves e ponteiros para localizar os registros.
O INDEX é o catálogo que diz em qual corredor e estante o livro está.
Se o índice tem problema, o livro pode continuar fisicamente ali, mas encontrá-lo fica muito mais difícil. Se você tem uma chave definida incorretamente, é como organizar livros pelo terceiro caractere do sobrenome do autor e fingir que aquilo faz sentido.
Melvin Udall chamaria isso de “uma arquitetura concebida por alguém que odeia leitores”.
4. Criando um KSDS com DEFINE CLUSTER
Vamos criar um cadastro de clientes cuja chave é um CPF de 11 bytes a partir da posição zero do registro.
Nesse caso, o CPF não começa no byte zero. Você precisa calcular a posição real com precisão. Não é chute, não é sensação, não é “acho que começa ali perto”.
Em mainframe, “quase certo” é apenas uma forma educada de dizer “errado”.
5. CI e CA: onde o VSAM realmente acomoda os registros
Dois conceitos assustam muita gente no início:
CI — Control Interval;
CA — Control Area.
Vamos simplificar sem mentir.
Um CI é como uma página organizada onde o VSAM coloca vários registros. É uma unidade de I/O: quando o VSAM lê ou grava, ele trabalha em torno dessas unidades.
Um CA é um conjunto de CIs.
Assim:
Cluster
└── Control Area
├── Control Interval
│ ├── Registro 1
│ ├── Registro 2
│ └── Espaço livre
├── Control Interval
└── Control Interval
Quando você insere um registro em um KSDS, ele precisa caber em algum CI na posição correta da chave.
Se não há espaço suficiente, o VSAM pode realizar um CI Split. Se a situação envolve uma estrutura maior, pode ocorrer um CA Split.
Isso não significa automaticamente corrupção ou desastre. É o VSAM reorganizando espaço para continuar atendendo inclusões.
Mas muitos splits podem criar fragmentação e aumentar o custo de I/O.
É por isso que existe:
FREESPACE(20 10)
A ideia é reservar espaço para que futuras inserções entre chaves existentes tenham onde ficar.
O primeiro número representa espaço livre dentro dos CIs;
O segundo define uma reserva de CIs livres em cada CA.
Se seu arquivo é carregado uma vez, raramente recebe inclusões e é muito lido, exagerar no FREESPACE desperdiça espaço.
Se ele recebe inserções constantes, principalmente em posições intermediárias da chave, um FREESPACE pequeno pode transformar seu KSDS em uma cidade que cresceu sem plano diretor.
Melvin provavelmente teria uma opinião sobre bairros construídos sem planejamento.
6. REPRO: a mudança de casa dos registros
REPRO é o subcomando usado para copiar dados.
Para fazer uma carga inicial de um arquivo sequencial para um KSDS:
É uma ferramenta excelente para ambientes de teste abandonados por gerações anteriores. Você começa procurando um KSDS e descobre seis versões, três índices alternativos, um PATH sem dono e um dataset chamado TESTE.FINAL.DEFINITIVO.NOVO2.
A arqueologia do mainframe é real.
8. PRINT: quando olhar o dado é melhor do que imaginar o dado
HEX ajuda quando há campos binários, COMP, COMP-3 ou caracteres estranhos;
DUMP é mais técnico e detalhado.
Um registro pode parecer correto em tela, mas possuir bytes inesperados. Um campo COMP-3 gravado com layout errado pode deixar o dado aparentemente normal em parte do processo e explodir em um S0C7 na etapa seguinte.
O hex não mente. Ele apenas não se esforça para ser simpático.
9. DELETE: a palavra que Melvin não deixaria você digitar sem backup
PURGE é um parâmetro que exige cuidado. Não é um tempero para fazer o comando “funcionar melhor”. É uma autorização mais agressiva para remover o objeto sob certas condições.
Antes de executar qualquer exclusão, faça o ritual que Melvin transformaria em lei:
Confira o HLQ;
Confirme ambiente de teste, homologação ou produção;
Faça LISTCAT;
Verifique AIX e PATH associados;
Garanta backup;
Leia o JCL como se ele tivesse sido escrito por seu inimigo;
Só então submeta.
Um DELETE errado pode terminar em segundos. A explicação ao gerente, ao auditor e ao time de recuperação costuma durar muito mais.
10. Backup lógico: EXPORT, IMPORT e a diferença entre guardar dados e preservar uma estrutura
Há duas ideias que muitos iniciantes misturam:
Copiar os registros;
Preservar uma imagem lógica do VSAM.
Com REPRO, você normalmente copia dados. É ótimo para descarregar e recarregar registros.
Com EXPORT, você cria uma exportação lógica que pode ser restaurada por IMPORT.
Em produção, empresas podem usar DFSMShsm, FDR, CA Disk, ferramentas de backup corporativo, storage replication e procedimentos de disaster recovery. O IDCAMS não substitui automaticamente toda essa arquitetura.
Mas ele é importantíssimo para backup lógico, migração, laboratório e recuperação controlada.
A verdade impopular é:
Backup não testado é um arquivo de ficção científica.
Se ninguém executou um IMPORT em ambiente seguro, ninguém sabe com certeza se aquele backup salvará o dia.
11. Alternate Index: encontrar um cliente sem usar a chave principal
Suponha que seu KSDS usa CPF como chave primária. Isso é ótimo quando o usuário tem o CPF.
Mas e se o negócio pede pesquisa por agência, cidade, código do produto ou e-mail?
Você poderia criar outro arquivo inteiro. Mas isso aumenta duplicação, manutenção e risco de inconsistência.
A solução VSAM é o AIX — Alternate Index.
O AIX cria uma segunda porta de busca para o mesmo cluster base.
O VERIFY pode ajudar com informações de fim lógico e condições relacionadas a encerramento impróprio. Mas ele não é um super-herói de capa azul capaz de recuperar tudo.
Ele não substitui:
Diagnóstico;
Backup;
Recuperação corporativa;
Análise de mensagens;
Reparo de aplicação que escreveu dados errados.
Use VERIFY porque há evidência de que ele se aplica, não porque o job apresentou uma mensagem assustadora e alguém sugeriu “rodar um verify para ver se melhora”.
13. EXAMINE: o CSI dentro do Control Interval
Se VERIFY é uma checagem focada em consistência de término, EXAMINE é o investigador forense.
INDEXTEST verifica aspectos do componente de índice;
DATATEST verifica aspectos do componente de dados;
A análise pode revelar inconsistências estruturais, problemas internos e situações que exigem recuperação ou reconstrução.
Quando ouvir “o arquivo está corrompido”, não transforme isso em verdade antes de investigar.
Pode haver:
Falha de I/O;
Problema de catálogo;
Cluster aberto indevidamente;
Compartilhamento mal definido;
AIX desatualizado;
Registro gravado com layout incompatível;
Programa que fez REWRITE de forma incorreta;
Erro de chave;
Erro de concorrência;
Falha após abend;
Estrutura realmente danificada.
A frase “VSAM corrompeu” é frequentemente o equivalente técnico de “alguém mexeu aí”.
E Melvin Udall não aceitaria “alguém” como nome de responsável.
14. Reorganização: o famoso REORG que não é um botão mágico
Você escreveu “rerog”, provavelmente referindo-se a REORG — reorganização.
No VSAM, geralmente não há um único comando universal chamado simplesmente REORG, como existe em outros contextos, por exemplo no Db2. A reorganização de um VSAM costuma ser construída por etapas.
O processo clássico é:
1. Descarregar os dados com REPRO
2. Excluir ou renomear o cluster antigo
3. Criar novamente o cluster com DEFINE
4. Recarregar dados ordenados com REPRO
5. Reconstruir AIX com BLDINDEX
6. Validar e liberar o arquivo
Limpeza de estrutura após processo de recuperação.
Mas reorganizar não é penitência semanal. Se o sistema sempre volta a fragmentar rapidamente, investigue o padrão de inserção, tamanho do CI, chave, espaço livre, volume, concorrência e lógica de carga.
Não adianta trocar o tapete se a máquina continua derramando óleo.
15. ALTER, SET e os pequenos comandos que salvam jobs repetíveis
O ALTER permite modificar alguns atributos catalogados, como renomear objetos em contextos permitidos.
Exemplo conceitual:
ALTER BELLACOSA.COBOL.CLIENTES.KSDS -
NEWNAME(BELLACOSA.COBOL.CLIENTES.KSDS.OLD)
Mas não tente usar ALTER para transformar qualquer atributo estrutural que você decidiu mudar numa terça-feira. Chave, posição da chave e aspectos fundamentais da organização normalmente exigem recriação controlada.
IDCAMS também permite alguma lógica de controle com IF, THEN, ELSE, DO, END e SET.
Por exemplo, em um ambiente de testes, você pode desejar apagar um arquivo e considerar aceitável que ele já não exista:
DELETE BELLACOSA.COBOL.CLIENTES.KSDS CLUSTER
IF LASTCC = 8 THEN -
SET MAXCC = 0
Isso não significa “ignore todos os erros”. Significa tratar conscientemente uma condição esperada.
Leia os retornos com maturidade:
RC
Interpretação inicial
0
Operação concluída
4
Aviso ou condição menor
8
Erro relevante; leia as mensagens
12
Erro sério
16
Falha grave
A maior armadilha do iniciante é olhar somente o MAXCC.
Um RC=0 pode significar que o IDCAMS executou perfeitamente uma instrução que você escreveu errada para o objetivo de negócio.
Um RC=8 pode ser esperado em um DELETE de um dataset inexistente em teste.
O mainframe não premia quem decora números. Ele premia quem lê contexto.
16. Curiosidades escondidas no catálogo
Curiosidade número um: o VSAM não se orienta apenas pelo nome digitado no JCL. Ele depende do catálogo para saber o que aquele nome representa, onde está e quais são seus atributos.
Curiosidade número dois: um KSDS não é “um arquivo ordenado” no sentido ingênuo. É uma estrutura que mantém registros, chaves, índices, intervalos e regras de expansão.
Curiosidade número três: o AIX não precisa carregar uma cópia completa do registro base. Ele funciona como uma rota alternativa de acesso.
Curiosidade número quatro: muitos problemas atribuídos ao COBOL aparecem, na verdade, na fronteira entre definição IDCAMS, layout do registro, política de acesso e operação.
Curiosidade número cinco: a chave do VSAM não é necessariamente a chave de negócio mais “bonita”. Ela é uma decisão arquitetural. CPF pode funcionar para busca individual; data de movimento pode servir para lote; uma chave composta pode representar agência + conta + dígito. O importante é entender o padrão de acesso que o sistema precisa atender.
17. O mapa mental definitivo do jovem programador COBOL
Quando você olha um VSAM, pense nesta sequência:
COBOL
↓
DDNAME / JCL
↓
Cluster VSAM
├── DATA
├── INDEX
├── CI
└── CA
↓
Catálogo
↓
Disco / Storage
Se houver pesquisa alternativa:
Aplicação
↓
PATH
↓
Alternate Index
↓
Cluster Base
↓
Registro
E se houver incidente:
Mensagens no joblog
↓
SYSPRINT do IDCAMS
↓
LISTCAT
↓
VERIFY ou EXAMINE, se aplicável
↓
Backup / REPRO / EXPORT / recuperação
Esse mapa evita a visão limitada de que “VSAM é uma cláusula no SELECT”.
Não é.
VSAM é uma estrutura de dados, uma decisão de armazenamento, um conjunto de controles operacionais e, muitas vezes, uma cápsula do tempo contendo décadas de regras de negócio.
Epílogo — Melvin Udall fecha o job
No fim do dia, Melvin Udall não ficaria impressionado porque você soube escrever:
DEFINE CLUSTER
Ele perguntaria:
Você sabe onde começa sua chave?
Conferiu RECORDSIZE contra o copybook?
Sua carga está ordenada?
Sabe se existe AIX?
Reconstruiu o índice após a reorganização?
Leu o SYSPRINT?
Testou o backup?
Sabe o que fará se o arquivo estiver aberto pelo CICS?
Tem certeza absoluta de que esse DELETE aponta para teste?
E, se você respondesse “acho que sim”, ele provavelmente encerraria a conversa.
Porque em VSAM, como em produção, “acho” é uma palavra perigosa.
A boa notícia é que ninguém precisa nascer sabendo CI, CA, AIX, PATH, REPRO, VERIFY e EXAMINE. Você aprende uma camada por vez. Primeiro cria. Depois carrega. Depois consulta. Depois copia. Depois investiga. Depois entende por que os veteranos ficam muito quietos quando alguém menciona PURGE.
O jovem programador COBOL evolui quando deixa de apenas abrir e fechar arquivos.
Ele evolui quando percebe que, atrás de cada READ, existe uma cidade inteira trabalhando para que o registro correto apareça no instante correto.
E, nesse dia, até Melvin Udall talvez permita um café ao seu lado.
Vagner Renato Bellacosa trabalha com IBM Mainframe
desde 1988
,
é IBM Champion e especialista em COBOL, CICS, Db2,
z/OS e IBM Z. Compartilha experiências profissionais,
conhecimento técnico, história da computação e práticas
do universo mainframe para aproximar novas gerações das
tecnologias que sustentam empresas, bancos e governos
ao redor do mundo.
IBM Champion
IBM Z
COBOL
CICS
Db2
z/OS
Mainframe desde 1988
