Guia do Usuário -...

IBM Tivoli Workload Scheduler para Aplicativos

Guia do Usuário

Versão 8.2

S517-7785-00

��

Nota

Antes de utilizar estas informações e o produto a que elas se referem, consulte as informações em “Avisos” na página 195.

Primeira Edição (Junho de 2003)

Esta edição se aplica à versão 8, release 2 do IBM Tivoli Workload Scheduler para Aplicativos (número do programa

5698-WSE) e a todos os releases e modificações subseqüentes até que seja indicado o contrário em novas edições.

© Copyright International Business Machines Corporation 2000, 2003. Todos os direitos reservados.

Índice

Prefácio . . . . . . . . . . . . . . vii

Quem Deve Ler este Manual . . . . . . . . vii

O que este Manual Contém . . . . . . . . . vii

Publicações . . . . . . . . . . . . . . ix

Publicações do IBM Tivoli Workload Scheduler . . x

Publicações do IBM Tivoli Workload Scheduler

para z/OS . . . . . . . . . . . . . . x

Kit de Coleção de Cópia Eletrônica para o IBM

Tivoli Workload Scheduler para z/OS . . . . . xi

Publicações listadas . . . . . . . . . . xii

Acessando Publicações On-line . . . . . . . xii

Solicitando Publicações . . . . . . . . . xii

Fornecendo Feedback sobre as Publicações . . . xii

Acessibilidade . . . . . . . . . . . . . xiii

Entrando em Contato com o IBM Software Support xiii

Convenções Utilizadas neste Manual . . . . . xiii

Convenções de Tipo de Caractere . . . . . . xiii

Variáveis e Caminhos que Dependem do

Sistema Operacional . . . . . . . . . . xiv

Parte 1. Tarefas Comuns de

Instalação e Configuração . . . . . . 1

Capítulo 1. Visão Geral do Produto . . . 3

Capítulo 2. Instalando o IBM Tivoli

Workload Scheduler para Aplicativos . . 5

Como Instalar . . . . . . . . . . . . . . 6

Utilizando o Assistente de Instalação . . . . . 7

Utilizando a Instalação Silenciosa . . . . . . 17

Utilizando o Tivoli Configuration Manager . . . 20

Desinstalando o Produto . . . . . . . . . . 23

Removendo uma Instalação por meio do ISMP 24

Removendo uma Instalação por meio do Tivoli

Configuration Manager . . . . . . . . . 24

Completando a Remoção do Método de Acesso

para Oracle e-Business Suite . . . . . . . . 24

Capítulo 3. Definindo Opções com o

Editor de Opções . . . . . . . . . . 27

Criando um Arquivo de Opções Locais . . . . . 29

Herança de Valor da Opção . . . . . . . . . 30

Capítulo 4. Definindo as Estações de

Trabalho de Agente Estendido . . . . 31

Criando uma Estação de Trabalho com o Job

Scheduling Console . . . . . . . . . . . . 31

Criando uma Estação de Trabalho da Linha de

Comando . . . . . . . . . . . . . . . 33

Definindo Estações de Trabalho para Planejamento

Ponto a Ponto . . . . . . . . . . . . . 34

Criando a Instrução CPUREC . . . . . . . 34

Definindo a Estação de Trabalho com ISPF . . . 35

Capítulo 5. Definindo os Jobs de

Agente Estendido . . . . . . . . . . 37

Definindo Jobs com o Job Scheduling Console . . . 37

Definindo Jobs com a Linha de Comandos do Tivoli

Workload Scheduler . . . . . . . . . . . 40

Definindo Jobs para Planejamento Ponto a Ponto . . 41

Parte 2. Método de Acesso do

Oracle e-Business Suite . . . . . . 43

Capítulo 6. Introdução . . . . . . . . 45

Recursos . . . . . . . . . . . . . . . 45

Requisitos de Software . . . . . . . . . . 45

Tarefas de Pós-instalação . . . . . . . . . . 45

Interface Software . . . . . . . . . . . . 47

Capítulo 7. Informações de Definição

do Job . . . . . . . . . . . . . . . 49

Definindo Jobs no Oracle Applications . . . . . 49

Executando um Único Job Simultaneamente . . 49

Definindo Jobs do Oracle Applications no Tivoli


Parâmetros da Cadeia de Tarefas para Jobs do

Oracle Applications . . . . . . . . . . . 49

Estados do Job do Tivoli Workload Scheduler e do

Oracle Applications . . . . . . . . . . . . 51

Capítulo 8. Referência do Arquivo de

Opções MCMAGENT . . . . . . . . . 53

O Arquivo de Opções . . . . . . . . . . . 53

Sintaxe de Entrada . . . . . . . . . . . 53

Exemplo . . . . . . . . . . . . . . 54

Criptografando as Senhas de Usuários do Oracle

Applications . . . . . . . . . . . . . 54


PeopleSoft . . . . . . . . . . . . 55

Capítulo 9. Introdução . . . . . . . . 57

Recursos . . . . . . . . . . . . . . . 57

Visão Geral Funcional . . . . . . . . . . . 57

Jobs do Programador de Processo do PeopleSoft . . 57

Rastreamento de Job do PeopleSoft no Tivoli

Workload Scheduler . . . . . . . . . . 58

Segurança . . . . . . . . . . . . . . . 58

Notas sobre o Suporte ao PeopleSoft versão 8.x . . 58

Capítulo 10. Planejamento de

Implementação . . . . . . . . . . . 61

PeopleSoft Versão 7.5 ou Anterior . . . . . . . 61

Requisitos do Host . . . . . . . . . . . 61

Requisitos de Software . . . . . . . . . 61

© Copyright IBM Corp. 2000, 2003 iii

Instalação para Usuário do Windows . . . . . 61

Verificando o Ambiente PeopleSoft . . . . . 62

Criando um ID de Processamento de Batch no

PeopleSoft . . . . . . . . . . . . . . 62

Arquivos Instalados . . . . . . . . . . 62

PeopleSoft Versão 8.x . . . . . . . . . . . 62

Requisitos do Host . . . . . . . . . . . 62

Requisitos de Software . . . . . . . . . 63

Criando um ID de Processamento de Batch no

PeopleSoft . . . . . . . . . . . . . . 63

Arquivos Instalados . . . . . . . . . . 63

Capítulo 11. Tarefas de Pós-Instalação 65

Configuração do Usuário para Windows . . . . 65

Criando o Arquivo de Opções . . . . . . . . 65

Editando Manualmente os Arquivos de Opções 68

Conectando Mais de um Banco de Dados do

PeopleSoft . . . . . . . . . . . . . . 69

Configurando o Ambiente PeopleSoft para a Versão

7.5 ou Anterior . . . . . . . . . . . . . 69

Personalizando o Servidor de Processo . . . . 69

Configurando o Cliente . . . . . . . . . 71

Executando o Script do Data Mover . . . . . 73

Configurando o Ambiente PeopleSoft para Versão

8.1x . . . . . . . . . . . . . . . . . 74

Personalizando o Servidor de Aplicativos . . . 74

Configurando o Cliente . . . . . . . . . 75

Configurando o Ambiente PeopleSoft para a Versão

8.4x . . . . . . . . . . . . . . . . . 75

Capítulo 12. Definindo os Jobs do

PeopleSoft . . . . . . . . . . . . . 77

Criando Definições de Job do Peoplesoft no Tivoli


Parâmetros de Cadeia de Tarefas para Jobs do

PeopleSoft . . . . . . . . . . . . . . 77

Configurando o Opens Dependencies 7.x Apenas . . 78

Exemplo de Dependências Abertas . . . . . 79

IBM Tivoli Workload Scheduler e o Mapeamento de

Status do Job do PeopleSoft . . . . . . . . . 80

Parte 4. Método de Acesso do R/3 83

Capítulo 13. Introdução . . . . . . . 85

Recursos . . . . . . . . . . . . . . . 85

Planejando o Processo para o Agente Estendido do

R/3 . . . . . . . . . . . . . . . . . 85

Suporte à Interface do XBP 2.0 . . . . . . . . 86

Capítulo 14. Instalação . . . . . . . . 87


Visão Geral da Instalação . . . . . . . . . 87

Instalando em Plataformas de Nível 2 . . . . . 88

Criptografando Senhas de Usuário do R/3 . . . . 89

Capítulo 15. Configuração do R/3 . . . 91

Visão Geral . . . . . . . . . . . . . . 91

Criando um Usuário RFC do IBM Tivoli Workload

Scheduler . . . . . . . . . . . . . . . 91

Criando o Perfil de Autorização para o Usuário do

Tivoli Workload Scheduler . . . . . . . . . 91

Utilizando a Transação SU02 e Criando

Manualmente o Perfil . . . . . . . . . . 91

Utilizando a Transação PFCG (Gerador de Perfil) 92

Copiar os Arquivos de Correção e de Transporte . . 94

Importar Módulos ABAP/4 para R/3 . . . . . . 94

Instalando os Módulos ABAP do r3batch no Sistema

R/3 . . . . . . . . . . . . . . . . . 95

Resolução de Problemas . . . . . . . . . . 96

Alterando a Senha de ID do Usuário RFC do Tivoli


Migrando de Versões Anteriores . . . . . . . 97

Utilizando o Suporte a XBP 2.0 . . . . . . . . 98

Criando o Perfil de Autorização para o Usuário

do Tivoli Workload Scheduler . . . . . . . 98

Imprimir Parâmetros e Problemas de Classe Job . . 99

Capítulo 16. Definindo Jobs de Agente

Estendido do R/3 . . . . . . . . . . 101

Definindo um Job no R/3 . . . . . . . . . 101

Definindo um Job no Tivoli Workload Scheduler 101

Utilizando Janelas Específicas do SAP do Job

Scheduling Console . . . . . . . . . . 102

Parâmetros da Cadeia de Tarefas para Jobs do

R/3 . . . . . . . . . . . . . . . . 110

Os Estados de Job do Tivoli Workload Scheduler e

do R/3 . . . . . . . . . . . . . . . 112

Capítulo 17. Executando Jobs

Novamente . . . . . . . . . . . . 113

Cópia Antiga e Cópia Nova de um Job Executado

Novamente . . . . . . . . . . . . . . 113

Capítulo 18. Business Information

Warehouse . . . . . . . . . . . . 115

Business Information Warehouse Support -

InfoPackages . . . . . . . . . . . . . 115

Autorizações do Usuário . . . . . . . . 115

Componentes do Business Warehouse . . . . . 115

Definindo os Jobs de Agente Estendido para BIW 115

Opções de Planejamento do R/3 de um

InfoPackage . . . . . . . . . . . . . . 116

Capítulo 19. Conectando-se ao

Sistema R/3 . . . . . . . . . . . . 117

Conexões para um Servidor de Aplicativos

Específico . . . . . . . . . . . . . . . 117

Grupos de Logon . . . . . . . . . . . . 118

Capítulo 20. Arquivos de Opções do

Método de Acesso do R/3 . . . . . . 119

Opções de Configuração . . . . . . . . . . 119

Opções Globais . . . . . . . . . . . . 119

Opções Locais . . . . . . . . . . . . 120

Opções Gerais . . . . . . . . . . . . 121

Utilização das Opções de Configuração . . . . . 124

Migração de Arquivos de Configuração . . . . 125

iv IBM Tivoli Workload Scheduler para Aplicativos: Guia do Usuário

Capítulo 21. BDC Wait . . . . . . . . 127

Utilizando Nomes de Sessão BDC . . . . . . 127

Utilizando IDs da Fila BDC com o Relatório

BDCRECXX . . . . . . . . . . . . . . 128

Utilizando IDs da fila BDC com FM

BDC_OPEN_GROUP . . . . . . . . . . . 129

Capítulo 22. Recursos de

Interceptação de Job e Pais-filhos . . 131

Interceptação de Job . . . . . . . . . . . 131

Implementando a Interceptação de Jobs . . . 131

Recursos Pais-filhos . . . . . . . . . . . 134

Capítulo 23. Suporte Nacional a

Idiomas . . . . . . . . . . . . . . 137

Opções de Suporte Nacional a Idiomas . . . . . 137

Páginas de Código Suportadas pelo R/3 . . . . 137

Configurações Suportadas e Limitações . . . . . 138


z/OS . . . . . . . . . . . . . . . 139

Capítulo 24. Introdução . . . . . . . 141

Recursos . . . . . . . . . . . . . . . 141


Visão Geral da Instalação . . . . . . . . . 141

Instalando em Plataformas de Nível 2 . . . . 142

Instalando no z/OS . . . . . . . . . . 142

Definindo Autorizações no z/OS . . . . . . 144

Observações Adicionais . . . . . . . . . 144

Versões de Gateway do z/OS . . . . . . . 149

Capítulo 25. Configuração e Operação 151

Arquivos de Opções de Método . . . . . . . 151

Arquivos de Opções de Método em Plataformas

de Nível 2 . . . . . . . . . . . . . 151

Definindo Jobs no z/OS . . . . . . . . . . 152

Definindo Jobs do z/OS no Tivoli Workload

Scheduler . . . . . . . . . . . . . . . 152

Sintaxe de Definição de Tarefas para Jobs do

z/OS Planejados com o Tivoli Workload

Scheduler . . . . . . . . . . . . . . 153

Sintaxe de Definição de Tarefas para Outros

Jobs do z/OS . . . . . . . . . . . . 154

Sintaxe de Dependências de arquivo (OPENS)

em arquivos do z/OS . . . . . . . . . 156

Capítulo 26. Informações de

Referência . . . . . . . . . . . . . 157

Visão Geral Técnica . . . . . . . . . . . 157

Operação com o JES . . . . . . . . . . 157

Operação com o CA-7 . . . . . . . . . 158

Outras Dicas do CA-7 . . . . . . . . . 159

Operação com OPC ou Tivoli Workload

Scheduler para z/OS . . . . . . . . . . 159

Verificando Arquivos no z/OS . . . . . . . 161

Considerações de Sincronização . . . . . . 161

Informações de Diagnóstico . . . . . . . . 162

Mensagens de Gateway . . . . . . . . . . 162

Parte 6. Capacidade de Serviços

Comuns . . . . . . . . . . . . . 167

Capítulo 27. Referência do Agente

Estendido . . . . . . . . . . . . . 169

O que São Agentes Estendidos? . . . . . . . 169

Definição de Estação de Trabalho . . . . . . 169

Interface do Método de Acesso . . . . . . . 169

Sintaxe da Linha de Comandos do Método . . 169

Mensagens de Resposta do Método . . . . . 171

Arquivo de Opções do Método . . . . . . 172

Execução do Método . . . . . . . . . . . 173

Tarefa LJ (Lançar Job) . . . . . . . . . 173

Tarefa MJ (Gerenciar Job) . . . . . . . . 174

Tarefa CF (Verificar Arquivo) . . . . . . . 174

Tarefa GS (Obter Status) . . . . . . . . . 175

O Comando cpuinfo . . . . . . . . . . 176

Resolução de Problemas . . . . . . . . . . 176

Mensagens de Erro da Lista Padrão de Jobs . . 176

Método Não Executável . . . . . . . . . 176

Mensagens do Gerenciador de Console . . . . 176

Mensagens do Composer e do Compiler . . . 176

Mensagens do Jobman . . . . . . . . . 176

Capítulo 28. A Biblioteca de

Mapeamento do Código de Retorno . . 179

O Arquivo de Mapeamento do Código de Retorno 179 179 179 180 180

Mapeamento de Código de Retorno para

Psagent e MCMAGENT . . . . . . . . . 180

Nomes dos Arquivos de Mapeamento do

Código de Retorno . . . . . . . . . . 184

Capítulo 29. Configurando o Utilitário

de Rastreamento . . . . . . . . . . 185

Capítulo 30. Resolução de Problemas 187

Resolvendo Problemas de Instalação do Método de

Acesso do PeopleSoft . . . . . . . . . . . 188

Capítulo 31. Arquivos Instalados . . . 189

Parte 7. Apêndices . . . . . . . . 193

Avisos . . . . . . . . . . . . . . 195

Marcas . . . . . . . . . . . . . . . 197

Glossário . . . . . . . . . . . . . 199

Índice Remissivo . . . . . . . . . . 203

Índice v

vi IBM Tivoli Workload Scheduler para Aplicativos: Guia do Usuário

Prefácio

O Guia do Usuário do IBM Tivoli Workload Scheduler para Aplicativos fornece

informações sobre como instalar, configurar e utilizar os métodos de acesso do IBM

Tivoli Workload Scheduler que executam e controlam jobs dos seguintes

aplicativos:

v Oracle e-Business Suite

v PeopleSoft

v R/3

v z/OS

Este guia inclui e amplia o conteúdo dos seguintes manuais:

v Guia do Usuário do IBM Tivoli Workload Scheduler para Aplicativos versão 8.1.1 para

Oracle e-Business Suite


PeopleSoft


R/3


z/OS

Quem Deve Ler este Manual

Este manual é destinado aos programadores de job que pretendem executar e

controlar jobs desses aplicativos com o IBM Tivoli Workload Scheduler. O usuário

deste guia deve ter alguns conhecimentos de:

v IBM Tivoli Workload Scheduler

v Tivoli Job Scheduling Console

v O ambiente de aplicativo específico

O que este Manual Contém

Este manual contém as seguintes seções:

Parte 1. Tarefas Comuns de Instalação e Configuração

A Parte 1 contém os seguintes capítulos:

v Capítulo 1, “Visão Geral do Produto”, na página 3

descreve o funcionamento básico de um agente estendido.

v Capítulo 2, “Instalando o IBM Tivoli Workload Scheduler para Aplicativos”, na

página 5

descreve os vários meios de instalar e desinstalar o produto, junto com as

plataformas e os pré-requisitos suportados.

v Capítulo 3, “Definindo Opções com o Editor de Opções”, na página 27

descreve como usar o Editor de Opções.

v Capítulo 4, “Definindo as Estações de Trabalho de Agente Estendido”, na página

31

© Copyright IBM Corp. 2000, 2003 vii

descreve como definir as estações de trabalho do agente estendido para todos os

métodos de acesso.

v Capítulo 5, “Definindo os Jobs de Agente Estendido”, na página 37

descreve como definir os jobs de agente estendido para todos os métodos de

acessos.

Parte 2. Método de Acesso do Oracle e-Business Suite


v Capítulo 6, “Introdução”, na página 45

descreve os recursos, os requisitos de software, as tarefas de pós-instalação e o

software de interface específico para o método de acesso do Oracle e-Business

Suite.

v Capítulo 7, “Informações de Definição do Job”, na página 49

fornece informações para definir os jobs do Tivoli Workload Scheduler

específicos para esse método de acesso.

v Capítulo 8, “Referência do Arquivo de Opções MCMAGENT”, na página 53

descreve as opções usadas por esse método de acesso.

Parte 3. Método de Acesso do PeopleSoft



descreve os recursos, as funções e outras informações gerais sobre o método de

acesso do PeopleSoft.

v Capítulo 10, “Planejamento de Implementação”, na página 61

descreve os requisitos de host e software e outras informações relevantes para

diferenciar as versões do PeopleSoft suportadas por esse método.

v Capítulo 11, “Tarefas de Pós-Instalação”, na página 65

descreve as tarefas de pós-instalação para esse método de acesso.

v Capítulo 12, “Definindo os Jobs do PeopleSoft”, na página 77


específicos para esse método de acesso.

Parte 4. Método de Acesso do R/3



descreve os recursos do método de acesso R/3.

v Capítulo 14, “Instalação”, na página 87

fornece informações de instalação específicas para esse método de acesso e

descreve a instalação em plataformas de Nível 2.

v Capítulo 15, “Configuração do R/3”, na página 91

descreve como configurar esse método de acesso para utilizá-lo com o R/3.

v Capítulo 16, “Definindo Jobs de Agente Estendido do R/3”, na página 101


específicos para o método de acesso de R/3.

v Capítulo 17, “Executando Jobs Novamente”, na página 113

descreve o mecanismo para nova execução de jobs.

viii IBM Tivoli Workload Scheduler para Aplicativos: Guia do Usuário

v Capítulo 18, “Business Information Warehouse”, na página 115

fornece informações sobre como utilizar o método de acesso com o R/3 Business

Information Warehouse.

v Capítulo 19, “Conectando-se ao Sistema R/3”, na página 117

descreve as conexões e os grupos de logon do R/3.

v Capítulo 20, “Arquivos de Opções do Método de Acesso do R/3”, na página 119

descreve as opções usadas por esse método de acesso.

v Capítulo 21, “BDC Wait”, na página 127

fornece detalhes sobre o BDC Wait.

v Capítulo 22, “Recursos de Interceptação de Job e Pais-filhos”, na página 131

descreve a interceptação do job e os recursos País-filhos do XBP 2.0.

v Capítulo 23, “Suporte Nacional a Idiomas”, na página 137

descreve o suporte de idioma nacional para esse método de acesso.

Parte 5. Método de Acesso z/OS



lista os recursos do método de acesso do z/OS; descreve como instalar a parte

distribuída em plataformas de nível 2 e como instalar os componentes de

gateway no z/OS.

v Capítulo 25, “Configuração e Operação”, na página 151

descreve as opções desse método de acesso e fornece informações específicas do

método sobre a definição de job.

v Capítulo 26, “Informações de Referência”, na página 157

fornece informações de referência para operações com os programadores de job

suportados e lista as mensagens de gateway.

Parte 6. Capacidade de Serviços Comuns


v Capítulo 27, “Referência do Agente Estendido”, na página 169

fornece informações de referência para desenvolver um método de acesso do

Tivoli Workload Scheduler.

v Capítulo 28, “A Biblioteca de Mapeamento do Código de Retorno”, na página

179

descreve como usar o utilitário de mapeamento do código de retorno.

v Capítulo 29, “Configurando o Utilitário de Rastreamento”, na página 185

descreve como configurar o utilitário de rastreamento.

v Capítulo 30, “Resolução de Problemas”, na página 187

fornece algumas informações gerais sobre solução de problemas.

v Capítulo 31, “Arquivos Instalados”, na página 189

lista os arquivos instalados de acordo a plataforma e com o recurso.

Publicações

Esta seção lista as publicações na biblioteca do IBM Tivoli Workload Scheduler

eTambém descreve como acessar as publicações Tivoli on-line, como solicitar

publicações Tivoli e como fazer comentários sobre publicações Tivoli.

Prefácio ix

Publicações do IBM Tivoli Workload Scheduler

Essa seção lista as publicações na biblioteca do IBM Tivoli Workload Scheduler e

documentos listados. Ela também descreve como acessar publicações Tivoli on-line

e como solicitar publicações Tivoli.

v IBM Tivoli Workload Scheduler - Guia de Planejamento e Instalação , S517-7780

Descreve como planejar uma rede do Tivoli Workload Scheduler e como instalar

e personalizar o Tivoli Workload Scheduler e o software associado.

v IBM Tivoli Workload Scheduler - Guia de Referência, S517-7781

Explica a linha de comandos do Tivoli Workload Scheduler, o entendimento do

funcionamento dos agentes estendidos e de rede e a integração do Tivoli

Workload Scheduler com o NetView e com o Tivoli Business Systems Manager.

v IBM Tivoli Workload Scheduler - Resolução de problemas e Mensagens de Erro ,

S517-7782

Interpreta as mensagens de erro do Tivoli Workload Scheduler e fornece fontes

de informações que ajudarão você a resolver problemas com o Tivoli Workload

Scheduler.

v IBM Tivoli Workload Scheduler Job Scheduling Console - Notas sobre o Release,

S517-7779

Fornece informações sobre como trabalhar com o Tivoli Workload Scheduler,

independentemente da plataforma, a partir de uma GUI comum.

v IBM Tivoli Workload Scheduler Job Scheduling Console - Guia do Usuário, S517-7778

Fornece informações sobre como trabalhar com o Tivoli Workload Scheduler,

independentemente da plataforma, a partir de uma GUI comum.

v IBM Tivoli Workload Scheduler para Notas sobre o Release de Aplicativos, S517-7786

Fornece as últimas informações sobre os agentes estendidos do Tivoli Workload

Scheduler.

v IBM Tivoli Workload Scheduler AS/400 Limited Fault-tolerant Agent User’s Guide,

SC32-1280

Descreve a instalação, configuração e utilização dos agentes tolerantes a falhas

do Tivoli Workload Scheduler no AS/400.

v IBM Tivoli Workload Scheduler Plus Module - Guia do Usuário, S517-7783

Explica a configuração e utilização do Plus Module do Tivoli Workload

Scheduler.

v IBM Tivoli Workload Scheduler - Notas Sobre o Release, S517-7784

Explica as últimas informações sobre o Tivoli Workload Scheduler.

Publicações do IBM Tivoli Workload Scheduler para z/OS

Os seguintes documentos estão disponíveis na biblioteca do IBM Tivoli Workload

Scheduler para z/OS:

v IBM Tivoli Workload Scheduler para z/OS Customization and Tuning , SC32-1265

Descreve como personalizar o Tivoli Workload Scheduler para z/OS.

v IBM Tivoli Workload Scheduler para z/OS Diagnosis Guide and Reference, SC32-1261

Fornece informações que ajudam a diagnosticar e corrigir possíveis problemas ao

utilizar o produto.

v IBM Tivoli Workload Scheduler para z/OS General Information, SC32-1256

Descreve os benefícios de todo o conjunto do Tivoli Workload Scheduler.

v IBM Tivoli Workload Scheduler para z/OS Getting Started, SC32-1262

x IBM Tivoli Workload Scheduler para Aplicativos: Guia do Usuário

Descreve os conceitos e a terminologia do IBM Tivoli Workload Scheduler para

z/OS e fornece instruções para que você trabalhe com o produto assim que

possível.

v IBM Tivoli Workload Scheduler para z/OS Installation Guide, SC32-1264

Explica como instalar o Tivoli Workload Scheduler para z/OS.

v IBM Tivoli Workload Scheduler para z/OS Licensed Program Specifications, GI11-4208

Fornece informações de planejamento sobre o Tivoli Workload Scheduler para

z/OS.

v IBM Tivoli Workload Scheduler para z/OS Managing the Workload, SC32-1263

Explica como planejar e programar a carga de trabalho e como controlar e

monitorar o plano atual.

v IBM Tivoli Workload Scheduler para z/OS Memo to Users, GI11-4209

Fornece um resumo das alterações do release atual do produto.

v IBM Tivoli Workload Scheduler para z/OS Messages and Codes, SC32-1267

Explica mensagens e códigos.

v IBM Tivoli Workload Scheduler para z/OS Program Directory, GI11-4203

Fornecido com a fita de instalação do Tivoli Workload Scheduler para z/OS,

descreve todos os materiais de instalação e fornece instruções de instalação

específicas para o nível do release do produto e número do recurso.

v IBM Tivoli Workload Scheduler para z/OS Programming Interfaces, SC32-1266

Fornece informações para desenvolver programas de aplicativos.

v IBM Tivoli Workload Scheduler para z/OS Quick Reference, SC32-1268

Fornece uma referência de consulta fácil e rápida para operar o produto.

Kit de Coleção de Cópia Eletrônica para o IBM Tivoli Workload

Scheduler para z/OS

Todos os manuais na biblioteca, exceto as publicações licenciadas, estão disponíveis

no formato de cópia eletrônica apresentável nos seguintes kits de coleção:

v IBM Online Library Omnibus Edition OS/390 Collection Kit, SK2T-6700.

v IBM Online Library z/OS Software Products Collection Kit, SK2T-4270.

Você pode ler os manuais em cópia eletrônica em CD-ROMs utilizando estes

programas IBM licenciados:

v Leitora de Cópia Eletrônica

v BookManager READ/2

v BookManager READ/DOS

v BookManager READ/6000

Todos os programas BookManager precisam de um computador pessoal equipado

com uma unidade de disco de CD-ROM (capaz de ler discos formatados no padrão

ISO 9660), além de uma placa e cabo correspondentes. Para obter informações

adicionais sobre hardware e software, consulte a documentação do produto

BookManager específico que você está utilizando.

As atualizações de manuais entre os releases são fornecidas apenas em cópia

eletrônica.

Prefácio xi

Publicações listadas

O Tivoli Software Glossary inclui definições para muitos termos técnicos listados ao

software Tivoli. O Tivoli Software Glossary está disponível, somente em inglês, no

seguinte Web site:

http://publib.boulder.ibm.com/tividd/glossary/termsmst04.htm

Acessando Publicações On-line

O CD de documentação contém as publicações que estão na biblioteca do produto.

O formato das publicações é PDF e/ou HTML. Para acessar as publicações

utilizando um navegador da Web, abra o arquivo infocenter.html. O arquivo

encontra-se no diretório de publicações apropriado no CD do produto.

A IBM lança publicações para este e todos os outros produtos Tivoli, assim que se

tornam disponíveis e sempre que são atualizados, no site do Tivoli Software

Information Center na Web. O Tivoli Software Information Center está localizado

no seguinte endereço da Web:

http://publib.boulder.ibm.com/tividd/td/tdprodlist.html

Clique no link do Tivoli Workload Scheduler para acessar a biblioteca de produtos.

Nota: Se você imprimir documentos PDF em papel que não seja tamanho carta,

selecione a caixa de opções Ajustar à página na janela Impressão do Adobe

Acrobat. Essa opção fica disponível quando você clica em Arquivo →

Imprimir. Ajustar à página garante que as dimensões totais de uma página

tamanho carta sejam impressas no papel que você está utilizando.

Solicitando Publicações

É possível solicitar várias publicações on-line da Tivoli neste Web site:

http://www.elink.ibmlink.ibm.com/public/applications/publications/cgibin/pbi.cgi

Você também pode solicitar por telefone ligando para um destes números:

v No Brasil: 0800-7873-78

v No Canadá: 800-426-4968

Em outros países, consulte o seguinte Web site para obter uma lista de números de

telefones:

http://www.ibm.com/software/tivoli/order-lit/

Fornecendo Feedback sobre as Publicações

Se você tiver comentários ou sugestões sobre os produtos e a documentação Tivoli,

preencha a pesquisa de feedback do cliente no seguinte Web site:

http://www.ibm.com/software/sysmgmt/products/support

xii IBM Tivoli Workload Scheduler para Aplicativos: Guia do Usuário

http://publib.boulder.ibm.com/tividd/glossary/termsmst04.htm

http://publib.boulder.ibm.com/tividd/td/tdprodlist.html

http://www.elink.ibmlink.ibm.com/public/applications/publications/cgibin/pbi.cgi

http://www.ibm.com/software/tivoli/order-lit/

http://www.ibm.com/software/sysmgmt/products/support

Acessibilidade

Os recursos de acessibilidade ajudam usuários com deficiências físicas, como

mobilidade restrita ou visão limitada, a usar os produtos de software com êxito.

Com este produto, é possível utilizar tecnologias assistidas para ouvir e navegar na

interface. Você pode também utilizar o teclado em vez do mouse para operar todos

os recursos da interface gráfica com o usuário.

Para obter informações adicionais, consulte o Apêndice Acessibilidade no Guia do

Usuário do Console de Programação do Job do IBM Tivoli Workload Scheduler.

Entrando em Contato com o IBM Software Support

Se você tiver algum problema com qualquer produto Tivoli, entre em contato com

o IBM Software Support. Consulte o IBM Software Support Guide no seguinte Web

site:

http://techsupport.services.ibm.com/guides/handbook.html

A documentação fornece informações sobre como entrar em contato com o IBM

Software Support, dependendo da gravidade do seu problema e das seguintes

informações:

v Registro e elegibilidade

v Números de telefone e endereços de e-mail, dependendo do país no qual você

está localizado;

v Informações que você deve ter antes de entrar em contato com o IBM Software

Support

Convenções Utilizadas neste Manual

Este manual utiliza diversas convenções para termos e ações especiais, comandos e

caminhos dependentes do sistema operacional.

Convenções de Tipo de Caractere

Este manual usa as seguintes convenções tipográficas:

Negrito

v Comandos em letras minúsculas ou em letras maiúsculas e

minúsculas (exceto aqueles com todas as letras maiúsculas) que

são difíceis de distinguir do texto ao redor.

v Controles de interface (caixas de opções, botões de comando,

botões de opções, botões de giro, campos, pastas, ícones,

quadros de listagem, itens dentro de quadros de listagem, listas

com várias colunas, contêineres, opções de menu, nomes de

menu, guias, folhas de propriedade), rótulos (como Dica: e

Considerações sobre o sistema operacional:)

v Títulos de coluna em uma tabela

v Palavras-chave e parâmetros em um texto

Os comandos (exceto os em letras maiúsculas) são exibidos em

fonte negrito.

Itálico

v Citações (títulos de manuais, disquetes e CDs)

Prefácio xiii

http://techsupport.services.ibm.com/guides/handbook.html

v Palavras definidas no texto

v Ênfase de palavras (palavras como palavras)

v Letras como letras

v Novos termos no texto (exceto em uma lista de definições)

v Variáveis e valores que você deve fornecer

Espaçamento Fixo

v Exemplos, exemplos de código e saída

v Nomes de arquivos, palavras-chave de programação e outros

elementos que são difíceis de serem distinguidos do texto ao

redor

v Texto de mensagem e prompts dirigidos ao usuário

v Texto que o usuário deve digitar

v Valores para argumentos ou opções de comando

Os exemplos de código, saída, texto que você deve digitar e

mensagens do sistema são exibidos em espaçamento fixo.

barras de revisão

Alterações técnicas no texto são indicadas por uma linha vertical à

esquerda da alteração.

Variáveis e Caminhos que Dependem do Sistema Operacional

Este manual utiliza a convenção UNIX para especificar variáveis de ambiente e

para notação de diretório.

Ao utilizar a linha de comandos Windows, substitua $variável por % variável% para

variáveis de ambiente e substitua cada barra (/) por uma barra invertida ( \) nos

caminhos de diretório.

Nota: Se você estiver utilizando o bash shell em um sistema Windows, será

possível utilizar as convenções UNIX.

xiv IBM Tivoli Workload Scheduler para Aplicativos: Guia do Usuário

Parte 1. Tarefas Comuns de Instalação e Configuração

© Copyright IBM Corp. 2000, 2003 1

2 IBM Tivoli Workload Scheduler para Aplicativos: Guia do Usuário

Capítulo 1. Visão Geral do Produto

Os XA (agentes estendidos) são utilizados para estender as funções de

planejamento do job do IBM Tivoli Workload Scheduler para outros sistemas e

aplicativos. Um agente estendido é definido como uma estação de trabalho que

tem um host e um método de acesso.

O host é um FTA (agente tolerante a falhas) do Tivoli Workload Scheduler ou um

SA (agente padrão).

O método de acesso é um programa executado pela estação de trabalho de host

sempre que o Tivoli Workload Scheduler, por meio da linha de comando ou pelo

Tivoli Job Scheduling Console, precisa interagir com o sistema externo. O Tivoli

Workload Scheduler para Aplicativos inclui os seguintes métodos de acesso:

v Método de acesso do Oracle e-Business Suite (MCMAGENT)

v Método de acesso do PeopleSoft (psagent)

v Método de acesso do R/3 (r3batch)

v Método de acesso do z/OS (mvsca7, mvsjes e mvsopc)

Para ativar e monitorar um job em um agente estendido, o host executa o método

de acesso, transmitindo os detalhes do job como opções da linha de comando. O

método de acesso comunica-se com o sistema externo para ativar o job e retornar o

status do job.

Uma estação de trabalho de agente externo é apenas uma entidade lógica listada

ao método de acesso hospedado pela estação de trabalho física do Tivoli Workload

Scheduler. Mais de uma estação de trabalho de agente estendido pode ser

hospedada pela mesma estação de trabalho do Tivoli Workload Scheduler e contar

com o mesmo método de acesso. O x-agent é definido em uma definição de

estação de trabalho padrão do Tivoli Workload Scheduler, que fornece ao x-agent

um nome e identifica o método de acesso.

A próxima figura mostra como esses elementos se ajustam no caso de uma

configuração de agente estendido normal.


Para ativar um job em um ambiente externo, o Tivoli Workload Scheduler executa

o método de acesso de agente estendido fornecendo um nome de estação de

trabalho de agente estendido e informações sobre o job. O método observa o

arquivo de correspondência chamado <WORKSTATION_NAME>_

<nome_do_método>.opts para determinar a qual instância do ambiente externo ele

irá se conectar. O método de acesso pode ativar jobs nessa instância e monitorá-los

por meio da conclusão do processo de gravação do job e das informações de status

no arquivo de lista padrão do job.

Os agentes estendidos podem ser usados para executar jobs em ambientes ponto a

ponto, em que o planejamento e a monitoração são executados a partir de um

controlador do IBM Tivoli Workload Scheduler para z/OS.

Figura 1. Como os Agentes Estendidos Funcionam.


Capítulo 2. Instalando o IBM Tivoli Workload Scheduler para

Aplicativos

Nas plataformas mais suportadas, todos os métodos de acesso do IBM Tivoli

Workload Scheduler para Aplicativos descritos neste guia são instalados por meio

de um processo de instalação comum. Seguindo esse processo, você instala um

instância do Tivoli Workload Scheduler para Aplicativos -em que a instância

corresponde ao adição de pelo menos um método de acesso à instalação do Tivoli

Workload Scheduler existente - e seleciona um ou mais métodos de acesso a partir

dos recursos de instalação.

O processo de instalação comum está disponível para as seguintes plataformas,

quando suportado por um método de acesso:

v Microsoft Windows NT ou 2000

v IBM AIX

v HP-UX

v Ambiente Operacional Sun

v Linux para Intel

v Linux/390

Para as seguintes plataformas, o processo de instalação permanece como descrito

na documentação de métodos individuais, no próximo capítulo:

v Compaq Tru64

v SGI Irix

v IBM Sequent Dynix

A tabela a seguir lista quais plataformas são suportadas por essa versão do IBM

Tivoli Workload Scheduler para Aplicativos:

Tabela 1. Plataformas Suportadas

Método de Acesso

Plataforma z/OS

(Gateway)

z/OS

(Servidor de

transação)

R/3 PeopleSoft Oracle eBusiness

Suite

IBM OS/390 V2R10 e

superior

X

IBM z/OS V1R1 e

superior

X

IBM AIX versões

4.3.3, 5.1, 5.2

X X X

IBM Sequent Dynix

versões 4.5.1

X

Solaris Operating

Environment Versões

7, 8, 9

X X X

Hewlett Packard

PA-RISC Versões 11.0,

11i

X X X


Tabela 1. Plataformas Suportadas (continuação)

Método de Acesso

Plataforma z/OS

(Gateway)

z/OS

(Servidor de

transação)

R/3 PeopleSoft Oracle eBusiness

Suite

SuSE Linux

Enterprise Server

versão 7 para OS/390

e zSeries (kernel 2.4)

X X

RedHat Linux para

OS/390 e zSeries

versão 7

X X

RedHat Linux (Intel)

versões 7.2, 7.3

X

SuSE Linux (Intel)

Enterprise Server

versão 8

X

Microsoft Windows

NT versão 4.0 com

Service Pack 6a

X X X

Microsoft Windows

2000 com Service

Pack 3 Professional,

Server, Advanced

X X X

Compaq Tru64 Versão

5.1

X X

SGI Irix versão 6.5.x X

Como Instalar

Você pode escolher dentre três modos alternativos para instalar o Tivoli Workload

Scheduler para Aplicativos:

v Usando o assistente ISMP (InstallShield Multi-Platform)

v Executando a opção de instalação silenciosa do InstallShield

v Usando o componente de Distribuição de Software do Tivoli Configuration

Manager

Antes de instalar o produto utilizando um desses métodos, verifique se as

condições a seguir são atendidas:

v Você deve ter uma instalação válida do IBM Tivoli Workload Scheduler versão

7.0 ou superior no computador antes de instalar qualquer um dos métodos de

acesso.

v Você deve ter direitos de raiz (Unix) ou de Administrador (Windows) para

executar a instalação.

v Você deve parar todos os serviços do Tivoli Workload Scheduler antes de iniciar

o processo de instalação.

v Para o método de acesso do PeopleSoft: a instalação desse método requer que o

ambiente PeopleSoft correspondente já esteja instalado e totalmente acessível a

partir da estação de trabalho em que ocorrerá a instalação.


v Para o método de acesso do Oracle eBusiness Suite: O servidor Oracle e-Business

Suite é exigido no mesmo nó físico que o método de acesso e o host do Tivoli

Workload Scheduler.

v Certifique-se de que o processo de instalação não esteja em execução na estação

de trabalho. Esse cenário pode existir em uma rede em que mais conexões telnet

sejam abertas no mesmo computador Unix por usuários autorizados para que

possam orientar remotamente a instalação de um método de acesso. Execute o

comando a seguir para verificar se o processo de instalação já está ativo no

computador em que desejar fazer a instalação:

ps -ef | grep setup.bin

Pelo mesmo sinal, se sua estação de trabalho executar mais instâncias do Tivoli

Workload Scheduler, restrinja a execução do processo de instalação para somente

uma instância por vez.

v Antes de instalar instâncias adicionais do produto ou de atualizar instâncias

existentes, verifique se o Editor de Opção não está em execução, ou poderá

haver falha na instalação.

Consulte Capítulo 31, “Arquivos Instalados”, na página 189 para obter uma lista de

arquivos que você deve encontrar no computador após a instalação.

Utilizando o Assistente de Instalação

Para utilizar o assistente de instalação do ISMP no computador, seu sistema

operacional deve ser capaz de executar Java Runtime Environment (JRE) versão

1.3.1. Algumas plataformas requerem níveis de manutenção para que suportem o

JRE 1.3.1. Consulte a tabela a seguir para saber se o sistema operacional deve ser

corrigido ou não. Para as plataformas suportadas não incluídas nessa tabela,

nenhuma correção adicional é necessária.

Tabela 2. Correções Requeridas para Executar o JRE 1.3.1

Sistema Operacional Correção Requerida para Executar o JRE 1.3.1

IBM AIX Versão 4.3.3 AIX 4330–10 - Nível de Manutenção Recomendado.

IBM AIX Versão 5.1 AIX 5100–02 - Nível de Manutenção Recomendado. Requer

que APAR IY19375 seja anteriormente aplicado e

consolidado.

Se você estiver utilizando um dos locales CKJ não UTF8

suportados, um dos seguintes conjuntos de arquivos

(disponíveis no CD base do AIX 5.1) será necessário:

v X11.fnt.ucs.ttf (para ja_JP ou Ja_JP)

v X11.fnt.ucs.ttf_CN (para zh_CN ou Zh_CN)

v X11.fnt.ucs.ttf_KR (para ko_KR)

v X11.fnt.ucs.ttf_TW (para zh_TW ou Zh_TW)

Para usuários japoneses: se você estiver utilizando o

Método de Entrada Japonês, deve aplicar os seguintes

PTFs para evitar alguns problemas listados ao Método de

Entrada.

v jkit.Wnn6.base 2.2.0.2 (PTF U479697 ou APAR IY22917)

(apenas usuários Wnn6)

v X11.motif.lib 5.1.0.15 (PTF U479604 ou APAR IY22933)

(apenas usuários AIX 5.1)

Solaris Operating

Environment Versões 7, 8, 9

Clusters de Correção datados de janeiro de 2002 ou

posterior.

Capítulo 2. Instalando o IBM Tivoli Workload Scheduler para Aplicativos 7

Tabela 2. Correções Requeridas para Executar o JRE 1.3.1 (continuação)

Sistema Operacional Correção Requerida para Executar o JRE 1.3.1

Hewlett Packard PA-RISC

Versões 11.0, 11i

As correções do sistema operacional devem estar

instaladas antes que você instale o produto. Para

determinar quais correções foram instaladas em seu

computador, efetue login como raiz e execute:

/usr/sbin/swlist -l product

Para suportar JRE 1.3.1.05, você deve ter:

v Para HP-UX 11.0, Quality Pack QPK1100

v Para HP-UX 11i, Quality Pack GOLDQPK11i

Para instalar um ou mais métodos de acesso do Tivoli Workload Scheduler para

Aplicativos no seu computador, execute os seguintes procedimentos:

1. Pare todos os serviços do Tivoli Workload Scheduler.

2. A partir do CD do produto ou de uma imagem, execute o comando de

instalação. Ele pode ser:

v setup.bin no Unix

v setup.exe no Windows

A janela Bem-vindo é exibida.

3. Clique em Next para continuar. A janela Acordo de Licença do Software é

exibida.

Figura 2. Janela Bem-vindo.


4. Selecione o botão de opções para aceitar o acordo e clique em Next para

continuar. A janela Escolher o Tipo de Instalação é exibida.

5. Escolha se você está executando uma nova instalação do Tivoli Workload

Scheduler para Aplicativos ou se está atualizando uma instalação existente. Se

você estiver instalando um método de acesso adicional, selecione Update an

instance.

v Se você escolher Create a new instance, o programa de instalação detectará

e listará todas as instalações do Tivoli Workload Scheduler no seu

computador.

Figura 3. Janela Acordo de Licença do Software.

Figura 4. Janela Escolher o Tipo de Instalação


v Se você escolher Update an instance, o programa de instalação detectará e

listará todas as instalações do Tivoli Workload Scheduler para Aplicativos

no seu computador.

Clique em Next para continuar.

Se você selecionar Create a new instance uma janela similar à Figura 5 será

exibida.

O programa de instalação pesquisa o sistema e lista todas as instâncias do

Tivoli Workload Scheduler existentes.

Notas:

a. Se o processo de descoberta não encontrar as instâncias existentes, uma

janela será exibida no local em que você poderá inserir o caminho de

instalação e o nome de uma instância.

b. Se você estiver no Unix e tiver várias instalações do Tivoli Workload

Scheduler versões 7.0 ou 8.1, que não foram instaladas adequadamente no

diretório inicial /home/TWSuser, a janela listará, aleatoriamente, somente

uma das instâncias e um dos nomes <desconhecido>. Dessas instâncias,

essa será a única que você poderá marcar para instalação. Consulte

Tabela 24 na página 187 para obter detalhes.

Se você selecionar Update an instance, uma janela semelhante a Figura 6 na

página 11 será exibida.

Figura 5. Janela Instâncias Instaladas do Tivoli Workload Scheduler.


O programa de instalação pesquisa o sistema e lista todas as instâncias do

Tivoli Workload Scheduler para Aplicativos existentes.

6. Selecione uma ou mais instâncias e clique em Next para continuar. Uma janela

que lista todos os métodos de acesso fornecidos com o Tivoli Workload

Scheduler para Aplicativos é exibida. A lista varia de acordo com a plataforma

na qual você está executando a instalação: as instalações no Unix não listam o

método de acesso para o PeopleSoft, enquanto as instalações no Windows não

listam o método de acesso para o Oracle.

Este exemplo é para uma instalação no Windows.

Figura 6. Janela Instâncias Instaladas do Tivoli Workload Scheduler para Aplicativos.

Figura 7. A Janela Selecionar os Recursos do Tivoli Workload Scheduler para Aplicativos no MS Windows.


Este exemplo é para uma instalação no Unix.

7. Selecione o método de acesso ou métodos que deseja instalar no seu

computador e clique em Next para continuar. Dependendo da quantidade e

de quais métodos de acesso você selecionou, uma ou mais janelas adicionais

exigirão informações específicas para o método de acesso. Isso pode ser:

v Para todos os métodos de acesso: o nome do usuário do Tivoli Workload

Scheduler que estará executando o método selecionado. Ele pode ter o

mesmo nome definido quando o Tivoli Workload Scheduler foi instalado.

v Para o método de acesso do PeopleSoft: a versão do ambiente PeopleTools e

um dos seguintes itens:

– Para o PeopleSoft versão 7.0x ou 7.5x, o caminho do diretório de tempo

de execução COBOL (normalmente <PS_HOME>\cblbin).

– Para o PeopleSoft versão 8.1x, o caminho para o PeopleSoft External APIs

(normalmente <EXT_API_DIR>\bin\client\winx86_extapi).

– Para o PeopleSoft versão 8.4x, o caminho para o diretório cliente do

PeopleSoft (normalmente <PS_HOME>\bin\client\winx86).

Essa é a janela para o Método de Acesso do R/3.

Figura 8. A Janela Selecionar os Recursos do Tivoli Workload Scheduler para Aplicativos no Unix.


Essa é a primeira janela para o Método de Acesso do PeopleSoft.

Essa é a segunda janela para o Método de Acesso do PeopleSoft.

Figura 9. Janela Informações Adicionais do Usuário para o Método de Acesso do R/3.

Figura 10. Primeira janela Informações Adicionais do Usuário para o Método de Acesso do PeopleSoft.


Essa é a janela para o Método de Acesso do z/OS.

8. Insira as informações necessárias e clique em Next para continuar. Uma

janela de informações de resumo é exibida. A Figura 13 na página 15 mostra

um exemplo de informações de resumo para a instalação do método de acesso

para o R/3.

Figura 11. Segunda janela Informações Adicionais do Usuário para o Método de Acesso do PeopleSoft.

Figura 12. Janela Informações Adicionais do Usuário para o Método de Acesso do z/OS.


9. Clique em Next para continuar. O processo de instalação começa a instalar os

métodos de acesso selecionados no computador. Uma janela mostrando o

andamento da instalação é exibida.

Quando a instalação estiver concluída, a seguinte janela será exibida,

perguntando se deseja executar o Editor de Opções. Esse é um editor de

arquivos baseado em Java que permite definir opções para os métodos de

acesso instalados. Se você optar por não executar o Editor de Opções agora,

será possível fazê-lo a qualquer momento.

Figura 13. Janela Resumo da Instalação.

Figura 14. A Janela Andamento da Instalação.


10. Clique no botão de opções apropriado se desejar executar o Editor de Opções

imediatamente ou não e selecione Next para continuar.

Se você clicar em Yes, o Editor de Opções será exibido e você poderá definir

as opções para os métodos instalados. Consulte Capítulo 3, “Definindo Opções

com o Editor de Opções”, na página 27 para aprender como utilizar o Editor

de Opções.

Ao terminar de usar o Editor de Opções, ou se tiver selecionado No na janela

anterior, a janela de saída da instalação será exibida.

11. Selecione Finish para sair do assistente de instalação.

Figura 15. Janela Ativação do Editor de Opções

Figura 16. A janela Saída do Assistente de Instalação.


O log de instalação chamado TWS4APPS.LOG é salvo no diretório maestro.

Utilizando a Instalação Silenciosa

Esse método fornece a opção para instalar o produto sem a utilização do assistente

de instalação do ISMP. Para instalar, utilizando esse método, prepare um arquivo

de opções com antecedência e especifique seu nome com o comando de instalação.

A utilização do método de instalação silenciosa permite instalar todos os métodos

de acesso simultaneamente.

O log de instalação chamado TWS4APPS.LOG é salvo no diretório maestro.

Formato: Para instalar o Tivoli Workload Scheduler para Aplicativos com o

método silencioso, utilize o seguinte comando:

v No Windows

setup.exe -silent -options nome_e_caminho_do_arquivo_de_opções

v No Unix

setup.bin -silent -options nome_e_caminho_do_arquivo_de_opções

Parâmetros:

-silent Especifica que a instalação não é direcionada por uma interface do usuário

mas por um arquivo de opções.

-options nome_e_caminho_do_arquivo_de_opções

Fornece o caminho e o nome do arquivo que contém as opções de

instalação. O arquivo de opções pode ser qualquer arquivo de texto com o

nome e a extensão escolhida. As opções estão escritas individualmente por

linha.

Um gabarito para executar uma instalação silenciosa é fornecido com o

produto. O gabarito é chamado silent.txt e está disponível no diretório

RESPONSE_FILE no CD-ROM do produto.

A tabela a seguir lista as opções que você pode utilizar para orientar a

instalação:

Tabela 3. Opções Necessárias para Instalação Silenciosa.

Opção Descrição Valor

-P TWS4APPS.installLocation O caminho no qual deseja

instalar o Tivoli Workload

Scheduler para Aplicativos.

Essa opção é obrigatória.

Um caminho absoluto.

-P TWS4APPS.name Um nome para essa

instância do Tivoli

Workload Scheduler para

Aplicativos. Essa opção é

obrigatória.

Um nome. Colocar entre aspas

duplas se o nome tiver espaço

em branco.

-P MCMAGENT_FEATURE.active Especifica que o método e

acesso para o Oracle

eBusiness Suite vai ser

instalado.

Verdadeiro ou Falso.


Tabela 3. Opções Necessárias para Instalação Silenciosa. (continuação)


-W LJUSER_MCMAGENT_INPUT_BEAN.LJUSER O nome do usuário do

Tivoli Workload Scheduler

que vai executar o método

de acesso para o Oracle

eBusiness Suite. Essa opção

é obrigatória se você estiver

instalando esse método.

Um nome de usuário do Tivoli

Workload Scheduler. Colocar

entre aspas duplas se o nome

tiver espaço em branco.

-P R3BATCH_FEATURE.active Especifica que o método de

acesso para R/3 vai ser

instalado.


-W LJUSER_R3BATCH_INPUT_BEAN.LJUSER O nome do usuário do



de acesso para R/3. Essa

opção é obrigatória se você

estiver instalando esse

método.





-P ZOSAGENT_FEATURE.active Especifica que o método de

acesso para z/OS vai ser

instalado.


-W LJUSER_ZOSAGENT_INPUT_BEAN.LJUSER O nome do usuário do



de acesso para o z/OS. Essa



método.





-P PSAGENT_FEATURE.active Especifica que o método de

acesso para o PeopleSoft vai

ser instalado.


-W LJUSER_PSAGENT_INPUT_BEAN.LJUSER O nome do usuário do



de acesso para o PeopleSoft.

Essa opção é obrigatória se

você estiver instalando esse

método.








-W LJUSER_PSAGENT_INPUT_BEAN.BEND_TYPE Especifica a versão do

ambiente PeopleTools. Essa



método.

Ele pode ser um ou mais dos

seguintes itens:

PS70MR2

PeopleTools 7.0x e

Merant NetExpress 2.x

PS70MR3

PeopleTools 7.0x e


PS70WB4

PeopleTools 7.0x e MF

COBOL Workbench 4.x

PS75MR2

PeopleTools 7.5x e


PS75MR3

PeopleTools 7.5x e


PS81 PeopleTools 8.1x


Várias entradas devem ser

separadas por ponto-e-vírgula.

-W PS70MR2_CBLDIR.DIRNAME O caminho do diretório

COBOL para PeopleTools

7.0x e Merant NetExpress

2.x. Utilize somente se você

especificou esse ambiente.

O caminho completo para esse

diretório, normalmente

<PS_HOME>\cblbin.








<PS_HOME>\cblbin.

-W PS70WB4_CBLDIR.DIRNAME O caminho do diretório


7.0x e MF COBOL

Workbench 4.x. Utilize

somente se você especificou

esse ambiente.



<PS_HOME>\cblbin.








<PS_HOME>\cblbin.








<PS_HOME>\cblbin.




-W PS81_APIDIR.DIRNAME O caminho do diretório do

External APIs para

PeopleTools 8.1x. Utilize


esse ambiente.



<EXT_API_DIR>\bin\client\

winx86_extapi.

-W PS84_APIDIR.DIRNAME O caminho do diretório

cliente do PeopleSoft para

PeopleTools 8.4x. Utilize


esse ambiente.



<PS_HOME>\bin\client\

winx86.

Exemplos: O seguinte exemplo utiliza um arquivo de opções chamado

silent_options.txt para instalar silenciosamente o Tivoli Workload Scheduler

para Aplicativos em um computador com o Windows:

setup.exe –silent –options c:\tmp\silent_options.txt

O seguinte exemplo utiliza um arquivo de opções chamado silent_options.txt

para instalar silenciosamente o Tivoli Workload Scheduler para Aplicativos em um

computador com o Unix semX-Server disponível:

setup.bin –silent –options /tmp/silent_options.txt

O seguinte exemplo é um arquivo de opções utilizado para orientar a instalação do

Tivoli Workload Scheduler para Aplicativos em um computador com Windows. Os

métodos de acesso para R/3 e para PeopleSoft são definidos como recursos de

instalação.

# LOCALIZAÇÃO DA INSTALAÇÃO e NOME DA INSTÂNCIA

-P TWS4APPS.installLocation=C:\win32app\maestro

-P TWS4APPS.name=SILENT

# DEFINIÇÕES DE R3BATCH

-P R3BATCH_FEATURE.active=true

-W LJUSER_R3BATCH_INPUT_BEAN.LJUSER=twsuser

# DEFINIÇÕES DE PSAGENT

-P PSAGENT_FEATURE.active=true

-W LJUSER_PSAGENT_INPUT_BEAN.LJUSER=tws

-W LJUSER_PSAGENT_INPUT_BEAN.BEND_TYPE=PS70MR2;PS75MR3

-W PS70MR2_CBLDIR.DIRNAME=M:\PSDIRS\PS70Merant2

-W PS75MR3_CBLDIR.DIRNAME=N:\PSDIRS\PS75Merant3

Utilizando o Tivoli Configuration Manager

Cada método de acesso pode ser instalado por meio da distribuição de um SPB

(bloco de pacote de software), utilizando o Tivoli Desktop ou o comando winstsp

do componente de Distribuição de Software do IBM Tivoli Configuration Manager,

versão 4.2. A distribuição e a instalação do Blocos de Pacote de Software podem

ser executadas por meio de computadores que estejam executando o Tivoli

Management Framework.

Implementar o Tivoli Workload Scheduler para Aplicativos por meio desse formato

de pacote fornece o seguinte conjunto de benefícios:

v Implementação não apenas de arquivo e diretórios, mas também de elementos

do ambiente, tais como INI, registros, ícones e mais.

v DESFAZER versus REMOVER para cada um dos elementos incorporados acima

no pacote de software.


v Utilização de variáveis (incorporadas, com destino específico ou predefinido) no

pacote.

v Utilização de condições no pacote de software por meio de seções específicas

para plataformas específicas.

v Utilização ilimitada de programas de usuário genéricos, para diferentes fases de

execução e gerenciamento personalizado dos códigos de retorno do programa.

v Reinicialização ou reinício de nós de extremidade durante a execução de ações

SP.

Com esse método você pode instalar somente um método de acesso por bloco de

pacote de software. Se você utilizar vários SPBs para instalar mais métodos de

acesso, tenha cuidado ao usar nomes diferentes para os pacotes.

Se você optar por orientar o processo de instalação a partir do Tivoli Desktop e o

seu mecanismo do Tivoli Workload Scheduler na estação de trabalho de destino for

a versão 8.2, certifique-se de que saiba o nome do diretório de instalação do

mecanismo antes de iniciar.

Para ser instalado por meio da distribuição de software, todos os SPBs do Tivoli

Workload Scheduler para Aplicativos exigem as seguintes opções:

Tabela 4. Opções Exigidas para Instalar Todos os SPBs do Tivoli Workload Scheduler para

Aplicativos por meio da Distribuição de Software.

Opção Descrição

INSTALL_DIR O caminho para o diretório maestro (que contém os métodos)

LJUSER O nome do usuário do Tivoli Workload Scheduler que vai

executar o método de acesso.

De forma adicional, o SPB para o método de acesso do PeopleSoft exige as

seguintes opções:

Tabela 5. Opções adicionais exigidas para instalar o método de acesso para o PeopleSoft

SPB por meio da Distribuição de Software.

Opção Descrição

INSTALL_BEND Especifica a versão do ambiente PeopleTools. Ele pode ser um

ou mais dos seguintes itens:

PS70MR2

PeopleTools 7.0x e Merant NetExpress 2.x

PS70MR3


PS70WB4

PeopleTools 7.0x e MF COBOL Workbench 4.x

PS75MR2


PS75MR3




Várias entradas devem ser separadas por ponto-e-vírgula.


Tabela 5. Opções adicionais exigidas para instalar o método de acesso para o PeopleSoft

SPB por meio da Distribuição de Software. (continuação)

Opção Descrição

PS70MR2_CBLDIR O caminho do diretório COBOL para PeopleTools 7.0x e Merant

NetExpress 2.x. Utilize somente se você especificou esse

ambiente.



ambiente.

PS70WB4_CBLDIR O caminho do diretório COBOL para PeopleTools 7.0x e MF

COBOL Workbench 4.x. Utilize somente se você especificou esse

ambiente.



ambiente.



ambiente.

PS81_APIDIR O caminho do diretório do External APIs para PeopleTools 8.1x.

Utilize somente se você especificou esse ambiente.

PS84_APIDIR O caminho do diretório cliente do PeopleSoftpara PeopleTools

8.4x. Utilize somente se você especificou esse ambiente.

O produto inclui também um SPB contendo Java Virtual Machine. Isso é útil para

instalar o Editor de opções com esse método. Esteja ciente, contudo, de que essa

Java Virtual Machine não pode substituir a Java Virtual Machine exigida para a

execução do produto PeopleSoft.

Para instalar um pacote de software, você deve executar as seguintes ações

utilizando a linha de comandos ou o Tivoli Desktop:

1. Importe o SPB para um Perfil de Pacote de Software. Faça isso para o SPBs:

v Dos métodos de acesso que deseja instalar

v Da JVM (Java Virtual Machine)

v Do Editor de Opções (para execução, é necessário que os outros dois SPBs já

estejam instalados)2. Instale o Perfil do Pacote de Software nos nós de extremidade gerenciados pelo

Tivoli Framework.

O seguinte exemplo mostra como instalar o SPB do método de acesso do R/3 em

uma estação de trabalho com o Windows.

1. Importe o arquivo do SBP TWS4APPS_R3BATCH_I386NT.SPB para um Perfil de

Pacote de Software do Tivoli Framework chamado, por exemplo,

TWS4APPS_R3BATCH_I386NT.8.2. Utilize o seguinte comando:

wimpspo -c PROFILE_MANAGER -f <SOURCE_PATH>/TWS4APPS_R3BATCH_I386NT.SPB -t build

-p <DEST_PATH_LOCAL>/TWS4APPS_R3BATCH_I386NT.SPB TWS4APPS_R3BATCH_I386NT.8.2

Com esse comando, o arquivo SOURCE_PATH/TWS4APPS_R3BATCH_I386NT.SPB é

importado para o Perfil de Pacote de Software chamado

TWS4APPS_R3BATCH_I386NT.8.2 que pertence ao gerenciador de perfil

PROFILE_MANAGER do Tivoli Framework.

O TWS4APPS_R3BATCH_I386NT.8.2 deve fazer referência ao

<DEST_PATH_LOCAL>/TWS4APPS_R3BATCH_I386NT.SPB como o arquivo local

contendo as informações necessárias.


Nota: Para instalar uma instância adicional desse SPB na mesma estação de

trabalho, você deve renomear o SPB.

2. Instale o Perfil de Pacote de Software TWS4APPS_R3BATCH_I386NT.8.2 em um

computador com nome do host epw2000 (que também deve ser definido como

um nó de extremidade do Tivoli Framework). Utilize o seguinte comando:

winstsp -D INSTALL_DIR=TWShome -D LJUser=TWSuser TWS4APPS_R3BATCH_I386NT.8.2

epw2000

Quando o log de instalação, nesse caso um arquivo chamado

$BINDIR/../swdis/work/TWS4APPS_R3BATCH_I386NT.log, mostra uma mensagem

Operação Bem-sucedida, o processo de instalação pode ser considerado concluído.

O seguinte exemplo mostra como instalar o SPB da JVM para AIX em um sistema

AIX. Observe que um pacote de software JVM diferente existe para cada

plataforma.

1. Importe o pacote de software chamado JRE131_AIX.SPB para um Perfil de

Pacote de Software chamado JRE131AIX.8.2. Utilize o seguinte comando:

wimpspo -c PROFILE_MANAGER -f <SOURCE_PATH>/JRE131_AIX.SPB -t build

-p <DEST_PATH_LOCAL>/JRE131_AIX.SPB

JRE131AIX.8.2

2. Instale o Perfil de Pacote de Software JRE131AIX.8.2 em um computador com o

nome do host epAIX. Utilize o seguinte comando:

winstsp -D INSTALL_DIR=TWShome -D LJUser=TWSuser JRE131AIX.8.2 epAIX

O seguinte exemplo mostra como instalar o SPB do Editor de Opções no mesmo

sistema AIX. Observe que o SPB do Editor de Opções é o mesmo para todas as

plataformas.

1. Importe o pacote de software chamado OPTED.SPB para um Perfil de Pacote de

Software chamado OPTED.8.2. Utilize o seguinte comando:

wimpspo -c PROFILE_MANAGER -f <SOURCE_PATH>/OPTED.SPB -t build

-p <DEST_PATH_LOCAL>/OPTED.SPB

OPTED.8.2

2. Instale o Perfil de Pacote de Software OPTED.8.2 em um computador com o

nome do host epAIX. Utilize o seguinte comando:

winstsp -D INSTALL_DIR=TWShome -D LJUser=TWSuser OPTED.8.2 epAIX

Desinstalando o Produto

Desinstalar o Tivoli Workload Scheduler para Aplicativos de uma estação de

trabalho requer que você siga o mesmo procedimento usado para a instalação:

v Se você instalou por meio do ISMP, desinstale usando um método ISMP

compatível.

v Se você instalou por meio da distribuição de software, desinstale utilizando o

mesmo método.

Se você planeja desinstalar o método de acesso para o Oracle eBusiness suite, esteja

ciente de que você terá que concluir a remoção do produto, manualmente.

Consulte “Completando a Remoção do Método de Acesso para Oracle e-Business

Suite” na página 24.

Em certas condições, quando você desinstala o produto totalmente, um diretório

chamado _xauninst pode ser esquecido pelo processo de desinstalação. Caso isso

ocorra, remova-o manualmente.


Removendo uma Instalação por meio do ISMP

Para desinstalar o produto seguindo um instalação ISMP:

v No Windows:

1. Selecione Adicionar/Remover Programas no Painel de Controle.

2. Localize IBM Tivoli Workload Scheduler para Aplicativos (nome do usuário).

3. Clique em Remover. Uma janela Desinstalador é aberta. Nela é possível

escolher se deseja excluir o produto inteiro ou um ou mais dos métodos de

acesso que foram instalados como recursos do produto.v No Unix:

1. Vá para o diretório <TWShome>/methods.

2. Execute o seguinte comando :

../_xauninst/uninstaller

Uma janela Desinstalador é aberta. Nela é possível escolher se deseja excluir

o produto inteiro ou um ou mais dos métodos de acesso que foram

instalados como recursos do produto.

Removendo uma Instalação por meio do Tivoli Configuration

Manager

Para desinstalar o produto utilizando a distribuição de software, use o Tivoli

Desktop ou o comando wremovsp.

Para ver uma lista de pacotes instalados no computador por meio da distribuição

de software, use um dos dois procedimentos a seguir:

v Utilize o Tivoli Inventory, incluído no Tivoli Configuration Manager, versão 4.2,

para executar a consulta chamada CM_STATUS_QUERY e listar qual método de

acesso que está instalado em qual estação de trabalho. Consulte a documentação

do Tivoli Inventory para obter referências.

v Visualize os arquivos de log da Distribuição de Software no computador. Cada

pacote de distribuição de software tem seu próprio arquivo de log — um

arquivo de texto que registra o histórico de instalação e desinstalação do pacote.

Por exemplo, o arquivo de log em um sistema AIX do pacote de método de

acesso do R/3, r3batch_tws_aix.log, é armazenado no diretório

$BINDIR/../swdis/work (em que $BINDIR é um caminho do ambiente do Tivoli

Framework inicializado pela execução do comando /etc/Tivoli/setup_env.sh).

Consulte a documentação do Tivoli Software Distribution para obter detalhes.

Completando a Remoção do Método de Acesso para Oracle

e-Business Suite

Depois finalizar o processo de desinstalação, execute as seguintes etapas:

1. Restaure APPLSYS.env para o seu conteúdo original, removendo a cadeia MCM

das variáveis APPLSHAR e APPLFUL. Por exemplo:

APPLSHAR=’ALR FF MCM’

deve ser

APPLSHAR=’ALR FF’

2. Remova os seguintes arquivos:

v <TWShome>/methods/MCMAGENT

v <TWShome>/catalog/C/mcm.cat

v MCMLJ, MCMSTAT e MCMTJ localizados no diretório $MCM_TOP/bin


v MCMprod.txt localizado no diretório $APPL_TOP/admin

v Todos os arquivos de opções


Capítulo 3. Definindo Opções com o Editor de Opções

Um arquivo de opções é um arquivos de texto que contém um conjunto de opções

de configurações necessário para executar um agente estendido. As opções são

gravadas uma por linha e têm o seguinte formato:

OPTION=VALUE

sem espaço antes, depois ou entre as palavras-chave.

As opções são utilizadas para alterar as propriedades de tempo de execução do

método de acesso, tais como a senha necessária para conectar-se a um sistema

externo (como SAP R/3) ou o nome de login para essa conexão.

Todos os métodos de acesso usam dois tipos de arquivos de opções. São eles:

Arquivo de Opções Globais

Um arquivo de configuração comum para uma instância particular de um

método de acesso, cujas definições afetam todas as estações de trabalho do

agente estendido, definidas nessa instância. Ele lista as opções, como

LJuser (que fornece o nome do usuário que executa o método de acesso) e

IFuser (que fornece o nome do usuário que executa o método para

recuperar informações do job), que são, em parte, inseridas no momento da

instalação. O nome desse arquivo é <nome_do_método_de_acesso>.opts.

Por exemplo, para uma instalação do método de acesso para R/3, o nome

do arquivos de opções globais é r3batch.opts.

Arquivo de Opções Locais

Um arquivo de configuração que é específico para cada estação de trabalho

de agente estendido dentro de uma instância particular de um método de

acesso. Toda estação de trabalho de agente estendido, exceto para z/OS,

deve ter um arquivo de opções locais com suas próprias opções de

configuração. O nome desse arquivo é nome da estação de

trabalho_<nome_do_método_de_acesso>.opts.

Por exemplo, se uma instalação do método de acesso para R/3 incluir duas

estações de trabalho de agente estendido, CPU1 e CPU2, os nomes dos

arquivos de opções locais serão, respectivamente, CPU1_r3batch.opts e

CPU2_r3batch.opts.

Os arquivos devem estar localizados no subdiretório methods da instalação do

Tivoli Workload Scheduler e são lidos quando o agente estendido e inicializado. As

opções são específicas para cada método de acesso. Para saber as opções de cada

método de acesso, consulte:

v Capítulo 8, “Referência do Arquivo de Opções MCMAGENT”, na página 53 para

Oracle

v Capítulo 11, “Tarefas de Pós-Instalação”, na página 65 para PeopleSoft

v Capítulo 20, “Arquivos de Opções do Método de Acesso do R/3”, na página 119

para R/3

v Capítulo 25, “Configuração e Operação”, na página 151 para z/OS

Você pode gravar os arquivos de opções com um editor de texto de sua escolha ou

criá-los com o Editor de Opções fornecido com o produto.


Antes de concluir a instalação, o Tivoli Workload Scheduler para Aplicativos

opcionalmente inicia o Editor de Opções para que você defina as opções locais,

enquanto alguns dos valores digitados durante o processo são usados para criar

um arquivo de opções globais. Para iniciar o Editor de Opções posteriormente, vá

para o subdiretório methods da instalação do Tivoli Workload Scheduler e execute

o arquivo opted.exe (Windows) ou o comando opted.bin (Unix).

Se você instalou o produto por meio do Tivoli Configuration Manager, inicie o

Editor de Opções com um destes comandos:

v TWShome\methods\opted\opted.bat no Windows

v TWShome/methods/opted/opted.sh no Unix

O Editor de Opções carrega automaticamente todos os arquivos de opções globais

e locais existentes. Além de editar arquivos existentes, você pode criar arquivos de

opções locais para as estações de trabalho de agente estendido definidas

recentemente.

O Editor de Opções fornece três visualizações possíveis de um arquivo de opções:

Simples

Exibe as opções como uma seqüência de guias e permite editar uma opção

por vez. Para visualizar ou editar uma opção, selecione a guia com o nome

da opção para exibir o campo para o valor. Esse é o modo mais fácil de

editar opções, pois você vê apenas o valor real que será usado no arquivo.

Valores herdados ou padrão não são exibidos. As opções obrigatórias estão

em amarelo e são marcadas por um asterisco(*).

Tabela Fornece uma exibição em tabela de todas as opções para um arquivo

selecionado. Para cada opção, as seguintes colunas são exibidas:

Valor O valor especificado no arquivo.

Valor Padrão

O valor usado pelo método se nenhum outro valor estiver

disponível.

Valor Herdado

O valor obtido do arquivo de opções globais, se a herança for

suportada pelo método.

Valor Real

O valor usado realmente no tempo de execução. A ordem de uso é:

valor, se disponível; valor herdado, se suportado; valor padrão.

As opções obrigatórias estão no plano de fundo amarelo.

Texto Exibe um arquivo de opções no formato comum, apresentando somente as

opções que têm um valor. Essa exibição é geralmente usada como objetivos

de visualização, como arquivos mostrados com especificação somente

leitura. Os campos de senha são mostrados no formato criptografado.

A janela do Editor de Opções é composta por três áreas principais, como mostrado

em Figura 17 na página 29. São elas:

Árvore de Arquivos de Opções

Mostra a lista de todos os arquivos de opções existentes, agrupados por

método.

Descritor de Opções

Fornece uma descrição da seleção atual.


Exibição de Opções de Arquivos

Exibe as opções de um arquivo selecionado em qualquer uma das três

exibições disponíveis.

Certifique-se de que o Editor de Opções não esteja em execução antes de incluir ou

atualizar os recursos ou as instâncias de uma instalação do Tivoli Workload

Scheduler para Aplicativos existente.

Você deve restringir o acesso ao executável do Editor de Opções. Se você tiver

várias instalações de um agente estendido, é possível aumentar a segurança,

mantendo somente uma cópia do Editor de Opções (na estação de trabalho mestre,

por exemplo). Utilizando o FTP, você pode gerenciar todos os arquivos de opções

criptografados de um único local.

Criando um Arquivo de Opções Locais

Enquanto os arquivos de opções globais são gerados sempre que você instala uma

instância de um método, você pode criar arquivos de opções locais no momento

em que desejar, antes ou depois de definir uma estação de trabalho de agente

estendido. Para fazer isso com o Editor de Opções:

1. Clique em File→New na barra de menu. A janela Novo Arquivo de Opções é

exibida.

Figura 17. O Editor de Opções

Capítulo 3. Definindo Opções com o Editor de Opções 29

2. Grave o nome de uma estação de trabalho de agente estendido que você

acabou de definir ou que planeja definir.

3. Selecione um método de acesso a partir daqueles instalados no menu

drop-down. O novo arquivo de opções terá o nome :

<nome_da_estação_de_trabalho_de_agente_estendido>_<nome_do_método>.opts.

4. Comece a inserir os valores para as opções.

Herança de Valor da Opção

Essa propriedade está disponível atualmente apenas para r3batch. Ela implica que

os arquivos de opções locais podem herdar valores existentes de opções

semelhantes no arquivo de opções globais (r3batch.opts). De fato, para um método

de acesso, as opções são listadas duas vezes: uma como global e outra como local.

Se a opção local não listar seu próprio valor, então aquela global equivalente é

utilizada. Por outro lado, se ela existir, o valor local será sempre mandatório em

relação ao valor global.

Por exemplo, você deseja definir o mesmo usuário e a mesma senha do R/3 para

todos os sistema do R/3. Utilizando essa propriedade, em vez de gravar o mesmo

valor em cada arquivo de opções locais, você pode gravá-lo uma vez no arquivo

de opções globais.


Capítulo 4. Definindo as Estações de Trabalho de Agente

Estendido

Uma definição de estação de trabalho de agente estendido é necessária para cada

entidade do método de acesso pela qual o Tivoli Workload Scheduler irá planejar e

ativar os jobs. As estações de trabalho de agente estendido são definidas no modo

padrão e incluem o nome do host do agente estendido e o nome do método.

Para ativar um job em uma estação de trabalho de agente estendido, o Tivoli

Workload Scheduler executa o método de acesso, transmitindo as informações

sobre o job. O método de acesso comunica-se com a instância do sistema z/OS,

R/3, PeopleSoft ou Oracle em particular e monitora o job até a conclusão,

gravando as informações de progresso e de status do job no arquivo de lista

padrão de job.

Criando uma Estação de Trabalho com o Job Scheduling Console

Para definir uma estação de trabalho de agente estendido com o Job Scheduling

Console, siga estas etapas:

1. Na janela principal, selecione o ícone Nova Estação de Trabalho na barra de

ferramentas superior ou clique com o botão direito do mouse no nome do

mecanismo do Tivoli Workload Scheduler e selecione Nova Estação de

Trabalho no menu drop down. A janela Propriedades - Estação de Trabalho no

Banco de Dados é exibida.

2. Complete os campos utilizando as informações na Tabela 6 na página 32.

3. Clique em OK para salvar e fechar a janela.

Figura 18. Definindo uma Estação de Trabalho com o Job Scheduling Console


A tabela a seguir mostra como completar os campos da janela de propriedades da

estação de trabalho, dependendo da estação de trabalho de agente estendido que

você deseja definir.

Tabela 6. Como Completar os Campos da Janela Propriedades - Estação de Trabalho no Banco de Dados

Campo Descrição por Método de Acesso

PeopleSoft z/OS Oracle eBusiness Suite R/3

Nome O nome para a estação de trabalho de agente estendido. Para todos os métodos de acesso

(exceto aquele para o z/OS que é sempre limitado para 8), o nome pode conter até 8 ou 16

caracteres alfanuméricos, dependendo da utilização expandida ou não expandida dos

bancos de dados. Isso pode incluir caracteres de traço e sublinhado, mas ele deve começar

com uma letra.

Para todos os métodos de acesso, esse nome deve ser consistente com o nome do arquivo de

opções associado à estação de trabalho. Isto é, se o arquivo de opções (normalmente criado

com o Editor de Opção) for chamado de <mycpu>_<mymethod>.opts, então mycpu e o Nome

devem ser iguais.

Nó null. O nome do nó ou o

endereço IP do

sistema z/OS. Nomes

de domínio

completamente

qualificados são

aceitos.

null. null.

Porta TCP Qualquer número

diferente de 0.

O endereço TCP

(número da porta) do

gateway do z/OS no

sistema z/OS. Insira o

mesmo valor como na

variável SYSTSIN

PORT descrita em

Tabela 21 na página

145.

Qualquer número

diferente de 0.

Qualquer número

diferente de 0.

Sistema Operacional Selecione OTHER.

Domínio O nome do domínio do Tivoli Workload Scheduler da estação de trabalho do host. Se você

precisar de ajuda para encontrá-lo, clique na elipse (...) para obter uma lista dos domínios

existentes. Clique em Utilizar Master, se você souber que a estação de trabalho do host está

no mesmo domínio que o gerenciador de domínio do master.

Fuso Horário Se a rede do Tivoli Workload Scheduler estiver utilizando a opção Fuso Horário, selecione o

fuso horário apropriado na lista drop down. Deixe o campo em branco se esse não for o

caso.

Descrição Uma descrição textual de formato livre da estação de trabalho (até 40 caracteres).

Comunicação SSL Não utilizada em estações de trabalho de agente estendido.

Atrás do Firewall Não utilizada em estações de trabalho de agente estendido.

Porta Segura Não utilizada em estações de trabalho de agente estendido.

Tipo de Estação de

Trabalho

Selecione Agente Estendido.

AutoLink Não utilizada em estações de trabalho de agente estendido.

Ignorar Selecione essa opção somente se quiser que o Tivoli Workload Scheduler ignore essa

definição de estação de trabalho. Essa opção é útil se desejar predefinir fluxos de job, jobs e

objetos para um sistema ainda não chegou.

Status Completo Não utilizada em estações de trabalho de agente estendido.


Tabela 6. Como Completar os Campos da Janela Propriedades - Estação de Trabalho no Banco de

Dados (continuação)

Campo Descrição por Método de Acesso

PeopleSoft z/OS Oracle eBusiness Suite R/3

Resolver

Dependências

Não utilizada em estações de trabalho de agente estendido.

Servidor Não utilizada em estações de trabalho de agente estendido.

Método de Acesso psagent Dependendo da

interface de

planejamento do job;

uma das seguintes:

mvsca7 Para ativar e

monitorar os

jobs do z/OS

por meio do

CA-7.

mvsjes Para ativar e

monitorar os

jobs do z/OS

por meio do

JES2 ou do

JES3.

mvsopc

Para ativar e

monitorar os

jobs do z/OS

por meio do

OPC ou do

Tivoli

Workload

Scheduler

para z/OS.Nota: O nome faz

distinção de

maiúsculas e

minúsculas (deve

estar em letra

minúscula) no Unix.

MCMAGENT

Nota: O nome faz

distinção de maiúsculas

e minúsculas e deve

estar em letra

maiúscula.

r3batch

Nota: O nome faz

distinção de

maiúsculas e

minúsculas (deve

estar em letra

minúscula) no Unix.

Host O nome do sistema de host do Tivoli Workload Scheduler. Esse é o agente tolerante a falhas

do Tivoli Workload Scheduler ou o agente padrão no qual o agente estendido está instalado.

Clique em elipse (...) para ver uma lista de hosts existentes.

Criando uma Estação de Trabalho da Linha de Comando

As definições de estação de trabalho de agente estendido podem ser feitas na linha

do comando do Tivoli Workload Scheduler, utilizando o programa composer. O

exemplo a seguir mostra uma definição para a estação de trabalho de agente

estendido chamada MVSCPU que utiliza o método de acesso do mvsjes.

cpuname MVSCPU description "zOS extended agent"

os other

node mvsesa36.rome.tivoli.com

tcpaddr 5000

domain masterdm

for maestro

Capítulo 4. Definindo as Estações de Trabalho de Agente Estendido 33

type x-agent

host ROCIOUS

access mvsjes

end

Consulte IBM Tivoli Workload Scheduler - Guia de Referência para obter mais

detalhes sobre como definir as estação de trabalho com o composer.

Definindo Estações de Trabalho para Planejamento Ponto a Ponto

Planejar em um ambiente ponto a ponto significa que no Tivoli Workload

Scheduler para z/OS você está planejando e monitorando jobs executados

fisicamente em estações de trabalho do Tivoli Workload Scheduler.

Para esse ponto, as estações de trabalho de agente estendido devem ser definidas

adequadamente como o estação de trabalho tolerante à falha no Tivoli Workload

Scheduler para z/OS.

Uma estação de trabalho tolerante à falha é uma definição de Tivoli Workload

Scheduler para z/OS de um agente do Tivoli Workload Scheduler existente na rede

distribuída. O agente do Tivoli Workload Scheduler é o local em que o job

associado à estação de trabalho tolerante à falha será executado na rede

distribuída.

Para definir a estação de trabalho de agente estendido no Tivoli Workload

Scheduler para z/OS, você deve:

1. Definir a estação de trabalho na instrução de inicialização do CPUREC.

2. Incluir a mesma definição de estação de trabalho no banco de dados por meio

do ISPF ou do Job Scheduling Console. Para obter uma descrição sobre como

definir a estação de trabalhando utilizando o Job Scheduling Console, consulte

o Guia do Usuário Tivoli Job Scheduling Console.

Criando a Instrução CPUREC

Primeiro, crie a instrução CPUREC para a estação de trabalho na instrução de

inicialização TOPOLOGY. A instrução de inicialização TOPOLOGY é utilizada para definir

parâmetros listados à topologia de rede conectada ao Tivoli Workload Scheduler.

Tal instrução de topologia de rede é constituída de uma ou mais instruções (uma

para cada domínio) DOMREC que descrevem a topologia de rede distribuída e por

várias instruções CPUREC, uma para cada estação de trabalho tolerante à falha.

O exemplo a seguir mostra uma instrução CPUREC para a estação de trabalho de

agente estendido do R/3 chamada R3XA. O agente estendido é hospedado por um

agente do Tivoli Workload Scheduler chamado TWSA, que é também o gerenciador

de domínio do DOMAIN1.

****************TPLGINFO MEMBER ***************************

/*********************************************************************/

/* DOMREC: Domain definition */

/*********************************************************************/

DOMREC DOMAIN(DOMAIN1)

DOMMNGR(TWSA)

DOMPARENT(MASTERDM)

/*********************************************************************/

/* CPUREC: Extended agent workstation definition */

/*********************************************************************/

CPUREC CPUNAME(R3XA)

CPUOS(OTHER)

CPUNODE(NODE1)


CPUDOMAIN(DOMAIN1)

CPUHOST(TWSA)

CPUTYPE(XAGENT)

CPUACCESS(r3batch)

CPUUSER(TWSuser)

CPUTZ(’Europe/Rome’)

/*********************************************************************/

/* CPUREC: Domain manager workstation definition */

/*********************************************************************/

CPUREC CPUNAME(TWSA)

CPUNODE(NODE1)

CPUAUTOLINK(ON)

CPUDOMAIN(DOMAIN1)

CPUTYPE(FTA)

CPUUSER(TWSuser)

CPUTZ(’Europe/Rome’)

As seguintes palavras-chave definem o R3XA como um agente estendido:

CPUACCESS

O método de acesso de agente estendido. Para R/3, é r3batch.

CPUHOST

O nome da estação de trabalho do Tivoli Workload Scheduler que hospeda

o agente estendido. Não pode ser outro agente padrão ou agente

estendido.

CPUTYPE

O tipo de estação de trabalho. Para um agente estendido, ele deve ser

XAGENT.

Para obter informações adicionais sobre o CPUREC, consulte Personalização e Ajuste do

Tivoli Workload Scheduler para z/OS.

Definindo a Estação de Trabalho com ISPF

O Figura 19 na página 36 mostra a definição do ISPF para o R3XA.

No ISPF (ou no Job Scheduling Console), defina a estação de trabalho como

computador automático e defina o campo Estação de Trabalho FT para Y. É a

instrução CPUREC com três palavras-chave descrita na seção anterior que fornece a

especificação do agente estendido.

Nota: Certifique-se de gravar a instrução CPUREC antes de definir o ISPF ou o Job

Scheduling Console, pois eles sozinhos não têm efeito sem a instrução

CPUREC.

Capítulo 4. Definindo as Estações de Trabalho de Agente Estendido 35

-------------- CRIANDO INFORMAÇÕES GERAIS SOBRE UMA ESTAÇÃO DE TRABALHO --------------

Command ===>

Insira o comando R para recursos A para disponibilidade ou M para método de acesso

acima ou insira os dados abaixo:

WORK STATION NAME ===> R3XA

DESCRIPTION ===> Agente estendido para o método de acesso do R/3____________________

WORK STATION TYPE ===> C G Geral, C Computador, P Impressora

REPORTING ATTR ===> A A Automático, S Inicialização e conclusão manual

C Conclusão apenas, N Não relatado

FT Work station ===> Y Estação de trabalho FT, Y ou N

PRINTOUT ROUTING ===> SYSPRINT O ddname do conjunto de dados de impressão de

planejamento diário

SERVER USAGE ===> N Utilização do servidor paralelo C , P , B ou N

Opções:

SPLITTABLE ===> N Interrupção de operação permitida, Y ou N

JOB SETUP ===> N Edição de JCL permitida, Y ou N

STARTED TASK, STC ===> N Suporte à tarefa iniciado, Y ou N

WTO ===> N WTO automático, Y ou N

DESTINATION ===> ________ Nome do destino

Padrões:

TRANSPORT TIME ===> 00.00 Hora a estação de trabalho anterior HH.MM

DURATION ===> ________ Duração de uma operação normal HH.MM.SS

Figura 19. Definindo uma Estação de Trabalho de Agente Estendido


Capítulo 5. Definindo os Jobs de Agente Estendido

Este capítulo explica como definir os jobs do Tivoli Workload Scheduler associados

aos jobs externos que você deseja executar por meio dos agentes estendidos.

Para executar e monitorar um job do PeopleSoft, R/3, Oracle ou z/OS com o Tivoli

Workload Scheduler, o agente estendido (ou o método de acesso) requer a

definição de job do Tivoli Workload Scheduler, em que você especifica o job

externo que pretende planejar, a estação de trabalho (também definida no Tivoli

Workload Scheduler) na qual ele deve ser executado e as ações de recuperação

desejadas. Para definir o job, você pode utilizar:

v O Tivoli Job Scheduling Console

v A linha de comandos do Tivoli Workload Scheduler

Se você estiver fazendo o planejamento em um ambiente ponto a ponto, para

definir o job será necessário utilizar os diálogos ISPF do Tivoli Workload Scheduler

para z/OS. Além disso, você deve criar um membro no SCRIPTLIB com uma

instrução JOBREC para o job.

Os jobs de agente estendido são incluídos nos fluxos de job e planejados como

qualquer outro job no Tivoli Workload Scheduler e no Tivoli Workload Scheduler

para z/OS.

Definindo Jobs com o Job Scheduling Console

As etapas descritas aqui para definir um job de agente estendido são comuns a

todos os métodos de acesso. Além disso, o método de acesso para o R/3 fornece

recursos complementares se você utilizar as etapas alternativas descritas em

“Utilizando Janelas Específicas do SAP do Job Scheduling Console” na página 102.

Para todos os métodos de acesso, siga estas etapas:

1. Na lista Ações da janela principal do Job Scheduling Console, selecione Nova

Definição de Job.

2. Selecione um mecanismo do Tivoli Workload Scheduler e, a partir da lista

resultante, clique em Tarefa de Agentes Estendidos. A página Geral da janela

Propriedades - Definição de Job é exibida.


3. Nessa página, você fornece informações sobre o job do Tivoli Workload

Scheduler que irá orientar o job externo. Complete os campos nessa janela com

a ajuda da tabela a seguir.

Tabela 7. A Página Geral da Janela Propriedades - Definição de Job (Descrição dos

Campos).

Campo Descrição

Tipo de Tarefa Esse é um campo somente-leitura e pode declarar Tarefa de Agente

Estendido.

Nome O nome do job do Tivoli Workload Scheduler que você está

definindo. Esse job irá orientar o job de aplicativo externo, cujo nome

será fornecido na próxima página desta janela. O nome pode conter

até 8 caracteres alfanuméricos, se o banco de dados não estiver

expandido ou 40 se estiver expandido. Ele pode incluir traços e

caracteres de sublinhado, mas deve ser iniciado com uma letra.

Espaços embutidos não são permitidos. Ele pode ser o mesmo do

nome do job externo, tão longo quanto for válido no Tivoli Workload

Scheduler.

Estação de

Trabalho

O nome da estação de trabalho do agente estendido na qual o job

deve ser executado. Você pode clicar no botão de elipse (...) para

exibir a janela Localizar e selecionar uma estação de trabalho

disponível.

Descrição Uma descrição em texto do job de até 64 caracteres alfanuméricos.

Esse campo é opcional.

Figura 20. Página Geral da janela Propriedades - Definição de Job.


Tabela 7. A Página Geral da Janela Propriedades - Definição de Job (Descrição dos

Campos). (continuação)

Campo Descrição

Login O nome do usuário necessário para executar o job no Tivoli Workload

Scheduler. Normalmente, esse é o valor do parâmetro LJuser,

especificado durante a instalação do Tivoli Workload Scheduler para

Aplicativos, que está no arquivo de opções para o método. Deve ser

um usuário válido na estação de trabalho do host do Tivoli Workload

Scheduler que deve ser capaz de acessar o produto externo. É

necessário planejar o job no Tivoli Workload Scheduler para que ele

seja mostrados nas exibições do Tivoli Workload Scheduler.

De modo alternativo, clique em Incluir Parâmetro para incluir

quaisquer parâmetros definidos ao ID de logon.

Opções de

Recuperação

A resposta automática do Tivoli Workload Scheduler se o job terminar

de forma anormal. O padrão é Parar. Para obter informações sobre

opções de recuperação, consulte o Tivoli Workload Scheduler - Guia de

Referências do .

Mensagem Um texto de mensagem ou um aviso opcional que é exibido quando

o job termina de forma anormal. Nenhum aviso predefinido é aceito

aqui.

Job O nome de um job de recuperação que é iniciado automaticamente

quando o job termina de forma anormal. Clique em elipse (...) para

exibir a janela Localizar e listar os jobs existentes.

Estação de

Trabalho

O nome da estação de trabalho que tem o job de recuperação.

4. Clique em Tarefa para continuar na próxima página. A página Tarefa da janela

é exibida.

Figura 21. A página Tarefa da janela Propriedades - Definição de Job.

Capítulo 5. Definindo os Jobs de Agente Estendido 39

5. Nessa página você fornece informações sobre o job externo (ou tarefa) que será

orientado pelo job definido na página anterior. Observe que a tarefa deve ter

sido definida no aplicativo externo. Complete os campos nessa janela com a

ajuda da tabela a seguir.

Tabela 8. A página Tarefa da janela Propriedades - Definição de Job (Descrição dos

Campos).

Campo Descrição

Tipo de Tarefa Esse é um campo somente-leitura e pode declarar Tarefa de

Agente Estendido.

Comando As especificações para o job externo (tarefa). Cada aplicativo

externo tem um conjunto de parâmetros diferente:

v Para jobs de Aplicativos Oracle, consulte “Parâmetros da

Cadeia de Tarefas para Jobs do Oracle Applications” na página

49.

v Para jobs do Peoplesoft, consulte “Parâmetros de Cadeia de

Tarefas para Jobs do PeopleSoft” na página 77.

v Para jobs do R/3, consulte “Parâmetros da Cadeia de Tarefas

para Jobs do R/3” na página 110.

v Para jobs do z/OS, consulte “Sintaxe de Definição de Tarefas

para Jobs do z/OS Planejados com o Tivoli Workload

Scheduler” na página 153.

Grave os parâmetros em uma cadeia com o seguinte formato

-parameter1 value1 -parameter2 value2...-parametern valuen

Clicar em Incluir Parâmetro... exibe a janela Localizar

Parâmetros, em que você pode listar e incluir parâmetros

predefinidos do Tivoli Workload Scheduler no campo Comando.

Expressão de

Mapeamento de Código

de Retorno

Uma expressão lógica que define quais códigos de retorno fazem

com que a tarefa seja bem-sucedida. Você pode utilizar

operadores de comparação e lógicos. Por exemplo, a expressão

RC≥6 indica que um código de retorno maior ou igual a 6

significa que a tarefa foi bem-sucedida.

6. Clique em OK para salvar a definição do job.

Definindo Jobs com a Linha de Comandos do Tivoli Workload

Scheduler

Os jobs também podem ser definidos no linha de comando composer do Tivoli

Workload Scheduler. O seguinte exemplo relata um job do Tivoli Workload

Scheduler chamadoorajob2 executado em uma estação de trabalho de agente

estendido de aplicativos Oracle chamada ora002. Ele conecta-se ao UNIX como

orajobs e ativa um job nos aplicativos Oracle. O job de aplicativos Oracle é

chamado poxacr e seu proprietário é global. Se for necessária a recuperação, o

Tivoli Workload Scheduler executará o job recov2 e continuará o processo.

ora002#orajob2

streamlogon orajobs

scriptname "-user global

-job fnd ’application developer’ po poxacr

-prn ps4 2

-v1 ’abc’"

descrição "oracle apps job #2"

recuperação continua após recov2


Observe que os argumentos do nome_da_cadeia são diferentes de acordo com o

aplicativo. Para obter referência, consulte:

v “Parâmetros da Cadeia de Tarefas para Jobs do Oracle Applications” na página

49.

v “Parâmetros de Cadeia de Tarefas para Jobs do PeopleSoft” na página 77.

v “Parâmetros da Cadeia de Tarefas para Jobs do R/3” na página 110.

v “Sintaxe de Definição de Tarefas para Jobs do z/OS Planejados com o Tivoli

Workload Scheduler” na página 153.

Para obter informações adicionais sobre a utilização da linha de comando para

definir jobs, consulte o Tivoli Workload Scheduler - Guia de Referências.

Definindo Jobs para Planejamento Ponto a Ponto

Os jobs de agente estendido planejados para serem executados em um ambiente

ponto a ponto não podem ser definidos por meio do Job Scheduling Console ou da

linha de comando do Tivoli Workload Scheduler. Eles devem ser incluídos em

SCRIPTLIB do Tivoli Workload Scheduler para z/OS.

No painel ISPF de OPERAÇÕES do Tivoli Workload Scheduler para z/OS, os jobs de

agente estendido são definidos como qualquer outro job, mas a escolha da estação

de trabalho do job de agente estendido denota seu tipo. O seguinte exemplo

mostra a definição de um job chamado SAPJOB. Esse é o job do Tivoli Workload

Scheduler para z/OS que orientará a execução de um job do R/3 (chamado

BAPRINT46B conforme pode ser visto no exemplo a seguir). Ele é mostra como um

job de agente estendido, apenas por que a estação de trabalho associada é uma

estação de trabalho de agente estendido chamada R3XA.

Para cada job, um membro deve ser criado em SCRIPTLIB do Tivoli Workload

Scheduler para z/OS com detalhes sobre o job em uma instrução JOBREC. Um

membro SAPJOB foi criado para o job no exemplo anterior. Ele contém uma

instrução JOBREC como esta:

JOBREC

JOBCMD(’/-job BAPRINT46B -user MAESTRO -i 14160001 -c C’)

JOBUSR(twsila)

A cadeia em JOBCMD é lida e interpretada pelo método de acesso antes da execução

do job. O job desse exemplo, BAPRINT46B, foi definido anteriormente em R/3 e

atribuído com um ID de 14160001, manualmente transcrito em JOBCMD.

--------------------------------- OPERAÇÕES -----------------Row 1 a 1 de 1

Comando ===> Scroll ===> PAGE

Insira/Altere os dados nas linhas e/ou insira qualquer um dos seguintes

comando de linha:

I(nn) - Inserir, R(nn),RR(nn) - Repetir, D(nn),DD - Excluir

S - Selecionar os detalhes da operação, J - Editar JCL

Digite o comando TEXT acima para incluir o texto da operação na lista ou digite o comando GRAPH para

visualizar a lista em forma de

gráfico.

Aplicativo : APLL1 FTW appl

Row Oper Duração Nome do job Processadores internos Morepreds

cmd ws no. HH.MM.SS -IntExt-

’’’’ R3XA 001 00.00.01 SAPJOB___ ___ ___ ___ ___ ___ ___ ___ ___ 0 0

******************************* Base do dados ********************************

Figura 22. Definindo um Job de Agente Estendido para Planejamento Ponto a Ponto .

Capítulo 5. Definindo os Jobs de Agente Estendido 41

O seguinte exemplo é para um job do PeopleSoft. Observe que a cadeia inteira que

segue a palavra-chave JOBCMD deve estar entre aspas duplas em vez de simples.

Isso é verdadeiro somente quando os jobs do PeopleSoft estão envolvidos, pois as

aspas simples também são utilizadas na cadeia.

JOBREC

JOBCMD("/-operator PS -process XRFWIN -type ’SQR Report’ -runcontrol TWS")

JOBUSR(PsBuild)

Os argumentos do JOBCMD são diferentes de acordo com o aplicativo. Para obter

referência, consulte:

v “Parâmetros da Cadeia de Tarefas para Jobs do Oracle Applications” na página

49.

v “Parâmetros de Cadeia de Tarefas para Jobs do PeopleSoft” na página 77.

v “Parâmetros da Cadeia de Tarefas para Jobs do R/3” na página 110.

v “Sintaxe de Definição de Tarefas para Jobs do z/OS Planejados com o Tivoli

Workload Scheduler” na página 153.


Parte 2. Método de Acesso do Oracle e-Business Suite


Capítulo 6. Introdução

O IBM Tivoli Workload Scheduler para Aplicativos do Oracle e-Business Suite

oferece a habilidade de planejar os jobs do Oracle e-Business Suite, utilizando o

recurso de planejamento de job sofisticado do Tivoli Workload Scheduler.

Neste manual, os Aplicativos Oracle e o Oracle e-Business Suite são usados

alternadamente para fazer referência ao nome do mesmo produto.

O host do Tivoli Workload Scheduler, o agente estendido do Tivoli Workload

Scheduler para Oracle e-Business Suite, e a instância do Oracle e-Business Suite

devem ser instalados no mesmo nó físico.

Recursos

v Utilize as dependências de job padrão do Tivoli Workload Scheduler’ (exceto as

dependências de Abrir Arquivo).

v Planeje os jobs do Oracle e-Business Suite para serem executados em dias e

horas especificados e em uma ordem predeterminada.

v Defina a interdependência dos jobs de Aplicativos Oracle e dos jobs executados

em sistemas diferentes, como R/3 e PeopleSoft.

v Defina a interdependência dos jobs de Aplicativos Oracle e dos jobs executados

em plataformas diferentes.

v Personalize os códigos de retorno de execução do job.

Requisitos de Software

Para instalar e utilizar o IBM Tivoli Workload Scheduler para Aplicativos do Oracle

e-Business Suite, é necessário:

v Um dos seguintes sistemas operacionais suportados:

– HP-UX 11.0, 11.i

– Solaris Operating Environment Versões 7, 8, 9

– IBM AIX 4.3.3, 5.1v O seguinte software instalado:

– IBM Tivoli Workload Scheduler 7.0 ou superior

– Oracle Applications 10.7 ou Oracle e-Business Suite 11.0 ou 11.i

– Para usuário do AIX e da HP apenas, o compilador gcc para a respectiva

plataforma. Os binários do compilador gcc podem ser recuperados de várias

fontes na Web.

Para obter a lista mais recente de plataformas suportadas, entre em contato com o

Atendimento ao Cliente local.

Tarefas de Pós-instalação

Depois de instalar o produto como explicado em Capítulo 2, “Instalando o IBM

Tivoli Workload Scheduler para Aplicativos”, na página 5, execute as seguintes

etapas para concluir a instalação do método de acesso para o Oracle e-Business

Suite:


1. Efetue logon como um usuário do Oracle Applications no Unix, que tem

acesso a todos os arquivos no diretório Oracle Application Top.

2. Alterne para o diretório instalado:

cd <TWShome>/methods/OracleTMP

Nota: Se você estiver executando o banco de dados de demonstração do Oracle

Applications, substitua o arquivo APPDEMO.env nas etapas 3 e 4. 3. Modifique o arquivo APPLSYS.env do Oracle Applications como se segue:

a. Adicione MCM às variáveis APPLSHAR e APPLFULL.

APPLSHAR=’ALR FF MCM’

APPLFUL=’FND AD AX AK GL RG INV OP MCM’

b. Defina e exporte a variável shell MCM_TOP:

MCM_TOP=$APPL_TOP/mcm/integration

export MCM_TOP

c. Inclua $MCM_TOP/bin na variável PATH, inserindo as seguintes linhas na

parte inferior do arquivo APPLSYS.env:

PATH=$PATH:$MCM_TOP/bin

export PATH

4. Execute o arquivo APPLSYS.env para definir o ambiente:

. APPLSYS.env

Nota: Certifique-se de que o logon do Oracle Applications tenha permissões para

gravação nos diretórios TWShome e methods. 5. Altere a propriedade de usuário e de grupo dos arquivos instalados para o

proprietário do Oracle Application.

6. Altere o diretório para /temp/usrxit.

7. Apenas para usuários de AIX e HP:

v Devido ao formato dos objetos MCMxxx.o, você precisa utilizar o compilador

gcc na plataforma para executar as seguintes etapas. Os binários do

compilador gcc podem ser transferidos de várias fonte na Internet.

v Apenas para usuários do AIX: Personalize o script adrelink fornecido pela

Oracle para as opções de novo vínculo do gcc:

a. Localize a seguinte linha:

AIXRIOS) LDFLAGS=’-s -H512 -T512 -bhalt:4 -brtl -L$(ORACL ....’

b. Exclua

-H512 -T512 -bhalt:4 -brtl

da linha, para que ela seja semelhante a :

AIXRIOS) LDFLAGS=’-s -L$(ORACL ....’

v Certifique-se de que o compilador gcc esteja configurado no caminho do

ambiente do Proprietário do Aplicativo. Como uma opção alternativa, você

pode editar o arquivo mcm.mk enviado com o produto para gravar o

caminho completo do gcc na linha

CC="gcc".

Nota: O IBM Tivoli Workload Scheduler para Aplicativos do Oracle

e-Business Suite suporta somente a versão 2.x do compilador gcc. A

versão 3.x não é suportada. 8. Execute o script de instalação mcminstall a partir do diretório temporário.

Utilize o seguinte comando:


sh mcminstall

Uma tela do Oracle Tivoli é exibida.

9. Responda às solicitações na tela de acordo com as definições do Oracle

Applications e da instalação do Tivoli Workload Scheduler.

O processo de instalação tenta um novo vínculo com os executáveis do Tivoli

Workload Scheduler para Aplicativos, utilizando as bibliotecas compartilhadas

do Oracle Applications.

Depois da conclusão bem-sucedida do processo de vínculos, você encontrará

os seguintes executáveis no diretório $MCM_TOP/bin:

v MCMLJ

v MCMSTAT

v MCMTJ

Esses arquivos binário são criados pelo utilitário adrelink para o Oracle

Applications. Esse utilitário também registrará o MCM com um módulo no

AOL.

Se encontrar problemas durante o processo de vínculo, você deverá corrigi-los

e executar novamente a etapa correspondente, pois essa etapa é responsável

por criar os arquivos binários que ativam o Tivoli Workload Scheduler para

Aplicativos para que ele interaja com o Oracle Concurrent Manager, no envio

e na monitoração de jobs.

10. Edite o arquivo de opções. Consulte Capítulo 8, “Referência do Arquivo de

Opções MCMAGENT”, na página 53 e Capítulo 3, “Definindo Opções com o

Editor de Opções”, na página 27 para obter detalhes.

Agora a instalação está concluída. Consulte a documentação do IBM Tivoli

Workload Scheduler para saber como iniciar o Batchman, como definir estações de

trabalho e jobs e outras operações do Tivoli Workload Scheduler.

Interface Software

A interface entre Tivoli Workload Scheduler e Oracle e-Business Suite é composta

dos seguintes softwares:

MCMAGENT

O método de acesso do IBM Tivoli Workload Scheduler para Aplicativos

do Oracle e-Business Suite.

MCMLJ

Envia um job para o OCM (Oracle Concurrent Manager).

MCMSTAT

Monitora o status de um job enviado.

MCMTJ

Finaliza o job enviado, mediante o recebimento de um sinal de eliminação

do Tivoli Workload Scheduler.

mcm.mk

Um utilitário de criação de arquivo para vincular os programas acima com

o Oracle Applications.

MCMAGENT.opts

Um arquivo de opções global que contém definições de configuração para

o método de acesso. Ele é criado pelo processo de instalação do Tivoli

Workload Scheduler para Aplicativos com alguns dos valores inseridos

Capítulo 6. Introdução 47

durante a instalação. Consulte Capítulo 8, “Referência do Arquivo de

Opções MCMAGENT”, na página 53 e Capítulo 3, “Definindo Opções com

o Editor de Opções”, na página 27 para obter detalhes.

<WORKSTATION_ NAME>_MCMAGENT.opts

Um arquivo de opções local que contém as definições de configuração para

o agente estendido. Um arquivo é exigido para cada estação de trabalho de

agente estendido definida. Consulte Capítulo 8, “Referência do Arquivo de

Opções MCMAGENT”, na página 53 e Capítulo 3, “Definindo Opções com

o Editor de Opções”, na página 27 para obter detalhes.


Capítulo 7. Informações de Definição do Job

Este capítulo fornece informações para definir jobs do Oracle Applications no


Definindo Jobs no Oracle Applications

No Oracle Applications, jobs que devem ser planejados com o Tivoli Workload

Scheduler são definidos da mesma maneira que outros jobs do Oracle Applications

(e podem ser enviados ao OCM). Quando você estiver enviando o job no OCM,

especifique as informações de planejamento e de reenvio. Quando estiver enviando

um job por meio do Tivoli Workload Scheduler, o Tivoli Workload Scheduler

cuidará das informações de planejamento e reenvio.

Para definir um job, utilize os executáveis e os formatos do Define Concurrent

Program e preencha as informações de dados gerais para o job. Agora o job está

disponível para planejamento a partir do Tivoli Workload Scheduler (e pode

também ser enviado no OCM).

Executando um Único Job Simultaneamente

Se um job do Oracle Applications for planejado para ser executado mais de uma

vez no Tivoli Workload Scheduler e se o Tivoli Workload Scheduler ativá-lo

simultaneamente, os jobs serão executados normalmente. Contudo, se o usuário do

Oracle Applications especificar que o job não pode ser executado simultaneamente,

o segundo job apresentará um estado de WAIT até que o primeiro job seja

concluído.

Definindo Jobs do Oracle Applications no Tivoli Workload Scheduler

As definições de job do Tivoli Workload Scheduler são necessárias para cada job

do Oracle Applications que você pretende planejar. Os jobs do Oracle Applications

são definidos no Tivoli Workload Scheduler como outros jobs e incluem o nome do

job, o nome do usuário e as opções de recuperação. Consulte Capítulo 5,

“Definindo os Jobs de Agente Estendido”, na página 37.

Parâmetros da Cadeia de Tarefas para Jobs do Oracle

Applications

Esta seção descreve os parâmetros da cadeia de tarefas que regem a execução de

jobs do Oracle Applications. Você deve especificá-los nos seguintes locais ao definir

os jobs do Tivoli Workload Scheduler associados:

v No campo Comando da página Tarefas da janela Propriedades - Definição do

Job, se estiver usando o Job Scheduling Console.

v Como argumentos da palavra-chave nome_do_script na instrução de definição

do job, se estiver usando a linha de comando do Tivoli Workload Scheduler.

v Como argumentos da palavra-chave JOBCMD na instrução JOBREC no SCRIPTLIB do

Tivoli Workload Scheduler para z/OS, se você estiver planejando em um

ambiente ponto a ponto.


Os parâmetros são descritos na tabela a seguir.

Tabela 9. Parâmetros da Cadeia de Tarefas para Jobs do Oracle Applications.

Parâmetro Descrição

-user appslogin

O nome de um usuário válido do Oracle

Applications (Apps login).

-job jobspecs

Os atributos de job do Oracle Applications. Há

quatro atributos de job que devem ser especificados

na seguinte ordem:

v O nome de um módulo do Applications utilizado

para conectar-se ao Oracle Applications (por

exemplo, FND).

v Uma responsabilidade válida para o módulo do

Applications (por exemplo, o ‘Desenvolvedor de

Aplicativos’). Esse parâmetro deve ser escrito

entre aspas simples.

v O nome de um aplicativo que registrou o job

(por exemplo, PO).

v O nome do job (por exemplo, POXACR). O nome

do job deve ser escrito em letras maiúsculas.

Por exemplo:

-job FND ’Desenvolvedor de Aplicativo’ PO

POXACR

-prn printopts

As duas opções de impressora para o job. Elas

devem ser inseridas na seguinte ordem:

v O nome da impressora (opcional). Se omitido, a

impressora padrão especificada no arquivo de

opções será utilizada.

v O número de cópias.

Por exemplo:

-prn ps4 2


Tabela 9. Parâmetros da Cadeia de Tarefas para Jobs do Oracle

Applications. (continuação)


[-vn (’valor’|null|:parâmetro)]

Os parâmetros do job, se houver. Essa cadeia será

opcional se nenhum parâmetro for especificado

para o job no Oracle Applications.

v n é o número do parâmetro (v1, v2, etc.).

v Um dos seguintes:

valor Um valor real. Escreva o valor entre

aspas simples se ele possuir caracteres

especiais.

:parâmetro

O nome de um parâmetro do Tivoli

Workload Scheduler já definido.

Consulte o Tivoli Workload Scheduler -

Guia de Referência para obter informações

adicionais sobre os parâmetros do Tivoli

Workload Scheduler.

O método de acesso incluirá automaticamente

todos os parâmetros que você não especificar na

definição com um valor null.

Estes são dois exemplos:

-v4 ’abc’

-v15 :p1

Este é um exemplo de uma especificação de cadeia de tarefas completa:

-user GLOBAL -job FND ’Desenvolvedor de Aplicativo’ PO POXACR -prn ps4 2 -v1 ’abc’

Estados do Job do Tivoli Workload Scheduler e do Oracle Applications

Quando um job do Oracle Applications for ativado pelo Tivoli Workload

Scheduler, você poderá monitorar seu andamento com o conman. A transição de

estado no Tivoli Workload Scheduler e os estados do Oracle Applications

correspondentes são listados a seguir.

Estados do Oracle Concurrent Manager Estados do Tivoli Workload Scheduler

Falha na Solicitação ou solicitação não

Encontrada

UT (tarefa não suportada)

Inativo SUSP

Pendente WAIT

Pendente Normal ADD

Em Execução Normal EXEC

Concluída Normal SUCC

Aviso de Conclusão SUCC

Concluído com Erro ABEND

Concluído com Finalização ABEND

Concluído Cancelado ABEND

Capítulo 7. Informações de Definição do Job 51

Para obter informações adicionais sobre o gerenciamento de job, consulte o Tivoli

Workload Scheduler - Manual de Referência.


Capítulo 8. Referência do Arquivo de Opções MCMAGENT

Esta seção fornece informações de referência detalhadas sobre o arquivo de opções

do IBM Tivoli Workload Scheduler para Aplicativos do Oracle e-Business Suite.

O Arquivo de Opções

Cada instância instalada do método de acesso do Oracle deve ter um arquivo de

opções de correspondência. Você pode criá-lo durante ou depois da instalação do

método de acesso com o Editor de Opções (consulte Capítulo 3, “Definindo Opções

com o Editor de Opções”, na página 27) ou com qualquer editor de texto comum.

A convenção de nomenclatura de cada arquivo de opções deve ser

<WORKSTATION_NAME>_MCMAGENT.opts e deve estar localizada no diretório

TWShome/methods. Se você não criar um, o agente utilizará, por padrão, o arquivo

de opções globais chamado MCMAGENT.opts.

Sintaxe de Entrada

A tabela a seguir lista as opções para o método de acesso MCMAGENT.

Tabela 10. Opções de MCMAGENT.

Opção Descrição

ORACLE_HOME O diretório do Unix em que o software do Oracle foi

instalado.

ORACLE_SID O identificador do sistema Oracle da instância do banco

de dados ao qual está se conectando. Isso corresponde ao

valor da variável $ORACLE_SID do Oracle Applications.

ORA_APP_TOPDIR O diretório do Unix em que o Oracle Applications está

instalado.

FND_TOPDIR O diretório FND top em que está localizada a Biblioteca

de Objetos de Aplicativos.

PATH A definição da variável PATH, incluindo, o caminho

existente, o caminho para o diretório bin do Oracle

Applications, o caminho para o diretório include no

diretório FND Top e outros, conforme necessário.

ENV O arquivo de ambiente a ser executado. Cada instância

do Oracle Applications tem seu próprio arquivo de

ambiente (APPLSYS.env ou APPDEMO.env). O nome do

arquivo .env fornecido aqui será utilizado para definir o

ambiente dinamicamente quando o Tivoli Workload

Scheduler executar jobs no Oracle Applications x-agent.

USERID Um id do usuário do banco de dados que tem acesso a

todos os Módulos no Oracle Applications. Ele deve ser

capaz de ativar, gerenciar e finalizar jobs no Oracle

Applications.

PASSWORD A senha para o ID do usuário selecionado. Para obter o

valor criptografado, use o utilitário enigma enviado com

o produto. Consulte “Criptografando as Senhas de

Usuários do Oracle Applications” na página 54.

PRINTER_NAME O id da impressão padrão.


Tabela 10. Opções de MCMAGENT. (continuação)

Opção Descrição

MIN_TIME O número de segundos a ser incluído no intervalo de

polling anterior, depois do qual a verificação do status

do job deve ser executada.

MAX_TIME O número de segundos depois do qual o intervalo de

polling não será incrementado.

Todas as opções são exigidas e devem ser gravados uma por linha no formato:

OPTION=VALUE

sem espaços em branco.

Exemplo

O arquivo HP113_MCMAGENT.opts é um arquivo de opções de amostra:

ORACLE_HOME=/general/ora716

ORACLE_SID=DEMO106

ORA_APP_TOPDIR=/apps106

FND_TOPDIR=$APPL_TOP/fnd/*

PATH=$PATH:$ORACLE_HOME/bin:$FND_TOP/include

ENV=$APPL_TOP/APPDEMO106.env

USERID=APPS_US

PASSWORD=APPS_US

PRINTER_NAME=PRINTER1

MIN_TIME=10

MAX_TIME=200

Criptografando as Senhas de Usuários do Oracle Applications

Quando você faz inserções no arquivo de opções, o valor de senha é

automaticamente criptografado, antes de ser gravado no arquivo. Se você

modificar o arquivo com um editor de texto, será necessário executar o programa

enigma para criptografar a senha antes de gravá-la no arquivo. Execute o programa

enigma como descrito abaixo:

enigma [senha]

Você pode incluir a senha na linha de comando ou inseri-la como resposta a um

prompt. O programa retorna uma versão criptografada que pode se inserida no

arquivo de opções.


Parte 3. Método de Acesso do PeopleSoft



O IBM Tivoli Workload Scheduler para Aplicativos do PeopleSoft permite que você

execute e monitore os jobs do PeopleSoft a partir de um ambienteTivoli Workload

Scheduler. Esses jobs podem ser executados como parte de um planejamento ou

enviados para um processamento de job ad-hoc. Os jobs de agente estendido do

PeopleSoft podem ter todas as dependências e as opções de recuperação como

outros jobs do Tivoli Workload Scheduler. Os jobs do PeopleSoft devem ser

relatados no Tivoli Workload Scheduler para que sejam executados e controlados

no ambiente Tivoli Workload Scheduler.

Recursos

v O agentes estendido para as versões 7.0, 7.5 e 8.x do PeopleSoft foram

certificadas pelo PeopleSoft no Windows NT 4.0 com Service Pack 6 e no

Windows 2000.

v Suporte ao PeopleSoft 8.x.

v Utilize as dependências do job padrão do Tivoli Workload Scheduler nos jobs do

PeopleSoft.

v Planeje os jobs do PeopleSoft para serem executados em dias e horas

especificados e em uma ordem predeterminada.

v Defina a interdependência dos jobs do PeopleSoft e dos jobs do Tivoli Workload

Scheduler executados em diferentes aplicativos, como o R/3 e o Oracle.

v Defina a interdependência dos jobs do PeopleSoft e dos jobs executados jobs em

diferentes plataformas.

v Personalize os códigos de retorno de execução do job.

Visão Geral Funcional

O Tivoli Workload Scheduler pode ativar e monitorar jobs no programador de

processos do PeopleSoft, utilizando uma estação de trabalho de agente estendido.

O agente estendido do PeopleSoft é definido em uma definição de estação de

trabalho do Tivoli Workload Scheduler padrão. Essa definição é um nome de

estação de trabalho lógica e especifica o método de acesso como psagent. O

método de acesso é utilizado para comunicar solicitações de job ao programador

de processo do PeopleSoft.

Para ativa um job do PeopleSoft, Tivoli Workload Scheduler executa o método

psagent, transmitindo as informações sobre o job. Um arquivo de opções fornece o

método com o caminho, o executável e outras informações sobre o programador de

processo do PeopleSoft e o servidor de aplicativos usado para ativar o job. O

agente estendido pode acessar a tabela de solicitações de processo do PeopleSoft e

fazer uma entrada na tabela para ativar o job. O progresso do job e as informações

de status são gravadas no arquivo de lista padrão do job.

Jobs do Programador de Processo do PeopleSoft

O programador de processo do PeopleSoft utiliza as entradas da tabela Solicitação

de Processo (PSPRCSRQST) para orientar as decisões de trabalho. Essas entradas

descrevem os processos que o agente do servidor Programador de Processo ativará.

Eles também contêm as informações necessárias para determinar o status do


processo. O método de acesso para o PeopleSoft pode inserir entrada, consultar o

conteúdo e modificar as informações de status nessa tabela(PSPRCSRQST).

Ao documentar um job do PeopleSoft no Tivoli Workload Scheduler, o usuário está

realmente definindo para que uma solicitação de processo seja inserida na tabela

Solicitação de Processo (PSPRCSRQST). Uma solicitação de processo no Tivoli

Workload Scheduler deve conter três partes de dados válidas:

v Uma definição de processo tendo duas partes:

– Tipo de Processo

– Nome do Processov Um ID do operador (desnecessário na execução no PeopleSoft 8.x)

v Um ID de controle de execução

Todos esses itens são exigidos para que um job do PeopleSoft seja executado. O

método de acesso para o PeopleSoft atualiza diretamente a tabela PSPRCSRQST para

o PeopleSoft 7.x (conexão de nível 2), enquanto que para o PeopleSoft 8.x ele

explora o servidor de aplicativo PeopleSoft por meio da interface exposta pela

interface do componente PROCESSREQUEST (conexão de nível 3).

Observe que o programador de processo e o servidor de aplicativos é executado no

Unix e nas estações de trabalho do Windows FTA, enquanto o agente estendido é

executado apenas no Windows NT ou no Windows 2000.

Rastreamento de Job do PeopleSoft no Tivoli Workload

Scheduler

Um job no PeopleSoft é uma coleção de processos que são executados juntos como

uma única unidade. Os jobs do Tivoli Workload Scheduler podem ser definidos de

uma das seguintes formas:

v Como jobs do PeopleSoft, isto é, como uma coleção de processos do PeopleSoft.

Nesse caso, o status do job do PeopleSoft é rastreado e não o status de processos

individuais dentro do job.

v Como processos do PeopleSoft. Nesse casso, o status de um processo individual

é rastreado e os planejamentos do Tivoli Workload Scheduler podem ser

definidos para criar interdependências complexas e opções de recuperação entre

os processos do PeopleSoft.

Segurança

A segurança para os jobs do PeopleSoft é tratada por padrão pela segurança do


Notas sobre o Suporte ao PeopleSoft versão 8.x

O suporte ao PeopleTools 8.x tem algumas alterações que você deve saber, se

planejar utilizar o método x-agent no seu ambiente.

v A palavra-chave -operator utilizada nas especificações de job do Tivoli

Workload Scheduler e em seus parâmetros de correspondência são ignoradas

atualmente pelo método psagent e pelo tempo de execução. Como conseqüência,

os jobs serão enviados e executados com o mesmo ID do operador PS, usado

para conexões com o PeopleSoft. Você não deve alterar as definições de job do

Tivoli Workload Scheduler, se desejar migrar do PeopleTools 7.x para o


PeopleTools 8.x. A diferença é que todos os jobs enviados ao x-agent do

PeopleSoft 8.x será executado no mesmo ID especificado no arquivo

<CPU_NAME>_psagent.opts.

v Não há necessidade de instalar a conectividade com o banco de dados no FTAs

hospedando os agentes estendidos do PeopleSoft, pois o método utiliza uma

arquitetura de nível 3 do PeopleSoft, atualmente. você terá que configurar pelo

menos um Servidor de Aplicativos PeopleSoft para que o agente estendido

funcione. O Servidor de aplicativos deve ser ativado para que os jobs sejam

enviados com sucesso para o programador de processo do PeopleSoft.

v Não será necessário carregar TVPUPSFT.dms no banco de dados do PeopleSoft 8.x

ao trabalhar no modo de nível 3.

v Para o PeopleSoft 8.1x, o método exige a instalação do suporte ao PeopleSoft

External Api no FTA que está hospedando o método de agente estendido. O

diretório de instalação da API externa é utilizado durante os processo de

instalação e configuração do agente estendido ao ser necessário especificar o

diretório inicial do PeopleSoft ou o diretório raiz do COBOL. Para instalar a API

externa, utilize o executável setup.exe localizado no diretório de servidor de

arquivos do PeopleSoft 8.1x, chamado: <PS_HOME>\setup\PsExtAPI. A instalação

do PeopleSoft External API deve ser executada antes da instalação do Tivoli

Workload Scheduler para Aplicativos. Verifique a instalação da API externa

como orientado pelas instruções no PeopleSoft: utilizando a ferramenta

jnitest.exe localizada no diretório de instalação do PS External API. Será

necessário reinicializar a estação de trabalho antes de utilizar a instalação do

PsExtAPI com sucesso. Se houver falha na inicialização, você verá uma janela

pop-up no TVPUPSFT.exe, dizendo:

"Houve uma falha ao inicializar o aplicativo de forma adequada (0xc0000005).

Clique em OK para

finalizar o aplicativo."


Capítulo 10. Planejamento de Implementação

PeopleSoft Versão 7.5 ou Anterior

Esta seção descreve o planejamento de implementação para o agente estendido

com o PeopleSoft 7.5 ou anterior.

Requisitos do Host

A estação de trabalho que hospeda o agente estendido exige os seguintes

requisitos:

v Ele deve ser um FTA (agente tolerante a falhas) do Tivoli Workload Scheduler ou

um SA (agente padrão) que execute uma versão suportada do Windows.

v Ele deve ter acesso de rede ao banco de dados do PeopleSoft.

v Ele deve ser capaz de se tornar uma estação de trabalho do PeopleSoft.

v Ele deve ter acesso às bibliotecas de suporte do PeopleSoft e do COBOL. O

suporte para COBOL deve ser compatível com o compilador utilizado para o

ambiente do programador de processo do NT.


IBM Tivoli Workload Scheduler para Aplicativos do PeopleSoft exige os seguintes

requisitos de software:

v Windows NT 4.0 com Service Pack 6 ou Windows 2000 com service pack 2.

v IBM Tivoli Workload Scheduler versão 7.0 ou posterior

v PeopleSoft versão 7.0, 7.5

v Compilador PeopleSoft COBOL

Notas:

1. O agente estendido para as versões 7.0 e 7.5 do PeopleSoft está disponível no

MicroFocus NetExpress 2.1 e no MicroFocus NetExpress 3.1.

2. O agente estendido para o PeopleSoft, versão 7.0, também foi compilado com o

Micro Focus COBOL workbench Compiler, versão 4.1

3. Para o Peoplesoft versões 7.x, é necessário recompilar o programador de

processo do Peoplesoft para Windows se você estiver usando-o para os jobs

gerenciados com o Tivoli Workload Scheduler.

Instalação para Usuário do Windows

v Crie um ID do usuário local ou de domínio com autoridade para acessar o

software PeopleSoft e Tivoli Workload Scheduler ou para instalar o usuário

existente para permitir o acesso ao software PeopleSoft e ao Tivoli Workload

Scheduler. Consulte “Configuração do Usuário para Windows” na página 65

para obter detalhes.

v Efetue logon como o novo usuário.

v Conecte-se às unidades apropriadas para o PeopleSoft. Certifique-se de

selecionar Reconectar no Logon. A letra da unidade deve ser a mesma que foi

especificada como PSDRIVE em psagent.opts.

v Execute a instalação do PeopleSoft. Siga as instruções fornecidas no software do

PeopleSoft.


Verificando o Ambiente PeopleSoft

Certifique-se de que o ambiente PeopleSoft esteja configurado corretamente e que

os jobs do PeopleSoft possam ser executados com sucesso pelo programador do

processo.

Notas:

1. Verifique a conectividade dos bancos de dados para os bancos de dados do

PeopleSoft utilizando o ID do Usuário do Windows criado anteriormente.

Conexão pode ser verificada com a execução de um comando de banco de

dados, usando qualquer utilitário ODBC.

2. Verifique o acesso ao servidor de arquivos do Peoplesoft ou a disponibilidade

da cópia local dos executáveis.

Criando um ID de Processamento de Batch no PeopleSoft

Você deve criar um ID do operador no PeopleSoft dedicado ao planejamento do

batch. Todos os jobs enviados pelo Tivoli Workload Scheduler devem usar esse ID

do operador.

Arquivos Instalados

Os seguintes arquivos são instalados no Tivoli Workload Scheduler e em diretórios

do PeopleSoft durante a instalação do Tivoli Workload Scheduler para Aplicativos:

Destino Arquivos Proprietário

TWShome \methods\PeopleSoft v TVPUPSFT7xx.dms, em que

xxespecifica o release do

PeopleSoft, versão 7.

v PTCUDCOP.cbl

Usuário Tivoli

Workload Scheduler

TWShome\methods v psagent.exe

v enigma.exe

Usuário Tivoli

Workload Scheduler

<PSDRIVE_PSVER>\cblbin v TVPUPSFT.exe

v TVPUPSFT.gnt

Proprietário do

PTPUPRCS.exe

Nota: TWShome indica o nome do diretório em que o Tivoli Workload Scheduler

foi instalado.

PeopleSoft Versão 8.x

Esta seção descreve o planejamento de implementação para o agente estendido

com o PeopleSoft versão 8.x.

Requisitos do Host

A estação de trabalho que hospeda o agente estendido deve ser um agente do

Tivoli Workload Scheduler tolerante a falhas ou um agente padrão em uma

plataforma Windows suportada.

Se seu site tiver vários servidores de processo para um único banco de dados do

PeopleSoft, será possível configurar ou estender uma estação de trabalho do agente

estendido (usando vários arquivos de opções) para processar jobs em vários

servidores de processo.



IBM Tivoli Workload Scheduler para Aplicativos do PeopleSoft exige os seguintes

requisitos de software:

v Windows NT 4.0 com Service Pack 6 ou Windows 2000 com service pack 2.

v IBM Tivoli Workload Scheduler versão 7.0 ou superior.

v PeopleSoft versão 8.1x ou 8.4x.

v Para o PeopleSoft versão 8.1x: PeopleTools External APIs versão 8.1x.

v Para o PeopleSoft versão 8.4x: acesso ao PeopleSoft File Server 8.4x ou

disponibilidade de uma cópia local dos executáveis.

Criando um ID de Processamento de Batch no PeopleSoft

Você deve criar um ID do operador no PeopleSoft dedicado ao planejamento do

batch. O ID do operador deve conceder autoridade para utilizar a Interface do

componente no ambiente PeopleTools. Todos os jobs enviados pelo IBM Tivoli

Workload Scheduler devem usar esse ID do operador.

Arquivos Instalados

Os seguintes arquivos são instalados no IBM Tivoli Workload Scheduler e em

diretórios do PeopleSoft durante a instalação do IBM Tivoli Workload Scheduler

para Aplicativos do PeopleSoft:

Destino Arquivos Proprietário

TWShome\methods v psagent.exe

v enigma.exe

Usuário Tivoli Workload

Scheduler

PSAPI_dir TVPUPSFT.exe Usuário Tivoli Workload

Scheduler

Nota: TWShome indica o nome do diretório em que o Tivoli Workload Scheduler

foi instalado.

Capítulo 10. Planejamento de Implementação 63

Capítulo 11. Tarefas de Pós-Instalação

Este capítulo descreve tarefas importantes que devem ser feitas após a instalação

do método de acesso.

Configuração do Usuário para Windows

Quando um cliente PeopleSoft é utilizado para enviar jobs com o IBM Tivoli

Workload Scheduler para Aplicativos do PeopleSoft no ambiente de nível três,

usando um compartilhamento em um servidor de arquivos PeopleSoft, o

streamlogon especificado no envio do job deve ser ″conhecido″ no cliente que

enviou e no servidor de arquivos PeopleSoft. Ele também deve ser:

v Um usuário de domínio

v Um usuário local definido no cliente e no servidor de arquivos PeopleSoft com o

mesmo nome e a mesma senha. O usuário deve então ser definido no banco de

dados do Tivoli Workload Scheduler.

Se essa condição não for atendida, os seguintes sintomas serão produzidos:

v Jobs serão classificados como abend

v Duas mensagens de erro do sistema operacional serão enviadas para a stdlist do

job, dizendo:

Falha no logon: nome de usuário desconhecido ou senha incorreta.

procwork.cpp(328): O canal foi finalizado.

O usuário deve fazer parte do Grupo do Administrador no cliente PeopleSoft. Se

essa condição não for atendida, os seguintes sintomas serão produzidos:

v Os jobs irão para o estado INTRO (e um sinal de adição ″+″ será incluído para

indicar um job ativo)

v Uma janela popup será exibida na estação de trabalho do Tivoli Workload

Scheduler que hospeda o agente estendido, como o título psagent.exe - Erro de

Aplicativo, dizendo:

Houve uma falha ao inicializar o aplicativo de forma adequada (0xc0000005).

Clique em OK para finalizar o aplicativo.

v Depois de clicar no botão OK os jobs irão para o estado abend, e a stdlist do job

mostrará somente o banner do programa JOBLNCH.

Criando o Arquivo de Opções

Os arquivos de opções de agente estendido do PeopleSoft especificam, entre outros

itens, o usuário do banco de dados com o qual o método se conecta ao banco de

dados do PeopleSoft. Eles também são usados para especificar a taxa de polling

para o módulo do PeopleSoft para verificação do status do job.

Esse arquivo deve estar localizado no computador do host para o agente estendido

no diretório TWShome\methods.

Para criar um arquivo de opções você pode utilizar o Editor de Opções disponível

com esse produto ou qualquer outro editor de texto. Consulte Capítulo 3,

“Definindo Opções com o Editor de Opções”, na página 27 para obter detalhes

sobre a criação ou a edição de arquivos de opções com o Editor de Opções e


“Editando Manualmente os Arquivos de Opções” na página 68 para obter

exemplos de arquivos de opções para esse método de acesso.

A tabela a seguir descreve as opções para o método de acesso psagent:

Tabela 11. Opções Psagent.

Opção Descrição

LJuser O ID de um usuário do Windows que ativa os jobs do IBM

Tivoli Workload Scheduler. Esse usuário do Windows deve ser

um usuário válido do Tivoli Workload Scheduler na estação de

trabalho do host.

CFuser O ID de um usuário do Windows que executa um arquivo de

verificação. O valor padrão deve corresponder ao valor de

Usuário de Ativação do Job.

CheckInterval O intervalo de tempo entre as verificações do status ao

monitorar a solicitação do processo. O valor padrão é 2

minutos. Utilize a opção CheckIntervalUnits para alterar de

minutos para segundos.

CheckIntervalUnits Especifica que o Intervalo de Verificação do Status está em

segundos (valor=1) em vez de estar em minutos (valor=60).

PSXA_TRACE Um valor de 1 ativa a execução de rastreamento. Um valor de 0

desativa essa execução.

PSDRIVE A letra da unidade do Windows para os arquivos do PeopleSoft

(por exemplo, N:).

PSVER O diretório inicial para os arquivos do PeopleSoft (por exemplo,

\PT7.5 ou \PT8) para todas as versões do PeopleSoft, exceto

8.1x. Nesse caso, é o diretório em que o arquivo TVPUPSFT.exe

está instalado (por exemplo, \PT817\bin\client\winx86_extapi)

COBROOT Para o PeopleSoft 7.x: o caminho para o diretório de base para

as bibliotecas do Micro Focus COBOL (por exemplo, N:\PT7.5).

Para o PeopleSoft 8.x: o caminho para o diretório de base para o

PeopleSoft External APIs. Ele é o mesmo que o Diretório inicial

do PeopleSoft.


Tabela 11. Opções Psagent. (continuação)

Opção Descrição

CONNECT Uma cadeia que contém as seguintes entradas:

Tipo de conexão

O tipo do sistema PeopleSoft RDBMS. Escolha um dos

exemplos a seguir:

v APPSERV (PeopleSoft 8.x apenas)

v ORACLE

v MICROSFT (Microsoft SQL Server)

v DB2 (DB2 para MVS)

v DB2UNIX

v SQLBASE

v DB2ODBC

v DB2400

v INFORMIX

v SYBASE

v DB2MDI

Nome do servidor de banco de dados

O Nome do servidor de banco de dados. Esse é para

Informix e Sybase apenas. Não utilizado para o

PeopleSoft versão 8.x.

Nome do servidor

O nome do servidor (endereço IP) especificado como

Tipo de conexão.

Para APPSERV, essa entrada deve ser o endereço

IP:porta TCP ou o nome IP.

Você pode especificar várias entradas desde que

estejam separadas por vírgulas.

ID do Operador

O ID do operador para conexão com o banco de dados

do PeopleSoft.

v Para o PeopleSoft versão 7.x, todos os jobs não serão

executados como esse ID, mas como o ID

especificado na definição do job do Tivoli Workload

Scheduler.

v Para o PeopleSoft versão 8.x, todos os jobs serão

executados como esse ID.

Senhas do operador

A senha criptografada para o ID do operador. Se

utilizar um editor comum para gravar os arquivos de

opções, você deverá utilizar primeiro a ferramenta

Enigma para criptografá-lo. Se você utilizar o Editor de

Opções, ele fará isso para você.

Servidor de processo padrão

O servidor de processo padrão que executa jobs no

PeopleSoft.

As entradas são separadas por barras (/), para que a cadeia

esteja neste formato item1/item2/.../item6 e devem ser

listadas na seqüência exibida nessa explicação.

Todas as entradas são obrigatórias com exceção do Nome do

servidor de banco de dados.


Tabela 11. Opções Psagent. (continuação)

Opção Descrição

TWSXA_PT84_JVMPATH O caminho para a Java Virtual Machine. Essa opção está

disponível para ser utilizada somente pelo PeopleTools versão

8.4x.

UTF8cmdline Se definido para 0, significa que o método de agente estendido

espera que o Tivoli Workload Scheduler envie os dados

necessário para ativar o job na página de código local. Caso

contrário, ele espera que os dados estejam no formato UTF8. O

valor padrão é 1 (por exemplo, formato UTF8).

TWSXA_CP A página de código que o método de agente estendido utiliza

ao se comunicar com o aplicativo externo. Se a opção estiver

ausente ou se tiver um valor inválido, a página de código local

será utilizada.

TWSMETH_CP A página de código que o método de agente estendido utiliza

para gerar a saída padrão. Se a opção estiver ausente ou se tiver

um valor inválido, a página de código local será utilizada.

TWSMETH_LANG O idioma que o método de agente estendido utiliza para a saída

padrão (isto é, o catálogo de mensagens especificado será

aberto). Se a opção estiver ausente ou se tiver um valor

inválido, o idioma local será utilizado.

TWSXA_LANG Não suportado para o agente estendido do PeopleSoft.

Os nomes de opção fazem distinção entre maiúsculas e minúsculas e devem ser

escritos como mostrado na coluna esquerda da tabela 11. Antes de utilizar o

arquivo de opções criado manualmente, verifique se todos os nomes de opção

estão escritos corretamente. As opções que não estiverem de acordo serão

ignoradas.

Editando Manualmente os Arquivos de Opções

Além do Editor de Opções, você pode utilizar qualquer editor comum para criar

ou alterar manualmente um arquivo de opções.

Abaixo estão dois arquivos de opções de exemplo. Esses exemplos vão ajudá-lo a

determinar os requisitos específicos do site. Seu arquivo de opções pode ser

diferente dos arquivos abaixo.

Lembre-se de salvar o arquivo no diretório TWShome\methods

Exemplo para o PeopleSoft 7.x

LJuser=TwsUsr

CFuser=TwsUsr

PSDRIVE=N:

PSVER=\PS750

COBROOT=N:\PS750

CONNECT=ORACLE/HR75/PSUSA/#oqola4O7lxp5refgbAreV/PSNT

CheckInterval=15

CheckIntervalUnits=1

PSXA_TRACE=0

Exemplo para PeopleSoft 8.1x

LJuser=TwsUsr

CFuser=TwsUsr

CheckInterval=15

PSDRIVE=D:


PSVER=\pt81x\bin\client\winx86_extapi

COBROOT=D:\pt81x\bin\client\winx86_extapi

CONNECT=AppServ/PSOFT81X:9000/PSDEV/jp5l83nlWe7wh5jxk46qeV/PSUNX

CheckIntervalUnits=1

PSXA_TRACE=1

Conectando Mais de um Banco de Dados do PeopleSoft

Pode ser necessário que o método psagent conecte-se a mais de um banco de

dados do PeopleSoft. Por exemplo, uma instalação simples do PeopleSoft pode ter

um ambiente TEST, DEMO e PRODUCTION, cada um com um banco de dados

separado. Isso requer que o método psagent utilize uma cadeia de conexão

separada para cada banco de dados.

Para suportar isso, você pode configurar várias estações de trabalho de agente

estendido do PeopleSoft que se conectam ao mesmo método mas utilizam arquivos

de opções diferentes. Quando uma estação de trabalho inicia o método, ela procura

primeiro o arquivo de opções com o nome da estação de trabalho de agente

estendido incluído no psagent.opts. Por exemplo, um agente estendido do

PeopleSoft chamado jupiter terá o seguinte arquivo de opções:

jupiter_psagent.opts

O método psagent pesquisa primeiro um arquivo de opções com o nome da

estação de trabalho de agente estendido e depois pelo arquivo padrão

psagent.opts. Isso permite que o usuário configure o agente estendido para cada

banco de dados do PeopleSoft.

Para conectar-se a apenas um banco de dados, utilize o nome padrão para o

arquivo de opções psagent.opts.

Configurando o Ambiente PeopleSoft para a Versão 7.5 ou Anterior

A seção a seguir explica como configurar o ambiente PeopleSoft se você estiver

utilizando o agente estendido com o PeopleSoft versão 7.5 ou anterior.

Personalizando o Servidor de Processo

Independentemente do tipo do sistema operacional em que você está planejando os

jobs do Tivoli Workload Scheduler, é necessário personalizar o executável do

servidor de processo correspondente utilizando a fonte COBOL PTCUDCOP.cbl

fornecida pela IBM.

Você deve substituir o arquivo PTCUDCOP.cbl fornecido pelo PeopleSoft pelo

arquivo equivalente fornecido pela IBM e compilar o programador de processo

novamente.

Orientação completas sobre como compilar o programador de processo novamente

podem ser encontradas no manual de instalação do PeopleSoft. Ao receber os

patches do PeopleSoft, você terá que repetir o processo de personalização do

servidor de processo, se o arquivo PTCUDCOP.cbl for substituído durante a

instalação do patch.

A seguir estão as explicações sobre como executar as etapas de personalização no

Windows e no UNIX.

Personalizando no Windows

Se o programador de processo do PeopleSoft estiver em execução no Windows,

consulte a seção ″Configurando o Ambiente Batch no Windows NT/2000″ no


manual de instalação do PeopleSoft para obter informações atualizadas. Você deve

ter instalado um compilador COBOL no servidor batch e compilado dessa

localização. O computador que executa a compilação deve ter um compilador

COBOL instalado e deve ter de gravar o acesso ao servidor de arquivos.

Para criar o servidor de processo em um computador com o Windows:

1. Abra uma janela do prompt de comando do DOS.

2. Configure duas variáveis de ambiente, PS_HOME e COBROOT, no computador

no qual está planejando compilar o COBOL. Use estes comandos:

set PS_HOME=n:\PS750

set COBROOT=c:\netexpress\base

3. Certifique-se de que o diretório de compilação c:\temp\compile exista; ele já

pode estar presente se você tiver executado CBLBLD.BAT. Se ele existir, remova

quaisquer arquivos existentes lá, apenas por precaução. Se ele não existir, será

necessário criá-lo com o seguinte comando:

mkdir c:\temp\compile

Nota: Certifique-se de ter permissões de gravação para o diretório de

compilação pois o processo de compilação ocorrerá nesse local.

4. Altere para o diretório <PS_HOME>\setup.

5. Execute o seguinte comando para copiar todos os arquivos de origem COBOL

do diretório <PS_HOME> para o diretório de compilação:

cblsrc <source directory> <compilation directory>

em que <source directory> é a unidade e o diretório em que o arquivo de

origem está (deve ser o mesmo que <PS_HOME>) e<compilation directory> é a

unidade e o diretório para o qual os arquivos de origem serão copiados.

Por exemplo, o seguinte comando pegará os arquivos de origem COBOL do

<PS_HOME> e copiará todos os arquivos necessários para o local em que o

processo de compilação ocorrerá.

cblsrc <PS_HOME> c:\temp\compile

6. Copie o arquivo PTCUDCOP.cbl fornecido pela IBM para o diretório de

compilação com o seguinte comando:

copy <TWS_HOME>\PeopleSoft\PTCUDCOP.cbl c:\temp\compile

7. Depois de concluir o CBLSRC, altere o diretório atual para o diretório de

compilação com o seguinte comando:

cd c:\temp\compile

8. Compile utilizando o seguinte comando:

CBLMAKE.BAT PTPUPRCS EXE LIST

Se houver algum problema de compilação, analise o arquivo PTPUPRCS.lis

para obter detalhes e tente executar o comando depois de solucionar os

problemas.

9. Depois de concluir o CBLMAKE.BAT, copie os arquivos EXE, GNT ou INT para

o diretório <PS_HOME>\cblbin, utilizando os seguintes comandos:

copy PTPUPRCS.exe <PS_HOME>\cblbin

copy PTPUPRCS.gnt <PS_HOME>\cblbin

Personalizando no UNIX

Se o programador de processo do PeopleSoft estiver em execução no UNIX,

consulte a seção ″Configurando o Ambiente Batch no UNIX″ no manual de

instalação do PeopleSoft para obter informações atualizadas. Você deve ter


instalado um compilador COBOL no servidor batch e executado a compilação

dessa localização. O computador que executa a compilação deve ter um

compilador COBOL instalado e deve gravar o acesso ao diretório

<PS_HOME>/cblbin.

Para criar o servidor de processo em uma máquina com o UNIX:

1. Efetue logon no servidor UNIX.

2. Altere o diretório atual para o diretório inicial do PeopleSoft.

3. Execute o script psconfig.sh.

4. Altere os diretórios para o diretório $PS_HOME/src/cbl.

5. Renomeie o PTCUDCOP.cbl para PTCUDCOP.old utilizando o seguinte

comando:

mv PTCUDCOP.cbl PTCUDCOP.old

6. Copie o PTCUDCOP.cbl do agente estendido (twshome/PeopleSoft) utilizando o

FTP.

7. Execute os seguintes comandos:

cd ../../install

pscbl.mak PTPUPRCS LIST

8. Depois da conclusão do script, verifique os diretórios de destino para os

arquivos criados recentemente em

<PS_HOME>/src/cbl/int

<PS_HOME>/src/cbl/lst

<PS_HOME>/cblbin

Eles devem ter um comprimento maior que zero bem como data e hora atuais.

Se houver algum problema durante a compilação, analise o arquivo

PTPUPRCS.lis para verificar os erros, corrija-os e tente executar a etapa de

compilação novamente.

Configurando o Cliente

Para executar o método de acesso do PeopleSoft para o ambiente PeopleTools 7.x,

você tem que executar em um ambiente PeopleSoft de nível 2, utilizando uma

estação de trabalho com conectividade adequada para o banco de dados.

Você deve instalar um software cliente para o banco de dados de sua escolha na

estação de trabalho que hospeda o agente estendido e configurá-lo para

comunicações adequadas ODBC. Teste a conectividade utilizando ferramentas de

teste ODBC fornecidas com o software cliente (por exemplo, teste ODBC 32bit para

Oracle).

Você precisa acessar o Servidor de Arquivos do PeopleSoft. Mapeie o

compartilhamento do servidor de arquivos para uma unidade de rede na estação

de trabalho Windows.

Para uma instalação de estação de trabalho para um ambiente PeopleSoft 7.x:

1. Acesse \\<fileserver>\<share> como a unidade compartilhada <d>: no seu

computador.

2. Defina PS_HOME para o diretório adequado na nova unidade compartilhada,

utilizando este comando:

set PS_HOME=<d>:\PS750

3. Execute:

%PS_HOME%\bin\CLIENT\WINX86\pscfg.exe


Uma janela de configuração, como aquela mostrada em Figura 23, é exibida.

4. Selecione a guia Client Setup e preencha os valores necessários, certificando-se

de ter selecionado a caixa de opções Install PeopleSoft ODBC Driver. Se você

estiver executando o SQL Server, será necessário selecionar a caixa de opções

Install ODBC Driver Manager 3.0.

Nota: O sinalizador Install PeopleSoft ODBC Drive instala um nome de origem

de dados do ″usuário″. Se você precisar acessar a origem de dados de

outro perfil de usuário, você terá que criar uma origem de dados

correspondente, utilizando ″Control Panel″-> ″ODBC (Data Source)″ na

máquina com o WinNT/2000 ou executar novamente a etapa de

personalização para todos os outros usuários que deseja utilizar para

enviar jobs de agente estendido do Tivoli Workload Scheduler.

Depois da conclusão, você dever ter no menu ″Iniciar/Programas″ um novo item

rotulado PeopleSoft 7.5.

Figura 23. Janela Configuração do Manager 7.5.


Executando o Script do Data Mover

Depois da conclusão da instalação, o PeopleSoft Data Mover é utilizado para

mover os procedimentos armazenados para o agente estendido do PeopleSoft no

local. Para obter informações adicionais sobre o script do Data Mover, consulte a

documentação do Peoplesoft.

1. Clique no ícone do DataMover no grupo PeopleSoft. A janela Peoplesoft Signon

é exibida.

2. Selecione o banco de dados apropriado e clique em OK. A janela de logon do

PeopleSoft é exibida.

3. Preencha os campos de logon e clique em OK. A janela do Data Mover é

exibida.

4. No menu File na janela do Data Mover, selecione o comando Open. Abra o

seguinte arquivo na janela do Data Mover:

TWShome\PeopleSoft\TVPUPSFT.dms

5. Assim que carregar os scripts na janela do Data Mover, execute-os.

A janela do Data Mover é divida em duas partes. A seção superior mostra as

instruções do script do Data Mover. A parte inferior mostra o status das

instruções do script, conforme são executados.

6. Verifique se o script está sendo executado com sucesso.

Figura 24. Janela PeopleSoft Signon.


Se houver falha nas instruções, verifique se os valores da janela de inicialização,

Nome do Banco de Dados, ID de Login e Senha, estão corretos e repita o

processo. Se o script do Data Mover continuar a falhar, consulte o DBA para

determinar se há algum problema no banco de dados.

Nota: O script do Data Mover deve ser executado em cada banco de dados que o

agente estendido para PeopleSoft irá utilizar. Para executar os scripts em

outro banco de dados, altere o nome do banco de dados e/ou RDBMS na

seqüência de login.

Configurando o Ambiente PeopleSoft para Versão 8.1x

A seção a seguir explica como configurar o ambiente PeopleSoft se você estiver

utilizando o agente estendido com o PeopleSoft versão 8.1x.

Personalizando o Servidor de Aplicativos

O método de acesso que suporta o PeopleTools 8.1x pode funcionar somente em

conjunto com a arquitetura de nível 3 doPeopleSoft. Isso implica que você

precisará implementar a arquitetura de nível 3 de PeopleSoft de acordo com as

instruções do PeopleSoft. Enquanto é necessário uma implementação completa da

arquitetura do PeopleSoft com pelo menos um servidor de aplicativo e um

servidor de processo do PeopleSoft, esse procedimento reduz os requisitos de

software e as dependências na estação de trabalho de agente estendido. Não há

necessidade de instalar a conectividade do banco de dados na estação de trabalho

que hospeda o agente estendido. Além disso, não há requisitos de personalização

para o servidor de processo, como era para o PeopleTools versão 7.x, e não haverá

a necessidade de executar scripts do Data Mover adicionais para a personalização

do banco de dados. O servidor de aplicativos deve ser ativado para que os jobs

sejam enviados com sucesso para o programador de processo do PeopleSoft.

Para configurar adequadamente o método de acesso, você precisará obter as

seguintes informações do administrador do PeopleSoft:

Figura 25. Janela DataMover


v Nome do host (ou endereço IP) do servidor de aplicativos

v Porta Jolt do servidor de aplicativos (normalmente 9000)

v Nome do servidor de processo

O ID do operador deve conceder autoridade para utilizar a Interface do

componente no ambiente PeopleTools.

Configurando o Cliente

Para executar o agente estendido com o ambiente PeopleTools 8.1x, é necessário

instalar o suporte ao PeopleSoft External API na estação de trabalho do Tivoli

Workload Scheduler que hospeda o agente estendido.

A instalação do PeopleSoft External API deve ser executada antes da instalação do

Tivoli Workload Scheduler para Aplicativos para PeopleSoft.

O manual de instalação do PeopleSoft contém informações sobre essa etapa da

instalação. Consulte a documentação adequada do PeopleSoft para obter instruções

atualizadas, dependendo da versão real do PeopleSoft. Para o PeopleTools 8.17

você deverá chamar o executável setup.exe localizado no diretório do servidor de

arquivos do PeopleSoft 8, chamado %PS_HOME%\setup\PsExtAPI.

Anote o diretório em que você instalou o External API, pois ele será necessário

durante a instalação do agente estendido e durante a configuração, quando deverá

informar o diretório PSHome ou quando será perguntado sobre o diretório raiz

COBOL.

Antes utilizar o External API, verifique a instalação como orientado pelas

instruções do PeopleSoft, utilizando a ferramenta jnitest.exe localizada no diretório

do External API. A ferramenta jnitest.exe verifica se você possui o MicroSoft Java

Virtual Machine para Java 3.2 versão 5.00.3167 ou superior. Se jnitest.exe encontrar

a versão aceitável, o MicroSoft Java Virtual Machine poderá ser carregado. Caso

contrário, você terá dificuldade para carregá-lo adequadamente. O External API

não funcionará a menos que a versão correta do MicroSoft Java Virtual Machine

esteja presente.

Será necessário reinicializar a estação de trabalho antes de utilizar a instalação do

PeopleSoft External API, com sucesso. Se houver falhas nesse procedimento,

sempre que o job do PeopleSoft for enviado por meio do ITWS, uma janela popup

do VPUPSFT.exe será exibida, dizendo:

"Houve uma falha ao inicializar o aplicativo de forma adequada (0xc0000005).

Clique em OK para finalizar o aplicativo."

Configurando o Ambiente PeopleSoft para a Versão 8.4x

Para o PeopleTools versão 8.4x, não há mais uma instalação separada do

PeopleSoft External APIs, que era fornecido como parte do cliente Windows

padrão; ele pode ser acessado por meio do servidor de arquivos do PeopleSoft no

diretório chamando PS_HOME\bin\client\winx86. Adicionalmente, de acordo com o

ID de Resolução do PeopleSoft 704309, você deve:

v Ser capaz de acessar o diretório chamado PS_HOME\class contendo o arquivo

psjoa.jar.

v Ter acesso a uma JVM (Java Virtual Machine) válida.


Nota: A JVM fornecida com esse produto não válida para esse propósito. Você

deve utilizar uma JVM suportada pelo PeopleSoft.

O método psagent.exe tomará conta das variáveis de ambiente de

definição/atualização CLASSPATH e PS_HOME se elas não forem definidas no

ambiente em que o job é ativado. Se o ambiente do caminho de sistema contiver

um acesso válido para jvm.dll, então você poderá precisar de uma configuração

de ambiente adicional. Caso contrário, você deve especificar uma nova opção no

arquivo psagent.opts com um editor de texto, para que o psagent.exe possa

atualizar o caminho para o local em a JVM está. Para fazer isso, inclua a seguinte

linha no arquivo de opções:

TWSXA_PT84_JVMPATH=<path to jvm.dll>

As JVMs válidas são fornecidas pelo PeopleSoft com os servidores de aplicativo

que suportam a arquitetura PIA, como ″BEA WebLogic Server″ (no subdiretório

jdk131\jre\bin\classic ou jdk131\jre\bin\hotspot) ou ″IBM WebSphere

Application Server″ (no subdiretório Java13\jre\bin\classic). Por exemplo, você

pode atualizar o arquivo de opções com:

v TWSXA_PT84_JVMPATH=D:\Program Files\IBM\Java13\jre\bin\classic

v TWSXA_PT84_JVMPATH=D:\bea\jdk131\jre\bin\classic

v TWSXA_PT84_JVMPATH=D:\bea\jdk131\jre\bin\hotspot

Se você não tiver essa palavra-chave ou se não tiver um caminho de sistema válido

para jvm.dll, você verá uma destas mensagens:

v AWS140020078E Exceção obtida no arquivo TVPUPSFT.cpp(#) durante função Principal

v AWS140020076E O problema encontrado pode estar listado às definições do ambiente:

verifique o seguinte:

1) Seu caminho contém um diretório válido da Java Virtual Machine

ou o arquivo de opções

contém TWSXA_PT84_JVMPATH

2) A variável de ambiente CLASSPATH contém uma caminho válido para psjoa.jar

3) O servidor de aplicativo de destino está ativo e em execução

4) Você definiu a variável de ambiente PS_HOME


Capítulo 12. Definindo os Jobs do PeopleSoft

Este capítulo fornece informações sobre a definição do job, utilizando o agente

estendido para o PeopleSoft.

Criando Definições de Job do Peoplesoft no Tivoli Workload

Scheduler

As definições de job do Tivoli Workload Scheduler são necessárias para cada job

do Peoplesoft que você pretende controlar. Um job do Tivoli Workload Scheduler

está associado ao job do Peoplesoft definido, e a s suas definições incluem:

v Nome do job

v Nome do proprietário

v Especificações do arquivo de script

v Opções de recuperação

Consulte Capítulo 5, “Definindo os Jobs de Agente Estendido”, na página 37 para

obter referência.

Parâmetros de Cadeia de Tarefas para Jobs do PeopleSoft


jobs do PeopleSoft. Você deve especificá-los nos seguintes locais ao definir os jobs

do Tivoli Workload Scheduler associados:

v No campo Comando da página Tarefas da janela Propriedades - Definição do

Job, se estiver usando o Job Scheduling Console.





ambiente ponto a ponto. Observe que nesse caso a cadeia inteira, seguindo a

palavra-chave JOBCMD, deve ser escrita entre aspas duplas.

A tabela a seguir lista os parâmetros.

Tabela 12. Parâmetros da Cadeia de Tarefas para Jobs do PeopleSoft.

Parâmetro Descrição Versão do PeopleTools

-operator O ID do operador do

PeopleSoft que ativa o job.

7.x, 8.1x

-process O nome do processo para o

job do PeopleSoft.

7.x, 8.1x, 8.4x

-type O tipo de processo para o job

do PeopleSoft. Essa entrada

deve ser escrita entre aspas

simples.

7.x, 8.1x, 8.4x

-runcontrol O ID de controle de execução

para o PeopleSoft.

7.x, 8.1x, 8.4x

-outputdest O destino da saída do job do

PeopleSoft.

8.1x, 8.4x


Tabela 12. Parâmetros da Cadeia de Tarefas para Jobs do PeopleSoft. (continuação)

Parâmetro Descrição Versão do PeopleTools

-outputtype O tipo de saída do job do

PeopleSoft. Os valores

válidos são:0 (qualquer um)

1 (Nenhum)

2 (Arquivo)

3 (Impressora)

4 (Janela)

5 (E-mail)

6 (Web)

7 (Padrão)

8.1x, 8.4x

-outputformat O formato de saída do job do

PeopleSoft. Os valores

válidos são:Nenhum CSV

DOC

Padrão HP

HTM

LPOTHERPDFPS

RPT

RTF

SPF

TXT

WKS

XLS

8.1x, 8.4x

-runlocationdescr O programador de processo

do PeopleSoft envolvido no

processamento do job do

PeopleSoft.

8.1x, 8.4x

-foldername O nome da pasta de relatório

utilizada para esse job. A

pasta deve ter sido criada

com o uso do PeopleSoft

Report Manager.

8.4x

Nota: Nenhuma verificação de sintaxe é executada nos valores de controle de

saída (outputdest, outputtype, outputformat e foldername). Se os valores

não forem reconhecidos, os padrões serão utilizados.

Este é um exemplo de uma especificação de cadeia de tarefa completa para um job

do Peoplesoft 8.1x:

-operator PS -process XRFWIN -type ’SQR Report’ -runcontrol 1 -runlocationdescr PSNT

Configurando o Opens Dependencies 7.x Apenas

Você pode configurar as dependências abertas do Tivoli Workload Scheduler nos

jobs do PeopleSoft. As dependências abertas do Tivoli Workload Scheduler são

mapeadas para o comando “select count” do SQL com uma cláusula “where” no

banco de dados do PeopleSoft. O SQL verifica basicamente se os valores

selecionados existem no banco de dados. Se as entradas especificadas existirem no

banco de dados, a conta será retornada com um valor e o job será executado. Se as

entradas especificadas não existirem no banco de dados, a conta será retornada

com um 0 e o job não poderá ser executado. Um resultado de zero é falso;

qualquer outro valor é verdadeiro.


Nota: Ao criar a dependência aberta no Console de Planejamento do Job, a tabela é

listada abaixo da caixa de texto do arquivo e a coluna e os dados são listados

como qualificadores na caixa de texto dos qualificadores.

Por exemplo:

opens /PSSERVERSTAT

resulta no seguinte comando do SQL:

select count(*) from PSSERVERSTAT;

Isso retorna uma conta das linhas em PSSERVERSTAT. Um resultado de zero é

falso; qualquer outro valor é verdadeiro.

Outro exemplo é:

opens /PSSERVERSTAT ("SERVERNAME = ’PSNT’ AND SERVERSTATUS = 3")

Isso resulta no seguinte comando do SQL:

select count(*) from PSSERVERSTAT where SERVERNAME = ’PSNT’ AND SERVERSTATUS = 3;

Isso retorna uma conta das linhas no PSSERVERSTAT para o servidor PSNT em

que o status é (em execução).

Para configurar as dependências abertas em um job:

1. Edite o fluxo do job no qual deseja incluir uma dependência aberta no modo

da linha de comando.

2. Inclua a seguinte cadeia de comando no job:

cpu#job opens /tabela(“coluna = ‘dados’”)

em que:

tabela Especifica o nome da tabela do PeopleSoft que deseja abrir.

coluna Especifica o nome da coluna que você está procurando.

dados Especifica os dados dentro daquela coluna que corresponde à pesquisa.3. Salve as alterações feitas e feche o fluxo do job.

Nota: Os dados da tabela que você está procurando devem estar escritos entre

aspas duplas.

Exemplo de Dependências Abertas

Os seguintes fluxo de job têm exemplos de dependências abertas.

Aqui está o primeiro exemplo:

SCHEDULE PS_CPU#TEST01

ON EVERYDAY

:

PS_CPU#XRFWIN1

PS_CPU#XRFAPF1

PS_CPU#XRFPNP1 FOLLOWS XRFAPF1

PS_CPU#SYSAUDT1 FOLLOWS XRFWIN1

PS_CPU#PTPTEDT1 OPENS /PSPRCSRQST ("PRCSTYPE = ’SQR Report’ AND RUNSTATUS = 9")

PS_CPU#XRFILD1 FOLLOWS XRFPNP1,PTPTEDT1

PS_CPU#DDDAUDT1 FOLLOWS PTPTEDT1,TEST02.@

PS_CPU#TLS7011 FOLLOWS TEST02.@,DDDAUDT1

END

Aqui está outro exemplo:

Capítulo 12. Definindo os Jobs do PeopleSoft 79

SCHEDULE PS_CPU#TEST02

ON EVERYDAY

AT 1330

:

PS_CPU#XRFWIN2 OPENS /PSSERVERSTAT ("SERVERNAME = ’PSNT’ AND SERVERSTATUS = 3")

PS_CPU#XRFAPF2 FOLLOWS TEST01.XRFAPF1

PS_CPU#XRFPNP2 FOLLOWS XRFAPF2

PS_CPU#SYSAUDT2 FOLLOWS XRFWIN2

PS_CPU#PTPTEDT2 OPENS /PSPRCSRQST ("PRCSTYPE = ’SQR Report’ AND RUNSTATUS = 9

AND PRCSNAME = ’DDDAUDIT’")

PS_CPU#XRFILD2 FOLLOWS XRFPNP2,PTPTEDT2

PS_CPU#DDDAUDT2

END

IBM Tivoli Workload Scheduler e o Mapeamento de Status do Job do

PeopleSoft

Quando um job do PeopleSoft é ativado pelo Tivoli Workload Scheduler, você

pode monitorar seu progresso com o Console de Planejamento do Job. A transição

de estado no IBM Tivoli Workload Scheduler e os estados do PeopleSoft

correspondentes são listados a seguir.

Status do PeopleSoft

Status do IBM Tivoli

Workload Scheduler Descrição

CANCEL CANCEL/ABEND Um operador do PeopleSoft ou o

método marcou a solicitação do

processo para cancelamento. O

método será cancelado em resposta a

uma tarefa do TJ.

DELETE CANCEL Um operador do PeopleSoft marcou a

solicitação do processo para exclusão.

ERROR FAIL Houve falha na tentativa de ativar

algumas razões. Nesse caso, a

solicitação de processo nunca iniciará

a execução realmente.

HOLD HOLD O processo é inadequado para

ativação. Isso pode ocorrer devido às

dependências não atendidas.

QUEUED READY Pronto para ativar.

INITIATED INIT Tentando ativar.

PROCESSING EXEC Processo em execução.

CANCELLED CANCEL/ABEND* Processo cancelado.

SUCCESSFUL SUCC Execução bem-sucedida.

NOT SUCCESSFUL ABEND Falha na execução.

Notas:

1. Os processos cancelados no PeopleSoft serão interrompidos se já estiverem em

execução. O mapeamento de status do IBM Tivoli Workload Scheduler deve

refletir isso. Um processo cancelado que ainda não foi iniciado deve estar

marcado como CANCEL no Tivoli Workload Scheduler. Um processo que foi

iniciado deve estar marcado como ABEND.

2. Uma solicitação de processo marcada para exclusão no programador de

processo não pode ser adequada para ativação. O registro é eliminado da tabela


durante um processo de manutenção normal. Com objetivos de processamento

do jnextday, tais solicitações devem ser consideradas inexistentes.

Capítulo 12. Definindo os Jobs do PeopleSoft 81

Parte 4. Método de Acesso do R/3



O IBM Tivoli Workload Scheduler para Aplicativos do R3 fornece a habilidade para

criar, planejar e controlar jobs do R/3 utilizando os recursos de planejamento de

job do Tivoli Workload Scheduler.

Recursos

Com o IBM Tivoli Workload Scheduler para Aplicativos do R3, você pode fazer o

seguinte:

v Utilizar as dependências do job padrão do Tivoli Workload Scheduler e os

controles nos jobs do R/3.

v Criar jobs do R/3 utilizando a interface do Tivoli Workload Scheduler.

v Planejar jobs do R/3 para serem executados em dias e horas especificados e em

uma ordem predeterminada.

v Definir uma interdependência dos jobs do PeopleSoft e dos jobs do Tivoli

Workload Scheduler executados em diferentes aplicativos, como o PeopleSoft e o

Oracle.

v Definir uma interdependência dos jobs do R/3 e dos jobs executados em

diferentes plataformas.

v Definir as opções de suporte a idiomas nacionais.

v Definir como utilizar as funcionalidades do R/3 Business Warehouse Support.

v Personalizar os códigos de retorno de execução do job.

v Utilizar os grupos de logon do R/3 para equilíbrio de carga e tolerância a falhas.

v Trabalhar com variantes e marcadores do R/3.

v Explorar o suporte da interface do BC-XBP 2.0.

Planejando o Processo para o Agente Estendido do R/3

Tivoli Workload Scheduler ativa os jobs no R/3 como os jobs definidos para serem

executados na estação de trabalho de agente estendido do Tivoli Workload

Scheduler. Uma estação de trabalho de agente estendido do R/3 é definida como

uma estação de trabalho do Tivoli Workload Scheduler que é hospedada por um

FTA ou por uma estação de trabalho mestre que utiliza o método de acesso do

r3batch. A estação de trabalho de agente estendido do R/3 utiliza o método de

acesso do r3batch para transmitir informações específicas do job do R/3 para

predefinir as instâncias do R/3. O método de acesso utiliza as informações

fornecidas no arquivo de opções, discutido posteriormente neste guia, para

conectar e ativar jobs em uma instância do R/3. Várias estações de trabalho de

agente estendido podem ser definidas para utilizar o mesmo host; isso é feito com

o uso de várias entradas de opções ou vários arquivos de opções. Os jobs do R/3

definidos no Tivoli Workload Scheduler devem corresponder aos jobs existentes no

ambiente R/3. Com a utilização do nome do agente estendido do R/3 como uma

chave, o r3batch utilizará o arquivo de opções de correspondência para

determinar quais instâncias do R/3 executarão o job. Ele fará uma cópia de um job

de gabarito no R/3 e o marcará como ativo para execução, com uma data de início

início imediato. Finalmente, ele monitora o job até sua conclusão, gravando as

informações de andamento e de status do job em uma lista padrão de job

localizada na estação de trabalho do host.


Para obter informações adicionais sobre o gerenciamento do job, consulte o Guia de

Referência do IBM Tivoli Workload Scheduler SH19-4556.

Suporte à Interface do XBP 2.0

O Tivoli Workload Scheduler para Aplicativos do R3 suporta completamente a

Interface do XBP 2.0. Isso fornece as seguintes vantagens:

v Rastreamento de jobs filhos.

Um job do Tivoli Workload Scheduler permanece no status EXEC até que toda a

árvore do job do R/3 seja concluída. Os logs do job do R/3 são recuperados e

armazenados no Tivoli Workload Scheduler stdlist, juntamente com as listas de

spool de todas as etapas do ABAP.

v Interceptação de jobs do R/3.

Os jobs planejados por usuários do R/3 podem ser interceptados antes da

execução baseada nos atributos do job. Um job do Coletor de Interceptação é

planejado periodicamente como um comando do Unix ou do Windows. Em cada

execução, ele coleta jobs do R/3 interceptados e os envia ao plano atual com

base em um gabarito.

v Todos os atributos de job são mantidos quando os jobs são executados

novamente.

As limitações envolvendo os parâmetros de impressão/arquivamento e classes

de job em conjunto com o uso de cópias antigas de jobs executados novamente

são removidas.

v Etapas de comandos externos.

Consulte “Utilizando o Suporte a XBP 2.0” na página 98 para obter detalhes.


Capítulo 14. Instalação

Esta seção contém as informações sobre a instalação do IBM Tivoli Workload

Scheduler para Aplicativos do R3.


Para instalar o IBM Tivoli Workload Scheduler para Aplicativos do R3, é necessário

que os seguintes itens estejam em execução:

v IBM Tivoli Workload Scheduler versão 7.0 ou posterior ou o IBM Tivoli

Workload Scheduler para z/OS com ponto a ponto.

v R/3 versão 3.1g, 3.1h, 3.1i, 4.0x, 4.5x, 4.6x, 4.7, 6.10 ou 6.20.

v Para as versões mais antigas que 6.20, o R/3 Support Package adequado como

descrito na seguinte tabela:

Tabela 13. R/3 Support Packages.

Versões do R/3 Notas do R/3

R/3 3.1x 393708, 430087, 357924, 517672

R/3 4.0x 393708, 430087, 111696, 357924, 517672

R/3 4.5x 148436, 172245, 326202, 326752, 393708,

399449, 357924, 517672

R/3 4.6x 326752, 352606, 399449, 453135, 435111,

357924, 517672, 610480

R/3 4.7 610480

R/3 6.10 399449, 435111, 453135, 357924, 517672,

610480

Nota: As notas 399449 e 430087 do R/3 resolvem os problemas do parâmetro de

impressão. As notas 357924, 517672 e 519137 são independentes do release.

Visão Geral da Instalação

A seguir está uma visão geral do Tivoli Workload Scheduler para os Aplicativos

para as etapas de instalação do método de acesso R/3. Antes de instalar o método

de acesso, certifique-se de que o Tivoli Workload Scheduler esteja instalado

corretamente na estação de trabalho do host.

1. No sistema que será o host o agente estendido para o R/3, execute as seguintes

etapas:

a. Se a plataforma em que estiver instalando for Compaq Tru64, siga as

instruções descritas em “Instalando em Plataformas de Nível 2” na página

88. Caso contrário, siga as instruções descritas em Capítulo 2, “Instalando o

IBM Tivoli Workload Scheduler para Aplicativos”, na página 5.2. Instale os ABAPs do r3batch no sistema R/3. Para fazer isso:

a. Efetue login na instância do R/3 como um administrador ou um usuário

básico com as autorizações corretas.

b. Importe os arquivos de correção e transporte.


Instalando em Plataformas de Nível 2

1. Efetue logon como raiz e vá para o diretórioTWShome.

2. No CD_ROM de instalação extraia o software:

tar xvf cd_path/TWS4APPS_R3BATCH_OSF.TAR

em que cd_path é o nome de caminho da unidade de CD-ROM.

3. Verifique se r3setup e r3btar.Z foram extraídos com sucesso no diretório atual.

4. Execute o script r3setup para descompactar os arquivos, execute a instalação

inicial e cria o arquivo r3options:

/bin/sh r3setup -new|-update

em que:

-new

Especifica uma nova instalação. -update

Especifica que você está instalando sobre uma versão instalada

anteriormente.

Será necessário especificar as informações listadas abaixo. Consulte a seção

Capítulo 20, “Arquivos de Opções do Método de Acesso do R/3”, na página

119 para obter mais detalhes.

v O nome do usuário do Tivoli Workload Scheduler se for diferente do valor

padrão (o padrão: maestro).

v O diretório em que o agente estendido deve estar instalado (digite o caminho

para TWShome).

v O Usuário de Ativação LJuser (padrão: maestro). Esse é o nome do usuário do

Tivoli Workload Scheduler que executa o r3batch . Deve ser uma conta do

UNIX válida.

v O Usuário de Informações IFuser (padrão: maestro). Esse é o nome do usuário

do Tivoli Workload Scheduler que recupera informações de job. IFuser deve

ser o mesmo que LJuser.

v O tipo de definição de job JobDef (padrão: r3batch). Esse é o tipo de interface

de definição do job do Tivoli Workload Scheduler. Pode ser:

a. r3batch (padrão). Ele fornece uma interface de definição de job específica

para os jobs do R/3.

b. maestrogen ou em branco. Ele fornece uma interface de definição de job

padrão sem campos de entrada específicos do R/3.v O nome da CPU do host para a definição de agente estendido do Tivoli

Workload Scheduler.

v O nome do host do servidor de aplicativos R/3.

v Se quiser especificar um gateway host do R/3 separado, digite NÃO.

v O ID do sistema R/3 de três caracteres (por exemplo: OSS ou TRN).

v O número da instância do R/3 de dois dígitos (por exemplo: 00 ou 01).

v O número do cliente R/3 de três dígitos (por exemplo: 100 ou 900).

v O ID do usuário do R/3 para chamadas de RFC (por exemplo: rfcuser)

v A senha para o ID do usuário RFC do R/3.

v O nível de auditoria de interface do R/3 (padrão: 0)

v Se quiser definir o idioma de login do SAP R/3 para o agente estendido

nesse sistema R/3 (padrão Não)


v Se quiser definir outra instância do agente estendido. Se você responder Sim,

será necessário fornecer outro conjunto de parâmetros. Uma entrada

adicional é inserida no arquivo de opções do R/3.5. Abra o Tivoli Job Scheduling Console ou o programa Composer e crie uma

definição de estação de trabalho no Tivoli Workload Scheduler para cada

instância do R/3.

Criptografando Senhas de Usuário do R/3

Ao incluir entradas no arquivo de opções, o valor de r3pass é criptografado

automaticamente antes de ser gravado no arquivo. Se você modificar o arquivo

com um editor de texto, será necessário executar oprograma enigma para

criptografar a senha antes de gravá-la no arquivo. Execute o comando de

criptografia como se segue:

enigma [senha]

Você pode incluir a senha na linha de comando ou inseri-la como resposta a um

prompt. O programa retorna uma versão criptografada que pode ser inserida no

arquivo de opções.

Capítulo 14. Instalação 89

Capítulo 15. Configuração do R/3

Para comunicar e controlar a execução do job em sistemas R/3 utilizando o

método de acesso para o R/3, você precisará executar as seguintes etapas de

configuração no ambiente R/3.

As etapas descritas neste capítulo exigirão um Administrador de BASE do R/3.

Visão Geral

Aqui está uma visão geral do procedimento de personalização:

1. Crie um novo ID do usuário do RFC no R/3 para Tivoli Workload Scheduler.

2. Crie um perfil de autorização como descrito em “Criando o Perfil de

Autorização para o Usuário do Tivoli Workload Scheduler”.

3. Copie os arquivos de correção e transporte do servidor Tivoli Workload

Scheduler para o servidor R/3.

4. Importe os arquivos de correção e de transporte para o R/3 e verifique a

instalação.

Nota: O procedimento de importação inclui somente novos módulos de função

ABAP/4 e várias tabelas internas no sistema R/3. Ele não modifica nenhum

dos objetos existentes.

Criando um Usuário RFC do IBM Tivoli Workload Scheduler

Para o Tivoli Workload Scheduler se comunicar com o R/3, você deve criar um ID

do usuário no R/3 para o processamento do batch do Tivoli Workload Scheduler.

Por razões de segurança, utiliza um novo ID do usuário em vez de um existente.

1. Crie um novo ID do usuário RFC.

2. Forneça a esse novo ID do usuário RFC os seguintes atributos:

v Um tipo de usuário do CPIC ou Comunicações, dependendo do release do

R/3.

v Uma senha com seis caracteres no máximo. O Tivoli Workload Scheduler

exige essa senha para iniciar ou monitorar os jobs do R/3. Se essa senha for

alterada no R/3, você deverá atualizar o arquivo de opções utilizado pelo

r3batch com a nova senha.

v Atribua os perfis de segurança apropriados, dependendo da versão do R/3.

Criando o Perfil de Autorização para o Usuário do Tivoli Workload

Scheduler

Há duas formas para executar essa tarefa:

v Utilizando a transação SU02 e criando manualmente o perfil.

v Utilizando o Gerador de Perfil (transação PFCG).

Utilizando a Transação SU02 e Criando Manualmente o Perfil

Faça o seguinte:

1. Grave um nome de perfil, por exemplo Z_TWS, e uma descrição.


2. Inclua manualmente as autorizações de acordo com a tabela a seguir:

Objeto Descrição Autorização

S_ADMI_FCD Autorizações do Sistema S_ADMI_ALL

S_BTCH_ADM Processo em segundo plano:

administrador de plano de

fundo

S_BTCH_ADM

S_BTCH_JOB Processo em segundo plano:

Operações em jobs de plano

de fundo

S_BTCH_ALL

S_BTCH_NAM Processo em segundo plano:

nome do usuário de plano

de fundo

S_BTCH_ALL

S_PROGRAM ABAP: programa que

executa verificações

S_ABAP_ALL

S_RFC Verificação de autorização

para acesso do RFC

S_RFC_ALL

S_SPO_ACT pool: Ações S_SPO_ALL

S_SPO_DEV Spool: Autorizações de

dispositivo

S_SPO_DEV_AL

S_XMI_LOG Autorizações de acesso

interno para o log XMI

S_XMILOG_ADM

S_XMI_PROD Autorização para interfaces

de gerenciamento externo

(XMI)

S_XMI_ADMIN

As autorizações estão localizadas na classe de objeto ″Basis: Administration″.

Dependendo da versão do R/3, é possível que a autorização S_RFC_ALL esteja

localizada na classe de objeto ″objeto de Autorização de Vários Aplicativo″ ou

″objetos de Autorização Não Específicos ao Aplicativo″.

3. Salve o perfil.

4. Vá para a janela de manutenção do usuário e atribua o perfil ao usuário do

R/3 do Tivoli Workload Scheduler.

5. Salve os dados do usuário.

Utilizando a Transação PFCG (Gerador de Perfil)

Faça o seguinte:

1. Grave um nome, por exemplo ZTWS, em Nome da Função.

2. Clique em Criar Função e grave uma descrição para a função, como ″Função

para o usuário do TWS″.

3. Salve a função.

4. Selecione a guia Autorizações.

5. Clique em Alterar Dados da Autorização.

6. No pop-up exibido, selecione Gabaritos.

7. Inclua manualmente os seguintes objetos de autorização:

Objeto Descrição

S_ADMI_FCD Autorizações do Sistema


Objeto Descrição

S_BTCH_ADM Processo em segundo plano: administrador de

plano de fundo

S_BTCH_JOB Processo em segundo plano: Operações em jobs de

plano de fundo

S_BTCH_NAM Processo em segundo plano: nome do usuário de

plano de fundo

S_PROGRAM ABAP: programa que executa verificações

S_RFC Verificação de autorização para acesso do RFC

S_SPO_ACT pool: Ações

S_SPO_DEV Spool: Autorizações de dispositivo

S_XMI_LOG Autorizações de acesso interno para o log XMI

S_XMI_PROD Autorização para interfaces de gerenciamento

externo (XMI)

8. Preencha os valores de acordo com o seguinte esquema:

S_ADMI_FCD Autorizações do Sistema

v Funções de administração de sistema:

Autorização total

S_BTCH_ADM Processo em segundo plano: administrador de

plano de fundo

v ID do administrador de plano de fundo:

Autorização total

S_BTCH_JOB Processo em segundo plano: Operações em jobs de

plano de fundo

v Operações de job: Autorização total

v Resumo dos jobs para um grupo: Autorização

total

S_BTCH_NAM Processo em segundo plano: nome do usuário de

plano de fundo

v Nome do usuário de plano de fundo para

verificação de autorização: Autorização total

S_PROGRAM ABAP: programa que executa verificações

v Programa ABAP/4 de ação do usuário:

Autorização total

v Programa ABAP/4 de grupo de autorização:

Autorização total

S_RFC Verificação de autorização para acesso do RFC

v Atividade: Autorização total

v Nome do RFC a ser protegido: Autorização total

v Tipo de objeto RFC a ser protegido: Autorização

total

S_SPO_ACT Spool: Ações

v Campo Autorização para ações de spool:

Autorização total

v Valor para a verificação de autorização:

Autorização total

Capítulo 15. Configuração do R/3 93

S_SPO_DEV Spool: Autorizações de dispositivo

v Spool - nomes de dispositivo longos: Autorização

total

S_XMI_LOG Autorizações de acesso interno para o log XMI

v Método de Acesso para o log XMI: Autorização

total

S_XMI_PROD Autorização para interfaces de gerenciamento

externo (XMI)

v Log XMI - Nome da companhia: TIVOLI*

v Log XMI - Nome do programa: MAESTRO*

v ID da interface: Autorização total

9. Salve as autorizações.

10. Gere um perfil. Utilize o mesmo nome gravado em Nome da Função.

11. Saia da janela de gerenciamento de autorização e selecione a guia Usuário.

12. Inclua o usuário do Tivoli Workload Scheduler na função.

13. Salve a função.

Copiar os Arquivos de Correção e de Transporte

O arquivo de configuração carrega dois arquivo de correção e de transporte no

diretório inicial do Tivoli Workload Scheduler. Você deve copiar esses arquivos de

correção e de transporte no servidor R/3 e importá-los para o banco de dados do

R/3, como se segue:

1. No servidor de banco de dados do R/3, efetue logon no sistema R/3 como

administrador.

2. Copie o arquivo de controle e o arquivo de dados do diretório

TWShome\methods para os seguintes diretórios no servidor de banco de dados

do R/3:

copiar controlfile /usr/sap/trans/cofiles/

copiar datafile /usr/sap/trans/data/

Os nomes de controlfile e datafile variam de release para release. Os arquivos são

instalados no diretório TWShome\methods e têm os seguintes nomes de

arquivo e formatos: K000xxx.TV1 (arquivo de controle) e R000xxx.TV1 (arquivo

de dados), em que xxx é um valor listado ao release.

Importar Módulos ABAP/4 para R/3

Esse procedimento gera, ativa e envolve novos módulos de função ABAP/4 no

sistema R/3 e várias novas tabelas internas. Nenhum objeto do sistema R/3

existente é modificado.

1. Altere para o seguinte diretório:

cd /usr/sap/trans/bin

2. Inclua o arquivo de transporte no buffer:

tp addtobuffer transport sid

em que:

transport

é o arquivo de solicitação de transporte. sid

é o ID do sistema R/3.


No diretório TWShome\methods, você pode localizar um arquivo chamado

K000xxx.TV1, então a solicitação de transporte será tv1K000xxx.

3. Execute o comando tp tst para testar a importação:

tp tst transport sid

Após a execução desse comando, analise os arquivos de log no diretório

/user/sap/trans/log para verificar a existência de mensagens de erro. Avisos

de nível de gravidade 4 são normais.

Se você encontrou erros, converse com um técnico em correção e transporte ou

tente utilizar modos incondicionais para realizar a importação.

4. Execute o seguinte comando para importar todos os arquivo para o buffer:

tp import transport sid

Esse comando gera os novos módulos ABAP/4 e os coloca no banco de dados

do R/3. Eles se tornam ativos automaticamente.

Após a execução desse comando, analise os arquivos de log no diretório

/user/sap/trans/log para verificar a existência de mensagens de erro. Avisos

de nível de gravidade 4 são normais.

Se você encontrar um problema, utilize modos incondicionais ao executar essa

etapa:

tp import transport sid U126

5. Quando a importação estiver concluída, verifique os arquivos de log para

verificar se a importação foi bem-sucedida. Os arquivos de log estão no

diretório /usr/sap/trans/log.

Instalando os Módulos ABAP do r3batch no Sistema R/3

Instalar os módulos ABAP do r3batch no sistema R/3. Para obter detalhes sobre a

instalação de módulos ABAP do r3batch, consulte Capítulo 15, “Configuração do

R/3”, na página 91. Este capítulo inclui instruções para a criação de um usuário

RFC e sobre a instalação dos seguintes módulos ABAP:

J_1O1_BDC_STATUS

J_1O1_DATE_TIME

J_1O1_JOB_ABAP_STEP_MODIFY

J_1O1_JOB_ADD_ABAP_STEP

J_1O1_JOB_ADD_EXTPGM_STEP

J_1O1_JOB_CLOSE

J_1O1_JOB_COPY

J_1O1_JOB_DEFINITION_GET

J_1O1_JOB_DELETE

J_1O1_JOB_EXTPGM_STEP_MODFY

J_1O1_JOB_FIND

J_1O1_JOB_FINDALL

J_1O1_JOB_HAS_EXTENDED_VARIANT

J_1O1_JOB_LOG

J_1O1_JOB_LOG_READ

J_1O1_JOB_OPEN

J_1O1_JOB_START

J_1O1_JOB_STATUS

J_1O1_JOB_STATUS_CHECK

J_1O1_JOB_STOP

J_1O1_RAISE_EVENT

J_1O1_REPORT_ALL_SELECTIONS

J_1O1_REPORT_DYNSEL_GET_DEF

J_1O1_REPORT_GET_TEXTPOOL

J_1O1_TABLE_GET_NAMETAB

J_1O1_VARIANT_COPY

J_1O1_VARIANT_COPY_4X

J_1O1_VARIANT_CREATE

J_1O1_VARIANT_CREATE_NEW


J_1O1_VARIANT_DELETE

J_1O1_VARIANT_DELETE_NEW

J_1O1_VARIANT_EXISTS

J_1O1_VARIANT_GET_DEFINITION

J_1O1_VARIANT_GET_DEF_NEW

J_1O1_VARIANT_GET_HELP_VALUES

J_1O1_VARIANT_INFO_GET

J_1O1_VARIANT_MAINTAIN_CNT_TBL

J_1O1_VARIANT_MAINTAIN_SEL_TBL

J_1O1_VARIANT_MODIFY

J_1O1_VARIANT_MODIFY_NEW

Resolução de Problemas

Se você não puder enviar jobs do R/3 utilizando o Tivoli Workload Scheduler após

a configuração do R/3, execute os seguintes testes:

v Verifique se é possível executar ping no sistema R/3 a partir do sistema Tivoli

Workload Scheduler. Isso mostrará a conectividade básica da rede.

v Observe que a utilização de roteadores do R/3 para acessar o sistema R/3 pode

exceder o tamanho do buffer interno da biblioteca RFC utilizada para armazenar

o nome do host do sistema R/3. Quando isso ocorre, o nome do host fica

truncado causando uma falha na conexão para o sistema R/3. Para solucionar

esse problema, não qualifique o nome dos roteadores do R/3 totalmente ou, de

modo alternativo, utilize os endereços IP.

v Execute o seguinte comando telnet para verificar a conectividade:

telnet systemname 33xx

em que systemname é o nome do sistema ou o endereço IP do servidor R/3 e xx

é a instância do R/3.

v Efetue logon no sistema R/3 como um administrador e verifique se o usuário

RFC do Tivoli Workload Scheduler (criado em “Criando um Usuário RFC do

IBM Tivoli Workload Scheduler” na página 91) existe.

v Crie um novo job do IBM Tivoli Workload Scheduler a ser executado no R/3 e

inclua as seguintes opções avançadas:

-debug

-trace

Essas opções são selecionadas com o uso de botões de opções na página

Propriedades - Tarefa de Definição de Job no Console de Planejamento do Job.

Utilizando a opção -debug, informações adicionais de depuração são incluídas

no arquivo de job stdlist (em Tivoli Workload Scheduler).

Quando você utiliza a opção -trace, um arquivo de rastreamento é criado no

diretório inicial do Tivoli Workload Scheduler. No UNIX, esse arquivo de

rastreamento é chamado dev_rfc. No Windows, o arquivo é chamado

rfcxxxxx_xxxxx.trc. Verifique se você excluiu a opção de rastreamento do job

depois de executar os procedimentos de depuração. O arquivo de

rastreamento pode tornar-se muito grande e impossível de gerenciar.

Nota: Normalmente essas opções são para depuração do agente estendido e

não devem ser utilizadas na produção padrão.v Se por alguma razão o gateway do R/3 truncar a cadeia de conexão, substitua

o nome IP pelo endereço IP.

v Se estiver instalando em um sistema AIX que não utiliza o idioma inglês

americano, será necessário instalar o Ambiente de Idioma Americano na

estação de trabalho do IBM Tivoli Workload Scheduler e do banco de dados

R/3. Caso contrário, o erro BAD TEXTENV (ou uma mensagem de erro

semelhante) pode ser exibido no arquivo de rastreamento dev_rfc e as

conexões para o R/3 irão falhar.


Alterando a Senha de ID do Usuário RFC do Tivoli Workload Scheduler

Se a senha de ID do usuário RFC do Tivoli Workload Scheduler for modificada

após a instalação inicial, o arquivo de opções utilizado pelo r3batch deverá ser

atualizado com essa alteração.

No UNIX, efetue logon como raiz no sistema em que o Tivoli Workload Scheduler

está instalado.

No Windows, efetue logon como um administrador e inicie o shell do DOS no

sistema em que o Tivoli Workload Scheduler estiver instalado, como se segue:

1. Gere uma versão criptografada da nova senha utilizando o comando enigma

em TWShome/methods. Para fazer isso em um shell de comando, digite:

enigma newpass

em que newpass é a nova senha para o ID do usuário RFC do Tivoli Workload

Scheduler.

O comando enigma emite uma versão criptografada da senha.

2. Copie a senha criptografada no arquivo de opções, que está localizado no

diretórioTWShome/methods. O arquivo pode ser editado com qualquer editor de

texto.

Certifique-se de copiar a senha de forma exata, preservando letras maiúsculas,

minúsculas e a pontuação. A senha criptografada é semelhante a:

#TjM-pYm#-z82G-rB

Se a senha criptografada for digitada de forma incorreta, o Tivoli Workload

Scheduler não poderá iniciar ou monitorar os jobs do batch do R/3.

Migrando de Versões Anteriores

Essa versão do agente estendido do Tivoli Workload Scheduler para o R/3 suporta

todas as versões do R/3 listada na Tabela 13 na página 87. Para obter a certificação

XBP do R/3 para as versões 4.0 e 4.5 do R/3, algumas alterações devem ser feitas

no agente de planejamento. O agente estendido do Tivoli Workload Scheduler para

a versão 4.x do R/3 utiliza interfaces RFC do R/3 oficiais para o planejamento do

job. São elas:

v A interface SXMI_XBP para as versões 3.1g a 4.0x do R/3

v A interface BAPI_XBP desde a versão 4.5a

Para evitar conflitos com outros fornecedores os módulo ABAP do Tivoli Workload

Scheduler pertencem, agora, ao espaço de nomes do parceiro do Tivoli Workload

Scheduler J_1O1_xxx. Após a conclusão da importação como descrito em “Importar

Módulos ABAP/4 para R/3” na página 94, os módulos de função RFC J_1O1_xxx

são instalados no sistema.

Se houver uma instalação anterior do agente estendido do Tivoli Workload

Scheduler para R/3 no sistema, você poderá excluir os seguintes módulos de

função do sistema R/3:

Z_MAE2_BDC_STATUS

Z_MAE2_DATE_TIME

Z_MAE2_JOB_COPY

Z_MAE2_JOB_DELETE

Z_MAE2_JOB_FIND

Z_MAE2_JOB_FINDALL

Z_MAE2_JOP_OPEN


Z_MAE2_JOB_LOG

Z_MAE2_JOB_START

Z_MAE2_JOB_STATUS

Z_MAE2_JOB_STOP

Essas são versões antigas de funções do Tivoli ABAP, que pertencem ao espaço de

nomes do cliente. Você também pode excluir o grupo de função YMA3. Não é

necessário excluir os módulos de função e o grupo de funções, mas você pode

fazer isso se desejar limpar o sistema.

Utilizando o Suporte a XBP 2.0

A interface SAP para planejamento de job externo (BC-XBP) foi estendida

recentemente para remover as limitações relatadas por clientes e parceiros. Ela é

fornecido pelo Basis Support Packages para todos os releases do R/3, começando

do WAS 4.6B.

As seguintes limitações foram removidas:

v A classe de job não é mais limitada a C

v Todos os parâmetros de impressão estão disponíveis

Os seguintes recursos foram incluídos:

v Relacionamento pai-filho

v Interceptação de job

v Suporte para jobs com etapas de comando externo

Verifique e aplique as seguintes notas SAP antes de utilizar a interface XBP 2.0 :

v 602683

v 612564

v 604496

Criando o Perfil de Autorização para o Usuário do Tivoli

Workload Scheduler

Há duas formas alternativas de incluir o objeto de autorização listado no perfil de

autorização do usuário do Tivoli Workload Scheduler:

v Utilizando a Transação SU02

v Utilizando o Gerador de Perfil

Utilizando a Transação SU02

Inclua o seguinte objeto:

Objeto Descrição Autorização

S_RZL_ADM CCMS: Administração de Sistema S_RZL_ALL

Utilizando o Gerador de Perfil

Faça o seguinte:

1. Inclua manualmente o seguinte objeto:

Objeto Descrição

S_RZL_ADM CCMS: Administração de Sistema

2. Defina o valor do campo de atividade para Autorização Total.


Imprimir Parâmetros e Problemas de Classe Job

O agente estendido para R/3 utiliza a interface RFC oficial do R/3 Versões 4.x à

6.20 para planejamento de job. Ao migrar de versões anteriores do R/3, pode haver

problemas para imprimir parâmetros nos jobs ativados pelo Tivoli Workload

Scheduler. Isso ocorre devido limitações nas interfaces RFC.

Estas limitações não são mais verdadeiras com XBP 2.0.

A tabela a seguir mostra os parâmetros de impressão suportados pelo API XBP 1.0.

Parâmetros de

Impressão 3.1x 4.0x

4.5x e posterior

dispositivo de saída U U U

imprimir

imediatamente

U U U

excluir após saída U U U

número de cópias U U U

modo de

arquivamento

U U U

autorização U U U

página de capa de

seleção

x U U

página de capa sap U U U

período de retenção

de spool

U U U

destinatário x x U

linhas x x U

colunas x x U

Para resolver a perda dos parâmetros de impressão durante a cópia do job, instale

o Support Package apropriado para o R/3, como declarado nas notas do R/3

399449 e 430087.

O mesmo se aplica à classe de job. As interfaces oficiais do R/3 permitem somente

jobs de classe C. Instalar o Support Package para R/3 também resolve esse

problema.


Capítulo 16. Definindo Jobs de Agente Estendido do R/3

Para controlar a execução do job na estação de trabalho do R/3 a partir do Tivoli

Workload Scheduler você deve definir o seguinte:

v Jobs no R/3 que você deseja executar sob o controle do Tivoli Workload

Scheduler. Você pode definir esses jobs utilizando as ferramentas padrão do R/3

ou as janelas específicas do SAP do Job Scheduling Console.

v Jobs no Tivoli Workload Scheduler que correspondem aos jobs no R/3. As

definições de job do Tivoli Workload Scheduler são utilizadas no planejamento e

na definição de dependências, mas os jobs do R/3 são realmente executados.

Definindo um Job no R/3

Para criar jobs do R/3 que são controlados pelo Tivoli Workload Scheduler, utilize

o seguinte:

v As ferramentas do R/3 padrão para definir jobs

v As janelas específicas do SAP do Job Scheduling Console.

Consulte a documentação do R/3 para obter informações sobre como criar jobs

com as ferramentas do R/3. Ao criar jobs no R/3, não atribua uma hora de início e

não especifique nenhuma dependência. Elas são controladas e especificadas no

Tivoli Workload Scheduler. O job é identificado no Tivoli Workload Scheduler pelo

seu nome de job do R/3 e pelo ID de job. O mesmo job pode ser planejado para

ser executado repetidamente pelo Tivoli Workload Scheduler sem ter que

redefini-lo mais de uma vez no R/3.

Nota: Para os jobs do R/3 controlados pelo Tivoli Workload Scheduler, a saída de

log do job no R/3 é encontrada abaixo do nome do usuário definido na

opção r3user do arquivo de opções.

Definindo um Job no Tivoli Workload Scheduler

Para definir o job do Tivoli Workload Scheduler, você pode utilizar:

v O Tivoli Job Scheduling Console.

v A linha de comando do Tivoli Workload Scheduler.

v Os diálogos ISPF do Tivoli Workload Scheduler para z/OS, se você deseja

planejar o job em um ambiente ponto a ponto.


obter referência.

Os procedimentos descritos no Capítulo 5, “Definindo os Jobs de Agente

Estendido”, na página 37 são comuns a todos os agentes estendidos do Tivoli

Workload Scheduler. O agente estendido para R/3 fornece um adicional por meio

do Job Scheduling Console.

No Job Scheduling Console, quando você seleciona o tipo de tarefa para uma nova

definição de job, é possível escolher entre dois tipos:

Tarefa de Agente Estendido

Ela é comum a todos os agentes estendidos. Se você selecionar essa opção:


v O job do R/3 associado deverá ser definido no banco de dados do R/3 e

você precisa saber o nome dele.

v Você pode utilizar o campo Comando em uma das janelas de definição

do job para inserir parâmetros para executar o job do R/3.

v As estações de trabalho de agente estendido definidas para o R/3

(especificando r3batch como o método de acesso) são listadas como

estações de trabalho de agente estendido genérico.

SAP É específico para jobs de agente estendido do R/3. Se você selecionar essa

opção:

v Você pode definir ou atualizar o job do R/3, bem como as variantes ou

os parâmetros SAP para executar o job, a partir das janelas do Job

Scheduling Console, como se estive operando no R/3.

v As estações de trabalho agente estendido do R/3 são consideradas

estações de trabalho R/3. Elas não são mostradas nas listas de estações

de trabalho de agente estendido genéricas exibidas quando você clica na

elipse próxima do campo Estação de Trabalho. Você deve saber o nome

para gravá-lo em um campo.

Para que o SAP seja exibido como uma tarefa opcional no Job Scheduling Console,

você deve definir a opção jobdef para o r3batch no arquivo de opções

r3batch.opts (localizado no subdiretório methods de TWShome ) do master do


Para aprender como definir um job de agente estendido do R/3, utilizando a

janelaTarefa de Agente Estendido, consulte Capítulo 5, “Definindo os Jobs de

Agente Estendido”, na página 37. Para aprender como definir um job de agente

estendido do R/3 utilizando a janela de tarefas SAP, consulte a próxima seção.

Utilizando Janelas Específicas do SAP do Job Scheduling

Console

Para criar uma definição de job no banco de dados do Tivoli Workload Scheduler

para um job do R/3, execute as seguintes etapas:

1. Na lista Ações da janela principal do Console de Planejamento de Job, selecione

Nova Definição de Job.

2. Selecione um mecanismo do Tivoli Workload Scheduler e, a partir da lista

resultante, clique em SAP. A janela Propriedades - Definição de Job é exibida.


3. Na página geral, você define o job do Tivoli Workload Scheduler que

direcionará o job do R/3. Complete os seguintes campos:

a. No campo Nome, insira o nome do Tivoli Workload Scheduler para o job

do R/3. O nome pode contar oito ou 40 caracteres alfanuméricos, se você

estiver utilizando a opção de banco de dados expandida. O nome do job

deve começar com uma letra.

b. No campo Estação de Trabalho, clique no botão de elipse (...) para abrir a

janela Localizar e selecione uma estação de trabalho disponível.

c. No campo Descrição, digite uma descrição para o job. Esse campo é uma

descrição de texto opcional do job e pode conter até 64 caracteres

alfanuméricos.

d. No campo Login, insira o ID de logon do Tivoli Workload Scheduler usado

para executar o job.

e. Clique em Incluir Parâmetro para incluir os parâmetros predefinidos para o

ID de logon .

f. No campo Opções de Recuperação, especifique quaisquer opções de

recuperação para o job do R/3. Consulte o IBM Tivoli Workload Scheduler -

Guia de Referência para obter informações sobre as opções de recuperação.4. Selecione Tarefa. A página Tarefa é exibida.

Figura 26. Propriedades - Definição de Job

Capítulo 16. Definindo Jobs de Agente Estendido do R/3 103

Nessa página, insira as especificações do job do R/3 que serão direcionadas

pelo job do Tivoli Workload Scheduler definido nas páginas anteriores. Você

pode utilizar essa página para criar os jobs do R/3 padrão(mas não

InfoPackages ou Process Chains) no sistema SAP .

5. Para especificar um job do R/3 existente:

a. Na página Tarefa, especifique o tipo de job e clique na elipse (...) próxima

ao campo Nome do Job. A janela SAP Pick List é exibida.

b. Utilize a pick list para localizar e selecionar um job do R/3 e clique em OK.

As informações do job são exibidas nos seguintes itens de volta na página

Tarefa:

v campo Nome do Job

v campo ID do Job

v botão Tipo de Job do R/3

Se o tipo de job for o Job do R/3 Padrão, você poderá editá-lo e ver seus

detalhes e o status.

Se o tipo de job for Business Warehouse Info Package ou Process Chain,

você poderá ver somente os detalhes.6. Para criar um job do R/3 padrão:

a. Na página Tarefa, selecione Job do R/3 Padrão e clique em Novo. A página

Job do R/3 da janela Definição de Job do SAP é exibida.

Figura 27. Tarefa Propriedades - Definição de Job


b. Na página Job do R/3, insira as informações sobre o job que você está

criando:

1) Digite um nome para o job do R/3 no campo Nome do Job.

2) Deixe o campo ID do Job em branco. Um ID será atribuído pelo sistema

R/3 quando você salvar a definição de job.

3) Digite o nome da estação de trabalho R/3 em que esse job será

executado no campo Host de Destino.

4) Clique em Etapas para abrir a seguinte página.

Figura 28. A página Job do R/3 da janela Definição de Job do SAP.


c. Na página Etapas você pode especificar um ou mais ABAPs ou programas

externos para o job do R/3. Repita as seguintes etapas para o número de

etapas a serem definidas:

1) Clique no botão Incluir Linha para incluir uma linha na tabela de

etapas.

2) Dê um clique duplo no campo Tipo e selecione se ele é um ABAP ou

um programa externo.

3) No campo Nome, digite um nome do ABAP ou um caminho e um nome

de arquivo totalmente qualificado para um programa externo.

4) No campo Usuário, digite o nome do usuário do R/3 que executa essa

etapa.

Figura 29. A página Etapas da janela Definição de Job do SAP.


5) No campo Var/Parâm, digite um nome de variante ou um parâmetro, se

necessário. As variantes são utilizadas com os ABAPs e os parâmetros

com os programas externos, mas ambos são opcionais. Nem todos os

ABAPs exigem variantes e nem todos os programas externos exigem

parâmetros. Um botão de elipse (...) está disponível próximo ao campo

para exibir a lista de variantes associadas com o ABAP. Você pode

utilizar essa lista para selecionar uma variante bem como para criar ou

alterar definições de variante. Consulte “Definindo ou Atualizando

Variantes do R/3 a partir do Job Scheduling Console” para obter

detalhes.

6) No campo Host de Destino, insira a estação de trabalho R/3 em que

esta etapa está sendo executada. Os hosts de destino são necessários

somente para os programas externos.

7) Insira os parâmetros de impressão e as especificações de sinalizadores de

controle de acordo com os requisitos do R/3.d. Quando você concluir a criação das etapas de ABAP ou de programas

externos, clique em OK. A definição de job do R/3 é salva no banco de

dados do R/3 e a janela é fechada. Se os jobs do R/3 forem salvos com

sucesso no banco de dados do R/3, a página Propriedades - Tarefa de

Definição de Job deverá exibir um ID de job do R/3.7. Clique em OK na janela Propriedades - Definição de Job para salvar a definição

do job no banco de dados do Tivoli Workload Scheduler.

Definindo ou Atualizando Variantes do R/3 a partir do Job

Scheduling Console

A ação de clicar na elipse ao lado do campo Var/Parâm na janela Definição de Job

do SAP exibe uma janela Lista de Variantes. Essa janela lista todas as variantes

associadas ao ABAP fornecido no campo Nome na Definição de Job do SAP e

lembrada na seguinte figura.


Nessa janela, além das outras ações, você pode criar ou atualizar variantes. Para

fazer isso, clique em Novo ou em Editar. Uma janela Estrutura de Variante

semelhante a essa é exibida (se você estiver fazendo edições, os campos e as

seleções não ficarão vazios):

Figura 30. A janela Lista de Variantes.


Na página Informações da Variante faça o seguinte:

1. Insira/modifique o nome e a descrição da variante.

2. Opcionalmente, verifique a caixa Propriedades:

Plano de Fundo

A variante pode ser utilizada somente em processamento em segundo

plano.

Protegida

A variante está protegida contra alterações feitas por outros usuários.

Invisível

A variante não será exibida na lista de valor F4 na GUI do SAP.

Estendido

Permite o uso de marcadores e cronômetros como valores de variante.

Se você marcar essa caixa, o botão cronômetro estará disponível.

Para as variantes estendidas, você pode usar marcadores e cronômetros que

eliminam a tarefa error-prone de valores de ajuste e portanto minimiza

automaticamente o esforço para a manutenção da variante. Os marcadores e os

cronômetros são pré-processados pelo Tivoli Workload Scheduler e os valores

são automaticamente ajustados quando o job é ativado. Os marcadores e os

cronômetros suportados são:

Tabela 14. Marcadores e Cronômetros para Variantes Estendidas.

Símbolo Significado Sintaxe

$S Data e hora AAAAMMDDHHMM

$D Dia do mês DD

$_D Data AAAAMMDD

Figura 31. A página Informações da Variante da janela Lista de Variantes.


Tabela 14. Marcadores e Cronômetros para Variantes Estendidas. (continuação)

Símbolo Significado Sintaxe

$M Mês MM

$Y Ano AA

$_Y Ano AAAA

$H Hora HH

$T Minuto MM

$_T Hora HHMMSS

$Nx Cronômetros 10 cronômetros: $N0 - $N9

($N = $N0)

$(date expression) Expressão de date Como o comando datecalc.

Entre o sinal $( e ).

$[arithmetic expression] Expressão aritmética As expressões aritméticas

permitem operações de +, −,

*, e / entre números inteiros

e de cronômetro.

Na página Valores da Variante, os campos e os valores são criados dinamicamente

por meio do r3batch dependendo das características da variante ou da etapa e são

idênticos àqueles contidos no janela SAP equivalente.

Parâmetros da Cadeia de Tarefas para Jobs do R/3


jobs do R/3. Você deve especificá-los nos seguintes locais ao definir os jobs do

Tivoli Workload Scheduler associados:

v No campo Comando da página Tarefa da janela Propriedades - Definição de Job,

você utilizará o Job Scheduling Console e Tarefa de Agente Estendido (e não

SAP) para uma nova definição de job.






A sintaxe da cadeia é a seguinte:

-job job_name ( -user user_name | -i (job_id|ipack_|pchain_) )

[-client def_client] [-exec_client exec_client] [-debug] [-trace]

Os parâmetros são descritos na tabela a seguir.

Tabela 15. Parâmetros da Cadeia de Tarefas para Jobs do R/3.


-job job_name

O nome da tarefa que deve ser executada.

É o nome do job do R/3, o nome do

campo do técnico do InfoPackage ou o

nome do ProcessChain. Esse parâmetro é

obrigatório.


Tabela 15. Parâmetros da Cadeia de Tarefas para Jobs do R/3. (continuação)


-user user_name

O usuário do R/3 que possui o job de

destino. Esse parâmetro pode ser utilizado

somente quando um sistema R/3 de

destino tem um job com o nome

especificado para o usuário determinado.

Ele não tem efeito nos jobs InfoPackage ou

ProcessChain, nem se um ID de job tiver

sido especificado no definição do job.

-i job_id

Um dos seguintes:

v Um ID de job do R/3 exclusivo, se o job

de destino for padrão.

v ipack_, se o job de destino for

InfoPackage.

v pchain_, se o job de destino for

ProcessChain.

Os parâmetros -user, -client e

-exec_client não terão efeito, se você

especificar um ID de job. Para os jobs de

InfoPackage e de ProcessChain, esse

parâmetro é obrigatório.

-client def_client

O número identificando o cliente R/3 em

que a definição do job deve ser

encontrada, independentemente do

número do cliente definido pela chave

r3client no arquivo de opções. Esse

parâmetro não tem efeito com jobs de

InfoPackage ou de ProcessChain, nem se

um ID de job tiver sido especificado na

definição de job.

-exec_client exec_client

O número identificando o cliente R/3 em

que o job deve ser executado,

independentemente do número do cliente

definido pela chave r3client no arquivo

de opções. Esse parâmetro não tem efeito

com jobs de InfoPackage ou de

ProcessChain, nem se um ID de job tiver

sido especificado na definição de job.

-debug

Ativa o rastreamento mais verboso do

r3batch.

-trace

Ativa o rastreamento de SAP RFC.

Notas:

1. Você pode especificar -i e -user na mesma definição de job, porém o nome do

usuário será ignorado.

2. Ao especificar o ID do job, -client e -exec_client são ignorados, pois o ID é

exclusivo para o sistema R/3 inteiro.

Este é um exemplo para um job do R/3 chamado BVTTEST com ID 03102401 e

usuário myuser:

-job BVTTEST –i 03102401 -debug


Este é um exemplo para o job do InfoPackage cujo nome técnico do campo é

ZPAK_3LZ3JRF29AJDQM65ZJBJF5OMY:

-job ZPAK_3LZ3JRF29AJDQM65ZJBJF5OMY -i ipak_

Os Estados de Job do Tivoli Workload Scheduler e do R/3

Quando um job do R/3 for ativado pelo Tivoli Workload Scheduler, você poderá

monitorar seu progresso. A transição de status no Tivoli Workload Scheduler

(status interno) e o status do R/3 correspondente são listados na tabela a seguir.

Estado do Job do Tvoli Workload Scheduler Estado do Job do R/3

INTRO N/D

WAIT Pronto

EXEC Ativo

SUCC Concluído

ABEND Cancelado

O estado INTRO indica que o Tivoli Workload Scheduler está no processo de

introdução do job, mas no R/3, o job ainda não está no estado Pronto. Como ele

leva algum tempo para colocar o job em fila e na coluna pronto, o estado INTRO

pode demorar alguns minutos se o sistema R/3 estiver particularmente ocupado.

Embora um job possa ser concluído no R/3, o Tivoli Workload Scheduler o

manterá no estado EXEC se as sessões BDC não estiverem concluídas e se você não

tiver selecionado a opção Disable BDC Wait. Para utilizar essa opção, consulte

Capítulo 21, “BDC Wait”, na página 127.


Capítulo 17. Executando Jobs Novamente

Antes de executar um job R/3 novamente com o Tivoli Workload Scheduler, você

pode optar por fornecer um nome de etapa para o job. Ao fazer isso, o r3batch será

afetado da seguinte maneira: se o nome da etapa tiver o formato “xnnnnnn” ou

“nnnnnnn” (em que “x” é um caractere sem dígito e “n” é um caractere de dígito),

então ele é utilizado como o número da etapa de início para a nova execução do

job do R/3.

Em todos os outros casos, esse valor não terá efeito na nova execução do job. O job

é executado novamente, iniciando da primeira etapa.

Somente quando o r3batch executa novamente um job a partir da primeira etapa,

porque o usuário o especificou como a etapa de início ou porque não foi

especificada nenhuma etapa de início, ele utiliza o recurso nova cópia, se aplicável.

Se a etapa de início for maior que essa, então o r3batch utilizará a cópia antiga para

executar o job novamente.

A seção a seguir explica a principal diferença entre a cópia nova e a antiga de um

job executado novamente.

Cópia Antiga e Cópia Nova de um Job Executado Novamente

Quando um método de acesso para o R/3 precisa lançar um job, ele faz uma cópia

de um job de gabarito e o executa.

O recurso de nova cópia está disponível para as versões 3.1i ou posterior do R/3.

Ele copia um job junto, preservando as etapas, a classe do job e todos os

parâmetros de impressão e arquivamento. Ele é executado com o uso de um novo

módulo de funções do R/3 que está incluído no R/3 Support Package, como

declarado nas notas do R/3 399449 e 430087.

Ao contrário, o recurso de cópia antiga, baseado nos módulos de função do R/3

padrão, cria um novo job do R/3 e inclui as etapas com um loop iniciado a partir

do nome ou número da etapa especificada. Certifique-se de que, exceto se você

tiver suporte para XBP 2.0 :

v A cópia antiga não preserva todos os parâmetros de impressão e arquivamento.

v A classe do job da cópia está definida sempre como a classe ″C″.

Consulte a seção “Imprimir Parâmetros e Problemas de Classe Job” na página 99

para aprender como resolver o problema de perda dos parâmetros da classe do job,

de impressão e de arquivamento.


Capítulo 18. Business Information Warehouse

Business Information Warehouse Support - InfoPackages

O BIW (Business Information Warehouse) é uma solução de armazém de dados

específica para o R/3. Ela permite o relato dos negócios e o suporte à decisões.

Autorizações do Usuário

O Tivoli Workload Scheduler para Aplicativos do R3 pode gerenciar o R/3 BIW

Info Packages e o Process Chains. Para utilizar a funcionalidade do R/3 BIW, é

necessário definir um usuário do Tivoli Workload Scheduler R/3 dentro do R/3

que necessite as seguintes autorizações adicionais:

As autorizações na tabela abaixo são necessárias somente se você desejar utilizar as

funcionalidades do Business Warehouse para o agente estendido.

Objeto Texto Autorização

S_DEVELOP ABAP Workbench E_ABAP_ALL

Nota: Além do perfil Z_MAESTRO, o perfil S_RS_ALL precisa ser incluído no

usuário do Tivoli Workload Scheduler.

Componentes do Business Warehouse

O R/3 suporta dois componentes principais do BIW, InfoPackages e Process

Chains.

Um InfoPackage é um ponto de entrada para o processo de carga de um

determinado InfoSource (um contêiner lógico de origem de dados, genericamente

chamado de InfoObject). Tecnicamente, um InfoPackage é um job SAP real cujo

objetivo é carregar os dados. Como qualquer outro job do R/3 job, ele contém

parâmetros específicos para job como hora de início, dependências e mais.

Um Process Chain é uma cadeia complexa de diferentes processo e

relacionamentos. Os processos dentro de uma cadeia de processo não são limitados

aos processos de carga de dados, ou InfoPackages, mas também incluem:

v Execução de Atributo/Alteração de Hierarquia

v Agregar rollup

v Programa ABAP

v Outra cadeia de processo

v Processo de compilação de cliente

Definindo os Jobs de Agente Estendido para BIW

Os InfoPackages e os Process Chains podem ser criados somente a partir do

ambiente R/3. Contudo, o nível de recurso 1.3 do Job Scheduling Console suporta

listas de pico dos InfoPackages e dos Process Chains, para que você possa definir

os jobs de agente estendido do Tivoli Workload Scheduler também para esses

objetos.


Consulte “Utilizando Janelas Específicas do SAP do Job Scheduling Console” na

página 102 para saber como definir jobs de agente estendido por meio de janelas

SAP do Job Scheduling Console.


saber como definir jobs de agente estendido por meio da janela Tarefa de Agente

Estendido do Job Scheduling Console ou pelo Composer.

Consulte “Parâmetros da Cadeia de Tarefas para Jobs do R/3” na página 110 para

conhecer os parâmetros de cadeia de tarefas para especificação dos InfoPackages e

dos Process Chains ao definir um job de agente estendido por meio da janela

Tarefa de Agente Estendido do Job Scheduling Console ou pelo Composer.

Opções de Planejamento do R/3 de um InfoPackage

Para poder planejar InfoPackages por meio do IBM Tivoli Workload Scheduler, as

opções de planejamento do InfoPackage devem ser ajustadas como segue:

v Tipo de início deve ser definido para ″Iniciar posteriormente em processo de

plano de fundo″.v Hora de início deve ser ″imediato″


Capítulo 19. Conectando-se ao Sistema R/3

O Tivoli Workload Scheduler para Aplicativos do R3 utiliza a biblioteca SAP RFC

(chamada de conexão remota) para conectar-se ao sistema R/3. O endereço de

conexão para um sistema R/3 é indicado como uma cadeia de conexão.

Conexões para um Servidor de Aplicativos Específico

Na sua forma básica, uma cadeia de conexão consiste em um nome de host (ou

nome de um IP) do servidor de aplicativos R/3; por exemplo:

/H/hemlock.tivlab.raleigh.ibm.com

Esse tipo de cadeia de conexão funciona somente em ambientes de rede simples,

em que todos os servidores de aplicativos podem ser alcançados diretamente por

meio de TCP/IP. Normalmente, as empresas modernas usam topologias de rede

mais complexas, com inúmeras pequenas sub-redes, que não podem se comunicar

diretamente por meio de TCP/IP. Para suportar esse tipo de rede, a biblioteca SAP

RFC suporta os roteadores SAP, que são colocados nos limites das sub-redes e

agem como proxies. Para esse tipo de rede, a cadeia de conexão é um conjunto de

cadeias de conexão básicas para cada roteador SAP, seguida por uma cadeia de

conexão básica para o sistema R/3 de destino; por exemplo:

/H/litespeed/H/amsaix33/H/hemlock.tivlab.raleigh.ibm.com

Além disso, é possível garantir a segurança dos roteadores SAP com senhas, para

evitar acesso não autorizado. Nesse caso, a cadeia de conexão básica para esse

roteador SAP é seguida por /P/ e a senha do roteador.

Nota: A biblioteca SAP RFC limita o comprimento da cadeia de conexão até 128

caracteres no máximo. Essa é uma limitação real em ambientes de rede

complexos. Como uma solução alternativa, é recomendado utilizar nomes de

host simples, sem um nome de domínio sempre que possível. Você também

pode utilizar endereços IP, mas isso não é recomendado, pois ele é muito

difícil de ser mantido.

O Tivoli Workload Scheduler para Aplicativos do R3 suporta ambos os tipos de

cadeias de conexão, básica e em conjunto, em que:

r3host É a cadeia de conexão.

r3instance

É o número de instâncias do R/3.

r3sid É o ID do sistema R/3.

Por exemplo:

r3host=/H/litespeed/H/amsaix33/H/hemlock.tivlab.raleigh.ibm.com

r3instance=00

r3sid=TV1


Grupos de Logon

Em grandes instalações de R/3, os servidores de aplicativos são normalmente

configurados em grupos de logon com propósitos de equilíbrio de carga e

tolerância a falhas. O equilíbrio de carga é feito por um servidor dedicado,

chamado Servidor de Mensagens. O servidor de mensagens atribui usuários,

automaticamente, ao servidor de aplicativos com a última carga de trabalho do

grupo de logon que ele controla.

Defina as seguintes opções para configurar o r3batch para conectar-se ao grupo de

logon:

r3host O nome do host do servidor de mensagens.

r3group

O nome do grupo de logon.

r3sid O ID do sistema R/3.

Por exemplo:

r3host=pwdf0647.wdf.sap-ag.de

r3group=PUBLIC

r3sid=QB6


Capítulo 20. Arquivos de Opções do Método de Acesso do

R/3

Os arquivos de opções para o método de acesso do R/3 são os seguintes:

r3batch.opts

Um arquivo de configuração comum para o método de acesso do r3batch,

cujas definições afetam todas as instâncias do r3batch. Ele funciona como

um arquivo de configuração “global”.

CPUNAME_r3batch.opts

Um arquivo de configuração que é específico para cada estação de trabalho

de agente estendido do IBM Tivoli Workload Scheduler - chamado

genericamente de “CPUNAME” - utilizando o método de acesso do

r3batch. Suas opções afetam somente a instância do r3batch utilizada pela

estação de trabalho particular. Ela funciona como um arquivo de

configuração “local”.

Por exemplo, se você desejar definir dois agentes estendidos chamados wkst1 e

wkst2 que acessarão dois Sistemas R/3 - SAP1 e SAP2 - com o método de acesso

do r3batch, você deverá definir os três arquivos de configuração a seguir:

v O arquivo r3batch.opts global

v O arquivo wkst1_r3batch.opts local

v O arquivo wkst2_r3batch.opts local

Nota: Se o r3batch encontrar o arquivo de configuração local para um agente

estendido, ele irá ignorar as informações contidas no r3options.

Opções de Configuração

Esta seção descreve as opções que você deseja configurar no r3batch.opts e no

CPUNAME_r3batch.opts.

Opções Globais

A tabela a seguir lista as opções que você deve colocar no arquivo de configuração

global r3batch.opts. Essas opções têm efeito somente quando estiverem executando

o agente estendido do Tivoli Workload Scheduler em um ambiente Unix.

Nota: Essas opções terão efeito somente se forem colocadas no arquivo

r3batch.opts.

Tabela 16. Opções de Configuração Global do R3batch.

Opção Descrição

job_sem_proj O ID do projeto para o semáforo do job.

var_sem_proj O ID do projeto para o semáforo de

variante.

icp_sem_proj O ID do projeto para o semáforo de

interceptação do job.


As opções job_sem_project e var_sem_project são definições avançadas que

permitem personalizar a sincronização entre os jobs. O sistema R/3 sincroniza o

acesso ao banco de dados, utilizando um sistema de gerenciamento de trava.

Quando o Tivoli Workload Scheduler para Aplicativos do R3 está em execução no

sistema R/3, os módulos de função de ABAP correspondentes travam e destravam

objetos diferentes no banco de dados, automaticamente. Ao tentar travar um

objeto, o sistema de gerenciamento de trava permite aguardar somente um período

de tempo limitado antes de a tentativa de travamento ser rejeitada com uma falha.

Quando isso acontece, o módulo de função atual é interrompido. O período de

tempo máximo, em segundos, para cada tentativa de travamento é especificado no

parâmetro do sistema enque/delay_max.

O código de retorno do módulo de função é muito geral para distinguir o overrun

do tempo de espera de travamento máximo a partir de outros erros do banco de

dados. Então, o método de acesso para o R/3 não pode processar e relatar um

erro. Se isso acontecer durante a execução de um job do R/3, o job será colocado

no estado abort.

Essa situação piora quando o Tivoli Workload Scheduler inicia uma quantidade de

jobs simultaneamente. Dependendo do tempo de espera de travamento máximo,

vários jobs serão interrompidos devido à expiração das tentativas de travamento.

Para resolver esse problema, o Tivoli Workload Scheduler para Aplicativos do R3

utiliza semáforos no nível do S.O. para sincronizar as chamadas do módulo de

função ABAP. Isso evita efetivamente os problemas descritos. Ele utiliza um

semáforo para as tarefas listadas ao job e outro para tarefas listadas à manutenção

da variante.

Para encontrar a mesma estrutura IPC em um ambiente UNIX, os parceiros de

comunicação têm que concordar com um identificador dessa estrutura. Há vários

modos para escolher esse identificador. O Tivoli Workload Scheduler para

Aplicativos do R3 utiliza dois parâmetros: um nome da caminho e um ID de

projeto (que um valor de caractere). O parâmetro de nome do caminho é levado do

caminho absoluto para o arquivo de opções. O ID do projeto é tirado das opções

descritas em Tabela 16 na página 119. Se essas opções forem omitidas, o Tivoli

Workload Scheduler para Aplicativos do R3 utilizará os valores padrão, que

funcionarão bem na maioria das instalações.

Opções Locais

A tabela a seguir lista as opções que você deve colocar nos arquivos de

configuração local.

Tabela 17. Opções de Configuração Local do R3batch.

Opção Descrição

r3client O número do cliente R/3. Essa opção é

necessária.

r3gateway O nome do host do gateway R/3.

r3group O nome do grupo de logon do R/3.

r3gwservice O número do serviço do gateway R/3.

r3host O nome do host do servidor de mensagem

do R/3, ao utilizar os grupos de logon, ou

os nome do host do servidor de aplicativos

em todos os outros casos. Essa opção é

necessária.


Tabela 17. Opções de Configuração Local do R3batch. (continuação)

Opção Descrição

r3instance O número da instância do R/3. Essa opção é

necessária.

r3password A senha para o r3user. O valor faz distinção

entre maiúsculas e minúsculas. Essa opção é

necessária.

r3sid O ID do sistema R/3. Essa opção é

necessária.

r3user O nome do usuário do R/3 com o qual o

método de acesso é conectado ao sistema R3.

Essa opção é necessária.

r3version Força o método de acesso a funcionar

somente em sistemas R/3 com versão

especificada. Utilize essa opção com

cuidado.

xbpversion Força o método de acesso a funcionar

somente em sistemas R/3 que suportam

uma versão do XBP especificada. Utilize essa

opção com cuidado.

Opções Gerais

A tabela a seguir lista as opções adicionais que você pode colocar no arquivo de

configuração.

Tabela 18. Opções de Configuração Geral do R3batch.

Opção Descrição Padrão

r3auditlevel O nível de auditoria para o

XBP. Um número de 0 a 3.

3

short_interval O pequeno intervalo, em

segundos, para a verificação

do status. Um valor maior

que 10 segundos.

10

long_interval O longo intervalo, em

segundos, para a verificação

do status. Um valor menor

que 3600 segundos.

3600

twsxa_cp A codificação que o r3batch

deve utilizar para abrir as

conexões RFC com sistemas

R/3. Pode ser um destes

valores:

v 1100

v 1103

v 8000

v 8300

v 8400

1100

Capítulo 20. Arquivos de Opções do Método de Acesso do R/3 121

Tabela 18. Opções de Configuração Geral do R3batch. (continuação)


twsxa_lang O idioma utilizado para

efetuar login nos sistemas

R/3. Pode ser:

v DE para alemão

v EN para inglês

v JA para japonês

EN

twsmeth_cp A codificação que o r3batch

deve utilizar para gravar sua

saída. Pode ser qualquer

uma das páginas de código

TIS existentes.

A página de código local

twsmeth_lang O idioma utilizado para

relatar as mensagens.

O idioma local

utf8cmdline Um valor, 0 ou 1, que

especifica se r3batch irá

aguardar parâmetros

estendidos codificados no

UTF-8. Um valor 1 indica

que irá aguardar.

1

retry A nova tentativa de

contagem para as chamadas

do módulo de função do

R/3. Um número maior que

0.

5

nojobdefs Definição de

permissão/proibição de

novos jobs do R/3 por meio

do Tivoli Workload

Scheduler GUI.

0

oldcopy Força o método de acesso a

utilizar um modo antigo de

copiar jobs. Especifique um

valor diferente de zero para

ativar.

0

old_picklist_mode Essa opção se aplica somente

às versões 4.5 e posterior do

R/3. Se essa opção estiver

desativada (valor 0), a

PickList dos jobs será

recuperada por meio do

módulo de função

BAPI_XBP_JOB_SELECT. Se ela

estiver ativada (valor

diferente de zero), a PickList

dos jobs será recuperada por

meio do módulo de função

BAPI_XBP_JOB_COUNT. Essa

opção deve ser desativa, pois

o módulo de função

BAPI_XBP_JOB_COUNT pode ser

executado com problemas.

0




rfc_open_retry A nova tentativa de

contagem para o abertura de

uma conexão RFC para o

sistema R/3. O valor é um

número maior que 0 para

limitar o número de

tentativas, -1 é usado para

não limitar o número de

tentativas.

5

rfc_open_delay O máximo de tempo, em

segundos, para aguarda entre

duas chamadas consecutivas

antes de abrir uma conexão

RFC.

1800

log_r3syslog Se ativado, ele faz com que o

método de acesso grave as

entradas mais recentes a

partir do syslog do R/3 para

o arquivo de rastreamento,

quando um RFC é retornado

com um erro geral.

Especifique ON para ativar e

OFF para desativar.

OFF

rcmap Ativa os recursos de

mapeamento RC do Tivoli

Workload Scheduler para

Aplicativos do R3.

Especifique ON para ativar e

OFF para desativar.

ON

max_name_counter O valor máximo do

cronômetro de nome da

variante. Se o cronômetro de

nome pesquisar o valor

especificado, ele será iniciado

por 0.

40

name_counter_policy Critério do cronômetro de

nome:

step O cronômetro de

nome é aumentado

a cada etapa.

job O cronômetro de

nome é aumentado

uma vez para o job.

job

max_n0_counter Valor máximo do cronômetro

N0. Se o cronômetro N0

pesquisar o valor

especificado, ele será iniciado

do 0.

2^15 - 1




n0_counter_policy Critério do cronômetro N0:

step O cronômetro N0 é

aumentado a cada

etapa.

job O cronômetro N0 é

aumentado uma vez

para o job.

job

Utilização das Opções de Configuração

O formato do arquivo de configuração CPUname_r3batch.opts é o seguinte:

option1=value1

option2=value2

option3=value3

...

sem espaço antes da opção e depois do valor, nem entre eles e entre caracteres

iguais.

Em r3batch.opts você pode colocar todas as informações comuns, como as opções

LJuser, IFuser, JobDef e LogFileName, enquanto coloca em um arquivo de

configuração local (por exemplo, wkst1_r3batch.opts) dados personalizados para o

sistema R/3 de destino do agente estendido (por exemplo, SAP1).

Você pode colocar uma opção local em um arquivo de configuração global se

quiser fornecer a mesma opção a todas as instâncias do r3batch. Se o nome do

usuário do R/3 for o mesmo em todos os sistemas R/3, você poderá colocar a

opção r3user no arquivo global sem duplicar as informações em todos os arquivos

de configuração local.

Observe que esses arquivos de configuração não são criados durante o processo de

instalação.

Uma opção global, como job_sem_proj, tem efeito somente no arquivo de

configuração global; se você colocá-la em um arquivo local file, ela não terá efeito.

O r3batch lê o arquivo de configuração global primeiro e, em seguida, o arquivo

local. Então cada opção (exceto as opções globais) contida no arquivo de

configuração local substituirá os arquivos globais. Por exemplo, se os arquivos de

configuração global e local contiverem a opção r3user, o r3batch utilizará o

arquivo local.

Há seis opções obrigatórias que o r3batch exige; você pode colocá-las no arquivo

de configuração local ou espalhá-las entre os arquivos global e local. Por exemplo,

você pode colocar r3user e r3password no arquivo de configuração global e r3sid,

r3instance, r3client e r3host no arquivo local.

A opção r3user é local é obrigatória. Ela deve ser colocada no arquivo de

configuração global ou no arquivo local.


Migração de Arquivos de Configuração

Esta seção fornece um exemplo de migração de arquivos de configuração do

r3options para vários arquivos .opts locais (CPU_r3batch.opts).

De um arquivo r3options com o seguinte conteúdo:

xacpu1 sap1 tv1 00 100 maestro 2QGp4-7JU5-MY2A-mX 30 300 2

xacpu1 sap2 d04 10 200 tws z57I-U5MY-2Amp-4X 30 100 2

Você pode criar dois arquivos locais, xacpu1_r3batch.opts e xacpu2_r3batch.opts.

A seguir está o conteúdo do xacpu1_r3batch.opts:

R3host=sap1

R3sid=tv1

R3instance=00

R3client=100

R3user=maestro

R3password=2QGp4-7JU5-MY2A-mX

short_interval=30

long_interval=300

R3auditlevel=2

A seguir está o conteúdo do xacpu2_r3batch.opts:

R3host=sap2

R3sid=d04

R3client=200

R3instance=10

R3user=tws

R3password=z57I-U5MY-2Amp-4X

short_interval=30

long_interval=100

R3auditlevel=2

O script Perl a seguir fornece um exemplo para uma migração automática.

Iniciando com o arquivo r3options, ele produz arquivos de configuração locais.

$r3options = "r3options";

unless (-e $r3options) {

die "Error: file $r3options not found\n";

}

unless (-r $r3options) {

die "Error: file $r3options unreadible \n";

}

format OPTSFORMAT =

R3host=@<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<

$host

R3sid=@<<<

$sid

R3instance=@<<

$inst

R3client=@<<<

$client

R3user=@<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<

$user

R/3password=@<<<<<<<<<<<<<<<<<

$passwd

short_interval=@<<<<

$sint

long_interval=@<<<<

$lint

R3auditlevel=@<<

$audit

.

open (INPUT, "<$r3options");


while (<INPUT>) {

if(!/^#/ && !/^(\s)+$/) {

($cpu,$host,$sid,$inst,$client,$user,$passwd,$sint,$lint,$audit)=split(/ /);

$optsfile = $cpu . "_r3batch.opts";

open (OPTSFORMAT,">$optsfile") || die "can not create $optsfile file";

write (OPTSFORMAT);

close OPTSFORMAT;

}

}

close INPUT;

Para utilizar essa amostra:

1. Instale um interceptador PERL no seu computador.

2. Copie a amostra em um arquivo aleatório chamado migrate.pl e armazene-o

no diretório<TWShome>/methods.

3. Execute perl migrate.pl.

Os arquivos de configuração locais serão criados no diretório <TWShome>/methods.


Capítulo 21. BDC Wait

Com a opção Batch Data Collector (BDC) wait, você pode especificar que um job

do R/3 ativado pelo IBM Tivoli Workload Scheduler não será considerado

concluído até que todas as sessões BDC tenham sido concluídas. Isso evita que

outros jobs do IBM Tivoli Workload Scheduler, que são dependentes do job do

R/3, sejam ativados até que todas as sessões BDC listadas para o job do R/3

tenham sido concluídas.

Para utilizar a opção, um job do R/3 deve gravar mensagens informativas no

joblog. Esse procedimento pode ser feito, incluindo uma instrução de mensagem

no relatório BDCREXX fornecido pela SAP, como descrito a seguir, utilizando o

nome da sessão BDC (até 12 caracteres) ou o ID da fila BDC (até 20 caracteres).

Várias mensagens podem ser gravadas para permitir a monitoração de várias

sessões BDC.

Alternativamente, se você não quiser fazer modificações do R/3, você poderá

também copiar BDCRECXX com outro nome, por exemplo ZBDCRECXX, fazer as

alterações na cópia e incluí-la em todos os programas que geram sessões BDC.

Você terá que fazer isso manualmente para cada job.

Se as sessões BDC não forem criadas com o uso da transação SM35, mas

diretamente pelo componente SAP, elas não poderão usar o relatório BDCRECXX.

Nesse caso, você pode fazer modificações no módulo de função fornecido pela

SAPBDC_OPEN_GROUP, como descrito a seguir. Observe que você deve modificar

o relatório BDCRECXX (ou seu cópia ZBDCRECXX) ou o módulo de função

BDC_OPEN_GROUP. Você não deve modificar ambos os objetos.

Nota: O status de conclusão de um job do R/3 ativado pelo IBM Tivoli Workload

Scheduler, se SUCC ou ABEND, é baseado totalmente no status de execução

do job do batch. Ele não está listado ao sucesso ou à falha de quaisquer

sessões BDC, que são consideradas concluídas independentemente de erros

encontrados durante o processamento de BDC. Se você quiser reagir em

relação aos erros de uma sessão BDC, você pode utilizar o recurso de

mapeamento do código de retorno do Tivoli Workload Scheduler, como

descrito em Capítulo 28, “A Biblioteca de Mapeamento do Código de

Retorno”, na página 179.

Utilizando Nomes de Sessão BDC

Para utilizar nomes de sessão BDC, modifique o formato open_group no objeto

BDCRECXX do R/3 como se segue:

v Para releases do SAP anteriores a 4.6c:

formato open_group.

if session = ’X’.

skip.

write: /(20) ’Create group’(i01), group.

skip.

* open batchinput group

call function ’BDC_OPEN_GROUP’

exporting client = sy-mandt

group = group

user = user

keep = keep


holddate = holddate.

message i001(92) with group.

write: /(30) ’BDC_OPEN_GROUP’(i02), (12) ’returncode:’(i05), sy_subrc.

endif.

endform.

v Para releases do SAP 4.6c e posterior:

formato open_group.

skip.


skip.




group = group

user = user

keep = keep

holddate = holddate.

message i001(92) with group.


endform.

Quando as sessões BDC forem especificadas por nome, o Tivoli Workload

Scheduler não aguardará a sessão BDC nomeada a ser concluída, se houver outras

sessões BDC com o mesmo nome sendo concluídas.

Exemplo

Um job do R/3 ativado pelo Tivoli Workload Scheduler inicia três sessões BDC

com o nome ORD2 e emite a seguinte mensagem BDCWAIT:

BDCWAIT:ORD2

Após a conclusão da primeira sessão ORD2, o status do job do R/3 é mostrado

como SUCC no Tivoli Workload Scheduler. O r3batch não sabe a diferença entre

BDCs não exclusivos (isto é, chamados BDCs).

Outro problema da utilização de sessões BDC com nomes é a questão das

diferentes horas do sistema em um ambiente R/3 distribuído. O r3batch varre as

sessões BDC com os nomes especificados gerados durante o tempo de execução do

job de criador. Se o job do criador não fizer nada além de iniciar sessões BDC, o

tempo de execução pode ser muito curto. Se não houver sincronização de horário

instalada, a hora do sistema de diversas estações de trabalho normalmente serão

diferentes no ambiente R/3. Essa diferença de hora pode ser maior que o tempo de

execução do job. Portanto, é possível que o intervalo de tempo incorreto seja

eliminado e as sessões BDC não sejam detectadas.

Portanto, é recomendado utilizar o método de ID da fila BDC, descrito nas seções a

seguir.

Utilizando IDs da Fila BDC com o Relatório BDCRECXX

Para resolver os problemas causados quando as sessões BDC são especificadas por

nome, você pode especificá-las pelo ID de fila, o identificador de sessão BDC de 20

dígitos. Como cada ID de fila atribuído ao R/3 é exclusivo, uma mensagem

BDCWAIT deve ser emitida para cada ID de fila separado a ser monitorado.

Para determinar o ID de fila, modifique o formato open_group no objeto

BDCRECXX do R/3 como se segue:


v Para releases do SAP anteriores a 4.6c:

formato open_group.

if session = ’X’.

skip.


skip.




group = group

user = user

keep = keep

holddate = holddate

importing qid = myquid.

message i001(92) with myqid.


endif.

endform.

v For SAP releases 4.6c and later:

form open_group.

skip.


skip.




group = group

user = user

keep = keep

holddate = holddate

importing qid = myquid.

message i001(92) with myqid.


endform.

Não se esqueça de definir a variável myqid no BDCRECXX. Com esse método, você

vai obter uma alteração global no sistema R/3.

Utilizando IDs da fila BDC com FM BDC_OPEN_GROUP

As sessões que não forem criadas pela transação SM35, mas por um componente

do SAP, pode não utilizar o relatório BDCREXX. Nesse caso, a melhor solução para

monitorar essas sessões BDC é modificar o módulo de função do SAP

BDC_OPEN_GROUP, como se segue:

FUNCTION BDC_OPEN_GROUP.

...

CALL ’BDC_OPEN_GROUP’ ID ’CLIENT’ FIELD CLIENT

ID ’GROUP’ FIELD GROUP

ID ’USER’ FIELD USER

ID ’KEEP’ FIELD KEEP

ID ’HOLDDATE’ FIELD HOLDDATE

ID ’DESTINATION’ FIELD DEST

ID ’QID’ FIELD QID

ID ’RECORD’ FIELD RECORD

ID ’PROG’ FIELD PROG.

*

IF SY-SUBRC EQ 0.

BQID = QID.

BUSER = SY-MSGV1.

BGROUP = GROUP.

* CALL FUNCTION ’DB_COMMIT’.

Capítulo 21. BDC Wait 129

CALL FUNCTION ’ENQUEUE_BDC_QID’

EXPORTING DATATYP = ’BDC ’

GROUPID = BGROUP

QID = BQID

EXCEPTIONS FOREIGN_LOCK = 98

SYSTEM_FAILURE = 99.

IF SY-SUBRC EQ 0.

message i001(92) with qid.

ENDIF.

ENDIF.

*

PERFORM FEHLER_BEHANDLUNG USING SY-SUBRC.

*

*

ENDFUNCTION.

Observe que os parâmetros reais da chamada da função C (CALL ‘BDC_OPEN_GROUP’

ID ...) podem variar dependendo do número do release do SAP.

Com esse método, você vai obter uma alteração global no sistema R/3.


Capítulo 22. Recursos de Interceptação de Job e Pais-filhos

Este capítulo descreve como os recursos de Interceptação de Job e Pais-filhos do

BC-XBP 2.0 são suportados pelo Tivoli Workload Scheduler para Aplicativos.

Interceptação de Job

A interceptação de job é um recurso da interface do BC-XBP 2.0. Ele permite que o

Tivoli Workload Scheduler tenha um controle sofisticado sobre os jobs ativados

pelos usuários do R/3 a partir da interface gráfica SAP.

O mecanismo de interceptação de job torna-se ativo quando programador de job

do R/3 está para iniciar o job do R/3 (isto é, o momento em que as condições de

início de um job do R/3 forem atendidas). Ele verifica os parâmetros do job(nome

do job, criador, cliente) nas entradas na tabela do R/3 TBCICPT1 e, quando os

parâmetros de job atendem aos critério, o job do R/3 é definido para o status

planejado e é marcado com um sinalizador especial, indicando que o job foi

interceptado.

Se o Tivoli Workload Scheduler foi configurado para indicar a interceptação do job,

ele executará periodicamente seu próprio job para recuperar a lista de jobs

interceptados e replanejá-los. Esse job pode ser referido como o job do coletor de

interceptação.

Implemente as seguintes etapas para configurar o Tivoli Workload Scheduler para

que ele indique a interceptação de job em um ambiente R/3:

1. Instale a interface do BC-XBP 2.0.

2. Ative o recurso de interceptação de job da interface do BC-XBP 2.0.

3. Defina um job do Tivoli Workload Scheduler para coletar, periodicamente, os

jobs do R/3 interceptados.

4. Especifique os critérios de interceptação no sistema R/3.

5. Especifique os critérios de interceptação no Tivoli Workload Scheduler.

Observe que os jobs ativados pelo Tivoli Workload Scheduler ou por outro

programador externo, com o uso da interface BC-XBP, não podem ser

interceptados. Isso ocorre devido ao design do mecanismo de interceptação, que

considera somente os jobs cujas condições de início foram atendidas dentro da

restrições de tempo ou de evento SAP.

Implementando a Interceptação de Jobs

Esta seção descreve qual ação é necessária para implementar a interceptação de

job.

Ativando o Recurso de Interceptação de Jobs

Consulte a nota SAP 604496 para saber se o sistema R/3 possui a interface BC-XBP

2.0 ou para saber qual support package SAP instalar para ativá-la.

Para ativar o recurso de interceptação de job, execute o relatório do ABAP

INITXBP2. Esse relatório mostra o status atual dos recursos de interceptação de job

e pais-filhos e permite alternar o status de ambos os recursos.


Coletando Jobs Interceptados Periodicamente

Como os jobs interceptados permanecem no status scheduled até que sejam

ativados novamente, você precisará definir um job do Tivoli Workload Scheduler a

ser coletado e o reiniciá-lo.

Esta é a sintaxe da definição do job para o coletor de interceptação no Tivoli

Workload Scheduler:

CPUNAME#JOBNAME

SCRIPTNAME "TWShome/methods/r3batch -HIJ -c CPUNAME"

DESCRIPTION "Collects intercepted jobs on SAP XA CPUNAME"

STREAMLOGON TWSuser

RECOVERY STOP

em que:

CPUNAME

É o nome da estação de trabalho de agente estendido.

JOBNAME

É o nome que será utilizado para o job do Tivoli Workload Scheduler.

TWShome

É o caminho completo para a instalação do Tivoli Workload Scheduler.

TWSuser

É o nome do usuário do Tivoli Workload Scheduler que iniciará o método

de acesso.

O job do coletor de interceptação deve ser executado em intervalos periódicos;

por exemplo, a cada 10 min. Ele irá recuperar todos os jobs que foram

interceptados, desde a última execução do coletor de interceptação e irá ativá-los

de acordo com um gabarito, como descrito a seguir.

Configurando um Critério de Interceptação no Sistema R/3

No R/3, os critérios de interceptação estão contidos na tabela TBCICPT1. Somente os

jobs que atenderem aos critérios dessa tabela serão interceptados, quando suas

condições de início forem atendidas. Todos os outros jobs serão executados

normalmente.

Você pode manter as entradas nessa tabela, utilizando a transaçãose16. Aqui você

pode definir o seguinte:

v Número do cliente

v Máscara do job

v Máscara do usuário.

Configurando os Critérios de Interceptação no Tivoli Workload

Scheduler

No Tivoli Workload Scheduler, os critérios de interceptação são definidos e usados

por meio de:

v Arquivos de critérios de interceptação

v Arquivos de gabarito

Utilizando Arquivos de Critérios de Interceptação: Os critérios de interceptação

para cada sistema R/3 são armazenados em um arquivo separado chamado

CPUNAME_r3batch.icp que está localizado no diretório

TWShome/methods/r3batch_icp do host do Tivoli Workload Scheduler. Esse arquivo

é lido pelo r3batch quando ele executa o job do coletor de interceptação.


Cada linha no arquivo é considerada um critério de interceptação e é caracterizada

pela seguinte sintaxe:

client job_mask user_mask template

em que client, job_mask e user_mask correspondem às colunas da tabela TBCICPT1,

enquanto template é o nome do gabarito que deve ser utilizado pelo coletor de

interceptação para reativar o job do R/3. Os parâmetros são separados por um ou

mais espaços. Você pode utilizar qualquer editor de texto para manter o conteúdo

desse arquivo.

Utilizando Arquivos de Gabarito: Um gabarito é um arquivo com extensão .jdf

localizado no mesmo diretório (TWShome/methods/r3batch_icp) que o arquivos de

critério de interceptação. O arquivo de gabarito contém instruções para o coletor

de interceptação sobre como executar o job interceptado do R/3 sob o controle do

Tivoli Workload Scheduler. Sua sintaxe corresponde à sintaxe do docommand no

conman. Você pode utilizar qualquer editor de texto para manter esse arquivo.

Se o arquivo de gabarito do usuário estiver vazio, um arquivo de gabarito

chamadodefault.jdf será utilizado. Se default.jdf não existir, as seguintes

instruções serão utilizadas:

alias=SAP_$RUN_$JOBNAME_$JOBCOUNT

Isso significa que os jobs interceptados do R/3 devem ser reiniciados

imediatamente, devido à ausência da opção de job at=. Os nomes do Tivoli

Workload Scheduler são compostos de uma cadeia SAP_, o número de execução

atual do coletor de interceptação e o nome e o ID do job do R/3.

Portanto, o conjunto de instruções para iniciar um job interceptado do R/3 é

recuperado na seguinte ordem:

1. Do arquivo de gabarito, se um gabarito existente for especificado no arquivo de

critério de interceptação.

2. Do arquivo de gabarito padrão, se o gabarito for especificado no arquivo de

critérios de interceptação, mas não existir, ou se o gabarito não for especificado

no arquivo de critérios de interceptação.

3. Do conjunto de instruções padrão, se o arquivo de gabarito padrão não existir.

Exemplo de Interceptação de Job: A tabela de critérios de interceptação no R/3

contém a seguinte entrada:

000 * fa*

O arquivo de critérios de interceptação no Tivoli Workload Scheduler contém a

seguinte entrada:

000 * fa* at1700

O arquivo de gabarito at1700.jdf contém a seguinte entrada:

alias;at=1700

Isso indica que todos os jobs, iniciados no cliente 000 pelos usuários do R/3 cujo

nome de usuário começa com fa, serão interceptados. O coletor de interceptação

reiniciará os jobs utilizando as instruções do arquivo de gabarito at1700.jdf. Os

jobs do R/3 serão iniciados às 17:00 com um nome aleatório, devido ao comando

alias.

Utilizando Marcadores: Nos arquivos de gabarito você pode utilizar uma

quantidade de marcadores que substituem o coletor de interceptação no tempo de

Capítulo 22. Recursos de Interceptação de Job e Pais-filhos 133

execução. Eles estão listados na tabela a seguir.

Tabela 19. Marcadores para Arquivos de Gabarito de Interceptação de Job.

Marcador Descrição

$CPU O nome da estação de trabalho de agente estendido no

qual o coletor de interceptação é executado.

$CLIENT O número do cliente do job interceptado do R/3.

$JOBNAME O nome do job interceptado do R/3.

$JOBCOUNT O ID do job interceptado do R/3.

$USER O nome do usuário que ativou o job do R/3.

$JOBNUM O número do job do coletor de interceptação.

$RUN O número de execução atual do coletor de interceptação.

$SCHED O nome de planejamento do coletor de interceptação.

$RAND Número aleatório.

Portanto, o gabarito

alias=ICP_$RAND_$JOBNAME_$JOBCOUNT_$CLIENT;at=1000

fornecerá a instrução para que o coletor de interceptação reinicie o job do R/3

chamado DEMO_JOB com ID de job 12345678 no cliente 100 às 10:00 como o job do


ICP_1432_DEMO_JOB_12345678_100

Recursos Pais-filhos

Em algumas situações, um job do R/3 produz dinamicamente uma quantidade de

outros jobs; por exemplo, para distribuir a carga de trabalho aos servidores de

aplicativo livres. Um exemplo proeminente são os jobs de atividade em massa do

componente FI-CA do R/3. Antes do BC-XBP 2.0, era difícil para os programadores

externos lidarem com essa situação, pois o processo de negócios não era

normalmente concluído com a finalização do job inicial (job pai), mas com a

finalização de todos os subjobs (jobs filhos).

A interface do BC-XBP 2.0 permite determinar se um job tem subjobs ativados,

seus nomes e IDs para que seja possível rastreá-los.

Para ativar esse recurso, utilize o relatório INITXBP2 do ABAP, que também pode

ser utilizado para alternar do status de interceptação do job.

Quando o recurso pais-filhos está ativo, o Tivoli Workload Scheduler considera um

job do R/3 como concluído depois da finalização de todos os jobs filhos; em outras

palavras, o status do job do Tivoli Workload Scheduler permanece como EXEC

durante a execução do job pai ou de qualquer um dos jobs filhos.

O status do job do Tivoli Workload Scheduler torna-se SUCC se o job pai e todos os

jobs filhos forem finalizados com sucesso. Se qualquer um dos jobs for finalizado

por um erro, o status do job do Tivoli Workload Scheduler torna-se ABEND.

Observe que o recurso pais-filhos pode interferir na interceptação do job, embora o

job pai não possa ser interceptado, qualquer um dos jobs filhos pode ser


interceptado se ele atender aos critérios de interceptação. Nesse caso, o job do

Tivoli Workload Scheduler permanece no status EXEC até que o job filho

interceptado seja reativado e concluído.

Os joblogs dos jobs filhos são conectados ao stdlist do Tivoli Workload Scheduler

após o joblog do job pai.

Capítulo 22. Recursos de Interceptação de Job e Pais-filhos 135

Capítulo 23. Suporte Nacional a Idiomas

Utilizando o novo esquema de arquivos de configuração, com arquivos de

configuração local e global, você pode configurar o r3batch para utilizar diferentes

páginas de códigos ou idiomas para saída e conexão com o sistema R/3 remoto.

Esse recurso permite que você instale o r3batch na estação de trabalho localizada

do Tivoli Workload Scheduler e utilize caracteres localizados para os nomes de job,

fluxos de job e variantes SAP do Tivoli Workload Scheduler.

Nota: Certifique-se das configurações suportadas e das limitações desse recurso.

Opções de Suporte Nacional a Idiomas

A opção TWSXA_CP afeta a página de código utilizada para abrir a conexão entre o

r3batch e o sistema R/3 de destino. Seu valor pode ser uma das páginas de código

R/3 instaladas no sistema R/3; o valor padrão é a página de código SAP 1100,

semelhante ao padrão ISO8859-1.

TWSXA_LANG afeta o idioma que o r3batch utiliza para efetuar login; ele pode ser

um dos itens a seguir:

1. EN (Inglês, o valor padrão)

2. GE (Alemão)

3. JA (Japonês)

TWSMETH_CP é a página de código que o r3batch utiliza para sua saída. Essa é uma

opção avançada e pode alterar a saída e o arquivo de log. Seu valor padrão é a

página de código usada pela estação de trabalho do Tivoli Workload Scheduler que

hospeda o r3batch. Recomendamos o uso dessa opção com cautela.

Nota: Isso é verdadeiro se você utilizar o nível de recurso 1.2 do Job Scheduling

Console. O nível de recurso 1.3 interage com o r3batch por meio do UTF-8,

portanto essa limitação não existe mais.

TWSMETH_LANG afeta o idioma do catálogo utilizado pelo r3batch. Essa versão

contém somente o catálogo de mensagens em inglês, portanto essa opção não tem

efeitos reais.

Páginas de Código Suportadas pelo R/3

O Tivoli Workload Scheduler para Aplicativos do R3 pode comunicar-se com o R/3

utilizando as seguintes páginas de código:

Tabela 20. Página de Código Suportadas pelo R/3

Página de Código do R/3 Descrição

1100 8859-1, o valor padrão

1103 MS 850

8000 SJIS: Shift JIS

8300 BIG5: Chinês Tradicional

8400 GBK: Chinês Simplificado


Configurações Suportadas e Limitações

O seguinte se aplica se você estiver utilizando o nível de recurso 1.2 do Job

Scheduling Console. O nível de recurso 1.3 interage com o r3batch por meio do

UTF-8, portanto essa limitação não existe mais.

O Tivoli Workload Scheduler para Aplicativos do R3 deve ser instalado em uma

estação de trabalho que utiliza uma página de código compatível com aquela nos

sistemas R/3 de destino. Por exemplo, se desejar utilizar o sistema R/3 japonês,

que usa a página de códigos SAP 8000, você deverá instalar o r3batch em uma

estação de trabalho que utilize a página de código do japonês, como SJIS ou

MS932. Se desejar recuperar a saída do r3batch com o Job Scheduling Console,

você deve executar o Job Scheduling Console em um sistema que utilize a mesma

página de código da estação de trabalho do Tivoli Workload Scheduler, na qual

r3batch está instalado. Se o agente de hospedagem utilizar MS932, então você

deverá executar o Job Scheduling Console em um sistema em japonês com aquela

página de código.


Parte 5. Método de Acesso do z/OS



O IBM Tivoli Workload Scheduler para Aplicativos do z/OS fornece a habilidade

de planejar e controlar os jobs do OS/390 ou do z/OS, utilizando recursos de

planejamento de job sofisticados do Tivoli Workload Scheduler.

Nota: Neste manual, o termo z/OS é utilizado para fazer referência às versões

suportadas do OS/390. Consulte a seção de requisitos de software.

Recursos

v Utilizar o Tivoli Workload Scheduler para planejar jobs do z/OS a serem

executados em horários específicos e na ordem predeterminada.

v Definir as dependências entre os jobs do Tivoli Workload Scheduler em execução

em diferentes plataformas de sistemas.

v Definir dependências para os jobs do Tivoli Workload Scheduler com base na

conclusão do jobs do z/OS que não foram ativados pelo Tivoli Workload

Scheduler.

v Definir dependências para os jobs do Tivoli Workload Scheduler com base na

existência de arquivos em um sistema z/OS.


O IBM Tivoli Workload Scheduler para Aplicativos requer o seguinte software:

Requisitos de Software Versões

IBM Tivoli Workload Scheduler 7.0 ou superior.

Sistema Operacional OS390 2.10 ou superior ou z/OS.

TCP/IP Um dos seguintes: IBM 3.1 ou superior;

Interlink 3.1 ou superior; Open Connect 2.3

ou superior.

Interface de Planejamento de Job v JES2 ou JES3.

v interface OPC: OPC 2.3.0 ou IBM Tivoli

Workload Scheduler para z/OS.

v interface CA7: qualquer versão suportada

atualmente.


O software IBM Tivoli Workload Scheduler para Aplicativos do z/OS consiste no

método de acesso do z/OS que deve estar localizado no host do Tivoli Workload

Scheduler e no software de gateway localizado no z/OS. O software de gateway

pode ser instalado a partir de um cartucho de fita 3480 ou do CD-ROM do IBM

Tivoli Workload Scheduler para Aplicativos.

Antes de instalar o método de acesso, certifique-se de que o Tivoli Workload

Scheduler esteja instalado corretamente na estação de trabalho do host.

1. No sistema que será o host do método de acesso para z/OS, se a plataforma

em que estiver instalando for uma das seguintes:


v Compaq Tru64

v SGI Irix

v IBM Sequent Dynix

siga as instruções descritas em “Instalando em Plataformas de Nível 2”.

Caso contrário, siga as instruções descritas em Capítulo 2, “Instalando o IBM

Tivoli Workload Scheduler para Aplicativos”, na página 5.

2. Instale o software de gateway no z/OS.

3. Defina as autorizações necessárias no z/OS.

Instalando em Plataformas de Nível 2

O software do método de acesso do z/OS para plataformas de nível 2 é fornecido

como um arquivo tar no CD. Siga estas etapas para instalá-lo:

1. Pare o Tivoli Workload Scheduler na estação de trabalho em que você está

instalando o método.

2. Efetue logon como raiz e altere o diretório para twshome/methods.

3. Monte o CD de instalação e restaure o arquivo tar com o seguinte comando:

tar xvf cd_folder/tarfile

em que:

parâmetro tar Descrição

cd_folder É o nome da unidade ou da pasta de CD.

tarfile É o arquivo TAR dependendo da plataforma de destino. Pode ser

um dos seguintes:

v TWS4APPS_ZOSAGENT_DYNIX.TAR para IBM Sequent

Dynix

v TWS4APPS_ZOSAGENT_IRIX.TAR para SGI Irix

v TWS4APPS_ZOSAGENT_OSF.TAR para Compaq True 64

4. Execute o seguinte comando no diretório twshome/methods:

./mvsinstall.sh -user twsuser

Instalando no z/OS

O módulo de gateway é fornecido em dois tipos de mídia:

v Um cartucho de fita 3480 que foi gravado no formato não-IDRC

(descompactado).

v O CD-ROM doIBM Tivoli Workload Scheduler para Aplicativos.

Ambas as mídias contêm os dois arquivos a seguir:

v A biblioteca de carga.

v As amostras dos dois procedimentos.

Você pode escolher como fará o download dos arquivos, que são idênticos no

conteúdo.

Descarregando os Arquivos do CD-ROM

Os arquivos de gateway são armazenados no diretório ZOS do CD-ROM do

produto e são chamados:

v LOADLIB

v SAMPLES


Para descarregar os arquivos no sistema z/OS:

1. No emulador da sessão TSO, selecione o shell de comando ISPF (comando

TSO) e use o utilitário Transferência de Arquivos (Enviar ao Host) para

transferir o membro da biblioteca LOADLIB e de SAMPLES do CD-ROM para

o sistema z/OS, definindo a transferência para um comprimento de registro

lógico de 80 e um formato de registro fixo.

2. Receba os membros nos conjuntos de dados de saída, utilizando a opção INDSN.

Esse procedimento descarregará 11 módulos de carda na biblioteca de saída e 2

amostras na biblioteca de amostras.

Descarregando os Arquivos da Fita

Modifique e envie um JCL que seja semelhante ao que se segue para descarregar a

fita. Personalize a placa do job e modifique os próximos dois parâmetros de acordo

com os padrões do ambiente:

v Insira um nome de job apropriado.

v Identifique um dispositivo de fita 3480.//MVSXAUNL JOB (876903,D07),’OPCL3’,MSGLEVEL=(1,1),

// MSGCLASS=A,CLASS=A,NOTIFY=&SYSUID

//**********************************************************************

//* *

//* THIS IS THE JOB THAT UNLOADS THE TIVOLI WORKLOAD SCHEDULER FOR *

//* APPLICATIONS z/OS Access Method Version 8.2.0 TO CUSTOMIZE *

//* *

//**********************************************************************

//STEP01 EXEC PGM=IEBCOPY

//SYSPRINT DD SYSOUT=*

//INDD DD DSN=TWSX.V8R2M0.SAMPLES,

// DISP=(OLD,PASS),UNIT=600,

// VOL=SER=IBM001,

// LABEL=(1,SL)

//OUTDD DD DSN=TWSX.V8R2M0.SAMPLES,

// DISP=(NEW,CATLG),

// SPACE=(32760,(2,2,10)),

// DCB=(RECFM=FB,LRECL=80,BLKSIZE=0),

// UNIT=3390,VOL=SER=OPC00C

//SYSUT3 DD UNIT=SYSDA,SPACE=(TRK,(20,1,10))


//SYSIN DD *

COPY OUTDD=OUTDD,INDD=((INDD,R))

//STEP02 EXEC PGM=IEBCOPY

//SYSPRINT DD SYSOUT=*

//INDD DD DSN=TWSX.V8R2M0.SERVICE.APFLIB1,

// DISP=(OLD,PASS),UNIT=600,

// VOL=SER=IBM001,

// LABEL=(2,SL)

//OUTDD DD DSN=TWSX.V8R2M0.SERVICE.APFLIB1,

// DISP=(NEW,CATLG),

// SPACE=(32760,(50,50,50)),

// DCB=(RECFM=U,BLKSIZE=32760),

// UNIT=3390,VOL=SER=OPC00C



//SYSIN DD *

COPY OUTDD=OUTDD,INDD=((INDD,R))

//*


Os componentes do programa z/OS do gateway do Tivoli Workload Scheduler são:

EEWTCP02

Esse programa estabelece que o Tivoli Workload Scheduler está rastreando

o sistema z/OS. Esse programa é iniciado pelo job EEWSPACE.


EEWTCP00

Esse é o programa de “gateway” que gerencia as comunicações TCP/IP

entre o Tivoli Workload Scheduler e o sistema z/OS. É iniciado pelo job

EEWSERVE. O EEWTCP00 converte os comandos do Tivoli Workload

Scheduler para comandos equivalentes do z/OS, roteia as informações de

volta para o Tivoli Workload Scheduler e executa as conversões de dados

EBCDIC-ASCII.

Ambos os programas são executados como tarefas de início, com um parâmetro

TIME=NOLIMIT. O EEWTCP02 é iniciado primeiro sempre, seguido pelo

EEWTCP00. Se os programas forem finalizados por algum motivo, eles devem ser

parados e não cancelados, para garantir que sejam encerrados sem causar impacto

em outros programas que utilizam a Saída IEFU84.

Definindo Autorizações no z/OS

Depois de instalar o produto no z/OS, autorize a biblioteca de carga. Isso pode ser

feito:

1. Emitindo um comando SETPROG do log do console. Por exemplo:

SETPROG APF,ADD,DSN=twsx.SERVICE.APFLIB1,

VOL=xxxxxx

em que: xxxxxxx é o número de série do volume em que a biblioteca de carga

está localizada ou:

SETPROG APF,ADD,DSN=twsx.SERVICE.APFLIB1,VOL=SMS

que indica um volume sob o controle do SMS.

2. Atualize o membro PROGxx do SYS1.PARMLIB ou a autorização será perdida

no próximo IPL.

3. Inclua EEWTCP00 na seção AUTCHCMD NAMES do

SYS1.PARMLIB(IKJTSOxx).

Observações Adicionais

As seções a seguir fornecem informações adicionais sobre o funcionamento do

agente estendido.

Saída IEFU84

O agente estendido para os fluxos de job de trilha do z/OS utilizam a saída

IEFU84. Essa saída dever ser ativada no membro do parâmetro SMF no

SYS1.PARMLIB. A IBM distribui uma saída IEFU84 de dummy com o sistema

operacional que é um programa IEFBR14. O job EEWSPACE (discutido

posteriormente) será encadeado dinamicamente à saída IEFU84. Se a saída IEFU84

estiver em uso, o EEWSPACE será de “front-end” para a saída IEFU84, obterá as

informações necessárias e ramificará a saída do usuário existente. Quando o

EEWSPACE for finalizado, ele será removido da cadeia e a cadeia será restaurada

para o seu status original. É importante notar que o EEWSPACE não terá efeito na

saída IEFU84 existente, que continuará a ser executada normalmente.

Segurança

A segurança é reforçada em várias áreas, normalmente, RACF, Top Secret, ACF2,

etc. O job EEWSERVE (discutido posteriormente) deve ter a habilidade de enviar

jobs que são executados sob IDs de usuário fornecidos no JCL a ser enviado. O JCL

não deve conter senhas. Isso pode ser autorizado com o uso de recursos de classe

SURROGAT no RACF e os equivalentes no ACF2 e no Top Secret. Os recursos de

classe PROPCNTL no RACF devem ser usados para evitar que jobs enviados sejam

executados sob um ID do usuário EEWSERVE. Equivalentes do ACF2 e Top Secret


também podem ser usados. A classe de recurso JESJOBS no RACF, e os

equivalentes do ACF2 ou do Top Secret, pode ser usada para controlar quais os

nomes e ID de usuário de jobs (com ou sem senhas) que podem ser enviados pelo

EEWSERVE.

Note que o Tivoli Workload Scheduler não suporta o uso da segurança do CA-7.

Segurança do Console

O job EEWSERVE (discutido posteriormente) envolve completamente o console ao

exibir os fluxos de job e ao emitir comandos de modificação para CA-7. Ele deve

ter autoridade para utilizar um console estendido. Consulte o administrador de

segurança para garantir que esse seja o caso. Note que o CA-7 deve ser

configurado para permitir que usuários emitam comandos de modificação por

meio do master ou de consoles estendidos. OPERCMDS deve ser modificado para

permitir essa funcionalidade, se ainda não tiver sido permitida. Consulte também

“Variáveis SYSTSIN” para obter informações sobre como especificar um ID de

usuário de autoridade.

Segurança externa (consulte Segurança acima) pode ser utilizada para autorizar o

usuário do CA-7 especificado para EEWSERVE, desde que o Workload Scheduler

não suporte o fornecimento de uma senha com o nome do usuário.

Iniciar

Sigas estas etapas:

1. Personalize e inicie o procedimento EEWSPACE (seguindo as instruções

contidas aqui) para iniciar o Gateway Data Space do agente estendido. O job

deve ser uma tarefa de início e não deve ser cancelado. Consulte “Variáveis

SYSTSIN” para obter uma descrição das definições de parâmetro. O

EEWSPACE irá criar o Data Space e instalar a saída IEFU84. Para finalizar o

job, utilize o comando STOP EEWSPACE a partir de qualquer console do z/OS.

Notas:

a. EEWSPACE deve estar ativo antes de o EEWSERVE ser iniciado.

b. Para encerrar, pare o EEWSERVE antes de parar o EEWSPACE.2. Personalize e inicie o procedimento EEWSERVE, seguindo as instruções

contidas aqui. Consulte “Variáveis SYSTSIN” para obter uma descrição das

definições de parâmetro.

3. Para finalizar o job, utilize o comando STOP EEWSERVE de qualquer console do

z/OS.

Variáveis SYSTSIN

As variáveis SYSTSIN são descritas abaixo. Você pode modificar as definições

conforme necessário para a configuração do site. As definições padrão estão entre

parênteses.

Tabela 21. Variáveis SYSTSIN.

Variável Descrição

CA7INTERFACE(CONSOLE) CONSOLE é a única interface

suportada para CA-7 e é o valor

padrão para essa variável. Defina

para NO se não quiser utilizar essa

interface.

CA7NAME(CA7ONL) O nome do espaço de endereço da

região de controle do CA-7.

Ignorada se o CA-7 não for

utilizado.


Tabela 21. Variáveis SYSTSIN. (continuação)


CA7OPTIONS(X’32’) As opções de release do CA-7. O

padrão é determinado por meio da

entrada da tabela do vetor de

subsistema do CA-7 e você não

deve alterá-lo a menos que

orientado para fazer isso pelo

Suporte Técnico da IBM.

CA7SPAN(9999) Essa variável se aplica

exclusivamente à interface do CA7.

O número representa o intervalo

mínimo (em hora e minutos) depois

do qual é possível ativar do Tivoli

Workload Scheduler o mesmo job

sem especificar um SCHID

diferente. O padrão é

intencionalmente definido para

9999, um valor inválido, para que

seja possível distinguir o caso em

que a variável não é utilizada. Se

especificado, ele deve ser um

número de 4 dígitos no formato

HHMM. Por exemplo:

v CA7SPAN(0010) significa 10

minutos.

v CA7SPAN(0130) significa 1 hora

e 30 minutos.

Consulte “Outras Dicas do CA-7”

na página 159 para obter mais

detalhes.

O intervalo mínimo em minutos

(quatro dígitos) após o qual é

possível ativar o mesmo job do

Tivoli Workload Scheduler sem

especificar um SCHID diferente.

Ignorar se você definir

CA7INTERFACE igual a NO.

CA7SUBSYSTEM(UC07) O nome do subsistema CA-7.

CA7USER(CA7CNSL) O ID do usuário utilizado para

emitir comandos do CA-7. Ignorada

se o CA-7 não for utilizado.




COMPLETIONCODE(LASTSTEP/MAXSTEP) A opção de código de conclusão do

job de multi-etapas do JES padrão.

LASTSTEP, o padrão, indica que o

código de conclusão para um job

multi-etapas do JES é determinado

pela última etapa executada no job.

MAXSTEP indica que o código de

conclusão é determinado pelo

código de conclusão mais alto de

qualquer etapa executada no job.

Essa variável define o padrão para

os jobs que não têm a opção de

substituição na configuração do

Tivoli Workload Scheduler para o

job.

DEBUG(NO) Se definido para YES, ela fará com

que o gateway produza mensagens

de diagnóstico. Utilize somente de

acordo com o Suporte Técnico da

IBM.

INTERLINKSUBSYSTEM(ACSS) O nome do subsistema utilizado

pela pilha Interlink TCPIP.

Ignorada se o Interlink não estiver

sendo usado como a pilha TCPIP.

JESCMDCHR($) O caractere de reconhecimento do

comando do job. O padrão é

definido para o sinal de dólar ($)

para sistemas JES2 e asterisco (*)

para sistemas JES3. Essa variável

deve ser alterada somente se um

caracter de reconhecimento de

comando diferente estiver sendo

utilizado.

MAXWAIT(500) A quantidade máxima de tempo,

em centésimos de segundo, para

aguardar uma resposta aos

comandos. Ignorar se você definir


MCSSTORAGE(3) A quantidade de armazenamento,

em megabytes, utilizada pelo

console estendido e pelo gateway.

Ignorar se você definir


OPCINTERFACE(PIF) PIF é a única interface suportada

para OPC ou Tivoli Workload

Scheduler para z/OS e é o valor

padrão para essa variável. Defina

para NO se não quiser utilizar essa

interface.




OPCMSGCLASS(*) A classe de mensagem para os logs

de mensagem alocados

dinamicamente, utilizados pelo

OPC ou pelo Tivoli Workload

Scheduler para z/OS. O asterisco

faz com que a classe seja definida

como sendo a mesma de

EEWSERVE. Ignorada se OPC ou

Tivoli Workload Scheduler para

z/OS não estiverem sendo

utilizados.

OPCSUBSYSTEM(OPCS) O nome do subsistema utilizado

para comunicações com a região de

controle do OPC ou do Tivoli

Workload Scheduler para z/OS.

PEERADDRESS(0 0 0 0) O padrão, 0 0 0 0, permite o acesso

por qualquer host. Para obter

melhor segurança, insira o endereço

IP do host do Workload Scheduler

do z/OS x-agent. Observação: Não

inclua ″.″ (ponto) entre os 0s no

código. Os pontos serão ativados

na exibição!

PORT(5000) O número da porta TCP utilizada

pelo Tivoli Workload Scheduler e o

gateway para comunicações. Esse

deve ser o mesmo valor inserido no

campo Endereço TCP da definição

de estação de trabalho do z/OS

x-agent.

PUTLINE(YES) Quando definida para YES, ela

direciona as informações de

rastreamento para DDNAME

SYSTSPRT.

QLIMIT(2000) O número máximo de mensagens a

serem colocadas em fila no console

estendido.

SUBSYS(UNIS) O prefixo utilizado pelo agente

estendido para z/OS como os

primeiros quatro caracteres dos

nomes de console estendidos. Ela

também é usada como os primeiros

quatro caracteres da leitora interna

DDNAMES. Faça as alterações

somente de acordo com o Suporte

Técnico da IBM.

SVCDUMP(NO) Quando definida para YES, os

abends causarão um dump do SVC.

Utilize somente de acordo com o

Suporte Técnico da IBM.

TCPIPSTACK(IBM) O fornecedor da pilha TCPIP (IBM,

INTERLINK ou OPENCONNECT).




TCPNAME(TCPIP) O nome do espaço de endereço

TCPIP quando a versão da pilha

TCPIP da IBM é utilizada.

TERMINATOR(X’25’) O caractere de finalização da

transação. Não faça alterações no

padrão a menos que orientado para

fazer isso pelo Suporte Técnico da

IBM.

WTP(NO) Quando definida para YES, ela

direciona as informações de

rastreamento para SYSLOG como

uma informação gravada para o

programador. Isso pode ser

utilizado se SYSTSPRT não atender

às suas necessidades.

Quando utilizar o CA-7,

PUTLINE(YES) e WTP(NO) são

exigidos se DEBUG(YES).

ZOSV1R2(NO) Defina para YES se estiver

utilizando a interface JES3 com o

z/OS V1R2 ou posterior. Esse

parâmetro é ignorado se você não

estiver usando a interface JES3,

pois:

v Se você estiver utilizando a

interface JES2, o nível do sistema

operacional não fará diferença

para o produto.

v Se você estiver utilizando o CA7

ou o Tivoli Workload Scheduler

para interfaces z/OS, o suporte

do z/OS V1R2 ou posterior está

assegurado, pelo tempo em que

o release do subsistema

correspondente suportá-lo.

Versões de Gateway do z/OS

A versão do EEWSERVE (e EEWSPACE) é exibida na primeira linha do log

EEWSERVE (e EEWSPACE). Por exemplo:

EEWTCP10 VERSION RELEASE MODIFICATION LEVEL = VxRyMz

em que VxRyMz contêm os níveis de versão, release e modificação.


Capítulo 25. Configuração e Operação

O Tivoli Workload Scheduler ativa os jobs em um agente estendido para estação de

trabalho z/OS. O agente estendido para o z/OS é configurado na definição de

estação de trabalho do Tivoli Workload Scheduler padrão, que fornece um nome a

ele e identifica o método de acesso a ser utilizado. O agente estendido para a

estação de trabalho z/OS é uma definição de estação de trabalho vinculada a uma

instância do sistema z/OS.

Para ativar um job em um agente estendido para a estação de trabalho z/OS, o

Tivoli Workload Scheduler executa o método de acesso, transmitindo informações

sobre o job. O método de acesso comunica-se com a instância do host do z/OS e

monitora o job até a conclusão, gravando as informações de progresso e status do

job no arquivo de lista padrão de job.

Este capítulo descreve como:

v Criar um arquivo de opções para selecionar opções para um método.

v Definir um agente estendido para o job do z/OS

v Planejar um agente estendido para o job do z/OS

Consulte Capítulo 4, “Definindo as Estações de Trabalho de Agente Estendido”, na

página 31 para saber como definir uma estação de trabalho de agente estendido no


Arquivos de Opções de Método

Em todas as plataformas suportadas, exceto Compaq Tru64, SGI Irix e IBM Sequent

Dynix, utilize o Editor de Opções para criar os arquivos de opções necessários.

Consulte Capítulo 3, “Definindo Opções com o Editor de Opções”, na página 27

para obter referência.

Arquivos de Opções de Método em Plataformas de Nível 2

No Compaq Tru64, SGI Irix e IBM Sequent Dynix, crie um arquivo de opções para

selecionar opções para um método. O arquivo deve ter o mesmo nome de caminho

que o método e a extensão opts. Por exemplo, crie os seguintes arquivos no UNIX

(assumindo que o diretório inicial do Tivoli Workload Scheduler seja

/usr/lib/tws):

/usr/lib/tws/methods/mvsca7.opts

/usr/lib/tws/methods/mvsjes.opts

/usr/lib/tws/methods/mvsopc.opts

Ou crie os seguintes arquivos no Windows (assumindo que o Tivoli Workload

Scheduler esteja instalado no caminho C:\WIN32APP\tws):

c:\win32app\tws\methods\mvsca7.opts

c:\win32app\tws\methods\mvsjes.opts

c:\win32app\tws\methods\mvsopc.opts


Para mvsca7, mvsjes e mvsopc as entradas do arquivo de opções são:

Entradas do Arquivo de Opções Descrição

LJuser=name Atribua um nome de usuário utilizado pelo método

de acesso para ativar jobs. Deve ser um usuário

válido do UNIX ou do Windows que envie jobs locais

e possa conectar-se ao gateway do z/OS do Tivoli

Workload Scheduler no sistema z/OS. O padrão é

parâmetro de login na definição do job.

CFuser=name (Necessário) Atribua o nome do usuário utilizado

pelo método de acesso para verificar as dependências

do arquivo. Ele pode ser o mesmo do LJuser.

GSuser=name (Opcional) Atribua o nome do usuário utilizado pelo

método de acesso para verificar jobs não ativados

pelo Tivoli Workload Scheduler no z/OS, usados

como dependências. O padrão é raiz.

CheckInterval=min (Opcional) Define a taxa de polling, em minutos, para

verificação do status dos jobs do z/OS que foram

ativados pelo método. Valores fracionados são

aceitos; por exemplo 0.5 para 30 segundos ou 1.5

para um minuto e 30 segundos. O padrão é 2.

Ao verificar os jobs que não foram ativados pelo

Tivoli Workload Scheduler no z/OS, usados como

dependências, o método utiliza a opção local do

Tivoli Workload Scheduler status de verificação bm

em vez de CheckInterval para determinar a taxa de

polling.

BlockTime=min (Opcional) Define a quantidade de tempo, em

minutos, que o método aguardará para obter uma

resposta para uma verificação de status antes

expiração de tempo. Esse valor deve ser menor que o

valor de CheckInterval (descrito acima) e da opção

local do Tivoli Workload Scheduler status de

verificação bm. Valores fracionados são aceitos; por

exemplo 0.5 para 30 segundos ou 1.5 para um minuto

e 30 segundos. O padrão é 2.

RetryCount=count (Opcional) Define o número de vezes da tentativa de

verificação de status antes de o Tivoli Workload

Scheduler gravar uma mensagem para um arquivo de

stdlist do job e marcá-lo no estado abend. Consulte

CheckInterval eBlockTime acima para obter

informações adicionais. O padrão é 10.

Definindo Jobs no z/OS

No z/OS, os jobs planejados com o Tivoli Workload Scheduler são definidos como

predeterminados para JES, CA-7 e OPC ou Tivoli Workload Scheduler para z/OS.

Definindo Jobs do z/OS no Tivoli Workload Scheduler

As definições de job do Tivoli Workload Schedulersão necessárias para cada job

z/OS que você deseja planejar e ativar com o Tivoli Workload Scheduler. Eles são

definidos como outros jobs do Tivoli Workload Scheduler e incluem o nome do job,

o nome do usuário, as opções de nome de script especial e as opções de

recuperação opcionais.



obter referência.

Sintaxe de Definição de Tarefas para Jobs do z/OS Planejados

com o Tivoli Workload Scheduler

A seguir estão descrições de sintaxe de definição de tarefas (linha de comando

“scriptname”) para os jobs do z/OS que o Tivoli Workload Scheduler planeja e

ativa por meio de estações de trabalho de agente estendido, utilizando os métodos

mvsjes (jobs do JES2/3), mvsca7 (jobs do CA-7) ou mvsopc (jobs do OPC ou do

IBM Tivoli Workload Scheduler para z/OS).

Você especifica esses parâmetros de cadeia de tarefas nos seguintes locais quando

definir os jobs do Tivoli Workload Scheduler associados:

v No campo Comando da página Tarefa da janela Propriedades - Definição de Job,

se estiver usando o Job Scheduling Console.






Para jobs do JES:

A sintaxe é:

dataset [<|= condcode]

em que:

dataset O nome do conjunto de dados do job do JES ou do conjunto de dados

particionado.

condcode

O código de condição que indica a conclusão bem-sucedida do job. Se

antecedido por <, o código de condição deve ser menor ou igual a esse

valor. Se antecedido por =, o código de condição deve ser igual a esse

valor. Se omitido, “= 0000” será utilizado. Observe que deve haver um

espaço nos dois lados do operador (< ou =).

Exemplo:

gold.apayable.cntl(apayjob1) = 0004

Para jobs do CA-7:

A sintaxe é:

jobname [SCHID(nnn)] [CC(nnnn) ] [...]

[RO(EQ|LT|GT|GE|LE|NE|#S|IG|NO) ]

[SET(SKP|NTR|NDB) ]

em que:

jobname

O nome do job no CA-7.

SCHID

O ID de planejamento (um número de 1 a 255) a ser atribuído ao job.

CC O código de condição utilizado com o RO que indica a conclusão

bem-sucedida do job.


RO O operador relacional para o código de condição CC.

SET Define as opções do job para ignorar a próxima execução planejada (SKP),

desativa o acionamento padrão do job (NTR) ou ignora o carregamento do

banco de dados na conclusão (NDB).

Para obter uma descrição completa dos parâmetros, consulte o Guia de Comandos

do CA-7.

Exemplo:

ARCVJOB SCHID(203) CC(0001) RO(EQ) SET(NDB)

Para jobs do OPC ou do Tivoli Workload Scheduler para z/OS:

A sintaxe é:

appl [IA(yymmddhhmm)|IATIME(hhmm) ] [...]

[DEADLINE(yymmddhhmm)|DEADLINETIME(hhmm) ]

[PRIORITY(pri) ]

[CPDEPR(Y|N|P|S) ]

em que:

appl O nome do aplicativo OPC ou Tivoli Workload Scheduler para z/OS a ser

inserido no plano atual.

IA A data e a hora de chegada da entrada no formulário: aammddhhmm .

IATIME

A hora de chegada da entrada no formulário: hhmm.

DEADLINE

A data e a hora de chegada do prazo final no formulário: aammddhhmm.

DEADLINETIME

A hora de chegada do prazo final no formulário: hhmm.

PRIORITY

A prioridade (1-9) na qual o aplicativo será executado..

CPDEPR

A seleção de resolução de dependência do plano atual.

Y Inclui todas as dependências sucessoras e predecessoras.

N Não inclui nenhuma dependência. (O padrão.)

P Inclui dependências predecessoras.

S Inclui dependências sucessoras.

Para obter uma descrição completa dos parâmetros, consulte a documentação do

OPC ou do Tivoli Workload Scheduler para z/OS.

Exemplo:

PREFABJOB44 IA(0202181000) PRIORITY(5) CPDEPR(Y)

Sintaxe de Definição de Tarefas para Outros Jobs do z/OS

A seguir estão descrições da sintaxe de definição de tarefas (linha de comando

“scriptname”) para jobs do z/OS que não foram ativados pelo Tivoli Workload

Scheduler, mas que devem ser monitoras para conclusão. A conclusão desses jobs

do z/OS pode ser utilizada como dependências “follows” para os jobs ativados


pelo Tivoli Workload Scheduler. Os jobs não ativados pelo Tivoli Workload

Scheduler podem ser JES, CA-7, OPC ou Tivoli Workload Scheduler para z/OS.

A sintaxe básica é:

tws-job follows xagent::"mvs-job"

em que:

tws-job O nome do job do Tivoli Workload Scheduler que depende da conclusão

do job do z/OS especificado.

xagent O nome da estação de trabalho x-agent do Tivoli Workload Scheduler

associado ao programador de job do z/OS — isto é, um x-agent definido

com o método mvsjes, mvsca7 ou mvsopc. Observe que os dois-pontos são

delimitadores necessários.

mvs-job

A identificação do job do z/OS. Observe que essa cadeia deve estar entre

aspas. Consulte as descrições de sintaxe abaixo.

Para jobs do JES:

A sintaxe é:

"jobname[<|= condcode]"

em que:

jobname

O nome do job no JES.

condcode

O código de condição que indica a conclusão bem-sucedida do job. Se

antecedido por <, o código de condição deve ser menor ou igual a esse

valor. Se antecedido por =, o código de condição deve ser igual a esse

valor. Se omitido, “= 0000” será utilizado. Observe que deve haver um

espaço nos dois lados do operador (< ou =).

Exemplo:

job5 follows jesworkstation::"apayable = 0004"

Para jobs do CA-7:

A sintaxe é:

"jobname [SCHID(nnn) ] [...]"

[DATE(*|*yyddd)} ]

[SPAN( {* }) ]

{scope }

{date }

{(startdate,starttime,scope) }

{(startdate,starttime,enddate,endtime) }

em que:

jobname

O nome do job no CA-7.

SCHID

O ID de planejamento (um número de 1 a 255) do job.

DATE Uma data de log específica a ser pesquisada para o job.


SPAN A extensão dos registros de log a ser pesquisada para o job.

Para obter descrições completas dos parâmetros, consulte oGuia de Comandos do

CA-7. Por exemplo:

joba follows workstation::"arcvjob schid(203) span(12)"

Consulte também “Outras Dicas do CA-7” na página 159

Para jobs do OPC ou do Tivoli Workload Scheduler para z/OS:

A sintaxe é:

"application[IA(yymmddhhmm)|IATIME(hhmm)][...]"

[JOBNAME(jobname) ]

[OPNO(num) ]

em que:

application

O nome do aplicativo OPC ou Tivoli Workload Scheduler para z/OS (fluxo

de job) no plano atual.

IA A data e a hora de chegada da entrada.

IATIME

A hora de chegada da entrada.

JOBNAME

O nome do job do z/OS.

OPNO

O número da operação (1-255). Se incluso, o aplicativo será considerado

concluído quando ele atingir esse número de operação.

Para obter uma descrição completa dos parâmetros, consulte a documentação

doOPC ou do Tivoli Workload Scheduler para z/OS. Por exemplo:

joba follows opcworkstation::"PREFABJOB44 IA(0202181000) JOBNAME(PFJ3)"

Sintaxe de Dependências de arquivo (OPENS) em arquivos do

z/OS

O job e os fluxos de job do Tivoli Workload Scheduler podem utilizar arquivos do

z/OS como dependências. A sintaxe básica é:

tws-job opens xagent#"hlq1.hlq2.hlq3"

em que:

tws-job O nome do job do Tivoli Workload Scheduler que depende do arquivo

especificado do z/OS.

xagent O nome da estação de trabalho x-agent do Tivoli Workload Scheduler

associado ao programador de job do z/OS — isto é, um x-agent definido

com o método mvsjes, mvsca7 ou mvsopc. Observe que um sinal # é um

delimitador obrigatório.

hlq1.hlq2.hlq3

A identificação do arquivo do z/OS em termos de qualificador de nível

alto. Observe que essa cadeia deve estar entre aspas.

Consulte “Verificando Arquivos no z/OS” na página 161 para informações

adicionais.


Capítulo 26. Informações de Referência

Visão Geral Técnica

Este capítulo descreve os estados do job ao operar o JES, CA-7 e OPC ou o Tivoli

Workload Scheduler para z/OS no ambiente Tivoli Workload Scheduler.

Operação com o JES

O que se segue é aplicado ao operar com JES.

Ativando Jobs do JES

Para ativar e monitorar um job do JES, o Tivoli Workload Scheduler transmite o

nome do conjunto de dados do JCL ou pds que ele deseja executar para o gateway

do z/OS, que, conseqüentemente, o envia ao JES. As submissões ocorrem com a

utilização de leitoras internas alocadas dinamicamente no JES. O gateway aloca

uma leitora interna no início de cada tarefa e, em seguida, envia o job para a

leitora.

Quando um job é enviado, o nome dele e o ID do Job do JES também são inseridos

no espaço de tabelas. Quando um registro do SMF, contendo dados de um

planejamento de job relevante, é transmitido por meio da saída IEFU84, as

informações do job e do código de condições são disponibilizadas para o Tivoli

Workload Scheduler. Como o Workload Scheduler manter uma monitoração do

nome do job e do ID do Job do JES, ele permite verificar o job específico enviado.

(Atualmente o gateway utiliza registros SMF Tipo 30 e também os subtipos 1,4,5.)

O Tivoli Workload Scheduler verifica os jobs enviados periodicamente para ver se

eles estão ativos. Se um job enviado do Tivoli Workload Scheduler não estiver

ativo e nenhuma informação sobre ele for encontrada por meio da saída IEFU84, o

job será marcado como abend na exibição do Tivoli Workload Scheduler. Essa

situação pode ocorrer se um job falhar por razões de segurança ou por problemas

de sintaxe do JCL.

Estados do Job do JES: A tabela a seguir lista os estados de job do JES com

relação ao Tivoli Workload Scheduler.

Estado do Job do

Tivoli Workload

Scheduler Estado do Job do JES Comentários

intro n/a O Workload Scheduler está iniciando o método.

wait Em fila

wait n/a Se o job permanecer nesse estado, pode ser

devido à violação de segurança no z/OS.

Verifique o job no sistema z/OS.

exec Em execução O job está em execução.

succ Concluído O código de condição do job atende aos

critérios de conclusão da definição de job do



Estado do Job do

Tivoli Workload

Scheduler Estado do Job do JES Comentários

abend Concluído O código de condição do job não atende aos


Tivoli Workload Scheduler ou ocorreu um

abend de sistema ou de usuário. Os códigos de

abend do sistema, em hex, possuem o prefixo

″S″; os códigos de abend do usuário, em

decimal, possuem um prefixo ″U″. Ambos os

tipos de código são gravados no arquivo stdlist

do job.

extrn n/a Status desconhecido. Pode ocorrer somente ao

verificar um job que é utilizado como uma

dependência.

Verificando os Jobs do JES: Para verificar um job do JES que não foi ativado pelo

Tivoli Workload Scheduler, o nome do job e transmitido pelo Tivoli Workload

Scheduler para o Gateway. Como o Tivoli Workload Scheduler não enviou o job, o

ID do Job do JES não está disponível. O Gateway insere o nome no Espaço de

tabela e aguarda informações sobre o job exibidas nos registros do SMF,

transmitidas pela saída IEFU84.

Operação com o CA-7

O que se segue é aplicado ao operar com o CA-7.

Ativando Jobs do CA-7

Para ativar e monitorar um job do CA-7, o Tivoli Workload Scheduler transmite o

nome do job e, opcionalmente, o schedID de CA-7, que deseja executar para o

Gateway do z/OS. No momento da solicitação de envio, o Gateway recebe o

Número do Job do CA-7 que é utilizado para rastrear todas as atividades

subseqüentes do job. É importante observar que o próprio CA-7 deve ser

autorizado para aceitar comandos a partir de um console para que o mecanismo

funcione. Consulte a documentação do CA-7 para obter informações adicionais

sobre os comandos Modify e Login e sobre os recursos.

Estados do Job do CA-7

A tabela a seguir lista os estados de job do CA-7 com relação ao Tivoli Workload

Scheduler.

Estado do Job

do Tivoli

Workload

Scheduler

Estado do Job do

CA-7 Comentários

intro n/a O Workload Scheduler está iniciando o método.

wait Fila Solicitação ou

Fila Pronto

O estado wait pode indicar também que o job foi

movido da fila Ativa para a fila Solicitação como

resultado de um abend. O job permanece na fila

Solicitação, com um prompt de reinício, até que o

operador reinicie ou cancele o job.

exec Fila Ativo

succ Concluído O código de condição do job atende aos critérios

de conclusão da definição de job do Tivoli

Workload Scheduler.


Estado do Job

do Tivoli

Workload

Scheduler

Estado do Job do

CA-7 Comentários

abend n/a O código de condição do job não atende aos


Tivoli Workload Scheduler. Leia a nota abaixo.

extrn n/a Status desconhecido. Pode ocorrer somente ao

verificar um job que é utilizado como uma

dependência. Leia a nota abaixo.

Nota: Se o job permanecer nos estados abend ou extrn, pode ser devido à violação

de segurança no z/OS. Verifique o job no sistema z/OS.

Verificando os Jobs do CA-7

Para verificar um job do CA-7 que não foi ativado pelo Tivoli Workload Scheduler,

o nome do job é transmitido pelo Tivoli Workload Scheduler para o Gateway. Para

ver se o job está sendo planejado ou executado, atualmente, pelo CA-7, o Gateway

procura as seguintes filas do CA-7, nesta ordem: fila Solicitação, fila Pronto e fila

Ativo. Se o job não for encontrado, o Tivoli Workload Scheduler verificará

novamente a taxa definida pelo valor do status de verificação bm no arquivo de

Opções Locais.

Outras Dicas do CA-7

v Ao utilizar o CA-7, o CA7USER também deve ser um ID do UNIX válido.

v A limitação que nas versões anteriores do produto forçava os usuários a

identificar ocorrências, exclusivamente, ao definir os jobs do CA-7 no Tivoli

Workload Scheduler (isto é, incluindo os operandos SCHID e/ou SPAN) foram

removidas graças aos novos parâmetros de inicialização do CA7SPAN.

A lógica por detrás da implementação do CA7SPAN é a seguinte: se SPAN for

especificado na definição do Tivoli Workload Scheduler de um job, então o

CA7SPAN será ignorado. Se o SPAN não for especificado (ou não puder ser

especificado, como no caso dos jobs ativados pelo Tivoli Workload Scheduler),

então o CA7SPAN será considerado e seu valor será utilizado nas consultas para

o CA7 como o SPAN. Isso evita a limitação de acordo com a qual cada

ocorrência deve ser identificada exclusivamente e torna possível ativar, do Tivoli

Workload Scheduler, o mesmo job com o mesmo SCHID, com apenas uma

condição em que o intervalo entre 2 envios deve ser maior que o valor

especificado com o CA7SPAN.

É importante saber que, se especificado, o valor do CA7SPAN será utilizado em

todas as consultas no CA7 (se elas se referirem aos jobs ativados pelo Tivoli

Workload Scheduler ou se elas forem emitidas para verificar as dependências

entre as redes para os jobs não ativados pelo Tivoli Workload Scheduler) com

somente a exceção daqueles jobs que foram especificados na definição do Tivoli

Workload Scheduler.

v Se você executar produtos – como AFOPER – que substituem as mensagens do

console, certifique-se de eles não substituam as mensagens do CA-7.

Operação com OPC ou Tivoli Workload Scheduler para z/OS

O que se segue é aplicado ao operar com o OPC ou com o Tivoli Workload


Capítulo 26. Informações de Referência 159

Ativando os Jobs do OPC ou do Tivoli Workload Scheduler para

z/OS

Para ativar e monitorar um job do OPC ou do Tivoli Workload Scheduler para

z/OS, o Tivoli Workload Scheduler transmite o nome do aplicativo e os outros

parâmetros opcionais que deseja executar para o Gateway do z/OS. Se ele existir

no banco de dados do OPC ou do Tivoli Workload Scheduler para z/OS, o

aplicativo será inserido no plano atual. Os parâmetros de resolução de chamada de

entrada, chegada de prazo final, prioridade de dependência automática, se

incluído, substituem qualquer valor especificado no no OPC ou Tivoli Workload


Na taxa definida pelo valor CheckInterval no arquivo de opções do método, o

Tivoli Workload Scheduler verifica o status da ocorrência (aplicativo) no OPC ou

no Tivoli Workload Scheduler para z/OS.

Estados das Operações do OPC ou do Tivoli Workload

Scheduler para z/OS

A tabela a seguir lista os estados da operação do OPC ou do Tivoli Workload

Scheduler para z/OS com relação ao Tivoli Workload Scheduler.

Estado do Job do Tivoli Workload

Scheduler

Estado da Operação do OPC ou do Tivoli

Workload Scheduler para z/OS

wait pendente

wait não decidido

wait em espera

wait pronto

exec iniciado

succ concluído

abend interrompido

abend erro

abend excluído

abend n/a

extrn n/a

Estados de Ocorrência do OPC ou do Tivoli Workload Scheduler

para z/OS

A tabela a seguir lista os estados de ocorrência de operações do OPC ou do Tivoli

Workload Scheduler para z/OS com relação ao Tivoli Workload Scheduler.

Estado do Fluxo de Job do


Estado de Ocorrência do OPC ou do Tivoli Workload

Scheduler para z/OS

wait pendente

wait não decidido

exec iniciado

succ concluído

abend erro

abend excluído

abend N/D


Estado do Fluxo de Job do


Estado de Ocorrência do OPC ou do Tivoli Workload

Scheduler para z/OS

extrn Status N/A desconhecido. Pode ocorrer somente ao verificar

um job que é utilizado como uma dependência. Leia a nota

abaixo.

Verificando Jobs do OPC ou do Tivoli Workload Scheduler para

z/OS

Para verificar um job do OPC ou do Tivoli Workload Scheduler para z/OS que não

foi ativado pelo Tivoli Workload Scheduler, o nome do aplicativo, e opcionalmente

a operação, é transmitido para o Gateway. Uma verificação é feita para ver se a

ocorrência ou a operação está no plano atual. Se ele não for encontrado, o Tivoli

Workload Scheduler verificará novamente a taxa definida pelo valor do status de

verificação bm no arquivo de Opções Locais.

Verificando Arquivos no z/OS

A existência de um arquivo pode ser usada como uma dependência de job no

Tivoli Workload Scheduler. Para verificar a existência de uma arquivo no z/OS, o

Tivoli Workload Scheduler transmite o nome do arquivo para o Gateway. O nome

do arquivo é alocado com o DISP=OLD e é considerado existente se as seguintes

condições se aplicarem:

v Os dados estão catalogados

v Ele está alocado

v Ele não está sendo usado por outra tarefa

Se não houver um conjunto de banco de dados, o Tivoli Workload Scheduler

continuará aguardando e verificando arquivos no intervalo predeterminado.

Observe que o Tivoli Workload Scheduler pode utilizar somente nomes de

conjuntos de bancos de dados totalmente qualificados para arquivos não

particionados. Se o nome do Grupo de Dados Gerado for utilizado, ele deverá ser

um nome totalmente qualificado e não um nome relativo (por exemplo

xxxxx.xxxxx(-1) não pode ser utilizado).

Considerações de Sincronização

Ao verificar jobs do z/OS que não foram ativados pelo Tivoli Workload Scheduler,

alguns problemas de sincronização podem ser críticos para assegurar que as

dependências de job associadas estejam corretamente resolvidas. Esses problemas

surgem como o resultado da concepção do Tivoli Workload Scheduler de um dia

de processamento. Uma discussão completa pode ser encontrada no Tivoli Workload

Scheduler - Guia de Referência. Em resumo, o Tivoli Workload Scheduler gera seu

planejamento de produção cada dia até o presente momento; por exemplo, 6:00

toda manhã. Para manter um relacionamento de trabalho entre os jobs em

execução no z/OS e os jobs em execução no Tivoli Workload Scheduler, é

necessária a sincronização entre os dois ambientes. Se, por exemplo, um job do

z/OS job for iniciado fora do Tivoli Workload Scheduler e concluído antes do

início do dia de processamento do Tivoli Workload Scheduler, ele não será visível

para o Tivoli Workload Scheduler e não deverá ser utilizado em uma dependência

de job do Tivoli Workload Scheduler. O Tivoli Workload Scheduler não tenta

determinar o status dos jobs concluídos antes do início do dia.

Se a sincronização não for considerada, como discutido acima, o Tivoli Workload

Scheduler poderá aguardar, por tempo indeterminado, para resolver uma

dependência do job. Um problema semelhante pode ocorrer como resultado de


uma falha na comunicação entre os ambientes z/OS e Tivoli Workload Scheduler

evitando que o Tivoli Workload Scheduler determine o status de um job do z/OS

para atender a uma dependência do job.

Informações de Diagnóstico

Os jobs do z/OS enviados pelo Tivoli Workload Scheduler podem falhar na

conclusão devido a inúmeras razões. A etapa no processo de envio, no qual há

uma falha do job, determina quantas informações estão disponíveis e quantas são

fornecidas pelo Tivoli Workload Scheduler como se segue:

v Se um job falhar antes de ser iniciado realmente (normalmente o resultado de

um JCL ou um problema de segurança), o Tivoli Workload Scheduler irá

reconhecer que ele não existe mais e o marcará como em abend na exibição do

Console Manager (Conman). Nenhuma informação adicional é fornecida.

v Se um job falha depois de ser iniciado, o Tivoli Workload Scheduler:

1. Obtém seu código de condição e o código de abend do usuário, se houver.

2. Gravá-os no arquivo de lista padrão do job

3. Marca o job como abend na exibição do Console Manager (Conman) ou do

Job Scheduling Console

As listas de job padrão podem ser exibidas com o Console Manager (Conman) e

com o Job Scheduling Console.

Mensagens de Gateway

As mensagens informativas são criadas dinamicamente pelo programa de gateway

do z/OS. Além das informações específicas para a condição, as mensagens podem

incluir:

v Data e hora no formato aammdd hhmmss

v Nome do módulo

v Rótulo dentro do módulo

v Nome da macro

v Código de razão (registro 0)

v Código de retorno (registro 15)

As mensagens de gateway do z/OS estão listadas abaixo. Para os nomes de

módulo (módulo), veja abaixo.

EEWI01E aammdd hhmmss módulo COM FALHA, MACRO macro PRÓXIMO AO RÓTULO rótulo COM

CÓDIGO DE

RETORNO = código & CÓDIGO DE RAZÃO = código

EEWI02E ammdd hhmmss módulo COM FALHA, MACRO macro PRÓXIMO AO RÓTULO rótulo COM

CÓDIGO DE

RETORNO = código & NÚMERO DO ERRO = erro

EEWI03I aammdd hhmmss módulo EMITIDO, MACRO macro PRÓXIMO AO RÓTULO rótulo PARA

OBTER O

DESCRITOR DE SOCKET = desc

EEWI04I aammdd hhmmss módulo EMITIDO, MACRO macro PRÓXIMO AO RÓTULO rótulo

PARA OBTER O NOME DO HOST = host

EEWI05I aammdd hhmmss módulo ENDEREÇO TCPIP = endereço ip

EEWI06I aammdd hhmmss nome do módulo = nome

EEWI07I aammdd hhmmss módulo EMITIDO, MACRO macro PRÓXIMO AO RÓTULO rótuloPARA A

MENSAGEM DE CARACTERE num = msg

EEWI08S aammdd hhmmss módulo COM FALHA NO DESLOCAMENTO deslocamento


EEWI09E aammdd hhmmss módulo COM FALHA, MACRO macro PRÓXIMO AO RÓTULO rótulo

COM CÓDIGO DE RETORNO

= código

EEWI10S aammdd hhmmss módulo EM ABEND COM CÓDIGO DE RAZÃO ASSOCIADO código

EEWI11I aammdd hhmmss módulo CONSOLE nome ATIVADO COM O ID DOCONSOLE id

EEWI12I aammdd hhmmss módulo SUBTAREFA nome CONCLUÍDA COM O CÓDIGO DE CONCLUSÃO

código

EEWI13I aammdd hhmmss módulo CHAMAR PARA "nome" PRÓXIMO AO RÓTULO rótulo CONCLUÍDO

COM O CÓDIGO DE CONCLUSÃO código

EEWI14S aammdd hhmmss módulo ESPAÇO DE DADOS INVÁLIDO ENCONTRADO PRÓXIMO AO RÓTULO

rótulo

EEWI15E aammdd hhmmss módulo DATASET "dset" DDNAME "dd" COM FALHA NA ABERTURA

PRÓXIMO AO RÓTULO rótulo

EEWI16I aammdd hhmmss módulo JOB ENVIADO "job" COM A IDENTIFICAÇÃO DE JES "id"

EEWI17I aammdd hhmmss módulo PEERADDRESS = endereço ip

EEWI18E aammdd hhmmss módulo TERMINADOR INVÁLIDO term

EEWI19E aammdd hhmmss módulo PRÓXIMO AO RÓTULO label VALOR INVÁLIDO ENCONTRADO

nome = valor

EEWI20E aammdd hhmmss módulo PRÓXIMO AO RÓTULO

rótulo COM FALHA AO ENCONTRAR A SAÍDA SMF IEFU84

ATIVA

EEWI21E aammdd hhmmss errmsg

EEWI22I aammdd hhmmss TAREFA tarefa MÓDULO módulo EMITIDO, MACRO macro PRÓXIMO AO

RÓTULO rótulo PARA FECHAR O DESCRITOR DE SOQUETE soquete

EEWI24E aammdd hhmmss módulo PRÓXIMO AO RÓTULO rótulo

EEWI25I aammdd hhmmss módulo PRÓXIMO AO RÓTULO rótulo APLICATIVO appl FOI INSERIDO

NO PLANO ATUAL COM A DATA E A HORA DE CHEGADA DE ENTRADA iadatetime

EEWI26I aammdd hhmmss módulo PRÓXIMO AO RÓTULO rótulo JOB nome_do_job(id_do_job)

EEWI27I aammdd hhmmss APLICATIVO appl FOI INSERIDO NO PLANO ATUAL

COM A DATA E A HORA DE CHEGADA DE ENTRADA iadatetime

EEWI28W aammdd hhmmss APLICATIVO appl NÃO FOI INSERIDO NO

PLANO ATUAL COM A DATA E A HORA DE CHEGADA DE ENTRADA iadatetime

EEWI29I aammdd hhmmss TAREFA tarefa MÓDULO módulo EMITIDO, MACRO macro PRÓXIMO DO

RÓTULO rótulo

COM O CÓDIGO DE RETORNO = código E O NÚMERO DO ERRO = erro

EEWI30S aammdd hhmmss módulo CA7SPAN DEVE SER DE 4 DÍGITOS NO FORMATO HHMM

Os nomes do módulos são:

Nome do Módulo Descrição

EEWPRE84 Anterior a saída SMF

EEWTCP00 Rotina de processamento principal

EEWTCP01 Veículo de teste do servidor

EEWTCP02 Rotina de construção do espaço de dados principal

EEWTCP05 Estabelece a rotina ESTAE para emitir mensagens de falha

EEWTCP07 Localiza o nome do conjunto de dados associado à abertura de

ACB/DCB

EEWTCP08 Localiza o nome do conjunto de dados associado ao DDNAME

EEWTCP10 Inicializa e analisa as variáveis

EEWTCP15 Localiza e inicializa os bloqueios de controle

EEWTCP20 Localiza e inicializa os bloqueios de controle



EEWTCP21 Veículo de teste do cliente



EEWTCP25 Servidor simultâneo

EEWTCP26 Fornecedor de Interlink TCPIP do servidor simultâneo

EEWTCP27 Servidor simultâneo para a pilha Openconnect TCPIP

EEWTCP30 Tarefa de servidor filho

EEWTCP31 Tarefa de servidor filho para a pilha Interlink TCPIP

EEWTCP32 Tarefa de servidor filho

EEWTCP84 Saída de registro SMF para SMFEWTM

EEWTCP87 Interface OPC

EEWTCP88 Lançamento de interface OPC

EEWTCP89 CA7 BTI

EEWTCP90 Emite comando e aguarda a resposta

EEWTCP91 Emite TERROR para formatar as mensagens e emite WTOS

EEWTCP92 Localiza a subcadeia dentro da cadeia

EEWTCP93 Emite o comando do CA-7 e aguarda a resposta

EEWTCP94 Saída STIMER para lançar o ECB past no parâmetro

EEWTCP95 Chama o IKJEFF02 para extrair o buffer usando EEWTCP99

EEWTCP96 Rotina ESTAE para emitir mensagens de falha

EEWTCP97 Chama o IKJEFF19 (DAIRFAIL/VSAMFAIL) para emitir

mensagens

EEWTCP98 Chama o IKJEFF02 para emitir mensagens do EEWTCP99

EEWTCP99 Tabela de mensagens

EEWTCPC7 Verifica o job do CA7

EEWTCPCA Verifica a rotina de tratamento de solicitação do aplicativo

EEWTCPCF Verifica a rotina de tratamento do arquivo

EEWTCPCJ Verifica a rotina de tratamento da solicitação do job

EEWTCPCO Verifica a rotina de tratamento de solicitação da operação

EEWTCPCV Enumera o job

EEWTCPED Criptografia/descriptografia de cadeia

EEWTCPEJ Enumera a rotina de tratamento da solicitação do job

EEWTCPFJ Libera a rotina de tratamento da solicitação do job

EEWTCPIA Insere o aplicativo

EEWTCPIE Inicialização de cadeia

EEWTCPKJ Elimina a rotina de tratamento da solicitação do job

EEWTCPKO Exclui o aplicativo OPC

EEWTCPL7 Ativa a rotina de tratamento da solicitação do job do CA-7

EEWTCPLJ Ativa a rotina de tratamento do job do CA-7

EEWTCPLO Insere o aplicativo OPC



EEWTCPQ7 Consulta a rotina de tratamento da solicitação do job do CA-7

EEWTCPQJ Consulta a rotina de tratamento da solicitação do job

EEWTCPQO Consulta o aplicativo OPC

EEWTCPQS Consulta a rotina de tratamento da solicitação do subsistema

EEWTCPRC Código de retorno

EEWTCPSC Abend do sistema

EEWTCPSE Criptografia/descriptografia de cadeia

EEWTCPUC Abend de usuário

EEWTCPWT Aguarda um valor de tempo especificada

EEWTCPXX Rotina de tratamento da solicitação inválida

Para ajudar na solução de problemas, certifique-se de obter o log do JES para as

tarefas iniciadas EEWSPACE e EEWSERVE. Esse procedimento ajudará na

determinação do contexto no qual a mensagem foi emitida. Dependendo da

interface de planejamento do job utilizada, algumas informações úteis podem ser

obtidas de outros logs. Por exemplo, se utilizar CA-7, você deve obter o seguinte:

v O log do CA-7

v O log do console para o intervalo que abrange o período de teste

v O log do job que resultou em erro (se esse for o caso)

v O arquivo de script do UNIX listado àquele job


Parte 6. Capacidade de Serviços Comuns


Capítulo 27. Referência do Agente Estendido

Este capítulo descreve a interface do agente estendido e fornece informações para

programadores que precisam criar métodos de acesso personalizados.

O que São Agentes Estendidos?

Agentes estendidos são utilizado para estender as funções de planejamento de job

do Tivoli Workload Scheduler para outros sistemas e aplicativos.

Um agente estendido é definido como uma estação de trabalho que tem um host e

um método de acesso. O host é qualquer outra estação de trabalho, exceto outro

agente estendido. O método de acesso é um script ou programa fornecido pelo

usuário ou pela IBM que é executado pelo host sempre que o agente estendido é

referido no plano de produção. Por exemplo, para lançar um job em um agente

estendido, o host executa o método de acesso, transmitindo a ele detalhes do job

como opções da linha de comandos. O método de acesso comunica-se com o

sistema externo ou aplicativo para lançar o job e retornar o status do job.

Definição de Estação de Trabalho

Cada agente estendido deve ter uma definição de estação de trabalho lógica. Essa

estação de trabalho lógica deve ser hospedada por uma estação de trabalho física

Tivoli Workload Scheduler seja master, gerenciador de domínio ou FTA. A

definição de estação de trabalho do agente estendido faz referência ao nome do

método de acesso e da estação de trabalho do host. Quando jobs são lançados na

estação de trabalho do agente estendido, o método de acesso é chamado e

transmite as informações do job ao sistema externo.

Interface do Método de Acesso

A interface entre o Tivoli Workload Scheduler e um método de acesso consiste em

informações transmitidas ao método na linha de comandos e em mensagens

retornadas para o programador em stdout.

Sintaxe da Linha de Comandos do Método

O host do planejador executa um método de acesso utilizando a seguinte sintaxe

da linha de comandos:

methodname -t task options -- taskstring

em que:

methodname

Especifica o nome do arquivo do método de acesso. Todos os métodos de

acesso deve ser armazenados no diretório: TWShome/methods

-t task Especifica a tarefa a ser executada, onde task é uma das seguintes:

LJ Lança um job.

MJ Gerencia um job lançado anteriormente. Utilize essa opção para

sincronizar novamente se uma tarefa LJ anterior tiver terminado

inesperadamente.


CF Verifica a disponibilidade de um arquivo. Utilize essa opção para

verificar as dependências opens.

GS Obtém o status de um job. Utilize essa opção para verificar as

dependências follows do job.

options Especifica as opções associadas à tarefa. Consulte “Opções de Tarefas” para

obter informações adicionais.

taskstring

Uma cadeia de até 255 caracteres associada à tarefa. Consulte “Opções de

Tarefas”.

Opções de Tarefas

As opções de tarefas são listadas na tabela a seguir. Um X significa que a opção é

válida para a tarefa.

Tarefa Opções

Cadeia da

Tarefa

-t -c -n -p -r -s -d -l -o -j -q -w -S

LJ X X X X X X X X X X ljstring

MJ X X X X X X X X X mjstring

CF X X X X cfstring

GS X X X X X X gsstring

-c xagent,host,master

Especifica os nomes do agente estendido, do host e do gerenciador de

domínio principal do planejador, separados por vírgulas.

-n nodename

Especifica o nome de nó do computador associado ao agente estendido, se

houver. Isso é definido no campo Nó da definição de estação de trabalho

do agente estendido.

-p portnumber

Especifica o número da porta TCP associada ao agente estendido, se

houver. Isso é definido no campo Endereço do TCP da definição de

estação de trabalho do agente estendido.

-r currentrun,specificrun

Especifica o número de execução atual do planejador e o número de

execução específico associado ao job, separados por uma vírgula. Os

números de execução atual e específico poderão ser diferentes se o job

tiver sido transportado de uma execução anterior.

-s jstream

Especifica o nome do fluxo do job.

-d scheddate,epoch

Especifica a data de planejamento (aammdd) e o período equivalente,

separados por uma vírgula.

-l user Especifica o nome de usuário do job. Isso é definido no campo Logon da

definição de job.

-o stdlist

Especifica o nome completo do caminho do arquivo de listagem padrão do

job. Qualquer saída do job deverá ser gravada nesse arquivo.


-j jobname,id

Especifica o nome do job e o identificador exclusivo atribuído pelo

planejador, separados por uma vírgula. O nome é definido no campo

Nome do Job da definição de job.

-q qualifier

Especifica o qualificador a ser utilizado em um comando de teste emitido

pelo método junto ao arquivo.

-w timeout

Especifica o período de tempo, em segundos, que o planejador aguarda

para obter uma resposta em um job externo antes de enviar um sinal

SIGTERM para o método de acesso. O padrão é 300.

-S novo nome

Especifica que o job é reexecutado utilizando esse nome no lugar do nome

de job original. Como um script de job, você pode usar o comando jobinfo

para retornar o nome do job e executar o script de forma diferente para

cada situação. Consulte a descrição do comando conman rerun no Guia de

Referência do IBM Tivoli Workload Scheduler para obter informações

adicionais.

-- ljstring

Utilizado com a tarefa LJ. A cadeia do campo Arquivo de Script ou

Comando da definição de job.

-- mjstring

Utilizado com a tarefa MJ. As informações fornecidas ao planejador pelo

método em uma resposta %CJ a uma tarefa LJ. Em geral, isso identifica o

job que foi lançado. Por exemplo, um método Unix pode fornecer o PID

(identificação do processo) do job lançado, que é enviado pelo

programador como parte de uma tarefa MJ.

-- cfstring

Utilizado com a tarefa CF. Para a dependência opens de um arquivo, a

cadeia do campo Opens Files da definição do fluxo de job.

-- gsstring

Utilizado com a tarefa GS. Especifica o job cujo status foi verificado. O

formato é o seguinte:

followsjob[,jobid]

em que:

followsjob

A cadeia da lista Follows Sched/Job da definição do fluxo de job.

jobid Um identificador de job opcional recebido pelo planejador em uma

resposta %CJ a uma tarefa GS anterior.

Mensagens de Resposta do Método

Os métodos retornam informações ao Tivoli Workload Scheduler em mensagens

gravadas no stdout. Toda linha começando com um sinal de porcentagem (%) e

terminando com uma nova linha, é interpretada como uma mensagem. As

mensagens possuem o seguinte formato:

%CJ state [mjstring | jobid]

%JS [cputime]

Capítulo 27. Referência do Agente Estendido 171

%RC rc

%UT [errormessage]

em que:

CJ Altera o estado do job.

state O estado para o qual o job é alterado. Todos os estados de job do

planejador são válidos, exceto hold e ready. Para a tarefa GS, os

seguintes estados também são válidos:

ERROR

Ocorreu um erro.

EXTRN

Status desconhecido.

mjstring

Uma cadeia de até 255 caracteres que o planejador incluirá em

qualquer tarefa MJ associada ao job. Consulte 171.

jobid Uma cadeia de até 64 caracteres que o planejador incluirá em

qualquer tarefa GS associada ao job. Consulte 171.

JS [cputime]

Indica a conclusão bem-sucedida de um job e fornece seu tempo de

execução decorrido em segundos.

RC rc rc é um número interpretado pelo Tivoli Workload Scheduler como o

código de retorno do job de agente estendido. O código de retorno será

considerado somente se uma condição de código de retorno for

especificada na definição do job de agente estendido. Se esse não for o

caso, ele será ignorado e a conclusão bem-sucedida do job de agente

estendido será indicada pela presença da mensagem %JS [cputime]. Da

mesma forma, se o método não enviar a mensagem %RC, então a

conclusão bem-sucedida do job de agente estendido será indicada pela

presença da mensagem %JS [cputime].

UT [errormessage]

Indica que a tarefa solicitada não é suportada pelo método. Exibe uma

cadeia de até 255 caracteres que o planejador incluirá em sua mensagem de

erro.

Arquivo de Opções do Método

É possível utilizar um arquivo de opções do método para especificar informações

especiais de logon e outras opções. O planejador lerá o arquivo, se existir, antes de

executar um método. Se o arquivo for modificado depois que o planejador for

iniciado, as alterações serão efetivadas quando ele for parado e reiniciado.

O arquivo pode conter opções do planejador e qualquer outra informação sobre o

método. As opções reconhecidas pelo planejador são as seguintes:

LJuser=username

CFuser=username

GSuser=username

GStimeout=seconds


em que:

LJuser=username

Especifica o logon a ser utilizado para as tarefas LJ e MJ. O padrão é o

logon da definição de job.

CFuser=username

Especifica o logon a ser utilizado para a tarefa CF. O padrão é raiz para

Unix, e para o Windows é o nome do usuário da conta na qual o

programador foi instalado.

GSuser=username

Especifica o logon a ser utilizado para as tarefas GS. O padrão é raiz para

Unix, e para o Windows é o nome do usuário da conta na qual o

programador foi instalado.

GStimeout=seconds

Especifica o período de tempo, em segundos, que o planejador aguarda

por uma resposta antes de eliminar o método de acesso. O padrão é 300

segundos.

Nota: Se o host do agente estendido for um computador do Windows, estes

usuários deverão ser definidos como objetos do usuário do programador.

O arquivo de opções deve ter o mesmo nome de caminho de seu método de

acesso, com uma extensão de arquivo .opts. Por exemplo, o nome do caminho do

Windows de um arquivo de opções para um método chamado netmth é:

v TWShome\methods\netmth.opts (global).

v TWShome\methods\<CPUname>_netmth.opts (local).

Execução do Método

Os tópicos a seguir descrevem o intercâmbio entre o Tivoli Workload Scheduler e

um método de acesso.

Tarefa LJ (Lançar Job)

A tarefa LJ orienta o método do agente estendido para lançar um job em um

sistema ou aplicativo externo. Antes de executar o método, o Tivoli Workload

Scheduler estabelece um ambiente de execução. O parâmetro LJuser é lido a partir

do arquivo de opções do método para determinar a conta do usuário com a qual

executar o método. Se o parâmetro não estiver presente ou o arquivo de opções

não existir, a conta do usuário especificada no campo Logon da definição do job

será utilizada. Além disso, as seguintes variáveis de ambiente são definidas:

HOME

O diretório pessoal do usuário de logon.

LOGNAME

O nome do usuário de logon.

PATH No Unix, ele é definido como /bin:/usr/bin. No Windows, ele é definido

como %SYSTEM%\SYSTEM32.

TZ O fuso horário.

Se o método não puder ser executado, o job será colocado no estado fail.

Depois de um método ser executado, ele grava mensagens em seu stdout que

indica o estado do job no sistema externo. As mensagens são resumidas na tabela a


seguir.

Tarefa Resposta do Método Ação do Tivoli Workload Scheduler

LJ e MJ %CJ state [mjstring] Define o estado do job como state. Inclui

mjstring em qualquer tarefa MJ

subseqüente.

%JS [cputime] Define o estado do job como succ.

Código de saída=diferente de

zero

Define o estado do job como abend.

%UT [errormessage] e Código

de saída=2

Define o estado do job como abend e exibe

errormessage.

Uma seqüência comum consiste em uma ou mais mensagens %CJ indicando

alterações no estado do job e, em seguida, uma mensagem %JS antes do método

sair para indicar que o job terminou com êxito. Se o job não for bem-sucedido, o

método deverá sair sem gravar a mensagem %JS. Um método que não suporta a

tarefa LJ grava uma mensagem %UT no stdout e sai com um código de saída 2.

Tarefa MJ (Gerenciar Job)

A tarefa MJ será utilizada para sincronizar com um job lançado anteriormente se o

planejador determinar que a tarefa LJ terminou inesperadamente. O planejador

configura o ambiente da mesma maneira que para a tarefa LJ e transmite a

mjstring.Consulte “Tarefa LJ (Lançar Job)” na página 173 para obter informações

adicionais.

Se o método localizar o job especificado, ele responderá com as mesmas

mensagens de uma tarefa LJ. Se o método não conseguir localizar o job, ele sairá

com um código de saída diferente de zero, fazendo com que o planejador coloque

o job no estado abend.

Como Eliminar um Job

Enquanto uma tarefa LJ ou MJ está sendo executada, o método deve detectar um

sinal SIGTERM (sinal 15). O sinal é enviado quando um operador emite um

comando Kill através do gerenciador de console do planejador. No recebimento do

sinal, o método deve tentar parar (kill) o job e sair sem gravar uma mensagem

%JS.

Tarefa CF (Verificar Arquivo)

A tarefa CF solicita o método do agente estendido para verificar a disponibilidade

de um arquivo no sistema externo. Antes de executar o método, o planejador

estabelece um ambiente de execução. O parâmetro CFuser é lido a partir do

arquivo de opções do método para determinar a conta do usuário com a qual


não existir, o usuário raiz será utilizado no Unix e, no Windows, será utilizado o

nome do usuário da conta na qual o programador foi instalado. Se o método não

puder ser executado, o arquivo que abre a dependência será marcado como falha,

isto é, o status do arquivo será definido como NÃO e qualquer job ou fluxo de job

dependente não terá permissão para ser executado.

Durante a execução, o método executa um comando de teste, ou equivalente, no

arquivo que está utilizando o qualificador transmitido a ele na opção -q da linha

de comandos. Se o teste do arquivo for verdadeiro, o método sairá com um código

de saída zero. Se o teste do arquivo for falso, o método sairá com um código de

saída diferente de zero. Isso é resumido na tabela a seguir.



CF Código de saída=0 Define o estado do arquivo como SIM.

Código de saída=diferente

de zero

Define o estado do arquivo como NÃO.


de saída=2

Define o estado do arquivo como NÃO.

Um método que não suporta a tarefa CF grava uma mensagem %UT no stdout e

sai com um código de saída 2.

Tarefa GS (Obter Status)

A tarefa GS informa ao método do agente estendido para verificar o status de um

job. Isso é necessário quando outro job depende da conclusão bem-sucedida de um

job externo. Antes de executar o método, o parâmetro GSuser é lido a partir do

arquivo de opções do método para determinar a conta de usuário com a qual


não existir, o usuário raiz será utilizado no Unix e, no Windows, será utilizado o

nome do usuário da conta na qual o programador foi instalado. Se o método não

puder ser executado, o job ou fluxo de job dependente não terá permissão para

executar. Se um jobid estiver disponível a partir de uma tarefa GS anterior, ele será

transmitido para o método.

O método verifica o estado do job especificado e o retorna em uma mensagem

%CJ gravada no stdout. Em seguida, sai com um código de saída zero. Em uma

taxa definida pela opção local status de verificação de bm, o método é executado

novamente com uma tarefa GS até que um dos seguintes estados de job sejam

retornados:

abend O job terminou de forma anormal.

succ O job foi concluído com êxito.

cancl O job foi cancelado.

done O job terminou, mas seu êxito ou falha não foi indicado.

fail O job não pôde ser executado.

error Ocorreu um erro no método durante a verificação do status do job.

extrn A verificação do job falhou ou o status do job não pôde ser determinado.

Observe que GStimeout no arquivo de opções do método especifica quanto tempo

o planejador aguardará por uma resposta antes de eliminar o método. Consulte

“Arquivo de Opções do Método” na página 172 para obter informações adicionais.

As respostas dos métodos são resumidas na tabela a seguir:


GS %CJ state [jobid] Define o estado do job como state e inclui

jobid em qualquer tarefa GS subseqüente.


de saída=2

O estado do job fica inalterado.

Um método que não suporta a tarefa GS grava uma mensagem %UT no stdout e

sai com um código de saída 2.


O Comando cpuinfo

O comando cpuinfo pode ser utilizado em um método de acesso para retornar

informações de uma definição de estação de trabalho. Consulte o Guia de

Referências do IBM Tivoli Workload Scheduler para obter informações de comando

completas.

Resolução de Problemas

Os tópicos a seguir são fornecidos para ajudá-lo a detectar e depurar problemas do

agente estendido e do método de acesso.

Mensagens de Erro da Lista Padrão de Jobs

Todas as mensagens de saída de um método de acesso, exceto as iniciadas com um

sinal de porcentagem (%), são gravadas no arquivo de lista padrão de jobs (stdlist).

Para as tarefas GS e CF não associadas a jobs do planejador, as mensagens são

gravadas no arquivo de lista padrão do planejador. Para obter informações

relativas a qualquer tipo de problema, verifique esses arquivos.

Método Não Executável

Se um método de acesso não puder ser executado, ocorrerá o seguinte:

v Para as tarefas LJ e MJ, o job será colocado no estado fail.

v Para a tarefa CF, a dependência de arquivo ficará sem solução e o job

dependente permanecerá no estado hold.

v Para a tarefa GS, a dependência de job ficará sem solução e o job dependente

permanecerá no estado hold.

Para obter informações adicionais, reveja os arquivos de lista padrão (stdlist) do

job e do planejador.

Mensagens do Gerenciador de Console

Esta mensagem de erro será exibida se você emitir um comando start, stop, link

ou unlink para um agente estendido:

Erro na execução do comando: Não implementado para agentes

estendidos. [2202.58]

Esse erro não será exibido se um agente estendido for selecionado como resultado

da utilização de caracteres curinga.

Mensagens do Composer e do Compiler

As mensagens de erro a seguir são geradas quando o Composer encontra sintaxe

inválida em uma definição de estação de trabalho:

MÉTODO DE ACESSO sintaticamente inválido [1116.45]

Palavra-chave de ACESSO duplicada [1116.46]

MÉTODO DE ACESSO ausente ou inválido [1116.47]

Se um agente estendido for definido com um método de acesso, mas sem um host,

a seguinte mensagem será exibida:

"O método precisa de uma CPU do Host"

Mensagens do Jobman

Para agentes estendidos, as mensagens de erro, de aviso e informativas são

gravadas no arquivo stdlist do Jobman.


O lançamento bem-sucedido de um job gera a seguinte mensagem:

Job jobname lançado para wkstation, #Jjobid para usuário username.

O lançamento mal sucedido de um job gera a seguinte mensagem:

Erro ao lançar jobname para wkstation: errortext

Falha em uma tarefa de verificação de arquivo gera a seguinte mensagem:

Erro ao chamar methodname para wkstation: errortext

Falha em uma tarefa de gerenciamento de job gera a seguinte mensagem:

Erro ao gerenciar jobname para wkstation utilizando methodname: errortext

Quando um método envia uma mensagem para o Jobman, mas não é reconhecida,

é gerada a seguinte mensagem:

Erro: mensagem inválida para jobname, #jjobnumber para

wkstation usando methodname.

"primeiros 64 caracteres da mensagem afetada"


Capítulo 28. A Biblioteca de Mapeamento do Código de

Retorno

A funcionalidade do mapeamento do código de retorno fornece um modo padrão

de mapear mensagens em valores de código de retorno. Além disso, o

mapeamento do código de retorno pode ser personalizado pelos usuários. Essa

funcionalidade está disponível nos métodos de acesso para:

v Oracle eBusiness Suite

v Peoplesoft

v R/3

Essa funcionalidade fornece mais granularidade na definição dos critérios de

sucesso/falha dos jobs e flexibilidade aprimorada no controle dos fluxos de

execução do job com base nos resultados da execução. O mapeamento do código

de retorno do job fornece os seguintes recursos:

v Os usuários podem definir um status de finalização do job (bem-sucedido ou

com falha) baseado na condição do código de retorno da execução do

programa/script do job.

v O código de retorno também pode ser fornecido para recuperar o job que está

associado à definição de job. Isso faz com que o job de recuperação execute

processos diferentes com base no código de retorno.

O Arquivo de Mapeamento do Código de Retorno

Esse arquivo permite que você personalize seus próprios códigos de retorno em

relação a determinadas condições que podem afetar um job quanto ele for

executado. Nesse arquivo é possível definir a condição de sucesso do job da qual o

Tivoli Workload Scheduler pode ser avaliado, se o job for concluído com sucesso

ou se houver erro. O código de retorno é enviado ao Tivoli Workload Scheduler na

forma de uma mensagem %RC nnnn. Se essa mensagem for recebida, o estado do

job será atualizado de acordo.

Formato

A sintaxe do arquivo de mapeamento do código de retorno é a seguinte:

[#] “pattern1” “pattern2”...“patternn” = RC value

Parâmetros

# Comentário opcional. Todas as linhas que se iniciam com esse símbolo (#)

não são utilizadas para o mapeamento.

patternn

As cadeias padrão delimitadas por aspas duplas (“ e ”). Se você utilizar

somente uma cadeia padrão, é possível omitir as aspas duplas. Se a cadeia

padrão contiver um caractere de aspas duplas, ele deve ser substituído por

uma barra invertida (\). A cadeia pode conter os seguintes caracteres

curinga ou caracteres especiais:

Asterisco (*)

Corresponde a um número arbitrário de caracteres.

Ponto de interrogação (?)

Corresponde a um único caractere.


Barra invertida (\)

Caractere de substituição.

Valor RC

O valor do código de retorno. Esse valor é enviado pelo método para o

Tivoli Workload Scheduler por meio de uma mensagem %RC nnnn.

Exemplos

No seguinte exemplo de um arquivo de mapeamento do código de retorno, os

números das linhas em negrito não pertencem ao arquivo mas são mostrado para

referência:

1. # Esse é um arquivo de mapeamento do RC para o joblog.

2.

3. “Usuário * inexistente ” = 102

4. “\*\*\*” = 103

5. “Usuário \

6. * \

7. inexistente” = 102

em que:

v A linha 1 é um comentário e não é utilizada para mapeamento.

v A linha 2 está em branco e é ignorada. Todos os espaços em branco, anteriores

ou posteriores a uma cadeia padrão são ignorados, bem como esses entre o sinal

de igual e o valor do código de retorno.

v A linha 3 corresponde a toda mensagem iniciando com a cadeiaUsuário e

terminando com a cadeia inexistente.

v A linha 4 corresponde a toda mensagem iniciando com três asteriscos (*)

seguidos de um espaço em branco. Quando você utiliza o asterisco com

mostrado acima e não como um caractere curinga, é necessário substituí-lo por

uma barra invertida.

v As linhas de 5 a 7 contêm um padrão de várias linhas. Ele corresponde as

mesmas mensagens que o padrão da linha 3.

Comentários

Observe os seguintes fatos:

v A ordem das linhas padrão é importante, pois a primeira correspondência de

linha padrão é utilizada para criar o valor do código de retorno.

v As cadeias padrão vazias (“”) são ignoradas pelo procedimento de

correspondência de padrões.

Por exemplo, a seguir é mostrada uma seqüência de padrões válida. A primeira

linha é mais restritiva que a segunda linha.

“625” “Usuário * inexistente” = 104

“” “Usuário * inexistente” = 102

A seqüência padrão a seguir é formalmente válida, mas a segunda linha padrão

nunca é utilizada; como a primeira linha é mais geral, ela sempre encontra

correspondência primeiro.

“” “Usuário * inexistente” = 102“625” “Usuário * inexistente” = 104

Mapeamento de Código de Retorno para Psagent e

MCMAGENT

Para o método de acesso para o PeopleSoft e o Oracle e-Business Suite, você pode

gravar os arquivos de mapeamento do código de retorno associados ao estado

interno listado em Tabela 22 na página 181 e em Tabela 23 na página 181.


Quando nenhum arquivo de mapeamento do código de retorno for definido ou

quando uma cadeia retornada pelo método de acesso não corresponder aos

padrões do arquivo de mapeamento, os métodos utilizarão os respectivos códigos

de retorno padrão listados nas mesmas tabelas.

Tabela 22. Estados de Job e Códigos de Retorno do Método de Acesso para PeopleSoft.

Estado do Job do Psoft Código de Retorno do Psoft

″CANCEL″ 1

″DELETE″ 2

″ERROR″ 3

″HOLD″ 4

″QUEUED″ 5

″INITIATED″ 6

″PROCESSING″ 7

″CANCELLED″ 8

″SUCCESS″ 9

″NO SUCCESSPOSTED″ 10

″POSTED″ 11

″NOT POSTED″ 12

″RESEND″ 13

″POSTING″ 14

″GENERATED″ 15

Tabela 23. Estados de Job e Códigos de Retorno do Método de Acesso paraOracle

e-Business Suite.

Estado do Job de MCMAGENT Código de Retorno do MCMAGENT

″RUNNING″ 1

″PENDING″ 2

″COMPLETE″ 3

″INACTIVE″ 4

″NORMAL″ 5

″TERMINATING″ 6

″PAUSED″ 7

″RESUMING″ 8

″STANDBY″ 9

″SCHEDULED″ 10

″WAITING″ 11

″WARNING″ 13

″ERROR″ 14

″TERMINATED″ 15

″DELETED″ 16

″ON HOLD″ 17

″DISABLED″ 18

″NO MANAGER″ 19

Capítulo 28. A Biblioteca de Mapeamento do Código de Retorno 181

Tabela 23. Estados de Job e Códigos de Retorno do Método de Acesso paraOracle

e-Business Suite. (continuação)

Estado do Job de MCMAGENT Código de Retorno do MCMAGENT

″SUSPENDED″ 20

″TEST FAILURE″ 21

″NOT FOUND″ 22


Exemplos: O agente estendido para o Oracle e-Business Suite retorna a cadeia

TERMINATED. O código de retorno resultante será o seguinte, dependendo dessa

condições:

v Não existe nenhum arquivo de mapeamento do código de retorno. Nesse caso, o

método envia um valor de código de retorno de 15 ,como mostrado em

Tabela 23 na página 181.

v O arquivo de mapeamento do código de retorno existe e é

"NORMAL"=0

"TERMINATED","DELETED"=1

Nesse caso, o método encontra o padrão de correspondência e envia um valor

de código de retorno de 1.

v O arquivo de mapeamento do código de retorno é

"NORMAL"=0

"ERROR","DELETED"=1

Nesse caso, o método não encontra o padrão de correspondência e envia um

valor de código de retorno de 15, como mostrado em Tabela 23 na página 181.

Capítulo 28. A Biblioteca de Mapeamento do Código de Retorno 183

Nomes dos Arquivos de Mapeamento do Código de Retorno

Cada método tem seu próprio conjunto de arquivos para mapear as mensagens em

valores de código de retorno. Os arquivos de mapeamento pode ser globais ou

locais para uma estação de trabalho.

Os arquivos de mapeamento do código de retorno, específicos para a estação de

trabalho, são nomeados de acordo com o seguinte esquema:

<TWShome>/methods/rcm/<nome_do_método>-<type>-<workstation>.rcm

Os arquivos de mapeamento global devem ter um nome de arquivo de acordo com

o seguinte esquema:

<TWShome>/methods/rcm/<nome_do_método>-<type>.rcm

Para os métodos de acesso PeopleSoft e Oracle e-Business, type é sempre igual a

rcmap. Para o método de acesso R/3, type é como descrito na seguinte seção.

Nomes de Arquivos de Mapeamento do Código de Retorno para

r3batch

O método para R3 utiliza os seguintes arquivos de mapeamento do código de

retorno global:

<TWShome>/rcm/methods/r3batch-joblog.rcm

Mapeia as mensagens do joblog de um job do R3 para os valores do

código de retorno. Se esse arquivo não estiver presente, as mensagens no

joblog serão ignoradas.

<TWShome>/rcm/methods/r3batch-pchainlog.rcm

Mapeia as mensagens do protocolo da Cadeia de Processo para os valores

do código de retorno. Se esse arquivo não estiver presente, as mensagens

no protocolo serão ignoradas.

<TWShome>/rcm/methods/r3batch-spool.rcm

Mapeia as mensagens na lista de spool do job de um job SAP para os

valores do código de retorno. Se esse arquivo não estiver presente, as

mensagens na lista de spool serão ignoradas.

<TWShome>/rcm/methods/r3batch-syslog.rcm

Mapeia as mensagens no syslog de um sistema SAP para valores do código

de retorno. Se esse arquivo não estiver presente, as mensagens no syslog

serão ignoradas.

<TWShome>/rcm/methods/r3batch-msgrc.rcm

Mapeia exceções ABAP / códigos de retorno BAPI dos módulos de função

RFC para os valores do código de retorno. Se esse arquivo não estiver

presente, o mapeamento será feito com uma tabela codificada.


Capítulo 29. Configurando o Utilitário de Rastreamento

Todos os métodos de acesso fornecem a possibilidade de configurar as opções de

rastreamento. Para fazer isso, você pode editar uma quantidade de propriedades

de rastreamento no arquivo de configuração

<nome_do_método_de_acesso>.properties localizado no subdiretório de métodos do

TWShome.

As propriedades de rastreamento configuráveis são:

v Nível de rastreamento (MIN,MID,MAX)

v Localização do arquivo de rastreamento (em termos de caminho absoluto)

O exemplo a seguir é um arquivo de configuração para o método de acesso de

R/3. Ele é chamado r3batch.properties. As palavras-chave discutidas nesta seção

estão realçadas para facilidade de utilização:

r3batch.organization=IBM

r3batch.product=TWS4APPS

r3batch.component=R3BATCH

r3batch.trace.tracers.level=DEBUG_MIN

r3batch.trace.tracers.listenerNames=r3batch.trace.handlers.traceFile

r3batch.trace.handlers.traceFile.fileDir=home/maestro/methods

r3batch.trace.handlers.traceFile.appending=true

r3batch.trace.handlers.traceFile.formatterName=r3batch.trace.formatter

Com a palavra-chave level, o mecanismo de rastreamento suporta três níveis de

rastreamento:

DEBUG_MIN

Somente erros fatais são listados. Esse é o padrão.

DEBUG_MID

Mensagens informativas e avisos também são listados.

DEBUG_MAX

Um resultado de depuração mais verboso é exibido.

As definições do arquivo de propriedades afetam todas as execuções do método de

acesso correspondente. Para especificar uma definição de rastreamento diferente

para um determinado job, inclua a seguinte opção na definição do job:

-tracelvl=(1|2|3)

em que:

v 1 = DEBUG_MIN

v 2 = DEBUG_MID

v 3 = DEBUG_MAX

Somente para o método de acesso R/3, você pode marcar a caixa de opções

Depurar na janela Definições das Propriedades do Job do Job Scheduling Console

para definir o nível de rastreamento para DEBUG_MAX de um job específico. Observe

que a caixa de opções Rastrear ativa o rastreamento de SAP RFC.

Os rastreamentos são gravados no formato XML. Por padrão, os arquivos de

rastreamento são armazenados no diretório de métodos. Para alterar esse

caminho,você pode usar a palavra-chave fileDir. Certifique-se de que o novo


caminho especificado já tenha sido criado como um caminho absoluto com os

direitos de gravação. Sempre use barras (ou barras invertidas) ao especificar um

novo caminho, mesmo se estiver no Windows.

Os arquivos de rastreamento fornecem informações sobre a execução de métodos

para os níveis de detalhes desejados. O nível de rastreamento mínimo está sempre

ativado, para garantir o recurso de FFDC (Captura de Dados da Primeira Falha).

O valor da chave anexando determina se um novo arquivo de rastreamento está

anexado a outro mais velho (verdadeiro) ou se a sobrescreve (falso). Um valor

verdadeiro é recomendado para todas as situações. De modo particular, ele não

deve ser alterado para falso durante a execução de jobs, pois isso poderá causar

perda de rastreamento.


Capítulo 30. Resolução de Problemas

Este capítulo lista alguns itens de problemas que você pode enfrentar ao instalar

ou utilizar o Tivoli Workload Scheduler para Aplicativos ou os métodos de acesso.

Tabela 24. Itens de Solução de Problemas

Área Item

Instalação:

Descobrindo

instâncias do

Tivoli Workload

Scheduler

Problema: se você estiver no Unix e tiver várias instalações do Tivoli Workload Scheduler

versões 7.0 ou 8.1 que não foram instaladas corretamente no diretório inicial /home/TWSuser, o

programa de instalação lista, aleatoriamente, somente uma das instâncias e um dos nomes que

ele <desconhece>.

Solução: para cada uma dessas instâncias, crie um diretório inicial adequado que aponte para o

diretório real da instalação do Tivoli Workload Scheduler. Faça o seguinte:

1. Na raiz, crie um diretório chamado /home/TWSuser, que se vincula ao diretório no qual o

produto foi instalado.

2. No arquivo /usr/unison/components, inclua uma entrada chamada /home/TWSuser que se

vincule à entrada para a instância em particular.

Instalação:

Instalando o

psagent

Problema: ao instalar o método de acesso para o recurso do PeopleSoft, a mensagem pop-up a

seguir pode ser exibida:

O número 6654 não pôde ser localizado na dll MFC42u.dll

Isso ocorre porque uma versão antiga de MFC42u.dll foi localizada no diretório do sistema do

Windows.

Solução: Substitua o arquivo MFC42u.dll com uma versão mais recente para eliminar o

problema. Uma versão mais recente da dll pode ser encontrada no diretório inicial do

PeopleSoft.

r3batch:

Planejando jobs

do R/3

Problema: quando um job SAP é criado, a seguinte mensagem é exibida, ao tentar exibir os

detalhes de uma variante do ABAP:

AWSO0101E

Rotina de ABAP inexistente.

J_101_REPORT_ALL_SELECTIONS instale a rotina do ABAP mais recente para Maestro!!

Solução: esse defeito é causado por um erro em um módulo de função da SAP. A SAP descreve

esse problema e as possíveis soluções nas notas 0351293 e 0116354.

Ambiente misto:

Mensagens nos

logs do job de

psagent e

zosagent

Se o ambiente de planejamento consistir no Tivoli Workload Scheduler versão 8.1 e no Tivoli

Workload Scheduler para Aplicativos versão 8.2, as mensagens nos logs do job dos métodos de

acesso para z/OS e PeopleSoft exibirão prefixos duplos:

v AWSxxxx EEWIyyyy <texto da mensagem > para zosagent

v AWSxxxx EEWNyyyy <texto da mensagem> para psagent

Ambiente misto:

códigos de

retorno de jobs de

agente estendido

Se o ambiente de planejamento consistir no Tivoli Workload Scheduler versão 8.2 e no Tivoli

Workload Scheduler para Aplicativos versão 8.1.1, então, o que é exibido como o código de

retorno de um job de agente estendido enviado (por meio do Job Scheduling Console ou

conman) será na verdade o código de saída desse job. Ele não deve ser interpretado como o

código de retorno.


Resolvendo Problemas de Instalação do Método de Acesso do

PeopleSoft

A instalação desse método de acesso requer um ambiente PeopleSoft específico em

termos de um diretório que dependa de uma versão do PeopleSoft. Alguns

executáveis do método de acesso são instalados nesse procedimento. A tabela a

seguir lista os diretórios e os arquivos que você deve procurar se estiver

solucionando problemas na instalação.

Tabela 25. Caminhos do Ambiente PeopleSoft.

Versão do

PeopleSoft

Nome do Diretório Procurar estes arquivos

7.x <PS_HOME>\cblbin

em que <PS_HOME> é o diretório inicial do

servidor de arquivos do Peoplesoft e está

acessível local e remotamente de uma estação de

trabalho executando o método de acesso.

TVPUPSFT.execblrtss.dll

8.1x <EXT_API_DIR>\bin\client\winx86_extapi

em que <EXT_API_DIR> é o diretório em que as

APIs externas do PeopleSoft foram instaladas.

TVPUPSFT.exe

pspiadapter.dll

8.4x <PS_HOME>\\bin\client\winx86

em que <PS_HOME> é o diretório inicial do

servidor de arquivos do Peoplesoft e está

acessível local e remotamente de uma estação de

trabalho executando o método de acesso.

TVPUPSFT.exe

pspiadapter.dll


Capítulo 31. Arquivos Instalados

Este capítulo fornece uma lista de arquivos que você deve encontrar no sistema

durante a instalação do Tivoli Workload Scheduler para Aplicativos. As

informações são fornecidas por plataforma e por recurso. Não estão incluídos

arquivos instalados para suporte a Java, além daqueles necessários para desinstalar

o produto.

A tabela a seguir lista os arquivos instalados no Windows.

Tabela 26. Arquivos instalados no Windows.

Recurso Arquivos

Método de Acesso do

PeopleSoft

TWS_HOME\catalog\C\peoplesoft.cat

TWS_HOME\methods\PeopleSoft\PTCUDCOP.bl

TWS_HOME\methods\PeopleSoft\TVPUPSFT700.dms

TWS_HOME\methods\PeopleSoft\TVPUPSFT750.dms

TWS_HOME\methods\defs\psagent.def

TWS_HOME\methods\enigma.exe

TWS_HOME\methods\msvcrt.dll

TWS_HOME\methods\oslayer.dll

TWS_HOME\methods\psagent.exe

TWS_HOME\methods\psagent.opts

TWS_HOME\methods\psagent.properties

Para o PeopleTools 7.0x e o Merant NetExpress 2:PSHOME70CBL2\cblbin\TVPUPSFT.exe

PSHOME70CBL2\cblbin\TVPUPSFT.gnt



PeopleTools 7.0x e MF COBOL Workbench 4.x:PSHOME70CWB4\cblbin\TVPUPSFT.exe

PSHOME70CWB4\cblbin\TVPUPSFT.gnt





Para o PeopleTools 8.1x:PSHOME81X\bin\client\winx86_extapi\TVPUPSFT.exe

Para o PeopleTools 8.4x:PSHOME84X\bin\client\winx86\TVPUPSFT.exe


Tabela 26. Arquivos instalados no Windows. (continuação)

Recurso Arquivos

Método de Acesso do R/3 TWS_HOME\methods\K000443.TV1

TWS_HOME\methods\R000443.TV1

TWS_HOME\methods\r3batch.exe

TWS_HOME\methods\r3batch.opts

TWS_HOME\methods\r3batch.properties

TWS_HOME\methods\r3batch_cp.map

TWS_HOME\methods\librfc32.dll

TWS_HOME\methods\enigma.exe


TWS_HOME\methods\msvbvm60.dll

TWS_HOME\methods\msvcp60.dll

TWS_HOME\methods\defs\r3batch.def

TWS_HOME\catalog\C\r3batch.cat

Método de Acesso do z/OS TWS_HOME\methods\mvsca7.exe

TWS_HOME\methods\mvsca7.opts

TWS_HOME\methods\mvsca7.properties

TWS_HOME\methods\mvsjes.exe

TWS_HOME\methods\mvsjes.opts

TWS_HOME\methods\mvsjes.properties

TWS_HOME\methods\mvsopc.exe

TWS_HOME\methods\mvsopc.opts

TWS_HOME\methods\mvsopc.properties

TWS_HOME\methods\oslayer.dll

TWS_HOME\methods\defs\mvsca7.def

TWS_HOME\methods\defs\mvsjes.def

TWS_HOME\methods\defs\mvsopc.def


TWS_HOME\catalog\C\mvs.cat

Comum TWS_HOME\methods\opted\jakarta-oro-2.0.6.jar

TWS_HOME\methods\opted\opted.bat

TWS_HOME\methods\opted\tws4apps.jar

TWS_HOME\methods\opted\tws4appsbeans.jar

TWS_HOME\methods\opted\uil.jar

TWS_HOME\methods\opted\xercesImpl.jar

TWS_HOME\methods\opted\xmlParserAPIs.jar

TWS_HOME\methods\opted.exe

Desinstalação TWS_HOME\methods\_xauninst\uninstall.dat

TWS_HOME\methods\_xauninst\uninstall.jar

TWS_HOME\methods\_xauninst\uninstaller.exe


A tabela a seguir lista os arquivos instalados no Unix (Plataformas de nível 1).

Tabela 27. Arquivos instalados no Unix (Plataformas de nível 1).

Recurso Arquivos

Método de Acesso do Oracle

e-Business Suite

TWS_HOME/catalog/C/mcm.cat

TWS_HOME/methods/MCMAGENT.opts

TWS_HOME/methods/MCMAGENT.properties

TWS_HOME/methods/OracleTMP/MCMAGENT

TWS_HOME/methods/OracleTMP/MCMLJ.o

TWS_HOME/methods/OracleTMP/MCMSTAT.o

TWS_HOME/methods/OracleTMP/MCMTJ.o

TWS_HOME/methods/OracleTMP/MCMprod.txt

TWS_HOME/methods/OracleTMP/libusr.a

TWS_HOME/methods/OracleTMP/mcm.mk

TWS_HOME/methods/OracleTMP/mcminstall

TWS_HOME/methods/OracleTMP/mcmoptions

TWS_HOME/methods/defs/MCMAGENT.def

TWS_HOME/methods/enigma

Método de Acesso do R/3 TWS_HOME/catalog/C/r3batch.cat

TWS_HOME/methods/K000443.TV1

TWS_HOME/methods/R000443.TV1

TWS_HOME/methods/defs/r3batch.def

TWS_HOME/methods/enigma

TWS_HOME/methods/r3batch

TWS_HOME/methods/r3batch.opts

TWS_HOME/methods/r3batch.properties

TWS_HOME/methods/r3batch_cp.map

método de Acesso do z/OS TWS_HOME/catalog/C/mvs.cat

TWS_HOME/methods/defs/mvsca7.def

TWS_HOME/methods/defs/mvsjes.def

TWS_HOME/methods/defs/mvsopc.def

TWS_HOME/methods/mvsca7

TWS_HOME/methods/mvsca7.opts

TWS_HOME/methods/mvsca7.properties

TWS_HOME/methods/mvsjes

TWS_HOME/methods/mvsjes.opts

TWS_HOME/methods/mvsjes.properties

TWS_HOME/methods/mvsopc

TWS_HOME/methods/mvsopc.opts

TWS_HOME/methods/mvsopc.properties

Comum TWS_HOME/methods/opted.bin

TWS_HOME/methods/opted/jakarta-oro-2.0.6.jar

TWS_HOME/methods/opted/opted.sh

TWS_HOME/methods/opted/tws4apps.jar

TWS_HOME/methods/opted/tws4appsbeans.jar

TWS_HOME/methods/opted/uil.jar

TWS_HOME/methods/opted/xercesImpl.jar

TWS_HOME/methods/opted/xmlParserAPIs.jar

Desinstalação TWS_HOME/methods/_xauninst/uninstall.dat

TWS_HOME/methods/_xauninst/uninstall.jar

TWS_HOME/methods/_xauninst/uninstaller

Capítulo 31. Arquivos Instalados 191

Parte 7. Apêndices


Avisos

Estas informações foram desenvolvidas para produtos e serviços oferecidos nos

Estados Unidos. É possível que a IBM não ofereça os produtos, serviços ou

recursos discutidos nesta publicação em outros países. Consulte um representante

IBM local para obter informações sobre produtos e serviços disponíveis atualmente

em sua área. Qualquer referência a um produto, programa ou serviço da IBM não

tem a intenção de afirmar ou inferir que somente esse produto, programa ou

serviço possa ser utilizado. Qualquer produto, programa ou serviço funcionalmente

equivalente, que não infrinja nenhum direito de propriedade intelectual da IBM,

poderá ser utilizado em substituição a este produto, programa ou serviço.

Entretanto, a avaliação e verificação da operação de qualquer produto, programa

ou serviço não-IBM são de responsabilidade do Cliente.

A IBM pode ter patentes ou solicitações de patentes relativas a assuntos tratados

neste documento. O fornecimento deste documento não garante ao Cliente nenhum

direito sobre tais patentes. Você pode enviar consultas sobre licença, por escrito,

para:

Gerência de Relações Comerciais e Industriais da IBM Brasil

Av. Pasteur, 138 - 146, Botafogo

Rio de Janeiro, RJ

CEP 22290-240

Para pedidos de licença listados a informações de DBCS (conjunto de caracteres de

byte duplo), entre em contato com o Departamento de Propriedade Intelectual da

IBM em seu país ou envie pedidos de licença, por escrito, para:

IBM World Trade Asia Corporation

Licensing

2-31 Roppongi 3-chome, Minato-ku

Tokyo 106, Japan

O parágrafo a seguir não se aplica ao Reino Unido ou a qualquer outro país no

qual tais provisões sejam inconsistentes com leis locais:

A INTERNATIONAL BUSINESS MACHINES CORPORATION FORNECE ESTA

PUBLICAÇÃO ″NO ESTADO EM QUE SE ENCONTRA″, SEM GARANTIA DE

NENHUM TIPO, SEJA EXPRESSA OU IMPLÍCITA, INCLUINDO, MAS NÃO SE

LIMITANDO ÀS GARANTIAS IMPLÍCITAS DE NÃO-VIOLAÇÃO, MERCADO

OU ADEQUAÇÃO A UM DETERMINADO PROPÓSITO.

Alguns países não permitem a exclusão de garantias expressas ou implícitas em

certas transações; portanto, esta disposição pode não se aplicar ao Cliente.

Estas informações podem incluir imprecisões técnicas ou erros tipográficos. São

feitas alterações periódicas nas informações aqui contidas; tais alterações serão


incorporadas em futuras edições desta publicação. A IBM pode fazer

aperfeiçoamentos e/ou alterações nos produtos ou programas descritos nesta

publicação a qualquer momento sem aviso prévio.

Referências nestas informações a web sites não-IBM são fornecidas apenas por

conveniência e não representam de forma alguma um endosso a esses web sites.

Os materiais contidos nesses Web sites não fazem parte dos materiais deste

produto IBM e a utilização desses Web sites é de inteira responsabilidade do

cliente.

A IBM tem direito de utilização ou distribuição das informações da forma que

julgar adequada, sem incorrer em obrigações para com o Cliente.

Licenciados deste programa que desejam obter informações adicionais sobre este

assunto com objetivo de permitir: (i) a troca de informações entre programas

criados independentemente e outros programas (incluindo este) e (ii) a utilização

mútua das informações trocadas, devem entrar em contato com:

Gerência de Relações Comerciais e Industriais da IBM Brasil

Av. Pasteur, 138-146, Botafogo

Rio de Janeiro, RJ

CEP 22290-240

Tais informações podem estar disponíveis, sujeitas a termos e condições

apropriadas, incluindo em alguns casos o pagamento de uma taxa.

O programa licenciado descrito neste documento e todo o material licenciado

disponível são fornecidos pela IBM sob os termos do Contrato com o Cliente IBM,

Contrato de Licença de Programação Internacional IBM ou qualquer outro contrato

equivalente.

Todos os dados de desempenho aqui contidos foram determinados em um

ambiente controlado. Portanto, os resultados obtidos em outros ambientes

operacionais podem variar significativamente. Algumas medidas podem ter sido

feitas nos sistemas a nível de desenvolvimento e não há garantias de que estas

medidas serão as mesmas nos sistemas geralmente disponíveis. Além disso,

algumas medidas podem ter sido estimadas por extrapolação. Os resultados reais

podem variar. Os usuários deste documento devem verificar os dados aplicáveis

em seu ambiente específico.

Informações relativas a produtos não-IBM foram obtidas junto aos fornecedores

destes produtos, seus anúncios publicados ou outras fontes públicas disponíveis. A

IBM não efetuou testes nestes produtos e não pode confirmar a precisão de seu

desempenho, compatibilidade ou qualquer outro requisito listado a produtos

não-IBM. Dúvidas sobre os recursos de produtos não-IBM devem ser dirigidas aos

fornecedores destes produtos.

Estas informações contêm exemplos de dados e relatórios utilizados em operações

de negócios diárias. Para ilustrá-los o melhor possível, os exemplos contêm nomes

de pessoas, empresas, marcas e produtos. Todos os nomes são fictícios e qualquer

semelhança com nomes e endereços de empresas reais é mera coincidência.


Se estas informações estiverem sendo exibidas em cópia eletrônica, as fotografias e

ilustrações coloridas podem não aparecer.

Marcas

IBM, o logotipo da IBM, Tivoli, AIX, AS/400, Dynix, MVS/ESA, OS/390, RACF,

RS/6000, Sequent, z/OS e zSeries são marcas ou marcas registradas da

International Business Machines Corporation nos Estados Unidos e/ou em outros

países.

Microsoft e Windows NT são marcas registradas da Microsoft Corporation nos

Estados Unidos e/ou em outros países.

UNIX é marca registrada da The Open Group nos Estados Unidos e em outros

países.

Java e todas as marcas e logotipos baseados em Java são marcas ou marcas

registradas da Sun Microsystems, Inc. nos Estados Unidos e em outros países.

Outros nomes de empresas, produtos e serviços podem ser marcas ou marcas de

serviço de terceiros.

Avisos 197

Glossário

A

Agente de rede. Um tipo de agente estendido

utilizado para criar dependências entre jobs e fluxos de

job em redes separadas do Tivoli Workload Scheduler.

Consulte também “Dependência INET (entre redes)”.

Agente estendido. Os agentes estendidos são usados

para integrar os recursos de controle do job do Tivoli

Workload Scheduler a outros sistemas operacionais (por

exemplo, MVS) e aplicativos (por exemplo, Oracle

Applications, Peoplesoft e R/3). Os agentes estendidos

utilizam scripts chamados métodos de acesso, para se

comunicarem com sistemas externos.

Agente tolerante a falhas. Uma estação de trabalho

do agente na rede do Tivoli Workload Scheduler capaz

de resolver as dependências locais e lançar seus jobs na

ausência de um gerenciador de domínio.

agente X. Consulte “Agente estendido”.

arquivo stdlist. Um arquivo de lista padrão é criado

para cada job lançado pelo Tivoli Workload Scheduler.

Os arquivos da lista padrão contém cabeçalho e

banners do trailer, comandos repetidos, erros e avisos.

Estes arquivos podem ser utilizados para detectar

problemas na execução do job.

Arquivo symphony. Este arquivo contém as

informações de planejamento necessárias pelo processo

de Controle de Produção (batchman) para executar o

plano. O arquivo é criado e carregado durante a fase de

pré-produção. Durante a fase de produção, ele é,

continuamente, atualizado para indicar o status atual

de processamento de produção: trabalho concluído,

trabalho em andamento, trabalho a ser executado. Para

gerenciar o processamento de produção, o conteúdo do

arquivo Symphony (plano) pode ser exibido e alterado

com o Job Scheduling Console.

B

Banco de Dados. O banco de dados contém todas as

definições criadas para objetos de planejamento (por

exemplo, jobs, fluxos de job, recursos, estações de

trabalho, etc). Além disso, o banco de dados mantém

outras informações importantes tais como estatísticas

do job e execução do fluxo de job, informações sobre o

ID do usuário que criou um objeto e a última data

modificada de um objeto. Em comparação, o plano

contém somente estes jobs e fluxos de job (incluindo

objetos dependentes) que são planejados para execução

na produção diária.

Banco de dados expandido. Bancos de dados

expandidos permitem nomes mais longos para objetos

do banco de dados, tais como jobs, fluxos de job,

estações de trabalho, domínios e usuários. Os bancos

de dados expandidos são configurados utilizando o

comando dbexpand ou como uma opção durante a

instalação. Não expanda seu banco de dados antes de

entender as implicações e impacto deste comando.

Batchman. Um processo iniciado no começo de cada

dia de processamento do Tivoli Workload Scheduler

para lançar jobs de acordo com as informações no

arquivo Symphony.

C

Calendário. Um objeto definido no banco de dados do

Tivoli Workload Scheduler que contém uma lista de

datas de planejamento. Como é um objeto exclusivo

definido no banco de dados, ele pode ser atribuído a

vários fluxos de job. Atribuir um calendário a um fluxo

de job faz com que o fluxo de job seja executado nos

dias especificados no calendário. Observe que um

calendário pode ser utilizado como um ciclo de

execução inclusivo ou exclusivo.

Caracteres Curinga. Os caracteres curinga para Tivoli

Workload Scheduler são: ? Substitui um caractere alfa.

% Substitui um caractere numérico. * Substitui zero ou

mais caracteres alfanuméricos. Geralmente, os

caracteres curinga são utilizados para redefinirem uma

pesquisa para um ou mais objetos no banco de dados.

Por exemplo, se desejar exibir todas as estações de

trabalho, é possível digitar o caractere curinga asterisco

(*). Para obter uma listagem de estações de trabalho

site1 até site8, você pode digitar site%.

Ciclo de execução. Um ciclo de execução especifica os

dias em que um fluxo de job é planejado para

execução. No Tivoli Workload Scheduler, existem três

tipos de ciclos de execução que você pode especificar

para um fluxo de job: um ciclo de execução Simples,

um ciclo de execução Semanal ou um ciclo de execução

Calendário (geralmente chamado de calendário).

Observe que cada tipo de ciclo de execução pode ser

inclusivo ou exclusivo. Isto é, cada ciclo de execução

pode definir os dias que um fluxo de job é incluído no

ciclo de produção ou os dias que um fluxo de job é

excluído do ciclo de produção. Quando você definir

vários ciclos de execução para um fluxo de job e os

ciclos de execução inclusivos e exclusivos especificam

os mesmos dias, os ciclos de execução exclusivos são

antecedidos.

Ciclo de execução exclusivo. Um ciclo de execução

que especifica os dias que um fluxo de job não pode


ser executado. Os ciclos de execução exclusivos

antecedem os ciclos de execução inclusivos.

Ciclo de Execução Inclusivo. Um ciclo de execução

que especifica os dias que um fluxo de job é planejado

ser executado. Os ciclos de execução exclusivos

antecedem os ciclos de execução inclusivos.

Ciclo de Execução Semanal. Um ciclo de execução

que especifica os dias da semana que um fluxo de job é

executado. Por exemplo, um fluxo de job pode ser

especificado para executar toda segunda-feira,

quarta-feira e sexta-feira utilizando um ciclo de

execução semanal. Um ciclo de execução semanal é

definido para um fluxo de job específico e não pode ser

utilizado por vários fluxos de job. Para obter maiores

informações, consulte Ciclo de Execução.

Ciclo de Execução Simples. Um conjunto específico

de dias definidos pelo usuário em que um fluxo de job

é executado. Um ciclo de execução simples é definido

por um fluxo de job específico e não pode ser utilizado

por vários fluxos de job. Para obter maiores

informações, consulte Ciclo de Execução.

Classe da estação de trabalho. Uma classe da estação

de trabalho é um grupo de estações de trabalho. É

possível colocar qualquer número de estações de

trabalho em uma classe. Os fluxos de job e jobs podem

ser atribuídos para serem executados em uma classe da

estação de trabalho. Este cria a replicação de um job ou

fluxo de job através de muitas estações de trabalho

acessíveis.

Comandos utilitários. Um conjunto de executáveis da

linha de comandos para gerenciar o planejador.

Composer. Um aplicativo existente da linha de

comandos para gerenciamento de definições de seus

objetos de planejamento no banco de dados.

Conman. Conman (console manager) é um aplicativo

existente da linha de comandos para gerenciamento do

ambiente de produção. O Conman executa as seguintes

tarefas: inicia e pára os processos de produção, altera e

exibe agendas e jobs no plano e controla a ligação da

estação de trabalho em uma rede.

D

Dependência. Um pré-requisito que deve ser satisfeito

antes que a execução de um job ou fluxo de job possa

continuar. O número máximo de dependências

permitido para um job ou fluxo de job é 40. Os quatro

tipos de dependências utilizados pelo Tivoli Workload

Scheduler são as dependências a seguir, dependências

de recursos, dependências de arquivos e dependências

de prompts.

Dependência seguinte. Uma dependência onde um

job ou fluxo de job não pode começar a execução, até

que outros jobs ou fluxos de job foram concluídos com

êxito.

Dependências INET (entre redes). Uma dependência

entre jobs ou fluxos de jobs em redes separadas do

Tivoli Workload Scheduler. Consulte também “Agente

de rede”.

Domínio. Um grupo nomeado de estações de trabalho

do Tivoli Workload Scheduler que consiste em um ou

mais agentes e em um gerenciador de domínio que age

como o hub de gerenciamento. Todos os domínios

possuem um domínio pai, exceto para o domínio

principal.

Duração. O tempo previsto para a conclusão do job.

Na exibição Linha de Tempo de jobs no banco de

dados, a duração é representada por uma barra

azul-clara no centro da barra de atividade, ou por um

losango azul-claro.

E

Estação de trabalho. Geralmente, uma estação de

trabalho é um computador individual no qual jobs e

fluxos de job são executados. Eles são definidos no

banco de dados do Tivoli Workload Scheduler como

um objeto exclusivo. É requerida uma definição da

estação de trabalho para todo computador que executa

jobs ou fluxos de job na rede do Workload Scheduler.

Exibição em árvore. A exibição no lado esquerdo do

Job Scheduling Console que exibe o servidor do

planejador, grupos de listas padrão e grupos de listas

criadas pelo usuário.

F

Fluxo de Job Final. O fluxo de job FINAL deve ser o

último fluxo de job executado em um dia de produção.

Ele contém um job que executa o arquivo script

Jnextday.

G

Gerenciador de Domínio. O hub de gerenciamento

em um domínio do Tivoli Workload Scheduler. Todas

as comunicações para e dos agentes no domínio são

roteadas através do gerenciador de domínio.

Gerenciador de Domínio Principal. Em uma rede do

Tivoli Workload Scheduler, o gerenciador de domínio

principal mantém os arquivos utilizados para

documentar os objetos de planejamento. Ele cria o

plano no início de cada dia e executa todo registro e

relatório da rede.


H

Hora de Início Estimada. A hora antes da qual o job

ou fluxo de job não pode ser iniciado. A hora de início

estimada é aquela estimada baseada em experiências

anteriores de execução do job ou fluxo de job. No

entanto, o job ou fluxo de job pode iniciar após a hora

especificada, desde que todas as outras dependências

estejam solucionadas. Na linha de tempo, a hora de

início é representada pelo início (canto esquerdo) da

barra de atividade azul-marinho. Para ocorrências de

jobs, a hora de início que o IBM Tivoli Workload

Scheduler para z/OS calcula é representado por uma

barra azul-clara.Consulte também“Tempo de início

atual” e “Hora inicial planejada”.

Hora Inicial Planejada. A hora que o planejador

estima que uma ocorrência de job será iniciada. Esta

estimativa é baseada nas horas de início de execuções

anteriores.

Host. Uma estação de trabalho do Workload Scheduler

requerida por agentes estendidos. Pode ser qualquer

estação de trabalho do planejador, exceto outro agente

estendido.

I

J

Job . Uma unidade de trabalho que é processada em

uma estação de trabalho. A definição do job consiste

em um nome de job exclusivo no banco de dados do

planejador junto com outras informações necessárias

para executar o job. Quando você inclui um job em um

fluxo de job, é possível definir suas dependências e

suas restrições de tempo tal como a hora de início e o

tempo final estimados.

Job externo. Um job de um fluxo de job que é um

predecessor de um job de outro fluxo de job. Um job

externo é representado por um ícone marcador de lugar

na exibição de Gráfico do fluxo do job.

Job / Fluxo de Job INET (entre redes). Um job ou

fluxo de job de uma rede remota do Tivoli Workload

Scheduler que é um predecessor de um job ou fluxo de

job na rede local. Um job entre redes é representado

por um ícone marcador de lugar na exibição de Gráfico

do fluxo de job. Consulte também “Agente de rede”.

Job Jnextday. O processamento da produção anterior e

posterior pode ser totalmente automatizado pelo

planejamento do job Jnextday para execução no final

de cada dia. Um exemplo de job jnextday é fornecido

como TWShome\Jnextday. O job Jnextday faz o

seguinte: configura o processamento do dia seguinte

(contido no arquivo Symphony), imprime relatórios,

transporta fluxos de job não concluídos e encerra e

reinicia o planejador.

Jobs interativos. Um job que é, interativamente,

executado em um desktop do Windows NT.

Job Stream (Fluxo de Job). Uma lista de jobs que é

executada como uma unidade (tal como um aplicativo

de backup semanal), junto com horas, prioridades e

outras dependências que determinam a ordem exata de

execução do job.

L

Limitador. O limitador de job é um controle principal

na execução do job em uma estação de trabalho. O

limitador de job é um nível de prioridade que uma

prioridade do job ou do fluxo de job deve exceder

antes de poder ser executado. Por exemplo, definir o

limitador para 40 previne que jobs com prioridades 40

ou menos sejam lançados.

Limite. Os limites do job fornecem uma maneira de

alocar um número específico de slots de job no qual o

Tivoli Workload Scheduler tem permissão para lançar

jobs. Um limite de job pode ser definido para cada

fluxo de job e para cada estação de trabalho. Por

exemplo, definir o limite de job da estação de trabalho

como 25 permite que o planejador não tenha mais que

25 jobs sendo executados simultaneamente na estação

de trabalho.

Lista. Uma lista exibe objetos de planejamento de job.

É necessário criar listas separadas para cada objeto de

planejamento do job. Para cada objeto de planejamento

do job, há dois tipos de listas: uma de definições no

banco de dados e outra de ocorrências no plano.

M

Método de acesso. Um método de acesso é um

executável usado por agente estendidos para conectar e

controlar a execução do job em outros sistemas

operacionais (por exemplo, MVS) e aplicativos (por

exemplo, Oracle Applications, Peoplesoft e R/3). O

método de acesso deve ser especificado na definição da

estação de trabalho para o agente estendido.

N

Ocorrência do fluxo de job. Um fluxo de job

planejado para uma data de execução específica no

plano. Consulte também “Fluxo de job”.

Ocorrência do Job. Um job planejado para uma data

de execução específica no plano. Consulte também

“Job”.

Opções globais. As opções globais são definidas no

gerenciador de domínio principal no arquivo globalopts

e essas opções aplicam-se a todas as estações de

trabalho na rede do Tivoli Workload Scheduler.

Consulte também “Opções locais”.

Glossário 201

Opções locais. São definidas no arquivo localopts.

Cada estação de trabalho na rede do Tivoli Workload

Scheduler deve ter um arquivo localopts. As definições

neste arquivo aplicam-se apenas a essa estação de

trabalho. Consulte também “Opções globais”.

P

Parâmetro. Os parâmetros são utilizados para

substituir valores em seus jobs e fluxos de job. Ao

utilizar um parâmetro em um script de job, o valor será

substituído na hora da execução. Neste caso, o

parâmetro deve ser definido na estação de trabalho

onde será utilizado. Os parâmetros não podem ser

utilizados quando fazer um script de jobs de agentes

estendidos.

Plano. O plano contém toda atividade de

planejamento de job planejada por um período de um

dia. No Tivoli Workload Scheduler, o plano é criado a

cada 24 horas e consiste em todos os jobs, fluxos de job

e objetos de dependência que são planejados para

serem executados nesse dia. Todos os fluxos de jobs

para os quais foram criados ciclos de execução, são

planejados automaticamente e incluídos no plano.

Como os progressos do ciclo de produção, os jobs e

fluxos de job no plano são executados de acordo com

suas restrições de tempo e outras dependências. Todos

os jobs ou fluxos de jobs que não são executados com

êxito, são deixados no plano do dia seguinte.

Predecessor. Um job que deve ser concluído com êxito

antes que os jobs do sucessor possam começar a

execução.

Prioridade. O planejador possui um sistema de

enfileiramento para jobs e fluxos de job no plano. Você

pode atribuir um nível de prioridade para cada job e

fluxo de job de 0 a 101. Uma prioridade 0 não será

executada.

Prompt. Os prompts podem ser utilizados como

dependências para jobs e fluxos de job. Um prompt

deve ser respondido positivamente para o job ou fluxo

de job dependente a ser lançado. Existem dois tipos de

prompts: predefinido e especial. Um prompt ad hoc é

definido dentro das propriedades de job ou fluxo de

job e é exclusivo para esse job ou fluxo de job. Um

prompt predefinido é definido no banco de dados do

planejador e pode ser utilizado por qualquer job ou

fluxo de job.

R

Recurso. Os recursos podem representar recursos

físicos ou lógicos em seu sistema. Uma vez definidos

no banco de dados do Tivoli Workload Scheduler, eles

podem ser utilizados como dependências para jobs e

fluxos de job. Por exemplo, você pode definir um

recurso nomeado ″fitas″ com um valor de unidade dois.

Em seguida, definir jobs que requerem duas unidades

de fitas disponíveis como uma dependência. Os jobs

com esta dependência não podem ser executados

concorrentemente, porque toda vez que um job é

executado, o recurso de “fitas” está em uso.

Restrições de tempo. Podem ser especificadas para

jobs e fluxos de job. Uma hora pode ser especificada

para a execução começar ou uma hora pode ser

especificada, após a qual a execução não será tentada.

Especificando ambas, você pode definir uma janela

dentro da qual um job ou fluxo de job será executado.

Para os jobs, você também pode especificar uma taxa

de repetição. Por exemplo, você pode lançar no Tivoli

Workload Scheduler o mesmo job a cada 30 minutos

entre às 8:30 a.m. e 1:30 p.m.

S

Status. Reflete o status atual do job ou fluxo de job

dentro do Job Scheduling Console. O status do Job

Scheduling Console é comum para o Tivoli Workload

Scheduler e IBM Tivoli Workload Scheduler para

z/OS.Consulte também Status interno.

Status do job. Consulte “Status”.

Status interno. Reflete o status atual de jobs e fluxos

de job no mecanismo do planejador. O status interno é

exclusivo para o Tivoli Workload Scheduler. Consulte

também Status.

Sucessor. Um job que não pode ser iniciado, até que

todos os jobs do predecessor nos quais ele depende

sejam concluídos com êxito.

T

Tempo final. O último momento em que um job ou

fluxo de job pode começar a execução. Este

corresponde à Hora final no Maestro existente.

U

Usuário. Somente para o Windows NT, o nome do

usuário especificado em um campo “Logon” de

definição do job deve ter uma definição do usuário

correspondente. As definições fornecem as senhas do

usuário requeridas pelo planejador para lançar jobs.

W

X


Índice Remissivo

Caracteres

EspeciaisWORKSTATION

NAME_MCMAGENT.opts 48

Aacessibilidade xiii

agentepadrão 45

tolerante a falhas 45

agente estendidodefinição de estação de trabalho 169

referência 169

visão geral 169

alterado senha, usuário RFC 97

arquivo de controle 94

arquivo de dados 94

arquivo de opções 57

arquivo de opções, R3OPTIONS 85

Arquivo de Script 154

arquivo mcmagent.optsexemplo 54

sintaxe de entrada 53

visão geral 53

arquivo R3OPTIONS 85

arquivos de correção e de transporte 94

arquivos de opções psagent 65

Bbancos de dados do Peoplesoft,

vários 69

BDC wait 127

CCA7INTERFACE 145

CA7NAME 145

CA7OPTIONS 146

CA7SPAN(9999) 146

CA7SUBSYSTEM 146

CA7USER 146

CFuser 152

CheckInterval 152

compatibilidade 87

COMPLETIONCODE 147

conectando vários bancos de dados 69

conexão para R/3, solução de

problemas 96

conexão R/3 96

contato por e-mail xii

controle de execução do job 101

convençõestipo de caractere xiii

convenções de tipo de caractere xiii

criando jobs de agente estendido 77

criando o perfil de autorização 91

criando um job 102

criando um job no R/3 101

criando uma dependência aberta 78

criptografando, senha do usuário do

R/3 89

criptografando senhas do usuário 54

criptografia de senha 54

DDEBUG 147

definições de job 77

definindo jobs do Oracle Applicationsno Tivoli Workload Scheduler 49

definindo jobs no Oracle

Applications 49

definindo jobs no Peoplesoft 57

definindo jobs no R/3 101

dependência aberta 78

dependência em jobs do zOS 154

dependências de job do zOS 154

depurar 96

Eenigma 54

estados, job 112

estados de ocorrência para o OPC 160

estados do aplicativo para o OPC 160

estados do jobMaestro e Oracle Applications 51

estados do job do R/3 112

estados do job para CA7 158

estados do job para JES 157

estados do job para o OPC 160

execução de job 201

exemplo de dependências abertas 79

exemplos de dependências abertas 79

Ffeedback sobre as publicações xii

Ggateway do z/OS

descarregando arquivos da fita 143

descarregando arquivos do

CD-ROM 142

Hhost de destino 105

Iincluindo, ABAP 106

incluindo, etapas 106

incluindo, programa externo 106

informações de diagnóstico 162

informações iniciais 57

iniciar 145

instalação 149

instalando módulos ABAP 91

INTERLINKSUBSYSTEM 147

JJCL para descarregar a fita 143

JESCMDCHR 147

joblog 127

jobsestados do job 112

jobs do CA7 153

jobs do JES 153

jobs do OPC 154

jobs do Oracle Applicationsdefinindo 49

LLJuser 152

Mmanuais

consultar publicações ix, xii

mapeamento de status do job 80

mapeando status, jobs 80

mapeando status do job 80

MAXWAIT 147

MCMAGENT 47

MCMAGENT.opts 47

MCSSTORAGE 147

mensagens 165

mensagens de erro 165

mensagens de gateway 165

método 85

método do R3BATCH 85

módulos ABAP 106

módulos ABAP, importando 94

Nnomes de caminho, notação xiv

nomes de diretório, notação xiv

notaçãonomes de caminho xiv

tipo de caractere xiv

variáveis de ambiente xiv

Oopção BDC wait 96

OPCINTERFACE 147

OPCMSGCLASS 148

opções psagent 65


OPCSUBSYSTEM 148

OPERCMDS 145

Oracle Applications x-agentrecursos 45

PPEERADDRESS 148

perfil de autorização, criando 91

perfil RFC 91

pilha TCPIP 148

planejando agentevisão geral 85

PORT 148

programa enigma 89

programa externo 106

psagent 57, 69

publicações ix

acessando on-line xii

solicitando xii

publicações on-lineacessando xii

PUTLINE 148

QQLIMIT 148

Rrastreio 96

recursos 45, 57, 141

requisitos de software 61, 63

requisitos do host 61

SSaída IEFU84 144

segurança 144

segurança do console 145

senha do usuário RFC 97

sintaxe, arquivo mcmagent.opts 53

softwarecomponentes 47

requisitos 45

software de interface 47

solicitando publicações xii

solução de problemas de conexão

R/3 96

status de verificação bm 159, 161

SUBSYS 148

suporte ao clienteconsulte suporte de software xiii

suporte ao softwareentrando em contato xiii

SVCDUMP 148

TTCPIPSTACK 148

TCPNAME 149

TERMINATOR 149

Tivoli Software Information Center xii

UUsuário RFC 96

Vvariáveis, notação de xiv

variáveis de ambiente, notação xiv

variáveis SYSTSIN 145

vários bancos de dados do Peoplesoft 69

versão TCP/IP 141

visão geral 57

visão geral da operação CA7 158

visão geral da operação JES 157, 158

visão geral da operação OPC 159

visão geral de instalação 87

visão geral técnica 157

WWTP 149

ZZOSV1R2 149


��

Impresso em Brazil

S517-7785-00

Guia do Usuário -...

Documents

Transcript of Guia do Usuário -...