JCL - Definindo Conjuntos de Dados
Um nome de conjunto de dados especifica o nome de um arquivo e é denotado por DSN em JCL. O parâmetro DSN se refere ao nome do conjunto de dados físico de um conjunto de dados recém-criado ou existente. O valor DSN pode ser composto de subnomes, cada um com 1 a 8 caracteres, separados por pontos e com comprimento total de 44 caracteres (alfanuméricos). A seguir está a sintaxe:
DSN=&name | *.stepname.ddnameTemporary datasetsprecisam de armazenamento apenas para a duração do trabalho e são excluídos na conclusão do trabalho. Esses conjuntos de dados são representados comoDSN=&name ou simplesmente sem um DSN especificado.
Se um conjunto de dados temporário criado por uma etapa de trabalho for usado na próxima etapa de trabalho, ele é referenciado como DSN=*.stepname.ddname. Isso é chamadoBackward Referencing.
Conjuntos de dados de concatenação
Se houver mais de um conjunto de dados do mesmo formato, eles podem ser concatenados e passados como uma entrada para o programa em um único nome DD.
//CONCATEX JOB CLASS=6,NOTIFY=&SYSUID
//*
//STEP10 EXEC PGM=SORT
//SORTIN DD DSN=SAMPLE.INPUT1,DISP=SHR
// DD DSN=SAMPLE.INPUT2,DISP=SHR
// DD DSN=SAMPLE.INPUT3,DISP=SHR
//SORTOUT DD DSN=SAMPLE.OUTPUT,DISP=(,CATLG,DELETE),
// LRECL=50,RECFM=FBNo exemplo acima, três conjuntos de dados são concatenados e passados como entrada para o programa SORT no nome SORTIN DD. Os arquivos são mesclados, classificados nos campos-chave especificados e, em seguida, gravados em um único arquivo de saída SAMPLE.OUTPUT no nome SORTOUT DD.
Substituindo conjuntos de dados
Em um JCL padronizado, o programa a ser executado e seus conjuntos de dados relacionados são colocados em um procedimento catalogado, que é chamado no JCL. Normalmente, para fins de teste ou para uma correção de incidente, pode haver a necessidade de usar conjuntos de dados diferentes daqueles especificados no procedimento catalogado. Nesse caso, o conjunto de dados no procedimento pode ser substituído no JCL.
//SAMPINST JOB 1,CLASS=6,MSGCLASS=Y,NOTIFY=&SYSUID
//*
//JSTEP1 EXEC CATLPROC,PROG=CATPRC1,DSNME=MYDATA.URMI.INPUT
// DATAC=MYDATA.BASE.LIB1(DATA1)
//STEP1.IN1 DD DSN=MYDATA.OVER.INPUT,DISP=SHR
//*
//* The cataloged procedure is as below:
//*
//CATLPROC PROC PROG=,BASELB=MYCOBOL.BASE.LIB1
//*
//STEP1 EXEC PGM=&PROG
//STEPLIB DD DSN=&BASELB,DISP=SHR
//IN1 DD DSN=MYDATA.URMI.INPUT,DISP=SHR
//OUT1 DD SYSOUT=*
//SYSOUT DD SYSOUT=*
//SYSIN DD MYDATA.BASE.LIB1(DATA1),DISP=SHR
//*
//STEP2 EXEC PGM=SORTNo exemplo acima, o conjunto de dados IN1 usa o arquivo MYDATA.URMI.INPUT no PROC, que é sobrescrito no JCL. Portanto, o arquivo de entrada usado na execução é MYDATA.OVER.INPUT. Observe que o conjunto de dados é referido como STEP1.IN1. Se houver apenas uma etapa no JCL / PROC, o conjunto de dados pode ser referido apenas com o nome DD. Da mesma forma, se houver mais de uma etapa na JCL, o conjunto de dados deve ser substituído como JSTEP1.STEP1.IN1.
//SAMPINST JOB 1,CLASS=6,MSGCLASS=Y,NOTIFY=&SYSUID
//*
//STEP EXEC CATLPROC,PROG=CATPRC1,DSNME=MYDATA.URMI.INPUT
// DATAC=MYDATA.BASE.LIB1(DATA1)
//STEP1.IN1 DD DSN=MYDATA.OVER.INPUT,DISP=SHR
// DD DUMMY
// DD DUMMY
//*No exemplo acima, dos três conjuntos de dados concatenados em IN1, o primeiro é sobrescrito no JCL e o restante é mantido como aquele presente no PROC.
Definindo GDGs em um JCL
Grupos de dados de geração (GDGs) são grupos de conjuntos de dados relacionados entre si por um nome comum. O nome comum é conhecido como base GDG e cada conjunto de dados associado à base é chamado de versão GDG.
Por exemplo, MYDATA.URMI.SAMPLE.GDG é o nome de base do GDG. Os conjuntos de dados são nomeados como MYDATA.URMI.SAMPLE.GDG.G0001V00, MYDATA.URMI.SAMPLE.GDG.G0002V00 e assim por diante. A versão mais recente do GDG é referida como MYDATA.URMI.SAMPLE.GDG (0), as versões anteriores são referidas como (-1), (-2) e assim por diante. A próxima versão a ser criada em um programa é chamada de MYDATA.URMI.SAMPLE.GDG (+1) no JCL.
Criar / alterar GDG em um JCL
As versões GDG podem ter parâmetros DCB iguais ou diferentes. Um modelo inicial DCB pode ser definido para ser usado por todas as versões, mas pode ser substituído ao criar novas versões.
//GDGSTEP1 EXEC PGM=IDCAMS
//SYSPRINT DD SYSOUT=*
//SYSIN DD *
DEFINE GDG(NAME(MYDATA.URMI.SAMPLE.GDG) -
LIMIT(7) -
NOEMPTY -
SCRATCH)
/*
//GDGSTEP2 EXEC PGM=IEFBR14
//GDGMODLD DD DSN=MYDATA.URMI.SAMPLE.GDG,
// DISP=(NEW,CATLG,DELETE),
// UNIT=SYSDA,
// SPACE=(CYL,10,20),
// DCB=(LRECL=50,RECFM=FB)
//No exemplo acima, o utilitário IDCAMS define a base GDG em GDGSTEP1 com os parâmetros abaixo passados na instrução SYSIN DD:
NAME especifica o nome do conjunto de dados físico da base GDG.
LIMIT especifica o número máximo de versões que a base GDG pode conter.
EMPTY cancela o catálogo de todas as gerações quando o LIMITE é atingido.
NOEMPTY descataloga a geração menos recente.
SCRATCH exclui fisicamente a geração quando ela não é catalogada.
NOSCRATCH não apague o dataset, ou seja, ele pode ser referenciado usando os parâmetros UNIT e VOL.
Em GDGSTEP2, o utilitário IEFBR14 especifica os parâmetros do modelo DD a serem usados por todas as versões.
IDCAMS pode ser usado para alterar os parâmetros de definição de um GDG, como aumentar LIMIT, alterar EMPTY para NOEMPTY, etc., e suas versões relacionadas usando o comando SYSIN é ALTER MYDATA.URMI.SAMPLE.GDG LIMIT(15) EMPTY.
Excluir GDG em um JCL
Usando o utilitário IEFBR14, podemos excluir uma única versão de um GDG.
//GDGSTEP3 EXEC PGM=IEFBR14
//GDGDEL DD DSN=MYDATA.URMI.SAMPLE.GDG(0),
// DISP=(OLD,DELETE,DELETE)No exemplo acima, a versão mais recente de MYDATA.URMI.SAMPLE.GDG foi excluída. Observe que o parâmetro DISP na conclusão normal do trabalho é codificado como DELETE. Portanto, o conjunto de dados é excluído quando a execução do trabalho é concluída.
IDCAMS pode ser usado para excluir o GDG e suas versões relacionadas usando o comando SYSIN DELETE(MYDATA.URMI.SAMPLE.GDG) GDG FORCE/PURGE.
FORCEexclui as versões GDG e a base GDG. Se qualquer uma das versões do GDG for configurada com uma data de expiração que ainda não expirou, essas não serão excluídas e, portanto, a base do GDG será mantida.
PURGE exclui as versões do GDG e a base do GDG, independentemente da data de expiração.
Usando GDG em um JCL
No exemplo a seguir, a versão mais recente de MYDATA.URMI.SAMPLE.GDG é usada como entrada para o programa e uma nova versão de MYDATA.URMI.SAMPLE.GDG é criada como saída.
//CNDSAMP JOB CLASS=6,NOTIFY=&SYSUID
//*
//STP01 EXEC PGM=MYCOBB
//IN1 DD DSN=MYDATA.URMI.SAMPLE.GDG(0),DISP=SHR
//OUT1 DD DSN=MYDATA.URMI.SAMPLE.GDG(+1),DISP=(,CALTG,DELETE)
// LRECL=100,RECFM=FBAqui, se o GDG tiver sido referido pelo nome real como MYDATA.URMI.SAMPLE.GDG.G0001V00, isso levará à alteração do JCL todas as vezes antes da execução. Usar (0) e (+1) faz com que ele substitua dinamicamente a versão GDG para execução.