T l Tivoli Workload -...

Tivoli® IBM Tivoli Workload

Scheduler

Guía de planificación e instalación

Versión 8.2 (Revisada en diciembre de 2004)

SC10-3833-02

��

Nota

Antes de utilizar este manual y el producto al que da soporte, lea la información contenida en la sección “Avisos” en la

página 175.

Tercera edición (diciembre 2004)

Este manual es la traducción del original inglés IBM Tivoli Workload Scheduler Planning and Installation Guide Version

8.2 (Revised December 2004), (SC32-1273-02).

Esta edición es aplicable a la versión 8, release 2, nivel de modificación 0 de IBM Tivoli Workload Scheduler

(número de programa 5698-WSH) y a todos los releases y modificaciones subsiguientes hasta que se indique lo

contrario en nuevas ediciones.

Esta edición sustituye a la SC10-3833-01.

© Copyright International Business Machines Corporation 1991, 2004. Reservados todos los derechos.

Contenido

Lista de figuras . . . . . . . . . . . vii

Lista de tablas . . . . . . . . . . . . ix

Acerca de esta guía . . . . . . . . . xi

Novedades de esta guía . . . . . . . . . . xi

A quién va dirigida esta guía . . . . . . . . xi

Contenido de esta guía . . . . . . . . . . . xi

Publicaciones . . . . . . . . . . . . . . xii

Biblioteca de Tivoli Workload Scheduler . . . . xii

Publicaciones afines . . . . . . . . . . xv

Acceso a las publicaciones en línea . . . . . xvi

Solicitud de publicaciones . . . . . . . . xvi

Accesibilidad . . . . . . . . . . . . . xvii

Información sobre el soporte . . . . . . . . xvii

Convenios utilizados en este manual . . . . . xvii

Convenios tipográficos . . . . . . . . . xvii

Variables y rutas dependientes del sistema

operativo . . . . . . . . . . . . . xviii

Sintaxis de los comandos . . . . . . . . xviii

Parte 1. Introducción . . . . . . . . 1

Capítulo 1. Introducción . . . . . . . . 3

Visión general de Tivoli Workload Scheduler . . . 3

Procesos . . . . . . . . . . . . . . . . 4

Comunicaciones de red . . . . . . . . . . . 5

Funcionamiento de la red . . . . . . . . . . 6

Agentes ampliados . . . . . . . . . . . . 6

Método de acceso de UNIX local . . . . . . 7

Método de acceso de UNIX remoto . . . . . . 7

Agentes ampliados de UNIX . . . . . . . . 7

Instancias del producto . . . . . . . . . . . 8

Archivo de registro . . . . . . . . . . . 8

Archivo de componentes . . . . . . . . . 9

Guía de inicio rápido . . . . . . . . . . . 10

Parte 2. Planificación . . . . . . . 11

Capítulo 2. Iniciación . . . . . . . . 13

Planificación de la red . . . . . . . . . . . 13

Visión general de la red de Tivoli Workload

Scheduler . . . . . . . . . . . . . . 13

Funcionalidad de dominio . . . . . . . . 13

Proceso localizado en el dominio . . . . . . 14

Consideraciones sobre la red . . . . . . . 14

Una red de un sólo dominio . . . . . . . . 15

Una red de dominio múltiple . . . . . . . 16

Conmutación a un gestor de dominio de reserva 17

Mecanismo de conmutación tolerante a errores 17

Bases de datos ampliadas . . . . . . . . . 19

Nombres de estación de trabajo . . . . . . . 19

Instalación del conector . . . . . . . . . 20

Consideraciones sobre los husos horarios . . . 21

Planificación de instalaciones . . . . . . . . 21

Selección de tipos de estación de trabajo . . . . 21

Selección del método de instalación . . . . . 21

Selección del tipo de instalación . . . . . . . 24

Comprobación de los requisitos de autorización del

usuario . . . . . . . . . . . . . . . . 25

Roles de autorización para ejecutar el asistente de

instalación . . . . . . . . . . . . . . 25

Roles de autorización para ejecutar el script

twsinst . . . . . . . . . . . . . . . 26

Roles de autorización para Software Distribution 26


customize . . . . . . . . . . . . . . 27

Roles de autorización para ejecutar una

instalación . . . . . . . . . . . . . . 27

Antes de la instalación . . . . . . . . . . . 27

Información sobre el usuario de Tivoli Workload

Scheduler . . . . . . . . . . . . . . 27

Criterios de validación de elementos de

instalación . . . . . . . . . . . . . . 28

Instalación para la planificación global . . . . 29

Información sobre la instalación . . . . . . 29

Antes de la actualización . . . . . . . . . . 32

Desvinculación y detención de Tivoli Workload

Scheduler . . . . . . . . . . . . . . 32

Detención del conector . . . . . . . . . 33

Archivos de copia de seguridad . . . . . . 34

Utilización de los nuevos archivos de

configuración . . . . . . . . . . . . . 34

Ampliación de la base de datos . . . . . . . 35

Implicaciones de Tivoli Management Framework 35

Parte 3. Instalación y actualización 37

Capítulo 3. Instalación mediante el

asistente de instalación . . . . . . . 39

Instalación de una instancia nueva de Tivoli

Workload Scheduler . . . . . . . . . . . 39

Secuencia de la instalación típica . . . . . . 40

Secuencia de la instalación completa . . . . . 41

Secuencia de la instalación personalizada . . . 43

Adición de una función nueva en una instalación

existente . . . . . . . . . . . . . . . 46

Promoción de una instalación existente . . . . . 48

Realización de una instalación desatendida . . . . 49

Procedimiento de instalación . . . . . . . 49

Capítulo 4. Instalación y promoción

mediante twsinst . . . . . . . . . . 51

Instalación y promoción . . . . . . . . . . 51

Capítulo 5. Instalación mediante

Software Distribution . . . . . . . . 55

© Copyright IBM Corp. 1991, 2004 iii

Paquetes de software y parámetros . . . . . . 55

Procedimiento de instalación . . . . . . . . 57

Instalación de paquetes de idioma . . . . . . . 58

Capítulo 6. Instalación mediante

customize . . . . . . . . . . . . . 61

El script customize . . . . . . . . . . . . 61

Instalación del motor de Tivoli Workload Scheduler 62

Capítulo 7. Actualización de Tivoli

Workload Scheduler . . . . . . . . . 65

Casos de actualización . . . . . . . . . . . 65

Actualización de Tivoli Workload Scheduler . . . 66

Utilización del asistente de instalación . . . . 66

Utilización de twsinst . . . . . . . . . . 68

Utilización del archivo de respuestas

migrationInstall . . . . . . . . . . . . 72

Utilización de Software Distribution . . . . . 73

Utilización de customize . . . . . . . . . 73

Parte 4. Configuración . . . . . . . 77

Capítulo 8. Después de la instalación 79

Netman . . . . . . . . . . . . . . . 79

Configuración de un gestor de dominio maestro . . 79

Configuración de un gestor de conmutación

tolerante a errores . . . . . . . . . . . . 80

Configuración de un agente tolerante a errores o un

agente estándar . . . . . . . . . . . . . 80

Actualización del archivo de seguridad . . . . . 82

Pasos de configuración para instalaciones UNIX de

Nivel 1 y Nivel 2 . . . . . . . . . . . . 82

Pasos de configuración para instalaciones de Nivel 2 83

Configuración de un agente tolerante a errores

después de la instalación . . . . . . . . . 83

Habilitación de la función de huso horario . . . . 84

Habilitación del huso horario en una red global 86

Capítulo 9. Personalización opcional 87

Opciones globales . . . . . . . . . . . . 87

Definición de las opciones globales . . . . . 87

Opciones de traspaso . . . . . . . . . . 91

Opciones locales . . . . . . . . . . . . . 92

Definición de las opciones locales . . . . . . 92

Configuración de la administración descentralizada 102

Compartimiento de los directorios del maestro 102

Compartimiento de parámetros de Tivoli

Workload Scheduler . . . . . . . . . . 102

Utilización de un sólo compartimiento . . . . 102

Definición de las opciones locales . . . . . 103

Definición de las opciones locales en el maestro 103

Mensajes de consola y mensajes de solicitud de

Tivoli Workload Scheduler . . . . . . . . . 104

Definición de sysloglocal en UNIX . . . . . 104

El comando console . . . . . . . . . . 105

Automatización del ciclo de producción . . . . 105

Personalización de la secuencia de trabajos final 106

Inicio de un ciclo de producción . . . . . . 106

Gestión del entorno de producción . . . . . . 106

Elección del inicio del día . . . . . . . . 106

Cambio del inicio del día . . . . . . . . 107

Creación de un plan para fechas futuras o

pasadas . . . . . . . . . . . . . . 107

Utilización de los scripts de configuración . . . . 108

Variables de entorno de Jobman . . . . . . 108

Script de configuración estándar - jobmanrc . . 109

Script de configuración local - .jobmanrc . . . 111

Tivoli Workload Scheduler y Tivoli Management

Framework . . . . . . . . . . . . . . 113

Tivoli Management Framework para usuarios

que no utilizan Tivoli . . . . . . . . . . 113

Adición de administradores de Tivoli . . . . 114

Consideraciones sobre el maestro de copia de

seguridad . . . . . . . . . . . . . . 116

Maestros que no dan soporte a Tivoli

Management Framework . . . . . . . . 117

Capítulo 10. Integración con otros

productos de IBM Tivoli . . . . . . . 121

Integración con IBM Tivoli Enterprise Data

Warehouse . . . . . . . . . . . . . . 121

Integración con IBM Tivoli NetView . . . . . . 121

General . . . . . . . . . . . . . . 121

Instalación del software de integración . . . . 124

Configuración . . . . . . . . . . . . 126

Objetos, símbolos y submapas . . . . . . . 128

Acciones del menú . . . . . . . . . . 130

Eventos de Tivoli Workload Scheduler/NetView 132

Archivos de configuración de Tivoli Workload

Scheduler/NetView . . . . . . . . . . 135

Opciones de configuración de Tivoli Workload


MIB de Unison Software . . . . . . . . 140

los apartados de programas de Tivoli Workload


Integración con IBM Tivoli Business Systems

Manager . . . . . . . . . . . . . . . 145

General . . . . . . . . . . . . . . 145

Utilización del mecanismo del indicador clave 146

Instalación y actualización del agente de

escucha común . . . . . . . . . . . . 147

Personalización de los archivos de configuración 148

Inicio y detención del agente de escucha común 150

Eventos de Tivoli Workload Scheduler/IBM

Tivoli Business Systems Manager . . . . . . 150

Capítulo 11. Definición de la

seguridad . . . . . . . . . . . . . 153

Definición de una autenticación y un cifrado

estrictos . . . . . . . . . . . . . . . 153

Conceptos clave de SSL . . . . . . . . . 154

Planificación del soporte de SSL en Tivoli


Configuración del soporte de SSL en Tivoli


Cómo trabajar con cortafuegos . . . . . . . 164

Capítulo 12. Desinstalación de Tivoli

Workload Scheduler . . . . . . . . 167

iv IBM Tivoli Workload Scheduler - Guía de planificación e instalación

Utilización del asistente de desinstalación . . . . 167

Utilización del script twsinst . . . . . . . . 167

Utilización de la CLI de Software Distribution . . 168

Utilización del script customize . . . . . . . 168

Apéndice. Información de soporte 171

Búsqueda en bases de conocimiento . . . . . . 171

Búsqueda en el centro de información en el

sistema local o en la red . . . . . . . . . 171

Búsqueda en el centro de información en el sitio

Web de soporte de IBM . . . . . . . . . 171

Búsqueda en Internet . . . . . . . . . . 172

Obtención de arreglos . . . . . . . . . . 172

Cómo ponerse en contacto con IBM Software

Support . . . . . . . . . . . . . . . 172

Determinación del impacto comercial del

problema . . . . . . . . . . . . . . 173

Descripción del problema y recopilación de la

información básica . . . . . . . . . . 173

Envío del problema a IBM Software Support 174

Avisos . . . . . . . . . . . . . . 175

Open source: test . . . . . . . . . . . . 176

Open source: OpenSSL . . . . . . . . . . 177

ASPECTOS DE LA LICENCIA . . . . . . 177

Licencia de OpenSSL . . . . . . . . . . 177

Licencia original de SSLeay . . . . . . . . 178

Open source: biblioteca de SNMP . . . . . . 179

Open source: biblioteca de husos horarios . . . . 180

Kit de herramientas de Tivoli Internationalization

Services . . . . . . . . . . . . . . . 180

Marcas registradas . . . . . . . . . . . . 181

Glosario . . . . . . . . . . . . . 183

Índice . . . . . . . . . . . . . . . 189

Contenido v

vi IBM Tivoli Workload Scheduler - Guía de planificación e instalación

Lista de figuras

1. Flujos del proceso . . . . . . . . . . . 5

2. Procesos en el funcionamiento de la red . . . 6

3. Topología de un sólo dominio . . . . . . 16

4. Dependencias inter-red . . . . . . . . . 16

5. Topología de dominio múltiple . . . . . . 17

6. Arquitectura de conexiones de entrada

múltiples . . . . . . . . . . . . . 18

7. Arquitectura del agente de escucha común 145

© Copyright IBM Corp. 1991, 2004 vii

viii IBM Tivoli Workload Scheduler - Guía de planificación e instalación

Lista de tablas

1. Sintaxis de los comandos . . . . . . . xviii

2. Atributos contenidos en el archivo de registro 8

3. Selección de la instalación de la estación de

trabajo . . . . . . . . . . . . . . 21

4. Métodos de instalación, componentes y

funciones . . . . . . . . . . . . . 23

5. Opciones de instalación de Tivoli Workload

Scheduler . . . . . . . . . . . . . 24

6. Roles de autorización necesarios para ejecutar

el asistente de instalación . . . . . . . . 25


twsinst . . . . . . . . . . . . . . 26

8. Roles de autorización necesarios para Software

Distribution . . . . . . . . . . . . 26


customize . . . . . . . . . . . . . 27


una actualización . . . . . . . . . . 27

11. Criterios de validación de elementos de

instalación . . . . . . . . . . . . . 28

12. Funciones de ISMP . . . . . . . . . . 39

13. Datos de CPU . . . . . . . . . . . . 41

14. Información sobre el conector de Tivoli


15. Panel de instalación de Tivoli Management

Framework . . . . . . . . . . . . 42

16. Panel de información de Tivoli Plus Module 44

17. Panel de instalación de la versión de Tivoli


18. Funciones y componentes instalables

opcionales . . . . . . . . . . . . . 46

19. Archivos de respuestas . . . . . . . . . 49

20. SPB para instalar Tivoli Workload Scheduler 55

21. Parámetros de instalación de SPB . . . . . 56

22. Lista de parámetros para instalar paquetes de

idioma . . . . . . . . . . . . . . 59

23. Actualización de Tivoli Workload Scheduler,

Versión 8.2 . . . . . . . . . . . . . 65

24. Utilización de las opciones de copia de

seguridad de twsinst . . . . . . . . . 69

25. Sintaxis de Globalopts . . . . . . . . . 87

26. Sintaxis de Localopts . . . . . . . . . 92

27. Accesos directos para codificadores de cifrado 98

28. Variables de entorno de Jobman . . . . . 108

29. Variables de jobmanrc . . . . . . . . . 109

30. Objetos y símbolos de Tivoli Workload

Scheduler/NetView . . . . . . . . . 128

31. Estado de Tivoli Workload


32. Eventos de Tivoli Workload


33. Condiciones de excepción específicas de

empresa . . . . . . . . . . . . . 140

34. Eventos reenviados para objetos de

planificación clave y no clave . . . . . . 146

35. Eventos de Tivoli Workload Scheduler para

Tivoli Business Systems Manager . . . . . 150

36. Archivos para opciones locales . . . . . . 161

37. Tipo de comunicación de acuerdo con el valor

de securitylevel. . . . . . . . . . . . 162

38. Accesos directos para codificadores de cifrado 164

© Copyright IBM Corp. 1991, 2004 ix

x IBM Tivoli Workload Scheduler - Guía de planificación e instalación

Acerca de esta guía

El manual IBM Tivoli Workload Scheduler - Guía de planificación e instalación

proporciona información sobre la instalación de una red de IBM Tivoli Workload

Scheduler 8.2. Esto incluye información sobre cómo planificar una red, instalar el

motor de Tivoli Workload Scheduler, el software del conector y la interfaz gráfica

de usuario. El manual también proporciona instrucciones para personalizar

opciones y elementos de seguridad de Tivoli Workload Scheduler para iniciar una

red. Finalmente, proporciona sugerencias e información sobre la migración desde

versiones anteriores del producto.

Novedades de esta guía

Este capítulo describe las modificaciones realizadas en esta guía.

Ahora esta publicación está dividida en las partes siguientes:

v Planificación: esta parte de la publicación proporciona la información necesaria

para planificar la instalación de la red. Describe la arquitectura, los requisito

previos de instalación y las tareas de preinstalación.

v Instalación: esta parte de la publicación proporciona la información necesaria

para instalar la red. Describe los diferentes métodos de instalación.

v Configuración: esta parte de la publicación proporciona la información necesaria

para configurar la red después de la instalación.

La versión anterior no estaba dividida en partes.

Además de reestructurar la publicación, también se ha añadido información nueva

acerca de los fix packs aparecidos desde el release anterior. Esta información está

relacionada con la nueva función añadida al fix pack 3 para la prestación de copia

de seguridad y la nueva función de gestión de conmutación tolerante a errores

añadida al fix pack 5.

A quién va dirigida esta guía

Esta guía va dirigida a las personas siguientes:

v Administradores de Tivoli Workload Scheduler: quienes planifican el diseño de

la red de Tivoli Workload Scheduler

v Instaladores - quienes instalan los diversos paquetes de software en los sistemas

que componen la red de Tivoli Workload Scheduler

Contenido de esta guía

Esta guía contiene los capítulos siguientes:

v Capítulo 1, “Introducción”, en la página 3

Describe la arquitectura del producto.

v Capítulo 2, “Iniciación”, en la página 13

Describe todo lo que necesita saber para poder iniciar la instalación.

v Capítulo 3, “Instalación mediante el asistente de instalación”, en la página 39

Describe la instalación mediante un asistente de instalación.

v Capítulo 4, “Instalación y promoción mediante twsinst”, en la página 51

© Copyright IBM Corp. 1991, 2004 xi

Describe la instalación mediante el script twsinst.

v Capítulo 5, “Instalación mediante Software Distribution”, en la página 55

Describe la instalación mediante bloques de paquetes de software.

v Capítulo 6, “Instalación mediante customize”, en la página 61

Describe la instalación mediante el script customize.

v Capítulo 7, “Actualización de Tivoli Workload Scheduler”, en la página 65

Describe cómo migrar y promover componentes.

v Capítulo 8, “Después de la instalación”, en la página 79

Describe la configuración que necesita realizar una vez finalizada la instalación.

v Capítulo 9, “Personalización opcional”, en la página 87

Describe cómo poner a punto la instalación.

v Capítulo 11, “Definición de la seguridad”, en la página 153

Describe cómo definir los parámetros de seguridad.

Publicaciones

Esta sección lista publicaciones de la biblioteca de Tivoli Workload Scheduler y

documentos afines. También describe cómo acceder a las publicaciones de Tivoli en

línea y cómo solicitar publicaciones de Tivoli.

Biblioteca de Tivoli Workload Scheduler

Tivoli Workload Scheduler comprende varios productos independientes disponibles

en diversas plataformas. La biblioteca se divide de forma similar:

Biblioteca de la suite IBM Tivoli Workload Scheduling

Esta biblioteca contiene todas las publicaciones para todas las plataformas

y todos los productos de Tivoli Workload Scheduler.

Biblioteca distribuida de IBM Tivoli Workload Scheduler

Esta biblioteca contiene todas las publicaciones que hacen referencia al uso

de Tivoli Workload Scheduler en plataformas distintas de z/OS.

Biblioteca de IBM Tivoli Workload Scheduler for z/OS

Esta biblioteca contiene todas las publicaciones que sólo atañen a IBM

Tivoli Workload Scheduler for z/OS.

Biblioteca de IBM Tivoli Workload Scheduler for Applications


Tivoli Workload Scheduler for Applications.

Biblioteca de IBM Tivoli Workload Scheduler for Virtualized Data Centers


Tivoli Workload Scheduler for Virtualized Data Centers.

Biblioteca de la suite IBM Tivoli Workload Scheduling

Las publicaciones siguientes están disponibles en la biblioteca de la suite IBM

Tivoli Workload Scheduling. Ésta incluye publicaciones que son comunes para

todos los productos, plataformas y componentes.

v IBM Tivoli Workload Scheduler: General Information, SC32-1256

Proporciona información general sobre todos los productos Tivoli Workload

Scheduler. Ofrece una perspectiva general sobre cómo utilizar estos productos de

forma conjunta para proporcionar soluciones de gestión de carga de trabajo en

toda la empresa.

v IBM Tivoli Workload Scheduler: Job Scheduling Console - Guía del usuario, SC10-3171

Contenido de esta guía

xii IBM Tivoli Workload Scheduler - Guía de planificación e instalación

Describe cómo trabajar con Tivoli Workload Scheduler, independientemente de

la plataforma, utilizando una GUI común denominada Job Scheduling Console.

v IBM Tivoli Workload Scheduler: Job Scheduling Console Release Notes, SC32-1258

Proporciona información de última hora sobre Job Scheduling Console.

v IBM Tivoli Workload Scheduler: Warehouse Enablement Pack Version 1.1.0

Implementation Guide for Tivoli Enterprise Data Warehouse, Version 1.1,

Proporciona información sobre la habilitación de Tivoli Workload Scheduler para

Tivoli Data Warehouse.

Nota: Esta guía sólo está disponible en el CD del producto. No es posible

acceder a esta guía en línea, tal y como puede hacerse con los otros libros

(consulte el apartado “Acceso a las publicaciones en línea” en la página

xvi).

Biblioteca distribuida IBM Tivoli Workload Scheduler

Las publicaciones siguientes están disponibles en la biblioteca distribuida de IBM

Tivoli Workload Scheduler. Ésta incluye publicaciones que hacen referencia a la

utilización del producto en todas las plataformas excepto en z/OS.

v IBM Tivoli Workload Scheduler: Release Notes, SC32-1277

Proporciona información de última hora sobre Tivoli Workload Scheduler en

plataformas distintas de z/OS.

v IBM Tivoli Workload Scheduler: Guía de planificación e instalación, SC10-3833

Describe cómo planificar e instalar IBM Tivoli Workload Scheduler en

plataformas distintas de z/OS y cómo integrar Tivoli Workload Scheduler con

NetView, Tivoli Data Warehouse e IBM Tivoli Business Systems Manager.

v IBM Tivoli Workload Scheduler: Guía de consulta, SC10-3852

Describe la línea de comandos de Tivoli Workload Scheduler que se utiliza en

plataformas distintas de z/OS y cómo actúan los agentes ampliados y los

agentes de red.

v IBM Tivoli Workload Scheduler: Administration and Troubleshooting, SC32-1275

Proporciona información sobre cómo administrar Tivoli Workload Scheduler en

plataformas distintas de z/OS y qué hacer si se produce algún fallo. Incluye

ayuda sobre muchos de los mensajes que generan los componentes principales

de Tivoli Workload Scheduler.

v IBM Tivoli Workload Scheduler: Agente tolerante a errores limitado para OS/400,

SC10-9992

Describe cómo instalar, configurar y utilizar Agentes tolerantes a errores

limitados Tivoli Workload Scheduler en AS/400.

v IBM Tivoli Workload Scheduler: Guía del usuario del módulo Plus, SC10-3865

Describe cómo configurar y utilizar el módulo Plus de Tivoli Workload

Scheduler.

Consulte http://www.ibm.com/software/tivoli/products/scheduler/ para ver una

descripción del producto.

Biblioteca de IBM Tivoli Workload Scheduler for z/OS

Los documentos siguientes están disponibles en la biblioteca de Tivoli Workload

Scheduler for z/OS:

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

Explica cómo definir los datos de instalación de Tivoli Workload Scheduler for

z/OS y cómo crear y modificar planificaciones.

Publicaciones

Acerca de esta guía xiii

http://www.ibm.com/software/tivoli/products/scheduler/

v IBM Tivoli Workload Scheduler for z/OS: Installation Guide

Describe cómo instalar Tivoli Workload Scheduler for z/OS.

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

Describe cómo personalizar Tivoli Workload Scheduler for z/OS.

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

Describe cómo planear y planificar la carga de trabajo y cómo controlar y

supervisar el plan actual.

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

Proporciona una referencia de consulta rápida y fácil para utilizar Tivoli

Workload Scheduler for z/OS.

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

Proporciona información para ayudar a diagnosticar y corregir posibles

problemas al utilizar Tivoli Workload Scheduler for z/OS.

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

Describe mensajes y códigos de Tivoli Workload Scheduler for z/OS.

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

Proporciona información para escribir programas de aplicación para Tivoli

Workload Scheduler for z/OS.

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

Proporciona información de planificación sobre Tivoli Workload Scheduler for

z/OS.

v IBM Tivoli Workload Scheduler for z/OS: Memo for program 5697-WSZ, GI11-4209

Proporciona un resumen de cambios correspondientes al release actual del

producto.

v IBM Tivoli Workload Scheduler for z/OS: Program Directory for program 5697-WSZ,

GI11-4203

Se proporciona junto con la cinta de instalación para Tivoli Workload Scheduler

for z/OS (programa 5697-WSZ) y describe todos los materiales de instalación y

las instrucciones de instalación específicas del nivel de release o del número de

función del producto.

v IBM Tivoli Workload Scheduler for z/OS: Program Directory for program 5698-WSZ,

GI11-4207

Se proporciona junto con la cinta de instalación para Tivoli Workload Scheduler

for z/OS (programa 5698-WSC) y describe todos los materiales de instalación y

las instrucciones de instalación específicas del nivel de release o del número de

función del producto.

Consulte http://www.ibm.com/software/tivoli/products/scheduler-zos/ para ver

una descripción del producto.

Biblioteca de IBM Tivoli Workload Scheduler for Applications

Los manuales siguientes están disponibles en la biblioteca de IBM Tivoli Workload

Scheduler for Applications:

v IBM Tivoli Workload Scheduler for Applications: Release Notes, SC32-1279

Proporciona información de última hora sobre agentes ampliados de Tivoli

Workload Scheduler.

v IBM Tivoli Workload Scheduler for Applications: User’s Guide, SC32-1278

Describe cómo instalar, utilizar y solucionar problemas de los agentes ampliados


Publicaciones

xiv IBM Tivoli Workload Scheduler - Guía de planificación e instalación

http://www.ibm.com/software/tivoli/products/scheduler-zos/

Consulte el vínculo http://www.ibm.com/software/tivoli/products/scheduler-apps/ para ver una descripción del producto.

Biblioteca de IBM Tivoli Workload Scheduler for Virtualized Data

Centers

Los manuales siguientes están disponibles en la biblioteca de IBM Tivoli Workload

Scheduler for Virtualized Data Centers:

v IBM Tivoli Workload Scheduler for Virtualized Data Centers: Release Notes, SC32-1453

Proporciona información de última hora sobre Tivoli Workload Scheduler for

Virtualized Data Centers.

v IBM Tivoli Workload Scheduler for Virtualized Data Centers: User’s Guide, SC32-1454

Describe cómo ampliar las posibilidades de planificación de Tivoli Workload

Scheduler para la optimización de la carga de trabajo y el cálculo reticular

habilitando el control de los trabajos de IBM LoadLeveler e IBM Grid Toolbox.

Consulte el vínculo http://www.ibm.com/software/info/ecatalog/en_US/

products/Y614224T20392S50.html para ver una descripción del producto.

Publicaciones afines

Los documentos siguientes proporcionan información adicional:

v IBM Redbooks: High Availability Scenarios with IBM Tivoli Workload Scheduler and

IBM Tivoli Framework

Este Redbook de IBM muestra cómo diseñar y crear entornos altamente

disponibles de IBM Tivoli Workload Scheduler e IBM Tivoli Management

Framework (servidor TMR, nodos gestionados y puntos finales). Presenta

estudios de casos de High Availability Cluster Multiprocessing (HACMP) para

AIX y Microsoft Windows Cluster Service (MSCS).

Este Redbook se puede encontrar en el sitio Web de Redbooks en

http://www.redbooks.ibm.com/abstracts/sg246632.html

v IBM Redbooks: Customizing IBM Tivoli Workload Scheduler for z/OS V8.2 to Improve

Performance

Este Redbook de IBM describe las técnicas que se pueden utilizar para mejorar

el rendimiento de Tivoli Workload Scheduler for z/OS (incluida la planificación

global).

Este Redbook puede encontrarse en el sitio Web Redbooks en


v IBM Redbooks: End-to-End Scheduling with IBM Tivoli Workload Scheduler Version 8.2

Este Redbook de IBM estudia la mejor forma de proporcionar una planificación

global utilizando Tivoli Workload Scheduler, Versión 8.2, tanto con componentes

distribuidos (antes conocido como Maestro) como con el sistema principal (antes

conocido como OPC).

Este Redbook se puede encontrar en el sitio Web de Redbooks en


El manual Tivoli Software Glossary incluye definiciones de muchos de los términos

técnicos referentes a software de Tivoli. El manual Tivoli Software Glossary está

disponible en el siguiente sitio Web de la biblioteca de software de Tivoli:

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

Publicaciones

Acerca de esta guía xv

http://www.ibm.com/software/tivoli/products/scheduler-apps/

http://www.ibm.com/software/tivoli/products/scheduler-apps/

http://www.ibm.com/software/info/ecatalog/en_US/products/Y614224T20392S50.html

http://www.ibm.com/software/info/ecatalog/en_US/products/Y614224T20392S50.html




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

Acceso a las publicaciones en línea

El CD de producto contiene las publicaciones existentes en la biblioteca del

producto. Las publicaciones están en formato PDF, HTML o ambos. Para acceder a

las publicaciones utilizando un navegador Web, abra el archivo infocenter.html. El

archivo se encuentra en el directorio de publicaciones apropiado del CD del

producto.

IBM envía publicaciones para éste y para todos los demás productos de Tivoli, a

medida se encuentran disponibles y siempre que se actualizan, en el sitio Web de

Tivoli Software Information Center. Para acceder al Tivoli Software Information

Center, debe ir primero a la biblioteca de software de Tivoli en la dirección

siguiente:

http://www.ibm.com/software/tivoli/library/

Desplácese y haga clic en el vínculo Product manuals. En la ventana del listado

alfabético de documentos técnicos de productos de Tivoli, haga clic en el vínculo

del producto de Tivoli Workload Scheduler adecuado para acceder a las

bibliotecas del producto de Tivoli Software Information Center. Todas las

publicaciones de la biblioteca de la suite de Tivoli Workload Scheduler, la

biblioteca distribuida y la biblioteca de z/OS se pueden encontrar bajo la entrada

Tivoli Workload Scheduler.

Nota: Si imprime documentos PDF en papel que no sea de tamaño carta,

establezca la opción de la ventana Archivo → Imprimir, que permite a

Adobe Reader imprimir páginas de tamaño carta en el papel elegido

localmente.

Publicaciones en línea de Tivoli Workload Scheduler

Todas las publicaciones de la biblioteca de Tivoli Workload Scheduler para z/OS

están disponibles en soporte de software visualizable en CD-ROM en IBM Online

Library: z/OS Software Products Collection Kit, SK3T-4270. Puede leer las

publicaciones en soporte de software de los CD-ROM utilizando estos programas

bajo licencia de IBM:

v BookManager READ/2 (número de programa 5601-454)

v BookManager READ/DOS (número de programa 5601-453)

v BookManager READ/6000 (número de programa 5765-086)

Todos los programas BookManager necesitan un sistema personal equipado con

una unidad de disco CD-ROM (con capacidad para leer discos formateados con el

estándar ISO 9660) con el adaptador y cable correspondiente. Para obtener

información adicional sobre hardware y software, consulte la documentación para

el producto BookManager específico que está utilizando.

Las actualizaciones de manuales que aparecen entre un release y otro se

proporcionan en copia de software solamente.

Solicitud de publicaciones

Puede solicitar muchas de las publicaciones de Tivoli en línea desde el siguiente

sitio Web: http://www.elink.ibmlink.ibm.com/public/applications/

publications/cgibin/pbi.cgi

Puede también hacer un pedido por teléfono, llamando a uno de estos números:

v En Estados Unidos: 800-879-2755

Publicaciones

xvi IBM Tivoli Workload Scheduler - Guía de planificación e instalación

http://www.ibm.com/software/tivoli/library/

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

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

v En Canadá: 800-426-4968

En otros países, consulte el sitio Web siguiente para obtener una lista de números

de teléfono:

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

Accesibilidad

Las funciones de accesibilidad permiten que los usuarios que padecen alguna

discapacidad física, como movilidad limitada o visión reducida, utilicen los

productos de software de manera satisfactoria. Con este producto, es posible

utilizar tecnologías de asistencia para la escucha y la navegación de la interfaz.

También puede utilizarse el teclado, en lugar del ratón, para trabajar con todas las

funciones de la interfaz gráfica de usuario.

Si desea información adicional, consulte el apéndice dedicado a la accesibilidad en

el manual Tivoli Workload Scheduler Job Scheduling Console - Guía del usuario.

Información sobre el soporte

Si tiene algún problema con el software de IBM, deseará resolverlo rápidamente.

IBM proporciona las opciones siguientes para ofrecerle el soporte que necesita:

v Búsqueda en bases de conocimiento: puede realizar una búsqueda entre una

amplia colección de problemas ya conocidos y soluciones posibles, Technotes y

otra información.

v Obtención de arreglos: puede encontrar los últimos arreglos que ya están

disponibles para su producto.

v Contacto con IBM Software Support: si aún así no puede resolver el problema y

necesita tratar con alguien de IBM, puede emplear una amplia gama de

posibilidades para ponerse en contacto con IBM Software Support.

Para obtener más información sobre estas tres formas de resolver problemas,

consulte el “Información de soporte”, en la página 171.

Convenios utilizados en este manual

Esta guía utiliza varios convenios para términos y acciones especiales, así como

para comandos y rutas dependientes del sistema operativo, sintaxis de comandos y

gráficos al margen.

Convenios tipográficos

Esta guía utiliza los siguientes convenios tipográficos:

Negrita

v Comandos en minúsculas y en mayúsculas y minúsculas que, de lo

contrario, no pueden distinguirse fácilmente del texto que los rodea

v Controles de interfaz (casillas de selección, pulsadores, botones de

selección, selectores cíclicos, campos, carpetas, iconos, cuadros de lista,

elementos contenidos en cuadros de lista, listas de varias columnas,

contenedores, opciones de menú, nombres de menú, pestañas, hojas de

propiedades), etiquetas (tales como Sugerencia:, y Consideraciones

sobre el sistema operativo:)

v Palabras clave y parámetros dentro del texto

Publicaciones

Acerca de esta guía xvii

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

Cursiva

v Palabras definidas dentro del texto

v Énfasis en palabras (palabras como tales)

v Términos nuevos dentro del texto (excepto los contenidos en una lista de

definiciones)

v Variables y valores que debe proporcionar el usuario

Monoespaciado

v Ejemplos y ejemplos de códigos

v Nombres de archivo, palabras clave de programación y otros elementos

difíciles de distinguir del texto circundante

v Texto de mensajes y solicitudes de información dirigidas al usuario

v Texto que debe escribir el usuario

v Valores de argumentos u opciones de comandos

Variables y rutas dependientes del sistema operativo

Esta guía utiliza el convenio UNIX para especificar variables de entorno y para la

notación de directorios.

Cuando utilice la línea de comandos de Windows, sustituya la notación $variable

por la notación %variable% para especificar variables de entorno y sustituya cada

barra inclinada (/) por una barra inclinada invertida (\) en las rutas de directorio.

Los nombres de variables de entorno no son siempre los mismos en Windows y en

UNIX. Por ejemplo, %TEMP% en Windows equivale a $tmp en UNIX.

Nota: Si utiliza el shell bash en un sistema Windows, puede utilizar los convenios

de UNIX.

Sintaxis de los comandos

Esta guía utiliza la sintaxis siguiente para describir comandos:

Tabla 1. Sintaxis de los comandos

Convenio de

sintaxis

Descripción

Corchetes ([ ]) La información delimitada por corchetes ([ ]) es opcional. Todo lo que

no esté delimitado por corchetes se debe especificar.

Llaves ({ }) Las llaves ({ }) identifican un conjunto de opciones mutuamente

excluyentes, en las que una de ellas es obligatoria.

Subrayado ( _ ) El signo de subrayado (_) sirve para conectar palabras en una variable.

Barra vertical ( |

)

Las opciones mutuamente excluyentes están separadas por una barra

vertical ( | ). Puede especificar una de las opciones separadas por la

barra vertical, pero no puede entrar varias opciones en un mismo

comando. La barra vertical se puede utilizar para separar opciones

opcionales u obligatorias.

Negrita El texto en negrita denota información literal que se debe especificar en

la línea de comandos exactamente tal como se muestra. Esto es

aplicable a nombres de comandos y a opciones no variables.

Cursiva El texto en cursiva denota información variable y se debe sustituir por

el valor representado.

Convenios

xviii IBM Tivoli Workload Scheduler - Guía de planificación e instalación

Parte 1. Introducción

Capítulo 1. Introducción . . . . . . . . . . 3

Visión general de Tivoli Workload Scheduler . . . 3

Procesos . . . . . . . . . . . . . . . . 4

Comunicaciones de red . . . . . . . . . . . 5

Funcionamiento de la red . . . . . . . . . . 6

Agentes ampliados . . . . . . . . . . . . 6

Método de acceso de UNIX local . . . . . . 7

Método de acceso de UNIX remoto . . . . . . 7

Agentes ampliados de UNIX . . . . . . . . 7

Gestión de la producción para agentes

ampliados . . . . . . . . . . . . . 8

Instancias del producto . . . . . . . . . . . 8

Archivo de registro . . . . . . . . . . . 8

Archivo de componentes . . . . . . . . . 9

Visualización del archivo de componentes . . 9

Guía de inicio rápido . . . . . . . . . . . 10

© Copyright IBM Corp. 1991, 2004 1

2 IBM Tivoli Workload Scheduler - Guía de planificación e instalación

Capítulo 1. Introducción

La presente guía contiene instrucciones para instalar, configurar y actualizar el

producto IBM Tivoli Workload Scheduler, Versión 8.2.

Visión general de Tivoli Workload Scheduler

Tivoli Workload Scheduler consta de tres partes:

Motor de Tivoli Workload Scheduler

El motor se ejecuta en varios tipos de sistemas operativos Microsoft

Windows y UNIX. Cuando en la presente guía se hace referencia a la

instalación del motor, se está aludiendo a la instalación de un maestro, un

maestro de copia de seguridad, un agente tolerante a errores o un agente

estándar, y sus archivos binarios asociados.

Conector de Tivoli Workload Scheduler

Este componente correlaciona los comandos de Job Scheduling Console con

el motor de Tivoli Workload Scheduler. Instale el conector en el maestro y

en cualquier agente tolerante a errores (FTA) que vaya a utilizar como

máquinas de reserva para la CPU maestra. El conector necesita que Tivoli

Management Framework esté configurado para un nodo gestionado o

servidor Tivoli.

Job Scheduling Console

Es una interfaz gráfica de usuario (GUI) basada en Java para Tivoli

Workload Scheduler. Instale Job Scheduling Console en cualquier máquina

desde la que desee gestionar objetos de plan y base de datos. Job

Scheduling Console no necesita que el motor o el conector de Tivoli

Workload Scheduler estén instalados en la misma estación de trabajo.

Puede utilizar Job Scheduling Console desde cualquier máquina siempre

que tenga un vínculo TCP/IP con la máquina donde se ejecuta el conector

de Tivoli Workload Scheduler. Para obtener información más detallada

acerca de Job Scheduling Console, consulte el manual IBM Tivoli Workload

Scheduler Job Scheduling Console - Guía del usuario.

Una red de Tivoli Workload Scheduler está formada por las estaciones de trabajo

en las que se ejecutan trabajos y secuencias de trabajos.

Principalmente, las definiciones de estación de trabajo hacen referencia a estaciones

de trabajo físicas. Pero en el caso de agentes ampliados y agentes de red, las

estaciones de trabajo son definiciones lógicas que deben estar albergadas en una

estación de trabajo física de Tivoli Workload Scheduler.

Cuando instale una red de Tivoli Workload Scheduler, puede elegir entre los

siguientes tipos de estación de trabajo:

Gestor de dominio maestro (MDM)

El gestor de dominio maestro es el dominio de nivel superior de una red

de Tivoli Workload Scheduler. Contiene los archivos de base de datos

centralizados utilizados para documentar objetos de planificación. El gestor

crea el plan de Producción, lo distribuye a todos los agentes de la red al

inicio del día, y realiza todas las acciones de registro y notificación para la

red.


Maestro de copia de seguridad

Es un agente tolerante a errores capaz de asumir las tareas del gestor de

dominio maestro.

Agente tolerante a errores (FTA)

Es una estación de trabajo capaz de resolver dependencias locales e iniciar

sus trabajos en ausencia de un gestor de dominio.

Agente estándar

Es una estación de trabajo que ejecuta trabajos sólo bajo la dirección de su

gestor de dominio.

Aparte de los roles que puede seleccionar durante la instalación, los agentes

tolerantes a errores pueden asumir uno de los siguientes:

Gestor de dominio

Es el centro de gestión en un dominio. Todas las comunicaciones

intercambiadas con los agentes de un dominio se direccionan a través del

gestor de dominio.

Host

Es la función de planificación necesaria para los agentes ampliados. Puede ser

efectuada por cualquier estación de trabajo de Tivoli Workload Scheduler, con

la excepción de otro agente ampliado.

Agente ampliado

Es una definición de estación de trabajo lógica que permite al usuario ejecutar

y controlar trabajos en otros sistemas y aplicaciones.

Agente de red

Es una definición de estación de trabajo lógica para crear dependencias entre

trabajos y secuencias de trabajos en redes de Tivoli Workload Scheduler

independientes.

Procesos

Netman se inicia mediante el script StartUp. El orden de creación de los procesos

es Netman, Mailman, Batchman y Jobman. En las estaciones de trabajo de agente

estándar, Batchman no se ejecuta. Todos los procesos, excepto Jobman, se ejecutan

utilizando el usuario TWS. Jobman se ejecuta como root.

Cuando comienza la actividad de la red, Netman recibe peticiones procedentes de

procesos Mailman remotos. Tras recibir una petición, Netman crea un proceso

Writer y le pasa la conexión a él. El proceso Writer recibe el mensaje y lo pasa al

proceso Mailman local. Los procesos Writer (puede existir más de uno en un gestor

de dominio) se inician mediante peticiones de vinculación y se detienen mediante

peticiones de desvinculación (o cuando finaliza el proceso Mailman solicitante).

Los gestores de dominio, incluido el gestor de dominio maestro, se pueden

comunicar con un gran número de agentes y gestores de dominio subordinados.

Para obtener una mejor eficiencia, puede definir servidores Mailman en un gestor

de dominio para distribuir la carga de comunicaciones (consulte la sección del

manual IBM Tivoli Workload Scheduler Job Scheduling Console - Guía del usuario que

describe cómo gestionar estaciones de trabajo de la base de datos).

Visión general


Comunicaciones de red

En una red de Tivoli Workload Scheduler, los agentes se comunican con sus

gestores de dominio y éstos se comunican con sus gestores de dominio primarios.

Básicamente se efectúan dos tipos de comunicaciones:

v Inicialización al inicio del día

v Mensajes de eventos de cambio de estado de planificación durante el día de

proceso.

Antes del inicio de cada nuevo día, el gestor de dominio maestro crea un archivo

de control de producción denominado Symphony. Luego se reinicia Tivoli Workload

Scheduler en la red y el gestor de dominio maestro envía una copia del nuevo

archivo Symphony a cada uno de sus agentes y gestores de dominio subordinados a

los que está vinculado automáticamente. A su vez, los gestores de dominio envían

copias a sus agentes y gestores de dominio subordinados con los que están

vinculados automáticamente. Los agentes y gestores de dominio que no están

configurados para vincularse automáticamente se inicializan con una copia de

Symphony tan pronto como se ejecuta una operación de vinculación en Tivoli

Workload Scheduler. El indicador autolink se establece de forma predeterminada

cuando se crea una estación de trabajo en Job Scheduling Console.

Figura 1. Flujos del proceso


Capítulo 1. Introducción 5

Después de iniciar la red, se pasan mensajes de planificación, tales como inicios y

finalizaciones de trabajos, desde los agentes a sus gestores de dominio, a través de

los gestores de dominio primarios hacia el gestor de dominio maestro. A

continuación, el gestor de dominio maestro difunde los mensajes por todo el árbol

jerárquico para actualizar los gestores de dominio y todos los agentes tolerantes a

errores que se ejecutan en modalidad de Estado completo.

Funcionamiento de la red

El proceso Batchman de cada gestor de dominio y estación de trabajo de agente

tolerante a errores trabaja de forma autónoma, examinando su archivo Symphony

para resolver dependencias e iniciar trabajos. Batchman inicia trabajos a través del

proceso Jobman. En un agente estándar, el proceso Jobman responde a las

peticiones de inicio procedentes del proceso Batchman del gestor de dominio.

El gestor de dominio maestro es informado continuamente del inicio y la

finalización de los trabajos y difunde la información a los gestores de dominio y

agentes tolerantes a errores para que puedan resolver las dependencias entre

estaciones de trabajo.

El grado de sincronización entre los archivos Symphony depende del valor de las

modalidades Estado completo y Resolver dependencias de la definición de una

estación de trabajo. Si estas modalidades están activas, el archivo Symphony de un

agente tolerante a errores contiene la misma información que el del gestor de

dominio maestro (consulte el manual IBM Tivoli Workload Scheduler Job Scheduling

Console - Guía del usuario).

Agentes ampliados

Un agente ampliado actúa como interfaz para un sistema o aplicación externo

ajeno a Tivoli Workload Scheduler. Se define como estación de trabajo de Tivoli

Workload Scheduler con un método de acceso y un host. El método de acceso se

comunica con el sistema o aplicación externo e inicia una serie de trabajos tales

como supervisar. Una dependencia de archivo es un trabajo o secuencia de trabajos

que necesita verificar la existencia de uno o más archivos para poder comenzar la

Figura 2. Procesos en el funcionamiento de la red



ejecución. El host es otra estación de trabajo de Tivoli Workload Scheduler (excepto

otro agente ampliado) que resuelve dependencias y emite peticiones de trabajos

mediante el método.

Los trabajos se definen para un agente ampliado de la misma manera que para

otras estaciones de trabajo de Tivoli Workload Scheduler, con la salvedad que los

atributos de los trabajos están determinados por el sistema o aplicación externo.

Existe software de agente ampliado para varios sistemas y aplicaciones. En la

sección siguiente se describen los agentes ampliados de UNIX que se incluyen con


Método de acceso de UNIX local

El método de acceso de UNIX local se puede utilizar para definir varias estaciones

de trabajo de Tivoli Workload Scheduler en un sol sistema: la estación de trabajo

host y uno o más agentes ampliados. Cuando Tivoli Workload Scheduler envía un

trabajo a un agente ampliado de UNIX local, el host invoca el método de acceso

unixlocl para ejecutar el trabajo. El método se inicia ejecutando el script de

configuración estándar en la estación de trabajo host (TWShome/jobmanrc). Si el

usuario de inicio de sesión del trabajo tiene permiso para utilizar un script de

configuración local y el script existe como $HOME/.jobmanrc, también se ejecuta el

script de configuración local. Seguidamente se ejecuta el propio trabajo, mediante

el script de configuración estándar o local. Si no existe ninguno de los dos scripts

de configuración, el método de acceso inicia el trabajo.

El inicio de los scripts de configuración jobmanrc y .jobmanrc se puede configurar

en el script de método. El método ejecuta de forma predeterminada los scripts de

configuración, si éstos existen. Para inhabilitar esta función, debe convertir en

comentario varias líneas del script de método. Para obtener más información,

examine el archivo de script TWShome/methods/unixlocl en el host del agente

ampliado.

Método de acceso de UNIX remoto

El método de acceso de UNIX remoto permite designar un sistema ajeno a Tivoli

Workload Scheduler para que ejecute trabajos planificados de Tivoli Workload

Scheduler. Cuando Tivoli Workload Scheduler envía un trabajo a un agente

ampliado de UNIX remoto, el método de acceso unixrsh crea un directorio

/tmp/maestro en el sistema ajeno a Tivoli Workload Scheduler. Luego transfiere un

script reiniciador al directorio y lo ejecuta. Seguidamente, el script reiniciador

ejecuta el trabajo planificado. El script reiniciador se crea una sola vez, a menos

que se suprima, traslade o esté caducado.

Para ejecutar trabajos a través del agente ampliado, el usuario de inicio de sesión

del trabajo debe recibir acceso apropiado en el sistema UNIX ajeno a Tivoli

Workload Scheduler. Para ello, se debe configurar un archivo .rhost,

/etc/host.equiv o equivalente en el sistema. Si se deben verificar dependencias de

archivo Opens, también se debe permitir el acceso root. Consulte al administrador

del sistema para obtener ayuda. Para obtener más información sobre el método de

acceso, examine el archivo de script TWShome/methods/unixrsh en un host de agente

ampliado.

Agentes ampliados de UNIX

Tivoli Workload Scheduler incluye métodos de acceso para dos tipos de agentes

ampliados de UNIX. El método de acceso local de UNIX permite que un sistema



UNIX individual actúe como dos estaciones de trabajo de Tivoli Workload

Scheduler, las cuales pueden ambas ejecutar trabajos planificados de Tivoli

Workload Scheduler. El método de acceso remoto de UNIX permite al usuario

designar un sistema UNIX remoto para que ejecute trabajos planificados de Tivoli

Workload Scheduler sin tener éste instalado en el sistema.

Tivoli Workload Scheduler recibe información sobre la ejecución de un trabajo

desde un agente ampliado, a través del archivo stdlist del trabajo. Un archivo de

opciones de método puede especificar nombres alternativos de inicio de sesión

para ejecutar trabajos y verificar dependencias de archivo Opens. Para obtener

información, consulte el manual IBM Tivoli Workload Scheduler - Guía de consulta.

Gestión de la producción para agentes ampliados

En general, los trabajos que se ejecutan en agentes ampliados se comportan como

otros trabajos de Tivoli Workload Scheduler. Tivoli Workload Scheduler hace un

seguimiento del estado de un trabajo y registra los datos de salida en los archivos

stdlist del trabajo. Estos archivos se guardan en la estación de trabajo host del

agente ampliado. Para obtener más información sobre la gestión de trabajos,

consulte la sección que describe las tareas del plan de Tivoli Workload Scheduler

en el manual IBM Tivoli Workload Scheduler Job Scheduling Console - Guía del usuario.

Instancias del producto

Se pueden instalar varias copias del producto en un mismo sistema siempre que

para cada instancia se utilice un nombre y una ruta de instalación exclusivos. Las

instancias se registran en el archivo de registro para las plataformas de Nivel 1 y

en el archivo de componentes para las plataformas de Nivel 2. Las versiones

anteriores de Tivoli Workload Scheduler también se registraban en el archivo de

componentes.

Archivo de registro

En las plataformas de Nivel 1, cuando instala Tivoli Workload Scheduler utilizando

el programa de instalación ISMP o el script twsinst, se realiza una comprobación

para determinar si existen otras instancias de Tivoli Workload Scheduler ya

instaladas. El archivo TWSRegistry.dat almacena el historial de todas las instancias

instaladas, y esta es la única finalidad de este archivo. En las plataformas

Windows, este archivo se guarda en el directorio de la unidad del sistema; por

ejemplo, c:\winnt\system32. En las plataformas UNIX, este archivo se guarda en la

ruta /etc/TWS. El archivo contiene los valores de los atributos siguientes que

definen una instalación de Tivoli Workload Scheduler:

Tabla 2. Atributos contenidos en el archivo de registro

Atributo Valor

ProductID TWS_ENGINE

PackageName El nombre del paquete de software utilizado

para realizar la instalación.

InstallationPath La ruta absoluta de la instancia de Tivoli

Workload Scheduler.

UserOwner El propietario de la instalación.

MajorVersion Número de release de Tivoli Workload

Scheduler.

MinorVersion Número de versión de Tivoli Workload

Scheduler.



Tabla 2. Atributos contenidos en el archivo de registro (continuación)

Atributo Valor

MaintenanceVersion Número de la versión de mantenimiento de


PatchVersion Número del parche de producto más

reciente instalado.

Agente Puede ser cualquiera de lo siguiente: agente

estándar, agente tolerante a errores, gestor

de dominio maestro.

FeatureList La lista de funciones opcionales instaladas.

LPName El nombre del bloque de paquetes de

software utilizado para instalar el paquete

de idioma.

LPList Lista de todos los idiomas instalados para la

instancia instalada.

A continuación se muestra un ejemplo de un archivo TWSRegistry.dat situado en

un gestor de dominio maestro:

/Tivoli/Workload_Scheduler/tws_nord_DN_objectClass=OU

/Tivoli/Workload_Scheduler/tws_nord_DN_PackageName=TWS_NT_tws_nord.8.2

/Tivoli/Workload_Scheduler/tws_nord_DN_MajorVersion=8

/Tivoli/Workload_Scheduler/tws_nord_DN_MinorVersion=2

/Tivoli/Workload_Scheduler/tws_nord_DN_PatchVersion=

/Tivoli/Workload_Scheduler/tws_nord_DN_FeatureList=TBSM

/Tivoli/Workload_Scheduler/tws_nord_DN_ProductID=TWS_ENGINE

/Tivoli/Workload_Scheduler/tws_nord_DN_ou=tws_nord

/Tivoli/Workload_Scheduler/tws_nord_DN_InstallationPath=c:\TWS\tws_nord

/Tivoli/Workload_Scheduler/tws_nord_DN_UserOwner=tws_nord

/Tivoli/Workload_Scheduler/tws_nord_DN_MaintenanceVersion=

/Tivoli/Workload_Scheduler/tws_nord_DN_Agent=MDM

Archivo de componentes

Para instalar el producto en las plataformas de Nivel 2 y para las instalaciones de

Tivoli Workload Scheduler versión 7.0 y 8.1, se definen grupos de productos en el

archivo de componentes. Este archivo permite instalar varias copias de un

producto en un solo sistema mediante la designación de usuarios diferentes para

cada copia. Si el archivo no existe antes de la instalación, se crea mediante el script

customize. Por ejemplo:

<product> <version> <home directory> <product group>

Maestro 7.0 /opt/maestro production

maestro (8.2) /data/maestro8/maestro TWS_maestro8_8.2

El script customize crea y actualiza automáticamente las entradas en este archivo.

En UNIX, el nombre del archivo de componentes se define en esta variable:

UNISON_COMPONENT_FILE

Si la variable no está definida, customize utiliza este nombre de archivo:

/usr/unison/components

Visualización del archivo de componentes

Después de una instalación o actualización, puede ver el contenido del archivo de

componentes en una plataforma de Nivel 2 ejecutando el programa ucomp, de esta

manera:

Instancias


ucomp -l

Guía de inicio rápido

Para instalar Tivoli Workload Scheduler, realice la tarea siguiente:

v Capítulo 2, “Iniciación”, en la página 13 para planificar la instalación antes de

empezar

v Parte 3, “Instalación y actualización”, en la página 37 para instalar Tivoli

Workload Scheduler y los componentes del conector

v Capítulo 8, “Después de la instalación”, en la página 79 para configurar la

instalación

También puede realizar las siguientes tareas opcionales:

v Capítulo 11, “Definición de la seguridad”, en la página 153 para definir los

parámetros de seguridad de Tivoli Workload Scheduler

v Capítulo 9, “Personalización opcional”, en la página 87 para establecer opciones

locales y globales

v “Promoción de una instalación existente” en la página 48 para actualizar una

instalación existente

v “Adición de una función nueva en una instalación existente” en la página 46

para añadir una función o componente a una instalación ya existente

Instancias


Parte 2. Planificación

Capítulo 2. Iniciación . . . . . . . . . . . 13

Planificación de la red . . . . . . . . . . . 13

Visión general de la red de Tivoli Workload

Scheduler . . . . . . . . . . . . . . 13

Funcionalidad de dominio . . . . . . . . 13

Proceso localizado en el dominio . . . . . . 14

Consideraciones sobre la red . . . . . . . 14

Una red de un sólo dominio . . . . . . . . 15

Una red de dominio múltiple . . . . . . . 16

Conmutación a un gestor de dominio de reserva 17

Mecanismo de conmutación tolerante a errores 17

Bases de datos ampliadas . . . . . . . . . 19

Nombres de estación de trabajo . . . . . . . 19

Instalación del conector . . . . . . . . . 20

Instalación de conectores en agentes tolerantes

a errores . . . . . . . . . . . . . 20

Consideraciones sobre los husos horarios . . . 21

Planificación de instalaciones . . . . . . . . 21

Selección de tipos de estación de trabajo . . . . 21

Selección del método de instalación . . . . . 21

Selección del tipo de instalación . . . . . . . 24

Comprobación de los requisitos de autorización del

usuario . . . . . . . . . . . . . . . . 25

Roles de autorización para ejecutar el asistente de

instalación . . . . . . . . . . . . . . 25


twsinst . . . . . . . . . . . . . . . 26

Roles de autorización para Software Distribution 26


customize . . . . . . . . . . . . . . 27

Roles de autorización para ejecutar una

instalación . . . . . . . . . . . . . . 27

Antes de la instalación . . . . . . . . . . . 27

Información sobre el usuario de Tivoli Workload

Scheduler . . . . . . . . . . . . . . 27

Creación de una cuenta de usuario en

sistemas operativos Windows . . . . . . 28

Creación de una cuenta de usuario en

sistemas UNIX . . . . . . . . . . . 28

Criterios de validación de elementos de

instalación . . . . . . . . . . . . . . 28

Instalación para la planificación global . . . . 29

Información sobre la instalación . . . . . . 29

Los CD de instalación . . . . . . . . . 29

Archivos de registro de la instalación . . . . 31

Servicios de Windows . . . . . . . . . 32

Modificación de los derechos del servicio

Jobmon para Windows . . . . . . . . 32

Antes de la actualización . . . . . . . . . . 32

Desvinculación y detención de Tivoli Workload

Scheduler . . . . . . . . . . . . . . 32

Detención del conector . . . . . . . . . 33

Archivos de copia de seguridad . . . . . . 34

Utilización de los nuevos archivos de

configuración . . . . . . . . . . . . . 34

Ampliación de la base de datos . . . . . . . 35

Implicaciones de Tivoli Management Framework 35

Cuando ya está instalada una versión

soportada de Tivoli Management Framework . 36


Capítulo 2. Iniciación

Este capítulo describe la información necesaria para preparar la instalación.

Planificación de la red

Antes de comenzar a instalar Tivoli Workload Scheduler, debe responder a las

preguntas siguientes.

1. ¿Utilizará una estructura de red de varios dominios o de un solo dominio?

2. Si utiliza varios dominios, ¿cómo los dividirá?

v Según ubicaciones geográficas; por ejemplo, los dominios Londres y París

v Según el huso horario; por ejemplo, la hora oficial del Pacífico (PST) y la

hora oficial del Este de EE.UU. (EST)

v Según la unidad de negocio; por ejemplo, marketing y contabilidad3. ¿Activará la función del huso horario?

4. ¿Habrá cortafuegos en su entorno?

Visión general de la red de Tivoli Workload Scheduler

Una red de Workload Scheduler contiene como mínimo un dominio de Workload

Scheduler, el dominio maestro, en el que el gestor de dominio maestro es el centro

de gestión. Se pueden utilizar otros dominios para dividir una red ampliamente

distribuida y definir así grupos menores gestionados localmente.

La utilización de varios dominios disminuye el volumen de tráfico de la red al

reducir las comunicaciones entre el gestor de dominio maestro y otros sistemas.

En una configuración con un solo dominio, el gestor de dominio maestro mantiene

comunicaciones con todas las estaciones de trabajo de la red de Workload

Scheduler.

En una configuración con varios dominios, el gestor de dominio maestro se

comunica con las estaciones de trabajo de su dominio y con los gestores de

dominio subordinados. A su vez, los gestores de dominio subordinados se

comunican con las estaciones de trabajo de sus dominios y con los gestores de

dominio subordinados. La utilización de varios dominios también proporciona

tolerancia a errores, ya que limita a un sólo dominio los problemas causados por la

pérdida de un gestor de dominio. Para limitar aún más los efectos, puede designar

gestores de dominio de reserva para que entren en funcionamiento si fallan los

gestores de dominio respectivos.

Funcionalidad de dominio

Cuando define un nuevo dominio, debe identificar el dominio primario y el gestor

de dominio. El dominio primario es el dominio situado directamente encima del

nuevo dominio en la jerarquía de dominios. Todas las comunicaciones

intercambiadas con un dominio se direccionan a través del gestor de dominio

primario.


Proceso localizado en el dominio

Una cuestión esencial a la hora de seleccionar la forma de configurar los dominios

de Tivoli Workload Scheduler es el concepto de proceso localizado. El objetivo es

separar o localizar las necesidades de planificación basándose en un conjunto

común de características.

Las características comunes son cosas tales como ubicaciones geográficas, funciones

empresariales o grupos de aplicaciones. El proceso relacionado con la definición de

grupos puede limitar el volumen de información de interdependencia que es

necesario comunicar entre dominios. Las ventajas de localizar el proceso en los

dominios son las siguientes:

v Un menor tráfico de la red. El mantener el proceso localizado a los dominios

elimina la necesidad de comunicaciones frecuentes entre los dominios.

v Proporciona una forma adecuada de aumentar la seguridad y simplificar la

administración. La seguridad y la administración se pueden definir a nivel de

dominio y estar limitadas a ese nivel. En lugar de utilizar una administración a

nivel de la red o específica de la estación de trabajo, puede tener una

administración de dominios.

v Se puede optimizar la tolerancia a errores para la red y las estaciones de trabajo.

En una red de Tivoli Workload Scheduler con varios dominios, puede definir

unidades de reserva para cada gestor de dominio; de esta forma, los problemas

producidos en un dominio no perturban las operaciones realizadas en otros

dominios.

Consideraciones sobre la red

Las cuestiones que se plantean a continuación le ayudarán a tomar decisiones

respecto a cómo configurar la red de Tivoli Workload Scheduler. Algunas

cuestiones hacen referencia a aspectos de la red, mientras que otras afectan a las

aplicaciones controladas por Tivoli Workload Scheduler.

v ¿Qué tamaño tiene su red de Tivoli Workload Scheduler? ¿Cuántos sistemas

contiene? ¿Cuántas aplicaciones y trabajos ejecuta la red?

El tamaño de la red le ayudará a decidir si debe utilizar una arquitectura de un

solo dominio o de varios dominios. Si tiene un número pequeño de sistemas o

un número pequeño de aplicaciones para controlar con Tivoli Workload

Scheduler, puede no ser necesario utilizar varios dominios.

v ¿Cuántas ubicaciones geográficas abarcará su red de Tivoli Workload Scheduler?

¿Qué nivel de fiabilidad y eficiencia tiene la comunicación entre las ubicaciones?

Esta es una de las razones principales para elegir una arquitectura de varios

dominios. Una configuración habitual es aquella en la que existe un dominio

para cada ubicación geográfica. Si elige una arquitectura de un solo dominio,

dependerá más de la red para mantener un proceso continuo.

v ¿Necesita una gestión centralizada o descentralizada de Tivoli Workload

Scheduler?

Una red de Tivoli Workload Scheduler, ya sea de uno o varios dominios, le

permite gestionar Tivoli Workload Scheduler desde un solo nodo, el gestor de

dominio maestro. Si desea gestionar varias ubicaciones por separado, puede ser

conveniente instalar una red de Tivoli Workload Scheduler en cada ubicación.

Observe que es posible lograr cierto grado de gestión descentralizada en una red

de Tivoli Workload Scheduler autónoma mediante el montaje o compartimiento

de sistemas de archivos.



v ¿Tiene varias entidades físicas o lógicas en un mismo emplazamiento? ¿Existen

varios edificios y hay varios pisos en cada edificio? ¿Existen diversos

departamentos o funciones empresariales? ¿Existen aplicaciones diferentes?

Estas pueden ser razones para elegir una configuración con varios dominios. Por

ejemplo, podría existir un dominio para cada edificio, departamento, función

empresarial o aplicación (fabricación, finanzas, ingeniería, etc.)

v ¿Ejecuta aplicaciones que funcionarán con Tivoli Workload Scheduler?

Si esas aplicaciones son distintas e independientes de otras aplicaciones, puede

elegir colocarlas en un dominio de Tivoli Workload Scheduler independiente.

v ¿Desea que los dominios de Tivoli Workload Scheduler sean un reflejo de los

dominios de Windows?

Esto no es un requisito necesario, pero puede ser útil.

v ¿Desea aislar o diferenciar un conjunto de sistemas basándose en el rendimiento

u otros criterios?

Esto puede proporcionar otra razón para definir varios dominios de Tivoli

Workload Scheduler y localizar sistemas basándose en el rendimiento o tipo de

plataforma.

v ¿Qué volumen de tráfico de red tiene ahora?

Si el tráfico de la red es gestionable, la necesidad de tener varios dominios es

menos importante.

v ¿Existen dependencias entre trabajos que afectan a varios sistemas, ubicaciones

geográficas o aplicaciones? Por ejemplo, ¿existe una dependencia entre el inicio

del Trabajo1 de la estación de trabajo1 y la conclusión del Trabajo2 que se

ejecuta en la estación de trabajo2?

El grado de interdependencia entre los trabajos es un factor importante al

configurar la red de Tivoli Workload Scheduler. Si utiliza varios dominios,

debería intentar mantener en un mismo dominio a los objetos interdependientes.

De esta manera, el tráfico de la red será menor y sacará más provecho de la

arquitectura basada en dominios.

v ¿Qué nivel de tolerancia a errores necesita?

Una desventaja evidente de la configuración con un solo dominio es la

dependencia respecto de un solo gestor de dominio. En una red con varios

dominios, la pérdida de un gestor de dominio individual afecta solamente a los

agentes situados en el dominio del gestor.

Una red de un sólo dominio

Una red de Tivoli Workload Scheduler de un solo dominio consta de un gestor de

dominio maestro y varios agentes. La Figura 3 en la página 16 muestra un ejemplo

de red de un solo dominio. Una red de un solo dominio es apropiada para

empresas que tienen pocas ubicaciones y funciones empresariales. Toda la

comunicación de la red se direcciona a través del gestor de dominio maestro.

Cuando existe una sola ubicación, sólo necesita interesarse por la fiabilidad de la

red local y el volumen de tráfico que puede manejar.


Capítulo 2. Iniciación 15

Las redes de un sólo dominio se pueden combinar con otras redes, de uno o varios

dominios, para atender las necesidades de varios emplazamientos. Tivoli Workload

Scheduler da soporte a dependencias inter-red para trabajos que se ejecutan en

redes de Tivoli Workload Scheduler diferentes.

El primer ejemplo muestra una red con un solo dominio. El gestor de dominio

maestro está situado en Atlanta, junto con varios agentes. Existen también dos

agentes situados en Denver. Los agentes de Denver dependen del gestor de

dominio maestro de Atlanta para resolver todas las dependencias entre agentes,

aunque las dependencias pueden estar en trabajos que se ejecutan en Denver. Una

alternativa sería crear redes de Tivoli Workload Scheduler de un solo dominio

independientes en Atlanta y Denver, tal como muestra el segundo ejemplo.

Una red de dominio múltiple

Las redes de dominio múltiple son especialmente apropiadas para las empresas

que abarcan varios emplazamientos, departamentos o funciones empresariales. Una

red de Tivoli Workload Scheduler de dominio múltiple consta de un gestor de

dominio maestro, varios gestores de dominio de nivel inferior y varios agentes en

cada dominio. Los agentes se comunican sólo con sus gestores de dominio, y éstos

se comunican con sus gestores de dominio primarios.

Figura 3. Topología de un sólo dominio

Atlanta

MDM

AA AA

Denver

O bien:

MDM

AA

MDM

AA

Atlanta

Denver

Denver

Figura 4. Dependencias inter-red



Tal y como ilustra la Figura 5, el gestor de dominio maestro está situado en

Atlanta; contiene los archivos de base de datos utilizados para documentar los

objetos de planificación, y distribuye el archivo Symphony a sus agentes y a los

gestores de dominio de Denver y Los Angeles. Seguidamente, los gestores de

dominio de Denver y Los Angeles distribuyen el archivo Symphony a sus agentes

y a los gestores de dominio subordinados de Boulder, Aurora y Burbank. El gestor

de dominio maestro de Atlanta se encarga de difundir información entre dominios

por toda la red.

Todas las comunicaciones intercambiadas con el gestor de dominio de Boulder se

direccionan a través de su gestor de dominio primario situado en Denver. Si

existen planificaciones o trabajos en el dominio de Boulder que dependen de

planificaciones o trabajos situado en el dominio de Aurora, esas dependencias son

resueltas por el gestor de dominio de Denver. La mayoría de las dependencias

entre agentes son gestionadas localmente por gestores de dominio de nivel inferior,

lo cual reduce notablemente el tráfico en la red WAN (Wide Area Network, red de

área amplia).

Conmutación a un gestor de dominio de reserva

Cada dominio tiene un gestor de dominio y, opcionalmente, uno o más gestores de

dominio de reserva. El gestor de dominio de reserva debe estar en el mismo

dominio que el gestor de dominio para el cual actúa como sustituto. Los gestores

de dominio de reserva deben ser agentes tolerantes a errores que ejecutan la

misma versión de producto del gestor de dominio para el que actúan de sustituto,

y deben tener habilitadas las opciones de Resolver dependencias y Estado

completo en sus definiciones de estación de trabajo.

Si un gestor de dominio falla durante la jornada de producción, el usuario puede

utilizar Job Scheduling Console o el comando switchmgr en la línea de comandos

conman, para conmutar a un gestor de dominio de reserva. Una acción de

conmutar gestor puede ejecutarla cualquiera que tenga acceso para iniciar y

detener las estaciones de trabajo del gestor de dominio y del gestor de dominio de

reserva.

La operación de conmutar gestor detiene el gestor de reserva y lo reinicia como

nuevo gestor de dominio, y convierte el gestor de dominio antiguo en un agente

tolerante a errores. Las identidades de los gestores de dominio actuales se pasan en

el archivo Symphony desde un día de proceso al siguiente, por lo que cualquier

conmutación sigue vigente hasta que se devuelve el control al gestor de dominio

original.

Mecanismo de conmutación tolerante a errores

El mecanismo de tolerancia a errores predeterminado se basa en conexiones de

entrada múltiples y conmuta roles entre el gestor de dominio y el gestor de

dominio de reserva. Dentro de un dominio, los eventos ya no se redireccionan

Nivel 1

Nivel 2

Nivel 3

A

A A A

DM

DM

A

DM

DM

AAA

MDMAtlanta

Denver Los Angeles

DMBoulder Aurora Burbank

A

Figura 5. Topología de dominio múltiple



desde el gestor de dominio primario, sino que llegan directamente desde los

agentes tolerantes a errores de origen. Cuando un agente tolerante a errores envía

un evento a un gestor de dominio primario, también envía el mismo evento a

todos los agentes tolerantes a errores de estado completo de dicho dominio. Si no

puede entregar el evento a ninguno de ellos, entonces dicho evento se coloca en el

almacenamiento intermedio del archivo pobox correspondiente del agente tolerante

a errores. Limite la cantidad de FTA con estado completo, ya que provoca

congestión de tráfico de red.

La Figura 6 muestra la arquitectura de conexiones de entrada múltiples.

La flecha continua representa las conexiones que se crean con un Tivoli Workload

Scheduler sin arquitectura de conexiones de entrada múltiples. Las fechas

discontinuas representan las conexiones de entrada adicionales que se crean para el

agente tolerante a errores de estado completo en un dominio con arquitectura de

conexiones de entrada múltiples.

Si el conmutador tolerante a errores está activo, los comandos link y unlink

emitidos desde el gestor de dominio principal actúan sobre las conexiones

primarias y secundarias.

Cuando un agente tolerante a errores de estado completo recibe un evento, lo

procesa y ya no lo redirecciona más allá, sino que lo coloca en el almacenamiento

intermedio localmente en una cola cíclica denominada ftbox. ftbox actúa como

cola de recuperación.

Figura 6. Arquitectura de conexiones de entrada múltiples



La arquitectura de conexiones de entrada múltiple garantiza que todos los eventos

recibidos y procesados por el gestor de dominio primario también serán recibidos

y procesados por el agente tolerante a errores de estado completo (o que serán

recibidos o procesados posteriormente si los eventos aún están en algún agente

pobox tolerante a errores). Si falla el gestor de dominio primario, un usuario puede

utilizar el comando de conmutación de gestor para conmutar las funciones del

gestor de dominio del gestor de dominio primario a un agente tolerante a errores

de estado completo seleccionado.

Cuando se recibe el comando de conmutación de gestor, todos los agentes

tolerantes a errores de dicho dominio se desconectan del gestor de dominio

primario y se conectan al agente tolerante a errores de estado completo. Durante la

fase de establecimiento del vínculo, el gestor nuevo se resincroniza con cada

estación de trabajo de conexión reenviando y regenerando el parcial de los eventos

colocados en el almacenamiento intermedia de los ftboxes. Así se garantiza que no

va a perderse ni duplicarse ningún evento que exista todavía en los cuadros de

mensajes del gestor de dominio primario.

Los agente tolerantes a errores de estado completo siempre se actualizan con la

última información de estado y todos los eventos procesos parcialmente o no

procesados se almacenan en, como mínimo, dos sistemas (el agente tolerante a

errores original si éste no ha podido entregarlo y el gestor de dominio o el agente

tolerante a errores de estado completo). A continuación, los eventos están

preparados para ser reenviados y para volver a procesarse, eliminando así el único

punto de error de la comunicación del gestor de dominio primario con el gestor de

dominio reserva.

Nota: Esta aproximación se aplica tanto al tráfico descendente como al ascendente.

El calificativo ″entrante″ o ″de entrada″ no depende de la dirección del

tráfico, sino que se centra en el dominio y se repite de la misma manera

para cada dominio donde reside como mínimo un agente tolerante a errores

de estado completo.

Bases de datos ampliadas

En Tivoli Workload Scheduler, Versión 8.2, se crean bases de datos ampliadas en el

gestor de dominio maestro la primera vez que se ejecuta el motor de Tivoli

Workload Scheduler.

Si está actualizando de la versión 7.0 o 8.1 a la versión 8.2, asegúrese de que

amplía sus bases de datos antes de utilizarlas con Tivoli Workload Scheduler

versión 8.2. Consulte el apartado “Ampliación de la base de datos” en la página 35

para obtener más información.

Nombres de estación de trabajo

La planificación de trabajos en una red de Tivoli Workload Scheduler se distribuye

entre varios sistemas. Para hacer un seguimiento exacto de trabajos, planificaciones

y otros objetos, se asigna un nombre de estación de trabajo exclusivo a cada

máquina. Los nombres pueden ser los mismos que los nombres de los nodos de

red, siempre que se ajusten a las reglas de denominación de Tivoli Workload

Scheduler. La longitud máxima permitida para el nombre de una estación de

trabajo es de 16 caracteres alfanuméricos; se pueden utilizar el guión (-) y el signo

de subrayado (_) y el nombre debe comenzar con una letra.



Instalación del conector

El conector es un servicio de Tivoli Management Framework que permite que los

clientes de Job Scheduling Console se comuniquen con el motor de Tivoli

Workload Scheduler. Para instalar el conector, debe tener instalado Tivoli

Management Framework, Versión 3.7.1 o posterior. Un conector se puede instalar

en un sistema que también debe ser un servidor Tivoli o un nodo gestionado.

Si desea instalar el conector en el dominio de Tivoli Workload Scheduler, pero no

existe ninguna región y no desea implementar un entorno de gestión Tivoli

completo, entonces debe instalar Tivoli Management Framework como región

única (y por tanto instalarlo como servidor Tivoli) en cada nodo donde se ejecutará

el conector.

Puede instalar conectores en estaciones de trabajos que no sean el gestor de

dominio maestro. Esto le permite ver la versión del archivo Symphony de la

estación de trabajo en cuestión. Esto puede ser importante para utilizar Job

Scheduling Console para gestionar la base de datos de parámetros locales o para

emitir el comando submit directamente hacia la estación de trabajo, en lugar de

emitirlo a través del maestro. La estación de trabajo en la que instale el conector

debe ser un nodo gestionado o un servidor Tivoli de la región de gestión Tivoli. En

cambio, para gestionar objetos de planificación de la base de datos de Tivoli

Workload Scheduler, debe instalar el conector en el gestor de dominio maestro que

esté configurado como servidor Tivoli o nodo gestionado.

Consulte el Capítulo 3, “Instalación mediante el asistente de instalación”, en la

página 39 para obtener información sobre la instalación del conector como función

adicional.

Instalación de conectores en agentes tolerantes a errores

La instalación de conectores distribuidos en agentes tolerantes a errores depende

del tipo de usuarios.

Usuarios que no utilizan el entorno Tivoli:

v Cuando cree un agente tolerante a errores, asegúrese de instalar el motor de

Tivoli Workload Scheduler antes de instalar el conector.

v Siga las instrucciones de instalación descritas en el capítulo del manual Tivoli

Workload Scheduler Job Scheduling Console - Guía del usuario donde se explica cómo

instalar el conector o siga el procedimiento descrito en el Capítulo 3, “Instalación

mediante el asistente de instalación”, en la página 39.

Usuarios que utilizan el entorno Tivoli:

v Normalmente el gestor de dominio maestro reside en un nodo gestionado. En

primer lugar debe instalar las clases de Job Scheduling Services/conector en el

servidor de Tivoli.

v Procure no crear una instancia en un nodo gestionado que no tenga instalado el

motor de Tivoli Workload Scheduler.

Todos los usuarios:

v Tenga en cuenta que durante el proceso de instalación del conector se solicitará

un nombre de instancia de Tivoli Workload Scheduler. Este nombre se mostrará

en el árbol de Planificación de trabajos de Job Scheduling Console. Para evitar

confusiones, es conveniente que utilice un nombre que incluya el nombre del

agente tolerante a errores.



v Si instala el conector en varios agentes tolerantes a errores de una red, tenga en

cuenta que los nombres de instancia deben ser exclusivos dentro de la red de

Tivoli Workload Scheduler y en la región de gestión Tivoli.

Consideraciones sobre los husos horarios

El soporte de huso horario es una función opcional que está inhabilitada de forma

predeterminada. Si se habilita, el soporte de huso horario permite la gestión de

cargas de trabajo a un nivel global.

Cuando se habilitan los husos horarios, éstos eliminan el tiempo muerto en la red

global. El tiempo muerto es el período de tiempo entre el inicio del día de Tivoli

Workload Scheduler en el dominio maestro y la hora de un agente tolerante a

errores en otra zona de huso horario. Por ejemplo, si un maestro en una zona de

huso horario del este empieza el día a las 6 a.m. e inicializa el agente tolerante a

errores en una zona de huso horario del oeste con tres horas de diferencia horaria,

la zona muerta para el agente tolerante a errores es entre las 3 a.m. y las 6 a.m.

Para obtener una descripción sobre cómo funcionan los husos horarios, consulte el

manual IBM Tivoli Workload Scheduler - Guía de consulta.

Planificación de instalaciones

Esta sección describe los puntos que necesita tener en cuenta antes de iniciar la

instalación de Tivoli Workload Scheduler.

Selección de tipos de estación de trabajo

Antes de iniciar la instalación, primero necesita decidir el tipo de estación de

trabajo que va a instalar. Debería leer el capítulo “Visión general de Tivoli

Workload Scheduler” en la página 3 para obtener una descripción de los diferentes

tipos de estación de trabajo.

La Tabla 3 resume el tipo de estación de trabajo en la que hay que instalar los

componentes:

Tabla 3. Selección de la instalación de la estación de trabajo

Tipo de estación de trabajo Conector

Gestor de dominio maestro Sí

Agente tolerante a errores Opcional

Agente estándar No

Nota: También instale el conector en su gestor de dominio de reserva.

Selección del método de instalación

Existen varios métodos para instalar Tivoli Workload Scheduler.

Asistente de InstallShield Multi-Platform (ISMP)

Cuando se instala Tivoli Workload Scheduler en una única estación de

trabajo, puede utilizar el asistente de instalación en modalidad interactiva

o desatendida. En la modalidad interactiva, el asistente le va guiando a

través de los pasos de instalación. En la modalidad desatendida, un

archivo de respuestas proporciona la información relevante para el proceso

de instalación, que se ejecuta como proceso de fondo y sin que el usuario

tenga que intervenir. Este método de instalación utiliza una Máquina



Virtual Java, y por tanto exige determinados requisitos del sistema.

Consulte el manual Tivoli Workload Scheduler Release Notes para obtener más

información. Consulte el Capítulo 3, “Instalación mediante el asistente de

instalación”, en la página 39.

Script twsinst para plataformas de Nivel 1

La ejecución de este script instala Tivoli Workload Scheduler en

plataformas UNIX de Nivel 1. Este método no hace uso de una Máquina

Virtual Java y se puede utilizar en lugar del asistente de ISMP. Consulte el

Capítulo 4, “Instalación y promoción mediante twsinst”, en la página 51.

Bloques de paquetes de software (SPB) de Software Distribution

El motor de Tivoli Workload Scheduler se puede instalar utilizando el

componente Software Distribution de IBM Tivoli Configuration Manager,

Versiones 4.2 o 4.2.1, mediante la distribución de bloques de paquetes de

software. Consulte el Capítulo 5, “Instalación mediante Software

Distribution”, en la página 55.

Script de shell customize para plataformas de Nivel 2

Este script instala Tivoli Workload Scheduler en plataformas de Nivel 2. Es

necesario realizar algunos pasos de configuración antes y después de

ejecutar este script. Consulte el Capítulo 6, “Instalación mediante

customize”, en la página 61.

Las secciones siguientes describen las razones que le llevarán a elegir el método

más indicado para cada ocasión.

La Tabla 4 en la página 23 lista los métodos de instalación disponibles y los

componentes y funciones que cada método instala en función de si se está

instalando una plataforma de Nivel 1 o 2.



Tabla 4. Métodos de instalación, componentes y funciones

Nivel de

plataforma

Método de

instalación

Agente de Tivoli

Workload

Scheduler

Funciones

opcionales que se

pueden instalar Consulte

Nivel 1 ISMP Agente tolerante

a errores

Gestor de

dominio maestro

Gestor de

dominio de

reserva

Connector +

Tivoli

Management

Framework

Tivoli Plus

Module + Tivoli

Management

Framework

Paquetes de

idioma

Capítulo 3,

“Instalación

mediante el

asistente de

instalación”, en la

página 39

Agente estándar Paquetes de

idioma

Instalación

desatendida

Agente tolerante

a errores

Gestor de

dominio maestro

Gestor de

dominio de

reserva

Connector +

Tivoli

Management

Framework

Tivoli Plus

Module + Tivoli

Management

Framework

Paquetes de

idioma

“Realización de

una instalación

desatendida” en la

página 49

Agente estándar Paquetes de

idioma

Script twsinst

(sólo

plataformas

UNIX)

Agente tolerante

a errores

Gestor de

dominio maestro

Gestor de

dominio de

reserva

Agente estándar

Instala

automáticamente

los paquetes de

idioma; no es

opcional.

Software

Distribution

Agente tolerante

a errores

Gestor de

dominio maestro

Gestor de

dominio de

reserva

Agente estándar

Ninguno “Paquetes de

software y

parámetros” en la

página 55

Ninguno Paquetes de

idioma

“Instalación de

paquetes de

idioma” en la

página 58



Tabla 4. Métodos de instalación, componentes y funciones (continuación)

Nivel de

plataforma

Método de

instalación

Agente de Tivoli

Workload

Scheduler

Funciones

opcionales que se

pueden instalar Consulte

Tivoli

Management

Framework

Conector

Tivoli Plus

Module

Tivoli Workload

Scheduler Job

Scheduling Console

- Guía del usuario

Tivoli Workload

Scheduler - Guía

del usuario del

módulo Plus

Nivel 2 customize Agente Capítulo 6,

“Instalación

mediante

customize”, en la

página 61

Nota: Consulte el manual Tivoli Workload Scheduler Release Notes para obtener una

lista de las plataformas de Nivel 1 y Nivel 2 soportadas.

Selección del tipo de instalación

La Tabla 5 proporciona la información necesaria para decidir qué tipo de nivel

desea instalar.

Tabla 5. Opciones de instalación de Tivoli Workload Scheduler

Opción de instalación Tipo de agente Funciones Descripción

Típica Agente tolerante a

errores

Paquete de idioma del

entorno local del

sistema operativo

Instala automáticamente un agente

tolerante a errores y sus archivos binarios

asociados, así como el entorno local de

idioma del sistema operativo.

Completa Gestor de dominio

maestro

Conector

Todos los paquetes de

idioma y los paquetes

de idioma de Tivoli

Management

Framework

Instala un gestor de dominio maestro y

sus archivos binarios asociados, el

conector y Tivoli Management Framework

(si no está instalado) y todos los paquetes

de idioma soportados.



Tabla 5. Opciones de instalación de Tivoli Workload Scheduler (continuación)

Opción de instalación Tipo de agente Funciones Descripción

Personalizada Agente estándar Paquetes de idioma

adicionales

seleccionados y

paquetes de idioma de

Tivoli Management

Framework de los

mismos idiomas

seleccionados

Instala un agente estándar y sus archivos

binarios asociados, y opcionalmente,

paquetes de idioma adicionales.

Agente tolerante a

errores

Maestro de copia de

seguridad

Gestor de dominio

maestro

Conector

Tivoli Plus Module

Paquetes de idioma

Instala todos los archivos binarios

relacionados con el tipo de agente

seleccionado, y opcionalmente, el conector,

Tivoli Plus Module y paquetes de idioma

adicionales. Tivoli Management

Framework, versión 3.7.1 o 4.1, es un

requisito previo para el conector y Tivoli

Plus Module. Consulte el apartado

“Implicaciones de Tivoli Management

Framework” en la página 35 para obtener

más información.

Antes de ejecutar el programa de instalación, determine el tipo de instalación que

desea realizar:

v “Secuencia de la instalación típica” en la página 40

v “Secuencia de la instalación completa” en la página 41

v “Secuencia de la instalación personalizada” en la página 43

Comprobación de los requisitos de autorización del usuario

En función del método de instalación que elija, necesitará comprobar los roles de

autorización antes de empezar el procedimiento de instalación.

Roles de autorización para ejecutar el asistente de instalación

La Tabla 6 proporciona los roles de autorización necesarios para utilizar el método

ISMP de instalación.

Tabla 6. Roles de autorización necesarios para ejecutar el asistente de instalación

Actividad Contexto Rol necesario

Instalación personalizada

o típica utilizando el

asistente de ISMP

Máquina v Windows: la cuenta de inicio de

sesión debe ser miembro del

grupo Administradores de

Windows.

v UNIX: acceso de usuario root



Tabla 6. Roles de autorización necesarios para ejecutar el asistente de

instalación (continuación)


Instalaciones con el

asistente de ISMP en las

que interviene Tivoli

Management Framework

v Instalación

personalizada para

instalar el conector o

Tivoli Plus Module*

v Añadir una función a

una instalación

existente que incluye el

conector o Tivoli Plus

Module*

Máquina v Windows: la cuenta de inicio de

sesión debe ser el Administrador

local.

v UNIX: acceso de usuario root

Región de gestión Tivoli super, admin o install_product

* Si ya está instalada una versión soportada de Tivoli Management Framework, debe

instalar el producto de una de las maneras siguientes:

v Inicie la sesión utilizando el nombre de usuario con el que se ha instalado Tivoli

Management Framework.

v Si ha iniciado la sesión con un nombre de usuario distinto del utilizado para instalar

Tivoli Management Framework, cambie los nombres de inicio de sesión de Tivoli

Administrator por este nombre de inicio de sesión de usuario.

v Cree un nuevo Administrador de Tivoli y cambie los nombres de inicio de sesión por el

nombre de usuario que realizará la instalación.

Roles de autorización para ejecutar el script twsinst


de instalación twsinst.

Tabla 7. Roles de autorización necesarios para ejecutar twsinst


Ejecutar el script twsinst Máquina Acceso root

Roles de autorización para Software Distribution


de instalación de Software Distribution.

Tabla 8. Roles de autorización necesarios para Software Distribution


Utilización de Software

Distribution para instalar un

bloque de paquetes de

software

TMR admin, senior, o super

Máquina v Windows: la cuenta de

inicio de sesión debe ser

miembro del grupo

Administradores de

Windows.

v UNIX: acceso de usuario

root



Roles de autorización para ejecutar el script customize


de instalación customize.

Tabla 9. Roles de autorización necesarios para ejecutar customize


Ejecutar el script customize Máquina Acceso root

Roles de autorización para ejecutar una instalación

La Tabla 10 proporciona el contexto y los roles de autorización necesarios para

ejecutar una actualización.

Tabla 10. Roles de autorización necesarios para ejecutar una actualización


v Actualizar utilizando el

programa de instalación

v Actualizar utilizando la

instalación desatendida

Máquina v Windows: la cuenta de

inicio de sesión debe ser

miembro del grupo

Administradores de

Windows. Si en el proceso

de actualización interviene

Tivoli Management

Framework, inicie la

sesión como

Administrador local.

v UNIX: acceso root

TMR super, admin o

install_product

Actualizar utilizando el

script twsinst

Máquina Acceso root

Actualizar utilizando

Software Distribution

TMR admin, senior, o super

Actualizar utilizando el

script customize

Máquina Acceso root

Antes de la instalación

Esta sección describe tareas de configuración opcionales e información sobre los

cambios que se efectúan en el sistema al instalar el producto. Se tratan los temas

siguientes:

v “Información sobre el usuario de Tivoli Workload Scheduler”

v “Instalación para la planificación global” en la página 29

v “Información sobre la instalación” en la página 29

Información sobre el usuario de Tivoli Workload Scheduler

Las instalaciones nuevas de Tivoli Workload Scheduler necesitan una cuenta de

usuario que tenga permisos específicos para instalar el software. Para las

plataformas Windows, los métodos de instalación descritos en esta guía crean este

usuario automáticamente o bien puede utilizar un usuario existente siempre que el

usuario tenga los derechos necesarios. En las plataformas UNIX, cualquiera que sea

el método de instalación elegido, el usuario de Tivoli Workload Scheduler se debe



crear manualmente antes de ejecutar la instalación. Las secciones siguientes

describen la creación manual de la cuenta de usuario, tanto en los sistemas

operativos Windows como UNIX.

Creación de una cuenta de usuario en sistemas operativos

Windows

En los sistemas operativos Windows, la instalación crea automáticamente el

usuario de Tivoli Workload Scheduler con los derechos apropiados, si el usuario no

existe todavía. Sin embargo, si tiene problemas con la creación del usuario, puede

seguir los pasos siguientes.

1. Cree una cuenta de usuario local denominada TWS en la máquina donde

instalará Tivoli Workload Scheduler.

Nota: Puede también utilizar una cuenta de usuario existente. Pero debe

asegurarse de que este usuario sea un miembro del grupo

Administradores de Windows.

2. Otorgue a TWSuser los siguientes derechos de usuario avanzados:

Actuar como parte del sistema operativo

Aumentar cuotas

Iniciar sesión como trabajo de lotes

Iniciar sesión como servicio

Iniciar sesión localmente

Sustituir una señal de nivel de proceso

Creación de una cuenta de usuario en sistemas UNIX

Las instalaciones en sistemas UNIX necesitan que ya exista una cuenta de usuario

válida en la estación de trabajo. Tivoli Workload Scheduler se instala en el

directorio inicial de este usuario. Utilice los comandos apropiados del sistema

operativo para crear este usuario.

Criterios de validación de elementos de instalación

La Tabla 11 lista los criterios que hay que seguir al hacer la instalación. Cuando se

hace la instalación utilizando el asistente de instalación, el sistema comprueba la

mayoría de estos criterios. Sin embargo, si se hace la instalación con otro método,

no se comprueban y la instalación puede fallar si son incorrectos. Lea estos

criterios antes de iniciar la instalación.

Tabla 11. Criterios de validación de elementos de instalación

Elemento

Espa-

cios

Longitud

máxima Caracteres válidos Valores predeterminados

Ruta de

instalación

NO – C:\win32app\TWS\$(tws_user)

Directorio inicial del usuario de

UNIX

Nombre de CPU NO 16 abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ0123456789_-

El primer carácter tiene que ser

alfabético

NOMBRE DE HOST

Nombre de CPU

maestra

NO 16 abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ0123456789_-


alfabético

MAESTRA



Tabla 11. Criterios de validación de elementos de instalación (continuación)

Elemento

Espa-

cios

Longitud

máxima Caracteres válidos Valores predeterminados

Número de

puerto TCP

NO 5 0 – 65535

Nombre de

usuario de TWS

NO 16 abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ0123456789_-


alfabético

Contraseña de

usuario de TWS

NO –

Dominio de

usuario de TWS

NO 16

Tipo de agente

de TWS

NO –

Nombre de

empresa

NO 40

Instalación para la planificación global

Si está instalando Tivoli Workload Scheduler en una estación de trabajo que se

utilizará como agente distribuido para la planificación global (un gestor de

dominio, un agente tolerante a errores o un agente estándar), debe especificar

OPCMASTER como nombre del gestor de dominio maestro durante el proceso de

instalación.

Información sobre la instalación

La instalación instala archivos de Tivoli Workload Scheduler para TWSuser en

TWShome, donde:

TWSuser

Es el usuario para el que se instala Tivoli Workload Scheduler. En los

sistemas Windows, si especifica un nombre de usuario que ya está definido

en la estación de trabajo, la instalación otorga automáticamente al usuario

los derechos necesarios para realizar la instalación. Para las estaciones de

trabajo UNIX solamente y antes de ejecutar la instalación, debe crear la

cuenta de inicio de sesión de usuario para la que está instalando el

producto, si la cuenta no existe todavía.

TWShome

Es la ubicación de instalación. En los sistemas Windows, la ubicación de

instalación predeterminada está definida como

unidad_sistema\win32app\TWS\TWSuser, pero puede especificar una

ubicación diferente. En los sistemas UNIX, el producto se instala en el

directorio inicial del usuario.

Los CD de instalación

Son necesarios los siguientes discos CD para iniciar el proceso de instalación:

Tivoli Workload Scheduler - Disco 1: El disco 1 incluye imágenes para AIX,

SOLARIS, HP-UX y Windows. Las imágenes se estructuran de la manera siguiente:



El disco 2 incluye imágenes para Linux y las plataformas de Nivel 2. Las imágenes

se estructuran de la manera siguiente:



Para las plataformas Windows, el archivo SETUP.exe está situado en la carpeta

Windows del Disco 1 de instalación de IBM Tivoli Workload Scheduler.

Cuando se copia la imagen de una determinada plataforma en otra estación de

trabajo para la instalación utilizando el asistente, además de dicha imagen

determinada también debe copiar los archivos siguientes:

v media.inf

v SETUP.jar

v Tivoli_TWS_LP.SPB

v TWS_size.txt

Archivos de registro de la instalación

Se escriben detalles sobre el proceso de instalación en diversos archivos de registro

situados en el directorio temporal definido en la máquina local, o en el

directorio_temporal especificado al instalar el producto mediante el comando

./SETUP.bin [-is:tempdir directorio_temporal. Puede examinar los archivos de

registro siguientes para obtener información sobre la instalación.

TWSIsmp.log

Es el archivo en el que graba el programa de asistente de instalación.

TWSInstall.log

Es el archivo en el que graban los programas ejecutables definidos en los

bloques de paquetes de software.



TWS_$(sistema_operativo)_$(usuario_TWS)^8.2.log

Es el archivo en el que graba Software Distribution.

twsinst_<ID>.log

Es el archivo en el que graba twsinst. <ID> indica el tipo de proceso de

instalación utilizado.

Para obtener más información acerca de los archivos de registro, consulte el

manual Tivoli Workload Scheduler Administration and Troubleshooting

Servicios de Windows

La instalación realizada en sistemas operativos Windows registra los servicios

siguientes en el Administrador de control de servicios de Windows:

v Tivoli Workload Scheduler (para TWSuser)

v Tivoli Netman (para TWSuser)

v Tivoli Token Service (para TWSuser)

v Autotrace Runtime

El Administrador de control de servicios mantiene su propia base de datos de

contraseñas de usuario. Por tanto, si la contraseña de TWSuser se cambia después

de la instalación, debe utilizar el applet Servicios del Panel de control para asignar

la nueva contraseña para Tivoli Token Service y Tivoli Workload Scheduler (para

TWSuser).

Modificación de los derechos del servicio Jobmon para Windows

En los sistemas Windows, el servicio Jobmon de Tivoli Workload Scheduler se

ejecuta en la cuenta SYSTEM con el derecho otorgado Permitir a los servicios que

interactúen con el escritorio. El usuario puede eliminar ese derecho por razones

de seguridad. Sin embargo, esto impedirá que el servicio inicie trabajos interactivos

que se ejecutan en una ventana en el escritorio del usuario. Estos trabajos no son

accesibles y no tienen acceso a recursos del escritorio. Como consecuencia, los

trabajos se pueden ejecutar sin fin o terminar de forma anómala debido a una falta

de recursos.

Antes de la actualización

Están soportadas las actualizaciones de Tivoli Workload Scheduler versión 7.0 y 8.1

a la versión 8.2. Antes de actualizar la instalación, lea los temas de esta sección.

Los temas tratados son los siguientes:

v “Desvinculación y detención de Tivoli Workload Scheduler”

v “Detención del conector” en la página 33

v “Archivos de copia de seguridad” en la página 34

v “Utilización de los nuevos archivos de configuración” en la página 34

v “Ampliación de la base de datos” en la página 35

v “Implicaciones de Tivoli Management Framework” en la página 35

Desvinculación y detención de Tivoli Workload Scheduler

Antes de realizar una operación de actualización, promoción o desinstalación,

asegúrese de que todos los procesos y servicios de Tivoli Workload Scheduler estén

detenidos. Si hay trabajos que están en ejecución actualmente, los procesos

asociados se deben detener manualmente. Siga estos pasos:



1. Desde Job Scheduling Console, detenga la estación de trabajo de destino. De lo

contrario, utilice el comando siguiente desde la línea de comandos del gestor

de dominio maestro mientras tenga la sesión iniciada como TWSuser:

conman “stop;wait”

2. Desde Job Scheduling Console, desvincule la estación de trabajo de destino

seleccionada de las demás estaciones de trabajo de la red. De lo contrario,

utilice el comando siguiente desde la línea de comandos del gestor de dominio

maestro:

conman "unlink nombre_estación_trabajo;noask"

3. Desde la línea de comandos (UNIX) o el indicador de comandos (Windows),

detenga el proceso Netman de la manera siguiente:

v En UNIX, ejecute:

conman “shut;wait"

v En Windows, ejecute el comando shutdown.cmd desde el directorio inicial de

Tivoli Workload Scheduler.4. Si está actualizando un agente, elimine (desmonte) todos los directorios

montados en NFS en el gestor de dominio maestro.

5. Si está actualizando una instalación que incluye el conector, asegúrese de que

también detiene el conector. Consulte el apartado siguiente para obtener

detalles.

Para verificar si existen servicios y procesos todavía en ejecución, siga estos pasos:

v En UNIX, escriba el comando

ps -u

Verifique que los procesos siguientes no se estén ejecutando: netman, mailman,

batchman, writer, jobman, JOBMAN y stageman.

v En Windows, ejecute el comando:

<unidad>unsupported\listproc.exe

Verifique que los procesos siguientes no se están ejecutando: netman, mailman,

batchman, writer, jobman, stageman, JOBMON, tokensrv y batchup.

También, asegúrese de que no haya programas de sistema que estén accediendo

al directorio o a cualquier cosa que esté por debajo de dicho directorio,

incluyendo el indicador de comandos y Windows Explorer.

Detención del conector

Si está actualizando una instalación en la que está incluido el conector, debe

detener el conector antes de iniciar el proceso de actualización. Sólo el asistente de

instalación ISMP y los métodos de instalación desatendida son capaces de

actualizar instalaciones existentes del conector. Utilice el comando wmaeutil para

detener el conector.

Para ejecutar el comando wmaeutil, siga estos pasos:

1. Defina el entorno Tivoli:

v Desde una línea de comandos de UNIX:

– Para ksh:

. /etc/Tivoli/setup_env.sh

– Para csh:

source /etc/Tivoli/setup_env.sh

v Desde una línea de comandos de Windows:



%SYSTEMROOT%\system32\drivers\etc\Tivoli\setup_env.cmd

2. Entre el comando siguiente:

v En UNIX

wmaeutil.sh ALL -stop

v En Microsoft Windows

wmaeutil.cmd ALL -stop

Archivos de copia de seguridad

El procedimiento de actualización para las plataformas de Nivel 1 crea una copia

de seguridad de la instalación completa de Tivoli Workload Scheduler, Versión 7.0

y 8.1 en un directorio denominado:

TWShome_backup_TWSuser

Nota: Los archivos de copia de seguridad se trasladan al mismo sistema de

archivos donde el usuario ha instalado originalmente el producto. Se realiza

una comprobación para asegurarse de que existe espacio suficiente en el

sistema de archivos; de lo contrario, el procedimiento de actualización no

puede comenzar. Si no tiene espacio de disco suficiente para realizar la

actualización, cree una copia de seguridad de la base de datos mozart y de

todos los archivos de configuración personalizados, e instale una nueva

instancia de Tivoli Workload Scheduler, Versión 8.2. Luego, transfiera los

archivos guardados y la base de datos mozart hacia la nueva instalación.

A menudo estos archivos de configuración se personalizan de acuerdo con las

necesidades específicas del usuario; puede utilizar las copias guardadas para

incorporar los cambios una vez hecha la actualización. El programa de instalación

no sobrescribirá ninguno de los archivos de los directorios mozart, stdlist ni unison

que se modificaron después de instalar Tivoli Workload Scheduler, es decir, los

archivos localopts, globalopts y tbsmadapter.config.

Si existe cualquier otro archivo que desee proteger durante una actualización, copie

los archivos o renómbrelos ahora. Como medida de precaución adicional, debería

también crear una copia de seguridad del directorio TWShome completo.

Tenga también en cuenta que si ha colocado cualquier archivo o directorio personal

en el directorio TWShome, éstos se van a perder durante el proceso de

actualización, puesto que todos los archivos de TWShome que no pertenecen a la

instalación IBM Tivoli Workload Scheduler no migran. Tendría que hacer copias de

seguridad de estos archivos o directorios antes de iniciar la actualización y

restaurarlos cuando dicha actualización se haya completado.

Utilización de los nuevos archivos de configuración

Durante el proceso de actualización, los modelos de archivo de configuración de

las versiones de IBM Tivoli Workload Scheduler anteriores son sobrescritos por los

nuevos en el directorio TWShome/config. Las copias de trabajo de estos modelos se

instalan con la extensión de archivo .TWS82. Estos modelos contienen valores

predeterminados además de la información que se ha suministrado durante la

instalación. Este proceso se aplica a los archivos de configuración siguientes:

v TWShome/mozart/globalopts

v TWShome/localopts

v TWShome/Tbsm/TbsmAdapter/adapter.config



Nota: Los archivos .TWS82 ya no se instalarán si actualiza la instalación con el

script twsinst.sh distribuido con el arreglo APAR IY48550 (incluido en el

paquete del fix pack 3).

Después del proceso de actualización, puede seguir utilizando los archivos de

configuración que utilizaba en la instalación anterior. Por ejemplo, después de la

actualización podrá encontrar tres copias del archivo de opciones globales

distribuidas de la manera siguiente:

v TWShome/config/globalopts

Ésta es la plantilla del archivo.

v TWShome/mozart/globalopts

Éste es el archivo de opciones globales anterior.

v TWShome/mozart/globalopts.TWS82

Ésta es la copia de trabajo del nuevo archivo de opciones globales de la Versión

8.2.

Puede seleccionar una de las opciones siguientes:

v Seguir utilizando el archivo de opciones globales antiguo. En este caso, no

deberá hacer nada.

v Utilizar el nuevo archivo de opciones globales. En este caso, deberá:

1. Renombrar globalopts como globalopts.old

2. Renombrar globalopts.TWS82 como globalopts

v Utilice el archivo de opciones globales nuevo, además de algunos de los valores

que tenía en el archivo antiguo. A continuación, proceda como en la opción

anterior y modifique el archivo manualmente.

Recuerde que, si desea activar las nuevas funciones opcionales que están

disponibles con la versión 8.2 (como por ejemplo SSL), debe utilizar el archivo de

opciones .TWS82 nuevo o añadir manualmente las opciones correspondientes de la

versión anterior.

Ampliación de la base de datos

Si está actualizando desde la versión 7.0 o 8.1 a la versión 8.2, asegúrese de que

amplía sus bases de datos antes de ejecutar el proceso de actualización. Además, si

la red incluye maestros de reserva junto con copias de archivos de base de datos,

amplíelos antes de ejecutar el proceso de actualización. El uso de bases de datos

expandidas es el valor predeterminado para las instalaciones de Tivoli Workload

Scheduler, Versión 8.2. Ello permite el uso de nombres largos para objetos de

planificación; por ejemplo, los nombres de trabajos pueden contener hasta 40

caracteres, en lugar de 8 como en las versiones anteriores. Para ampliar las bases

de datos, ejecute el comando dbexpand en el gestor de dominio maestro. El

programa establece en ″Sí″ la opción global ″versión expandida″, crea copias de

seguridad de las bases de datos existentes, y amplía las bases de datos para

aceptar nombres de objetos largos. Ejecute dbexpand una sola vez; de lo contrario

se perderá la copia de seguridad de las bases de datos existentes. Las copias de

seguridad se colocan en un directorio denominado mozart.old, dentro del

directorio mozart.

Implicaciones de Tivoli Management Framework

El motor de Tivoli Workload Scheduler no es una aplicación de Tivoli Management

Framework. Sin embargo, Tivoli Management Framework, Versión 3.7.1 o 4.1, es



un requisito previo del conector de Tivoli Workload Scheduler y Tivoli Plus

Module. El conector es necesario si desea utilizar Job Scheduling Console.

Cuando instale o actualice a Tivoli Workload Scheduler, Versión 8.2, es necesaria la

presencia de Tivoli Management Framework, Versión 3.7.1 o 4.1 para utilizar

funciones opcionales tales como el conector de Tivoli Workload Scheduler y Tivoli

Plus Module. Estas funciones deben estar instaladas en el servidor Tivoli. No se

pueden realizar actualizaciones en nodos gestionados utilizando el programa de

instalación, pero sí pueden realizarse desde el escritorio de Tivoli. El programa de

instalación instala automáticamente el servidor de Tivoli Management Framework

si no se detecta su presencia durante la instalación. Si se detecta la presencia de

Tivoli Management Framework, el programa de instalación verifica su versión; si

se detecta un versión no soportada, no se realiza la actualización. Deberá actualizar

manualmente Tivoli Management Framework a la versión 3.7.1 o 4.1 y comenzar el

proceso de actualización de Tivoli Workload Scheduler.

Cuando ya está instalada una versión soportada de Tivoli

Management Framework

El programa de instalación es capaz de detectar la presencia de una instalación de

Tivoli Management Framework y también de verificar la versión. Si se detecta una

versión soportada, existen varios requisito previos que se deben cumplir; de lo

contrario la instalación fallará.

Roles de Administrador

Verifique que el Administrador de Tivoli Management Framework tenga

asignado el rol de autorización install_product.

Encendido y ejecución de Tivoli Management Framework

Verifique el servidor de Tivoli Management Framework está encendido y

en ejecución.

Tivoli Management Server, no un nodo gestionado

Tivoli Workload Scheduler Connector y Tivoli Plus Module deben estar

instalados en un servidor de Tivoli Management Framework. No se

pueden realizar actualizaciones en nodos gestionados utilizando el

programa de instalación, pero sí pueden realizarse desde el escritorio de

Tivoli.

No existen versiones anteriores del conector de Tivoli Workload Scheduler ni

Tivoli Plus Module en los nodos gestionados de la región

Para actualizar el conector de Tivoli Workload Scheduler y Tivoli Plus

Module en el servidor Tivoli utilizando el programa de instalación, no

debe existir ninguna versión anterior de esos componentes en los nodos

gestionados de la región Tivoli. En un entorno que contenga conectores o

Tivoli Plus Module en el servidor Tivoli y en nodos gestionados, debe

realizar la actualización en dos fases: 1) utilice el programa de instalación

para actualizar sólo el motor de Tivoli Workload Scheduler en el servidor

Tivoli y 2) desde el escritorio de Tivoli actualice los conectores en los

nodos gestionados y servidor Tivoli.



Parte 3. Instalación y actualización

Capítulo 3. Instalación mediante el asistente de

instalación . . . . . . . . . . . . . . 39

Instalación de una instancia nueva de Tivoli

Workload Scheduler . . . . . . . . . . . 39

Secuencia de la instalación típica . . . . . . 40

Secuencia de la instalación completa . . . . . 41

Secuencia de la instalación personalizada . . . 43

Adición de una función nueva en una instalación

existente . . . . . . . . . . . . . . . 46

Promoción de una instalación existente . . . . . 48

Realización de una instalación desatendida . . . . 49

Procedimiento de instalación . . . . . . . 49

Capítulo 4. Instalación y promoción mediante

twsinst . . . . . . . . . . . . . . . 51

Instalación y promoción . . . . . . . . . . 51

Capítulo 5. Instalación mediante Software

Distribution . . . . . . . . . . . . . . 55

Paquetes de software y parámetros . . . . . . 55

Procedimiento de instalación . . . . . . . . 57

Instalación de paquetes de idioma . . . . . . . 58

Capítulo 6. Instalación mediante customize . . . 61

El script customize . . . . . . . . . . . . 61

Instalación del motor de Tivoli Workload Scheduler 62

Capítulo 7. Actualización de Tivoli Workload

Scheduler . . . . . . . . . . . . . . 65

Casos de actualización . . . . . . . . . . . 65

Actualización de Tivoli Workload Scheduler . . . 66

Utilización del asistente de instalación . . . . 66

Utilización de twsinst . . . . . . . . . . 68

Creación de una copia de seguridad antes de

ejecutar el script . . . . . . . . . . . 68

Ejecución de twsinst . . . . . . . . . 70

Utilización del archivo de respuestas

migrationInstall . . . . . . . . . . . . 72

Utilización de Software Distribution . . . . . 73

Utilización de customize . . . . . . . . . 73


Capítulo 3. Instalación mediante el asistente de instalación

Este capítulo describe cómo instalar, añadir funciones, promover y desinstalar

Tivoli Workload Scheduler utilizando el asistente de instalación. El asistente de

instalación sólo se ejecuta en plataformas de Nivel 1. Consulte el manual Tivoli

Workload Scheduler Release Notes para obtener una lista de las plataformas de Nivel

1 soportadas. Este capítulo contiene las secciones siguientes:

v “Instalación de una instancia nueva de Tivoli Workload Scheduler”

v “Adición de una función nueva en una instalación existente” en la página 46

v “Promoción de una instalación existente” en la página 48

v “Realización de una instalación desatendida” en la página 49

Para obtener información sobre la actualización de Tivoli Workload Scheduler,

Versión 8.2, consulte el Capítulo 7, “Actualización de Tivoli Workload Scheduler”,

en la página 65.

Instalación de una instancia nueva de Tivoli Workload Scheduler

Una instalación nueva puede ser típica, completa o personalizada. La Tabla 12

detalla lo que se ha instalado en cada opción de instalación.

Tabla 12. Funciones de ISMP

Función Típica Personalizada Completa Actualización

Tipo de agente Agente tolerante

a errores

Opción del

usuario

Gestor de

dominio maestro

Opción del

usuario

Tivoli Plus

Module

No instalado Opción del

usuario

No instalado No instalado

Conector No instalado Opción del

usuario

Instalado No instalado

Tivoli

Framework

No instalado Si se ha

seleccionado

Tivoli Plus

Module o el

conector

Instalado No instalado

Idiomas Entorno local del

sistema

Opción del

usuario

Todos los

idiomas

No instalado

Para instalar una instancia nueva de Tivoli Workload Scheduler, siga los pasos

siguientes:

1. Inserte el Disco 1 de instalación de IBM Tivoli Workload Scheduler.

Si está instalando en una estación de trabajo Linux, inserte el Disco 2 de

instalación de IBM Tivoli Workload Scheduler.

2. Ejecute el programa de instalación correspondiente al sistema operativo donde

está realizando la instalación.

v Para las plataformas Windows, el archivo SETUP.exe está situado en la

carpeta Windows.

v En las plataformas UNIX, el archivo SETUP.bin está situado en el directorio

raíz del CD de instalación. Utilice el archivo SETUP.bin del CD únicamente


para la instalaciones completa. Para instalaciones típicas o personalizadas,

utilice el archivo SETUP.bin ubicado en el directorio /bin. 3. Se inicia el asistente de instalación. Seleccione el idioma del asistente de

instalación. Haga clic en Aceptar.

4. Lea la información de bienvenida y haga clic en Siguiente.

5. Lea y acepte el acuerdo de licencia. Haga clic en Siguiente.

6. La opción Instalar un agente de Tivoli Workload Scheduler nuevo está

seleccionada de forma predeterminada. Haga clic en Siguiente.

7. Especifique el nombre de usuario de Tivoli Workload Scheduler. No está

permitido usar espacios en blanco.

v En los sistemas Windows, si esta cuenta de usuario no existe ya, el

programa de instalación la crea automáticamente. Si especifica un usuario

de dominio, especifique el nombre en la forma

nombre_dominio\nombre_usuario. Si especifica un usuario local con el mismo

nombre que un usuario de dominio, primero el administrador debe crear

manualmente el usuario local y luego especificarlo en la forma

nombre_sistema\nombre_usuario. Escriba y confirme la contraseña.

Nota: La contraseña debe cumplir la política de contraseñas definida en los

Valores de seguridad locales; de lo contrario, la instalación fallará.

v En los sistemas UNIX, esta cuenta de usuario se debe crear manualmente

antes de ejecutar el programa de instalación. Cree un usuario con un

directorio inicial. IBM Tivoli Workload Scheduler se instalará en el

directorio inicial (HOME) del usuario seleccionado.

Haga clic en Siguiente.

8. En los sistemas Windows, si ha especificado un nombre de usuario que no

existe todavía, se muestra un panel de información. Revise la información y

haga clic en Siguiente.

9. Sólo en los sistemas Windows, especifique el directorio de instalación en el

que se instalará el producto. El nombre de directorio no puede contener

espacios en blanco. El directorio debe estar situado en un sistema de archivos

NTFS. Haga clic en Examinar para seleccionar un directorio de destino

diferente y, a continuación, haga clic en Siguiente.

10. Seleccione el tipo de instalación:

v Típica. Consulte el apartado “Secuencia de la instalación típica”.

v Completa. Consulte el apartado “Secuencia de la instalación completa” en

la página 41.

v Personalizada. Consulte el apartado “Secuencia de la instalación

personalizada” en la página 43.

Secuencia de la instalación típica

Para realizar una instalación típica, siga estos pasos:

1. Proporcione la información siguiente. Consulte el apartado ″Internationalization

Notes″ en el manual IBM Tivoli Workload Scheduler Release Notes para conocer las

restricciones existentes.

Instalación de ISMP


Tabla 13. Datos de CPU

Campo Valor

Empresa Escriba el nombre de la empresa. Este

nombre aparece en las cabeceras de

programa e informes. Están permitidos los

espacios en blanco, siempre que el nombre

no esté delimitado por comillas dobles.

Esta CPU Escriba el nombre de la estación de trabajo

para Tivoli Workload Scheduler. Este

nombre no puede tener más de 16 caracteres

y no puede contener espacios en blanco.

CPU maestra Escriba el nombre del gestor de dominio

maestro. Este nombre no puede tener más

de 16 caracteres y no puede contener

espacios en blanco.

Número de puerto TCP Es el número de puerto TCP utilizado por la

instancia que se está instalando. Debe ser un

valor comprendido dentro del rango

1–65535. El valor predeterminado es 31111.

Si instala más de una instancia en la misma

estación de trabajo, utilice un número de

puerto diferente para cada instancia.


2. Revise los valores de instalación y haga clic en Siguiente. Una barra de

progreso indica que la instalación se ha iniciado.

3. Cuando la instalación finaliza, se muestra un panel que indica que la

instalación ha sido satisfactoria o que indica la ubicación del archivo de registro

si la instalación no ha sido satisfactoria. Haga clic en Finalizar.

Para configurar el agente tolerante a errores, consulte el apartado “Configuración

de un agente tolerante a errores o un agente estándar” en la página 80. Para las

instalaciones en UNIX, consulte también el apartado “Pasos de configuración para

instalaciones UNIX de Nivel 1 y Nivel 2” en la página 82.

Secuencia de la instalación completa

Siga los pasos siguientes para realizar una instalación completa.

1. Proporcione los datos descritos en la Tabla 13. Consulte el apartado

″Internationalization Notes″ en el manual IBM Tivoli Workload Scheduler Release

Notes para conocer las restricciones existentes. Haga clic en Siguiente.

2. Complete el panel según la información de la tabla siguiente.

Tabla 14. Información sobre el conector de Tivoli Workload Scheduler

Campo Valor

Nombre de instancia del conector Escriba el nombre que sirve para identificar

la instancia en la ventana de Job Scheduling

Console. El nombre debe ser exclusivo

dentro de la red del planificador.

Directorio inicial de Tivoli Workload

Scheduler

Muestra la ubicación de la instalación de

Tivoli Workload Scheduler que se ha

especificado en un panel anterior.


3. El conector requiere Tivoli Management Framework. Si no se detecta ninguna

versión de Tivoli Management Framework, puede instalarla ahora con la


Capítulo 3. Instalación mediante el asistente de instalación 41

información que le proporciona la Tabla 15. Si detecta una versión de Tivoli

Management Framework a la que no se da soporte, concluya la instalación y

actualice la versión de Tivoli Management Framework tal y como se describe

en el manual Tivoli Enterprise Installation Guide.

Tabla 15. Panel de instalación de Tivoli Management Framework

Campo Valor

Cuenta de acceso remoto Escriba el nombre de la cuenta de acceso

remoto de Tivoli que permite que los

programas Tivoli accedan a sistemas de

archivos remotos.

Contraseña Escriba la contraseña para la cuenta de

acceso remoto.

Contraseña de instalación Especifique una contraseña de instalación

si desea que se utilice una contraseña para

instalaciones subsiguientes de nodos

gestionados.

Los campos restantes son opcionales y son aplicables si piensa desplegar

programas Tivoli o nodos gestionados en el entorno de Tivoli Management

Framework. Haga clic en Siguiente.

Nota: En Windows, el escritorio de Tivoli debe instalarse de forma

independiente. Para obtener más información, consulte el manual Tivoli

Management Framework Planning Deployment Guide.


progreso indica que la instalación se ha iniciado. Para determinar el paso

siguiente que debe realizar, examine la lista siguiente y determine la situación

que mejor corresponde a su entorno:

v No ha sido necesario instalar Tivoli Management Framework, pues se ha

detectado una versión soportada en la estación de trabajo. Vaya al paso 5 en

la página 43.

v Se instalará el servidor de Tivoli Management Framework, versión 4.1, pues

no se ha detectado su presencia. Siga los pasos siguientes:

a. Se mostrará la ventana Localice la imagen de instalación para conocer la

ubicación de las imágenes de Tivoli Management Framework. Si no ha

copiado las imágenes en la máquina local o no están accesibles en una

unidad montada NFS, desmonte el CD de instalación y monte el CD de

Tivoli Management Framework. Vaya al directorio donde están

contenidas las imágenes. Haga clic en Aceptar para continuar la

instalación. Una barra de progreso indica que se está instalando el

servidor Tivoli.

b. A continuación, se le solicitará que especifique las imágenes de Tivoli Job

Scheduling Services necesarias para instalar el conector. Estas imágenes

están situadas en el directorio TWS_CONN del CD de instalación. Vaya a

ese directorio y haga clic en Aceptar. El programa de instalación instalará

el conector.

Nota: En Windows, si Tivoli Management Framework no se ha instalado

nunca en la estación de trabajo, se puede solicitar al usuario que

rearranque el sistema antes de que se le soliciten las imágenes de

Tivoli Job Scheduling Services para finalizar la instalación. Haga

clic en Ahora para reiniciar el sistema. Después del reinicio del

sistema, se vuelve a iniciar el programa de instalación y se solicitan



al usuario las imágenes necesarias para instalar el conector. Si no

reinicia el sistema inmediatamente, sólo se instala el motor de

Tivoli Workload Scheduler, sin el conector. El conector se instalará

la próxima vez que reinicie la estación de trabajo.5. Cuando la instalación finaliza, se muestra un panel que indica que la



Para configurar el gestor de dominio maestro, consulte el apartado “Configuración

de un gestor de dominio maestro” en la página 79. Para instalaciones de UNIX,

consulte el apartado “Pasos de configuración para instalaciones UNIX de Nivel 1 y

Nivel 2” en la página 82.

Si ha instalado el conector, debe configurar el archivo de seguridad tal y como se

describe en el apartado “Actualización del archivo de seguridad” en la página 82.

Secuencia de la instalación personalizada

Siga los pasos siguientes para realizar una instalación personalizada.

Nota: Si la instalación incluye la instalación de Tivoli Management Framework

(personalizada incluido el conector o Tivoli Plus), asegúrese de tener

iniciada una sesión como administrador.

1. Proporcione los datos descritos en la Tabla 13 en la página 41. Consulte el

apartado ″Internationalization Notes″ en el manual IBM Tivoli Workload

Scheduler Release Notes para conocer las restricciones existentes. Haga clic en

Siguiente.

2. Para determinar el paso siguiente que debe realizar, siga los pasos descritos

para el tipo de agente que ha seleccionado para instalar:

v Agente estándar

a. Seleccione idiomas adicionales para instalar y haga clic en Siguiente.

b. Revise los valores de instalación y haga clic en Siguiente. Una barra de


c. Cuando la instalación finaliza, se muestra un panel que indica que la

instalación ha sido satisfactoria o que indica la ubicación del archivo de

registro si la instalación no ha sido satisfactoria. Haga clic en Finalizar.

d. Para configurar el agente estándar que acaba de instalar, consulte el

apartado “Configuración de un agente tolerante a errores o un agente

estándar” en la página 80. Para las instalaciones en UNIX, consulte

también el apartado “Pasos de configuración para instalaciones UNIX de

Nivel 1 y Nivel 2” en la página 82.v Agente tolerante a errores, Maestro de copia de seguridad, Gestor de

dominio maestro. Si selecciona uno o ambos componentes opcionales, vaya

al paso 3 en la página 44. Si no ha seleccionado ninguno de los componentes

opcionales, siga los pasos siguientes:

a. Seleccione idiomas adicionales para instalar y haga clic en Siguiente.






d. Para configurar el agente o maestro que acaba de instalar, consulte los

apartados “Configuración de un agente tolerante a errores o un agente

estándar” en la página 80 o “Configuración de un gestor de dominio



maestro” en la página 79. Para las instalaciones en UNIX, consulte

también el apartado “Pasos de configuración para instalaciones UNIX de

Nivel 1 y Nivel 2” en la página 82.3. Si ha seleccionado instalar el conector, proporcione la información descrita en el

apartado Tabla 14 en la página 41. En otro caso, vaya al paso siguiente. Si el

conector ya está instalado, se creará una nueva instancia. Haga clic en

Siguiente.

4. Si ha especificado el componente opcional Tivoli Plus Module, proporcione la

información siguiente: En otro caso, vaya al paso siguiente:

Tabla 16. Panel de información de Tivoli Plus Module

Campo Valor

Nombre de usuario Muestra el usuario para el cual se instala

Tivoli Workload Scheduler. Este usuario se

ha especificado en una instalación anterior.

Directorio inicial de Tivoli Workload

Scheduler

Muestra la ubicación de la instalación de

Tivoli Workload Scheduler. Esta ruta de

acceso se ha especificado en una instalación

anterior.

Directorio de instalación de Job Scheduling

Console

Opcionalmente, especifique la ubicación de

la instalación de Job Scheduling Console. Se

crea una tarea que permite al usuario iniciar

Job Scheduling Console desde el escritorio

de Tivoli.

Especifique esta información en los campos apropiados y haga clic en

Siguiente.

5. Seleccione idiomas adicionales para instalar y haga clic en Siguiente. Si ha

instalado idiomas en una instalación anterior, se pueden inhabilitar desde el

panel de selección de idiomas.

6. Los componentes Conector y Tivoli Plus Module necesitan Tivoli Management

Framework. Para determinar el paso siguiente que debe realizar, examine la

lista siguiente y determine la situación que mejor corresponde a su entorno:

v En la estación de trabajo existe una versión soportada de Tivoli Management

Framework (versiones 3.7.1 o 4.1). Vaya al paso 7 en la página 45.

v Se ha detectado una versión no soportada por Tivoli Workload Scheduler.

Salga del programa de instalación, actualice la instalación de Tivoli

Management Framework y reinicie el programa de instalación. Consulte el

manual Tivoli Enterprise Installation Guide para obtener instrucciones de

actualización. O bien, vuelva atrás y seleccione un tipo de instalación

diferente.

v Tivoli Management Framework no está instalado en la estación de trabajo.

Para hacer que el programa de instalación instale el servidor de Tivoli

Management Framework, versión 4.1, en la estación de trabajo, especifique el

directorio donde desea instalar el servidor, o utilice el botón Examinar para

localizar el directorio. Los campos restantes son opcionales y son aplicables si

piensa desplegar programas Tivoli o nodos gestionados en el entorno de

Tivoli Management Framework. Opcionalmente, especifique la información

siguiente:



Tabla 17. Panel de instalación de la versión de Tivoli Management Framework

Campo Valor

Cuenta de acceso remoto Escriba el nombre de la cuenta de acceso

remoto de Tivoli que permite que los

programas Tivoli accedan a sistemas de

archivos remotos.

Contraseña Escriba la contraseña para la cuenta de

acceso remoto.

Contraseña de instalación Especifique una contraseña de instalación

si desea que se utilice una contraseña

para instalaciones subsiguientes de nodos

gestionados.


Nota: En Windows, el escritorio de Tivoli debe instalarse de forma

independiente. Para obtener más información, consulte el manual Tivoli

Management Framework Planning and Installation Guide.


progreso indica que la instalación se ha iniciado. Para determinar el paso

siguiente que debe realizar, examine la lista siguiente y determine la situación

que mejor corresponde a su entorno:

v No ha sido necesario instalar Tivoli Management Framework, pues se ha

detectado una versión soportada en la estación de trabajo. Si ha seleccionado

idiomas adicionales, puede que tenga que especificar las imágenes de soporte

de idioma de Tivoli Management Framework. Localice las imágenes y haga

clic en Aceptar. Vaya al paso 8 en la página 46.

v Se instalará el servidor de Tivoli Management Framework, versión 4.1, pues

no se ha detectado su presencia. Dependiendo de los componentes

opcionales que seleccionó, puede que tenga que seguir todos o algunos de

los pasos siguientes:

a. Se mostrará la ventana Localice la imagen de instalación para conocer la

ubicación de las imágenes de Tivoli Management Framework. Si no ha

copiado las imágenes en la máquina local o no están accesibles en una

unidad montada NFS, desmonte el CD de instalación y monte el CD de

Tivoli Management Framework. Vaya al directorio donde están

contenidas las imágenes. Haga clic en Aceptar para continuar la

instalación. Una barra de progreso indica que se está instalando el

servidor Tivoli.

b. A continuación, si ha seleccionado instalar paquetes de idioma

adicionales, se le solicitará que especifique las imágenes de los paquetes

de idioma de Tivoli Management Framework. Vaya al directorio indicado

y haga clic en Aceptar.

c. A continuación, se le solicitará que especifique las imágenes de Tivoli Job

Scheduling Services necesarias para instalar el conector. Estas imágenes

están situadas en el directorio TWS_CONN del CD de instalación. Vaya a

ese directorio y haga clic en Aceptar. El programa de instalación instalará

el conector.

Nota: En Windows, si Tivoli Management Framework no se ha instalado

nunca en la estación de trabajo, se puede solicitar al usuario que

reinicie el sistema antes de solicitarle las imágenes de Tivoli Job

Scheduling Services para finalizar la instalación. Haga clic en

Ahora para reiniciar el sistema inmediatamente. Después del



reinicio del sistema, se vuelve a iniciar el programa de instalación

y se solicitan al usuario las imágenes necesarias para instalar el

conector. Vaya al directorio donde están contenidas las imágenes y

haga clic en Siguiente. Si no reinicia el sistema inmediatamente,

sólo se instala el motor de Tivoli Workload Scheduler, sin el

conector. El conector se instalará la próxima vez que reinicie la

estación de trabajo. Si ha instalado el conector, debe configurar el

archivo de seguridad. Para obtener instrucciones, consulte el

apartado “Actualización del archivo de seguridad” en la página 82.

d. Si ha seleccionado instalar Tivoli Plus Module, las imágenes de

instalación están situadas en la carpeta TWSPLUS del CD de instalación.

Vaya a la carpeta y haga clic en Aceptar.8. Cuando la instalación finaliza, se muestra un panel que indica que la



Para configurar el agente o maestro que acaba de instalar, consulte los apartados

“Configuración de un agente tolerante a errores o un agente estándar” en la página

80 o “Configuración de un gestor de dominio maestro” en la página 79. Para las

instalaciones en UNIX, consulte también el apartado “Pasos de configuración para

instalaciones UNIX de Nivel 1 y Nivel 2” en la página 82.

Si ha instalado el conector, debe configurar el archivo de seguridad tal y como se

describe en el apartado “Actualización del archivo de seguridad” en la página 82.

Adición de una función nueva en una instalación existente

Puede instalar los siguientes componentes o funciones opcionales que no se

instalaron durante una instalación anterior de Tivoli Workload Scheduler Versión

8.2, utilizando el programa de instalación:

Tabla 18. Funciones y componentes instalables opcionales

Función Descripción

Tivoli Plus Module Integra Tivoli Workload Scheduler con Tivoli

Management Framework, Tivoli Enterprise Console y

Distributed Monitoring. Tivoli Management Framework

versión 3.7.1 o 4.1 es un requisito previo para este

componente. Si se detecta una versión anterior a 3.7.1,

esta función no se puede instalar. Si no se detecta una

instalación, se instala automáticamente la versión 4.1.

Consulte el apartado “Implicaciones de Tivoli

Management Framework” en la página 35 para obtener

más información.

Conector de Tivoli Workload

Scheduler

Job Scheduling Console se comunica con el sistema

Tivoli Workload Scheduler a través del conector.

Convierte las instrucciones entradas mediante Job

Sheduling Console en comandos de Workload

Scheduler. Tivoli Management Framework versión 3.7.1

o 4.1 es un requisito previo para este componente. Si se

detecta una versión anterior a 3.7.1, esta función no se

puede instalar. Si no se detecta una instalación, se

instala automáticamente la versión 4.1. Consulte el

apartado “Implicaciones de Tivoli Management

Framework” en la página 35 para obtener más

información.



Tabla 18. Funciones y componentes instalables opcionales (continuación)

Función Descripción

Paquetes de idioma El paquete de idioma del inglés y el entorno local de

idioma del sistema operativo se instalan de forma

predeterminada. El programa de instalación permite a

los usuarios seleccionar cualquiera de los idiomas

soportados.

La instalación de Tivoli Plus Module y del conector se describen en el apartado

“Secuencia de la instalación personalizada” en la página 43

Para instalar paquetes de idioma adicionales, realice los pasos siguientes:

1. Inserte el Disco 1 de instalación de IBM Tivoli Workload Scheduler.Si está instalando en una estación de trabajo Linux, inserte el Disco 2 de




v En las plataformas Windows, el archivo SETUP.exe está situado en el

directorio de la plataforma en la que desea instalar Tivoli Workload

Scheduler.


raíz del CD de instalación. 3. Se inicia el asistente. Seleccione el idioma de instalación t haga clic en

Aceptar.

4. Lea la información de bienvenida. Haga clic en Siguiente.


6. En la lista desplegable, seleccione una instalación existente de Tivoli Workload

Scheduler, Versión 8.2. Las instalaciones de la Versión 8.2 se identifican

mediante el tipo de agente y el nombre de usuario para el que se ha instalado

el agente. Las instalaciones de las versiones 7.0 y 8.1 se identifican por el

nombre de grupo asignado.

7. El botón de selección Agregar una función a la instancia seleccionada se

selecciona de forma predeterminada. Haga clic en Siguiente.

8. Revise la información de usuario y haga clic en Siguiente.

9. Revise el directorio de destino y haga clic en Siguiente.

10. Revise la información de configuración de la estación de trabajo.

11. Seleccione las funciones opcionales que desea instalar.

v Si ha seleccionado una o más funciones opcionales, haga clic en Siguiente.

v Si no ha seleccionado funciones opcionales en este panel, haga clic en

Siguiente y siga estos pasos:

a. Seleccione idiomas adicionales para instalar y haga clic en Siguiente. Si

ha instalado idiomas en una instalación anterior, se pueden inhabilitar

desde el panel de selección de idiomas.





registro si la instalación no ha sido satisfactoria. Haga clic en Finalizar.12. Seleccione idiomas adicionales para instalar y haga clic en Siguiente. Si ha

instalado idiomas en una instalación anterior, se pueden inhabilitar desde el

panel de selección de idiomas.





14. Cuando la instalación finaliza, se muestra un panel que indica que la



Promoción de una instalación existente

Reconfigure un agente de Tivoli Workload Scheduler, Versión 8.2, para obtener un

tipo de agente diferente. Puede realizar las operaciones siguientes:

v Promover un agente estándar a un gestor de dominio maestro/maestro de copia

de seguridad

v Promover un agente estándar a un agente tolerante a errores

v Promover un agente tolerante a errores a un gestor de dominio maestro/maestro

de copia de seguridad

Antes de realizar una operación de promover, asegúrese de que todos los procesos

y servicios de Tivoli Workload Scheduler estén detenidos. Para obtener información

sobre la detención de los procesos y servicios, consulte el apartado “Desvinculación

y detención de Tivoli Workload Scheduler” en la página 32.

Para promover un agente de Tivoli Workload Scheduler Versión 8.2 y obtener un

tipo diferente de agente, siga los pasos siguientes:

1. Inserte el Disco 1 de instalación de IBM Tivoli Workload Scheduler.Si está instalando en una estación de trabajo Linux, inserte el Disco 2 de





directorio de la plataforma en la que desea instalar Tivoli Workload

Scheduler.


raíz del CD de instalación. 3. Se inicia el asistente. Seleccione el idioma del asistente de instalación. Haga

clic en Aceptar.



6. En la lista desplegable, seleccione una instalación existente de Tivoli Workload

Scheduler, Versión 8.2. Las instalaciones se identifican mediante el tipo de

agente y el nombre de usuario para el que se ha instalado el agente.

7. Seleccione Promover la instancia seleccionada y haga clic en Siguiente.

8. Revise la información de usuario y haga clic en Siguiente.

9. Revise el directorio de instalación de destino y haga clic en Siguiente.

10. Seleccione el tipo de agente de Tivoli Workload Scheduler hacia el que desea

promover la instancia seleccionada y haga clic en Siguiente.

11. Revise los valores de configuración de la estación de trabajo y haga clic en

Siguiente.





13. Cuando la instalación finaliza satisfactoriamente, se muestra un panel para

indicarlo. Si una instalación no se realiza satisfactoriamente, consulte el

archivo de registro indicado. Haga clic en Finalizar.

Realización de una instalación desatendida

Utilice las plantillas de archivo de respuesta que se proporcionan en el CD (CD 1

\RESPONSE_FILE\) para realizar una instalación desatendida. Los archivos de

respuestas incluyen toda la información necesaria para que el programa de

instalación se ejecute sin la intervención del usuario. Las instrucciones para

personalizar los archivos están incluidos en los propios archivos en forma de

comentarios.

La tabla siguiente lista los archivos de respuestas disponibles y el tipo de

instalación que cada uno realiza:

Tabla 19. Archivos de respuestas

Tipo de instalación

Archivo de respuestas que se debe

utilizar

Primera instalación freshInstall.txt

Añadir función a instalación existente updateInstall.txt

Promover un agente de una instalación existente updateInstall.txt

Actualizar Tivoli Workload Scheduler, Versión 7.0

o 8.1 a la versión 8.2

migrationInstall.txt

Nota: Si la instalación necesita Tivoli Management Framework (las funciones de

conector y Tivoli Plus Module lo necesitan), debe copiar todas las imágenes

en la máquina local o hacer que sean accesibles en una unidad montada

NFS.

Procedimiento de instalación

Para realizar una instalación desatendida, realice los pasos siguientes:

1. Copie el archivo de respuestas pertinente en un directorio local y edite el

archivo de acuerdo con las necesidades de su entorno.

2. Guarde el archivo con los cambios que ha realizado.

3. Entre el comando siguiente:

v En UNIX,

./SETUP.bin -options <dir_local>/archivo_respuestas.txt

El archivo SETUP.bin está situado en el directorio raíz del Disco 1 de

instalación de IBM Tivoli Workload Scheduler. Solamente para la plataforma

Linux, el archivo SETUP.bin está situado en el directorio raíz del Disco 2 de


v En Windows,

SETUP.exe -options <dir_local>\archivo_respuestas.txt

El archivo SETUP.exe está situado en la carpeta de Windows del Disco 1 de

instalación de IBM Tivoli Workload Scheduler.4. Cuando finalice la instalación, ejecute una de las tareas de configuración

siguientes, de acuerdo con el tipo de agente que se ha instalado:

v “Configuración de un gestor de dominio maestro” en la página 79



v “Configuración de un agente tolerante a errores o un agente estándar” en la

página 80

v Si ha utilizado el archivo updateInstall.txt para añadir un conector, debe

actualizar el archivo de seguridad. Para obtener instrucciones, consulte el

apartado “Actualización del archivo de seguridad” en la página 82.

v Para las instalaciones en UNIX, consulte también el apartado “Pasos de

configuración para instalaciones UNIX de Nivel 1 y Nivel 2” en la página 82.



Capítulo 4. Instalación y promoción mediante twsinst

Esta sección describe el método de línea de comandos para instalaciones que

utilizan el script twsinst en plataformas UNIX de Nivel 1. Consulte el manual

Tivoli Workload Scheduler Release Notes para obtener una lista de las plataformas

soportadas. Para las instalaciones de Nivel 2 desde la línea de comandos, consulte

el Capítulo 6, “Instalación mediante customize”, en la página 61.

Instalación y promoción

En plataformas UNIX de Nivel 1, se utiliza el script twsinst para instalar un:

v Gestor de dominio maestro

v Maestro de copia de seguridad

v Agente tolerante a errores

v Agente estándar

También puede utilizar el script twsinst para realizar actualizaciones a partir de las

versiones 7.0 y 8.1, desinstalar una instancia de la versión 8.2 y promover un

agente existente en la versión 8.2 para obtener un tipo de agente diferente. Para

obtener más información acerca de cómo hacer actualizaciones, consulte el

apartado “Ejecución de twsinst” en la página 70.

Consulte el manual Tivoli Workload Scheduler Release Notes para obtener una lista de

las plataformas de Nivel 2 a las que se da soporte.

Para instalar o promover una instancia de Tivoli Workload Scheduler, realice los

pasos siguientes


2. Cree el usuario de Tivoli Workload Scheduler. Por omisión, el software se

instala en el directorio inicial del usuario, denominado TWShome.

Usuario:

TWSuser

Directorio inicial:

TWShome (por ejemplo: /opt/TWS)3. Inicie la sesión como root, localice el directorio de la plataforma en la que desea

ejecutar el script y ejecute el script twsinst.

Sinopsis

Mostrar la utilización y la versión del comando

twsinst -u | -v

Instalar una nueva instancia

twsinst -new -uname <nombre_usuario>

[-cputype {master | bkm_agent | ft_agent | st_agent} ]

[-thiscpu <nombre_cpu>]

[-master <nombre_cpu_maestra>]

[-port <número_puerto>]

[-company <nombre_empresa>]

[-inst_dir <dir_instalación>]

[-lang <id_idioma>]


Promover una instancia

twsinst -promote -uname <nombre_usuario>

[-cputype {master | bkm_agent | ft_agent} ]

[-inst_dir <dir_instalación>]

[-lang <id_idioma>]

Parámetros

-u Muestra información sobre el uso del comando y concluye su ejecución.

-v Muestra la versión del comando y concluye su ejecución.

-new | -promote

Especifica el tipo de instalación a realizar:

-new Denota una instalación nueva de Tivoli Workload Scheduler,

Versión 8.2. Instala un agente o maestro y todos los paquetes de

idioma soportados.

-promote

Para actualizaciones existentes de Tivoli Workload Scheduler,

versión 8.2, puede realizar estas operaciones:

v Promover un agente estándar para obtener un agente tolerante a

errores, un gestor de dominio maestro o un maestro de copia de

seguridad

v Promover un agente tolerante a errores para obtener un gestor

de dominio maestro o maestro de copia de seguridad

Antes de realizar una operación de promover, asegúrese de que

todos los procesos y servicios de Tivoli Workload Scheduler estén

detenidos. Para obtener información sobre la detención de los

procesos y servicios, consulte el apartado “Desvinculación y

detención de Tivoli Workload Scheduler” en la página 32.

-uname <nombre_usuario>

Es el nombre del usuario para el cual se instala, actualiza, promueve o

desinstala Tivoli Workload Scheduler. El software de TWS se instala o

actualiza en este directorio inicial de usuario. Este nombre de usuario es

distinto del usuario que realiza la instalación y que ha iniciado una sesión

como root. Para una instalación nueva, esta cuenta de usuario se debe

crear manualmente antes de ejecutar la instalación. Cree un usuario con un

directorio inicial. Tivoli Workload Scheduler se instalará en el directorio

inicial (HOME) del usuario especificado.

-cputype

Especifica el tipo de agente de Tivoli Workload Scheduler a instalar. Los

valores válidos son:

v master

v bkm_agent (maestro de copia de seguridad)

v ft_agent (agente tolerante a errores, dominio maestro, gestor de dominio

de reserva)

v st_agent (agente estándar)

Si no se especifica un valor, el valor predeterminado es ft_agent. Cuando

-cputype=master, -master se establece por omisión en el mismo valor que

-thiscpu.

-thiscpu <nombre_cpu>

Es el nombre de la estación de trabajo de Tivoli Workload Scheduler de

esta instalación. El nombre no puede tener más de 16 caracteres. Este

instalación de twsinst


nombre está registrado en el archivo localopts. Si no se especifica un valor,

el valor predeterminado es el nombre de host de la estación de trabajo.

Consulte el apartado ″Internationalization Notes″ en el manual IBM Tivoli

Workload Scheduler Release Notes para conocer las restricciones existentes.

-master <nombre_cpu_maestro>

Es el nombre de la estación de trabajo del gestor de dominio maestro. Este

nombre no puede tener más de 16 caracteres y no puede contener espacios

en blanco. Este nombre está registrado en el archivo globalopts. Si no se

especifica un valor, el valor predeterminado es MASTER. Consulte el


Scheduler Release Notes para conocer las restricciones existentes.

-port <número_puerto>

Es el número del puerto TCP. Este número está registrado en el archivo

localopts. Si no se especifica un valor, se establece por omisión en 31111.

-company <nombre_empresa>

Es el nombre de la empresa. El nombre de la empresa no puede contener

espacios en blanco. Este nombre aparece en las cabeceras de programa e

informes. Si no se especifica un nombre, el nombre por omisión es

COMPANY.

Antes de actualizar o promover una CPU existente, asegúrese de que el

nombre de empresa no contiene espacios en blanco. Puede verificar la

existencia de caracteres en blanco y eliminarlos del nombre de empresa

modificando la entrada correspondiente en el archivo

TWShome/mozart/globalopts.

-inst_dir <dir_instalación>

Es el directorio de la instalación de Tivoli Workload Scheduler. Esta ruta no

puede contener espacios en blanco. Si no se especifica un valor, la ruta

utilizada es el directorio inicial de nombre_usuario.

-lang <id_idioma>

El idioma en el que se visualizan los mensajes twsinst. Si no se especifica

un valor, se utiliza el idioma del sistema (LANG). Si falta el catálogo

asociado, se utiliza el catálogo de idioma predeterminado C.

Nota: La opción -lang no se debe confundir con los paquetes de idioma

soportados de Tivoli Workload Scheduler. Por omisión, todos los

paquetes de idioma soportados se instalan cuando el producto se

instala utilizando el script twsinst.

Ejemplos

A continuación se muestra un script twsinst de ejemplo para instalar una instancia

nueva en una estación de trabajo de agente tolerante a errores:

./twsinst -new -uname twsuser -cputype ft_agent -thiscpu fta -master mdm

-port 31124 -company IBM

A continuación se muestra un script twsinst de ejemplo para promover un agente

tolerante a errores y obtener una estación de trabajo de gestor de dominio maestro:

./twsinst -promote -uname twuser -cputype master


Capítulo 4. Instalación y promoción mediante twsinst 53

Capítulo 5. Instalación mediante Software Distribution

Este capítulo describe cómo realizar la instalación utilizando bloques de paquetes

de software de Software Distribution.

Paquetes de software y parámetros

Tivoli Workload Scheduler puede instalarse distribuyendo un bloque de paquetes

de software (SPB) mediante el componente Software Distribution de IBM Tivoli

Configuration Manager, Versiones 4.2 o 4.2.1. Puede distribuir el SPB, localmente o

remotamente, utilizando la interfaz de línea de comandos o desde el escritorio de

Tivoli.

Nota: No modifique el SPB suministrado.

Existe un SPB para cada plataforma de Nivel 1 soportada. Los bloques de paquetes

de software están situados en el Disco 1 de instalación de IBM Tivoli Workload

Scheduler y en el disco de instalación 2, dentro del directorio de la plataforma en

la que desea realizar la instalación. La línea de comandos de Software Distribution

está situada en una carpeta denominada CLI, dentro de la carpeta de cada

plataforma. También existe un SPB para instalar solamente los paquetes de idioma.

El bloque de paquetes de software para los paquetes de idioma está en el

directorio raíz del Disco 1 de instalación de IBM Tivoli Workload Scheduler. La

Tabla 20 lista los SPB utilizados para instalar componentes y funciones de Tivoli

Workload Scheduler.

Tabla 20. SPB para instalar Tivoli Workload Scheduler

Archivo .SPB Descripción

Tivoli_TWS_WINDOWS.SPB Es el paquete de software para los sistemas

operativos Windows.

Tivoli_TWS_AIX.SPB Es el paquete de software para los sistemas

operativos AIX.

Tivoli_TWS_HP.SPB Es el paquete de software para los entornos

operativos HP-UX.

Tivoli_TWS_SOLARIS.SPB Es el paquete de software para los entornos

operativos Solaris.

Tivoli_TWS_LINUX_I386.SPB Es el paquete de software para Linux de

Intel.

Tivoli_TWS_LINUX_S390.SPB Es el paquete de software para Linux de

OS/390.

Tivoli_TWS_LP.SPB Es el paquete de software que sirve para

instalar un paquete de idioma.

Un bloque de paquetes de software utiliza varios parámetros de Tivoli Workload

Scheduler para realizar la instalación. Estos parámetros están definidos como

variables predeterminadas en el paquete de software. A continuación sigue la lista

de los parámetros de instalación:


Tabla 21. Parámetros de instalación de SPB

Variable Descripción

install_dir El parámetro obligatorio es la ruta calificada al

completo para la ubicación de instalación de Tivoli

Workload Scheduler. Esta ruta no puede contener

espacios en blanco. En las estaciones de trabajo

Windows, esta ruta se crea si no existe ya. En las

estaciones de trabajo UNIX, esta ruta es la misma que

el directorio inicial del usuario. Los valores

predeterminados son:

v Windows:

$(system_drive)\winn32app\TWS\$(tws_user)

v UNIX: opt/TWS/$(tws_user)

tws_user Este parámetro obligatorio es el nombre del usuario

para el cual se instala la instancia de Tivoli Workload

Scheduler. En los sistemas Windows, si esta cuenta de

usuario no existe ya, el programa de instalación la crea

automáticamente. Si especifica un usuario de dominio,

especifique el nombre en la forma nombre_dominio\

nombre_usuario. Si especifica un usuario local con el

mismo nombre que un usuario de dominio, primero el

Administrador debe crear manualmente el usuario

local y luego especificarlo en la forma

nombre_sistema\nombre_usuario. En los sistemas UNIX,

esta cuenta de usuario se debe crear manualmente

antes de ejecutar el programa de instalación. Cree un

usuario con un directorio inicial. IBM Tivoli Workload

Scheduler se instalará en el directorio inicial (HOME)

del usuario seleccionado. El valor predeterminado es

$(user_name).

domain Este parámetro es opcional, a menos que el usuario

sea un usuario de dominio cuando éste sea necesario.

Es el nombre de dominio del usuario. Si especifica un

usuario de dominio, especifique el nombre en la forma

nombre_dominio\ nombre_usuario. El valor

predeterminado es $(computer_name).

backup_dir Este parámetro opcional aparece cuando se está

realizando una actualización. Indica la ubicación en

donde se copiará la instalación actual antes de ser

actualizada. El valor predeterminado es

$(install_dir)_backup_$(tws_user).

create_user (sólo para Windows) Si no existe el usuario, este parámetro es obligatorio.

Especifique true si $(tws_user) aún no existe.

Asegúrese de que el usuario local no existe en el

dominio. El valor predeterminado es false.

check_user Este parámetro es obligatorio para los usuarios

existentes. Si create_user = true, el valor de check_user

no se tiene en cuenta. El valor predeterminado es true.

pwd (sólo para Windows) Este parámetro es obligatorio para las plataformas

Windows cuando se realiza la instalación por primera

vez. Es la contraseña asociada al nombre de usuario

tws_user.

st_agent

ft_agent

master

bkm_agent

Especifique true sólo para el tipo de agente que desea

instalar. El valor predeterminado es false.

Instalación de Software Distribution


Tabla 21. Parámetros de instalación de SPB (continuación)

Variable Descripción

company Este parámetro opcional es el nombre de la empresa.

Este nombre aparece en las cabeceras de programa e

informes. El valor predeterminado es COMPANY.

this_cpu Este parámetro obligatorio es el nombre de la estación

de trabajo en la que se está realizando la instalación.

Este nombre no puede tener más de 16 caracteres y no

puede contener espacios en blanco. El valor

predeterminado es THIS CPU.

master_cpu Este parámetro obligatorio es el nombre del gestor de

dominio maestro. Este nombre no puede tener más de

16 caracteres y no puede contener espacios en blanco.

Este valor es el mismo que this_cpu si está instalando

un gestor de dominio maestro. El valor

predeterminado es MASTER.

tcp_port Este parámetro obligatorio es el número de puerto

TCP que utiliza la instancia que se está instalando. Si

instala más de una instancia en la misma estación de

trabajo, utilice un número de puerto diferente para

cada instancia. Debe ser un valor no asignado, de 16

bits, comprendido dentro del rango de 1–65535. El

valor predeterminado es 31111.

fresh_install Este parámetro obligatorio indica si se trata de la

primera vez que se hace la instalación. Especifique

true para realizar una instalación nueva. Especifique

false para realizar una promoción o una actualización.

El valor predeterminado es true.

upgrade Este parámetro obligatorio indica si la instalación es

una actualización. Especifique false para realizar una

instalación u una promoción nueva. Especifique true

para realizar una actualización. El valor

predeterminado es false.

promote Este parámetro obligatorio indica si la instalación es

una promoción. Especifique true para realizar una

promoción y false para realizar una instalación o una

actualización nueva.

backup Este parámetro opcional indica una copia de

seguridad. Especifique false para realizar una

instalación nueva. El valor predeterminado es false.

group Este parámetro opcional indica el nombre del grupo

asignado durante la instalación de Tivoli Workload

Scheduler, Versión 8.1. Especifique este nombre al

realizar una actualización. El valor predeterminado es

TWS group.

Procedimiento de instalación

Para realizar la instalación, complete los pasos siguientes:

1. Defina el entorno Tivoli. Consulte el apartado “Detención del conector” en la

página 33.

2. Importe el bloque de paquetes de software utilizando el comando wimpspo.

3. Instale el bloque de paquetes de software utilizando el comando winstsp.


Capítulo 5. Instalación mediante Software Distribution 57

4. Ejecute una de las tareas de configuración siguientes, de acuerdo con el tipo de

agente que se ha instalado:

v “Configuración de un gestor de dominio maestro” en la página 79

v “Configuración de un agente tolerante a errores o un agente estándar” en la

página 80

v Para las instalaciones en UNIX, consulte también el apartado “Pasos de

configuración para instalaciones UNIX de Nivel 1 y Nivel 2” en la página 82.

Para obtener instrucciones completas sobre la realización de estas tareas, consulte

la explicación de wimpspo y winstsp en los manuales IBM Tivoli Configuration

Manager, Reference Manual for Software Distribution e IBM Tivoli Configuration

Manager, User’s Guide for Software Distribution.

El ejemplo siguiente muestra los valores necesarios para realizar una instalación

nueva de un gestor de dominio maestro en una estación de trabajo Windows,

cuando el usuario no está definido en la estación de trabajo.

winstsp –D install_dir="testB\TWS\juno" –D tws_user="juno"

[–D create_user="true" –D pwd="Password"]

{–D st_agent="false"|–D ft_agent="false"|–D master="true"|–D bkm_agent="false"}

–D this_cpu="saturn" –D master_cpu="saturn" –D tcp_port="3111"

{–D fresh_install="true" | –D upgrade="false" | –D promote="false"}

–D backup="false"

Tivoli_TWS_WINDOWS.spb [suscriptores...]

Algunas variables de este ejemplo se podrían omitir. Por ejemplo, si master = true,

la instalación no tendrá en cuenta los valores de los demás tipos de agentes. Por lo

tanto, las variables st_agent, ft_agent, bkm_agent se podrían omitir del comando, o

aunque se especificaran, sus valores no se tendrían en cuenta debido a que sus

valores predeterminados están establecidos en false.

Instalación de paquetes de idioma

Puede también instalar paquetes de idioma utilizando Software Distribution.

Localice el bloque de paquetes de software Tivoli_TWS_LP.SPB en el directorio raíz

del Disco 1 de instalación de IBM Tivoli Workload Scheduler, y luego personalice

los parámetros siguientes antes de instalar.



Tabla 22. Lista de parámetros para instalar paquetes de idioma

Variable

predeterminada

Descripción Necesario Valor

predeterminado

zh_CN

it

ko

es

zh_TW

ja

pt_BR

de

fr

ALL_LANG

Chino simplificado

Italiano

Coreano

Español

Chino tradicional

Japonés

Portugués brasileño

Alemán

Francés

Todos los idiomas

anteriores.

Especifique true para

los idiomas a instalar.

El valor

predeterminado de

los otros idiomas es

false.

false

tws_user Es el nombre de

usuario para el cual

se instala el paquete

de idioma

especificado.

Sí $(user_name)

install_dir Es la ruta calificada

al completo en la que

se instalan los

paquetes de idioma

especificados.

Sí $(program_files)


Capítulo 5. Instalación mediante Software Distribution 59

Esta es la sintaxis necesaria para instalar todos los idiomas:

winstsp -D install_dir="Installation Path" -D tws_user="UserName"

[-D zh_C =true ... -D de=true | ALL_LANG=true] Tivoli_TWS_LP.SPB [suscriptores...]

La sintaxis siguiente es la sintaxis necesaria para instalar los paquetes de idioma

italiano y alemán:

winstsp -D install_dir="Installation Path" -D tws_user="UserName"

[-D it =true | -D de=true] Tivoli_TWS_LP.SPB [suscriptores...]



Capítulo 6. Instalación mediante customize

Esta sección describe la utilización del script customize desde la línea de comandos

como método de instalación para las plataformas de Nivel 2. Consulte el manual

Tivoli Workload Scheduler Release Notes para obtener una lista de las plataformas de

Nivel 2 soportadas. Para las instalaciones de Nivel 1 desde la línea de comandos,

consulte el Capítulo 4, “Instalación y promoción mediante twsinst”, en la página

51.

El script customize

Utilice el script customize para instalar, actualizar y desinstalar Tivoli Workload

Scheduler en las plataformas de Nivel 2 a las que se da soporte.

Sinopsis

customize -new -thiscpu nombre_estación_trabajo -master nombre_estación_trabajo

[-company ″ nombre_empresa″] [-nolinks|-execpath nombre_ruta] [-uname

nombre_usuario][-port puerto netman]

customize -update[-company ″ nombre_empresa″] [-uname nombre_usuario]

Descripción

El script customize instala o actualiza Tivoli Workload Scheduler. Utilice este script

para realizar las funciones siguientes:

v Instalación nueva de Tivoli Workload Scheduler: Instalar Tivoli Workload

Scheduler. Crear un archivo de componentes con entradas nuevas.

v Actualizaciones de Tivoli Workload Scheduler: Actualizar Tivoli Workload

Scheduler, si es necesario. Actualizar entradas del archivo de componentes.

Utilice también este script para restaurar los valores predeterminados de

permisos, siempre que el archivo MAESTRO.TAR original no esté en el

directorio TWShome.

v Se registran datos sobre el proceso de instalación en un archivo denominado

customize.log. Puede encontrar este archivo en el mismo directorio desde donde

ejecuta el script customize.

Argumentos

-new Indica una instalación nueva.

-update

Indica una actualización de una instalación existente. Observe que la

actualización del software no cambia el tipo de las bases de datos

utilizadas por Tivoli Workload Scheduler.

-thiscpu

Es el nombre de la estación de trabajo. El nombre puede tener un máximo

de 16 caracteres alfanuméricos; se pueden utilizar el guión (-) y el signo de

subrayado (_) y el nombre debe comenzar con una letra. Este nombre se

debe utilizar más tarde para definir formalmente la estación de trabajo en



-master

Es el nombre del gestor de dominio maestro. El nombre puede tener un

máximo de 16 caracteres de longitud. Este nombre se debe utilizar más

tarde para definir formalmente la estación de trabajo en Tivoli Workload

Scheduler.

-company

Es el nombre de la empresa, delimitado por comillas dobles (con un

máximo de 40 caracteres). Este nombre aparece en las cabeceras de

programa e informes.

[-nolinks|-execpath nombre_ruta]

La opción de vínculos determina la ruta utilizada por customize para

establecer vínculos con los comandos de utilidad de Tivoli Workload

Scheduler. Si especifica -nolinks, no se crean vínculos. Si especifica

-execpath, se crean vínculos a partir de la ruta especificada. Si se omite

linkopt, se crean vínculos de esta manera:

usr/bin/mat twshome/bin/at

usr/bin/mbatch twshome/bin/batch

usr/bin/datecalc twshome/bin/datecalc

usr/bin/jobstdl twshome/bin/jobstdl

usr/bin/maestro twshome/bin/maestro

usr/bin/mdemon twshome/bin/mdemon

usr/bin/morestdl twshome/bin/morestdl

usr/bin/muser twshome/bin/muser

usr/bin/parms twshome/bin/parms

-uname

Es el nombre del usuario para el cual se instalará o actualizará Tivoli

Workload Scheduler. El nombre no debe contener puntos (.). El software de

TWS se instala o actualiza en el directorio inicial de este usuario. Si se

omite este parámetro, el nombre de usuario predeterminado es maestro.

-port Es el número del puerto TCP al cual responde Netman en la máquina

local. Debe ser un valor sin signo, de 16 bits, comprendido dentro del

rango 1-65535 (recuerde que los valores comprendidos entre 0 y 1023 están

reservados para los servicios conocidos públicamente, tales como FTP,

TELNET, HTTP, etc.). El valor predeterminado es 31111. Puede modificar

este valor en todo momento en el archivo de opciones local.

Instalación del motor de Tivoli Workload Scheduler

Siga las instrucciones para los sistemas de Nivel 2 si está instalando Tivoli

Workload Scheduler por primera vez, o si Tivoli Workload Scheduler se ha

desinstalado por completo. Para las plataformas de Nivel 1, consulte el Capítulo 3,

“Instalación mediante el asistente de instalación”, en la página 39.

Siga los pasos siguientes para instalar Tivoli Workload Scheduler en una

plataforma de Nivel 2.

1. Cree el usuario de Tivoli Workload Scheduler. El software se instala en el

directorio inicial del usuario, denominado TWShome.

Usuario:

TWSuser

Instalación de customize


Directorio inicial:

TWShome (por ejemplo: /opt/maestro)2. Monte el Disco 2 de instalación de IBM Tivoli Workload Scheduler.

a. Inicie la sesión como root, y cambie de directorio para ir a TWShome.

b. Extraiga el software:

tar -xvf cd2/plataforma/MAESTRO.TAR

Nota: Para la plataforma IBM-Sequent Numa (DYNIX), debe también

añadir la opción -o.

donde:

cd Es el nombre de ruta de la unidad de CD.

plataforma

Es el tipo de la plataforma utilizada. Puede ser uno de los

siguientes valores:

DYNIX para IBM-Sequent Numa

IRIX para SGI Irix

LINUX_PPC para SuSE Linux Enterprise Server para iSeries y

pSeries

OSF para Compaq True643. Ejecute el script customize. El script se ejecuta desde el directorio en el que se

quiere instalar el producto.

A continuación se muestra un script customize de ejemplo para una estación de

trabajo tolerante a errores:

/bin/sh customize -new -thiscpu dm1 -master mdm -uname twsuser [opciones]

Para obtener más información sobre los argumentos de customize y ver más

ejemplos, consulte el apartado El script customize en la página 61.

4. El proceso de instalación de Tivoli Workload Scheduler ha finalizado. Para

configurar la estación de trabajo en la red, consulte los apartados “Pasos de

configuración para instalaciones UNIX de Nivel 1 y Nivel 2” en la página 82 y

“Pasos de configuración para instalaciones de Nivel 2” en la página 83.

Después de finalizar la instalación, ejecute el comando StartUp para iniciar

Netman:

StartUp


Capítulo 6. Instalación mediante customize 63

Capítulo 7. Actualización de Tivoli Workload Scheduler

Puede actualizar un gestor de dominio maestro, un gestor de dominio, un agente

tolerante a errores y un agente estándar desde Tivoli Workload Scheduler Versión

7.0 y 8.1 a la versión 8.2 actual. Tivoli Workload Scheduler, Versión 8.2 da soporte a

la compatibilidad con versiones anteriores; por tanto, puede actualizar la red

gradualmente, en momentos diferentes y sin ningún orden determinado. Puede

realizar una actualización descendente (es decir, actualizar primero el maestro,

luego los gestores de dominio y finalmente los agentes tolerantes a errores), y

también realizar una actualización ascendente (es decir, comenzar con los agentes

tolerantes a errores y luego actualizar por orden, dejando el maestro para el final.

Pero si actualiza el maestro en primer lugar, algunas funciones nuevas de la

versión 8.2 (soporte de cortafuegos, seguridad centralizada) no funcionarán hasta

que actualice la red completa.

Durante el procedimiento de actualización, la instalación hace una copia de

seguridad de todos los datos del maestro y de la información de configuración,

instala el nuevo código de producto y migra automáticamente los datos de

planificación y de configuración antiguos. Sin embargo, no migra archivos de

usuario ni los directorios ubicados en el directorio TWShome. Consulte el apartado

“Archivos de copia de seguridad” en la página 34 para obtener más detalles.

Casos de actualización

La tabla siguiente describe casos de actualización que se pueden dar en la red, y

los pasos necesarios para actualizar a Tivoli Workload Scheduler, Versión 8.2

utilizando el programa de instalación.

Tabla 23. Actualización de Tivoli Workload Scheduler, Versión 8.2

Si actualmente está

instalado... Siga estos pasos... Consulte...

Tivoli Workload Scheduler,

Versiones 7.0 o 8.1 (no se

ha instalado el conector de

Tivoli Workload Scheduler

o Tivoli Plus Module)

Ejecute el programa de

instalación y realice una

actualización.

“Utilización del asistente de

instalación” en la página 66


Versiones 7.0 o 8.1

Tivoli Management

Framework, Versión 3.6.x


Connector, Versiones 7.0 o

8.1

1. Actualice a Tivoli

Management Framework,

Versión 4.1.

2. Ejecute el programa de


actualización.

Tivoli Enterprise Installation

Guide


instalación” en la página 66


Tabla 23. Actualización de Tivoli Workload Scheduler, Versión 8.2 (continuación)

Si actualmente está

instalado... Siga estos pasos... Consulte...


Versiones 7.0, 8.1

Tivoli Management

Framework, Versiones 3.7.1

o 4.1


Connector, Versiones 7.0 o

8.1

1. Ejecute el programa de


actualización. El

programa asistente

actualiza

automáticamente el

conector, si este está

configurado para el

agente seleccionado que

se debe actualizar.

2. Compruebe los requisito

previos de Tivoli

Management Framework.


instalación”

“Cuando ya está instalada una

versión soportada de Tivoli

Management Framework” en la

página 36

Actualización de Tivoli Workload Scheduler

Las secciones siguientes describen los procedimientos necesarios para actualizar la

instalación de Tivoli Workload Scheduler Versión 7.0 o 8.1 a Tivoli Workload

Scheduler, Versión 8.2. Estos procedimientos son los siguientes:

v “Utilización del asistente de instalación”

v “Ejecución de twsinst” en la página 70

v “Utilización del archivo de respuestas migrationInstall” en la página 72

v “Utilización de Software Distribution” en la página 73

v “Utilización de customize” en la página 73

Utilización del asistente de instalación

Puede actualizar un gestor de dominio maestro, un gestor de dominio, un agente

tolerante a errores y un agente estándar desde Tivoli Workload Scheduler Versión

7.0 y 8.1 a la versión 8.2 actual.

Durante el procedimiento de actualización, la instalación crea una copia de

seguridad de todos los datos del maestro y de la información de configuración,

instala el nuevo código de producto y migra automáticamente los datos de

planificación y de configuración antiguos.

Antes de realizar la actualización, asegúrese de que todos los procesos y servicios

de Tivoli Workload Scheduler estén detenidos. El programa de instalación detiene

los procesos de Tivoli Workload Scheduler que encuentra activos, pero si existen

trabajos en ejecución, el usuario debe detener manualmente los procesos asociados.

Para obtener información sobre la detención de los procesos y servicios, consulte el

apartado “Desvinculación y detención de Tivoli Workload Scheduler” en la página

32.


detener el conector antes de iniciar el proceso de actualización. Consulte el

apartado “Detención del conector” en la página 33.

Para realizar una actualización, siga estos pasos:

Actualización


1. Inserte el Disco 1 de instalación de IBM Tivoli Workload Scheduler. Para las

plataformas Linux, inserte el Disco 2 de instalación de IBM Tivoli Workload

Scheduler.


está realizando la actualización.


directorio de la plataforma en la que desea realizar la actualización.


raíz del CD de instalación. Para iniciar la actualización, ejecute el comando

siguiente:

./SETUP.bin [-is:tempdir <directorio_temporal>]

donde,

-is:tempdir <directorio_temporal>

Especifica un directorio temporal de trabajo en el que se copian

archivos y directorios de instalación. El valor predeterminado de

<directorio_temporal> es el directorio temporal definido en la

máquina local. Si utiliza el valor predeterminado, después del

proceso de instalación debe suprimir manualmente los archivos y

directorios siguientes que se han copiado en ese directorio:

– SETUP.jar

– TWS_size.txt

– media.inf

– Tivoli_TWS_LP.SPB

– directorio RESPONSE_FILE

– directorio TWS_CONN

– directorio TWSPLUS

– directorio denominado de acuerdo con el nombre del sistema

operativo

Si especifica un nombre diferente para el <directorio_temporal>,

suprima la carpeta cuando finalice el proceso de instalación. 3. Se inicia el asistente de instalación. Seleccione el idioma del asistente de

instalación. Haga clic en Aceptar.



6. En la lista desplegable, seleccione una instalación existente de un release

anterior del producto para el cual desee realizar la actualización. La instancia

se puede identificar por su nombre de grupo.

7. El botón de selección Actualizar la instancia seleccionada se selecciona de

forma predeterminada. Haga clic en Siguiente. En Windows, compruebe el

nombre de usuario y escriba la contraseña asociada al usuario.

8. Revise el usuario de Tivoli Workload Scheduler para el que se realizará la

actualización. Haga clic en Siguiente.

9. Revise la ubicación de la instalación para la estación de trabajo y haga clic en

Siguiente.

10. Seleccione el tipo de agente para el que desea realizar la actualización y haga

clic en Siguiente. Compruebe que el tipo seleccionado corresponde a la

instancia que se ha seleccionado para actualizar.

11. Revise la información de datos de CPU y haga clic en Siguiente.

Actualización

Capítulo 7. Actualización de Tivoli Workload Scheduler 67

12. Revise los valores de instalación y haga clic en Siguiente. La actualización ha

comenzado.

13. Cuando la instalación finaliza satisfactoriamente, se muestra un panel para

indicarlo. Si una instalación no se realiza satisfactoriamente, consulte el

archivo de registro indicado.

14. Haga clic en Finalizar.

Utilización de twsinst

Puede actualizar mediante el script twsinst. Si pretende hacer una copia de

seguridad manualmente antes de hacer la instalación, primero debería leer el

apartado “Creación de una copia de seguridad antes de ejecutar el script” antes de

iniciar la actualización.

Creación de una copia de seguridad antes de ejecutar el script

Las dos nuevas opciones de copia de seguridad, -backup_dir y -nobackup, se han

distribuido en un arreglo GA incluido en el paquete del fix pack 3. El arreglo está

ubicado en el directorio GA_fixes del CD_1, se denomina APAR IY48550 y hay que

aplicarlo directamente a la versión GA (General Availability) de IBM Tivoli

Workload Scheduler 8.2. Debido a un error de documentación, el arreglo no

aparece listado dentro del contenido del CD en el readme del fix pack 3. Las notas

siguientes se aplican a las nuevas opciones:

v El propósito de -nobackup es permitir al usuario que elija entre ejecutar la copia

de seguridad de la instalación IBM Tivoli Workload Scheduler anterior

manualmente o dejar que el proceso twsinst lo haga automáticamente. El

propósito de -backup_dir es que el usuario pueda especificar un directorio para

hacer la copia de seguridad distinto del predeterminado. Las dos opciones

también pueden utilizarse a la vez. En función de cómo se utilicen, existen

cuatro acciones posibles:

Actualización


Tabla 24. Utilización de las opciones de copia de seguridad de twsinst

Si se especifica... Los resultados son...

-nobackup Deberá ejecutar la copia de seguridad

manualmente en el directorio de copia de

seguridad predeterminado (consulte el

apartado Instalación y promoción en la

página 51).

-nobackup y -backup_dir Deberá ejecutar la copia de seguridad

manualmente en el directorio de copia de

seguridad que el usuario especifique.

Nada twsinst ejecuta automáticamente la copia de

seguridad en el directorio de copia de

seguridad predeterminado (consulte el

apartado Instalación y promoción en la

página 51).

-backup_dir twsinst ejecuta automáticamente la copia de

seguridad en el directorio de copia de

seguridad que el usuario especifique.

v La razón principal para utilizar la opción -nobackup es que el usuario prefiera él

mismo hacer la copia de seguridad de la instalación anterior. Dicha copia de

seguridad es importante porque twsinst la utiliza para recuperar y transferir

algunos de los valores de personalización desde la instalación anterior a la

nueva. Por ello, si utiliza esta opción, para garantizar que el proceso de

migración finaliza correctamente el paso de personalización, siga los pasos

siguientes antes de ejecutar twsinst:

1. Detenga todos los procesos IBM Tivoli Workload Scheduler.

2. Cree el directorio de copia de seguridad que necesita el paso de

personalización durante el proceso de migración. Tanto si también utiliza la

opción -backup_dir, como si utiliza la opción predeterminada (consulte el

apartado Instalación y promoción en la página 51), cree manualmente este

directorio.

3. Ejecute el comando siguiente:

chmod -R 755 $BACKUP_DIR

4. Haga lo siguiente para guardar el mínimo conjunto de directorios/archivos

de IBM Tivoli Workload Scheduler que necesita el paso de personalización en

el directorio$BACKUP_SUBDIR:

a. Traslade los directorios/archivos siguientes:

– $INST_DIR/bin

– $INST_DIR/Security

b. Copie los directorios/archivos siguientes (utilice el comando cp -p ...

para preservar los derechos correctos):

– $INST_DIR/catalog

– $INST_DIR/methods

– $INST_DIR/mozart/globalopts

– $INST_DIR/Tbsm

– $INST_DIR/Symphony

– $INST_DIR/parameters

– $INST_DIR/parameters.KEY

– $INST_DIR/Jobtable

– $INST_DIR/Jobmanrc

Actualización


– $INST_DIR/localopts

– $INST_DIR/BmEvents.conf, si TBSM está personalizado

– $INST_DIR/MAgent.conf, si TBSM está personalizado

– $INST_DIR/CLEvents.conf, si TBSM está personalizado

– /usr/unison/components

Nota: Estos son los archivos que se copian cuando se hace una copia de

seguridad automática. Puede hacer copias de seguridad de todos

los archivos que desee conservar.5. Traslade $INST_DIR/../unison al directorio $BACKUP_DIR para crear su copia

de seguridad.

6. Ejecute twsinst -update ... -nobackup para iniciar el proceso de migración.

7. Verifique que el proceso de migración se ha completado correctamente y

suprima $BACKUP_DIR.v Si no especifica -nobackup, la copia de seguridad se crea automáticamente (en el

directorio de copia de seguridad que se especifica con -backup_dir; de lo

contrario, en el directorio de copia de seguridad predeterminado). El proceso

realiza lo siguiente de forma automática:

1. Crea el archivo TWS82bck_$TWSuser_PID.tar bajo el directorio de copia de

seguridad a partir de la lectura de la lista filelist_bck82. Si este paso falla, se

visualiza un mensaje y el proceso se detiene; si se completa de forma

correcta, el archivo .tar se comprime.

2. Copia todos los archivos/directorios necesarios para el paso de

personalización y el archivo actual /usr/unison/components en el directorio

de copia de seguridad.

Si falla el proceso de migración, el procedimiento de retrotracción restaurará los

archivos a partir del archivo .tar guardado.

Ejecución de twsinst

Utilice este procedimiento para actualizar una instalación existente de IBM Tivoli

Workload Scheduler versión 7.0 o 8.1 a la versión 8.2, en las plataformas de Nivel

1. El procedimiento también instala todos los paquetes de idioma soportados. Este

procedimiento utiliza el método de línea de comandos para actualizar mediante el

script twsinst. Consulte el manual Tivoli Workload Scheduler Release Notes para

obtener una lista de las plataformas de Nivel 1 a las que se da soporte. Para las

instalaciones de Nivel 2 desde la línea de comandos, consulte el Capítulo 6,

“Instalación mediante customize”, en la página 61.


de Tivoli Workload Scheduler estén detenidos. El asistente de instalación detiene

los procesos de Tivoli Workload Scheduler que encuentra activos, pero si existen

trabajos en ejecución, el usuario debe detener manualmente los procesos asociados.

Para obtener información sobre la detención de los procesos y servicios, consulte el

apartado “Desvinculación y detención de Tivoli Workload Scheduler” en la página

32.

Siga los pasos siguientes para actualizar una instalación de la versión 7.0 o 8.1 a

Tivoli Workload Scheduler, Versión 8.2 utilizando el script twsinst.


2. Inicie la sesión como root, y cambie de directorio para ir a TWShome.

3. Localice el directorio de la plataforma en la que desea ejecutar el script y

ejecute el script twsinst de esta manera:

Actualización


twsinst -update -uname <nombre_usuario>

-cputype {master | bkm_agent | ft_agent | st_agent}

[-inst_dir <dir_inst>]

[-backup_dir <dir_copia_seguridad>]

[-nobackup]

[-lang <id_idioma>]

Nota: Las opciones siguientes sólo están disponibles si se ha aplicado el arreglo

para APAR IY48550 incluido en el fix pack 3 para el paquete de la

Versión 8.2:

v -backup_dir <dir_copia_seguridad>

v -nobackup

-update

Actualiza una instalación existente. También instala todos los paquetes de

idioma soportados. Sólo están soportadas las instalaciones de las versiones

7.0 y 8.1 del producto. La actualización del software no modifica el tipo de

bases de datos utilizadas por Tivoli Workload Scheduler. Consulte el

Capítulo 7, “Actualización de Tivoli Workload Scheduler”, en la página 65

para obtener más información sobre la actualización y consulte el apartado

“Ejecución de twsinst” en la página 70.

-cputype

Especifica el tipo de agente de Tivoli Workload Scheduler a instalar. Los

valores válidos son:

v master

v bkm_agent (maestro de copia de seguridad)

v ft_agent (agente tolerante a errores, gestor de dominio, gestor de

dominio de reserva)

v st_agent (agente estándar)

Si no se especifica un valor, el valor predeterminado es ft_agent. Cuando

-cputype=master, -master se establece de forma predeterminada en el

mismo valor que -thiscpu.

-master <nombre_cpu_maestro>

Es el nombre de la estación de trabajo del gestor de dominio maestro. Este

nombre no puede tener más de 16 caracteres y no puede contener espacios

en blanco. Este nombre está registrado en el archivo globalopts. Si no se

especifica un valor, el valor predeterminado es MASTER. Consulte el


Scheduler Release Notes para conocer las restricciones existentes.

-inst_dir <dir_instalación>

Es el directorio de la instalación de Tivoli Workload Scheduler. Esta ruta no

puede contener espacios en blanco. Si no se especifica un valor, la ruta

utilizada es el directorio inicial de nombre_usuario.

-backup_dir<backup_dir>

Puede utilizarse para especificar el nombre de un directorio alternativo

(que debe crearse manualmente) como destino de la copia de seguridad de

una versión anterior. Esta opción puede utilizarse en combinación con

-nobackup.

Si no se especifica esta opción cuando se ejecuta una actualización, se

utilizará el siguiente valor predeterminado:

$BACKUP_DIR = $INST_DIR_backup_$TWS_USER

donde:

Actualización


v $INST_DIR es la ruta de instalación de IBM Tivoli Workload Scheduler (el

nombre del directorio de inicio en UNIX).

v $TWS_USER es el nombre de usuario de IBM Tivoli Workload Scheduler.

Por ejemplo:

$INST_DIR=/opt/TWS/TWS81

$TWS_USER=maest81

$BACKUP_DIR=/opt/TWS/TWS81_backup_maest81

$BACKUP_SUBDIR=/opt/TWS/TWS81_backup_maest81/TWS81

En el directorio de copia de seguridad, también tiene que crear un

subdirectorio denominado como el último directorio de la ruta de

instalación.

-nobackup

Inhabilita la copia automática de la versión IBM Tivoli Workload Scheduler

anterior al ejecutar una actualización. Esta opción puede utilizarse en

combinación con -backup_dir.

-lang <id_idioma>

El idioma en el que se visualizan los mensajes twsinst. Si no se especifica

un valor, se utiliza el idioma del sistema (LANG). Si falta el catálogo

asociado, se utiliza el catálogo de idioma predeterminado C.


soportados de Tivoli Workload Scheduler. De forma predeterminada,

todos los paquetes de idioma soportados se instalan cuando se hace

la instalación mediante el script twsinst.Por ejemplo, este es un script twsinst de muestra para actualizar un agente

tolerante a errores de Tivoli Workload Scheduler, Versión 7.0 y obtener una

estación de trabajo de agente tolerante a errores de la Versión 8.2:

./twsinst -update -uname twsuser -cputype ft_agent

Utilización del archivo de respuestas migrationInstall

El archivo de respuestas proporcionado le permite ejecutar el programa asistente

de instalación en la modalidad desatendida, sin tener que ejecutar el asistente en la

modalidad gráfica. Puede actualizar Tivoli Workload Scheduler utilizando el

archivo de respuestas migrationInstall.txt proporcionado en el Disco 1 de

instalación de IBM Tivoli Workload Scheduler, en la ruta siguiente:

\RESPONSE_FILE\migrationInstall.txt.


de Tivoli Workload Scheduler estén detenidos. Para obtener información sobre la

detención de los procesos y servicios, consulte el apartado “Desvinculación y



detener el conector antes de iniciar el proceso de actualización. Consulte el

apartado “Detención del conector” en la página 33.

Copie el archivo de respuestas en un directorio local y edite el archivo de acuerdo

con las necesidades de su entorno de actualización particular. Las instrucciones

para personalizar los archivos de respuestas están incluidas en los propios

archivos, en forma de comentarios. Para iniciar la actualización en la modalidad

desatendida, escriba este comando:

v En UNIX,

Actualización


./SETUP.bin -options <dir_local>/migrationInstall.txt

v En Windows,

SETUP.exe -options <dir_local>\migrationInstall.txt

Utilización de Software Distribution

El bloque de paquetes de software utiliza varios parámetros de Tivoli Workload

Scheduler para realizar la actualización. El usuario debe asignar a cada variable los

valores correctos que sean representativos de la instalación que se está

actualizando; de lo contrario se asignará el valor predeterminado. Estos parámetros

están definidos como variables predeterminadas en el paquete de software. Para

obtener una lista de parámetros, consulte la Tabla 21 en la página 56.





Para realizar la actualización, siga estos pasos:

1. Defina el entorno Tivoli. Consulte el apartado “Detención del conector” en la

página 33.

2. Importe el bloque de paquetes de software utilizando el comando wimpspo.

3. Instale el bloque de paquetes de software utilizando el comando winstsp.

Para obtener instrucciones completas sobre la realización de estas tareas, consulte

los manuales IBM Tivoli Configuration Manager, Reference Manual for Software

Distribution e IBM Tivoli Configuration Manager, User’s Guide for Software Distribution.

El ejemplo siguiente muestra los valores necesarios para actualizar un gestor de

dominio maestro de Tivoli Workload Scheduler versión 8.1 a Tivoli Workload

Scheduler versión 8.2 en un sistema Windows.

winstsp –D install_dir="d:\win32app\TWS\juno" –D tws_user="juno"

{–D st_agent="false"|–D ft_agent="false"|–D master="false"|–D bkm_agent="false"}

–D this_cpu="saturn" –D master_cpu="saturn" –D tcp_port="3111"

{–D fresh_install="false" | –D upgrade="true" | –D promote="false"}

–D backup="true" –D group="TWS81group"

Tivoli_TWS_WINDOWS.spb [suscriptores...]

Utilización de customize





Nota: Consulte el manual Tivoli Workload Scheduler Release Notes para obtener

información adicional sobre la actualización de software existente.

El script customize traslada el directorio de métodos a un directorio denominado

twshome/config.old. A menudo estos archivos se personalizan de acuerdo con las

necesidades específicas del usuario; puede utilizar las copias guardadas para

incorporar los cambios una vez hecha la actualización. El script customize no

sobrescribirá ninguno de los archivos del directorio stdlist que se modificaron

después de la instalación de Tivoli Workload Scheduler.

Actualización


Si existe cualquier otro archivo que desee proteger durante la actualización, copie

los archivos o renómbrelos ahora. Como medida de precaución adicional, debería

también crear una copia de seguridad de lo siguiente:

v El directorio TWShome.

v El archivo components (normalmente, /usr/unison/components)

Para actualizar mediante el script customize, realice los pasos siguientes:

1. Monte el Disco 2 de instalación de IBM Tivoli Workload Scheduler.

a. Inicie la sesión como root, y cambie de directorio para ir a twshome.

b. Extraiga el software:

tar -xvf cd2/plataforma/MAESTRO.TAR

donde:

cd Es el nombre de ruta de la unidad de CD.

plataforma

Es el tipo de la plataforma utilizada. Puede ser uno de los

siguientes valores:

DYNIX para IBM-Sequent Numa

IRIX para SGI Irix

LINUX_PPC para SuSE Linux Enterprise Server para iSeries y

pSeries

OSF para Compaq True64

Actualización


2. Ejecute el script customize .

A continuación se muestra un script customize de ejemplo para una estación de

trabajo de agente tolerante a errores:

/bin/sh customize -update -uname name [opciones]

Para obtener más información sobre los argumentos de customize y ver más

ejemplos, consulte el apartado El script customize en la página 61.

Actualización


Actualización


Parte 4. Configuración

Capítulo 8. Después de la instalación . . . . . 79

Netman . . . . . . . . . . . . . . . 79

Configuración de un gestor de dominio maestro . . 79

Configuración de un gestor de conmutación

tolerante a errores . . . . . . . . . . . . 80

Configuración de un agente tolerante a errores o un

agente estándar . . . . . . . . . . . . . 80

Actualización del archivo de seguridad . . . . . 82

Pasos de configuración para instalaciones UNIX de

Nivel 1 y Nivel 2 . . . . . . . . . . . . 82

Pasos de configuración para instalaciones de Nivel 2 83

Configuración de un agente tolerante a errores

después de la instalación . . . . . . . . . 83

Habilitación de la función de huso horario . . . . 84

Habilitación del huso horario en una red global 86

Capítulo 9. Personalización opcional . . . . . 87

Opciones globales . . . . . . . . . . . . 87

Definición de las opciones globales . . . . . 87

Ejemplo de archivo de opciones globales . . 91

Opciones de traspaso . . . . . . . . . . 91

Opciones locales . . . . . . . . . . . . . 92

Definición de las opciones locales . . . . . . 92

Ejemplo de archivo de opciones locales . . . 100

Configuración de la administración descentralizada 102

Compartimiento de los directorios del maestro 102

Compartimiento de parámetros de Tivoli


Utilización de un sólo compartimiento . . . . 102

Definición de las opciones locales . . . . . 103

Definición de las opciones locales en el maestro 103

Mensajes de consola y mensajes de solicitud de

Tivoli Workload Scheduler . . . . . . . . . 104

Definición de sysloglocal en UNIX . . . . . 104

El comando console . . . . . . . . . . 105

Automatización del ciclo de producción . . . . 105

Personalización de la secuencia de trabajos final 106

Inicio de un ciclo de producción . . . . . . 106

Gestión del entorno de producción . . . . . . 106

Elección del inicio del día . . . . . . . . 106

Cambio del inicio del día . . . . . . . . 107

Creación de un plan para fechas futuras o

pasadas . . . . . . . . . . . . . . 107

Utilización de los scripts de configuración . . . . 108

Variables de entorno de Jobman . . . . . . 108

Script de configuración estándar - jobmanrc . . 109

Script de configuración local - .jobmanrc . . . 111

Tivoli Workload Scheduler y Tivoli Management

Framework . . . . . . . . . . . . . . 113

Tivoli Management Framework para usuarios

que no utilizan Tivoli . . . . . . . . . . 113

Adición de administradores de Tivoli . . . . 114

Consideraciones sobre el maestro de copia de

seguridad . . . . . . . . . . . . . . 116

Maestros que no dan soporte a Tivoli


Traslado del maestro de copia de seguridad 117

Creación de un maestro de copia de

seguridad . . . . . . . . . . . . . 117

Montaje de bases de datos del gestor de

dominio maestro . . . . . . . . . . 118

Capítulo 10. Integración con otros productos de

IBM Tivoli . . . . . . . . . . . . . . 121

Integración con IBM Tivoli Enterprise Data

Warehouse . . . . . . . . . . . . . . 121

Integración con IBM Tivoli NetView . . . . . . 121

General . . . . . . . . . . . . . . 121

Cómo funciona Tivoli Workload


Tipos de información . . . . . . . . . 122

Definiciones . . . . . . . . . . . . 122

Requisitos generales . . . . . . . . . 123

Configuración . . . . . . . . . . . 123

Instalación del software de integración . . . . 124

Ejecución del script customize . . . . . . 124

Instalación . . . . . . . . . . . . 125

Configuración . . . . . . . . . . . . 126

Objetos, símbolos y submapas . . . . . . . 128

Estado de los símbolos de Tivoli Workload


Correlación de agentes ampliados . . . . 130

Acciones del menú . . . . . . . . . . 130

Cambio de los comandos . . . . . . . 131

Eventos de Tivoli Workload Scheduler/NetView 132

Sondeo y condiciones de excepción de SNMP 134



El archivo de configuración BmEvents . . . 135

El archivo de configuración MAgent . . . . 136

Supervisión de procesos writer y servidores 138



Frecuencia de exploración de los agentes . . 138

Frecuencia de sondeo del gestor . . . . . 138

Configuración de agentes en NetView . . . 139

Configuración del estado de la estación de

trabajo en NetView . . . . . . . . . 139

MIB de Unison Software . . . . . . . . 140

Cómo volver a configurar condiciones de

excepción específicas de empresa . . . . . 140



Sinopsis de mdemon . . . . . . . . . 143

Sinopsis de magent . . . . . . . . . 144

Integración con IBM Tivoli Business Systems

Manager . . . . . . . . . . . . . . . 145

General . . . . . . . . . . . . . . 145

Utilización del mecanismo del indicador clave 146

Definición del indicador clave . . . . . . 146

Instalación y actualización del agente de

escucha común . . . . . . . . . . . . 147


Personalización de los archivos de configuración 148

Personalización de BmEvents.conf . . . . 149

Personalización de ClEvents.conf . . . . . 149

Inicio y detención del agente de escucha común 150

Eventos de Tivoli Workload Scheduler/IBM

Tivoli Business Systems Manager . . . . . . 150

Capítulo 11. Definición de la seguridad . . . . 153

Definición de una autenticación y un cifrado

estrictos . . . . . . . . . . . . . . . 153

Conceptos clave de SSL . . . . . . . . . 154

Planificación del soporte de SSL en Tivoli


Configuración del soporte de SSL en Tivoli


Configuración de claves privadas y

certificados . . . . . . . . . . . . 158

Creación de una autoridad de certificación

propia . . . . . . . . . . . . . . 159

Creación de claves privadas y certificados 160

Configuración de atributos de SSL . . . . 161

Definición de las opciones locales de SSL . . 162

Cómo trabajar con cortafuegos . . . . . . . 164

Capítulo 12. Desinstalación de Tivoli Workload

Scheduler . . . . . . . . . . . . . . 167

Utilización del asistente de desinstalación . . . . 167

Utilización del script twsinst . . . . . . . . 167

Utilización de la CLI de Software Distribution . . 168

Utilización del script customize . . . . . . . 168


Capítulo 8. Después de la instalación

Este capítulo describe tareas de configuración que puede ser necesario realizar al

final del procedimiento de instalación que ha seguido. Cada procedimiento

descrito le indicará las tareas si son necesarias.

Netman

Al final de la instalación, se inicia automáticamente el proceso Netman. De esta

manera se puede controlar si el proceso de instalación ha sido satisfactorio.

Configuración de un gestor de dominio maestro

Una vez instalado un gestor de dominio maestro, con independencia del método

de instalación utilizado, debe añadir la secuencia de trabajos final a la base de

datos y ejecutar Jnextday. Esta secuencia de trabajos se coloca en producción todos

los días, y da como resultado la ejecución de un trabajo denominado Jnextday

antes del inicio de un nuevo día. La instalación crea un archivo Sfinal en el

directorio TWShome de la estación de trabajo que contiene la definición de la

secuencia de trabajos final. Puede utilizar este archivo Sfinal o crear y personalizar

uno nuevo. Consulte el apartado “Automatización del ciclo de producción” en la

página 105 para obtener detalles sobre la personalización de la secuencia de

trabajos final.

El ejemplo siguiente muestra cómo configurar un gestor de dominio maestro

después de la instalación:

1. Para ejecutar comandos tales como conman o composer, debe definir las

variables PATH y TWS_TISDIR. La variable TWS_TISDIR permite a Tivoli

Workload Scheduler visualizar mensajes utilizando el idioma y juego de

códigos correcto.

v En los sistemas Windows, edite la variable del sistema PATH para que

incluya TWShome y TWShome\bin. Por ejemplo, si Tivoli Workload Scheduler

se ha instalado en el directorio c:\win32app\TWS\jdoe, la variable PATH

debe incluir lo siguiente:

PATH=\win32app\TWS\jdoe;\win32app\TWS\jdoe\bin

Cree la variable de entorno TWS_TISDIR y asigne TWShome como valor. De

esta manera, se definen las variables de entorno y rutas de búsqueda

necesarias para poder ejecutar comandos aunque el usuario no se encuentre

situado en la ruta TWShome. Como alternativa, puede ejecutar el script de

shell tws_env.cmd para definir tanto la variable PATH como TWS_TISDIR.

Nota: Si tiene de más de una versión de IBM Tivoli Workload Scheduler

instalada en el sistema, asegúrese de que TWS_TISDIR apunte a la

última versión. Esto garantiza que se utilizarán las tablas de

conversión de juegos de caracteres más recientes.

v Para los sistemas UNIX, vea el paso 1 en la página 83 en el apartado “Pasos

de configuración para instalaciones UNIX de Nivel 1 y Nivel 2” en la página

82.2. Inicie la sesión como TWSuser.

3. Ejecute el comando composer.


4. Añada la definición de la secuencia de trabajos final a la base de datos

ejecutando este comando:

composer add Sfinal

Si no se ha utilizado el archivo Sfinal proporcionado con la instalación, sino

que se ha creado un archivo nuevo, utilice el nombre de este último en lugar

de Sfinal.

5. Salga de la línea de comandos de composer.

6. Ejecute el trabajo Jnextday:

Jnextday

Puede automatizar este paso después de instalar por primera vez. Consulte el

apartado “Automatización del ciclo de producción” en la página 105 para

obtener detalles.

7. Cuando finalice el trabajo Jnextday, compruebe el estado de Tivoli Workload

Scheduler:

conman status

Si Tivoli Workload Scheduler se ha iniciado correctamente, el estado es

Batchman=LIVES.

8. Aumente el límite para permitir la ejecución de trabajos. El límite de trabajos

predeterminado después de la instalación está establecido en 0. Esto significa

que no se ejecutará ningún trabajo, por lo que puede aumentar el límite de

trabajos ahora:

conman "limit;10"

Configuración de un gestor de conmutación tolerante a errores

Para habilitar la función, siga estos pasos:

1. Abra el archivo <TWShome>/mozart/globalopts en el gestor de dominio maestro.

2. Añada la línea enable switch fault tolerance = yes en la parte inferior.

3. Guarde y cierre el archivo.

4. La función estará activa desde el siguiente trabajo Jnextday.

En la funcionalidad global, se ha introducido un parámetro nuevo en la sentencia

TOPOLOGY:

ENABLESWITCHFT (Y/N)

ftbox es una cola de mensajes cíclica donde cada agente de estado completo

almacena los mensajes que enviaría si actuara como gestor de dominio. Cuando la

cola se llena, los mensajes nuevos sobrescriben a los antiguos, desde el principio.

Es posible modificar el tamaño de ftbox como se hace con cualquier otra cola de

mensajes, utilizando el comando evtsize.

Configuración de un agente tolerante a errores o un agente estándar

Una vez instalado un agente tolerante a errores o un agente estándar, con

independencia del método de instalación utilizado, debe definir la estación de

trabajo en el maestro y vincular la estación de trabajo desde el maestro. Puede

ejecutar esta tarea utilizando Job Scheduling Console o la interfaz de línea de

comandos. Consulte el manual Tivoli Workload Scheduler Job Scheduling Console -

Después de la instalación


Guía del usuario para obtener más información. El ejemplo siguiente muestra cómo

configurar un agente tolerante a errores después de una instalación desde la línea

de comandos:

1. Para ejecutar comandos tales como conman o composer, debe definir las

variables PATH y TWS_TISDIR. La variable TWS_TISDIR permite a Tivoli

Workload Scheduler visualizar mensajes utilizando el idioma y juego de

códigos correcto.

v En los sistemas Windows, edite la variable del sistema PATH para que

incluya TWShome y TWShome\bin. Por ejemplo, si Tivoli Workload Scheduler

se ha instalado en el directorio c:\win32app\TWS\jdoe, la variable PATH

debe incluir lo siguiente:

PATH=\win32app\TWS\jdoe;\win32app\TWS\jdoe\bin

Cree la variable de entorno TWS_TISDIR y asigne TWShome como valor. De

esta manera, se definen las variables de entorno y rutas de búsqueda

necesarias para poder ejecutar comandos aunque el usuario no se encuentre

situado en la ruta TWShome. Como alternativa, puede ejecutar el script de

shell tws_env.cmd para definir tanto la variable PATH como TWS_TISDIR.

Nota: Si tiene de más de una versión de IBM Tivoli Workload Scheduler

instalada en el sistema, asegúrese de que TWS_TISDIR apunte a la

última versión. Esto garantiza que se utilizarán las tablas de

conversión de juegos de caracteres más recientes.

v Para los sistemas UNIX, vea el paso 1 en la página 83 en el apartado “Pasos

de configuración para instalaciones UNIX de Nivel 1 y Nivel 2” en la página

82.2. Inicie la sesión en el gestor de dominio maestro como TWSuser.

3. Cree la definición de la estación de trabajo para un agente tolerante a errores

en la base de datos de Tivoli Workload Scheduler, utilizando la línea de

comandos de composer. Abra una ventana de línea de comandos y entre estos

comandos:

composer

new

4. Esto abrirá un editor de textos donde puede crear la definición de la estación

de trabajo en la base de datos de Tivoli Workload Scheduler para un agente

tolerante a errores. El ejemplo siguiente muestra una definición de estación de

trabajo para un agente tolerante a errores. Para obtener más información sobre

las definiciones de estación de trabajo, consulte el manual Tivoli Workload

Scheduler - Guía de consulta.

cpuname DM1

os UNIX

node domain1

description "Agente tolerante a errores"

for Maestro

autolink off

end

5. El agente tolerante a errores recién definido no se reconoce hasta que el trabajo

Jnextday se ejecuta en la secuencia de trabajos final. Si desea incorporar antes el

agente tolerante a errores, puede ejecutar conman ″release final″. Para obtener

información sobre la definición de objetos de planificación, consulte el manual

Tivoli Workload Scheduler - Guía de consulta.

6. Ejecute el comando link desde el gestor de dominio maestro para vincular el

agente tolerante a errores y descargar en él el archivo Symphony:

conman “link nombre_agente_tolerante_a_errores”



Actualización del archivo de seguridad

Cuando se lleva a cabo una instalación completa, el procedimiento de instalación

crea automáticamente un administrador de Tivoli denominado TWS_TWSuser,

edita los nombres de inicio de sesión del administrador con el nombre de usuario

de Tivoli Workload Scheduler y actualiza el archivo de seguridad con el

administrador de Tivoli. Sin embargo, si ha realizado una operación de agregar

función, instalando el conector en una instalación existente, debe actualizar el

archivo de seguridad manualmente.

Siga los pasos siguientes para añadir al archivo de seguridad del planificador el

Administrador de Tivoli (TWS_TWSuser) creado durante el procedimiento de

instalación con el nombre de inicio de sesión del planificador.

1. Inicie la sesión como usuario (habitualmente TWSuser o maestro).

2. Cambie de directorio para ir a TWShome.

3. Ejecute el comando dumpsec para crear una copia temporal editable del

archivo de seguridad:

dumpsec >tempsec

4. Edite el archivo tempsec para insertar el nombre del Administrador dentro de

la cabecera USER MAESTRO, tal como se describe en el ejemplo siguiente:

USER MAESTRO

CPU=@+LOGON=tws82,root,TWS_TWSuser

donde TWS_TWSuser es el nombre del Administrador.

Nota: Para obtener el nombre del Administrador, abra el escritorio de Tivoli y

haga doble clic en Administradores. El nombre del Administrador es el

grupo de Administradores al que pertenece su nombre de inicio de

sesión.

5. Defina el entorno Tivoli:

Desde una línea de comandos de UNIX:

v Para ksh:

. /etc/Tivoli/setup_env.sh

v Para csh:

source /etc/Tivoli/setup_env.sh

6. Entre el comando siguiente para detener el conector:

v En UNIX

wmaeutil.sh ALL -stop

v En Microsoft Windows

wmaeutil.cmd ALL -stop

7. Ejecute el comando makesec para compilar el archivo temporal y obtener un

nuevo archivo de seguridad:

makesec tempsec

Para obtener más información sobre los comandos makesec y dumpsec, consulte el

manual IBM Tivoli Workload Scheduler - Guía de consulta.

Pasos de configuración para instalaciones UNIX de Nivel 1 y Nivel 2

Para las instalaciones en plataformas UNIX de Nivel 1 y Nivel 2, realice las tareas

de configuración siguientes.



1. Cree un archivo .profile para el TWSuser, si no existe ya uno

(TWShome/.profile). Edite el archivo y modifique la variable PATH para incluir

TWShome y TWShome/bin. Por ejemplo, si Tivoli Workload Scheduler se ha

instalado en el directorio /opt/maestro, en el entorno del shell Bourne/Korn, la

variable PATH debe definirse de esta manera:

PATH=/opt/maestro:/opt/maestro/bin:$PATH

export PATH

Además de PATH, debe también establecer la variable TWS_TISDIR en el valor

TWShome. La variable TWS_TISDIR permite a Tivoli Workload Scheduler

visualizar mensajes utilizando el idioma y juego de códigos correcto. Por

ejemplo,

TWS_TISDIR=/opt/maestro

export TWS_TISDIR

De esta manera, se definen las variables de entorno y rutas de búsqueda

necesarias para poder ejecutar comandos, tales como conman o composer,

aunque el usuario no se encuentre situado en la ruta TWShome. Como

alternativa, puede ejecutar el script de shell tws_env para definir tanto la

variable PATH como TWS_TISDIR. Debe definir estas variables para poder

ejecutar comandos. Se proporcionan dos versiones del script tws_env:

v tws_env.sh para los entornos de shell Bourne y Korn

v tws_env.csh para los entornos de shell C

Vea el paso 1 en la página 79 dentro del apartado “Configuración de un gestor

de dominio maestro” en la página 79 para obtener información sobre el script

tws_env para los sistemas Windows.

2. Para iniciar automáticamente como daemon el proceso de gestión de red de

Tivoli Workload Scheduler, Netman, cada vez que inicie el sistema, añada una

de las especificaciones siguientes al archivo /etc/rc, o al archivo apropiado

para su sistema. Para iniciar Netman solamente:

if [-x twshome/StartUp]

then

echo "netman iniciado..."

/bin/su - twsuser -c " twshome/StartUp"

fi

O bien, para iniciar el árbol de procesos completo de Tivoli Workload

Scheduler:

if [-x twshome/bin/conman]

then

echo "Workload Scheduler iniciado..."

/bin/su - twsuser -c " twshome/bin/conman start"

fi

Pasos de configuración para instalaciones de Nivel 2

Para las instalaciones de Nivel 2, ejecute las tareas de configuración siguientes.

Estas tareas se deben ejecutar desde las interfaces de línea de comandos de

composer y conman.

Configuración de un agente tolerante a errores después de la

instalación

Después de configurar de esta manera el agente tolerante a errores, puede utilizar

Job Scheduling Console para configurar las demás estaciones de trabajo y los

objetos de planificación de trabajos de la red de Tivoli Workload Scheduler.



Consulte el manual IBM Tivoli Workload Scheduler - Guía de consulta para obtener

detalles sobre los comandos utilizados a continuación. Consulte el manual Tivoli

Workload Scheduler Job Scheduling Console - Guía del usuario para obtener información

sobre la utilización de Job Scheduling Console para configurar otras estaciones de

trabajo de la red.

1. Inicie la sesión en el gestor de dominio maestro como TWSuser. Este es el

usuario encargado de gestionar la instancia del gestor de dominio maestro de


2. Cree la definición de la estación de trabajo para el agente tolerante a errores en

la base de datos de Tivoli Workload Scheduler, utilizando la línea de comandos

de composer. Antes de ejecutar comandos, vea el punto 1 en la página 83

referente a la definición de las variables de entorno PATH y TWS_TISDIR. Abra

una ventana de línea de comandos y entre estos comandos:

composer

new

3. Esto abrirá un editor de textos donde puede crear la definición de la estación

de trabajo en la base de datos de Tivoli Workload Scheduler para un agente

tolerante a errores. El ejemplo siguiente muestra una definición de estación de

trabajo para un agente tolerante a errores. Para obtener más información sobre

las definiciones de estación de trabajo, consulte el manual Tivoli Workload

Scheduler - Guía de consulta.

cpuname FTA1

os UNIX

node FTA1.rome.ibm.com

description "Agente tolerante a errores"

for Maestro

autolink on

end

4. Cree un nuevo archivo Symphony que incluya la definición de la estación de

trabajo tolerante a errores. Para hacer esto, ejecute el trabajo Jnextday en el

gestor de dominio maestro que sirve para automatizar la creación de un nuevo

archivo Symphony:

Jnextday

5. Emita el comando link desde el gestor de dominio maestro para vincular el

agente tolerante a errores y descargar en él el archivo Symphony:

conman “link nombre_agente_tolerante_a_errores”

Habilitación de la función de huso horario

La función de huso horario se habilita mediante una entrada del archivo

globalopts y especificando un huso horario en la definición de estación de trabajo

del maestro, de esta manera:

timezone enable = yes|no

Los husos horarios se inhabilitan de forma predeterminada al instalar o actualizar

el producto. Si falta la entrada timezone enable en el archivo globalopts, se

inhabilitan los husos horarios.

Los pasos siguientes describen el método de implementar la función de huso

horario:

1. Cargue Tivoli Workload Scheduler.



El valor predeterminado para la función de huso horario es timezone enable =

no en el archivo globalopts. La base de datos permite que se especifiquen husos

horarios para estaciones de trabajo, pero no en las horas de inicio y plazo límite

dentro de las secuencias de trabajos de la base de datos. La creación del plan

(Jnextday) pasa por alto cualquier huso horario existente en la base de datos. El

usuario no puede especificar husos horarios en ningún lugar del plan.

2. Defina husos horarios de estación de trabajo.

Defina el huso horario de la estación de trabajo maestra, del maestro de copia

de seguridad y de cualquier agente tolerante a errores que esté en un huso

horario diferente del utilizado por el maestro. No se permiten husos horarios

en la base de datos para las especificaciones horarias de inicio y plazo límite. En

este momento no se permitirá ningún huso horario en el plan, pues la entrada

timezone enable del archivo globalopts todavía está establecida en NO.

3. Una vez definidos correctamente los husos horarios de estación de trabajo,

establezca timezone enable en YES en el archivo globalopts. Este valor, y la

definición de huso horario contenida en la estación de trabajo maestra,

permitirá que la red de Tivoli Workload Scheduler saque provecho del soporte

de huso horario.

En este momento, todos los usuarios podrán utilizar husos horarios en

cualquier lugar de la base de datos, pero deben esperar a la ejecución siguiente

de Jnextday para utilizarlos en las especificaciones horarias de inicio y plazo

límite. Hasta que se ejecute Jnextday, los usuarios no podrán utilizar husos

horarios en el plan. La próxima vez que se ejecute Jnextday, los husos horarios

se aplicarán al plan, y Job Scheduling Console y el programa de fondo

permitirán la especificación de husos horarios en cualquier lugar del plan.

4. Comience a utilizar husos horarios en las especificaciones horarias de inicio y

plazo límite donde sea necesario.

Ahora todas las referencias de huso horario contenidas en la base de datos y en

el plan puede utilizarlas con Job Scheduling Console y la interfaz de línea de

comandos (CLI).



Habilitación del huso horario en una red global

En una red global, la estación de trabajo se define en el maestro de Tivoli

Workload Scheduler for z/OS. Defina la estación de trabajo utilizando el comando

CPUREC, tal como se describe en el manual IBM Tivoli Workload Scheduler for z/OS

Customization and Tuning. En la sentencia CPUREC, defina el huso horario local de

la estación de trabajo utilizando la palabra clave CPUTZ. Si no especifica la palabra

clave CPUTZ, el valor predeterminado es UTC (hora universal coordinada).

Asegúrese de que el huso horario especificado en CPUTZ coincida con el huso

horario del sistema operativo de la estación de trabajo donde se ejecuta Tivoli

Workload Scheduler. Si los husos horarios no coinciden, se muestra un mensaje

codificado como AWSBHT128I en el archivo de registro de la estación de trabajo.

En una red global, la función de huso horario está siempre habilitada y no es

necesario definirla en el archivo globalopts. Además, el valor especificado para la

palabra clave CPUTZ se utiliza para cada estación de trabajo. Si no se especifica el

valor de CPUTZ, se utiliza el valor predeterminado UTC.



Capítulo 9. Personalización opcional

Después de instalar el producto, puede personalizarlo de acuerdo con sus

necesidades. Este capítulo describe pasos opcionales de personalización para su

instalación de Tivoli Workload Scheduler. Los temas tratados son los siguientes:

v “Opciones globales”

v “Opciones locales” en la página 92

v “Configuración de la administración descentralizada” en la página 102

v “Mensajes de consola y mensajes de solicitud de Tivoli Workload Scheduler” en

la página 104

v “Automatización del ciclo de producción” en la página 105

v “Gestión del entorno de producción” en la página 106

v “Utilización de los scripts de configuración” en la página 108

v “Tivoli Workload Scheduler y Tivoli Management Framework” en la página 113

Opciones globales

Puede definir opciones globales en el gestor de dominio común y éstas son

aplicables a todas las estaciones de trabajo de la red de Tivoli Workload Scheduler.

Definición de las opciones globales

Puede definir las opciones globales en el archivo globalopts con un editor de

textos. Puede hacer cambios en cualquier momento, pero no serán efectivos hasta

que detenga y reinicie Tivoli Workload Scheduler. La Tabla 25 describe la sintaxis

del archivo. En las entradas no se distingue entre mayúsculas y minúsculas.

Tabla 25. Sintaxis de Globalopts

Sintaxis Valor predeterminado

# comentario

automatically grant logon as batch = yes|no no

batchman schedule = yes|no no

bmmsgbase = entero 1000

bmmsgdelta = entero 1000

carry job states = ([estado[,...]]) nulo

carryforward = yes|no|all yes

centralized security=on|off off

company = nombre_empresa nulo

database audit level = 0|1 0

enable list security check = yes|no no

history = días 10

ignore calendars = yes|no no

master = estación_trabajo Se define inicialmente al instalar


plan audit level = 0|1 0

retain rerun job name = yes|no no


Tabla 25. Sintaxis de Globalopts (continuación)


start = hora_inicio 0600

timezone enable = yes|no no

# comentario

Todo lo que sigue a continuación del signo de almohadilla hasta el final de

la línea se trata como un comentario.

automatically grant logon as batch job

Esto es sólo para trabajos de Windows. Si su valor es yes, los usuarios

conectados para trabajos de Windows reciben automáticamente el derecho

a iniciar la sesión como trabajo de proceso por lotes (Logon as batch job).

Si su valor es no o se omite esta opción, el derecho se debe otorgar

manualmente a cada usuario o grupo. Observe que el derecho no se puede

otorgar automáticamente para los usuarios que ejecutan trabajos en un

Controlador de dominio de reserva (Backup Domain Controller, BDC), por

lo que debe otorgar esos derechos manualmente.

bmmsgbase

Especifique el número máximo de solicitudes que se pueden mostrar al

operador después de la finalización anómala de un trabajo. El valor

predeterminado es 1000.

bmmsgdelta

Especifique un número adicional de solicitudes para el valor definido en

bmmsgbase para el caso en el que un trabajo se ejecuta de nuevo después

de su finalización anómala y se ha alcanzado el límite especificado en

bmmsgbase. El valor predeterminado es 1000.

batchman schedule

Esta es una opción de producción que afecta a la actuación de Batchman,

que es el proceso de control de producción de Tivoli Workload Scheduler.

El valor especificado determina la prioridad asignada a las secuencias de

trabajos creadas para trabajos no planificados. Especifique yes para hacer

que se asigne una prioridad 10 a esas secuencias de trabajos. Especifique

no para hacer que se asigne una prioridad 0 a esas secuencias de trabajos.

carry job states

Esta es una opción de pre-producción que afecta a la actuación del

comando stageman. El valor especificado determina los trabajos, de

acuerdo con el estado, que se deben incluir en secuencias de trabajos que

se trasladan al día de proceso siguiente. Debe delimitar los estados de

trabajo con paréntesis, comillas dobles o comillas simples. Las comas

pueden ser sustituidas por espacios en blanco. Los estados internos válidos

de trabajos son los siguientes:

abend abenp add done exec fail

hold intro pend ready rjob sched

skel succ succp susp wait waitd

Estos son algunos ejemplos de la opción:

carry job states=(abend,exec,hold,intro)

carry job states="abend exec hold intro"

carry job states=’abend exec hold intro’

Especifique una lista vacía de esta manera:

Personalización opcional


carry job states=()

Consulte el apartado “Opciones de traspaso” en la página 91 para obtener

más información.

carryforward


comando stageman. Su valor determina si las secuencias de trabajos no

finalizadas se trasladan desde el plan de producción antiguo al nuevo

(Symphony). Especifique yes para hacer que las secuencias de trabajos no

finalizadas se trasladen al nuevo plan sólo si la opción Carry Forward está

habilitada en la definición de la secuencia de trabajos. Especifique all para

hacer que se trasladen al nuevo plan todas las secuencias de trabajos no

finalizadas, con independencia del valor de la opción Carry Forward.

Especifique no para inhabilitar totalmente la función de traslado hacia

delante. La opción de línea de comandos stageman -carryforward recibe

los mismos valores y tiene la misma finalidad que la opción global

carryforward. Si se utiliza, prevalece sobre la opción global. Consulte el

apartado “Opciones de traspaso” en la página 91 para obtener más

información.

centralized security

Esta opción gobierna cómo se utiliza el archivo de seguridad dentro de la

red de IBM Tivoli Workload Scheduler.

Si el valor es on, los archivos de seguridad de todas las estaciones de

trabajo de la red de IBM Tivoli Workload Scheduler se pueden crear y

modificar sólo en el maestro, y el administrador de IBM Tivoli Workload

Scheduler es el encargado de su creación, mantenimiento y distribución.

Si el valor es off, el archivo de seguridad de cada estación de trabajo

puede ser gestionado por su usuario root o administrador. El usuario local

puede ejecutar el comando makesec para crear o actualizar el archivo.

El valor predeterminado es off. Consulte el manual IBM Tivoli Workload

Scheduler - Guía de consulta para obtener detalles sobre el uso de esta

función.

company

Es el nombre de la empresa, que puede tener un máximo de 40 caracteres.

Si el nombre contiene espacios en blanco, delimite el nombre completo

mediante comillas (″). Si utiliza el juego de caracteres del japonés

Katakana, delimite siempre el nombre por medio de comillas simples o

dobles para asegurarse de que aparezca en las páginas de los informes.

database audit level

Seleccione si desea habilitar o inhabilitar la auditoría de bases de datos.

Los valores válidos son 0 para inhabilitar la auditoría de bases de datos y 1

para activarla. La información de auditoría se registra en el directorio

TWShome/audit/database. Cada estación de trabajo de Tivoli Workload

Scheduler mantiene su propio archivo de registro. Para la base de datos,

sólo se registran acciones en el archivo de auditoría, no el éxito o fracaso

de la acción. Para obtener más información sobre esta función, consulte el

apartado Habilitación de la función de huso horario.

enable list security check

Esta es una opción de seguridad que controla qué objetos del plan está

autorizado el usuario a listar cuando ejecuta una consulta de Job

Scheduling Console o un comando de visualización de conman. Si el valor

de esta opción es yes, los objetos del plan devueltos por una consulta o



comando de visualización se muestran al usuario sólo si este ha recibido

permiso list en el archivo de seguridad. El valor predeterminado es no.

Cambie el valor a yes si desea comprobar la existencia del permiso list en

el archivo de seguridad.

history

Especifique el número de días durante los que desea guardar estadísticas

sobre trabajos. Las estadísticas se desechan por orden de mayor a menor

antigüedad. Esto no afecta a los archivos de lista estándar de trabajos, los

cuales se deben eliminar con el comando rmstdlist. Consulte el manual

Tivoli Workload Scheduler - Guía de consulta para obtener más información

sobre el comando rmstdlist.

ignore calendars


comando compiler. El valor de esta opción determina si se copian o no

calendarios de usuario en el nuevo archivo de control de producción.

Especifique yes si desea impedir que los calendarios se copien en el nuevo

plan de producción (archivo Symphony). Esto ahorra espacio en el archivo,

pero permite el uso de nombres de calendarios en las expresiones de fecha.

Especifique no si desea que los calendarios de usuario se copien en el

nuevo plan de producción. Consulte la explicación sobre el comando

compiler en el manual Tivoli Workload Scheduler - Guía de consulta para

obtener más información.

master

Es el nombre del gestor de dominio maestro. Se define al instalar Tivoli

Workload Scheduler.

plan audit level

Seleccione si desea habilitar o inhabilitar la auditoría del plan. Los valores

válidos son 0 para inhabilitar la auditoría del plan y 1 para activarla. La

información de auditoría se registra en un archivo plano del directorio

TWShome/audit/plan. Cada estación de trabajo de Tivoli Workload

Scheduler mantiene su propio archivo de registro. Para el plan, sólo se

registran acciones en el archivo de auditoría, no el éxito o fracaso de la

acción. Para obtener más información sobre esta función, consulte el

apartado Habilitación de la función de huso horario.

retain rerun job name

Esta es una opción de producción que afecta a la actuación de Batchman,

que es el proceso de control de producción de Tivoli Workload Scheduler.

El valor de esta opción determina si los trabajos que se ejecutan de nuevo

con el comando rerun de Conman conservan o no sus nombres de trabajo

originales. Especifique yes si desea que los trabajos que se vuelven a

ejecutar conserven sus nombres de trabajo originales. Especifique no si

desea permitir que el nombre de rerun from (volver a ejecutar desde) se

asigne para reejecutar trabajos.

start Especifique la hora de inicio del día de proceso de Tivoli Workload

Scheduler en el formato de 24 horas: hhmm (0000-2359 ). La hora de inicio

predeterminada es 6:00 A.M., y la hora de arranque predeterminada de la

secuencia de trabajos final es 5:59 A.M. Si cambia la hora de inicio , debe

también cambiar la hora de arranque de la secuencia de trabajos final,

cuyo valor es generalmente igual a un minuto antes que la hora de inicio.

timezone enable

Seleccione si desea habilitar o inhabilitar la opción de huso horario. Los

valores válidos son yes para activar husos horarios en la red, y no para



inhabilitar los husos horarios. El huso horario se establece en la definición

de la estación de trabajo y la función se puede habilitar mediante el valor

de la entrada correspondiente del archivo globalopts. Los husos horarios

se inhabilitan por omisión al instalar o actualizar Tivoli Workload

Scheduler. Si falta la entrada timezone enable en el archivo globalopts, se

inhabilitan los husos horarios. Para obtener más información sobre esta

función, consulte el apartado Habilitación de la función de huso horario.

Ejemplo de archivo de opciones globales

Existe una plantilla de archivo de opciones globales que contiene valores

predeterminados de Tivoli Workload Scheduler ubicado en

TWShome/config/globalopts.

Durante el proceso de instalación, se instala una copia de trabajo del archivo del

archivo de opciones globales de la manera siguiente TWShome/mozart/globalopts.

El usuario puede personalizar la copia de trabajo de acuerdo con sus necesidades.

A continuación se muestra un ejemplo de archivo de opciones globales:

# Globalopts file on the master domain manager defines

# attributes of the Tivoli Workload Scheduler network.

#--------------------------------------------------------

company="IBM"

master=main

start=0600

history=10

carryforward=yes

ignore calendars=no

batchman schedule=no

retain rerun job name=no

centralized security=no

#

#--------------------------------------------------------

# End of globalopts.

Opciones de traspaso

Las secuencias de trabajos se traspasan a otro día mediante el comando stageman

durante el proceso de fin de día. El proceso de traspaso está afectado por lo

siguiente:

v La palabra clave carryforward contenida en las secuencias de trabajos. Consulte

el manual Tivoli Workload Scheduler - Guía de consulta para obtener más

información.

v La opción global carryforward. Consulte la página en la página 89.

v La opción de línea de comandos stageman -carryforward. Consulte la

explicación sobre el comando stageman en el manual Tivoli Workload Scheduler -

Guía de consulta.

v La opción global carry job states . Consulte la página 88.

La tabla siguiente muestra cómo las diversas opciones de traspaso actúan juntas.

Opciones globales Operación de traspaso

carryforward=no No se traspasa ninguna secuencia de trabajos.

carryforward=yes carry job

states=(estados)

Las secuencias de trabajos se traspasan sólo si contienen

trabajos en los estados especificados y tienen habilitada

la opción Carryforward. Sólo los trabajos que están en

los estados especificados se traspasan con las secuencias

de trabajos.



Opciones globales Operación de traspaso

carryforward=yes carry job

states=()

Las secuencias de trabajos se traspasan sólo si están

incompletas y tienen habilitada la opción Carryforward.

Se traspasan todos los trabajos con las secuencias de

trabajos.

carryforward=all carry job

states=(estados)

Las secuencias de trabajos se traspasan sólo si tienen

trabajos en los estados especificados. Sólo los trabajos

que están en los estados especificados se traspasan con

las secuencias de trabajos.

carryforward=all carry job

states=()

Las secuencias de trabajos se traspasan sólo si están

incompletas. Se traspasan todos los trabajos con las

secuencias de trabajos.

Las opciones de traspaso tienen el comportamiento siguiente:

v Cualquier secuencia de trabajos cuyo estado no sea SUCC se considera

incompleta y se traspasa. Una cadena de reejecución de trabajos se considera

incompleta si como mínimo existe un trabajo incompleto, por lo que se traspasa

toda la cadena.

v Si se utiliza la opción de línea de comandos stageman -carryforward, siempre

prevalece la opción global carryforward. Si no se especifica ninguna de esas dos

opciones, el valor predeterminado es carryforward=yes.

v El valor predeterminado es nulo para la opción global carry job states. Es decir,

si la lista está vacía o se omite la opción, la función de traspaso actúa tal como

se describe para carry job states=().

v Los trabajos y secuencias de trabajos que fueron cancelados no se traspasan

nunca.

v Los trabajos y secuencias de trabajos para los que se ha alcanzado la hora

especificada en until no se traspasan nunca.

v La decisión de traspasar un trabajo repetitivo (definido por la opción Every) está

basada en el estado de la ejecución más reciente del trabajo.

v Si un trabajo está en ejecución cuando el trabajo Jnextday comienza a ejecutarse

y no se ha especificado el traspaso del trabajo, el trabajo sigue ejecutándose y se

coloca en la secuencia de trabajos userjobs para el nuevo día de producción.

Observe que las dependencias respecto a tales trabajos no se traspasan, y todos

los recursos retenidos por el trabajo se liberan.

Opciones locales

Las opciones locales se definen en cada estación de trabajo y son aplicables sólo a

dicha estación de trabajo.

Definición de las opciones locales

Las opciones locales se especifican en un archivo denominado localopts con un

editor de textos. Puede hacer cambios en cualquier momento, pero no serán

efectivos hasta que detenga y reinicie Tivoli Workload Scheduler. La Tabla 26

describe la sintaxis. En las entradas no se distingue entre mayúsculas y

minúsculas.

Tabla 26. Sintaxis de Localopts


# comentario



Tabla 26. Sintaxis de Localopts (continuación)


bm check deadline = segundos 0

bm check file = segundos 120

bm check status = segundos 300

bm check until = segundos 300

bm look = segundos 30

bm read = segundos 15

bm stats = on|off off

bm verbose = on|off off

composer prompt = clave dash (-)

conman cli prompt = clave percent (%)

date format= entero 1

db visible for gui= yes|no no

jm job table size = entradas 160

jm look = segundos 300

jm nice = valor 0

jm no root = yes|no no

jm read = segundos 10

merge stdlists = yes|no yes

mm cache mailbox = yes|no no

mm cache size = bytes 32

mm read = segundos 15

mm resolve master = yes|no yes

mm response = segundos 600

mm retry link = segundos 600

mm sound off =yes|no no

mm unlink = segundos 960

mozart directory = mozart_share Ninguno

nm ipvalidate = none|full none

nm mortal = yes|no no

nm port = número de puerto 31111

nm read = segundos 60

nm retry = segundos 800

nm SSL port = valor 31113

parameters directory =parms_share Ninguno

SSL auth mode = caonly|string|cpu caonly

SSL auth string = cadena de caracteres tws

SSL CA certificate =*.crt TWShome/ssl/nombre_archivo.crt

SSL certificate =*.crt TWShome/ssl/nombre_archivo.crt

SSL certificate chain =*.crt TWShome/ssl/nombre_archivo.crt

SSL encryption cipher Ninguno. Véase la Tabla 38 en la página 164



Tabla 26. Sintaxis de Localopts (continuación)


SSL key = *.key TWShome/ssl/nombre_archivo.crt

SSL key pwd = *.sth TWShome/ssl/nombre_archivo.sth

SSL random seed =*.rnd TWShome/ssl/nombre_archivo.rnd

stdlist width = columnas 80

sync level = low|medium|high high

switch sym prompt = clave percent (%)

syslog local = recurso -1

tcp timeout = segundos 600

thiscpu = estación_trabajo thiscpu

wr read = segundos 600

wr enable compression = yes|no no

wr unlink = segundos 600

# comentario

Todo lo que sigue a continuación del signo de almohadilla hasta el final de

la línea se trata como un comentario.

bm check deadline

Especifique el número máximo de segundos que Batchman esperará antes

de notificar que se ha alcanzado el tiempo límite para el trabajo o

secuencia de trabajos. El valor predeterminado es (0), que significa que no

se comprueba el tiempo límite y no se notifica su caducidad. Para habilitar

esa comprobación, especifique un valor en segundos.

bm check file

Especifique el número mínimo de segundos que Batchman esperará antes

de comprobar la existencia de un archivo que se utiliza como dependencia.

bm check status

Especifique el número de segundos que Batchman esperará antes de

comprobar de nuevo el estado de una dependencia inter-red.

bm check until

Especifique el número máximo de segundos que Batchman esperará antes

de notificar que se ha alcanzado un tiempo límite ″Until″ para el trabajo o

secuencia de trabajos. Especificar un valor menor que el valor

predeterminado (300) puede producir una sobrecarga del sistema. Si el

valor de esta opción es menor que el valor de la opción local bm read,

prevalece el valor de bm read.

bm look

Especifique el número mínimo de segundos que Batchman esperará antes

de examinar y actualizar su archivo de control de producción.

bm read

Especifique el número máximo de segundos que Batchman esperará a que

llegue un mensaje al archivo de mensajes INTERCOM.MSG. Si no existe

ningún mensaje puesto en cola, Batchman esperará hasta que se alcance el

tiempo de espera o se escriba un mensaje en el archivo.

bm stats

Especifique on para hacer que Batchman envíe sus estadísticas de arranque



y conclusión del sistema al archivo de lista estándar del comando.

Especifique off para impedir que las estadísticas de Batchman se envíen al

archivo de lista estándar.

bm verbose

Especifique on para hacer que Batchman envíe todos los mensajes de

estado de trabajos al archivo de lista estándar. Especifique off para impedir

que el conjunto ampliado de mensajes de estado de trabajos se envíen al

archivo de lista estándar.

composer prompt

Especifique un indicador de solicitud para la línea de comandos de

composer. El indicador de solicitud puede tener un máximo de 10

caracteres de longitud. El valor predeterminado es un guión (-).

conman prompt


conman. El indicador de solicitud puede tener un máximo de 8 caracteres

de longitud. El valor predeterminado es un signo de porcentaje (%).

date format

Especifique el valor correspondiente al formato de fecha que desee. Los

valores pueden ser:

v 0 corresponde a aa/mm/dd

v 1 corresponde a mm/dd/aa

v 2 corresponde a dd/mm/aa

v 3 denota la utilización de variables de Native Language Support

El valor predeterminado es 1.

db visible for gui

Especifique yes para permitir que Job Scheduling Console pueda acceder a

la base de datos del agente tolerante a errores, mientras se conecta al

agente tolerante a errores, aunque éste no sea el gestor de dominio

maestro. El usuario de Job Scheduling Console puede visualizar los iconos

de la base de datos. El valor predeterminado es no.

jm job table size

Especifique el tamaño, expresado como número de entradas, de la tabla de

trabajos utilizada por Jobman.

jm look

Especifique el número mínimo de segundos que Jobman esperará antes de

buscar trabajos finalizados y realizar tareas generales de gestión de

trabajos.

jm nice

Para UNIX solamente, especifique el valor nice que se debe aplicar a los

trabajos iniciados por Jobman.

jm no root

Para UNIX solamente, especifique yes para impedir que Jobman inicie

trabajos root. Especifique no para permitir que Jobman inicie trabajos root.

jm read

Especifique el número máximo de segundos que Jobman esperará a que

llegue un mensaje al archivo de mensajes COURIER.MSG.

mm cache mailbox

Utilice esta opción para permitir que mailman utilice una caché de lectura

para los mensajes entrantes. En ese caso, no todos los mensajes se colocan



en la caché, sino sólo aquellos que no se consideran esenciales para la

estabilidad de la red. El valor predeterminado es no.

mm cache size

Utilice esta opción si también utiliza mm cache mailbox. El valor

predeterminado es 32. Utilice el valor predeterminado para redes pequeñas

y de tamaño mediano. Utilice valores mayores para redes grandes. Evite

utilizar un valor alto para redes pequeñas. El valor máximo es 512 (los

valores mayores no se tienen en cuenta).

merge stdlists

Especifique yes para hacer que todos los procesos de control de Tivoli

Workload Scheduler, excepto Netman, envíen sus mensajes de consola a un

archivo de lista estándar individual. El nombre asignado al archivo es

TWSmerge. Especifique no para hacer que los procesos envíen mensajes a

archivos de lista estándar independientes.

mm read

Especifique la frecuencia, en segundos, con la que Mailman comprueba la

existencia de mensajes en su buzón de correo. El valor predeterminado es

15 segundos. Si se especifica un valor menor, Tivoli Workload Scheduler se

ejecutará con mayor velocidad, pero se consumirá más tiempo de

procesador.

mm resolve master

Si el valor de esta opción es ″yes″ (valor predeterminado), la variable

$MASTER se resuelve al comienzo del día de producción. El host de

cualquier agente ampliado se conmutará después del siguiente Jnextday

(conmutación a largo plazo). Si el valor de esta opción es ″no″, la variable

$MASTER no se resuelve cuando se ejecuta Jnextday, lo cual permite que el

host de cualquier agente ampliado se conmute justo después de un

comando switchmgr de conman (conmutación a corto y largo plazo).

mm response

Especifique el número máximo de segundos que Mailman esperará una

respuesta antes de notificar que una estación de trabajo no responde. El

tiempo de respuesta no debería ser menor que 90 segundos.

mm retry link

Especifique el número máximo de segundos que Mailman esperará,

después de desvincularse de una estación de trabajo que no responde,

antes de intentar vincularse de nuevo con la estación de trabajo.

mm sound off

Especifica cómo Mailman responde a un comando tellop ? de conman.

Especifique yes para hacer que Mailman muestre información sobre cada

tarea que está realizando. Especifique no para hacer que Mailman envíe

sólo su propia información de estado.

mm unlink

Especifique el número máximo de segundos que Mailman esperará antes

de desvincularse de una estación de trabajo que no responde. El tiempo de

espera no debería ser menor que el tiempo de respuesta especificado para

la opción local nm response.

nm ipvalidate

Especifique full para habilitar la validación de direcciones IP. Si la

validación IP falla, no se permite la conexión. Especifique none para

permitir conexiones cuando la validación IP falle.



nm mortal

Especifique yes para hacer que termine la ejecución de Netman cuando se

hayan detenido todos sus procesos secundarios. Especifique no para hacer

que Netman siga ejecutándose incluso después de haberse detenido sus

procesos secundarios.

nm port

Especifique el número de puerto TCP al cual responde Netman en el

sistema local. Este valor debe coincidir con el puerto TCP especificado en

la definición de estación de trabajo del sistema. Debe ser un valor sin

signo, de 16 bits, comprendido dentro del rango 1-65535 (recuerde que los

valores comprendidos entre 0 y 1023 están reservados para los servicios

conocidos públicamente, tales como FTP, TELNET, HTTP, etc.).

nm read

Especifique el número máximo de segundos que Netman esperará una

petición de conexión antes de comprobar la existencia de comandos stop y

start en su cola de mensajes.

nm retry

Especifique el número máximo de segundos que Netman esperará antes de

intentar establecer de nuevo una conexión que ha fallado.

nm SSL port

Es el puerto utilizado para recibir las conexiones SSL entrantes. Este valor

debe coincidir con el definido en el atributo secureaddr en la definición de

estación de trabajo contenida en la base de datos de IBM Tivoli Workload

Scheduler. Debe ser diferente de la opción local nm port que define el

puerto utilizado para las comunicaciones normales. Durante la instalación,

el valor predeterminado es 0. Cuando se crea la CPU y se habilita la

autenticación SSL, el número de puerto toma el valor 31113.

Notas:

1. En Windows, defina esta opción también en el archivo localopts.

2. Si instala varias instancias de Tivoli Workload Scheduler versión 8.2 en

el mismo sistema, asigne un valor diferente a cada puerto de SSL.

3. Si no piensa utilizar SSL, establezca el valor en 0.

SSL auth mode

Define el comportamiento de Tivoli Workload Scheduler durante la fase de

reconocimiento de SSL, de acuerdo con estos valores:

caonly Tivoli Workload Scheduler comprueba la validez del certificado y

verifica que el certificado del interlocutor haya sido emitido por

una CA reconocida. La información contenida en el certificado no

se examina. Es el valor predeterminado. Si no especifica la opción

″SSL auth mode″, o define un valor que no es válido, se utiliza el

valor ″caonly″.

string Tivoli Workload Scheduler comprueba la validez del certificado y


una CA reconocida. También verifica que el Nombre común

(Common Name, CN) del Tema del certificado coincida con la

cadena de caracteres especificada en la opción ″SL auth string″.

Consulte la página 98.

cpu Tivoli Workload Scheduler comprueba la validez del certificado y





(Common Name, CN) del Tema del certificado coincida con el

nombre de la CPU que ha solicitado el servicio.

SSL auth string

Se utiliza en combinación con la opción SSL auth mode cuando se

especifica el valor ″string″. La opción SSL auth string (que comprende de

1 a 64 caracteres) se utiliza para verificar la validez del certificado. Si no

especifica un valor para SSL auth string en combinación con SSL auth

mode, el valor predeterminado que se utiliza para ″string″ es ″tws″.

SSL CA certificate

En la autenticación SSL, es el nombre del archivo donde están contenidos

los certificados de autoridad de certificación fiable necesarios para la

autenticación. Las CA (autoridades de certificación) de este archivo

también se utilizan para crear la lista de las CA de cliente aceptables que

se pasan al cliente cuando el extremo servidor de la conexión solicita un

certificado de cliente. Este archivo es la concatenación, en orden de

preferencia, de los diversos archivos de certificados de CA codificados por

PEM. Consulte el apartado “Definición de una autenticación y un cifrado

estrictos” en la página 153 para obtener detalles.

SSL certificate

En la autenticación SSL, es el nombre del archivo de certificado local.

Consulte el apartado “Definición de una autenticación y un cifrado


SSL certificate chain

En la autenticación SSL, es el nombre del archivo que contiene la

concatenación de los certificados codificados por PEM procedentes de

autoridades de certificación y que forman la cadena de certificados del

certificado de la estación de trabajo. Este parámetro es opcional. Si no se

especifica, se utiliza el archivo especificado para SSL CA certificate.



SSL encryption cipher

Son los codificadores que la estación de trabajo utiliza durante una

conexión SSL. Utilice los accesos directos siguientes:

Tabla 27. Accesos directos para codificadores de cifrado

Acceso directo Codificadores de cifrado

SSLv3 SSL versión 3.0

TLSv TLS versión 1.0

EXP Exportación

EXPORT40 Exportación de 40 bits


LOW Baja resistencia (sin exportación, DES simple)

MEDIUM Codificadores con cifrado de 128 bits

HIGH Codificadores que utilizan Triple-DES

NULL Codificadores que no utilizan cifrado

SSL key

En la autenticación SSL, es el nombre del archivo de clave privada.





SSL key pwd

En la autenticación SSL, es el nombre del archivo donde está contenida la

contraseña correspondiente a la clave secreta. Consulte el apartado

“Definición de una autenticación y un cifrado estrictos” en la página 153

para obtener detalles.

SSL random seed

Es el archivo de números seudoaleatorios utilizado por OpenSSL en

algunas plataformas. Sin la existencia de este archivo, la autenticación SSL

no puede funcionar debidamente. Consulte el apartado “Definición de una

autenticación y un cifrado estrictos” en la página 153 para obtener detalles.

stdlist width

Especifique el ancho máximo de los mensajes de consola de Tivoli

Workload Scheduler. Puede especificar un número de columna

comprendido dentro del rango 1 - 255; las líneas se ajustarán

automáticamente para el número de columna especificado o en una

posición anterior, dependiendo de la presencia de caracteres intercalados

de control de carro. Especifique un número negativo o 0 para no tener en

cuenta el ancho de línea. En UNIX, no es necesario tener en cuenta el

ancho de línea si habilita el registro del sistema con la opción syslog local.

syslog local

Para UNIX solamente, habilita o inhabilita el registro del sistema de Tivoli

Workload Scheduler. Especifique -1 para desactivar el registro del sistema

para Tivoli Workload Scheduler. Especifique un número comprendido entre

0 y 7 para activar el registro del sistema y hacer que Tivoli Workload

Scheduler utilice el correspondiente recurso local (LOCAL0 a LOCAL7)

para sus mensajes. Especifique cualquier otro número para activar el

registro del sistema y hacer que Tivoli Workload Scheduler utilice el

recurso USER para sus mensajes. Para obtener más información, consulte el

apartado “Mensajes de consola y mensajes de solicitud de Tivoli Workload

Scheduler” en la página 104.

sync level

Especifique la frecuencia con la que Tivoli Workload Scheduler sincroniza

la información escrita en disco. Esta opción afecta a todos los agentes de

correo y sólo es aplicable a estaciones de trabajo UNIX. Los valores pueden

ser:

low Permite que el sistema operativo se haga cargo de la operación.

medium

Descarga las actualizaciones a disco una vez finalizada una

transacción.

high Descarga las actualizaciones a disco cada vez que se entran datos.

El valor predeterminado es high.

switch sym prompt


conman después de haber seleccionado un archivo Symphony diferente

con el comando setsym. El indicador de solicitud puede tener un máximo

de 8 caracteres de longitud. El valor predeterminado es un signo de

porcentaje (%).

tcp timeout

Este atributo del proceso Netman especifica el número máximo de



segundos que Mailman y Conman esperarán a que finalice una petición

para una estación de trabajo vinculada que no responde. El valor

predeterminado es 600 segundos

thiscpu

Especifique el nombre de la estación de trabajo para Tivoli Workload

Scheduler.

wr enable compression

Utilice esta opción para agentes tolerantes a errores. Especifique si el

agente tolerante a errores puede recibir el archivo Symphony en forma

comprimida desde el gestor de dominio maestro. El valor predeterminado

es no.

wr read

Especifique el número de segundos que el proceso Writer esperará un

mensaje entrante antes de comprobar si existe una petición de terminación

procedente de Netman.

wr unlink

Especifique el número de segundos que el proceso Writer esperará antes de

concluir la ejecución si no se recibe ningún mensaje entrante. El límite

inferior es 120 y el valor predeterminado es 600.

Ejemplo de archivo de opciones locales

Existe un archivo plantilla que contiene los valores predeterminados ubicado en

TWShome/config/localopts.

Durante el proceso de instalación, se instala una copia de trabajo de el archivo de

opciones locales de la manera siguiente TWShome/localopts, a menos que haya

especificado una ubicación diferente de la predeterminada para netman. Existen

dos copias del archivo localopts: una en TWShome y otra en Netmanhome. Las

opciones que pertenezcan a netman deben actualizarse en el archivo localopts de

Netmanhome.

El usuario puede personalizar la copia de trabajo de acuerdo con sus necesidades.

Por ejemplo:

#

# Tivoli Workload Scheduler localopts file defines attributes of this Workstation.

#

#----------------------------------------------------------------------------

# Attributes of this Workstation:

#

thiscpu = <THIS_CPU>

merge stdlists = yes

stdlist widt h= 80

syslog local = -1

#

#----------------------------------------------------------------------------

# Attributes of this Workstation for Tivoli Workload Scheduler batchman process:

#

bm check file = 120

bm check status = 300

bm look = 15

bm read = 10

bm stats = off

bm verbose = off

bm check until = 300

bm check deadline = 600

#

#----------------------------------------------------------------------------

# Attributes of this Workstation for Tivoli Workload Scheduler jobman process:

#

jm job table size = 1024



jm look = 300

jm nice = 0

jm no root = no

jm read = 10

#

#----------------------------------------------------------------------------

# Attributes of this Workstation for Tivoli Workload Scheduler mailman process:

#

mm response = 600

mm retrylink = 600

mm sound off = no

mm unlink = 960

mm cache mailbox = no

mm cache size = 32

mm resolve master = yes

#

#----------------------------------------------------------------------------

# Attributes of this Workstation for Tivoli Workload Scheduler netman process:

#

nm mortal = no

nm port = <TCP_PORT>

nm read = 10

nm retry = 800

#

#----------------------------------------------------------------------------

# Attributes of this Workstation for Tivoli Workload Scheduler writer process:

#

wr read = 600

wr unlink = 120

wr enable compression = no

#

#----------------------------------------------------------------------------

# Optional attributes of this Workstation for remote database files

#

# mozart directory = <HOME>/mozart

# parameters directory = <HOME>

#

#----------------------------------------------------------------------------

# Custom format attributes

#

date format = 1# The possible values are 0-ymd, 1-mdy, 2-dmy, 3-NLS.

composer prompt = -

conman prompt = %

switch sym prompt = <n>%

#

#----------------------------------------------------------------------------

# Attributes for customization of I/O on mailbox files

#

sync level = high

#

#----------------------------------------------------------------------------

# Network attributes

#

tcp timeout = 600

#

#----------------------------------------------------------------------------

# SSL Attributes

#

nm SSL port = 0

SSL key = $(TWShome)/ssl/TWS.key

SSL certificate = $(TWShome)/ssl/TWS.crt

SSL key pwd = $(TWShome)/ssl/TWS.sth

SSL CA certificate = $(TWShome)/ssl/TWSTrustedCA.crt

SSL certificate chain = $(TWShome)/ssl/TWSCertificateChain.crt

SSL random seed = $(TWShome)/ssl/TWS.rnd

SSL Encryption Cipher = SSLv3

SSL auth mode = caonly

SSL auth string = tws



Configuración de la administración descentralizada

Puede administrar objetos de planificación de Tivoli Workload Scheduler desde

una sistema distinto del que tiene el gestor de dominio maestro de Tivoli Workload

Scheduler donde residen las bases de datos.

Si piensa administrar objetos de planificación de esta manera, debe crear recursos

compartidos para los directorios en el gestor de dominio maestro y definir un

conjunto de opciones locales en los demás sistemas.

Compartimiento de los directorios del maestro

Asegúrese de que los directorios siguientes se puedan compartir en el gestor de

dominio maestro y defina los permisos para dar control total al usuario del

dominio, TWS o maestro:

TWShome\mozart

TWShome\network

Compartimiento de parámetros de Tivoli Workload Scheduler

Los parámetros de sustitución de Tivoli Workload Scheduler son normalmente

específicos del sistema y se administran por separado en cada sistema. Si desea

que los parámetros sean comunes a todos los sistemas y se administren desde

cualquier sistema, puede compartir el directorio TWShome tal como se ha descrito

anteriormente para otros directorios, o bien copiar la base de datos de parámetros,

cada vez que cambie, desde el gestor de dominio maestro en cada uno de los

demás sistemas. Los archivos de la base de datos son:

TWShome\parameters

TWShome\parameters.KEY

Utilización de un sólo compartimiento

Como alternativa al compartimiento de directorios diferentes, puede trasladar

todos los archivos de la base de datos a un directorio común, compartir el

directorio y luego definir las opciones locales (descrito más abajo) para el nombre

de compartimiento. Los archivos de la base de datos son:

En TWShome\network\ :

cpudata

cpudata.KEY

userdata

userdata.KEY

En TWShome\mozart\ :

calendars

calendars.KEY

job.sched

job.sched.KEY

jobs

jobs.KEY

mastsked

mastsked.KEY

prompts

prompts.KEY

resources

resources.KEY

En TWShome:



parameters

parameters.KEY

Tivoli Workload Scheduler crea los archivos según sea necesario. Si los archivos no

existen, puede simplemente definir las opciones locales para el directorio

compartido, tal como se describe a continuación.

Definición de las opciones locales

Para acceder a las bases de datos compartidas del maestro, defina las opciones

locales en cada sistema desde la que desee administrar objetos de planificación de

Tivoli Workload Scheduler. En el presente tema se describen las opciones y el

procedimiento para modificarlas.

Observe que para cada opción se puede definir un nombre convencional

(unidad:\compartimiento) o un nombre según el convenio universal de

denominación (UNC) (\\nodo\compartimiento). Si se utiliza un nombre

convencional, el usuario de Tivoli Workload Scheduler se debe conectar

explícitamente al compartimiento. Si se utiliza un nombre UNC, no es necesaria

una conexión explícita. Las opciones locales son:

mozart directory

Define el nombre del directorio mozart compartido del maestro.

unison network directory

Define el nombre del directorio compartido del maestro.

parameters directory

Define el nombre del directorio TWShome compartido del maestro.

Si una opción no se define o no existe, los programas de Tivoli Workload

Scheduler intentan abrir los archivos de base de datos del sistema local. Consulte

el apartado “Definición de las opciones locales” para obtener más información.

Defina las opciones de esta manera en cada sistema:

1. Utilice un editor de su elección para abrir y modificar el archivo

TWShome\localopts.

2. Las opciones aparecen como comentarios en el archivo proporcionado por

Tivoli. Para definir una opción, elimine el signo # de la columna 1 y cambie el

valor para que apunte al directorio correcto. Por ejemplo, para acceder a todos

los objetos excepto los parámetros:

mozart directory = \\hub\mozart

unison network directory = \\hub\unison

# parameters directory = d:\maestro

3. Guarde el archivo y salga.

4. Detenga y reinicie Tivoli Workload Scheduler (incluido Netman) para hacer que

los cambios sean efectivos.

Si una opción no se define o no existe, el programa Composer de Tivoli Workload

Scheduler intenta acceder a los archivos de base de datos del sistema local.

Definición de las opciones locales en el maestro

Si los archivos de base de datos se han trasladado desde los directorios

predeterminados, deberá definir las opciones locales en el gestor de dominio

maestro en la ubicación nueva. Consulte el apartado “Definición de las opciones

locales”.



Mensajes de consola y mensajes de solicitud de Tivoli Workload

Scheduler

Los procesos de control de Tivoli Workload Scheduler (Netman, Mailman,

Batchman, Jobman y Writer) escriben sus mensajes de estado (denominados

mensajes de consola) en archivos de lista estándar. Estos mensajes incluyen los

mensajes de solicitud utilizados como dependencias de trabajos y secuencias de

trabajos. En UNIX, los mensajes también se pueden enviar hacia el daemon syslog

(syslogd) y hacia un terminal donde se ejecuta el gestor de consola de Tivoli

Workload Scheduler. Estas funciones se describen en las secciones siguientes.

Definición de sysloglocal en UNIX

Si asigna un número positivo a sysloglocal en el archivo de opciones locales, los

procesos de control de Tivoli Workload Scheduler envían sus mensajes de consola

y de solicitud hacia el daemon syslog. Establezca esa opción en -1 para desactivar

la función. Si establece la opción en un número positivo para habilitar el registro

del sistema, debe también establecer la opción local stdlistwidth en 0 o en un

número negativo.

Los mensajes de consola de Tivoli Workload Scheduler corresponden a los niveles

siguientes de syslog:

LOG_ERR

Mensajes de error, tales como la finalización anómala de un proceso de

control o un error del sistema de archivos.

LOG_WARNING

Mensajes de aviso, tales como un error de vínculo o una secuencia de

trabajos bloqueada.

LOG_NOTICE

Mensajes especiales, tales como mensajes de solicitud y tellops.

LOG_INFO

Mensajes informativos, tales como los que notifican el inicio de un trabajo

y cambios de estado de un trabajo o secuencia de trabajos.

Cuando sysloglocal está establecido en un número positivo, define el recurso de

registro del sistema utilizado por Tivoli Workload Scheduler. Por ejemplo,

especifique 4 para indicar a Tivoli Workload Scheduler que utilice el recurso local

LOCAL4. Una vez hecho esto, debe crear las entradas apropiadas en el archivo

/etc/syslog.conf y reconfigurar el daemon syslog. Para utilizar LOCAL4 y que los

mensajes de Tivoli Workload Scheduler se envíen a la consola del sistema,

especifique la línea siguiente en /etc/syslog.conf:

local4 /dev/console

Para que los mensajes de error de Tivoli Workload Scheduler se envíen a los

usuarios maestro y root, especifique lo siguiente:

local4.err maestro,root

Observe que los campos del selector y de la acción deben estar separados por una

tabulación como mínimo. Después de modificar /etc/syslog.conf, puede

reconfigurar el daemon syslog especificando este comando:

kill -HUP `cat /etc/syslog.pid`



El comando console

Puede utilizar el comando console de conman (gestor de consola) para establecer

el nivel de mensajes de Tivoli Workload Scheduler y dirigir los mensajes hacia la

terminal. El valor del nivel de mensajes sólo afecta a los mensajes de Batchman y

Mailman, que son los más numerosos. También define el nivel de los mensajes

escritos en el archivo o archivos de lista estándar y en el daemon syslog. Por

ejemplo, el comando siguiente establece en 2 el nivel de los mensajes de Batchman

y Mailman y envía los mensajes hacia el sistema del usuario:

console sess;level=2

Los mensajes se envían al sistema del usuario hasta que éste ejecute otro comando

console o concluya la ejecución de conman. Para detener el envío de mensajes a su

terminal, puede emitir este comando de conman:

console sys

Automatización del ciclo de producción

El proceso de pre-producción y post-producción se puede automatizar por

completo mediante la adición de la secuencia de trabajos final proporcionada por

Tivoli, o equivalente proporcionado por el usuario, a la base de datos de Tivoli

Workload Scheduler junto con otras secuencias de trabajos. El directorio

TWShome/Sfinal contiene una copia de la secuencia de trabajos proporcionada por

Tivoli, y el directorio TWShome/Jnextday contiene una copia del script de trabajo .

Puede serle útil disponer de copias impresas para ayudarle a comprender el

proceso de producción.

La secuencia de trabajos final se coloca en producción cada día, y da como

resultado la ejecución de un trabajo denominado Jnextday antes del inicio de un

nuevo día. El trabajo efectúa las tareas siguientes:

1. Vincula todas las estaciones de trabajo para asegurarse de que el gestor de

dominio maestro se ha actualizado con la información de planificación más

reciente.

2. Ejecuta el comando schedulr para seleccionar secuencias de trabajos para el

plan de producción del nuevo día.

3. Ejecuta el comando compiler para compilar el plan de producción.

4. Ejecuta el comandoreptr para imprimir informes de pre-producción.

5. Detiene Tivoli Workload Scheduler.

6. Ejecuta el comando stageman para traspasar a otro día secuencias de trabajos

no finalizadas, registrar el plan de producción antiguo e instalar el nuevo plan.

7. Inicia Tivoli Workload Scheduler para el nuevo día.

8. Ejecuta los comandos reptr y rep8 para imprimir informes de post-producción

del día anterior.

9. Ejecuta el comando logman para registrar estadísticas de trabajos del día

anterior.

En la biblioteca de publicaciones de Tivoli Workload Scheduler, los términos final

y Jnextday hacen referencia a las versiones proporcionadas por Tivoli y a cualquier

equivalente proporcionado por el usuario.



Personalización de la secuencia de trabajos final

Antes de utilizar la secuencia de trabajos final, puede modificarla según sus

necesidades, o puede crear una secuencia de trabajos diferente para utilizarla en su

lugar.

Si crea su propia secuencia de trabajos, utilice como modelo la secuencia de

trabajos proporcionada por Tivoli. En este caso, tenga en cuenta lo siguiente:

v Si modifica la forma en la que stageman crea los nombres de los archivos de

registro, recuerde que reptr y logman deben utilizar los mismos nombres.

v Si desea imprimir los informes de pre-producción antes de un nuevo día, puede

descomponer el trabajo Jnextday en dos trabajos. El primer trabajo ejecutará

schedulr, compiler y reptr. El segundo trabajo detendrá Tivoli Workload

Scheduler, ejecutará stageman, iniciará Tivoli Workload Scheduler y ejecutará

reptr y logman. Entonces el primer trabajo se puede planificar para ejecutarse en

un momento cualquiera antes del final del día, mientras que el segundo trabajo

se planifica para que se ejecute justo antes del final del día.

Consulte el apartado “Configuración de un gestor de dominio maestro” en la

página 79 para obtener información sobre la adición de la secuencia de trabajos

final a la base de datos.

Inicio de un ciclo de producción

Si no se ha iniciado antes, o si se hace necesario iniciar un nuevo día de

producción en un momento diferente del definido para el inicio del día, siga estos

pasos:

1. Inicie la sesión como usuario maestro en el gestor de dominio maestro.

2. En un indicador de comandos, ejecute conman "release final".

Esto efectuará un proceso de pre-producción e iniciará procesos de producción


Gestión del entorno de producción

Esta sección proporciona información sobre el cambio del inicio del día para Tivoli

Workload Scheduler y la creación de un plan para procesar días de proceso futuros

o pasados.

Elección del inicio del día

Existen tres opciones habituales para el inicio del día de producción.

v Primera hora de la mañana

v Última hora de la tarde

v Medianoche

Estas son algunas de las implicaciones para la planificación:

Hora de inicio y hora de inicio más tardía

Las horas de inicio (palabra clave AT) especificadas están siempre en

relación con la hora de inicio del día de producción del planificador. Puede

ser necesario añadir “+ 1 día” a las secuencias de trabajos cuyos trabajos se

ejecutan a lo largo de varios días de producción. Además, asegúrese de

que la hora de inicio más tardía (palabra clave UNTIL) sea una hora

posterior a la hora de inicio.

palabra clave ON

Los días de producción y los días de calendario pueden no ser los mismos.



Si su día de producción comienza a las 06:00 a.m. (el valor

predeterminado), 05:59 a.m. será el último minuto del día de producción.

Una secuencia de trabajos definida para ejecutarse el lunes (ON MONDAY)

a las 05:30, se seleccionará el lunes y se ejecutará en el día de calendario

martes a las 5:30 a.m.

palabra clave carryforward

El colocar el inicio del día cerca de medianoche para corresponderse con el

día de calendario tenderá a producir un gran número de secuencias de

trabajo trasladadas al día siguiente. Esto puede aumentar la complejidad

de la gestión del centro de proceso de datos.

plazo límite

Se envían notificaciones cuando un trabajo o secuencia de trabajos han

alcanzado su plazo límite, pero todavía no ha empezado o no ha

terminado de ejecutarse. Un plazo límite especifica el período dentro del

cual debe finalizar un trabajo o secuencias de trabajos.

Cambio del inicio del día

El inicio del día para Tivoli Workload Scheduler es cuando se ejecuta la secuencia

de trabajos final y se detienen y reinician los procesos de Tivoli Workload

Scheduler. Para especificar el inicio del día para Tivoli Workload Scheduler:

1. Modifique la opción start en el archivo Globalopts. Esta opción especifica la

hora de inicio del día de proceso de Tivoli Workload Scheduler en el formato

de 24 horas: hhmm (0000-2359 ). La hora de inicio predeterminada es 6:00 A.M.

2. Modifique la hora de inicio (palabra clave AT) de la secuencia de trabajos final

para que se ejecute 1 minuto antes del final del día.

Para especificar la medianoche como inicio del día de producción:

1. Establezca la hora de inicio de la secuencia de trabajos final en medianoche.

2. Establezca la opción start del archivo Globalopts en 0001.

En cambio, si el valor de la opción start es 0000 y el valor de Jnextday es 2359,

existe el riesgo de que seleccione planificaciones o secuencias de trabajos para el

día que acaba de terminar, pues el comando schedulr utiliza la fecha del sistema y

las redes pequeñas pueden a veces llegar a la ejecución de schedulr antes de

medianoche.

Creación de un plan para fechas futuras o pasadas

Puede crear un plan para ejecutar procesos que normalmente se planifican para un

día de proceso futuro o pasado. En la práctica, este procedimiento reconstruye

cualquier día de proceso especificado. Puede necesitar utilizar este procedimiento

si ha perdido un día de proceso debido a una urgencia.

1. Desvincule y detenga todas las estaciones de trabajo de la red de Tivoli

Workload Scheduler, utilizando estos comandos:

conman “unlink @!@;noask”

conman “stop @!@;wait”

Esto detiene todo el proceso en la red.

2. Ejecute el comando schedulr con la opción ″date″ para crear un archivo

prodsked:

schedulr -date MM/DD/AA

Con la opción ″date″ puede especificar crear un plan basado en un día de

proceso futuro o pasado.

3. Ejecute el comando compiler para crear un archivo symnew:



compiler (-date MM/DD/AA)

Puede utilizar la opción ″date″ con el compilador para especificar la fecha de

hoy o la fecha del día que desea reconstruir. Esta opción puede ser necesaria si

tiene secuencias de trabajos que contienen parámetros de entrada dependientes

de valores de fecha. El scheddate se especifica de acuerdo con la fecha

especificada con el comando compiler. Si no especifica una fecha, se utiliza por

omisión la fecha entrada con el comando schedulr.

4. Ejecute el gestor de consola para detener los procesos de Tivoli Workload

Scheduler:

conman stop @!@

5. Ejecute stageman para crear el nuevo archivo Symphony:

stageman

6. Ejecute el gestor de consola para iniciar los procesos de Tivoli Workload

Scheduler:

conman start

Utilización de los scripts de configuración

Tivoli Workload Scheduler proporciona dos scripts de configuración estándar, uno

a nivel global y otro a nivel local, para establecer el entorno de producción.

En el entorno de producción, los trabajos se inician bajo la dirección del proceso de

control de producción (Batchman). Batchman soluciona todas las dependencias de

trabajos para asegurar el orden de ejecución correcto y, a continuación, emite un

mensaje de ejecución de trabajo al proceso Jobman.

Jobman genera un proceso de monitor de trabajos que se inicia definiendo un

grupo de variables de entorno y, a continuación, éste ejecuta un script de

configuración estándar (maestrohome/jobmanrc). Si el usuario tiene permiso para

utilizar un script de configuración local y existe el script $HOME/.jobmanrc, el

script de configuración local también se ejecuta. Por lo tanto, bien el script de

configuración estándar o bien el script de configuración local ejecutan el trabajo.

Cada uno de los procesos que Jobman inicia, incluyendo los scripts de

configuración y los trabajos, conservan el nombre del usuario registrado al iniciar

la sesión del trabajo. En el caso de los trabajos enviados, conservan el nombre de

usuario del usuario que los envía. Para que los trabajos se ejecuten con el entorno

del usuario, asegúrese de añadir el entorno .profile del usuario en el script de

configuración local.

Variables de entorno de Jobman

Jobman establece y exporta las variables que aparecen en la tabla siguiente.

Tabla 28. Variables de entorno de Jobman

Variable Valor

HOME El directorio del nombre del usuario de

inicio de sesión

LOGNAME El nombre del usuario de inicio de sesión

PATH Para MS-Windows:

%SYSTEMROOT\SYSTEM32. Para UNIX:

/bin:/usr/bin

TZ El huso horario



Tabla 28. Variables de entorno de Jobman (continuación)

UNISON_SHELL El shell del inicio de sesión del usuario

UNISON_CPU El nombre de esta CPU

UNISON_HOST El nombre de la CPU maestra/host

UNISON_JOB El nombre del trabajo calificado al completo:

cpu#sched.job

UNISON_JOBNUM El número de trabajo (ppid)

UNISON_MASTER El nombre de la CPU maestra

UNISON_RUN El número de ejecución de producción actual

de Tivoli Workload Scheduler

UNISON_SCHED El nombre de la secuencia de trabajos

UNISON_SCHED_DATE La fecha de producción de Tivoli Workload

Scheduler (aammdd)

UNISON_SCHED_EPOCH La fecha de producción de Tivoli Workload

Scheduler, expresada en formato epoch

Script de configuración estándar - jobmanrc

Tivoli Workload Scheduler proporciona una plantilla de script de configuración

estándar denominada TWShome/config/jobmanrc. Se instala automáticamente como

TWShome/jobmanrc. El administrador del sistema puede utilizar este script para

establecer el entorno deseado antes de ejecutar cada trabajo. Si desea modificar el

script, efectúe las modificaciones en la copia de trabajo (TWShome/jobmanrc),

dejando intacto el archivo plantilla. El archivo contiene variables configurables y

comentarios para ayudarle a comprender la metodología. Tabla 29 describe las

variables jobmanrc.

Tabla 29. Variables de jobmanrc

Variable Valor

UNISON_JCL Es el nombre de ruta del archivo de script del

trabajo.

UNISON_STDLIST Es el nombre de ruta del archivo de lista

estándar del trabajo.

UNISON_EXIT yes|no

v Si se establece en yes, el trabajo termina

inmediatamente si cualquier comando

devuelve un código de salida distinto de

cero.

v Si se establece en no, el trabajo sigue

ejecutándose si un comando devuelve un

código de salida distinto de cero.

Cualquier otro valor se interpreta como no.



Tabla 29. Variables de jobmanrc (continuación)

Variable Valor

LOCAL_RC_OK yes|no

v Si se establece en yes, se ejecuta el script de

configuración local del usuario (si existe), y

se pasa $UNISON_JCL como primer

argumento. Esta opción se puede permitir o

denegar al usuario. Consulte el apartado

“Script de configuración local - .jobmanrc” en

la página 111 para obtener más información.

v Si se establece en no, no se tiene en cuenta la

presencia de un script de configuración local

y se ejecuta $UNISON_JCL.

Cualquier otro valor se interpreta como no.

MAIL_ON_ABEND yes|no

v Si se establece en yes, se envía un mensaje al

buzón del usuario de inicio de sesión si el

trabajo termina con un código de salida

distinto de cero. Como valor de esta opción

se pueden también especificar uno o más

nombres de usuario, separados por espacios,

y se enviará un mensaje a cada usuario. Por

ejemplo, ″root mis sam mary″.

v Si el valor es no, no se envían mensajes

cuando el trabajo finaliza de forma anómala.

Los mensajes de finalización anómala tienen

este formato:

cpu#sched.job

archivo_jcl ha fallado con código_salida

Por

favor, examine archivo_lista_estándar



Tabla 29. Variables de jobmanrc (continuación)

Variable Valor

SHELL_TYPE standard|user|script

v Si se establece en standard se lee la primera

línea del archivo jcl para determinar qué

shell se debe utilizar para ejecutar el trabajo.

Si la primera línea no empieza con #! se

utiliza /bin/sh para ejecutar el script del

configuración local o UNISON_JCL. La salida

de los comandos se envía al archivo de lista


v Si se establece en user, el script de

configuración local o $UNISON_JCL se

ejecuta mediante el shell de inicio de sesión

del usuario ($UNISON_SHELL). La salida de

los comandos se envía al archivo de lista


v Si se establece en script (valor

predeterminado), el script de configuración

local o $UNISON_JCL se ejecuta

directamente, y la salida de los comandos no

se reenvía a menos que el script de

configuración local o $UNISON_JCL

contenga un comando set -x.

Cualquier otro valor se interpreta como

standard.

USE_EXEC yes|no

v Si se establece en yes, el trabajo o el script de

configuración local del usuario se ejecuta

utilizando el comando exec, con lo que se

elimina un proceso adicional. Si se solicita un

sub-shell (vea SHELL_TYPE), se ejecutará el

shell que se está utilizando. Es decir, una vez

ejecutado el comando/script, el proceso

″jobmanrc″ deja de existir, por lo que

USE_EXEC debe tomar el valor ″NO″ si la

función ″MAIL_ON_ABEND″ está habilitada.

En este caso, el proceso necesita regresar a

″jobmanrc″ para permitir el post-proceso.

Esta opción no se tiene en cuenta si

MAIL_ON_ABEND también tiene el valor

yes.

v Cualquier otro valor se interpreta como no,

en cuyo caso el trabajo o el script de

configuración local lo ejecuta otro proceso de

shell.

Script de configuración local - .jobmanrc

El script de configuración local permite a los usuarios establecer un entorno

deseado para la ejecución de sus propios trabajos. A diferencia del script jobmanrc,

el script .jobmanrc se puede personalizar para que efectúe acciones diferentes para

usuarios diferentes. Cada usuario definido en el directorio inicial puede

personalizar el script .jobmanrc para realizar acciones de pre-proceso y

post-proceso. Cuando se ejecuta un trabajo, Tivoli Workload Scheduler inicia el

script jobmanrc, el cual define las variables de entorno necesarias, inicia el



comando y notifica el estado del trabajo a Jobman para registrarlo en el plan

actual. El script .jobmanrc es un paso adicional que se produce antes de que el

trabajo se inicie propiamente.

Para ejecutar el script, siga estas directrices:

1. Para utilizar el script .jobmanrc, debe instalar el script de configuración

estándar jobmanrc y la variable de entorno LOCAL_RC_OK debe establecerse

en yes (consulte la Tabla 29).

2. Para permitir el uso de .jobmanrc sólo a determinados usuarios, establezca

LOCAL_RC_OK en yes y especifique una lista de usuarios permitidos en el

siguiente archivo: TWShome/localrc.allow. Sólo los usuarios definidos en este

archivo podrán utilizar .jobmanrc. Si dicho archivo no existe, el nombre de

usuario no debe aparecer en TWShome/localrc.deny. Si no existe ninguno de

esos dos archivos, el usuario tiene permiso para utilizar el script de

configuración local. Como alternativa, puede definir una lista de usuarios en el

archivo TWShome/localrc.deny para los usuarios que no deberían utilizar el

script .jobmanrc.

3. El script de configuración local debe estar instalado en el directorio inicial del

usuario (TWShome/.jobmanrc) y debe tener permiso de ejecución.

4. Los trabajos no se ejecutan automáticamente, el comando o script debe iniciarse

desde dentro de .jobmanrc. En función del tipo de actividad de proceso que

desee realizar, el comando o script se inicia de forma diferente. Siga estas reglas

generales:

v Si el trabajo a ejecutar es un comando, utilice eval

v Si el trabajo a ejecutar es un script y no es necesario ningún post-proceso,

utilice exec o eval

v Si el trabajo a ejecutar es un script y es necesario algún post-proceso, utilice

eval

Si piensa utilizar un script de configuración local, éste debe ejecutar como mínimo

el archivo de script del trabajo ($UNISON_JCL). El script de configuración estándar

proporcionado por Tivoli, jobmanrc, ejecuta el script de configuración local del

usuario de la manera siguiente:

$EXECIT $USE_SHELL $TWSHOME/.jobmanrc "$UNISON_JCL" $IS_COMMAND

El valor de USE_SHELL se establece en el valor de la variable SHELL_TYPE de

jobmanrc (consulte la Tabla 29 en la página 109). IS_COMMAND se establece en

yes si el trabajo se ha planificado o se ha enviado utilizando la estructura

docommand. EXECIT se establece en exec si la variable USE_EXEC se define en

yes (consulte la Tabla 29 en la página 109); de lo contrario, es nulo. Todas las

variables exportadas a jobmanrc están disponibles en el shell de .jobmanrc. Sin

embargo, las variables que están definidas, pero no exportadas, no están

disponibles.

A continuación dispone de un ejemplo de un script .jobmanrc que efectúa tareas

de proceso de acuerdo con el código de salida del trabajo del usuario:

##### Start of .jobmanrc script #####

#!/bin/sh

echo "*********************************"

echo "* Entering .jobmanrc processing *"

echo "*********************************"

echo ""

echo "**************************************"

echo "* Doing some pre-processing activity *"



echo "**************************************"

echo ""

echo "Setting variable USER_DEFINED_VARIABLES"

echo ""

USER_DEFINED_VARIABLES=some_value

export USER_DEFINED_VARIABLES

echo "************************************"

echo "* Launching the TWS command/script *"

echo "************************************"

echo ""

eval "$UNISON_JCL"

RETURN_CODE=$?

echo "*******************************************"

echo "* Executing post processing into .jobmanrc*"

echo "*******************************************"

echo ""

if [ $RETURN_CODE -gt 0 ]

then

echo "Return code from commnad = " $RETURN_CODE

echo "Setting Return Code to 0"

RETURN_CODE=0

fi

exit $RETURN_CODE

##### End of .jobmanrc script #####

Tivoli Workload Scheduler y Tivoli Management Framework

Esta sección incluye los temas siguientes sobre Tivoli Workload Scheduler y Tivoli

Management Framework:

v “Tivoli Management Framework para usuarios que no utilizan Tivoli”

v “Adición de administradores de Tivoli” en la página 114

v “Consideraciones sobre el maestro de copia de seguridad” en la página 116

v “Maestros que no dan soporte a Tivoli Management Framework” en la página

117

Tivoli Management Framework para usuarios que no utilizan

Tivoli

Tivoli Management Framework es una infraestructura abierta, orientada a objetos,

que incluye un conjunto de gestores, intermediarios y agentes que se ajustan a la

especificación OMG/CORBA (Object Management Group/Common Object Request

Broker Architecture). La tecnología OMG/CORBA permite ocultar al usuario

diferencias importantes existentes entre los sistemas operativos, y permite

encapsular servicios clave dentro de objetos que pueden ser utilizados por varias

aplicaciones de gestión. Tivoli Management Framework proporciona independencia

respecto de la plataforma, una arquitectura unificadora para todas las aplicaciones

y un conjunto variado de interfaces de programas de aplicación (API) que han sido

adoptadas por DMTF (Desktop Management Task Force) y The Open Group (antes

denominado X/Open) como base para una infraestructura de gestión de sistemas.

Las API de Tivoli proporcionan servicios comunes de red y gestión de sistemas,

tales como la planificación, el soporte de transacciones y los perfiles de

configuración, así como un recurso de objeto genérico para usuarios de bases de

datos.



La unidad básica de la funcionalidad de Tivoli Management Framework es la

región de gestión Tivoli. Una región consta de un servidor Tivoli y los clientes que

el servidor gestiona. El servidor Tivoli contiene la base de datos correspondiente a

la región. Dependiendo del tamaño y los requisitos de un entorno, se puede definir

más de una región. Si existen varias regiones, pueden ser autónomas o bien estar

conectadas entre sí para compartir información y recursos. Los administradores con

el rol apropiado pueden gestionar desde un mismo sistema todos los recursos

intercambiados existentes en un conjunto de regiones conectadas, como si los

recursos estuvieran todos en la región del sistema local. En general, un servidor

Tivoli puede atender un máximo de 200 nodos totalmente gestionados. A partir de

Tivoli Management Framework 3.6 y posterior, se ubican nuevos servicios en el

servidor Tivoli y en algunos nodos gestionados para permitir que estos nodos

actúen como gateways para cientos de puntos finales. Esto aumenta

significativamente el ámbito de actuación de una región individual.

Tivoli Management Framework proporciona una implementación basada en

servidores de un Intermediario de petición de objeto (ORB) de CORBA y de un

adaptador de objeto básico (BOA). También proporciona servicios afines para

objetos, de gestión y escritorio e incluye una implementación de las API adoptadas

por The Open Group para una infraestructura de gestión de sistemas. El asignador

de objetos (oserv) es el componente principal de la unidad ejecutable de la

infraestructura. Se implementa en forma de proceso individual de varios threads

que se ejecuta como proceso de fondo en cada cliente Tivoli de una región y en el

servidor Tivoli de esa región. El asignador de objetos consta de un intermediario

de petición de objeto, el BOA y servicios asociados. El asignador de objetos que se

ejecuta en el servidor Tivoli proporciona servicios adicionales, tales como

seguridad y resolución de herencia de implementación.

Un nodo gestionado Tivoli ejecuta el mismo software que se ejecuta en un servidor

Tivoli. Desde un nodo gestionado puede ejecutar el escritorio de Tivoli y gestionar

directamente otros recursos gestionados de Tivoli. Un nodo gestionado tiene su

propio servicio oserv, que se ejecuta continuamente y se comunica con el servicio

oserv del servidor Tivoli. Un nodo gestionado también mantiene su propia base de

datos cliente. La diferencia principal entre un servidor Tivoli y un nodo gestionado

es el tamaño de la base de datos. Además, no puede existir un nodo gestionado sin

un servidor Tivoli en una región de gestión Tivoli.

Adición de administradores de Tivoli

Suponga que desea instalar el conector en el gestor de dominio maestro para poder

tener varios clientes de Job Scheduling Console. El archivo de Seguridad actual

contenido en el maestro es el siguiente:

###########################################################

# Security File

###########################################################

# (1) APPLIES TO MAESTRO OR ROOT USERS LOGGED IN ON THE

# MASTER DOMAIN MANAGER

user mastersm cpu=$master + logon=maestro,root

begin

# OBJECT ATTRIBUTES ACCESS CAPABILITIES

# ---------- ------------ ----------------------

job access=@

schedule access=@

resource access=@

prompt access=@

file access=@

calendar access=@

cpu access=@

parameter name=@ ~ name=r@ access=@



userobj cpu=@ + logon=@ access=@

end

###########################################################

# (2) APPLIES TO MAESTRO OR ROOT USERS LOGGED IN ON ANY

# WORKSTATION OTHER THAN THE MASTER DOMAIN MANAGER.

user sm logon=maestro,root

begin


# ---------- ------------ ----------------------

job cpu=$thiscpu access=@

schedule cpu=$thiscpu access=@

resource cpu=$thiscpu access=@

prompt access=@

file access=@

calendar access=@

cpu cpu=$thiscpu access=@

parameter cpu=$thiscpu

~ name=r@ access=@

end

###########################################################

Suponga que desea que estos dos usuarios utilicen Job Scheduling Console.

Después de instalar el software de Tivoli Management Framework, desde el

escritorio de Tivoli puede crear un administrador de Tivoli adicional para cada

usuario (además del administrador predeterminado creado por el proceso de

instalación). Un administrador se puede denominar mastersm y el otro se puede

denominar sm. A continuación, añada las definiciones respectivas, con lo que el

archivo de Seguridad tendrá este aspecto:

###########################################################

# Security File

###########################################################

# (1) APPLIES TO MAESTRO OR ROOT USERS LOGGED IN ON THE


user mastersm cpu=$master + logon=maestro,root

begin


# ---------- ------------ ----------------------

job access=@

schedule access=@

resource access=@

prompt access=@

file access=@

calendar access=@

cpu access=@



end

###########################################################

# (2) TIVOLI ADMINISTATOR DEFINITION FOR MAESTRO OR ROOT USERS

LOGGED IN ON THE


user mastersm cpu=$framework + logon=mastersm

begin


# ---------- ------------ ----------------------

job access=@

schedule access=@

resource access=@

prompt access=@

file access=@

calendar access=@

cpu access=@



end



###########################################################

###########################################################

# (3) APPLIES TO MAESTRO OR ROOT USERS LOGGED IN ON ANY

# WORKSTATION OTHER THAN THE MASTER DOMAIN MANAGER.

user sm logon=maestro,root

begin


# ---------- ------------ ----------------------




prompt access=@

file access=@

calendar access=@



~ name=r@ access=@

end

##############################################

################

(4) TIVOLI ADMINISTRATOR DEFINITION FOR MAESTRO OR

ROOT USERS LOGGED IN ON ANY

# WORKSTATION OTHER THAN THE MASTER DOMAIN

MANAGER.

user sm cpu=$framework + logon=sm

begin


# ---------- ------------ ----------------------




prompt access=@

file access=@

calendar access=@



~ name=r@ access=@

end

##########################################################

El nuevo archivo de Seguridad otorga los mismos privilegios a los usuarios

originales también en Job Scheduling Console.

Además, en el servidor Tivoli podría añadir dos nuevos nombres de inicio de

sesión para el Administrador de Tivoli mastersm:

[email protected]

[email protected]

De esta forma, cualquier usuario autorizado que se conecte a rome o london como

maestro adquirirá los privilegios otorgados a mastersm.

Consideraciones sobre el maestro de copia de seguridad

Si desea instalar el conector en el maestro de copia de seguridad, no existe ninguna

región y no desea implementar un entorno de gestión Tivoli completo, puede

instalar un nuevo servidor Tivoli en el maestro de copia de seguridad.

Si en el maestro de copia de seguridad instala un servidor Tivoli diferente que el

maestro, asegúrese de que habilita las mismas entradas que en el maestro, es decir:

v Inicio

v Plan y niveles de auditoría de base de datos



v Opción global de habilitación de huso horario

Maestros que no dan soporte a Tivoli Management Framework

Si el gestor de dominio maestro no se ejecuta en una plataforma que da soporte al

servidor o nodo gestionado de Tivoli Management Framework y al conector, y

desea poder utilizar Job Scheduling Console, puede elegir de entre estas tres

opciones:

v Traslade el gestor de dominio maestro a una de las plataformas soportadas.

v Cree un maestro de copia de seguridad en una plataforma soportada.

v Mediante NFS, monte las bases de datos del maestro.

Traslado del maestro de copia de seguridad

Para trasladar el gestor de dominio maestro (desde UNIX a UNIX):

1. Seleccione un agente tolerante a errores existente en la red o cree uno. Si crea

un agente tolerante a errores, asegúrese de que su definición tenga habilitadas

las opciones Resolver dependencias y Estado completo.

2. En el gestor de dominio maestro, ejecute tar para TWShome/mozart/* y

TWShome/network/*.

3. Mediante untar, despliegue estos archivos en directorios del mismo nombre

del agente tolerante a errores.

4. No copie parámetros ni parameters.KEY del directorio inicial; de lo contrario

sobrescribirá parámetros que son exclusivos del agente tolerante a errores.

Cree una lista de parámetros de ambas máquinas, y añada los necesarios al

agente tolerante a errores.

5. En el agente tolerante a errores, edite el archivo globalopts para cambiar el

nombre del maestro por el nombre del agente tolerante a errores.

6. En el maestro antiguo, utilice el comando switchmgr para conmutar al nuevo

maestro.

7. Cancele la planificación final existente en la producción del día actual.

8. Añada la planificación final al nuevo maestro (utilice

composer “modify sched=nombre_maestro_antiguo#final”

y cambie el ID de estación de trabajo en la línea de planificación).

9. Después de guardar y añadir, suprima la planificación oldmastername#final

con este comando:

composer “delete sched=nombre_maestro_antiguo#final”

10. Envíe la nueva planificación final a la producción diaria.

11. En el maestro antiguo, edite el archivo globalopts para que refleje el nombre del

nuevo maestro.

Nota: No es necesario editar todas las opciones globales para cada estación de

trabajo de la red. Los nodos reconocerán el nuevo maestro en el

próximo Jnextday cuando el maestro inicialice los nodos.

Creación de un maestro de copia de seguridad

Para crear un maestro de copia de seguridad:

1. Instale Tivoli Management Framework. Consulte el manual Tivoli Enterprise

Installation Guide para obtener información.

2. Instale el motor de Tivoli Workload Scheduler. Consulte el Capítulo 3,

“Instalación mediante el asistente de instalación”, en la página 39 o el

Capítulo 6, “Instalación mediante customize”, en la página 61.



3. Instale el conector. Consulte el capítulo del manual Tivoli Workload Scheduler Job

Scheduling Console - Guía del usuario donde se describe cómo instalar el conector.

4. Personalice la estación de trabajo con opciones de seguridad y opciones locales

de Tivoli Workload Scheduler. Consulte el Capítulo 11, “Definición de la

seguridad”, en la página 153 y el Capítulo 9, “Personalización opcional”, en la

página 87.

5. Defina la estación de trabajo en la red de Tivoli Workload Scheduler. Utilice el

comando cpuname de Composer o la ventana Crear estaciones de trabajo de

Job Scheduling Console. Asegúrese de que la definición de la estación de

trabajo tenga habilitadas las opciones Resolver dependencias y Estado

completo. Consulte los manuales IBM Tivoli Workload Scheduler - Guía de consulta

o IBM Tivoli Job Scheduling Console - Guía del usuario.

Montaje de bases de datos del gestor de dominio maestro

Mediante NFS, puede montar las siguientes bases de datos del maestro en un

agente tolerante a errores que se ejecuta en una plataforma soportada:

v /usr/lib/maestro/mozart/globalopts (la copia funcional)

v /usr/lib/unison/network/cpudata

El agente tolerante a errores debe tener habilitadas las opciones Estado completo y

Resolver dependencias en su definición de estación de trabajo.

Antes de montar las bases de datos, asegúrese de que el sistema de archivos donde

residen los directorios necesarios se ha incluido en el archivo /etc/exports de la

estación de trabajo maestra. Si elige controlar la disponibilidad del sistema de

archivos, cree las entradas apropiadas en el archivo /etc/hosts o /etc/netgroup del

maestro.

El punto de montaje en el agente tolerante a errores debe ser el mismo que el del

maestro. Por ejemplo, en el agente tolerante a errores:

cd twshome

/etc/mount nombre_maestro :mozart mozart

/etc/mount nombre_maestro :../unison/network

../unison/network

Para hacer que las bases de datos se monten automáticamente, puede especificar

las operaciones de montaje en el archivo /etc/checklist.

Si utiliza este método, tenga en cuenta que la base de datos de parámetros

contenida en el agente tolerante a errores no es la del maestro, sino que es una

copia local. Esto es importante cuando utiliza parámetros como parte de la

definiciones de trabajos (en el nombre de tarea o nombre de inicio de sesión), pues

cuando se alcanza el momento especificado por Jnextday, todos los parámetros

especificados con el símbolo de intercalación ( ^ ) en las definiciones de trabajos se

amplían a partir de la base de datos de parámetros del maestro. Existen dos

soluciones posibles a este problema:

v Cree un script para cargar y cambiar los valores de parámetros desde el agente

tolerante a errores al maestro. Ejecute este script justo antes de que se alcance

Jnextday. El crear una dependencia respecto de Jnextday asegura que los

parámetros se carguen satisfactoriamente antes de que Jnextday prepare la

producción para el día siguiente.



v En la cpu maestra, traslade la base de datos de parámetros al directorio mozart.

Cree un vínculo desde el maestro al directorio inicial. A continuación, en el

agente tolerante a errores, cree un vínculo desde la base de datos de parámetros

de mozart al directorio twshome.

Si desea habilitar la función de huso horario en Job Scheduling Console, también

es necesario que edite el archivo local globalopts en el agente tolerante a errores

para definir la entrada timezone enable.



Capítulo 10. Integración con otros productos de IBM Tivoli

IBM Tivoli Workload Scheduler proporciona integración inmediata con los

siguientes productos de IBM:

v IBM Tivoli NetView

v IBM Tivoli Business Systems Manager

v IBM Tivoli Enterprise Data Warehouse

v IBM Tivoli Distributed Monitoring (Classic Edition)

v IBM Tivoli Enterprise Console

v IBM Tivoli Management Framework

Este capítulo describe la integración con Tivoli NetView, Tivoli Business Systems

Manager y Tivoli Enterprise Data Warehouse.

La integración con Tivoli Distributed Monitoring (Classic Edition) y Tivoli

Enterprise Console se realiza utilizando Tivoli Workload Scheduler Plus Module,

Versión 8.2, tal y como se describe en el manual IBM Tivoli Workload Scheduler Plus

Module, Versión 8.2, Guía del usuario.

La integración con Tivoli Management Framework es un requisito previo del

conector de Tivoli Workload Scheduler para integrarse con Job Scheduling Console

o Tivoli Plus Module para Tivoli Workload Scheduler. La integración con Tivoli

Management Framework también permite gestionar todas las estaciones de trabajo

físicas donde se ha instalado el punto final de Tivoli, utilizando las funciones de la

suite de productos basada en Tivoli Framework.

Integración con IBM Tivoli Enterprise Data Warehouse

Cuando el entorno contiene muchos productos y servicios para gestionar y

supervisar la empresa de TI, el almacenamiento de estos datos, la creación de

informes y el análisis de los datos se convierte en una tarea compleja. IBM Tivoli

Enterprise Data Warehouse permite reunir estos datos en un sólo lugar, un

depósito de datos central, y ofrece una visión completa del negocio para ver sus

componentes independientemente de las aplicaciones específicas.

Tivoli Workload Scheduler proporciona un paquete de habilitación de Tivoli

Enterprise Data Warehouse para consolidar datos de planificación en la base de

datos de Tivoli Enterprise Data Warehouse. La documentación del paquete de

habilitación de depósito se encuentra en el disco 2 de instalación de Tivoli

Workload Scheduler, en la ruta

tedw_apps_etl/aws/pkg/v820/doc/TivoliWorkloadScheduler8.2_for_TEDW.doc.

Integración con IBM Tivoli NetView

Esta sección describe la integración de IBM Tivoli Workload Scheduler en UNIX

con NetView para AIX.

General

Tivoli Workload Scheduler/NetView es una aplicación de NetView que permite a

los gestores (o administradores) de la red supervisar y diagnosticar redes de Tivoli

Workload Scheduler desde un nodo de gestión de NetView.


Incluye un conjunto de submapas y símbolos para visualizar redes del planificador

de forma topográfica y determina el estado de la actividad de planificación de

trabajos y los procesos del planificador críticos en cada estación de trabajo. Las

acciones del menú permiten iniciar y detener los procesos del planificador y

ejecutar conman en cada estación de trabajo de la red.

Cómo funciona Tivoli Workload Scheduler/NetView

Tivoli Workload Scheduler/NetView consiste en software de gestor y de agente. El

gestor se ejecuta en los nodos de gestión de NetView y el agente se ejecuta en los

nodos gestionados. Todos los nodos deben tener instalado Tivoli Workload

Scheduler para UNIX. El gestor (mdemon sólo se ejecuta en AIX) sondea a sus

agentes (magent) de forma periódica para obtener información sobre los procesos

del planificador. Si la información devuelta durante un sondeo es distinta de la del

sondeo precedente, el color del símbolo correspondiente cambia para señalar el

cambio de estado. Por ejemplo, de verde (normal) pasa a rojo (crítico) o amarillo

(marginal). Después de actuar para remediar una condición marginal o crítica, el

siguiente sondeo devuelve el símbolo correspondiente al estado normal.

El agente también genera condiciones de excepción de SNMP para informar al

gestor sobre sucesos asincrónicos tales como trabajos que terminan de forma

anómala, planificaciones bloqueadas y procesos del planificador reiniciados.

Aunque los sondeos y las condiciones de excepción son funcionalmente

independientes, la información que acompaña a una condición de excepción puede

estar relacionada con cambios en el símbolo de estado. Si, por ejemplo, un trabajo

planificado termina de forma anómala, el símbolo para la estación de trabajo

cambia de color y se registra una condición de excepción de terminación anómala

de trabajo en el registro de eventos de NetView. Al examinar el registro, podrá

aislar el problema rápidamente y tomar las medidas adecuadas.

El proceso muser ejecuta los comandos que emite un usuario de NetView y

actualiza el mapa del usuario. Se inicia un muser para cada usuario de NetView

cuyo mapa tenga activada la aplicación Tivoli Workload Scheduler/NetView.

Tipos de información

El gestor recopila dos tipos de información sondeando a sus agentes:

Planificación de trabajos

Indica el estado de los trabajos y las planificaciones de una red de Tivoli

Workload Scheduler. Un único agente proporciona la información, el cual

normalmente se ejecuta en el maestro de la red. De forma alternativa, también

puede suministrar la información un agente que se ejecute en un agente

tolerante a errores que se haya configurado como maestro de copia de

seguridad.

Proceso supervisado

Indica el estado de los procesos críticos del planificador en una estación de

trabajo (netman, mailman, batchman, jobman, servidores mailman, writers y

todas las conexiones de agentes ampliados). Esta información la proporcionan

únicamente agentes locales que se ejecutan en cada estación de trabajo.

Definiciones

CPU y nodo

Los términos CPU y nodo se utilizan indistintamente para referirse a una

estación de trabajo.

Nodos de gestión

Un nodo de gestión de NetView que ejecuta un gestor de Tivoli Workload

Integración de productos


Scheduler/NetView (mdemon). En NetView 6.x y posterior, las funciones del

nodo de gestión pueden distribuirse por un servidor y uno o varios servidores.

Nodo gestionado

Los nodos que comprende una red de Tivoli Workload Scheduler y que

permiten la ejecución del agente de Tivoli Workload Scheduler/NetView

(magent).

Red de Tivoli Workload Scheduler gestionada

Un grupo de nodos que se han configurado como una red de Tivoli Workload

Scheduler y cuyo estado de planificación de trabajos se gestiona desde un nodo

de gestión de NetView. Desde un único nodo de gestión puede gestionarse más

de una red.

Requisitos generales

Los requisitos de configuración básicos son los siguientes:

v Los nodos de gestión (servidor y clientes) deben tener Tivoli Workload

Scheduler instalado, pero no tienen por qué ser miembros de redes de

planificador gestionadas.

v Los gestores de Tivoli Workload Scheduler/NetView (mdemon) se ejecutan

exclusivamente en AIX. Los agentes de Tivoli Workload Scheduler/NetView

(magent) se ejecutan en AIX, HPUX y Solaris.

v Debe haber como mínimo un nodo gestionado en una red de planificador

gestionada. Para garantizar la precisión de la información de planificación de

trabajos, este debería ser el maestro o el maestro de copia de seguridad, es decir,

un agente tolerante a errores con fullstatus on y resolvedep en su definición.

Configuración

El nodo de gestión de NetView puede o no ser miembro de una red de Tivoli

Workload Scheduler gestionada.

El agente de Tivoli Workload Scheduler/NetView puede ejecutarse en estaciones

de trabajo maestras, proporcionando información precisa sobre la planificación de

trabajos en sus redes de Tivoli Workload Scheduler respectivas. De forma

alternativa, los agentes pueden ejecutarse en maestros de reserva. En cualquier

caso, pueden instalarse agentes adicionales en otras estaciones de trabajo del

planificador para supervisar el estado de sus procesos críticos.

Cuando planifique la configuración, debería considerar lo siguiente:

v Si elige utilizar una estación de trabajo maestra, o un maestro de copia de

seguridad, como el nodo de gestión de NetView, también puede tener un agente

de Tivoli Workload Scheduler/NetView que proporcione estado de planificación

de trabajos para su red de Tivoli Workload Scheduler. Esto reduce el tráfico

gestor-agente de Tivoli Workload Scheduler/NetView durante el sondeo. Sin

embargo, también debe tener en cuenta la carga de trabajo adicional que impone

la gestión de NetView, particularmente en redes de gran tamaño y en aquellas

que tienen varias aplicaciones de NetView, que puede ralentizar sensiblemente

los procesos de Tivoli Workload Scheduler.

v La elección de un agente estándar de Tivoli Workload Scheduler como un nodo

de gestión de NetView, o la utilización del nodo de gestión de NetView actual

como un agente estándar, tiene la ventaja de no sobrecargar el maestro y de

permitir la utilización de Tivoli Workload Scheduler en dicho nodo para

planificar tareas de gestión de NetView, como el vaciado de los archivos de

registro.


Capítulo 10. Integración con otros productos de IBM Tivoli 123

Instalación del software de integración

El software de Tivoli Workload Scheduler/NetView se entrega y se instala como

parte de Tivoli Workload Scheduler en UNIX. Antes de realizar los pasos siguientes

para Tivoli Workload Scheduler/NetView, asegúrese de que Tivoli Workload

Scheduler para UNIX está correctamente instalado en el nodo de gestión (servidor

y clientes) y en cada nodo gestionado.

Puesto que la finalidad de Tivoli Workload Scheduler/NetView consiste en

supervisar el funcionamiento de Tivoli Workload Scheduler para UNIX, los nuevos

usuarios deberían:

1. Instalar e implementar Tivoli Workload Scheduler para UNIX hasta que

comprendan bien su funcionamiento y sean capaces de planificar y realizar el

seguimiento de sus propios trabajos.

2. Siga los pasos descritos a continuación para instalar Tivoli Workload

Scheduler/NetView.

Ejecución del script customize

Como parte del procedimiento de instalación, debe ejecutar el script customize de

Tivoli Workload Scheduler/NetView en los nodos gestionados y los nodos de

gestión de NetView. El script customize realiza los pasos siguientes:

Determinación del directorio inicial de Tivoli Workload Scheduler: Al directorio

inicial del usuario de Tivoli Workload Scheduler, normalmente /usr/lib/maestro,

se le denomina TWShome en toda esta sección. Este es el directorio que ha definido

al instalar Tivoli Workload Scheduler. El script customize de Tivoli Workload

Scheduler/NetView determina el directorio inicial del usuario y lo utiliza para

instalar correctamente Tivoli Workload Scheduler/NetView.

Utilización de customize en nodos gestionados: En nodos gestionados, customize

hace lo siguiente:

1. Modifica TWShome/StartUp para añadir un comando que ejecute el agente

Maestro/NV (magent).

2. Crea los siguientes archivos de configuración:

TWShome/BmEvents.conf

TWShome/MAgent.conf

3. Además, para cada nodo de AIX:

a. Modifica /etc/snmpd.conf para añadir un nuevo agente smux y definir el

nodo de destino para las condiciones de excepción.

b. Modifica /etc/snmpd.peers para configurar el nuevo agente smux.

c. Modifica /etc/mib.defs para añadir la MIB de Unison Software.4. Para NetView versión 6.x y posterior, si el nodo gestionado es un cliente de

NetView, se instala el ARF (Application Registration File, Archivo de registro de

aplicación) de Tivoli Workload Scheduler.

Utilización de customize en el nodo de gestión y en la versión 6.x del servidor

NetView: En el nodo de gestión y en la versión 6.x del servidor NetView,

customize hace lo siguiente:

1. Realiza los pasos descritos anteriormente para los nodos gestionados.

2. Registra el proceso mdemon de Tivoli Workload Scheduler/NetView para que

lo inicie NetView.

3. Añade las condiciones de excepción de empresa de Unison Software.

4. Copia los archivos, la aplicación, la MIB y los archivos de ayuda de Tivoli

Workload Scheduler en la estructura de directorios correspondiente.



Utilización de customize en clientes de la versión 6.x de NetView: En los

clientes de la versión 6.x de NetView, customize hace lo siguiente:

1. Realiza los pasos descritos anteriormente para los nodos gestionados.

2. Copia la aplicación y los archivos de ayuda de Tivoli Workload

Scheduler/NetView en la estructura de directorios correspondiente. El ARF

(Application Registration File, Archivo de registro de aplicación) que instala

Tivoli Workload Scheduler/NetView utiliza la prestación nvserver_run de

NetView para iniciar la aplicación en el servidor.

Revisión de los cambios: Si desea revisar los cambios efectuados por customize

antes de instalar los archivos, ejecute el script con la opción -noinst, de la siguiente

manera:

/bin/sh TWShome/OV/customize -noinst

Cree los archivos en el directorio /tmp. Cuando se ejecute customize, se le indicará

dónde debe trasladar los archivos para finalizar la instalación. De forma

alternativa, puede eliminar los archivos de /tmp y ejecutar de nuevo customize sin

la opción -noinst.

Eliminación de los cambios: Para desinstalar Tivoli Workload

Scheduler/NetView, y eliminar los cambios efectuados por customize, ejecute el

script decustomize:

/bin/sh TWShome/OV/decustomize

Sinopsis de customize: La sintaxis de customize es la siguiente:

customize [-uname name] [-prev3] [-noinst] [-client] [-manager host ]

donde:

[-uname name]

Nombre de usuario de IBM Tivoli Workload Scheduler.

-prev3 Incluya esta opción si su versión de NetView es anterior a la versión 3.

-noinst

No sobregrabar los archivos de configuración de NetView existentes.

Consulte el apartado “Revisión de los cambios”.

-client En NetView versión 6.x y posterior, incluya esta opción para los clientes de

gestión.

-manager

El nombre de host del nodo de gestión. En NetView versión 6.x y

posterior, se trata del nombre de host del servidor de NetView. Es

obligatorio para los nodos gestionados y los clientes de NetView. No utilice

esta opción en el nodo de gestión ni en el servidor de NetView.

Instalación

El proceso de instalación consta de los siguientes dos pasos:

v Instalación en nodos gestionados y en clientes de NetView

v Instalación en el nodo de gestión o en el servidor de NetView

Instalación en nodos gestionados y en clientes de NetView: El nodo de gestión

también puede ser un nodo gestionado. Para el nodo de gestión o el servidor de

NetView, omita este paso y realice el paso Instalación del nodo de gestión o el

servidor de NetView.



1. Asegúrese de que no se está ejecutando ningún proceso de Tivoli Workload

Scheduler. Si es necesario, emita un comando shutdown de conman.

2. Inicie la sesión como root.

3. Para los nodos gestionados, incluidos aquellos que también son clientes de

NetView que no se utilizan para gestionar Tivoli Workload Scheduler, ejecute el

script customize de la manera siguiente:

/bin/sh <TWShome>/OV/customize -manager host

donde host es el nombre de host del nodo de gestión.

4. Para los clientes de NetView que se utilizan para gestionar Tivoli Workload

Scheduler, ejecute customize de la manera siguiente:

/bin/sh <TWShome>/OV/customize -client [-manager host]

donde host es el nombre de host del nodo de gestión.

5. Ejecute StartUp:

<TWShome>/StartUp

Instalación del nodo de gestión o el servidor de NetView:

1. Asegúrese de que no se está ejecutando ningún proceso de Tivoli Workload

Scheduler. Si es necesario, emita un comando shutdown de conman.

2. Inicie la sesión como root.

3. Ejecute el script customize de la manera siguiente:

/bin/sh <TWShome>/OV/customize

4. Si no desea que el agente Tivoli Workload Scheduler/NetView se ejecute en

este nodo, edite <TWShome>/StartUp y elimine la ejecución de magent.

5. Si desea que Tivoli Workload Scheduler se ejecute en este nodo, ejecute

StartUp:

<TWShome>/StartUp

6. Inicie el daemon de Tivoli Workload Scheduler/NetView (mdemon) de la

manera siguiente:

/usr/OV/bin/ovstart Unison_Maestro_Manager

o bien, para las versiones de NetView anteriores a la 3, deténgalo e inícielo de

la siguiente manera:

/usr/OV/bin/ovstop

/usr/OV/bin/ovstart

Configuración

Siga estos pasos:

1. Determine el usuario que gestionará Tivoli Workload Scheduler con NetView.

a. En cada nodo gestionado, entre el nombre de host del nodo de gestión en el

archivo $HOME/.rhosts del usuario.

b. Para permitir que el usuario ejecute determinados comandos del

planificador, debe añadir una definición de usuario en el archivo de

seguridad del planificador. Por ejemplo, puede otorgar a este usuario las

mismas capacidades que al usuario maestro predeterminado. Para obtener

más información sobre la seguridad de Tivoli Workload Scheduler, consulte

el manual IBM Tivoli Workload Scheduler - Planificación e instalación.2. En el nodo de gestión, ejecute NetView.

3. Abra el mapa que desea utilizar.



a. En el menú File (Archivo), seleccione Describe Map... (Describir mapa)

b. Cuando aparezca el cuadro de diálogo Map Description (Descripción de

mapa), seleccione Maestro-Unison Software(c) en la lista Configurable

Applications (Aplicaciones configurables) y haga clic en Configure For This

Map... (Configurar para este mapa).

c. Cuando aparezca el cuadro de diálogo Configuration (Configuración), haga

clic en True (Verdadero) bajo Enable Maestro for this map (Habilitar

Maestro para este mapa).

d. Haga clic en Verify (Verificar).

e. Haga clic en OK (Aceptar) para cerrar el cuadro de diálogo Configuration.

f. Haga clic en OK para cerrar el cuadro de diálogo Map Description.4. Si desea utilizar el examinador de MIB, cargue la MIB de Tivoli Workload

Scheduler de la manera siguiente:

a. En el menú Options (Opciones), seleccione Load/Unload MIBs:SNMP...

(Cargar/descargar MIB:SNMP).

b. Cuando aparezca el cuadro de diálogo Load/Unload MIB, haga clic en

Load (Cargar).

c. Cuando aparezca el cuadro de diálogo Load MIB From File (Cargar MIB

desde archivo), entre

/usr/OV/snmp_mibs/Maestro.mib

en el campo MIB File to Load (Archivo MIB para cargar). Haga clic en OK

(Aceptar).

d. Haga clic en Close (Cerrar) para cerrar el cuadro de diálogo Load/Unload

MIBs.5. Si el nodo de gestión no es también un nodo de Tivoli Workload Scheduler

gestionado, o bien si va a gestionar más de una red de Tivoli Workload

Scheduler, utilice la función de descripción de objeto de NetView para

identificar nodos gestionados donde se ejecutan agentes de Tivoli Workload

Scheduler/NetView.

a. Desplácese hacia abajo por el árbol Internet IP hasta el submapa Segmento

de IP que muestra todos los nodos.

b. Seleccione un nodo donde se esté ejecutando un agente de Tivoli Workload

Scheduler/NetView. Pulse Control-O para abrir el diálogo Object

Description (Descripción de objeto).

c. En el diálogo Object Description, seleccione General Attributes (Atributos

generales) en la lista Object Attributes (Atributos de objeto) y haga clic

enView/Modify Object Attributes (Ver/Modificar atributos de objeto).

d. En el diálogo Attributes for Object (Atributos para objeto), haga clic en True

(Verdadero) bajo el atributo isUTMaestroAgent.

e. Haga clic en OK (Aceptar) para cerrar el diálogo Attributes for Object

(Atributos para objeto).

f. Haga clic en OK (Aceptar) para cerrar el diálogo Object Description

(Descripción de objeto).

g. Repita los pasos del 5b al 5f para cada nodo en el que se esté ejecutando un

agente de Tivoli Workload Scheduler/NetView.

h. Vuelva al submapa Root (Raíz). En el menú Tools (Herramientas), seleccione

Tivoli Workload Scheduler y, a continuación, seleccione Re-discover

(Redescubrir).

i. Cuando aparezca el símbolo de Unison Software(c), haga doble clic sobre el

mismo para abrir el submapa de Unison Software(c) que muestra un símbolo



para cada red de Tivoli Workload Scheduler. Haga doble en un símbolo de

red de Tivoli Workload Scheduler para abrir un submapa Red de Tivoli

Workload Scheduler que muestra una representación topográfica de la red.

Ahora ya está listo para utilizar Tivoli Workload Scheduler/NetView. En el maestro

de Tivoli Workload Scheduler, emita un comando conman start@ para reiniciar

Tivoli Workload Scheduler en la red. Esto puede hacerse en NetView, en el

submapa Red de Tivoli Workload Scheduler, de la manera siguiente:

1. Seleccione todos los nodos de la red.

2. En el menú Tools (Herramientas), seleccione Tivoli Workload Scheduler, y, a

continuación, seleccione Start (Inicio).

Objetos, símbolos y submapas

Los objetos y símbolos de Tivoli Workload Scheduler/NetView se describen en la

Tabla 30.

Tabla 30. Objetos y símbolos de Tivoli Workload Scheduler/NetView

Símbolo Descripción

La aplicación Unison Software. Este símbolo aparece

en el submapa raíz. Su color indica el estado agregado

de todas las redes de Tivoli Workload Scheduler.

En el submapa Unison Software (c), una red de Tivoli

Workload Scheduler. Su color indica el estado

agregado de todas las estaciones de trabajo y los

vínculos que comprende una red de Tivoli Workload

Scheduler.

En el submapa Red de Tivoli Workload Scheduler, un

host. Su color indica el estado agregado del host,

todos sus agentes y sus vínculos.

En un submapa Red de Tivoli Workload Scheduler,

una representación topográfica de las estaciones de

trabajo y los vínculos que comprende una red de

Tivoli Workload Scheduler. El color de un símbolo de

estación de trabajo indica el estado de la planificación

de trabajos de la estación de trabajo. El color de un

símbolo de vínculo (una línea) indica el estado del

vínculo de estación de trabajo. Los símbolos de

estación de trabajo también aparecen en los submapas

de nodo de IP.

Si una estación de trabajo de la red es un host pero no

es el maestro, la estación de trabajo se representa

mediante un símbolo de red (por ejemplo, SLAVE3 ).

Para el host y sus agentes conectados existe un

submapa Red de host.

El software de Tivoli Workload Scheduler de una

estación de trabajo. Este símbolo aparece en el

submapa de nodo de IP. Su color indica el estado

agregado de todos los procesos supervisados de una

estación de trabajo de Tivoli Workload Scheduler.

Tenga en cuenta que los agentes ampliados no tienen

procesos supervisados.



Tabla 30. Objetos y símbolos de Tivoli Workload Scheduler/NetView (continuación)

Símbolo Descripción

Los procesos supervisados de una estación de trabajo

de Tivoli Workload Scheduler. Estos símbolos aparecen

en el submapa de procesos supervisados. El color de

un símbolo de proceso indica el estado del proceso. Si

hace clic en el símbolo NETMAN, se efectuará la

acción de arranque (Startup) (consulte el apartado

“Acciones del menú” en la página 130). Si hace clic en

el símbolo MAGENT, se iniciará el proceso magent en

la estación de trabajo.

Estado de los símbolos de Tivoli Workload Scheduler/NetView

El color de un símbolo de Tivoli Workload Scheduler/NetView indica su estado

actual. Los colores se describen en la Tabla 31. El estado de los símbolos de

procesos supervisados y de estación de trabajo de Tivoli Workload Scheduler se

propagan en dirección ascendente por el árbol de submapas del modo que se

define en NetView. La propagación se define seleccionando Describe Map

(Describir mapa) en el menú File (Archivo) y seleccionando el Compound Status

(Estado compuesto) deseado.

Tabla 31. Estado de Tivoli Workload Scheduler/NetView

Color

Procesos

supervisados

(símbolos de

procesos

supervisados)

Planificación de

trabajos (Símbolos

de CPU de maestro)

Comunicación

(símbolos de

vínculos de maestro)

Negro N/A N/A Activo o desconocido

*

Azul (Desconocido) * * N/A

Verde

(Normal/Activo)

En ejecución Sin eventos no

reconocidos

N/A

Amarillo (Marginal) Detenido Trabajo(s)

terminado(s) de

forma anómala,

fallido(s) o

suspendido(s)

Inactivo (sin vínculo)

Rojo

(Crítico/Inactivo)

Terminado de forma

anómala o

desaparecido

Planificación(ones)

terminada(s) de

forma anómala,

atascada(s) o

suspendida(s)

Inactivo (error)

Tostado (Sin

gestionar)

Ya no se sondea más Ya no se sondea más N/A

Verde Dk (No

reconocido)

Ignorar hasta no

reconocido

Ignorar hasta no

reconocido

N/A

*El estado Desconocido lo establece Tivoli Workload Scheduler/NetView cuando el

estado de un objeto no puede determinarse. Este puede ser el resultado de una de

las siguientes situaciones:

v Si un agente tolerante a errores o estándar no está vinculado con el maestro, el

estado de planificación de trabajos de dicha estación de trabajo es desconocido.



v Si fallan las comunicaciones con el proceso mdemon, el estado de todos los

procesos supervisados y de toda la planificación de trabajos es desconocido.

v Si fallan las comunicaciones con el proceso de un agente, su estado es Crítico y

el resto de los procesos supervisados de dicha estación de trabajo es

desconocido.

v Si un proceso de agente no se puede encontrar en el maestro, el maestro de

copia de seguridad o un agente tolerante a errores con ″fullstatus on″, el estado

de la planificación de trabajos en todas las estaciones de trabajo de la red de

Tivoli Workload Scheduler es desconocido.

v Si el maestro de Tivoli Workload Scheduler está inactivo, o no gestionado, el

estado de las comunicaciones (vínculo) es desconocido.

Para obtener más información sobre el estado de la estación de trabajo de Tivoli

Workload Scheduler, consulte el apartado “Configuración del estado de la estación

de trabajo en NetView” en la página 139.

Correlación de agentes ampliados

Si el host de un agente ampliado es el maestro, el agente ampliado se muestra

como conectado al maestro en el submapa Red de Tivoli Workload Scheduler. Si el

host de un agente ampliado no es el maestro:

v El agente ampliado no se muestra en el submapa Red de Tivoli Workload

Scheduler.

v El host se representa mediante un símbolo de red y los agentes ampliados se

muestran en el submapa Red de host.

Acciones del menú

Para utilizar las acciones del menú de Tivoli Workload Scheduler/NetView,

seleccione Tivoli Workload Scheduler en el menú Herramientas. Estas acciones

también están disponibles en el menú de contexto haciendo clic con el botón

derecho del ratón sobre un símbolo.

Las acciones del menú son las siguientes:

View (Ver)

Abrir un submapa hijo para un símbolo de Tivoli Workload

Scheduler/NetView. Si elige View después de seleccionar un símbolo de

estación de trabajo en el submapa de red de Tivoli Workload Scheduler se

abre el submapa de los procesos supervisados. Si elige View después de

seleccionar un símbolo de estación de trabajo en el submapa de IP de nodo

se vuelve al submapa de red de Tivoli Workload Scheduler.

Master conman (Conman maestro)

Ejecutar el programa de línea de comandos de conman en el maestro de

Tivoli Workload Scheduler. La ejecución del programa en el maestro

permite ejecutar todos los comandos de conman (con la excepción de

shutdown) para cualquier estación de trabajo de la red de Tivoli Workload

Scheduler. Para obtener información sobre los comandos de conman,

consulte el manual IBM Tivoli Workload Scheduler - Guía de consulta.

Acknowledge (Reconocer)

Reconocer el estado de los símbolos de Tivoli Workload

Scheduler/NetView seleccionados. Cuando se reconoce, el estado de un

símbolo vuelve a ser normal. No es necesario reconocer el estado crítico o

marginal de un símbolo de proceso supervisado, puesto que vuelve a ser

normal cuando el propio proceso supervisado se está ejecutando.

Reconozca el estado crítico o marginal de símbolos de estación de trabajo



de Tivoli Workload Scheduler antes o después de realizar alguna acción

para remediar el problema. De lo contrario, no vuelve a ser normal.

Conman

Ejecutar el programa de línea de comandos de conman en las estaciones de

trabajo de Tivoli Workload Scheduler seleccionadas. La ejecución del

programa en una estación de trabajo distinta de la maestra permite ejecutar

todos los comandos de conman únicamente en dicha estación de trabajo.

Para obtener información sobre los comandos de conman, consulte el

manual IBM Tivoli Workload Scheduler - Guía de consulta. Para un agente

ampliado, conman se ejecuta en su host.

Start (Iniciar)

Emitir un comando start de conman para las estaciones de trabajo

seleccionadas. De forma predeterminada, el comando para esta acción es el

siguiente:

remsh %H %P/bin/conman ’start %c’

Down (stop) [Inactivo (detener)]

Emitir un comando stop de conman para las estaciones de trabajo

seleccionadas. De forma predeterminada, el comando para esta acción es el

siguiente:

remsh %H %P/bin/conman ’stop %c’

StartUp (Arrancar)

Ejecutar el script StartUp de Tivoli Workload Scheduler en las estaciones

de trabajo seleccionadas. De forma predeterminada, el comando para esta

acción es el siguiente:

remsh %h %P/StartUp

Para un agente ampliado, conman se ejecuta en su host.

Rediscover (Redescubrir)

Localizar nuevos agentes y nuevos objetos de Tivoli Workload Scheduler, y

actualizar todos los submapas de Tivoli Workload Scheduler/NetView.

Nota: Ejecute Rediscover cada vez que cambie la configuración de la

estación de trabajo de Tivoli Workload Scheduler.

Los parámetros sustituidos de las líneas de comandos son los siguientes:

%c El nombre de la estación de trabajo de Tivoli Workload Scheduler de un

símbolo de estación de trabajo seleccionado.

%D El nombre de DISPLAY actual.

%h El nombre de host de un símbolo de estación de trabajo seleccionado.

%H El nombre de host del maestro de Tivoli Workload Scheduler.

%p El nombre de proceso de un símbolo de proceso seleccionado, o

“MAESTRO” si no se trata de un proceso.

%P El directorio inicial del usuario maestro (normalmente /usr/lib/maestro ).

Cambio de los comandos

Los comandos ejecutados al seleccionar acciones de Tivoli Workload

Scheduler/NetView pueden modificarse en NetView eligiendo Describe Map

(Describir mapa) en el menú File (Archivo). Cuando aparezca el cuadro de diálogo

Map Description (Descripción de mapa), seleccione Maestro-Unison Software en la

lista Configurable Applications (Aplicaciones configurables) y haga clic en



Configure For This Map (Configurar para este mapa). Efectúe los cambios en el

cuadro de diálogo Configuration (Configuración). Para obtener instrucciones,

consulte la documentación de NetView o la ayuda en línea. También puede

consultar las notas que aparecen a continuación.

Notas:

1. Para ejecutar determinados comandos de conman, el usuario que ejecuta

NetView debe definirse en el archivo de seguridad de Tivoli Workload

Scheduler. Para obtener más información, consulte el manual IBM Tivoli

Workload Scheduler - Guía de consulta.

2. Elimine el comando remsh si no se necesita. Por ejemplo, si el nodo de gestión

es el maestro de Tivoli Workload Scheduler, las acciones remsh para el conman

maestro, Start y Down (stop) no se necesitan.

3. Como se indica, los comandos remsh requieren que el usuario de NetView

pueda iniciar la sesión en otros nodos sin solicitud de contraseña.

Eventos de Tivoli Workload Scheduler/NetView

Los eventos de Tivoli Workload Scheduler/NetView se listan en el manual IBM

Tivoli Workload Scheduler - Guía de consulta. Los cuatro primeros (1-53) indican el

estado de los procesos críticos que supervisan los agente de Tivoli Workload

Scheduler/NetView, incluidos los propios agentes (evento 1). Los eventos

restantes(101-252) indican el estado de la actividad de planificación de trabajos.

Todos los eventos listados pueden tener como resultado condiciones de excepción

de SNMP generadas por los agentes de Tivoli Workload Scheduler/NetView. La

posibilidad de que se generen o no condiciones de excepción se controla mediante

las opciones establecidas en los archivos de configuración de los agentes. Consulte

el apartado “Archivos de configuración de Tivoli Workload Scheduler/NetView”

en la página 135 para obtener más información.

La columna Additional Actions del manual IBM Tivoli Workload Scheduler - Guía de

consulta lista las acciones de que dispone el operador para cada evento. Las

acciones pueden iniciarse seleccionando Additional Actions (Acciones adicionales)

en el menú Options (Opciones) y, a continuación, seleccionando una opción en el

panel Additional Actions.

Nota: Debe tener el acceso de seguridad de Tivoli Workload Scheduler apropiado

para llevar a cabo la acción elegida.

Tabla 32. Eventos de Tivoli Workload Scheduler/NetView

Nº de

condición de

excepción Nombre Descripción Acciones adicionales

1 * uTtrapReset Se ha reiniciado el

proceso magent.

N/A

51 uTtrapProcessReset Se ha reiniciado un

proceso supervisado.

Este evento se notifica

de forma

predeterminada en el

archivo BmEvents.conf

N/A

52 * uTtrapProcessGone Un proceso

supervisado ya no

aparece.

N/A



Tabla 32. Eventos de Tivoli Workload Scheduler/NetView (continuación)

Nº de

condición de


53 * uTrapProcessAbend Un proceso

supervisado ha

terminado de forma

anómala.

N/A

54 * uTrapXagentConnLost Se ha perdido la

conexión entre un host

y xagent.

N/A

101 * uTtrapJobAbend Un trabajo planificado

ha terminado de forma

anómala.

Mostrar trabajo, Volver

a ejecutar trabajo,

Cancelar trabajo

102 * uTtrapJobFailed Un trabajo externo está

en el estado de error.


a ejecutar trabajo,

Cancelar trabajo

103 uTtrapJobLaunch Un trabajo planificado

se ha iniciado

satisfactoriamente.


a ejecutar trabajo,

Cancelar trabajo

104 uTtrapJobDone Un trabajo planificado

está en un estado

distinto de ABEND

(terminación de forma

anómala).


a ejecutar trabajo,

Cancelar trabajo

105* uTtrapJobUntil Un trabajo planificado

está hasta (UNTIL) que

haya pasado un

tiempo, no se iniciará.


a ejecutar trabajo,

Cancelar trabajo

111 uTrapJobCant Un trabajo planificado

no se ha podido iniciar.


a ejecutar trabajo,

Cancelar trabajo

151 * uTtrapSchedAbend Una planificación ha

terminado de forma

anómala (ABEND).

Mostrar planificación,

Cancelar planificación

152 * uTtrapSchedStuck Una planificación está

en el estado de

atascado (STUCK).



153 uTtrapSchedStart Una planificación ha

iniciado la ejecución.



154 uTtrapSchedDone Una planificación está

en un estado distinto

de ABEND

(terminación de forma

anómala).



155* uTtrapSchedUntil Una planificación está

hasta (UNTIL) que

haya pasado un

tiempo, no se iniciará.



201 * uTtrapGlobalPrompt Se ha emitido una

solicitud global.

Responder



Tabla 32. Eventos de Tivoli Workload Scheduler/NetView (continuación)

Nº de

condición de


202 * uTtrapSchedPrompt Se ha emitido una

solicitud de

planificación.

Responder

203 * uTtrapJobPrompt Se ha emitido una

solicitud de trabajo.

Responder

204 * uTtrapJobRerunPrompt Se ha emitido una

solicitud de volver a

ejecutar un trabajo.

Responder

251 uTtrapLinkDropped Se ha cerrado el

vínculo con una

estación de trabajo.

Vínculo

252 * uTtrapLinkBroken Se ha cerrado el

vínculo con una

estación de trabajo

debido a un error.

Vínculo

* Estas condiciones de excepción se habilitan de

forma predeterminada.

Sondeo y condiciones de excepción de SNMP

Puesto que SNMP utiliza un protocolo de transporte poco fiable (UDP), Tivoli

Workload Scheduler/NetView no se basa en las condiciones de excepción de

SNMP para indicar el estado de sus símbolos. En su lugar, el gestor sondea sus

agentes periódicamente, solicitando valores de MIB específicos. Los valores

devueltos se comparan con los que ha devuelto el sondeo anterior y las diferencias

se indican como cambios de estado en símbolos de Tivoli Workload

Scheduler/NetView. El intervalo de sondeo predeterminado es de un minuto.

Consulte el apartado “Opciones de configuración de Tivoli Workload

Scheduler/NetView” en la página 138 para obtener información sobre el modo de

cambiar el intervalo de sondeo.

Para obtener estado de proceso crítico, el gestor sondea todos sus agentes. Para el

estado de planificación de trabajos, el gestor determina cuál de sus agentes tiene

más posibilidades de poseer la información necesaria y sondea únicamente dicho

agente. La elección se efectúa en el siguiente orden de precedencia:

1. El agente que se ejecuta en el maestro de Tivoli Workload Scheduler.

2. El agente que se ejecuta en un maestro de copia de seguridad de Tivoli

Workload Scheduler.

3. El agente que se ejecuta en cualquier agente tolerante a errores de Tivoli

Workload Scheduler que tenga ″fullstatus on″ en su definición de estación de

trabajo.

La habilitación de las condiciones de excepción de Tivoli Workload

Scheduler/NetView ofrece las siguientes ventajas:

1. Se incluyen variables específicas de evento con cada condición de excepción.

2. Las condiciones de excepción se registran en el registro de eventos de NetView.

Si se habilitan las condiciones de excepción de terminación de trabajo de forma

anómala (101), se recopila suficiente información para identificar un trabajo que ha



terminado de forma anómala, su planificación y la estación de trabajo donde se

ejecuta. Esto resulta útil al decidir qué acciones emprender para resolver un

problema.

Si lo desea, puede inhabilitar algunas o todas las condiciones de excepción de

Tivoli Workload Scheduler/NetView por los siguientes motivos:

1. Para reducir el tráfico de la red.

2. Para evitar confusión por parte de otros usuarios de NetView limitando el

número de eventos registrados.

Para obtener más información sobre las condiciones de excepción específicas de

empresa de Unison Software y sus variables, consulte el apartado “Cómo volver a

configurar condiciones de excepción específicas de empresa” en la página 140.


Scheduler/NetView

En cada nodo gestionado (cada nodo que ejecuta un agente de Tivoli Workload

Scheduler/NetView), la selección de eventos y el modo en que se notifican se

controla estableciendo variables en dos archivos de configuración:

v El archivo de configuración BmEvents controla la notificación de eventos de

planificación de trabajos (101-252 en la Tabla 32) por parte de los procesos de

producción mailman y batchman. Estos eventos se pasan al agente, que puede

convertirlos en condiciones de excepción de SNMP, dependiendo de los valores

de su archivo de configuración.

v El archivo de configuración MAgent controla la notificación por parte del agente

de Tivoli Workload Scheduler/NetView, magent. Los eventos seleccionados en

este archivo se convierten en condiciones de excepción de SNMP, que se pasan a

NetView por parte del gestor de Tivoli Workload Scheduler/NetView manager,

mdemon, en el nodo de gestión. Las condiciones de excepción también las

pueden procesar otros sistemas de gestión de red.

El archivo de configuración BmEvents

El archivo de configuración BmEvents se denomina <TWShome>/BmEvents.conf. Se

utiliza para configurar los procesos de producción de Tivoli Workload Scheduler en

cada estación de trabajo que tiene un agente instalado. Su contenido se describe a

continuación.

# comentario

Una línea de comentario.

OPTIONS=MASTER|OFF

Si el valor se establece en MASTER, se notifican todos los eventos de

planificación de trabajos que reúne dicha estación de trabajo. Si esa

estación de trabajo es el gestor de dominio maestro o el gestor de dominio

del maestro de copia de seguridad con ″full status on″ (estado completo),

se notifican todos los eventos de planificación del entorno de planificación.

Si el valor se establece en OFF, dicha estación de trabajo no notifica ningún

evento de planificación de trabajos. Si se comenta, adopta el valor

predeterminado de MASTER en la estación de trabajo del gestor de

dominio maestro, al tiempo que permite notificar todos los eventos de

planificación de trabajo relacionados con dicha estación de trabajo

únicamente en una estación de trabajo distinta del gestor de dominio

maestro.

EVENT= n [ n ...]

La lista de eventos que se deben notificar. Los números de evento deben



separarse por un espacio como mínimo. Si se omite, los eventos notificados

de forma predeterminada son los siguientes:

51 101 102 105 151 152 155 201 202 203 204 251 252

El evento 51 indica a mailman y batchman que deben notificar el hecho de

que se han reiniciado. Los eventos 1, 52 y 53 no son válidos en este archivo

(consulte el apartado “El archivo de configuración MAgent”).

Si se incluye el parámetro EVENT, este altera temporalmente y

completamente los valores predeterminados. Para eliminar únicamente el

evento 102 de la lista, por ejemplo, debe entrar lo siguiente:

EVENT=51 101 105 151 152 155 201 202 203 204 251 252

Consulte la Tabla 32 en la página 132 para obtener una descripción de los

eventos.

PIPE=nombre de archivo

Si se establece, los eventos de planificación se graban en un archivo FIFO.

Para que los eventos se envíen al agente de Tivoli Workload

Scheduler/NetView, el valor deberá ser el siguiente:

PIPE=MAGENT.P

Con el software de Tivoli Workload Scheduler se incluye un archivo de

configuración BmEvents. Contiene varias líneas de comentario y un único valor de

parámetro:

PIPE=MAGENT.P

Esto causa que los eventos se notifiquen de la siguiente manera:

v Si se instala en el maestro, notificará todos los eventos de planificación de

trabajos (101-252) para todas las estaciones de trabajo de la red. Si se instala en

cualquier otra estación de trabajo, no se notificará ningún evento de

planificación de trabajos. El evento de reinicio de proceso (51) se notifica

independientemente del tipo de estación de trabajo.

v Se notifican los siguientes eventos:

51 101 102 105 151 152 155 201 202 203 204 251 252

v La información de evento se graba en un archivo FIFO denominado MAGENT.P,

que es leído por el agente de Tivoli Workload Scheduler/NetView.

El archivo de configuración MAgent

El archivo de configuración MAgent se denomina <TWShome>/MAgent.conf. Se utiliza

para configurar el agente en cada estación de trabajo. Su contenido se describe a

continuación.

# comentario

Una línea de comentario.

OPTIONS=MASTER|OFF

Si se establece en MASTER, el agente de esta estación de trabajo enviará

los eventos de planificación de trabajos leídos del archivo MAGENT.P

como condiciones de excepción de SNMP. Si se establece en OFF , esta

estación de trabajo no genera ninguna condición de excepción de

planificación de trabajos. Si se omite, adopta el valor predeterminado de

MASTER en el maestro y de OFF en otras estaciones de trabajo.

Esta variable sólo es obligatoria si el maestro no se va a utilizar para

generar condiciones de excepción de planificación de trabajos para la red.



Por ejemplo, si el maestro no es un nodo gestionado (no hay ningún

agente instalado), debería establecer esta variable en MASTER en un

maestro de copia de seguridad que tenga un agente instalado.

EVENT= n [ n ...]

La lista de eventos que se deben enviar como condiciones de excepción de

SNMP. Con la excepción de los eventos 1, 52 y 53, no se generarán

condiciones de excepción a menos que los eventos correspondientes se

activen en el archivo de configuración BmEvents. Los números de evento

deben separarse por un espacio como mínimo. Si se omite, los eventos

enviados como condiciones de excepción de forma predeterminada son los

siguientes:

1 52 53 54 101 102 105 151 152 155 201 202 203 204 252

El evento 1 (magent reiniciado) no se puede desactivar.

Si se incluye este parámetro, alterará temporalmente los valores

predeterminados. Para eliminar únicamente el evento 102 de la lista, por

ejemplo, debe entrar lo siguiente:

EVENT=1 52 53 54 101 105 151 152 155 201 202 203 204 252

Consulte la Tabla 32 en la página 132 para obtener una descripción de los

eventos.

+name [nombre_archivo_pid]

De forma predeterminada, la lista de procesos que supervisa el agente de

Tivoli Workload Scheduler/NetView contiene los siguientes procesos:

magent, netman, mailman, batchman, jobman, todos los servidores

mailman, todos los writers y todas las conexiones de agentes ampliados.

Utilice esta sintaxis para añadir procesos a la lista. Si no se trata de un

proceso de Tivoli Workload Scheduler, deberá incluir su nombre de archivo

PID. Estos son algunos ejemplos:

+SENDMAIL /etc/sendmail.pid

+SYSLOG /etc/syslogd.pid

-name Utilice esta sintaxis para eliminar procesos de la lista de procesos

supervisados. Para eliminar procesos de writer, utilice esta forma:

- cpuid :writer

Por ejemplo, para eliminar procesos de writer de todas las estaciones de

trabajo cuyos ID empiezan con SYS, entre:

-SYS@:WRITER

Para eliminar todos los procesos de writer, entre:

-@:WRITER

Para eliminar los servidores de mailman 5 y A, entre:

-SERVER5

-SERVERA

Para eliminar todos los servidores de mailman, entre:

-SERVER@



Con el software de Tivoli Workload Scheduler/NetView se incluye un archivo de

configuración MAgent. Contiene todas las líneas de comentario; no hay parámetros

establecidos. Esto causa que las condiciones de excepción de SNMP se generen de

la siguiente manera:

v Si se instala en el maestro, se generan condiciones de excepción para los eventos

de planificación de trabajos (101-252) en todas las estaciones de trabajo de la red.

Si se instala en cualquier otra estación de trabajo, no se generan condiciones de

excepción de planificación de trabajos.

v Los siguientes eventos tienen como resultado condiciones de excepción de

SNMP:

1 52 53 54 101 102 105 151 152 155 201 202 203 204 252

v Se supervisan los siguientes procesos: magent, netman, mailman, batchman,

jobman, todos los servidores mailman, todos los procesos writer y todas las

conexiones de agentes ampliados.

Supervisión de procesos writer y servidores

Los procesos de servidor mailman y writer se inician y detienen cuando se

vinculan y desvinculan estaciones de trabajo de Tivoli Workload Scheduler. Su

naturaleza transitoria, y el número resultante de cambios de estado en NetView

pueden causar confusión, particularmente en redes de Tivoli Workload Scheduler

de gran tamaño en los que suelen producirse vinculaciones y desvinculaciones. Por

esta razón, puede eliminar los procesos de servidor mailman y writer de la lista de

procesos supervisados.


Scheduler/NetView

Los submapas, símbolos y objetos de Tivoli Workload Scheduler/NetView pueden

modificarse como otros de NetView. Los temas siguientes describen algunas

opciones de configuración específicas para Tivoli Workload Scheduler/NetView.

Frecuencia de exploración de los agentes

De forma predeterminada, los agentes de Tivoli Workload Scheduler/NetView

exploran y actualizan el estado de los procesos supervisados cada 60 segundos.

Para cambiar la frecuencia:

1. Inicie la sesión en el nodo gestionado y edite el archivo <TWShome>/StartUp.

2. Añada la opción -timeout en la línea de comandos de magent.

Por ejemplo, para cambiar la velocidad a 120 segundos, realice el siguiente cambio:

<TWShome>/bin/magent -peers hosts -timeout 120

Frecuencia de sondeo del gestor

El gestor de Tivoli Workload Scheduler/NetView (mdemon) sondea sus agentes

para recuperar información de estado sobre los nodos gestionados. La frecuencia se

define en el archivo /usr/OV/lrf/Mae.mgmt.lrf del nodo de gestión. A menos que

se especifique lo contrario, la frecuencia de sondeo se establece de forma

predeterminada en 60 segundos.

Para cambiar la frecuencia:

1. Edite el archivo para añadir la opción -timeout a la línea de comandos de

mdemon. Por ejemplo, para cambiar la velocidad a 120 segundos, realice el

siguiente cambio:

Unison_Software_Maestro_Manager: <TWShome>/bin/mdemon:

OVs_YES_START:pmd,ovwdb:-pmd,-timeout,120:OVs_WELL_BEHAVED



2. Después de efectuar un cambio, suprima el registro antiguo ejecutando el

comando ovdelobj.

3. Registre el gestor ejecutando el comando ovaddobj y proporcionando el

nombre del archivo lrf.

Para obtener más información, revise las páginas man para ovaddobj(8) y lrf(4).

Consulte también el apartado Configuración de agentes en NetView.

Configuración de agentes en NetView

Para cambiar la configuración de agentes de Tivoli Workload Scheduler/NetView

en NetView, siga los pasos siguientes:

1. Desplácese hacia abajo por el árbol Internet IP hasta el submapa Segmento de

IP que muestra todos los nodos.

2. Seleccione un nodo donde se esté ejecutando un agente de Tivoli Workload

Scheduler/NetView. Pulse Control-O para abrir el panel Object Description

(Descripción de objeto).

3. En el panel Object Description, seleccione Maestro - Unison Software(c) en la

lista Object Attributes (Atributos de objeto).

4. Haga clic en el botón View/Modify Object Attributes (Ver/Modificar atributos

de objeto).

5. En el panel Attributes for Object (Atributos para objeto):

a. Para ignorar este agente por completo, haga clic en False (Falso) bajo Does

a Maestro agent exist on this cpu? (¿Existe un agente Maestro en esta

CPU?).

b. Para cambiar la frecuencia en que mdemon sondea a es te agente, entre el

número de segundos bajo Enter the number of seconds between polling

(Entre el número de segundos entre sondeos). Si este número es distinto de

cero, alterará temporalmente la frecuencia definida para el proceso mdemon

(consulte el apartado “Frecuencia de sondeo del gestor” en la página 138).

c. Haga clic en Verify (Verificar) y, a continuación OK (Aceptar) para cerrar el

panel Attributes for Object.6. Haga clic en OK (Aceptar) para cerrar el panel Object Description.

Configuración del estado de la estación de trabajo en NetView

Para modificar la forma en que indica el estado un símbolo de estación de trabajo

de Tivoli Workload Scheduler, siga los pasos siguientes:

1. Seleccione un símbolo de estación de trabajo en el submapa de red de Tivoli

Workload Scheduler.

2. Pulse Control-O para abrir el panel Object Description (Descripción de objeto).

3. En el diálogo Object Description, seleccione Tivoli Workload Scheduler en la

lista Object Attributes (Atributos de objeto).

4. Haga clic en View/Modify Object Attributes (Ver/Modificar atributos de

objeto).

5. En el diálogo Attributes for Object (Atributos para objeto), haga clic en True

(Verdadero) o False (Falso) para ignorar o reconocer los distintos eventos de

planificación de trabajos. Por ejemplo, para ignorar eventos de terminación

anómala de trabajos, si hace clic en True (Verdadero) bajo Tivoli Workload

Scheduler se ignorarán los eventos JobAbend.

6. Haga clic en Verify (Verificar) y, a continuación OK (Aceptar) para cerrar el

panel Attributes for Object.

7. Haga clic en OK (Aceptar) para cerrar el panel Object Description.



MIB de Unison Software

Para obtener una lista completa de las MIB de empresa de Unison Software,

consulte el archivo TWShome/OV/Maestro.mib.

Cómo volver a configurar condiciones de excepción específicas

de empresa

Las condiciones de excepción específicas de empresa de Tivoli Workload

Scheduler/NetView se configuran con mensajes predeterminados que se ajustarán

a las necesidades de muchos usuarios. Para volver a configurar las condiciones de

excepción, elija Event Configuration (Configuración de eventos) en el menú

Options (Opciones). Para obtener instrucciones, consulte la documentación de

NetView o la ayuda en línea. También puede ser útil consultar la página man para

trapd.conf(4).

Las condiciones de excepción específicas de empresa y sus variables posicionales se

listan en la Tabla 33. Las descripciones de las condiciones de excepción se listan en

Tabla 32.

La Tabla 33 lista condiciones de excepción específicas de empresa.

Tabla 33. Condiciones de excepción específicas de empresa

Condición de excepción Identificador Variables posicionales

1 * uTtrapReset 1 Número de identificador

de agente

2 Versión de software

3 Cadena de mensaje de

Tivoli Workload Scheduler, si

hay alguna

51 52 * 53 * uTtrapProcessReset

uTtrapProcessGone

uTrapProcessAbend

1 PID de proceso

2 Nombre de programa



hay alguna

54 * uTrapXagentConnLost 1 Nombre de programa



hay alguna



Tabla 33. Condiciones de excepción específicas de empresa (continuación)


101 * 102 * 103 104 105* 204 * uTtrapJobAbend

uTtrapJobFailed

uTtrapJobLaunch

uTtrapJobDone

uTtrapJobUntil

uTtrapJobRerunPrompt

1 Nombre de estación de

trabajo de la planificación

2 Nombre de planificación

3 Nombre de trabajo. Para

aquellos trabajos que se

envían con at o batch , si el

nombre que proporciona el

usuario no es exclusivo, este

será el nombre generado por

Tivoli Workload Scheduler, y

el nombre proporcionado por

el usuario aparecerá como la

variable 7

4 Nombre de la estación de

trabajo en la que se ejecuta el

trabajo

5 Nombre de trabajo (pid)

6 Estado del trabajo,

indicado por un entero: 1

(ready, listo), 2 (hold,

retenido), 3 (exec, en

ejecución), 5 (abend,

terminado de forma

anómala), 6 (succ,

satisfactorio), 7 (cancl,

cancelado), 8 (done,

terminado), 13 (fail, fallido),

16 (intro), 23 (pendiente de

terminación anómala), 24

(succp, pendiente de

satisfactorio), 25 (pend,

pendiente).

7 Nombre (real) enviado del

trabajo. Para aquellos

trabajos que se envían con at

o batch , este será el nombre

proporcionado por el usuario

si no es exclusivo. El nombre

exclusivo que genera

Maestro aparece como la

variable 3

8 Nombre de usuario bajo el

que se ejecuta el trabajo.

9 Nombre del archivo de

script del trabajo, o el

comando que ejecuta. El

espacio en blanco se

sustituye por el equivalente

octal; por ejemplo, un

espacio aparece como 040.





101 * 102 * 103 104 105* 204 * uTtrapJobAbend

uTtrapJobFailed

uTtrapJobLaunch

uTtrapJobDone

uTtrapJobUntil

uTtrapJobRerunPrompt

10 La frecuencia con la que

se ejecuta un trabajo every

(cada), expresada en forma

de hhmm . Si no se ha

especificado every (cada) para

el trabajo, será -32768.

11 Paso de recuperación de

trabajo, indicado por un

entero: 1 (detener), 2 (detener

después de trabajo de

recuperación), 3 (volver a

ejecutar), 4 (volver a ejecutar

después de trabajo de

recuperación), 5 (continuar),

6 (continuar después de

trabajo de recuperación), 10

(esta es la nueva ejecución

del trabajo), 20 (esta es la

ejecución del trabajo de

recuperación).

12 Una indicación de la hora

de evento, expresada como:

aaaammddhhmmss 00 (es decir,

año, mes, día, hora, minuto,

segundo, las centenas

siempre ceros).

13 El número de solicitud, o

cero si no hay solicitud.

14 El texto de la solicitud, o

el mensaje de error de Tivoli

Workload Scheduler.

151 * 152 * 153 154 155* uTtrapSchedAbend

uTtrapSchedStuck

uTtrapSchedStart

uTtrapSchedDone

uTtrapSchedUntil

1 Nombre de estación de

trabajo de la solicitud.

2 Nombre de planificación.

3 Estado de la planificación,


(ready, listo), 2 (hold,

retenido), 3 (exec, en

ejecución), 4 (stuck,

atascado), 5 (abend,

terminado de forma

anómala), 6 (succ,

satisfactorio), 7 (cancl,

cancelado).

4 Mensaje de error de Tivoli

Workload Scheduler, si hay

alguno.





201 * uTtrapGlobalPrompt 1 Nombre de solicitud

2 Número de solicitud

3 Texto de la solicitud

202 * uTtrapSchedPrompt 1 Nombre de estación de





203 * uTtrapJobPrompt 1 Nombre de estación de



3 Nombre de trabajo

4 Nombre de la estación de

trabajo del trabajo



251 252 * uTtrapLinkDropped

uTtrapLinkBroken

1 El nombre de la estación

de trabajo.

2 Estado del vínculo,


(desconocido), 2 (inactivo

debido a una

desvinculación), 3 (inactivo

debido a un error), 4 (activo).

3 Mensaje de error de Tivoli

Workload Scheduler.

* Estas condiciones de excepción están habilitadas de forma predeterminada.


Scheduler/NetView

La siguiente información se ofrece para aquellos que deseen ejecutar los programas

de Tivoli Workload Scheduler/NetView manualmente. El programa del gestor,

mdemon, se inicia habitualmente con NetView como parte de la secuencia ovstart

y sus opciones de ejecución se incluyen en el archivo /usr/OV/lrf/Mae.mgmt.lrf. El

programa del agente, magent, se inicia normalmente dentro del script StartUp de

Tivoli Workload Scheduler (<TWShome>/bin/StartUp).

Sinopsis de mdemon

mdemon [-timeout segs] [-pmd] [-port puerto] [-retry segs]

donde:



-timeout

La frecuencia a la que se sondean los agentes, expresada en segundos. El

valor predeterminado es de 60 segundos. Consulte los apartados

“Frecuencia de sondeo del gestor” en la página 138 y “Configuración de

agentes en NetView” en la página 139 para obtener más información sobre

cómo cambiar la frecuencia.

-pmd Esta opción causa que mdemon se ejecute bajo pmd (Port Map Demon) de

NetView. De lo contrario, debe ejecutarse manualmente. Esta opción se

incluye de forma predeterminada en el archivo /usr/OV/lrf/Mae.mgmt.lrf.

-port Sólo para agentes de HP-UX. Identifica la dirección del puerto de los

nodos gestionados en los que responderán los agentes de HP-UX. El valor


-retry El periodo de tiempo que mdemon esperará antes de intentar conectarse

de nuevo a un agente que no responde. El valor predeterminado es 600

segundos

Sinopsis de magent

La sintaxis de magent es la siguiente:

magent -peers host [, host [,...]] [-timeout segs ] [-notraps] [-port puerto]

donde:

-peers Sólo para agentes de HP-UX. Define los hosts (nombres o direcciones IP) a

los que el agente enviará sus condiciones de excepción. El valor

predeterminado es 127.0.0.1 (bucle cerrado).

Para los agentes de AIX el archivo /etc/snmpd.conf debe modificarse para

definir los hosts a los que el agente enviará sus condiciones de excepción.

Para añadir otro host, por ejemplo, duplique la línea de la condición de

excepción existente y cambie el nombre de host:

# Este archivo contiene el registro

# del agente de Tivoli Workload Scheduler.

#

trap public host1 1.3.6.1.4.1.736 fe

trap public host2 1.3.6.1.4.1.736 fe

-timeout

La velocidad a la que el agente comprueba sus procesos supervisados,

expresada en segundos. El valor predeterminado es de 60 segundos.

-notraps

Si se incluye, el agente no generará condiciones de excepción.

-port Sólo para agentes de HP-UX. Define la dirección del puerto en la que este

agente responde. El valor predeterminado es 31112.



Integración con IBM Tivoli Business Systems Manager

Esta sección describe la integración de IBM Tivoli Workload Scheduler con IBM

Tivoli Business Systems Manager.

General

IBM Tivoli Business Systems Manager es una aplicación de gestión de sistemas

orientada a objetos que facilita la supervisión y la gestión de eventos de recursos,

aplicaciones y subsistemas dentro de la empresa con el objetivo de proporcionar

disponibilidad continua. La supervisión de los planes diarios de Tivoli Workload

Scheduler con IBM Tivoli Business Systems Manager permite determinar

rápidamente los problemas que pueden poner en peligro la finalización

satisfactoria y oportuna de las planificaciones. La integración de Tivoli Workload

Scheduler con IBM Tivoli Business Systems Manager permite gestionar

planificaciones desde una perspectiva de sistemas empresariales exclusiva.

La integración se consigue mediante los siguientes elementos:

v Un indicador especial (indicador clave) de Tivoli Workload Scheduler que marca

aquellos trabajos o secuencias de trabajos que desea que IBM Tivoli Business

Systems Manager supervise con mayor detalle. La información sobre estos

objetos clave se envía en forma de eventos.

v Un mecanismo de descubrimiento masivo que envía información sobre todos los

trabajos y secuencias de trabajos clave del plan diario a IBM Tivoli Business

Systems Manager.

v Un mecanismo de descubrimiento parcial que envía cambios del plan diario

para trabajos y secuencias de trabajos clave a IBM Tivoli Business Systems

Manager.

Mediante estos mecanismos, el agente CommonListener de Tivoli Workload

Scheduler interactúa con el adaptador de IBM Tivoli Business Systems Manager

CommonListener. La figura siguiente muestra de qué modo los eventos y los

comandos se pasan desde batchman al agente de escucha común que, a su vez, los

interpreta y ejecuta peticiones adecuadas al adaptador de TBSM.

Nota: El proceso de agente CommonListener debe detenerse y reiniciarse cada día.

Es necesario un descubrimiento masivo diario para que la integración

funcione correctamente.

Figura 7. Arquitectura del agente de escucha común



Para el descubrimiento masivo, la base de datos de TBSM se llena con todos los

objetos clave que están en el plan diario de Tivoli Workload Scheduler. Para cada

objeto clave del plan, el planificador reenvía información sobre su tipo,

propiedades y estado a la interfaz de escucha común de TBSM. A continuación, el

escucha común llena la base de datos de TBSM con estos datos.

Cuando se añade un nuevo trabajo o secuencia de trabajos al plan de Tivoli

Workload Scheduler, una función add de descubrimiento parcial reenvía la

información a IBM Tivoli Business Systems Manager. Del mismo modo, cuando se

cambia un atributo de objeto clave, una función modify de descubrimiento parcial

notifica a IBM Tivoli Business Systems Manager.

Utilización del mecanismo del indicador clave

El indicador clave identifica los trabajos o secuencias de trabajo más críticos que

deben supervisarse con IBM Tivoli Business Systems Manager. A tales trabajos o

secuencias de trabajo se les denomina habitualmente trabajos clave y secuencias de

trabajos clave.

Si un trabajo o secuencia de trabajos se marca como clave, IBM Tivoli Business

Systems Manager recibirá una notificación cada vez que se produzca un cambio de

estado o un cambio de propiedad.

En cualquier caso, la notificación de determinados eventos críticos se reenvía para

todos los trabajos y secuencias de trabajos, independientemente de si tienen el

indicador clave o no. La Tabla 34 lista dichos eventos.

Tabla 34. Eventos reenviados para objetos de planificación clave y no clave

Evento de

planificador Tipo de ID

Tipo de evento de

TBSM Gravedad

TWS_Job_Abend Batch Excepción Crítico

TWS_Sched_Abend BatchCycle Excepción Crítico

TWS_Job_Cancel Batch Mensaje Aviso

TWS_Sched_Cancel BatchCycle Mensaje Aviso

TWS_Job_Failed Batch Excepción Crítico

Definición del indicador clave

Para habilitar el mecanismo de indicador clave de la estación de trabajo, debe tener

correctamente configurado el parámetro del archivo BmEvents.conf (consulte el

apartado “Personalización de BmEvents.conf” en la página 149).

Puede marcar un trabajo o secuencia de trabajos como clave tanto en la base de

datos como en el plan diario. En la base de datos, los trabajos clave pueden

definirse como si estuvieran insertados en una secuencia de trabajos.

Para marcar un trabajo o una secuencia de trabajos como clave, puede utilizar uno

de los métodos siguientes:

v Las palabras clave KEYSCHED (para secuencias de trabajos) y KEYJOB (para

trabajos), tal como muestra el ejemplo siguiente.

SCHEDULE cpu1#sched1

ON mo,tu...

AT 0100

KEYSCHED

:cpu1#myjob1 KEYJOB



END

cpu1#myjob1

SCRIPTNAME"C:\my.bat"

STREAMLOGON"twsusr1"

RECOVERY STOP

v Las ventanas de propiedades de trabajo y secuencia de trabajos de Job

Scheduling Console.

Las ventanas de propiedades de trabajo muestran, tanto a nivel de base de datos

como de plan, una casilla de selección Es trabajo supervisado que se marca para

especificar la supervisión de IBM Tivoli Business Systems Manager. En la

ventana de propiedades de trabajo del nivel de plan, puede cambiar este valor

para la instancia de trabajo específica.

Las ventanas de propiedades de corriente de trabajo muestran, a nivel de base

de datos y de plan, los dos elementos siguientes:

– Una casilla de selección Es secuencia de trabajos supervisada que se marca

para especificar que IBM Tivoli Business Systems Manager debe supervisar la

secuencia de trabajos. Puede cambiar este valor a nivel de instancia de

secuencia de trabajos.

– Un campo de sólo lectura denominado Contiene trabajo supervisado que

indica si alguno de los trabajos comprendidos en la secuencia de trabajos se

ha marcado como clave.Puede elegir el indicador clave como criterio de filtrado cuando ejecuta listas de

trabajos o secuencias de trabajos en la base de datos o en el plan.

Instalación y actualización del agente de escucha común

Tivoli Workload Scheduler, Versión 8.2 se integra con Tivoli Business System

Manager, Versión 1.5 con APAR OW51467 o posterior.

Debe tener Java Runtime Environment (JRE) Versión 1.3 instalado en cada estación

de trabajo que va a ejecutar el agente de escucha común.

El agente de escucha común se instala automáticamente con Tivoli Workload

Scheduler. Puede ejecutarse en cualquier tipo de estación de trabajo de IBM Tivoli

Workload Scheduler (maestro, FTA, etc.). Debe iniciar como mínimo uno por cada

red de IBM Tivoli Workload Scheduler, posiblemente en el maestro o en un FTA

que se haya configurado con la opción de estado completo.

Después de instalar IBM Tivoli Workload Scheduler, haga lo siguiente para

configurar el agente de escucha común:

1. Entre lo siguiente para configurar el entorno:

v En Windows:

PATH=%JRE-DIR%\jre\bin;%JRE-DIR%\jre\bin\classic;%PATH%

v En Solaris:

LD_LIBRARY_PATH=$JRE-DIR/jre/lib/sparc/:$JRE-DIR/jre/lib/sparc/client:$LD_LIBRARY_PATH

v En AIX:

LD_LIBRARY_PATH=$JRE-DIR/jre/bin/classic/:$JRE-DIR/jre/bin/:$LD_LIBRARY_PATH

LIBPATH=$JRE-DIR/jre/bin/classic/:$JRE-DIR/jre/bin/:TWShome/Tbsm/

TbsmAdapter:$LIBPATH

export LIBPATH

AIXTHREAD_SCOPE=S

AIXTHREAD_MUTEX_DEBUG=OFF

AIXTHREAD_RWLOCK_DEBUG=OFF

AIXTHREAD_COND_DEBUG=OFF



v En Linux:

LD_LIBRARY_PATH=$JRE-DIR/jre/bin/classic:$JRE-DIR/jre/bin:$LD_LIBRARY_PATH

donde $JRE-DIR es la ruta de instalación de Java RunTime Environment 1.3.1.

Nota: Después de establecer la ruta, reinicie IBM Tivoli Workload Scheduler

antes de iniciar el agente de escucha común.

2. Configure el archivo <TWShome>/Tbsm/TbsmAdapter/adapter.config para

permitir que el agente de escucha común se conecte al CommonListener de

Tivoli Business Systems Manager. Establezca los siguientes parámetros:

loggingmode.default = false

transport.local.ip.address = adapterhost

transport.request.address = adapterhost.INSTR.QM+INSTR.Q

transport.response.address = adapterhost.INSTR.QM+INSTR.Q

transport.server.ip.address = serverhost

donde,

adapterhost

Es el nombre de host completo del sistema que está ejecutando el

agente de escucha común.

serverhost

Es el nombre de host completo del sistema donde se ha instalado el

CommonListener.

Durante la instalación se copian los siguientes archivos en un directorio

denominado <TWShome>/CommonListener:

v El ejecutable del agente de escucha común que ejecutará el proceso de escucha

común.

v El archivo de configuración ClEvents.conf.

v El script customize que debe ejecutar cuando termina la instalación de Tivoli

Workload Scheduler.

Cuando ejecuta customize, el script realiza las siguientes acciones:

1. Instala ClEvents.conf en el directorio <TWShome>.

2. Instala BmEvents.conf en el directorio <TWShome> si todavía no se ha instalado.

Se personaliza para que lo utilice el agente de escucha común.

Nota: Para ejecutar customize, debe iniciar la sesión como administrador.

Personalización de los archivos de configuración

Para ejecutar el agente de escucha común hay dos archivos de gran importancia:

v BmEvents.conf

v ClEvents.conf

Estos archivos se configuran con valores predeterminados cuando ejecuta

customize. Puede cambiar los valores predeterminados si tiene preferencias

distintas con respecto a qué eventos que se notificarán a IBM Tivoli Business

Systems Manager y cómo deben notificarse.

Mailman, batchman o el agente de escucha común leen estos archivos de

configuración cuando se inicializan. Si efectúa cambios en dichos archivos, tendrá

que reiniciarlos.



Personalización de BmEvents.conf

Puede cambiar los siguientes parámetros:

OPTIONS=MASTER|OFF

Si el valor es OFF, sólo se reenvían a IBM Tivoli Business Systems

Manager los eventos locales. Si el valor es MASTER, también se reenvían

los eventos que se producen en las estaciones de trabajo conectadas. El

valor debería ser MASTER para la estación de trabajo maestra y OFF para

las otras estaciones de trabajo.

LOGGING=ALL|KEY

Si el valor es KEY, se habilita el mecanismo de filtrado de indicadores

clave. Los eventos se envían sólo para trabajos y secuencias de trabajos

clave (consulte la Tabla 35 para encontrar los eventos filtrados por el

indicador clave y la Tabla 34 para obtener una lista de los eventos que se

reenvían independientemente de que el trabajo o la secuencia de trabajos

sea clave o no). Si el valor es ALL, los eventos también se envían para

trabajos y secuencias de trabajos no clave.

EVENTS = <n>

La lista de eventos que se deben notificar a IBM Tivoli Business Systems

Manager. De forma predeterminada, se envían todos los eventos listados

en la Tabla 35 en la página 150. Puede excluir algunos eventos si no le

interesa notificarlos. En este caso, escriba aquí la lista de números de

evento que desea enviar.

MSG = <ruta_msg>

El nombre y la ruta del archivo de mensajes donde batchman y mailman

grabarán los eventos que deberá leer el agente de escucha común. Puede

añadir más de un archivo de mensajes.

SYMEVNTS=YES|NO

Si el valor es YES, batchman notifica eventos de estado de trabajo

inmediatamente después de la generación del plan. Sólo es válido para

trabajos indicados como clave con LOGGING=KEY. Si el valor se

establece en NO, no se proporciona ningún informe. NO es el valor

predeterminado.

Personalización de ClEvents.conf

Puede cambiar los siguientes parámetros:

EVENTS = <n>

La lista de eventos que se deben notificar a IBM Tivoli Business Systems

Manager. De forma predeterminada, se envían todos los eventos listados

en la Tabla 35 en la página 150. Puede excluir algunos eventos si no le

interesa notificarlos. En este caso, escriba aquí la lista de números de

evento que desea enviar.

MSG = <ruta_msg>

El nombre y la ruta del archivo de mensajes donde batchman y mailman

grabarán los eventos que deberá leer el agente de escucha común. El

nombre y la ruta de este archivo debe coincidir con uno de los archivos de

salida especificados en BmEvents.conf.

RETRYINTERVAL=<segundos>

La cantidad de tiempo transcurrido el cual el cl_agent (agente de escucha

común) intenta volver a conectarse con el adaptador de Tivoli Business

Systems Manager.



Inicio y detención del agente de escucha común

El proceso del agente de escucha común es independiente de los otros procesos de

Tivoli Workload Scheduler. Puede ejecutarlo con los siguientes mandatos:

conman clagent_start

Inicia el agente enviando una nueva petición de servicio a netman. Al igual

que el comando conman start, esta petición también inicia netman, si está

inactivo.

conman clagent_stop

Detiene el agente colocando un mensaje en el buzón.

conman cl_bulkdiscovery

Reúne información sobre los trabajos y las secuencias de trabajo clave.

Eventos de Tivoli Workload Scheduler/IBM Tivoli Business

Systems Manager

La Tabla 35 lista los eventos que se notifican a IBM Tivoli Business Systems

Manager a menos que lo especifique de otro modo en los archivos de

configuración (consulte el apartado “Personalización de los archivos de

configuración” en la página 148).

Tabla 35. Eventos de Tivoli Workload Scheduler para Tivoli Business Systems Manager

Evento Tipo Descripción

El filtrado

de indica-

dores

clave está

habilitado

101 mstJobAbend El trabajo ha terminado de forma

anómala

No

102 mstJobFailed El trabajo está en estado de error No

103 mstJobLaunch El trabajo se ha iniciado Sí

104 mstJobDone El trabajo ha finalizado Sí

105 mstJobUntil Trabajo hasta que caduque el tiempo No

106 mstJobSubmit El trabajo se ha enviado No

107 mstJobCancel El trabajo se ha cancelado No

108 mstJobReady El trabajo está en estado de listo Sí

109 mstJobHold El trabajo está en estado de retenido Sí

110 mstJobRestart El trabajo está en estado de reiniciar Sí

111 mstJobCant Batchman no ha podido secuenciar el

trabajo

No

112 mstJobSuccp El trabajo está en estado pendiente de

satisfactorio

Sí

113 mstJobExtrn El trabajo está en estado de externo Sí

114 mstJobIntro El trabajo está en estado de intro Sí

115 mstJobStuck El trabajo está en estado de atascado Sí

116 mstJobWait El trabajo está en estado de espera Sí

117 mstJobWaitd El trabajo está en estado de espera

aplazada

Sí

118 mstJobSched El trabajo está en estado de

planificación

Sí



Tabla 35. Eventos de Tivoli Workload Scheduler para Tivoli Business Systems

Manager (continuación)


El filtrado

de indica-

dores

clave está

habilitado

119 mstJobModify Se ha modificado la propiedad del

trabajo

Sí

120 mstJobLate El trabajo se ha retrasado Sí

121 mstJobUntilCont Trabajo hasta que caduque el tiempo

con opción de continuar

Sí

122 mstJobUntilCanc Trabajo hasta que caduque el tiempo

con opción de cancelar

Sí

151 mstSchedAbend La planificación ha terminado de

forma anómala

No

152 mstSchedStuck La planificación está en estado de

retenida

No

153 mstSchedStart La planificación se ha iniciado Sí

154 mstSchedDone La planificación ha finalizado Sí

155 mstSchedUntil Planificación hasta que caduque el

tiempo

Sí

156 mstSchedSubmit La planificación se ha enviado No

157 mstSchedCancel La planificación se ha cancelado No

158 mstSchedReady La planificación está en estado de

lista

Sí

159 mstSchedHold La planificación está en estado de

retenida

Sí

160 mstSchedExtrn La planificación está en estado de

externa

Sí

161 mstSchedCnPend La planificación está en estado

pendiente de cancelación

Sí

163 mstSchedLate La planificación se ha retrasado Sí

164 mstSchedUntilCont Planificación hasta que caduque el

tiempo con opción de continuar

Sí

165 mstSchedUntilCanc Planificación hasta que caduque el

tiempo con opción de cancelar

Sí

201 mstGlobalPrompt Se ha mostrado una solicitud global No

202 mstSchedPrompt Se ha mostrado una solicitud local

para una planificación

Sí

203 mstJobPrompt Se ha mostrado una solicitud local

para un trabajo

Sí

204 mstJobRecovPrompt Se ha mostrado una solicitud para un

trabajo de recuperación

No

251 mstLinkDropped Se ha cerrado el vínculo de

comunicación entre estaciones de

trabajo

No



Tabla 35. Eventos de Tivoli Workload Scheduler para Tivoli Business Systems

Manager (continuación)


El filtrado

de indica-

dores

clave está

habilitado

252 mstLinkBroken Ha fallado el vínculo de

comunicación entre estaciones de

trabajo

No

351 mstDomainMgrSwitch El gestor de dominio se ha

conmutado.

No



Capítulo 11. Definición de la seguridad

Este capítulo describe las funciones de seguridad siguientes:

v “Definición de una autenticación y un cifrado estrictos”

v “Cómo trabajar con cortafuegos” en la página 164

Definición de una autenticación y un cifrado estrictos

Tivoli Workload Scheduler proporciona un mecanismo de conexión seguro,

autenticado y cifrado entre componentes que se ejecutan en dominios no

protegidos y componentes que se ejecutan en dominios protegidos. Este

mecanismo está basado en el protocolo Secure Sockets Layer (SSL) y hace uso de

OpenSSL Toolkit, el cual se instala automáticamente en la estación de trabajo del

usuario junto con IBM Tivoli Workload Scheduler.

El usuario o administrador de IBM Tivoli Workload Scheduler puede decidir si

desea implementar o no el soporte de SSL en la red.

Nota: Antes de implementar el soporte de SSL en la red de Tivoli Workload

Scheduler, consulte al administrador de seguridad con respecto a la política

de la empresa.

Si decide no implementar el soporte de SSL, la seguridad de la instalación de IBM

Tivoli Workload Scheduler dependerá de un simple mecanismo de autenticación

basado en la comprobación de IP y de un mecanismo de cifrado que se aplica sólo

a las contraseñas de los usuarios de Windows.

El protocolo SSL está basado en un sistema de claves privadas y públicas y es la

norma de seguridad más estricta actualmente en uso para las comunicaciones en

Internet. La seguridad de conexión proporcionada por el protocolo tiene tres

propiedades básicas:

v La conexión es privada. Se utiliza el cifrado después de un reconocimiento

inicial para definir una clave secreta. Se utiliza cifrado simétrico para el cifrado

de datos (por ejemplo, DES y RC4).

v La identidad de la entidad homóloga (interlocutor) se puede autenticar

utilizando el cifrado por claves asimétricas o públicas (por ejemplo, RSA y DSS).

v La conexión es fiable. El mecanismo de transporte de mensajes incluye una

comprobación de la integridad de los mensajes que hace uso de un MAC por

clave. Se utilizan funciones seguras de cálculo de claves, tales como SHA y MD5,

para los cálculos de MAC.

IBM Tivoli Workload Scheduler utiliza la autenticación SSL al abrir una sesión

cliente-servidor entre dos estaciones de trabajo principalmente para asegurar la

identidad del proceso cliente (tal como mailman o el conector) que está solicitando

hacer uso de la conexión.

El administrador de Tivoli Workload Scheduler deberá definir qué estaciones de

trabajo de la red necesitan establecer sesiones SSL con las demás estaciones de

trabajo. La información que indica si una conexión debe ser o no de tipo SSL se

puede configurar en la definición de la estación de trabajo, contenida en la base de

datos de IBM Tivoli Workload Scheduler, utilizando la línea de comandos o Job

Scheduling Console de IBM Tivoli Workload Scheduler.


El soporte para SSL de Tivoli Workload Scheduler proporciona funciones básicas en

el sector de la gestión de certificados. Aporta funciones básicas, tales como la

inserción y gestión de claves y certificados, a la configuración del depósito de

claves y de la cadena de confianza. No proporciona recursos de gestión avanzada

de certificados, tales como listas de revocación y consultas de revocación basadas

en directorios de la red.

Para proporcionar seguridad de SSL para un gestor de dominio conectado a IBM

Tivoli Workload Scheduler for z/OS en una conexión de extremo a extremo, debe

configurar OS/390 Cryptographic Services System SSL en el código de IBM Tivoli

Workload Scheduler que se ejecuta en el shell de UNIX para OS/390 USS, del

espacio de direcciones del servidor IBM Tivoli Workload Scheduler for z/OS.

Consulte la documentación de IBM Tivoli Workload Scheduler for z/OS para

conocer cómo realizar esa tarea.

Conceptos clave de SSL

Para autenticar la identidad de una entidad homóloga, el protocolo SSL utiliza

certificados X.509 denominados certificados digitales. En esencia, un certificado

digital es una tarjeta de identificación electrónica emitida por una entidad fiable y

que permite que un usuario verifique al emisor y receptor del certificado mediante

el uso del cifrado por clave pública.

El cifrado por clave pública utiliza dos claves de cifrado diferentes: una clave

privada y una clave pública. El cifrado por clave pública también se denomina

cifrado asimétrico, pues la información se puede cifrar con una clave y descifrarla

con la clave complementaria perteneciente a un par proporcionado de claves

públicas-privadas. Los pares de claves públicas-privadas son simplemente largas

cadenas de datos que actúan como claves en un sistema de cifrado de un usuario.

El usuario guarda la clave privada en un lugar seguro (por ejemplo, en forma

cifrada en el disco duro de un PC) y proporciona la clave pública a las personas

con las que se desea comunicar. La clave privada se utiliza para añadir una firma

digital a todas las comunicaciones seguras enviadas por el usuario, mientras que la

clave pública es utilizada por el receptor para verificar la firma del emisor.

El cifrado por clave pública está basado en una relación de confianza: el receptor

de una clave pública necesita tener la seguridad de que la clave pertenece

realmente al emisor y no a un impostor. Los certificados digitales proporcionan esa

seguridad. Por esta razón, las estaciones de trabajo de IBM Tivoli Workload

Scheduler que comparten una sesión de SSL deben tener instalados localmente

depósitos para los certificados X.509 que se intercambiaran durante el

establecimiento de la sesión de SSL para autenticar la sesión.

Los certificados digitales son emitidos por una autoridad fiable, denominada

también autoridad de certificación (certificate authority, CA). Un certificado digital

firmado contiene:

v El nombre distinguido del propietario

v La clave pública del propietario

v El nombre distinguido de la autoridad de certificación (del emisor)

v La firma de la autoridad de certificación sobre esos campos

La petición de certificación que se envía a una autoridad de certificación para

firmar contiene:

v El nombre distinguido del propietario (del peticionario)


Definición de la seguridad


v La firma del propietario sobre esos campos

Una autoridad de certificación (CA), tal como VeriSign o Thawte, establece una

relación de confianza con una aplicación cliente (o servidor) cuando su certificado

raíz (es decir, el certificado que contiene la firma de la autoridad de certificación)

aparece en las listas de autoridades de certificación fiables del cliente (servidor). La

forma en que una aplicación crea su lista de autoridades de certificación fiables

depende de la implementación de SSL. Por ejemplo, si se utiliza OpenSSL, la lista

de autoridades de certificación fiables es simplemente un archivo que contiene los

certificados concatenados de todas las autoridades de certificación en las que se

debe confiar. Si se utiliza OS/390 Cryptographic Services System SSL, la lista de

autoridades de certificación fiables es una base de datos exclusiva que contiene los

certificados de las autoridades de certificación fiables. La autoridad de certificación

verifica esta firma con la clave pública del certificado digital para asegurarse de

que la petición de certificación no se ha modificado al circular entre el peticionario

y la CA y que el peticionario está en posesión de la clave privada que coincide con

la clave pública contenida en la petición de certificación.

La CA también se encarga de realizar cierto grado de verificación de la identidad.

Esto puede comprender desde una reconocimiento laxo de la identidad del

propietario hasta un reconocimiento absoluto. Una clase particular de certificado es

el certificado digital autofirmado, que contiene lo siguiente:

v El nombre distinguido del propietario


v La firma del propietario sobre esos campos

El certificado digital raíz de una CA es un ejemplo de certificado digital

autofirmado. Los usuarios pueden también crear sus propios certificados digitales

autofirmados con fines de prueba.

El ejemplo siguiente describe de forma simplificada cómo se utilizan los

certificados digitales al establecer una sesión de SSL. En este supuesto, Appl1 es un

proceso cliente que establece una conexión SLL con la aplicación servidor Appl2:

1. El cliente Appl1 solicita establecer una sesión de SSL con el servidor Appl2.

2. Appl2 inicia el protocolo de reconocimiento de SSL. Appl2 cifra la información

utilizando su clave privada y envía su certificado junto con la clave pública

correspondiente a Appl1.

3. Appl1 recibe el certificado procedente de Appl2 y verifica que esté firmado por

una autoridad de certificación (CA) fiable. Si el certificado está firmado por una

CA fiable, Appl1 puede opcionalmente extraer algo de información (tal como el

nombre distinguido) almacenada en el certificado y realiza comprobaciones de

autenticación adicionales sobre Appl2.

4. En este momento, el proceso servidor se ha autenticado, y el proceso cliente

inicia su parte del proceso de autenticación, es decir, Appl1 cifra la información

utilizando su clave privada y envía el certificado junto con su clave pública a

Appl2.

5. Appl2 recibe el certificado procedente de Appl1 y verifica que esté firmado por

una autoridad de certificación (CA) fiable.

6. Si el certificado está firmado por una CA fiable, Appl2 puede opcionalmente

extraer algo de información (tal como el nombre distinguido) almacenada en el

certificado y realiza comprobaciones de autenticación adicionales sobre Appl1.


Capítulo 11. Definición de la seguridad 155

Planificación del soporte de SSL en Tivoli Workload Scheduler

Para implementar el soporte de SSL en la red, el administrador de Tivoli Workload

Scheduler debe planificar por adelantado cómo las estaciones de trabajo se

autenticarán entre sí. El administrador puede decidir configurar la red de Tivoli

Workload Scheduler de forma que todas las estaciones de trabajo que establezcan

sesiones de SSL se autentiquen de la misma manera, o bien configurar niveles de

autenticación diferentes para cada estación de trabajo. El nivel de autenticación

afecta la forma en que se crean los certificados digitales y se instalan en las

estaciones de trabajo donde se utiliza el soporte de SSL. Para habilitar el soporte

de SSL, especifique opciones locales de SSL en el archivo localopts. Consulte el

apartado “Definición de las opciones locales de SSL” en la página 162.

SSL proporciona los métodos de autenticación siguientes:

Relación de confianza a través de una CA solamente

Dos estaciones de trabajo establecen una relación de confianza entre ellas si

cada una recibe de la otra un certificado que está firmado por una

autoridad de certificación fiable (tal como VeriSign), es decir, si el

certificado de la CA está en la lista de autoridades de certificación fiables

de cada estación de trabajo. Con este nivel de autenticación, la estación de

trabajo no realiza ninguna comprobación adicional sobre el contenido del

certificado, tal como la verificación del nombre distinguido. Cualquier

certificado (incluso un certificado bancario personal) firmado por una CA

fiable se puede utilizar para establecer una sesión de SSL. Esta

autenticación es bastante débil, pues permite que un intruso provisto de

una clave privada y un certificado firmado los instale en una estación de

trabajo cualquiera y establezca una conexión dentro de la red. En este

método se utiliza una clave privada y un certificado individual para la red

de Tivoli Workload Scheduler completa. Consulte la página 163 para

definir la opción ″caonly″ en el archivo localopts.

Comprobar si el nombre distinguido coincide con una cadena de caracteres

definida

Dos estaciones de trabajo establecen una relación de confianza entre ellas

si, tras recibir un certificado con la firma de la CA fiable, cada una realiza

una comprobación adicional extrayendo el nombre distinguido contenido

en el certificado y comparándolo con una cadena de caracteres que el

administrador de Tivoli Workload Scheduler ha definido en el archivo de

opciones locales de la estación de trabajo. Este método añade un nivel más

de autenticación al método de relación de confianza a través de una CA

solamente. Un intruso puede tener una clave privada y un certificado

firmado, pero el nombre distinguido especificado en ese certificado debe

coincidir con el especificado en el certificado original. Si no coinciden, no

se establece la conexión. Con este método, puede también emplear una

clave privada y un certificado diferentes para cada dominio de la red.

Consulte la página 163 para definir la opción ″string″ en el archivo

localopts.

Comprobar si el nombre distinguido coincide el nombre de la estación de

trabajo

Dos estaciones de trabajo establecen una relación de confianza entre ellas

si, tras recibir un certificado con la firma de la CA fiable, cada una realiza

una comprobación adicional extrayendo el nombre distinguido contenido

en el certificado y comparándolo con el nombre de la estación de trabajo

que ha enviado el certificado. Este método añade un nivel más de

autenticación. Un intruso puede tener una clave privada y un certificado

firmado, pero el nombre distinguido especificado en ese certificado debe



coincidir con el nombre de la estación de trabajo. El utilizar de esta forma

el nombre distinguido ayuda también a comprobar la identidad de la

estación de trabajo interlocutora. Con este método, puede también emplear

una clave privada y un certificado diferentes para cada estación de trabajo

de la red. Consulte la página 163 para definir la opción ″cpu″ en el archivo

localopts.

Como administrador de Tivoli Workload Scheduler, puede elegir implementar uno

de los métodos siguientes o una combinación de ellos:

Utilizar el mismo certificado para la red completa

En este caso, debe seguir estos pasos:

1. Cree una clave privada.

2. Cree una petición de firma de certificado para esa clave privada.

Opcionalmente, puede asignar al campo del nombre distinguido (DN)

del certificado una cadena de caracteres de su elección, por ejemplo, el

nombre del maestro de Tivoli Workload Scheduler.

3. Solicite a una autoridad de certificación (externa, tal como VeriSign o

Thawte, o de creación propia) que firme un certificado correspondiente

a la clave privada. Si ha creado su propia autoridad de certificación, el

certificado se denomina certificado autofirmado.

4. Instale la clave privada y el certificado en todas las estaciones de

trabajo donde se utilizará SSL.

5. Añada la autoridad de certificación que ha firmado el certificado a la

lista de las CA fiables en todas las estaciones de trabajo donde se

utilizará SSL.

Si las estaciones de trabajo están configuradas con la opción Relación de

confianza a través de CA solamente, aceptarán conexiones con cualquier

otra estación de trabajo que envíe un certificado firmado por esa CA fiable.

Para aplicar la autenticación, puede definir en el archivo de opciones

locales de las estaciones de trabajo un nombre o lista de nombres que

deben coincidir con el contenido del campo de nombre distinguido (DN)

del certificado para poder aceptar una petición de conexión.

Utilizar un certificado para cada dominio

En este caso, repita los pasos anteriores para crear e instalar más claves

privadas y certificados firmados, uno para cada dominio de la red de IBM

Tivoli Workload Scheduler. A continuación, configure cada estación de

trabajo para que acepte conexiones sólo con interlocutores que tengan una

cadena de caracteres determinada en el campo de nombre distinguido de

su certificado.

Utilizar un certificado para cada CPU

En este caso, repita los pasos anteriores para crear e instalar en cada

estación de trabajo una clave privada y certificado firmado diferentes y

añadir una lista de las CA fiables que contenga la CA que ha firmado el

certificado. A continuación, configure cada estación de trabajo para que

acepte conexiones sólo con interlocutores que tengan su nombre de

estación de trabajo (tal como aparece en el archivo Symphony) registrado

en el campo del nombre distinguido de su certificado.

Si utiliza la autenticación SSL para la red de Tivoli Workload Scheduler de su

empresa y no para el comercio exterior por Internet, puede actuar como su propia

autoridad de certificación para crear y firmar los certificados. Para ser su propia

CA (autoridad de certificación), debe crear una clave de CA y un certificado de CA

autofirmado. Una vez hecho eso, podrá firmar cualquier petición de certificación



con su propia firma de CA y crear certificados válidos. Para utilizar un certificado

autofirmado, debe añadir su certificado de CA a la lista de las CA fiables de cada

estación de trabajo donde se utilizará SSL. Esto permite a los clientes actuar como

una autoridad de certificación real, sin tener que solicitar certificados a una CA

comercial.

Configuración del soporte de SSL en Tivoli Workload

Scheduler

Para configurar SSL para la red, debe seguir estos pasos:

1. Cree un directorio SSL dentro del directorio TWShome. Por omisión, el archivo

localopts contiene la ruta TWShome\ssl. Si crea un directorio con un nombre

diferente de SSL en el directorio TWShome, actualice el archivo localopts según

convenga.

2. Copie openssl.cnf y openssl.exe en el directorio SSL.

3. Cree tantas claves privadas, certificados y listas de las CA fiables como piense

utilizar en la red.

4. Para cada estación de trabajo donde se utilizará la autenticación SSL:

v Actualice la definición de la estación de trabajo en la base de datos de Tivoli

Workload Scheduler con los atributos de SSL.

v Añada las opciones locales de SSL al archivo localopts.

Aunque no es necesario seguir un orden determinado, se deben ejecutar todas

estas tareas para activar el soporte de SSL.

En Tivoli Workload Scheduler, el soporte de SSL está disponible sólo para los

agentes tolerantes a errores (incluidos el maestro y los gestores de dominio), pero

no para los agentes ampliados. Si desea utilizar la autenticación SSL para una

estación de trabajo donde se ejecuta un agente ampliado, debe especificar este

parámetro en la definición de la estación de trabajo host del agente ampliado.

Configuración de claves privadas y certificados

Para utilizar la autenticación SSL en una estación de trabajo, necesita crear e

instalar lo siguiente:

v La clave privada y el certificado correspondiente que identifica a la estación de

trabajo en una sesión de SSL.

v La lista de autoridades de certificación en las que puede confiar la estación de

trabajo.

Debe utilizar el programa de utilidad openssl desde la línea de comandos para:

v Crear un archivo que contiene bytes generados de forma seudoaleatoria

(TWS.rnd). Este archivo es necesario en algunas plataformas para que SSL

funcione correctamente.

v Crear una clave privada.

v Guardar la contraseña que se ha utilizado para instalar la clave en un archivo.

v Crear una petición de firma de certificado.

v Enviar esta petición de firma de certificado a una autoridad de certificación para

que la firma, o bien:

– Crear su propia autoridad de certificación

– Crear un certificado de CA autofirmado (estructura X.509) con la clave RSA

de su propia CA

– Utilizar su propia autoridad de certificación para firmar y crear certificados

reales



Esas acciones crearán los archivos siguientes, que instalará en las estaciones de

trabajo:

v Un archivo de clave privada (por ejemplo, TWS.key). Este archivo debe estar

protegido, para que no se robe con el fin de utilizar la identidad de la estación

de trabajo. Guarde este archivo en un directorio para el que tenga acceso de

lectura el usuario de TWS de la estación de trabajo, por ejemplo,

TWShome/ssl/TWS.key.

v El archivo de certificado correspondiente (por ejemplo, TWS.crt). Guarde este

archivo en un directorio para el que tenga acceso de lectura el usuario de TWS

de la estación de trabajo, por ejemplo, TWShome/ssl/TWS.crt.

v Un archivo que contiene una secuencia de bytes generada de forma

seudoaleatoria. Guarde este archivo en cualquier directorio para el que tenga

acceso de lectura el usuario de TWS de la estación de trabajo, por ejemplo,

TWShome/ssl/TWS.rnd.

Además, debe crear lo siguiente:

v Un archivo que contiene la contraseña utilizada para cifrar la clave privada.

Guarde este archivo en un directorio para el que tenga acceso de lectura el

usuario de TWS de la estación de trabajo, por ejemplo, TWShome/ssl/TWS.sth.

v El archivo de la cadena de certificados. Contiene la concatenación de los

certificados codificados por PEM procedentes de autoridades de certificación que

forman la cadena de certificados del certificado de la estación de trabajo.

Empieza con el certificado de las CA de la estación de trabajo y puede

extenderse hasta el certificado de la CA raíz. Este archivo es simplemente la

concatenación de los diversos archivos de certificados de CA, codificados por

PEM, normalmente dispuestos en el orden de la cadena de certificados.

v El archivo de las autoridades de certificación fiables. Contiene los certificados de

las CA fiables para utilizarlos durante la autenticación. Las CA de este archivo

también se utilizan para crear la lista de las CA de cliente aceptables que se

pasan al cliente cuando el extremo servidor de la conexión solicita un certificado

de cliente. Este archivo es simplemente la concatenación de los diversos archivos

de certificados de CA, codificados por PEM, dispuestos en orden de preferencia.

Creación de una autoridad de certificación propia

Si piensa utilizar la autenticación SSL dentro de los límites de su empresa y no

para el comercio exterior por Internet, puede resultarle más fácil crear su propia

autoridad de certificación (CA) para crear una relación de confianza con todas las

instalaciones de IBM Tivoli Workload Scheduler. Para ello, siga los pasos indicados

a continuación.

Nota: En los pasos siguientes, se utilizan nombres de ejemplo para designar los

archivos creados durante el proceso TWS y TWSca. Puede utilizar nombres

de su elección, pero conserve las mismas extensiones de archivo.

1. Seleccione una estación de trabajo como instalación raíz de la CA.

2. Escriba el comando siguiente desde el directorio SSL para inicializar el

generador de números seudoaleatorios, de lo contrario los comandos siguientes

no serán efectivos.

v En UNIX:

$ openssl rand -out TWS.rnd -rand ./openssl 8192

v En Windows:

$ openssl rand -out TWS.rnd -rand ./openssl.exe 8192

3. Escriba el comando siguiente para crear la clave privada de la CA:

$ openssl genrsa -out TWSca.key 1024



4. Escriba el comando siguiente para crear un certificado de CA autofirmado

(estructura X.509):

$ openssl req -new -x509 -days 365 -key TWSca.key -out TWSca.crt -config ./openssl.cnf

Ahora tiene una autoridad de certificación que puede utilizar para crear una

relación de confianza con todas las instalaciones. Si lo desea, puede crear más de

una CA.

Creación de claves privadas y certificados

Los pasos siguientes describen cómo crear una clave y un certificado individuales.

Puede decidir si desea utilizar un solo par clave-certificado para la red completa,

un par para cada dominio o uno para cada estación de trabajo. En los pasos

siguientes se supone que desea crear un par clave-certificado para cada estación de

trabajo; por ello se utiliza el nombre genérico nombre_estación_trabajo para designar

los archivos de salida creados durante el proceso.

En cada estación de trabajo, siga los pasos siguientes para crear una clave privada

y un certificado:

1. Escriba el comando siguiente desde el directorio SSL para inicializar el

generador de números seudoaleatorios, de lo contrario los comandos siguientes

no serán efectivos.

v En UNIX:

$ openssl rand -out nombre_estación_trabajo.rnd -rand ./openssl 8192

v En Windows:

$ openssl rand -out nombre_estación_trabajo.rnd -rand ./openssl.exe 8192

2. Escriba el comando siguiente para crear la clave privada (este ejemplo utiliza el

cifrado triple-DES):

$ openssl genrsa -des3 -out nombre_estación_trabajo.key 1024

A continuación, guarde la contraseña que se ha solicitado para cifrar la clave en

un archivo denominado nombre_estación_trabajo.pwd.

Nota: Verifique que el archivo nombre_estación_trabajo.pwd contiene solamente

los caracteres de la contraseña. Por ejemplo, si se ha especificado la

palabra maestro como contraseña, el archivo nombre_estación_trabajo.pwd

no debe contener ningún carácter de retorno de carro (CR) ni de salto de

línea (LF) al final (debe tener 7 bytes de longitud).

3. Escriba el comando siguiente para guardar la contraseña, codificada según

base64, dentro del archivo oculto apropiado:

$

openssl base64 -in nombre_estación_trabajo.pwd

-out nombre_estación_trabajo.sth

A continuación puede suprimir el archivo nombre_estación_trabajo.pwd.

4. Escriba el comando siguiente para crear una petición de firma de certificado

(certificate signing request, CSR):

$ openssl req -new -key nombre_estación_trabajo.key -out

nombre_estación_trabajo.csr -config ./openssl.cnf

Se solicitará al usuario que especifique algunos valores en la pantalla, tales

como el nombre de empresa, el nombre personal y otros. Para asegurar la

compatibilidad futura, puede especificar el nombre de la estación de trabajo

como nombre distinguido.

5. Envíe el archivo nombre_estación_trabajo.csr a su CA a fin de obtener el

certificado correspondiente a la clave privada.



Mediante su clave privada (TWSca.key) y certificado (TWSca.crt), la CA firmará

la CSR (nombre_estación_trabajo.csr) y creará un certificado firmado

(nombre_estación_trabajo.crt) con el comando siguiente:

$ openssl x509 -req -CA TWSca.crt -CAkey TWSca.key -days 365

-in nombre_estación_trabajo.csr

-out nombre_estación_trabajo.crt -CAcreateserial

6. Distribuya a la estación de trabajo el nuevo certificado

nombre_estación_trabajo.crt y el certificado público de la CA (TWSca.crt).

La tabla siguiente resume cuáles de los archivos creados durante el proceso se

deben definir como valores para las opciones locales de la estación de trabajo.

Tabla 36. Archivos para opciones locales

Opción local Archivo

SSL key nombre_estación_trabajo.key

SSL certificate nombre_estación_trabajo.crt

SSL key pwd nombre_estación_trabajo.sth

SSL ca certificate TWSca.crt

SSL random seed nombre_estación_trabajo.rnd

Configuración de atributos de SSL

Utilice la línea de comandos de composer o Job Scheduling Console para actualizar

la definición de estación de trabajo en la base de datos. Consulte los manuales

Tivoli Workload Scheduler - Guía de consulta o Tivoli Workload Scheduler Job Scheduling

Console - Guía del usuario para obtener más información.

Configure los atributos siguientes:

secureaddr

Define el puerto utilizado para recibir las conexiones SSL entrantes. Este

valor debe coincidir con el definido en la opción local nm SSL port de la

estación de trabajo. Debe ser diferente de la opción local nm port que

define el puerto utilizado para las comunicaciones normales. Si

securitylevel está especificado, pero falta este atributo, se utiliza 31113

como valor predeterminado.

securitylevel

Especifica el tipo de autenticación SSL para la estación de trabajo. Debe ser

uno de los valores siguientes:

enabled

La estación de trabajo utiliza la autenticación SSL sólo si su

estación de trabajo de gestor de dominio u otro agente tolerante a

errores situado por debajo de él en la jerarquía de dominios

necesita hacer uso de esa autenticación.

on La estación de trabajo utiliza la autenticación SSL cuando se

conecta a su gestor de dominio. El gestor de dominio utiliza la

autenticación SSL cuando se conecta a su gestor de dominio

primario. El agente tolerante a errores rechaza cualquier conexión

entrante procedente de su gestor de dominio si no es una conexión

SSL.

force La estación de trabajo utiliza la autenticación SSL para todas sus

conexiones y acepta conexiones procedentes de los gestores de



dominio primario y subordinado. La estación de trabajo rechazará

cualquier conexión entrante si no es conexión SSL.

Si se omite este atributo, la estación de trabajo no se configura para las

conexiones SSL. En este caso, no se tendrá en cuenta el valor especificado

para secureaddr. Debe también asignar el valor 0 a la opción local nm ssl

port para asegurarse de que este puerto no sea abierto por netman. La

tabla siguiente describe el tipo de comunicación utilizado para cada valor

de securitylevel.

Tabla 37. Tipo de comunicación de acuerdo con el valor de securitylevel.

Agente tolerante a errores

(gestor de dominio)

Gestor de dominio (gestor de

dominio primario)

Tipo de conexión

- - TCP/IP

Enabled - TCP/IP

On - Sin conexión

Force - Sin conexión

- On TCP/IP

Enabled On TCP/IP

On On SSL

Force On SSL

- Enabled TCP/IP

Enabled Enabled TCP/IP

On Enabled SSL

Force Enabled SSL

- Force Sin conexión

Enabled Force SSL

On Force SSL

Force Force SSL

El ejemplo siguiente muestra una definición de estación de trabajo que incluye los

atributos de seguridad:

cpuname ENNETI3

os WNT

node apollo

tcpaddr 30112

secureaddr 32222

for maestro

autolink off

fullstatus on

securitylevel on

end

Definición de las opciones locales de SSL

Especifique las entradas siguientes en el archivo localopts de la estación de

trabajo. Consulte el apartado “Ejemplo de archivo de opciones locales” en la

página 100 para ver estas entradas en un archivo localopts de ejemplo.

nm SSL port

Es el puerto utilizado para recibir las conexiones SSL entrantes. Este valor

debe coincidir con el definido en el atributo secureaddr en la definición de

estación de trabajo contenida en la base de datos de IBM Tivoli Workload



Scheduler. Debe ser diferente de la opción local nm port que define el

puerto utilizado para las comunicaciones normales. El valor


Notas:

1. En Windows, defina esta opción también en TWShome/localopts.

2. Si instala varias instancias de Tivoli Workload Scheduler 8.2 en la

misma máquina, asigne un valor diferente a cada puerto de SSL.

3. Si no piensa utilizar SSL, establezca el valor en 0.SSL auth mode

Define el comportamiento de Tivoli Workload Scheduler durante la fase de

reconocimiento de SSL, de acuerdo con estos valores:

caonly Tivoli Workload Scheduler comprueba la validez del certificado y


una CA reconocida. La información contenida en el certificado no

se examina. Es el valor predeterminado. Si no especifica la opción

″SSL auth mode″, o define un valor que no es válido, se utiliza el

valor ″caonly″.

string Tivoli Workload Scheduler comprueba la validez del certificado y



(Common Name, CN) del Asunto del certificado coincida con la

cadena de caracteres especificada en la opción SSL auth string.

Consulte la página 163.

cpu Tivoli Workload Scheduler comprueba la validez del certificado y



(Common Name, CN) del Tema del certificado coincida con el

nombre de la CPU que ha solicitado el servicio.SSL auth string

Se utiliza en combinación con la opción SSL auth mode cuando se

especifica el valor string. La opción SSL auth string (que comprende de 1

a 64 caracteres) se utiliza para verificar la validez del certificado. Si no se

especifica un valor para SSL auth string en combinación con SSL auth

mode, el valor predeterminado que se utiliza es tws.

SSL key

Es el nombre del archivo de clave privada. La ruta predeterminada

definida en el archivo localopts es TWShome/ssl/nombre_archivo.key.

SSL certificate

Es el nombre del archivo de certificado local. La ruta predeterminada en el

archivo localopts es TWShome/ssl/nombre_archivo.crt.

SSL key pwd

Es el nombre del archivo donde está contenida la contraseña

correspondiente a la clave secreta. La ruta predeterminada definida en el

archivo localopts es TWShome/ssl/nombre_archivo.sth.

SSL CA certificate

Es el nombre del archivo donde están contenidos los certificados de CA

fiable necesarios para la autenticación. Las CA de este archivo también se

utilizan para crear la lista de las CA de cliente aceptables que se pasan al

cliente cuando el extremo servidor de la conexión solicita un certificado de

cliente. Este archivo es la concatenación, en orden de preferencia, de los

diversos archivos de certificados de CA codificados por PEM. La ruta

predeterminada definida en el archivo localopts es

TWShome/ssl/nombre_archivo.crt.

SSL certificate chain

Es el nombre del archivo que contiene la concatenación de los certificados



codificados por PEM procedentes de autoridades de certificación y que

forman la cadena de certificados del certificado de la estación de trabajo.

Este parámetro es opcional. Si no se especifica, se utiliza el archivo

especificado para SSL CA certificate.

SSL random seed

Es el archivo de números seudoaleatorios utilizado por OpenSSL en

algunas plataformas. Sin la existencia de este archivo, la autenticación SSL

no puede funcionar debidamente. La ruta predeterminada definida en el

archivo localopts es TWShome/ssl/nombre_archivo.rnd.

SSL encryption cipher

Son los codificadores que la estación de trabajo utiliza durante una

conexión SSL. Utilice los accesos directos siguientes:

Tabla 38. Accesos directos para codificadores de cifrado

Acceso directo Codificadores de cifrado

SSLv3 SSL versión 3.0

TLSv TLS versión 1.0

EXP Exportación



LOW Baja resistencia (sin exportación, DES simple)

MEDIUM Codificadores con cifrado de 128 bits

HIGH Codificadores que utilizan Triple-DES

NULL Codificadores que no utilizan cifrado

Cómo trabajar con cortafuegos

En la fase de diseño de una red de IBM Tivoli Workload Scheduler, el

administrador debe conocer dónde están situados los cortafuegos en la red, qué

agentes tolerantes a errores y qué gestores de dominio pertenecen a un cortafuegos

determinado, y cuáles son los puntos de entrada a los cortafuegos. Una vez bien

conocidas esas cuestiones, el administrador debe definir el atributo behindfirewall

para algunas de las definiciones de estación de trabajo contenidas en la base de

datos de Tivoli Workload Scheduler. En particular, si una definición de estación de

trabajo tiene el atributo behindfirewall establecido en ON, esto significa que existe

un cortafuegos entre la estación de trabajo y el maestro de Tivoli Workload

Scheduler. En este caso, el vínculo estación de trabajo-gestor de dominio es el

único vínculo permitido entre la estación de trabajo y su gestor de dominio.

Todas las estaciones de trabajo de Tivoli Workload Scheduler deben tener definido

el atributo behindfirewall si el vínculo con el gestor de dominio correspondiente,

o con cualquier gestor de dominio de la jerarquía de Tivoli Workload Scheduler

hasta llegar al maestro, está situado detrás de un cortafuegos.

Todas las estaciones de trabajo de Tivoli Workload Scheduler deben tener definido

el atributo behindfirewall si el vínculo de la estación de trabajo con el gestor de

dominio correspondiente, o con cualquier gestor de dominio de la jerarquía de

Tivoli Workload Scheduler hasta llegar al maestro, está situado detrás de un

cortafuegos.

Cuando se diseña una red de IBM Tivoli Workload Scheduler sobre una estructura

existente de cortafuegos, no importa qué agentes tolerantes a errores y qué gestores



de dominio están en el lado seguro del cortafuegos y cuáles están en el lado no

seguro. La única preocupación debe ser los límites del cortafuegos. Por ejemplo, es

irrelevante si el maestro está en una zona no segura y algunos de los gestores de

dominio están en zonas seguras, o viceversa. La estructura de cortafuegos se debe

considerar siempre comenzando en el maestro y siguiendo por la jerarquía de IBM

Tivoli Workload Scheduler, marcando todas las estaciones de trabajo que tengan un

cortafuegos entre ellas y su correspondiente gestor de dominio.

Para todas las estaciones de trabajo que tengan behindfirewall establecido en ON,

los comandos start wkstation, stop wkstation y showjobs se envían siguiendo la

jerarquía de dominios, en lugar de hacer que el maestro o gestor de dominio

establezca una conexión directa con la estación de trabajo. Esto supone una mejora

significativa en la seguridad.

Este atributo actúa también para varios cortafuegos anidados. Para los agentes

ampliados, puede especificar la existencia de una CPU de agente ampliado detrás

de un cortafuegos asignando el valor ON al atributo behindfirewall, en la estación

de trabajo host. El atributo es de sólo lectura en el plan; para cambiar el atributo

en el plan, el administrador debe actualizarlo en la base de datos y luego volver a

crear el plan.

Consulte el manual Tivoli Workload Scheduler - Guía de consulta para obtener detalles

sobre cómo definir este atributo.



Capítulo 12. Desinstalación de Tivoli Workload Scheduler

La desinstalación se crea durante el procedimiento de instalación. Por consiguiente,

utilice el mismo método que ha elegido para instalar el producto al desinstalar

dicho producto. Por ejemplo, si ha instalado el producto utilizando el asistente de

instalación, utilice el asistente de desinstalación para la eliminación subsiguiente

del producto.

La desinstalación del producto no elimina los archivos que se crearon después de

instalar Tivoli Workload Scheduler, ni los archivos que estén abiertos al realizar la

desinstalación. Si no necesita dichos archivos, tendrá que eliminarlos manualmente.

Consulte el manual Tivoli Workload Scheduler Administration and Troubleshooting para

obtener información sobre la eliminación manual de Tivoli Workload Scheduler.

Utilización del asistente de desinstalación

El asistente de desinstalación elimina archivos del producto, claves del registro y

servicios. Elimina los archivos binarios asociados al agente de Tivoli Workload

Scheduler instalado y a los paquetes de idioma.

El programa de desinstalación no elimina el conector de Tivoli Workload

Scheduler, Tivoli Plus Module ni Tivoli Management Framework. Consulte el

manual Tivoli Workload Scheduler Job Scheduling Console - Guía del usuario para

desinstalar el conector, el manual Tivoli Workload Scheduler - Guía del usuario del

módulo Plus para desinstalar Tivoli Plus Module y el manual Tivoli Enterprise

Installation Guide para desinstalar Tivoli Management Framework.

Para desinstalar Tivoli Workload Scheduler, siga estos pasos:

1. Asegúrese de que todos los procesos y servicios de Tivoli Workload Scheduler

se detengan y que no haya trabajos activos o pendientes. Consulte el apartado

“Desvinculación y detención de Tivoli Workload Scheduler” en la página 32.

2. Localice el directorio _uninst en la ruta de instalación de TWShome.

3. Ejecute el programa de desinstalación.

v Windows: uninstaller.exe

v UNIX: uninstaller.bin

4. Se inicia el asistente de instalación. Seleccione el idioma del asistente de

desinstalación. Haga clic en Aceptar.


6. Revise la información del proceso de desinstalación. Haga clic en Siguiente.

7. Haga clic en Finalizar para cerrar el programa de desinstalación.

Utilización del script twsinst

Consulte el manual Tivoli Workload Scheduler Troubleshooting and Error Messages para

obtener información sobre la desinstalación manual de Tivoli Workload Scheduler.

Siga estos pasos para desinstalar Tivoli Workload Scheduler utilizando el script

twsinst.

1. Antes de desinstalar, detenga todos los procesos de Tivoli Workload Scheduler

que se crearon en el sistema. Si hay trabajos que están en ejecución


actualmente, los procesos asociados se deben detener manualmente. Para

obtener información sobre la detención de los procesos y servicios, consulte el

apartado “Desvinculación y detención de Tivoli Workload Scheduler” en la

página 32.

2. Vaya al directorio de instalación.

3. Ejecute el script twsinst de la manera siguiente:

twsinst -uninst -uname <nombre_usuario>

[-lang <id_idioma>]

-uninst

Desinstala Tivoli Workload Scheduler, Versión 8.2. Antes de realizar una

desinstalación, asegúrese de que todos los procesos y servicios de Tivoli

Workload Scheduler estén detenidos. Para obtener información sobre la



-uname <nombre_usuario>

Es el nombre del usuario para el cual se instala, actualiza, promueve o

desinstala Tivoli Workload Scheduler. El software se instala o se actualiza en

este directorio inicial del usuario. Este nombre de usuario es distinto del

usuario que realiza la instalación y que ha iniciado una sesión como root. Para

una instalación nueva, esta cuenta de usuario se debe crear manualmente antes

de ejecutar la instalación. Cree un usuario con un directorio inicial. Tivoli

Workload Scheduler se instalará en el directorio inicial (HOME) del usuario

especificado.

-lang <id_idioma>

El idioma en el que se visualizan los mensajes de twsinst. Si no se especifica

un valor, se utiliza el idioma del sistema (LANG). Si falta el catálogo asociado,

se utiliza el catálogo de idioma predeterminado C.


soportados de Tivoli Workload Scheduler. Por omisión, todos los

paquetes de idioma soportados se instalan cuando el producto se instala

utilizando el script twsinst.

A continuación se muestra un script twsinst de ejemplo que sirve para desinstalar

el motor de Tivoli Workload Scheduler, Versión 8.2, instalado originalmente para el

usuario denominado twsuser:

./twsinst -uninst -uname twsuser

Utilización de la CLI de Software Distribution

Para desinstalar el producto, utilice el mismo método que ha elegido para

instalarlo. Puede desinstalar Tivoli Workload Scheduler utilizando el comando

wremovsp de Software Distribution, de esta manera:

wremovsp Tivoli_TWS_WINDOWS.spb [suscriptores...]

Este método también se puede utilizar para desinstalar el bloque de paquetes de

software que sirve para instalar los paquetes de idioma. Consulte el manual Tivoli

Workload Scheduler Troubleshooting and Error Messages para obtener información

sobre la desinstalación manual de Tivoli Workload Scheduler.

Utilización del script customize

Siga estos pasos para desinstalar Tivoli Workload Scheduler en una plataforma de

Nivel 2:

Desinstalación


1. Antes de desinstalar, detenga todos los procesos de Tivoli Workload Scheduler

que se crearon en el sistema. Consulte el apartado “Desvinculación y detención

de Tivoli Workload Scheduler” en la página 32.

2. Inicie la sesión en el sistema como root.

3. Revise el contenido del archivo denominado /usr/unison/components. Si el

archivo contiene varias entradas que corresponden a cuentas Maestro/Tivoli

Workload Scheduler (grupos de productos) diferentes, edite el archivo

suprimiendo las líneas correspondientes a las instancias que desea eliminar.

Por ejemplo, suponga que /usr/unison/components contiene las entradas

siguientes:

maestro 7.0 /opt/maestro DEFAULT

maestro 8.2 /data/maestro8/maestro TWS_maestro8_8.2

Si piensa eliminar la instancia de Tivoli Workload Scheduler situada en

/opt/maestro, suprima la primera línea. Si /usr/unison/components contiene sólo la

instancia que desea eliminar, suprima el archivo completo.

4. Elimine los vínculos, si corresponde, establecidos con el directorio /usr/bin. El

proceso de instalación le proporciona la opción de vincular ejecutables de Tivoli

Workload Scheduler con un directorio común. El valor predeterminado es

/usr/bin. Elimine los archivos siguientes:

v /usr/bin/maestro

v /usr/bin/mat

v /usr/bin/mbatch

v /usr/bin/datecalc

v /usr/bin/morestdl

v /usr/bin/jobstdl

v /usr/bin/parms5. Finalmente, elimine la cuenta Maestro/Tivoli Workload Scheduler completa

utilizando este comando:

rm -rf <twshome>

Si se ha modificado el comando de arranque del sistema para que incluya un

comando conman ″start″ o <twshome>/StartUp, debe también eliminar esas

entradas.

Desinstalación

Capítulo 12. Desinstalación de Tivoli Workload Scheduler 169

Apéndice. Información de soporte

Esta sección describe las opciones siguientes para obtener soporte para productos

de IBM:

v “Búsqueda en bases de conocimiento”

v “Obtención de arreglos” en la página 172

v “Cómo ponerse en contacto con IBM Software Support” en la página 172

Búsqueda en bases de conocimiento

Si tiene algún problema con el software de IBM, deseará resolverlo con rapidez.

Empiece por buscar las bases de conocimiento disponibles para determinar si la

solución a su problema ya se ha documentado.

Búsqueda en el centro de información en el sistema local o

en la red

IBM proporciona una extensa documentación sobre el producto que puede

instalarse en el sistema local o en un servidor de Intranet. La documentación se

suministra en los CD de publicaciones disponibles con el producto, puede bajarse

de IBM tal y como se describe en el apartado “Acceso a las publicaciones en línea”

en la página xvi o puede solicitarse a IBM una copia impresa tal y como se

describe en el apartado “Solicitud de publicaciones” en la página xvi.

Abra las versiones PDF de los documentos y utilice los recursos de búsqueda

incorporados de Adobe Reader para buscar la información necesaria.

Búsqueda en el centro de información en el sitio Web de

soporte de IBM

El sitio Web de soporte de software de IBM tiene numerosos documentos

disponibles en línea, de los cuales uno o más pueden proporcionarle la

información que requiere:

1. Diríjase al sitio Web de IBM Software Support

(http://www.ibm.com/software/support).

2. Bajo Products A - Z, seleccione el nombre del producto: seleccione ″I″ para IBM

y, a continuación, desplácese hacia abajo hasta las entradas de productos que

empiezan por ″IBM Tivoli Workload Scheduler″. Estas entradas abren sitios de

soporte específicos de producto.

3. Bajo Self help y Learn, elija en la lista los distintos tipos de documentación de

soporte del producto:

v Manuales

v Redbooks

v Libros blancos

v Archivos readme y otra documentación

Para acceder a algunos documentos es necesario registrarse (se indica mediante un

icono de llave junto al título del documento). Para registrarse, seleccione el

documento que desea ver y, cuando se le solicite que inicie la sesión, siga los

vínculos para registrarse usted mismo. También están disponibles las FAQ sobre

las ventajas de registrarse.


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

Búsqueda en Internet

Si no encuentra una respuesta a su pregunta en el centro de información, busque

en Internet para obtener otra información que pueda ayudarle a resolver el

problema.

Obtención de arreglos

Es posible que exista un arreglo del producto para resolver el problema. Puede

determinar los arreglos que están disponibles para el producto de software de IBM

consultando el sitio Web de soporte para el producto:

1. Diríjase al sitio Web de IBM Software Support

(http://www.ibm.com/software/support).

2. Bajo Products A - Z, seleccione el nombre del producto: seleccione ″I″ para IBM

y, a continuación, desplácese hacia abajo hasta las entradas de productos que

empiezan por ″IBM Tivoli Workload Scheduler″. Estas entradas abren sitios de

soporte específicos de producto.

3. Bajo Self help, siga el vínculo hasta Search all Downloads, donde encontrará

una lista de arreglos, de fix packs y otras actualizaciones de servicio del

producto.

4. Haga clic en el nombre de un arreglo para leer la descripción y, opcionalmente,

bajarlo.

Para recibir notificaciones semanales por correo electrónico sobre los arreglos y

otras noticias sobre los productos de IBM, siga estos pasos:

1. Desde la página de soporte a cualquier producto de IBM, haga clic sobre My

support en el panel en la izquierda de la página.

2. Si ya se ha registrado, podrá pasar al paso siguiente. Si todavía no se ha

registrado, haga clic en registrar en el ángulo superior derecho de la página de

soporte para establecer el ID de usuario y la contraseña.

3. Inicie la sesión en My support.

4. En la página My support, seleccione la pestaña Edit profile y haga clic sobre

Subscribe to email. Seleccione una familia de productos y compruebe los

cuadros apropiados para el tipo de información que requiere.

5. Haga clic en Update.

6. Para recibir notificaciones por correo electrónico sobre otros productos, repita

los pasos 4 y 5.

Para obtener más información acerca de los tipos de arreglos, consulte el manual

Software Support Handbook

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

Cómo ponerse en contacto con IBM Software Support

IBM Software Support proporciona asistencia si surgen defectos en los productos.

Antes de contactar con IBM Software Support, la empresa debe tener un contrato

de mantenimiento de software de IBM activo y el usuario debe disponer de

autorización para presentar problemas a IBM. El tipo de contrato de

mantenimiento de software que necesite dependerá del tipo de producto que

tenga:

v Para productos de software distribuidos por IBM (incluidos, pero sin limitarse a

ellos, los productos Tivoli, Lotus, y Rational, además de los productos DB2 y

WebSphere que se ejecutan en sistemas operativos Windows o UNIX), regístrese

en Passport Advantage de una de las maneras siguientes:

Soporte


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

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

– En línea: diríjase a la página Web de Passport Advantage

(http://www.lotus.com/services/passport.nsf/WebDocs/

Passport_Advantage_Home) y haga clic en How to Enroll

– Por teléfono: para obtener el número de teléfono al que debe llamar en su

país, diríjase al sitio Web de IBM Software Support

(http://techsupport.services.ibm.com/guides/contacts.html) y haga clic sobre

el nombre de su zona geográfica.v Para productos de software eServer de IBM (incluidos, pero sin limitarse a ellos,

los productos DB2 y WebSphere que se ejecutan en entornos zSeries, pSeries e

iSeries), puede contratar un acuerdo de mantenimiento de software directamente

a través de un representante de ventas de IBM o mediante un asociado

comercial de IBM. Para obtener más información sobre soporte para productos

de software de eServer, diríjase a la página Web de IBM Technical Support

Advantage Web (http://www.ibm.com/servers/eserver/techsupport.html).

Si no está seguro del tipo de contrato de mantenimiento de software que necesita,

llame al número 1-800-IBMSERV (1-800-426-7378) en Estados Unidos o, desde otros

países, diríjase a la página de contactos de IBM Software Support Handbook en la

Web (http://techsupport.services.ibm.com/guides/contacts.html) y haga clic sobre

el nombre de su zona geográfica para obtener los números de teléfono de las

personas que proporcionan soporte en su localidad.

Siga los pasos descritos en este apartado para ponerse en contacto con IBM

Software Support:

1. Determinación del impacto comercial del problema.

2. Descripción del problema y recopilación de la información básica.

3. Envío del problema a IBM Software Support.

Determinación del impacto comercial del problema

Cuando notifique un problema a IBM, se le pedirá que indique el nivel de

gravedad. Por ello, debe comprender y valorar el impacto comercial del problema

que está notificando. Utilice los criterios siguientes:

Gravedad 1 Impacto comercial crítico: no se puede utilizar el programa, por

lo que se produce un impacto crítico en las operaciones. Esta

condición requiere una solución inmediata.

Gravedad 2 Impacto comercial importante: el programa se puede utilizar pero

está severamente limitado.

Gravedad 3 Impacto comercial moderado: el programa se puede utilizar pero

las funciones menos importantes no están disponibles (no críticas

para las operaciones).

Gravedad 4 Impacto comercial mínimo: el problema causa un impacto leve en

las operaciones o se ha implementado una solución alternativa

para el mismo.

Descripción del problema y recopilación de la información

básica

Cuando notifique un problema a IBM, sea tan concreto como sea posible. Incluya

toda la información básica relevante para que los especialistas de IBM Software

Support puedan ayudarle a solucionar el problema de modo eficaz. Para ahorrar

tiempo, prepare las respuestas a estas preguntas:

Contactar con el servicio de soporte

Apéndice. Información de soporte 173

http://www.lotus.com/services/passport.nsf/WebDocs/Passport_Advantage_Home

http://www.lotus.com/services/passport.nsf/WebDocs/Passport_Advantage_Home

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

http://www.ibm.com/servers/eserver/techsupport.html


v ¿Qué versiones de software se estaban ejecutando cuando se produjo el

problema?

v ¿Dispone de registros, rastreos y mensajes relacionados con los síntomas del

problema? Es muy probable que IBM Software Support le pida esta información.

v ¿Puede reproducir el problema? En caso afirmativo, ¿qué pasos condujeron a la

anomalía?

v ¿Se ha realizado algún cambio en el sistema? (por ejemplo, en el hardware, en el

sistema operativo, en el software de redes, etc.)

v ¿Actualmente está utilizando una solución provisional para este problema? En

caso afirmativo, debe estar preparado para explicarlo cuando notifique el

problema.

Envío del problema a IBM Software Support

Puede enviar el problema de una de las dos maneras siguientes:

v En línea: Vaya a la página ″Submit and track problems″ del sitio de IBM

Software Support (http://www.ibm.com/software/support/probsub.html).

Introduzca la información en la herramienta de envío de problemas adecuada.

v Por teléfono: Para saber el número de teléfono de su país, vaya a la página de

contactos de IBM Software Support Handbook en la Web

(http://techsupport.services.ibm.com/guides/contacts.html) y haga clic sobre el

nombre de su zona geográfica.

Si el problema que envía se debe a un defecto de software, a la falta de

documentación o a que ésta no es lo suficientemente precisa, IBM Software

Support creará un APAR (Authorized Program Analysis Report, Informe de

análisis de programa autorizado). El APAR describe el problema de forma

detallada. Siempre que sea posible, IBM Software Support le proporcionará una

solución provisional para que la implemente mientras se resuelve el APAR y se

suministra un arreglo. IBM publica diariamente los APAR resueltos en las páginas

Web de IBM product support, para que los otros usuarios que tengan el mismo

problema puedan beneficiarse de las mismas soluciones.

Para obtener más información sobre la solución del problema, consulte el apartado

Búsqueda en bases de conocimiento y Obtención de arreglos.

Contactar con el servicio de soporte


http://www.ibm.com/software/support/probsub.html


Avisos

Esta información se ha elaborado para productos y servicios ofrecidos en Estados

Unidos. Puede que IBM no ofrezca en otros países los productos y servicios

tratados en este documento. Consulte al representante local de IBM para obtener

información sobre los productos y servicios que actualmente pueden adquirirse en

su zona geográfica. Las referencias hechas a un producto, programa o servicio de

IBM no pretenden afirmar ni implicar que sólo pueda utilizarse este producto,

programa o servicio de IBM. En su lugar se puede utilizar cualquier producto,

programa o servicio funcionalmente equivalente que no vulnere ningún derecho de

propiedad intelectual de IBM. Sin embargo, es responsabilidad del usuario evaluar

y verificar el funcionamiento de cualquier producto, programa o servicio que no

sea de IBM.

IBM puede tener patentes o solicitudes de patentes en tramitación que afecten al

tema tratado en este documento. La posesión de este documento no le otorga

ninguna licencia sobre dichas patentes. Puede enviar consultas sobre licencias, por

escrito, a:

IBM Director of Licensing

IBM Corporation

North Castle Drive

Armonk, NY 10504-1785 EE.UU.

Para consultas sobre licencias acerca de información de doble byte (DBCS),

consulte al Departamento de Propiedad Intelectual de IBM de su país o envíe las

consultas, por escrito, a:

IBM World Trade Asia Corporation

Licensing

2-31 Roppongi 3-chome, Minato-ku

Tokio 106, Japón

El párrafo siguiente no es aplicable al Reino Unido ni a ningún otro país donde

tales disposiciones sean incompatibles con la legislación local:

INTERNATIONAL BUSINESS MACHINES CORPORATION PROPORCIONA

ESTA PUBLICACIÓN ″TAL CUAL″, SIN GARANTÍAS DE NINGÚN TIPO, NI

EXPLÍCITAS NI IMPLÍCITAS, INCLUIDAS, PERO SIN LIMITARSE A ELLAS, LAS

GARANTÍAS IMPLÍCITAS DE NO VULNERACIÓN DE DERECHOS,

COMERCIABILIDAD O IDONEIDAD PARA UN FIN DETERMINADO.

Algunos estados no autorizan la exclusión de garantías explícitas o implícitas en

determinadas transacciones, por lo que es posible que esta declaración no sea

aplicable en su caso.

Esta información puede contener imprecisiones técnicas o errores tipográficos.

Periódicamente se efectúan cambios en la información aquí contenida; estos

cambios se incorporarán en nuevas ediciones de la publicación. IBM puede

efectuar mejoras y/o cambios en el producto o productos y/o en el programa o

programas que se describen en esta publicación en cualquier momento y sin previo

aviso.


Cualquier referencia en esta publicación a sitios Web que no sean de IBM se facilita

con fines puramente informativos y en ningún caso pueden interpretarse como un

aval de dichos sitios Web. La información contenida en esos sitios Web no forma

parte de la información para el presente producto de IBM y el usuario es

responsable de la utilización de esos sitios Web.

IBM puede utilizar o distribuir cualquier información que le proporcione del modo

en que IBM crea apropiado, sin contraer ninguna obligación con el remitente de la

información.

Los licenciatarios de este programa que deseen obtener información sobre él con el

fin de habilitar: (i) el intercambio de información entre programas creados

independientemente y otros programas (incluido éste) y (ii) la utilización mutua de

la información que se ha intercambiado, deben ponerse en contacto con:

IBM Corporation

2Z4A/101

11400 Burnet Road

Austin, TX 78758 EE.UU.

Esta información puede estar disponible, conforme a los términos y condiciones

apropiados, incluido en algunos casos, el pago de una tarifa.

IBM proporciona el programa bajo licencia descrito en este manual y todo el

material bajo licencia asociado a él según los términos del Contrato del Cliente de

IBM o el Contrato Internacional para Programas bajo Licencia o cualquier acuerdo

equivalente entre las partes.

La información relativa a los productos que no son de IBM se ha obtenido de los

proveedores de los mismos, de sus anuncios publicados o de otras fuentes

disponibles públicamente. IBM no ha probado dichos productos y no puede

confirmar con precisión el rendimiento, la compatibilidad ni ninguna otra

reclamación en relación con los productos que no son de IBM. Las preguntas sobre

las posibilidades de los productos que no son de IBM deben dirigirse a los

proveedores de los mismos.

Esta información puede contener ejemplos de datos e informes utilizados en

operaciones comerciales diarias. Para ilustrarlos de la forma más completa posible,

los ejemplos incluyen nombre de personas, empresas, marcas y productos. Todos

estos nombres son ficticios y cualquier parecido con los nombres y las direcciones

de una empresa comercial real es completamente casual.

Open source: test

Copyright (c) 1992, 1993, 1994

The Regents of the University of California. Reservados todos los derechos.

Este código procede de software aportado a Berkeley por Kenneth Almquist.

Están permitidas la redistribución y utilización en formato fuente y binario, con o

sin modificación, siempre que se cumplan las condiciones siguientes:

1. Las redistribuciones de código fuente deben incluir la nota de copyright

indicada anteriormente, la presente lista de condiciones y la declaración de

renuncia mostrada más abajo.


2. Las redistribuciones en formato binario deben incluir, junto con la

documentación y/o otros materiales proporcionados con la distribución, la nota

de copyright mostrada anteriormente, la presente lista de condiciones y la

declaración de renuncia mostrada más abajo.

3. Todos los materiales de propaganda que mencionen funciones o el uso de este

software deben mostrar el reconocimiento de titularidad siguiente:

Este producto incluye software desarrollado por la Universidad de California

en Berkeley, y por sus colaboradores.

4. No se puede utilizar el nombre de la Universidad ni los nombres de sus

colaboradores para avalar o promocionar productos derivados de este software

sin permiso previo específico por escrito.

LOS REGENTES Y COLABORADORES PROPORCIONAN ESTE SOFTWARE ″TAL

CUAL″, SIN GARANTÍAS EXPRESAS NI IMPLÍCITAS DE NINGUNA CLASE,

INCLUIDAS, PERO SIN LIMITARSE A ELLAS, LAS GARANTÍAS IMPLÍCITAS DE

COMERCIABILIDAD Y ADECUACIÓN PARA UN FIN DETERMINADO. EN

NINGÚN CASO, LOS REGENTES Y COLABORADORES SERÁN RESPONSABLES

POR DAÑOS DIRECTOS, INDIRECTOS, INCIDENTALES, ESPECIALES,

EJEMPLARES NI CONSECUENTES (INCLUIDO, PERO SIN LIMITARSE A ELLO,

EL SUMINISTRO DE BIENES O SERVICIOS SUSTITUTOS; LA PÉRDIDA DE USO,

DATOS O BENEFICIOS; O LA INTERRUPCIÓN DEL NEGOCIO) CUALQUIERA

QUE SEA LA CAUSA Y DE ACUERDO CON CUALQUIER BASE JURÍDICA DE

RESPONSABILIDAD, YA SEA POR CONTRATO, RESPONSABILIDAD ESTRICTA

O DAÑO LEGAL (CON O SIN NEGLIGENCIA) QUE RESULTEN DE LA

UTILIZACIÓN DE ESTE SOFTWARE, INCLUSO SI SE ADVIERTE DE LA

POSIBILIDAD DE TAL DAÑO.

Open source: OpenSSL

Este producto incluye software desarrollado por OpenSSL Project para su

utilización en OpenSSL Toolkit. (http://www.openssl.org/)

ASPECTOS DE LA LICENCIA

OpenSSL Toolkit está sujeto a una licencia doble; es decir, se aplican al Toolkit las

condiciones de la licencia de OpenSSL y de la licencia original de SSLeay. A

continuación se muestran los textos de las licencias. En realidad, ambas licencias

son licencias de BSD-styleOpen Source. Si desea información sobre algún aspecto

de las licencias relacionado con OpenSSL, póngase en contacto con

[email protected].

Licencia de OpenSSL

Copyright (c) 1998-2001 The OpenSSL Project. Reservados todos los derechos.



1. Las redistribuciones de código fuente deben incluir la nota de copyright

indicada anteriormente, la presente lista de condiciones y la declaración de

renuncia mostrada más abajo.





Avisos 177

3. Todo el material publicitario que mencione características o el uso de este

software debe incluir este reconocimiento de titularidad: ″Este producto

contiene software desarrollado por The OpenSSL Project para su utilización en

el OpenSSL Toolkit. (http://www.openssl.org/)″.

4. Los nombres ″OpenSSL Toolkit″ y ″OpenSSL Project″ no deben utilizarse sin

previo consentimiento escrito para avalar ni promocionar productos derivados

de este software. Para obtener permiso escrito, póngase en contacto con

[email protected].

5. Los productos derivados de este software no se pueden denominar ″OpenSSL″

ni puede aparecer ″OpenSSL″ en sus nombres sin previo consentimiento escrito

de The OpenSSL Project.

6. Las redistribuciones, hechas en la forma que sea, deben incluir este

reconocimiento de titularidad: ″Este producto contiene software desarrollado

por The OpenSSL Project para su utilización en el OpenSSL Toolkit

(http://www.openssl.org/)″.

The OpenSSL Project PROPORCIONA ESTE SOFTWARE ″TAL CUAL″, SIN

GARANTÍAS EXPRESAS NI IMPLÍCITAS DE NINGUNA CLASE, INCLUIDAS,

PERO SIN LIMITARSE A ELLAS, LAS GARANTÍAS IMPLÍCITAS DE

COMERCIABILIDAD Y ADECUACIÓN PARA UN FIN DETERMINADO. EN

NINGÚN CASO The OpenSSL Project NI SUS COLABORADORES SERÁN

RESPONSABLES POR DAÑOS DIRECTOS, INDIRECTOS, INCIDENTALES,

ESPECIALES, EJEMPLARES NI CONSECUENTES (INCLUIDO, PERO SIN

LIMITARSE A ELLO, EL SUMINISTRO DE BIENES O SERVICIOS SUSTITUTOS;

LA PÉRDIDA DE USO, DATOS O BENEFICIOS; O LA INTERRUPCIÓN DEL

NEGOCIO) CUALQUIERA QUE SEA LA CAUSA Y DE ACUERDO CON

CUALQUIER BASE JURÍDICA DE RESPONSABILIDAD, YA SEA POR

CONTRATO, RESPONSABILIDAD ESTRICTA O DAÑO LEGAL (CON O SIN

NEGLIGENCIA) QUE RESULTEN DE LA UTILIZACIÓN DE ESTE SOFTWARE,

INCLUSO SI SE ADVIERTE DE LA POSIBILIDAD DE TAL DAÑO.

Este producto incluye software criptográfico escrito por Eric Young

([email protected]). Este producto incluye software escrito por Tim Hudson

([email protected]).

Licencia original de SSLeay

Copyright (C) 1995-1998 Eric Young ([email protected]) Reservados todos los

derechos.

Este paquete de software es una implementación para SSL escrita por Eric Young

([email protected]). Esta implementación se ha escrito en conformidad con el

estándar SSL de Netscape.

Esta biblioteca de software puede utilizarse gratuitamente con fines comerciales y

no comerciales, siempre que se cumplan las condiciones siguientes. Las condiciones

siguientes son aplicables a todo el código de programación incluido en esta

distribución, ya sea código RC4, RSA, lhash, DES, etc., no sólo el código de SSL. La

documentación de SSL incluida en esta distribución está sujeta a las mismas

condiciones de copyright, salvo que el titular de los derechos de autor es Tim

Hudson ([email protected]).

El propietario de los derechos de autor sigue siendo Eric Young, y por ello no debe

suprimirse ninguna nota de copyright incluida en el código. Si este paquete de

software se utiliza en un producto, se debe reconocer la autoría de Eric Young para

las partes utilizadas de la biblioteca de software. Este reconocimiento de titularidad


puede hacerse en forma de mensaje de texto en el arranque del programa o en la

documentación (legible por máquina o impresa) que se proporciona con el paquete

de software.



1. Las redistribuciones de código fuente deben incluir la nota de copyright, la

presente lista de condiciones y la declaración de renuncia mostrada más abajo.





3. Todo el material publicitario que mencione características o el uso de este

software debe incluir este reconocimiento de titularidad: ″Este producto

contiene software criptográfico escrito por Eric Young ([email protected])″. La

palabra ″criptográfico″ se puede omitir si las rutinas de la biblioteca que se está

utilizando no están relacionadas con la criptografía.

4. Si incluye cualquier código específico de Windows (o un derivado de él)

procedente del directorio apps (código de aplicación), debe incluir este

reconocimiento de titularidad: ″Este producto incluye software escrito por Tim

Hudson ([email protected])″

ERIC YOUNG PROPORCIONA ESTE SOFTWARE ″TAL CUAL″, SIN GARANTÍAS

EXPRESAS NI IMPLÍCITAS DE NINGUNA CLASE, INCLUIDAS, PERO SIN

LIMITARSE A ELLAS, LAS GARANTÍAS IMPLÍCITAS DE COMERCIABILIDAD Y

ADECUACIÓN PARA UN FIN DETERMINADO. EN NINGÚN CASO EL AUTOR

NI LOS COLABORADORES SERÁN RESPONSABLES POR DAÑOS DIRECTOS,

INDIRECTOS, INCIDENTALES, ESPECIALES, EJEMPLARES NI CONSECUENTES

(INCLUIDO, PERO SIN LIMITARSE A ELLO, EL SUMINISTRO DE BIENES O

SERVICIOS SUSTITUTOS; LA PÉRDIDA DE USO, DATOS O BENEFICIOS; O LA

INTERRUPCIÓN DEL NEGOCIO) CUALQUIERA QUE SEA LA CAUSA Y DE

ACUERDO CON CUALQUIER BASE JURÍDICA DE RESPONSABILIDAD, YA SEA

POR CONTRATO, RESPONSABILIDAD ESTRICTA O DAÑO LEGAL (CON O SIN

NEGLIGENCIA) QUE RESULTEN DE LA UTILIZACIÓN DE ESTE SOFTWARE,

INCLUSO SI SE ADVIERTE DE LA POSIBILIDAD DE TAL DAÑO.

Las condiciones de licencia y distribución de cualquier versión disponible

públicamente o derivada de este código no se pueden cambiar. Es decir, no se debe

copiar el código y aplicarle otra licencia de distribución (incluida la licencia pública

GNU].

Open source: biblioteca de SNMP

Copyright 1988, 1989 de Carnegie Mellon University.

Reservados todos los derechos.

Por la presente se otorga permiso para utilizar, copiar, modificar y distribuir este

software y su documentación para cualquier finalidad y de forma gratuita, siempre

que la nota de copyright anterior aparezca en todas las copias y que tanto la nota

de copyright como esta nota de permiso aparezcan en la documentación de

soporte, y que el nombre de CMU no se utilice en publicidad ni propaganda

relativa a la distribución del software sin previo permiso específico por escrito.

Avisos 179

CMU DENIEGA TODAS LAS GARANTÍAS RESPECTO A ESTE SOFTWARE,

INCLUIDAS TODAS LAS GARANTÍAS IMPLÍCITAS DE COMERCIABILIDAD Y

ADECUACIÓN. EN NINGÚN CASO SERA CMU RESPONSABLE DE LOS

POSIBLES DAÑOS ESPECIALES, INDIRECTOS O CONSIGUIENTES, NI DE LOS

POSIBLES DAÑOS RESULTANTES DE LA PÉRDIDA DE USO, DATOS O

BENEFICIOS, YA SEAN EN UNA ACCIÓN DE CONTRATO, NEGLIGENCIA U

OTRO TIPO DE ACCIÓN AGRAVANTE, RESULTANTE DE O RELACIONADA

CON EL USO O RENDIMIENTO DE ESTE SOFTWARE.

Open source: biblioteca de husos horarios

Copyright (c) 1985, 1987, 1988 The Regents of the University of California.


Están permitidos la redistribución y el uso en formatos fuente y binario siempre

que la nota de copyright anterior y este párrafo se copien en todos esos formatos y

que la documentación, los materiales de propaganda y otros materiales

relacionados con esta distribución y uso reconozcan que el software ha sido

desarrollado por la Universidad de California en Berkeley. No se puede utilizar el

nombre de la Universidad para avalar o promocionar productos derivados de este

software sin permiso previo específico por escrito. ESTE SOFTWARE SE

PROPORCIONA ″TAL CUAL″, SIN GARANTÍAS EXPRESAS NI IMPLÍCITAS DE

NINGUNA CLASE, INCLUIDAS, PERO SIN LIMITARSE A ELLAS, LAS

GARANTÍAS IMPLÍCITAS DE COMERCIABILIDAD Y ADECUACIÓN PARA UN

FIN DETERMINADO.

Kit de herramientas de Tivoli Internationalization Services

Este paquete contiene software abierto de Alfalfa Software. El uso de este software

abierto en productos de IBM ha sido aprobado por IBM OSSC, pero se deben

incluir las notas de copyright y permiso de Alfalfa Software en la documentación

de soporte del producto. Esto podría hacerse en un archivo readme proporcionado

con el producto. Este es el texto de las notas de copyright y permiso:

Copyright 1990, de Alfalfa Software Incorporated, Cambridge, Massachusetts.


Por la presente se otorga permiso para utilizar, copiar, modificar y distribuir este

software y su documentación para cualquier finalidad y de forma gratuita, siempre

que la nota de copyright anterior aparezca en todas las copias y que tanto la nota

de copyright como esta nota de permiso aparezcan en la documentación de

soporte, y que el nombre de Alfalfa no se utilice en publicidad ni propaganda

relativa a la distribución del software sin previo permiso específico por escrito.

ALPHALPHA DENIEGA TODAS LAS GARANTÍAS RESPECTO A ESTE

SOFTWARE, INCLUIDAS TODAS LAS GARANTÍAS IMPLÍCITAS DE

COMERCIABILIDAD Y ADECUACIÓN. EN NINGÚN CASO SERA ALPHALPHA

RESPONSABLE DE LOS POSIBLES DAÑOS ESPECIALES, INDIRECTOS O

CONSIGUIENTES, NI DE LOS POSIBLES DAÑOS RESULTANTES DE LA

PÉRDIDA DE USO, DATOS O BENEFICIOS, YA SEAN EN UNA ACCIÓN DE

CONTRATO, NEGLIGENCIA U OTRO TIPO DE ACCIÓN AGRAVANTE,

RESULTANTE DE O RELACIONADA CON EL USO O RENDIMIENTO DE ESTE

SOFTWARE.


Marcas registradas

IBM, Tivoli, el logotipo de Tivoli, Tivoli Enterprise Console, AIX, AS/400,

BookManager, Dynix, OS/390, NetView y Sequent son marcas registradas o marcas

comerciales de International Business Machines Corporation o Tivoli Systems Inc.

en Estados Unidos o en otros países.

Intel es una marca registrada de Intel Corporation.

Microsoft, Windows y Windows NT son marcas registradas de Microsoft

Corporation en Estados Unidos o en otros países.

UNIX es una marca registrada de The Open Group en Estados Unidos y otros

países.

Java y todas las marcas registradas y logotipos basados en Java son marcas

comerciales o marcas registradas de Sun Microsystems, Inc. en Estados Unidos y

otros países.

Otros nombres de empresas, productos y servicios pueden ser marcas registradas o

marcas de servicio de terceros.

Avisos 181

Glosario

A

Agente ampliado. Los agentes ampliados se utilizan

para integrar las funciones de control de trabajos de

Tivoli Workload Scheduler con otros sistemas

operativos (por ejemplo, MVS) y aplicaciones (por

ejemplo, Oracle Applications, Peoplesoft, y Baan). Los

agentes ampliados utilizan métodos de acceso llamados

mediante scripts para comunicarse con sistemas

externos.

Agente de red. Tipo de agente ampliado utilizado

para crear dependencias entre trabajos y secuencias de

trabajos que residen en redes de Tivoli Workload

Scheduler independientes. Véase también

“Dependencia inter-red (INET)”.

Agente tolerante a errores. Estación de trabajo agente

de la red de Tivoli Workload Scheduler capaz de

resolver dependencias locales y ejecutar sus trabajos en

ausencia de un gestor de dominio.

Archivo stdlist. Se crea un archivo de lista estándar

para cada trabajo ejecutado por Tivoli Workload

Scheduler. Los archivos de lista estándar contienen

mensajes de cabecera y de cola, comandos reenviados,

errores y avisos. Estos archivos se pueden utilizar para

resolver problemas en la ejecución de los trabajos.

Archivo Symphony. Este archivo contiene la

información de planificación que necesita el proceso de

control de producción (batchman) para ejecutar el plan.

El archivo se crea y se carga durante la fase de

pre-producción. Durante la fase de producción, el

archivo se actualiza continuamente para indicar el

estado actual del proceso de producción: trabajo

finalizado, trabajo en proceso, trabajo por hacer. Para

gestionar el proceso de producción, el contenido del

archivo Symphony (plan) se puede visualizar y alterar

con Job Scheduling Console.

B

Base de datos. La base de datos contiene todas las

definiciones que el usuario ha creado para objetos de

planificación (tales como trabajos, secuencias de

trabajos, recursos, estaciones de trabajo, etc). Además,

la base de datos contiene otros elementos de

información importantes, tales como estadísticas de la

ejecución de trabajos y secuencias de trabajos,

información sobre el ID de usuario que ha creado un

objeto y la fecha de última modificación de un objeto.

En cambio, el plan sólo contiene los trabajos y

secuencias de trabajos (incluidos los objetos

dependientes) que están planificados para ejecutarse en

la producción del día actual.

Base de datos ampliada. Las bases de datos

ampliadas permiten nombres más largos para objetos

de base de datos, tales como trabajos, secuencias de

trabajos, estaciones de trabajo, dominios y usuarios. Las

bases de datos ampliadas se configuran utilizando el

comando dbexpand o como una opción durante la

instalación. No amplíe la base de datos sin antes

conocer las implicaciones y el efecto de ese comando.

Batchman. Batchman es un proceso que se inicia al

comienzo de cada día de proceso de Tivoli Workload

Scheduler para ejecutar trabajos de acuerdo con la

información contenida en el archivo Symphony.

C

Calendario. Un calendario es un objeto definido en la

base de datos de Tivoli Workload Scheduler que

contiene una lista de fechas de planificación. Debido a

que es un objeto exclusivo definido en una base de

datos, se puede asignar a varias secuencias de trabajos.

La asignación de un calendario a una secuencia de

trabajos hace que ésta se ejecute los días especificados

en el calendario. Observe que un calendario se puede

utilizar como un ciclo de ejecución incluyente o

excluyente.

Caracteres comodín. Los comodines para Tivoli

Workload Scheduler son:

? Sustituye a un carácter alfanumérico individual.

% Sustituye a un carácter numérico individual.

* Sustituye a un número cualquiera de caracteres

alfanuméricos en Tivoli Job Scheduling Console.

@ Sustituye a un número cualquiera de caracteres

alfanuméricos en la línea de comandos de Tivoli

Workload Scheduler.

Normalmente los caracteres comodín se utilizan para

refinar una búsqueda de uno o más objetos de la base

de datos. Por ejemplo, si desea listar todas las

estaciones de trabajo, puede especificar el carácter

comodín representado por el asterisco (*). Para obtener

una lista de las estaciones de trabajo del grupo

comprendido entre site1 y site8, puede especificar

site%.

Ciclo de ejecución. Un ciclo de ejecución especifica

los días para los que está planificada la ejecución de

una secuencia de trabajos. En Tivoli Workload

Scheduler, puede especificar tres tipos de ciclos de

ejecución: un ciclo de ejecución Simple, un ciclo de


ejecución Semanal o un ciclo de ejecución de

Calendario (normalmente denominado calendario).

Observe que cada tipo de ciclo de ejecución puede ser

incluyente o excluyente. Es decir, un ciclo de ejecución

puede definir los días que una secuencia de trabajos

está incluida en el ciclo de producción o los días que

una secuencia de trabajos está excluida del ciclo de

producción. Cuando define varios ciclos de ejecución

para una secuencia de trabajos, y los ciclos de ejecución

incluyentes y excluyentes especifican los mismos días,

los ciclos de ejecución excluyentes tienen prioridad.

Ciclo de ejecución excluyente. Ciclo de ejecución que

especifica los días en los que no se puede ejecutar una

secuencia de trabajos. Los ciclos de ejecución

excluyentes tienen prioridad sobre los ciclos de

ejecución incluyentes.

Ciclo de ejecución incluyente. Ciclo de ejecución que

especifica los días para los que está planificada la

ejecución de una secuencia de trabajos. Los ciclos de

ejecución excluyentes tienen prioridad sobre los ciclos

de ejecución incluyentes.

Ciclo de ejecución semanal. Ciclo de ejecución que

especifica los días de la semana en los que se ejecuta

una secuencia de trabajos. Por ejemplo, se puede

especificar que una secuencia de trabajos se ejecute

cada lunes, miércoles y viernes utilizando un ciclo de

ejecución semanal. Un ciclo de ejecución semanal se

define para una secuencia de trabajos determinada y no

puede ser utilizado por varias secuencias de trabajos.

Para obtener más información, véase Ciclo de ejecución.

Ciclo de ejecución simple. Un ciclo de ejecución

simple es un conjunto específico de días definidos por

el usuario en los que se ejecuta una secuencia de

trabajos. Un ciclo de ejecución simple se define para

una secuencia de trabajos determinada y no puede ser

utilizado por varias secuencias de trabajos. Para

obtener más información, véase Ciclo de ejecución.

Clase de estación de trabajo. Una clase de estación de

trabajo es un grupo de estaciones de trabajo. Una clase

puede comprender un número cualquiera de estaciones

de trabajo. Se pueden asignar trabajos y secuencias de

trabajos para que se ejecuten en una clase de estación

de trabajo. Esto facilita la replicación de un trabajo o

secuencia de trabajos entre muchas estaciones de

trabajo.

Comandos de servicio. Conjunto de ejecutables para

gestionar Tivoli Workload Scheduler desde una línea de

comandos.

Composer. Composer es una aplicación de línea de

comandos heredada que se utiliza para gestionar las

definiciones de los objetos de planificación contenidos

en la base de datos.

Conman. Conman (console manager) es una

aplicación de línea de comandos heredada que se

utiliza para gestionar el entorno de producción.

Conman realiza las tareas siguientes: iniciar y detener

procesos de producción, alterar y visualizar

planificaciones y trabajos contenidos en el plan y

controlar la vinculación de estaciones de trabajo en una

red.

D

Delimitación. La delimitación de trabajo es un control

maestro sobre la ejecución de trabajos en una estación

de trabajo. La delimitación de trabajo es un nivel de

prioridad que debe ser superado por la prioridad de un

trabajo o secuencia de trabajos para que se pueda

ejecutar. Por ejemplo, un valor de delimitación

establecido en 40 impide que se ejecuten los trabajos

cuya prioridad sea igual o menor que 40.

Dependencia. Una dependencia es un requisito previo

que se debe satisfacer para que pueda comenzar la

ejecución de un trabajo o secuencia de trabajos. El

número máximo de dependencias permitidas para un

trabajo o secuencia de trabajos es 40. Tivoli Workload

Scheduler utiliza cuatro tipos de dependencias:

dependencias de continuación, dependencias de

recurso, dependencias de archivo y dependencias de

solicitud.

Dependencia de continuación. Dependencia en la que

un trabajo o secuencia de trabajos no puede comenzar a

ejecutarse hasta que hayan finalizado satisfactoriamente

otros trabajos o secuencias de trabajos.

Dependencias inter-red (INET). Dependencia entre

trabajos o secuencias de trabajos que residen en redes

de Tivoli Workload Scheduler independientes. Véase

también “Agente de red”.

Dominio. Un dominio es un grupo de estaciones de

trabajo de Tivoli Workload Scheduler que tiene un

nombre asignado y consta de uno o más agentes y de

un gestor de dominio que actúa como centro de

gestión. Todos los dominios tienen un dominio

primario, excepto el dominio maestro.

Duración. Es el periodo de tiempo previsto para la

finalización de un trabajo. En la vista Franja horaria de

los trabajos de la base de datos, la duración se

representa mediante una barra azul claro en el centro

de la barra de actividad o mediante un rombo azul

claro.

E

Estación de trabajo. Una estación de trabajo es

normalmente un sistema individual en la que se

ejecutan trabajos y secuencias de trabajos. Las

estaciones de trabajo se definen en la base de datos de

Tivoli Workload Scheduler como objeto exclusivo. Es

necesaria una definición de estación de trabajo para

cada sistema donde se ejecuten trabajos o secuencias de

trabajos en la red de Workload Scheduler.


Estado. El estado refleja el estado actual de los

trabajos y secuencias de trabajos dentro de Job

Scheduling Console. El estado de Job Scheduling

Console es común a Tivoli Workload Scheduler y OPC.

Véase también Estado interno.

Estado de trabajo. Véase “Estado”.

Estado interno. El estado interno refleja el estado

actual de trabajos y secuencias de trabajos en el motor

de Tivoli Workload Scheduler. El estado interno es

exclusivo de Tivoli Workload Scheduler. Véase también

Estado.

G

Gestor de dominio. Es el centro de gestión de un

dominio de Tivoli Workload Scheduler. Todas las

comunicaciones intercambiadas con los agentes de un

dominio se direccionan a través del gestor de dominio.

Gestor de dominio maestro. En una red de Tivoli

Workload Scheduler, el gestor de dominio maestro

mantiene los archivos utilizados para documentar los

objetos de planificación. El gestor de dominio maestro

crea el plan al inicio de cada día y realiza todas las

acciones de registro y notificación para la red.

H

Hora de inicio más temprana. Es la hora antes de la

cual el trabajo o secuencia de trabajos no puede

comenzar. La hora de inicio más temprana es una

estimación basada en ejecuciones anteriores del trabajo

o secuencia de trabajos. Sin embargo, el trabajo o

secuencia de trabajos puede comenzar después de la

hora especificada siempre que se satisfagan todas las

demás dependencias. En la franja horaria, la hora de

inicio está representada por el comienzo (extremo

izquierdo) de la barra de actividad azul marino. Para

las instancias de trabajo, la hora de inicio calculada por

OPC se representa mediante una barra azul claro.

Véase también “Hora de inicio real” y “Hora de inicio

planificada”.

Hora de inicio planificada. Hora estimada por el

Tivoli Workload Scheduler para el inicio de una

instancia de trabajo. Esta estimación está basada en las

horas de inicio de ejecuciones anteriores.

Host. Estación de trabajo de Workload Scheduler que

es necesaria para los agentes ampliados. Puede ser

cualquier estación de trabajo de Tivoli Workload

Scheduler, con la excepción de otro agente ampliado.

I

Instancia de secuencia de trabajos. Secuencia de

trabajos que está planificada para una fecha de

ejecución específica en el plan. Véase también

“Secuencia de trabajos”.

Instancia de trabajo. Trabajo que está planificado para

una fecha de ejecución específica en el plan. Véase

también “Trabajo”.

L

Límite. Los límites de trabajos proporcionan una

forma de asignar un número específico de intervalos de

trabajo en los que se permite que Tivoli Workload

Scheduler ejecute trabajos. Se puede definir un límite

de trabajos para cada secuencia de trabajos y para cada

estación de trabajo. Por ejemplo, si el límite de trabajos

de la estación de trabajo está establecido en 25, Tivoli

Workload Scheduler puede tener un máximo de 25

trabajos en ejecución simultánea en la estación de

trabajo.

Lista. Una lista muestra objetos de planificación de

trabajos. Debe crear listas independientes para cada

objeto de planificación de trabajos. Existen dos tipos de

listas para cada objeto de planificación de trabajos: una

lista de definiciones en la base de datos y una lista de

instancias en el plan.

M

Método de acceso. Un método de acceso es un

ejecutable que utilizan los agentes ampliados para

conectar y controlar la ejecución de trabajos en otros

sistemas operativos (por ejemplo, MVS) y aplicaciones

(por ejemplo, Oracle Applications, Peoplesoft y Baan).

El método de acceso se debe especificar en la definición

de estación de trabajo para el agente ampliado.

O

Opciones globales. Las opciones globales se definen

en el archivo globalopts del gestor de dominio maestro

y son aplicables a todas las estaciones de trabajo de la

red de Tivoli Workload Scheduler. Véase también

“Opciones locales”.

Opciones locales. Las opciones locales se definen en

el archivo localopts. Cada estación de trabajo de la red

de Tivoli Workload Scheduler debe tener un archivo

localopts. Los valores de este archivo sólo son

aplicables a la estación de trabajo correspondiente.

Véase también “Opciones globales”.

Glosario 185

P

Parámetro. Los parámetros se utilizan para entrar

valores en los trabajos y secuencias de trabajos. Cuando

se utiliza un parámetro en un script de trabajo, el

parámetro es sustituido por el valor durante la

ejecución. En este caso, el parámetro debe estar

definido en la estación de trabajo donde se utilizará.

No se pueden utilizar parámetros al crear scripts para

trabajos de agente ampliado.

Plan. El plan contiene toda la actividad de

planificación de trabajos planificada para un día

individual. En Tivoli Workload Scheduler, el plan se

crea cada 24 horas y consta de todos los trabajos,

secuencias de trabajos y objetos de dependencia que

están planificados para ejecutarse para ese día. Todas

las secuencias de trabajos para las que se han creado

ciclos de ejecución se planifican automáticamente y se

incluyen en el plan. A medida que el ciclo de

producción progresa, los trabajos y secuencias de

trabajos del plan se ejecutan de acuerdo con sus

restricciones horarias y otras dependencias. Cualquier

trabajo o secuencia de trabajos que no se ejecute

satisfactoriamente se traslada al plan del día siguiente.

Plazo límite. Es el último punto en el tiempo en el

que un trabajo o secuencia de trabajos puede comenzar

la ejecución. Esto corresponde a la especificación

horaria Until en el maestro heredado.

Predecesor. Trabajo que debe finalizar

satisfactoriamente para que pueda comenzar la

ejecución de trabajos sucesores.

Prioridad. Tivoli Workload Scheduler tiene un sistema

de colas de espera para los trabajos y secuencias de

trabajos del plan. El usuario puede asignar un nivel de

prioridad a cada trabajo y secuencia de trabajos,

comprendido entre 0 y 101. Una prioridad de 0 hace

que no se realice la ejecución.

R

Recurso. Los recursos pueden representar recursos

físicos o lógicos del sistema. Una vez definidos en la

base de datos de Tivoli Workload Scheduler, los

recursos se pueden utilizar como dependencias para

trabajos y secuencias de trabajo. Por ejemplo, puede

definir un recurso denominado ″cintas″ con un valor

unitario de 2. Luego, defina trabajos que necesiten dos

unidades de cinta disponibles como dependencia. Los

trabajos con esta dependencia no se pueden ejecutar

simultáneamente, pues cada vez que se ejecuta un

trabajo, el recurso “cintas” está en uso.

Región de gestión Tivoli (TMR). En un entorno

Tivoli, el conjunto formado por un servidor Tivoli y los

clientes a los que atiende. Puede existir más de una

TMR en una organización. Una TMR se ocupa de la

conectividad física de los recursos, mientras que una

región de política aborda la organización lógica de los

recursos.

Restricciones horarias. Se pueden especificar

restricciones horarias para trabajos y secuencias de

trabajos. Se puede especificar una hora para el inicio de

la ejecución o una hora pasada la cual no se intentará

la ejecución. Mediante ambas especificaciones, puede

definir un intervalo dentro del cual se ejecutará un

trabajo o secuencia de trabajos. Para los trabajos, puede

también especificar una frecuencia de repetición. Por

ejemplo, puede hacer que Tivoli Workload Scheduler

ejecute el mismo trabajo cada 30 minutos entre las

horas 8:30 a.m. y 1:30 p.m.

S

Secuencia de trabajos. Una secuencia de trabajos

consta de una lista de trabajos que se ejecutan como

una unidad (tal como una aplicación de copia de

seguridad semanal), junto con especificaciones horarias,

prioridades y otras dependencias que determinan el

orden exacto de ejecución de los trabajos.

Secuencia de trabajos final. La secuencia de trabajos

FINAL debe ser la última secuencia de trabajos que se

ejecuta en un día de producción. Contiene un trabajo

por el que se ejecuta el archivo de script Jnextday.

Solicitud. Las solicitudes se pueden utilizar como

dependencias para trabajos y secuencias de trabajos.

Una solicitud debe ser respondida afirmativamente

para que se ejecute un trabajo o secuencia de trabajos.

Existen dos tipos de solicitudes: predefinidas y ad hoc.

Una solicitud ad hoc se define dentro de las

propiedades de un trabajo o secuencia de trabajos y es

exclusiva de ese trabajo o secuencia de trabajos. Una

solicitud predefinida se define en la base de datos de

Tivoli Workload Scheduler y puede ser utilizada por

cualquier trabajo o secuencia de trabajos.

Sucesor. Trabajo que no puede comenzar hasta que

finalicen satisfactoriamente todos los trabajos

predecesores de los cuales depende.

T

Tivoli Management Framework (TMF). Software base

necesario para ejecutar las aplicaciones incluidas en el

paquete de productos Tivoli. Esta infraestructura de

software permite la integración de aplicaciones de

gestión de sistemas pertenecientes a Tivoli Systems Inc.

y sus socios comerciales. Tivoli Management

Framework incluye lo siguiente:

v Intermediario de petición de objetos (oserv)

v Base de datos de objetos distribuida

v Funciones de administración básicas

v Servicios de aplicaciones básicos


v Servicios básicos de escritorio como la interfaz

gráfica de usuario

En un entorno Tivoli, se instala Tivoli Management

Framework en cada cliente y en cada servidor. Sin

embargo, el servidor TMR es el único servidor que

contiene la base de datos de objetos completa.

Trabajo. Un trabajo es una unidad de trabajo que se

procesa en una estación de trabajo. La definición del

trabajo consta de un nombre de trabajo exclusivo

contenido en la base de datos de Tivoli Workload

Scheduler junto con otra información necesaria para

ejecutar el trabajo. Cuando el usuario añade un trabajo

a una secuencia de trabajos, puede definir sus

dependencias y restricciones horarias, tales como la

hora de inicio prevista y el plazo límite.

Trabajo externo. Trabajo perteneciente a una secuencia

de trabajos que es un predecesor de un trabajo situado

en otra secuencia de trabajos. Un trabajo externo se

representa mediante un icono de espacio reservado en

la vista Gráfico de la secuencia de trabajos.

Trabajo Jnextday. El proceso de pre-producción y

post-producción se puede automatizar por completo

planificando el trabajo Jnextday para que se ejecute al

final de cada día. Se proporciona un trabajo jnextday de

ejemplo en TWShome\Jnextday. El trabajo Jnextday

efectúa lo siguiente: configura el proceso del día

siguiente (contenido en el archivo de Symphony),

imprime informes, traspasa a otro día trabajos no

finalizados y detiene y reinicia el Tivoli Workload

Scheduler.

Trabajo / secuencia de trabajos de inter-red (INET).

Trabajo o secuencia de trabajos de una red remota de

Tivoli Workload Scheduler que precede a un trabajo o

secuencia de trabajos de la red local. Un trabajo de

inter-red se representa mediante un icono de espacio

reservado en la vista Gráfico de la secuencia de

trabajos. Véase también “Agente de red”.

Trabajos interactivos. Trabajo que se ejecuta

interactivamente en un escritorio de Windows NT.

U

Usuario. En Windows NT solamente, el nombre de

usuario especificado en el valor “Logon” de una

definición de trabajo debe coincidir con una definición

de usuario. Las definiciones proporcionan las

contraseñas de usuario necesarias para que Tivoli

Workload Scheduler ejecute los trabajos.

V

Vista en árbol. Vista situada en el lado izquierdo de

Job Scheduling Console donde se muestra el servidor

de Tivoli Workload Scheduler, grupos de listas

predeterminadas y grupos de listas creadas por el

usuario.

X

X-agent. Véase “Agente ampliado”.

Glosario 187

Índice

Caracteres

Especiales/usr/unison/components 169

Números5601-453, número de programa xvi

5601-454, número de programa xvi

5765-086, número de programa xvi

Aaccesibilidad xvii

actualizar 36

Nivel 1 65, 66

plataformas de Nivel 2 73

adapter.configactualizar 34

Administradorañadir 114

agente ampliadodetrás de cortafuegos 165

agentes ampliados 6

APARIY45982 92

IY46485 108

IY47753 34

IY48407 32

IY49332 79, 81

IY50279 35

IY50282 34

IY53209 122, 123

IY57227 132

archivo, dependencia de 6

archivo de componentes 9

archivo de componentes, visualización 9

archivo de registroatributos 8

ejemplo 9

archivos de configuración 34

archivos de registro 31

arranque, script 4

arreglos, obtención 172

asignador de objetos 114

AT, palabra clave 106, 107

auditoríanivel del plan 90

nivel para base de datos 89

autoridad de certificación 159

Bbase de datos

montar 118

base de datos, nivel de auditoría 89

bases de conocimiento, búsqueda para

encontrar la solución a un problema de

software 171

behindfirewall, opción 164

biblioteca xii

biblioteca de publicaciones del

producto xii

bm check deadline, opción 94

bm check file, opción 94

bm check status, opción 94

bm check until, opción 94

bm look, opción 94

bm read, opción 94

bm status, opción 94

bm verbose, opción 95

BmEvents.confactualizar 34

BookManager xvi

Ccaonly SSL auth mode, opción 97

carryforward, opción 89

carryforward, palabra clave 107

CD, instalación 29

centralized security, opción 89

centros de información, búsqueda para

encontrar una solución a un problema

de software 171

certificados 154, 158

claves privadas 158

CLEvents.confactualizar 34

CLIconman 17

switchmg 17

wimpspo 57

winstsp 57

wmaeutil 33

comando evtsize 80

comandosconsole 105

dumpsec 82

evtsize 80

makesec 82

wmaeutil 82

wremovsp 168

compiler 105, 107

comunicación SSLenabled 161

force 161

on 161

conector 35

ubicación de instalación 20

Conectordónde instalar 20

conector de TWS 3

instancias 20

configuración, scripts de 108

conmutargestor de dominio de reserva 17

tolerante a errores 17

console, comando 105

conveniostipo de letra xvii

convenios de denominaciónestaciones de trabajo 19

convenios tipográficos xvii

copia de seguridad, archivos de 34

cortafuegos, soporte de 164

cpu SSL auth mode, opción 97

cpuname 118

crearel maestro de copia de seguridad 117

usuario en Windows 28

cuenta de usuariocrear en UNIX 27

crear en Windows 28

derechos 28

customize, scriptejecutar 74

sintaxis 61

Ddefinir opciones globales 87

definir opciones locales 92

dependenciaarchivo 6

dependencias inter-red 16

desatendida, instalación 49

desinstalarplataformas de Nivel 1 167


desvincular estaciones de trabajo 32

detenerservicios 32

determinación del problemadeterminación del impacto comercial

para IBM Software Support 173

determinación del problema para IBM

Software Support 173

envío del problema a IBM Software

Support 174

detrás de cortafuegosagente ampliado 165

directorioscompartir 102

directorios compartidosgestor de dominio maestro 102

dumpsec, comando 82

Eeliminar el producto 167

enable list security check 89

escritorio de Tivoli 114

estaciones de trabajoconvenios de denominación 19

desvincular 32

estado completo 117


Ffinal 105, 117

final, secuencia de trabajospersonalizar 106

Ggestor de dominio de reserva

conmutar 17

gestor de dominio maestro 3

directorios compartidos 102

ubicación de instalación 20

globalopts 117

actualizar 34

globalopts, archivofunción de huso horario 84

grupos de productos 8

Hhabilitar función de huso horario 84

history, opción 90

hora de inicio 90

huso horarioen maestro de copia de

seguridad 117

opción enable 90

visión general 21

IIBM Software Support

determinación del impacto comercial

para IBM Software Support 173

informes de pre-producción 106

inicio 85, 106, 107

inicio del día 90, 107

instalaciónactualizar 36, 65, 66

añadir nuevo componente 46

archivos de registro 31

bloques de paquetes de software 55

desatendida 49

discos CD 29

nueva instancia 39



programa asistente 39

promover 48

requisito previos 35, 36

Internet, búsqueda para encontrar una

solución a un problema de

software 172

Jjm job table size, opción 95

jm look, opción 95

jm nice, opción 95

jm no root, opción 95

jm read, opción 95

Jnextday 105

ejecutar 79

Job Scheduling Console 35

varios usuarios 114

Llibros xii

véase Publicaciones xii, xvi

list, permisoopción enable 89

localoptsactualizar 34

logman 105

Mmaestro

backup 116

maestro de copia de seguridad 116

crear 117

trasladar 117

manuales xii

véase Publicaciones xii, xvi

mensajes de consola y mensajes de

solicitud 104

mensajes de proceso 104

merge stdlists, opción 95

método de accesoUNIX local 7

UNIX remoto 7

migrar 36

mm read, opción 96

mm response, opción 96

mm retry link, opción 96

mm sound off, opción 96

mm unlink, opción 96

montaje NFS 117

montar bases de datos 118

mozart 119

Nnivel de mensajes 105

nivel de seguridadenabled 161

force 161

on 161

nm ipvalidate, opción 96

nm mortal 96

nm port, opción 97

nm read, opción 97

nm retry, opción 97

nm SSL port, opción 97

nodo gestionado 114

nombre de usuariocrear 40, 44, 47, 56

nombres de directorio, notación xviii

nombres de ruta, notación xviii

notaciónnombres de ruta xviii

tipo de letra xviii

variables de entorno xviii

número de puerto 57, 62, 162

números de programa5601-453 xvi

5601-454 xvi

5765-086 xvi

OON, palabra clave 106

opciones globalesarchivo de ejemplo 91

definir 87

plantilla de archivo 91

sintaxis 87

opciones localesarchivo de ejemplo 100

definir 92, 103

definir sysloglocal 104

plantilla de archivo 100

sintaxis 92

SSL 162

oserv 114

Ppaquetes de idioma

eliminar 167

instalar 24, 25, 47, 53, 55, 58, 72, 168

parameters.KEY 117

parámetros 117

plan, nivel de auditoría 90

plazo límite 85, 107

programas de instalación 29

publicaciones xii

acceso en línea xvi

solicitud xvi

publicaciones, en línea xvi

publicaciones en línea xvi

acceso xvi

publicaciones en soporte de

software xvi

puerto tcp 57, 62

RRegión de gestión Tivoli 114

rep8 105

reptr 105

resolver dependencias 117

Sscripts

arranque 4

configuración 7

scripts de configuración 7, 108

scheddate 108

schedulr 105, 107

secuencia de trabajos final 106

añadir 79

seguridadvisión general 153

seguridad, archivo deactualizar 82

definir administradores de Tivoli 114

serviciosdetener 32

Servidor de gestión Tivoli 114

setup_env 33, 82

Sfinal 105

añadir 79


sitio Web de soporte, búsqueda para

encontrar una solución a un problema

de software 171

Software Supportdescripción del problema para IBM

Software Support 173

envío del problema a IBM Software

Support 174

ponerse en contacto 172

solicitud de publicaciones xvi

soporte al clientevéase soporte de software 172

soporte de SSLconceptos 154

configurar 158

métodos de autenticación 156

SSL, atributosconfigurar 161

SSL, número de puerto 162

SSL auth mode, opción 97

SSL auth string 98

SSL CA certificate, opción 98

SSL certificate, opción 98

SSL certificate chain, opción 98

SSL encryption cipher, opción 98

SSL key, opción 98

SSL key pwd, opción 98

SSL random seed, opción 99

stageman 105

stdlist width, opción 99

string SSL auth mode, opción 97

submit 20

switchmgr 17, 117

Symphony 20

sync level 99

syslog 104

syslog local, opción 99

Ttcp timeout, opción 99

thiscpu 100

timezone enable 85, 119

Tivoli Management Frameworkcomo requisito previo 36

versiones soportadas 36

Tivoli Software Information Center xvi

tolerancia a erroresconmutar 17

gestor de dominio de reserva 17

traspaso, opción 91

TWS_TISDIR, variable 83

twsinstautorización, roles 26

utilización 51

Vvariables, notación para xviii

variables de entorno, notación xviii

ventanaCrear estaciones de trabajo 118

Wwmaeutil 33

wmaeutil, comando 82

wr enable compression, opción 100

wr read, opción 100

wr unlink, opción 100

wremovsp, comando 168

Índice 191

��

Número de Programa: 5698-WSH

SC10-3833-02

T l Tivoli Workload -...

Documents

Transcript of T l Tivoli Workload -...