Bellacosa Mainframe VSAM e seus File Status

💥 FILE STATUS 00… E MESMO ASSIM DEU RUIM? — O LADO SOMBRIO DO VSAM QUE NINGUÉM TE CONTA

Se você acha que FILE STATUS = só checar 00 e seguir a vida, prepare-se:
👉 é exatamente assim que nascem os bugs mais caros do mainframe.

Hoje vamos abrir a caixa preta do VSAM FILE STATUS no estilo Bellacosa:
sem romantismo, direto na ferida — código, causa e como sair vivo.

---

🧠 O QUE É FILE STATUS (DE VERDADE)

FILE STATUS é um campo de 2 bytes no COBOL que retorna o resultado de TODA operação de I/O.

💣 Tradução real:

É o único contrato entre seu programa e o VSAM. Ignorou… perdeu o controle.

---

🔢 MAPA COMPLETO DOS FILE STATUS (VSAM COBOL)

Vamos direto ao que interessa.

---

✅ SUCESSO (OU QUASE…)

Código	Significado	Tradução Bellacosa	Ação
00	Sucesso	“Tudo certo… por enquanto”	OK
02	Sucesso com duplicidade permitida	Registro duplicado aceito	Validar regra de negócio

---

📭 FIM / NÃO ENCONTRADO

Código	Significado	Tradução	Ação
10	End of File	Acabou	Fluxo normal
13	Nenhum próximo registro	Cursor inválido	Ver START
23	Registro não encontrado	“Você pediu algo que não existe”	Validar chave
35	Dataset não encontrado	“Você abriu algo que não existe”	Ver catálogo

💥 Clássico:

FS=23 não é erro técnico — é erro de lógica.

---

🔁 DUPLICIDADE / CHAVE

Código	Significado	Tradução	Ação
22	Duplicate key	Já existe	Tratar insert
24	Boundary violation	Fora do range	Validar chave
21	Sequência inválida	Ordem errada	Ordenação errada

💣 Esse trio derruba batch inteiro.

---

⚙️ ERROS DE ACESSO / LÓGICA

Código	Significado	Tradução	Ação
34	Boundary violation (ESDS/RRDS)	Fora do espaço	Ajustar definição
41	OPEN já executado	Reabriu arquivo	Revisar fluxo
42	CLOSE em arquivo não aberto	Bagunça de controle	Ajustar lógica
43	REWRITE sem READ	Atualizando fantasma	Corrigir fluxo
44	Record size mismatch	Layout errado	Revisar copybook

💥 Esse grupo é:

erro de programador raiz

---

🔒 LOCK / CONCORRÊNCIA (O TERROR DO ONLINE)

Código	Significado	Tradução	Ação
91	Lock timeout/deadlock	“Outro job está na sua frente”	Retry
92	Logic error	Acesso inconsistente	Revisar fluxo
93	Resource unavailable	Recurso indisponível	Esperar/retry

💣 Aqui entra:

• CICS
• RLS
• Batch concorrente

👉 Esse é o mundo real.

---

💾 ERROS FÍSICOS / INFRA

Código	Significado	Tradução	Ação
90	Erro geral	“Algo deu muito errado”	Ver log
94	Falha em READ/WRITE	Problema físico	Ver dataset
97	Erro de VSAM	Falha interna	Analisar IDCAMS
98	File locked	Dataset travado	Ver enqueue

💥 Tradução:

Aqui você chama o sysprog.

---

🧨 OS CÓDIGOS QUE MAIS CAEM EM PRODUÇÃO

Top 5 do caos:

1. 23 → registro não encontrado
2. 22 → duplicate key
3. 10 → EOF mal tratado
4. 91 → lock em produção
5. 44 → layout errado

👉 Se você nunca viu esses… você ainda não sofreu o suficiente.

---

🧪 EXEMPLO COBOL (DO MUNDO REAL)

READ ARQ-VSAM
   AT END
      MOVE '10' TO WS-FS
   NOT AT END
      CONTINUE
END-READ

IF WS-FS NOT = '00' AND WS-FS NOT = '10'
   DISPLAY 'ERRO VSAM: ' WS-FS
   PERFORM TRATA-ERRO
END-IF

💡 Bellacosa insight:

Nunca trate só 00. Sempre trate o resto.

---

⚠️ ARMADILHAS QUE DERRUBAM SISTEMA

🔥 Ignorar FILE STATUS
🔥 Não tratar 23
🔥 Não prever retry para 91
🔥 REWRITE sem READ
🔥 Layout diferente do VSAM

💣 Resultado:

• dados inconsistentes
• batch quebrado
• incidente em produção

---

🧠 DICAS DE GUERRA (OU SOBREVIVÊNCIA)

✔ Sempre logar FILE STATUS
✔ Criar tabela de tratamento centralizado
✔ Retry inteligente para 91/93
✔ Validar chave antes de acessar
✔ Testar concorrência

👉 E a regra de ouro:

💥 FILE STATUS não é detalhe. É arquitetura.

---

🧨 EASTER EGG (PRA QUEM É RAIZ)

👉 FILE STATUS 00 não garante sucesso lógico
👉 VSAM pode retornar sucesso e ainda assim você estar lendo dado errado

Sim…

💣 O erro pode ser silencioso

---

🔥 VSAM RETURN CODE — ANATOMIA COMPLETA (RAIZ MAINFRAME)

Quando você acessa VSAM via COBOL (ou assembler por baixo), o retorno vem em dois níveis:

🧩 1. FILE STATUS (COBOL)

• 2 bytes
• Interface simplificada
• Ex: 00, 10, 21, 23

👉 Isso é só a “versão resumida do erro”

---

🧠 2. VSAM STATUS (nível real — baixo nível)

Esse é o que você mostrou na imagem:

VSAM-CODE = 08 00 24

👉 Isso vem do REGISTER 15 + feedback interno do VSAM

---

🧠 ESTRUTURA DO VSAM CODE (3 CAMPOS)

Campo	Tamanho	Origem	Função
Return Code	1 byte	Register 15	Status geral
Function Code	1 byte	VSAM	Tipo de operação
Feedback Code	1 byte	VSAM	Motivo detalhado

👉 Total: 3 bytes

---

🧬 1. REGISTER (R15) — O CARA QUE MANDA

📌 O que é?

No IBM z/OS, o Register 15 (R15) é:

👉 O registrador padrão de retorno de programas

---

📦 Tamanho:

• 32 bits (4 bytes) no hardware
• Mas VSAM usa apenas 1 byte relevante (low-order)

---

📊 Uso:

• Indica sucesso ou falha da macro VSAM (GET, PUT, etc.)

Valores típicos:

Valor	Significado
00	Sucesso
04	Warning
08	Erro
12	Erro severo

💥 Esse é o “OK/FAIL” da operação

---

⚙️ 2. FUNCTION CODE — O QUE O VSAM ESTAVA FAZENDO

📌 O que é?

Indica qual operação VSAM estava sendo executada

---

📦 Tamanho:

• 1 byte

---

📊 Uso:

Ajuda a entender o contexto do erro

Exemplos:

Código	Operação
00	Acesso ao cluster base
04	Acesso via AIX
08	Inserção
0C	Update
10	Delete

💬 Pense como:
👉 “em que momento deu ruim?”

---

🚨 3. FEEDBACK FIELD CODE — O VERDADEIRO ERRO

📌 O que é?

👉 O coração do diagnóstico VSAM

Mostra exatamente por que falhou

---

📦 Tamanho:

• 1 byte

---

📊 Uso:

Diagnóstico fino (nível sênior)

Exemplos famosos:

Código	Significado
00	OK
04	Duplicate key
08	Record not found
0C	End of dataset
10	Length error
24	Key out of range
28	Sequence error

💥 Esse é o código que resolve incidente em produção

---

🧠 JUNTANDO TUDO

Exemplo:

VSAM-CODE = 08 00 24

Campo	Valor	Significado
R15	08	Erro
Function	00	Acesso cluster
Feedback	24	Key out of range

---

🔄 RELAÇÃO COM COBOL (FILE STATUS)

VSAM interno	COBOL FS
Feedback 08	23
Feedback 24	21
Feedback 04	22

👉 COBOL simplifica — VSAM detalha

---

💡 RESUMO VISUAL

01 RETURN-STATUS. 05 FS-CODE PIC X(2). 05 VSAM-CODE. 10 VSAM-R15-RETURN PIC S9(4) Usage Comp-5. 10 VSAM-FUNCTION PIC S9(4) Usage Comp-5. 10 VSAM-FEEDBACK PIC S9(4) Usage Comp-5.

[ R15 ] [ FUNC ] [ FEEDBACK ]
   ↓        ↓         ↓
 STATUS   OPERAÇÃO   CAUSA REAL

---

⚠️ IMPORTANTE (nível sênior)

👉 O COBOL esconde informação

Se você olha só:

FILE STATUS = 21

👉 Você está vendo só a superfície

💥 O diagnóstico real exige VSAM-CODE

---

☕ INSIGHT FINAL (estilo Bellacosa)

• R15 diz “deu erro”
• Function diz “onde deu erro”
• Feedback diz “por que deu erro”

---

🔥 PROVOCAÇÃO FINAL

Se você debuga VSAM só com FILE STATUS…

👉 você está dirigindo o mainframe olhando pelo retrovisor 😏

🎯 CONCLUSÃO (SOCO FINAL)

Se você não domina FILE STATUS…

👉 você não domina VSAM
👉 você não domina batch
👉 você não domina produção

💥 FILE STATUS é o log invisível do seu sistema

Ignore ele…
e o sistema vai te ensinar — da pior forma.

 

Bellacosa Mainframe e o max-cc conditional code

☕🔥 MAXCC — O “HUMOR” DO JOB NO z/OS

Quando o Mainframe Diz:

“SEU JOB TERMINOU… MAS EU TENHO ALGO A DIZER.”

Se existe uma coisa que TODO Junior Padawan COBOL precisa aprender cedo…

é que no z/OS:

nem todo fim de job é igual.

Às vezes o JOB termina:

✅ normalmente
⚠️ com avisos
🔥 com erros graves
☠️ completamente destruído

E quem conta essa história é o:

🚨 MAXCC

---

☕ O QUE É MAXCC?

MAXCC significa:

MAXIMUM CONDITION CODE

É o maior retorno gerado pelos steps do JOB.

---

🔥 A FILOSOFIA DO MAXCC

No z/OS:

programas “conversam” com o scheduler usando códigos numéricos.

Exemplo:

RETURN-CODE = 0

significa:

“Tudo OK.”

Mas:

RETURN-CODE = 16

significa:

“O APOCALIPSE CHEGOU.”

---

☕ O MAXCC MAIS FAMOSO

No SDSF/JESMSGLG:

MAXCC=0000

ou:

COND CODE 0004

---

🔥 O SEGREDO

MAXCC NÃO É ABEND.

Isso é MUITO importante.

---

☕ ABEND

Falha anormal.

Exemplo:

• S0C7

• S0C4

• S806

---

☕ MAXCC

Programa terminou normalmente…

MAS quer avisar algo.

---

🔥 MAXCC 00 — O “MUNDO EM PAZ”

✅ MAXCC=0000

Significa:

tudo terminou perfeitamente.

---

☕ EXEMPLO

IEF142I STEP01 - STEP WAS EXECUTED - COND CODE 0000

---

🔥 INTERPRETAÇÃO BELLACOSA

O mainframe está dizendo:

☕ “Excelente, Padawan. Nada explodiu hoje.”

---

☕ CENÁRIO TÍPICO

• arquivo processado

• SORT OK

• DB2 OK

• nenhum warning

• tudo consistente

---

🔥 MAXCC 04 — O “WARNING ELEGANTE”

⚠️ MAXCC=0004

O JOB terminou.

Mas:

algo merece atenção.

---

☕ O MAIS IMPORTANTE

MAXCC 4 normalmente NÃO é erro fatal.

Muitos jobs em produção aceitam:

RC=4 normalmente.

---

🔥 EXEMPLOS CLÁSSICOS

---

☕ SORT

SORT FIELDS=COPY

Mas:

• registro inválido ignorado

• campo truncado

• duplicidade encontrada

Resultado:

RC=4

---

☕ IDCAMS

DELETE DATASET

Dataset não existe.

IDCAMS retorna:

4

Porque:

“não achei, mas sobrevivi.”

---

☕ IEBCOPY

Membro duplicado.

Warning.

RC=4.

---

🔥 INTERPRETAÇÃO BELLACOSA

☕ “Nada morreu… mas eu notei uma coisa estranha.”

---

🔥 MAXCC 08 — O “ERRO OPERACIONAL”

❌ MAXCC=0008

Agora a conversa ficou séria.

---

☕ SIGNIFICADO

o processamento falhou parcialmente.

---

🔥 MUITOS JOBS PARAM EM RC=8

Schedulers frequentemente tratam:

RC >= 8

como falha.

---

☕ EXEMPLOS CLÁSSICOS

---

☕ SORT

Campo inválido.

Chave inconsistente.

Arquivo problemático.

---

☕ IDCAMS

Falha em DEFINE CLUSTER.

---

☕ DB2

SQLCODE sério.

---

☕ COBOL

Programa detecta erro de negócio:

MOVE 8 TO RETURN-CODE
STOP RUN

---

🔥 INTERPRETAÇÃO BELLACOSA

☕ “Padawan… algo deu errado e você PRECISA olhar.”

---

🔥 MAXCC 12 — O “DESASTRE CONTROLADO”

☠️ MAXCC=0012

Agora entramos na zona crítica.

---

☕ SIGNIFICADO

Erro grave.

Processamento comprometido.

---

🔥 EXEMPLOS CLÁSSICOS

• falha forte em SORT

• utility quebrada

• VSAM inconsistente

• falha DB2 importante

• step inutilizado

---

☕ O JOB AINDA TERMINOU

Isso diferencia de ABEND.

O programa conseguiu:

terminar conscientemente.

Mas avisando:

“o resultado NÃO é confiável.”

---

🔥 EXEMPLO COBOL

IF WS-ERRO-CRITICO = 'S'
   MOVE 12 TO RETURN-CODE
   STOP RUN
END-IF

---

🔥 INTERPRETAÇÃO BELLACOSA

☕ “O castelo ainda está de pé… mas está pegando fogo.”

---

🔥 MAXCC 16 — O “JUÍZO FINAL”

🚨 MAXCC=0016

Aqui o sistema está praticamente gritando.

---

☕ SIGNIFICADO

falha gravíssima.

---

🔥 MUITOS PRODUTOS TRATAM 16 COMO FATAL

Especialmente:

• DFSORT

• IDCAMS

• DB2 utilities

• IEBCOPY

• custom utilities

---

☕ EXEMPLOS CLÁSSICOS

• arquivo inacessível

• utility impossível de executar

• parâmetro inválido

• corrupção

• inconsistência crítica

---

🔥 COBOL TAMBÉM PODE RETORNAR 16

MOVE 16 TO RETURN-CODE
STOP RUN

---

☕ INTERPRETAÇÃO BELLACOSA

☕ “Padawan… o processamento fracassou de forma épica.”

---

🔥 O SEGREDO MAIS IMPORTANTE

CADA PRODUTO INTERPRETA RC DE FORMA DIFERENTE.

---

☕ EXEMPLO

Para um utilitário:

RC=4

pode ser trivial.

Para outro:

RC=4

já significa problema sério.

---

🔥 O JCL E O COND=

Agora nasce o verdadeiro conhecimento Jedi.

---

☕ EXEMPLO

//STEP2 EXEC PGM=PROG2,COND=(8,LT)

Significa:

execute STEP2 somente se RC anterior NÃO for menor que 8.

---

🔥 O IF/THEN/ELSE MODERNO

Mais elegante:

// IF (STEP1.RC > 4) THEN
//STEPERR EXEC PGM=ALERTA
// ENDIF

---

☕ O MAXCC E O JES2

O JES acompanha:

• RCs

• ABENDs

• steps

• histórico do JOB

---

🔥 O MAXCC E O SCHEDULER

Ferramentas como:

• Control-M

• CA7

• TWS

tomam decisões usando:

RC/MAXCC.

---

☕ EXEMPLO REAL

RC=0 → continua fluxo
RC=4 → warning
RC>=8 → dispara incidente

---

🔥 O MAIOR ERRO DO PADAWAN

Achar:

RC=4 = tudo OK

Não necessariamente.

Você PRECISA entender:

o contexto do utilitário/programa.

---

☕ O SEGREDO DOS VETERANOS

Veteranos sempre perguntam:

“QUEM RETORNOU O RC?”

Porque:

• DFSORT

• IDCAMS

• COBOL

• DB2

• CICS utilities

cada um possui semântica própria.

---

🔥 CURIOSIDADE HISTÓRICA

MAXCC existe desde os tempos do:

OS/360

Década de:

🏛️ 1960

IBM precisava que jobs batch “conversassem” automaticamente entre si.

Então nasceram:

• return codes

• condition codes

• job control logic

---

☕ EASTER EGG MAINFRAME

Veteranos brincam:

RC=0 → “milagre corporativo”

RC=4 → “o sistema tossiu”

RC=8 → “alguém vai abrir chamado”

RC=12 → “gerência foi avisada”

RC=16 → “prepare o café… a madrugada será longa.”

  

Bellacosa Mainframe e o comando Stop Run em Cobol

O que é o comando STOP RUN em COBOL?

O comando STOP RUN é uma das instruções mais conhecidas da linguagem COBOL.

Sua função é:

Encerrar a execução do programa

Quando o COBOL encontra um STOP RUN, ele finaliza o programa e devolve o controle ao sistema operacional (z/OS), ao CICS, ao Job Batch ou ao ambiente que executou o programa.

---

Sintaxe

STOP RUN.

---

Exemplo Simples

IDENTIFICATION DIVISION.
PROGRAM-ID. HELLO.

PROCEDURE DIVISION.

DISPLAY 'OLA MUNDO'.

STOP RUN.

Resultado:

OLA MUNDO

O programa termina logo após o DISPLAY.

---

Fluxo de Execução

Início Programa
       ↓
Comandos COBOL
       ↓
STOP RUN
       ↓
Fim Programa
       ↓
Retorno ao z/OS

---

O que acontece internamente?

Quando executado:

STOP RUN.

o COBOL:

✅ Fecha arquivos abertos

✅ Libera memória

✅ Finaliza o Language Environment (LE)

✅ Retorna ao sistema operacional

✅ Define o Return Code

---

Exemplo em Batch

DISPLAY 'PROCESSAMENTO OK'.

STOP RUN.

JCL:

//STEP1 EXEC PGM=FIN001

Resultado:

CC 0000

(Job encerrado com sucesso)

---

STOP RUN e Return Code

Podemos definir um código de retorno.

Exemplo:

MOVE 8 TO RETURN-CODE.

STOP RUN.

Resultado:

CC 0008

No SDSF:

RC=0008

---

Exemplo de Erro

IF SQLCODE NOT = 0

   MOVE 16 TO RETURN-CODE

   STOP RUN

END-IF.

Resultado:

CC=0016

---

STOP RUN x GOBACK

Uma das dúvidas mais comuns.

---

STOP RUN

Finaliza completamente a aplicação.

STOP RUN.

---

GOBACK

Retorna ao programa chamador.

GOBACK.

---

Exemplo

Programa principal:

CALL 'SUBROT1'.

---

Subprograma:

GOBACK.

Retorna ao programa principal.

---

Se usar:

STOP RUN.

todo o processo termina.

---

Exemplo Visual

Com GOBACK

MAIN
 ↓
SUB1
 ↓
GOBACK
 ↓
MAIN continua

---

Com STOP RUN

MAIN
 ↓
SUB1
 ↓
STOP RUN
 ↓
Tudo termina

---

Uso em Subprogramas

Normalmente:

❌ Evita-se STOP RUN

✅ Usa-se GOBACK

---

Exemplo Incorreto

PROGRAM-ID. SUBROT1.

DISPLAY 'SUB'.

STOP RUN.

Se chamado por:

CALL 'SUBROT1'

todo o JOB poderá terminar.

---

Exemplo Correto

PROGRAM-ID. SUBROT1.

DISPLAY 'SUB'.

GOBACK.

---

STOP RUN em CICS

Programas CICS não devem usar:

STOP RUN

Normalmente utilizam:

EXEC CICS RETURN
END-EXEC

---

STOP RUN em IMS

Em IMS TM também não é recomendado.

Utilizam-se comandos específicos do ambiente.

---

STOP RUN em Batch

É onde aparece com maior frequência.

---

Exemplo:

OPEN INPUT ARQENT.

PERFORM PROCESSA-ARQUIVO.

CLOSE ARQENT.

STOP RUN.

---

STOP RUN e Arquivos

Antes do STOP RUN é boa prática:

CLOSE ARQENT.
CLOSE ARQSAI.

STOP RUN.

---

Embora...

O runtime normalmente feche os arquivos automaticamente.

---

STOP RUN e Language Environment

O LE (Language Environment) interpreta:

STOP RUN

como:

Fim da aplicação

Executando rotinas de limpeza.

---

Evolução Histórica

Nas versões antigas:

STOP RUN

era praticamente obrigatório.

Hoje:

GOBACK

é mais utilizado em muitos ambientes.

---

Boas Práticas

✅ Use STOP RUN em programas principais Batch

✅ Use GOBACK em subprogramas

✅ Defina RETURN-CODE quando necessário

✅ Feche arquivos antes de terminar

---

Erros Comuns

Usar STOP RUN em subprograma

Pode encerrar toda a aplicação.

---

Usar STOP RUN em CICS

Pode gerar problemas de execução.

---

Não definir RETURN-CODE

Dificulta automação e controle do Scheduler.

---

Exemplo Completo

IDENTIFICATION DIVISION.
PROGRAM-ID. TESTE.

DATA DIVISION.

WORKING-STORAGE SECTION.

01 WS-TOTAL PIC 9(5).

PROCEDURE DIVISION.

MOVE 100 TO WS-TOTAL.

DISPLAY 'TOTAL = ' WS-TOTAL.

MOVE 0 TO RETURN-CODE.

STOP RUN.

---

Curiosidades

1. STOP RUN existe desde as primeiras versões do COBOL

2. É um dos comandos mais executados do mundo corporativo

3. Milhões de JOBs Batch terminam diariamente através dele

4. Em aplicações modernas, GOBACK costuma substituir STOP RUN em muitos cenários

---

Resumo Rápido

Comando	Função
STOP RUN	Finaliza o programa
GOBACK	Retorna ao chamador
RETURN-CODE	Define código de retorno
CLOSE	Fecha arquivos
EXEC CICS RETURN	Finaliza transação CICS
Batch	Uso comum de STOP RUN
Subprograma	Preferir GOBACK

---

Conclusão

O STOP RUN é o comando responsável por encerrar a execução de um programa COBOL e devolver o controle ao ambiente que o executou. Em programas Batch ele é amplamente utilizado, enquanto em subprogramas normalmente é substituído por GOBACK, que retorna o controle ao programa chamador sem finalizar toda a aplicação.