 |
| Bellacosa Mainframe e o westworld no CICS |
☕ Um Café no Bellacosa Mainframe
Westworld no CICS — Quando o Cowboy de Chapéu Preto Atravessou a Região, Igor Tentou Dar RETURN e Descobriu que o ABEND Ainda Tinha Balas
Ou: um jovem padawan COBOL entrou no parque de diversões do CICS, confundiu condição excepcional com fim do mundo, encontrou ASRA no saloon, AICA galopando em círculos e aprendeu que capturar o Pistoleiro não significa recuperar a transação
Prólogo — “Temos as férias perfeitas para você”
Em 1973, muito antes de alguém discutir inteligência artificial generativa no café da firma, Michael Crichton escreveu e dirigiu Westworld. O filme mostrava Delos, um parque de diversões para adultos formado por três mundos: o Velho Oeste, a Roma Antiga e a Europa medieval. Os visitantes pagavam para viver fantasias cercados por androides tão convincentes que pareciam humanos.
Tudo funcionava até deixar de funcionar.
Pequenas anomalias surgiam aqui e ali. Um robô recusava uma ordem. Uma cascavel mecânica atacava quando não deveria. Um cavaleiro ultrapassava os limites de segurança. Os técnicos percebiam que alguma coisa estava errada, mas ainda acreditavam que o problema cabia dentro dos painéis da sala de controle.
Então aparece o Pistoleiro, interpretado por Yul Brynner: roupa preta, passos metódicos, olhos artificiais e uma persistência que faria qualquer operador pedir um CEMT INQUIRE TASK. Aquilo que fora criado para perder duelos e divertir visitantes passa a perseguir Peter Martin como se tivesse recebido uma instrução impossível de cancelar.
O filme é uma metáfora quase perfeita para uma região CICS.
Delos é a região. Cada visitante é uma task. Os edifícios são recursos. Os anfitriões são programas. A sala subterrânea representa as equipes de operação. As regras do parque são as definições e controles do CICS. E o Cowboy de Chapéu Preto é o ABEND: ele pode surgir num programa profundo, atravessar níveis lógicos e continuar subindo até encontrar alguém preparado para recebê-lo.
Mas há uma diferença importante: no CICS, não basta atirar no mensageiro, apagar a mensagem da tela e dizer que o parque voltou ao normal. É preciso descobrir o que aconteceu com a unidade de trabalho, o que foi atualizado, o que precisa ser desfeito e se a transação ainda é confiável.
Bem-vindo a Westworld. Favor manter mãos, pés e COMMAREA dentro da transação.
1. Antes do tiroteio: transação, task e programa não são a mesma coisa
Para o programador COBOL iniciante, esses três conceitos às vezes parecem sinônimos. Não são.
A transação é identificada normalmente por um código de quatro caracteres, como TR01. Sua definição informa ao CICS qual programa inicial deve ser executado e contém atributos operacionais importantes.
A task é a instância daquela transação em execução. Se cinquenta usuários executarem TR01, teremos uma mesma definição de transação, mas várias tasks, cada qual com seu número, seu contexto e seus dados.
O programa é o código que executa dentro da task. Uma task pode passar por muitos programas:
TR01
└── PROGA
└── LINK PROGB
└── LINK PROGCPense em Delos. “Westworld” é a atração anunciada no catálogo. A visita de Peter Martin é uma execução concreta. O saloon, a cadeia e o hotel são partes diferentes da experiência. Do mesmo modo, a transação é a entrada comercial; a task é a visita em andamento; e os programas são os ambientes atravessados.
Quando ocorre um ABEND, é a task que termina anormalmente. O programa que estava ativo pode ter provocado a falha, recebido a falha ou simplesmente estar no caminho dela.
Essa distinção muda o diagnóstico. Dizer “o programa caiu” é confortável, mas incompleto. O suporte precisa saber:
qual região CICS;
qual transação;
qual número da task;
qual programa estava executando;
qual nível lógico;
qual comando ou instrução falhou;
qual unidade de trabalho estava aberta;
quais recursos haviam sido alterados.
O código do ABEND é a placa pendurada no saloon. A cena do crime continua lá dentro.
2. Afinal, o que é um ABEND?
ABEND significa abnormal end, ou término anormal. Ele ocorre quando a task não pode — ou não deve — continuar seu processamento normal.
As causas incluem:
program check;
erro de lógica;
dado incompatível;
endereço de memória inválido;
condição excepcional CICS não tratada;
loop ou consumo excessivo de CPU;
arquivo fechado ou indisponível;
programa inexistente ou desabilitado;
falha de autorização;
timeout ou purge;
erro em comunicação;
EXEC CICS ABENDemitido deliberadamente pela aplicação;problema de integridade em uma unidade de trabalho.
O iniciante costuma imaginar que todo ABEND é equivalente a uma explosão. Alguns são explosões. Outros são portas que a aplicação tentou abrir sem possuir a chave. Outros ainda são o próprio programa puxando o alarme porque percebeu que continuar seria perigoso.
Por isso, “eliminar todos os ABENDs” não é uma meta madura. Uma aplicação financeira pode preferir terminar anormalmente e executar backout a continuar depois de uma atualização incompleta.
O objetivo correto é:
evitar falhas previsíveis, tratar condições esperadas, preservar evidências nas falhas inesperadas e proteger a integridade dos dados.
No parque de Crichton, o problema não foi um único robô quebrar. O problema foi o sistema continuar vendendo normalidade enquanto os sinais mostravam que as garantias haviam desaparecido.
3. Condição excepcional não é automaticamente ABEND
Esta é a primeira grande curva da trilha.
Considere:
EXEC CICS READ
FILE('CLIENTES')
INTO(WS-CLIENTE)
RIDFLD(WS-CHAVE)
END-EXEC.Se a chave não existir, o CICS poderá retornar NOTFND. Isso é uma condição excepcional do comando READ, mas pode ser uma situação normal para o negócio: o usuário procurou um cliente que não está cadastrado.
O que acontecerá depende de como o programa foi preparado:
| Estratégia | O que acontece |
|---|---|
RESP e RESP2 | O programa recebe os códigos e decide |
HANDLE CONDITION | O controle é desviado para uma rotina |
IGNORE CONDITION | A ação padrão é suprimida para a condição |
NOHANDLE no comando | O tratamento automático é suprimido naquele comando |
| Nenhuma proteção | O CICS aplica a ação padrão, frequentemente um ABEND |
Essa é a diferença entre um hóspede não encontrado no hotel e o Cowboy atravessando a recepção a tiros. Os dois são eventos fora do caminho feliz, mas não pertencem à mesma categoria.
4. RESP e RESP2: pergunte ao comando o que aconteceu
Para código COBOL estruturado, RESP e RESP2 geralmente tornam o fluxo mais claro:
01 WS-RESP PIC S9(8) COMP VALUE ZERO.
01 WS-RESP2 PIC S9(8) COMP VALUE ZERO.
EXEC CICS READ
FILE('CLIENTES')
INTO(WS-CLIENTE)
RIDFLD(WS-CHAVE)
RESP(WS-RESP)
RESP2(WS-RESP2)
END-EXEC
EVALUATE WS-RESP
WHEN DFHRESP(NORMAL)
PERFORM PROCESSAR-CLIENTE
WHEN DFHRESP(NOTFND)
PERFORM INFORMAR-CLIENTE-INEXISTENTE
WHEN DFHRESP(NOTOPEN)
PERFORM REGISTRAR-ERRO-TECNICO
PERFORM ABORTAR-OPERACAO
WHEN OTHER
PERFORM REGISTRAR-RESPOSTA-INESPERADA
PERFORM ABORTAR-OPERACAO
END-EVALUATE.RESP fornece a condição principal. RESP2 oferece detalhe adicional cujo significado depende do comando e da resposta. Portanto, não existe um dicionário universal de RESP2: é preciso consultar a documentação do comando específico.
Também é preferível comparar com DFHRESP(NORMAL), DFHRESP(NOTFND) e outras constantes simbólicas, em vez de espalhar números mágicos pelo fonte. Daqui a dois anos, ninguém deveria precisar perguntar por que Igor escreveu IF WS-RESP = 13.
Dica de produção
Inicialize as variáveis, teste a resposta imediatamente depois do comando e preserve o contexto antes de executar outras operações CICS. O último comando pode alterar campos do EIB e deixar a equipe investigando o mensageiro em vez do atirador.
5. HANDLE CONDITION: coloque um xerife na esquina
HANDLE CONDITION associa condições CICS a rótulos:
EXEC CICS HANDLE CONDITION
NOTFND(SEM-CLIENTE)
NOTOPEN(ARQUIVO-FECHADO)
IOERR(ERRO-DE-IO)
END-EXEC.Quando uma dessas condições surgir em comando sujeito ao mecanismo, o controle poderá saltar para a rotina indicada.
É útil, especialmente em programas antigos ou em fluxos bem delimitados, mas exige cuidado. O tratamento fica ativo no nível lógico e pode capturar uma condição gerada longe do ponto onde foi declarado. Em um fonte grande, isso cria um roteiro de faroeste no qual o espectador precisa rever quarenta minutos para descobrir por que alguém entrou pela janela.
Para iniciantes, uma regra prática:
use
RESPquando a decisão pertence à operação específica;use
HANDLE CONDITIONquando um desvio controlado realmente melhora o desenho;não misture estilos sem entender precedência e escopo;
nunca continue usando uma área de dados quando o comando que deveria preenchê-la falhou.
6. NOHANDLE: retirar o alarme não apaga a fumaça
NOHANDLE impede que os mecanismos automáticos de tratamento sejam aplicados àquele comando:
EXEC CICS READ
FILE('CLIENTES')
INTO(WS-CLIENTE)
RIDFLD(WS-CHAVE)
NOHANDLE
END-EXEC.Isso não significa “ignore o erro e considere sucesso”.
Se a leitura falhar e o programa prosseguir:
PERFORM CALCULAR-LIMITE.WS-CLIENTE pode conter zeros, dados antigos ou conteúdo inconsistente. O erro original era um NOTFND; o erro seguinte pode virar ASRA, cálculo incorreto ou, pior, uma decisão financeira válida sobre o cliente errado.
NOHANDLE sem verificação é Igor cobrindo os olhos do androide e anunciando que o Pistoleiro não consegue mais enxergá-lo.
7. HANDLE ABEND: a última barreira do parque
HANDLE ABEND instala uma saída de ABEND no nível lógico do programa:
EXEC CICS HANDLE ABEND
PROGRAM('ERRPGM')
END-EXEC.Em contextos compatíveis, também pode apontar para um rótulo:
EXEC CICS HANDLE ABEND
LABEL(ROT-ABEND)
END-EXEC.Ele não deve substituir o tratamento de condições previsíveis. Seu papel é receber falhas anormais, preservar informações e conduzir uma terminação ou recuperação controlada.
Imagine:
PROGA — saída A ativa
└── LINK PROGB — saída B ativa
└── LINK PROGC — nenhum handler
└── ASRAO CICS procura uma saída no nível atual. Não encontrando, sobe pelos níveis lógicos até localizar uma saída ativa. Se não houver nenhuma, a task termina anormalmente.
Existe apenas uma saída ativa por nível lógico. Declarar outra nesse mesmo nível desativa a anterior. Quando a saída recebe controle, o CICS a desativa antes de executar seu código, evitando reentrada infinita caso o próprio handler falhe.
É o Cowboy de Chapéu Preto atravessando Westworld, Medievalworld e Romanworld. Ele só para quando encontra alguém preparado — ou quando não resta mais parque.
8. CANCEL versus CANCEL: duas placas iguais em portas diferentes
O material que iniciou nossa conversa colocava “CANCEL versus HANDLE ABEND”, mas essa comparação pode induzir o iniciante ao erro.
EXEC CICS HANDLE ABEND
CANCEL
END-EXEC.Esse comando desativa a saída de ABEND do nível lógico atual. Ele não ordena, por si só, o encerramento imediato da task.
Já:
EXEC CICS ABEND
CANCEL
END-EXEC.é outra operação: cancela as saídas de ABEND em todos os níveis e força o término anormal.
| Comando | Significado |
HANDLE ABEND PROGRAM(...) | Ativa programa de tratamento |
HANDLE ABEND LABEL(...) | Ativa rotina local |
HANDLE ABEND CANCEL | Desativa a saída do nível atual |
HANDLE ABEND RESET | Reativa a saída após ela ter recebido controle |
ABEND ABCODE('E001') | Provoca ABEND definido pela aplicação |
ABEND CANCEL | Ignora todas as saídas e termina a task |
No CICS, contexto é munição. A mesma palavra, colocada em outro comando, produz outro resultado.
9. O erro mais perigoso: capturar o ABEND e dar RETURN
Chegamos à cena central.
Suponha uma transferência:
1. Debitar conta A
2. Creditar conta B
3. Gravar histórico
4. Enviar confirmaçãoO débito é realizado. Antes do crédito, o programa sofre ASRA. O handler registra “erro tratado” e executa:
EXEC CICS RETURN
END-EXEC.Parece elegante. Não é.
Quando uma saída de ABEND termina com RETURN, o CICS pode devolver controle ao nível lógico superior como se o programa inferior tivesse retornado normalmente. Se a transação atualizou recursos recuperáveis e dependia do ABEND para provocar backout, o backout não ocorre; as alterações podem ser confirmadas.
Assim, uma rotina criada para proteger a aplicação pode transformar:
falha detectável + backoutem:
falha escondida + commit parcialA própria IBM adverte que, quando é necessário preservar a integridade de recursos recuperáveis, a saída deve terminar com ABEND, não simplesmente retornar. Consulte How it works: Abend exit code.
Um desenho prudente:
ERRPGM-MAIN.
PERFORM CAPTURAR-CONTEXTO
PERFORM GRAVAR-LOG-SANITIZADO
PERFORM NOTIFICAR-OPERACAO
EXEC CICS ABEND
ABCODE('E001')
END-EXEC.O handler pode registrar e notificar. Mas, se a unidade de trabalho precisa ser desfeita, deve permitir ou provocar o término anormal adequado.
Matar o alarme não mata o Cowboy.
10. Backout, commit e unidade de trabalho
Uma Unit of Work agrupa alterações que devem ser tratadas como uma unidade coerente.
UPDATE VSAM
+
UPDATE Db2
+
mensagem persistente
=
trabalho ainda não confirmadoQuando ocorre um syncpoint bem-sucedido, as alterações recuperáveis são confirmadas. Quando uma task termina anormalmente em condições apropriadas, o CICS pode executar dynamic transaction backout.
Mas nem tudo é automaticamente recuperável:
um arquivo precisa estar definido e operado como recurso recuperável;
integrações externas podem não participar do mesmo escopo transacional;
uma chamada HTTP pode ter sido processada embora a resposta tenha se perdido;
uma mensagem pode pertencer a outra unidade de trabalho;
efeitos fora do CICS podem exigir compensação;
uma UOW distribuída pode ficar in-doubt.
Por isso, “deu ABEND, então tudo voltou” é uma crença perigosa.
Antes de repetir a transação, confirme:
Houve backout?
Algum syncpoint ocorreu antes da falha?
O Db2 confirmou alterações?
A mensagem MQ foi publicada?
O sistema remoto recebeu a solicitação?
Existe chave de idempotência?
A primeira tentativa pode ter terminado com sucesso apesar da resposta perdida?
Retry sem conhecer o estado anterior é o equivalente operacional de colocar dois Pistoleiros no parque para resolver o problema do primeiro.
11. ASRA — o anfitrião perdeu o controle do próprio corpo
ASRA indica que a task terminou por causa de um program check.
Possíveis causas:
dado não numérico em operação decimal;
subscrito fora dos limites;
referência inválida à memória;
endereço corrompido;
storage já liberado;
incompatibilidade de parâmetros entre chamador e chamado;
copybooks divergentes;
comprimento incorreto;
corrupção de storage ocorrida antes;
erro em COBOL, PL/I, assembler ou componente chamado.
ASRA não é a causa-raiz; é a categoria. A investigação precisa localizar:
programa;
offset;
statement correspondente no compile listing;
PSW;
registradores;
traceback do Language Environment;
áreas de dados envolvidas;
versão exata do módulo carregado;
cadeia de
LINK,XCTLou chamadas.
Se o load module em execução não corresponde ao listing usado na investigação, o offset pode levar a uma linha inocente. É como analisar o mapa de Westworld da semana passada depois que alguém mudou o saloon de lugar.
A definição oficial pode ser consultada em IBM — ASRA.
12. AICA — o Cowboy que galopa em círculos
AICA indica uma possível runaway task: a task consumiu tempo de execução além do limite considerado aceitável.
Exemplo:
PERFORM UNTIL WS-FIM = 'S'
ADD 1 TO WS-CONTADOR
END-PERFORM.Se WS-FIM nunca mudar, temos um loop clássico.
Mas AICA não prova automaticamente “loop infinito”. Também pode sinalizar:
processamento legítimo grande demais para uma transação online;
algoritmo ineficiente;
ausência de pontos de suspensão;
volume anormal;
configuração inadequada do intervalo de runaway;
rotina batch colocada dentro do CICS;
instrumentação alterando o tempo;
laço que deveria avançar um cursor, mas não avança.
O CICS consegue detectar determinados loops comparando a execução com o intervalo configurado. Algumas chamadas que suspendem a task podem alterar esse comportamento. A investigação oficial está em IBM — AICA.
O conserto não é simplesmente aumentar o timeout. Primeiro determine se o trabalho pertence ao ambiente online, se pode ser paginado, dividido, agendado ou redesenhado.
Dar mais tempo a um loop infinito apenas permite que o Cowboy cavalgue mais longe.
13. AEI9 — a pista errada do infográfico
Aqui existe uma correção objetiva e importante.
O infográfico original apresentou AEI9 como algo relacionado a comando ou parâmetro inválido. AEI9 corresponde a MAPFAIL.
MAPFAIL costuma aparecer no BMS quando:
nenhum dado utilizável foi transmitido;
o usuário acionou uma tecla sem modificar campos;
a entrada chegou sem o formato esperado;
o programa esperava dados mapeados, mas recebeu entrada não formatada.
Já INVREQ, condição associada a requisição inválida, aparece como AEIP nessa família. AEIS corresponde a NOTOPEN.
| Código | Condição |
| AEI9 | MAPFAIL |
| AEIP | INVREQ |
| AEIS | NOTOPEN |
| AEIM | NOTFND |
| AEI0 | PGMIDERR |
Essa diferença não é preciosismo. Se o operador procura parâmetro inválido diante de AEI9, perderá tempo examinando o comando errado quando deveria investigar entrada de terminal e BMS. Veja IBM — MAPFAIL.
14. EIB: o bolso do casaco do visitante
O EXEC Interface Block contém informações sobre o contexto da task:
EIBTRNID: identificador da transação;EIBTASKN: número da task;EIBTRMID: terminal;EIBDATEeEIBTIME: data e hora;EIBFN: função do último comando;EIBRESP: resposta principal;EIBRESP2: resposta secundária;EIBCALEN: tamanho da COMMAREA recebida;EIBAID: tecla de atenção recebida.
O detalhe crítico é “último comando”. Se o programa de erro executar vários comandos antes de preservar o EIB, poderá sobrescrever a evidência original.
MOVE EIBTRNID TO LOG-TRANSACAO
MOVE EIBTASKN TO LOG-TASK
MOVE EIBTRMID TO LOG-TERMINAL
MOVE EIBFN TO LOG-FUNCAO
MOVE EIBRESP TO LOG-RESP
MOVE EIBRESP2 TO LOG-RESP2.Faça a captura cedo. Depois sanitize e registre.
Também não grave indiscriminadamente senhas, tokens, PINs, CVV, chaves, documentos completos ou COMMAREAs inteiras. Um log excelente para diagnóstico pode ser excelente também para um invasor.
15. Passo a passo do suporte de produção
Passo 1 — Identifique a visita
Colete região, transação, task, usuário, terminal ou canal, horário e correlation ID.
Passo 2 — Leia as mensagens associadas
O código de ABEND sozinho não conta a história. Procure mensagens DFH, logs da região, JES, Language Environment, Db2, MQ e demais componentes relacionados.
Passo 3 — Preserve dump e trace
Não suprima dumps por reflexo. Dump é caro quando existe em excesso, mas ausência de evidência também custa. A política deve equilibrar diagnóstico, volume, privacidade e recorrência.
Passo 4 — Classifique
É program check, runaway, condição EXEC não tratada, autorização, indisponibilidade, purge, timeout, falha distribuída ou ABEND criado pela aplicação?
Passo 5 — Localize o ponto
Para condição CICS, identifique comando, RESP, RESP2, parâmetros e recurso.
Para ASRA, use dump, offset, listing, PSW, registradores e traceback.
Passo 6 — Descubra o que mudou
deploy recente;
copybook alterado;
módulo sem
NEWCOPYouPHASEINadequado;definição de arquivo;
mudança RACF;
mapa BMS regenerado;
aumento de volume;
alteração no programa chamador;
erro restrito a uma região ou registro.
Passo 7 — Verifique integridade
Determine commit, backout, syncpoints, mensagens enviadas e efeitos externos.
Passo 8 — Só então decida
Corrigir, recuperar, compensar, reiniciar, repetir de modo idempotente ou escalar.
16. CEDF: visitar o parque com as luzes acesas
CEDF ajuda a observar interativamente o fluxo de comandos CICS. Ele pode mostrar entrada e saída de comandos, condições, opções e sequência de execução.
Mas não é máquina do tempo.
CEDF:
ajuda a reproduzir;
revela o fluxo;
permite examinar comandos;
não substitui dump;
pode alterar timing;
pode esconder problemas concorrentes;
exige extremo cuidado em produção.
A combinação forte é:
CEDF para compreender
+ dump para congelar a falha
+ trace para reconstruir a sequência
+ logs para correlacionar componentes
+ listing para localizar a instruçãoObservar o Pistoleiro em câmera lenta ajuda. Ainda precisamos saber quem liberou a arma, qual trava falhou e se a sala de controle perdeu energia.
17. Curiosidades escondidas no parque
Easter egg 1 — o Pistoleiro já havia cavalgado antes
O visual de Yul Brynner em Westworld foi construído para lembrar Chris Adams, personagem interpretado por ele em The Magnificent Seven — Sete Homens e um Destino. Roupa escura, postura e presença criam uma referência cinematográfica deliberada. O robô parece uma cópia de outro cowboy, quase como um módulo recompilado a partir de um fonte antigo.
Easter egg 2 — visão digital antes de CGI virar rotina
O filme foi pioneiro no uso de processamento digital de imagem em longa-metragem para simular a visão pixelada do Pistoleiro. Décadas antes de dashboards coloridos e observabilidade distribuída, Crichton já nos colocava dentro do “sensor” da máquina.
Easter egg 3 — três mundos, três ambientes
Romanworld, Medievalworld e Westworld parecem ambientes separados, mas os defeitos atravessam fronteiras. É uma boa lembrança de que regiões, serviços e plataformas isolados no organograma podem compartilhar dependências invisíveis.
Easter egg 4 — Crichton repetiria a pergunta
Anos depois, Jurassic Park retomaria a ideia de uma atração tecnológica complexa, vendida como controlável, cuja segurança dependia de camadas frágeis e excesso de confiança corporativa.
Easter egg 5 — a frase de marketing
O slogan de Delos prometia férias extraordinárias. Depois do desastre, a promessa volta com ironia. Em TI, o equivalente é o slide que anuncia “zero incidentes” antes de a primeira evidência chegar ao console.
Informações históricas do filme podem ser consultadas na página oficial de Michael Crichton e no relato técnico da American Society of Cinematographers.
18. O mapa de decisão do jovem padawan
Quando um comando CICS não retorna NORMAL, pergunte:
A condição é esperada pelo negócio?
Ela pertence ao comando atual?
Posso tratá-la localmente com
RESP?Alguma área de dados deixou de ser preenchida?
É seguro continuar?
Houve atualização recuperável?
Preciso provocar backout?
Existe efeito fora da unidade de trabalho?
Preciso de dump?
Tenho evidência suficiente antes de emitir outro comando?
Quando ocorre ABEND:
Preserve o código original.
Capture o contexto.
Não mascare falha de integridade.
Não execute
RETURNpor hábito.Não repita a transação cegamente.
Não confunda o código com a causa-raiz.
Confirme o estado da UOW.
Diferencie recuperação técnica de recuperação do negócio.
Epílogo — O Cowboy fecha o chamado?
No início de Westworld, os visitantes acreditam que o parque é seguro porque os androides foram programados para obedecer. A confiança nasce da regra escrita, não da evidência operacional.
No CICS, acontece algo parecido. O programa foi testado. O arquivo é recuperável. O handler existe. O log foi criado. A mensagem “erro tratado” apareceu. Tudo isso ajuda, mas nada disso prova que a transação terminou de forma íntegra.
HANDLE ABEND não é um colete à prova de balas. É uma saída program-level que oferece à aplicação uma última oportunidade de decidir o que fazer diante do término anormal.
Às vezes, a decisão será limpar recursos e continuar em um nível superior.
Às vezes, será converter uma falha técnica em resposta controlada.
Às vezes, será registrar o contexto e emitir outro ABEND para garantir o backout.
E muitas vezes, o ato mais profissional será admitir que o estado não é confiável e impedir que a task confirme uma meia verdade.
O programador iniciante aprende sintaxe:
EXEC CICS HANDLE ABEND
PROGRAM('ERRPGM')
END-EXEC.O profissional aprende responsabilidade:
Capturar uma falha não significa recuperar o negócio; remover o alarme não restaura a integridade; e nenhum
RETURNdeve atravessar a porta antes que alguém confira o que aconteceu com o commit e o backout.
Na última cena, o parque permanece silencioso. A sala de controle já não controla nada. Peter Martin sobrevive, mas olha ao redor sem saber exatamente onde terminou a fantasia e começou a falha.
No console do CICS, o Cowboy de Chapéu Preto deixa sua última mensagem:
ABEND CODE IS NOT ROOT CAUSEIgor olha para o dump, tira lentamente o dedo do CANCEL e finalmente chama o programador que guardou o compile listing correto.
O boteco pode reabrir.
Mas somente depois do backout.
Referências essenciais
