Bellacosa Mainframe arpesenta o IDCAMS no Z/OS

💣 IDCAMS NÃO É SÓ DELETE E DEFINE — É O CANIVETE SUÍÇO QUE TODO DEV COBOL SUBESTIMA! 🔥

Os segredos obscuros, históricos e poderosos do utilitário que governa o mundo VSAM no z/OS

Se você é um dev COBOL sênior e acha que já viu de tudo no z/OS… cuidado. O IDCAMS é aquele tipo de ferramenta que parece simples — até o dia em que salva (ou destrói) seu ambiente em produção.

Este não é um artigo básico. É um mergulho profundo, no estilo Bellacosa Mainframe: com história, bastidores, exemplos reais, curiosidades obscuras e aqueles “easter eggs” que só quem vive o mainframe conhece.

---

🧠 O QUE É IDCAMS — DE VERDADE?

O IDCAMS (Access Method Services) é o utilitário oficial do z/OS para gerenciar datasets VSAM e não-VSAM.

Mas reduzir o IDCAMS a “DEFINE e DELETE” é como dizer que COBOL é só MOVE e PERFORM.

👉 Ele é, na prática:

• Um gerenciador de estruturas físicas de dados
• Um motor de diagnóstico
• Um orquestrador de catálogos
• Um cirurgião de datasets corrompidos

---

🕰️ ORIGEM — QUANDO TUDO COMEÇOU

O IDCAMS nasceu junto com o VSAM (Virtual Storage Access Method) lá na década de 1970, substituindo métodos mais antigos como:

• ISAM
• BDAM
• QSAM (ainda usado, mas com outro propósito)

📌 A ideia era revolucionária:

Criar um sistema de arquivos com acesso indexado, eficiente e resiliente.

E o IDCAMS virou o “painel de controle” disso tudo.

---

⚙️ O CORE DO IDCAMS — COMANDOS ESSENCIAIS

Vamos além do básico.

🔹 DEFINE — Criando um KSDS (o clássico)

//STEP01 EXEC PGM=IDCAMS
//SYSPRINT DD SYSOUT=*
//SYSIN DD *
  DEFINE CLUSTER(NAME(MEU.KSDS)
         INDEXED
         KEYS(10 0)
         RECORDSIZE(80 80)
         TRACKS(10 5)
         FREESPACE(10 10))
/*

💡 Insight avançado:

• FREESPACE impacta diretamente performance e splits
• TRACKS(prim sec) influencia fragmentação futura

---

🔹 DELETE — O perigo silencioso

DELETE MEU.KSDS CLUSTER

💣 Easter egg:
Se você rodar DELETE sem checar o catalog corretamente…
👉 Pode apagar mais do que imagina (especialmente com aliases mal configurados)

---

🔹 REPRO — O verdadeiro “MOVE” do mundo VSAM

REPRO INFILE(INPUT) OUTFILE(OUTPUT)

🔥 Muito mais poderoso do que parece:

• Migração entre VSAM ↔ PS
• Backup
• Recovery
• Testes de carga

💡 Dica de sênior:
Use REPRO ... REPLACE com extremo cuidado — ele sobrescreve sem dó.

---

🔹 LISTCAT — O raio-X do dataset

LISTCAT ENT(MEU.KSDS) ALL

📌 Aqui mora o ouro:

• CI/CA size
• Número de registros
• Status físico
• Informações de catálogo

💡 Curiosidade:
Muitos problemas de performance são detectáveis apenas com LISTCAT bem interpretado.

---

⚖️ Pontos Fortes vs Limitações

✅ Fortes

• Nativo do z/OS
• Extremamente poderoso
• Sem custo adicional
• Alta performance

❌ Limitações

• Sintaxe pouco amigável
• Documentação densa
• Erros pouco intuitivos 

---

🧪 LAB PRÁTICO — DO ZERO AO CONTROLE TOTAL

🎯 Objetivo:

Criar, popular, consultar e remover um VSAM

---

🥇 Passo 1 — Criar KSDS

Use DEFINE (já vimos)

---

🥈 Passo 2 — Inserir dados via REPRO

//INPUT DD *
0000000001CLIENTE A
0000000002CLIENTE B
/*
//OUTPUT DD DSN=MEU.KSDS,DISP=OLD

REPRO INFILE(INPUT) OUTFILE(OUTPUT)

---

🥉 Passo 3 — Validar estrutura

LISTCAT ENT(MEU.KSDS) ALL

---

🏁 Passo 4 — Limpeza controlada

DELETE MEU.KSDS CLUSTER

---

🧬 CURIOSIDADES QUE POUCOS CONHECEM

🧩 1. IDCAMS NÃO É SÓ VSAM

Ele também gerencia:

• GDG
• Catalogs
• Non-VSAM datasets

---

🧩 2. O “SET MAXCC” — o hack elegante

IF MAXCC > 0 THEN SET MAXCC = 0

🔥 Isso evita falhas em jobs quando o erro é esperado
(clássico em DELETE de dataset inexistente)

---

🧩 3. O retorno não é só 0 ou 8

Códigos comuns:

• 0 → sucesso
• 4 → warning
• 8 → erro
• 12/16 → desastre

💡 Dev sênior usa isso para lógica de controle em JCL

---

🧩 4. Você pode “debugar” storage com IDCAMS

Comandos como:

• PRINT
• VERIFY
• EXAMINE

👉 Permitem inspecionar dados em baixo nível

---

🧠 DICAS DE OURO PARA DEV COBOL SÊNIOR

✔ Nunca culpe o COBOL antes de olhar o VSAM via IDCAMS
✔ LISTCAT é seu melhor amigo em troubleshooting
✔ REPRO é sua arma secreta para testes e recovery
✔ DELETE sem critério é suicídio em produção
✔ Entender CI/CA é mais importante que decorar sintaxe

---

⚠️ ARMADILHAS REAIS (BASEADAS EM CAMPO)

💣 Dataset aparentemente vazio… mas com índice inconsistente
💣 REPRO truncando dados por RECORDSIZE incorreto
💣 DEFINE com KEYS errado causando caos silencioso
💣 Catalog apontando para dataset inexistente

---

🧠 REFLEXÃO FINAL

O IDCAMS é aquele tipo de ferramenta que separa:

• quem usa mainframe
  de quem entende mainframe

Ele opera no nível onde:
👉 estrutura física
👉 performance
👉 integridade

…se encontram.

---

☕ ESTILO BELLACOSA — VEREDITO FINAL

Se você domina COBOL mas ignora IDCAMS…

👉 você está pilotando um avião sem entender o motor.

---

💥 TABELA COMPLETA — PARÂMETROS IDCAMS (NA PRÁTICA)

---

🧱 🔹 DEFINE CLUSTER (o mais importante de todos)

Parâmetro	Tipo	Descrição	Insight de campo
NAME	obrigatório	Nome do dataset	Base de tudo
INDEXED	tipo	KSDS	Mais comum
NONINDEXED	tipo	ESDS	Sequencial
LINEAR	tipo	LDS	Usado por DB2
KEYS(length offset)	obrigatório (KSDS)	Define chave	Erro aqui = desastre
RECORDSIZE(avg max)	obrigatório	Tamanho registro	Impacta CI
FREESPACE(ci ca)	opcional	Espaço livre	Evita split
CYLINDERS(primary secondary)	opcional	Alocação	Produção padrão
TRACKS	opcional	Alternativa a cilindros	Mais granular
SHAREOPTIONS(x y)	opcional	Concorrência	CICS crítico
REUSE	opcional	Reutilização	Batch útil
SPEED	opcional	Mais rápido	Sem recovery
RECOVERY	opcional	Mais seguro	Default prod
UNIQUEKEY	opcional	Chave única	Default KSDS
NONUNIQUEKEY	opcional	Permite duplicidade	Muito usado
BUFFERSPACE	opcional	Memória	Raro
CISZ	opcional	Control Interval	Performance tuning
VOLUMES	opcional	Volume físico	Storage define
ERASE	opcional	Segurança	LGPD vibes 😄
CONTROLINTERVALSIZE	opcional	Mesmo que CISZ	Nome longo
IMBED	opcional	Índice embutido	Raro hoje
REPLICATE	opcional	Replica índice	Legado
LOG / NOLOG	opcional	Logging	Batch tuning

---

🧩 🔹 DEFINE DATA / INDEX

Parâmetro	Descrição	Observação
NAME	Nome componente	Obrigatório
CYLINDERS / TRACKS	Espaço	Separação física
VOLUMES	Volume	Multi-volume
CONTROLINTERVALSIZE	CI size	Ajuste fino
FREESPACE	Espaço livre	Mesmo conceito
BUFFERSPACE	Memória	Pouco usado

💡 Insight:
Separar DATA e INDEX melhora performance em ambientes grandes.

---

🔄 🔹 REPRO (o ETL raiz do mainframe)

Parâmetro	Descrição	Uso real
INFILE	Entrada DD	Batch clássico
OUTFILE	Saída DD
INDATASET	Entrada direta	Alternativa
OUTDATASET	Saída direta
REPLACE	Sobrescreve	Muito usado
COUNT(n)	Limite registros	Teste
SKIP(n)	Pula registros	Debug
FROMKEY	Início por chave	VSAM
TOKEY	Fim por chave	VSAM
KEYS	Intervalo	Filtro
LOG / NOLOG	Logging	Performance
FASTLOAD	Carga rápida	Grandes volumes

💣 Insight avançado:
REPRO pode substituir ferramentas ETL simples.

---

🔍 🔹 LISTCAT (diagnóstico avançado)

Parâmetro	Descrição	Uso
ENTRY / ENT	Nome dataset	Direto
ALL	Tudo	Sempre usar
LEVEL	Prefixo	Listagem
HISTORY	Histórico	Auditoria
VOLUME	Info volume	Storage
ALLOCATION	Espaço	Capacidade

💡 Dica:
LISTCAT é seu “debugger de storage”.

---

❌ 🔹 DELETE

Parâmetro	Descrição	Risco
CLUSTER	Remove tudo	Normal
DATA	Só dados	Avançado
INDEX	Só índice	Raro
PURGE	Ignora proteção	💀 perigoso
ERASE	Apaga fisicamente	Segurança
NOSCRATCH	Remove catálogo apenas	Deixa dados

---

🔧 🔹 ALTER

Parâmetro	Descrição	Uso
NEWNAME	Renomeia	Muito usado
VOLUMES	Muda volume	Storage
BUFFERSPACE	Ajuste memória	Raro

---

🖨️ 🔹 PRINT

Parâmetro	Descrição	Uso
INDATASET	Dataset	Base
CHARACTER	Texto	Debug
HEX	Hexadecimal	Debug avançado
DUMP	Dump bruto	Forense
COUNT	Limite	Teste

---

🧪 🔹 VERIFY

Parâmetro	Descrição
DATASET	Dataset alvo
RECOVER	Tenta corrigir

👉 Essencial após crash

---

⚙️ 🔹 Parâmetros via DD (tuning real)

Parâmetro	Onde	Descrição
AMP	DD	Parâmetros avançados
BUFND	AMP	Buffers de dados
BUFNI	AMP	Buffers de índice
STRNO	AMP	Concorrência
OPTCD	AMP	Modo acesso
MACRF	AMP	Método acesso

---

🧠 🔹 Parâmetros menos conhecidos (nível ninja)

Parâmetro	Descrição	Quando usar
IMBED	Índice dentro do CI	Pequenos datasets
REPLICATE	Replica índice	Legado
LOG	Logging	Auditoria
NOLOG	Sem log	Performance
SPEED	Performance	Batch
RECOVERY	Segurança	Prod

---

🤯 RELAÇÃO COM COBOL (o que ninguém explica)

Tudo isso impacta diretamente:

• FILE STATUS
• Tempo de I/O
• Locks (CICS)
• CPU usage

👉 Exemplo real:

• FREESPACE errado → split → slowdown → batch estoura janela

---

⚖️ RESUMO ESTRATÉGICO

👉 Os parâmetros mais críticos na prática:

1. KEYS
2. RECORDSIZE
3. FREESPACE
4. CISZ
5. SHAREOPTIONS
6. BUFND / BUFNI

---

🧨 VERDADE FINAL 

“IDCAMS não é sobre comando…
é sobre controle físico dos dados.”

Se você domina isso:

• Você prevê problema antes de acontecer
• Você resolve incidente sem depender de ninguém
• Você vira referência no time
• 
  

 

🔥 IBM 3592 JF – O cartucho que carrega impérios de dados

---

🧠 Introdução – quando o dado dorme em fita, mas sonha em petabytes

Se você acha que fita magnética é coisa de museu, é porque nunca encarou um IBM 3592 JF rodando em um TS1140/TS1150 dentro de um data center que parece mais uma nave espacial do que uma sala fria.
O 3592 JF não é “backup”. Ele é arquivo corporativo, retenção legal, seguro contra ransomware e, em muitos bancos, a última linha de defesa da civilização digital.

Bem-vindo ao mundo onde dados não são deletados — são arquivados com honra.

---

📜 História – da fita de rolo ao JF

A linhagem do IBM 3592 nasce no início dos anos 2000 como sucessor espiritual das 3490/3480.
O sufixo JF marca uma geração madura, refinada, feita para:

• Ambientes z/OS heavy-duty

• Integração com DFSMS/HSM

• Coexistência com VTS, TS7700 e GDPS

📼 O JF é o tipo de mídia que sobrevive a mudanças de diretoria, ERPs, fusões e três modas de cloud.

---

🧱 Arquitetura do cartucho IBM 3592 JF

Características físicas e lógicas:

• 📏 Formato proprietário IBM (não confundir com LTO)

• 💾 Capacidade nativa: ~700 GB

• 🗜️ Capacidade com compressão: até ~2–3 TB (dependendo do workload)

• 🔐 Suporte a criptografia por hardware

• 🧬 Servo tracking de altíssima precisão

💡 Easter egg: a densidade da fita é tão alta que um cartucho mal acondicionado “grita” no log do drive antes mesmo de falhar.

---

🏗️ Onde ele vive no mundo real

Normalmente você encontra o 3592 JF em:

• 🗄️ IBM TS3500 / TS4500 Tape Library

• 🧠 TS7700 (Virtual Tape Server) como mídia física de backend

• 🧾 Ambientes regulados: bancos, seguradoras, governos

Ele conversa intimamente com:

• z/OS DFSMS

• HSM (Hierarchical Storage Manager)

• DFSMShsm Migration / Recall

---

🔄 Workflow clássico no mainframe

📌 Passo a passo “vida de fita”

1. Dataset criado (PS ou GDG)

2. Política de SMS decide: disk hoje, fita amanhã

3. HSM migra o dataset para fita

4. Catalog aponta para volume JF

5. Recall on-demand traz o dado de volta

6. Dataset volta ao disco como se nada tivesse acontecido

🧙‍♂️ Magia negra mainframe: a aplicação nunca sabe que o dado dormiu em fita.

---

📊 Logs, SMF e rastros

O 3592 JF deixa pegadas elegantes:

• SMF 14/15 – uso de fita

• SMF 42 – atividades de DFSMS

• SMF 94 – criptografia

• Logs do TS7700 (se virtualizado)

📎 Dica Bellacosa: fita não mente. Se algo sumiu, o SMF sabe onde foi parar.

---

🧩 Curiosidades que só quem viveu sabe

• ☕ Drives 3592 “acordam” antes do operador terminar o café

• 🔁 Uma fita JF pode sobreviver 30 anos se bem armazenada

• 🧯 Ransomware odeia fita — ela não monta sozinha

• 🎩 Cartucho com label mal escrito vira lenda urbana no CPD

---

🛠️ Dicas práticas de sobrevivência

✔️ Padronize nomenclatura de volumes
✔️ Nunca misture JF com JE/JB sem planejamento
✔️ Use criptografia nativa, não “caseira”
✔️ Monitore recalls excessivos (sinal de má política de HSM)
✔️ Tape não é lenta — lento é acesso mal desenhado

---

📚 Guia de estudo para mainframers

📖 Leia e domine:

• DFSMS Storage Administration

• DFSMShsm Implementation

• IBM TS11xx Drive Redbooks

• SMF 14/15 deep dive

🧠 Exercício clássico:

Simule migração, expiração, recall e auditoria de um dataset crítico sem que a aplicação perceba.

---

🧪 Aplicações reais do IBM 3592 JF

• 📜 Retenção legal (7–30 anos)

• 🏦 Histórico financeiro imutável

• 🧬 Dados médicos arquivados

• 🛰️ DR offline (air gap real)

• 📦 Data lake pré-cloud que ainda funciona

---

🧨 Comentário final – El Jefe Style

Enquanto o mundo discute se “cloud é o futuro”, o IBM 3592 JF continua fazendo o que sempre fez:
guardar o passado para proteger o futuro.

No mainframe, fita não é legado.
É estratégia.

🔥 Midnight Lunch aprovado. A fita gira, o dado dorme, o mainframer sorri.

 

Bellacosa Mainframe e o idcams criando gdgs

☕ Um Café no Bellacosa Mainframe

Jimi Dini Entrou no Catálogo — O Dia em que um GDG Criou uma Geração, Sofreu ABEND e Descobriu que IDCAMS Não É Um Curandeiro de Arquivos

Ou: como deixar de chamar todo arquivo com G0001V00 de “backup”, entender por que (+1) pode virar confusão e descobrir que o verdadeiro rock-and-roll do batch é saber o que ficou no catálogo depois do RC=12

Prólogo — a fita cassete que se chamava ontem

Imagine Jimi Dini, uma criatura de camisa de flanela, café frio e paciência limitada para apresentações com setenta slides, entrando na sala de operações às três da manhã. No monitor, um job de fechamento acabou de cair com ABEND. O operador aponta para a tela e decreta:

— Relaxa. O arquivo está no GDG.

Jimi olha para o spool, toma um gole de café e responde:

— “No GDG” quer dizer o quê? Está criado? Catalogado? É a geração ativa? É a de ontem? Está pendurada em deferred roll-in? Ou alguém só viu um G0042V00 no volume e resolveu chamar isso de plano de recuperação?

É aqui que começa a educação sentimental do programador COBOL. GDG não é uma palavra mágica para “backup”; IDCAMS não é uma ambulância que ressuscita dado errado; e o catálogo não é um detalhe administrativo que alguém do storage resolve quando o seu JCL ficou feio. Os três formam uma parte muito importante da segurança operacional do batch.

Vamos desmontar essa história sem misticismo — mas com respeito pelo momento em que um DELETE ... PURGE é digitado no ambiente errado e a sala inteira fica subitamente muito silenciosa.

1. GDG: uma estante, não uma pasta com nome bonito

GDG significa Generation Data Group. É um grupo de datasets relacionados, mantidos em ordem de geração pelo z/OS. Pense numa coleção de edições de jornal: a base é o título da coleção; cada GDS (Generation Data Set) é uma edição física.

Base lógica:

BELLACOSA.FOLHA.RELATORIO

Gerações físicas que o sistema administra:

BELLACOSA.FOLHA.RELATORIO.G0001V00
BELLACOSA.FOLHA.RELATORIO.G0002V00
BELLACOSA.FOLHA.RELATORIO.G0003V00

O sufixo G0003V00 não é um ornamento que você inventa no teclado. Ele é formado pelo sistema: o número da geração e, quando necessário, o número de versão. A grande vantagem aparece quando o programa não precisa conhecer esse nome físico. Ele só pede a edição que precisa.

Referência no JCL	Tradução humana
(+1)	“Vou criar a próxima edição.”
(0)	“Quero a edição mais recente ativa.”
(-1)	“Quero a imediatamente anterior.”
(-2)	“Quero a de duas execuções atrás.”
G0042V00	“Quero exatamente esta edição física.”

Para um lote diário de extratos, isto é ouro. O job de hoje cria (+1). O processo de conferência lê (0). Uma rotina de comparação lê (-1). O JCL expressa intenção, não uma data carimbada à mão numa convenção de nomes que um dia alguém vai esquecer de atualizar.

Mas atenção: GDG administra gerações, não prova que o conteúdo está certo. Se o COBOL calculou juros usando uma taxa incorreta, você não possui um backup apenas porque o arquivo se chama G0088V00. Você possui uma versão perfeitamente organizada de um erro.

2. IDCAMS: o cartório do condomínio de datasets

IDCAMS, Access Method Services, é a ferramenta que conversa com o catálogo e administra vários objetos de dados. Ele é famoso entre programadores por criar VSAM, mas chamar IDCAMS de “o programa que cria KSDS” é como chamar um cartório de “o lugar onde se reconhece firma”. Verdadeiro, mas dramaticamente incompleto.

Com IDCAMS, podemos, entre outras coisas:

• definir e alterar bases GDG;

• listar entradas do catálogo;

• criar, apagar e alterar clusters VSAM;

• copiar ou carregar dados com REPRO;

• trabalhar com índices alternativos;

• investigar atributos que o JCL sozinho não torna tão visíveis.

O esqueleto clássico é:

//IDCAMS   EXEC PGM=IDCAMS
//SYSPRINT DD SYSOUT=*
//SYSIN    DD *
  comandos IDCAMS
/*

Guarde uma regra de sobrevivência: se IDCAMS voltar com condição diferente de zero, não pare no RC=8. Abra o SYSPRINT. O retorno é o alarme; as mensagens são o laudo médico. Elas costumam revelar se a base já existe, se uma geração possui retenção, se houve problema de autorização RACF ou se o catálogo localizou algo diferente do que você imaginava.

3. Criando a base: antes de nascer a primeira geração

Definir a base GDG não cria um arquivo de negócio. Cria a regra de vida das futuras gerações no catálogo.

//DEFGDG   EXEC PGM=IDCAMS
//SYSPRINT DD SYSOUT=*
//SYSIN    DD *
  DEFINE GENERATIONDATAGROUP -
    (NAME(BELLACOSA.FOLHA.RELATORIO) -
     LIMIT(7) -
     NOEMPTY -
     SCRATCH -
     NOPURGE)
/*

Também é válido escrever DEFINE GDG. Eu, porém, gosto de começar com GENERATIONDATAGROUP: evita que o jovem padawan imagine que está definindo um dataset sequencial. Está definindo a base, a estante e suas regras.

LIMIT(7): quantas edições cabem na estante?

LIMIT determina o número de gerações ativas. Para um job diário, LIMIT(7) pode representar uma semana. Para fechamento mensal, LIMIT(13) costuma cobrir doze meses e o atual. Para uma interface cuja correção pode levar noventa dias, talvez sete seja uma receita para uma conversa desagradável com auditoria.

O limite não deve nascer do folclore — “sempre fizemos 30” —, mas de perguntas concretas: por quantos dias pode ocorrer reprocessamento? Há retenção legal? Quem recupera um arquivo se o parceiro rejeitar a carga depois de duas semanas? Há espaço para isso? Em GDG clássico, o limite pode chegar a 255; um GDG estendido pode suportar até 999, sujeito à política do ambiente.

NOEMPTY: retire o mais antigo, não a banda inteira

Com NOEMPTY, quando chega uma nova geração acima do limite, apenas a mais velha sofre roll-off — deixa de fazer parte da base. É o comportamento normal em processamento contínuo.

Com LIMIT(3), ao criar a quarta geração:

antes: G0001, G0002, G0003
depois: G0002, G0003, G0004

EMPTY é outra conversa: quando o limite estoura, todas as gerações existentes saem da base. Há usos específicos para ciclos fechados, mas para relatório diário isso equivale a contratar Jimi Dini para organizar os arquivos e entregar-lhe um lança-chamas. Use NOEMPTY como padrão mental até que alguém explique, por escrito, por que EMPTY é necessário.

SCRATCH, NOSCRATCH, PURGE e NOPURGE: o que acontece quando a geração cai da estante?

Quando uma geração sofre roll-off, ela pode simplesmente deixar a base ou também ser removida do armazenamento:

• SCRATCH: remove o dataset físico conforme o processamento aplicável;

• NOSCRATCH: não o apaga automaticamente; ele pode continuar existindo e, no cenário SMS, ficar recatalogado fora da base como rolled off;

• NOPURGE: respeita retenção/data de expiração;

• PURGE: pode ultrapassar essa barreira de retenção.

Para operação comum, NOEMPTY, SCRATCH e NOPURGE são uma combinação honesta: remove somente a geração mais velha, libera espaço e não atropela proteção de retenção. Mas ela exige que seu LIMIT seja correto. Se a empresa precisa manter sessenta dias, LIMIT(7) com SCRATCH não é automação; é descarte programado.

4. O COBOL encontra o JCL: quem faz o quê?

O COBOL não deveria carregar a preocupação com o nome absoluto da geração. Ele abre um DDNAME. O JCL decide o dataset. O catálogo resolve a geração. Esta separação é uma das pequenas elegâncias do mainframe.

JCL que cria uma geração:

//GERAEXTR EXEC PGM=PGMEXTR
//STEPLIB  DD DSN=BELLACOSA.LOADLIB,DISP=SHR
//SYSOUT   DD SYSOUT=*
//EXTRATO  DD DSN=BELLACOSA.BATCH.EXTRATO(+1),
//            DISP=(NEW,CATLG,DELETE),
//            SPACE=(CYL,(20,10),RLSE),
//            DCB=(RECFM=FB,LRECL=200,BLKSIZE=0)

No programa:

SELECT ARQ-EXTRATO ASSIGN TO EXTRATO
       ORGANIZATION IS SEQUENTIAL
       FILE STATUS IS WS-FS-EXTRATO.

O programa escreve em EXTRATO. Não precisa saber se virou G0042V00. E isto dá liberdade para a equipe ajustar as regras de infraestrutura sem reescrever lógica de negócio.

Na execução seguinte, o mais novo pode ser lido assim:

//ENTRADA DD DSN=BELLACOSA.BATCH.EXTRATO(0),DISP=SHR

E a comparação com o anterior:

//HOJE    DD DSN=BELLACOSA.BATCH.EXTRATO(0),DISP=SHR
//ONTEM   DD DSN=BELLACOSA.BATCH.EXTRATO(-1),DISP=SHR

Esse é um ponto em que a vida do iniciante melhora: (+1) é para criar; (0) é a geração ativa mais recente; (-1) é a anterior. Não tente tratar (+1) como “o arquivo de hoje para leitura em qualquer etapa paralela”. O momento do catalogamento e o fluxo do job importam.

5. A cena do crime: job caiu ao criar (+1)

Agora chegamos à pergunta que separa quem decorou sintaxe de quem começa a entender operação.

O job aloca:

BELLACOSA.BATCH.EXTRATO(+1)

O z/OS reserva o nome físico, o programa começa a escrever e então acontece um ABEND: um S0C7, falta de espaço, falha de I/O, queda de subsistema ou aquela rotina antiga que decide que o valor HIGH-VALUES é uma proposta de carreira.

Pode sobrar uma geração física criada, por exemplo G0042V00, sem que ela tenha sido incluída como geração ativa na base. Esse é um estado conhecido como deferred roll-in. Na prática, o arquivo pode estar no DASD, mas (0) ainda aponta para a geração anterior.

O primeiro impulso de alguém é executar de novo. Às vezes funciona. Às vezes transforma um incidente simples numa investigação arqueológica.

Primeiro, investigue:

//LISTGDG  EXEC PGM=IDCAMS
//SYSPRINT DD SYSOUT=*
//SYSIN    DD *
  LISTCAT ENT(BELLACOSA.BATCH.EXTRATO) ALL
  LISTCAT LVL(BELLACOSA.BATCH.EXTRATO) ALL
/*

Depois, leia o spool: JESMSGLG, JESJCL, SYSPRINT e os SYSOUTs do programa. Você quer saber: a geração existe? O conteúdo foi fechado corretamente? O job morreu antes ou depois de gravar? A geração deveria sobreviver? Há outro job dependente em execução?

Se a GDS estiver íntegra e for realmente a geração que deve entrar na base, IDCAMS oferece a correção de catálogo:

//ROLLIN   EXEC PGM=IDCAMS
//SYSPRINT DD SYSOUT=*
//SYSIN    DD *
  ALTER BELLACOSA.BATCH.EXTRATO.G0042V00 ROLLIN
/*

O ROLLIN torna a geração ativa no GDG. É a ferramenta certa para a pergunta certa: “a geração existe e está boa, mas não foi associada à base”. Não a use como ritual automático após todo ABEND. Se o programa morreu depois de gravar metade do arquivo, colocar essa geração no GDG é apenas catalogar oficialmente um problema.

6. Reexecutar, corrigir ou recuperar? Três verbos, três decisões

Jimi Dini escreveria isto na parede da sala de controle: não conserte catálogo antes de decidir se o dado merece ser preservado.

Caso A — o conteúdo está correto, mas a geração não entrou

Valide volume, tamanho, quantidade de registros, totais de controle e sinal de término da aplicação. Se tudo estiver íntegro, ALTER ... ROLLIN pode ser a escolha adequada.

Caso B — o conteúdo está errado

Não “edite” a geração em silêncio para fingir que nada ocorreu. Corrija a causa, gere uma nova (+1) e documente o reprocessamento. A beleza do GDG é justamente preservar a sequência. Uma geração nova, correta e auditável costuma ser muito mais defensável que uma cirurgia clandestina na geração anterior.

Caso C — a geração está incompleta ou descartável

Depois de confirmação operacional, a geração física pode precisar ser excluída e o job reexecutado de maneira controlada. Isto não deve ser decidido pelo programador isolado em produção: há scheduler, dependências, retenção, RACF e possíveis consumidores do arquivo.

O vilão frequente é o segundo job disparado antes que o primeiro tenha sido tratado. Em GDS SMS no DASD, o mecanismo de GDS reclaim pode reutilizar uma geração pendente quando outro job tenta criar o mesmo (+1). Isso pode sobrescrever conteúdo anterior. Portanto, interrompa dependentes, entenda o estado e só então rerode.

7. ALTER, LISTCAT, DELETE: ferramentas, não martelos

LISTCAT é sua lanterna:

LISTCAT ENT(BELLACOSA.BATCH.EXTRATO) ALL

Ele permite enxergar atributos da base, limite e gerações. Use antes de tomar decisão destrutiva.

ALTER ajusta a política:

ALTER BELLACOSA.BATCH.EXTRATO LIMIT(45)

Isso aumenta a capacidade futura de retenção. Não traz de volta dados que já sofreram scratch. Também vale lembrar: reduzir limite pode provocar roll-off das gerações mais antigas. Não trate um ALTER LIMIT como ajuste cosmético.

DELETE faz exatamente o que o nome promete:

DELETE BELLACOSA.BATCH.EXTRATO.G0042V00

apaga uma geração específica; enquanto:

DELETE BELLACOSA.BATCH.EXTRATO GDG

atinge a base GDG. Isso é reconstrução, não manutenção corriqueira. Antes de qualquer DELETE, confirme ambiente, HLQ, entrada de catálogo, volumes e autorização. O personagem que diz “é só um GDG de teste” merece ao menos uma segunda verificação — porque o ambiente de teste costuma ter um nome suspeitosamente parecido com produção numa sexta-feira.

8. VERIFY não é varinha mágica

Outro equívoco comum: ouvir que IDCAMS possui VERIFY e concluir que ele corrige qualquer GDG. Não. VERIFY está ligado à verificação de consistência de estruturas VSAM e catálogo em cenários próprios. Ele não confere se a regra de cálculo do seu COBOL estava correta; não repõe registros faltantes num arquivo sequencial; não transforma uma GDS truncada em extrato válido.

Para GDG, pense assim:

Sintoma	Ação inicial correta
Arquivo lógico aponta para a geração errada	LISTCAT, avaliar estado e ROLLIN se aplicável
Geração não existe	Investigar job, retenção, scratch, backup e catálogo
Dados têm erro de negócio	Corrigir programa/parâmetro e reprocessar para nova geração
Retenção está pequena	ALTER LIMIT, com avaliação de espaço e auditoria
Estrutura VSAM está inconsistente	Acionar procedimento VSAM/storage; pode envolver VERIFY
Catálogo parece corrompido	Escalar ao storage/system programmer; não recriar base no improviso

O IDCAMS é excelente, mas não substitui diagnóstico. Ele administra registros de catálogo; seu processo operacional decide o que é dado confiável.

9. Passo a passo do jovem padawan antes de mexer num GDG

Quando um job com GDG falhar, siga este roteiro:

1. Pare o reflexo de rerodar. Veja se existem dependentes e evite duas tentativas criando o mesmo (+1).

2. Leia o ABEND e o spool. Descubra a causa, não só o código final.

3. Liste a base. Use LISTCAT ENT(nome-da-base) ALL.

4. Identifique a geração física. Ela existe? Está ativa, rolled off ou pendente?

5. Valide o conteúdo. Totais, contagem, trailer, retorno da aplicação, volume e integridade esperada.

6. Escolha conscientemente. ROLLIN se a geração boa não entrou; novo (+1) se deve reprocessar; descarte controlado se está incompleta.

7. Registre a decisão. Ticket, evidência de totals e horário da intervenção valem ouro na auditoria.

8. Libere a cadeia somente após a consistência. O próximo consumidor não deve descobrir o problema por acidente.

10. Curiosidades para contar no café — sem quebrar produção

Uma GDG pode ser muito mais antiga que boa parte do código Java que hoje a consome. E ainda assim ela resolve um problema moderno: versionamento de dados em lote. A diferença é que, no z/OS, esse versionamento está acoplado a catálogo, retenção, JCL, segurança e operação de grandes volumes — não a uma pasta chamada backup_final_agora_vai_3.

Outra curiosidade: o sufixo absoluto existe para quando uma referência precisa ser imutável. Usar (0) é ótimo para “a mais recente”; usar G0042V00 é apropriado quando uma auditoria, reconciliação ou reexecução exige provar que foi aquela geração, e não a que veio depois.

Por fim, GDG não elimina backup, disaster recovery, retenção corporativa ou cópia para fita/cloud. Ele ajuda a manter versões operacionais de datasets. Backup protege contra outra classe de problemas: perda de volume, desastre, corrupção ampla, retenção longa e erros que só foram percebidos quando todas as gerações úteis já saíram da estante.

Epílogo — o som que fica depois do ABEND

No fim da madrugada, Jimi Dini fecha o SYSPRINT, confere o LISTCAT e deixa uma frase para o programador COBOL iniciante:

— O mainframe não é antigo; ele só não confia em improviso.

GDG oferece uma cronologia clara. IDCAMS administra a cronologia no catálogo. JCL declara como cada etapa usa essa cronologia. COBOL processa os registros. Quando algo falha, a resposta madura não é “reroda e vê”. É descobrir o que foi alocado, o que foi catalogado, o que está íntegro e qual ação preserva tanto o negócio quanto a rastreabilidade.

Quando você entende isso, (+1) deixa de ser uma sequência estranha entre parênteses. Ele se torna uma promessa operacional: “esta é a próxima versão do dado; trate-a com o respeito que ela terá quando alguém precisar explicar seu conteúdo daqui a três meses.

Bellacosa Mainframe trabalhando com jcl datasets o parametro disp

☕ O Holocron do DISP: O Pequeno Parâmetro de JCL que Decide o Destino de Bilhões de Registros no IBM Z

"Todo Padawan COBOL aprende SHR, OLD, NEW e MOD na primeira semana. O problema é que a maioria só descobre o verdadeiro significado dessas quatro letras depois do primeiro incidente em produção às 02h17 da madrugada."

Há algo fascinante no universo IBM Z.

As coisas mais poderosas quase sempre parecem pequenas.

Um simples DD Statement.

Um DSN.

Um SPACE.

Um UNIT.

E escondido entre vírgulas aparentemente inocentes, encontramos um dos maiores guardiões do processamento batch corporativo:

DISP=(...)

Para muitos desenvolvedores iniciantes, DISP é apenas uma exigência burocrática do JCL.

Para um analista de produção experiente, um administrador de armazenamento, um Sysprog z/OS ou um veterano de operações, DISP é outra coisa completamente diferente.

DISP é um contrato.

Um acordo silencioso entre a aplicação, o Allocation Manager do z/OS, o Catalog Manager, o SMS, o RACF, o JES2, o DFSMS e, em alguns casos, o próprio destino profissional do programador que escreveu o JCL.

O Primeiro Ensinamento do Holocron

O formato completo parece simples.

DISP=(status,normal,abnormal)

Mas nele estão escondidas três decisões críticas.

Primeira decisão:

Como acessar o dataset?

Segunda decisão:

O que fazer quando tudo der certo?

Terceira decisão:

O que fazer quando tudo der errado?

E no mundo corporativo, convenhamos, a terceira pergunta costuma ser muito mais importante.

---

DISP não é um parâmetro. É governança.

Quando um Job chega ao JES2, ele inicia uma pequena jornada.

Converter.

Interpreter.

Allocation.

SMS.

Catalog.

Open.

Execution.

E é justamente durante a fase de Allocation que DISP deixa de ser texto e passa a ser política operacional.

O sistema precisa responder perguntas difíceis:

• O dataset existe?

• Está catalogado?

• O usuário possui permissão RACF?

• Existe alguém usando esse arquivo?

• Posso criar outro?

• Preciso esperar?

• Posso deletar em caso de ABEND?

O programador enxerga:

DISP=OLD

O z/OS enxerga:

"Preciso obter um ENQ exclusivo sobre esse recurso, validar segurança, localizar volumes, conversar com SMS e garantir que ninguém mais toque nesse arquivo."

---

DISP=SHR — A Grande Ilusão do Compartilhamento

Todo curso ensina:

SHR significa compartilhado.

Correto.

Mas incompleto.

SHR significa:

Shared Allocation

Não significa:

Shared Update

Não significa:

Ausência de Lock

Não significa:

Concorrência segura

Imagine uma biblioteca pública.

Todos podem ler o mesmo livro.

Mas ninguém pode arrancar páginas enquanto outra pessoa está lendo.

É exatamente assim que funciona.

Em datasets sequenciais tradicionais, SHR costuma conviver bem.

Já em VSAM, RLS, Image Copies do DB2, GDGs ou arquivos manipulados por utilitários específicos, a história muda bastante.

O programador júnior pensa:

"SHR deixa todo mundo acessar."

O Sysprog pensa:

"Qual será o modo do ENQ?"

Porque internamente existe algo parecido com:

QNAME=SYSDSN
RNAME=CLIENTE.MASTER
MODE=SHR

E isso faz toda a diferença.

---

DISP=OLD — O Parâmetro Mais Injustiçado do Mainframe

Existe um mito muito antigo.

OLD significa atualização.

Não.

OLD significa:

Alocação Exclusiva.

Ponto.

Você pode abrir um dataset com DISP=OLD apenas para leitura.

Pode fazer backup.

Pode reorganizar.

Pode executar IDCAMS.

Pode executar IEBCOPY.

Pode fazer SORT.

Pode executar DFSORT.

Pode simplesmente garantir que ninguém mexa naquele arquivo durante sua execução.

Na prática, OLD é o equivalente ao programador veterano dizendo:

"Esse arquivo é meu por enquanto. Todos os outros aguardem."

E é justamente aí que começam algumas das histórias mais curiosas das centrais de produção.

Quem nunca viu:

IEC161I

ou

WAITING FOR DATASET

durante quatro horas seguidas?

Normalmente existe um DISP=OLD escondido em algum lugar.

---

DISP=NEW — O Nascimento de um Dataset

NEW é quase poético.

Ele representa criação.

Nascimento.

Um novo objeto no universo z/OS.

Mas NEW possui exigências.

Não basta desejar.

É necessário informar:

SPACE.

DCB.

UNIT.

Ou confiar no SMS.

Exemplo clássico:

DISP=(NEW,CATLG,DELETE)
SPACE=(CYL,(10,5))
DCB=(RECFM=FB,LRECL=80)

Exemplo moderno:

DATACLAS=FB80
STORCLAS=FAST
MGMTCLAS=PROD

Hoje o SMS resolve muito do trabalho.

Mas o princípio permanece.

NEW espera algo importante:

O dataset não deve existir.

Caso contrário:

IEC141I

aparece para lembrar que o universo IBM Z não gosta de duplicidades.

---

DISP=MOD — O Diário que Nunca Termina

Minha analogia favorita continua sendo a do diário.

Imagine um caderno.

Você não rasga páginas antigas.

Você apenas continua escrevendo.

É isso que MOD faz.

Posiciona no EOF.

Acrescenta registros.

Mantém histórico.

Parece inofensivo.

Até descobrirmos um arquivo de auditoria criado em 2009.

Hoje com 780 GB.

Com backup demorando três horas.

E restore demorando mais quatro.

Tudo porque alguém escreveu:

DISP=MOD

e nunca mais voltou para revisar.

---

O Poder Oculto do Segundo e Terceiro Parâmetros

É aqui que mora a verdadeira maturidade técnica.

Considere:

DISP=(NEW,CATLG,DELETE)

Sucesso?

Cataloga.

ABEND?

Delete.

Elegante.

Limpo.

Seguro.

Agora observe:

DISP=(NEW,PASS,DELETE)

Esse é um dos favoritos dos veteranos.

O arquivo passa de STEP em STEP.

Nunca é catalogado.

Nunca polui o catálogo corporativo.

No final do Job desaparece.

Quase zen.

Outro clássico pouco lembrado:

DISP=(OLD,KEEP,KEEP)

Nada muda.

Tudo permanece.

Independentemente do resultado.

---

O Sysprog Não Lê DISP. Ele Faz Perguntas.

Ao olhar um DD Statement, um Sysprog experiente não pensa em SHR ou OLD.

Ele pensa:

• Haverá contenção?

• Existe risco de SB37?

• O SMS conseguirá alocar?

• O RACF permitirá acesso?

• O restart será possível?

• O GDG crescerá indefinidamente?

• O backup continuará viável?

• O catálogo ficará consistente?

• Um Job crítico ficará esperando às 02h17 da manhã?

Porque muitos incidentes de produção começam exatamente assim:

DISP=(...)

E terminam com uma reunião às 09h00 envolvendo operações, infraestrutura, armazenamento, segurança e o desenvolvedor que jurava ter apenas "copiado um JCL antigo".

---

O Último Conselho ao Padawan COBOL

Aprender SHR, OLD, NEW e MOD é fácil.

Entender ENQ.

Catalog Management.

SMS.

RACF.

GDG.

VSAM.

Restart.

Contenção.

Boas práticas operacionais.

Isso leva anos.

O verdadeiro profissional de IBM Z não escreve apenas programas.

Ele administra recursos compartilhados de uma plataforma responsável por processar cartões de crédito, aposentadorias, seguros, bolsas de valores, transações bancárias e sistemas governamentais de países inteiros.

E talvez seja justamente essa a grande beleza do Mainframe.

No IBM Z, até uma pequena linha de JCL pode carregar responsabilidades suficientes para sustentar bilhões de registros, milhares de empresas e décadas de história computacional.

E tudo isso começa com uma única palavra.

DISP.

Este é o tipo de conhecimento que transforma um simples usuário de JCL em alguém capaz de compreender os mecanismos invisíveis que mantêm o coração batch do IBM Z pulsando silenciosamente há mais de meio século.