Bellacosa Mainframe e o cics forward recovery

☕ Um Café no Bellacosa Mainframe

CICS Forward Recovery: Sherlock Holmes, COBOL e o Mistério do VSAM Desaparecido

Imagine a cena.

São 14h37 de uma terça-feira aparentemente tranquila. O café ainda está quente, o sistema bancário está processando milhares de transações por minuto e os programas COBOL continuam trabalhando discretamente, como sempre fizeram: lendo clientes, atualizando saldos, gravando pagamentos e respondendo às telas CICS.

De repente, o telefone toca.

— O arquivo de clientes está com erro.

Alguns segundos depois, chega uma mensagem mais preocupante:

— O VSAM não abre.

Em seguida, a sentença que nenhum operador, programador ou analista de produção deseja ouvir:

— Parece que houve uma falha no storage. O arquivo pode estar corrompido.

Nesse momento, o programador COBOL iniciante talvez pense:

“É só restaurar o backup.”

Elementar, meu caro padawan do mainframe.

Mas incompleto.

Restaurar o backup pode trazer o arquivo de volta. Porém, dependendo do horário em que esse backup foi criado, todas as atualizações realizadas depois dele podem desaparecer.

O arquivo volta, mas volta ao passado.

É como encontrar a vítima viva, porém sem memória das últimas doze horas.

É nesse ponto que Sherlock Holmes deixa a lupa sobre a mesa, observa as pegadas deixadas pelos journals e declara:

“O backup mostra onde estivemos. Os logs mostram tudo o que aconteceu depois.”

Bem-vindo ao CICS Forward Recovery, o mecanismo utilizado para reconstruir dados fisicamente danificados por meio da combinação de uma cópia de segurança com registros de alterações posteriores.

Neste artigo, vamos investigar o conceito passo a passo, entender a diferença entre backup, backout e forward recovery, acompanhar um caso bancário completo e descobrir por que os journals são como testemunhas silenciosas de cada atualização feita em um arquivo VSAM.

O primeiro indício: o que é Forward Recovery?

Forward Recovery, ou recuperação para a frente, é um processo utilizado para reconstruir um dataset danificado a partir de dois elementos principais:

Backup consistente
        +
Registros de alterações posteriores
        =
Dataset reconstruído

O backup fornece o ponto de partida.

Os registros de journal fornecem os acontecimentos posteriores.

A recuperação aplica essas alterações sobre a cópia restaurada até que o arquivo alcance o estado consistente mais recente possível.

Considere o seguinte cenário:

00:00 – Backup completo do arquivo VSAM
00:10 – Cliente 100 recebe um depósito
01:25 – Cliente 200 atualiza o endereço
03:40 – Cliente 300 encerra a conta
08:15 – Cliente 400 faz uma transferência
12:00 – Cliente 500 paga um boleto
14:37 – O volume de disco sofre uma falha

Se restaurarmos somente o backup da meia-noite, o arquivo será recuperado no estado em que estava às 00:00.

Todas as operações realizadas entre 00:00 e 14:37 desaparecerão.

O Forward Recovery restaura o backup e, depois, reaplica as alterações registradas após sua criação.

Backup de 00:00
       ↓
Atualização de 00:10
       ↓
Atualização de 01:25
       ↓
Exclusão de 03:40
       ↓
Transferência de 08:15
       ↓
Pagamento de 12:00
       ↓
Estado recuperado próximo de 14:37

A palavra forward existe porque o processo caminha para a frente no tempo.

Ele parte de um ponto conhecido e reconstrói o caminho até o estado mais recente.

A cena do crime: o que exatamente foi perdido?

Antes de pensar em recuperação, precisamos investigar o tipo de falha.

Nem todo problema exige Forward Recovery.

Essa distinção é fundamental.

Em um ambiente CICS, podemos encontrar pelo menos duas grandes categorias de falha:

Falha lógica ou transacional.
Falha física ou estrutural.

Uma falha lógica acontece quando uma transação não consegue concluir corretamente.

Uma falha física acontece quando o próprio dataset, volume ou meio de armazenamento sofre dano ou se torna indisponível.

Observe a diferença.

Falha lógica

Uma transação deveria:

1. Debitar R$ 500 da conta A
2. Creditar R$ 500 na conta B

O débito acontece, mas o crédito falha.

Nesse caso, o arquivo não desapareceu. O disco não foi destruído. O dataset ainda existe.

O problema está na transação incompleta.

O CICS pode desfazer as alterações já realizadas por meio do backout.

Falha física

Agora imagine:

CUSTOMER.MASTER.FILE

O dataset está em um volume que sofreu corrupção.

O CICS tenta abrir o arquivo e recebe erro.

O catálogo pode apontar para o dataset, mas os dados não podem ser lidos corretamente.

Nesse caso, não basta desfazer uma transação. É preciso reconstruir o arquivo.

É aqui que entra o Forward Recovery.

Sherlock Holmes resumiria assim:

Backout corrige o ato. Forward Recovery reconstrói a cena.

O arquivo VSAM: o cofre onde os dados vivem

Para um programador COBOL iniciante, VSAM pode parecer apenas “o arquivo que o programa lê”.

Mas ele é muito mais que isso.

VSAM, ou Virtual Storage Access Method, é uma tecnologia de armazenamento amplamente utilizada no IBM Z.

Entre os tipos mais conhecidos estão:

KSDS — Key-Sequenced Data Set;
ESDS — Entry-Sequenced Data Set;
RRDS — Relative Record Data Set;
LDS — Linear Data Set.

Em aplicações CICS, o KSDS é extremamente comum.

Ele permite acessar registros por meio de uma chave.

Por exemplo:

01  CUSTOMER-RECORD.
    05 CUSTOMER-ID       PIC 9(10).
    05 CUSTOMER-NAME     PIC X(40).
    05 CUSTOMER-BALANCE  PIC S9(11)V99 COMP-3.

A chave poderia ser:

CUSTOMER-ID

Quando uma transação consulta um cliente, o programa pode executar uma leitura semelhante a:

EXEC CICS READ
     FILE('CUSTFILE')
     INTO(CUSTOMER-RECORD)
     RIDFLD(CUSTOMER-ID)
     RESP(WS-RESP)
END-EXEC.

Quando modifica o registro, pode utilizar:

EXEC CICS REWRITE
     FILE('CUSTFILE')
     FROM(CUSTOMER-RECORD)
     RESP(WS-RESP)
END-EXEC.

O programador enxerga comandos como READ, WRITE, REWRITE e DELETE.

Porém, por trás dessas instruções há uma cadeia completa de responsabilidades:

Programa COBOL
      ↓
Comando EXEC CICS
      ↓
CICS File Control
      ↓
VSAM
      ↓
Storage

Se o problema estiver no programa, talvez tenhamos um erro lógico.

Se o problema estiver no armazenamento físico, talvez tenhamos um caso de Forward Recovery.

A testemunha silenciosa: o journal

O journal é um dos elementos centrais da recuperação.

Ele registra informações sobre alterações realizadas nos dados.

Dependendo da configuração do ambiente, dos recursos utilizados e da estratégia de recuperação, os registros necessários podem ser gravados em logs e journals mantidos para esse propósito.

Uma forma simplificada de imaginar um registro de alteração é:

Arquivo: CUSTFILE
Operação: UPDATE
Chave: 0000001234
Horário: 10:25:31
Novo saldo: 000000015500.00

Outro registro poderia representar uma inclusão:

Arquivo: CUSTFILE
Operação: INSERT
Chave: 0000009876
Nome: JOHN WATSON
Saldo: 000000000100.00

Outro poderia indicar uma exclusão:

Arquivo: CUSTFILE
Operação: DELETE
Chave: 0000004444

Durante o Forward Recovery, essas informações são aplicadas sobre o arquivo restaurado.

É como reconstruir um romance perdido utilizando uma edição antiga e todas as correções feitas pelo autor depois dela.

O backup contém o livro antigo.

O journal contém as páginas alteradas.

Backup não é journal, journal não é backup

Esse é um ponto que merece ser gravado em letras garrafais na parede da sala de operações:

Backup e journal são complementares, não substitutos.

O backup é uma fotografia completa ou consistente do dataset em determinado momento.

O journal é uma sequência de mudanças.

Se você possui apenas o backup, pode recuperar o arquivo até o horário da cópia.

Se possui apenas registros de alterações, talvez não tenha uma base íntegra sobre a qual aplicá-los.

A estratégia completa se parece com isto:

BACKUP + JOURNAL + PROCEDIMENTO TESTADO = RECUPERAÇÃO CONFIÁVEL

Ainda falta uma peça importante: o procedimento precisa ser conhecido, documentado e testado.

Um backup que nunca foi restaurado é apenas uma promessa gravada em fita, disco ou nuvem.

O método Sherlock Holmes de recuperação

Sherlock Holmes nunca começa acusando alguém aleatoriamente.

Ele coleta fatos.

Em um incidente real, uma recuperação responsável também precisa seguir evidências.

Podemos organizar a investigação em etapas.

Passo 1 — Confirmar o sintoma

Antes de declarar que o arquivo está corrompido, verifique:

Qual mensagem foi emitida?
Qual código de resposta CICS apareceu?
O arquivo está CLOSED, DISABLED ou UNENABLED?
O problema ocorre para todas as chaves ou apenas algumas?
O dataset está catalogado?
O volume está disponível?
O erro é físico ou uma definição incorreta?
Houve alteração de catálogo, migração ou restore recente?

Nem todo erro de acesso significa corrupção.

Um arquivo pode estar fechado.

Uma definição pode apontar para o dataset errado.

Uma chave pode estar malformada.

Um programa COBOL pode ter fornecido um RIDFLD incorreto.

Holmes diria:

“Não confunda ausência de evidência com evidência de destruição.”

Passo 2 — Proteger a cena

Ao suspeitar de dano físico, o ambiente não deve continuar gravando descontroladamente.

A equipe pode precisar:

suspender transações;
fechar ou desabilitar o arquivo;
impedir novas atualizações;
registrar o horário exato da falha;
preservar logs e journals;
comunicar produção, storage, suporte e negócio.

Essa etapa evita que a investigação seja contaminada.

Passo 3 — Identificar o último backup válido

A equipe precisa descobrir:

quando o backup foi criado;
se ele foi concluído corretamente;
se é full ou incremental;
qual dataset corresponde ao arquivo afetado;
se o backup é consistente;
onde está armazenado;
quanto tempo será necessário para restaurá-lo.

Exemplo:

Último backup completo: 05/08/2026 00:00
Último backup incremental: 05/08/2026 12:00
Falha detectada: 05/08/2026 14:37

Nesse caso, talvez o ponto de partida mais eficiente seja o backup incremental das 12:00, desde que ele faça parte de uma cadeia consistente.

Passo 4 — Determinar o intervalo de journals

Precisamos identificar quais registros cobrem o período entre o backup e a falha.

Início: horário do backup
Fim: último ponto consistente antes da falha

Não basta dizer “aplique todos os logs”.

É necessário saber:

quais logs pertencem ao período;
se não há lacunas;
se a sequência está completa;
se os registros correspondem ao dataset correto;
se há duplicidade;
se existe um ponto de recuperação específico.

Uma lacuna no journal é como uma página arrancada do diário do suspeito.

Talvez ainda seja possível resolver o caso, mas a confiança diminui.

Passo 5 — Restaurar o dataset

O backup é restaurado para o local planejado.

Em ambientes bem estruturados, a equipe pode primeiro restaurar para um dataset alternativo.

Por exemplo:

PROD.CUSTOMER.MASTER

poderia ser restaurado temporariamente como:

RECOVERY.CUSTOMER.MASTER

Isso permite validações antes da substituição definitiva.

A ferramenta utilizada depende do ambiente e pode envolver recursos de:

IDCAMS;
DFSMSdss;
produtos de backup corporativo;
snapshots;
soluções de storage;
software especializado em recuperação de VSAM.

Passo 6 — Aplicar as alterações para a frente

Com o backup restaurado, inicia-se a aplicação dos registros posteriores.

Conceitualmente:

Estado no backup
      +
Alterações registradas
      =
Estado recuperado

As operações podem incluir:

criação de registros;
atualização de registros;
exclusão de registros.

A aplicação precisa respeitar a ordem correta.

Imagine:

10:00 – Cliente criado
10:05 – Cliente atualizado
10:10 – Cliente excluído

Se a ordem for alterada, o resultado poderá ser incoerente.

A cronologia é parte da verdade.

Passo 7 — Validar a consistência

Nunca disponibilize o arquivo apenas porque a ferramenta terminou com condition code zero.

Um CC 0000 indica que o utilitário concluiu conforme sua lógica. Não prova, sozinho, que o negócio está correto.

A validação pode envolver:

contagem de registros;
comparação de totais;
verificação de chaves;
validação de saldos;
relatórios de reconciliação;
testes de leitura;
testes de atualização;
verificação de índices alternativos;
conferência com outros sistemas;
validação pelos responsáveis de negócio.

Exemplo:

Quantidade esperada de clientes: 8.542.190
Quantidade recuperada:          8.542.190

Mas a quantidade sozinha não basta.

É preciso verificar valores críticos.

Total contábil esperado: R$ 982.450.221,37
Total recuperado:        R$ 982.450.221,37

Agora temos uma evidência melhor.

Passo 8 — Reabrir o arquivo e retomar a aplicação

Depois da aprovação:

o dataset recuperado é colocado no local correto;
definições são conferidas;
o arquivo é reaberto ou habilitado;
as transações são liberadas;
o sistema é monitorado;
a equipe acompanha erros e tempos de resposta.

A recuperação não termina quando o arquivo abre.

Ela termina quando o serviço volta com estabilidade e o negócio confirma que os dados estão corretos.

O caso do Banco Baker Street

Vamos construir um exemplo completo.

O Banco Baker Street mantém o cadastro de clientes em um KSDS chamado:

BANK.PROD.CUSTOMER.MASTER

A aplicação CICS utiliza a definição:

CUSTFILE

O backup completo ocorre diariamente à meia-noite.

Às 14h37, um problema de storage torna parte do dataset ilegível.

As transações começam a receber erro ao executar READ e REWRITE.

O programa COBOL possui tratamento de resposta:

EXEC CICS READ
     FILE('CUSTFILE')
     INTO(CUSTOMER-RECORD)
     RIDFLD(CUSTOMER-ID)
     RESP(WS-RESP)
END-EXEC

EVALUATE WS-RESP
    WHEN DFHRESP(NORMAL)
         CONTINUE
    WHEN DFHRESP(NOTFND)
         MOVE 'CLIENTE NAO ENCONTRADO' TO WS-MESSAGE
    WHEN OTHER
         PERFORM HANDLE-FILE-ERROR
END-EVALUATE.

O programa informa erro, mas não é ele quem recuperará fisicamente o dataset.

Essa é uma lição importante para o iniciante:

Nem todo problema encontrado pelo programa deve ser resolvido dentro do programa.

O COBOL detecta a falha.

O CICS gerencia o recurso.

A equipe de infraestrutura e recuperação reconstrói o dataset.

O processo poderia seguir assim:

1. Suspender as transações que atualizam CUSTFILE.
2. Registrar o horário da falha.
3. Fechar ou desabilitar o arquivo.
4. Confirmar o último backup válido.
5. Localizar os journals posteriores ao backup.
6. Restaurar o backup em uma área de recuperação.
7. Aplicar os registros até o ponto consistente.
8. Executar reconciliação.
9. Substituir ou disponibilizar o arquivo recuperado.
10. Reabrir CUSTFILE.
11. Executar transações controladas.
12. Liberar o serviço.

Depois da recuperação, o cliente Sherlock consulta seu saldo.

O valor está correto.

Watson atualiza o endereço.

A alteração é gravada.

Moriarty tenta causar outro incidente, mas encontra o runbook documentado, os backups testados e os journals devidamente preservados.

Desta vez, até o vilão pede transferência para a baixa plataforma.

Forward Recovery versus Transaction Backout

Essa comparação é uma das perguntas favoritas em entrevistas.

Transaction Backout

O backout desfaz alterações de uma unidade de trabalho que não foi concluída corretamente.

Exemplo:

Débito realizado
Crédito não realizado
Transação falha
CICS desfaz o débito

Seu foco é a consistência transacional.

Ele normalmente trabalha com informações que permitem restaurar valores anteriores, frequentemente chamadas de before-images.

Forward Recovery

O Forward Recovery reconstrói um dataset fisicamente danificado.

Exemplo:

Dataset perdido
Backup restaurado
Alterações posteriores reaplicadas
Arquivo reconstruído

Seu foco é a recuperação do dado armazenado.

Característica	Transaction Backout	Forward Recovery
Tipo de problema	Falha lógica	Falha física
Escopo	Unidade de trabalho	Dataset
Direção	Volta ao estado anterior	Avança do backup ao estado recente
Finalidade	Desfazer transação incompleta	Reconstruir dados perdidos
Dataset precisa estar destruído?	Não	Pode estar corrompido ou perdido
Base principal	Informações para desfazer mudanças	Backup e registros posteriores

Uma frase para memorizar:

Backout apaga os passos defeituosos. Forward Recovery refaz os passos corretos.

Before-image e after-image

Considere um saldo inicial:

R$ 1.000,00

Depois de um depósito:

R$ 1.200,00

A imagem anterior é:

Before-image = R$ 1.000,00

A imagem posterior é:

After-image = R$ 1.200,00

Para desfazer a alteração, interessa o valor anterior.

Para reconstruir o estado atualizado a partir de um backup, interessam as informações que permitam reaplicar a mudança.

A implementação exata depende da infraestrutura, do tipo de recurso e da configuração de logging e journaling.

O programador iniciante não precisa decorar toda a mecânica interna no primeiro dia.

Mas precisa compreender o princípio:

BACKOUT → desfazer
FORWARD RECOVERY → reaplicar

RPO e RTO: o relógio de Moriarty

Toda recuperação séria deve considerar dois indicadores.

RPO — Recovery Point Objective

O RPO define quanto dado a organização aceita perder.

Exemplo:

RPO de 12 horas

Significa que, em determinado cenário, perder até 12 horas de dados estaria dentro do limite planejado.

Em um banco, isso provavelmente seria inaceitável para muitos sistemas.

Com journaling adequado, o ponto de recuperação pode ficar muito próximo do momento da falha.

RTO — Recovery Time Objective

O RTO define quanto tempo o serviço pode permanecer indisponível.

Exemplo:

RTO de 30 minutos

Isso significa que a organização espera restaurar o serviço dentro desse intervalo.

Forward Recovery influencia ambos.

Journals completos ajudam a reduzir a perda de dados.

Automação, backups rápidos e procedimentos testados ajudam a reduzir o tempo de recuperação.

O vilão mais perigoso de uma recuperação não é a falha de disco.

É o improviso.

O papel do CICS VSAM Recovery

Em ambientes corporativos, pode ser utilizado o CICS VSAM Recovery, frequentemente conhecido como CICS VR, para auxiliar no gerenciamento e na recuperação de dados VSAM relacionados a cargas CICS.

Uma solução especializada pode ajudar a:

identificar backups disponíveis;
localizar logs necessários;
planejar pontos de recuperação;
automatizar etapas;
reduzir erros operacionais;
manter informações sobre recursos recuperáveis;
apoiar a reconstrução de datasets.

É importante não imaginar que existe uma única ferramenta universal utilizada por todas as empresas.

Cada instalação possui sua arquitetura, seus produtos, seus padrões e seus procedimentos.

Algumas utilizam CICS VR.

Outras combinam ferramentas de storage, backup corporativo e rotinas próprias.

A tecnologia pode variar.

O princípio continua o mesmo:

Restaurar uma base válida
+
Reaplicar alterações válidas
+
Validar o resultado

Curiosidades da sala de máquinas

1. Um backup rápido não é necessariamente um restore rápido

Alguns processos produzem backups em poucos minutos, mas a restauração pode levar muito mais tempo.

Por isso, o planejamento deve medir os dois lados.

2. O índice alternativo também importa

Um KSDS pode possuir Alternate Index, ou AIX.

A estratégia de recuperação precisa considerar a consistência entre o cluster base e seus caminhos de acesso alternativos.

Não adianta recuperar os registros e esquecer a estrutura usada pelas aplicações para encontrá-los.

3. O catálogo pode sobreviver ao dataset

É possível que o catálogo ainda contenha a definição do arquivo, embora o conteúdo físico esteja indisponível.

É como possuir o endereço de uma casa que foi destruída.

4. Alta disponibilidade não elimina recuperação

Replicação, redundância e failover reduzem interrupções, mas não tornam o ambiente imune a corrupção lógica, erro humano ou propagação de dados inválidos.

Uma cópia perfeitamente replicada de um erro continua sendo um erro perfeitamente replicado.

5. Journals também exigem proteção

Se o arquivo e os journals estiverem sujeitos ao mesmo ponto único de falha, a estratégia poderá fracassar justamente quando for necessária.

6. O melhor runbook é aquele executado em teste

Documentos de recuperação não devem ser tratados como relíquias sagradas.

Devem ser ensaiados, atualizados e criticados.

Uma linha desatualizada em um procedimento pode custar horas durante um incidente real.

Dicas para o programador COBOL iniciante

Mesmo que você não seja o responsável por executar o restore, seu código pode ajudar muito durante incidentes.

Sempre trate RESP e RESP2

Evite assumir que todo comando CICS funcionará.

EXEC CICS WRITE
     FILE('CUSTFILE')
     FROM(CUSTOMER-RECORD)
     RIDFLD(CUSTOMER-ID)
     RESP(WS-RESP)
     RESP2(WS-RESP2)
END-EXEC.

Depois, avalie a resposta.

Não transforme todo erro em “registro não encontrado”

Um erro físico não é igual a NOTFND.

Tratar qualquer falha como ausência de cliente mascara problemas graves.

Registre contexto suficiente

Quando permitido pelos padrões da empresa, registre:

transação;
programa;
arquivo;
operação;
chave;
RESP;
RESP2;
horário;
identificador de correlação.

Isso ajuda a investigação.

Evite mensagens genéricas

Mensagem ruim:

ERRO NO ARQUIVO

Mensagem melhor:

TRAN=CU01 PROG=PGMCUST FILE=CUSTFILE OP=READ
RESP=xx RESP2=yy KEY=0000001234

Sem expor dados sensíveis, forneça evidências úteis.

Entenda a unidade de trabalho

Saiba onde ocorre o commit.

Saiba quais atualizações fazem parte da mesma transação.

Saiba o que deve ser desfeito se algo falhar.

Não tente “consertar” corrupção física com lógica improvisada

Um programa que ignora erros e continua gravando pode transformar um incidente recuperável em um desastre maior.

Easter eggs escondidos no dataset

Como prometido, aqui estão alguns pequenos easter eggs para o leitor atento.

O arquivo do exemplo chama-se BANK.PROD.CUSTOMER.MASTER, mas os clientes utilizados incluem Sherlock Holmes, John Watson e Moriarty.

O horário da falha, 14h37, não possui poder místico. Ele foi escolhido justamente para lembrar que incidentes reais raramente respeitam horários redondos.

O café aparece porque toda grande investigação de produção possui três elementos inevitáveis:

Logs
Hipóteses
Cafeína

E há um quarto elemento não documentado:

Alguém dizendo:
“Isso nunca aconteceu antes.”

Na prática, quando alguém pronuncia essa frase, procure um ticket semelhante aberto três anos antes.

Provavelmente ele existe.

Perguntas de entrevista

O que é Forward Recovery no CICS?

É o processo de reconstrução de um dataset danificado, normalmente restaurando um backup consistente e aplicando registros de alterações posteriores até atingir o ponto de recuperação desejado.

Qual é a diferença entre Forward Recovery e Backout?

Backout desfaz alterações de uma transação incompleta. Forward Recovery reaplica alterações sobre um backup para reconstruir um dataset perdido ou corrompido.

Por que o backup sozinho pode ser insuficiente?

Porque ele representa o estado do arquivo no momento em que foi criado. Todas as atualizações posteriores precisam ser recuperadas por outros registros, como journals apropriados.

Em que situações o Forward Recovery pode ser necessário?

Em casos como:

falha de volume;
corrupção de dataset;
perda de mídia;
dano físico no armazenamento;
necessidade de reconstrução de arquivo crítico.

Qual é o papel do journal?

Preservar informações sobre alterações que podem ser aplicadas depois da restauração do backup.

O que deve ser validado após a recuperação?

Estrutura, quantidade de registros, chaves, totais financeiros, consistência de índices, funcionamento das transações e reconciliação com sistemas relacionados.

Checklist do detetive de produção

Antes da falha:

[ ] Existe backup?
[ ] O backup foi testado?
[ ] Journaling está configurado?
[ ] Os logs estão protegidos?
[ ] O RPO está definido?
[ ] O RTO está definido?
[ ] O procedimento está documentado?
[ ] A equipe treinou a recuperação?
[ ] Existem contatos de escalonamento?
[ ] O negócio conhece os impactos?

Durante a falha:

[ ] Registrar o horário
[ ] Preservar evidências
[ ] Suspender atualizações
[ ] Identificar o dataset
[ ] Confirmar a natureza da falha
[ ] Encontrar o último backup válido
[ ] Localizar os journals necessários
[ ] Executar o runbook

Depois da recuperação:

[ ] Validar registros
[ ] Reconciliar totais
[ ] Testar leituras
[ ] Testar atualizações
[ ] Monitorar transações
[ ] Comunicar o negócio
[ ] Documentar a causa
[ ] Atualizar o procedimento
[ ] Realizar post-mortem

A conclusão de Sherlock Holmes

Forward Recovery não é apenas um comando, um utilitário ou uma função isolada do CICS.

É uma estratégia.

Ela começa muito antes da falha, quando a empresa decide:

como produzir backups;
como registrar alterações;
onde armazenar cópias;
quanto dado pode perder;
quanto tempo pode ficar parada;
quem será chamado;
como validar a recuperação.

Quando o incidente acontece, não é hora de inventar a solução.

É hora de executar aquilo que já foi planejado.

Para o programador COBOL iniciante, a principal lição é compreender que um sistema transacional possui camadas.

Seu programa pode executar:

READ
WRITE
REWRITE
DELETE

Mas a sobrevivência desses dados depende de uma arquitetura maior:

COBOL
  ↓
CICS
  ↓
VSAM
  ↓
Logging e Journaling
  ↓
Backup
  ↓
Storage
  ↓
Recuperação
  ↓
Continuidade do negócio

Quando todas essas peças trabalham juntas, uma falha física não precisa se transformar em perda irreversível.

O dataset pode ser reconstruído.

As transações podem voltar.

O negócio pode continuar.

E o jovem programador, observando os logs como pistas espalhadas pela Baker Street do IBM Z, finalmente compreende que o mainframe não é apenas uma máquina que processa dados.

É uma fortaleza construída para preservar a história de cada transação.

Porque, no mundo dos sistemas críticos, cada registro conta.

Cada journal é uma testemunha.

Cada backup é uma fotografia.

E toda recuperação bem-sucedida começa com a pergunta certa:

“O que aconteceu depois da última cópia confiável?”

Elementar, meu caro programador COBOL.

Translate

terça-feira, 10 de novembro de 2020