Bellacosa Maifnrame e o caso do return code que decidiu quem viveria no batch

☕ Um Café no Bellacosa Mainframe

O Caso do Return Code que Decidiu Quem Viveria no Batch

JCL IF/THEN/ELSE: o detetive invisível que interroga programas, examina falhas e escolhe o próximo passo

A chuva caía sobre o data center como uma sequência interminável de registros gravados em fita.

Do lado de fora, a cidade dormia. Dentro da sala de operações, milhares de luzes piscavam em silêncio, enquanto o z/OS processava folhas de pagamento, transferências bancárias, seguros, cartões de crédito, estoques, relatórios fiscais e uma quantidade de dinheiro que faria qualquer contador perder o sono.

Eram duas horas e dezessete da madrugada quando o telefone tocou.

— Bellacosa, temos um problema.

Do outro lado da linha, um jovem programador COBOL parecia nervoso.

— O relatório não foi enviado. O programa de geração terminou, mas o passo seguinte não executou. No spool aparece uma coisa chamada IF/THEN/ELSE. Acho que o JCL decidiu ignorar meu programa.

Acendi o abajur, empurrei para o lado uma velha revista de mistério dos anos 1950 e observei o copo de café frio sobre a mesa.

O rapaz ainda não sabia, mas havia acabado de encontrar uma das figuras mais discretas e poderosas do mundo batch.

O JCL não era apenas uma lista de programas.

Ele também podia tomar decisões.

E, em algum lugar daquele JOB, uma condição havia interrogado um Return Code, analisado as evidências e decidido que determinado passo não merecia executar.

O nome do suspeito?

IF / THEN / ELSE

Esta é a história de como o JCL aprendeu a escolher caminhos.

1. O JCL não é apenas um carregador de programas

Para um programador COBOL iniciante, o JCL costuma parecer uma espécie de porteiro do mainframe.

Ele informa:

qual programa será executado;
quais arquivos serão utilizados;
onde os relatórios serão gravados;
quais parâmetros serão enviados;
quais recursos o JOB precisará.

Um exemplo simples poderia ser:

//RELATOR  JOB (1234),'BELLACOSA',CLASS=A,MSGCLASS=X
//STEP01   EXEC PGM=GERAREL
//ENTRADA  DD DSN=EMPRESA.VENDAS.DIARIO,DISP=SHR
//SAIDA    DD SYSOUT=*
//SYSOUT   DD SYSOUT=*
//SYSPRINT DD SYSOUT=*

Nesse caso, o JCL solicita ao sistema que execute o programa GERAREL.

Durante algum tempo, o iniciante imagina que o JCL faz apenas isso: chama programas e associa arquivos.

Mas existe um nível mais profundo.

Um JOB pode conter vários passos:

//STEP01 EXEC PGM=VALIDA
//STEP02 EXEC PGM=ATUALIZA
//STEP03 EXEC PGM=RELATOR
//STEP04 EXEC PGM=ENVIA

Agora surge uma pergunta crítica:

todos os passos devem executar mesmo quando um dos anteriores falhar?

Naturalmente, não.

Se o programa de validação descobrir que o arquivo de entrada está inválido, não faz sentido atualizar o banco de dados.

Se a atualização não for concluída, não é seguro gerar um relatório afirmando que tudo terminou corretamente.

Se o relatório não existir, não há motivo para tentar enviá-lo.

Foi para controlar decisões como essas que o JCL recebeu estruturas condicionais.

2. O que é IF/THEN/ELSE no JCL?

O IF/THEN/ELSE permite que o JOB escolha quais passos deverão executar com base no resultado de passos anteriores.

A ideia fundamental é a mesma encontrada no COBOL.

Em COBOL, podemos escrever:

IF WS-SALDO > 0
    DISPLAY 'CONTA POSITIVA'
ELSE
    DISPLAY 'CONTA SEM SALDO'
END-IF

O programa examina uma condição e escolhe uma ação.

No JCL, entretanto, a decisão é maior.

O JCL não escolhe apenas uma instrução.

Ele pode decidir se um programa inteiro será ou não executado.

Veja o exemplo básico:

//STEP01   EXEC PGM=PROGA
//TESTE01  IF (STEP01.RC = 0) THEN
//STEP02   EXEC PGM=PROGB
//         ELSE
//STEP03   EXEC PGM=PROGC
//         ENDIF

O fluxo é o seguinte:

STEP01 executa o programa PROGA.
O sistema registra o Return Code produzido por esse passo.
O JCL avalia a condição STEP01.RC = 0.
Se a condição for verdadeira, executa STEP02.
Caso contrário, executa STEP03.
Ao encontrar ENDIF, o fluxo condicional termina.

Visualmente:

                 STEP01
                   |
          STEP01.RC é igual a 0?
              /             \
           SIM               NÃO
            |                  |
         STEP02             STEP03
            \                  /
                 CONTINUA

É uma bifurcação na estrada do batch.

Um caminho será percorrido.

O outro ficará registrado no spool como um passo não executado por causa da lógica condicional.

3. O Return Code: a testemunha principal

O coração dessa história não é o IF.

É o Return Code.

O Return Code, geralmente abreviado como RC, é um valor devolvido por um programa ao terminar.

Ele comunica ao sistema o resultado da execução.

Uma convenção comum é:

Return Code	Significado habitual
0	Processamento concluído com sucesso
4	Sucesso com advertência
8	Erro de processamento
12	Erro grave
16	Falha severa

Mas existe uma regra fundamental:

O significado do Return Code pertence ao programa ou ao utilitário que o produziu.

Não existe uma lei universal determinando que RC=4 seja sempre aceitável ou que RC=8 represente exatamente o mesmo erro em todos os programas.

No IDCAMS, no DFSORT, em programas COBOL internos ou em produtos de terceiros, os significados podem variar.

Por isso, o programador deve conhecer o contrato de retorno do programa executado.

Imagine um programa de validação de clientes:

RC=0   Todos os registros são válidos
RC=4   Existem registros com advertências
RC=8   Existem registros rejeitados
RC=12  O arquivo não pôde ser processado

Nesse caso, talvez seja permitido continuar com RC=4.

A condição poderia ser:

//CHKVALID IF (STEP01.RC <= 4) THEN
//STEP02   EXEC PGM=ATUALIZA
//         ELSE
//STEPERRO EXEC PGM=TRATAERR
//         ENDIF

Agora o JOB aceita retorno zero ou quatro.

Isso demonstra por que o teste simplista RC = 0 nem sempre é suficiente.

4. Como um programa COBOL define o Return Code?

Em COBOL, o programa pode atribuir um valor ao registrador especial RETURN-CODE.

Exemplo:

       IDENTIFICATION DIVISION.
       PROGRAM-ID. VALIDA01.

       DATA DIVISION.
       WORKING-STORAGE SECTION.

       01  WS-QTD-ERROS       PIC 9(05) VALUE ZERO.

       PROCEDURE DIVISION.

           PERFORM PROCESSAR-ARQUIVO

           IF WS-QTD-ERROS = ZERO
               MOVE 0 TO RETURN-CODE
           ELSE
               MOVE 8 TO RETURN-CODE
           END-IF

           GOBACK.

Quando o programa termina com:

MOVE 0 TO RETURN-CODE

o passo pode aparecer no spool com retorno zero.

Quando termina com:

MOVE 8 TO RETURN-CODE

o JCL poderá testar esse valor em um passo posterior.

Essa comunicação é extremamente importante.

O programa COBOL conhece o resultado funcional do processamento.

O JCL conhece o fluxo completo do JOB.

O Return Code é a ponte entre os dois.

É como se o programa deixasse um bilhete sobre a mesa:

“Terminei. Este é o estado do caso.”

O JCL lê o bilhete e decide o que fazer.

5. A anatomia correta de uma estrutura condicional

Observe este exemplo mais completo:

//FECHAMEN JOB (ACCT),'FECHAMENTO',CLASS=A,MSGCLASS=X
//*
//VALIDA   EXEC PGM=PGMVALID
//ARQENT   DD DSN=EMPRESA.MOVIMENTO.DIA,DISP=SHR
//RELERR   DD SYSOUT=*
//*
//IFVALID  IF (VALIDA.RC <= 4) THEN
//*
//ATUALIZA EXEC PGM=PGMATU
//ARQENT   DD DSN=EMPRESA.MOVIMENTO.DIA,DISP=SHR
//CADASTRO DD DSN=EMPRESA.CLIENTES.MASTER,DISP=OLD
//*
//IFATU    IF (ATUALIZA.RC = 0) THEN
//RELATOR  EXEC PGM=PGMREL
//SAIDA    DD SYSOUT=*
//         ELSE
//ERROATU  EXEC PGM=PGMERRO
//         ENDIF
//*
//         ELSE
//ERROVAL  EXEC PGM=PGMERRO
//         ENDIF

Temos dois níveis de decisão.

Primeiro:

IF (VALIDA.RC <= 4) THEN

Se a validação for aceitável, o JOB executa ATUALIZA.

Depois:

IF (ATUALIZA.RC = 0) THEN

Se a atualização terminar com sucesso, o relatório será gerado.

Caso contrário, ERROATU será executado.

Se a validação inicial falhar, o JOB nem chega à atualização. Ele segue diretamente para ERROVAL.

Esse é um exemplo de IF aninhado.

Funciona bem, mas exige disciplina.

Quanto mais níveis de aninhamento existirem, mais difícil será compreender o JOB.

Um JCL com sete ou oito IFs dentro de outros IFs pode se transformar em uma mansão noir cheia de corredores, portas falsas e quartos onde ninguém se lembra de ter entrado.

6. Operadores de comparação

O JCL permite comparar Return Codes de diferentes maneiras.

Igualdade

//TESTE IF (STEP01.RC = 0) THEN

Também pode ser encontrada a forma mnemônica:

//TESTE IF (STEP01.RC EQ 0) THEN

Diferente

//TESTE IF (STEP01.RC NE 0) THEN

Dependendo do ambiente e da codificação disponível, símbolos como ¬= podem aparecer, mas as formas mnemônicas são frequentemente mais claras e evitam problemas de caracteres.

Maior que

//TESTE IF (STEP01.RC GT 4) THEN

Menor que

//TESTE IF (STEP01.RC LT 8) THEN

Maior ou igual

//TESTE IF (STEP01.RC GE 8) THEN

Menor ou igual

//TESTE IF (STEP01.RC LE 4) THEN

As formas mnemônicas são:

Operador	Significado
EQ	Igual
NE	Diferente
GT	Maior que
LT	Menor que
GE	Maior ou igual
LE	Menor ou igual

7. Condições compostas com AND e OR

O JCL pode analisar mais de uma evidência.

Utilizando AND

//TESTE IF (STEP01.RC = 0 & STEP02.RC = 0) THEN

Ou, conforme a forma adotada:

//TESTE IF (STEP01.RC EQ 0 AND STEP02.RC EQ 0) THEN

A condição será verdadeira somente se os dois passos terminarem com retorno zero.

Exemplo prático:

STEP01 valida o arquivo de clientes;
STEP02 valida o arquivo de contratos;
STEP03 executa apenas quando os dois arquivos são válidos.

//IFOK     IF (STEP01.RC EQ 0 AND STEP02.RC EQ 0) THEN
//STEP03   EXEC PGM=ATUALIZA
//         ENDIF

Utilizando OR

//IFERRO   IF (STEP01.RC GE 8 OR STEP02.RC GE 8) THEN
//TRATAERR EXEC PGM=ERROGER
//         ENDIF

Aqui, o tratamento será executado se qualquer um dos passos retornar oito ou mais.

A importância dos parênteses

Em condições complexas, use parênteses para deixar a intenção visível:

//TESTE IF ((STEP01.RC LE 4) AND
//          (STEP02.RC EQ 0)) THEN

O JOB não é lugar para jogos de adivinhação.

Um programador pode compreender uma expressão hoje e esquecê-la seis meses depois. Um colega chamado às três da madrugada terá ainda menos paciência.

Escreva para a manutenção, não apenas para o interpretador.

8. RC não é a mesma coisa que ABEND

Essa é uma das distinções mais importantes para um iniciante.

Um Return Code significa que o programa chegou a uma conclusão normal e devolveu um resultado.

Um ABEND significa que ocorreu uma terminação anormal.

Exemplos de ABEND:

S0C7
S0C4
S806
U4038

Um S0C7, por exemplo, frequentemente está relacionado a uma operação numérica inválida, como tentar tratar conteúdo não numérico como número.

Um S806 pode indicar que o programa não foi encontrado em uma biblioteca de carga acessível.

Nesses casos, não estamos simplesmente diante de um RC=8.

O programa sofreu uma interrupção anormal.

O JCL permite testar situações de ABEND.

Exemplo:

//STEP01   EXEC PGM=PROGA
//IFABEND  IF (STEP01.ABEND) THEN
//DUMP     EXEC PGM=GERADUMP
//         ENDIF

Também é possível testar se um passo executou normalmente:

//IFNORMAL IF (STEP01.RUN AND NOT STEP01.ABEND) THEN
//STEP02   EXEC PGM=PROGB
//         ENDIF

A disponibilidade e a forma exata dos testes devem ser verificadas de acordo com os padrões do ambiente e a documentação utilizada pela instalação, mas o conceito central permanece:

RC trata o resultado de uma conclusão normal;
ABEND trata uma terminação anormal;
um passo pode não executar por causa de uma condição anterior;
um passo não executado não deve ser confundido com um programa que executou e retornou erro.

No spool, essas diferenças contam a história real do JOB.

9. O que acontece quando não existe ELSE?

O ELSE é opcional.

Podemos escrever:

//STEP01   EXEC PGM=PROGA
//SEOK     IF (STEP01.RC EQ 0) THEN
//STEP02   EXEC PGM=PROGB
//         ENDIF

Se STEP01.RC for zero, STEP02 executará.

Caso contrário, o bloco será ignorado e o JOB continuará depois do ENDIF.

Isso é útil quando existe uma ação necessária apenas em uma situação específica.

Exemplo:

//AVISO IF (VALIDA.RC EQ 4) THEN
//EMAIL EXEC PGM=ENVIAAV
//      ENDIF

O e-mail será enviado somente quando houver advertências.

10. Vários passos dentro do THEN e do ELSE

Um erro comum é imaginar que cada bloco pode conter apenas um EXEC.

Na verdade, vários passos podem ser agrupados.

//STEP01   EXEC PGM=VALIDA
//FLUXOOK  IF (STEP01.RC LE 4) THEN
//STEP02   EXEC PGM=ATUALIZA
//STEP03   EXEC PGM=RELATOR
//STEP04   EXEC PGM=ENVIA
//         ELSE
//STEP90   EXEC PGM=LOGERRO
//STEP91   EXEC PGM=NOTIFICA
//         ENDIF

Se a validação for aceitável, três programas serão executados.

Se não for, dois programas de tratamento serão acionados.

Esse tipo de construção aparece com frequência em ambientes de produção.

11. Exemplo realista: fechamento de vendas

Considere o seguinte processo noturno:

Receber arquivo de vendas.
Validar estrutura.
Atualizar banco de dados.
Gerar relatório.
Enviar relatório.
Em caso de erro, registrar ocorrência e notificar o suporte.

O JCL poderia ser:

//VENDAS   JOB (FIN),'FECHAMENTO',CLASS=A,MSGCLASS=X
//*
//VALIDA   EXEC PGM=VALVEND
//ARQVEN   DD DSN=LOJA.VENDAS.DIARIA,DISP=SHR
//RELERR   DD SYSOUT=*
//*
//IFVAL    IF (VALIDA.RC LE 4) THEN
//*
//ATUALIZA EXEC PGM=ATUVEND
//ARQVEN   DD DSN=LOJA.VENDAS.DIARIA,DISP=SHR
//BASEVEN  DD DSN=LOJA.VENDAS.MASTER,DISP=OLD
//*
//IFATU    IF (ATUALIZA.RC EQ 0) THEN
//RELATOR  EXEC PGM=RELVEND
//RELATORI DD DSN=LOJA.RELATORIO.DIARIO,
//            DISP=(NEW,CATLG,DELETE),
//            SPACE=(CYL,(5,2)),
//            DCB=(RECFM=FB,LRECL=133,BLKSIZE=0)
//*
//ENVIA    EXEC PGM=MAILBAT
//ARQMAIL  DD DSN=LOJA.RELATORIO.DIARIO,DISP=SHR
//         ELSE
//LOGATU   EXEC PGM=LOGERRO
//AVISAATU EXEC PGM=AVISOPS
//         ENDIF
//*
//         ELSE
//LOGVAL   EXEC PGM=LOGERRO
//AVISAVAL EXEC PGM=AVISOPS
//         ENDIF

Agora examine a lógica.

Cenário 1: validação retorna zero

O arquivo está correto.

O JOB entra no primeiro THEN.

Cenário 2: validação retorna quatro

O arquivo contém advertências permitidas.

Como a condição é LE 4, o processamento continua.

Cenário 3: validação retorna oito

O JOB ignora atualização, relatório e envio.

Executa LOGVAL e AVISAVAL.

Cenário 4: atualização retorna oito

A validação foi aceita, mas a atualização falhou.

O relatório e o envio não executam.

O JOB chama LOGATU e AVISAATU.

Esse desenho impede que um relatório aparentemente correto seja enviado após uma atualização malsucedida.

É assim que uma estrutura condicional protege a integridade operacional.

12. IF/THEN/ELSE versus COND

Antes da popularização das estruturas condicionais explícitas, muitos JOBs utilizavam intensamente o parâmetro COND.

Exemplo:

//STEP02 EXEC PGM=PROGB,COND=(0,NE,STEP01)

O problema é que COND trabalha com uma lógica que muitos iniciantes consideram invertida.

O parâmetro indica uma condição para ignorar o passo.

Em outras palavras, quando a condição do COND é verdadeira, o passo não executa.

Isso exige atenção.

No exemplo:

COND=(0,NE,STEP01)

a interpretação é aproximadamente:

Ignore STEP02 se o Return Code de STEP01 for diferente de zero.

Portanto, STEP02 executa apenas quando STEP01.RC é zero.

O equivalente com IF é mais legível:

//TESTE IF (STEP01.RC EQ 0) THEN
//STEP02 EXEC PGM=PROGB
//      ENDIF

Compare:

COND=(0,NE,STEP01)

com:

IF (STEP01.RC EQ 0) THEN

A segunda forma parece uma frase.

Por isso, em fluxos complexos, o IF/THEN/ELSE geralmente facilita a leitura e a manutenção.

Isso não significa que COND esteja morto.

Muitos JOBs antigos e novos ainda o utilizam.

Um profissional de mainframe precisa compreender os dois.

Mas deve evitar misturar COND e estruturas IF sem necessidade, pois a combinação pode criar comportamentos difíceis de analisar.

13. Passo a passo para investigar um JOB condicional

Quando você encontrar um JCL grande, não tente compreender tudo ao mesmo tempo.

Use o método Bellacosa de investigação batch.

Passo 1 — Localize todos os EXEC

Anote cada step:

VALIDA
ATUALIZA
RELATOR
ENVIA
LOGERRO
AVISOPS

Isso revela os atores da história.

Passo 2 — Localize todos os IF

Procure:

IF
ELSE
ENDIF

Marque o início e o fim de cada bloco.

Passo 3 — Descubra qual step está sendo testado

Exemplo:

IF (VALIDA.RC LE 4) THEN

O suspeito interrogado é VALIDA.

Passo 4 — Consulte o significado dos Return Codes

Descubra o contrato do programa.

Talvez:

0 = sucesso
4 = aviso
8 = arquivo inválido
12 = falha de abertura

Sem essa informação, a condição é apenas um número sem contexto.

Passo 5 — Desenhe o fluxo

Use papel, quadro ou editor de texto:

VALIDA
  |
RC <= 4?
 /      \
SIM      NÃO
 |        |
ATUALIZA  LOGERRO
 |
RC = 0?
 /      \
SIM      NÃO
 |        |
RELATOR  AVISOPS
ENVIA

Passo 6 — Compare com o spool

Verifique:

quais passos realmente executaram;
quais foram ignorados;
quais retornaram código;
se houve ABEND;
qual foi o maior Return Code do JOB;
se alguma condição alterou o fluxo.

O spool é a cena do crime.

Não confie apenas no que o desenvolvedor acredita que aconteceu.

Leia as evidências.

14. Erros comuns de iniciantes

Considerar qualquer valor diferente de zero como desastre

Nem sempre RC=4 representa falha.

Pode ser apenas uma advertência.

O contrato do programa deve definir isso.

Testar o step errado

IF (STEP02.RC EQ 0) THEN

não funciona como esperado se STEP02 não executou ou se a intenção era testar STEP01.

Nomes claros reduzem esse risco.

Esquecer o ENDIF

Cada estrutura precisa ser encerrada corretamente.

Em fluxos aninhados, identação e comentários ajudam muito.

Criar condições excessivamente complexas

Uma expressão com muitos AND, OR, NOT e parênteses pode funcionar, mas se tornar impossível de manter.

Às vezes, dividir o processamento em mais de um bloco é melhor.

Confundir step ignorado com erro

Um passo dentro de um ramo não escolhido pode aparecer como não executado.

Isso não significa que seu programa falhou.

Significa que o JCL decidiu não chamá-lo.

Tratar ABEND como Return Code comum

Um S0C7 não é simplesmente RC=7.

ABENDs possuem outra natureza e exigem tratamento apropriado.

Não documentar Return Codes funcionais

Um programa COBOL que retorna RC=6, RC=20 ou RC=32 sem documentação está deixando uma bomba-relógio para a equipe de produção.

15. Boas práticas para JCL de produção

Use nomes significativos

Evite:

//STEP1
//STEP2
//STEP3

Prefira:

//VALIDA
//ATUALIZA
//GERAREL
//ENVIA

O nome do step deve ajudar a contar a história do JOB.

Nomeie os blocos condicionais

//IFVALID IF (VALIDA.RC LE 4) THEN

Isso facilita localizar mensagens e interpretar o fluxo.

Comente decisões incomuns

//* RC=4 INDICA REGISTROS REJEITADOS, MAS PROCESSAMENTO PODE CONTINUAR

Um bom comentário economiza horas de investigação.

Padronize Return Codes

A equipe deve saber o que cada faixa representa.

Por exemplo:

0      Sucesso
4      Advertência
8      Erro funcional
12     Erro técnico
16+    Falha severa

Evite aninhamento profundo

Se o JOB parecer uma boneca russa de IFs, talvez seja hora de redesenhar o fluxo.

Sempre pense no tratamento de erro

Não basta impedir a execução de passos posteriores.

Pergunte:

quem será notificado?
onde o erro será registrado?
o arquivo será preservado?
será necessário restart?
o operador saberá qual ação tomar?
o scheduler interpretará o resultado corretamente?

Um bom IF não apenas impede problemas.

Ele orienta a recuperação.

16. Curiosidades do mundo batch

O JOB pode terminar “bem”, mas o negócio ter falhado

Tecnicamente, um programa pode terminar com RC=0 mesmo quando não processou nada útil.

Por exemplo, o arquivo estava vazio, mas o programa considerou isso normal.

O sistema operacional vê sucesso.

O negócio talvez veja um desastre.

Por isso, Return Codes devem representar estados relevantes para a operação.

O maior RC costuma chamar atenção

Ferramentas de operação e schedulers frequentemente analisam o maior Return Code encontrado no JOB.

Mas o comportamento exato depende das regras da instalação e da automação utilizada.

Schedulers também tomam decisões

Produtos como IBM Workload Scheduler, Control-M e outras soluções podem avaliar status de JOBs, Return Codes, dependências, horários e recursos.

Nesse cenário, existe uma cadeia de inteligência:

Programa COBOL
      ↓
Return Code
      ↓
JCL IF/THEN/ELSE
      ↓
Resultado do JOB
      ↓
Scheduler
      ↓
Próximo processamento

Um pequeno número devolvido por um programa pode impedir a execução de uma cadeia inteira de processamento corporativo.

Um RC mal definido pode custar caro

Imagine um programa que detecta inconsistência financeira, grava uma mensagem no relatório, mas termina com RC=0.

O JCL entende que tudo ocorreu corretamente.

O relatório é enviado.

O scheduler libera os próximos JOBs.

Horas depois, alguém descobre que os dados estavam errados.

O problema não foi apenas técnico.

Foi uma falha de comunicação entre programa e operação.

17. O exemplo definitivo para um Padawan COBOL

Vamos construir um fluxo simples e completo.

O objetivo é:

validar um arquivo;
processá-lo se estiver correto;
gerar relatório se o processamento terminar bem;
executar tratamento se algo falhar.

//PEDIDOS  JOB (1234),'PEDIDOS',CLASS=A,MSGCLASS=X
//*
//VALIDA   EXEC PGM=VALPED
//ARQPED   DD DSN=EMPRESA.PEDIDOS.ENTRADA,DISP=SHR
//SYSOUT   DD SYSOUT=*
//*
//IFVAL    IF (VALIDA.RC LE 4) THEN
//*
//PROCESSA EXEC PGM=PROCPED
//ARQPED   DD DSN=EMPRESA.PEDIDOS.ENTRADA,DISP=SHR
//CADPED   DD DSN=EMPRESA.PEDIDOS.MASTER,DISP=OLD
//SYSOUT   DD SYSOUT=*
//*
//IFPROC   IF (PROCESSA.RC EQ 0) THEN
//RELATOR  EXEC PGM=RELPED
//RELATORI DD SYSOUT=*
//         ELSE
//ERROPROC EXEC PGM=TRATPED
//MOTIVO   DD *
FALHA NO PROCESSAMENTO DE PEDIDOS
/*
//         ENDIF
//*
//         ELSE
//ERROVAL  EXEC PGM=TRATPED
//MOTIVO   DD *
ARQUIVO DE PEDIDOS REPROVADO NA VALIDACAO
/*
//         ENDIF

O raciocínio é:

VALIDA
  |
  +-- RC 0 ou 4?
        |
        +-- SIM → PROCESSA
        |            |
        |            +-- RC 0?
        |                  |
        |                  +-- SIM → RELATOR
        |                  |
        |                  +-- NÃO → ERROPROC
        |
        +-- NÃO → ERROVAL

O iniciante que aprende a desenhar esse fluxo já está deixando de apenas “ler JCL”.

Ele começa a pensar como alguém de produção.

18. O easter egg do velho operador

Dizem que, em um data center antigo, havia um operador chamado Moretti.

Ninguém sabia sua idade. Alguns juravam que ele já trabalhava ali quando os discos ainda pareciam máquinas de lavar.

Moretti tinha um ritual.

Sempre que um JOB terminava, ele não olhava primeiro para o programa, para o consumo de CPU ou para o horário.

Ele procurava o Return Code.

Certa madrugada, um novato perguntou:

— Por que o senhor olha primeiro para um número tão pequeno?

Moretti respondeu:

— Porque os programas falam muito nos relatórios, mas dizem a verdade no retorno.

Anos depois, quando Moretti se aposentou, encontraram um cartão perfurado em sua gaveta.

Nele havia apenas uma frase:

RC=0 NÃO SIGNIFICA QUE O UNIVERSO ESTÁ CORRETO.
SIGNIFICA APENAS QUE O PROGRAMA DISSE QUE ESTÁ.

Ninguém sabe se a história é verdadeira.

Mas todo programador mainframe deveria guardar a frase.

19. A conclusão do caso

Naquela madrugada, o jovem programador voltou ao telefone.

— Bellacosa, encontrei o problema. O primeiro programa terminou com RC=4. O IF estava testando apenas RC=0. Por isso o passo de envio não executou.

— E o que significa RC=4 nesse programa?

Houve silêncio.

Depois, ouvi o som de páginas sendo folheadas.

— Significa que o relatório foi gerado, mas alguns registros foram ignorados. Ainda é permitido enviá-lo.

— Então o erro não estava no programa.

— Estava na condição.

Exatamente.

O programa havia feito seu trabalho.

O JCL também.

O problema era que alguém havia escrito uma regra incompleta.

A condição dizia:

IF (STEP01.RC EQ 0) THEN

Mas a regra de negócio deveria aceitar zero e quatro:

IF (STEP01.RC LE 4) THEN

Uma pequena diferença.

Dois caracteres.

Uma decisão completamente diferente.

No mainframe, muitas catástrofes não começam com explosões, fumaça ou mensagens dramáticas.

Elas começam com detalhes.

Um dataset com o DISP errado.

Um campo numérico mal inicializado.

Uma biblioteca ausente no STEPLIB.

Um Return Code não documentado.

Ou um IF que pergunta a coisa errada.

O IF/THEN/ELSE transforma o JCL em algo muito maior do que uma sequência estática de comandos. Ele permite que o JOB observe resultados, escolha caminhos, evite processamentos inúteis, proteja dados, acione tratamentos e automatize decisões operacionais.

Para quem trabalha com COBOL, produção, suporte, operações ou sistemas, dominar esse recurso não é opcional.

É parte da alfabetização batch.

Quando você compreender o Return Code, começará a entender o programa.

Quando compreender o IF, começará a entender o JOB.

E quando conseguir seguir o fluxo inteiro pelo spool, examinando cada passo, cada retorno, cada desvio e cada programa ignorado...

Bem...

Nesse momento, jovem Padawan, você já não estará apenas executando JCL.

Estará investigando o mainframe.

E em uma madrugada chuvosa, quando um JOB de milhões de reais parar sem explicação aparente, talvez alguém ligue para você.

Na tela, uma única linha estará esperando:

//MISTERIO IF (STEP01.RC GT 4) THEN

O café estará frio.

A sala estará escura.

E o caso será seu.

Translate

quarta-feira, 13 de novembro de 2019