 |
| 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."
