✨ 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

Mostrar mensagens com a etiqueta gdg. Mostrar todas as mensagens

sábado, 10 de janeiro de 2026

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

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:

KEYS
RECORDSIZE
FREESPACE
CISZ
SHAREOPTIONS
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

terça-feira, 16 de janeiro de 2024

🔥 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”

Dataset criado (PS ou GDG)
Política de SMS decide: disk hoje, fita amanhã
HSM migra o dataset para fita
Catalog aponta para volume JF
Recall on-demand traz o dado de volta
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.

domingo, 4 de dezembro de 2016

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

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

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.

quinta-feira, 17 de abril de 2014

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

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.

sexta-feira, 26 de julho de 2013

☕🔥 ABEND S013 — O “GUARDIÃO DOS DATASETS” NO z/OS

Bellacosa Mainframe abend s013

☕🔥 ABEND S013 — O “GUARDIÃO DOS DATASETS” NO z/OS

Quando o Mainframe Diz:

“VOCÊ ESTÁ TENTANDO USAR O ARQUIVO DO JEITO ERRADO.”

Se existe um ABEND que faz o programador COBOL Junior questionar:

“O problema é no JCL?”
“No arquivo?”
“No DCB?”
“No RECFM?”
“No LRECL?”
“NO UNIVERSO?!”

…esse ABEND é o lendário:

🚨 S013

E normalmente ele aparece assim:

IEC141I 013-20

ou:

ABEND=S013

ou:

IEC141I 013-34

☕ Respira, Padawan.

Porque o S013 é um dos ABENDs MAIS IMPORTANTES para aprender:

dataset organization

DCB

RECFM

LRECL

BLKSIZE

OPEN/CLOSE/EOV

integridade física do arquivo

🔥 O QUE É O S013?

O S013 é um:

🚨 DCB / DATASET OPEN ERROR

Traduzindo:

O z/OS NÃO CONSEGUIU ABRIR O DATASET CORRETAMENTE.

☕ A FILOSOFIA DO S013

O dataset existe.

O JCL existe.

O programa existe.

Mas:

ALGUMA CARACTERÍSTICA DO ARQUIVO NÃO BATE.

🔥 O MAINFRAME É OBCECADO POR ESTRUTURA

No mundo distribuído:

abre arquivo

No z/OS:

qual RECFM?
qual LRECL?
qual BLKSIZE?
FB?
VB?
VBS?
U?
QSAM?
VSAM?

Porque:

arquivo no mainframe é estrutura física rigorosa.

☕ ANALOGIA BELLACOSA MAINFRAME

Imagine um trem tentando entrar num túnel.

Mas:

largura errada
altura errada
trilho incompatível

Resultado:

💥 S013

🔥 O MOMENTO EXATO DO S013

Fluxo:

COBOL OPEN
 ↓
OPEN/CLOSE/EOV
 ↓
Validação DCB
 ↓
Mismatch
 ↓
S013

☕ O QUE É DCB?

DATA CONTROL BLOCK

O DNA do dataset.

Define:

RECFM
LRECL
BLKSIZE
DSORG

🔥 O S013 MAIS FAMOSO

🚨 S013-20

O rei absoluto dos juniors.

☕ O QUE SIGNIFICA S013-20?

DCB incompatível

Geralmente:

RECFM errado
LRECL errado
programa espera algo diferente

🔥 EXEMPLO CLÁSSICO

Arquivo real:

RECFM=FB
LRECL=80

Mas COBOL define:

FD CLIENTE
   RECORD CONTAINS 120 CHARACTERS.

Resultado:

☠️ S013-20

☕ O MAINFRAME OLHA E DIZ

“O TAMANHO NÃO BATE.”

🔥 OUTRO CLÁSSICO

Arquivo:

VB

Programa espera:

FB

Resultado:

💥 S013

☕ FB vs VB — A GUERRA ETERNA

☕ FB

Fixed Block.

Todos registros possuem mesmo tamanho.

☕ VB

Variable Block.

Registros variáveis.

Possui RDW.

🔥 O RDW — O BYTE FANTASMA

VB possui:

Record Descriptor Word

4 bytes extras no início.

Junior esquece isso.

Resultado:

☠️ caos absoluto.

☕ O S013 E O COBOL

Outro clássico:

01 REGISTRO PIC X(100).

Mas dataset:

LRECL=80

Resultado:

💥 S013

🔥 O S013 E O SORT

SORT cria dataset:

VB

Programa batch espera:

FB

Explosão inevitável.

☕ O S013 E O DISP

Outro caso famoso.

//ARQ DD DISP=OLD

Mas dataset não permite acesso correto.

Ou:

está vazio
está corrompido
organização errada

🔥 O S013-14

Muito ligado a:

OPEN ERROR

Problemas físicos/lógicos na abertura.

🔥 O S013-18

Associado a:

DCB inconsistente

🔥 O S013-34

Muito famoso em:

RECFM incompatível

☕ COMO INVESTIGAR O S013 PASSO A PASSO

✅ PASSO 1 — IDENTIFIQUE O SUBCÓDIGO

Exemplo:

013-20

O número após hífen é crucial.

✅ PASSO 2 — IDENTIFIQUE O DDNAME

Mensagem:

IEC141I 013-20,JOB1,STEP01,CLIENTE

DDNAME:

CLIENTE

✅ PASSO 3 — VERIFIQUE O DATASET

Use:

3.4 ISPF

ou:

LISTDSI

Verifique:

RECFM
LRECL
BLKSIZE
DSORG

✅ PASSO 4 — VERIFIQUE O FD COBOL

Exemplo:

FD CLIENTE
01 REG-CLIENTE PIC X(120).

Compare com dataset REAL.

✅ PASSO 5 — VERIFIQUE O JCL

Talvez:

DCB=(RECFM=FB,LRECL=80)

mas programa espera:

🔥 O SEGREDO DOS DUMPS

S013 normalmente NÃO exige dump profundo estilo S0C4.

O ouro está nas:

mensagens IEC

☕ AS MENSAGENS IEC SÃO A BÍBLIA

Exemplo:

IEC141I
IEC143I
IEC130I

Elas contam:

dataset
problema
DCB
incompatibilidade

🔥 COMO O VETERANO PENSA

Veterano vê:

013-20

E imediatamente pergunta:

“FB ou VB?”

☕ O MAIOR ERRO DOS JUNIORS

Pensar:

“O problema está no COBOL.”

Frequentemente está em:

JCL
DCB
dataset
utilitário
SORT anterior

🔥 O S013 E O IDCAMS

Outro clássico.

DEFINE CLUSTER cria:

LRECL diferente

Programa usa layout antigo.

Resultado:

💥 S013

☕ O S013 E O GDG

Geração nova criada com DCB errado.

Toda cadeia explode depois.

🔥 O S013 FANTASMA

O mais traiçoeiro.

Problema nasceu:

ontem

Mas explode:

hoje

Porque dataset foi criado incorretamente antes.

☕ O S013 E O “RECFM U”

Modo arquimago ativado.

Datasets:

RECFM=U

são “Undefined”.

Muito usados em:

loadlibs
executáveis
dumps

Ler isso como FB?

☠️ desastre garantido.

🔥 COMO EVITAR S013

✅ Sempre validar RECFM

✅ Sempre validar LRECL

✅ Revisar DCB no JCL

✅ Padronizar copybooks

✅ Conferir SORTs

✅ Verificar geração GDG

✅ Nunca assumir FB/VB

☕ O SEGREDO DO IEBGENER

Ferramenta clássica para testar datasets.

Veteranos usam para:

validar DCB
testar leitura
confirmar estrutura

🔥 CURIOSIDADE HISTÓRICA

O S013 vem dos tempos do:

IBM OS/360

Década de:

🏛️ 1960

Naquela época:

fitas
discos
blocagem física

eram fundamentais.

O sistema precisava garantir:

integridade absoluta da mídia.

☕ EASTER EGG MAINFRAME

Veteranos brincam:

“S013 é o dataset dizendo:

VOCÊ NÃO ME ENTENDE.”

🔥 O MAIOR APRENDIZADO

S013 ensina algo profundo:

NO MAINFRAME, ARQUIVO NÃO É “SÓ UM ARQUIVO”.

É:

geometria
física
organização
blocagem
arquitetura

☕ A VERDADE FINAL

O S0C7 pune números inválidos.
O S0C4 pune memória inválida.
Mas…

☕ O S013 PUNE QUEM NÃO RESPEITA A ESTRUTURA SAGRADA DOS DATASETS NO z/OS.

quinta-feira, 22 de março de 2007

O que é DSN em JCL?

Bellacosa Mainframe explicando dsn em jcl

O que é DSN em JCL?

No ambiente Mainframe, DSN significa:

Data Set Name

Ou seja:

Nome de um Dataset

O parâmetro DSN= é um dos mais utilizados em JCL e serve para informar qual arquivo (dataset) será utilizado por um programa, utility ou procedimento.

Definição Simples

Pense no DSN como o caminho de um arquivo no Windows.

Windows:

C:\ARQUIVOS\CLIENTES.TXT

Mainframe:

USER.PROJETO.CLIENTES

Esse nome é o DSN.

Exemplo Básico

//ARQENT DD DSN=USER.PROJETO.CLIENTES,
//       DISP=SHR

Onde:

DSN=USER.PROJETO.CLIENTES

é o dataset utilizado.

Significado da Sigla

Sigla	Significado
DS	Data Set
N	Name
DSN	Data Set Name

Estrutura de um DSN

Um dataset é composto por qualificadores.

Exemplo:

EMPRESA.FINANCEIRO.CLIENTES

Cada parte possui significado.

EMPRESA
   ↓
FINANCEIRO
   ↓
CLIENTES

Exemplo Corporativo

BANCO.PRODUCAO.COBOL
BANCO.TESTE.COBOL
BANCO.CLIENTES.VSAM
BANCO.JCL.PROC

Uso em DD Statements

O uso mais comum.

//ENTRADA DD DSN=USER.ARQ.ENTRADA,
//            DISP=SHR

Dataset Sequencial

//SAIDA DD DSN=USER.ARQ.SAIDA,
//          DISP=OLD

Dataset VSAM

//CLIENTE DD DSN=BANCO.CLIENTE.KSDS,
//            DISP=SHR

Dataset GDG

//RELAT DD DSN=USER.RELATORIO.GDG(+1),
//          DISP=(NEW,CATLG)

Dataset Temporário

//SORTWK DD DSN=&&TEMP,
//           DISP=(NEW,PASS)

O dataset existe apenas durante o Job.

DSN e DISP

Normalmente aparecem juntos.

//ARQ DD DSN=USER.CLIENTES,
//        DISP=SHR

Onde:

DSN = Nome do Dataset

DISP = Como será utilizado

DSN em Criação de Arquivos

//SAIDA DD DSN=USER.NOVO.ARQUIVO,
//          DISP=(NEW,CATLG,DELETE),

O dataset será criado.

DSN em SYSUT1 e SYSUT2

Muito comum em utilities.

//SYSUT1 DD DSN=USER.ARQ.ORIGEM,
//            DISP=SHR
//SYSUT2 DD DSN=USER.ARQ.DESTINO,
//            DISP=(NEW,CATLG)

DSN em IDCAMS

//ARQVSAM DD DSN=EMPRESA.CLIENTE.KSDS

DSN em SORT

//SORTIN DD DSN=USER.CLIENTES,
//           DISP=SHR

//SORTOUT DD DSN=USER.CLIENTES.ORD,
//            DISP=(NEW,CATLG)

DSN e Catálogo

O catálogo do z/OS mantém informações sobre o dataset.

Quando informamos:

DSN=USER.CLIENTES

o sistema consulta o catálogo para localizar o arquivo.

Regras para Nomes

Um DSN:

✅ Pode ter até 44 caracteres

✅ Pode possuir vários qualificadores

✅ Usa ponto (.) como separador

Exemplo:

EMPRESA.FINANCEIRO.ARQUIVOS.CLIENTES

Qualificadores

Cada qualificador pode ter:

1 a 8 caracteres

Exemplo:

EMPRESA
FINANCE
CLIENTES

Caracteres Permitidos

Normalmente:

A-Z
0-9
@
#
$

Exemplo Real

//STEP01 EXEC PGM=COBOLPGM

//ENTRADA DD DSN=BANCO.PROD.CLIENTES,
 //          DISP=SHR

//SAIDA DD DSN=BANCO.PROD.RELATORIO,
 //         DISP=(NEW,CATLG,DELETE)

Erros Comuns

Dataset Não Existe

IEC141I
DATA SET NOT FOUND

Nome Incorreto

JCL ERROR

Dataset Em Uso

DATA SET IN USE

Boas Práticas

✅ Utilizar nomenclatura padronizada

✅ Separar Produção e Teste

✅ Usar qualificadores significativos

✅ Evitar nomes genéricos

Curiosidade

O conceito de DSN existe desde os primeiros sistemas OS/360 da IBM nos anos 1960. Mesmo após décadas de evolução tecnológica, ele continua sendo uma das estruturas fundamentais do z/OS, organizando bilhões de datasets utilizados diariamente por bancos, seguradoras e governos.

Resumo Rápido

Comando	Função
DSN=USER.ARQ	Dataset existente
DSN=ARQ(+1)	Nova geração GDG
DSN=&&TEMP	Dataset temporário
DSN=ARQ.VSAM	Arquivo VSAM
DSN=ARQ.SEQ	Arquivo sequencial

Conclusão

O DSN (Data Set Name) é o nome lógico de um dataset no Mainframe. Utilizado principalmente em instruções DD do JCL, ele identifica arquivos sequenciais, VSAM, GDGs, bibliotecas, datasets temporários e diversos outros recursos do z/OS. Dominar o uso de DSN é um dos primeiros passos para compreender JCL, Batch e administração de arquivos em ambientes Mainframe.

Translate

sábado, 10 de janeiro de 2026