CA-7

CA-7

O CA-7 é mais uma das ferramentas de calendário para Job. São chamadas 'Schedulers', pois 'Schedulam' os Jobs. Estas ferramentas ajudam muito na otimização do trabalho no Mainframe, pois depois do aparecimento delas, os Jobs são colocados ordenadamente e automaticamente no sistema para executar, o analista, operador e programador, entram no CA-7 e define para um Job ou para um pacote inteiro de Jobs, qual será o dia e hora que vão executar, antes ou depois de qual outro Job, usando este ou aquele recurso, etc. Antes do CA-7 tudo isso ere feito MANUALMENTE. Entao, as ferramentas de Schedulling vieram para ajudar, e muito, em todo o trabalho de Mainframe, mais precisamente no processamento Batch.



As Tasks de CA7

No sistema, existem algumas Tasks que o CA-7 necessita para que os Jobs executem através do CA-7. Estas são CA7ONL e CA7NCF. Existem ainda as Tasks CA7ICOM e CA-11. O CA7ICOM e o CA7NCF são usado para quando Jobs de outros sistemas executam no CA-7 de um único sistema. O CA7ICOM precisa estar instalado em todos os sistemas que dividem o CA-7. Já o CA-11 é usado para ajudar o CA-7, o CA-11 é usado para 'restart' de Jobs, se o CA-11 está instalado em um sistema, fica mais fácil trabalhar com Jobs que estão em erro.




Telas de DB


Estas telas sao as usadas para definir as informacoes de Schedule de um Job.

Definindo um Job no CA7

Estas telas em forma de menus sao usados para trabalhar com o plano de Schedulling do CA7.

Segue o que se mostra no menu:

DATA BASE DEFINITION FOR:

1 - CPU JOB
2 - SCHEDULING
3 - JOB PREDECESSOR/SUCCESSOR
4 - WORKLOAD DOCUMENTATION
5 - INPUT/OUTPUT NETWORK
6 - DATA SET

OTHER FUNCTIONS AVAILABLE:

7 - JCL LIBRARY MAINTENANCE
8 - TEXT EDITOR
9 - CLEAR THE TEXT EDITOR ACTIVE AREA
ACTIVE AREA NOW CONTAINS 0000 LINES OF TEXT

A partir dai, e so entrar na opcao escolhida para o que se deseja. As outras telas serao apresentadas a seguir.




DB.1


Esta opção dá ao usuário a oportunidade de ver se o job existe no Database do CA-7. Tambem pode-se DELETAR, PURGAR, e ADICIONAR um Job.

Explicando brevemente as opcoes de FUNCTION na tela DB.1

LIST - Lista um job ja existente no ca7

ADD - Adiciona um Job no CA-7

DELETE - Deleta o Job do CA-7 mas nao retira as 'amarracoes' do job, ou seja, nenhuma dependencia desse job nao vai ser retirada.

PURGE - Deleta o Job e retira todos as 'amarracoes' desse job para com outros, remove as dependecias.

Segue pequena descrição do que se pode ver nessa tela, nos outros campos:

Antes de um Job ser colocado no calendário, ele precisa ser definido no Database, de acordo com as caracteristicas de cada Job. Isto é possível usando a opção DB.1 (CPU Job Definition).

Para entrar no DB.1 é só digitar DB.1 na linha de comando do CA-7.


O que se vê na tela de DB.1:


JOB - O nome do Job a ser adicionado, listado, deletado ou atualizado. De 1 a 8 alfanumerico.

SYSTEM - O nome do sistema a qual o Job pertence. De 1 a 8 alfanumerico. Importante que o nome do SYSTEM tenha um nome parecido com o Index definido para a Biblioteca de JCL.

JOBNET - Campo para informações acicionais do Job. De 1 a 8 alfanumerico.

OWNER - Campo para idenfificação do ID dono do Job, por motivos de segurança.

UID - Define o dódigo do Job (de 1 a 255). Este código, quando combinado com definições de segurança, quem tem acesso ao Job.

ID - Index (De 0 a 254) na Biblioteca de onde o CA7 para o Job é retirado. Este ID ou Index funciona como um ALIAS, ou um 'apelido' para o Dataset que seria a Biblioteca de JCL.

MEMBER - O membro de JCL que vai ser usado no Job. Normalmente o mesmo nome do Job.

RELOAD - Indica se a referencia cruzada de informação deve ser carregada.

EXEC - Indica se o Job deve submeter no sistema operacional quando está no calendário ou adicionado manualmente. JCL não é pedido para Jobs não executáveis. Pode-se usar a opcao EXEC=N para um Dummy Job, para que o job execute no JES mas nao execute nenhum STEP ou programa, muito usado para continuar uma cadeia de jobs de execucao sem ter que Deletar um Job.

RETAIN–JCL – Indica se o JCL da ultima boa execução do Jobs é paar ser mantida na Trailer Queue.

HOLD - Indica se o Job deve entrar na Request Queue com requerimento HOLD.

JCL-OVRD - Indica se o Job deve entrar na Request Queue com requerimento de JCL override

USE-OVRD-LIB - Indica se o Job deve puxar o JCL de uma biblioteca 254 para o próximo ciclo de produção.

VERIFY - Indica se o Job deve entrar na Request Queue com requerimento de verificação

MAINT - Indica se o Job é de manutenção. Este parametro permite que se bloqueie o uso de um DSN gerado por ele de ser usado por ou para outro Job. Se este job cria um Dataset que e Trigger de outro job, entao tem que estar definido como MAINT=N, pois entao o CA-7 vai deixar o DSN livre para uso. Mas se, por exemplo, o Dataset gerado por esse job nao deve ser usado por outro job, ou as vezes o proprio job usa um Dataset que ele cria, entao o MAINT=Y deve ser definido.

JOB - Indica o Lead Time ( de 1 a 99 ) a ser usado para requerimento de Job que tenha valores LEADTM definidos como 00 na tela de DB.3.2

DSN - Indica o Lead Time ( de 1 a 99 ) a ser usado para requerimento de Dataset definido na tela DB.3.1, que já tenha sido definido como 00.

MAINID - Especifica um identificados no CA7 indicando qual CPU deve ou nao exetucar um Job.

INSERT-RMS - Indica se o CA7 deverá automaticamente inserir o Step U11RMS. Deve ser Y(yes) para usar o CA11 para re-executar um Job.

COND CODE – Indica qual cond code o CA7 deveria verificar para determinar se o Job terminou bem.

RO - Especifica a condição para comparar contra o COND-CODE para determinar se o Job terminou bem. Para que o CA-7 deixe de fazer a verificacao de Condition Code, entao deve-se definir o COND CODE=0 e RO=0. Existe outro tipo de verificacao pelo CA-7 que seria uma verificacao por parametros no JCL, entao deve-se definir o COND CODE=0 e o RO=#S, entao cartoes #SCC pre-definidos no JCL serao lidos no JCL.

BEFORE - Indica que o Job não deve ser considerado no calendário antes da data indicada.

AFTER - Indica que o Job deve ser considerado no calendário depois da data indicada.

LTERM - Indica qual terminal logico do CA7 deve receber mensagens sobre o job.

RQMT-LIST – Indica se os requerimentos devem ser listados no terminal especificado no LTERM quando os Jobs entram na Request Queue.

PROMPTS – Indica se o LTERM terminal deve enviar mensagens de Late (atrasado) se o Job estiver Late (atrasado).

RQMTS NOT USED - Indica se o CA7 deve gerar esta mensagen de erro.

DSN NOT FOUND – Indica se o CA7 deve gerarmensagem de erro SMF0-13.

REGION - Indica o tamanho maximo de uma Region especificado no JOB ou no parametro EXEC, ou usar o Default se nada estiver especificado no JCL.

CLOCK-TIME – Indica o horário necessário para o Job executar. Se colocar o CLOCK-TIME=2359, define que os parametros definidos no Schedule do job na tela DB.1 serao usados sem mudanca. Caso deixe este parametro definido normalmente, entao o proprio CA-7 definira este parametro, pois este seria uma media de tempo total de execucao do Job, definido em minutos e horas.

CPU-TIME - Indica o tempo de CPU necessário para executar o Job.

CLASS - Indica a classe WLB que o Jobs deve usar.

PRTY - Indica a prioridade WLB (De 0 a 255) que o Job vai ter quando entrar na Request Queue.

MSGCLASS - Automaticamente tirado do JOB.

TYPE1: M - TYPE1:C - TYPE2:M - TYPE2:C - Todos em comum com o WLB para Tape Drives.




DB.2 - Schedulling


Usado para parametros de Schedulling tipo data, tempo, Trigger, etc.

Dentro desta opcao, ha um sub-menu explicando, que se segue abaixo:

DATE/TIME SCHEDULING FOR:

1 - CPU JOB
2 - INPUT NETWORK
3 - OUTPUT NETWORK

TRIGGER SCHEDULING FOR:

4 - JOB TRIGGERING OTHER CPU JOB(S)
5 - INPUT NETWORK TRIGGERING CPU JOB(S)
6 - DATA SET TRIGGERING CPU JOB(S)

OTHER FUNCTIONS AVAILABLE:

7 - MODIFICATION TO RESOLVED SCHEDULE DATES
8 - BASE CALENDAR MAINTENANCE


DB.2.1 - Scheduling de Job


Algumas Dicas sobre Scheduling.

As opcoes da primeira tela sao as seguintes:

EDIT - Usado quando esta adicionando o primeiro Schedule de um Job.

DELETE - Usado para Deletar Schedule de um job, mas este faz o DELETE de TODOS os SCHID's, portanto cuidado. Se for um DELETE de um so SCHID, entado entrar no SCHEDULE com FE e fazer o DELETE dentro.

FE - Usado para fazer qualquer alteracao nos Schedules do Job.

FETCH - Usado para 'copiar' o Schedule de um job para outro. Mas este comando copia TODOS os Schedules de um job para outro. Deve-se digitar FETCH e o nome do Job de que se quer copiar o Schedule, digita ENTER, entao coloca SAVE o nome do Job novo e ENTER dai ta feito.

RESOLV - USado para validar a criacao de Schedule ou alteracao no Schedule de um Job no CA7 .


Adicionando ou Alterando um Schedule


Quando for adicionar um Job, deve-se usar a opcao EDIT, Jobname e o calendario que sera usado logo abaixo, caso nao coloque o calendario, o DEFAULT sera o 7A.

Assim que pressionar ENTER, a proxima tela vem para as difinicoes. Deve-se escolher entre as opcoes de ADD, LIST, DELETE, REPLACE, SS, SR, ETC.

ADD - Usado para adicionar um novo Schedule para o Job.

DELETE - Usado para Deletar Schedule para o Job. Usado para deletar um ou mais Schedules de um Job, mas nao todos.

LIST - Lista os Schedules de um Job.

REPL - Replace, usado para alteracao do Schedule de um job.

SS - Save Schedule - Usado para salvar o primeiro schedule de um job.


Adicionando um Schedule

Apos Selecionar EDIT ou FE na primeira tela do Scheduling, coloque o nome do Job e o calendario no campo SCAL (caso seja um ADD de um novo Schedule), e pressione ENTER

Se esta adicionando um Schedule entao no primeiro campo deve ser colocado ADD, e entao os seguintes campos podem/devem ser preenchidos:

SCHID ID - Este campo numerico ( de 0 a 255 ), vai ser o codigo do Schedule, como um "nome" para o Schedule.

SCAL - Campo onde pode-se preencher o calendario do Job, dependendo se o mesmo calendario sera usado pra todos os Schidules do Job, ou se vai usar um calendario padrao, definido na primeira tela do Schedule. Este campo deve ser preenchido escolhendo o calendario de acordo com a necessidade de execucao do Job.

ROLL - Este campo se traduz de maneira pratica fazendo uma pergunta. "Este job deve ignorar feriados no calendario que se esta usando como base?". Entao as seguintes opcoes seriam estas:

D (DROP) - Nao executa nos feriados, etc.

N (NO ROLL) - Executa nos feriados e dias uteis do calendario.

F (FORWARD) - Executa um dia depois do dia marcado como feriado no calendario base.

B (BACKWARD) - Executa um dia antes do dia marcado como feriado.

INDEX - Parametro ligado ao parametro ROLL, que caso seja usado F ou B no parametro ROLL, o parametro INDEX vai definir quando o Job vai executar, quantos dias antes ou quantos dias depois. Este parametro tem 3 digitos numericos, e pode ser usado para "rolar" a execucao do Job quantos dias necessarios no caso de ROLL=F ou ROLL=B. O parametro tambem pode ser negativo ou positivo, ou seja, o Job pode executar antes ou depois do dia que for nao executavel, escolhendo + ou -.

DOTM (Due Out Time) - Este parametro e de extrema importancia para o Schedule pois o Scan do CA-7 se utiliza deste parametro para definir quando colocar o Job para executar.

LEADTM (Lead Time) - Parametro tambem muito importante, utilizado para o calculo do horario de execucao para o Scan do CA-7.

SUBTM (Submit Time) - Parametro utilizado como uma dependencia de tempo. O Job nao comeca execucao sem que este horario nao chegue, mesmo o Job ja estando na fila pronto para executar.

STARTTM ( Start Time) - Este parametro nao e configuravel na tela de DB.2.1, mas e o resultado de DOTM - LEADTM = STARTTM. Este o valor do Start Time pode ser igual ao Submit Time, mas se o Job estiver com o parametro PROMPT=Y, entao o Job vai alarmar atrasado (Shout Late), ou seja, o ideal e que exista alguma diferenca entre SUBTM e STARTTM. A diferenca entre estes dois valores seria o tempo que o Job tem para comecar a executar.

Exemplo: DOTM=2330 LEADTM=0020 SUBTM=2300. Neste caso o STARTTM vai ser 2310 ( que e 2330-0020=2310 ), entao o Job tem entre 2300 e 2310 para comecar a executar.

TYPE - Este parametro e usado para Jobs ciclicos, ou seja, Jobs que vao executar regularmente em um certo intervalo de tempo. Para isso, este parametro tem que estar TYPE=CLOCK.

INTERVAL - Este sera o parametro de intervalo de tempo no qual o Job vai executar. Por exemplo, se estiver definido INTERVAL=0015, o Job vai executar de 15 em 15 minutos.

REPEAT - Este parametro definine quantas vezes o Job vai executar, nos devidos intervalos, durante o dia. Por exemplo, se definir o SUBTM=0001 (meia noite e um), o INTERVAL=0100 (uma hora), e se quer que o Job execute o dia inteiro de hora em hora, entao o parametro tem que estar REPEAT=0023, que seria a primeira execucao as 0001 mais 23 repeticoes, ate as 2301 da noite. Este parametro tem a seguinte idéia de tempo:

INTERVAL=0001 - Executa a cada um minuto
INTERVAL=0010 - Executa a cada dez minutos
INTERVAL=0100 - Executa a cada hora
INTERVAL=1000 - Executa a cada 10 horas

Significa que os dois ultimos digitos sao para minutos e os dois primeiros sao para horas.

Quando definindo um Job ciclico, deve-se ter em mente que o ciclo vai parar se o Job terminar em erro. E neste caso o Job tem que ser forcado completo para que o cilco continue, pois se o Job for cancelado, o ciclo para e so continua no dia seguinte.

DAILY - Indica que o Job vai executar todos os dias executaveis do calendario base escolhido para ele.

WEEKLY - Define qual ou quais dias da semana o Job vai executar. Podem ser marcados quantos dias forem necessarios. PAra fazer isso e so colocar um X na frente dos dias ou do dia da semana que se deseja que o Job execute. Por exemplo, se quiser que um Job execute toda segunda feira, entao ficaria assim:

WEEKLY = x - SUN MON x TUE WED THU FRI SAT

*MONTHLY - Este parametro pode definir um job para executar mensalmente, semanalmente, etc. Devem ser definidos da seguinte maneira, quais meses o Job vai exeutar, qual semana e qual dia da semana, e se for necessario, qual dia do mes o job vai executar. Seguem alguns exemplos:

1 - Um job deve executar todas as quartas feiras da primeira e terceira semana do mes de janeiro, entao ficaria assim:

MONTHLY = x - JAN x FEB MAR APR MAY JUN JUL AGO SEP OCT NOV DEC
WEEK 1,3 - DOW wed

2 - Um Job deve executar todos os meses no segundo dia do mes, entao seria assim:

MONTHLY = x - Se deixar em branco os meses marcando somente o MONTHLY = x, o CA-7 entende automaticamente como todos os meses.

WEEK - DOW - Estes tambem nao precisam ser preenchidos, ja que o Job deve executar em um dia especifico do mes.

RDAY = 2 - Entao aqui esta definido o dia do mes que o Job deve executar.

Este parametro e chamado Relative Day, pois define o dia que o Job deve executar, seja o dia do mes tal como dia 10 ou 10o dia, por exemplo, se quiser definir um Job para executar no 10o dia util do mes, entao deve ser escolhido um calendario base so com dias uteis e que seja SCHONLY=Y e colocar RDAY=10 para que execute no 10o dia, e o ROLL=D para que nao execute feriados. Entao se quiser definir que o Job execute no dia 10 do mes, nao importando se util ou nao, entao deve-se usar RDAY=10, um calendario definido como SCHONLY=N, e o ROLL=N. O parametro pode ser negativo tambem, poiso como definir o ultimo dia de cada mes, se os meses podem ter 28, 29, 30 ou 31 dias? Entao usa-se 0 para ultimo dia, -1 para o penultimo e assim por diante.

ANNUAL = x - RDAY xxx - Parametro que define um Job que executa uma, ou algumas vezes ao ano somente.
Entao se define no campo RDAY usando Data Juliana, que e o dia do ano contado diretamente. Outra opcao possivel para Jobs anuais, seria definir o dia que ele NAO vai executar da seguinte maneira:

O Job A nao deve executar no dia juliano 132, por exemplo, entao define-se ANNUAL=x - RDAY=/132.
Esta barra / significa NON RUN DAY.

SYMETRIC - Usado para executar de tanto em tanto tempo. Por exemplo, quero que meu Job execute dia sim dia nao, entao coloca-se a data juliana no START que vai ser o dia vai comecar e coloca-se depois no SPAN coloca 02 para que execute de 2 em 2 dias.



DB.2.7 - Job Calendar

Esta opcao seria onde se ve o calendario criado quando se adiciona um Schedule em um Job. Nesta tela pode-se alterar e listar o calendario de um job. Esta tela so da a opcao de se trabalhar um SCHID de cada vez, ou seja, bem especifico.

Esta tela mostra um quadro para o Schedule de um job com zeros e uns, zero para os dias que o Job nao vai executar e um para os dias que o Job esta definido para executar.

Nesta tela pode so se fazer alteracoes temporarias, ou seja, se houver alteracao nesta tela, esta sera apagaqda caso haja um RESOLV do calendario base correspondente.

Para alguma atualizacao, deve-se utilizar a opcao UPD e trocar o 0 por 1, ou 1 por 0 e digitar ENTER. Entao a mudanca esta realizada e podera ser usada imediatamente.



DB.2.8 - Base Calendar

O Base Calendar, ou calendario base, seria o calendario que o Job vai usar como base para se Schedule. Um calendario base sera criado de acordo com as necessidades do cliente, mas existem os calentarios Default no CA-7, que sao os que permitem os Job executarem todos os dias (7A por exemplo), os que permitem que o Job execute de segunda a sabado (6A por exemplo) e os que permitem execucao de seginda a sexta (5A por exemplo).

O calendario sera montado com 0 e 1, onde 0 seria os dias que NAO serao possiveis de execucao e 1 os dias possiveis de execucao.

OBS: Modificar um calendario vai modificar a situacao de TODOS os Jobs que utilizam este calenadario, portanto deve ser feito com muito cuidado e certeza do que se esta fazendo.

Trabalhando Com Um Calendario

As opcoes que podem ser usadas no calendario sao:

LIST - Usados para listar um calendario. Digita-se LIST e o nome do calendario SCAL00xx (onde 00 seria o ano e xx seria o nome dado ao calendario em caracteres nao numericos.

ADD - Usado para adicionar um calendario novo.

UPD - Usado para Update, ou atualizacao do calendario.

DELETE - Usado para deletar um calendario.

SCHONLY - Este parametro vai ser usado para uma definicao muito importante no Schedule de um Job. As opcoes deste parametros sao Y ou N. Estas opcoes funcionam da seguinte mandeira, aceitam ou nao um job executar somente dias uteis ou nao. Uma maneira facil de entender seu usao seria fazendo a seguinte pergunta: "Este calendario permite que um job conte como executaveis somente os dias definidos no calendario base?" Dai a resposta seria Y ou N. Este parametro seria de extrema importancia para o Schedule de um job que necessita executar somente em dias uteis, porque neste caso, um calendario base que so tem dias uteis como executaveis, mas o parametro SCHONLY tem que estar como Y para funcionar.



DB.2.4 - JOB TRIGGERING

O Job Triggering funciona da seguinte maneira, um job sem Schedule vai ser colocado em execucao por outro Job. Exemplo, o Job A vai "triggar" o Job B, neste caso assim que o Job A terminar a execucao, ele adiciona o Job B para executar, o Job A tem que terminar sem erro para que o trigger funcione.

Na tela db.2.4 a primeira linha de comando seria OPTION e nesta linha de comando pode ser usadas as seguintes opcoes comuns:

1 - LIST - Comando usado para listar o Job e seus "triggers".

2 - UPD - Comando usado para atualizar os "triggers", adicionar e deletar "triggers".

Logo abaixo tem esta opcao:

JOBNAME - O espaco para colocar o nome do Job que vai triggar outros.

Logo abaixo tem as opcoes onde se adicionam os Job que vao ser "triggados".

Entao estas sao as opcoes desta parte:

CMD - Esta coluna de comando vai ser usada para comandos de Update pro job "triggado", neste caso digita-se a primeira letra do comando:

1 - A - Para adicionar "trigger"
2 - U - Para "Update" do "trigger"
3 - D - Para "deletar" o "trigger"

SCHID - Nesta coluna deve ser usado o Schedule ID. Por exemplo o Job A vai "triggar" o Job B, o Job A executa no SCHID 30, entao ele obrigatoriamente tem que "triggar" no SCHID 30. O que pode ser definido tambem, mas na coluna TRIGID, seria definir o Job B ser "triggado" no SCHID 30 e executar em outro SCHID.

TRIGGERED JOB - Nesta coluna se define o Job que vai ser "triggado", ou seja, usando os exemplos acima, este seria o espaco para colocar o Job B.

TRIGID - Nesta coluna pode-se definir o SCHID na qual o Job vai executar, mas este parametro nao seir obrigatorio, so vai ser usado quando necessario. Exemplo, o Job B esta sendo "triggado" no SCHID 30, mas gostaria que o Job B executasse no SCHID 31, entao se define isso no TRIGID.

QTM - Parametro usado como um tempo de espera para que o Job nao alerte como LATE. Por exemplo, se um job for definido com QTM=0030, este Job,depois de "triggado", tera 30 minutos para comecar sua execucao antes de alertar LATE. O CA-7 nao permite que se defina QTM e DOTM ao mesmo tempo em um Job "triggado".

DOTM-LEADTM-SUBTM - Parametros que podem ser definidos em um Job para que, mesmo sendo "triggado", ele ainda espere um determinado horario para comecar a execucao.



DB.2.6 - DATA SET TRIGGERING

Esta opcao de definicao do CA-7, permite que um Dataset ao ser catalogado no sistema (seja quando criado por outro Job ou catalogado apos ser transmitido de outra LPAR) "trigge" um Job.

OPTION - Campo utilizado para colocar comandos que serao usados na montagem ou listagem dos Jobs "triggered Jobs" de um Dataset. Estes sao os mais comuns:

1 - LIST - Comando usado para listar o Dataset e seus "triggers".

2 - UPD - Comando usado para atualizar, adicionar e Deletar os "triggered Jobs".

DATA SET - Campo onde se coloca o nome do Dataset

CMD - Esta coluna de comando vai ser usada para comandos de Update pro job "triggado", neste caso digita-se a primeira letra do comando:

1 - A - Para adicionar "trigger"
2 - U - Para "Update" do "trigger"
3 - D - Para "deletar" o "trigger"

SCHID - Para Dataset Triggering deve-se usar SEMPRE SCHID=00. Nesta coluna deve ser usado o Schedule ID. Por exemplo o Dataset A vai "triggar" o Job B, mas quer que o Job execute no SCHID = 030, isso pode ser definido tambem, mas na coluna TRIGID, seria definir o Job B ser "triggado" no SCHID 00 e executar em outro SCHID, neste caso o 30.

TRIGGERED JOB - Nesta coluna se define o Job que vai ser "triggado", ou seja, usando os exemplos acima, este seria o espaco para colocar o Job B.

TRIGID - Nesta coluna pode-se definir o SCHID na qual o Job vai executar, mas este parametro nao seir obrigatorio, so vai ser usado quando necessario. Exemplo, o Job B esta sendo "triggado" no SCHID 00, mas gostaria que o Job B executasse no SCHID 31, entao se define isso no TRIGID.

QTM - Parametro usado como um tempo de espera para que o Job nao alerte como LATE. Por exemplo, se um job for definido com QTM=0030, este Job,depois de "triggado", tera 30 minutos para comecar sua execucao antes de alertar LATE. O CA-7 nao permite que se defina QTM e DOTM ao mesmo tempo em um Job "triggado".

DOTM-LEADTM-SUBTM - Parametros que podem ser definidos em um Job para que, mesmo sendo "triggado", ele ainda espere um determinado horario para comecar a execucao.




DB.3 - JOB PREDECESSOR/SUCCESSOR

Como o titulo ja diz, este menu e responsavel por predecessores e sucessores.

EXECUTION REQUIREMENTS DEFINED BY:

1 - DATA SET PREDECESSORS
2 - CPU JOB PREDECESSORS OR MUTUALLY EXCLUSIVE JOBS (CAN NOT RUN AT SAME TIME)
4 - INPUT NETWORK PREDECESSORS OR OUTPUT NETWORK SUCCESSORS
6 - USER MEMO-FORM PREDECESSORS
7 - REPORT IDS CREATED


DB.3.1 - DATASET PREDECESSORS


Esta opcao serve para adicionar um Datset como dependencia de um Job. Ou seja, o Job vai esperar este Dataset ser catalogado antes de comecar a executar. Diferentemente do Dataset Triggering, nesta situacao o Job tem seu proprio Schedule, entao esta seria mais uma dependencia que precisa ser satisfeita antes de o Job executar.

Estes sao os parametros que podem ser preenchidos no campo OPTION.

1 - LIST - Comando usado para listar o Job e seus "Dataset Requirements".

2 - UPD - Comando usado para atualizar, adicionar e Deletar os "Dataset Requirements".

JOB - Campo onde se coloca o nome do Job.

Logo abaixo vao aparecer os outros campos para preenchimento, em forma de colunas:

CMD - Coluna usada para comandos para os predecessores ja adicionados ou para adicionar novos.

Estas sao as opcoes da coluna CMD:
1 - U - Comando para Update do Requirment
2 - A - Comando para adicionar um novo Requirement
3 - D - Comando paa deletar um Requirement

SCHD - Coluna onde se define para qual Schedule ID o Requirement sera adicionado, O Schedule ID tera que ser um valido, um que ja esteja definido no Job (DB.2,1).

LEADTM - Parametro que deve ser definido, em horas, quanto tempo o Job deve esperar pelo Dataset ou ate quantas horas o Job olha pra tras pra saber se o Dataset Requirement ja esta la.

DATASETNAME - Coluna onde se preenche com o nome do Dataset que vai ser o Requirerment.

DSNBR - Parametro que esta ligado ao nome do Dataset, foi criado quando o Dataset foi adicionado ao CA-7. Este parametro nao tem necessidade de ser preeenchido, pois o CA-7 faz isso automaticamente.

PERM - Define se o Dataset vai ser real ou nao para este Job. Um Dataset Requirement real, PERM=N significa que vai ser mesmo uma dependencia. Caso seja definido como PERM=Y entao vai ser uma falsa dependencia, ou seja,, o Job vai executar estando o Dataset la ou nao. Mas o Dataset pode ser adicionado no CA-7 como PERM ou NORM. Entao este campo so seria utilizado caso um mesmo Dataset deva ser dependecia real pra um Job e falsa pra outro Job.

Como foi dito acima, o parametro PERM tem duas opcoes: Y ou N.

NEXT RUN - Indica como esta dependencia deve ser tratada. Existem tres opcoes:

1 - YES - Indica que sera um requirement que esta permanentemente relacionado ao Job, e so sai de la se for retirado manualmente por alguem.

2 - SKIP - Indica que somente para a proxima execucao o Job nao tera a dependencia deste Dataset, ou seja, na proxima execucao do Job ele pula esta dependencia e executa sem olhar pra ela. Logo apos tudo volta ao normal. Mas se durante a execucao o Job tiver problemas e for cancelado esta condicao continua, pois o CA-7 so vai entender que funcionou caso o Job execute bem, ou seja, so muda de SKIP pra YES caso o Job termine bem.

3 - ONLY - Esta condicao indica que a dependencia so vai funcionar por uma execucao do Job, e que assim que terminar o Job, a dependencia sera apagada. E no mesmo caso de cima, esta condicao so termina se o Job terminar bem, pois se ele for cancelado ou ficar em erro, a dependencia continua la.



DB.3.2 - 2 - CPU JOB PREDECESSORS OR MUTUALLY EXCLUSIVE JOBS (CAN NOT RUN AT SAME TIME)


Esta Opcao do CA-7 serve para adicionar a um Job, um outro job como dependencia, o que significa que este job que tera esta dependencia tera seu proprio schedule, mas ao chegar seu dia e horario pra execucao, o requirement ( ou requirements no caso de mais de um ) tambem tem que ter executado, senao o Job vai ficar esperando por ele ou eles. Este recurso faz com que um Job espere por outro, seja qual for o motivo ou intensao de se criar este tipo de dependencia, as vezes porque um job vai gerar um arquivo que outro vai usar, ou para ter certeza que varios Jobs vao executar em uma ordem especifica, etc.

Estes sao os parametros que podem ser preenchidos no campo OPTION.

1 - LIST - Comando usado para listar o Job e seus "Dataset Requirements".

2 - UPD - Comando usado para atualizar, adicionar e Deletar os "Dataset Requirements".

JOB - Campo onde se coloca o nome do Job.

Logo abaixo vao aparecer os outros campos para preenchimento, em forma de colunas:

CMD - Coluna usada para comandos para os predecessores ja adicionados ou para adicionar novos.

Estas sao as opcoes da coluna CMD:
1 - U - Comando para Update do Requirment
2 - A - Comando para adicionar um novo Requirement
3 - D - Comando paa deletar um Requirement

SCHD - Coluna onde se define para qual Schedule ID o Requirement sera adicionado, O Schedule ID tera que ser um valido, um que ja esteja definido no Job (DB.2,1).

LEADTM - Parametro que deve ser definido, em horas, quanto tempo o Job deve esperar pelo Dataset ou ate quantas horas o Job olha pra tras pra saber se o Dataset Requirement ja esta la.

JOBNAME - Campo usado para colocar o nome do job que vai ser dependencia (predecessor) para o job principal. Este campo apresenta tres opcoes para se colocar junto do nome do Job:

1 - Jobname - Colocando simplesmente o nome do Job, funciona como uma dependencia normal.
2 - /Jobname - Esta barra antes do nome do Job indica uam dependencia negativa, ou seja, os jobs nao poderao executar ao mesmo tempo. Usado para que Jobs nao executem ao mesmo tempo no CA-7. Precisa ser colocado nos dois Jobs, tem que ser mutuo.
3 - ?Jobname - Requirement MAYBE. Indica que se o Job que vai ser dependencia nao tiver executado ainda, ou nao estiver na fila de execucao, o Job principal nao vai esperar por ele. O Job principal so espera pela dependencia se a dependencia estiver executando ou na fila de execucao.

NEXT RUN - Indica como esta dependencia deve ser tratada. Existem tres opcoes:

1 - YES - Indica que sera um requirement que esta permanentemente relacionado ao Job, e so sai de la se for retirado manualmente por alguem.

2 - SKIP - Indica que somente para a proxima execucao o Job nao tera a dependencia deste Dataset, ou seja, na proxima execucao do Job ele pula esta dependencia e executa sem olhar pra ela. Logo apos tudo volta ao normal. Mas se durante a execucao o Job tiver problemas e for cancelado esta condicao continua, pois o CA-7 so vai entender que funcionou caso o Job execute bem, ou seja, so muda de SKIP pra YES caso o Job termine bem.

3 - ONLY - Esta condicao indica que a dependencia so vai funcionar por uma execucao do Job, e que assim que terminar o Job, a dependencia sera apagada. E no mesmo caso de cima, esta condicao so termina se o Job terminar bem, pois se ele for cancelado ou ficar em erro, a dependencia continua la.


Dicas de Requirement

Um Job que está definido como Requirement para outro Job só poderá ser utilizado UMA VEZ como Requirement. Por exemplo, o JOBA precisa esperar um JOBB antes de executar, mas por alguma razão o JOBA executa novamente naquele dia, mas o JOBB executa só uma vez, e como o JOBB já foi utilizado como Requirement, a segunda execução do JOBA não vai poder utilizar novamente como Requirment o JOBB naquele dia. Somente a próxima execução do JOBB vai servir novamente como Requirement.


A Diferença entre NEGATIVE REQUIREMENT e EXCLUSIVE RESOURCE

Apesar de serem parecidos, existe sim uma diferença entre os dois.

O NEGATIVE REQUIREMENT é mais simples, somente feito para que um Job não execute ao mesmo tempo que outro, não importando inclusive a ordem de execução. Se um dos dois Jobs estiverem executando quando o outro for chamado para a READY QUEUE, este que foi chamado depois vai ficar esperando.

Já com relação ao EXCLUSIVE RESOURCE a situação é mais complexa, este recurso do CA-7 impede que dois Jobs se utilizem de recursos do sistema ao mesmo tempo, sejam eles quais forem, ou ainda que façam o SHARE dos recursos, mas sendo que um Job vai ter prioridade sobre outro. O RM ( Resource Manager ) ainda dá como opção o gerenciamento de recursos, ou seja, definind que um Job só execute caso um certo recurso esteja disponivel no sistema, este correquisito nao depende de qual outro Job está utilizando o recurso ou não, ele só exige que o recurso estará ou não disponivel no sistema. Mas isso será discutido no tópico de gerenciamento de recursos (RM).




DB.4 - WORKLOAD DOCUMENTATION

Esta opcao e usada para documentacao.

DOCUMENTATION FOR:

1 - CPU JOB
2 - INPUT/OUTPUT NETWORK
3 - USER-DEFINED ITEM
4 - DATA SET
5 - DD STATEMENT
6 - APPLICATION SYSTEM




DB.5 - INPUT/OUTPUT NETWORK

Esta opcao nao tem um submenu. E usada para parametros de rede.




DB.6 - DATA SET

Esta opcao nao tem sub-menu, e e usada para Datasets.

As opcoes principais sao:

ADD,DELETE,FORMAT,LIST,RENAME,UPD

Pode ser usado para cadastrar, atualizar, ou remover um Dataset, estas são as opções mais usadas.

Os Campos sao os seguintes:

DSNAME - Campo onde se coloca o nome do Dataset




ARFSET - Opcao AR.3

O ARSET e usado para colocar alguma condicao a um Job podendo envolver outros Jobs, Steps de um Job, um Job e a console, etc.


Tipos de ARFSET - Definicoes de Manual


ARF uses the following tests to monitor exception conditions:

EC - Test of elapsed time at job completion
EE - Test for excessive elapsed time during job execution
IS - Test date and time at job submission
JC - Test job completion
LA - Respond when CA-7 issues initial late prompt for job
LB - Determine if job is late when job begins execution
LE - Determine if job is late when job ends execution
LS - Determine if job is late when job is submitted
SC - Test step completion


O que O ARFSET Pode Fazer


Issue a message to a TSO user
Issue a message to the console on the CA-7 host
Wait a specified number of minutes before proceeding to
the next response
Submit special recovery jobs
Track the progress of these recovery jobs and retry them
if not successful
Wait a specified number of minutes between retries of the
recovery jobs
Skip certain responses if the recovery job does not
complete successfully
Issue CA-7 and operating system commands

Que Jobs Podem Ser Monitorados Pelo ARF

ARF begins monitoring jobs when they enter the request queue. ARF can monitor a job ONLY while it is in one of the following queues: request, ready, or active.
When a job enters the request queue, CA-7 tries to determine whether or not the job is to be monitored by ARF. By default, no job will be monitored by ARF.
In order to be monitored by ARF, a job must have an ARFSET associated with it.


O Que Exatamente e Um ARFSET?


ARF monitoring of exception conditions is controlled through
ARF condition definitions. A set of such definitions is known as
an ARFSET. ARF will monitor all the exception conditions for the
job that are indicated by the condition definitions in the ARFSET
associated with the job (if any). If no ARFSET is associated with
the job, ARF will not monitor it.

EXEMPLO:

LA - Late ARFSET

DEFINICAO DE LA

LA - Late Notification at CA-7 Prompting
An ARF exception is recognized when CA-7 begins late prompting for the job. The exception occurs only once for the job when it is initially considered late by CA-7.
Also, the exception is only taken if the job becomes late while in the request queue, not when it enters the request queue as late. The prompt must actually be done. For example, if the JOB screen uses PROMPTS of N, the exception does not occur even though the job may show with a late status.

Este tipo de ARFSET e usado para quando um Job esta Late no CA7. O que pode ser feito? Uma mensagem pode ser enviada para console, pode-se liberar um outro Job, etc.

Por exemplo, caso seja uma mensagem para a console, quando criando o ARF deve-se optar por AM

DEFINICAO DE AM

AM - Issue a Message. The AM action statement can be used to issue messages to the MVS console or to a specified TSO user.

Se a Mensagem vai ser HIGHLITED ou nao, deve se usar H

DEFINICAO DE H

H Send the messages to the MVS console and highlight them.

Em seguida deve-se definir a mensagem em si, e o texto deve vir depois de M=

DEFINICAO DE M

M= The data following the M= specifies the text of a message that is to be issued. If the text contains
commas or keywords (x=y), enclose the entire text string in parentheses. The maximum length is 60 characters




CA-7 SCAN

O CA-7 se utiliza do SCAN para trazer,de tempos em tempos, os Jobs da sua Job Lib para a execucao.

Cada CA-7 tem sua propria configuracao de intervalo para o SCAN, que pode ocorrer, de hora em hora, de duas em duas horas, de quatro em quatro horas, ou sejam, o dono do sistema escolhe a melhor definicao de SCAN para seus Jobs.

Veja este exemplo:

SPAN = 240 INCREMENT = 120

DWELL = 0030

NEXT SCAN WAKE-UP = 09232 AT 1402

NEXT SCAN PERIOD START TIME = 09232 AT 1602

No exemplo acima, vemos os parametros que definem o SCAN para o sistema. Vamos explicar todos eles.

SPAN - Este parametro define quais Jobs o SCAN vai trazer para o CA-7 no proximo periodo (neste caso nas proximas 4 horas) todos os Jobs que deveriam executar neste periodo. Por exemplo, neste caso, o proximo periodo seria 16:02 que neste caso, levando em conta o SPAN, vai enxergar os Jobs que devem executar entre 14:02 e 18:02.

SCAN PERIOD START TIME - O SCAN seria o CA-7 efetivamente trazendo os Jobs para a fila de
execucao. Neste caso o SCAN acontece de 2 horas em 2 horas, porque porque o horario definido esta 1402 para a proxima "acordada" do SCAN. Esta "acordada" vai trazer para a fila de execucao os Jobs que ja foram pegos no ultimo SCAN.

SCAN WAKE UP- Este parametro indica quando o SPAN deve passar novamente para que outros Jobs sejam adicionados a fila. Isto indica que, neste caso, o Job vai pegar as proximas 4 horas de Job pela frente.

DWELL - Parametro usado para definicao do horario de excucao do Job. Este parametro tem muita importancia na definicao de qual SCAN vai pegar este Job para traze-lo pra fila.

O parametro DWELL ajuda a calcular o horario para referencia do SCAN. Veremos no exemplo a
seguir.

Definindo o horario para o Job ser escaneado.

Vamos imaginar o Job A.

Este Job tem DOTM=1630, LEADTM=0030 e SUBTM=1600, e o DWELL=0030 definido no SCAN.

Qual horario o SCAN reconhece para este Job? DOTM? SUBTM? STARTM?

Eis a conta que o SCAN vai assumir:

DOTM - (LEADTM + DWELL) = SCAN REFERENCE TIME

Ou seja:

1630 - ( 0100 ) = 1530

Entao 1530 vai ser a referencia para o SCAN. Finalizando, se o SCAN passar as 1130 entao ele vai enxergar o Job, ja se o SCAN passar as 1100 nao vai ver o Job, que so vai ser pego na proxima passada do SCAN.

Se o Job pode vir pra fila 4 horas antes do horario definido, porque ele nao entra pra executar
antes?

Neste caso entra o SUBTM, que funciona como uma dependencia de tempo para o Job.

Se o Job foi trazido pra fila as 1130 porque ele nao executa?

Porque ele tem o SUBTM de 1600 entao ele fica na fila ate as 1600.




CA-7 Reprots

GRAPHS

O CA-7 tem uma ferramenta para Reports, esta é o GRAPH. Esta ferramenta possibilita que se tirem reports de informações do CA-7, tais como numeros de Jobs Queues, numeros de Database como add jobs, etc. Estas informações são retiradas em Reports do Ca-7 definindo-se quais informações se deseja, e de aual periodo serão estas informações.


System Graphs

Report de performance do Ca-7

Esta opção Reporte de Sistema tem alvo as informações dos Ca-7 tais como número de Logons, número de Security Violation,

GRAPHS,ID=XX,FROM=MMDDYY,TO=MMDDYY

Este é o comando que gera o Report. Explicando melhor, o comando precisa de um ID que indicará qual a informação alvo do report ( Logon, Violation, etc ), e também do periodo no qual se quer as infomações no formato mes - dia - ano.

Segue abaixo a lista de ID's e o Report alvo de cada um.

0010 - CA-7 ACTIVE TIME IN MINUTES - Tempo que o Ca-7 está ativo no sistema ou complexo ou LPar.

0020 - CA-7 UP TIME VS. OS WAIT TIME IN SECONDS - Compara o tempo em que o Ca-7 ficou em espera com o tempo que está ativo.

0030 - TOTAL OS WAIT TIME IN MINUTES - Tempo que o CA-7 ficou em espera (WAIT).

0040 - NUMBER OF WRITES TO STATISTICS FILE - Numeros de Write's no dataset UCC7STAT.

0050 - COMM. TASK WAIT TIME IN MINUTES - Reflete o tempo agregado que a Task de comunicação ficou sem fazer nada ou esperando por processamento no Dataset de Comunicação.

0060 - CA-7 UP TIME VS. COMM. TASK ACTIVE TIME IN SECONDS - Compara o tempo em que o Ca-7 está ativo com o tempo citado acima no ID 50.

0070 - NUMBER OF LOGONS - Mostra o número de Logons com sucesso usando o comando /LOGON.

0080 - SECURITY VIOLATIONS** - Numero de tentativas com Security Violations.




CA-7 Listando Queues (filas)


Todo Job que está indo executar no CA-7 necessita passar por tres filas, que são:

Request Queue – Esperando iniciar execução ou até que todos os requerimento sejam satisfeitos( assim como recursos, dependencias de outros Jobs ou arquivos );

Ready Queue – fila de execução, pode também estar esperando por recurso ou tempo;

Active Queue - Job executando;

XQJ - Jobs na Request Queue podem ser controlados usando uma tela formatada. Esta tela é acessada entrando o comando 'XQJ'.

XQM – Uma combinação de LQ,LIST=RQMT e XQJ, mostra o estado do Job, usado especiamente para verificar e fazer um POST(liberação) de requerimentos;


Tipos de requerimentos - Verificando


Digitando XQM,JOB=xxxx (xxxx=numero do Job) CA-7 mostra o que e qual tipo de dependencia que o Job tem.Na sequencia, o CA-7 mostra:

.J – Jobs
.I – Requerimento interno
.E – Requerimento externo
.U – User
.N – Dependencia de network
.S – Dependencia de tempo
.H - Hold
.J – Verificação de JCL
.V – Verificação de requerimento

XQN – Mostra o estado do Job, incluindo Jobs com estado Skeleton ou erro de referencia de JCL, o que XQM ou XQJ não mostrariam;

XWLB – Workload Balancing baseado em objetivos de Users. Limitando quantos Jobs podem executar durante um periodo especifico;




Algumas Diferenças no CA7


RUN, DEMAND e EXTL


Run – O Job é executado via pedido de usuário não tem relação com dependencias com outros Jobs.

Demand – O Job é executado via pedido de usuário e mantém as dependencias que os jobs tem originalmente (DEMAND,JOB=xxxx,SCHID=xx) - Onde SCHID é a definição de calendário que o job vai rodar, informação passada pelo suporte.

EXTL – O Job é submetido externalmente e vai ser 'trackeado' pelo CA-7.

NOTA - Existem Jobs que tem Demand interno, significa que em um Step específico tem um programa utilitário do CA-7 usado para enviar comandos para submeter outro Job.


CANCEL x FORCE COMPLETE


Cancelando um Job no CA/7 não vai permitir este de 'trigar' outros Jobs or satisfazer outros sucessores.

Forçando um Job completo no CA/7 vai permitir tudo o que é negado cancelando o mesmo.

Da linha de comando do CA-7 digitar XQ or XQ,JOB=jobname
Coloque o cursor no JOBNAME e digite F na frente do Job.
A seguinte tela vai aparecer:

REASON:

//— — RESUBMIT FOR PRODUCTION //

— — FORCE COMPLETE

— — CA-11 RESTART/RERUN PSEUDO:

Entao deve-se colocar um X na opcao desejada, que pode ser Restart, Force Complete ou CA11 Restart.



Salvando Alterações de um JCL


Para atualizar o JCL do job (editar), para adicionar um cartao de restart por exemplo usar 'SR' na primeira linha da primeira coluna, dai entao rodar o Job normalmente, sem usar o ca11.

Estados de Jobs já Submetidos

SSCN – o Job tem um calendário e foi submetido via SSCAN;

DEMD – requisitado por user;

AUTO – 'trigado' por outro Job;

RUN – executado via 'run';



Estados de Job Indicando Problemas:


JCLERR – Job 'abendado' com erro de JCL;

COND-CD – Job 'abendado' por Condition Code Check;

#STEPCC – Job 'abendado' com um Cond Code irreconhecído definido pelos parametros de #SCC no JCL;

NOUID – Job não tem um User-ID válido para submissão;

REQUE – Job foi Re-Queued (reenfileirado) para Restart;

LATE – Job não inicializou no tempo devido a problemas com predecessores, arquivos or outros recursos não disponíveis.



Alterar o SUBMIT TIME de um JOB


1. Digitar o comando XQJ,JOB=jobname
2. Na tela que se segue, em frente ao job, digitar 'U', de Update;
3.na proxima aparecem horarios de SUBMIT TIME, DEADLINE TIME e DUE-OUT TIME.
4. O SUBMIT TIME devera ser alterado, conforme o solicitado pelo suporte;
5. O DEADLINE TIME, sera o mesmo do SUBMIT;
6. O DUE-OUT sera um valor maior que os dois anteriores, a criterio do suporte (esse horario e o limite para a submissao do Job, e apos este horario ele vai ter o flag de late); a sugestao e que se confirme com o suporte qual sera esse horario.

SKELETON STATUS


O CA-7 usa uma série de filas ( disk data sets ) para mover um Job através de seu ciclo de produção e claro também para um histórico Online poder acontecer e um report ser guardado na log ( que pode ser default de instalação ou customizada ).
Quando um usuário requisita um Job a ser processado ou o database automaticamente determina que o Job está pronto para ser processado ( Schedule Scan ), então..uma record é escrita na Request Queue ( LREQ )

Dica 1:- o Schedule Scan segue o mesmo processo de wake up/sleep do control-m, acorda e schedula o proximo ciclo de Jobs, seguindo um horáio determinado pelo scheduler, com o top line command SSCAN, podemos saber qual é o intervalo que este scan acorda )

Na Request Queue é onde vão ser gravados, exatamente neste momento, os requerimentos para o Job. Agora também uma cópia do JCL é tirada da livraria de onde o Job deve rodar e essa cópia do JCL é escrita na Trailer Queue.

Dica 2: - é por isso que jobs em skeleton status só podem ser identificados com o comando LREQ, ST=LATE,SEQ=JOB, porque vai ser quando o Job estiver na Request queue que ele vai entrar ou não nesse status … e também obviamente por isso não o encontramos na QM.4-X screen, porque esta é a maintenance screen, o Job ainda não passou por todos os ciclos para chegar nela )

Dica 3:- para saber de qual livraria um Job roda entre na tela de : DATA BASE DEFINITION FOR CPU JOB, para ter acesso a essa tela você pode tanto digitar na linha de comando: DB.1 ou JOB
Fazendo uso da função LIST - na segunda linha chamada JCL a primeira FIELD a seguir será ID: - este ID: será identificado por um número, com este número em mente vamos digitar o comando: /DISPLAY,ST=JCL, dentro desta tela aparecerão todas as livrarias que estão disponíveis e seus respectivos ID numbers.
Há ainda o comando /DISPLAY,ST=JCLVAR que mostra qual é o tipo de arquivo.

Resumindo, o CA-7 não olha para trás em nenhum momento, ele submete o Job por SSCAN quando ele tiver que ser submetido, mas vamos supor que isso aconteça 2:30h antes do horário que ele está determinado a rodar, quando o SSCAN passar se o analista tiver movido o JCL de lugar, nesse caso vamos certamente receber um SKELETON status. Ainda que se conseguisse dar Requeue num Job que está em Skeleton, ele não vai voltar a capturar um novo JCL para escrever na Trailer queue, portanto somente cancelando o Job e demandando de volta é que podemos fazê-lo rodar.

Uma questão de autoridade é possível. Existem três diferentes tipos de acesso:
- Acesso de Login ( este acesso nao influi )
- Acesso as livrarias de onde vai se executar Jobs (este acesso pode influir)
- Acesso a dar diferentes tipos de comando ( este acesso pode influir )

E também o Job deve ter acesso a rodar daquela livraria

Logo, a não ser que seja um Job novo ( no caso o Job nao tem acesso para rodar) ou um analista novo ( de repente um operador novo que ainda nao recebeu acesso de comandos ou acesso as livrarias quando for executar um Demand ele não consegue chegar ao JCL por isso o Skeleton pode acontecer) não devemos ter problema de autoridade na questão de Skeleton.

Existe ainda a possibilidade do CA-7 estar apontando para a livraria errada, isso também resulta em Skeleton.

Dica 4: - Para que isso não aconteça… toda vez que conversarmos com um analista sobre um Job em SKELETON vamos esclarecer a ele que: todo Job que terá seu JCL movido antes de rodar, deve ser colocado em HOLD na DB.1 com opção de HOLD= YES e EXEC=NO, desta forma esse Job não vai aparecer na fila.

Quando todos os requerimentos tiverem sido satisfeitos o Job então é movido para a READY queue.

Dica 5: - um Job sempre deve aparecer por poucos segundos na READY queue a não ser que:
Há três possibilidades aqui:

A primeira: o Job está esperando por uma VIRTUAL RESOURCE, requerimentos 'virtuais' definidos para cada Job que não fazem parte dos que podemos ver na tela XQM, são Special Resources na verdade, definidas pelo analista na tela de Virtual Resource Management - que pode ser acessada pelo comando de linha "RM" VRM é uma facilidade do CA-7 e tem 5 diferente tipos, que são: EXCLUSIVE, ADDRESS SPACE, SHARED, RESOURCE COUNT and CO-REQUISITE

Lembrando também que cada virtual resource dentro de seu tipo, tem ainda um sub-tipo: Quando esta resource vai ser liberada para outros jobs usarem… isso está definido na opção de FREE= *
Para que uma resource possa ser liberada para uso de outro Job, o primeiro obrigatoriamente deve ter a opção FREE setada para "F"

A segunda: Todo Scheduler tem a possibilidade de restringir a submissão de Jobs no CA-7 por classes, isso é chamado de CLASS BARRIERS
O CA-7 suporta até 36 diferentes classes de Jobs [ de A - Z e de 0 - 9 ]
Os jobs são assignados para determinada classe dentro da DB.1 tanto quando da inclusão do Job no Database, quanto por meio da opção UPD na própria DB.1 em CLASS FIELD

Como o CA-7 sabe o que foi submetido, ele não vai submeter mais Jobs para uma determinada classe se já estivermos no limite.

Isso também serve para checar Jobs demais na fila de late, eles podem estar esperando por classes do CA-7!!!

Ambos 'status' "WAITING FOR VRM RESOURCES…" ou "CLASS BARRIERS REACHED"
podem ser encontrados pelo comando " LRDYP,LIST=STATUS "

A terceira possibilidade é: a Utility que faz a comunicação entre CA-7 e JES2 pode não estar funcionando.

Outros sistemas, não usam CA7NCF e sim CA7ICOM.

Se não houver nenhum problema, segundos depois de passar pela READY Queue, o Job será movido pra ACTIVE Queue

Se o Job completar normal, uma Record vai temporariamente de volta para a Request Queue e vai neste momento completar o processo: 'trigar' outros jobs, satisfazer requerimentos, etc.

Quando esse processo tiver terminado, uma Record vai ser também escrita na PRIOR RUN Queue. Esta record não sai mais do CA-7 enquanto o Job não rodar mais uma vez e outra Record for sobre posta a essa. Por isso muitas vezes encontramos um Job na LPRRN mas não encontramos na LRLOG.

Uma Record é escrita na LRLOG com tudo que foi feito com aquele Job. Se ele completou, se foi postado requerimento manual, se foi dado force complete etc… Porém essa log por default ou customização fica available por alguns dias apenas, enquanto a Prior Run vai ficar lá sempre, ou até que o job rode novamente e reescreva sua record nesta fila.


Comandos Para Verificar as Filas de CA-7

O parametro a ser comparado é o Tracks em relação ao AVAILABLE, e o Available tem que estar maior que que o Tracks. Mas um número muito baixo de Available pode causar problemas.

/DISPLAY,Q=TRL - Verifica a Trailer Queue, que é a maior causa de problema de Skeleton. Se o numeor de Available estiver baixo, bem abaixo do de Tracks enão este deve ser o problema. Então o time de operação deve acionar o time de MVS e avisá-los sobre isto.

Veja o exemplo abaixo, o número de Availables é 4 e o númeor em uso é 150, então precisa ser limpo.

/DISPLAY,Q=TRL

QUEUE DISPLAY (3390)
QUEUE TRACKS AVAIL. INDEX ENTRIES AVAIL..

TRL … . 000150 000004 A

/DISPLAY,Q=RDY - Verifica a Ready Queue.

/DISPLAY,Q=REQ - Verifica a Request Queue.

/DISPLAY,Q=ACT - Verifica a Active Queue.




#SCC Cards

Estes cartões #SCC tem uma função muito importante, a de definir várias condições de ABEND para vários STEPS diferentes.
Já usando o CA-7, só é possível adicionar uma condição que vai ser usada por todo o Job.

As opções usadas nos cartões #SCC são de exclusão, ou seja, definindo uma condicao em um STEP, quer dizer que todos os outros STEPS vão aceitar esta condição menos o STEP que esta com ela definida.
Veja exemplos abaixo:

Exemplo 1

#SCC,COND=(2,LT,*-JS01)
#SCC,COND=(2,LT,*-JS001A)
#SCC,COND=(2,LT,*-JS002)
#SCC,COND=(2,LT,*-JS002A)

O *- significa todos os STEPS menos este. Ou seja, com esta é uma opção de exclusão.

Usando este exemplo, os STEPS JS01, JS001A, JS002, JS002A, vão ser excluidos das condições. Ou seja, todos os outros STEPS do Job vão ter como condição 2,LT, e estes acima serão os únicos que não vão aceitar esta condição.

Exemplo 2

#SCC,COND=(16,LT,STEP0030)

Neste exemplo, STEP testado vai ser somente o STEP0030, e funciona exatamente o contrario do que esta na DB.1 do CA-7. Caso o STEP0030 tenha COND CODE de 16, LT daí entao ele ABENDA.

Exemplo 3

#SCC,COND=(0,LT,*-STEP5)
#SCC,COND=(0,LT,*-STEP10)

Este exemplo é bem parecido com o primeiro, O Job inteiro vai ter o 0,LT como parametro de checagem para COND CODE, menos os STEPS STEP5 e STEP10.




MENSAGENS DO CA-7

O Ca-7 Pode emitir algumas menasgens em alguns casos especificos. Podendo indicando várias coisas, Skeleton, Autoridade Insuficiente, Numero de logon maximo atingido, etc. Veja abaixo algumas delas.


Mensagens de JCL Skeleton

Quando a situação Skeleton ocorrer, o Job vai entrar no CA-7 para execução sem JCL, ou seja, ele nao vai executar e vai mostrar no topo da tela a mensagem UNABLE TO ATTACH JCL, seguido de uma "Flower Box" com a mensagem do motivo do Skeleton, e mais JOB IS IN REQUEST QUEUE IN 'SKELETON' STATUS, indicando que o Job foi para a REQ QUEUE sem JCL.

A seguir alguns exemplos das mensagens.

Trailer Queue Full - A TRAILER QUEUE é a fila onde o CA-7 guarda o JCL de cada Job nas filas. Se esta fila encher, entao nenhum job pode ser "schedulado", pois o CA-7 nao tem como colocar o JCL deste novo Job em nenhuma fila. Geralmente limpando a REQUEST QUEUE resolve o problema.
Utilizando o comando /DISPLAY,Q=ALL, vão ser mostradas as filas do CA-7, entao pode-se decidir qual limpar.

DATA SET IS USER ID PROTECTED - Este caso é, em geral, a JCL LIB nao dá autoridade ao CA-7 para puxar o JCL do Job. Será necessário contactar o time de security para resolver isso. O dono do Job e da JCL Lib é quem deve faze-lo.

DATA SET JCLID/JCLLIB IS NOT DEFINED TO CA-7 - Mensagem que aparece quando se usa uma ALIAS de Lib que não está definido no CA-7, ou seja, ainda oa foi criado.

SPO7-13 UNABLE TO ATTACH JCL (001C)
JCL MEMBER NAME NOT FOUND IN PDS

Mensagens que indicam que o JCL não está no Dataset de JCL apontado no CA-7.


Mensagens Diversas

CA-7.X011 SESSION USER LIMIT REACHED, TRY AGAIN LATER

Mensagem que indica que o máximo de usuários logados no CA-7 já foi atingido. Esta configuração é feita pelo time de MVS, e não por comando. De dentro do CA-7 não há tambem como ver qual o limite definido, pois é definido nos arquivos de instalaçao do CA-7.

CA-7.306 - ** WARNING ** 80% SCRATCH QUEUE UTILIZATION WARNING

Mensagem que indica que uma das filas está cheia. A porcentagem na qual a mensagem aparece é definida na instalação do CA-7. O time de MVS deverá ser contactado.

JCL HAS CHANGED, MUST HAVE 'F' IN CA-11

Mensagem que indica que o JCL teve alguma mudança, entao um comando de LOAD pode ser necessário.




Unless otherwise stated, the content of this page is licensed under Creative Commons Attribution-ShareAlike 3.0 License