ABEND S013 — Anatomia Completa do OPEN no z/OS

 

Bellacosa Mainframe e o abend s013

☕ Um Café no Bellacosa Mainframe

ABEND S013 — Anatomia Completa do OPEN no z/OS

Como um Programador COBOL Padawan Pode Pensar Como um Engenheiro de Sistemas ao Investigar Datasets

"O programador júnior acredita que o programa abre um arquivo. O programador experiente sabe que, antes disso, o z/OS inicia uma longa conversa com o sistema operacional, o catálogo, o SMS, o Access Method e a própria mídia. O ABEND S013 acontece quando algum desses participantes responde: 'isso não faz sentido'."

---

O Mistério do OPEN

Quase todo programador COBOL escreve algo parecido com isto:

OPEN INPUT ARQ-CLIENTE

Uma única instrução.

Cinco letras.

OPEN.

Mas, no IBM Z, essa talvez seja uma das instruções mais sofisticadas de toda a linguagem.

No Windows, Linux ou macOS, abrir um arquivo costuma significar localizar um caminho no sistema de arquivos, verificar permissões e entregar um ponteiro para leitura.

No z/OS, não.

Quando o programa executa um OPEN, ele desencadeia uma sequência de validações que existe desde os tempos do IBM System/360, na década de 1960. Esse mecanismo evoluiu ao longo de mais de sessenta anos justamente porque bancos, bolsas de valores, companhias aéreas e órgãos governamentais não podem correr o risco de interpretar um dataset de forma incorreta.

É nesse momento que nasce o ABEND S013.

E, para entendê-lo de verdade, precisamos abandonar a ideia de que "arquivo é apenas um arquivo".

---

A Filosofia do Mainframe

O IBM Z nunca confiou cegamente nas aplicações.

Ele parte de uma premissa simples:

"Antes de entregar qualquer dado ao programa, vou verificar se ele realmente sabe interpretar esse dataset."

Isso parece exagero?

Imagine um programa esperando registros de 80 bytes e recebendo registros de 300 bytes.

Ou esperando registros fixos (FB) quando o dataset contém registros variáveis (VB).

Ou lendo um executável (RECFM=U) como se fosse um arquivo texto.

Em poucos segundos, a memória seria corrompida e os dados poderiam ser interpretados de forma incorreta.

Em ambientes financeiros, isso seria inaceitável.

Por isso o z/OS prefere interromper imediatamente a execução.

É exatamente esse o espírito do S013.

---

O Que Realmente Acontece Durante o OPEN

Quando o COBOL executa:

OPEN INPUT CLIENTE

o sistema operacional inicia uma sequência de etapas invisíveis ao programador.

Em alto nível, o fluxo é semelhante ao seguinte:

Programa COBOL
      │
      ▼
Language Environment
      │
      ▼
OPEN Macro
      │
      ▼
OPEN/CLOSE/EOV
      │
      ▼
Access Method (QSAM/BSAM/VSAM)
      │
      ▼
Leitura do JFCB
      │
      ▼
Consulta ao Catálogo
      │
      ▼
Leitura do DSCB
      │
      ▼
Aplicação das regras SMS
      │
      ▼
Validação do DCB
      │
      ▼
Arquivo liberado

Se qualquer uma dessas etapas detectar inconsistências, o OPEN é interrompido antes mesmo da primeira leitura.

---

O OPEN Não Abre Apenas um Dataset

Essa é uma das maiores descobertas para quem está começando.

O OPEN não verifica somente se o dataset existe.

Ele precisa responder perguntas como:

• o dataset foi catalogado corretamente?

• existe volume disponível?

• o dispositivo está online?

• o usuário possui autorização?

• o DDNAME aponta para o dataset correto?

• o RECFM é compatível?

• o LRECL corresponde ao esperado?

• o BLKSIZE faz sentido?

• o DSORG é suportado?

• o Access Method escolhido consegue acessar esse tipo de organização?

Cada resposta negativa pode produzir mensagens diferentes.

O S013 aparece quando essas verificações relacionadas à abertura e aos atributos físicos do dataset falham.

---

Quem São os Participantes Dessa Conversa?

Quando o OPEN é executado, vários componentes trabalham em conjunto.

O Programa COBOL

Ele informa como pretende utilizar o arquivo.

Exemplo:

OPEN INPUT CLIENTE

ou

OPEN OUTPUT CLIENTE

Além disso, a FD define características lógicas do registro:

FD CLIENTE.
01 REG-CLIENTE.
   05 ...

Essas informações serão comparadas com o dataset real.

---

O DD Statement

No JCL existe outro participante:

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

Aqui o sistema descobre:

• nome do dataset

• modo de acesso

• parâmetros DCB opcionais

• volume

• dispositivo

---

O Catálogo

O catálogo funciona como um enorme índice.

Ele responde perguntas como:

• onde o dataset está?

• em qual volume?

• ele existe?

• possui alias?

• está migrado?

Sem catálogo correto, muitas operações sequer começam.

---

O DSCB

Pouco conhecido pelos iniciantes, o Data Set Control Block descreve as características físicas do dataset gravadas no disco.

Entre elas:

• RECFM

• LRECL

• BLKSIZE

• DSORG

• Volume

• Extents

É daqui que o sistema obtém boa parte das informações que serão comparadas com aquilo que o programa espera.

---

O DCB — O DNA do Dataset

Se existe um protagonista nessa história, ele é o Data Control Block.

O DCB descreve como os registros estão organizados.

Entre seus principais atributos estão:

• RECFM

• LRECL

• BLKSIZE

• DSORG

• MACRF

• Buffering

Pense nele como a "ficha técnica" do dataset.

Sem essa ficha, o sistema não sabe interpretar corretamente os bytes gravados em disco.

---

A Regra Mais Importante

O z/OS nunca pergunta:

"Será que o programa consegue se adaptar?"

Ele pergunta:

"O programa está preparado para interpretar exatamente este dataset?"

Essa diferença muda completamente a forma de pensar.

---

O DCB Merge

Muitos imaginam que existe apenas um DCB.

Na prática, diversas fontes de informação são combinadas.

Entre elas:

• atributos do programa;

• atributos informados no DD;

• atributos gravados no dataset;

• regras do Access Method;

• parâmetros definidos pelo SMS.

Esse processo é conhecido como DCB Merge.

É durante essa composição que surgem muitas incompatibilidades.

Imagine o seguinte cenário:

Dataset:

RECFM=FB
LRECL=80

DD:

DCB=(RECFM=VB,LRECL=120)

Programa:

FD CLIENTE.
01 REG PIC X(120).

O sistema precisa decidir quais atributos prevalecem e, se não houver combinação válida, o resultado poderá ser um S013.

---

O Momento Exato do ABEND

É comum ouvir:

"O programa caiu no OPEN."

Tecnicamente, isso é verdade.

Mas o que acontece é mais interessante.

OPEN
 │
 ▼
Localiza DD
 │
 ▼
Consulta catálogo
 │
 ▼
Localiza dataset
 │
 ▼
Lê atributos físicos
 │
 ▼
Compara DCB
 │
 ▼
Compara RECFM
 │
 ▼
Compara LRECL
 │
 ▼
Compara BLKSIZE
 │
 ▼
Tudo compatível?
      │
   Sim │ Não
      ▼
 Continua      S013

O sistema interrompe a execução antes do primeiro READ.

Isso significa que, muitas vezes, o COBOL está completamente correto.

Quem está errado é o ambiente.

---

Por Que o Mainframe é Tão Rigoroso?

Porque ele foi projetado para proteger dados.

Imagine uma instituição financeira.

Se um dataset de extrato fosse interpretado com um layout incorreto, um campo "Saldo" poderia ser lido como "Número da Conta".

O resultado seria imprevisível.

O S013 impede justamente esse tipo de desastre.

Ele prefere falhar imediatamente a permitir que dados sejam interpretados de forma incorreta.

---

Uma Analogia Bellacosa Mainframe

Imagine um trem de alta velocidade chegando a uma estação.

Antes que qualquer passageiro desembarque, dezenas de verificações acontecem:

• a bitola é compatível?

• a plataforma está correta?

• a tensão elétrica é adequada?

• a composição cabe na estação?

• a sinalização autoriza a entrada?

Se alguma resposta for negativa, o trem não entra.

O S013 funciona da mesma forma.

O dataset existe.

O programa existe.

Mas o sistema detecta que eles não "conversam o mesmo idioma".

---

Como um Analista Sênior Pensa

Um programador iniciante costuma perguntar:

"Onde está o erro do meu COBOL?"

Um analista experiente faz perguntas diferentes:

• Qual foi o subcódigo?

• Qual DDNAME falhou?

• Quem criou esse dataset?

• Houve um SORT antes?

• O SMS alterou algum atributo?

• O dataset pertence a um GDG?

• O layout mudou recentemente?

• O DCB foi herdado corretamente?

• O RECFM continua sendo FB?

• O LRECL ainda corresponde ao copybook?

Perceba a diferença.

O foco deixa de ser apenas o programa e passa a ser todo o ecossistema que participa da abertura do dataset.

---

O Primeiro Princípio do Padawan

Existe uma regra que vale ouro:

Se um programa falhou no OPEN, ainda não pense no READ. Pense em engenharia de datasets.

Na maioria das vezes, o problema está na infraestrutura lógica do arquivo, não na lógica de negócio.

---

Conclusão

O ABEND S013 não é apenas uma mensagem de erro. Ele representa uma das filosofias mais importantes do IBM Z: a integridade estrutural vem antes da execução.

Enquanto outras plataformas frequentemente tentam prosseguir mesmo diante de inconsistências, o z/OS interrompe a operação quando percebe que o programa e o dataset não compartilham a mesma "visão" da estrutura dos dados. Essa decisão, refinada ao longo de décadas, é uma das razões pelas quais o mainframe continua sendo a base de sistemas que processam bilhões de transações com confiabilidade.

Na Parte 2, entraremos no coração técnico do problema: RECFM, LRECL, BLKSIZE, DSORG, DCB Merge e as diferenças entre FB, VB, VBS e U, mostrando por que um único atributo incompatível é suficiente para transformar um simples OPEN em um ABEND S013.

Bellacosa Mainframe Storage e DASD 3390

---

💽 Tracks, Cilindros e DASD no IBM Mainframe

Arquitetura, não nostalgia

“O mainframe não mede storage em tracks e cilindros porque é antigo.
Ele faz isso porque sabe exatamente o que está fazendo.”

---

1️⃣ A origem da filosofia: quando hardware importava (e ainda importa)

Desde os primórdios do IBM System/360 (1964), o mainframe foi projetado com um princípio inegociável:

👉 Controle total do I/O

Naquela época:

• Disco era caro

• CPU era valiosa

• I/O era o gargalo

💡 Conclusão da IBM:

“Se o gargalo é I/O, precisamos dominar o disco até o último detalhe físico.”

Assim nascem os conceitos de:

• Track

• Cilindro

• Bloco

• Extent

Nada disso é acaso. É engenharia.

---

2️⃣ O que é um TRACK (pista) – o átomo do DASD

📀 Track é:

• Uma circunferência física no platter do disco

• Unidade mínima de alocação real

• Otimizada para leitura e escrita sequencial

Características importantes:

• Contém um ou mais blocos

• O tamanho em bytes não é fixo

• Depende de:

  • Dataset (PS, PO, VSAM)

  • BLKSIZE

  • Tipo de acesso

📏 Referência clássica (3390):

• ≈ 56 KB por track (didático, não absoluto)

🧪 Easter egg técnico:

Mesmo quando você pede espaço em MB,
o DFSMS converte tudo para tracks internamente 😎

---

3️⃣ O que é um CILINDRO – o segredo da performance

🛢️ Cilindro =
Conjunto de tracks alinhados verticalmente em todos os pratos do disco.

Por que isso é genial?

• O braço do disco não precisa se mover

• Menos seek

• Mais throughput

• Menos latência

📌 Em mainframe:

Performance não é pico, é constância.

---

IBM HD 3390

4️⃣ Modelos clássicos de DASD IBM (história viva)

📦 IBM 2311 / 2314

• Anos 60 / 70

• Discos removíveis

• Origem dos conceitos de cilindro

📦 IBM 3330 – “Merlin”

• Gigante físico

• Primeiro “big storage”

📦 IBM 3380

• Alta densidade

• Base para sistemas bancários dos anos 80

📦 IBM 3390 (o eterno)

• Padrão até hoje (logicamente)

• Modelos:

  • 3390-3 (~2,8 GB)

  • 3390-9 (~8,4 GB)

• Referência de cálculo de tracks/cilindros

📦 DS8000 (atual)

• Storage virtualizado

• Cache massivo

• Flash

• Mas… emula 3390
  😏

O mainframe moderniza sem quebrar o passado.

---

5️⃣ Evolução: do ferro ao virtual (sem perder o controle)

Hoje:

• Não existe mais “disco girando” como antes

• Temos:

  • Cache

  • Flash

  • Virtualização

  • Striping interno

Mas o z/OS continua falando em:

• Track

• Cilindro

• Extent

💡 Por quê?

Porque:

• SMF mede I/O em tracks

• WLM calcula impacto por volume

• SMS aloca espaço físico previsível

• Batch depende disso

---

6️⃣ Alocação no dia a dia (JCL raiz)

Exemplo clássico:

//ARQ1 DD DSN=MEU.ARQUIVO,
//         DISP=(NEW,CATLG,DELETE),
//         SPACE=(CYL,(10,5),RLSE),
//         DCB=(RECFM=FB,LRECL=80,BLKSIZE=0)

📌 Tradução para o padawan:

• 10 cilindros primários

• 5 cilindros secundários

• Espaço real

• Custo previsível

• Impacto conhecido

---

7️⃣ Performance: onde o mainframe humilha

Linux / Unix:

• Você pede “10 GB”

• O filesystem decide tudo

• Fragmentação invisível

• Latência variável

Mainframe:

• Você define:

  • Onde

  • Quanto

  • Como cresce

• O sistema sabe:

  • Quantos seeks

  • Quantos tracks

  • Quanto I/O será gerado

📊 Resultado:

• SLA calculável

• Batch que termina no horário

• Sistema que envelhece bem

---

8️⃣ Uso prático: quem realmente se beneficia disso?

🏦 Bancos
✈️ Companhias aéreas
🏛️ Governos
💳 Clearing e pagamentos
📊 BI batch massivo

Onde:

• Erro não é opção

• Retry não existe

• Previsibilidade é rei

---

9️⃣ Curiosidades e Easter Eggs de mainframer

🧠 Você sabia?

• SPACE=(TRK,…) ainda é usado em sistemas críticos

• VSAM define espaço em CI/CA, mas mapeia para tracks

• SMF Type 42 mede EXCP por dataset

• EAV permite volumes gigantes, mas o cálculo continua físico

• O termo DASD é mais velho que “storage” 😄

---

🔚 Conclusão Bellacosa Mainframe ☕

Falar de tracks e cilindros não é nostalgia.
É respeito à física, engenharia de verdade e responsabilidade operacional.

“Mainframe não abstrai o problema.
Ele encara o problema de frente.”

E é por isso que, décadas depois,
ele ainda roda o mundo.

---

 

O que é Blockagem em Dataset QSAM?

Quando começamos a estudar datasets no mainframe, rapidamente aparecem termos como:

• RECFM;

• LRECL;

• BLKSIZE;

• blockagem.

No começo parece algo extremamente técnico.

Mas a ideia é mais simples do que parece.

E entender blockagem é fundamental para:

• performance;

• uso de disco;

• processamento batch;

• COBOL;

• SORT;

• QSAM.

---

Primeiro: o que é QSAM?

QSAM significa:

Queued Sequential Access Method

É um método de acesso usado no z/OS para trabalhar com arquivos sequenciais.

Ele é muito utilizado em:

• COBOL;

• JCL;

• relatórios batch;

• processamento financeiro.

---

O que é um registro?

Antes da blockagem, precisamos entender:

registro.

Um registro representa:

uma linha de dados.

Exemplo:

JOAO      0001500
MARIA     0003200
CARLOS    0009800

Cada linha é um registro.

---

O problema sem blockagem

Imagine um dataset com:

• milhões de registros;

• cada registro com 80 bytes.

Se o disco gravasse:

• 1 registro por vez,

o sistema faria milhões de operações de I/O.

Isso seria:

• lento;

• caro;

• ineficiente.

---

Então nasceu a blockagem

A ideia é simples:

agrupar vários registros em um único bloco físico.

---

Analogia fácil

Imagine transportar livros.

Sem blockagem:

• 1 livro por viagem.

Com blockagem:

• vários livros dentro de uma caixa.

Resultado:

• menos viagens;

• mais eficiência.

---

O que é um bloco?

Bloco é:

um conjunto de registros gravados juntos no disco.

---

Exemplo simples

Imagine:

• registro = 80 bytes

• bloco = 800 bytes

O sistema consegue armazenar:

10 registros dentro do mesmo bloco

Porque:

10 × 80 = 800

---

Onde isso aparece?

Na definição do dataset:

RECFM=FB
LRECL=80
BLKSIZE=800

---

Entendendo os parâmetros

---

RECFM=FB

Formato:

Fixed Block

Registros fixos com blockagem.

---

LRECL=80

Cada registro possui:
80 bytes.

---

BLKSIZE=800

Cada bloco possui:
800 bytes.

---

Resultado

O sistema grava:

10 registros por bloco.

---

Por que isso melhora performance?

Porque o disco trabalha melhor lendo:

• grandes blocos;
  do que:

• registros individuais.

---

Benefícios da blockagem

---

1. Menos I/O

Reduz acessos físicos ao disco.

---

2. Mais velocidade

Leitura e gravação mais rápidas.

---

3. Melhor uso do disco

Menos desperdício.

---

4. Melhor performance batch

Especialmente em:

• SORT;

• COBOL;

• grandes arquivos.

---

O que acontece sem blockagem?

Exemplo:

RECFM=F
LRECL=80

Aqui:

• registros fixos;

• sem blocagem.

Cada registro é gravado separadamente.

---

Isso é ruim?

Nem sempre.

Mas normalmente:

• FB é mais eficiente que F.

---

Blockagem em VB

Também existe em datasets variáveis.

Exemplo:

RECFM=VB

Nesse caso:

• registros possuem tamanhos diferentes;

• mas continuam agrupados em blocos.

---

O que é BLKSIZE?

BLKSIZE significa:

Block Size

Define:

o tamanho físico do bloco.

---

Exemplo visual

Sem blockagem:

[REG]
[REG]
[REG]
[REG]

Com blockagem:

[BLOCO: REG REG REG REG]

---

Quem define a blockagem?

Pode ser:

• programador;

• JCL;

• sistema;

• SMS do z/OS.

---

O sistema pode calcular sozinho?

Sim.

Hoje muitos ambientes usam:

BLKSIZE=0

O z/OS calcula automaticamente o melhor tamanho.

---

Isso é muito usado atualmente

Porque:

• reduz erros;

• otimiza performance;

• simplifica configuração.

---

Exemplo de JCL

//ARQ DD DSN=USUARIO.TESTE,
//    DISP=(NEW,CATLG),
//    RECFM=FB,
//    LRECL=80,
//    BLKSIZE=800

---

O que isso cria?

Dataset:

• registros fixos;

• 80 bytes;

• 10 registros por bloco.

---

Como COBOL lê isso?

O COBOL normalmente não “vê” a blockagem diretamente.

O QSAM e o z/OS fazem isso automaticamente.

---

O programador trabalha com registros

O sistema operacional cuida dos blocos.

---

O que é blocking factor?

Também chamado:

fator de blockagem.

Indica:
quantos registros cabem no bloco.

---

Exemplo

LRECL = 80
BLKSIZE = 800

Fator:

800 ÷ 80 = 10

---

Então:

blocking factor = 10

---

Erros comuns de iniciantes

---

1. Confundir bloco com registro

Registro = linha lógica
Bloco = agrupamento físico

---

2. Ignorar BLKSIZE

Isso pode afetar performance.

---

3. Pensar que COBOL controla tudo

Quem gerencia blockagem é:

• QSAM;

• z/OS.

---

4. Definir BLKSIZE errado

Pode gerar desperdício ou erros.

---

Curiosidades incríveis

1. Blockagem existe desde os primeiros mainframes

Porque I/O sempre foi crítico.

---

2. Grandes bancos dependem fortemente disso

Performance batch seria inviável sem blockagem.

---

3. O conceito influenciou vários sistemas modernos

Mesmo hoje muitos bancos de dados usam ideias parecidas.

---

4. Um bom BLKSIZE pode melhorar muito performance

Principalmente em arquivos gigantes.

---

Como visualizar atributos do dataset?

No ISPF 3.4:

• digite I;

• veja:

  • RECFM;

  • LRECL;

  • BLKSIZE.

Ou via comando:

LISTDS 'USUARIO.ARQ'

---

Resumo rápido

Conceito	Significado
Registro	Linha lógica
Bloco	Grupo de registros
Blockagem	Agrupar registros
BLKSIZE	Tamanho do bloco
LRECL	Tamanho do registro
FB	Fixo com bloco
VB	Variável com bloco

---

Conclusão

A blockagem em datasets QSAM é uma técnica usada pelo z/OS para melhorar eficiência e performance no acesso aos dados.

Em vez de gravar registros individualmente, o sistema agrupa vários registros em blocos físicos, reduzindo operações de I/O e acelerando o processamento batch.

Entender blockagem é um passo essencial para dominar:

• datasets;

• COBOL;

• JCL;

• SORT;

• arquitetura interna do mainframe IBM Z.