Translate

segunda-feira, 22 de junho de 2026

☕💥 Quando um Dataset VSAM Corrompe no z/OS: Guia de Sobrevivência para Sysprogs, Desenvolvedores COBOL e Administradores CICS

 

Bellacosa Mainframe uma pequena ajudinha recuperando dataset vsam

☕💥 Quando um Dataset VSAM Corrompe no z/OS: Guia de Sobrevivência para Sysprogs, Desenvolvedores COBOL e Administradores CICS

"Há dois tipos de profissionais de Mainframe: os que já recuperaram um dataset corrompido e os que ainda vão recuperar."


Introdução

Poucas mensagens conseguem acelerar tanto os batimentos cardíacos de um profissional de Mainframe quanto estas:

IDC3302I ACTION ERROR
IDC3351I VSAM OPEN RETURN CODE 168
IEC161I
IEC070I
DFHFC0157

Ou pior ainda:

"O arquivo de clientes não abre em produção."

Silêncio.

O scheduler para.

O CICS começa a emitir mensagens.

Os jobs entram em abend.

O telefone toca.

Alguém pergunta:

"Tem backup?"

E nesse momento percebemos que existe uma grande diferença entre saber programar COBOL, conhecer VSAM e realmente entender o processo de recuperação de corrupção em datasets no z/OS.

Hoje vamos tomar um café e conversar sobre um assunto pouco ensinado em treinamentos, mas extremamente valorizado em bancos, seguradoras, companhias aéreas e órgãos governamentais:

Como recuperar um dataset VSAM corrompido no z/OS.


O que significa um Dataset Corrompido?

Nem toda falha é uma corrupção.

Às vezes é apenas um catálogo inconsistente.

Em outros casos temos problemas muito mais graves.

Exemplos:

  • EOF inconsistente

  • HURBA inválido

  • HARBA incorreto

  • Alternate Index quebrado

  • Cadeia lógica danificada

  • Control Interval inválida

  • Problemas na VTOC

  • SMSVSAM inconsistente

  • CI Split interrompido

  • Erros físicos em disco


Primeira Regra: Pare Tudo

O maior erro que vejo iniciantes cometerem é tentar "olhar rapidamente".

Não.

Pare imediatamente.

Batch

Segure scheduler.

CA7

Control-M

TWS


CICS

Fechar arquivo.

CEMT SET FILE(CUSTFILE) CLOSED

ou

CEMT SET FILE(CUSTFILE) DISABLED

IMS

/DBR CUSTOMER

Started Tasks

Encerrar consumidores.

MQ

Connectors

Replication

ETL

CDC


A regra é simples.

Dataset suspeito.

Sem acesso.

Sem exceções.


Segunda Etapa: LISTCAT

Antes de sair executando VERIFY.

Olhe o paciente.

Comando

//STEP1 EXEC PGB=IDCAMS
//SYSPRINT DD SYSOUT=*
//SYSIN DD *

 LISTCAT ENT(PROD.CUST.KSDS)
 ALL

/*

O que analisar?

Cluster

Data Component

Index Component

Volume

HI-USED-RBA

Catalog

SMS Classes


Exemplo

HURBA = 000001987654
HARBA = 000001999999

Valores estranhos podem indicar inconsistências.


VERIFY

Provavelmente a ferramenta mais subestimada do IDCAMS.


Função

Sincronizar.

Catalog

Volume

EOF

RBA

Informações físicas


Exemplo

VERIFY DATASET(PROD.CUST.KSDS)

Com recuperação:

VERIFY DATASET(PROD.CUST.KSDS)
RECOVER

O VERIFY resolve

EOF incorreto

Catalog inconsistente

Discrepâncias simples

Alguns problemas em KSDS


Mas atenção.

VERIFY não é mágica.

Ele não reconstrói uma estrutura destruída.


EXAMINE

Agora começa a parte realmente interessante.

EXAMINE é quase um scanner médico do VSAM.


Data Component

EXAMINE -
NAME(PROD.CUST.KSDS)
DATATEST

Índice

EXAMINE -
NAME(PROD.CUST.KSDS)
INDEXTEST

Completo

EXAMINE -
NAME(PROD.CUST.KSDS)
DATA

O que ele encontra?

Control Interval inválida

Ponteiros quebrados

Índices inconsistentes

RBAs errados

Registros perdidos


A Grande Pergunta

Após EXAMINE surge a decisão.

Corrupção pequena?

ou

Corrupção severa?

Essa decisão define tudo.


Cenário 1 — Corrupção Leve

Exemplos.

Catalog inconsistente.

EOF errado.

Pequenos danos.


Solução.

VERIFY

REPRO

Rebuild


REPRO

Criar novo cluster.

DEFINE CLUSTER(...)

Copiar.

REPRO -
INFILE(IN1)
OUTFILE(OUT1)

Muitas vezes isso resolve.

Surpreendentemente.


Cenário 2 — Corrupção Grave

Aqui muda completamente.

Nunca seja herói.

Backup sempre vence.


Restore

Melhor prática.

Sempre.


DFSMSdss

RESTORE DATASET(...)

HSM

HRECOVER

FDR

RESTORE TYPE=DS

E se não existir backup?

Infelizmente acontece.

Mais vezes do que deveria.


Estratégia

Salvar o que for possível.

Criar novo dataset.

Tentar REPRO.

Descartar registros inválidos.

Reconstruir índices.


Alternate Index

Muitos esquecem do AIX.

Ele também pode corromper.


Rebuild

BLDINDEX

Ou.

Excluir.

Criar novamente.

Popular.


Recuperação de Catálogo

Uma área extremamente especializada.

Pouca gente domina.

Muito valorizada.


DIAGNOSE

DIAGNOSE

EXPORT

EXPORT -
CATALOG(MYCAT)
TEMPORARY

IMPORT

IMPORT CONNECT

Ambientes CICS

A situação muda bastante.

Especialmente em RLS.


SMSVSAM

Cache compartilhado.

Lock global.

Coupling Facility.

Múltiplas regiões.


Problemas comuns.

CF inconsistente.

Lock perdido.

Buffer inválido.


Procedimento

Fechar arquivos.

Verificar SMSVSAM.

Executar VERIFY.

EXAMINE.

Restore.

Abrir novamente.


Ambientes Bancários

O fluxo normalmente é.


Incidente aberto.

Congelamento.

Snapshot.

LISTCAT.

VERIFY.

EXAMINE.

Análise.

Restore.

Testes.

Validação.

Produção.


Testes Pós-Recovery

Nunca devolver imediatamente.

Teste.

Leia registros.

Atualize.

Delete.

Browse.

Sequencial.

Random.


Batch

Executar programas COBOL.

Validar.

Retorno.

SMF.

CPU.

EXCP.


CICS

Abrir arquivo.

Executar transações.

CRUD.

Commit.

Syncpoint.


IMS

DBOPEN.

GN.

GU.

REPL.

DLET.


Ferramentas Úteis

IDCAMS

DFSMSdss

DFSMShsm

FDR

LISTCAT

VERIFY

EXAMINE

BLDINDEX

DIAGNOSE


O que Aprendemos?

O Mainframe continua sendo uma das plataformas mais resilientes do planeta.

Mas nenhuma tecnologia é imune.

Discos falham.

Pessoas erram.

Jobs são cancelados.

Aplicações apresentam bugs.

Volumes ficam inconsistentes.

Catálogos podem sofrer danos.

A diferença entre um desastre e uma recuperação tranquila quase sempre está em três fatores.

Backup.

Procedimentos.

Conhecimento.

Um desenvolvedor COBOL que entende apenas READ, WRITE e REWRITE é valioso.

Um desenvolvedor que compreende LISTCAT, VERIFY, EXAMINE, REPRO, recuperação de catálogo e estratégias de restore torna-se um profissional muito mais próximo do universo de Sysprog, Storage e Administração z/OS.

E essa é justamente uma das características que mais diferencia especialistas Mainframe experientes.

Porque no fim do dia, quando o telefone toca e alguém diz:

"O arquivo de produção corrompeu..."

A pergunta deixa de ser:

"Quem programou isso?"

E passa a ser:

"Quem sabe trazer a base de volta?"

E, acredite, nas grandes corporações, essas pessoas são lembradas por muitos anos.


Bellacosa Mainframe

"Transformando mensagens IDCAMS em oportunidades de aprendizado, um café por vez."


Sem comentários:

Enviar um comentário