2.12 - Variaveis e afins

Sempre que você encontrar uma linha com um “comando” SET no JCL ali estará definido algo que será substituido mais pra frente quando da submissão do job. Mas será substituido apenas nos cartoes EXEC e DD e em um qualificador de um arquivo ou outro, um parm talvez. Aqui nao tem segredo, geralmente tem um “JOB” que vai ser um JCL basicao que será o “chamador” de uma procedure, algo como

//JOB00000 JOB 'EXECUTA HELLO WORLD',
// NOTIFY=&SYSUID 
// SET ENTRADA=ARQ.BUGA.ENTRADA 
// SET SAIDA=ARQ.BUGA.SAIDA 
//RODAPROC EXEC PROC0001

E o PROC0001 seria assim

//PROC0001 PROC 
//STEP0001 EXEC PGM=IEBGENER 
//SYSUT1 DD DSN=&ENTRADA,DISP=SHR 
//SYSUT2 DD DSN=&SAIDA,DISP=MOD 
//SYSPRINT DD SYSOUT=* 
//SYSIN DD DUMMY
// PEND

“PROC” ou Procedure difere do JOB porque não tem cabeçalho, afinal de contas algum JOB vai chama-la e esse JOB já carregou o minimo de recursos que o sistema operacional precisaria para a execução. A PROC tem geralmente o mesmo nome externo (do membro) e o identificador da primeira linha (sempre PROC) e termina com um PEND.

Basicamente existem 2 tipos de procedures, as catalogadas que estão separadas do JOB que as executa como é a PROC0001 e as que são conhecidas como In-Stream que possuem o JOB no mesmo dataset.

O grande lance de usar procedures catalogadas é que você consegue ter uma versatilidade muito maior que um JOB que é meio engessado, deixa eu explicar melhor, em um JOB se você quiser utilizar um outro arquivo de entrada você precisa altera direto nele. Se for uma procedure ela pode receber o arquivo como uma variavel que foi definida no job que a chamou, como no exemplo anterior, você precisa apenas alterar no JOB que é bem basico e geralmente é um passador de parametros para a procedure.

Nas versoes mais recentes do sistema operacional (acho que da V2R1 pra frente) o JCL aceita substituições de “variaveis/parametros” para dentro de cartoes SYSIN e afins, antes dessa funcionalidade seu ambiente provavelmente possuia alguma traquitana para conseguir realizar tal façanha.

A adaptacao é simples e requer que seu JCL receba umas paradinhas novas, tecnicamente falando é um Statment novo, o EXPORT que trabalhara em conjunto com o SYMBOLS na sequencia de um DD* e também foi introduzido o PARMDD que analogo ao EXPORT informa onde estao os parametros que serao substituidos.

Segue exemplo que ilustra a utilizacao da substituição de simbolicos seja em partes de nome de datasets ou como dados “in-stream”, o JOB é um chamador da procedure de compilacao do PL/I e execução de bind:

///COMPILA JOB 'COMPILA PL1',
// NOTIFY=&SYSUID
//* -------------------------------------
// EXPORT SYMLIST=(MEMBRO) *** PRA SUBSTITUIR EM SYSIN E AFINS
// SET MEMBRO=CCR213P *** PROGRAMA A SER COMPILADO
//* -------------------------------------
//JCL JCLLIB ORDER=BUGA.PROCLB
//* -------------------------------------
//IBMZCLD EXEC IBMZCLD
//PPLI.SYSIN DD DISP=SHR,DSN=BUGA.FONTES.PL1(&MEMBRO) ** FONTE
//PPLI.SYSLIB DD DISP=SHR,DSN=OUTROS.SISTEMAS.BOOKS
//PC.DBRMLIB DD DISP=SHR,DSN=BUGA.DBRMLIB(&MEMBRO)
//PC.SYSLIB DD DISP=SHR,DSN=OUTROS.SISTEMAS.BOOKS
//-------------------------------------------------------------------- 
// BIND DO PROGRAMA
//-------------------------------------------------------------------- 
//STEP1 EXEC PGM=IKJEFT01,REGION=4096K
//DBRMLIB DD DSN=BUGA.DBRMLIB,DISP=SHR
//SYSTSPRT DD SYSOUT=,DCB=BLKSIZE=121
//SYSPRINT DD SYSOUT=*
//SYSUDUMP DD SYSOUT=*
//SYSIN DD DUMMY
//SYSTSIN DD ,SYMBOLS=JCLONLY *** SUBTITUI &MEMBRO ABAIXO
    DSN SYSTEM(DB2)
    BIND PACKAGE(PADRON) -
    OWNER(BUGA) -
    MEMBER(&MEMBRO) -
    VALIDATE(BIND) -
    SQLERROR(CONTINUE) -
    ISOLATION(CS) -
    RELEASE(COMMIT) -
    ACTION(REPLACE)
//

Last updated